Bug#1020799: Transition: pkg-config to pkgconf: next steps

2022-10-20 Thread Leopold Palomo-Avellaneda

El 20/10/22 a les 12:56, Johannes Schauer Marin Rodrigues ha escrit:

Quoting Andrej Shadura (2022-10-20 12:25:13)

I’ve been rebuilding packages with pkgconf for the past couple of weeks, and
it looks very good so far:

http://pkgconf-migration.debian.net/


Thank you! Attached is a dd-list of those packages listed in the "Failures
only" page in case somebody wants to have a quick glance whether their package
is affected.



I have rebuilt fcl changing pkg-config by pkgconf in Build-dependencies 
in a pbuilder environment and it has been successful. So, I guess that 
it can been dropped from failure list.


Thanks for the work Andrej,


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?



Bug#1006001: Qtcreator devel files

2022-02-23 Thread Leopold Palomo-Avellaneda

Hi all!!

I have investigated a bit, but I need your experience. Using the salsa 
repo of qtcreator, I have added in control a new package:



--
diff --git a/debian/control b/debian/control
index 5b810ce..980a927 100644
--- a/debian/control
+++ b/debian/control
@@ -104,3 +104,17 @@ Description: documentation for Qt Creator IDE
  and easier.
  .
  This package contains documentation for Qt Creator IDE.
+
+Package: qtcreator-devel
+Architecture: all
+Multi-Arch: foreign
+Section: doc
+Depends: ${misc:Depends}
+Suggests: qt5-datga
+Description: Devel files to create plugins for Qt Creator IDE
+ Qt Creator is a cross-platform integrated development environment (IDE)
+ designed to make development with the Qt application framework faster
+ and easier.
+ .
+ This package contains source code of Qt Creator IDE needed to build
+ plugins.
--

In the rules file, I have activated the devel component:


--
diff --git a/debian/rules b/debian/rules
index b552a4e..bdc3d26 100755
--- a/debian/rules
+++ b/debian/rules
@@ -42,6 +42,7 @@ execute_after_dh_auto_install:
 ifneq (,$(filter qtcreator-doc, $(shell dh_listpackages)))
DESTDIR=$(CURDIR)/debian/tmp cmake --install $(CURDIR)/builddir 
--component qch_docs
DESTDIR=$(CURDIR)/debian/tmp cmake --install $(CURDIR)/builddir 
--component html_docs
+   DESTDIR=$(CURDIR)/debian/tmp cmake --install $(CURDIR)/builddir 
--component Devel

 endif

# Not needed
--

And in the debian directory, I have added debian/qtcreator-devel.install 
with:


--
usr/include/qtcreator usr/src
usr/lib/cmake usr/src/qtcreator
--

I have tried to follow the directory structure from the arch package 
[1]. Probably I will have made some mistakes.


Although the package is built (also backported for bullseye), I have 
some trouble when I try to build a plugin, specially with the paths.


So, please, could you check it?

Best regards,

Leopold


[1] 
https://archlinux.pkgs.org/rolling/ownstuff-x86_64/qtcreator-src-6.0.1-1-any.pkg.tar.zst.html


--
--
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?



Bug#1004072: libignition-common3-core-dev: Missing run dependency

2022-01-20 Thread Leopold Palomo-Avellaneda
Package: libignition-common3-core-dev
Version: 3.14.0+dfsg-4
Severity: normal

Dear Maintainer,

* What led up to the situation?

To use libignition-common with CMake, 
ignition-common3/ignition-common3-config.cmake introduces several dependencies:

find_package(DL ${ign_package_quiet} ${ign_package_required})
find_package(UUID ${ign_package_quiet} ${ign_package_required})
find_package(tinyobjloader ${ign_package_quiet} ${ign_package_required})

You should add libtinyobjloader-dev to Depends field.

Thanks.

Leopold


-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libignition-common3-core-dev depends on:
ii  libignition-cmake-dev  2.9.0-1~drp11+20220117
ii  libignition-common3-3  3.14.0+dfsg-4~drp11+20220118
ii  uuid-dev   2.36.1-8

libignition-common3-core-dev recommends no packages.

libignition-common3-core-dev suggests no packages.

-- no debconf information



Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

2021-06-02 Thread Leopold Palomo-Avellaneda

Hi Jochen!


first, thanks for the test. I was guessing but I do no pretend that you did it. 
In any case, it is great that you have done it because now, we have real 
information.


OTOH I like very much your summary. I take it as a reference for the future.

Thanks for all,

Cheers,

Leo


--
--
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?



Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

2021-06-02 Thread Leopold Palomo-Avellaneda
It's strange and I think that it's more a misunderstanding from upstream than a 
packaging name error.


I agree with Jochen that for Bullseye with just a binNMU should be enough. 
However, I would like to know if it's binary incompatible 1.12.5 and 1.12.10. 
Because, if the are compatible, maybe with just patch Ogre to have soversion 
with major.minor instead complete version should be more appropriated.


Leo



Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

2021-02-14 Thread Leopold Palomo-Avellaneda
El 14/2/21 a les 18:07, Jérémy Lal ha escrit:
[...]
> 
> 
> Hello,
> 
> i'll go ahead. However there is a high chance it won't migrate to testing,
> due to soft freeze policy as Thomas pointed out. Let's see.

Release Team has sent and email explaining the sate of bullseye. There's
a part that says:

--
General
===

As always, talk to us, preferably via the bts, if you experience issues
that we need to be aware of or where you need help. Please be aware it's
now a very busy time for us, so bear with us.

--


So, Thomas Perret, as maintainer, please follow that advice and put in
contact with Release Team and explain the situation.

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?



Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

2021-02-14 Thread Leopold Palomo-Avellaneda
Hi Mechtilde,


El 14/2/21 a les 14:41, Mechtilde Stehmann ha escrit:
> Hello Leopold,
> hello all,
> 
> does it also build at buildd after a source only upload.

ok

> At the official build machines it is n't allowed to install a package
> which isn't called in debian/control beside the essential build packages.

yes, you are right.

> You have to call *all needed* packages for building in debian/control.
> Otherwise it can't be build at the official build machines.

Yes, it's true. But, this is not the case. It call all the dependencies
to build the package. But it fails *before* you call pbuilder in a clean
env.

> This should be ensured by pbuilder. You have to be able to build in a
> clean pbuilder chroot.

I have a pbuilder installation to build packages. I'm using pbuilder,
and I built a lot of backports to myself. The server where I run
pbuilder is a Debian stable with several packages installed, nothing
important. Without sphinx-common, when I try to build paperwork, from
salsa I got:

$ pdebuild
W: /root/.pbuilderrc does not exist
dpkg-checkbuilddeps: error: Unmet build dependencies: python3-sphinx
python3-sphinxcontrib.plantuml sphinx-doc
W: Unmet build-dependency in source
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying
0001-Search-for-data-files-in-system-folders.patch
dpkg-source: info: applying
0002-Show-all-page-at-once-until-python3-getkey-gets-pack.patch
dpkg-source: info: applying 0003-Disable-potentially-dangerous-plugins.patch
dh clean --with python3,sphinxdoc --buildsystem=pybuild
dh: error: unable to load addon sphinxdoc: Can't locate
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install
the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28
/usr/share/perl/5.28 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base) at (eval 15) line 1.
BEGIN failed--compilation aborted at (eval 15) line 1.

make: *** [debian/rules:38: clean] Error 25

Before, pbuilder is call. However, if I install sphinx-common and run
again pbuilder paperwork is built.

Another thing is if you really need to call:

 dh $@ --with python3,sphinxdoc --buildsystem=pybuild

with sphinxdoc.

In any case, salsa C-I is passed and doesn't fail, and AFAIK they use a
similar env as build machines. Please, DD, push this package. It would
be a pity that we don't have this version in Bullseye.

Best regards,

Leopold


> Kind regards
> 
> Mechtilde
> 
> Am 14.02.21 um 14:15 schrieb Leopold Palomo-Avellaneda:
>> Mechtilde,
>>
>>
>> El 14/2/21 a les 14:04, Mechtilde Stehmann ha escrit:
>>
>> [...]
>>
>>> dh clean --with python3,sphinxdoc --buildsystem=pybuild
>>> dh: error: unable to load addon sphinxdoc: Can't locate
>>> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install
>>> the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
>>> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1
>>> /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32
>>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base
>>> /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32
>>> /usr/local/lib/site_perl) at (eval 14) line 1.
>>> BEGIN failed--compilation aborted at (eval 14) line 1.
>>
>> [...]
>>
>>
>> IMHO the problem that you have here is that you have not installed in
>> the box where you run pbuilder or gbp the package sphinx-common.
>>
>> That package contains the file
>> sphinx-common: /usr/share/perl5/Debian/Debhelper/Sequence/sphinxdoc.pm
>>
>> that needs Debhelper to prepare the package to be built.
>>
>> I have backported paperwork without any problem.
>>
>> Best 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?



Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

2021-02-14 Thread Leopold Palomo-Avellaneda
Mechtilde,


El 14/2/21 a les 14:04, Mechtilde Stehmann ha escrit:

[...]

> dh clean --with python3,sphinxdoc --buildsystem=pybuild
> dh: error: unable to load addon sphinxdoc: Can't locate
> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install
> the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1
> /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base
> /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32
> /usr/local/lib/site_perl) at (eval 14) line 1.
> BEGIN failed--compilation aborted at (eval 14) line 1.

[...]


IMHO the problem that you have here is that you have not installed in
the box where you run pbuilder or gbp the package sphinx-common.

That package contains the file
sphinx-common: /usr/share/perl5/Debian/Debhelper/Sequence/sphinxdoc.pm

that needs Debhelper to prepare the package to be built.

I have backported paperwork without any problem.

Best 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?



Bug#980636: amd64 fails

2021-01-25 Thread Leopold Palomo-Avellaneda
I have almost backported to Buster pytorch and I have found the same error, and 
probably it's something related with rules file.


In the rules file, CMake options are configured and there's a line:

ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el))
export USE_MKLDNN = ON
else
export USE_MKLDNN = OFF
endif


however, is passed to CMake USE_MKLDNN = ON (at least my CMakeCache says it). 
The question is that replacing:


ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el))

by

ifneq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el))

it solved the issue. I have seen in another places that maybe should be replaced 
also.




--
--
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?



Bug#968626: Patch is not working

2021-01-12 Thread Leopold Palomo-Avellaneda
El 7/1/21 a les 16:54, Maximilian Stein ha escrit:
>>I have used the patch from Maximilian Stein, but I got the same error.
> 
> Have you tried to debug the exact cause of the failure in your case? In
> my message above I outlined how I debugged the issue — maybe that helps
> to investigate your situation.

First of all, I'm sorry because I couldn't test what did you say. In any
case, after upgrade to 13.5.6 artifacts are working again.

So, my recommendation is to solve first #977701 and after check is this
is solved.


-- 
--
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?



Bug#977701: gitlab: Missing assets, breaking some functionalities

2021-01-12 Thread Leopold Palomo-Avellaneda
Just to put some info in the bug:

I have upgraded my gitlab installation to 13.5.6-1~fto10+2.

I have follow wiki instructions but there are missing dependencies:

ruby-charlock-holmes ruby-mini-magick

node-katex must be backported if not, there are error because
katex.min.css is missing. A possible workaround is to drop the
references in the directory /usr/share/gitlab/app/assets/javascripts
the files:

behaviors/markdown/render_math.js:   // import(/* webpackChunkName:
'katex' */ 'katex/dist/katex.min.css'),

notebook/cells/markdown.vue:/* @import '~katex/dist/katex.min.css'; */

After that seem that gitlab is working ... I hope.

-- 
--
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?



Bug#977701: gitlab: Assets

2021-01-12 Thread Leopold Palomo-Avellaneda

Trying upgrading gitlab I have found that there are missing dependencies:

ruby-charlock-holmes ruby-mini-magick


Also, node-katex must be packaged in fasttrack because there are some module 
that needs it:


Error: Can't resolve '~katex/dist/katex.min.css' in 
'/usr/share/gitlab/app/assets/javascripts/notebook/cells'


also,


ERROR in ./behaviors/markdown/render_math.js
Module not found: Error: Can't resolve 'katex/dist/katex.min.css' in 
'/usr/share/gitlab/app/assets/javascripts/behaviors/markdown'

 @ ./behaviors/markdown/render_math.js 142:12-144:29


--
--
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?



Bug#974159: Patch

2021-01-12 Thread Leopold Palomo-Avellaneda

I have solved this bug just with this little patch.


$ diff gitaly.postinst~ gitaly.postinst
51c51
<   export $(grep '^\s*path\s*=' /etc/gitaly/config.toml | sed 's/ //g' | 
sed 's/"//g')

---
>   export $(grep '^\s*path\s*=' /etc/gitaly/config.toml | sed 's/ //g' | 
sed 's/"//g' | sed "s/'//g" )




--
--
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?



Bug#968626: Patch is not working

2021-01-07 Thread Leopold Palomo-Avellaneda

I'm using gitlab (13.3.9-1+fto10+1) and gitlab-runner (13.7.0, from upstream).

I have used the patch from Maximilian Stein, but I got the same error. Well, I 
patch the file and retry the CI.


Any idea how to solve this?





--
--
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?



Bug#978730: transition: fcl

2020-12-30 Thread Leopold Palomo-Avellaneda
Subject: transition: fcl
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Dear release team,

I would like to ask a transition slot for the fcl library. Upstream
published a new version with a soname bump.

We have had a lot of problems to build in many archs, but the last one,
(mipsel) finally worked with the last version of the package.

The only package that depends on fcl is dart, and I have built it (amd64).

Please accept the transition slot.

Best regards,


Leopold

-

Ben file:

title = "fcl";
is_affected = .depends ~ /\b(libfcl0\.6|libfcl0\.5)\b/
is_good = .depends ~ /\b(libfcl0\.6)\b/
is_bad = .depends ~ /\b(libfcl0\.5)\b/



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

-- 
--
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?



OpenPGP_signature
Description: OpenPGP digital signature


Bug#974159: gitaly: Error in postinst script

2020-11-10 Thread Leopold Palomo-Avellaneda
Package: gitaly
Version: 13.3.9+dfsg-1+fto10+1
Severity: normal

Installing gitaly I have found that if it's an upgrade, or install, and
it's installed, there's and error because when the script is executed,
in the line 50:

# Check if storage path exist and create if required
  export $(grep '^\s*path\s*=' /etc/gitaly/config.toml | sed 's/ //g' |
sed 's/"//g')
  if ! [ -d $path ] ; then runuser -u ${gitlab_user} -- sh -c 'mkdir
$path'; fi

The problem is the path in my case contains:
'/home/projects/gitlab/repositories'. Pay attention in the ' ', so the
if ![-d $path] check for a '/home/projects/gitlab/repositories' and of
course my path doesn't exists. It exists without ''. So, when you try to
create the path , I don't know why, the '' disappears and the error
occurs because the path exists.

Hope have been clear.


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8),
LANGUAGE=ca:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


-- 
--
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?



Bug#971532: nvidia-graphics-drivers: Blank screen with just the mouse with sddm

2020-10-01 Thread Leopold Palomo-Avellaneda

Package: nvidia-graphics-drivers
Severity: normal

Dear Maintainer,


I'm having problems with the nvidia-graphics driver. I'm using 450.66-1~bpo10+1 
and it has been tested with linux-image-4.19.0-11-amd64 and 
linux-image-5.7.0-0.bpo.2-amd64.


With all the test test that I have done the result has been the same. When sddm 
load, a black screen in showed and the cursor, nothing more. However, with 
nouveau the works.


Checking /var/log/Xorg.0.log what I have found interesting is this:
...
 (EE) Failed to open authorization file 
"/var/run/sddm/{4f23d2f5-babb-4b65-bbfd-ba06776ed6cb}": No such file or directory

...

Surfing on the web what I have found is that is something related with drm and 
the nvidia driver, but although I have forced with nvidia-drm.modeset=1 I don't 
have found any different result.


Any idea of what is failing here?

Leopold


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
--
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?



Bug#970779: dh-python: Hardening settings

2020-09-23 Thread Leopold Palomo-Avellaneda
Package: dh-python
Version: 3.20190308
Severity: normal

Dear Maintainer,

if the python package generates a binary .so module, although the hardening 
options are defined in rules they are not used to build the cpython stuff.

Please, check this because lintian complains if the python package generate 
.cpython stuff.



-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-python depends on:
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.7
ii  libdpkg-perl  1.19.7

-- no debconf information



Bug#964192: ITP: python-chess -- a pure Python chess library

2020-07-03 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: "Leopold Palomo-Avellaneda" 

* Package name: python-chess
  Version : 0.31.2
  Upstream Author : Niklas Fiekas 
* URL : https://github.com/niklasf/python-chess
* License : GPL-3.0
  Programming Lang: Python
  Description : Pure Python chess library

 python-chess is a pure Python chess library with move generation,
 move validation and support for common formats.

 I would like to maintain/donate to Debian Games Team
.



-- 
--
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?



Bug#951499: transition: collada-dom

2020-03-13 Thread Leopold Palomo-Avellaneda

Alberto (openscenegraph maintainer),


if nothing strange happens this weekend we will push collada-dom to unstable. I 
don't think that openscenegraph will FTBFS because we have added a transitional 
package, but if not as we have commented privately, with the change of 
libcollada-dom2.4-dp-dev to libcollada-dom-dev should be enough to build.


If you need sponsor to push a new version of the package I'm quite sure that 
some of the guys CC here will help you in case.


Cheers,

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?



signature.asc
Description: OpenPGP digital signature


Bug#951499: transition: collada-dom

2020-02-17 Thread Leopold Palomo-Avellaneda

Subject: transition: collada-dom
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Dear release team,

I would like to ask a transition slot for the collada-dom library. Upstream 
published a
new version with a soname bump and we have done also a package name change in 
terms of
coherence. The affected packages (2) can be build without any problem with the 
new
version but needs to change the name of the package build deps (if not FTBFS).

openscenegraph
ros-collada-urdf

Please accept the transition slot.

Best regards,


Leopold

-

Ben file:

title = "collada-dom";
is_affected = .depends ~ 
/\b(libcollada\-dom\-dev|libcollada\-dom2\.5\-dp0|libcollada\-dom2\.4\-dp0)\b/
is_good = .depends ~ /\b(libcollada\-dom\-dev|libcollada\-dom2\.5\-dp0)\b/
is_bad = .depends ~ /\b(libcollada\-dom2\.4\-dp0)\b/

--
--
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?



Bug#944596: gitlab: Upgrading to 12.2.9-1 fails

2019-11-12 Thread Leopold Palomo-Avellaneda
Package: gitlab
Version: 12.2.9-1+fto10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,



upgrading right now to gitlab (12.2.9-1+fto10+1) I have found this error:

Using version_sorter 2.2.4
Using vmstat 2.3.0
Using webpack-rails 0.9.11
Using wikicloth 0.8.1
Bundle complete! 181 Gemfile dependencies, 331 gems now installed.
Gems in the groups development and test were not installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Running final rake tasks and tweaks...
gitlab_production database is not empty, skipping gitlab setup
fatal: no és un dipòsit de git (ni cap dels directoris pares): .git
fatal: no és un dipòsit de git (ni cap dels directoris pares): .git
/usr/share/gitlab/lib/gitlab.rb:38: warning: already initialized constant
Gitlab::COM_URL
/usr/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was 
here
/usr/share/gitlab/lib/gitlab.rb:39: warning: already initialized constant
Gitlab::APP_DIRS_PATTERN
/usr/share/gitlab/lib/gitlab.rb:39: warning: previous definition of
APP_DIRS_PATTERN was here
/usr/share/gitlab/lib/gitlab.rb:40: warning: already initialized constant
Gitlab::SUBDOMAIN_REGEX
/usr/share/gitlab/lib/gitlab.rb:40: warning: previous definition of
SUBDOMAIN_REGEX was here
/usr/share/gitlab/lib/gitlab.rb:41: warning: already initialized constant
Gitlab::VERSION
/usr/share/gitlab/lib/gitlab.rb:41: warning: previous definition of VERSION was 
here
/usr/share/gitlab/lib/gitlab.rb:42: warning: already initialized constant
Gitlab::INSTALLATION_TYPE
/usr/share/gitlab/lib/gitlab.rb:42: warning: previous definition of
INSTALLATION_TYPE was here
/usr/share/gitlab/lib/gitlab.rb:43: warning: already initialized constant
Gitlab::HTTP_PROXY_ENV_VARS
/usr/share/gitlab/lib/gitlab.rb:43: warning: previous definition of
HTTP_PROXY_ENV_VARS was here
/usr/share/gitlab/config/initializers/2_app.rb:6: warning: already initialized
constant Gitlab::VERSION
/usr/share/gitlab/lib/gitlab.rb:41: warning: previous definition of VERSION was 
here
rake aborted!
NoMethodError: undefined method `mysql?' for Gitlab::Database:Module
/usr/share/gitlab/config/initializers/active_record_mysql_timestamp.rb:7:in
`'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:285:in
`load'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:285:in
`block in load'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in
`load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:285:in
`load'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:657:in
`block in load_config_initializer'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/notifications.rb:170:in
`instrument'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:656:in
`load_config_initializer'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:614:in
`block (2 levels) in '
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:613:in
`each'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:613:in
`block in '
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/initializable.rb:32:in
`instance_exec'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/initializable.rb:32:in
`run'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/initializable.rb:61:in
`block in run_initializers'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/initializable.rb:50:in
`each'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/initializable.rb:50:in
`tsort_each_child'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/initializable.rb:60:in
`run_initializers'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/application.rb:361:in
`initialize!'
/usr/share/gitlab/config/environment.rb:6:in `'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in
`require'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in
`block in require'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in
`load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in
`require'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/application.rb:337:in
`require_environment!'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/application.rb:520:in
`block in run_tasks_blocks'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
dpkg: s'ha produït un error en processar el paquet gitlab (--configure):
 el subprocés «s'ha instal·lat el script 

Bug#942545: gitlab: Wrong permissions in some update

2019-10-17 Thread Leopold Palomo-Avellaneda
Package: gitlab
Version: 12.0.9-1+fto10+1
Severity: normal

Dear Maintainer,

Since some weeks ago the generation of artifacts didn't work for me.
I have had the time to check it (or the inspiration) and I have found that the
directory:

/var/lib/gitlab/shared/artifacts/tmp

should have gitlab:gitlab permisions to write, not root:root. It failed in some
update.

Please, could you check in the package that this directory set the correct 
permissions?

-- System Information:
Debian Release: 10.1
  APT prefers buster-fasttrack
  APT policy: (900, 'buster-fasttrack'), (900, 'buster-backports'), (900, 
'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gitlab depends on:
ii  asciidoctor  1.5.8-1
ii  bc   1.07.1-2+b1
ii  bundler  1.17.3-3
ii  bzip21.0.6-9.2~deb10u1
ii  dbconfig-pgsql   2.0.11+deb10u1
ii  debconf [debconf-2.0]1.5.71
ii  exim44.92-8+deb10u2
ii  exim4-daemon-light [mail-transport-agent]4.92-8+deb10u2
ii  gitlab-common12.0.9-1+fto10+1
ii  gitlab-workhorse 8.5.2+debian-1~bpo10+1
ii  libjs-bootstrap4 [node-bootstrap]4.3.1+dfsg2-1
ii  libjs-pdf1.5.188+dfsg-1~bpo10+1
ii  libjs-popper.js [node-popper.js] 1.14.6+ds2-1
ii  libjs-uglify 2.8.29-6
ii  lsb-base 10.2019051400
ii  nginx1.14.2-2+deb10u1
ii  nginx-full [nginx]   1.14.2-2+deb10u1
ii  node-autosize4.0.2~dfsg1-3
ii  node-axios   0.17.1+dfsg-2
ii  node-brace-expansion 1.1.8-1
ii  node-cache-loader2.0.1-2~bpo10+1
ii  node-chart.js2.7.3+dfsg-5
ii  node-core-js 3.2.1-1~bpo10+1
ii  node-css-loader  1.0.1-1
ii  node-d3  4.13.0-6~bpo10+1
ii  node-d3-array1.2.4-2~bpo10+1
ii  node-d3-axis 1.0.12-2~bpo10+1
ii  node-d3-brush1.0.6-2~bpo10+1
ii  node-d3-ease 1.0.5-2~bpo10+1
ii  node-d3-scale1.0.7-6~bpo10+1
ii  node-d3-selection1.4.0-3~bpo10+1
ii  node-d3-shape1.3.5-2~bpo10+1
ii  node-d3-time 1.0.11-3~bpo10+1
ii  node-d3-time-format  2.1.3-2~bpo10+1
ii  node-d3-transition   1.2.0-3~bpo10+1
ii  node-dateformat  3.0.0-1
ii  node-exports-loader  0.7.0-2~bpo10+1
ii  node-file-loader 3.0.1-1~bpo10+1
ii  node-fuzzaldrin-plus 0.5.0+dfsg-1
ii  node-glob7.1.3-2
ii  node-imports-loader  0.8.0-2~bpo10+1
ii  node-jed 1.1.1-1
ii  node-jquery  3.4.0+dfsg-1~bpo10+1
ii  node-jquery-ujs  1.2.2-2
ii  node-jquery.waitforimages2.4.0+ds-1
ii  node-js-cookie   2.2.0-2
ii  node-jszip   3.1.4+dfsg-1
ii  node-jszip-utils 0.0.2+dfsg-1
ii  node-mousetrap   1.6.1+ds-1
ii  node-pikaday 1.8.0-1
ii  node-raven-js3.22.1+dfsg-2
ii  node-raw-loader  1.0.0-2~bpo10+1
ii  node-three-orbit-controls82.1.0-2
ii  node-three-stl-loader1.0.6-2
ii  node-timeago.js  3.0.2+dfsg-3
ii  node-underscore  1.9.1~dfsg-1
ii  node-url-loader  1.1.2-1~bpo10+1
ii  

Bug#922900: O: qdacco -- offline Dacco Catalan <-> English dictionary frontend (qt)

2019-09-26 Thread Leopold Palomo-Avellaneda
Control: retitle -1 ITA: qdacco -- offline Dacco Catalan <-> English dictionary
 frontend (qt)
Control: owner -1 l...@alaxarxa.net


I know the project since some years ago and Carles Pina (qdacco) developer is a
good friend so I think I should take care of it.


-- 
--
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?



Bug#922890: ITA: dacco -- Catalan/English dictionary (xml files))

2019-09-25 Thread Leopold Palomo-Avellaneda
Control: owner -1 l...@alaxarxa.net

--
--
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?



Bug#922890: (no subject)

2019-09-25 Thread Leopold Palomo-Avellaneda
Control: owner 922890 l...@alaxarxa.net

-- 
--
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?



Bug#922890: ITA: dacco -- Catalan/English dictionary (xml files)

2019-09-25 Thread Leopold Palomo-Avellaneda
Control: retitle -1 ITA: dacco -- Catalan/English dictionary (xml files)
Control: owner l...@alaxarxa.net


I know the project since some years ago and Carles Pina (qdacco) developer is a
good friend so I think I should take care of it.


-- 
--
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?



Bug#932914: gitlab: Increase version dependency of ruby-fog-google

2019-07-24 Thread Leopold Palomo-Avellaneda
Package: gitlab
Version: 11.10.8+dfsg-1+fto10+1
Severity: normal

Dear Maintainer,

after upgrading the package from stretch-backports to buster-backports and
fasttrack the process failed. gitlab has ruby-fog-google > 1.8.2 as dependency
but the installation detects that is not enough.

It could be solve simple instaling manually:

apt-get install -t buster-backports ruby-fog-google.


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gitlab depends on:
ii  asciidoctor1.5.8-1
ii  bc 1.07.1-2+b1
ii  bundler1.17.3-3
ii  bzip2  1.0.6-9.1
ii  dbconfig-pgsql 2.0.11
ii  debconf [debconf-2.0]  1.5.71
ii  exim4  4.92-8
ii  exim4-daemon-light [mail-transport-agent]  4.92-8
ii  gitlab-common  11.10.8+dfsg-1+fto10+1
ii  gitlab-workhorse   8.5.2+debian-1~bpo10+1
ii  libjs-bootstrap4 [node-bootstrap]  4.3.1+dfsg2-1
ii  libjs-pdf  1.5.188+dfsg-1~bpo10+1
ii  libjs-popper.js [node-popper.js]   1.14.6+ds2-1
ii  libjs-uglify   2.8.29-6
ii  lsb-base   10.2019051400
ii  nginx  1.14.2-2
ii  nginx-full [nginx] 1.14.2-2
ii  node-autosize  4.0.2~dfsg1-3
ii  node-axios 0.17.1+dfsg-2
ii  node-brace-expansion   1.1.8-1
ii  node-chart.js  2.7.3+dfsg-5
ii  node-core-js   2.4.1-2
ii  node-css-loader1.0.1-1
ii  node-d3-array  1.2.1-3
ii  node-d3-axis   1.0.8-3
ii  node-d3-brush  1.0.4-3
ii  node-d3-ease   1.0.3-3
ii  node-d3-scale  1.0.7-3~bpo10+1
ii  node-d3-selection  1.4.0-3~bpo10+1
ii  node-d3-shape  1.2.0-2
ii  node-d3-time   1.0.11-3~bpo10+1
ii  node-d3-time-format2.1.3-2~bpo10+1
ii  node-d3-transition 1.2.0-3~bpo10+1
ii  node-dateformat3.0.0-1
ii  node-fuzzaldrin-plus   0.5.0+dfsg-1
ii  node-glob  7.1.3-2
ii  node-jed   1.1.1-1
ii  node-jquery3.4.0+dfsg-1~bpo10+1
ii  node-jquery-ujs1.2.2-2
ii  node-jquery.waitforimages  2.4.0+ds-1
ii  node-js-cookie 2.2.0-2
ii  node-jszip 3.1.4+dfsg-1
ii  node-jszip-utils   0.0.2+dfsg-1
ii  node-mousetrap 1.6.1+ds-1
ii  node-pikaday   1.8.0-1
ii  node-raven-js  3.22.1+dfsg-2
ii  node-three-orbit-controls  82.1.0-2
ii  node-three-stl-loader  1.0.6-2
ii  node-timeago.js3.0.2+dfsg-3
ii  node-underscore1.9.1~dfsg-1
ii  node-vue-resource  1.5.1+dfsg-3~bpo10+1
ii  node-webpack-stats-plugin  0.2.1-1
ii  nodejs 10.15.2~dfsg-2
ii  openssh-client 1:7.9p1-10
ii  postgresql-client  11+200+deb10u1
ii  postgresql-client-11 [postgresql-client]   11.4-1
ii  postgresql-client-9.6 [postgresql-client]  9.6.13-0+deb9u1
ii  postgresql-contrib 11+200+deb10u1
ii  rake   12.3.1-3
ii  redis-server   5:5.0.3-4+deb10u1
ii  ruby   1:2.5.1
ii  ruby-ace-rails-ap  4.1.1-1
ii  ruby-acts-as-taggable-on   6.0.0-3
ii  ruby-addressable   2.5.2-1
ii  ruby-akismet   2.0.0-1
ii  ruby-asana 0.8.1-2~bpo10+1
ii  ruby-asciidoctor-plantuml  0.0.8-1
ii  ruby-attr-encrypted3.1.0-2~bpo10+1
ii  ruby-babosa1.0.2-2
ii  ruby-base320.3.2-3
ii  ruby-batch-loader  1.2.2-1
ii  ruby-bcrypt-pbkdf 

Bug#930998: RM: ompl/1.4.2+ds1-3

2019-06-25 Thread Leopold Palomo-Avellaneda
Just some clarifications:


As Jochen said:

> Reason: The package in testing is RC buggy with #930507. Leo pushed a
> new -3 revision over a week ago to unstable but expressed in

> https://lists.debian.org/debian-release/2019/06/msg00526.html
> 
> that he is not 'very happy with the patches'. 

he missed the final sentence ... but "they are valid". When I was saying that I
was not happy I asked three possible options and I didn't receive any answer. I
just create another set of patch different from upstream to solve the same and I
don't think that it was a good idea (not follow Upstream solving the same). And
the most formal solution should be to use the Depends field of pkg-config.

The bug mentioned the dependencies of the pkgfile about the includes and that
was solved. The problem has been that I introduce a more strong dependency
(libode-dev)

After discussing the state
> in #debian-release today, I had a look at the -3 version and tested it
> using
> 
> http://ompl.kavrakilab.org/RigidBodyPlanningWithIntegrationAndControls_8cpp_source.html
> 
> and
> 
> g++ $(pkg-config --cflags --libs ompl) -o 
> RigidBodyPlanningWithIntegrationAndControls 
> RigidBodyPlanningWithIntegrationAndControls.cpp
> 
> I found that that libompl-dev was still missing dependencies, i.e.
> libode-dev and boost.

boost is added, Jochen do it. But libode no. I just solved the pkg issue but I
didn't pay attention that that changed brought the libode-dev. You only need
libode if you use one extension. For instance, the example that Jochen mentioned
generate:

 g++ -I/usr/include/eigen3 -lompl /usr/lib/x86_64-linux-gnu/libode.so
/usr/lib/x86_64-linux-gnu/libboost_serialization.so
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/lib/x86_64-linux-gnu/libboost_system.so -lpthread -o
RigidBodyPlanningWithIntegrationAndControls
RigidBodyPlanningWithIntegrationAndControls.cpp

if I drop the ode part (/usr/lib/x86_64-linux-gnu/libode.so) the program
compiles and links perfectly, and runs. If I uninstall libode-dev the program
works (and builds without the libode.so). Only needs libode-dev because
pkg-config add that flag. And it added because if you use the ode extension in
theory you need to link against it, but it's not clear to me. libompl is linked
against ode because that extension, but if you don't use any ode symbols I think
that you don't need to link against it.

> Given that the deadline for change in buster passed and the package would need
> more review to get fixed, I propose to drop it from the buster release.

It's a pity and a sad thing to me. I have been working with this package and
tried to keep it in a good shape and now because a last time bug, bad resolved
and with a simple solution (change Suggest to depends of libode-dev) it's out of
buster.

I have pushed a new version replacing my patches with an adaptation of upstream
patches to solve the problem from here:

https://bitbucket.org/ompl/ompl/commits/e3855102b037643a9625ff6694bb2f559eecb411

Here my patches:

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0002-Patch-from-upstream-to-add-include-dirs.patch

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0003-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0004-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch


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?



Bug#930507: Reopen. It's not solved

2019-06-17 Thread Leopold Palomo-Avellaneda
reopen 930507



Bug#930646: Reopen the bug

2019-06-17 Thread Leopold Palomo-Avellaneda
Package: libompl-dev
reopen 930507

-- 
--
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?



Bug#925205: nmu: ros-rosconsole_1.13.9-1

2019-03-21 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu ros-rosconsole_1.13.9-1 . ANY . unstable . -m "Rebuild because of #924395 
bug in ros-catkin"

tags 924399 - moreinfo



-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#924399: release.debian.org: ros-catkin has a bug and needs to rebuild one package

2019-03-18 Thread Leopold Palomo-Avellaneda
El 17/3/19 a les 9:26, Niels Thykier ha escrit:
> Control: tags -1 moreinfo
> 
> Leopold Palomo-Avellaneda:
>> Package: release.debian.org
>> Severity: normal
>>
>> I have detected an ugly bug in ros-catkin (#924395). It _only_ affects to
>> software that uses catkin and generates pkgconfig files (.pc) that uses
>> Boost.
>>
>> In our case we have ros-rosconsole. The pkgconfig file is wrong. So, I would
>> like to push a new version of ros-catking and ask a rebuild of
>> ros-rosconsole.
>>
>> Can it be possible for Buster?
>>
>> Best regards,
>>
>> Leopold
>>
>>
>> [...]
> Hi Leopold,
> 
> Please go ahead with the minimal change in #924395 and remove the
> moreinfo tag once ros-catkin has been uploaded (please include the
> binNMU request in that follow up - see
> https://release.debian.org/wanna-build.html for the syntax).
> 
> For future reference/case, please consider:
>  * File an unblock request (use reportbug as it generate the correct
>bug metadata)
>  * Include/Attach the changes in form of a full debdiff.
> 
> These steps make it easier for us to find, track and review your request.
> 
> Thanks,
> ~Niels
> 

Hi Niels,

ros-catkin is uploaded and accepted. I wait some hours to ask for NMU. However,
I would like to add that I found another bug related with the cmake boost thread
library issue.

https://github.com/ros-visualization/python_qt_binding/commit/0a4893791039d5c3f851ee7bc2de832209d52f6d

It's not so critical like the other one because I have only found one package
that this one makes an error, but the package in the archive is wrong. So, if
you agree, I file a bug, and I can prepare a patch for the version in testing
and pushed. I hope not to find more errors in the ros testing packages ...


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?



Bug#924399: release.debian.org: ros-catkin has a bug and needs to rebuild one package

2019-03-12 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal

I have detected an ugly bug in ros-catkin (#924395). It _only_ affects to
software that uses catkin and generates pkgconfig files (.pc) that uses
Boost.

In our case we have ros-rosconsole. The pkgconfig file is wrong. So, I would
like to push a new version of ros-catking and ask a rebuild of
ros-rosconsole.

Can it be possible for Buster?

Best regards,

Leopold



-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#924395: ros-catkin: catkin generates incorrect double -l in pthread libs from boost

2019-03-12 Thread Leopold Palomo-Avellaneda
Source: ros-catkin
Severity: important


catkin generates .pc files from its templates. However, arround the inclusion 
of cmake 3.12.x or 3.13.x, the FindBoost macro injects a -lpthread in the
BOOST_libraries. This information is bad resolved by catkin introducing a 
double -l-lpthread in the .pc files generated that use Boost.

I have only detected rosconsole.pc (librosconsole-dev. Source ros-rosconsole)
that has -l-lpthread.

The solution is simple:

--- /usr/share/catkin/cmake/catkin_package.cmake~   2018-12-02 
14:35:11.0
+0100
+++ /usr/share/catkin/cmake/catkin_package.cmake2019-03-12 
10:30:29.742795867 +0100
@@ -270,7 +270,9 @@
   catkin_filter_libraries_for_build_configuration(libraries
${PKG_CONFIG_LIBRARIES})
   foreach(library ${libraries})
 if(NOT IS_ABSOLUTE ${library})
-  set(library "-l${library}")
+  if(NOT ${library} MATCHES "^-l")
+set(library "-l${library}")
+  endif()
 endif()
 list_append_deduplicate(PKG_CONFIG_LIBRARIES_WITH_PREFIX ${library})
   endforeach()

I have prepared a new version of the package patched waiting to release team 
aprovation.

Best regards,

Leopold


-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#922832: ITP: ros-joint-state-publisher -- Tool for setting and publishing joint state values for a given URDF.

2019-02-21 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner:  Leopold Palomo-Avellaneda 

* Package name: ros-joint-state-publisher
  Version : 1.12.13
  Upstream Author : Willow Garage, Inc.
* URL : https://github.com/ros/joint-state-publisher
* License : BSD-3-clause
  Programming Lang: C++
  Description : Tool for setting and publishing joint state values
for a given URDF.

Upstream of the existing Debian package src:ros-robot-model split the
project into four individual projects. The maintainers of
src:ros-robot-model want to follow this split and remove
src:ros-robot-model in favour of four new source packages which will
track each of the new projects, respectively.

This ITP is for the new source package src:ros-joint-state-publisher

-- 
--
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?



Bug#922825: ITP: ros-collada-urdf -- Converting from collada files to URDF

2019-02-21 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner:  Leopold Palomo-Avellaneda 

* Package name: ros-collada-urdf
  Version : 1.12.12
  Upstream Author : Willow Garage, Inc., University of Tokyo
* URL : https://github.com/ros/collada-urdf
* License : BSD-3-clause
  Programming Lang: C++
  Description : Converting from collada files to URDF

Upstream of the existing Debian package src:ros-robot-model split the
project into four individual projects. The maintainers of
src:ros-robot-model want to follow this split and remove
src:ros-robot-model in favour of four new source packages which will
track each of the new projects, respectively.

This ITP is for the new source package src:ros-collada-urdf

-- 
--
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?



Bug#918987: transition: ode

2019-01-13 Thread Leopold Palomo-Avellaneda
El 13/1/19 a les 15:52, Emilio Pozuelo Monfort ha escrit:
> On 11/01/2019 18:09, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>>
>> On 11/01/2019 15:17, Leopold Palomo-Avellaneda wrote:
>>> Subject: transition: ode
>>> Package: release.debian.org
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> Severity: normal
>>>
>>> Dear release team,
>>>
>>> I would like to ask a transition slot for the ode library. Upstream 
>>> published a
>>> new version with a soname bump. The affected packages can be build without 
>>> any
>>> problem with the new version (I did it in an pbuilder environment).
>>>
>>> Please accept with transition slot. I know that is too close to Buster 
>>> freeze.
>>
>> Go ahead.
> 
> And your package fails (and was already failing) to build on several release
> architectures. You should have fixed that before requesting a transition slot.
> 
> Please look at those failures:
> 
> https://buildd.debian.org/status/package.php?p=ode
> 

First of all I'm so sorry. I didn't check the build of the package
because I thought that it was built. I was more worried about the
dependencies than the package itself. Upstream told me the there was no
important changes. I check specially ABI changes.

In any case, after I notice the problem I worked on. In some archs there
was a problem in autotest, and in others an assert that for an check
from upstream. The problem was in non common archs.

I pushed a new version of the package yesterday night solving the issue
in some archs and this morning I have pushed another version of the
package with the patches sent by upstream. Also, some people in
#debian-mentors helped me in this issue.

Now, it builds in all the archs expect ia64 because some dependencies,
not the package itself.

I can only say this...


-- 
--
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?



signature.asc
Description: OpenPGP digital signature


Bug#918987: transition: ode

2019-01-11 Thread Leopold Palomo-Avellaneda
Subject: transition: ode
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Dear release team,

I would like to ask a transition slot for the ode library. Upstream published a
new version with a soname bump. The affected packages can be build without any
problem with the new version (I did it in an pbuilder environment).

Please accept with transition slot. I know that is too close to Buster freeze.

darkplaces ok
k3d ok
mokomaze ok
mu-cade ok
ompl ok
pyepl ok
python-pyode ok
stormbaancoureur ok
xmoto ok



Best regards,


Leopold

-

Ben file:

title = "ode";
is_affected = .depends ~ /\b(libode8|libode6)\b/
is_good = .depends ~ /\b(libode8)\b/
is_bad = .depends ~ /\b(libode6)\b/
-- 
--
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?



signature.asc
Description: OpenPGP digital signature


Bug#914392: transition: coin3

2018-12-19 Thread Leopold Palomo-Avellaneda
El 19/12/18 a les 11:41, Emilio Pozuelo Monfort ha escrit:
> Control: tags -1 confirmed
> 
> On 16/12/2018 23:08, Leopold Palomo-Avellaneda wrote:
>> El 28/11/18 a les 19:12, Emilio Pozuelo Monfort ha escrit:
>>> On 22/11/2018 23:33, Leopold Palomo-Avellaneda wrote:
>>>> Subject: transition: coin3
>>>> Package: release.debian.org
>>>> User: release.debian@packages.debian.org
>>>> Usertags: transition
>>>> Severity: normal
>>>>
>>>> Dear release team,
>>>>
>>>> I would like to ask a transition slot for the coin3 library. The package
>>>> has been reworked and a new version of the upstream has been packaged.
>>>>
>>>> Upstream have changed the build system to CMake and this has been used
>>>> for the package. This has an implication that it will break with FTBFS
>>>> the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I
>>>> have contacted with all the maintainers and they are aware about it and
>>>> we are preparing patches or simple disable in any case.
>>>
>>> Where are you discussing that? I don't see bug reports for those packages.
>>> Please file bugs so that we can track the status and decide when to start 
>>> this
>>> transition based on the disruption that it will cause. Also please make 
>>> those
>>> bugs block this one.
>> Dear release team,
>>
>> we have two packages in new with versions that built against coin3 in
>> experimental:
>>
>> https://ftp-master.debian.org/new/soqt_1.6.0~ea5cd76+ds1-1~exp1.html
>> https://ftp-master.debian.org/new/pivy_0.6.4-1~exp1.html
>>
>> both are the version more problematic and FTBFS without these new
>> versions. Please, could you push coin3 to unstable to initiate the
>> transition to make all this versions be built?
>>
>> freecad needs both. We have built freecad with both and works perfectly.
> 
> I don't see a bug for openscenegraph-3.4. Is there one?

no, there's no bug.

 What's its status?

I built it without any problem. That's why I didn't fill any bug. In any case I
will check it.

> Anyway go ahead with this. I trust that you will take care of openscenegraph 
> as
> you have done with everything else.

I understand that I can push it to unstable. Right?

And should I have to do a transition for soqt too or can I could to it together?

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?



Bug#914392: transition: coin3

2018-12-16 Thread Leopold Palomo-Avellaneda
El 28/11/18 a les 19:12, Emilio Pozuelo Monfort ha escrit:
> On 22/11/2018 23:33, Leopold Palomo-Avellaneda wrote:
>> Subject: transition: coin3
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Severity: normal
>>
>> Dear release team,
>>
>> I would like to ask a transition slot for the coin3 library. The package
>> has been reworked and a new version of the upstream has been packaged.
>>
>> Upstream have changed the build system to CMake and this has been used
>> for the package. This has an implication that it will break with FTBFS
>> the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I
>> have contacted with all the maintainers and they are aware about it and
>> we are preparing patches or simple disable in any case.
> 
> Where are you discussing that? I don't see bug reports for those packages.
> Please file bugs so that we can track the status and decide when to start this
> transition based on the disruption that it will cause. Also please make those
> bugs block this one.
Dear release team,

we have two packages in new with versions that built against coin3 in
experimental:

https://ftp-master.debian.org/new/soqt_1.6.0~ea5cd76+ds1-1~exp1.html
https://ftp-master.debian.org/new/pivy_0.6.4-1~exp1.html

both are the version more problematic and FTBFS without these new
versions. Please, could you push coin3 to unstable to initiate the
transition to make all this versions be built?

freecad needs both. We have built freecad with both and works perfectly.

Best 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?



Bug#916321: ITP: plotsauce -- Survex 3d file to XML converter

2018-12-12 Thread Leopold Palomo-Avellaneda
El 13/12/18 a les 2:37, Wookey ha escrit:
> Package: wnpp
> Severity: wishlist
> Owner: Wookey 
> 
> * Package name: plotsauce
>   Version : 0.1
>   Upstream Author : Philip Schuchardt 
> * URL : https://github.com/vpicaver/plotsauce
> * License : GPL2 or later
>   Programming Lang: C++
>   Description : Survex 3d file to XML converter
> 
> Qt-based utility to convert Survex 3d files into XML. Survex is cave
> surveying software, and the .3d file is its default output format.
> 
> 
> This package is used by cavewhere (ITP:836249).
> 
The correct url is:

https://github.com/Cavewhere/plotsauce

-- 
--
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?



Bug#874727: New version of coin3

2018-12-12 Thread Leopold Palomo-Avellaneda
Hi,

see:

https://lists.debian.org/debian-science/2018/12/msg00028.html

Cheers,

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?



signature.asc
Description: OpenPGP digital signature


Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

2018-12-03 Thread Leopold Palomo-Avellaneda
El 30/11/18 a les 15:16, Thorsten Glaser ha escrit:
> On Fri, 30 Nov 2018, Pirate Praveen wrote:
> 
>> That is indeed the current definition. The question is about the
>> possibility of changing that definition or finding other ways to

maybe creating another kind of repo. debian-contributuions debian-blabla, 
whatever.

[...]


> If your upstreams aren’t, they’re probably not worth the
> effort using the software.

well, Debian is using gitlab!!! so this sentence has no sense. The problem here
is that is a complex software that depends of a lot of pieces and it's not
easy/possible to fit the definition. So, maybe we should create another category
of software.

Cheers,

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?



signature.asc
Description: OpenPGP digital signature


Bug#915383: freecad: Freecad using new version of coin3 with cmake

2018-12-03 Thread Leopold Palomo-Avellaneda
Package: freecad
Severity: grave
Justification: renders package unusable

Dear Maintainer,

coin3 is in experimental and is in the beginning of a transition to a new 
version built with cmake.
freecad will need to use this version.



-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freecad depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0   1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-signals1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u3
pn  libcoin80v5 
ii  libfreeimage3   3.17.0+ds1-5
ii  libfreetype62.6.3-3.2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  liboce-foundation10 0.17.2-2
ii  liboce-modeling10   0.17.2-2
ii  liboce-ocaf-lite10  0.17.2-2
ii  liboce-ocaf10   0.17.2-2
ii  liboce-visualization10  0.17.2-2
ii  libpyside1.21.2.2-2+b1
ii  libpython2.72.7.13-2+deb9u3
ii  libqt4-network  4:4.8.7+dfsg-11
ii  libqt4-opengl   4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libqtwebkit42.3.4.dfsg-9.1
ii  libshiboken1.2v51.2.2-3.1
ii  libsoqt4-20 1.6.0~e8310f-3
ii  libspnav0   0.2.3-1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libx11-62:1.6.4-3+deb9u1
ii  libxerces-c3.1  3.1.4+debian-2+deb9u1
ii  libxext62:1.3.3-1+b2
ii  libzipios++0v5  0.1.5.9+cvs.2007.04.28-6
ii  pyside-tools0.2.15-1+b1
ii  python  2.7.13-2
ii  python-collada  0.4-2
ii  python-matplotlib   2.0.0+dfsg1-2
pn  python-pivy 
ii  python-ply  3.9-1
ii  python-pyside   1.2.2-2
ii  python2.7   2.7.13-2+deb9u3
ii  zlib1g  1:1.2.8.dfsg-5

freecad recommends no packages.

Versions of packages freecad suggests:
ii  graphviz  2.38.0-17
pn  povray



Bug#875186: New version in salsa

2018-12-03 Thread Leopold Palomo-Avellaneda
There's a new version of the package in

https://salsa.debian.org/science-team/soqt/tree/Qt5


it builds soqt with qt5 and coin3 cmake version.


-- 
--
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?



signature.asc
Description: OpenPGP digital signature


Bug#915371: pivy: Coin3 cmake transition

2018-12-03 Thread Leopold Palomo-Avellaneda
Source: pivy
Severity: grave
Justification: renders package unusable

Dear Maintainer,

coin3 is doing a transition to 4.0.0 using CMake as build system.

During the test the package FTBFS using the version that is in experimental. 
Please, check this version.



-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#914392: transition: coin3

2018-11-28 Thread Leopold Palomo-Avellaneda
El 28/11/18 a les 19:12, Emilio Pozuelo Monfort ha escrit:
> On 22/11/2018 23:33, Leopold Palomo-Avellaneda wrote:
>> Subject: transition: coin3
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Severity: normal
>>
>> Dear release team,
>>
>> I would like to ask a transition slot for the coin3 library. The package
>> has been reworked and a new version of the upstream has been packaged.
>>
>> Upstream have changed the build system to CMake and this has been used
>> for the package. This has an implication that it will break with FTBFS
>> the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I
>> have contacted with all the maintainers and they are aware about it and
>> we are preparing patches or simple disable in any case.
> 
> Where are you discussing that? 

Almost all of them in private mails. I will adopt SoQt. I have been
working with that package and Anton Gladky know all my work. You can
check [1] qt5 branch.

With Kurt Kremitzki (freecad and pivy) we are in contact about how to
solve the migration.

And with openscenegraph I have interchanged some mail with one of the
maintainer about that.

I don't see bug reports for those packages.
> Please file bugs so that we can track the status and decide when to start this
> transition based on the disruption that it will cause. Also please make those
> bugs block this one.

we are waiting to have coin in unstable to push new versions/patches. About:

- soqt, no problematic. I have done it
- pivy. I was not able to build it with the coin3 cmake version. Waiting
that Kurt work on it. I'm not an Python expert. But it should be reasonable.
- Freecad, depends on pivy. The new version doesn't depends on soqt.
- openscengraph, it only uses coin to import wrl files in a plugin. In
the worse case it can be disabled, but that

Are you proposing that I fill a bug before the package fails?

Cheers,


Leopold


[1] https://salsa.debian.org/science-team/soqt/tree/Qt5



-- 
--
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?



signature.asc
Description: OpenPGP digital signature


Bug#914392: transition: coin3

2018-11-22 Thread Leopold Palomo-Avellaneda
Subject: transition: coin3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Dear release team,

I would like to ask a transition slot for the coin3 library. The package
has been reworked and a new version of the upstream has been packaged.

Upstream have changed the build system to CMake and this has been used
for the package. This has an implication that it will break with FTBFS
the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I
have contacted with all the maintainers and they are aware about it and
we are preparing patches or simple disable in any case.

Coin3 also is affected by one bug #874727 (serious) that have marked the
package to autoremoval. The two bugs of the sources are referring to the
inclusion of a embed copy of expat that in this version is dropped.

In the case of soqt, I have a new version adapted for coin3 with cmake.
When it enter to unstable we will push it.

Best regards,


Leopold

-

Ben file:

title = "coin3";
is_affected = .depends ~
/\b(libcoin\-dev|libcoin\-doc|libcoin\-runtime|libcoin80c|libcoin80\-dev|libcoin80\-doc|libcoin80\-r
is_good = .depends ~
/\b(libcoin\-dev|libcoin\-doc|libcoin\-runtime|libcoin80c)\b/;
is_bad = .depends ~
/\b(libcoin80\-dev|libcoin80\-doc|libcoin80\-runtime|libcoin80v5)\b/;


-- 

--
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?





signature.asc
Description: OpenPGP digital signature


Bug#907166: gitlab: Unneeded steps during update/upgrade

2018-08-24 Thread Leopold Palomo-Avellaneda
Package: gitlab
Version: 8.13.11+dfsg1-8+deb9u3
Severity: normal

Dear Maintainer,

upgrading or updating gitlab is a pain when you have a lot of repositories. 
Configuring
gitlab makes a:

- Making gitlab owner of /var/lib/gitlab...
- Creating runtime directories for gitlab...
- Updating file permissions... chown 

is you are updating, in theory these steps are done. The problem is that if you 
have a big
repositories or a lot of repositories, these steps are huge time consuming with 
no sense because
the permissions are correct in a running gitlab instance.

Please, could you check if is this necessary when you update/upgrade?

Thx.

Leopold

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b3
ii  bundler   1.13.6-2
ii  dbconfig-pgsql2.0.8
ii  debconf [debconf-2.0] 1.5.61
ii  exim4 4.89-2+deb9u3
ii  exim4-daemon-light [mail-transport-agent  4.89-2+deb9u3
ii  git   1:2.11.0-3+deb9u3
ii  gitlab-shell  3.6.6-4
ii  gitlab-workhorse  0.8.5+debian-3+b2
ii  init-system-helpers   1.48
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nginx 1.10.3-1+deb9u1
ii  nginx-full [nginx]1.10.3-1+deb9u1
ii  nodejs4.8.2~dfsg-1
ii  openssh-client1:7.4p1-10+deb9u4
ii  postgresql-client 9.6+181+deb9u2
ii  postgresql-client-9.6 [postgresql-client  9.6.10-0+deb9u1
ii  postgresql-contrib9.6+181+deb9u2
ii  rake  10.5.0-2
ii  redis-server  3:3.2.6-3+deb9u2
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-5
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser   0.5.8-1
ii  ruby-fog-aws  0.12.0-1
ii  ruby-fog-azure0.0.2-1
ii  ruby-fog-core 1.42.0-1
ii  ruby-fog-google   0.3.2-1
ii  ruby-fog-local0.3.0-1
ii  ruby-fog-openstack0.1.6-4
ii  ruby-fog-rackspace0.1.1-4
ii  ruby-fogbugz  0.2.1-3
ii  ruby-font-awesome-rails   4.6.3.0-2
ii  ruby-gemnasium-gitlab-service   

Bug#802919: stretch-backport of unison

2018-05-20 Thread Leopold Palomo-Avellaneda
El 20/05/18 a les 16:02, Stéphane Glondu ha escrit:
> Le 19/05/2018 à 18:08, Leopold Palomo-Avellaneda a écrit :
>> I'm having sync problems and crashes with unison of stretch. See:
>>
>> https://github.com/bcpierce00/unison/issues/94#issuecomment-390412441
> 
> I've just commented on this issue.
> 
>> I think that all is referred to the same issue.
> 
> Indeed.
> 
>> Please, could you create a backport in stretch?
> 
> As I said, I think a binNMU is sufficient. I will look into it.
> 

perfect!!

Do whatever you think is better to solve that issue.

Thanks.


-- 
--
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?



Bug#802919: stretch-backport of unison

2018-05-19 Thread Leopold Palomo-Avellaneda
Hi,

I'm having sync problems and crashes with unison of stretch. See:

https://github.com/bcpierce00/unison/issues/94#issuecomment-390412441


I think that all is referred to the same issue. Please, could you create
a backport in stretch?

Thx

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?



Bug#889908: gitlab: missing gem in the Gemfile

2018-02-09 Thread Leopold Palomo-Avellaneda
On 09/02/18 09:32, Pirate Praveen wrote:
> On വ്യാഴം 08 ഫെബ്രുവരി 2018 10:06 വൈകു, Leopold Palomo-Avellaneda wrote:
>> Please, could you give me some workaround to solve this issue?
> 
> You will need to set environment variable DB. See
> https://salsa.debian.org/ruby-team/gitlab/raw/debian/8.13.11+dfsg1-8/debian/README.Debian
> 
> 

Running this:

runuser -u gitlab -- sh -c 'cd /usr/share/gitlab && .
/etc/gitlab/gitlab-debian.conf && export DB RAILS_ENV && rake gitlab:check
RAILS_ENV=production'

I got this:

D, [2018-02-09T10:54:56.488801 #1412] DEBUG -- sentry: ** [Raven] Specified
'postgresql' for database adapter, but the gem is not loaded. Add `gem 'pg'` to
your Gemfile (and ensure its version is at the minimum required by
ActiveRecord). excluded from capture due to environment or should_capture 
callback
rake aborted!
Gem::LoadError: Specified 'postgresql' for database adapter, but the gem is not
loaded. Add `gem 'pg'` to your Gemfile (and ensure its version is at the minimum
required by ActiveRecord).
/usr/share/gitlab/config/environment.rb:5:in `'
Gem::LoadError: pg is not part of the bundle. Add it to Gemfile.
/usr/share/gitlab/config/environment.rb:5:in `'
Tasks: TOP => gitlab:check => gitlab:gitlab_shell:check => environment
(See full trace by running task with --trace)


But, if I run this:

runuser -u gitlab -- sh -c 'cd /usr/share/gitlab && .
/etc/gitlab/gitlab-debian.conf && export DB=all RAILS_ENV && rake gitlab:check
RAILS_ENV=production'

if works.

Checking the Gemfile this part is problematic:


# Supported DBs
ENV["DB"] ||= "mysql"
gem "mysql2", '~> 0.3.16' if ENV["DB"] == "all" || ENV["DB"] == "mysql"
gem "pg", '~> 0.18.2' if ENV["DB"] == "all" || ENV["DB"] == "postgres"


changing this:

-ENV["DB"] ||= "mysql"
+ENV["DB"] ||= "all"

work is all cases.

I don't have sufficient knowledge to see if this is a bug or error from my own,
but there's something wrong here.

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?



signature.asc
Description: OpenPGP digital signature


Bug#889908: gitlab: missing gem in the Gemfile

2018-02-08 Thread Leopold Palomo-Avellaneda
Package: gitlab
Version: 8.13.11+dfsg1-8
Severity: normal

Dear Maintainer,


after have an instance of gitlab operative I have found that if I try to import
an existing git repo using this:

bundle exec rake gitlab:import:repos['import-repos/'] RAILS_ENV=production


I got this error:


 bundle exec rake gitlab:import:repos['import-repos/'] RAILS_ENV=production
D, [2018-02-08T17:10:40.489831 #1633] DEBUG -- sentry: ** [Raven] Specified
'postgresql' for database adapter, but the gem is not loaded. Add `gem 'pg'` to
your Gemfile (and ensure its version is at the minimum required by
ActiveRecord). excluded from capture due to environment or should_capture 
callback
rake aborted!
Gem::LoadError: Specified 'postgresql' for database adapter, but the gem is not
loaded. Add `gem 'pg'` to your Gemfile (and ensure its version is at the minimum
required by ActiveRecord).
/usr/share/gitlab/config/environment.rb:5:in `'
Gem::LoadError: pg is not part of the bundle. Add it to Gemfile.
/usr/share/gitlab/config/environment.rb:5:in `'
Tasks: TOP => gitlab:import:repos => environment
(See full trace by running task with --trace)


Please, could you give me some workaround to solve this issue?

Best regards,

Leopold



-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8),
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b3
ii  bundler   1.13.6-2
ii  dbconfig-pgsql2.0.8
ii  debconf [debconf-2.0] 1.5.61
ii  exim4 4.89-2+deb9u2
ii  exim4-daemon-light [mail-transport-agent  4.89-2+deb9u2
ii  git   1:2.11.0-3+deb9u2
ii  gitlab-shell  3.6.6-4
ii  gitlab-workhorse  0.8.5+debian-3+b2
ii  init-system-helpers   1.48
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nginx 1.10.3-1+deb9u1
ii  nginx-full [nginx]1.10.3-1+deb9u1
ii  nodejs4.8.2~dfsg-1
ii  openssh-client1:7.4p1-10+deb9u2
ii  postgresql-client 9.6+181+deb9u1
ii  postgresql-client-9.6 [postgresql-client  9.6.6-0+deb9u1
ii  postgresql-contrib9.6+181+deb9u1
ii  rake  10.5.0-2
ii  redis-server  3:3.2.6-1
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-5
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser 

Bug#868295: ITP: ros-image-pipeline -- Utilities to work from raw images to higher-level vision processing

2017-07-14 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

We (Robotics section of Debian Science team) are packaging
ROS (Robot OS: http://www.ros.org/) for Debian. ROS uses
many packages already in Debian, but also has a set of
core/toolchain/build-system packages which are not yet
uploaded. This package is part of that ROS system.

Most of the packaging work is already done, and available at
http://anonscm.debian.org/cgit/debian-science/packages/ros/

  Package name: ros-image-pipeline
  Version : 1.12.20
  URL : http://www.ros.org/wiki/image_pipeline
  License : BSD-3-Clause, Apache-2.0
  Programming Lang: C++, Python
  Description : Utilities to work from raw images to higher-level vision
processing

This package is part of Robot OS (ROS). This package fills the gap between
getting raw images from a camera driver and higher-level vision processing



Bug#841412: digikam: FTBFS: error with opencv 3.1

2017-06-30 Thread Leopold Palomo-Avellaneda
Hi,

activating in rules

-DENABLE_OPENCV3=ON \

digikam build witn OpenCV3.1. So, this shouldn't block opencv transition.

Leopold





-- 
--
Leopold Palomo-Avellaneda <leopold.pal...@upc.edu>
Institut d'Organització i Control de Sistemes Industrials -IOC-
Universitat Politècnica de Catalunya -UPC-

Institute of Industrial and Control Engineering
Technical University of Catalonia
Avda. Diagonal 647, pl. 11
08028 BARCELONA (Spain)

Tel. +34-934016655 (office)
Tel. +34-934017163 (lab)
Fax. +34-934016605



Bug#841411: libkf5kface: FTBFS: error with opencv 3.1

2017-06-29 Thread Leopold Palomo-Avellaneda
Hola Maximiliano,


I have investigated a bit to compile libkf5kface against opencv3.1. I have found
one patch from upstream and another to activate CMake to build against opencv 
3.1.

With this two patches libkf5kface builds but fail in the test:


/usr/bin/ctest --force-new-ctest-process -j8
Test project
/srv/drp/packages/opencv/transition/libkf5kface/libkf5kface-15.12.0/obj-x86_64-linux-gnu
Start 1: appstreamtest
1/1 Test #1: appstreamtest ***Failed0.01 sec
CMake Error at /usr/share/ECM/kde-modules/appstreamtest.cmake:1 (file):
  file failed to open for reading (No such file or directory):


/srv/drp/packages/opencv/transition/libkf5kface/libkf5kface-15.12.0/obj-x86_64-linux-gnu/install_manifest.txt




0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.01 sec

The following tests FAILED:
  1 - appstreamtest (Failed)


as it seems to be something more specific of the package, please could you check
it it the solution is trivial?

Thanks,

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?
>From ec6e82328cac37c9d59b49245b18c3f0abee4d8f Mon Sep 17 00:00:00 2001
From: Xuetian Weng 
Date: Sun, 6 Nov 2016 20:25:15 +0100
Subject: Add opencv 3.1 support

REVIEW: 126833
---
 src/recognition-opencv-lbph/facerec_borrowed.cpp | 41 ++--
 src/recognition-opencv-lbph/facerec_borrowed.h   |  9 ++
 2 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/src/recognition-opencv-lbph/facerec_borrowed.cpp b/src/recognition-opencv-lbph/facerec_borrowed.cpp
index 748691e..3c37ce2 100644
--- a/src/recognition-opencv-lbph/facerec_borrowed.cpp
+++ b/src/recognition-opencv-lbph/facerec_borrowed.cpp
@@ -36,6 +36,8 @@
  *
  *  */
 
+#define QT_NO_EMIT
+
 #include "facerec_borrowed.h"
 
 // C++ includes
@@ -375,7 +377,11 @@ void LBPHFaceRecognizer::train(InputArrayOfArrays _in_src, InputArray _inm_label
 }
 }
 
+#if OPENCV_TEST_VERSION(3,1,0)
 void LBPHFaceRecognizer::predict(InputArray _src, int , double ) const
+#else
+void LBPHFaceRecognizer::predict(cv::InputArray _src, cv::Ptr collector, const int state) const
+#endif
 {
 if(m_histograms.empty())
 {
@@ -394,8 +400,12 @@ void LBPHFaceRecognizer::predict(InputArray _src, int , double 
   m_grid_y,  /* grid size y */
   true   /* normed histograms   */
  );
+#if OPENCV_TEST_VERSION(3,1,0)
 minDist  = DBL_MAX;
 minClass = -1;
+#else
+collector->init((int)m_histograms.size(), state);
+#endif
 
 // This is the standard method
 
@@ -406,11 +416,19 @@ void LBPHFaceRecognizer::predict(InputArray _src, int , double 
 {
 double dist = compareHist(m_histograms[sampleIdx], query, CV_COMP_CHISQR);
 
+#if OPENCV_TEST_VERSION(3,1,0)
 if((dist < minDist) && (dist < m_threshold))
 {
 minDist  = dist;
 minClass = m_labels.at((int) sampleIdx);
 }
+#else
+int label = m_labels.at((int) sampleIdx);
+if (!collector->emit(label, dist, state))
+{
+return;
+}
+#endif
 }
 }
 
@@ -422,7 +440,7 @@ void LBPHFaceRecognizer::predict(InputArray _src, int , double 
 // Create map "label -> vector of distances to all histograms for this label"
 std::map distancesMap;
 
-for(size_t sampleIdx = 0; sampleIdx < m_histograms.size(); sampleIdx++) 
+for(size_t sampleIdx = 0; sampleIdx < m_histograms.size(); sampleIdx++)
 {
 double dist = compareHist(m_histograms[sampleIdx], query, CV_COMP_CHISQR);
 std::vector& distances = distancesMap[m_labels.at((int) sampleIdx)];
@@ -445,11 +463,18 @@ void LBPHFaceRecognizer::predict(InputArray _src, int , double 
 double mean = sum / it->second.size();
 s  += QString::fromLatin1("%1: %2 - ").arg(it->first).arg(mean);
 
+#if OPENCV_TEST_VERSION(3,1,0)
 if((mean < minDist) && (mean < m_threshold))
 {
 minDist = mean;
 minClass = it->first;
 }
+#else
+if (!collector->emit(it->first, mean, state))
+{
+return;
+}
+#endif
 }
 
 qCDebug(LIBKFACE_LOG) << s;
@@ -462,7 +487,7 @@ void LBPHFaceRecognizer::predict(InputArray _src, int , double 
 // map "label -> number of histograms"
 

Bug#849068: ITP: ros-opencv-apps -- OpenCV functionalities for Robot OS

2016-12-22 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
user: debian-scie...@lists.debian.org
usertag: ros
X-Debbugs-CC: debian-de...@lists.debian.org

We (Robotics section of Debian Science team) are packaging
ROS (Robot OS: http://www.ros.org/) for Debian. ROS uses
many packages already in Debian, but also has a set of
core/toolchain/build-system packages which are not yet
uploaded. This package is part of that ROS system.

Most of the packaging work is already done, and available at
http://anonscm.debian.org/cgit/debian-science/packages/ros/

  Package name: ros-opencv-apps
  Version : 1.11.14
  URL : http://wiki.ros.org/opencv_apps
  License : BSD-3-clause
  Programming Lang: C++
  Description : Functionalities from OpenCV for Robot OS

This package is part of Robot OS (ROS). It contains several ROS
packages for working providing OpenCV functionalities in a simplest
manner in ROS, i.e., running a launch file that corresponds to
the functionality.

Previously this package was inside ros-vision-opencv but upstream split
the package and create this one.



Bug#842846: New ros-vision-opencv transition

2016-11-01 Thread Leopold Palomo-Avellaneda
El dimarts, 1 de novembre de 2016, a les 19:49:35 CET, Emilio Pozuelo Monfort 
va escriure:
> Control: tags -1 confirmed
> 
> On 01/11/16 19:13, Leopold Palomo-Avellaneda wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear Release Team,
> > 
> > I'm filing this bug for a new transition of ros-vision-opencv. It is
> > in experimental. It builds on all architectures in testing, where it built
> > previously.
> 
> Go ahead.
> 
> BTW I'm happy if you skip the transition bug when only a small number of
> rdeps are involved and you maintain all of them (like in this case). Of
> course if you want to file the bug and wait for an ack, that is fine too!
> 
Thx,

just following the normal procedure. Although I agree that it's a bit heavy in 
these cases.

Cheers,

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?


signature.asc
Description: This is a digitally signed message part.


Bug#842846: New ros-vision-opencv transition

2016-11-01 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'm filing this bug for a new transition of ros-vision-opencv. It is 
in experimental. It builds on all architectures in testing, where it built 
previously. 


Ben file:

title = "ros-vision-opencv";
is_affected = .depends ~ 
/\b(libcv\-bridge1d|cl\-opencv\-apps|libcv\-bridge0d|libopencv\-apps\-dev|libopencv\-apps0d|opencv\-apps\-tools|python\-opencv\-apps)\b/
is_good = .depends ~ /\b(libcv\-bridge1d)\b/
is_bad = .depends ~ 
/\b(cl\-opencv\-apps|libcv\-bridge0d|libopencv\-apps\-dev|libopencv\-apps0d|opencv\-apps\-tools|python\-opencv\-apps)\b/

All reverse dependencies test rebuilds. All rdepends are listed here:

https://release.debian.org/transitions/html/auto-ros-vision-opencv.html

-- 
--
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?


signature.asc
Description: This is a digitally signed message part.


Bug#840165: fcl bug

2016-10-17 Thread Leopold Palomo-Avellaneda
I have deleted the hack to activate the SSE code. It seems that has no sense. 
Upstream clarifies in its CMakeLists: #always disable, for now.

It justs add -native as parameter to the compiler making it not generic. So 
it's better to disable.

Please Jochen, could you upload it?

Best 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?

signature.asc
Description: This is a digitally signed message part.


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

2016-08-30 Thread Leopold Palomo-Avellaneda
El Dimarts, 30 d'agost de 2016, a les 19:03:32, Gianfranco Costamagna va 
escriure:
> control: reopen -1
> control: reassign -1 src:kido
> control: found -1 0.1.0+dfsg-1
> control: tags -1 patch
> control: tags -1 pending
> 
> >I can confirm that this is not a bug in flann. As I said in a previous
> >message the problem is that the new flann version has incorporated lz4
> >code, so you must link against flann:
> >
> >$ pkg-config --libs flann
> >-lflann -lflann_cpp
> 
> seems that kido was already linking the correct libraries, but the testsuite
> wasn't. with your great help fixing became trivial.
> 
> BTW, why are you shipping a bundled lz4 library? this is against Debian
> policy, please consider using the system version.

because upstream do it. I have realized today that lz4 is embed. I'll contact 
with the author about that.

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?


signature.asc
Description: This is a digitally signed message part.


Bug#835930: flann: breaks reverse-dependencies

2016-08-29 Thread Leopold Palomo-Avellaneda
El Dilluns, 29 d'agost de 2016, a les 12:34:15, Gianfranco Costamagna va 
escriure:
> Source: flann
> Severity: serious
> Version: 1.9.1+dfsg-2
> 
> Justification: breaks reverse dependencies.
> 
> Hi, the latest flann broke kido build, now it fails with a missing LZ4 link.

there's no missing link IMHO. The problem is that the new flann version has 
incorporated lz4 code, so you must link against libflann_cpp, that has the lz4 
missing functions.

But I should investigate more ...


-- 
--
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?

signature.asc
Description: This is a digitally signed message part.


Bug#813470: Request for adoption

2016-07-11 Thread Leopold Palomo-Avellaneda
If no one is interested, I will try to maintain this package.
-- 
--
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?

signature.asc
Description: This is a digitally signed message part.


Bug#787259: Acknowledgement (start error with pbuilder-satisfydepends-gdebi)

2016-07-06 Thread Leopold Palomo-Avellaneda
On Fri, 27 May 2016 20:33:54 + Mattia Rizzolo  wrote:
> control: tag -1 unreproducible moreinfo
> 
> On Sun, Jun 07, 2015 at 01:55:25PM +0200, Mattia Rizzolo wrote:
> > On Sun, May 31, 2015 at 3:34 PM, Jörg Frings-Fürst
> >  wrote:
> > > The output of "sudo DIST=vivid pbuilder --update && DIST=vivid pdebuild 
| tee
> > > ../update_build_with_PBUILDERSATISFYDEPENDSCMD.log"
> > > ist attached.
> > 
> > there is not the --update bits.
> 
> Also, I got around actually trying it, and the gdebi resolvers just work
> fine.
> Do you still have problems with it?
> 

Hi,

I have been able to reproduce it. Well, I have had this error in one package 
since one year ago I have been very frustrating till Mattia target me to this 
bug.

To reproduce it, assuming that you have a pbuilder with unstable just:

mkdir assimp
cd assimp
apt-get source assimp
cd assimp-3.2~dfsg
DIST=unstable DEB_BUILD_OPTIONS="parallel=8" pdebuild

And  I can confirm that dropping the PBUILDERSATISFYDEPENDSCMD line and running 
update, the error disappears.

The question then is why this line could produce the error is some packages 
and in other no.

Leopold




signature.asc
Description: This is a digitally signed message part.


Bug#828966: transition: ros-ros-comm

2016-06-29 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'm filing this bug for a transition of ros-ros-comm . It is 
in experimental. It builds on all architectures in testing, where it built 
previously. 

Ben file:

title = "ros-ros-comm";
is_affected = .depends ~ 
/\b(libmessage\-filters1d|librosbag\-storage1d|librosbag1d|librosconsole2d|libroscpp1d|libroslz4\-1d|libtopic\-tools1d|libxmlrpcpp1d|libmessage\-filters0d|librosbag\-storage0d|librosbag0d|librosconsole1d|libroscpp0d|libroslz4\-0d|libtopic\-tools0d|libxmlrpcpp0d)\b/
is_good = .depends ~ 
/\b(libmessage\-filters1d|librosbag\-storage1d|librosbag1d|librosconsole2d|libroscpp1d|libroslz4\-1d|libtopic\-tools1d|libxmlrpcpp1d)\b/
is_bad = .depends ~ 
/\b(libmessage\-filters0d|librosbag\-storage0d|librosbag0d|librosconsole1d|libroscpp0d|libroslz4\-0d|libtopic\-tools0d|libxmlrpcpp0d)\b/

All reverse dependencies test rebuilds. All rdepends are listed here:
https://release.debian.org/transitions/html/auto-ros-ros-comm.html

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#827341: transition: octomap

2016-06-15 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'm filing this bug for a transition of octomap. It is 
in experimental. It builds on all architectures in testing, where it built 
previously. 


Ben file:

title = "octomap";
is_affected = .depends ~ 
/\b(libdynamicedt3d1\.8|liboctomap1\.8|liboctovis1\.8|libdynamicedt3d1\.6|libdynamicedt3d1\.6\-dbg|liboctomap1\.6v5|liboctomap1\.6v5\-dbg|liboctovis1\.6v5|liboctovis1\.6v5\-dbg)\b/
is_good = .depends ~ /\b(libdynamicedt3d1\.8|liboctomap1\.8|liboctovis1\.8)\b/
is_bad = .depends ~ 
/\b(libdynamicedt3d1\.6|libdynamicedt3d1\.6\-dbg|liboctomap1\.6v5|liboctomap1\.6v5\-dbg|liboctovis1\.6v5|liboctovis1\.6v5\-dbg)\b/

All reverse dependencies test rebuilds. All rdepends are listed here:

https://release.debian.org/transitions/html/auto-octomap.html

Thanks

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#824526: New libode version: transition

2016-05-17 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'm filing this bug for a new transition of ode (Open Dynamics Engine). It is 
in experimental. It builds on all architectures in testing, where it built 
previously. 


Ben file:

title = "ode";
is_affected = .depends ~ /\b(libode6|libode4)\b/
is_good = .depends ~ /\b(libode6)\b/
is_bad = .depends ~ /\b(libode4)\b/

All reverse dependencies test rebuilds. All rdepends are listed here:

https://release.debian.org/transitions/html/auto-ode.html


-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#820292: librosbag-storage-dev: Missing libbz2-dev dependency

2016-04-07 Thread Leopold Palomo-Avellaneda
Package: librosbag-storage-dev
Version: 1.11.16-5
Severity: important

Dear Maintainer (myself),

librosbag-storage-dev needs libbz2-dev as dependency. It has a file:
/usr/include/rosbag/chunked_file.h

that contains an include:

#include 

that belongs to libbz2-dev.

Thanks to  Mani Monajjemi

Leopold


-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librosbag-storage-dev depends on:
ii  libboost-date-time-dev1.55.0.2
ii  libboost-filesystem-dev   1.55.0.2
ii  libboost-program-options-dev  1.55.0.2
ii  libboost-regex-dev1.55.0.2
ii  libconsole-bridge-dev 0.2.5-2+b1
ii  librosbag-storage0d   1.11.16-4~drp8+20160222~drp8+20160222
ii  libroslz4-dev 1.11.16-4~drp8+20160222~drp8+20160222

librosbag-storage-dev recommends no packages.

librosbag-storage-dev suggests no packages.

-- no debconf information



Bug#807690: libassimp-dev: CMake files gives incorrect info

2015-12-11 Thread Leopold Palomo-Avellaneda
Package: libassimp-dev
Version: 3.2~dfsg-2
Severity: normal

Dear Maintainer,

I would like to tell you one bug I have found. I'm a bit shamed because 
it has been my fault, because I think that I introduce it with the last bug 
(#806317)

As the cmake files are installed, the some software that uses Assimp try to
use then searching the assimp-config file (CMake based). The problem is that in
that file there are these two lines:


set( ASSIMP_LIBRARIES assimp${ASSIMP_LIBRARY_SUFFIX})
set( ASSIMP_LIBRARIES ${ASSIMP_LIBRARIES})


upstream by default has:

set( ASSIMP_LIBRARIES assimp${ASSIMP_LIBRARY_SUFFIX})
set( ASSIMP_LIBRARIES ${ASSIMP_LIBRARIES}@CMAKE_DEBUG_POSTFIX@)

so, the cmake files return to the assimp users (developers) that to link
with assimp thery must link against -lassimpd, and that library doesn't exist 
in 
debian.

So, one simple way to solve it is to add in the rules file:

DEB_CMAKE_EXTRA_FLAGS=-DASSIMP_BUILD_ARCHITECTURE=$(DEB_HOST_ARCH) \
-DASSIMP_LIB_INSTALL_DIR=lib/$(DEB_HOST_MULTIARCH) \
-DCMAKE_SHARED_LINKER_FLAGS="$(LDFLAGS)" \
-DCMAKE_EXE_LINKER_FLAGS="$(LDFLAGS)" \   
-DCMAKE_INSTALL_PREFIX=/usr \
-DBUILD_ASSIMP_SAMPLES=OFF \ 
-DASSIMP_BUILD_TESTS=OFF \   
-DCMAKE_DEBUG_POSTFIX='' \   
-DASSIMP_ENABLE_BOOST_WORKAROUND=OFF

the   -DCMAKE_DEBUG_POSTFIX='' 

Sorry for the noise produced. I hope that not too much package had the FTBFS 
label.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libassimp-dev depends on:
ii  libassimp3  3.2~dfsg-1~drp8+3

libassimp-dev recommends no packages.

libassimp-dev suggests no packages.

-- no debconf information



Bug#806317: libassimp-dev: Missing CMake package files

2015-11-26 Thread Leopold Palomo-Avellaneda
Package: libassimp-dev
Version: 3.2~dfsg-1
Severity: normal
Tags: patch

Dear Maintainer,

asssimp upstream provides some files from CMake to help the 
developers to use its library. That files are installed in
lib/*/cmake

Just modifiying libassimp-dev.install and adding:

debian/tmp/usr/lib/*/cmake

the user that use cmake just doing:
 find_package(assimp REQUIRED NO_MODULE)

cmake will found the library filling the needed information.


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libassimp-dev depends on:
ii  libassimp3  3.2~dfsg-1~drp8+1

libassimp-dev recommends no packages.

libassimp-dev suggests no packages.

-- no debconf information



Bug#804728: FTBFS: libode-sp-dev has been dropped

2015-11-10 Thread Leopold Palomo-Avellaneda
Source: soya
Severity: serious

soya needs ode to be built. ode has a new version in unstable that  
has dropped the sp (single precession) version. Also, ode has been upgraded
to 0.13.1 version. So, soya  will fail till its Build-depends field change 
from libode-sp-dev to libode-dev and had been upgraded to ode 0.13.x.



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#804727: FTBFS: libode-sp-dev has been dropped

2015-11-10 Thread Leopold Palomo-Avellaneda
Package: mokomaze
Version: 0.5.5+git8+dfsg0-3
Severity: serious
Justification: Policy 7.1

Mokomaze needs ode to be built. ode has a new version in unstable that
has dropped the sp (single precession) version. So, mokomaze will fail till
its Build-depends field change from libode-sp-dev to libode-dev.

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mokomaze depends on:
ii  fonts-liberation  1.07.4-1
ii  libc6 2.19-18+deb8u1
ii  libode1sp 2:0.11.1-4.1
ii  libsdl-image1.2   1.2.12-5+b5
ii  libsdl-ttf2.0-0   2.0.11-3
ii  libsdl1.2debian   1.2.15-10+b1

mokomaze recommends no packages.

mokomaze suggests no packages.

-- no debconf information



Bug#804285: transition: ode

2015-11-09 Thread Leopold Palomo-Avellaneda
El Dilluns, 9 de novembre de 2015, a les 19:11:05, Emilio Pozuelo Monfort va 
escriure:
> Control: tags -1 confirmed
> 
> On 06/11/15 23:53, Leopold Palomo-Avellaneda wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear Release Team,
> > 
> > I'm filing this bug for a new transition of ode (Open Dynamics Engine).
> > 
> > In Debian we have a version too old (0.11.1-4.1, 2009-05-25). The package
> > has been rewritten and a new version has been uploaded to experimental
> > (0.13.1+git20150309-1). This version has been tested with the ode build
> > dependencies with this result:
> > 
> > darkplaces: ok, built
> > k3d: ok, built
> > mokomaze: ok, built
> > mu-cade: ok built
> > ompl: ok built
> > pyepl: ok built
> > pyode: ok built
> > soya: too old the debian version. Upstream didn't test the new version
> > with 0.13.x ode taoframework: ok, built
> > stormbaancoureur: ok. built
> > xmoto: ok, built
> 
> You can go ahead with this.
> 
> Note that a couple of packages (mokomaze, soya) build-depend on the old
> libode-sp-dev. Please file bugs with severity serious against those two
> packages and make them block this bug.

Sorry. I don't understand it.

Are you asking me that I fill a bug against a package because FTBFS "before" 
upload it to unstable or "after" upload it and it failed?


-- 
--
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?


signature.asc
Description: This is a digitally signed message part.


Bug#804285: transition: ode

2015-11-06 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'm filing this bug for a new transition of ode (Open Dynamics Engine). 

In Debian we have a version too old (0.11.1-4.1, 2009-05-25). The package has 
been 
rewritten and a new version has been uploaded to experimental 
(0.13.1+git20150309-1). 
This version has been tested with the ode build dependencies with this result:

darkplaces: ok, built
k3d: ok, built
mokomaze: ok, built
mu-cade: ok built
ompl: ok built
pyepl: ok built
pyode: ok built
soya: too old the debian version. Upstream didn't test the new version with 
0.13.x ode
taoframework: ok, built
stormbaancoureur: ok. built
xmoto: ok, built


Ben file:

title = "ode";
is_affected = .depends ~ /\b(libode4|libode\-sp\-dev|libode1|libode1sp)\b/;
is_good = .depends ~ /\b(libode4)\b/;
is_bad = .depends ~ /\b(libode\-sp\-dev|libode1|libode1sp)\b/;



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#788418: New upload in mentors

2015-10-14 Thread Leopold Palomo-Avellaneda
El Dimecres, 14 d'octubre de 2015, a les 09:55:02, Herbert Parentes Fortes 
Neto va escriure:
> Hi Ghislain,
> 
> > Alright, I have uploaded a new candidate package on mentors.
> > 
> > However, the lintian on mentors shows an error that I cannot reproduce
> > locally on my gbp build. The error is the following:
> > 
> > postinst-must-call-ldconfig
> > 
> > and makes no-sense to me, as I am not doing anything much differently
> > from the previous upload. Besides, my local lintian does not show it.
> > 
> > Thoughts?
> 
> Your local lintian is 'sid' ? If so, it is a different
> version of mentors, I believe.
> 
> I asked the same question days ago. And debhelper on
> sid should take care of it.

I have found the same odd behavior. In one of my boxes, with wheezy and 
lintian 2.5.30+deb8u2~bpo70+1 I have that message.

However, in another box with jessie and lintian 2.5.38~bpo8+1 it doesn't 
appears.

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?

signature.asc
Description: This is a digitally signed message part.


Bug#797281: ompl ftbfs because boost

2015-09-09 Thread Leopold Palomo-Avellaneda
Dear reporter,

the problem with this bug is a problem of boost 1.58 and gcc5. Ompl builds 
without any problem with boost 1.59 and gcc5. 

798021 has a patch. Just need that boost maintainers upload a new version of 
boost 1.58 of upgrade boost-defaults to 1.59.

Thanks

Leopold



Bug#792386: fltk1.3: Wrong .cmake file or lib filename

2015-07-14 Thread Leopold Palomo-Avellaneda
Source: fltk1.3
Version: 1.3.3-1
Severity: normal

Dear Maintainer,

* What led up to the situation?

We are trying to use the libfltk-dev package to build some piece of software 
and 
we are getting CMake Errors:

CMake Error at /usr/lib/fltk/FLTK-Targets.cmake:102 (message):
  The imported target fltk_cairo_SHARED references the file

 /usr/lib/x86_64-linux-gnu/libfltk_cairo.so.1.3.3

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 /usr/lib/fltk/FLTK-Targets.cmake

  but not all the files it references.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

using it with cmake


The question is that that file expects to have 
/usr/lib/x86_64-linux-gnu/libfltk_cairo.so.1.3.3. 
Looking on the sources and your rules file the file is not created. However, 
calling 
cmake with plain parameters the file and the corresponding links are created:

lrwxrwxrwx 1 root drp  20 jul 14 10:56 libfltk_cairo.so - 
libfltk_cairo.so.1.3
lrwxrwxrwx 1 root drp  22 jul 14 10:56 libfltk_cairo.so.1.3 - 
libfltk_cairo.so.1.3.3
-rwxr-xr-x 1 root drp   15936 jul 14 10:56 libfltk_cairo.so.1.3.3

So, it's something related to your rules. The package is no built with needed 
links.
Please could you take on eye on it because for us the package is unusable?


*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


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



Bug#783109: Aw: Bug#783109: ITP: orocos-kdl -- Orocos Kinematics and Dynamics Library

2015-04-22 Thread Leopold Palomo-Avellaneda
El Dimecres, 22 d'abril de 2015, a les 15:03:32, Steffen Möller va escriure:
 Hi Leopold,
 
 I would definitely wish to have the time to play with this. The least I can
 do is to help with sponsoring.
 
 Ping me.

Pong

the package is almost done:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/kdl.git

and almost lintian clean.

If you want to test it:

http://sir.upc.edu/debian-robotics/pool/main/o/orocos-kdl/

or,

http://mentors.debian.net/package/orocos-kdl


also, 


https://launchpad.net/~deb-rob/+archive/ubuntu/ros-trusty/+sourcepub/4957488/+listing-archive-extra

And, yes, let me make a final check and please, sponsor it.

Leopold



 Steffen
 
  Gesendet: Mittwoch, 22. April 2015 um 12:37 Uhr
  Von: Leopold Palomo-Avellaneda l...@alaxarxa.net
  An: Debian Bug Tracking System sub...@bugs.debian.org
  Betreff: Bug#783109: ITP: orocos-kdl -- Orocos Kinematics and Dynamics
  Library
  
  Package: wnpp
  Severity: wishlist
  Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net
  
  * Package name: orocos-kdl
  
Version : 1.3.0
Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
  
  * URL : http://www.orocos.org/kdl
  * License : LGPL
  
Programming Lang: C++
Description : Orocos Kinematics and Dynamics Library
  
  Orocos project to supply RealTime usable kinematics and dynamics code,
  it contains code for rigid body kinematics calculations and
  representations for kinematic structures and their inverse and forward
  kinematic solvers. This package contains the development files
  of the library.
  
  - why is this package useful/relevant?
  
  Yes, it's a good kinematics and dynamics library, especially for kinematic
  chains.
  
  - is it a dependency for  another package? do you use it? if there are
  other packages 
providing similar functionality, how does it compare?
  
  A lot of robotics packages use it. We use it in our lab. AFAIK, not other
  are so complete and well designed.
  
  - how do you plan to maintain it? inside a packaging team?
  
  Inside debian-science team. I have done a preliminary work in:
  
  http://anonscm.debian.org/cgit/debian-science/packages/orocos/kdl.git
  
  - are you looking for co-maintainers? do you need a sponsor?
  
  Yes, both. Any help will be welcome. It's better to have co-maintainers.

-- 
--
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?

signature.asc
Description: This is a digitally signed message part.


Bug#783109: ITP: orocos-kdl -- Orocos Kinematics and Dynamics Library

2015-04-22 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net

* Package name: orocos-kdl
  Version : 1.3.0
  Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
* URL : http://www.orocos.org/kdl
* License : LGPL
  Programming Lang: C++
  Description : Orocos Kinematics and Dynamics Library

Orocos project to supply RealTime usable kinematics and dynamics code,
it contains code for rigid body kinematics calculations and
representations for kinematic structures and their inverse and forward
kinematic solvers. This package contains the development files
of the library.

- why is this package useful/relevant? 

Yes, it's a good kinematics and dynamics library, especially for kinematic
chains.

- is it a dependency for  another package? do you use it? if there are other 
packages
  providing similar functionality, how does it compare?

A lot of robotics packages use it. We use it in our lab. AFAIK, not other
are so complete and well designed.

- how do you plan to maintain it? inside a packaging team?

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/kdl.git

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. It's better to have co-maintainers.


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



Bug#783008: ITP: orocos-utilrb -- Ruby toolkit: collection of useful Ruby classes

2015-04-20 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net

* Package name: orocos-utilrb
  Version : 2.8.0
  Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
* URL : https://github.com/orocos-toolchain/utilrb
* License : CeCILL-B (BSD-like)
  Programming Lang: ruby
  Description : Ruby toolkit: collection of useful Ruby classes

Utilrb is yet another Ruby toolkit, in the spirit of facets. It includes
all the standard class extensions used in other projects.

- why is this package useful/relevant? is it a dependency for
  another package? 

Yes, orocos-utilrb belongs to orocos-toolchain (as project)

- do you use it? if there are other packages providing similar functionality, 
  how does it compare?

We use it in our lab. Not known. Orocos developers use it.

- how do you plan to maintain it? inside a packaging team (check list at
https://wiki.debian.org/Teams)? 

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/utilrb.git

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. All orocos-toolkit is a complex piece
of software.


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



Bug#783016: ITP: orocos-typelib -- C/C++ type introspection library

2015-04-20 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net

* Package name: orocos-typelib
  Version : 2.8.0
  Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
* URL : https://github.com/orocos-toolchain/typelib
* License : CeCILL-B (BSD-like)
  Programming Lang: C++ and Ruby
  Description : C/C++ type introspection library

This library offers an introspection mechanism for C/C++ value-types. I.e.
it offers a way to represent types, and to manipulate in-memory values
that are instances of those types.

A Ruby binding is included, which gives a fast and transparent
modification of C/C++ in-memory types from Ruby.

- why is this package useful/relevant? is it a dependency for
  another package? 

Yes, orocos-typelib belongs to orocos-toolchain (as project)

- do you use it? if there are other packages providing similar functionality, 
  how does it compare?

We use it in our lab. Not known is there's another with similar
functionality. 

- how do you plan to maintain it? inside a packaging team (check list at 
https://wiki.debian.org/Teams)? 

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/typelib.git

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. All orocos-toolkit is a complex piece
of software.


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



Bug#782745: ITP: orocos-log4cpp -- C++ library for flexible logging

2015-04-17 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net

* Package name: orocos-log4cpp
  Version : 2.8.0
  Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
* URL : https://github.com/orocos-toolchain/log4cpp
* License : LGPL
  Programming Lang: C++
  Description : C++ library for flexible logging

Log for C++ is a library of C++ classes for flexible logging to files,
syslog and other destinations. Orocos-log4cpp is maintained by Orocos
developers. This version of log4cpp deviates from the official release
by adding custom category factories. Orocos requires this for setting
up real-time logging.

- why is this package useful/relevant? is it a dependency for
  another package? 

Yes, orocos-ocl that belongs to orocos-toolchain (as project)

- do you use it? if there are other packages providing similar functionality, 
  how does it compare?

We use it in our lab. Yes, we have another version in debian of the same.
This is a fork, with more capabilities of log4cpp. 

I have tried to convince upstream to fusion both projects. Also I have tried
to do it myself, but I was not able to that. The orocos developers have
design their fork in the way that could be co-installabled, because they
have increased the SONAME. However, the -dev package is not co-installable
with the original one.

Also, I have renamed this version with orocos-log4cpp.
 
- how do you plan to maintain it? inside a packaging team (check list at 
https://wiki.debian.org/Teams)? 

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/log4cpp.git

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. All orocos-toolkit is a complex piece
of software.


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



Bug#782623: ITP: orocos-ocl -- Orocos Component Library

2015-04-15 Thread Leopold Palomo-Avellaneda
El Dimecres, 15 d'abril de 2015, a les 13:33:51, Andreas Tille va escriure:
 Hi Leopold,
 
 it seems you missed to CC debian-science list which I'm hereby doing. :-)
 You probably know how SoB works ...

Hi Andreas,

my fault. I'm sorry. orocos is a monster and package it requires a lot of 
work. I was concentrate on it and I forget this step. Also, I forget orocos-
rtt #782210.

Best regards,

Leopold

 Kind regards
 
   Andreas.
 
 On Wed, Apr 15, 2015 at 08:11:16AM +0200, Leopold Palomo-Avellaneda wrote:
  Package: wnpp
  Severity: wishlist
  Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net
  
  * Package name: orocos-ocl
  
Version : 2.8.0
Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
  
  * URL : http://www.orocos.org/
  * License : GPL + runtime exception
  
Programming Lang: C++ and lua
Description : Orocos Component Library
  
  The Orocos Real-Time Toolkit (RTT) is not an application
  in itself, but it provides the infrastructure and the
  functionalities to build robotics applications in C++. The Orocos
  Component Library is a set of components in libraries.
  
  - why is this package useful/relevant? is it a dependency for another
  package?
  
  It's a complement for the orocos-rtt library. To have the complete
  orocos-toolchain you need it. Also, helps to develop components with the
  orocos-rtt library.
  
  - do you use it?
  
  Yes, we use it at the lab where I work.
  
  - if there are other packages providing similar functionality, how does it
  - compare?
  
  ROS is another framework.
  
  - how do you plan to maintain it? inside a packaging team?
  
  Inside debian-science team. I have done a preliminary work in:
  
  http://anonscm.debian.org/cgit/debian-science/packages/orocos/ocl.git/
  
  - are you looking for co-maintainers? do you need a sponsor?
  
  Yes, both. Any help will be welcome. It's a orocos is a complex package.

-- 
--
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?

signature.asc
Description: This is a digitally signed message part.


Bug#782623: ITP: orocos-ocl -- Orocos Component Library

2015-04-15 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net

* Package name: orocos-ocl
  Version : 2.8.0
  Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
* URL : http://www.orocos.org/
* License : GPL + runtime exception
  Programming Lang: C++ and lua
  Description : Orocos Component Library

The Orocos Real-Time Toolkit (RTT) is not an application
in itself, but it provides the infrastructure and the
functionalities to build robotics applications in C++. The Orocos
Component Library is a set of components in libraries.

- why is this package useful/relevant? is it a dependency for another package? 

It's a complement for the orocos-rtt library. To have the complete
orocos-toolchain you need it. Also, helps to develop components with the
orocos-rtt library.

- do you use it? 

Yes, we use it at the lab where I work.

- if there are other packages providing similar functionality, how does it
- compare?

ROS is another framework.

- how do you plan to maintain it? inside a packaging team?

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/ocl.git/

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. It's a orocos is a complex package.


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



Bug#726500: fglrx-legacy-driver in Jessie

2015-04-13 Thread Leopold Palomo-Avellaneda
Hi,

may I understand that we won't have this driver in Jessie?
-- 
--
Leopold Palomo-Avellaneda leopold.pal...@upc.edu
Institut d'Organització i Control de Sistemes Industrials -IOC-
Universitat Politècnica de Catalunya -UPC-

Institute of Industrial and Control Engineering
Technical University of Catalonia
Avda. Diagonal 647, pl. 11
08028 BARCELONA (Spain)

Tel. +34-934016655 (office)
Tel. +34-934017163 (lab)
Fax. +34-934016605


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



Bug#782210: ITP: orocos-rtt -- Orocos Real-Time Toolkit

2015-04-09 Thread Leopold Palomo-Avellaneda
Package: wnpp
Severity: wishlist
Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net

* Package name: orocos-rtt
  Version : 2.8.0
  Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
* URL : http://www.orocos.org/
* License : GPL + runtime exception
  Programming Lang: C++
  Description : Orocos Real-Time Toolkit

The Orocos Real-Time Toolkit (RTT) is not an application
in itself, but it provides the infrastructure and the
functionalities to build robotics applications in C++. The
emphasis is on real-time, online interactive and
component based applications.

- why is this package useful/relevant? 

It's an important package in the robotics world. It's a
useful framework to build robotics components.

- is it a dependency for another package? 

Another packages in the orocos toolbox. You cannot have the 
complete orocos toolbox if you don't have it.

- do you use it? 

Yes, we use it at the lab where I work.

- if there are other packages providing similar functionality, how does it 
compare?

ROS is another framework, and it's also in the todo list.

- how do you plan to maintain it? inside a packaging team?

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/rtt.git/

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. It's a complex package.


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



Bug#780527: debian-maintainers: Please add Leopold Palomo-Avellaneda as a Debian Maintainer

2015-03-15 Thread Leopold Palomo-Avellaneda
Package: debian-maintainers
Severity: normal

Dear Maintainer,

Please add Leopold Palomo-Avellaneda to the keyring.
The jetring changeset is attached.

Best regards,

Leopold

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Comment: Add Leopold Palomo-Avellaneda l...@alaxarxa.net as a Debian 
Maintainer
Date: Sun, 15 Mar 2015 17:15:16 +0100
Action: import
Recommended-By: 
  Andreas Tille andr...@an3as.eu,
  Nobuhiro Iwamatsu iwama...@nigauri.org
Agreement: 
  https://lists.debian.org/debian-newmaint/2015/02/msg00012.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2015/02/msg00014.html
  https://lists.debian.org/debian-newmaint/2015/03/msg3.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFMkGbgBEACh2k6hN3AceFEuJEL32RGDQ63hTLd4iuGOy0fuBMXHLKszPslk
  BeZRd3CjNMVWYPLz7KGG98al0tLwA2SQLhmDoZlWOCh0gcg280D0K7Oja/o9LxX0
  5iTjGeplSoP2sSIncDB2dF8BWOauf48mMYoGmEA6tHCPK7p4MxpTbKlqRZqtbhNh
  uVYCL7fMY4hXWjjB15h3ENJufOktPJphQjijfY3H0OcEu7Q2tMxZcerpMJtd5twJ
  4jB0ID5cJfcaHH+Glci/uR+9BPGFX7/8uwA5KI04gfTRbxfJ4L6UqNCxYph4DZUB
  sHM+4k82ohGJ8Uzx3flINHv6L4yX5MXsb7OpKqtVjMFTbe3/9MMwesiB3tABXKYr
  zaKY6ZSkXK0V5RLRNcjPAABxFRtxI/tLzcjfNlcE3BQFhKYAgv0cGeDqdK8vogIf
  VMuC93Uu8OFA7vETEU13rJtF6kjA4MEZFLHO76BuWk2u853J2JKRyc7JGjW1/sS3
  hMqug2bWqrJWgIj/rbhE/6M6BzP/yHAM4pcuvSzBz5h/YyY87N5SBQBIW0uZ+E6y
  Gk3phZxhi9U46gUrSP2qskjAhFGSUjfk2upv/PUZfiW8QCvSkWVruMIdu08XWleL
  XAzTgnuLTLNIckcQQTUJ2ONnDU8XRPttgrizzQspAcSoNUN0L2waOhKNswARAQAB
  tDJMZW9wb2xkIFBhbG9tby1BdmVsbGFuZWRhIDxsZW9wb2xkLnBhbG9tb0B1cGMu
  ZWR1PokCOAQTAQIAIgUCUyXTVwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA
  CgkQBfSnqUmi2aqu/A//dXydW9M6TF9QUkPwLNI5y9KJitbM8Fk0A0sE1J9wRZ28
  ffnBtKBWGBSVKKXA8+7X1UsztoIgE3KfYeqJ2/zRvrugVtRyYbhcvn2yikbH99S3
  ezAc5b0ZfBD8SoT2U5CehTM+5GKLgsEbWlYeZ99Tf948qrhR/dif/tZS1OEYVxek
  hbiMCjTIRoZa2Ux9KQ54nFjYUcYEWDboWn44Hm3N1SLuy7h5CJQ7+mWSujIqZUZe
  9v5mMcpy0VLZaVu016TTMvL7ruCX3qUShgALXUmQfq95Oz772C6l2AzdOgZdsREz
  ycgKW2Zyw3Jub9FQ3wRkuiVdY71lLQbZL+DIhZv/7spEid7qbO/+6L+411tdRoGM
  CPc36rjkf2wlcaGtukIg8qbAH/M7l4ID/wxJzkkIZs42nk/5LzLM8Is4g6avpOJB
  Qe8CdRA0gYqAXzKHCBnOFwOPXg71YTT6zwsZI8GjXfZ6l9CzKVlUW2ONa9QsdA10
  FZWanvuQvHUVs947Sy2VGLWGI68R3s50BE/46DO9uVmSUnuFjQmhY+i1Z9Akx42y
  xEV1mu3j5DdJniVmgIoRizX0VWTLp1DyWxyIcRL6IHANM14Yx6Y/iaY9okr4fewB
  Lj7aszdM6vckphA+oOREl5Ia8DETgPNrXlhVmv8FcOAyUeKVRpODblFWMAHIEiOJ
  AhwEEAECAAYFAlMorjgACgkQp+2DH1mzoOgPiA//YvDSjBw4L4sCP+10yAOpckTD
  f1TFxud+mbOFdWru1/XfSA3w/YO9yHlg3Lcrh1Chbb8/EpX1QZxMFlWfTHcKt+Co
  oSKYN/DicH5GiGBnt/P+kx2R+8fbBm3W2NervTGvQnmkb/9HnT74zS94dOO9OMys
  evq8xCLQ5htFzZVZgp58Cb5yaWp/znZoIlijNG12fqI1bkNf14U9W7wDN5Tk+6Jx
  kpW2In6sI1NXoU1EPaiOsYexLBQRsj2IlOkgbkP81YB+plX5oeMxAYggzaIwL6/f
  O2Gmbwr6yZ5twSBMvYk09WaDSzrvQDw7bY5TWdTHv62T1O6ziHQJG2R56UlBGOkj
  aIVj34JpMYrnQCI7x5LWlGVI+e7cR37HucOG4PvgW/TO1x5fMeqyu47Zz8c8ZeYS
  0BylcndVCBkZJuq1vD09vyeeYTU1ZQmVfnCpfex5wRhjPpUjB3HzXwtM4neYrBf/
  Ejr6TOOStudYiWjoAcdY2X5qaGPKJp2t8f+clN4/L7Np61rD2uCMvE7Fu5culsac
  PSFccL+iNDaXm/zd3h30r7PIcejPqiIzLy2ofJkET0iKXBCRYuFi7uTHIjOlvOfl
  kiVfZiTjlGaH5DBh4Qho9aIqN3zVfnb+HR5/0CLJp0ua0ByMwTETz9f9mc9e90U7
  03186m+2HcLgruQnQCyJAhwEEAEIAAYFAlR7vzIACgkQHnCRsfFKZKI0chAAl/PC
  NHVBZ++plV22Se57TDt574o27rxHNHjh1QhDH+kHb1zejbVPhur6wf7KYG+OWguP
  ptAQrE6yM1Ias0PYlDYNRogjFTCUTNfcUZcYXfhzHa96psngzz5ENcAutsfCiyas
  rPuZX/OR9JATSQPy874JWq/c2idVuppNsS1QkYfaqZocnMbS9FYmOcvy1QKG/WOS
  ffIqokHYFJu18+x+/ZtHZxAdOhVemFeIEfNE9zbJyXh7qVg1AH6HSyxVx57s+eVW
  sakQ3bVTzS3rsVEV+53X6IPBnmX0iviRyF69FZALGujEhtJgFSpL5fQTkmV8W44Q
  AlrXtIB/ux0DyjoXbUBlqj4uadDaA5a/wch6/sayUihjqbnqoFWUXkiD4R3LoNwX
  8JyeKqb9xkqAhxfCxpfQKFs6P7ZPPW+L99TwSoY4rWkjunWnEsfCcNcDY/FZpAfG
  1Moq0qGgyf1QApxqOhyOfJj6aCVqvrHHSIpBys9yhXxL45O372TpfPytwGRcnXup
  voXi4XCkv1BgYUxzK4VokFzGJo0kq9bcVC4HBeUrDp5tsDbR4ZTndWSnigzbFm+v
  ROKBEoF+sc5YjhrShVdFu+lMyPMqkPDR18BYOoh85mW9WaQByQKLfVDJidrgw7+2
  P8IL63h3u/vesrReUiQ1NTjcdiq9AhLzIY1QqTe0LExlb3BvbGQgUGFsb21vLUF2
  ZWxsYW5lZGEgPGxlb0BhbGF4YXJ4YS5uZXQ+iQI7BBMBAgAlAhsDBgsJCAcDAgYV
  CAIJCgsEFgIDAQIeAQIXgAUCUyXTgwIZAQAKCRAF9KepSaLZqtWxD/0RqUquEDQ/
  1gESTkn7gTeVicb7C0a33kZ+Wf0FuxhWoQrRBa2MXiCyrq4ZT8ZSGC6DxvYgMzYF
  eDraBCNqarWtfTlkHesjnNl9NVU+ZYJ0U6a8td4MWcH2DdoKPNAVaDdVlg6RkmTR
  TfgtOvsl5widZUhmxSsmTeebsqVnNuQBZ7h43Z4qLlyAChyCjkkM9r6fk6Etu8wU
  qGJg2QxOjowhI5BiN8MrpD/vrz1pkEEYiuTAysTbtiY+yRp5vH7qQCRqZbhVQ1ot
  j/wCotE7zmKhnIk12EbJcMuvX4QpKWCdoCV1soRZI0ypFRZdGkxcPDBn0LHyIwyw
  24K7ZI2IgW4Y3S38uh6hbp7u2Wn76EyxryVObjNHLfT/yOqwQZyof1qZGIXtWXkb
  BR/xLW1z6Yg28YYcW7TeihrLkdUI1DzxKJ5Ic5HAh8COsDHmM2Sy5b8a4gRvug6T
  TRJyuaaWmRZUEDVU9ndV7jFZTqWs9JbRYjcA4RCNBje/eJkmbNyqJAuUdftBsdhq
  D2J4PvFMvIikGA5mb6jDvdC1ClwbGZxZ7M6SO8wyq+wKZxPejTrH/HR8WL5REHFC
  sS8gxCrBtAQA17C5JiIA6t+ZA/cIsPd8Y1Rdo8QcNnkZIFwui+KqqlR

Bug#779884: unblock: pcl/1.7.2-7

2015-03-05 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pcl.

We have had a sometimes FTBFS bug #779183. The submitter sent a patch 
(trivial) and we applied it. 

Attach the debdiff against the package in testing.

unblock pcl/1.7.2-7

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pcl-1.7.2/debian/changelog pcl-1.7.2/debian/changelog
--- pcl-1.7.2/debian/changelog	2014-12-02 08:29:50.0 +0100
+++ pcl-1.7.2/debian/changelog	2015-02-25 23:12:56.0 +0100
@@ -1,3 +1,10 @@
+pcl (1.7.2-7) unstable; urgency=medium
+
+  * Added patch to solve sometimes FTBFS. Patch proposed by
+James Cowgill (thanks!!!). Closes: #779183
+
+ -- Leopold Palomo-Avellaneda l...@alaxarxa.net  Wed, 25 Feb 2015 23:12:50 +0100
+
 pcl (1.7.2-6) unstable; urgency=medium
 
   [ Jochen Sprickerhof ]
diff -Nru pcl-1.7.2/debian/patches/0005-tools-depends-on-visualization.patch pcl-1.7.2/debian/patches/0005-tools-depends-on-visualization.patch
--- pcl-1.7.2/debian/patches/0005-tools-depends-on-visualization.patch	1970-01-01 01:00:00.0 +0100
+++ pcl-1.7.2/debian/patches/0005-tools-depends-on-visualization.patch	2015-02-25 15:56:15.0 +0100
@@ -0,0 +1,20 @@
+From 421326315ad0f5012a58677d9f1fcb31fa82f6c3 Tue Dec 2 08:30:14 2014
+From: James Cowgill james...@cowgill.org.uk
+Date: Wed, 25 Feb 2015 09:22:52 +
+Subject: Bug#779183: pcl: sometimes FTBFS - fatal error: pcl/visualization/pcl_visualizer.h: No such file or directory
+
+See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779183
+---
+
+diff --git a/tools/CMakeLists.txt b/tools/CMakeLists.txt
+index d5bb290..d533471 100644
+--- a/tools/CMakeLists.txt
 b/tools/CMakeLists.txt
+@@ -1,6 +1,6 @@
+ set (SUBSYS_NAME tools)
+ set (SUBSYS_DESC Useful PCL-based command line tools)
+-set (SUBSYS_DEPS common io filters sample_consensus segmentation search kdtree features surface octree registration recognition geometry keypoints)
++set (SUBSYS_DEPS common io filters sample_consensus segmentation search kdtree features surface octree registration recognition geometry keypoints visualization)
+ set (DEFAULT ON)
+ set (REASON )
+ 
diff -Nru pcl-1.7.2/debian/patches/series pcl-1.7.2/debian/patches/series
--- pcl-1.7.2/debian/patches/series	2014-12-01 16:32:27.0 +0100
+++ pcl-1.7.2/debian/patches/series	2015-02-25 15:56:41.0 +0100
@@ -2,3 +2,4 @@
 0002-Corrected-openni-dev-and-openni2-dev-in-PCLConfig.cm.patch
 0003-Always-build-libpcl_apps.so.patch
 0004-Correct-PCL_ROOT-in-PCLConfig.cmake.patch
+0005-tools-depends-on-visualization.patch


Bug#779183: pcl: sometimes FTBFS - fatal error: pcl/visualization/pcl_visualizer.h: No such file or directory

2015-02-26 Thread Leopold Palomo-Avellaneda
Hi James,

thanks for reporting it and the patch.

I have created a new version of the package. It's here:

http://mentors.debian.net/package/pcl

Now I will ask to the sponsor to upload the new version and ask to ftp-master 
to unblock it.

Best regards,

Leopold


El Dimecres, 25 de febrer de 2015, a les 09:22:52, James Cowgill va escriure:
 Source: pcl
 Version: 1.7.2-6
 Severity: serious
 Tags: patch
 
 Hi,
 
 pcl seems to sometimes FTBFS with this error:
  [ 52%] Building CXX object
  tools/CMakeFiles/pcl_mesh2pcd.dir/mesh2pcd.cpp.o
  cd /tmp/buildd/pcl-1.7.2/build/tools  /usr/bin/c++  
  -DEIGEN_USE_NEW_STDVECTOR
  -DEIGEN_YES_I_KNOW_SPARSE_MODULE_IS_NOT_STABLE_YET -DQT_CORE_LIB
  -DQT_GUI_LIB -DQT_NO_DEBUG -Dqh_QHpointer -g -O2 -fstack-protector-strong
  -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
  -pthread -fopenmp  -Wno-deprecated -isystem /usr/include/eigen3 -isystem
  /usr/include/ni
  -I/tmp/buildd/pcl-1.7.2/recognition/include/pcl/recognition/3rdparty
  -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtGui -isystem
  /usr/include/qt4/QtCore -I/tmp/buildd/pcl-1.7.2/build/include
  -I/tmp/buildd/pcl-1.7.2/common/include -I/tmp/buildd/pcl-1.7.2/io/include
  -I/tmp/buildd/pcl-1.7.2/filters/include
  -I/tmp/buildd/pcl-1.7.2/sample_consensus/include
  -I/tmp/buildd/pcl-1.7.2/segmentation/include
  -I/tmp/buildd/pcl-1.7.2/search/include
  -I/tmp/buildd/pcl-1.7.2/kdtree/include
  -I/tmp/buildd/pcl-1.7.2/features/include
  -I/tmp/buildd/pcl-1.7.2/surface/include
  -I/tmp/buildd/pcl-1.7.2/octree/include
  -I/tmp/buildd/pcl-1.7.2/registration/include
  -I/tmp/buildd/pcl-1.7.2/recognition/include
  -I/tmp/buildd/pcl-1.7.2/geometry/include
  -I/tmp/buildd/pcl-1.7.2/keypoints/include -I/usr/include/vtk-5.8
  -I/tmp/buildd/pcl-1.7.2/tools/include-o
  CMakeFiles/pcl_mesh2pcd.dir/mesh2pcd.cpp.o -c
  /tmp/buildd/pcl-1.7.2/tools/mesh2pcd.cpp
  /tmp/buildd/pcl-1.7.2/tools/mesh2pcd.cpp:38:46: fatal error:
  pcl/visualization/pcl_visualizer.h: No such file or directory 
   #include pcl/visualization/pcl_visualizer.h
   
^
  
  compilation terminated.
 
 Note that -I/.../visualization/include does not appear in the compiler
 command like it does on the successful builds.
 
 The top of the log contains this which seems a bit strange:
  -- The following subsystems will be built:
  --   common
  --   kdtree
  --   octree
  --   search
  --   sample_consensus
  --   filters
  --   features
  --   geometry
  --   registration
  --   io
  --   segmentation
  --   surface
  --   recognition
  --   keypoints
  --   visualization
  --   tracking
  --   apps
  
 building:
 |_ point_cloud_editor
 |_ in_hand_scanner
 |_ modeler
 
 not building:
 |_ cloud_composer: No reason
 |_ optronic_viewer: FZAPI was not found.
  
  --   people
  --   outofcore
  --   examples
  -- The following subsystems will not be built:
  --   tools: Requires visualization.
  --   global_tests: No reason
 
 I had a look at the build system and it seems that tools does not
 declare a dependency on visualization so the order they're built is
 random. I think the order depends on the order of directory entries as
 chosen by the filesystem driver. This could explain why the build worked
 on some buildds.
 
 I haven't managed to build the current version on my amd64 machine at
 all (in various different chroots).
 
 Some logs of failed builds (the arm64 one later built successfully):
 https://buildd.debian.org/status/fetch.php?pkg=pclarch=sparcver=1.7.2-6st
 amp=1417974163
 https://launchpadlibrarian.net/193721902/buildlog_ubuntu-vivid-ppc64el.pcl_
 1.7.2-6_FAILEDTOBUILD.txt.gz
 
 https://buildd.debian.org/status/fetch.php?pkg=pclarch=arm64ver=1.7.2-3st
 amp=1416536853
 
 I've attached a patch which adds the dependency which fixes this issue
 for me.
 
 Thanks,
 James

-- 
--
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?

signature.asc
Description: This is a digitally signed message part.


Bug#775890: assimp: Unresolved symbols in the debian version

2015-01-20 Thread Leopold Palomo-Avellaneda
Package: assimp
Version: 3.0~dfsg-3
Severity: important

Dear Maintainer,

* What exactly did you do (or not do) that was effective (or ineffective)?

The debian version of the package shipped in sid or jessie has some symbols
dropped.

* What was the outcome of this action?

A simple program cannot be linked with the library.

* What outcome did you expect instead?

A linkeable lib.

I have attached a simple file to show the result. It could be compiled
using:

g++ assimp.cpp -o assimp-ex `pkg-config --libs assimp`

if you do it with the debian version, you obtain an error:

/tmp/ccnjCEiB.o: In function `main':
assimp.cpp:(.text+0x1c): undefined reference to `aiMaterial::aiMaterial()'
/tmp/ccnjCEiB.o: In function `aiReturn aiMaterial::AddPropertyfloat(float
/const*, unsigned int, char const*, unsigned int, unsigned int)':
assimp.cpp:(.text._ZN10aiMaterial11AddPropertyIfEE8aiReturnPKT_jPKcjj[_ZN10aiMaterial11AddPropertyIfEE8aiReturnPKT_jPKcjj]+0x4d):
/undefined reference to `aiMaterial::AddBinaryProperty(void const*, unsigned
/int, char const*, unsigned int, unsigned int, aiPropertyTypeInfo)'
/tmp/ccnjCEiB.o: In function `aiReturn
/aiMaterial::AddPropertyaiColor3D(aiColor3D const*, unsigned int, char
/const*, unsigned int, unsigned int)':
assimp.cpp:(.text._ZN10aiMaterial11AddPropertyI9aiColor3DEE8aiReturnPKT_jPKcjj[_ZN10aiMaterial11AddPropertyI9aiColor3DEE8aiReturnPKT_jPKcjj]+0x4d):
/undefined reference to `aiMaterial::AddBinaryProperty(void const*, unsigned
/int, char const*, unsigned int, unsigned int, aiPropertyTypeInfo)'
/tmp/ccnjCEiB.o: In function `aiReturn aiMaterial::AddPropertychar(char
/const*, unsigned int, char const*, unsigned int, unsigned int)':
assimp.cpp:(.text._ZN10aiMaterial11AddPropertyIcEE8aiReturnPKT_jPKcjj[_ZN10aiMaterial11AddPropertyIcEE8aiReturnPKT_jPKcjj]+0x4d):
/undefined reference to `aiMaterial::AddBinaryProperty(void const*, unsigned
/int, char const*, unsigned int, unsigned int, aiPropertyTypeInfo)'
collect2: error: ld returned 1 exit status


However, if you download the upstream version [1], compile it (using the
same cmake options as the debian stuff) and install it in /usr/local, you
can obtain an unuseful linked program.

I guess that the file libassimp3.ver doesn't contain all the needed stuff,
for instante aiMaterial and then it's not exported. But, I'm not sure.

Please, could you look it? to me this package is unusable because I cannot
link my soft against it.


[1]
http://sourceforge.net/projects/assimp/files/assimp-3.0/assimp--3.0.1270-full.zip

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
#include assimp/scene.h

int main(void) {
aiMaterial *aiMat = new aiMaterial;

aiColor3D color;
float value;

//Add name
aiMat-AddProperty(material,1,AI_MATKEY_NAME);

//Add diffuse color
color = aiColor3D(0.1,0.2,0.3);
aiMat-AddProperty(color,1,AI_MATKEY_COLOR_DIFFUSE);

//Add transparency
value = 0.1;
aiMat-AddProperty(value,1,AI_MATKEY_OPACITY);

return 0;
}


Bug#775014: nfs-common: Degraded performance on nfs4 clients after upgrade to Jessie

2015-01-12 Thread Leopold Palomo-Avellaneda
El Diumenge, 11 de gener de 2015, a les 10:17:29, Martin Steigerwald va 
escriure:
 As I am interested in NFS performance issues due to my work I copied my work
 address in.

Me too.

 Am Sonntag, 11. Januar 2015, 01:16:03 schrieben Sie:
  El Dissabte, 10 de gener de 2015, a les 19:30:12, Martin Steigerwald va
  escriure:
  [...]
  
   I suggest you upgrade to 3.16 bpo kernel. Maybe that already makes a
   difference. And additionally there is greater chance you get security
   updates on that one, cause AFAIK older bpo kernels are not maintained
   anymore.
  
  It's in one of the main server of my institute and it's not easy. Anyway,
  I
  have programed it to do it soon. Thanks for the suggestion.
  
  [...]
  
cami:/recursos /home/recursos nfs4
rw,sync,nodev,noatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,soft
,p
ro
t
o=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.8,local_
lo
ck
=n one,addr=192.168.1.254 0 0
   
   What is this on the wheezy machine?
  
  all the servers are wheezy. The clients are Jessie.
  
   Look in grep nfs /proc/mounts or nfsstat -m
   
   I suggest not to manually tune this. Current kernels use good default
   values. I have seen rsize and wsize of up to 1048576.
   
   Additionally are they all the same hardware, same network cards? If not,
   what is the fast system using and what is the slow system using?
  
  well, I have worked on this issue and i have found some conclusions:
  
  - now, with modern kernels (and nfs4) it has no sense to set rsize and
  wsize. The negotiation between client and server do the best one. So, all
  the pages in the net are outdated.
 
 Hehe, my own training slides where outdated as well – for years. We found
 out about it on one of my Linux performance analysis  tuning trainings as
 participants of the training measures NFS performance with dd with and
 without tuning and it was actually better without tuning. cat /proc/mounts
 – /etc/mtab wasn´t a symlink to it back then – revealed the difference.
 Thats where I found that 1048576 value for both rsize and wsize, instead of
 the 8192 or 32768 I recommended to set.
 
  - the sync parameter works totally different (client side) in a 3.2 kernel
  than 3.16 (also 3.12 or 3.8) . I'm talking for a similar hardware
  (Gigabyte
  NIC, similar cpu, etc) but on a 100 Mb network) from ~7MB/s (kernel 3.2 vs
  63,8 kB/s 3.8). In another environment with a Giga network the rates are
  (
  ~145 kB/s vs ~70,3 MB/s)
 
 Interesting. For all I know sync should be quite okay with NFSv3 and
 upwards. With NFSv2 it was very slow.

Now no. With nfs4 and modern kernels, at least works worst.

  - no significant differences in with wsize. At least that I had found. But
  the default autonegotiation works very well.
  
  - I still don't understand why, although I have a good hardware in the
  work, when my clients do:
  
  $ dd if=/dev/zero of=myrandom bs=4096 count=7
  
  obtains about ~70MB/s
  
  and if I execute the same in the server I obtain 167 MB/s. About 2.5 time
  slower
 
 Do you mean a local dd versus a dd on the client on the NFS mount?

yes. I mean that the users have the home shared by nfs. So, if I login in a 
client, and I do:

dd if=/dev/zero of=myrandom bs=4096 count=7

I obtain ~70MB/s

if I do an ssh to the nfs server (hds then are locally) and I do the same then 
I obtain about 167MB/s.

I have a gigabyte network, with a server with four nics with bounding. iperf 
show me transfers about 937 Mbits/sec (client). However, I cannot affirm that 
my network is perfect. ifconfig shows me a lot of dropped packages.


 Also note that dd may not be the best measurement tool depending on your
 workload and that you will have caching effects with dd unless you use
 oflag=direct, which I never tested with NFS mounts, or at least to correct
 the measured time with conv=fsync (I think).

well with this parameter dd fall down to 79,8 kB/s :-( . However, some more 
sophisticated tool, like iozone should be used to make a trusty information.

 
 There are some nice slides from Greg Banks from SGI about NFS performance. I
 can dig out the URL to it when they are still available online next week at
 work. They are from 2008, but were much more up to date than many other
 things I found on the net. Most of it is not only outdated, but plain wrong
 meanwhile.

I feeling is that there's a lot of back magic around this. And all is about 
trial and error method.

  I still consider this issue important, I think that a lot of people that
  upgrade to Jessie with nfs mounts will found some problem. but this is
  just
  MHO.
 
 I wonder tough whether there is a high probability for a fix for wheezy,
 as jessie is shortly before release and its not a bug in itself, but a
 performance issue. And: It may be fixed by just upgrading the kernel to the
 3.16 bpo one.

is someone (like me) has a environtment with a lot of machines, with a some 
network parameters tried 

Bug#775014: nfs-common: Degraded performance on nfs4 clients after upgrade to Jessie

2015-01-10 Thread Leopold Palomo-Avellaneda
El Dissabte, 10 de gener de 2015, a les 19:30:12, Martin Steigerwald va 
escriure:
[...]

 
 I suggest you upgrade to 3.16 bpo kernel. Maybe that already makes a
 difference. And additionally there is greater chance you get security
 updates on that one, cause AFAIK older bpo kernels are not maintained
 anymore.

It's in one of the main server of my institute and it's not easy. Anyway, I 
have programed it to do it soon. Thanks for the suggestion.

[...]

  cami:/recursos /home/recursos nfs4
  rw,sync,nodev,noatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,soft,pro
  t
  o=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.8,local_lock
  =n one,addr=192.168.1.254 0 0
 
 What is this on the wheezy machine?

all the servers are wheezy. The clients are Jessie.

 Look in grep nfs /proc/mounts or nfsstat -m
 
 I suggest not to manually tune this. Current kernels use good default
 values. I have seen rsize and wsize of up to 1048576.

 Additionally are they all the same hardware, same network cards? If not,
 what is the fast system using and what is the slow system using?


well, I have worked on this issue and i have found some conclusions:

- now, with modern kernels (and nfs4) it has no sense to set rsize and wsize. 
The negotiation between client and server do the best one. So, all the pages 
in the net are outdated.

- the sync parameter works totally different (client side) in a 3.2 kernel than 
3.16 (also 3.12 or 3.8) . I'm talking for a similar hardware (Gigabyte NIC, 
similar cpu, etc) but on a 100 Mb network) from ~7MB/s (kernel 3.2 vs 63,8 
kB/s 3.8). In another environment with a Giga network the rates are ( ~145 
kB/s vs ~70,3 MB/s)

- no significant differences in with wsize. At least that I had found. But the 
default autonegotiation works very well.

- I still don't understand why, although I have a good hardware in the work, 
when my clients do:
 
$ dd if=/dev/zero of=myrandom bs=4096 count=7

obtains about ~70MB/s

and if I execute the same in the server I obtain 167 MB/s. About 2.5 time 
slower

I still consider this issue important, I think that a lot of people that 
upgrade to Jessie with nfs mounts will found some problem. but this is just 
MHO.

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?


signature.asc
Description: This is a digitally signed message part.


Bug#775014: nfs-common: Degraded performance on nfs4 clients after upgrade to Jessie

2015-01-09 Thread Leopold Palomo-Avellaneda
Package: nfs-common
Version: 1:1.2.8-9
Severity: important

I have a typical environment with a nfs server and some clients with home
there, or shared resources. In the server I have a Wheezy (in one server
with 3.12-0.bpo.1-amd64 version and in other 3.2.63). My clients basically
are Wheezy but I'm preparing to Jessie and I wanted to test the upgrade.
 
I have realized that in the two cases that I have tested (at home and work)
both, with the same parameters (fstab) that worked normal with Wheezy, now,
they have an horrible performance in write operations. I'm having
differences of several order of magnitude (37,9 KB/s Jessie vs 17,4 MB/s)

For instance:
Wheezy machine:
$ dd if=/dev/zero of=myrandom bs=1024 count=1000
1000+0 registres llegits
1000+0 registres escrits
1024000 octets (1,0 MB) copiats, 0,0590127 s, 17,4 MB/s

Jessie machine
$ dd if=/dev/zero of=myrandom bs=1024 count=1000
1000+0 registres llegits
1000+0 registres escrits
1024000 octets (1,0 MB) copiats, 27,0021 s, 37,9 kB/s

I hope that the kernel developers have changed some default parameter and I
have it wrong. But, with this version of the kernel, my nfs clients cannot
work well.

I'm open to make any test or provide any needed information.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  57366  status
1000241   tcp  33506  status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 5
Pipefs-Directory = /run/rpc_pipefs
Domain = alaxarxa.net
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
[Translation]
Method = nsswitch
-- /etc/fstab --
#nfs4
cami:/recursos   /home/recursosnfs4 
auto,rw,nodev,sync,_netdev,retry=10,rsize=65536,wsize=65536,soft,noatime,intr   
0 0
-- /proc/mounts --
cami:/recursos /home/recursos nfs4 
rw,sync,nodev,noatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.8,local_lock=none,addr=192.168.1.254
 0 0

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nfs-common depends on:
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libc6   2.19-13
ii  libcap2 1:2.24-6
ii  libcomerr2  1.42.12-1
ii  libdevmapper1.02.1  2:1.02.90-2
ii  libevent-2.0-5  2.0.21-stable-1.1
ii  libgssapi-krb5-21.12.1+dfsg-16
ii  libk5crypto31.12.1+dfsg-16
ii  libkeyutils11.5.9-5+b1
ii  libkrb5-3   1.12.1+dfsg-16
ii  libmount1   2.25.2-4
ii  libnfsidmap20.25-5
ii  libtirpc1   0.2.5-1
ii  libwrap07.6.q-25
ii  lsb-base4.1+Debian13+nmu1
ii  rpcbind 0.2.1-6
ii  ucf 3.0030

Versions of packages nfs-common recommends:
ii  python  2.7.8-2

Versions of packages nfs-common suggests:
pn  open-iscsi  none
pn  watchdognone

-- Configuration Files:
/etc/default/nfs-common changed:
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=


-- no debconf information


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



Bug#771084: Unblock: pcl/1.7.2-4/1.7.2-5/1.7.2-6

2014-12-02 Thread Leopold Palomo-Avellaneda
A Dilluns, 1 de desembre de 2014, Niels Thykier va escriure:
 
 Can you have it done by the end of the week?

Nobuhiro,

please, new version without the --parallel

Could you make a new upload?

http://mentors.debian.net/package/pcl

Leo

-- 
--
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?


signature.asc
Description: This is a digitally signed message part.


Bug#771084: Unblock: pcl/1.7.2-4/1.7.2-5

2014-12-01 Thread Leopold Palomo-Avellaneda
Hi all,

pcl 1.7.2-5 is in unstable. The change proposed by release team is made. 
However, we have another issue [1]. In the #debian-buildd channel, suggested 
removing the --parallel dh flag. Basically the buildd ran out of memory. It's 
something aleatory.

Niels, we don't know what to do. Can we make another build?
Do we have to make another package without that option?

I have read [2] but I don't understand what would happen now. Do we have time 
to be in Jessie?

Thanks,

Leopold

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pclarch=i386ver=1.7.2-5stamp=1417380979
https://release.debian.org/jessie/freeze_policy.html


-- 
--
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?


signature.asc
Description: This is a digitally signed message part.


Bug#771084: Unblock: pcl/1.7.2-4/1.7.2-5/1.7.2-6

2014-12-01 Thread Leopold Palomo-Avellaneda
El Dilluns, 1 de desembre de 2014, a les 21:45:28, Niels Thykier va escriure:
 On 2014-12-01 15:19, Leopold Palomo-Avellaneda wrote:
  Hi all,
  
  pcl 1.7.2-5 is in unstable. The change proposed by release team is made.
  However, we have another issue [1]. In the #debian-buildd channel,
  suggested removing the --parallel dh flag. Basically the buildd ran out
  of memory. It's something aleatory.
  
  Niels, we don't know what to do. Can we make another build?
  Do we have to make another package without that option?
  
  I have read [2] but I don't understand what would happen now. Do we have
  time to be in Jessie?
  
  Thanks,
  
  Leopold
  
  [1]
  https://buildd.debian.org/status/fetch.php?pkg=pclarch=i386ver=1.7.2-5s
  tamp=1417380979 https://release.debian.org/jessie/freeze_policy.html
 
 Feel free to make another upload removing the --parallel, if you
 believe it will work.

I hope so, I think that it has sense.

Well, one  the consequences of deleting --parallel is that now it needs about 
4 hours to compile in my system. I don't know in Nobuhiro computer. So, now 
it's compiling and tomorrow I will ask to Nobuhiro to upload it.

 Can you have it done by the end of the week?

Nobuhiro should be the correct person to answer this question.

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?


signature.asc
Description: This is a digitally signed message part.


Bug#771084: Unblock: pcl/1.7.2-4

2014-11-26 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi again :-(

sadly we received another bug in the pcl package (#770503). We though that the 
binary package was Multi-Arch, but one file collision between platforms. 
Upstream has been notified so, till next version will not be solved. So, for 
Jessie, we have to put that binary package as no Multi-Arch.

In the middle, reviewing the packages in the control file, we realized that 
one binary package had a missing Multi-Arch field, so we added it.

Please, could you unblock pcl?

-
ChangeLog

[Leopold Palomo-Avellaneda]
  * Added missing Multi-arch field for libpcl-apps1.7.
  * Removing Multi-Arch of libpcl-dev. Closes: #770503



Best 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?
diff --git a/debian/changelog b/debian/changelog
index af16355..40589d2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pcl (1.7.2-4) unstable; urgency=medium
+
+  [Leopold Palomo-Avellaneda]
+  * Added missing Multi-arch field for libpcl-apps1.7.
+  * Removing Multi-Arch of libpcl-dev. Closes: #770503
+
+ -- Leopold Palomo-Avellaneda l...@alaxarxa.net  Mon, 24 Nov 2014 12:27:06 +0100
+
 pcl (1.7.2-3) unstable; urgency=medium
 
   [ Jochen Sprickerhof ]
diff --git a/debian/control b/debian/control
index a91f60a..eced6f6 100644
--- a/debian/control
+++ b/debian/control
@@ -43,7 +43,6 @@ Depends: libboost-all-dev,
  libpcl1.7 (= ${binary:Version}),
  ${misc:Depends}
 Suggests: libpcl-doc
-Multi-Arch: same
 Description: Point Cloud Library - development files
  The Point Cloud Library (PCL) is a standalone, large scale, open
  project for 2D/3D image and point cloud processing.
@@ -119,6 +118,7 @@ Description: Point Cloud Library - common library
 
 Package: libpcl-apps1.7
 Architecture: any
+Multi-Arch: same 
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends},
 	 ${misc:Depends}


signature.asc
Description: This is a digitally signed message part.


Bug#771084: Unblock: pcl/1.7.2-4

2014-11-26 Thread Leopold Palomo-Avellaneda
A Dijous, 27 de novembre de 2014, Niels Thykier va escriure:
 Control: tags -1 moreinfo
 
 On 2014-11-26 17:27, Leopold Palomo-Avellaneda wrote:
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: unblock
  
  Hi again :-(
  
  sadly we received another bug in the pcl package (#770503). We though that 
the 
  binary package was Multi-Arch, but one file collision between platforms. 
  Upstream has been notified so, till next version will not be solved. So, 
for 
  Jessie, we have to put that binary package as no Multi-Arch.
  
  In the middle, reviewing the packages in the control file, we realized 
that 
  one binary package had a missing Multi-Arch field, so we added it.
  
  Please, could you unblock pcl?
  
  -
  ChangeLog
  
  [Leopold Palomo-Avellaneda]
* Added missing Multi-arch field for libpcl-apps1.7.
* Removing Multi-Arch of libpcl-dev. Closes: #770503
  
  
  
  Best regards,
  
  Leopold
  
 
 Hi Leopold,
 
 At this point, I am not too keen on accepting an addition of a
 multi-arch: same binary.  Could I convince you to undo it for Jessie
 then apply it first thing after the release?
 
Hi Niels,

at this point I accept anything that release team propose me to put pcl in 
Jessie. But, I would like to note some points:

- if we don't put libpcl-apps1.7 Multi-Arch, pcl could not be fully Multi-
Arch. But also I have to say, that not all the pcl suite depends libpcl-apps. 
It could be delayed till Jessie release and after upload it.

- I'm no a DD. I depend of Nobuhiro. If he has no problem, I prepare -5 
version with your proposing changes. But, I can understand that Nobuhiro could 
begin to hate me and pcl.

- to add Multi-Arch to libpcl-apps1.7 is not a big change IMHO. All it's done 
to make it Multi-Arch, however I forget to add this line.

Your propose implies that we have to prepare a new version of the package, 
built, upload to mentors, ask to Nobuhiro to download, built?, and upload to 
ftp-master and fill another Unblock to pcl/1.7.2-5. Think I need more or less 
1 hour of time to build pcl in a dual amd64 quadcore server.

I don't know what more to say...

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?


signature.asc
Description: This is a digitally signed message part.


Bug#770462: Unblock: pcl/1.7.2-3

2014-11-21 Thread Leopold Palomo-Avellaneda
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

We have had to make some changes in the package pcl. We know we have done 
bad things, but we have needed because some bugs:

* Change openni-dev to libopenni, Closes: #768953

we got an important bug making our package (pkg-config information) wrong. 
Simple, we changed the name of the reference to libopenni

* Build without OpenNI when it's not available. It opens
the number of architectures where it could be built. Closes: #769883

as we have openni as built dependency, we found that we _only_ had two arch to 
be built, when the package should be built in all. So, we made a conditional 
of this dependency.

* Fix PCLConfig.cmake (patch taken from Fedora). Closes: #770029

when we were doing this modifications we received a complain of one user about 
the CMake files and we found that we had a bug that fedora had solved before.

That's why the changes. 

Please, could you unblock pcl?

Best regards,

Leopold

-- 
--
Linux User 152692 PGP: 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?


signature.asc
Description: This is a digitally signed message part.


  1   2   >