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
BNot realy all you need is somewhere to store hashes/versions/such data
AI guess but in that case you still need cron
Bwell actiond can do that
BBut it would be lot easier if i could do azfunc or lambda but in theory actions should work
AI believe release-monitoring.org actually pushes to an activemq queue
AIf you could subscribe to that you’d just need to dispatch builds
0If anyone ran into same issue, i created a thread for it and posted solution in there.
0Updated the tutorial to support nvidia cuda.
https://gist.github.com/theonlyfoxy/d7a3d8e90493a00faaef1cbd782da196
https://gist.github.com/theonlyfoxy/d7a3d8e90493a00faaef1cbd782da196
Jthis is awesome, would you consider working on this to submit it to the documentation? It'd be amazing.
BI need to get comfortable with the devcontainers workflow... i think it's the step which may make dev work better for me
XThe startingpoint rewrite PR is no longer a draft. Reviews this way ->> https://github.com/ublue-os/startingpoint/pull/135
XI also have a small PR for the website to be merged at the same time ->> https://github.com/ublue-os/website/pull/445
XHuge thanks to @Gerblesh for the contributions on this one.
0Yea. It significantly enhanced my dev workflow.
BGitHub
(sorry on a plane will add more detail later) We may have a volunteer to help do this after I announced the project on the framework forums. Just outlining what we'd need to do this. The TLDR i...
MHas there been any work on getting systemd-homed to work? It's seemingly enabled by default and the pam modules are easy enough to edit to work with authselect. However SELinux seems to be a blocker due to the wrong "profiles" not sure of name haven't used SELinux much before.
If I put SELinux into permissive mode it works.
I think systemd-homed would probably be a good fit for this model. But I guess it probably still a bit immature for user creation from the installer
If I put SELinux into permissive mode it works.
I think systemd-homed would probably be a good fit for this model. But I guess it probably still a bit immature for user creation from the installer
E@akdev any inventive ways for how we could set inst.resolution=1280x800 just for Deck here? Since kickstart isn't being pulled in here, I'm not sure how we'd handle isolating the Deck
https://github.com/ublue-os/lorax-compose/blob/main/lorax-templates/efi.tmpl
https://github.com/ublue-os/lorax-compose/blob/main/lorax-templates/efi.tmpl
Anot really, I need to learn a bit more about mako templates
only idea I've had is using env vars but it's kinda bad
only idea I've had is using env vars but it's kinda bad
AI want to expose functionality to override grub with your own template and also inject files but not sure how to it yet
GAlso curious, is everything in place to make an offline M1 Mac ISO? We have lorax compose, so we can easily make the ISO a different architecture, we just need to build an arm image
GI'm guessing we can also install different packages/drivers in the installer with lorax
GThough idk, need to look into lorax more
ANot at all, there's not even apple silicon ostree images
GIt's a different bootloader right?
AI made one and was actually able to boot but my Macbook was really slow
ALike 1 second on the clock would take minutes to pass
GAnd kernel + other packages
AThose images still use grub but they chainload from m1n1
AGAh
GSo still a lot of work to be done
AYeah, it's difficult to debug because I have no idea what I'm doing lmaoo
Am1n1 chainloads to uboot and that chainloads to grub
