Re: gcc 5 C++ string issue
Orion Poplawski or...@cora.nwra.com writes:
On 02/24/2015 05:22 PM, Kevin Kofler wrote:
Orion Poplawski wrote:
Getting:
/builddir/build/BUILD/mrpt-1.0.2/libs/base/include/mrpt/utils/mrpt_macros.h:296:150:
error: no match for 'operator' (operand types are
'std::basic_ostreamchar' and 'std::ostringstream {aka
std::__cxx11::basic_ostringstreamchar}')
#define ASSERT_NOT_EQUAL_( __A, __B) { if (__A==__B) {
#std::ostringstream
s;sASSERT_NOT_EQUAL_(#__A,#__B) failed with\n#__A=
__A \n#__B=__B; THROW_EXCEPTION(s.str()) } }
Any idea what wrong here?
The following patch fixes the compilation issue:
diff -up mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp\~
mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp
--- mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp~ 2013-01-05
00:23:15.0 +0100
+++ mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp 2015-02-25
16:55:48.628178380 +0100
@@ -97,7 +97,7 @@ void CImpinjRFID::startDriver()
const int ret = ::system(cmdline.str().c_str());
if (0!=ret)
- std::cerr [CImpinjRFID::startDriver] Error ( ret )
invoking command:\n cmdline std::endl;
+ std::cerr [CImpinjRFID::startDriver] Error ( ret )
invoking command:\n cmdline.str() std::endl;
system::exitThread(); // JL-Emil: Really needed? If not, just
remove...
}
I don't know why this stopped working, but it never did the intended
thing as written anyway.
With this out of the way, I'm getting a bunch of the following:
../../lib/libmrpt-maps.so.1.0.2: undefined reference to
`pcl::PCDWriter::setLockingPermissions(std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar const,
boost::interprocess::file_lock)'
So pcl should be rebuilt for new ABI it seems.
Thanks,
Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
Josh Boyer jwbo...@fedoraproject.org writes: We should not include preprocessed source files by default without the user knowing and agreeing. People use gcc to build proprietary source still. There's a check box to this effect in ABRT. It's not much different from sending backtraces or some other things that ABRT already sends. Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why there is no sync for libicu soname rebuilds?
Parag Nemade panem...@gmail.com writes: I actually got more confused when pmachata built harfbuzz without giving specific information in the changelog. The reason was that I was rebuilding both Boots and ICU deps, and since I just took a list of conflicts en blocks (as explained in another e-mail), I needed a neutral commit message. Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why there is no sync for libicu soname rebuilds?
Mikolaj Izdebski mizde...@redhat.com writes: I don't know why 0.9.38-3 was built, it looks like unnecessary build. Yes, it is. About 30 packages diverged after f22-boost side-tag had been created. It's impractical to check by hand whether any happened to be already rebuilt in the short window since the merge. So I just took the list of merge conflicts and scheduled a rebuild for all of them, and harfbuzz ended up being rebuilt twice. Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Results of Boost rebase
Hi, Most of the mass rebuild finished last week already, but due to FOSDEM and other circumstances (like me leaving the result file on my home NFS out of reach yesterday) I'm only getting to writing this now. A bunch of Boost-related bugs have been already resolved, or I contacted the maintainers. The following is the stuff that I plonked as not my business. Contact me if you think it in fact is, I'll look into it. The following look like they miss an #include iostream 8729595 glob2 error: 'cout' is not a member of 'std' 8731436 cclive ./cc/error.h:52:3: error: 'clog' is not a member of 'std' 8725522 blobby missing #include iostream? (only iosfwd?) A dep API changed apparently: 8743153 dmlite-plugins-profiler fatal error: dmlite/cpp/dmlite.h: No such file or directory 8743851 dmlite-plugins-adapter fatal error: dmlite/cpp/dmlite.h: No such file or directory 8747666 dmlite-plugins-memcache fatal error: dmlite/cpp/dmlite.h: No such file or directory 8742774 fityk error: lua.h version not in desired range 8739488 highlight error: too few arguments to function 'int lua_dump 8738031 snapper too few arguments to function 'int btrfs_read_and_process_send_stream 8743748 player error: too many arguments to function 'int sg_init()' 8737636 spring CMAKE: Could NOT find FONTCONFIG (missing: FONTCONFIG_LIBRARY FONTCONFIG_INCLUDE_DIR) 8729612 psi4fatal error: gitversion.h: No such file or directory zmq.hpp was renamed to zmq.h. 8738365 pdnsfatal error: zmq.hpp: No such file or directory 8768907 airinv fatal error: zmq.hpp: No such file or directory Documentation fails: 8765846 sdformatLaTeX Error: File `adjustbox.sty' not found. 8731230 roboptim-trajectory sh: gs: command not found 8737247 roboptim-core sh: gs: command not found 8731841 zookeeper unknown resolver null 8726792 libyui doxygen memory corruption on ARM What looks like various test suite failures: 8766409 trademgen test suite failures 8730816 cvc4test suite fail monotonetest suite failures 8738494 csdiff test suite failures 8727935 Macaulay2 looks like test suite failures as well 8736847 swigkernel_require.rb:54:in `require': cannot load such file -- example (LoadError) C++ errors: 8729771 gfal2-pythoninvalid conversion from const char* to char* 8735859 pathfinder invalid abstract return type 'xplc_ptrWvBufUrlStream::ProtectedPtr' 8738140 libopkele invalid abstract return type 'opkele::util::basic_filteratorIT' Build errors: 8765305 mrptNo rule to make target '/usr/lib/libnetcdf_c++.so', needed by 'lib/libmrpt-pbmap.so.1.0.2' 8738411 yoshimi Directory not found: /builddir/build/[...]/usr/lib64/lv2/yoshimi.lv2 8733973 elektra error: Installed (but unpackaged) file(s) found: 8726219 libflatarrayerror: Installed (but unpackaged) file(s) found These were skipped or failed due to dependencies on other software that failed: openoffice.org-diafilterdep: libreoffice fawkes dep: player gazebo dep: sdformat, player simcrs dep: airinv Failures that seem to be Boost-related, but I haven't had time (yet) to address them: 8740330 hugin 8738235 kicad 8737708 boost-gdb-printers 8730865 valyriatear 8729315 luabind Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Introducing abidiff (was Re: [Guielines Change] Changes to the packaging guidelines)
Dodji Seketeli do...@seketeli.org writes: but the link just points to the package. While it's not necessarily difficult to use, I wouldn't quite call it intuitive either. Indeed. And while we are in the Shameless Plug department, I'd like to mention the presence of a new tool called 'abidiff'. You can learn about it at https://sourceware.org/libabigail/manual/abidiff.html. I used abiff to evaluate impact of recent TBB rebase, and would like to corroborate Dodji's statement. It's a great tool. I'd be glad to mention abidiff on that page too, but as I don't intend to force it upon you guys, I'd wait for folks to look at the tool and say what they think first. It should be there in my opinion. Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[slic3r] Rebuild for boost 1.57.0
commit 71b6739cd7e4f2863289ba4993ff2e25a68d17d1
Author: Petr Machata pmach...@redhat.com
Date: Mon Jan 26 21:17:28 2015 +0100
Rebuild for boost 1.57.0
slic3r.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/slic3r.spec b/slic3r.spec
index 6f99957..cd6e901 100644
--- a/slic3r.spec
+++ b/slic3r.spec
@@ -1,6 +1,6 @@
Name: slic3r
Version:1.1.7
-Release:2%{?dist}
+Release:3%{?dist}
Summary:G-code generator for 3D printers (RepRap, Makerbot, Ultimaker
etc.)
License:AGPLv3 and CC-BY
# Images are CC-BY, code is AGPLv3
@@ -174,6 +174,9 @@ fi
%{_datadir}/%{name}
%changelog
+* Mon Jan 26 2015 Petr Machata pmach...@redhat.com - 1.1.7-3
+- Rebuild for boost 1.57.0
+
* Mon Oct 20 2014 Miro Hrončok mhron...@redhat.com - 1.1.7-2
- Unbundle polyclipping 6.2.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: TBB rebase
Petr Machata pmach...@redhat.com writes: I'll rebase TBB to 4.3u2 next week. This is now done in Rawhide. The F21 update is here: https://admin.fedoraproject.org/updates/tbb-4.3-1.20141204.fc21 Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: TBB rebase
Dodji Seketeli do...@seketeli.org writes: Petr Machata pmach...@redhat.com a écrit: The soname didn't change. I reviewed the actual changes using abidiff, and the only thing reported that I think is an actual ABI violation is insertion of one virtual method. I don't think that's real however: https://sourceware.org/bugzilla/show_bug.cgi?id=17861 Indeed, the reported insertion of the virtual method is a false positive resulting from a bug in abidiff. I have committed a change to abidiff that should fix that issue now. Great! And I confirm that the other abi changes reported by abidiff do not represent ABI-incompatible changes. Cool, thanks for confirmation. Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Boost 1.57.0
The packages with MPICH enabled are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=8678117 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2283793 http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706653 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2852781 Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Boost 1.57.0
Your favorite time of the year, and mine as well, is here! The plan is to do the rebase next week, maybe on the weekend already. As usual, I'll request a side tag, build boost, and then work through the dependent packages. I'll wrap the work on Thursday at the latest regardless on what state it is in (hopefully most will have been done by then), as I'll be traveling to FOSDEM on Friday. If you want to take a fresh-from-the-oven candidate package for a spin, help yourselves: http://koji.fedoraproject.org/koji/taskinfo?taskID=8677132 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2852665 http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706650 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2283587 I just noticed there are no MPICH packages, because I had MPICH support turned off locally. I'm spinning a new batch, but if you happen not to care about MPICH, the above should be just fine. The sources are here: https://github.com/pmachata/F22Boost158 I'll squash merge to Fedora just before I build the final package. Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: TBB rebase
Marcin Juszkiewicz mjuszkiew...@redhat.com writes: W dniu 19.01.2015 o 20:58, Petr Machata pisze: I'll rebase TBB to 4.3u2 next week. A scratch build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=8665932 Can you do builds on secondary architectures as well? arm-koji for aarch64 (should use generic), ppc-koji for PowerPC and s390-koji for S/390 ones? http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2851356 http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706545 PPC is still spinning. Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
TBB rebase
Hello, I'll rebase TBB to 4.3u2 next week. A scratch build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=8665932 Client packages are as follows, their owners are CC'd. adobe-source-libraries-0:1.0.43-23.fc22.src freecad-0:0.14-5.fc22.src gazebo-0:4.0.2-1.fc22.src mrpt-0:1.0.2-10.fc22.src openms-0:1.11.1-11.fc22.src smesh-0:6.5.3.1-1.fc22.src suitesparse-0:4.3.1-4.fc22.src The soname didn't change. I reviewed the actual changes using abidiff, and the only thing reported that I think is an actual ABI violation is insertion of one virtual method. I don't think that's real however: https://sourceware.org/bugzilla/show_bug.cgi?id=17861 So the current plan is to simply update TBB and not even bump and rebuild clients, but if you could take your packages for a spin with the scratch builds, and report back, that would be great. Thank you, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Koschei - continuous rebuilds for packages
Colin Walters walt...@verbum.org writes: On Tue, Jul 1, 2014, at 12:53 PM, Michael Catanzaro wrote: Yes, soname bumps are nonevents with OBS, since everything is automatically rebuilt. Sounds like Koschei is a big step towards that. I've always found it really strange how so many people talk about rebuilding for soname bumps. The *entire point* of a soname bump is to communicate that the API/ABI has *changed*, and thus it may require active human intervention to update callers for the change. In other The soname bump reflects a change in ABI. The API could have stayed the same. (But of course, sometimes the ABI bump isn't warranted, and sometimes manual intervention is necessary.) Personally, I would welcome such service for Boost bumps. Most of the time, the rebuilds just pass. If I could get e-mails about the 10% or so of problematic packages for closer inspection, and the rest would just rebuild without me having to lift a finger, that would be great. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rebuilds for Boost 1.55 mostly done
Hi there,
the rebuilds are mostly over, thanks for everyone who chimed in. Some
packages may have been double-rebuilt, as there was no synchronization
between the partakers.
Maybe next year I'll publish the list of packages on a wiki, organized
by dependencies, so that people at least know in what order to rebuild
the packages. People wishing to partake would annotate in the wiki. Or
something. We'll see.
Anyway. This is the break-down of package failures with a short note
that I made for myself regarding the overt reason of failure. The
numbers are task ID's.
* Configury stuff:
6877744 spring (CMake backward-compatibility unsupported)
6879574 xs (autoreconf needs -if or something)
6884300 dmlite-plugins-memcache (-std=c++11 not passed on command line)
* Dependency problems:
6878034 sdcc (BFD: right-hand operand of comma expression has no effect)
6878281 orthanc (some dep problem apparently)
6878753 csound (no package java-gcj-compat-devel)
6879835 hugin (requires libgcj-devel)
6881932 scribus (Could NOT find PythonLibs)
gpsdrive (mising BR:freetype or something)
* Mysteriously hard C++ errors:
6878277 kate-plugin-cpphelper (initlist vs. explicit ctor)
6878306 clementine (namespace org::freedesktop::UDisks)
6879204 libopkele (error: invalid abstract return type)
6881504 pathfinder (error: invalid abstract return type)
6879206 glob2 ('struct Game::BuildProject' is private)
6888959 sdformat ('class urdf::Link' has no member named
'collision_groups')
6888951 fawkes (error: 'textpara_t' has not been declared)
* Warnings turned errors:
6878621 curlpp (a function defined but not used)
6879564 libkni3 (-Werror=format-string)
6881890 diet (-Werror=format-string)
* Something must have changed in lex/yacc toolchain, as the following
two both have a problem with expected vs. actual number of parameters:
6878948 ptlib (something with yyparser)
6881211 rcssserver (something with lex)
* The following two need patching in KDE I think. The include file
should be QtCore/QFile, shouldn't it? Tweaking -I in the client
package also seems to work as a temporary measure:
6878464 kradio4 (error: QFile: No such file or directory)
6883795 kpilot (error: QFile: No such file or directory)
* Maven-related:
6879292 bookkeeper
6879822 zookeeper
* Assorted:
6881502 Macaulay2 (Floating point exception)
6881687 python-ufc (ghostscript)
6882332 srecord (ghostscript)
6881678 zorba (xqdoc Segmentation fault)
6877049 ompl (test suite failure)
6878957 monotone (false on ARM)
6879562 librecad (patch mismatch)
* Timeouts:
6888934 R-bigmemory
6888920 libreoffice
Thanks,
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Boost 1.55.0
Hello, boost-1.55.0 has been built in a side-tag f21-boost. I'll be rebuilding Boost clients over the next couple days--first those that depend on Boost DSO's, then possibly the rest. Anyone wanting to join the party should feel free. This is the incantation to use to build in the side tag: $ fedpkg build --target f21-boost The list of already-built packages can be had this way: $ http://koji.fedoraproject.org/koji/builds?inherited=0tagID=269order=-build_idlatest=1 Note that mass rebuild is currently scheduled on 26th, which is next Monday. f21-boost will merge then at the latest. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 885474] make bails with *** INTERNAL: readdir: Bad file descriptor
Ralf Corsepius rc040...@freenet.de writes: However, I recall another case, deps on dirs often don't work: (massively) parallel make. Did you try to build the package single-threaded (make -j1)? No, it used -j2 (as bug 885474 suggests). PM. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 885474] make bails with *** INTERNAL: readdir: Bad file descriptor
Ralf Corsepius rc040...@freenet.de writes: I guess, no. AFAIS, this makefile carries deps on directories. This is a very old known general limitation of and portability isse with make and one of known donts. Deps on dirs work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices. Apparently, Linux just joined the ranks of other *nices--I can reproduce the problem on local filesystems just fine. I didn't know it's a don't, thanks for pointing this out. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mass rebuild update
Peter Robinson pbrobin...@gmail.com writes: Maybe we need to put a mass rebuild starts point in the Schedule in the future so that people are more aware of this and have the sorts of features like a perl rebase done in reasonable time. That would be useful. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Cannot install boost-static...
Ahmad Samir ahmadsamir3...@gmail.com writes: $ yum list boost-static* [...] Available Packages boost-static.i686 1.53.0-6.fc19fedora boost-static.x86_64 1.53.0-8.fc19updates it looks like boost-static-1.53.0-8.fc19.i686 is missing from x86_64 updates repo; but it's available in i386 updates repo: e.g. https://mirrors.kernel.org/fedora/updates/19/i386/boost-static-1.53.0-8.fc19.i686.rpm This is reminiscent of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=837901 Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rebuild of Boost dependees
punto...@libero.it punto...@libero.it writes: there is also zookeeper... to be rebuild with the new boost? Yeah, I only got around to rebuilding those that directly depend on Boost DSO's. I guess I can order builds of the rest of the dependencies today, though originally my plan was to go through DSO deps only. I'll hardly have time to go through failures though, as I'd like to merge in about 12 hours. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rebuild of Boost dependees
More failures from another bunch of rebuilds of about 100 packages that
have API-only dependence on Boost. I fixed those overtly Boost-related,
what remains seems to fail due to something else, so it should be OK to
just fix these in Rawhide and ignore Boost.
Note that f20-boost will be merged soon. Right now I'm just waiting for
R-bigmemory and stp rebuilds to finish--I don't see any other
in-progress builds in f20-boost. Thanks to everyone who helped me move
this along!
Unresolved deps:
Macaulay2 5677473 No Package found for
{libfac,factory}-{devel,static}
gpsdrive5677699 No Package found for compat-libgda-devel
libkni3 5677935 No Package found for texlive-utils
gr-air-modes5677713 GnuRadio Runtime required to compile
gr-air-modes
openoffice.org-diafilter5678089 depends on libreoffice-core
Assorted C/C++ errors:
abiword 5677483 #include gcrypt.h
ardour 5677496 invalid conversion from 'const LilvPort* {aka
const LilvPortImpl*}' to 'LilvPort* {aka LilvPortImpl*}'
bind10 5677520 error: 'inlinline' was not declared in this
scope
^^^ apparent typo???
csound 5677569 error: unknown type name 'TREE'
dyninst 5677602 error: redefinition of 'struct
ptrace_peeksiginfo_args'
valyriatear 5678319 invalid use of incomplete type 'png_info {aka
struct png_info_def}'
roboptim-core 5678187 typedef 'value_type' locally defined but not
used
^^^
Probably safe to drop, but if the typedef is meaningful but
unused, then either convert to BOOST_STATIC_ASSERT, or use
__attribute__ ((unused)).
stellarium 5678268 POD document had syntax errors at
/usr/bin/pod2man line 69
^^^
The last bunch also had one like this.
fritzing5677658 no matching function for call to 'qMax(double,
qreal)'
kdenetwork 5677818 invalid conversion from 'void (*)(void*,
OtrlNotifyLevel, const char*, const char*, const char*, const char*, const
char*, const char*)' to 'void (*)(void*)'
nodejs-mapnik 5678058 no matching function for call to
'mapnik::vector::processormapnik::vector::backend_pbf::processor(backend_type,
mapnik::Map, double, unsigned int, unsigned int, unsigned int)'
pathfinder 5678114 cannot allocate an object of abstract type
'xplc_ptrWvBufUrlStream::ProtectedPtr'
Apparently LUA was updated:
highlight 5677808 'lua_number2integer' was not declared in this
scope
monotone5678043 'LUA_GLOBALSINDEX' was not declared in this
scope
widelands 5678370 error: 'LUAI_UINT32' does not name a type
Unversioned docs:
cyphesis5677579 Installed (but unpackaged) file(s) found
scribus 5678227 Installed (but unpackaged) file(s) found
Related to ARM:
yoshimi 5678415 ARM: unrecognized command line option '-msse'
Obscure errors:
oyranos 5678093 deutsche Fehler
libclaw 5677926 File not found by glob:
/builddir/build/BUILDROOT/libclaw-1.7.0-9.fc20.x86_64/usr/lib64/*.so.*
zorba bin/zorba (or make?) Segmentation fault
xmms2 5678386 {task 25618896: xsubpp XMMSClientResult.xs -
XMMSClientResult.c} ???
Thanks,
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rebuild of Boost dependees
Hi there,
as some of you may have noticed, the biannual Boost rebuild has been
underway since Saturday! So far about 100 packages have been rebuilt.
I'll appreciate any help that I can get with resolving the current
failures. Just ping me on IRC (_petr) so that we don't duplicate
effort. Currently the following are the failures that I know about
(with task numbers in case you wish to inspect):
C or C++ errors:
pcl 5663101 error: 'sqrt' is not a member of
'Eigen::internal'
pokerth 5663090 gcrypt.h: No such file or directory
minion 5663196 ICE
zarafa 5663602 C++ errors
openlierox 5663123 'LUA_GLOBALSINDEX' was not declared in this
scope
Bugs apparently related to unversioned docfiles change:
CGAL5663106 Installed (but unpackaged) file(s) found:
snapper 5665599 Installed (but unpackaged) file(s) found
stdair 5663142 Installed (but unpackaged) file(s) found
fatrat 5672534 Installed (but unpackaged) file(s) found
-- Frankly, I'm confused by those. Fatrat and CGAL don't mention
version in any way--they simply use %{_docdir} and %doc. stdair does
mention version, but the build failure complains about stuff
installed by %doc. What gives?
Bugs apparently related to ARM:
spring 5664257 unrecognized argument in option '-mtune=generic'
ceph5663470 ARM unsupported? (gperftools-devel)
mongodb 5663581 ARM unsupported? (gperftools-devel)
0ad 5663431 ARM unsupperted? (nvidia-texture-tools or
somethig)
Assorted errors:
hugin 5663415 POD document had syntax errors at
/usr/bin/pod2man line 69.
python-tag 5663153 urllib2.URLError: urlopen error [Errno -2]
Name or service not known
polybori5663365 SCONS: internal error in regular expression
engine
Unresolved deps:
bookkeeper 5663346 Package: xbean-3.13-2.fc20.noarch (build)
Requires: eclipse-equinox-osgi
airrac 5668958 depends on stdair
airsched5669057 depends on stdair
sevmgr 5668947 depends on stdair
simfqt 5668967 depends on stdair
travelccm 5669008 depends on stdair
fawkes 5669050 depends on pcl
mrpt5669093 depends on pcl
iwhd5668878 depends on mongodb
condor 5668979 depends on mongodb
openscad5668923 depends on CGAL
crrcsim 5669040 depends on CGAL
There's also this:
libreoffice 566 BOOST_NOEXCEPT
which is apparently boost-related, but I was unsuccessful in reproducing
this locally, and am leaving it aside in favor of lower-hanging fruit ;)
Thanks,
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rebuild of Boost dependees
Petr Machata pmach...@redhat.com writes: as some of you may have noticed, the biannual Boost rebuild has been underway since Saturday! [...] I'll appreciate any help that I can get with resolving the current failures. I forgot to mention that if you wish to build Boost clients, you should use the following incantation: fedpkg build --target f20-boost Also, I'm leaving for my vacation on Wendesday. I will likely request tag merge tomorrow (on Tuesday) midnight-ish UTC. (Hopefully with libreoffice resolved ;) ) Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rebuild of Boost dependees
Ville Skyttä ville.sky...@iki.fi writes: These are now fixed in master. Thanks! PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rebuild of Boost dependees
punto...@libero.it punto...@libero.it writes: Il 29/07/2013 18:01, Petr Machata ha scritto: bookkeeper 5663346 Package: xbean-3.13-2.fc20.noarch (build) Requires: eclipse-equinox-osgi sorry, i rebuilt without boost 1.54.x support... eclipse-equinox-osgi is available also in arm* repos No problem, I rebumped and rebuilt it in f20-boost. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Should Boost even be Feature/Change? [Was: F20 Self Contained Change: Ryu Network Operating System]
Dan Mashal dan.mas...@gmail.com writes: The Feature page still belongs to the FeaturePageIncomplete category. I feel a somewhat similar way about boost and it would be nice if there was some more detailed descriptions here. Frankly, my biannual filing of Feature/Change page is mostly cargo-culting. It's just rebase, really, even though there are 250 dependers. I like how the Change process forces me to think and argue through some implicit assumptions, but I've been doing this for some time now, and more or less know the drill. In the end we simply need to patch our way out of any build failures, one way or another. So if the consensus is that Boost rebases don't need this sort of paperwork, I'll simply not do it the next time around. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should Boost even be Feature/Change?
Petr Machata pmach...@redhat.com writes: Dan Mashal dan.mas...@gmail.com writes: The Feature page still belongs to the FeaturePageIncomplete category. I feel a somewhat similar way about boost and it would be nice if there was some more detailed descriptions here. So if the consensus is that Boost rebases don't need this sort of paperwork, I'll simply not do it the next time around. Or, did you mean that Boost Change page is incomplete? Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile-time shared library name mismatching base name (SDL)
Petr Pisar ppi...@redhat.com writes: Is the installed libSDL.so symlink a mistage in the SDL-devel package? Is renaming libSDL.so to libSDL-1.2.so wise? The libSDL.so is used in upstream and other distributions. I'm speculating here, but renaming the actual DSO like this would make it possible to install two runtime SDL versions side by side (say, 1.2 and 2.0). However, it's safe to assume that you'll only ever need one SDL-devel, so it's fine to just name the symlink libSDL.so--which allows you to use -lSDL on compiler command line (instead of having to spell out -lSDL-1.2). No idea why it confuses ldconfig like this though. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Who uses abi-compliance-checker?
Richard Shaw hobbes1...@gmail.com writes: I initially got abi-compliance-checker into Fedora because one of my packages does not maintain any sort of API/ABI compatibility or even versioning for that matter. That way I could always check a new release to see if any of its dependencies needed to be rebuilt. It would be nice to use this to decide that we don't need to rebuild clients across Boost upgrades. The trouble is that for this, more than static Dwarf inspection is needed. We also need an analysis of all templates that haven't been instantiated, in case another library used them in API. This seems to call for a solution based on a GCC plugin or something similar, where you really get to see and dump the source. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-threads-tbb/f19] Rebuild for TBB memory barrier bug
Summary of changes: a4b73be... Rebuild for TBB memory barrier bug (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
TBB rebased to 4.1u3 in Rawhide
This was long overdue, last update was almost a year ago. That said, the update should be safe: upstream-tracker.org lists only one warning that is potentially ABI-breaking, which is that the constant eid_max changed value. That constant doesn't appear to be used by any of the clients. Soname wasn't bumped. If you encounter problems with TBB, please do not hesitate to contact me (either via this e-mail address, or _petr on IRC) and I should be able to help. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OK to bump soname for a lesser-used library?
Dan Horák d...@danny.cz writes: Josh Stone píše v Út 05. 03. 2013 v 09:44 -0800: Is that feasible for C++ APIs? I mean, it might be possible if you're *really* careful about hiding class changes, but this project is not structured that way. it is, see eg. the wxWidgets library, they are really good in that Regarding C++ ABI, I found this worth reading: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.53 in Rawhide
Kevin Fenzi ke...@scrye.com writes: On Fri, 08 Feb 2013 02:57:19 +0100 Petr Machata pmach...@redhat.com wrote: Hi there, I have just built boost 1.53. I didn't go through the side tag as originally envisioned, as tomorrow's mass rebuild should take care of it all in one fell swoop. I'll still be available for help if your package mysteriously fails or if there's just too many 's and 's in your package for a sane person to wrap their head around. Dennis is traveling right now, so it looks like the mass rebuild may be pushed off to the 12th. Do we want to untag this until then? Or is it going to cause broken deps? FYI (Y as in wider community), Kevin went ahead and did that, which is fine by me. You can still find the relevant RPMs in koji if you are interested in trying out 1.53 before the real thing lands. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost 1.53.0
Kevin Fenzi ke...@scrye.com writes: I know the last cycle the boost tag was merged back in and there were a lot of packages that still needed rebuilding. For this cycle, do you have any provenpackagers in your feature owners that could just make sure all the packages are rebuilt? It would be nice to merge in something that doesn't have very many/if any broken deps in rawhide. Yeah, last update wasn't quite as successful as I had hoped, so I applied for provenpackager privs myself. If things go well, I'll be able to handle much of rebuilds myself. Denis is a provenpackager already, but he was unavailable the last time around. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Boost 1.53.0
Hi there, as every release, we (the Boost maintainers) intend to rebase Boost for Fedora 19. The targeted release is 1.53.0. The plan is outlined on the feature page [1]. Boost 1.53 is not out yet (it will be on February 4). Beta is out, but I don't think it's a good idea to rebase to that. With Boost, there's no guarantee that the ABI will stay stable from beta to final. We would have to review whether any ABI-breaking changes were made, which is annoying enough by itself, and we would possibly end up re-rebuilding clients anyway. So while we may _package_ beta (for purposes of local testing, scratch builds and such), I don't think we should push it to Rawhide. I'll write again when things progress further. Thanks, PM [1] https://fedoraproject.org/wiki/Features/F19Boost153 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Boost.Thread in Boost 1.50
Hi there, if you had problems with linking or detection of Boost.Thread due to a message that looks similar to this: /usr/bin/ld: /tmp/ccAv0B8G.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv' /usr/bin/ld: note: '_ZN5boost6system15system_categoryEv' is defined in DSO /lib64/libboost_system-mt.so.1.50.0 so try adding it to the linker command line /lib64/libboost_system-mt.so.1.50.0: could not read symbols: Invalid operation ... then this is caused by Boost.Thread pulling in Boost.System. Because this symbol is brought in by includes, it appears as undefined in the linked binary itself, and it needs to be linked not only with -lboost_thread-mt, but also -lboost_system-mt. This was fixed by latest boost build, which replaces libbost_thread-mt.so with a linker script, that does this automatically. That is in Rawhide, and a bodhi update request for Fedora 18 was filed: https://admin.fedoraproject.org/updates/boost-1.50.0-4.fc18 So if you had to put in any hacks to have your script detect Boost.Thread, or to link one of the binaries, it should shortly be possible to remove them. Thanks, PM P.S. this is tracked upstream at: https://svn.boost.org/trac/boost/ticket/7241 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost and Python 3 in f18
David Malcolm dmalc...@redhat.com writes: On Tue, 2012-08-07 at 01:22 +0200, Petr Machata wrote: Jon Ciesla limburg...@gmail.com writes: On Mon, Aug 6, 2012 at 11:33 AM, David Malcolm dmalc...@redhat.com wrote: (c) move the boost-1.50 from f18-boost into f18 proper My understanding is that tonight dgilmore will be doing c. Great, that would be very helpful. I'll try to coordinate with him over IRC (am trying to do so now in fact). Petr: What is the status of this? I was told by dgilmore to put a request in the boost side tag ticket earlier today. I promptly did that. dgilmore said he was about to branch f18, and would prefer to merge boost soon, so it seems like he knows about this, and it's now just a matter of time. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost and Python 3 in f18
Petr Machata pmach...@redhat.com writes: look at re-enabling Python 3 this week, but I'm thinking that I'll actually build it only after the merge. Python 3 support is in git. I'll spin a build after the merge is done. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost and Python 3 in f18
David Malcolm dmalc...@redhat.com writes: On Sat, 2012-08-04 at 21:30 +0530, Parag N(पराग़) wrote: Thanks. But I am getting this error for xs package scratch build. DEBUG util.py:257: -- gc-devel-7.2c-3.fc18.x86_64 DEBUG util.py:257: -- readline-devel-6.2-5.fc18.x86_64 DEBUG util.py:257: Error: Package: boost-python3-1.48.0-16.fc18.x86_64 (build) DEBUG util.py:257: Requires: libpython3.2mu.so.1.0()(64bit) DEBUG util.py:257: You could try using --skip-broken to work around the problem I am not able to find boost-python3 subpackage from boost package build. I think this is a consequence of the latest boost packages being done in a side tag for: http://fedoraproject.org/wiki/Features/F18Boost150 Currently, the latest boost build in f18 seems to be: boost-1.48.0-16.fc18 http://koji.fedoraproject.org/koji/buildinfo?buildID=326854 whereas the latest boost build is in f18-boost: boost-1.50.0-1.fc18 http://koji.fedoraproject.org/koji/buildinfo?buildID=344226 The commit for boost 1.50: http://pkgs.fedoraproject.org/cgit/boost.git/commit/?id=a2450339dffbaadf0e31879429cc026862ec2439 seems to have dropped the python3 subpackage which confused me and my scripts. Temporarily, as I wanted to get out mostly-working Boost 1.50 out. I'll look at re-enabling Python 3 this week, but I'm thinking that I'll actually build it only after the merge. I'd need to do so anyway, and presumably that would impact ABIs of boost-python3, so there's no value in having the build in a tag. It's not clear to me that anything actually uses boost-python3 I put in Python 3 support at a user request, as it seems sensible to me to support both Python versions, and it was reasonably easy to put the support in. It is quite possible there are no direct users in Fedora itself. In the meantime, it looks like my Python 3.3 rebuild has broken boost installs in f18 buildroots until the boost-1.50 build lands in f18. Sorry about that. Is there an ETA for when the boost stuff will be merged? I'm thinking the end of this week. This gives about a week for fixes and rebuilds before Alpha. Anyone knows if there is a way to address maintainers of packages dependent on boost? That's about 100 packages that depend on runtime libraries, and then those that have Boost as BR. I guess I may need to crawl package database. Apparently, without direct pings, people won't rebuild the client packages. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost 1.50 built into a side tag
Jon Ciesla limburg...@gmail.com writes: I rebuilt my boost users into f18-boost, and now I'm getting rawhide broken dep warnings for one that needs a rebuild for libGLEW. The boost rebuild in f18-boost has the new libGLEW. I'm assuming I can just let it sit until f18-boost is tagged into f18, right? Yes, I'm afraid so. I guess we might do some magic with tagging libGLEW into f18-boost and having your package rebuilt against both the new boost and libGLEW, but that sounds messy and I'd rather avoid it. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Boost 1.50 built into a side tag
Hi all, this is to let you know that boost has been upgraded to 1.50, sans Python 3 support, which will arrive later. After complaints in past years, we decided to request a dedicated side-tag (f18-boost) not to break a hundred or so packages that depend on it in Rawhide. As always, all client packages, especially those that depend on boost runtime libraries, need to be rebuilt, but this time around you need to request the right tag explicitly: fedpkg build --target=f18-boost This tag will live for a couple weeks, but I think we should merge back before alpha freeze, which is 2012-08-14, in about two weeks. There's at least one disruptive change that I know about: Boost.Filesystem v2 has been discontinued and anyone who hasn't yet ported their code to v3 must do so now. As usual, feel free to open bugs, ping me on IRC (_petr) or send e-mails if one of your packages doesn't like the new boost. We'll figure out how to work around the notorious API changes. (Or fix boost.) Thank you, Petr Machata Related: https://fedoraproject.org/wiki/Features/F18Boost150 https://bugzilla.redhat.com/show_bug.cgi?id=825826 https://fedorahosted.org/rel-eng/ticket/5230 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Examining -static package build timestamps in koji
Michael Schwendt mschwe...@gmail.com writes: 21 link with flex libs-- flex doesn't change often, though I believe that libfl.a hasn't really changed in Fedora at all. It exports two symbols, totaling something like 10 lines of actual code. Absence of client rebuilds is just not a problem in this case. tilda-0.9.6-6.fc16.src older than flex-2.5.35-15.fc18.src.rpm 231 days Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Boost-1.50 in Fedora 18, Boost.Filesystem v2 to be dropped
Hi there, we (the Boost maintainers) intend to bump boost to a more recent version in course of Fedora 18 development. Though no schedule is available for Boost or Fedora as of yet, it seems like we are aiming for 1.50 and there should be a couple months of overlap. We intend to make this a feature when our plans become more solid, as usually. One of the more invasive changes that this release will probably bring is getting rid of support for Boost.Filesystem v2 [1], which was already announced about two Fedoras ago. I'd like to encourage all maintainers who build their packages with -DBOOST_FILESYSTEM_VERSION=2 to drop that option and try to rebuild their packages as soon as possible, ideally before the new Boost lands. Thanks, PM P.S. thanks to Denis Arnaud who spotted the intention of removal! [1] http://lists.boost.org/Archives/boost/2012/03/191238.php -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundling?!
Ralf Ertzinger fed...@camperquake.de writes: Hi. On Sun, 19 Feb 2012 22:26:20 +0100, Petr Machata wrote Please don't do this. The main reason being that header code from bundled boost is in general not binary compatible with the native code from system boost. It might maybe happen to work, but is likely to fail in obscure and hard to debug ways if the version of bundled boost differs from system boost. If I understand the OP right then ASL comes with it's own build system, and it is the build system that uses the bundled boost libraries. The ASL itself (the binaries that end up in the RPM) can be built against the system boost. Ah, that shouldn't be a problem I guess. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundling?!
Alec Leamas leamas.a...@gmail.com writes: I've tried to package Adobe Source Libraries, (BZ:790628). Once again, I'm running into bundling issues.. The situation is basically that ASL build system expects a boost source tree to be available. This is not just to include and link, it's for the complete build process. I've dealt with it by having having the source tree available during build, and thus in the source. As a last step; I've relinked the resulting library against system boost libraries. Please don't do this. The main reason being that header code from bundled boost is in general not binary compatible with the native code from system boost. It might maybe happen to work, but is likely to fail in obscure and hard to debug ways if the version of bundled boost differs from system boost. Secondarily, much of boost functionality is in the headers. Relinking against system boost libraries after you compiled against bundled version will only take from the system that part of boost functionality that's not inlined from the headers. The former point is really the killer here. Using headers that don't exactly match DSOs, with the project as volatile as boost, is not recommended. Although I presently don't, I could easily use system include files as well during build. Basically, this means that there are no dependencies between the built lib and and the private boost copy. The alternative is to patch the boost-based build system in ASL. However, this means diverging quite a lot from upstream build system, and is less attractive from that point of view. You could perhaps just copy the system headers in your build tree, if it's unreasonably complicated to tweak the build system. Would that work? Thank you, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cmake parallel make problem.
Richard Shaw hobbes1...@gmail.com writes: On Tue, Jan 10, 2012 at 8:18 AM, Rex Dieter rdie...@math.unl.edu wrote: Richard Shaw wrote: I've gone through the CMakeLists.txt and added add_dependencies(... but I think that's redundant because target_link_libraries is getting set properly. I'm not sure this is redundant, as I would imaging it would be hard to infer the origin of the target_link_library (ie, if it's local or not). Do you mean this could be a scope issue? From what I gathered reading the cmake documentation, add_dependencies was most useful for custom and external targets. Everything builds fine if I force -j1 so I think it's trying to build things in the right order. Perhaps one job is finishing before another and it just doesn't understand it needs to wait for another job to finish? I didn't look into your problem, but what you say would mean that cmake is not generating all necessary dependencies for make. Having a rule like X: Y Z is not enough. If Z depends on Y, you need additionally Z: Y, otherwise make will parallelize Y and Z. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.7 linking failure: undefined reference to foo
Julian Sikorski beleg...@gmail.com writes:
I was trying to build mame (an rpmfusion package) with gcc-4.7. I have
managed to get it to build, but it fails at the linking stage:
obj/sdl/libocore.a(sdlsocket.o): In function `operator new(unsigned long)':
/builddir/build/BUILD/mame-0.144u5/src/emu/emualloc.h:114: undefined
reference to `malloc_file_line(unsigned long, char const*, int)'
obj/sdl/libocore.a(sdlsocket.o): In function `operator delete(void*)':
/builddir/build/BUILD/mame-0.144u5/src/emu/emualloc.h:131: undefined
reference to `free_file_line(void*, char const*, int)'
collect2: error: ld returned 1 exit status
The problem boils down to the following reproducer:
#include new
#include cstddef
void *malloc_file_line(size_t size, const char *file, int line);
__attribute__((always_inline)) inline void *
operator new(std::size_t size) {
return malloc_file_line(size, __null, 0);
}
struct item {
void add() { new item; }
};
int main(int argc, char *argv[]) {
return 0;
}
# g++ ble.cc
/tmp/ccwc7vSd.o: In function `operator new(unsigned long)':
ble.cc:(.text._Znwm[_Znwm]+0x1e): undefined reference to
`malloc_file_line(unsigned long, char const*, int)'
If #include new is removed, the problem goes away. I suspect there
might be another declarations of new operator in that header file, and
the two are not going well together. Would you be so kind as to open a
bug against gcc? It looks like something that responsible parties
should take a look at, what with all the inline and always_inline
stuff that GCC seems to be ignoring.
To work around your immediate problem, I think you might #define
NO_MEM_TRACKING before including emu.h, like this:
diff -up mame-0.144u5/src/osd/sdl/sdlsocket.c\~
mame-0.144u5/src/osd/sdl/sdlsocket.c
--- mame-0.144u5/src/osd/sdl/sdlsocket.c~ 2012-01-10 00:34:48.0
+0100
+++ mame-0.144u5/src/osd/sdl/sdlsocket.c2012-01-10 02:13:51.293943347
+0100
@@ -23,6 +23,7 @@
#endif
#include errno.h
+#define NO_MEM_TRACKING
#include emu.h
#include sdlfile.h
It then proceeds for a bit before hitting a C++11 correctness problem.
You might consider smuggling in -std=c++98 and alarm upstream, it seems
GCC 4.7 defaults to C++11 and the code is not ready for this.
Thanks,
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost build failure
Orion Poplawski or...@cora.nwra.com writes: On 12/05/2011 05:29 PM, Petr Machata wrote: Orion Poplawskior...@cora.nwra.com writes: I'm seeing the following boost related build error building paraview in rawhide. Do any boost gurus know what the issue might be the issue? Hi there, please do not hesitate to file bugs for such regressions. I only noticed this message today. It wasn't obvious to me that it was a regression. New versions of libraries things often change. Well, yeah, it is a change. The regression here is that your package stopped building. This could well be caused by a bug in boost, or perhaps the API just changed. It's hard to tell with boost. If you open a bug agains boost for such things, I'll look at it and typically will come up with a patch that either fixes the package, or boost. I'll open an upstream bug for this. Do you have a link for this? https://svn.boost.org/trac/boost/ticket/6221 But don't hold your breath, it was wontfix'd, as expected. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost soname bump
Bruno Wolff III br...@wolff.to writes: It looks like there was a soname bump in boost yesterday. Boost affects enough stuff, that there really should have been a heads up message posted to the devel list about this. Yes, Denis Arnaud has kindly prepared a new release, but forgot to give a yell. That said, it's been a ritual for about past three years that with every Fedora there comes a point in time when boost breaks all its clients. That much should be hardly surprising. To address a point raised in another mail: this version is here to stay, unless something goes awry. We will of course fix bugs as they turn up, but neither further rebasing, nor withdrawing this version is in plan as of now. Note that boost::filesystem v2 has been scheduled for removal in 1.48, but this doesn't seem to have happened yet, the code is still there. If there are problems with compiling against the new boost, or you want to address some point of packaging, feel free to contact me. I'm _petr on #fedora-devel. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost soname bump
Adam Williamson awill...@redhat.com writes: On Tue, 2011-11-22 at 14:49 +0100, Petr Machata wrote: Bruno Wolff III br...@wolff.to writes: It looks like there was a soname bump in boost yesterday. Boost affects enough stuff, that there really should have been a heads up message posted to the devel list about this. Yes, Denis Arnaud has kindly prepared a new release, but forgot to give a yell. That said, it's been a ritual for about past three years that with every Fedora there comes a point in time when boost breaks all its clients. That much should be hardly surprising. Surprising, no, but it could certainly handled better. The intent of the requirement for a week's notice *in advance* is so dependent packages can get out ahead of checking if they'll work with the new library without adjustment, and if adjustment is needed, get it ready. So that when the bump lands, dependent packages can simply be quickly rebuilt, and Rawhide only has major dependency issues for a day or two, instead of two weeks while everyone runs around trying to adjust for the surprise changes. Really, for something with as many deps maintained by as many people as Boost, it should be required for the bump to be done in a tag and all It's maintained by me and Denis. The rest of the people are either watchers, or bkoz, who formally owns boost, but really has stepped off some time ago, or Deji, who was granted commit right for some one-off ABI change in libmpich2, and whom I removed just now. (or at least most of) the rebuilds to be completed in the tag prior to merging it back into the main Rawhide stream. Some groups already do this, to the general benefit of all. We will consider doing that the next time around, it's not the first time that I hear this proposal. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Threading Building Blocks rebased to 4.0 in Rawhide
Hi there, SSIA. The update is ABI-breaking (at least concurrent_priority_queue changed member layout, I didn't look further), but upstream didn't bump soname. Rebuild is recommended. I'm CC-ing maintainers of the three client packages that I know about. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Kevin Kofler kevin.kof...@chello.at writes: It's not the Firefox maintainers, it is Mozilla who have decided that release numbers are irrelevant and that the bug fix release for Firefox 5 is Firefox 6. If Firefox were following the update policy, they'd backport the security fixes, not push the new versions. Is that actually possible? I seem to recall that the reason why Firefox can be called Firefox in Fedora, and not, say, Iceweasel or whatever, is that we ship vanilla upstream. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
TBB (Threading Building Blocks) rebase
Hi there, I rebased TBB to 3.0. This should even be ABI-stable release--upstream didn't bump the SONAME, and I verified that no ABI-looking symbols disappeared. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.47.0
Jon Ciesla l...@jcomserv.net writes:
Wesnoth seems not to like the new Boost all that well:
http://koji.fedoraproject.org/koji/getfile?taskID=3218720name=build.log
Is this a common sort of error? My Boost-fu is weak, so there might be
something obvious I'm missing.
Yeah, all boost errors tend to spew lines and lines of error messages
like that. That's the nature of them templetes. I'm looking into this
one, and it seems to be some interplay between BOOST_FOREACH,
boost::ptr_vector and GCC version. Not sure what exactly yet.
It can be worked around by replacing the foreach calls in
wesnoth-1.8.6/src/gui/widgets/tree_view_node.cpp in this manner:
- foreach(const ttree_view_node node, children_) {
+ for (boost::ptr_vectorttree_view_node::const_iterator it
+ = children_.begin (); it != children_.end (); ++it) {
+ const ttree_view_node node = *it;
Thanks,
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.47.0
Petr Machata pmach...@redhat.com writes: Jon Ciesla l...@jcomserv.net writes: Wesnoth seems not to like the new Boost all that well: http://koji.fedoraproject.org/koji/getfile?taskID=3218720name=build.log Is this a common sort of error? My Boost-fu is weak, so there might be something obvious I'm missing. Yeah, all boost errors tend to spew lines and lines of error messages like that. That's the nature of them templetes. I'm looking into this one, and it seems to be some interplay between BOOST_FOREACH, boost::ptr_vector and GCC version. Not sure what exactly yet. ... and boost::noncopyable. Forgot about that one. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.47.0
Petr Machata pmach...@redhat.com writes: Jon Ciesla l...@jcomserv.net writes: Wesnoth seems not to like the new Boost all that well: http://koji.fedoraproject.org/koji/getfile?taskID=3218720name=build.log Is this a common sort of error? My Boost-fu is weak, so there might be something obvious I'm missing. I'm looking into this one, and it seems to be some interplay between BOOST_FOREACH, boost::ptr_vector and GCC version. Not sure what exactly yet. Opened a bugzilla to track this FTBFS. With GCC 4.6+, BOOST_FOREACH cannot be used to iterate over noncopyable collections. https://bugzilla.redhat.com/show_bug.cgi?id=724818 Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.47.0
Petr Machata pmach...@redhat.com writes: in accordance with the announced Fedora feature[1][2], we (the Boost maintainers) plan to rebase Boost to 1.47.0 really soon now. [...] I'll do that in the next few days and if all comes out green-ish, I'll push the package into Fedora 16 and write a follow-up to this e-mail with guidelines on overcoming the obstacles, if any. It all seems good, I rebuilt 25 packages and hit no boost-related problems. That means that boost::filesystem v2 has still not been obsoleted. According to the documentation, this will happen in version 1.48.0, which would thus make a good candidate for early rebase in Fedora 17 rawhide. I'm now building Boost 1.47.0 in rawhide for Fedora 16 rawhide. This involves soname bump, as usual, and so maintainers of dependent packages need to rebuild. The full list has been posted by Kalev Lember to this very thread. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.47.0
Kalev Lember kalevlem...@gmail.com writes: On 07/18/2011 11:35 PM, Petr Machata wrote: in accordance with the announced Fedora feature[1][2], we (the Boost maintainers) plan to rebase Boost to 1.47.0 really soon now. Boost 1.47.0 has been released recently and Denis Arnaud kindly did the packaging, so it is ready for scratch builds, smoke testing, and related fun. I'll do that in the next few days and if all comes out green-ish, I'll push the package into Fedora 16 and write a follow-up to this e-mail with guidelines on overcoming the obstacles, if any. How are you planning to handle the rebuilds for all the 176 affected source packages? Is there going to be a koji side tag for rebuilds? The last time around maintainers were largely able to respin their packages themselves when given a notice. What I did in the past, and plan an doing this time again, is that I go through the list, rebuilding the packages in mock. If bugs occur, I fix them either in Boost, or in the package itself, in which case I open FTBFS with a patch attached. I don't have privileges to bump, rebuild and patch the packages myself. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.47.0
Peter Robinson pbrobin...@gmail.com writes: On Mon, Jul 18, 2011 at 9:35 PM, Petr Machata [1]pmach...@redhat.com wrote: in accordance with the announced Fedora feature[1][2], we (the Boost maintainers) plan to rebase Boost to 1.47.0 really soon now. Boost 1.47.0 has been released recently and Denis Arnaud kindly did the packaging, so it is ready for scratch builds, smoke testing, and related fun. Don't hesitate to ping me on irc (_petr) with any concerns that you have. The only concern I have is with jumping to a release later than 1.47 in F-16 post alpha which is in fact the time when features should be complete. So in fact it should have already landed. Post alpha the release will branch from rawhide at which point please feel free to push 1.48 to F-17 rawhide with appropriate heads up to people. We definitely won't bump again in F16 cycle. What is likely to happen is series of isolated patches that we backport from future releases, as requested in bug reports or otherwise. We might consider pushing 1.47.1 if it turns up, but that largely depends on whether it would be humanly possible to review the patch-set for ABI breakages. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boost 1.47.0
Hi there, in accordance with the announced Fedora feature[1][2], we (the Boost maintainers) plan to rebase Boost to 1.47.0 really soon now. Boost 1.47.0 has been released recently and Denis Arnaud kindly did the packaging, so it is ready for scratch builds, smoke testing, and related fun. I'll do that in the next few days and if all comes out green-ish, I'll push the package into Fedora 16 and write a follow-up to this e-mail with guidelines on overcoming the obstacles, if any. Further plans: originally, we hoped that 1.48.0 would be about out by now, and we would manage to get beta into Fedora 16, much like we did with 1.46.0 for Fedora 15. But the Boost schedule slipped, and made any such plans impossible to realize[2]. At the same time, the sentiment of Boost upstream seems to be to (gradually) get back to the original schedule, so we may end up with 1.50.0 in Fedora 17. Handling +3 bump might end up being more interesting than is desirable, so to alleviate this, we will most probably want to do at least one larger rebase mid-Rawhide, either to 1.48.0, or 1.49.0. I'll write more when I know more. Don't hesitate to ping me on irc (_petr) with any concerns that you have. [1] https://fedoraproject.org/wiki/Features/F16Boost147 [2] https://bugzilla.redhat.com/show_bug.cgi?id=711845 Thanks, Petr Machata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is boost 1.46.1 in rawhide for real?
Bruno Wolff III br...@wolff.to writes: I don't remember seeing a soname bump announcement for boost and since for branched it went from 1.46.0 to 1.46.1 and then back to 1.46.0, I don't want to start rebuilding stuff if this is going to happen in rawhide too. It's not our plan te revert this in rawhide, but we plan to rebase again later in the cycle, probably for 1.48. I see that nothing has been rebuilt against 1.46.1 yet, so what I could do is keep the patchlevel and just drop the SONAME back to 1.46.0. The changes between 1.46.0 and 1.46.1 _should_ be safe--not quite safe enough for pushing to F15, in my opinion, but rawhide has seen worse. That way boost users shouldn't have to rebuild twice. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is boost 1.46.1 in rawhide for real?
Bruno Wolff III br...@wolff.to writes: On Wed, Apr 06, 2011 at 16:18:34 +0200, Petr Machata pmach...@redhat.com wrote: Bruno Wolff III br...@wolff.to writes: I don't remember seeing a soname bump announcement for boost and since for branched it went from 1.46.0 to 1.46.1 and then back to 1.46.0, I don't want to start rebuilding stuff if this is going to happen in rawhide too. It's not our plan te revert this in rawhide, but we plan to rebase again later in the cycle, probably for 1.48. I see that nothing has been rebuilt against 1.46.1 yet, so what I could do is keep the patchlevel and just drop the SONAME back to 1.46.0. The changes between 1.46.0 and 1.46.1 _should_ be safe--not quite safe enough for pushing to F15, in my opinion, but rawhide has seen worse. That way boost users shouldn't have to rebuild twice. I don't have a problem rebuilding twice. I'd like to get a heads up that a soname bump is comming, rather than finding out after the fact. This makes scheduling the work a bit easier. Boost is used by enough stuff, that I think a heads up to devel is warranted. In this particular case I was concerned, because of the previous reversion in F15 and didn't want to make things worse by starting rebuilds before I knew this change was going to stick. Yes, the soname bump in F15 was done by mistake, and obviously the testing caught that, so it was reverted right away. The bump in F16 was the result of the same mistake, but there I thought it might as well stay. Except I should have mailed to devel list about it, I'm sorry I didn't. So 1.46.1 is there for real, later to be replaced most probably by 1.48.0, or whatever the upstream manages to finish in the mean time. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Axel Thimm: Unresponsive maintainer?
Kevin Fenzi ke...@scrye.com writes: I have someone very interested in taking over mediawiki-openid and php-pear-Auth-OpenID, so I will probably approve them for those packages soon since they are both very broken and need love, but I wonder how many of the others are in the same state. :( Hope he's ok and will return to Fedora someday. If someone can get a hold of him, we should at least get co-maintainers for his packages so he doesn't need to worry about them. I'd be glad to take chrpath. PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How is it determined if a package needs to be rebuilt for a newer Fedora version?
Richard Shaw hobbes1...@gmail.com writes: On Wed, Mar 23, 2011 at 8:19 AM, Chris Adams cmad...@hiwaay.net wrote: This would be more appropriate on fedora-devel (any follow-up questions should go there). Basically, you rebuild a package when there is a good reason to rebuild it. You've made packaging changes or you pulled in a new upstream version are the main reasons for a package maintainer to do it. Sometimes it'll get rebuilt (or you'll need to submit a rebuild) when dependencies change (such as a shared library soname bump). I'm still a little green in this area. Do you mean that a version bump in the library that is not backward compatible? SONAME bump in a library is a priori backwards incompatible. The binary won't be able to start if the library name changes, because the dynamic linker will be looking for the library with the old version, and of course failing. The rawhide report and branched report e-mails that hit fedora-devel, list all the cases where the library name changed, but the binary was not yet rebuilt to pick up the change. PM -- 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
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
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
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
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
