<cruxbot>
[opt/3.7]: bash-completion: updated to version 2.15.0
<cruxbot>
[contrib/3.7]: gtksourceview: updated to version 5.14.2
<cruxbot>
[contrib/3.7]: dunst: updated to version 1.12.0
<cruxbot>
[contrib/3.7]: docker-compose: updated to version 2.31.0
<cruxbot>
[contrib/3.7]: docker-buildx: updated to version 0.19.1
rever_4192 has joined #crux
tilman has quit [Ping timeout: 252 seconds]
tilman has joined #crux
zorz has joined #crux
jue has quit [Remote host closed the connection]
uwumeowmeownyaa has joined #crux
<r0ni>
whats the correct order to make llvm,clang,etc so cmake don't ask me for the prior version when building select things? it never works out on my system like I'd expect it
<cruxbridge>
<tim> What problem are you having exactly?
<r0ni>
qt6-tools wants llvm 19.1.3 yet i've got 19.1.4 installed.. feel like every time llvm, etc upgrades this happens
<r0ni>
there a magic rebuild i need to do every time?
<remiliascarlet>
Clang goes before LLVM.
<remiliascarlet>
Fuck, no.
<remiliascarlet>
LLVM goes before Clang.
<r0ni>
llvm > compiler-rt > clang ... but why when updating the system every time it shits the bed
<SiFuh_>
r0ni: Well it shouldn't be sleeping
<r0ni>
SiFuh i don't sleep myself, nothing here sleeps
<SiFuh_>
The way it should be!
<r0ni>
;)
<remiliascarlet>
That's because LLVM is a massive clusterfuck.
<r0ni>
i just pkgrm all of them and i'll rebuild llvm first and go from there
<cruxbridge>
<tim> r0ni: it actually fails the build for qt6-tools?
<r0ni>
tim: yes
<cruxbridge>
<tim> you got a log for that?
<r0ni>
i can make one
<cruxbridge>
<tim> please, I never had that problem so I really can't tell whats happening there
<cruxbridge>
<tim> maybe. you don't seem to override CC anywhere else
<cruxbridge>
<tim> do you have opt/clang-ccache-bindings installed?
<r0ni>
yes
zorz has quit [Quit: leaving]
lavaball has joined #crux
<cruxbridge>
<tim> you could try to compile with -DFEATURE_clangcpp=OFF
<cruxbridge>
<tim> or -DFEATURE_clang=OFF, not sure
<cruxbridge>
<jloc0> Rebuilding clang right now, I’ll try that after.
<cruxbridge>
<jloc0> Cleared my ccache too just in case
<cruxbridge>
<tim> looks like you might give it a try with llvm 19.1.5 later/tomorrow anway ;)
<r0ni>
FML lol
<r0ni>
i feel maybe the arm64 ports get updated out of order or something... it happens every single time
<cruxbridge>
<tim> I mean yeah, they are. But its not too far apart. And that would maybe make sense: there is an llvm and compiler-rt overlay that get updated later than the official x86_64 repo. if you now already built clang against the prior systems version before updating llvm and compiler-rt I can imagine how that could lead to problems
<cruxbridge>
<tim> I always forget that all the things you do/report probably happen on your M1, right? :P
<r0ni>
yes, apologies lol my intel machine is humming along just fine
<cruxbridge>
<tim> That makes a lot of sense now
<r0ni>
I feel like i need to track both port repos but also use my own 3rd repo of ports to manage it all properly
<cruxbridge>
<tim> or lock clang et al. and update them when all things are in order?
<cruxbridge>
<tim> maybe there should be a check for that to exit the build early in the x86_64 repo
<r0ni>
I need to do some PRs there packages been skipped for a while now keeping things out of sync
<cruxbridge>
<tim> I had a few failures on my rpi4 deployment as well but never had enough time to dig into what kept failing there
<r0ni>
lots of footprint mismatchs in this qt6 update on arm64 too... i need to diff them and see what it is
<cruxbridge>
<tim> qt6 has something new that foobars my desktop builds footprint as well. Need to trace that one too
<cruxbridge>
<tim> it would be great to have a better solutions about footprints..
<cruxbridge>
<tim> it would suffice if the message about mismatches would be informational but not fail the build
<r0ni>
what about removing anything with an arch listed from the footprint and treating them like NEW files?
<r0ni>
fixes it although not quite a best-case solution
_moth_ has quit [Ping timeout: 255 seconds]
<r0ni>
tho with default settings it'd still fail footprint mismatching
<cruxbridge>
<tim> https://git.crux.nu/tools/pkgutils/pulls/2 I tried it like that but it altered more lines than it should have needed O:) But I didn't spend a lot of time with it either
<r0ni>
rebuilding clang fixed it qt6-tools builds now
<r0ni>
i put up a "for dev only" xfce 4.20pre2 diff repo to work against my 4.18 repo https://lngn.net/crux/xfce4d/ if anyone wants to try and get wayland things working on xfce ;)
<cruxbridge>
<tim> that i haven't tried yet either
<cruxbridge>
<tim> i still want to
<r0ni>
ports like pokemon... gotta build em all!
<cruxbridge>
<tim> lol
<r0ni>
the secet to the repo is depinst 'libxfce4windowing' and then build/update the rest should be golden (if anyone feels adventerous)
<farkuhar>
r0ni: In FS#1576, therealfun dismissed the idea of enabling PKGMK_IGNORE_NEW by default, claiming that it would "reduce the utility of the .footprint file." One of the replies to FS#1576 suggested that keeping PKGMK_IGNORE_MISSING disabled would preserve enough of the utility of footprints, except in odd cases like darfo's clean-container build of qt6-webengine.
<farkuhar>
therealfun was inspired to write a "flexible footprint filter" because of the different footprints that emerge when some soft dependency is found during configure. But his solution might be a good starting point for accommodating different kernel versions or CPU architectures.