Hi Bruno,
With all of the updates to gnulib-tool.py it is very easy to see why
GNU Bison fails to build. This is the only diff shown between
gnulib-tool.py and gnulib-tool.sh after running ./bootstrap:
--- a/bison-python/gnulib-po/LINGUAS
+++ b/bison-shell/gnulib-po/LINGUAS
@@ -1,18 +1,4 @@
# Se
Hi Bruno,
On 3/26/24 5:20 AM, Bruno Haible wrote:
> Regarding the 'modules' subdirectory: When I see you replacing 2 lines of code
> with 8 lines of code, and especially searching for a 'modules' file name
> component, I wonder whether there's no simpler solution.
> Namely, a module of name NAME c
On 3/30/24 4:29 PM, Bruno Haible wrote:
> I see. This is similar to the initial code for the GLMakefileTable, which
> cloned the table row in the getter. Here it sorted the lists in the setter.
> Feels like a "safety first" attitude that was slightly exaggerated.
Maybe. I also added 'sorted(set(mo
Hi Bruno,
On 3/30/24 4:22 PM, Bruno Haible wrote:
> Once the test suite entirely passes, will be the time to revisit this
> 'cleaner'
> function. Your approach with the regex can be part of the solution.
Yes, that sounds like a good idea. It should be easier to validate
changes that way. The tes
Hi Pádraig,
> As a matter of interest, where did you get the figure that
> 94% of users have a $TERM set to xterm.* ?
Personal guesses / estimations :-D.
> > +def get_terminfo_string(capability: str) -> str:
> > +'''Returns the value of a string-type terminfo capability for the
> > current
Collin Funk wrote:
> In a few of the import tests gnulib-tool.py doesn't add the 'dummy'
> module even though gnulib-tool.sh does.
>
> This is because the 'dummy' module was added after GLImport saved the
> modules in the GLModuleTable:
>
> # Transmit base_modules, final_modules, main_mod
Hello Collin,
Back to our usual business.
> This small patch fixes this diff in the import tests:
>
> $ cat ../output.txt
> $ diff -u ./test-oath-toolkit-1.result/gl/m4/gnulib-cache.m4
> tmp27490-result/gl/m4/gnulib-cache.m4
> --- ./test-oath-toolkit-1.result/gl/m4/gnulib-cache.m42024-
Eric Gallager wrote:
> wouldn't it be good to add some additional tests anyways?
I'm satisfied with testing that the invocations of this macro in GNU gettext
produce, in 'configure', exactly the expansion that I would expect.
If you want to contribute a unit test for it, feel free to do so.
> Li
On Sat, Mar 30, 2024 at 5:15 PM Bruno Haible wrote:
>
> Eric Gallager wrote:
> > One thing I noticed in the writeup is that part of the way it worked
> > involved a modified copy of gnulib's build-to-host.m4 macro file; ...
> > is if there's anything gnulib can add on
> > its end to ensure that th
Paul Eggert wrote:
> I installed the attached to do that. I don't know whether this will fix
> Andreas's problem, whatever it is.
Thanks. It will allow us to distinguish a completely dysfunctional
'Europe/Paris' from one which exists but does not have the correct data
about the DST begin and DST
Collin Funk wrote:
> This file was .gitignore'd and only contained in the distributed
> tarballs. Given the rest of the situation, the goal was obviously to
> hide this as much as possible. It is annoying that they choose to hide
> it among real, useful Gnulib code.
It was pretty logical that Jia
Eric Gallager wrote:
> One thing I noticed in the writeup is that part of the way it worked
> involved a modified copy of gnulib's build-to-host.m4 macro file; ...
> is if there's anything gnulib can add on
> its end to ensure that the macro actually does what it's supposed to
> do?
Having source
On 3/29/24 08:15, Andreas Schwab wrote:
On Mär 29 2024, Bruno Haible wrote:
Yes. And make sure that it has a time zone database installed at all.
Why? That doesn't make any sense.
Although Andreas is not clear, perhaps he is alluding to the fact that
Gnulib's localtime_r tests assume that
On 3/30/24 10:46 AM, Paul Eggert wrote:
> On 3/29/24 22:04, Eric Gallager wrote:
>> So, one thing I'm wondering, is if there's anything gnulib can add on
>> its end to ensure that the macro actually does what it's supposed to
>> do?
>
> That wouldn't suffice, since the attacker can arrange for gl_
On 3/29/24 22:04, Eric Gallager wrote:
So, one thing I'm wondering, is if there's anything gnulib can add on
its end to ensure that the macro actually does what it's supposed to
do?
That wouldn't suffice, since the attacker can arrange for
gl_BUILD_TO_HOST to do what it's actually supposed to
On 29/03/2024 21:59, Bruno Haible wrote:
Pádraig Brady wrote:
You could determine that programatically with something like:
if os.system(r'{ tput bold || tput md; } >/dev/null 2>&1') == 0:
# enable bold output
As a matter of interest, where did you get the figure that
94% of users have a
In a few of the import tests gnulib-tool.py doesn't add the 'dummy'
module even though gnulib-tool.sh does.
This is because the 'dummy' module was added after GLImport saved the
modules in the GLModuleTable:
# Transmit base_modules, final_modules, main_modules and tests_modules.
s
17 matches
Mail list logo
