Bug 590205 - Boost 1.41 has a gzip issue on x86_64
Summary: Boost 1.41 has a gzip issue on x86_64
Alias: None
Product: Fedora
Classification: Fedora
Component: boost
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Benjamin Kosnik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-08 04:25 UTC by Bruno Wolff III
Modified: 2013-08-09 05:49 UTC (History)
7 users (show)

Fixed In Version: boost-1.41.0-8.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-19 19:12:44 UTC
Type: ---

Attachments (Terms of Use)

Description Bruno Wolff III 2010-05-08 04:25:23 UTC
Description of problem:
This is noticeable in Wesnoth when trying to connect to a multiplayer game server. This doesn't work on x86_64, but does on i386.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Bruno Wolff III 2010-05-08 04:26:07 UTC
I added Jon in case someone reports this against Wesnoth instead of Boost.

Comment 2 Bruno Wolff III 2010-05-08 04:27:01 UTC
I forgot to mention the symptom is the attempt to join the server hanging on x86_64.

Comment 3 Denis Arnaud 2010-05-08 14:48:44 UTC
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?

Comment 4 Bruno Wolff III 2010-05-08 15:34:19 UTC
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.

Comment 5 Denis Arnaud 2010-05-08 15:53:13 UTC
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).

Comment 6 Bruno Wolff III 2010-05-09 16:17:43 UTC
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
After applying this change to 1.41, the regression disappeared.

Comment 7 Bruno Wolff III 2010-05-09 18:01:43 UTC
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.

Comment 8 Petr Machata 2010-05-10 13:28:05 UTC
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.

Comment 9 Bruno Wolff III 2010-05-10 20:23:30 UTC
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.

Comment 10 Petr Machata 2010-05-11 09:39:58 UTC
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.

Comment 11 Petr Machata 2010-05-11 10:16:31 UTC
Try this build please http://koji.fedoraproject.org/koji/taskinfo?taskID=2179395

Comment 12 Bruno Wolff III 2010-05-11 13:08:03 UTC
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.

Comment 13 Michal Hlavinka 2010-05-12 10:20:03 UTC
I've installed scratch build from comment #11 and wesnoth still does not connect to the server

Comment 14 Bruno Wolff III 2010-05-12 13:11:59 UTC
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.

Comment 15 Bruno Wolff III 2010-05-12 21:26:10 UTC
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.

Comment 16 Bruno Wolff III 2010-05-13 03:41:37 UTC
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.

Comment 17 Bruno Wolff III 2010-05-13 04:00:31 UTC
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.

Comment 18 Michal Hlavinka 2010-05-13 07:16:57 UTC
(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

Comment 19 Bruno Wolff III 2010-05-13 14:54:09 UTC
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.

Comment 20 Gwyn Ciesla 2010-05-13 15:10:31 UTC
I can commit the relevant changes to wesnoth so the chain build can be done.  What branches, just devel and F-13?

Comment 21 Bruno Wolff III 2010-05-13 15:52:04 UTC
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.

Comment 22 Petr Machata 2010-05-13 17:10:08 UTC
I've committed the changes.  According to this site:
"""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?

Comment 23 Gwyn Ciesla 2010-05-13 17:25:42 UTC
Wesnoth devel rebuild is in progress, should finish soon.

Comment 24 Bruno Wolff III 2010-05-13 20:50:59 UTC
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.

Comment 25 Fedora Update System 2010-05-14 00:48:26 UTC
boost-1.41.0-8.fc13 has been submitted as an update for Fedora 13.

Comment 26 Fedora Update System 2010-05-15 20:17:06 UTC
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

Comment 27 Bruno Wolff III 2010-05-19 13:25:46 UTC
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.

Comment 28 Petr Machata 2010-05-19 14:31:52 UTC
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.

Comment 29 Bruno Wolff III 2010-05-19 14:44:01 UTC
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.

Comment 30 Fedora Update System 2010-05-19 19:12:40 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.