NetBSD reproducible builds stuck?

[Christos Zoulas]

The sqlite3.c file is the largest c file in the build clocking at an amazing:

[11:49am] 409>wc sqlite3.c
  250850 1137278 8848252 sqlite3.c

250K LOC ?!?! It definitely would eat most space than anything else in the build in /tmp.
I think the choice is to enlarge /tmp or make the compiler use /var/tmp which is presumably larger (but slower since it is not tmpfs).
Perhaps what happened is that it was close enough to breaking and some change pushed it over the edge since the file has not
changed since last September.

christos

> On Feb 26, 2024, at 11:35 AM, Jan-Benedict Glaw <jbglaw at lug-owl.de> wrote:
> 
> On Mon, 2024-02-26 16:24:19 +0100, Jan-Benedict Glaw <jbglaw at lug-owl.de <mailto:jbglaw at lug-owl.de>> wrote:
>> On Mon, 2024-02-26 08:03:20 -0500, Christos Zoulas <christos at 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
> 
> -- 
> _______________________________________________
> Reproducible-builds mailing list
> Reproducible-builds at alioth-lists.debian.net <mailto:Reproducible-builds at alioth-lists.debian.net>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20240226/13c13500/attachment.htm>