NetBSD reproducible builds stuck?

[Christos Zoulas]

I am fairly confident that if we double the size of tmpfs it will work... Is that easy to do?

christos

> On Feb 26, 2024, at 11:52 AM, Christos Zoulas <christos at zoulas.com> wrote:
> 
> 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 <mailto: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/20240228/1bb58e0a/attachment.htm>