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 <chris...@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 <jbg...@lug-owl.de >> <mailto:jbg...@lug-owl.de>> wrote: >> >> On Mon, 2024-02-26 16:24:19 +0100, Jan-Benedict Glaw <jbg...@lug-owl.de >> <mailto: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 >> >> -- >> _______________________________________________ >> Reproducible-builds mailing list >> Reproducible-builds@alioth-lists.debian.net >> <mailto:Reproducible-builds@alioth-lists.debian.net> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
