Created attachment 696323 [details] Fix for this issue Description of problem: See this build log: http://kojipkgs.fedoraproject.org/work/tasks/7320/4947320/build.log In particular: gcc.compile.c++ /builddir/build/BUILD/built_artifacts/gcc-4.8.0/release/asl-dev/link-static/threading-multi/source/eve.o In file included from source/eve.cpp:22:0: ./adobe/cmath.hpp:76:12: error: 'std::float_t' has not been declared using std::float_t; There's a couple more. math.hpp seems to be relying on the fact that std::float_t will be available outside of C++11 mode, which it isn't, with recent GCC. I think it should instead always request tr1/cmath and look into std::tr1::float_t. I'm attaching a patch to this effect.
Hi, and thanks for patch! I've seen this coming, and is hesitating because asl is just a dependency of bombono-dvd. And bombobo upstream seems dead ATM. So, to orphan or not, that is the question. I'll decide and take care of this shortly.
(In reply to comment #1) > I've seen this coming, and is hesitating because asl is just a dependency of > bombono-dvd. And bombobo upstream seems dead ATM. So, to orphan or not, that > is the question. please continue with ASL I resumed working on packaging GiGi (bug #571416) and it needs ASL - in fact I was about to kindly ask if you were willing to package also APL?
Petr: many thanks for the patch, it saved me a lot of time! I have adjusted it (it didn't apply cleanly for some reason) and rebuilt the package. Karel: as of now, I have no plans to package APL. In fact, I think it would be best to do that in a GiGi context, IIRC it's patched to fit GiGi. I can continue to maintain ASL as long as bombono is buildable, but with a dead upstream this will not be the case forever (it might even break on the same gcc changes as ASL; I don't know until rpmfusion is rebuilt).
(In reply to comment #3) > Karel: as of now, I have no plans to package APL. okay, I'll try myself if I have some spare time (and energy) > In fact, I think it would be best to do that in a GiGi context, IIRC it's > patched to fit GiGi. the plan is to patch GiGi to work with separate APL and push the necessary changes upstream ... most of the bundled sources seem to be untouched, so it shouldn't be hard to adapt GiGi to work without custom patches in APL > I can continue to maintain ASL as long as bombono is buildable, but with > a dead upstream this will not be the case forever probably the author thinks that it has reached perfection and there's nothing else to improve in the code :-) anyways, thanks for getting ASL into Fedora, and I'll be glad if you take care about it as long as possible
(In reply to comment #4) > (In reply to comment #3) > > Karel: as of now, I have no plans to package APL. > > okay, I'll try myself if I have some spare time (and energy) uh, oh, giving up for now, I've found that APL is very closely tied to ASL, it shares the buildsystem, making it separate is far beyond my abilities ... maybe it'd be better to add it as a subpackage of ASL (if there was a volunteer :-)) > > In fact, I think it would be best to do that in a GiGi context, IIRC it's > > patched to fit GiGi. > > the plan is to patch GiGi to work with separate APL and push the necessary > changes upstream ... most of the bundled sources seem to be untouched, so it > shouldn't be hard to adapt GiGi to work without custom patches in APL giving up this one too I've spent the whole yesterday trying building GiGi with the upstream version of libraries, and the devil lies in "most of" - that tiny bit which differs seems the most complicated part, it wouldn't be just simple patching of a few changes but a rewrite of some functions/internal logic to adapt for changes in data structures etc. > > I can continue to maintain ASL as long as bombono is buildable, but with > > a dead upstream this will not be the case forever ... > anyways, thanks for getting ASL into Fedora, and I'll be glad if you take > care about it as long as possible considering the above, I'd rather try to get an exception for bundling the libraries, so GiGi won't depend on your package but still I'm hesitant to give up completely, you've did a great job getting this into Fedora, and now it should be in vain? :-/
What we did with ASL/Bombono was to add some #ifdef's to the sources which by default was undefined, but defined by the bombono build. Could you do something similar? Last time I checked the upstream wasn't that active, and patches was queued for a very long time. I actually think bundling is the right way to go here, the big changes in combination with dead upstream being the motive. If you apply for a bundling exception and FPC returns a "No, build an APL package" I'll see if we can work together with a ASL subpackage. But please investigate the bundling exception first, I actually think it's the best option here.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.