<sad_plan>
any suggestions for naming on my package manager written in rc? currently its just rcpm, simply becase Ive called the rest of my stuff this way. rcinit and rcsm for reference. I suppose rcpm works though. but im open for suggestions
_whitelogger has joined #kisslinux
_whitelogger has joined #kisslinux
fturco has joined #kisslinux
fultilt has quit [Quit: Leaving]
so has quit [Remote host closed the connection]
so has joined #kisslinux
fturco has quit [Quit: nyaa~]
worf1338 has quit [Ping timeout: 252 seconds]
fturco has joined #kisslinux
phinxy has quit [Read error: Connection reset by peer]
phinxy has joined #kisslinux
fturco has quit [Quit: nyaa~]
fultilt has joined #kisslinux
EliSoli has joined #kisslinux
<EliSoli>
I'm having some problem when compiling on KISS
<EliSoli>
"cannot use keyword 'false' as enumeration constant"
<EliSoli>
"'false' is a keyword with '-std=c23' onwards"
<EliSoli>
It seems there's a problem with GCC
<EliSoli>
can anybody please help me on this?
<fultilt>
Looks like they upgraded gcc to 15.1. They shouldn't have done that, not until they'd checked *every single package* for compatibility. Try adding 'export CFLAGS="$CFLAGS -std=gnu17"' near the top of libsndfile/build.
asimov has joined #kisslinux
<asimov>
hi guys
<asimov>
hi guys
<EliSoli>
Don't you recommend adding that to my global CFLAGS?
<fultilt>
EliSoli: Sure, I think that should work.
<EliSoli>
This issue happens on KISS (even after setting -std=gnu17) and Arch, but not on Gentoo
<EliSoli>
well, I'm making some tests and I think adding that flag to the makefile actually fixed
<sad_plan>
EliSoli: gcc 15.1.0 defaults to gnu23 now, which seems to break some packages. I havent really bothered to check my own, but im sure theres going to be some issues on my end aswell...
<EliSoli>
hmmm... that's gonna be a bit of headache for us. But at least not in my personal projects (-std=ansi)
<sad_plan>
yeah, I didnt like that either. its even worse on oasis, where its goals is to be iso C conforming. luckily, mcf was quick to fix things when he bumped gcc though. so its all good there anyway
<asimov>
you guys see importance to use react or web frameworks?
<EliSoli>
yes, it makes life a lot easier
<asimov>
i'm planning to make some website kinda knowledge hub like privacyguides.org
<EliSoli>
that wasn't enough to compile my kernel...
<fultilt>
I heard there was some drama around the latest release of Linux, when Linus made a bunch of last-minute changes to support GCC 15, totally not following usual kernel workflow.
<asimov>
in this case you thing is necessary or too bloat?
<EliSoli>
6.14.5 is not compiling, neither the last versions with gcc 15
<EliSoli>
asimov I think it's necessary. Frameworks are there to help
<EliSoli>
and you plan to make something that will need islands and states
<EliSoli>
it seems at least
<asimov>
EliSoli: try kernel 6.15-r5
<asimov>
I haved the same issue
<EliSoli>
try sveltekit, i've been trying it for something and i think it's pretty cool
<asimov>
Compiled in the latest mainstream
<EliSoli>
I'll try asimov
<asimov>
Probably will be same same error
<asimov>
Something about apci
<asimov>
acpi*
<kris_>
i wonder if clang has this many breakages
<kris_>
gcc 14 broke a bunch of stuff too
<asimov>
Anyway
<asimov>
again
<asimov>
someone here is using xdg-desktop-portals?
<asimov>
i'm still not get it working lol
<asimov>
seems i'm doomed on this
<EliSoli>
Did y'all notice the linux firmware download links are out of service?
<EliSoli>
it's returning 503
<EliSoli>
Error 503 first byte timeout
<EliSoli>
first byte timeout
<EliSoli>
Error 54113
<EliSoli>
if it wasn't an HDD with void I had here i wouldn't be able to finish my KISS install until who knows when
<asimov>
normal
<asimov>
sometimes the world is against kiss
<asimov>
i had a problem to build nasm because the server is down
<EliSoli>
that's how it feels to live in the shadows?
<asimov>
kinda
<asimov>
i'm still without screensharing
<asimov>
and still don't know why
<asimov>
and no one can help anymore lol
<EliSoli>
do you have xdg-desktop-portal and xdg-desktop-portal-wlr?
<asimov>
yeah
<asimov>
something in pipewire about enum format
<EliSoli>
i had the same issue, just add -std=gnu17 to your CFLAGS when compiling libsndfile asimov
<asimov>
no way
<asimov>
i will test this
<asimov>
wait
<asimov>
this is not just for compiling?
<EliSoli>
yes
<asimov>
it comipiled
<asimov>
this is not the problem
<EliSoli>
then?
<asimov>
dont know if you get it
<asimov>
the problem is pipewire i think
<asimov>
i had this problem months ago
<EliSoli>
kernel 6.15-rc5 worked, thx
<EliSoli>
about the screensharing, i'll try to setup that on my env, i'll let you know if I manage something
<EliSoli>
you always use this name here? asimov
<asimov>
yeah
<asimov>
since some years ago
<EliSoli>
ok
<asimov>
same name
<asimov>
is like the 20 time i installed kiss again
<asimov>
and nothing about screensharing
<EliSoli>
same hahah i keep breaking it for some reason
EliSoli has quit [Quit: Client closed]
<asimov>
sometimes i dream about making kiss more upstream and more maintained
<sad_plan>
kris_: im more curious as to why gcc devs makes breaking changes to gcc to begin with. one would assume that a compiler would aim not to cause breakage
<sad_plan>
although, regarding clang, I dont recall this happening in the past anyway
<kris_>
sad_plan this seems to be just widely standard for gnu projects really
<kris_>
glibc breaks stuff constantly too
<sad_plan>
yeah ive heard glibc have had numerous breakages in the past. maybe this is just the standard over at gnu land
<kris_>
it happens
<kris_>
unfortunately i just got my local server moved back over to glibc
<kris_>
in that case im not particularly concerned with breakage but glibc is responsible for a lot of pretty severe vulns on the regular
<sad_plan>
why not use musl?
<kris_>
i was for the past few weeks but ive been having some undiagnosable bug with qemu that i couldnt solve
<sad_plan>
I get that sometimes one needs glibc though. in the case of nvidia drivers for one
<kris_>
so this is part of troubleshooting that
<kris_>
this is a server that does nothing other than run virtual machines
<sad_plan>
ah
<kris_>
it's a little more annoying on void sometimes
<kris_>
they use musl 1.1.24 with a buncha patches so i had to test both my own build and theirs
<kris_>
swapped the kernel, rolled back the servers bios, bunch of other stuff
<kris_>
if it's still not fixed im going to replace the hardware
<sad_plan>
why does void even do this? instead of actually updating musl properly?
<kris_>
time_t issues on 32 bit
<kris_>
there are some abi changes xbps needs in order to not break on 32 bit systems with newer musl
<kris_>
its shitty but if you're on a 64 bit system you can quite literally just compile latest musl and use it
<sad_plan>
im pretty sure they could just have a quick glance at what other distros does, and just reference that, and call it a day
<sad_plan>
or, i mean, fix xpbs
<kris_>
im not sure why its taking so long but xbps needs some changes
<kris_>
and i think they're still arguing about how they want to fix that
<kris_>
but recently ive been seeing some work on rewriting xbps in golang
<sad_plan>
sounds like maybe they should stop fiddling with their dicks and get to work instead :p
EliSoli has joined #kisslinux
<sad_plan>
ah, well, that would certainly stop fixing existing issues to a certain degree anyway
<kris_>
i refuse to view this as a "get to work" type of issue because everyone just does this in their free time
<kris_>
i just update musl myself on my own systems
<kris_>
*to me* the solution is to just drop 32 bit cpu support though
<sad_plan>
well sure, but if you actually wanna see something done, you gotta put in the work. but im guessing it wasnt annoying enough for the devs to fix it
<sad_plan>
people still use 32 bit machines, but theyre getting fewer by the day though
<sad_plan>
nevertheless, that would also be a solution
<kris_>
i kinda have a mentality of if you're still using 32 bit you need to just go pick up a free computer from the trash dump
<kris_>
but personally i would also bump to x86_64-v3
EliSoli has quit [Quit: Client closed]
<sad_plan>
lol, well yeah, but some use it out of principle. I talked to a guy over on newnet, and he used all kinds of old stuff. programmed exclsivly in c89 more or less
<sad_plan>
when did even v3 come out? Im under the impression that its been quite some time now..
<sad_plan>
ah, 2013 it seems
<sad_plan>
with intels haskwell gpu gen
<sad_plan>
and 2015 for amd it seems
asimov has quit [Ping timeout: 244 seconds]
kris__ has joined #kisslinux
kris_ has quit [*.net *.split]
micr0 has quit [*.net *.split]
082ABPQUA has quit [*.net *.split]
zenomat has quit [*.net *.split]
V has quit [*.net *.split]
il has quit [*.net *.split]
kris__ is now known as kris_
micr0 has joined #kisslinux
082ABPQUA has joined #kisslinux
zenomat has joined #kisslinux
V has joined #kisslinux
il has joined #kisslinux
<kris_>
yeah haswell
<kris_>
it's definitely kind of an extreme move because it's not like older than haswell hardware is unusable but it's also so old that i feel like it's time to consider bumping to v3 lol
<kris_>
at least for some things because there are some pretty major benefits to things like cryptography
<sad_plan>
im kinda on the fence on that one. while I agree that we should maintain modern hardware, to keep our computing safer, hardware can be expensive, and if we all of a sudden drop support for hardware older than N years, all of a sudden we got a lot of unusable hardware around, which is kindof a nightmare for the environment in any case :p
<kris_>
you aren't wrong and really something like kiss is immune to this anyway
<kris_>
what most other distros are considering doing right now is having a v2 repo and a v3 repo
<sad_plan>
for sure, unless software all of a sudden find way to not work on 32-bit :p
<kris_>
v4 wont happen for a LONG time, i don't even have v4 support and i'm on intels most recent release
<sad_plan>
yea, cachyos has a v3 and v4 repo actually
<sad_plan>
dunno about v2
<sad_plan>
im on cachyos on my desktop atm, getting my feet wet in, and I do like that I can take advantage of some of the more modern features of my hardware
<sad_plan>
maintaining legacy support is also an endless cabacle, which will utlimately just get bigger and bigger
<kris_>
ive not used cachyos
<kris_>
not really my style of OS
<kris_>
and really when i ran an entirely march=native'd void system i didnt notice any speed difference
<kris_>
can only tell via synthetic benchmarks
<kris_>
but the thing that matters via v3 is that you get a LOT more iterations with most crypt setups
<kris_>
iirc sometimes +200%
<kris_>
ubuntu published some benchmarks a while ago
<sad_plan>
well, I just wanted something decent ootb, where I could easily play my games. it did however help that it conviniently had the things I wanted packaged already, and its all built with LTO, PGO and so on. basically trying to sqeeze out every bit of performance
<sad_plan>
march=native doesnt really do much from what I can gather. atleast not on its own
<kris_>
i may try it at some point but i guess i'm just jaded and tired of hopping around
<sad_plan>
back to cachyos, I was using nobara, for the same reasons, but.. well my /home got nuked, so I figured why not try something else while I had to reinstall anyway
<kris_>
btrfs i'm guessing
<sad_plan>
no, ext4
<kris_>
ah that's also not super surprising
<kris_>
do you know what caused it though
<sad_plan>
I was running out of space on / all the time, so I tried to move my /home 5G to the left. which ultimatly failed, so it tried to roll back conviniently also failed....
<kris_>
sounds like you maybe should be using something like btrfs or zfs then
<kris_>
i never split off my /home, i find it's more trouble than it's worth
<kris_>
and since i only feel comfortable using xfs that's just going to make a split /home even more painful for me since i can't shrink partitions
<sad_plan>
perhaps, but using btrfs means Id have to package btfsprogs aswell, which I kinda dont wanna do. zfs needs out of tree patches aswell. probably no biggie though. maybe ill look into it later, when I get a second drive installed
<kris_>
if you're not encrypting zfs is a good call
<sad_plan>
re xfs, you can only go one way with it though. iirc, you cant shrink it? or was it the other way around
<kris_>
but you also need to keep your kernel held back because it's out of tree
<kris_>
and yeah you cannot shrink xfs
<kris_>
you can grow but never shrink
<sad_plan>
yeah, I wont bother with encryption
<kris_>
something kinda cool though, you can grow an xfs partition while it's literally mounted and in use
<sad_plan>
zfs is packaged on oasis though, so theres that
<sad_plan>
really?
<sad_plan>
didnt know that
<kris_>
but xfs is just SO much faster than every other filesystem
<kris_>
and in my experience, much more stable than ext4
<kris_>
and has some interesting features like reflink so copies of data don't consume more storage, it just references the original until one of them is modified
<kris_>
which means copies are also instant and can be handled like instant snapshots of data
<sad_plan>
yeah I was using xfs some time ago, but I grew tired of maintaing xfsprogs, which kept adding new dependencies on version bumps..
<kris_>
meh i didnt find it too crazy to package for kiss