75 Replies
https://github.com/ublue-os/bazzite/commit/46a3e7508e2ebb59836cfaad328754c6751b788a
Looks like Kyle was busy last night with some dynamic elements + a tips file.
Some ideas from last night:
- show a warning when image date > 30 days
And then the tips thing will allow us to dynamically build a collection of built in useful stuff
I was thinking it might be annoying to show it on every terminal open since I go through a ton a day, maybe a setting showing it only it's changed so we don't get too spammy
Sorry If it wasn’t clear, the thing I built for config only displays a static user-motd
But. Maybe we should change the hard coded path to display to be something in /etc (eg, /etc/user-motd) then the stock (from config) script will always work and stuff like @Kyle Gospo did for dynamic tips can run from a second script and overwrite the user-motd file
no opinions on design other than we should think about tips. Like should we have them in config so that they hit everybody and the bazzifin add theirs on top or do we leave them decoupled?
I'm kind of leaning towards keeping them seperate so it's more targetted to each user story but also see the value of having one place in config to do like "warning: there are major shifts happening to foo, check this link" if we ever need it. For things like say, the
just
transition
(Just spitballing ideas)I made the folder generic and the file it picks out of it is at random
That way you can continue stacking on more tips as your images get more complicated
So a base tip file totally makes sense
man this turned out so good. ❤️ ❤️ ❤️ ❤️ ❤️
So… why aren’t we just using the coreos utility if we are reinventing the same thing?
And apologies for not being more in touch with this today. A lot of family stuff.
no worries
it was actually way more complicated once bob looked into it
and it accounts for like, sshing in or not, etc.
and ubuntu's was messier
so it was just like "can we just cat/glow a markdown file?"
Worth it.
SO WORTH IT.
@Kyle Gospo lmk when yours is ready and we'll start a thread
(in the forum)
or feel free to kick it off
It's live
on a fresh vm, interesting
brian did a fresh install and got the real one. I'm just an unreproducable mess today
"skill issue"
Weird though, do you have a tips file?
Should be able to pick apart the shell script
it's ok I'm not sweating it, it'll be easier to find all this when the installer is ready
actually ...
my email blew up with commits today "thanks Kyle?"
in the end, i still haven't seen the final code in bluefin/bazzite... i'm confused if what i built in config was wrong or what?
@j0rge @Kyle Gospo
and just dealing with more family drama... so not a lot of energy to look at this stuff today
don't even sweat it
we're in chat if you wanna hang tho
Kyle explained to me that we just slap on top of what's in config, so yeah, we needed that. 😄
M V P
that was a cool "weekend project" that's basically done and these tips are gonna be awesome
Still using your base, everything I've done was just markdown formatting
Much appreciated
and each opening offers a new tip, and we can use markdown in the tips file
so like, we can put all sorts of links to docs in there
it'll be baller
@j0rge
Light theme and tips working
@Noel
Sick! Could you grab some screenshots? Or feel free to update the post.
Can do
ah, ok, i see what you did here... and this is what i meant...
if our primary consumers of user-motd (bazzite and ublue) are going to override the
profile.d/user-motd.sh
script... then it's wrong... we should agree on a shared solution.
and in retrospect, i think i heard @j0rge talk about wanting dynamic tips, but when i asked for feedback, someone it was agreed to store a static file in /usr/share/ublue-os (an immutable directory), rather than /etcIf we could simply agree on /usr/libexec/ublue-motd as a provider, then we could stop overriding that user-motd script today
only reason it's changed
i didn't think there was disagreement when we built the thing 😉 but you left and didn't give feedback 😉
didn't say there was 😛
just talking about how we can simplify/standardize a bit
so more of it is in one place
a default tips file may make sense too
what bugs me is I built something, its mutated all within a couple days, but also been announced at the same time as a new feature... so now if we change it, it's like we are breaking something
I like what you are doing, so I think we could change to be more like this, but now there's naming inconsistencies
we're using bazzite.md./bluefin.md as the motd names, so I don't mind fixing the naming inconsistencies one bit
honestly should just be motd.md
sorry man I was pushing to move fast, we should have slown down and gotten more concensus. I apologize.
or template.md
i'm not 😡 angry 😄
just 🐛 bugged
right now we're the only two consumers of it, so I don't think any change is breaking and I'll put in the time to standardize
on whatever we agree on
I chased the shiny.
i hope this is clear, i'm happy with the progres... but i very much want to work more closely with you guys one the things that cross main+bluefin+bazzite
and I probably could have helped us improve this in realtime if my day wasn't completely full yesterday, so my apologies for being absent and then coming back to gripe
nah don't apologize for family stuff, let's not make this a job
fair
Here is what I have gathered that will hopefully help things going forward:
I think if we know there is going to be something that crosses main, Bluefin, and Bazzite as a feature, we should make sure it is implemented in the same way everywhere.
That way, we don't repeat work unnecessarily. I think it's good to lab things in the downstream, but before any announcement, it would be good to get consensus. Am I tracking?
yeah and tbf if we had do overs we'd have arranged them differently but whatever.
my memory isn't even 100% from what we did on Saturday, but I thought we were doing that... i guess the main difference is we believed we had concencus on how to move forward and just did it
honestly, i'm mostly upset with my self... if we'd put the
cat'ed
user-motd file in /etc/ ... then Kyle could have solved tips without needing to override user-motd.sh
and that's probably what bugs me most, I think i knew betterWe have ~90 days, no problemo
I was going to run an ad for Ubuntu Pro in mine.
what if we really just do that? change the path of
/usr/share/ublue-os/user-motd
to be /etc/user-motd
and then the cool tip efforts Kyle did could simply be in profile.d/ublue-user-motd.sh
which would run and update /etc/user-motd
before profile.d/user-motd.sh
runs? Then the more dynamic "tips" solution doesn't clobber the simpel solution, but builds on it instead?
I'm happy to Draft PR this all the repos: config, bazzite, bluefin
and we can consider them togetherI think I prefer the executable, I don't want to write to /etc every time a terminal is opened
the simple solution makes sense, but supporting an executable as well could be cool
J0rge and I both had the problem that generating the MOTD from the containerfile resulted in an empty file
oh? I thought that was working
made the file but the contents were
see, i missed a very important thing!
glow moment
good news is it looks really good, and we're still using 100% of the just stuff you did
🙂
so, from the base you gave us
these are the material changes:
well, thank you for clarifying the problems for me... i really had missed the fact there was a full on failure to write contents in the file from image build (i'd like to solve that) and... i can see your point about not wanting to write a file per-terminal load
user-motd.sh becomes..
which is the same as before minus calling something in libexec
yep, i had to read the latest version of a PR to see that
and libexec is where all the complicated shit happens
so...
basic concept is using sed to replace filler text in the md
and then piping that into glow
could copy this same concept but just make ublue-motd do nothing more than display in the config repo
and then bazz/blue are only changing that, which they'd need to since bazz/blue have that image-info.json file
and main doesnt
plus any custom dynamic content would also need to be in there anyway
so... your "dynamic" stuff is fine... because i see that as the bit bazzite/bluefin controlling that
should we try something like:
??? so, anyone wanting to implement fancy stuff can provide
/usr/libexec/ublue-motd
of their choice, else, if an implementer wishes to have a simple user-motd they can?sounds great to me
i'll tinker a bit
then share some PRs... thanks for the feedback @Kyle Gospo
version of it for fish
do we ship a "fish.d"?
we do not, but bazzite does ship fish so I'm adding it on my end
sharing in case you wanted it
sure, happy to add it in my PR to bazzite
actually let's skip that one, it'd conflict
we need to replace the built in fish_greeting file due to it having it's own very simple motd
better done w/ a COPY in a containerfile
i'll just handle the bits i can test and i'll let you handle fish 😄
GitHub
feat: add more flexibility to user-motd by bsherman · Pull Request ...
Changes are:
allow /usr/libexec/ublue-motd as executable, dynamic motd
change to /etc/user-motd for static motd, allowing choice to customizate user-motd at runtime if pre-generated is not desired
And for bluefin/bazzite i just did this:
https://github.com/ublue-os/bluefin/pull/855
https://github.com/ublue-os/bazzite/pull/722
nice
that's the updated version? 😄
yup!
thanks much