jaeger changed the topic of #crux to: CRUX 3.7 | Homepage: https://crux.nu/ | Ports: https://crux.nu/portdb/ https://crux.ninja/portdb/ | Logs: https://libera.irclog.whitequark.org/crux/
ivandi has quit [Quit: WeeChat 4.0.4]
ivandi has joined #crux
remiliascarlet has joined #crux
samsep10l has joined #crux
<samsep10l> jaeger: hello, I am installing the mingw-w64 family packages, and I saw version mistmatch between some of them, for example: mingw-w64-gcc points to 12.2.0 release, but both mingw-w64-crt and mingw-w64-headers point to 10.0.0 release. wine build fine with that, but maybe they should be upgrade as mingw-w64-gcc?
<samsep10l> jaeger: my mistake, I compared the gcc version with mingw-w64, which both are different. :-)
remiliascarlet has quit [Quit: WeeChat 4.0.3]
remiliascarlet has joined #crux
<cruxbot> [contrib.git/3.7]: python3-gevent: 23.7.0 -> 23.9.0
<cruxbot> [contrib.git/3.7]: xdg-desktop-portal: 1.17.1 -> 1.17.2
<cruxbot> [opt.git/3.7]: strace: 6.4 -> 6.5
<cruxbot> [opt.git/3.7]: dbus: 1.14.8 -> 1.14.10
<cruxbot> [compat-32.git/3.7]: dbus-32: 1.14.8 -> 1.14.10
<SiFuh> Weird. I have a USB 3.0 type C Gigabit Lan Ethernet dongle. It works all my computers that have a type C port except the MSI Delta 15. If I use a type C to type A adapter it works fine. But for some weird reason even though the type C port works for everything else it doesn't work for that dongle.
<SiFuh> Wonder why the MSI Delta 15's type C port recognizes everything but that dongle and yet the type A right beside it recognizes the dongle.
<remiliascarlet> Did you enable the appropriete motherboard and/or USB supports in the kernel?
<SiFuh> Everything works in the MSI Delta 15's type C port. Even the other type C port on the other side of the laptop. The only exception is that this particular dongle doesn't work in these type C ports and only in the type A ports which are directly beside the type C ports. The dongle works fine work in the type C ports for all my other machines but just not in the MSI Delta 15.
lavaball has joined #crux
disapper3nce has joined #crux
disapper3nce has quit [Quit: Client closed]
lavaball has quit [Remote host closed the connection]
lavaball has joined #crux
disapper3nce has joined #crux
disapper3nce has quit [Quit: Client closed]
<samsep10l> hi, anyone here have this bug with mpv? mpv: symbol lookup error: /usr/lib/libshaderc_shared.so.1: undefined symbol: _ZTVN8spvtools5utils5TimerE
<ukky> samsep10l: It seems similar to this: https://bugs.archlinux.org/task/63720
<SiFuh> rebuild shaderc
<SiFuh> The command revdep is also your friend
<SiFuh> ukky: One of the comments says to rebuild libplacebo as well
<samsep10l> SiFuh: yeah, I think I missed libplacebo, I am sure I rebuild shaderc but not that one. I will try
<SiFuh> samsep10l: revdep should so the effected packages everytime you recompile anyway
<SiFuh> so/show
<samsep10l> mm so far no luck, i rebuilt shaderc, libplacebo and mpv, and still get the same error, from i see, revdep seems ok but no luck. I also tried to downgrade glslang to 12.3.1, but still nothing. I will still look later.
<SiFuh> I will attempt this build but it will take awhile because internet is under heavy load so downloading is going to be slow.......
dunnoifishouldus has joined #crux
dunnoifishouldus has quit [Client Quit]
<farkuhar> samsep10l: it should be possible to fix the breakage without downgrading glslang. I hit a similar error after glslang got bumped to 13.0.0 but it was resolved by rebuilding shaderc, as SiFuh said.
<farkuhar> in the ArchLinux bug report that ukky shared, it was the glslang maintainer who left the final comment (taking responsibility for not foreseeing the possible breakage).
<samsep10l> farkuhar: yeah, I was trying the downgrade glslang because of that comment.
<farkuhar> samsep10l: on a distro like Arch that uses binary packages by default, downgrading is the most convenient option. But on CRUX it's just as easy to rebuild the direct dependent of glslang (in this case, shaderc).
<ukky> samsep10l: Try rebuilding spirv-tools
<samsep10l> ukky: leave glslang installed right?
<ukky> glslang depends on spirv-tools, so yeah, leave glslang installed
<samsep10l> farkuhar: so far, rebuilding only shaderc did nothing on mpv, and rebuilding glslang, shaderc,libplacebo and mpv itself, did nothing on mpv. I will try what ukky says and tell you both.
<SiFuh> samsep10l: I can't even build gslang
<SiFuh> FAILED: src/libplacebo.so.192.p/glsl_glslang.cc.o
<SiFuh> libplacebo not glsang sorry
<farkuhar> for comparison, here are the timestamps of the packages on my system: glslang#13.0.0 Aug 28 16:00; libplacebo Aug 20 20:26; spirv-tools Aug 18 20:19; shaderc Aug 31 07:58; and mpv Aug 30 14:21.
<farkuhar> so the only packages I updated after glslang were shaderc and mpv. Maybe I tried to build libplacebo but hit the same error as SiFuh. Anyway, I managed to get mpv working even without rebuilding libplacebo or spirv-tools.
exark has quit [Server closed connection]
<SiFuh> farkuhar: I can't compile shaderc either
exark has joined #crux
<SiFuh> resources.cc:142:6: error: cannot convert '<brace-enclosed initializer list>' to 'int' in initialization
<samsep10l> what libplacebo version do you have guys? I have 6.292.1 in his Pkgfile
<SiFuh> I will try to rebuild spirv-tools since it is a dependency
<samsep10l> in /contrib
<SiFuh> Latest as of 2 days ago samsep10l
<farkuhar> SiFuh: can you paste the full build log somewhere? I'll want to dig into this breakage some more.
<SiFuh> farkuhar: can, but I should do a ports -u to make sure I am up-to-date first
<SiFuh> Only two days behind though
<SiFuh> farkuhar: what is that xi.io thinging that jaeger uses to 'dpaste like thing' on the cmdline?
<farkuhar> http://ix.io
<SiFuh> Cheers
<SiFuh> No expiry date?
<SiFuh> http://ix.io/4Fc1 <-- So this is basically forever?
<farkuhar> until they have to recycle that url, I guess
<SiFuh> Okay
<SiFuh> farkuhar: http://ix.io/4Fc2 <- shaderc
<samsep10l> ey i finally make it to work! I removed spirv-{headers,tools}, glslang, sahderc, libplacebo and mpv, and install in order: spirv-headers, spirv-tools, glslang, shaderc, libplacebo, mpv
<SiFuh> http://ix.io/4Fc4 <-- libplacebo
<samsep10l> i will try again, i don't know if that is the correct order or it just luck.
<farkuhar> samsep10l: nice work!
<samsep10l> i just reinstall mpv again with `prt-get depinst mpv` and now just magically works. I am very confused about this haha
samsep10l has quit [Quit: Lost terminal]
<farkuhar> SiFuh: those are very old versions of shaderc and libplacebo you're trying to build. I thought you did 'ports -u' already.
<SiFuh> I did
<farkuhar> what architecture is it? arm or x86_64?
<SiFuh> WTF? We are still on CRUX 3.7 right?
<SiFuh> x86_64
samsep10l has joined #crux
<farkuhar> you don't happen to have an overlay that's masking the contrib repo, do you?
<SiFuh> No
<ukky> SiFuh is testing 3.8
<farkuhar> strange. Here the most current versions are shaderc#2023.6 and libplacebo#6.292.1, but your build logs show shaderc#2022.1 and libplacebo#4.192.1
<SiFuh> I am running ports -u again. I did a sysup
<farkuhar> ukky: maybe it's that external drive where SiFuh saves his distfiles and ports. If it's mounted read-only then ports -u would have no effect.
<SiFuh> And will complain
<SiFuh> mmm
<SiFuh> Ahhhhhhhhhhhhhhhhhhh
<SiFuh> contrib.rsync.inactive <---
<SiFuh> Good catch farkuhar
<farkuhar> SiFuh: I have that too ... but /etc/ports/contrib.git-ssh on my system has taken on the duties previously delegated to the rsync driver.
<SiFuh> samsep10l: Got a lot to update on this machine now.
<SiFuh> Where to get the git stuff?
<SiFuh> I have been using git for my repo for a long time. Would love to have all the crux repos under git as well.
<farkuhar> According to the gitweb page: "git clone git://crux.nu/ + project path"
<farkuhar> Then you just modify the git driver to match whatever appears in .git/config
<farkuhar> Yup, that should work. But if you also have write-access to the repo, you can use this sync file instead: http://ix.io/4Fcb
<SiFuh> No write access
<SiFuh> I tried that already before moving to git ;-)
<samsep10l> also, mpv in my case, needs to have xorg-libxpresent or none or my videos are played (maybe it is for my gpu, an amd)
<samsep10l> it is listed as optional deps through.
<farkuhar> samsep10l: I should probably mention that in the mpv README. The video backend is not hard-coded, in order to have a flexible port that will work on Wayland-only systems without pulling in a whole bunch of X11 deps.
<farkuhar> Now I seem to recall that the SDL videodriver is also an option for getting videos to display on X11 systems. Rather than creating too many dups (mpv-sdl, mpv-libxpresent, mpv-libva for example), it's preferred to have just one flexible port and let the user decide which video backend they want to use.
<samsep10l> farkuhar: that could be a good idea, I think.
<SiFuh> farkuhar: Works, I just updated core/contrib/opt/xorg to the git driver. So damned happy about that ;-)
<jaeger> samsep10l: no worries. Yeah, mingw stuff has funky versions
<cruxbot> [contrib.git/3.7]: mpv: updated README
gub has quit [Server closed connection]
gub has joined #crux
<samsep10l> jaeger: yeah. btw, I am writing Pkgfiles for another two mingw-w64 related tools: mingw-w64-widl and mingw-w64-winpthreads, which both are requried for vkd3d-proton, to play D3D12 under vulkan, would you like if I send to you the Pkgfiles when I tested both well? Also, the build order of each mingw-w64 package is important, when adding the new packages to the mix.
<samsep10l> requried = required *
<jaeger> I haven't messed with vkd3d myself but could take a look at them if you like
samsep10l has quit [Ping timeout: 255 seconds]
samsep10l has joined #crux
<samsep10l> jaeger: I usually clone the github repo and install on the wine prefix, I think it can be far from easy to create a distro package for that, since the final script just need a WINEPREFIX where override the d3d12.dll files so It can use d3d12 through vulkan, but feel free to explore if it can be integrated in crux as a port :) this is the repo: https://github.com/HansKristian-Work/vkd3d-proton
<samsep10l> it's not the same vkd3d shipped by the wine team, it is a fork which it is used by Valve's proton tool.
<samsep10l> pretty cool for that d3d12 games out there (even if I do not usually play a lot of them, but d3d12 it is the new standard nowadays)
lavaball has quit [Remote host closed the connection]
lavaball has joined #crux
<ukky> Regarding 'prtrej' tool: The question is confusing: 'Keep old' vs 'Install new'. Timestamp of file in /etc is newer than timestamp of a file from /var/lib/pkg/rejected/etc
<farkuhar> ukky: I agree; prtrej is making unwarranted assumptions in describing files as old or new. A more sophisticated tool you can use is rejmerge. But feel free to propose a patch.
groovy4shoes is now known as groovy2shoes
petrov has joined #crux
<cruxbot> [opt.git/3.7]: postfix: updated to version 3.8.2
<cruxbot> [opt.git/3.7]: alsa-utils: updated to version 1.2.10
<cruxbot> [opt.git/3.7]: alsa-ucm-conf: updated to version 1.2.10
<cruxbot> [opt.git/3.7]: alsa-lib: updated to version 1.2.10
<cruxbot> [compat-32.git/3.7]: alsa-lib-32: updated to version 1.2.10
<cruxbot> [contrib.git/3.7]: postfix-pgsql: updated to version 3.8.2
<cruxbot> [contrib.git/3.7]: open-vm-tools: updated to version 12.3.0-22234872
<cruxbot> [contrib.git/3.7]: libvirt-python: updated to version 9.7.0
<cruxbot> [contrib.git/3.7]: libvirt: updated to version 9.7.0
<cruxbot> [contrib.git/3.7]: docker-compose: updated to version 2.21.0
<cruxbot> [contrib.git/3.7]: containerd: updated to version 1.7.5
ivandi has quit [Quit: WeeChat 4.0.4]
ivandi has joined #crux
petrov has quit [Quit: Konversation terminated!]
<ukky> farkuhar: Something like this: http://ix.io/4FcS
medonja has joined #crux
<farkuhar> ukky: yours is not as dramatic as what I was imagining, but it's simple and fixes the issue at hand.
<SiFuh> Heh
<farkuhar> http://ix.io/4FcW is my first attempt at modernizing the script. It avoids spinning up two 'find' processes, and uses bash pattern deletions instead of external sed processes.
<farkuhar> It also bypasses the disk-write for capturing the user's selection. But that's a minor concern, considering how /tmp is typically mounted.
<ukky> There is one athoer issue with 'prtrej' though: It only handles root installation. That is not a real issue for me yet, there are other issues with cross-compilation to fix first.
<ukky> s/athoer/another/
<ukky> Adding SYSROOT functionality to 'prtrej' should be simple though
z3bra has quit [Server closed connection]
z3bra has joined #crux
<ukky> Does anybody run PAM-less CRUX system? Was PAM too difficult to remove?
_0bitcount has joined #crux
<remiliascarlet> I'm having the opposite problem; even though pinentry is installed, I can't use GNU Pass, because for whatever reason it thinks there's no pinentry installed.
medonja has quit []
<ukky> remiliascarlet: Never used pinentry, but it does not install any file into /etc/pam.d, thus it seems like cannot be used via PAM services
_0bitcount has quit [Quit: Leaving]
leah2 has quit [Ping timeout: 245 seconds]
samsep10l has quit [Quit: leaving]
farkuhar has left #crux [#crux]
leah2 has joined #crux
farkuhar has joined #crux
<ukky> One of the system is behind corporate firewall, so rsync does not work. Couldn't find info at crux.nu how to convert /etc/ports/core.rsync from rsync driver into httpup driver. Added ROOT_DIR and URL, now 'ports -u' works behind proxy.
<farkuhar> ukky: funny you should mention it. SiFuh just converted from the rsync driver to the git driver for all the official repos. Scroll up to see that option.
<ukky> My company does not let any IP packet out if it is not using port 80 or 443. So, I might not be able to sync ports if repo uses git driver.
<SiFuh> ukky: http://ix.io/4Fca
<SiFuh> Example. But you need to remove your old /usr/ports/contrib so git will consider it from git
<ukky> SiFuh: checking if it works...
<ukky> Should the file be named contrib.httpup?
<SiFuh> No
<SiFuh> contrib.git
<SiFuh> Move contrib.httpup to contrib.httpup.inactive
<ukky> okay, system is fresh, I need to install git then
<farkuhar> heh, just got an email with a patch to implement samsep10l's suggestion https://lists.crux.nu/pipermail/crux/2022-June/007193.html
<farkuhar> using a hard-coded file descriptor to trigger the deletion is risky, though; there's no guarantee that open( logFile.c_str(), ...) in installtransaction.cpp will not return samsep10l's hard-coded integer.
<farkuhar> I think the result that samsep10l desires---a tidier directory of build logs---is more easily delegated to an external tool (like the prtrej script that ukky and I were working on earlier). It gives me an excuse to insert another example into the prt-get man-page ...
<ukky> Unfortunately, git protocol does not work behind corporate firewall. That's okay, whatever I need is currently in core/opt/xorg. Anything from other repos I can copy-paste into local overlay, basically I just need Pkgfile and then manually update upon version bumps.
<SiFuh> So sad
<ukky> This is not a deal breaker, I can live with that.
_0bitcount has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
lavaball has quit [Remote host closed the connection]
_0bitcount has quit [Quit: Leaving]
tilman has quit [Ping timeout: 250 seconds]
tilman has joined #crux