Bug 1675699 - pyexiv2: FTBFS in Fedora rawhide/f30
Summary: pyexiv2: FTBFS in Fedora rawhide/f30
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pyexiv2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F30FTBFS
TreeView+ depends on / blocked
 
Reported: 2019-02-11 21:31 UTC by Fedora Release Engineering
Modified: 2023-09-14 04:49 UTC (History)
5 users (show)

Fixed In Version: pyexiv2-0.3.2-40.fc31
Clone Of:
Environment:
Last Closed: 2019-05-22 07:42:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (1.00 KB, text/plain)
2019-02-11 21:31 UTC, Fedora Release Engineering
no flags Details
root.log (1.00 KB, text/plain)
2019-02-11 21:31 UTC, Fedora Release Engineering
no flags Details
state.log (625 bytes, text/plain)
2019-02-11 21:31 UTC, Fedora Release Engineering
no flags Details
patch to build on f30 (3.55 KB, patch)
2019-05-22 03:22 UTC, scott
no flags Details | Diff

Description Fedora Release Engineering 2019-02-11 21:31:11 UTC
pyexiv2 failed to build from source in Fedora rawhide/f30

https://koji.fedoraproject.org/koji/taskinfo?taskID=32452401


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
Please fix pyexiv2 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,
pyexiv2 will be orphaned. Before branching of Fedora 31,
pyexiv2 will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://fedoraproject.org/wiki/Fails_to_build_from_source

Comment 1 Fedora Release Engineering 2019-02-11 21:31:13 UTC
Created attachment 1532121 [details]
build.log

file build.log too big, will only attach last 1024 bytes

Comment 2 Fedora Release Engineering 2019-02-11 21:31:15 UTC
Created attachment 1532122 [details]
root.log

file root.log too big, will only attach last 1024 bytes

Comment 3 Fedora Release Engineering 2019-02-11 21:31:16 UTC
Created attachment 1532123 [details]
state.log

Comment 4 Zbigniew Jędrzejewski-Szmek 2019-03-03 14:36:09 UTC
Should pyexiv4 be retired? It's dead upstream since ~2012 and upstream recommends GExiv2 instead.

Comment 5 Zbigniew Jędrzejewski-Szmek 2019-03-03 14:37:16 UTC
Stuff that needs pyexiv2:
$ dnf repoquery --whatrequires pyexiv2 --releasever=rawhide
jbrout-0:0.4-0.21.git20140930reva7c8fb8.fc30.noarch
pony-0:0.4-18.fc30.noarch
rapid-photo-downloader-0:0.4.11-10.fc29.noarch

Comment 6 Peter Lemenkov 2019-03-04 14:07:50 UTC
jbrout is switching to py3 (and to Gobject https://gitlab.com/jbrout/jbrout/merge_requests/7), rapid-photo-downloader package is horribly outdated (https://launchpad.net/rapid/pyqt).

Where can I download Pony's source code - I still don't know. Looks like abandonware to me.

Comment 7 Fedora Release Engineering 2019-04-26 23:31:19 UTC
Dear Maintainer,

your package has not been built successfully in f30. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
can be orphaned if this bug remains in NEW state more than 8 weeks.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Comment 8 scott 2019-05-22 03:22:21 UTC
Created attachment 1571780 [details]
patch to build on f30

quick&dirty patch to get pyexiv2 to build on f30.

Comment 9 Zbigniew Jędrzejewski-Szmek 2019-05-22 07:26:02 UTC
Built in rawhide. Let's close this. Ideally the package would be retired, but as long as there are dependencies, it's less disruptive to keep it in zombie state.

Comment 10 Red Hat Bugzilla 2023-09-14 04:49:32 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.