| 2 Apr 2021 |
 jochensp | there is mono.. | 08:06:44 |
 Hans-Christoph Steiner | yeah, I think C# can be totally free sofware. There have been C# apps in Debian for years | 08:10:45 |
| Hans-Christoph Steiner | I don't know about building C# apps for Android though, there could be required proprietary bits | 08:11:10 |
| Hans-Christoph Steiner | proletarius101: did you figure out the issue with sudo fdroid failing? | 08:19:49 |
| Hans-Christoph Steiner | izzy: about reducing the size of fdroiddata, what we can do now is slow down its growth. For example, we could switch the merge mode to be squash and turn off merge commits. | 09:22:28 |
| Hans-Christoph Steiner | merge commits are pretty small though | 09:22:56 |
 cde | What doesn't help is just the sheer number of files present | 09:23:50 |
| cde | Perhaps if we can come up with a better way to organise them we could have a new repo and keep the existing repo as an archive | 09:24:14 |
| cde | org.fdroid.fdroid could go under org/fd or something like that, I remember linking some article about this a while ago | 09:25:06 |
| jochensp | maybe we could differentiate between static metadata and build dependent things. A lot of apps basically only have some static entries and fdroidserver could just build the latest git tag | 09:28:18 |
| jochensp | and we could have a second git for those apps that require more work (like varying build recipes) | 09:29:26 |
| jochensp | also I think app descriptions, translations.. should be an extra repo | 09:30:09 |
| Hans-Christoph Steiner | we're mostly pushing app descriptions and translations upstream these day | 09:35:29 |
| Hans-Christoph Steiner | we could try to start encouraging people to use .fdroid.yml, that doesn't work for Builds: though | 09:36:27 |
| Hans-Christoph Steiner | it would allow upstream to control all the links | 09:36:35 |
| Hans-Christoph Steiner | using sensible defaults might help a bit too, the files would be smaller. s!182 | 09:39:09 |
![@freenode_[gibot]:matrix.org](./avatar/%5Bgibot%5D) [gibot] | [server] !182: WIP: add sensible defaults to the build metadata - https://gitlab.com/fdroid/fdroidserver/merge_requests/182 | 09:39:12 |
 proletarius101 | In reply to @eighthave:matrix.org
proletarius101: did you figure out the issue with sudo fdroid failing? Not yet. Actually locally it works well😂 | 10:56:35 |
| proletarius101 | I mean locally in the container. But I haven't execute all commands line by line. So I suspect it's hidden in some scripts | 10:58:33 |
| Hans-Christoph Steiner | I added a proposed patch to the original issue https://gitlab.com/fdroid/fdroiddata/-/issues/2344#note_543707869 | 11:02:39 |
| Hans-Christoph Steiner | proletarius101: ^ | 11:02:52 |
| Hans-Christoph Steiner | proletarius101: seems like lots of that fdroid build job should really be put into a docker image that is built with the buildserver provisioning scripts | 11:05:30 |
| Hans-Christoph Steiner | that would then also could be used for verification.f-droid.org | 11:06:23 |
| proletarius101 | In reply to @eighthave:matrix.org
proletarius101: seems like lots of that fdroid build job should really be put into a docker image that is built with the buildserver provisioning scripts That would be nice. Less redundant work | 11:07:03 |
| proletarius101 | But I don't really understand how😂 | 11:07:28 |
| proletarius101 | You mean like what we do in the real build server? | 11:07:53 |
| Hans-Christoph Steiner | vagrant up --provider docker | 11:07:56 |
| Hans-Christoph Steiner | https://www.vagrantup.com/docs/provisioning/docker | 11:08:46 |
| proletarius101 | I know that, but how could this be used in the ci | 11:09:37 |
| proletarius101 | I guess it should rather be docker in docker? But is it really different from what we have for now | 11:10:11 |
