Re: [Nautilus-list] Nautilus Issues
- From: Ali Abdin <aliabdin aucegypt edu>
- To: nautilus-list lists eazel com
- Subject: Re: [Nautilus-list] Nautilus Issues
- Date: Sat, 13 May 2000 06:19:24 +0300
>> 3) The current .spec.in file is /VERY/ outdated. It doesn't allow you to even
>> create RPMS :) I have enclosed a more 'accurate' .spec and .spec.in file.
>> Could someone update CVS with this? It creates RPMs correctly (at least on my
>> system). Oh another thing - I have debug enabled and commented out the
>> stripping stuff. This should be taken out (or better yet, kept 'as is' until
>> your 1.0 release - for better quality bug reports). The .spec.in file before
>> was also a bit inaccurate in some stuff so I fixed it out (it left some files
>> installed and wasn't correct for i18n stuff, according to the million other
>> GNOME .spec files I've seen)
> Ramiro is building RPMs, so he must have good spec files. I think he might
> not have checked them in for some reason of his own.
According to Ramiro (from IRC) this is not so. He said he'd look at my
.spec.in file later
>> 4) Apparently --enable-debug=yes does not set the '-g' in the Makefile CFLAGS
>> so now there is no real debugging info for gdb :( This means my below bug
>> report is probably not very useful :(
> That's not right. We have -g in our builds. There must be some other problem
> in your configuration. I think we just use the standard GNOME macros
> directory for this. Nothing Nautilus-specific about how we get "-g" set.
Apparently it was a problem with my side :) It is quite complicated to explain
I had hacked the RPMs to include --enable-debug=yes, then I accidently
copied over the origina nautilus ones, and compiled with that - then
I realized the spec file was broke, so instead of recompiling again
I just tar'd the nautilus rpm builddir with a fixed spec file and kept
trying until I got it right (avoiding rebuilding and stuff since all the
.o files were there)
>> 5) On startup - I get a couple of errors :)
>>
>> a) Gtk-CRITICAL **: file gtkcontainer.c: line 715 (gtk_container_add):
>> assertion `widget->parent == NULL' failed.
> I can't reproduce this. Maybe you can run it under gdb and get a backtrace.
> Nautilus turns criticals and warnings into "drop into debugger" events, but
> only if you are running under the debugger (no core dumps).
Umm - this "drop into debugger" thing doesn't work for me. If I get criticals
or whatever it continues to function pretty normally under gdb :)
Looking at the source code in ntl-main.c:
if (getenv ("NAUTILUS_DEBUG") != NULL) {
nautilus_make_warnings_and_criticals_stop_in_debugger
(G_LOG_DOMAIN, g_log_domain_glib, "Gdk", "Gtk", "GnomeVFS", "GnomeUI", "Bonobo", NULL);
}
I assume I should set the NAUTILUS_DEBUG environment first :)
First of all, I only get this if starting up using the 'eazel' icons.
Secondly, it doesn't stop in debugger upon criticlals, only upon
warnings apparently :(
Actually it stopped on this:
** CRITICAL **: file oaf-activate.c: line 123 (oaf_activate_from_id): assertion `ac' failed.
but not on this:
Gtk-CRITICAL **: file gtkcontainer.c: line 715 (gtk_container_add): assertion `widget->parent == NULL' failed.
Sorry - its 6:17AM and i'm really tired so I have no desire to debug it
further at this time (sleeeeeep)
>> b) ** WARNING **: Unable to find handler for file: /home/aliabdin/tutorial.xcf
> Same here. I can't even find this warning ("Unable to find handler") in our
> source code.
I found the problem :) the error message comes from gdk-pixbuf
Specifically - gdk_pixbuf_new_from_file () at gdk-pixbuf-io.c:195
It appears nautilus detects it as an image and tries to get gdk-pixbuf to
handle it, regardless of whether gdk-pixbuf can. Here is a limited backtrace:
#5 0x405b4ffc in gdk_pixbuf_new_from_file () at gdk-pixbuf-io.c:195
#6 0x406b1af5 in load_specific_image () from /usr/lib/libnautilus-extensions.so.0
#7 0x406b2254 in get_image_from_cache () from /usr/lib/libnautilus-extensions.so.0
#8 0x406b1bad in load_image_for_scaling () from /usr/lib/libnautilus-extensions.so.0
#9 0x406b1fb0 in load_image_scale_if_necessary () from /usr/lib/libnautilus-extensions.so.0
#10 0x406b2299 in get_image_from_cache () from /usr/lib/libnautilus-extensions.so.0
#11 0x406b23bb in nautilus_icon_factory_get_pixbuf_for_icon () from /usr/lib/libnautilus-extensions.so.0
#12 0x406aced2 in nautilus_icon_container_update_icon () from /usr/lib/libnautilus-extensions.so.0
#13 0x406a931c in icon_new () from /usr/lib/libnautilus-extensions.so.0
#14 0x406ad247 in nautilus_icon_container_add_auto () from /usr/lib/libnautilus-extensions.so.0
#15 0x806cc5e in add_icon_at_free_position ()
#16 0x806d649 in display_icons_not_already_positioned ()
#17 0x806d806 in fm_icon_view_done_adding_files ()
>> 6) I right-click on a file and then go to emblems - Sometimes when I click on
>> a checkbox it 'locks up' nautilus solidly. How to repeat: load up nautilus and
>> keep randomly clicking on the emblems. It is not easy to repeat though
>> (although if I just keep emblem clicking it will eventually happen). I /think/
>> that it might be related to how fast I click (some sort of race?)
> I tried this and found a bug (double delete) that I fixed. I don't know if
> it's the same bug you ran into.
I'll try latest CVS when I get a chance
>> 5) When I use choose Customize, choose emblems, and then try to drag it onto
>> an icon a segfault - here are the error messages and necessary debug info:
>>
>> This is the message I get before the segfault
>> ** ERROR **: file nautilus-icon-dnd.c: line 1119 (drag_drop_callback):
>> assertion failed: (dnd_info->got_data_type)
>> aborting...
> I don't have time to look at this one right now. I'll probably make a
> Bugzilla bug report about it later and get someone else to look at it
Okay thanks - sorry I couldn't do this myself
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]