Bug#882591: gazebo FTBFS: /usr/include/boost/predef/language/stdc.h:52: Parse error at "defined"

[Gianfranco Costamagna]

control: reopen -1
control: notfixed -1 7.8.1+dfsg-3

Hello, the Ubuntu patch seems more complete, and your approach will probably 
FTBFS again if the user uses a new boost
(like Ubuntu does), or a new qt or whatever changes.
The Ubuntu patch is taken from Fedora, and seems to make it compile correctly 
with new toolchains, so I think using it
might be beneficial for the future, what do you think?

The failure message is the reason for reopening this bug

PATCH:
http://launchpadlibrarian.net/349631320/gazebo_7.8.1+dfsg-3build1_7.8.1+dfsg-3ubuntu1.diff.gz

FAILURE:
https://launchpad.net/ubuntu/+source/gazebo/7.8.1+dfsg-3/+build/13780015

/usr/include/boost/predef/language/stdc.h:52: Parse error at "defined"
gazebo/gui/CMakeFiles/gazebo_gui.dir/build.make:75: recipe for target 
'gazebo/gui/moc_ApplyWrenchDialog.cxx' failed


thanks!

Gianfranco



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#875410: librsb: please fix build with wl-asneeded

[Gianfranco Costamagna]

Source: librsb
Version: 1.2.0-rc7-3
Severity: normal
Tags: patch

Hello, the following patch makes the package build when wl-asneeded is the 
default

--- librsb-1.2.0-rc7/debian/rules   2017-08-10 06:20:24.0 +
+++ librsb-1.2.0-rc7/debian/rules   2017-09-11 08:47:54.0 +
@@ -31,7 +31,7 @@
override_dh_auto_test:
make qtests
(cd debian ;\
-gcc -o rsb127_bugfix -I.. -L../.libs -lrsb rsb127_bugfix.c ;   \
+gcc -o rsb127_bugfix -I.. rsb127_bugfix.c -L../.libs -lrsb;\
LD_LIBRARY_PATH=../.libs ./rsb127_bugfix )

override_dh_compress:

thanks for considering it

Gianfranco

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

Bug#865526: closed by Gianfranco Costamagna <locutusofb...@debian.org> (Re: libpetsc3.7.5-dev: uninstallable on current sid)

[Gianfranco Costamagna]

control: close -1


Hello Adrian,
>No disagreement on that, but why did you close the bug?


because it triggers an useless autoremoval from testing, while the testing 
version
is completely fine.
>This is a release critical bug that should stay open until it is fixed 
>in sid.


this is not RC, because transitions and binNMU requests aren't.
RC would be in case Britney lets it migrate to testing, which isn't the case.

I requested a biNMU request a few seconds ago, so we should be fine with this 
one
in a few hours/days.

We can't track RC bugs because of a missing NMU, because otherwise the BTW 
would be full
of uninstallability bugs (useless) and "fixed" packages will be removed from 
testing
too (look e.g. to haskell and ocaml)

I know this isn't a strong point, this is why I asked on #-release channel for 
some
advices, feel free to disagree with me, but please followup on #866582

thanks!

G.

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

Bug#850150: freemat ftbfs with LLVM 3.9

[Gianfranco Costamagna]

control: clone -1 -2
control: block -1 by -2
control: retitle -2 llvm-toolchain-3.9 make some reverse-dependencies FTBFS on 
i386
control: reassign -2 src:llvm-toolchain-3.9
control: found -2 1:3.9.1-1
control: tags -2 patch

On Wed, 4 Jan 2017 16:14:03 +0200 Graham Inggs  wrote:
> Hi
> 
> The attached updated fix-llvm-build.patch fixes the build almost 
> everywhere by adding LLVMCoverage to OPTIONAL_LIBS.
> 
> The build now fails on i386 with the following:
> 
> In file included from 
> /usr/lib/llvm-3.9/include/llvm/Target/TargetOptions.h:20:0,
>   from 
> /usr/lib/llvm-3.9/include/llvm/Target/TargetMachine.h:22,
>   from 
> /usr/lib/llvm-3.9/include/llvm/ExecutionEngine/ExecutionEngine.h:28,
>   from 
> /<>/freemat-4.2+dfsg1/libs/libMatC/CJitFuncClang.hpp:8,
>   from 
> /<>/freemat-4.2+dfsg1/libs/libMatC/JITFactory.cpp:2:
> /usr/lib/llvm-3.9/include/llvm/MC/MCAsmInfo.h:39:6: error: expected 
> identifier before ‘,’ token
> X86, /// Windows x86, uses no CFI, just EH tables
>^
> /usr/lib/llvm-3.9/include/llvm/MC/MCAsmInfo.h: In member function ‘bool 
> llvm::MCAsmInfo::usesWindowsCFI() const’:
> /usr/lib/llvm-3.9/include/llvm/MC/MCAsmInfo.h:555:58: error: expected 
> unqualified-id before ‘)’ token
>   WinEHEncodingType != WinEH::EncodingType::X86);
>^
> 
> Regards
> Graham
> 

as already said, this seems to be a regression in llvm-toolchain-3.9, somewhere 
that X86 is already defined
and clashing with the definition.
s/X86/x86 works, even if I don't know exactly the implications of that code 
(seems to be some windows-only define
FWICS)

the patch is here:
-- llvm-toolchain-3.9-3.9.1.orig/include/llvm/MC/MCAsmInfo.h
+++ llvm-toolchain-3.9-3.9.1/include/llvm/MC/MCAsmInfo.h
@@ -36,7 +36,7 @@ enum class EncodingType {
   ARM, /// Windows NT (Windows on ARM)
   CE,  /// Windows CE ARM, PowerPC, SH3, SH4
   Itanium, /// Windows x64, Windows Itanium (IA-64)
-  X86, /// Windows x86, uses no CFI, just EH tables
+  x86, /// Windows x86, uses no CFI, just EH tables
   MIPS = Alpha,
 };
 }
@@ -552,7 +552,7 @@ public:
   bool usesWindowsCFI() const {
 return ExceptionsType == ExceptionHandling::WinEH &&
(WinEHEncodingType != WinEH::EncodingType::Invalid &&
-WinEHEncodingType != WinEH::EncodingType::X86);
+WinEHEncodingType != WinEH::EncodingType::x86);
   }
 
   bool doesDwarfUseRelocationsAcrossSections() const {
--- llvm-toolchain-3.9-3.9.1.orig/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
+++ llvm-toolchain-3.9-3.9.1/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
@@ -278,7 +278,7 @@ bool AsmPrinter::doInitialization(Module
 default: llvm_unreachable("unsupported unwinding information encoding");
 case WinEH::EncodingType::Invalid:
   break;
-case WinEH::EncodingType::X86:
+case WinEH::EncodingType::x86:
 case WinEH::EncodingType::Itanium:
   ES = new WinException(this);
   break;
--- llvm-toolchain-3.9-3.9.1.orig/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
+++ llvm-toolchain-3.9-3.9.1/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
@@ -136,7 +136,7 @@ X86MCAsmInfoMicrosoft::X86MCAsmInfoMicro
 // 32-bit X86 doesn't use CFI, so this isn't a real encoding type. It's 
just
 // a place holder that the Windows EHStreamer looks for to suppress CFI
 // output. In particular, usesWindowsCFI() returns false.
-WinEHEncodingType = WinEH::EncodingType::X86;
+WinEHEncodingType = WinEH::EncodingType::x86;
   }
 
   ExceptionsType = ExceptionHandling::WinEH;

G.



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#843897: Should allow pyqt5

[Gianfranco Costamagna]

control: tags -1 moreinfo

Hi Yuri, unfortunately seems that your patch is not enough, e.g.
you are not recommending python-qt5* packages


I'm already discussing the qt5 switch with the two people in cc,
lets keep this bug as opportunity to think about the switch and patch.

thanks,

Gianfranco




Il Giovedì 10 Novembre 2016 15:09, Yuri D'Elia  ha scritto:
Package: python-pyqtgraph
Version: 0.9.10-5
Severity: normal

pyqtgraph 0.10 can now also work with pyqt5. I'd suggest adjusting the
dependencies to allow this.

python-pyqtgraph should depend on python-qt4 | python-pyqt5 | python-pyside
python3-pyqtgraph should depend on python3-pyqt4 | python3-pyqt5 | 
python3-pyside

Thanks.

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

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

Versions of packages python-pyqtgraph depends on:
ii  python-numpy  1:1.11.2-1
ii  python-qt44.11.4+dfsg-2
ii  python-scipy  0.18.1-2
pn  python:any

Versions of packages python-pyqtgraph recommends:
ii  python-matplotlib  1.5.3-1
ii  python-opengl  3.1.0+dfsg-1
ii  python-qt4-gl  4.11.4+dfsg-2

Versions of packages python-pyqtgraph suggests:
ii  python-pyqtgraph-doc  0.9.10-5

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

Bug#843243: gazebo: diff for NMU version 7.3.1+dfsg-1.1

[Gianfranco Costamagna]

control: tags -1 pending

On deferred/5

(patch attached)

G.
On Sat, 5 Nov 2016 12:11:51 + (UTC) Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> Package: gazebo
> Version: 7.3.1+dfsg-1
> Severity: serious
> Justification: FTBFS with ongoing boost1.62 transition
> 
> Tags: patch
> 
> Dear maintainer,
> 
> I've prepared an NMU for gazebo (versioned as 7.3.1+dfsg-1.1) and
> not uploaded it :)
> 
> it is a cherry-pick of an upstream build fix (even if I found it after 
> uploading
> the fix in Ubuntu).
> Can you please apply and upload? this is fixing a build failure with the 
> current
> sid package.
> 
> Regards.
> 
> The NMU needs to sed UNRELEASED/unstable and to close this bug :)
> 
> 
> G.
diff -Nru gazebo-7.3.1+dfsg/debian/changelog gazebo-7.3.1+dfsg/debian/changelog
--- gazebo-7.3.1+dfsg/debian/changelog  2016-09-16 00:09:49.0 +0200
+++ gazebo-7.3.1+dfsg/debian/changelog  2016-11-09 21:36:30.0 +0100
@@ -1,3 +1,11 @@
+gazebo (7.3.1+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/fix-boost1.62.patch: cherry-pick upstream commit to fix
+a boost1.62 build failure due to a missing include (Closes: #843243).
+
+ -- Gianfranco Costamagna <locutusofb...@debian.org>  Sat, 05 Nov 2016 
13:06:20 +0100
+
 gazebo (7.3.1+dfsg-1) unstable; urgency=medium
 
   * Imported Upstream version 7.3.1
diff -Nru gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch 
gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch
--- gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch1970-01-01 
01:00:00.0 +0100
+++ gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch2016-11-09 
21:36:30.0 +0100
@@ -0,0 +1,14 @@
+Description: fix a build failure with boost1.62
+Author: Carlos Agüero
+Origin: 
https://bitbucket.org/osrf/gazebo/commits/5a7cfea81159d5287a561bc8be035f89f0dc303d
+
+--- gazebo-7.3.1+dfsg.orig/gazebo/rendering/Camera.cc
 gazebo-7.3.1+dfsg/gazebo/rendering/Camera.cc
+@@ -25,6 +25,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #ifndef _WIN32
diff -Nru gazebo-7.3.1+dfsg/debian/patches/series 
gazebo-7.3.1+dfsg/debian/patches/series
--- gazebo-7.3.1+dfsg/debian/patches/series 2016-09-15 23:57:55.0 
+0200
+++ gazebo-7.3.1+dfsg/debian/patches/series 2016-11-09 21:36:30.0 
+0100
@@ -4,3 +4,4 @@
 0009-fix-gcc6-linking.patch
 0001-fix_tinyxml_constant.patch
 0004-fix-status-double-declaration.patch
+fix-boost1.62.patch


signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#843243: gazebo: diff for NMU version 7.3.1+dfsg-1.1

[Gianfranco Costamagna]

Package: gazebo
Version: 7.3.1+dfsg-1
Severity: serious
Justification: FTBFS with ongoing boost1.62 transition

Tags: patch

Dear maintainer,

I've prepared an NMU for gazebo (versioned as 7.3.1+dfsg-1.1) and
not uploaded it :)

it is a cherry-pick of an upstream build fix (even if I found it after uploading
the fix in Ubuntu).
Can you please apply and upload? this is fixing a build failure with the current
sid package.

Regards.

The NMU needs to sed UNRELEASED/unstable and to close this bug :)


G.
diff -Nru gazebo-7.3.1+dfsg/debian/changelog gazebo-7.3.1+dfsg/debian/changelog
--- gazebo-7.3.1+dfsg/debian/changelog	2016-09-16 00:09:49.0 +0200
+++ gazebo-7.3.1+dfsg/debian/changelog	2016-11-05 13:06:54.0 +0100
@@ -1,3 +1,11 @@
+gazebo (7.3.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/fix-boost1.62.patch: cherry-pick upstream commit to fix
+a boost1.62 build failure due to a missing include (Closes: #-1).
+
+ -- Gianfranco Costamagna <locutusofb...@debian.org>  Sat, 05 Nov 2016 13:06:20 +0100
+
 gazebo (7.3.1+dfsg-1) unstable; urgency=medium
 
   * Imported Upstream version 7.3.1
diff -Nru gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch
--- gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch	1970-01-01 01:00:00.0 +0100
+++ gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch	2016-11-05 13:05:43.0 +0100
@@ -0,0 +1,14 @@
+Description: fix a build failure with boost1.62
+Author: Carlos Agüero
+Origin: https://bitbucket.org/osrf/gazebo/commits/5a7cfea81159d5287a561bc8be035f89f0dc303d
+
+--- gazebo-7.3.1+dfsg.orig/gazebo/rendering/Camera.cc
 gazebo-7.3.1+dfsg/gazebo/rendering/Camera.cc
+@@ -25,6 +25,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #ifndef _WIN32
diff -Nru gazebo-7.3.1+dfsg/debian/patches/series gazebo-7.3.1+dfsg/debian/patches/series
--- gazebo-7.3.1+dfsg/debian/patches/series	2016-09-15 23:57:55.0 +0200
+++ gazebo-7.3.1+dfsg/debian/patches/series	2016-11-05 11:31:08.0 +0100
@@ -4,3 +4,4 @@
 0009-fix-gcc6-linking.patch
 0001-fix_tinyxml_constant.patch
 0004-fix-status-double-declaration.patch
+fix-boost1.62.patch
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#841285: freemat: FTBFS (cannot find -lclangTidyReadabilityModule)

[Gianfranco Costamagna]

Hi Santiago

>Ok, I could agree that freemat is probably not to be blamed for this.



as an llvm team member, I can say that we are already working on removing 3.6 
from testing.
Yesterday 3.8 migrated, and today we already opened 4 bugs against 
ftp.debian.org to make llvm-defaults migrate too.

let me quote #devel discussion here (with no nicks)


[15:11:36] seems that llvm-defaults needs some care to migrate...
[15:13:04] i.e. the armel binaries removed?
[15:13:24] including rdeps
[15:25:45] I think they are still here :/ sorry about that
[15:28:22] (I just filed a RM for the obsolete lldb binaries, not related to 
testing migration, but just for cleaning up the view)
[15:56:11] llvm 3.8 migrated, so if you can do that part with mapreri, we can 
remove 3.6 from testing too
[15:56:24] see e.g. #841303
[15:56:27] -zwiebelbot/22#debian-devel- Debian#841303: RM: aspectc++ qtcreator 
libclang-perl [armel] -- RoQA; FTBFS - https://bugs.debian.org/841303
[15:58:09] maybe we can ask  to kick llvm-3.6 out of testing?
[15:59:34] britney is trying to remove it already, but it can't happen until 
llvm-toolchain-3.9 gets fixed
[15:59:59] oh... ok
[16:00:12] (if you can look at llvm 3.9/arm64, that'd be good)
[16:02:27] yeah, -defaults won't migrate until it gets removed from armel
[16:02:37] can youfile an RM bug for that?
[16:03:09] also, a bug for python-lldb-3.9 decruft on powerpc/ppc64el/s390x
[16:03:53] ppc64el?
[16:04:01] I filed one for ppc/s390x some minutes ago
[16:04:08] ah, nvm
[16:05:39] sent (decruft of python-lldb-3.9)
[16:07:07] still need one for llvm-defaults/armel
[16:08:11] checking dak rm output
[16:08:19] # Broken Depends:
[16:08:19] emscripten: emscripten
[16:08:27] could be worse
[16:08:47] a package with 5 RC bugs, probably nobody cares anyway :>
[16:08:52] 4*
[16:09:06] it was ok to remove it from armel
[16:09:24] I guess, RM it before, then
[16:09:33] yes
[16:09:45] file both, make the llvm-defaults block on the emscripten bug
[16:09:48] see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839033#15
[16:09:48] yes yes
[16:09:51] -zwiebelbot/22#debian-devel- Debian#839033: RM: 
llvm-toolchain-snapshot [armel mips64el] -- RoQA; FTBFS, outdated snapshot - 
https://bugs.debian.org/839033
[16:19:04] #841298 #841305 #841306 #841308 — these should take care of 
everything from what I see.
[16:19:50] I hope ftpmasters will process the last one correctly and not cause 
sourceless binaries by forgetting -B (ISTR removals.html generator doesn't add 
it, or something)

G.

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

Bug#833667: freemat: FTBFS with LLVM 3.8

[Gianfranco Costamagna]

control: tags -1 patch pending

Hi, based on Graham little testing (sorry but I can't provide testing, I'll 
trust
his wordings), I uploaded on deferred/1 and git committed the patch on repo.

cheers

G.

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

Bug#828928: both RC are fixed in experimental

[Gianfranco Costamagna]

Hi,


>AFAIR, that code is nor part of opencv anymore in the new release,
>so I don't know how to extract a patch and make it work on the old version.



fedora might have a patch, feel free to NMU if it works :)

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

Bug#828928: both RC are fixed in experimental

[Gianfranco Costamagna]

Hi,

>Any chance you can fix the FTBFS for unstable?

>It's currently biting me on powerpcspe [1].


AFAIR, that code is nor part of opencv anymore in the new release,
so I don't know how to extract a patch and make it work on the old version.

I suspect a transition might be our best way to bring the fixed package back 
into
a buildable state, unfortunately I'm no the maintainer, nor I know his schedule.

sorry,

G.

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

Bug#836384: closed by Jose Luis Rivero <jriv...@osrfoundation.org> (Bug#836384: fixed in ignition-transport 1.3.0-4)

[Gianfranco Costamagna]

control: reopen -1

Hi, not sure, but it seems still not good!

autopkgtest [17:41:45]: test build: [---
In file included from 
/usr/include/ignition/transport1/ignition/transport/NodeShared.hh:40:0,
from /usr/include/ignition/transport1/ignition/transport/Node.hh:41,
from /usr/include/ignition/transport1/ignition/transport.hh:9,
from igntest.c:1:
/usr/include/ignition/transport1/ignition/transport/RepHandler.hh:38:41: fatal 
error: google/protobuf/stubs/casts.h: No such file or directory
#include 
^
compilation terminated.
autopkgtest [17:41:45]: test build: ---]
autopkgtest [17:41:45]: test build:  - - - - - - - - - - results - - - - - - - 
- - -
buildFAIL non-zero exit status 1
autopkgtest [17:41:46]: test build:  - - - - - - - - - - stderr - - - - - - - - 
- -
In file included from 
/usr/include/ignition/transport1/ignition/transport/NodeShared.hh:40:0,
from /usr/include/ignition/transport1/ignition/transport/Node.hh:41,
from /usr/include/ignition/transport1/ignition/transport.hh:9,
from igntest.c:1:
/usr/include/ignition/transport1/ignition/transport/RepHandler.hh:38:41: fatal 
error: google/protobuf/stubs/casts.h: No such file or directory
#include 
^
compilation terminated.
autopkgtest [17:41:46]:  summary
buildFAIL non-zero exit status 1
Exit request sent.

cheers,

G.





Il Sabato 10 Settembre 2016 18:27, Debian Bug Tracking System 
 ha scritto:
This is an automatic notification regarding your Bug report
which was filed against the src:ignition-transport package:

#836384: ignition-transport: breaks with new protobuf3, and link failures

It has been closed by Jose Luis Rivero .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Jose Luis Rivero 
 by
replying to this email.


-- 
836384: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836384
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problemsSource: ignition-transport
Source-Version: 1.3.0-4

We believe that the bug you reported is fixed in the latest version of
ignition-transport, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 836...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jose Luis Rivero  (supplier of updated 
ignition-transport package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 10 Sep 2016 14:43:28 +
Source: ignition-transport
Binary: libignition-transport1 libignition-transport-dev
Architecture: source
Version: 1.3.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Jose Luis Rivero 
Description:
libignition-transport-dev - Ignition Robotics transport Library - Development 
files
libignition-transport1 - Ignition Robotics Transport Library - Shared library
Closes: 836384
Changes:
ignition-transport (1.3.0-4) unstable; urgency=medium
.
   * Fix pkgconfig file. Ignition transport 1.x series does not use 
ignition-msgs
(Closes: #836384)
Checksums-Sha1:
c5b1bbee46f4712bb7762ed2944792a986637195 2026 ignition-transport_1.3.0-4.dsc
35cca0f6f08c21714d62c49ad9089b77997a5e17 5892 
ignition-transport_1.3.0-4.debian.tar.xz
Checksums-Sha256:
a1170e369a9558a091aced237535547b43cd6950efa96b2fe62542c92b8c044e 2026 
ignition-transport_1.3.0-4.dsc
10ffa9824a8efe1c2b43077457ff416c49353197779b2bad9b9b406209c11e5b 5892 
ignition-transport_1.3.0-4.debian.tar.xz
Files:
6042d9b2df1dc4f480786ee2e29d4a1f 2026 science extra 
ignition-transport_1.3.0-4.dsc
5f3c25cd509b30bd5585c2a014f5dfde 5892 science extra 
ignition-transport_1.3.0-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJX1Bx0AAoJEF6UbAkK/wQn3aYIAIUz+qLyhNLdHgCXBbfKc7QQ
4zwypZ1Rz3lapwwm6nPqrH73ixhKB8gsS+UoffedRoHOr8c27L7ESMYf/Hi5o9H6
a7rtVL0xEFDsJcSEJn59SRr4U64efPwmgxZcaaFWTp4fHadD5qRYOBMETwNI9LSs
l47Ot2bw1LPp5nzMul9vq8RGB5W50PpQwmYtW4qyIoNO1rOWwQj6S/z/kaIcKLkN
i/818tMH+bmDK+qKs7fmhT5kyKxpYKcIZffxtIhKz4f6ZGhPtlpmNYe6axuLEa/1
j0LgKuTqc9o89VntIbHEOnlTJUjGifWZyV4lfD0flvnLPODTYb0xTcK4J8hpuHo=
=AdFY
-END PGP SIGNATURE-
Source: ignition-transport
Version: 1.3.0-2
Severity: serious

Hi, the latest protobuf3 broke ignition-transport testsuite and package, lets 
analyze the issues:
(based on the 

Bug#836384: closed by Jose Luis Rivero <jriv...@osrfoundation.org> (Bug#836384: fixed in ignition-transport 1.3.0-3)

[Gianfranco Costamagna]

control: reopen -1

Hi, can you please also make sure the testsuite works?

there is still the header file wrong include, I suspect nothing using this 
software can build in this way

autopkgtest [16:52:26]: test build: [---
Package ignition-msgs0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `ignition-msgs0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'ignition-msgs0', required by 'ignition-transport1', not found
igntest.c:1:33: fatal error: ignition/transport.hh: No such file or directory
#include 
^
compilation terminated.
autopkgtest [16:52:27]: test build: ---]
autopkgtest [16:52:27]: test build:  - - - - - - - - - - results - - - - - - - 
- - -
buildFAIL non-zero exit status 1
autopkgtest [16:52:27]: test build:  - - - - - - - - - - stderr - - - - - - - - 
- -
Package ignition-msgs0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `ignition-msgs0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'ignition-msgs0', required by 'ignition-transport1', not found
igntest.c:1:33: fatal error: ignition/transport.hh: No such file or directory
#include 
^
compilation terminated.
autopkgtest [16:52:27]:  summary
buildFAIL non-zero exit status 1
Exit request sent.

This bad header is installed with ignition-transport

thanks,

G.




Il Giovedì 8 Settembre 2016 3:21, Debian Bug Tracking System 
 ha scritto:
This is an automatic notification regarding your Bug report
which was filed against the src:ignition-transport package:

#836384: ignition-transport: breaks with new protobuf3, and link failures

It has been closed by Jose Luis Rivero .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Jose Luis Rivero 
 by
replying to this email.


-- 
836384: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836384
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problemsSource: ignition-transport
Source-Version: 1.3.0-3

We believe that the bug you reported is fixed in the latest version of
ignition-transport, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 836...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jose Luis Rivero  (supplier of updated 
ignition-transport package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 06 Sep 2016 21:22:27 +
Source: ignition-transport
Binary: libignition-transport1 libignition-transport-dev
Architecture: source
Version: 1.3.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Jose Luis Rivero 
Description:
libignition-transport-dev - Ignition Robotics transport Library - Development 
files
libignition-transport1 - Ignition Robotics Transport Library - Shared library
Closes: 836384
Changes:
ignition-transport (1.3.0-3) unstable; urgency=medium
.
   * Added patch for pkgconfig file
(Closes: #836384)
Checksums-Sha1:
ad51c8c4fc5fc314d58235cd970dcd9ba6b3e312 2026 ignition-transport_1.3.0-3.dsc
e6aa6bf38cffde7ecd9a13ee0b115cb0131a7c0a 5856 
ignition-transport_1.3.0-3.debian.tar.xz
Checksums-Sha256:
c26a5af1431dde2267eee8439126e88186fd5611727119e3f31aae1557409d1d 2026 
ignition-transport_1.3.0-3.dsc
f04675d9322581875d1643d40b010ab8821825ceb76718dde8f93831437e2fed 5856 
ignition-transport_1.3.0-3.debian.tar.xz
Files:
c82545c34494bf902c881fe5fdc5cccf 2026 science extra 
ignition-transport_1.3.0-3.dsc
41614dc7aee170587c927d4fa6e9 5856 science extra 
ignition-transport_1.3.0-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJX0LdpAAoJEF6UbAkK/wQnJEEIAJ/JPQitgAjVvmV121ei86JJ
ZMBoafAM1FTnKaXOhyc/Jqe7OnhIalvqTnsaNpLOAJ94nn/aHWQuPRS9Do5pcTwG
d+ftbw6zR7uQxB3gE3c2PUhjaUjN3LEPFhs8ZrdNrtVXSIhm9PGVzlI/RJ3zVeWA
Mo27xkuK5awm6HBtoMvy/yDeL545cqKZnkGrFmH4ZvaOmw/dqU1IE+QGhneEVGj4
L07nSEaJh6ntdAO8kcLiJRBRcOfz85PZYMKjHYEF9xSuZOllQpB5QDnft37l+wj+
uHTGVCJqtkrCIvveDTN8Yfk9kqyg8hP5tGpea09P2gseN7K2HenFL18wnB/1Hh4=
=R2T8
-END PGP SIGNATURE-
Source: ignition-transport
Version: 1.3.0-2
Severity: serious

Hi, the latest protobuf3 broke ignition-transport testsuite and package, lets 
analyze the issues:
(based on 

Bug#836384: ignition-transport: breaks with new protobuf3, and link failures

[Gianfranco Costamagna]

Source: ignition-transport
Version: 1.3.0-2
Severity: serious

Hi, the latest protobuf3 broke ignition-transport testsuite and package, lets 
analyze the issues:
(based on the main on debian/tests
#include 

int main()
{
// Create a transport node.
ignition::transport::Uuid uuid;
return 0;
}



first issue:
./build 
In file included from 
/usr/include/ignition/transport1/ignition/transport/NodeShared.hh:40:0,
from /usr/include/ignition/transport1/ignition/transport/Node.hh:41,
from /usr/include/ignition/transport1/ignition/transport.hh:9,
from igntest.c:1:
/usr/include/ignition/transport1/ignition/transport/RepHandler.hh:38:41: fatal 
error: google/protobuf/stubs/casts.h: No such file or directory
#include 
^


this file has been deleted in new protobuf I guess
(removing that line from the hh file works a little better)

that said, the second issue is:
pkg-config --cflags --libs ignition-transport1
-std=c++11 -I/usr/include/ignition/transport1 -lignition-transport1 -l1


that -l1 breaks the build, lets see:
./build 
/usr/bin/ld: cannot find -l1



g++ -o igntest igntest.c `pkg-config --cflags --libs ignition-transport1`
/usr/bin/ld: cannot find -l1
collect2: error: ld returned 1 exit status



removing it works:
g++ -o igntest igntest.c -std=c++11 -I/usr/include/ignition/transport1 
-lignition-transport1
./igntest
echo $?


As usual, please let me know if you have a fix or you need further details

thanks,
G.

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

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

[Gianfranco Costamagna]

Hi,

>Thanks for the assumption and the offer, I have rights now to upload

>changes to kido.


thanks for fixing, next time I'll commit on git indeed, and we will save
some time.
Fortunately patches were trivial, so we didn't loose much time :)

cheers!

Gianfranco

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

Re: kido_0.1.0+dfsg-2_source.changes REJECTED

[Gianfranco Costamagna]

Hi,


> >> ACL dm: not allowed to upload source package 'kido'



a good DM knows how to push the tags on git and avoid double effort
from other people, bu answering to RC bugs :)

again, if you need a sponsor I'm here.

(NMU deleted)

G.

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

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

[Gianfranco Costamagna]

Hi Jose, are you aware of your RC bugs?

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

also, the xml patch looks almost the same as the upstream cherry-pick, and the 
link patch looks mostly the same as my patch.

https://github.com/dartsim/dart/commit/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch

Can you please consider setting the correct authorship and forward patches 
upstream?
(I don't care about authorship, but cherry-picking from upstream, changing it 
is considered bad).

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

G.



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: fplll_5.0.1-1_amd64.changes ACCEPTED into experimental, experimental

[Gianfranco Costamagna]

Hi Julien,


>fplll (5.0.1-1) experimental; urgency=medium


the package seems to have FTBFS on some release architectures,
and probably will fail more once every arch has been picked up by
a buildd.
Please take care of the failures before asking a transition slot.
(even if you are not planning to ask for it, the package will migrate
once all the architectures have been built)

thanks,

G.

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

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

[Gianfranco Costamagna]

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.

Attaching the debdiff uploaded in deferred/2



G.


debdiff
Description: Binary data
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#833817: kido: FTBFS on non-x86 architectures due to hard-wired compiler flags

[Gianfranco Costamagna]

control: tags -1 patch

attached a patch, unfortunately I can't upload because it seems the latest 
flann.
(I'm opening a bug)

G.
diff -Nru kido-0.1.0+dfsg/debian/changelog kido-0.1.0+dfsg/debian/changelog
--- kido-0.1.0+dfsg/debian/changelog2016-07-21 16:33:19.0 +0200
+++ kido-0.1.0+dfsg/debian/changelog2016-08-29 13:25:42.0 +0200
@@ -1,3 +1,16 @@
+kido (0.1.0+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix-msse2-flag: 
+- remove msse3 hard-coded flag (Closes: #833817)
+  * debian/patches/update-new-fcl.patch:
+- fix boost issue with new fcl.
+  * debian/patches/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch:
+- cherry-pick part of upstream fix for new fcl and tinyxml2.
+  (Closes: #835734)
+
+ -- Gianfranco Costamagna <locutusofb...@debian.org>  Mon, 29 Aug 2016 
12:22:34 +0200
+
 kido (0.1.0+dfsg-1) unstable; urgency=medium
 
   * Initial release. (Closes: #812126)
diff -Nru 
kido-0.1.0+dfsg/debian/patches/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch 
kido-0.1.0+dfsg/debian/patches/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch
--- 
kido-0.1.0+dfsg/debian/patches/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch   
1970-01-01 01:00:00.0 +0100
+++ 
kido-0.1.0+dfsg/debian/patches/2841967fc6628c9aea58c93227b28abdf5dfbcc2.patch   
2016-08-29 12:50:17.0 +0200
@@ -0,0 +1,66 @@
+From 2841967fc6628c9aea58c93227b28abdf5dfbcc2 Mon Sep 17 00:00:00 2001
+From: Jeongseok Lee <jsle...@users.noreply.github.com>
+Date: Thu, 21 Jul 2016 17:34:40 -0400
+Subject: [PATCH] Update API to support fcl 0.5 and tinyxml 4.0 -- for DART 6.1
+ (#750)
+
+* Update API to support fcl 0.5.0
+
+* Update changelog
+
+* Use type aliasing rather than boilerplate preprocessors
+
+* Switch to use XML_SUCCESS rather than XML_NO_ERROR
+---
+ kido/utils/XmlHelpers.cpp   | 10 +-
+ 7 files changed, 24 insertions(+), 17 deletions(-)
+
+Index: kido-0.1.0+dfsg/kido/utils/XmlHelpers.cpp
+===
+--- kido-0.1.0+dfsg.orig/kido/utils/XmlHelpers.cpp
 kido-0.1.0+dfsg/kido/utils/XmlHelpers.cpp
+@@ -731,7 +731,7 @@
+   const int result = element->QueryBoolAttribute(attributeName.c_str(),
+  );
+ 
+-  if (result != tinyxml2::XML_NO_ERROR)
++  if (result != tinyxml2::XML_SUCCESS)
+   {
+ dtwarn << "[getAttribute] Error in parsing bool type attribute ["
+<< attributeName << "] of an element [" << element->Name()
+@@ -749,7 +749,7 @@
+   int val = 0;
+   const int result = element->QueryIntAttribute(attributeName.c_str(), );
+ 
+-  if (result != tinyxml2::XML_NO_ERROR)
++  if (result != tinyxml2::XML_SUCCESS)
+   {
+ dtwarn << "[getAttribute] Error in parsing int type attribute ["
+<< attributeName << "] of an element [" << element->Name()
+@@ -768,7 +768,7 @@
+   const int result = element->QueryUnsignedAttribute(attributeName.c_str(),
+  );
+ 
+-  if (result != tinyxml2::XML_NO_ERROR)
++  if (result != tinyxml2::XML_SUCCESS)
+   {
+ dtwarn << "[getAttribute] Error in parsing unsiged int type attribute ["
+<< attributeName << "] of an element [" << element->Name()
+@@ -787,7 +787,7 @@
+   const int result = element->QueryFloatAttribute(attributeName.c_str(),
+   );
+ 
+-  if (result != tinyxml2::XML_NO_ERROR)
++  if (result != tinyxml2::XML_SUCCESS)
+   {
+ dtwarn << "[getAttribute] Error in parsing float type attribute ["
+<< attributeName << "] of an element [" << element->Name()
+@@ -806,7 +806,7 @@
+   const int result = element->QueryDoubleAttribute(attributeName.c_str(),
+);
+ 
+-  if (result != tinyxml2::XML_NO_ERROR)
++  if (result != tinyxml2::XML_SUCCESS)
+   {
+ dtwarn << "[getAttribute] Error in parsing double type attribute ["
+<< attributeName << "] of an element [" << element->Name()
diff -Nru kido-0.1.0+dfsg/debian/patches/fix-msse2-flag.patch 
kido-0.1.0+dfsg/debian/patches/fix-msse2-flag.patch
--- kido-0.1.0+dfsg/debian/patches/fix-msse2-flag.patch 1970-01-01 
01:00:00.0 +0100
+++ kido-0.1.0+dfsg/debian/patches/fix-msse2-flag.patch 2016-08-29 
13:25:17.0 +0200
@@ -0,0 +1,37 @@
+Description: Remove msse2 flag
+Author: Gianfranco Costamagna <locutusofb...@debian.org>
+Bug-Debian: https://bugs.debian.org/833817
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fiel

Bug#828928: both RC are fixed in experimental

[Gianfranco Costamagna]

fixed -1 3.0.0+dfsg-1~exp3
Version: 3.0.0+dfsg-1~exp3

G.



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: ntl_9.9.0-1_amd64.changes REJECTED

[Gianfranco Costamagna]

Hi Thorsten,


>unfortunately I have to reject your package. 
>Please mention the license of
>  ntl-9.9.0/src/GetTime0.c
>in your debian/copyright.


FYI, we fixed this, and the package is again in new queue
(in case you have already reviewed it, this might save some time
to review from another ftpmaster I hope)

thanks for your work!

Gianfranco

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

Bug#826307: (no subject)

[Gianfranco Costamagna]

Version: 3.4.0+repack1-1

I'm closing, this seems fixed in the new upload.

g.



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: ITA for an abandoned package: evolver case

[Gianfranco Costamagna]

Hi,

>Right now the package rocks.
>But the upstream version is (very) old, and the Debian package material
>clearly needs some refreshment. Is a patch really appropriate here ?
>May I rather wait for  clear orphaning instead ?


I see (2.30 VS 2.70)...
what about:
gbp import-dscs --debsnap git-import-dsc --pristine-tar evolver
(or similar)
create a repo on github or debian-science, do all the stuff you want there, 
open a bug for the new
release,
open a bug with "packaging refactoring" pointing to the git repo, so everybody 
can see/contribute
on the new shiny repo, and eventually sign if the package is orphaned.

In case the package isn't orphaned you will be able to git format-patch the 
various commits and propose
patches to the maintainer.

(and you probably loose less time in doing that)

G.

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

Re: ITA for an abandoned package: evolver case

[Gianfranco Costamagna]

Hi,

>May I fill an ITA or something to signify that someone to working

>the [surface] evolver package ?

A bug with patches should be enough, ITA means somebody orphaning the package
and only the maintainer/MIA team can do it.

But a bug with patches and you proposing the maintainership is something
that might be appreciated by the community

G.

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

Re: ITA for an abandoned package: evolver case

[Gianfranco Costamagna]

Hi,



>i am maintaining many packages, which were maintained by Adam
>originally. But all of them are team-maintained (Debian Science), and this
>one is not.
>
>AFAIK Adam is not active in Debian last several years. From my point of
>view, it will not be too offensive, if evolver will be moved under the roof
>of Debian Science and you can be added as an uploader of this package.
>But we need a confirmation from Adam or MIA-team, I think.


last activity is around 2012 according to db.d.o
>Another option for the time being is that you are preparing a new upload,
>file a bug against evolver ("new version...") and the package will be NMUed
>after some time.


I second this option, together with the move on debian-science of the package.

in the meanwhile, according to quantz, the MIA process started some time ago 
(on 2016-05-24), so I guess
you can start proposing patches and open bugs, and then somebody will sponsor
the work (after some reasonable time), together with a move to science team.


thanks!

Gianfranco


2016-06-07 23:42 GMT+02:00 Jerome BENOIT :
> Hello All,
>
> since a while I [0] have wanted to update the [surface] evolver package [1,2]
> because I used it a few years ego [and because I may use it a gain sooner or 
> later]:
> I try to contact several times the current maintainer in view to get
> the package officially orphaned before any ITA submission.
> So far, I got no feed back. The package is clearly abandoned.
> Is there any Debian authority that have the permission to orphan it ?
> If not, what can be done ?
>
> Thanks,
> Jerome
>
> [0] https://qa.debian.org/developer.php?login=calculus%40rezozer.net=1
> [1] https://packages.qa.debian.org/e/evolver.html
> [2] http://facstaff.susqu.edu/brakke/evolver/evolver.html
>
> --
> debian-science-maintainers mailing list
> debian-science-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

Bug#825923: python-nltk: nltk/tokenize/api.py imports ntlk.six which has been dropped

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

Hi, fixed, committed signed and uploaded
https://anonscm.debian.org/cgit/debian-science/packages/nltk.git/commit/?id=a8a1e52aaabe158edd6074dc353e95b6d1e7bbccthanks
 a lot for the report!



G.


Il Martedì 31 Maggio 2016 14:39, Raphaël Hertzog  ha 
scritto:
Package: python-nltk
Version: 3.2.1-1
Severity: grave
Justification: renders package unusable
User: de...@kali.org
Usertags: origin-kali

I just got a report on Kali that w3af no longer works:
https://bugs.kali.org/view.php?id=3323

The stacktrace ends with this:
  File "/usr/lib/python2.7/dist-packages/nltk/tokenize/api.py", line 14, in

from nltk.six import add_metaclass
ImportError: No module named six

The Debian patch use-six-package.diff is thus incomplete and should be updated
to also correct the import in nltk/tokenize/api.py.

Thank you for a quick fix (with urgency=high please so that it gets fixed in
testing quickly, thank you).

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

Bug#801820: vmtk: switch to vtk6

[Gianfranco Costamagna]

This is the tarball I just uploaded.

g.

On Thu, 15 Oct 2015 00:11:33 +0200 Andreas Beckmann  wrote:
> Source: vmtk
> Version: 1.0.1-3
> Severity: serious
> Tags: sid stretch
> Control: block 798164 with -1
> 
> As written in #798164, stretch will not ship with vtk5, so please switch
> to vtk6.
> 
> 
> Andreas
> 
> 


vmtk_1.3-1.debian.tar.xz
Description: application/xz


signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#820113: vtk6: diff for NMU version 6.2.0+dfsg1-11.1

[Gianfranco Costamagna]

Hi,

with my debian science hat on (and vtk uploader for some time)

dcut ftp-master reschedule -d 0 -f vtk6_6.2.0+dfsg1-11.1_source.changes

this is actually blocking 3-4 packages in the libpng16 transition.

cheers,

G.



On Sun, 10 Apr 2016 20:11:26 +0200 Tobias Frost  wrote:
> Control: tags 820113 + patch
> Control: tags 820113 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for vtk6 (versioned as 6.2.0+dfsg1-11.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> diff -Nru vtk6-6.2.0+dfsg1/debian/changelog vtk6-6.2.0+dfsg1/debian/changelog
> --- vtk6-6.2.0+dfsg1/debian/changelog 2016-04-04 12:41:28.0 +0200
> +++ vtk6-6.2.0+dfsg1/debian/changelog 2016-04-10 20:10:50.0 +0200
> @@ -1,3 +1,10 @@
> +vtk6 (6.2.0+dfsg1-11.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Make libvtk6-dev depend on libhdf5-mpi-dev. (Closes: #820113)
> +
> + -- Tobias Frost   Sun, 10 Apr 2016 20:10:50 +0200
> +
>  vtk6 (6.2.0+dfsg1-11) unstable; urgency=medium
>  
>* [efaf1ec] remove dependencies on libxdmf-dev because it is not be used
> diff -Nru vtk6-6.2.0+dfsg1/debian/control vtk6-6.2.0+dfsg1/debian/control
> --- vtk6-6.2.0+dfsg1/debian/control   2016-04-04 11:23:13.0 +0200
> +++ vtk6-6.2.0+dfsg1/debian/control   2016-04-10 20:09:10.0 +0200
> @@ -95,6 +95,7 @@
>   libgl1-mesa-dev | libgl-dev,
>   libgl2ps-dev,
>   libglu1-mesa-dev | libglu-dev,
> + libhdf5-mpi-dev,
>   libjpeg-dev,
>   libjsoncpp-dev,
>   libmysqlclient-dev,
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#704206: teem: diff for NMU version 1.11.0~svn6057-1.1

[Gianfranco Costamagna]

Hi Tobias,


dcut ftp-master reschedule -d 0 -f teem_1.11.0~svn6057-1.1_source.changes


thanks for the NMU!

g.

On Sat, 09 Apr 2016 10:36:05 +0200 Tobias Frost  wrote:
> Control: tags 704206 + pending
> Control: tags 820503 + patch
> Control: tags 820503 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for teem (versioned as 1.11.0~svn6057-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> diff -Nru teem-1.11.0~svn6057/debian/changelog 
> teem-1.11.0~svn6057/debian/changelog
> --- teem-1.11.0~svn6057/debian/changelog  2013-08-17 05:16:21.0 
> +0200
> +++ teem-1.11.0~svn6057/debian/changelog  2016-04-09 10:34:39.0 
> +0200
> @@ -1,3 +1,13 @@
> +teem (1.11.0~svn6057-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Use -ffloat-store (i386) and -ffp-contract=off on certain archs to fix
> +testsuite failures due to rounding issues. Thanks to Adam Conrad and 
> Erwan
> +Prioul for the patch (Closes: #704206)
> +  * Make build verbose (Closes: #820503)
> +
> + -- Tobias Frost   Sat, 09 Apr 2016 10:34:39 +0200
> +
>  teem (1.11.0~svn6057-1) unstable; urgency=low
>  
>* new upstream snapshot
> diff -Nru teem-1.11.0~svn6057/debian/rules teem-1.11.0~svn6057/debian/rules
> --- teem-1.11.0~svn6057/debian/rules  2013-01-11 18:23:26.0 +0100
> +++ teem-1.11.0~svn6057/debian/rules  2016-04-09 10:27:04.0 +0200
> @@ -16,7 +16,7 @@
>  DEB_CMAKE_EXTRA_FLAGS = \
>  -DCMAKE_INSTALL_PREFIX:PATH=/usr \
>  -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
> --DCMAKE_VERBOSE_MAKEFILE=$(DH_VERBOSE) \
> +-DCMAKE_VERBOSE_MAKEFILE=ON \
>  -DCMAKE_SKIP_RPATH:BOOL=ON \
>  -DBUILD_EXPERIMENTAL_APPS:BOOL=OFF \
>  -DBUILD_EXPERIMENTAL_LIBS:BOOL=OFF \
> @@ -24,6 +24,13 @@
>  -DTeem_USE_LIB_INSTALL_SUBDIR:BOOL=ON \
>  -DBUILD_SHARED_LIBS:BOOL=ON \
>  
> +ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386))
> +  CFLAGS += -ffloat-store
> +endif
> +ifneq (,$(filter $(DEB_HOST_ARCH_CPU), powerpc ppc64 s390x))
> +  CFLAGS += -ffp-contract=off
> +endif
> +
>  
>  build/libteem${ABI_VERSION}::
>   cd $(DEB_BUILDDIR) && LD_LIBRARY_PATH=`pwd`/bin:$$LD_LIBRARY_PATH ctest 
> -VV -D ExperimentalTest
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Poly/ML 5.6-3

[Gianfranco Costamagna]

Hi, 

>Added in 
>http://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=bb8f943a3b54332b65cf4a64644e9e8b57bdbdcf.

ok :)

please do source-only uploads, or use pbuilder/sbuild to generate the binaries.
If you are in doubt, don't hesitate to ask me or to the debian-mentors list :)

$ dcut -k 92978A6E195E4921825F7FF0F34F09744E9F5DD9 ftp-master dm --uid "James 
Clarke" --allow polyml
Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
Picking DM James Clarke <jrt...@jrtc27.com> with fingerprint 
8F58342BEABE1EF4379551FBB193770C186A1C7D

You need a passphrase to unlock the secret key for
user: "Gianfranco Costamagna <locutusofb...@debian.org>"
4096-bit RSA key, ID 4E9F5DD9, created 2014-09-14

Uploading locutus-1457862406.dak-commands to ftp-master

now you should be able to perform the uploads by yourself :)

cheers!

Gianfranco

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

Re: Poly/ML 5.6-3

[Gianfranco Costamagna]

Hi, did you perform step 4?

I'm having a look soon, and if your key gets included in debian-keyring just 
ping me
https://wiki.debian.org/DebianMaintainer

cheers,

G.





Il Sabato 12 Marzo 2016 18:48, James Clarke  ha scritto:
Hi Gianfranco,
I’m ready to release polyml 5.6-3, with the following changes:

polyml (5.6-3) unstable; urgency=low

  * Support for the Hurd
  * Build is now reproducible
  * Bump up Standards-Version to 3.9.7
  * New patches:
- alpha.diff: Add support for alpha
- bss-ioarea.diff: Export ioarea to bss section
- m68k.diff: Add support for m68k
- maxpathlen.diff: Remove all use of MAXPATHLEN
- mips64.diff: Add support for mips64/mips64el
- noexec-stack-gnu.diff: Mark stack as non-executable on all GNU systems
- noflsh-unsigned.diff: Cast NOFLSH to unsigned (fixes a warning on the
Hurd)
- source-date-epoch.diff: Use SOURCE_DATE_EPOCH instead of current time if
it is defined
- x32.diff: Add support for x32

-- James Clarke   Sat, 12 Mar 2016 17:17:35 +

I don’t believe I yet have permission to upload polyml; could you please either 
grant me permission or sponsor another upload? In case of the latter, I have 
uploaded 5.6-3 to mentors.

Thanks,
James

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

Re: Your nfft upload to unstable

[Gianfranco Costamagna]

Hi Jonathan,


>This said, you got clearance to upload in #813019 which I've just found, 

>so you aren't really to blame for this. Still, it's a pity the 
>transition cannot proceed.


actually I checked (both the auto-nfft page, and the release.d.o bug), and 
there were no
collisions with other transitions.

One package is maintained by Ghislain, and so it shouldn't be a problem, while 
the other has
a partial patch, and had almost one year since the first 3.3~alpha release to 
make some work on that
side.

I'm not saying forcing people to transition is a nice way to do things (and 
sorry for that).
But having 9 months to make the package compliant with the new release should 
be a good timeline for everybody.

Specially because I posted the build failure fix on the bug report and "two" 
lines needed a change.
(a variable got renamed in nfft).

BTW the particular package was even marked for autoremoval (because of RC 
#811223 in one b-d) when I sponsored the package,
and this was another reason for not delaying the upload anymore.

I'm sure Ghislain will finish the work in the next few days :)

cheers,

Gianfranco

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

Bug#767338: vtk6: autopkgtest fails on unexpected warning

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
it seems it has been accidentally dropped while fixing #779802
http://anonscm.debian.org/cgit/debian-science/packages/vtk6.git/patch/de
bian/tests/control?id=0b9b3099c4bdde384ff64b751a58734f86c26e99

in fact in the bug report the patch provided doesn't change the
control file, so I suspect just a bad commit :)

cheers,

Gianfranco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWtitmAAoJEPNPCXROn13ZxnEQAJdJp62gTzONKfhJ8IlySpFt
fpNqyMxgVnjOLO54NYPedWWfFlc8U57Ic/sREqJAH11lxR76TZ5M5NoRKQGyW3qv
ALWjR3oLLNQK3jHTlDj/CcU368UgFZ2ftX7jQpKSQi8N6HDbn9RrjpmDbX18CfdV
1CliFT3s0TKQT2H/mLF5Y38OAsHIjTJBebfspoPO3s0bMd7Y4YhEtU1xipRyNH5F
lwI4DYSVysZx8uYdMBk09OOo7lRFkhDX2+bAjofBAU0ERmw6wh6Ycoy08VIgcwFU
kALCanrBBw6SX9lhiy5F4uqnR+wcIDDbPU96Lh5uaP6G8GwKfhEMZL+1jNB6bEVu
Ho/WAc67rHf/1vS8F0bVnIeHGo4m7rXCqdro/8awhlUdszJ/asWd/ZyjS5Xu2plt
BTu/rKRcWyVKfy9KKx4togbArd110OoE5fglY7LSGxDUXZqNiFha19bjE2yFW5Y+
bzgbE0gh35La2gRBoahzaRxG3BPUj6HZWbcGWal7YrvhKuFWt9mJuD5TrjXXtrku
WFv3f60Wnsd6DItdJRwYpwxnAEWYBWns42ikp4DCxmzO46BHxFHqWIRUEDm1TuSP
2aaBQcXLmHBoahQsW1WGsVQmbFt10bbR8jhjNsuuupHcKGhgNqeKKuG+SeUojDHg
bNFtKy62veqPEDSta+K5
=yD75
-END PGP SIGNATURE-

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

Re: polyml 5.6-2

[Gianfranco Costamagna]

Hi,

>That's odd; the only thing I can think of is I changed git-buildpackage from 
>re-creating the orig.tar.gz from the upstream tag to it using the pristine-tar 
>>branch... Perhaps they're not identical then? Anyway, thanks!


the problem seems to be about compression level.

I did a dpkg-buildpackage and it didn't complain about changed bits on the orig 
tarball, so probably it was a matter of some different compression
in the orig tarball.

Not a big issue, it happens to me from time to time and some packages.


>I didn't realise you thought I was ready; thanks, I may do so.

being a DM is the first step, and it means just "I want to maintain packages, 
and I'm already doing it for some".

The next step is to have dm permissions for a particular package, to upload 
directly the package without needing a sponsor.

for this you might need some additional uploads, but you are on the right way 
with your package.

cheers!

Gianfranco

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

Bug#793998: apophenia: FTBFS: tests fail on certain architectures

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, unfortunately this bug reappared in version 1.0+ds-1 where the
Debian patches have been included upstream, but a particular upstream
commit made a regression on many architectures.

reverting this commit [1] seems to work, but I'm sure about the
implications.

[1]
https://github.com/b-k/apophenia/commit/344fab5d7dcca241a3190acff9bfe1e6
33351eed

On Mon, 31 Aug 2015 16:38:06 -0400 u...@debian.org (Aaron M. Ucko) wrote
:
> notfixed 793998 0.999b+ds3-3 found 793998 0.999b+ds3-3 thanks
> 
> "Aaron M. Ucko"  writes:
> 
>> * distribution_tests fails on *i386 and ppc64el. *
>> ../eg/test_updating fails on arm64, (traditional) powerpc, and
>> s390x.
> 
> These two tests are better now, thanks!
> 
>> * s390x has one other failed test: ../eg/t_test_by_rows.
> 
> This test continues to fail on s390x, though; please keep this bug
> open until you've addressed it as well.
> 
> Thanks!
> 
> -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) 
> http://www.mit.edu/~amu/ |
> http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWq9X8AAoJEPNPCXROn13Z6goP/21wyitIfeA9P9ptxIcArD7L
m0I1nYXmUX+Sy7jQaAOhfqj3RGrum9lmX9gnQl+OmlcRpupByd/kXOYgAEfH4VHa
EkoBegZ+WmmELkLWkz3qyESW1N70oZcVVpK+MoUEna22VGXEUa9zM6X2b1aIG3wQ
dP9dxRHmh44egwXPMB7iAdhcP2hv+1tz7IXNNSNmeEC4RSQr/hlQ9rTvIm1Ishd7
GRzzB2QPYT/o3W+/7L4jbUhiYOLV2GeG8IUAc1Xv8bYpqpHsXso1Idy5LMvMFkm7
MJBYVZHqObTxJnJANPFXmYXADJGnvK4L3NPnZezvR87+6ms3Lctjsr/boy6p8CYZ
DwV3pQSZ6APd/+E1X8nHkQ78ODVq9aAWrxjSt+bPat91mFAKWq/7lhmrgIo348vD
u3mIF6AZVos6UH2froaAWv8/tRXXKzWr39DBByRCezBZJynGyJHXsDWu+/6r7GDw
piOJ8UN0H+1aaanz/hf3J+JLh0R/Wdcxp4M/IWuASdckQy8t71HrSWRnlfdmKkZA
sLHrn0ROq+oNTecYS1o/cykxH36U57hdmz6qxOjcQyXyUoO69/6P6sKTM7h0FuPk
eiGYNmzU22t0sLAmRor2NSngOU2dlEtJV/Mrw6PobIaNG31U0X7byzbO/g4VMqt+
mIxXbDKgmf1reg4Ir5w7
=vp/I
-END PGP SIGNATURE-

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

Re: polyml 5.6-1 (was: polyml 5.5.2-4)

[Gianfranco Costamagna]

Hi, sponsoring in a few moments.

note: it will go through binNEW queue :)

cheers,

G.





Il Martedì 26 Gennaio 2016 10:12, James Clarke <jrt...@jrtc27.com> ha scritto:
Hi Gianfranco,
I have uploaded 5.6-1 to mentors; could you please review it?

Thanks,
James


> On 25 Jan 2016, at 21:08, James Clarke <jrt...@jrtc27.com> wrote:
> 
> Ok, hopefully my s390x build will finish soon and I can then upload 5.6-1 to 
> mentors including S/390 support (and thus, barring any regressions, have 
> support for every release architecture!).
> 
> Thanks,
> James
> 
>> On 25 Jan 2016, at 21:07, Gianfranco Costamagna 
>> <costamagnagianfra...@yahoo.it> wrote:
>> 
>> Again, I think I'll trust your dsc file, but unfortunately I need to prior 
>> have one to test and double check/report back in case of issues.
>> 
>> So if you have a dsc, please share, I think it will be fine!
>> 
>> Cheers,
>> G.
>> 
>> Sent from Yahoo Mail on Android
>> 
>> On Mon, 25 Jan, 2016 at 22:00, James Clarke
>> <jrt...@jrtc27.com> wrote:
>> Hi Gianfranco,
>> For platforms where fe{g,s}etround (and other equivalent functions for 
>> different platforms), the implementation of {g,s}etRoundingMode is to raise 
>> an exception saying “Unable to set floating point rounding control” which 
>> can be either be caught in the user’s ML code or left to propagate up to the 
>> top level leading to an uncaught exception.
>> 
>> My proposal is this:
>> 
>> * On systems with __SOFTFP__ defined, raise an exception as above stating 
>> that {g,s}etRoundingMode is not supported for software-based floating point 
>> implementations.
>> * Modify the test case to catch this exception, in effect skipping it on 
>> armel.
>> 
>> What do you think?
>> 
>> Upstream has also just released 5.6 (it’s been on the horizon for a month 
>> but no date was given; if only they could have done so yesterday!). I have 
>> already updated locally and got it working for amd64. I also potentially 
>> have a working s390x patch (had to fix some assumptions in the code that 
>> break on a 64-bit big-endian architecture); just waiting for it to finish 
>> building in the emulator. Assuming my s390x patch works and you approve of 
>> my armel proposal, I will go ahead and add those to the package and then 
>> upload 5.6-1 to mentors.
>> 
>> Thanks,
>> James
>> 
>>> On 25 Jan 2016, at 20:49, Gianfranco Costamagna 
>>> <costamagnagianfra...@yahoo.it> wrote:
>>> 
>>> Hi, you are the maintainer, so it should be only up to you to make the 
>>> final decision about architectures to support.
>>> You need to understand the use case of this particular test, what is the 
>>> probability to hit this with real code running on an armel machine? In fact 
>>> since this has almost never worked on armel it wouldn't be a real 
>>> regression, but I'll leave to you the decision about the topic, and to me 
>>> eventually to complain if I don't like your solution (and you are free to 
>>> find a sponsor that likes better your approach) :-)
>>> 
>>> Just jocking, I always found a common agreement prior to sponsor a package 
>>> :)
>>> 
>>> So, at the end, please tell me your solution, or even better give me a dsc 
>>> to sponsor :)
>>> 
>>> If the bug is in glibc seems rather good to report it and disable the test.
>>> (Remember to reenable it if glibc gets fixed)
>>> 
>>> If it is by design broken on armel you might want to add a pointer 
>>> somewhere for the user, or a note in the manpage.
>>> 
>>> But again you are the maintainer, I trust your opinion after sponsoring 4 
>>> times already the package!
>>> 
>>> Cheers,
>>> 
>>> Gianfranco
>>> 
>>> Sent from Yahoo Mail on Android
>>> 
>>> On Mon, 25 Jan, 2016 at 20:55, James Clarke
>>> <jrt...@jrtc27.com> wrote:
>>> Hi Gianfranco,
>>> 
>>> 
>>>>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
>>>>> Should I get in touch with debian-arm?
>>>> 
>>>> probably yes, even if I don't care there are much armel porters there...
>>>> 
>>>> You might end up in asking ftpmaster to remove the armel binary.
>>> 
>>> 
>>> Ok, I think I’ve worked out what’s going on. The software floating-point 
>>> implementation seems to only support FE_NEAREST. On an ARM device without 

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Again, I think I'll trust your dsc file, but unfortunately I need to prior have 
one to test and double check/report back in case of issues.
So if you have a dsc, please share, I think it will be fine!
Cheers,G.
Sent from Yahoo Mail on Android 
 
  On Mon, 25 Jan, 2016 at 22:00, James Clarke<jrt...@jrtc27.com> wrote:   Hi 
Gianfranco,
For platforms where fe{g,s}etround (and other equivalent functions for 
different platforms), the implementation of {g,s}etRoundingMode is to raise an 
exception saying “Unable to set floating point rounding control” which can be 
either be caught in the user’s ML code or left to propagate up to the top level 
leading to an uncaught exception.

My proposal is this:

* On systems with __SOFTFP__ defined, raise an exception as above stating that 
{g,s}etRoundingMode is not supported for software-based floating point 
implementations.
* Modify the test case to catch this exception, in effect skipping it on armel.

What do you think?

Upstream has also just released 5.6 (it’s been on the horizon for a month but 
no date was given; if only they could have done so yesterday!). I have already 
updated locally and got it working for amd64. I also potentially have a working 
s390x patch (had to fix some assumptions in the code that break on a 64-bit 
big-endian architecture); just waiting for it to finish building in the 
emulator. Assuming my s390x patch works and you approve of my armel proposal, I 
will go ahead and add those to the package and then upload 5.6-1 to mentors.

Thanks,
James

> On 25 Jan 2016, at 20:49, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Hi, you are the maintainer, so it should be only up to you to make the final 
> decision about architectures to support.
> You need to understand the use case of this particular test, what is the 
> probability to hit this with real code running on an armel machine? In fact 
> since this has almost never worked on armel it wouldn't be a real regression, 
> but I'll leave to you the decision about the topic, and to me eventually to 
> complain if I don't like your solution (and you are free to find a sponsor 
> that likes better your approach) :-)
> 
> Just jocking, I always found a common agreement prior to sponsor a package :)
> 
> So, at the end, please tell me your solution, or even better give me a dsc to 
> sponsor :)
> 
> If the bug is in glibc seems rather good to report it and disable the test.
> (Remember to reenable it if glibc gets fixed)
> 
> If it is by design broken on armel you might want to add a pointer somewhere 
> for the user, or a note in the manpage.
> 
> But again you are the maintainer, I trust your opinion after sponsoring 4 
> times already the package!
> 
> Cheers,
> 
> Gianfranco
> 
> Sent from Yahoo Mail on Android
> 
> On Mon, 25 Jan, 2016 at 20:55, James Clarke
> <jrt...@jrtc27.com> wrote:
> Hi Gianfranco,
> 
> 
> >> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
> >> Should I get in touch with debian-arm?
> >
> > probably yes, even if I don't care there are much armel porters there...
> >
> > You might end up in asking ftpmaster to remove the armel binary.
> 
> 
> Ok, I think I’ve worked out what’s going on. The software floating-point 
> implementation seems to only support FE_NEAREST. On an ARM device without an 
> FPU, fe{g,s}etround are not supported and should return 1. However, if you 
> are running on an ARM device which has an FPU, fe{g,s}etround will change the 
> FPU’s rounding mode and return 0 for success, but because the floating-point 
> operations are done in software, the rounding mode has no effect. In short, 
> there’s no way for polyml to have proper rounding support on armel. Evidence 
> supporting this is below.
> 
> On cortex-r5:
> 
>    Current rounding: 0
>    Setting to FE_UPWARD (4194304): 1    <- rounding mode not supported
>    Current rounding: 0
>    1.0 / 3.0: 0.15
>    1.0 / 3.0 * 1.0: 1.00
>    Current rounding: 0
> 
> On cortex-a8:
> 
>    Current rounding: 0
>    Setting to FE_UPWARD (4194304): 0
>    Current rounding: 4194304
>    1.0 / 3.0: 0.15
>    1.0 / 3.0 * 1.0: 1.00
>    Current rounding: 4194304
> 
> Given that libc ships on armel but does not conform to the standard for 
> rounding, would it make sense to ship polyml for armel with this test 
> disabled? It seems a shame not to support armel at all.
> 
> Regards,
> James
  
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi, you are the maintainer, so it should be only up to you to make the final 
decision about architectures to support.You need to understand the use case of 
this particular test, what is the probability to hit this with real code 
running on an armel machine? In fact since this has almost never worked on 
armel it wouldn't be a real regression, but I'll leave to you the decision 
about the topic, and to me eventually to complain if I don't like your solution 
(and you are free to find a sponsor that likes better your approach) :-)
Just jocking, I always found a common agreement prior to sponsor a package :)
So, at the end, please tell me your solution, or even better give me a dsc to 
sponsor :)
If the bug is in glibc seems rather good to report it and disable the 
test.(Remember to reenable it if glibc gets fixed)
If it is by design broken on armel you might want to add a pointer somewhere 
for the user, or a note in the manpage.
But again you are the maintainer, I trust your opinion after sponsoring 4 times 
already the package!

Cheers,
Gianfranco

Sent from Yahoo Mail on Android 
 
  On Mon, 25 Jan, 2016 at 20:55, James Clarke wrote:   Hi 
Gianfranco,

>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
>> Should I get in touch with debian-arm?
> 
> probably yes, even if I don't care there are much armel porters there...
> 
> You might end up in asking ftpmaster to remove the armel binary.

Ok, I think I’ve worked out what’s going on. The software floating-point 
implementation seems to only support FE_NEAREST. On an ARM device without an 
FPU, fe{g,s}etround are not supported and should return 1. However, if you are 
running on an ARM device which has an FPU, fe{g,s}etround will change the FPU’s 
rounding mode and return 0 for success, but because the floating-point 
operations are done in software, the rounding mode has no effect. In short, 
there’s no way for polyml to have proper rounding support on armel. Evidence 
supporting this is below.

On cortex-r5:

    Current rounding: 0
    Setting to FE_UPWARD (4194304): 1    <- rounding mode not supported
    Current rounding: 0
    1.0 / 3.0: 0.15
    1.0 / 3.0 * 1.0: 1.00
    Current rounding: 0

On cortex-a8:

    Current rounding: 0
    Setting to FE_UPWARD (4194304): 0
    Current rounding: 4194304
    1.0 / 3.0: 0.15
    1.0 / 3.0 * 1.0: 1.00
    Current rounding: 4194304

Given that libc ships on armel but does not conform to the standard for 
rounding, would it make sense to ship polyml for armel with this test disabled? 
It seems a shame not to support armel at all.

Regards,
James  
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi,

>Meant to say: I have one, though it’s running raspbian; would that mess with 
>things?
not sure, I'm pretty sure the bug has always been there, just hidden because of 
a missing
testsuite run...
and you don't have too much dependencies on your package, so probably you will 
hit the bug
on raspbian too (BTW do you have an armel raspbian? I thought nobody was still 
using armel,
and everybody was on armhf for raspberrypi now ;) )

anyway, my first build was on qemu pbuilder-dist, and I'm running right now two 
builds.


one locally, and one in a porterbox

./poly < Tests/Succeed/Test121.ML
Poly/ML 5.5.2 Release
val check = fn: bool -> unit
exception Unordered
type decimal_approx =
{class: float_class, digits: int list, exp: int, sign: bool}
datatype float_class = INF | NAN | NORMAL | SUBNORMAL | ZERO
val fromString = fn: string -> decimal_approx option
val getRoundingMode = fn: unit -> rounding_mode
datatype real_order = EQUAL | GREATER | LESS | UNORDERED
datatype rounding_mode = TO_NEAREST | TO_NEGINF | TO_POSINF | TO_ZERO
val scan = fn:
(char, 'a) StringCvt.reader -> (decimal_approx, 'a) StringCvt.reader
val setRoundingMode = fn: rounding_mode -> unit
val toString = fn: decimal_approx -> string
val it = (): unit
val it = (): unit
val pos = 0.33: real
Exception- Fail "Wrong" raised
val neg = ~0.33: real
Exception- Fail "Wrong" raised
val it = (): unit
val it = (): unit
val pos = 0.33: real
Exception- Fail "Wrong" raised
val neg = ~0.33: real
Exception- Fail "Wrong" raised
val it = (): unit
val it = (): unit
val pos = 0.33: real
Exception- Fail "Wrong" raised
val neg = ~0.33: real
Exception- Fail "Wrong" raised
val it = (): unit
val it = (): unit
val it = (): unit
val pos = 0.33: real
val neg = ~0.33: real
val it = (): unit


I quickly looked at the test
setRoundingMode(TO_POSINF);
check(getRoundingMode() = TO_POSINF);
val pos = 1.0/3.0;
check(pos * 3.0 > 1.0);
val neg = ~1.0/3.0;
check(neg * 3.0 > ~1.0);


well, I'm not sure the test is correct, I mean, you might have the exact 1.0 
value too

setRoundingMode(TO_POSINF);
check(getRoundingMode() = TO_POSINF);
val pos = 1.0/3.0;
check(pos * 3.0 >= 1.0);
val neg = ~1.0/3.0;
check(neg * 3.0 >= ~1.0);


seems to be more appropriate to me (replace > with >=)
not sure if with Real numbers this is something that can happen
(I mean this kind of rounding), but seems to be fixing the issue.

I can upload the fix, if you give me a dsc file :)
(note: I'm not sure this change is sane, I don't understand polyml language, so 
probably
you might have a better point of view than me).

BTW, what about overriding dh_auto_test to print the command you gave me in 
case of failure?

something like
override_dh_auto_test:
dh_auto_test || do something in case of failure, e.g. loop and print tests || 
exit 1

not sure if it works, needs to be tested :)

cheers,

G.

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi,

>That’s my guess. The test suite wasn’t run before I took over (I feared I had 
>stopped it running when I changed debian/rules to modern debhelper) either, so 
>who >knows how long it’s been there.



I don't find running testsuites there
https://buildd.debian.org/status/logs.php?pkg=polyml=armel
>It’s armhf, though you can use an armel pbuilder on top of that, no? The armel 
>buildd used has Machine Architecture: armhf.


I don't know... is it faster than a qemu virtual environment? I'm not sure 
about it, probably yes, but I never did tests

>Thanks to your pbuilderrc fix I’m running a build myself, although it’s going 
>to take a while...


(note I used apt experimental resolver, but it should work with plain apt, or 
apt-classic too)

>1/3 can’t be represented exactly, so when rounding to +Inf, you get a little 
>bit more than 1/3. 3 can be represented exactly, so 3 * 1/3 is a little more 
>than 1, >and since the rounding mode is set to +Inf it should therefore round 
>to a little over 1. I’m pretty sure the test is correct; certainly it works on 
>every other >supported platform.


ok


>> override_dh_auto_test:
>> dh_auto_test || do something in case of failure, e.g. loop and print tests 
>> || exit 1>
>
>I’m not sure what you mean?


the || means "exec the next command if the first doesn't exit successfully"

override_dh_auto_foo
dh_auto_foo
is usually a no-op, but if you append a || another command

it means:
execute dh_auto_foo, if it returns !=0 then execute "another command", that 
might be the call you asked me to do before

since the second command might be successful, but the testsuite wasn't, to 
avoid hiding testfailures, it is nice to append

&& exit 1 (not || this time, it was a typo from my side), this should mean
do the testsuite

if it fails, try to print something verbose on buildd machine logs, so we can 
see what happened, but in this case exit the build with a failure
value

look e.g. here
https://sources.debian.net/src/insighttoolkit4/4.8.2-3.1/debian/rules/


cheers,

G.

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi,




>Yeah that’s what I was saying; there are no runs for any previous versions.


ok, I read it wrongly then :)

>Probably not given the lack of power on a pi.



real hw is anyway better because it can exclude qemu related bugs :)

>I’m aware of the sh syntax; the trouble is, the test suite doesn’t log 
>anything to a file like that example, so I would have to re-run the failed 
>tests manually, >or mess with the testing code itself.


mmm I was thinking about:
dh_auto_test || for i=1 to n do ./poly < Tests/Succeed/Test$$i.ML; done && exit 
1

what is printed here is visible on buildd logs, so you might have at least a 
clue to the test output

>Have you had a look at my other email which includes a short test program?


sure, answer already performed, but not sent
(I'm waiting the result of a build to hit enter :p)



cheers,

G.

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi,

> 1/3 can’t be represented exactly, so when rounding to +Inf, you get a little 
> bit more than 1/3. 3 can be represented exactly, so 3 * 1/3 is a little more 
> than 1, >and since the rounding mode is set to +Inf it should therefore round 
> to a little over 1. I’m pretty sure the test is correct; certainly it works 
> on every other >supported platform.


ok

>Besides FE_UPWARD having a different value (given that it’s 
>platform-specific), armel calculates 1.0 / 3.0 as 0.15, which 
>is wrong for FE_UPWARD >(but correct for FE_NEAREST), and I imagine there are 
>similar issues for the other rounding modes (other than FE_NEAREST). Any 
>thoughts as to what could be going >on?
sorry but I didn't even understand what you said here :) you have a knowledge 
on the rounding model order of magnitude higher than mine :)
I don't think I can help here, but BTW

IIRC armel doesn't have floating point instructions, but only emulated in 
software (this should be the difference with armhf), so can this be

just a gcc-5 bug? you might want to try and use gcc-4.9 or gcc-6 from 
experimental to see if the bug is still there

I did a few seconds ago a build with CC=gcc-4.9 CXX=g++-4.9 in rules file
and also with gcc-6, it fails on all of them.

cheers,

Gianfranco

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi,

>I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. 
>Should I get in touch with debian-arm?


probably yes, even if I don't care there are much armel porters there...

You might end up in asking ftpmaster to remove the armel binary.

cheers,

Gianfranco

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi James,


>I have been working with upstream to port Poly/ML to additional architectures, 
>and have backported these changes. I have uploaded 5.5.2-4 to mentors; could 
>you >please check it and then upload it?



wonderful, lets review:

1) you took over the package maintenance, can I see a post where the current 
uploaders acked the change?
2) a patch against testsuite not mentioned in changelog
3) patches against mips* not mentioned in changelog.

basically I would change changelog mentioning the patch name, e.g.
new patches:
foo.diff: add support for foo architecture

and so on.
the patches should be good :)

cheers,

Gianfranco

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi,

>I am aware s390x is failing. I have been trying to port it, and it no longer 
>segfaults (thanks to the pexport-endian.diff patch from upstream), but one 
>part of the >build step (the compiler bootstrapping itself) exits with code 1, 
>without printing anything. That’s on my list of things to talk to upstream 
>about.



I'm not sure I can help here... for sure you have to patch configure.ac, but 
other than that some code might be needed aswell.
>x32 fails because there’s some hand-written assembly that isn’t aware of x32 
>(it assumes i386 and amd64 are the only two cases).


ok

>Interestingly armel has failed a test case for floating-point (funnily enough 
>I had just that test failed when I was testing ppc64el and it turned out to be 
>a bug >in qemu!), so I’ll need to look into that. Previous uploads weren’t 
>running the tests as part of the build, so I don’t know if this is a 
>regression or not. armhf >has built successfully though...


ok (I'll point you to a solution if possible)

>I’m currently a student, so one package is more than enough, although 
>certainly one day I would consider applying to be a Debian Maintainer. Having 
>said that, for >a package in debian-science, there’s hardly any inconvenience 
>on my part.


wonderful :)

BTW you can apply as DM also if you want to maintain only one package, assuming 
you will in the future try to be more involved :)

cheers,

G.



> On 24 Jan 2016, at 20:10, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Sure, thanks for the kind words for the former maintainers :)
> 
> Btw s390x and x32 just failed to build, you might want to poke upstream about 
> a porting, and ping me about testing patches on porter boxes :)
> 
> If you want ti maintain some other packages you might even consider applying 
> for Debian Contributor or Debian Maintainer, you are doing a good job here, 
> you might even have direct upload privileges one day for this package :)
> 
> Cheers,
> 
> G.
> --------
> Dom 24/1/16, James Clarke <jrt...@jrtc27.com> ha scritto:
> 
> Oggetto: Re: polyml 5.5.2-4
> A: "Gianfranco Costamagna" <costamagnagianfra...@yahoo.it>
> Cc: "Debian Science Team" 
> <debian-science-maintainers@lists.alioth.debian.org>, "Lionel Elie Mamane" 
> <lio...@mamane.lu>, "Achim D. Brucker" <adbruc...@0x5f.org>
> Data: Domenica 24 gennaio 2016, 20:47
> 
> Oh right, I wasn’t
> aware such a thing was the done thing; I was just using
> xindy (just so happened to see that someone took over
> maintenance of it on debian-devel) as a reference. Of course
> it goes without saying that I’m grateful for all the work
> Lionel and Achim have done on it; I hope nobody thinks
> otherwise. Without them there would be no Poly/ML package on
> Debian and its derivatives.
> 
> Thanks for continuing to sponsor me!
> 
> Regards,
> James
> 
>> 
> On 24 Jan 2016, at 19:41, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it>
> wrote:
>> 
>> I uploaded
> it a few seconds ago, hopefully it will appear before the
> next dinstall
>> (due in 12 minutes), and
> then start building everywhere.
>> 
>> BTW nitpick, usually on changelog when a
> person takes over a package maintenance
>> 
> is used to say somthing like
>> "take
> over the package maintenance
>> - thanks
> Lionel, and Achim for your work!"
>> 
> 
>> and then upload :)
>> 
>> anyway, thanks to
> you both for your work, and James, keep up the nice work!
>> (as you did in the last three uploads)
>> 
>> cheers,
>> 
>> Gianfranco
>> 
>> 
>> 
>> 
>> 
>> Il Domenica 24
> Gennaio 2016 20:38, James Clarke <jrt...@jrtc27.com>
> ha scritto:
>> Hi Gianfranco (cc’d
> Lionel and Achim as this upload officially makes me
> uploader),
>> Many thanks; I’ll push the
> changes to debian-science/polyml.git.
>> 
> 
>> Regards,
>> James
>> 
>> 
>>> On 24 Jan 2016, at 19:36, Gianfranco
> Costamagna <costamagnagianfra...@yahoo.it>
> wrote:
>>> 
>>> 
> Signed in a few minutes!
>>> 
>>> thanks for
> your contribution to Debian!
>>> 
>>> cheers,
>>> 
>>> Gianfranco
>>> 
> 
>>> 
>>> 
>>> 
>>> 
>>> Il Domenica 24 Gennaio 2016 14:54,
> James Clarke <jrt...@jrtc27.com>
> ha scritto:
>>> Hi Gianfranco,
>>> 
>>>> 1) you
> took over the package maintenance, can I see a post

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Hi again,



>Is there any way in which I could get access to an armel porter box to try and 
>work out what’s causing the failure?


as a normal contributor not, as a DM yes, after you requested the access, as a 
DD yes.

that said, I'm happy to test patches if you have some, but I can't easily give 
you access to a machine
(I have a raspberrypi in the office, I could try to wake it on :) )


anyway, back to my DM days, I always managed to fix the porting issues in this 
way
pbuilder-dist sid armel update

pbuilder-dist sid armel build polyml_5.5.2-4.dsc

or

pbuilder-dist sid armel login


IIRC you need qemu-user-static or something similar, but it is quite handy when 
it works :)
(slow but nice)

BTW since a few days it is segfaulting with apt set as resolver (or was it 
aptitude the default?)
anyway, I added this to my pbuilderrc
PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-experimental"



it doesn't finish completely the build, but I can go until the failing test
Test121.ML => Failed!!
Test120.ML => Passed
Test119.ML => Passed
Test118.ML => Passed
Test117.ML => Passed
Test116.ML => Passed
Test115.ML => Passed

[...]
Test026.ML => Passed
Test025.ML => qemu: uncaught target signal 11 (Segmentation fault) - core dumped
/bin/bash: line 1: 12858 Doneecho "val () = use 
\"./Tests/RunTests\"; val () = OS.Process.exit(if runTests \"./Tests\" then 
OS.Process.success else OS.Process.failure):unit;"
12859 Segmentation fault  | ./poly
Makefile:1178: recipe for target 'check-local' failed
make[3]: *** [check-local] Error 139
make[3]: Leaving directory '/build/polyml-5.5.2'
Makefile:998: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory '/build/polyml-5.5.2'
Makefile:707: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/build/polyml-5.5.2'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


does this help you?

cheers,

Gianfranco

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

I uploaded it a few seconds ago, hopefully it will appear before the next 
dinstall
(due in 12 minutes), and then start building everywhere.

BTW nitpick, usually on changelog when a person takes over a package maintenance
is used to say somthing like
"take over the package maintenance
 - thanks Lionel, and Achim for your work!"

and then upload :)

anyway, thanks to you both for your work, and James, keep up the nice work!
(as you did in the last three uploads)

cheers,

Gianfranco





Il Domenica 24 Gennaio 2016 20:38, James Clarke <jrt...@jrtc27.com> ha scritto:
Hi Gianfranco (cc’d Lionel and Achim as this upload officially makes me 
uploader),
Many thanks; I’ll push the changes to debian-science/polyml.git.

Regards,
James


> On 24 Jan 2016, at 19:36, Gianfranco Costamagna 
> <costamagnagianfra...@yahoo.it> wrote:
> 
> Signed in a few minutes!
> 
> thanks for your contribution to Debian!
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> 
> Il Domenica 24 Gennaio 2016 14:54, James Clarke <jrt...@jrtc27.com> ha 
> scritto:
> Hi Gianfranco,
> 
>> 1) you took over the package maintenance, can I see a post where the current 
>> uploaders acked the change?
> 
> Please see the entirety of this thread in debian-science: 
> https://lists.debian.org/debian-science/2016/01/msg00035.html
> 
>> 2) a patch against testsuite not mentioned in changelog
>> 3) patches against mips* not mentioned in changelog.
>> 
>> basically I would change changelog mentioning the patch name, e.g.
>> new patches:
>> foo.diff: add support for foo architecture
>> 
>> and so on.
>> the patches should be good :)
> 
> I have amended the changelog and re-uploaded to mentors; how is it now?
> 
> Thanks,
> 
> James

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Signed in a few minutes!

thanks for your contribution to Debian!

cheers,

Gianfranco





Il Domenica 24 Gennaio 2016 14:54, James Clarke  ha scritto:
Hi Gianfranco,

> 1) you took over the package maintenance, can I see a post where the current 
> uploaders acked the change?

Please see the entirety of this thread in debian-science: 
https://lists.debian.org/debian-science/2016/01/msg00035.html

> 2) a patch against testsuite not mentioned in changelog
> 3) patches against mips* not mentioned in changelog.
> 
> basically I would change changelog mentioning the patch name, e.g.
> new patches:
> foo.diff: add support for foo architecture
> 
> and so on.
> the patches should be good :)

I have amended the changelog and re-uploaded to mentors; how is it now?

Thanks,

James

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

Re: polyml 5.5.2-4

[Gianfranco Costamagna]

Sure, thanks for the kind words for the former maintainers :)

Btw s390x and x32 just failed to build, you might want to poke upstream about a 
porting, and ping me about testing patches on porter boxes :)

If you want ti maintain some other packages you might even consider applying 
for Debian Contributor or Debian Maintainer, you are doing a good job here, you 
might even have direct upload privileges one day for this package :)

Cheers,

G.

Dom 24/1/16, James Clarke <jrt...@jrtc27.com> ha scritto:

 Oggetto: Re: polyml 5.5.2-4
 A: "Gianfranco Costamagna" <costamagnagianfra...@yahoo.it>
 Cc: "Debian Science Team" 
<debian-science-maintainers@lists.alioth.debian.org>, "Lionel Elie Mamane" 
<lio...@mamane.lu>, "Achim D. Brucker" <adbruc...@0x5f.org>
 Data: Domenica 24 gennaio 2016, 20:47
 
 Oh right, I wasn’t
 aware such a thing was the done thing; I was just using
 xindy (just so happened to see that someone took over
 maintenance of it on debian-devel) as a reference. Of course
 it goes without saying that I’m grateful for all the work
 Lionel and Achim have done on it; I hope nobody thinks
 otherwise. Without them there would be no Poly/ML package on
 Debian and its derivatives.
 
 Thanks for continuing to sponsor me!
 
 Regards,
 James
 
 >
 On 24 Jan 2016, at 19:41, Gianfranco Costamagna <costamagnagianfra...@yahoo.it>
 wrote:
 > 
 > I uploaded
 it a few seconds ago, hopefully it will appear before the
 next dinstall
 > (due in 12 minutes), and
 then start building everywhere.
 > 
 > BTW nitpick, usually on changelog when a
 person takes over a package maintenance
 >
 is used to say somthing like
 > "take
 over the package maintenance
 > - thanks
 Lionel, and Achim for your work!"
 >
 
 > and then upload :)
 > 
 > anyway, thanks to
 you both for your work, and James, keep up the nice work!
 > (as you did in the last three uploads)
 > 
 > cheers,
 > 
 > Gianfranco
 > 
 > 
 > 
 > 
 > 
 > Il Domenica 24
 Gennaio 2016 20:38, James Clarke <jrt...@jrtc27.com>
 ha scritto:
 > Hi Gianfranco (cc’d
 Lionel and Achim as this upload officially makes me
 uploader),
 > Many thanks; I’ll push the
 changes to debian-science/polyml.git.
 >
 
 > Regards,
 > James
 > 
 > 
 >> On 24 Jan 2016, at 19:36, Gianfranco
 Costamagna <costamagnagianfra...@yahoo.it>
 wrote:
 >> 
 >>
 Signed in a few minutes!
 >> 
 >> thanks for
 your contribution to Debian!
 >> 
 >> cheers,
 >> 
 >> Gianfranco
 >>
 
 >> 
 >> 
 >> 
 >> 
 >> Il Domenica 24 Gennaio 2016 14:54,
 James Clarke <jrt...@jrtc27.com>
 ha scritto:
 >> Hi Gianfranco,
 >> 
 >>> 1) you
 took over the package maintenance, can I see a post where
 the current uploaders acked the change?
 >> 
 >> Please see
 the entirety of this thread in debian-science: 
https://lists.debian.org/debian-science/2016/01/msg00035.html
 >> 
 >>> 2) a
 patch against testsuite not mentioned in changelog
 >>> 3) patches against mips* not
 mentioned in changelog.
 >>> 
 >>> basically I would change changelog
 mentioning the patch name, e.g.
 >>>
 new patches:
 >>> foo.diff: add
 support for foo architecture
 >>>
 
 >>> and so on.
 >>> the patches should be good :)
 >> 
 >> I have
 amended the changelog and re-uploaded to mentors; how is it
 now?
 >> 
 >>
 Thanks,
 >> 
 >>
 James

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

Bug#810188: ipe: diff for NMU version 7.1.10-1.1

[Gianfranco Costamagna]

Control: tags 810188 + patch
Control: tags 810188 + pending


Dear maintainer,

I've prepared an NMU for ipe (versioned as 7.1.10-1.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru ipe-7.1.10/debian/changelog ipe-7.1.10/debian/changelog
--- ipe-7.1.10/debian/changelog 2015-11-21 18:11:39.0 +0100
+++ ipe-7.1.10/debian/changelog 2016-01-22 11:09:49.0 +0100
@@ -1,3 +1,11 @@
+ipe (7.1.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #810188)
+
+ -- Gianfranco Costamagna <locutusofb...@debian.org>  Fri, 22 Jan 2016 
11:09:34 +0100
+
ipe (7.1.10-1) unstable; urgency=medium

* New upstream.
diff -Nru ipe-7.1.10/debian/control ipe-7.1.10/debian/control
--- ipe-7.1.10/debian/control   2015-11-21 14:58:27.0 +0100
+++ ipe-7.1.10/debian/control   2016-01-22 11:09:31.0 +0100
@@ -14,7 +14,7 @@
libfreetype6-dev (>= 2.3.9),
libcairo2-dev,
libjpeg8-dev,
-  libpng12-dev,
+  libpng-dev,
liblua5.2-dev,
gsfonts
Build-Conflicts: libipe1-dev

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

Bug#811761: cld2: FTBFS with GCC 6: narrowing conversion

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/CLD2Owners/cld2/issues/47


Hi Martin, thanks for the useful bug report, I have reported it upstream.

cheers,

Gianfranco




Il Mercoledì 20 Gennaio 2016 3:06, Martin Michlmayr  ha scritto:
Package: cld2
Version: 0.0.0-git20150806-2
Severity: important
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-6 gcc-6-narrowing

This package fails to build with GCC 6.  GCC 6 has not been released
yet, but it's expected that GCC 6 will become the default compiler for
stretch.

Note that only the first error is reported; there might be more.  You
can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
you can set CC=gcc-6 CXX=g++-6 explicitly.

You may be able to find out more about this issue at
https://gcc.gnu.org/gcc-6/changes.html

> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
...
> [ 29%] Building CXX object 
> CMakeFiles/cld2_full.dir/internal/cld_generated_cjk_delta_bi_32.cc.o
> /usr/bin/c++   -Dcld2_full_EXPORTS  -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -fPIC   -o 
> CMakeFiles/cld2_full.dir/internal/cld_generated_cjk_delta_bi_32.cc.o -c 
> /<>/internal/cld_generated_cjk_delta_bi_32.cc
> /<>/internal/scoreonescriptspan.cc: In function 'void 
> CLD2::ScoreEntireScriptSpan(const CLD2::LangSpan&, CLD2::ScoringContext*, 
> CLD2::DocTote*, CLD2::ResultChunkVector*)':
> /<>/internal/scoreonescriptspan.cc:1149:5: warning: narrowing 
> conversion of 'score' from 'int' to 'CLD2::uint16 {aka short unsigned int}' 
> inside { } [-Wnarrowing]
>  };
>  ^
> 
> /<>/internal/scoreonescriptspan.cc:1149:5: warning: narrowing 
> conversion of 'bytes' from 'int' to 'CLD2::uint16 {aka short unsigned int}' 
> inside { } [-Wnarrowing]
> /<>/internal/scoreonescriptspan.cc:1149:5: warning: narrowing 
> conversion of 'reliability' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/scoreonescriptspan.cc:1149:5: warning: narrowing 
> conversion of 'reliability' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
>  };
>  ^
> 
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of '-14' from 'int' to 'CLD2::uint8 {aka unsigned char}' 
> inside { } [-Wnarrowing]
> /<>/internal/cld_generated_cjk_uni_prop_80.cc:7089:1: error: 
> narrowing conversion of 

Bug#808320: Proposed fix with breaks / replaces

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

> +Replaces: libarrayfire-cpu-dev (<< 3.2.1+dfsg1-6) +Breaks:
> libarrayfire-cpu-dev (<< 3.2.1+dfsg1-6)

please check this wiky, that should have the most common use-cases
https://wiki.debian.org/PackageTransition

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWd3sxAAoJEPNPCXROn13ZH3gP/0STTxRv6pNCQQpxdOKsgJgk
ClQUDbE8hdzKDIAFLCXgWnv1Hxq8GO0Z5xkAQoCAefzZd4hv2Q6ZaBb3v2K8OE/c
SVhkvRjr8JpZqbmCHeyk7wAmyrDHjhuofJge9M4NOOCuOLeac5lh8Fwo/O6i8bnN
MvqdYxWsyj218FKmOTZ55a/fR3HQ2yqiLXYBa+yNm0hdT0PF4eiOcgYDzR0oewtD
nIJAkkBOlRiw8tyLoJbn1UAd8nIughA651Xc/A+TSPpDtufUJdEbTdSORJyAiCYC
xXMxtZypZ1gHEdTthul+L3rcIjtgyUm6a1+slG2c76s39/nUuJgxDfpBtHkQNb//
lkxKSAEkIpyimNEw5PcItj1vrsNtFG1nwlTE3uqoSyzP1RNXRbsv6I7b0MQW/7eB
ORjL2vbFArgWlIdV8bMBL3fJaSFSpDX9kqZw4f99vTiomUPfGj9ZLZjyvg5vzAHb
Ds62w8dZAgS+BuTE7Og0LD//aJHn3s9D+l/QltAkNP5bl2OqO9Ku3F8y2ftcNLGG
9W+2HjdiXqnf8f8p1TIsI0ewhXFwJ/4QKlxQNEgMmip8iW7OxCZ9BuHa9MX0EujD
ucyR1BcXdgZsjDR8arG7J6MHPDwD+b70zv/qRwBsoB7pnq7qy2qyou0zs5jTUGqp
RUylV5wcr/oTA/o4dHAb
=xGg2
-END PGP SIGNATURE-

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

Re: polyml 5.5.2-3

[Gianfranco Costamagna]

Hi, yes, this is a false positive!

anyway, Built thanks for your contribution to Debian!

cheers,

G.





Il Mercoledì 21 Ottobre 2015 2:46, James Clarke  ha scritto:
My guess is the version of lintian on mentors.debian.net is not completely up 
to date. Lintian has only accepted the trigger since 2015-09-10 
(https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=5468a38e208e7041279fa6b68ab7116a38263865)
 with 2.5.37 being the first version to contain it.

James


> On 20 Oct 2015, at 23:09, James Clarke  wrote:
> 
> For some reason, mentors is giving a lintian error for 
> "postinst-must-call-ldconfig”, although I have extracted the control 
> information from the package and the contents of triggers is:
> 
>> # Triggers added by dh_makeshlibs
>> activate-noawait ldconfig
> 
> as expected, which is supposed to make lintian happy. Running lintian locally 
> does not give this error which makes this even stranger.
> 
> James
> 
>> On 20 Oct 2015, at 22:45, James Clarke  wrote:
>> 
>> Hi Gianfranco,
>> I’ve updated the package to support arm64 using a patch from upstream, and 
>> uploaded it to mentors as 5.5.2-3. Could you please check and upload it?
>> 
>> Thanks,
>> James
>> 
> 

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

Re: Bug#787861: review: polyml

[Gianfranco Costamagna]

Hi James,

I sponsored the package
(BTW I was intending to subscribe to debian-science, but also debian-devel is 
nice to be subscribed)


However, I would appreciate a fix for the following missing flags in a future 
release:
CXXFLAGS missing (-fPIE):
LDFLAGS missing (-Wl,-z,now)
CFLAGS missing (-fPIE):
LDFLAGS missing (-fPIE -pie -Wl,-z,now)
you can see the full log here [1] or by using blhc tool


[1] http://debomatic-i386.debian.net/distribution#unstable/polyml/5.5.2-1/blhc



cheers,

G.

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

Re: Bug#787861: review: polyml

[Gianfranco Costamagna]

Hi James,




>
>
>I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling 
>all hardening flags. I also realised that the new polyc shell script requires 
>gcc and >libffi-dev to produce standalone executables, so I have added those 
>as dependencies for polyml.


wonderful, I'll upload again then :)
>Should I push my changes to debian-science/packages/polyml.git (especially 
>since that’s the repository in debian/control)? Also, going forwards, if I 
>want to get a >new version uploaded, do I need to file a new RFS “bug” against 
>sponsorship-requests, or should I instead just email debian-science asking for 
>a team upload >(subject to a review of the package)?


yes, and if you can't do it I can do it for you :)

For another upload you can ping me directly or add an RFS bug, as you prefer.

cheers,

G.

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

Re: Bug#787861: review: polyml

[Gianfranco Costamagna]

it is fine, the first upload is always tricky, after things are easier :)


cheers,


G.


Sent from Yahoo Mail on Android

From:"James Clarke" 
Date:Sat, 17 Oct, 2015 at 17:33
Subject:Bug#787861: review: polyml

Hi Gianfranco,

>> I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling 
>> all hardening flags. I also realised that the new polyc shell script 
>> requires gcc and >libffi-dev to produce standalone executables, so I have 
>> added those as dependencies for polyml.
> 
> wonderful, I'll upload again then :)

Great, thanks.

>> Should I push my changes to debian-science/packages/polyml.git (especially 
>> since that’s the repository in debian/control)? Also, going forwards, if I 
>> want to get a >new version uploaded, do I need to file a new RFS “bug” 
>> against sponsorship-requests, or should I instead just email debian-science 
>> asking for a team upload >(subject to a review of the package)?
> 
> yes, and if you can't do it I can do it for you :)

Pushed.

> For another upload you can ping me directly or add an RFS bug, as you prefer.

Ok, I’ll probably come to you first then seeing as creating an RFS bug can be a 
nuisance; having the same uploader would make sense, rather than some new 
person having to start from scratch with the package every time. Of course, if 
you ever want me to find someone else, please say so; I’ll understand :)

Thanks,


James

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

Re: Bug#787861: review: polyml

[Gianfranco Costamagna]

Hi James


>I have uploaded 5.5.2-1~rc2 to mentors.



please call it 5.5.2-1 and nothing more :)
you can push the same version many times on mentors with no problems.
>1) Do I need to send a separate email to this then? I also filed #801793 for a 
>transition, but that has already been closed as unnecessary since there are no 
>rdeps.


true, nevermind I didn't test carefully rdeps
(so we might go directly on unstable then)

>I hardly think linking against this static library is an issue.


ok
>7) I have added arm64, ppc64el and ppc64


what about the "any" keyword? I don't like specifying manually architectures, 
specially because it makes
porters people angry :)

porters needs a build failure instead of a build that didn't start at all, 
except when there is a good
reason to not build on a particular architecture
e.g. systemd on kfreebsd-* and hurd-*

>9) Added (libffi/msvcc.sh is MPL-1.1, GPL-2.0+ or LGPL-2.1+)


wonderful
>11) It doesn’t seem to work without the debian/tmp/ prefix. The manpage for 
>dh_install specifically mentions falling back to debian/tmp/, but there is no 
>such >statement in dh_installman, so I believe you have to specify that 
>manually.


well, no problem
>12) I unused-file-paragraph-in-dep5-copyright: Fixed by reordering entries
>13) I vcs-field-not-canonical: Changed to Vcs-Browser: 
>https://anonscm.debian.org/cgit/debian-science/packages/polyml.git/ and 
>Vcs-Git: git://anonscm.debian.org/debian-science/packages/polyml.git
>14) W shlib-with-executable-stack: This is because libpolyml has one assembly 
>file[1] for x86 (other architectures don’t have any assembly). I have added a 
>patch under debian/patches which I have also submitted upstream to fix this.
>

>[1] GNU as defaults to having an executable stack, unlike with GCC etc, and 
>you have to explicitly tell it to not do so. You can either do this by adding 
>the magic >'.section .note.GNU-stack, "", @progbits' statement, or by passing 
>it a command-line argument. The former is apparently generally preferred (and 
>is what libffi >does in its assembly files).
nice to learn something new! thanks a lot



I guess we are mostly ready, just go on unstable (urgency=low might be better)
think about arch:any

and I guess I'll prepare the upload.

cheers,

G.

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

Re: Bug#787861: review: polyml

[Gianfranco Costamagna]

Hi,

>I have uploaded the latest version to mentors. Currently, the old maintainers 
>are still listed in debian/control. I’m happy to assume responsibility for bug 
>>reports etc, so do I need to add myself to Uploaders? I don’t want to tread 
>on anyone’s toes though if that’s bad form.

well, for sure I suggest you to subscribe to debian-devel mail list and to the 
package [1] at the bottom of the page.

you can also contact MIA team to know if the maintainers are really MIA, in 
that case the package will be orphaned and you will be able to take it over.


the problem actually is that the package is not building fine on amd64 and i386.

"configure.ac:410: error: possibly undefined macro: LT_SYS_SYMBOL_USCORE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation."

BTW you need to add libffi-dev to build-dependencies and enable it in configure 
script.

However I failed in building it correctly.


[1]https://packages.qa.debian.org/p/polyml.html

cheers,

G.

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

Bug#732362: vtk 5.10 is coming to unstable soon (TM)

[Gianfranco Costamagna]

Hi, since vtk had to be renamed, and since I did clean it up and upload on 
experimental a loong time ago, I would like
to keep the possibility of the gcc-5 transition rebuilds to push 5.10 on 
unstable soon.

It should just be a matter of binNMUing the depending packages, so I guess this 
one won't be so painful,
now that vtk5.10 is fixed, and many packages switched already to vtk6.

Please tell me if somebody is against this move.

cheers,

G.

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

Bug#794010: Fixed in unstable and experimental

[Gianfranco Costamagna]

Hi,
since nobody took care of this issue, I took the liberty to fix this bug and 
upload directly
on unstable, due to policy allowing to put on 0 day queue packages with more 
than 7 days old RC
bugs and no intention to fix.

I did upload as NMU, even if I'm in the Debian Science team, because I would 
like to avoid
maintaining this package, and switch ASAP to vtk6.

This is unfortunately still needed to make the netcdf transition finish, and I 
guess I'll
try to move to vtk-5.10 in the near future, at least to avoid loosing all the 
work
I did for the vtk-5.10 version.




BTW In order to avoid a new transition for tcl/tk 8.5 removal, I took the 
liberty to cherry-pick the 

ubuntu 8.6 patch, specially because we are already transitioning due to the v5 
soname change.

I hope it is ok, I don't think tcl-tk 8.5 will be still there for Stretch
(and I hope also vtk won't be there)

cheers,

Gianfranco

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

Bug#794853: libvigraimpex: non DFSG file in the source package

[Gianfranco Costamagna]

Source: libvigraimpex
Version: 1.10.0+dfsg-9
Severity: Serious
Justification: non DFSG file in the source package
User: locutusofb...@debian.org
Usertags: license-problem-non-free-img-lenna


Hi libvigraimpex Maintainer(s),
your package has been found to contain a copy of a non DFSG
file, that makes your package non DFSG.

This image (called lenna.jpg, or lena.jpg with some variants)
is an image of Lena Söderberg, photographed by Dwight Hooker,
cropped from the centerfold of the November 1972 issue of Playboy magazine.

This file is to be considered distributable but non free
(at the end of this bug report you will find a link to the lintian tag,
with a more complete description of the issue and references)

Below a list of the affected files:
- src/examples/lenna.bmp

note, I did stop checking for the all files as soon as I found one
good match, so they might be not all bad references, please update
this bug if not correct.

More information about this issue can be found on the
license-problem-non-free-img-lenna lintian tag [1] and Debian bug [2]

[1] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html
[2] https://bugs.debian.org/771191

thanks,

Gianfranco

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

Bug#794858: sivp: non DFSG file in the source package

[Gianfranco Costamagna]

Source: sivp
Version: 0.5.3+svn287-2.1
Severity: Serious
Justification: non DFSG file in the source package
User: locutusofb...@debian.org
Usertags: license-problem-non-free-img-lenna

Hi sivp Maintainer(s),
your package has been found to contain a copy of a non DFSG
file, that makes your package non DFSG.

This image (called lenna.jpg, or lena.jpg with some variants)
is an image of Lena Söderberg, photographed by Dwight Hooker,
cropped from the centerfold of the November 1972 issue of Playboy magazine.

This file is to be considered distributable but non free
(at the end of this bug report you will find a link to the lintian tag,
with a more complete description of the issue and references)

Below a list of the affected files:
- images/lena.png

note, I did stop checking for the all files as soon as I found one
good match, so they might be not all bad references, please update
this bug if not correct.

More information about this issue can be found on the
license-problem-non-free-img-lenna lintian tag [1] and Debian bug [2]

[1] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html
[2] https://bugs.debian.org/771191

thanks,

Gianfranco

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

Bug#794856: opencv: non DFSG file in the source package

[Gianfranco Costamagna]

Source: opencv
Version: 2.4.9.1+dfsg-1.1
Severity: Serious
Justification: non DFSG file in the source package
User: locutusofb...@debian.org
Usertags: license-problem-non-free-img-lenna

Hi opencv Maintainer(s),
your package has been found to contain a copy of a non DFSG
file, that makes your package non DFSG.

This image (called lenna.jpg, or lena.jpg with some variants)
is an image of Lena Söderberg, photographed by Dwight Hooker,
cropped from the centerfold of the November 1972 issue of Playboy magazine.

This file is to be considered distributable but non free
(at the end of this bug report you will find a link to the lintian tag,
with a more complete description of the issue and references)

Below a list of the affected files:
- samples/c/lena.jpg
- samples/cpp/lena.jpg
- samples/cpp/tutorial_code/images/lena.png
- doc/tutorials/introduction/clojure_dev_intro/images/lena.png
- doc/tutorials/introduction/desktop_java/images/lena.png
- modules/java/android_test/res/drawable/lena.jpg
- samples/winrt/OcvImageProcessing/OcvImageProcessing/Assets/Lena.png
- samples/java/clojure/simple-sample/resources/images/lena.png

note, I did stop checking for the all files as soon as I found one
good match, so they might be not all bad references, please update
this bug if not correct.

More information about this issue can be found on the
license-problem-non-free-img-lenna lintian tag [1] and Debian bug [2]

[1] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html
[2] https://bugs.debian.org/771191

thanks,

Gianfranco

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

Bug#794861: visp: non DFSG file in the source package

[Gianfranco Costamagna]

Source: visp
Version: 2.10.0-4
Severity: Serious
Justification: non DFSG file in the source package
User: locutusofb...@debian.org
Usertags: license-problem-non-free-img-lenna

Hi visp Maintainer(s),
your package has been found to contain a copy of a non DFSG
file, that makes your package non DFSG.

This image (called lenna.jpg, or lena.jpg with some variants)
is an image of Lena Söderberg, photographed by Dwight Hooker,
cropped from the centerfold of the November 1972 issue of Playboy magazine.

This file is to be considered distributable but non free
(at the end of this bug report you will find a link to the lintian tag,
with a more complete description of the issue and references)

Below a list of the affected files:
- doc/image/img-lena-blured-default.png
- doc/image/img-lena-blured-var2.png
- doc/image/img-lena-canny.png
- doc/image/img-lena-dIxy.png
- doc/image/img-lena-gray.png
- doc/image/img-lena-pyr.png
- doc/image/img-lena-sobel.png
- doc/image/img-lena-win.jpg
- doc/image/img-lena.png
- tutorial/image/lena.bmp
- tutorial/image/lena.jpeg
- tutorial/image/lena.pgm
- tutorial/image/lena.png
- tutorial/image/lena.ppm

note, I did stop checking for the all files as soon as I found one
good match, so they might be not all bad references, please update
this bug if not correct.

More information about this issue can be found on the
license-problem-non-free-img-lenna lintian tag [1] and Debian bug [2]

[1] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html
[2] https://bugs.debian.org/771191

thanks,

Gianfranco

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

Bug#794554: Fixed upstream

[Gianfranco Costamagna]

Hi Tobias, I do not know if you are aware of this,
and there are only 4 hours left for the upload (in deferred queue).


Anyway, upstream fixed this issue there:
https://github.com/roboptim/roboptim-core/commit/ebf98e6c293113cd7729f7560deafb2ac2cea7be

cheers,

Gianfranco

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

Bug#767338: Patch

[Gianfranco Costamagna]

Hi Anton, Martin,

I'm attaching your patch/workaround to sort out the reason of the 
warning/build failure.

:)


diff -Nru vtk6-6.1.0+dfsg2/debian/tests/control 
vtk6-6.1.0+dfsg2/debian/tests/control
--- vtk6-6.1.0+dfsg2/debian/tests/control   2014-10-22 21:11:16.0 
+0200
+++ vtk6-6.1.0+dfsg2/debian/tests/control   2015-01-04 16:43:06.0 
+0100
@@ -1,2 +1,3 @@
Tests: buildBoolean buildPoint buildVTU buildDistance buildPNG buildVTP
Depends: libvtk6-dev, build-essential, cmake
+Restrictions: allow-stderr



cheers,

Gianfranco

(I opened a merge bug on launchpad 1407476, would be nice to plain sync the 
package in the future if possible)

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

Bug#767338: R: Bug#767338: Patch

[Gianfranco Costamagna]

Hi Anton,
the thanks goes to the great Martin :-)

However the warning when building is actually throwing the error, the real 
patch (if I understand correctly) should be to fix the build warning rather 
thank hiding it :-)

but I'm not the maintainer, neither the patch creator... I'm just giving my 2 
cents here

cheers,

Gianfranco


--
Il dom 4 gen 2015 19:59 CET, Anton Gladky ha scritto:

tags 767338 +pending
thanks

Hi Gianfranco,

thanks for the patch! Commited, will appear in next upload.

http://anonscm.debian.org/cgit/debian-science/packages/vtk6.git/commit/?id=99abc4562730ce323d0441f390d07ef2d4e1cc6f

Cheers

Anton


2015-01-04 19:26 GMT+01:00 Gianfranco Costamagna
costamagnagianfra...@yahoo.it:
 Hi Anton, Martin,

 I'm attaching your patch/workaround to sort out the reason of the 
 warning/build failure.

 :)


 diff -Nru vtk6-6.1.0+dfsg2/debian/tests/control 
 vtk6-6.1.0+dfsg2/debian/tests/control
 --- vtk6-6.1.0+dfsg2/debian/tests/control   2014-10-22 
 21:11:16.0 +0200
 +++ vtk6-6.1.0+dfsg2/debian/tests/control   2015-01-04 
 16:43:06.0 +0100
 @@ -1,2 +1,3 @@
 Tests: buildBoolean buildPoint buildVTU buildDistance buildPNG buildVTP
 Depends: libvtk6-dev, build-essential, cmake
 +Restrictions: allow-stderr



 cheers,

 Gianfranco

 (I opened a merge bug on launchpad 1407476, would be nice to plain sync the 
 package in the future if possible)

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

-- 
To unsubscribe, send mail to 767338-unsubscr...@bugs.debian.org.

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

Bug#757645: Rationale for the change

[Gianfranco Costamagna]

Hi Frédéric and Yuri,

First of all, thanks to you both for the bug report.

In only one month is good to see people complaining and to see the increased 
popcon :), so thanks for using the package and for the bug report.

I'll try to explain with a simple example the reason for this change:
python /usr/lib/python2.7/dist-packages/pyqtgraph/examples/__main__.py

the example code shows you the CLIExample window, when you can write and run 
easily the code, with the useful list of the examples on the left, where you 
can choose to force PyQt, or PySide as rendering engines.

Since also my first sponsor got some troubles in running them (if you choose 
pyside without having it installed you will likely have a import error and in 
some cases a segfault, IIRC), and since I'm a person that _really_ likes to 
install and run things, rather than install, 
run/fail/run/fail/check_faults/change_library, I choose to go for having them 
both required.

Unfortunately I understand this change is good for people approaching for the 
first time to the package, while for code already in place is really an 
overread.

For this reason, since I really want to fix this issue, I ask to you both how 
to proceed.
What comes in my mind is:
A) provide a python-pyqtgraph-examples with them both, and leave 
python-pyqtgraph have the choosable dependency qt|side (and maybe a recommend 
or suggest for the examples package), this will go in new, and I can catch the 
ball for adding a -doc package (upstream asked me to add it, I just need to 
tweak a little bit the package, the change should be trivial).

B) revert this change, having a possible not fully working example suite (bad 
idea for people like me, but I'm just a clueless maintainer with no strong 
opinion on this)


C) something that I didn't think about, but maybe possible (usually a DD comes 
here with a great and simple solution I didn't think about)



In my opinion A is the best solution (didn't come in my mind when I firstly 
thought about this problem), but I really would like to hear some feedbacks ;)


BTW I'm a quite old DM, but I'm not in the dm.txt list for this package, so 
would be nice to have a sponsor for the change ;).

Gianfranco

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

Bug#757645: Rationale for the change

[Gianfranco Costamagna]

Hi Yuri



 Il Lunedì 18 Agosto 2014 11:12, Yuri D'Elia wav...@thregr.org ha scritto:
  On 08/18/2014 08:22 AM, Gianfranco Costamagna wrote:
  Since also my first sponsor got some troubles in running them (if you
  choose pyside without having it installed you will likely have a
  import error and in some cases a segfault, IIRC), and since I'm a
  person that _really_ likes to install and run things, rather than
  install, run/fail/run/fail/check_faults/change_library, I choose to
  go for having them both required.
 
 IMHO it's perfectly reasonable that if you can select the binding
 engine, and the selected one is missing, the example fails.
 
 The idea of the example is not to let people swap engines at runtime,
 but to make the example run at all.
 
 You could detect at runtime which binding is available and gray out
 the selection if you really wanted to. This would fix the issue
 permanently.

this needs code, and would be nice to have a patch, or to report upstream :)

 
  In my opinion A is the best solution (didn't come in my mind when I
  firstly thought about this problem), but I really would like to hear
  some feedbacks ;)
 
 I would go for a
 
 Depends: pyside|pyqt
 
 recommending pyside as the favorable option, since pyqt with python 2.7
 has still the old SIP api enabled by default (and changing it is a
 PITA). I would recommend newcomers to use pyside if possible, even just
 for the API. Most developers already have a clear idea of which binding
 to use.
 

changed in git :)

 I would agree with upstream here to ship with the documentation. I'm
 working often offline, and I've reported many bug reports trying to ship
 docs along with the packages and to always Suggest: the -doc package if
 it exists.
 
 I personally wouldn't put examples into a different package, but ship
 them with the documentation. Unless the examples come with extra
 unreasonable dependencies. In this case, the -doc can recommend *both*
 pyqt and pyside (that is, with 2 recommends), without affecting the main
 package and without requiring an extra one.
 

but my approach will avoid the extra documentation if not needed, someone 
talked about small systems ;)

I mean, python is used in both development and deploy systems, so maybe a split 
is also good

 I feel that a reccomends would be too strong anyway, as one of the goals
 of pyqtgraph is really to be interchangeable between the two. As far as
 an example is concerned, if it runs with the installed engine, what's
 the point really?

the point is that people like me wants to have stuff working without reading 
the READMEs, trying to search for the right dependencies, look at 
recommends/depends/suggests fields...

my solution should be easily apt-get install friendly, with a nice difference 
between deploy and devel, and without requiring any kind of reading of the 
README.Debian documentation.

anyway I don't think I would like to add some code for detecting the available 
engine on the system (just an import with an exception catch?) for the *only* 
benefit of debian distros.

Upstream is so responsive about patches, so if you want to code and send 
upstream I'll be happy to cherry-pick and go for your solution :D

cheers,

Gianfranco

 
 
  BTW I'm a quite old DM, but I'm not in the dm.txt list for this
  package, so would be nice to have a sponsor for the change ;).
 
 Cannot help you here, I also need sponsors ;)
 

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

Bug#757645: Rationale for the change

[Gianfranco Costamagna]

 Il Lunedì 18 Agosto 2014 11:54, Yuri D'Elia wav...@thregr.org ha scritto:

  On 08/18/2014 11:32 AM, Gianfranco Costamagna wrote:
  You could detect at runtime which binding is available and gray 
  out the selection if you really wanted to. This would fix the 
  issue permanently.
 
  this needs code, and would be nice to have a patch, or to report 
  upstream :)
 
 Yes, this is why it's probably like this anyway. Not worth the effort.
 
  but my approach will avoid the extra documentation if not needed, 
  someone talked about small systems ;)
 
 No problem with that. It's always good to have more granularity.
 
 Though generally speaking, you'd need examples for doing development.
 
 
  I feel that a reccomends would be too strong anyway, as one of the 
  goals of pyqtgraph is really to be interchangeable between the
  two. As far as an example is concerned, if it runs with the
  installed engine, what's the point really?
 
  the point is that people like me wants to have stuff working without 
  reading the READMEs, trying to search for the right dependencies, 
  look at recommends/depends/suggests fields...
 
 I think this discussion is a bit overkill.
 
 I mean, you need pyqtgraph for development.
 pyqtgraph needs at least *one* qt binding to work at all.
 As a developer, I don't need strict dependencies to understand that.
 In fact, I'm forced to use pyqt in some projects, and pyside in others.
 
 When pyqtgraph is pulled as a dependency, you need to make sure to pull
 the least amount of dependencies for user's sake. This is why an OR
 dependency is the way to go. I would revert dependencies just to fix this.
 
 I'm being pragmatic here. I'd expect developers to know what pyqt or
 pyside mean. Maybe they don't know which one to choose, but this doesn't
 make an intrinsic difference.

I completely agree, this is what I committed on git so far
http://anonscm.debian.org/cgit/debian-science/packages/python-pyqtgraph.git

the fixed package is already on mentors
https://mentors.debian.net/package/python-pyqtgraph

and if somebody will ever fix the examples I'll be really happy to make them 
come back to the original place :D
(since because of the -doc package this will require a NEW step)

Now I'm trying to get everything work with python3
cheers,

G.

 

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

Should the link be updated?

[Gianfranco Costamagna]

Hi debian release and vtk6 maintainers,

Following up from an irc conversation on ftp and release channel I think the 
Ben file should be updated to

is_good = .depends ~ libvtk6.1;


 thanks,


Gianfranco

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

Bug#747108: I: Fixed in mentors, can anybody please sponsor?

[Gianfranco Costamagna]

Hi Anton, thanks again for the upload, but are you sure my patch alone is 
enough?
Because I started from Jordi's modifications, that were into the 
allpatches.patch patch
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=42;bug=731823

I don't know if it works without them, did you test it?
also the tcl patch and the missing ${shlibs:Depends} should be fixed in my 
opinion

Gianfranco


Il Sabato 10 Maggio 2014 10:24, Anton Gladky gl...@debian.org ha scritto:

Hi Gianfranco,

thanks for the fix! I have applied your patch and made an upload.

http://anonscm.debian.org/gitweb/?p=collab-maint/vtk.git;a=commitdiff;h=5e721d4f2721b41c528ccd5960e6196ff4a77318



Anton



2014-05-10 0:09 GMT+02:00 Gianfranco Costamagna 
costamagnagianfra...@yahoo.it:
 Hi Anton,

 Thanks to you for the upload!

 Since you are in the debian science team, can you please also upload vtk?
 http://bugs.debian.org/731823

 and also, do you think the vtk tcl fixes should be cherry picked to vtk6
 too?

 cheers,

 Gianfranco

 Il Venerdì 9 Maggio 2014 23:36, Anton Gladky gl...@debian.org ha scritto:

 Hi Gianfranco,

 thanks for the help! I integrated your fix into the next upload.

 Regards

 Anton


 2014-05-09 19:03 GMT+02:00 Gianfranco Costamagna
 costamagnagianfra...@yahoo.it:

 Hi *
 Like for the other bug 731823 I did the same trick for this RC bug.

 However I'm not sure if the TCL patches from Jordi should be applied here
 too or not.

 the trick was this patch
 --- vtk6-6.0.0.orig/Wrapping/Java/CMakeLists.txt
 +++ vtk6-6.0.0/Wrapping/Java/CMakeLists.txt
 @@ -237,7 +237,7 @@ add_custom_command(
    OUTPUT ${VTK_BINARY_DIR}/java/javac_stamp.txt
    DEPENDS ${VTK_JAVA_SOURCE_FILES}
    COMMAND ${JAVA_COMPILE} ${JAVAC_OPTIONS}
 -    -source 1.5 -classpath
 ${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
 ${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
 +    -source 1.5 -target 1.5 -classpath
 ${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
 ${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
      ${VTK_BINARY_DIR}/java/vtk/*.java
 ${VTK_BINARY_DIR}/java/vtk/rendering/*.java
 ${VTK_BINARY_DIR}/java/vtk/rendering/awt/*.java ${SWT_FILES}
    COMMAND ${CMAKE_COMMAND} -E touch
 ${VTK_BINARY_DIR}/java/javac_stamp.txt
    COMMENT Compiling Java Classes



 waiting for a sponsor on mentors;)



 cheers,
 Gianfranco


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

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






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

Bug#731823: Not fixed.

[Gianfranco Costamagna]

Hi all, I grabbed the deb from debian incoming and this bug is NOT fixed.


Can you please upload again with the real fix from mentors?



There is also a build failure on kfreebsd-amd64, don't know if related to this 
fix
https://buildd.debian.org/status/fetch.php?pkg=vtkarch=kfreebsd-amd64ver=5.8.0-16stamp=1399720557
cheers,

Gianfranco

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

Bug#747108: I: Fixed in mentors, can anybody please sponsor?

[Gianfranco Costamagna]

Hi *

Like for the other bug 731823 I did the same trick for this RC bug.


However I'm not sure if the TCL patches from Jordi should be applied here too 
or not.


the trick was this patch
--- vtk6-6.0.0.orig/Wrapping/Java/CMakeLists.txt
+++ vtk6-6.0.0/Wrapping/Java/CMakeLists.txt
@@ -237,7 +237,7 @@
 add_custom_command(
   OUTPUT ${VTK_BINARY_DIR}/java/javac_stamp.txt
   DEPENDS ${VTK_JAVA_SOURCE_FILES}
   COMMAND ${JAVA_COMPILE} ${JAVAC_OPTIONS}
-    -source 1.5 -classpath 
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath 
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
+    -source 1.5 -target 1.5 -classpath 
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath 
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
 ${VTK_BINARY_DIR}/java/vtk/*.java
 ${VTK_BINARY_DIR}/java/vtk/rendering/*.java 
${VTK_BINARY_DIR}/java/vtk/rendering/awt/*.java ${SWT_FILES}
   COMMAND ${CMAKE_COMMAND} -E touch ${VTK_BINARY_DIR}/java/javac_stamp.txt
   COMMENT Compiling Java Classes




waiting for a sponsor on mentors;)




cheers,
Gianfranco-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#747108: I: Fixed in mentors, can anybody please sponsor?

[Gianfranco Costamagna]

Hi Anton,

Thanks to you for the upload!

Since you are in the debian science team, can you please also upload vtk?
http://bugs.debian.org/731823


and also, do you think the vtk tcl fixes should be cherry picked to vtk6 too?

cheers,


Gianfranco


Il Venerdì 9 Maggio 2014 23:36, Anton Gladky gl...@debian.org ha scritto:
 
Hi Gianfranco,

thanks for the help! I integrated your fix into the next upload.

Regards

Anton


2014-05-09 19:03 GMT+02:00 Gianfranco Costamagna
costamagnagianfra...@yahoo.it:

 Hi *
 Like for the other bug 731823 I did the same trick for this RC bug.

 However I'm not sure if the TCL patches from Jordi should be applied here
 too or not.

 the trick was this patch
 --- vtk6-6.0.0.orig/Wrapping/Java/CMakeLists.txt
 +++ vtk6-6.0.0/Wrapping/Java/CMakeLists.txt
 @@ -237,7 +237,7 @@ add_custom_command(
    OUTPUT ${VTK_BINARY_DIR}/java/javac_stamp.txt
    DEPENDS ${VTK_JAVA_SOURCE_FILES}
    COMMAND ${JAVA_COMPILE} ${JAVAC_OPTIONS}
 -    -source 1.5 -classpath
 ${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
 ${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
 +    -source 1.5 -target 1.5 -classpath
 ${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
 ${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
      ${VTK_BINARY_DIR}/java/vtk/*.java
 ${VTK_BINARY_DIR}/java/vtk/rendering/*.java
 ${VTK_BINARY_DIR}/java/vtk/rendering/awt/*.java ${SWT_FILES}
    COMMAND ${CMAKE_COMMAND} -E touch ${VTK_BINARY_DIR}/java/javac_stamp.txt
    COMMENT Compiling Java Classes



 waiting for a sponsor on mentors;)



 cheers,
 Gianfranco

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



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