| Summary: | localedata: add copyright disclaimer to locale files | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Thorsten Glaser <tg> |
| Component: | localedata | Assignee: | GNU C Library Locale Maintainers <libc-locales> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | cjlhomeaddress, fweimer, glibc-bugs, jrnieder, pasky |
| Priority: | P3 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | 2.24 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
Thorsten Glaser
2010-01-23 16:26:57 UTC
I'm not going to do any of that. The licenses are all fine with me. If somebody has problems they have to do the work. Work in progress is being tracked at http://www.helgefjell.de/debianitem.php?name=bug555168 As someone working on several new locales, it would help if you could provide an example copyright line for the file header that would be considered "ideal". As long as it’s not an explicit Public Domain (which is probably illegal), much would be fine with me. For example, something like this: Copyright © 2010, 2011, 2012 → Foo M. Bar <fbar@baz.org> This locale information is available under any Open Source licence approved by the OSI, at your choice. (Possibly also all OKFN approved licences, if you feel like that.) (In reply to comment #4) > As long as it’s not an explicit Public Domain (which is probably > illegal), much would be fine with me. Heh, I was about to post the following: | I'm fond of | | % This file has been put in the public domain. | % You can do whatever you want with this file. | % | % Author: Chris Leonard | | Some[*] might object that under some systems of law, there is no such | thing as putting a work in the public domain. These people would be | right. Luckily the above wording makes the intent clear and | unambiguous enough that reasonable courts recognize it as a license | grant. | | [*] http://www.rosenlaw.com/lj16.htm | Rebuttal: http://cr.yp.to/publicdomain.html | | If you want to dodge that issue, here's another reasonable way to go: | | % Copyright © 2012 Chris Leonard | % License: Zlib <http://www.zlib.net/zlib_license.html> Thorsten's "any OSI-approved license" is fine, too. Even something that requires reproducing a disclaimer of warranty like the LGPL, GPL, Expat license, or a two-clause BSD-style license is fine, though it seems silly for locale data. Explicit PD alone is *not* enough, it's non-free: it lacks an explicit copyright licence, and since the Berne Convention, all works are automatically under copyright protection. Saying a work is PD isn't possible in all jurisdictions. If you absolutely must insist on PD, I really insist on you including a paragraph similar to the following too: .\" In countries where the Public Domain status of the work may not be .\" valid, its primary author hereby grants a copyright licence to the .\" general public to deal in the work without restriction and permis- .\" sion to sublicence derivates under the terms of any (OSI approved) .\" Open Source licence. (In reply to comment #6) > Explicit PD alone is *not* enough, it's non-free: it lacks an explicit > copyright licence, and since the Berne Convention, all works are automatically > under copyright protection. Saying a work is PD isn't possible in all > jurisdictions. > > If you absolutely must insist on PD, I really insist on you including a > paragraph similar to the following too: > > .\" In countries where the Public Domain status of the work may not be > .\" valid, its primary author hereby grants a copyright licence to the > .\" general public to deal in the work without restriction and permis- > .\" sion to sublicence derivates under the terms of any (OSI approved) > .\" Open Source licence. If "Public Domain" like is a goal, is there any problem with CC-zero http://creativecommons.org/publicdomain/zero/1.0/ or does CC-0 fail to overcome the absense of public domain status in certain juridictions? CC0 would be fine, but OSI has decided to not approve it at the moment. People raised concerns about things like patent grants, and it was decided to further discuss, especially as CC is in the process of working on the next version of their other licences at the moment, and to revisit that later. (For what it’s worth, I voted in favour of approving CC0.) As long as only things like FSF and DFSG compatibility are a goal, that shouldn’t stop you, but having OSI approval has, in the past, helped any sort of licencing issue. Now, I’d suggest https://www.mirbsd.org/MirOS-Licence.htm which *is* OSI approved *and* FSF and DFSG compatible *and* can be used for code, data and any other kind of copyrightable work. (Disclaimer: that’s mine, so I’m biased. Although I’ve published criteria a lawyer-written copycenter-style licence must fulfil for me to disrecommend this one in favour of the new one.) (In reply to comment #7) > If "Public Domain" like is a goal, is there any problem with CC-zero > > http://creativecommons.org/publicdomain/zero/1.0/ These are matters of taste. Practically speaking, any free software license is probably line. Any GPL-compatible license is certainly fine. I can't stop you, but CC-zero is a pain in the neck because its text is very long. Is "Public Domain"-like your goal? Anyway, we've gone off-topic for this bugtracker --- feel free to contact me and Thorsten by email and cc some mailing list of your choice and we can guide you through the process of choosing a license that matches your intent. If you just want a default for locales in glibc, LGPL-2.1+ ("the license of glibc") is probably what most people were assuming the locales already had. A license notice can look like this: % Copyright © 2012, Chris Leonard % This file is free software; you can redistribute it and/or modify % it under the terms of the GNU Lesser General Public License; either % version 2.1 of the License, or (at your option) any later version. I'm sorry, I didn't realize the presence of this bug earlier. We have made some research regarding this on the mailing list some time ago and this is currently the opinion of FSF on the matter: http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html I.e., locale data is not copyrightable, therefore it cannot be covered by any licence and that is also the reason we do not require copyright assignment paperwork from the locale authors. If you (e.g. Debian project) disagree, I encourage you to contact copyright-clerk@fsf.org or SFLC for further discussions. For us developers, this situation really is the best outcome since no paperwork is needed, I'd say. My opinion is that the outcome of this bug should be removal of licence notices (and "copyright" notices) from all localedata files to clear up any possible confusion - comments? (Which is something I'm not likely to engage myself with as my localedata TODO backlog is sufficiently long already, but maybe it is important enough for some downstream projects like Debian to contribute such a patch, if they share this view?) (In reply to comment #10) > I'm sorry, I didn't realize the presence of this bug earlier. We have made > some research regarding this on the mailing list some time ago and this is > currently the opinion of FSF on the matter: > > http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html > > I.e., locale data is not copyrightable, therefore it cannot be covered by any > licence and that is also the reason we do not require copyright assignment > paperwork from the locale authors. I guess one approach would be to scrub all the comments out of these files so all that is left is the locale data? Though I wouldn't be too thrilled with that. Indeed, the concern was raised in Debian (I stumbled upon it), so the SFLC/FSF opinion is not enough to close this “as is”. However, if the information from the mail you linked is correct, and the data really consists only of uncopyrightable information, I personally (not speaking for Debian) believe your way of resolving this (by removing the notices; I’d notify the people involved though) is valid. Jonathan, simply commenting the data does not necessarily add enough “work” to fall under Copyright protection. /me looks at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=wo_SN;att=1;bug=555168 for example, now This example indeed looks uncopyrightable (but the notion of “being put into PD by its author” is offensive). If the others are like this, I hope Debian will accept the resolution that the problem is not in the inconsistent notices but that there have been notices put on such data at all. (Note, IANAL, and I don’t speak for the Debian glibc maintainers or ftpmasters or legal people.) Hi Eben et al, Petr Baudis wrote: > I'm sorry, I didn't realize the presence of this bug earlier. We have made some > research regarding this on the mailing list some time ago and this is currently > the opinion of FSF on the matter: > > http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html > > I.e., locale data is not copyrightable, therefore it cannot be covered by any > licence and that is also the reason we do not require copyright assignment > paperwork from the locale authors. > > If you (e.g. Debian project) disagree, I encourage you to contact > copyright-clerk@fsf.org or SFLC for further discussions. For us developers, > this situation really is the best outcome since no paperwork is needed, I'd > say. My opinion is that the outcome of this bug should be removal of licence > notices (and "copyright" notices) from all localedata files to clear up any > possible confusion - comments? Legal question for you. Along with everything else it contains, the GNU C library provides a collection of locale data. Localedata files include basic information about how programs should interact with users in a particular area: currency symbols, paper size, which encoding to use for text files, translations for "yes" and "no", and other details like that. You can find the glibc locales in the localedata/locales directory of glibc: http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales For example, the English locale for the United States is available from the following address. http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US Since this is mostly factual information without much creative content, no one paid much mind to its license. Many locales permit use, distribution, and commercial use without permitting modification: # Distribution and use is free, also for # commercial purposes. Most notably, the POSIX locale contains that notice. Some are more philosophical: % Distribution and use is Josh Triplett (cc-ed) noticed this in 2009 and reported it to the Debian project[1]. We are concerned that although these files do not contain much creative content, they do contain some, for example in their comments. We are generally not lawyers and do not know what does and doesn't fall under copyright protection in the United States and elsewhere. It is important for it to be very clear to both us and our users what their rights are. Helge (cc-ed) has taken a survey of authors of locales with the notice that doesn't permit modification to find what license terms they intend. Some findings: - many locale authors expected that, as part of glibc, these would have the same license as glibc (LGPL-2.1+) - they did not intend to forbid modification, and the notice was propagated from the POSIX locale by copy and paste. - when asked what terms they would like going forward for their work, most prefer "public domain", followed by LGPL and GPL. You can find a summary of Helge's efforts at [2], and the actual emails are at [1]. Unlike most of glibc, the FSF has not historically required copyright assignment for these files. Independently of the above investigation, they were recently asked about and reaffirmed this position[3]: Well that was fast. The SFLC said that this type of thing isn't copyrightable, and that paperwork isn't really necessary. So we should be good to go. Thank you so much for all your help. Questions: - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain copyright notices. Are we legally permitted to remove the notices or to change them to say "Authors: ..."? - Suppose I wanted to add the text "You may freely use, modify, distribute, and relicense this file" to each of the locale data files, to make it completely clear that users are free to incorporate text from them into differently licensed works. Would that be legally permissible? Would it be accurate? Is there any reason not to do it? - When locale authors have stated a preferred license, is there value in documenting that, or would it be counterproductive? - If the legal heir to some author of many locales wants to be really nasty, what is the worst they can do on the basis of this contribution? Thanks in advance for looking this over. Sincerely, Jonathan [1] http://bugs.debian.org/555168 [2] http://www.helgefjell.de/debianitem.php?name=bug555168 [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html Hmm, I contributed a number of locales. I always assumed that there was a copyright to each of them.
I do hold a masters in legislate law.
In my work, there was a considerable amount of labour. My initial work was about 100 pages for
the POSIX standard 1003.2 back in 1993. The expression was quite inventive at the time (IMHO)
and it had a number of facilities, such as being able to be run in many character sets,
it was character set independent - which was a novelty then and interesting, because
we has so many charsets then, and not almost just UTF8 as of today. It was 20 years ago!
Also the machinery had an elaborate set of character names that had had quite some design
work for it to be mnemnoninc. The sorting was an innovative way of sorting almost
all of the characters (in use at that time) which had never been done before.
There was quite some work in getting the data for each country and language, and
also to get interested parties to agree on the data.
The system with locales and charmaps and repertoiremaps itself was also quite inventive.
And just getting it to compile was also some effort.
But then I attached a licence to it that was not compatible with OSI definitions.
I actually think the locales preceded the OSI defs in time. I wrongly thought that I
should be a kind of maste editor of all of the data, this did not work out.
I am happy with what came out of it, and all the activity and involvement from all over
the world on the glibc localedef data. I recently stated that all of the data I have
contributed is released under GPL v2. I hope this solves some problems.
With my law background I think is is not fair to say the there is no
work height in the data. I don't care too much for my own work wrt. the licences,
My aim was that the data and the work should be used, and also to maintain some quality
to the work. The data should not become flawed. The current scheme with glibc is a
good way to ensure that - but I did not envisage that when I wrote the specs
and the license.
best regards
Keld
On Sun, Jul 15, 2012 at 07:05:10PM +0000, jrnieder at gmail dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
>
> --- Comment #13 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-15 19:05:10 UTC ---
> Hi Eben et al,
>
> Petr Baudis wrote:
>
> > I'm sorry, I didn't realize the presence of this bug earlier. We have made some
> > research regarding this on the mailing list some time ago and this is currently
> > the opinion of FSF on the matter:
> >
> > http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
> >
> > I.e., locale data is not copyrightable, therefore it cannot be covered by any
> > licence and that is also the reason we do not require copyright assignment
> > paperwork from the locale authors.
> >
> > If you (e.g. Debian project) disagree, I encourage you to contact
> > copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
> > this situation really is the best outcome since no paperwork is needed, I'd
> > say. My opinion is that the outcome of this bug should be removal of licence
> > notices (and "copyright" notices) from all localedata files to clear up any
> > possible confusion - comments?
>
> Legal question for you.
>
> Along with everything else it contains, the GNU C library provides a
> collection of locale data. Localedata files include basic information
> about how programs should interact with users in a particular area:
> currency symbols, paper size, which encoding to use for text files,
> translations for "yes" and "no", and other details like that. You can
> find the glibc locales in the localedata/locales directory of glibc:
>
> http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
>
> For example, the English locale for the United States is available
> from the following address.
>
>
> http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US
>
> Since this is mostly factual information without much creative
> content, no one paid much mind to its license. Many locales permit
> use, distribution, and commercial use without permitting modification:
>
> # Distribution and use is free, also for
> # commercial purposes.
>
> Most notably, the POSIX locale contains that notice. Some are more
> philosophical:
>
> % Distribution and use is
>
> Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
> Debian project[1].
>
> We are concerned that although these files do not contain much
> creative content, they do contain some, for example in their comments.
> We are generally not lawyers and do not know what does and doesn't
> fall under copyright protection in the United States and elsewhere.
> It is important for it to be very clear to both us and our users what
> their rights are.
>
> Helge (cc-ed) has taken a survey of authors of locales with the notice
> that doesn't permit modification to find what license terms they
> intend. Some findings:
>
> - many locale authors expected that, as part of glibc, these
> would have the same license as glibc (LGPL-2.1+)
>
> - they did not intend to forbid modification, and the notice was
> propagated from the POSIX locale by copy and paste.
>
> - when asked what terms they would like going forward for their work,
> most prefer "public domain", followed by LGPL and GPL.
>
> You can find a summary of Helge's efforts at [2], and the actual
> emails are at [1].
>
> Unlike most of glibc, the FSF has not historically required copyright
> assignment for these files. Independently of the above investigation,
> they were recently asked about and reaffirmed this position[3]:
>
> Well that was fast. The SFLC said that this type of thing isn't
> copyrightable, and that
> paperwork isn't really necessary. So we should be good to go. Thank you so
> much for all your
> help.
>
> Questions:
>
> - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
> copyright notices. Are we legally permitted to remove the
> notices or to change them to say "Authors: ..."?
>
> - Suppose I wanted to add the text "You may freely use, modify,
> distribute, and relicense this file" to each of the locale data
> files, to make it completely clear that users are free to
> incorporate text from them into differently licensed works. Would
> that be legally permissible? Would it be accurate? Is there any
> reason not to do it?
>
> - When locale authors have stated a preferred license, is there value
> in documenting that, or would it be counterproductive?
>
> - If the legal heir to some author of many locales wants to be really
> nasty, what is the worst they can do on the basis of this
> contribution?
>
> Thanks in advance for looking this over.
>
> Sincerely,
> Jonathan
>
> [1] http://bugs.debian.org/555168
> [2] http://www.helgefjell.de/debianitem.php?name=bug555168
> [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
Hi Keld, Keld Simonsen wrote[1]: > Hmm, I contributed a number of locales. I always assumed that there was a > copyright to each of them. > I do hold a masters in legislate law. [lots of helpful background snipped, including the intent of the original notice] Thanks much for this. I'm cc-ing the SFLC since I'm not sure they automatically receive mails to that bug tracker. My guess is that the FSF's concerns that prompted the "this type of thing isn't copyrightable" answer were USA-centric. If I remember correctly, in some jurisdictions outside the United States, the eligibility of a work for copyright is based on the amount of work put into it (as you remind me), while in the United States it's based on a concept of creativity. (For the curious: I personally would be happiest if the FSF would continue not to care about these works' copyright while everyone else would consider them as possibly copyrighted. That way there is no need for copyright assignment --- less paperwork! --- but there would be no excuse not to follow the usual free software practice of documenting the explicit permission grants the authors provide.) Jonathan [1] http://sourceware.org/PR11213#c14 On Sun, Jul 15, 2012 at 08:13:31PM -0500, Jonathan Nieder wrote:
> Hi Keld,
>
> Keld Simonsen wrote[1]:
>
> > Hmm, I contributed a number of locales. I always assumed that there was a
> > copyright to each of them.
> > I do hold a masters in legislate law.
> [lots of helpful background snipped, including the intent of the
> original notice]
>
> Thanks much for this. I'm cc-ing the SFLC since I'm not sure they
> automatically receive mails to that bug tracker.
>
> My guess is that the FSF's concerns that prompted the "this type of
> thing isn't copyrightable" answer were USA-centric. If I remember
> correctly, in some jurisdictions outside the United States, the
> eligibility of a work for copyright is based on the amount of work put
> into it (as you remind me), while in the United States it's based on a
> concept of creativity.
I claim that there is a lot of creativity in how the locales are written, at least
the big ones. As said one of my intial works were 100 pages of the POSIX.2 standard.
And then the locales grew even further, with the advent of full ISO 10646 (Unicode)
coverage and ISO TR 14652 extra categories. There is a lot of design and ideas,
and a lot of design criteria in the locales. Including a number of theoretical landmarks,
and something that could have been patentetd, if somebody were inclined to do such nasty things:-)
And IMHO that has resulted in a system that still has a number of advantages over
what big players in the market have done for i18n.
And then there is compilation copyright according to the Berne convention - maybe you
don't hold copyright on the data, but you hold copyright on the presentation on it and the
collection of the combination of the data.
I would say in juridical terms it would not be safe to assume that there is no copyright on
the locales (and charmaps and repertoiremaps).
Best regards
keld
Keld, I certainly agree that there is a lot of creativity in the way you designed the locales specification. However, to me that would imply a copyright on the specification and copyright on the implementation. Individual localedata files that simply follow the pre-defined format and contain commonly known facts seem to be a different matter to me? The compilation copyright seems like a more serious issue. (Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm looking to a statement from someone at FSF/SFLC.) Keld, while you may have had a lot of “sweat of brow”, in the end, the locale data (in the one file I looked at) is mere fact, and there is, basically, only one way to express such facts using the format glibc expects. This is, at least, under the EU interoperability directive, not copyrightable (neither are *.h files, unless they include insane amounts of inline functions, by the way). As for the USA, you probably know that better than I do, but the work, while it may have cost you a lot of creativity, is mostly “sweat of brow”, to express the fact that way. You may have designed the interface, the character naming convention, etc. but these are interfaces, not works in the sense of copyright. I really do not want you to lose any attribution of that, but I don’t believe the (one file I looked at with) locale information as shown is not copyrightable. “something that could have been patentetd”[sic] is of different scope than copyright relevant work. I also fear you could probably have patented it, but not put it under copyright protection. (Jonathan, mere effort is also not enough in Germany, although USA’s “sweat of brow” doctrine is a tad stronger. Still, we’re facing interoperability interfaces here, and mere fact; the currency of the USA is the Dollar, no matter what.) The presentation and combination of the data may, may, be affected by copyright or even database law, true. I guess SFLC and, if possible, international lawyers could have a look at that. I laud your attempt to keep quality, but IMHO, using legal matters for that is not the way to go. You could run a “locale data repository”, from which e.g. glibc could then pull, for that, like tzdata. On Mon, Jul 16, 2012 at 11:44:25AM +0000, pasky at ucw dot cz wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
>
> --- Comment #17 from Petr Baudis <pasky at ucw dot cz> 2012-07-16 11:44:25 UTC ---
> Keld, I certainly agree that there is a lot of creativity in the way you
> designed the locales specification. However, to me that would imply a copyright
> on the specification and copyright on the implementation. Individual localedata
> files that simply follow the pre-defined format and contain commonly known
> facts seem to be a different matter to me?
>
> The compilation copyright seems like a more serious issue.
>
> (Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm
> looking to a statement from someone at FSF/SFLC.)
I did not create the original POSIX specification of locale and charmap formats,
one of the main people behind that was Gary Miller, and for the sorting Greger Leijonhufvud.
I was the main contributor for the ISO TR 14652 extensions.
Anyway what I wrote for POSIX.2 was the localedata - not the specification of the formats.
This was what later became the da_DK and the i18n locales - that is pure localedata data.
And there was a lot of design and creativity in that. So it is not just the design
that has work height - also the *data* has.
Then filling in data in the locale format - how much work height is there in that?
I don't know. I think it may be that same problem of how much creativity there is in
providing patches in general to OSS. Is it just a spelling creation? Or what?
I once provided a patch of just 1 line to the Linux kernel. It took quite some research and
some imagnation how to do it and development of new of theory,
and I probably could have patented that mechanism.
In some cases that patch could speed up performance with 50 %
So you cannot judge work height by the size of the contribution.
best regards
keld
On Mon, Jul 16, 2012 at 01:13:31PM +0000, tg at mirbsd dot de wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=11213 > > --- Comment #18 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-16 13:13:31 UTC --- > Keld, while you may have had a lot of ???sweat of brow???, in the end, the locale > data (in the one file I looked at) is mere fact, and there is, basically, only > one way to express such facts using the format glibc expects. Yes, some of the locales are stright forward. But if you look at the whole combination of a locale, with the LC_COLLATE, the LC_CTYPE, and the transliteration specs, there is not only sweat in it but a lot of decisions. Even the LC_MESSAGES data for yes and no contains a number of variations to consider. And even the LC_TIME has some tricks. The choices is a common subject we talk about on the localedata reflector, because there are different ways of doing a lot of things in the locale data. And when there is choice, there is creativity and work height. > This is, at > least, under the EU interoperability directive, not copyrightable (neither are > *.h files, unless they include insane amounts of inline functions, by the way). > As for the USA, you probably know that better than I do, but the work, while it > may have cost you a lot of creativity, is mostly ???sweat of brow???, to express > the fact that way. You may have designed the interface, the character naming > convention, etc. but these are interfaces, not works in the sense of copyright. > I really do not want you to lose any attribution of that, but I don???t believe > the (one file I looked at with) locale information as shown is not > copyrightable. (maybe too many negations here - but I think I know what you mean.) I think there is differences of what level of work height that is needed for it to be copyrightable in different countries. but I would be astonished if say 1000 lines of data with a number of serious design decisions on the solutions did not enjoy copyright in any country (under the Berne convention).. I do think locales per se are works. They are freestanding items, that are supposed then to work toghether with other parts to make a functioning system. > ???something that could have been patentetd???[sic] is of different scope than > copyright relevant work. I also fear you could probably have patented it, but > not put it under copyright protection. (Jonathan, mere effort is also not > enough in Germany, although USA???s ???sweat of brow??? doctrine is a tad stronger. > Still, we???re facing interoperability interfaces here, and mere fact; the > currency of the USA is the Dollar, no matter what.) :-) best regards keld I think there is something to the analogy that "glibc locale" is to "glibc" as "PO file" is to "YOUR_PACKAGE_NAME_HERE". Similar purposes are served in both cases, with specific, properly-formatted information being supplied by the localizer to allow usage of (in this case glibc) in their language. The common licensing / copyright header lines in a PO file are: # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR OF THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. This is certainly most localizers expectation of how their work will be licensed and they will credited, it stands to reason that glibc locale developers will have similar expectations, but that is merely opinion and not in any way a legal argument. On 07/15/2012 09:13 PM, Jonathan Nieder wrote: > Hi Keld, > > Keld Simonsen wrote[1]: > >> Hmm, I contributed a number of locales. I always assumed that there was a >> copyright to each of them. >> I do hold a masters in legislate law. > [lots of helpful background snipped, including the intent of the > original notice] > > Thanks much for this. I'm cc-ing the SFLC since I'm not sure they > automatically receive mails to that bug tracker. > > My guess is that the FSF's concerns that prompted the "this type of > thing isn't copyrightable" answer were USA-centric. If I remember > correctly, in some jurisdictions outside the United States, the > eligibility of a work for copyright is based on the amount of work put > into it (as you remind me), while in the United States it's based on a > concept of creativity. > > (For the curious: I personally would be happiest if the FSF would > continue not to care about these works' copyright while everyone else > would consider them as possibly copyrighted. That way there is no > need for copyright assignment --- less paperwork! --- but there would > be no excuse not to follow the usual free software practice of > documenting the explicit permission grants the authors provide.) > > Jonathan > > [1] http://sourceware.org/PR11213#c14 The Software Freedom Law Center has received an email from you sent to help@softwarefreedom.org. We look forward to helping you in any way we can, but before we can do that we need to make sure that you understand that your email to us does not create an attorney-client relationship with us and any information you send us will not be considered confidential or privileged. If you understand that, just reply to this message by keeping the text of this paragraph and adding "Understood" and we will respond to your email shortly. However, if your message contains any information that you would like to be considered confidential or privileged (in other words, you do not want it to be considered public information), please respond to this message with "Delete my message" or just "Delete." We understand that this procedure may seem burdensome, but it is required by law in order to ensure your rights and the rights of our clients are protected. On 07/15/2012 03:04 PM, Jonathan Nieder wrote: > Hi Eben et al, > > Petr Baudis wrote: > >> I'm sorry, I didn't realize the presence of this bug earlier. We have made some >> research regarding this on the mailing list some time ago and this is currently >> the opinion of FSF on the matter: >> >> http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html >> >> I.e., locale data is not copyrightable, therefore it cannot be covered by any >> licence and that is also the reason we do not require copyright assignment >> paperwork from the locale authors. >> >> If you (e.g. Debian project) disagree, I encourage you to contact >> copyright-clerk@fsf.org or SFLC for further discussions. For us developers, >> this situation really is the best outcome since no paperwork is needed, I'd >> say. My opinion is that the outcome of this bug should be removal of licence >> notices (and "copyright" notices) from all localedata files to clear up any >> possible confusion - comments? > > Legal question for you. > > Along with everything else it contains, the GNU C library provides a > collection of locale data. Localedata files include basic information > about how programs should interact with users in a particular area: > currency symbols, paper size, which encoding to use for text files, > translations for "yes" and "no", and other details like that. You can > find the glibc locales in the localedata/locales directory of glibc: > > http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales > > For example, the English locale for the United States is available > from the following address. > > http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US > > Since this is mostly factual information without much creative > content, no one paid much mind to its license. Many locales permit > use, distribution, and commercial use without permitting modification: > > # Distribution and use is free, also for > # commercial purposes. > > Most notably, the POSIX locale contains that notice. Some are more > philosophical: > > % Distribution and use is > > Josh Triplett (cc-ed) noticed this in 2009 and reported it to the > Debian project[1]. > > We are concerned that although these files do not contain much > creative content, they do contain some, for example in their comments. > We are generally not lawyers and do not know what does and doesn't > fall under copyright protection in the United States and elsewhere. > It is important for it to be very clear to both us and our users what > their rights are. > > Helge (cc-ed) has taken a survey of authors of locales with the notice > that doesn't permit modification to find what license terms they > intend. Some findings: > > - many locale authors expected that, as part of glibc, these > would have the same license as glibc (LGPL-2.1+) > > - they did not intend to forbid modification, and the notice was > propagated from the POSIX locale by copy and paste. > > - when asked what terms they would like going forward for their work, > most prefer "public domain", followed by LGPL and GPL. > > You can find a summary of Helge's efforts at [2], and the actual > emails are at [1]. > > Unlike most of glibc, the FSF has not historically required copyright > assignment for these files. Independently of the above investigation, > they were recently asked about and reaffirmed this position[3]: > > Well that was fast. The SFLC said that this type of thing isn't copyrightable, and that > paperwork isn't really necessary. So we should be good to go. Thank you so much for all your > help. > > Questions: > > - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain > copyright notices. Are we legally permitted to remove the > notices or to change them to say "Authors: ..."? > > - Suppose I wanted to add the text "You may freely use, modify, > distribute, and relicense this file" to each of the locale data > files, to make it completely clear that users are free to > incorporate text from them into differently licensed works. Would > that be legally permissible? Would it be accurate? Is there any > reason not to do it? > > - When locale authors have stated a preferred license, is there value > in documenting that, or would it be counterproductive? > > - If the legal heir to some author of many locales wants to be really > nasty, what is the worst they can do on the basis of this > contribution? > > Thanks in advance for looking this over. > > Sincerely, > Jonathan > > [1] http://bugs.debian.org/555168 > [2] http://www.helgefjell.de/debianitem.php?name=bug555168 > [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html The Software Freedom Law Center has received an email from you sent to help@softwarefreedom.org. We look forward to helping you in any way we can, but before we can do that we need to make sure that you understand that your email to us does not create an attorney-client relationship with us and any information you send us will not be considered confidential or privileged. If you understand that, just reply to this message by keeping the text of this paragraph and adding "Understood" and we will respond to your email shortly. However, if your message contains any information that you would like to be considered confidential or privileged (in other words, you do not want it to be considered public information), please respond to this message with "Delete my message" or just "Delete." We understand that this procedure may seem burdensome, but it is required by law in order to ensure your rights and the rights of our clients are protected. On 07/16/2012 04:55 AM, Keld Simonsen wrote: > On Sun, Jul 15, 2012 at 08:13:31PM -0500, Jonathan Nieder wrote: >> Hi Keld, >> >> Keld Simonsen wrote[1]: >> >>> Hmm, I contributed a number of locales. I always assumed that there was a >>> copyright to each of them. >>> I do hold a masters in legislate law. >> [lots of helpful background snipped, including the intent of the >> original notice] >> >> Thanks much for this. I'm cc-ing the SFLC since I'm not sure they >> automatically receive mails to that bug tracker. >> >> My guess is that the FSF's concerns that prompted the "this type of >> thing isn't copyrightable" answer were USA-centric. If I remember >> correctly, in some jurisdictions outside the United States, the >> eligibility of a work for copyright is based on the amount of work put >> into it (as you remind me), while in the United States it's based on a >> concept of creativity. > > I claim that there is a lot of creativity in how the locales are written, at least > the big ones. As said one of my intial works were 100 pages of the POSIX.2 standard. > And then the locales grew even further, with the advent of full ISO 10646 (Unicode) > coverage and ISO TR 14652 extra categories. There is a lot of design and ideas, > and a lot of design criteria in the locales. Including a number of theoretical landmarks, > and something that could have been patentetd, if somebody were inclined to do such nasty things:-) > And IMHO that has resulted in a system that still has a number of advantages over > what big players in the market have done for i18n. > > And then there is compilation copyright according to the Berne convention - maybe you > don't hold copyright on the data, but you hold copyright on the presentation on it and the > collection of the combination of the data. > > I would say in juridical terms it would not be safe to assume that there is no copyright on > the locales (and charmaps and repertoiremaps). > > Best regards > keld The Software Freedom Law Center has received an email from you sent to help@softwarefreedom.org. We look forward to helping you in any way we can, but before we can do that we need to make sure that you understand that your email to us does not create an attorney-client relationship with us and any information you send us will not be considered confidential or privileged. If you understand that, just reply to this message by keeping the text of this paragraph and adding "Understood" and we will respond to your email shortly. However, if your message contains any information that you would like to be considered confidential or privileged (in other words, you do not want it to be considered public information), please respond to this message with "Delete my message" or just "Delete." We understand that this procedure may seem burdensome, but it is required by law in order to ensure your rights and the rights of our clients are protected. On 07/16/2012 04:55 AM, Keld Simonsen wrote: > On Sun, Jul 15, 2012 at 08:13:31PM -0500, Jonathan Nieder wrote: >> Hi Keld, >> >> Keld Simonsen wrote[1]: >> >>> Hmm, I contributed a number of locales. I always assumed that there was a >>> copyright to each of them. >>> I do hold a masters in legislate law. >> [lots of helpful background snipped, including the intent of the >> original notice] >> >> Thanks much for this. I'm cc-ing the SFLC since I'm not sure they >> automatically receive mails to that bug tracker. >> >> My guess is that the FSF's concerns that prompted the "this type of >> thing isn't copyrightable" answer were USA-centric. If I remember >> correctly, in some jurisdictions outside the United States, the >> eligibility of a work for copyright is based on the amount of work put >> into it (as you remind me), while in the United States it's based on a >> concept of creativity. > > I claim that there is a lot of creativity in how the locales are written, at least > the big ones. As said one of my intial works were 100 pages of the POSIX.2 standard. > And then the locales grew even further, with the advent of full ISO 10646 (Unicode) > coverage and ISO TR 14652 extra categories. There is a lot of design and ideas, > and a lot of design criteria in the locales. Including a number of theoretical landmarks, > and something that could have been patentetd, if somebody were inclined to do such nasty things:-) > And IMHO that has resulted in a system that still has a number of advantages over > what big players in the market have done for i18n. > > And then there is compilation copyright according to the Berne convention - maybe you > don't hold copyright on the data, but you hold copyright on the presentation on it and the > collection of the combination of the data. > > I would say in juridical terms it would not be safe to assume that there is no copyright on > the locales (and charmaps and repertoiremaps). > > Best regards > keld The Software Freedom Law Center has received an email from you sent to help@softwarefreedom.org. We look forward to helping you in any way we can, but before we can do that we need to make sure that you understand that your email to us does not create an attorney-client relationship with us and any information you send us will not be considered confidential or privileged. If you understand that, just reply to this message by keeping the text of this paragraph and adding "Understood" and we will respond to your email shortly. However, if your message contains any information that you would like to be considered confidential or privileged (in other words, you do not want it to be considered public information), please respond to this message with "Delete my message" or just "Delete." We understand that this procedure may seem burdensome, but it is required by law in order to ensure your rights and the rights of our clients are protected. (In reply to comment #17) > (Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm > looking to a statement from someone at FSF/SFLC.) I've asked the Debian Project Leader to make a formal request for advice, since that seems to be how the SFLC would prefer this to go. Bureaucracy... Oh well. I look forward to hints from the legal folk, too. I've had the opportunity to bring this to the attention of the GNOME Technical Advisory Board (via a member I know). I do think this is a serious matter and requires high-level attention to drive resolution as quickly as feasible. this is the FSF decision: https://sourceware.org/ml/libc-locales/2013-q1/msg00048.html we will be updating the locale data files with that header all localedata files now contain that language This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, master has been updated
via a4cea54b12ff33e81be4413abb74905020890330 (commit)
from f9378ac3773ffe998a2b3406568778ee9f77f759 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a4cea54b12ff33e81be4413abb74905020890330
commit a4cea54b12ff33e81be4413abb74905020890330
Author: Mike Frysinger <vapier@gentoo.org>
Date: Sat Feb 20 01:59:46 2016 -0500
localedata: standardize copyright/license information [BZ #11213]
Use the language from the FSF in all locale files to disclaim any
license/copyright on locale data.
See https://sourceware.org/ml/libc-locales/2013-q1/msg00048.html
-----------------------------------------------------------------------
Summary of changes:
localedata/ChangeLog | 331 ++++++++++++++++++++++++++++++
localedata/locales/POSIX | 9 +-
localedata/locales/aa_DJ | 7 +
localedata/locales/aa_ER | 7 +
localedata/locales/aa_ER@saaho | 7 +
localedata/locales/aa_ET | 7 +
localedata/locales/af_ZA | 7 +
localedata/locales/ak_GH | 16 +-
localedata/locales/am_ET | 7 +
localedata/locales/an_ES | 7 +
localedata/locales/anp_IN | 14 +-
localedata/locales/ar_AE | 7 +
localedata/locales/ar_BH | 7 +
localedata/locales/ar_DZ | 7 +
localedata/locales/ar_EG | 7 +
localedata/locales/ar_IN | 7 +
localedata/locales/ar_IQ | 7 +
localedata/locales/ar_JO | 7 +
localedata/locales/ar_KW | 7 +
localedata/locales/ar_LB | 7 +
localedata/locales/ar_LY | 7 +
localedata/locales/ar_MA | 7 +
localedata/locales/ar_OM | 7 +
localedata/locales/ar_QA | 7 +
localedata/locales/ar_SA | 7 +
localedata/locales/ar_SD | 14 +-
localedata/locales/ar_SS | 14 +-
localedata/locales/ar_SY | 7 +
localedata/locales/ar_TN | 7 +
localedata/locales/ar_YE | 7 +
localedata/locales/as_IN | 7 +
localedata/locales/ast_ES | 7 +
localedata/locales/ayc_PE | 14 +-
localedata/locales/az_AZ | 9 +-
localedata/locales/be_BY | 9 +-
localedata/locales/be_BY@latin | 9 +-
localedata/locales/bem_ZM | 9 +-
localedata/locales/ber_DZ | 9 +-
localedata/locales/ber_MA | 9 +-
localedata/locales/bg_BG | 8 +-
localedata/locales/bhb_IN | 7 +
localedata/locales/bho_IN | 7 +
localedata/locales/bn_BD | 7 +
localedata/locales/bn_IN | 7 +
localedata/locales/bo_CN | 7 +
localedata/locales/bo_IN | 7 +
localedata/locales/br_FR | 9 +-
localedata/locales/br_FR@euro | 9 +-
localedata/locales/brx_IN | 7 +
localedata/locales/bs_BA | 9 +-
localedata/locales/byn_ER | 7 +
localedata/locales/ca_AD | 9 +-
localedata/locales/ca_ES | 9 +-
localedata/locales/ca_ES@euro | 9 +-
localedata/locales/ca_FR | 9 +-
localedata/locales/ca_IT | 9 +-
localedata/locales/ce_RU | 7 +
localedata/locales/cmn_TW | 14 +-
localedata/locales/crh_UA | 9 +-
localedata/locales/cs_CZ | 8 +-
localedata/locales/csb_PL | 9 +-
localedata/locales/cv_RU | 9 +-
localedata/locales/cy_GB | 8 +-
localedata/locales/da_DK | 9 +-
localedata/locales/de_AT | 9 +-
localedata/locales/de_AT@euro | 9 +-
localedata/locales/de_BE | 9 +-
localedata/locales/de_BE@euro | 9 +-
localedata/locales/de_CH | 9 +-
localedata/locales/de_DE | 7 +
localedata/locales/de_DE@euro | 7 +
localedata/locales/de_LU | 9 +-
localedata/locales/de_LU@euro | 9 +-
localedata/locales/doi_IN | 7 +
localedata/locales/dv_MV | 9 +-
localedata/locales/dz_BT | 7 +
localedata/locales/el_CY | 7 +
localedata/locales/el_GR | 9 +-
localedata/locales/el_GR@euro | 7 +
localedata/locales/en_AG | 7 +
localedata/locales/en_AU | 9 +-
localedata/locales/en_BW | 9 +-
localedata/locales/en_CA | 9 +-
localedata/locales/en_DK | 9 +-
localedata/locales/en_GB | 9 +-
localedata/locales/en_HK | 7 +
localedata/locales/en_IE | 9 +-
localedata/locales/en_IE@euro | 9 +-
localedata/locales/en_IN | 7 +
localedata/locales/en_NG | 9 +-
localedata/locales/en_NZ | 9 +-
localedata/locales/en_PH | 7 +
localedata/locales/en_SG | 7 +
localedata/locales/en_US | 7 +
localedata/locales/en_ZA | 9 +-
localedata/locales/en_ZM | 9 +-
localedata/locales/en_ZW | 9 +-
localedata/locales/es_AR | 9 +-
localedata/locales/es_BO | 9 +-
localedata/locales/es_CL | 9 +-
localedata/locales/es_CO | 9 +-
localedata/locales/es_CR | 9 +-
localedata/locales/es_CU | 9 +-
localedata/locales/es_DO | 9 +-
localedata/locales/es_EC | 9 +-
localedata/locales/es_ES | 9 +-
localedata/locales/es_ES@euro | 9 +-
localedata/locales/es_GT | 9 +-
localedata/locales/es_HN | 9 +-
localedata/locales/es_MX | 9 +-
localedata/locales/es_NI | 9 +-
localedata/locales/es_PA | 9 +-
localedata/locales/es_PE | 9 +-
localedata/locales/es_PR | 9 +-
localedata/locales/es_PY | 9 +-
localedata/locales/es_SV | 9 +-
localedata/locales/es_US | 9 +-
localedata/locales/es_UY | 9 +-
localedata/locales/es_VE | 9 +-
localedata/locales/et_EE | 9 +-
localedata/locales/eu_ES | 9 +-
localedata/locales/eu_ES@euro | 9 +-
localedata/locales/fa_IR | 9 +-
localedata/locales/ff_SN | 9 +-
localedata/locales/fi_FI | 9 +-
localedata/locales/fi_FI@euro | 9 +-
localedata/locales/fil_PH | 9 +-
localedata/locales/fo_FO | 9 +-
localedata/locales/fr_BE | 9 +-
localedata/locales/fr_BE@euro | 9 +-
localedata/locales/fr_CA | 9 +-
localedata/locales/fr_CH | 9 +-
localedata/locales/fr_FR | 10 +-
localedata/locales/fr_FR@euro | 9 +-
localedata/locales/fr_LU | 9 +-
localedata/locales/fr_LU@euro | 9 +-
localedata/locales/fur_IT | 9 +-
localedata/locales/fy_DE | 8 +-
localedata/locales/fy_NL | 9 +-
localedata/locales/ga_IE | 9 +-
localedata/locales/ga_IE@euro | 9 +-
localedata/locales/gd_GB | 14 +-
localedata/locales/gez_ER | 7 +
localedata/locales/gez_ER@abegede | 7 +
localedata/locales/gez_ET | 7 +
localedata/locales/gez_ET@abegede | 7 +
localedata/locales/gl_ES | 9 +-
localedata/locales/gl_ES@euro | 9 +-
localedata/locales/gu_IN | 7 +
localedata/locales/gv_GB | 9 +-
localedata/locales/ha_NG | 9 +-
localedata/locales/hak_TW | 14 +-
localedata/locales/he_IL | 9 +-
localedata/locales/hi_IN | 7 +
localedata/locales/hne_IN | 7 +
localedata/locales/hr_HR | 9 +-
localedata/locales/hsb_DE | 9 +-
localedata/locales/ht_HT | 16 +-
localedata/locales/hu_HU | 9 +-
localedata/locales/hy_AM | 8 +-
localedata/locales/i18n | 7 +
localedata/locales/ia_FR | 7 +
localedata/locales/id_ID | 9 +-
localedata/locales/ig_NG | 9 +-
localedata/locales/ik_CA | 9 +-
localedata/locales/is_IS | 9 +-
localedata/locales/iso14651_t1 | 7 +
localedata/locales/iso14651_t1_common | 7 +
localedata/locales/iso14651_t1_pinyin | 7 +
localedata/locales/it_CH | 9 +-
localedata/locales/it_IT | 9 +-
localedata/locales/it_IT@euro | 9 +-
localedata/locales/iu_CA | 8 +-
localedata/locales/iw_IL | 9 +-
localedata/locales/ja_JP | 7 +
localedata/locales/ka_GE | 8 +-
localedata/locales/kk_KZ | 9 +-
localedata/locales/kl_GL | 9 +-
localedata/locales/km_KH | 32 +---
localedata/locales/kn_IN | 7 +
localedata/locales/ko_KR | 8 +-
localedata/locales/kok_IN | 7 +
localedata/locales/ks_IN | 7 +
localedata/locales/ks_IN@devanagari | 7 +
localedata/locales/ku_TR | 9 +-
localedata/locales/kw_GB | 9 +-
localedata/locales/ky_KG | 7 +
localedata/locales/lb_LU | 7 +
localedata/locales/lg_UG | 9 +-
localedata/locales/li_BE | 7 +-
localedata/locales/li_NL | 7 +-
localedata/locales/lij_IT | 7 +
localedata/locales/lo_LA | 35 +---
localedata/locales/lt_LT | 9 +-
localedata/locales/lv_LV | 9 +-
localedata/locales/lzh_TW | 14 +-
localedata/locales/mag_IN | 7 +
localedata/locales/mai_IN | 7 +
localedata/locales/mg_MG | 9 +-
localedata/locales/mhr_RU | 9 +-
localedata/locales/mi_NZ | 9 +-
localedata/locales/mk_MK | 9 +-
localedata/locales/ml_IN | 7 +
localedata/locales/mn_MN | 9 +-
localedata/locales/mni_IN | 7 +
localedata/locales/mr_IN | 7 +
localedata/locales/ms_MY | 7 +
localedata/locales/mt_MT | 7 +
localedata/locales/my_MM | 7 +
localedata/locales/nan_TW | 14 +-
localedata/locales/nan_TW@latin | 9 +-
localedata/locales/nb_NO | 9 +-
localedata/locales/nds_DE | 7 +-
localedata/locales/nds_NL | 7 +-
localedata/locales/ne_NP | 7 +
localedata/locales/nhn_MX | 7 +
localedata/locales/niu_NU | 7 +
localedata/locales/niu_NZ | 7 +
localedata/locales/nl_AW | 7 +
localedata/locales/nl_BE | 9 +-
localedata/locales/nl_BE@euro | 9 +-
localedata/locales/nl_NL | 9 +-
localedata/locales/nl_NL@euro | 9 +-
localedata/locales/nn_NO | 7 +
localedata/locales/nr_ZA | 7 +
localedata/locales/nso_ZA | 7 +
localedata/locales/oc_FR | 8 +-
localedata/locales/om_ET | 7 +
localedata/locales/om_KE | 7 +
localedata/locales/or_IN | 7 +
localedata/locales/os_RU | 9 +-
localedata/locales/pa_IN | 7 +
localedata/locales/pa_PK | 9 +-
localedata/locales/pap_AW | 14 +-
localedata/locales/pap_CW | 14 +-
localedata/locales/pl_PL | 9 +-
localedata/locales/ps_AF | 7 +
localedata/locales/pt_BR | 9 +-
localedata/locales/pt_PT | 9 +-
localedata/locales/pt_PT@euro | 9 +-
localedata/locales/quz_PE | 17 +-
localedata/locales/raj_IN | 7 +
localedata/locales/ro_RO | 9 +-
localedata/locales/ru_RU | 9 +-
localedata/locales/ru_UA | 9 +-
localedata/locales/rw_RW | 7 +
localedata/locales/sa_IN | 7 +
localedata/locales/sat_IN | 7 +
localedata/locales/sc_IT | 9 +-
localedata/locales/sd_IN | 7 +
localedata/locales/sd_IN@devanagari | 7 +
localedata/locales/se_NO | 9 +-
localedata/locales/shs_CA | 9 +-
localedata/locales/si_LK | 7 +
localedata/locales/sid_ET | 7 +
localedata/locales/sk_SK | 8 +-
localedata/locales/sl_SI | 9 +-
localedata/locales/so_DJ | 7 +
localedata/locales/so_ET | 7 +
localedata/locales/so_KE | 7 +
localedata/locales/so_SO | 7 +
localedata/locales/sq_AL | 7 +
localedata/locales/sq_MK | 7 +
localedata/locales/sr_ME | 9 +-
localedata/locales/sr_RS | 10 +-
localedata/locales/sr_RS@latin | 10 +-
localedata/locales/ss_ZA | 7 +
localedata/locales/st_ZA | 7 +
localedata/locales/sv_FI | 9 +-
localedata/locales/sv_FI@euro | 9 +-
localedata/locales/sv_SE | 9 +-
localedata/locales/sw_KE | 9 +-
localedata/locales/sw_TZ | 9 +-
localedata/locales/szl_PL | 9 +-
localedata/locales/ta_IN | 7 +
localedata/locales/ta_LK | 9 +-
localedata/locales/tcy_IN | 7 +
localedata/locales/te_IN | 7 +
localedata/locales/tg_TJ | 9 +-
localedata/locales/th_TH | 31 +---
localedata/locales/the_NP | 18 +-
localedata/locales/ti_ER | 7 +
localedata/locales/ti_ET | 7 +
localedata/locales/tig_ER | 7 +
localedata/locales/tk_TM | 10 +-
localedata/locales/tl_PH | 9 +-
localedata/locales/tn_ZA | 7 +
localedata/locales/tr_CY | 9 +-
localedata/locales/tr_TR | 9 +-
localedata/locales/translit_circle | 7 +
localedata/locales/translit_cjk_compat | 7 +
localedata/locales/translit_cjk_variants | 7 +
localedata/locales/translit_combining | 7 +
localedata/locales/translit_compat | 7 +
localedata/locales/translit_font | 7 +
localedata/locales/translit_fraction | 7 +
localedata/locales/translit_hangul | 7 +
localedata/locales/translit_narrow | 7 +
localedata/locales/translit_neutral | 7 +
localedata/locales/translit_small | 7 +
localedata/locales/translit_wide | 7 +
localedata/locales/ts_ZA | 7 +
localedata/locales/tt_RU | 9 +-
localedata/locales/tt_RU@iqtelif | 9 +-
localedata/locales/ug_CN | 9 +-
localedata/locales/uk_UA | 12 +-
localedata/locales/unm_US | 9 +-
localedata/locales/ur_IN | 7 +
localedata/locales/ur_PK | 9 +-
localedata/locales/uz_UZ | 9 +-
localedata/locales/uz_UZ@cyrillic | 9 +-
localedata/locales/ve_ZA | 7 +
localedata/locales/vi_VN | 9 +-
localedata/locales/wa_BE | 8 +-
localedata/locales/wa_BE@euro | 9 +-
localedata/locales/wae_CH | 7 +
localedata/locales/wal_ET | 7 +
localedata/locales/wo_SN | 9 +-
localedata/locales/xh_ZA | 7 +
localedata/locales/yi_US | 8 +-
localedata/locales/yo_NG | 9 +-
localedata/locales/yue_HK | 7 +
localedata/locales/zh_CN | 7 +
localedata/locales/zh_HK | 7 +
localedata/locales/zh_SG | 7 +
localedata/locales/zh_TW | 7 +
localedata/locales/zu_ZA | 7 +
327 files changed, 2610 insertions(+), 529 deletions(-)
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The annotated tag, glibc-2.24 has been created
at beb0f59498c3e0337df298f9d7a3f8f77eb39842 (tag)
tagging fdfc9260b61d3d72541f18104d24c7bcb0ce5ca2 (commit)
replaces glibc-2.23
tagged by Carlos O'Donell
on Mon Aug 1 22:46:26 2016 -0400
- Log -----------------------------------------------------------------
The GNU C Library
=================
The GNU C Library version 2.24 is now available.
The GNU C Library is used as *the* C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.
The GNU C Library is primarily designed to be a portable
and high performance C library. It follows all relevant
standards including ISO C11 and POSIX.1-2008. It is also
internationalized and has one of the most complete
internationalization interfaces known.
The GNU C Library webpage is at http://www.gnu.org/software/libc/
Packages for the 2.24 release may be downloaded from:
http://ftpmirror.gnu.org/libc/
http://ftp.gnu.org/gnu/libc/
The mirror list is at http://www.gnu.org/order/ftp.html
NEWS for version 2.24
=====================
* The minimum Linux kernel version that this version of the GNU C Library
can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
kernel version 2.6.32 or later suffices (on architectures that already
required kernel versions more recent than 3.2, those requirements remain
unchanged). Linux 3.2 or later kernel headers are required on all
architectures.
* The pap_AN locale has been deleted. This has been deprecated for a long
time. It has been replaced by pap_AW & pap_CW, both of which have long
been included in previous releases.
* The readdir_r and readdir64_r functions have been deprecated. It is
recommended to use readdir and readdir64 instead.
* The type “union wait” has been removed. It was deprecated in the early
1990s and never part of POSIX. Application code should use the int type
instead of “union wait”.
* A new NSS action is added to facilitate large distributed system
administration. The action, MERGE, allows remote user stores like LDAP
to be merged into local user stores like /etc/groups in order to provide
easy to use, updated, and managed sets of merged credentials. The new
action can be used by configuring it in /etc/nsswitch.conf:
group: files [SUCCESS=merge] nis
Implemented by Stephen Gallagher (Red Hat).
* The deprecated __malloc_initialize_hook variable has been removed from the
API.
* The long unused localedef --old-style option has been removed. It hasn't
done anything in over 16 years. Scripts using this option can safely
drop it.
* nextupl, nextup, nextupf, nextdownl, nextdown and nextdownf are added to
libm. They are defined by TS 18661 and IEEE754-2008. The nextup functions
return the next representable value in the direction of positive infinity
and the nextdown functions return the next representable value in the
direction of negative infinity. These are currently enabled as GNU
extensions.
Security related changes:
* An unnecessary stack copy in _nss_dns_getnetbyname_r was removed. It
could result in a stack overflow when getnetbyname was called with an
overly long name. (CVE-2016-3075)
* Previously, getaddrinfo copied large amounts of address data to the stack,
even after the fix for CVE-2013-4458 has been applied, potentially
resulting in a stack overflow. getaddrinfo now uses a heap allocation
instead. Reported by Michael Petlan. (CVE-2016-3706)
* The glob function suffered from a stack-based buffer overflow when it was
called with the GLOB_ALTDIRFUNC flag and encountered a long file name.
Reported by Alexander Cherepanov. (CVE-2016-1234)
* The Sun RPC UDP client could exhaust all available stack space when
flooded with crafted ICMP and UDP messages. Reported by Aldy Hernandez'
alloca plugin for GCC. (CVE-2016-4429)
* The IPv6 name server management code in libresolv could result in a memory
leak for each thread which is created, performs a failing naming lookup,
and exits. Over time, this could result in a denial of service due to
memory exhaustion. Reported by Matthias Schiffer. (CVE-2016-5417)
The following bugs are resolved with this release:
[1170] localedata: ne_NP: update Nepali locale definition file
[3629] manual: stpcpy description in string.texi refers to MS-DOG instead
of MS-DOS.
[6527] malloc: [powerpc] Malloc alignment insufficient for PowerPC
[6796] math: fdim() does not set errno on overflow
[10354] libc: posix_spawn should use vfork() in more cases than presently
[11213] localedata: localedata: add copyright disclaimer to locale files
[12143] localedata: chr_US: new Cherokee locale
[12450] localedata: sgs_LT: new locale
[12676] localedata: ln_CD: new locale
[13237] localedata: LC_ADDRESS.country_name: update all locales w/latest
CLDR data
[13304] math: fma, fmaf, fmal produce wrong results
[14259] build: --localedir arg to configure is ignored
[14499] nptl: Does posix_spawn invoke atfork handlers / use vfork?
[14750] libc: Race condition in posix_spawn vfork usage vs signal handlers
[14934] localedata: es_CL: wrong first weekday chilean locale
[15262] localedata: LC_MESSAGES.yesexpr/noexpr: inconsistent use of
romanisation
[15263] localedata: LC_MESSAGES.yesexpr/noexpr: inconsistent use of 1/0
and +/-
[15264] localedata: LC_MESSAGES.yesstr/nostr: lacking in many locales
[15368] nptl: raise() is not async-signal-safe
[15479] math: ceil, floor, round and trunc raise inexact exception
[15578] localedata: kk_KZ: various updates
[16003] localedata: pap_AN: punt old locale
[16137] localedata: iw_IL: punt old locale
[16190] localedata: eo: new esperanto locale
[16374] localedata: lv_LV: change currency symbol in LC_MONETARY to euro
[16742] malloc: race condition: pthread_atfork() called before first
malloc() results in unexpected locking behaviour/deadlocks
[16975] localedata: LC_MESSAGES.yesexpr/noexpr: revisit capitalization in
all locales
[16983] localedata: postal_fmt does not allow %l and %n modifiers
[17565] localedata: pt_PT: wrong (work-)week start
[17899] math: [powerpc] floorl returns negative zero with FE_DOWNWARD
[17950] build: Build fails with -msse
[18205] localedata: be_BY*: wrong first_weekday and first_workday
[18433] libc: posix_spawn does not return correctly upon failure to
execute
[18453] localedata: charmaps/IBM875: incorrect codes
[18712] string: bits/string2.h incompatible with -O2 -Werror=packed
-Wsystem-headers
[18896] localedata: he_IL: improvements for currency
[18911] localedata: ro_RO: Correcting week day name for "Tuesday" in
Romanian locale data
[18960] locale: s390: _nl_locale_subfreeres uses larl opcode on misaligned
symbol
[19056] libc: Deprecate readdir_r
[19133] localedata: pt_*: days & months should be lowercase in Portuguese
language
[19198] localedata: nl_NL: small improvements for Dutch locales
[19257] network: Per-thread memory leak in __res_vinit with IPv6
nameservers (CVE-2016-5417)
[19269] build: tst-audit4 and tst-audit10 failures with gcc-6 on non avx
machine
[19400] locale: Language missing in "iso-639.def", trivial fix in
description
[19431] malloc: Deadlock between fflush, getdelim, and fork
[19505] libc: Incorrect file descriptor validity checks in
posix_spawn_file_actions_add{open,close,dup2}
[19509] dynamic-link: dlsym, dlvsym do not report errors through dlerror
when using RTLD_NEXT
[19512] locale: Stale `#ifndef HAVE_BUILTIN_EXPECT' in
`intl/{gettextP,loadinfo}.h'
[19534] libc: execle, execlp may use malloc
[19568] localedata: *_CH: Swiss locales have inconsistent start of week
[19573] network: res_nclose and __res_maybe_init disagree about name
server initialization, breaking Hesiod
[19575] localedata: Status of GB18030 tables
[19581] localedata: sr_* date_fmt string contains additional newline
[19583] string: SSSE3_Fast_Copy_Backward flag needs to be enabled for AMD
Excavator core
[19592] math: [ldbl-128ibm] ceill incorrect in non-default rounding modes
[19593] math: [ldbl-128ibm] truncl incorrect in non-default rounding modes
[19594] math: [ldbl-128ibm] roundl incorrect in non-default rounding modes
[19595] math: [ldbl-128ibm] fmodl incorrect for results in subnormal
double range
[19602] math: [ldbl-128ibm] fmodl handling of equal arguments with low
part zero incorrect
[19603] math: [ldbl-128ibm] remainderl, remquol incorrect sign handling in
equality tests
[19610] dynamic-link: ldconfig -X removes stale symbolic links
[19613] libc: s390x (64 bit) macro expansion WCOREDUMP and others
[19633] locale: strfmon_l applies global locale to number formatting
[19642] network: Memory leak in getnameinfo
[19648] libc: test-skeleton.c: Do not set RLIMIT_DATA
[19653] libc: Potential for NULL pointer dereference (CWE-476) in
glibc-2.22
[19654] math: [x86_64] Need testcase for BZ #19590 fix
[19671] localedata: Missing Sanity Check for malloc() in 'tst-fmon.c' &
'tst-numeric.c'
[19674] math: [ldbl-128ibm] powl incorrect overflow handling
[19677] math: [ldbl-128ibm] remainderl equality test incorrect for zero
low part
[19678] math: [ldbl-128ibm] nextafterl, nexttowardl incorrect sign of zero
result
[19679] dynamic-link: gcc-4.9.3 C++ exception handling broken due to
unaligned stack
[19726] locale: Converting UCS4LE to INTERNAL with iconv() does not update
pointers and lengths in error-case.
[19727] locale: Converting from/to UTF-xx with iconv() does not always
report errors on UTF-16 surrogates values.
[19755] nscd: nscd assertion failure in gc
[19758] dynamic-link: Typo in EXTRA_LD_ENVVARS for x86-64
[19759] libc: mempcpy shouldn't be inlined
[19762] dynamic-link: HAS_CPU_FEATURE/HAS_ARCH_FEATURE are easy to misuse
[19765] libc: s390 needs an optimized mempcpy
[19779] glob: glob: buffer overflow with GLOB_ALTDIRFUNC due to incorrect
NAME_MAX limit assumption (CVE-2016-1234)
[19783] build: benchtests don't support --enable-hardcoded-path-in-tests
[19787] network: Missing and incorrect truncation checks in getnameinfo
[19790] math: [ldbl-128ibm] nearbyintl incorrect in non-default rounding
modes
[19791] network: Assertion failure in res_query.c with un-connectable name
server addresses
[19792] libc: MIPS: backtrace yields infinite backtrace with makecontext
[19822] math: libm.so install clobbers old version
[19825] network: resolv: send_vc can return uninitialized data in second
response to getaddrinfo
[19830] network: nss_dns: should check RDATA length against buffer length
[19831] network: nss_dns: getaddrinfo returns uninitialized data when
confronted with A/AAAA records of invalid size
[19837] nss: nss_db: No retries for some long lines with a larger buffer
[19848] math: powl(10,n) for n=-4,-5,-6,-7 is off by more than 1 ULP
[19853] stdio: Printing IBM long double in decimal with high precision is
sometimes incorrect
[19860] build: x86_64: compile errors for tst-audit10 and tst-auditmod10b
[19861] nptl: libpthread IFUNC resolver for fork can lead to crash
[19862] network: resolv, nss_dns: Remove remaining logging of unexpected
record types
[19865] network: Assertion failure or memory leak in
_nss_dns_getcanonname_r
[19868] network: nss_dns: netent code does not skip over non-PTR records
[19879] network: nss_dns: Stack overflow in getnetbyname implementation
(CVE-2016-3075)
[19881] string: Improve x86-64 memset
[19907] string: Incorrect memcpy tests
[19916] dynamic-link: S390: fprs/vrs are not saved/restored while
resolving symbols
[19925] libc: termios.h XCASE namespace
[19928] string: memmove-vec-unaligned-erms.S is slow with large data size
[19929] libc: limits.h NL_NMAX namespace
[19931] stdio: Memory leak in vfprintf
[19957] libc: clone(CLONE_VM) access invalid parent memory
[19963] localedata: en_IL: New locale
[19989] stdio: stdio.h cuserid namespace
[19994] network: getaddrinfo does not restore RES_USE_INET6 flag in
gethosts
[19996] locale: langinfo.h nl_langinfo_l namespace
[20005] stdio: fflush on a file opened with fmemopen resets position to 0
[20010] network: getaddrinfo: Stack overflow in hostent translation
(CVE-2016-3706)
[20012] stdio: libio: fmemopen append mode failure
[20014] stdio: stdio.h namespace for pre-threads POSIX
[20017] network: resolv: Use gmtime_r instead of gmtime in p_secstodate
[20023] libc: fcntl.h timespec namespace
[20024] math: [x86_64] vectorized sincos trashes the stack
[20031] network: nss_hesiod: Heap overflow in get_txt_records
[20041] time: sys/time.h timespec namespace
[20043] libc: unistd.h missing cuserid for UNIX98 and before
[20044] libc: unistd.h missing pthread_atfork for UNIX98
[20051] libc: ttyslot in wrong header under wrong conditions
[20054] libc: gethostname not declared for XPG4
[20055] libc: termios.h missing tcgetsid for XPG4
[20072] dynamic-link: x86 init_cpu_features is called twice in static
executable
[20073] libc: sys/stat.h fchmod namespace
[20074] libc: stdlib.h rand_r namespace
[20076] libc: sys/stat.h missing S_IFSOCK, S_ISSOCK for XPG4
[20094] libc: stdlib.h should not declare grantpt, ptsname, unlockpt for
XPG3
[20111] libc: struct sockaddr_storage cannot be aggregate-copied
[20112] network: sunrpc: stack (frame) overflow in Sun RPC clntudp_call
(CVE-2016-4429)
[20115] string: Extra alignment in memset-vec-unaligned-erms.S
[20119] libc: Wrong mask for processors level type from CPUID
[20139] dynamic-link: Upper part of zmm is zeroed if Glibc is built with
AS not supporting AVX512
[20151] math: [ldbl-128/ldbl-128ibm] j0l, j1l, y0l, y1l return sNaN for
sNaN argument
[20153] math: [ldbl-128ibm] sqrtl (sNaN) returns sNaN
[20156] math: [ldbl-128ibm] ceill, rintl etc. return sNaN for sNaN
argument
[20157] math: [powerpc] fabsl (sNaN) wrongly raises "invalid"
[20160] math: [powerpc] ceil, rint etc. return sNaN for sNaN input
[20178] libc: posix_spawn{p} should not call exit
[20191] stdio: libio: vtables hardening
[20195] string: FMA4 detection requires CPUID execution with register
eax=0x80000001
[20198] libc: quick_exit incorrectly destroys C++11 thread objects.
[20205] math: [i386/x86_64] nextafterl incorrect incrementing negative
subnormals
[20212] math: acos (sNaN) returns sNaN
[20213] math: asin (sNaN) returns sNaN
[20214] network: Linux header sync with linux/in6.h and ipv6.h again.
[20218] math: [i386] asinhl (sNaN) returns sNaN
[20219] math: [i386] atanhl (sNaN) returns sNaN
[20222] stdio: fopencookie: Mangle function pointers
[20224] math: [i386] cbrtl (sNaN) returns sNaN
[20225] math: ldexp, scalbn, scalbln return sNaN for sNaN input
[20226] math: [i386/x86_64] expl, exp10l, expm1l return sNaN for sNaN
input
[20227] math: [i386/x86_64] logl (sNaN) returns sNaN
[20228] math: [i386/x86_64] log10l (sNaN) returns sNaN
[20229] math: [i386/x86_64] log1pl (sNaN) returns sNaN
[20232] math: [ldbl-128] expm1l (sNaN) returns sNaN
[20233] math: [ldbl-128ibm] expm1l (sNaN) returns sNaN
[20234] math: [ldbl-128ibm] log1pl (sNaN) returns sNaN
[20235] math: [i386/x86_64] log2l (sNaN) returns sNaN
[20237] nss: nss_db: get*ent segfaults without preceding set*ent
[20240] math: modf (sNaN) returns sNaN
[20248] libc: debug/tst-longjump_chk2 calls printf from a signal handler
[20250] math: frexp (sNaN) returns sNaN
[20252] math: atan2 (sNaN, qNaN) fails to raise "invalid"
[20255] math: [i386] fdim, fdimf return with excess range and precision /
double rounding
[20256] math: [i386/x86_64] fdiml returns sNaN for sNaN input
[20260] string: ../sysdeps/x86/bits/string.h:1092:3: error: array
subscript is below array bounds [-Werror=array-bounds]
[20262] nis: _nss_nis_initgroups_dyn always returns NSS_STATUS_NOTFOUND
[20263] nptl: robust mutex deadlocks if other thread requests timedlock
(Only arm/linux)
[20277] libc: $dp is not initialized correctly in sysdeps/hppa/start.S
[20284] malloc: malloc: Corrupt arena avoidance causes unnecessary mmap
fallbacks
[20296] math: [i386/x86_64] scalbl returns sNaN for sNaN input, missing
"invalid" exceptions
[20314] nptl: make[4]: *** [/usr/include/stdlib.h] Error 1
[20316] localedata: id_ID: Februari instead of Pebruari
[20327] string: POWER8 strcasecmp returns incorrect result
[20347] math: Failure: Test: j0_downward (0xap+0)
[20348] libc: FAIL: misc/tst-preadvwritev64
[20349] libc: 64-bit value is passed differently in p{readv,writev}{64}
[20350] libc: There is no test for p{read,write}64
[20357] math: Incorrect cos result for 1.5174239687223976
[20384] build: Don't run libmvec-sincos-avx* tests on non avx machines
Contributors
============
This release was made possible by the contributions of many people.
The maintainers are grateful to everyone who has contributed
changes or bug reports. These include:
Adhemerval Zanella
Andreas Schwab
Andrew Senkevich
Anton Blanchard
Arnas Udovičius
Aurelien Jarno
Carlos Eduardo Seo
Carlos O'Donell
Chris Metcalf
Chung-Lin Tang
Claude Paroz
Dimitris Pappas
Dmitry V. Levin
Dylan Alex Simon
Eduardo Trápani
Florian Weimer
Gabriel F. T. Gomes
Gunnar Hjalmarsson
Gustavo Romero
Guy Rutenberg
H.J. Lu
Hongjiu Zhang
Jiyoung Yun
John David Anglin
Joseph Myers
Khem Raj
Maciej W. Rozycki
Mark Wielaard
Marko Myllynen
Martin Galvan
Matthew Fortune
Matthias Wallnoefer
Mike FABIAN
Mike Frysinger
Neskie Manuel
Nick Alcock
Paras pradhan
Paul E. Murphy
Paul Pluzhnikov
Rajalakshmi Srinivasaraghavan
Rical Jasan
Richard Henderson
Robin van der Vliet
Roland McGrath
Samuel Thibault
Siddhesh Poyarekar
Simion Onea
Stefan Liebler
Stephen Gallagher
Szabolcs Nagy
Timur Birsh
Torvald Riegel
Tulio Magno Quites Machado Filho
Wilco Dijkstra
Will Newton
Yvan Roux
Zack Weinberg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXoAmUAAoJEBZ5K06iU0D4Nx8P/3EGutqtVg6OubIKw9izzWMO
6pNj7Iy569Bk+ER2ElR5xvTeumpVS05A8r94oXX0rzCNsFIAVct7Ocr62r/OQz8A
+p6W+USpORha6m+SzY1bkI1109RR6Q4jpbENkhk/JKcBXJ7AHWHeW72QKMP0+JJu
QBavQ8b3ZLJQ4X+Be10bjseTaqAn4XNYj6fmajQC2x7F0sL32+xFjSktw8hn9AFs
A32yS3c2v/GfqKIyNj4Yz/akZzffACZ+8twVkJGDK5eoMGGQ/Obr3yttzKSNsN+O
n73HyyP4O8dG/U+v5k0IR4drT6mnUFRHUvkN10VahCHiTSG5AFQut30lwvVKzhF6
VYylPzbhOcVnSuJqdT4xJ6sumvQl5W4IAb/GKSso62MrcKFYPFdnx0wgMX6Arlgm
wkuSkSQCOfj/be2/R88alRJYNTW39vsPqKPop5ov/uXbfHqIoFcQitS0vDFJqGIC
zOhJSlV0cS/StKkw0xNgQ6Ay/dnHMm2Hzg5lqRzaQblkDVrNfN7TqyeZBEhwh3N5
KifvkdKSO6L6N7dM3nLsT+qJWoSp8dNsQ+qCHL6A/hL0SA4nxJ3hmC5hanCL+7D8
MrO5m+Z5yjpdSWFDmJv2LZsIzYX2UGZmUO19c7zvZoIrXuJE4bQXEmM4rylrNXGS
Lcke/0PPdvDeSW7iWjjP
=j7Oo
-----END PGP SIGNATURE-----
Adhemerval Zanella (40):
Open development for 2.24.
Updated translations for 2.23.
Regenerate libc.pot for 2.23.
Regenerated configure scripts.
Update NEWS with 2.24 template
posix: Remove dynamic memory allocation from execl{e,p}
posix: execvpe cleanup
posix: New Linux posix_spawn{p} implementation
posix: Fix tst-execvpe5 for --enable-hardcoded-path-in-tests
posix: Fix posix_spawn invalid memory access
posix: Fix posix_spawn implict check style
Fix tst-dlsym-error build
Improve generic strspn performance
Improve generic strpbrk performance
Remove powerpc64 strspn, strcspn, and strpbrk implementation
Use PTR_ALIGN_DOWN on strcspn and strspn
Define __ASSUME_ALIGNED_REGISTER_PAIRS for missing ports
Consolidate off_t/off64_t syscall argument passing
Consolidate pread/pread64 implementations
Consolidate pwrite/pwrite64 implementations
Fix pread consolidation on ports that require argument alignment
libio: Update internal fmemopen position after write (BZ #20005)
Fix clone (CLONE_VM) pid/tid reset (BZ#19957)
libio: Fix fmemopen append mode failure (BZ# 20012)
powerpc: Fix clone CLONE_VM compare
Adjust kernel-features.h defaults for recvmsg and sendmsg
network: recvmsg and sendmsg standard compliance (BZ#16919)
network: recvmmsg and sendmmsg standard compliance (BZ#16919)
network: Fix missing bits from {recv,send}{m}msg standard com,pliance
posix: Call _exit in failure case for posix_spawn{p} (BZ#20178)
Consolidate preadv/preadv64 implementation
Consolidate pwritev/pwritev64 implementations
Revert {send,sendm,recv,recvm}msg conformance changes
Remove __ASSUME_FUTEX_LOCK_PI
nptl: Add sendmmsg and recvmmsg cancellation tests
Fix p{readv,writev}{64} consolidation implementation
nptl: Add more coverage in tst-cancel4
Remove __ASSUME_OFF_DIFF_OFF64 definition
Fix LO_HI_LONG definition
Refactor Linux raise implementation (BZ#15368)
Andreas Schwab (13):
Don't use long double math functions if NO_LONG_DOUBLE
Fix min/max needed for ascii to INTERNAL conversion
Fix compilation of test-signgam-* tests
Fix resource leak in resolver (bug 19257)
Register extra test objects
m68k: avoid local labels in symbol table
m68k: use large PIC model for gcrt1.o
Use __typeof instead of typeof
Fix nscd assertion failure in gc (bug 19755)
Avoid array-bounds warning for strncat on i586 (bug 20260)
Return proper status from _nss_nis_initgroups_dyn (bug 20262)
m68k: suppress -Wframe-address warning
Add test case for bug 20263
Andrew Senkevich (2):
Added tests to ensure linkage through libmvec *_finite aliases which are
Fixed wrong vector sincos/sincosf ABI to have it compatible with
Anton Blanchard (1):
powerpc: Add a POWER8-optimized version of sinf()
Arnas Udovičius (1):
localedata: sgs_LT: new locale [BZ #12450]
Aurelien Jarno (17):
Add placeholder libnsl.abilist and libutil.abilist files
Add sys/auxv.h wrapper to include/sys/
mips: terminate the FDE before the return trampoline in makecontext
Assume __NR_openat is always defined
Assume __NR_utimensat is always defined
Synchronize <sys/personality.h> with kernel headers
MIPS, SPARC: fix wrong vfork aliases in libpthread.so
MIPS, SPARC: more fixes to the vfork aliases in libpthread.so
MIPS: run tst-mode-switch-{1,2,3}.c using test-skeleton.c
i686/multiarch: Regenerate ulps
SPARC64: update localplt.data
SPARC: fix nearbyint on sNaN input
New locale de_LI
localedata: fix de_LI locale
ppc: Fix modf (sNaN) for pre-POWER5+ CPU (bug 20240).
Define __USE_KERNEL_IPV6_DEFS macro for non-Linux kernels
sparc: remove ceil, floor, trunc sparc specific implementations
Carlos Eduardo Seo (2):
powerpc: Fix dl-procinfo HWCAP
powerpc: Optimization for strlen for POWER8.
Carlos O'Donell (16):
nptl: support thread stacks that grow up
GB 18030-2005: Document non-rountrip and PUA mappings (bug 19575).
Enable --localedir to set message catalog directory (Bug 14259)
NEWS (2.23): Fix typo in bug 19048 text.
Removed unused timezone/checktab.awk.
Remove mention of checktab.awk in timezone/README.
Fix building glibc master with NDEBUG and --with-cpu.
localedata: an_ES: fix case of lang_ab
Fix macro API for __USE_KERNEL_IPV6_DEFS.
Fix include/wchar.h for C++
Bug 20198: quick_exit should not call destructors.
Bug 20214: Fix linux/in6.h and netinet/in.h sync.
Bug 20215: Always undefine __always_inline before defining it.
Expand comments in Linux times() implementation.
Update libc.pot and NEWS.
Update for glibc 2.24 release.
Chris Metcalf (2):
Bump up tst-malloc-thread-fail timeout from 20 to 30s
tile: only define __ASSUME_ALIGNED_REGISTER_PAIRS for 32-bit
Chung-Lin Tang (2):
Fix stdlib/tst-makecontext regression for Nios II
Nios II localplt.data update: remove __eqsf2
Claude Paroz (1):
localedata: ln_CD: new locale [BZ #12676]
Dimitris Pappas (1):
charmaps: IBM875: fix mapping of iota/upsilon variants [BZ #18453]
Dmitry V. Levin (1):
intl: reintroduce unintentionally disabled optimization
Dylan Alex Simon (1):
math: don't clobber old libm.so on install [BZ #19822]
Eduardo Trápani (1):
localedata: eo: new Esperanto locale [BZ #16190]
Florian Weimer (91):
tst-malloc-thread-exit: Use fewer system resources
Remove trailing newline from date_fmt in Serbian locales [BZ #19581]
Improve file descriptor checks for posix_spawn actions [BZ #19505]
res_ninit: Update comment
malloc: Remove arena_mem variable
malloc: Remove max_total_mem member form struct malloc_par
malloc: Remove NO_THREADS
Deprecate readdir_r, readdir64_r [BZ #19056]
test-skeleton.c: Do not set RLIMIT_DATA [BZ #19648]
tst-audit4, tst-audit10: Compile AVX/AVX-512 code separately [BZ #19269]
libio: Clean up _IO_file_doallocate and _IO_wfile_doallocate
ldconfig: Do not remove stale symbolic links with -X [BZ #19610]
sunrpc: In key_call_keyenvoy, use int status instead of union wait
tst-audit10: Fix compilation on compilers without bit_AVX512F [BZ #19860]
resolv: Always set *resplen2 out parameter in send_dg [BZ #19791]
nss_db: Propagate ERANGE error if parse_line fails [BZ #19837]
CVE-2016-3075: Stack overflow in _nss_dns_getnetbyname_r [BZ #19879]
Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]
strfmon_l: Use specified locale for number formatting [BZ #19633]
scratch_buffer_set_array_size: Include <limits.h>
hsearch_r: Include <limits.h>
Add missing bug number to ChangeLog
nss_dns: Fix assertion failure in _nss_dns_getcanonname_r [BZ #19865]
Remove union wait [BZ #19613]
malloc: Run fork handler as late as possible [BZ #19431]
malloc: Remove unused definitions of thread_atfork, thread_atfork_static
malloc: Remove malloc hooks from fork handler
malloc: Add missing internal_function attributes on function definitions
vfprintf: Fix memory with large width and precision [BZ #19931]
resolv: Always set *resplen2 out parameter in send_vc [BZ #19825]
nss_dns: Validate RDATA length against packet length [BZ #19830]
resolv, nss_dns: Remove remaining syslog logging [BZ #19862]
nss_dns: Check address length before creating addrinfo result [BZ #19831]
nss_dns: Remove custom offsetof macro definition
nss_dns: Skip over non-PTR records in the netent code [BZ #19868]
Fix ChangeLog date to reflect commit date
resolv: Remove SCCS and RCS keywords
resolv: Remove _LIBC conditionals
inet: Remove SCCS keywords
resolv: Remove BIND_UPDATE preprocessor conditionals
resolv: Remove RESOLVSORT preprocess conditionals
resolv: Remove RFC1535 conditionals
resolv: Remove traces of ULTRIX support
resolv: Remove __BIND_NOSTATIC conditionals
resolv: Remove BSD compatibility conditionals and header
resolv: Remove SUNSECURITY preprocessor conditionals
resolv: Assorted preprocessor cleanups
resolv: Reindent preprocessor conditionals following cleanups
getnameinfo: Do not preserve errno
glob: Simplify the interface for the GLOB_ALTDIRFUNC callback gl_readdir
CVE-2016-3706: getaddrinfo: stack overflow in hostent conversion [BZ #20010]
NEWS entry for CVE-2016-3075
getnameinfo: Refactor and fix memory leak [BZ #19642]
hesiod: Remove RCS keywords
hesiod: Remove DEF_RHS
hesiod: Always use thread-local resolver state [BZ #19573]
hesiod: Avoid heap overflow in get_txt_records [BZ #20031]
CVE-2016-1234: glob: Do not copy d_name field of struct dirent [BZ #19779]
getnameinfo: Reduce line length and add missing comments
getnameinfo: Avoid calling strnlen on uninitialized buffer
getnameinfo: Return EAI_OVERFLOW in more cases [BZ #19787]
malloc: Adjust header file guard in malloc-internal.h
getaddrinfo: Restore RES_USE_INET6 flag on error path [BZ #19994]
resolv: Call gmtime_r instead of gmtime in p_secstodate [BZ #20017]
localedef: Do not compile with mcheck
getaddrinfo: Convert from extend_alloca to struct scratch_buffer
Increase fork signal safety for single-threaded processes [BZ #19703]
malloc: Rewrite dumped heap for compatibility in __malloc_set_state
tst-mallocfork2: Fix race condition, use fewer resources
Make padding in struct sockaddr_storage explicit [BZ #20111]
CVE-2016-4429: sunrpc: Do not use alloca in clntudp_call [BZ #20112]
malloc: Correct malloc alignment on 32-bit architectures [BZ #6527]
fork in libpthread cannot use IFUNC resolver [BZ #19861]
libio: Use wmemset instead of __wmemset to avoid linknamespace issue
tst-rec-dlopen: Use interposed malloc instead of hooks
malloc: Correct size computation in realloc for dumped fake mmapped chunks
quick_exit tests: Do not use C++ headers
malloc: Remove __malloc_initialize_hook from the API [BZ #19564]
fopencookie: Mangle function pointers stored on the heap [BZ #20222]
malloc_usable_size: Use correct size for dumped fake mapped chunks
nss_db: Fix initialization of iteration position [BZ #20237]
debug/tst-longjmp_chk2: Make signal handler more conservative [BZ #20248]
Revert __malloc_initialize_hook symbol poisoning
elf: Consolidate machine-agnostic DTV definitions in <dl-dtv.h>
malloc: Avoid premature fallback to mmap [BZ #20284]
test-skeleton.c: Add write_message function
test-skeleton.c: xmalloc, xcalloc, xrealloc are potentially unused
test-skeleton.c (xrealloc): Support realloc-as-free
libio: Implement vtable verification [BZ #20191]
Correct bug number in ChangeLog [BZ #18960]
CVE-2016-5417 was assigned to bug 19257
Gabriel F. T. Gomes (3):
powerpc: Remove uses of operand modifier (%s) in inline asm
powerpc: Zero pad using memset in strncpy/stpncpy
powerpc: Fix operand prefixes
Gunnar Hjalmarsson (1):
localedata: id_ID: Februari instead of Pebruari [BZ #20316]
Gustavo Romero (1):
powerpc: Fix missing verb and typo in comment about AT_HWCAP entry
Guy Rutenberg (1):
localedata: en_IL: new English locale [BZ #19963]
H.J. Lu (68):
[x86_64] Set DL_RUNTIME_UNALIGNED_VEC_SIZE to 8
Call x86-64 __setcontext directly
Call x86-64 __mcount_internal/__sigjmp_save directly
Copy x86_64 _mcount.op from _mcount.o
Or bit_Prefer_MAP_32BIT_EXEC in EXTRA_LD_ENVVARS
x86-64: Fix memcpy IFUNC selection
Add a comment in sysdeps/x86_64/Makefile
Replace @PLT with @GOTPCREL(%rip) in call
Replace PREINIT_FUNCTION@PLT with *%rax in call
Use HAS_ARCH_FEATURE with Fast_Rep_String
Group AVX512 functions in .text.avx512 section
Support --enable-hardcoded-path-in-tests in benchtests
Define _HAVE_STRING_ARCH_mempcpy to 1 for x86
Add _arch_/_cpu_ to index_*/bit_* in x86 cpu-features.h
Use JUMPTARGET in x86-64 mathvec
Use JUMPTARGET in x86-64 pthread
Set index_arch_AVX_Fast_Unaligned_Load only for Intel processors
Don't set %rcx twice before "rep movsb"
[x86] Add a feature bit: Fast_Unaligned_Copy
Implement x86-64 multiarch mempcpy in memcpy
Make __memcpy_avx512_no_vzeroupper an alias
Initial Enhanced REP MOVSB/STOSB (ERMS) support
Add x86-64 memmove with unaligned load/store and rep movsb
Add x86-64 memset with unaligned store and rep stosb
Test 64-byte alignment in memcpy benchtest
Test 64-byte alignment in memmove benchtest
Test 64-byte alignment in memset benchtest
Remove Fast_Copy_Backward from Intel Core processors
Fix memmove-vec-unaligned-erms.S
Don't put SSE2/AVX/AVX512 memmove/memset in ld.so
Add a comment in memset-sse2-unaligned-erms.S
Force 32-bit displacement in memset-vec-unaligned-erms.S
Add memcpy/memmove/memset benchmarks with large data
X86-64: Prepare memset-vec-unaligned-erms.S
X86-64: Prepare memmove-vec-unaligned-erms.S
X86-64: Use non-temporal store in memcpy on large data
Detect Intel Goldmont and Airmont processors
Reduce number of mmap calls from __libc_memalign in ld.so
Move sysdeps/x86_64/cacheinfo.c to sysdeps/x86
Remove x86 ifunc-defines.sym and rtld-global-offsets.sym
Support non-inclusive caches on Intel processors
Call init_cpu_features only if SHARED is defined
Clear destination buffer updated by the previous run
Don't call internal __pthread_unwind via PLT
Don't call internal _Unwind_Resume via PLT
Remove alignments on jump targets in memset
Check the HTT bit before counting logical threads
Correct Intel processor level type mask from CPUID
Remove special L2 cache case for Knights Landing
Avoid an extra branch to PLT for -z now
Count number of logical processors sharing L2 cache
Fix a typo in comments in memmove-vec-unaligned-erms.S
Check FMA after COMMON_CPUID_INDEX_80000001
X86-64: Remove the previous SSE2/AVX2 memsets
X86-64: Remove previous default/SSE2/AVX2 memcpy/memmove
X86-64: Add dummy memcopy.h and wordcopy.c
Always indirect branch to __libc_start_main via GOT
Compile tst-cleanupx4 test with -fexceptions
Check Prefer_ERMS in memmove/memcpy/mempcpy/memset
Require binutils 2.24 to build x86-64 glibc [BZ #20139]
Make copies of cstdlib/cmath and use them [BZ #20314]
X86-64: Define LO_HI_LONG to skip pos_h [BZ #20349]
x86-64: Properly align stack in _dl_tlsdesc_dynamic [BZ #20309]
Test p{read,write}64 with offset > 4GB
x86-64: Add p{read,write}[v]64 to syscalls.list [BZ #20348]
Regenerate i686 libm-test-ulps with GCC 6.1 at -O3 [BZ #20347]
i386: Compile rtld-*.os with -mno-sse -mno-mmx -mfpmath=387
Don't compile do_test with -mavx/-mavx/-mavx512
Hongjiu Zhang (1):
sln: use stat64
Jiyoung Yun (1):
Fix robust mutex daedlock [BZ #20263]
John David Anglin (2):
hppa: fix loading of global pointer in _start [BZ #20277]
hppa: Update libm-test-ulps.
Joseph Myers (107):
Fix ldbl-128ibm floorl for non-default rounding modes (bug 17899).
Fix ldbl-128ibm ceill for non-default rounding modes (bug 19592).
Fix ldbl-128ibm truncl for non-default rounding modes (bug 19593).
Fix ldbl-128ibm roundl for non-default rounding modes (bug 19594).
Fix ldbl-128ibm fmodl handling of subnormal results (bug 19595).
Fix ldbl-128ibm fmodl handling of equal arguments with low part zero (bug 19602).
Fix ldbl-128ibm remainderl, remquol equality tests (bug 19603).
Fix ldbl-128ibm powl overflow handling (bug 19674).
Fix ldbl-128ibm nextafterl, nexttowardl sign of zero result (bug 19678).
Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere.
Remove linux/fanotify.h configure test.
Remove kernel-features.h conditionals on pre-3.2 kernels.
Fix ldbl-128ibm remainderl equality test for zero low part (bug 19677).
Fix ldbl-128ibm nearbyintl in non-default rounding modes (bug 19790).
Allow spurious underflow / inexact for ldbl-128ibm.
Update glibc headers for Linux 4.5.
Adjust kernel-features.h defaults for socket syscalls.
Remove __ASSUME_PPOLL.
Remove __ASSUME_FALLOCATE.
Remove __ASSUME_EVENTFD2, move eventfd to syscalls.list.
Remove __ASSUME_SIGNALFD4.
Remove __ASSUME_GETDENTS64_SYSCALL.
Fix x86_64 / x86 powl inaccuracy for integer exponents (bug 19848).
[microblaze] Remove __ASSUME_FUTIMESAT.
Fix termios.h XCASE namespace (bug 19925).
Fix limits.h NL_NMAX namespace (bug 19929).
Fix stdio.h cuserid namespace (bug 19989).
Define off_t in stdio.h for XOPEN2K.
conformtest: Correct XOPEN2K stdarg.h expectations.
Fix langinfo.h nl_langinfo_l namespace (bug 19996).
conformtest: Correct some signal.h expectations for XOPEN2K.
conformtest: Correct some stdio.h expectations for UNIX98.
conformtest: Correct stdio.h expectations for fdopen.
Also define off_t in stdio.h for UNIX98.
conformtest: Add langinfo.h expectations for YESSTR, NOSTR.
Fix stdio.h namespace for pre-threads POSIX (bug 20014).
Fix fcntl.h timespec namespace (bug 20023).
Fix sys/time.h timespec namespace (bug 20041).
conformtest: Remove some bogus sys/types.h expectations for XPG3 and XPG4.
Declare cuserid in unistd.h for UNIX98 and before (bug 20043).
Declare pthread_atfork in unistd.h for UNIX98 (bug 20044).
conformtest: Fix st_blksize, st_blocks expectations for XPG3, XPG4.
conformtest: Correct some sys/stat.h expectations for XPG3.
Fix sys/stat.h fchmod namespace (bug 20073).
Declare tcgetsid for XPG4 (bug 20055).
conformtest: Do not expect S_IF* in fcntl.h.
Declare gethostname for XPG4 (bug 20054).
conformtest: Correct some unistd.h expectations for XPG3, XPG4.
conformtest: Correct time.h XPG3 expectations.
conformtest: Do not expect strdup in string.h for XPG3.
conformtest: Correct some stdlib.h expectations for XPG3.
Correct ttyslot header declaration conditions (bug 20051).
Fix stdlib.h rand_r namespace (bug 20074).
Make sys/stat.h define S_IFSOCK, S_ISSOCK for XPG4 (bug 20076).
Do not declare grantpt, ptsname, unlockpt in stdlib.h for XPG3 (bug 20094).
Add Q_GETNEXTQUOTA from Linux 4.6 to sys/quota.h.
Add CLONE_NEWCGROUP from Linux 4.6 to bits/sched.h.
Update libm-test.inc comment about NaN signs.
conformtest: Correct search.h expectations for XPG3.
conformtest: Correct pwd.h expectations for XPG3.
Implement proper fmal for ldbl-128ibm (bug 13304).
conformtest: Correct ftw.h expectations for XPG3, XPG4.
Update sysdeps/unix/sysv/linux/bits/socket.h for Linux 4.6.
conformtest: Correct some limits.h expectations for XPG3, XPG4.
Do not raise "inexact" from generic ceil (bug 15479).
Do not raise "inexact" from generic floor (bug 15479).
Do not raise "inexact" from generic round (bug 15479).
Do not raise "inexact" from x86_64 SSE4.1 ceil, floor (bug 15479).
Do not raise "inexact" from powerpc32 ceil, floor, trunc (bug 15479).
Do not raise "inexact" from powerpc64 ceil, floor, trunc (bug 15479).
Support sNaN testing in libm-test.inc.
Add more sNaN tests to libm-test.inc.
Fix ldbl-128 j0l, j1l, y0l, y1l for sNaN argument (bug 20151).
Fix ldbl-128ibm sqrtl (sNaN) (bug 20153).
Fix ldbl-128ibm ceill, rintl etc. for sNaN arguments (bug 20156).
Remove unused macros from libm-test.inc.
Avoid "invalid" exceptions from powerpc fabsl (sNaN) (bug 20157).
Fix powerpc32 ceil, rint etc. on sNaN input (bug 20160).
Fix powerpc64 ceil, rint etc. on sNaN input (bug 20160).
Fix x86/x86_64 nextafterl incrementing negative subnormals (bug 20205).
Fix dbl-64 acos (sNaN) (bug 20212).
Fix dbl-64 asin (sNaN) (bug 20213).
Fix i386 asinhl (sNaN) (bug 20218).
Fix i386 atanhl (sNaN) (bug 20219).
Fix i386 cbrtl (sNaN) (bug 20224).
Fix ldexp, scalbn, scalbln for sNaN input (bug 20225).
Fix i386/x86_64 expl, exp10l, expm1l for sNaN input (bug 20226).
Fix i386/x86_64 logl (sNaN) (bug 20227).
Fix i386/x86_64 log10l (sNaN) (bug 20228).
Fix i386/x86_64 log1pl (sNaN) (bug 20229).
Fix ldbl-128 expm1l (sNaN) (bug 20232).
Fix ldbl-128ibm expm1l (sNaN) (bug 20233).
Fix ldbl-128ibm log1pl (sNaN) (bug 20234).
Fix i386/x86_64 log2l (sNaN) (bug 20235).
Fix modf (sNaN) (bug 20240).
Fix frexp (NaN) (bug 20250).
Add more sNaN tests (cimag, conj, copysign, creal, fma, fmod).
Fix dbl-64 atan2 (sNaN, qNaN) (bug 20252).
Simplify generic fdim implementations.
Use generic fdim on more architectures (bug 6796, bug 20255, bug 20256).
Fix i386 fdim double rounding (bug 20255).
Simplify x86 nearbyint functions.
Add more sNaN tests (most remaining real functions).
Fix i386/x86_64 scalbl with sNaN input (bug 20296).
Avoid "inexact" exceptions in i386/x86_64 ceil functions (bug 15479).
Avoid "inexact" exceptions in i386/x86_64 floor functions (bug 15479).
Avoid "inexact" exceptions in i386/x86_64 trunc functions (bug 15479).
Khem Raj (2):
When disabling SSE, make sure -fpmath is not set to use SSE either
elf: Define missing Meta architecture specific relocations
Maciej W. Rozycki (1):
Treat STV_HIDDEN and STV_INTERNAL symbols as STB_LOCAL
Mark Wielaard (2):
elf/elf.h: Add new 386 and X86_64 relocations from binutils.
elf.h: Add NT_ARM_SYSTEM_CALL constant.
Marko Myllynen (1):
localedef: drop unused --old-style
Martin Galvan (1):
Add pretty printers for the NPTL lock types
Matthew Fortune (1):
VDSO support for MIPS
Matthias Wallnoefer (2):
localedata: de_{AT,CH}: copy data from de_DE
localedata: de_IT: new locale
Mike FABIAN (1):
localedata: i18n: fix typos in tel_int_fmt
Mike Frysinger (44):
locledata: trim trailing blank lines/comments
localedata: dz_BT/ps_AF: reformat data
localedata: CLDRv28: update LC_TELEPHONE.int_prefix
locales: pap_AN: delete old/deprecated locale [BZ #16003]
test-skeleton: increase default TIMEOUT to 20 seconds
localedata: an_ES: fix lang_ab value
localedata: es_PR: change LC_MEASUREMENT to metric
localedata: clear LC_IDENTIFICATION tel/fax fields
link sln fix to bugzilla [BZ #15333]
localedata: use same comment_char/escape_char in these files
add ChangeLog entry
localedata: standardize first few lines
localedata: standardize copyright/license information [BZ #11213]
localedata: iw_IL: delete old/deprecated locale [BZ #16137]
configure: fix `test ==` usage
localedata: CLDRv28: update LC_PAPER values
localedata: LC_TIME.date_fmt: delete entries same as the default value
localedata: CLDRv29: update LC_IDENTIFICATION language/territory fields
localedata: LC_MEASUREMENT: use copy directives everywhere
localedata: LC_PAPER: use copy directives everywhere
localedata: CLDRv29: update LC_ADDRESS.country_num values
localedata: fix LC_ADDRESS.country_car entries
localedata: CLDRv29: update LC_ADDRESS.country_name translations
localedata: LC_IDENTIFICATION.category: set to ISO 30112 2014 standard
localedef: check LC_IDENTIFICATION.category values
localedata: CLDRv29: update LC_MONETARY int_curr_symbol & currency_symbol
localedata: LC_IDENTIFICATION: delete uncommon fields
locale: ld-telephone: update to ISO-30112 2014
localedef: allow %l/%n in postal_fmt [BZ #16983]
localedata: fix LC_TELEPHONE in a few locales
localedata: CLDRv29: update LC_TIME week/first_week,workday fields
localedef: change week_1stweek default to 7
localedata: standard LC_MESSAGES string regexes a bit
localedata: LC_MESSAGES.{yes,no}expr: add +1/-0 to all regexes [BZ #15263]
localedata: LC_MESSAGES.{yes,no}expr: standardize yY/nN [BZ #15262]
localedata: CLDRv29: update LC_MESSAGES yes/no strings [BZ #15264] [BZ #16975]
tst-langinfo: update yesexpr/noexpr baselines
tst-fmon/tst-numeric: switch malloc to static stack space [BZ #19671]
localedata: add more translit entries
localedata: pt_BR/pt_PT: make days/months lowercase [BZ #19133]
unicode-gen: include standard comment file header
NEWS: clarify localedef --old-style update
manual: fix spelling typos
microblaze: fix variable name collision with syscall macros
Neskie Manuel (1):
localedata: chr_US: new Cherokee locale [BZ #12143]
Nick Alcock (2):
x86, pthread_cond_*wait: Do not depend on %eax not being clobbered
Allow overriding of CFLAGS as well as CPPFLAGS for rtld.
Paras pradhan (1):
localedata: ne_NP: misc updates [BZ #1170]
Paul E. Murphy (22):
Increase internal precision of ldbl-128ibm decimal printf [BZ #19853]
powerpc: Add optimized P8 strspn
powerpc: Add optimized strcspn for P8
powerpc: Add missing insn in swapcontext [BZ #20004]
Refactor bug-strtod.c to better test new types.
Refactor bug-strtod2.c to be type generic
Refactor tst-strtod6.c
Refactor tst-strtod-round.c
Fixup usage of MANT_DIG in libm-test.inc
Fixup usage of MIN_EXP in libm-test.inc
Refactor tst-strtod-round.c for type-generic-ness
Begin refactor of libm-test.inc
Refactor type specific macros using regexes
Refactor M_ macros defined in libm-test.inc
Replace M_PI2l with lit_pi_2_d in libm-test.inc
Replace M_PIl with lit_pi in libm-test.inc
Replace M_PI_4l with lit_pi_4_d in libm-test.inc
Replace M_El with lit_e in libm-test.inc
Apply LIT(x) to floating point literals in libm-test.c
Remove CHOOSE() macro from libm-tests.inc
Remove type specific information from auto-libm-test-in
Generate new format names in auto-libm-test-out
Paul Pluzhnikov (7):
2016-03-03 Paul Pluzhnikov <ppluzhnikov@google.com>
2016-05-30 Paul Pluzhnikov <ppluzhnikov@google.com>
Merge branch 'master' of ssh://sourceware.org/git/glibc
2016-06-05 Paul Pluzhnikov <ppluzhnikov@google.com>
2016-06-09 Paul Pluzhnikov <ppluzhnikov@gmail.com>
2016-06-11 Paul Pluzhnikov <ppluzhnikov@google.com>
Fix rt/tst-aio64.c as well, and mention login/tst-utmp.c in ChangeLog
Rajalakshmi Srinivasaraghavan (4):
powerpc: Rearrange cfi_offset calls
powerpc: strcasestr optmization for power8
Add nextup and nextdown math functions
powerpc: Fix return code of strcasecmp for unaligned inputs
Rical Jasan (9):
manual: fix typos in the memory chapter
manual: fix typos in the character handling chapter
manual: fix typos in the string chapters
manual: fix typos in character set handling
manual: fix typos in the locale chapter
manual: fix typos in the locale chapter
manual: fix typos in the message chapter
manual: fix typos in the search chapter
manual: fix typos in the pattern chapter
Richard Henderson (2):
elf.h: Sync with the gabi webpage
elf.h: Add declarations for BPF
Robin van der Vliet (1):
locale: iso-639: add Talossan language [BZ #19400]
Roland McGrath (9):
Add fts64_* to sysdeps/arm/nacl/libc.abilist
Typo fixes.
Gratuitous change to poke buildbot.
Fix c++-types-check conditionalization.
Omit test-math-isinff when no C++ compiler.
Conditionalize c++-types-check.out addition to tests-special.
Fix edito in last change.
Fix tst-audit10 build when -mavx512f is not supported.
stpcpy is part of POSIX.1-2008 [BZ #3629]
Samuel Thibault (23):
Fix flag test in waitid compatibility layer
Fix hurd build
hurd: Break errnos.d / libc-modules.h dependency loop
Fix mach-syscalls.mk build
hurd: Do not hide rtld symbols which need to be preempted
hurd: Allow inlining IO locks
hurd: Add c++-types expected result
Fix malloc threaded tests link on non-Linux
Fix crash on getauxval call without HAVE_AUX_VECTOR
Fix build with HAVE_AUX_VECTOR
hurd: fix profiling short-living processes
Fix gprof timing
non-linux: Apply RFC3542 obsoletion of RFC2292 macros
non-linux: Apply RFC3542 obsoletion of RFC2292 macros
aio: fix newp->running data race
Revert "aio: fix newp->running data race"
hurd: fix _hurd_self_sigstate reference from ____longjmp_chk
Add more hurd exception to local headers list
hurd: disable ifunc for now
mach: Add mach_print sycsall declaration
hurd: Fix PTR_{,DE}MANGLE calls
Add missing changelog part
Fix TABDLY value
Siddhesh Poyarekar (10):
New make target to only build benchmark binaries
Fix up ChangeLog formatting
benchtests: Update README to include instructions for bench-build target
Fix up ChangeLog
benchtests: Clean up extra-objs
benchtests: Support for cross-building benchmarks
Avoid attempt for runtime checks if all environments are defined
Fix up ChangeLog
Revert "Add pretty printers for the NPTL lock types"
Fix cos computation for multiple precision fallback (bz #20357)
Simion Onea (1):
localedata: ro_RO: update Tuesday translation [BZ #18911]
Stefan Liebler (31):
Add missing inclusion of libc-internal.h.
S390: Save and restore fprs/vrs while resolving symbols.
S390: Extend structs La_s390_regs / La_s390_retval with vector-registers.
S390: Use ahi instead of aghi in 32bit _dl_runtime_resolve.
Mention Bug in ChangeLog for S390: Save and restore fprs/vrs while resolving symbols.
Fix strfmon_l: Use specified locale for number formatting [BZ #19633]
Add missing iucv related defines.
S390: Add support for vdso getcpu symbol.
S390: Use fPIC to avoid R_390_GOT12 relocation in gcrt1.o.
Fix tst-cancel17/tst-cancelx17, which sometimes segfaults while exiting.
S390: Use mvcle for copies > 1MB on 32bit with default memcpy variant.
S390: Use 64bit instruction to check for copies of > 1MB with mvcle.
S390: Do not call memcpy, memcmp, memset within libc.so via ifunc-plt.
S390: Implement mempcpy with help of memcpy. [BZ #19765]
S390: Get rid of make warning: overriding recipe for target gconv-modules.
S390: Configure check for vector support in gcc.
S390: Optimize 8bit-generic iconv modules.
S390: Optimize builtin iconv-modules.
S390: Optimize iso-8859-1 to ibm037 iconv-module.
S390: Optimize utf8-utf32 module.
S390: Optimize utf8-utf16 module.
S390: Optimize utf16-utf32 module.
S390: Use s390-64 specific ionv-modules on s390-32, too.
S390: Fix utf32 to utf8 handling of low surrogates (disable cu41).
S390: Fix utf32 to utf16 handling of low surrogates (disable cu42).
Fix ucs4le_internal_loop in error case. [BZ #19726]
Fix UTF-16 surrogate handling. [BZ #19727]
tst-rec-dlopen: Fix build fail due to missing inclusion of string.h
S390: Fix relocation of _nl_current_LC_CATETORY_used in static build. [BZ #19860]
S390: Use DT_JUMPREL in prelink undo code.
S390: Do not clobber r13 with memcpy on 31bit with copies >1MB.
Stephen Gallagher (1):
NSS: Implement group merging support.
Szabolcs Nagy (4):
[AArch64] Fix libc internal asm profiling code
[AArch64] Add bits/hwcap.h for aarch64 linux
[AArch64] Regenerate libm-test-ulps
[AArch64] Update libm-test-ulps
Timur Birsh (1):
localedata: kk_KZ: various updates [BZ #15578]
Torvald Riegel (1):
Remove atomic_compare_and_exchange_bool_rel.
Tulio Magno Quites Machado Filho (3):
Fix type of parameter passed by malloc_consolidate
powerpc: Fix --disable-multi-arch build on POWER8
powerpc: Add a POWER8-optimized version of expf()
Wilco Dijkstra (7):
Improve generic strcspn performance
Remove pre GCC3.2 optimizations from string/bits/string2.h.
Move mempcpy, strcpy and stpcpy inlines to string/string-inlines.c as compatibility
This is an optimized memset for AArch64. Memset is split into 4 main cases:
This is an optimized memcpy/memmove for AArch64. Copies are split into 3 main
Add a simple rawmemchr implementation. Use strlen for rawmemchr(s, '\0') as it
This patch further tunes memcpy - avoid one branch for sizes 1-3,
Will Newton (1):
elf/elf.h: Add missing Meta relocations
Yvan Roux (1):
Suppress GCC 6 warning about ambiguous 'else' with -Wparentheses
Zack Weinberg (3):
Move sysdeps/generic/bits/hwcap.h to top-level bits/
Move sysdeps/generic/bits/hwcap.h to top-level bits/
Don't install the internal header grp-merge.h
raji (1):
powerpc: strcasecmp/strncasecmp optmization for power8
ricaljasan@pacific.net (2):
manual: fix typo in the introduction
manual: fix typos in error reporting
-----------------------------------------------------------------------
|