<farkuhar>
ppetrov^: icu is an optional dependency of qt5. Did you have icu installed when building qt5?
<ppetrov^>
i have it installed, let me check if qt5 linked against it
<ppetrov^>
yes it is
<farkuhar>
as for mesa-demos, line 85 of meson.build only gets triggered if wayland is detected. Since wayland is not a hard dependency, the maintainer might not have tested that code path. It might be wiser to pass -D wayland=disabled to meson setup, rather than hacking meson.build directly.
<ppetrov^>
thanks farkuhar, now i remember i dealt with this before... Actually the whole thing about stuff linking against stuff not listed in the Depends row is beginning to bother me
<ppetrov^>
i know the best thing to do is to have a 'clean' build system, however, i do not have the time to spend on this
<ppetrov^>
i was thinking to make a copy of all ports where i sed to the Pkgfiles the full list of dependencies created when building on my system. However, I expect that i'll run into cirular dependencies, and I think i saw a discussion about that
<farkuhar>
I suggest you bring up the mesa-demos issue in #crux-devel. That at least can be dealt with immediately. The long-term problem of eager linking (exacerbated by flexible Pkgfiles) is better suited for FS#1576.
<ppetrov^>
thanks, but i am not interested to report anything there anymore. After reading that the worst of my system is expected simply because i have a gtk1 port, fuck it
<ppetrov^>
anyway, i'll follow any development about the "eager linking" :)
joacim has quit [Ping timeout: 268 seconds]
joacim has joined #crux
jjasghar has quit [Ping timeout: 255 seconds]
hunter0one has joined #crux
groovy2shoes has quit [Ping timeout: 260 seconds]
<hunter0one>
Hi all, just installed CRUX for the first time and I'm loving it :-) I'm curious though, I noticed "PKGMK_FFMPEG+=", "PKGMK_NM-=", etc. are ways to add/remove flags in the Pkgfile for certain ports. I could not find the naming convention for this variable in the pkgmk man page. For example, would tuning "consolekit" be done with a 'PKGMK_CK' variable? How do I tell?
<SiFuh>
hunter0one: You can but you don't need to touch them.
<SiFuh>
Basically the Maintainer is checking your system if some things are installed. If they are then the port will include the additional dependencies. If they are not there, then no worries, the port will skip it and build as normal.
<SiFuh>
If you install anything under # Optional: then basically the port will detect it automatically. If not, don't be too concerned.
<SiFuh>
So for example som users don't use pulseaudio. The port during build checks if you have pulseaudio. If you don't it doesn't bother with pulseaudio. If you do, then it allows ffmpeg to be compiled with pulseaudio support
<hunter0one>
I see, the main reason I'm asking is because I can't get ck-launch-session to actually launch my wm with consolekit. I got the port from opt. I couldn't find --enable-polkit in there which I thought was the culprit
<SiFuh>
What has that to do with ffmpeg?
<hunter0one>
Yeah, I saw the "prt-get isinst" before running that :-)
<SiFuh>
What WM/DE are you using?
<hunter0one>
Well, I was just using an example for ffmpeg. ffmpeg and networkmanager both have this variable in Pkgfile.
<hunter0one>
IceWM, I wrote a port for it
<SiFuh>
ck-launch-session is usually automatic with DE but for WM you need to launch t with a script
<darfo>
ppetrov^, qtwebengine/icudtl.dat is caused when icu is installed and it doesn't build the internal icu. That's why I don't like those tests that check if a port is installed and change the build options.
<SiFuh>
SO for me I use XDM as a login screen and my WM is fluxbox. So to launch ck-launch-session I add it to my ~/.xsession file.
<hunter0one>
Yeah I have ck-launch-session in .xinitrc & .xsession (I use SLiM as a display manager).
<SiFuh>
ck-launch-session startfluxbox
<SiFuh>
SLIM is pretty cool
<hunter0one>
But I also tried to copy the systemwide xinitrc by getting the scripts in /etc/X11/xinit/xinitrc.d which includes ones for dbus and consolekit but this didn't work either
<hunter0one>
I just have xinitrc and xsession aliased. SLiM for some reason uses xinitrc instead of xsession although it's not startx, lol
<SiFuh>
Yeah, just ln -s it
<hunter0one>
I'm in pure ALSA and I can't load any media in Firefox, is the firefox-bin in opt without ALSA support?
<SiFuh>
Ahhh
<ppetrov^>
thanks darfo. Does this affect qt5 applications?
<jaeger>
firefox-bin requires pulseaudio (or something that provides it like pipewire) if I remembmer right
<hunter0one>
:thumbsup:
<jaeger>
my memory and my spelling are both suspect today :P
<hunter0one>
I usually have a lot of issues with Linux audio, I had a headset that was rather good but one side completely stopped working, I think the speakers blown, so I switched to some earbuds. The problem with the earbuds is I get a really annoying echo effect LOL.
<hunter0one>
But in pulseaudio I could just unplug and replug and fix it
<hunter0one>
ALSA I know would need more tweaking, but ALSA doesn't pop as much as Pulse/Pipewire does for me
<hunter0one>
But I probably will end up using Pipewire out of convenience
<darfo>
ppetrov^, no I have icu installed and build qtwebengine with -if switch and it works fine
<darfo>
sure annoying after hours of compiling to have it fail on a footprint error
<cruxbot>
[contrib.git/3.7]: python3-rapidfuzz: initial commit, version 2.13.7
<cruxbot>
[contrib.git/3.7]: python3-jarowinkler: initial commit, version 1.2.3
<hunter0one>
SiFuh: and that "ck-launch-session startfluxbox" works for you? Consolekit runs in the background?
<SiFuh>
Yep
<SiFuh>
I also launch dbus as a SERVICE in rc.conf
<hunter0one>
Hmm, that might be my issue
<hunter0one>
Brb
hunter0one has quit [Quit: Leaving]
groovy2shoes has joined #crux
hunter0one has joined #crux
<hunter0one>
Pipewire didnt have xdg-desktop-portal as a dependency, but pipewire won't launch because rtkit complains about it
hunter0one has quit [Quit: Leaving]
ivandi has quit [Quit: WeeChat 3.8]
ivandi has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
hunter0one has joined #crux
<hunter0one>
back
<SiFuh>
front
<hunter0one>
lol
<hunter0one>
Using the dbus service fixed ck-launch-session not working, i've also gotten pipewire to work that way too :-)
<SiFuh>
So it is party time?
<hunter0one>
Indeed, the only thing I need to do now is figure out how to make pipewire not sound like I'm in a tunnel. The amount of options there are it could be anything..
<ukky>
hunter0one: compare sound quality in Pipewire vs ALSA. If you cannot make quality playback with ALSA, I doubt that Pipewire or PulseAudio would help
<hunter0one>
You're right, all the way down to ALSA I have issues. Interestingly, OSSv4 worked wonders when I still used FreeBSD. I wish it still worked on Linux. This "tunnel" effect has only started since I swapped to earbuds though which makes me think its something with echo cancellation and/or sources
hunter0one has quit [Quit: Leaving]
<ukky>
How do you prefer to set your PKGMK_*? PKGMK_SOURCE_DIR="/var/cache/crux/pkgsrc", or PKGMK_SOURCE_DIR="$PWD"? Yes, it is up to user's preferences. I've got used to shared directories. What is the advantage of using SRC, PACKAGE and WORK, under port directory?
<ppetrov^>
i have a common folder where I store all sources, ukky
<ppetrov^>
a dedicated folder for src and another for pkg
<ukky>
ppetrov^: that is what I do too. And for WORK a shared dir too, with port name as subdir.
<ppetrov^>
i have this: PKGMK_WORK_DIR="/media/data0/prt/build/$name-$version"
<ukky>
but if you want to test some package, it is better to use $PWD, right?
<ppetrov^>
data0 is a separate hdd
<ppetrov^>
i test build everything there... ah and it is mounted in RAM
<ppetrov^>
there's a totorial in the wiki about speeding up build times
<ukky>
My PKGMK_WORK_DIR="/var/cache/crux/pkgbuild/$name"
<ppetrov^>
yep, makes perfect sense
<ukky>
I will add '-$version', it will be more clear if build fails and work directory remains.
<ukky>
ppetrov^: Building in RAM may not speed up build process. When I tested Chromium build with and without RAM work directory, one test was built in 6h51m36s, and the other in 6h50m36s
<ppetrov^>
well, i don't know then... been doing this since the spinning disk times
<ukky>
I do not see advantages of using ramfs as work dirs for building, unless you have 1TiB of RAM