Bernhard Voelker writes:
> On 4/21/24 01:14, Bruno Haible wrote:
>>- install Python on their development machines,
>
> I'd guess most hosts have python installed nowadays ... the question is
> rather which version of it, and how compatible it is:
What a host has installed (or could install) i
On 4/21/24 01:14, Bruno Haible wrote:
- install Python on their development machines,
I'd guess most hosts have python installed nowadays ... the question is
rather which version of it, and how compatible it is:
now it's <3.7 which is incompatible (according to your mail),
but in future ther
Paul Eggert wrote:
> I hope we can drop the sh implementation at the first opportunity -
> which would be after we've tested the Python implementation enough, and
> when we want to add some features and it's a pain to add them to both sh
> and Python.
Of course it's a pain to maintain two imple
I hope we can drop the sh implementation at the first opportunity -
which would be after we've tested the Python implementation enough, and
when we want to add some features and it's a pain to add them to both sh
and Python.
Bernhard Voelker wrote:
> There will come the question whether there are plans to drop the 'sh' mode,
> or if or how long both modes will be maintained in parallel.
Sure, the question will come. And the conclusion will be based on two
considerations:
- No package maintainer is expected to say "I
Hi Paul,
Thanks for the feedback.
> If you are using git submodules, something like this:
> $ git -C gnulib pull origin master
> $ git commit -m 'build: update gnulib submodule to latest' gnulib
With the newest 'bootstrap', this would not be needed. But many packages
still
On 4/20/24 02:22, Bruno Haible wrote:
Hi,
It's now time to call for beta-testers of the Python gnulib-tool.
I plan to post the same text to info-gnu and to planet.gnu.org.
Here is a draft. Please comment!
findutils results ...
--
On 20/04/2024 01:22, Bruno Haible wrote:
Hi,
It's now time to call for beta-testers of the Python gnulib-tool.
I plan to post the same text to info-gnu and to planet.gnu.org.
Here is a draft. Please comment!
coreutils results...
4. Clean the built files of your package:
$ make -k
Bruno Haible writes:
> Hi,
>
> It's now time to call for beta-testers of the Python gnulib-tool.
> I plan to post the same text to info-gnu and to planet.gnu.org.
Confirmed success with oath-toolkit; identical generated files.
Old execution time was ~48 seconds, now it is at 0.7 seconds.
The s
On 2024-04-19 17:22, Bruno Haible wrote:
Hi,
2. Update your gnulib checkout. (For some packages, it comes as a
git submodule named 'gnulib'.) Like this:
$ git pull
Set the environment variable GNULIB_SRCDIR, pointing to this checkout.
Might help to spell out what to do
Collin Funk wrote:
> But would this work on stable branches?
It would not work, no. Also it would not work in submodules (which fix
a certain commit of gnulib). That's why in step 2 we need a
$ git checkout master
Bruno
On 4/19/24 5:22 PM, Bruno Haible wrote:
> 5. Regenerate the fetched and generated files of your package.
> Depending on the packge, this may be a command such as
>$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
Forgive me if this is a silly question, I have focused on
pygnulib
PS:
> 2. Update your gnulib checkout. (For some packages, it comes as a
> git submodule named 'gnulib'.) Like this:
>$ git pull
That should be:
$ git checkout master
$ git pull
Hi,
It's now time to call for beta-testers of the Python gnulib-tool.
I plan to post the same text to info-gnu and to planet.gnu.org.
Here is a draft. Please comment!
-
GNU gnulib: calling for beta-testers
If you are developer
14 matches
Mail list logo