Bug#865236: Please update dependencies from latex-xcolor to tl-latex-recommended

2017-06-20 Thread Pablo Oliveira 
Dear Sylvestre,

I have fixed the bug in ask's package git. Could you please upload the
new version ?

Thanks

Pablo


On 06/20/2017 07:05 AM, norb...@preining.info wrote:
> Source: ask
> Version: 1.1.1-1
> Severity: serious
> Justification: FTBFS
> X-Debbugs-CC: debian-tex-ma...@lists.debian.org
> 
> Dear maintainer,
> 
> latex-xcolor has been a dummy transitional package now since 2 releases
> (since oldstable), and has been dropped in current unstable.
> 
> Please update your dependencies to texlive-latex-recommended.
> 
> Thanks
> 
> Norbert
>

Bug#832622: clang-3.9: Uninstallable in unstable

2016-07-29 Thread Pablo Oliveira 
Hi,


I believe the problem may have been fixed by Brad King in the version
1:3.9~svn275918-1~exp2. Relevant part of the changelog:

llvm-toolchain-3.9 (1:3.9~svn275918-1~exp2) experimental; urgency=medium
  ...
  * LLVMConfig.cmake is now installed to /lib/cmake/llvm instead
of /share/llvm/cmake
Thanks to Brad King of the fix
  ...

As soon as this version hits my mirror, I will test and confirm. If
anybody has already the packages and can test it would be great !

Regards,

Pablo

On 07/29/2016 06:31 PM, Sergey Zinov wrote:
> I have encountered this bug too. I found following workaround so far:
> 
> First removing llvm-3.9-dev package:
> apt remove llvm-3.9-dev
> Then installing them together:
> apt install llvm-3.9-dev clang-3.9
> 
> 
> 
> ___
> Pkg-llvm-team mailing list
> pkg-llvm-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team
>

Bug#832825: ask: FTBFS: Tests failures

2016-07-29 Thread Pablo Oliveira 
Dear Lucas,

Thanks for this bug report which I can reproduce. The problem seems to
be due to a missing dependency in the package r-cran-tgp. It expects
r-cran-maptree but it is only declared as a build dependency.

I'm filing a bug against r-cran-tgp.

Thanks,

Pablo

On 07/29/2016 09:47 AM, Lucas Nussbaum wrote:
> Source: ask
> Version: 1.0.1-2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160728 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>>
>> -- created: ---
>>   default.log  (1641 bytes)
>>   outdir
>>   labelled.data  (788 bytes)
>>   labelled0.data  (788 bytes)
>>   requested0.data  (343 bytes)
>>
>> - >> end captured stdout << --
>>
>> --
>> Ran 29 tests in 34.744s
>>
>> FAILED (failures=1)
>> make[1]: *** [test] Error 1
>> Makefile:21: recipe for target 'test' failed
> 
> The full build log is available from:
>http://people.debian.org/~lucas/logs/2016/07/28/ask_1.0.1-2_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>

Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1

2016-05-07 Thread Pablo Oliveira 
On 05/07/2016 04:05 PM, Pablo Oliveira wrote:
> On Sun, 24 Apr 2016 16:40:39 +0200 Sylvestre Ledru
> <sylves...@debian.org> wrote:
>> [...]
>> yes, this is fine. A patch would be appreciated as I don't have the
>> bandwidth for the next two weeks.
> 
> 
> Attached is a tentative patch fixing the symlinks and adding the missing
> dependencies. I'm testing a full clean rebuild with it and will report back.

The previously attached patch fixes the import issue on a clean build of
llvm-toolchain-3.8.

Regards,

Pablo

Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1

2016-05-07 Thread Pablo Oliveira 
Hi,

On Sun, 24 Apr 2016 16:40:39 +0200 Sylvestre Ledru
 wrote:
> Le 24/04/2016 à 10:08, Graham Inggs a écrit :
> > Confirming.  Python-lldb-3.8 has missing dependencies and some
broken symlinks.
> >
> > After installing python-lldb-3.8, I needed to take the steps below (as
> > root) before I could 'import lldb' successfully.
> >
> > apt-get install lldb-3.8 liblldb-3.8 liblldb-3.8-dev
> >
> > cd /usr/lib/llvm-3.8/lib/python2.7/site-packages/lldb
> > rm libLLVM-3.8.0.so.1
> > ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1
libLLVM-3.8.0.so.1
> > rm libLLVM-3.8.so.1
> > ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1
libLLVM-3.8.so.1
> > rm _lldb.so
> > ln -s ../../../../../x86_64-linux-gnu/liblldb-3.8.so _lldb.so
/pkg-llvm-team
>
> yes, this is fine. A patch would be appreciated as I don't have the
> bandwidth for the next two weeks.


Attached is a tentative patch fixing the symlinks and adding the missing
dependencies. I'm testing a full clean rebuild with it and will report back.

This patch does not fix the problem in #813798 (lldb testsuite failing
due to invalid _lldb.so symlink), which happens because lldb's
finishSwigPythonLLDB.py does not know about the SOEXT we are adding. I'm
working on that.

Regards,

Pablo
Index: control
===
--- control (revision 1915)
+++ control (working copy)
@@ -395,7 +395,7 @@
 Package: python-lldb-3.8
 Section: python
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, python
+Depends: ${shlibs:Depends}, ${misc:Depends}, liblldb-3.8, lldb-3.8, python
 Conflicts: python-lldb-3.4, python-lldb-3.5, python-lldb-3.6, python-lldb-3.7
 Pre-Depends: ${misc:Pre-Depends}
 Description: Next generation, high-performance debugger, python lib
Index: liblldb-X.Y.links.in
===
--- liblldb-X.Y.links.in(revision 1915)
+++ liblldb-X.Y.links.in(working copy)
@@ -1,4 +1,3 @@
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so
-usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so 
usr/lib/python2.7/dist-packages/lldb-@LLVM_VERSION@/_lldb.so
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb.so.1
 
Index: python-lldb-X.Y.links.in
===
--- python-lldb-X.Y.links.in(revision 1915)
+++ python-lldb-X.Y.links.in(working copy)
@@ -1,5 +1,6 @@
-usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1  
usr/lib/python2.7/dist-packages/lldb/libLLVM-@LLVM_VERSION_FULL@.so.1
-usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1  
usr/lib/python2.7/dist-packages/lldb/libLLVM-@LLVM_VERSION@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1 
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/libLLVM-@LLVM_VERSION_FULL@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1 
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/libLLVM-@LLVM_VERSION@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1  
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/_lldb.so
 usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/ 
usr/lib/python2.7/dist-packages/lldb
 
 
Index: rules
===
--- rules   (revision 1915)
+++ rules   (working copy)
@@ -412,7 +412,7 @@
sed -i 's|LLVM_CMAKE_DIR 
"/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake"|LLVM_CMAKE_DIR 
"/usr/share/llvm-$(LLVM_VERSION)/cmake"|' 
$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMConfig.cmake
 
 # Managed in lldb-X.Y.links.in
-   rm -f 
$(CURDIR)/$(TARGET_BUILD)/$(BUILD_DIR)/lib/python*/site-packages/lldb/_lldb.so
+   rm -f 
$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/python*/site-packages/lldb/_lldb.so
 
 # Manage the polly files. Sometimes, we build them. Sometimes not.
if test "$(POLLY_ENABLE)" = yes; then \

Bug#820866: r-cran-tgp: FTBFS: cmath:171:3: error: template with C linkage

2016-05-03 Thread Pablo Oliveira 
On Mon, 2 May 2016 16:52:31 +0200 Pablo Oliveira <pa...@sifflez.org> wrote:
> Dear both,
> 
> On Wed, 20 Apr 2016 03:44:41 +0200 Andreas Beckmann <a...@debian.org> wrote:
> > Hi Chris,
> > [...]
> > 
> > I cannot reproduce this in my sid pbuilder setup. Could you check again?
> > (I think gcc got updated since you filed this bug.)
> 
> I am able to reproduce the problem using cowbuilder unstable/amd64.
> 
> I will try to see if the new upstream version (2.4-14) fixes the problem
> and update the package.

The new upstream version of tgp (2.4-14) fixes the issue on unstable.
(I have not tested with the previous 3.2.5-1 r-base-dev, nor with 3.3.0,
so I have no comments regarding #823313)

I have updated the tgp package at

  <https://anonscm.debian.org/git/debian-science/packages/r-cran-tgp.git/>

The new upstream version adds a new dependency (r-cran-maptree) which I
have packaged here (ITP #823320):

 <https://anonscm.debian.org/git/debian-science/packages/r-cran-maptree.git/>

Could somebody please upload these packages ?

Thanks,

Pablo

Bug#820866: r-cran-tgp: FTBFS: cmath:171:3: error: template with C linkage

2016-05-02 Thread Pablo Oliveira 
Dear both,

On Wed, 20 Apr 2016 03:44:41 +0200 Andreas Beckmann  wrote:
> Hi Chris,
> [...]
> 
> I cannot reproduce this in my sid pbuilder setup. Could you check again?
> (I think gcc got updated since you filed this bug.)

I am able to reproduce the problem using cowbuilder unstable/amd64.

I will try to see if the new upstream version (2.4-14) fixes the problem
and update the package.

Pablo
make[1]: Entering directory '/build/r-cran-tgp-2.4-9/src'
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -DRPRINT -DNDEBUG  -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c all_draws.c -o all_draws.o
g++ -I/usr/share/R/include -DNDEBUG -DRPRINT -DNDEBUG  -fpic  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c base.cc -o base.o
In file included from /usr/share/R/include/R.h:40:0,
 from rhelp.h:20,
 from base.h:30,
 from base.cc:25:
/usr/include/c++/5/cstdlib: In function 'long long int std::abs(long long int)':
/usr/include/c++/5/cstdlib:174:20: error: conflicting declaration of C function 'long long int std::abs(long long int)'
   abs(long long __x) { return __builtin_llabs (__x); }
^
/usr/include/c++/5/cstdlib:166:3: note: previous declaration 'long int std::abs(long int)'
   abs(long __i) { return __builtin_labs(__i); }
   ^
/usr/include/c++/5/cstdlib: In function '__int128 std::abs(__int128)':
/usr/include/c++/5/cstdlib:179:33: error: conflicting declaration of C function '__int128 std::abs(__int128)'
   abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
 ^
/usr/include/c++/5/cstdlib:174:3: note: previous declaration 'long long int std::abs(long long int)'
   abs(long long __x) { return __builtin_llabs (__x); }
   ^
/usr/include/c++/5/cstdlib:179:33: error: conflicting declaration of C function '__int128 std::abs(__int128)'
   abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
 ^
/usr/include/c++/5/cstdlib:166:3: note: previous declaration 'long int std::abs(long int)'
   abs(long __i) { return __builtin_labs(__i); }
   ^
In file included from /usr/include/c++/5/cmath:42:0,
 from /usr/share/R/include/R.h:43,
 from rhelp.h:20,
 from base.h:30,
 from base.cc:25:
/usr/include/c++/5/bits/cpp_type_traits.h: At global scope:
/usr/include/c++/5/bits/cpp_type_traits.h:72:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:85:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:89:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:95:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:103:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:110:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:118:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:125:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:135:3: error: template with C linkage
   template
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:146:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:153:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:160:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:167:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:175:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:199:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:206:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:213:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:220:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:227:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:234:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:241:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:248:3: error: template specialization with C linkage
   template<>
   ^
/usr/include/c++/5/bits/cpp_type_traits.h:270:1: error: template

Bug#771132: morse-simulator is not usable with the current version of blender

2014-12-01 Thread Pablo Oliveira 

Hi Séverin,

Séverin Lemaignan severin.lemaig...@epfl.ch wrote:
 For sanity check, can you post the output of `morse --version`?

Sure:

morse 1.2.1

 Thanks for your report. MORSE 1.2.1 is indeed expected to support Blender 
 2.72.

From my tests, MORSE 1.2.1 does not work out of the box with Blender 2.72. I
relaxed the version check at morse:48 and ran into another problem. Apparently,
Blender 2.72 has substituded the link_append method by two separate link and 
append
methods 
(http://blender.stackexchange.com/questions/17876/import-object-without-bpy-ops-wm-link-append).
To make morse work on my system I had to patch line 63 of
/usr/lib/python3/dist-packages/morse/builder/bpymorse.py with link_append = 
bpy.ops.wm.link

Thanks,

Pablo Oliveira


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

Bug#771132: morse-simulator is not usable with the current version of blender

2014-11-26 Thread Pablo Oliveira 
Package: morse-simulator
Version: 1.2.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Bug #751901 that was fixed in 1.2-3 seems to have reappeard in 1.2.1-1.

Most of morse commands (including morse check) fail with the following message:

* Checking version of /usr/bin/blender... Found v.2.72.0

* Checking version of /usr/bin/blender... Found v.2.72.0

* Could not find a correct Blender executable, neither in the path or in MORSE
prefix. Blender = 2.62 and  2.72 is required to run MORSE.
You can alternatively set the $MORSE_BLENDER environment variable to point to
a specific Blender executable

* Could not find Blender executable

* Your environment is not correctly setup to run MORSE!

Thanks,

Pablo

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-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

Versions of packages morse-simulator depends on:
ii  blender  2.72.b+dfsg0-1
ii  morse-simulator-data 1.2.1-1
ii  python3  3.4.2-1
ii  python3-morse-simulator  1.2.1-1
pn  python3:any  none

Versions of packages morse-simulator recommends:
ii  morse-simulator-doc  1.2.1-1

morse-simulator suggests no packages.

-- no debconf information


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