If we (community) want to get more opinionated with `main` and push a firstboot experience, sure we

If we (community) want to get more opinionated with

main

main

and push a firstboot experience, sure we can, but I am personally very pleased with the approach that was taken.

main/nvidia

main/nvidia

main/nvidia

main/nvidia try to stays "stock-ish" so there's an improved foundation on which all the cool/custom stuff can be built.

Bbsherman I should clarify... when I say "sister to bluefi" I don't even mean as opinionat...

Michael•5/12/23, 4:38 PM

I 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.

MMichael I think I got ya. If I was going to focus on one, I'd want to work on something ...

bshermanOP•5/12/23, 4:40 PM

if 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

Bbsherman if the driver is available as akmod, *maybe* it could go in main 😄 we do want ...

Michael•5/12/23, 4:42 PM

I 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.

Bbsherman If we (community) want to get more opinionated with `main` and push a firstboot ...

Arcitec•5/12/23, 4:43 PM

I 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 startingpointstartingpoint 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

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/*.shvauxite-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.

MMichael I don't think it is haha. But that may be something I have to look at. I have be...

bshermanOP•5/12/23, 4:44 PM

it 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.

AArcitec I totally agree with you on that. Firstboot being the "scriptable/hackable" one,...

bshermanOP•5/12/23, 4:45 PM

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?

Bbsherman 💙 for all but the question at the end LOL. i'm not sure what you mean by mov...

Arcitec•5/12/23, 4:47 PM

It 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/*.sh

scripts/pre/*.sh

and

scripts/post/*.sh

scripts/post/*.sh

vauxite-recipe.yml

vauxite-recipe.yml

: Also runs

vauxite.sh

vauxite.sh

which in turn runs

autostart.sh vauxite/${SCRIPT_MODE}

autostart.sh vauxite/${SCRIPT_MODE}

, which would cause it to execute every script in

scripts/vauxite/pre/*.sh

scripts/vauxite/pre/*.sh

and

scripts/vauxite/post/*.sh

scripts/vauxite/post/*.sh

at the appropriate stages.

It's doable. I am not saying it's a good idea though. But it would mean that we work on 1 build system for everything.

Arcitec•5/12/23, 4:48 PM

But it's such a lofty idea that I didn't even plan it! I am not sure I even like it.

Arcitec•5/12/23, 4:49 PM

Everything you've currently automated in main+nvidia could definitely be ported to this.

Arcitec•5/12/23, 4:49 PM

But what's the value of doing that? Beyond having to maintain only 1 system.

Arcitec•5/12/23, 4:50 PM

bshermanOP•5/12/23, 4:50 PM

I 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

Arcitec•5/12/23, 4:51 PM

Yeah. 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!

AArcitec It was created to be flexible but wasn't made with main+nvidia in mind. It could...

fiftydinar•5/12/23, 4:52 PM

I just want to remind you of this article:

https://ometer.com/preferences.html

fiftydinar•5/12/23, 4:52 PM

I don't think that having tons of variants in 1 ISO is a good idea.

fiftydinar•5/12/23, 4:53 PM

Oh, build system

fiftydinar•5/12/23, 4:53 PM

Nothing, ignore

Arcitec•5/12/23, 4:53 PM

Haha yes it's just the build system.

j0rge•5/12/23, 5:28 PM

@bsherman can you mark your PR as a draft? that way notification filters work instead of doing WIP in the changelog

Jj0rge @bsherman can you mark your PR as a draft? that way notification filters work in...

bshermanOP•5/12/23, 5:29 PM

yes. good call.

Jj0rge @bsherman can you mark your PR as a draft? that way notification filters work in...

bshermanOP•5/12/23, 5:30 PM

umm... trying to find where i do that

bshermanOP•5/12/23, 5:30 PM

ah, found it... sneaky text

Arcitec•5/12/23, 5:33 PM

@bsherman Yes I had the same issue. That draft link is very sneaky!

bshermanOP•5/12/23, 5:35 PM

i have some kind of RubberDuck

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

AArcitec I'm also undecided whether we should install the minimalistic `/etc/profile.d` s...

xyny•5/12/23, 5:35 PM

Looking good. I wouldn't mind a leftover file in

/etc/profile.d/?

/etc/profile.d/?

~/.config/autostart

~/.config/autostart

, but maybe just having one in

/etc/

/etc/

feels better than having one in

~/

~/

. The only con I see in that is the fact that the "yafti toggle" wouldn't disable everything yafti-related in the build.

Xxyny Looking good. I wouldn't mind a leftover file in `/etc/profile.d/?` or `~/.confi...

Arcitec•5/12/23, 5:37 PM

Great 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

~/.config/autostart

~/.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.

Arcitec•5/12/23, 5:39 PM

I'll do some tests in a VM to see what's the impact of dead autostart symlinks.

xyny•5/12/23, 5:40 PM

I 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.

xyny•5/12/23, 5:40 PM

But maybe I don't mind that. I'd just like to make sure that every bit of it's code is documented well.

Arcitec•5/12/23, 5:40 PM

It's still lean and thin. Thinner than before

Arcitec•5/12/23, 5:41 PM

No more need to edit build.sh. And soon being able to remove yafti if wanted. Leaner in other words

xyny•5/12/23, 5:41 PM

Well, it was arguably at it's thinnest when the recipe had two config values;

rpms:

rpms:

and

flatpaks:

flatpaks:

Arcitec•5/12/23, 5:41 PM

Yeah but then it was too opinionated and pre-installed stuff, so swings and roundabouts.

bshermanOP•5/12/23, 5:42 PM

I think startingpoint is still pretty lean

especially compared to bluefin or my custom image, etc

xyny•5/12/23, 5:42 PM

And sure, you can do more things from the

recipe.yml

recipe.yml

and you don't have to get into the weeds, the codebase is just a bit7 more complicated

Bbsherman I think startingpoint is still pretty lean 😉 especially compared to bluefin o...

xyny•5/12/23, 5:42 PM

Sure, it's a startingpoint after all

Arcitec•5/12/23, 5:43 PM

Yeah, the autorun functionality might be what you're thinking of. It's pretty easy to understand it though.

Arcitec•5/12/23, 5:43 PM

scripts:
  # "Pre" scripts run very early in the build, immediately after your custom
  # repos have been imported (so that you can access those repos if necessary).
  pre:
    # Automatically runs script files within "scripts/pre/".
    - autorun.sh
    # Manually listed scripts.
    # - example_pre.sh

  # "Post" scripts run at the end of the build process.
  post:
    # Automatically runs script files within "scripts/post/".
    - autorun.sh
    # Manually listed scripts.
    # - example_post.sh

scripts:
  # "Pre" scripts run very early in the build, immediately after your custom
  # repos have been imported (so that you can access those repos if necessary).
  pre:
    # Automatically runs script files within "scripts/pre/".
    - autorun.sh
    # Manually listed scripts.
    # - example_pre.sh

  # "Post" scripts run at the end of the build process.
  post:
    # Automatically runs script files within "scripts/post/".
    - autorun.sh
    # Manually listed scripts.
    # - example_post.sh

Arcitec•5/12/23, 5:43 PM

Plus the great

scripts/README.md

scripts/README.md

file which explains in depth.

https://github.com/ublue-os/startingpoint/blob/main/scripts/README.md

Arcitec•5/12/23, 5:43 PM

I don't see any issues with it.

What could be improved?

xyny•5/12/23, 5:45 PM

It'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.

Arcitec•5/12/23, 5:46 PM

Thank you too.

Oh and regarding the autostart script, I'll get to testing the dead symlinks now to see what the OS says!

Xxyny It's pretty good. Good job Arcitect, always looking to improve everything. We'll...

bshermanOP•5/12/23, 5:46 PM

the moon? lets go to Mars!

Bbsherman the moon? lets go to Mars!

xyny•5/12/23, 5:48 PM

I was bout to write that, but then I remembered this asset gamblers and startup founders saying of To the moon , routinely sarcastically used by Ben Awad on YT.

Arcitec•5/12/23, 5:50 PM

@hermmm Alright so at least on

gnome-session

gnome-session

it only leads to a silent syslog entry:

WARNING: Desktop file /var/home/johnny/.config/autostart/foo.desktop for application foo.desktop could not be parsed or references a missing TryExec binary

WARNING: Desktop file /var/home/johnny/.config/autostart/foo.desktop for application foo.desktop could not be parsed or references a missing TryExec binary

I'll try KDE too. If both are fine with missing links, I'd say it's tested enough to be okay leaving an orphan?

Edit: KDE gives a silent syslog warning too, from

systemd-xdg-aut

systemd-xdg-aut

which says

/var/home/johnny/.config/autostart/foo.desktop: stat() failed, ignoring: No such file or directory

/var/home/johnny/.config/autostart/foo.desktop: stat() failed, ignoring: No such file or directory

bshermanOP•5/12/23, 5:50 PM

@Arcitec I'll add this to the paths proposal discussion after we chat but... how passionate are you about the "no clunky paths"?

I'm looking at how to move from

/usr/share/ublue-os/ublue-os-update-services

/usr/share/ublue-os/ublue-os-update-services

/usr/share/ublue-os/update-services

/usr/share/ublue-os/update-services

and I don't like what I'm seeing.

It's due to the RPM spec, and I really like the cleanliness of the spec as is.

See this line for example: https://github.com/ublue-os/config/blob/main/rpmspec/ublue-os-update-services.spec#L49

%attr(0644,root,root) %{_datadir}/%{VENDOR}/%{NAME}/%{_sysconfdir}/rpm-ostreed.conf

%attr(0644,root,root) %{_datadir}/%{VENDOR}/%{NAME}/%{_sysconfdir}/rpm-ostreed.conf

The

%{VENDOR}

%{VENDOR}

ublue-os

ublue-os

and the

%{NAME}

%{NAME}

ublue-os-update-services

ublue-os-update-services

.

edit: add local context

AArcitec @hermmm Alright so at least on `gnome-session` it only leads to a silent syslog ...

xyny•5/12/23, 5:50 PM

Sure!

Bbsherman @Arcitec I'll add this to the paths proposal discussion after we chat but... how...

bshermanOP•5/12/23, 5:52 PM

I don't want the re-name the RPM as it should be

ublue-os-update-services

ublue-os-update-services

in the RPM database.

Bbsherman @Arcitec I'll add this to the paths proposal discussion after we chat but... how...

Arcitec•5/12/23, 5:52 PM

Ew. I see the point but I think there's a way in RPM specs to create dynamic variables, where we could add one that's something like

%SHARED_DATA_PATH=${NAME:/-ublue-os/}

%SHARED_DATA_PATH=${NAME:/-ublue-os/}

(pseudocode)

Arcitec•5/12/23, 5:52 PM

I remember seeing people do something dynamic like that to get the first 7 characters of Git commit hashes