Created attachment 1700421 [details] changes for el7 It would be useful to have this in EPEL (7 and 8). It needs the devtoolset compiler for epel7. I've attached a patch, tested with scratch builds on koji in the unfortunate absence of copr ppc64le.
(In reply to Dave Love from comment #0) > Created attachment 1700421 [details] > changes for el7 > > It would be useful to have this in EPEL (7 and 8). It needs the devtoolset > compiler for epel7. I've attached a patch, tested with scratch builds on > koji in the unfortunate absence of copr ppc64le. EPEL 8 would be possible with GCC 8/9. But EPEL 7 (GCC 4.8) would be problematic, Not sure I can support the full (400+) set of operations there and enable IFUNC dynamic libraries would require a work around for missing __builtin_cpu_is() suport. What version is the devtoolset compiler?
devtoolset-9 should be workable. I will need to clues on where / how to get started.
devtoolset-9 on el7 gets you gcc 9. I maintain packages done that way for updated language support and target support, e.g. avx512 on el7 x86. (This sort of thing must be more relevant to EPEL than Fedora, so it's worth doing, though HPC sites are strangely resistant to installing system packages.) You need to request new branches for epel7 and epel8. It's changed since I last did this, and I lose track, but I think you need to check out the pveclib repo and in it do e.g. "fedpkg request-branch epel7". I assume you get mail when that's been done. (This must be written up somewhere in the info for packagers, but I don't know where now.) Apply my patch on the master branch and check it in, switch to the other branches in turn and git merge master into them, assuming you want to keep the same spec on each branch. Hope that helps. Ask on the devel list if necessary, I guess.
(In reply to Dave Love from comment #0) > Created attachment 1700421 [details] > changes for el7 > > It would be useful to have this in EPEL (7 and 8). It needs the devtoolset > compiler for epel7. I've attached a patch, tested with scratch builds on > koji in the unfortunate absence of copr ppc64le. +%{?el7:BuildRequires: devtoolset-9-gcc-c++} +%{?el7:source /opt/rh/devtoolset-9/enable} +%{?el7:source /opt/rh/devtoolset-9/enable} +%{?el7:%exclude %{_docdir}/%{name}} +%{?el7:%exclude %{_datadir}/licenses/%{name}} So what are the adds for el8? 1. Repeat each with s/el7/el8/? 2. Use devtoolset-9 for both? or?
(In reply to Dave Love from comment #3) > devtoolset-9 on el7 gets you gcc 9. I maintain packages done that way for > updated language support and target support, e.g. avx512 on el7 x86. (This > sort of thing must be more relevant to EPEL than Fedora, so it's worth > doing, though HPC sites are strangely resistant to installing system > packages.) > You need to request new branches for epel7 and epel8. It's changed since I > last did this, and I lose track, but I think you need to check out the > pveclib repo and in it do e.g. "fedpkg request-branch epel7". I assume you > get mail when that's been done. (This must be written up somewhere in the > info for packagers, but I don't know where now.) Apply my patch on the > master branch and check it in, switch to the other branches in turn and git > merge master into them, assuming you want to keep the same spec on each > branch. > Hope that helps. Ask on the devel list if necessary, I guess. So this is still, in New state and I assume needs some approval process? What is the next step?
So how (can) I get the devtoolset so I can rpmbuild test my new pveclib.spec file? sudo dnf install devtoolset-9-toolchain No match for argument: devtoolset-9-toolchain Error: Unable to find a match: devtoolset-9-toolchain
(In reply to Steven Jay Munroe from comment #4) > So what are the adds for el8? > > 1. Repeat each with s/el7/el8/? > 2. Use devtoolset-9 for both? or? You don't need a change for el8; it builds asis.
(In reply to Steven Jay Munroe from comment #5) > So this is still, in New state and I assume needs some approval process? I don't know/remember how the bugzilla states work generally, but don't worry about the "new" status. It will go away once it's explicitly closed or a relevant package is pushed to stable that is tagged with the bug number when it's submitted.
(In reply to Steven Jay Munroe from comment #6) > So how (can) I get the devtoolset so I can rpmbuild test my new pveclib.spec > file? > > sudo dnf install devtoolset-9-toolchain > No match for argument: devtoolset-9-toolchain > Error: Unable to find a match: devtoolset-9-toolchain How you enable the repo will depend on whether you're on RHEL or CentOS, and I don't remember off-hand. You probably don't need whatever -toolchain pulls in, but you shouldn't need to do that. Builds in koji or or under mock locally have it enabled, and you should normally use mock to fix the build environment. I checked the build under mock on the Fedora ppc64 testing VM.
How about fedora? rpmbuild fails with the el7 patch applied because it can't find devtoolset.But works otherwise. fedpkg --release f33 scratch-build --srpm --fail-fast is also failing with the el7 patch. Looking for some difference ...
It works for me. Perhaps it was a transient system error.
Ya your patch conflicts with my own 1.0.4 change. So I did (tried to do) a manual merge. Net I had some extra leading '+' that caused the fail. Cleaned that up and it worked much better. I still have a question about the build.log? I never saw on, nor do I know where the look. It could be that my fail was so early there there was no build.log yet...
Ok now a hard question. Versioning? The original project version was 1.0.3 for the library version was: %{_libdir}/libpvec.so.0 %{_libdir}/libpvec.so.0.0.0 This version (1.0.4) added a bunch of function symbols (from vec_int512_ppc.c) and IFUNC dynamic binding (from vec_runtime_DYN.c) but I don't think removes any existing symbols (there was not much of library to 1.0.3). My inclination was to bump to %{_libdir}/libpvec.so.1 %{_libdir}/libpvec.so.1.0.4 and this what I built for rawhide 1.0.4apla2 (Does and alpha really count)? But my project reviewers have suggested this (bumping the major) was too much? And the responsibility of contributing to EL7/8 increases the stakes. This documentation does not really help: https://fedoraproject.org/wiki/PackagingDrafts/TildeVersioning So please advise what library version I need / should use for this bump. And does my alpha2 build on rawhide set a precedent?
You don't bump the soname for adding symbols - only changing or removing them. This might help: https://autotools.io/libtool/version.html that said, I've found the following difference: 2 Removed variable symbols not referenced by debug info: tifrexpof10 tipowof10 If those symbols were removed, you really should be bumping the soname. You also didn't set Version/Release properly for an alpha version for the rpm. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_prerelease_versions FWIW - I wouldn't consider your alpha2 build on rawhide a precedent.
Ok So it is: %{_libdir}/libpvec.so.1 %{_libdir}/libpvec.so.1.0.0 but now I have a new problem. $ fedpkg new-sources *.tar.gz Could not execute new_sources: Request is unauthorized. $ klist Ticket cache: KCM:1000 Default principal: munroesj52 Valid starting Expires Service principal 07/15/2020 11:36:09 07/16/2020 11:10:14 HTTP/koji.fedoraproject.org renew until 07/22/2020 11:10:14 07/15/2020 11:11:29 07/16/2020 11:10:14 krbtgt/FEDORAPROJECT.ORG renew until 07/22/2020 11:10:14 07/15/2020 15:39:45 07/16/2020 11:10:14 HTTP/src.fedoraproject.org renew until 07/22/2020 11:10:14 This worked Wednesday, so how do I reauthorize?
So I have to run $ kinit munroesj52 each time?
Failed again, Were are the build.logs? $ fedpkg --release f33 scratch-build --srpm --fail-fast setting SOURCE_DATE_EPOCH=1594080000 Wrote: /home/sjmunroe/fedora-scm/pveclib/pveclib-1.0.4-3.fc33.src.rpm [====================================] 100% 00:00:00 755.96 KiB 1.05 MiB/sec Building pveclib-1.0.4-3.fc33.src.rpm for f33-candidate Created task: 47350445 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=47350445 Watching tasks (this may be safely interrupted)... 47350445 build (f33-candidate, pveclib-1.0.4-3.fc33.src.rpm): free 47350445 build (f33-candidate, pveclib-1.0.4-3.fc33.src.rpm): free -> open (buildvm-s390x-03.s390.fedoraproject.org) 47350450 rebuildSRPM (noarch): open (buildvm-s390x-03.s390.fedoraproject.org) 47350536 buildArch (pveclib-1.0.4-3.fc33.src.rpm, ppc64le): open (buildvm-ppc64le-22.iad2.fedoraproject.org) 47350450 rebuildSRPM (noarch): open (buildvm-s390x-03.s390.fedoraproject.org) -> closed 0 free 2 open 1 done 0 failed 47350445 build (f33-candidate, pveclib-1.0.4-3.fc33.src.rpm): open (buildvm-s390x-03.s390.fedoraproject.org) -> FAILED: BuildError: error building package (arch ppc64le), mock exited with status 1; see build.log or root.log for more information 0 free 1 open 1 done 1 failed 47350536 buildArch (pveclib-1.0.4-3.fc33.src.rpm, ppc64le): open (buildvm-ppc64le-22.iad2.fedoraproject.org) -> FAILED: BuildError: error building package (arch ppc64le), mock exited with status 1; see build.log or root.log for more information 0 free 0 open 1 done 2 failed 47350445 build (f33-candidate, pveclib-1.0.4-3.fc33.src.rpm) failed
https://github.com/rpm-software-management/mock/blob/master/mock/py/mockbuild/exception.py#L26 # 1 = something happened - it's bad So like a timeout or builder systems down?
Ok so the problem seems to be this: RPM build errors: File not found: /home/sjmunroe/rpmbuild/BUILDROOT/pveclib-1.0.4-3.fc32.ppc64le/usr/lib64/libpvec.so.1.0.0 Because the pveclib.spec files says: %{_libdir}/libpvec.so.1 %{_libdir}/libpvec.so.1.0.0 But the ./src/Makefile.am file has: libpvec_la_LDFLAGS = -version-info $(PVECLIB_SO_VERSION) And the Configure.ac file has: # Update this value for every release: (A:B:C will map to foo.so.(A-C).C.B) # http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html PVECLIB_SO_VERSION=1:4:0 AC_SUBST(PVECLIB_SO_VERSION) Now there are two ways to make build work in the short term. 1) change libpvec.so.1.0.0 to libpvec.so.1.0.4 in the spec file. - I tried this and it works. 2) remove -version-info from libpvec_la_LDFLAGS ./src/Makefile.am and regenerate the Makefile's - Have not tried this yet and I am sure there are more death traps. - Seems that this requires a new tag (v1.0.5 or ?)
Another death trap: So to get libpvec.so.1.0.0 removing -version-info was not enough (end up with libpvec.so.0.0.0 which does not match either). So had to set: PVECLIB_SO_VERSION=1:0:0 This now passes rpmbuild -bb at least
(In reply to Steven Jay Munroe from comment #16) > So I have to run > > $ kinit munroesj52 > > each time? Your kerberos ticket is only valid for 24 hours at a time. You can renew before that with "kinit -R" or look into using krenew. At some point KCM should handle renewals, but I don't think that's ready yet.
Don't remove -version-info. Use: %{_libdir}/libpvec.so.1*
(In reply to Orion Poplawski from comment #22) > Don't remove -version-info. Use: > > %{_libdir}/libpvec.so.1* That worked and did not require a new tag. Thanks.
One more question for Dave ;) Pveclib 1.0.4 for F33/Rawhide: "This update has been submitted for stable by bodhi" So I assume unless some bug pops up peveclib-1.0.4 is in the queue for F33 and EL7/8? Should I also apply your el7 patch to the F32 branch? This make pveclib-1.0.3 available to EL7/8 also and perhaps a little sooner.
No, every branch is independent. Any changes you want for EPEL7/8 need to be merged into the epel7 and epel8 git branches and built and updates submitted. Likewise for F32/F31.
oookkk so will need a few more clues: $ fedpkg switch-branch epel7 Could not execute switch_branch: Unknown remote branch origin/epel7 So do I need to create the epel7 branch under pveclib or create an new pveclib project under epel7?
Step 7 of https://fedoraproject.org/wiki/New_package_process_for_existing_contributors
so this bugzila does not seem to be a valid request. So do I need a new (step 5) fedora-review request? With EPEL as the target?
Why do you think that? You just need to request epel7 and epel8 branches. pveclib has already been reviewed and is an existing package.
So step 7 -> fedpkg request-repo PACKAGE-NAME BUGZILLA-TICKET-NUMBER PACKAGE-NAME=pveclib BUGZILLA-TICKET-NUMBER=1725924? Or skip ahead to fedpkg request-branch --repo pveclib epel7 ?
(In reply to Orion Poplawski from comment #29) > Why do you think that? You just need to request epel7 and epel8 branches. > pveclib has already been reviewed and is an existing package. I appreciate your patience. In case it is not obvious by now I am seriously dyslexic.
Ah, sorry - did not notice that step 7 included request-repo. But since you already did that all you need now is the request-branch step.
(In reply to Steven Jay Munroe from comment #17) > Failed again, Were are the build.logs? > > > $ fedpkg --release f33 scratch-build --srpm --fail-fast > > > setting SOURCE_DATE_EPOCH=1594080000 > Wrote: /home/sjmunroe/fedora-scm/pveclib/pveclib-1.0.4-3.fc33.src.rpm > [====================================] 100% 00:00:00 755.96 KiB 1.05 > MiB/sec > Building pveclib-1.0.4-3.fc33.src.rpm for f33-candidate > Created task: 47350445 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=47350445 I'm having difficulty following this and bugzilla flags, but the build log for that case is there under the buildArch descendent link.
(In reply to Steven Jay Munroe from comment #24) > Should I also apply your el7 patch to the F32 branch? This make > pveclib-1.0.3 available to EL7/8 also and perhaps a little sooner. It's up to you whether or not you maintain the different branches in sync. I do, so I would merge the change to epel7 into epel8 and master, at least. I might not bother with f31, f32 unless there was a reason to change them.
Ok "what is the deal" with fedpkg ... scratch-build and the build.log! So now am trying to build: $ fedpkg --release epel7 scratch-build --srpm --fail-fast setting SOURCE_DATE_EPOCH=1594080000 Wrote: /home/sjmunroe/fedora-scm/pveclib/pveclib-1.0.4-3.el7.src.rpm [====================================] 100% 00:00:00 755.99 KiB 1.05 MiB/sec Building pveclib-1.0.4-3.el7.src.rpm for epel7-candidate Created task: 47508368 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=47508368 Watching tasks (this may be safely interrupted)... 47508368 build (epel7-candidate, pveclib-1.0.4-3.el7.src.rpm): free 47508368 build (epel7-candidate, pveclib-1.0.4-3.el7.src.rpm): free -> open (buildvm-s390x-05.s390.fedoraproject.org) 47508378 rebuildSRPM (noarch): free 47508378 rebuildSRPM (noarch): free -> open (buildhw-x86-12.iad2.fedoraproject.org) 47508482 buildArch (pveclib-1.0.4-3.el7.src.rpm, ppc64le): free 47508378 rebuildSRPM (noarch): open (buildhw-x86-12.iad2.fedoraproject.org) -> closed 1 free 1 open 1 done 0 failed 47508482 buildArch (pveclib-1.0.4-3.el7.src.rpm, ppc64le): free -> open (buildvm-ppc64le-35.iad2.fedoraproject.org) 47508482 buildArch (pveclib-1.0.4-3.el7.src.rpm, ppc64le): open (buildvm-ppc64le-35.iad2.fedoraproject.org) -> FAILED: BuildError: error building package (arch ppc64le), mock exited with status 1; see build.log or root.log for more information 0 free 1 open 1 done 1 failed 47508368 build (epel7-candidate, pveclib-1.0.4-3.el7.src.rpm): open (buildvm-s390x-05.s390.fedoraproject.org) -> FAILED: BuildError: error building package (arch ppc64le), mock exited with status 1; see build.log or root.log for more information 0 free 0 open 1 done 2 failed 47508368 build (epel7-candidate, pveclib-1.0.4-3.el7.src.rpm) failed So where is thew build.log? I have never found a build.log or root.log. Obviously I have done something stupid. But I will need a little more information. So are build.logs even available for fedpkg .. scratch-build .. --fail-fast Is there a different options that does?
Follow the task info link to the logs.
Ok found Processing files: pveclib-debuginfo-1.0.4-3.el7.ppc64le error: File not found: /builddir/build/BUILDROOT/pveclib-1.0.4-3.el7.ppc64le/usr/lib/debug/usr/lib64/libpvecstatic.so.0.0.0.debug RPM build errors: File not found: /builddir/build/BUILDROOT/pveclib-1.0.4-3.el7.ppc64le/usr/lib/debug/usr/lib64/libpvecstatic.so.0.0.0.debug Child return code was: 1 Where is weird because the there is not suppose to be a libpvecstatic.so. So the *spec has: find %{buildroot} -type f -name "*.la" -delete find %{buildroot} -type f -name "libpvec.a" -delete find %{buildroot} -type l -name "libpvecstatic.so" -delete find %{buildroot} -type l -name "libpvecstatic.so.0" -delete find %{buildroot} -type f -name "libpvecstatic.so.0.0.0" -delete find %{buildroot} -type f -name "libpvecstatic.so.0.0.0*.debug" -delete That bit seems to be the problem. Changed -find %{buildroot} -type f -name "libpvecstatic.so.0.0.0*.debug" -delete +find %{buildroot} -type f -name "libpvecstatic.so.0.0.0-*.debug" -delete and it built: https://koji.fedoraproject.org/koji/buildinfo?buildID=1544306 Not sure what is different between rawhide and el7...
So better luck with epel8: https://koji.fedoraproject.org/koji/buildinfo?buildID=1544314 And epel8.playground? https://koji.fedoraproject.org/koji/buildinfo?buildID=1544313 So I think I am complete the F33, el7, and el8: https://koji.fedoraproject.org/koji/packageinfo?packageID=29760 I am not sure what epel8.playground is about. Is this rawhide for EPEL?
FEDORA-EPEL-2020-7c3fde7f74 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7c3fde7f74
FEDORA-EPEL-2020-df3af2a8f8 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-df3af2a8f8
FEDORA-EPEL-2020-df3af2a8f8 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-df3af2a8f8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-7c3fde7f74 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7c3fde7f74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-df3af2a8f8 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-7c3fde7f74 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.