<pitillo>
jaeger: amazing!!! thank you very much!!! keep them for a while... just in case I break something on core-arm64
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ crux-ports-core-arm64 ] kbd: update to 2.6.3
crux-arm-bot has left #crux-arm [#crux-arm]
<beerman>
pitillo imo, with the script in mind that i posted, the gcc update can be pulled in
<beerman>
with that its easy to identify the core ports that need a bump for its release number so a rebuild is triggered afterwards
<pitillo>
beerman: I have it in the queue, but as it's the one which will take more time, I thought to bump it the last one
<beerman>
alright, yeah, makes sense
<beerman>
sure takes a while :)
<pitillo>
it shouldn't break anything, just binaries will be built with the older gcc version
<beerman>
true, but these lto'd libs may cause weird build failures that you can't easily trace back to where it stems from
<beerman>
i tested this script on an older build container I had flying around which had the described problem. when i updated e.g. gtk3 i had to turn of lto for gtk3 itself as it failed linking. I never really found out why. with the script I was able to fix the container
<pitillo>
interesting behavior
<pitillo>
revdep won't show that problem as those binaries will be "hidden"... not sure how to manage it to advertise anyone to use the script just to do a full rebuild after gcc bump
<pitillo>
we have jaeger_'s packages just in case anyone has a problem to rollback but that should be the last resource
<beerman>
well, the script called with -l will just list the ports to be rebuilt
<pitillo>
I'm powering on my desktop just to make a test with the script and check if I can solve my issues with chrome
<beerman>
if you check that in a container with only core installed, you can make out which ports to rebuild to have it all fit together
<beerman>
chrome? but chrome is prebuilt etc? Are you building chromium still? I have a port for ungoogled-chromium that I keep in my overlay though, can't be arsed to maintain that beast
<pitillo>
yeah, sorry, I meant chromium... I've being using it since long time ago but one if its deps was broken and no way to fix it
<pitillo>
it's a crazy port... I remember sepen fighting with it years ago
<beerman>
haha
<beerman>
my Pkgfile is 358 lines long
<beerman>
that shit is crazy and it breaks with system libs so often
<pitillo>
pfffff
<pitillo>
just checking the number of lines that Pkgfile scares...
<beerman>
glad i got that ryzen 5800x which makes it... well... easier :D instead of ~24h per built it now takes an initial 7 or so?
<pitillo>
7h on current computers is crazy....
<beerman>
i am glad other people on other distros seem to be able to keep up with it so i am just here playing the pure copycat that i am
<beerman>
yeah thats with lto and everything
<beerman>
native wayland backend, pipewire etc :D
<beerman>
its working well
<pitillo>
other distros have a big team backwards... CRUX is small and the team behind always do an amazing job
<beerman>
if i hadn't god knows how many ports in contrib already i might have imported it
<beerman>
i never dared to build it on aarch64 xD
<pitillo>
I've seen it... you took a lot of ports just to don't drop them
<pitillo>
ummm if I'm right, I had built it many times on ARM.... I was using it on the chromebook
<beerman>
i adopted most ports that i depend on myself with whatever, i took a few out of sentimental habbits which i wanted to avoid but there is nobody keeping them alive otherwise..
<beerman>
e.g. scummvm
<pitillo>
I used the odroid for the first build and rebuilt on the chromebook to use it... it took more than 48h
<beerman>
hoho, 48h :D but not too bad on that small hardware
<beerman>
after all, i am not using crux because installing packages is so fun and easy and not time consuming at all
<pitillo>
yeah... if they are dropped, they are missed and with them, all the work the maintainer did for them, a real pity
<beerman>
the work is not gone, its just stashed in the git history
<pitillo>
yeah, not bad 48h but think that they were old versions... it was a beast but now I believe it's worse (it grow a log since then)
<pitillo>
yeah, your are right... "hidden"
<beerman>
i am of the side of the fence where i would have a graveyard repository that is discouraged to be used in a productive system, but would import all the dropped ports
<beerman>
but jue is against it and we never implemented one
<pitillo>
but probably someone who wants a "dropped" ports will start from fresh instead of checking git history
<beerman>
truth be told, starting from scratch is not a bad thing always
<pitillo>
that doesn't sound bad IMHO... but a question related to it is who is the responsible of that repo
<pitillo>
not a bad thing... but may be you can hit your head with a wall which a maintainer hit before xD
<beerman>
back in the day, a few years back, romster ran this script that would rebuild all ports in core opt contrib xorg one after another, and when a build failed, the script would upload the log to some website
<beerman>
i worked so hard to erase all problems with these ports, it was a never ending story for months
<beerman>
there was so much crud in some of these Pkgfiles
<beerman>
a thousand cooks means there is also a thousand tastes in your soup
<pitillo>
I remember that history... you were very active at crux channels in that time
<pitillo>
true
<beerman>
at least core, opt, xorg should aim to be a one flavour
<beerman>
imo
<pitillo>
yes, that is the CRUX base... those repos are the official ones
<beerman>
i reworked quite a bit of syntax in core for 3.7
<pitillo>
all must go in the same direction (from a maintenance pov)
<beerman>
you know what drives me mad? when there is spaces AND tabs in the same file
<beerman>
this has been all over the place
<beerman>
:D
<pitillo>
I know that feeling... xD
<pitillo>
this is why we removed the 4 spaces tabs and cut them to 2 spaces tabs in crux-arm
<pitillo>
we saw a lot of Pkgfile which at that time had spaces instead of tabs...
<pitillo>
working with them to keep "aligned" at format level was a pain, so we started formatting from scratch
<pitillo>
the worse part... comparing Pkgfiles from CRUX to CRUX-ARM
<pitillo>
we didn't took that part in mind and probably it was an error
<pitillo>
fuck... my NAS power adaptor is doing strange things
<beerman>
i only format with %s/<tab>/ /g
<beerman>
its just my preference, i changed that in 3.8 too after i found out that, iirc, both jue and jaeger, prefer spaces? but that can be changed easily
<pitillo>
that will depend on your tab space configuration...
<beerman>
with expandtab in vim you can do ^V<TAB> and print a tab
<r0ni>
rebuilding arm changes to see if things work this time around... seems to be going good so far
<pitillo>
I'm ready to break all soon... libarchive on the way... and next one openssl which shouldn't break anything... but it smells for me that it will do xD
<beerman>
it won't, don't worry :D
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ crux-ports-core-arm64 ] libarchive: removed overlay. Important: remember to revdep and rebuild dependent ports
crux-arm-bot has left #crux-arm [#crux-arm]
<beerman>
libarchive broke cmake! how dare you!
<r0ni>
i keep getting llvm not found but it's installed, mesa fails to build, and i keep running out of space building rust
<r0ni>
apparetnyl 9 gb isn't enough
<beerman>
r0ni llvm not found for mesa?
<beerman>
mesa might need a fix for llvm 17 which got updated yesterday, i am not that far in yet. see the commit in x86_64 repos
<r0ni>
yeah, but it's looking for a header file and it dies... i'll check if i have logs on this one
<beerman>
pitillo ^ something to keep in mind, i can create a pr for that for aarch64 if it helps
<beerman>
rust already got the fix it needed for llvm 17
<r0ni>
i'm building rust now after cleaning up some more space
<beerman>
no idea how much space it took while building, but it might take a while for sure
<beerman>
took the pi 4 around 6 hours
<r0ni>
oh it only takes a little bit on m1
<r0ni>
maybe 20 mins or so
<beerman>
thats neat :D
<r0ni>
tonight i'll see about installing natively... this is vm performance
<r0ni>
i really don't want to install fedora so i may just use nbd and wipe my install and just do it with a rootfs
<r0ni>
the boot process is a pita to get right, so i shouldn't mess up what i've got working
<r0ni>
wiped ccache, thats bout the only space i got unless i expand the drive (which prob would have taken less time and effort)
<beerman>
yep :D
<r0ni>
rust take 3... fire!
<r0ni>
theres a deep cut hollywood joke in there
<beerman>
ba dum tss :D
<r0ni>
i am interested in if it will complete, i had been trying to build 1.72 for a while unsuccessfully on my unofficial updated ports vm and it always failed
<beerman>
there isn't too many factors i am aware of in general to make rust fail
<beerman>
llvm is the biggest one, if your version is incompatible, it will fail. if you have e.g. rust 1.70.0 installed and try to install 1.72.0, it might fail as well
<r0ni>
i never had an issue before which i thought odd, only 1.71 and newer
<beerman>
1.71.0 reintroduced an odd behaviour where it was unable to get built with itself or something like that
<beerman>
might also be a problem you saw, i imported a patch for that in opt/rust but I neglected opt-arm64/rust
<r0ni>
ya see i had just taken x86 scripts and edited them
<r0ni>
changed to aarch64 etc and went with it
<beerman>
Oo ok
<r0ni>
i wanted to see how far things can go without the -arm specific ports
<r0ni>
cuz most issues seem to be footprint and/or build aarch64 things
<r0ni>
that system still works nicely tho, cept for rust up-to-date anyway
<beerman>
yeah why not
<beerman>
i am here trying to enhance the official opt/rust port to allow building e.g. wasi targets
<beerman>
i added a check to sed cc, cxx, ar, ranlib directives in the config.toml to use either gcc or llvm/clang
<beerman>
i have a rust-wasm port to test this out with
<r0ni>
the wasi stuff was failing for me, thats when i looked at revdep and saw rust there
<beerman>
i want to compile zjstatus for zellij, thats the final goal
<beerman>
you had that working already or were you trying to get it to work?
<r0ni>
.... and I didn't need to know zellij existed, now i'm doomed
<beerman>
lmao
<r0ni>
no, i meant the wasi-compiler-rt port
<beerman>
have you ever got talked into our lord and savior neovim yet?
<r0ni>
haha nope, i've used the newb friendly mcedit for decades and never looked further
<beerman>
if you ever feel like dooming your self once more.. i won't say more ;)
<r0ni>
i mean i've used vim, but not so sure on neovim
<beerman>
neovim supports different config directories so you can try either at will
<beerman>
they added that since these config distributions are getting more and more popular
<beerman>
https://www.lazyvim.org/ there is also this one which I guess is much lighter, plugin wise
<r0ni>
won't be long till the ol lady leaves me, "all you care about is text-mode!" i can hear her screaming
<beerman>
heh, i am about to pulled away from the keyboard as well
<r0ni>
heh cheers, you've given me some new toys to play with lol
<beerman>
the pi4 lxc host is still updating, this takes much longer. including clang and all the fun stuff
<beerman>
sure, no worries. remember, these toys are an depinst away from you ;)
<r0ni>
rust finished!
<beerman>
woop woop
<r0ni>
39 mins, not too bad
<beerman>
nah thats fine
<beerman>
my 5900x took 20m:9s for the rust rebuilt with clang/lld
<beerman>
now its already crunching on rust-wasm with clang/lld
<beerman>
and after that, i am hopefully able to compile zjstatus
<r0ni>
i'm only using half my m1, so i assume it'd be faster natively for sure
<beerman>
because zellij is nice, just not fully there yet, and i have no time to hack features into that, its under active development though and zjstatus is just the start for a good plugin
<beerman>
that system is a rather new feature which made me look into zellij again. they switched the config system from toml to kdl or something since the last time i looked
<beerman>
aaand thats finished, 13m:5s
<beerman>
doesn't work, oh well, but the error is different <.<
<r0ni>
thats' still progress
<beerman>
yeah will see, seems just like a linking problem and i see patches for that floating around but I'd like to understand what exactly is going on there
<beerman>
well, doesn't matter, thats not too important :D
<beerman>
pitillo cmake rebuilt just fine after i installed the missing, new system deps
<beerman>
good thing about dropping so many overlays!
<r0ni>
mesa builds with that sed line now so good there
<r0ni>
it donot like those cflags tho
<beerman>
sorry?
<beerman>
:P
<r0ni>
-mtls-dialect=gnu
<beerman>
it should say lignux
<beerman>
:D
<r0ni>
hahaha
<r0ni>
ok, i've got to head out... ttyl beerman
<beerman>
cya r0ni
<pitillo>
re-reading...
<pitillo>
beerman: go ahead with mesa if you have it clear
<pitillo>
I can test/check here
crux-arm-bot has joined #crux-arm
crux-arm-bot has left #crux-arm [#crux-arm]
<crux-arm-bot>
[ crux-ports-core-arm64 ] openssl: update to 3.1.3 Important: remember to revdep and rebuild dependent ports
<pitillo>
the script returned a very big list of ports to be rebuilt....
<pitillo>
gcc on the way... this will took a looong time (crossing fingers to get it built without problems)
<beerman>
pitillo on my way 🫡
<beerman>
might take a while longer, the host ist busy on clang and the container is slower due to that
<beerman>
do you have any knowledge about vulkan stuff with mesa on arm targets? Thats what I noticed obviously missing
<pitillo>
no idea really. I remember someone asked for vulkan support to be added
<pitillo>
I don't remember who, but he had a nvidia device I believe
<beerman>
there is more than sway, but i never ventured deeper into that. as an i3-user on x11, i was happy that sway would swallow my config as is with only minimal changes needed
<pitillo>
here an enlightenment user since I don't remember....
<beerman>
this still works? XD
<beerman>
wow
<pitillo>
I thought it was easier than it is xD
<pitillo>
Inneed more timenfor reading and understanding better
<pitillo>
rust finished now without problems
<beerman>
it really is just installing wayland, update a few ports, choosing a compositor (its what they call a window manager for wayland)
<beerman>
done
<beerman>
pipewire? stop any other daemon - start the pipewire daemon - done
<beerman>
well, not that easy really, if you want to emulate pulseaudio and/or jack with it, but not too much of a fuzz either
<pitillo>
I have wayland installed. I'll review enlightenment build to check if it supports it (it should, but not sure if my build does)
<beerman>
basically just include them in the config..
<pitillo>
yes, it does for sure...but probably it needs somentweaks and support installed (my build probably hasn't aa wayland came later I believe)
<beerman>
there is no choice in a manager anymore - you need wireplumber
<beerman>
they dropped the other
<pitillo>
pipewire understood... nice notes
<pitillo>
for enlightment only efl and E need to be rebuilt to add wayland support... then point to use it
<pitillo>
sounds reasonable
<pitillo>
let's see if tomorrow I can get a break at afternoon to make those tests
<pitillo>
for today, is more than enought (gcc is still building, I'll check at work tomorrow)
<pitillo>
have fun and a good night!
<beerman>
you too
<beerman>
i am still looking at mesa
<beerman>
i am hoping vulkan stuff doesn't need an overlay
<beerman>
[87/2450] its getting a bit bigger though, not sure if all targets are needed but i am looking at what arch arm ships
<beerman>
pitillo r0ni https://git.crux.nu:82/tb/notes/wiki/pipewire my notes on pipewire, updated, will exchange that with the port and pmwiki when i get the markdown plugin working :P
<beerman>
mesa test seems to work fine here, i just need to fiddle with the pi kernel more, my resolution with dual head is fucked for no reason