Please do not distribute AUR-links here and offer own builds / ports. The AUR is full with questionable, non-free distributed package-scripts. We do not support this here!

Especially DO NOT distribute binaries. Therefore I have removed the corresponding parts.

So the answer here therefore is: No, not possible for Hyperbola. We distribute free, libre software on source-base and compile packages on source-base. If there is no source, it is non-free.

Going therefore into details: You have used paru. The program is written near complete only in Rust, which is not possible to be built with Hyperbola. So paru is NOT POSSIBLE to be used: https://github.com/morganamilo/paru
Furthermore Arch GNU/Linux and AUR are not very reliable when it comes into licensing: Within packages the licenses are often only marked with GPL (without the version-number) or even wrong licenses as GPL is also used as "something free and libre" while the original package and its sources are licensed completely different likewise MIT (Expat), ISC or something else. So the full AUR is nothing to rely on and every build-script needs a concrete review. The preferred way is to use the build-scripts, review and audit them and create something reliable from them, working on. Using just a Rust-based program to download something from the AUR is the worst case possible. Hyperbola does encourage building own package-scripts, no problem when they are based on others or use them as base (for sure with mentioning the original authors then needed). But we do not encourage to copy AUR-packages here and for sure not so called "binary"-packages as they are not even building from source.

Hyperbola is offering a version of grub marked good and stable. We do not have the interest to offer the newest release. The recommendation of Libreboot is not fitting the compliance Hyperbola is up to. The problems:

1. That package linked is downloading data direct from git-repositories. So there is no stable tarball anyone can rely on.
2. Weak hashsums are used for packaging.
3. The resulting package is only guaranteed working on Arch GNU/Linux.

We had this talk already and I can only repeat it again: I have not the time to work on a modified grub-package. If you want, you can always try to backport those patches from the package or / and update the grub-version. Neither the AUR-package would work nor the recommendation from Libreboot as those are oriented on Linux but not on systems going FHS and UNIX likewise Hyperbola. So as you have asked, here is the source-tree with all relevant parts: https://git.hyperbola.info:50100/packag … /tree/grub

You can try building your own package.from it. Linking also the points Hyperbola is marking important:
https://wiki.hyperbola.info/doku.php?id … ble_system

We have no issue in community-oriented packaging: So when a grub-package works and is stable tested, based on stable tarballs also we can go through adapting and further optimizing. But as said also: I have seen that our current grub-package needs a rework. So I have done that and prepared a good working rebuild as this one is a leftover from 0.4 preparation. While stable working we also need always to guarantee that every package released can be rebuild from scratch when people look here: https://repo.hyperbola.info:50011/gnu-p … hyperbola/

(The directory is the same for stable!)

I have already answered the question, jim. More than once, but well: The comparison with Android is just another not fitting one, because Hyperbola is NOT Android, while Android itself is also not direct a GNU/Linux-system (there is no glibc, it is bionic being used).

You want something implemented, please go ahead and support doing this so Hyperbola may be able to integrate it. I have already listed the needed parts. So again:

1. You need a clean chroot-environment (please use stable Hyperbola and not testing, more to read about libretools here).
2. You need a working source-tree for packaging, possible use here: https://git.hyperbola.info:50100/~team/ … 34a54ef004
3. You need to modify the package fitting the version-number you want to use.
4. Adapt the patches you need.

That is the way to build a package for Hyperbola in short notes. And please stop using short-lined comparisons. That one with Android is a really bad one, because it is exactly not like "Newer software is almost direct more secure!". This implied one is the same term false and shortened. And this is NOT an invitation to start a debate about Androids patch-level and security, just to be clear!

With a sigh: I even understand your point without any example. But it stays nevertheless questionable besides that your "new example" is even more worse than the one before now. Or should we now start comparing why it is better to look after already used machinery and try even to repair and enhance it instead of "throwing old away"? E-waste is a desastrous point growing. So you do not need the bad comparisons like those. One-dimensional looking, yes ... some alike fitting (with the questionable side-effect of growing economic footprint as common sense is no longer that way and people do whatever they think is best with the lowest amount of effort done for themselves). But all of those do not have just one dimension as security has also not only one attack-vector like the patch-level of the kernel as an example. This is only misused in arguments stating that "newest is always better". And you have underlined this again now - from my perspective again one-dimensional. And I ask again: Stop derailing your own thread leading it off-topic.

And as for building: You have all needed. You can also start with a complete different package. Packaging is not that complicated under pacman / hyperman. And it is also not more complicated with libretools. You just need to follow the guides available and we have already talked about the dirty way with makepkg. So I would recommend this first. Otherwise I cannot help here further. I have linked you the ground reasonings of Hyperbola, you have sources for th package in a renewed state from even today. All you need now is a tryout. Yes, technical emancipation is a ground rule for Hyperbola. But this includes also the will doing so and the more guidance I write or offer the more invitation is there to explain every single detail for every single package and this is not meant that way. Yes, Hyperbola will get upcoming an article for exactly this: Packaging guidance. But this have some elementary basic requirement: Knowing how to compile and patch software. So instead of asking me now for every detail on how to create a package: https://wiki.hyperbola.info/doku.php?id … guidelines (for a start)

You have makepkg already installed when pacman / hyperman is there.
For a package:

1. Download all relevant parts (given git-link).
2. Copy all in exactly one folder (named grub as example).
3. Start local building with "makepkg -s" (not "makepkg -si" as you first want to see whats going on).

Really, not that complicated for a first tryout.
After building you can start with tryouts like updating to a newer version. My proposal:

1. Dry run building a current version.
2. Update the package-version.
3. Go for patching and adapting.

Yes, there are more traps and you will have a learning-curve. But no guidance can overcome this step.
By the way: This is closing now the circle ... I have no problem answering concrete questions on how and where traps are and packaging works. Same as for repairing and enhancing an existing tool and machinery, likewise flashing also possible systems on a mobile device (IF there is so much interest and need for those per defintion unsafe devices) is supporting the lifecycle instead of the one-dimensional answer "newer is better". And please stop now using those comparisons. Test packaging your own!

Jim, for real: It is not complicated and you just need to read the PKGBUILD I have already linked. Read through and build the package. As it seems argon2id support is not common also in Grub and needs patching you have chosen this point on your own. But first go just through packaging, nothing more. Just this as you want modifications to be done not all the rest wants or demand.

Besides that: One last time, your argumentation on the rest is ... even under nicest perspective ... not respectful and full sarcasm. So I ask - one last time now: Stop that point and focus on one step ahead. And understand that I have not the time to be here for your service only.

I repeat also: Packaging (= creating a real package for Hyperbola) is possible at any time with tools being there from the start. It is better as building Grub direct local and installing it as this method has the risk leaving parts in your system and you have to remove them manually (with going through all Makefiles and source-definitions). So as I have said: You were given already everything needed for a first start. Make smaller steps instead trying to enforce support from me or anyone else with sarcasm and disrespecting arguments stating "I'm right, you are in fact childish" ... you really think this is going to work? You see that this is only derailing your thread and before you go further off-topic next with stating that "I am disrespecting users for whatever your next reasoning" ... I will stop answering then and ignore your questions in this matter. So either you want to choose working together and do also steps into packaging or you prefer building local, but on your own. You have asked about packaging starting here with paru and this is exactly packaging from AUR. The only difference is: I have proposed doing this on clean basics for you. So when you talk about a clean way managing your system, you should also talk about packaging and not only building alone. The difference I'm on: Teaching to package? Yes. Guidance on how build your "very own and personal patched Grub"? No.

One last and final time: There is no need to act like this, argument like this and react like this. Working together in the matter of the community? Absolute sure thing. So you have many arguments and information here on how to start. Your choice and approach now.

I suggest(ed) to learn packaging as the alternative is what you already noted: Building Grub direct and local, which is quite more with issues. Surely possible, but the results may vary besides building Grub is also with more traps when using for example on Coreboot-systems (or Libreboot). I referenced the PKGBUILD for exactly the reasoning to get inside perspective in the build-process (which is clearly to be seen there), the needed dependencies from a clean environment and direct also to learn packaging.

So with the PKGBUILD you can first learn how to build a reversible to be used package: Install or remove it, use the one from the repositories again or use your own build instead. The difference is: You have always an up- or downgrade on your choice. Therefore the first and most important fields in the PKGBUILD (https://git.hyperbola.info:50100/~team/ … 34a54ef004):

pkgver=2.04
pkgrel=6
epoch=2

pkgver marks as the name says the used version of the package, either 2.04 or what you want then 2.12.
pkgrel is starting for 2.04 at 6 current, needs for another local build (and any following to be rised in one step, so for example 2.04-7 when you do your own or starting new at 1 when you use a complete new version, so 2.12-1)
epoch is same as pkgver but used for complex packages like Grub to differ better between minor and major releases (so for a 2.12 it would start again with 1)

You need to look at those parts: Package-versions (explained above), the source-array and the hashsum-array. Example:

source=("https://ftp.gnu.org/gnu/${pkgname}/${pkgname}-${pkgver}.tar.xz"{,.sig}
        "https://repo.hyperbola.info:50000/sources/grub/grub-extras.tar.gz"{,.sig}
        "https://repo.hyperbola.info:50000/sources/grub/gnulib.tar.gz"{,.sig}
        "https://repo.hyperbola.info:50000/sources/grub/grub2_${_debver}-${_debrel}.debian.tar.xz"{,.sig}
        "https://ftp.gnu.org/gnu/unifont/unifont-${_UNIFONT_VER}/unifont-${_UNIFONT_VER}.bdf.gz"{,.sig}
        '0001-10_linux-20_linux_xen-detect-hyperbola-initramfs.patch'
        '0002-add-GRUB_COLOR_variables.patch'
        '0003-10_linux-20_linux_xen-rebrand-free-distros.patch'
        '0004-20_linux_xen-detect-kernel-configuration-files.patch'
        '0005-20_linux_xen-remove-placeholder-entry.patch'
        'grub.default'
        'remove-relocator64.patch')

sha512sums=('9c15c42d0cf5d61446b752194e3b628bb04be0fe6ea0240ab62b3d753784712744846e1f7c3651d8e0968d22012e6d713c38c44936d4004ded3ca4d4007babbb'
            'SKIP'
            'ba34812007ab2acac08ae7bcf7f9168473657704d65a82ece28a93666cdf1b8d49f5f4aa67d4edc1d8bbf498dc0e2f3adb0e1164f3c9af1bfe0a955043bf4fa3'
            'SKIP'
            '8012a5472de910bd4d6637a7a889d81bfc12cfbd00adeb6a12d4aad43e8d8a90884fc9ecfcaef43faf9b7030f14b0071b57d71f1c87dab1d9cfe94371d4bb5e9'
            'SKIP'
            '61d6900140f83a5e4c066e3f530d5093cd1961b036f37c29eefd14131fb2e2022602dcfff2ac6cd58769bca1cb824446550b0c2a9aba6b4a3ae5c7ed82943b5a'
            'SKIP'
            '45cf6a0c08d498a41a0bf2acff1ba34c1a59991f9f4a7b73c2124b408ce17b5aece8a008b85a196e84e031448c0333bc1fdaa65ad6329f1c0889ef56a218ae27'
            'SKIP'
            '3529ab4d08a4165e081c49dfc1cf40079ad9a1b9dd7ab6d39147fc347cb6aa615fd90292ecd5ecbfb543bf444bef27043a2392029d0210f9b4a6369365d3da1b'
            '0ae2f50a397268ea0ff46faa180e699ba956acaa68504d9dde7c33ab194430df57c2e2e5f9fe30b6c31e7806666faad4b274747ba151035e338bcaab3d875c3e'
            'f88b937b9a4f24cc1f2a113c55a8ab01b8b610616e72d2191f375d32b2ae27ca6a50811632711848253026e0c9a36a40f8be8bec1daa33f03666b00f60f1b14b'
            '63938fde65f20a616a1611f2b533ae596a2e13ca7b30796071bc59762cde0fe588fcc5008bfa593f0fb01e0f929642eeecd687072fdb6aa0d0456d0e8778ceba'
            '22b0b479b1cc448a240739b0be164dc202bfb9688f8219aef5c711a1b96aaf06da78323a5e79d74adefd34ac42fe6566592bf398c9de99f6f35fcd28794d1418'
            'c715b089ba869ed957450403bb2c57b5650a0bb0f6a8e823893e030296268a53870825ea37e219ab3e7261c79e6efacab9fe624a70ecce4c3c4456c2cf54e816'
            'fa7ccf679d69e0ebe2b7b537e566b11122f8dc6d8de85f952e4eec19ac724c63251b40660446d8141be014ac9cd8d6d1da05453c44f9869c1e69c3d1f7e30d4a')

When you change a package-version and leave the rest: At minimum the first entry will change. So you have to change also the first line in sha512sums with the correct hashsum for the newly downloaded tarball. This is the command to help you in that:

sha512sum [FILENAME]

As said: Downloading all parts listed in the concrete folder into a local one and execute the command makepkg -s brings you at minimum a bit more deeper and nearer towards your own package to be used at any given time. This has advantages:

- as said reversible testing
- good starting conditions for your further research
- no manual intervention outside packaging direct in your root-filesystem

What can you learn from a PKGBUILD?

- how to build the package, even if you do not want to learn more about packaging itself it shows how to build in which order and where traps are
- what dependencies are needed
- patching needed in different situations (your wished feature is not supported upstream so far I have seen, this is important then)

Please tell me where I can get a link to git?
Example Git Clone URL: https://hyperbola.info/grub.2.04.git

This is a little different from what I meant, I have to show a link to Grub, you can delete it later.

Git Clone URL: 

git clone https://aur.archlinux.org/grub-improved-luks2-git.git

for example I'm in chroot

# arch-chroot /mnt

and then I assemble Grub, which will then be installed into the system

# su  - jim

$ git clone .....

$ cd grub...

$ makepkg -si  

you mean that for example, now I have Grub 2.04 installed, then I compiled Grub 2.12 and installed it instead of Grub 2.04. How to do this safely so as not to break the system? Using USB-live to remove the old Grub and install a new one?

I have not said it is fully safe: I only mentioned a way forward to have a reversible own standing package for usage. You want to use a complete new feature not even part of the upstream-release so far (argon2id), so I would not say it is "safe" for usage. Besides to underline that you should try this first in a virtual environment.

If we are talking about assembling and installing Grub 2.12 on a ready-made system, then I want to clarify again, is this instruction => https://linuxconfig.org/grub-compile-fr … ,suitable? I'll replace Grub 2.6 with Grub 2.12 and try installing it in a virtual machine to see how it works.

I don’t understand why I need PKGBUILD Grub 2.04 https://git.hyperbola.info:50100/~team/ … 34a54ef004 now if I’m building Grub 2.12. I would appreciate an explanation.