no such metadata / no such ref errors on the command line

[Alexander Larsson]

I wonder if you just didn't update appdata in a long time and the
remote side garbage collected that commit (we don't keep infinite
history). If that is the case then this is sort of bad, because we
should not fail to update in this situation...

On Sat, Apr 7, 2018 at 3:40 PM, Michael Gratton <mike at vee.net> wrote:
> On Sat, Apr 7, 2018 at 12:39 AM, Dan Nicholson <nicholson at endlessm.com>
> wrote:
>>
>> Endless (mostly self-inflicted because we
>> decided to share an ostree repo between flatpak and ostree). I wrote a
>> nasty script to find missing objects, mark commits as partial (so
>> ostree pull descends the whole commit), and then pulls them after
>> figuring out what ref/remote they point to.
>>
>>
>> https://github.com/endlessm/eos-meta/blob/master/eos-tech-support/eos-fix-ostree-repo
>>
>> I think it would work if you pass it --repo=/var/liib/flatpak/repo,
>> but I've only ever tested it on Endless.
>
>
> Thanks for the suggestion - I tried running it, but error'ed out running it
> twice:
>
>> mjg at payens:~$ sudo ~/eos-fix-ostree-repo --repo=/var/iib/flatpak/repo
>> WARNING: Do not start App Center while this is running
>> Traceback (most recent call last):
>> Receiving metadata objects: 1/(estimating) -/s 0 bytes
>> Traceback (most recent call last):
>>   File "/home/mjg/Incoming/eos-fix-ostree-repo", line 223, in
>> fix_dangling_refs
>>     repo.load_commit(checksum)
>> GLib.Error: g-io-error-quark: No such metadata object
>> 3f97e8db7dffa626bd19b4a763b6a371698c58054877215c00bf1b1d4d00db50.commit (1)
>> mjg at payens:~$ sudo ~/eos-fix-ostree-repo --repo=/var/lib/flatpak/repo
>> During handling of the above exception, another exception occurred:
>> Killing processes with /var/lib/flatpak/repo open with signal
>> Signals.SIGTERM
>> Traceback (most recent call last):ftware with signal Signals.SIGTERM
>>   File "/home/mjg/Incoming/eos-fix-ostree-repo", line 403, in
>> <module>SIGKILL
>>     main()s pointing to missing commits in /var/lib/flatpak/repo
>>   File "/home/mjg/Incoming/eos-fix-ostree-repo", line 390, in main00db50
>> commit metadata f    fix_dangling_refs(repo)appstream/x86_64
>>   File "/home/mjg/Incoming/eos-fix-ostree-repo", line 238, in
>> fix_dangling_refs
>>     pull_commit(repo, remote, checksum)
>>   File "/home/mjg/Incoming/eos-fix-ostree-repo", line 208, in pull_commit
>>     repo.pull_with_options(remote, opts, progress)
>> GLib.Error: g-io-error-quark: Server returned status 404: Not Found (1)
>
>
> (Does it even use the --repo arg? I ran it twice due to the typo in the path
> the first time, but it looks like it was doing something)
>
> Anyway, your discussion of the manual process then lead me to try simply
> pulling the bad ref (gnome-apps-nightly:appstream/x86_64), which was updated
> to point to a different commit and now both flatpak update and search have
> stopped complaining about the missing commit.
>
> So, cheers!
>
> //Mike
>
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ <http://mjog.vee.net/>
>
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com