Bug#1002451: lintian: False positive file-references-package-build-path

[Jose Luis Blanco Claraco]

Package: lintian
Version: 2.114.0
Severity: normal
X-Debbugs-Cc: joseluisblan...@gmail.com

Dear Maintainer,

I found a false positive report of file-references-package-build-path for a C++ 
header file 
included in a package, which does not contain any path at all. 
The string detected by data/files/build-path-regex in our case is inside this 
C++ comment: 

/* Defined only if MRPT is being build/was built with precompiled
   headers enabled */

I know it would be pretty complicated to discard C++ comments with a simple 
regex, but
a possible solution is to change the most generic regex: 

^build/

to something more specific capturing names like real build paths, for example: 
`build/mrpt-mtM7nO/` => `build/[:alpha:]*-[:alpha:]{6}` or alike?

Thanks, 


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-91-generic (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils2.37-10
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1001618: RM: mrpt [ppc64el] -- ROM; We want a newer mrpt version to get into unstable, then into testing, but we have this bug blocking it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100078

[Jose Luis Blanco-Claraco]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: joseluisblan...@gmail.com

Bug#902488: Use system libraries

[JOSE LUIS BLANCO CLARACO]

Hi,

Thanks for the pointer. We'll evaluate that possibility. However, we
used a somewhat modified version of the library, so it might be no
trivial; but it's worth trying.

Cheers,


On Wed, Jun 27, 2018 at 8:39 AM, Yangfl  wrote:
> Source: mrpt
> Severity: wishlist
>
> Hi,
>
> As libsimpleini-dev is now available, please consider using system
> libraries instead of bundled ones.



-- 
_______

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

Bug#880388: mrpt: Please don't use unaligned access on ARM

[JOSE LUIS BLANCO CLARACO]

Hi Steve,

Thanks for the patch!
It's been incorporated upstream, will be fixed in the next version
1.5.4, to be released soon.

Cheers,


On Tue, Oct 31, 2017 at 7:40 AM, Steve Langasek
<steve.langa...@canonical.com> wrote:
> Package: mrpt
> Version: 1:1.5.3-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic ubuntu-patch
>
> Hi José Luis,
>
> The new upstream release of mrpt fails to build on armhf in Ubuntu, because
> it assumes unaligned reads are allowed.  This is not a portable assumption;
> specifically, on armhf this may raise a SIGBUS depending on the CPU and the
> kernel configuration.
>
> The Ubuntu infrastructure does raise SIGBUS, so I've uploaded the attached
> patch to Ubuntu to fix the failure.  Please consider applying this in Debian
> as well, where it make affect some number of users even if it doesn't
> trigger on Debian infrastructure.
>
> Thanks,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developerhttp://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org



-- 
___

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

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#873528: mrpt: FTBFS on sparc64: no B2500000-B4000000

[JOSE LUIS BLANCO CLARACO]

Thanks Aaron!

I have fixed this upstream [1]. Next release will have this fixed.
I've just sent the command to tag this bug as "fixed-upstream".

Cheers,

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



On Mon, Aug 28, 2017 at 8:23 PM, Aaron M. Ucko <u...@debian.org> wrote:
> Source: mrpt
> Version: 1:1.5.3-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
>
> The latest build of mrpt for sparc64 (admittedly not a release
> architecture) failed:
>
>   /<>/libs/hwdrivers/src/rplidar/src/arch/linux/net_serial.cpp: 
> In member function '_u32 rp::arch::net::raw_serial::getTermBaudBitmap(_u32)':
>   
> /<>/libs/hwdrivers/src/rplidar/src/arch/linux/net_serial.cpp:300:49:
>  error: 'B250' was not declared in this scope
>
> (and likewise for B300, B350, and B400).  Please account
> for the possibility that these macros are undefined.  (sparc and
> sparc64 have historically used their own values of termios constants,
> perhaps to match Solaris.)
>
> 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#865735: mrpt shouldn't disable PIE

[JOSE LUIS BLANCO CLARACO]

Thanks Adrian!

We already addressed this upstream (and in a waiting version in
mentors.debian.org) but by adding "+pie". We'll use your version if
that's more correct. Thanks.

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#834274: mrpt: FTBFS in testing

[JOSE LUIS BLANCO CLARACO]

Gracias Santiago, (cc:Gianfranco)

This FTBFS did seem to be caused by the latest Eigen 3.3. beta
version. I could reproduce the error and it's fixed now upstream.

I have added another debian/patch to MRPT 1.4.0 and uploaded it to
mentors [1]. It could be great if any of you could sponsor it to
quickly fix this bug in Debian.

Thanks in advance for your time!!

Best,
JL

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


On Sun, Aug 14, 2016 at 2:28 AM, Santiago Vila <sanv...@unex.es> wrote:
> Package: src:mrpt
> Version: 1.4.0-5
> Severity: serious
>
> Dear maintainer:
>
> This package currently fails to build from source in stretch:
>
> --
> [ 29%] Building CXX object 
> libs/opengl/CMakeFiles/mrpt-opengl.dir/src/CEllipsoidInverseDepth2D.cpp.o
> cd /build/mrpt-1.4.0/obj-x86_64-linux-gnu/libs/opengl && /usr/bin/c++   
> -DMRPT_ASSIMP_VERSION_MAJOR=3 -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
> -Dmrpt_opengl_EXPORTS -I/usr/include/eigen3 -I/usr/include/eigen3/unsupported 
> -I/usr/include/libftdi1 -I/usr/include/opencv -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/x86_64-linux-gnu/ffmpeg 
> -I/usr/include/x86_64-linux-gnu/libavcodec 
> -I/usr/include/x86_64-linux-gnu/libavformat 
> -I/usr/include/x86_64-linux-gnu/libswscale -isystem 
> /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem 
> /usr/include/wx-3.0 -I/build/mrpt-1.4.0/. 
> -I/build/mrpt-1.4.0/obj-x86_64-linux-gnu/include/mrpt-config/unix 
> -I/build/mrpt-1.4.0/libs/opengl/src -I/build/mrpt-1.4.0/libs/opengl/src/glext 
> -I/usr/include/assimp -I/build/mrpt-1.4.0/libs/opengl/include 
> -I/build/mrpt-1.4.0/libs/base/include  -isystem /usr/include/wx-3.0 -I 
> /usr/include/wx-3.0 -isystem 
> /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -I 
> /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unic
>  ode-3.0 -isystem /usr/include/eigen3 -g -O2 
> -fdebug-prefix-map=/build/mrpt-1.4.0=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
> -Wreturn-type -Wextra -Wno-unused-parameter  -Wall -Wno-long-long 
> -Wno-variadic-macros -Wno-write-strings -std=c++11 -pthread  -msse2 
> -funroll-loops -mfpmath=sse  -g -O2 -fdebug-prefix-map=/build/mrpt-1.4.0=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC   
> -I/usr/include/assimp -o 
> CMakeFiles/mrpt-opengl.dir/src/CEllipsoidInverseDepth2D.cpp.o -c 
> /build/mrpt-1.4.0/libs/opengl/src/CEllipsoidInverseDepth2D.cpp
> tests/CMakeFiles/test_mrpt_base.dir/build.make:353: recipe for target 
> 'tests/CMakeFiles/test_mrpt_base.dir/__/libs/base/src/math/matrix_ops4_unittest.cpp.o'
>  failed
> make[4]: *** 
> [tests/CMakeFiles/test_mrpt_base.dir/__/libs/base/src/math/matrix_ops4_unittest.cpp.o]
>  Error 1
> --
>
> There are full logs available here:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/mrpt.html
>
> 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#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

DIR»/libs/base/include/mrpt/utils/bits.h:133:20: note: candidate: 
> void mrpt::utils::reverseBytesInPlace(int16_t&) 
> void BASE_IMPEXP reverseBytesInPlace(int16_t& v_in_out);
> ^
> /«PKGBUILDDIR»/libs/base/include/mrpt/utils/bits.h:133:20: note:   conversion 
> of argument 1 would be ill-formed:
> In file included from /«PKGBUILDDIR»/libs/maps/src/maps-precomp.h:14:0,
> from /«PKGBUILDDIR»/libs/maps/src/maps/CColouredPointsMap.cpp:10:
> /«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:77: error: invalid 
> initialization of non-const reference of type 'int16_t& {aka short int&}' 
> from an rvalue of type 'int16_t {aka short int}'
> for (size_t i=0;i<ElementCount;i++) mrpt::utils::reverseBytesInPlace(ptr[i]);
>
> and maybe more
> https://buildd.debian.org/status/package.php?p=mrpt=unstable
>
> G.
>
>
>
>
>
> Il Venerdì 22 Luglio 2016 10:32, Gianfranco Costamagna 
> <locutusofb...@debian.org> ha scritto:
> Hi,
>
>
>
>>fat finger typo!  ;-)
>
>
> :)
>>https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-4.dsc
>>
>>I included the potential fix to the other HPPA bug... hopefully it'll
>>work at the first attempt!
>
>
> you will know in a few hours, the package is uploaded, it will go in
> unstable at the end of dinstall
> https://ftp-master.debian.org/dinstall.status
> https://ftp-master.debian.org/dinstall.html
>>Thanks for everything guys!
>
>
> you are welcome, lets hope for the best!
> (and for hppa, if it doesn't fix, just reopen the bug and don't care,
> we don't have porter machines, so porters have to look at the issue, I can't)
>
>
> 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#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

You're quick! Alright... (sigh) I'll wait until everything ends to see if
there are more problems and will submit one more patch this is
something personal now ;-)

Thanks!

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

>>Hi Aarom, Gianfranco,
> s/m/n ;)

fat finger typo!  ;-)


> since we have a fix for the other architecture, what about adding this patch 
> and upload on
> unstable?
> at least we have a fix for sparc64.

Done!

The new package is in mentors:
https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-4.dsc

I included the potential fix to the other HPPA bug... hopefully it'll
work at the first attempt!

Thanks for everything guys!
JL

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

Hi Aarom, Gianfranco,

Regarding this bug for HPPA, I can't run any test myself for lack of
access to this architecture, but carefully reviewing the code I think
I might have found a fix.
The patch is in [1].

It would be great if you have access to a porter machine with hppa,
but if you don't, just let me know and I'll prepare the next package
version for unstable which can be uploaded and tested in the build
farm... a waste of resources if it doesn't work, but I can't find
another alternative if no porter box is available...

The patch in [1]  is intended to be tested on top of the latest
1:1.0.4:3 version [2].
Instead of a costly complete build, the minimal test suite to check
this bug can be run with the attached rules file.
The main difference is the execution of:

dh_auto_build -O--buildsystem=cmake -- run_tests_mrpt_hwdrivers

instead of the complete build.

In the event of a unit test failure, it would be very valuable to see
the gdb bt output:

gdb --args /PATH/TO/SRCS/tests/test_mrpt_hwdrivers /PATH/TO/SRCS/
(run)
(bt)

Cheers,
JL

[1] https://github.com/MRPT/mrpt/commit/8d2580e56a60b1444568ca9cb8d976496044832c
[2] http://httpredir.debian.org/debian/pool/main/m/mrpt/mrpt_1.4.0-3.dsc

Bug#830741: mrpt: FTBFS on sparc64: TopographyReconstructPathFrom3RTK bus error

[JOSE LUIS BLANCO CLARACO]

This is now fixed upstream (tagged as such).
A patch from the pull-request in [1] will be included in the next
patched version to mark this bug solved.

One million thanks to Aaron for his advice and to Gianfranco for his
persistent support with porter machines... this couldn't have been
fixed without you!!

[1] https://github.com/MRPT/mrpt/issues/295

Bug#830741: mrpt: FTBFS on sparc64: TopographyReconstructPathFrom3RTK bus error

[JOSE LUIS BLANCO CLARACO]

Hi again Aaron, (cc: Gianfranco)

I can't figure out what's the problematic code by inspecting the code,
so I have prepared a modified package version which should reveal us
more details on the failure.
Could it be possible for any of you to launch a build for this
package, at least in a porter machine of the problematic architectures
(hppa and sparc64)?? If not, submitting it as a new package version to
unstable would be a solution, but the debugging stuff I added here may
make other archs to fail, so it's not my preferred solution...

Best and thanks for your time.
JL

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


On Mon, Jul 11, 2016 at 12:27 AM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
> Source: mrpt
> Version: 1:1.4.0-3
> Severity: important
> Justification: fails to build from source
>
> Thanks for fixing the sparc64 mrpt compilation error!  Alas, the build
> still fails, this time with a test suite error:
>
>   [ RUN  ] TopographyReconstructPathFrom3RTK.sampleDataset
>   Bus error
>
> Could you please take a look?  ("Bus error" typically indicates
> insufficiently aligned data.)
>
> 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#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

Thanks Aaron! I'm really busy these days with other open fronts in
MRPT, but will try to eventually fix this.

Best,


On Mon, Jul 11, 2016 at 12:24 AM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
> Source: mrpt
> Version: 1:1.4.0-3
> Severity: important
> Justification: fails to build from source
>
> Thanks for looking into the build failures I previously reported.
> mrpt builds are in much better shape now, but the hppa build still fails:
>
>   [ RUN  ] CGPSInterface.parse_NMEA_RMC
>   unknown file: Failure
>   C++ exception with description "
>
>=== MRPT EXCEPTION =
>   void mrpt::system::timestampToParts(mrpt::system::TTimeStamp, 
> mrpt::system::TTimeParts&, bool), line 120:
>   Assert condition failed: sec_frac<1.0
>   " thrown in the test body.
>   [  FAILED  ] CGPSInterface.parse_NMEA_RMC (8 ms)
>
> 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#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
>