All,
Our release announcements does not mention the git commit hash that was
used to prepare the release. While SHA1 is broken, I still think
including the commit hash provide some additional information that may
be useful further down the line, and hopefully including doesn't incur
too much
On running 'make release' I got this error message:
GEN release-prep
fatal: No names found, cannot describe anything.
make[1]: Entering directory '/home/jas/src/inetutils'
The error message is harmless since the code already handled this
situation, but the error message should be silenced
Bruno Haible writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packages [1],
> * 'cargo fetch' for Rust
Bruno Haible writes:
> Simon Josefsson wrote:
>> I've found it to only be cost
>> effective to setup my own runners for platforms that gitlab doesn't
>> support natively, such as arm64 or ppc64el.
>
> For GitHub runners, hosting your own runners comes with security risks [1].
>
> Do GitLab
All, (going out to both debian-devel and bug-gnulib, please be
respectful of each community's different perspectives and trim Cc
when focus shifts to any Debian or gnulib specific topics)
(please pardon the accidental duplicate post to bug-gnulib...)
The content of upstream
All, (going out to both debian-devel and bug-gnulib, please be
respectful of each community's different perspectives and trim Cc
when focus shifts to any Debian or gnulib specific topics)
The content of upstream source code releases can largely be categorized
into 1) the actual native
Bruno Haible writes:
> + int alarm_value = 50;
>signal (SIGALRM, SIG_DFL);
> - alarm (10);
> + alarm (alarm_value);
Nice trick, but doesn't the compiler optimize away this? Maybe a
'volatile' is needed.
/Simon
signature.asc
Description: PGP signature
Bruno Haible writes:
> Simon Josefsson wrote:
>> I forgot to mention: the pattern to provide re-usable GitLab CI/CD
>> definitions that I'm inspired by is Debian's pipeline project:
>>
>> https://salsa.debian.org/salsa-ci-team/pipeline/
>>
>> It is easy to setup a new project to use their
Bruno Haible writes:
>> I think the pattern of having the .gitlab-ci.yml outside of the core
>> Savannah project is a good one for those GNU projects who are not
>> embracing the GitLab platform. Then GitLab-related stuff stays on the
>> GitLab platform and doesn't invade the core project.
>
>
I forgot to mention: the pattern to provide re-usable GitLab CI/CD
definitions that I'm inspired by is Debian's pipeline project:
https://salsa.debian.org/salsa-ci-team/pipeline/
It is easy to setup a new project to use their reusable pipeline -- just
add the CI/CD configuration file setting
Bruno Haible writes:
> gnulib-tool is used is many CI jobs. Just adding 'python3' to the
> prerequisites of such a job makes it run faster. Here are the execution
> times for a single run, before and after adding 'python3', for those
> CIs that I maintain or co-maintain. In minutes and seconds.
Thanks for +1 Bruno, I have pushed the commits below. More history or
insight on how to think about use of these types would be great. My
recollection was that these types were preferred for compatibility with
ancient C tools that didn't parse 'unsigned char' etc.
/Simon
From
How about adding inetutils u_* syntax-checks to gnulib's maint.mk?
sc_unsigned_char:
@prohibit=u''_char \
halt='don'\''t use u''_char; instead use unsigned char' \
$(_sc_search_regexp)
sc_unsigned_long:
@prohibit=u''_long \
halt='don'\''t use u''_long;
Collin Funk writes:
> Hi Simon,
>
> On 5/2/24 11:25 AM, Simon Josefsson via Bug reports for the GNU Internet
> utilities wrote:
>>> Sadly, I cannot do this, at least not easily. After installing GNU
>>> indent, "make syntax-check" complains about many files:
>>>
>>> $ indent --version
>>>
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
Bruno Haible writes:
> I don't agree with this patch. It misrepresents the dates on which people
> have checked in their commits.
Paul Eggert writes:
> Emacs has had the tradition of using UTC for ChangeLog dates, so
> please support that as well, as an option. This Emacs tradition dates
>
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
Hi
I ran into a reproducability problem in gitlog-to-changelog, and noticed
Guix people had also ran into this and worked around it outside of
gitlog-to-changelog:
https://issues.guix.gnu.org/70169/#21
However I don't think it makes sense for ChangeLog dates to depend on
the timezone under any
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
> file output and stdout
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 time and 95% of the time I use
>>
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
>>
Another attempt below, with known open issues:
1) it seems something has to be said about tz variables, either the
function "always sets" them, "never sets" them, or (in new text below)
"may set" them depending on what other functions are called. Not
optimal, but better than not documenting it.
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,
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
> > warn that this function should
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
Hi,
I noticed http:// links were used here... patch below is pushed.
Happy new year,
/Simon
* build-aux/announce-gen: Use https:// URLs.
---
ChangeLog | 5 +
build-aux/announce-gen | 6 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/ChangeLog
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:
>
> Lowercase:
> as, cp, bash,
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__) &&
Hi. I think announce-gen should use the username provided by the
per-repo .git/config rather than the global ~/.gitconfig.
I hit this corner on build farms where I don't want to modify files
outside of the repository.
/Simon
From 6928b3b86169bf5d265f745ff5f93eb21181a59e Mon Sep 17 00:00:00 2001
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:
> >
> > sc_libtool_version_bump:
> >
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
Hi. We got a bug report about a build failure (see below), and I'm
wondering:
1) Does gnulib support building with gcc -std=c99? I think we should,
but it could have documented missing functionality or breakage.
2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for
GCC, which
Hi. I had a background job doing 'make check' in a project that
triggered a GnuPG private key operation PIN prompt... this was
surprising to me, and the attached fix should avoid that happening. If
my PIN had been cached, this would have signed a commit behind my back
(although this would have
Bruno Haible writes:
> Hi Simon,
>
>> +@if ! indent --version 2> /dev/null | grep -q 'GNU indent'; then\
>
> As mentioned in the Autoconf manual [1], the grep option '-q' is not portable.
> E.g. on Solaris 10:
>
> $ echo | grep -q x
> grep: illegal option -- q
> Usage: grep -hblcnsviw
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:
Hi.
I noticed that the generated InetUtils manual had a locale problem in
the timestamp:
https://www.gnu.org/software/inetutils/manual/
The script gendocs.sh has:
: "${SETLANG="env LANG= LC_MESSAGES= LC_ALL= LANGUAGE="}"
...
curdate=`$SETLANG date '+%B %d, %Y'`
The reason seems to be LC_TIME
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 stdbool.h. ...
>>
>> Does C23 disallow this?
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
Paul Eggert writes:
> On 9/22/22 11:20, Bjarni Ingi Gislason wrote:
>
>> CC='clang -Wsign-compare' ./gnulib-tool --test malloca 2>
>
> Oh, please don't use -Wsign-compare. Clang generates too many false
> alarms with -Wsign-compare, we don't recommend that warning, and
> Gnulib-using programs
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 by
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 when it doesn't work? tests/parser.sh in
> > libtasn1
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
>
1 - 100 of 192 matches
Mail list logo