dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
Guoguo has joined #fedora-riscv
Guoguo has quit [Ping timeout: 260 seconds]
Guoguo has joined #fedora-riscv
Guoguo has quit [Ping timeout: 268 seconds]
Guoguo has joined #fedora-riscv
Guoguo has quit []
Guest42 has joined #fedora-riscv
<Guest42> How close are we until we get risc-v as an edition on Fedora? Any eta?
Guest42 has quit [Client Quit]
davidlt has joined #fedora-riscv
amusil has joined #fedora-riscv
<amusil> davidlt I saw the reply from yesterday, so do I get that right that there isn't any way currently to get those >f38 booting in qemu?
<davidlt> They do boot, but I don't have instructions written up.
<davidlt> Because I was able to direct-boot the kernel, initrd with EDKII on QEMU. So no GRUB2 or systemd-boot.
<davidlt> That's what Pungi does for Anaconda to run the installer.
<amusil> One last thing I have tried was this:
<amusil> virt-install    --name fedora-riscv     --arch riscv64     --vcpus 15     --memory 16386     --os-variant fedora38     --boot loader=/usr/share/edk2/riscv/RISCV_VIRT.fd     --import --disk path=$PWD/Fedora-image.qcow2     --network network=default     --graphics none
<davidlt> The only difference today would be that ACPI might be working now (would need to check).
amusil has quit [Quit: Client closed]
amusil has joined #fedora-riscv
<davidlt> I don't recall if changes to edk2 landed in upstream Fedora, or stayed in virt-preview COPR
<amusil> However this command just leads to black screen, not sure if the image is really booting and the console is just wrong or it's not doing anything at all
<davidlt> That's one thing.
<amusil> That edk2 package seemed fairly new
<davidlt> It's something like this: https://paste.centos.org/view/83543ac8
<davidlt> The EFI kernels depend on UEFI firmware. It's using EFI ZBOOT to uncompress itself (riscv and arm kernels dont have uncompressor available in the kernel itself)
<davidlt> EFI ZBOOT stuff was added recently, and it's generic (used by arm64 and riscv64) to uncompress itself
<davidlt> IIRC chatting with the maintainer of edk2 package is that preference is only for qcow2 images these days
<amusil> Let's see if that package that I have provides it
<davidlt> The final changes to the spec most likely don't incl. .fd files.
<davidlt> Again, I never truly finished this work, but it booted and Anaconda did the install.
<amusil> So i have probably older one, there is only:
<davidlt> The only change since that is ACPI landed in QEMU and kernel IIRC.
<amusil> RISCV_VIRT.fd and RISCV_VIRT.raw
<davidlt> looking at edk2 dist-git all the changes seem to be there.
<davidlt> ah, .fd are fine, the .raw files were nuked
<davidlt> virt firmware json files are also present
<amusil> But this package still doesn't contain the qcows
<davidlt> Thus you want the latest build from F40
<amusil> So i need to get never one before attempting further
<amusil> Yeah I have the f37 one :)
<davidlt> I think all the stuff from Pungi work related to EDKII landed in Fedora 40
<davidlt> You can grab newer one from virt-preview COPR most likely
<amusil> And I need to find a way to convince virt-install to set it up
<davidlt> I do want to ship EDKII by default in Fedora 40 for riscv64, but some bits depend on RH folks working on bootloader bits
<davidlt> I most likely will nuke GRUB2 and go for systemd-boot, but that required rebasing gnu-efi, which is "stuck" too. Yet it's way smaller compared to GRUB2 stuff.
<amusil> But thank you very much for the pointer, at least I know where to continue
<amusil> How close is proper official build for riscv?
<davidlt> So Pungi uses libvirt to run all of this. Thus it works.
<davidlt> Depends on what you call official, we have been building Fedora since 2016 :)
<amusil> Well the same images as for arm64
<amusil> Just grab and go :)
<davidlt> So we had that for years, but in recent years it's hard to find time to cook them (requires testing).
<davidlt> It's basically lack of hands and time in a day to finish anything. That's why we images happen so rarely.
<amusil> Understandable
<davidlt> Those are before UEFI stuff.
<amusil> Right I was able to boot one of those
<davidlt> The idea would be to get back to disk image work, and hopefully finish Pungi too.
<davidlt> But that's after Fedora 40 mass rebuild is in a good shape.
<davidlt> We have started upstreaming dist-git changes recently thus there is even more work.
<davidlt> We hope to have a new Koji setup with FAS integration, so that's there the big push happens.
<davidlt> Otherwise folks managed to run Fedora 40 on their VF2s :) So it works as-is (and I about to break it with mass rebuild).
<amusil> Yeah I don't have any rela hardware
<amusil> *real
<amusil> So qemu is convenient way to get things going
<davidlt> Yeah, but it's not always fast :)
<amusil> I don't mind it being slow if it works in the end :D
<davidlt> But there is no hardware (today) that would match server compliance.
<amusil> If I manage to get it working I'll definitely try to update the https://fedoraproject.org/wiki/Architectures/RISC-V/Installing page
<davidlt> Cool!
<davidlt> I need to work on a new kernel too, but I still doing Rust, Python, Perl rebuilds
<davidlt> amusil, if you are a package maintainer you can also post here dist-git URLs for testing, and in some cases we also create accounts
<amusil> I'm not currently
hursand has joined #fedora-riscv
davidlt has quit [Ping timeout: 240 seconds]
<hursand> rwmjones_ Hello and I got a problem. We've tested before that the the tests for ghc related packages(ghc-*) haven't explicitly supported riscv64 arch. So I plan to submit a pull request to disable the entire tests for ghc-* packages on riscv64 arch, and I want to know if that's acceptable?
JasenChao has joined #fedora-riscv
davidlt has joined #fedora-riscv
<rwmjones_> davidlt: ^^
<rwmjones_> hursand said:
<rwmjones_> │07:27:01 hursand | rwmjones_ Hello and I got a problem. We've tested before that the the tests for ghc related │ kito-cheng
<rwmjones_> │ | packages(ghc-*) haven't explicitly supported riscv64 arch. So I plan to submit a pull request to │ leah2
<rwmjones_> │ | disable the entire tests for ghc-* packages on riscv64 arch, and I want to know if that's acceptable? │ moto-timo
<davidlt> hursand, don't we run tests for GHC packages?
<rwmjones_> hursand: are there particular packages that fail?
<rwmjones_> what is the failure?
<davidlt> IIRC the tests are running (otherwise packages wouldn't build)
<hursand> davidlt Yes we do run tests for GHC packages, and there're some specific packages that failed to pass the tests
<rwmjones_> I think david has rebuilt all or almost all ghc packages unmodified
<davidlt> hursand, could you give us a list of packages
<davidlt> ?
<rwmjones_> I'd like to see an example of a failure
<davidlt> I haven't rebuild the whole GHC package land, but majority right now.
<davidlt> and I don't recall any particular troubling things in the past (C or LLVM backends).
<davidlt> Thus I wouldn't want a global disable, and instead we should investigate whatever is failing for now.
<hursand> The previous compilation is on fc39 branch and I'm rebuilding these packages on rawhide, I'll be back with detailed info if the error persists
<davidlt> hursand, could you give example now?
<davidlt> Note in Fedora/RISCV we don't really have F39, we skipped it to chase F40 (CentOS Stream 10).
<hursand> davidlt I've checked all the failed packages and found the most errors are like ```Couldn't find a target code interpreter. Try with -fexternal-interpreter```, and these packages can be successfully built on rawhide branch now, so I think all ghc packages should be ok now. Sorry for bothering :)
<davidlt> That's fixed, take a new GHC from fedora.riscv.rocks
<hursand> Got it
<davidlt> We fixed that 1-2 weeks ago.
<rwmjones_> hursand: yeah we fixed that one, fix is in Rawhide
<davidlt> rwmjones_, it would be great if you could prep the same changes to ghc9.6, and ghc9.8
<davidlt> rwmjones_, especially 9.6 as that's what Fedora 40 will ship as default
<davidlt> 9.8 is F41 most likely
<rwmjones_> davidlt: yeah later today
<davidlt> I am fixing Perl today
<davidlt> For some unknown reason not all noarch packages were import properly.
<davidlt> koji import <..> skipped some RPMs while doing import without giving me a reason.
<davidlt> Anyways, identifying and fixing it
hursand has quit [Quit: Client closed]
amusil has quit [Ping timeout: 250 seconds]
davidlt has quit [Ping timeout: 240 seconds]
amusil has joined #fedora-riscv
amusil has quit [Quit: Client closed]
JasenChao has quit [Ping timeout: 250 seconds]
davidlt has joined #fedora-riscv
JasenChao has joined #fedora-riscv
<davidlt> I think I recovered
<davidlt> Launching a bunch of packages to verify before sending the rest
<rwmjones_> davidlt: ok doing ghc9* now
<rwmjones_> btw ceph failed yesterday with some atomic ops error:
<rwmjones_> actually no wait, it's not that
<rwmjones_> the error was:
<rwmjones_> {standard input}: Assembler messages:
<rwmjones_> {standard input}:4752281: Warning: end of file not at end of a line; newline inserted
<rwmjones_> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
<rwmjones_> g++: fatal error: Killed signal terminated program cc1plus
<rwmjones_> so that's all weird but I didn't look further
<rwmjones_> (for context, this is ceph with mold enabled)
<davidlt> rwmjones_, sounds like OOM
<davidlt> When you see "Killed signal terminated program cc1plu" it's typically out-of-memory stuff
<davidlt> and assembly files or whatever don't get fully written out showing interesting errors
<rwmjones_> yup could be
JasenChao has quit [Ping timeout: 250 seconds]
<davidlt> rwmjones_, JDK11 backport landed: https://github.com/openjdk/riscv-port-jdk11u/pull/3
<davidlt> This can now be regenerated if needed and land in Fedora.
<rwmjones_> davidlt: it's kind of impossible to test those ghc9.* builds on riscv64, so I'm just going to wait and check they don't break regular koji
<rwmjones_> davidlt: re openjdk, best to let the students deal with it? they seem to be into jdk packaging
<rwmjones_> fuwei: ^^
JasenChao has joined #fedora-riscv
<davidlt> rwmjones_, yeah, sure. I just didn't want it to land in Fedora until upstream accepted backport.
<davidlt> The same applies to other backports to other versions.
<rwmjones_> actually it's songsong doing the packaging on that one
davidlt has quit [Ping timeout: 252 seconds]
JasenChao has quit [Quit: Client closed]
JasenChao has joined #fedora-riscv
masami has joined #fedora-riscv
JasenChao has quit [Quit: Client closed]
davidlt has joined #fedora-riscv
masami has quit [Quit: Leaving]
<davidlt> had some stress right now
<davidlt> stupid travel router decided to upgrade itself, and turned on VPN toggle (but my VPN is disabled)
<davidlt> Thankfully I managed to debug that and avoid loosing Rust build
<rwmjones_> :-(
zsun has joined #fedora-riscv
zsun has quit [Ping timeout: 264 seconds]
davidlt has quit [Ping timeout: 268 seconds]