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
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
>>
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.
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
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
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
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
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?
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
>
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
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
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
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
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
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,
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
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:
> 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
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
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
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
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,
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
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:
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:
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 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
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
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:
> >
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
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:
> 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.
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
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:
> 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
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
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
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,
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.
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
>>
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:
> 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
>>
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
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
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
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
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,
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
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
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
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
>
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
(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
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
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
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:
> 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,
>
> 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:
> 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
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
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
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
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
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
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
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
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]
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
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
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
>>>
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;
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
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:
> 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.
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
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
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)
The content of upstream source code releases can largely be categorized
into 1) the actual native
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
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
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
101 - 192 of 192 matches
Mail list logo
