Bug 1507661

Summary: gdbus-codegen fails
Product: Red Hat Enterprise Linux 7 Reporter: Matěj Cepl <mcepl>
Component: glib2Assignee: Colin Walters <walters>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: herrold, mats, mcepl, tpelka
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 13:06:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1508056    
Bug Blocks:    
Attachments:
Description Flags
proposed patch none

Description Matěj Cepl 2017-10-30 20:36:33 UTC
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 21:40:04 UTC
Created attachment 1345637 [details]
proposed patch

Comment 3 Colin Walters 2017-10-31 14:25:58 UTC
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 15:10:11 UTC
(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 16:54:51 UTC
We actually need https://bugzilla.gnome.org/show_bug.cgi?id=789723 too.

Comment 7 Colin Walters 2017-10-31 17:54:43 UTC
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 17:33:21 UTC
Note the same issue appeared in bug 1485853 on the Fedora side.

Comment 16 errata-xmlrpc 2018-04-10 13:06:05 UTC
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