<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
<petrifiedoak>
nvm rebuilding fixed it
<petrifiedoak>
yeah nvm that didnt fix it
<petrifiedoak>
cmakelist.txt exists in the tarball
<sujo>
unrelated; kiss will generate date cache directories without proper chown
<sujo>
e.g. $XDG_CACHE_HOME/2023-07-15 is root:root, not `ls -ld | cut -d' ' -f3`
<sujo>
*$XDG_CACHE_HOME/kiss/logs/2023-07-15
<sujo>
rel. is line 2095 in kiss source
<sujo>
*2094
<sujo>
disregard prev.
<sujo>
rel. is actually 1092
<sujo>
(it's not)
<sujo>
mkdir -p ... $log_dir ...
<sujo>
results in improper perms of parent dir if DNE
<sad_plan>
yeah that happens sometimes. just delete the logsdir, or fix the permission
<sad_plan>
if you have a fix for it, by all means, make a pr for it aswell
<sujo>
will attempt one hopefully by this weekend
<sujo>
dunno where it's breaking though -- mkdir -p $cac_dir/logs/${time%-*} shouldn't do anything but make the correct directory
<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
<sujo>
nothing wrong with a few sisyphean tasks
<sujo>
rolling your own distro is bound to be an uphill battle :^)
<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
sad_plan has quit [Quit: brb]
sad_plan has joined #kisslinux
<sujo>
yup ;)
petrifiedoak has quit [Quit: Client closed]
<sujo>
i was just commenting on the sisyphean nature <-> rolling up hills
<sujo>
rolling (stones) up hills
<sad_plan>
was that the thing about rolling a stone uphilll, only to lose it and see it rolling down again or something?
<sujo>
Almost
<sujo>
> As a punishment for his crimes Hades made Sisyphus roll a huge boulder endlessly up a steep hill in Tartarus
<sad_plan>
yeah, that rings a bell
<sujo>
maybe it was a bit of a stretch, but the pieces were all there :)
<sujo>
anyway, the dispersion of the workload is certainly beneficial
<sujo>
I'll try to lighten the load with this one
<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
<sujo>
are you truly rolling your own if you're not writing the bytecode?
<sad_plan>
maybe, maybe not. that depends what youre satisfied with really
<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
<sujo>
(that was satirical)
<sujo>
but it certainly is a question of scope
<sad_plan>
sure, but some will still argue that its all or nothing :p
<sad_plan>
alot of people are.. extremists when it comes to computer stuff
<sujo>
mmmmm
<sujo>
i'd like to inject for a moment...
<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.
<sad_plan>
oh ffs. I didnt even say linux. I also dont use gnu coreutils, nor busybox for that matter
<sad_plan>
that meme is so old at this point
<sujo>
I personally use the purest form of UNIX
<sad_plan>
riight
<sujo>
bell labs (tm)
<sujo>
I run it on my OG PDP 11
<sujo>
it takes up 1/2 of the living room
<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
<sad_plan>
lol
<sad_plan>
computers were massive back then
<sad_plan>
like silly big
<sad_plan>
atleast in comparison
<sujo>
sad_plan: plan9* has a pretty decent modern suite
<sad_plan>
plan9 does, but plan9 != unix
<sad_plan>
hardware support is varying, depending on which fork one uses
<sujo>
right, but re; "release plan9 sources"
<sujo>
plan9 = unix++?
<sujo>
>plan9 is to unix what c++ is to c
<sujo>
:me
<sad_plan>
yes, but only the forks has more hardware support. the old plan9 doesnt have that, because its so old at this point
<sujo>
sometimes all you can do is fork
<sad_plan>
sure
<sujo>
but I see your point
<sad_plan>
yeah
sad_plan has quit [Quit: nyaa~]
geekthattweaks has quit [Quit: Connection closed for inactivity]
<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)
<phoebos>
as in `file a b` is run as `file a & file b`?
<xdream8[m]>
print order changes as a side effect of threading but i have a solution to this in my mind.
<sewn>
blazing fast and memory safe
ryanoats has quit [Quit: Leaving]
sad_plan has joined #kisslinux
<sad_plan>
hi
<illiliti>
phoebos: i remember i already commented on that issue, albeit here not there
<illiliti>
i think we can fix that by passing date via _KISS_DATE to children processes
<illiliti>
and then use it to construct log_dir
<illiliti>
any other bright ideas?
<sad_plan>
shouldnt I be able to find memory/cpu usage in /proc/$pid? I mostly find empty files
<sad_plan>
I was initially looking for memory usage, so one would think it should be /proc/$pid/mem, but its empty
<sad_plan>
I dont have top, so cant use that :p
<illiliti>
perhaps man proc 5 can help?
<sad_plan>
ill have to look again. maybe I missed something
<sewn>
hi sad_]plan
<sad_plan>
hi sewn
<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.