<midfavila>
sad_plan vova right now i'm just taking the core of my kiss repos and packing them up
<midfavila>
as usual the problem remains with a native build of GCC >:C
<midfavila>
all my searches result in "lol use a distro that has a native gcc that's easier'
<midfavila>
which is distinctly unhelpful
<vova>
what about going gnuless
<vova>
llvm based compiler only instead GCC based
<vova>
instead of GCC based *
<midfavila>
honestly i might use cproc+qbe to bootstrap an old gcc and then from there build a new one
<midfavila>
i'm so fuckin done with gcc's shit though i swear
<riteo>
the cproc route sounds super interesting
<sad_plan>
midfavila: that might be the way to go tbh.
fultilt has quit [Quit: Leaving]
<sad_plan>
you may also try stage0 -> mes -> tinycc-bootstrap -> gcc-2.95 -> gcc-4.7 -> any modern gcc.
ElKowar has quit [Quit: Ping timeout (120 seconds)]
ElKowar has joined #kisslinux
<vova>
also
<vova>
is anyone really interested in rewriting the kiss package manager ? a new one in C or Zig or whatever, with virtual package, restricted packages (prevent accidental deletion of kiss or busybox), sandboxed build (proot)
<vova>
I started to do it, but I hope it'll replace the POSIX shell version of it
<riteo>
vova I'm, slowly, in my free-free-time working on a lil C implementation myself
<vova>
nice, same !
<riteo>
although my very long term plans are to make a sort of fork of the package format itself to allow some niceties and optimize to a very particular usecase
<riteo>
like, I want to make an as-little-bandwidth-as-possible version of kiss, with all the complexity it might entail
<vova>
I think I'd be a good idea to create a new repo on codeberg to discuss about a new kiss package manager, with yes a new format for the files (except build), like adding a maintainer files, why not a provides file, or even join everything inside a single file like butcher (sabotage Linux)
<riteo>
and other niceties like consistent, isolated buil packaging and shit like that
<riteo>
vova: in my opinion, that would be different from kiss
<riteo>
like, kiss linux is extremely limited. That also makes it extremely simple.
<riteo>
some people might be perfectly fine with that. Think about slackware which is even simpler AFAIU
<vova>
I never used Slackware but from what I've read it's a mix of classic Unix with a port system à la *BSD
<riteo>
also wrt provides, I'd argue that there are a lot of kiss-y ways to implement that and not necessarily a provides file
<riteo>
like, in my various notes I pointed out that if a package is indeed "reproducible" as in, does not fetch shit from the environment, we could also bundle a manifest file and use that as the provides list
<vova>
do you think it'd still be a good idea to rewrite kiss in C ? It'd allow for example to not have git installed (using libgit2 directly), nor curl (libcurl), all of that statically linked in a single bin
<riteo>
so that a package could depend on a file such as `/bin/cc` `/bin/ninja` and whatever
<riteo>
vova: in all honesty, yes, a nice C statically linked version would be very worth it
<riteo>
although a distro shipping it altogether would become its own flavor of kiss, IMO
<riteo>
Maybe I'm just too nostalgic or whatever but I seriously think that the POSIX script is what made kiss... kiss
<vova>
it is in some ways
<vova>
just like the baseinit in pure POSIX shell
<riteo>
oh yeah that interface is a very overlooked part
<riteo>
an hypotethical kiss+ could build on that too
<vova>
I'm not against pure POSIX shell, but what bother me with it is the fact that you must rely on global variable instead of having something more clean with `local` variables
<vova>
a good kiss reimplementation should in any way be retrocompatible with the POSIX shell kiss version
<riteo>
yeah
<riteo>
wrt posix shell, in all fairness the medium has been stretched a bit to allow for a whole package manager to happen
<riteo>
like, given the level of complexity I'd have... Yeah I know... Gone for a proper scripting language like python
<riteo>
that's actually my workflow recently. If it's easier to mess around with python I usually do to test whether an idea is good and then write it properly in C
<riteo>
because string handling :shudders:
<vova>
hehe yeah python is nice for quick prototyping
<phinxy>
git.busybox.net has expired certificate, kiss fails to curl tarballs
<phoebos>
phinxy: yes, but in repo the busybox source is a release on busybox.net, not git