[1/1,V2] manual/time.texi: correct the zoneinfo path
Commit Message
The 'new' data directory path is about to have its
21st birthday. The info page needs to celebrate
with it.
glibc/ChangeLog.4:1828:
Sat Jul 16 00:42:30 1994 Roland McGrath (roland@churchy.gnu.ai.mit.edu)
* Makeconfig (datadir): Default to $(prefix)/share, not $(prefix)/lib.
(sysconfdir): Variable renamed from etcdir.
glibc/ChangeLog.4:1709:
Fri Jul 29 01:50:37 1994 Roland McGrath <roland@churchy.gnu.ai.mit.edu>
* Version 1.08.4.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
ChangeLog | 5 +++++
manual/time.texi | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
Comments
On 02/01/2015 08:36 PM, J William Piggott wrote:
>
> The 'new' data directory path is about to have its
> 21st birthday. The info page needs to celebrate
> with it.
>
> glibc/ChangeLog.4:1828:
> Sat Jul 16 00:42:30 1994 Roland McGrath (roland@churchy.gnu.ai.mit.edu)
> * Makeconfig (datadir): Default to $(prefix)/share, not $(prefix)/lib.
> (sysconfdir): Variable renamed from etcdir.
> glibc/ChangeLog.4:1709:
> Fri Jul 29 01:50:37 1994 Roland McGrath <roland@churchy.gnu.ai.mit.edu>
> * Version 1.08.4.
>
> Signed-off-by: J William Piggott <elseifthen@gmx.com>
Applied.
We try to have bugs for all the user-visible changes we make,
so I created bug 17969 for this.
Cheers,
Carlos.
On 02/12/2015 10:24 PM, Carlos O'Donell wrote:
>
> Applied.
Thank you Carlos.
Could you clarify one more thing for me please? The contribution
checklist says that Changelog entries should not be sent as a patch, but
I see that many people do so. Which is the preferred way?
Thank you,
William
On 02/13/2015 04:47 PM, J William Piggott wrote:
> On 02/12/2015 10:24 PM, Carlos O'Donell wrote:
>>
>> Applied.
>
> Thank you Carlos.
>
> Could you clarify one more thing for me please? The contribution
> checklist says that Changelog entries should not be sent as a patch, but
> I see that many people do so. Which is the preferred way?
To be honest, as a patch. I'm going to change the contribution checklist.
As a patch it allows me to use patchwork to pull down the patch, git am,
and then let my merge driver fix it up or fixup manually.
c.
> To be honest, as a patch. I'm going to change the contribution checklist.
A consensus of one?
> As a patch it allows me to use patchwork to pull down the patch, git am,
> and then let my merge driver fix it up or fixup manually.
The main reason it has always been policy not to include ChangeLog diffs in
a patch is that the context (i.e. top few lines of the file) always changes
and so the patch fails to apply. If it does happen to apply because of
successful context matching, that puts the new log entry someplace other
than at the top of the line, which is not allowed.
On Fri, 13 Feb 2015, Roland McGrath wrote:
> > To be honest, as a patch. I'm going to change the contribution checklist.
>
> A consensus of one?
>
> > As a patch it allows me to use patchwork to pull down the patch, git am,
> > and then let my merge driver fix it up or fixup manually.
>
> The main reason it has always been policy not to include ChangeLog diffs in
> a patch is that the context (i.e. top few lines of the file) always changes
> and so the patch fails to apply. If it does happen to apply because of
> successful context matching, that puts the new log entry someplace other
> than at the top of the line, which is not allowed.
I also say that ChangeLog diffs should not appear in the patch. Even if
it's applied at the top because of custom merge handling, you still need
to add the bug number to NEWS, and still need to update the date on the
ChangeLog entry to reflect the date of commit, and still need to
regenerate any generated files not included in the diff.
On 02/13/2015 06:16 PM, Roland McGrath wrote:
>> To be honest, as a patch. I'm going to change the contribution checklist.
>
> A consensus of one?
Sorry, my intent was to simply start a new discussion on the topic.
>> As a patch it allows me to use patchwork to pull down the patch, git am,
>> and then let my merge driver fix it up or fixup manually.
>
> The main reason it has always been policy not to include ChangeLog diffs in
> a patch is that the context (i.e. top few lines of the file) always changes
> and so the patch fails to apply. If it does happen to apply because of
> successful context matching, that puts the new log entry someplace other
> than at the top of the line, which is not allowed.
Right.
The mean reason I want everything in the patch is so that I can do:
pwclient get XXX
patch -1 < foo.patch
or
git am foo.patch
Then I fixup ChangeLog quickly.
Alternatively I would have to cut and paste from foo.patch to
ChangeLog.
This discussion however is going to degenerate quickly into "Why
do we need ChangeLogs" and that's not a useful place to go.
I will instead take this time to look over again how to do ChangeLog
auto-generation from commit meta-data, to solve this problem more easily.
Cheers,
Carlos.
On Fri, 13 Feb 2015, Carlos O'Donell wrote:
> I will instead take this time to look over again how to do ChangeLog
> auto-generation from commit meta-data, to solve this problem more easily.
I advise looking at the gnulib gitlog-to-changelog script for that
purpose. Things to consider include the handling of commits with multiple
authors for the ChangeLog entry, handling post-commit corrections
(including to authors and dates), choice of date for the generated
ChangeLog entries (commit date is probably better than author date, people
rebasing sometimes end up pushing changes where the author date is months
ago), handling the separate ChangeLogs still used for libidn and
localedata, and distinguishing the long description of the rationale for a
change (which should be included in the commit message, not just the
summary line and ChangeLog entry) from the description of what changed
that goes in the ChangeLog entry.
I'm not sure how much of that gitlog-to-changelog handles, but it seems a
reasonable starting point. And we could always consider such things as
stopping using the remaining subdirectory ChangeLogs, or putting the full
rationale in the generated ChangeLog rather than just the description of
what changed, if desired.
(I suppose "make dist" could no longer use git archive unless the release
process involves committing the generated ChangeLog before tagging /
branching / releasing.)
@@ -1,3 +1,8 @@
+2015-01-16 J William Piggott <elseifthen@gmx.com>
+
+ * manual/time.texi: correct the zoneinfo path in the TZ Variable
+ node.
+
2015-01-31 David S. Miller <davem@davemloft.net>
* sysdeps/sparc/sparc32/bits/atomic.h
@@ -2509,11 +2509,11 @@ rule for choosing the default time zone, so there is little we can say
about them.
@cindex time zone database
-@pindex /share/lib/zoneinfo
+@pindex /usr/share/zoneinfo
@pindex zoneinfo
If @var{characters} begins with a slash, it is an absolute file name;
otherwise the library looks for the file
-@w{@file{/share/lib/zoneinfo/@var{characters}}}. The @file{zoneinfo}
+@w{@file{/usr/share/zoneinfo/@var{characters}}}. The @file{zoneinfo}
directory contains data files describing local time zones in many
different parts of the world. The names represent major cities, with
subdirectories for geographical areas; for example,