<noocsharp>
illiliti: didn't aosp recently rewrite their bluetooth stack in rust?
<illiliti>
idk
Torr has quit [Quit: leaving]
dilyn has joined #kisslinux
<dilyn>
:o o/
<noocsharp>
who are you
<dilyn>
i'm a ~ghost~
<dilyn>
of maintainers past
<vbt[m]>
welcome dylan
chomwitt has joined #kisslinux
ioraff has quit [Ping timeout: 245 seconds]
chomwitt has quit [Ping timeout: 264 seconds]
<testuser[m]12>
Hi
ella-0_ has joined #kisslinux
ella-0 has quit [Ping timeout: 245 seconds]
dilyn has quit [Quit: Ping timeout (120 seconds)]
chomwitt has joined #kisslinux
<Ogromny>
Hi everybody
<testuser[m]12>
The answer is no, those are very common dependencies on any system/distribution that why we use them in the core daemon and they fit pretty well in our design.
<testuser[m]12>
A Bluetooth application communicates with the Bluetooth process through Binder. The Bluetooth process uses JNI to communicate with the Bluetooth stack and provides developers with access to various Bluetooth profiles.
stjohn has joined #kisslinux
<wael[m]>
is there a `lspci` like that can actually list PCI device names like GNU lspci?
<stjohn>
wael: Is there a GNU lspci? It's not part of util-linux. There's a KISS package for pciutils in the community repo and that doesn't appear to be a GNU project.
<wael[m]>
busybox provides lspci
<wael[m]>
pciutils provides it as well, but can be picked by alternatives, thanks!!
<wael[m]>
but how do i switch it out? i cant figure out how to swap with kiss
<wael[m]>
nvm, just had to specify the path
<stjohn>
You can do this: `kiss a | grep ^pciutils | kiss a -`
<illiliti>
toybox lspci can display names also
<illiliti>
it needs hwdata first, specifically pci.ids
<Ogromny>
Does firefox need dbus and so be built without `--disable-dbus` to have push notification working ?
<testuser[m]12>
Yeah
<testuser[m]12>
Why do u need notifications from a browser though
<Ogromny>
I'm pretty much forced to use discord for work so...
<stjohn>
I've seen them used by lichess to notify you that it's your turn in a correspondence game. Not really a *need* so much as a use, though.
<Ogromny>
(All my co-workers chat via discord)
<stjohn>
Oh yeah that is a pain in the arse. You could use the desktop app, or go a different way and use a third-party client (there is a plugin for libpurple).
<illiliti>
until you get banned for not complying with vendor lock policy heh
<stjohn>
BURN IT WITH FIRE
<illiliti>
i wish i could lol
soliwilos has joined #kisslinux
<phinxy>
My kiss -a has 7 pages of gobject-introspection conflicts with glib..
<phinxy>
I suppose I remove glib since gobject-introspection.git provides both 1.0 and 2.0?
chomwitt has quit [Ping timeout: 260 seconds]
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
soliwilos has quit [Remote host closed the connection]
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
ioraff has joined #kisslinux
<riteo>
lately I got this completely dumbass idea
<riteo>
what if each package had like, some package-manager-specific configure options?
<illiliti>
use flags?
<riteo>
kinda
<illiliti>
bad idea
<riteo>
but only package-specific and "embedded" in the version
<riteo>
like "I'm using gcc 12.1.0[libasan=true]" or something like that
<riteo>
are package specific use flags a bad idea too?
<ioraff>
still would require quite a bit of monkeying with the build scripts
<riteo>
yeah, but forking a package just for a configure flag is silly IMO
<riteo>
they'd be just enviroment variables probably
<riteo>
or what, arguments? We're talking about simple things
<ioraff>
I disagree. keeps the build scripts as simple as possible
<riteo>
yeah but then you gotta mantain a lot of packages just for stupid changes
<riteo>
and it's worse when you're talking about stuff like gcc/firefox which has potentially a lot of patches and whatnot
<illiliti>
it isn't worth the effort riteo. use flags will result in code smell, just check any gentoo ebuild and understand how terrible it is
<riteo>
I'll take a look
<ioraff>
don't really need to maintain them. just symlink every file except the build script.
<ioraff>
are you still working on a package manager?
<riteo>
I never started it tbh, just collected a lot of ideas
<riteo>
I'm kinda tight due to godot's beta being close
<riteo>
still, in my package manager this whole mess would be partially irrelevant since the juice would be in the final built format and installer, the simplest and most important pieces
<riteo>
the package builder would come later
<riteo>
I just never talked about this silly idea which for some reason is sticking to me
<riteo>
btw I can't find some examples, I tried with both firefox or GCC but the first is like, extremely complicated only at building it and GCC is inherting 99% of stuff
<riteo>
s/inherting/inheriting/g
<riteo>
ioraff: the issue is exactly with the symlinking approach
<riteo>
if I want to make a single-line edit to the build file I can symlink how I want
<riteo>
it won't work
<riteo>
and also 99% of packages have of important pretty much just the build file or patches, with new flags or tricks being implemented expecially there
qwerty111 has joined #kisslinux
<qwerty111>
Hi, does anyone use f2fs? What are the advantages over ext4?
<ioraff>
I used it awhile back. I believe the advantages come mostly with raw solid-state (e.g. SD card) storage
<ioraff>
riteo: I don't follow
<riteo>
illiliti: I can kinda see what you mean, but it looks like they've made it super complicated
<riteo>
ioraff: most of my forks are simply single line changes to enable simple features or maybe add a single dependency, but mostly the former
<riteo>
my approach would try to make it as least variable and generic as possible
<illiliti>
i used to use f2fs before i switched to zfs. in short it has no noticeable advantage, so don't bother really
<riteo>
ideally, any gcc 12.1.0[libasan=yes] package would be identical, independently of the machine
<riteo>
although I admit that this example is kinda bad, as I would probably make some fragmentated packages (gcc-libasan, gcc-doc, and so on), but I imagine this being pretty controversial
<ioraff>
sure. but the maintenance cost of that is minimal if every other file is symlinked, since build files don't change often.
<riteo>
uh, sure? I always noticed the opposite pretty much
<riteo>
most of the stuff happens in the build file
<riteo>
also it's not like some packages don't have specific behaviour-altering-variables or conditions already
<illiliti>
you could split configure flags into its own file, but still, this doesn't give you full flexibility over build file and needlessly complicates things
<riteo>
that'd be way more complicated. Souldn't it be enough to use something like ${LIBASAN---disable-libasan}?
<riteo>
perhaps by just setting it
<illiliti>
you're inventing use flags
<riteo>
I'm really having trouble understanding why they're bad
<riteo>
I mean, I understand that global use flags are bad
<illiliti>
what if in order to enable or disable asan, you need more logic that just --disable/enable flag? that's where things become messy
<ioraff>
most stuff happens with patches
<ioraff>
I suppose we could relegate more complicated logic to forks
riteo is now known as Guest466
riteo has joined #kisslinux
<riteo>
sorry, my laptop froze
<riteo>
illiliti: I see your example, but theoretically this stuff would only be used for relatively simple things
<riteo>
if you need something more complex you'd probably need a separate package I think
<riteo>
also it's not like a user-forked package requires a lot of extra logic
Guest466 has quit [Ping timeout: 245 seconds]
<Ogromny>
USE flags are terrible, use gentoo daily for some month and you'll understand why Kiss should never have those
<riteo>
you know what, I should try gentoo sometimes
<Ogromny>
Honestly it's a great OS
<Ogromny>
you will learn a LOT of things
<riteo>
my version would be extremely more limited on purpose though
<Ogromny>
Simple and customizable AF
<riteo>
at least AFAIK from gentoo's docs
<illiliti>
riteo: use flags also could introduce circular dependency in some circumstances
<Ogromny>
The only drawback with Gentoo it's that it's so easy to do a dependency circle and resolving it with emerge is a mess
<wael[m]>
i personally never really liked gentoo for how hard and complex it was to manage
<illiliti>
gentoo is garbage
<riteo>
I think I'm starting to see why it's not a great idea
<riteo>
but I would really like to improve this whole forking situation
<riteo>
as I get slower and more messy updates due to this and I personally get annoyed by it
<Ogromny>
The one thing that I really liked from gentoo was virtual package, like you install rustup or whatever that manage rust version and it'll automatically install rust (a fake package with nothing in it)
<wael[m]>
what kind of USE flags could even be implemented in KISS? the repositories are made for Wayland and no Dbus or pulseaudio.
<illiliti>
provides is not bad idea yeah, but it complicates dependency handling
<riteo>
Ogromny: I said it before. It'd be for simple configuration changes
<wael[m]>
what about conflicts?
<riteo>
like adding support for certain features at configure time
<Ogromny>
You can check if some package are installed to enable some option
<illiliti>
conflicts? we have kiss a already which is fine
<riteo>
that's exactly what I want to avoid
<riteo>
I think they talked about feature conflicts?
<illiliti>
ah
<Ogromny>
Like maybe check if dbus is installed and if it's not add --disable-dbus or whatever to the build
<riteo>
Ogromny: in my mind the ideal would be packages which build identically everywhere
<illiliti>
> that's where things become messy
<Ogromny>
$(kiss s dbus) || "--disable-dbus"
<riteo>
it's the #1 issue IMO on kiss, that packages are too brittle since they take everything they can find from the system
<riteo>
btw regarding the provides thing: what if a package could depend on a file, instead of another package?
<riteo>
that'd allow for easier package/implementation replacements
<wael[m]>
Ogromny: i wish dbus checking would actually be implemented, but dbus is considered bloat anyway.
<illiliti>
that's how alpine apk work riteo
<riteo>
oh, nice, I like apk tbf
<riteo>
I think that idea might work instead
<riteo>
but I seriously how to fix the "stupid forks" problem, since it fragments work so much
<riteo>
and wastes so much time for anybody not wanting an extremely embedded like minimal system, since the base packages disable pretty much completely everything and then once I want to use some weird feature (like gcc's address sanitizer) I have to fork a whole package just for that
<illiliti>
forking is fine in kiss. don't be afraid of it
<riteo>
perhaps what could be improved would be the forking experience? Because having to run `kiss-outdated` in my local fork repo and having to check for any difference in the new one is pretty boring
<riteo>
and by pretty I mean a lot
<illiliti>
i see
<riteo>
I seriously feel like there's some way of fixing this issue, but can't put my finger on it
<illiliti>
i feel you
<riteo>
kiss's approach of "switch to simpler software" isn't working in this case since even python (some might call it bloated, but it's needed pretty much everywhere) required me to fork the package
<ioraff>
environmental variables for simple things doesn't sound bad
<riteo>
and in my silly idea they would be bound to the version or somehow in the package data
<riteo>
I don't think I would let it allow to change dependencies, although I'm not sure about the implications of either options
<riteo>
but I'm slowly getting convinced that there must be another way
<riteo>
I should look at my fork depo for more data and allow myself to think out of the box instead of grabbing onto this thing
<riteo>
also because I got inspired from what? pip? pip's shit
<testuser[m]12>
Make everything use dlopen
<ioraff>
you could change build and depends with KISS_HOOK
<testuser[m]12>
Run time use flags
<ioraff>
yeah pip is horrible
<riteo>
testuser[m]12: bingo
<riteo>
powered by dbus
<riteo>
and a systemd module
<riteo>
systemless packages, those are the future
<riteo>
systemless but with systemd(tm)
soliwilos has quit [Ping timeout: 268 seconds]
<riteo>
ioraff: nah, that'd be too brittle and complicated tbf
soliwilos has joined #kisslinux
<ioraff>
fair. I only use it to change compiler flags
<riteo>
the thing is though, that this complexity must eventually get in somewhere
<riteo>
either we completely subvert the whole architecture of certain pieces (s6 style I think), or we put more complexity somewhere
<riteo>
now, that could be the package manager, some extra tool for handling forks or the build scripts
<riteo>
but with such a dumb system it's bound to become more complex, the challenge's not doing that
<riteo>
another big issue's that KISS is monolithic, so there's very little room for dumb extremely cohesive components (UNIX style)
<riteo>
(although I get why some find it a good thing)
<Ogromny>
Or with create a pseudo build file, like build.patch that take a build file and change some lines like a patch file
<illiliti>
> user is smart, kiss is dumb
<illiliti>
do you remember that? maybe it's good thing to keep things dumb?
<riteo>
I completely agree about keeping things as dumb as possible
<Ogromny>
like build.pseudo, first line is the real build file and the rest is the patch
<riteo>
that's the issue I'm exposing
<riteo>
Ogromny: I thought about it, but a lot of patches (dunno, one for each feature) sound a nightmare to maintain
<riteo>
I get that this whole thing's purpose is to not waste a lot of time collectively wanting to modify/update each package for dumb things, but this risks becoming torture
<riteo>
illiliti: what I meant by my reasoning above is that perhaps we should look at it in another potentially radical way
<riteo>
as our absolutely biggest priority is keeping the package system as dumb as possible (recall the VERSION thing and its controversiality)?
<riteo>
that's also why I probably wanted to split the package system into two or more binaries, to keep them at doing the stupidest things and allowing for ad-hoc solutions, different implementations or who knows what
<riteo>
although I should surely look at more unix style subvertive solutions like s6. I'm starting to think that (in this context) we're imposing ourselves some specific structure to follow, the same that gentoo follows and that resulted in useflags
<riteo>
because effectively, there's not a lot of room for custom solutions in our current structure
<riteo>
hope I'm not being annoying with these extremely abstract ideas and that perhaps I'm giving some to y'all
<Ogromny>
Nah, fresh/divergent idea are always a good things
<riteo>
welp, gotta move my laptop, I'll keep reading the logs but I should rejoin later I think, cya!
<Ogromny>
Cya !
<ioraff>
see ya
riteo has quit [Quit: epic package system moment]
dilyn has joined #kisslinux
<dilyn>
did somebody mention ~~use flags~~
<wael[m]>
yes, infact it was riteo
<dilyn>
believe it or not, jail
<illiliti>
> that's also why I probably wanted to split the package system into two or more binaries, to keep them at doing the stupidest things and allowing for ad-hoc
<illiliti>
despite the fact that i prefer single static binary, i like this idea
<dilyn>
what is this from?
<illiliti>
it's riteo idea
<dilyn>
ah
<dilyn>
My favorite implementation was hook-editable build scripts
<dilyn>
Yeah I know why he did it, I just really enjoyed the feature
<dilyn>
simplified my own repository substantially. Once the change was reverted, I just decided to maintain my own repository and not use anyone else's
qwerty111 has quit [Quit: Client closed]
zlg has quit [Ping timeout: 268 seconds]
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
riteo has joined #kisslinux
<riteo>
hiiiii!
<riteo>
mobile riteo here
<riteo>
I read the logs, and I just wanted that by "ad hoc solution" I meant more weird package builders or who knows what, although that was a pretty big hypotetical. I should still let in the idea of throwing these pseudo use flags away and allowing myself to do weirder things
<riteo>
s/I just wanted that/I just wanted to say that/g
riteo has quit [Quit: Quit]
riteo has joined #kisslinux
<illiliti>
riteo: do you plan to add maintainer file to packages?
<riteo>
that's really secondary, but tbf I'd like to not rely exclusively on git
<riteo>
and I don't reallt like the need to commit exclusively by the maintainer
<riteo>
so I think that I'd probably add it, althout it would surely be an extension more than anything
<illiliti>
and what do you think about sandbox build? does it fit into your design?
<dilyn>
Add SPDX lines to the build file as well :v
<riteo>
absolutely, as I said ideally reproducible and system-indipendent packages are great
<riteo>
am I overengineering
<dilyn>
or just a meta file
<riteo>
be honest
<riteo>
I'm not against package metadata at all tbh
<riteo>
it's hell to understand what a package's for
<illiliti>
well, it's better to sort packages like gentoo does than introducing metadata. eg libs in sys-libs and so on
<riteo>
but I's make metadata an extension, I don't think that everyone wants it and it's surely not needed
<riteo>
just add it if a repo wants it :p
<Ogromny>
anybody tried to do a BSD fork with kiss ? Like OpenBSD/Kiss
<Ogromny>
Or FreeBSD
<riteo>
i think midfavilla
<illiliti>
merakor/cem(carbs author) tried but failed
<Ogromny>
Ah :(
<riteo>
so can you guys be honest
<riteo>
am I overengineering
<Ogromny>
Bro you fine don't worry
<Ogromny>
You just want tge best
<Ogromny>
the*
<dilyn>
"over-engineering" is just a poor euphemism for "bad programming"
<dilyn>
you should think about this in terms of scope
<riteo>
I'm trying to set one for sure, although tbf my project wants to be more a testbed for package manager ideas
<dilyn>
kiss outsources or leaves out things like maintainer information and licenses because they're out-of-scope. kiss has a hard dependency on git as coded to be fully-featured, and so we can easily outsource knowing the maintainer of any package based on the infrastructure kiss operates in
<riteo>
that's also why I want to take a highly modular approach
<riteo>
I see
<dilyn>
is this maybe a bad move? sure, but that's the design choice for kiss. It's not under-engineered, it's just moving the engineering to some where else
<riteo>
yeah tbf I critique kiss' ossession for removing actual features from stuff
<illiliti>
riteo: btw what do you think about nix approach? personally i hate declarative config cuz it limits control over system
<riteo>
I get that less is more, but nothing is not good
<riteo>
nix's idea is cool, I think that they put in a way too complicated way
<riteo>
btw switching to the laptop, brb
<illiliti>
same thing with guix
riteo has quit [Remote host closed the connection]
<illiliti>
would be awesome if we have nix without declarative garbage
<illiliti>
and without systemd of course
claudia02 has joined #kisslinux
riteo has joined #kisslinux
<riteo>
hiiiiiii!
<riteo>
I'm back!
<Ogromny>
!!
<riteo>
illiliti: regarding sorting packages, gentoo's approach is still pretty tedious to do and doesn't encourage multiple repos as much as kiss does
<riteo>
and I love multiple separately maintained repos
<riteo>
I really want to note that I'm not at all against all of kiss, I think it's definiltely a pioneer of an alternative way and reasoning behind the managing of a linux distro
<riteo>
it's staples are extremely important to me, like the 0 bus factor, the KISS principle and the self-maintainibility aspects are all fundamental in this kind of system
<riteo>
but as I already said some time ago, it feels a bit toyish, kinda like a prototype. I saw quite a few people leaving because they couldn't package certain software and that was kinda sad to see
<illiliti>
you could implement recursive repositories
<illiliti>
like, if directory contains build file, then it's package, else it's repo
<riteo>
mh
<riteo>
it'd still be hard to know about the package
<illiliti>
why
<riteo>
and the fact that we minimalist guys name their software in very simple ways doesn't help with search engines
<riteo>
illiliti: just knowing the category (which btw, would have to be standardized, ergo another mess) wouldn't be enough to satisfy most of people's curiosity tbh
<riteo>
the most we got was a README file, implemented by nobody except dylan
<riteo>
that was a genius move IMO, distro specific documentation shipped per-package and easily readable by anyone
<riteo>
actually I added a README file to the kakoune package. I never found the time to add it to lvm too, but at least I'd like to do it someday
<riteo>
in fact one of my original ideas was more of a kiss extension with some extra stuff, like an optional metadata format at the start of the README
<riteo>
now stuff drastically changed though
<riteo>
I kept the notes in chronological order, if they weren't in italian I would've sent them here probably
<riteo>
Although the big descriptive comment of the first principles (which are still valid IIRC) is in english
<riteo>
I chose to write them first in the prototype script (which I never started) so that I would not forget the then sudden blurbs of ideas
<riteo>
yeah it was meant to be kiss-compatible
<illiliti>
meant? you don't intend to be compatible with kiss anymore?
<riteo>
technically, it would be
<riteo>
but I'd experiment with an alternative system too
<riteo>
technically it can be compatible with _any_ packaging system
<illiliti>
that's interesting
<riteo>
that's the great thing about the modularity of the whole system
<riteo>
I mean, anybody can repackage stuff from one binary format to another, so that's not that big of a thing now that I think about it
dilyn has quit [Ping timeout: 272 seconds]
<riteo>
although I meant more like building straight to the new system's package format, but that doesn't sound that cool either
<illiliti>
i think i understand now the level of modularity stuff you have in mind
<riteo>
yeah, the actual and most important focus is the final binary package and the installation thing, which are* (*should) be trivial
<riteo>
and that's what I want, the dumbest most absolute stuff in the most essentials steps
chomwitt has quit [Ping timeout: 244 seconds]
<riteo>
the main idea for the binary package is a pax(?) archive with one or more folder: "root", which represents, well, the root and then any possible extensions
zlg has joined #kisslinux
<riteo>
I chose deliberately to make this extendable because unfortunately software changes constantly (I know, slippery slope), but it would be a complete mess to repackage the world because it becomes unconfortable to package something needed
<riteo>
there shouldn't me much else though, probably just a "meta" folder and perhaps (if we don't want to put it there) the original package recipe
<riteo>
into it's own folder
<riteo>
s/it's/its/
<illiliti>
nice
<riteo>
also (and this can be probably controversial), the metadata would use the filesystem as a key-value "db"
<riteo>
so, a maintainer file with the maintainer, a description file with the description and so on
<riteo>
easy to parse and clean
<riteo>
this part should be easy and fun to implement even in C, although I've never continued that C book tbrh
<illiliti>
you could also investigate squashfs format instead of pax, but it is less(?) portable
<riteo>
yeah it doesn't make me go crazy
<riteo>
it got a shitton of dependencies
<riteo>
and by shitton I mean it
<riteo>
I couldn't compile it here without wasting wayyy too much time
<riteo>
it's extremely efficient with duplicate files (even than ZPAQ AFAICT) but holy moly does it have a lot of dependencies
<illiliti>
looks bloated indeed
<riteo>
and that's a real waste IMO
riteo has quit [Quit: riteo]
riteo has joined #kisslinux
<riteo>
I have no idea what I pressed, but catgirl got angry
<riteo>
I was saying: from the README it looks like it's 10 times faster at compressing and 6 times smaller than squashfs
<riteo>
oh sorry the opposite
<riteo>
6 times faster and 10 times smaller
<riteo>
but still, I think that probably pax would be the best option as it's standard, compatible and simple(?)
<riteo>
at least if squashfs hasn't got some benefit of which I don't kno
<riteo>
s/kno/know/
<wael[m]>
you seem to be full of ideas and confidence
<riteo>
confidence none lmao
<riteo>
my ideas document goes back and forwards
<riteo>
half of the stuff I'm telling you might change from one moment to the others. It's pretty much just frustation behind some stuff and "inspiration" taken from everywhere
<riteo>
I can explain to you what thing I've "taken" from what
<riteo>
like, my package system's motto would be pracitally a mawww citation: "riteo's experiment for a better package manager"
<riteo>
(with the due credit, I'm not an asshole)
<wael[m]>
is it going to be forked from KISS? or self made?
<riteo>
the unix-y weird aspect would come from s6 (although I should study it more), the weird scrapped idea came from pip I think while the solid/immutable core _I think_ comes from hare
<riteo>
absolutely self made probably in C
<riteo>
also because I got an obsession for PD stuff, expecially when it's core
<riteo>
(Public Domain)
<wael[m]>
like XBPS?
<riteo>
what was it?
<riteo>
void's package system?
<illiliti>
aye
<riteo>
it's MIT AFAICT?
<illiliti>
bsd2
<riteo>
then the answer is no, I think
<riteo>
unless I got it wrong
<riteo>
although the hashing of the metadata is what I got in mind too originally
<riteo>
yeah I still hadn't shared that idea
<riteo>
but basically everything is checksummed, even the metadata, so that you can sign a master checksum and call it a day with pgp signing
<wael[m]>
well since you did say package manager, is that exactly what you meant? not a whole distribution?
<riteo>
ehhhhhhhhh
<riteo>
technically I'd argue that what makes a distro is the package system
<riteo>
but I'm talking about specifically the package system, although I wouldn't be too scared to make my own
<riteo>
perhaps leeching into kiss' depos with a compatibility builder
<wael[m]>
true, but consider things like musl and SSL implementation, etc etc
<riteo>
ooooh, I don't know void very well but it would surely be kiss inspired
<riteo>
as I said before I take really at heart KISS Linux's base principles
<riteo>
mainly the three listed in the website main page
<riteo>
wait one's the package depo
<wael[m]>
so like kiss, musl, openssl, busybox
<riteo>
yeah I remembered that there were written the three principles or something, well, they're the 0 bus factor and extensibility pretty much
<riteo>
yeah, like kiss
<riteo>
musl, openssl, busybox
<riteo>
although I might experiment with some stuff
<riteo>
like bearssl and some shims like oasis did, or some more permissive coreutils implementation
<riteo>
I also liked the idea of some indipendent ship for packages to put init stuff into, I could probably make a device managing too
<riteo>
s/ship/shim/
<riteo>
and hell, I might even try to make most stuff statically linked in my distro, but I don't know how far that might go
<wael[m]>
someone made a kiss repo dedicated to it, you should check it out
<riteo>
dylin?
<riteo>
IIRC he tried making a static repo
<wael[m]>
hovercat
<riteo>
oh, didn't know about that
<riteo>
but in the end the objective is making a "more usable" version of kiss which allows packaging even some less... Ideal software and in general to not shit itself at every update
<wael[m]>
I didn't know about dilyns static repo either, I like the concept but I can't even statically link dwm or st
<riteo>
that aspect is actually quite underdocumented AFAICT
<wael[m]>
riteo: I mean, I don't see any current problems of kiss yet
<riteo>
I mean, there are surely people talking about it, but there are not many actual practical examples
<riteo>
wael[m]: with time I found quite a lot in a way
<wael[m]>
what's the most important one?
<riteo>
I'd argue lack of sandboxing
<riteo>
packages keep constantly taking stuff from the system when you don't want to
<wael[m]>
so, like a chroot?
<riteo>
they continuously change and keep finding reasons to fail
<riteo>
kinda, although a proper sandbox can avoid it I think
<riteo>
just allow it to see the files of the packages it depends to and you're done
<ioraff>
a reasonable statically-linked system would need to have incremental builds
<riteo>
lately I'm allowing to be more radical, but you can absolutely make a kiss compatible improved version, I just want to allow myself to experiment with crazy ideas, since there's so much that could be done
<riteo>
ioraff: isn't ccache enough?
<riteo>
or am I understanding "incremental builds" wrong?
<illiliti>
also sandbox would prevent packages fetching data from internet at build time
<riteo>
yeah that brings on the other big issue, although "technically" not that big according who you ask, which aren't few here I think
<riteo>
most shitty but needed software can't be reasonably packaged, ask to the people who tried to package java
<riteo>
it's hell, expecially wanting to respect the (actually pretty good) no-internet build
<riteo>
... rule
<illiliti>
only package manager should be allowed to connect to internet. tarballs must be self-contained imo
<riteo>
absolutely agree
<riteo>
tbf I have a way to call this part of kiss' philosophy but I think it might be offensive
<riteo>
but I absolutely love it
<riteo>
not the nickname, the philosophy part
<riteo>
dunno if I can say, tell me if it's bad, I'll find a replacement
<Ogromny>
Pretty good idea imho
<ioraff>
riteo: not really. if a library update is ABI-compatible, one should just be able to re-link the dependent binary. if a header changes, or the build system is (poorly) written with absolute paths, then ccache won't be useful.
<riteo>
the thing is though that some stuff fails to build if you don't clean the build directory
<ioraff>
then perhaps the only way to do it is rewrite the build system for every package, like oasis.
<ioraff>
s/do it/do it reasonably/
<riteo>
I mean
<riteo>
you can do that with my hypotetical system
<riteo>
but the thing kind of stays even then
<riteo>
godot for example required a clean build at one point due to some messed up object files
<riteo>
and there are from what I can tell quite a few types of bugs that come from this
claudia02 has quit [Remote host closed the connection]
<riteo>
switching to mobile again, brb
riteo has quit [Quit: epic switching moment]
riteo has joined #kisslinux
<riteo>
here I am
<illiliti>
how do you plan to deal with go and rust? these bastards require internet to fetch deps unless you hack them or repackage tarballs
<riteo>
that's actually why I wanted to take the kuoichai route, sort of
<riteo>
worst case you make a new remote type, I can explain if you want
<riteo>
but I think that if we didn't want to make that kuiochai-style solution (which I really liked tbh), we could make a pre-build in-package hook which downloads stuff
<riteo>
since most of the stuff is AFAICT "use my shitty package manager to fetch stuff"
<riteo>
small ot thing
<riteo>
does anybody know whether gcc's asan works on musl
<riteo>
it keeps insisting that there's no asan in the start of the library path, even when statically linked
<illiliti>
no idea
<illiliti>
i would not be surprised if it works only on glibc
<riteo>
I'm leaning towards that direction
<riteo>
I should try with LLVM but bruh, godot's CI's failing with GCC's one, not LLVM's one for some reason
<illiliti>
why do you need godot?
<riteo>
illiliti read just now, sorry
<riteo>
I love it, and I want to make stuff with jt
<riteo>
s/jt/it/
<riteo>
I've been porting it to wayland for quite a while now
<riteo>
it's surprisingly musl compatible, most stuff is statically linked in, no frills at all
<riteo>
it's currently X11 only though, that's what I'm working on since ~January