<midfavila>
nothing about sys_siglist being undefined?
pbsds has joined #kisslinux
<ioraff>
nope
<midfavila>
strange
<midfavila>
must have something to do with the binutils
<ioraff>
linked with bfd, if that matters.
<midfavila>
yeah, it probably does
<ioraff>
what did you link it with?
<midfavila>
tccld
<ioraff>
actually, it seems like it uses its own linker by default
<midfavila>
what version of tcc and dash?
<ioraff>
git, 0.5.11.5
<midfavila>
my dash is a little older... hrm
<midfavila>
maybe they fixed the references to sys_siglist
ejjdhfjsu has joined #kisslinux
<midfavila>
...wtf
<midfavila>
wiped out my chroot and unpacked just to make sure I had a clean environment, now 'm getting a different error
<midfavila>
something is definitely fucky-wucky
<midfavila>
oh, no, wait. the actual error was still undefined references to sys_siglist
<testuser[m]12>
Hi
<ioraff>
hi
<midfavila>
i see what's going on - dash implemented a wrapper for strsignal that uses sys_siglist if the function isn't available, and it's not detecting it with my new rootfs for some reason
ejjdhfjsu has quit [Remote host closed the connection]
ejjdhfjsu has joined #kisslinux
<midfavila>
okay, weird
<midfavila>
turns out, autotools is just shit and wasn't detecting things properly
<midfavila>
spent a few minutes fiddling with config.h, works fine now
<midfavila>
:thinking:
<midfavila>
turns out, replacing autotools with plain make solves most of my problems
<midfavila>
wild
<midfavila>
well, tcc officially seems capable of compiling TinyX
sad_plan has joined #kisslinux
<sad_plan>
hi
<midfavila>
hello again
<wael[m]>
hi
<midfavila>
was just mentioning tinyx
<sad_plan>
yeah, I was reading through the logs as we speak. it did build with tcc I see
<sad_plan>
thats really cool.
<midfavila>
yep
<sad_plan>
i didnt know tcc had its own linker either. I thought it was just a compiler tbh
<midfavila>
just need to get its dependencies to compile and rewrite the build system to not depend on autotools
<midfavila>
and yeah, tcc is a complete dev toolchain
<midfavila>
has x86 and arm assemblers, as well as a linker and a compiler, and a preprocessor as well
<midfavila>
it puts its ~100k lines to good use
<sad_plan>
yeah. did you get my comment regarding libXdmcp btw? its not needed after all
<midfavila>
yeah I saw that
<midfavila>
i'm more concerned about stuff like libpng though
<sad_plan>
good
<midfavila>
why is that listed as a dep?
<sad_plan>
links to libpng
<sad_plan>
atleast on my end
<sad_plan>
does it not on your end?
<midfavila>
it does, but presumably in an opportunistic fashion
<midfavila>
i don't go off of kiss' autodep generator
<midfavila>
to be blunt, it's fucking trash
<sad_plan>
hm. perhaps.
<sad_plan>
I went off of what it linked to to begin with atleast
<midfavila>
there have been so many packages i've had to fix where someone built it and threw the output of kiss' dep generator into depends
<sad_plan>
it aint perfect, but its usually what I use
<midfavila>
it's... *fine*, I guess
<midfavila>
if there's no other option
<sad_plan>
yeah
<midfavila>
but i usually consult the project itself and then LFS, followed by Alpine, Gentoo and finally Debian
<sad_plan>
yeah, I have just been reading the readme for the most part. theres just not a whole lot of docs on it. else kyx0r has been working on it somewhat
<sad_plan>
im rebuilding tinyx now without libpng, and ill see if it builds correctly
<midfavila>
cool, keep me posted
<sad_plan>
noo, libpng is required
<midfavila>
lame
<midfavila>
that means libtool is required and perl by proxy
<sad_plan>
Package 'libpng', required by 'freetype2', not found
<midfavila>
can you not disable freetype?
<midfavila>
if freetype can't be disabled then tcc goes out the window
<sad_plan>
theres no flag for it in the configure script that Im aware of
<sad_plan>
I could look
<midfavila>
hrm
<midfavila>
might need to patch it
<midfavila>
tinyx itself i mean
<sad_plan>
yeah
<sad_plan>
but no, theres no flag for freetype. not anything thats clearly labeled anyway
<midfavila>
hrm
<sad_plan>
freetype is mentioned in several of the makefiles actually
<midfavila>
yeah, i ran a grep on them
<midfavila>
almost certainly going to need a patchjob
<sad_plan>
yeah
<midfavila>
well,
<midfavila>
my response is that things should start with ripping out just Xfbdev
<midfavila>
and then a makefile should be set up for it,
<midfavila>
and then patching can start
<sad_plan>
dont you mean Xvesa? I cant even use Xvesa as its only for 32-bit
<midfavila>
oh, i wasn't clear, my bad
<midfavila>
i meant that xfbdev should be made its own thing
<midfavila>
and the rest left to die
ejjdhfjsu has quit [Remote host closed the connection]
ejjdhfjsu has joined #kisslinux
<midfavila>
my vision is to get xfbdev working as an interim solution, and then start work on kicking MGR into shape
<midfavila>
in particular, this one actually builds
<midfavila>
(although it uses cmake)
<sad_plan>
ah, yeah xvesa is no longer relevant. I simply deleted it after building in my buildscript, but I wanted to patch it out too actually. but havent looked much into it
<sad_plan>
does mgr even work anymore on any recent computer? I mean, seeing as its from the 80s
<midfavila>
well, if nothing else it compiles and runs on my system
<sad_plan>
not that that is an argument for something not working though
<midfavila>
it doesn't *do* anything, at least that I can tell
<midfavila>
but it does compile and "work"
<sad_plan>
ah, cool
<midfavila>
i've seen another project that got it working as an X client
<midfavila>
and I mean, I wouldn't count it out just 'cause it's an old program
<midfavila>
motif is from the 80s and it runs like a dream
<sad_plan>
probably cause its *properly* made? I dunno. I tend to assume if something is properly written, it probably works longer in any case. atleast if its portable anyway
<midfavila>
well, i think mgr was properly written for its time
<midfavila>
but there are definitely archaic elements to its design
<midfavila>
the main element that strikes me atm is the limitations on mouse input it has
<midfavila>
(specifically requires a one, two, or three-button microsoft protocol serial mouse, a bus mouse, or something similar)
<midfavila>
or ps/2
<midfavila>
but such things could be changed readily
<midfavila>
honestly, with a little effort, i could see myself *really* enjoying mgr
<sad_plan>
hm, it seems we might be able to rid xvesa from the makefile. it is a messy gnu makefile, but Im sure we can find the switch for it there. im on to something now. would be nice to not even need to build xvesa tbh
<sad_plan>
cool
fitrh has joined #kisslinux
midfavila has quit [Remote host closed the connection]
<sad_plan>
fucking hell, for whatever reason it complains about missing libXdmcp instead, even though its disbled. I removed vesa from one of the makefiles, so that make wouldnt even go there..
ejjdhfjsu_ has joined #kisslinux
ejjdhfjsu has quit [Ping timeout: 252 seconds]
ioraff has quit [Ping timeout: 268 seconds]
vouivre has joined #kisslinux
<vouivre>
hello
<sad_plan>
hi
<wael[m]>
hallo
<vouivre>
sad_plan: did you see the issue I created about fzy ?
<vouivre>
it was your suggestion
<sad_plan>
yeah, I made a comment there. but dylin has answered, nor has anyone else for that matter
<sad_plan>
in any case, me or you can simply make a PR for it, and refer it to the issue. I have built it with the features you mentioned, including all of neo-arch's patches, and there were no issues on my end. I can make a pr if youd like
<wael[m]>
please make a fzy fork
<vouivre>
I really like your suggestion. Why not patching ytfzf. Why a fork ? To merge the PR ?
<wael[m]>
shitty reason - i am blocked from fzy repository
<vouivre>
So you wouldn't be able to install it ?
<wael[m]>
plus good many pull requests get ignored - included a feature i liked, and when i tried to ask why i got blocked
<wael[m]>
i can still use fzy but theres missing features that go unnoticed by the maintainer
<vouivre>
HHhhmmm, I remember something now.
<sad_plan>
it all depends on wether or not it makes a difference for others or not. I mean, im probably not the only one who uses ytfzf, and if other people notice theres a difference, or some features lacking, they might complain about it. hence me wanting to get someone elses opinion on the matter.
<sad_plan>
regarding fzy, I see no issue in adding it to the community repo anyway
<wael[m]>
have a look at any pull request in the fzy repository
<sad_plan>
Im aware of the pr, its said pr we're refering to. which neo-arch has made a pr for. we're planing including them untill theyre included in the upstream.
<vouivre>
you are right about the opinion of other users.
<sad_plan>
we might be better of creating a separate issue regarding using fzy with ytfzf though. seeing as theyre seperate things
<sad_plan>
yeah. I wouldnt be too happy either if I used a tool, and suddenly someone removed some vital features I used
* sad_plan
shrugs
<vouivre>
wael[m]: I didn't see what you mean after looking at a few PR
<vouivre>
ok. Let me just test the PR I mentionned. I'll tell you if it would be nice to also include it.
<sad_plan>
you do that
<wael[m]>
why not set the executible mark
vouivre has quit [Read error: Connection reset by peer]
vouivre has joined #kisslinux
<sad_plan>
wael[m]: you mean './' ?
<wael[m]>
chmod +x
<sad_plan>
it is executable, it was just missing sh foo or ./foo
<sad_plan>
but './' didnt work for me for some reason
<wael[m]>
whaaaaaat
<wael[m]>
well okay thats a fix
<wael[m]>
adding chmod +x to the configure script in the build file makes it work, but 'sh ' is smaller so
<vouivre>
just tell me when you discussion is finished, I have another question for you.
<wael[m]>
go ahead
<sad_plan>
yeah. Im not entierly sure what happened in the commit, as I did infact build it beforehand, but I messed with some of the branches when creating multiple prs so
<sad_plan>
yeah go ahead
<vouivre>
were you able to update bash ? The build fails on my system
<sad_plan>
built on my end. what seems to be the issue?
<wael[m]>
does kiss report 'successful install'
<vouivre>
I assume a patch problem
<sad_plan>
whats the error?
<testuser[m]12>
adding static to ldflags breaks compilation of 2 extra programs in /usr/lib/bash
<sad_plan>
is that why they used cflags instead?
<sad_plan>
i tried to use the builtin static configure flag even, but it failed for me
<sad_plan>
and -static is a linker flag, so I changed it so it would be correct
<testuser[m]12>
just check the end of the build log
<sad_plan>
I dont see any option for disabling them in the configure script though. but no matter. just build it dynamically anyway
<testuser[m]12>
u could disable plugin support altogether ig but i dont think its right cuz it's needlessly disabling an upstream feature that has no extra cost
<sad_plan>
I see.
<sad_plan>
ffs, I built bash without the static flag, and those libs still complain
<testuser[m]12>
its ok
<testuser[m]12>
just make sure that u can load them from inside bash
<testuser[m]12>
on glibc they work fine with ldd but not on musl, but loading them works on both
<testuser[m]12>
is there a better way to close shithub PR's when `git am`-ing rather than manually editing commit msg to add "closes #PR" ?
<vouivre>
do I create an issue for the error I get ?
<sad_plan>
do you use busybox patch, or a some other build of patch vouivre
<testuser[m]12>
@vouivre what package provides your /usr/bin/patch
<vouivre>
I have not customized busybox. Basically everything from repo and community
<testuser[m]12>
kiss s bash
<vouivre>
kiss-owns /usr/bin/patch -> patch
<testuser[m]12>
first time seeing a patch apply with busybox patch but not with gnu patch lo
<testuser[m]12>
wtf
<testuser[m]12>
yea it breaks with gnu patch
<vouivre>
sorry, I don't remember why I switched to gnu patch
<vouivre>
the build succeed, thank you!
<sad_plan>
lol wtf, ive been trying to rebuild my whole system this week, and after fixing several issues with some packages building, it seems im actually running out of memory. even though I got more ram to spare, I dont have any more swap left.
<vouivre>
I have to go now. Have a nice day.
vouivre has quit [Quit: nyaa~]
<testuser[m]12>
lmao the patches dont even apply with busybox patch
<sad_plan>
the bash patches?
<testuser[m]12>
yeah
<testuser[m]12>
they're supposed to apply
<testuser[m]12>
they fail with patch and busybox patch doesnt inform that its rejecting them
<sad_plan>
lol
<sad_plan>
do we even need them now though?
<testuser[m]12>
arch just does patch -p0 like here but they fail with that, and void adds the -N flag to ignore any reversed patch that would get rejected
<testuser[m]12>
patch rejects them saying they're already applied
<testuser[m]12>
so they're useless ig
<sad_plan>
so we drop them then
<testuser[m]12>
let me check
<testuser[m]12>
one patch is useful
<testuser[m]12>
but thats the -012 one
<testuser[m]12>
wait
<testuser[m]12>
btw u need to add export CFLAGS="$CFLAGS -DSYS_BASHRC='\"/etc/bash/bashrc\"'", everyone seems to add it
<sad_plan>
hm, ok
<testuser[m]12>
nvm they're all useless
<testuser[m]12>
the patches that apply just duplicate previous code
<sad_plan>
is bumping the version again really neccessary ths time?
<testuser[m]12>
yes
<sad_plan>
done, pr is up in a sec
fitrh has quit [Ping timeout: 268 seconds]
fitrh has joined #kisslinux
ejjdhfjsu_ has quit [Ping timeout: 260 seconds]
ejjdhfjsu has joined #kisslinux
ejjdhfjsu_ has joined #kisslinux
ejjdhfjsu has quit [Ping timeout: 252 seconds]
<testuser[m]12>
can you specify the output filename for a file in sources?
<sad_plan>
for kiss you mean?
<testuser[m]12>
yea
<sad_plan>
if the filename changes, I suppose you can
<testuser[m]12>
how
<sad_plan>
youd have to change it elsewhere too though, or use a glob or something I suppose