gdcm failed to build from source in Fedora rawhide/f31
For details on the mass rebuild see:
Please fix gdcm at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
gdcm will be orphaned. Before branching of Fedora 32,
gdcm will be retired, if it still fails to build.
For more details on the FTBFS policy, please visit:
Created attachment 1596195 [details]
Created attachment 1596196 [details]
file root.log too big, will only attach last 32768 bytes
Created attachment 1596197 [details]
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:
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
Author: Ankur Sinha (Ankur Sinha Gmail) <email@example.com>
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?
(In reply to Miro Hrončok from comment #9)
> A Python 3.8 rawhide scratchbuild of the f30 branch:
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 
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.
I've rebuilt ITK already. I'll work on the others now and push a combined update.
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.
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.