dee fails to build with Python 3.9.0a5. Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 103, in <module> from giscanner.scannermain import scanner_main File "/usr/lib64/gobject-introspection/giscanner/scannermain.py", line 36, in <module> from giscanner.dumper import compile_introspection_binary File "/usr/lib64/gobject-introspection/giscanner/dumper.py", line 28, in <module> from .gdumpparser import IntrospectionBinary File "/usr/lib64/gobject-introspection/giscanner/gdumpparser.py", line 25, in <module> from xml.etree.cElementTree import parse ModuleNotFoundError: No module named 'xml.etree.cElementTree' This is caused directly by bz1817649. For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01321034-dee/ For all our attempts to build dee with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/dee/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
Even with bz1817649 fixes, dee still fails to build. /usr/bin/vapigen --pkg gio-2.0 --library dee-1.0 --metadatadir=. ../src/Dee-1.0.gir Dee-1.0-custom.vala error: construct properties not supported for specified property type error: construct properties not supported for specified property type Generation failed: 2 error(s), 0 warning(s) This doesn't sound Python 3.9 specific. For the build logs, see: https://download.copr.fedorainfracloud.org/results/@python/python3.9/fedora-rawhide-x86_64/01321346-dee/ For all our attempts to build dee with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/dee/
Pretty sure that failure is caused by vala. Updating my local vala from 0.48.0 (Fedora 32) to 0.48.2 (Fedora Rawhide) triggers this failure. We had a similar failure when Fedora 31 was rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1718278), but it magically disappeared. Presumably due to a fix in vala. By hacking up vapigen a bit, I was able to get it to tell me what those two specified property types are: error: construct properties not supported for specified property type: `Dee.FilterModel.filter` error: construct properties not supported for specified property type: `Dee.Index.reader` But as to how to fix them? I have no clue. If anyone actually understands vala, maybe they can fix this.
There's a Vala 0.48.3 so I can build that for Rawhide and see if this fixes the issue. Should we report it to upstream as well?
Looks like Kalev already built Vala 0.48.3 in Rawhide. Miro can you retry building Dee?
https://koschei.fedoraproject.org/package/dee?collection=f33 shows that Vala 0.48.3 have not made the build succeed.
I wonder if we should retire this. Dee does not seem to have had a stable release for a very long time, but alas there are packages depending on it. ~ ❯ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires dee Fedora - Rawhide - Developmental packages for the next Fedora release 2.0 MB/s | 72 MB 00:35 Fedora - Rawhide - Source 1.1 MB/s | 6.8 MB 00:06 Last metadata expiration check: 0:00:02 ago on Fri 15 May 2020 02:57:09 PM PDT. dee-devel-0:1.2.7-29.fc32.i686 dee-devel-0:1.2.7-29.fc32.x86_64 libunity-0:7.1.4-19.20190319.fc32.i686 libunity-0:7.1.4-19.20190319.fc32.x86_64 zeitgeist-0:1.0.2-2.fc32.x86_64 Alas, libunity is further pulled in by multiple packages. ~ 1m 31s ❯ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires libunity Last metadata expiration check: 0:01:57 ago on Fri 15 May 2020 02:57:09 PM PDT. elementary-files-0:4.4.2-1.fc33.i686 elementary-files-0:4.4.2-1.fc33.x86_64 libunity-devel-0:7.1.4-19.20190319.fc32.i686 libunity-devel-0:7.1.4-19.20190319.fc32.x86_64 python3-libunity-0:7.1.4-19.20190319.fc32.x86_64 vgrive-0:1.6.0-1.fc33.x86_64 vocal-0:2.4.1-3.fc32.x86_64 Let me take a look at what changed in Vala point releases -- it's a bit unfortunate if a breaking change gets introduced this way.
I looked around a bit and this appeared to be already patched in Debian, so I went ahead and backported the fix.
FEDORA-2020-8cdaaf9f0f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8cdaaf9f0f
Kalev, thanks for the fix!
FEDORA-2020-8cdaaf9f0f has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8cdaaf9f0f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8cdaaf9f0f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This comment is mass posted to all bugs blocking the Python 3.9 tracker, sorry if it is not 100 % relevant. When in doubt, please ask. The Python 3.9 rebuild is in progress in a Koji side tag. If you fix this bug, please don't rebuild the package in regular rawhide, but do it in the side tag with: $ fedpkg build --target=f33-python The rebuild is progressing slowly and it is possible this package won't have all the required build dependencies yet. If that's the case, please just leave the fix committed and pushed and we will eventually rebuild it for you. You are not asked to go and try rebuild all the missing dependencies yourself. If you know there is a bootstrap loop in the dependencies, let me know and we can untangle it together. If you want to test your fix or reproduce the failure, you can still use the Copr repo mentioned in the initial comment of this bug: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/
FEDORA-2020-8cdaaf9f0f has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.