Hi Steve,
As package and upstream's maintainer, what should I do to ensure the
library is change safe?
Would it help to totally remove references to time_t in all public headers?
El dom, 18 feb 2024, 9:00, Steve Langasek escribió:
> Source: mrpt
> Version: 1:2.11.9+ds-1
> Severity: important
Thanks, Andreas!
Fixed on salsa:
https://salsa.debian.org/robotics-team/mrpt/-/commit/37b6bbda747e7dc540cb61a001ed0026cd5be7f9
However, I think we can't make any release to Debian/sid at the moment
due to the freeze, right?
Cheers,
JL
On Wed, May 3, 2023 at 3:51 PM Andreas Beckmann wrote:
>
>
Hi Lucas,
Thanks for reporting!
I've investigated this and found that the error comes from building
against a version of the package "cv_bridge" (libcv-bridge-dev) which
wasn't yet rebuilt against the latest opencv 4.5.4, but for the older
4.5.3.
Does this still qualify as a FTBFS error in mrpt?
Wow, good catch, thanks!
It's now fixed upstream [1], the next release will come with this fixed.
[1] https://github.com/MRPT/mrpt/commit/e585a555b556b97bef50a803b9dfd9d53070931f
On Mon, Mar 29, 2021 at 11:09 AM Andreas Beckmann wrote:
>
> Package: libmrpt-vision-lgpl-dev
> Version: 1:2.1.7-1
>
Thanks Lucas for reporting.
This seems to be an issue detected with gcc 10.2.1, since I tried with
the exact opencv version 4.5.1 and both gcc 7.5 and 10.2.0 and it
didn't complain about that ambiguity.
I'll try to install gcc 10.2.1 to verify this.
Best,
JL
Hi Matthias:
I'm curious about the rationale of not using libbinutils as shared
libraries... sorry if this seems a stupid question!
The dependency was added in this last version to enable using BFD to
find debug info in binaries and expose that in the upstream library
functionality.
Cheers,
JL
Thanks, Scott, it worked!
https://buildd.debian.org/status/package.php?p=mrpt&suite=sid
JL
On Sat, Sep 26, 2020 at 3:30 AM Scott Talbert wrote:
> If you don't mind, please do a new package upload to mentors.
Sure! Done here:
https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_2.1.0-2.dsc
Best,
JL
Hi Sebastian (cc: Scott):
On Fri, Sep 25, 2020 at 10:50 PM Sebastian Ramacher
wrote:
> Reducing the optimization level on mips64el might help to reduce the
> compile time. Alternatively, if possible, one could split the source
> files into smaller ones.
Hmmm... great idea!
In fact, there was al
Thanks for reporting, Sebastian!
Although, I'm not sure how to proceed in this case... it compiled in
the past but it looks like the builder machine entered into swapping
(?) this time.
JL
--
/**
* Jose Luis Blanco-Claraco
* Universidad de Almería - Departamento de Ingeniería
* [Homepage]( h
Hi, Gianfranco:
> > This issue has been fixed upstream:
> > https://github.com/MRPT/mrpt/commit/15234dc335c2413e3fd41021f7511f1d36fe915b.
> > Could you please apply the fix to the Debian package so that
> > ros-geometry2 transition can be completed? Thanks
>
>
> looks like that commit is already p
Thanks for reporting.
It has been fixed in version 2:2.0.3-3.
Cheers,
JL
Ok, sorry, forgot my last message, you already mentioned the new problem:
> But now that missing mipsel build can't be addressed without
> also updating mrpt for auto-opencv because it currently FTBFS in
> unstable.
It's a shame, but I think that perhaps I'll just leave mrpt to be
removed from te
Hi Olly,
> It was waiting for mrpt 2.0.0 for wxwidgets3.0-gtk3 that got us into the
> current mess of having two entangled transitions on the go for mrpt. If
> we'd just updated the B-Ds of the existing package we'd have got that
> out the way weeks (possibly months) ago. Instead mrpt is now the
14 matches
Mail list logo
