ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
<chadmed>
hmm yep looks like its trying to load zink
<chadmed>
i dont think mesa was built with VIDEO_CARDS=asahi
<leio>
that zink stuff is usually just a red herring warning in my experience, especially in that form where it says it doesn't have zink available
<chadmed>
do apple_dri.so and asahi_dir.so exist in /usr/lib64/dri?
<leio>
I'm guessing the xorg in there is because sddm doesn't do wayland or something?
<nyaomixyz>
asahi_dri and apple_dri are there
<chadmed>
sddm supports wayland sort-of, it needs manual config and you need to remove agetty from tty0 in inittab
<chadmed>
PITA
<leio>
yeah, nvm, plasma looks to be in wayland
<nyaomixyz>
correct sddm is not yet defaulting to wayland but since i am now starting from terminal this shouldn't be an issue
* leio
sneaks off to bed, gl
<chadmed>
can you try rebuild mesa and libdrm?
<chadmed>
everything in the logs looks fine tbh
<nyaomixyz>
and yet for some reason llvmpipe remains
<nyaomixyz>
no dice
<nyaomixyz>
not even MESA_LOADER_DRIVER_OVERRIDE=asahi works
<nyaomixyz>
MESA_LOADER_DRIVER_OVERRIDE=apple works, but it's a slideshow
<nyaomixyz>
asahi -> llvmpipe
chadmed_ has joined #asahi-alt
ipatch_ has quit [Quit: WeeChat 4.2.1]
<nyaomixyz>
tried to specify use flags by hand but it amounted to nothing
possiblemeatball has quit [Quit: Quit]
zerdox has quit [Ping timeout: 480 seconds]
<nyaomixyz>
chadmed: why the hell all the dri libs have the same md5sum
<psykose>
they're hardlinks
<psykose>
gallium is one library
<nyaomixyz>
oh
<nyaomixyz>
now it makes sense
<psykose>
ls -li
<psykose>
i don't know why they're hardlinks
<psykose>
they work fine as symlinks too
<psykose>
seems like a silly decisiou
<psykose>
decision*
<nyaomixyz>
yeah
<nyaomixyz>
also because it kinda tricks your brain in thinking stuff
<nyaomixyz>
btw, idk what the hell is wrong
<chadmed_>
yeah sorry im at a loss too... i just did a fresh install last night on a j314 and it all worked fine
<chadmed_>
im working on fixing the rust bs in the overlay rn, then ill need to do an MR for asahi-sources in the main gentoo branch
<chadmed_>
which will of course take 600 years to get merged because no one with write access has the bandwidth to review anything and no one wants to give me write access
<psykose>
what's the normal way to find out why mesa refused to load a specific driver
<nyaomixyz>
tbqh
<psykose>
that is not trying to compare strace with code :D
<nyaomixyz>
at some point it emerged the mesa gentoo driver but i masked that out, removed it from existence and then i installed mesa from asahi
<psykose>
that would be ok
<nyaomixyz>
at this point i am wondering if something was left in there
<chadmed_>
ahhh
<nyaomixyz>
but like
<chadmed_>
uhh one second
<chadmed_>
yeah that is kinda fucky
<chadmed_>
you have to rebuild some other package
<nyaomixyz>
oh god
<nyaomixyz>
which one
<nyaomixyz>
libdrm? done
<chadmed_>
nah not libdrm theres some other one
<psykose>
whee
<nyaomixyz>
vulkan-loader?
<nyaomixyz>
libglvnd
<chadmed_>
it might be libglvnd
<nyaomixyz>
it's from nvidia
<chadmed_>
zstd is from meta but its not just for accessing facebook
<nyaomixyz>
i know though it seems wacky that could be it
<chadmed_>
also try xorg-proto
<psykose>
xorgproto is just a bunch of headers so that would mean more rebuilds after
<tpw_rules>
chadmed_: are you that guy who claims zstd is how facebook is trying to take over the world
<chadmed_>
no....
<psykose>
that's probably the worst part about zstd
<psykose>
nothing about itself, just all the people that refuse to touch it because 'lol facebook'
<psykose>
always hurts when something comes out that pushes the pareto front and people turn up their nose
<nyaomixyz>
tried to rebuild a bunch of other media-libs, nothing
<chadmed_>
im out of ideas then something's clearly broken because a clean install Just Works(tm)
<nyaomixyz>
this was supposed to be a clean install but i fucked it up midway without noticing lmao
<tpw_rules>
i've had a few users report corruption of the built mesa libraries and idk why
<nyaomixyz>
on one side i can restart, on the other it's a pain
<nyaomixyz>
it'd be easier to tear the entirety of mesa down
<psykose>
emerge world minus a few packages and take a break :-)
KxCORP5 has quit [Quit: Bye!]
KxCORP5 has joined #asahi-alt
<tpw_rules>
or reformat?
<chadmed_>
you could probably just try doing emerge @installed and letting it rip
<chadmed_>
will take a decent whack of time though :p
nyaomixyz has quit [Remote host closed the connection]
<chadmed_>
ugh that rust patch is so big
jeisom has quit [Ping timeout: 480 seconds]
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
chadmed_ has quit [Remote host closed the connection]
chadmed_ has joined #asahi-alt
nyaomixyz has joined #asahi-alt
<nyaomixyz>
hello - dropping in to report, no progress yet but i found that DRI devices aren't even good. Starting to wonder that problem is not related to mesa
nyaomixyz has quit [Remote host closed the connection]
<chadmed>
did you try emerge @installed?
nyaomixyz has joined #asahi-alt
<nyaomixyz>
chadmed: no I didn't yet. Doing it now
<nyaomixyz>
900 something packages
<nyaomixyz>
what I found is that the gpu lives at /dev/dri/card1
<nyaomixyz>
and it's THE gpu
<nyaomixyz>
however the screen for some reason seems connected to /dev/dri/card0
<chadmed>
its because the gpu is not the display controller
<nyaomixyz>
and that display controller
<chadmed>
they are totally independent SIP blocks and have almost nothing to do with each other
<nyaomixyz>
card0 shows up as framebuffer
<nyaomixyz>
dunno if it's legitimate
<nyaomixyz>
before rebuilding the kernel today (after your rust patch I made sure to emerge sync for safety) not even the gpu was recognized
<nyaomixyz>
so now I have a legitimate card1 and renderD128
<nyaomixyz>
yet, llvmpipe on kde
<nyaomixyz>
btw the hdmi won't work
<chadmed>
something about your install is totally busted then, you should just reinstall
<nyaomixyz>
like it spams "Failed to get dp-xbar: -517" exactly
<chadmed>
ah yep i _think_ thats going to be because the distkernel uses the alarm kernel config which doesnt have that option
<nyaomixyz>
but could that be related?
<chadmed>
can you try with asahi-sources instead of asahi-kernel and ill upload the .config i use
<chadmed>
this is a very very barebones kernel but everything asahi-related should work
<nyaomixyz>
well... i'll do that after emerging the entirety of my install at this point
<nyaomixyz>
or i could also cancel
<nyaomixyz>
uhm
<nyaomixyz>
nice, it crashes because rust
<chadmed>
ergh yeah take the patch from the overlay and put it in /etc/portage/patches/sys-kernel/asahi-sources/
<nyaomixyz>
in any case, so people are not using asahi-kernel for real?
<chadmed>
i started working on the dist-kernel in preparation for bootable install media however we need a reliable way to copy down the fedora kernel config which doesnt exist for COPRs
<chadmed>
someone was working on it but the configs they landed on were not conformant to our "do what upstream does" policy
<nyaomixyz>
i will emerge @installed for now, because i have other stuff pending irl and well, so that i start narrowing down the thing
<chadmed>
and they were unwilling to change
<nyaomixyz>
however i wonder if anyone else can reproduce by just emerging asahi-kernel at this point
<chadmed>
asahi-kernel works on my mac studio
chadmed has quit [Remote host closed the connection]
<mps>
chadmed: alpine asahi kernel config works long time and very stable, maybe you could look in its config (sorry for advertising)
chadmed has joined #asahi-alt
<nyaomixyz>
chadmed: ok but a mac studio doesn't have a built in screen... i wonder if this can be repro'd on m1 pro macbooks at this point (if it's a platform issue we're all happy and i am just unlucky)
<chadmed>
the builtin screen is irrelevant, the relationship between the display controller and gpu is the same in all machines
<janneg>
has the asahi-kernel config CONFIG_MUX_APPLE_DPXBAR as module / built-in? that would be the most obvious cause for "Failed to get dp-xbar: -517"
<chadmed>
no it doesnt, its just the -edge config from ALARM pkgbuilds repo
<chadmed>
i need to grab the fedora config and host that somewhere and just pull it in as a SRC_URI
<nyaomixyz>
btw
<janneg>
that breaks asahi-kernel on all m2* devices
<nyaomixyz>
what does ls -la /dev/dri/by-path look like in your machines?
<janneg>
nyaomixyz: the display controller never probes because because the driver for one piece required for hdmi support (on laptops) is not enabled in the config
<nyaomixyz>
so i tried to compile asahi-sources and it would hang on boot
<nyaomixyz>
so i unmerged and remerged it for good measure
<nyaomixyz>
now rebuilding again with chad's config
<nyaomixyz>
also following 1:1 the install.sh
<janneg>
chadmed_: see the the "
<nyaomixyz>
this is like the first time i am installing gentoo ever but at least i got some experience in wacky linux stuff from other distros... it's fun
<nyaomixyz>
well not fun fun as i would've loved to do stuff by this point but eh, problems
<janneg>
chadmed_: see the the "Dist Git Source" links on the copr build page
<nyaomixyz>
chadmed_: your configuration won't boot on my pc
<nyaomixyz>
err, macbook
jeisom has joined #asahi-alt
<nyaomixyz>
well, compiling with the fedora config
<nyaomixyz>
and here goes nothing
chadmed has joined #asahi-alt
<chadmed>
are you using dracut to make an initramfs?
<nyaomixyz>
yes
<chadmed>
did you pass --zstd to it?
<nyaomixyz>
i'm passing whatever is in ./install.sh so it's compress gzip
<chadmed>
ah yeah thats wrong my config only uses zstd across the kernel
<chadmed>
i told you it was barebones heh :p
<nyaomixyz>
well
<nyaomixyz>
man
<chadmed>
hence why its not suitable for a dist kernel
<nyaomixyz>
fair
<janneg>
I'm working on getting asahi-kernel fixed
<nyaomixyz>
however probably the entire asahi-gentoosupport has to be revised
<nyaomixyz>
so that it pulls asahi-meta
<nyaomixyz>
oh and also why the hell `exec $(which asahi-fwupdate)`
<chadmed>
there was a reason but it escapes me
<nyaomixyz>
it won't ever print your "finished" lines tho
<chadmed>
that repo is basically deprecated at this point anyway, the plan going forward is for a bootable livecd with all required ebuilds upstream or the choice of a prepackaged disk image like the vanilla asahi installer
<mps>
ahm, latest tagged kernel is still 6.6 based
<chadmed>
yes
<mps>
not sure should it be upgraded for distro (alpine in my case)
<nyaomixyz>
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
<nyaomixyz>
nice
<nyaomixyz>
new dep for asahi-kernel with fedora config
<janneg>
thanks, I wouldn't have noticed the missing the pahole dependency, curse of dev machines which have dev tools installed
<janneg>
chadmed: is there a reason why asahi-kernel depends on virtual/dist-kernel?
<nyaomixyz>
asahi-sources doesn't have dtbs in /lib/modules wtf
<nyaomixyz>
is there a make subcommand for those?
<chadmed>
janneg: gentoo-kernel does it so we do it too
<chadmed>
yeah its make dtbs_install
<janneg>
since asahi-sources doesn't build / install anything that's to be expected
<sam_>
it's required to pull in the new version of dist-kernel in the right order
<chadmed>
update-m1n1 is patched to take them from /usr/src/linux though
<sam_>
(for the rebuilds)
<janneg>
but virtual/dist-kernel depends on the upstream dist-kernel, i.e. that's pointless for us
<sam_>
you'll have to fork the virtual until you add asahi-kernel to ::gentoo
<chadmed>
i override upstream in the overlay
<chadmed>
because asahi-kernel depends on virtual/dist-kernel-6.6.0_p15 specifically it will never try to pull upstream
<nyaomixyz>
oh god it's taking dracut so long to compress this initrd
<nyaomixyz>
the fedora config has to be cut
<chadmed>
no it doesnt
<chadmed>
if you want a dist kernel, you get the full dist kernel experience
<chadmed>
use asahi-sources if you want a lighter kernel
<janneg>
ah, so I should install virtual/dist-kernel::asahi instead of asahi-kernel
<chadmed>
no you shouldnt need to
<chadmed>
the dep graph will resolve to only ever want virtual/dist-kernel::asahi
<chadmed>
since there is no virtual/dist-kernel-6.6.0_p15 upstream
<chadmed>
argh ffs
jeisom has quit [Quit: Leaving]
<chadmed>
_now_ it will only ever depend on 6.6.0_p15 :/
<janneg>
but doesn't that break the auto update as well?
jeisom has joined #asahi-alt
<chadmed>
wdym
<janneg>
if it deepends on dist-kernel-6.6.0_p15 it will not pull in dist-kernel-6.8.0_p1 once we provide that
<chadmed>
we just add a virtual/dist-kernel version for that
<chadmed>
the ebuild has =virtual/dist-kernel-${PV} so it will look for a virtual/dist-kernel with a version exactly matching the actual kernel ebuild
<chadmed>
since there are no upstream kernels called -6.8.0_pX then it wont match on anything but what we provide
<chadmed>
no upstream virtual/dist-kernels*
<janneg>
I'm not convinced that the auto-update within ::asahi will work with the fixed version
<nyaomixyz>
well, compiling asahi-sources with fedora config makes a compressed initramfs of 200mb
<nyaomixyz>
and it won't even boot because it won't find /init
<nyaomixyz>
for some reason
<nyaomixyz>
it hangs with errno -2
<nyaomixyz>
so enoent
<nyaomixyz>
which is.. understandable? is that linked to systemd in some way?
<chadmed>
janneg: just tested it and it worked fine
<janneg>
fedora-asahi-remix' initramfs are ~95M
<chadmed>
nyaomixyz: unless the fedora config looks somewhere other than /sbin/init it shouldnt matter
<janneg>
chadmed: ok
<chadmed>
can you try with my config again and pass --zstd to dracut
<chadmed>
all we need to do for updating to work properly is remember to also push a new version of virtual/dist-kernel that matches exactly the asahi-kernel version
<chadmed>
and portage resolves the deps properly and updates successfully
<janneg>
is it an oversight that asahi-kernel has no metadata cache?
<janneg>
mps: asahi-6.6-16 fixes HDMI issues on M2* desktop systems
<mps>
janneg: aha, thanks for info
<chadmed>
janneg: not an oversight i just stopped pushing them since they pollute the commits and dont seem to be neccessary/wanted as they also screw with pkgdev
<chadmed>
theyre not present in ::gentoo
<sam_>
is the overlay in the official repo list?
<chadmed>
nope
<sam_>
if it's not, if you get it added, then we mirror it w/ metadata added
<chadmed>
i think leio wanted to get some QA stuff cleaned up before endorsing it
<sam_>
there's far worse in the list ;)
<chadmed>
i dealt with a bunch of stuff pkgcheck was complaining about months ago but theres probably more
<sam_>
yeah i guess add the pkgcheck action to the gh repo first
<janneg>
asahi-kernel initramfs size with fedora config is 41M, not yet booted though
<chadmed>
its insane to me that the same people who own github also somehow managed to wrought the crime against humanity that is azure devops upon us
<chadmed>
spent over a week wrangling CI stuff on azure for work and just gave up, its deranged
<sam_>
horrible isnt it
axt has joined #asahi-alt
<chadmed>
i have it running on a single repo since its the only one we have that actually needs to build deployable artefacts but if i had to do another one id probably sooner quit and look for another job
<nyaomixyz>
btw it didn't boot because dracut couldn't copy the full initramfs to the uefi
<nyaomixyz>
it wasn't 200mb it seems
<nyaomixyz>
it was... more
<leio>
what are we talking about? Getting to overlays list?
<chadmed>
leio: yeah mostly
<leio>
I vaguely recall encouraging you to file the PR to api.g.o
<nyaomixyz>
AAAAAAAAND
<nyaomixyz>
yes
<nyaomixyz>
it was the kernel
<leio>
and was annoyed I couldn't just give an eselect repository instruction in the project page
<nyaomixyz>
asahi-kernel has to be revised
<nyaomixyz>
your configs booted with gpu acceleration
<nyaomixyz>
oh shit i was really thinking of emerging @installed poor me
<nyaomixyz>
cc chadmed
<chadmed>
eyyyy \o/
<nyaomixyz>
so i can install gentoo after all
<nyaomixyz>
ok but now... do i leave this on github issues?
<chadmed>
yeah leave the issue open and ill close it when we fix it up
<chadmed>
sorry about all the mess, i started fixing all this stuff during the christmas break and then got inundated with life/work stuff...
<chadmed>
someone should pay me to do this full time i think :p
possiblemeatball has joined #asahi-alt
<nyaomixyz>
and here i was doubting myself
<nyaomixyz>
tho
<nyaomixyz>
i kinda don't like fedora so...
<nyaomixyz>
ok but now for real what's the difference between the two configuration files? question mark
<chadmed>
as in the fedora config and mine?
<nyaomixyz>
as in alarm and yours
<nyaomixyz>
but legitimately a kernel built with fedora configs won't fit on the 512mb efi
<nyaomixyz>
it's 1.4gb uncompressed
<nyaomixyz>
so either the modules and kernel are compressed beforehand with zstd or.. idk
<sam_>
wtf are you doing if it wont fit
<sam_>
maybe it's the page size i guess
<sam_>
but i mean the gentoo fedora config ones are like, 100MB or something
<nyaomixyz>
I literally downloaded the config from fedora and then I ran... make -j4
<nyaomixyz>
make install and make modules_install
<chadmed>
the alarm build is older than gilgamesh and mine is not so it has all the latest kernel options
<nyaomixyz>
dracut failed copying the initrd to /boot
<nyaomixyz>
btw tested hdmi and it works too
<nyaomixyz>
so yeah asahi-kernel... bad move from me
<janneg>
1.4gb uncompressed sounds like modules with debug info, which makes sense as the fedora build keeps the debug info in a separate package
<nyaomixyz>
kernel-aarch64-16k-fedora.config
<nyaomixyz>
this is the one I downloaded
<nyaomixyz>
uhmmm
<janneg>
use asahi-kernel with asahi-kernel as that seems to remove either the debug CONFIGs or removes the debug info before install
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
qdot has quit [Ping timeout: 480 seconds]
paps__ has joined #asahi-alt
<paps__>
hi, I'm trying to boot a live debian in order to luks encrypt my debian asahi install, but after following the instructions from @cy8aer (https://git.g3la.de/repos/m1-debian) and making the usb key both ways (either from debian or macos) I cannot boot from it. After typing 'run bootcmd_usb0' or 'run usb_boot', U-boot says 'no usb devices available'
<paps__>
Or it says 'Device 0: unknown device'. Any idea what I might be doing wrong? Do I need to worry about boot flags on the usb thumb drive? thanks and sorry for the noob questions
<cy8aer>
Look at your live stick in "efi/debian/grub.cfg" and try other than "hd0" like "hd1", "hd2" - for me it is "hd2"
<cy8aer>
Looks like it is different for every device and usb slot (?)
<cy8aer>
oh, for me it is "hd3" (macbook pro m1pro)
<chadmed>
u-boot's usb stack is not very good and doesnt work with some usb sticks too. try a different stick
<paps__>
I think you're talking about a future problem I'm going to have :) Right now I don't get to the stage where it tries to boot from the stick. U-boot basically doesn't see my key
<paps__>
@chadmed ah interesting, ok I will try
<cy8aer>
And: I do not know which description you actually used for starting it up. It should be: "env set boot_efibootmgr; run bootcmd_usb0"
<cy8aer>
(just correcting at every place I documented this)
<cy8aer>
and the stick should have a subpartition, do not put vfat directly in the stick (e.g. "sda") but into e.g. "sda1"
<paps__>
I got it to boot! I had to use a different key and then change hd0 to hd3 :) Thanks a lot for the help
axt has left #asahi-alt [#asahi-alt]
qdot has joined #asahi-alt
<cy8aer>
yep sorry for the unconvenience 😉
<cy8aer>
paps__: what system do you have? Probably "hd3" is the new parameter for grub...
<janneg>
we probably want to cut the fedora config down, it installs 39M of dtbs to /boot
<mps>
dtbs for all SoCs
<paps__>
@cy8aer it's a m1 pro 14"
<cy8aer>
ok, same system. So no prove that hd3 is standard
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #asahi-alt
<nyaomixyz>
asahi-kernel with the fedora config builds and runs fine
<nyaomixyz>
now i'm supposed to go through with the installation since it's been half done since yesterday
<janneg>
zzywysm: not much to do about distro kernels as you can't predict which devices users want to use
ipatch has joined #asahi-alt
Compassion1 has quit [Quit: lounge quit]
jacksonchen666 has quit [Quit: WeeChat 4.2.1]
Compassion1 has joined #asahi-alt
Compassion1 has quit []
Compassion1 has joined #asahi-alt
<zzywysm>
anyone have any insight into why these changes lead to memory savings? my primary goal was getting rid of build warnings, and my secondary goal was increased performance
paps__ has quit [Quit: Connection closed for inactivity]
<tpw_rules>
chadmed: wireplumber 0.5 apparently "refactors" the lua script support and asahi-audio doesn't work properly anymore. i've rolled back to 0.4 but you might wish to know
<nyaomixyz>
oh no
<mps>
tpw_rules: I reported this issue few days ago
<mps>
reported here
<tpw_rules>
ah, i had missed that
<mps>
also I went back to 0.4
ipatch has quit [Quit: WeeChat 4.2.1]
ipatch has joined #asahi-alt
possiblemeatball has quit [Quit: Quit]
jeisom has quit [Quit: Leaving]
jeisom has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
jacksonchen666 has joined #asahi-alt
chadmed__ has joined #asahi-alt
<chadmed__>
tpw_rules, mps: ill look into it when i have the time. wp 0.5 hasnt made it into gentoo yet so i didnt notice
<sam_>
deliberately because of the breakage
<sam_>
not been in a hurry...
<sam_>
i think the migration doc thing only got made like 2 days ago
<nyaomixyz>
is there a gentoo binhost that provides packages without systemd integration?
<nyaomixyz>
because I wanted to test that, but I am still compiling the most of packages
<sam_>
i think the binhost has one or two openrc builders but it doesnt rebuild everything as lots of packages do not have USE=systemd
<sam_>
it's just that the openrc one needs to gain a few packages
<sam_>
but i am very surprised by *most*
<sam_>
the notable issue one is webkit-gtk where it has USE=systemd but its for something silly and that annoys people
<nyaomixyz>
systemd is winning.....
<sam_>
well its not about winning
<sam_>
its because the other way around is harder
<sam_>
like, on a systemd machine, you can build stuff w/ USE=-systemd
<nyaomixyz>
compiling webkitgtk as we speak
jacksonchen666 has quit [Quit: WeeChat 4.2.1]
<sam_>
but on an openrc machine, you cant just build stuff w/ USE=systemd
<sam_>
when u say most things
<sam_>
do you really mean you are sad building webkit-gtk
<leio>
webkit-gtk feels like something that would work with elogind?
<sam_>
which is totally reasonable, but a different matter
<sam_>
i looked into it before and i don't remember the answer
<sam_>
maybe tomorrow
<leio>
it's journal usage per cmake knob; maybe if it works and we made USE=systemd depend on systemd || elogind, the binpkg would be usable if openrc doesn't use.mask systemd? (does it?)
<nyaomixyz>
i did spawn more jobs than my ram could keep and i already crashed the puter on that hill
* leio
would just use systemd, and does :)
* nyaomixyz
would just use openrc, it's still the default
<sam_>
"default" doesn't really mean anything in gentoo
<sam_>
anyway
<sam_>
we should add webkit-gtk to one of the openrc builders
<sam_>
back later
<nyaomixyz>
i know i was teasing
<nyaomixyz>
about the default
<sam_>
i have heard it seriously so many times
<sam_>
everything in the book from both "sides"
<nyaomixyz>
but like, for real, i only run openrc on my personal stuff
<sam_>
i have no sense of humour anymore about it, im like a husk
<nyaomixyz>
systemd i run on my homelab thingy tho
<nyaomixyz>
well i guess that you've lived enough days with people fighting each other over the init system choice
<nyaomixyz>
i only barely looked at that discourse
<nyaomixyz>
used openrc because uh alpine had it and i worked with it, then artix had it and i wanted to try it, now gentoo
<chadmed__>
urgh so everything has changed to spa-json
<chadmed__>
thats not necessarily a bad thing but virtually everything we did has to be thrown in the bin :)
possiblemeatball has joined #asahi-alt
kidplayer666 has joined #asahi-alt
chadmed__ has quit [Remote host closed the connection]
JayBeeFOSS has quit [Remote host closed the connection]