Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
Control: forwarded -1 https://ogre3d.atlassian.net/browse/OGRE-420 2014-06-13 6:21 GMT+01:00 Scott Howard showard...@gmail.com: block 744171 by 749944 thanks On Sun, Jun 1, 2014 at 12:29 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't know if I mention this to them in the past. It happened in a time when development was not very active and the old leader had to retire for some reason, I think. Since then, I submitted bugs that they fixed like inclusion of 3rd party library code, co-installability of different versions, support for new ports, etc. I will forward this to them hopefully soonish (but not now). If somebody beats me to it, I will not complain! :-) Cheers and thanks for your help. Thank you, sounds reasonable. FYI: freeorion FTBFS too. Putting a block on the transition bug so it shows up on their radar too. https://buildd.debian.org/status/package.php?p=freeorion I just uploaded a version depending on libboost*-dev, without versions (and closing this bug report); and forwarded the bug report upstream (URL above) as follow-up action, as per discussed previously. I am aware that setting this as forwarded and closing at the same time is a bit contradictory, but the main issue requested is fixed and I wanted to document the upstream bug somewhere. If from the discussion with upstream this requires a follow up in the mid-long term, I will open another bug report to better track its development. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
block 744171 by 749944 thanks On Sun, Jun 1, 2014 at 12:29 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't know if I mention this to them in the past. It happened in a time when development was not very active and the old leader had to retire for some reason, I think. Since then, I submitted bugs that they fixed like inclusion of 3rd party library code, co-installability of different versions, support for new ports, etc. I will forward this to them hopefully soonish (but not now). If somebody beats me to it, I will not complain! :-) Cheers and thanks for your help. Thank you, sounds reasonable. FYI: freeorion FTBFS too. Putting a block on the transition bug so it shows up on their radar too. https://buildd.debian.org/status/package.php?p=freeorion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
2014-05-31 16:30 GMT+01:00 Scott Howard showard...@gmail.com: Thanks for all the info, sorry to make you spend time rehashing this! For my own sanity, I'll try to summarize the technical problem: It looks like the troublesome functions are defined in headers [1], so ogre gets the definitions hardcoded if it pulls in the headers. Those functions are now statically included and may only be compatible with a specific version of boost threads. Because of this, programs can break since ogre is no longer binary compatible after a binNMU that bumps boost. The currently implemented fix solution is to define a build depends to a specefic the version of boos. That prevents ogre from secretly becoming binary incompatible with a binNMU, but it doesn't prevent it from happening manually. For example, even if ogre depended on boost 1.47 explicitly, this bug would have happened when ogre was bumped to 1.48 manually. Yes, I believe that the above, with two comments: - I don't know if the problem was supposed to be a bug in Boost that it's not likely to occur again until next century, or if OGRE or something else are doing something wrong in using Boost. The fact that it did not repeat in a few years (and could have been repeated now with the binNMU of ogre-1.8) seems to indicate that it's not very frequent, at least. - probably you meant this already, but it's not OGRE that it becomes incompatible with itself -- the incompatibility is in the projects that use OGRE I think, technically, it seems the the libogre package name should therefore have an indication of what boost version it was compiled against since policy says that if a new version of a library is not binary compatible with previous versions, it must have a name change. libogre-1.9 might have to be libogre-1.9-b1.54, and then the next version when compiled against boost 1.55 will be libogre-1.9-b1.55. That is awkward, but it looks like the only way to ensure binary compatibility. Maybe it's the only solution, but ugh, it's ugly and complicated/has many disadvantages (frequently having to go through NEW queue several times per year, transitions needed, etc). In that case I wonder if it's better to risk occasional problems! Specially since the solution was devised as a somehow quick fix before a freeze, and because I didn't know if the problem would recur in the future soon after that -- but it seems that it didn't, in a few years. If now the drawbacks are worse than just depending on the default Boost versions, maybe we can just do that. Longer term, maybe someone should talk with ogre upstream and see what they think of this. Should ogre be doing anything differently as to not expose those boost functions without a compiler error that there is a mismatch? Maybe ogre is missing [2]: #include boost/config/abi_prefix.hpp or #include boost/config.hpp in [3]? or something with: http://www.boost.org/development/separate_compilation.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674633#31 [2] http://www.boost.org/doc/libs/1_55_0/boost/config/abi_prefix.hpp [3] http://anonscm.debian.org/gitweb/?p=pkg-games/ogre-1.9.git;a=blob;f=OgreMain/include/Threading/OgreThreadHeadersBoost.h;hb=HEAD I don't know if I mention this to them in the past. It happened in a time when development was not very active and the old leader had to retire for some reason, I think. Since then, I submitted bugs that they fixed like inclusion of 3rd party library code, co-installability of different versions, support for new ports, etc. I will forward this to them hopefully soonish (but not now). If somebody beats me to it, I will not complain! :-) Cheers and thanks for your help. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
2014-05-31 2:06 GMT+01:00 Scott Howard showard...@gmail.com: reopen 749944 On Fri, May 30, 2014 at 7:50 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-05-31 0:18 GMT+01:00 Scott Howard showard...@gmail.com: On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: The versions are hardcoded to force reverse build-depends using the same versions, due to problems in the past (incompatibilities causing deadlocks when starting the application): Thank you for explaining. I'll update my package to follow ogre's hardcoded version of boost manually to prevent that bug from happening. Is that MyGui? mygui and openmw. I'm CC:ing Bret to this email, he's been maintaining them. Bret: Ogre exposes the boost ABI, so to prevent situations where previously compiled programs break when boost is bumped, ogre-1.9 is hardcoded to a specefic library version. Manuel, what do you think of this (please correct me if I'm wrong): Since packages depending on ogre-1.9 are built against other libraries that use boost-defaults, that causes them to FTBFS when the boost transition occurs. Ogre-1.9 does not transition with the rest of the archive. Packages really should depend on the version of boost in boost-defaults otherwise the archive might become inconsistent (you can see that 350 packages in the archive depend on boost, and ogre is one one of 4 that do not depend on the default version defined by boost-defaults). To keep the archive consistent and support the user case defined in bug 674633 I propose 1) ogre-1.9 depend on libboost-dev 2) libogre-1.9-dev depend on: libboost-dev (which would pull in the proper version and conflict for those users that are developing with another library, addressing bug 674633). Also: But it takes a bit of time, disk space (several GBs) of which I don't have much at the moment, and probably binNMUs to reverse dependencies just in case that something like that bug happens again (ogre-1.9 compiled with 1.55 and rdeps having been compiled with 1.54 from the previous versions forced by ogre-1.9 could cause a problem similar to the previous bug). That is what is supposed to happen when the whole archive transitions to a new version of boost. If ogre had a BD on boost-defaults (libboost*-dev), ogre and ogre's dependencies would have been binNMUed by the team performing the transition. Instead, the whole archive transitions, except ogre. Ogre's rdepends that also depend on either libboost-default or any other library that depends on libboost-default FTBFS and have to be removed from testing in order for the boost transition to complete. This isn't very important now, since few packages depend on ogre-1.9, but as the number of packages depending on ogre-1.9 increase, it will become increasingly important to depend on boost-defaults (libboost-dev). The bug described in 674633 is unfortunate, it will never occur in a stable release (were boost versions are not changing). I believe the emphasis should be on maintaining archive consistency which will mean users using unstable/testing as a development environment will break on occasion. You can reduce the effects of that breakage by build-depending on libboost-dev, thus forcing those users to also upgrade their code/compilation to the new versions of boost as well. I am a bit busy this weekend so I don't have time to relearn all of the intricacies of the issue, but from memory I think that it didn't happen exactly as you describe or with the same consequences. Just for reference, one thing that people has to have in mind before reading that bug report is CEGUI was not the Debian package but an upstream version (so it was not only an internal problem of Debian and transitions of packages in the archive), and the reporter was the lead developer of CEGUI. I also don't know if CEGUI was using boost::thread directly or only through OGRE (if it was using boost at the time it was for other libraries and not for the same thread thing; I think), and possibly using a way of compilation that introduced the problem directly into the binary (static compilation), not calling the dynamic library. With the next version of boost, OGRE was binNMUed or equivalent, and the code from boost was updated in a way that was incompatible with the previous code which was present in CEGUI binary (either for legit reasons or by mistakes in the libraries or their usage). Say, with the old version, CEGUI got statically compiled a version doing something like (probably nothing like what really happened, but hopefully helps explain the problem): lock(resrcmgr_lock) lock(resrc_a) do_stuff() lock(resrc_b) With the new version, OGRE had something like: lock(resrc_a) lock(resrcmgr_lock) do_stuff() lock(resrc_b) For some reason, things interlocked in initialisation every time. In that case, since the code of CEGUI is updated only at compile time, it cannot be
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
Thanks for all the info, sorry to make you spend time rehashing this! For my own sanity, I'll try to summarize the technical problem: It looks like the troublesome functions are defined in headers [1], so ogre gets the definitions hardcoded if it pulls in the headers. Those functions are now statically included and may only be compatible with a specific version of boost threads. Because of this, programs can break since ogre is no longer binary compatible after a binNMU that bumps boost. The currently implemented fix solution is to define a build depends to a specefic the version of boos. That prevents ogre from secretly becoming binary incompatible with a binNMU, but it doesn't prevent it from happening manually. For example, even if ogre depended on boost 1.47 explicitly, this bug would have happened when ogre was bumped to 1.48 manually. I think, technically, it seems the the libogre package name should therefore have an indication of what boost version it was compiled against since policy says that if a new version of a library is not binary compatible with previous versions, it must have a name change. libogre-1.9 might have to be libogre-1.9-b1.54, and then the next version when compiled against boost 1.55 will be libogre-1.9-b1.55. That is awkward, but it looks like the only way to ensure binary compatibility. Longer term, maybe someone should talk with ogre upstream and see what they think of this. Should ogre be doing anything differently as to not expose those boost functions without a compiler error that there is a mismatch? Maybe ogre is missing [2]: #include boost/config/abi_prefix.hpp or #include boost/config.hpp in [3]? or something with: http://www.boost.org/development/separate_compilation.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674633#31 [2] http://www.boost.org/doc/libs/1_55_0/boost/config/abi_prefix.hpp [3] http://anonscm.debian.org/gitweb/?p=pkg-games/ogre-1.9.git;a=blob;f=OgreMain/include/Threading/OgreThreadHeadersBoost.h;hb=HEAD -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
Source: ogre-1.9 Severity: wishlist Hello, Ogre-1.9 builds against boost 1.54. Debian just bumped boost-defaults to 1.55. Is it possible to bump debian/control BDs such that it builds against libboost-dev instead of libboost1.54-dev? It will make future transitions easier. Thank you. https://release.debian.org/transitions/html/boost1.55.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744171 ~Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
2014-05-30 20:39 GMT+01:00 Scott Howard showard...@gmail.com: Source: ogre-1.9 Severity: wishlist Hello, Ogre-1.9 builds against boost 1.54. Debian just bumped boost-defaults to 1.55. Is it possible to bump debian/control BDs such that it builds against libboost-dev instead of libboost1.54-dev? It will make future transitions easier. Thank you. https://release.debian.org/transitions/html/boost1.55.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744171 Hi Scott, Is this necessary because 1.54 is going to be removed? The versions are hardcoded to force reverse build-depends using the same versions, due to problems in the past (incompatibilities causing deadlocks when starting the application): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674633 http://metadata.ftp-master.debian.org/changelogs/main/o/ogre/unstable_changelog (last item in 1.7.4+dfsg1-6) Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
2014-05-31 0:18 GMT+01:00 Scott Howard showard...@gmail.com: On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: The versions are hardcoded to force reverse build-depends using the same versions, due to problems in the past (incompatibilities causing deadlocks when starting the application): Thank you for explaining. I'll update my package to follow ogre's hardcoded version of boost manually to prevent that bug from happening. Is that MyGui? I plan to switch ogre-1.9 to 1.55 soon, specially if it's the one for next stable, or perhaps wait a bit to see if it's bumped again before the freeze. But it takes a bit of time, disk space (several GBs) of which I don't have much at the moment, and probably binNMUs to reverse dependencies just in case that something like that bug happens again (ogre-1.9 compiled with 1.55 and rdeps having been compiled with 1.54 from the previous versions forced by ogre-1.9 could cause a problem similar to the previous bug). Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
reopen 749944 On Fri, May 30, 2014 at 7:50 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-05-31 0:18 GMT+01:00 Scott Howard showard...@gmail.com: On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: The versions are hardcoded to force reverse build-depends using the same versions, due to problems in the past (incompatibilities causing deadlocks when starting the application): Thank you for explaining. I'll update my package to follow ogre's hardcoded version of boost manually to prevent that bug from happening. Is that MyGui? mygui and openmw. I'm CC:ing Bret to this email, he's been maintaining them. Bret: Ogre exposes the boost ABI, so to prevent situations where previously compiled programs break when boost is bumped, ogre-1.9 is hardcoded to a specefic library version. Manuel, what do you think of this (please correct me if I'm wrong): Since packages depending on ogre-1.9 are built against other libraries that use boost-defaults, that causes them to FTBFS when the boost transition occurs. Ogre-1.9 does not transition with the rest of the archive. Packages really should depend on the version of boost in boost-defaults otherwise the archive might become inconsistent (you can see that 350 packages in the archive depend on boost, and ogre is one one of 4 that do not depend on the default version defined by boost-defaults). To keep the archive consistent and support the user case defined in bug 674633 I propose 1) ogre-1.9 depend on libboost-dev 2) libogre-1.9-dev depend on: libboost-dev (which would pull in the proper version and conflict for those users that are developing with another library, addressing bug 674633). Also: But it takes a bit of time, disk space (several GBs) of which I don't have much at the moment, and probably binNMUs to reverse dependencies just in case that something like that bug happens again (ogre-1.9 compiled with 1.55 and rdeps having been compiled with 1.54 from the previous versions forced by ogre-1.9 could cause a problem similar to the previous bug). That is what is supposed to happen when the whole archive transitions to a new version of boost. If ogre had a BD on boost-defaults (libboost*-dev), ogre and ogre's dependencies would have been binNMUed by the team performing the transition. Instead, the whole archive transitions, except ogre. Ogre's rdepends that also depend on either libboost-default or any other library that depends on libboost-default FTBFS and have to be removed from testing in order for the boost transition to complete. This isn't very important now, since few packages depend on ogre-1.9, but as the number of packages depending on ogre-1.9 increase, it will become increasingly important to depend on boost-defaults (libboost-dev). The bug described in 674633 is unfortunate, it will never occur in a stable release (were boost versions are not changing). I believe the emphasis should be on maintaining archive consistency which will mean users using unstable/testing as a development environment will break on occasion. You can reduce the effects of that breakage by build-depending on libboost-dev, thus forcing those users to also upgrade their code/compilation to the new versions of boost as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
On Fri, May 30, 2014 at 9:06 PM, Scott Howard showard...@gmail.com wrote: You can reduce the effects of that breakage by build-depending on libboost-dev, thus forcing those users to also upgrade their code/compilation to the new versions of boost as well. typo: you can reduce the effects of that breakage by having libogre-1.9-dev DEPEND on libboost-dev, thus forcing those users to also upgrade their code/compilation to the new versions of boost as well. update: 99.2% of the packages in the archive build against boost-defaults (libboost-dev). Every library in the archive except one builds against boost-defaults. The one that does not only compiles against boost 1.54 and thus is manually set. They are probably going to switch to libboost-dev now that debian is at 1.55. That means that any package that depends on ogre-1.9 and also depends on any other library that is an rdepends of boost will FTBFS. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
