On Mon, 2024-02-26 16:24:19 +0100, Jan-Benedict Glaw <jbg...@lug-owl.de> wrote:
> On Mon, 2024-02-26 08:03:20 -0500, Christos Zoulas <chris...@zoulas.com>
> wrote:
> > I don't understand what:
> >
> >
> > ++ find '*' -type f
> > find: ‘*’: No such file or directory
> >
> > is supposed to do... I don't think '*' could work...
>
>
> That must correspond to this part:
>
> 178 tree .
> 179 for i in *; do
> 180 pushd "${i}"
> 181 for j in $(find * -type f | sort -u ) ; do
> 182 let ALL_FILES+=1
>
> That `*` will only become a literal '*' with an empty directory, so I
> guess that's the actual issue. Hope to have an in-depth look at it
> tonight..
Just had a quick peek. It's building (each twice) sparc64 and amd64.
While sparc succeeds, the amd64 build breaks during `./build.sh [..]
release`:
[...]
compile lib/sqlite3.po
create lib/sqlite3.d
create lib/.depend
/srv/workspace/chroots/rbuild-netbsd-build-cdfDhQXt/b1-x86_64-amd64/external/public-domain/sqlite/lib/../dist/sqlite3.c:250849:1:
fatal error: error writing to /tmp/ccowLQ9J.s: No space left
on device
250849 | SQLITE_API const char *sqlite3_sourceid(void){ return
SQLITE_SOURCE_ID; }
| ^~~~~~~~~~
compilation terminated.
--- sqlite3.pico ---
*** Failed target: sqlite3.pico
*** Failed commands:
[...]
/tmp is tmpfs (so RAM-based). I'm not (yet?) sure what happens here.
Either the box has _so_ hefty memory pressure that it can no longer
create a few files, or maybe we (or something else) is building in
/tmp (and eating up all memory.) From a first glance, the script seems
to build in /src, so I actually guess that some other job is killing it.
@holger: Is there monitoring in place to see what's running while it's
failing to build due to /tmp (on tmpfs) being "full"?
MfG, JBG
--
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
