Downloading your patches from filefactory.com just now, which has the same flaws than most free hosts: limited download speed and simultaneous downloads not allowed (unless the downloader is willing to pay)…
Well, I’m definitely going to host them, with no other limitation than my own bandwidth (~5x the speed allowed by filefactory for free downloads)

Plus, thanks to them I will be able to update my scripts to new scripts building the last version of WL2 from any version uploaded by GOG.com.

Same bug with linux_patch3-patch4.delta & linux_patch4-patch5.delta, with duplicity 0.6.24, 0.6.25 & 0.7.0.
I tried to extract the *.delta with tar, and everything went well. Any idea about what is not going as expected?

A few things might help me find where the fault is:
What is the distribution you use?
Which version of duplicity?
Which version of python?

Following your instructions I have been able to build a working .delta file for 4.1 -> 5.1. Sizes mismatch between the .delta I just created and the one you provide.
What do you think? Might there be something faulty in the .delta files you built for Linux? Or is there a difference between Steam and GOG versions of WL2? Or anything I just don’t think of?

Anyway, if you’re okay with this I should be able to build .delta files for every Linux GOG.com published version, and put them online for testing.
For the Windows and Mac OS X ones, you still are on your own yet
Well, actually I should be able to access Windows-powered toasters quite easily, but I kept backup of old GOG.com versions of WL2 only for Linux.

-----

Anyway, thank you for the short guide about rdiffdir, I can see quite a bunch of uses for this tool in my multiples projects

vv221 wrote:What do you think? Might there be something faulty in the .delta files you built for Linux? Or is there a difference between Steam and GOG versions of WL2? Or anything I just don’t think of?

Ha! Well, I think I spotted the problem: you're using the Steam patches!

The GOG.com patches are here: viewtopic.php?f=34&t=11081#p141739 The data is largely the same, but the file hierarchy is slightly different (which would explain why things aren't showing up in the correct locations).

The Steam deltas are named: linux_patch2-patch3, linux_patch3-patch4, linux_patch4-patch5, etc. while the GOG ones are named: patch1.5.0.9_1.6.0.10, patch1.6.0.10_1.7.0.11, etc. (after the GOG version numbers).

vv221 wrote:Anyway, thank you for the short guide about rdiffdir, I can see quite a bunch of uses for this tool in my multiples projects

No problem! I haven't looked at the source, but I've long suspected rdiffdir is really just a wrapper for tar and bsdiff (your Traceback has confirmed tar is one of the components). It might be easily replaced with something simpler / more cross compatible.

This account is dormant. I won't be responding to threads, quotes or private massages.

Looks like we’re halfway to the goal: the delta 'patch1.6.0.10_1.7.0.11.delta' is working as expected, while 'patch1.5.0.9_1.6.0.10.delta' fails with the "AssertionError: snapshot" I posted earlier.

When building a new (working) delta for upgrading 1.5.0.9 to 1.6.0.10, sizes of yours and mines mismatch.
When building a new delta for upgrading 1.6.0.10 to 1.7.0.11, yours and mines are the same size (diff actually reports they differ, but it might only be due to different tar versions between our respective systems, or something like this).

-----

Phew, I think I might take a break now, it’s 5AM on this side of Earth, and I got one patch working.
I can upload my working patch for upgrading from 1.5.0.9 to 1.6.0.10 if you wish, as well as building a couple more for the older versions.

Just thinking about it: it would be no hassle for me to build patches for upgrading every published GOG.com version to the latest build (Linux only), now that you’ve showed me how to do it. It would at least lighten a bit your "burden"

Hmm, they were created the same way... Did you check the md5sums of the 7z archive and resources.assets?

Another idea: before applying the delta, delete the PlayerConnectionConfigFile in the WL2_Data folder. A shot in the dark, but that might have done that when I created the signature originally.

I'd be happy to have you involved with creating the GOG.com Linux patches. But I'm not sure we can continue to call these "Semi-official" if they aren't coming from inXile directly; so I'll need to think on it.

Although, if you want to create patches for the older GOG versions: I don't see any harm in it. I don't have them myself and I can credit you with putting them together. But first: I'd like to figure out our patching issue before we put more work into these; you're my only beta tester.

This account is dormant. I won't be responding to threads, quotes or private massages.

tonurics wrote:Hmm, they were created the same way... Did you check the md5sums of the 7z archive and resources.assets?

Checked and double-checked.

Another idea: before applying the delta, delete the PlayerConnectionConfigFile in the WL2_Data folder.

Still getting the "AssertionError: snapshot". I wish it were a more easily understandable error message.

I'd be happy to have you involved with creating the GOG.com Linux patches. But I'm not sure we can continue to call these "Semi-official" if they aren't coming from inXile directly; so I'll need to think on it.

Like you said, there will be plenty of time to think about it when we’ll finally get the tricky patch working as expected…

I'd like to figure out our patching issue before we put more work into these; you're my only beta tester.

And we’re precisely in a situation where more testers would be a great help.
What if the version of WL2 I use as a base is corrupted, despite the right checksum for the resources.assets file?
I’m going to raise a call on the GOG forums to get some help sorting this out. (EDIT: Done!)

To any Linux GOGer reading this, if you still have the 1.5.0.9 archive, could you please tell me if you get the same md5 checksum I get?

For a week or two I should have access to other computers, running other versions of Debian (Wheezy i386, Wheezy amd64, and Jessie i386 or amd64, can’t remember the architecture of the last one). I’m going to run the same test on these in a couple days (very poor connection to transfer the 11G WL2 archive through), just to be sure I’m not experimenting a rdiffdir bug on my main computer (Debian Sid amd64).

When I get back to the office next week, I'll md5sum the signatures I created. I assume that they should be the same on both our systems. That should help us figure out what has happened. (If the deltas are created with tar: it would record the owner and group ids of our files. Which could explain why our deltas are different, but still work.)

If the base is corrupted, then any output is going to be messed up as well. Based on what I read here I take it that the "AssertionError: snapshot" is because it hit a file it didn't like and gave up.

And thanks for making the post on the GOG forums!

This account is dormant. I won't be responding to threads, quotes or private massages.

tonurics wrote:Based on what I read here I take it that the "AssertionError: snapshot" is because it hit a file it didn't like and gave up.

While 141 files to test one by one would be an awful chore for any human being, it should be a piece of cake for the adequate shell script… Getting to work on it right now!

-----

It’s going to take a while, as the script needs to put back WL2 game dir in its original state after every failed attempt to patch it (once for every file in it until it achieve to patch it or it has tried once with each file removed in turn with no success). As I can’t find a way to see what has been modified before the patching fails, it means copying the whole game dir each time.
I let you guess how long this could take before every file has been tested individually… A chance I have a nearly idle server ready to see this through completion!

I’ll report here once it’s done (might take a dozen of hours), hopefully with the identity of the offending file.

As this test is a time-consuming task but very light on CPU and memory, I still can run other tests while this one is going on.

tonurics wrote:Haha, I like your gusto! I was more or less content with knowing what was causing the cryptic error message. But it will be interesting to find out more.

I finally had no luck with this: I tried applying the patch with each time a different file removed from the game folder (minus resources.assets, it means 140 iterations), but got the same error message each and every time.
I don’t feel like trying it again for every possible two-files combination: it would take about three months on my computer with the method I used. I had an idea allowing to do it in only one day, but I’m missing 34 of the computers needed to put it to the trial of reality (well, one supercomputer could be enough, but I don’t know of anybody ready to lend one for the experience)