Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
On 29/12/17 17:37, Philipp Huebner wrote: > Hi, > > Am 27.12.2017 um 10:25 schrieb Emilio Pozuelo Monfort: > >> BTW I was going to schedule this binNMU for the time being in order to have a >> working ceres-solver, but it seems there was an upload since this request was >> opened. Do you need a binNMU now? If so I'll schedule it. > > while it's true that there was an upload of ceres, there was also > another upload of eigen since, causing #883619, so please do schedule a > binNMU for ceres as well. Scheduled. Emilio
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi, Am 27.12.2017 um 10:25 schrieb Emilio Pozuelo Monfort: > BTW I was going to schedule this binNMU for the time being in order to have a > working ceres-solver, but it seems there was an upload since this request was > opened. Do you need a binNMU now? If so I'll schedule it. while it's true that there was an upload of ceres, there was also another upload of eigen since, causing #883619, so please do schedule a binNMU for ceres as well. Regards, -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
On 28/12/17 11:44, Jochen Sprickerhof wrote: > Hi Emilio, > > * Emilio Pozuelo Monfort [2017-12-27 10:25]: >> Now, it'd be a different case if your project exposed part of the Eigen ABI, >> and >> given there's no shared library, there can't be a SONAME bump so the only >> way to >> ensure there are no ABI mismatches is to ensure all projects are built with >> the >> same Eigen version. > > That's the case for Ceres and PCL. The headers and shared objects shows > numerous > references to Eigen. > >> BTW I was going to schedule this binNMU for the time being in order to have a >> working ceres-solver, but it seems there was an upload since this request was >> opened. Do you need a binNMU now? If so I'll schedule it. Otherwise let's >> continue this conversation to clarify whether these binNMUs are required or >> they >> could be prevented. > > Ceres was, but if you could schedule one for pcl, that would be great. And > yes, > let's use this Bug to continue the discussion. pcl binNMUed. If you can come up with an example that shows why building two packages with different versions of eigen would cause problems, that'd be good. Cheers, Emilio
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi Emilio, * Emilio Pozuelo Monfort [2017-12-27 10:25]: Now, it'd be a different case if your project exposed part of the Eigen ABI, and given there's no shared library, there can't be a SONAME bump so the only way to ensure there are no ABI mismatches is to ensure all projects are built with the same Eigen version. That's the case for Ceres and PCL. The headers and shared objects shows numerous references to Eigen. BTW I was going to schedule this binNMU for the time being in order to have a working ceres-solver, but it seems there was an upload since this request was opened. Do you need a binNMU now? If so I'll schedule it. Otherwise let's continue this conversation to clarify whether these binNMUs are required or they could be prevented. Ceres was, but if you could schedule one for pcl, that would be great. And yes, let's use this Bug to continue the discussion. Cheers Jochen signature.asc Description: PGP signature
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi Jochen, On 23/12/17 18:11, Jochen Sprickerhof wrote: > Hi Julien, > > * Julien Cristau [2017-12-02 19:46]: >> I don't think the release team is willing to routinely do this without >> understanding why we're doing it, so an explanation for why these would >> be necessary is welcome. > > I gave some insides in this same bug in https://bugs.debian.org/868355#15. > Can you be more specific if you need more information? I still don't quite understand what the exact problem is. You talk about the "one definition rule", but my question is, why does that matter? If your project uses Eigen but doesn't export any Eigen symbols on its API/ABI, then it doesn't matter if a newer version of Eigen changes definitions, structs, or anything else. A third project using both Eigen and your project wouldn't be affected by the different Eigen version than your project was built with, because your project doesn't expose Eigen at all. Now, it'd be a different case if your project exposed part of the Eigen ABI, and given there's no shared library, there can't be a SONAME bump so the only way to ensure there are no ABI mismatches is to ensure all projects are built with the same Eigen version. It's possible that I'm rather confused about how Eigen works, and that these strict build dependency checks are needed for a different reason. I am not familiar with Eigen, so that's why I need you to explain me why we need these checks. If they are needed for a good reason, I am OK with that and will be happy to schedule the binNMUs whenever they are needed. But if not, I'd like to avoid us doing unnecessary binNMUs. For reference, other projects have had strict version checks on the compiler. Those are generally not needed, and we've been able to disable those checks and talk to upstream about it. BTW I was going to schedule this binNMU for the time being in order to have a working ceres-solver, but it seems there was an upload since this request was opened. Do you need a binNMU now? If so I'll schedule it. Otherwise let's continue this conversation to clarify whether these binNMUs are required or they could be prevented. Cheers, Emilio
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi Julien, * Julien Cristau [2017-12-02 19:46]: I don't think the release team is willing to routinely do this without understanding why we're doing it, so an explanation for why these would be necessary is welcome. I gave some insides in this same bug in https://bugs.debian.org/868355#15. Can you be more specific if you need more information? Thanks and Cheers Jochen signature.asc Description: PGP signature
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Control: tag -1 moreinfo On Sat, Aug 12, 2017 at 08:28:30 +0200, Jochen Sprickerhof wrote: > Hi Emilio, > > can you comment if requesting BinNMUs in such cases would be ok for the > release team, or should we try find an other solution? > I don't think the release team is willing to routinely do this without understanding why we're doing it, so an explanation for why these would be necessary is welcome. Cheers, Julien
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi Emilio, can you comment if requesting BinNMUs in such cases would be ok for the release team, or should we try find an other solution? Cheers Jochen * Anton Gladky [2017-07-19 17:59]: > Hi all, > > well, I would prefer to rebuild all reverse dependencies after > each new eigen3 (and probably any other header-only lib) > upload [1] and be ready to request it. But it looks like it is > not a common case to do such BinNMUs. > > [1] https://bugs.debian.org/845819 > > Regards > > Anton > > > 2017-07-19 8:35 GMT+02:00 Philipp Huebner : > > Hi, > > > > until I find the time to package the new release of Ceres Solver, > > please go ahead with the BinNMU. > > > > With Eigen3 being a header-only library and numeric math libraries > > making use of derivatives and templating like crazy, I believe this > > strict Eigen3 check to be well reasoned. > > > > I'll ask upstream about this, but expect them to confirm it. > > > > > > Regards, > > -- > > .''`. Philipp Huebner > > : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F > > `. `'` > > `- > > > signature.asc Description: PGP signature
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi all, well, I would prefer to rebuild all reverse dependencies after each new eigen3 (and probably any other header-only lib) upload [1] and be ready to request it. But it looks like it is not a common case to do such BinNMUs. [1] https://bugs.debian.org/845819 Regards Anton 2017-07-19 8:35 GMT+02:00 Philipp Huebner : > Hi, > > until I find the time to package the new release of Ceres Solver, > please go ahead with the BinNMU. > > With Eigen3 being a header-only library and numeric math libraries > making use of derivatives and templating like crazy, I believe this > strict Eigen3 check to be well reasoned. > > I'll ask upstream about this, but expect them to confirm it. > > > Regards, > -- > .''`. Philipp Huebner > : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F > `. `'` > `- >
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi, until I find the time to package the new release of Ceres Solver, please go ahead with the BinNMU. With Eigen3 being a header-only library and numeric math libraries making use of derivatives and templating like crazy, I believe this strict Eigen3 check to be well reasoned. I'll ask upstream about this, but expect them to confirm it. Regards, -- .''`. Philipp Huebner : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
[adding Philipp and Anton as the respective maintainers] * Emilio Pozuelo Monfort [2017-07-15 09:40]: > On 14/07/17 21:42, Jochen Sprickerhof wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > Hi, > > > > please rebuild Ceres against the current Eigen3 version, as it encodes the > > version in the CeresConfig.cmake and makes Google Cartographer to file in > > cmake > > with: > > > > CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message): > > Failed to find Ceres - Found Eigen dependency, but the version of Eigen > > found (3.3.4) does not exactly match the version of Eigen Ceres was > > compiled with (3.3.2). This can cause subtle bugs by triggering > > violations > > of the One Definition Rule. See the Wikipedia article > > http://en.wikipedia.org/wiki/One_Definition_Rule for more details > > Why do you need the same version at runtime than the one it was compiled with? > Multiple definitions doesn't sound like a good reason to me, as eigen and > ceres > shouldn't be defining things in the same namespace in the first place, thus > conflicts should be impossible. > > Sounds like a too strict check that should be removed. I think it's an actual problem not only in Ceres: http://eigen.tuxfamily.narkive.com/fweQWUaX/eigen-and-the-one-definition-rule At the moment Ceres is not usable in Debian unstable, so as a simple measure I would propose to do the binnmu. I'm not sure about a long term solution. I've looked into the Built-Using field [1]. But we would have to make sure that every package using Eigen adds this field and I have found nothing about recompiling every user automatically when a new Eigen version is uploaded. I assume it would be better to trigger a rebuild of all dependencies when Eigen is uploaded, but I'm not aware of an automatic mechanism in Debian to do that. Any ideas? Cheers Jochen [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using signature.asc Description: PGP signature
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
On 14/07/17 21:42, Jochen Sprickerhof wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hi, > > please rebuild Ceres against the current Eigen3 version, as it encodes the > version in the CeresConfig.cmake and makes Google Cartographer to file in > cmake > with: > > CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message): > Failed to find Ceres - Found Eigen dependency, but the version of Eigen > found (3.3.4) does not exactly match the version of Eigen Ceres was > compiled with (3.3.2). This can cause subtle bugs by triggering violations > of the One Definition Rule. See the Wikipedia article > http://en.wikipedia.org/wiki/One_Definition_Rule for more details Why do you need the same version at runtime than the one it was compiled with? Multiple definitions doesn't sound like a good reason to me, as eigen and ceres shouldn't be defining things in the same namespace in the first place, thus conflicts should be impossible. Sounds like a too strict check that should be removed. Emilio
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please rebuild Ceres against the current Eigen3 version, as it encodes the version in the CeresConfig.cmake and makes Google Cartographer to file in cmake with: CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message): Failed to find Ceres - Found Eigen dependency, but the version of Eigen found (3.3.4) does not exactly match the version of Eigen Ceres was compiled with (3.3.2). This can cause subtle bugs by triggering violations of the One Definition Rule. See the Wikipedia article http://en.wikipedia.org/wiki/One_Definition_Rule for more details Thanks! Jochen nmu ceres-solver_1.12.0+dfsg0-1+b3 . ANY . unstable . -m "Rebuild against new libeigen3-dev" -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)