gnome-utils: port outdated, replaced by new individual GNOME packages, maintainers wanted.

[dbevans (David B. Evans)]

gnome-utils is outdated and has not been updated since GNOME 3.2. In the current GNOME 3.10 distribution, it has been replaced by individual packages for the utilities that have been carried forward. This is a good opportunity for developers wanting to contribute to MacPorts' GNOME3 coverage by contributing one or more of these missing ports.

Utilities provided by the current gnome-utils port are

baobab (DISABLED)
gnome-dictionary (DISABLED)
gnome-font-viewer
gnome-panel-screenshot
gnome-screenshot
gnome-search-tool
gnome-system-log
gnome-thumbnail-font

Equivalent packages provided in the current GNOME 3.10 distribution are

baobab (previously part of gnome-utils) (COMPLETED juanrgar@)
gnome-dictionary (previously part of gnome-utils) (COMPLETED juanrgar@)
gnome-font-viewer (previously part of gnome-utils)
gnome-screenshot (previously part of gnome-utils)
gnome-system-log (previously part of gnome-utils)

The following utilities are obsolete, are not provided by GNOME 3.10 and will disappear when gnome-utils is fully replaced

gnome-panel-screenshot
gnome-search-tool
gnome-thumbnail-font

If you are interested in responding to this request, I suggest the following procedure

• Indicate your intent in a comment to this ticket
• Create a new port for your submission.
• To prevent a conflict, modify the existing gnome-utils port to disable building of the outdated equivalent of your port, add your port in depends_run and revbump.
• Modify the existing gnome3-core port by moving your port from the commented list of unported packages to depends_lib and revbump.

If you don't have commit privileges you can post your new Portfiles here for review and committal. Otherwise, post a comment here when you have completed the above steps.

Let me know if you have any questions or suggestions and thanks for any help you can provide.

[cooljeanius (Eric Gallager)]

Cc Me!

[juanrgar (Juan R. García Blanco)]

Cc Me!

[juanrgar (Juan R. García Blanco)]

I've created a Portfile for baobab@3.10.1. It builds and runs ok on OSX 10.9, as far as I've tested it. GNOME's new approach to applications, global menu and merged toolbar-decoration, seem to cause some problems here: once the window is maximised I've not found a way to unmaximise it properly; this is not strictly related to the port though.

I've created a patch to gnome3-core's Portfile. However, I don't know what to do with gnome-utils' Portfile; I've not found a way to disable compilation of baobab through a configure flag. I guess it requires patching configure.ac and Makefile.am, but please correct me if I'm wrong.

[juanrgar (Juan R. García Blanco)]

baobab Portfile

[dbevans (David B. Evans)]

The baobab Portfile looks good from here. I think the minimizing issue has to do with the fact that it is not running in a proper GNOME session.

With respect to gnome3-core, you've made the appropriate changes but I would prefer that you keep the dependencies in alphabetical order so its easier to find a particular port.

With respect to gnome-utils, I agree you need to patch it to disable baobab. Since each utility is built in a separate subdir all you need to do is remove baobab from the SUBDIRS declaration in Makefile.am and remove any baobab specific dependencies check in configure.ac. The port is already built with autoreconf so you don't need to change anything there.

I'm leaving the office right now but I'll test build the port and commit it when I get home this evening.

Thanks for your help.

[juanrgar (Juan R. García Blanco)]

gnome3-core Portfile patch to add baobab

[juanrgar (Juan R. García Blanco)]

gnome-dictionary Portfile

[juanrgar (Juan R. García Blanco)]

baobab and gnome-dictionary added to gnome3-core

[juanrgar (Juan R. García Blanco)]

gnome-utils patches to not compile and install baobab and gnome-dictionary

[juanrgar (Juan R. García Blanco)]

I've added a gnome-dictionary Portfile. I've also updated gnome3-core patch to add both baobab and gnome-dictionary. Also attached is a set of patches to gnome-utils that prevent baobab and gnome-dictionary inside gnome-utils from compiling and installing.

[dbevans (David B. Evans)]

baobab committed in r115683
gnome-dictionary committed in r115684
gnome-utils changes committed in r115685 (disable outdated baobab and gnome-dictionary and depend on the new versions)
gnome3-core updated to include baobab and gnome-dictionary in r115693

I made a few dependency changes (using configure/configure.ac as guide to required dependencies), fixed license info (multiple licenses are separated by spaces not commas), and added a pre-activate phase to baobab and gnome-dictionary to guard against activation errors when upgrading gnome-utils after this change. Finally had to make a few further fixes to baobab to get it to build on the Lion and SL buildbots (r115688, r115692).

Let me know if you have any questions about any of this.

Thanks again for your submissions

[juanrgar (Juan R. García Blanco)]

Thank you! The dependency on vala was pretty obvious, sorry. Just a quick question: dbus and dconf aren't dependencies for both baobab and gnome-dictionary because they don't make use of dbus and dconf API directly, right? Also, dconf "shouldn't" be a dependency on OSX since I think plists are used as gsettings backend instead. For the dbus case I can't find the port in the dependency chain that triggers dbus installation; I'd expect glib2 to depend on dbus but that's not the case.

Also, the buildbot is accessed through ​https://build.macports.org/, right?

Thank you in advance.

[dbevans (David B. Evans)]

Yes on all the above. WRT dbus, it is necessary (if you don't have it installed and running many GNOME apps will complain) but the preferred API to talk to dbus is GDbus (part of gio provided by glib2) and it only needs to know how to find the address (socket) for the dbus instance you want to talk to in order to work.

gsettings does have a native OS X backend and you'd think that means that you wouldn't need dconf but there are some ports that depend on it explicitly so it's sometimes needed and the two work with each other transparently.

At any rate, for dependencies, I recommend to be guided by what is tested at configure time plus anything else that is necessary for the build.

WRT buildbots, ​https://build.macports.org/waterfall gives a useful display of whats going on there.

So two down and 3 to go for this ticket.

[juanrgar (Juan R. García Blanco)]

gnome-system-log Portfile

[juanrgar (Juan R. García Blanco)]

Add gnome-system-log to gnome3-core depends_lib

[juanrgar (Juan R. García Blanco)]

Added gnome-system-log.

gnome-screenshot is giving me some trouble: it runs without a problem but it does nothing... even if I have some other X11 windows currently open. I need to investigate this a little more.

[juanrgar (Juan R. García Blanco)]

Disable logview (gnome-system-log) in gnome-utils

[juanrgar (Juan R. García Blanco)]

gnome-system-log@3.9.90

[juanrgar (Juan R. García Blanco)]

Just added Portfile for gnome-system-log@3.9.90 after realising that despite being odd-numbered it's the version that Fedora 20 ships with.

[dbevans (David B. Evans)]

Replying to juanrgar@…:

Added gnome-system-log.

gnome-screenshot is giving me some trouble: it runs without a problem but it does nothing... even if I have some other X11 windows currently open. I need to investigate this a little more.

it is run by gnome-session when it launches and I currently have it disabled in the gnome-flashback session provided by gnome-panel because of it's unavailability. I doubt that it will work without window manager support from a gnome-session (just based on my idea of what it should do). Let me know what you find out.

[dbevans (David B. Evans)]

Replying to juanrgar@…:

Just added Portfile for gnome-system-log@3.9.90 after realising that despite being odd-numbered it's the version that Fedora 20 ships with.

Yes, that's the version included in the official GNOME 3.10.2 release. See versions.txt installed with gnome3-core which is the official list of package versions to be included in the release as provided by GNOME Release Engineering. Also can be found ​here.

[dbevans (David B. Evans)]

gnome-system-log committed in r115819.
gnome-utils related updates committed in r115820.
gnome3-core related updates committed in r115821.

[juanrgar (Juan R. García Blanco)]

gnome-font-viewer added to gnome3-core

[juanrgar (Juan R. García Blanco)]

gnome-font-viewer Portfile

[juanrgar (Juan R. García Blanco)]

Remove font-viewer from gnome-utils

[juanrgar (Juan R. García Blanco)]

Added gnome-font-viewer. In my system it shows no fonts; I don't know if this is expected behaviour or something else should be done.

[dbevans (David B. Evans)]

I thought the same time and ran the port in gdb to see what was happening. The end result was that it is working just does a lot of font processing before it starts drawing any fonts. On my system it takes 30 seconds from the time the blank window appeared to the time fonts started rendering. Admittedly there are a lot of fonts. It initially gets the list of font directories from fontconfig and then processes all the fonts in those directories before drawing. I count 33 directories with over 5000 fonts. So start it up, go get a cup of tea and see if there are any fonts when you get back.

Based on this, I vote to commit the port as-is, but it's up to you. Let me know.

BTW, any progress on gnome-screenshot? Why not post your current Portfile and we can both try and see what the issue is. As I said before, I'm not sure how it's supposed to work within the GNOME session.

[juanrgar (Juan R. García Blanco)]

You're right; it took a few seconds to load all the fonts. Of course if you think it's ok to commit it, just commit, you're the master ;)

Regarding gnome-screenshot I've been busy these weeks and I've not done any progress. So yeah, I'll upload it. What I've observed is that when I launch it, although it does not display any window, it does take a screenshot and saves it under ~/Pictures. However, even if I have other X11 apps open, the picture is all black.

[juanrgar (Juan R. García Blanco)]

gnome-screenshot Portfile

[juanrgar (Juan R. García Blanco)]

I've found that if I ask gnome-screenshot to display a window, and then take a screenshot, it crashes during initialising the file chooser dialog :(

[juanrgar (Juan R. García Blanco)]

When taking a screenshot of the whole screen, gnome-screenshot crashes in gtk_file_chooser_default_init while creating the dialog from a .ui file. Therefore, I get rid of the GtkFileChooserButton in the .ui file, and now that does not crash. I don't know what can be wrong since I guess the XDG stuff works ok on OSX. But, when in the save screenshot dialog (without GtkFileChooserButton) I tried to display the about dialog, it crashed again... and also while parsing a .ui file. So maybe there's something wrong with these particular .ui files, since I think other applications use GtkBuilder too and they run ok. Please find attached the relevant backtrace:

frame #0: 0x00007fff8f32cd13 libsystem_platform.dylib`_platform_strcmp + 19 frame #1: 0x0000000100aad660 libglib-2.0.0.dylib`g_str_equal + 9 frame #2: 0x0000000100aacb10 libglib-2.0.0.dylib`g_hash_table_lookup + 170 frame #3: 0x0000000100ac71e5 libglib-2.0.0.dylib`quark_from_string + 36 frame #4: 0x0000000100ac7458 libglib-2.0.0.dylib`g_intern_static_string + 40 frame #5: 0x0000000100a58bca libgobject-2.0.0.dylib`g_param_spec_internal + 288 frame #6: 0x0000000100a5c0d9 libgobject-2.0.0.dylib`g_param_spec_string + 44 frame #7: 0x00000001001850e7 libgtk-3.0.dylib`gtk_about_dialog_class_intern_init + 338 frame #8: 0x0000000100a64d26 libgobject-2.0.0.dylib`g_type_class_ref + 1080 frame #9: 0x0000000100a541e6 libgobject-2.0.0.dylib`g_object_newv + 122 frame #10: 0x0000000100a54132 libgobject-2.0.0.dylib`g_object_new + 193 frame #11: 0x0000000100186a2b libgtk-3.0.dylib`gtk_show_about_dialog + 173 frame #12: 0x0000000100008b05 gnome-screenshot`action_about(action=0x0000000102033f80, parameter=0x0000000000000000, user_data=0x00000001020050f0) + 501 at screenshot-application.c:788

[juanrgar (Juan R. García Blanco)]

Sorry, I was wrong. When I try to show the about dialog it crashes, but not during .ui parsing. Although in both cases the crash happens in *_strcmp. When I try to show the about dialog from within the main window (not the save screenshot dialog), it shows ok. I guess then there's something wrong with the save screenshot dialog; besides the screenshot being all black.

    frame #0: 0x00007fff8f32cd13 libsystem_platform.dylib`_platform_strcmp + 19
    frame #1: 0x0000000100aac660 libglib-2.0.0.dylib`g_str_equal + 9
    frame #2: 0x0000000100aabb10 libglib-2.0.0.dylib`g_hash_table_lookup + 170
    frame #3: 0x0000000100ac61e5 libglib-2.0.0.dylib`quark_from_string + 36
    frame #4: 0x0000000100ac6458 libglib-2.0.0.dylib`g_intern_static_string + 40
    frame #5: 0x0000000100a57bca libgobject-2.0.0.dylib`g_param_spec_internal + 288
    frame #6: 0x0000000100a5b368 libgobject-2.0.0.dylib`g_param_spec_object + 77
    frame #7: 0x0000000100218121 libgtk-3.0.dylib`gtk_file_chooser_default_init + 512
    frame #8: 0x0000000100a669e9 libgobject-2.0.0.dylib`type_iface_ensure_dflt_vtable_Wm + 162
    frame #9: 0x0000000100a68a78 libgobject-2.0.0.dylib`type_iface_vtable_base_init_Wm + 213
    frame #10: 0x0000000100a63c79 libgobject-2.0.0.dylib`g_type_class_ref + 907
    frame #11: 0x00000001001a6a54 libgtk-3.0.dylib`gtk_builder_get_parameters + 55
    frame #12: 0x00000001001a653e libgtk-3.0.dylib`_gtk_builder_construct + 220
    frame #13: 0x00000001001ab718 libgtk-3.0.dylib`builder_construct + 84
    frame #14: 0x00000001001ab3fd libgtk-3.0.dylib`end_element + 891
    frame #15: 0x0000000100abcd9c libglib-2.0.0.dylib`g_markup_parse_context_parse + 3572
    frame #16: 0x00000001001a9cc8 libgtk-3.0.dylib`_gtk_builder_parser_parse_buffer + 248
    frame #17: 0x00000001001a7a37 libgtk-3.0.dylib`gtk_builder_add_from_resource + 354
    frame #18: 0x0000000100009d5a gnome-screenshot`screenshot_dialog_new(screenshot=0x0000000101854320, initial_uri=0x0000000101142420, f=0x0000000100007bb0, user_data=0x000000010200f0f0) + 202 at screenshot-dialog.c:186
    frame #19: 0x0000000100007b6f gnome-screenshot`build_filename_ready_cb(source=0x0000000000000000, res=0x000000010191c320, user_data=0x000000010200f0f0) + 479 at screenshot-application.c:477

[dbevans (David B. Evans)]

Replying to juanrgar@…:

You're right; it took a few seconds to load all the fonts. Of course if you think it's ok to commit it, just commit, you're the master ;)

But you're the maintainer!

gnome-font-viewer committed in r116099
gnome-utils updated in r116100
gnome3-core updated in r116101

[juanrgar (Juan R. García Blanco)]

Add gnome-screenshot to gnome3-core

[juanrgar (Juan R. García Blanco)]

gnome-screenshot removed from gnome-utils

[juanrgar (Juan R. García Blanco)]

I've added gnome3-core and gnome-utils patches for gnome-screenshot just for completeness sake.

I've come up with a small test that loads screenshot-dialog.ui, and it works fine. However, if I do

g_type_class_ref (GTK_TYPE_FILE_CHOOSER);

which I think is in the crash back trace, I get this

(process:33203): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type 'GtkFileChooser'

This is weird I think. Anyways, I guess that if there's a bug, it doesn't seem to be in gnome-screenshot. Maybe after taking the screenshot, i.e. after performing some calls to X11, Gtk+ comes to a bad state or something; I think this is important to note, the crash happens after taking the screenshot.

[juanrgar (Juan R. García Blanco)]

Just noticed that gnome-logs replaces gnome-system-log; I guess we could wait until gnome-logs 3.12 is released to make the move.

[dbevans (David B. Evans)]

Replying to juanrgar@…:

Just noticed that gnome-logs replaces gnome-system-log; I guess we could wait until gnome-logs 3.12 is released to make the move.

Right.

As of the 3.11.4 release, gnome-system-log (3.9.90) is listed in core and gnome-logs is listed in apps. So they're still carrying both in the release.

If you want to get a head start on 3.12, you can look at the unstable version of gnome-logs which was updated to version 3.11.5 this afternoon. Unstable release 3.11.5 is due tomorrow.

[dbevans (David B. Evans)]

Replying to juanrgar@…:

I've added gnome3-core and gnome-utils patches for gnome-screenshot just for completeness sake.

I've come up with a small test that loads screenshot-dialog.ui, and it works fine. However, if I do

g_type_class_ref (GTK_TYPE_FILE_CHOOSER);

which I think is in the crash back trace, I get this

(process:33203): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type 'GtkFileChooser'

This is weird I think. Anyways, I guess that if there's a bug, it doesn't seem to be in gnome-screenshot. Maybe after taking the screenshot, i.e. after performing some calls to X11, Gtk+ comes to a bad state or something; I think this is important to note, the crash happens after taking the screenshot.

Just moved this port from my personal test branch to GNOME-3/stable (r119586) and rebuilt it using the latest gtk3 (3.12.1). Running gnome-screenshot from the command line (in a OS X terminal window) causes the screen to blink and a png the size of the screen is created but the content is all black. Error message but no crash observed.

$ gnome-screenshot -f test.png
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.
$ file test.png
test.png: PNG image data, 1680 x 1028, 8-bit/color RGB, non-interlaced

Attempting a screenshot of a window with -w option gives the same result, png is still the size of the screen not the window. Content is black.

$ gnome-screenshot -w -f test-window.png
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.
$ file test-window.png
test-window.png: PNG image data, 1680 x 1028, 8-bit/color RGB, non-interlaced

Finally if I open an xterm and run the window test from there, I at least get a file that is the size of the window but still black content.

$ gnome-screenshot -w -f test-xterm-screenshot.png
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.
$ file test-xterm-screenshot.png
test-xterm-screenshot.png: PNG image data, 484 x 338, 8-bit/color RGBA, non-interlaced

Screen shot png's attached

Submitted port version is 3.10.1 but latest available is 3.12.0 so it probably should be updated before any further testing.

[dbevans (David B. Evans)]

Result of full screen screenshot from Mac terminal window

[dbevans (David B. Evans)]

Result of window screenshot from Mac terminal window

[dbevans (David B. Evans)]

Result of window screenshot from xterm (X11) window

[dbevans (David B. Evans)]

Updating and closing this ticket.

All ports except gnome-screenshot have been completed. Discussions with jeremyhu (some time ago) have confirmed that the problems noted above with this port are due to the fact that XQuartz, due to it's architecture, does not allow grabbing of a screenshot using X11 protocol as this app would like to do.

Special thanks to juanrgar for his help with this effort.

gnome-utils removed in r144414.