Bug#1066207: marked as pending in mrpt

[Jose Luis Blanco-Claraco]

Control: tag -1 pending

Hello,

Bug #1066207 in mrpt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/robotics-team/mrpt/-/commit/26ef06161dcc53c70a646d7fd6e3c189da10dd95


Add d/patch to fix FTBFS (Closes: #1066207)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066207

Bug#933469: Solved

[Jose Luis Blanco]

This bug has been solved with the new uploaded version: mrpt 1:1.5.8-1

Already sent a mail to cont...@bugs.debian.org to mark it as solved.

Cheers,
JL

Bug#874220: openni2 mustn't build with NEON on armel/armhf

[JOSE LUIS BLANCO CLARACO]

Hi Adrian,

Thanks for tagging "mrpt" here!
Is there any expected action on our side? Should we disable linking
against openni2 in armhf in the meanwhile... or it's better to wait
for this bug to be solved? It actually blocks mrpt to get into
testing...

Cheers,


On Mon, Sep 4, 2017 at 12:45 PM, Adrian Bunk <b...@debian.org> wrote:
> Source: openni2
> Version: 2.2.0.33+dfsg-7
> Severity: serious
> Tags: patch
> Control: affects -1 src:mrpt
>
> NEON is not part of the armel and armhf architecture baselines,
> it is therefore not permitted to use NEON unless proper runtime
> detection is used.
>
> NEON is also not available on the autobuilders.
>
>
> openni2 trying to build with NEON on armel causes it to FTBFS:
>
> https://buildd.debian.org/status/logs.php?pkg=openni2=armel
>
> ...
> In file included from Sensor/XnPacked11DepthProcessor.cpp:27:0:
> /usr/lib/gcc/arm-linux-gnueabi/7/include/arm_neon.h:31:2: error: #error "NEON 
> intrinsics not available with the soft-float ABI.  Please use 
> -mfloat-abi=softp or -mfloat-abi=hard"
>  #error "NEON intrinsics not available with the soft-float ABI.  Please use 
> -mfloat-abi=softp or -mfloat-abi=hard"
>   ^
>
>
>
> I also strongly suspect that the FTBFS of mrpt on armhf might be
> caused by this bug (test_mrpt_hwdrivers is linked with libOpenNI2):
>
> https://buildd.debian.org/status/fetch.php?pkg=mrpt=armhf=1%3A1.5.3-1=1504457093=0
>
> ...
> cd /<>/obj-arm-linux-gnueabihf/tests && ./test_mrpt_hwdrivers
> Illegal instruction
>
>
>
> The "uname -m" usage in ThirdParty/PSCommon/BuildSystem/CommonDefs.mak
> is wrong and also results in openni2 being built differently for i386
> depending on whether a 32bit or 64bit kernel is used, but here I am
> only addressing the ARM issues.
>
> The fix contains of 3 parts:
>
> 1. In debian/patches/series, comment out
> 0006-rpi-Added-Armv6l-as-new-target-platform-and-created-missing-OniPlatformLinux-Arm.h-header.patch
>
> This only made the uname bug above worse.
>
>
> 2. In debian/patches/0012-generic-linux.patch, fix a typo in
> ThirdParty/PSCommon/BuildSystem/Platform.generic: FLAGS -> CFLAGS
>
>
> 3. Add the attached 0016-armel-armhf-no-neon.patch



-- 
___

Jose Luis Blanco-Claraco
Universidad de Almería - Departamento de Ingeniería
https://w3.ual.es/~jlblanco/
https://github.com/jlblancoc
___

Bug#873525: mrpt: FTBFS on mips64el: test_mrpt_graphslam fails

[JOSE LUIS BLANCO CLARACO]

Dear Aaron,  (cc: Santiago)

Thanks for reporting this one!

I spent some time debugging this issue raised in mips64el and the only
suspicious operations in that code area (detected with GCC sanitizers)
have been fixed upstream with the patch in [1].

Unfortunately, I have no easy way (qemu aside...) to test the
compilation of the package in this architecture to assess whether the
bug has really gone; realistically, the bug might probably still be
there, and more testing would be required.

I found out [2] that there is one porter box named "eller.debian.org"
which may be useful to debug this issue...
Is there a procedure to request temporary access to such a builder machine?

Last year I read about this same topic and arrived to the conclusion
that "the way" was to apply to become a "Debian Maintainer"... what do
you think about this?

Best,
JL

[1] https://github.com/MRPT/mrpt/commit/440e1d8aa677933f7954c4ae4f0b086fa4e24761
[2] 
https://wiki.debian.org/MIPSPort?action=show=mips64el#Development_Team
[3] https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer


On Mon, Aug 28, 2017 at 8:11 PM, Aaron M. Ucko <u...@debian.org> wrote:
> Source: mrpt
> Version: 1:1.5.3-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The latest mips64el build of mrpt failed:
>
>   cd /<>/obj-mips64el-linux-gnuabi64/tests && 
> ./test_mrpt_graphslam
>   [==] Running 4 tests from 2 test cases.
>   [--] Global test environment set-up.
>   [--] 2 tests from GraphSlamLevMarqTester2D
>   [ RUN  ] GraphSlamLevMarqTester2D.OptimizeSampleRingPath
>   /<>/libs/graphslam/src/graph_slam_levmarq_unittest.cpp:59: 
> Failure
>   Expected: (levmarq_info.final_total_sq_error) <= (1e-2), actual: 534.008 vs 
> 0.01
>   Bus error
>   tests/CMakeFiles/run_tests_mrpt_graphslam.dir/build.make:60: recipe for 
> target 'tests/CMakeFiles/run_tests_mrpt_graphslam' failed
>
> Could you please take a look?
>
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
___

Jose Luis Blanco-Claraco
Universidad de Almería - Departamento de Ingeniería
https://w3.ual.es/~jlblanco/
https://github.com/jlblancoc
___

Bug#834274: mrpt: FTBFS in testing

[JOSE LUIS BLANCO CLARACO]

I couldn't replicate this particular crash in my machine with Eigen
3.3beta1, but I guess where the error is and have pushed a patch. The
package is now in mentors: [1].

I tested it 100% on my local system and in a pbuild (sid) environment,
without any problem, so hopefully this one will make it!

Cheers,

[1] https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-7.dsc

Bug#834274: mrpt: FTBFS in testing

[JOSE LUIS BLANCO CLARACO]

Yes, Santiago notified me and I'm investigating it... Thanks for taking
care!

Bug#834274: mrpt: FTBFS in testing

[JOSE LUIS BLANCO CLARACO]

You're right, it's better like that.

Done. It should be online within minutes in the same link:
https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-6.dsc

Cheers,

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

Hi again Gianfranco,

I just noticed a missing open bug regarding a FTBFS on sparc64. OK,
it's a weird platform... but I already had the fix upstream, it was
overlooked in the last set of patches.

I added a new patch for it in a new version 1.4.0-3 and just uploaded
it to Mentors [1]. It would be great if you could sponsor it, so the
package becomes bug-free...

Cheers and thanks again for everything!
JL

[1] https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-3.dsc

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

All green! :-) See [1].

Thank you so much for the push.

I guess that the second half of archs in [1] are not officially
supported and it's not a big deal to have some failures on them,
right?

Best, have a nice weekend.
JL

[1] https://buildd.debian.org/status/package.php?p=mrpt

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

Thanks so much!

Sure I will, every day learning something new...

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

> ok, rebased with current debian/unstable package and build good
>
> I did grab the package from unstable, added the commit above, and did a 
> complete build.
> It didn't fail on s390x, so I don't know how to trigger that failure.

Well, that's good news, I guess! Thank you for your time.

I have just cherry-picked some commits and applied them to 1.4.0-1
(current "unstable") to create 1.4.0-2 which should fix all FTBFS
bugs, hopefully...
The DSC is in [1]. This is my first debian package with patches (via
dquilt) but I think it's fine.

Perhaps you could consider sponsoring its upload to Debian so we can
close a few bugs and fix the package for big-endian platforms?

Best,
JL

[1] https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-2.dsc

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

Hi again Gianfranco,

I think I've (properly) fixed the issues in big-endian architectures
for one set of tests.
It would be great if you could launch a build in a test machine to confirm it...

The patch is in [1]. You could test it over release 1.4.0 (*without*
the latest patch which, if you recall it, just put a #if 0 around the
failing tests!), or just grab the whole thing from git master [2].

>From Debian logs, I see that there is one more test that fails in
*some* big endian architectures. I'm almost sure it could be debugged
by running it with gdb.
In these last weeks I managed to create a system to run unit tests
under gdb as part of the Debian build, but it's disabled by default
because it caused problems in armhf.
You could also uncomment it (see lines [3] of debian/rules) to see if
we can get more useful info about potential failures...
Just replace

MRPT_TEST_TARGET = test

with:

MRPT_TEST_TARGET = test_gdb


Thanks for your support!!

[1] https://github.com/MRPT/mrpt/commit/e791599a30a0b60b551ee3e31225609b1a798a39
[2] https://github.com/MRPT/mrpt
[3] 
https://github.com/MRPT/mrpt/blob/b346bbbadbcf0f582c078c9e975f0ad4e0125565/packaging/debian/rules#L23

On Mon, Jul 4, 2016 at 12:13 PM, Gianfranco Costamagna
<locutusofb...@debian.org> wrote:
> Hi,
>
>
>>lease, find the workaround (not solution!) commit in [1]. Please, if
>
>>possible, apply it directly over the current v1.4.0 Debian package to
>>unblock building in big endian platforms. It would be great if you
>>could sponsor the update in Debian, not only in Ubuntu.
>>
>>If I find spare time to work in a real solution, I'll contact you just
>>in case you could help me testing the patches in porter machines...
>
>
> I can sponsor whatever you give me, a dsc, a tarball of debian packaging 
> directory,
> whatever (a git snapshot)
>
>
> Right now, I applied the two commits as patches, and the fix for 
> breaks+replaces
> fields, and I uploaded it in Ubuntu (to check if everything is correct)
>
> I called it ~build2 [1], so on the Debian upload it will be overridden 
> automatically
> by the auto import robot
>
>
> here [2]
>
> [1] https://launchpad.net/ubuntu/+source/mrpt/1:1.4.0-1build2
>
> [2] 
> http://launchpadlibrarian.net/270793330/mrpt_1%3A1.4.0-1build1_1%3A1.4.0-1build2.diff.gz
>
> I'm looking the build logs, if you can give me a dsc file I'll sponsor it in 
> a matter of minutes.
>
> If you don't change the version, just send me a tarball of the debian 
> directory, it should be enough for me!
>
> thanks for "fixing" :)
>
> Gianfranco



-- 
___

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

Hi,

Please, find the workaround (not solution!) commit in [1]. Please, if
possible, apply it directly over the current v1.4.0 Debian package to
unblock building in big endian platforms. It would be great if you
could sponsor the update in Debian, not only in Ubuntu.

If I find spare time to work in a real solution, I'll contact you just
in case you could help me testing the patches in porter machines...

Thanks for the support!

[1] https://github.com/MRPT/mrpt/commit/b247f14ffdaf8f31ec8cafefcc2a12ac1d210618

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

Hi Gianfranco ,

Sorry for the delay, but it's difficult for me to debug those tests
because I can't run the tests in any local / remote machine...

A few days after this bug report, I applied to become a DM (via my
sponsor) in part as a way to be able to run these tests in Debian
infraestructure.
Do you know of another way to quickly do tests on those big-endian platforms?

As an alternative, I can submit a patch to just skip those tests in
big-endian platforms and leave this for future fix and in the
meanwhile unblock the transition in Ubuntu.

JL


On Fri, Jul 1, 2016 at 12:07 PM, Gianfranco Costamagna
 wrote:
> Hi Jose, do you have any ETA for this issue?
>
> this is preventing the opencv decruft, and the transition in Ubuntu.
>
> thanks
>
> Gianfranco
>

Bug#807662: mrpt-common: fails to upgrade from 'jessie' - trying to overwrite /usr/share/mrpt/config_files/simul-beacons/example_simul-beacons.ini

[Jose Luis Blanco]

Thanks! Fixed upstream.


On Thu, Jun 2, 2016 at 2:15 AM, Andreas Beckmann <a...@debian.org> wrote:
> Followup-For: Bug #807662
> Control: found -1 1:1.4.0-1
>
> Hi,
>
> the Breaks+Replaces recently added are missing the epoch and are
> therefore ineffective.
>
>
> Andreas



-- 
_______

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#825844: mrpt: FTBFS on armhf: parse_NMEA_ZDA bus error

[Jose Luis Blanco]

>> I noticed it and it took me 2 days of research until I found the
>> problem to be inside a gtest template. A possible solution is now
>> committed upstream [1],
>
> Great, thanks!

Confirmed, it's fixed now upstream. Will mark it as done in the next release.

>> I'm waiting for build farms in Ubuntu PPA to
>> test if the patch works... It would be great to know of some easy way
>> of doing the test directly on Debian, but I'm unaware of any!
>
> You can request guest access to porterboxes:
> https://dsa.debian.org/doc/guest-account/

Thanks for the pointer Aaron, will try it...

Cheers,
JL

-- 
_______

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#825844: mrpt: FTBFS on armhf: parse_NMEA_ZDA bus error

[Jose Luis Blanco]

Thanks Aaron!

I noticed it and it took me 2 days of research until I found the
problem to be inside a gtest template. A possible solution is now
committed upstream [1], I'm waiting for build farms in Ubuntu PPA to
test if the patch works... It would be great to know of some easy way
of doing the test directly on Debian, but I'm unaware of any!


Best,

[1] https://github.com/MRPT/mrpt/commit/70c9d5a5ebd01bce09537249bbc2acf4d15f038c


On Mon, May 30, 2016 at 7:46 PM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
> Source: mrpt
> Version: 1:1.4.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The mrpt build for armhf has started failing:
>
>   [ RUN  ] CGPSInterface.parse_NMEA_ZDA
>   Bus error
>   tests/CMakeFiles/run_tests_mrpt_hwdrivers.dir/build.make:60: recipe for 
> target 'tests/CMakeFiles/run_tests_mrpt_hwdrivers' failed
>
> Could you please take a look?
>
> Thanks!



-- 
_______

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#821818: mrpt-apps: uses ${binary:Version} in dependency on arch:all mrpt-common

[Jose Luis Blanco]

Ok, thanks anyway! :-)

I've marked this bug as done in debian/changelog for the next release.

> Exactly!
>
> Andreas
>

Bug#821818: mrpt-apps: uses ${binary:Version} in dependency on arch:all mrpt-common

[Jose Luis Blanco]

Thanks Andreas!

I think this is already fixed upstream, please check line 391 in this
file: https://github.com/MRPT/mrpt/blob/master/packaging/debian/control.in#L391


Package: mrpt-apps
Architecture: any
Depends: mrpt-common (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends}


Is that what you meant, right?

Cheers,
JL

Bug#803700: mrpt: FTBFS: 7 FAILED TESTS

[Jose Luis Blanco]

Thanks Andreas.

For the records: This was caused by the use of the latest alpha
version of Eigen 3.3, as explained in this bug report:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1066#c3

It is already fixed upstream in MRPT. We will release a new version
soon to close this bug.

JL


On Sun, Nov 1, 2015 at 10:05 PM, Andreas Cadhalpun
<andreas.cadhal...@googlemail.com> wrote:
> Source: mrpt
> Version: 1.3.0-1.1
> Severity: serious
>
> Dear Maintainer,
>
> mrpt currently fails to build due to test failures:
>
> [==] 139 tests from 24 test cases ran. (8760 ms total)
> [  PASSED  ] 132 tests.
> [  FAILED  ] 7 tests, listed below:
> [  FAILED  ] Pose3DQuatPDFGaussTests.CompositionJacobian
> [  FAILED  ] Pose3DQuatPDFGaussTests.Composition
> [  FAILED  ] Pose3DQuatPDFGaussTests.InverseComposition
> [  FAILED  ] Pose3DQuatPDFGaussTests.ChangeCoordsRef
> [  FAILED  ] Pose3DPDFGaussTests.CompositionJacobian
> [  FAILED  ] Pose3DPDFGaussTests.AllOperators
> [  FAILED  ] Pose3DPDFGaussTests.ChangeCoordsRef
>
>  7 FAILED TESTS
>
> A full build log is available from the reproducibility rebuild [1].
>
> Best regards,
> Andreas
>
>
> 1: https://reproducible.debian.net/rb-pkg/unstable/amd64/mrpt.html



-- 
___

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#765314: mrpt: FTBFS on all non-x86-based architectures

[Jose Luis Blanco]

Dear Olly,

I think that all problematic old mrpt packages are now removed after
the FTP removal request:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765962

Shall we re-upload a new patched version of MRPT for the system to
re-try to get it into testing?
Or it should go on automatically? (1.2.2-1.1 packages for 'standard'
architectures are still there...)

Best, and thanks for the help.

JL


On Thu, Oct 16, 2014 at 4:02 AM, Olly Betts o...@survex.com wrote:
 On Wed, Oct 15, 2014 at 01:40:43PM +0200, Jose Luis Blanco wrote:
 I would add a third patch to fix (avoid) errors in hurd. If you have
 the possibility of adding it it would be great!

 So, these are the 3 patches:
 https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f
 https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19
 https://github.com/jlblancoc/mrpt/commit/c81effd1228234e2ed17caf0ef22f0caee6b

 Can be downloaded as git diffs as well:

 https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f.diff
 https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19.diff
 https://github.com/jlblancoc/mrpt/commit/c81effd1228234e2ed17caf0ef22f0caee6b.diff

 I don't mind making another NMU, but since mrpt takes an hour to build,
 I'd prefer to try to fix all the architectures at once, and mipsel has
 also failed to build with an internal compiler error:

 https://buildd.debian.org/status/fetch.php?pkg=mrptarch=mipselver=1%3A1.2.2-1.1stamp=1413406454

  On Wed, Oct 15, 2014 at 7:31 AM, Jose Luis Blanco
  joseluisblan...@gmail.com wrote:
  Any recommendation about how to test it locally on s390x? qemu or alike?

 I've not tried qemu myself - I'd guess it's likely to take quite a while
 to build under qemu though.

 You can request guest access to the debian porter boxes:

 https://dsa.debian.org/doc/guest-account/

 Not sure if you're a DM or in NM, but if not you'll need to get a DD to
 sponsor the request.  It's probably most appropriate to get your usual
 upload sponsor to send in the request, but I guess I can if he/she isn't
 available.

  A partner got it tested in a physical mips device before submitting,
  so hopefully it will work there...

 It's not yet tried to build there yet.

 Cheers,
 Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756104: binary removal mrpt

[Jose Luis Blanco]

Thank you very much!! I am on a 48h trip with only mobile access, I will
check it out asap.


On Friday, October 17, 2014, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:

 Hi Jose,

 In order to get them removed you have to open a bug against ftp.debian.org

 Feel free to copy the significant bit from this bug report

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764859


 cheers,

 Gianfranco



-- 
___

Dr. Jose-Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#756104: mrpt: FTBFS on mips, mipsel, powerpc, s390x

[Jose Luis Blanco]

Thanks for the pointer. To what list should I head to ask for such removal?

JL


On Thu, Oct 16, 2014 at 8:04 PM, Ralf Treinen trei...@free.fr wrote:
 Hello,

 I am sorry, but even when it now compiles on powerpc, it still fails to
 compile on mipsel, s390x, sparc, as well as on hurd-i386 and the new
 ppc64el (status unknown for mips). [1]

 In view of that fact that we are 3 weeks from freeze you might want to
 consider asking for removal of the binary packages on release architectures
 where mrpt used to compile before.

 -Ralf.

 [1] https://buildd.debian.org/status/package.php?p=mrptsuite=unstable


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765314: mrpt: FTBFS on all non-x86-based architectures

[Jose Luis Blanco]

Hi Olly,

In theory, these patches should fix sparc  (I think) s390x:

- 
https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f
-https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19

But couldn't test it locally. Would you please try to attach them as
patches for a new version 1.2.2-1.2??

Best,
JL


On Wed, Oct 15, 2014 at 7:31 AM, Jose Luis Blanco
joseluisblan...@gmail.com wrote:
 Any recommendation about how to test it locally on s390x? qemu or alike?

 A partner got it tested in a physical mips device before submitting,
 so hopefully it will work there...

 Thanks.


 On Wed, Oct 15, 2014 at 7:00 AM, Olly Betts o...@survex.com wrote:
 Still not building everywhere:

 https://buildd.debian.org/status/package.php?p=mrpt

 It's never built on ppc64el, so that won't block testing migration (but
 it would be good to sort out).

 The failure on sparc isn't a big problem, as sparc isn't a release arch
 for jessie.

 And armel, mips, and mipsel are yet to attempt a build of this version.

 But the failure on s390x needs sorting out if mrpt is to make jessie -
 failure is in the testsuite:

 [ RUN  ] Synch.CriticalSections_Multi
 *** stack smashing detected ***: ./test_mrpt_base terminated

 For backtrace, etc see the tail end of:

 https://buildd.debian.org/status/fetch.php?pkg=mrptarch=s390xver=1%3A1.2.2-1.1stamp=1413289418

 Cheers,
 Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765314: mrpt: FTBFS on all non-x86-based architectures

[Jose Luis Blanco]

I would add a third patch to fix (avoid) errors in hurd. If you have
the possibility of adding it it would be great!

So, these are the 3 patches:
https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f
https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19
https://github.com/jlblancoc/mrpt/commit/c81effd1228234e2ed17caf0ef22f0caee6b

Can be downloaded as git diffs as well:

https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f.diff
https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19.diff
https://github.com/jlblancoc/mrpt/commit/c81effd1228234e2ed17caf0ef22f0caee6b.diff

Best,
JL


On Wed, Oct 15, 2014 at 9:14 AM, Jose Luis Blanco
joseluisblan...@gmail.com wrote:
 Hi Olly,

 In theory, these patches should fix sparc  (I think) s390x:

 - 
 https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f
 -https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19

 But couldn't test it locally. Would you please try to attach them as
 patches for a new version 1.2.2-1.2??

 Best,
 JL


 On Wed, Oct 15, 2014 at 7:31 AM, Jose Luis Blanco
 joseluisblan...@gmail.com wrote:
 Any recommendation about how to test it locally on s390x? qemu or alike?

 A partner got it tested in a physical mips device before submitting,
 so hopefully it will work there...

 Thanks.


 On Wed, Oct 15, 2014 at 7:00 AM, Olly Betts o...@survex.com wrote:
 Still not building everywhere:

 https://buildd.debian.org/status/package.php?p=mrpt

 It's never built on ppc64el, so that won't block testing migration (but
 it would be good to sort out).

 The failure on sparc isn't a big problem, as sparc isn't a release arch
 for jessie.

 And armel, mips, and mipsel are yet to attempt a build of this version.

 But the failure on s390x needs sorting out if mrpt is to make jessie -
 failure is in the testsuite:

 [ RUN  ] Synch.CriticalSections_Multi
 *** stack smashing detected ***: ./test_mrpt_base terminated

 For backtrace, etc see the tail end of:

 https://buildd.debian.org/status/fetch.php?pkg=mrptarch=s390xver=1%3A1.2.2-1.1stamp=1413289418

 Cheers,
 Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765314: mrpt: FTBFS on all non-x86-based architectures

[Jose Luis Blanco]

Yes please, and thanks for the patch!
I noticed it yesterday and fixed upstream [1], but didn't know how to
propagate this quickly to Debian.

Thanks.
JL

[1] 
https://github.com/jlblancoc/mrpt/commit/f095bba6c4337de8c3d113b08558ae09ebbf0a53



On Tue, Oct 14, 2014 at 4:29 AM, Olly Betts o...@survex.com wrote:
 Package: mrpt
 Version: 1:1.2.2-1
 Severity: serious
 Justification: FTBFS
 Tags: patch sid jessie
 User: freewx-ma...@lists.alioth.debian.org
 Usertags: wx3.0

 Dear maintainer,

 The latest upload of mrpt fails to build on all non-x86-based
 architectures, due to passing SSE4-related compiler options.

 It also presumably compiles to code using SSE4 instructions on x86-based
 architectures, which means it won't work on older x86 processors which
 Debian aims to support.

 I've attached a patch which fixes debian/rules to pass the correct
 options to the upstream build system (which seem to have changed between
 1.2.1 and 1.2.2).  I've test built this on x86_64 and verified from the
 build log that the SSE4-related options get set correctly.

 If you'd like me to NMU this fix, just let me know.

 Cheers,
 Olly



-- 
___

Dr. Jose-Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765314: mrpt: FTBFS on all non-x86-based architectures

[Jose Luis Blanco]

Any recommendation about how to test it locally on s390x? qemu or alike?

A partner got it tested in a physical mips device before submitting,
so hopefully it will work there...

Thanks.


On Wed, Oct 15, 2014 at 7:00 AM, Olly Betts o...@survex.com wrote:
 Still not building everywhere:

 https://buildd.debian.org/status/package.php?p=mrpt

 It's never built on ppc64el, so that won't block testing migration (but
 it would be good to sort out).

 The failure on sparc isn't a big problem, as sparc isn't a release arch
 for jessie.

 And armel, mips, and mipsel are yet to attempt a build of this version.

 But the failure on s390x needs sorting out if mrpt is to make jessie -
 failure is in the testsuite:

 [ RUN  ] Synch.CriticalSections_Multi
 *** stack smashing detected ***: ./test_mrpt_base terminated

 For backtrace, etc see the tail end of:

 https://buildd.debian.org/status/fetch.php?pkg=mrptarch=s390xver=1%3A1.2.2-1.1stamp=1413289418

 Cheers,
 Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

Great news!

Sure. I'm preparing it, after some checking will submit it.

Thanks.
JL


On Fri, Sep 12, 2014 at 10:17 AM, Jurica Stanojkovic
jurica.stanojko...@imgtec.com wrote:
 Hi Jose Luis,

 I can confirm that the head of git (from Sep, 10, 2014) has been built 
 successfully on mips and mipsel.
 All tests executed successfully.
 Please note that changes from Sep 11 and 12 have not been included in this 
 and that I have set BUILD_ASSIMP=OFF for mips and mipsel.

 Could you please prepare new version of mrpt package for Debian?

 Thank you!
 Jurica
 
 From: Jose Luis Blanco [joseluisblan...@gmail.com]
 Sent: 09 September 2014 02:18
 To: Jurica Stanojkovic
 Cc: 758...@bugs.debian.org
 Subject: Re: Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

 Thanks for the investigation!

 Following that line, I think I have solved all de-serialization
 problems in GIT head: https://github.com/jlblancoc/mrpt/commits/master
 The two relevant patches are:
 1) 
 https://github.com/jlblancoc/mrpt/commit/7b1536c7f43ddc9cc949407f71fde0c8db0ecf5b
 2) 
 https://github.com/jlblancoc/mrpt/commit/d7fe726eb896b1a9d453e3b2d53252b25dbc3918

 Let me know if this finally solves the issue.

 JL



-- 
___

Dr. Jose-Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

Thanks for the investigation!

Following that line, I think I have solved all de-serialization
problems in GIT head: https://github.com/jlblancoc/mrpt/commits/master
The two relevant patches are:
1) 
https://github.com/jlblancoc/mrpt/commit/7b1536c7f43ddc9cc949407f71fde0c8db0ecf5b
2) 
https://github.com/jlblancoc/mrpt/commit/d7fe726eb896b1a9d453e3b2d53252b25dbc3918

Let me know if this finally solves the issue.

JL


On Mon, Sep 8, 2014 at 5:26 PM, Jurica Stanojkovic
jurica.stanojko...@imgtec.com wrote:
 Hello Jose Luis,

 On big endian. while executing MonteCarlo2D.RunSampleDataset test first 
 problem is found here:
 https://github.com/jlblancoc/mrpt/blob/master/libs/base/src/utils/CStream.cpp
 After the line 405 version_old have value that is in wrong endian format 
 (little endian).

 Second problem is here:
 https://github.com/jlblancoc/mrpt/blob/master/libs/maps/src/maps/COccupancyGridMap2D_insert.cpp
 After the line 168 curRange have value that is in wrong endian format (little 
 endian).

 For now I have used mrpt::utils::reverseBytesInPlace( ) to fix wrong endian 
 values and I am trying to investigate problem further.

 Afrer resolving those problems  MonteCarlo2D.RunSampleDataset test fail with 
 message:
 *Warning: Test failed. Will give it another chance, since after all it's 
 nondeterministic!

 Can you please look and comment at these issues?

 Thank you!
 Jurica


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

Thank you very much!!


On Wed, Aug 27, 2014 at 1:53 PM, Jurica Stanojkovic
jurica.stanojko...@imgtec.com wrote:
 Hello,

 I can confirm that the current head of git (taken on monday) has been built 
 successfully on mips as well.
 All tests executed without an error.
 TEST(ReactiveNavTests, LoadNavLogFile) and TEST(MonteCarlo2D, 
 RunSampleDataset) were skipped on big endian.
 Also TEST(Synch, CSemaphore_named ) has returned the mesage:
 *Skipping test* It seems the kernel doesn't support named semaphores in this 
 platform.

 Regards,
 Jurica


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

 With these changes I was able to build package on mips*

Good! Just for curiosity: are all other unit tests passing? Because
that means that de-serialization is actually working (it's used in
other tests, like in ReactiveNavTests.LoadNavLogFile).

I have finally solved the pragma pack problem properly, with these 2
additional commits:
4) 
https://github.com/jlblancoc/mrpt/commit/cd4878874b930e151deb6d89577c215c687b80b3
5) 
https://github.com/jlblancoc/mrpt/commit/b52d65b5a0bcc552e7a7c6d420f30be623d8fd38

It would be great if you could confirm that the current head of git
master is building correctly in mips...
I guess it may take a long time to build in mips, so thank you very
much for your tests!!

Cheers,
JL


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

So, the #ifdef workaround was incorrectly placed, to start with!

This patch will solve it:
https://github.com/jlblancoc/mrpt/commit/c06ed1c384ba2e719c52f65a1a49bddcf7d261e5

But obviously, that's not the ideal solution because that's resigning
trying to fix de-serialization problems!

I didn't know that issue about #pragma pack, it will be a problem.
Let me check it more in depth, but I'm sure the struct pack'ing is
taken for granted in some parts of the code. Actually, there's even
one unit test checking it...

Please, let me know whatever other unit tests don't pass in MIPS while
I think what to do with the pragmas.

BTW: Is there any macro to detect architectures with strict alignment rules?

JL


On Thu, Aug 21, 2014 at 5:10 PM, Jurica Stanojkovic
jurica.stanojko...@imgtec.com wrote:
 Hi Jose Luis,

 Thank you for the quick response!

 I can confirm that patches that you have proposed have resolved build issue 
 on i386.

 I am working on resolving build issues for mips and mipsel.

 On mips and mipsel I have looked into
 https://github.com/jlblancoc/mrpt/blob/master/libs/slam/src/slam/CMonteCarloLocalization2D_unittest.cpp

 function void run_test_pf_localization(CPose2D meanPose, CMatrixDouble33 
 cov) on big endian is not doing anything,
 but run_test_pf_localization is used in TEST(MonteCarlo2D, RunSampleDataset).

 #if MRPT_IS_BIG_ENDIAN
 MRPT_TODO(Debug this issue in big endian platforms)
 return; // Skip this test for now
 #endif

 That is causing the following error:
 https://buildd.debian.org/status/fetch.php?pkg=mrptarch=mipsver=1%3A1.2.1-1stamp=1406312477

 I will look further into function run_test_pf_localization.

 There is also .h file:
 https://github.com/jlblancoc/mrpt/blob/master/libs/base/include/mrpt/math/lightweight_geom_data.h

 containing #pragma pack(push,1) directive for structures that have float 
 and double arguments.

 I think that this is causing unaligned access on architectures with strict 
 alignment rules:
 https://buildd.debian.org/status/fetch.php?pkg=mrptarch=mipselver=1%3A1.2.1-1stamp=1406169915

 For mips* architecture double should be 8 byte aligned and float should be 4 
 byte aligned.

 Can we disable #pragma pack(push,1) in this file for architectures with 
 strict alignment rules?

 Any comments are welcome.

 Thanks!
 Jurica



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

Thanks a lot for your interest in fixing this, Jurica!
I'm the upstream maintainer of mrpt, and was becoming desperate trying
to debug in mips* for my lack of experience in cross-buidling, qemu,
etc.

So, on the build errors in mips (and other big-endian platforms): I
*suspect* that some errors may be caused by missing byte-reordering in
serialization, via mrpt::utils::CStream and/or the affected classes
methods named readFromStream() and writeToStream(), so that's where
you could first look at while debugging in mips*. At least, that's
what I suspect, but couldn't check it because can't debug in those
platforms! :-(

About the other errors in this present bug: Yes, I'll study them.
In the meanwhile, you can avoid them by, instead of running make
test, running:

 tests/test_mrpt_base --gtest_filter=-*CSemaphore*

to run all tests in the lib mrpt-base, excepting those that give you problems.
For the other test sets, you can also try, for example:

make run_tests_mrpt_opengl

and so on. Hit TAB after make run_tests_mrpt_ to see the full list.

Hope it helps!

JL

On Wed, Aug 20, 2014 at 6:12 PM, Jurica Stanojkovic
jurica.stanojko...@imgtec.com wrote:
 Package: mrpt
 Version: 1:1.2.1-1
 Severity: serious
 Tags: sid
 Justification: FTBFS
 User: debian-mips-dev-disc...@lists.alioth.debian.org

 Hello,

 package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips* with the following
 message, but was previously built successfully on i386, amd64:

 i386 log:

 [--] 5 tests from Synch
 [ RUN  ] Synch.CSemaphore_named_6t_1init
 Exception in [auxiliary_thread_launcher_LIN/WIN]!!!:


  === MRPT EXCEPTION =
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 81:
 Creating semaphore (name='mrpt-demo-sem1') raised error: Function not
 implemented
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 87:
 /«PKGBUILDDIR»/libs/base/src/synch/CCriticalSection_unittest.cpp:53: Failure
 Value of: false
   Actual: false
 Expected: true
 Thread didn't finished in timeout! While testing: CSemaphore named:
 #threads=6, init count=1
 [  FAILED  ] Synch.CSemaphore_named_6t_1init (5000 ms)
 [ RUN  ] Synch.CSemaphore_named_10t_5init
 Exception in [auxiliary_thread_launcher_LIN/WIN]!!!:


  === MRPT EXCEPTION =
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 81:
 Creating semaphore (name='mrpt-demo-sem1') raised error: Function not
 implemented
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 87:
 /«PKGBUILDDIR»/libs/base/src/synch/CCriticalSection_unittest.cpp:53: Failure
 Value of: false
   Actual: false
 Expected: true
 Thread didn't finished in timeout! While testing: CSemaphore named:
 #threads=10, init count=5
 [  FAILED  ] Synch.CSemaphore_named_10t_5init (5000 ms)
 [ RUN  ] Synch.CriticalSections_Simple
 [   OK ] Synch.CriticalSections_Simple (1 ms)
 [ RUN  ] Synch.CriticalSections_NoDoubleEnter
 [   OK ] Synch.CriticalSections_NoDoubleEnter (1 ms)
 [ RUN  ] Synch.CriticalSections_Multi
 [   OK ] Synch.CriticalSections_Multi (1557 ms)
 [--] 5 tests from Synch (11560 ms total)

 ...

 [--] Global test environment tear-down
 [==] 138 tests from 23 test cases ran. (11643 ms total)
 [  PASSED  ] 136 tests.
 [  FAILED  ] 2 tests, listed below:
 [  FAILED  ] Synch.CSemaphore_named_6t_1init
 [  FAILED  ] Synch.CSemaphore_named_10t_5init

  2 FAILED TESTS
 make[4]: *** [tests/CMakeFiles/run_tests_mrpt_base] Error 1
 tests/CMakeFiles/run_tests_mrpt_base.dir/build.make:52: recipe for target
 'tests/CMakeFiles/run_tests_mrpt_base' failed
 make[4]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 make[3]: *** [tests/CMakeFiles/run_tests_mrpt_base.dir/all] Error 2
 CMakeFiles/Makefile2:5096: recipe for target
 'tests/CMakeFiles/run_tests_mrpt_base.dir/all' failed
 make[3]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 make[2]: *** [tests/CMakeFiles/test.dir/rule] Error 2
 CMakeFiles/Makefile2:5455: recipe for target
 'tests/CMakeFiles/test.dir/rule' failed
 make[2]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 make[1]: *** [test] Error 2
 Makefile:1665: recipe for target 'test' failed
 make[1]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 dh_auto_test: make -j1 test ARGS+=-j1 returned exit code 2
 make: *** [build-arch] Error 2
 debian/rules:44: recipe for target 'build-arch' failed
 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


 Could someone please help with this regression?

 I am working on resolving other build issues for mrpt package build on mips
 and mipsel, but I can not resolve them until this regression gets resolved.

 Thanks!
 Jurica



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*

[Jose Luis Blanco]

Hi Jurica,

Please, hopefully these two patches can solve all named semaphore errors:

1) 
https://github.com/jlblancoc/mrpt/commit/9a878c0950edd8ca7de6f4584f920c4e0db05ecc
2) 
https://github.com/jlblancoc/mrpt/commit/289498fc34703c2fcf6b61e72c3311144e5fb570

Cheers,
JL


On Wed, Aug 20, 2014 at 7:40 PM, Jose Luis Blanco
joseluisblan...@gmail.com wrote:
 Thanks a lot for your interest in fixing this, Jurica!
 I'm the upstream maintainer of mrpt, and was becoming desperate trying
 to debug in mips* for my lack of experience in cross-buidling, qemu,
 etc.

 So, on the build errors in mips (and other big-endian platforms): I
 *suspect* that some errors may be caused by missing byte-reordering in
 serialization, via mrpt::utils::CStream and/or the affected classes
 methods named readFromStream() and writeToStream(), so that's where
 you could first look at while debugging in mips*. At least, that's
 what I suspect, but couldn't check it because can't debug in those
 platforms! :-(

 About the other errors in this present bug: Yes, I'll study them.
 In the meanwhile, you can avoid them by, instead of running make
 test, running:

  tests/test_mrpt_base --gtest_filter=-*CSemaphore*

 to run all tests in the lib mrpt-base, excepting those that give you problems.
 For the other test sets, you can also try, for example:

 make run_tests_mrpt_opengl

 and so on. Hit TAB after make run_tests_mrpt_ to see the full list.

 Hope it helps!

 JL

 On Wed, Aug 20, 2014 at 6:12 PM, Jurica Stanojkovic
 jurica.stanojko...@imgtec.com wrote:
 Package: mrpt
 Version: 1:1.2.1-1
 Severity: serious
 Tags: sid
 Justification: FTBFS
 User: debian-mips-dev-disc...@lists.alioth.debian.org

 Hello,

 package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips* with the following
 message, but was previously built successfully on i386, amd64:

 i386 log:

 [--] 5 tests from Synch
 [ RUN  ] Synch.CSemaphore_named_6t_1init
 Exception in [auxiliary_thread_launcher_LIN/WIN]!!!:


  === MRPT EXCEPTION =
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 81:
 Creating semaphore (name='mrpt-demo-sem1') raised error: Function not
 implemented
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 87:
 /«PKGBUILDDIR»/libs/base/src/synch/CCriticalSection_unittest.cpp:53: Failure
 Value of: false
   Actual: false
 Expected: true
 Thread didn't finished in timeout! While testing: CSemaphore named:
 #threads=6, init count=1
 [  FAILED  ] Synch.CSemaphore_named_6t_1init (5000 ms)
 [ RUN  ] Synch.CSemaphore_named_10t_5init
 Exception in [auxiliary_thread_launcher_LIN/WIN]!!!:


  === MRPT EXCEPTION =
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 81:
 Creating semaphore (name='mrpt-demo-sem1') raised error: Function not
 implemented
 mrpt::synch::CSemaphore::CSemaphore(unsigned int, unsigned int, const
 string), line 87:
 /«PKGBUILDDIR»/libs/base/src/synch/CCriticalSection_unittest.cpp:53: Failure
 Value of: false
   Actual: false
 Expected: true
 Thread didn't finished in timeout! While testing: CSemaphore named:
 #threads=10, init count=5
 [  FAILED  ] Synch.CSemaphore_named_10t_5init (5000 ms)
 [ RUN  ] Synch.CriticalSections_Simple
 [   OK ] Synch.CriticalSections_Simple (1 ms)
 [ RUN  ] Synch.CriticalSections_NoDoubleEnter
 [   OK ] Synch.CriticalSections_NoDoubleEnter (1 ms)
 [ RUN  ] Synch.CriticalSections_Multi
 [   OK ] Synch.CriticalSections_Multi (1557 ms)
 [--] 5 tests from Synch (11560 ms total)

 ...

 [--] Global test environment tear-down
 [==] 138 tests from 23 test cases ran. (11643 ms total)
 [  PASSED  ] 136 tests.
 [  FAILED  ] 2 tests, listed below:
 [  FAILED  ] Synch.CSemaphore_named_6t_1init
 [  FAILED  ] Synch.CSemaphore_named_10t_5init

  2 FAILED TESTS
 make[4]: *** [tests/CMakeFiles/run_tests_mrpt_base] Error 1
 tests/CMakeFiles/run_tests_mrpt_base.dir/build.make:52: recipe for target
 'tests/CMakeFiles/run_tests_mrpt_base' failed
 make[4]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 make[3]: *** [tests/CMakeFiles/run_tests_mrpt_base.dir/all] Error 2
 CMakeFiles/Makefile2:5096: recipe for target
 'tests/CMakeFiles/run_tests_mrpt_base.dir/all' failed
 make[3]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 make[2]: *** [tests/CMakeFiles/test.dir/rule] Error 2
 CMakeFiles/Makefile2:5455: recipe for target
 'tests/CMakeFiles/test.dir/rule' failed
 make[2]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 make[1]: *** [test] Error 2
 Makefile:1665: recipe for target 'test' failed
 make[1]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
 dh_auto_test: make -j1 test ARGS+=-j1 returned exit code 2
 make: *** [build-arch] Error 2
 debian/rules:44: recipe for target 'build-arch' failed
 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


 Could someone please help

Bug#755478: libmrpt-base1.0: not installable in sid, needs migration to libavcodec55

[Jose Luis Blanco]

Hi and thanks for noticing,

A newer version of the package (1.2.1) was uploaded recently to Debian
mentors [1] which hopefully fixes all build errors in those archs.
I already let my mentor (José Luis Redejo, jredr...@debian.org) know
about it, so I expect the new package to be uploaded soon.

Best,
JL

[1] http://mentors.debian.net/package/mrpt

On Mon, Jul 21, 2014 at 11:02 AM, Ralf Treinen
trei...@pps.univ-paris-diderot.fr wrote:

 Package: libmrpt-base1.0
 Version: 1:1.0.2-1
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-uninstallable

 Hello,

 libmrpt-base1.0 is not installable in sid on any of the architecture where
 it exsists. This is the case since at least 2014-04-05:

 Architectures: mipsel
 Version: 1:1.0.0-1
 No package matches the dependency libavcodec53 (= 6:0.8.3-1~) | 
 libavcodec-extra-53 (= 6:0.8.5) of package libmrpt-base1.0 (=1:1.0.0-1)

 Architectures: powerpc, s390x
 Version: 1:1.0.2-1
 No package matches the dependency libavcodec54 (= 6:9.1-1) | 
 libavcodec-extra-54 (= 6:9.8) of package libmrpt-base1.0 (=1:1.0.2-1)

 Architectures: mips
 Version: 1:1.0.1-1
 No package matches the dependency libavcodec53 (= 6:0.8.3-1~) | 
 libavcodec-extra-53 (= 6:0.8.7) of package libmrpt-base1.0 (=1:1.0.1-1)

 This package should migrate to libavcodec55.

 Cheers -Ralf.


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753390: non-free stuff in source package

[Jose Luis Blanco]

I think this commit upstream should fix the bug:
https://github.com/jlblancoc/mrpt/commit/7bb216e1e0c421ea4525948aa1da95e6e640f562

License of two Latex docs has been ported to CC BY-SA 4.0, which is
reportedly compatible with Debian policies.

I'll mark this bug as solved in the next release, unless more problems
are reported.

Cheers,
JL


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753390: non-free stuff in source package

[Jose Luis Blanco]

Hello Thorsten,

Thanks for the pointer!

However, I'm unsure about how to proceed: the content under
CC-BY-NC-ND you mean are probably two guides written in Latex. Unless
it's really unsuitable to Debian policies, I would like to keep them
there so they are built and stored in the mrpt-doc package as .ps
docs.

Other contents in this directory are:
- Man pages as .pod files (-- which end up in the mrpt-apps package)
- Doxygen pages (-- also go to the mrpt-doc package)
- Some code examples.

Since I'm also the author upstream, I can update the debian/copyright
and/or the license of the two guides in Latex. Let me know what would
be the preferred changes so all contents in the Debian package
mrpt-doc can be maintained there and I can flag this bug as done.

Cheers,
JL


On Tue, Jul 1, 2014 at 1:40 PM, Thorsten Alteholz alteh...@debian.org wrote:
 Package: mrpt
 Version: 1:1.2.0-1
 Severity: serious
 User: alteh...@debian.org
 Usertags: ftp
 X-Debbugs-CC: ftpmas...@ftp-master.debian.org
 thanks

 Dear Maintainer,

 please remove the doc directory from the source package. Most of the stuff
 is either licensed under CC-BY-NC-ND or some other license that makes it
 unfit for main.

 In this context you might want to review your debian/copyright.

 Thanks!
   Thorsten


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724466: mrpt: FTBFS: libdc1394 error: Failed to initialize libdc1394, followed by a SIGSEGV

[Jose Luis Blanco]

Hi Olly, and thanks for following up.

Actually the error from libdc1394 is, I'm almost 100% sure, not
related to the crash: that error message comes from initialization
code in OpenCV (libopencv-dev), which MRPT links against, and during
some range of versions it was always shown at start-up and was
annoying, but not critical.

About the urandom error: I have no clue...

I'm trying to catch up with this package, so will try to reproduce the
error, and if I feel swamped would consider orphan it.

Best,
JL


On Mon, Jun 9, 2014 at 6:29 AM, Olly Betts o...@survex.com wrote:
 Jose - this RC bug has now been open for 8.5 months without any comment
 from the maintainer.  Are you still interested in maintaining mrpt in
 Debian?  If not, it would be better to orphan the package so that others
 who are interested in maintaining it can more easily take over.

 On Tue, Sep 24, 2013 at 07:46:12AM +0300, Damyan Ivanov wrote:
 mrpt seems to fail to build in a clean current sid pbuilder chroot:

 [100%] Generating performance HTML pages
 /tmp/buildd/mrpt-1.0.2/bin/mrpt-perfdata2html 
 /tmp/buildd/mrpt-1.0.2/doc/perf-data/
 libdc1394 error: Failed to initialize libdc1394
 *FATAL*: Signal SIGSEGV caught!
 make[4]: *** [doc/CMakeFiles/documentation_performance_html] Aborted

 Using sbuild, I also get a FTBFS, but with a different error - perhaps
 this helps:

 | [100%] Generating performance HTML pages
 | /«PKGBUILDDIR»/bin/mrpt-perfdata2html /«PKGBUILDDIR»/doc/perf-data/
 | Fatal: can't open /dev/urandom: Bad address
 | make[4]: *** [doc/CMakeFiles/documentation_performance_html] Aborted

 There's been a new upstream release of libdc1394-22 packaged since dam's
 report, so perhaps the different message is due to that rather than
 sbuild vs pbuilder:

 http://metadata.ftp-master.debian.org/changelogs//main/libd/libdc1394-22/libdc1394-22_2.2.2-1_changelog

 Cheers,
 Olly


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624950: New entry to Debian bug: libcv-dev: error: 'ptrdiff_t' does not name a type

[Jose Luis Blanco]

I confirm this bug and that it's serious since it prevents other
packages to build in SID with the newest g++ 4.6.

However, it can be very easily fixed by patching one single line, as
shown in the attached patch (also copied below):

=
diff -w -rupN OpenCV-2.1.0//include/opencv/cxcore.hpp
opencv-2.1.0//include/opencv/cxcore.hpp
--- OpenCV-2.1.0//include/opencv/cxcore.hpp 2010-04-06 03:24:40.0 
+0200
+++ opencv-2.1.0//include/opencv/cxcore.hpp 2011-05-08 19:56:53.759113108 
+0200
@@ -66,6 +66,7 @@ namespace cv {

 using std::vector;
 using std::string;
+using std::ptrdiff_t;

 templatetypename _Tp class CV_EXPORTS Size_;
 templatetypename _Tp class CV_EXPORTS Point_;


Please, could a maintainer patch this package and issue a new rebuild??

BTW: After fixing this bug OpenCV seems not to completely build due to
a similar bug in the headers of libavcodec, but perhaps they've
already patched it too in SID.

Cheers,
Jose Luis

-- 
___

Dr. Jose-Luis Blanco-Claraco
Dpt. Ing. Civil, Mat. y Fabric - Phone: +34 951 952435
E.T.S.I. Industriales - Despacho 2.037
Universidad de Malaga - Campus Universitario de Teatinos
29071 Malaga, Spain
https://sites.google.com/site/jlblancosite/
___
diff -w -rupN OpenCV-2.1.0//include/opencv/cxcore.hpp opencv-2.1.0//include/opencv/cxcore.hpp
--- OpenCV-2.1.0//include/opencv/cxcore.hpp	2010-04-06 03:24:40.0 +0200
+++ opencv-2.1.0//include/opencv/cxcore.hpp	2011-05-08 19:56:53.759113108 +0200
@@ -66,6 +66,7 @@ namespace cv {
 
 using std::vector;
 using std::string;
+using std::ptrdiff_t;
 
 templatetypename _Tp class CV_EXPORTS Size_;
 templatetypename _Tp class CV_EXPORTS Point_;

Bug#617537: src:mrpt: FTBFS, uses silly amounts of memory

[Jose Luis Blanco]

Thanks for filing the bug, Julien!

Hopefully it's already fixed upstream, I'll marked it as closed in the
next release.

The memory problem was due to a recent change to Eigen3, a cool
library for matrices, but it *massively* relies on C++ templates and
leads to this sort of things.
I just split big .cpp files into smaller pieces and observed the
memory consumption was reduced. Let's see...

BTW: Do you know if those build errors are what prevents mrpt-0.9.4 to
move into testing or it is something else?

Cheers,
JL

On Wed, Mar 9, 2011 at 5:46 PM, Julien Cristau jcris...@debian.org wrote:
 Package: src:mrpt
 Version: 1:0.9.4-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)

 building mrpt seems to require insane amounts of memory, leading to
 ftbfs on buildds:
 s390 got OOM(?) killed:
 https://buildd.debian.org/fetch.cgi?pkg=mrptarch=s390ver=1%3A0.9.4-1stamp=1295783490file=logas=raw

 mips went out of virtual memory:
 https://buildd.debian.org/fetch.cgi?pkg=mrptarch=mipsver=1%3A0.9.4-1stamp=1294673927file=logas=raw

 mipsel didn't output anything for so long the buildd timed out:
 https://buildd.debian.org/fetch.cgi?pkg=mrptarch=mipselver=1%3A0.9.4-1stamp=1294547471file=logas=raw

 Cheers,
 Julien





-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#607990: (no subject)

[Jose Luis Blanco]

For the records: this issue was due to the Eigen3 (beta3) library not
building in those architectures. It has been fixed in the embedded
version within MRPT and the corresponding patches sent upstream.

More info in this mailing list thread:
http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2010/12/msg00074.html

Best,
JL




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605996: mrpt: powerpc not fixed, mips broke

[Jose Luis Blanco]

Hi Sebastian,

Thanks for reporting the bug.

Do you (or anyone else) know how can I test if patch fixes the issue
without having to go through an FTP master? Something like launching
test builds?
If that doesn't exist, I'll just try patches in the next -2 version of
the package.

Thanks in advance,

Jose Luis




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#599989: fixed in upstream

[Jose Luis Blanco]

This bug has been fixed upstream, and will be marked in next changelog
as Close: 

If in the meanwhile anyone knows/wants to patch it for Debian, I attach
the patch here.

JL
Index: libs/base/include/mrpt/math/ops_containers.h
===
--- libs/base/include/mrpt/math/ops_containers.h	(revision 2212)
+++ libs/base/include/mrpt/math/ops_containers.h	(working copy)
@@ -248,11 +248,13 @@
 		}
 
 		/** Finds the maximum value (and the corresponding zero-based index) from a given container.
+		  * \exception std::exception On an empty input vector
 		  */
 		template class CONTAINER
 		typename CONTAINER::value_type
 		maximum(const CONTAINER v, size_t *maxIndex)
 		{
+			ASSERT_ABOVE_(v.size(),0)
 			typename CONTAINER::const_iterator maxIt = std::max_element(v.begin(),v.end());
 			if (maxIndex) *maxIndex = std::distance(v.begin(),maxIt);
 			return *maxIt;
@@ -260,11 +262,13 @@
 
 		/** Finds the maximum value (and the corresponding zero-based index) from a given vector.
 		  * \sa maximum, minimum_maximum
+		  * \exception std::exception On an empty input vector
 		  */
 		template class CONTAINER
 		typename CONTAINER::value_type
 		minimum(const CONTAINER v, size_t *minIndex)
 		{
+			ASSERT_ABOVE_(v.size(),0)
 			typename CONTAINER::const_iterator minIt = std::min_element(v.begin(),v.end());
 			if (minIndex) *minIndex = std::distance(v.begin(),minIt);
 			return *minIt;
@@ -272,6 +276,7 @@
 
 		/** Compute the minimum and maximum of a vector at once
 		  * \sa maximum, minimum
+		  * \exception std::exception On an empty input vector
 		  */
 		template class CONTAINER
 		void minimum_maximum(
@@ -281,6 +286,7 @@
 			size_t *minIndex,
 			size_t *maxIndex)
 		{
+			ASSERT_ABOVE_(v.size(),0)
 			const size_t N = v.size();
 			if (N)
 			{

Bug#560538: New upstream relase solves FTBFS (mrpt: FTBFS: pinhole.cpp:39:20: error: cvaux.h: No such file or directory

[Jose Luis Blanco]

Hi there,

I'll upload it to debian mentors and notify it to my mentor, by this weekend.
Thanks for the remainder and the note about the package names!

Best,
JL

On Fri, Apr 16, 2010 at 1:52 PM, Hideki Yamane henr...@debian.or.jp wrote:
 Hi,

  upstream says,
MRPT Downloads -  Latest release: 0.8.1 - 6/MAR/2010

  and it solves this FTBFS (I can build it with pbuilder).
  Could you consider to update to it?

  # Please use ~ for svn version, i.e. 0.8.1~svn1408-1
   It should be updated as 1:0.8.1-1 now.

 --
 Regards,

  Hideki Yamane     henrich @ debian.or.jp/iijmio-mail.jp
  http://wiki.debian.org/HidekiYamane



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#503458: mrpt - FTBFS: unrecognized command line option -mtune=native

[Jose Luis Blanco]

Hello Bastian,

Thanks for reporting me. Do you know what should be my next step with
this package? I want to fix it, but then I should submit it again to
mentors.d.o, right??

Thanks a lot for your time.

Best,
Jose Luis


Bastian Blank wrote:
 Package: mrpt
 Version: 0.6.2svn476-1
 Severity: serious
 
 There was an error while trying to autobuild your package:
 
 Automatic build of mrpt_0.6.2svn476-1 on debian-31.osdl.marist.edu by 
 sbuild/s390 98
 [...]
 make[3]: Entering directory `/build/buildd/mrpt-0.6.2svn476'
 [  0%] Building CXX object otherlibs/ann/CMakeFiles/mrpt-ann.dir/ANN.o
 cc1plus: error: unrecognized command line option -mtune=native
 make[3]: *** [otherlibs/ann/CMakeFiles/mrpt-ann.dir/ANN.o] Error 1
 make[3]: Leaving directory `/build/buildd/mrpt-0.6.2svn476'
 make[2]: *** [otherlibs/ann/CMakeFiles/mrpt-ann.dir/all] Error 2
 make[2]: Leaving directory `/build/buildd/mrpt-0.6.2svn476'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/build/buildd/mrpt-0.6.2svn476'
 make: *** [install] Error 2
 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave 
 error exit status 2
 **
 Build finished at 20081026-0557
 FAILED [dpkg-buildpackage died]
 
 Using -mtune=native is unacceptable for building Debian packages at all.
 
 Bastian
 
 



-- 

___

Jose-Luis Blanco-Claraco  Phone: +34 952 132848
Dpto. Ingenieria de Sistemas y Automatica
E.T.S.I. Telecomunicacion   Fax: +34 952 133361
Universidad de Malaga
Campus Universitario de Teatinos
29071 Malaga, Spain

http://www.isa.uma.es/jlblanco
___




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]