Bug 1735238
Summary: | gdcm: FTBFS in Fedora rawhide/f31 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fedora Release Engineering <releng> | ||||||||
Component: | gdcm | Assignee: | Ankur Sinha (FranciscoD) <sanjay.ankur> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 31 | CC: | igor.raits, jplesnik, kwizart, mhroncok, neuro-sig, sanjay.ankur, sebp, sergio | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | gdcm-2.8.9-2.fc31 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2019-10-26 17:23:36 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | 1733789 | ||||||||||
Bug Blocks: | 1700317, 1732841, 1736365 | ||||||||||
Attachments: |
|
Description
Fedora Release Engineering
2019-07-31 19:17:47 UTC
Created attachment 1596195 [details]
build.log
Created attachment 1596196 [details]
root.log
file root.log too big, will only attach last 32768 bytes
Created attachment 1596197 [details]
state.log
PR ready for merge: https://src.fedoraproject.org/rpms/gdcm/pull-request/5 *** Bug 1716462 has been marked as a duplicate of this bug. *** This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31. The coordinated rebuild of Python 3.8 has started in the `f32-python` side tag. If you figure out how to rebuild this package, please don't rebuild it in regular rawhide, but use the side tag instead: on branch master: $ fedpkg build --target=f32-python To wait for a build to show up in the side tag, do: $ koji wait-repo f32-python --build=<nvr> Where <nvr> is name-version-release of the source package, e.g. python-foo-1.1-2.fc32. An updated mock config is posted at: http://copr.fedorainfracloud.org/coprs/g/python/python3.8/ Note that it will take a while before the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Thanks. Let us know if you need up to date info, or if you have any questions. PS this message is mass posted to all the bugs that block the PYTHON38 bug. If this is also a Fedora 31 FTBFS bug and you manage to fix it, you can do a f31 build as usual: on branch f31: $ fedpkg build Patch was not updated for version 2.8.9 Patch #2 (0002-Increase-xslt-maxdepth.patch): patching file Utilities/doxygen/CMakeLists.txt Hunk #1 FAILED at 252. 1 out of 1 hunk FAILED -- saving rejects to file Utilities/doxygen/CMakeLists.txt.rej The new source was pushed into git in April, but it was build for the first time by F31 mass rebuild commit 91a84ebf380c206214dea4b56f53a60c87ee24c2 Author: Ankur Sinha (Ankur Sinha Gmail) <sanjay.ankur> Date: Thu Apr 11 13:48:37 2019 +0100 Update to 2.8.9: DOES NOT BUILD YET A Python 3.8 rawhide scratchbuild of the f30 branch: https://koji.fedoraproject.org/koji/taskinfo?taskID=37198183 If it builds, I plan to revert to https://src.fedoraproject.org/rpms/gdcm/c/3d3af5e9a9f8948ca3b32d12ebe5d5ecbebf2e52?branch=master Sure---whatever works really. if we are using proven-packager powers, i'd prefer to do the CharLS update and move forwards instead but that will require more toe-stepping than this. Actually, could you give me today to fix the build using a bundled charls? It can be unbundled when chalrs is updated. Thatll be a better/cleaner fix than a revert? Sure. (In reply to Miro Hrončok from comment #9) > A Python 3.8 rawhide scratchbuild of the f30 branch: > https://koji.fedoraproject.org/koji/taskinfo?taskID=37198183 Note that accidentally, this build was not a scratchbuild :( So in theory, gdcm was rebuilt. Except it has a lower version-release. Sorry about that. No worries. Does that mean this bug can be closed now? I'll update to the new version whenever we get the CharLS update then. > Does that mean this bug can be closed now?
I don't think so.
Solution here [1] [1] https://src.fedoraproject.org/rpms/gdcm/pull-request/6 Thanks Sergio. PR merged, built for F31 and the new version for F32/rawhide also. This only fixes the build, and it wasn't python3 related either. So, I don't see a reason to push an update for this. What do you think Sergio, Miro? Ah, no, I wrote that too quickly---we went to 2.8.9 for F31 too, and the patch release includes a soname bump here too. So the deps need rebuilding: (ins)[asinha@ankur-pc gdcm(f31=)]$ sudo dnf repoquery --source --whatrequires 'libgdcm*' Last metadata expiration check: 0:00:29 ago on Sat 21 Sep 2019 12:20:59 BST. InsightToolkit-4.13.1-2.fc31.src.rpm gdcm-2.8.8-5.fc31.src.rpm octave-dicom-0.2.1-2.fc30.src.rpm opencv-3.4.6-6.fc31.src.rpm I've rebuilt ITK already. I'll work on the others now and push a combined update. octave-dicom: done ITK: done opencv: PRs opened for master and F31 (In reply to Ankur Sinha (FranciscoD) from comment #19) > octave-dicom: done > ITK: done > opencv: PRs opened for master and F31 I merged your PR , and redid the Buildroot Override for gdcm-2.8.9-2.fc31 and opencv is building now for F31, to see if we close this bug for F31. Is not clear for me that opencv4 will be in F31, so for now we have one new single commit on F31 ... Sure, opencv4 in f31 is not possible since we are in final freeze today. Unfortunately, you might be late by one day since we will have to request a freeze exeption to have this build updated. FEDORA-2019-75145b258c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-75145b258c It seems like there is no gdcm 2.8.9 updates, is this update dropped ? Should we revert f31 to older gdcm ? No, I was waiting for the OpenCV rebuild. All the packages that needed rebuilding should be pushed as part of the same update, so that they are also pushed to mirrors together. FEDORA-2019-75145b258c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-75145b258c As a note: upstream has confirmed that they do not make ABI changes in patch releases. The soname version has remained 2.8 (they set it to MAJOR.MINOR). However, the abidiff tool did point something out, and I'm not sure where that came from: https://taskotron.fedoraproject.org/artifacts/all/a27eb81c-da03-11e9-bcf0-52540077ca13/tests.yml/gdcm-2.8.9-2.fc31.log So, while this time, we've done the "mass rebuild", in the future we should need them for patch level updates. InsightToolkit-4.13.1-3.fc31, gdcm-2.8.9-2.fc31, octave-dicom-0.2.2-3.fc31, opencv-3.4.6-7.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. |