<thefossguy>
<davidlt[m]> "I think we don't even have..." <- I forgot to ask you about this. Is there a reason why the build fails? (Still new to the Koji UI and unable to dive in myself, apologies for not checking it myself.)
<thefossguy>
I'm currently using Arch Linux on the VF2 and have podman working just fine. The issue on the side of containerization is that there aren't many riscv64 images.
<davidlt[m]>
Containers work on riscv64 for years now.
<davidlt[m]>
Podman is blocked by google-x-tools package, which has tons of cyclic dependencies that needs to be figured out.
<davidlt[m]>
We have been using containers with systemd-nspawn for years now, and the actual runtime are compiled IIRC.
<davidlt[m]>
Interesting, the dependencies in Arch Linux for golang-x-tools are a lot less detailed.
<davidlt[m]>
Also it doesn't show cyclic dependency.
<davidlt[m]>
In Fedora those are generated automatically and way more detailed.
<thefossguy>
Could it be because Arch Linux does not have a min/max version for compatibility reasons?
<davidlt[m]>
Even the list of requirements is way smaller. I mean significantly smaller, like it was written manually by someone (I don't know).
<davidlt[m]>
It's a packaging thing. Fedora has automated macros for provides/requires, those generate a largish list and detailed one too.
<thefossguy>
There are two "src repos", which one are you talking about? The maintainer for RISCV has his own set of patches for upstream PKGBUILDs. Some need a patch to build but some don't. :)
<davidlt[m]>
I am looking at the official stuff.
<davidlt[m]>
Anyways, not a big problem, but just needs someone to sit down and figure it out.
<davidlt[m]>
I didn't look at podman as there are no problems with it AFAIK.
<thefossguy>
Oh, so you looked at the go-x-tools package?
<davidlt[m]>
yeah, x-tools, x-text, etc.
<thefossguy>
Ok I get what you mean now
<thefossguy>
I want RHEL but I prefer Arch Linux's build tooling
<thefossguy>
It took me only a day or so to build the kernel as a .pkg.tar.zst package and the RHEL9 kernel.spec file is 3000 lines long, of which 1500 is still code, the rest is changelog.
<thefossguy>
Ooof :(
<alexsaezm>
<davidlt[m]> "Hopefully alexsaezm might do it..." <- I'm gonna take a look at this this evening after I stop yelling at ppc64le
<davidlt[m]>
Thankfully ppc64le did not became widely available :) Otherwise it would be a nighmare to have another popular arch :D
<davidlt[m]>
Pratham Patel: you don't need to modify *.spec directly in dist-git. Technically you modify kernel-ark (which contains RHEL, ELN, and Fedora) kernel information.
<davidlt[m]>
What you see in dist-git is basically a "product" generated from kernel-ark.
<davidlt[m]>
Of course you can hack all of this in any way you like :)
<davidlt[m]>
There is a structure with branches, but usually poorly documented (personal opinion), and spending time with Red Hat kernel folks in their IRC channel helps to figure out things.
<davidlt[m]>
<alexsaezm> "I'm gonna take a look at this..." <- Thanks!
<thefossguy>
davidlt[m]: Doesn't RHEL officially support ppc64le?
<alexsaezm>
yes
<davidlt[m]>
Yup (unless something changed).
<alexsaezm>
it's not popular as a workstation, but it's somewhat popular as server
<alexsaezm>
I kinda like it, when I yell at it, it's me yelling at myself for having zero clue :D
<davidlt[m]>
I used to play with some POWER9 servers before.
<davidlt[m]>
I remember debugging LLVM with IBM folks on it, and ISA was interesting.
<davidlt[m]>
IIRC I liked "TOC" and there is something like two entry point into a function.
<thefossguy>
<davidlt[m]> "Pratham Patel: you don't need to..." <- I'm still new to the DNF world, so thanks for the tip! I will look into this. I'm definitely interested in finding out why you guys find RHEL addicting when the naming convention is not the most uniform (`--assumeno` and `--skip-broken`).
<thefossguy>
But agreed, the rest is awesome! :D
<davidlt[m]>
Anyways, old days :
<davidlt[m]>
I am not addicted to a particular distribution. I am used to a particular policies/situation on a distribution for sure.
<davidlt[m]>
I am with Fedora mostly because of how fast it goes, adoption of new technologies, etc. and the most important thing are developers.
<thefossguy>
I don't know how that was delivered but the "why you are addicted even though this is stupid" was a joke :)
<davidlt[m]>
I know way too many Red Hat folks working on so many upstream projects, and a lot of them are extremely helpful. Just a good vibe.
<thefossguy>
And by addicted, I mean "why are you still with Fedora/RHEL when you can easily switch to another distribution"
<thefossguy>
davidlt[m]: OSS is nice :)
<davidlt[m]>
It's mostly due to the folks working on it or around it :)
<davidlt[m]>
Like I really like NixOS, but I am not willing to switch to it.
<thefossguy>
That I agree with. skip77 is one of them :D
<davidlt[m]>
I used Manjaro on my AArch64 laptop, but didn't like how they were cooking things.
<thefossguy>
Manjaro...
<davidlt[m]>
and yes, that basically means I had to wait 2 or 3 years for some feature X to be working in Fedora.
<davidlt[m]>
Because the right way is the hard one (and usually a long one).
<thefossguy>
When I look for Linux compatible, I look for "Fedora compatible" laptops specifically for this reason
<davidlt[m]>
I know folks ant SUSE and Canonical. Love the engineers too, really great folks.
<davidlt[m]>
I still don't like some decisions Canonical or distribution makes.
<thefossguy>
Fedora has a F[L]OSS-only policy afaik and it means everything in upstream works. Meanwhile the Dell dev laptops have a vendor kernel :surprise_pikachu_face:
<thefossguy>
davidlt[m]: you're snapped :P
<davidlt[m]>
Good one 😸
<alexsaezm>
thefossguy: Pratham Patel: Usually Red Hat demands their workers to upstream everything first, that means work on Fedora before anything else in a lot of scenarios and submit everything instead of having it internally. Hence the policy in Fedora
<thefossguy>
I like that!
<davidlt[m]>
I have built so many packages in Fedora over the years (from Koji: 219'875 builds submitted). Fedora is not perfect, but it's probably similar situation in other distributions too.
<alexsaezm>
davidlt[m]: how do you look that? tasks under your profile?
<davidlt[m]>
GRUB2 is a big problem in all major distros.
<thefossguy>
Side note: how do you enable a kernel config option from the CLI when you can't find it from menuconfig?
<davidlt[m]>
It's like everyone has 200, 300, or 300+ patches on that one :D
<thefossguy>
davidlt[m]: defconfig doesn't enable that config
<thefossguy>
time to look at kernel-ark now
<davidlt[m]>
Well it could be that your defconfig isn't working.
<davidlt[m]>
I mean after config checks run defconfig changes.
<thefossguy>
isnt that olddefconfig?
<davidlt[m]>
Source defconfig == Generated by the system at kernel configure time.
<davidlt[m]>
Fedora/RHEL/etc. kernel builds will check for this and break the build before compile starts.
<davidlt[m]>
You must get the config right before the kernel build can happen. Basically after kernel stuff runs the generated configuration must be exactly what you expected it to me.
<davidlt[m]>
If you enabled a new CONFIG_* option and those are different the build will fail.
<thefossguy>
Yeah, had a few fail on me because of a wrong config
<davidlt[m]>
It takes it from Rawhide and builds for older versions of Fedora.
<davidlt[m]>
I bet QEMU 8.0.0 will land within days.
<davidlt[m]>
I had a walk and remembered something.
<davidlt[m]>
alexsaezm: IIRC x86_64 and aarch64 are smart on the kernel side. Basically even if you use 57-bit virtual address space they will allocate memory from the lower bits unless you explicitly ask for somewhere else.
<davidlt[m]>
That's not implemented for riscv64.
<davidlt[m]>
and Golang only understands how to deal with Sv39.
<davidlt[m]>
To maintain compatibility with userspace applications that rely on the ARMv8.0 VA space maximum size of 48 bits, the kernel will, by default, return virtual addresses to userspace from a 48-bit range.
<davidlt[m]>
Userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter larger than 48 bits.
<davidlt[m]>
So basically maybe_high_address = mmap(~0UL, size, prot, flags,...);
<davidlt[m]>
This default behaviour is disabled if `CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y` are used to compile the kernel.
<davidlt[m]>
What we have now (or soon) is ability to tell QEMU that do Sv39/48/57 for virt machine, or the kernel boot parameter to limit it to Sv39/48/57.
<davidlt[m]>
But you still cannot boot a kernel on Sv48 or Sv57 machine and expect Golang, V8/Node, OpenJDK to work properly without this mmap + hint feature implemented.
<davidlt[m]>
Unless those packages implement their logic to adjust pointer tagged based on VA bit size.
<davidlt[m]>
There is a fun kernel potential kernel feature if someone wants to have fun :)
<davidlt[m]>
Ventana VT1 is Sv48 hardware, the 1st one.
<davidlt[m]>
Even 64-core SoC (2S 128-core system) is still Sv39 and that's why it has limited RAM capacity support.