Package: locales
Version: 2.1.3-2
When upgrading libc6, locales needs to overwrite a file in the
previous version of libc6, used --force-overwrite to do it.
This should be the default, as locales must be installed before
libc6.
Rob.
reassign 57979 2utf
thanks
>After installing locales_2.1.3-2 from potato, the 2utf package stops
>working:
>
>2UTF: aliases database needs update.
>can't find such alias: ``latin1''
> /usr/local/share/i18n/charmaps/*latin1*
> /usr/share/i18n/charmaps/*latin1*
> /usr/share/i18n/charmap/*latin1*
>2U
Package: libc6-dev
Version: 2.1.3-2
Severity: wishlist
Hi, just lurking around, I noticed :
$ dpkg -L libc6-dev | grep '\.a$' | xargs file
/usr/lib/libBrokenLocale.a: current ar archive
/usr/lib/libbsd-compat.a: current ar archive
/usr/lib/libc.a:current ar archive
/usr/lib/libc_non
Installing:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libnss1-compat_2.1.3-4_i386.deb
to di
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
libc6-dev_2.1.3-4_i386.deb
to dists/potato/main/binary-i386/devel/libc6-dev_2.1.3-4.deb
replacing libc6-dev_2.1.3-2.deb
libc6-dev_2.1.3-4_i386.deb
to dists/woody/m
Package: libc6
Version: 2.1.3-2
Debian: 2.2
Kernel: 2.2.14
About a week ago I experienced some problems when trying to upgrade my
system using apt-get update & apt-get -f upgrade. See output below:
-
[EMAIL PROTECTED] /root# apt-get -f upgrade
Reading Package Lists... Done
Building Dependency
Your message dated 21 Feb 2000 10:04:53 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57031: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:53 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57456: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:53 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57482: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:53 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57580: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:54 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57584: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:54 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57698: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:54 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57797: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:55 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57885: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:55 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#57922: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
Your message dated 21 Feb 2000 10:04:55 -
with message-id <[EMAIL PROTECTED]>
and subject line Bug#58385: fixed in glibc 2.1.3-4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respo
On Friday 18 February 2000, at 0 h 50, the keyboard of Seth R Arnold
<[EMAIL PROTECTED]> wrote:
> A friend of mine can't get his potato machine upgraded to woody as a result
> of this --- he has been trying to run apt-get upgrade every day for the last
> two weeks, with no positive effects.
A wo
Package: glibc
Version: 2.1.3-2
Can't build source. The source build fails claiming the kernel headers are
too old, displaying the following:
checking for gcc -fexceptions... yes
checking for DWARF2 unwind info support... static
checking for __builtin_expect... no
running configure fragment for
Hi,
After staring at the exception handling code in the C runtime
environment a bit harder I have decided that, until the issues of the
DWARF2 frame info format can be resolved in gcc (which they will have
to be eventually - think IA-64), the only way to deal with this
problem is simply to have ld
On 21 Feb 2000, David Huggins-Daines wrote:
> After staring at the exception handling code in the C runtime
> environment a bit harder I have decided that, until the issues of the
> DWARF2 frame info format can be resolved in gcc (which they will have
> to be eventually - think IA-64), the only w
"Christopher C. Chimelis" <[EMAIL PROTECTED]> writes:
> On 21 Feb 2000, David Huggins-Daines wrote:
> Great work! BTW, the offending code is also in binutils' source and is
> quite a bit more explicit (see gas/ehopt.c). I need to look at the DWARF2
> spec, but I don't see why it would require su
On 21 Feb 2000, David Huggins-Daines wrote:
> 3) C++ runtime support that reads the frame info in exception handlers
>(gcc/frame.o)
Won't this also generate unaligned faults when they access the
information? Has anyone tested an actual exception throw to see how many
faults crop up?
Jason
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 21 Feb 2000, David Huggins-Daines wrote:
>
> > 3) C++ runtime support that reads the frame info in exception handlers
> >(gcc/frame.o)
>
> Won't this also generate unaligned faults when they access the
> information? Has anyone tested an actua
On 21 Feb 2000, David Huggins-Daines wrote:
> No - read the code in gcc/frame.c - it already *expects* this
> information to be unaligned (in fact that's where I took the code to
> read unaligned quadwords from :). This is why I suspect that the
> ld.so workaround is the only way to fix this - g
33 matches
Mail list logo
