| 5 Jun 2020 |
 _hc | oops out of order | 19:13:20 |
| _hc | in any case, I have to sign off for the evening, good night all! | 19:13:43 |
 Bubu | In reply to @eighthave:matrix.org
that just gave me an idea: we should have a box that just constantly mirrors master on all our git repos as a monitor we have gibot, which actually that | 20:23:53 |
| Bubu | could be a more specialized tool for the job though | 20:24:29 |
| Bubu | The gcc runner has completed a full checkupdates run in I think 2.5 hours I think? | 20:26:00 |
| Bubu | that's decent | 20:26:05 |
| Bubu | just need to do something about the job canceling | 20:26:34 |
| Bubu | In reply to @eighthave:matrix.org
that just gave me an idea: we should have a box that just constantly mirrors master on all our git repos as a monitor * we have gibot, which actually does that (doesn't save the commits but would still alert that there was one) | 20:29:19 |
| Bubu | * could be a more specialized tool for the job though, sounds like a good idea | 20:29:29 |
 cdesai | it could be a simple script that just does 'git remote update' for all repos, and puts the log somewhere | 20:31:33 |
| Bubu | _hc: https://about.gitlab.com/blog/2016/04/05/shared-runners/
All your builds run on Digital Ocean 4GB instances, with CoreOS and the latest Docker Engine installed.
Your builds will always be run on fresh machines. This will effectively eliminate possible security issues, as there is no potential of breaking out of the container.
| 20:43:29 |
| Bubu | that's from 2016 and their infrastructure probably changed. I very much doubt they've changed anything on that point thouhg | 20:43:58 |
| Bubu | that point = every build runs in a fresh VM | 20:44:17 |
| Bubu | I'll find a place to open an issue with gitlab aksing for clarification on how the shared runner infrastructure is set up nowadays | 20:44:56 |
| Bubu | not today probably | 20:45:09 |
| 6 Jun 2020 |
| _hc | based on what I know about gitlab runners, I think they mean docker runs when they say "machines" | 07:39:47 |
| _hc | I don't think they are resetting the VM between each job | 07:40:23 |
| _hc | they might be doing an extra layer of docker where they have a docker contianer setup to run docker containers, and the docker runner container is reset each job | 07:41:06 |
| _hc | they could be doing snapshotting like fdroid build does, maybe they have a way to make that faster | 07:42:20 |
| _hc | also, the whole spectre class of bugs means achieving root-level memory reads from inside VMs and containers | 07:43:07 |
| _hc | they are read-only exploits, so not breakng out of the VM | 07:43:30 |
| _hc | reading out of the VM | 07:43:36 |
| Bubu | Forum update incoming!
| 11:51:41 |
| Bubu | In reply to @bubu:bubu1.eu
Forum update incoming!
done. | 12:43:29 |
| 7 Jun 2020 |
 @fynngodau:disroot.org | Bubu: A friend ran some tests what Andriod versions need what pm command to disable packages (because I wasn't really sure whether the AndroidEnthusiasts answer was right). disable-user should always work from Android 5 onwards. (hide works until Android 7 without root.) You mentioned that apps won't display an "Enable" button, which we found to only be true for user apps; for system apps the Enable button will be shown. | 21:31:54 |
| Bubu | fyfyone: thanks for the info! | 21:32:33 |
| @fynngodau:disroot.org | (I wrote "until 7", I meant "up to including 6.x") | 21:36:35 |
| Bubu | I needed to know how many apps got an update in the last X days, so I made a chart: | 21:43:03 |
| Bubu | 
Download image.png | 21:43:08 |
| Bubu | the beginning didn't record when apks were published | 21:43:42 |
