| Message ID | alpine.DEB.2.20.1701010026470.408@digraph.polyomino.org.uk |
|---|---|
| State | New |
| Headers | show |
On 01/01/2017 01:27 AM, Joseph Myers wrote: > I've updated copyright dates in glibc for 2017. This is the patch for > the changes not generated by scripts/update-copyrights and subsequent > build / regeneration of generated files. Could we rotate the ChangeLog file, too, please? Thanks, Florian
On 01 Jan 2017 08:22, Florian Weimer wrote: > On 01/01/2017 01:27 AM, Joseph Myers wrote: > > I've updated copyright dates in glibc for 2017. This is the patch for > > the changes not generated by scripts/update-copyrights and subsequent > > build / regeneration of generated files. > > Could we rotate the ChangeLog file, too, please? can we stuff them into a subdir too ? maybe manual/ for lack of a better pace ? we've got 33 of these things cluttering up the toplevel. even better: let's delete them and be done. -mike
On Sun, 1 Jan 2017, Florian Weimer wrote: > On 01/01/2017 01:27 AM, Joseph Myers wrote: > > I've updated copyright dates in glibc for 2017. This is the patch for > > the changes not generated by scripts/update-copyrights and subsequent > > build / regeneration of generated files. > > Could we rotate the ChangeLog file, too, please? ChangeLog rotation was previously objected to in <https://sourceware.org/ml/libc-alpha/2013-06/msg00305.html>. What I think we should now aim for regarding ChangeLogs - not during a freeze apart maybe from the first step - is: 1. Move libidn/ChangeLog to ChangeLog.libidn, localedata/ChangeLog to ChangeLog.localedata, stop using separate ChangeLogs for those subdirectories and just put everything in the toplevel ChangeLog. 2. Develop conventions for embedding ChangeLog entries in git commit messages to support automatic ChangeLog generation. Develop a script to be run from the pre-receive hook that rejects master and release branch updates unless they have a properly formatted ChangeLog entry following those conventions in their commit messages for each pushed commit (or follow appropriate conventions for indicating a commit that deliberately does not have a ChangeLog entry). Develop a script that updates ChangeLog with the messages for all commits since that script was last run. 3. Declare a flag day, at which ChangeLog is renamed to ChangeLog.18 and future commits do not add entries to ChangeLog except as a result of running that script. 4. As the last commit before a release is tagged, the script would be run to update ChangeLog and the results committed, so that releases can continue to be built with "git archive". In addition, if a mistake or omission in a ChangeLog entry in a past commit message is to be corrected, the approach would be to run the script, commit the results, then edit the resulting ChangeLog content; this avoids the need for any on-the-side list of edits to ChangeLog entries. Not needing to be done as part of the move to automatically generated ChangeLogs, but facilitated by it, would be arranging for patchwork to automatically mark patches committed when the git-patch-id of a commit is the same as that of a patch in patchwork (because it would become normal for a patch posted for review to be the same as the patch that gets committed). This would reduce the extent to which patchwork fills up with patches that have in fact been committed, although manual work is still needed to deal with the backlog (both reviewing patches that need review, and updating entries for patches that have in fact been committed or superseded).
On 01/02/2017 02:45 PM, Joseph Myers wrote: > On Sun, 1 Jan 2017, Florian Weimer wrote: > >> On 01/01/2017 01:27 AM, Joseph Myers wrote: >>> I've updated copyright dates in glibc for 2017. This is the patch for >>> the changes not generated by scripts/update-copyrights and subsequent >>> build / regeneration of generated files. >> >> Could we rotate the ChangeLog file, too, please? > > ChangeLog rotation was previously objected to in > <https://sourceware.org/ml/libc-alpha/2013-06/msg00305.html>. My problem with the current situation is that the compress Git object for the main ChangeLog file is now around 800K. I have currently 37 such compressed objects in my git tree which cannot be packed, and that's quite inconvenient when rsync'ing things around. Rotating the ChangeLog would be a very low-tech solution to mitigate this issue. Thanks, Florian
On Mon, 2 Jan 2017, Florian Weimer wrote: > > > Could we rotate the ChangeLog file, too, please? > > > > ChangeLog rotation was previously objected to in > > <https://sourceware.org/ml/libc-alpha/2013-06/msg00305.html>. > > My problem with the current situation is that the compress Git object for the > main ChangeLog file is now around 800K. I have currently 37 such compressed > objects in my git tree which cannot be packed, and that's quite inconvenient > when rsync'ing things around. > > Rotating the ChangeLog would be a very low-tech solution to mitigate this > issue. Well, I don't object to either ad hoc rotation to ChangeLog.18, or rearranging past ChangeLogs by date, independent of a move to automatically generated ChangeLogs. But the previous discussion is evidence of a lack of consensus. (Correction to my previous message about renaming ChangeLogs: the existing convention when stopping using ChangeLogs in a subdirectory would be to rename to e.g. libidn/ChangeLog.old, as done in nptl/ and nptl_db/, not to toplevel ChangeLog.libidn.)
On Sun, 2017-01-01 at 04:57 -0500, Mike Frysinger wrote:
> even better: let's delete them and be done.
Yes, please.
The last discussion of this that I saw was in August 2015. When Mike
proposed to get rid of Changelogs back then, there weren't any reasons
given in response why we would still need to maintain them (sorry if I
missed any); only Andreas mentioned that a tarball release wouldn't have
them.
To me personally, Changelogs are write-only data -- meaning they have no
value for me, and are just overhead. It's not a challenging task for
sure, but you have to pay attention to not make little stupid mistakes,
and I find myself just writing short information there like
* file (function): Adapt.
I'd much rather see us putting all the time required for the changelog
into actually improving the commit message (ie, the reasons for applying
the patch).
Can we please again compare the time we spend on maintaining changelogs
against the time we potentially gain for ... well, something that hasn't
been mentioned in the 2015 discussion? I suspect the effort spent is
much bigger than the gain.
On Mon, 2 Jan 2017, Torvald Riegel wrote: > On Sun, 2017-01-01 at 04:57 -0500, Mike Frysinger wrote: > > even better: let's delete them and be done. > > Yes, please. The old logs are routinely useful for identifying the logical changesets for changes before the move to git. The newer logs are a matter of the GNU Coding Standards. That is, if you don't want to maintain information about "what" changed in that particular form, you should be persuading the GCS maintainers to allow just logging descriptions of what and why changed at the logical level rather than the level of individual files and functions (in the case where a version control system provides tracking of the "what" ... not all GNU packages have public version control). Absent such a GCS change, we can still move to automatic generation but that requires various infrastructure work such as I outlined.
On Mon, 2017-01-02 at 15:23 +0000, Joseph Myers wrote: > On Mon, 2 Jan 2017, Torvald Riegel wrote: > > > On Sun, 2017-01-01 at 04:57 -0500, Mike Frysinger wrote: > > > even better: let's delete them and be done. > > > > Yes, please. > > The old logs are routinely useful for identifying the logical changesets > for changes before the move to git. That's true. My hate for them was a little strong it seems ;) The old logs should not be removed. > The newer logs are a matter of the GNU Coding Standards. That is, if you > don't want to maintain information about "what" changed in that particular > form, you should be persuading the GCS maintainers to allow just logging > descriptions of what and why changed at the logical level rather than the > level of individual files and functions (in the case where a version > control system provides tracking of the "what" ... not all GNU packages > have public version control). Are you saying that from your point of view, GCS is the only significant reason for maintaining changelogs? In my opinion, the coding standards need to serve the projects. If we can find consensus in glibc that it does not give us a net win, then it doesn't serve us. One could still argue that it may serve users/developers that are not interacting with the glibc community directly (in which case they'd be told to just use git, please...); However, beyond grouping changes (ie, "logical change sets" as you write above), the changelogs aren't really useful IMO: they details vary a lot regarding "what", and "why is mostly not covered at all. Thus, developers outside of the glibc developer community would still have to consult libc-alpha or the git logs, so I see no significant benefit of the changelogs. > Absent such a GCS change, we can still move > to automatic generation but that requires various infrastructure work such > as I outlined. Yes, and just to be clear, I think something like what you outline would be a benefit over the existing situation. However, I'd much prefer for you (or/and everyone else) to not have to spend the effort on that infrastructure work and just get rid of changelogs. Maybe we should just announce that we'll stop doing changelogs and see whether anybody complains. If people complain, it would be interesting to see whether they can show that what they perceive as a loss when not having changelogs is larger than the win for the glibc developers (and thus all of glibc's users, indirectly).
Joseph, the scheme you propose is close to what is used for GNU Emacs: everything is in a top-level ChangeLog, commit messages are in ChangeLog format, a script autogenerates the ChangeLog file, and the autogenerated ChangeLog file is committed just before release (and just before corrections are made). Unfortunately there's a problem with this approach: it's a pain to merge. This is because different branches can have different committed ChangeLog files, which are mostly autogenerated but contain some hand edits. The autogenerated parts of these files are not necessarily in the same order even for the parts that are in common (because that's how 'git log' works). We have not solved this problem in Emacs, so in practice one branch (the release branch) has a decent ChangeLog file, the other branches are a mess, and after a release a massive ChangeLog cleanup is needed to the next branch (a cleanup that never gets done right). I see several ways out of this problem: 1. Adopt the approach used in GNU coreutils etc., which have on-the-side lists of edits to ChangeLog entries. You've rejected this, and perhaps rightly so, as being too much of a pain to maintain. 2. Use a procedure based on "git notes" (or some other Git-based metadata) to store edits to commit messages. This would also be a pain to maintain, most likely, though perhaps less than (1). 3. Write a tool for merging mostly-autogenerated but partly hand-edited ChangeLogs. Unfortunately the only way to debug this would be to use it for a while and in the meantime ChangeLogs will likely be in a mess. No one has gotten up the energy to do this for Emacs. 4. Never fix ChangeLog entries. Only auto-generate them. If they're wrong, they're wrong: history records mistakes as well as successes. 5. Do not bother to auto-generate ChangeLog files. People interested in history can look at the Git history. 6. Like (5), but also delete existing ChangeLog files. As I understand it, this is what Mike Frysinger proposes.
On Mon, 2 Jan 2017, Torvald Riegel wrote: > > The newer logs are a matter of the GNU Coding Standards. That is, if you > > don't want to maintain information about "what" changed in that particular > > form, you should be persuading the GCS maintainers to allow just logging > > descriptions of what and why changed at the logical level rather than the > > level of individual files and functions (in the case where a version > > control system provides tracking of the "what" ... not all GNU packages > > have public version control). > > Are you saying that from your point of view, GCS is the only significant > reason for maintaining changelogs? My suggestion is that it would be reasonable to argue to the GCS maintainers that ChangeLog-format logs need not be maintained for a package for which all of the following are true: * it has public version control, * in a distributed VCS, * where commits are made for each logical change, not batched into a commit per release (see bash for an example of such batching) or per day or other such batching, * with authors not just committers tracked, * with commit messages describing the logical "what" changed (but not describing the physical "what" at the level of changes to individual files and functions). That is, when all the above are true, the information about changes is more usefully available through the VCS than through ChangeLog-style messages and people wanting that information will be expecting to go to the VCS for it rather than to find it in the release tarballs, so ChangeLog-style messages can be considered obsoleted by the VCS in that case (and in that case, the GCS requirements for ChangeLog files do not serve a useful technical purpose - this is a separate matter from any legal reasons there might be for including such information about changes and their authorship in release tarballs). > Maybe we should just announce that we'll stop doing changelogs and see > whether anybody complains. If people complain, it would be interesting That's not an appropriate way to work for a GNU package. We need to work with the GNU project (and quite possibly, the FSF in turn work with their lawyers to establish if there are any legal reasons relating to attribution of changes within releases). If the GCS were then changed along the lines I propose above, we'd still need to establish appropriate conventions for commit message contents - that is, that any nontrivial change should include a description in the commit message along the lines of what goes in the mailing list posting of the patch. But we can of course establish such a rule for meaningful commit messages independently of a change to the GCS.
On Mon, 2 Jan 2017, Paul Eggert wrote: > Unfortunately there's a problem with this approach: it's a pain to merge. This > is because different branches can have different committed ChangeLog files, > which are mostly autogenerated but contain some hand edits. The autogenerated Since in practice we don't do point releases from branches in glibc, with my proposal (absent persuading the GCS maintainers of the non-utility for ChangeLogs in certain cases) ChangeLogs would most likely only ever be updated on master, not on branches. Branches would have commit messages following the relevant conventions, but the script probably wouldn't be run there.
On Mon, 2 Jan 2017, Joseph Myers wrote: > * it has public version control, > > * where commits are made for each logical change, not batched into a > commit per release (see bash for an example of such batching) or per day > or other such batching, And, frankly, I think maintain.texi should make these two into requirements for GNU packages rather than the present "It is very important to keep backup files of all source files of GNU. You can do this using a source control system (such as Bazaar, RCS, CVS, Git, Subversion, @dots{}) if you like.". But that's a separate issue from not requiring ChangeLogs in certain cases.
On Mon, 2017-01-02 at 17:19 +0000, Joseph Myers wrote: > On Mon, 2 Jan 2017, Torvald Riegel wrote: > > > > The newer logs are a matter of the GNU Coding Standards. That is, if you > > > don't want to maintain information about "what" changed in that particular > > > form, you should be persuading the GCS maintainers to allow just logging > > > descriptions of what and why changed at the logical level rather than the > > > level of individual files and functions (in the case where a version > > > control system provides tracking of the "what" ... not all GNU packages > > > have public version control). > > > > Are you saying that from your point of view, GCS is the only significant > > reason for maintaining changelogs? > > My suggestion is that it would be reasonable to argue to the GCS > maintainers that ChangeLog-format logs need not be maintained for a > package for which all of the following are true: > > * it has public version control, > > * in a distributed VCS, > > * where commits are made for each logical change, not batched into a > commit per release (see bash for an example of such batching) or per day > or other such batching, > > * with authors not just committers tracked, > > * with commit messages describing the logical "what" changed (but not > describing the physical "what" at the level of changes to individual files > and functions). > > That is, when all the above are true, the information about changes is > more usefully available through the VCS than through ChangeLog-style > messages and people wanting that information will be expecting to go to > the VCS for it rather than to find it in the release tarballs, so > ChangeLog-style messages can be considered obsoleted by the VCS in that > case (and in that case, the GCS requirements for ChangeLog files do not > serve a useful technical purpose - Thanks. That's a useful ruleset. > this is a separate matter from any > legal reasons there might be for including such information about changes > and their authorship in release tarballs). > > > Maybe we should just announce that we'll stop doing changelogs and see > > whether anybody complains. If people complain, it would be interesting > > That's not an appropriate way to work for a GNU package. We need to work > with the GNU project (and quite possibly, the FSF in turn work with their > lawyers to establish if there are any legal reasons relating to > attribution of changes within releases). So, who should this go to at the FSF side? maintainers@gnu.org? Do you want to start this discussion? Or can I just copy-and-paste what you wrote above? Do we have consensus in glibc that aside from any legal considerations regarding attribution (an important point you made, thanks), we'd like to have a rule like the one you proposed above in place so we don't have to maintain changelogs? Regarding the legal considerations, do we need anything else beyond the FSF's opinion on this?
On Mon, 2 Jan 2017, Torvald Riegel wrote: > So, who should this go to at the FSF side? maintainers@gnu.org? bug-standards is the relevant public mailing list. (In practice it's RMS and Karl Berry who maintain the GCS, I think.) > Do you want to start this discussion? Or can I just copy-and-paste what > you wrote above? I suggest you start it. > Regarding the legal considerations, do we need anything else beyond the > FSF's opinion on this? It's a matter of persuading the GCS maintainers to change the requirements. Presumably if they are persuaded that the change makes technical sense they'll take any legal advice needed.
On Mon, 2017-01-02 at 17:27 +0000, Joseph Myers wrote: > On Mon, 2 Jan 2017, Joseph Myers wrote: > > > * it has public version control, > > > > * where commits are made for each logical change, not batched into a > > commit per release (see bash for an example of such batching) or per day > > or other such batching, > > And, frankly, I think maintain.texi should make these two into > requirements for GNU packages rather than the present "It is very > important to keep backup files of all source files of GNU. You can do this > using a source control system (such as Bazaar, RCS, CVS, Git, Subversion, > @dots{}) if you like.". Agreed. It would also help if the GNU coding standards would be clearer regarding separating requirements from recommendations/opinions/taste. For examples, nuggets such as " C++ is ok too, but please don’t make heavy use of templates." certainly can't be a general requirement (that would apply to libstdc++, for example). > But that's a separate issue from not requiring > ChangeLogs in certain cases. > Agreed.
On Mon, 2017-01-02 at 17:19 +0000, Joseph Myers wrote: > If the GCS were then changed along the lines I propose above, we'd still > need to establish appropriate conventions for commit message contents - > that is, that any nontrivial change should include a description in the > commit message along the lines of what goes in the mailing list posting of > the patch. But we can of course establish such a rule for meaningful > commit messages independently of a change to the GCS. I think we should do the latter (though I had assumed we already do require that?)
diff --git a/NEWS b/NEWS index b928e19..12880fa 100644 --- a/NEWS +++ b/NEWS @@ -3574,7 +3574,7 @@ Version 1.04 ---------------------------------------------------------------------- Copyright information: -Copyright (C) 1992-2016 Free Software Foundation, Inc. +Copyright (C) 1992-2017 Free Software Foundation, Inc. Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the diff --git a/catgets/gencat.c b/catgets/gencat.c index 839276a..6fd1de7 100644 --- a/catgets/gencat.c +++ b/catgets/gencat.c @@ -246,7 +246,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/csu/version.c b/csu/version.c index 32f01a5..e0d884d 100644 --- a/csu/version.c +++ b/csu/version.c @@ -25,7 +25,7 @@ static const char __libc_version[] = VERSION; static const char banner[] = "GNU C Library "PKGVERSION RELEASE" release version "VERSION", by Roland McGrath et al.\n\ -Copyright (C) 2016 Free Software Foundation, Inc.\n\ +Copyright (C) 2017 Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions.\n\ There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A\n\ PARTICULAR PURPOSE.\n\ diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh index 72962e2..db4154a 100755 --- a/debug/catchsegv.sh +++ b/debug/catchsegv.sh @@ -40,7 +40,7 @@ EOF ;; --v | --ve | --ver | --vers | --versi | --versio | --version) echo 'catchsegv @PKGVERSION@@VERSION@' - echo 'Copyright (C) 2016 Free Software Foundation, Inc. + echo 'Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Ulrich Drepper.' diff --git a/debug/pcprofiledump.c b/debug/pcprofiledump.c index 8366304..a32cdef 100644 --- a/debug/pcprofiledump.c +++ b/debug/pcprofiledump.c @@ -226,6 +226,6 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/debug/xtrace.sh b/debug/xtrace.sh index de68e53..fd14f29 100755 --- a/debug/xtrace.sh +++ b/debug/xtrace.sh @@ -64,7 +64,7 @@ do_version() { printf $"Copyright (C) %s Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -" "2016" +" "2017" printf $"Written by %s. " "Ulrich Drepper" exit 0 diff --git a/elf/ldconfig.c b/elf/ldconfig.c index 723d392..99caf9e 100644 --- a/elf/ldconfig.c +++ b/elf/ldconfig.c @@ -325,7 +325,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Andreas Jaeger"); } diff --git a/elf/ldd.bash.in b/elf/ldd.bash.in index 1a97a61..7dd1fcc 100644 --- a/elf/ldd.bash.in +++ b/elf/ldd.bash.in @@ -38,7 +38,7 @@ while test $# -gt 0; do printf $"Copyright (C) %s Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -" "2016" +" "2017" printf $"Written by %s and %s. " "Roland McGrath" "Ulrich Drepper" exit 0 diff --git a/elf/pldd.c b/elf/pldd.c index 6755253..ddfa88d 100644 --- a/elf/pldd.c +++ b/elf/pldd.c @@ -269,7 +269,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/elf/sotruss.sh b/elf/sotruss.sh index be102bd..c83e837 100755 --- a/elf/sotruss.sh +++ b/elf/sotruss.sh @@ -75,7 +75,7 @@ while test $# -gt 0; do printf $"Copyright (C) %s Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -" "2016" +" "2017" printf $"Written by %s.\n" "Ulrich Drepper" exit 0 ;; diff --git a/elf/sprof.c b/elf/sprof.c index 60e3101..85c4975 100644 --- a/elf/sprof.c +++ b/elf/sprof.c @@ -391,7 +391,7 @@ Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ "), - "2016"); + "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/iconv/iconv_prog.c b/iconv/iconv_prog.c index a029036..1397d2e 100644 --- a/iconv/iconv_prog.c +++ b/iconv/iconv_prog.c @@ -426,7 +426,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/iconv/iconvconfig.c b/iconv/iconvconfig.c index 65ea111..9be4111 100644 --- a/iconv/iconvconfig.c +++ b/iconv/iconvconfig.c @@ -397,7 +397,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/locale/programs/locale.c b/locale/programs/locale.c index 6384c5c..9412900 100644 --- a/locale/programs/locale.c +++ b/locale/programs/locale.c @@ -295,7 +295,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/locale/programs/localedef.c b/locale/programs/localedef.c index 559a114..6acc134 100644 --- a/locale/programs/localedef.c +++ b/locale/programs/localedef.c @@ -393,7 +393,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/login/programs/pt_chown.c b/login/programs/pt_chown.c index 4875ac5..f12064b 100644 --- a/login/programs/pt_chown.c +++ b/login/programs/pt_chown.c @@ -64,7 +64,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); } static char * diff --git a/malloc/memusage.sh b/malloc/memusage.sh index 3999af5..93ece87 100755 --- a/malloc/memusage.sh +++ b/malloc/memusage.sh @@ -71,7 +71,7 @@ do_version() { printf $"Copyright (C) %s Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -" "2016" +" "2017" printf $"Written by %s. " "Ulrich Drepper" exit 0 diff --git a/malloc/memusagestat.c b/malloc/memusagestat.c index 78af427..0bd158b 100644 --- a/malloc/memusagestat.c +++ b/malloc/memusagestat.c @@ -582,6 +582,6 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/malloc/mtrace.pl b/malloc/mtrace.pl index fa3716e..4acbd81 100644 --- a/malloc/mtrace.pl +++ b/malloc/mtrace.pl @@ -45,7 +45,7 @@ arglist: while (@ARGV) { $ARGV[0] eq "--vers" || $ARGV[0] eq "--versi" || $ARGV[0] eq "--versio" || $ARGV[0] eq "--version") { print "mtrace $PKGVERSION$VERSION\n"; - print "Copyright (C) 2016 Free Software Foundation, Inc.\n"; + print "Copyright (C) 2017 Free Software Foundation, Inc.\n"; print "This is free software; see the source for copying conditions. There is NO\n"; print "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n"; print "Written by Ulrich Drepper <drepper\@gnu.org>\n"; diff --git a/manual/libc.texinfo b/manual/libc.texinfo index c4138db..9c6a5d5 100644 --- a/manual/libc.texinfo +++ b/manual/libc.texinfo @@ -53,7 +53,7 @@ This is @value{VERSION} @value{PKGVERSION}. @end ifclear -Copyright @copyright{} 1993--2016 Free Software Foundation, Inc. +Copyright @copyright{} 1993--2017 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version diff --git a/nptl/version.c b/nptl/version.c index b4f5d99..d9513fb 100644 --- a/nptl/version.c +++ b/nptl/version.c @@ -23,7 +23,7 @@ static const char banner[] = #include "banner.h" -"Copyright (C) 2016 Free Software Foundation, Inc.\n\ +"Copyright (C) 2017 Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions.\n\ There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A\n\ PARTICULAR PURPOSE.\n" diff --git a/nscd/nscd.c b/nscd/nscd.c index 86033a7..69ef413 100644 --- a/nscd/nscd.c +++ b/nscd/nscd.c @@ -510,7 +510,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Thorsten Kukuk and Ulrich Drepper"); } diff --git a/nss/getent.c b/nss/getent.c index 67e131f..8f8c3fe 100644 --- a/nss/getent.c +++ b/nss/getent.c @@ -87,7 +87,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Thorsten Kukuk"); } diff --git a/nss/makedb.c b/nss/makedb.c index 5e6cd11..542244d 100644 --- a/nss/makedb.c +++ b/nss/makedb.c @@ -386,7 +386,7 @@ print_version (FILE *stream, struct argp_state *state) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); fprintf (stream, gettext ("Written by %s.\n"), "Ulrich Drepper"); } diff --git a/posix/getconf.c b/posix/getconf.c index b6a50da..0155848 100644 --- a/posix/getconf.c +++ b/posix/getconf.c @@ -486,7 +486,7 @@ main (int argc, char *argv[]) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); printf (gettext ("Written by %s.\n"), "Roland McGrath"); return 0; } diff --git a/scripts/test-installation.pl b/scripts/test-installation.pl index 7d2e85a..c5b9fde 100755 --- a/scripts/test-installation.pl +++ b/scripts/test-installation.pl @@ -59,7 +59,7 @@ arglist: while (@ARGV) { $ARGV[0] eq "--vers" || $ARGV[0] eq "--versi" || $ARGV[0] eq "--versio" || $ARGV[0] eq "--version") { print "test-installation (GNU $PACKAGE)\n"; - print "Copyright (C) 2016 Free Software Foundation, Inc.\n"; + print "Copyright (C) 2017 Free Software Foundation, Inc.\n"; print "This is free software; see the source for copying conditions. There is NO\n"; print "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n"; print "Written by Andreas Jaeger <aj\@arthur.rhein-neckar.de>\n"; diff --git a/sysdeps/unix/sysv/linux/lddlibc4.c b/sysdeps/unix/sysv/linux/lddlibc4.c index 5e0092c..25c4cb9 100644 --- a/sysdeps/unix/sysv/linux/lddlibc4.c +++ b/sysdeps/unix/sysv/linux/lddlibc4.c @@ -69,7 +69,7 @@ main (int argc, char *argv[]) Copyright (C) %s Free Software Foundation, Inc.\n\ This is free software; see the source for copying conditions. There is NO\n\ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\ -"), "2016"); +"), "2017"); return 0; }