| 28 Sep 2021 |
 jochensp | yes | 18:49:45 |
| jochensp | because mutt was not maintained and neomutt had all the new stuff | 18:50:02 |
 εΉΈη« (πππΎπ/πππΎπ) | In reply to @_oftc_jochensp:matrix.org
and normally we see something as non free if the license is only for a specific group (like F-Droid) and I would argue that we should not accept such apps "the license" is doing a lot of work in that sentence. we're not allowed to use the firefox logo and name for fennec in f-droid (though debian can -- now, before it had to be "iceweasel" -- for the desktop version, and that's a trademark issue, not sure if the logo itself is free or not copyright-wise). if the only non-free thing is the fact that you can't use the official logo (and name, though again, trademark, not copyright) for custom builds, I don't see a problem with that (though I'd consider NonFreeAssets appropriate if the logo is indeed non-free copyright-wise). | 18:54:23 |
| jochensp | εΉΈη« (πππΎπ/πππΎπ): honestly I'm not sure how the deal with Firefox in Debian is. Afair it is maintained by Mozilla people | 19:01:12 |
| εΉΈη« (πππΎπ/πππΎπ) | iirc debian got permission to use the trademark since debian was considered "trusted" (or something similar, can't remember the exact wording). I'm not aware of Mozilla people maintaining it, or how that's relevant. | 19:04:07 |
| jochensp | εΉΈη« (πππΎπ/πππΎπ): details are here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006 | 22:08:36 |
| εΉΈη« (πππΎπ/πππΎπ) | jochensp: thx. I already had that page bookmarked I see. didn't remember the bit about the maintainer being a Mozilla employee. still, I think "More generally, Mozilla trusts the Debian packagers to use their best judgment to achieve the same quality as the official Firefox binaries." is the important bit here. | 22:12:58 |
| jochensp | sure | 22:19:40 |
| 29 Sep 2021 |
 proletarius101 | In reply to @eighthave:matrix.org
in my experience, apt-get install and gradle download and install faster than loading the docker images, so it was faster to leave all that stuff out of the docker image. Did you have something else in mind? Actually not. Let alone apt-get needs to extract and configure things | 01:40:51 |
| proletarius101 | All their services are in gcp us | 01:46:05 |
| proletarius101 | In reply to @eighthave:matrix.org
I think the best path to simply that is to make the docker images use the same provisioning setup as the buildserver VMs Yes they should. But running the provisioning script ahead is simply changing the timing of the snapshot. No effects on the provisioning steps | 01:53:10 |
| proletarius101 | BTW I also think the common apt-get steps should be baked into the build server VM image and rebuild it when the upstream changes | 01:54:14 |
| proletarius101 | * Yes they should. But running the provisioning script ahead is simply changing the timing of the snapshot. No effects on the order/scripts provisioning steps | 01:55:21 |
| proletarius101 | * Yes they should. But running the provisioning script ahead is simply changing the timing of the snapshot. No effects on the order/scripts of the provisioning steps | 01:55:28 |
 _hc | In reply to @obfusk:matrix.org
I did add NonFreeAssets to wire b/c of "No license is granted to the Wire trademark and its associated logos, all of which will continue to be owned exclusively by Wire Swiss GmbH. Any use of the Wire trademark and/or its associated logos is expressly prohibited without the express prior written consent of Wire Swiss GmbH." NonFreeAssets and free software is about copyright, not trademarks. They are separate things. A trademarked graphic can be fully freely licensed, that doesn't change trademark enforcement. | 08:01:10 |
| _hc | In reply to @proletarius101:matrix.org
Actually not. Let alone apt-get needs to extract and configure things actually yes, this is based on actual real world measurements on our exising infra. | 08:06:45 |
| _hc | based on that, I put quite a bit of effort to shrink the docker images sizes because it was taking 10+ minutes just to load the docker image | 08:07:29 |
| proletarius101 | do we have any special reason not to shallow clone app code? I see we clone the whole history of apps in fdroid build: https://gitlab.com/fdroid/fdroidserver/-/blob/master/fdroidserver/common.py#L1141 | 14:25:05 |
| proletarius101 | some apps, e.g. telegram, have outstanding repo history size | 14:25:56 |
| proletarius101 | causing the ci to raise no disk space error. but little benefits i can see to clone the whole history | 14:28:01 |
| proletarius101 | * causing the ci to raise no disk space error. but little benefits i can see from cloning the whole history | 14:28:17 |
| _hc | proletarius101: yes, there are reasons. see commits that change GIT_DEPTH in .gitlab-ci.yml | 14:30:56 |
| _hc | ah you mean for the app's git repo? | 14:31:33 |
| proletarius101 | in which repo? | 14:31:37 |
| proletarius101 | yeah | 14:31:38 |
| _hc | currently the idea is that in production, the git clone is cached and updated | 14:32:23 |
| _hc | also checkupdates uses the history | 14:32:41 |
| proletarius101 | but maybe ~1000 commits is enough? | 14:33:03 |
| _hc | another reason to separate checkupdates from everything else | 14:33:05 |
| proletarius101 | also checkupdates checks tags | 14:33:24 |
