2022-05-01 20:44:52 <clandmeter> ikke: i enabled the new webhook container
2022-05-03 04:33:52 <ikke> gitlab security notification
2022-05-05 07:45:25 <ncopa> re alpine-instealler-testsuite gitlab action. could we use a small equinix metal instance for it? ie. have a runner in a bare metal machine, so we dont need nested virtualizaion?
2022-05-05 07:45:53 <ncopa> or maybe we could even spawn it up and tear it down when running it
2022-05-05 07:46:46 <clandmeter> there are no small equinix instances anymore
2022-05-05 07:47:00 <clandmeter> the one we had is not available anymore
2022-05-05 07:47:58 <clandmeter> ncopa: you can just use a shell runner
2022-05-05 07:47:58 <ncopa> s/small/smallest available/
2022-05-05 07:47:58 <alpine-meetbot> ncopa meant to say: re alpine-instealler-testsuite gitlab action. could we use a smallest available equinix metal instance for it? ie. have a runner in a bare metal machine, so we dont need nested virtualizaion?
2022-05-05 07:48:01 <clandmeter> its already available
2022-05-05 07:48:10 <clandmeter> i use it to use qemu
2022-05-05 07:48:20 <clandmeter> i set them up recently
2022-05-05 07:48:43 <clandmeter> both for x86 and aarch64
2022-05-05 07:50:17 <clandmeter> ncopa:  https://gitlab.alpinelinux.org/clandmeter/alpine-disk-image/-/blob/master/.gitlab-ci.yml
2022-05-05 07:51:01 <ncopa> the idea is: when tagging a release, run a job that will: 1) spin up a bare metal machine (using terrafor), 2) install git qemu etc 3) checkout alpine-installer-testsuite 4) download the release artifacts to the baremetal machine, 5) run the testsuite 6) report back to gitlab runner
2022-05-05 07:52:40 <clandmeter> the gitlab runner (shell) already has qemu and git installed
2022-05-05 07:53:24 <ncopa> oh, cool
2022-05-05 07:53:43 <clandmeter> i think what i do is similar to what you do
2022-05-05 07:54:02 <clandmeter> except i use packer and you use expect
2022-05-05 07:54:47 <clandmeter> shell executor does not use any virtualization 
2022-05-05 07:55:59 <clandmeter> i do use docker, but its just to deploy things
2022-05-05 08:09:15 <ikke> My idea is to use space we have on azure for that
2022-05-05 08:09:55 <clandmeter> azure is baremetal?
2022-05-05 08:09:58 <ikke> no
2022-05-05 08:10:02 <ikke> that it's not
2022-05-05 08:10:10 <ikke> hence the nested virtualization
2022-05-05 08:10:29 <ikke> There are instance types which support it
2022-05-05 08:11:06 <clandmeter> if we expose /dev/kvm in docker, what would be the downside to that?
2022-05-05 08:11:15 <clandmeter> on real hw
2022-05-05 08:12:17 <ikke> If we just run the suite on tags, which we control, I see little issue
2022-05-05 08:12:50 <clandmeter> the disadvantage of using a shell executor is that its not a clean env on each run
2022-05-05 08:12:54 <ikke> correct
2022-05-05 08:13:13 <clandmeter> but if you do your magic in qemu, it does not really matter that much.
2022-05-05 08:13:23 <ikke> also correct
2022-05-05 08:14:15 <clandmeter> spinning a real machine on equinix on each run seems like lot of wasted time, i guess it will take some time to provision the server.
2022-05-05 08:19:05 <ikke> We could check what we can do with spot instances?
2022-05-05 08:21:41 <ncopa> how long time does it takes to spin up an alpine instance on equinix?
2022-05-05 08:27:14 <clandmeter> i have no clue, but only loading the efi firmware takes a lot of time
2022-05-05 08:27:32 <ncopa> is it 30 seconds or 5 mins?
2022-05-05 08:27:52 <clandmeter> depends on hw i guess
2022-05-05 08:28:12 <clandmeter> im using a server for work atm that takes minutes to boot
2022-05-05 08:29:45 <clandmeter> i mean why would you want to spin a bare metal server to afterwards run qemu in it?
2022-05-05 08:30:17 <ncopa> to run the alpine-installer-testsuite
2022-05-05 08:30:21 <clandmeter> what you are testing runs in qemu right? not on metal?
2022-05-05 08:30:28 <ncopa> yes
2022-05-05 08:30:57 <clandmeter> so then its kind of useless to needing to spin a new server and wait for boot install and kexec
2022-05-05 08:31:02 <ncopa> i set up a matrix of different emulated hardware combinations (IDE disk, virtio disk, nvme) and run the installer on it
2022-05-05 08:31:25 <ncopa> i test with one or two disks
2022-05-05 08:31:33 <ncopa> test boot with bios or uefi
2022-05-05 08:31:45 <clandmeter> how many arches are you testing?
2022-05-05 08:31:57 <clandmeter> you want to run emulated or kvm?
2022-05-05 08:32:00 <ncopa> right now only x86 and x86_64
2022-05-05 08:32:08 <ncopa> preferrible not
2022-05-05 08:32:27 <ncopa> i'd also like to test on aarch64 hw
2022-05-05 08:32:31 <clandmeter> some arches will be more difficult to test i guess?
2022-05-05 08:32:34 <ncopa> test armv7 and aarch64
2022-05-05 08:32:37 <ncopa> yup
2022-05-05 08:32:39 <clandmeter> like s390x
2022-05-05 08:33:00 <ncopa> i think for ppc64le and s390x we might need to do some simple testing with emulated qemu
2022-05-05 08:33:11 <clandmeter> running with kvm is always nice
2022-05-05 08:33:15 <ncopa> yup
2022-05-05 08:33:28 <clandmeter> thats why i wonder why not just expose it in docker?
2022-05-05 08:33:49 <ncopa> you mean run qemu in docker?
2022-05-05 08:33:56 <clandmeter> what would you miss out on?
2022-05-05 08:34:00 <clandmeter> yeah
2022-05-05 08:34:06 <ncopa> i can do that
2022-05-05 08:34:14 <ncopa> just need to pass in /dev/kvm i guess
2022-05-05 08:34:18 <clandmeter> i was thinking to do the same
2022-05-05 08:34:23 <clandmeter> and move aways from shell executor
2022-05-05 08:34:51 <ncopa> but docker itself runs on bare-metal?
2022-05-05 08:34:56 <clandmeter> we need to do that on the runner, but we can set up specific ones for just kvm usage
2022-05-05 08:35:39 <clandmeter> docker runs on baremetal? 
2022-05-05 08:35:46 <clandmeter> dont understand that question :)
2022-05-05 08:36:24 <ncopa> i think "set up specific ones for just kvm usage" answered my question
2022-05-05 08:36:37 <clandmeter> ok :)
2022-05-05 08:36:59 <clandmeter> that way you dont need to wait for boot, installer, kexec
2022-05-05 08:37:08 <clandmeter> just have a docker image fit for your needs
2022-05-05 08:37:51 <ncopa> right
2022-05-05 08:38:17 <ncopa> i was just thnking that we don't need have the bare-metal machine constantly running
2022-05-05 08:38:45 <ncopa> since those tests only need to run when we tag release candidates or releases
2022-05-05 08:39:33 <clandmeter> well that could be possible, but with the cost mentioned above.
2022-05-05 08:39:40 <clandmeter> and another thing
2022-05-05 08:39:45 <clandmeter> we cant spin arm servers
2022-05-05 08:40:13 <ncopa> ok
2022-05-05 08:40:20 <clandmeter> i still need to sent another email to arm ppl
2022-05-05 08:40:53 <clandmeter> to show them how important alpine is to the arm community
2022-05-05 08:41:05 <clandmeter> and 1 server is not enough for such tasks
2022-05-05 08:43:37 <mps> clandmeter: and riscv
2022-05-05 08:43:51 <clandmeter> ?
2022-05-05 08:44:11 <mps> alpine is important for riscv, imo
2022-05-05 12:26:05 <ikke> We do get hardware from riscvm, but here is no server-grade hw yet
2022-05-05 12:48:08 <mps> ikke: yes, i know, but I have rights to dream
2022-05-05 18:43:50 <psykose> ikke: for some reason someone emailed me saying they can't even fork aports as public
2022-05-05 18:44:23 <ikke> Well, public is disabled for users. They should be able to set it to internal
2022-05-05 18:44:44 <psykose> yes, but you said it needs to be public for anything to work later
2022-05-05 18:45:18 <psykose> and that things automatically go from internal to public
2022-05-05 18:45:23 <ikke> yes
2022-05-05 18:45:24 <psykose> so.. what is the point of disabling it
2022-05-05 18:45:30 <ikke> We only do it for aports
2022-05-05 18:45:47 <psykose> this is so frustrating that i wish we just allowed public-only and called it a day
2022-05-05 18:45:50 <psykose> i'm so tired of this
2022-05-05 18:46:01 <ikke> The reason we set it up like that is that we want to discourage users from using this instance for random projects
2022-05-05 18:46:51 <ikke> The issue that prevents contributors from rebasing when the project is internal has been fixed, so just a little bit of patience left before that lands
2022-05-05 18:47:26 <psykose> yes, but if they fork aports as private then the same issue remains
2022-05-05 18:47:43 <psykose> nothing rewrites private into anything
2022-05-05 18:51:37 <psykose> re random projects; is there no way to forbid new non-fork repo creation entirely in CE
2022-05-05 18:53:46 <ikke> I suppose setting the projects limit to 0
2022-05-05 19:42:34 <ikke> So it turned out I immediately upgraded to gitlab 14.10 instead of first to 14.9
2022-05-05 19:42:47 <ikke> https://docs.gitlab.com/ee/update/#1490
2022-05-05 19:45:49 <psykose> ah
2022-05-05 19:46:16 <psykose> neat
2022-05-05 19:46:28 <ikke> The mentioned background jobs are running
2022-05-05 19:47:41 <psykose> they should perhaps complete..
2022-05-05 19:48:00 <ikke> yes, I see one already making progress
2022-05-05 19:48:06 <ikke> MigratePersonalNamespaceProjectMaintainerToOwner: members 99.00% 
2022-05-05 19:48:23 <psykose> at last i can be a true owner /s
2022-05-05 19:48:30 <ikke> :D
2022-05-05 19:52:55 <ikke> How about NullifyOrphanRunnerIdOnCiBuilds: ci_builds 7.00% 
2022-05-05 19:54:50 <psykose> a whole null of my own, too 🥺
2022-05-05 20:56:41 <psykose> rebasing !34009 also fails with the new hook
2022-05-05 21:05:26 <ikke> I see what's going on, will look at it tomorrow
2022-05-06 09:51:18 <mps> we don't have rust in s390x and riscv-64
2022-05-06 09:53:01 <mps> new clamav needs rust
2022-05-06 12:13:57 <ikke> psykose: one thing I did change is that by default projects are set to internal instead of private, maybe that will reduce the amount of forks that start as private
2022-05-06 12:15:52 <psykose> hope so
2022-05-06 12:23:03 <psykose> thanks :3
2022-05-06 16:24:01 <ikke> 14.10.2 does not solve the issue errors
2022-05-06 16:24:04 <ikke> sadly
2022-05-06 17:54:50 <ikke> Oof, the irony: a 500 response from gitlab when trying to report an issue :/
2022-05-08 15:44:35 <minimal> any plans to fix that Issues in Gitlab are no longer viewable if not logged in? Or is this a new Gitlab "feature" that cannot be reverted?
2022-05-08 15:46:42 <ikke> https://gitlab.com/gitlab-org/gitlab/-/issues/361699
2022-05-08 15:46:54 <ikke> Want to fix it, but trying to figure out how
2022-05-08 15:53:28 <minimal> ok, thanks
2022-05-08 15:55:15 <ikke> Something graphql related
2022-05-08 15:58:58 <minimal> weird that the MR page works though when not logged in
2022-05-09 12:30:14 <ikke> I received confirmation that the rv64 board is being shipped
2022-05-09 12:32:05 <psykose> someone could've walked it across the atlantic in this time /s
2022-05-09 12:40:42 <mps> ikke: also
2022-05-09 12:40:48 <mps> few days ago
2022-05-09 12:41:36 <mps> I downloaded some docs about JH7100 and started to read when I have some time
2022-05-09 12:42:04 <mps> and I started to skim over ISA
2022-05-09 12:42:44 <mps> btw, last night I managed to destroy my macbook m1
2022-05-09 12:42:59 <ikke> ouch, how did you manage to do that?
2022-05-09 12:43:46 <mps> simple, spilled water over it :\
2022-05-09 12:44:59 <ikke> bummer
2022-05-09 12:47:12 <mps> will try to call service if they can 'save' it
2022-05-09 13:35:45 <ikke> "Your package is delayed due to local reasons."
2022-05-09 13:35:50 <ikke> More delays
2022-05-09 13:57:39 <psykose> giga delay
2022-05-09 14:03:16 <minimal> ikke: can't you add another worker machine so the package will build quicker? ;-)
2022-05-09 14:16:54 <clandmeter> Same here
2022-05-10 04:31:23 <ikke> apparently we are not the only one having the problem with the error on the issue list when not being logged in
2022-05-10 18:00:32 <ikke> https://git.pleroma.social/pleroma/pleroma/-/issues
2022-05-10 18:00:38 <ikke> same issue
2022-05-10 18:00:57 <ikke> minimal: ^
2022-05-10 18:05:44 <minimal> ikke: on Gitlab's own issues page you can't search for an issue (such as this problem) without being logged in....doh!
2022-05-10 18:06:52 <ikke> Yeah, that's anoying
2022-05-10 18:07:04 <ikke> But at least you can still see the issues
2022-05-10 18:24:31 <minimal> yeah but short of trawling through all their recent issues there's no easy way to know (i.e. search) if its already on their radar
2022-05-10 18:24:48 <ikke> I did search for it
2022-05-10 18:25:27 <ikke> and someone else managed to find at least this one
2022-05-11 10:26:38 <ikke> So apparently the error has to do with 'public' being restricted in our instance
2022-05-11 14:42:04 <ikke> Someone from gitlab is working on a fix for the issue
2022-05-11 14:45:43 <clandmeter> \o/
2022-05-11 17:53:31 <ncopa> Ariadne told me she cannot push to main anymore
2022-05-11 17:54:02 <Ariadne> can we just delete this stupid hook
2022-05-11 17:54:10 <Ariadne> we either trust people to push to alpine or we don't
2022-05-11 17:54:38 <ncopa> i guess that 1. makes sense 2. would simplify things
2022-05-11 17:56:53 <ncopa> what is enforcing that limitation?
2022-05-11 18:00:29 <ncopa> I also have that. "You are not allowed to push to the main repository. Try again."
2022-05-11 18:01:33 <ncopa> but it seems like i can press there mer when pipeline finishes
2022-05-11 18:05:28 <Ariadne> ikke: can we just delete this?  i don't think it really gets us anything
2022-05-11 18:06:10 <Ariadne> like i understand the theory behind it -- graduate people up to having main access -- but realistically, it just blocks people from getting work done
2022-05-11 18:06:39 <Ariadne> and now it is blocking anyone from getting *anything* done
2022-05-11 18:06:51 <ncopa> does it? it seems to work for me now?
2022-05-11 18:06:54 <ncopa> not sure what is happening
2022-05-11 18:06:59 <ncopa> i saw the error message
2022-05-11 18:07:52 <ncopa> but after a refresh or something it disapeared?
2022-05-11 18:08:52 <psykose> merge something, then :p
2022-05-11 18:09:10 <psykose> i vote for !33751
2022-05-11 18:10:26 <Ariadne> nope it does not work for me
2022-05-11 18:12:11 <ncopa> weird. I wonder how it is supposed to work. and what enforces it
2022-05-11 18:12:29 <psykose> shell script with some greps and a magic file
2022-05-11 18:14:44 <Ariadne> i think if we want to have this, we should do it as separate projects in gitlab
2022-05-11 18:14:55 <Ariadne> instead of something ported from gitolite days
2022-05-11 18:15:06 <Ariadne> but i am not convinced we really need it
2022-05-11 18:15:12 <Ariadne> we should just get rid of it
2022-05-11 18:15:20 <Ariadne> it's a point of failure that serves only political purpose
2022-05-11 18:15:47 <ncopa> psykose: do you know how/where they are executed?
2022-05-11 18:15:49 <ncopa> from where
2022-05-11 18:16:00 <Ariadne> gitlab runs it as a pre-commit hook
2022-05-11 18:16:02 <psykose> some hook container on something i don't have access to
2022-05-11 18:19:48 <ikke> /srv/docker/repositories/alpine-aports/custom_hooks/update
2022-05-11 18:20:31 <ikke> Sorry /srv/docker/gitlab/... 
2022-05-11 18:21:54 <Ariadne> can we just delete this damn thing
2022-05-11 18:22:51 <Ariadne> it is political theatre and provides no actual security benefit to alpine -- if somebody wants to fuck up alpine with commit rights, they will just jump through the additional hoops to get main access anyway
2022-05-11 18:23:24 <ncopa> ikke: so it is not to be found from the webui?
2022-05-11 18:23:29 <Ariadne> in fact, right now, it is causing security problems to alpine
2022-05-11 18:23:35 <Ariadne> because i cannot mitigate CVEs
2022-05-11 18:25:35 <ikke> ncopa: correct 
2022-05-11 18:26:05 <ncopa> where does this machine run?
2022-05-11 18:26:19 <ikke> deu2-dev1
2022-05-11 18:26:26 <ikke> Linode 
2022-05-11 18:29:51 <ncopa> ok. i dont have login there
2022-05-11 18:33:10 <ikke> Oof
2022-05-11 21:15:00 <clandmeter> ikke: was it the hook that failed?
2022-05-12 04:48:55 <psykose> more like 100%
2022-05-12 04:50:05 <ikke> 100% is more than 95% :P
2022-05-12 04:51:27 <psykose> indeed so
2022-05-12 04:51:28 <psykose> :3
2022-05-12 04:51:49 <psykose> afaik most of the space is trimmed at the end of the run once the old gopkgs will be trimmed
2022-05-12 04:51:58 <psykose> just well, 6 worlds at once is a big growth
2022-05-12 04:52:35 <ikke> Yeah, at leas in the current raid config, that box does not have enough space
2022-05-12 04:52:40 <ikke> (lvm raid)
2022-05-12 04:57:55 <psykose> also very fun, zabbix removed the unsupported tags from github, so 5.4 is gone for 3.15
2022-05-12 05:02:12 <psykose> they have 'official' tarballs on the website, https://www.zabbix.com/download_sources#unsupported but they have dbschema missing or something
2022-05-12 05:04:15 <ikke> they can be generated
2022-05-12 05:04:52 <ikke> make dbschema
2022-05-12 05:06:32 <psykose> that's what i mean :) it's undefined
2022-05-12 05:06:51 <psykose> looking at the configure stuff, everything is gated behind #if DBSCHEMA
2022-05-12 05:06:58 <psykose> and DBSCHEMA is set from a `test -d create`
2022-05-12 05:07:20 <psykose> if you force make the directory, you get failures with ` No rule to make target '../../../create/src/schema.tmpl', needed by 'dbschema.c'.  Stop. `
2022-05-12 05:07:32 <psykose> so, simply the create folder with the base things is not part of the tarball
2022-05-12 05:07:53 <ikke> did you run autoreconf?
2022-05-12 05:08:00 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/zabbix/APKBUILD#L98
2022-05-12 05:08:27 <psykose> i mean.. the apkbuild is running it right there
2022-05-12 05:08:29 <psykose> not doing this by hand
2022-05-12 05:08:33 <ikke> ah ok
2022-05-12 05:09:23 <psykose> idk why the 'official' tarballs are missing this
2022-05-12 05:10:25 <psykose> oh, hm
2022-05-12 05:10:49 <psykose> they are already built, that's why
2022-05-12 05:11:03 <psykose> no need to run it at all, unless it's supposed to be updated
2022-05-12 05:12:36 <ikke> Right, if you download it from github (source), you do need to do it, but hte ofificial tarballs already have it included
2022-05-12 05:13:00 <psykose> mhm
2022-05-12 05:13:04 <psykose> guess it can just be removed then
2022-05-12 05:13:07 <ikke> But strange that it fails
2022-05-12 05:13:43 <psykose> well, the rule is not generated without the base files being present
2022-05-12 05:13:51 <psykose> they purposefully just remove them
2022-05-12 05:14:53 <ikke> ah ok
2022-05-12 05:17:38 <ikke> We do at least have the source we built with on distfiles
2022-05-12 05:18:55 <ikke> are you doing a go upgrade?
2022-05-12 05:18:57 <psykose> it's fine to swap i think
2022-05-12 05:19:00 <psykose> yeah, this was the last thing
2022-05-12 05:19:13 <psykose> just doublechecking a diff on the edge one
2022-05-12 05:19:23 <ikke> 5.4 is eol, will not receive any updates anymore
2022-05-12 05:19:24 <psykose> removing make dbschema removes some files, now seeing if new source + remove is identical
2022-05-12 05:19:30 <psykose> yeah, but it's a 3.15 rebuild
2022-05-12 05:19:36 <ikke> ahuh
2022-05-12 05:19:58 <ikke> I mean that there will be no other versions anymore anyway
2022-05-12 05:20:02 <psykose> mhm
2022-05-12 05:22:29 <psykose> it does have one more side effect
2022-05-12 05:22:51 <psykose> some useless .gitignore folders are removed from usr/share/webapps/zabbix in zabbix-webif
2022-05-12 05:23:09 <ikke> aha
2022-05-12 05:23:11 <psykose> and all of usr/share/webapps/zabbix/tests/ is dropped, which leads to a 63->60 mb change
2022-05-12 05:23:21 <psykose> you should change to the official tarball next upgrade
2022-05-12 05:23:42 <ikke> The main reason I used source is that it's easier to test rc's
2022-05-12 05:23:48 <psykose> yeah, it is
2022-05-12 05:24:03 <ikke> in the past that was usefull specifically for go and 32-bits
2022-05-12 05:24:22 <psykose> and with that, both go's are now sent
2022-05-12 05:24:26 <psykose> rip to diskspace
2022-05-12 05:25:56 <psykose> i think there's some $HOME/go / .cargo cache to trim by now
2022-05-12 05:26:31 <ikke> yeah
2022-05-12 05:32:39 <ikke> 150G should be enough for a while
2022-05-12 05:32:58 <psykose> yeah
2022-05-12 05:33:00 <ikke> for builder in build-3-16-* build-3-15-* build-edge-*; do rm -rf ./$builder/rootfs/home/buildozer/.cargo ./$builder/rootfs/home/buildozer/.cache/go-build ./$builder/rootfs/home/buildozer/.cache/yarn ./$builder/roo
2022-05-12 05:33:02 <ikke> tfs/home/buildozer/go; done
2022-05-12 05:33:28 <psykose> it wasn't not enough currently, but there is that middle period where old packages aren't deleted yet, so unfortunate
2022-05-12 05:34:16 <ikke> But we need to think about the next release
2022-05-12 05:34:32 <psykose> i don't think it's possible without another machine
2022-05-12 05:34:49 <ikke> At least this one still has unassigned space
2022-05-12 05:34:52 <psykose> ah
2022-05-12 05:34:55 <psykose> then sure
2022-05-12 05:35:03 <psykose> there will be space freed up on proper release
2022-05-12 05:35:10 <ikke> I'm just conservative in assigning it
2022-05-12 05:35:10 <psykose> er, no
2022-05-12 05:35:43 <ikke> The rc's can be removed
2022-05-12 05:36:09 <psykose> those are pretty small anyway
2022-05-12 05:36:12 <ikke> yup
2022-05-12 07:05:43 <clandmeter> ikke: ?
2022-05-12 07:11:14 <ikke> re update hook?
2022-05-12 07:14:14 <clandmeter> yup
2022-05-12 07:24:17 <ikke> the hook was working, the acl list outdated
2022-05-12 09:13:04 <clandmeter> ah ok, thx for checking. 
2022-05-12 09:16:44 <psykose> rebooting deu1/deu7 for the usual kernel and things :)
2022-05-12 09:20:05 <psykose> algitbot: ping
2022-05-12 09:21:19 <clandmeter> ikke: we need to think about a plan to get those new t1 servers going
2022-05-12 09:21:29 <clandmeter> or at least the new NL one
2022-05-12 09:31:47 <ikke> You wanted to use zfs, right?
2022-05-12 09:47:01 <clandmeter> we can, the disk setup is kind of optimal for zfs usage
2022-05-12 09:47:08 <clandmeter> but its not  a must for me
2022-05-12 09:50:34 <ikke> I don't mind
2022-05-12 09:50:47 <ikke> I have no experience with it myself though
2022-05-12 09:51:50 <clandmeter> lets change that :)
2022-05-12 09:52:12 <clandmeter> i have played with it, just not that much.
2022-05-12 09:52:41 <clandmeter> do we want to run docker on it?
2022-05-12 09:57:07 <ikke> good quesiton, not sure
2022-05-12 10:32:32 <ikke> ugh, from 150G free to 36G free in a couple of hours
2022-05-12 10:34:31 <psykose> i'm curious where the space went, considering no actual new packages were added
2022-05-12 10:35:34 <ikke> ~/go apparently
2022-05-12 10:36:05 <psykose> hah
2022-05-12 10:36:09 <psykose> well, that makes sense
2022-05-12 11:42:49 <ncopa> i might need some handholding to set up a CI job for alpine-conf. I'd like to install kyua and run `make test` for every MR
2022-05-12 11:43:19 <psykose> afaik that is editing the .gitlab-ci.yml in the alpine-conf repo
2022-05-12 11:43:54 <psykose> +- perhaps hitting a toggle somewhere
2022-05-12 11:44:26 <ncopa> maybe I need to create a docker image as well?
2022-05-12 11:44:31 <psykose> then the rest is the gitlab ci pipeline thing, for which the apk-tools ones might be of use https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/.gitlab-ci.yml
2022-05-12 11:44:36 <psykose> ehh, i don't think so
2022-05-12 11:44:47 <psykose> apk just uses standard alpine:latest
2022-05-12 11:45:04 <ncopa> oh... thats nice
2022-05-12 11:45:23 <psykose> even if you want to 'add stuff' into the container, unless it's building custom stuff upfront, it's not slow to apk add / run a bit of shell
2022-05-12 11:45:39 <psykose> if you want to build a whole thing then yeah, a custom image would be useful to make it faster
2022-05-12 11:46:42 <psykose> but from the sound of it, this is just running make test on some shell scripts, so just alpine should be fine
2022-05-12 11:48:40 <ikke> If it's just a few deps, it's maybe easier to do it directly in .gitlab-ci.yaml. If you need a more elaborate setup, we can make an image
2022-05-12 11:48:48 <ncopa> yeah
2022-05-12 11:48:58 <ncopa> i guess I'll create an MR with it
2022-05-12 11:49:55 <ikke> Don't forget to add tags to the jobs to select the runners
2022-05-12 11:50:16 <psykose> you can probably copy the apk one and leave only the test stage and go from there
2022-05-12 11:57:38 <ncopa> Something like this?
2022-05-12 11:57:38 <ncopa> https://tpaste.us/qaNa
2022-05-12 11:57:38 <ncopa> $ tpaste < .gitlab-ci.yaml 
2022-05-12 11:58:33 <ikke> Note that each jobs starts with a clean tree by default
2022-05-12 11:59:59 <ikke> so if the goal is to just run tests (that depends on built files), it's probably enough to have a single job that does both
2022-05-12 12:00:06 <ncopa> yeah
2022-05-12 12:01:03 <ikke> Multiple stages can make sense if you want to avoid expensive builds by checking things in advance
2022-05-12 12:04:50 <ncopa> do I need to add runners for it? https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/65
2022-05-12 12:05:14 <ikke> ncopa: you need to enable shared runners here: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/settings/ci_cd
2022-05-12 12:05:46 <ikke> under the runners section
2022-05-12 12:06:16 <ikke> And then restart the job
2022-05-12 12:06:54 <ikke> yes!
2022-05-12 12:07:57 <psykose> :3
2022-05-12 12:09:29 <ncopa> sweet!
2022-05-12 12:09:38 <ncopa> something is broken in the kyua setup though
2022-05-12 12:10:05 <psykose> i assume the test-env it sources doesn't exist or something
2022-05-12 12:10:08 <psykose> is something supposed to make it
2022-05-12 12:26:10 <psykose> ah, the ole strace in the ci job :)
2022-05-12 12:26:47 <ikke> :D
2022-05-12 13:01:37 <ncopa> i cannot figure out what it does and why it fails
2022-05-12 13:05:18 <ikke> Can you reproduce it locally in a docker container?
2022-05-12 13:12:20 <ncopa> nope
2022-05-12 13:12:24 <ncopa> but I figured it out now
2022-05-12 13:12:49 <ncopa> i have a *.sh in .gitignore, so the tests/test_env.sh was never included in git
2022-05-12 13:13:04 <ikke> aha
2022-05-12 13:13:06 <psykose> hey i guessed that :)
2022-05-12 13:13:26 <ncopa> oh.. sorry i missed that while on lunch...
2022-05-12 13:13:33 <psykose> hehe
2022-05-12 13:13:37 <psykose> hope it was as tasty as mine
2022-05-12 13:13:47 <ncopa> psykose: i definitively need to better at listening
2022-05-12 13:19:24 <ncopa> \o/ its now in prod!
2022-05-12 13:19:48 <psykose> \/o
2022-05-12 13:19:58 <psykose> and with that i'm off to bed
2022-05-12 13:20:21 <ikke> o/
2022-05-12 13:34:24 <ncopa> good night!
2022-05-12 15:05:04 <ncopa> any idea why there are no runners for this MR? https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/64
2022-05-12 15:11:56 <ikke> ncopa: did you enable shared runners after rebasing / starting the pipeline?
2022-05-12 15:12:12 <ncopa> no
2022-05-12 15:12:23 <ncopa> do i need enable shared runners for the users fork?
2022-05-12 15:12:36 <ikke> Normally not, we don't need to do it for aports either
2022-05-12 15:12:45 <ikke> And they are enabled
2022-05-12 16:35:22 <ikke> clandmeter: What do you think about lifthing the restriction on public repos on our instance? More then once it has created issues
2022-05-12 16:35:52 <clandmeter> i think we have to be careful with it
2022-05-12 16:36:51 <clandmeter> what would be the reason to do it?
2022-05-12 16:37:29 <ikke> 1) get rid of issues caused by it (apparently gitlab is not testing with this enabled a lot)
2022-05-12 16:38:06 <ikke> 2) psykose (and I assume others as well) get frustrated because they cannot rebase some MRs in certain cases
2022-05-12 16:39:48 <clandmeter> thats related to permsisions?
2022-05-12 16:39:49 <panekj> it's also annoying because internal/private forks default to making MR in own repo (because alpine repos are public and gitlab is like: we need to protect you)
2022-05-12 16:40:59 <ikke> clandmeter: Yes
2022-05-12 16:43:08 <clandmeter> if psykose has issues with it, maybe she can help montior abuse if we switch?
2022-05-12 16:46:10 <clandmeter> abuse is the main concern here right?
2022-05-12 16:47:17 <ikke> The primary concert was users starting to host their own personal projects which is a liability for us
2022-05-12 16:47:45 <ikke> We already have people agreeing to some terms regarding to that
2022-05-12 16:48:43 <clandmeter> does it impact CI usage?
2022-05-12 16:49:08 <ikke> No, in the sense that people can already abuse CI with private projects
2022-05-12 16:49:23 <clandmeter> nod
2022-05-12 16:49:56 <clandmeter> i guess in the end it does not really matter?
2022-05-12 16:50:06 <ikke> Yeah, I was thinking the same
2022-05-12 16:52:46 <ikke> So should I proceed and remove it?
2022-05-12 16:53:04 <clandmeter> sounds good to me
2022-05-12 16:53:22 <clandmeter> and would be good if we have somebody to keep an eye on it
2022-05-12 16:54:46 <ikke> minimal: issues are visible again when not logged in
2022-05-12 16:55:04 <ikke> clandmeter: I think you should be able to get ssh keys again now as well
2022-05-12 16:55:33 <clandmeter> :)
2022-05-12 16:55:56 <clandmeter> Pandoras box has opened 
2022-05-12 17:40:29 <minimal> ikke: good news :-)
2022-05-12 17:40:43 <minimal> ike: was it a bug or a feature?
2022-05-12 17:41:00 <ikke> bug
2022-05-12 17:41:22 <ikke> but triggers by having public repos restricted
2022-05-12 17:41:27 <ikke> triggered*
2022-05-12 19:34:45 <ikke> ncopa: I think for existing forks, you'd need to enable shared runners, new forks will have it enabled
2022-05-12 19:35:03 <ikke> https://gitlab.alpinelinux.org/dbradley/alpine-conf/-/jobs/719708
2022-05-12 23:52:31 <psykose> sure, i can watch gitlab if you want me to, though i'm unsure of what lets one do that aside from some admin ui
2022-05-12 23:53:01 <psykose> it's all fine by me though, i don't mind
2022-05-13 09:02:48 <mps> psykose: did you create MR for clamav 0.104.3
2022-05-13 09:03:47 <psykose> no, how come
2022-05-13 09:03:47 <mps> I doubt that the 0.105.0 will be solved soon, it needs rust but we don't have rust on s390x and riscv64
2022-05-13 09:03:52 <psykose> yep
2022-05-13 09:03:59 <psykose> just thought i'd make it .3 since we had it in 3.15 already
2022-05-13 09:04:16 <psykose> re: rust, imo it's fine to just disable it on those arches i guess
2022-05-13 09:04:25 <mps> psykose: ok, I will cherry pick from 3.15, I upgraded clamav there few days ago
2022-05-13 09:04:26 <psykose> and perhaps in the next 6 months we will have rust there, finally :)
2022-05-13 09:04:40 <psykose> mps: i mean that i already merged 0.104.3 into edge
2022-05-13 09:04:51 <mps> ah, good
2022-05-13 09:05:56 <mps> 'perhaps' sounds like infinite ;)
2022-05-13 09:06:45 <psykose> well, for s390x it's guaranteed
2022-05-13 09:06:52 <psykose> or there will not be s390x anymore :p
2022-05-13 09:06:58 <psykose> for riscv i guess it is more infinite..
2022-05-13 09:07:11 <psykose> but it already builds, just need to figure out some internal issues, hopefully upstream helps
2022-05-13 09:08:34 <mps> (I'm not sure we need s390x (and ppc64le) but ...)
2022-05-13 09:22:43 <psykose> ppc64le at least usually works :)
2022-05-13 09:22:52 <psykose> (until binutils or go or whatever else magically stops working..)
2022-05-13 09:54:28 <panekj> anything that has ring as dependency: am I a joke to you?
2022-05-13 17:19:12 <zv> what do y'all use for arm builders, and where did you get them?
2022-05-13 17:29:45 <mps> zv: it is one neoverse-n1 machine and builders for armhf,armv7 and aarch64 are 3 lxc
2022-05-14 07:44:38 <ikke> zv: arm sponsors us a machine
2022-05-14 07:45:19 <ikke> netbox upgraded to 3.2.3
2022-05-14 14:34:20 <zv> ikke: do you have an account manager there / would you be in a position to share their contact info?
2022-05-16 06:44:25 <rails> zv: do you need arm64 resources for something?