Bug#1064188: mrpt: NMU diff for 64-bit time_t transition
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 > Tags: patch pending sid trixie > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > mrpt as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for mrpt > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if > information > becomes available that your package should not be included in the > transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) >
Bug#1035446: libmrpt-vision-lgpl-dev: missing Depends: libmrpt-vision-lgpl2.5 (= ${binary:Version})
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: > > Package: libmrpt-vision-lgpl-dev > Version: 1:2.5.8+ds-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > 0m49.8s ERROR: FAIL: Broken symlinks: > /usr/lib/x86_64-linux-gnu/libmrpt-vision-lgpl.so -> > libmrpt-vision-lgpl.so.2.5 (libmrpt-vision-lgpl-dev:amd64) > > There is a > Depends: libmrpt-vision2.5 (= 1:2.5.8+ds-1+b1) > which probably only mentions the wrong package name. > > > cheers, > > Andreas -- /** * Jose Luis Blanco-Claraco * Universidad de Almería - Departamento de Ingeniería * [Homepage]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */
Bug#997530:
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? "libcv-bridge-dev" is already listed in d/control... (?). Best, JL
Bug#986071: libmrpt-vision-lgpl-dev: broken symlink /usr/lib/x86_64-linux-gnu/libmrpt-vision-lgpl.so -> libmrpt-vision-lgpl.so.2.1
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 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 1m19.1s ERROR: FAIL: Broken symlinks: > /usr/lib/x86_64-linux-gnu/libmrpt-vision-lgpl.so -> > libmrpt-vision-lgpl.so.2.1 (libmrpt-vision-lgpl-dev) > > libmrpt-vision-lgpl-dev has a dependency on libmrpt-vision2.1, but that > should probably be libmrpt-vision-lgpl2.1 instead. > > > cheers, > > Andreas -- /** * Jose Luis Blanco-Claraco * Universidad de Almería - Departamento de Ingeniería * [Homepage]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */
Bug#978209: mrpt: FTBFS: mainwindow.h:218:2: error: reference to ‘Tracker’ is ambiguous
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
Bug#976803: mrpt uses private binutils shared library
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 On Tue, Dec 8, 2020 at 7:51 AM Matthias Klose wrote: > > Package: src:mrpt > Version: 1:2.1.5-1 > Severity: serious > Tags: sid bullseye > > mrpt uses private binutils shared libraries: > > Package: libmrpt-core2.1 > Depends: libbinutils (>= 2.35.1), libbinutils (<< 2.35.2), [...] > > Please don't do this. Either disable the use of these libraries, or > link these statically and add a Built-Using attribute to the binary package. -- /** * Jose Luis Blanco-Claraco * Universidad de Almería - Departamento de Ingeniería * [Homepage]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */
Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity
Thanks, Scott, it worked! https://buildd.debian.org/status/package.php?p=mrpt=sid JL
Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity
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
Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity
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 already a piece of logic in debian/rules but was only active in "mipsel", I have updated it upstream via this commit/patch: https://github.com/MRPT/mrpt/commit/8d60d8b5bc6e50e605c965ace165837840fb4c34 Do you think it might be worth submitting version 1:2.1.0-2 via a patch? @Scott: Should I upload an entire new package to mentors.debian.net, or would it be enough to send our the patch file, if you are willing to sponsor the new upload? Best, JL
Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity
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]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */
Bug#964044: mrpt: FTBFS: test failure
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 part of 2.0.4? Sorry for the confusion on this particular unit test. Yes, the commit you mention was already included into 2.0.4, and it solved all the issues detected by "valgrind helgrind". *But* even with that fixed, it failed as you reported in this bug, so there is this newer commit upstream: https://github.com/MRPT/mrpt/commit/e84511500276d38d3eeff0b220e8d45e0d74fc93 which is not yet released as 2.0.5, and which you can include as a patch if you want to go on with the ros-geometry2 transition. Cheers, JL -- /** * Jose Luis Blanco-Claraco * Universidad de Almería - Departamento de Ingeniería * [Homepage]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */
Bug#960703: mrpt: FTBFS on amd64: test failures
Thanks for reporting. It has been fixed in version 2:2.0.3-3. Cheers, JL
Bug#922586: FTBFS against opencv 4.0.1 (exp)
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 testing. Anyway, mrpt-2 comes with many different packages so (if I recall it right...) the procedure would be similar, it will have to go through the "New queue" (sigh). Right now, addressing all the opencv4 changes in the mrpt-1.x branch would take me too much time, which will be better invested in going for the 2.0.0 version. Thanks for all your help, any other comments or advice will be much appreciated!
Bug#922586: FTBFS against opencv 4.0.1 (exp)
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 final > package blocking wxwidgets3.0-gtk3's completion. > > I understand it's tempting when you're both upstream maintainer and > Debian maintainer to try to do everything via new upstream releases > (it's a trap I've fallen into myself), but there are situations where > just fixing it in Debian really is the better option. You are totally right, I can see it now However, I want to point out that we don't need to wait for mrpt-2.0.0, since the current version in unstable (1.5.8) already fixes this wxwidgets3.0-gtk3 bug. As you said, the problem now is the build issue in mipsel... I wrote an email to ftpmasters 12 days ago requesting the deletion of mrpt-1.x.x for mipsel, so we could go on quickly ago, but had no response yet. Perhaps you know a better way to go though? Perhaps a patch in debian/control to specify that we want mrpt-1.5.8 to get built on all archs except mipsel? Thanks, JL
