Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages

Aurelien Jarno wrote: > As a subsidiary question, do you know how to prevent libc6-amd64:i386 to > be installed on a native amd64 system, but allow it on an i386 system, > even with libc6:amd64 already installed? Use Conflicts against dpkg:amd64, maybe. :( -- To UNSUBSCRIBE, email to debian-gl

Bug#718577: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations

tags 718577 + upstream patch quit Hal BugsBuster wrote: > Do you mean that all these catastrophic overheads are no longer > existing in libm-2.18 ? Yes, I believe Carlos was saying that glibc 2.18 has a fix for the performance regression, which Debian should apply: >> commit 2506109403de69bd454

Bug#556173: libc-bin: introduces custom manual pages / manpages package

Simon Paillard wrote: > Do you have a position regarding this ? [...] > On Thu, May 23, 2013 at 11:48:51PM +0200, Simon Paillard wrote: >> If you agree with this, the next manpages{,dev} upload will replace libc-bin >> with appropriate version, then you can drop them. Please go ahead. (I'm not

Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high

severity 572895 tags 572895 + upstream quit Harald Dunkel wrote: > AFAICS the mesa folks don't rely upon the os abi tag anymore: > > https://bugs.freedesktop.org/show_bug.cgi?id=26663 Thanks. I think this is still a bug (priority between LD_LIBRARY_PATH and .note.ABI-tag makes .note.ABI-tag muc

Bug#632281: elfutils isn't finding its plugins

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 worried that there's no value of ORIGIN and LIB that would make "$ORIGIN/../

Bug#583088: error generating locales es_ES, syntax errors, no definition categorys

tags 583088 + moreinfo quit Hi again, In 2010, Iker Salmón San Millán wrote: > The same happens with kernel 2.6.32-5-686. I cannot acces now to the others > computers to see if i can reproduce the bug or maybe theres is something > diferent in my laptop's configuration. > > It is not a problem

Bug#566508: libc6: error inside of python since last security upgrade

tags 566508 + moreinfo quit In 2010, dan aronson wrote: > Since I did the last security upgrade to this package I've been getting the > following problem often, but not always during running of a cron job. > > *** glibc detected *** /usr/bin/python: corrupted double-linked list: > 0x020

Bug#576484: libc6-prof: segmentation fault when using profiling with pthread.

tags 576484 + moreinfo quit Hi, In 2010, Witold Baryluk wrote: > Package: libc6-prof > Version: 2.10.2-6 > Severity: important > > # cat a.c int main() { return 0; } > # gcc -g -pg a.c -o a -static-libgcc -lc_p > # ./a > Exit code 0 > # gcc -g -pg a.c -o a -static-libgcc -lc_p -pthread > # ./

Bug#534312: upgrade of libc6 causes SEGFAULTs

tags 534312 + moreinfo quit Hi, In 2009, Ulf Hermann wrote: >> You say you are using libc6 from unstable on a lenny system. What is the >> list of packages you tried to upgrade? > > I tried to install a full KDE 4.2, that's quite a lot of packages and some of > them depend on the newer libc - I

Bug#713914: Add more information why libc is not usable with Linux kernel < 2.6.32

retitle 713914 squeeze->wheezy: reminder that kernel should be >= 2.6.32 before upgrade reassign 713914 release-notes tags 713914 + wheezy affects 713914 + libc6 quit Hi Thomas, Thomas Bleher wrote: > When updating Squeeze to Wheezy, I encountered the following error on > two separate machines:

Bug#707306: libc6: unable to upgrade to 2.17 getting errors while configuring

Hi, shirish शिरीष wrote: > A copy of the C library was found in an unexpected directory: > '/lib/libdl-2.11.2.so' [...] > I removed the offending library copy as well as the original, quite a > few of them before I was able to correctly install it without any > errors :- Where did these files

Bug#703980: time.h: defining TIME_UTC conflicts with boost/thread/xtime.hpp enum

reassign 703980 src:boost1.49 forcemerge 701377 703980 tags 701377 + sid experimental affects 701377 libc6-dev quit Dmitrijs Ledkovs wrote: > TIME_UTC is part of C11 standard, which is more authoritative despite > boost's prior usage. > In boost1.49 package this is bug 701733, but it's marked won

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

Vincent Lefevre wrote: > On 2013-03-03 23:49:26 -0800, Jonathan Nieder wrote: >> Better debdiff attached. > > OK, but I don't know how to download the eglibc source: both > "apt-get source eglibc/unstable" and "apt-get source -t unstable eglibc" > dow

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

tags 153022 + upstream patch moreinfo quit On 2013-03-03 16:33:45 -0800, Jonathan Nieder wrote: > If someone prepares a backport of the fix for 2.13.y, would you > like to test it? debdiff attached. Completely untested. diff -u eglibc-2.13/debian/changelog eglibc-2.13/debian/cha

Bug#665940: Bug 637239 is still present in stable (with libc6 2.11.3-3)

unarchive 637239 forcemerge 637239 665940 quit Hi, In 2012, Robin Houston wrote: > The bug reported in #637239 is still present in squeeze, though it is > recorded > as having been fixed in 2.11.3-1. > > This may be verified by running the test script at > http://sourceware.org/bugzilla/attachme

Bug#634261: [sparc] iceweasel: Bus Error in setbuf()

(culling cc list) Hi Adrian, John Paul Adrian Glaubitz wrote: > [Subject: Debian #634261: Is it actually a(n RC) bug?] Please keep in mind that these appear as emails in a crowded inbox, so the subject line can be a good place to put valuable context. > Mike Hommey wrote: >> FYI, I found that

Bug#690154: eglibc: FTBFS: gcc-4.4: Internal error: Segmentation fault (program as)

tags 690154 + unreproducible # unreproducible severity 690154 important quit Michael Banck wrote: >> Lucas Nussbaum wrote: >>> During a rebuild of all packages in *wheezy*, your package failed to >>> build on amd64. >>> >>> Two notes on this bug: >>> - the build failed twice in a row (I auto-retr

Bug#692154: Shouldn't description mention also 3.2 kernels?

for changes in cvs-ldconfig-cache-abi.diff. * debian/debhelper.in/libc.preinst: Remove old ld.so.cache on upgrade. + [ Jonathan Nieder ] + * control.in/opt: correct misspelling of "Ezra" in descriptions of +*-i686 variants. Thanks to Thorsten Glaser. + -- Adam Conrad

Bug#693848: libc6: ld.so: LD_DEBUG=libs doesn't do what help says

Samuel Bronson wrote: > | libsdisplay library search paths [...] > I expected this to list the entire library search path: [...] > but, as you can see, it didn't. Is this just an unclear help message, > or is it actually an implementation bug? The former, I think. Since it was introdu

Bug#692154: Shouldn't description mention also 3.2 kernels?

dex: changelog === --- changelog (révision 5364) +++ changelog (copie de travail) @@ -1,6 +1,9 @@ eglibc (2.13-37) UNRELEASED; urgency=low - * + [ Jonathan Nieder ] + * control.in/opt: remove outdated reference to 2.6 kernel from +description o

Bug#208308: *printf() and incomplete multibyte sequences may cause infinite loops in applications

-28 Andreas Schwab + + [BZ #6530] + * stdio-common/vfprintf.c (process_string_arg): Revert + 2000-07-22 change. + +2011-09-28 Jonathan Nieder + + * stdio-common/Makefile (tst-sprintf-ENV): Set environment + for testcase. + * stdio-common/tst-sprintf.c: Include + (ma

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

notfound 691606 eglibc/2.13-36 tags 691606 - moreinfo quit Beojan Stanislaus wrote: > strange. I upgraded again and it works now. I think it simply failed to > install correctly the first time around (though why aptitude didn't complain > about this later, I don't now. > > I'm closing this bug.

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

Beojan Stanislaus wrote: > Although (as expected) when booting into recovery mode (the only way I can > login), the syslog output appears on the screen during boot. Ok, perfect. In recovery mode, could you please run set -x . /etc/default/locale dmesg and attach the ou

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

Beojan Stanislaus wrote: > On Saturday 27 October 2012 11:56:26 Jonathan Nieder wrote: >> Could you try: >> >> set -x >> . /etc/default/locales; # or whatever file reproduces this >> >> and then also attach full "dmesg" output? [...] > U

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

Beojan Stanislaus wrote: > locale file attached. [...] > # File generated by update-locale > LANG="en_GB.UTF-8" > LANGUAGE="en_GB:en" Ok, thanks. I don't see anything objectionable there, so the problem has to be somewhere else. Could you try: set -x . /etc/default/locales; # or whatever fi

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

tags 691606 + moreinfo # machine-specific severity 691606 important quit Hi, Beojan Stanislaus wrote: > This version of locales causes any script that includes the line > . /etc/default/locales > > to exit with a floating point exception. I don't have that file. I do have $ grep .

Bug#650234: Use chroot's ld.so to do loading?

unmerge 626482 reassign 650234 fakechroot 2.15-1 severity 650234 important tags 650234 + upstream quit Elliott Mitchell wrote: > user@host:/$ ls > Segmentation fault > user@host:/$ /lib/ld-linux.so.2 ls > ls: error while loading shared libraries: ls: cannot open shared object file: > No such fil

Bug#684889: Confirmed, but FTBFS with patch (Re: eglibc: CVE-2012-3480)

Hi Bas, Bas Wijnen wrote: > Encountered regressions that don't match expected failures: > tst-cputimer1.out, Error 1 > make: *** [/tmp/eglibc-2.13/stamp-dir/check_i686] Fout 1 Yeah, I don't think this is due to the patch. It's been mentioned in various places: e.g., [1] [2] I can't find a repo

Bug#690154: eglibc: FTBFS: gcc-4.4: Internal error: Segmentation fault (program as)

Hi Lucas, Lucas Nussbaum wrote: > During a rebuild of all packages in *wheezy*, your package failed to > build on amd64. > > Two notes on this bug: > - the build failed twice in a row (I auto-retry failed builds) > - the build did not fail with gcc 4.7 from unstable (I was doing a test > rebuil

Bug#689932: Please define sized int{8,16,32,64}_t types portably even for GCC

Josh Triplett wrote: > On Sun, Oct 07, 2012 at 04:52:30PM -0700, Jonathan Nieder wrote: >> Which compiler are you using? Is its identifying itself as gcc >= 2.7 >> intentional? > > c2hs, which uses GCC's preprocessor. Independently of this request, that seems lik

Bug#689932: Please define sized int{8,16,32,64}_t types portably even for GCC

Hi Josh, Josh Triplett wrote: > However, for compilers that identify themselves as GCC (which includes > many non-GCC compilers), sys/types.h does this instead: > > # define __intN_t(N, MODE) \ > typedef int int##N##_t __attribute__ ((__mode__ (MODE))) The condition used is #if !__GNU

Bug#555168: Request for wheezy-ignore tag: bug#555168 (glibc locale files with license not permitting modification)

Julien Cristau wrote: > Hopefully it won't take too much longer to > sort out, but I don't think there's a point delaying the release (or > deleting existing locale data from the distro) while there's hope of a > resolution. Thanks for looking it over. Makes sense. Jon

Bug#682678: /usr/include/features.h referes to bits/predefs.h, but no "bits" link or dir in /usr/include

# affects many libraries, not just libc reassign 682678 general merge 637232 682678 quit Hi Alex, Alex Adam wrote: > I've tried to build GCC-4.6.2 on my system from sources. > I've got compilation failed with the following error message: > In file included from /usr/include/stdio.h:28:0, >

Bug#555168: Unclear license situation for (e)glibc locales provided by you

Raphael Finkel wrote: > Helge, > > I would be glad to relicense this work in whatever way will give it the > most distribution. I don't want to restrict it, but I would like my > name associated with it. Does that mean something like % This file has been put in the public domain. % You can do

Bug#679172: ls[8213]: segfault in libc-2.11.3.so

Hi Axel, a...@users.sourceforge.net wrote: > Just found this in /var/log/kern.log and /var/log/messages: > > ls[8213]: segfault at 1ebbc787 ip b769aa53 sp bffcbc14 error 4 in > libc-2.11.3.so[b7626000+14] If anything, this would be a symptom of memory corruption or a bug in "ls". Can you r

Bug#673596: NPTL not properly cleaning up threads on SMP systems?

--- debian/changelog(revision 5284) +++ debian/changelog(working copy) @@ -11,6 +11,11 @@ * patches/hurd-i386/libpthread_nort.diff: Add patch to revert upstream librt usage. + [ Jonathan Nieder ] + * patches/any/unsubmitted-tst-eintr1-eagain.diff: new patch to work around

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

tags 673596 + upstream quit Thibaut Girka wrote: > dlfcn/bug-atexit3 is the first to fail (fails to load libstdc++.so.6). Oh, right. glibc doesn't know to look to /lib/$(gcc -print-multiarch) for libraries, so I usually copy libstdc++.so.6 and libgcc_s.so.1 to the build tree by hand so the test

Bug#674412: tcc: undefined symbol '__builtin_expect' on pthread_cleanup_push() call

tags 674412 + upstream notforwarded 674412 quit Hi, Thomas Preud'homme wrote: > Le jeudi 24 mai 2012 14:47:39, vous avez écrit : >> $ tcc -Wall -Wextra thread.c -pthread >> thread.c:10: warning: implicit declaration of function '__builtin_expect' >> tcc: error: undefined symbol '__builtin_expect

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Thibaut Girka wrote: > I couldn't reproduce this because of other failed tests. Which test? If you use LD_LIBRARY_PATH to use the newly built libc and libpthread, does your testcase still reproduce the bug? (It should be possible to see if the intended libs are being picked up with "ldd".) -

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Jonathan Nieder wrote: > # configure > cd glibc > mkdir BUILD > ../configure --prefix=$HOME/opt/glibc Whoops, left out a second "cd". I meant: mkdir glibc/BUILD cd glibc/BUILD ../configure --prefix=$HOME/opt/glibc Sorry for the confusi

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Thibaut Girka wrote: > Well, no, after a quick inspection, it appears the test behaves correctly. > Then, I have no idea why it would fail. Thanks. Ok, a new test to try: # get the source: git clone git://sourceware.org/git/glibc.git # configure cd glibc mkdir BUILD ../configure --prefix

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Hi Thibaut, Thibaut Girka wrote: > I've been bitten by this bug too, and here is what I've gathered: > > tst-eintr1 spawns threads continuously, without joining them, until it > receives a SIGALRM. Thanks for the analysis. If I am reading correctly, tst-eintr1 tries to spawn 11 child threads, o

Bug#674917: libc6-dev: mblen is erroneously marked warn_unused_result

forwarded 674917 http://sourceware.org/PR14176 quit Antti-Juhani Kaijanaho wrote: > However, I've done what you asked. > http://sourceware.org/bugzilla/show_bug.cgi?id=14176 Thanks much. Kind regards, Jonathan -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject

Bug#674917: libc6-dev: mblen is erroneously marked warn_unused_result

tags 674917 + upstream patch quit Hi, Antti-Juhani Kaijanaho wrote: > However, so far as I can see, ignoring the return value of mblen is never a > security problem and is sometimes appropriate (the first call to the function > is often mblen(NULL, 0), the result value of which is usually of no

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

retitle 673596 libc6: tst-eintr1 fails ("tf1: pthread_create failed: Resource temporarily unavailable") quit Philip Ashmore wrote: > ...and here they are< $ ldd build-tree/amd64-libc/nptl/tst-eintr1 > linux-vdso.so.1 => (0x7fff481ff000) > libpthread.so.0 => /lib/x86_64-lin

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Jonathan Nieder wrote: > Do you have access to another machine you could try to reproduce the > problem on? Actually, before then: could you please run the test I outlined before? That is: 1. Find tst-eintr1. It should be somewhere like build-tree/amd64-libc/nptl/tst-eintr1 2.

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Philip Ashmore wrote: > It looks like you're building on i386 - the bug report is for amd64. My bad --- sorry about that. > If someone could tell me the steps, I could provide you with the automated > install script > to set up Debian Wheezy in VMware so it's the same as mine, allowing others t

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

severity 673596 important quit Hi Philip, Philip Ashmore wrote: > Should I attach /var/log/dmesg? Unless you've been running into other problems, I wouldn't bother. I doubt this problem is CPU-specific, though of course I could be wrong. How reproducible is the test failure? You can run test

Bug#673933: eglibc: FTBFS with patch from experimental (hurd-i386/libpthread_clean.diff patches the wrong file)

tags 673933 + patch quit Jonathan Nieder wrote: > The attached patch seems to fix it. Here's the same as a patch against the repo on svn.debian.org. Index: debian/changelog === --- debian/changelog(revision 5255) ++

Bug#673933: eglibc: FTBFS with patch from experimental (hurd-i386/libpthread_clean.diff patches the wrong file)

Source: eglibc Version: 2.13-32 Tags: experimental Justification: will ftbfs with GNU patch (>= 2.6.2) X-Debbugs-Cc: pa...@packages.debian.org Hi, Philip Ashmore wrote[1]: > The wheezy installation failed to build eglibc-2.13-32 with the > following errors

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Philip Ashmore wrote: > .tf1: pthread_create failed: Resource temporarily unavailable > tf1: pthread_create failed: Resource temporarily unavailable That's EAGAIN, which usually would mean some resource limit has been hit (or an out-of-memory condition). Does one of ulimit -a ca

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

Hi Philip, Philip Ashmore wrote: > annexc.out, Error 1 (ignored) > tst-eintr1.out, Error 1 > tst-writev.out, Error 1 > *** > Encountered regressions that don't match expected failures: > tst-eintr1.out, Error 1 What does the tst-eintr1.out file say? Curious, Jonathan -- To UNSUB

Bug#673339: [locales] es_MX has wrong decimal_point and thousands_sep

severity 673339 important quit Carlos C Soto wrote: > Severity: critical This is not critical. [...] > The locales for es_MX in decimal_point and thousands_sep should be > the same as en_US: [...] > This command has inverted the "." and the "," Thanks for reporting, Jonathan -- To UNSUBSCR

Bug#671709: libc6-i386: libc6 no valid name for dpkg as multiarch install on amd64 - error code (2)

reassign 671709 apt 0.8.15.10 forcemerge 665727 671709 quit Hi Thomas, thomas wrote: > Hole:1 http://debian.tu-bs.de/debian/ testing/main libc6-i686 i386 2.13-32 > [1.242 kB] > Es wurden 1.242 kB in 1 s geholt (1.062 kB/s) > Lese Changelogs... Fertig > dpkg: Fehler: --configure benötigt einen g

Bug#564874: manpages: Please ship ld.so manpage

reassign 564874 manpages 3.23-1 quit Simon Paillard wrote: > I concur, but we need agreement of libc-bin maintainers. Reassigning to manpages, since this couldn't be fixed by a change in eglibc alone (or in other words: to unconfuse debbugs[1]). If you think the page is ready already, then plea

Bug#564874: manpages: Please ship ld.so manpage

Michael Kerrisk wrote: > For info: Jonathan Neider, CCed was looking at integrating those > pieces of the Debian libc-bin page that were missing from the upstream > man-pages ld.so.8 page. We did upstream one piece already, but I'm not > sure what Jonathan's current plans are for further work. Lo

Re: [Fwd: Re: eglibc 2.14 for wheezy?]

Hi, Svante Signell wrote: > Hello, I was recommended to forward my question here. What is the > current plan? The wheezy release is not too far away. (Disclaimer: I am not an eglibc maintainer.) It is rather late to get eglibc 2.14 into wheezy, and my best guess is that it probably won't happen

Bug#552561: please provide en_CH locale

Hi, wiekalth...@gmx.de wrote: > [Subject: What is the status?] Please keep in mind that these appear as emails in a crowded inbox, so the subject line can be a good place to put valuable context. > I have similar needs as Martin. Want my system to speak English with > whatever local flavor I li

Bug#634261: iceweasel 5.0 does not start on sparc, bus error

tags 634261 + upstream quit Hi Mike, FYI: Jurij Smakov wrote: > For the record, I do not consider this bug to be RC. As far as I know, > it only manifested itself for iceweasel and only because iceweasel > does really funky things with its symbols. The bug now contains enough > information f

Bug#666043: libc6-dev: unusable due to missing

tags 666043 + moreinfo quit Hi, Raphael Manfredi wrote: > The packaged file does a: > > #include > > but that file is missing from the package, hence the header > cannot be included in programs. $ dpkg-query -S /usr/include/i386-linux-gnu/sys/ucontext.h libc6-dev: /usr/include/i386-

Re: lenny->squeeze: Upgrading locales causes broken en_US.utf8 locale during upgrade

tags 585737 = reassign 660669 locales 2.11.3-3 forcemerge 585737 660669 affects 585737 + upgrade-reports quit Hi Josh, Josh Triplett wrote: > I just upgraded an old system from lenny to squeeze. The upgrade run > included the "locales" package. Early on in the upgrade, apt unpacked > the repla

Bug#660779: ldconfig: should ignore files with names ending in "-gdb.py"

reassign 660779 libstdc++6-4.6-dbg 4.6.2-6 forcemerge 652160 660779 affects 652160 + libc-bin quit Hi Samuel, Samuel Bronson wrote: > ldconfig: /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF > file - it has the wrong magic bytes at the start. > > The file in question is from l

Bug#660526: [PATCH glibc-2.11.y] Re: is incomplete for POSIX 2008

tags 660526 + upstream patch moreinfo quit Hi Petr and Jérémy, Jérémy Compostella wrote: > I apology if this bug has already been reported but I am unable to find > it through the web bug report interface. > > POSIX 2008 requires that expose ssize_t, va_list, and getline > (among others) if _PO

Bug#658278: ld.so segfaults on wrong input

severity 658278 wishlist tags 658278 + moreinfo quit Goswin von Brederlow wrote: > It has a different interpreter in its elf section. Ld.so could check > that to determine wether the elf file is one it should care about. A common use case is testing updated versions of ld.so by running binaries

Bug#659064: libc6 - Includes file in /lib64

Bastian Blank wrote: > On Wed, Feb 08, 2012 at 12:09:31AM +0100, Aurelien Jarno wrote: >> On Wed, Feb 08, 2012 at 12:05:20AM +0100, Bastian Blank wrote: >>> It exists in the filesystem as relict from the old package. >> >> We have a preinst script making sure it is replaced from a symlink to a >>

Bug#659064: libc6 - Includes file in /lib64

Hi Bastian, Bastian Blank wrote: > libc6 includes the file /lib64/ld-linux-x86-64.so.2. It was decided that > this should not happen, because neither dpkg nor any of the bootstrap > tools handles this properly. See #514015 for further informations. libc6 does not contain a /lib64 -> /lib symlink

Re: Missing accept4 for ia64

Jonathan Nieder wrote: > You may want to file a bug report with a patch for udev to Depend on > libc6.1 (>= 2.13-25) [ia64]. See the libc changelog for details. On second thought, since there was a symbols bump, a binnmu of udev against libc6-dev 2.13-25 or later should be enough.

Re: Missing accept4 for ia64

Émeric Maschino wrote: > So, what is thus the "fixed" package version I should wait for? You may want to file a bug report with a patch for udev to Depend on libc6.1 (>= 2.13-25) [ia64]. See the libc changelog for details. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-glibc-req

Re: Missing accept4 for ia64

Aurelien Jarno wrote: > On Sat, Jan 28, 2012 at 04:04:07PM -0600, Jonathan Nieder wrote: >> Aurelien Jarno wrote: >>> Yes, it should probably work. Should I bump the build-dep on >>> linux-libc-dev to a recent version (in that case which version?). >> >>

Re: Missing accept4 for ia64

Aurelien Jarno wrote: > On Sat, Jan 28, 2012 at 09:52:36PM +, Ben Hutchings wrote: >> accept4() was not implemented by Linux on ia64 for a long time. I >> believe eglibc will define the C wrapper automatically when built >> against the updated linux-libc-dev. > > Yes, it should probably work.

Bug#655711: ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd party loader in /lib directory

Hi, venkatesh_pra...@mcafee.com wrote: > Version: 2.13-0ubuntu13 Can you reproduce this with libc-bin from Debian squeeze or sid? If not, this is not the place to report it. Ubuntu bugs are tracked on launchpad. > System having installed with some 3rd party loaders (ld-.so.x) > in /lib direct

Bug#654835: libc/NEWS.Debian: please suggest use of LIBRARY_PATH and CPATH envvars

B and -I to the compiler. + + -- Jonathan Nieder Thu, 05 Jan 2012 19:20:52 -0600 + eglibc (2.13-24) unstable; urgency=low * patches/m68k/cvs-byteswap.diff: fix m68k optimized version of diff --git a/debian/debhelper.in/libc.NEWS b/debian/debhelper.in/libc.NEWS index e069cdc2..cb5f9e7f 1006

Bug#653178: "/bin/cat whatever just segfaults" (Re: Bug#653178: reopen)

Hi Eric, Eric Valette wrote: > reopen #653179 Rather than fiddling with metadata, why not provide some information to help others reproduce or otherwise understand your report? /bin/cat works fine for me. [1] has some hints. Sorry for the trouble, Jonathan [1] http://www.chiark.greenend.org.

Bug#636286: tagging 636286

Thorsten Glaser wrote: > Aurelien Jarno dixit: >> tags 636286 + wontfix > > Uhm, why? If someone working for glibc upstream says that the > locale files produced by the Debian patched version of glibc > are invalid… The wontfix tag has a somewhat complicated role. In practice, it generally means

Bug#653446: ldconfig: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF file

reassign 653446 libstdc++6-4.6-dbg 4.6.2-9 severity 652160 minor merge 652160 653446 quit Julian Andres Klode wrote: > Since some weeks, whenever ldconfig is run during an upgrade, I get > the following warning: > > ldconfig: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF > f

Bug#652356: please use argument-safe bswap macros on all architectures

Aurelien Jarno wrote: > If you are not an m68k porter, you should simply stop to care about > m68k porting issues. There are kinder ways to say that. Thorsten, can you test this patch or arrange for it to be tested? commit fb3ed187 Author: Andreas Schwab Date: Sun Mar 6 19:52:43 2011 +0100

Bug#649164: getconf: missing POSIX_V7_THREADS_CFLAGS, POSIX_V7_THREADS_LDFLAGS variables

Package: libc-bin Version: 2.13-21 Severity: wishlist Justification: POSIX.1-2008 XCU.c99 extended description, table 4-6 Tags: upstream Hi, POSIX says: In addition to the type size programming environments above, all implementations support a multi-threaded programming e

Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

# affects most development libraries, not just libc reassign 648889 general forcemerge 637232 648889 quit Hi Wolfgang, Wolfgang Tichy wrote: > I just tried to comiple some code with the intel compiler and got: > /usr/include/features.h(323): catastrophic error: could not open source file > "bits

Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility

Jonathan Nieder wrote: > Lionel Elie Mamane wrote: >> And I've just checked for overlap by running >> these on the latrace output: [...] > Could you try the analagous checks with strcpy and stpcpy? Ah, I have another idea. Could you try the libc6 package from wheezy

Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility

Hi Lionel, Lionel Elie Mamane wrote: > And I've just checked for overlap by running > these on the latrace output: > > grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) <= > strtonum($5) && strtonum($8) + strtonum($11) >= strtonum($5)) print "overlap: > " $5 " " $8 " " $11 }' > gre

Bug#644990: NEWS.Debian.gz: s/$arch/

Sedat Dilek wrote: > On Fri, Oct 14, 2011 at 9:44 PM, Jonathan Nieder wrote: >> It means that you might want to pass those flags to the compiler. >> The compiler doesn't examine any environment variables, so your >> "export CFLAGS" incantation isn't go

Bug#644990: NEWS.Debian.gz: s/$arch/

Jonathan Nieder wrote: > The compiler doesn't examine any environment variables (Just to be clear, this is a lie. The compiler does examine some environment variables, though CFLAGS is not one of them.) [...] > But what does this have to do with the "" text in libc6-d

Bug#644990: NEWS.Debian.gz: s/$arch/

Sedat Dilek wrote: > I am unsure how to interpret "you might try to pass the following > option to your: -B/usr/lib/ -I/usr/include/"? > > Normally, I would expect to do: > > export CFLAGS="$CFLAGS -B/usr/lib/ -I/usr/include/" > > But in case of gcc-trunk upstream this change impacts: [...] It m

Bug#644990: NEWS.Debian.gz: s/$arch/

Hi Sedat, Sedat Dilek wrote: > /usr/share/doc/libc6/NEWS.Debian.gz says: [...] > you might try to pass the following option to your > compiler: > > -B/usr/lib/$arch -I/usr/include/$arch > > Better use commonly used when talking about multiarch [1] instead: > > -B/usr/lib/

Bug#644986: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

reassign 644986 general severity 644986 critical merge 637232 644986 quit Sedat Dilek wrote: > I played again with CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET by exporting > them. [...] > -B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE} ... > ...does NOT catch the problem with crt*.o files. Last time we

Bug#644986: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

Hi Sedat, Sedat Dilek wrote: > these problems here were already discussed on #multiarch and reported > by me (see for example #636116 or #637218), but still exist. Those look like different bugs. #636116 was about libc6-dev-amd64 failing to unpack! #629819 was about crti.o et al moving to the

Bug#644270: strcoll(): collation sequences of locales unspecified

reassign 644270 manpages-dev 3.32-0.2 retitle 644270 strcoll(3): please make locale(5) easier to find severity 644270 wishlist Hi, Filipus Klutiero wrote: > strcoll(3) explains that: > >> The strcoll() function compares the two strings s1 and s2. It returns an >> integer less than, equal to, or

Bug#644023: FTBFS on kfreebsd-i386

Petr Salinger wrote: > It effectively test return code of > >fprintf (fp, "%2147483648d%2147483648d", 1, 1); > > The printf family returns int and should return number of written bytes. > It therefore cannot exceed MAX_INT. > > But the test tries to print twice entry with width MAX_INT+1. > I

Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)

Robert Millan wrote: > Encountered regressions that don't match expected failures: > bug22.out, Error 1 And what is the content of bug22.out? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive

Bug#641868: alpha: fallocate() in libc6.1 but no declaration in fcntl.h

Hi, Michael Cree wrote: > The fallocate() interface is present in libc6.1 on Alpha as is easily > verified by: [...] > Only the posix_fallocate() interface is declared in the headers as > verified by: [...] > Source package libtorrent FTBFS because of this. Yep, looks like glibc-ports's sysdeps/

Bug#636686: partial upgrade from squeeze to wheezy fails

Adam Heath wrote: > Well, fixing this in apt won't be good enough, as that version won't > be made available in stable. Of course. But it's still an apt bug, seriously. As for the case at hand: the more I think about it, the less the Breaks by libc6 makes sense. In the motivating example Bug#6

Bug#639290: partial upgrade from squeeze to wheezy fails

reassign 639290 apt quit Hi again, Adam Heath wrote: > 639290 says that you can deconfigure perl. That is not possible. Why? I thought the whole point of having a separate perl and perl-base is that perl is not essential. So as an intermediate state during an upgrade, it should be perfectly

Bug#639290: partial upgrade from squeeze to wheezy fails

Hi APT team, Quick puzzle for you. Adam Heath wrote: > E: Could not perform immediate configuration on 'perl'. Please see man > 5 apt.conf under APT::Immediate-Configure for details. (2) > == > > libc6(wheezy) breaks perl << 5.12. perl 5.12 depends on libgdm3. > libgdm3 pre-depends multiarch-su

Bug#639214: eglibc: changes to paths concerning crt1.o, crti.o and crtn.o breaks building LLVM Trunk

reassign 639214 general forcemerge 637232 639214 quit Hi Marc, Marc J. Driftmeyer wrote: > With the most recent changes of moving the object files under > /usr/lib/x86_64-linux-gnu/ the linker to build Clang/LLVM breaks. > > A workaround is to add symlinks for crt1.o, crti.o and crtn.o back > un

Bug#631256: eglibc: ftbfs with binutils-gold: "These critical programs are missing or too old: ld"

tags 631256 + fixed-upstream quit Jonathan Nieder wrote: > with minor changes, it builds but the resulting ld.so > segfaults[*]. Yes! A build with binutils-gold works now (no segfault). Using 25ad0df1 ("Bug fixes for longjmp_chk on sparc", 2011-08-22) with the "Mak

Bug#617759: Thank you (Re: icedove: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc)

Aurelien Jarno wrote: > Fixes > symbols resolution with issues with icedove/iceweasel/iceape. Closes: > #617759. Yes, it works! (Confirmed the bug again with icedove 3.1.12-1, then upgraded and the bug went away.) Thanks, Aurelien. -- To UNSUBSCRIBE, email to debian-glibc-re

Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems

Quick thoughts. Sven Joachim wrote: > +ldfile=$(readlink -e RTLD_SO) > +# Test if libc is of the same architecture as coreutils > +# If not, they almost surely have a multiarch system and we can use > +# the native ELF interpreter > +if ! $ldfile /bin/true 2>/dev/null; then >

Bug#637360: backtrace() doesn't work on armel

Aurelien Jarno wrote: > Backtrace code for ARM EABI has been added in glibc 2.11 [1], and is > based on unwind information. -funwind-tables is therefore necessary to > get it working, and then backtrace() is fully functional. > > I therefore don't see the need to tag this bug as wontfix. Sure,

Bug#637360: backtrace() doesn't work on armel

severity 637360 wishlist retitle 637360 [arm] backtrace() requires unwind information # unlikely to be fixed any time soon tags 637360 + upstream wontfix quit Hi Stéphane, Stéphane Glondu wrote: > #include > > int main() { > void *buffer[100]; > return backtrace(buffer, 100); > }

Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems

Aurelien Jarno wrote: > I don't think we want any manual intervention for this transition. For > the symlink I would prefer not having /lib64 left, as a lot of configure > scripts are actually looking to /lib64 to determine random things. Also > we have just seen that leaving leftover that are not

  1   2   3   >