Bug#997120: [Debian-med-packaging] Bug#997120:

[Jose Luis Rivero]

On Wed, Feb 16, 2022 at 8:32 AM Emmanuel Promayon <
emmanuel.proma...@univ-grenoble-alpes.fr> wrote:

> Dear Jose and Andreas,
>
> On 14/02/2022 17:02, Andreas Tille wrote:
>
> Am Mon, Feb 14, 2022 at 12:18:47AM +0100 schrieb Jose Luis Rivero:
>
> You are welcome. This bug is preventing one of my packages (Gazebo) from
> being
> migrated to testing. Could we please upload a revision bump of the current
> version to solve this issue while we work on 5.0.2?
>
> Hmmm, that's a bit tricky now.  I've uploaded 5.0.2 to new[1].  May be
> pinging #debian-ftp could help?  (I'm hesitating a bit to do so myself
> since I used that option recently a bit frequently.)
>
> Sorry about that: I did not notice that bug 997120 was blocking gazebo
> (should there did not be a flag or message somewhere to alert about that?
> Being quite inexperienced I might well as missed it...)
> Let me know if (and how!) I can help with asking the ftpmaster team.
>

No worries Emmanuel, thanks for your offer to help. I have not pinged the
ftp-master team yet,
so you are on time to help the poor Gazebo to go to testing :)

Thanks!

>

Bug#997120:

[Jose Luis Rivero]

Hello!

>
> Am Mon, Feb 07, 2022 at 10:57:36PM +0100 schrieb Emmanuel Promayon:
> > Thank you very much for this patch, you are absolutely right: your patch
> > fixes the problem!
>
> Possibly it fixes camitk for the current package in Debian.  So thanks a
> lot in any case.
>

You are welcome. This bug is preventing one of my packages (Gazebo) from
being
migrated to testing. Could we please upload a revision bump of the current
version to solve this issue while we work on 5.0.2?

> > It should also work perfectly well to make the last upstream version
(5.0.2)
> > build properly. Andreas started to check on last month but with your
patch,
> > it should work.
> > I can confirm anyway that camitk version 5.0.2 builds well with ITK5
with
> > the help of your patch.
>
> I've pushed an adapted patch to Git but I can't confirm that it builds.
> May be you can have another look and compare the status in Git with your
> local build?  There are about 100 failed tests in the build time test
> suite.  Unfortunately salsa-ci chokes in source extration (no idea why
> so I can only provide my local build log if you can't verify this.
>

I think that the problem in salsa is that the artifact handling between
steps
is broken due to the high number of files of camitk. We can probably copy
the
workaround that the linux kernel team has in place, see:

https://www.decadent.org.uk/ben/blog/ci-for-the-debian-kernel-team.html

Running the salsa catmik code in my sbuild run seems fine to me:

"""
100% tests passed, 0 tests failed out of 526
...
+--+
| Summary
   |
+--+

Autopkgtest: pass
Build Architecture: amd64
Build Type: full
Build-Space: 6680544
Build-Time: 743
Distribution: unstable
Host Architecture: amd64
Install-Time: 74
Job: /home/jrivero/code/debian/camitk_5.0.2-1.dsc
Lintian: warn
Machine Architecture: amd64
Package: camitk
Package-Time: 823
Piuparts: fail
Source-Version: 5.0.2-1
Space: 6680544
Status: successful
Version: 5.0.2-1

"""

The Piuparts failure I think is something related to my local setup but
compilation, test and autopkgtest seems fine to my eyes.

Thanks.

Bug#997120:

[Jose Luis Rivero]

Hi. I've been looking into the camitk compilation, I think I have a patch
for it.

The build is currently failing by trying to find the file
CommandLineOptions.ixx.o. Problem is really in
the line above where the compiler does not identify the file
CommandLineOptions.ixx as a valid
c++ file, so the object file is not being generated:
"""
c++: warning:
/build/camitk-o5Au93/camitk-4.1.2/sdk/applications/testactions/CommandLineOptions.ixx:

linker input file unused because linking not done
""

The compiler can be informed about the format of the file by using -x c++
but the result
won't compile at all since the file seems to be designed to be used in
combination with
other headers (other headers include .ixx at the end of the file). The code
is in the compilation
units via include in other headers, no reason to add it to CMake.

Removing the .ixx makes the compilation work in an Sid sbuild environment.
"""
+--+
| Summary
   |
+--+

Autopkgtest: pass
Build Architecture: amd64
Build Type: full
Build-Space: 6204608
Build-Time: 725
Distribution: unstable
Host Architecture: amd64
Install-Time: 72
Job: /home/jrivero/code/debian/camitk_4.1.2-5.dsc
Lintian: warn
Machine Architecture: amd64
Package: camitk
Package-Time: 801
Piuparts: pass
Source-Version: 4.1.2-5
Space: 6204608
Status: successful
Version: 4.1.2-5
"""

Attached is the debdiff.


camitk_4.2.2-5.debdiff
Description: Binary data

Bug#1002160: ignition-transport: FTBFS: build-dependency not installable: libignition-msgs5-5 (= 5.1.0+dfsg-7+b1)

[Jose Luis Rivero]

The problems should be fixed by resolving the transition from experimental
to unstable of the whole Ignition family:
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002286

On Tue, Dec 21, 2021 at 5:34 PM Lucas Nussbaum  wrote:

> Source: ignition-transport
> Version: 8.0.0+dfsg-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211220 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> >
> +--+
> > | Install package build dependencies
>|
> >
> +--+
> >
> >
> > Setup apt archive
> > -
> >
> > Merged Build-Depends: cmake, pkg-config, debhelper-compat (= 12),
> libgtest-dev, libprotoc-dev, libprotobuf-dev, protobuf-compiler, uuid-dev,
> libzmq3-dev (>= 3.0.0), libignition-msgs-dev (>= 5), libignition-cmake-dev
> (>= 2), libsqlite3-dev, build-essential, fakeroot
> > Filtered Build-Depends: cmake, pkg-config, debhelper-compat (= 12),
> libgtest-dev, libprotoc-dev, libprotobuf-dev, protobuf-compiler, uuid-dev,
> libzmq3-dev (>= 3.0.0), libignition-msgs-dev (>= 5), libignition-cmake-dev
> (>= 2), libsqlite3-dev, build-essential, fakeroot
> > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in
> '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
> > Ign:1 copy:/<>/apt_archive ./ InRelease
> > Get:2 copy:/<>/apt_archive ./ Release [957 B]
> > Ign:3 copy:/<>/apt_archive ./ Release.gpg
> > Get:4 copy:/<>/apt_archive ./ Sources [459 B]
> > Get:5 copy:/<>/apt_archive ./ Packages [540 B]
> > Fetched 1956 B in 0s (0 B/s)
> > Reading package lists...
> > Reading package lists...
> >
> > Install main build dependencies (apt-based resolver)
> > 
> >
> > Installing build dependencies
> > Reading package lists...
> > Building dependency tree...
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> >
> > The following packages have unmet dependencies:
> >  libignition-msgs-dev : Depends: libignition-msgs5-5 (= 5.1.0+dfsg-7+b1)
> but it is not going to be installed
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.
>
>
> The full build log is available from:
>
> http://qa-logs.debian.net/2021/12/20/ignition-transport_8.0.0+dfsg-3_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
>

Bug#984063:

[Jose Luis Rivero]

Hello! Gazebo maintainer here, affected by this RC bug. Looking into
upstream repository there is a potential commit that can be used to patch
this problem until new versions land in Debian:

https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359a8fdb55304124823a3a8c9

Let me know if you need more help or assistance.
Thanks!

Bug#984276:

[Jose Luis Rivero]

Hello! Gazebo maintainer here, affected by this RC bug on opencolorio. I've
looked in the problem and seems something easy to fix:

diff --git a/src/core/ImageDesc.cpp b/src/core/ImageDesc.cpp
index 63156c8..e96e758 100644
--- a/src/core/ImageDesc.cpp
+++ b/src/core/ImageDesc.cpp
@@ -57,8 +57,8 @@ OCIO_NAMESPACE_ENTER
 os << "gData=" << planarImg->getGData() << ", ";
 os << "bData=" << planarImg->getBData() << ", ";
 os << "aData=" << planarImg->getAData() << ", ";
-os << "width=" << packedImg->getWidth() << ", ";
-os << "height=" << packedImg->getHeight() << ", ";
+os << "width=" << planarImg->getWidth() << ", ";
+os << "height=" << planarImg->getHeight() << ", ";
 os << "yStrideBytes=" << planarImg->getYStrideBytes() << "";
 os << ">";
 }

The repo in salsa seems to be a work in progress to get 2.x series into
Debian, although not finished yet. We could apply this patch on top of the
current version to fix this bug while the 2.x transition is being done.

Let me know if you need more help.
Thanks!

Bug#887931: gazebo FTBFS with libtinyxml2-dev 6.0.0+dfsg-1

[Jose Luis Rivero]

gazebo 7.10 is going to be released in a few days and it will ship the fix:
https://bitbucket.org/osrf/gazebo/src/d15878d662a21dea2a0f61c218ce54e2aff4f489/Changelog.md?fileviewer=file-view-default

I'll wait and sync to the latest version directly.
Thanks for the patch Peter.

On Thu, Jan 25, 2018 at 9:08 AM, peter green  wrote:

> Hi
>
> I just applied the upstream patch in raspbian. The patch to the sourcecode
> applied fine but the patch to the buildsystem had to be applied manually.
>
> A debdiff of what I uploaded to Raspbian is attatched, no intent to NMU in
> Debian.
>
>
>

Bug#840165: fcl bug

[Jose Luis Rivero]

On 17/10/16 19:17, Jochen Sprickerhof wrote:
> * Leopold Palomo-Avellaneda <l...@alaxarxa.net> [2016-10-17 11:31]:
>> Please Jochen, could you upload it?
> 
> Will do later.
> 
> @Jose: Can you comment why you added it in
> 
> https://anonscm.debian.org/cgit/debian-science/packages/fcl.git/commit/?id=2b59789404c96e4fbc6877ef2db0adccbeb8d97b
> 

I remember to see the option while working on enabling the octomap
support and enable expecting the build system to do what the option says
(strictly enabling SSE). I did not look into the implementation sorry.

+1 on removing it.

-- 
Jose Luis Rivero <jriv...@osrfoundation.org>



signature.asc
Description: OpenPGP digital signature

Bug#835734: Bug#835930 kido: missing link libraries

[Jose Luis Rivero]

Hello Gianfranco:

On 31/08/16 08:48, Gianfranco Costamagna wrote:
> Hi Jose, are you aware of your RC bugs?
> 

I was aware of my RC bugs, yes, and I was working on fixing them.

> in case, please say something about the ongoing work on git, because there is 
> no gain in having somebody else prepare an NMU
> without acking/nacking changes or thanking him.
> 

I did not look into my bugmail during these last days, sorry about that.
Thanks for taking time to work on debugging and fixing the packages.

For the next time, please feel free to use the package git so we could
add another layer to avoid work duplication.

> also, the xml patch looks almost the same as the upstream cherry-pick, and 
> the link patch looks mostly the same as my patch.
> 
> https://github.com/dartsim/dart/commit/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch
> 
> Can you please consider setting the correct authorship and forward patches 
> upstream?
> 

Sorry for not checking upstream code this time. I have the impression
that you think that I deliberately miss/remove the credit from patches,
that is not the case Gianfranco. I have no reason to do this which goes
against what rules open source. I wrote my patches (both were trivial)
without using upstream changes or notice the existence of your patch.

> (I don't care about authorship, but cherry-picking from upstream,
changing it is considered bad).

Fully agree here, I will remove my custom patches and use the upstream
commit.

> I'll assume good faith from your side, and cancel the NMU.
> (let me know if you need a sponsor)

Thanks for the assumption and the offer, I have rights now to upload
changes to kido.

-- 
Jose Luis Rivero <jriv...@osrfoundation.org>



signature.asc
Description: OpenPGP digital signature

Bug#811498: libconsole-bridge0.2v5: ABI bump without package rename

[Jose Luis Rivero]

Package: libconsole-bridge0.2v5
Followup-For: Bug #811498

Hey Jochen:

Thanks for the report. You are right, I broke the new update. My
intention was not to change package and library name since upstream
did not change the API/ABI (I'm working with them to keep a sane
semantic versioning scheme). I did that for the package but not for
the library, sorry for that.

I believe that we can workaround on this problem by creating a symlink
from libconsole_bridge.so.0.3 to a new libconsole_bridge.so.0.2. This
way we can respect the upstream release as-it but keep the dependencies
stable in debian which depends on the 0.2 lib.

Jochen, do you see any problem with this? or do you have a better idea
to solve the situation keeping in mind that there is no ABI/API change
in the new 0.3.0 version?

Thanks.

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

Kernel: Linux 3.13.0-74-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libconsole-bridge0.2v5 depends on:
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-22
ii  libstdc++6  5.2.1-22

libconsole-bridge0.2v5 recommends no packages.

libconsole-bridge0.2v5 suggests no packages.

-- no debconf information

Bug#747361: sdformat: FTBFS: most odd-numbered tests time out

[Jose Luis Rivero]

I've never seen this before in sdformat upstream project or our own 
building farms. The fact that only odd tests are failing is because the 
even ones are just checkers of the output of the test run before. So the 
conclusion is: all of them are returning a timeout.


May I have access to the building log? What command is exactly being run 
during the test phase?


Thanks!

On 05/07/2014 10:17 PM, Aaron M. Ucko wrote:

Source: sdformat
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source

Automated builds of sdformat have all been encountering test timeouts,
in a distinctive pattern:

   The following tests FAILED:
  1 - INTEGRATION_audio (Timeout)
  3 - INTEGRATION_cfm_damping_implicit_spring_damper (Timeout)
  5 - INTEGRATION_fixed_joint_reduction (Timeout)
  7 - INTEGRATION_joint_axis_frame (Timeout)
  9 - INTEGRATION_provide_feedback (Timeout)
  11 - PERFORMANCE_parser_urdf (Timeout)
  13 - UNIT_SDF_TEST (Timeout)
  15 - UNIT_Console_TEST (Timeout)
  19 - UNIT_parser_urdf_TEST (Timeout)

It's not clear why, but I do see that the tests were always running in
parallel; could they somehow interfere with each other?  At any rate,
please do take a look.

Thanks!




--
Jose Luis Rivero jriv...@osrfoundation.org


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

Bug#743815: FTBFS: 'class urdf::Link' has no member named 'collision_groups'

[Jose Luis Rivero]

Working on solving it with upstream:
https://bitbucket.org/osrf/sdformat/issue/59/embedded-copy-of-urdfdom-is-outdated


On Sun, Apr 6, 2014 at 8:47 PM, Julien Cristau jcris...@debian.org wrote:

 Source: sdformat
 Version: 1.4.11-1
 Severity: serious
 Justification: fails to build from source
 X-Debbugs-Cc: urdf...@packages.debian.org

 Hi,

 your package no longer builds in unstable, probably because of the
 latest urdfdom upload:
  [ 36%] Building CXX object src/CMakeFiles/sdformat.dir/parser_urdf.cc.o
  cd /«PKGBUILDDIR»/obj-x86_64-linux-gnu/src  /usr/bin/c++
 -Dsdformat_EXPORTS -g -O2 -fstack-protector --param=ssp-buffer-size=4
 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2   -Wall -Wextra
 -Wno-long-long -Wno-unused-value -Wno-unused-value -Wno-unused-value
 -Wno-unused-value -Wfloat-equal -Wshadow -Winit-self -Wswitch-default
 -Wmissing-include-dirs -pedantic -fPIC -I/«PKGBUILDDIR»/test/gtest/include
 -I/«PKGBUILDDIR»/include -I/«PKGBUILDDIR»/obj-x86_64-linux-gnu
 -I/«PKGBUILDDIR»/obj-x86_64-linux-gnu/include-fPIC -o
 CMakeFiles/sdformat.dir/parser_urdf.cc.o -c
 /«PKGBUILDDIR»/src/parser_urdf.cc
  /«PKGBUILDDIR»/src/parser_urdf.cc: In function 'void
 ReduceCollisionToParent(UrdfLinkPtr, const string, UrdfCollisionPtr)':
  /«PKGBUILDDIR»/src/parser_urdf.cc:324:12: error: 'class urdf::Link' has
 no member named 'collision_groups'
   _link-collision_groups.insert(make_pair(_groupName, cols));
  ^

 Cheers,
 Julien

 --
 debian-science-maintainers mailing list
 debian-science-maintain...@lists.alioth.debian.org

 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers