Paul Eggert writes:
> You raise several good points. A couple of quick reaction:
>
> On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:
>
>> - the gnulib git submodule is huge. Not rarely I get out of memory
>>errors during 'git clone' in CI/CD jo
Bruno Haible writes:
> Hi Simon,
>
>> you can ... via
>> GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
>> needs. ...
>> [1]
>> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
>> [2]
Bruno Haible writes:
> Since
> - IRIX 6.5 is end-of-life for more than 10 years [1],
> - I don't have access to an IRIX machine any more,
> - the AC_SYS_LARGEFILE macro no longer supports IRIX,
> I would suggest to remove mentions of IRIX support from the
> documentation.
+1
"On
Reuben Thomas writes:
> TLDR: FTP Master rejected my libpaper package because it contains gnulib
> source files. I pointed out that other Debian packages for which I am
> upstream do exactly this and have been accepted, and that it is the
> standard way to use gnulib. A few senior Debian
Collin Funk writes:
> Hi Paul,
>
> On 4/23/24 11:22 PM, Paul Eggert wrote:
>> Why is telnetd.h including config.h? Only a top-level C file should
>> include config.h, and it should so so at the start.
>
> I don't disagree. Most of those lines are 20 years old, so I assume it
> wasn't a problem
Janneke Nieuwenhuizen writes:
>> Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap
>> uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So,
>> even if newer versions of 'make' or 'gcc' will use a Python-based
>> gnulib-tool,
>> there won't be a
Bruno Haible writes:
> Janneke Nieuwenhuizen wrote:
>> Are are we creating a problem for
>> bootstrapping (or even a dependency cycle) when introducing this new
>> dependency into a certain package.
>
> I think you answered this question with "no", when writing in [1]:
>
> "Even more recently
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
615498218a7995de98a201 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Mon, 15 Apr 2024 17:47:52 +0200
Subject: [PATCH] gitlog-to-changelog: Revert 2024-04-12 fix and add
documentation.
* build-aux/gitlog-to-changelog: Use localtime.
* doc/gitlog-to-changelog.texi: Add.
* doc/gnuli
Bruno Haible writes:
> Hi Simon,
>
> In the other thread [1][2][2a], but see also [3] and [4], you are asking
Hi Bruno -- thanks for attempting to bring som order to this complicated
matter! I am in agreement with most of what you say, although some
comments below.
>> Has this changed, so we
fre 2024-04-12 klockan 18:47 +0200 skrev Bruno Haible:
> The ChangeLogs are not random data. They are text files meant to be
> read
> and interpreted by humans. Shoving a "let's use GMT for everyone"
> attitude
> here is not the right way to handle the diversity of time zones.
>
> There was a
:~/src/gnulib$ build-aux/gitlog-to-changelog > foo
jas@kaka:~/src/gnulib$ TZ=UTC0 build-aux/gitlog-to-changelog > bar
jas@kaka:~/src/gnulib$ diff -ur foo bar
I have committed this.
/Simon
From dfb71172a46ef41f8cf8ab7ca529c1dd3097a41d Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri,
Simon Josefsson via Gnulib discussion list writes:
> My reaction was initially exactly the same as yours, until I found this
> piece of --help documentation, which actually is the first (and
> presumably highest priority) rule:
>
> * If the environment variable GNULIB_SRCDIR
Paul Eggert writes:
> On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
>> Is bootstrap intended to be reliable from within a tarball? I thought
>> the bootstrap script was not included in tarballs because it wasn't
>> designed to be ran that way, and t
Bruno Haible writes:
> Hi Simon,
>
>> Bug #2: ./bootstrap writes to the path indicated by --gnulib-srcdir with
>> the 'git checkout' command, and leaves the --gnulib-srcdir path at that
>> commit after ./bootstrap is finished. This happens to work in my
>> example since I pointed it to a
Hi
I'm trying to get ./bootstrap from a minimal source-only archive
generated via 'git archive' that has GNULIB_REVISION set in
bootstrap.conf, expecting this to work:
./bootstrap --gnulib-srcdir=/home/jas/src/gnulib
Bug #1: it seems GNULIB_REVISION in bootstrap.conf has no effect, and
this
Bruno Haible writes:
> Bernhard Voelker wrote:
>> > Last month, I spent 2 days on prerelease testing of coreutils. If, after
>> > downloading the carefully prepared tarball from ftp.gnu.org, the first
>> > thing a distro does is to throw away the *.m4 files and regenerate the
>> > configure
Guillem Jover writes:
> But if as a downstream distribution I explicitly request everything to
> be considered obsolete via --force, then I really do want to get whatever
> is in the system instead of in the upstream package. Because then I
> can fix things centrally in a distribution dependency
Eric Blake writes:
> Widening the audience to include bug-gnulib, which is the upstream
> source of "# build-to-host.m4 serial 3" which was bypassed by the
> malicious "# build-to-host.m4 serial 30".
>
> On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote:
>> Hi!
>>
>> While analyzing
Bruno Haible writes:
> Hi Simon and Collin,
>
>> > Could putting the following into bootstrap.conf be a method that
>> > we could recommend? Then developers can override it with
>> > GNULIB_TOOL_IMPL=sh ./bootstrap if they want.
>> >
>> > GNULIB_TOOL_IMPL=${GNULIB_TOOL_IMPL:-py}
>>
>> I'd
(moving to bug-gnulib)
Collin Funk writes:
> On 3/22/24 2:18 PM, Simon Josefsson wrote:
>> Upgrading inetutils to use gnulib-tool.py would be nice. As a start, I
>> bumped the gnulib submodule.
>
> Bruno and I are still working on it with a test suite. We want the
>
Collin Funk writes:
>> But in the current state, it fails for nearly every command. There's
>> no hope that you can expect identical results from the two implementations
>> as long as there are still items in the TODO list.
>
> Yes. I am working on it. I've added the following lines to my
>
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
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
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
Bruno Haible writes:
> Simon Josefsson wrote:
>> is it possible to design a reliable
>> caching mechanism? Something similar to CONFIG_SITE for autoconf?
>
> CONFIG_SITE is not reliable; that's the problem with it...
>
>> I find that ./gnulib-tool takes a long
Bruno Haible writes:
>> What is the status of the Python gnulib tool? I'm not sure how far
>> behind it is compared to the shell script but it seems like it would
>> be much faster. I would say more maintainable but I might just be bad
>> at writing shell scripts. :)
>
> Yes, it's the hope that
Bruno Haible writes:
> --- a/top/maint.mk
> +++ b/top/maint.mk
> @@ -503,6 +503,7 @@ sc_prohibit_have_config_h:
> # Nearly all .c files must include . However, we also permit this
> # via inclusion of a package-specific header, if cfg.mk specified one.
> # config_h_header must be suitable
Bruno Haible writes:
> Paul Eggert wrote:
>> >> So CTIME_BUFSIZE should be 35?
>> > With 50 years of computer science experience, we should have learned
>> > the lesson to allocate more room than sounds necessary*now*. If
>> > now you think 35 will be sufficient for all times, then we should
>>
tring functions.
Copyright (C) 2024 FSF
Authors: Paul Eggert, Bruno Haible, Simon Josefsson
License: LGPL-2+
*/
#include
#include
/* This evaluates to 35 on typical machines today, and will grow
automatically if time_t gets wider - it could even exceed 70 if
needed. 7 = fl
How about this (or gl-ctime?):
/* safer-ctime.h -- safer version of ctime().
Copyright (C) 2024 FSF
Authors: Paul Eggert, Bruno Haible, Simon Josefsson
License: LGPL-2+
*/
#define SAFER_CTIME_BUFSIZE 35
/* Convert WHEN representing the number of seconds before/after epoch,
1970-01
Paul Eggert writes:
> and we can package this up into a function like this:
>
> char c[CTIME_BUFSIZE];
> safer_ctime (c, *tp);
>
> if people prefer simplicity.
Yes please. Using complex APIs to implement safer_ctime is fine, but I
would prefer to not make existing ctime code more
You convinced me inetutils (and many other programs) has real bugs
related to ctime today that should be fixed. Now I want to figure out
what the best fix to existing code is.
Paul Eggert writes:
>> Another idea is to have gnulib's ctime augment the C standard to have
>> ctime not be undefined
Here are some examples of ctime usage in GNU InetUtils, starting with
inetd (a single-threaded application):
https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/inetd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1710
This prints day of time of the system. While we could rewrite that to
mån 2024-02-05 klockan 00:59 -0800 skrev Paul Eggert:
> On 2024-02-05 00:16, Simon Josefsson wrote:
> > didn't see anything in your patch that would warn about usage of
> > ctime?
> > Would it make sense for a gnulib ctime module to NOT replace ctime
> > but
> &g
Paul Eggert writes:
> This recent bug relating to ctime suggests that the ctime module is
> more trouble than it's worth now. I propose that we remove
> it. Proposed patch attached (but not installed).
Intresting approach -- I don't mind changing any ctime calls to strftime
in code I come
Paul Eggert writes:
> On 2024-01-01 16:08, Bernhard Voelker wrote:
>> That commit broke the 'update-copyright' tests, because the test script
>> got messed up.
>
> Thanks for reporting that. Turing would have been amused by
> update-copyright modifying its own test, and then failing the modified
Thanks for report, Dmitry. I am slowly coming back to this. I have
noticed that Cygwin (via MSYS2) has the same strverscmp as musl:
https://cygwin.com/cgit/newlib-cygwin/tree/newlib/libc/string/strverscmp.c
Compare against musl strverscmp:
Happy hew year!
I was greeted with the seasonal
copyright_check
./gnulib/lib/version-etc.c
maint.mk: out of date copyright in ./gnulib/lib/version-etc.c; update it
in several projects, and did a copyright year bump.
/Simon
signature.asc
Description: PGP signature
/ChangeLog
index 4c5a678323..a3a10e0258 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2023-12-29 Simon Josefsson
+
+ announce-gen: Improve links.
+ * build-aux/announce-gen: Use https:// URLs.
+
2023-12-29 Bruno Haible
error: More clang -Winclude-next-absolute-path
Bruno Haible writes:
> Simon Josefsson wrote:
>> Looking at many traditional GNU tools, it seems --help strings uses
>> lower-case so can we settle on that?
>
> From what I've seen, there are widely used programs in either camp.
> Picking some programs at random:
>
Jeffrey Walton writes:
>> What should we do?
>> (A) Ensure that glibc and gnulib argp behave the same:
>> - Push Sergey's lowercase commit into glibc?
>> - Revert Sergey's lowercase commit in gnulib?
>> or
>> (B) Ensure that gnulib overrides glibc:
>> - Use '#define
Pádraig Brady writes:
> However if there are good use-cases for bad inputs
> we may need to adjust this patch,
> rather than failing unconditionally.
>
> For example we could just flag non canonical input in the context,
> and leave it up to the caller how to deal with that.
That adds
Pádraig Brady writes:
> To give a little more context, this will avoid
> round trip issues like the following, by failing early:
>
> $ echo "HelloWorld==" | base64 -d | base64
> HelloWorlQ==
Thanks for background and patches! There are use-cases for bad inputs
(both for good and malicious
Bruno Haible writes:
> * Commit b93de66735cd6f935ee0970f8cb26908d113e09d introduced mcel.h, but
> it has tabs. Can we untabify
> mcel.h
> mountlist.c
> verify.h
> (as we do with all source files that are not shared with glibc)?
We may have discussed this before, but what do you
Bruno Haible writes:
> -#define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
> -#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED &&
> BUILDING_LIBFOO
> -#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
> -#elif (defined _WIN32 && !defined __CYGWIN__) &&
From: Simon Josefsson
Date: Mon, 17 Jul 2023 22:07:57 +0200
Subject: [PATCH] announce-gen: Allow using local git user.name.
* build-aux/announce-gen (readable_interval): Remove --global
parameter to 'git config' call.
---
ChangeLog | 6 ++
build-aux/announce-gen | 4 ++--
2
Bruno Haible writes:
> Thanks for the inputs and feedbacks. Here are the new modules
> string-desc,
> xstring-desc,
> string-desc-quotearg
> that I'm adding.
Thank you for making it library-friendly! I will try to find some
package and migrate to these tools, rather than to use custom
Bruno Haible writes:
> struct
> {
> size_t nbytes;
> char * data;
> }
>
> I propose to add a module that adds such a type, together with elementary
> functions that work on them.
I think this is a useful contribution, however I see two deal-breakers
for having it in gnulib -- both
tis 2023-03-07 klockan 14:20 +0100 skrev Bruno Haible:
> Simon Josefsson wrote:
> > Consider adjusting your habit to update the libtool version
> > directly
> > AFTER a release instead. I put the following in cfg.mk to make
> > sure I
> > don't forget this:
Vivien Kraus writes:
> Dear gnulib people,
>
> How do you manage the libtool version information for a library using
> gnulib? For now, I have it written down explicitly in configure.ac.
> Unfortunately, this requires a new commit to bump the numbers before
> each release.
>
> Gnulib provides a
Bruno Haible writes:
> Therefore, I would be in favour of EITHER
> * doing this when the community as a whole has adopted 'nullptr' in C, i.e.
> this keyword is no longer something that is new to an average newcomer,
> (even if that's only 10 years from now),
> OR
> * doing the change only
Reuben Thomas writes:
> Using the standard gnulib release procedure for GNU projects,
> coordina...@translationproject.org is automatically emailed for each
> release, but apparently this is not desired. I received this from Benno
> Schulenberg :
>
> My scripts find zero changes in the msgids.
Bruno Haible writes:
> The 'fts' module was not documented in the documentation, so far.
The gnulib fts is different from glibc API, and they can return
different results when called the same way. See end of earlier thread
here:
Vivien Kraus writes:
> However, there are situations in which you only have access to a
> shallow clone of the git repository (for instance, Gitlab CI). I am not
> sure how this solution would work in that case.
Indeed, good point. I think 'make dist' should continue to work in
shallow clones,
Bruno Haible writes:
> Paul Eggert wrote:
>> some users want to "trust but verify" and a reproducible
>> tarball is easier to audit than a non-reproducible one, so for these
>> users it can be a win to omit the irrelevant data from the tarball.
>
> Reproducibility can be implemented in
Hi Bruno,
> Hi Simon,
>
>> > This attempts to make
>> > reproducible tarballs by sorting the files and passing the
>> > "--mtime=" option to tar. ...
>> Having the same mtime on all files in a tarball
>
> First question: What is the point of doing that?
Good question, I don't know the
Hi. Quoting the recent binutils announcement:
> As an experiment these tarballs were made with the new "-r "
> option supported by the src-release.sh script. This attempts to make
> reproducible tarballs by sorting the files and passing the
> "--mtime=" option to tar. The date used for
Hi. We got a bug report about a gnulib self-test failure:
https://gitlab.com/oath-toolkit/oath-toolkit/-/issues/30
Summarizing, this is the failure:
test-stat-time.c:186: assertion 'statinfo[2].st_mtime < statinfo[1].st_ctime ||
(statinfo[2].st_mtime == statinfo[1].st_ctime &&
Paul Eggert writes:
>> 2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for
>> GCC, which isn't working in non-GNU modes of gcc. Further wondering:
>
> I hope I fixed this particular problem by installing the attached.
Thank you!
> Perhaps Gnulib's other uses of asm should
Paul Eggert writes:
> Here's a proposed set of patches to add support for C23's
> memset_explicit function, along with the corresponding fallout in
> Gnulib. The idea is to prefer memset_explicit, but continue to
> support explicit_bzero (which is not marked as obsolescent, as it's
> too soon
no, what is the better idiom to use here instead of
explicit_bzero?
Other thoughts?
/Simon
Simon Josefsson via Discussion list for GNU Libtasn1
writes:
> Vincent Fortier writes:
>
>> While preparing a gnutls update I ended-up updating libtasn1 from
>> 4.16. Going to 4.17 works but
been a harmless one). I think this behaviour
should generally be considered a bug. I wonder if there are more
examples of this hidden deep inside scripts.
/Simon
From 0ab73798b5bc703233195c1d37f96d977fc26ad8 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sun, 13 Nov 2022 11:50:51 +0100
ion -- q
> Usage: grep -hblcnsviw pattern file . . .
>
> The portable alternative is
> grep 'GNU indent' > /dev/null
Thank you! I installed these two fixes, which caught the unportable
usages in scripts for some packages.
/Simon
From 4555e788613f1f5d1e8519427591bef3274d3124 Mon Sep 17 0
Hi. I installed this to let 'make syntax-check' on Mac OS succeed, I
don't think it is useful to use non-GNU indent.
/Simon
From 4ad0eedf4ff8d294a10c20b8945d0e59aa8141db Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Mon, 31 Oct 2022 09:42:42 +0100
Subject: [PATCH] maintainer-makefile
S= LC_ALL= LANGUAGE= date
'+%B %d, %Y'
October 25, 2022
jas@latte:~/src/gnulib$
The attached patch fixes this.
/Simon
From 1575cb2bb925bd0b4bd160e06e05d39303c5cca5 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Tue, 25 Oct 2022 23:39:15 +0200
Subject: [PATCH] gendocs: Output timestamp in Engli
Bruno Haible writes:
> While testing a GNU sed snapshot on macOS 10.13, I see this test failure:
...
> ==85029== Invalid read of size 16
...
> An out-of-bounds read. Oh oh. When I reconfigure and recompile with the
> environment variable
> gl_cv_func_working_getdelim=no
> this test succeeds.
Bruno Haible writes:
> Paul Eggert wrote:
>> > Shouldn't the following cause a compilation error?
>> >
>> > root@18544d251872:/# cat>foo.c
>> > int main (void) {
>> > int true = 42;
>> > return true;
>> > }
>>
>> Yes if you have a C23 compiler, which GCC 12 isn't. To get a proper
>>
Bruno Haible writes:
> Simon Josefsson wrote:
>> rlogind.c: In function 'rlogind_mainloop':
>> rlogind.c:1112:7: error: expected identifier or '(' before numeric constant
>> 1112 | int true;
>> | ^~~~
>>
>> The file does not include s
Hi.
Upgrading gnulib in inetutils causes a build failure:
rlogind.c: In function 'rlogind_mainloop':
rlogind.c:1112:7: error: expected identifier or '(' before numeric constant
1112 | int true;
| ^~~~
The file does not include stdbool.h. Apparently this has worked for
many years
Bjarni Ingi Gislason writes:
> "sh -x build-aux/get-version-gen" outputs:
I don't think that's a bug -- running the script under 'sh -x' is not a
supported by of invoking it, but a way to invoke shell debugging of the
script. I don't see anything unexpected in the debug output, it doesn't
similar comment to the manual: it is handy with a reference
for people like me who cannot remember all different warning flags and
whether they are generally useful or not.
/Simon
From 54c09c98a67219ba2cf70c4bb23f80990db37066 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri, 23 Sep 2022 09:06:22 +02
Btw, see my concerns with this code earlier here:
https://lists.gnu.org/archive/html/bug-gnulib/2022-08/msg00040.html
https://lists.gnu.org/archive/html/bug-gnulib/2022-08/msg00044.html
Instead of the patch, I have merely disabled it when I ran into issues,
since it doesn't add value for me and
Hi. I have committed this.
/Simon
From 4b17a1ae49e69df1ac5dc35a4f60b20ab958baf2 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Tue, 6 Sep 2022 14:32:05 +0200
Subject: [PATCH] gnumakefile: Improve tarball reproducibility.
* top/GNUmakefile (TAR_OPTIONS): Add --sort=name. Suggested
Bruno Haible writes:
> On MSVC, with libunistring installed as a shared library, I get this link
> error:
>
> /home/bruno/msvc/compile cl -nologo -MD -L/usr/local/msvc64/lib -o
> test-categ_none.exe unictype/test-categ_none.obj libtests.a ../gllib/libgnu.a
> libtests.a ../gllib/libgnu.a
Paul Eggert writes:
>> +if (ckd_mul (, plen, sizeof (CHAR))
>> \
>
> Indeed it should. Thanks for reporting that. I installed the attached.
Thank you!
>> I wonder why no self-check has caught this?
>
> Apparently I tested it only on platforms with working
I think some of these patches introduced a build failure of GNU
InetUtils on Debian 6, see build error below. The following looks
strange:
-if (INT_MULTIPLY_WRAPV (plen, sizeof (CHAR), ) \
-|| INT_ADD_WRAPV (new_used, plensize, _used)) \
+
Bruno Haible writes:
> Hi,
>
> Wesley Viana wrote:
>> So I was wondering how to contribute by "packing" gnulib into a brew
>> formula.
>
> Packaging gnulib through a packaging system (such as Debian, pkg, BSD ports,
> or brew) is, in the current state of things, not desirable.
>
> Gnulib is a
tor 2022-08-25 klockan 19:21 +0200 skrev Bruno Haible:
> Simon Josefsson wrote:
> > > In GNU gettext, many tests use "tr -d '\r'" since 2007 already,
> > > and no one
> > > ever has reported a problem with it.
> >
> > But does it fail fatally wh
Bruno Haible writes:
> Since we are already stating in the generic INSTALL file, since 2008:
>
> On Solaris, don't put '/usr/ucb' early in your 'PATH'. This
> directory contains several dysfunctional programs; working variants of
> these programs are available in '/usr/bin'. So, if
Bruno Haible writes:
> In this case, you'll better modify the unit test to pipe the result
> through "tr -d '\r'".
This is unrelated, but alas I've not found a more portable way to trim
CR than this since some tr do not support \r:
if echo solaris | tr -d '\r' | grep solais > /dev/null; then
I discovered use of DISTCHECK_CONFIGURE_FLAGS in Makefile.am for several
projects, but that's a user-variable and AM_DISTCHECK_CONFIGURE_FLAGS
should be used.
/Simon
From dec7194206fc1ec7db0a94472d8ece58025040c6 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Tue, 16 Aug 2022 17:26:56 +0200
Updated patch below.
Meanwhile, I'll disable the public-submodule-commit test in the projects
I work on -- I don't think it is appropriate to run it on every 'make
check' invocation. Disable it by putting this in cfg.mk:
submodule-checks =
gl_public_submodule_commit =
/Simon
diff --git
Hi
Fetching the gnulib submodule takes quite some time, so I'd like to use
a shallow checkout instead. However I get an error:
jas@latte:~/src/gsasl-small$ make check
GEN public-submodule-commit
fatal: run_command returned non-zero status for gnulib
.
maint.mk: found non-public submodule
This improve the suggested Makefile.am snippet.
/Simon
From 416872ced15e471f2af2f960ca911da05748a870 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Tue, 16 Aug 2022 00:28:22 +0200
Subject: [PATCH] pmccabe2html: Doc fix.
* build-aux/pmccabe2html: Don't use reserved _SOURCES namespace.
Use
Bruno Haible writes:
> Hi all 'bootstrap' users,
>
> Over the last few years, it has become more and more clear that bootstrap
> does two things:
> (1) Fetch auxiliary files that are not in the git checkout.
> This is the part that requires network access and that has
>
Bruno Haible writes:
> Hi dear GNU libidn developers (Simon et al.),
..
> These adjustments will be needed the next time you use the '--bootstrap-sync'
> option.
Thank you Bruno -- should be fixed in libidn git now.
/Simon
signature.asc
Description: PGP signature
Hi. I've pushed the attached patch, as bootstrap.conf is more of a
shell script than a conf file.
/Simon
From 1c7a057b52147c7bb734e94ed814116fcdba1b4c Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sun, 14 Aug 2022 22:38:01 +0200
Subject: [PATCH] bootstrap.conf: Use proper shell marker
Reuben Thomas writes:
> As suggested in the gnulib manual, I have converted a project (GNU a2ps) to
> use --po-base[=po-gnulib] and --po-domain, allowing gnulib to create an
> extra message catalog for gnulib sources.
>
> So, I have removed the gnulib files from po/POTFILES.in.
>
> However,
Bruno Haible writes:
> Recent discussion in gnu-prog-discuss has shown that making the separation
> into two phases (1) and (2) explicit will have several benefits:
Wonderful, thank you! I have yet to digest everything, so I'll fall
back on stylistic comments:
> The first phase is a script
Bruno Haible writes:
> The handling of the GNULIB_SRCDIR environment variable in 'bootstrap'
> is hard to understand, despite the long documentation in `bootstrap --help`.
Thank you! I have encountered this a couple of times, and always had to
read the source code to learn how it worked, and
Bruno Haible writes:
> Therefore I would now like to actually do it.
Thanks for working on this, it is important!
Maybe I am getting old, but one year seems like a fairly short period of
time. The list would be shortened with the following names if we used
two years:
Daiki Ueno
Bruno Haible writes:
> Hi Simon,
>
>> I'm reading
>>
>>
>> https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html
>>
>> that recommends using the 'gettext' module but it is marked obsolete:
>>
>> This module is obsolete. Use the module 'gettext-h' instead to
Hi
I'm reading
https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html
that recommends using the 'gettext' module but it is marked obsolete:
This module is obsolete. Use the module 'gettext-h' instead to make
your program capable of internationalization, when
'libiconv', since that just the implementation. 'iconv' is the POSIX
> facility's name.
Wonderful, thank you!
/Simon
>
> 2022-07-10 Bruno Haible
>
> iconv: Define a summary result.
> Reported by Simon Josefsson in
> <https://lists.gnu.org/archive/html/b
Bruno Haible writes:
> Simon Josefsson wrote:
>> + my $gpg_fingerprint = `LANG=C gpg --fingerprint $gpg_key_id | grep -v
>> ^sub`;
>
> LANG=C has no effect if LC_ALL is set, since LC_ALL has a higher precedence
> than
> LANG [1].
>
> [1]
> https:/
Bruno Haible writes:
> The last line gives an overfull line in the PDF output, so let me add a line
> break.
>
> Also, there is some collision risk for a shell variable named 'shared'.
>
> I'm therefore applying this:
Thank you Bruno!
/Simon
signature.asc
Description: PGP signature
Hi
In libidn and libidn2 we (used to) print this during ./configure:
Libiconv: $am_cv_func_iconv $LTLIBICONV
It prints the right thing in most cases, that is, one of these:
Libiconv: yes -liconv ...
Libiconv: no, consider installing GNU libiconv
However on
Bruno Haible writes:
> Hi Simon,
>
> Two remarks regarding 'announce-gen':
>
> 1) I used the command
>$ $GNULIB_SRCDIR/build-aux/announce-gen --release-type stable \
>--package-name libunistring --previous-version 0.9.10 \
>--current-version 1.0 --gpg-key-id F5BE8B267C6A406D
Reuben Thomas writes:
> Just noticed that it says: "Running without arguments will suffice in most
> cases." However, there is a mandatory argument!
Thank you! I pushed this fix.
/Simon
From be1b6d4bfaf1ad73780f30d6cd12cae3633b816a Mon Sep 17 00:00:00 2001
From: Simon Josefss
1 - 100 of 1783 matches
Mail list logo
