Bug 1507661 - gdbus-codegen fails
gdbus-codegen fails
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glib2 (Show other bugs)
7.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Colin Walters
Desktop QE
: Reopened
Depends On: 1508056
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-30 16:36 EDT by Matěj Cepl
Modified: 2018-05-17 10:39 EDT (History)
4 users (show)

See Also:
Fixed In Version: glib2-2.54.1-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 09:06:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (577 bytes, patch)
2017-10-30 17:40 EDT, Matěj Cepl
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0770 None None None 2018-04-10 09:07 EDT

  None (edit)
Description Matěj Cepl 2017-10-30 16:36:33 EDT
Description of problem:
matej@mitmanek: ~$ gdbus-codegen --help
Traceback (most recent call last):
  File "/bin/gdbus-codegen", line 41, in <module>
    from codegen import codegen_main
ImportError: No module named codegen
matej@mitmanek: ~$

Version-Release number of selected component (if applicable):
glib2-devel-2.54.0-1.el7_4.x86_64

How reproducible:
100%

Additional info:
The problem lies in the /bin/gdbus-codegen script itself:

elif os.path.basename(filedir) == 'bin':
    # Make the prefix containing gdbus-codegen 'relocatable' at runtime by
    # adding /some/prefix/bin/../share/glib-2.0 to the python path
    path = os.path.join(filedir, '..', 'share', 'glib-2.0')

must fail to do The Right Thing™ when it is in /bin/ instead of /usr/bin/ as apparently expected.
Comment 2 Matěj Cepl 2017-10-30 17:40 EDT
Created attachment 1345637 [details]
proposed patch
Comment 3 Colin Walters 2017-10-31 10:25:58 EDT
Thanks for the bug report and patch!  I did a quick annotate on git upstream and
saw:

https://git.gnome.org/browse/glib/commit/?id=b9f2ea423526735f7fe7371fb1339eae91a618c2

Let's backport that instead?
Comment 4 Matěj Cepl 2017-10-31 11:10:11 EDT
(In reply to Colin Walters from comment #3)
> Thanks for the bug report and patch!  I did a quick annotate on git upstream
> and saw:
> 
> https://git.gnome.org/browse/glib/commit/
> ?id=b9f2ea423526735f7fe7371fb1339eae91a618c2
> 
> Let's backport that instead?

Sounds a way better. That algorithm of looking for the proper dir with libraries is in my opinion too brittle, and after all when building the package we know where all those files will go.
Comment 5 Colin Walters 2017-10-31 12:54:51 EDT
We actually need https://bugzilla.gnome.org/show_bug.cgi?id=789723 too.
Comment 7 Colin Walters 2017-10-31 13:54:43 EDT
Not going to go through the hoops to get a pm_ack for this, it should be fixed in the current build, please reopen/comment/send smoke signal it still doesn't work or there are any other issues.  Thanks!
Comment 10 Mats Wichmann 2017-11-08 12:33:21 EST
Note the same issue appeared in bug 1485853 on the Fedora side.
Comment 16 errata-xmlrpc 2018-04-10 09:06:05 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0770

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