Update copyright dates not handled by scripts/update-copyrights [committed]
Commit Message
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.
Please remember to include 2017 in the dates for any new files added
in future (which means updating any existing uncommitted patches you
have that add new files to use the new copyright dates in them).
2017-01-01 Joseph Myers <joseph@codesourcery.com>
* NEWS: Update copyright dates.
* catgets/gencat.c (print_version): Likewise.
* csu/version.c (banner): Likewise.
* debug/catchsegv.sh: Likewise.
* debug/pcprofiledump.c (print_version): Likewise.
* debug/xtrace.sh (do_version): Likewise.
* elf/ldconfig.c (print_version): Likewise.
* elf/ldd.bash.in: Likewise.
* elf/pldd.c (print_version): Likewise.
* elf/sotruss.sh: Likewise.
* elf/sprof.c (print_version): Likewise.
* iconv/iconv_prog.c (print_version): Likewise.
* iconv/iconvconfig.c (print_version): Likewise.
* locale/programs/locale.c (print_version): Likewise.
* locale/programs/localedef.c (print_version): Likewise.
* login/programs/pt_chown.c (print_version): Likewise.
* malloc/memusage.sh (do_version): Likewise.
* malloc/memusagestat.c (print_version): Likewise.
* malloc/mtrace.pl: Likewise.
* manual/libc.texinfo: Likewise.
* nptl/version.c (banner): Likewise.
* nscd/nscd.c (print_version): Likewise.
* nss/getent.c (print_version): Likewise.
* nss/makedb.c (print_version): Likewise.
* posix/getconf.c (main): Likewise.
* scripts/test-installation.pl: Likewise.
* sysdeps/unix/sysv/linux/lddlibc4.c (main): Likewise.
Comments
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?)
@@ -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
@@ -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");
}
@@ -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\
@@ -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.'
@@ -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");
}
@@ -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
@@ -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");
}
@@ -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
@@ -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");
}
@@ -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
;;
@@ -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");
}
@@ -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");
}
@@ -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");
}
@@ -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");
}
@@ -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");
}
@@ -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 *
@@ -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
@@ -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");
}
@@ -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";
@@ -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
@@ -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"
@@ -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");
}
@@ -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");
}
@@ -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");
}
@@ -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;
}
@@ -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";
@@ -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;
}