💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2021-07-01.txt captured on 2024-05-26 at 16:15:21.
⬅️ Previous capture (2021-12-17)
-=-=-=-=-=-=-
[2021-07-01T00:01:56Z] <illiliti> but this way allows to keep current repository layout without modifications
[2021-07-01T00:02:16Z] <illiliti> i mean no "provides" file
[2021-07-01T00:03:36Z] <dilyn> I've packaged many, many things. There is... still only one application that I've dealth with that cares about a provides file
[2021-07-01T00:03:48Z] <dilyn> the rest care about a specific package
[2021-07-01T00:03:54Z] <dilyn> I don't understand what the inconvenience is
[2021-07-01T00:06:59Z] <illiliti> i don't care. i don't use "provides" functionality
[2021-07-01T00:08:02Z] <midfavila> like I said,
[2021-07-01T00:08:07Z] <midfavila> *not a big deal*
[2021-07-01T00:08:25Z] <midfavila> it's just something that would be useful *sometimes*, in my *opinion*
[2021-07-01T00:09:05Z] <acheam> provides is nice for using alternate implantations
[2021-07-01T00:09:26Z] <acheam> for example: samurai provides ninja, byacc provides bison, etc
[2021-07-01T00:12:09Z] <dilyn> that's just the alternatives system :P
[2021-07-01T00:12:18Z] <illiliti> i think we need to decide which udev implementation to use(?)
[2021-07-01T00:13:27Z] <illiliti> eudev is stable, easier to setup and use, supports everything
[2021-07-01T00:15:15Z] <illiliti> libudev-zero is recently became stable, harder to understand for newbies, doesn't support everything
[2021-07-01T00:18:28Z] <illiliti> eudev can be used with libudev-zero if compiled statically
[2021-07-01T00:18:45Z] <dilyn> that's fair criticism of libudev-zero, but KISS isn't newbie friendly in general :v
[2021-07-01T00:18:58Z] <illiliti> yeah
[2021-07-01T00:20:08Z] <dilyn> i'm not convinced that, had dylan originally had the choice between libudev-zero and eudev, he would've even included eudev
[2021-07-01T00:21:24Z] <illiliti> libudev-zero does support everything in main repo, not sure about community
[2021-07-01T00:24:08Z] <dilyn> almost everything, except apparenlty android-tools, tlp, and usbutils
[2021-07-01T00:24:20Z] <dilyn> at least for things which explicitly demand eudev
[2021-07-01T00:25:11Z] <dilyn> the problem I would have with relegating eudev to community && making libinput require libudev-zero is that it's so powerful and NOT "evil", it would just be less convenient than the current way
[2021-07-01T00:26:41Z] <acheam> dilyn: no its not the alternatives system
[2021-07-01T00:26:53Z] * midfavila sighs...
[2021-07-01T00:26:56Z] <acheam> because I still want my byacc package to be called byacc
[2021-07-01T00:26:58Z] <midfavila> there's a second chroot down to the second problem
[2021-07-01T00:27:06Z] <midfavila> that being kiss overwriting perms...
[2021-07-01T00:27:07Z] <acheam> but it needs to be called bison to resolve dependencies correctly
[2021-07-01T00:27:31Z] <dilyn> that was mostly a joke
[2021-07-01T00:27:50Z] <dilyn> a bad joke
[2021-07-01T00:28:02Z] <acheam> ah okay
[2021-07-01T00:28:05Z] <dilyn> wdym mid?
[2021-07-01T00:28:54Z] <midfavila> jexactly what I said
[2021-07-01T00:29:10Z] <midfavila> directories and files are having their groups and owners overwritten
[2021-07-01T00:29:41Z] <midfavila> i'm done for now
[2021-07-01T00:29:45Z] <midfavila> three days wasted on this
[2021-07-01T00:34:39Z] <illiliti> android-tools are so bloated and overengineered. i can't believe we have it in community
[2021-07-01T00:35:59Z] <acheam> testuser[m]1: defend yourself
[2021-07-01T00:36:12Z] <acheam> ehr hes sleeping probably
[2021-07-01T00:38:01Z] <illiliti> Additionally the following software is required at compile-time:
[2021-07-01T00:38:04Z] <illiliti> A C and C++ compiler (either GCC >= 10.X or clang)
[2021-07-01T00:38:10Z] <illiliti> The Go compiler
[2021-07-01T00:38:14Z] <illiliti> CMake
[2021-07-01T00:38:18Z] <illiliti> Perl
[2021-07-01T00:38:40Z] <dilyn> when you just finished your coding bootcamp and you want to flex how much you know
[2021-07-01T00:38:53Z] <acheam> https://ytprivate.com/MkJkyMuBm3g
[2021-07-01T00:39:06Z] <acheam> cool compare/contrast by landley himself
[2021-07-01T00:40:18Z] <dilyn> the man, the myth
[2021-07-01T00:40:26Z] <acheam> not a legend?
[2021-07-01T00:40:45Z] <dilyn> nah
[2021-07-01T00:40:48Z] <dilyn> he's just a mensch
[2021-07-01T00:41:24Z] <illiliti> what DE he is using?
[2021-07-01T00:41:35Z] <acheam> MATE?
[2021-07-01T00:41:40Z] <acheam> or XFCE
[2021-07-01T00:41:47Z] <dilyn> do you think he just uses whatever replaced aboriginal and lives in a TTY?
[2021-07-01T00:41:53Z] <acheam> yes.
[2021-07-01T00:42:16Z] <acheam> top bar suggests MATE, dock suggests XFCE, I can't tell
[2021-07-01T00:42:39Z] <acheam> maybe later he'll mouse over something that will give a clue
[2021-07-01T00:42:53Z] <illiliti> lxde lol
[2021-07-01T00:43:06Z] <acheam> oh?
[2021-07-01T00:43:41Z] <illiliti> this is lxde or xfce i think
[2021-07-01T00:44:25Z] <acheam> I don't think its lxde
[2021-07-01T00:45:08Z] <acheam> lxde has a single bar IIRC
[2021-07-01T00:45:13Z] <acheam> this has two like XFCE
[2021-07-01T00:45:56Z] <msk_1411[m]> Anyone else failing to build qt5-webengine?
[2021-07-01T00:46:07Z] <msk_1411[m]> Here's the log of mine: https://0x0.st/-fzr.txt
[2021-07-01T00:47:08Z] <acheam> dilyn:
[2021-07-01T00:48:51Z] <dilyn> g++: fatal error: Killed signal terminated program cc1plus
[2021-07-01T00:48:55Z] <dilyn> d'ya run outta ram lad
[2021-07-01T00:49:23Z] <msk_1411[m]> Oh, that was probably it, then
[2021-07-01T00:49:26Z] <dilyn> that late in the build I wouldn't be surprised
[2021-07-01T00:49:36Z] <msk_1411[m]> I should have compiled it outside of an xorg session
[2021-07-01T00:50:02Z] <dilyn> I'd recommend just halving your makeflags
[2021-07-01T00:50:15Z] <msk_1411[m]> How did you know that line, "g++: fatal error" indicated RAM running out?
[2021-07-01T00:50:17Z] <dilyn> like when I build webengine (in RAM) I do MAKEFLAGS="-j12 -l12"
[2021-07-01T00:50:44Z] <dilyn> because 1) cc1plus being killed isn't a build system error, and 2) I have built webengine far too often :)
[2021-07-01T00:51:25Z] <msk_1411[m]> I echoed $MAKEFLAGS and have none set
[2021-07-01T00:51:39Z] <msk_1411[m]> I don't see a default in the build file
[2021-07-01T00:52:03Z] <dilyn> oh well hm actually webengine uses gn... does gn respect makeflags? or ninjaflags...
[2021-07-01T00:53:09Z] <msk_1411[m]> I remember the Gentoo wiki recommending having the jobs set to RAM / 2
[2021-07-01T00:53:17Z] <msk_1411[m]> So, you were building with 24 G?
[2021-07-01T00:53:24Z] <msk_1411[m]> This laptop only has 4 G of RAM
[2021-07-01T00:53:34Z] <dilyn> for llvm/chromium/webengine I just set MAKEFLAGS="-j12 -l12" NINJAFLAGS=-j12 SAMUFLAGS=-j12
[2021-07-01T00:53:58Z] <dilyn> you might be remembering wrong :v
[2021-07-01T00:54:03Z] <dilyn> I have 24 cores, so yeah I'm just halving it
[2021-07-01T00:54:40Z] <dilyn> don't use -pipe in your C{XX}FLAGS and unset KISS_TMPDIR if it's set to tmpfs (/tmp), and you'll (probably) succeed
[2021-07-01T00:54:44Z] <dilyn> I'd recommend using ccache
[2021-07-01T00:55:59Z] <msk_1411[m]> $KISS_TMPDIR doesn't exist
[2021-07-01T00:56:38Z] <msk_1411[m]> cat /proc/cpuinfo says it has 2 cores, so would I try MAKEFLAGS="-j1 -l1" and so on?
[2021-07-01T00:57:02Z] <dilyn> yeah :X
[2021-07-01T00:57:13Z] <dilyn> it's gonna take all day to build
[2021-07-01T00:57:48Z] <msk_1411[m]> Yeah, it was running for over 24 hours before it failed
[2021-07-01T00:58:26Z] <dilyn> ouch :X
[2021-07-01T00:59:01Z] <dilyn> I am eternally thankful I don't have to debug build problems on a four core machine ever again lmfao
[2021-07-01T00:59:43Z] <msk_1411[m]> That would be super painful
[2021-07-01T01:00:29Z] <msk_1411[m]> I'm glad that this one was my fault and (it looks like) relatively easy to fix
[2021-07-01T01:01:07Z] <msk_1411[m]> Alright, thanks for your help
[2021-07-01T01:01:17Z] <dilyn> yeah there's only a couple of packages that pose this risk - llvm, firefox, chromium, qt5-webengine
[2021-07-01T01:01:22Z] <dilyn> most other things you're pretty safe
[2021-07-01T01:02:47Z] <msk_1411[m]> Hopefully there won't be too many new releases of those
[2021-07-01T01:03:37Z] <dilyn> unfortunately firefox and chromium are updated every month :)
[2021-07-01T01:04:38Z] <acheam> there's a bin repo with llvm and Firefox though
[2021-07-01T01:06:05Z] <msk_1411[m]> I'm trying the firefox binary package right now
[2021-07-01T01:06:49Z] <msk_1411[m]> If everything works, I'll try installing kiss and compiling webengine on my main laptop, which has slightly higher specs
[2021-07-01T01:16:24Z] <dilyn> ah acheam that video is muy bueno
[2021-07-01T01:16:35Z] <acheam> si
[2021-07-01T01:16:39Z] <dilyn> for all his quirks, i really enjoy listening to landley talk
[2021-07-01T01:17:01Z] <dilyn> i've watched this video like eight times lol
[2021-07-01T01:17:47Z] <acheam> well now I know why you hate GPL
[2021-07-01T01:18:06Z] <dilyn> :)
[2021-07-01T01:18:15Z] <acheam> any job news?
[2021-07-01T01:18:17Z] <dilyn> i wrote a blog a month ago about why i hate the GPL. this video was a featured source
[2021-07-01T01:18:43Z] <dilyn> my last interviewer said i'll hear back next week if I either a) got the job or b) have to interview with the CEO :)
[2021-07-01T01:18:49Z] <dilyn> I'm hoping it's a
[2021-07-01T01:18:58Z] <acheam> oh do you have an RSS feed?
[2021-07-01T01:19:06Z] <dilyn> nah
[2021-07-01T01:19:12Z] <dilyn> i never pushed the blog lol
[2021-07-01T01:19:19Z] <acheam> lol why?
[2021-07-01T01:19:29Z] <acheam> good luck!
[2021-07-01T01:19:39Z] <dilyn> it wasn't clear enough, and I want to find a way to make it more clear and direct without writing four thousand words
[2021-07-01T01:19:47Z] <dilyn> as it stands it just sounds like a weak argument
[2021-07-01T01:19:53Z] <dilyn> thanks! I really hope I get it
[2021-07-01T01:20:54Z] <acheam> all license arguments are pretty week tbh
[2021-07-01T01:21:10Z] <acheam> its such a multifaceted issue that there is no valid super strong argument
[2021-07-01T01:21:13Z] <dilyn> I think my qualms with the GPL are strong
[2021-07-01T01:21:20Z] <dilyn> most other licenses... it's harder to make a good case
[2021-07-01T01:21:35Z] <dilyn> but most licenses aren't GNU :)
[2021-07-01T03:41:04Z] <GalaxyNova> yo
[2021-07-01T03:41:09Z] <GalaxyNova> dylan is authoring commit on kiss again
[2021-07-01T03:41:12Z] <GalaxyNova> great news
[2021-07-01T03:41:20Z] <GalaxyNova> nice to have him back :D
[2021-07-01T03:46:33Z] <acheam> ye hes been around on this channel yoo
[2021-07-01T03:46:45Z] <acheam> s/yoo/too/go
[2021-07-01T04:15:02Z] <msk_1411[m]> Anyone know what part of the installation I messed up to cause "Read-only file system"?
[2021-07-01T04:16:31Z] <msk_1411[m]> I used arch's genfstab for /etc/fstab, perhaps that's the issue
[2021-07-01T04:38:21Z] <msk_1411[m]> Actually no, that can't be it, I've successfully installed KISS on this laptop despite using genfstab
[2021-07-01T04:38:40Z] <illiliti> post it here
[2021-07-01T04:38:43Z] <illiliti> /etc/fstab
[2021-07-01T04:42:25Z] <msk_1411[m]> No valid network device is appearing, so I won't be able to upload it with 0x0.st
[2021-07-01T04:42:38Z] <msk_1411[m]> Would a photo with my phone be okay?
[2021-07-01T04:43:16Z] <illiliti> yep
[2021-07-01T04:46:21Z] <msk_1411[m]> https://i.snipboard.io/uXY7gT.jpg
[2021-07-01T04:46:39Z] <msk_1411[m]> Sorry, I don't know of any good image sharing sites
[2021-07-01T04:47:08Z] <msk_1411[m]> and excuse how disgusting the laptop looks
[2021-07-01T04:49:15Z] <msk_1411[m]> This is a GPT/UEFI system
[2021-07-01T04:49:30Z] <GalaxyNova> msk_1411[m]: use 0x0.st
[2021-07-01T04:49:46Z] <GalaxyNova> it's a great file sharing website
[2021-07-01T04:50:09Z] <msk_1411[m]> Yeah I just read their site again and realized that they don't only do text files
[2021-07-01T04:50:39Z] <illiliti> fstab looks good
[2021-07-01T04:50:47Z] <illiliti> i prefer https://envs.sh
[2021-07-01T04:51:16Z] <GalaxyNova> kinda odd how you have the efi dir mounted at /efi
[2021-07-01T04:51:23Z] <GalaxyNova> usually its mounted in /boot/efi
[2021-07-01T04:51:30Z] <GalaxyNova> but that shoudn't effect anything
[2021-07-01T04:52:29Z] <illiliti> iirc /efi superseded /boot/efi
[2021-07-01T04:53:06Z] <illiliti> msk_1411[m]: send /proc/cmdline
[2021-07-01T04:53:53Z] <illiliti> what bootloader do you use? efistub, grub, syslinux, lilo, etc... ?
[2021-07-01T04:54:43Z] <msk_1411[m]> /proc is an empty directory
[2021-07-01T04:54:50Z] <msk_1411[m]> I am using grub + efibootmgr
[2021-07-01T04:54:58Z] <testuser[m]1> Hi
[2021-07-01T04:54:59Z] <msk_1411[m]> the default on the install guide
[2021-07-01T04:55:08Z] <GalaxyNova> hi! testuser[m]1
[2021-07-01T04:55:39Z] <msk_1411[m]> I can run mount -t proc none proc/
[2021-07-01T04:56:18Z] <msk_1411[m]> then, /proc/cmdline becomes ``BOOT_IMAGE=/boot/vmlinuz-5.12.13 root=/dev/sda3 ro loglevel=3 quiet``
[2021-07-01T04:56:40Z] <msk_1411[m]> I assume ro stands for readonly
[2021-07-01T04:57:24Z] <illiliti> i guess that's the problem
[2021-07-01T04:58:05Z] <GalaxyNova> I also have ro in /proc/cmdline and i have a rw filesystem :/
[2021-07-01T04:58:14Z] <GalaxyNova> i think it's normal
[2021-07-01T04:58:48Z] <msk_1411[m]> on this, working kiss install that I'm typing from, it also says ro in /proc/cmdline
[2021-07-01T04:58:52Z] <testuser[m]1> acheam: why not use virtual environments
[2021-07-01T05:00:10Z] <acheam> testuser[m]1: can you explain more? I'm familiar with virtual environments from a developer standpoint, less so from a packaging one
[2021-07-01T05:00:52Z] <GalaxyNova> ig he's thinking of shipping a whole venv with all the deps installed?
[2021-07-01T05:01:18Z] <illiliti> msk_1411[m]: looks like your init not working correctly
[2021-07-01T05:01:36Z] <testuser[m]1> <acheam "testuser: defend yourself"> I had to flash lineage on my phone
[2021-07-01T05:01:50Z] <msk_1411[m]> Yeah, I'm just looking over the commands I had ran while installing and comparing it to the installation guide
[2021-07-01T05:01:52Z] <testuser[m]1> What's the kiss way to do it
[2021-07-01T05:02:01Z] <msk_1411[m]> I forgot to build baseinit
[2021-07-01T05:02:10Z] <illiliti> lol
[2021-07-01T05:02:11Z] <testuser[m]1> acheam: i meant just install in a local virtualenv instead of system packages
[2021-07-01T05:02:15Z] <msk_1411[m]> Damn it, I'm such an idiot
[2021-07-01T05:02:41Z] <msk_1411[m]> I'm sorry illiti, thank you for trying to help me
[2021-07-01T05:02:47Z] <acheam> oh okay testuser[m]1
[2021-07-01T05:02:57Z] <testuser[m]1> Wait you want to distribute stuff ?
[2021-07-01T05:03:05Z] <acheam> uh kind of?
[2021-07-01T05:03:14Z] <acheam> I'm just trying to package sphinx
[2021-07-01T05:03:15Z] <illiliti> msk_1411[m]: np
[2021-07-01T05:03:23Z] <illiliti> it happens to the best of us
[2021-07-01T05:03:46Z] <acheam> for now im just pip installing it
[2021-07-01T05:03:52Z] <schillingklaus> such as dilyn and dylan
[2021-07-01T05:04:16Z] <acheam> which is fine until I remove the package and it removes shared dependencies
[2021-07-01T05:04:36Z] <acheam> pip installing it as in the build file is pip installing it
[2021-07-01T05:04:44Z] <testuser[m]1> That's bad
[2021-07-01T05:04:48Z] <acheam> yes
[2021-07-01T05:05:01Z] <schillingklaus> pip installing is bad?
[2021-07-01T05:05:08Z] <acheam> but I dont know any better way that doesnt involve packaging 15 python dependencies
[2021-07-01T05:05:10Z] <testuser[m]1> In the build file
[2021-07-01T05:05:20Z] <illiliti> it clutters you system with garbage
[2021-07-01T05:05:49Z] <testuser[m]1> i just do `python -m venv ./junk`
[2021-07-01T05:06:24Z] <acheam> because I just need it for llvm right now I think I'll put it in a venv within the build
[2021-07-01T05:06:57Z] <acheam> still requires internet at the build stage but at least its not screwing with my dependencies
[2021-07-01T05:07:00Z] <testuser[m]1> What part of llvm needs it
[2021-07-01T05:07:03Z] <testuser[m]1> Doc generation ?
[2021-07-01T05:07:05Z] <acheam> yes
[2021-07-01T05:07:12Z] <GalaxyNova> what do you guys think about this pull request https://github.com/kiss-community/kiss/pull/40
[2021-07-01T05:07:32Z] <testuser[m]1> I guess you could yank the docs from arch's binary package or something into a package llvm-docs
[2021-07-01T05:08:27Z] <testuser[m]1> Other than the fact that pax isn't that commonly available, it's good
[2021-07-01T05:10:11Z] <acheam> testuser[m]1: that feels like cheating :(
[2021-07-01T05:10:26Z] <acheam> s/:\(/:\)/g
[2021-07-01T05:10:28Z] <testuser[m]1> Better than your current approach
[2021-07-01T05:10:30Z] <testuser[m]1> :p
[2021-07-01T05:15:19Z] <GalaxyNova> also btw is `shift` posix?
[2021-07-01T05:15:40Z] <illiliti> yes
[2021-07-01T05:15:52Z] <GalaxyNova> phew :D
[2021-07-01T05:15:53Z] <illiliti> it's a shell builtin
[2021-07-01T05:21:43Z] <testuser[m]1> What do you need the llvm docs for anyway acheam, not like you deal with llvm-* stuff directly
[2021-07-01T05:22:07Z] <acheam> my llvm package has clang and stuff too
[2021-07-01T05:22:56Z] <testuser[m]1> Is sphinx needed just for html docs or man pages too?
[2021-07-01T05:33:29Z] <acheam> both
[2021-07-01T05:33:36Z] <acheam> but I only generate manpages
[2021-07-01T08:23:30Z] <sad_plan> when building a package that has no deps at all, like openresolv, is there any reason to specify it being static, when going for a staticly linked system? I mean, does it make any difference when building if i export cflags -static, as opposed to not?
[2021-07-01T08:28:50Z] <testuser[m]1> it still depends on libc
[2021-07-01T08:28:59Z] <testuser[m]1> not automatically static
[2021-07-01T08:29:09Z] <testuser[m]1> Also static should be in ldflags
[2021-07-01T08:30:09Z] <sad_plan> so that would mean, in openresolv, its 'make LDFLAGS="$LDFLAGS -static"', correct?
[2021-07-01T08:31:04Z] <testuser[m]1> Yeah
[2021-07-01T08:31:26Z] <sad_plan> ok, cool.
[2021-07-01T08:32:25Z] <illiliti> openresolv is written in posix shell. it's unaffected by static flag
[2021-07-01T08:34:18Z] <illiliti> static flag will affect only programs that were written in compiled languages
[2021-07-01T08:34:58Z] <illiliti> but actually it depends on language
[2021-07-01T08:36:04Z] <sad_plan> I wasnt aware of openresolv being a shellscript. tbh I didnt check :p but yeah, I was sortof thought as much about static linking only was relevant for compiled langauges
[2021-07-01T08:38:20Z] <illiliti> why do you need openresolv? just set your dns manually in /etc/resolv.conf and make it read only
[2021-07-01T08:40:32Z] <sad_plan> I never really thought about it. I sortof just followed the guide, and it said its recommended to use openresolv. but since you mentioned it. im going to check that out momentarly
[2021-07-01T08:42:05Z] <illiliti> openresolv is usually unneeded thing unless you have dhcp server that changes dns frequently
[2021-07-01T08:44:50Z] <illiliti> personally, i use dnscrypt-proxy as a dns server
[2021-07-01T08:46:50Z] <illiliti> because my isp does mitm on dns queries
[2021-07-01T09:09:25Z] <sad_plan> I dont have a dhcp server, so I suppose I dont need it :p
[2021-07-01T09:09:52Z] <sad_plan> ah thats a bummer. I always been curious about dnscrypt, but never really figured out how it works
[2021-07-01T09:12:12Z] <testuser[m]1> You need dhcp unless static ip
[2021-07-01T09:12:45Z] <sad_plan> isnt eiwd handling that on its own?
[2021-07-01T09:13:15Z] <sad_plan> I could swear thats listed on the kiss website, and in wikis
[2021-07-01T09:15:58Z] <sad_plan> aah, no now I see. to use eiwd's builtin resolv functions, I do need openresolv. if not, I would have to install dhcp as you stated
[2021-07-01T09:53:11Z] <illiliti> false. you don't need openresolv to use eiwd
[2021-07-01T09:55:25Z] <sad_plan> so the post-install is wrong? it says you need it to use the builtin dns feature. is that no longer the case? or has that simply never been the case? :p
[2021-07-01T09:57:45Z] <illiliti> > or has that simply never been the case
[2021-07-01T09:57:47Z] <illiliti> this
[2021-07-01T10:00:09Z] <illiliti> fyi, original iwd requires either systemd or openresolv
[2021-07-01T10:00:16Z] <illiliti> i removed this nonsense in eiwd
[2021-07-01T10:01:35Z] <schillingklaus> yeah, systemd is nonsense to be deleted wherever encountered. I do not know what openresolv is, though
[2021-07-01T10:17:57Z] <sad_plan> aah, ok
[2021-07-01T10:27:21Z] <sad_plan> what is this thread support that libelf requires? libelf fails for me all the time, when trying to build it staticly. cant find anything in dilyns repos either, about that issue in particular
[2021-07-01T10:28:01Z] <testuser[m]1> show the error
[2021-07-01T10:28:09Z] <testuser[m]1> try passing -pthread manually
[2021-07-01T10:29:12Z] <sad_plan> http://0x0.st/-f-c.txt
[2021-07-01T10:29:48Z] <testuser[m]1> show config.log
[2021-07-01T10:32:04Z] <sad_plan> http://0x0.st/-f-A.log
[2021-07-01T10:32:42Z] <testuser[m]1> /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-musl/11.1.0/crtend.o: relocation R_X86_64_32 against `.ctors' can not be used when making a shared object; recompile with -fPIC
[2021-07-01T10:32:46Z] <testuser[m]1> pass --disable-shared
[2021-07-01T10:33:05Z] <testuser[m]1> you cant pass -static to build a shared library
[2021-07-01T10:33:28Z] <sad_plan> that is true. perhaps I overlooked that when making the repo.
[2021-07-01T10:43:22Z] <sad_plan> I have another question for you, which you perhaps could answer. I know that I cant for the life of me hope to compile everything staticly. so I was thinking about either not using -static flag in my cflags, or fork all those packages that I cant built staticly, and just sed away the -static flag on those packages. whats your thought on this? I currently require rust, because of firefox, and I know that staticly linking might not a
[2021-07-01T10:44:45Z] <sad_plan> if I took away -static in my cflags, I would obviously had to specify that on every damn package that I want to build staticly though, aand now that I think of it, there might be more packages that I would end up building staticly anyway
[2021-07-01T10:44:47Z] <testuser[m]1> set a kiss hook to disable static
[2021-07-01T10:45:31Z] <sad_plan> aah, yeah that would be an idea. disable it for just those few packages that I dont want to build staticly
[2021-07-01T10:45:36Z] <testuser[m]1> your depends file will be messed up with false dependencies anyways if you dont fork everything
[2021-07-01T10:48:24Z] <sad_plan> how so? because the packages already exist, but said package cant locate them?
[2021-07-01T10:48:54Z] <testuser[m]1> in normal repo foo needs libbar but you're static so it only needs libbar make
[2021-07-01T10:52:05Z] <sad_plan> aah, I see. so all packages that already exist, staticly, just needs to add make to all of those libs essentially
[2021-07-01T10:52:30Z] <sad_plan> for new packages that is
[2021-07-01T10:52:36Z] <sad_plan> thats non-static
[2021-07-01T11:18:38Z] <sad_plan> libelf still fails thought. Ive rebuilt whole core to be sure
[2021-07-01T11:18:42Z] <sad_plan> same error
[2021-07-01T11:20:19Z] <testuser[m]1> Weird
[2021-07-01T11:20:25Z] <testuser[m]1> Check dilyn kiss-static repo
[2021-07-01T11:21:11Z] <testuser[m]1> Nothing special there for libelf hmm
[2021-07-01T11:21:18Z] <testuser[m]1> Do you mind sending the modified build file of yours
[2021-07-01T11:21:37Z] <sad_plan> I dont belive I did anything in particular, but sure. buildscript comming up
[2021-07-01T11:22:03Z] <testuser[m]1> Oh
[2021-07-01T11:22:07Z] <testuser[m]1> You had to pass to configure script
[2021-07-01T11:22:09Z] <testuser[m]1> Not to ldflags
[2021-07-01T11:22:23Z] <testuser[m]1> Add --disable-shared in the build file args
[2021-07-01T11:23:02Z] <sad_plan> for libelf I assume?
[2021-07-01T11:24:12Z] <testuser[m]1> Yeah
[2021-07-01T11:29:37Z] <sad_plan> hm, doesnt appear to work. still gives me same error. hold on, and ill push the change, and give you the link. maybe you notice something that I dont
[2021-07-01T11:31:12Z] <sad_plan> https://github.com/hovercats/kiss-somethingsomethingstatic
[2021-07-01T11:33:23Z] <testuser[m]1> hmm seems ok
[2021-07-01T11:33:31Z] <testuser[m]1> send the new config.log, maybe something else is failing
[2021-07-01T11:38:41Z] <sad_plan> http://0x0.st/-f-w.log
[2021-07-01T11:40:10Z] <testuser[m]1> hmm so its still trying the same thing
[2021-07-01T11:40:13Z] <testuser[m]1> lemmme check the configure
[2021-07-01T11:40:42Z] <sad_plan> cheers
[2021-07-01T11:46:14Z] <testuser[m]1> oh it doesnt check static or shared configure options
[2021-07-01T11:47:37Z] <sad_plan> so it just ignores if I pass static, and just assumes its shared?
[2021-07-01T11:53:55Z] <testuser[m]1> it builds both
[2021-07-01T11:54:23Z] <testuser[m]1> theres not really any need to fork libs, since if you build programs that need them with -static it'll use static lib instead of shared one
[2021-07-01T11:54:39Z] <testuser[m]1> except the libs where static libs are explicitly disabled
[2021-07-01T11:56:02Z] <sad_plan> strange. aah ok. but libelf is required to build the kernel it seems, so Im sortof depndent on it. I was trying without it, but for some reason I have yet to get it to work. Ill give you the details
[2021-07-01T11:57:53Z] <sad_plan> gives me this error
[2021-07-01T11:57:59Z] <sad_plan> error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel
[2021-07-01T11:58:04Z] <cem> illiliti: No, I'm using iwd and I don't have openresolv
[2021-07-01T12:00:55Z] <cem> iwd can use dhcpcd
[2021-07-01T12:02:26Z] <illiliti> cem: did you set EnableNetworkConfiguration=true in iwd.conf?
[2021-07-01T12:02:35Z] <illiliti> dhcpcd is superfluous
[2021-07-01T12:02:43Z] <cem> I don't have a configuration at all
[2021-07-01T12:03:26Z] <cem> I just used void's patch to use dhcp by default
[2021-07-01T12:04:30Z] <cem> Not patch, just a sed call
[2021-07-01T12:05:19Z] <illiliti> show me
[2021-07-01T12:06:18Z] <cem> https://termbin.com/ulvn
[2021-07-01T12:06:54Z] <cem> It just uses /etc/resolv.conf
[2021-07-01T12:07:06Z] <cem> I'm using busybox udhcpc as my dhcp client
[2021-07-01T12:09:34Z] <illiliti> resolvconf is openresolv
[2021-07-01T12:09:47Z] <cem> I literally don't have it
[2021-07-01T12:09:52Z] <illiliti> what package provides resolvconf?
[2021-07-01T12:10:12Z] <cem> resolvconf means the file /etc/resolv.conf, doesn't it
[2021-07-01T12:10:22Z] <illiliti> no
[2021-07-01T12:10:29Z] <illiliti> resolvconf is an executable
[2021-07-01T12:10:36Z] <cem> I don't have that either
[2021-07-01T12:11:11Z] <illiliti> well, iwd doesn't require openresolv/systemd because you didn't set EnableNetworkConfiguration=true
[2021-07-01T12:11:54Z] <cem> Ah alright
[2021-07-01T12:12:19Z] <cem> I misunderstood you then
[2021-07-01T12:12:25Z] <illiliti> EnableNetworkConfiguration=true basically enables builtin dhcp
[2021-07-01T12:12:43Z] <dilyn> static libelf is garbage :)
[2021-07-01T12:13:22Z] <cem> illiliti: oh I forgot about that
[2021-07-01T12:13:29Z] <cem> eiwd doesn't need it?
[2021-07-01T12:13:33Z] <cem> That's nice
[2021-07-01T12:13:54Z] <cem> dilyn: s,static ,,
[2021-07-01T12:14:15Z] <cem> Jokes aside, why?
[2021-07-01T12:14:30Z] <testuser[m]1> build system issue
[2021-07-01T12:14:38Z] <dilyn> because it's build system won't let you actually just make it statically
[2021-07-01T12:14:44Z] <dilyn> https://github.com/dilyn-corner/KISS-me/blob/c213399825033bfc1f0ee8036cdbae42941d6dbd/extra/libelf/build
[2021-07-01T12:14:55Z] <cem> Is it libtool?
[2021-07-01T12:15:06Z] <dilyn> no
[2021-07-01T12:15:14Z] <dilyn> it's just bad :v
[2021-07-01T12:16:10Z] <cem> Manually link everything :^)
[2021-07-01T12:16:15Z] <dilyn> tbh...
[2021-07-01T12:18:08Z] <illiliti> elfutils devs are hostile
[2021-07-01T12:18:52Z] <illiliti> they are sabotaging us
[2021-07-01T12:19:29Z] <dilyn> well if you don't use AMDGPU and you don't mind using a worse unwinder... (:
[2021-07-01T12:20:23Z] <sad_plan> i amd using amdgpu :( I dunno what the unwinder is anywah either :p
[2021-07-01T12:21:51Z] <dilyn> womp
[2021-07-01T12:21:53Z] <testuser[m]1> you can just rm the .so files
[2021-07-01T12:23:28Z] <sad_plan> what .so files?
[2021-07-01T12:23:49Z] <testuser[m]1> the ones built by libelf
[2021-07-01T12:23:53Z] <testuser[m]1> and just keep the static lib
[2021-07-01T12:24:44Z] <illiliti> what is the state of kiss? seems like development slowly diverging(?)
[2021-07-01T12:28:08Z] <sad_plan> but libelf doesnt build for me..
[2021-07-01T12:29:32Z] <testuser[m]1> It does
[2021-07-01T12:29:37Z] <testuser[m]1> Just remove -static
[2021-07-01T12:30:41Z] <sad_plan> ah ok. ill do it when I get back on my laptop. cheers
[2021-07-01T12:32:26Z] <dilyn> pro tip: -static is a useless flag
[2021-07-01T12:33:01Z] <cem> Why?
[2021-07-01T12:33:39Z] <dilyn> because nobody really knows what it does, and some build systems just don't care about it
[2021-07-01T12:33:51Z] <dilyn> like meson! it gives no fucks. It just finds the library, you don't get to choose
[2021-07-01T12:34:53Z] <cem> Yeah, sadly true for quite a lot of software
[2021-07-01T12:35:17Z] <cem> But I also kind of don't want to link anything on the X side statically
[2021-07-01T12:35:26Z] <dilyn> hhhhmmmmm, why?
[2021-07-01T12:35:35Z] <cem> The size
[2021-07-01T12:35:35Z] <dilyn> I think linking X stuff statically is the ideal case tbh
[2021-07-01T12:35:45Z] <dilyn> it should be smaller!
[2021-07-01T12:36:07Z] <cem> slock statically linked 1.1M
[2021-07-01T12:36:13Z] <cem> slock dynamically linked 52K
[2021-07-01T12:36:28Z] <dilyn> what all does slock depend on?
[2021-07-01T12:36:39Z] <cem> libX11 and that's it
[2021-07-01T12:36:55Z] <testuser[m]1> lol glibc libx11 static is 10M
[2021-07-01T12:36:59Z] <testuser[m]1> eww
[2021-07-01T12:37:11Z] <testuser[m]1> oh this time it isnt glibc
[2021-07-01T12:37:16Z] <testuser[m]1> its just fat
[2021-07-01T12:37:34Z] <dilyn> well that' aint true cem; the whole dep chain for libX11 then is something like 9 packages
[2021-07-01T12:38:41Z] <cem> Okay linking dynamically just a sec
[2021-07-01T12:38:52Z] <cem> libXext and libXrandr
[2021-07-01T12:39:32Z] <cem> I can ldd for the indirect dependencies as well
[2021-07-01T12:40:00Z] <cem> libc, X11, Xext, Xrandr, xcb, Xau, Xrender
[2021-07-01T12:40:14Z] <dilyn> comparing static to nonstatic directly is always going to show the static version as being bigger; you have to talk about size differences holistically if you want gains
[2021-07-01T12:40:30Z] <dilyn> that is to say, you no longer need a ton of dependencies, so you can include those size savings for slock
[2021-07-01T12:40:51Z] <dilyn> but yeah, a static object on its own will probably be a bit bigger
[2021-07-01T12:40:59Z] <cem> Kind of true, I guess
[2021-07-01T12:43:02Z] <dilyn> my static KISS chroot tarball is 34MB (w/o a toolchain) and just over 100MB with, but a regular KISS chroot tarball is over 200 uncompressed
[2021-07-01T12:43:10Z] <dilyn> so a lot of that space lives in /lib
[2021-07-01T12:43:53Z] <cem> Well the total is 2.1M
[2021-07-01T12:44:34Z] <cem> But, if you are going to have multiple X binaries, you're still better off linking them dynamically, no?
[2021-07-01T12:45:11Z] <cem> 5 dynamically linked slock binaries plus the libraries are smaller than 5 statically linked slock binaries
[2021-07-01T12:45:14Z] <dilyn> I mean i think you're better off in general dynamically linking a lot of things xD
[2021-07-01T12:46:15Z] <cem> You don't see that difference quite a lot on linking smaller software such as ones that use libcurl or libssl
[2021-07-01T12:46:50Z] <cem> Things go from 100K to 200K, not from 52K to 1M
[2021-07-01T12:48:07Z] <cem> That's why I don't get much excited on linking X programs statically
[2021-07-01T12:48:19Z] <cem> Maybe I'm wrong to think that way idk
[2021-07-01T12:48:50Z] <cem> Since storage is not a big issue anyway
[2021-07-01T12:50:43Z] <dilyn> luckily people decided for us which way was better haha
[2021-07-01T12:51:07Z] <dilyn> so now we just get to sit in shadowy corners of the internet and reee into the ether about how static is superior bla hoopla
[2021-07-01T14:05:52Z] <claudia> acheam, you said you got distcc working. Could you share your build? and maybe say something if you created special users/group.
[2021-07-01T14:11:50Z] <testuser[m]1> claudia duper tux kart is missinf dependency on glew
[2021-07-01T14:12:00Z] <testuser[m]1> In kiss games
[2021-07-01T14:16:05Z] <claudia> fixed. thanks
[2021-07-01T14:16:35Z] <claudia> I changed removed glu and added glew, since glew depends on glu.
[2021-07-01T14:29:58Z] <acheam> claudia: https://git.sr.ht/~armaan/kiss-repo/tree/main/distcc
[2021-07-01T14:37:21Z] <claudia> thanks. I had once http://ix.io/3rEu . Which is pretty much the same. But my client never showd up on my server distcc :(
[2021-07-01T15:03:14Z] <acheam> :(
[2021-07-01T15:27:46Z] <testuser[m]1> Release tarballs for projects shouldn't include the .git directory right ?
[2021-07-01T15:31:18Z] <konimex> aye
[2021-07-01T15:39:08Z] <omanom> @midfavila http://0x0.st/-fH2.png nice FVWM setup
[2021-07-01T15:41:11Z] <omanom> https://github.com/wooosh/dots/tree/master/.fvwm
[2021-07-01T15:45:40Z] <testuser[m]1> https://github.com/kisslinux/repo/commits/master looks like dylan wants to remove install usage completely
[2021-07-01T15:56:47Z] <dilyn> that's an interesting shift
[2021-07-01T16:26:48Z] <msk_1411[m]> is there a significant difference in functionality?
[2021-07-01T16:27:35Z] <msk_1411[m]> he seems to just be using stuff like cp and mkdir instead
[2021-07-01T16:36:03Z] <dilyn> you'd probably have to rely on -p a lot
[2021-07-01T16:36:23Z] <testuser[m]1> <msk_1411[m] "is there a significant differenc"> Its more portable
[2021-07-01T16:42:05Z] <midfavila> Anyone running into trouble with hummingbird init? My new image makes it to a tty and prompt, and I can do some stuff (edit files, display images on the framebuffer, make Internet connections over ethernet, etc) but the second I try to run X or any sort of daemon like iwd, I drop to a root prompt for a split second with the error "init failed", before being forced into a reboot
[2021-07-01T17:04:40Z] <acheam> testing it, I see
[2021-07-01T17:04:56Z] <midfavila> it's reproducible, then?
[2021-07-01T17:05:03Z] <midfavila> fwiw shifting to shinit works for me
[2021-07-01T17:21:50Z] <claudia02> dilyn: I have seen you a few times using german words in an english conversation. Like your post on reddit, using the word "verboten".
[2021-07-01T17:22:06Z] <claudia02> Is this something english speakers usually understand?
[2021-07-01T17:22:17Z] <dilyn> depends on the audience xD
[2021-07-01T17:22:29Z] <omanom> there's some generally well-known words
[2021-07-01T17:22:31Z] <dilyn> but I think americans frequently comandeer words from other languages, either knowingly or not
[2021-07-01T17:22:36Z] <omanom> verboten, achtung, wunderbar
[2021-07-01T17:22:44Z] <midfavila> english speakers in general borrow words a lot
[2021-07-01T17:22:57Z] <dilyn> ciao, gesundheit, hola
[2021-07-01T17:23:16Z] <claudia02> y verboten is prob a pretty popular word.
[2021-07-01T17:23:57Z] <omanom> plus with the number of movies / tv shows / books with WWII as a subject there tends to be some exposure
[2021-07-01T17:24:23Z] <claudia02> gotcha. make sense.
[2021-07-01T17:24:39Z] <claudia02> this always made me stumble
[2021-07-01T17:25:30Z] <dilyn> us americans are a tricky folx
[2021-07-01T17:25:54Z] * midfavila rolls their eyes
[2021-07-01T17:28:01Z] <omanom> from the US perspective, German immigrants were a large percentage of the settlers all across the country
[2021-07-01T17:28:24Z] <dilyn> indeed!
[2021-07-01T18:39:00Z] <midfavila> hmm. and now I'm running into a second weird error... anyone ever have X fail to start with "Failed to set IOPL for I/O function (not implemented)"?
[2021-07-01T18:40:24Z] <omanom> i have not, what's your full Xorg log?
[2021-07-01T18:40:28Z] <msk_1411[m]> what are the permissions on xinit
[2021-07-01T18:40:34Z] <midfavila> looks like it's something to do with the way that programs in protected and long mode on IA32 and amd64 chips access system IO... which makes some degree of sense, but I'm not sure why there'd be problems stemming from that. unless it's something to do with my workstation's slightly different ISA than my laptop's (Haswell-E compared to Haswell)
[2021-07-01T18:40:49Z] <msk_1411[m]> * what are the permissions on your xinit executable
[2021-07-01T18:40:51Z] <midfavila> fwiw I'm just trying to run X -configure, not xinitrc
[2021-07-01T18:40:55Z] <midfavila> i don't use xinit
[2021-07-01T18:41:13Z] <midfavila> as for the logs, will post after I've rebuilt the binary on my laptop - I want to make sure it's not some weirdness with ISA differences, omanom
[2021-07-01T18:41:32Z] <omanom> gotcha, ok
[2021-07-01T18:41:38Z] <omanom> gotcha, ok
[2021-07-01T18:42:10Z] <midfavila> crusin' down the binary highway at a blazing 800mhz
[2021-07-01T18:47:07Z] <midfavila-laptop> alright, wew
[2021-07-01T18:47:10Z] <midfavila-laptop> logs incoming
[2021-07-01T18:47:30Z] <midfavila-laptop> http://0x0.st/-f89.log
[2021-07-01T18:47:59Z] <midfavila-laptop> looks like something to do with stripping..?
[2021-07-01T18:48:36Z] <midfavila-laptop> but checking the mentioned drivers with file says that they're not stripped, and I don't know when or how non-executables would have been stripped, besides
[2021-07-01T18:48:45Z] <midfavila-laptop> i've made stupid mistakes, but nothing like that before
[2021-07-01T18:52:36Z] <omanom> do you have xf86-video-intel built?
[2021-07-01T18:52:54Z] <midfavila-laptop> Yeah. That's what's providing my intel video driver.
[2021-07-01T18:53:36Z] <midfavila-laptop> I've already tried rebuilding it, but no dice. Gonna see if libpciaccess or libdrm are the culprit...
[2021-07-01T18:54:52Z] <omanom> did you rebuild xorg-server too? weird issue, for sure
[2021-07-01T18:54:57Z] <midfavila-laptop> Yep
[2021-07-01T18:55:07Z] <midfavila-laptop> This latest image has been nothing but trouble
[2021-07-01T18:55:34Z] <midfavila-laptop> randomly overwriting perms or files, hummingbird was acting funky, and now this
[2021-07-01T18:57:09Z] <midfavila-laptop> hmm. seems like the symbol it's complaining about is normally provided by libfb.so
[2021-07-01T18:57:22Z] <midfavila-laptop> which is available and hasn't been hit with any weird mutations...
[2021-07-01T18:57:45Z] <dilyn> do anything strange with your graphics selections in the kernel?
[2021-07-01T18:58:00Z] <midfavila-laptop> nothing at all. just bog standard, as per defconfig
[2021-07-01T18:58:34Z] <midfavila-laptop> besides,
[2021-07-01T18:58:40Z] <midfavila-laptop> this occurs with my previous kernel, as well
[2021-07-01T18:58:45Z] <midfavila-laptop> which wasn't giving me trouble on my last install
[2021-07-01T18:58:49Z] <midfavila-laptop> it can't be a kernel error
[2021-07-01T18:59:04Z] <dilyn> i mean, why not?
[2021-07-01T18:59:23Z] <cem> what's wrong with shinit anyways :^)
[2021-07-01T18:59:30Z] <midfavila-laptop> because if it was an error with my latest kernel, switching to the known-good kernel would fix it
[2021-07-01T18:59:42Z] <midfavila-laptop> it does not, and has the same error, meaning it must be something else
[2021-07-01T19:00:08Z] <midfavila-laptop> and there's nothing wrong with shinit, it was hummingbird that was giving me trouble. kept dropping to an emergency shell and forcing a reboot under certain seemingly-unrelated conditions
[2021-07-01T19:00:35Z] <cem> yeah, I was making the joke of "why swtich off of it"
[2021-07-01T19:00:47Z] <midfavila-laptop> including, but not limited to: my shell reading /etc/profile, attempting to start XDM, ending an iwd process, using emacs...
[2021-07-01T19:01:06Z] <midfavila-laptop> but at least ALSA isn't giving me trouble lmfao
[2021-07-01T19:01:31Z] <midfavila-laptop> the worst part about this error is that there's nothing useful about it on the net
[2021-07-01T19:01:51Z] <midfavila-laptop> just some old posts about ARM debian from 2004 and some mint user whose suggestion was "turn it off and on again a few times"
[2021-07-01T19:02:10Z] <midfavila-laptop> and some stuff about SELinux, which... I don't even have enabled in the kernel.
[2021-07-01T19:02:22Z] <cem> Maybe because you are booting with "ro" option?
[2021-07-01T19:02:36Z] <midfavila-laptop> init remounts root rw
[2021-07-01T19:02:44Z] <cem> tru
[2021-07-01T19:02:47Z] <midfavila-laptop> and i was booting with ro before, besides
[2021-07-01T19:03:06Z] <midfavila-laptop> hmm.
[2021-07-01T19:03:15Z] <cem> I had a similar issue with ro but that was a long time ago
[2021-07-01T19:03:19Z] <midfavila-laptop> i don't even think this is an X error. it's gotta be one of the supporting libraries or programs...
[2021-07-01T19:03:45Z] <midfavila-laptop> the framebuffer device is available and works, too...
[2021-07-01T19:03:50Z] <dilyn> i mean it's literally a missing symbol error, in the driver (presumably) supplied by xf86-video-intel, and that missing symbol is in one of the xorg-server libs
[2021-07-01T19:03:50Z] <cem> The problem is that I don't remember the details, it was on Void
[2021-07-01T19:04:01Z] <omanom> there's a Sabotage post from like 2015: https://www.openwall.com/lists/sabotage/2015/01/09/1
[2021-07-01T19:04:29Z] <dilyn> did mid fork xorg-server to disable glamor :P
[2021-07-01T19:04:44Z] <midfavila-laptop> nope.
[2021-07-01T19:04:57Z] <midfavila-laptop> vesa doesn't cmoplain about missing symbols though
[2021-07-01T19:05:05Z] <midfavila-laptop> but it still fails with the same error
[2021-07-01T19:05:16Z] <omanom> well, 2014 is the more exact one: https://www.openwall.com/lists/sabotage/2014/11/17/5
[2021-07-01T19:05:19Z] <midfavila-laptop> xf85EnableIOPorts: failed to set IOPL for I/O (Function not implemented)
[2021-07-01T19:05:52Z] <cem> So maybe since I came late to this conversation that I don't exactly understand what's going on
[2021-07-01T19:05:59Z] <cem> X fails on shinit, but not on hummingbird?
[2021-07-01T19:06:03Z] <midfavila-laptop> no
[2021-07-01T19:06:06Z] <cem> Sorry the vice versa
[2021-07-01T19:06:07Z] <midfavila-laptop> X is a seperate issue
[2021-07-01T19:06:11Z] <cem> Oh okay
[2021-07-01T19:06:50Z] <midfavila-laptop> i honestly have no clue what's going on with X. the missing symbol thing is obviously a problem, but if vesa doesn't run into that issue, but KMS and the Intel driver do, then it's clearly small-fry compared to this IOPL problem
[2021-07-01T19:11:01Z] <dilyn> how are you starting X?
[2021-07-01T19:11:23Z] <dilyn> it's either a symbol error or a permissions error, and if you rebuilt a bunch of things then it's probably perms
[2021-07-01T19:11:31Z] <midfavila> X -configure, like I said
[2021-07-01T19:11:39Z] <midfavila> and it's not permissions, I've already checked that.
[2021-07-01T19:12:15Z] <cem> Seems Dylan released a new version of kiss https://github.com/kisslinux/kiss/releases/tag/5.4.0
[2021-07-01T19:15:40Z] <omanom> doesn't that just generate a configuration file and exit?
[2021-07-01T19:15:52Z] <omanom> or does it start and persist an X server
[2021-07-01T19:16:04Z] <midfavila> it generates a configuration file, yes
[2021-07-01T19:16:12Z] <midfavila> without that, it fails to start, stating a lack of screens
[2021-07-01T19:16:18Z] <midfavila> hence my attempt to generate said configuration
[2021-07-01T19:16:43Z] <dilyn> making a xorg.conf usually causes more problems than it solves
[2021-07-01T19:16:54Z] <midfavila> tell that to my desktop.
[2021-07-01T19:16:57Z] <dilyn> it's not even a recommended way of setting up xorg afaik
[2021-07-01T19:17:02Z] <midfavila> either way
[2021-07-01T19:17:10Z] <midfavila> my choice of using an xorg configuration file or not isn't what's relevant
[2021-07-01T19:17:25Z] <omanom> does one get generated? or it fails before the file is generated at all
[2021-07-01T19:17:41Z] <midfavila> fails before it can generate the file. i assume it has to have IOPL capability before it can query the display panel
[2021-07-01T19:17:52Z] <midfavila> so when it attempts said query to generate a config file, it fails
[2021-07-01T19:18:03Z] <msk_1411[m]> using xinit still results in the same error, then, right?
[2021-07-01T19:18:29Z] <midfavila> it likely would.
[2021-07-01T19:26:15Z] <omanom> any chance we can convince you to try with xinit and/or sx?
[2021-07-01T19:27:09Z] <midfavila> sure, I'll give it a shot, but I have doubts it'll change anything
[2021-07-01T19:27:47Z] <midfavila-laptop> yup, same error
[2021-07-01T19:28:20Z] <omanom> thanks for trying it, was hoping it was some weird "X is now out of date" problem
[2021-07-01T19:28:44Z] <midfavila-laptop> that would be nice, but none of the problems I run into seem that simple :\
[2021-07-01T19:31:43Z] <midfavila-laptop> yeah... a little more in-depth look, with VESA X is able to detect the screen, but still fails with IOPL errors. what a pain...
[2021-07-01T19:31:49Z] <midfavila-laptop> watch it be something completely unrelated to X
[2021-07-01T19:37:15Z] <omanom> there's this: https://wiki.archlinux.org/title/Intel_graphics#Xorg_configuration
[2021-07-01T19:37:34Z] <omanom> on my kissbox its under /usr/share/X11 rather than /etc/X11
[2021-07-01T19:37:54Z] <midfavila> X checks under /usr/share/X11 and /etc/X11
[2021-07-01T19:38:25Z] <midfavila> ...wait a second...
[2021-07-01T19:38:34Z] <midfavila> ...
[2021-07-01T19:38:41Z] <midfavila> ...could it... no, never mind.
[2021-07-01T19:39:00Z] <omanom> lol you can't just say never mind, spit it out!
[2021-07-01T19:39:08Z] <midfavila> i was going to say that it might have something to do with me fiddling with how the TTY handles the framebuffer, to increase available columns and spaces
[2021-07-01T19:39:39Z] <midfavila> but that's still a kernel-level thing, and the known-good kernel (still encountering the same problem) had stock framebuffer settings
[2021-07-01T19:39:44Z] <midfavila> so that can't be it either
[2021-07-01T19:40:22Z] <omanom> i wouldn't think so, "fbPutImage: symbol not found" implies a framebuffer (fb) problem but your intel drivers built fine so...
[2021-07-01T19:40:36Z] <midfavila> i'm not even concerned about that at this point
[2021-07-01T19:40:51Z] <midfavila> the bigger issue imho is this IOPL failure
[2021-07-01T19:41:16Z] <midfavila> like I mentioned earlier, the VESA drivers don't run into the symbol error, but they do still hit a brick wall with IOPL problems
[2021-07-01T19:42:06Z] <cem> midfavila: Ugh, try setting setuid?
[2021-07-01T19:42:08Z] <omanom> i dunno, the log fails to load all available drivers /prior/ to spitting out that IOPL issue. maybe im reading it wrong
[2021-07-01T19:42:27Z] <midfavila> cem I'm running X as root rn
[2021-07-01T19:42:33Z] <cem> Oh
[2021-07-01T19:42:55Z] <midfavila> omanom yeah, but it only fails to load the KMS and intel drivers due to the missing symbol error, at which point it succeeds with the VESA driver
[2021-07-01T19:43:48Z] <omanom> the log you provided doesn't show any VESA driver load that i see?
[2021-07-01T19:43:58Z] <cem> which package owns /usr/lib/xorg/modules/drivers/modesetting_drv.so?
[2021-07-01T19:44:21Z] <midfavila> i gave the VESA driver a shot after uploading the logs, omanom, but aside from that one change it's the same
[2021-07-01T19:44:25Z] <midfavila> will check, cem
[2021-07-01T19:44:41Z] <omanom> oh alright, ok
[2021-07-01T19:45:03Z] <midfavila-laptop> xorg-server cem
[2021-07-01T19:45:10Z] <midfavila-laptop> which is to be expected
[2021-07-01T19:45:14Z] <midfavila-laptop> i'm just using the standard xorg repo
[2021-07-01T19:47:09Z] <cem> Ah alright mine were static
[2021-07-01T22:09:00Z] <midfavila> the uplink ost is so aesthetic