Re: boost 1.46.0
On Sat, 2011-02-05 at 11:05 +0100, Petr Machata wrote: 04.02.2011 14:33, Petr Machata wrote: I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. The packages that I tried built OK, so I'm calling this good enough, and spinning an official build now. The list of ABI dependences is here. These packages really really need to be rebuilt, otherwise they'll stop working (soname bump on boost side) after the new boost gets into the build root. I can't rebuild other people's packages, so I can't do any of this myself. It would probably be a good idea to apply for provenpackager status then. IMHO, being the maintainer of a component on which multiple other packages depend is a pretty good justification for being a provenpackager. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
07.02.2011 20:03, Zach Carter wrote: I believe my package schroot may have been hit by a 1.46 issue that is fixed in 1.47 Is there a plan to update to 1.47 or backport the fixes? Not in a systematic manner, but generally yes, we do fixes of this sort. From the 1.47 changelog: Doc fixes: Update release history, add tables of macros and deprecated names. Bug fix: convenience.hpp didn't fully apply BOOST_FILESYSTEM_NO_DEPRECATED to name changes. Bug fix: Ticket #1972 'remove' fixes. Bug fix: Restore deprecated basic_directory_entry names inadvertently removed. Bug fix: Provide deprecated functions has_branch_path and has_leaf, inadvertently omitted from 1.36.0 Add workarounds for Codegear/Borland C++ Builder 2009. Actually I found the above in 1.37 (not 47) changelog. The ticket #1972 has been closed for years. See: http://www.boost.org/doc/libs/1_45_0/libs/filesystem/v2/doc/index.htm From http://koji.fedoraproject.org/koji/getfile?taskID=2765676name=build.log: sbuild-chroot-config.cc: In member function 'void sbuild::chroot_config::add_config_directory(const string, const string)': sbuild-chroot-config.cc:170:32: error: 'class boost::filesystem3::directory_entry' has no member named 'leaf' If there's a lot of problems like this, compile with -DBOOST_FILESYSTEM_VERSION=2 and have upstream decide what to do long-term. In this particular case, you should be able to replace leaf() with path().filename().string(). PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Tuesday, February 08, 2011 04:43:37 am Petr Machata wrote: Actually I found the above in 1.37 (not 47) changelog. The ticket #1972 has been closed for years. See: http://www.boost.org/doc/libs/1_45_0/libs/filesystem/v2/doc/index.htm Oops, my bad for substituting s/4/3/ somehow in my head, thanks for correcting me. From http://koji.fedoraproject.org/koji/getfile?taskID=2765676name=build.log: sbuild-chroot-config.cc: In member function 'void sbuild::chroot_config::add_config_directory(const string, const string)': sbuild-chroot-config.cc:170:32: error: 'class boost::filesystem3::directory_entry' has no member named 'leaf' If there's a lot of problems like this, compile with -DBOOST_FILESYSTEM_VERSION=2 and have upstream decide what to do long-term. In this particular case, you should be able to replace leaf() with path().filename().string(). This worked perfectly, thanks! -Zach -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Friday, February 04, 2011 05:33:24 am Petr Machata wrote: Hi, beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. PM References: [1] http://fedoraproject.org/wiki/Features/F15Boost146 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2760766 I believe my package schroot may have been hit by a 1.46 issue that is fixed in 1.47 Is there a plan to update to 1.47 or backport the fixes? From the 1.47 changelog: Doc fixes: Update release history, add tables of macros and deprecated names. Bug fix: convenience.hpp didn't fully apply BOOST_FILESYSTEM_NO_DEPRECATED to name changes. Bug fix: Ticket #1972 'remove' fixes. Bug fix: Restore deprecated basic_directory_entry names inadvertently removed. Bug fix: Provide deprecated functions has_branch_path and has_leaf, inadvertently omitted from 1.36.0 Add workarounds for Codegear/Borland C++ Builder 2009. From http://koji.fedoraproject.org/koji/getfile?taskID=2765676name=build.log: sbuild-chroot-config.cc: In member function 'void sbuild::chroot_config::add_config_directory(const string, const string)': sbuild-chroot-config.cc:170:32: error: 'class boost::filesystem3::directory_entry' has no member named 'leaf' -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Sat, 05 Feb 2011 11:05:57 +0100 Petr Machata wrote: 04.02.2011 14:33, Petr Machata wrote: I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. [snip] I'll check my mail later today, and see if anything wildly wrong goes on. I just rebuild my package and tried a random other one: xsd and it failed: http://koji.fedoraproject.org/koji/taskinfo?taskID=2764873 Will try to rebuild some other too, and keep an updated todo list at: http://tomspur.fedorapeople.org/boost_upgrade/ in failed, are noted, which packages failed to build because of the boost upgrade. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
06.02.2011 15:44, Thomas Spura wrote:
I just rebuild my package and tried a random other one: xsd and it
failed:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2764873
From the looks of it, this is the case of boost::filesystem v2 vs. v3.
This will get rid of it:
diff --git a/xsd.spec b/xsd.spec
index 6ab29ce..6584f3e 100644
--- a/xsd.spec
+++ b/xsd.spec
@@ -58,7 +58,7 @@ popd
%if 0%{?el5}
make verbose=1 CXXFLAGS=$RPM_OPT_FLAGS -g1 BOOST_LINK_SYSTEM=n
%else
-make verbose=1 CXXFLAGS=$RPM_OPT_FLAGS
+make verbose=1 CXXFLAGS=$RPM_OPT_FLAGS -DBOOST_FILESYSTEM_VERSION=2
%endif
It seems to progress well after that change.
Will try to rebuild some other too, and keep an updated todo list at:
http://tomspur.fedorapeople.org/boost_upgrade/
in failed, are noted, which packages failed to build because of the
boost upgrade.
Thanks, that will be cool.
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On 02/04/2011 03:38 PM, Petr Machata wrote: 04.02.2011 21:10, Bastien Nocera wrote: Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? What you are hitting here seems more related to gcc or binutils change. For some reason g++ -R isn't valid anymore. Passing this as g++ -Wl,-R fixes the problem (or at least works around it). FWIW I don't see -R in gcc manual on F14, must have been obsolete for a bit already. Later in the build and throughout it hits a problem in libsigc++, which doesn't #include cstddef. You will need to do that including yourself before it's fixed in libsigc++. fwiw, libsigc++ got fixed on Friday so that portion of the patch is no longer needed. http://koji.fedoraproject.org/koji/buildinfo?buildID=217049 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
04.02.2011 14:33, Petr Machata wrote: I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. The packages that I tried built OK, so I'm calling this good enough, and spinning an official build now. The list of ABI dependences is here. These packages really really need to be rebuilt, otherwise they'll stop working (soname bump on boost side) after the new boost gets into the build root. I can't rebuild other people's packages, so I can't do any of this myself. CGAL-3.6.1-2.fc15.src.rpm HippoDraw-1.21.1-12.fc15.src.rpm LuxRender-0.7.1-2.fc15.src.rpm QuantLib-1.0.1-4.fc15.src.rpm akonadi-1.5.0-1.fc15.src.rpm aqsis-1.6.0-5.fc14.src.rpm asc-2.2.0.0-9.fc15.src.rpm avogadro-1.0.1-11.fc15.src.rpm barry-0.17-0.6.20110126git.fc15.src.rpm bastet-0.43-8.fc15.src.rpm chess-1.0-31.fc15.src.rpm compiz-0.9.2.2-0.11.git619abc05b1.fc15.src.rpm compiz-fusion-extras-0.9.2.1-2.fc15.src.rpm compiz-fusion-unsupported-0.9.2.1-4.fc15.src.rpm compiz-plugins-main-0.9.2.1-7.fc15.src.rpm easystroke-0.5.3-2.fc15.src.rpm ekiga-3.3.0-4.fc15.src.rpm ember-0.6.0-1.fc15.src.rpm esperanza-0.4.0-8.20100601git.fc15.src.rpm fatrat-1.1.3-2.fc15.src.rpm fawkes-0.4.1-1.fc15.src.rpm fife-0.3.2-1.fc15.src.rpm fuse-encfs-1.7.2-1.fc15.src.rpm fusecompress-2.6-8.20100223git754bc0de.fc15.src.rpm glob2-0.9.4.4-2.fc15.src.rpm glom-1.15.1-1.fc15.src.rpm gnash-0.8.8-4.fc15.src.rpm gnote-0.7.3-4.fc15.src.rpm gnuradio-3.2.2-8.fc15.src.rpm gpsdrive-2.11-1.fc15.src.rpm hugin-2010.4.0-1.fc15.src.rpm k3d-0.8.0.1-4.fc15.src.rpm kdeedu-4.6.0-1.fc15.src.rpm libcompizconfig-0.9.2.1-5.fc15.src.rpm liborigin2-13092010-1.fc15.src.rpm libpst-0.6.49-2.fc15.src.rpm lyx-2.0.0-0.11.beta3.fc15.src.rpm mapnik-0.7.1-6.fc14.src.rpm mbox2eml-0.1.1-4.fc14.src.rpm minion-0.10-4.fc15.src.rpm mkvtoolnix-4.4.0-1.fc15.src.rpm mongodb-1.6.4-3.fc15.src.rpm mygui-3.0.1-3.fc15.src.rpm ogre-1.7.2-8.fc15.src.rpm openvrml-0.18.6-4.fc14.1.src.rpm pingus-0.7.2-11.fc15.src.rpm player-3.0.2-5.fc15.src.rpm plee-the-bear-0.4.1-8.fc15.src.rpm pokerth-0.8.3-1.fc15.src.rpm pyactivemq-0.1.0-8.20100214svn209.fc15.src.rpm pyexiv2-0.3.0-1.fc15.src.rpm pymilia-0.3.0-4.fc15.src.rpm python-polybori-0.5-11.fc15.src.rpm python-tag-0.94.5-6.fc14.src.rpm python-visual-5.40-2.fc15.src.rpm qbittorrent-2.6.4-2.fc15.src.rpm qpid-cpp-0.8-2.fc15.src.rpm rb_libtorrent-0.14.11-1.fc15.src.rpm rcsslogplayer-14.0.1-3.fc15.src.rpm rcssmonitor-14.1.0-2.fc15.src.rpm rcssserver-14.0.3-2.fc15.src.rpm referencer-1.1.6-12.fc15.src.rpm rmol-0.23.1-1.fc15.src.rpm schroot-1.4.10-1.fc15.src.rpm simspark-0.2.1-3.fc15.src.rpm soci-3.0.0-18.fc15.src.rpm source-highlight-3.1.4-1.fc15.src.rpm spring-0.82.7.1-1.fc15.src.rpm springlobby-0.120-1.fc15.src.rpm swift-1.0-0.7.beta8.fc15.src.rpm torium-0.4.2-10.fc15.src.rpm twinkle-1.4.2-7.fc15.src.rpm urg-0.8.7-4.fc15.src.rpm vegastrike-0.5.0-19.fc15.src.rpm vigra-1.7.0-2.fc15.src.rpm votca-csg-1.0.1-2.fc15.src.rpm votca-tools-1.0.1-3.fc15.src.rpm wesnoth-1.8.5-2.fc15.src.rpm widelands-0-0.20.Build14.fc15.src.rpm xsd-3.3.0-2.fc15.src.rpm I'll check my mail later today, and see if anything wildly wrong goes on. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Sat, Feb 05, 2011 at 11:05:57 +0100, Petr Machata pmach...@redhat.com wrote: The packages that I tried built OK, so I'm calling this good enough, and spinning an official build now. The list of ABI dependences is here. These packages really really need to be rebuilt, otherwise they'll stop working (soname bump on boost side) after the new boost gets into the build root. I can't rebuild other people's packages, so I can't do any of this myself. There's going to be a mass rebuild shortly, so those packages should all be rebuilt soon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
Bruno Wolff III wrote: There's going to be a mass rebuild shortly, so those packages should all be rebuilt soon. But the way our mass rebuilds are done does not work for dependency chains where all involved packages have to be rebuilt in reverse dependency order to fix the broken dependency on the old Boost. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boost 1.46.0
Hi, beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. PM References: [1] http://fedoraproject.org/wiki/Features/F15Boost146 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2760766 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
Petr Machata wrote: beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. repoquery --archlist=src --repoid=rawhide-source -q \ --whatrequires boost-devel | wc -l returns 163 for me. On quick inspection, I didn't see too much in said list that's too critpath'y (though I did see some a couple of items low in the kde stack, akonadi and kdepimlibs), but wondering if this is worthy of introducing a side koji tag to do the necessary rebuilds. It may also depend on the risk of api breakage here. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
Rex Dieter (rdie...@math.unl.edu) said: Petr Machata wrote: beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. repoquery --archlist=src --repoid=rawhide-source -q \ --whatrequires boost-devel | wc -l returns 163 for me. On quick inspection, I didn't see too much in said list that's too critpath'y (though I did see some a couple of items low in the kde stack, akonadi and kdepimlibs), but wondering if this is worthy of introducing a side koji tag to do the necessary rebuilds. It may also depend on the risk of api breakage here. Note that we already have one package that isn't building against current boost in F-15: https://bugzilla.gnome.org/show_bug.cgi?id=641416 I'm assuming that could be fixed while we're rebuilding? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Fri, 2011-02-04 at 14:33 +0100, Petr Machata wrote: Hi, beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? Because of boost changes between December and yesterday, I wasn't able to recompile gnote: https://bugzilla.gnome.org/show_bug.cgi?id=641416 The build failures are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872 It's critical if we want gnote in F15's GNOME desktop. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On 2/4/11 3:10 PM, Bastien Nocera wrote: On Fri, 2011-02-04 at 14:33 +0100, Petr Machata wrote: Hi, beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? Because of boost changes between December and yesterday, I wasn't able to recompile gnote: https://bugzilla.gnome.org/show_bug.cgi?id=641416 The build failures are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872 It's critical if we want gnote in F15's GNOME desktop. Isn't boost.m4 just some third-party macro? Perhaps upstream could be encouraged not to use it? It seems rather pointless to me. That is, it looks like it's checking a bunch of things that don't need checking. AFAIK, the only configuration information one needs to divine about Boost is the library name suffix. If one guesses that Boost libraries will end in -mt, one will be correct a large majority of the time. When that's wrong, one might want to make a few other guesses--or punt and make the user supply the suffix at configure time (which is not at all unreasonable, since the complete list of possible suffixes is *quite* long). Braden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Fri, 2011-02-04 at 15:41 -0500, Braden McDaniel wrote: On 2/4/11 3:10 PM, Bastien Nocera wrote: On Fri, 2011-02-04 at 14:33 +0100, Petr Machata wrote: Hi, beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? Because of boost changes between December and yesterday, I wasn't able to recompile gnote: https://bugzilla.gnome.org/show_bug.cgi?id=641416 The build failures are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872 It's critical if we want gnote in F15's GNOME desktop. Isn't boost.m4 just some third-party macro? Perhaps upstream could be encouraged not to use it? It seems rather pointless to me. That is, it looks like it's checking a bunch of things that don't need checking. AFAIK, the only configuration information one needs to divine about Boost is the library name suffix. If one guesses that Boost libraries will end in -mt, one will be correct a large majority of the time. When that's wrong, one might want to make a few other guesses--or punt and make the user supply the suffix at configure time (which is not at all unreasonable, since the complete list of possible suffixes is *quite* long). I'm pretty sure the gnote developers would take any patches to remove that code, as long as it did detection as you mentioned above. If boost provided a pkg-config file, or their own macros, I'm pretty sure that gnote wouldn't be using it. I don't know enough about boost to make those changes myself, and wading through 2 tarballs of 40 megs each to figure out the library layout of boost is a bit beyond me. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On 2/4/11 4:11 PM, Bastien Nocera wrote:
On Fri, 2011-02-04 at 15:41 -0500, Braden McDaniel wrote:
On 2/4/11 3:10 PM, Bastien Nocera wrote:
[snip]
Could we please either have boost.m4 packaged in Fedora, or at least
changes for running with the latest boost in Fedora integrated upstream?
Because of boost changes between December and yesterday, I wasn't able
to recompile gnote:
https://bugzilla.gnome.org/show_bug.cgi?id=641416
The build failures are here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872
It's critical if we want gnote in F15's GNOME desktop.
Isn't boost.m4 just some third-party macro?
Perhaps upstream could be encouraged not to use it?
[snip]
I'm pretty sure the gnote developers would take any patches to remove
that code, as long as it did detection as you mentioned above. If boost
provided a pkg-config file, or their own macros, I'm pretty sure that
gnote wouldn't be using it.
I don't know enough about boost to make those changes myself, and wading
through 2 tarballs of 40 megs each to figure out the library layout of
boost is a bit beyond me.
I am pretty sure that wading is unnecessary.
All I do in my own Boost-dependent project is this:
---
AS_IF([test -z ${BOOST_LIB_SUFFIX+x}], [BOOST_LIB_SUFFIX=-mt])
AC_ARG_VAR([BOOST_LIB_SUFFIX], [Boost library name suffix [default=-mt]])
AC_CACHE_CHECK([for boost_thread$BOOST_LIB_SUFFIX library],
[ov_cv_boost_thread],
[ov_cv_boost_thread=no
ov_save_LIBS=$LIBS
LIBS=-lboost_thread$BOOST_LIB_SUFFIX $LIBS
AC_LANG_PUSH([C++])
AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include boost/thread.hpp]],
[[boost::thread t]])],
[ov_cv_boost_thread=yes])
AC_LANG_POP
LIBS=$ov_save_LIBS
])
AS_IF([test X$ov_cv_boost_thread = Xno],
[AC_MSG_FAILURE([libboost_thread$BOOST_LIB_SUFFIX not found])])
---
Then, references to Boost libraries in Makefile.am need to look like
-lboost_foo$BOOST_LIB_SUFFIX.
And you're done.
As you can see, I don't do any detection of the Boost library suffix;
and I don't have a very high opinion of attempts to do so. Indeed, I'm
generally of the mind that attempts simply to detect features that are
implemented consistently (when present at all) are misguided. When such
diagnostics are trivial or incidental, they're fine. But as soon as
they're the least bit nontrivial, you've got an unnecessary test that
can break--and that's a very silly reason for your package to stop building.
Braden
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
04.02.2011 14:59, Rex Dieter wrote: Petr Machata wrote: beta of boost-1.46.0 was released recently and packaged yesterday. It's now in the git, and a scratch build[2] was done. This is in preparation for final release that should be out on 7th, just before the feature freeze. Providing boost-1.46.0 is one of features of F15[1]. I'm in the process of test-driving a couple packages locally to make sure that the new boost works. If that turns out well, I'll do a non-scratch build of boost-1.46.0-0.beta1 later today. repoquery --archlist=src --repoid=rawhide-source -q \ --whatrequires boost-devel | wc -l returns 163 for me. I used this: repoquery -s --whatrequires libboost\* | sort -u | wc -l which returns actual src.rpm of packages that depend on one of boost DSOs. There's 81 of them. Those are packages that really need rebuilding against the new boost, because they won't work otherwise. Packages that use header-only libraries linked essentially statically. On quick inspection, I didn't see too much in said list that's too critpath'y (though I did see some a couple of items low in the kde stack, akonadi and kdepimlibs), but wondering if this is worthy of introducing a side koji tag to do the necessary rebuilds. I rebuilt the following locally: akonadi-1.5.0-1.fc15.src.rpm aqsis-1.6.0-5.fc14.src.rpm asc-2.2.0.0-9.fc15.src.rpm avogadro-1.0.1-11.fc15.src.rpm barry-0.17-0.6.20110126git.fc15.src.rpm bastet-0.43-8.fc15.src.rpm aqsis needs a couple patches, I'll file a bug for that. The rest built OK. I noticed that akonadi has a testsuite, which passed, and I played and got my ass kicked by bastet, which means that it probably works. I think that all means that the smoke test went rather OK. One point that will cause problems (that's one aqsis patch) is that boost::filesystem now defaults to V3 of the API, where before it defaulted to V2. These APIs are not fully compatible. If the package uses the functions that are missing in V3, the conservative thing to do is to pass -DBOOST_FILESYSTEM_VERSION=2 in CXXFLAGS or to #define the same in appropriate places. It may also depend on the risk of api breakage here. That's never too low with boost, but I wonder how much ABI changes can one do in course of two weeks worth of bugfixing. (Again, I'm more concerned about ABI breakages than API. Stuff will keep working in face of the latter.) PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
04.02.2011 21:10, Bastien Nocera wrote: Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? What you are hitting here seems more related to gcc or binutils change. For some reason g++ -R isn't valid anymore. Passing this as g++ -Wl,-R fixes the problem (or at least works around it). FWIW I don't see -R in gcc manual on F14, must have been obsolete for a bit already. Later in the build and throughout it hits a problem in libsigc++, which doesn't #include cstddef. You will need to do that including yourself before it's fixed in libsigc++. Yet later in the build it hits the problem with boost::filesystem that I talked about in another thread earlier today. Building against v2 works around this. Finally the build passes, except rpmbuild complains that two files are not available: /builddir/build/BUILDROOT/gnote-0.7.3-5.fc15.x86_64/usr/libexec/gnote-applet /builddir/build/BUILDROOT/gnote-0.7.3-5.fc15.x86_64/usr/lib64/bonobo/servers/GNOME_GnoteApplet.server Could that be related to --disable-applet that you added recently? I'm attaching a patch that addresses the points above, except the last one. Hope this helps, PM diff --git a/gnote-0.7.3-boost-filesystem.patch b/gnote-0.7.3-boost-filesystem.patch new file mode 100644 index 000..9d428f3 --- /dev/null +++ b/gnote-0.7.3-boost-filesystem.patch @@ -0,0 +1,14 @@ +diff -up gnote-0.7.3/configure\~ gnote-0.7.3/configure +--- gnote-0.7.3/configure~ 2010-11-04 14:20:08.0 +0100 gnote-0.7.3/configure 2011-02-04 23:54:01.0 +0100 +@@ -16394,7 +16394,7 @@ rm -f core conftest.err conftest_ipa8_co + LDFLAGS=$boost_save_LDFLAGS + LIBS=$boost_save_LIBS + if test x$boost_cv_lib_system = xyes; then +-boost_cv_lib_system_LDFLAGS=-L$boost_ldpath -R$boost_ldpath ++boost_cv_lib_system_LDFLAGS=-L$boost_ldpath -Wl,-R$boost_ldpath + break 6 + else + boost_failed_libs=$boost_failed_libs@$boost_lib@ + +Diff finished. Fri Feb 4 23:54:06 2011 diff --git a/gnote-0.7.3-signal.patch b/gnote-0.7.3-signal.patch new file mode 100644 index 000..6468e7f --- /dev/null +++ b/gnote-0.7.3-signal.patch @@ -0,0 +1,121 @@ +diff -urp gnote-0.7.3/src/addinmanager.hpp gnote-0.7.3-pm/src/addinmanager.hpp +--- gnote-0.7.3/src/addinmanager.hpp 2011-02-05 00:01:56.0 +0100 gnote-0.7.3-pm/src/addinmanager.hpp2011-02-05 00:11:50.0 +0100 +@@ -26,6 +26,7 @@ + #include map + #include string + ++#include cstddef + #include sigc++/signal.h + + #include sharp/modulemanager.hpp +diff -urp gnote-0.7.3/src/notebooks/notebookmanager.hpp gnote-0.7.3-pm/src/notebooks/notebookmanager.hpp +--- gnote-0.7.3/src/notebooks/notebookmanager.hpp 2010-09-26 10:44:19.0 +0200 gnote-0.7.3-pm/src/notebooks/notebookmanager.hpp 2011-02-05 00:11:50.0 +0100 +@@ -23,6 +23,7 @@ + #ifndef _NOTEBOOK_MANAGER_HPP__ + #define _NOTEBOOK_MANAGER_HPP__ + ++#include cstddef + #include sigc++/signal.h + #include gtkmm/liststore.h + #include gtkmm/treemodel.h +diff -urp gnote-0.7.3/src/note.hpp gnote-0.7.3-pm/src/note.hpp +--- gnote-0.7.3/src/note.hpp 2010-09-26 10:44:19.0 +0200 gnote-0.7.3-pm/src/note.hpp2011-02-05 00:11:50.0 +0100 +@@ -30,6 +30,7 @@ + + #include libxml/tree.h + ++#include cstddef + #include sigc++/signal.h + #include gtkmm/textbuffer.h + +diff -urp gnote-0.7.3/src/notemanager.hpp gnote-0.7.3-pm/src/notemanager.hpp +--- gnote-0.7.3/src/notemanager.hpp2010-09-26 10:44:19.0 +0200 gnote-0.7.3-pm/src/notemanager.hpp 2011-02-05 00:11:50.0 +0100 +@@ -28,6 +28,7 @@ + + #include gconf/gconf.h + ++#include cstddef + #include sigc++/signal.h + + #include preferences.hpp +diff -urp gnote-0.7.3/src/notetag.hpp gnote-0.7.3-pm/src/notetag.hpp +--- gnote-0.7.3/src/notetag.hpp2010-09-26 10:44:19.0 +0200 gnote-0.7.3-pm/src/notetag.hpp 2011-02-05 00:11:50.0 +0100 +@@ -24,6 +24,7 @@ + + #include string + ++#include cstddef + #include sigc++/signal.h + #include glibmm/refptr.h + #include gtkmm/textbuffer.h +diff -urp gnote-0.7.3/src/preferences.hpp gnote-0.7.3-pm/src/preferences.hpp +--- gnote-0.7.3/src/preferences.hpp2010-09-26 10:44:19.0 +0200 gnote-0.7.3-pm/src/preferences.hpp 2011-02-05 00:11:50.0 +0100 +@@ -25,6 +25,7 @@ + + #include string + #include gconf/gconf-client.h ++#include cstddef + #include sigc++/signal.h + + #include base/singleton.hpp +diff -urp gnote-0.7.3/src/prefskeybinder.hpp gnote-0.7.3-pm/src/prefskeybinder.hpp +--- gnote-0.7.3/src/prefskeybinder.hpp 2010-09-26 10:44:19.0 +0200 gnote-0.7.3-pm/src/prefskeybinder.hpp 2011-02-05 00:11:50.0 +0100 +@@ -23,6 +23,7 @@ + #define _PREFSKEYBINDER_HPP_ + + #include string ++#include cstddef + #include sigc++/signal.h + #include sigc++/slot.h + +diff -urp
Re: boost 1.46.0
05.02.2011 00:38, Petr Machata wrote: What you are hitting here seems more related to gcc or binutils change. For some reason g++ -R isn't valid anymore. Passing this as g++ -Wl,-R fixes the problem (or at least works around it). FWIW I don't see -R in gcc manual on F14, must have been obsolete for a bit already. I'm attaching a patch that addresses the points above, except the last one. Except that that patch changes the configure script instead of m4/boost.m4. That would be the more upstreamable solution, but would require autoreconf-ing or similar. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Sat, 2011-02-05 at 00:38 +0100, Petr Machata wrote: 04.02.2011 21:10, Bastien Nocera wrote: Could we please either have boost.m4 packaged in Fedora, or at least changes for running with the latest boost in Fedora integrated upstream? What you are hitting here seems more related to gcc or binutils change. For some reason g++ -R isn't valid anymore. Passing this as g++ -Wl,-R fixes the problem (or at least works around it). FWIW I don't see -R in gcc manual on F14, must have been obsolete for a bit already. I saw that one, but was figuring out that it should detected the library earlier than that. Later in the build and throughout it hits a problem in libsigc++, which doesn't #include cstddef. You will need to do that including yourself before it's fixed in libsigc++. Yet later in the build it hits the problem with boost::filesystem that I talked about in another thread earlier today. Building against v2 works around this. OK. Finally the build passes, except rpmbuild complains that two files are not available: /builddir/build/BUILDROOT/gnote-0.7.3-5.fc15.x86_64/usr/libexec/gnote-applet /builddir/build/BUILDROOT/gnote-0.7.3-5.fc15.x86_64/usr/lib64/bonobo/servers/GNOME_GnoteApplet.server Could that be related to --disable-applet that you added recently? Yep. I'm attaching a patch that addresses the points above, except the last one. It's all in git now, and building. Thanks very much for your help! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
Petr Machata wrote:
+-boost_cv_lib_system_LDFLAGS=-L$boost_ldpath -R$boost_ldpath
++boost_cv_lib_system_LDFLAGS=-L$boost_ldpath -Wl,-R$boost_ldpath
Actually, the -R switch should be dropped entirely. -R is a shortcut for
--rpath. We don't want an rpath set on $boost_ldpath, which is the system
%{_libdir}; setting that rpath is a violation of our packaging guidelines!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
