12 Aug 2021 |
εΉΈη« (πππΎπ/πππΎπ) | Izzy: I think the repo priority issue is probably something that rarely happens, and if it does, probably because a developer with their own repo or repo maintainer has stopped updating an app. | 22:14:34 |
εΉΈη« (πππΎπ/πππΎπ) | having the repo maintainer remove the app completely if it's no longer updated would fix it for most users I think and probably be the best solution. | 22:15:43 |
εΉΈη« (πππΎπ/πππΎπ) | not that I would not like to be able to specify priorities. | 22:15:57 |
εΉΈη« (πππΎπ/πππΎπ) | (being able to blocklist an app from a repo if you do want other apps from it would also help, but then you'd have to be aware that you need to do that.) | 22:16:32 |
Izzy | Not only that, εΉΈη« (πππΎπ/πππΎπ) β I've experienced several different circumstances where this happens. Think e.g. of apps "overriding" pre-installed GApps, like microG and GCamProvider using the very same packageName as GMS (that made me remove GCamProvider from my repo as I was no longer able to update microG at all). And in the linked issue, it have been the testing versions which were no longer updated (temporarily) but still be shown "suggested | 22:18:14 |
Izzy | " despite of newer versions in our repo. | 22:18:14 |
εΉΈη« (πππΎπ/πππΎπ) | another option would be a per-app repo whitelist option. | 22:18:23 |
Izzy | There might be even more constellations we're not aware of. | 22:18:55 |
εΉΈη« (πππΎπ/πππΎπ) | Izzy: yes, the problem is probably not so much "no updates at all" as it is "currentversion not updated". | 22:20:22 |
Izzy | The problem is you won't even be aware there are updates. | 22:21:33 |
Izzy | Bad UX. | 22:21:43 |
εΉΈη« (πππΎπ/πππΎπ) | https://gitlab.com/fdroid/fdroidclient/-/merge_requests/435 "The UI looks good. But I'm concerned that the database layer is not yet stable enough to support this. I really would like to wait on adding this until all the rest of the things have settled. I can't think of any burning use case for this." | 22:23:03 |
εΉΈη« (πππΎπ/πππΎπ) | Izzy: true. another alternative might be to have a setting that shows you a message when there are newer currentversions in other repos. | 22:24:38 |
cde | the prioritisation needs to be smarter. | 22:24:42 |
εΉΈη« (πππΎπ/πππΎπ) | yes. but it's hard to come up with something that "always works". | 22:25:52 |
Izzy | yupp. Or user-definable (incl. "turn off"). One exception: incompatible signatures for installed apps. | 22:26:13 |
cde | yes, but getting it 90% of the way there would still be simpler than implementing something else. | 22:26:20 |
Izzy | Exactly. | 22:26:36 |
εΉΈη« (πππΎπ/πππΎπ) | for an analogy: apt pinning works pretty well for debian repos. but it's hardly user friendly. | 22:27:07 |
Izzy | Well, need to catch some sleep. Past nights were way to short⦠| 22:27:07 |
εΉΈη« (πππΎπ/πππΎπ) | https://gitlab.com/fdroid/fdroidclient/-/issues/2247 | 22:47:45 |
13 Aug 2021 |
proletarius101 | Dark theme color contrast treatment: https://gitlab.com/fdroid/fdroidclient/-/merge_requests/1046 | 05:43:23 |
_hc | In reply to @obfusk:matrix.org somewhat related: personally, I'd like to be able to allow/blocklist which apps a repo is allowed to provide. I could see that as an extra screen accessible from the Repo Details screen. The tricky part would implementing that in fdroidclient's database layer, its already quite complicated. I think it would be also useful if, when adding a new repo, there was an overview of which apps a repo has, and any conflicts with other repos, | 07:52:20 |
_hc | εΉΈη« (πππΎπ/πππΎπ): you are good at the bugs, that's a very valuable contribution. I generally try to tag bugs I think are worth putting time into, "help-wanted" is the best overview: https://gitlab.com/groups/fdroid/-/issues?scope=all&state=opened&label_name[]=help-wanted | 07:54:49 |
linsui | https://gitlab.com/fdroid/fdroiddata/-/merge_requests/9554#note_650337519 | 08:38:38 |
linsui | We still can't install build-tools;31.0.0 | 08:39:09 |
_hc | does it have a new license? | 09:11:55 |
linsui | I don't know. How can I check that? | 09:16:05 |
_hc | I responded in the MR | 09:35:36 |
Licaon_Kter[xmpp] | ``` | 14:10:23 |