Completely understand, if I end up getting into ublue, then I'll have to consider it.
Completely understand, if I end up getting into ublue, then I'll have to consider it.
AYeah it's the startingpoint repo, which is the only one that auto-starts yafti at the moment. It's super fragile at the moment, so all these changes are necessary. It seems like a solid plan to me but perhaps I'm missing some small change that could make it even better.
AOh you responded to the restructuring discussion? I'll check now
AI read, that sounds great. And yeah don't burn yourself out. We don't need to move everything at once. One small file at a time is enough. 
AI'll reply there now though
BI should clarify... when I say "sister to bluefi" I don't even mean as opinionated and stylized as bluefin... though, it could be what you want it to be
I should probably say more like a sister to
The idea in my head, it
Another thought... if we could work with System76 to adjust how they do this (eg, use akmod instead of kmod) and maybe host a repo of RPM packages instead of requiring a lot of local
I should probably say more like a sister to
startingpoint or nvidiamainThe idea in my head, it
ublue-os/system76 would be the image for users of that hardware, and other downstream images could in turn use it.Another thought... if we could work with System76 to adjust how they do this (eg, use akmod instead of kmod) and maybe host a repo of RPM packages instead of requiring a lot of local
makemain
Byeah, nutshell summary of my thoughts... what I see in your proposals is cleanup, standardization, forward looking for automation and subsequent projects to have a good pattern to follow. good stuff.
But also, I'm happy the custom first boot stuff is staying in starting point for the moment.
But also, I'm happy the custom first boot stuff is staying in starting point for the moment.
BIf we (community) want to get more opinionated with
mainmain/nvidia try to stays "stock-ish" so there's an improved foundation on which all the cool/custom stuff can be built.
MI think I got ya. If I was going to focus on one, I'd want to work on something for my capture PC first. Needs a driver that doesn't belong in main but that I would need to run ublue on a pc I would use for capturing. Maybe a "creator" edition or something. Time will tell. Long ways to go before I'm anywhere ready to try it haha.
Bif the driver is available as akmod, maybe it could go in main 
we do want some hardware enablement there, it's just a bit vague as still only do that via udev rules and nvidia
we do want some hardware enablement there, it's just a bit vague as still only do that via udev rules and nvidiaMI don't think it is haha. But that may be something I have to look at. I have been installing via dkms. Don't think it would ever be a fit for main haha.
Edit: I believe the source is available at least.
Edit: I believe the source is available at least.
AI totally agree with you on that. Firstboot being the "scriptable/hackable" one, and main + nvidia being the "clean cores" is a great setup.
The way I've been modernizing
The only thing missing is a way to create a
Example:
I dunno if it's worth pursuing such a feature to make it possible to move main + nvidia to the same system as startingpoint though. It'd be nice for users but not sure if there's value for us.
The way I've been modernizing
startingpoint is almost at the point where main + nvidia could be refactored to be scripts for it. It's now flexible enough to be able to run a core set of scripts/actions for every image, and then having per-recipe scripts listed for the specific flavors.The only thing missing is a way to create a
recipe.yml matrix where there's a "core recipe" and then the per-variant changes such as removing certain packages, adding extras, etc. It could already be implemented if the flavors used scripts for those per-flavor changes though.Example:
vauxite-recipe.yml: runs scripts/vauxite/*.sh in addition to the common scripts.I dunno if it's worth pursuing such a feature to make it possible to move main + nvidia to the same system as startingpoint though. It'd be nice for users but not sure if there's value for us.
Bit is in the back of my head to solve the dkms build problem... i started once, but life is busy... there are definitely a few things out there we need...
and I will say, I have built dkms for silverblue OCI, but my roadblock was getting the secure boot signing done... and for ublue specific, we need it to work for all users...
so, priorities... getting akmods done first, then eventually solving the dkms issues.
and I will say, I have built dkms for silverblue OCI, but my roadblock was getting the secure boot signing done... and for ublue specific, we need it to work for all users...
so, priorities... getting akmods done first, then eventually solving the dkms issues.
B
for all but the question at the end LOL. i'm not sure what you mean by moving "main+ nvidia" to the same system as starting point?AIt was created to be flexible but wasn't made with main+nvidia in mind. It could be improved on that front but it would already be really easy to do. Example:
- Every image would run all scripts in
scripts/pre/*.shandscripts/post/*.sh vauxite-recipe.yml: Also runsvauxite.shwhich in turn runsautostart.sh vauxite/${SCRIPT_MODE}, which would cause it to execute every script inscripts/vauxite/pre/*.shandscripts/vauxite/post/*.shat the appropriate stages.
ABut it's such a lofty idea that I didn't even plan it! I am not sure I even like it.
AEverything you've currently automated in main+nvidia could definitely be ported to this.
ABut what's the value of doing that? Beyond having to maintain only 1 system.
A
BI think i'm tracking with you. But I think we definitely just do the cleanup/standardization stuff you've suggested first... and you can make these types of improvements in starting point... and if we then see value after you have it smoothed out there, it could be a discussion/proposal on making the change to main
AYeah. I am just asking your thoughts since I am not sure I like the idea at all. Just saying that it's possible. But yeah, time to focus on smoothing out the standardization first!
But yeah, time to focus on smoothing out the standardization first!
FFI don't think that having tons of variants in 1 ISO is a good idea.
FOh, build system
FNothing, ignore
AHaha yes it's just the build system.
J@bsherman can you mark your PR as a draft? that way notification filters work instead of doing WIP in the changelog
Byes. good call.
Bumm... trying to find where i do that
Bah, found it... sneaky text
A@bsherman Yes I had the same issue. That draft link is very sneaky!
Bi have some kind of 
syndrome... often i have to type the thing I can't figure out (like that draft sneaky text) and then i'll immediately find the solution.
it's humbling
syndrome... often i have to type the thing I can't figure out (like that draft sneaky text) and then i'll immediately find the solution.it's humbling
XLooking good. I wouldn't mind a leftover file in
/etc/profile.d/? or ~/.config/autostart, but maybe just having one in /etc/ feels better than having one in ~/
AGreat to hear.
Yeah the "it won't disable everything" is what I dislike too.
I am also unsure what actually happens when there is a dead symlink in
Either way I am trying to think of ways to make sure the users see zero errors if they move between flavors of ublue. Some that use it and some that don't.
Yeah the "it won't disable everything" is what I dislike too.
I am also unsure what actually happens when there is a dead symlink in
~/.config/autostart. If the OS complains or just moves along like nothing.Either way I am trying to think of ways to make sure the users see zero errors if they move between flavors of ublue. Some that use it and some that don't.
AI'll do some tests in a VM to see what's the impact of dead autostart symlinks.
XI feel like startingpoint is evolving so much (into a way more customizable durection, though), that it's kinda losing my original vision for it; being a lean and thin template where all code is thoroughly documented, easy to grow and stretch, but understandable in it's entirety. It's turned more into a framework-as-a-template, or it's turning. from kickstart.nvim to NvChad.
XBut maybe I don't mind that. I'd just like to make sure that every bit of it's code is documented well.
AIt's still lean and thin. Thinner than before
ANo more need to edit build.sh. And soon being able to remove yafti if wanted. Leaner in other words
XWell, it was arguably at it's thinnest when the recipe had two config values;
rpms: and flatpaks:.AYeah but then it was too opinionated and pre-installed stuff, so swings and roundabouts.
BI think startingpoint is still pretty lean especially compared to bluefin or my custom image, etc
especially compared to bluefin or my custom image, etcXAnd sure, you can do more things from the
recipe.yml and you don't have to get into the weeds, the codebase is just a bit7 more complicatedXSure, it's a startingpoint after all
AYeah, the autorun functionality might be what you're thinking of. It's pretty easy to understand it though.
AAPlus the great
https://github.com/ublue-os/startingpoint/blob/main/scripts/README.md
scripts/README.md file which explains in depth.https://github.com/ublue-os/startingpoint/blob/main/scripts/README.md
AI don't see any issues with it. What could be improved?
What could be improved?XIt's pretty good. Good job Arcitect, always looking to improve everything. We'll get to the moon and back with that attitude in no time.
AThank you too. Oh and regarding the autostart script, I'll get to testing the dead symlinks now to see what the OS says!
Oh and regarding the autostart script, I'll get to testing the dead symlinks now to see what the OS says! Bthe moon? lets go to Mars!