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 attachment 86163 [details] 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 attachment 86181 [details] 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 attachment 86228 [details] 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 attachment 86811 [details] 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 attachment 86819 [details] 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 attachment 86894 [details] 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 attachment 86945 [details] 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 attachment 86960 [details] x2-demo-1.4.01.ebuild This fixes the src_install file movement violation.
It's now in the tree...
