Bug#887078: Bug#887886: libc6 from experimental makes vlc crash (even after rebuilding from source)

On 21/01/2018 17:16, Aurelien Jarno wrote: control: forcemerge -1 887078 On 2018-01-21 14:12, Eric Valette wrote: Package: libc6 Version: 2.26.9000+20180108.401311cf-0experimental0 Severity: critical Justification: breaks unrelated software launching vlc crash immediately with sigsegv

Bug#887886: libc6 from experimental makes vlc crash (even after rebuilding from source)

Package: libc6 Version: 2.26.9000+20180108.401311cf-0experimental0 Severity: critical Justification: breaks unrelated software launching vlc crash immediately with sigsegv. Downgrading to unstable makes it work again. -- System Information: Debian Release: buster/sid APT prefers unstable APT

Bug#806910: been bitten by this as well. Prevent me to compile anything that checks G++ in autoconf...

Thanks for the fixes... -- eric

Bug#806695: libc6: Why still working on 2.21 in experimental instead of 2.22?

Package: libc6 Version: 2.21-0experimental4 Severity: wishlist I do see activity in glibc on experimental but still on glibC 2.21. Any reason to not jump at 2.22? -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Archite

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

On 03/01/2012 04:25, Jonathan Nieder wrote: 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

Bug#653178: reopen

reopen #653179 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f02340f.7050...@free.fr

Bug#653178: reopen as the libc6 bug may still be there

reopen #65318 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f00990c.7060...@free.fr

Bug#626457: Thanks for the tip.

I broke my setting with the libc upgrade this morning. But recreating the symbolic links indeed fixed the problem. For those who want a method to rescue: take a netinst iso, or whatever linux rescue or live disk you prefer. Mount the linux disk / and /usr file system somewhere (with debian net

Bug#337056: libc6-i686 always flagged as orphaned by deborphan

Package: libc6-i686 Version: 2.3.5-7 Severity: minor -ptxp-ceva6380:/home/ceva6380# deborphan libc6-i686 r-ptxp-ceva6380:/home/ceva6380# While this is my libc on my system. Can we find a way to mark it as non orphaned even if no packages depends explicitely on it? NB : the problem is that norm

Bug#276062: Please test /usr/include/nptl and /usr/lib/nptl with glibc 2.3.5-1 in experimental

Eric Valette wrote: > GOTO Masanori wrote: > >>Eric, >> >>I put /usr/include/nptl headers and /usr/lib/nptl static libraries >>into glibc 2.3.5-1 which is available in experimental. If you need it >>so much, could you test it? OK I did. It work on a basic

Bug#279423: Please test /usr/include/nptl and /usr/lib/nptl with glibc 2.3.5-1 in experimental

system. This package includes shared versions of the standard C library and the standard math library, as well as many others. Timezone data is also included. No chroot. I'm running this for about two weeks on my two personnal computers and also on my professionnal computer. Thanks for coming

Re: 2.3.4-1 in experimental

Hi, just a few words to say thanks. May I also suggest you to run the open posixtestsuite to see how better is this version of the library compared to old one. Now waiting a static version of NPTL :-) Regards, -- __ / ` Eric Valette /-- __ o

Bug#282091: libc6: pthread_exit called in main exits the whole process even if other threads are running

Package: libc6 Version: 2.3.2.ds1-18 Severity: normal A test program is given in the bug report below. This bug has been fixed upstream in glibc cvs (not even in 2.3.3). -- System Information: Debian Release: 3.1 APT prefers unstable

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

Eric Valette wrote: Here is my report on running posixtestsuite-1.4.3 on two different environments : - The original debian libc-dev using dynamic linking mode but the LinuxThread related include for pthread and rt many to check if the current status does not lead to too much errors

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

Eric Valette wrote: Thanks for responding and clarifying this. So the remainding problems are only : - Performance, - Posix compliance/ different signal behavior, - hability to choose between implementation by knwoledgeable users, I recommend the Open POSIX testsuite. Here is my

Bug#280137: libc6-dev: Cannot access mq_* Posix function

Package: libc6-dev Version: 2.3.2.ds1-18 Severity: normal mqueue.h is missing. Importing the one provided in nptl includes does not work because then it cause unresolved. Found trying to run Open posix testsuite 1.4.3. -- System Information: Debian Release: 3.1 APT prefers unstable APT poli

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

Daniel Jacobowitz wrote: They are binary compatible, in the set of things exported by both, if that's what you're asking. Otherwise providing both at runtime would not work. Thanks for responding and clarifying this. So the remainding problems are only : - Performance, - Posix compliance/ diffe

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

GOTO Masanori wrote: Yes, I think you're correct. I didn't deny your opinion. So I tagged it as wishlist for working future glibc package after sarge. Whishlist for me means : not a bug. I think if/whenever a NPTL implementation has a pthread related structure size differerent than a linuxthre

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

GOTO Masanori wrote: severity 279423 wishlist retitle 279423 libc6-dev: libc6-dev should ship /usr/include/nptl merge 279423 276062 thanks At Wed, 03 Nov 2004 23:03:53 +0100, Eric Valette wrote: Eric Valette wrote: In fact most distributions do exactly the same as Debian with their default

Bug#279970: Please educate debian libc6-dev maintainer

Package: libc6-dev Version: 2.3.2.ds1-18 Severity: wishlist The current maintainer seems more concerned about closing bug report than actually fixing the bugs. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linu

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

Eric Valette wrote: In fact most distributions do exactly the same as Debian with their default headers and dynamic libraries. So because other distrib mades bad choices, Debian must follow. Good point. I will check and report if this is even true latter on. That is not even true : 1) <h

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

Daniel Jacobowitz wrote: On Wed, Nov 03, 2004 at 12:02:29AM +0100, Eric Valette wrote: 2) When linking in dynamic mode, nptl implementation is dynamically chosen while the includes that have been used to compile the program arethe linuxThread ones, This is only true if your kernel supports

Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

Package: libc6-dev Version: 2.3.2.ds1-18 Severity: grave Due implementaion decisions made to have NPTL threads availiable when possible, the actual status of libc6-dev is almost incoherent : 1) The includes related to pthread (pthread.h, semaphores.h, bits/*.h) are the one that b

Bug#276062: Severity downgraded to wishlist : I still did not get any reason why linuxthread is used in static mode

GOTO Masanori wrote: At Tue, 12 Oct 2004 09:41:55 +0200, Eric Valette wrote: I don't mind you change the severity but would like to get an explanation... I think it's good idea to support /usr/lib/nptl - but it's wishlist rathar than important. We plan to support them after sarge

Bug#276062: Severity downgraded to wishlist : I still did not get any reason why linuxthread is used in static mode

I don't mind you change the severity but would like to get an explanation... -- eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#276062: libc6-dev: Different thread model when linking in static mode or dynamic mode on 2.6 kernel

Package: libc6-dev Version: 2.3.2.ds1-17 Severity: important Trying to reduce the memory consuption of a RT process by using static libraries rather than dynamic ones (VmSize 87 Mb -> 35 Mb so _yes_ this is worth doing especially due to the needed mlockall system call) I noticed that the static

Re: NPTL when dynamically linked linuxthread when statically => How to have NPTL with -static ld flags

GOTO Masanori wrote: At Mon, 11 Oct 2004 15:17:33 +0200, Eric Valette wrote: I'm trying to port a soft RT Posix Application from LynxOS to Linux 2.6. Application works great but due to dynamic libraries inefficencies when mlockall is used, I need to link statically (For those inter

NPTL when dynamically linked linuxthread when statically => How to have NPTL with -static ld flags

ng ps ax that in the dynamic case I have a single process with 9 threads and in the other case 9 process as if I was using linuxthread. Is there anything special to do? Should I open a bug to libc6-dev -- __ / ` Eric Valette /-- __ o _. 6 rue Pa

Bug#218516: linux-kernel-headers: Check for symbolic link before installing

Eric Valette wrote: Because Sarge supports NPTL when using 2.6 kernels, and that requires 2.6 headers to be useful. A number of other applications can take advantage of 2.6 features there now. NPTL is fine mostly for servers. But I guess a number of user mode driver for average people will

Bug#218516: linux-kernel-headers: Check for symbolic link before installing

e and the discussion. -- __ / ` Eric Valette /-- __ o _. 6 rue Paul Le Flem (___, / (_(_(__ 35740 Pace Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76 E-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a sub

Bug#218516: linux-kernel-headers: Check for symbolic link before installing

Daniel Jacobowitz wrote: On Sat, Nov 01, 2003 at 10:23:09PM +0100, Eric Valette wrote: Daniel Jacobowitz wrote: Come on, there are a dozen FAQs explaining this. The kernel headers used to compile user space applications MUST MATCH THE HEADERS THAT GLIBC WAS COMPILED AGAINST. Period. If you

Bug#218516: linux-kernel-headers: Check for symbolic link before installing

, expects others or at least let people do things by checking *needed* symbolic links... -- __ / ` Eric Valette /-- __ o _. 6 rue Paul Le Flem (___, / (_(_(__ 35740 Pace Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76 E

Bug#218516: linux-kernel-headers: Check for symbolic link before installing

Package: linux-kernel-headers Version: 2.5.999-test7-bk-5 Severity: normal To compile some apps, I add to use recent kernel headers and thus linked by hand asm,scsi,linux using symbolic links directly to the real linux includes. Installing the linux-kernel-headers packages screwed my real kerne