Simon Josefsson wrote:
> I'm not sure I follow what you actually plan to do wrt multiple files
> X1, X2, ... Xn. Can you give some code example? Maybe I understand
> that better...
Roughly like this (untested).
# func_file_vmtime returns the virtual modification time of a file,
# as a number of
Bruno Haible writes:
> Simon Josefsson wrote:
>> I'm not sure I follow what you actually plan to do wrt multiple files
>> X1, X2, ... Xn. Can you give some code example? Maybe I understand
>> that better...
>
> Roughly like this (untested).
Oh, that is neat! But is there any advantage compare
Hi
I got this error message when doing 'make release':
make release-prep RELEASE_TYPE=alpha
make[2]: Entering directory '/builds/debdistutils/packages/b'
make --no-print-directory -s announcement \
> ~/announce-libidn-17.42.23
/bin/bash: line 2: cd: ../libidn/gnulib: No such file or directory
a
Yesterday's patches added more than 50 new deprecated modules. Of course,
we don't plan to document deprecated modules; therefore it makes no sense
to list them in the "Undocumented modules" index. This patch implemnts that.
2024-12-28 Bruno Haible
doc: Omit deprecated modules from th
Jim Meyering writes:
> On Sat, Dec 28, 2024 at 10:01 AM Simon Josefsson wrote:
>> Jim Meyering writes:
>>
>> >> if test "x$v" = xUNKNOWN \
>> >> && test -f ${tarball_version_file}-git \
>> >> && head -1 ${tarball_version_file}-git \
>> >> | grep -v '^$Format' > /dev/
Jim Meyering writes:
>> if test "x$v" = xUNKNOWN \
>> && test -f ${tarball_version_file}-git \
>> && head -1 ${tarball_version_file}-git \
>> | grep -v '^$Format' > /dev/null 2>&1; then
>> v=$(head -1 ${tarball_version_file}-git)
>> fi
>
> That code uses "grep -v"
Oops. Thank you.
Hmm... it shouldn't be hard to make vc-dwim do the right thing by
default for projects like gnulib that VC their ChangeLog file.
On Sat, Dec 28, 2024 at 9:46 AM Bruno Haible wrote:
>
> Jim Meyering wrote:
> > I've fixed that and cleaned up via this just-pushed change:
>
> I've a
On 12/26/24 17:06, Bruno Haible via Gnulib discussion list wrote:
Rather than assign a silly
EPOCH_DATE or some other nonsense [1], the idea would be to take
timestamp(Y) := max (vmtime(X1), vmtime(X2), ..., vmtime(Xn)).
where vmtime(X) is defined as:
- if X is under version control and
Simon Josefsson via Gnulib discussion list writes:
> --- a/top/maint.mk
> +++ b/top/maint.mk
Please disregard that part, it is an unrelated the change for a
completely different problem and I'm still experimenting with that patch
to see if it is the right one...
/Simon
signature.asc
Descripti
Paul Eggert writes:
> On 12/28/24 04:38, Simon Josefsson via Gnulib discussion list wrote:
>> The tarball use the same
>> mtime for all files.
>> So I don't understand this concern. What problem do you see if you
>> don't perform those steps?
>
> I must be missing something because for many tarb
Building a testdir on CentOS 6, I get this compilation error:
depbase=`echo file-has-acl.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC
-DEXEEXT=\"\" -I. -I../../gllib -I.. -DGNULIB_STRICT_CHECKING=1
-I/home/bruno/inst-x86
Hi.
This error was triggered when running 'make release' in a VPATH build:
(my $first_name = `git config user.name|cut -d' ' -f1`)
=~ m{\S} or die "no name? set user.name in ~/.gitconfig\n";
Fortunately the script already know srcdir so passing it to git with -C
was simple. I pushed this
On Sat, Dec 28, 2024 at 10:01 AM Simon Josefsson wrote:
> Jim Meyering writes:
>
> >> if test "x$v" = xUNKNOWN \
> >> && test -f ${tarball_version_file}-git \
> >> && head -1 ${tarball_version_file}-git \
> >> | grep -v '^$Format' > /dev/null 2>&1; then
> >> v=$(he
On 12/28/24 10:08, Simon Josefsson wrote:
some 'make's treat
equal timestamps as meaning the destination is out of date and needs
to be rebuilt. (Although POSIX does not require this 'make' behavior,
it encourages it.)
Which 'make' behave like that?
AIX and HP-UX 'make', to my knowledge. I wou
Building a testdir on FreeBSD 11, I get this compilation error:
c++ -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I../../gltests -I..
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I..
-I../../gltests/.. -I../gllib -I../../gltests/../gllib -I/home/bruno/include
-Wall -
On Fri, Dec 27, 2024 at 3:35 AM Simon Josefsson wrote:
> Hi Jim, all,
Hi Simon,
> If I run git-version-gen in a snapshot of a git repository it will
> return UNKNOWN because it cannot find out the version.
>
> Git has a .gitattribute mechanism to mark some files as 'export-subst'
> which makes g
Building a testdir of module 'endian' on CentOS 5, I get this build error:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../gltests -I..
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I..
-I../../gltests/.. -I../gllib -I../../gltests/../gllib
-I/home/bruno/inst-x86_64-64/include
Jim Meyering wrote:
> I've fixed that and cleaned up via this just-pushed change:
I've added the mandatory ChangeLog entry for your change.
Bruno
On 12/28/24 04:38, Simon Josefsson via Gnulib discussion list wrote:
The tarball use the same
mtime for all files.
So I don't understand this concern. What problem do you see if you
don't perform those steps?
I must be missing something because for many tarballs it's obvious that
one shouldn
Thanks for doing that, and for doing all the other naming cleanup.
Bruno Haible via Gnulib discussion list writes:
> My conclusion is: The 'bmake' program that you tried is inferior
> to what NetBSD is using, and since on GNU systems we have GNU make,
> there is no need to support or even try another 'make' program.
I agree.
Also, Simon I remember Debian's bma
Hi Bruno,
Bruno Haible writes:
> The module 'servent' is still not in the Module index. Since two months
> ago, the idiom to use is:
Fixed, with the attached.
I'll remember to compare my changes to some of the other documentation
next time. Sorry about that. :)
Collin
>From 1d1888d09f0f67517
On NetBSD 7.1.1, I'm seeing a compilation error:
gcc -std=gnu11 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I../../gltests
-I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I..
-I../../gltests/.. -I../gllib -I../../gltests/../gllib -I/home/bruno/include
-Wall -Wno-
Compiling a testdir on OpenBSD 6.0, I get this compilation error:
../gllib/wchar.h: In member function 'gnulib::_gl_wcrtomb_wrapper::operator
size_t (*)(char*, wchar_t, rpl_mbstate_t*)() const':
../gllib/wchar.h:1254: error: invalid conversion from 'size_t (*)(char*,
wchar_t, mbstate_t*)' to 'si
Simon Josefsson wrote:
> This also change from using 'git describe || git rev-parse --short=10'
> to using 'git rev-parse', which results in announcement to look like
> this:
>
> This release was bootstrapped with the following tools:
> Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20
Paul Eggert writes:
> On 12/28/24 10:08, Simon Josefsson wrote:
>>> some 'make's treat
>>> equal timestamps as meaning the destination is out of date and needs
>>> to be rebuilt. (Although POSIX does not require this 'make' behavior,
>>> it encourages it.)
>> Which 'make' behave like that?
>
> AI
On Sat, Dec 28, 2024 at 11:26 AM Simon Josefsson wrote:
>
> Jim Meyering writes:
>
> > On Sat, Dec 28, 2024 at 10:01 AM Simon Josefsson
> > wrote:
> >> Jim Meyering writes:
> >>
> >> >> if test "x$v" = xUNKNOWN \
> >> >> && test -f ${tarball_version_file}-git \
> >> >> && head
Thanks -- I agree avoiding 'grep' is nice, I pushed this change inspired
by your approach.
/Simon
From 83c5387249b5bbfd32d01a51af14ac53bac1bc36 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sat, 28 Dec 2024 21:19:18 +0100
Subject: [PATCH] git-version-gen: avoid use of grep, suggested by Ji
> I've applied the attached patch to mention the servent module in the
> documentation for the functions getservbyname and getservbyport.
The module 'servent' is still not in the Module index. Since two months
ago, the idiom to use is:
Gnulib module:
@mindex
Bruno
[Changing the subject to attract more attention]
Simon Josefsson wrote:
> 4) using abbreviated short identifiers makes it possible for someone
> to create a malicious git commit that matches the hash prefix, and
> then it would be unclear which commit the announcement really
> ref
Hi Collin,
> I've applied the attached patch to mention the servent module in the
> documentation for the functions getservbyname and getservbyport.
A nit: In an @itemize list, each paragraph has an @item line. When you
add a paragraph, and an @item before it. When you delete a paragraph,
delete
Simon Josefsson wrote:
> > is to suffix it with a date:
> >
> > Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20 (2024-12-28)
>
> I agree. Even the date is more human friendly, so how about
>
> Gnulib 2024-12-28 (552c0b06355a6720c8ce87ce305f42ed15a32d20)
Yes, this is even better. It an
Bruno Haible writes:
> A nit: In an @itemize list, each paragraph has an @item line. When you
> add a paragraph, and an @item before it. When you delete a paragraph,
> delete the @item before it.
>
> But you shouldn't delete such a paragraph. Rather, move it from the
> section "Portability proble
On 12/28/24 12:07, Simon Josefsson wrote:
I tried on cfarm's AIX 7.1 and 7.3 with /usr/bin/make and
libidn and it worked fine.
Oh, I thought AIX had the problem because it exhibits this behavior:
$ echo 't: s; cp -p s t' >Makefile
$ touch s
$ make
cp -p s t
$ make
c
On 12/28/24 15:46, Bruno Haible via Gnulib discussion list wrote:
What a human reader would like to understand is whether such a
commit number is recent or not. Therefore, what I would suggest
is to suffix it with a date:
Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20 (2024-12-28)
I
Bruno Haible via Gnulib discussion list writes:
> Hi Simon,
>
> Simon Josefsson wrote:
>> Hi. I tried building libidn using 'bmake' from Debian which labels
>> itself as NetBSD make and got this error message:
>>
>> bmake: don't know how to make iconv_open-aix.h. Stop
>> ...
>> I naively sugges
Bruno Haible via Gnulib discussion list writes:
> [Changing the subject to attract more attention]
>
> Simon Josefsson wrote:
>> 4) using abbreviated short identifiers makes it possible for someone
>> to create a malicious git commit that matches the hash prefix, and
>> then it would
Bruno Haible via Gnulib discussion list writes:
> Simon Josefsson wrote:
>> This also change from using 'git describe || git rev-parse --short=10'
>> to using 'git rev-parse', which results in announcement to look like
>> this:
>>
>> This release was bootstrapped with the following tools:
>
Hi. I tried building libidn using 'bmake' from Debian which labels
itself as NetBSD make and got this error message:
bmake: don't know how to make iconv_open-aix.h. Stop
Looking at modules/iconv_open it has these rules:
$(srcdir)/iconv_open-aix.h: $(srcdir)/iconv_open-aix.gperf
$(V_GPER
Hi,
I've applied the attached patch to mention the servent module in the
documentation for the functions getservbyname and getservbyport. These
functions exist on Windows in winsock2.h [1][2].
Also, since servent depends on sys_socket-h which will include
winsock2.h on Windows I am 99% sure the d
Hi Simon,
Simon Josefsson wrote:
> Hi. I tried building libidn using 'bmake' from Debian which labels
> itself as NetBSD make and got this error message:
>
> bmake: don't know how to make iconv_open-aix.h. Stop
> ...
> I naively suggest the patch below (which makes bmake happy), but I may
> be m
Simon Josefsson via Gnulib discussion list writes:
> It seems this make implementation barfs at
> '$(srcdir)/iconv_open-aix.h:', even changing it into
> './iconv_open-aix.h:' works.
That should be 'does NOT work'.
/Simon
signature.asc
Description: PGP signature
Simon Josefsson wrote:
> Oh, that is neat! But is there any advantage compared to simply using a
> global mtime for all files in the tarball?
For the specific case of creating a tarball, I see three advantages:
* When you pick a global mtime for all files, you need to pick it in a
way that
While the gnulib CI is "green", building a testdir on older BSD platforms leads
to compilation errors.
For example, on OpenBSD 6.0, most compilation units fail to compile with these
errors:
gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC
-DEXEEXT=\"\" -I. -I../../gllib
Bruno Haible via Gnulib discussion list writes:
> Simon Josefsson wrote:
>> Oh, that is neat! But is there any advantage compared to simply using a
>> global mtime for all files in the tarball?
>
> For the specific case of creating a tarball, I see three advantages:
>
> * When you pick a globa
45 matches
Mail list logo
