Collin Funk wrote:
> I'm still finishing some things before we can recommend it for
> testing.
Right. It would not be productive if we had different package
maintainers report the same bug(s) at the same time.
> But Wget seems like a good project for testing. Do you have
> any thoughts Bruno?
Hi Darshit,
On 3/14/24 12:12 PM, Darshit Shah wrote:
> I'm following the development of gnulib-tool.py pretty closely. Wget and
> Wget2 have tried to use the Python version multiple times in the past with
> varying levels of success.
I am enjoying working on it, so hopefully this time will be
Hi Bruno and Colin,
I'm following the development of gnulib-tool.py pretty closely. Wget and Wget2
have tried to use the Python version multiple times in the past with varying
levels of success.
I'll volunteer my time for using GNU Wget and Wget2 as initial beta testers of
the new Python
Hi Bruno,
On 3/10/24 8:59 AM, Bruno Haible wrote:
> 4) There is a list of packages that use gnulib, in the file users.txt.
>We can pick, say, the 10 most important or most active GNU packages among
>these, and repeat step 3) for each of them.
I am still working on gnulib-tool.py.TODO and
I like the plan to replace gnulib-tool with a faster implementation, and
a two-year migration phase sounds reasonable to see if it will work in
practice.
Trying gnulib-tool.py on OATH Toolkit (which use a somewhat unorthodox
gnulib usage style by adding code into git) results in error below. I
Hi Simon and Bruno,
On 3/10/24 7:00 PM, Bruno Haible wrote:
> I think this would be a reasonable time after having made the Python
> implementation
> the default. I expect every package maintainer to run 'gnulib-tool' at least
> once
> in two years and report problems if they occur. Based on
Hi Simon,
> > - With approach (A), when we make a change to gnulib-tool, we need to
> > commit
> > new expected test results, which is quite easy. No effort otherwise.
> > - With approach (B), we will get failures for other reasons as well: when
> > a gnulib module has changed in an
Bruno Haible writes:
> I guess we are thinking about slightly different things:
>
> * (A) I am thinking about
> - for P in { coreutils, gettext, ... }, taking a frozen(!) checkout of P,
> removing irrelevant source files (esp. all *.h, *.c, documentation,
> etc.),
> - and a
Hi Simon,
> > 5) Possibly it makes also sense to allow GNULIB_TOOL_IMPL to be set to
> >'sh+py'. In this case the script will make a full copy of the destination
> >dir, run the shell implementation and the Python implementation on the
> >two destination dirs, separately, and compare
Bruno Haible writes:
> 5) Possibly it makes also sense to allow GNULIB_TOOL_IMPL to be set to
>'sh+py'. In this case the script will make a full copy of the destination
>dir, run the shell implementation and the Python implementation on the
>two destination dirs, separately, and
10 matches
Mail list logo
