01:47 <fishe> been trying for literally multiple days and no matter what i do wine just can't see my controller

01:50 <braewoods> fishe: is it recognized by anything at all?

01:50 <fishe> xpad sees it fine and using jstest everything functions fine, but wine doesn't pick it up

01:51 <fishe> ive been trying to get xboxdrv to compile to no avail, there is one in the portdb through some third party but it's multiple years out of date

01:51 <braewoods> i wonder if there's a missing wine dependency or similar.

01:52 <fishe> i can check the pkgfile and see if im missing anything rq

01:52 <braewoods> but i can say it's probably a configuration problem at build or runtime. i know controllers work under wine on other distributions.

01:52 <braewoods> and/or maybe a kernel issue if your drivers are wrong

01:53 <braewoods> it gets kinda complex

01:56 <fishe> all of the listed dependencies are there

01:56 <fishe> guess i'll try recompiling now that xpad is installed

01:59 <braewoods> fishe: i would test it with Linux native software that is known to support controllers. particularly an emulator to see if it can detect it at all

02:00 <braewoods> mednafen, snes9x being some examples

02:00 <braewoods> or super tux kart or w/e it is called these days

02:01 <fishe> ill test it with supertuxcart, i only play one game and it isn't linux native

02:18 <fishe> weirdly, it looks like the controller isn't found in tuxkart either. maybe because `/dev/input/js0` is kind of a strange place for a controller to be?

02:35 <fishe> slowly becoming more and more disenchanted with the idea of compiling everything from source

09:18 <cruxbot> [xorg.git/3.6]: xkeyboard-config: update to 2.36

09:18 <cruxbot> [opt.git/3.6]: graphviz: update to 4.0.0

09:18 <cruxbot> [opt.git/3.6]: iwd: update to 1.28

11:11 <cruxbot> [contrib.git/3.6]: firefox: 100.0.2 -> 101.0

11:28 <cruxbot> [opt.git/3.6]: firefox-bin: 100.0.2 -> 101.0

11:34 <cruxbot> [contrib.git/3.6]: mkvtoolnix: 67.0.0 -> 68.0.0

11:41 <cruxbot> [opt.git/3.6]: glslang: 11.9.0 -> 11.10.0

12:14 <cruxbot> [contrib.git/3.6]: thunderbird: 91.9.1 -> 91.10.0

12:40 <ppetrov^> graphviz fails to build if ghostscript is present

12:43 <ppetrov^> https://pastebin.com/ud8zEXca

17:29 <farkuhar> I never had any INSTALL NO directives in pkgadd.conf until groovy2shoes pointed out that the system would work just fine without any libtool .la files. So I went ahead and put the corresponding INSTALL NO line in /etc/pkgadd.conf.

17:30 <farkuhar> After having it there for a few months, I got around to running prtcheckmissing, and that's when I learned that the package database still thinks there should be .la files in /usr/lib.

17:32 <farkuhar> I dug into the pkgadd source code and noticed that the call to db_commit() happens BEFORE any install rules from pkgadd.conf are applied.

17:34 <farkuhar> If anyone has INSTALL NO directives in their pkgadd.conf, and you want less confusing output, here's a one-liner that'll do it: grep -v -f <(awk '/^\s*INSTALL.*NO$/ {print gensub(/\^(.*)\$/, "^/\\1 ", "g", $2)}' /etc/pkgadd.conf) <(prtcheckmissing)

17:36 <farkuhar> I tried to put the filter into prtcheckmissing itself, but perl's grep function kept complaining about "useless use of a private array in a void context". Changing the grep to a foreach loop does work, but it's easier just to do the grep outside of prtcheckmissing.

19:52 <farkuhar> Got it to work inside the perl script itself: http://sprunge.us/MWYXEc?pl apparently the perl compiler needed some syntactical hints (braces instead of parentheses) to know whether the first argument to grep is an "expression" or a "block of code" (with Boolean return value)

19:55 <farkuhar> But a bigger issue is the divergence between the package database and what's on the filesystem. If you set up INSTALL NO rules in pkgadd.conf for a different reason (say you want some config files in /etc to be managed independently of prt-get and pkgadd), then running pkgrm on a package, which had INSTALL NO rules applied, might remove files that you didn't ever want prt-get to touch. This behaviour is similar to, but distinct from, the issue raised in FS#1888

20:47 <cruxbot> [opt.git/3.6]: mtools: updated to version 4.0.40

20:51 <cruxbot> [opt.git/3.6]: alsa-utils: updated to version 1.2.7

20:51 <cruxbot> [opt.git/3.6]: alsa-ucm-conf: updated to version 1.2.7

20:51 <cruxbot> [opt.git/3.6]: alsa-lib: updated to version 1.2.7

20:51 <cruxbot> [compat-32.git/3.6]: alsa-lib-32: updated to version 1.2.7

21:00 <cruxbot> [contrib.git/3.6]: containerd: updated to version 1.6.5

21:06 <cruxbot> [contrib.git/3.6]: nginx: updated to version 1.22.0

22:47 <cruxbot> [opt.git/3.6]: nodejs: 18.2.0 -> 18.3.0