New version released May 6th.
Created attachment 235277 [details] Ebuild created from boost-1.42.0-r1.ebuild. This seems to work for me. Note that 'random_device.cpp' moved, and no longer has an ifdef on __linux__. I'll attach my updated jamfile next.
Created attachment 235279 [details] Jamfile for Boost.Random (new version of random-Jamfile). Fixed 'random-Jamfile' to work for the 1.43.0 location of the source for Boost.Random.
Created attachment 235281 [details, diff] Same as the one for 1.42.0.
Created attachment 235283 [details, diff] Same as the one for 1.42.0.
Created attachment 235285 [details, diff] Same as the one for 1.42.0.
(In reply to comment #1) > Created an attachment (id=235277) [details] > Ebuild created from boost-1.42.0-r1.ebuild. > > This seems to work for me. Note that 'random_device.cpp' moved, and no longer > has an ifdef on __linux__. I'll attach my updated jamfile next. > Okay, I've attached all the files I used locally. I have not done a lot of testing, but everything compiles, and it's working for my projects. This should be a start for the maintainer.
I'll fix encfs before further work on boost.
(In reply to comment #7) > I'll fix encfs before further work on boost. encfs-1.6 should work now and upstream says it's tested with 1.43, but better test anyway (I didn't)
Successfully installed boost-1_43. Thanks, Duncan. Only patch >boost-1.43.0-template_arity-gcc45.patch< did not succeed, I think they changed/fixed it upstream. Meanwhile, boost-1.44 beta will be available by next week - and final another two weeks later - I think the 'official portage version' should concentrate on 1.44 and leave out 1.43. Just my thinking.
*** Bug 333141 has been marked as a duplicate of this bug. ***
FYI. From my tests it seems like 1.44.0 doesn't compile without dev-libs/icu.
Created attachment 244271 [details, diff] Patch for boost-build-1.44.0 to fix compilation with -q -q (abort on first error) has problems with newly introduced configure checks like regex uses to detect ICU. This patch fixes the problem.
Created attachment 244273 [details, diff] Patch to fix two issues with spirit attributes Adds a missing include and fixes BOOST_SPIRIT_DEBUG_NODE with optionals.
1.44 has been release a month ago on August 13th. Portage currently has version 1.42 that has been released on February 2nd. Can someone please attach an ebuild for 1.44 I can test? Maybe we can have it in portage before 1.45 is out.
is there anything stopping this other than an ebuild writing?
Yes: a dev who's interested in getting this going.
(In reply to comment #16) > Yes: a dev who's interested in getting this going. > I could start proxy maintaining if there's a user interested.
I'm interested.
me too
Look at the CC list. There are interested users who do not understand why it takes October-May = 6 months to upgrade, like Debian. Where is the tracker for all the packages broken by this upgrade? There isn't one. AFAIK, nothing breaks.
(In reply to comment #20) > Look at the CC list. There are interested users who do not understand why it > takes October-May = 6 months to upgrade, like Debian. Where is the tracker for > all the packages broken by this upgrade? There isn't one. AFAIK, nothing > breaks. > Well Boost is always the slowest thing to update. You could try getting the 1.43 ebuild at the top, put the 1.44.0 patches in and try and compile the 1.44 version
Is there any chance to get 1.44 in the portage tree finally???
We have to wait for someone to make an ebuild. But I was looking on the forum, and it seems they are wanting to split the ebuild up (I don't know what's the obsession with split ebuilds).
(In reply to comment #23) > We have to wait for someone to make an ebuild. But I was looking on the forum, > and it seems they are wanting to split the ebuild up (I don't know what's the > obsession with split ebuilds). Looking at long boost build times, it might be quite reasonable.
I honestly don't see long build times. It only takes 15 minutes to compile, but then again I have a fast cpu :P
I'd frankly rather see Boost 1.43.0 in the tree (for which I attached an ebuild way back in June) than 1.44.0, if I had to pick one. Boost 1.44.0 has had a number of issues. For example, Boost.Serialization broke backwards compatibility of archives: https://svn.boost.org/trac/boost/ticket/4660 I've read other complaints about the quality of 1.44.0, although I think they are mostly related to mingw. If there's any interest, I can attach my current ebuild for 1.43.0 -- it needed a bunch of changes at some point due to a change in the python eclass.
(In reply to comment #26) > If there's any interest, I can attach my current ebuild for 1.43.0 I'm interested.
Created attachment 253747 [details] 1.43.0 ebuild (with updates to match 1.42.0). Here's my current 1.43.0 ebuild, which is based off of boost-1.42.0-r2.
Created attachment 253793 [details] closer to 1.42.0-r2 Your ebuild seems based on 1.42.0 , not -r2 , because it lacks the ${P}-gcc45-python.patch (and from the header). Why did you remove the code to build the boost.random library with /dev/urandom support on non-Linux platforms too? This ebuild adds both.
Created attachment 253795 [details] dev-util/boost-build updated for 1.43.0 The missing patch from 1.42 is already upstream.
(In reply to comment #29) > Created an attachment (id=253793) [details] > closer to 1.42.0-r2 > > Your ebuild seems based on 1.42.0 , not -r2 , because it lacks the > ${P}-gcc45-python.patch (and from the header). You're right --- I mispoke. I didn't look very carefully at -r2. I created this from 1.42.0 originally, and have been updating it periodically to keep it working on my system. I did a quick diff against r2, and it looked similar enough. > Why did you remove the code to > build the boost.random library with /dev/urandom support on non-Linux platforms > too? See comment #1.
Created attachment 253827 [details] farther from 1.42.0-r2 As per comment #1 :)
it is time to start a new version bump bug.... boost 1.45 is out! http://www.boost.org/users/news/version_1_45_0
It seems that something changed with boost-build for 1.45.0. At least I couldn't reuse the old ebuild, but I am at lost how to fix it. Could someone post the ebuilds for 1.45, pretty please?
Created attachment 255129 [details] ebuild for boost-build-1.45.0 (based on boost-build-1.42.0) "jam/src" got moved to "build/v2/engine/src". Also, the patches from 1.42.0 are both upstream now.
(In reply to comment #35) > Created an attachment (id=255129) [details] > ebuild for boost-build-1.45.0 (based on boost-build-1.42.0) Note: I haven't used or tested this at all (or even merged it). I just confirmed that "ebuild boost-build-1.45.0 install" will run without error.
@35: Thanks a lot for the quick reply!
I can confirm that boost-build-1.45.0.ebuild (2010-11-22 19:25) and renamed versions of the following files: remove-toolset-1.43.0.patch (2010-06-14 16:27) boost-1.43.0-random-Jamfile (2010-06-14 16:25) boost-1.43.0.ebuild (2010-11-10 01:30) with these lines removed: # bug 291660 epatch "${FILESDIR}/boost-${PV}-parameter-needs-python.patch" epatch "${FILESDIR}"/${P}-gcc45-python.patch successfully build and install boost-1.45.0. I have built another project against the installed libraries and everything seems to be running fine.
I have installed 1.45.0 and briefly tested a few applications that depend on it, everything seems fine.
(In reply to comment #35) > Created an attachment (id=255129) [details] > ebuild for boost-build-1.45.0 (based on boost-build-1.42.0) > > "jam/src" got moved to "build/v2/engine/src". > > Also, the patches from 1.42.0 are both upstream now. > Excellent! i struggled a week for changing the ebuild from 1.42 to meet my requirement but now finished with just a search in bugzilla~ After a partial test with my 10+ boost-depended program everything seems to work fine, i thought the version bump should be accepted quickly.
Boost has no maintainer at the moment http://archives.gentoo.org/gentoo-dev/msg_b6189d38cebbc4fd482e4aabcc73d524.xml I plan to take over this package and start working on boost version bump in my overlay[1]. If you need write access so you can help me develop the ebuilds for that send me an email including your ssh pub key. [1] http://git.overlays.gentoo.org/index_maintenance.html?p=dev/hwoarang.git;a=tree
I have compiled 19 packages with boost-1.45 and didn't run into a single issue. Those ebuild work like a charm!
(In reply to comment #42) > I have compiled 19 packages with boost-1.45 and didn't run into a single issue. > Those ebuild work like a charm! Which ebuilds are you talking about? There is no ebuild for boost-1.45.0 attached to the bug report atm, and the one from hwoarang's overlay does not work. (It's missing two patch files.)
(In reply to comment #43) > (In reply to comment #42) > > I have compiled 19 packages with boost-1.45 and didn't run into a single issue. > > Those ebuild work like a charm! > > Which ebuilds are you talking about? There is no ebuild for boost-1.45.0 > attached to the bug report atm, and the one from hwoarang's overlay does not > work. (It's missing two patch files.) > The ebuilds from my overlay should be ok now. I fixed the remaining build problems ( at least those that I was able to identify )
(In reply to comment #44) > The ebuilds from my overlay should be ok now. I fixed the remaining build > problems ( at least those that I was able to identify ) That was fast. The ebuild works now and at least on of my projects that uses boost builds cleanly against it.
On tree ( masked ). They will remain masked for further testing. Thanks to everybody for the ebuilds
(In reply to comment #46) > On tree ( masked ). They will remain masked for further testing. Thanks to > everybody for the ebuilds > Great! Already testing now... :) Btw, what do you think of geki's idea to make more boost libraries optional (via USE flags) as described in #310207? He has done the legwork to split them into different ebuilds already and move code into eclass, which could be adapted...
(In reply to comment #47) > Btw, what do you think of geki's idea to make more boost libraries optional > (via USE flags) as described in #310207? He has done the legwork to split them > into different ebuilds already and move code into eclass, which could be > adapted... Geki's eclass has at least one siginificant problem - it install boost documentation in different directories (one per package) which makes it hard to use
Well, I do think it would need adaptation, I am sure it is possible to change that behaviour. Anyway, I can not report any issues on my system using boost-1.45. Meanwhile, 1.46 is out.
(In reply to comment #49) > Meanwhile, 1.46 is out I've been working on resolving conflicts with the filesystem v3 api which is the default for 1.46. see blockers for Bug 356479
