yeah, i'm curious what you'd do alternatively? more ostree native?
yeah, i'm curious what you'd do alternatively? more ostree native?
GThat would be rpm-ostree no? It wouldn't be ingesting a local OCI, instead re building the ostree image with the packages, which is exactly what rpm-ostree does for package layering
AMm I am not sure, I wish there was a way of rebasing OCI layers
ATo be honest I am using ansible for the whole set up so that adds to it
ABut also it has to be written like 3 times:
- podman storage
- Local image in filesystem
- ostree repo
AMaybe there's a way of not doing that
AAI pushed it
Xa modular system doesn't lend itself well for
fleek add kind of functionality
B
GitHub
Use --delete-if-present so it would not fail if nomodeset not exists
GFair, also what do we need to add to the website for docs for the new startingpoint? I think we should try to find a way to automatically fetch the README.md for each module and the repo itself
G@akdev it appears notifications have issues running as root...
Gany proposed solutions?
GGok so it works...
Ginteresting
GGI wonder if we can simplify this
Gyeah this could work...
Gthere's a lot of problems though, mainly being that all environment variables are exposed and could potentially break things, and the command has to be run with
sudo -E so it makes things difficultGthe
DBUS_SESSION_BUS_ADDRESS doesn't seem too hard to obtain with just needing the UID and usernameG
Gfixed the simply justfile issue
Gproblem becomes how do we get the right user to run the notifications on
Gsorry, got a little caught up here, moved to: https://discord.com/channels/1072614816579063828/1126164331759931392/1149555476506357880
KCheck out
just --chooseKbig fan
ZMy heart almost skipped a beat reading "zerolayer" as I was about to read it as "zeroslayer".
XI don't know about the README fetch stuff, the docs already exists in the repo, it's intended that you can read it in your code editor or smth while writing the config. The docs changes that need to be done are changing the parts that refer to the config format and adding a mention of the modular system.
0
Jok ya'll, I'm going offline for a bit for a work trip (containerdays in hamburg!). I think we've got everything set so if something happens and it's blocking on me then we have a bus factor that needs to be removed, but we should be ok!
NLol you’re in Hamburg????
N
Bthe land of my people. When I was in the army (way back in the day) I spent several weeks in Hamburg supporting Desert Shield operations. I looked in the phone book (that's how long ago it was) and there were PAGES of Ketelsens there. Confirming the family oral histories.
NI live there lol
JThat reminds me -- did people in Hamburg invent the hamburger? I know there's the hamburg steak, but the hamburger itself seems to have a more contested origin
JThis video makes it sounds like the hamburger was clearly invented in hamburg, but everything I've read so far suggests that it was more likely that people who immigrated from hamburg to NYC would eat the familiar hamburg steak between two slices of bread or buns https://www.youtube.com/watch?v=ZbepW6dc4tg
JPM me if you wanna hang out with some containernerds
BYeah, I wanted to pull the nvidia/main possible split discussion and also how triggering builds could work into this channel
B@akdev we want multiple triggers outisde of just other workflows like when other repos(ustream ones get something pushed to)get updated or when image gets updated(again upstream) or when package gets updated...
Bit at least includes config > akmods > main > nvidia and maybe some new framework image
Amain build completion should trigger nvidia build, that’d be easy to easy way - but this has a limit of 3 levels deep
BAs you said workflow has easiest to do as its a part of github rest we would have to trigger via workflow_dispach
BBigpod: are you suggesting https://github.com/ublue-os/main/issues/25#issuecomment-1707419621 that we don't do a build at all unless upstream fedora/rpmfusion have actual updates in their repos for packages we install?
BNo what the thinking is that if update to package occurs we can automatically rebuild minutes after it hits
Bah, ok
so still do daily builds
but also monitor for key packages upstream and additionally trigger on those?
so still do daily builds
but also monitor for key packages upstream and additionally trigger on those?
BYes
Bkeep an eye out because it can take few hours, sometimes many to actually get a package that is marked stable from testing
BI'm kind of interested in the basics of this new "builds" repo ... like it could have an action to trigger our builds serially, and wait for each to succeed, then spin up the next
Bthat could get around the 3 level deep concern
AI think monitoring releases requires a long running service
