Bug 2311813
| Summary: | fails to upgrade to rc6 with failed dependencies | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Koberstein <davek> |
| Component: | wsjtx | Assignee: | Jaroslav Škarvada <jskarvad> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 40 | CC: | dan, hobbes1069, jskarvad, kevin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | aarch64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | wsjtx-2.7.0-7.fc41 wsjtx-2.7.0-7.fc40 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-09-23 00:15:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dave Koberstein
2024-09-11 20:41:06 UTC
No clue what happened, but try this scratch build: https://kojipkgs.fedoraproject.org//work/tasks/6222/123296222/wsjtx-2.7.0-6.fc42.aarch64.rpm Well, it's different! I got this - with some additional errors: $ sudo dnf install ./wsjtx-2.7.0-6.fc42.aarch64.rpm Last metadata expiration check: 1:25:10 ago on Thu 12 Sep 2024 02:25:57 PM PDT. Error: Problem: conflicting requests - nothing provides libm.so.6(GLIBC_2.2.5)(64bit) needed by wsjtx-2.7.0-6.fc42.aarch64 from @commandline - nothing provides libmvec.so.1(GLIBC_2.22)(64bit) needed by wsjtx-2.7.0-6.fc42.aarch64 from @commandline - nothing provides libc.so.6(GLIBC_2.14)(64bit) needed by wsjtx-2.7.0-6.fc42.aarch64 from @commandline - nothing provides libc.so.6(GLIBC_2.2.5)(64bit) needed by wsjtx-2.7.0-6.fc42.aarch64 from @commandline - nothing provides libc.so.6(GLIBC_2.4)(64bit) needed by wsjtx-2.7.0-6.fc42.aarch64 from @commandline (try to add '--skip-broken' to skip uninstallable packages) How does rpmbuild figure out the "Requires"? The spec file doesn't seem to have changed - at least there are no "Requires" directives. These two lists of Requires are pretty similar: https://rpmfind.net/linux/RPM/fedora/40/aarch64/w/wsjtx-2.7.0-3.fc40.aarch64.html https://rpmfind.net/linux/RPM/fedora/updates/40/aarch64/Packages/w/wsjtx-2.7.0-6.fc40.aarch64.html But the -6 version does not include "glibc >= 2.38.9000-33". Is that suspicious? Well there's a few things going on here: To answer your question RPM knows what what dependencies were used to compile with... And my assumption for the original problem is that somehow some libraries were updated after wsjtx was built but without it being rebuilt. The second part, I just goofed and rebuilt for Rawhide, nof F40, which I now have in process. Makes sense. I did try a build on copr using fc40 and had the same issue. Very strange. Looking forward to trying your new test build. Here it is, if this doesn't work we need to look at what might be wrong on your system... https://kojipkgs.fedoraproject.org//work/tasks/5339/123325339/wsjtx-2.7.0-6.fc40.aarch64.rpm Bummer. Same issue as the rawhide build: Error: Problem: conflicting requests - nothing provides libm.so.6(GLIBC_2.2.5)(64bit) needed by wsjtx-2.7.0-6.fc40.aarch64 from @commandline - nothing provides libmvec.so.1(GLIBC_2.22)(64bit) needed by wsjtx-2.7.0-6.fc40.aarch64 from @commandline - nothing provides libc.so.6(GLIBC_2.14)(64bit) needed by wsjtx-2.7.0-6.fc40.aarch64 from @commandline - nothing provides libc.so.6(GLIBC_2.2.5)(64bit) needed by wsjtx-2.7.0-6.fc40.aarch64 from @commandline - nothing provides libc.so.6(GLIBC_2.4)(64bit) needed by wsjtx-2.7.0-6.fc40.aarch64 from @commandline You suggest there might be something wrong with my system. Given that 2.7.0-3 installs (I've dnf-remove'd and dnf-install'd it), what could that be? How to track it down? Do you have a test aarch64 install to try a quick test install? If it makes sense, I can try my own build of the rpmsrc file and see how that works. I presume it would work since the Requires are figured out at build time. Help appreciated! I would try a `dnf --refresh update` and see if there was some major C library update but those are not generally done within a release. The test machine I can access is on F39 but showing the same issue. Interesting. I'm at a loss for the moment so I posted to the Fedora development list. I do that for every upgrade. :) I did also try it in this case just to be double sure. So there's further weirdness. I pulled the source rpm and did a --rebuild. The resulting rpm has the same issue. You'd think building it on my system, if it has something wrong with it, that the build would be ok. Just to mention it, I haven't installed anything outside of normal rpm sources. I use these (as provide from --refresh): $ sudo dnf upgrade --refresh Copr repo for pijuice-hat owned by komacke 4.7 kB/s | 1.5 kB 00:00 Copr repo for raspberrypi-userland owned by leo3418 7.3 kB/s | 1.5 kB 00:00 Fedora 40 - aarch64 59 kB/s | 16 kB 00:00 Fedora 40 openh264 (From Cisco) - aarch64 4.8 kB/s | 990 B 00:00 Fedora 40 - aarch64 - Updates 59 kB/s | 13 kB 00:00 RPM Fusion for Fedora 40 - Free 11 kB/s | 3.6 kB 00:00 RPM Fusion for Fedora 40 - Free - Updates 13 kB/s | 3.9 kB 00:00 Dependencies resolved. Nothing to do. Complete! Just for sake of completeness, I'll pull 2.7.0-3 and rebuild it and confirm it installs. If it does that would suggest something in the source rpm. FWIW it installs on an x86_64 fc40. More weirdness. the -3 does not rebuild successfully. It's a source code issue:
/home/n9dk/rpmbuild/BUILD/wsjtx-2.7.0/wsjtx/qmap/libqmap/decode0.f90:6:28:
6 | real*4 dd(2,NSMAX),ss(322,NFFT),savg(NFFT)
| 1
Error: Variable ‘nfft’ cannot appear in the expression at (1)
/home/n9dk/rpmbuild/BUILD/wsjtx-2.7.0/wsjtx/qmap/libqmap/decode0.f90:6:39:
6 | real*4 dd(2,NSMAX),ss(322,NFFT),savg(NFFT)
| 1
Error: Variable ‘nfft’ cannot appear in the expression at (1)
gmake[2]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:150: qmap/libqmap/CMakeFiles/qmap_impl.dir/decode0.f90.o] Error 1
I'll try to confirm I have the right source rpm and move further upstream to see if I can get this to build. I might also try a copr build since that's the closest I can get to "official" builds.
At least this is expected. 2.7.0-3 failed to build with the same error on the copr infrastructure. But that doesn't explain how there is an rpm for this source rpm (which I have installed successfully from fedora). The problem with https://kojipkgs.fedoraproject.org//packages/wsjtx/2.7.0/6.fc40/aarch64/wsjtx-2.7.0-6.fc40.aarch64.rpm is that it contains some x86_64 prebuild binaries (foxchk, sfrx and sftx) and those binaries require the "weird" glibc symbols. see wsjtx/lib/superfox in the source archive Thanks Dan! I wouldn't have thought to check for that. It's never been a problem before with this upstream. There definitely had to be something that contained those symbols, so the dependency generator (which is processing ELF data from binaries) was adding them. Then I have opened the wsjtx-2.7.0-6.fc40.aarch64.rpm in midnight commander using F3 and notices there were 3 files with different timestamp than the rest of files. Then I checked what those files were :-) BTW I haven't seen sources for those superfox binaries, so there might be one more issue ... Is this something that needs to be reported to wsjtx developers or is it something handled at rpm build time? Or both? I see it's new in the -6 (not in -3). But as it is being shared for all platforms in binary form, it seems like the spec file should be responsible for cleaning it up. Kind of a dumb comment. I wish I could edit. :) So the question really is will they distribute arm binaries of superfox. And if not, will wstjx still work without the superfox-supported feature. I'm on the groups.io list where I started with this issue. I've posted it back. I'm not sure if that's the most efficient way to reach the upstream developers. Richard - do you have contacts to report this to more efficiently? I sent a message to the developer list, they are working on making the source available. Apparently the prebuilt binaries we due to a time crunch to make them available for a contest. I worked on removing superfox this morning from the package but didn't get done before I had to get ready for $DAYJOB. That's great news. Especially the part that they are expecting to release using source instead of binaries. The working rc3 package expires at the end of this month. But obviously one can always go back to 2.6.1 if rc6 isn't working. Ok, let's try this again! https://kojipkgs.fedoraproject.org//work/tasks/4702/123364702/wsjtx-2.7.0-6.fc42.aarch64.rpm That's it! Thanks so much for figuring it out. It looks like that was from rawhide but no matter, it installed (upgraded, actually). I see the superfox setting. I presume that doesn't work until they get around to putting source into the distribution instead of binaries. Looks like an interesting feature. Too bad it created this havoc. Thanks again! I'll watch for a real package on the fc40 repo. Crap I did it again! :) Anyway, once I build new versions it should upgrade anyway since I need to bump the release. FEDORA-2024-fb5bb457dc (wsjtx-2.7.0-7.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-fb5bb457dc FEDORA-2024-b68c344cee (wsjtx-2.7.0-7.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b68c344cee If the package includes prebuilt binaries and cannot be built without them, it is not allowed in Fedora at all: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries Apparently, you managed to build without superfox, so that is now OK (your latest package appears to me to be in compliance with the above policy), but in principle the binaries are not supposed to be in the source tarball at all (and you should complain to upstream about that, see the policy link above). FEDORA-2024-b68c344cee has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b68c344cee` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b68c344cee See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-fb5bb457dc has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-fb5bb457dc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-fb5bb457dc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-b68c344cee (wsjtx-2.7.0-7.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-fb5bb457dc (wsjtx-2.7.0-7.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. |