Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 117488 - app-misc/alexandria needs glade_module_register_widgets or crash with solution
Summary: app-misc/alexandria needs glade_module_register_widgets or crash with solution
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: John Keeping
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-02 13:59 UTC by Aymeric Nys
Modified: 2008-04-28 19:44 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aymeric Nys 2006-01-02 13:59:11 UTC
aymeric@veckman ~ $ alexandria
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: line 21
   libglade-WARNING **:could not find `gnome' init function:
`glade_module_register_widgets': /usr/lib/libgnome-2.so.0: undefined
symbol: glade_module_register_widgets
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: line 21
   libglade-WARNING **:could not find `bonobo' init function:
`glade_module_register_widgets': /usr/lib/libbonobo-2.so.0: undefined
symbol: glade_module_register_widgets
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: line 21
   libglade-WARNING **:unknown property `enable_layout_config' for class
`GnomeApp'
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: line 21
   libglade-WARNING **:could not find a parent that handles internal
children for `dock'
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: line 21
   libglade-WARNING **:could not find a parent that handles internal
children for `appbar'
-----------------------
Alexandria just crashed
-----------------------
Timestamp: ven d?c 30 14:20:53 EST 2005
Message: undefined method `model=' for nil:NilClass
Backtrace:
/usr/lib/ruby/site_ruby/1.8/alexandria/ui/main_app.rb:358:in
`setup_books_listview'
/usr/lib/ruby/site_ruby/1.8/alexandria/ui/main_app.rb:1106:in
`initialize_ui'
/usr/lib/ruby/site_ruby/1.8/alexandria/ui/main_app.rb:85:in `initialize'
/usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:41:in `main'
/usr/lib/ruby/site_ruby/1.8/alexandria.rb:66:in `main'
/usr/bin/alexandria:10
Release: 0.6.1

Uname -a: Linux veckman 2.6.14-gentoo-r2n #1 PREEMPT Thu Dec 29 16:25:10
EST 2005 ppc 7455, altivec supported PowerBook6,3 GNU/Linux

I use alexandria-0.6.1, ruby-1.8.4, ruby-gnome2, ruby-libglade-0.14.1

Solutions available at this address: http://xlife.zuavra.net/curse/0010/
What I did is to put file in /etc/env.d whith LDPATH="/usr/lib/libglade/2.0/"
in it, type env-update and then everything is fine.
Comment 1 foser (RETIRED) gentoo-dev 2006-03-11 09:04:09 UTC
I assume that your libs/apps are all installed in their default locations, not some other root ?
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-07-30 14:35:29 UTC
Re-assign, maintainer retired.
Comment 3 Hans de Graaff gentoo-dev Security 2007-11-18 07:59:42 UTC
Re-assign back to maintainer-needed. The fact that it's written in Ruby is really no reason to assign the bug to the ruby herd, and we're understaffed as it is. 
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2007-11-18 09:03:51 UTC
(In reply to comment #3)
> Re-assign back to maintainer-needed. The fact that it's written in Ruby is
> really no reason to assign the bug to the ruby herd, and we're understaffed as
> it is. 

Then perhaps remove ruby from metadata.xml? ;) 

Comment 5 Carsten Lohrke (RETIRED) gentoo-dev 2008-01-08 00:32:35 UTC
So no one wants this? Are there more/better book collections for the Gnome desktop? If no one speaks up, I'll mask it for removal. There has been a new version released recently, so this application is not an abandoned one.
Comment 6 Tobias Scherbaum (RETIRED) gentoo-dev 2008-03-09 19:03:08 UTC
(In reply to comment #5)
> So no one wants this? Are there more/better book collections for the Gnome
> desktop? If no one speaks up, I'll mask it for removal. There has been a new
> version released recently, so this application is not an abandoned one.
> 

alexandria got a proxy-maintainer lately, see metadata.xml - no need to mask it for removal.
Comment 7 Hans de Graaff gentoo-dev Security 2008-03-10 05:42:38 UTC
I just added alexandria 0.6.2 to the tree this weekend. It would be great if someone can confirm that this version fixes this problem, so that we can close this bug.
Comment 8 Adrian Bassett 2008-04-25 14:31:03 UTC
(In reply to comment #7)
> I just added alexandria 0.6.2 to the tree this weekend. It would be great if
> someone can confirm that this version fixes this problem, so that we can close
> this bug.
> 

I am new to alexandria, not to mention ruby, etc.  However, I have just installed alexandria 0.6.3.  Until I created a file in /etc/env.d as per the suggestion in comment #1 re LDPATH the program wouldn't run.  With a suitable file in place the program ran (after an env-update) but produced the following warning:

'Can't load hpricot, hence provider Amazon not available'

After emerging dev-ruby/hpricot the program starts up without complaint.

Therefore, the ebuild for alexandria should create a suitable file in /etc/env.d  that modifies the LDPATH appropriately (thinks:  perhaps that should be the job of gnome-base/libglade?);  it should also depend on dev-ruby/hpricot.

Hope these comments help.
Comment 9 Adrian Bassett 2008-04-25 18:35:56 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > I just added alexandria 0.6.2 to the tree this weekend. It would be great if
> > someone can confirm that this version fixes this problem, so that we can close
> > this bug.
> > 
> 
> I am new to alexandria, not to mention ruby, etc.  However, I have just
> installed alexandria 0.6.3.  Until I created a file in /etc/env.d as per the
> suggestion in comment #1 re LDPATH the program wouldn't run.  With a suitable
> file in place the program ran (after an env-update) but produced the following
> warning:
> 
> 'Can't load hpricot, hence provider Amazon not available'
> 
> After emerging dev-ruby/hpricot the program starts up without complaint.
> 
> Therefore, the ebuild for alexandria should create a suitable file in
> /etc/env.d  that modifies the LDPATH appropriately (thinks:  perhaps that
> should be the job of gnome-base/libglade?);  it should also depend on
> dev-ruby/hpricot.
> 
> Hope these comments help.
> 
I have just installed alexandria on a separate system and now see that the ebuild does point out the need to emerge separate packages (including hpricot) to enable certain book providers (this information had just scrolled off, earlier).  However, I didn't have either mechanize or ruby-zoom installed at that time and there weren't warnings about the book providers that these packages enable, which is perhaps a bit inconsistent.  Are we looking at the need for USE flags here, or is that a bit over-the-top?

Sorry if I caused any confusion with my earlier comments.
Comment 10 Adrian Bassett 2008-04-25 18:52:48 UTC
(In reply to comment #8)

> > ... Until I created a file in /etc/env.d as per the
> > suggestion in comment #1 re LDPATH the program wouldn't run.  With a suitable
> > file in place the program ran (after an env-update) ...

This appears to be the case with ~amd64 (the first arch I installed on) which works once LDPATH="/usr/lib/libglade/2.0/" is added to the library search path.  On ~x86 libglade libraries are in /usr/lib so presumably no env.d file modifications are necessary.
Comment 11 Hans de Graaff gentoo-dev Security 2008-04-26 06:32:42 UTC
Assigning to John Keeping as he is now updating the alexandria ebuilds.
Comment 12 John Keeping 2008-04-26 11:10:31 UTC
I can't recreate this on my system whatever I try with the latest stable versions of all the relevant libraries. I'm on an AMD64 system and have /usr/lib -> /usr/lib64 symlinked. Can you post what your /usr/lib points to? Also, have you tried running revdep-rebuild, without the modified LDPATH in your environment?

Have you noticed problems with any other applications? A lot of things seem to depend on libglade and I can't see why Alexandria would break without other things breaking as well.

From the post at http://xlife.zuavra.net/index.php/52/ from comment #1 it looks like the correct solution is exporting LIBGLADE_MODULE_PATH set to an appropriate value, but I don't think it makes sense for Alexandria to do this, it should probably be done by libglade if it fixes the problem.

The issue of USE flags vs. comments post-install is discussed in bug #215337.
Comment 13 Adrian Bassett 2008-04-28 10:41:57 UTC
(In reply to comment #12)
> I can't recreate this on my system whatever I try with the latest stable
> versions of all the relevant libraries. 

I'm on ~amd64, i.e. the 'testing' branch of the arch, so perhaps there's a difference there?  However, I've removed the env.d entry and can't now recreate the problem.  All that's changed as far as alexandria is concerned is that dev-ruby/mechanize and dev-ruby/ruby-zoom have been emerged.  Maybe that explains things - sorry, I don't have time to try un-emerging these and testing further.

>I'm on an AMD64 system and have
> /usr/lib -> /usr/lib64 symlinked. Can you post what your /usr/lib points to?

lrwxrwxrwx 1 root root 5 Jan 22 13:01 /usr/lib -> lib64

> Also, have you tried running revdep-rebuild, without the modified LDPATH in
> your environment?

Yes, revdep-rebuild has been run since the most recent emerge of liblagde and before that of alexandria (and the associated changed in LDPATH) without anything showing.
 
> Have you noticed problems with any other applications? A lot of things seem to
> depend on libglade and I can't see why Alexandria would break without other
> things breaking as well.

No, I have 60+ apps that depend on libglade (equery depends libglade) and have not had other failures AFAICR.
 
> From the post at http://xlife.zuavra.net/index.php/52/ from comment #1 it looks
> like the correct solution is exporting LIBGLADE_MODULE_PATH set to an
> appropriate value, but I don't think it makes sense for Alexandria to do this,
> it should probably be done by libglade if it fixes the problem.

I agree an application-specific env. variable would be preferable.

> The issue of USE flags vs. comments post-install is discussed in bug #215337.

Had a quick look at that and can see the argument about USE flags for compile- as opposed to run-time dependencies.

But making USE flags available for adding functionality seems sensible where that implies installing other packages.  The output from 'emerge -pv alexandria' should give a rounded view of the program's capabilities so, e.g., if you want a z39.50 capability then select Z3950 (or whatever name).  If you don't, then don't.

This is desirable even if the extra functionality can be added later by installing other packages;  i.e. USE flags are how you know (at a certain level) what the capabilities of a program are and how you say how much of those you want installed and available.




Comment 14 John Keeping 2008-04-28 18:24:20 UTC
I didn't have dev-ruby/mechanize or dev-ruby/ruby-zoom installed during my testing, so it looks like this has been solved by something external.

As there's no way to know if anything I change fixes this now that you don't have the problem any more, I'm going to close this WORKSFORME.

For USE flags, I think you're right. The difference between Alexandria and Git is that the additional packages give Alexandria itself more functionality, but for Git they provide interoperability with the external programs. I won't change this for the current version, but from recent posts on the Alexandria mailing-list it looks like 0.6.4 will be out soon and I'll move to USE for that providing Hans agrees.
Comment 15 Adrian Bassett 2008-04-28 19:44:14 UTC
Thanks.  I'll try the new version as and when it appears in portage.