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.