Re: failure in building gnulib tests wih pcc on debian

[Stefano Lattarini]

On Tuesday 15 November 2011, Bruno Haible wrote:
> Eric Blake wrote:
> > > ... on an unstable Debian using pcc
> > > (Portable C Compiler, version 1.1.0~DEVEL+20110422-1
> > ...
> > Warnings like this, and the error in test-float.c, mean that all other
> > packages using the same gnulib modules will have the same problem.  We
> > should fix it upstream in gnulib.
> 
> I don't think it's worth spending time on supporting pcc in gnulib
> at this point. My evaluation of pcc-1.0.0 [1] revealed a number of
> code generation bugs. Let them fix their compiler to produce working
> code first.
> 
JFTR, this is fine by me.  I tried to compile grep with pcc "just for
kicks", not for any serious reason, and I'm not interest in having it
really working in that setup.  Two minor points though:

 - Apart from the build failures of the gnulib test(s), GNU grep has
   built fine with pcc 1.1.0 (Debian:pcc_1.1.0~DEVEL+20110422-1), and
   its testsuite has passed.

 - Running the gnulib tests with pcc and reporting problems to its
   developers could significantly help them to find (and posssibly
   fix) their bugs much faster.  The risk of not doing so is that
   that compiler will gain momentum nonetheless, and gnulib will some
   day have to start supporting it "as is" (for benefits of older
   versions out in the wild), which means more Yet More Workarounds
   in the gnulib code base.

Though, as I've said, this is of no real importance to me, so I won't
try to push you in any direction.

Thanks,
  Stefano

[PATCH] maint.mk: fix tight-scope.mk generation in VPATH builds.

[Gary V. Vaughan]

Okay to push?

* top/maint.mk (tight-scope.mk): Make sure to prefix file
reference with $(srcdir) so that the file is found correctly even
when running `make syntax-check' in a VPATH build.

Signed-off-by: Gary V. Vaughan 
---
 ChangeLog|7 +++
 top/maint.mk |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7799f7a..dd1f5ff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-11-15  Gary V. Vaughan  
+
+   maint.mk: fix tight-scope.mk generation in VPATH builds.
+   * top/maint.mk (tight-scope.mk): Make sure to prefix file
+   reference with $(srcdir) so that the file is found correctly even
+   when running `make syntax-check' in a VPATH build.
+
 2011-11-01  Gary V. Vaughan  
 
gitlog-to-changelog: support `tiny change' commits.
diff --git a/top/maint.mk b/top/maint.mk
index d2f5830..76844a0 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1438,7 +1438,7 @@ sc_tight_scope: tight-scope.mk
 
 tight-scope.mk: $(ME)
@rm -f $@ $@-t
-   @perl -ne '/^# TS-start/.../^# TS-end/ and print' $(ME) > $@-t
+   @perl -ne '/^# TS-start/.../^# TS-end/ and print' $(srcdir)/$(ME) > $@-t
@chmod a=r $@-t && mv $@-t $@
 
 ifeq (a,b)
-- 
1.7.7.3

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Jim Meyering]

Gary V. Vaughan wrote:
> I think 'Copyright-paper-required: No' is still the best compromise here for
> the reasons stated earlier in the thread.
>
> Okay to push?
>
> The FSF require that all non-trivial patches to its projects be
> accompanied by appropriate paperwork, or that any patches that are
> applied without that paperwork are marked as such in the
> ChangeLog.
> * gitlog-to-changelog: Convert `Copyright-paperwork-required: No'
> lines from the git log message to standard `(tiny change)'
> ChangeLog annotation.
> * scripts/git-hooks/commit-msg: Diagnose redundant or malformed
> Copyright-paperwork-required lines.

This is setting FSF policy, and commit logs (at least on "master")
are typically immutable, so I'd rather you defer pushing until
the maintainer's guide endorses some precise syntax.  I don't want
to end up mandating one syntax and then find out later that some
other syntax is preferred.  For example, I have a slight preference
for a semantically positive tag like "Copyright-paperwork-exempt:".

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Gary V. Vaughan]

Hi Jim,

On 15 Nov 2011, at 18:14, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> I think 'Copyright-paper-required: No' is still the best compromise here for
>> the reasons stated earlier in the thread.
>> 
>> Okay to push?
>> 
>> The FSF require that all non-trivial patches to its projects be
>> accompanied by appropriate paperwork, or that any patches that are
>> applied without that paperwork are marked as such in the
>> ChangeLog.
>> * gitlog-to-changelog: Convert `Copyright-paperwork-required: No'
>> lines from the git log message to standard `(tiny change)'
>> ChangeLog annotation.
>> * scripts/git-hooks/commit-msg: Diagnose redundant or malformed
>> Copyright-paperwork-required lines.
> 
> This is setting FSF policy,

Well, the policy is already set very clearly...

From http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant

   "If a person contributes more than around 15 lines of code and/or text
that is legally significant for copyright purposes, we need copyright
papers for that contribution..."

   "If that is not so, you can install the small patch. Write ‘(tiny change)’
after the patch author’s name, like this:

  2002-11-04  Robert Fenk(tiny change)"

> and commit logs (at least on "master")
> are typically immutable, so I'd rather you defer pushing until
> the maintainer's guide endorses some precise syntax.

The syntax of the git commit log entry is not exposed in the distribution,
which is partly why we have `gitlog-to-changelog' to make sure we *do*
distribute a ChangeLog set out as required by the gnu maintainer docs.

> I don't want
> to end up mandating one syntax and then find out later that some
> other syntax is preferred.

I'm almost certain that there is no precedent in GNU projects for git
log syntax to denote the "(tiny change)" annotation required in GNU
ChangeLog entries, generated or otherwise.  If there is some other
syntax used by another project that also uses gitlog-to-changelog, they
can either patch the script to parse their syntax using gnulib-tool's
local patching mechanism, or submit such a patch upstream to bug-gnulib
for inclusion in the gitlog-to-changelog.  Either way, I don't forsee
any problems.

> For example, I have a slight preference
> for a semantically positive tag like "Copyright-paperwork-exempt:".

That seems fine to me too.

Rather than stalling, what's the next step to keep things in motion?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Jim Meyering]

Gary V. Vaughan wrote:

> Hi Jim,
>
> On 15 Nov 2011, at 18:14, Jim Meyering wrote:
>> Gary V. Vaughan wrote:
>>> I think 'Copyright-paper-required: No' is still the best compromise here for
...
>> This is setting FSF policy,
>
> Well, the policy is already set very clearly...
>
> From http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant

That part is not in question.

The syntax you are proposing would set policy for
GNU projects that use gitlog-to-changelog.

...
>> For example, I have a slight preference
>> for a semantically positive tag like "Copyright-paperwork-exempt:".
>
> That seems fine to me too.
>
> Rather than stalling, what's the next step to keep things in motion?

Propose a patch to maintain.texi.

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Gary V. Vaughan]

Hi Jim,

On 15 Nov 2011, at 19:02, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> On 15 Nov 2011, at 18:14, Jim Meyering wrote:
>>> Gary V. Vaughan wrote:
 I think 'Copyright-paper-required: No' is still the best compromise here 
 for
> ...
>>> This is setting FSF policy,
>> 
>> Well, the policy is already set very clearly...
>> 
>> From http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
> 
> That part is not in question.
> 
> The syntax you are proposing would set policy for
> GNU projects that use gitlog-to-changelog.

Not at all. It would set a precedent for sure, and it enables other
projects to track '(tiny change)' annotations in git logs in accordance
with the maintainer guidelines - but does not by any means set anything
in stone... many GNU projects don't even use git after all.

>>> For example, I have a slight preference
>>> for a semantically positive tag like "Copyright-paperwork-exempt:".
>> 
>> That seems fine to me too.
>> 
>> Rather than stalling, what's the next step to keep things in motion?
> 
> Propose a patch to maintain.texi.

I don't want to get into a debate over the merits of generated
ChangeLogs with RMS, which I already know he doesn't like.

So never mind this second patch, I'll just keep it in the
gl/build-aux/gitlog-to-changelog.diff of my projects.  Any other
project that likes it can find a copy there, or in the bug-gnulib
archives. (Although I still think that if you use gitlog-to-changelog
to generate all your ChangeLogs without tracking and correctly
generating the '(tiny change)' annotations somehow, then you're not
respecting the maintainer guidelines on ChangeLog entries.)

How about pushing the multi-author patch?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Jim Meyering]

Gary V. Vaughan wrote:

> Hi Jim,
>
> On 15 Nov 2011, at 19:02, Jim Meyering wrote:
>> Gary V. Vaughan wrote:
>>> On 15 Nov 2011, at 18:14, Jim Meyering wrote:
 Gary V. Vaughan wrote:
> I think 'Copyright-paper-required: No' is still the best compromise here 
> for
>> ...
 This is setting FSF policy,
>>>
>>> Well, the policy is already set very clearly...
>>>
>>> From http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
>>
>> That part is not in question.
>>
>> The syntax you are proposing would set policy for
>> GNU projects that use gitlog-to-changelog.
>
> Not at all. It would set a precedent for sure, and it enables other
> projects to track '(tiny change)' annotations in git logs in accordance
> with the maintainer guidelines - but does not by any means set anything
> in stone... many GNU projects don't even use git after all.
>
 For example, I have a slight preference
 for a semantically positive tag like "Copyright-paperwork-exempt:".
>>>
>>> That seems fine to me too.
>>>
>>> Rather than stalling, what's the next step to keep things in motion?
>>
>> Propose a patch to maintain.texi.
>
> I don't want to get into a debate over the merits of generated
> ChangeLogs with RMS, which I already know he doesn't like.

I don't recall any objection to generated ChangeLogs.
No one ever gave me negative feedback about what I do in coreutils
(since 2008), diffutils, grep, etc., and as such I wouldn't expect
any debate.  It's established practice.

> So never mind this second patch, I'll just keep it in the
> gl/build-aux/gitlog-to-changelog.diff of my projects.  Any other
> project that likes it can find a copy there, or in the bug-gnulib
> archives. (Although I still think that if you use gitlog-to-changelog
> to generate all your ChangeLogs without tracking and correctly
> generating the '(tiny change)' annotations somehow, then you're not
> respecting the maintainer guidelines on ChangeLog entries.)
>
> How about pushing the multi-author patch?

I will re-review/test it and reply tomorrow.

I can give a little feedback already: I do not want to
add a bourne-shell git commit-msg hook script to gnulib.
If I thought the one we're using in coreutils were ready,
I would have proposed to add something general based on it.

There are two issues:
- we need more experience with the idea and the framework.
  I suspect that very few people have used it so far.
- it is not ready for gnulib: I am rewriting it in Perl,
  which is more portable, and with git, guaranteed to be available.

Re: [PATCH] maint.mk: fix tight-scope.mk generation in VPATH builds.

[Jim Meyering]

Gary V. Vaughan wrote:
> Okay to push?
>
> * top/maint.mk (tight-scope.mk): Make sure to prefix file
> reference with $(srcdir) so that the file is found correctly even
> when running `make syntax-check' in a VPATH build.
...
>  tight-scope.mk: $(ME)
>   @rm -f $@ $@-t
> - @perl -ne '/^# TS-start/.../^# TS-end/ and print' $(ME) > $@-t
> + @perl -ne '/^# TS-start/.../^# TS-end/ and print' $(srcdir)/$(ME) > $@-t
>   @chmod a=r $@-t && mv $@-t $@

Ok.  Thanks.
(but please be sure not to push the preceding change(s) implied
by your ChangeLog context)

Re: [PATCH] maint.mk: fix tight-scope.mk generation in VPATH builds.

[Gary V. Vaughan]

Hi Jim,

On 15 Nov 2011, at 20:14, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> Okay to push?
>> 
>> * top/maint.mk (tight-scope.mk): Make sure to prefix file
>> reference with $(srcdir) so that the file is found correctly even
>> when running `make syntax-check' in a VPATH build.
> ...
>> tight-scope.mk: $(ME)
>>  @rm -f $@ $@-t
>> -@perl -ne '/^# TS-start/.../^# TS-end/ and print' $(ME) > $@-t
>> +@perl -ne '/^# TS-start/.../^# TS-end/ and print' $(srcdir)/$(ME) > $@-t
>>  @chmod a=r $@-t && mv $@-t $@
> 
> Ok.  Thanks.

Done.

> (but please be sure not to push the preceding change(s) implied
> by your ChangeLog context)

No problem, I have a private 'pending' branch for patches I've submitted for
review, and I cherry-pick into master for pushing, and then rebase pending
when I'm done.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Gary V. Vaughan]

Hi Jim,

On 15 Nov 2011, at 20:10, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> On 15 Nov 2011, at 19:02, Jim Meyering wrote:
>>> Propose a patch to maintain.texi.
>> 
>> I don't want to get into a debate over the merits of generated
>> ChangeLogs with RMS, which I already know he doesn't like.
> 
> I don't recall any objection to generated ChangeLogs.
> No one ever gave me negative feedback about what I do in coreutils
> (since 2008), diffutils, grep, etc., and as such I wouldn't expect
> any debate.  It's established practice.

Nonetheless, I'd rather avoid the possibility.

And I certainly don't want to get sidetracked into writing a whole
new chapter for maintain.texi, which currently avoids discussing VCS
entirely.

>> So never mind this second patch, I'll just keep it in the
>> gl/build-aux/gitlog-to-changelog.diff of my projects.  Any other
>> project that likes it can find a copy there, or in the bug-gnulib
>> archives. (Although I still think that if you use gitlog-to-changelog
>> to generate all your ChangeLogs without tracking and correctly
>> generating the '(tiny change)' annotations somehow, then you're not
>> respecting the maintainer guidelines on ChangeLog entries.)
>> 
>> How about pushing the multi-author patch?
> 
> I will re-review/test it and reply tomorrow.

Excellent! Thanks :)

> I can give a little feedback already: I do not want to
> add a bourne-shell git commit-msg hook script to gnulib.
> If I thought the one we're using in coreutils were ready,
> I would have proposed to add something general based on it.

Agreed.  Writing a new perl script is well outside my expertise anyway.

Since git seems to allow but a single commit-msg hook script, a nice
goal would be to have some sort of framework for executing snippets
from separate files for various checks (maybe in .git/hooks/commit-msg.d).
That way projects could install the framework, and add a selection of
checks from gnulib (in Perl I imagine), and some bespoke checks in a
language the maintainer is comfortable with... much better than having
to cobble together a monolithic script from checks that would be convenient
assembled from various sources.

> There are two issues:
> - we need more experience with the idea and the framework.
>  I suspect that very few people have used it so far.
> - it is not ready for gnulib: I am rewriting it in Perl,
>  which is more portable, and with git, guaranteed to be available.

All sounds good to me.  Especially if you don't ask me to write any more
perl code! ;)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

openat requires lstat.m4

[Ben Walton]

Hi All,

I was playing with some gnulib stuff tonight and noticed that if I
import only openat, I get errors when later running autoreconf:

configure.ac:17: warning: gl_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK is m4_require'd 
but not m4_defun'd
m4/openat.m4:11: gl_FUNC_OPENAT is expanded from...
m4/gnulib-comp.m4:105: gl_INIT is expanded from...
configure.ac:17: the top level

The following small tweak resolved this for me but I don't know if
this is a complete or proper fix.

diff --git a/modules/openat b/modules/openat
index f2da9bc..4124541 100644
--- a/modules/openat
+++ b/modules/openat
@@ -5,6 +5,7 @@ Files:
 lib/at-func.c
 lib/openat.c
 lib/openat-priv.h
+m4/lstat.m4
 m4/openat.m4
 m4/mode_t.m4

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

gnulib integration how to

[Ben Walton]

Hi Bruno,

I sent this to Jim last night as he's listed as the owner of gnulib on
savanah, but he suggested I send this to you (and bug-gnulib).

A while back I wrote a 'how to integrate gnulib'[1] tutorial that was
aimed at the OpenCSW maintainer community.  We package software for
Solaris so gnulib is a huge benefit to us.  We quite often encounter
packages that require gnulib support in order to build.

Is this document of any value to the project in terms of inclusion on
the website or in doc/?  I'd be willing to fully generalize it if so.
Right now it contains some OpenCSW-specific notes that wouldn't have
any meaning to people not building for OpenCSW.

Any feedback is also welcomed...it's getting high visibility in search
results, so I'd like to clean up issues you see even if you don't
think it's worth linking to or including.

Thanks
-Ben

[1] http://wiki.opencsw.org/adding-gnulib
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

Re: openat requires lstat.m4

[Bruno Haible]

Hi,

Ben Walton wrote:
> I was playing with some gnulib stuff tonight and noticed that if I
> import only openat, I get errors when later running autoreconf:
> 
> configure.ac:17: warning: gl_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK is 
> m4_require'd but not m4_defun'd
> m4/openat.m4:11: gl_FUNC_OPENAT is expanded from...
> m4/gnulib-comp.m4:105: gl_INIT is expanded from...
> configure.ac:17: the top level
> 
> The following small tweak resolved this for me but I don't know if
> this is a complete or proper fix.
> 
> diff --git a/modules/openat b/modules/openat
> index f2da9bc..4124541 100644
> --- a/modules/openat
> +++ b/modules/openat
> @@ -5,6 +5,7 @@ Files:
>  lib/at-func.c
>  lib/openat.c
>  lib/openat-priv.h
> +m4/lstat.m4
>  m4/openat.m4
>  m4/mode_t.m4

The fix is correct. For maintainability it needs to be added also to
some other module descriptions.

I'm applying this. The "tiny change" is not meant to be a derogatory
designation; it merely documents that your contribution to gnulib so far
did not require the exchange of copyright assignment paperwork.


2011-11-15  Ben Walton   (tiny change)
Bruno Haible  

Fix some modules' file list.
* modules/fstatat (Files): Add m4/lstat.m4.
* modules/openat (Files): Likewise.
* modules/unlinkat (Files): Likewise.

--- modules/fstatat.origWed Nov 16 03:06:12 2011
+++ modules/fstatat Wed Nov 16 03:05:07 2011
@@ -6,6 +6,7 @@
 lib/at-func.c
 lib/openat-priv.h
 m4/fstatat.m4
+m4/lstat.m4
 
 Depends-on:
 sys_stat
--- modules/openat.orig Wed Nov 16 03:06:12 2011
+++ modules/openat  Wed Nov 16 03:05:06 2011
@@ -6,6 +6,7 @@
 lib/openat.c
 lib/openat-priv.h
 m4/openat.m4
+m4/lstat.m4
 m4/mode_t.m4
 
 Depends-on:
--- modules/unlinkat.orig   Wed Nov 16 03:06:12 2011
+++ modules/unlinkatWed Nov 16 03:05:06 2011
@@ -6,6 +6,7 @@
 lib/at-func.c
 lib/openat-priv.h
 m4/unlinkat.m4
+m4/lstat.m4
 
 Depends-on:
 unistd

-- 
In memoriam Kurt Gerron 

Re: gnulib integration how to

[Bruno Haible]

Hi Ben,

Ben Walton wrote:
> I sent this to Jim last night as he's listed as the owner of gnulib on
> savanah, but he suggested I send this to you (and bug-gnulib).

Yes, things like this are suitable for public discussion.

> A while back I wrote a 'how to integrate gnulib'[1] tutorial that was
> aimed at the OpenCSW maintainer community.  We package software for
> Solaris so gnulib is a huge benefit to us.  We quite often encounter
> packages that require gnulib support in order to build.
>
> Is this document of any value to the project in terms of inclusion on
> the website or in doc/?

Two things:

1) From the perspective of a distributor of packages for a specific
   platform, the libposix subproject of gnulib (see
   

   and gnulib/STATUS-libposix) should be of interest to you.
   In the long run, this will be more economic for you than modifying
   the configuration of dozens of packages.

2) Your writeup has ca. 80% overlap with the gnulib documentation,
   10% is specific to OpenCSW, and 10% is generic text not yet handled
   by the gnulib documentation.

   What is, in general, the value of a smaller documentation when a more
   extensive documentation already exists? Answer: The fact that it is
   smaller. Faster to read. So, there is a value in linking from the gnulib
   manual to your writeup.

   But if we have a GNU package's documentation that starts to link to
   related doc pieces, it will be likely that some of these linked-to
   docs become out-of-date. So, before our manual can link to your
   doc, your text should make it prominently clear when it was last
   updated. IMO the currently location of that hint (near the bottom,
   between a Google ad and a Wikidot ad, with a tiny font) is not sufficient.
   The right place for such a note is between the title and the body.

   Other than that, the idea of section "Knowing When gnulib is Helpful"
   could be helpful for the Gnulib section "2.1 Finding modules". But that
   section should also mention GNULIB_POSIXCHECK, since that is the preferred
   way of finding which gnulib modules are helpful (with this method, you
   don't need e.g. a HP-UX machine to find which modules are needed for HP-UX).

> I'd like to clean up issues you see even if you don't
> think it's worth linking to or including.

I'm running out of time on this now; someone else can comment, please?

Bruno
-- 
In memoriam Kurt Gerron