| 28 Sep 2021 |
 jochensp | in metadata. | 07:52:16 |
 linsui | I thought we can add a new entry. E.g. flutter: stable/2.5.1 and let the bot update it. | 08:03:40 |
| linsui | Since we have an increasing number of flutter apps we should support it as gradle.
Maybe
flutter: | 08:08:00 |
| linsui | Redacted or Malformed Event | 08:08:12 |
| jochensp | linsui: there is https://gitlab.com/fdroid/fdroidserver/-/issues/554#note_518360180 | 08:09:24 |
| linsui | Yes, I know. But we need to require upstream to add that. | 08:10:25 |
| jochensp | linsui: what exactly would we need from upstream? | 08:11:43 |
| linsui | sdks:
dart: ">=2.10.0 <2.11.0"
flutter: ">=1.22.0 <2.0.0"
| 08:13:09 |
| linsui | E.g. Sharik is using 2.5.0 but in the pubspec.yml there is only flutter: ">=2.0.0" | 08:16:15 |
| linsui | It's not very useful. | 08:16:22 |
| linsui | I would like to have something like
flutter:
stable: 2.5.1
flavor: fdroid
in the metadata and fdroidserver do the
- $$flutter$$/bin/flutter config --no-analytics
- $$flutter$$/bin/flutter build apk
part automatic. The output path should be calculated, too.
| 08:18:50 |
| jochensp | linsui: for Sharik I would assume that 2.0 just works, or not? | 08:41:13 |
| linsui | https://github.com/marchellodev/sharik/issues/115
Generally flutter has very bad backward compatibility. | 08:45:24 |
| linsui | Or forward compatibility? | 08:46:57 |
 _hc | I'm partial to adding support for Builds: entry to srclibs https://gitlab.com/fdroid/fdroidserver/-/issues/886 | 10:45:57 |
| _hc | then we have shared build script, and a place were someone could also figure out caching of build products as needed | 10:46:47 |
| linsui | We can just use the Prepare. What's the difference? | 10:47:35 |
| _hc | I didn't think Prepare did much | 10:47:55 |
| _hc | the idea would be to have pre-release scripts | 10:48:04 |
| _hc | Prepare seems to be global, one entry for all releases of the srclibs | 10:49:41 |
| _hc | oops per-release | 12:44:55 |
 εΉΈη« (πππΎπ/πππΎπ) | In reply to @_oftc_zx2c4:matrix.org
linsui: another thing... any idea why the webpage doesnt show wg's app logo? as mentioned, failing icon extraction is a known issue. for upstreams, adding an icon png to the repo's triple-t/fastlane metadata sidesteps the issue, providing an easy fix :) | 12:47:43 |
| _hc | and also, gives them control over the icon, and the ability to provide a full 512x512 version of it | 12:50:37 |
 proletarius101 | Sorry I forgot how the discussion about this went to, but i think making docker images (variants) for each fdroiddata job is quite helpful for building speed of MRs. And it will still provide the same environment as what we have now. e.g. for the fdroid build job, at least https://gitlab.com/fdroid/fdroiddata/blob/master/.gitlab-ci.yml#L218-269 can be done in the Dockerfile | 12:53:18 |
| proletarius101 | the docker image rebuild can be triggered by webhooks of the fdroidserver repo, etc | 12:54:00 |
| _hc | 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? | 14:42:55 |
| _hc | that's on gitlab.com at least. If we move more towards our own runners, then it makes sense to move stuff into the docker image because we can make each runner store keep our images in the local cache | 14:43:38 |
| _hc | it is also easier to maintain when that stuff is not in the docker image | 14:43:59 |
| _hc | I think the best path to simply that is to make the docker images use the same provisioning setup as the buildserver VMs | 14:44:51 |
| linsui | Does anyone know what happened on trebleshot? The author said that the development will stop but published some versions after then. Now the repo disappered. | 14:55:14 |
