<phinxy>
illiliti_: -display gtk on qemu does indeed work better than SDL
riteo has joined #kisslinux
<riteo>
hiiiiiiiiii!
<riteo>
I'm back, again!
<riteo>
(i'm not dylan though)
<riteo>
this time I should be a little bit more active here since summer started for me too :)
<illiliti_>
phinxy: nice
<illiliti_>
what are you planning to do riteo?
<riteo>
kiss-wise I got a bunch of weird ideas to experiment for a "better" package manager
<riteo>
its motto is literally "riteo's experiment for a better package manager", taken straight from kakoune
<riteo>
I've got still a lot of stuff to study but perhaps it might tell if certain things are feasible or not, and it's a great excuse to do something in C, although I've still gotta finish that book that midfavilla "borrowed" me
<riteo>
sometimes I might regurgitate whatever mess it's becoming
<riteo>
and it should technically be kiss-compatible, if things go the way I'm thinking
<riteo>
otherwise I have to write a test or two for weston to let the guys over there fix a bug that's blocking my godot port
<riteo>
since I've not been here in a while, did you already discuss about hare?
<riteo>
I'm not sure whether to learn it, but it looks very nice by how it's going
<illiliti_>
hare is nice, but lacking some features
<riteo>
it's still in development, so that's to expect I guess
<illiliti_>
for example hare has no support for dwarf, you have to resort to printf() debugging lol
<riteo>
wow I didn't know it didn't have dwarf support yet
<illiliti_>
also interop with C sucks
<riteo>
I guess they'll iron it out eventually
<illiliti_>
i hope so
<riteo>
the actual problems will come when the specification is frozen
<riteo>
which is both a great and a terrible thing ig
<illiliti_>
specification is de-facto frozen already, drew said there will be no breaking changes
<riteo>
oh, didn't he say that he found some issues with error handling?
<riteo>
like some edge case or something
<riteo>
I'm curious on how they'll fix it
<illiliti_>
dunno
<riteo>
what're you working on, instead?
<illiliti_>
right now?
<riteo>
not exactly now, in general
<illiliti_>
muon
<riteo>
the meson c implementation?
<illiliti_>
yep
<riteo>
wasn't meson like in python
<illiliti_>
it is
<illiliti_>
which is why it sucks
<riteo>
mh
<riteo>
does it have python build scripts like scons?
<riteo>
because if that's the case I wonder how you're gonna handle them
<illiliti_>
muon has no python scripts and doesn't require python. some packages require python yeah, that's problem
<riteo>
there have been proposals/drafts to switch to meson but they went to nowhere AFAICT
<riteo>
also who's Stone Tickle?
<riteo>
I looked for muon on sr.ht and it looks like that's the account muon's on
<illiliti_>
he's author of muon yeah
<riteo>
oh so you're contributing
<riteo>
I see
<riteo>
I also noticed quite a big absence of other members too, do you know what happened to them?
<illiliti_>
who exactly?
<riteo>
the guys who were active when I was too: mid, dylin, testuser and so on
<riteo>
the logs aren't that active lately
<riteo>
I dunno if they're busy with life/jobs or if they have some late summer vacations, are active only on specific hours and so on
<illiliti_>
testuser is here, mid sometimes here too, dilyn haven't been here for some time
<riteo>
I see
<illiliti_>
i'm still afloat somehow too :)
<riteo>
that's nice
<illiliti_>
some people left or rarely come here again
<riteo>
who left?
<illiliti_>
claudia iirc
<riteo>
uhh, the author of kiss-games?
<illiliti_>
aye
<riteo>
oh
<illiliti_>
E5ten also
<riteo>
I don't recall them
<riteo>
wait
<riteo>
the wyverkiss guy?
<illiliti_>
no no
<illiliti_>
that's konimex
<riteo>
oh ok, I looked their username up and found a wyverkiss repo without noticing that it was a fork
<riteo>
oh it's not even a fork, just some sort of redirect?
<riteo>
well, this community's taking an interesting turn nonetheless with the weird "disappearance" of dylan
<riteo>
and tbf, I kinda like it
<riteo>
although I'm really finding some annoying flaws with the package manager on which I'd like to work on separately
<riteo>
like the #1 issue I found is the absence of good priviledge escalation handling. Would it be hard (ignoring shell limitations) to make the package manager run as root and when building doing so into an user process?
<riteo>
That would avoid reliance on weird persistance features and improve unsupervised updating
<illiliti_>
yeah, priviledge escalation is deeply flawed. i don't like it too
<riteo>
then there are some harder or more minor issues with stuff like packages picking up whatever they like from the system, allowing for kiss to build actual circular dependencies
<riteo>
how bloated would it be to build everything inside a small container or to somehow limit what can packages do? I know that it's technically a flaw of the package, but it would be inpractical to either patch everything or just deal with it tbh
<illiliti_>
kiss needs proper sandbox. this is long-standing issue
<riteo>
can sandboxes limit what libraries can packages access?
<illiliti_>
yeah, see landlock
<riteo>
I think the hardest part would be making it "portable" or at least nicely decoupled
<riteo>
tbf I was thinking about making my test package manager as unix-y as possible, eg separating installation, building and perhaps even dependency fetching into separate programs
<riteo>
like, building a package with pkgbuild (example name) and then installing it with pkginstall, perhaps even through a pipe
<riteo>
that way binary packages would come in free
<illiliti_>
sounds interesting
<riteo>
but this is approaching that weird mumbling territory I was talking about, nothing of this has really been tested and neither properly studied
<riteo>
I really want to take more inspirations before starting, eg by studying s6 properly, which is like the best example of unix philosophy at work
<riteo>
the thing I'm most confident though is the concept of "dynamic" sources, kuiochai style
<riteo>
basically instead of hardcoding the "git+blabla" syntax, you make it some sort of executable (could be a shell script, binary plugin, whatever) and put it somewhere where it will find it
<riteo>
so stuff like fossil and [insert latest svn/download thing] would not change the actual package system specification
<illiliti_>
so you want to make it pluggable?
<illiliti_>
like pam
<riteo>
pam?
<riteo>
the user access thing?
<illiliti_>
yep
<riteo>
never properly understood that thing, so I don't know if it's similar
<riteo>
I want to make source handling modular though
<riteo>
In the case of kuiochai (a little project of mine) sources are just executables who get a string as an argument and then they parse it/do wathever they please with it
<riteo>
that's the most interesting feature I want to implement tbh
<illiliti_>
perhaps it's good idea if you come up with decent design
<riteo>
what do you mean?
<riteo>
like a properly defined document?
<riteo>
or is this idea bad?
<illiliti_>
no no, just make it sane
<riteo>
so I should make it simpler
<riteo>
mh, I didn't recall kuiochai returning the url, I surely wouldn't do that on this package system
<riteo>
but as I said, this is all a big theorical mess born from a bunch of issues I've been having with kiss
<riteo>
eventually I'll try to laid them out and test what works and what not, hence "riteo's experiment for a better package manager"
<riteo>
(with due credits to kakoune for the inspiration)
<riteo>
but surely the idea is to make it sturdier and more modular, making the smallest and most stable core possible, layering optional stuff if needed
<riteo>
hell, with the separate building thing one might make a kiss adapter that spits out the binary package for this theorethical package manager and thus making it compatible with kiss
<illiliti_>
i'm still a fan of static package manager though. dylan, noocsharp, then i attempted to create something usable but failed due to various reasons
<illiliti_>
maybe dylan is still working on k in his secret project
<riteo>
I wondered that too
<riteo>
perhaps he's gonna show us the latest and coolest iteration of kiss
<riteo>
because after all, tbh I see it as a prototype
<riteo>
a stepping stone, sure
<riteo>
but still a prototype
<illiliti_>
before he disappeared, he was working on s6 support for kiss
<riteo>
oh it's still not done?
<riteo>
I thought it worked fine, judging from the screenshots on kisslinux.org
<riteo>
the static package manager approach has its advantages for sure
<riteo>
but at the same time it's impossible to realistically support software that isn't just plain make make install stuff (which is sometimes needed)
<riteo>
even "just" java takes a lot of efforts due to both its painful bootstrapping process and its complex dependency handling
<riteo>
iirc that was the reason it got abandoned twice on kiss, due to the (IMO great) offline building requirement
<riteo>
this would allow for a gradle/ant/maven/whathever source handler or some other thing to download the dependencies ad hoc without resorting to some weird hacks (same thing for rust ig)
<illiliti_>
java is beyond repair no?
<riteo>
in what context
<illiliti_>
as a language. i don't understand why people use it
<riteo>
oh it's very messed up, I agree
<riteo>
but we can't just make it magically disappear because bloated, some stuff requires it
<riteo>
there wouldn't be java binary packages floating around after all
<riteo>
and let's not forget that dylan plays minecraft, or at least loves porting its mods to newer versions
<riteo>
so that implies that either he gave up on kiss or that he's using the binary packages or java in general on kiss
<illiliti_>
did he? i didn't know
<riteo>
wait lemme double check
<riteo>
uh, the orgs are gone
<illiliti_>
i recall muevoid was playing minecraft but not dylan
<riteo>
if you look into the graph thing, in the repos he worked on
<illiliti_>
i'd rather play terraria than minecraft imo, which is pretty good without mods
<riteo>
no wait it was not that
<riteo>
that phenomenon where people just keep adding new stuff and never finishing development because "this version wlil be better"
<riteo>
minecraft's a whole new chapter in my weird opinion book
<riteo>
it could be like, so much, but it's just so wrong and laggy and slow and going through weird stuff
<riteo>
I just gave up on it, despite loving the concept
jslick has quit [Ping timeout: 268 seconds]
<riteo>
so that's it, it's hard to make everything work and make it small and elegant, that's why I'm taking my time to take other inspirations and build something that works good enough at fixing the biggest current problems before posing new ones
jslick has joined #kisslinux
<illiliti_>
re s6, he didn't finish it, but he added support for kiss init
<riteo>
awww so I won't be able to use it on my kiss laptop?
<riteo>
there's even a repo/extra package
ejjdhfjsu_ has joined #kisslinux
<illiliti_>
yeah, but using it as init/service manager is still todo
<riteo>
that's a bummer
<riteo>
re terraria: it's still a radically different game from minecraft, despite sharing some similarities
ioraff has quit [Ping timeout: 246 seconds]
<riteo>
"radically" is effectively a big word
<riteo>
radically in some aspects, it's still an adventure sandbox
ejjdhfjsu has quit [Ping timeout: 246 seconds]
<riteo>
the first thing I'll work on will be the package file format. I thought of just using a tar with a metadata and a root folder in them
<riteo>
actually pax sounds interesting but I'm not sure on whether it's worth it
<illiliti_>
it's worth it, however there's not so many implementations
<illiliti_>
original one from 80s, incomplete one by mcf and gnu
<riteo>
but stdarc.c doesn't have pax, albeit it being an extension of star
<riteo>
also there's the autistic challenge that comes with my software of being as unlicensed as possible
<riteo>
because yes
<illiliti_>
i usually use bsd0 for algos and sometimes libraries
<riteo>
same thing as the unlicense afaict
<riteo>
but still, I try to extend it to my software too
<illiliti_>
less verbose
<riteo>
eh, the unlicense should like allow usage in pd-free countries or something like that
<riteo>
in doubt, triple license lmao
<riteo>
Unlicense/CC0/BSD0
<illiliti_>
agpl3 is the only way
<riteo>
take that lawyers
<riteo>
tbf I'm not that big of a fan for gpl software
<illiliti_>
why
<riteo>
I mean, it has its uses as a weapon on which I agree, but I feel like that using it blindly can only cause harm
<riteo>
look at google, they can take massive fines without taking a sweat
<riteo>
if they were to take your small little gpl software, what would you do?
<riteo>
in that case it would at most cause problems to the average developer, due to its viral nature
<riteo>
(and still, you'd have to spend big money to even just attempt to fine google, which would crush you)
<illiliti_>
i woudn't able to enforce gpl, but at least i could publicly shame them
<riteo>
mh
<illiliti_>
fsf could do this for me if they want
<riteo>
I guess, but you'd still have to find out
<riteo>
and still, for extremely small software it's ultra overkill
<riteo>
it's like using a nuclear bomb for a small civil war
<riteo>
I acknowledge and appreciate the weapon that the GPL can be, but I simply feel like it's not needed like 99% of the times, and it would still be hard to even just notice violations
<illiliti_>
yeah for tiny software it's overkill i agree
<illiliti_>
i also don't think that google would attempt to steal gpl software
<riteo>
publicly surely not
<riteo>
and this does not want to become a tin hat thing
<riteo>
just replace google with any big corpo or something like that, I guess it's more a thought experiment than anything
<illiliti_>
they have anti-agpl policy, they know consequences
<riteo>
I guess its purpose is just to wonder what are certain software protecting themselves from
<riteo>
the linux kernel or blender for example have their perfectly fine motives behind their gpl
<riteo>
as they want to protect themselves against as many people as possible due to their heavy nature and they also got the resources to manage any violation
<illiliti_>
i would replace google with russian/chinese companies, oh yeah they steal basically everything
<riteo>
there's a shitton of cloned gpl apps on the play store iirc
<illiliti_>
don't use play store, dunno
<riteo>
that's my main concern. Expecially with more essential stuff like even the libc or the coreutils, I find personally (although I'm a bit extremist from this point of view) that they should be as free from restriction as possible
<riteo>
oh I don't lol
<riteo>
I use fdroid
<riteo>
that's why I also care to make my implementation of this hypotethical package manager as public as possible, since it's such an essential part of the system
<riteo>
and it's would also be so niche/simple that it would not make sense to gpl it anyway
<riteo>
like kakoune
<riteo>
well, I should go to sleep
<riteo>
it's been a real pleasure talking to you, really!
<riteo>
byeeeeeeeeeee
<illiliti_>
bye! thank you too
riteo has quit [Quit: epic conversation moment]
<testuser[m]>
riteo: hi
<testuser[m]>
Hi
<illiliti_>
hi
ehawkvu has quit [Remote host closed the connection]
ejjdhfjsu_ has quit [Remote host closed the connection]
chomwitt has joined #kisslinux
jslick has quit [Ping timeout: 255 seconds]
testuser[m] has quit [*.net *.split]
psydroid has quit [*.net *.split]
psydroid has joined #kisslinux
testuser[m] has joined #kisslinux
phoebos[m] has quit [Ping timeout: 240 seconds]
lealgo[m] has quit [Ping timeout: 248 seconds]
cem[m] has quit [Ping timeout: 248 seconds]
opal[m] has quit [Ping timeout: 248 seconds]
testuser[m] has quit [Ping timeout: 252 seconds]
Guest6357 has quit [Ping timeout: 264 seconds]
konimex has quit [Ping timeout: 265 seconds]
psydroid has quit [Ping timeout: 268 seconds]
phoebos[m] has joined #kisslinux
lealgo[m] has joined #kisslinux
cem[m] has joined #kisslinux
opal[m] has joined #kisslinux
phoebos[m] has quit [Quit: Bridge terminating on SIGTERM]
lealgo[m] has quit [Quit: Bridge terminating on SIGTERM]
cem[m] has quit [Client Quit]
opal[m] has quit [Client Quit]
opal[m] has joined #kisslinux
psydroid has joined #kisslinux
testuser[m] has joined #kisslinux
konimex has joined #kisslinux
Guest6277 has joined #kisslinux
cem[m] has joined #kisslinux
lealgo[m] has joined #kisslinux
phoebos[m] has joined #kisslinux
<testuser[m]>
is there no alternative to dbus if u want to screencast with audio on ayyland? for pure video u can wf-record to v4l2 device
illiliti_ has quit [Quit: leaving]
jslick has joined #kisslinux
ella-0_ has joined #kisslinux
ella-0 has quit [Read error: Connection reset by peer]
claudia02 has quit [Excess Flood]
vouivre has joined #kisslinux
<vouivre>
hi everybody
<vouivre>
I have a question about testing a package and I thought this time I will use irc.
<omanom>
hello!
<vouivre>
what is the best way to share a log file on irc ? Something like pastebin or 0x0.st ?
<testuser[m]>
0x0
<vouivre>
ok
<omanom>
ix.io for text, as well
<vouivre>
I have post on 0x0 if it's necessary. Thank you for your suggestion omanom
<vouivre>
I want to submit a new package, mtpaint
<vouivre>
it's a painting software with a gui
<vouivre>
I have compiled it in a chroot to add the dependencies and it compiles
<vouivre>
without problem
<vouivre>
next I wanted to test it, but I get an error.
<vouivre>
I don't know if a dependency is missing or if there is a problem with the gui in the chroot
<ioraff>
phinxy: probably not right now. it says it can bootstrap 1.54.0, so we'd still need to chain together every release until 1.61.0 (unless we just ship 1.54.0). I'm thinking gcc-rs will be our best bet.