i will see if i can make something more ublue generic then, is there a specific repo this would fit
i will see if i can make something more ublue generic then, is there a specific repo this would fit properly into?
Jnot sure, I'm not familiar with most of this heh
Jlet's see what the others say, I'm sure we can find the best place
Hok, right now this is just some logic i wrote into bazzite-hardware-setup which does a few things based on the users hardware, notably kargs and initramfs argument related things
Hi noticed a while back it would wipe all my initramfs and dracut arguments when the hw version changed 
EI would personally recommend config
EPackage hardware setup as an RPM
Hwell i know nothing about packaging RPMs, but it shouldnt be a problem to decouple the initramfs part of hardware setup and make it its own thing to be used across ublue for things like hardware-setup and other boottime configs
EIf we can get this genericized, I don't mind packaging it. I think that'll ultimately be an easier way to distribute it. Would be cool to consolidate initramfs stuff and possibly other helpers so that people can architect their own hardware setup implementations more easily
J
Hmaybe the "solution" here is to take a page out of windows book and make a "brew shell" that has brew first in the path and thats the only way to use brew directly (this more a joke and last resort workaround i guess)
(this more a joke and last resort workaround i guess)Hat least i remember that was a thing back when i had to use windows
JI was thinking a container but I'd rather not have to do that
Jor maybe putting the homebrew $PATH statement in one of the other dotfiles but the internet's full of confusing statements so it could be one or any combo of .profile, .bashrc, etc.
Hback when i did a lot of python version dependent development i had aliases to set different paths depending on which python venv i had to use so i would just have 
$REALPATH, $PATH27, $PATH3 and $PATHCUSTOM and the aliases just exported those depending on what i needed. it was messy but i needed a solution fast to just get working Hi dont really think there will be a one solution fits all when it comes to that brew issue just because of how environment variables are handled in all platforms
Jwell we only have to fix it for ourselves
Jlike maybe in a terminal config
Hi know, but most platforms handle envs in the same way, you either have it and whatever is first takes precedence or you dont have it (which is why you would have shells with correct paths applied for things like git bash, visual studio, etc in windows)
also because windows for some reason has i believe a 256 character limit for its $PATH or something weird like that
also because windows for some reason has i believe a 256 character limit for its $PATH or something weird like that
Joh I think we might be past that already lol
Hyeah but i know that was a limitation for windows as i hit that limit very fast when i just tried to make my workflow work on windows back when i did dev work for a company
Hthey got tired of trying to force windows to work for me they just gave me permission to use linux where i just set up my dev environment in less than 5 mins
Hi think the options might be
- brew init command (activate brew $PATH) when needed
- dedicated "brew shell" using whatever shell the user has configured
- container/distrobox (adds more hoops though)
Hneither is a good solution
Mor encourage people to use nix profiles instead, which don't expose binaries of intermediate dependencies to the environment
Jno thanks
Mi don't think you'll get homebrew to fix its broken deployment model
EBrews environment/path would need to precede the hosts. Otherwise it will always take priority. Unfortunately, I think the best way around that is a container
Jyeah I'm always back to the root problem of not having a terminal with container support. 
EI was just thinking about the same thing
Jlet's see what the podmansh folks come back with I guess, dan seemed interested in at least investigating the use case
EWould be awesome
JI posted on the flathub discourse, maybe there's a way to tell flatpak to just ignore that stuff
Jok after work I'll pr it out of the justfile and then just do a brew container
ESounds good!
JJI'll just put this in a container in a distrobox
KCan you add that as part of this PR? Then I can update Bazzite's yafti to point there at the same time
KThe distrobox change I mean
Jit'll take me a while to do it
JI'd like to get this in to prevent people from installing it easily in the meantime while I make a post
Jdistrobox just won't accept the brew box ootb, we gotta do some adjustments, etc.
JHomebrew distrobox thread
CStatus update on the image switcher app
C- polish UI (easy-moderate)
- add menu options (trivial)
- replace print statements with variables (trivial)
- write 3 lines to build a string (trivial)
- figure out how to live-update the rebase command (moderate)
- write 3 lines to connect the rebase button (trivial)
- write function to run rebase command (moderate)
- write documentation (easy)
- publish flatpak (easy-moderate)
- test
CThe four dropdowns work, and output the necessary data. The two links work. Most of the UI is raw XML, which should be possible to reverse engineer with much nicer Python now that I know a lot more about how these things work. With nice formatting, this app is a template plus 16 lines of code. It is really 8 lines of code.
Him guessing "spin" also contains special builds like -asus and -surface?
C(Incomplete, trivial to add to:)
Spin is Main/Bazzite/Bluefin
Desktop is Gnome/KDE/Sway
GPU drivers is Open Source/Nvidia
Hardware is General/Surface/Asus/Deck
Spin is Main/Bazzite/Bluefin
Desktop is Gnome/KDE/Sway
GPU drivers is Open Source/Nvidia
Hardware is General/Surface/Asus/Deck
Hoh i didnt even see the hardware part
Him pretty much still waking up here
CI can add a couple lines of conditional logic to make sure the user is informed of whether their current selections add up to a valid rebase command
