| 27 Apr 2021 |
 proletarius101 | In reply to @freenode_jochensp:matrix.org
..I was more thinking of the overall process, I don't see a reason for Docker files (nor docker) becoming a standard It's only the bundling standard, not the packaging standard | 12:37:28 |
 jochensp | proletarius101: if you have everything packaged properly, you don't need a building standard, it could be as minimal as mmdebstrap calling apt | 12:39:27 |
 _hc | jochensp: the idea here is to provide another way to use the buildserver instances that is much easier to manage for many devs | 12:46:57 |
| _hc | e.g. so people can build in something extremely close to the production setup | 12:47:29 |
| _hc | few people want to run stretch ;-) | 12:47:46 |
 Passiing | In reply to @eighthave:matrix.org
stencil: you mean in Weblate? Yup | 13:27:51 |
| jochensp | _hc: sure, I don't speak against containers for build environments, rather about having the steps to to it encoded in packages instead of Dockerfiles, see how sbuild is doing it | 14:00:55 |
| _hc | stencil: I don't know, but I do know that it would be great if we had translators who took charge of organizing things like glossaries in Weblate. | 14:18:52 |
| _hc | jochensp: in fdroid buildsserver's case, the steps are encoded in provisioning scripts, which can easily be run in a Dockerfile | 14:19:41 |
|  @freenode_kempe:matrix.org left the room. | 16:28:47 |
| @freenode_kempe:matrix.org joined the room. | 16:29:10 |
|  @freenode_foobar48:matrix.org left the room. | 19:31:17 |
| 28 Apr 2021 |
|  jochensp1 joined the room. | 01:07:47 |
| jochensp left the room. | 01:10:11 |
| jochensp joined the room. | 02:48:24 |
 @rdfg77:kde.org | Is https://f-droid.org/ down? | 04:16:59 |
 cdesai | I can ping it but it isn't loading. | 04:24:41 |
| cdesai | yep my CI job that downloads f-droid apps failed too, connection timed out | 04:26:44 |
| @rdfg77:kde.org | Port 80 works but 443 only responses the first tcping. | 04:28:22 |
| @rdfg77:kde.org | It works now. | 06:27:34 |
| proletarius101 | I remember there is a change in merging strategy. There is not a rebase button in merge requests | 07:27:25 |
| proletarius101 | Is that intentional? | 07:27:44 |
 @festplattenschnitzel:matrix.org | Which project? fdroiddata? | 07:42:09 |
| proletarius101 | In reply to @proletarius101:matrix.org
I remember there is a change in merging strategy. There is not a rebase button in merge requests Oh there are. But what is the strategy now? Not possible to just merge when the main branch changes? | 07:42:12 |
| proletarius101 | In reply to @festplattenschnitzel:matrix.org
Which project? fdroiddata? Yes | 07:42:14 |
| @festplattenschnitzel:matrix.org | In reply to @proletarius101:matrix.org
Oh there are. But what is the strategy now? Not possible to just merge when the main branch changes? AFAIK We do "Fast-forward merging" at the moment …
https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html | 07:44:50 |
| proletarius101 | Hmm, maybe squash all commits would make it work? Given that the file I change doesn't overlap with any main branch changes. I'm not that familiar with fast forward | 07:47:21 |
| cdesai | fast forward simply avoids creating merge commits to have a linear history | 07:49:01 |
| cdesai | so it will try to merge if that won't create a merge commit, otherwise it'll rebase. | 07:49:19 |
| cdesai | https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html | 07:49:33 |
