Opened 14 years ago

Closed 13 years ago

#21 closed task (fixed)

OSX Packaging: py2app

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 1.1
Component: Global Keywords:
Cc:

Description (last modified by 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)

Change History (23)

comment:1 Changed 14 years ago by Antoine Martin

Milestone: 0.91.0

comment:2 Changed 14 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Antoine Martin
Status: newaccepted

comment:3 Changed 14 years ago by Antoine Martin

Description: modified (diff)

comment:4 Changed 14 years ago by Antoine Martin

Description: modified (diff)

comment:5 Changed 14 years ago by Antoine Martin

Description: modified (diff)

comment:6 Changed 14 years ago by Antoine Martin

Description: modified (diff)

comment:7 Changed 14 years ago by Antoine Martin

Description: modified (diff)

comment:8 Changed 14 years ago by Antoine Martin

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

Last edited 13 years ago by Antoine Martin (previous) (diff)

comment:9 Changed 14 years ago by Antoine Martin

for pygtk and py2app, see py2app vs pygtk

comment:10 Changed 14 years ago by 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.

comment:11 Changed 14 years ago by 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

comment:12 Changed 14 years ago by 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

comment:13 Changed 14 years ago by Antoine Martin

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

comment:14 Changed 14 years ago by Antoine Martin

Description: modified (diff)

comment:15 Changed 14 years ago by 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

comment:16 Changed 14 years ago by 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).

comment:17 Changed 14 years ago by 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...

comment:18 Changed 14 years ago by Antoine Martin

Milestone: 1.00.9.1

comment:19 Changed 14 years ago by 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...

comment:20 Changed 14 years ago by Antoine Martin

Milestone: 0.9.11.0

comment:21 Changed 14 years ago by Antoine Martin

Milestone: 1.01.1

Current packaging using gtk-osx bundle seems to work.

py2app would be nicer, but this is not urgent.

Moving to 1.1

comment:22 in reply to:  21 Changed 13 years ago by 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.

comment:23 Changed 13 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

Unlikely to bother with py2app now. Closing.

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

Note: See TracTickets for help on using tickets.