[Sugar-devel] Bug 1240354 - SoaS live x86_64 20150706 does not login from live system user

Jerry Vonau me at jvonau.ca
Tue Sep 1 22:03:28 EDT 2015

> On September 1, 2015 at 3:39 PM "Sam P." <sam at sam.today> wrote:
> No, that is exactly the same issue.  If you open the log attached <
> https://bugzilla.redhat.com/attachment.cgi?id=1048658> you'll see
> "GLib.Error: g-invoke-error-quark: Could not locate acme_volume_alsa_new:
> 'acme_volume_alsa_new': /lib64/libsugar-eventcontroller.so.0: undefined
> symbol: acme_volume_alsa_new (1)"
> As noted on <https://bugzilla.redhat.com/show_bug.cgi?id=1240147>, this
> bug
> is very weird because it works 100% if you copy the libs compiled by
> sugar-build.

Sam, where are you copying the 'lib' files to? /lib, /lib64, /usr/lib, or

> "Failed to load shared library 'libsugarext.so.0' referenced by the
> typelib: /lib/libsugarext.so.0: undefined"

Based on Peter's response in bugzilla this should be /usr/lib{64} as
needed. Think the difference will be between sugar-build's layout and
mock/rpmbuild for rpms. Here are links to the latest rpm logs: 


Question for Peter, I don't fully understand why at the rpm macro level
%configure spits out the libs to %_libdir in the toolkit spec file and the
same %configure call in sugar's spec has the resulting rpms looking in
%_lib. Just digging into the black art voodoo of rpm packaging a little
That leads me to think if sugar is building against a library that is only
available in sugar's toolkit should the toolkit be declared as a
BuildRequires and be pulled into the BuildRoot for sugar? Is that kind of
thing sorted out at the rpm macro level anyway, or is some tweak to
%configure is needed somewhere? Trying to brush up on the finer points of
packaging for my own education.

More information about the Sugar-devel mailing list