Bug 590205

I added Jon in case someone reports this against Wesnoth instead of Boost.

I forgot to mention the symptom is the attempt to join the server hanging on x86_64.

In the link you referenced (http://forums.wesnoth.org/viewtopic.php?f=4&t=28071), only Arch Linux is mentioned. Has Boost-1.41 on Fedora got the same problem?

One of the people trying to play Wesnoth for last night's community gaming had to install the i686 version of Wesnoth and dependent libraries in order to be able to play. The symptoms were the same and switching to i686 got things working. So likely it is the same issue.
I don't have an x86_64 machine at home to easily retest this with. I can try at work on Monday.
He also tried going back to the 1.39 version of boost, but that didn't provide a needed function. There wasn't a 1.40 version in koji. We didn't have time to build 1.40 from source.

From your reference to Koji, I understand that you have tried with Fedora, but it is not clearly stated.
As for the version of Boost, we (Fedora packagers) went directly from 1.39 to 1.41. So, it is normal that you cannot find any released Boost 1.40 (though some temporary builds have been done in Koji for version 1.40, but the results have been removed, for sure, as they are no longer used).

I found a point to the probable resolution. I can test it on Monday when I have access to hardware to test it on.
Here is a quote from a mailing list discussion about the bug:
Hi, there. Found issue was really related to CRC check on x86_64 platform.
The related ticket is #3352 (https://svn.boost.org/trac/boost/ticket/3352)
and changeset that resolves the issue is
https://svn.boost.org/trac/boost/changeset/57610.
After applying this change to 1.41, the regression disappeared.

I was able to successfully run rpmbuild with the upstream patch. I will do a before and after test tomorrow when it will be a lot easier to test using Wesnoth at the x64_64 machine.

Thanks for the investigation.  I checked the sources, and the patch seems sensible (even though it's a bit weird to have two names for uint32_t...).  I'll apply it.

The f14 build isn't installable on my F13 system. My test build with the patch doesn't appear to solve the problem.
I'll either end up doing a scratch build of your version for F13 (instead of a local build) and/or I'll do some more digging to see if there is a similar problem in some other part of the compression filter support.

Sorry, it totally didn't occur to me that devel version obviously doesn't solve your problem.  I'm spinning an F-13 build right now.

Try this build please http://koji.fedoraproject.org/koji/taskinfo?taskID=2179395

I am out sick today, so I won't be able to touch my x86_64 until tomorrow.
I might be able to try it out today with vnc, but that is iffy.
Thanks for doing the scratch build.

I've installed scratch build from comment #11 and wesnoth still does not connect to the server

I'll do a test of the scratch build in a few hours. I'll also test using the i686 version of wesnoth on x86_64 to confirm that this changes the behavior. (That was the work around used by one of the community gaming participants.) I'll also look over the other reports more carefully. I thought there was a comment that one patch fixed things, so that I would have expected the CRC patch to have solved the problem.

I was able to confirm that the scratch build did NOT fix the problem.
I also confirmed that the i686 version of wesnoth was able to connect to the server on an x86_64 machine when the x86_64 version wasn't able to.
I'll do some more reading up on the problem and see if I can figure out what the rest of the puzzle is.
Testing will be slow going for me since I don't get that much time to test stuff on the x86_64 machine.

I checked the patch that supposedly fixed the problem for arch linux and it appears to be the same one.
Maybe there are really two problems, one with boost and one someplace else.

I suspect that I know the answer. zlib.hpp is part of boost-devel. Most likely wesnoth will need to be rebuilt with the new boost-devel. I'll be testing that theory tomorrow.

(In reply to comment #17)
> I suspect that I know the answer. zlib.hpp is part of boost-devel. Most likely
> wesnoth will need to be rebuilt with the new boost-devel. I'll be testing that
> theory tomorrow.    

I've tried locally rebuilt wesnoth with that scratch build of boost and it works for me now, I can successfully connect to the server

I tested my rebuilt version of Wesnoth and it does appear to work properly now.

It would be nice to get boost and wesnoth chain built so that we could test both updates at once. Otherwise the wesnoth update will need to wait until the boost update is in stable updates.

I can commit the relevant changes to wesnoth so the chain build can be done.  What branches, just devel and F-13?

I don't think Wesnoth needs any changes other than a version bump. The current builds used a bad zlib.hpp header and the correct one will be used if it is based on a fixed copy of boost.
It looks like the 1.41 version of boost is only on F13 and F14. So those should be the only branches needing rebuilds.
Checking things out, I see F14 already has the new version of boost, so you should be able to do a rebuild in F14 right now.
The F13 branch of boost doesn't have the change committed yet (probably the scratch build was using the F14 version with a dist-f13 target). So that will need to be coordinated with Petr.

I've committed the changes.  According to this site:
  http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained_builds
"""chain-builds only work when building on the devel/ branch. [otherwise] open a ticket with the Release Engineering team asking for earlier built packages to be included in the proper buildroot."""

Devel branch is already built, so I started a build for F 13, and will push that to testing afterwards.  I'm wondering about opening that ticket, wouldn't that push boost effectively to stable?

Wesnoth devel rebuild is in progress, should finish soon.

I did a real quick test of wesnoth-1.8.1-2.fc14.x86_64 on F13 with the boost scratch build installed and it was able to connect to the official server. So I think the F14 build of Wesnoth is good.

boost-1.41.0-8.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/boost-1.41.0-8.fc13

boost-1.41.0-8.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update boost'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/boost-1.41.0-8.fc13

Do you think you are going to be comfortable pushing the update to testing in the next day or two? There was some positive feedback, but the testing was fairly limited.
If not, then we should look at asking Releng to help with building Wesnoth using the update. I wouldn't think Wesnoth would need a lot of testing (mainly just checking that bug is resolved in the new build), but it would be nice to have the weekend to do some sanity testing.
We'd really like to have the fixed update in the updates repository by late Monday so people don't need to get it twice.

You mean to stable?  I requested karma automatism with the default threshold.  The patch made sense to me and seemed simple enough, is why.  It's now waiting for releng action to be pushed to stable, I believe it will happen before the end of the week.

Thanks, that's the answer I was looking for. I wasn't sure that it was set to move on karma. I saw we had three +1s and had expected it to have moved if that was the case. But it probably was just that there wasn't a push to stable since the third +1.
So hopefully it will move today or tomorrow.

boost-1.41.0-8.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.