EGLIBC 2.19 set up (last release branch), EGLIBC trunk now closed

2014-02-07 Thread Joseph S. Myers
to file issues for glibc corresponding to any EGLIBC issues that actually apply to current glibc. -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive

Status of remaining glibc/EGLIBC differences 2013-11-06

2013-11-06 Thread Joseph S. Myers
in the EGLIBC tracker any more, and anyone interested to file issues for glibc corresponding to any EGLIBC issues that actually apply to current glibc. -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble

Status of remaining glibc/EGLIBC differences 2013-10-11

2013-10-11 Thread Joseph S. Myers
, and anyone interested to file issues for glibc corresponding to any EGLIBC issues that actually apply to current glibc. -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas

Phasing out the separate EGLIBC source tree

2013-07-20 Thread Joseph S. Myers
, then remove it from EGLIBC. I do not plan to copy any issues from the EGLIBC tracker to the glibc one; people concerned about particular issues should file corresponding ones in the glibc tracker as needed. -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc

Re: [Patches] Phasing out the separate EGLIBC source tree

2013-07-20 Thread Joseph S. Myers
, and not at all for others - x86 should be considered much like ARM (an architecture with no DFP support in GCC) in this regard. (Ideally, defining __STDC_WANT_DEC_FP__ would cause an error on unsupported architectures.) -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email

Re: [Patches] Phasing out the separate EGLIBC source tree

2013-07-20 Thread Joseph S. Myers
doubt the repository will be going read-only for a couple of years, as that would be after all FSF glibc branches up to and including 2.19 are closed, and right now all of 2.15, 2.16 and 2.17 are open.) -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ

Re: [patch] reduce namespace polloution from sys/ucontext.h on arm

2011-12-20 Thread Joseph S. Myers
On Tue, 20 Dec 2011, peter green wrote: Joseph S. Myers wrote: The most obvious users of these definitions would be (native) GDB and gdbserver - do those still build OK (i.e. include the correct headers to get the definitions they need and not rely on any definitions that were removed

Re: [patch] reduce namespace polloution from sys/ucontext.h on arm

2011-12-19 Thread Joseph S. Myers
? -- Joseph S. Myers jos...@codesourcery.com -- 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/pine.lnx.4.64.1112192002051.2...@digraph.polyomino.org.uk

Bug#582698: [patches] Re: Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported

2010-05-22 Thread Joseph S. Myers
the (partial) fix for GCC PR 7263. I see no reason this should be unacceptable for FSF glibc (though one can never entirely predict how the FSF glibc maintainers will react to a given patch). -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org

Bug#570233: [patches] please add timepps.h

2010-02-26 Thread Joseph S. Myers
, not inline in the header - so meaning that the ABI compatibility issues *do* arise. Even if you provide a separate library, as I'd suggest, making the headers namespace-clean is still a good idea. -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ

Bug#570233: [patches] please add timepps.h

2010-02-26 Thread Joseph S. Myers
fewer than gnome-terminal, but on my system it's still linked with libcap (POSIX.1e capabilities) and libattr (extended attributes), neither of which is part of EGLIBC even though both might be considered to relate to kernel interfaces. -- Joseph S. Myers jos...@codesourcery.com

Re: [patches] [PATCH] Fix pthread_mutex_unlock.man recursive semantic

2009-11-10 Thread Joseph S. Myers
On Sun, 8 Nov 2009, Samuel Thibault wrote: Joseph S. Myers, le Sun 08 Nov 2009 00:42:29 +, a écrit : On Fri, 6 Nov 2009, Samuel Thibault wrote: There is a small error in the pthread_mutex_unlock manpage: as required by the POSIX norm, recursive mutexes do check that its caller

Re: glibc release branch procedures

2009-05-28 Thread Joseph S. Myers
they are first ready for mainline development. I would generally favour being liberal as to what bug fixes are accepted for a release branch (given that they are in mainline first, do not involve ABI/API changes and do not require other target-specific changes). -- Joseph S. Myers jos...@codesourcery.com