Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Emilio Pozuelo Monfort]

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

[Philipp Huebner]

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

[Emilio Pozuelo Monfort]

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

[Jochen Sprickerhof]

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

[Emilio Pozuelo Monfort]

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

[Jochen Sprickerhof]

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

[Julien Cristau]

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

Processed: Re: Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #868355 [release.debian.org] nmu: ceres-solver_1.12.0+dfsg0-1+b3
Added tag(s) moreinfo.

-- 
868355: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868355
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Jochen Sprickerhof]

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

[Anton Gladky]

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

[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: OpenPGP digital signature

Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Jochen Sprickerhof]

[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

[Emilio Pozuelo Monfort]

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

[Jochen Sprickerhof]

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)