<pitillo>
hey all, updating some core ports will break ABI... any suggestion to manage this situation? (commits advertising? locking them? any other way?)
<beerman>
heyo :)
<beerman>
which ports are you having a problem with? I usually keep the system up and running until I got everything resolved, but I understand this can be tricky on some arm platforms
<pitillo>
I'll paste a current diff between upstream versions here... a little big list but without much movement at this channel, I think it won't disturb
<pitillo>
gcc 12.2.0-1 12.3.0-2 (core)
<pitillo>
libnl 3.7.0-1 3.8.0-1 (opt)
<pitillo>
pkgutils 5.40.9-1 5.40.10-1 (core)
<pitillo>
openssl 3.0.7-1 3.1.3-1 (core)
<pitillo>
util-linux 2.38.1-1 2.39.2-1 (core)
<pitillo>
meson 0.64.1-1 1.2.1-1 (core)
<pitillo>
linux-pam 1.5.2-3 1.5.3-1 (core)
<pitillo>
glibc 2.36-3 2.36-6 (core)
<pitillo>
libgmp 6.2.1-1 6.3.0-1 (core)
<pitillo>
python3 3.10.9-1 3.10.13-1 (core)
<pitillo>
pkgconf 1.9.3-1 2.0.3-1 (core)
<pitillo>
kbd 2.5.1-1 2.6.3-1 (core)
<pitillo>
nftables 1.0.5-1 1.0.8-1 (core)
<pitillo>
db 5.3.28-2 5.3.28-3 (core)
<pitillo>
dbus 1.14.4-1 1.14.10-1 (opt)
<pitillo>
cmake 3.24.2-1 3.27.6-1 (core)
<pitillo>
libarchive 3.6.2-1 3.7.2-1 (core)
<pitillo>
if I'm right, openssl, meson, cmake and libarchive are candidates to break things (specially openssl -> ssh affected, so leaving the session can end on a locked remote system)
<beerman>
cmake and meson are not likely to break anything
<beerman>
libarchive more so, but as long as you make sure to revdep and rebuild where needed shouldn't hinder anything
<pitillo>
yes, both are delicate
<beerman>
openssl and ssh are not related? at least my ldd of /usr/sbin/sshd doesn't look that way, libcrypt and libcrypto are both glibc things
<pitillo>
I'd like to start this weekend moving on... so I think a commit message remembering rebuild/revdep could be enought, but not sure
<pitillo>
let me check, but I believe they were linked
<jaeger>
You could build generic versions of the breaking ports and host them in case of a bad interaction
<beerman>
if you notifiy users about that in some way i'd advise to add a /etc/rc.d/sshd restart to the list of advisories :)
<pitillo>
you are right, they seem to be linked with libcrypt/o
<beerman>
i used these images to build the raspberry container
<pitillo>
that sounds good too jaeger
<beerman>
just note that my packages are rather old
<beerman>
but these can be redone easily in a container, given some time
<pitillo>
let's see if I can put hands on along the weekend... and don't let core forgotten
<beerman>
heh :) perfect
<beerman>
i can really reassure you that these updates should be non critical by any means I can see
<beerman>
i didn't spend much attention to arm lately, so.. sorry for that :/ I am happy if I can help in any way possible
<beerman>
if you want, I can work up a new set of core ports, updated to current versions in CRUX, and share them here
<pitillo>
don't worry, all things seems to work as expected...
<beerman>
for the raspberry pi 4 that is, aarch64 :)
<pitillo>
probably the only work ahead is align core overlay with upstream
<pitillo>
and probably make an announce about the 3.7 release (here I'm using it without problems since long time ago xD)
<beerman>
we have been moving fast :) it's hard to keep up on ARM like that. Before I'd do a rust refresh for opt-aarch64 I'll prepare the next llvm updates too
<beerman>
one of my pies is productive as well on 3.7 for a long time too :D you have both my thumbs up for a release
<pitillo>
usually we can move as fast as CRUX, but some ports takes ages to build. The solution I believe is going on the M1 and develop there, but my wife is pretty busy at work and I can't invade the laptop
<beerman>
but you are right, some packages are just nightmares on slow machines
<jaeger>
I can do some building on my m1 mini if you need
<pitillo>
xDDD
<pitillo>
big ports are the hard ones (rust, lvvm...) those probably are the candidates to be maintained on the M1
<beerman>
pi4 is fine as well :) but the m1 will surely dust it
<jaeger>
Sure, just tell me which environment you ned me to build and I'll try it... generic or specific, etc.
<jaeger>
s/need/need
<jaeger>
typing is hard today :)
<beerman>
it's friday, after all
<jaeger>
indeed
<beerman>
i feel like its time to undust my second pi again and help out a bit 8-) it has been sitting on the shelf for a few months now
<jaeger>
I hear also that pis are starting to become available again
<pitillo>
jaeger: probably a generic one should be enought to bump them, but if they are usefull for you for any device, optimized could be fine. The point is to keep ports up to date and/or synced with upstream
<pitillo>
that sounds like a plan beerman xD
<jaeger>
generic seems like the best place to start
<pitillo>
yeah jaeger... bit by bit... let's see if they came affordable again... but from my side, I'm just thinking on an M1 directly
<beerman>
i wish it could do poe :(
<jaeger>
Yeah, just commenting. I'm not going to buy another pi just for this, have quite a few still around... plus the M1
<jaeger>
You could get one of those PoE hat things... though yeah, would be nice if it were not needed
<beerman>
pies have been getting more and more available, i am not buying a new one either though :) Two have to suffice here. I still want to do a rootfs for the pinephone, but I fear I won't be able to support it further after that
<beerman>
heh yeah I know about the hats, but I don't have any :D i was looking for where i can plug it in <.<
<beerman>
network is easier for me
<beerman>
but it booted up fine, no issues with that :)
<beerman>
first need to update the containers core packages
<beerman>
that ports -u is pulling in a lot :D
<jaeger>
At some point I'm tempted to try asahi linux on the M1
<beerman>
asahi was the m1 optimised distro? should be a good experience :)
<jaeger>
yes... just been waiting for things like GPU to mature, etc.
<jaeger>
It's come a long way, I'm sure, I haven't looked at it recently
<beerman>
I have no personal experience with those. Just from what I have been reading on the common news portals :)
<beerman>
i am just here happy that distcc just works, so hopefully the core update (excluding the ports i have installed that depend on rust to be built, e.g. atuin, delta..)
<pitillo>
I'm waiting for the M3 lauch to check M1/M2 prices... may be waiting a bit show some deals soon
<pitillo>
asahi sounds very interesting if you are not really interested on the MAC stuff
<jaeger>
I use a mac all the time for work, not really a mac person :P
<beerman>
its been weeks and still most people don't know I switched to CRUX on my work notebook xD
<beerman>
can't be bothered with windows problems when I want to get work done 💁♀️
<jaeger>
I was able to run linux on my older work macbook pro (intel) for a while until corp IT moved into a mobile device management ecosystem that has zero linux support :/
<jaeger>
So now it's either mac or windows and between the two I chose mac, though honestly either would work since the majority of what I do is remote
<jaeger>
or in containers, etc.
<beerman>
ouch, yeah
<beerman>
my biggest problem is azure, but if the thumbscrews they put on that is that you have to use some hardware token and the edge browser then I'm golden ;)
<beerman>
pitillo https://dpaste.com/ETLWSUQNN btw, I found this script while looking through some gentoo stuff. this helps to fix weird problems if you have incompatible lto'd libraries around
<beerman>
after upgrading gcc it makes sense to run this with -l or -r
<beerman>
updating the container took 1h:48m:17s :) thanks to distcc for sure
<jaeger>
Not bad at all
<beerman>
I consider that fast enough really :) but sure, more power is always nicer. anyhow, I hope I can present a few prs for llvm/rust over the weekend