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?
These #ARM#rk3328 based SBCs are going to drive me insane. I'm currently booting the #debian installer for #aarch64 over pxe because they're making use of eMMC modules instead of SD cards and the installer has to run through twice with me re-flashing u-boot twice in order to get a running system. These logs should be interesting once I get around to looking at them.
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.
Apple enables the TBI (top byte ignore) feature for macOS #aarch64 userland binaries, so this C program works correctly even when setting the 8 MSBits of a pointer to an arbitrary value.
The ideal platform for a new bare metal #Lisp machine? 😀
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/
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/
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.
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 :)
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