Bug#1020799: Transition: pkg-config to pkgconf: next steps
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&suite=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
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
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
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
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
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
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
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 gi
Bug#942545: gitlab: Wrong permissions in some update
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 node-
Bug#922900: O: qdacco -- offline Dacco Catalan <-> English dictionary frontend (qt)
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))
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)
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)
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
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
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
reopen 930507
Bug#930646: Reopen the bug
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Hi, activating in rules -DENABLE_OPENCV3=ON \ digikam build witn OpenCV3.1. So, this shouldn't block opencv transition. Leopold -- -- Leopold Palomo-Avellaneda 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
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 &minClass, double &minDist) 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 &minClass, double &minDist
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 &minClass, double &minDist
{
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 &minClass, double &minDist
// 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 &minClass, double &minDist
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 &minClass, double &m
Bug#849068: ITP: ros-opencv-apps -- OpenCV functionalities for Robot OS
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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" > > An: "Debian Bug Tracking System" > > Betreff: Bug#783109: ITP: orocos-kdl -- Orocos Kinematics and Dynamics > > Library > > > > Package: wnpp > > Severity: wishlist > > Owner: "Leopold Palomo-Avellaneda" > > > > * Package name: orocos-kdl > > > > Version : 1.3.0 > > Upstream Author : Orocos Developers > > > > * 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
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: orocos-kdl Version : 1.3.0 Upstream Author : Orocos Developers * 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#783016: ITP: orocos-typelib -- C/C++ type introspection library
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: orocos-typelib Version : 2.8.0 Upstream Author : Orocos Developers * 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#783008: ITP: orocos-utilrb -- Ruby toolkit: collection of useful Ruby classes
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: orocos-utilrb Version : 2.8.0 Upstream Author : Orocos Developers * 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#782745: ITP: orocos-log4cpp -- C++ library for flexible logging
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: orocos-log4cpp Version : 2.8.0 Upstream Author : Orocos Developers * 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
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" > > > > * Package name: orocos-ocl > > > > Version : 2.8.0 > > Upstream Author : Orocos Developers > > > > * 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
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: orocos-ocl Version : 2.8.0 Upstream Author : Orocos Developers * 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
Hi, may I understand that we won't have this driver in Jessie? -- -- Leopold Palomo-Avellaneda 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
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: orocos-rtt Version : 2.8.0 Upstream Author : Orocos Developers * 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
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 as a Debian Maintainer Date: Sun, 15 Mar 2015 17:15:16 +0100 Action: import Recommended-By: Andreas Tille , Nobuhiro Iwamatsu 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+MwRPQGCN YT
Bug#779884: unblock: pcl/1.7.2-7
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 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 +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
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 > > > > ^ > > > > 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=pcl&arch=sparc&ver=1.7.2-6&st > 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=pcl&arch=arm64&ver=1.7.2-3&st > 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
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::AddProperty(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::AddProperty(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::AddProperty(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
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
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 >
Bug#775014: nfs-common: Degraded performance on nfs4 clients after upgrade to Jessie
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
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 pn watchdog -- 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
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/1.7.2-6
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=pcl&arch=i386&ver=1.7.2-5&s > > 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/1.7.2-5
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=pcl&arch=i386&ver=1.7.2-5&stamp=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
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#771084: Unblock: pcl/1.7.2-4
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 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#770462: Unblock: pcl/1.7.2-3
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.
