On 11/05/2023 15:31, Bruno Haible wrote:
Pádraig Brady wrote:
@Padraig: you're at least doing some pre-release tests on several platforms,
but that's no real CI, is it?
Right.
No real CI at present.
It would be good though, directly for coreutils
and indirectly for gnulib.
We have a CI for g
Pádraig Brady wrote:
> > @Padraig: you're at least doing some pre-release tests on several platforms,
> > but that's no real CI, is it?
>
> Right.
> No real CI at present.
> It would be good though, directly for coreutils
> and indirectly for gnulib.
We have a CI for gnulib at Gitlab [1], but it
On 11/05/2023 07:58, Bernhard Voelker wrote:
On 5/9/23 20:57, Bruno Haible wrote:
Bernhard Voelker wrote:
I noticed the issue because the following "very-expensive" tests failed
(which succeeded with coreutils-9.3):
FAIL: tests/rm/ext3-perf
FAIL: tests/rm/many-dir-entries-vs-OOM
Di
On 5/9/23 20:57, Bruno Haible wrote:
Bernhard Voelker wrote:
I noticed the issue because the following "very-expensive" tests failed
(which succeeded with coreutils-9.3):
FAIL: tests/rm/ext3-perf
FAIL: tests/rm/many-dir-entries-vs-OOM
Did you notice these failures by chance, or do you
Bernhard Voelker wrote:
> Gnulib commit 3f0950f65abb (2023-04-26) not only lead to build time
> issues, but also made e.g. coreutils' rm(1) fail:
> ...
> I can confirm that this gnulib commit d4d8abb39eb0 fixes the issue again.
Yep, mistakes do happen. Gnulib has stable branches that can protect s
