<div dir="ltr"><div dir="ltr">On Wed, Jul 31, 2024 at 7:24 PM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mittwoch, 31. Juli 2024 00:05:55 CEST Albert Astals Cid wrote:<br>
> neochat - 2nd week<br>
> * <a href="https://invent.kde.org/network/neochat/-/pipelines/744320" rel="noreferrer" target="_blank">https://invent.kde.org/network/neochat/-/pipelines/744320</a><br>
> * flatpak packaging fails<br>
> * complains about signing?<br>
<br>
The verbose log in task-debug.log contains<br>
```<br>
2024-07-30 17:32:10,257 INFO flatpaksigner Running ['flatpak', 'build-import-<br>
bundle', '--update-appstream', '--gpg-<br>
sign=C78BF89D05C413A086459241700327D7B23406B3', '/tmp/tmpxyj846m1/neochat-<br>
nightly', 'unsigned.flatpak'] ...<br>
2024-07-30 17:32:11,686 ERROR flatpaksigner The process exited with 1<br>
2024-07-30 17:32:11,687 DEBUG flatpaksigner stdout:<br>
b'Importing app/org.kde.neochat/x86_64/master <br>
(27153ab08ced81594894c186cbf4ba62d90b979b708a19b78a210b3dbb818f3d)\n'<br>
2024-07-30 17:32:11,687 DEBUG flatpaksigner stderr:<br>
b"\n(flatpak build-import-bundle:667729): GLib-CRITICAL **: 17:32:10.687: <br>
g_str_has_prefix: assertion 'str != NULL' failed\n\n(flatpak build-import-<br>
bundle:667729): OSTree-CRITICAL **: 17:32:10.687: _ostree_repo_get_remote: <br>
assertion 'name != NULL' failed\n\n(flatpak build-import-bundle:667729): GLib-<br>
CRITICAL **: 17:32:10.687: g_propagate_error: assertion 'src != NULL' <br>
failed\nerror: Executing delta part 0: opcode open-splice-and-close: Writing <br>
content object: min-free-space-percent '3%' would be exceeded, at least <br>
77.8\xc2\xa0kB requested\n"<br>
2024-07-30 17:32:13,130 ERROR flatpaksigner Error: Processing task <br>
'20240730T172831-network-neochat_2014953' failed with Error('Running flatpak <br>
failed'). Giving up.<br>
```<br>
<br>
It looks like it's a disk space problem.<br>
<br>
On the signer I see<br>
```<br>
$ df -h<br>
Filesystem Size Used Avail Use% Mounted on<br>
/dev/vda2 49G 35G 12G 75% /<br>
```<br>
i.e. there are 12 GiB (~ 25 %) disk space free. While signing a Flatpak repo <br>
the repo is temporarily copied from <a href="http://cdn.kde.org" rel="noreferrer" target="_blank">cdn.kde.org</a> to the signer. My guess is <br>
that the NeoChat Flatpak repo is close to 12 GiB so that less than 3 % of <br>
space is left which seems to be the cause of the above error.<br>
<br>
I'm not sure how best to proceed. Throw more disk space at the problem? Reduce <br>
the size of the NeoChat Flatpak repo (and of all other Flatpak repos)? Start a <br>
new NeoChat Flatpak repo from scratch?<br></blockquote><div><br></div><div>I've done a couple of things now which both immediately resolve the issue as well as move us towards a longer term solution.</div><div><br></div><div>First: overall disk space utilisation on the signer is due to MacOS and Android keeping excessive logs. I have now purged those, not sure why we had 15GB+ of dated log files between the two of them.</div><div>That has brought us up to much more reasonable free space levels:</div><div><br></div><div>Filesystem Size Used Avail Use% Mounted on<br>/dev/vda2 49G 24G 24G 51% /<br></div><div><br></div><div>The second step is enabling pruning of our Flatpak repositories, where only a certain number of builds are kept - i've hardcoded this at 10 but we could look at tweaking that or making it configurable through the project level configuration perhaps.</div><div>See <a href="https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/69">https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/69</a> for that change.</div><div><br></div><div>That is something we had on the Binary Factory - although it had to be set much more aggressively there due to the sheer number of builds and the space that the full size Flatpak repository demanded.</div><div>It is probably worth checking with a Flatpak expert regarding whether the parameters i've suggested are technically correct to ensure they won't cause other issues (excessive repacking of Git repositories can actually make them larger for instance)</div><div><br></div><div>In terms of the largest Flatpak repositories we currently have, it looks like Neochat was the first to get >10GB although others aren't far behind:</div><div><br></div><div>root@tinami ~ # du -h --max-depth=1 /srv/www/<a href="http://cdn.kde.org/flatpak/">cdn.kde.org/flatpak/</a> | grep G<br>12G /srv/www/<a href="http://cdn.kde.org/flatpak/neochat-nightly">cdn.kde.org/flatpak/neochat-nightly</a><br>7.4G /srv/www/<a href="http://cdn.kde.org/flatpak/gcompris-nightly">cdn.kde.org/flatpak/gcompris-nightly</a><br>1.4G /srv/www/<a href="http://cdn.kde.org/flatpak/rkward-nightly">cdn.kde.org/flatpak/rkward-nightly</a><br>1.3G /srv/www/<a href="http://cdn.kde.org/flatpak/labplot-nightly">cdn.kde.org/flatpak/labplot-nightly</a><br>1.8G /srv/www/<a href="http://cdn.kde.org/flatpak/umbrello-nightly">cdn.kde.org/flatpak/umbrello-nightly</a><br>1.8G /srv/www/<a href="http://cdn.kde.org/flatpak/kde-runtime-nightly">cdn.kde.org/flatpak/kde-runtime-nightly</a><br>3.9G /srv/www/<a href="http://cdn.kde.org/flatpak/kdenlive-nightly">cdn.kde.org/flatpak/kdenlive-nightly</a><br>1.4G /srv/www/<a href="http://cdn.kde.org/flatpak/kleopatra-nightly">cdn.kde.org/flatpak/kleopatra-nightly</a><br>1.1G /srv/www/<a href="http://cdn.kde.org/flatpak/kate-nightly">cdn.kde.org/flatpak/kate-nightly</a><br>1.9G /srv/www/<a href="http://cdn.kde.org/flatpak/itinerary-nightly">cdn.kde.org/flatpak/itinerary-nightly</a><br>1.6G /srv/www/<a href="http://cdn.kde.org/flatpak/ruqola-nightly">cdn.kde.org/flatpak/ruqola-nightly</a><br>48G /srv/www/<a href="http://cdn.kde.org/flatpak/">cdn.kde.org/flatpak/</a><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Ingo</blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>