Joel E. Denny wrote:
> On Tue, 4 Aug 2009, Karl Berry wrote:
>
>> It definitely would be nice, and I've contemplated doing so from time to
>> time, but it never seemed like a big enough deal with which to occupy
>> rms's time discussing.
>
> I understand.
>
>> So, the consensus is that we shou
On Tue, 4 Aug 2009, Karl Berry wrote:
> 5. Inconsistent line prefix. In many cases, it's a C-style comment such
> that "/*" appears only on the first line. In some cases, it's just
> inconsistent indentation.
>
> For better or worse, it's very common to have /* or just * preceding
On Tue, 4 Aug 2009, Karl Berry wrote:
> It definitely would be nice, and I've contemplated doing so from time to
> time, but it never seemed like a big enough deal with which to occupy
> rms's time discussing.
I understand.
> So, the consensus is that we should make (C) completely optional?
Joel E. Denny wrote:
> On Wed, 5 Aug 2009, Eric Blake wrote:
>
>> > +if ( diff --version < /dev/null 2>&1 | grep GNU ) 2>&1 > /dev/null;
>> > then
>> > + compare() { diff -u "$@"; }
>>
>> 'diff -u' is required by POSIX 2008. Rather than filtering on
>> whether 'diff --version' includes GNU, it wo
On Wed, 5 Aug 2009, Eric Blake wrote:
> > +if ( diff --version < /dev/null 2>&1 | grep GNU ) 2>&1 > /dev/null;
> > then
> > + compare() { diff -u "$@"; }
>
> 'diff -u' is required by POSIX 2008. Rather than filtering on
> whether 'diff --version' includes GNU, it would be better to
> filter on
> +if ( diff --version < /dev/null 2>&1 | grep GNU ) 2>&1 > /dev/null;
> then
> + compare() { diff -u "$@"; }
'diff -u' is required by POSIX 2008. Rather than filtering on
whether 'diff --version' includes GNU, it would be better to
filter on whether 'diff -u' is accepted on the command line,
to
On Tue, 4 Aug 2009, Joel E. Denny wrote:
> > [BTW, it'd be good to use a "compare" function as defined in
> > test-vc-list-files-cvs.sh, in case diff is not available or
> > does not honor the -u option. ]
>
> Ok.
The following patch implements that. Unlike test-vc-list-files-cvs.sh, I
decided
5. Inconsistent line prefix. In many cases, it's a C-style comment such
that "/*" appears only on the first line. In some cases, it's just
inconsistent indentation.
For better or worse, it's very common to have /* or just * preceding the
copyright line ...
The GNU maintainers documentation says:
Ah, yes, you're right, sorry. I was thinking of the paragraph I added
to gpl-howto.html on the web site:
Always use the English word “Copyright”; by international
convention, this is used worldwide, even for material in other
languages. The copyright s
On Tue, 4 Aug 2009, Karl Berry wrote:
> > Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
> with no
> > "(C)") the preferred form?
>
> It's recommended by the GNU coding standards and GNU maintainers
> documentation.
>
> The (C) is neither recommended nor
> Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
with no
> "(C)") the preferred form?
It's recommended by the GNU coding standards and GNU maintainers
documentation.
The (C) is neither recommended nor disrecommended, though I admit most
of the examples (wr
> 2. No "(C)" after "Copyright".
Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
with no "(C)") the preferred form?
It is correct (to the best of my knowledge) that the "(C)" is
insignificant. It is harmless to have it, though. It should be neither
required no
On Tue, 4 Aug 2009, Jim Meyering wrote:
> > diff --git a/ChangeLog b/ChangeLog
> > index ba72930..9591fdb 100644
> > --- a/ChangeLog
> > +++ b/ChangeLog
> > @@ -23,6 +23,12 @@
> >
> > 2009-08-03 Joel E. Denny
> >
> > + update-copyright: support @copyright{} and ©
> > + * build-aux/update-c
On Tue, 4 Aug 2009, Matthew Woehlke wrote:
> Joel E. Denny wrote:
> > I just ran update-copyright on gnulib. It warns about a long list of files.
> > There are various problems:
> >
> > 2. No "(C)" after "Copyright".
>
> Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright" wit
Joel E. Denny wrote:
> On Mon, 3 Aug 2009, Joel E. Denny wrote:
>
>> I just ran update-copyright on gnulib. It warns about a long list of
>> files. There are various problems:
>>
>> 1. "@copyright{}" or "©" instead of "(C)".
>
>> In my opinion, update-copyright should be extended to handle #1.
>
Joel E. Denny wrote:
I just ran update-copyright on gnulib. It warns about a long list of
files. There are various problems:
2. No "(C)" after "Copyright".
Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
with no "(C)") the preferred form?
--
Matthew
Please do not qu
On Tue, 4 Aug 2009, Jim Meyering wrote:
> That was mistakenly on top of your change.
> Here's a clean version that also uses \015 rather than
> tr's slightly less portable \r.
>
> >From 7ef1309415c41e2a3c361a80854d3866d310a87e Mon Sep 17 00:00:00 2001
> From: Jim Meyering
> Date: Tue, 4 Aug 2009
On Tue, 4 Aug 2009, Jim Meyering wrote:
> > From f7aecbdf27eea1a0a6eb0960dbb34627ff56ccb6 Mon Sep 17 00:00:00 2001
> > From: Joel E. Denny
> > Date: Tue, 4 Aug 2009 09:37:54 -0400
> > Subject: [PATCH] update-copyright-tests: correctly test EOL=\r\n handling
> >
> > * tests/test-update-copyright.s
Jim Meyering wrote:
> Joel E. Denny wrote:
>> On Tue, 4 Aug 2009, Jim Meyering wrote:
>>
>>> Thanks for all of that.
>>> I've pushed that as well as your other three change sets,
>>> and one more change:
>>
>> Thanks. Unfortunately, my email client ate the \r\n sequences in the DOS
>> EOL test.
Joel E. Denny wrote:
> On Tue, 4 Aug 2009, Jim Meyering wrote:
>
>> Thanks for all of that.
>> I've pushed that as well as your other three change sets,
>> and one more change:
>
> Thanks. Unfortunately, my email client ate the \r\n sequences in the DOS
> EOL test. Sorry about that. The attached
On Mon, 3 Aug 2009, Joel E. Denny wrote:
> I just ran update-copyright on gnulib. It warns about a long list of
> files. There are various problems:
>
> 1. "@copyright{}" or "©" instead of "(C)".
> In my opinion, update-copyright should be extended to handle #1.
The following patch impleme
On Tue, 4 Aug 2009, Jim Meyering wrote:
> Thanks for all of that.
> I've pushed that as well as your other three change sets,
> and one more change:
Thanks. Unfortunately, my email client ate the \r\n sequences in the DOS
EOL test. Sorry about that. The attached patch adds them back.From f7ae
Joel E. Denny wrote:
> On Sat, 1 Aug 2009, Joel E. Denny wrote:
>
>> > No objection on principle, from me. The 'update-copyright' module
>> > works fine for me in most cases. But it has no testsuite, therefore it
>> > may surprise us.
>>
>> My test suite has mostly been coreutils and bison (plus a
On Mon, 3 Aug 2009, Joel E. Denny wrote:
> > Also, I posted some major changes to update-copyright here:
> >
> > http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00135.html
>
> I found a bug in that code, which the following patch fixes.
>
> >From 1e91305468e96d8eea16a151fc7b63745d66b4
On Sat, 1 Aug 2009, Joel E. Denny wrote:
> > No objection on principle, from me. The 'update-copyright' module
> > works fine for me in most cases. But it has no testsuite, therefore it
> > may surprise us.
>
> My test suite has mostly been coreutils and bison (plus a few handwritten
> tests for
"Joel E. Denny" writes:
>> For example I note that
>> $ build-aux/update-copyright < lib/gc-gnulib.c
>> gives a warning.
>
> That doesn't contain an FSF copyright, so an update-copyright makefile
> target should probably just exclude it.
That was a mistake when adding the file into gnulib, no
Hi Bruno.
On Sat, 1 Aug 2009, Bruno Haible wrote:
> > Would anyone object to my mass-updating all
> > FSF-copyright year lists in gnulib to include 2009?
> > (of course, I'd exclude files that are still
> > in sync with originals elsewhere)
>
> No objection on principle, from me. The 'update-cop
Jim Meyering wrote:
> Updating copyright year lists piecemeal is tiresome and unnecessary, now.
>
> http://marc.info/?l=coreutils-bug&m=124788185110393&w=2
Hey, since 2006 already!
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2a577fa2027dc966eadcdd71a9b5f6e699f89165
Such a
28 matches
Mail list logo
