ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
agd5f has joined #freedesktop
ximion has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
ximion has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
agd5f has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
ximion has joined #freedesktop
minus has joined #freedesktop
<minus>
i just registered a gitlab account, but i did not get a confirmation email and when i try to login i get a message saying "Your account is pending approval from your GitLab administrator and hence blocked."
<minus>
just = 20 minutes ago
<DavidHeidelberg[m]>
minus: Hi! Wait until the monday, admins have a weekend ;-)
<minus>
fair; i expect it to be automatic since the sigup page say: >your account will become active within 10-15 minutes.
<minus>
expected*
<jenatali>
IIRC from discussion here there was a 30 minute delay on that email
<minus>
the email did arrive, but it was an hour
<minus>
so it wasn't manual after all but the information on the signup page is just wrong?
<DavidHeidelberg[m]>
jenatali: so the process is automated?
<jenatali>
I thought there was an automated process with admin override if needed, yeah
<minus>
would be nice to update the notice on the signup page to say 1 hour instead of 10-15 minutes then
<minus>
i wonder if using a yubikey's (or similar) attestation certificate would also work as a spam filter, replacing the delay + recaptcha. about as useful as a phone number against spam but not as privacy-concerning
ximion has quit []
<minus>
oh god, recaptcha on editing an issue, that's insane
<mupuf>
minus: hmm, this never happens to me, so expect for it to go away
<__tim>
I get that too occasionally, usually when I edit twice in a row in a short time
<mupuf>
as for the delivery time of emails, it can take a while because of grey filtering
<mupuf>
__tim: oh, weird, thanks for letting me know
<minus>
yeah, i got it when editing an issue after creating it (every time though)
<DavidHeidelberg[m]>
I put two jobs, and both got deployed on fdo-equinix-m3l-9, do we have something where I can ensure that only my job will run (for benchmarking purposes)?
jacker has joined #freedesktop
<DavidHeidelberg[m]>
mupuf: where is the code for the nice sections you use in valve jobs?
<DavidHeidelberg[m]>
I'm for using it everywhere + also, the time in the section name is good looking
<DavidHeidelberg[m]>
have you tried test performance, I'm thinking that we use bash everywhere, but for scripting Ubuntu pushed dash for a long time. I see you like live extremely so... busybox :D
jacker has quit []
danvet has joined #freedesktop
<DavidHeidelberg[m]>
mupuf: I looked into your code, but set -abdedeghfgd probably works only on busybox, it's funnmy but bash and zsh refuse apply some options even when it shows them in "$-"
<mupuf>
DavidHeidelberg[m]: oh no!
<DavidHeidelberg[m]>
afk have to move from coffee :D
<DavidHeidelberg[m]>
back. Anyway. I'll try unified style w/ boot2cont, I like it
<DavidHeidelberg[m]>
for set +x hack, I think keeping just return value of grep x should be enough and just toogle it
<DavidHeidelberg[m]>
or using bash [[ ]] with "*x*" but that's busybox incompat for sure
<DavidHeidelberg[m]>
gst-htz-2 ERROR: Preparation failed: creating cache volume: set volume permissions: create permission container for volume "runner-thys1ka2-project-5165-concurrent-0-53f5fed7485886fa-cache-c33bcaa1fd2c77edfc3893b41966cea8": Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? (linux_set.go:95:120s)
<mupuf>
DavidHeidelberg[m]: I use busybox because the initramfs needs to be as small as possible. Performance is irrelevant since no processing is done in the shell script
<mupuf>
And the plan is to rewrite most of it in golang to allow dropping busybox altogether, along with wget and other tools like it
<mupuf>
So, don't try too hard to unify the codebases ;)
<DavidHeidelberg[m]>
mupuf: hmm. Golang. I get it, but we're more Rusty :D
<DavidHeidelberg[m]>
which isn't best tool for CI (imho)
<mupuf>
Oh, I don't get to chose... podman, mcli, and uroot are in golang
<mupuf>
So they can be merged into one binary
<mupuf>
Again, reducing the size
<mupuf>
The initramfs is downloaded at every boot
<mupuf>
So, size matters :s
<mupuf>
Right now, it is 20 MB. When all is done, it should be about 12 MB
<mupuf>
And no shellscripts! 😇
<DavidHeidelberg[m]>
that's definitely plis
<DavidHeidelberg[m]>
plus
<mupuf>
Yeah, especially for u-boot boards... It is such a stupid bootloader when it comes to memory allocations and thus really like small binaries
<mupuf>
And speaking about this, linux 6.1 brings support for compressed EFI arm64 Linux images!
<mupuf>
Not the Image.gz, I am talking about a self-decompressing image
<mupuf>
It will reduce the kernel size massively and again allow me to fit better in u-boot's hardcoded segments
<mupuf>
So, the next b2c release may come with RPi and other SBC support out of the box
<mupuf>
Then, support in valve infra?
<DavidHeidelberg[m]>
btw. why gitlab yaml linter so stupid
<DavidHeidelberg[m]>
it doesn't even try tell me where is the issue, it always point into some untouched code for decades....
<mupuf>
Yeah...
AbleBacon has joined #freedesktop
ximion has joined #freedesktop
<DavidHeidelberg[m]>
and FDO dying again
<DavidHeidelberg[m]>
see these very often: "ERROR: Preparation failed: creating cache volume: set volume permissions: create permission container for volume "runner-thys1ka2-project-5165-concurrent-0-d8583b12c57df6b6-cache-c33bcaa1fd2c77edfc3893b41966cea8": Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? (linux_set.go:95:120s)"
<DavidHeidelberg[m]>
mupuf: maybe you'll have idea. in `script:` I can't keep the exported functions to use them in another script, is it expected?
<DavidHeidelberg[m]>
I feel like I'm using CI again (and not some char-dump output)
<daniels>
DavidHeidelberg[m]: errors about /var/run/docker.sock aren't to do with fd.o as such, they're runner-local - which runner are you observing that on?
<DavidHeidelberg[m]>
daniels: seen this twice: runner-thys1ka2-project-5165-concurrent-0-d8583b12c57df6b6-cache-c33bcaa1fd2c77edfc3893b41966cea8"
<daniels>
which runner?
<daniels>
it's not an infrastructure problem with gitlab.fd.o or any of our centralised services, it's something that's localised to an individual gitlab-runner instance
<daniels>
so without knowing which runner it's on, we can't fix it
<daniels>
as for having jobs isolated to have a runner all to themselves, that's just not something we have for the build runner
<daniels>
*runners
<DavidHeidelberg[m]>
#596 (thys1kA2) gst-htz-2
<daniels>
when did you see this? it seems like all its jobs have passed for the last 24h or so