Hi Simon,
Simon Josefsson wrote:
> Jim Meyering writes:
...
>> I'm using coreutils' maint.mk in 3 or 4 other projects,
>> nearly verbatim. As such, I'm reluctant to remove rules, since
>> that would mean migrating them out to each cfg.mk, which is maintained
>> separately, and thus harder to kee
Jim Meyering writes:
> Simon Josefsson wrote:
>> Reuben Thomas writes:
>>
>>> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>>>
Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from
gnulib.
>>>
>>> O
Simon Josefsson wrote:
> Reuben Thomas writes:
>
>> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>>
>>> Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
>>> so at minimum it would need a patch that made it use maint.mk from
>>> gnulib.
>>
>> Or it could use maintainer-makefile
On Tue, 14 Apr 2009, Simon Josefsson wrote:
So if you have time, please proceed in trying to merge these files. I
am sorry that I have been quite busy and haven't had time to review and
comment. But in general I support your approach.
I'm not bothered about the speed as I'm not in any hurry,
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
>> so at minimum it would need a patch that made it use maint.mk from
>> gnulib.
>
> Or it could use maintainer-makefile, unless there's some reason why
pretty much reached the end of that particular tedious limitation.
Not even remotely the case.
My request is, please stick to 7-bit ASCII whenever it is all feasible.
Names in ChangeLogs and the like are one thing, but randomly
throwing in UTF-8 (or any other encoding) into email (or source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/7/2009 6:32 AM:
>> If you use Bruno's git-merge-changelog program, and attach a
>> .gitattributes notation to your changelog that you do so, then ChangeLog
>> diffs have a high probability of applying correctly,
>
> Tha
Eric Blake wrote:
> According to Jim Meyering on 4/7/2009 2:56 AM:
>> - use ChangeLog-style "* full-relative-name/to-each-affected-file
>> (func,rule,etc.): description..." in the log, because that is what
>> goes into the ChangeLog for gnulib. In coreutils, the log is the
>> primary sour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/7/2009 2:56 AM:
> - use ChangeLog-style "* full-relative-name/to-each-affected-file
> (func,rule,etc.): description..." in the log, because that is what
> goes into the ChangeLog for gnulib. In coreutils, the log i
Reuben Thomas wrote:
...
> Which means I have to configure Emacs specially for writing certain
> files. It's a pain that in a system invented in the last ten years
> (git) UTF-8 is still a second-class citizen.
There's nothing wrong with git's UTF-8 support.
Reuben Thomas wrote:
> On Tue, 7 Apr 2009, Jim Meyering wrote:
>> Didn't you notice how it was harder to read your UTF8-encoded Subject
>> line in what I quoted?
>
> Yes, but that's because you pasted an encoded mail header into your reply.
No, I did not.
You attached the patch as type text/xdiff,
On Tue, 7 Apr 2009, Jim Meyering wrote:
Didn't you notice how it was harder to read your UTF8-encoded Subject
line in what I quoted?
Yes, but that's because you pasted an encoded mail header into your reply. I
normally only read mail headers in an MUA where they are displayed properly.
Are y
Reuben Thomas wrote:
> On Tue, 7 Apr 2009, Jim Meyering wrote:
>> - your summary/subject was needlessly utf8-encoded.
>> That makes it harder to read.
>
> For the sake of one apostrophe. It's a pity, I made Emacs do smart
> quotes in text mode, and now it looks like I need an exception. What'
On Tue, 7 Apr 2009, Jim Meyering wrote:
- your summary/subject was needlessly utf8-encoded.
That makes it harder to read.
For the sake of one apostrophe. It's a pity, I made Emacs do smart quotes in
text mode, and now it looks like I need an exception. What's the problem
with UTF-8 in
Reuben Thomas wrote:
> On Tue, 7 Apr 2009, Jim Meyering wrote:
>> Ok. Post "git format-patch ..." output and I'll push it,
>> unless someone objects in the mean time.
>
> Attached. Let me know if I did something wrong.
>
> (Copyright assignment: I'm assuming that since I didn't write any of
> this
On Tue, 7 Apr 2009, Jim Meyering wrote:
Ok. Post "git format-patch ..." output and I'll push it,
unless someone objects in the mean time.
Attached. Let me know if I did something wrong.
(Copyright assignment: I'm assuming that since I didn't write any of this,
but just made trivial changes,
Reuben Thomas wrote:
> On Mon, 6 Apr 2009, Jim Meyering wrote:
>
>> Ok by me. Though I don't like the use of $(C_SOURCES), as I
>> mentioned. I do understand you're trying to do this gradually. I'd
>> be inclined to make bigger changes ;-) It's only "make
>> syntax-check", after all.
>
> OK, I'm
On Mon, 6 Apr 2009, Jim Meyering wrote:
Ok by me. Though I don't like the use of $(C_SOURCES), as I mentioned.
I do understand you're trying to do this gradually. I'd be inclined to
make bigger changes ;-) It's only "make syntax-check", after all.
OK, I'm just trying to make changes that I
Reuben Thomas wrote:
> On Sat, 4 Apr 2009, Jim Meyering wrote:
>> Reuben Thomas wrote:
>>> On Sat, 4 Apr 2009, Jim Meyering wrote:
>>>
Those buglets were from coreutils' maint.mk.
>>>
>>> Just to be clear, the buglets were from coreutils' maint.mk, but the
>>> patch I sent was a patch to gnuli
On Sat, 4 Apr 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Sat, 4 Apr 2009, Jim Meyering wrote:
Those buglets were from coreutils' maint.mk.
Just to be clear, the buglets were from coreutils' maint.mk, but the
patch I sent was a patch to gnulib's maint.mk. So your push below:
Subject
Reuben Thomas wrote:
> On Sat, 4 Apr 2009, Jim Meyering wrote:
>
>> Those buglets were from coreutils' maint.mk.
>
> Just to be clear, the buglets were from coreutils' maint.mk, but the
> patch I sent was a patch to gnulib's maint.mk. So your push below:
>
>> Subject: [PATCH] tests: make syntax-che
On Sat, 4 Apr 2009, Jim Meyering wrote:
Those buglets were from coreutils' maint.mk.
Just to be clear, the buglets were from coreutils' maint.mk, but the patch I
sent was a patch to gnulib's maint.mk. So your push below:
Subject: [PATCH] tests: make syntax-checks more robust
is to coreut
Ralf Wildenhues wrote:
> Hello Reuben,
>
> a couple of nits:
Thanks, Ralf.
Those buglets were from coreutils' maint.mk.
Here's what I expect to push in your name:
>From d75bcea4cfc7927535d19d34d8d103621b4a0d6d Mon Sep 17 00:00:00 2001
From: Ralf Wildenhues
Date: Sat, 4 Apr 2009 10:25:18 +0200
Su
Hello Reuben,
a couple of nits:
* Reuben Thomas wrote on Fri, Apr 03, 2009 at 03:57:46PM CEST:
> --- a/top/maint.mk
> +++ b/top/maint.mk
> @@ -38,34 +38,42 @@ GZIP_ENV = '--no-name --best $(gzip_rsyncable)'
> # Doing it here saves us from having to set LC_ALL elsewhere in this file.
> export LC
Reuben Thomas wrote:
> On Fri, 3 Apr 2009, Jim Meyering wrote:
>> I'll take your word that it doesn't change anything.
>> Someone who uses it may want to try it or give it a closer look.
>
> Let me know, and I can do some more work. The next thing I'm
> interested in is adding some more source chec
On Fri, 3 Apr 2009, Jim Meyering wrote:
I'll take your word that it doesn't change anything.
Someone who uses it may want to try it or give it a closer look.
Let me know, and I can do some more work. The next thing I'm interested in
is adding some more source checking rules, particularly thos
Reuben Thomas wrote:
> On Fri, 3 Apr 2009, Reuben Thomas wrote:
>
>> On Wed, 1 Apr 2009, Reuben Thomas wrote:
>>
>>> Would you like to suggest what I should do next to my patch?
>>
>> Not having had a reply, I've come up with my own answer: start with
>> a little bit of merging.
>>
>> What I've don
Reuben Thomas wrote:
> On Wed, 1 Apr 2009, Reuben Thomas wrote:
>
>> Would you like to suggest what I should do next to my patch?
>
> Not having had a reply, I've come up with my own answer: start with a
> little bit of merging.
>
> What I've done so far is to add the macros _prohibit_regexp and
>
On Fri, 3 Apr 2009, Reuben Thomas wrote:
On Wed, 1 Apr 2009, Reuben Thomas wrote:
Would you like to suggest what I should do next to my patch?
Not having had a reply, I've come up with my own answer: start with a little
bit of merging.
What I've done so far is to add the macros _prohibit_
On Wed, 1 Apr 2009, Reuben Thomas wrote:
Would you like to suggest what I should do next to my patch?
Not having had a reply, I've come up with my own answer: start with a little
bit of merging.
What I've done so far is to add the macros _prohibit_regexp and
_header_without_use to gnulib's
Simon Josefsson wrote:
> Reuben Thomas writes:
...
>>> 4. Use of C_SOURCES in sc_* rules.
>>
>> There seems to be a conflict here between coreutils's approach (use a
>> list of exceptions generated from the VCS) and gnulib's (generate a
>> list of files to look at). What do you suggest as a next s
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from
gnulib.
Or it could use maintainer-makefile, unless there's some reason why not?
Further, some of the rules in
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> It will be easier to review if you post patches for gnulib's maint.mk
>> instead of the entire new file.
>
> I'll do that.
Thanks!
>> You may have to patch coreutils maint.mk too, but that could go to
>> bug-coreut...@gnu.o
On Wed, 1 Apr 2009, Simon Josefsson wrote:
It will be easier to review if you post patches for gnulib's maint.mk
instead of the entire new file.
I'll do that.
You may have to patch coreutils maint.mk too, but that could go to
bug-coreut...@gnu.org.
I was hoping to end up with a single file
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> Reuben Thomas writes:
>>>
>>> Since coreutils' maint.mk seems to be shared with other projects
>>> already, could it not simply be pushed into gnulib as it is? Could
>>> those projects (currently, according to the comments,
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Reuben Thomas writes:
Since coreutils' maint.mk seems to be shared with other projects
already, could it not simply be pushed into gnulib as it is? Could
those projects (currently, according to the comments, "coreutils,
idutils, CPPI, Bison, and Auto
Reuben Thomas writes:
> On Fri, 20 Mar 2009, Simon Josefsson wrote:
>
>> Reuben Thomas writes:
>>
>>> On Fri, 20 Mar 2009, Eric Blake wrote:
>>>
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
>
On Fri, 20 Mar 2009, Simon Josefsson wrote:
Reuben Thomas writes:
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of rule that sh
Eric Blake wrote:
> According to Reuben Thomas on 3/20/2009 8:10 AM:
>>> Always including first is easy to forget.
>>> You might want to use rules like these from gnulib's maint.mk:
>> I just checked gnulib out from git and I don't find this rule or
>
> Jim meant coreutil's maint.mk.
I sure did.
Reuben Thomas writes:
> On Fri, 20 Mar 2009, Eric Blake wrote:
>
>> Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
>> although several people have expressed interest in resyncing them.
>
> Aha! This is surely the sort of rule that should be pushed into
> gnulib. Thanks a
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of rule that should be pushed into gnulib.
Thanks anyway.
This problem seems to occ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reuben Thomas on 3/20/2009 8:10 AM:
>> Always including first is easy to forget.
>> You might want to use rules like these from gnulib's maint.mk:
> I just checked gnulib out from git and I don't find this rule or
Jim meant coreutil's ma
On Thu, 19 Mar 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
Always including first is easy to forget.
You might want to use rules like these from gnulib's mai
Reuben Thomas wrote:
> On Wed, 18 Mar 2009, Eric Blake wrote:
>
>> Ahh. The bug is in zile, not gnulib.
>
> Ah, thanks very much, and apologies for the noise.
Always including first is easy to forget.
You might want to use rules like these from gnulib's maint.mk:
# Nearly all .c files must incl
Eric Blake wrote:
> That is a no-no when using gnulib. EVERY .c file in your
> project MUST include prior to anything else (or include a
> project-specific .h which in turn includes first).
Yes. This is actually already documented in gnulib's documentation:
http://www.gnu.org/software/gnulib/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 3/18/2009 8:31 PM:
> Ahh. The bug is in zile, not gnulib.
>
> http://git.savannah.gnu.org/cgit/zile.git/tree/src/lists.c
Wow. That was my first experience with cgit instead of gitweb, and I
liked it. When did savannah ad
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
--
http://rrt.sc3d.org/ | mediate, v.i. to butt in (Bierce)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-zile]
According to Reuben Thomas on 3/18/2009 8:16 PM:
> On Wed, 18 Mar 2009, Eric Blake wrote:
>
>> Did you actually encounter a compilation failure where restrict was
>> improperly defined while using gnulib? If so, how do we reproduce
On Wed, 18 Mar 2009, Eric Blake wrote:
Did you actually encounter a compilation failure where restrict was
improperly defined while using gnulib? If so, how do we reproduce it?
It was not on my system, but on a BSD box that Nelson Beebe was kindly
building GNU Zile on for me. A bit of the bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reuben Thomas on 3/18/2009 7:50 PM:
> string.h uses restrict, which doesn't work if the compiler is C89 (e.g.
> gcc in -std=c89 mode).
>
> regex.h has some code to detect this case and allow for it; should
> string.
string.h uses restrict, which doesn't work if the compiler is C89 (e.g. gcc
in -std=c89 mode).
regex.h has some code to detect this case and allow for it; should string.h
copy this code? Or should it be broken out into a module? (It would be
useful to gnulib users too.)
--
51 matches
Mail list logo
