bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Ludovic Courtès <ludo@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.

Awesome :)

> 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?

I thought this did prevent substitution, at least I have problems:

→ guix build --substitute-urls=https://ci.guix.gnu.org /gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
guix build: error: integer expected from stream

Maybe the database could be queried to find the affected items, then
they could be GC'd?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]