Bug#800846: error message in preinst doesn't match test, checks for kernel 3.2 but tells the user it needs 2.6.32
Package: libc6 Version: 2.21-0experimental1 I had an expermimental chroot on a system that happened to be running an old kernel. I got an error message about needing a 2.6.32 kernel which was strange as I already had a 2.6.32 kernel. Reading the preinst revealed # The GNU libc requires a >= 3.2 kernel, found in wheezy if linux_compare_versions "$kernel_ver" lt 3.2 then echo WARNING: this version of the GNU libc requires kernel version echo 2.6.32 or later. Please upgrade your kernel before installing echo glibc. kernel26_help exit 1 fi So it's checking for 3.2 but telling the user they need 2.6.32.
Bug#669858: eglibc FTBFS on mips and mipsel, Encountered regressions that don't match expected failures:
Package: eglibc Severity: serious From the mips build log (the mipsel one looks the same to me though I haven't done a thourough check to see if the list of failed tests is identical Encountered regressions that don't match expected failures: tst-cancel24, Error 1 tst-cancelx10, Error 1 tst-cancelx11, Error 1 tst-cancelx12, Error 1 tst-cancelx13, Error 1 tst-cancelx14, Error 1 tst-cancelx15, Error 1 tst-cancelx16, Error 1 tst-cancelx17, Error 1 tst-cancelx18, Error 1 tst-cancelx20, Error 1 tst-cancelx21, Error 1 tst-cancelx4, Error 1 tst-cancelx5, Error 1 tst-cancelx8, Error 1 tst-cancelx9, Error 1 tst-chk4, Error 1 tst-chk5, Error 1 tst-chk6, Error 1 tst-cleanupx0, Error 1 tst-cleanupx1, Error 1 tst-cleanupx3, Error 1 tst-cleanupx4, Error 1 tst-lfschk4, Error 1 tst-lfschk5, Error 1 tst-lfschk6, Error 1 tst-mqueue8x, Error 1 tst-oncex3, Error 1 tst-oncex4, Error 1 -- 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/4f92a2e4.2000...@p10link.net
Bug#652844: please include patch to reduce namespace polloution from sys/ucontext.h on arm
package: libc6-dev
version:
severity: important
justification: causes other packages to FTBFS
On arm* sys/ucontext.h heavilly polloutes the global
namespace firstly by including sys/user.h (which defines
among other things a type called struct user and secondly
by defining symbols and #defines named R? to represent
the processor registers.
That issue in itself is nothing new but fairly recently*
signal.h started including sys/ucontext.h by default
causing programs that (quite reasonable IMO) used those
names for their own symbols to fail to build on arm. This
has been especially noticable recently because debian is
trying to build the new armhf port.
After discussions on debian-arm/debian-glibc/linaro-dev
(I do not know which responders came from which list)
I was given the following advice on the struct user
issue by Ulrich Weigand.
Now, glibc also provides a file sys/ucontext.h that defines
layouts of register sets for use with signal handlers as well
as the makecontext/setcontext/getcontext family of routines.
Usually, those layouts tend to be in fact identical to the
layouts described in sys/user.h / sys/procfs.h. Apparently,
whoever implemented the ARM version of sys/ucontext.h was
trying to avoid some seemingly unnecessary code duplication
by making sys/ucontext.h *include* sys/procfs.h and using
the information from there directly. This is not done on other
platforms, for precisely the reason that the sys/procfs.h
and sys/user.h headers do pollute the name space ...
So I think the right thing to do in the short term would be to
stop sys/ucontext.h including sys/procfs.h, and instead add the
register set information there directly, even if that means some
duplication of code. (Again, since this is never-changing ABI,
duplication isn't actually all that bad. Also, all the other
platforms do it that way too, so why should ARM be different ...)
On the issue of the R? definitions I proposed renaming them
to REG_R?. The use of a REG_ prefix is consistent with
x86, x64 and sparc (I couldn't find any comparable definitions
at all on other architectures I looked at) I asked what the
impact of this change would be on the aforementioned mailing
lists and got the following reply from Konstantinos Margaritis
at worst the packages that had to be workaround on arm* for this, can
have the workaround removed.
The attached patch implements these changes (note that the filename
of the patch currently starts with unaassigned as that was the
atatus when I prepared it.
My tests do not show any new failures in the libc testsuite (though
I do get failures that debian considers unexpected regardless
of whether this patch is applied or not)
The patch was accepted upstream by Joseph Myers jos...@codesourcery.com
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff;h=c1e30fd8bffd53aa9849fe410ca8a4204c91f836
Please include this change in the next upload of eglibc to sid.
* I have not investigated exactly when this change occoured
but it was somewhere between the version in debian squeeze
and the version in debian wheezy.
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h
===
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2006-08-17 01:23:58.0 +
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2011-12-17 12:52:43.0 +
@@ -23,7 +23,6 @@
#include features.h
#include signal.h
-#include sys/procfs.h
/* We need the signal context definitions even if they are not used
included in signal.h. */
@@ -35,47 +34,64 @@
#define NGREG 18
/* Container for all general registers. */
-typedef elf_gregset_t gregset_t;
+typedef greg_t gregset_t[NGREG];
/* Number of each register is the `gregset_t' array. */
enum
{
- R0 = 0,
-#define R0 R0
- R1 = 1,
-#define R1 R1
- R2 = 2,
-#define R2 R2
- R3 = 3,
-#define R3 R3
- R4 = 4,
-#define R4 R4
- R5 = 5,
-#define R5 R5
- R6 = 6,
-#define R6 R6
- R7 = 7,
-#define R7 R7
- R8 = 8,
-#define R8 R8
- R9 = 9,
-#define R9 R9
- R10 = 10,
-#define R10 R10
- R11 = 11,
-#define R11 R11
- R12 = 12,
-#define R12 R12
- R13 = 13,
-#define R13 R13
- R14 = 14,
-#define R14 R14
- R15 = 15
-#define R15 R15
+ REG_R0 = 0,
+#define REG_R0 REG_R0
+ REG_R1 = 1,
+#define REG_R1 REG_R1
+ REG_R2 = 2,
+#define REG_R2 REG_R2
+ REG_R3 = 3,
+#define REG_R3 REG_R3
+ REG_R4 = 4,
+#define REG_R4 REG_R4
+ REG_R5 = 5,
+#define REG_R5 REG_R5
+ REG_R6 = 6,
+#define REG_R6 REG_R6
+ REG_R7 = 7,
+#define REG_R7 REG_R7
+ REG_R8 = 8,
+#define REG_R8 REG_R8
+ REG_R9 = 9,
+#define REG_R9 REG_R9
+ REG_R10 = 10,
+#define REG_R10 REG_R10
+ REG_R11 = 11,
+#define REG_R11 REG_R11
+ REG_R12 = 12,
+#define REG_R12 REG_R12
+ REG_R13 = 13,
+#define REG_R13 REG_R13
+ REG_R14 = 14,
+#define REG_R14 REG_R14
+ REG_R15 = 15
+#define REG_R15 REG_R15
};
+struct _libc_fpstate
+{
+ struct
+ {
+unsigned int sign1:1;
+unsigned int
Re: [patch] reduce namespace polloution from sys/ucontext.h on arm
Joseph S. Myers wrote: The most obvious users of these definitions would be (native) GDB and gdbserver - do those still build OK (i.e. include the correct headers to get the definitions they need and not rely on any definitions that were removed) after this patch? I have built the debian gdb package (which builds both gdb and gdbserver) sucessfully on a system with this patch. Have you verified that it still works to include both sys/ucontext.h and sys/procfs.h in the same source file, in either order? I had already tried that in one order, just tried the other order too. Both work fine. When I copied a structure definition over to remove the dependency I made sure to rename it (following the name used for the equivilent structure on amd64). -- 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/4eeff00c.3060...@p10link.net
Re: struct user conflicts on arm
Konstantinos Margaritis wrote:
Does anyone know what the impact of renaming these to use a REG_ prefix like
i386, amd64 and sparc do* would be?
at worst the packages that had to be workaround on arm* for this, can
have the workaround removed.
I have prepared a patch (attatched) that eliminates the dependency on
sys/procfs.h and renames R? to REG_R?. I have tested it by modifying the
header locally. I am now attempting to rebuild glibc with the patch.
After rebuilding glibc I will install it and attempt to rebuild GDB.
Please comment on the patch and advise on the best route for submission
(that is should I go through debian, through eglibc or direct to glibc?)
Since you're in the process of fixing things for glibc/arm
Note that I am not a glibc developer nor am I a dd (and even if I was a
dd I don't think I would NMU glibc). I'm just a user with an interest
in the future of debian on arm.
would you
mind also looking at WCHAR_MIN/MAX undefined for arm?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
They most certainly are defined. The trouble is that WCHAR_MAX is defined
in a strange way.
#define __WCHAR_MAX ( (wchar_t) - 1 )
This definition is fine for normal c or c++ code but
it cannot be properly evaluated in the context of a
preprocessor conditional.
The bug report has a patch (actually a replacement for
an existing patch) which looks fine to me.
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h
===
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2006-08-17 01:23:58.0 +
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2011-12-17 12:52:43.0 +
@@ -23,7 +23,6 @@
#include features.h
#include signal.h
-#include sys/procfs.h
/* We need the signal context definitions even if they are not used
included in signal.h. */
@@ -35,47 +34,64 @@
#define NGREG 18
/* Container for all general registers. */
-typedef elf_gregset_t gregset_t;
+typedef greg_t gregset_t[NGREG];
/* Number of each register is the `gregset_t' array. */
enum
{
- R0 = 0,
-#define R0 R0
- R1 = 1,
-#define R1 R1
- R2 = 2,
-#define R2 R2
- R3 = 3,
-#define R3 R3
- R4 = 4,
-#define R4 R4
- R5 = 5,
-#define R5 R5
- R6 = 6,
-#define R6 R6
- R7 = 7,
-#define R7 R7
- R8 = 8,
-#define R8 R8
- R9 = 9,
-#define R9 R9
- R10 = 10,
-#define R10 R10
- R11 = 11,
-#define R11 R11
- R12 = 12,
-#define R12 R12
- R13 = 13,
-#define R13 R13
- R14 = 14,
-#define R14 R14
- R15 = 15
-#define R15 R15
+ REG_R0 = 0,
+#define REG_R0 REG_R0
+ REG_R1 = 1,
+#define REG_R1 REG_R1
+ REG_R2 = 2,
+#define REG_R2 REG_R2
+ REG_R3 = 3,
+#define REG_R3 REG_R3
+ REG_R4 = 4,
+#define REG_R4 REG_R4
+ REG_R5 = 5,
+#define REG_R5 REG_R5
+ REG_R6 = 6,
+#define REG_R6 REG_R6
+ REG_R7 = 7,
+#define REG_R7 REG_R7
+ REG_R8 = 8,
+#define REG_R8 REG_R8
+ REG_R9 = 9,
+#define REG_R9 REG_R9
+ REG_R10 = 10,
+#define REG_R10 REG_R10
+ REG_R11 = 11,
+#define REG_R11 REG_R11
+ REG_R12 = 12,
+#define REG_R12 REG_R12
+ REG_R13 = 13,
+#define REG_R13 REG_R13
+ REG_R14 = 14,
+#define REG_R14 REG_R14
+ REG_R15 = 15
+#define REG_R15 REG_R15
};
+struct _libc_fpstate
+{
+ struct
+ {
+unsigned int sign1:1;
+unsigned int unused:15;
+unsigned int sign2:1;
+unsigned int exponent:14;
+unsigned int j:1;
+unsigned int mantissa1:31;
+unsigned int mantissa0:32;
+ } fpregs[8];
+ unsigned int fpsr:32;
+ unsigned int fpcr:32;
+ unsigned char ftype[8];
+ unsigned int init_flag;
+};
/* Structure to describe FPU registers. */
-typedef elf_fpregset_t fpregset_t;
+typedef struct _libc_fpstate fpregset_t;
/* Context to describe whole processor state. This only describes
the core registers; coprocessor registers get saved elsewhere
Re: struct user conflicts on arm
ISO C99 says that WCHAR_MAX must be a constant expression and the above definition is such an expression. Technically the program needs fixing (see below though for the standards matter but so do users), there is nothing wrong with a type cast and a constant value e.g. signed -1 converted to unsigned int (ARM GNU/Linux value for wchar_t). However, the real issue here is that it differs from x86, the most common architecture, and differences from x86 cause porting problems. The patch itself is insufficient because it doesn't take into account wordsize. When we switch to the 64-bit ARM ABI it should just work. Therefore you need to check for __WORDSIZE and *only* define a value if we are *not* 64-bits. You don't want to define anything for the 64-bit case until the 64-bit ARM ABI is out and finalized. Thanks for the info, I may look at this later. The ucontext namespace pollution seems to be a bigger issue though. Your patch to fix ucontext namespace pollution looks good, please post that to libc-ports for review should I send it immidiately or should I wait until I have test results to give them? and make sure to state what testing you've done with the patch. At a minimum you should run the glibc testsuite Afaict the debian packaging automatically runs the testsuite and compares it against a list of expected failures (ideally that list would be empty but in real life). Right now i'm running into unexpected testsuite failures (unfortunately the last test build I didn't take a log of so i've got to run it again to find out details of the failures) but I do not know if those failures are related to my patch, related to changes in the build environment since the package was last built in debian or related to my hardware. Further testing will be neeed to establish that (and said testing takes a while, a beagleboard xm isn't exactly a speed demon). and build gdb with those newly installed headers. Will do once I get glibc built and installed, are there any specific tests you want doing with gdb or is testing it still builds sufficient?? Cheers, Carlos. Thanks for the help and advice so-far. -- 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/4eed39e0.30...@p10link.net
Re: struct user conflicts on arm
Ulrich WeigandNow, glibc also provides a file sys/ucontext.h that defines Ulrich Weigandlayouts of register sets for use with signal handlers as well Ulrich Weigandas the makecontext/setcontext/getcontext family of routines. Ulrich Weigand Ulrich WeigandUsually, those layouts tend to be in fact identical to the Ulrich Weigandlayouts described in sys/user.h / sys/procfs.h. Apparently, Ulrich Weigandwhoever implemented the ARM version of sys/ucontext.h was Ulrich Weigandtrying to avoid some seemingly unnecessary code duplication Ulrich Weigandby making sys/ucontext.h *include* sys/procfs.h and using Ulrich Weigandthe information from there directly. This is not done on other Ulrich Weigandplatforms, for precisely the reason that the sys/procfs.h Ulrich Weigandand sys/user.h headers do pollute the name space ... Ulrich Weigand Ulrich WeigandSo I think the right thing to do in the short term would be to Ulrich Weigandstop sys/ucontext.h including sys/procfs.h, and instead add the Ulrich Weigandregister set information there directly, even if that means some Ulrich Weigandduplication of code. (Again, since this is never-changing ABI, Ulrich Weigandduplication isn't actually all that bad. Also, all the other Ulrich Weigandplatforms do it that way too, so why should ARM be different ...) Makes sense to me While we are talking about modifying sys/ucontext.h David Given raised another issue with that header (for those reading on the linaro list his post can be found at http://lists.debian.org/debian-arm/2011/12/msg00048.html) David GivenThis might be a good time to mention that on ARM, sys/ucontext.h defines David Givenboth symbols and preprocessor macros called R0, R1, R2, etc in the David Givenglobal namespace; this is causing one of my packages to fail to build David Givendue to symbol collision. David Given David GivenI'm fixing the package, but naming symbols stuff like that is still David Givenpretty antisocial... Does anyone know what the impact of renaming these to use a REG_ prefix like i386, amd64 and sparc do* would be? * ia64,mips, mipsel, powerpc, 390 and s390x don't seem to define such symbols at all. -- 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/4eec420f.8010...@postgrad.manchester.ac.uk
Re: struct user conflicts on armel and armfh
As a first step why don't you try breaking the header include chain in glibc, and rebuild gdb to ensure everything works? It looks like there are two places the chain could reasonablly be broken. sys/ucontext.h could stop including sys/procfs.h (this would match amd64) or signal.h could stop including sys/ucontext.h (this would match armel squeeze) I first tried breaking the chain by removing the include of sys/procfs.h from sys/ucontext.h (this would make arm* consistent with i386 and amd64) but it seems sys/ucontext.h on arm DOES use a couple of things from sys/procfs.h so breaking the chain at this point would require investigating those. Next I tried breaking the chain by commenting out the include of sys/ucontext.h in signal.h. This seemed more positive, a test program that included signal.h still built fine as did gdb. So that brings us back to why is signal/h including sys/ucontext.h by default in wheezy/sid when it didn't do so in squeeze. It seems the cause is the change of the following ifdef Squeeze: #ifdef __USE_XOPEN /* This will define `ucontext_t' and `mcontext_t'. */ # include sys/ucontext.h # endif Wheezy/Sid: # if defined __USE_XOPEN || defined __USE_XOPEN2K8 /* This will define `ucontext_t' and `mcontext_t'. */ # include sys/ucontext.h # endif seems to be defined by default From my tests it seems that in both squeeze and sid __USE_XOPEN2K8 gets defined by default (in ) but __USE_XOPEN does not. so this change to the ifdef changed it from default no to default yes Reverting the change the ifdef would solve the issue but before submitting a patch to actually do that I would like to know why the change was made in the first place. -- 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/4eea41f4.8010...@p10link.net
Re: struct user conflicts on armel and armfh
Carlos O'Donell wrote: As an upstream glibc maintainer I would be happy to see this fixed in glibc and gdb, but nobody has stepped up to fix it. Ok. The `struct user` is used by the gdbserver code that uses ptrace (PTRACE_PEEKUSR/POKEUSR) to peek/poke at the inferior and read out stored register values from the USER area. The userspace definition of `struct user` is equivalent to task_regs(child) layout and is an agreement between the kernel and userspace for debugging. There appears to be no good reason for it to be called `struct user` on Linux (on other OSs this is harder to control), it should have been named something that doesn't clash with the applications namespace e.g. struct __user. While renaming the structure would be one soloution to the conflicts changing a long standing* interface to solve a problem that is arch specific and has only recently become a significant issue** seems like a wrong approach to me. The real problem IMO is that headers that are supposed to be implementing special purpose interfaces for debugging are being pulled in by headers that are supposed to be implementing common public interfaces. * at least as far back as debian slink ** In squeeze armel signal.h would only include sys/ucontext.h if explicit defines were set. In wheezy and sid it seems to include it by default. Are you volunteering to change glibc and gdb, and work with upstream to get the changes merged? Depends on what exactly is involved in doing that and whether we can agree on how things should be fixed. As I said i'm not convinced that gdb needs to be changed. -- 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/4ee99eaf.80...@postgrad.manchester.ac.uk
struct user conflicts on armel and armfh
recently i've been seeing some packages FTBFS on armhf with definition clashes of struct user. Test building packages the package on armel has invariblly shown the issue happening there as well despite the same version of the source package having built there successfully in the past. I've also seen mention of this issue in bug reports from others. Afaict so far this issue has been dealt with on the appliation side but i'm not convinced that expecting application developers to rename a structure that uses a common and obvious name is reasonbable. taking ratbox-services as an example the current version was built successfully on armel 563 days ago, it failed on armhf 3 days ago. -DHELPDIR=\/usr/share/ratbox-services/help\ -DLANGDIR=\/usr/share/ratbox-services/langs\ -c c_error.c In file included from c_error.c:38:0: ../include/client.h:42:8: error: redefinition of 'struct user' /usr/include/arm-linux-gnueabihf/sys/user.h:49:8: note: originally defined here make[2]: *** [c_error.o] Error 1 I have reproduced this issue on armel sid and armel wheezy. The package builds succesfully on armel squeeze. Some testing reveals that in this case sys/user.h is pulled in by sys/procfs.h which in turn is pulled in by sys/ucontext.h which is pulled in by signal.h which is in turn pulled in by signal.h which is in turn pulled in by sys/wait.h which is pulled in by a header in the app. On amd64 (and presumablly other architectures) sys/ucontext.h does not include sys/procfs.h so the issue does not happen. I then took a look at the comments in the various headers along the chain. sys/procfs.h has the following comment /* This is somewhat modelled after the file of the same name on SVR4 systems. It provides a definition of the core file format for ELF used on Linux. It doesn't have anything to do with the /proc file system, even though Linux has one. Anyway, the whole purpose of this file is for GDB and GDB only. Don't read too much into it. Don't use it for anything other than GDB unless you know what you are doing. */ and sys/user.h has the following comment /* The whole purpose of this file is for GDB and GDB only. Don't read too much into it. Don't use it for anything other than GDB unless you know what you are doing. */ meanwhile sys/wait.h has the following comment /* *POSIX Standard: 3.2.1 Wait for Process Terminationsys/wait.h */ ,signal.h has the following comment /* *ISO C99 Standard: 7.14 Signal handling signal.h */ and sys/ucontext.h has the following comment /* System V/ARM ABI compliant context switching support. */ So now i've described the situation I have two questions why the heck are headers that are supposedly for GDB and GDB only and that define a structure name that is likely to conflict with structures in an application being pulled in by headers that are supposed to be implementing standard interfaces? Do porters and/or glibc maintainers think this should be dealt with on the libc6-dev side or should I continue to file patches that deal with this issue on the application side? -- 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/4ee7e6e3.8050...@postgrad.manchester.ac.uk
Re: Bug#551775: bitlbee: Uninstallable package due to conflict with libc6
oops forgot to actually cc it like I said I would Does anyone know if there is any particular reason that bitlbee uses libresolv.a rather than libresolv.so ? Yes; the fact that Ulrich Drepper thought it'd be a good idea to declare this API private and unsupported, claiming it's for internal use only, even though it's documented in various places already, including IIRC O'Reilly's DNS BIND. I can see that as a good reason for using the static version in upstream bitlbee. Nevertheless debian does appear to provide a libresolv.so with a proper soname and linking against it does seem to give sane dependencies from dpkg-shlibdeps so maybe it would be a good idea to use it in the debian packages. Ccing debian-glibc to see if they have an opinion on the matter. Does anyone know if statically linking libresolv and dynamically linking glibc then upgrading glibc is supposed to be supported? It's never been a problem so far, and the previous BitlBee package went through several libc6 revisions. TBH I'm more than willing to figure out some way to drop this strict dependency while continuing to use libresolv.a. If someone ever decides to change the res API I can always do a reupload that temporarily disables SRV record lookups, for example. Is there an easy way to do that? I see the -x flag to dpkg-shlibdeps, but that would completely eliminate the libc6 dependencies, and that's not really what I want, of course. You could always sed it out of debian/substvars between the call to dpkg-shlibdeps and dpkg-gencontrol but it's a bit ugly to say the least. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#454266: upgrade to 2.7 fails, leaving system unusable
+++-==-==- un libc6-i686 none (no description available) The file comes from libc6-i686 version 2.6.1-1. According to the symlink it has been installed on 2007-08-21 (ie the date it migrates to testing). After a bit of thinking I have come up with what I belive is a likely explanation for this incident and other similar ones that have happened in the past. Installation on that particular day would seem to indicate it was installed as part of an update. un in a dpkg -l generally means there is no entry for the package in /var/lib/dpkg/status. If the package was removed it would be rc and if purged it would be pn This would seem to indicate that libc6-i686 was previously installed and being updated normally but at some point during or after the update to 2.6.1-1 it's entry in the dpkg status file completely dissapeared. IIRC some filesystems that journal data but not metadata can zero out blocks of a file. I did a quick test of this idea by doing dd if=/dev/zero of=/var/lib/dpkg/status bs=4096 count=1 seek=1 and then running apt-get -f install. I tried the same with other seeks too. The bottom line is zeroing out the first block of that file causes dpkg to fail but zeroing out other blocks will often cause dpkg to simply forget that some packages are installed (and probablly get some wrong info about whatever packages happen to fall on the block edges). The user will be told to run apt-get -f install and upon doing so it will appear thier system is fixed but packages like libc6-i686 which have little if anything depending on them will be left extracted on the system with no record in the dpkg database. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453264: libc6-dev: fails to define ptrdiff_t in malloc.h
It's not that easy in the swi-prolog case. The two headers are included in two separate headers, which are then included into the .c file. The order cannot be switched around, because the former header includes config.h, which is needed for the second header to work at all (IIRC). Can't you just include malloc.h directly from the C file before including the header that indirectly includes wchar.h ? Generally standard headers are designed so that once you have included them once including them again does nothing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421037: libc6 upgrade apparently failing on some netwinders
nearly a week ago a bug was filed against libc6 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421037) reporting a sigill when upgrading on a netwinder. Replies to the bug report say that on some netwinders it does work. there is still no information in the bug report log on what the illegal instruction was and very little information on the characteristics (model number, kernel version etc) of the netwinders that suffer from the issue. can any arm porters shed any light on this issue?
Bug#419189: i'd suggest a check
it seems like it would be a good idea to check for non dpkg owned versions of problem libraries sitting in that directory in the preinst and either aborting the upgrade before the system is left in a badly broken state or moving the files out of the way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
