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
davidlt has joined #fedora-riscv
davidlt has quit [Ping timeout: 268 seconds]
davidlt has joined #fedora-riscv
davidlt[m] has quit [Read error: Software caused connection abort]
davidlt[m] has joined #fedora-riscv
moto-timo has quit [Read error: Software caused connection abort]
moto-timo has joined #fedora-riscv
mbohun[m] has quit [Quit: You have been kicked for being idle]
jcajka has joined #fedora-riscv
<rwmjones> seems like the visionfive's are shipping
<davidlt[m]> Cool. Did they send yours out?
<rwmjones> they emailed me to confirm my address
<rwmjones> "within the next 48 hours"
<rwmjones> davidlt[m]: which *.pc file is it that has the wrong path? may be worth bringing this up on devel list
<rwmjones> also be interested in why this causes failures particularly on riscv64, I would think it affects every arch?
<davidlt[m]> rwmjones: I think it's because meson internal lookup kicks in, and it gets something wrong for riscv64 too. It typically ends up something like /lib64/lib64/lp64d/blah.so, which is also wrong which leads to failure.
<davidlt[m]> There are more, but later. I don't have a full list.
<davidlt[m]> This actually was discussed in 2012 (in upstream by Fedora): https://cmake.org/pipermail/cmake/2012-February/049206.html
<rwmjones> hmm, the x86 pc file is wrong
<rwmjones> (/usr/lib64/pkgconfig/libcares.pc)
<davidlt[m]> I think it's just the same issues, relative vs. absolute paths.
<rwmjones> prefix=/usr
<rwmjones> exec_prefix=${prefix}/bin
<rwmjones> libdir=${prefix}//usr/lib64
<davidlt[m]> Exactly.
<rwmjones> $ pkgconf --libs libcares
<rwmjones> -L/usr/usr/lib64 -lcares
<davidlt[m]> These files are quite popular, and there should be some kind of validation tool one could run at the end.
<rwmjones> now to work out how to check for this systematically ...
<davidlt[m]> Exaclty. Meson at that point takes care to attempt to find it.
<davidlt[m]> I can tell you of another similar package in a minute or two (just firing up podman container to install a package)
<davidlt[m]> I will scan all the failing logs maybe next week, and thus catch most of them.
<davidlt[m]> Another one is libasyncns.pc (libasyncns-devel).
<davidlt[m]> libdir=${exec_prefix}/lib
<davidlt[m]> instead of lib64
<davidlt[m]> pkgconf --libs libasyncns
<davidlt[m]> -L/usr/lib -lasyncns
<rwmjones> also libibmad
<davidlt[m]> So meson does something like this: /lib64/lib64/lp64d/libasyncns.so
<rwmjones> libibnetdisc
<davidlt[m]> Which is also wrong.
<rwmjones> and many more
<rwmjones> let me see if I can make a systematic test
<davidlt[m]> There should something that would check the directories, check if the libraries exist in those, etc.
<rwmjones> yup
<davidlt[m]> Basically nothing fancy, but something that validates that pc files is correct.
<davidlt[m]> If not for meson failing on riscv64 with wrong paths this probably not have showed up on other arches.
<davidlt[m]> Mainly because of default library search paths.
<davidlt[m]> Even if you pass a crappy "-L" it still finds it in default or other valid -L paths.
<davidlt[m]> Sadly I 120% focused on building so all the spec changes, patches are in our dist-git.
<rwmjones> davidlt[m]: you don't remember what package used c-ares and failed to build before it was fixed?
<davidlt[m]> rwmjones: mmsd-tng
<rwmjones> I'm trying to understand the exact reason this only fails on riscv64
<davidlt[m]> because of meson
<davidlt[m]> You need to look at redhat-linux-build/meson-info/intro-dependencies.json generated by meson
<davidlt[m]> It should show: /usr/lib64/libcares.so
<davidlt[m]> {"name": "libcares", "version": "1.17.2", "compile_args": [], "link_args": ["/usr/lib64/libcares.so"]}
<davidlt[m]> if PC file is wrong, you get:
<davidlt[m]> {"name": "libcares", "version": "1.17.2", "compile_args": [], "link_args": ["/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libcares.so"]}
<davidlt[m]> I didn't check, but I assume meson tries to find the lib on it's own.
<davidlt[m]> For riscv64 on Fedora it comes up with /lib64/lib64/lp64d/libcares.so which is wrong and thus fails with a missing file.
<davidlt[m]> Note double lib64 in the path.
<davidlt[m]> That's why broken PC files + meson on riscv64 causes this issue.
<rwmjones> do you have the build.log from a failed build
<rwmjones> super annoying that koji hides older builds if they have the same NVR
<davidlt[m]> well you need to look for the task, which still exist :)
<rwmjones> right, it's finding the task which is the difficult part ..
<davidlt[m]> Huh. I think I see the first snow.
<davidlt[m]> I lowered Kojira settings to 12 hours now to gain a bit more space.
<davidlt[m]> Something is wrong with upstream Koji. It's hard to access it.
<davidlt[m]> Maybe some maintenance.
jcajka has quit [Quit: Leaving]
<davidlt[m]> Another one
<davidlt[m]> ninja: error: '/lib64/lib64/lp64d/libmt32emu.so', needed by 'tests/dos_files', missing and no known rule to make it
<davidlt[m]> While building dosbox-staging
<davidlt[m]> oh, lowering Kojira settings was mistake :)
<davidlt[m]> Some packages failed because repo already expired :)
<davidlt[m]> upstream Koji is just so slow
<rwmjones> davidlt[m]: it's been up and down all morning; seems to be working but slow right now
jcajka has joined #fedora-riscv
<davidlt[m]> probably because of f37
<davidlt[m]> rwmjones: call rpm --eval '%{_libdir}' ?
<davidlt[m]> % rpm --eval '%_libdir'
<davidlt[m]> /usr/lib64
<davidlt[m]> and %__os_install_post should be modified in redhat-rpm-macros
<rwmjones> yeah I was trying to avoid weird recursion :-/
<davidlt[m]> rwmjones: note that you use xargs and find commands
<davidlt[m]> these are probably not available by default
<davidlt[m]> I assume you would need BR on findutils and xargs
<davidlt[m]> ah, I don't recall which package is needed for xargs
<davidlt[m]> well, it's actually findutils again :)
somlo has quit [Quit: Leaving]
somlo has joined #fedora-riscv
Kevinsadminaccou has quit [Quit: You have been kicked for being idle]
<davidlt[m]> Our 2nd mass sync will result in ~1500 successful builds, ~1000 failed ones.
<davidlt[m]> Which is kinda impressive. This delta between upstream and downstream has never been so small.
<davidlt[m]> I think, I have to stop here, and spent what free space left on producing F37 disk image. Prep for Koji server migration.
<davidlt[m]> So that means it's time for me look at the OpenSBI, U-Boot (should be just a day) and kernel-ark stuff.
<davidlt[m]> While a good part of me still ones to fight until all the failing packages are just generic boring issues like C/C++ missing headers, string formatting, etc.
<davidlt[m]> We will have way more fun once we don't need to think about free space on the new server :)
<davidlt[m]> (or nightmare, depends on a day)
cyberpear has joined #fedora-riscv
jcajka has quit [Quit: Leaving]
sorear has quit [Ping timeout: 268 seconds]
jbowen has quit [Ping timeout: 255 seconds]
sorear has joined #fedora-riscv
sorear has quit [Ping timeout: 268 seconds]
jbowen has joined #fedora-riscv
jbowen has quit [Max SendQ exceeded]
jbowen has joined #fedora-riscv
jbowen has quit [Max SendQ exceeded]
jbowen has joined #fedora-riscv
sorear has joined #fedora-riscv
jbowen has quit [Max SendQ exceeded]
jbowen has joined #fedora-riscv
jbowen has quit [Max SendQ exceeded]
jbowen has joined #fedora-riscv
jbowen has quit [Max SendQ exceeded]
jbowen has joined #fedora-riscv
jbowen has quit [Max SendQ exceeded]
jbowen has joined #fedora-riscv
davidlt has quit [Ping timeout: 256 seconds]