daniels 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
shashanks_ has joined #freedesktop
bubben has joined #freedesktop
shashanks has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> home]
privacy has joined #freedesktop
Haaninjo has quit [Quit: Ex-Chat]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
bubben has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
Kayden has joined #freedesktop
Leopold_ has quit [Ping timeout: 480 seconds]
atticf is now known as Guest13804
atticf has joined #freedesktop
atticf has quit [Remote host closed the connection]
Guest13804 has quit [Ping timeout: 480 seconds]
atticf has joined #freedesktop
bmodem has joined #freedesktop
Leopold has joined #freedesktop
Leopold has quit [Remote host closed the connection]
privacy has quit [Quit: Leaving]
AbleBacon has quit [Read error: Connection reset by peer]
havdan[m] has quit [Quit: Client limit exceeded: 20000]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #freedesktop
bmodem has quit [Excess Flood]
bmodem has joined #freedesktop
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
tzimmermann has joined #freedesktop
<bentiss>
gitlab security update incoming, so we'll bump to gitlab 16.7.2 just one week before 16
<bentiss>
*before 16.8 is out
cadubentzen has quit [Read error: Connection reset by peer]
<mupuf>
bentiss: :)
cadubentzen has joined #freedesktop
<bentiss>
migration is done, gitaly have restarted, we are now just waiting for webservice to rollout to the new version
<bentiss>
nd done. Welcome to gitlab 16.7.2
<mupuf>
thank you!
<mupuf>
Do you know when gitlab 17 is expected to come?
* mupuf
needs to spend time migrating to the new runner registration flow :D
<bentiss>
yeah, we probably need to do the same for the equinix runners.... but not today
<mupuf>
you programatically generate their tokens?
<bentiss>
nope
<bentiss>
a good old copy/paste when deploying IIRC
<pinchartl>
I've done the same
<pinchartl>
provisioning runners is an infrequent enough operation that I haven't tried to use the API to create the token
sima has joined #freedesktop
<bentiss>
pinchartl: the problem is that we'll need to do something different starting with gitlab 17
<pinchartl>
switching from a registration token to an authentication token, right ?
<bentiss>
yeah, something like that
<pinchartl>
yes, I've done that recently
<pinchartl>
and implemented support for it in lava-gitlab-runner
<bentiss>
basically, IIRC, we need to register the runner first on the instance, and then have the token instead of having a generic token and let the runner register itself
<pinchartl>
there are ongoing discussions though, and the end result may be different than what I proposed
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #freedesktop
bilboed has joined #freedesktop
gchini has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
gchini has joined #freedesktop
egbert has quit [Read error: Connection reset by peer]
egbert has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
kxkamil has quit []
kxkamil has joined #freedesktop
mvlad has joined #freedesktop
<pinchartl>
mupuf: is boot2container suitable to run on low-end ARM(64) systems ?
<mupuf>
Arm64, yes. Anything with 256M ram will work
<mupuf>
Arm, I need to fixup the build process for it
<pinchartl>
using an sd card to store container images is fine ?
<mupuf>
The only real issue should be that b2c takes ~80MB of RAM
<mupuf>
Yes
<pinchartl>
could b2c run from a rootfs on the sd card too instead of using an initramfs ?
<mupuf>
yeah, should work, just need to extract the cpio archive
<pinchartl>
I'm looking for a way to run debian image on arm64 systems for CI purpose, where every run should start from the same pristine state
<mupuf>
I see
<pinchartl>
with containers any runtime change will be stored in an overlay in ram, so it gets thrown away automatically
<pinchartl>
otherwise I would need a r/o nfs root + overlayfs
<mupuf>
Right
<mupuf>
pinchartl: how will you control the boot command though? U-boot+pxe?
<mupuf>
Or u-boot script?
<mupuf>
(In case you want to change the boot target)
<pinchartl>
probably a u-boot script, yes
<pinchartl>
(loaded through tftp)
<mupuf>
Sounds like a workable plan
<mupuf>
Let me know if some things can be done on b2c's side to make this use case easy yo maintain
<pinchartl>
sure
<pinchartl>
thanks
<mupuf>
I guess you'll need to generate a disk image with u-boot and an integrated b2c
<mupuf>
Then we can let b2c take over the empty space in the partition table
<mupuf>
Maybe we could modify boot2ipxe, since it does most of the work already
<mripard>
pinchartl: do you really need debian, or would an immutable distro (Silverblue, nixos, etc.) work for you?
pkira has joined #freedesktop
<pinchartl>
mripard: we've standardized lots of tooling on debian packages, so I would like to at least stick to that
<pinchartl>
and I want a pre-built image that contains all the dependencies, they shouldn't be reinstalled on every boot
<mripard>
ack :)
<pinchartl>
only the libcamera binaries should be deployed at runtime
<mupuf>
pinchartl: you won't download the kernel through tftp?
<pinchartl>
possibly
<pinchartl>
but the kernel won't get rebuilt every time
<pinchartl>
updating the kernel will be a manual operation
<mupuf>
Make it so your pipeline can control it, so that updating the kernel can be pre-merge tested
<mupuf>
Advice from a friend ;)
<pinchartl>
we're testing libcamera, no the kernel. updating the kernel would be no different than updating the userspace dependencies (such as the meson version for instance)
<mupuf>
Right, I would advise making that config part of the pipeline for the same reason
<mupuf>
Let me tell you, updating 20 machines is no fun, but figuring out why one fails is no fun, especially in panic
<mupuf>
With 100 machines, you are doomed
<mupuf>
That's why I built b2c and citron the way they are: no config stored on the DUT
<mupuf>
Just the BIOS config
<mupuf>
Everything else is pre-merge testable
<pinchartl>
we need to at least *cache* the container in permanent storage on the DUT
<mupuf>
Yeah, caching is fine
<mupuf>
Another reason I went with containers
<mupuf>
Reproducibility, fresh boot every time, cacheable
<mupuf>
And standardised transport protocols
<pinchartl>
standardized image formats and transport protocols are nice, yes
<pinchartl>
container isolation isn't an important feature in this case, it's more about easing deployment
<mupuf>
:)
<mupuf>
Anyway, just my 2 cents
<pinchartl>
does b2c run podman as root ?
<mupuf>
Yes, in a privileged container
<mupuf>
So, full access to the DUT
<pinchartl>
ok, pretty much no isolation then. perfect
<mupuf>
Yep
<mupuf>
You can control which cgroups to use too
* pinchartl
pulled his hair out with running the chrome os sdk in a container last month
<pinchartl>
in the end I had to run podman --privileged as root, nothing else worked :-(
<mupuf>
Oh yeah, I can believe that!
<mupuf>
Even though it is a privileged container, you can still run background services
<mupuf>
We use that for monitoring
<mupuf>
We use telegraf to send back CPU/GPU/temperature/RAM/SMART information about the DUT during execution
<mupuf>
And no need to modify the project-specific container for that
<mupuf>
It is its own independent container
<mupuf>
So updates don't even require changes to the repos of every project you run on
<mupuf>
Composition is a great feature of containers
<pinchartl>
running multiple containers can be useful too, yes
gert31 has joined #freedesktop
Leopold_ has joined #freedesktop
gchini has quit [Quit: Leaving]
gchini has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
privacy has joined #freedesktop
gert31 has quit [Ping timeout: 480 seconds]
ximion has joined #freedesktop
thaller has quit [Remote host closed the connection]
thaller has joined #freedesktop
thaller has quit [Read error: Connection reset by peer]
thaller has joined #freedesktop
mvlad has quit [Ping timeout: 480 seconds]
mvlad has joined #freedesktop
blatant has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
<kxkamil>
any progress on gmail.com ML drops?
bmodem has quit [Ping timeout: 480 seconds]
<emersion>
i wanted to have a look at this, but i have my hands full with more urgent stuff now
<pinchartl>
would gmail get fixed faster if @google.com and @chromium.org addresses were unsubscribed too ? :-)
<mupuf>
lol
tomeu has joined #freedesktop
<tomeu>
the chromeos sdk used to hard require root because of its use of loop devices, I don't know if that got fixed at some point
<pinchartl>
tomeu: it requires root for many extra reasons
<pinchartl>
most of them are fine running as "root" in a container
<pinchartl>
but not all of them
<tomeu>
yeah, that's what I meant
<daniels>
pinchartl: _completely_ agree with what mupuf said earlier - local caching is good, but make sure everything is ultimately sourced from config/pipeline, otherwise you're just creating problems for yourself later down the line
<mupuf>
yeah, *especially* when dealing with notoriously-flaky sdcard
<pinchartl>
daniels: so you're happy storing all the container images that will run on the DUTs in registry.fd.o ?
<daniels>
pinchartl: let's try it and see what happens
<pinchartl>
:-)
vkareh has joined #freedesktop
<mupuf>
pinchartl: the 75G monsters? Ha ha
<mupuf>
you could also keep that local: put a docker registry on the ci gateway
bmodem has joined #freedesktop
<mupuf>
well, you probably want to have a pull-through caching registry anyway, so that every DUT would download it from there rather than from registry.fd.o
<pinchartl>
one more thing to learn how to setup
<pinchartl>
jmondi: ^^
<mupuf>
fortunately, it's pretty simple :)
<pinchartl>
everything is simple once you know how to do it :-)
<kisak>
Looks good here, thanks for the quick triage.
<bentiss>
mupuf: thanks!
<mupuf>
my pleasure
Leopold_ has quit [Remote host closed the connection]
blatant has quit [Quit: WeeChat 4.1.2]
kisak has left #freedesktop [#freedesktop]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #freedesktop
lsd|2 has joined #freedesktop
pkira has quit [Quit: WeeChat 4.1.2]
tzimmermann has quit [Quit: Leaving]
Leopold_ has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
<bwidawsk>
Could use some advice... At some point I had a `fixes` branch. I think this collides now with any branch named `fixes/*` leading to this: https://gitlab.freedesktop.org/bwidawsk/sudbury/-/jobs/53679765#L14. Is the best way to fix this just to wipe the container and start over, or can I force reinitialize the git repo?