OSX Packaging: py2app

[Antoine Martin]

Packaging should be done with: ​py2app

Server seems to work OK on OSX (after installing all the required dependencies using macports) and it can authenticate users using python-PAM, but I have added support for Kerberos5 anyway using
​pykpass
There is a new server option: "authentication_module" = [pam|pykpass].

We will also need to load the list of X applications from somewhere... and OSX does not follow the freedesktop spec, so we may just test for a few (xterm, ...) and create these "*.desktop" files in ~/shifter/server/menu/ on first start.

TigerVNC can be built on OSX, but I cannot find any ready-made images, see this:
​tigervnc-devel message
More info on nasm/ld bug ​here

nxproxy can be built with macports' help (libpng, jpeg):
​nxproxy-apple

xpra: client and server both build fine (with ​this simple patch)
But only the client is usable... (keymap issues for server)

[Antoine Martin]

had to use a window rather than StatusIcon on OSX: ​changeset

[Antoine Martin]

for pygtk and py2app, see ​py2app vs pygtk

[Antoine Martin]

Lots of issues... (sigh)

First, when building with python25 (python_select python25):

WARNING: Mach-O header may be too large to relocate
WARNING: Mach-O header may be too large to relocate
Traceback (most recent call last):
  File "/opt/local/lib/python2.5/site-packages/py2app/build_app.py", line 589, in _run
    self.run_normal()
  File "/opt/local/lib/python2.5/site-packages/py2app/build_app.py", line 660, in run_normal
    self.create_binaries(py_files, pkgdirs, extensions, loader_files)
  File "/opt/local/lib/python2.5/site-packages/py2app/build_app.py", line 777, in create_binaries
    platfiles = mm.run()
  File "/opt/local/lib/python2.5/site-packages/macholib/MachOStandalone.py", line 135, in run
    node.write(f)
  File "/opt/local/lib/python2.5/site-packages/macholib/MachO.py", line 113, in write
    header.write(f)
  File "/opt/local/lib/python2.5/site-packages/macholib/MachO.py", line 304, in write
    self.synchronize_size()
  File "/opt/local/lib/python2.5/site-packages/macholib/MachO.py", line 294, in synchronize_size
    raise ValueError("New Mach-O header is too large to relocate")
ValueError: New Mach-O header is too large to relocate
> /opt/local/lib/python2.5/site-packages/macholib/MachO.py(294)synchronize_size()
-> raise ValueError("New Mach-O header is too large to relocate")
(Pdb) 

Next, with python26, it builds ok, but fails at runtime with gobject.thread_init() related weirdness... Looks like it would require threaad_init to be called whenever there is a "import gobject", which is not acceptable. Something is wrong with the module loader / py2app.

[Antoine Martin]

Here is the thread_init non-sense (has been called before this gets printed out):

(process:23287): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use g_type_init() prior to this function
(process:23287): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:23287): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed

Maybe we should use wx for the UI? It seems to integrate better:
​http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X

[Antoine Martin]

​here is a solution for the "New Mach-O header is too large to relocate" issue, which requires rebuilding a lot of packages with a linker option set to:

default configure.ldflags   {"-L${prefix}/lib -Xlinker -headerpad_max_install_names"}

in /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl

[Antoine Martin]

According to ​this post we may also have to start the X server via a script if it is not running (sigh).

[Antoine Martin]

And there may still be some issues with pango fonts, as per ​http://www.danplanet.com/home/82-codemonkeying/88-using-py2app-with-gtk

[Antoine Martin]

Correction: the Glib g_type_init() bug is present with *all* versions of python (tested with 2.4, 2.5 and 2.6).

[Antoine Martin]

Seems to me like the way forward is to use native ​gtk-osx

Problem is that all my attempts at building it have failed.
Fortunately someone has made a DMG available: ​gtk-osx bin dmg

The code runs fine with this, let's hope the packaging works better than the previous attempt with ports+py2app...

[Antoine Martin]

The g_type_init() bug occurred with gtk-osx too, but was easier to fix (just copy all the dylibs from the binary installation into the app folder).
So maybe we can still fix the py2app non-native-gtk build by finding out which libraries it is missing...

[Antoine Martin]

Current packaging using gtk-osx bundle seems to work.

py2app would be nicer, but this is not urgent.

Moving to 1.1

[CodenameKT]

Replying to antoine:

Current packaging using gtk-osx bundle seems to work.

py2app would be nicer, but this is not urgent.

Moving to 1.1

Antoine, I am having a similar problem packaging my pygtk app with py2app. Was wondering if you could give the resolution as it looks like you were able to resolve this problem. codenamekt at g m a i l .com

BTW, great work. I love the application.

[Antoine Martin]

Unlikely to bother with py2app now. Closing.

For details, please see the complete step-by-step documentation ​here