Eric Blake wrote:
> Would it still be possible to keep symlink development (yes, that means
> during development, the linked files bear a looser license than necessary,
> but only on the developer's machine), so long as a maintainer-check
> guarantees a fresh gnulib checkout with proper licenses at
Clemens Koller wrote:
> > m4-1.4.10 doesn't build anymore (1.4.9 built fine):
> >
> > make[1]: Entering directory `/usr/ports/core/m4/work/src/m4-1.4.10/
> > src'
> > gcc -std=gnu99 -O2 -pipe -o m4 m4.o builtin.o debug.o eval.o
> > format.o freeze.o input.o macro.o output.o path.o symtab.o
Karl and other lawyers
Please stop calling me a lawyer. I'm not one.
rms suggested simply removing the @node and any sectioning command
at all from the beginning of the Texinfo versions of the licenses. That
way manuals can do whatever they want.
Sounded sensible to me, so barring objections, I'll make those changes
in a bit.
It will require some changes in exist
On Jul 13, 2007, at 12:22 PM, Clemens Koller wrote:
Hi, Gary!
Hi Clemens,
Thanks for the bug report. I'm forwarding to the bug-m4 mailing list
for
wider visibility.
This looks like a corner case for one of the files from gnulib that m4
imports during bootstrap: I'm forwarding to the bug-
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> I had to make some changes in order to get coreutils'
>> bootstrap procedure to succeed once again:
>
> That didn't quite work for me:
>
>$ ./bootstrap --gnulib-srcdir=../gnulib
>./bootstrap: Bootstrappin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 7/13/2007 12:41 PM:
>
> Going back to using copies (instead of symbolic links) when
> bootstrapping would not merely be a minor annoyance for me; it would
> be a real hassle and would make the resulting programs less reliab
[EMAIL PROTECTED] (Karl Berry) writes:
> But nowadays my understanding is that coreutils, and
> every other project, uses gnulib-tool.
The problem occurs even when gnulib-tool is being used. A common way
for developers to use gnulib-tool, which I use in many projects (not
just coreutils), is som
I notice that coreutils bootstrap has diverged from gnulib bootstrap.
Was this intended? Here's the current difference (counting the
coreutils patch I just proposed). Would there be any objection to
installing these changes into gnulib?
2007-07-13 Paul Eggert <[EMAIL PROTECTED]>
* boo
Jim Meyering <[EMAIL PROTECTED]> writes:
> I had to make some changes in order to get coreutils'
> bootstrap procedure to succeed once again:
That didn't quite work for me:
$ ./bootstrap --gnulib-srcdir=../gnulib
./bootstrap: Bootstrapping from checked-out coreutils sources...
...
./
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2007-07-02 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/inttypes.m4 (gl_INTTYPES_H): Define __STDC_LIMIT_MACROS in C++
> mode, when inttypes.h comes from gnulib.
> Reported by Joel E. Denny <[EMAIL PROTECTED]>.
Thanks for that patch; it
Bruno Haible <[EMAIL PROTECTED]> writes:
> Can you please try this patch? Just modify lib/stdint_.h as indicated
> (with "patch lib/stdint_.h < this-mail"), then "make".
Thanks for catching that misspelling, which should get fixed regardless
of whether it fixes his problem. I installed your patc
If I remember correctly, the initial reason why gnulib used the GPL
template for some LGPL file was because CoreUtils didn't yet use
gnulib-tool at the time. The CoreUtils maintainers didn't want to
manually change the files every time they were imported from gnulib.
I suggest we revert that deci
13 matches
Mail list logo
