Package: libc6-dev
Version: 2.3.2.ds1-20
Hi,
libnss-pgsql uses with _LIBC and NOT_IN_libc
defined to use __libc_lock_*.
On amd64 this is failing because it does this:
#ifdef _LIBC
# include
# include
# include
#endif
None of those seem to exist on amd64, probably because we do not
have tls
reassign 298247 libnss-pgsql
retitle 298247 libnss-pgsql: Uses non-exported libc interface.
thanks
On Sun, Mar 06, 2005 at 11:00:46AM -0500, Daniel Jacobowitz wrote:
> On Sun, Mar 06, 2005 at 02:01:12AM +0100, Kurt Roeckx wrote:
> > Package: libc6-dev
> > Version: 2.3.2.ds1
Hi,
When building debian-installer, I'm also getting the following
error:
Command failed with status 1 : gcc -nostdlib -nostartfiles -shared
-Wl,-soname=libc.so.6 -uwctomb -ufclose -ufreopen64 -ugetmntent -usleep
-uwcsncasecmp -ustrptime -umktime -u__fxstat -ugetline -ulocaltime -uiopl
-ugetppi
reassign 317946 libc6
severity 317946 serious
merge 317946 318956
thanks
Merging those bugs, since they all obviously are the same.
I'm setting it to serious since the other 2 merge ones are set to
serious too.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscrib
severity 313404 serious
merge 313404 315793
thanks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
severity 317674 serious
merge 317674 317946
thanks
Yet an other one it seems.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.3.2.ds1-22
Hi,
It seems that on amd64, all binaries and libraries in the libc6
pacakge have a wrong dynamic linker in the binaries.
ldd /lib/libc.so.6
/lib/ld-linux-x86-64.so.2 (0x002a95556000)
ldd /usr/bin/iconv
libc.so.6 => /lib/libc.so.6 (0x00
Hi,
I'm seeing a simular problem when building openct on amd64 that
is caused by including usbdevice_fs.h.
A buildd log is available at:
http://amd64.ftbfs.de/fetch.php?&pkg=openct&ver=0.6.5-2&arch=amd64&stamp=1126228644&file=log&as=raw
The first problem here is that div64.h uses BIT_PER_LONG, wh
Package: tzdata
Hi,
I've read today that upstream has taken down the source because
of a law suite against them. From what I understand they have
based some of their historic information on the ACS American
Atlas. Upstream believes that all information is in the public
domain.
Kurt
--
To
On Fri, Oct 07, 2011 at 09:22:17PM +0200, Julien Cristau wrote:
> On Fri, Oct 7, 2011 at 21:17:35 +0200, Kurt Roeckx wrote:
>
> > Package: tzdata
> >
> > Hi,
> >
> > I've read today that upstream has taken down the source because
> > of a law s
On Sun, Apr 06, 2008 at 05:43:06PM +0200, Elmar Hoffmann wrote:
> Hi Kurt,
>
> on Tue, Jul 31, 2007 at 01:34:43 +0200, you wrote:
>
> > tags 343140 + ipv6
>
> Havig read the bug report, I do think that this was in error. This bug
> is not about lacking/non-working IPv6 support.
You're right, an
On Sun, Jul 06, 2008 at 03:09:09PM -0700, Steve Langasek wrote:
> Hi folks,
>
> I've run across an ipv4/ipv6 configuration issue which I think needs to have
> light cast on it so we can try to resolve this in time for lenny (whatever
> the right resolution actually is), in order to avoid a pile-up
On Sun, Jul 06, 2008 at 05:14:44PM -0700, Steve Langasek wrote:
> On Mon, Jul 07, 2008 at 01:39:37AM +0200, Kurt Roeckx wrote:
>
> > You don't seem to request ipv4 addresses, you request AF_UNSPEC, which
> > should get you both ipv4 and ipv6. You get 127.0.0.1 twic
retitle 746516 glibc: Enable -fasynchronous-unwind-tables on more arches.
thanks
> It seems that not all arches have -fasynchronous-unwind-tables
> enabled. I see it enabled on amd64, i386, s390x, but disabled
> on armel/armhf, powerpc.
>
> Could this enable this on more architectures?
>
> I'm
Package: libc6-dev,linux-libc-dev
Severity: important
Hi,
When building dv4l I get the following error:
In file included from /usr/include/sys/time.h:31,
from /usr/include/linux/videodev2.h:59,
from /usr/include/linux/videodev.h:17,
from palettes
Package: libc6
Version: 2.9-12
Hi,
It seems that libc6 doesn't try the other nameserver anymore when
the first returns "5(REFUSED)". If a nameserver returns REFUSED,
it's not the same as a permanent error.
Atleast apt-get in stable and testing/unstable react different
to this.
Kurt
--
To
On Fri, Jul 03, 2009 at 02:50:54AM +0200, Aurelien Jarno wrote:
> On Thu, Jul 02, 2009 at 08:15:29PM +0200, Kurt Roeckx wrote:
> > Package: libc6
> > Version: 2.9-12
> >
> > Hi,
> >
> > It seems that libc6 doesn't try the other nameserver anymore wh
On Mon, Aug 10, 2009 at 08:23:12PM +0200, Kurt Roeckx wrote:
> Source: libc6.1-dev
> Version: 2.9-23
> Severity: important
>
> Hi,
>
> While building audit on alpha, I get the following error:
> > gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../auparse -fPIC -DPIC
&
Source: eglibc
Version: 2.10.2-2
Severity: wishlist
Hi,
Could you please provide support for NTP API 4?
The changes in version 4 is the addition of MOD_TAI (ADJ_TAI)
and a tai member in the ntptimeval struct.
The kernel already supports this since 2.6.26 when ADJ_TAI
got added. The current /us
> Changing the struct ntptimeval means changing the ABI. This has been
> done upstream using symbol versioning, using GLIBC_2.12. I am currently
> not sure we can already use this version without breaking the binary
> compatibility with other distributions.
We're only waiting for this since 2000.
Package: libc6-dev
Version: 2.10.2-2
Hi,
As already requested in #558314, I would like to see the
following defines in timex.h:
#define MOD_NANOADJ_NANO
#define MOD_MICRO ADJ_MICRO
I don't want anything for TAI support yet, so don't define
NTP_API of MOD_TAI yet, they're not useful
Package: libc6
Version: 2.10.2-6
Severity: important
Hi,
It seems that getaddrinfo() now returns EAI_NONAME for a non-permanent
error. Trying to resolve something using "host" or "dig", I get
as error:
";; connection timed out; no servers could be reached"
That is clearly different that an error
On Fri, Jul 01, 2011 at 07:44:01PM +0200, Kurt Roeckx wrote:
>
> Anyway, I think ld.so does what it's supposed to do in case
> everything was multiarch, the files would need to be moved
> there in that case. But I think it's wrong to only try
> the multiarch location.
On Sat, Jul 13, 2013 at 04:15:44PM -0700, Jonathan Nieder wrote:
> Hi Kurt,
>
> In November, 2012, you wrote (re elfutils's plugin path):
>
> > unarchive 632281
> > reopen 632281
> > #It doesnt do the right thing in case of non-multi arch now
>
> How should $LIB be set to support this? I'm wo
Source: glibc
Version: 2.25-2
Hi,
On kfreebsd-* and hurd I'm getting a linker failure that mremap()
doesn't exist. It exists in sys/mman.h.
Kurt
reassign 403658 purelibc
retitle 403658 purelibc: FTBFS: Makes use of glibc internal _IO_MTSAFE_IO.
thanks
> Theoretically you should not define _IO_MTSAFE_IO it is reserved for
> glibc internals. That's why you get an error there, when using a NPTL libc.
So, I've reassign it to purelibc, because
So on amd64, with 2.3.2.ds1-22sarge4 I get:
intrepid:~$ zdump -v /usr/share/zoneinfo/UTC
/etc/localtime -9223372036854775808 = NULL
/etc/localtime -9223372036854689408 = NULL
/etc/localtime 9223372036854689407 = NULL
/etc/localtime 9223372036854775807 = NULL
intrepid:~$ zdump --version
@(#)zdum
> From: Aurelien Jarno <[EMAIL PROTECTED]>
> On Tue, Jul 24, 2007 at 09:00:12AM +0200, Matthias Klose wrote:
> > severity 433391 grave
> > clone 433391 -1
> > reassign -1 glibc
> > block 433391 by -1
> > thanks
> >
> > Building gcj or gcc-snapshot on a system downgraded to glibc-2.5
> > doesn't sh
Package: glibc
Version: 2.6.1-1
Severity: important
Hi,
It seems that getaddrinfo() seems to sort the results, which defeats the
point of having multiple A-records in the first place.
If I look up 0.pool.ntp.org I (now) get:
0.pool.ntp.org has address 193.39.78.2
0.pool.ntp.org has address 195.
reopen 438179
thanks
On Thu, Aug 16, 2007 at 08:24:51PM +0200, Aurelien Jarno wrote:
>
> This is a feature, not a bug. getaddrinfo() sorts results according to
> RFC3484. You can configure the way they are sorted using /etc/gai.conf.
None of the rules in rfc3484 say anything about this. In fact
On Thu, Aug 16, 2007 at 10:03:14PM +0200, Aurelien Jarno wrote:
> Kurt Roeckx a écrit :
> > reopen 438179
> > thanks
> >
> > On Thu, Aug 16, 2007 at 08:24:51PM +0200, Aurelien Jarno wrote:
> >> This is a feature, not a bug. getaddrinfo() sorts results accordin
On Thu, Aug 16, 2007 at 10:42:20PM +0200, Aurelien Jarno wrote:
> >>Rule 9: Use longest matching prefix.
> >>When DA and DB belong to the same address family (both are IPv6 or
> >>both are IPv4): If CommonPrefixLen(DA, Source(DA)) >
> >>CommonPrefixLen(DB, Source(DB)), then prefer
> The reason we have that sorting is to get consistency.
> I won't add such an option to disturb it. Not to sort is completely,
> utterly wrong since the order in which addresses are returned from the
> service are more or less random.
The random order is exactly the point in the first! Namese
Hi,
I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
should sort the results or not. I think the current way it sorts things
does not work at all in IPv4, and I think it hurts more than it does
good.
I'm seeking input from the tech-ctte on how to handle this.
Kurt
si
On Fri, Sep 07, 2007 at 12:34:10AM +0200, Pierre Habouzit wrote:
> the Ctte may want to read:
> - http://udrepper.livejournal.com/16116.html
> - http://people.redhat.com/drepper/linux-rfc3484.html
The first one makes a point to which I party agree, but also disagree.
It's atleast in the spi
On Fri, Sep 07, 2007 at 06:54:21PM +1000, Anthony Towns wrote:
> OTOH, getaddrinfo is meant to give a "close" answer, and doing prefix
> matching on NATed addresses isn't the Right Thing. For IPv6, that's fine
> because it's handled by earlier scoping rules. For NATed IPv4 though the
> prefix we sh
On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
> >
> > Heedless of the effect on the DNS round-robin functionality I describe
> > above, the authors of RFC3484 specified (s6 rule 9) that all addresses
> > should be sorted by "proximity" to the host making the choice - where
> > "pr
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
> I've attached a small test program. The results are:
> sarge: libc6 2.3.2.ds1-22sarge5: random order
> etch: libc6 2.3.6.ds1-13etch2: ordered results
Maybe I should attach it.
Kurt
#include
#include
#include
#inc
On Fri, Sep 28, 2007 at 06:23:06PM +, Pierre Habouzit wrote:
> DNS RR is "broken" on Windows XP since SP2, Windows Vista, most *BSDs,
> Redhat and Fedora, and probably any Linux distribution out there
I've just tested XP SP2 myself in various ways. I've tried things
like internet explorer,
On Sat, Sep 29, 2007 at 11:56:35AM +0200, Wolf Wiegand wrote:
> Hi,
>
> Kurt Roeckx wrote:
>
> > I haven't seen anybody claim that any of the *BSDs implemented rule 9
> > that also says he tested it, I've only seen reported of FreeBSD saying
> > it didn&#x
Package: libc6-dev, linux-libc-dev
Severity: important
Hi,
When building proftpd-dfsg on amd64 I get the following error:
In file included from /usr/include/asm/types.h:5,
from /usr/include/asm-x86_64/sigcontext.h:4,
from /usr/include/asm/sigcontext.h:5,
On Sun, Oct 07, 2007 at 12:09:51PM +0200, Bastian Blank wrote:
> On Sun, Oct 07, 2007 at 11:38:18AM +0200, Kurt Roeckx wrote:
> > When building proftpd-dfsg on amd64 I get the following error:
> > In file included from /usr/include/asm/types.h:5,
> > from /u
I always have to go and search what the option is to show the current
charmap. It's documented in nl_langinfo(3), but it would be nice that
it was documented in either the locale manpage, or that the locale tool
could show it itself.
By guessing from the same manpage I could atleast find those
ad
Package: glibc
Version: 2.3.5-8
Severity: important
Tags: patch
Hi,
glibc is failing to build on amd64 with the following error:
gcc ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S -c -I../include -I.
-I/build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl -I.. -I../libio
-I/build/buildd/
I'm planning on doing an NMU for this tommorrow. We currently
don't have a libc6 in testing because of this.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Nov 27, 2005 at 12:06:15AM -0500, Daniel Jacobowitz wrote:
> On Sat, Nov 26, 2005 at 04:35:45PM +0100, Kurt Roeckx wrote:
> > I'm planning on doing an NMU for this tommorrow. We currently
> > don't have a libc6 in testing because of this.
>
> I assume you
-amd64 libc6-prof libc6
libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb
libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-8.1
Distribution: unstable
Urgency: low
Maintainer: GNU Libc Maintainers
Changed-By: Kurt Roeckx <[EMAIL PROTEC
Hi,
I'm now also seeing this error message in the latest version of
qemu (0.8.0-1)
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
Could someone please give an update of the status of this
request? It seems to be open for a long time, and it would be
nice to get rid of ia32-libs.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Feb 20, 2006 at 11:10:41AM -0700, Bdale Garbee wrote:
> On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote:
> > If there's
> > consensus that putting this stuff in /usr/lib32 on amd64 is prettier than
> > /emul/ia32-linux, I see no reason not to move forward.
>
> My sense is that the
On Wed, Feb 22, 2006 at 02:45:20PM +0100, Andreas Jochens wrote:
>
> To fix this, I suggest to add the missing symlink /usr/lib64 -> /usr/lib
> to the 'libc6-udeb' package in debian/sysdeps/amd64.mk in a similar
> way as it is done for the 'libc6' package.
The /lib64 -> lib symlink on d-i is crea
On Sat, Mar 04, 2006 at 02:23:25PM +0100, Cyril Chaboisseau wrote:
> I just built qemu 0.8.0-2 from source but with just a slight change from
> usbdevice_fs.h as described here
> http://lkml.org/lkml/2005/9/3/60
>
> without this change qemu couldn't build but as the author of the patch
> (Harald W
Package: debhelper
Severity: wishlist
Hi,
Some libraries want to restart a list of services when the
library gets upgraded. I currently know of only 2 such libraries
that have code for it: libc6 and libssl0.9.8.
They both have a simular postinst script, but they also have
differences.
For inst
On Fri, Mar 10, 2006 at 02:02:04PM +0100, Daniel Schepler wrote:
> After some investigation of the failure of kdelibs to build, I found it
> appears to be a bug in either libtool, ld, or the dynamic linker, so I'm
> CC'ing the maintainers of those packages. The problem is that lt-meinproc is
>
Package: glibc
Version: 2.3.999-1
Severity: important
Hi,
Your package failed to build on amd64. The amd64 version seems
to have build without problem, but then when it tried to build
the i386 version, it failed with the following error:
running configure fragment for sysdeps/i386/elf
checking
Package: glibc
Version: 2.3.999-1
Severity: serious
Tags: experimental
Hi,
Your package is failing to build on amd64 with a segmentation
fault. From the buildd log:
GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C
LOCPATH=/build/buildd/glibc-2.3.999/build-tree/amd
Package: libc6
Version: 2.3.6-15
Severity: important
Hi,
It seems that iconv() return -1 and sets errno to EILSEQ on valid
input that it can't convert to the output encoding. It shouldn't be
doing that, since it is valid input.
This can be simple showed using the iconv util, since it reacts
the
Hi,
The problem is that the .TH is missing then the '.'. Line 104
looks like:
TH ICONV 1 "etch" "20/Jun/2004" "Debian GNU/Linux"
And should be:
.TH ICONV 1 "etch" "20/Jun/2004" "Debian GNU/Linux"
After that change it looks normal again.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
Package: libc6-dev
Version: 2.3.6.ds1-9
Severity: important
Hi,
While trying to build purelibc on amd64 I get the following error:
In file included from /usr/include/libio.h:171,
from /usr/include/stdio.h:72,
from stdio.c:25:
/usr/include/bits/stdio-lock.h:24:26:
On Fri, Apr 16, 2004 at 12:54:03PM +1000, Herbert Xu wrote:
>
> On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
> >
> > On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
> >
> > > Accordingly, I believe that the pattern in your example means
> > > "backslash, followed by a, f
On Sat, Apr 17, 2004 at 07:58:21AM +1000, Herbert Xu wrote:
> On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote:
> >
> > After reading all that you have to get confused about what "[\[\]\\]" means.
> > At the "highest level" it says that the &#x
On Sat, Apr 17, 2004 at 12:14:39PM -0700, Ben Pfaff wrote:
> Herbert Xu <[EMAIL PROTECTED]> writes:
>
> >> Accordingly, I believe that the pattern in your example means
> >> "backslash, followed by a, followed by closing square bracket", not what
> >> you think it means.
> >
> > You're quite right
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Here is a small patch that fixes warning/errors about usage of
long long for amd64.
Kurt
--- include/asm-x86_64/types.h.orig 2004-04-22 23:16:11.294209120 +0200
+++ include/asm-x86_64/types.h 2004-04-22 23:16:02.109605392 +0200
@@
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
u64 type. That type is __KERNEL__ only.
I think the whole file should be probably be #ifdef'd to
__KERNEL__ but I'm not sure.
This problem causes a build failure for sysklog
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
/usr/include/asm/mpspec.h (i386, line 6) does:
#include
Which does not exist.
What does however exist are the following files:
/usr/include/asm/mach-bigsmp/mach_mpspec.h
/usr/include/asm/mach-default/mach_mpspec.h
/usr/include/asm/mach-e
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/bitmap.h it's using BITS_PER_LONG all over
the place but BITS_PER_LONG is __KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/cpumask.h it's using BITS_TO_LONGS which is
__KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
On Sun, Apr 25, 2004 at 10:40:37PM +0900, GOTO Masanori wrote:
> At Sun, 25 Apr 2004 14:25:49 +0200,
> Kurt Roeckx wrote:
> > In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
> > u64 type. That type is __KERNEL__ only.
> >
> > I think the whole file
On Sun, Apr 25, 2004 at 11:21:53PM +0900, GOTO Masanori wrote:
>
> Which version did you build sysklogd ?
I'm using 1.4.1-10, which is the latest in testing.
Trying the same with 1.4.1-14 fixes all my problems.
Sorry for all those bugreports about sysklogd.
Kurt
On Mon, May 03, 2004 at 05:13:28PM +0200, Goswin von Brederlow wrote:
> Hi,
>
> I'm forwarding this to debian-amd64 since I'm not working on debians
> amd64 anymore since the DAM rejected me.
I can't reproduce this on a system with libc6 2.3.2.ds1-11,
coreutils 5.0.91-2 and a 2.6.5 kernel. Neith
Package: libc6
Version: 2.3.2.ds1-12
It seems that pthread_condattr_setpshared and
pthread_mutexattr_setpshared both return 38 (ENOSYS) when called
on amd64.
Example code:
pthread_condattr_t condattr;
printf("%d\n", pthread_condattr_init(&condattr));
printf("%d\n", pthrea
On Sun, May 09, 2004 at 04:27:23PM -0400, Daniel Jacobowitz wrote:
>
> Details about the kernel and environment on both test systems?
It's both times on the same machine with the same kernel. It's
an x86_64 2.6.5 kernel.
The i386 part is a chroot with sarge i386 on it, amd64 is a
pure64 amd64 c
On Sun, May 09, 2004 at 05:47:00PM -0400, Daniel Jacobowitz wrote:
>
> If the tools support it, and it works, someone should provide a patch
> to the debian/sysdeps/ file to enable it. The x86_64 configuration
> isn't even in debian-glibc CVS as far as I know, take it up with the
> porters.
Putt
Package: libc6
Version: 2.3.2.ds1-11
When trying to build glibc on amd64 it seems to compile fine, it
even already created glibc-doc_2.3.2.ds1-11_all.deb and
locales_2.3.2.ds1-11_all.deb but then fails with like this:
dpkg-deb: building package `locales' in
`../locales_2.3.2.ds1-11_all.deb'.
touc
Package: libc6
Version: 2.3.2.ds1-11
It seems the weak symbols for res_* are missing on amd64.
in resolv/res_data.c there is:
#if SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)
weak_alias (__res_query, res_query);
It seems the "SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)"
returns false for some
On Sun, Apr 04, 2004 at 06:22:57PM -0400, Daniel Jacobowitz wrote:
> On Sun, Apr 04, 2004 at 11:50:15PM +0200, Kurt Roeckx wrote:
> > Package: libc6
> > Version: 2.3.2.ds1-11
> >
> > It seems the weak symbols for res_* are missing on amd64.
> >
> >
On Sun, Apr 04, 2004 at 07:26:18PM -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 05, 2004 at 12:32:29AM +0200, Kurt Roeckx wrote:
> >
> > It's a problem because configure doesn't find it anymore. It
> > doesn't include resolv.h so it doesn't know that it
On Fri, Apr 16, 2004 at 12:54:03PM +1000, Herbert Xu wrote:
>
> On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
> >
> > On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
> >
> > > Accordingly, I believe that the pattern in your example means
> > > "backslash, followed by a, f
On Sat, Apr 17, 2004 at 07:58:21AM +1000, Herbert Xu wrote:
> On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote:
> >
> > After reading all that you have to get confused about what "[\[\]\\]" means.
> > At the "highest level" it says that the &#x
On Sat, Apr 17, 2004 at 12:14:39PM -0700, Ben Pfaff wrote:
> Herbert Xu <[EMAIL PROTECTED]> writes:
>
> >> Accordingly, I believe that the pattern in your example means
> >> "backslash, followed by a, followed by closing square bracket", not what
> >> you think it means.
> >
> > You're quite right
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Here is a small patch that fixes warning/errors about usage of
long long for amd64.
Kurt
--- include/asm-x86_64/types.h.orig 2004-04-22 23:16:11.294209120 +0200
+++ include/asm-x86_64/types.h 2004-04-22 23:16:02.109605392 +0200
@@
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
u64 type. That type is __KERNEL__ only.
I think the whole file should be probably be #ifdef'd to
__KERNEL__ but I'm not sure.
This problem causes a build failure for sysklog
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
/usr/include/asm/mpspec.h (i386, line 6) does:
#include
Which does not exist.
What does however exist are the following files:
/usr/include/asm/mach-bigsmp/mach_mpspec.h
/usr/include/asm/mach-default/mach_mpspec.h
/usr/include/asm/mach-e
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/bitmap.h it's using BITS_PER_LONG all over
the place but BITS_PER_LONG is __KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
--
To UNSUBSCRIBE, email
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/cpumask.h it's using BITS_TO_LONGS which is
__KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
On Sun, Apr 25, 2004 at 10:40:37PM +0900, GOTO Masanori wrote:
> At Sun, 25 Apr 2004 14:25:49 +0200,
> Kurt Roeckx wrote:
> > In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
> > u64 type. That type is __KERNEL__ only.
> >
> > I think the whole file
On Sun, Apr 25, 2004 at 11:21:53PM +0900, GOTO Masanori wrote:
>
> Which version did you build sysklogd ?
I'm using 1.4.1-10, which is the latest in testing.
Trying the same with 1.4.1-14 fixes all my problems.
Sorry for all those bugreports about sysklogd.
Kurt
--
To UNSUBSCRIBE, email t
On Sun, May 09, 2004 at 05:47:00PM -0400, Daniel Jacobowitz wrote:
>
> If the tools support it, and it works, someone should provide a patch
> to the debian/sysdeps/ file to enable it. The x86_64 configuration
> isn't even in debian-glibc CVS as far as I know, take it up with the
> porters.
Putt
On Mon, May 03, 2004 at 05:13:28PM +0200, Goswin von Brederlow wrote:
> Hi,
>
> I'm forwarding this to debian-amd64 since I'm not working on debians
> amd64 anymore since the DAM rejected me.
I can't reproduce this on a system with libc6 2.3.2.ds1-11,
coreutils 5.0.91-2 and a 2.6.5 kernel. Neith
On Sat, Oct 23, 2004 at 09:52:11PM +0200, Andreas Jochens wrote:
>
> +--- ldconfig.h 2002-04-22 11:51:40.0 +
> glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldconfig.h2004-10-07
> 14:47:52.649686928 +
> +@@ -20,7 +20,7 @@
> +
> + #define SYSDEP_KNOWN_INTERPRETER_NAMES
On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote:
>
> This patch is harmless with respect to any LSB requirement.
> The name of the dynamic loader, which is coded into every binary
> can only be changed in the gcc package. This patch does not change
> that.
I don't know what you a
On Sun, Oct 31, 2004 at 10:35:02AM +0100, Thomas Koenig wrote:
> int mycomp(void const *p1, void const *p2) {
> mydata const *v1, *v2;
> v1 = p1;
> v2 = p2;
> return (v1->key) < (v2->key);
> }
Change that return to return (v1->key) - (v2->key) and it will
work as expected.
Kurt
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,
> c
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
> > > sy
94 matches
Mail list logo
