Bugzilla Bug 132286

Hi, here's an ebuild for the demo of "X2 - The Threat".

I suggest category "games-strategy".

The standard unpack_makeself in eutils does not work, so I've included a
replacement function.

I've checked that the end result is the same as a patched installation via the
LGP's update.

Created an attachment (id=86163) [edit]
x2-demo-1.4.01.ebuild

comments:

no need for RESTRICT="primaryuri"
virtual/x11 doesn't provide x11-libs/gtk+ - should be out of the list for that
no need for virtual/libc
probably in pkg_postinst there should be a big fat warning that the X server
has to be running in 24bbp or better.  16 isn't good enough.

Created an attachment (id=86181) [edit]
x2-demo-1.4.01.ebuild

"primaryuri" is in there by choice, not necessity. I see no point in having
several "wget: file not found" messages scroll by initially. It's a 180mb
download, where the licence isn't explicit.

The game itself shows a reasonable message, if xorg has a bad colour depth: 
"You must have a pixel colour depth of at least 24bpp on your X display. We
detected you are running at 16". This game will run like a dog, without a
*decent* video card :)  But then, so will e.g. Doom 3 and Quake 4.

What needs to be done to fix unpack_makeself?  Is it just that a new version of
makeself was used?  If so, I would much rather fix unpack_makeself in the
eclass than override it in the ebuild.

Also, I think the patching should be done in src_install instead, like we do in
pretty much every other ebuild that uses loki_patch.

Otherwise, it looks good.

Created an attachment (id=86228) [edit]
x2-demo-1.4.01.ebuild

Oops. My problem with unpack_makeself was caused by my own incorrect usage,
rather than unpack_makeself not working when supplied with individual files.
The warning message "bzip2: (stdin): trailing garbage after EOF ignored" turns
out to be harmless.

Here is a fixed ebuild.

GRR... patching doesn't work on amd64.  I've tried both the external (in-tree)
loki_patch and the version shipped with the patch itself.

OK... It isn't just amd64.  I'm getting the same thing on x86, too.

Also, I even get this when running things manually.

inertia ~ # bash /usr/portage/distfiles/x2-demo-1.4-1.4.01-x86.run
Verifying archive integrity... All good.
Uncompressing X2: The Threat DEMO Update 1.4 - 1.4.01...............
=============================================================
Welcome to the X2 - The Threat DEMO Update 1.4 - 1.4.01
=============================================================

Would you like to read the README for this update?  [Y/n]: n

=============================================================
Would you like to apply this update? [Y/n]:

=============================================================
Performing update:
ERROR: No matching delta for /usr/local/games/x2-demo/x2_demo.dynamic

You need games-util/loki_patch-20051209 (which is masked by
/usr/portage/profiles/package.mask) to apply the patch -- 20050324 failed for
me too, 20051209 didn't.

Created an attachment (id=86811) [edit]
x2-demo-1.4.01.ebuild

This ebuild uses loki_patch-20051209 (bug #133407), to hopefully fix the patch
reliability issue. It uses a symbolic link from directory "data" to
"patchdata", to workaround the directory name change in the newer loki_patch.

loki_patch should itself be patched, to change back to the "data" directory
name, before being package.keyworded.

I guess you guys are missing my point that using the "official" method of
patching is failing for me, too.  I've been able to reproduce the failures on
every machine I own.

Created an attachment (id=86819) [edit]
x2-demo-1.4.01.ebuild

Uses xdelta instead of loki_patch.

 # emerge -v x2-demo
Calculating dependencies... done!
>>> Emerging (1 of 1) games-strategy/x2-demo-1.4.01 to /
>>> Creating Manifest for /usr/local/portage/games-strategy/x2-demo
>>> Unpacking source...
>>> Unpacking x2-demo.run to /var/tmp/portage/x2-demo-1.4.01/work
21582+1 records in
183877+1 records out
188290092 bytes (188 MB) copied, 77.6325 seconds, 2.4 MB/s

bzip2: (stdin): trailing garbage after EOF ignored
>>> Unpacking x2-demo-1.4-1.4.01-x86.run to /var/tmp/portage/x2-demo-1.4.01/work122+1 records in
1059+1 records out
1084491 bytes (1.1 MB) copied, 0.332312 seconds, 3.3 MB/s

bzip2: (stdin): trailing garbage after EOF ignored
>>> Unpacking ./data.tar.gz to /var/tmp/portage/x2-demo-1.4.01/work
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/x2-demo-1.4.01/work ...
>>> Source compiled.
>>> Test phase [not enabled]: games-strategy/x2-demo-1.4.01

>>> Install x2-demo-1.4.01 into /var/tmp/portage/x2-demo-1.4.01/image/ category games-strategy
xdelta: expected from file (x2_demo) of length 6204668 bytes

!!! ERROR: games-strategy/x2-demo-1.4.01 failed.
Call stack:
  ebuild.sh, line 1527:   Called dyn_install
  ebuild.sh, line 1005:   Called src_install
  x2-demo-1.4.01.ebuild, line 58:   Called die

!!! xdelta data/x2_demo.0 failed
!!! If you need support, post the topmost build error, and the call stack if
relevant.

I get the same bzip2 messages and numbers. But all these ebuilds work for me.
The two filesizes, before and after patching, are:

Before   After    File
6204668  6212284  x2_demo
4435772  4443484  x2_demo.dynamic

The md5sums of the source files are:

bc44d4daabe6dc84deead93f1085305a  x2-demo.run
12b7b0feb746918bfe512504376729f4  x2-demo-1.4-1.4.01-x86.run

a6d6e04d331900f92c2fee58e1aa86c1  /usr/portage/distfiles/x2-demo.run
12b7b0feb746918bfe512504376729f4 
/usr/portage/distfiles/x2-demo-1.4-1.4.01-x86.run

That might explain something.  Re-downloading.

Just downloaded it again.

a6d6e04d331900f92c2fee58e1aa86c1  /usr/portage/distfiles/x2-demo.run

I'm willing to bet that they changed it upstream, which is why this isn't
working.

Created an attachment (id=86894) [edit]
x2-demo-1.4.01.ebuild

They've changed x2-demo.run to *include* the patch. So it's really version
1.4.01. Here's the ebuild with the now-unnecessary patching removed.

Patching is no longer relevant for this bug.

<lgp-michael> wolf31o2|work: the new x2-demo is patched
<lgp-michael> the patched version is 1.4.01

Yeah.

This means I'll be using my version of the ebuild (w/ amd64 support... yay!). 
It's based off yours, minus doing any moving and deleting in src_install (which
is an ebuild faux pas, by the way...) and using doins -r instead.

I'd like to thank you for all the work you've done to get this going.  I know
it's a bit trying when upstream makes changes like this.

Created an attachment (id=86945) [edit]
x2-demo-1.4.01.ebuild

Well, src_install() can be tidied up slightly to this, but I think having
"doins -r *" is a good future-version-proof feature, for e.g. if the next
version happens to contain a new directory.

Well, "future-version-proof" or not, it isn't something that we accept anymore.
 You should be able to run the src_install portion repeatedly with the same
results.  Yes, there are tons of ebuilds that don't do this, and I'm fixing up
any of them that I come across (and notice).

Created an attachment (id=86960) [edit]
x2-demo-1.4.01.ebuild

This fixes the src_install file movement violation.

It's now in the tree...