Re: sponsoring library transitions

[Jose Luis Rivero]

Hello Pierre:

On Tue, Mar 5, 2024 at 11:16 PM Pierre Gruet  wrote:

> >
> > I've been following the time64_t transition and I think that all
> > packages have landed unstable and some days have passed since that. Is
> > it now a good moment to upload the new versions and start the
> transitions?
> >
> > Thanks!
>
> THanks for following the situation; I think we have to wait longer,
> packages have been uploaded to unstable but there are some side effects
> and the migration to testing has not happened yet.
> For instance, even dart had failed its build on ppc64el, I have just
> triggered a new build, which passed. Let's wait all the packages
> successfully build and are in testing before going on; I can guess the
> release team will appreciate having the time_t transition behind in
> order to process new transitions.
>
> But no worry, we will be able to proceed to all the updates you are
> planning to do!
>

Thanks Pierre for the information. No problem, let's wait.

Re: sponsoring library transitions

[Jose Luis Rivero]

Hi again:

On Fri, Feb 9, 2024 at 6:12 PM Pierre Gruet  wrote:

> ... dart is currently involved in the 64 bit time_t transition. Have you
> seen that Version 6.12.1+dfsg4-13.1~exp1 has been uploaded to
> experimental? It will undergo a library transition so we should wait it
> is finished.
>

I've been following the time64_t transition and I think that all packages
have landed unstable and some days have passed since that. Is it now a good
moment to upload the new versions and start the transitions?

Thanks!

Re: sponsoring library transitions

[Jose Luis Rivero]

On Fri, Feb 9, 2024 at 6:12 PM Pierre Gruet  wrote:

> Hi Jose Luis,
>
> Le 08/02/2024 à 18:24, Jose Luis Rivero a écrit :
>
> ... dart is currently involved in the 64 bit time_t transition. Have you
> seen that Version 6.12.1+dfsg4-13.1~exp1 has been uploaded to
> experimental? It will undergo a library transition so we should wait it
> is finished.
>

Ouch! Yes, I saw the transition emails and the experimental package but did
not remember it when I sent the sponsoring request.
Thanks for bringing this to the table, we can wait until the time_t
transition is done.

Thanks Pierre.

sponsoring library transitions

[Jose Luis Rivero]

Hi all:

I have a couple of library transitions ready to review and upload and would
need sponsoring to start the transitioning process:

 - urdfdom https://salsa.debian.org/science-team/urdfdom
 - dart https://salsa.debian.org/science-team/dart
   (salsa CI is over 3 hours)

Thanks!

Need sponsor for a new package: ignition-utils

[Jose Luis Rivero]

Hello Science team:

I would need a sponsor for a new package in the Ignition Robotics family:
ignition-utils. Timo and Jochen have been kindly reviewing my packages but
I would prefer not to overload them and make the requests as collective as
possible inside the team.

In exchange I can offer to review another package or try to fix any bug
that you or the team is interested in.

Thanks!

Re: Multiple versions of Ignition libraries for different simulators

[Jose Luis Rivero]

On Tue, Aug 17, 2021 at 2:48 PM Jochen Sprickerhof 
wrote:

> * Jose Luis Rivero  [2021-08-17 14:05]:
> >ignition-gazebo is a rewrite of the good old Gazebo (Gazebo classic) which
> >is designed to supersede it. Can be seen as a ROS 1 vs ROS 2 evolution
> >since they share some important aspects like the break of compatibility
> >with the antecesor. It is hard to say that the replacement is ready since
> >it mostly varies with everyone's use case. There is a table that can help
> >in this front:
> >https://ignitionrobotics.org/docs/edifice/comparison
>
> Thanks, looks like a lot of features are there while a bunch is still
> missing. Not sure if it makes sense to update already, but I don't use
> Gazebo currently so your call.
>

Your quick look I think is accurate.


> >I have the feeling that there is a large community of people now using
> >Gazebo that will take some time to migrate to ignition-gazebo for
> different
> >reasons so my personal preference would be to be able to have both
> >available in Debian during some time to give people time to plan the
> >migration.
>
> But are they bound to Gazebo or also to a specific ROS and Ubuntu
> version?
>

Good question. The Gazebo user base mainly comes from people integrating it
with ROS but there are some users of the simulation without integrating it
in other frameworks. The good point of keeping Gazebo11 in Debian is that
ROS and ROS2 integrate this version for current distributions and any other
probably until the EOL of it. User can get it directly from Debian (all
supported platforms and and all its derivatives) instead of dealing with
other kinds of sources.


> >> So my view here would be to upload ignition-gazebo once it is ready and
> >> then see if supporting the old version makes sense.
> >>
> >>
> >I agree. Problem here is that if we upgrade some of the ignition libraries
> >to new major versions, Gazebo classic has never been tested to compile or
> >work with the new major versions so it is unknown if the new mix would
> work
> >in the same or compatible way with previous mix of Gazebo + supported
> >Ignition libs major versions.
>
> Yeah, I mean gazebo plus libraries in the corresponding version. Having
> multiple versions of software in Debian for a transition period seems
> quiet normal.
>

Thanks, that seems to me the most reasonable approach for the whole
problem.

A possible migration plan inside Debian could be:

In experimental:
 1. Rename the needed parts (source package, -deb package, ...) of current
ignition libraries used by Gazebo11 that are not compatible with
ignition-gazebo latest.
 2. Change gazebo11 to use these new package names.
 3. Introduce latest major versions of Ignition libraries in renamed in 1
with the current approach of naming them to be the default ones (mainly
standard -dev package name).

4. Move the whole set of things (all ignition libraries)  from experimental
to unstable at once to facilitate ignition libraries transition to the
latest for the user not in Gazebo.

Does this seem reasonable?

Thanks Jochen for the help.

Re: Multiple versions of Ignition libraries for different simulators

[Jose Luis Rivero]

Hello Leo:

On Mon, Aug 16, 2021 at 12:19 AM Leopold Palomo-Avellaneda 
wrote:

> Hi all,
>
>
> first of all sorry for the late reply.
>
>
No problem.


>
> El 14/8/21 a les 22:17, Jochen Sprickerhof ha escrit:
> > Hi Jose,
> >
> > sorry for the late reply. I had a longer discussion with Timo about this
> > today.
> >
> > * Jose Luis Rivero  [2021-08-11 18:10]:
> >> Development upstream (Open Robotics) is now focused on the new
> >> ignition-gazebo simulator (considered like the sucesor of Gazebo) which
> >> depends on the whole Ignition family of libraries, some of them are the
> >> same libraries (like ignition-transport) than the ones used by Gazebo.
> >
> > Can you give some insights on how both versions compare feature wise?
> > Is it a drop in replacement so everyone could/should switch?
> > If not, when is that expected?
>
> Exactly, Jose your sentence is not clear. Should I understand that
> gazebo11 _only works with ign-transport8 and not ign-transport11? Why?
> I'm asking the same as Jochen.
>

Gazebo11, as far as I know nowadays, has only been tested and used with
ign-transport8. Could it work with ign-transport11? Maybe, I've never seen
that combination but there is nothing I know of preventing it from working.
The point here for me is: do we want to explore the route of combining
gazebo11 on top of different major versions of Ignition libraries than the
ones supported upstream instead of having multiple versions of Ignitions in
Debian? Because going with the first option could lead us to find bugs and
other behaviour differences that upstream is probably going to close by
saying: use the recommended version or use our binaries which use the
recommended versions and that could create a severe problem for the whole
community.

Thanks.

Re: Multiple versions of Ignition libraries for different simulators

[Jose Luis Rivero]

Hey Jochen:

On Sat, Aug 14, 2021 at 10:17 PM Jochen Sprickerhof 
wrote:

> Hi Jose,
>
> sorry for the late reply. I had a longer discussion with Timo about this
> today.
>

No worries.


> * Jose Luis Rivero  [2021-08-11 18:10]:
> >Development upstream (Open Robotics) is now focused on the new
> >ignition-gazebo simulator (considered like the sucesor of Gazebo) which
> >depends on the whole Ignition family of libraries, some of them are the
> >same libraries (like ignition-transport) than the ones used by Gazebo.
>
> Can you give some insights on how both versions compare feature wise?
> Is it a drop in replacement so everyone could/should switch?
> If not, when is that expected?
>

ignition-gazebo is a rewrite of the good old Gazebo (Gazebo classic) which
is designed to supersede it. Can be seen as a ROS 1 vs ROS 2 evolution
since they share some important aspects like the break of compatibility
with the antecesor. It is hard to say that the replacement is ready since
it mostly varies with everyone's use case. There is a table that can help
in this front:
https://ignitionrobotics.org/docs/edifice/comparison


>
> >Problem is that both current versions of Gazebo and ignition-gazebo depend
> >on different major versions of the ignition libraries (i.e gazebo11 used
> >ign-transport8 and ignition-gazebo uses ign-transport11). Although
> upstream
> >supports side by side installations of the Ignition family we have tried
> to
> >have in Debian just one of them to make transitions easier and reduce the
> >maintenance effort. I'm not sure if this problem can drive us to change
> our
> >current practices.
>
> I would see those libraries as independent project for now and would
> expect Debian to provide the latest versions by default once all
> software is compatible.
>

+1. Note that upstream is supporting different major versions at the same
time: development, patches and releases continue in different major
versions of each Ignition library.


> >One of the robotics simulators, Gazebo version 11, is still supported
> >upstream until 2025 but no longer releases new versions.
>
> I'm not sure that is a good argument if there are no new versions. In
> general I would expect Debian to ship the latest version of a software
> so if I do a apt install gazebo, I would expect the latest version
> providing /usr/bin/gazebo.
>

Ouch sorry, I wrote it incompletely: "No longer releases new versions"
means there are no new major versions (aka gazebo12) but development and
new releases of gazebo11 continue (as long as they don't respect the
restrictins of Semantic versioning).


> On the other hand, If you think there is a large enough use base
> (looking at popcon I'm not sure), it may make sense to provide the old
> version with different package names.


I have the feeling that there is a large community of people now using
Gazebo that will take some time to migrate to ignition-gazebo for different
reasons so my personal preference would be to be able to have both
available in Debian during some time to give people time to plan the
migration.


> Note that if you want to support
> this you would probably need to patch the old version to be compatible
> with new libraries, compilers.. that do not support parallel
> installation.
>

Gazebo "classic" (gazebo11) is receiving patches to work with different new
versions of dependencies and upstream is happy integrating them. What I
have not seen are packagers (or users) using different major versions of
Ignition libraries from the ones proposed upstream which are supported and
will be supported until Gazebo is EOL in 2025. I agree that there could be
problems integrating new versions of non-ignition dependencies that are not
going to be installed in parallel but I would expect upstream to be
flexible enough to solve or workaround this situation since we are going to
have a good bunch of new platforms and new versions from here until 2025.


>
> So my view here would be to upload ignition-gazebo once it is ready and
> then see if supporting the old version makes sense.
>
>
I agree. Problem here is that if we upgrade some of the ignition libraries
to new major versions, Gazebo classic has never been tested to compile or
work with the new major versions so it is unknown if the new mix would work
in the same or compatible way with previous mix of Gazebo + supported
Ignition libs major versions.

Thanks.
 Jose

Multiple versions of Ignition libraries for different simulators

[Jose Luis Rivero]

Hi all:

I would like to ask what would the best approach to solve the following
problem (specially interested in the opinions of my fellow ROS team members
here: Jochen, Leo):

One of the robotics simulators, Gazebo version 11, is still supported
upstream until 2025 but no longer releases new versions. We have it in
Debian and it depends on different major versions of Ignition libraries
(these libs are a refactor from the Gazebo code) and other physics
libraries (like DART or Bullet).

Development upstream (Open Robotics) is now focused on the new
ignition-gazebo simulator (considered like the sucesor of Gazebo) which
depends on the whole Ignition family of libraries, some of them are the
same libraries (like ignition-transport) than the ones used by Gazebo.

Problem is that both current versions of Gazebo and ignition-gazebo depend
on different major versions of the ignition libraries (i.e gazebo11 used
ign-transport8 and ignition-gazebo uses ign-transport11). Although upstream
supports side by side installations of the Ignition family we have tried to
have in Debian just one of them to make transitions easier and reduce the
maintenance effort. I'm not sure if this problem can drive us to change our
current practices.

Thanks!

P.D: disclaimer, I work for Open Robotics which is upstream of Ignition
libraries and Gazebo.

Re: Problems with my maintainer upload

[Jose Luis Rivero]

On Thu, Jan 11, 2018 at 6:52 PM, James Clarke <jrt...@debian.org> wrote:

>
> Yes, but you need ssh access to coccia, i.e. be a DD. Looking on there at
> /srv/ftp-master.debian.org/log/current:
>
> > 2018071905|process-upload|dak|ignition-math2_2.9.0+dfsg1-1_source.changes|Error
> while loading changes: No valid signature found. (GPG exited with status
> code 0)
> > gpg: Signature made Tue Jan  9 22:50:01 2018 UTC
> > gpg:using RSA key A08161BBEC1CC063961459035E946C
> 090AFF0427
> > gpg:issuer "jriv...@osrfoundation.org"
> > gpg: Good signature from "Jose Luis Rivero <jriv...@osrfoundation.org>"
> [expired]
> > gpg: WARNING: Using untrusted key!
>
> Your key has expired, or at least the copy in the keyring. Note that the
> keyring is uploaded manually around once a month, so even if you renew
> your key
> and upload it to the keyservers, you won't be able to upload anything for a
> while and will need sponsorship.
>
>
That makes sense. The best way of knowing when the update is done is
probably looking into the keyring repository log, right?
https://anonscm.debian.org/git/keyring/keyring.git/log/

Thanks James.

Problems with my maintainer upload

[Jose Luis Rivero]

Hello all:

Excuse me if the question stupid but I have a problem with one of my
maintainer uploads.

In this case ignition-math2 is the package and the upload is to update
to the 2.9.0 version. After I run dput I get a message of "Processing
..." but never get "ACCEPTED or REJECTED".

Here is the message that arrived to mailing list:
https://lists.alioth.debian.org/pipermail/debian-science-maintainers/2018-January/056854.html

Is there any log or register where I can find what is the problem? Am I
missing something obvious?

Thanks.

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

Re: r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)

[Jose Luis Rivero]

Hello Andreas:

On 11/01/18 15:11, Andreas Tille wrote:
> Hi again,
> 
> On Thu, Jan 11, 2018 at 08:34:09AM +0100, Andreas Tille wrote:
>>>   # Add include paths for git2r
>>>  -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
>>> ${CPPFLAGS}"
>>> -+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
>>> ++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
>>
>> ...
>> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -idirafter 
>> /usr/include/git2  -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
>> -DGIT_OPENSSL -DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL -DGIT_SSH 
>> -DGIT_CURL -DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R 
>>  -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -g  -c git2r_branch.c -o git2r_branch.o
>> git2r_branch.c: In function 'git2r_branch_upstream_canonical_name':
>> git2r_branch.c:407:19: error: 'GIT_BUF_INIT' undeclared (first use in this 
>> function); did you mean 'GIT_REF_OID'?
>>  git_buf buf = GIT_BUF_INIT;
>>^~~~
>>GIT_REF_OID
>> git2r_branch.c:407:19: note: each undeclared identifier is reported only 
>> once for each function it appears in
>> git2r_branch.c:427:11: warning: implicit declaration of function 
>> 'git_buf_join3'; did you mean 'git_buf_set'? 
>> [-Wimplicit-function-declaration]
>>  err = git_buf_join3(
>>^
>>git_buf_set
>> /usr/lib/R/etc/Makeconf:159: recipe for target 'git2r_branch.o' failed
>>
>>
>> This is in
>>
>>/usr/include/git2/buffer.h:#define GIT_BUF_INIT_CONST(STR,LEN) { (char 
>> *)(STR), 0, (size_t)(LEN) }
>>
>> but it seems a different buffer.h is used.
> 
> I dived a bit deeper into this and found this other buffer.h: It is a
> private header from libgit2/src/ and other headers from there are needed
> as well like common.h, cc_compat.h, thread-utils.h and possibly other
> header files.
> 
> That's ... uh, no idea how to call this.  What would you suggest:
> Live with the nasty code copy and just add it to debian/copyright or
> hack around all those usage of private header files.  I've pushed some
> changes to Git[1] which keeps some (not all needed - for instance
> thread-utils.h is missing) but if there is no better idea how to deal
> with this I think I have better things to spent my time on than getting
> rid of a code copy you can not really cleanly get rid of.
> 

I agree with your analysis, the mess of headers that libgit2 is using
IMHO could make the solution (cherry pick only some parts of libgit2)
worse than maintaining the embedded copy.

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

Re: Help with libgit2 needed to strip code copy from r-cran-git2r

[Jose Luis Rivero]

dah .. I sent the reverse patch sorry:

diff --git a/debian/patches/use_debian_packaged_libgit2.patch
b/debian/patches/use_debian_packaged_libgit2.patch
index c716773..ab603cd 100644
--- a/debian/patches/use_debian_packaged_libgit2.patch
+++ b/debian/patches/use_debian_packaged_libgit2.patch
@@ -87,7 +87,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
  if test "x${have_ssh2}" = xyes; then
 -LIBSSH2_CFLAGS="-Ilibgit2/deps/libssh2/include"
 -LIBSSH2_LIBS="-Llibgit2/deps/libssh2/lib -lssh2"
-+LIBSSH2_CFLAGS="-I/usr/include/git2"
++LIBSSH2_CFLAGS="-idirafter /usr/include/git2"
 +LIBSSH2_LIBS="-lgit2 -lssh2"
  fi
  fi
@@ -97,7 +97,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100

  # Add include paths for git2r
 -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
${CPPFLAGS}"
-+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"


On Thu, Jan 11, 2018 at 12:42 AM, Jose Luis Rivero <jriv...@openrobotics.org
> wrote:

> Curiosity drove me to give it a look. From what I understand: libgit2
> seems to be multiplatform and for some of the platforms (this time Windows)
> they are shipping files with the same names that those that we can find in
> /usr/include, in this case inttypes.h. You have include in your patch to
> use the system version of libgit2 an -I/usr/include/git2 which is making
> the compilation to use the inttypes.h from libgit2 (the windows copy)
> instead of the one in /usr/include (which is evaluated the last by the
> compiler).
>
> Something like this patch should work, although I did not test it:
>
> """
> diff --git a/debian/patches/use_debian_packaged_libgit2.patch
> b/debian/patches/use_debian_packaged_libgit2.patch
> index ab603cd..c716773 100644
> --- a/debian/patches/use_debian_packaged_libgit2.patch
> +++ b/debian/patches/use_debian_packaged_libgit2.patch
> @@ -87,7 +87,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
>   if test "x${have_ssh2}" = xyes; then
>  -LIBSSH2_CFLAGS="-Ilibgit2/deps/libssh2/include"
>  -LIBSSH2_LIBS="-Llibgit2/deps/libssh2/lib -lssh2"
> -+LIBSSH2_CFLAGS="-idirafter /usr/include/git2"
> ++LIBSSH2_CFLAGS="-I/usr/include/git2"
>  +LIBSSH2_LIBS="-lgit2 -lssh2"
>   fi
>   fi
> @@ -97,7 +97,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
>
>   # Add include paths for git2r
>  -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
> ${CPPFLAGS}"
> -+CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
> ++CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
>
>   # Add definitions
>   CPPFLAGS="${CPPFLAGS} -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL
> -DLIBGIT2_NO_FEATURES_H"
> """
>
> If use the "-idirafter" option the libgit2 headers are evaluated in the
> last position when invoking the compiler, so the linux system inttypes.h go
> first:
> https://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation
>
>
>
>
>
> On Thu, Jan 11, 2018 at 12:15 AM, Philip Rinn <ri...@inventati.org> wrote:
>
>> Hi,
>>
>> I looked into this as well this evening and didn't really understand what
>> they are
>> doing. Did you ask the upstream authors why they didn't just depend on
>> libgit2 as
>> they did for libssh2, OpenSSL, ...? It's probably easier to understand
>> the problem
>> with their help. [If you don't want to do that I can do...]
>>
>> Best,
>>
>> Philip
>>
>>
>

Re: Help with libgit2 needed to strip code copy from r-cran-git2r

[Jose Luis Rivero]

Curiosity drove me to give it a look. From what I understand: libgit2 seems
to be multiplatform and for some of the platforms (this time Windows) they
are shipping files with the same names that those that we can find in
/usr/include, in this case inttypes.h. You have include in your patch to
use the system version of libgit2 an -I/usr/include/git2 which is making
the compilation to use the inttypes.h from libgit2 (the windows copy)
instead of the one in /usr/include (which is evaluated the last by the
compiler).

Something like this patch should work, although I did not test it:

"""
diff --git a/debian/patches/use_debian_packaged_libgit2.patch
b/debian/patches/use_debian_packaged_libgit2.patch
index ab603cd..c716773 100644
--- a/debian/patches/use_debian_packaged_libgit2.patch
+++ b/debian/patches/use_debian_packaged_libgit2.patch
@@ -87,7 +87,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
  if test "x${have_ssh2}" = xyes; then
 -LIBSSH2_CFLAGS="-Ilibgit2/deps/libssh2/include"
 -LIBSSH2_LIBS="-Llibgit2/deps/libssh2/lib -lssh2"
-+LIBSSH2_CFLAGS="-idirafter /usr/include/git2"
++LIBSSH2_CFLAGS="-I/usr/include/git2"
 +LIBSSH2_LIBS="-lgit2 -lssh2"
  fi
  fi
@@ -97,7 +97,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100

  # Add include paths for git2r
 -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
${CPPFLAGS}"
-+CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
++CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"

  # Add definitions
  CPPFLAGS="${CPPFLAGS} -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL
-DLIBGIT2_NO_FEATURES_H"
"""

If use the "-idirafter" option the libgit2 headers are evaluated in the
last position when invoking the compiler, so the linux system inttypes.h go
first:
https://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation





On Thu, Jan 11, 2018 at 12:15 AM, Philip Rinn  wrote:

> Hi,
>
> I looked into this as well this evening and didn't really understand what
> they are
> doing. Did you ask the upstream authors why they didn't just depend on
> libgit2 as
> they did for libssh2, OpenSSL, ...? It's probably easier to understand the
> problem
> with their help. [If you don't want to do that I can do...]
>
> Best,
>
> Philip
>
>

Re: Debian science robotics subgroup

[Jose Luis Rivero]

On Wed, Jan 10, 2018 at 3:29 PM, Leopold Palomo-Avellaneda  wrote:

>
> The only thing that might be worth considering, is whether you
> > think an own Debian Robotics Blend would fly (in terms of contributors
> > and number of packages).  In this case a separate packaging team might
> > make sense.
> >
>
> Well, Debian Science Team has 886 projects (source packages?). It's a big
> umbrella for all scientific packages. Maybe some subcategories (subgroups
> or
> whatever) would attract the people for a more specific project than a
> generic
> one. The problem them would be the borders, where a package/project goes
> to one
> place or other.
>
> About the robotic group  I really don't know. Jochen? Jose?
>
>
Thanks Leo for the proposal. I don't have an strong opinion on this topic
since I don't have the experience of many years that most of you have
organizing the debian-science group, so I'm happy to read others opinions
and suggestion and follow whatever you collectively decide is good.

Re: Please categorise your packages for the Debian Science metapackages

[Jose Luis Rivero]

On 04/01/17 15:50, Andreas Tille wrote:
> Hi,
> 
> as in every release cycle I'm trying to verify that every package
> maintained in Debian Science team is properly categorised in our Blends
> tasks.  If a package is just a predependency for some other scientific
> software I can add it to a blacklist of packages that should not show
> up in the Debian Science metapackages explicitly.  I have uploaded the
> list of not yet categorised (not yet blacklisted) source packages to
> 
>http://blends.debian.net/tmp/debian-science.txt
> 

Thanks Andreas for the reminder. I've updated gazebo/sdformat versions
and included gazebo into the simulation category. git format-patch attached.

Happy new year.

-- 
Jose Luis Rivero <jriv...@osrfoundation.org>
>From 60907a695f95ec9290c040e318361228287f858d Mon Sep 17 00:00:00 2001
From: Jose Luis Rivero <jriv...@osrfoundation.org>
Date: Thu, 5 Jan 2017 15:17:18 +0100
Subject: [PATCH] Update gazebo and sdformat versioned packages.

Update gazebo and sdformat versioned pacakges to the latest version and
added gazebo to the tasks/simulation blend.
---
 tasks/robotics | 2 +-
 tasks/robotics-dev | 4 ++--
 tasks/simulations  | 2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tasks/robotics b/tasks/robotics
index a09b595..b85b7c0 100644
--- a/tasks/robotics
+++ b/tasks/robotics
@@ -176,7 +176,7 @@ Pkg-Description: Point Cloud Library
  large consortium of researchers and engineers around the world. It is
  written in C++ and released under the BSD license.
 
-Depends: gazebo5
+Depends: gazebo7
 
 Depends: openrave
 Homepage: http://openrave.org/
diff --git a/tasks/robotics-dev b/tasks/robotics-dev
index ec6200c..b0cf433 100644
--- a/tasks/robotics-dev
+++ b/tasks/robotics-dev
@@ -29,7 +29,7 @@ Depends: liburdfdom-dev, liburdfdom-headers-dev
 
 Depends: libslicot-dev
 
-Depends: libsdformat-dev
+Depends: libsdformat4-dev
 
 Depends: libconsole-bridge-dev
 
@@ -37,7 +37,7 @@ Depends: libcomedi-dev, python-comedilib
 
 Depends: libccd-dev
 
-Depends: libgazebo5-dev
+Depends: libgazebo7-dev
 
 Depends: libsimbody-dev
 
diff --git a/tasks/simulations b/tasks/simulations
index 58201f4..d05aad9 100644
--- a/tasks/simulations
+++ b/tasks/simulations
@@ -33,6 +33,8 @@ Depends: python3-woo | python-woo
 
 Depends: libceres-dev
 
+Depends: gazebo7
+
 Suggests:  ceres-solver-doc
 
 Depends: python-escript | python3-escript | python-escript-mpi | python3-escript-mpi
-- 
2.7.4

debdiff addressed to strecth-staging

[Jose Luis Rivero]

Hi all:

I've received the bug below that attaches a debdiff that includes a
modification in the changelog with the header:

+gazebo (7.3.0+dfsg-3+rpi1) stretch-staging; urgency=medium

Two quick questions:
 * what does the rpi suffix mean? (raspberry pi?)
 * I assume that strech-staging is a valid distribution and I can
   directly upload the change to it, can't I?

Thanks.

 Forwarded Message 
Subject: Bug#837121: gazebo: please restrict libkido-dev
(build-)dependency to architectures where it is available.
Resent-Date: Thu, 08 Sep 2016 23:39:02 +
Resent-From: Peter Green 
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: Debian Science Maintainers

Date: Fri, 09 Sep 2016 00:35:25 +0100
From: Peter Green 
Reply-To: Peter Green , 837...@bugs.debian.org
To: Debian Bug Tracking System 

Package: gazebo
Version: 7.3.0+dfsg-3
Severity: serious
Tags: patch

The most recent version of gazebo added a build-dependency on
libkido-dev to the source package and added a binary on libkido-dev to
libgazebo7-dev

No mention of this was made in the changelog and no other changes in the
upload seem to be related but
https://anonscm.debian.org/git/debian-science/packages/gazebo.git/commit/?id=80f9a218ccebb32258812afdf1cce6b50ab88126
indicates this was to add support for a new feature.

libkido-dev is only available on a handful of architectures. As a result
this new (build-)dependency is blocking the migration of the new version
of the package (and hence the FTBFS fix) to testing.

The attatched patch restricts the (build-)dependencies on libkido-dev to
the architectures where it is actually available (amd64, arm64, i386,
ppc64el and alpha)

diff -Nru gazebo-7.3.0+dfsg/debian/changelog gazebo-7.3.0+dfsg/debian/changelog
--- gazebo-7.3.0+dfsg/debian/changelog  2016-08-31 17:57:53.0 +
+++ gazebo-7.3.0+dfsg/debian/changelog  2016-09-07 15:06:23.0 +
@@ -1,3 +1,10 @@
+gazebo (7.3.0+dfsg-3+rpi1) stretch-staging; urgency=medium
+
+  * Restrict (build-)dependency on libkido-dev to architectures where that 
package
+is actually available (amd64, arm64, i386, ppc64el and alpha). 
+
+ -- Peter Michael Green   Wed, 07 Sep 2016 15:06:23 
+
+
 gazebo (7.3.0+dfsg-3) unstable; urgency=medium
 
   [ Jochen Sprickerhof ]
diff -Nru gazebo-7.3.0+dfsg/debian/control gazebo-7.3.0+dfsg/debian/control
--- gazebo-7.3.0+dfsg/debian/control2016-08-30 22:54:59.0 +
+++ gazebo-7.3.0+dfsg/debian/control2016-09-07 15:06:07.0 +
@@ -45,7 +45,7 @@
libbullet-dev,
libsimbody-dev,
libsimbody-dev (<< 4.0.0),
-   libkido-dev,
+   libkido-dev [amd64 arm64 i386 powerpc alpha],
libgdal-dev,
ruby-ronn,
libgtest-dev
@@ -138,7 +138,7 @@
  libignition-math2-dev,
  libbullet-dev,
  libsimbody-dev,
- libkido-dev,
+ libkido-dev [amd64 arm64 i386 powerpc alpha],
  libgazebo7 (= ${binary:Version}),
  gazebo7-common (= ${source:Version}),
  gazebo7-plugin-base (= ${binary:Version}),

Re: How to filter bugmail from my packages

[Jose Luis Rivero]

Thanks Mattia, Julien. The links were really helpful.

On 31/08/16 20:31, Julien Puydt wrote:
> Hi,
> 
> On 31/08/2016 19:30, Mattia Rizzolo wrote:
>> On Wed, Aug 31, 2016 at 07:22:31PM +0200, Jose Luis Rivero wrote:
>>> According with our debian-science policy[1] I set the following fields
>>> in the control files of my packages:
>>>
>>> """
>>>  Maintainer: Debian Science Maintainers <debian-science-maintainers@...>
>>>  Uploaders: Jose Luis Rivero <jrivero@..>
>>> """
>>
>> of course
>>
>>> The problem with this is that I don't know how can I filter from all the
>>> mails that go to debian-science-maintainer those who come from my
>>> maintained packages.
>>>
>>> Any idea how this could be done?
>>
>> if you use a sane MUA that let you filter for email headers, you can
>> filter for X-Debian-PR-Source (iirc that one is set from the BTS, so
>> it'll be in all mails from it).
>>
>> Otherwise you can avoid being subscribed to
>> debian-science-maintainers@lado and subscribe individually to your
>> packages through tracker.d.o (which I suggest wholeheartedly anyway),
>> there you could filter email for your packages using a wider range of
>> headers, even:
>> https://www.debian.org/doc/manuals/developers-reference/ch04.en.html#pkg-tracker-mail-filtering
>>
>>
> 
> You can also take the habit of going to:
> https://qa.debian.org/developer.php
> (well, a direct link to the page with your email)
> 
> there's also:
> https://udd.debian.org/dmd/
> (again, a direct link to the page with your email)
> 
> That makes managing a good number of packages quite easy.
> 
> Snark on #debian-science
> 


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

How to filter bugmail from my packages

[Jose Luis Rivero]

Hi all:

According with our debian-science policy[1] I set the following fields
in the control files of my packages:

"""
 Maintainer: Debian Science Maintainers <debian-science-maintainers@...>
 Uploaders: Jose Luis Rivero <jrivero@..>
"""

The problem with this is that I don't know how can I filter from all the
mails that go to debian-science-maintainer those who come from my
maintained packages.

Any idea how this could be done?
Thanks.

[1]
http://debian-science.alioth.debian.org/debian-science-policy.html#idm45916846962880

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

Re: Sponsoring for new package inside debian-science

[Jose Luis Rivero]

On 29/07/16 09:18, Andreas Tille wrote:
> Hi again,
> 
> I had a look into kido and ignition-msgs.  I removed some boilerplate in
> d/rules from ignition-msgs (please git pull) and noticed that pristine-tar
> branch is missing.  Please push all branches or create the missing branch.
> 

Ouk, sorry about that. I've implemented a check for the pristine-tar
branch and fixes most of the Lintian warnings.

http://build.osrfoundation.org/view/All/job/ignition-msgs-pkg_builder-master-debian_sid-amd64/23/console

Changes are in git. Thanks Andreas!

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

Sponsorship needed for several updates

[Jose Luis Rivero]

Hi all:

I've updated most of my currently maintained packages. Some of them have
bumped the ABI/API and this have triggered migration in package names
that needs a DD approval to go into the NEW queue. Usually Anton is
sponsoring my updates but I hope that he is enjoying his deserved
holidays these days so if anyone in debian-science can give them a look,
that would be awesome.

All the pkgs are in our git and I use our foundation build farm for
testing the generation of the packages. All them should be lintian clean
(except for recent warning with testsuite-triggers which I think is a
false positive). Here is the list:

1. fcl [0.4 -> 0.5]
http://build.osrfoundation.org/view/main/view/debian/job/fcl-pkg_builder-master-debian_sid-amd64/

2. urdfdom and urdfdom-header [0.4.1 -> 1.0]
http://build.osrfoundation.org/job/urdfdom-headers-pkg_builder-master-debian_sid-amd64/19/
urdfdom requires first to include urdfdom-headers (this latest one
should not require NEW Queue)

3. ignition-transport [0.9.0-3 -> 1.3]
http://build.osrfoundation.org/job/ignition-transport-pkg_builder-master-debian_sid-amd64/34

Thanks!

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

Re: gazebo: Don't depend on robot-player-dev (libgazebo5-dev)

[Jose Luis Rivero]

On 11/09/2015 08:22 PM, Anton Gladky wrote:
> Hi Peter,
> 
> 2015-11-09 20:16 GMT+01:00 Paul Gevers <elb...@debian.org>:
>> Could we please agree on the way how to make Debian slightly better (I 
>> propose to
>> remove player).
> 
> Sure, I can prepare such an upload. Jose, are you OK with that?
> 

Oh, I promised to the player maintainer to help with this package as it
has been quite used by the robotics community some years ago and I think
that it has still some users (part of them from gazebo support).

Looks like patches are floating around to fix the serious bugs. Would
you mind if I import it to debian-science and patch the whole thing?

Thanks.



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

Re: examples of gtest done right in Debian

[Jose Luis Rivero]

On 08/05/2015 09:27 PM, Anton Gladky wrote:
 2015-08-05 20:18 GMT+02:00 Jochen Sprickerhof
 debian-scie...@jochen.sprickerhof.de
 mailto:debian-scie...@jochen.sprickerhof.de:
 
 We have a FindGtest.cmake module in PCL, maybe that would be interesting
 for Gazebo as well:
 
 
 https://github.com/PointCloudLibrary/pcl/blob/master/cmake/Modules/FindGtest.cmake
 
 
 Thanks Jochen,
 
 there is system-installed FindGtest.cmake, which is wrong, because
 it looks for a pre-built gtest. But your cmake-file looks good.
 
 Jose, if you want and have a time, you can try to integrate it into
 gazebo.
 

Sure:
http://anonscm.debian.org/cgit/debian-science/packages/gazebo.git/commit/?id=f1b941f1e30dbbe30d7015413cebb5f1d96592bd

@Jochen: could you fix the FindGtest.cmake comment at the beginning,
when it says GTEST_SRC, probably want to say GTEST_SRC_DIR.

Thanks.


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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c3f1fb.8000...@osrfoundation.org

Re: examples of gtest done right in Debian

[Jose Luis Rivero]

Hi Ghislain:

On 08/05/2015 01:30 PM, Ghislain Vaillant wrote:
 Hi Anton,
 
 That sounds like a good example, although not exactly what I had in mind.
 
 Please correct me if I am wrong but I am assuming from this patch that
 gazebo was compiling gtest from a vendorized copy? 

Right.

 The patch then
 consists in pointing gazebo to a different location for the gtest source
 files. So, gazebo was already following the upstream gtest
 recommendations, which made patching for Debian quite simple.

Right.

 The upstream projects I am dealing with rely on the fact that a
 pre-compiled version already exists in the system and the latter is
 detectable via find_package. For this, I expect (perhaps wrongfully)
 patching to be much more invasive.

I agree with your analysis. You probably will need to patch and compile
gtest together with your software.

 Hence myself asking whether such case has already been dealt with in the
 archive, so I don't spend too much time trying things.

I don't know about any helper provided by debian packaging utilities to
avoid every maintainer the task of creating the commands to compile and
use gtest with your building system.

 Thanks,
 Ghis
 
 
 On 05/08/15 10:15, Anton Gladky wrote:
 Hi Ghislain,

 gazebo was fixed recently to use a system-installed
 gtest [1].

 [1]
 http://anonscm.debian.org/cgit/debian-science/packages/gazebo.git/tree/debian/patches/0002_use_system_gtest.patch


 Cheers


 Anton

 2015-08-05 11:12 GMT+02:00 Ghislain Vaillant ghisv...@gmail.com
 mailto:ghisv...@gmail.com:

 Hi everyone,

 I am currently dealing with a few upstream projects which rely on
 gtest for building their test suite in cmake.

 Unfortunately, and unlike upstream recommendation to *not* rely
 precompiled binaries of gtest [1], upstream uses find_package(gtest)
 and links its test suite with the expected found libgtest and
 libgtest_main shared objects.

 [1]

 https://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog


 Could you guys please point me to what you consider good examples of
 gtest integration with cmake and corresponding patching in Debian to
 use the gtest package within the archive?

 Best regards,
 Ghislain


 --
 To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
 mailto:debian-science-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org mailto:listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c1d370.8070...@gmail.com


 
 


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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c22abf.40...@osrfoundation.org

Re: Gazebo is not installable

[Jose Luis Rivero]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/28/2015 11:36 PM, Leopold Palomo-Avellaneda wrote:
 HI,
 
 please, Jose do:
 
 - create a new version of the package gazebo: 5.0.1+dfsg-2 - delete
 robot-player-dev build dependency. Gazebo5 doesn't need it. - close
 bug #787007. It'll be automatically closed when you build a new 
 version of the package. - push your changes to git. - built the
 package, test, make your own checks.
 

Done. Thanks for the help Leo.

 Anton please,
 
 - built the new version of gazebo and upload it to debian.
 
 There is really a problem with the player-package, which prevents
 migrating gazebo into testing. So, if we want to have gazebo in
 testing #726561 should be fixed.
 
 It's an stupid bug, not closed because any esoteric reason that
 have made that gazebo3 wasn't in Jessie.
 
 Cheers
 
 Leo
 
 Cheers
 
 Anton
 
 2015-05-28 19:37 GMT+02:00 Jose Luis Rivero
 jriv...@osrfoundation.org:
 Hey Anton:
 
 I believe that to fix the problem that Leo is describing in his
 mail, we just need to generate a new version of Gazebo and it
 will built against libsimbody-3.5 without a major problem.
 
 If it is just a matter of generate a 5.0.1+dfsg-2 (there is no
 version limitation in the control file, just simbody 3.X
 series) , that is totally fine for me. Please go ahead. If you
 need me to modify anything, please point me to it.
 
 Thanks Leo, Jochen for reporting.
 
 On Wed, May 27, 2015 at 5:19 PM, Leopold Palomo-Avellaneda
 
 l...@alaxarxa.net wrote:
 El Dimecres, 27 de maig de 2015, a les 11:35:33, Leopold 
 Palomo-Avellaneda va
 
 escriure:
 Hi,
 
 I don't know what is wrong with gazebo but now the
 situation is that this package is not installable in a sid
 environment.
 
 The situation was that the package uploaded by Anton was
 built using libsimbody3.4. However, this package have been
 upgraded to simbody3.5, deleting the old one.
 
 I have compiled and used gazebo5 with simbody3.5 and works
 without any noticeable issue.
 
 So, please could you do something?
 
 Also, please could you delete robot-player-dev dependency. I
 think that it doesn't need that package.
 
 Regards,
 
 Leopold
 
 
 -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia 
 - A: Because it messes up
 the order in which people normally read text. Q: Why is
 top-posting such a bad thing? A: Top-posting. Q: What is the
 most annoying thing in e-mail?
 


- -- 
Jose Luis Rivero jriv...@osrfoundation.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVakQ2AAoJEF6UbAkK/wQnnmMH/j+H2B/d3/7RCuvReMIA2gCP
lpzCyupu0Y+N9b+9yw1rDz73cT0fuXYPUP7croDZRsrH5EUWybe4qNNTm5RBKbhq
2FGfe84yxRoPZSG1M2QR32CHYiO3lFyvuUdyQatf/XAx500noNmrruZJj0yxFVc1
ikiLCaNY1yeM93SlWRm9VbnrptBtlWtlL1eZr22H1KYmbLlVv+k7Pa5pqiicUrI4
5VjxyqrghppV5POSZDaOdCfNx+RNwb8WknCO7zzn+bwRfRcbgiibqTDrU4XULgyJ
w7fmP3JSkK/XEvxl6mhOv3yp2mlLIzckuP/kRvsEIl8HEm5t/Q7rKNZ0d+ks2As=
=P68X
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/556a4436.1090...@osrfoundation.org

Re: Gazebo is not installable

[Jose Luis Rivero]

Hey Anton:

I believe that to fix the problem that Leo is describing in his mail, we
just need to generate a new version of Gazebo and it will built against
libsimbody-3.5 without a major problem.

If it is just a matter of generate a 5.0.1+dfsg-2 (there is no version
limitation in the control file, just simbody 3.X series) , that is totally
fine for me. Please go ahead. If you need me to modify anything, please
point me to it.

Thanks Leo, Jochen for reporting.

On Wed, May 27, 2015 at 5:19 PM, Leopold Palomo-Avellaneda l...@alaxarxa.net
 wrote:

 El Dimecres, 27 de maig de 2015, a les 11:35:33, Leopold Palomo-Avellaneda
 va
 escriure:
  Hi,
 
  I don't know what is wrong with gazebo but now the situation is that this
  package is not installable in a sid environment.
 
  The situation was that the package uploaded by Anton was built using
  libsimbody3.4. However, this package have been upgraded to simbody3.5,
  deleting the old one.
 
  I have compiled and used gazebo5 with simbody3.5 and works without any
  noticeable issue.
 
  So, please could you do something?
 
 Also, please could you delete robot-player-dev dependency. I think that it
 doesn't need that package.

 Regards,

 Leopold


 --
 --
 Linux User 152692 GPG: 05F4A7A949A2D9AA
 Catalonia
 -
 A: Because it messes up the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing in e-mail?

Re: Do I need specific binary package relationships in this case ?

[Jose Luis Rivero]

Hello Ghislain:

On 15/01/15 18:27, Ghislain Vaillant wrote:
 Hi everyone,
 
 I am currently packaging an update of libnfft. The new version brings
 along support for multi-precision, which means more binaries can be
 created and a transition should be occuring between the old and new
 package layout.
 
 Version 3.2 is currently in the archive and provides:
 - libnfft3-1  -- double precision version
 - libnfft3-dev  -- headers and dev stuff
 
 Version 3.3, which also got a sodump, now builds:
 - libnfft3-double2  -- double precision version
 - libnfft3-single2  -- single precision version
 - libnfft3-long2  -- long double precision version
 - libnfft3-dev  -- headers and dev stuff
 - libnfft3-2  -- transitional package, should probably install single,
 double and long versions
 
 Do I need to provide any specific breaks / replaces relationship between
 the packages to make sure the upgrade path is properly covered ?
 

When I faced this same situation in the past, I found really useful the
following documentation pages:

 - https://wiki.debian.org/PackageTransition
 - https://wiki.debian.org/Renaming_a_Package

Hope it helps. Kind Regards.

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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b7fb3a.2030...@osrfoundation.org

Re: Fwd: Do I need specific binary package relationships in this case ?

[Jose Luis Rivero]

On 15/01/15 19:12, Ghislain Vaillant wrote:
 
 2015-01-15 17:39 GMT+00:00 Jose Luis Rivero jriv...@osrfoundation.org
 mailto:jriv...@osrfoundation.org:
 
 Hello Ghislain:
 
 On 15/01/15 18:27, Ghislain Vaillant wrote:
  Hi everyone,
 
  I am currently packaging an update of libnfft. The new version brings
  along support for multi-precision, which means more binaries can be
  created and a transition should be occuring between the old and new
  package layout.
 
  Version 3.2 is currently in the archive and provides:
  - libnfft3-1  -- double precision version
  - libnfft3-dev  -- headers and dev stuff
 
  Version 3.3, which also got a sodump, now builds:
  - libnfft3-double2  -- double precision version
  - libnfft3-single2  -- single precision version
  - libnfft3-long2  -- long double precision version
  - libnfft3-dev  -- headers and dev stuff
  - libnfft3-2  -- transitional package, should probably install single,
  double and long versions
 
  Do I need to provide any specific breaks / replaces relationship
 between
  the packages to make sure the upgrade path is properly covered ?
 
 
 When I faced this same situation in the past, I found really useful the
 following documentation pages:
 
  - https://wiki.debian.org/PackageTransition
  - https://wiki.debian.org/Renaming_a_Package
 
 Hope it helps. Kind Regards.
 
 
 
 These are great resources. Thanks for sharing.
 
 Am I right to assume case #8 in [1] ?
 

I think that #8 is the your case, yes.

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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b84979.8040...@osrfoundation.org

Re: UNRELEASED when searching for a sponsor (Was: RFS: eclib -- library and tools for elliptic curves)

[Jose Luis Rivero]

On 08/04/2014 05:14 PM, Andreas Tille wrote:

 The fact that the package was uploaded is then indicated in the vcs by
 the debian revision tag which is created by the sponsor.

 [1] http://pet.alioth.debian.org/
 
 Unfortunately this list is desperately outdated (I know for sure that
 PET does not work for Debian Med any more since the last PET rewrite
 :-()
 
 [2] http://pet.debian.net/pkg-perl/pet.cgi

 One can of course do it differently, but this is why I considered
 removing UNRELEASED when one is ready a standard practice.
 
 I agree that this workflow has some advantages *IF* PET is used and I
 would really welcome if we could implement PET for Debian Science as
 well (any volunteer??)
 

I'm volunteer. Andreas, what needs to be done?

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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dfa4e9.3040...@osrfoundation.org

Re: octomap_1.6.6-1_amd64.changes REJECTED

[Jose Luis Rivero]

On 07/31/2014 02:06 PM, Andreas Tille wrote:
 
 That's currently my most hated lintian warning - lintian is simply wrong
 here since uscan knows the Files-Excluded feature.  There are some
 devscripts/uscan bugs/discussions around this.
 
 Does something like the following patch work for your problem?

 diff --git a/debian/watch b/debian/watch
 index ff4a10c..9a324ac 100644
 --- a/debian/watch
 +++ b/debian/watch
 @@ -3,7 +3,5 @@
  version=3

  # For GitHub projects you can use the tags page:
 -opts=uversionmangle=s/$/+dfsg/ \
 +opts=dversionmangle=s/\+dfsg// \
   https://github.com/OctoMap/octomap/tags .*/v?(\d\S*)\.tar\.gz
 -

 Good!!
 
 ... to suppress the lintian warning ... but bad if it comes to
 downloading a properly named orig tarball.  Please revert this and
 ignore the lintian warning.
  

Ouch, good to know. Thanks for the trick Andreas.

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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53db93d2.2050...@osrfoundation.org

Re: octomap_1.6.6-1_amd64.changes REJECTED

[Jose Luis Rivero]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Leo:

On 07/31/2014 12:43 AM, Leopold Palomo-Avellaneda wrote:
 Hi Andreas,
 
 El Dimarts, 29 de juliol de 2014, a les 16:40:21, Andreas Tille va
 escriure: [...]
 
 Once you consider your work finished, you could simply ping me
 that you are ready.  Just make sure you keep the changelog entry
 targeting at UNRELEASED and everybody knows that it is work in
 progress.
 
 I have worked in the octomap package following the ftp-master
 advices. I have a lintian warning  about:
 
 debian-watch-file-should-dversionmangle-not-uversionmangle
 

Does something like the following patch work for your problem?

diff --git a/debian/watch b/debian/watch
index ff4a10c..9a324ac 100644
- --- a/debian/watch
+++ b/debian/watch
@@ -3,7 +3,5 @@
 version=3

 # For GitHub projects you can use the tags page:
- -opts=uversionmangle=s/$/+dfsg/ \
+opts=dversionmangle=s/\+dfsg// \
  https://github.com/OctoMap/octomap/tags .*/v?(\d\S*)\.tar\.gz
- -
- -

- -- 
Jose Luis Rivero jriv...@osrfoundation.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT2YTuAAoJEF6UbAkK/wQn+3QIAOFwgK9iJBWtia3tXndGAYWC
ySmTP4OzhuZuhrY0gnRErqZ4T8Q2W5iMesGcNNSCrUS5wwdrxwJ+u2VkIKf4cqvl
B8tRR6EXhoXabaCpwsohZM5iAsXUPjPkAAEFzt54YmFCgjwjniZ6ztOZOgzyMoe+
+Q2aPY66U2GlLQO2+r0LrytrlYt73yOgD5/nGLLAg+DOIO9b7jbdyGt7RFw+hf0W
f1Uu9KWzrm1zqyP6W6O237vNHvxyixdDLT6odS1LvTNmwaN2orsDfc9/7wE3s0bL
nfh/vjONpG9G8TPN+M8cZxNprxG9ErLiRZj+3mVaiRpxcQ2gasTb9NPvsi7udg8=
=iz/C
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d984ee.1070...@osrfoundation.org

[sponsor needed] Simbody - Multibody dynamics API

[Jose Luis Rivero]

Hi all:

I would like to propose the inclusion of a new robotics package, Simbody.

* Web: https://simtk.org/home/simbody/
* Project description: Simbody is a SimTK toolset providing general
multibody dynamics capability, that is, the ability to solve Newton's
2nd law F=ma in any set of generalized coordinates subject to arbitrary
constraints. Simbody is provided as an open source, object-oriented C++
API and delivers high-performance, accuracy-controlled
science/engineering-quality results.

Upstream is very kind and responsive and is always open to suggestions
about how to improve the management of the project. They are quite happy
about having the project into debian:
- https://github.com/simbody/simbody/issues/49

The package is in our git repository[1] but has a couple of lintian
error/warning, I sent a mail[2] on Friday about this. Feedback is very
welcome.

As usual, the blends patch for robotics:

diff --git a/tasks/robotics-dev b/tasks/robotics-dev
index 7d187bb..c6af804 100644
--- a/tasks/robotics-dev
+++ b/tasks/robotics-dev
@@ -32,3 +32,5 @@ Depends: libconsole-bridge-dev
 Depends: libcomedi-dev, python-comedilib

 Depends: libccd-dev
+
+Depends: libsimbody-dev

[1]
http://anonscm.debian.org/gitweb/?p=debian-science/packages/simbody.git;a=summary
[2]
http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2014-April/024167.html

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


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5342b80f.1020...@osrfoundation.org

Re: Looking for a sponsor for some robotics related packages

[Jose Luis Rivero]

Hello Andreas:

On 01/15/2014 10:53 AM, Andreas Tille wrote:

Hi Jose,

On Wed, Jan 15, 2014 at 02:29:11AM +0100, Jose Luis Rivero wrote:

Please, prepare git-patch for this debian-science meta-package  [1]. Add all of
these 4 packages.

[1] http://anonscm.debian.org/gitweb/?p=blends/projects/science.git



I could not find exactly the place were I should add sdformat nor
any documentation related to the procedure


The long answer is

 http://blends.debian.org/blends



Got it, thanks. Do you that it could help new people like to write a 
minimal README on the repository explaining in a few steps how to make 
the correct changes to include new packages?



so I just use the force and follow my instinct.


Valid apporach - but leaded to wrong result. ;-)



That was completely expected, I have quite bad jedi skills :)

Thanks for the long explanation, indeed it helps me a lot to understand 
how it works. All makes sense to me. Just a little detail:


[snip]

...
OK, took over

$ git diff
diff --git a/tasks/robotics b/tasks/robotics
index f7b7724..db50edf 100644
--- a/tasks/robotics
+++ b/tasks/robotics
@@ -207,3 +207,13 @@ WNPP: 706133
  Suggests: libcoin60-runtime, libvtk5.4

  Suggests: octave, gnuplot
+
+Depends: console-bridge
+Homepage: https://github.com/ros/console_bridge
+Responsible: Jose Luis Rivero jriv...@osrfoundation.org
+License: BSD-3-clause
+Pkg-Description: Console Bridge Library
+ ROS-independent, pure CMake (i.e. non-catkin and non-rosbuild
+ package) that provides logging calls that mirror those found in
+ rosconsole, but for applications that are not necessarily using ROS.
+


Please note:  This assumes that the *binary* package will be named
console-bridge (also see below)!



Which is wrong since console-bridge is a library, no console-bridge as 
such. console-bridge is different from the other packages since it has 
been already uploaded. But I believe that, in the same way that you did 
for liburfdom we should add it as Depends: libconsole-bridge-dev in 
the corresponding tasks/robotics-dev, right?


Thanks again Andreas.

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


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d6bc20.60...@osrfoundation.org

Re: Looking for a sponsor for some robotics related packages

[Jose Luis Rivero]

On 01/13/2014 06:35 PM, Anton Gladky wrote:

Hi Jose,

2014/1/11 Jose Luis Rivero jriv...@osrfoundation.org:

I'm done with upstream. Green light by my side to upload urdfdom,
urdfdom-headers and sdformat, if the case of you find them in a good shape.


urdfdo* should be repacked due to dfsg. But get-orig-source as far as I see
just downloads them without removing non-dfsg files. Please, describe also
in README.source what exactly was removed.


You were right, I did not add instructions to clean the upstream 
sources. Instead of that, I followed Andreas' suggestion from and use 
the Files-Excluded in debian/copyright.


In the case of urdfdom-headers, dfsg is not needed anymore since 
upstream change the repository (now releases are free of VCS files). 
Next version won't need the dfsg process.



BTW, thanks for taking care of console-bridge. Double checking the QA
page I found that if fails to build in some platforms[1] due to problem
with symbol checking. How would you recommend to fix this? Optional symbols?


Sorry, I can not help you on that. I am personally not using symbols in any
of my libs.


After Thomas' suggestion I removed all symbols support from my packages. 
I updated the already released console-bridge debian release -2 after 
removed the symbols support.



I am still not able to download sdformat. Have you talked to upstream?



It took a bit more than expected but the download section should be now 
working. You will see that watch file is looking in to gazebosim.org 
instead of sdformat.org but this is right. I use to do the releases for 
sdformat and are stored in there.



Please, prepare git-patch for this debian-science meta-package  [1]. Add all of
these 4 packages.

[1] http://anonscm.debian.org/gitweb/?p=blends/projects/science.git



I could not find exactly the place were I should add sdformat nor any 
documentation related to the procedure so I just use the force and 
follow my instinct. I only add to debian-science-tasks.desc the 
libsdformat-dev. This package should install as dependency the whole 
family (-dev + lib) urdfdom and console-bridge.


Anton, Andreas, Thomas thanks for the help.
Regards,

diff --git a/debian-science-tasks.desc b/debian-science-tasks.desc
index 75f074a..9d72fa5 100644
--- a/debian-science-tasks.desc
+++ b/debian-science-tasks.desc
@@ -1340,6 +1340,7 @@ Packages: list
  libode-dev
  morse-simulator
  robot-player
+ libsdformat-dev

 Task: science-simulations
 Section: debian-science
diff --git a/tasks/robotics b/tasks/robotics
index f7b7724..1147a49 100644
--- a/tasks/robotics
+++ b/tasks/robotics
@@ -207,3 +207,47 @@ WNPP: 706133
 Suggests: libcoin60-runtime, libvtk5.4

 Suggests: octave, gnuplot
+
+Depends: console-bridge
+Homepage: https://github.com/ros/console_bridge
+Responsible: Jose Luis Rivero jriv...@osrfoundation.org
+License: BSD-3-clause
+Pkg-Description: Console Bridge Library
+ ROS-independent, pure CMake (i.e. non-catkin and non-rosbuild
+ package) that provides logging calls that mirror those found in
+ rosconsole, but for applications that are not necessarily using ROS.
+
+Depends: urdfdom
+Homepage: https://github.com/ros/urdfdom
+Responsible: Jose Luis Rivero jriv...@osrfoundation.org
+License: BSD-3-clause
+Pkg-Description: URDF DOM - model library
+ The URDF (U-Robot Description Format) library provides core data
+ structures and a simple XML parsers for populating the class data
+ structures from an URDF file.
+ .
+ This package contains the URDF DOM model library.
+
+Depends: urdfdom-headers
+Homepage: https://github.com/ros/urdfdom_headers
+Responsible: Jose Luis Rivero jriv...@osrfoundation.org
+License: BSD-3-clause
+Pkg-Description: URDF DOM - header files
+ The URDF (U-Robot Description Format) library provides core data
+ structures and a simple XML parsers for populating the class data
+ structures from an URDF file.
+ .
+ This package contains the headers files.
+



Thanks,

Anton




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


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d5e467.4020...@osrfoundation.org

Re: Looking for a sponsor for some robotics related packages

[Jose Luis Rivero]

Hi Anton:

On 01/09/2014 06:46 PM, Jose Luis Rivero wrote:
 On 01/08/2014 08:27 PM, Anton Gladky wrote:
...
 
 BTW, I'm double checking with urdfdom upstream the policy on ABI/API,
 please hold on the upload until I'm sure about how is this going to be
 handled.
 

I'm done with upstream. Green light by my side to upload urdfdom,
urdfdom-headers and sdformat, if the case of you find them in a good shape.

BTW, thanks for taking care of console-bridge. Double checking the QA
page I found that if fails to build in some platforms[1] due to problem
with symbol checking. How would you recommend to fix this? Optional symbols?

Have a good weekend.

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

 Thanks very much for the review.
 Regards,
  Jose.
 
 Best regards,

 Anton


 2014/1/8 Jose Luis Rivero jriv...@osrfoundation.org:
 Hi Anton:

 On 01/08/2014 08:03 AM, Anton Gladky wrote:
 Hi,

 packages look OK. I will try to upload them in the evening.


 Thanks very much for the quick response. Impressive. Please let me know
 of any problem you want me to fix.

 Why do you have this line in all debian/rules?
 .PHONY: override_dh_auto_clean override_dh_strip


 AFAIK, debian/rules is invoke in the same way than a standard Makefile,
 so .PHONY targets benefits could also apply there.

 Current Standards-Version is 3.9.5 now.

 Do you want me to update this in the three packages? BTW, should Lintian
 warn about this kind of things?

 Regards,
  Jose.

 Regards,

 Anton


 2014/1/7 Jose Luis Rivero jriv...@osrfoundation.org:
 Dear science team:

 During the last month, as part of my work for the OSRF[1], I've been
 working with Thomas Moulard (thanks!) in bringing some of our usual
 robotics software packages into a good shape for being included into 
 debian.

 I believe that now they are in a good shape to start the process. These
 first four packages are used as dependencies for many others (like the
 gazebo simulator) so they seem like a good starting point to me:

 * console-bridge
 
 Original Debianization: Thomas Moulard
 http://anonscm.debian.org/gitweb/?p=debian-science/packages/console-bridge.git

 * urdfdom  urdfdom-headers
 
 Original Debianization: Thomas Moulard
 http://anonscm.debian.org/gitweb/?p=debian-science/packages/urdfdom.git
 http://anonscm.debian.org/gitweb/?p=debian-science/packages/urdfdom-headers.git

 * sdformat
 --
 http://anonscm.debian.org/gitweb/?p=debian-science/packages/sdformat.git

 I would like to include them into the Robotics Blend if possible (thanks
 Andreas for letting me know about the project).

 They are into the debian-science git repository, no lintian warnings in
 my debian sid, latest versions, .symbols files ready, we have direct
 contact with urdfdom/console-bridge upstream and the OSRF is upstream
 for sdformat.

 If someone could help us with the review/upload that would be great.

 Thanks a lot, Regards
  - Jose.

 P.D: A part from Thomas, I've also contacted with Leo Palomo-Avellaneda
 who is part the robotics tasks of debian-science blend and is happy to
 help with the review or fixes, time permitting.

 [1] OSRF: Open Source Robotics Foundation

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



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

 
 


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



signature.asc
Description: OpenPGP digital signature

Looking for a sponsor for some robotics related packages

[Jose Luis Rivero]

Dear science team:

During the last month, as part of my work for the OSRF[1], I've been
working with Thomas Moulard (thanks!) in bringing some of our usual
robotics software packages into a good shape for being included into debian.

I believe that now they are in a good shape to start the process. These
first four packages are used as dependencies for many others (like the
gazebo simulator) so they seem like a good starting point to me:

* console-bridge

Original Debianization: Thomas Moulard
http://anonscm.debian.org/gitweb/?p=debian-science/packages/console-bridge.git

* urdfdom  urdfdom-headers

Original Debianization: Thomas Moulard
http://anonscm.debian.org/gitweb/?p=debian-science/packages/urdfdom.git
http://anonscm.debian.org/gitweb/?p=debian-science/packages/urdfdom-headers.git

* sdformat
--
http://anonscm.debian.org/gitweb/?p=debian-science/packages/sdformat.git

I would like to include them into the Robotics Blend if possible (thanks
Andreas for letting me know about the project).

They are into the debian-science git repository, no lintian warnings in
my debian sid, latest versions, .symbols files ready, we have direct
contact with urdfdom/console-bridge upstream and the OSRF is upstream
for sdformat.

If someone could help us with the review/upload that would be great.

Thanks a lot, Regards
 - Jose.

P.D: A part from Thomas, I've also contacted with Leo Palomo-Avellaneda
who is part the robotics tasks of debian-science blend and is happy to
help with the review or fixes, time permitting.

[1] OSRF: Open Source Robotics Foundation

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



signature.asc
Description: OpenPGP digital signature

Re: Bug#728723: ITP: simbody -- Open-source toolkit for simulation of articulated mechanisms

[Jose Luis Rivero]

Hello Andreas:

On 11/04/2013 10:20 PM, Andreas Tille wrote:

Hi Jose,

I guess you are intending to package this and also Bug#728719: ITP:
sdformat under Debian Science umbrella.  Please make sure your are
maintaining it in Debian Science Vcs and it would be great if you
would forward ITPs like this also to Debian Science mailing list.



Thanks for pointing me into the right direction. I will create the 
proper repositories and will take care of including debain-science when 
sending the ITP bugs.



Thanks for your ITP and feel free to ask on Debian Science mailing
list if you might need a sponsor.  You might be interested in my
Sponsoring of Blends[1] effort.



Oh yes, I will probably need some help once the packaging is ready. I 
didn't know the PureBlends project, looks like a very good resource to 
me. Thanks!


Kind regards,
 - Jose


Kind regards

Andreas.

[1] https://wiki.debian.org/DebianPureBlends/SoB

On Mon, Nov 04, 2013 at 05:16:37PM +, Jose Luis Rivero wrote:

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero jriv...@osrfoundation.org

* Package name: simbody
   Version : 3.3
   Upstream Author : Michael Sherman msher...@stanford.edu
* URL : https://simtk.org/home/simbody
* License : Apache
   Programming Lang: C++, C
   Description : Open-source toolkit for simulation of articulated 
mechanisms

Simbody is a SimTK toolset providing general multibody dynamics capability,
that is, the ability to solve Newton's 2nd law F=ma in any set of generalized
coordinates subject to arbitrary constraints. Simbody is provided as an open
source, object-oriented C++ API and delivers high-performance,
accuracy-controlled science/engineering-quality results.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104171637.10985.1481.reportbug@gem







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


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52798c26.8030...@osrfoundation.org

Re: ITP: sdformat -- Simulation Description Format (SDF) parser

[Jose Luis Rivero]

/CC to debian-science list

On 11/04/2013 06:00 PM, Jose Luis Rivero wrote:

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero jriv...@osrfoundation.org

* Package name: sdformat
   Version : 1.4.9
   Upstream Author : Open Source Robotics Foundation
* URL : http://sdformat.org
* License : BSD
   Programming Lang: C++
   Description : Simulation Description Format (SDF) parser

SDF is an XML file format that describes environments, objects, and robots
in a manner suitable for robotic applications. SDF is capable of representing
and describing different physic engines, lighting properties, terrain, static
or dynamic objects, and articulated robots with various sensors, and acutators.
The format of SDF is also described by XML, which facilitates updates and
allows conversion from previous versions. A parser is also contained within
this package that reads SDF files and returns a C++ interface.




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


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5279909f.3080...@osrfoundation.org