On 4/19/24 10:07 AM, Bruno Haible wrote:
> Yeah, it seems redundant. You will surely find out whether doing so
> triggers some warnings from pylint, PyCharm, or other tools...
What do you think of the attached patch?
I tried to find out more about these variables but they are only
mentioned brief
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 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
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 ...
--
This difference in output was highlighted by the sh+py mode:
diff -u tmp3271005-result/do-autobuild
tmp3271005-result-glpy3271006/do-autobuild
--- tmp3271005-result/do-autobuild 2024-04-20 20:42:09.788152428 +0200
+++ tmp3271005-result-glpy3271006/do-autobuild 2024-04-20 20:41:12.699970866
On 2024-04-17 16:09, Bruno Haible wrote:
Can I have your agreement to relicensing your contributions to this
module under LGPLv2+, please?
Yes, that's fine.
When computing the list of old and new file, gnulib-tool.sh sorts them in
ASCII order, i.e. case-sensitively. (gnulib.tool.sh lines 5507 and 5513.)
gnulib-tool.py needs to be consistent with that.
2024-04-20 Bruno Haible
gnulib-tool.py: Sort file lists case-sensitively.
* pygn
Trying the GNULIB_TOOL_IMPL=sh+py procedure on my 'diffutils' checkout,
I see a failure:
/GNULIB/gnulib-git/gnulib-tool: *** gnulib-tool.py produced different files
than gnulib-tool.sh! Compare /DIFFUTILS/diffutils-1 and /DIFFUTILS/glpyEnEmgU.
/GNULIB/gnulib-git/gnulib-tool: *** Stop.
./bootstrap
Hi Collin,
> What do you think of the attached patch?
Looks good, and passes the test suite. => Applied.
> from pygnulib import __author__, __copyright__
>
> to get them from __init__.py.
That seems to work, yes.
Thanks!
Bruno
Paul Eggert reported:
> I tried this on my well-worn copy of GNU diffutils, and got the
> following diagnostics. These were all diagnostics about backup files, or
> files I manually deleted by moving them into a '.del' subdirectory (an
> old habit of mine), or symlink loops that I had created to
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
Simon Josefsson wrote:
> jas@kaka:~/src/oath-toolkit$ time make -f cfg.mk
> ...
> real 0m48,169s
> user 0m49,900s
> sys 0m9,658s
> jas@kaka:~/src/oath-toolkit$ export GNULIB_TOOL_IMPL=py
> jas@kaka:~/src/oath-toolkit$ time make -f cfg.mk
> ...
> real 0m0,704s
> user 0m0,527s
> sys 0m0,179
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
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.
Hi Bruno,
On 4/20/24 3:50 PM, Bruno Haible wrote:
> On Linux: On Cygwin 2.9.0:
>
> in create-tests: time ./test-all.sh in create-tests: time
> ./test-all.sh
> sh: 1225 secsh: 27406 sec
> py: 155 sec
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
On Sonntag, 21. April 2024 01:01:01 CEST Collin Funk wrote:
> Hi Bruno,
>
> On 4/20/24 3:50 PM, Bruno Haible wrote:
> > On Linux: On Cygwin 2.9.0:
> >
> > in create-tests: time ./test-all.sh in create-tests: time
> > ./test-all.sh
> > sh: 1225 sec
> > Can I have your agreement to relicensing your contributions to this
> > module under LGPLv2+, please?
Thanks to you all for approving it. (Daniel Richard G.'s approval reached me
by private email.)
With this, we can relicense 'nan' under LGPLv2+.
And 'signed-nan' as well, to which I am the o
On 4/20/24 4:50 PM, Bruno Haible wrote:
> What I measure (with "GNULIB_TOOL_IMPL=sh time ./test-create-testdir-1.sh")
> is:
> dash 22 sec
> bash 20 sec
dash 31 sec
bash 28 sec
Similar here. Looks like my desktop is just older than I remembered
originally.
> I think that 'dash' is genera
Two type hints are incorrectly marked 'dict[str, str]' instead of
'dict[str, tuple[re.Pattern, str] | None]'. I assume I forgot to
change these when inlining sed expressions to use re.sub().
Previously the dict would be:
# key : value
'file-category' : 'sed-expression'
but now it is:
When using --create-testdir with a bad module name:
$ gnulib-tool.py --create-testdir --dir aaa bad-module-name
gnulib-tool: warning: module bad-module-name doesn't exist
Traceback (most recent call last):
File "/home/collin/.local/src/gnulib/.gnulib-tool.py", line 30, in
main.main_with_exc
21 matches
Mail list logo
