<ukky>
SiFuh: jaeger: I'd like to ask you to add these kernel modules: CONFIG_BROADCOM_PHY and CONFIG_BCM_NET_PHYLIB. My CONFIG_TIGON3 is not detected without those.
<SiFuh>
ukky: I have them all configured as modules
<ukky>
Well, kernel that comes with 3.7 ISO does not have them. It has only CONFIG_TIGON3 defined. And whithout PHY drivers tg3 driver fails to load.
<SiFuh>
You talking about the ISO boot kernel?
<ukky>
Yes
<SiFuh>
Ahh, then that will be through jaeger
<ukky>
Okay
<ukky>
jaeger: This line caps number of jobs to 4 when building qtwebengine: export NINJAFLAGS="${NINJAFLAGS} -j4"
<jaeger>
It did not on my threadripper system. Still used 32 cores
<jaeger>
Which was itself somewhat interesting because it used 32, not 34
<jaeger>
I'll give it one more try, maybe I fat-fingered it or something
<jaeger>
interesting, it does say 34 on that host:
<jaeger>
$ ninja --help 2>&1 | grep parallel -j N run N jobs in parallel (0 means infinity) [default=34 on this system]
<jaeger>
Another bit of data, nodejs seems to call ninja with -j32 so maybe it's respecting JOBS there?
<jaeger>
OK, yeah, at least nodejs respects JOBS
CrashTestDummy3 has joined #crux
CrashTestDummy has quit [Ping timeout: 246 seconds]
CrashTestDummy2 has joined #crux
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
CrashTestDummy3 has joined #crux
CrashTestDummy has joined #crux
CrashTestDummy2 has quit [Ping timeout: 272 seconds]
CrashTestDummy3 has quit [Ping timeout: 252 seconds]
CrashTestDummy2 has joined #crux
CrashTestDummy has quit [Ping timeout: 252 seconds]
CrashTestDummy3 has joined #crux
CrashTestDummy has joined #crux
CrashTestDummy2 has quit [Ping timeout: 272 seconds]
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
CrashTestDummy2 has joined #crux
CrashTestDummy3 has joined #crux
CrashTestDummy has quit [Ping timeout: 246 seconds]
CrashTestDummy has joined #crux
CrashTestDummy2 has quit [Ping timeout: 246 seconds]
CrashTestDummy2 has joined #crux
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
CrashTestDummy has quit [Ping timeout: 246 seconds]
CrashTestDummy has joined #crux
CrashTestDummy2 has quit [Ping timeout: 240 seconds]
CrashTestDummy2 has joined #crux
CrashTestDummy has quit [Ping timeout: 264 seconds]
CrashTestDummy3 has joined #crux
CrashTestDummy2 has quit [Ping timeout: 264 seconds]
CrashTestDummy3 has quit [Remote host closed the connection]
CrashTestDummy3 has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
CrashTestDummy3 has quit [Remote host closed the connection]
CrashTestDummy has joined #crux
CrashTestDummy has quit [Read error: Connection reset by peer]
CrashTestDummy has joined #crux
CrashTestDummy2 has joined #crux
CrashTestDummy3 has joined #crux
CrashTestDummy has quit [Ping timeout: 255 seconds]
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
CrashTestDummy2 has joined #crux
SiFuh has quit [Remote host closed the connection]
CrashTestDummy has joined #crux
SiFuh has joined #crux
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
CrashTestDummy3 has joined #crux
CrashTestDummy2 has quit [Ping timeout: 260 seconds]
CrashTestDummy has quit [Ping timeout: 268 seconds]
CrashTestDummy has joined #crux
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
CrashTestDummy2 has joined #crux
CrashTestDummy has quit [Ping timeout: 268 seconds]
CrashTestDummy2 has quit [Ping timeout: 256 seconds]
ppetrov^ has joined #crux
_moth_ has quit [Ping timeout: 264 seconds]
lavaball has joined #crux
<ppetrov^>
jaeger, building qt6-webengine, 8 cores [2041/30352] at the moment, ~10 GB. Will let you know how much up it goes
<ppetrov^>
in the beginning, it said that this is not used by the project: QT_FEATURE_webengine_system_liblcms2
CrashTestDummy has joined #crux
CrashTestDummy2 has joined #crux
CrashTestDummy has quit [Ping timeout: 256 seconds]
CrashTestDummy3 has joined #crux
CrashTestDummy2 has quit [Ping timeout: 264 seconds]
CrashTestDummy3 has quit [Ping timeout: 256 seconds]
<ppetrov^>
[11117/30352]: stays around 12G
CrashTestDummy has joined #crux
<r0ni>
just a fyi I had been able to build qt6-webengine AFTER fixing all the lto gcc builds on my machine. Previous failures were random but I did manage to build the port as-is the other day. Prior I was looking into patches other distros were shipping, in the end, none of that made a difference
<ppetrov^>
would the CPU itself (not number of threads) also matter about the RAM consumption?
<r0ni>
maybe? tbh i'm using a pretty limited VM with 4cores/5threads/12gbram/8gb swap/zram and that manages just fine
<ppetrov^>
how did you manage to get 5 threads out of 4 cores?
CrashTestDummy has quit [Ping timeout: 252 seconds]
<ppetrov^>
well, if i understood correctly, jaeger was concerned that the more cores you use, the more RAM is consumed (naturally). So, 4 cores should not eat that much ram
<r0ni>
oop sry typo 4 threads
<ppetrov^>
:P
<ppetrov^>
oho... [16308/30352]: 16G
<r0ni>
it eats 16-20gb ram at some points... the zram was very helpful. when i didn't have zram before, it always failed
<ppetrov^>
[18347/30352]: 20G
<SiFuh>
ppetrov^: Almost done that kernel by the way.
<ppetrov^>
great! without that, I won't be able to use CRUX :)
<SiFuh>
Liar. HAHAH
<ppetrov^>
well, I can't configure a kernel by myself and I am really not interested to learn _that_
<SiFuh>
ppetrov^: Wouldn't blame you for that.
<SiFuh>
Thought it was difficult back in the 2.x.x days. But man it is ridiculous now
lavaball has quit [Remote host closed the connection]
<ppetrov^>
[23534/30352]: 25G
<ppetrov^>
SiFuh, back in the 2.6.* days I would add a few modules into the kernel, but never configured one from scratch
<SiFuh>
ppetrov^: It was easy but at the same time difficult because compilation would often fail. However, it was kind of small so it wasn't much a of a problem. But as a side not, hardware wasn't like it is today so it still took a bit of time.
<SiFuh>
Today compilation is insanely easy and very clean. But configuration is now a problem because so many options availble
<ppetrov^>
yep. I just don't have the hardware knowledge and don't think I have the mental strength for the configuration. Compile time does not bother me, my i7-9700 still holds well
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
<ppetrov^>
ok, build complete. On 8 cores/threads RAM never went over 30G
lavaball has joined #crux
<ukky>
jaeger: Strange indeed. On my system ninja displays `$(nproc)+2` as the default. But when qtwebengine builds, ninja uses my JOBS or MAKEFLAGS, which both are defined in pkgmk.conf.
<cruxbot>
[opt/3.7]: mupdf: updated to version 1.24.5
<cruxbot>
[opt/3.7]: krb5: updated to version 1.21.3
<ppetrov^>
so, python2 will be gone from 3.8. Will the python3 stuff stay as "python3" or simply "python"?
lavaball has quit [Remote host closed the connection]
<ukky>
jaeger: Does your threadripper system set JOBS=32 in pkgmk.conf when building qtwebengine?
<jaeger>
30G for 8 threads matches what I've seen. I can build it on both the 32t and 16t systems if I only use 8t, they both have 32G RAM
<jaeger>
ukky: yes. I'm testing it again today
<ukky>
jaeger: Then qtwebengine/Pkgfile will set number of jobs in NINJAFLAGS to the value of JOBS, minus one, at line 73 of qtwebengine/Pkgfile.
<jaeger>
Noted. I'm using qt6-webengine for these tests, though
<ukky>
That might be the difference. qtwebengine is built via qmake-qt5, but qt6-webengine is built using cmake.
<ppetrov^>
jaeger, at work we have an old workstation with total of 48 threads and 512 GB of RAM (DDR3). I can build there if you like :P
<jaeger>
Testing more with qt6-webengine today. If I export NINJAFLAGS in the qt6-webengine Pkgfile it does seem to use that, no idea why I couldn't get it to yesterday. I was annoyed and tired so maybe I did something stupid. But it does NOT care about JOBS from pkgmk.conf, it seems.
<jaeger>
So maybe the answer is just to add a NINJAFLAGS setting derived from JOBS in the same way that opt/qtwebengine does it.
<jaeger>
Though I would still need to lower it WAY down for systems with lots of cores/threads.
<ppetrov^>
jaeger, or just write a README to warn users about it and that's it?
<cruxbridge>
<tim> jaeger: if that works I can add that, for sure
<jaeger>
Well, please test it if you're so inclined because I'm not sure I can trust anything I see or say :P
<cruxbridge>
<tim> xD
<ukky>
We have multiple options here. Maybe the easiest would be adding to pkgmk.conf: [ "$name" = "qt6-webengine" ] && export NINJAFLAGS="${NINJAFLAGS} -j${WHATEVER}"
<ppetrov^>
if there are other ports that are so RAM hungry at build time, maybe make a list which can be sourced by pkgmk.conf? Adding this line to pkgmk.conf just for one package seems too much. or maybe I'm wrong :)
<cruxbridge>
<tim> i copied the line from qtwebengine to qt6-webengine, set it to 6 jobs and it seems to work for me, so in general this seems like a working knob here
<jaeger>
I'm not a fan of adding to pkgmk.conf for a single port that many people wouldn't even install
<ppetrov^>
we have prt-get.aliases, why not pkgmk.threads, and list there ports and the number of cores to use
<cruxbridge>
<tim> ppetrov^: i agree, I also dislike that users would need to add that themselves or anything if we don't add it for everybody, and not everybody uses it
<cruxbridge>
<tim> I would prefer to fix it via login the Pkgfile tbh
<cruxbridge>
<tim> logic*
<jaeger>
For now I'd vote for Pkgfile logic but something like pkgmk.threads or pkgmk.vars would be worth at least exploring in the future
<jaeger>
pkgmk.hacks :P
<serpente>
agreed to not adding to pkgmk, README seens the best, but maybe you can add NINJAFLAGS to the Pkgfile
<cruxbridge>
<tim> imho, it's only chromium and whateverelse internally packages chromium, like webengine
<ukky>
the user should be able to override Pkgfile' logic in selecting number of jobs
<cruxbridge>
<tim> and thats what the qtwebengine Pkgfile currently does
<ppetrov^>
jaeger, the shorter the name the better. ehh,.. still should be dexcriptive though
<cruxbridge>
<tim> pkgmk.hax then
<jaeger>
Please do not consider pkgmk.hacks a serious suggestion :D
<ppetrov^>
pkgmk.vars would imply users set also other stuff for the ports listed there. pkgmk.{cores,threads} tell explicitly what the conf file does
<cruxbridge>
<tim> anyway, i stopped the build. anybody that has the problem can tell me if the line from qtwebengine fixes it for them too, or I can just push it now and you can report how that works, I am fine with either
<jaeger>
The comment is technically incorrect but close. Default is $(nproc)+2
<cruxbridge>
<tim> I can change that too, no idea when/where/.. I picked that up
<jaeger>
With that said, this would make the qt6-webengine build adhere to JOBS/NINJAFLAGS but for those of us without 3-4G RAM per thread we'll still have to adjust it to build that single port. I'm not sure what the best solution would be but at least that change gets it closer.
<jaeger>
'ninja --help' shows the default (and value for the system on which it is invoked) for reference
<cruxbridge>
<tim> I mean, there could be a function that calculates the job count based on limits that we can define
<ukky>
that function should be used only when user does not define JOBS
<ppetrov^>
jaeger, a bit of an unorthodox idea but... is it possible to breakdown qt6-webengine to subsets of smaller packages?
<ppetrov^>
of course this will introduce additional dependencies, something that nobody really wants
<ppetrov^>
but at least will make the build process faster if someone doe snot need everything from qt6-webengine
<cruxbridge>
<tim> ppetrov^: I am the packager :) and I don't think it is possible, no. You disable/enable features, thats what I already do while trying not to cripple the port
lavaball has joined #crux
<cruxbridge>
<tim> I mean, technically everything is possible. I am sure you can hack the project and generate cmakefiles that will do what you imagine there, but yeah..
<ppetrov^>
cruxbridge, tim: I managed to build just a subset of pdf related stuff, to satisfy a port of mine (ucsf-chimerax), but ye: better have one big package with everything that's needed
ppetrov^ has quit [Quit: Leaving]
ppetrov^ has joined #crux
<cruxbridge>
<tim> interesting. you got a Pkgfile? Just for my curiosity
<ppetrov^>
i used as a starting point qt6-webengine's port if i remember correctly
<SiFuh>
jaeger: I can release it today, I want to check it more but I think it is done.
<jaeger>
Up to you, no rush. I just started test builds yesterday so there's plenty of time.
<jaeger>
When you're happy with it (even if that's now) send me the link and I'll add it to the test builds
<SiFuh>
jaeger: Awesome. Just let me do the primping and preening and all should be fine. I think it is done anway.
<SiFuh>
anyway*
<jaeger>
ok
<SiFuh>
I will send before tonight, because I go jungle again for a few days
<SiFuh>
jaeger: Amazingly good timing by the way. I just had some beer bottling to do and some dog related stuff. I was able to begin it before anything
<jaeger>
great :)
<SiFuh>
My words exactly Haha without the smiley face
<SiFuh>
There was a hmmph in front though
<jaeger>
heh, noted
<SiFuh>
You will get it before Saturday Asian time.
<SiFuh>
Unless ppetrov^ wants to test it ;-) first
<ppetrov^>
i used your config for 5.* with make oldconfig for 6.5.*
<ppetrov^>
worked fine
<SiFuh>
ppetrov^: I send you the link if you want to test
<ppetrov^>
newest LTS for the 6.6 series is 6.6.36
<ppetrov^>
:P
<SiFuh>
Blame jaeger
<SiFuh>
He told me 35
<jaeger>
yesterday it was .35 :P
<ppetrov^>
I am 99.9% it is the one. <- if the computer explodes, i'll let you know
<SiFuh>
ppetrov^: How? Telepathy?
<ppetrov^>
i have another
<SiFuh>
jaeger: So we are moving to 6.6.36 now?
<ppetrov^>
SiFuh, they will change it meanwhile to 37
<jaeger>
I'm building the first test ISO with .35. If you want to go with .36, that's fine. I imagine they will be very similar
<ppetrov^>
it's like a neverending adventure, the kernel thing
<SiFuh>
I hate this new versioning scheme
<SiFuh>
jaeger: I will do a .36 or .37 or whatever on Monday Asian time.
<jaeger>
ok
<SiFuh>
They seem to change a word from misspelled to mispelled and BOOM kernel update
<SiFuh>
They seem to have gone full nucking futs. All good. It will be done.
tilman has quit [Ping timeout: 256 seconds]
tilman has joined #crux
<stratofall>
Any chance someone can link me to a openjdk17-jdk precompiled package? Seems the java mirror might be down in the Pkgfile. Seems jdk8 is to old, and jdk20 is to new for the 1.21 minecraft server. Both of those java installs work. Just not 17.
<cruxbridge>
<tim> oops, yeah, my server is down for maintenance currently, and I'm taking my time with it too
<stratofall>
Its all good. I was gonna get it done somehow. Just figured a pre-made package would be quickest if possible. Before toiling in the Pkgfile.
<cruxbridge>
<tim> no worries, I'm on my way to fix it
<stratofall>
Thank you :) My stepson very much appreciates it.
<stratofall>
Its, all good. I appreciate all of the few that maintain this distro.
<stratofall>
Always seems like I have 5min here or there. Jump in, grab the updates. Move on... Been trying to move all the machines to Crux lately. And docker has come in handy a few times already too.
<crash_>
yeah i have been moving my machines as well to crux, even the slowest ones.. they take a while to upgrade but it's worthit in the end
plan908 has joined #crux
farkuhar has joined #crux
ppetrov^ has quit [Quit: Leaving]
lavaball has quit [Remote host closed the connection]