gemini - kennedy.gemi.dev

💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2022-08-26.txt captured on 2024-03-21 at 15:53:05.
-=-=-=-=-=-=-
[2022-08-26T00:01:39Z] <phoebos> could someone kindly https://tmp.bvnf.space/0001-pinentry-bump-to-1.2.1.patch
[2022-08-26T00:33:02Z] <ioraff> done
[2022-08-26T00:50:07Z] <phoebos> thanks
[2022-08-26T01:26:26Z] <midfavila> dunno if you guys care, but i've modified libtool to use plain make instead of autotools
[2022-08-26T01:26:33Z] <midfavila> https://git.sdf.org/midfavila/editline
[2022-08-26T01:26:52Z] <midfavila> bit of a quick hack, but it should work
[2022-08-26T02:20:10Z] <midfavila> could someone give compiling dash with tcc statically a shot?
[2022-08-26T02:27:34Z] <ioraff> can you send a patch so tcc satisfies the configure script?
[2022-08-26T02:37:58Z] <midfavila> tcc satisfies it on my system
[2022-08-26T02:38:04Z] <midfavila> no patch necessary
[2022-08-26T02:38:08Z] <midfavila> check your cflags and ldflags?
[2022-08-26T02:43:13Z] <ioraff> oh yeah
[2022-08-26T02:43:29Z] <ioraff> compiled and seems to run fine
[2022-08-26T02:43:38Z] <midfavila> with -static though?
[2022-08-26T02:43:47Z] <ioraff> yes
[2022-08-26T02:43:55Z] <midfavila> ...huh...
[2022-08-26T02:44:18Z] <midfavila> nothing about sys_siglist being undefined?
[2022-08-26T02:45:56Z] <ioraff> nope
[2022-08-26T02:46:04Z] <midfavila> strange
[2022-08-26T02:46:10Z] <midfavila> must have something to do with the binutils
[2022-08-26T02:46:10Z] <ioraff> linked with bfd, if that matters.
[2022-08-26T02:46:17Z] <midfavila> yeah, it probably does
[2022-08-26T02:46:26Z] <ioraff> what did you link it with?
[2022-08-26T02:46:35Z] <midfavila> tccld
[2022-08-26T02:52:50Z] <ioraff> actually, it seems like it uses its own linker by default
[2022-08-26T02:54:04Z] <midfavila> what version of tcc and dash?
[2022-08-26T02:54:23Z] <ioraff> git, 0.5.11.5
[2022-08-26T02:54:54Z] <midfavila> my dash is a little older... hrm
[2022-08-26T02:54:59Z] <midfavila> maybe they fixed the references to sys_siglist
[2022-08-26T03:21:52Z] <midfavila> ...wtf
[2022-08-26T03:22:07Z] <midfavila> wiped out my chroot and unpacked just to make sure I had a clean environment, now 'm getting a different error
[2022-08-26T03:22:12Z] <midfavila> something is definitely fucky-wucky
[2022-08-26T03:26:41Z] <midfavila> oh, no, wait. the actual error was still undefined references to sys_siglist
[2022-08-26T03:34:12Z] <testuser[m]12> Hi
[2022-08-26T03:39:39Z] <ioraff> hi
[2022-08-26T03:48:53Z] <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
[2022-08-26T04:06:21Z] <midfavila> okay, weird
[2022-08-26T04:06:33Z] <midfavila> turns out, autotools is just shit and wasn't detecting things properly
[2022-08-26T04:06:46Z] <midfavila> spent a few minutes fiddling with config.h, works fine now
[2022-08-26T04:06:47Z] <midfavila> :thinking:
[2022-08-26T04:24:14Z] <midfavila> turns out, replacing autotools with plain make solves most of my problems
[2022-08-26T04:24:15Z] <midfavila> wild
[2022-08-26T05:01:16Z] <midfavila> well, tcc officially seems capable of compiling TinyX
[2022-08-26T05:02:56Z] <sad_plan> hi
[2022-08-26T05:03:08Z] <midfavila> hello again
[2022-08-26T05:03:09Z] <wael[m]> hi
[2022-08-26T05:03:16Z] <midfavila> was just mentioning tinyx
[2022-08-26T05:03:48Z] <sad_plan> yeah, I was reading through the logs as we speak. it did build with tcc I see
[2022-08-26T05:03:56Z] <sad_plan> thats really cool. 
[2022-08-26T05:04:08Z] <midfavila> yep
[2022-08-26T05:04:21Z] <sad_plan> i didnt know tcc had its own linker either. I thought it was just a compiler tbh
[2022-08-26T05:04:26Z] <midfavila> just need to get its dependencies to compile and rewrite the build system to not depend on autotools
[2022-08-26T05:04:31Z] <midfavila> and yeah, tcc is a complete dev toolchain
[2022-08-26T05:04:44Z] <midfavila> has x86 and arm assemblers, as well as a linker and a compiler, and a preprocessor as well
[2022-08-26T05:04:56Z] <midfavila> it puts its ~100k lines to good use
[2022-08-26T05:04:59Z] <sad_plan> yeah. did you get my comment regarding libXdmcp btw? its not needed after all
[2022-08-26T05:05:06Z] <midfavila> yeah I saw that
[2022-08-26T05:05:11Z] <midfavila> i'm more concerned about stuff like libpng though
[2022-08-26T05:05:16Z] <sad_plan> good
[2022-08-26T05:05:17Z] <midfavila> why is that listed as a dep?
[2022-08-26T05:05:36Z] <sad_plan> links to libpng
[2022-08-26T05:05:43Z] <sad_plan> atleast on my end
[2022-08-26T05:06:13Z] <sad_plan> does it not on your end?
[2022-08-26T05:06:25Z] <midfavila> it does, but presumably in an opportunistic fashion
[2022-08-26T05:06:37Z] <midfavila> i don't go off of kiss' autodep generator
[2022-08-26T05:06:44Z] <midfavila> to be blunt, it's fucking trash
[2022-08-26T05:06:45Z] <sad_plan> hm. perhaps.
[2022-08-26T05:07:00Z] <sad_plan> I went off of what it linked to to begin with atleast
[2022-08-26T05:07:07Z] <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
[2022-08-26T05:07:17Z] <sad_plan> it aint perfect, but its usually what I use
[2022-08-26T05:07:24Z] <midfavila> it's... *fine*, I guess
[2022-08-26T05:07:29Z] <midfavila> if there's no other option 
[2022-08-26T05:07:35Z] <sad_plan> yeah
[2022-08-26T05:07:49Z] <midfavila> but i usually consult the project itself and then LFS, followed by Alpine, Gentoo and finally Debian
[2022-08-26T05:09:04Z] <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
[2022-08-26T05:09:17Z] <sad_plan> im rebuilding tinyx now without libpng, and ill see if it builds correctly
[2022-08-26T05:09:25Z] <midfavila> cool, keep me posted
[2022-08-26T05:09:28Z] <sad_plan> noo, libpng is required
[2022-08-26T05:09:36Z] <midfavila> lame
[2022-08-26T05:09:43Z] <midfavila> that means libtool is required and perl by proxy
[2022-08-26T05:09:44Z] <sad_plan> Package 'libpng', required by 'freetype2', not found
[2022-08-26T05:09:50Z] <midfavila> can you not disable freetype?
[2022-08-26T05:10:02Z] <midfavila> if freetype can't be disabled then tcc goes out the window
[2022-08-26T05:10:08Z] <sad_plan> theres no flag for it in the configure script that Im aware of
[2022-08-26T05:10:13Z] <sad_plan> I could look
[2022-08-26T05:10:13Z] <midfavila> hrm
[2022-08-26T05:10:18Z] <midfavila> might need to patch it
[2022-08-26T05:10:24Z] <midfavila> tinyx itself i mean
[2022-08-26T05:11:45Z] <sad_plan> yeah
[2022-08-26T05:12:05Z] <sad_plan> but no, theres no flag for freetype. not anything thats clearly labeled anyway
[2022-08-26T05:13:03Z] <midfavila> hrm
[2022-08-26T05:13:04Z] <sad_plan> freetype is mentioned in several of the makefiles actually
[2022-08-26T05:13:10Z] <midfavila> yeah, i ran a grep on them
[2022-08-26T05:13:18Z] <midfavila> almost certainly going to need a patchjob
[2022-08-26T05:13:29Z] <sad_plan> yeah
[2022-08-26T05:13:40Z] <midfavila> well,
[2022-08-26T05:14:08Z] <midfavila> my response is that things should start with ripping out just Xfbdev
[2022-08-26T05:14:21Z] <midfavila> and then a makefile should be set up for it,
[2022-08-26T05:14:24Z] <midfavila> and then patching can start
[2022-08-26T05:14:53Z] <sad_plan> dont you mean Xvesa? I cant even use Xvesa as its only for 32-bit
[2022-08-26T05:15:07Z] <midfavila> oh, i wasn't clear, my bad
[2022-08-26T05:15:14Z] <midfavila> i meant that xfbdev should be made its own thing
[2022-08-26T05:15:17Z] <midfavila> and the rest left to die
[2022-08-26T05:17:18Z] <midfavila> my vision is to get xfbdev working as an interim solution, and then start work on kicking MGR into shape
[2022-08-26T05:18:15Z] <midfavila> https://en.wikipedia.org/wiki/ManaGeR
[2022-08-26T05:18:27Z] <midfavila> there seem to be a few forks aimed at bringing it back to life already
[2022-08-26T05:19:29Z] <midfavila> https://github.com/ProgrammerArchaeology/bellcore-mgr
[2022-08-26T05:19:34Z] <midfavila> in particular, this one actually builds
[2022-08-26T05:19:41Z] <midfavila> (although it uses cmake)
[2022-08-26T05:24:25Z] <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
[2022-08-26T05:25:34Z] <sad_plan> does mgr even work anymore on any recent computer? I mean, seeing as its from the 80s
[2022-08-26T05:25:50Z] <midfavila> well, if nothing else it compiles and runs on my system
[2022-08-26T05:25:54Z] <sad_plan> not that that is an argument for something not working though
[2022-08-26T05:25:59Z] <midfavila> it doesn't *do* anything, at least that I can tell
[2022-08-26T05:26:02Z] <midfavila> but it does compile and "work"
[2022-08-26T05:26:02Z] <sad_plan> ah, cool
[2022-08-26T05:26:12Z] <midfavila> i've seen another project that got it working as an X client
[2022-08-26T05:26:28Z] <midfavila> and I mean, I wouldn't count it out just 'cause it's an old program
[2022-08-26T05:26:36Z] <midfavila> motif is from the 80s and it runs like a dream
[2022-08-26T05:27:25Z] <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
[2022-08-26T05:28:15Z] <midfavila> well, i think mgr was properly written for its time
[2022-08-26T05:28:28Z] <midfavila> but there are definitely archaic elements to its design
[2022-08-26T05:28:41Z] <midfavila> the main element that strikes me atm is the limitations on mouse input it has
[2022-08-26T05:28:58Z] <midfavila> (specifically requires a one, two, or three-button microsoft protocol serial mouse, a bus mouse, or something similar)
[2022-08-26T05:29:03Z] <midfavila> or ps/2
[2022-08-26T05:29:10Z] <midfavila> but such things could be changed readily
[2022-08-26T05:29:26Z] <midfavila> honestly, with a little effort, i could see myself *really* enjoying mgr
[2022-08-26T05:29:36Z] <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
[2022-08-26T05:30:01Z] <sad_plan> cool
[2022-08-26T05:40:52Z] <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..
[2022-08-26T06:39:02Z] <vouivre> hello
[2022-08-26T06:39:05Z] <sad_plan> hi
[2022-08-26T06:39:18Z] <wael[m]> hallo
[2022-08-26T06:39:23Z] <vouivre> sad_plan: did you see the issue I created about fzy ?
[2022-08-26T06:39:48Z] <vouivre> it was your suggestion
[2022-08-26T06:40:22Z] <sad_plan> yeah, I made a comment there. but dylin has answered, nor has anyone else for that matter
[2022-08-26T06:41:08Z] <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
[2022-08-26T06:41:32Z] <wael[m]> please make a fzy fork
[2022-08-26T06:42:34Z] <vouivre> I really like your suggestion. Why not patching ytfzf. Why a fork ? To merge the PR ? 
[2022-08-26T06:43:00Z] <wael[m]> shitty reason - i am blocked from fzy repository 
[2022-08-26T06:43:24Z] <vouivre> So you wouldn't be able to install it ? 
[2022-08-26T06:43:28Z] <wael[m]> plus good many pull requests get ignored - included a feature i liked, and when i tried to ask why i got blocked
[2022-08-26T06:43:45Z] <wael[m]> i can still use fzy but theres missing features that go unnoticed by the maintainer
[2022-08-26T06:44:07Z] <vouivre> HHhhmmm, I remember something now.
[2022-08-26T06:44:18Z] <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.
[2022-08-26T06:44:38Z] <sad_plan> regarding fzy, I see no issue in adding it to the community repo anyway
[2022-08-26T06:45:02Z] <wael[m]> have a look at any pull request in the fzy repository
[2022-08-26T06:46:08Z] <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.
[2022-08-26T06:49:23Z] <vouivre> you are right about the opinion of other users.
[2022-08-26T06:49:29Z] <sad_plan> we might be better of creating a separate issue regarding using fzy with ytfzf though. seeing as theyre seperate things
[2022-08-26T06:49:51Z] <sad_plan> yeah. I wouldnt be too happy either if I used a tool, and suddenly someone removed some vital features I used
[2022-08-26T06:50:01Z] * sad_plan shrugs
[2022-08-26T06:50:32Z] <vouivre> wael[m]: I didn't see what you mean after looking at a few PR
[2022-08-26T06:50:45Z] <vouivre> did you have a look at this PR:
[2022-08-26T06:50:58Z] <vouivre> https://github.com/jhawthorn/fzy/pull/174
[2022-08-26T06:51:15Z] <wael[m]> vouivre: tl;dr maintainer ignores good PRs
[2022-08-26T06:56:17Z] <sad_plan> hence why we include it ourselfes instead. easy peasy
[2022-08-26T06:56:38Z] <wael[m]> fair enough
[2022-08-26T06:56:43Z] <vouivre> after searching, I found 
[2022-08-26T06:56:53Z] <wael[m]> as a patch or as a fork?
[2022-08-26T06:57:36Z] <vouivre> https://github.com/jhawthorn/fzy/pull/32#issuecomment-301252654
[2022-08-26T06:59:38Z] <vouivre> I'm almost convinced the will be no more developpment of fzy and the PR won't be merged.
[2022-08-26T07:00:12Z] <sad_plan> that might be the case. alot of projects often dies when the maintainer just choose not to work on it anymore..
[2022-08-26T07:00:34Z] <sad_plan> last commit is late january, so its some time ago to say the least..
[2022-08-26T07:01:45Z] <vouivre> we could do a fork, but if I do the fork I will only be able to merge the PR, at best it will take a loooooonnnnnngggg time to add features
[2022-08-26T07:02:37Z] <vouivre> or perhaps a user could be interested to fork it.
[2022-08-26T07:13:59Z] <sad_plan> I wouldnt bother forking it, with the intention of getting features pushed upstream, unless you activly plan on working it yourself. 
[2022-08-26T07:14:14Z] <sad_plan> for kiss, I would just add the patches from said PR and be done for the day.
[2022-08-26T07:14:24Z] <sad_plan> if theres more stuff, just add those too aswell
[2022-08-26T07:16:38Z] <sad_plan> vouivre: its only the patches from neo-arch that youd want included, yes?
[2022-08-26T07:16:48Z] <sad_plan> ill make a pr
[2022-08-26T07:17:53Z] <sad_plan> wael[m]: regarding your issue https://github.com/kiss-community/community/issues/1218 I belive I did, but it seems I messed up afterwards. Ive created a pr for it for a fix
[2022-08-26T07:18:03Z] <vouivre> ok. Let me just test the PR I mentionned. I'll tell you if it would be nice to also include it.
[2022-08-26T07:18:38Z] <sad_plan> you do that
[2022-08-26T07:18:47Z] <wael[m]> why not set the executible mark
[2022-08-26T07:21:19Z] <sad_plan> wael[m]: you mean './' ?
[2022-08-26T07:21:28Z] <wael[m]> chmod +x
[2022-08-26T07:21:55Z] <sad_plan> it is executable, it was just missing sh foo or ./foo
[2022-08-26T07:22:05Z] <sad_plan> but './' didnt work for me for some reason
[2022-08-26T07:22:08Z] <wael[m]> whaaaaaat 
[2022-08-26T07:22:14Z] <wael[m]> well okay thats a fix 
[2022-08-26T07:22:55Z] <wael[m]> adding chmod +x to the configure script in the build file makes it work, but 'sh ' is smaller so
[2022-08-26T07:23:15Z] <vouivre> just tell me when you discussion is finished, I have another question for you. 
[2022-08-26T07:23:29Z] <wael[m]> go ahead
[2022-08-26T07:23:30Z] <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
[2022-08-26T07:23:32Z] <sad_plan> yeah go ahead
[2022-08-26T07:23:52Z] <vouivre> were you able to update bash ? The build fails on my system
[2022-08-26T07:24:07Z] <sad_plan> built on my end. what seems to be the issue?
[2022-08-26T07:24:10Z] <wael[m]> does kiss report 'successful install'
[2022-08-26T07:24:28Z] <vouivre> I assume a patch problem
[2022-08-26T07:24:40Z] <sad_plan> whats the error?
[2022-08-26T07:24:42Z] <testuser[m]12> adding static  to ldflags breaks compilation of 2 extra programs in /usr/lib/bash
[2022-08-26T07:24:59Z] <sad_plan> is that why they used cflags instead?
[2022-08-26T07:25:34Z] <sad_plan> i tried to use the builtin static configure flag even, but it failed for me
[2022-08-26T07:25:54Z] <sad_plan> and -static is a linker flag, so I changed it so it would be correct
[2022-08-26T07:26:14Z] <testuser[m]12> just check the end of the build log
[2022-08-26T07:26:25Z] <sad_plan> building as we speak
[2022-08-26T07:26:37Z] <vouivre> http://0x0.st/o9Uh.txt
[2022-08-26T07:27:18Z] <sad_plan> huh, the patch actually doenst apply
[2022-08-26T07:27:45Z] <sad_plan> testuser[m]12: I see what you mean. it builds successfully, but actually gets an error at the bottom
[2022-08-26T07:29:03Z] <sad_plan> which appears to not be present when using cflags instead
[2022-08-26T07:29:58Z] <sad_plan> revert to cflags then. ill make a pr for it
[2022-08-26T07:30:47Z] <sad_plan> vouivre: are you using busybox patch? or do you have some other patch in which you use?
[2022-08-26T07:31:20Z] <testuser[m]12> it isn't going to be static anymore then lol
[2022-08-26T07:31:28Z] <testuser[m]12> only shared libs are installed to /usr/lib/bash
[2022-08-26T07:31:31Z] <testuser[m]12> idk  what they're for
[2022-08-26T07:31:56Z] <sad_plan> the /bin/bash will still be static
[2022-08-26T07:32:03Z] <sad_plan> aswell as the others
[2022-08-26T07:32:45Z] <testuser[m]12> static binaries cant dlopen shared lib
[2022-08-26T07:33:24Z] <testuser[m]12> its ok if they're not used by bahs
[2022-08-26T07:34:08Z] <sad_plan> no, but that shouldnt matter, seeing as the bin is static, right?
[2022-08-26T07:36:16Z] <testuser[m]12> the stuff in /usr/lib/bash seems like extra builtins / plugins to me which have to be dlopen'd at runtime
[2022-08-26T07:36:20Z] <testuser[m]12> idk
[2022-08-26T07:36:39Z] <sad_plan> yeah, they all complain about missing symbols if you ldd them
[2022-08-26T07:36:58Z] <testuser[m]12> they're not supposed to do that
[2022-08-26T07:37:04Z] <testuser[m]12> they're just regular shared libraries
[2022-08-26T07:37:29Z] <sad_plan> h
[2022-08-26T07:37:32Z] <sad_plan> hm
[2022-08-26T07:39:47Z] <testuser[m]12> Some examples of ready-to-dynamic-load builtins.  Most of the... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3040f780975bc1576cf4d24ecd0e73964bc8ff6a)
[2022-08-26T07:40:43Z] <testuser[m]12> bash supports loadable modules and those are examples for it
[2022-08-26T07:40:44Z] <testuser[m]12> so making it static is breaking this feature
[2022-08-26T07:41:31Z] <sad_plan> so we should remove the static flag, and just build bash dynamically instead then
[2022-08-26T07:41:57Z] <testuser[m]12> yes
[2022-08-26T07:42:11Z] <sad_plan> will do. ill create a pr right away
[2022-08-26T07:43:33Z] <sad_plan> couldnt we build those plugins statically though? out of curiousity :p
[2022-08-26T07:44:17Z] <testuser[m]12> point of plugins is dynamic loading
[2022-08-26T07:44:23Z] <testuser[m]12> plug in
[2022-08-26T07:44:49Z] <sad_plan> sure, but still. 
[2022-08-26T07:45:04Z] <testuser[m]12> those are optional so no point in building them in
[2022-08-26T07:45:13Z] <testuser[m]12> u can have user defined plugins
[2022-08-26T07:45:18Z] <testuser[m]12> https://termbin.com/1xlb how it's supposed to work
[2022-08-26T07:45:33Z] <testuser[m]12> https://termbin.com/yd9k
[2022-08-26T07:45:42Z] <sad_plan> right
[2022-08-26T07:46:15Z] <sad_plan> I dont see any option for disabling them in the configure script though. but no matter. just build it dynamically anyway
[2022-08-26T07:46:33Z] <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
[2022-08-26T07:48:24Z] <sad_plan> I see.
[2022-08-26T07:48:40Z] <sad_plan> ffs, I built bash without the static flag, and those libs still complain
[2022-08-26T07:49:00Z] <testuser[m]12> its ok
[2022-08-26T07:49:14Z] <testuser[m]12> just make sure that u can load them from inside bash
[2022-08-26T07:49:28Z] <testuser[m]12> on glibc they work fine with ldd but not on musl, but loading them works on both
[2022-08-26T07:50:16Z] <sad_plan> ah ok, so no biggie then
[2022-08-26T07:51:21Z] <sad_plan> pr is up
[2022-08-26T07:51:25Z] <sad_plan> https://github.com/kiss-community/community/pull/1220
[2022-08-26T07:52:20Z] <testuser[m]12> bump version
[2022-08-26T07:52:29Z] <sad_plan> will do
[2022-08-26T07:53:09Z] <sad_plan> done
[2022-08-26T07:55:27Z] <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" ?
[2022-08-26T08:04:29Z] <vouivre> do I create an issue for the error I get ? 
[2022-08-26T08:04:52Z] <sad_plan> do you use busybox patch, or a some other build of patch vouivre 
[2022-08-26T08:05:34Z] <testuser[m]12> @vouivre what package provides your /usr/bin/patch
[2022-08-26T08:05:55Z] <vouivre> I have not customized busybox. Basically everything from repo and community
[2022-08-26T08:06:04Z] <testuser[m]12> kiss s bash
[2022-08-26T08:06:42Z] <vouivre> kiss-owns /usr/bin/patch -> patch
[2022-08-26T08:07:03Z] <testuser[m]12> first time seeing a patch apply with busybox patch but not with gnu patch lo
[2022-08-26T08:07:09Z] <testuser[m]12> wtf
[2022-08-26T08:07:42Z] <testuser[m]12> yea it breaks with gnu patch
[2022-08-26T08:08:09Z] <vouivre> sorry, I don't remember why I switched to gnu patch
[2022-08-26T08:09:22Z] <vouivre> the build succeed, thank you!
[2022-08-26T08:10:57Z] <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. 
[2022-08-26T08:18:41Z] <vouivre> I have to go now. Have a nice day.
[2022-08-26T08:22:54Z] <testuser[m]12> lmao the patches dont even apply with busybox patch
[2022-08-26T08:24:16Z] <sad_plan> the bash patches?
[2022-08-26T08:24:28Z] <testuser[m]12> yeah
[2022-08-26T08:24:33Z] <testuser[m]12> they're supposed to apply
[2022-08-26T08:24:46Z] <testuser[m]12> they fail with patch and busybox patch doesnt inform that its rejecting them
[2022-08-26T08:25:24Z] <sad_plan> lol
[2022-08-26T08:26:01Z] <sad_plan> do we even need them now though?
[2022-08-26T08:26:23Z] <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
[2022-08-26T08:26:32Z] <testuser[m]12> patch rejects them saying they're already applied
[2022-08-26T08:26:34Z] <testuser[m]12> so they're useless ig
[2022-08-26T08:27:03Z] <sad_plan> so we drop them then
[2022-08-26T08:27:19Z] <testuser[m]12> let me check
[2022-08-26T08:28:38Z] <testuser[m]12> one patch is useful
[2022-08-26T08:29:09Z] <testuser[m]12> but thats the -012 one
[2022-08-26T08:29:09Z] <testuser[m]12> wait
[2022-08-26T08:32:29Z] <testuser[m]12> btw u need to add export CFLAGS="$CFLAGS -DSYS_BASHRC='\"/etc/bash/bashrc\"'", everyone seems to add it
[2022-08-26T08:34:29Z] <sad_plan> hm, ok
[2022-08-26T08:41:40Z] <testuser[m]12> nvm they're all useless
[2022-08-26T08:41:46Z] <testuser[m]12> the patches that apply just duplicate previous code
[2022-08-26T08:44:52Z] <sad_plan> is bumping the version again really neccessary ths time?
[2022-08-26T08:49:43Z] <testuser[m]12> yes
[2022-08-26T08:50:11Z] <sad_plan> done, pr is up in a sec
[2022-08-26T10:17:23Z] <testuser[m]12> can you specify the output filename for a file in sources?
[2022-08-26T10:18:56Z] <sad_plan> for kiss you mean?
[2022-08-26T10:19:04Z] <testuser[m]12> yea
[2022-08-26T10:19:29Z] <sad_plan> if the filename changes, I suppose you can
[2022-08-26T10:19:38Z] <testuser[m]12> how
[2022-08-26T10:20:27Z] <sad_plan> youd have to change it elsewhere too though, or use a glob or something I suppose
[2022-08-26T10:20:44Z] <testuser[m]12> https://url.com filename
[2022-08-26T10:20:46Z] <testuser[m]12> i want to do this
[2022-08-26T10:20:49Z] <sad_plan> hm
[2022-08-26T10:20:52Z] <sad_plan> why?
[2022-08-26T10:20:55Z] <testuser[m]12> but filename wil be the dir where the source is stored
[2022-08-26T10:21:00Z] <sad_plan> correct
[2022-08-26T10:21:08Z] <sad_plan> thats the way kiss is set up afaik
[2022-08-26T10:21:13Z] <testuser[m]12> bypassing meson subproject network requirement
[2022-08-26T10:21:18Z] <testuser[m]12> i dont want to package that thing
[2022-08-26T10:21:26Z] <testuser[m]12> so im just adding meson's links to sources
[2022-08-26T10:22:04Z] <sad_plan> why cant you just rename it in the buildscript though?
[2022-08-26T10:22:15Z] <testuser[m]12> feels more hacky
[2022-08-26T10:22:21Z] <testuser[m]12> meh ig ill just package it seperateely
[2022-08-26T10:23:29Z] <sad_plan> what are you trying to package
[2022-08-26T10:23:52Z] <testuser[m]12> some nvidia vdpau vaapi driver shit
[2022-08-26T10:23:59Z] <testuser[m]12> it needs nvidia headrs for make
[2022-08-26T10:24:10Z] <sad_plan> I see
[2022-08-26T10:24:28Z] <wael[m]> woa
[2022-08-26T10:24:37Z] <sad_plan> what?
[2022-08-26T10:24:55Z] <wael[m]> rhfniguyhnatrurongjuzdsm;gbjlktghyjdisok
[2022-08-26T11:01:54Z] <phoebos> testuser[m]12: how do your scripts to add a runit logger work?
[2022-08-26T11:02:05Z] <phoebos> is the first one /var/service/svlogd/run ?
[2022-08-26T11:03:19Z] <phoebos> and the second one run once for each package to set it up
[2022-08-26T11:47:51Z] <testuser[m]12> oh i forgot
[2022-08-26T11:48:03Z] <testuser[m]12> the first one goes in /etc/sv/logger
[2022-08-26T11:48:29Z] <testuser[m]12> and the second one is to symlink the logger script to /etc/sv/service/log/run
[2022-08-26T11:49:18Z] <testuser[m]12> /etc/sv/logger isnt some fixed path u can put it anywhere
[2022-08-26T11:49:24Z] <testuser[m]12> just have to symlink it later
[2022-08-26T11:56:17Z] <testuser[m]12> illiliti: https://github.com/kiss-community/repo/issues/83
[2022-08-26T12:03:14Z] <testuser[m]12> I can hotplug in Wayland just fine
[2022-08-26T18:02:03Z] <ioraff> testuser[m]12: are you running the mdev daemon?
[2022-08-26T18:51:15Z] <testuser[m]12> ioraff: yeah