it was built in November and December, I think that means there is a bug. For build frequency, have a look: https://gitlab.archlinux.org/archlinux/packaging/packages/python-aotriton/-/commits/main
please read the comments above. What you want would mean that ALHP would need to provide all packages, not only the rebuilt packages. This would mean a lot more storage space and traffic. As…
If my memory does not fail me, python-aotriton also did that LTO --> non-LTO thing in december and also sometime earlier last year.
the python rebuild is still running and will do so at least until tomorrow. https://status.alhp.dev/ until that rebuild hits the repo's you should disable alhp repo's if you need to update or…
You can uncomment the line #VerbosePkgLists in your /etc/pacman.conf (to read VerbosePkgLists) to make it easier to spot non-ALHP updates.
It can happen that another Arch - package pulles…
look closely - the situation appears because you are upgrading packages that are taken from the Arch repository with the ALHP packages still being built.
ALHP can't hold your packages on your…
it still has to be uploaded and mirrors have to be synced. The build cycle still has 43 packages to go for that to be done.
@anonfunc i tried again with rebuilding rust with the non-lto.conf and it still produces a usable rust package. The version in the repository is still producing the error.
no worries. Something seems to have gone wrong though - rust 1:1.89.0-1.2 still produces the error, and the status page shows that it is still an LTO build.
ok found some time to compile rust locally.
- Building rust with the regular makepkg-x86-64-v4.conf leads to the above mentioned error when…
I also ran into the issue when trying to recompile mesa locally.
Can you try to rebuild rust locally with the relevant makepkg.conf from here: https://alhp.dev/makepkg/ and check if the issue…
accoring to the status page, firefox now builts with LTO, although it should have been added to the non-LTO list. Anyway, Firefox now successfully builds which means this issue can be closed.
unfortunately, llvm/clang 20 (currently in testing) still does not fix the problem with firefox ...
extra-x86-64-v3/element-desktop 1.11.92-2.1
the problem is also tracked in the Arch bug tracker, a first fix seems to be only a partial fix: https://gitlab.archlinux.org/archlinux/packaging/packages/element.io/-/issues/14
sorry false alarm. Just realized that something undid my changes to the build scripts in /usr/share/devtools/makepkg.conf.d without generating pacnew's or pacsave's -.-
With v4 optimizations it…
@anonfunc llvm/clang 19 seems to finally fix the firefox build, at least I could now build it in a clean chroot with v4 optimizations.