Package: locales
Version: 2.24-3
Severity: normal
File: /usr/sbin/locale-gen
Tags: security
While stracing localedef, I noticed this behavior:
open("i18n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/i18n/locales/i18n", O_RDONLY) = 4
There's no chdir;
By comparing stack traces under ld-linux.so and not, I was able to determine
that the NULL is coming from global->errors, which is supposed to get
initialized to STDERR but somehow isn't when ld-linux.so runs curl.
While playing with that, I noticed that trying to printf the address of global
Joey Hess wrote:
> Even fdopen(1, 'w') crashes the same way.
Er, ignore that, it's obviously wrong.
But, stdout stderr etc are indeed looking very wrong..
joey@kite:~/tmp/curl-7.44.0/debian/build>cat src/tool_main.c
#include
#include
int main(int argc, char *argv[])
{
fprintf(
Fully minimal test case is in the attached shell script.
This bug only occurs if the binary is linked with -pie.
--
see shy jo
testcase.sh
Description: Bourne shell script
signature.asc
Description: Digital signature
Joey Hess wrote:
> Tried building curl from source to get a useful backtrace, but that
> build didn't have the problem.
>
> Since that build was done using gcc 4.9.2-4, it may be another hint in
> the direction of the recent gcc transitions.
Indeed, I built curl with gcc 5.2
Aurelien Jarno wrote:
The fp pointer is NULL in both of the above functions. Could you please
try to get a backtrace to see which caller starts to pass a NULL
pointer?
Tried building curl from source to get a useful backtrace, but that
build didn't have the problem.
Since that build was done
Colin Watson wrote:
Here's LD_DEBUG=all output, which suggests it might relate to NSS.
22014: symbol=fclose; lookup in file=/lib/x86_64-linux-gnu/libc.so.6
[0]
22014: binding file /lib/x86_64-linux-gnu/libnss_compat.so.2 [0] to
/lib/x86_64-linux-gnu/libc.so.6 [0]: normal
Package: libc6
Version: 2.17-7
Severity: important
On a system with kernel 2.6.32 (forced by a hosting provider) and this
libc6, any calls to eventfd() fail. This causes at least all nontrivial
haskell programs to fail to run, since ghc uses eventfd in its
runtime system when performing IO.
Here
Marc F. Clemente wrote:
Then there is the question of America/Detroit. I travel to the East
Coast of the US. Do I pick America/Detroit or America/New_York?
What's the difference and how would I know? Should I pick
America/Detroit only when I am in Detroit, or when I am in Michigan,
or on
Package: tzdata
Version: 2010m-1
Severity: normal
On this system, /usr/share/zoneinfo/JEST exists, and /etc/timezone
uses it and works fine, but it breaks upgrades of tzdata.
r...@gnu:/usr/share/zoneinfoDEBCONF_DEBUG=developer
/var/lib/dpkg/info/tzdata.config
debconf (developer): frontend
Package: libc6
Version: 2.10.2-6
Severity: normal
r...@gnu:/home/joey/var/lib/dpkg/info/libc6.postinst configure 2.09
Checking for services that may need to be restarted...
Checking init scripts...
atd is running.
[: 92: missing ]
Checking periodic command scheduler...failed (failed to start).
[:
Package: libc6
Version: 2.10.2-6
Severity: normal
Tags: d-i
Symptom A:
libc6 will often be upgraded in the latter half of a d-i installation,
when an old version is installed from CD or a mirror, and a newer
version is available on a mirror, or on security.debian.org. During this
upgrade, the
Package: locales
Version: 2.9-12
Severity: normal
Tags: d-i
I have at least two systems where /etc/locale.gen contains two copies of the
en_US.UTF-8 line. On both, one copy is present in alphabetical order with the
rest, and the other copy is near the end of the file. Reconfiguring locales
does
http://sourceware.org/bugzilla/show_bug.cgi?id=4980
--
see shy jo, Amazed to be able to both mindlessly forward links
from reddit and possibly contribute value this this
thread at the same time. Not amazed at Drepper's behavior,
particualarly.
signature.asc
I'd be happy to help test a version of libc6 that uses symbol files on
armel. It'll take a while to compile it of course. :-)
--
see shy jo
signature.asc
Description: Digital signature
Couldn't file triggers be used, so ldconfig is triggered after any
package installs a library file? That's much more how I expected
triggers to be used, rather than needing an ugly ldconfig wrapper. I
think it also addresses drow's point about libraries in nonstandard
locations, since those
I've reopened this bug since a report of the same problem was filed on
debconf, and this bug has all the useful information.
I see no indication that the bug is in debconf. When the kde frontend is
loaded, debconf loads perl-qt, which involves loading the qt library.
Based on this bug log,
Pierre Habouzit wrote:
The point is, there is an RFC, and we put a patch so that admins can
disable it using gai.conf.
There is an RFC is not always a good excuse for breaking existing systems.
Admins can disable it is not a good argument when one common class of
the breakage is all the
Just spent half an hour since my slug wouldn't boot and I had to reflash
an old initramfs. This bug should be fixed ASAP before it breaks a lot
of systems.
[EMAIL PROTECTED]:/tmp/initramfsmkinitramfs -o out -k
Working files in /root/tmp/mkinitramfs_tj3082 and overlay in
Along similar lines, perhaps the preinst should check for it? If the
preinst can see it in the envoronment, you know the system is screwed.
:-)
--
see shy jo
signature.asc
Description: Digital signature
Package: tzdata
Version: 2007e-2
Severity: normal
The config script could check $2 to see if it's being upgraded from a
pre-debconf-using version, and skip asking questions if so. There's no
need to bother everyone with redundant time zone questions on upgrade.
-- System Information:
Debian
Package: libc6
Version: 2.3.6.ds1-4
Severity: normal
Preparing to replace libc6 2.3.6.ds1-4 (using .../libc6_2.3.6.ds1-5_i386.deb)
...
Matching libraries: /usr/lib/libpthread.so.20
A copy of glibc was found in an unexpected directory.
It is not safe to upgrade the C library in this situation;
Aurelien Jarno wrote:
You suggest conflicting with libpthread2, but that basically means it
would render the package uninstallable.
Which is fine, since libpthread2 is obsolete and has no reverse
dependencies.
I won't flag this bug as RC, since AFAICS it only affects upgrades from
older
Frans Pop wrote:
reassign 381881 libc6-udeb
version 381881 2.3.6-18
retitle 381881 Please add librt to the udeb (needed by mkfs.xfs)
severity 381881 important
tags 381881 + d-i
thanks
On Monday 07 August 2006 17:31, Ionut Georgescu wrote:
mkfs.xfs failed with error loading shared
Package: glibc
Severity: grave
Version: 2.3.6-13
Tags: d-i
As the subject says, these udebs are empty as of this version, which
makes d-i unable to resolve dns..
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Package: libc6-udeb
Version: 2.3.6-11
Severity: critical
Tags: d-i
Alphix It seems that libc6-udeb breaks d-i since the last hour or so:
Loading libc6-udeb failed for unknown reasons. Aborting. (in syslog:
annash: error while loading shared libraries: libgcc_s.so.1: cannot open
shared
I can reproduce this, with both 2.3.6-11 and 2.3.6-12, on i386.
Apparently, libc.so.6 is now linked with libgcc_s.so.1 on i386, which was
not previously the case with version -9.
Version -9:
[EMAIL PROTECTED]:~ldd /lib/libc.so.6
/lib/ld-linux.so.2 (0xa7feb000)
linux-gate.so.1 =
Gabor Gombas wrote:
How about storing the md5sum of /etc/localtime and updating it only if
the checksum has not been changed (and warning the user otherwise).
X.org does something similar for auto-updating xorg.conf if the user did
not change it manually.
It should even be possible to use ucf
Robert Millan wrote:
As you can see in the other mail, it seems to cause some breakage with nptl
and
librt. I'm not sure if d-i needs threading at all (or even what librt is ;).
Is that an issue for libc-udeb ?
Yes, I think that the graphical installer currently uses threads in at
least one
Robert Millan wrote:
I've tested what would be the size saving when building glibc with -Os:
Huh, I think I've checked whether -Os helped pretty much everything in
d-i, but never thought to try libc. Good idea, and this space savings
would in fact be useful; both because we're bursting at the
Kurt Roeckx wrote:
Package: debhelper
Severity: wishlist
If you want to file a bug report against debhelper, it might help to
send it to the BTS..
libc6 doesn't use debconf, libssl0.9.8 does, but probably not as
it should. But maybe libc6 can't used debconf?
libc6 can use debconf as long
Daniel Jacobowitz wrote:
libc6-i686 (like libc6-sparcv9) is something quite different - it's an
optimization package, it doesn't enable any new functionality.
What new functionality does libc6-amd64 provide to a non-amd system?
FWIW, adding 7 mb to standard without consulting anyone has a
Package: glibc
This package depends/pre-depends on debconf without allowing the dependency
to be satisfied with an alternate of debconf-2.0. That is to say, its
dependency should read: debconf | debconf-2.0
Until this is fixed, it is impossible to use this package with cdebconf,
and very hard to
GOTO Masanori wrote:
I changed now. BTW, is it ok to leave dependency Depends:
libnss-dns-udeb?
Good point, we do currently include libc on at least one image (boot
floppy) without libnss-dns, so it's not really a dependency and the
dependency should be removed.
--
see shy jo
signature.asc
Package: glibc
Severity: normal
Tags: d-i
libc6-udeb depends on libnss-files-udeb, which is unnecessary since most
d-i images don't need that udeb at all, and the udebs that do need it
seems to depend on it (openssh-client-udeb, openssh-server-udeb).
d-i has ignored unfilled dependencies when
Package: glibc
Severity: normal
Every time a new glibc is uploaded that has a locales with a dependency
on exactly that version of glibc, installs of unstable on every
architecture are broken until the autobuilder catches up and builds
glibc. Installs fail with errors like these:
locales:
Margarita Manterola wrote:
I've seen this bug for a while now. Sorry for not reporting it earlier.
When prompted to select the timezone, at second stage of the installer, if
you have chosen Argentina as the country, you get a dialog that is too
big to fit on screen, but can be corrected to
Blars Blarson wrote:
On a freshly installed sarge system (used april 27 i386 buisnesscard)
I get errors from perl and other programs due to the setting of
LC_CTYPE to the non-installed locale en_US.UTF8. Either this locale
needs to be installed by default as well or the default setting of
Can youfind out what is setting LC_CTYPE on your system? Something in
/etc/environment, your shell's rc files, your dotfiles, or what?
--
see shy jo
signature.asc
Description: Digital signature
Blars Blarson wrote:
On a freshly installed sarge system (used april 27 i386 buisnesscard)
I get errors from perl and other programs due to the setting of
LC_CTYPE to the non-installed locale en_US.UTF8. Either this locale
needs to be installed by default as well or the default setting of
Can youfind out what is setting LC_CTYPE on your system? Something in
/etc/environment, your shell's rc files, your dotfiles, or what?
--
see shy jo
signature.asc
Description: Digital signature
Christian Perrier wrote:
Joey ? Should we split the bug and assign a Please mark the locales
package for installation as soon as something else than English (USA)
is chosen bug to debian-installer or base-config ?
languagechooser already does that.
--
see shy jo
signature.asc
Description:
GOTO Masanori wrote:
I don't think spliting zoneinfo is useful.
(1) If zoneinfo is set as required, then at last we need to install
libc6 and zoneinfo on general machine.
(2) I think even on many small dedicated servers, they need to handle
time. And if such servers has no need
Steve McIntyre wrote:
No problem here. The zone info is actually quite small (compressed)
within the .deb, not really big enough to warrant the split I was
(mistakenly) asking for. Sorry for bothering you and thanks for
looking into this.
It is, however, 5 mb unpacked, which is quite large
GOTO Masanori wrote:
I don't think spliting zoneinfo is useful.
(1) If zoneinfo is set as required, then at last we need to install
libc6 and zoneinfo on general machine.
(2) I think even on many small dedicated servers, they need to handle
time. And if such servers has no need
Steve McIntyre wrote:
No problem here. The zone info is actually quite small (compressed)
within the .deb, not really big enough to warrant the split I was
(mistakenly) asking for. Sorry for bothering you and thanks for
looking into this.
It is, however, 5 mb unpacked, which is quite large
Steve McIntyre wrote:
* Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.
If you give in to this bug report, please
Steve McIntyre wrote:
* Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.
If you give in to this bug report, please
Jeff Bailey wrote:
Hrm.. I'd like to ask the debhelper maintainer what he thinks first -
It seems to me that one of the fixups scripts (possibly dh_fixperms)
should have this built in.
I'm going to be late to work today, but I'll try to remember to ask
joeyh when he hops on later.
In
Jeff Bailey wrote:
Hrm.. I'd like to ask the debhelper maintainer what he thinks first -
It seems to me that one of the fixups scripts (possibly dh_fixperms)
should have this built in.
I'm going to be late to work today, but I'll try to remember to ask
joeyh when he hops on later.
In
Daniel Jacobowitz wrote:
1. I need to pass custom arguments to objcopy --only-keep-debug.
Specifically, I'm removing every piece of debug info except for
.debug_frame. This means no type information, line number information,
et cetera - but very low disk space usage, low GDB startup times,
Daniel Jacobowitz wrote:
1. I need to pass custom arguments to objcopy --only-keep-debug.
Specifically, I'm removing every piece of debug info except for
.debug_frame. This means no type information, line number information,
et cetera - but very low disk space usage, low GDB startup times,
Daniel Jacobowitz wrote:
Hmm, I could add an option to pass parameters to objcopy, but I'm not
exactly thrilled about the idea.
Then a wrapper it is :)
Also not very thrilling. :-)
Do you think any other packages will have reason to need to do this, or
is it pretty much as glibc only
Daniel Jacobowitz wrote:
The last three lines are because libc6.postinst does a dpkg -l of sysvinit,
which is not yet installed. Perhaps they could be sent to stderr to help
clean up the debootstrap output a little bit?
They're already sent to stderr. In -11 they'll be sent to /dev/null
Daniel Jacobowitz wrote:
The last three lines are because libc6.postinst does a dpkg -l of sysvinit,
which is not yet installed. Perhaps they could be sent to stderr to help
clean up the debootstrap output a little bit?
They're already sent to stderr. In -11 they'll be sent to /dev/null
Package: libc6
Version: 2.3.2.ds1-10
Severity: minor
From my debootstrap.log:
(Reading database ... 220 files and directories currently installed.)
Unpacking libc6 (from .../libc6_2.3.2.ds1-10_i386.deb) ...
dpkg: libc6: dependency problems, but configuring anyway as you request:
libc6 depends
Colin Watson wrote:
I don't know why dpkg-buildpackage didn't check that for you.
Possibly because it is currently broken, although I have not checked if
the bug is triggered by glibc's control file.
--
see shy jo
signature.asc
Description: Digital signature
Colin Watson wrote:
I don't know why dpkg-buildpackage didn't check that for you.
Possibly because it is currently broken, although I have not checked if
the bug is triggered by glibc's control file.
--
see shy jo
signature.asc
Description: Digital signature
GOTO Masanori wrote:
It looks really good. It is the future rock replacement. BTW, one
problem is libc6.postinst invokes tzconfig. Should we remove tzconfig
configuration code from libc6.postinst?
I can't say, because I've never understood why the postinst does that.
--
see shy jo
Petter Reinholdtsen wrote:
So I'm not sure if it should be reassigned, or just closed. The
problem is hidden with the two fixes, and the last real is probably
already reported against slang. The behaviour of the locales package
is not obviously a bug, so I am reluctant to report it.
I
Denis Barbier wrote:
On Wed, Sep 10, 2003 at 01:47:25PM -0400, Joey Hess wrote:
Petter Reinholdtsen wrote:
So I'm not sure if it should be reassigned, or just closed. The
problem is hidden with the two fixes, and the last real is probably
already reported against slang. The behaviour
Package: libc6
Version: 2.3.2-4
Severity: normal
We currently have two programs in base, tzconfig and tzsetup, that do
the same things. I thought I asked for this a long time ago, but I think
tzconfig should be removed from the distribution. If there is a lot of
documentation that refers to
- debian/patches/revert-old-libio.dpatch: back out changes causing
problems with fseek in binaries linked with glibc 2.0.
(Closes: #206839)
FWIW, the libio revert in glibc 2.3.2-4 also fixed my problems with
segfault on rewind(fileno(FILE)) in mooix. Mooix was built with glibc
Package: libc6
Version: 2.3.2-3
Severity: grave
(Reading database ... 144697 files and directories currently installed.)
Preparing to replace libc6 2.3.2-2 (using .../libc6_2.3.2-3_i386.deb) ...
Unpacking replacement libc6 ...
dpkg: error processing /var/cache/apt/archives/libc6_2.3.2-3_i386.deb
I have a very strange segfault with glibc 2.3.2, code worked with
earlier glibc versions.
Program received signal SIGSEGV, Segmentation fault.
0x400873bd in _IO_seekoff_unlocked (fp=0x8049b68, offset=0, dir=0, mode=3) at
ioseekoff.c:55
55 ioseekoff.c: No such file or directory.
in
Michael Stone wrote:
I don't know that there's a full list of *packages* that might be
affected.
Start with config.guess files from ~2001. Also ltmain.sh from the
same time period.
[EMAIL PROTECTED]:~package~/grepunposix `locate config.guess` |wc -l
12
[EMAIL
- Forwarded message from Paul Eggert [EMAIL PROTECTED] -
How about this much-simpler workaround instead: patch glibc so that
_POSIX2_VERSION has its old value. That is more honest, since you
probably still have some programs that don't conform to POSIX
1003.1-2001 yet.
GOTO Masanori wrote:
It's fine, and in this modification chance, we would like to apply
#117509 locales: Message grammar. Do you think?
Yes, that is a definite improvement.
if db_go; then
STATE=$(($STATE + 1))
else
STATE=$(($STATE - 1))
fi
done
I
Package: libc6
Version: 2.3.1-16
Severity: normal
My laptop, which was installed from stable last summer and upgraded to
unstable, has /usr/doc/libc6 and /usr/doc/libc6-dev symlinks. I see no
code in the postinsts or preinsts that could be responsible for this.
My server, installed this spring
GOTO Masanori wrote:
It seems that this problem exists in almost glibc packages; libc6,
libc6-dev, libc6-pic, libc6-dbg, libc6-prof, locales, nscd,
glibc-doc...
Yeah, I later noticed it in glibc-doc and locales as well, after filing
the bug.
I decided to add that code to prerm in all glibc
GOTO Masanori wrote:
I checked with glibc 2.3.1-14 on kernel 2.4.19, your test program
returns ENOMEM. It's fixed. BTW, is it really glibc problem?
I think it's kernel problem. Look using with strace:
mprotect(0x804a000, 2147532800, PROT_READ) = -1 ENOMEM (Cannot allocate memory)
Daniel Jacobowitz wrote:
The one in RPM. However, glibc 2.3.1-3 should (temporarily) work
around this issue (and a rebuild of static libraries in the RPM package
will help, too).
Well, I get the error in the middle of a rpm build, so the couple of
static libraries in there should have already
It seems that longrun and similar programs (procmeter3 longrun support,
etc) are broken by the new libc.
This program should read the transmeta vendor cpuid:
#define CPUID_DEVICE /dev/cpu/0/cpuid
#define CPUID_TMx86_VENDOR_ID 0x8086
#include sys/types.h
#include sys/stat.h
#include fcntl.h
Jeff Bailey wrote:
Is it perhaps using an installed library instead of the newly built
one? Either that or it's probably pulling in a static library for
something else. I don't have enough information to offer a better
suggestion.
The failing link is linking a static rpm binary, so yes, it
Jeff Bailey wrote:
It seems that this is caused by pre glibc-2.3 static libraries. I
don't yet understand the whole problem, but I do know that a simple
recompile of the static library makes it pick up the new symbols
correctly.
Which static library do you mean, one of the ones in glibc, or
Daniel Jacobowitz wrote:
The one in RPM. However, glibc 2.3.1-3 should (temporarily) work
around this issue (and a rebuild of static libraries in the RPM package
will help, too).
Well, I get the error in the middle of a rpm build, so the couple of
static libraries in there should have already
It seems that longrun and similar programs (procmeter3 longrun support,
etc) are broken by the new libc.
This program should read the transmeta vendor cpuid:
#define CPUID_DEVICE /dev/cpu/0/cpuid
#define CPUID_TMx86_VENDOR_ID 0x8086
#include sys/types.h
#include sys/stat.h
#include fcntl.h
Jeff Bailey wrote:
Is it perhaps using an installed library instead of the newly built
one? Either that or it's probably pulling in a static library for
something else. I don't have enough information to offer a better
suggestion.
The failing link is linking a static rpm binary, so yes, it
Randolph Chung wrote:
if (pread(fd, data, 16, CPUID_TMx86_VENDOR_ID) != 16) {
um that last field is an offset, why does it use the vendor ID as
the offset?
I suppose that is the offset to the vender id. I don't relly understand
how the longrun information is came up with though.
Jeff do you have any fixes for rpm and glibc 2.3.1? I don't know where
this __ctype_b symbol is coming from (ctype.h?) or why the linker wants it,
but I get similar errors merely building rpm on a system with glibc 2.3.1
and it seems libc has stopped exporting the symbol. I tend to think this is
Martin Schulze wrote:
Even worse, syslogd only reads what is provided on /dev/log.
The socket is world writable, glibc's syslog() function writes
to it, from any program. Restricting its write access to root
would effectively disable syslogging.
syslogd could use getsockopt(SO_PEERCRED)
Ben Collins wrote:
Not everything has to be recompiled. Just libs that use obsolete symbols
(ones that have changed to weak symbols for compatibility, but now have
newer versions of that symbol). We had this same issue with the 2.0.7 -
2.1.0 upgrade. It was actually a lot more extensive than
Miros/law `Jubal' Baran wrote:
Wouldn't it be good to implement subpackages into dpkg?
It would be easier and more generally useful to implement file
exclusions. Then you could exclude all of /usr/share/locale/ except C
and favorite-language-code-here, plus it has other uses like
systems that
83 matches
Mail list logo
