cleaned up xpra.spec

[pyther]

Cleaned up the xpra.spec. The build dependencies depend on packages in #605.

Removed the generic option. If there is a need we can break the package out into components such as (client, server, codecs, opengl, etc...)

Removed bunch of old crufty options.

[Antoine Martin]

I like (and will try to merge):

• the move towards proper mock build support with BuildRequires
• _datadir and other macros we should already be using
• other simplications (egg file hack without using a #define, etc)

but there are too many changes in this specfile for me to apply wholesale:

• unlike CentOS, Fedora can be built with dynamically linked modules (via rpmfusion) - and this is what we will continue to provide as there is absolutely no way we can take the responsibility for updating all those packages whenever there are security issues that require a rebuild with newer libs (we just don't have the manpower)
• I think #603 workaround should be dealt with separately
• why have the chcon workarounds disappeared?
• where is %debug_package?

[pyther]

Responding to your questions/points

• we talked about this in irc

• In regards to #603, I agree the workaround should be removed.

• I removed the chcon workarounds because xpra works on EL6 and Fedora 20 with selinux without the workaround. I am not an expert, but it would appear that setting type texrel_shlib_t is not preferred (1) (2). I don't understand text relocation, so I have no objection if this is kept. A comment explaining why this workaround is in place would be useful, though.

• Regarding %debug_package, I removed it since debug packages get built automatically with mock. I have no strong feelings here, though if you decided to keep it, I think the line should go towards the top of the SPEC file. Note, most packages do not define %debug_package.

(1) ​http://danwalsh.livejournal.com/2006/05/11/ (see execmod)
(2) ​http://danwalsh.livejournal.com/13716.html

[Antoine Martin]

• as per #613: it looks like we'll be shipping minimal media libraries for quite a few distros
• thanks for the links on textrel_shlib_t - I think we can drop it from the new spec file, for the old ones I've reopened #284
• as for %debug_package, I'll do some testing - I don't think I'll be switching to mock just yet (to support all the builds during the transition period) and so I may still need it

[Antoine Martin]

Some changes already applied: r7101 + r7103

Anything more than those and I quickly ran into problems building on at least one platform. Please re-submit incremental changes (similar to the two commits above) instead of wholesale changes.

Some questions / remarks:

• python2_sitelib - why do we need this? doesn't seem to be used anywhere.
• BuildRequires should be updated to use the xpra private library headers from #613 (ie: xpra-libvpx-devel) - but only for those distributions that do not provide the headers we need out of the box (libvpx-devel is in Fedora and centos7, too old in centos6 - so there will need to be some ugly logic in there)
• the %post and %postun steps remove the check for fedora, have you tested this on oldies like centos5?
• why add an absolute path to /usr/bin/update-desktop-database and /bin/touch ?
• old_xdg remains but include_egg got changed to a test for el5, I don't mind which is used but it has to be consistent
• --with-Xdummy will not work on many centos versions
• $RPM_BUILD_ROOT vs %buildroot - I believe the latter does not work on centos5...

PS: found a good reference on which macros are available in which versions here: ​zarb.org : macros

[pyther]

• python2_sitelib: we don't need it. As we we are using python2_sitearch. I like defining both, it doesn't do any harm, personal preference really.

• BuildRequires: I did the work for this, I thought I attached it to this ticket, but apparently I did not. I will merge my work into the current spec (svn) and create a new ticket.

• regarding %post and %postun: Do you plan to still support el5? I want to say I tested this spec on EL5/EL6/Fedora 19/Fedora 20. However, it has been a while ago and I don't remember. Retesting would probably be useful.

• regards to Xdummy it is supported on EL6/EL7. Do you want to continue to support EL5?

• %buildroot works with EL5 within a mock environment. I believe mock is using the rpmbuild version that ships with EL5.

• regarding the absolute path: this is what fedora recommends: ​http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache

[Antoine Martin]

regarding %post and %postun: Do you plan to still support el5?

Yes, 0.14.x will be the last branch to support EL5, and it will be a LTS release.
As soon as development opens for 0.15.x, I will drop support for EL5, python24 and python25, old versions of pygtk, etc. At last!
(I wished I could drop python26 too..)

regards to Xdummy it is supported on EL6/EL7. Do you want to continue to support EL5?

As per above, yes.
Note: although Xdummy works on EL6.3 and later, it doesn't on 6.2 and earlier. (IIRC, I could be off by one on the version numbers)
And I have to provide rpms for 6.2.

---

I want to say I tested this spec on EL5/EL6/Fedora 19/Fedora 20...

OK, I was only asking because normally special cases don't end up in the code (specfile in this case) unless I've hit some problems.
Applied in r7108.

regarding the absolute path: this is what fedora recommends...

OK, also merged in r7107.

Does this also apply to commands like rm and cd? How do we make the distinction?

---

Note to self: if all goes well, we can probably drop the static modules and also get rid of all the selinux stuff.

[Antoine Martin]

Lots of cleanups in r7283.

[pyther]

Does this also apply to commands like rm and cd? How do we make the distinction?

I've seen both the full path specified and just the command specified. I think, in general, the best practice would be to use use the absolute path. You won't have to worry about functions, aliases, or paths that way.

[pyther]

One Major Issue: BuildRequires: setuptool should be BuildRequires: python-setuptools

Xpra should be installed in python_sitearch in the case of x86_64 that would be /usr/lib64

$ find /usr/lib64/python2.6/site-packages/  | grep '\.so' | wc -l
85
$ find /usr/lib/python2.6/site-packages/  | grep '\.so' | wc -l
0

See this mark on the difference between sitelib and sitearch:

You got it right. If you don't have any platform-specific code, use %{python_sitelib} exclusively. If you do, like C-binding stuff, then all

these should go to %{python_sitearch}, since the location will be
different on 64-bit architectures.

​http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00513.html

[pyther]

xpra.spec patch based on r7292

[Antoine Martin]

• setuptool vs python-setuptools fix in r7293
• sitearch vs sitelib in r7294
• avahi-ui-tools dep removed in r7295 (see commit message for details on this insanity)

I hope the latter does not cause problems somewhere.. (centos5?)

[Antoine Martin]

0.14.0 has been shipped with all these changes, closing at last!