| 29 Sep 2022 |
 _hc | all of fdroid used to be in one repository, including website, data, and client. | 13:32:33 |
| _hc | we should go Google BigTable style! we could switch from Git to the Android repo tool | 13:33:41 |
| _hc | 😉 | 13:33:56 |
 FestplattenSchnitzel | In reply to @_oftc_jochensp:matrix.org
also I think two repos are harder to discover then one If you have contributed at e.g. Exodus and want to submit a single signature at fdroid-sus, you probably don't want to dig into F-Droid Data / one of it's subdirectories. | 13:34:30 |
 uniq | I like modularization. | 13:35:03 |
 jochensp | that's a lot of ifs.. | 13:35:03 |
| jochensp | anyway, we can still move stuff later (like we just did with the AFs and categories ;) ) | 13:35:19 |
| uniq | an loose coupling | 13:35:24 |
 linsui | In reply to @festplattenschnitzel:matrix.org
If you have contributed at e.g. Exodus and want to submit a single signature at fdroid-sus, you probably don't want to dig into F-Droid Data / one of it's subdirectories. But they can just open an MR. | 13:35:54 |
| FestplattenSchnitzel | In reply to @_oftc_jochensp:matrix.org
that's a lot of ifs.. I'd like to make it as easy as possible to contribute stuff from the beginning. | 13:36:34 |
| jochensp | FestplattenSchnitzel: I think then it is actually easier to have it in one repo | 13:37:01 |
| FestplattenSchnitzel | In reply to @rdfg77:kde.org
But they can just open an MR. Right, currently F-Droid Data people are the ones that deal with signatures the most, so +1 for CON. | 13:37:30 |
| FestplattenSchnitzel | Also kinda CON: it should be easy to rip out stuff after if needed. | 13:38:53 |
| jochensp | and when fixing a scanner signature (for example if it blocks a new app) it should be clear when it is active | 13:39:40 |
![@_oftc_Licaon_Kter[xmpp]:matrix.org](./avatar/Licaon_Kter%5Bxmpp%5D) Licaon_Kter[xmpp] | jochensp: for fdroidserver users it's "yet another repo" | 13:43:26 |
| _hc | the scanner rulies are already separate from fdroiddata and this fdroid/suss setup is already implemented, so in the interest of getting things done, I think michael should move forward with fdroid/suss for now. Then we can always change things in the future as needed. | 13:44:28 |
| _hc | it seems pretty easy to incrementally add support for scanner rules in fdroiddata as needed | 13:45:00 |
| jochensp | Licaon_Kter[xmpp]: I think fdroidserver should be agnostic to data | 13:47:38 |
| jochensp | (dito for client and website) | 13:48:03 |
| uniq | In reply to @_oftc_jochensp:matrix.org
Licaon_Kter[xmpp]: I think fdroidserver should be agnostic to data And I think fdroidserver should just work | 14:01:39 |
| uniq | If want to test building one of my apps with the latest version of fdroid buildserver in my own custom repository I except the same behavior as if I were building it in the context of fdroiddata | 14:02:43 |
| jochensp | for building yes, for a scan to flag unwanted code no | 14:03:49 |
| uniq | afiak fdroid build --buildserver runs scan_binary and will fail if the scan fails | 14:05:14 |
| jochensp | afaik it does not | 14:05:49 |
| jochensp | fdroid build --scan-binary does | 14:06:10 |
| jochensp | but we don't run that on the official server | 14:06:18 |
| linsui | In reply to @uniq:matrix.org
If want to test building one of my apps with the latest version of fdroid buildserver in my own custom repository I except the same behavior as if I were building it in the context of fdroiddata Do you mean that it should work without the whole fdroiddata repo but only a single recipe? | 14:07:16 |
| uniq | https://gitlab.com/fdroid/fdroidserver/-/blob/244273e58e4da131969fcfc6548eb8e3abc05925/fdroidserver/build.py#L238 | 14:07:28 |
| jochensp | scan_binary is false by default | 14:07:56 |
| jochensp | https://gitlab.com/fdroid/fdroidserver/-/blob/244273e58e4da131969fcfc6548eb8e3abc05925/fdroidserver/common.py#L129 | 14:08:50 |
