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> mupuf: https://about.gitlab.com/releases/ -> May 16th, 2024
<mupuf> oh boy, I need to step on it then!
<mupuf> thanks!
<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
<bentiss> oh, that's good!
<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 :-)
<mupuf> now you know ;)
<mupuf> https://github.com/distribution/distribution/releases/tag/v2.8.3 <-- and here you can get the binary (it is go-based, so no other dependencies)
<mupuf> it doesn't have to be a unix socket, I just have it connected to a socket-activated service
<mupuf> https://distribution.github.io/distribution/ <-- that's the documentation for the configuration
rgallaispou has joined #freedesktop
rgallaispou has left #freedesktop [#freedesktop]
Leopold_ has joined #freedesktop
kisak has joined #freedesktop
<kisak> meh ... Gitlab.fd.o/mesa/mesa has a 3 times normal height header today for some reason (128 pixels)
<kisak> If I inspect the page and delete the 120x120 img[...]/fdo-logo.png line, it snaps back to a normal size (same as yesterday).
<kisak> (firefox 115.6.0)
<mupuf> kisak: what header
<mupuf> ?
<mupuf> the one that shows mesa/mesa?
<bentiss> someone needs to resize the logo :)
<mupuf> ha ha ha
<kisak> looks about the same as what I'm seeing
<mupuf> right, I can reproduce
<mupuf> fixed
<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?
<pinchartl> bwidawsk: in https://gitlab.freedesktop.org/bwidawsk/sudbury/-/pipelines there should be a "Clear runner caches" on the top right. it may help
<pinchartl> (a bit of a guess, I haven't tried it)
* bwidawsk tries
<bwidawsk> I think there might be an env var or something, I vaguely recall seeing one
<bwidawsk> maybe GIT_STRATEGY?
<pinchartl> that could also have an effect
<bwidawsk> clearing the runner caches didn't help
<bwidawsk> yeah, GIT_STRATEGY: clone worked
mchehab has quit [Quit: ZNC - https://znc.in]
mchehab has joined #freedesktop
AbleBacon has joined #freedesktop
Inline has joined #freedesktop
jarthur has joined #freedesktop
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #freedesktop
itaipu has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
thaller is now known as Guest13879
thaller has joined #freedesktop
Guest13879 has quit [Ping timeout: 480 seconds]
<bwidawsk> I think if there were a way to hop it in and `git remote prune` that'd work too
<bwidawsk> maybe pre_script would work there? not sure
Haaninjo has joined #freedesktop
privacy has quit [Quit: Leaving]
Leopold_ has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
ximion 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
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
Inline has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
vkareh has quit [Quit: WeeChat 4.1.2]
Leopold_ has quit [Remote host closed the connection]
<DavidHeidelberg> eric_engestrom: around? https://gitlab.freedesktop.org/anholt/deqp-runner/-/merge_requests/65 I'm thinking to patch this MR on deqp we use, so we could generate smaller rootfs (not take that much space on our NFS)
<DavidHeidelberg> eric_engestrom: if you won't mind, I would put your deqp checks into the one MR
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #freedesktop
Haaninjo has quit [Quit: Ex-Chat]
<DavidHeidelberg> ping eric_engestrom
<DavidHeidelberg> I'll be bumping to deqp 0.18.0 I'm thinking to add the gzip patch
Leopold_ has joined #freedesktop
privacy has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
sima is now known as Guest13901
sima has joined #freedesktop