Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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.
I assume that your libs/apps are all installed in their default locations, not some other root ?
Re-assign, maintainer retired.
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.
(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? ;)
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.
(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.
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.
(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.
(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.
(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.
Assigning to John Keeping as he is now updating the alexandria ebuilds.
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.
(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.
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.
Thanks. I'll try the new version as and when it appears in portage.
