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
zsun has joined #fedora-riscv
jednorozec has quit [Read error: Connection reset by peer]
jednorozec has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
davidlt has joined #fedora-riscv
davidlt has quit [Ping timeout: 260 seconds]
zsun has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt> that's binutils 2.42 for F41/Rawhide. So far failed tests, but probably will land soonish.
<davidlt> no new patches for riscv in GCC 14 for the last 24 hours :) That's good.
<davidlt> Seems like things are finally settling down
<davidlt> today I will continue rebuilding GHC
<davidlt> I guess our mass rebuild is starting with GHC :) awkward :)
zsun has quit [Quit: Leaving.]
<davidlt> oh, ast2700 incl. riscv64 core
<davidlt> (MCU)
<davidlt> riscv32
jcajka has joined #fedora-riscv
jcajka has quit [Client Quit]
jcajka has joined #fedora-riscv
<sorear> davidlt: ref? all I can find for ast2700 is that support was added to TF-A two months ago
<davidlt> sorear, it's on qemu devel mailing list
<rwmjones_> g'morning
<rwmjones_> any more packages you want me to look at, put the names in here
<davidlt> morning, let me look and make a list
<davidlt> this one needs retesting for sure, not sure why it works differently on riscv64
<davidlt> fftw (needs retesting), but it's basically MPI stuff, might need work with upstream: http://fedora.riscv.rocks:3000/rpms/fftw/commit/6b98ceb5c257fcfc403f4e88836259688221af0a
<davidlt> freecell-solver valgrind, but requires a more proper fix (rm the valgrind tests?): http://fedora.riscv.rocks:3000/rpms/freecell-solver/commit/b99796effa93411a2757f89dcf2c3c224aaf96fa
<rwmjones_> done Random123, biab and I'll do the other packages
<davidlt> gd, -ffp-contract=off, but %check part should not be upstreamed (tests pass now): http://fedora.riscv.rocks:3000/rpms/gd/commit/f93ac742bddd1a0e6693be52f2d728b6ab265a85
<davidlt> gdb, needs to add riscv64 support in the spec (check spec): http://fedora.riscv.rocks:3000/rpms/gdb/src/branch/main-riscv64
<sharkcz> re astyle - we (aka me) might want to rebase to latest release, seems they made couple new releases last year, previous (3.1) was in 2018 ...
<davidlt> gdl, disable broken tests (but recheck locally): http://fedora.riscv.rocks:3000/rpms/gdl/commit/118e3685e8ef04fd5a2cb7647136c76d7b74d8c9
<davidlt> sharkcz, sure, if you have dist-git URL, SRPM just post details here or Matrix and Richard or me can launch a test build for riscv64
<sharkcz> ack
<davidlt> rwmjones_, I assume you do test these changes on Fedora 40 (riscv64) locally before submitting?
<davidlt> anyways, I look for trivial/easy ones right now
<davidlt> I already see some are not needed (e.g. disabled docs before of pandoc)
<davidlt> enough for now
<davidlt> rwmjones_, https://github.com/nothings/stb/pull/1610/files , I am looking at __LP64__ part and I don't really know why I added it :)
<rwmjones_> davidlt: yes
<rwmjones_> I mean, I compile them, I don't test them in huge detail
<rwmjones_> davidlt: re __LP64__ I thought that was actually a better idea than just listing every possible 64 bit arch by name
<rwmjones_> which was why I left it
<rwmjones_> let's see what they say upstream anyway
<davidlt> Yeah, I think that's why it's there.
<davidlt> Listing all arches is not really comfortable.
<sorear> __riscv_xlen is wrong there anyway, xlen is the register size not the ABI pointer size
<sorear> normally I recommend __SIZEOF_POINTER__, I haven't looked at the compatibility story for __LP64__
<sorear> why not use stdint.h? C89 compiler support?
<davidlt> ah yes, for newer things I recall using __SIZEOF_POINTER__ more often
<davidlt> LP64 macro is: These macros are defined, with value 1, if (and only if) the compilation is for a target where long int and pointer both use 64-bits and int uses 32-bit.
<sorear> i'm hoping that Windows for RV64 is more common than ILP32 for RV64 in the long run
<sorear> (LLP64)
<davidlt> I forgot that Windows as LLP64 on x86_64, is that true for aarch64 too?
<rwmjones_> davidlt: on both Linux and macOS aarch64 it defines __LP64__, I don't have Windows to test
<sharkcz> davidlt: re astyle - it should be rpmbuild (likely /usr/lib/rpm/redhat/brp-ldconfig) what adds the filename -> soname symlink automagically when processing the binary rpm content, you should be able to drop the change, if not, then "rpmbuild" is broken
<davidlt> https://godbolt.org/ probably knows :)
* rwmjones_ is just rebuilding astyle right now, results soon ...
<davidlt> rwmjones_, is on top of this :)
<rwmjones_> so it fails with ...
<rwmjones_> RPM build warnings:
<rwmjones_> %patchN is deprecated (2 usages found), use %patch N (or %patch -P N)
<rwmjones_> RPM build errors:
<rwmjones_> File not found: /home/rjones/rpmbuild/BUILDROOT/astyle-3.1-21.fc41.riscv64/usr/lib64/libastyle.so.3
<rwmjones_> let's see what the file is called ..
<davidlt> I recall it working on all arches expect riscv64
<rwmjones_> $ ls -l /home/rjones/rpmbuild/BUILDROOT/astyle-3.1-21.fc41.riscv64/usr/lib64/
<rwmjones_> total 312
<rwmjones_> lrwxrwxrwx 1 rjones rjones 18 Feb 15 10:14 libastyle.so -> libastyle.so.3.1.0
<rwmjones_> -rwxr-xr-x 1 rjones rjones 316800 Feb 15 10:14 libastyle.so.3.1.0
<davidlt> It had the that symlink missing on riscv64
<davidlt> sharkcz, ^^
<rwmjones_> + ln -s libastyle.so.3.1.0 libastyle.so
<sharkcz> yup, then something doesn't work as expected ...
<rwmjones_> %soversion expands to 3.1.0 I guess?
<sorear> https://reviews.llvm.org/D36098?id=108991 not a primary source but best i've found so far
<rwmjones_> it does feel like an upstream bug of some sort, rather than riscv64
<sharkcz> IMHO it's /usr/lib/rpm/redhat/brp-ldconfig issue
<sharkcz> we can add the symlink, but it hides the root cause IMO
<rwmjones_> maybe, but it seems like linking libastyle.so -> libastyle.so.3.1.0 is always wrong as that's not how shared libraries are normally linked?
<sharkcz> AFAIK that's OK
<sharkcz> looking at /usr/lib/rpm/redhat/brp-ldconfig, it's better to create the missing symlink explicitly
<sharkcz> # TODO: warn if it created new symlinks and guide people. :-)
davidlt has quit [Ping timeout: 268 seconds]
davidlt has joined #fedora-riscv
<davidlt> rwmjones_, not all GHC packages got rebuilt during the mass rebuild, could you / maintainer restart the failed build?
<davidlt> so far ghc-readline and ghc-libxml-sax the last two rebuilds failed
<davidlt> otherwise I have to make our own NVR for these
<rwmjones_> davidlt: do you mean in regular koji?
<davidlt> Yes, yeah, some packages failed in mass rebuild and thus no new NVR
<davidlt> I guess petersen didn't look into them
<rwmjones_> because the branch has happened, that's an f41 build
<rwmjones_> don't know if you also want f40
<davidlt> yes, because my script syncs between tags
<davidlt> thanks
<davidlt> there will probably be more later today
<davidlt> these should be part of failed builds of mass rebuild
<davidlt> oh yeah, there are more.
<rwmjones_> looking..
<rwmjones_> I see a lot ..
<rwmjones_> ghc-readline f41 failed btw
<davidlt> well, if there is newer versions (NVR) builds these are fine, but in mass rebuild (at a time) these failed to rebuild
<rwmjones_> ghc-libxml-sax f41 also failed
<rwmjones_> ghc-libxml-sax f40 also failed
<davidlt> sounds like we have a problem in general
<rwmjones_> I'll have a look at it
<rwmjones_> ok these are "modern C" things
<davidlt> I will try to build the failed NVRs (all of these are bumps), but if any "fix" happens hopefully it gets a new NVR
<davidlt> oh, so pandoc will get blocked :)
<rwmjones_> yeah I don't think there's a chance this will build with gcc14
<rwmjones_> I was using some older gcc
<davidlt> chat with petersen about status/cleanups/etc
<davidlt> I am a bit surprised as modern C cleanups have been ongoing for many months now
<rwmjones_> let me see if this is code in the package itself, or code generated by ghc ..
<davidlt> it's probably C code in GHC package
<davidlt> I recall that cabal files (?) might contain GCC flags
<davidlt> Actually the list incl. ghc-pandoc-types too
<davidlt> only on ppc64le, but logs are gone
<rwmjones_> ok I think this is generated C code, although not sure what generates it
<davidlt> looking at failures it seems random arches
<davidlt> ppc64le seems to be a popular one to fail
<rwmjones_> yeah it's generated by ghc
<rwmjones_> files like compiler/GHC/HsToCore/Foreign/C.hs
<sharkcz> fyi astyle has been updated in rawhide
<rwmjones_> sharkcz: thanks, will test it now
<davidlt> sharkcz, could we get symlink fix in F40 too?
<sharkcz> sure
<davidlt> thanks
<rwmjones_> ok astyle from rawhide is building on my riscv machine now
<davidlt> rwmjones_, there is a good chance GHC stuff might have been fixes upstream already
<rwmjones_> yeah I'm looking at that
<davidlt> the main question would be: do these changes change compiler hash? :) // resulting in GHC ecosystem rebuild again
<rwmjones_> there's an upstream fix for -Wincompatible-pointer-types-discards-qualifiers
<davidlt> Some reference material for what to look: https://fedoraproject.org/wiki/Changes/PortingToModernC
iooi has quit [Ping timeout: 252 seconds]
<rwmjones_> I would say there's very little chance we can backport small things, and maybe updating ghc is the best option
<rwmjones_> for riscv can we build pandoc in f39 buildroot?
<davidlt> we don't have f39. We skipped it to spend all time / boards towards f40 catch up.
<davidlt> this needs a proper fix, we could wait until GHC 9.6.X lands in Fedora 40
<davidlt> at that point this will have to fixed anyways
<davidlt> there is no way around it as hashes for all GHC packages will change
<davidlt> most likely these fixes exist only in 9.9
<rwmjones_> so if there was a package that included FFI and just depended on ghc, I might be able to build it locally and try to fix ghc
<davidlt> check with petersen, he would know
<rwmjones_> how to search for that ..
<davidlt> alternative would be to disable these
<davidlt> try rebuilding with build_type_safety_c set to 0
<davidlt> Alternative is to disabled that in code per package, in Cabal file.
<davidlt> Anyways, talk with petersen as he must have a plan for this (GHC 9.6 is approved for F40).
<davidlt> and I doubt all these cleanups are in 9.6.X
<rwmjones_> here's ghc-readline with build_type_safety_c == 0 (scratch build):
<rwmjones_> davidlt: I posted on devel@
<rwmjones_> sharkcz: it compiles now, although I saw these warnings:
<rwmjones_> Duplicate build-ids /home/rjones/rpmbuild/BUILDROOT/astyle-3.1-22.fc41.riscv64/usr/lib64/libastyle.so.3 and /home/rjones/rpmbuild/BUILDROOT/astyle-3.1-22.fc41.riscv64/usr/lib64/libastyle.so.3.1.0
<rwmjones_> Duplicate build-ids /home/rjones/rpmbuild/BUILDROOT/astyle-3.1-22.fc41.riscv64/usr/lib/debug/usr/lib64/libastyle.so.3-3.1-22.fc41.riscv64.debug and /home/rjones/rpmbuild/BUILDROOT/astyle-3.1-22.fc41.riscv64/usr/lib/debug/usr/lib64/libastyle.so.3.1.0-3.1-22.fc41.riscv64.debug
<rwmjones_> (apparently not fatal)
<sharkcz> yeah, I see them as well and could not get rid of them
<davidlt> rwmjones_, cool, you could have added Florian as he owns Modern C change
<sharkcz> and would be useful to know why /usr/lib/rpm/redhat/brp-ldconfig didn't do its job ...
<rwmjones_> davidlt: if he doesn't see it in a few hours I'll ping him, but he's usually very responsive
<davidlt> does ldconfig actually create symlinks?
<rwmjones_> yes
<davidlt> maybe re-run this with script modified in mock buildroot?
<davidlt> you could pass -v to ldconfig
<rwmjones_> could it be a /lib64/lp64d thing?
<rwmjones_> that directory doesn't exist in the buildroot, so maybe ldconfig gives up
<davidlt> Yeah, I am thinking the same
<rwmjones_> back in 30 mins
<davidlt> it's not part of basefilesystem?
<davidlt> it should be there if GCC is installed IIRC
<davidlt> we have:
<davidlt>
<davidlt> %ifarch x86_64 ppc64 sparc64 s390x aarch64 ppc64le mips64 mips64el riscv64
<davidlt>
<davidlt> oops
<davidlt>
<davidlt> /%{_lib}
<davidlt> we aren't creating /%{_lib}/<ABI> directories
<davidlt> I was thinking about this recently
<davidlt> we also aren't setting libdir to /%{_lib}/<ABI>
<davidlt> at some point we need to spend time to figure out what we want to do with this
<davidlt> this is also messing with meson (but that's meson problem)
<davidlt> thanks to Pioneer it's easier to experiment with GCC (especially if you disable all the stages)
<davidlt> AFK
esv has quit [Remote host closed the connection]
esv has joined #fedora-riscv
<davidlt> that was a mistake :)
<davidlt> but yeah, this requires a proper fixing.
<davidlt> this will most likely will be needed for GHC 9.6 move
<davidlt> rwmjones_, I would suggest rebuilding all failed GHC related packages to collect all Modern C related failures
<davidlt> I afraid these could change compiler hash if we do one-by-one and thus we would need to keep recompiling everything
<davidlt> we need upstream GHC ticket too
<rwmjones_> florian's suggestion of emitting #pragma in ghc might be a good one
<davidlt> not really, pragma is just another way to hide it
<davidlt> replicated Vala workaround is still a workaround
<davidlt> we need to collect all failures, capture failed generated files too
<davidlt> then cook a GHC issue
<davidlt> then we can look at temporary workaround
<davidlt> (pragma stuff)
<rwmjones_> one sec, dealing with stuff
<rwmjones_> ok
<rwmjones_> so I'll do scratch builds of all the ghc-* packages that failed
<davidlt> there are 5.6K issues on GHC repo OoO
<davidlt> o_O
<davidlt> Peterson has an issue files 3 weeks ago: https://gitlab.haskell.org/ghc/ghc/-/issues/24348
<davidlt> ah, but this for GHC itself
<rwmjones_> ok I kicked off scratch builds of all the failed packages
<davidlt> Surprisingly GHC 9.4 compiled fine :)
<rwmjones_> (see email update)
masami has joined #fedora-riscv
* davidlt checking..
<davidlt> rwmjones_, nice investigation!
<davidlt> respin ghc-th-orphans, sounds like OOM
<davidlt> are ghc-gi-gtk, ghc-gi-ostree reported upstream?
<rwmjones_> nope
<rwmjones_> let's try florian's patch, I'm doing all this on x86-64
<davidlt> rwmjones_, 2nd one worked
masami has quit [Quit: Leaving]
<davidlt> why did it work on f41, but not f40?
<davidlt> could you re-try on f40?
<davidlt> ghc-gi-gtk fail feels strange, and might be related to atk packages
<davidlt> hmm... there was a new version of at-spi2-core (atk-devel)
<rwmjones_> sure, one sec
<rwmjones_> I'm having problems even rebuilding ghc locally on x86-64
<rwmjones_> /usr/bin/ld.gold: pack-relative-relocs: unknown -z option
<rwmjones_> (even after commenting out the ld.gold stuff from the spec file)
zsun has joined #fedora-riscv
<davidlt> some bits might still use ld.gold (hardcoded)
<rwmjones_> just upgraded the whole machine to rawhide ..
<rwmjones_> biab, meetings ....
<davidlt> be careful, this might have binutils 2.42 :)
<davidlt> nah, that's still blocked in Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2024-86f122ac31
zsun has quit [Quit: Leaving.]
<rwmjones_> davidlt: florian's patch worked, I'll send it upstream shortly
<davidlt> rwmjones_, cool
<davidlt> rwmjones_, cool, saw the email
<davidlt> and a new batch of GHC packages goes to Koji queue
<davidlt> actually I am experimenting with this too, I am running Pioneer with maxjobs=16 / capacity 64.0 in Koji
<rwmjones_> I'm just doing an unpatched fftw build on vf2, seems ok so far but it hasn't got the check stage yet
<davidlt> ok
jcajka has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 264 seconds]
cyberpear has joined #fedora-riscv
cyberpear has quit [Quit: Connection closed for inactivity]