07:04 <beerman> thanks. i'll leave that part of investigation happily to somebody else

12:01 <farkuhar> qt5 and qt6-base are flexible enough to accommodate the case, libxkbcommon being built without xkeyboard-config. Other ports might degrade less gracefully (failing to start at all!), and will need to list xkeyboard-config as a hard dependency. But unless we give prt-get the logic to deal with soft dependencies (and set "softdeps yes" as a new default?), there's no guarantee that xkeyboard-config will be installed before libxkbcommon.

12:03 <beerman> yeah

12:03 <beerman> softdeps yes as a default is a hard no from me but yeah

12:03 <farkuhar> in this case it might not matter much, the order in which the two ports are built, as long as the files provided by xkeyboard-config are present at runtime.

12:07 <farkuhar> I'm thinking of wayland compositors that select the keyboard map using data in /usr/share/X11/xkb, which is no longer guaranteed to be populated if libxkbcommon is an end leaf in the dependency tree.

12:43 <beerman> it really isn't an end leaf if i understand correctly. i3, foot, firefox, alacritty, gtk4, qt* depend on it. xkeyboard-config is the problematic companion here, imo

13:28 <farkuhar> yeah, bad wording on my part. We definitely need to figure out where xkeyboard-config belongs, relative to all the ports that could previously rely on getting it through libxkbcommon.

13:34 <beerman> yeah

16:30 <beerman> jaeger https://dpaste.org/14OAv heh, this might interest you

16:31 <beerman> i also plan on adding a patch for fmt 10 for kodi and spdlog

16:31 <beerman> heads up that contrib/kodi will need that as well as a rebuild afterwards

16:34 <beerman> having xkeyboard-config installed is enough, no need to recompile libxkbcommon, but it needs to get started after xkeyboard-config is installed

18:05 <jaeger> So basically I need to add xkeyboard-config as a dep and add that fmt 10 patch?

18:08 <beerman> jaeger yeah

18:10 <jaeger> OK, thanks. Will look at that today

19:10 <jaeger> bleh... still can't build qtwebengine without disabling a bunch of cores

19:13 <ukky> qtwebengine is hard on CPU cores. How much RAM do you have per CPU thread?

19:16 <beerman> what is a bunch of cores? How many are you throwing at it?

19:36 <jaeger> That particular system has 16 threads and 16GB RAM, which always results in a failure. Disabling 8 cores it works.

19:36 <jaeger> s/cores/threads/

19:37 <jaeger> It's possible that some number fewer than 8 would also work, I haven't tested specifics.

19:41 <beerman> mh, weird

19:41 <beerman> i think there are switches to limit how many threads it links with

19:42 <beerman> is it possibly crashing while its linking those jumbo libs by any chance?

19:42 <ukky> That system config explains it.

19:43 <ukky> Gentoo _requires_ ratio 2GiB per 1 job (for gcc). And requires 1.5 GiB per job when using clang compiler.

19:44 <ukky> Similar ratio is required to compile Chromium.

19:53 <jaeger> In theory there are switches but in practice they don't seem to actually work... Though to be fair it's been a LONG time since I last tested them. Perhaps that's been fixed by now.

19:55 <beerman> qt6 is better in that regard as in its using cmake.. it makes configuring it a bit easier