Re: [Nautilus-list] Nautilus Issues



>> 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]