<asdfhjkl>
This functionality allows users to set their own git mirroring sources for all upstream, such as what I have right now https://git.asdfhjkl.xyz/asdf/ to e.g. sync upstream sources locally at the LAN, and always have the full source code for the whole world without the internet connection being required
<testuser[m]>
asdfhjkl: so bad
<testuser[m]>
there shouldn't be variable substitution in sources file at all
<testuser[m]>
and your variable doesn't elucidate the problem well cuz you're not going to have a mirror for all pkgs on your git
<testuser[m]>
Why not just download all tarballs and ync to ur cache
<wael[m]>
hHI
<wael[m]>
Hi
trunc88 has joined #kisslinux
trunc88 has quit [Client Quit]
_whitelogger has joined #kisslinux
<wael[m]>
is kiss (the package manager) supposed to have a Makefile?
Torr has quit [Quit: leaving]
<asdfhjkl>
> there shouldn't be variable substitution in sources file at all
<asdfhjkl>
There is no substitution happening in the sources file. Happens at kiss level if you set an env var. Optional.
<asdfhjkl>
> cuz you're not going to have a mirror for all pkgs on your git
<asdfhjkl>
I already do, if I understand you correctly. I've setup mirrors to upstream all original sources for `repo/core` already, currently right here at the moment, https://git.asdfhjkl.xyz/asdf/ , will be better organized later
<asdfhjkl>
> Why not just download all tarballs and ync to ur cache
<asdfhjkl>
Because I want to sync everything from my own git server that mirrors various different git servers from upstream
<asdfhjkl>
testuser[m]
<testuser[m]>
running latest git of everything will break most stuf
<asdfhjkl>
Why? It's pinned to hash
<asdfhjkl>
Can just bump my hashes every few months, and if they don't build, look at the kiss project first and merge the fix in, or solve it myself
<asdfhjkl>
Keep going if you have more concerns, I need this kind of feedback to think it all through
<testuser[m]>
kiss the pkg manager isn't going to support temptation of sources file
<testuser[m]>
VERSION markers are also going to be removed
<testuser[m]>
it should be fully static
<asdfhjkl>
temptation?
<testuser[m]>
if u want u can generate it urself with m4 and switch repos when source goes down
<asdfhjkl>
All I'm doing is modifying one function of kiss, https://pastebin.com/raw/5MiXi5Z1 which allows the user to override git sources entirely, in such a way that it will use YOUR self hosted git server to fetch git packages. It leaves tarball configured packages, such as community, alone
<asdfhjkl>
The idea behind it is having the full source code repositories available on your system, by default, for everything, via your self hosted mirror - which later can be federated in various ways, decentralizing the distro. It's a distro hackers dream IMO.
<asdfhjkl>
To do it though, you need a git server mirroring all upstream of core. (Like I have done.) And you have to fork repo, converting it to use git repos for everything, and have to fork your kiss, at this time at least, adding my code as a patch, I suppose.
rohan has quit [Ping timeout: 246 seconds]
rohan has joined #kisslinux
<testuser[m]>
kiss can't implement eval for sources, or any variable that's going to be substituted
<testuser[m]>
Cuz the sources files should always be static
<testuser[m]>
Preprocessing can be done on your side
<testuser[m]>
inactive will have repo which is down
<testuser[m]>
this is just unnecessary complexity
<testuser[m]>
If needed it can be done outside kiss
<testuser[m]>
due to modularity
<testuser[m]>
eg sources are not hardcoded in build file
<testuser[m]>
so you can just make sources a symlink
<testuser[m]>
and keep the rest
<asdfhjkl>
What you call complexity I think is elegant, I suppose.
<asdfhjkl>
I don't want to manage a bunch of symlinks. If I have a git server that is mirroring the entirety of `repo/core`'s upstream sources, then I want to just fork my own `repo` and tell kiss to use my git server to get everything.
<asdfhjkl>
Doing this, I can have a personal git server, consolidated, that has the sources, to the whole world, coming from the source of truth directly, and I can still track the kiss project's progress in the package build files, and I can point a whole kiss farm of computers at my git server to get what I need distributed to my machines, and additionally,
<asdfhjkl>
each computer will store its own copy of things in ~/.cache as well (backups of backups). I could run this whole project with a self hosted git server if I wanted, I'm just that much closer to the source of truth, and I'm not that much closer to running my own distro project, not requiring some official release tarball, and running my own mirror,
<asdfhjkl>
when upstream sources go down, my mirror stays up. Federated kiss.
<wael[m]>
what the fart
<asdfhjkl>
lmao
<testuser[m]>
asdfhjkl: symlink method is much more elegant. Same thing. Swappign environment variable in /etc vs swapping a symlink with a script that let's you choose among servers
<testuser[m]>
Symlink usage doesn't need kiss modifications
<asdfhjkl>
Ok let's flesh out your approach so that I make sure I understand what you mean testuser[m] :)
<asdfhjkl>
So in your method, one would just apply a symlink to all of the `sources` files within their forked version of `repo`?
<testuser[m]>
ill send
<testuser[m]>
Wai
<asdfhjkl>
K
<asdfhjkl>
Because I considered writing a script that iterates through `sources` and changes them to use the git server that I want, but then I thought - what if someone else wants to use a git server that's not my git server?
<asdfhjkl>
So, the environment variable in /etc/ was the idea, but then I found that kiss can't process environment variables within `sources`, so then I modified kiss instead to detect the environment variable during section when it is setting the remotes.
<asdfhjkl>
But I suppose you're saying, that instead, I could have some odd 23 different sources files generated for all of core, where my forked version of repo contains only symlinks, pointing to each sources file that contains my git server in the url
<asdfhjkl>
see I don't want to have a directory tree with 23 unique sources files when I can just set one environment variable
<testuser[m]>
Yea generated source file for every git remote, so ~/Active is symlink to either ~/MyGit or ~/TheirGit, and MyGit/TheirGit have corresponding sources files for pkgs
<testuser[m]>
Generated by script
<asdfhjkl>
Yeah...
<testuser[m]>
i don't see how extra files is a problem if you use a script
<asdfhjkl>
Well, with my approach, it's definitely a commitment, because it'll rewrite every single git url to be your git server declared in /etc/profile and if you don't host that code, then that package ain't going to build.
<asdfhjkl>
Vs.
<asdfhjkl>
your approach does have the flexibility of pointing only those particular repos that you are interested in having git sources for usage of.
<asdfhjkl>
However, AFAIK, all code in repo and community is using tarballs by default anyways right now.
<testuser[m]>
Anyways there's no sane mechanism to substitute variables in files without eval
<testuser[m]>
Other than using external C tools
<asdfhjkl>
I'm going to keep hacking my fork
<asdfhjkl>
I can revert to your approach later if I like it better after trying it
<asdfhjkl>
Thanks for the ocmments man
<asdfhjkl>
comments*
dotkwa[m] has joined #kisslinux
asdfhjkl has quit [Quit: Client closed]
asdfhjkl has joined #kisslinux
asdfhjkl has quit [Client Quit]
asdfhjkl has joined #kisslinux
dilynm has quit [Remote host closed the connection]
dilynm has joined #kisslinux
<wael[m]>
anyone here know of any other good X tiling/dynamic window manager other than dwm or bspwm
<wael[m]>
starting to get a little bored of dwm
<asdfhjkl>
i like dwm it's smart in the way it manages space imo
<asdfhjkl>
but ratpoison gives a more gnu screen-like experience which can be better on smaller laptop monitors
<asdfhjkl>
exwm is great on X for emacs users who want emacs everywhere, or there is also stumpwm if you want to hack in common lisp, or monad for haskellers
<asdfhjkl>
xmonad*
<wael[m]>
i said good X tiling/dynamic window manager :D
<asdfhjkl>
Ah
brassado has joined #kisslinux
<asdfhjkl>
Well dwm is unbeatable so get back to work and let it keep doing the Lord's work
asdfhjkl has quit [Quit: Client closed]
brassado is now known as sam_sepi0l
<wael[m]>
fair enough.
dilynm has quit [Remote host closed the connection]
wael_ has quit [Remote host closed the connection]
wael_ has joined #kisslinux
wael_ has quit [Remote host closed the connection]
wael_ has joined #kisslinux
<wael_>
finally i think i got bouncing working woo
vbt is now known as santa25
asdfhjkl has joined #kisslinux
dilynm has quit [Ping timeout: 256 seconds]
schillingklaus has joined #kisslinux
Torr has joined #kisslinux
dilynm has joined #kisslinux
schillingklaus has quit [Remote host closed the connection]
<midfavila>
working on the high-level draft of my next revision of apport, looking at eliminating branches as much as possible
<midfavila>
wanted a way in particular to set the protocol to be used in a more elegant fashion than an if-then-else chain of strcmps
<midfavila>
friend suggests i use this routine, dlsym, to have the program inspect its own symbol table at runtime
<midfavila>
and i'm sitting here grinning like an idiot because of how cool of an idea that is
<midfavila>
i didn't even think to check for this sort of routine in POSIX
<noocsharp>
an alternative would be to have a struct of function pointers which specifies an interface to a particular protocol
<noocsharp>
rather, an abstract interface for any protocol
<noocsharp>
and using a hash table or something to map protocols to their struct
<noocsharp>
much simpler and more practical since it's a pretty common technique used in c
<midfavila>
considering i have no clue how to implement a practical hash table, that's a no go
<midfavila>
but that method would also be much more complex in terms of memory and CPU time, and conceputally, too. with this, it's... load the program's symbol table at runtime, break the URI up, check to see if there's a routine with the same name as the protocol segment of the URI. done
<midfavila>
plus this method makes it easier to move apport's main functions out into a library in the future
<midfavila>
and it in turn makes that library easy to extend
<midfavila>
no need to maintain tables or anything manually, no hash function. offloads all the work to the OS
<midfavila>
idk
<noocsharp>
a lot of libraries use the struct of function pointers technique to abstract over different backend
<noocsharp>
backends*
<midfavila>
i mean
<midfavila>
okay
<midfavila>
that's fine if it works for them
<midfavila>
but i want to try it this way
<noocsharp>
good luck, i couldn't get dlsym to give me the address of the main function lol
<midfavila>
i think it has some merits over that method and it's easier for me to implement and reason about
* midfavila
shrugs
<noocsharp>
i know elegance is subjective, but using the dynamic linking library like this doesn't feel very elegant
<midfavila>
right now, yeah, it's obviously a bit of a hack
<midfavila>
a program loading itself to determine what to do at runtime is kinda in the same vein as self-modifying code, at least to me
<midfavila>
but apport from the beginning has been intended as a curl replacement library
<midfavila>
having a single library to provide an abstraction over sockets, and then that library being able to dynamically link in submodules as necessary during runtime, is a fairly decent design, in my opinion
<midfavila>
the final version won't have a single executable that handles everything loading a copy of itself, that's just silly
<noocsharp>
yeah, that seems pretty reasonable
<midfavila>
instead the idea is to have apport sit atop libapport, and then load submodules for, say, HTTP and TLS, or just gopher, or gopher and TLS, or... literally anything
<midfavila>
and then have the submodule do all the hard work implementing the protocol
<midfavila>
this could extend to ftp, spartan, gemini, smtp, any TCP/IP protocol
<midfavila>
this would make, in turn, a general-purpose frontend like apport *very* versatile
<noocsharp>
what's wrong with curl?
<midfavila>
without needing to recompile apport or libapport, you could, independent of anyone else, write a submodule for libapport that adds your favorite protocol and then *immediately* have a client with a familiar UX available
<midfavila>
curl is gargantuan, does a bunch of shit i don't care about, and it doesn't build with tcc
<midfavila>
it also requires an oSSL-compatible TLS implementation
<midfavila>
apportate has used libtls from the beginning
<noocsharp>
uhh, curl has bearssl support
<midfavila>
does it? news to me
<midfavila>
regardless, the use of libtls in particular is what i'm interested in
<midfavila>
dropbear is great, but it's also niche right now. writing software that uses it directly either constrains the number of people who can use it, or requires you double up on effort by writing an oSSL-compatible routine in your program
<midfavila>
using libtls makes it trivial to port to really any existing tls implementation
<midfavila>
idk
<midfavila>
this is just how i see things. probably wrong
<midfavila>
er
<midfavila>
bearssl
<midfavila>
not dropbear
<midfavila>
wtf
<midfavila>
muscle memory turns any technical mention of "bear" into dropbear, and i'm too braindead rn to notice that. i've eaten like
<midfavila>
two eggs and a small banana and that's it today, bleh
<noocsharp>
do you know why curl doesn't build with tcc?
<noocsharp>
like what features is tcc lacking that curl uses
<midfavila>
haven't checked in a while
<midfavila>
i might have also misremembered that
<midfavila>
let me check
<midfavila>
a while back i went through my new repo and mentally classed anything that depended on something that doesn't build with tcc as also unable to build with tcc
<midfavila>
...christ this is gonna take forever to download