reassign 254314 libc6
thanks
On Jun 14, Andreas Metzler <[EMAIL PROTECTED]> wrote:
> mutt crashes on the attached mbox file (gzipped to make sure it is
> transfered unchanged) when used with this initialisation file:
Looks like a libc bug.
#0 0x401d4259 in find_collation_sequence_value () from
Package: multiarch-support
Version: 2.13-7
Severity: normal
multiarch-support depends on libc6, so /usr/share/doc/multiarch-support/
can be a symlink to /usr/share/doc/libc6/ : we can and should save 150
KB on every Debian system.
The same applies to the libc6-* packages.
--
ciao,
Marco
signa
I am able to reproduce this over and over with firefox and liferea.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 12, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> I don't think such a patch, involving the kernel, a userland daemon and
> changes into glibc, should be integrated into Debian if it has not been
> integrated upstream. I believe such things should be standardized a
> minimum, so that all dist
On Oct 23, Daniel Molka wrote:
> error getting signalfd
This is the code which is failing (I expect with ENOSYS):
pfd[FD_SIGNAL].fd = signalfd(-1, &mask, 0);
if (pfd[FD_SIGNAL].fd < 0) {
> ii libc6 2.9-12 GNU C Library: Shared libraries
This
On Apr 17, Tore Anderson wrote:
> It would be great if Debian could also apply the patch. That is clearly
> the behaviour that will serve end users the best.
Agreed. Can the libc maintainers please comment on this issue?
The next Debian release will be used in a period in which more and more
si
On Apr 29, Clint Adams wrote:
> Is the danger of the cache being 30 days out-of-date not a worry
> in practice?
And what about the increased memory usage on large systems?
I am not persuaded at all that this change is appropriate for the
default configuration.
I'd even say that supporting offline
reassign 689427 nscd
thanks
On Nov 17, Michael Biebl wrote:
> Imho this is a bug in nscd. At least I find it very confusing/unexpected
> that a stop+start has a different result then a restart.
Agreed: if flushing the cache on stop/restart is appropriate then nscd
should provide a proper system
Maybe then the glibc people know what could make ldconfig create a link
to the wrong library.
On Sep 30, shichimohedron wrote:
> >Does it still happen after something like this?
>
> > mv /usr/sbin/ldconfig /usr/sbin/ldconfig.old
> > cp -a /bin/true /usr/sbin/ldconfig
> > dpkg -i .../libcrypt1_
Thank you Aurelien for your help, so this is user error.
On Sep 30, shichimohedron wrote:
>
> On Thursday, September 30th, 2021 at 12:08 PM, Aurelien Jarno
> wrote:
>
> > It could be that this libpthread.so.1 file is actually a copy of an old
> >
> > libcrypt.so.1. It's something you can che
> As the issue is actually introduced by the usrmerge package, I am
> reassigning the bug there. I am also tagging it wontfix as I don't
> believe the usrmerge maintainer will want to rollback the usrmerge
> transition, but feel free to change that if I am wrong.
Indeed.
I have used TSM for many y
Control: reassign -1 libc6
Control: version -1 2.25
On Nov 21, Thorsten Glaser wrote:
> udevadm: Relink `/lib/x86_64-linux-gnux32/libkmod.so.2' with
> `/lib/x86_64-linux-gnux32/libpthread.so.0' for IFUNC symbol `system'
>
> This was printed a hundred times or so to the terminal.
I understand t
On Aug 17, Aurelien Jarno wrote:
> > > The preinst scripts could check whether the package is being installed
> > > in a --merged-usr environment and create (dangling) symlinks if
> > > /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> > > they went missing.
Yes: this is how
Package: glibc
Version: 2.29-2
Severity: normal
The libc implementation of crypt(3) has been deprecated since 2.28.
libxcrypt is needed to support modern hashing algorithms.
How do you want to coordinate switching to libxcrypt?
The libxcrypt implementation is source and binary backward compatibl
On Oct 06, Aurelien Jarno wrote:
> The libxcrypt implementation is indeed source backward compatible,
> however doesn't seem binary backward compatible. libc6 provides
> libcrypt.so.1 while libxcrypt provides libcrypt.so.2.
It provides both, but currently I am not even building libcrypt.so.2
sin
On Oct 06, Aurelien Jarno wrote:
> Ah this doesn't match the version in unstable, it's only in NEW for now.
> I guess we need to wait for it to get out of there first.
For reasons which I do not understand, the ftpmasters obliquely let me
know that they will not accept libxcrypt from NEW until t
On Oct 07, Aurelien Jarno wrote:
Dear debian-boot: for the benefit of the ftpmasters, please confirm that
you have no objections to src:libxcrypt generating a libcrypt1-udeb
package (initially in experimental) which will provide crypt(3)
currently in the libc udeb.
> I guess we should keep bu
On Oct 09, Aurelien Jarno wrote:
> I have implemented the first option in the libxcrypt branch:
>
> https://salsa.debian.org/glibc-team/glibc/tree/libxcrypt
And here you can see a tentative libxcrypt package: does it look right
to you?
https://salsa.debian.org/md/libxcrypt/blob/master/debian/c
On Nov 05, Aurelien Jarno wrote:
> We have done a new upload of glibc into sid. I have just merged the
> changes to the libxcrypt branch. You might want to update your branch by
> adding 1 to the debian revision for the breaks/conflicts.
I have uploaded 4.4.10-2 targeted to experimental with Brea
On Jan 05, Aurelien Jarno wrote:
> The bcrypt() function has been moved out of libc and is now provided by
> libxcrypt. Reassigning the bug accordingly.
libxcrypt's crypt(3) supports bcrypt and also more modern methods, so
the bug can be closed.
Some work in the PAM package is still desirable,
On Nov 14, Dominic Hargreaves wrote:
> This seems to be same as #953562 which was reported in March.
Why do you think that this is the same?
--
ciao,
Marco
signature.asc
Description: PGP signature
On Nov 16, Niko Tyni wrote:
> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
> is fully installed.
I think that Niko is right, so I would like to know the opinion of the
glibc maintainers.
--
On Nov 19, Sven Joachim wrote:
> I am not one of them, but AFAICS that would introduce a fatal circular
> dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be
> configured before it can be unpacked, but libcrypt1 depends on libc6 so
> it cannot be configured before libc6 is at leas
On Apr 14, Paul Gevers wrote:
> The patch looks sensible after reading the discussion in these bugs. Can
> we have an upload soon to have exposure?
Unless there are any objections I will do a libxcrypt upload in a couple
of days.
I think that I can leave the udeb library in /usr/lib/.
--
ciao
reopen 343140
retitle 343140 resolver uses the search list before other address families
thanks
On Dec 20, GOTO Masanori <[EMAIL PROTECTED]> wrote:
> Okay, I close it. If you think there's bugs in libc, please tell me
> about it.
I think this is definitely a glibc bug, and disabling IPv6 support
On Dec 21, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> It's not a bug. It may be inefficient, but that's not a bug in itself.
I find this reasoning very peculiar. If an algorithm is inefficient and
this causes problems then it is obviously buggy.
And it's doubly buggy if its inefficiencies cause are
On Dec 23, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > I find this reasoning very peculiar. If an algorithm is inefficient and
> > this causes problems then it is obviously buggy.
> An algorithm is buggy if it does not match the specification. I see no
Yet another very peculiar definition from you
In article <[EMAIL PROTECTED]> you wrote:
>I noticed that inndstart started segfaulting after upgrading to libc6
>version 2.3.2-2.
If this only happens when you reload hosts.nntp (this is also done every
night from crontab) then it's a very old INN bug fixed in 1.7.2debian-23.
--
ciao,
Marco
-
Package: libc6
Version: 2.3.2-5
Severity: serious
[This is a standard text.]
This bug has serious severity because it is a policy violation and
is an item in aj's list of release showstoppers.
One or more libraries in this package are buggy.
All libraries need to be linked against other librarie
[EMAIL PROTECTED] wrote:
>I'm running ext2 on linux 2.2.20 but a friend of mine is running
>reiserfs on 2.4.22 and have the same problem.
I think that d_type is only available on modern 2.4 kernels when using
ext2 or ext3.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
This problem is supposed to happen when the wrong version of libc
is installed instead of the correct one or e.g. in /usr/lib/.
Unless there is a different and sparc64-specific issue then I think this
bug should be closed.
--
ciao, |
Marco | [2226 alWax7Q4tbXfE]
--
To UNSUBSCRIBE, email to [EM
On Dec 22, GOTO Masanori <[EMAIL PROTECTED]> wrote:
>Interesting. My debian box uses USB + hotplug, and it mounts usbfs
>automatically. I don't know what hotplug is actually doing, but IIRC
>usbdevfs is needed for this kind of hotplugging daemons. Is it worth
>while mounting with /etc/init.
Package: timezones
Version: N/A
Severity: important
I have been able to remove the package, with the obvious results...
Something sould depend on timezones, users should not be able to
remove it.
-- System Information
Debian Release: potato
Kernel Version: Linux wonderland 2.2.12 #0 Sat Aug 28 00
On Nov 21, Debian Bug Tracking System <[EMAIL PROTECTED]> wrote:
Nevermind, I noticed it *should* be removed after installing libc6.
But the user should be warned he has to run tzconfig after removing it.
--
ciao,
Marco
Package: libc6
Version: 2.1.2-10
Severity: wishlist
$ cat bad.c
#define _XOPEN_SOURCE
#include
#include
#include
int main(void){exit(0);}
$ cc -Wredundant-decls bad.c
In file included from /usr/include/unistd.h:724,
from bad.c:4:
/usr/include/getopt.h:36: warning: redundant re
Package: libc6
Version: 2.1.2-10
Severity: normal
Please put the it.po file in the potato and woody packages.
It has not been integrated upstream because of problems with the
translation project robot.
begin 644 glibc-it.po.gz
M'XL("`X%FS@"`V=L:6)C+6ET+G!O`*QE^
M\QU[K>-%(JZE2%Q.<%.U$!MGG/DT"S
M\.
reassign 63658 libc6
thanks
Regex support is buggy.
You can find the whole story and test cases in the other bug messages.
--
ciao,
Marco
--- Begin Message ---
On 2000-05-14 16:53:05 +0200, Andreas Metzler wrote:
> color body yellow blue "^ {0,3}([|>:}#] ?){3}.*"
OK... I saved your message to
What should I do? I can't login to the box, either with IPv4 or IPv6.
looks like the new libc broke ssh... anybody else noticed that?
it also broke postfix-tls and I think I know why
I get in the log messages like Oct 5 01:47:23 baol sshd[1913]: fatal:
get_sock_port: getnameinfo NI_NUMERICS
If anybody wants to maintain this package please step forward.
Known problems:
- build-depends should be versioned
- one element of the testsuite has been disabled because it fails when
built out of the tree and I haven't been able to fix it
The red hat package builds /sbin/prelink as a static
On Jan 02, Philip Blundell <[EMAIL PROTECTED]> wrote:
>> Would it be appropriate to file bugs against packages which fail
>> prelinking? Does anybody understand what's wrong with many gnome
>> libraries (it complains about a undefined weak symbol).
>What's the actual error you see? If it's th
If anybody wants to maintain this package please step forward.
Known problems:
- build-depends should be versioned
- one element of the testsuite has been disabled because it fails when
built out of the tree and I haven't been able to fix it
The red hat package builds /sbin/prelink as a static
On Jan 02, Philip Blundell <[EMAIL PROTECTED]> wrote:
>> Would it be appropriate to file bugs against packages which fail
>> prelinking? Does anybody understand what's wrong with many gnome
>> libraries (it complains about a undefined weak symbol).
>What's the actual error you see? If it's th
Package: glibc-doc
Version: 2.3.1-7
Severity: normal
lrwxrwxrwx1 root root 17 Dec 24 17:03
/usr/share/doc/glibc-doc/html/index.html -> chapters_toc.html
But chapters_toc.html does not exist.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux wonderlan
I think that policy needs two small corrections to reflect current
practices wrt shared libraries and PIC code:
- what is PIC library needs to be correctly defined: compiling with
-fPIC is not enough to have PIC code, the object MUST NOT have a
TEXTREL section either [any other symbols need to
Package: glibc
Severity: wishlist
GNU libidn (http://www.gnu.org/software/libidn/) now can be built as a
glibc component to support internationalized domain names.
When the new getaddrinfo flag is not used it's out of all code paths, so
this will not introduce new stability concerns.
See this URL
This problem is supposed to happen when the wrong version of libc
is installed instead of the correct one or e.g. in /usr/lib/.
Unless there is a different and sparc64-specific issue then I think this
bug should be closed.
--
ciao, |
Marco | [2226 alWax7Q4tbXfE]
On Dec 22, GOTO Masanori <[EMAIL PROTECTED]> wrote:
>Interesting. My debian box uses USB + hotplug, and it mounts usbfs
>automatically. I don't know what hotplug is actually doing, but IIRC
>usbdevfs is needed for this kind of hotplugging daemons. Is it worth
>while mounting with /etc/init.
I'm lazy, so I will include my last blog post as a summary.
This goes to debian-glibc and the initscripts maintainer as well because
S35mountkernfs needs to be split in two parts: one which will mount /proc
and /sys, to be run at S03 and one for the rest, which can be left at S35.
This will have t
I'm lazy, so I will include my last blog post as a summary.
This goes to debian-glibc and the initscripts maintainer as well because
S35mountkernfs needs to be split in two parts: one which will mount /proc
and /sys, to be run at S03 and one for the rest, which can be left at S35.
This will have t
I forgot a crucial detail about mounting the kernel file systems early
in the boot process: /dev/pts must be mounted after udev has mounted its
own ramfs over /dev, so we will still need two different init script
even after mountkernfs will be removed from libc6.
--
ciao, |
Marco | [5289 trbA.sor
On Mar 24, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
> Sounds like udev needs to run before everything else if it uses
> a ramfs as /dev .. can't you just say "if you want to use udev
> with a ram-based filesystem, run udev from initrd" ? I think
> that's what the general idea was, anyway
On Mar 24, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> Umm, why does you udev package mount a ramfs over /dev? The whole point
Because this makes the package a lot more robust, as there are no risks
of breaking the original /dev which will be available again when udev is
disabled or purged.
It
On Mar 26, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
> 1. udev runs after mountvirtfs, umounts /dev/pts, mounts a new /dev,
>remounts /dev/pts. If you use " umount -l" it won't even matter
>if /dev/pts is busy, and since there is only one instance of devpts
>anyway you'll remou
reassign 254314 libc6
thanks
On Jun 14, Andreas Metzler <[EMAIL PROTECTED]> wrote:
> mutt crashes on the attached mbox file (gzipped to make sure it is
> transfered unchanged) when used with this initialisation file:
Looks like a libc bug.
#0 0x401d4259 in find_collation_sequence_value () from
reassign 289945 libc6
retitle 289945 please add support for long long dev_t
tag 289945 patch upstream
thanks
Please apply to allow udev to create nodes for drivers which need more
than 2^8 minors.
On Jan 12, Roland Dreier <[EMAIL PROTECTED]> wrote:
> (I guess this bug should be reassigned to lib
On Feb 26, Faidon Liambotis wrote:
> It's great that Fedora has already paved the way here and did most of
> the hard work! I don't know how your appetite is in doing this for
> trixie, but I'd personally love to see this happen.
Agreed, Adam and Faidon are clearly right.
This is "just" 8 MB of d
56 matches
Mail list logo
