Hi, Ludovic Courtès <l...@gnu.org> skribis:
> This is what I get for the last one: > > sqlite> select * from validpaths where path = > '/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5'; > 48732920|/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5|sha256:86426115e1f49835a24612ae89a180e87ac835332b4e83d19ecbd43211336cd2|1623360391|/gnu/store/722yyaa1qvkaakn6p7ywwr4dnm5wmddz-flightgear-2018.3.5.drv|-1610199336 > > > The registration date is: > > scheme@(guile-user)> ,use(srfi srfi-19) > scheme@(guile-user)> (date->string (time-utc->date (make-time time-utc 0 > 1623360391)) "~1" ) > $164 = "2021-06-10" > >> I think there were safeguards put in place to avoid bad data making it's >> way in to the store database? > > I thought so too (commit 13a7d2a538b00aa0a8cf9b999f1a4ff3e5959af9)! > So we must be using another code path. At last I found the culprit (me! :-)). This is fixed by commit f9b1bb916c284bea00dd5549a43e0894b219d650. The reason ci.guix would experience it and not bayfront is because the Cuirass worker mechanism relies on substitutes to retrieve files from a worker, and this is how it would end up storing a negative size. We’ll have to upgrade the ‘guix’ package and deploy it on berlin. I don’t think it’s easily feasible to fix existing entries in the store database and (more importantly) narinfos so I’d just leave them around; the bogus nar size propagates but it’s harmless and doesn’t prevent substitution. Thoughts? Ludo’.