Simon Josefsson via Gnulib discussion list writes:
> My reaction was initially exactly the same as yours, until I found this
> piece of --help documentation, which actually is the first (and
> presumably highest priority) rule:
>
> * If the environment variable GNULIB_SRCDIR is set (either as an
Paul Eggert writes:
> On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
>> Is bootstrap intended to be reliable from within a tarball? I thought
>> the bootstrap script was not included in tarballs because it wasn't
>> designed to be ran that way, and the way it is designed may
Bruno Haible writes:
> Hi Simon,
>
>> Bug #2: ./bootstrap writes to the path indicated by --gnulib-srcdir with
>> the 'git checkout' command, and leaves the --gnulib-srcdir path at that
>> commit after ./bootstrap is finished. This happens to work in my
>> example since I pointed it to a writabl
Nick Bowler wrote:
> Not including the scripts used to build configure in a source tarball
> is a mistake, particularly for a GPL-licensed package. The configure
> script itself is clearly object code, and the GPL defines corresponding
> source to include any "scripts to control [its generation]".
Another package that exhibits a difference:
$ export GNULIB_TOOL_IMPL=sh+py
$ cvs -z3 -d:pserver:anonym...@cvs.savannah.nongnu.org:/sources/jugtail co
jugtail
$ cd jugtail
$ $GNULIB_SRCDIR/gnulib-tool --update
.../gnulib-tool: *** gnulib-tool.sh failed but gnulib-tool.py succeeded!
Inspect .../g
Hi Simon,
> Bug #2: ./bootstrap writes to the path indicated by --gnulib-srcdir with
> the 'git checkout' command, and leaves the --gnulib-srcdir path at that
> commit after ./bootstrap is finished. This happens to work in my
> example since I pointed it to a writable work tree, but I think alter
On 2024-04-10 16:36, Simon Josefsson wrote:
> Is bootstrap intended to be reliable from within a tarball? I thought
> the bootstrap script was not included in tarballs because it wasn't
> designed to be ran that way, and the way it is designed may not give
> expected results. Has this changed, so
In the 'time' package, a .gitignore file does not end with a newline. And
while gnulib-tool.py adds a newline before adding more lines, gnulib.tool.sh
does not.
How to reproduce:
$ git clone https://git.savannah.gnu.org/git/time.git
$ cd time
Remove the duplicate /build-aux line from .gitignore.
A couple of packages (barcode, gcal, gengetopt, myserver) have an old
gnulib configuration that still uses a module 'free', 'malloc', or 'getopt'.
These modules have been renamed in the mean time.
gnulib-tool.sh prints warnings about missing modules or mistyped module names.
gnulib-tool.py current
On Wed, Apr 10, 2024 at 5:44 PM Paul Eggert wrote:
>
> On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
> > Is bootstrap intended to be reliable from within a tarball? I thought
> > the bootstrap script was not included in tarballs because it wasn't
> > designed to be ran that
My quick reaction is that you've identified two bugs. --gnulib-srcdir
should only read from that directory, and GNULIB_REVISION should work in
bootstrap.conf.
On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
Is bootstrap intended to be reliable from within a tarball? I thought
the bootstrap script was not included in tarballs because it wasn't
designed to be ran that way, and the way it is designed may not give
expected results.
I
Hi
I'm trying to get ./bootstrap from a minimal source-only archive
generated via 'git archive' that has GNULIB_REVISION set in
bootstrap.conf, expecting this to work:
./bootstrap --gnulib-srcdir=/home/jas/src/gnulib
Bug #1: it seems GNULIB_REVISION in bootstrap.conf has no effect, and
this code
Collin Funk wrote:
> I attached the patch with the callable(module_filter) check.
Thanks! Applied. This eliminates one more item from the TODO list.
Bruno
Bruno Haible writes:
> Bernhard Voelker wrote:
>> > Last month, I spent 2 days on prerelease testing of coreutils. If, after
>> > downloading the carefully prepared tarball from ftp.gnu.org, the first
>> > thing a distro does is to throw away the *.m4 files and regenerate the
>> > configure s
On 4/10/24 7:17 AM, Bruno Haible wrote:
> Pretty good. The only thing that's missing is the type check for
> module_filter.
> Is it
> module_filter is functionNope!
> module_filter is CallableNope!
> module_filter is callable
On 4/10/24 4:22 PM, Bruno Haible wrote:
Sure, if downstream applies a patch that modifies bootstrap.conf, they need
to rerun 'bootstrap'. That goes without saying. I hope downstream then also
runs "make check".
Sure, full automated QA is in action on all supported platforms.
Have a nice day,
B
> Patch attached.
Typo patch applied.
Bernhard Voelker wrote:
> > Last month, I spent 2 days on prerelease testing of coreutils. If, after
> > downloading the carefully prepared tarball from ftp.gnu.org, the first
> > thing a distro does is to throw away the *.m4 files and regenerate the
> > configure script with their own one,
>
Hi Collin,
> > A better fix would be revisit this 'verifier'. Either an enum with 3
> > possible
> > values, or (better) a function GLModule -> bool. And call it 'moduleFilter'
> > rather than 'verifier'.
>
> How does this patch look?
Pretty good. The only thing that's missing is the type chec
Hi Bruno,
On 4/10/24 4:26 AM, Bruno Haible wrote:
> The Python implementation has created a tests/ directory instead of a
> gettext-tools/tests/ directory.
Ah, I see. Sounds like something simple. I don't think I have even
looked at that section of the code...
I'll try to get around to fixing th
Hi Bruno,
On 4/9/24 12:04 PM, Bruno Haible wrote:
> A better fix would be revisit this 'verifier'. Either an enum with 3 possible
> values, or (better) a function GLModule -> bool. And call it 'moduleFilter'
> rather than 'verifier'.
How does this patch look?
This method seems much clearer to m
On 4/1/24 11:54 PM, Bruno Haible wrote:
> Last month, I spent 2 days on prerelease testing of coreutils. If, after
> downloading the carefully prepared tarball from ftp.gnu.org, the first
> thing a distro does is to throw away the *.m4 files and regenerate the
> configure script with their own one
Hi Collin,
Another package that shows a difference. Can you please handle it?
$ export GNULIB_TOOL_IMPL=sh+py
$ git clone https://git.savannah.gnu.org/git/wget.git
$ cd wget
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
...
./bootstrap: .../gnulib-tool --no-changelog --aux-dir=bu
Hi Collin,
Can you please look into this one?
$ export GNULIB_TOOL_IMPL=sh+py
$ git clone https://git.savannah.gnu.org/git/gettext.git
$ sh -x ./autogen.sh
...
+ .../gnulib-tool --copy-file tests/init.sh gettext-tools
.../gnulib-tool: *** gnulib-tool.py produced different files than
gnulib-tool.
Hi Collin,
> By the way, here is a list of packages that I have tested using your
> method here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00018.html
Good progress!
> These were done sometime in the past ~10 commits, so I would have to
> go through and double check no br
26 matches
Mail list logo
