💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2023-07-15.txt captured on 2024-06-16 at 13:29:33.
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
[2023-07-15T00:37:15Z] <petrifiedoak> --enable-shared in repo/extra/python seems to break it for me
[2023-07-15T00:37:22Z] <petrifiedoak> it complains about libpython
[2023-07-15T00:37:28Z] <petrifiedoak> after removing --enable-shared it built fine
[2023-07-15T00:37:37Z] <petrifiedoak> idk if anyone else has this
[2023-07-15T00:37:45Z] <petrifiedoak> Would anyone mind checking?
[2023-07-15T00:38:30Z] <sad_plan> I have shared enabled, and rebuilt python earlier today
[2023-07-15T00:38:55Z] <sewn> petrifiedoak: you may have a issue with your toolchain of some sort
[2023-07-15T00:39:00Z] <petrifiedoak> Hm, might be a system specific issue for me
[2023-07-15T00:39:01Z] <sewn> I've also had it be built fine
[2023-07-15T00:39:10Z] <petrifiedoak> ill check the logs
[2023-07-15T00:40:06Z] <petrifiedoak> Error loading shared library libpython3.11.so.1.0: No such file or directory (needed by ./python)
[2023-07-15T00:40:26Z] <sewn> so it tried to link to something that doesn't exist
[2023-07-15T00:40:37Z] <sewn> is this a binary or freshly cooked
[2023-07-15T00:40:47Z] <petrifiedoak> freshly baked
[2023-07-15T00:41:09Z] <sewn> kiss list python | nc termbin.com 9999
[2023-07-15T00:41:15Z] <sewn> oh I mean manif
[2023-07-15T00:41:17Z] <sewn> kiss manif
[2023-07-15T00:41:42Z] <sewn> may also wanna check ldd /usr/bin/python
[2023-07-15T00:42:11Z] <petrifiedoak> yeah its working fine after removing --shared-library
[2023-07-15T00:42:20Z] <petrifiedoak> https://termbin.com/2hz6m
[2023-07-15T00:44:25Z] <sewn> petrifiedoak: that's because python would be statically linked
[2023-07-15T00:44:39Z] <sewn> I assume the manifest you gave me is the one without shared library
[2023-07-15T00:44:56Z] <sewn> but I'd python is dynamically linked it would fail to find libpython?
[2023-07-15T00:45:18Z] <petrifiedoak> yeah the manifest is the one without shared library
[2023-07-15T01:23:34Z] <petrifiedoak> https://termbin.com/zgpq, cmake just failed. Anyone mind helping me?
[2023-07-15T01:34:32Z] <sad_plan> can you find the file yourself, if you unpack the tarball manually? seeing as it appears to error out on a missing cmakelist.txt file
[2023-07-15T01:35:37Z] <petrifiedoak> nvm rebuilding fixed it
[2023-07-15T01:43:13Z] <petrifiedoak> yeah nvm that didnt fix it
[2023-07-15T01:43:19Z] <petrifiedoak> cmakelist.txt exists in the tarball
[2023-07-15T02:00:25Z] <sujo> unrelated; kiss will generate date cache directories without proper chown
[2023-07-15T02:02:34Z] <sujo> e.g. $XDG_CACHE_HOME/2023-07-15 is root:root, not `ls -ld | cut -d' ' -f3`
[2023-07-15T02:05:42Z] <sujo> *$XDG_CACHE_HOME/kiss/logs/2023-07-15
[2023-07-15T02:06:57Z] <sujo> rel. is line 2095 in kiss source
[2023-07-15T02:07:11Z] <sujo> *2094
[2023-07-15T02:08:26Z] <sujo> disregard prev.
[2023-07-15T02:08:41Z] <sujo> rel. is actually 1092
[2023-07-15T02:10:58Z] <sujo> (it's not)
[2023-07-15T02:11:14Z] <sujo> mkdir -p ... $log_dir ...
[2023-07-15T02:12:42Z] <sujo> results in improper perms of parent dir if DNE
[2023-07-15T02:18:23Z] <sad_plan> yeah that happens sometimes. just delete the logsdir, or fix the permission
[2023-07-15T02:18:39Z] <sad_plan> if you have a fix for it, by all means, make a pr for it aswell
[2023-07-15T02:20:15Z] <sujo> will attempt one hopefully by this weekend
[2023-07-15T02:33:48Z] <sujo> dunno where it's breaking though -- mkdir -p $cac_dir/logs/${time%-*} shouldn't do anything but make the correct directory
[2023-07-15T02:34:29Z] <sad_plan> this has to my knowledge been an issue for a rather long time. so I have no clue. I suppose someone wouldve fixed it already if people knew why it was missbehaving
[2023-07-15T02:35:56Z] <sujo> nothing wrong with a few sisyphean tasks
[2023-07-15T02:36:11Z] <sujo> rolling your own distro is bound to be an uphill battle :^)
[2023-07-15T02:37:19Z] <sad_plan> if you aim to solely fix everything yourself, then sure. but not if you can check what other people does aswell. I maintain most of the packages I use, and I dont face too much issues. atleast not anymore :p
[2023-07-15T02:40:09Z] <sujo> yup ;)
[2023-07-15T02:40:31Z] <sujo> i was just commenting on the sisyphean nature <-> rolling up hills
[2023-07-15T02:40:43Z] <sujo> rolling (stones) up hills
[2023-07-15T02:41:21Z] <sad_plan> was that the thing about rolling a stone uphilll, only to lose it and see it rolling down again or something?
[2023-07-15T02:42:03Z] <sujo> Almost
[2023-07-15T02:42:05Z] <sujo> > As a punishment for his crimes Hades made Sisyphus roll a huge boulder endlessly up a steep hill in Tartarus
[2023-07-15T02:42:27Z] <sad_plan> yeah, that rings a bell
[2023-07-15T02:43:42Z] <sujo> maybe it was a bit of a stretch, but the pieces were all there :)
[2023-07-15T02:44:10Z] <sujo> anyway, the dispersion of the workload is certainly beneficial
[2023-07-15T02:44:22Z] <sujo> I'll try to lighten the load with this one
[2023-07-15T02:45:20Z] <sad_plan> theres no need to do the work twice. so to speak. if someone else has already done the work (for you), why should you redo it. atleast thats an argument against maintaning everything yourself
[2023-07-15T02:46:15Z] <sujo> are you truly rolling your own if you're not writing the bytecode?
[2023-07-15T02:46:50Z] <sad_plan> maybe, maybe not. that depends what youre satisfied with really
[2023-07-15T02:47:26Z] <sad_plan> someone might argue that its all or nothing, while others will still say they maintain their own distro, and still have packages not maintained by themselves on the system
[2023-07-15T02:48:50Z] <sujo> (that was satirical)
[2023-07-15T02:49:02Z] <sujo> but it certainly is a question of scope
[2023-07-15T02:49:10Z] <sad_plan> sure, but some will still argue that its all or nothing :p
[2023-07-15T02:49:24Z] <sad_plan> alot of people are.. extremists when it comes to computer stuff
[2023-07-15T02:49:39Z] <sujo> mmmmm
[2023-07-15T02:49:46Z] <sujo> i'd like to inject for a moment...
[2023-07-15T02:51:11Z] <sujo> What you are referring to as Linux is in fact GNU/Linux or as recently i have taken to calling - GNU+Linux. Linux is not an operating system unto itself but rather another free component of a full functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
[2023-07-15T02:52:06Z] <sad_plan> oh ffs. I didnt even say linux. I also dont use gnu coreutils, nor busybox for that matter
[2023-07-15T02:52:13Z] <sad_plan> that meme is so old at this point
[2023-07-15T02:53:18Z] <sujo> I personally use the purest form of UNIX
[2023-07-15T02:53:34Z] <sad_plan> riight
[2023-07-15T02:53:52Z] <sujo> bell labs (tm)
[2023-07-15T02:54:34Z] <sujo> I run it on my OG PDP 11
[2023-07-15T02:54:41Z] <sujo> it takes up 1/2 of the living room
[2023-07-15T02:54:51Z] <sad_plan> but unix doesnt work on modern hardware, does it? I know they released plan9 sources under MIT or something couple years ago though
[2023-07-15T02:54:54Z] <sad_plan> lol
[2023-07-15T02:55:02Z] <sad_plan> computers were massive back then
[2023-07-15T02:55:13Z] <sad_plan> like silly big
[2023-07-15T02:55:19Z] <sad_plan> atleast in comparison
[2023-07-15T02:55:21Z] <sujo> sad_plan: plan9* has a pretty decent modern suite
[2023-07-15T02:55:37Z] <sad_plan> plan9 does, but plan9 != unix
[2023-07-15T02:56:17Z] <sad_plan> hardware support is varying, depending on which fork one uses
[2023-07-15T02:56:26Z] <sujo> right, but re; "release plan9 sources"
[2023-07-15T02:56:48Z] <sujo> plan9 = unix++?
[2023-07-15T02:56:58Z] <sujo> >plan9 is to unix what c++ is to c
[2023-07-15T02:57:03Z] <sujo> :me
[2023-07-15T02:57:29Z] <sad_plan> yes, but only the forks has more hardware support. the old plan9 doesnt have that, because its so old at this point
[2023-07-15T02:59:20Z] <sujo> sometimes all you can do is fork
[2023-07-15T02:59:31Z] <sad_plan> sure
[2023-07-15T02:59:35Z] <sujo> but I see your point
[2023-07-15T02:59:54Z] <sad_plan> yeah
[2023-07-15T07:13:39Z] <phoebos> https://codeberg.org/kiss-community/kiss/issues/98
[2023-07-15T11:50:28Z] <testuser[m]> hi
[2023-07-15T11:51:24Z] <sewn> hi
[2023-07-15T15:01:12Z] <ruivlea> i built llvm 16.0.6. some sed needed https://codeberg.org/ruivlea/siss/src/branch/main/extra/llvm/build
[2023-07-15T15:02:50Z] <ruivlea> clang 16.0.6 also can be built. but cmake source needed. https://codeberg.org/ruivlea/siss/src/branch/main/extra/clang
[2023-07-15T15:39:30Z] <sujo> phoebos: o7
[2023-07-15T15:56:35Z] <xdream8[m]> I implemented shinit in rust
[2023-07-15T15:56:35Z] <xdream8[m]> https://codeberg.org/XDream8/rinit
[2023-07-15T16:12:33Z] <xdream8[m]> I am planning to write a service manager in rust too
[2023-07-15T17:15:35Z] <sewn> how big is rinit
[2023-07-15T17:29:43Z] * xdream8[m] sent a sh code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/508adcd7bf3f8a75efd192069c71a83cd65e5e25
[2023-07-15T17:30:34Z] <xdream8[m]> I already packaged it in my repo: https://codeberg.org/XDream8/kiss-repo/src/branch/main/core/rinit
[2023-07-15T17:32:53Z] <xdream8[m]> it works exactly same as shinit and it should give better performance overall when you compile it using release or optimized profile
[2023-07-15T19:32:08Z] <xdream8[m]> I started writing a service manager in rust: https://codeberg.org/XDream8/rsv
[2023-07-15T19:41:40Z] <sewn> why use env? runsvdir doesn't do that
[2023-07-15T19:44:38Z] <xdream8[m]> I know it is for testing. i set it to example_services directory to test how it runs.
[2023-07-15T19:45:05Z] <xdream8[m]> https://codeberg.org/XDream8/rsv/src/branch/master/example_services
[2023-07-15T19:46:34Z] <xdream8[m]> currently it is a WIP
[2023-07-15T19:55:01Z] <phoebos> why would rust have better performance for launching a shell script
[2023-07-15T20:15:16Z] <xdream8[m]> rust should have better performance in managing signals
[2023-07-15T20:16:32Z] <xdream8[m]> also rust binaries generally just start a lot faster than shell scripts
[2023-07-15T20:17:43Z] <xdream8[m]> An example with benchmarks may be this: https://codeberg.org/XDream8/file-rs
[2023-07-15T20:21:38Z] <xdream8[m]> but i wrote `file-rs` to be a lot faster than `file` so these are not so true.
[2023-07-15T20:21:38Z] <xdream8[m]> like where as `file-rs` uses threading but `file` does not
[2023-07-15T20:34:41Z] <phoebos> your file-rs does a lot less than file, so it's unsurprising it's faster
[2023-07-15T20:36:37Z] <phoebos> what do you use threading for
[2023-07-15T20:42:36Z] <xdream8[m]> files types/mimetypes/extensions are processed in threads
[2023-07-15T20:42:37Z] <xdream8[m]> https://codeberg.org/XDream8/file-rs/src/commit/a53211d56cad9b7cd1555854ef3b33a579813a9b/src/main.rs#L66
[2023-07-15T20:44:20Z] <xdream8[m]> You can set how much threads you want to use with --jobs/-j flag(if you dont set it explicitly, file-rs automatically detects number of cpus you have and sets it)
[2023-07-15T20:45:07Z] <phoebos> as in `file a b` is run as `file a & file b`?
[2023-07-15T20:52:57Z] <xdream8[m]> print order changes as a side effect of threading but i have a solution to this in my mind.
[2023-07-15T20:53:52Z] <sewn> blazing fast and memory safe
[2023-07-15T21:18:47Z] <sad_plan> hi
[2023-07-15T21:23:00Z] <illiliti> phoebos: i remember i already commented on that issue, albeit here not there
[2023-07-15T21:26:15Z] <illiliti> i think we can fix that by passing date via _KISS_DATE to children processes
[2023-07-15T21:27:18Z] <illiliti> and then use it to construct log_dir
[2023-07-15T21:28:24Z] <illiliti> any other bright ideas?
[2023-07-15T21:42:51Z] <sad_plan> shouldnt I be able to find memory/cpu usage in /proc/$pid? I mostly find empty files
[2023-07-15T21:43:08Z] <sad_plan> I was initially looking for memory usage, so one would think it should be /proc/$pid/mem, but its empty
[2023-07-15T21:43:18Z] <sad_plan> I dont have top, so cant use that :p
[2023-07-15T22:12:20Z] <illiliti> perhaps man proc 5 can help?
[2023-07-15T22:16:46Z] <sad_plan> ill have to look again. maybe I missed something
[2023-07-15T22:19:44Z] <sewn> hi sad_]plan
[2023-07-15T22:19:50Z] <sad_plan> hi sewn
[2023-07-15T22:28:52Z] <sad_plan> it seems that I should be able to view it, but it requires CONFIG_PROC_PAGE_MONITOR to be enabled in kernel. which ive not enabled. /proc/pid/smaps should as far as I can tell from the manpage show usage.