We're extremely pleased to announce a major milestone in the history of seL4: The proof of functional correctness for the 64-bit Arm architecture (AArch64) is complete!
Congratulations Proofcraft on this awesome achievement!
We're immensely grateful to UK's National Cyber Security Centre for for funding this work, which is of great importance to the seL4 ecosystem.
You now no longer have to chose between a verified kernel and a modern processor, you can have both 😁 https://sel4.systems/news/#aarch64-fc
I also refreshed what I’m calling the “pkg_dump” of #slackware#aarch64 package builds yesterday. There’s a shit-ton of stuff there, like a full gnome 46 desktop, and the latest Firefox 125.0.1, MAME, i3, sway, hyprland, etc. https://slackware.lngn.net/pub/aarch64/pkg_dump/
It seems that on #NixOS (unstable), there are (currently) no premade builds of #Plasma6 on the cache server for #aarch64. Unfortunately, on my #pinebook_pro, the integrated 64GB MMC simply isn't big enough to build it from source, even on a fresh vanilla installation! :blobcatnotlikethis:
I started seeing this after updating the system, which also updated gcc. I suspected a gcc regression, so I filed https://bugs.gentoo.org/923154 in Gentoo's bugzilla.
I found that the previous version of gcc didn't have this problem. Should be able to bisect..
I also tried and couldn't reproduce the failure in a 32-bit chroot on #Gentoo's #aarch64 development machine, so I was stuck doing all the debugging (and loooooong #gcc builds) on my very slow single-core 800MHz Solid Run #CuBox.
Diff'ing the assembly output between the working and non-working gcc versions I saw:
> - vmov.f64 d0, #6.:e+0
> + vmov.f64 d0, #7.0e+0
Naturally, binutils' assembler fails to recognize "6.:e+0" as a floating-point constant. Where is the ":" coming from?
Updated the #nwgshell#slackware#aarch64 repo earlier with the python 3.11 upgrades, as well as pushed all the other updates needed in other repos. NOW I can focus on real updates like hyprland and updating the WebKit-gtk package and deps. Wee! https://slackware.lngn.net/
wer unseren experimentellen fediverse- #flohmarkt unter #nix / #nixos auf dem #raspberrypi einsetzen möchte kann das nun tun. die flake unterstützt jetzt auch #aarch64 :)
I've put online my QT6 build AND I've started a little temporary repo for #slackwareaarch64. Since it's currently having major lag from the x86 Slackware, and there's been a ton of security updates the past week, I've built ALL the updates so #aarch64 users can be as secure as their Intel brethren. Leech the packages or add to slackpkg+ and let it do the talking here: https://slackware.lngn.net/pub/aarch64/slkupdiff/
QT6-6.6.1 is sitting all alone in https://slackware.lngn.net/pub/aarch64/
Back to work on packaging @hare for @fedora, let's see how much I can bang out in a few hours. The resulting artifacts are going to be fairly simple, but not particularly packager friendly. That's a day-2 project.
New cross-compile meta packages for #GNU and #LLVM dependencies.
I've created a convenience script, harex, to switch to non-GNU toolsets. Just set HARE_XCOMPILE_TOOLCHAIN to "llvm". User specified env vars will still be respected.
Alright, I’ll do something productive since I took the day off work. Building libreoffice 7.6.3.2 for #slackware#aarch64 and I’ll push the updates I’m sitting on for #nwgshell once I check and ensure I didn’t break any packages.
@Tekchip thanks for sharing your experience with #aarch64 and #flatpak support. Honestly, It didn't work with me. #snap was the only option available to me. I will try to give flatpak another shot.