Quote from author's homepage: "Xpra gives you "persistent remote applications" for X. That is, unlike normal X applications, applications run with xpra are "persistent" -- you can run them remotely, and they don't die if your connection does. You can detach them, and reattach them later -- even from another computer -- with no loss of state. And unlike VNC or RDP, xpra is for remote applications, not remote desktops -- individual applications show up as individual windows on your screen, managed by your window manager. They're not trapped in a box. So basically it's screen for remote X apps." Reproducible: Always Steps to Reproduce: I wrote two ebuild: for xpra and for library that it depends on, named wimpiggy. Both xpra and wimpiggy are parts of project named Parti - "tabbing/tiling (one might say "partitioning") window manager"(author's quote) and source code for them is in one code tree, but i decided to split ebuild for this application(and set dependecy for xpra ebuild to wimpiggy ebuild). Maybe somebody add ebuild for Parti, i do not wrote it because i did not use it. Also this is my first ebuild, so please do not scream on me too loudly for any mistakes. P.S. Now i trying to wrote ebuild for last version of xmove, that i have got from Mandrive 2009.1(rpm2targz is a cool thing ;)). Last version of xmove seems to be very useful and(it is very important) it correctly works with new X server. P.P.S. Sorry for my baaad english...
Created attachment 192706 [details] Ebuild for xpra, place it to x11-misc/xpra
Created attachment 192708 [details] Ebuild for wimpiggy, place it to x11-libs/wimpiggy
ok on amd64 with python2.6 too
Comment on attachment 192708 [details] Ebuild for wimpiggy, place it to x11-libs/wimpiggy ><HTML><HEAD/><BODY><PRE># Copyright 1999-2009 Gentoo Technologies, Inc. ># Distributed under the terms of the GNU General Public License v2 ># $Header: $ > >inherit eutils python > >PYVER=2.5 >DESCRIPTION="A library for writing window managers, using GTK+ and Python" >HOMEPAGE="http://partiwm.org" >SRC_URI="http://partiwm.org/static/downloads/parti-all-${PV}.tar.gz" >S="${WORKDIR}/parti-all-${PV}" > >LICENSE="UNKNOWN" >SLOT="0" >KEYWORDS="~x86 ~amd64" >IUSE="" > >DEPEND="dev-python/pyrex > x11-base/xorg-server" >RDEPEND=${DEPEND} > >src_compile() { > ./do-build >} > >src_install() { > insinto /usr/$(get_libdir)/python${PYVER}/site-packages/wimpiggy > doins install/lib/python/wimpiggy/*.py > doins install/lib/python/wimpiggy/*.pyc > insinto /usr/$(get_libdir)/python${PYVER}/site-packages/wimpiggy/lowlevel > doins install/lib/python/wimpiggy/lowlevel/*.py > doins install/lib/python/wimpiggy/lowlevel/*.pyc > doins install/lib/python/wimpiggy/lowlevel/*.so > > python_need_rebuild >} > >pkg_postrm() { > python_version > python_mod_cleanup >} ></PRE></BODY></HTML>
Comment on attachment 192706 [details] Ebuild for xpra, place it to x11-misc/xpra ><HTML><HEAD/><BODY><PRE># Copyright 1999-2009 Gentoo Technologies, Inc. ># Distributed under the terms of the GNU General Public License v2 ># $Header: $ > >inherit eutils python > >PYVER=2.5 >DESCRIPTION="X Persistent Remote Applications" >HOMEPAGE="http://partiwm.org" >SRC_URI="http://partiwm.org/static/downloads/parti-all-${PV}.tar.gz" >S="${WORKDIR}/parti-all-${PV}" > >LICENSE="UNKNOWN" >SLOT="0" >KEYWORDS="~x86 ~amd64" >IUSE="" > >DEPEND="dev-python/pyrex > x11-base/xorg-server > x11-libs/wimpiggy" >RDEPEND=${DEPEND} > >src_compile() { > ./do-build >} > >src_install() { > dobin install/bin/xpra > doman install/share/man/man1/*.1 > insinto /usr/$(get_libdir)/python${PYVER}/site-packages/xpra > doins install/lib/python/xpra/*.py > doins install/lib/python/xpra/*.pyc > doins install/lib/python/xpra/*.so > insinto /usr/$(get_libdir)/python${PYVER}/site-packages/xpra/scripts > doins install/lib/python/xpra/scripts/*.py > doins install/lib/python/xpra/scripts/*.pyc > > python_need_rebuild >} > >pkg_postrm() { > python_version > python_mod_cleanup >} ></PRE></BODY></HTML>
Damn, i think that i will fix ebuild content directly it attachments :(
According to some files headers the license should be : - LICENSE="GPL-2 LGPL-2.1" 'eutils' seems not needed the ebuild work with only : - inherit python Maybe you don't need to set PYVER in header, just call python_version in src_install beginning and it works with current pyver. Thanks for your ebuild
Created attachment 197050 [details] Updated, more accurate ebuild for x11-misc/xpra
Created attachment 197052 [details] Updated, more accurate ebuild for x11-libs/wimpiggy
Here comes code cleaning for ebuild... :)
Created attachment 209699 [details] Further updated ebuild - deals with latest version of xextproto This ebuild checks the version of xextproto and applies a patch to deal with the lack of XTest.h if greater than version 7.0.5.
Created attachment 209700 [details, diff] This goes will my previous ebuild
Created attachment 209702 [details] Further updated ebuild - deals with latest version of xextproto
Created attachment 209704 [details, diff] This goes will my previous ebuild
Upon further testing this ebuild builds but what it produces doesn't run. My apologies, this is my first submission to Bugzilla and the late binding in python threw me off.
it seems that xpra do not work with recent(>=1.6) xorg-server. Need code update from program developer...
i have updated the ebuilds to handle the deprecation (and subsequent die()) of python_version calls made (see upcoming attachments). the packages compile and seem to install correctly. however, there seems to be some problem after install when i run xpra i get: > ~ $ xpra start :13 Traceback (most recent call last): File "/usr/bin/xpra", line 6, in <module> xpra.scripts.main.main(__file__, sys.argv) File "/usr/lib/python2.6/site-packages/xpra/scripts/main.py", line 81, in main from xpra.scripts.server import run_server File "/usr/lib/python2.6/site-packages/xpra/scripts/server.py", line 18, in <module> from xpra.wait_for_x_server import wait_for_x_server ImportError: No module named wait_for_x_server maybe this has something to do with an incorrect install of dependent modules. unsure right now...
Created attachment 240535 [details] update to ebuild to handle changes to python
Created attachment 240537 [details] update to ebuild to handle changes to python
the last ebuild i posted was missing the correct paths for the doins commands. i've updated those ebuilds.
Created attachment 240587 [details] fix to ebuild doins paths
Created attachment 240589 [details] fix to ebuild doins paths
i finally got xpra to work! however, i only got it to work by not performing the XTest patch in the build. in the submitted ebuild, the patch is applied when xextproto is of version 7.0.5. i have version 7.1.1, yet applying the patch actually causes xpra to break. i am not submitting an updated ebuild with the epatch removed until i understand why the original patch was put in place.
Created attachment 240997 [details] proposed live ebuild for wimpiggy
Created attachment 240999 [details] proposed live ebuild for xpra
i've updated the 0.0.6 ebuilds for xpra and wimpiggy. i removed the XTest patch as xpra would always fail complaining of a missing xtest_fake_key function that the patch removed, even though my chroot env had xextproto-7.1.1. i also added a patch to eliminate the deprecation warning in 2.6 and impending removal in 3.1 regarding importing the sets module. it simply tests the version of python and uses ImmutableSet for older versions and frozenset for the newer ones.
Created attachment 241001 [details] removal of XTest patch. addition of deprecation warning patch
Created attachment 241003 [details] removal of XTest patch. addition of deprecation warning patch. clean-up of deps.
Created attachment 241005 [details, diff] patch to handle deprecation of sets module this patch was accepted and committed (see issue 27 of the partiwm project)
Created attachment 241007 [details, diff] patch to handle deprecation of sets module this patch was accepted and committed (see issue 27 of the partiwm project)
Created attachment 241025 [details] added correct dependency on libXtst for wimpiggy live ebuild after building in stripped down chrooted environment, found that x11-libs/libXtst is a required dependency that was missing.
Created attachment 241109 [details] in completely stripped chroot env, these are all the dependencies for wimpiggy
Created attachment 241111 [details] in completely stripped chroot env, these are all the dependencies for wimpiggy
I am glad to see, that these programs are needed by someone else. By the way is there any opportunity to mark really old ebuild as absolete? I am reporter of this bug, but i can mark obsolete only my own ebuilds and patches...
Created attachment 241353 [details] include xposix and win32 platform modules on install
By the way - in some of ebuilds field KEYWORDS="-x86 -amd64"... Is that normal?
(In reply to comment #36) > By the way - in some of ebuilds field KEYWORDS="-x86 -amd64"... Is that normal? > for the 0.0.6 builds, there should be tildes (~x86 ~amd64) denoting unstable, not dashes. for the live ebuilds, there are no keywords. to unmask these, add lines in your /etc/portage/package.keywords file such as: =x11-libs/wimpiggy-9999 ** =x11-misc/xpra-9999 ** truthfully, i've never seen this declared as the official gentoo way but i've seen it enough places to think it's generally accepted. input from a gentoo developer or arch tester who knows more is welcome.
(In reply to comment #36) > By the way - in some of ebuilds field KEYWORDS="-x86 -amd64"... Is that normal? No, this denotes that there's no chance for these arches to build this package. like "~amd64 ~x86 -*" for binary packages with 32bit and 64 bit binary packages. (In reply to comment #37) > for the 0.0.6 builds, there should be tildes (~x86 ~amd64) denoting unstable, ack > for the live ebuilds, there are no keywords. to unmask these, add > lines in your /etc/portage/package.keywords file such as: > > =x11-libs/wimpiggy-9999 ** > =x11-misc/xpra-9999 ** ack So is it really neccessary to pack this as two packages? I haven't seen a chance to build http://code.google.com/p/partiwm/downloads/list in separate. and it's stupid to ignore `python setup.py install` and run `python setup.py build` twice (more sophisticated suggestions on how to use setup.py are welcome). I try to commit this as x11-wm/parti, objections? Michael
> I try to commit this as x11-wm/parti, objections? In other repository(i do not remember which is) these packages are installed separately (as for the time when i wrote first version of these ebuilds). But i do not have any objections if it will be in portage tree as a solid ebuild.
I've included changeset 620a831d81 (the sets deprecation patch) http://code.google.com/p/partiwm/source/detail?r=620a831d81d1b5d085da0c651dcea15805c6f9f3&path=/wimpiggy/window.py and changeset fedd8b2841 http://code.google.com/p/partiwm/source/detail?r=fedd8b28419771ab5086a836d0f42bd2c361b9c1&path=/xpra/server.py +*parti-0.0.6 (31 Aug 2010) + + 31 Aug 2010; Michael Weber <xmw@gentoo.org> +parti-0.0.6.ebuild, + +files/parti-0.0.6-python-2.6-sets-deprecation.patch, + +files/parti-0.0.6-python-import.patch, +metadata.xml: + Initial commit, fixed bug #271527, thanks to Pinkbyte <pinkbyte@mail.ru>, + Dan <dtyler@csh.rit.edu> and Eric Johnson <tokenmathematician@gmail.com> + for their great work on bug #271527.
+*parti-9999 (31 Aug 2010) + + 31 Aug 2010; Michael Weber <xmw@gentoo.org> +parti-9999.ebuild, + +files/parti-9999-constants.pxi: + Added LiveVCS ebuild, needs wimpiggy/lowlevel/constants.pxi.
(In reply to comment #41) > +*parti-9999 (31 Aug 2010) > + > + 31 Aug 2010; Michael Weber <xmw@gentoo.org> +parti-9999.ebuild, > + +files/parti-9999-constants.pxi: > + Added LiveVCS ebuild, needs wimpiggy/lowlevel/constants.pxi. > thanks! i just installed it (non chroot env, though) and did a couple checks. looks good so far! i did notice a few additional dependencies get pulled in for parti (i'm assuming) that are not necessary for wimpiggy and xpra.
