Bug#645881: critical update 29 available

[Sylvestre Ledru]

CC debian release & security

Le mercredi 19 octobre 2011 à 12:21 +0200, Thijs Kinkhorst a écrit :
> Upstream has released Java SE 6 update 29 yesterday:
> http://www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html
> with security fixes.

Well, that especially means that it is now time to consider the removal
of sun-java6 from Debian.

We, the distros, are no longer allowed by Oracle to redistribute this
version [1] [2].
The OpenJDK (6 or 7) is now the way to go.

About stable, I don't know what the security team would recommend
here ?!

Thanks,
Sylvestre
[1]
http://sylvestre.ledru.info/blog/sylvestre/2011/08/26/sun_java6_packages_removed_from_debian_u
[2] http://jdk-distros.java.net/
The DLJ has finally been retired, and so has been this project.






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

Bug#635295: Please rename the package to php5-apc

[Sylvestre Ledru]

Hi

Any progress on this subject? The lack of consistency over the archive
is boring...

Sylvestre





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

Bug#666539: clang: Fails when trying to include chrono from C++11

[Sylvestre Ledru]

Hello Mario,

> 
> x4:/tmp% clang++ -std=c++0x -o clang-chrono clang-chrono.cxx
> In file included from clang-chrono.cxx:1:
> /usr/include/c++/4.6/chrono:666:7: error: static_assert expression is not an 
> integral constant expression
>   static_assert(system_clock::duration::min()
>   ^ ~
> 1 error generated.
> zsh: exit 1 clang++ -std=c++0x -o clang-chrono clang-chrono.cxx
I haven't checked if it is fixed in the current trunk or not but it
looks like it is a known issue:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015641.html


Sylvestre




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

Bug#666110: [Pkg-openmpi-maintainers] Bug#666110: pvbatch / openmpi refuses under chroot

[Sylvestre Ledru]

On 02/04/2012 20:46, Anton Gladky wrote:

Sylvestre,  1.4.3-3 fails to build with that patch?

Anton




On my systems, it fails to build (but not because of this patch)

Sylvestre




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

Bug#666996: RM: libjogl2-java [mips] -- ROM; Allow the transition of the rc5

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

Hello,
Could you remove libjogl2-java from mips to allow the transition of the rc5 ?

Thanks,
Sylvestre

Note: this was a request for a partial removal from testing, converted in one 
for unstable



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

Bug#667602: Problem is associated with upgrade of libjrosetta-java to version 1.0.4-3

[Sylvestre Ledru]

With:
libjrosetta-java 1.0.4-3
scilab 5.3.3-8   

it works for me ?!


Le vendredi 06 avril 2012 à 00:16 +0200, Wojciech Zabolotny a écrit :
> I have just tested that on another machina scilab was working.
> Then I performed update of the system which upgraded libjrosetta-java
> to version 1.0.4-3
> After that update scilab was not warking any more as described in the
> previous report.
> -- 
> Regards,
> WZab
> 
> 
> 

-- 
-----
Sylvestre Ledru
Operation manager
Community manager
-
Scilab Enterprises
http://www.scilab-enterprises.com/
http://www.scilab.org/
-




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

Bug#799145: openmprtl: Multiarch support

[Sylvestre Ledru]

Source: openmprtl
Severity: normal

The openmp library should be multiarch ready.
This is not the case for now.

Sylvestre


-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#790735: openmprtl: add MIPS support

[Sylvestre Ledru]

Le 01/07/2015 11:55, Dejan Latinovic a écrit :

> I had created patch that contains support for MIPS:
> openmprtl_add-mips-support.patch
Thanks for the patch. It is pending in NEW.
Do you want me to forward your work upstream?

Cheers,
S

Bug#790686: (no subject)

[Sylvestre Ledru]

affect 790686 clang-3.6
thanks

This is fixed version 3.7

3.5 is going to die soon, I will fix 3.6.

Sylvestre

Bug#799908: /usr/lib/llvm-3.6/bin/clang: A templated constexpr function decorated with 'noexcept()' crashes the compiler (c++1z flag is used)

[Sylvestre Ledru]

severity 799908 normal
thanks

Le 24/09/2015 06:27, Abhishek Sudhakaran a écrit :
> Package: clang-3.6
> Version: 1:3.6-2ubuntu1~trusty1
?? why are you reporting this bug on the debian bts ?
> Severity: important
> File: /usr/lib/llvm-3.6/bin/clang
>
> Dear Maintainer,
>
>
>* What led up to the situation?
>   templated constexpr function decorated with 'noexcept()' crashes the 
> compiler (c++1z flag is used)
>
Could you provide a testcase?
Otherwise, I will have to close this bug.
Thanks
S

Bug#795499: patch

[Sylvestre Ledru]

Hello,

Le 14/08/2015 20:35, Michael Vogt a écrit :
> Hi,
>
> here the debian/* debdiff. I'm not sure about the version number, it
> appears that upstream has changed the schema.
The old versioning is still proposed here:
https://github.com/include-what-you-use/include-what-you-use/releases

Thanks for your patch. Next time, please write if from the current
version (3.5) ;)

Sylvestre

Bug#796211: clang-3.8: -fsanitize doesn't work due to missing ubsan libraries (they were in libclang-common-3.x-dev)

[Sylvestre Ledru]

Le 20/08/2015 12:40, Vincent Lefevre a écrit :
> Package: clang-3.8
> Version: 1:3.8~svn245286-1
> Severity: important
>
> $ clang-3.8 -fsanitize=undefined min.c
> /usr/bin/ld.bfd.real: cannot find 
> /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/lib/linux/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file or directory
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> This is the same problem as with clang-3.7; see:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779785
>
Yep, this is because they are now generated only with the cmake build
infra and I am still using the autotools one...

Sylvestre

Bug#842642: clang-3.9: memory sanitizer segfaults immediately

[Sylvestre Ledru]

I could apply upstream-msan-prevent-initialization-failure.diff  to 3.8 
but not the two others, could you share yours?

Thanks
S

Le 11/11/2016 à 09:52, Norbert Lange a écrit :

The same 2 patches also apply to toolchain 3.8.1-15 (with some
offsets), but I haven`t testing building it

2016-11-11 1:25 GMT+01:00 Norbert Lange :

BTW. make check-sanitizer would have likely found this issue, might
want to enable it?
I believe it knows which sanitizers should work

2016-11-11 0:46 GMT+01:00 Norbert Lange :

Tags: patch


Hi,

I got it working, seems that from the 3 related patched, one is already applied.
The attached archive is the 3 patches and a edited "series" file,
it should be painless for you to integrate it into the debian/patches
directory for 3.9

I did not try with 3.8 yet (possibly more difficult), building llvm
takes quite a while.

Kind Regards,
Norbert

2016-11-09 11:04 GMT+01:00 Norbert Lange :

Hi,

researched a bit further and the same compiled programm will run fine
on debian jessie.
I tracked it down to being caused by a newer glibc version [1][2],
apparently during loading of shared libs, glibc can now allocate
memory which messes up sanitzers (mostly in more subtile ways than the
memory sanitizer).

The result is, that if stretch will ship with the current glibc, clang
and gcc (I dont think its patched there either), then the sanitizers
won`t be usable.
1) revert the fix in glibc. Would have the advantage that "sanitized"
binaries compiled from current and older clang/gcc versions will work
2) adopt the fixed from upstream [3][4] (possibly more) into clang
(and possibly gcc).
or maybe both?

Kind Regards,
Norbert

PS. shouldn`t the testsuite catch these bugs?

[1] 
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
[2] https://llvm.org/bugs/show_bug.cgi?id=27310
[3] 
https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
[4] 
https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67

2016-10-31 21:43 GMT+01:00 Norbert Lange :

On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru  wrote:

Le 31/10/2016 à 00:39, Norbert Lange a écrit :

Package: clang-3.9
Version: 1:3.9-2
Severity: normal

Dear Maintainer,

The memory sanitizer is unusable as it segfaults during initialization.
To reproduce:
echo 'int main() { return 0; }' >/tmp/test.c
clang -fsanitize=memory -o test test.c

can you try with clang-3.9 instead?

Same thing, output:

$ clang-3.9 -fsanitize=memory -o test test.c -v
clang version 3.9.0-2 (tags/RELEASE_390/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
  "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name test.c -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem
/usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
-fmessage-length 135 -fsanitize=memory
-fsanitize-blacklist=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/msan_blacklist.txt
-fno-assume-sane-operator-new -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-2d4d2c.o -x
c test.c
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target
x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/include
  /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
  /us

Bug#842642: clang-3.9: memory sanitizer segfaults immediately

[Sylvestre Ledru]

Yeah, my bad. Why did you included the third patch btw?

thanks again


Le 11/11/2016 à 17:02, Norbert Lange a écrit :

Hi, you messed up the order, look in the series file from the attachment.
You only need those two patches (in this order), third is already
included in 3.8.1:

upstream-msan-prevent-initialization-failure.diff
upstream-asan-msan-fix-reallocation-logic.diff

if you want you can refresh them with quilt, but they apply cleanly
for me (with some other linenumbers)

2016-11-11 16:23 GMT+01:00 Sylvestre Ledru :

I could apply upstream-msan-prevent-initialization-failure.diff  to 3.8 but
not the two others, could you share yours?
Thanks
S


Le 11/11/2016 à 09:52, Norbert Lange a écrit :

The same 2 patches also apply to toolchain 3.8.1-15 (with some
offsets), but I haven`t testing building it

2016-11-11 1:25 GMT+01:00 Norbert Lange :

BTW. make check-sanitizer would have likely found this issue, might
want to enable it?
I believe it knows which sanitizers should work

2016-11-11 0:46 GMT+01:00 Norbert Lange :

Tags: patch


Hi,

I got it working, seems that from the 3 related patched, one is already
applied.
The attached archive is the 3 patches and a edited "series" file,
it should be painless for you to integrate it into the debian/patches
directory for 3.9

I did not try with 3.8 yet (possibly more difficult), building llvm
takes quite a while.

Kind Regards,
Norbert

2016-11-09 11:04 GMT+01:00 Norbert Lange :

Hi,

researched a bit further and the same compiled programm will run fine
on debian jessie.
I tracked it down to being caused by a newer glibc version [1][2],
apparently during loading of shared libs, glibc can now allocate
memory which messes up sanitzers (mostly in more subtile ways than the
memory sanitizer).

The result is, that if stretch will ship with the current glibc, clang
and gcc (I dont think its patched there either), then the sanitizers
won`t be usable.
1) revert the fix in glibc. Would have the advantage that "sanitized"
binaries compiled from current and older clang/gcc versions will work
2) adopt the fixed from upstream [3][4] (possibly more) into clang
(and possibly gcc).
or maybe both?

Kind Regards,
Norbert

PS. shouldn`t the testsuite catch these bugs?

[1]
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
[2] https://llvm.org/bugs/show_bug.cgi?id=27310
[3]
https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
[4]
https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67

2016-10-31 21:43 GMT+01:00 Norbert Lange :

On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru
 wrote:

Le 31/10/2016 à 00:39, Norbert Lange a écrit :

Package: clang-3.9
Version: 1:3.9-2
Severity: normal

Dear Maintainer,

The memory sanitizer is unusable as it segfaults during
initialization.
To reproduce:
echo 'int main() { return 0; }' >/tmp/test.c
clang -fsanitize=memory -o test test.c

can you try with clang-3.9 instead?

Same thing, output:

$ clang-3.9 -fsanitize=memory -o test test.c -v
clang version 3.9.0-2 (tags/RELEASE_390/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
Found candidate GCC installation:
/usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
   "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name test.c -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem
/usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
-fmessage-length 

Bug#766316: subdownloader: Fails to download substitles when having an accent in the path "é"

[Sylvestre Ledru]

Hello

Because I am still facing this issue and this is causing this tool to be 
useless, I uploaded as NMU with a 7 days delay.


Sylvestre
Le 25/07/2016 à 14:14, Sylvestre Ledru a écrit :

The attached patch fixed it.

https://bugs.launchpad.net/subdownloader/+bug/1289949 provided a partial
fix. I fixed the last issue in main.py

My test didn't show other regressions but don't hesitate to double check
(you should ;)

Sylvestre

Bug#766316: subdownloader: Fails to download substitles when having an accent in the path "é"

[Sylvestre Ledru]

If you are OK, can I just upload it now? Thanks

Le 11 nov. 2016 21:32, "Emilien Klein"  a écrit :

> Ok, thanks.
>
> Le ven. 11 nov. 2016 20:52, Sylvestre Ledru  a
> écrit :
>
>> Hello
>>
>> Because I am still facing this issue and this is causing this tool to be
>> useless, I uploaded as NMU with a 7 days delay.
>>
>> Sylvestre
>> Le 25/07/2016 à 14:14, Sylvestre Ledru a écrit :
>> > The attached patch fixed it.
>> >
>> > https://bugs.launchpad.net/subdownloader/+bug/1289949 provided a
>> partial
>> > fix. I fixed the last issue in main.py
>> >
>> > My test didn't show other regressions but don't hesitate to double check
>> > (you should ;)
>> >
>> > Sylvestre
>> >
>> >
>>
>>

Bug#842642: clang-3.9: memory sanitizer segfaults immediately

[Sylvestre Ledru]

I already uploaded 3.8 and 3.9 with the change. Could you report a new bug
for this? Merci

Le 11 nov. 2016 11:14 PM, "Norbert Lange"  a écrit :

> Hello,
>
> seems like the "efficiency sanitizer" needs a patch aswell. Luckily this
> is only for 3.9 as 3.8 doesnt even have this sanitizer.
> Building now, I don`t expect any problems.
>

Bug#836602: Reopening

[Sylvestre Ledru]

control: reopen -1

Hello,

I am sorry but ghc should aim to switch to 3.8 before the freeze.
I don't think we should ship with 3 llvm versions because of a single package.

Sylvestre

Bug#844209: RM: sivp -- ROM; Low popcon, dead upstream

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

hello

I think this is time to delete sivp from the archive.
with a popcorn of 23 and dead upstream, I don't think we should keep it in the 
archive.

S

Bug#820535: llvm-toolchain-3.8 on lower arm targets

[Sylvestre Ledru]

Le 05/11/2016 à 17:57, Pauli a écrit :

On Wed, 5 Oct 2016 23:33:49 +1300, Bruce Hoult wrote:

On Wed, Oct 5, 2016 at 7:46 AM, Tim Northover via llvm-dev <
llvm-...@lists.llvm.org> wrote:


Hi Emilio,

On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev
 wrote:

In file included from /«PKGBUILDDIR»/lib/Support/ThreadPool.cpp:14:0:
/«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function
'std::shared_future llvm::ThreadPool::async(Function&&, Args&&

...)':

/«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h:78:77: error: return

type

'class std::shared_future' is incomplete
inline std::shared_future async(Function &&F, Args &&...

ArgList) {
 ^

Any idea about this failure?

For the Debian armel porters, we're switching to LLVM 3.8, so this

failure

(which happens on 3.8, 3.9 and llvm-toolchain-snapshot) is likely going

to cause

some package removals on armel as we try to get rid of older LLVM

versions.

Helping fixing this issue would be appreciated to prevent that.

This looks like the kind of failure you get when your host toolchain
doesn't support C++11 properly (specifically lock-free atomics in this
case).  When I've seen it before GCC was defaulting to a CPU that's
too old to do atomics properly, and that configuration is very
unlikely to be supported by LLVM ever (any more).


This seems bogus.

C++11 allows atomic variables to be implemented using mutexes if the CPU
doesn't support atomic operations on a given data type in some other way.

If you don't call atomic_is_lock_free(&var) then everything should work
correctly, albeit perhaps more slowly than you might like.

It seems to me that atomic_is_lock_free() (or precomputed shortcuts such as
ATOMIC_INT_LOCK_FREE) is there to enable you the possibility to use a
different algorithm (if one is available), not to throw up your hands and
say you don't support that architecture at all!

If it's the standard library going out of its way to
check ATOMIC_INT_LOCK_FREE  and then throwing up its hands and giving up
then I'd say that's a bug. Simply taking out that check should produce
working, correct code on anything that supports mutexes at all.

Attached patch to debian libstdc++ package is supposed to fix clang
compilation.I'm still waiting compilation to complete before I can
test it. The compilation will take long time in an armel vm. I decided
to share it in case someone else has faster test environment than I
have.

The patch has extra src directory that needs to be striped with
s/\([ab]\)\/src/\1/g if someone tries to apply it to upstream sources.

Doko, any chance you could apply this patch?
This would be great for armel!

Thanks
S

Bug#862328: clang-4.0: ClangConfig.cmake is broken by Debian packaging

[Sylvestre Ledru]

Hello



Le 11/05/2017 à 13:26, Sylvain Joubert a écrit :
> Package: clang-4.0
> Version: 1:4.0.1~+rc1-1
> Severity: important
>
> Dear Maintainer,
>
> In the same way as #819072 and preceding issues for LLVMConfig, the Clang 
> CMake
> files are not usable with the current packaging in Debian.
> While LLVMConfig.cmake can be found without issue, this is not the case for
> ClangConfig.cmake
>
Would you mind providing a patch for this?

Thanks
S

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

[Sylvestre Ledru]

This should be probably reported as a separate bug! 

Thanks all for investigating :) 

Le 12 mai 2017 22:04:08 GMT+02:00, Graham Inggs  a écrit :
>Confirming that the second patch does fix hanging during the
>sanitizer_common tests on arm64.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#857085: [Pkg-d-devel] Bug#857085: terminix FTBFS on armhf: Error executing /usr/bin/ldc2: Segmentation fault

[Sylvestre Ledru]

Looks like similar to #862360?
According to
https://buildd.debian.org/status/logs.php?pkg=terminix&arch=armhf
the last 3 failures are only on hartmann

S


Le 23/05/2017 à 10:16, Matthias Klumpp a écrit :
> Cc Sylvestre Ledru as he maintains LLVM and might know best about
> changes done in the LLVM toolchain in Debian.
> 
> I uploaded an LDC to unstable yesterday with no changes but it's LLVM
> dependency changed to build against LLVM 4.0. With that version, the
> bug did not happen at all on the buildds.
> To be really certain it was gone, I used the harris porterbox again to
> see if it compiles the exact version of Terminix correctly now, and
> indeed it does.
> Then, I tried to build Terminix with the exact LDC version from
> Stretch before, and the bug also didn't show (4 builds in a row, just
> to be sure - the bug did *always* happen on harris before). I had a
> manually compiled version of LDC on that machine still, from previous
> attempts to debug the issue, that was compiled with LLVM 3.8 last, and
> building with that also didn't show the bug anymore.
> 
> So, LDC 1.1.1 built with LLVM 3.8, 3.9 and 4.0 in Stretch and Sid does
> not actually show this bug anymore. When jcristau removed LDC from
> Stretch (yes, I am still not happy with the amount of
> non-communication that was going on here!), the copy in there was
> actually already working, because something else in the toolchain
> changed and resolved the issue.
> 
> So, this of course might be a bug in LDC that now just doesn't get
> triggered anymore because something else has changed, but given the
> amount of work put in this bug to find the issue in LDC and the code
> where this bug actually happens in LDC, I think it's justified to
> assume that this is not actually a bug in LDC at all.
> 
> So, what's broken? LLVM 3.9 and 3.8 in Stretch received changes
> lately, but I do fail to see anything in the changelog that would have
> impacted this bug at all:
> 
> ```
> llvm-toolchain-3.9 (1:3.9.1-8) unstable; urgency=medium
> 
>   * Really fix "use versioned symbols" for llvm
> Thanks to Julien Cristau for the patch (Closes: #849098)
> 
>  -- Sylvestre Ledru   Tue, 25 Apr 2017 15:10:10 +0200
> 
> llvm-toolchain-3.9 (1:3.9.1-7) unstable; urgency=medium
> 
>   * Limit the archs where the ocaml binding is built
> Should fix the FTBFS
> Currently amd64 arm64 armel armhf i386
> 
>  -- Sylvestre Ledru   Sat, 15 Apr 2017 12:03:30 +0200
> 
> llvm-toolchain-3.9 (1:3.9.1-6) unstable; urgency=medium
> 
>   * Upload in unstable
>   * Bring back ocaml. Thanks to Cyril Soldani (Closes: #858626)
> 
>  -- Sylvestre Ledru   Fri, 14 Apr 2017 10:02:03 +0200
> 
> llvm-toolchain-3.9 (1:3.9.1-6~exp2) experimental; urgency=medium
> 
>   * Add override_dh_makeshlibs for the libllvm or liblldb versions
> Thanks to Julien Cristau for the patch
>   * change the min version of the libclang1 symbols to 1:3.9.1-6~
>   * Fix the symlink on scan-build-py
> 
>  -- Sylvestre Ledru   Tue, 28 Mar 2017 06:32:40 +0200
> 
> llvm-toolchain-3.9 (1:3.9.1-6~exp1) experimental; urgency=medium
> 
>   [ Rebecca N. Palmer ]
>   * Allow '!pointer' in OpenCL (Closes: #857623)
>   * Add missing liblldb symlink (Closes: #857683)
>   * Use versioned symbols (Closes: #848368)
> 
>  -- Sylvestre Ledru   Sun, 19 Mar 2017 10:12:03 +0100
> 
> llvm-toolchain-3.9 (1:3.9.1-5) unstable; urgency=medium
> 
>   * Fix the incorrect symlink to scan-build-py (Closes: #856869)
> 
>  -- Sylvestre Ledru   Sun, 12 Mar 2017 10:01:10 +0100
> ```
> 
> There were also GCC updates, and quite a bit of other stuff has
> changed as well, but since LDC now compiles the code correctly without
> being recompiled itself, I think it's safe to rule out any bug in GCC
> (as that's only used to build the C++ parts of LDC, and a
> wrong-codegen bug would have persisted in the binaries).
> 
> Not exactly sure where to go from here, but unless some major
> revelation about this bug happens, I am very inclined to just close it
> in a few weeks (and in case something like this happens again, we can
> file a new bug).
> 
> @Sylvestre: I know it's a long shot, but do you maybe know about
> anything in LLVM that could have altered the codegen in any way,
> recently in Stretch? From the changelogs, it doesn't really look like
> it, but maybe I am missing something. Context on this bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857085#41
> 
> Cheers,
> Matthias
> 

Bug#858626: libllvm-3.8-ocaml-dev: Package is empty

[Sylvestre Ledru]

Le 27/03/2017 à 23:54, Cyril Soldani a écrit :
> Hello,
>
> On Sat, 25 Mar 2017 16:37:20 +0100
> Sylvestre Ledru  wrote:
>> Le 24/03/2017 à 17:04, Cyril Soldani a écrit :
>>> It looks like this folder is missing since `libllvm-3.6-ocaml-dev`,
>>> and is still missing in `libllvm-3.9-ocaml-dev`. Last version
>>> containing it was `libllvm-3.5-ocaml-dev`, but it is not
>>> installable on `stretch`. 
>> Thanks!
>> As it has been in this state for a while and nobody complained about,
>> I will probably just remove it from the packaging...
> I understand your rationale, but I would still like to give the
> following arguments in favour of keeping (and fixing) the package:
Did you try to rebuild it from scratch ? fails for me:

-- Up-to-date:
/home/sylvestre/dev/debian/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-3.8-3.8.1/debian/tmp/usr/lib/llvm-3.8/bin/yaml2obj
CMake Error at docs/cmake_install.cmake:36 (file):
  file INSTALL cannot find
 
"/home/sylvestre/dev/debian/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-3.8-3.8.1/build-llvm/docs/ocamldoc/html".
Call Stack (most recent call first):
  cmake_install.cmake:66 (include)


Makefile:86 : la recette pour la cible « install » a échouée
make[2]: *** [install] Erreur 1
make[2] : on quitte le répertoire
« 
/home/sylvestre/dev/debian/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-3.8-3.8.1/build-llvm
 »

S




signature.asc
Description: OpenPGP digital signature

Bug#858626: libllvm-3.8-ocaml-dev: Package is empty

[Sylvestre Ledru]

Le 28/03/2017 à 00:04, Cyril Soldani a écrit :
> Hello,
>
> On Sat, 25 Mar 2017 16:37:20 +0100
> Sylvestre Ledru  wrote:
>> Le 24/03/2017 à 17:04, Cyril Soldani a écrit :
>>> It looks like this folder is missing since `libllvm-3.6-ocaml-dev`,
>>> and is still missing in `libllvm-3.9-ocaml-dev`. Last version
>>> containing it was `libllvm-3.5-ocaml-dev`, but it is not
>>> installable on `stretch`. 
>> Thanks!
>> As it has been in this state for a while and nobody complained about,
>> I will probably just remove it from the packaging...
> I understand your rationale, but I would still like to give the
> following arguments in favour of keeping (and fixing) the package:
If you are interested to bring it back, please start from r2529
(and try in a clean pbuilder, your patch had missing build deps)

This is blocking me on other bugs and I don't have time for this bug.

sorry
S




signature.asc
Description: OpenPGP digital signature

Bug#856869: clang-3.9: broken symlink: /usr/bin/scan-build-3.9-py -> ../share/clang/scan-build-3.9/bin/scan-build-py

[Sylvestre Ledru]

Le 13/03/2017 à 20:22, Andreas Beckmann a écrit :
> Followup-For: Bug #856869
>
> Hi Sylvestre,
>
> this issue also shows up in clang-4.0 and clang-5.0. Do you prefer
> separate bug reports for them or does the fix "automatically" flow to
> the newer versions?
>
> e.g.
>
> 0m46.8s ERROR: FAIL: Broken symlinks:
>   /usr/bin/scan-build-5.0-py -> 
> ../share/clang/scan-build-5.0/bin/scan-build-py
>
This is already fixed in the svn, thanks for asking :)

Bug#857682: uploaded to delayed/3

[Sylvestre Ledru]

Sorry for not doing that ealier. please upload it now if you can :)
Le 17/03/2017 à 18:41, Martin Zobel-Helas a écrit :
> Hi,
>
> i uploaded a fixed version to delayed/3.
>
> find patch attached
>

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 18/03/2017 à 23:40, Rebecca N. Palmer a écrit :
> Can this be fixed in time for Ubuntu 17.04?  Their mesa is built against LLVM 
> 4.0, so if this bug isn't fixed, I (as beignet maintainer) have to choose 
> between "apply a very new 4.0-support patch that might or might not work" and 
> "leave beignet on 3.9, making OpenCL+OpenGL applications (e.g.
> blender) subject to this bug".
> 
>> I've been told that there is a command line to add a version to all symbols
>> without a script, that should be enough at least for Debian packaging.
> -Wl,--default-symver : rarely used (only 5 packages), and forces the symbol 
> version to be the soname (i.e. libLLVM-3.9.so.1) rather than the conventional 
> LLVM_3.9 form (i.e. potential binary incompatibility if upstream later decide 
> to do it the conventional way), but should at least fix this crash.
> 
> The attached debdiff is for this option, and also fixes #857623 and #857683.  
> Warning: has NOT been tested yet.
> 
> I intend to try extending the earlier "version script" patch to also cover 
> libclang and liblldb tomorrow.

Impressive! I believe we can try this solution. Many thanks.
I started to build this myself.

If it is working file, I will discuss with upstream about integrating that!
Bravo,
Sylvestre

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 19/03/2017 à 11:13, Rebecca N. Palmer a écrit :
> Here's the 'version script' solution, now covering libLLVM, libclang,
> liblldb, libLTO, BugpointPasses, LLVMHello and LLVMgold (I suspect
> only the first 2-3 actually have use for it, but all except the first
> are set from the same place).
>
> Warning: this hasn't been tested either, and the
> cmake/modules/AddLLVM.cmake modified here gets shipped in llvm-3.9-dev.
>
Looks great, well done for this great work!
What do you mean by "not tested" ? You did built it right?

S

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 19/03/2017 à 15:46, Rebecca N. Palmer a écrit :
>> What do you mean by "not tested" ? You did built it right?
> Not as of that message.
>
> I since tried to build the "version script" option: it failed most of
> its tests with
> -- 
> Exit Code: 126
>
> Command Output (stderr):
> -- 
> E: env var COWDANCER_ILISTFILE not defined
> E: cowdancer: Fatal, initialize_functions failed
> E: env var COWDANCER_ILISTFILE not defined
> E: env var COWDANCER_ILISTFILE not defined
> E: env var COWDANCER_ILISTFILE not defined
> /bin/bash:
> /home/rnpalmer/Debian/builds/stackbuild/llvm-toolchain-3.9-3.9.1/build-llvm/test/CodeGen/X86/Output/2008-04-09-BranchFolding.ll.script:
> Cannot allocate memory 
First time that I see that error
and LLVM should not have any test failing

S

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 19/03/2017 à 17:02, Rebecca N. Palmer a écrit :
> 12 clang tests "unexpectedly" fail, but they're the same 12 that do so
> in the existing package:
> Failing Tests (12):
> Clang :: CodeGen/linux-arm-atomic.c
> Clang :: Driver/arm-cortex-cpus.c
> Clang :: Driver/arm-features.c
> Clang :: Driver/arm-ias-Wa.s
> Clang :: Driver/arm-mfpu.c
> Clang :: Driver/cross-linux.c
> Clang :: Driver/mips-as.c
> Clang :: Driver/mips-integrated-as.s
> Clang :: Preprocessor/arm-acle-6.5.c
> Clang :: Preprocessor/arm-target-features.c
> Clang :: Sema/builtins.c
> Clang :: SemaCXX/warn-memsize-comparison.cpp
>
>   Expected Passes: 9572
>   Expected Failures  : 16
>   Unsupported Tests  : 40
>   Unexpected Failures: 12
>
> The build then fails for symbols mismatch...with what looks like
> exactly the change we *want*:
>
> (last few of many)
> + clang_saveTranslationUnit@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_sortCodeCompletionResults@Base 3.2
> + clang_sortCodeCompletionResults@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_toggleCrashRecovery@Base 3.2
> + clang_toggleCrashRecovery@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_tokenize@Base 3.2
> + clang_tokenize@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_visitChildren@Base 3.2
> + clang_visitChildren@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_visitChildrenWithBlock@Base 3.2
> + clang_visitChildrenWithBlock@LLVM_3.9 1:3.9.1-5local2
> dh_makeshlibs: failing due to earlier errors
>
Indeed. Are you going to update the symbol file?

Many thanks again!

S

Bug#858626: libllvm-3.8-ocaml-dev: Package is empty

[Sylvestre Ledru]

Le 24/03/2017 à 17:04, Cyril Soldani a écrit :
> It looks like this folder is missing since `libllvm-3.6-ocaml-dev`, and
> is still missing in `libllvm-3.9-ocaml-dev`. Last version containing it
> was `libllvm-3.5-ocaml-dev`, but it is not installable on `stretch`.
>
Thanks!
As it has been in this state for a while and nobody complained about,
I will probably just remove it from the packaging...

S

Bug#726230: Geolocation fixed

[Sylvestre Ledru]

Hello,

As attachment, you will find a patch to enable geolocation in the Firefox 
debian package.

As mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726230#45, 
Mozilla is OK
with the key being public.

Mike, please let me know if you want me to push that and/or update firefox-esr 
too.

Cheers,
Sylvestre

>From 610f19f941e0bf4a2292466fa5256d4fa2006dcd Mon Sep 17 00:00:00 2001
From: Sylvestre Ledru 
Date: Thu, 2 Mar 2017 11:17:24 +0100
Subject: [PATCH] Enable geolocation using Mozilla's Location Service (Closes:
 #726230)

---
 debian/browser.mozconfig.in | 1 +
 debian/changelog| 6 ++
 debian/mls.key  | 2 ++
 3 files changed, 9 insertions(+)
 create mode 100644 debian/mls.key

diff --git a/debian/browser.mozconfig.in b/debian/browser.mozconfig.in
index 590c4f35306..8729c462a8a 100644
--- a/debian/browser.mozconfig.in
+++ b/debian/browser.mozconfig.in
@@ -46,3 +46,4 @@ ac_add_options --enable-pie
 %if BUILD_RUST
 ac_add_options --enable-rust
 %endif
+ac_add_options --with-mozilla-api-keyfile=$topsrcdir/debian/mls.key
diff --git a/debian/changelog b/debian/changelog
index 72fd814e65f..b5c558addf3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+firefox (51.0.1-4) unstable; urgency=medium
+
+  * Enable geolocation using Mozilla's Location Service (Closes: #726230)
+
+ -- Sylvestre Ledru   Thu, 02 Mar 2017 11:16:51 +0100
+
 firefox (51.0.1-3) unstable; urgency=medium
 
   * js/src/jit/mips-shared/Assembler-mips-shared.h,
diff --git a/debian/mls.key b/debian/mls.key
new file mode 100644
index 000..3bc906ca3eb
--- /dev/null
+++ b/debian/mls.key
@@ -0,0 +1,2 @@
+91e66841-a83b-487f-9b5d-e460f5225ebf
+
-- 
2.11.0

Bug#839906: Bug#839909: diff NMU for llvm-defaults_0.34+nmu1

[Sylvestre Ledru]

Hello

please upload it now

merci anton!

S

Le 11/03/2017 à 21:07, Anton Gladky a écrit :
> tags 839906 +pending +patch
> tags 839909 +pending +patch
> thanks
> 
> Dear maintainer,
> 
> I have prepared an NMU (versioned as 0.34+nmu1) and
> uploaded to DELAYED/5.
> 
> Please fell free to tell me if I should delay it longer, cancel
> or reschedule.
> 
> Diff is attached.
> 
> Best regards
> 
> Anton
> 

Bug#856542: Comment

[Sylvestre Ledru]

Le 12/03/2017 à 13:20, Jacques-Pascal Deplaix a écrit :
> I see in the sources (llvm-toolchain-4.0_4.0-1.debian.tar.xz) that all
> content of liblld-X.Y.install.in is commented.
> This might be the problem. Why is it commented in the first place ?
because it is breaking the generation of the packages but needed for the ci
http://llvm-jenkins.debian.net/
I haven't looked why.

(only for the static lib)

Don't hesitate to provide a patch, I won't investigate that soon.

S

Bug#855222: clang-4.0 has wrong C++ include search path order

[Sylvestre Ledru]

This is probably the correct fix. Thanks :) 

Le 15 février 2017 21:06:12 GMT+01:00, Jason Rhinelander 
 a écrit :
>A quick follow-up and potential solution:
>
>I rebuilt the package with debian/patches/fix-clang-path-and-build.diff
>
>changed to move the added `addSystemInclude(...)` call to just *after* 
>adding the c++ library include paths, instead of before it, which 
>results in a working include path order:
>
>$ clang++-4.0 -v -E -x c++ -stdlib=libc++ -
>clang version 4.0.0-+rc2-1.1 (tags/RELEASE_400/rc1)
>...
>#include "..." search starts here:
>#include <...> search starts here:
>  /usr/include/c++/v1
>  /usr/include/clang/4.0.0/include
>  /usr/local/include
>  /usr/include/x86_64-linux-gnu
>  /usr/include
>End of search list.
>
>
>I'm not sure if that causes other problems, but it looks like a fix.
>
>
>Jason Rhinelander
>
>___
>Pkg-llvm-team mailing list
>pkg-llvm-t...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#861170: llvm-toolchain-4.0: missing Build-Depends: cmake (>= 3.4.3), libncurses-dev

[Sylvestre Ledru]

Le 25/04/2017 à 12:31, Helmut Grohne a écrit :
> Source: llvm-toolchain-4.0
> Version: 4.0_4.0-3
> Severity: important
Next time, please fill one per issue.


> Building llvm-toolchain-4.0 errors out when one tries to build it with
> a version of cmake older than 3.4.3. 
Because of the way apt.llvm.org operate, I cannot set this for now.
Anyway, upstream is checking that in the cmake configure. So, I don't think 
this is an important issue.


> installation set does not contain libncurses-dev. Both of these happen
> when trying to backport the package to jessie. Please add a version
> restriction (>= 3.4.3) to the cmake build dependency and add
> libncurses-dev to build depends as both are really needed. Not adding
> them can result in a serious bug when other packages change their
> runtime dependencies.
Fixed for libncurses in the svn.

S

Bug#861336: iceweasel: Can't remove properly

[Sylvestre Ledru]

Hello,

Le 27/04/2017 à 17:28, Taneli Hongisto a écrit :
> Package: iceweasel
> Version: 45.9.0esr-1~deb8u1
> Severity: important
>
> Dear Maintainer,
>
>  am using chormium as my go-to browser but cannot remove iceweasel or firefox-
> esr packages without being prompted to also remove gnome and gnome-core. It is
> a dependancy problem.
Please provide more information. This would help with the diagnostic of the 
issue.

S

Bug#854965: clang-4.0: Pulls 64-bit libs on i386 system

[Sylvestre Ledru]

Why do you consider that as serious? 

Le 12 février 2017 17:28:45 GMT+01:00, Robert Luberda  a 
écrit :
>Package: clang-4.0
>Version: 1:4.0~+rc2-1
>Severity: serious
>
>For some reason clang has recently started depending (via
>libclang-common-4.0-dev) on 64-bit packages like lib64gcc1 
>that I believe are mostly needed for cross-compiling only, 
>what most of people don't do.
>
>Could you please get rid of those strange dependencies?
>
>Regards,
>robert
>
>-- System Information:
>Debian Release: 9.0
>  APT prefers unstable
>  APT policy: (990, 'unstable'), (200, 'testing')
>Architecture: i386 (i686)
>
>Kernel: Linux 4.9.0-1-686-pae (SMP w/1 CPU core)
>Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: sysvinit (via /sbin/init)
>
>___
>Pkg-llvm-team mailing list
>pkg-llvm-t...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#854965: clang-4.0: Pulls 64-bit libs on i386 system

[Sylvestre Ledru]

severity 854965 normal
thanks

Le 12/02/2017 à 20:34, Robert Luberda a écrit :
> Sylvestre Ledru pisze:
>> Why do you consider that as serious?
> The Debian Policy in section 3.5 says "Every package must specify the
> dependency information about other packages that are required for the
> first to work correctly."  It can be that the sentence is more about
> depending on needed packages rather than about not depending on
> unnecessary ones, but honestly I would still consider too wide
> dependencies as a serious bug. However feel free lower the severity if
> you disagree.
yeah, I just did. This doesn't cause any severe issues.

> Anyway in my opinion the 64-bit libraries are not needed for clang to
> work correctly on i386. I can see that the libclang-common-dev package
> started providing some x86_64 libs, and dpkg-shlibdeps added dependences
> that were necessary for those libs; but I am really in doubt if clang
> will ever use those libs in normal usage, so maybe there is some
> packaging error somewhere? However if this was intentional for any
> reason, it would be great if you could consider making the dev package
> Multi-Arch:same instead to get rid of those strange 64-bit libs dependences.
I think it was introduced in 3.9-5 to fix bug #841923. I guess 3.9 is
also impacted

Don't hesitate to propose a patch to implement Multi-Arch:same.
I won't have the time to implement it soon.

S
 

Bug#855012: clang-3.9: Segmentation fault when compiling

[Sylvestre Ledru]

Le 13/02/2017 à 09:27, Eric Peter Stavarache a écrit :
> Package: clang-3.9
> Version: 1:3.9.1-4
> Severity: important
>
> Dear Maintainer,
>
>
> This the code in question:
>
I am getting with your command line:
---
main.cpp:1:10: fatal error: 'memory' file not found
#include 
 ^
1 error generated.
---

If I comment the include, I am getting:
main.cpp:9:28: fatal error: unused parameter 'eth_context'
[-Wunused-parameter]
static action foo(StructA ð_context)
   ^
1 error generated.


Can you tell me more?

S

Bug#855012: clang-3.9: Segmentation fault when compiling

[Sylvestre Ledru]

OK, I can reproduce it with:
$ /usr/lib/llvm-3.9/bin/clang -cc1  -Werror  -Wfatal-errors -x c++
main.cpp -Wall
main.cpp:7:6: fatal error: scoped enumerations are a C++11 extension
enum class action { };
 ^
#0 0x7f7f57c70125 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0x707125)
#1 0x7f7f57c6e2de llvm::sys::RunSignalHandlers()
(/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0x7052de)
#2 0x7f7f57c6e402
(/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0x705402)
#3 0x7f7f5a19b100 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11100)
#4 0x5634e9d5bbe3 (/usr/lib/llvm-3.9/bin/clang+0x120dbe3)
#5 0x5634e9d5bd9d (/usr/lib/llvm-3.9/bin/clang+0x120dd9d)
#6 0x5634e9d5be41 (/usr/lib/llvm-3.9/bin/clang+0x120de41)
#7 0x5634e9d5f405 (/usr/lib/llvm-3.9/bin/clang+0x1211405)
#8 0x5634e9d5e13b (/usr/lib/llvm-3.9/bin/clang+0x121013b)
#9 0x5634e9d60550 clang::CFG::buildCFG(clang::Decl const*,
clang::Stmt*, clang::ASTContext*, clang::CFG::BuildOptions const&)
(/usr/lib/llvm-3.9/bin/clang+0x1212550)
#10 0x5634e9d4dcfa clang::AnalysisDeclContext::getCFG()
(/usr/lib/llvm-3.9/bin/clang+0x11ffcfa)
#11 0x5634e9a8c72a
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::BlockExpr
const*) (/usr/lib/llvm-3.9/bin/clang+0xf3e72a)
#12 0x5634e967e8c7
clang::Sema::PopFunctionScopeInfo(clang::sema::AnalysisBasedWarnings::Policy
const*, clang::Decl const*, clang::BlockExpr const*)
(/usr/lib/llvm-3.9/bin/clang+0xb308c7)
#13 0x5634e972ec02
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool)
(/usr/lib/llvm-3.9/bin/clang+0xbe0c02)
#14 0x5634e956d324
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) (/usr/lib/llvm-3.9/bin/clang+0xa1f324)
#15 0x5634e94e6894
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::LateParsedAttrList*) (/usr/lib/llvm-3.9/bin/clang+0x998894)
#16 0x5634e9505407
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int,
clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/usr/lib/llvm-3.9/bin/clang+0x9b7407)
#17 0x5634e94e2032
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
(/usr/lib/llvm-3.9/bin/clang+0x994032)
#18 0x5634e94e26f1 (/usr/lib/llvm-3.9/bin/clang+0x9946f1)
#19 0x5634e94e271f
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
(/usr/lib/llvm-3.9/bin/clang+0x99471f)
#20 0x5634e94e884f
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) (/usr/lib/llvm-3.9/bin/clang+0x99a84f)
#21 0x5634e94e9204
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&)
(/usr/lib/llvm-3.9/bin/clang+0x99b204)
#22 0x5634e94ddb1b clang::ParseAST(clang::Sema&, bool, bool)
(/usr/lib/llvm-3.9/bin/clang+0x98fb1b)
#23 0x5634e92b7e26 clang::FrontendAction::Execute()
(/usr/lib/llvm-3.9/bin/clang+0x769e26)
#24 0x5634e928aa76
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/lib/llvm-3.9/bin/clang+0x73ca76)
#25 0x5634e9333553
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/lib/llvm-3.9/bin/clang+0x7e5553)
#26 0x5634e8f99a98 cc1_main(llvm::ArrayRef, char
const*, void*) (/usr/lib/llvm-3.9/bin/clang+0x44ba98)
#27 0x5634e8f8d683 main (/usr/lib/llvm-3.9/bin/clang+0x43f683)
#28 0x7f7f5671b2b1 __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b1)
#29 0x5634e8f97e0a _start (/usr/lib/llvm-3.9/bin/clang+0x449e0a)
Stack dump:
0.Program arguments: /usr/lib/llvm-3.9/bin/clang -cc1 -Werror
-Wfatal-errors -x c++ main.cpp -Wall
1. parser at end of file
2.main.cpp:25:1: parsing function body 'fun'
Erreur de segmentation




Le 13/02/2017 à 09:54, Eric Peter STAVARACHE a écrit :
> The include error is because it uses the libs provided by gcc 6.3.0
>
> Try this version that does not include anything.
>
>
>
> struct StructA;
> struct StructB;
> struct StructC;
>
> enum class action { };
>
> template
> struct shared_ptr
> {
>
> shared_ptr(T*)
> {
>
> }
>
> };
>
> static action foo(StructA ð_context)
> {
> }
>
> static void fun(struct StructB *response, void *callbackContext)
> {
> shared_ptr context =
> shared_ptr(reinterpret_cast(callbackContext));
> }
> 
> From: Sylvestre Ledru 
> Sent: Monday, February 13, 2017 10:39 AM
> To: Eric Peter STAVARACHE; 855...@bugs.debian.org
> Subject: Re: Bug#855012: clang-3.9: Segmentation fault when compiling
&

Bug#824724: ninja-build: Please package the new upstream release (1.7.1)

[Sylvestre Ledru]

Package: ninja-build
Version: 1.6.0-1
Severity: wishlist

Hello,

The title says all. It would be great to have ninja 1.7.1 in Debian!

Thanks,
Sylvestre

Bug#825155: incomplete libclang shared library

[Sylvestre Ledru]

Le 24/05/2016 à 09:46, Matthias Klose a écrit :
> Package: src:llvm-toolchain-3.8
> Version: 1:3.8-2
> Severity: important
>
> when trying to link creduce with -lclang-3.8 -lLLVM-3.8 instead of
> using the separate static libs, there are link failures, apparently
> some libraries are missing in the shared lib. See the attached log. 
Can you define "some libraries"?

S

Bug#803644: fixed in julia 0.4.2-1

[Sylvestre Ledru]

Le 09/12/2015 13:35, Emilio Pozuelo Monfort a écrit :
> On 09/12/15 19:30, Peter Colberg wrote:
>> On Wed, Dec 09, 2015 at 12:51:15PM +0100, Emilio Pozuelo Monfort wrote:
>>> On 08/12/15 16:54, Peter Colberg wrote:
 As an alternative to not having Julia 0.4 in Debian at all, would you
 agree to the Julia team reuploading the LLVM 3.3 package to unstable
 under our maintainership?
>>> Sorry but that isn't an option.
>>>
>>> What you can do is keep julia in unstable using llvm 3.8, and that will 
>>> migrate
>>> to testing once 3.8 is officially released and migrates to testing.
>> Emilio, thanks for your feedback. I see two options going forward then:
>>
>> Either we let julia depend on llvm 3.8, which will delay the migration
>> to testing until next spring. This is basically equivalent to skipping
>> Julia 0.4 entirely.
>>
>> Or we let julia depend on llvm 3.7 and accept the performance hit on
>> amd64.
> You can do the latter, and upload a version that uses llvm 3.8 to experimental
> so testing/sid users can try that if necessary.
>
This is a clever solution :)
You can report a bug on the package in testing/unstable to inform our users.

Sylvestre

Bug#786836: [Pkg-rust-maintainers] Bug#786836: packaging not yet ready for mass/stable usage

[Sylvestre Ledru]

Hello Ralph,
Le 10/12/2015 10:51, Ralph Giles a écrit :
> On Tue, 26 May 2015 00:15:50 +0200 Luca Bruno  wrote:
>
>> Even though Rust recently reached the 1.0 milestone, compiler and
>> ecosystem packaging still has to reach a "ready for the masses"
>> status.
> What needs to happen to resolve this bug?
>
> We're starting to use rust code in Firefox, and I'd like to make sure
> we have a rust toolchain in debian so it's still possible to build
> upcoming releases.
I will be at the meeting [1] in 30 minutes :p , we can discuss about
that if you want :)
Myself, I am happy to let rust migrate to testing. Using the Debian rust
packages to build
Firefox is a proof that it is ready for production.

S
[1] http://mozlando2015.sched.org/event/4lND/rustservo-in-gecko

Bug#786836: [Pkg-rust-maintainers] Bug#786836: packaging not yet ready for mass/stable usage

[Sylvestre Ledru]

Le 10/12/2015 12:19, Luca Bruno a écrit :
> On Thursday 10 December 2015 10:58:28 Sylvestre Ledru wrote:
>
>>>> Even though Rust recently reached the 1.0 milestone, compiler and
>>>> ecosystem packaging still has to reach a "ready for the masses"
>>>> status.
>>> What needs to happen to resolve this bug?
>> Myself, I am happy to let rust migrate to testing. Using the Debian rust
>> packages to build Firefox is a proof that it is ready for production.
> We had an informal discussion on IRC a bunch of days ago, and we now feel 
> confident enough to let rustc+cargo into testing.
> rustc 1.5.0 has been tagged today, and together with cargo 0.6.0 we plan to 
> let them migrate to testing.
>
> On the other hand, we are still a bit unsure on the rest of the ecosystem 
> (for 
> which we'll probably need a dh helper), so we still plan to keep on hold 
> third-party libraries and apps packaging.
>
> I'll take care of closing this bug in a few days, assuming rustc+cargo are 
> fine.
>
I am working on the packaging of 1.5. I will close the bug as part of
the upload.
I will also replace the hash of the package by the version as discussed
a couple months ago.

Works for you?

Sylvestre




signature.asc
Description: OpenPGP digital signature

Bug#788327: Swift update

[Sylvestre Ledru]

llvm & clang patched and probably necessary for swift.
This won't be easy I think

Bug#808576: [Pkg-rust-maintainers] Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"

[Sylvestre Ledru]

Le 21/12/2015 14:02, Luca Bruno a écrit :
> On Monday 21 December 2015 12:27:47 Luca Bruno wrote:
> 
>> For reference, current working sid toolchain is ld 2.25.90.20151209 and gcc
>> 5.3.1-4.
> 
> Similarly, I tried in a fresh stretch environment and it works fine.
> The toolchain there is ld 2.25.90.20151209 and gcc 5.3.1-3.
As mentioned on #debian-rust this morning, it seems the same as:
https://github.com/rust-lang/rust/issues/30305

Rust 1.5 cherry-picked from unstable on a testing system?

S




signature.asc
Description: OpenPGP digital signature

Bug#758325: clang: trying to overwrite files from clang-3.3

[Sylvestre Ledru]

severity 758325 normal
thanks

On 16/08/2014 23:31, Bernd Zeimetz wrote:
> Package: clang
> Version: 1:3.4-23
> Severity: grave
>
> clang fails to install together with clang-3.3:
>
> Unpacking clang (1:3.4-23) over (1:3.3-21+nmu1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/clang_1%3a3.4-23_amd64.deb (--unpack):
>  trying to overwrite '/usr/bin/clang-tblgen', which is also in package
>  clang-3.3 1:3.3-16
>  Processing triggers for man-db (2.6.7.1-1) ...
>
>
> There is a breaks/replaces for clang-3.3 missing.
>
> As clang-3.3 will be removed I guess it should be fine to downgrade the
> bug, but the current state doesn't make regular testing/unstable users
> happy ;)
>
Yes, I don't really care about 3.3 anymore...

We still have it just for bug 753971.

Sylvestre


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

Bug#758585: FTBFS on mips and mipsel due to lack of lldb-3.4-dev there

[Sylvestre Ledru]

block 758585 by 758314
thanks

Hello Olly,

No, it is not deliberate and the change is done.
I was waiting for other changes before uploading but I will try to
upload it today.

Cheers,
S


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

Bug#755354: subsurface Re: Bug#755354: is help needed?

[Sylvestre Ledru]

block 755354 by 745960
thanks

+ tim as cc since he worked on that.

On 20/08/2014 18:12, Salvo Tomaselli wrote:
> Hello,
>
> if help is needed (maintainer has no time) I can package the new version, but 
> since I'm not a DD I'd need a sponsor.
>
> Please let me know.
Very sorry about the lack of information in this bug.
Actually, the problem is that the new version of subsurface needs
libgit2 and it is not yet in Debian unstable.
So, I see a few potential solutions:
* upload the new version of subsurface in experimental
* disable libgit2 features (I don't think it is possible)
* convince Russell Sim to upload it in unstable

I would happy to sponsor this.

Cheers,
Sylvestre


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

Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Sylvestre Ledru]

On 21/08/2014 21:17, Sébastien Villemot wrote:
> Hi Sylvestre,
>
> Le lundi 07 juillet 2014 à 16:50 +0200, Sylvestre Ledru a écrit :
>
>> Me too but 3.3 is already more than an year old. It is unmaintained
>> (unlike 3.4 which has point releases) and 3.5 will be part of Debian Jessie.
>> I cannot afford to maintain 4 versions of LLVM in parallel (3.3, 3.4,
>> 3.5 and snapshot).
> julia has been removed from jessie, and I raised the severity of the
> present bug to serious, so you can safely remove LLVM 3.3 from jessie if
> you wish.
>
> I am working on a version of julia that builds against LLVM 3.5.
> Hopefully it will reach sid soon.
>
>
Oh, merci :)

Good luck with the 3.5 based packaging.

Sylvestre


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

Bug#759275: feel++: FTBFS - /usr/bin/clang++ not found (should be clang++-3.4)

[Sylvestre Ledru]

That is likely to be caused by:
http://sylvestre.ledru.info/blog/2014/08/11/clang-3-4-3-5

cheers,
S

On 25/08/2014 21:28, Christophe Prud'homme wrote:
> That's weird, all my packages are built with pbuilder and I never has
> this issue.
> I will check and try out your fix.
>
> Best regards
> C.
>
>
> On Mon, Aug 25, 2014 at 8:51 PM, Michael Tautschnig  > wrote:
>
> Package: feel++
> Version: 1:0.98.0-final-3
> Severity: serious
> Usertags: goto-cc
>
> During a rebuild of all Debian packages in a clean sid chroot
> (using cowbuilder
> and pbuilder) the build failed with the following error.
>
> [...]
> -- Check for working CXX compiler: /usr/bin/clang++
> CMake Error: your CXX compiler: "/usr/bin/clang++" was not found. 
>  Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
> CMake Error: Internal CMake error, TryCompile configure of cmake
> failed
> -- Check for working CXX compiler: /usr/bin/clang++ -- broken
> CMake Error at
> /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
>   The C++ compiler "/usr/bin/clang++" is not able to compile a
> simple test
>   program.
>
>   It fails with the following output:
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:62 (project)
>
>
> CMake Error: your CXX compiler: "/usr/bin/clang++" was not found. 
>  Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
> -- Configuring incomplete, errors occurred!
>
>
> Indeed this should be clang++-3.4 it seems:
>
> # ls -l /usr/bin/clang++*
> lrwxrwxrwx 1 root root 27 Aug 19 06:58 /usr/bin/clang++-3.4 ->
> ../lib/llvm-3.4/bin/clang++
>
> You may want to depend on the clang package instead of clang-3.4 |
> clang-3.5.
>
> The full build log is attached; please do let me know if the
> problem is
> unreproducible, in which case I shall try to investigate further.
>
> Best,
> Michael
>
>
>
>
> -- 
> Professor in Scientific Computing
> IRMA, CeMoSiS, AMIES
> IRMA: http://www-irma.u-strasbg.fr/~prudhomm
> 
> CeMoSis: http://www.cemosis.fr 
> AMIES: http://www.agence-maths-entreprises.fr/
> Téléphone : 03 68 85 0089 - Bureau : P-210
> Mobile: 06 87 64 60 51
>
>

Bug#753965: Removal of llvm 3.3

[Sylvestre Ledru]

tags 753965 - moreinfo
thanks

Now that kfreebsd has removed it dependency to llvm 3.3 
and julia is no longer in testing (and the maintainer agreed),

could you remove llvm 3.3?

Thanks
Sylvestre


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

Bug#794462: arcanist should depends on the exact same version of libphutil

[Sylvestre Ledru]

Package: arcanist
Version: 0~git20150613-1
Severity: important

Dear Maintainer,

I just updated (only) arcanist to v 0~git20150613-1
and  
$ arc diff 
failed with:

PHP Fatal error:  Call to undefined method PhutilTranslator::setLocale() in 
/usr/share/arcanist/scripts/__init_script__.php on line 57

Fatal error: Call to undefined method PhutilTranslator::setLocale() in 
/usr/share/arcanist/scripts/__init_script__.php on line 57

Updating libphutil from 0~git20150129-2 to 0~git20150613-1 fixed the issue.

arcanist should depends on the same version of libphutil.

Thanks,
Sylvestre


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'stable-updates'), (500, 'stable'), 
(300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages arcanist depends on:
ii  libphutil  0~git20150613-1
ii  php5-cli   5.6.5+dfsg-1
ii  php5-curl  5.6.5+dfsg-1

arcanist recommends no packages.

Versions of packages arcanist suggests:
ii  python  2.7.9-1

-- no debconf information


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

Bug#794473: RM: dragonegg -- ROM; Not maintained upstream

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

Hello,

Dragonegg is a dead project. Upstream is no longer maintaining it
and it has been removed from the llvm release cycle.
popcon is low (60) and clang is now a better alternative.
I guess this is time to remove it from Debian.

Sylvestre


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

Bug#794572: Fix setting GCC version

[Sylvestre Ledru]

Le 04/08/2015 16:37, Matthias Klose a écrit :
> Package: src:llvm-toolchain-3.7
> Version: 1:3.7~+rc2-1
> Severity: serious
> Tags: sid stretch patch
>
> patch at
> http://launchpadlibrarian.net/213567928/llvm-toolchain-3.7_1%3A3.7~%2Brc2-1_1%3A3.7~%2Brc2-1ubuntu1.diff.gz
>
>
This patch does not work in the context of http://llvm-jenkins.debian.net/
I fixed in the repository but I will try to fix bug 794539 before
uploading it

Sylvestre


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

Bug#781197: FTBFS with GCC-5

[Sylvestre Ledru]

Le 06/08/2015 13:36, Sebastian Andrzej Siewior a écrit :
> On 2015-03-25 23:57:21 [+0100], Roderich Schupp wrote:
>> Build stops with:
>>
> I tried 3.5.2-1 with gcc version 5.2.1 20150730 (Debian 5.2.1-14). Patch
> Patch #1 should fix the FTBFS.
> Patch #2 should workaround the part where it tries to use gcc-5.2 which is
> not available as package or binary.
Many thanks!

> The build ends now with
> | 
> | Failing Tests (29):
> | LLVM :: CodeGen/AArch64/arm64-2012-06-06-FPToUI.ll
> | LLVM :: CodeGen/AArch64/arm64-abi_align.ll
> | LLVM :: CodeGen/AArch64/arm64-anyregcc-crash.ll
> | LLVM :: CodeGen/AArch64/arm64-anyregcc.ll
> | LLVM :: CodeGen/AArch64/arm64-big-endian-bitconverts.ll
> | LLVM :: CodeGen/AArch64/arm64-big-endian-vector-caller.ll
> | LLVM :: CodeGen/AArch64/arm64-elf-globals.ll
> | LLVM :: CodeGen/AArch64/arm64-fast-isel-call.ll
> | LLVM :: CodeGen/AArch64/arm64-fast-isel-indirectbr.ll
> | LLVM :: CodeGen/AArch64/arm64-fast-isel-noconvert.ll
> | LLVM :: CodeGen/AArch64/arm64-fastisel-gep-promote-before-add.ll
> | LLVM :: CodeGen/AArch64/arm64-fp128.ll
> | LLVM :: CodeGen/AArch64/arm64-illegal-float-ops.ll
> | LLVM :: CodeGen/AArch64/arm64-neon-mul-div.ll
> | LLVM :: CodeGen/AArch64/arm64-neon-vector-list-spill.ll
> | LLVM :: CodeGen/AArch64/arm64-platform-reg.ll
> | LLVM :: CodeGen/AArch64/arm64-spill.ll
> | LLVM :: CodeGen/AArch64/arm64-stackmap.ll
> | LLVM :: CodeGen/AArch64/arm64-stacksave.ll
> | LLVM :: CodeGen/AArch64/arm64-vcvt_f.ll
> | LLVM :: CodeGen/AArch64/arm64-vfloatintrinsics.ll
> | LLVM :: CodeGen/AArch64/i128-fast-isel-fallback.ll
> | LLVM :: CodeGen/AArch64/illegal-float-ops.ll
> | LLVM :: CodeGen/AArch64/ldst-opt.ll
> | LLVM :: CodeGen/AArch64/neon-fpround_f128.ll
> | LLVM :: CodeGen/AArch64/ragreedy-csr.ll
> | LLVM :: CodeGen/AArch64/regress-tail-livereg.ll
> | LLVM :: CodeGen/AArch64/sincos-expansion.ll
> | LLVM :: CodeGen/AArch64/sincospow-vector-expansion.ll
> | 
> |   Expected Passes: 11001
> |   Expected Failures  : 80
> |   Unsupported Tests  : 156
> |   Unexpected Passes  : 18
> |   Unexpected Failures: 29
> | Makefile:107: recipe for target 'check-local' failed
> 
> on AMD64. One step further I guess.
Do you have the actual errors?
We should probably just silent/ignore these 29 tests.
This is the support of ARM64. I don't think that anybody is going to use
clang 3.5 to build on/to ARM64 using this version (3.6 is much better for ARM64)

Sylvestre


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

Bug#789875: needs to be removed

[Sylvestre Ledru]

Le 12/08/2015 09:30, Salvo Tomaselli a écrit :
> tags: wontfix
> thanks
>
>
> Libgit2 breaks API at every minor release.
>
> Subsurface insists on using it.
>
> Subsurface's upstream does not like distributions and will make packaging 
> more 
> and more difficult on purpose, to discourage distributions from packaging it.
>
> https://www.mail-archive.com/subsurface@subsurface-divelog.org/msg05634.html
>
> Honestly, there is nothing I can do, that doesn't involve forking subsurface.
>
> Sorry
>
:(
I reported bug #795267 for the removal.


Cheers,
Sylvestre




signature.asc
Description: OpenPGP digital signature

Bug#795267: RM: subsurface -- ROM; Upstream is making our work impossible on purpose

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

See https://www.mail-archive.com/subsurface@subsurface-divelog.org/msg05634.html
and bug #789875 for more information

Sylvestre

Bug#795238: subsurface: Please remove

[Sylvestre Ledru]

Le 12/08/2015 19:37, Christoph Anton Mitterer a écrit :
> On Wed, 2015-08-12 at 09:31 +0200, Salvo Tomaselli wrote:
>> upstream forked quite a lot of libraries.
> Which?
libgit, libmarble & libdivecomputer
>>  Packaging subsurface is
>> impossible.
> Other projects would do this as well and packaging them works
> nevertheless... and subsurface is already packaged, so it's definitely
> not impossible... o.O
I have been maintaining subsurface for a while. It was easy in the past,
it is much harder now...
>
>> It should be removed.
> absolutely not WTF?!
>
Thanks for this input,
Sylvestre

Bug#825504: clang-3.6: clang++-3.6 does not find libstdc++ headers on !linux

[Sylvestre Ledru]

Le 27/05/2016 à 12:19, Andreas Beckmann a écrit :
> Package: clang-3.6
> Version: 1:3.6.2-3
> Severity: important
>
> Hi,
>
> clang++-3.6 does not work properly on kfreebsd-amd64, and I'd expect the
> same happens on the other non-linux architectures, too:
>
> $ echo '#include ' | clang++-3.6 -v -x c++ -E - >/dev/null
> Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
> Target: x86_64-pc-kfreebsd-gnu
> Thread model: posix
>  "/usr/lib/llvm-3.6/bin/clang" -cc1 -triple x86_64-pc-kfreebsd-gnu -E 
> -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model 
> static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose 
> -mconstructor-aliases -munwind-tables -target-cpu x86-64 
> -target-linker-version 2.25.1 -v -dwarf-column-info -resource-dir 
> /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 -fdeprecated-macro 
> -fdebug-compilation-dir /home/anbe/pocl -ferror-limit 19 -fmessage-length 214 
> -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions 
> -fdiagnostics-show-option -fcolor-diagnostics -o - -x c++ -
> clang -cc1 version 3.6.2 based upon LLVM 3.6.2 default target 
> x86_64-pc-kfreebsd-gnu
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
>  /usr/include
> End of search list.
> :1:10: fatal error: 'iostream' file not found
> #include 
>  ^
> 1 error generated.
>
Does the same thing happen with 3.7? I remember fixing this kind of
issues in the past.
Thanks,
S

Bug#819475: [Pkg-rust-maintainers] Bug#819475: rustc not run depend on gcc 4.9.2

[Sylvestre Ledru]

Le 29/03/2016 à 11:23, wanglihe a écrit :
> Package: rustc
> Version: 1.7.0+dfsg1-1
> Severity: important
>
> Dear Maintainer,
>
> I added testing repo and just   apt install rustc, so the gcc tool chain
> remain at 4.9.2, and rustc can not compile any source code with error
> about cc, after I update gcc, the problem resolved.
What is the error ?

Thanks
S

Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging

[Sylvestre Ledru]

Le 24/03/2016 à 19:43, Brad King a écrit :
> On 03/24/2016 11:42 AM, Sylvestre Ledru wrote:
>>> CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include):
>>>   include could not find load file:
>> As you are much more familiar than me on this, would you mind proposing a 
>> patch?
> While I'm familiar with LLVM's CMake packaging infrastructure I'm not so
> much with debian packaging.  I'm not set up to try building the package
> myself but I can help you update
>
>  https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.8/
>
> as covered in the following sections.
many thanks. I will try to integrate that asap.

By the way, a side question, after the build with cmake, before the
"make install", is
it possible to remove the temporary files (*.o for example)?
The whole build requires a lot of spaces. 29G on my system.

Thanks
S

Bug#815006: Restore Iceweasel branding

[Sylvestre Ledru]

Le 06/04/2016 à 14:21, Paul Wise a écrit :
> On Wed, 2016-04-06 at 11:56 +, nord-stream wrote:
>
>> About Iceweasel branding restoration add-on:
> I'm willing to upload this to Debian if you package it properly.
> I expect it should take over the iceweasel transitional package?
I don't agree with this statement. I believe that people should get Firefox 
from now in Debian.
Debian users who wants to use Firefox on Debian have been "forced" to use 
Iceweasel, it wasn't a choice.
If people wants to get Iceweasel, they should install this theme.

Sylvestre

Bug#815006: Restore Iceweasel branding

[Sylvestre Ledru]

Le 06/04/2016 à 15:04, Paul Wise a écrit :
> On Wed, 2016-04-06 at 14:35 +0200, Sylvestre Ledru wrote:
>
>> If people wants to get Iceweasel, they should install this theme.
> Fair enough.
Thanks for your flexibility :)
>  What would you recommend as a package name? Options:
>
> xul-ext-iceweasel
> firefox-branding-iceweasel
> iceweasel-branding
>
The first one is too technical to me.

The two others are fine by me!

Sylvestre




signature.asc
Description: OpenPGP digital signature

Bug#820333: RFA: hubicfuse -- Support for mounting Hubic drive

[Sylvestre Ledru]

Package: wnpp
Severity: normal

I request an adopter for the hubicfuse package.

The package description is:
 HubicFuse is a FUSE application which provides access to Hubic's
 cloud files via a mount-point.

As I moved to dropbox, I am not longer using hubic. Therefor, my interest
for this product and my capability to test has strongly decreased.

Sylvestre

Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1~+rc1-1~exp1

[Sylvestre Ledru]

Hello,
Le 09/06/2016 à 15:15, antoine.pierlot-gar...@scle.fr a écrit :

Dear maintainer,

When using llvm-3.8-dev  1:3.8.1~+rc1-1~exp1, the bug is still not
completely fixed.

/usr/lib/llvm-3.8/share/llvm/cmake/LLVMExports.cmake still detects the
missing installation of the following library files:

 "/usr/lib/llvm-3.8/lib/libPollyISL.a"
 "/usr/lib/llvm-3.8/lib/libPolly.a"
 "/usr/lib/llvm-3.8/bin/sancov"

(Similar to section 3 of Brad King's message #20 at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819072#20 )

The first two are deleted during packaging, and the third one is
installed by clang-3.8, which is not a dependency of llvm-3.8-dev.

After commenting `libPolly*.a` checks from
`LLVMExports-relwithdebinfo.cmake` and installing clang-3.8,
`find_package(LLVM)` works fine.


Thanks for the feedback.

A patch would be appreciated, I don't have time to investigate this :/

Thanks
Sylvestre

Bug#827185: source:llvm-toolchain-snapshot: Enable a full bootstrap of clang

[Sylvestre Ledru]

Package: source
Severity: wishlist

For now, clang is built using gcc.
We should be able to build clang using clang using the classical bootstrap 
sequence.
This will probably require a bunch of changes on debian/rules.


Sylvestre

Bug#815006: Closing Renaming Iceweasel to Firefox

[Sylvestre Ledru]

Hello,

As firefox-esr is  available in oldstable and stable, I am closing this bug.

Many thanks to Mike for making all the changes!

Next step, icedove => thunderbird (bug #816679)

Sylvestre

PS: about the iceweasel-branding, I believe you should continue the
discussion in the itp bug (if any).

Bug#813798: llvm-toolchain-3.8: LLDB testsuite does not run correctly

[Sylvestre Ledru]

Le 08/05/2016 à 00:29, Pablo Oliveira a écrit :

Hi,

On Fri, 05 Feb 2016 12:18:02 +0100 Sylvestre Ledru
 wrote:

Package: llvm-toolchain-3.8
Severity: normal

Running lldb testsuite is mostly failing with:
[...]
ImportError: No module named _lldb

Probably caused by a missing symlink

Full log:
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.8&arch=i386&ver=1%3A3.8~%2Brc2-1~exp1&stamp=1454632881

S

Attached a patch against the current svn revision that fixes this
bug. The problem is that lldb/scripts/Python/finishSwigPythonLLDB.py
does not know about the -3.8.so.1 suffix we use and cannot link to the
correct liblldb.

Looks great, thanks.


Regards,

Pablo

PS: What is the pkg-llvm-team policy regarding patches: is it better to
submit them through the BTS or to apply them directly on the svn ?

I don't mind if you commit them yourself. Au contraire, you will get 
proper credit!



Sylvestre

Bug#819185: clang: please enable -fdebug-prefix-map support

[Sylvestre Ledru]

Le 24/03/2016 à 09:24, Daniel Kahn Gillmor a écrit :

Package: clang
Version: 1:3.7-34~exp1
Severity: wishlist
Tags: upstream patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
Control: forwarded -1 https://llvm.org/bugs/show_bug.cgi?id=24619

clang currently doesn't support -fdebug-prefix-map, but it's useful
when trying to make reproducible builds.

upstream has added this feature in svn (r250094):

  https://llvm.org/bugs/show_bug.cgi?id=24619

but it doesn't appear to be in debian yet.

Maybe it's in 3.8.0 ?  It would be great to have it available in
debian at any rate so that we can make builds reproducible independent
of where they're built.

The upstream patch is attached.

Sorry about the delay


A few things:
* it doesn't apply to the 3.7 branch (the rebase should be easy)
* Is it worth the trouble? 3.8 should be enough ?

Thanks

S

Bug#820930: octave: Missing ending curly brace for rotated text in tikz terminal

[Sylvestre Ledru]

Le 09/05/2016 à 09:48, Agustin Martin a écrit :

On Thu, May 05, 2016 at 04:21:02PM +0200, Agustin Martin wrote:

On Fri, Apr 15, 2016 at 10:01:05AM -0700, Mike Miller wrote:

On Wed, Apr 13, 2016 at 20:00:22 +0200, Agustin Martin wrote:

Dear Maintainer,

I have noticed a problem when rotated text is processed to a tikz file.
Seems that (noticed only in this case) an ending curly brace is missing.

...

Confirmed, this is actually a bug in the gl2ps library that should be
fixed when version 1.3.9 is packaged (untested).

Refer to the gl2ps upstream bug report [1] and patch [2]. As there's
nothing to be done in octave, I've reassigned to the libgl2ps0 package
which is still at 1.3.8.

[1]: https://geuz.org/trac/gl2ps/ticket/11
[2]: https://geuz.org/trac/gl2ps/changeset/601

Hi, maintainer,

Since gl2ps 1.3.9 seems to involve a transition, I have extracted the part
that is relevant to this bug report. Please see attached patch, minimally
tested in my system.

Please let me know what do you think about the change. Otherwise I will
upload a NMU with it.

Changes uploaded to DELAYED/7 as 1.3.8-1.3.


No need to delay it, please upload it now :)

S

Bug#827866: clang: __atomic_test_and_set provokes clang++ crash on aarch64-linux-gnu target

[Sylvestre Ledru]

Le 21/06/2016 à 23:26, Marco Milanese a écrit :
> Package: clang
> Version: 1:3.6-33
> Severity: normal
>
> Dear Maintainer,
>
> When I try to cross compile (target=aarch64-linux-gnu) the following C++ code,
> clang++ crashes:
could you try with 3.7 or 3.8?
Thanks
S

Bug#811682: FTBFS with GCC 6: could not convert a from x to y

[Sylvestre Ledru]

Le 26/06/2016 à 14:27, Gert Wollny a écrit :
> Control: tags -1 patch 
>
> Hello, 
>
> the attached patch fixes the reported compile error and also fixes the
> "narrowing conversion" errors that came up with g++-6.
>
> The package now builds with g++-6 (but it is not lintian-clean). 
>
> Best, 
> Gert 
Hello,

Are you sure?
It fails to build from source in unstable.

View.cc: In member function 'SmartPtr View::getCharAt(const
scaled&, const scaled&, CharIndex&, Point*, BoundingBox*) const':
View.cc:294:10: error: 'nullptr' was not declared in this scope
   return nullptr;

Thanks

S

Bug#828734: [iwyu] 3.8 recommends includes for things not used in file

[Sylvestre Ledru]

forwarded 828734 
https://github.com/include-what-you-use/include-what-you-use/issues/334
thanks

Le 27/06/2016 à 12:52, Franz Schrober a écrit :

Package: iwyu
Version: 3.8-1
Severity: important


It was noticed that the upgrade from 3.7 to 3.8 introduced a regression. iwyu
is now recommending includes for things which are nowhere used in a file.


Thanks.
I don't know how to fix that, I forwarded it to upstream

S

Bug#819072: closed by Sylvestre Ledru (Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1-1)

[Sylvestre Ledru]

Le 27/06/2016 à 19:52, Brad King a écrit :
> On 06/23/2016 09:36 AM, Debian Bug Tracking System wrote:
>> This is an automatic notification regarding your Bug report
>> which was filed against the llvm-3.8-dev package:
>>
>> #819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging
>>
>> It has been closed by Sylvestre Ledru .
> There is one remaining problem as of 3.8.1-1.
>
> In r1918 this change was made:
>
>   # Explicit debian/tmp since there are multiple declarations
>  -debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/*.cmake 
> usr/share/llvm-@LLVM_VERSION@/cmake/
>  +debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/*.cmake
>
> This is correct.  However, my suggestion to do that also stated
> that we need to add a symlink:
>
>  /usr/share/llvm-@LLVM_VERSION@/cmake -> 
> /usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake
>
> This symlink is missing and so CMake projects cannot find the package
> in default search locations.
>
> I'm not familiar enough with debian packaging infrastructure to know
> how to create this symlink and get it included in the llvm-3.8-dev
> package, but it should be pretty simple for those that know.
>
> Meanwhile the attached patch removes an unnecessary `sed` operation
> that no longer matches anything or has any effect.
>
> Thanks,
> -Brad
>
OK, many thanks.

looks like the same as https://llvm.org/bugs/show_bug.cgi?id=28325 ?

Thanks
S

Bug#829361: clang-3.8-doc: Fix the lintian warning 'privacy-breach-uses-embedded-file'

[Sylvestre Ledru]

Package: clang-3.8-doc
Severity: normal

Dear Maintainer,

A bunch of warnings are triggered by lintian about privacy:
usr/share/doc/clang-3.8-doc/html/AddressSanitizer.html You may use 
libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js?config=tex-ams-mml_htmlormml)
usr/share/doc/clang-3.8-doc/html/AttributeReference.html You may use 
libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js?config=tex-ams-mml_htmlormml)

We should fix them (on llvm-toolchain-snapshot too)

Sylvestre

Bug#820537: binutils: ld cannot link big binaries on mips/mipsel / llvm-toolchain-3.8: FTBFS on mips and mipsel

[Sylvestre Ledru]

tags 820537 + fixed pending
thanks


Using -gsplit-dwarf fixed the issue .

LLVM fails to build now with

../../../../lib/liblldbCore.a(DataExtractor.cpp.o):/usr/include/c++/5/bits/atomic_base.h:396:
 undefined reference to `__atomic_load_8'
../../../../lib/liblldbCore.a(DataExtractor.cpp.o):/usr/include/c++/5/bits/atomic_base.h:374:
 undefined reference to `__atomic_store_8'
../../../../lib/liblldbCore.a(DataExtractor.cpp.o):/usr/include/c++/5/bits/atomic_base.h:396:
 undefined reference to `__atomic_load_8'

Hopefully, enabling the link against lib atomic should be enough.
I updated the vcs but I won't upload it until two weeks (holidays), if
someone wants to try, go ahead!

Cheers,
Sylvestre

Bug#822057: gl2ps 1.3.9 released

[Sylvestre Ledru]

Le 20/04/2016 à 23:24, Nico Schlömer a écrit :
> Source: gl2ps
> Severity: wishlist
>
> GL2PS 1.3.9 has been released on Oct 17, 2015 [1]. The new VTK 7 (not yet in
> Debian) will require it, so it'd be great if we could bump the version here.
>
>
> [1] http://www.geuz.org/pipermail/gl2ps-announce/2015/22.html
I had a look and it requires a transition.
I don't have the bandwidth to manage that (I am not longer using gl2ps)

Sorry :/   
Sylvestre

Bug#822161: RFA: gl2ps

[Sylvestre Ledru]

Package: wnpp
Severity: normal

Hello,

I was interested gl2ps for Scilab. As I am not longer involved in Scilab, I 
don't think I will be doing a good job for gl2ps anymore.
This is a pretty easy library to maintain and upstream is very reactive and 
friendly.

Sylvestre

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

[Sylvestre Ledru]

Hello,
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 mailing list
> pkg-llvm-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

yes, this is fine. A patch would be appreciated as I don't have the
bandwidth for the next two weeks.

Sylvestre

Bug#822458: libjgraphx-java: new version and new upstream URL

[Sylvestre Ledru]

Hello,

Le 24/04/2016 à 19:39, ydir...@free.fr a écrit :

Package: libjgraphx-java
Version: 2.1.0.7-1

Homepage from control file and copyright file redirects to jgraphx github repo,
which is at v3.5.1.2.


FYI, I am not planning to work on this.

When I was managing it actively, upstream was breaking regularly the 
compatibility, making it very hard to follow (dependency like Scilab had 
to be updated too).


S

Bug#822813: libclang-common-3.7-dev: ASAN missing from package

[Sylvestre Ledru]

Le 27/04/2016 à 22:47, Douglas F. Calvert a écrit :

Package: libclang-common-3.7-dev
Version: 1:3.7.1-2
Severity: normal

Hello,

ASAN is not usable with clang-3.7:

/usr/bin/ld: cannot find 
/usr/lib/llvm-3.7/bin/../lib/clang/3.7.1/lib/linux/libclang_rt.asan-x86_64.a: 
No such file or directory


All of the other versioned clang-common-dev packages provide 
libclang_rt.asan-x86_64.a:

$apt-file search  libclang_rt.asan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.2/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.2/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.8-dev: 
/usr/lib/llvm-3.8/lib/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.8-dev: 
/usr/lib/llvm-3.8/lib/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a.syms
libclang-common-3.9-dev: 
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.9-dev: 
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.asan-x86_64.a.syms


Yes, this is expected. The build of asan was removed when using autoconf.
3.6 was still supported
3.8 migrated to cmake.

There is no plan to fix that. So, please switch to 3.8.
Sorry about that,
S

Bug#793752: clang-3.7: "inline" function in same file not found

[Sylvestre Ledru]

Hello,

Le 27/07/2015 00:02, Ph. Marek a écrit :
> Package: clang-3.7
> Version: 1:3.7~svn239806-1+b1
> Severity: normal
>
> Please fetch a checkout of r2474 of
> http://fsvs.tigris.org/svn/fsvs/branches/clang-3.7-bug
> and try to compile.
>
> The results are
> commit.o: In function `ci___send_user_props':
> commit.c:328: undefined reference to `send_a_prop'
> racallback.o: In function `cb___change_dir_prop':
> racallback.c:476: undefined reference to `cb___store_prop'
> racallback.o: In function `cb___change_file_prop':
> racallback.c:614: undefined reference to `cb___store_prop'
>
> but if the "inline" are removed (commit.c:244, racallback.c:296)
> the result is as expected.
>
It requires a login to checkout the repo.
Anyway, please attach a test case in the bug.

Thanks
S


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

Bug#748923: emscripten: New upstream version (1.16.0) available

[Sylvestre Ledru]

On 22/05/2014 12:05, Turo Lamminen wrote:
> Package: emscripten
> Version: 1.10.0~20140205~ef1e460-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> New upstream version (1.16.0) is available. Please consider packaging
> it.
> 
Yeah, except that now Emscripten used a patched version of LLVM:
https://github.com/kripken/emscripten/wiki/LLVM-Backend

I can upload a new version but all users will have to use the option
EMCC_FAST_COMPILER=0
I could hack to force that in the code but it requires some updates.

I will think about that (and don't hesitate if you have a better idea or
patch)

Sylvestre


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

Bug#753956: [emscripten] Some sources are not included in your package

[Sylvestre Ledru]

On 06/07/2014 20:50, bastien ROUCARIES wrote:
> Package: emscripten
> Version:  1.10.0~20140205~ef1e460-1
> user: lintian-ma...@debian.org
> usertags: source-is-missing
> severity: serious
> X-Debbugs-CC: ftpmas...@debian.org
>
> Hi,
>
> Your package seems to include some files that lack sources
> in prefered forms of modification:
>
> src/emscripten-source-map.min.js
> tools/crunch-worker.js
>
> The following are false positive and you should supply override (source 
> location is not found by search & replace)
> third_party/lzma.js/lzma-decoder.js
> third_party/lzma.js/lzma-full.js
> third_party/websockify/include/web-socket-js/WebSocketMain.swf
> third_party/websockify/include/web-socket-js/swfobject.js
> third_party/websockify/include/web-socket-js/src/WebSocketMain.swf
> third_party/websockify/include/web-socket-js/src/swfobject.js
>
What about updating lintian to avoid false positives?

Sylvestre


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

Bug#753965: RM: llvm-toolchain-3.3 -- ROM; Replaced by llvm-toolchain-3.4

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

Hello

I would like to remove this package from Debian before jessie
llvm-toolchain-3.4 now replaces it.

Thanks,
Sylvestre


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

Bug#753967: ldc: Please publish the sources in a VCS

[Sylvestre Ledru]

Package: ldc
Severity: wishlist

Hello,

Could you publish the sources of the VCS (on alioth if possible) ?
and also update the VCS- Flags

Thanks
Sylvestre

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Sylvestre Ledru]

Source: julia
Severity: important

Dear Maintainer,

I would like to remove llvm-toolchain-3.3 from the archive ASAP.
Could you switch to llvm-3.4-dev?

Thanks
Sylvestre

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#753971: [Pkg-julia-devel] Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Sylvestre Ledru]

On 06/07/2014 23:55, Sébastien Villemot wrote:
> Control: tags -1 + upstream
>
> Hi Sylvestre,
>
> Le dimanche 06 juillet 2014 à 19:39 +0200, Sylvestre Ledru a écrit :
>> Source: julia
>> Severity: important
>> I would like to remove llvm-toolchain-3.3 from the archive ASAP.
>> Could you switch to llvm-3.4-dev?
> Unfortunately upstream does not officially support LLVM 3.4 yet, not
> even for the latest development sources (it seems to compile, but there
> are issues, like https://github.com/JuliaLang/julia/issues/6369 ). For
> the current stable release (0.2) that is in sid, it is even worse, since
> julia FTBFS due to LLVM API changes.
OK. thanks for the information.
> So at the very least I have to package a development snapshot. I need to
> get several new build dependencies through NEW, so it will take some
> time. Hopefully that will be done before the jessie freeze.
>
Yeh. I am not planning to have llvm 3.3 in Jessie. :/

Sylvestre




signature.asc
Description: OpenPGP digital signature

Bug#753971: [Pkg-julia-devel] Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Sylvestre Ledru]

On 07/07/2014 00:12, Sébastien Villemot wrote:
> Le dimanche 06 juillet 2014 à 23:55 +0200, Sébastien Villemot a écrit :
>
>
>> Le dimanche 06 juillet 2014 à 19:39 +0200, Sylvestre Ledru a écrit :
>>> Source: julia
>>> Severity: important
>>> I would like to remove llvm-toolchain-3.3 from the archive ASAP.
>>> Could you switch to llvm-3.4-dev?
>> Unfortunately upstream does not officially support LLVM 3.4 yet, not
>> even for the latest development sources (it seems to compile, but there
>> are issues, like https://github.com/JuliaLang/julia/issues/6369 ). For
>> the current stable release (0.2) that is in sid, it is even worse, since
>> julia FTBFS due to LLVM API changes.
>>
>> So at the very least I have to package a development snapshot. I need to
>> get several new build dependencies through NEW, so it will take some
>> time. Hopefully that will be done before the jessie freeze.
> Looking at https://github.com/JuliaLang/julia/issues/6757, it seems that
> even the next major release of Julia (0.3) will still require LLVM 3.3
> to be fully functional.
>
> Would that be acceptable for you to ship LLVM 3.3 in Jessie?
>
Not really ... I am planning to ship with llvm 3.4 & 3.5.
I don't want to third instance just for a single package.

Sylvestre




signature.asc
Description: OpenPGP digital signature

Bug#753971: [Pkg-julia-devel] Bug#753971: Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Sylvestre Ledru]

On 07/07/2014 09:10, Viral Shah wrote:
> Julia support for LLVM 3.4 is only experimental and we will probably go
> directly to 3.5.
Do you have an eta on Julia-on-llvm-3.5 ? LLVM 3.5 branching is probably
going to happen this week.

> Is it an option to include 3.3 in the Julia package in that case?
> 
No. It had a maintenance burden on Debian that we don't want.

Sylvestre


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

Bug#754045: libedit2: Broken rl_callback_read_char() in libedit's readline emulation

[Sylvestre Ledru]

On 07/07/2014 02:40, Federico G. Schwindt wrote:
> Package: libedit2
> Version: 3.1-20140213-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Since the libedit2 update to 3.1- rl_callback_read_char() is broken.
> I've raised a bug report with upstream (NetBSD) here:
> 
>   http://gnats.netbsd.org/48957
> 
> This is now fixed. Diff available at:
> 
>   
> http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/readline.c.diff?r1=1.110&r2=1.111&sortby=date
OK. I updated the VCS and it will be fixed in the next upload.

> Also it'd be nice if you bump LIBEDIT_MAJOR, LIBEDIT_MINOR or both to
> match what the current versioning in the package, something that was
> apparently missed when the version was bumped from 2.11- to 3.1-.
> 
Please
1 issue = 1 bug

Especially when they are different like here.


On the issue here, I know this but there were no reason to update the
ABI number.
Transition from a package name to the other is a huge work on a library
like libedit. So, I won't rename libedit2 to libedit3.

Sylvestre


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

Bug#754045: libedit2: Broken rl_callback_read_char() in libedit's readline emulation

[Sylvestre Ledru]

On 07/07/2014 11:29, Federico Schwindt wrote:
> 
> On the issue here, I know this but there were no reason to update the
> ABI number.
> Transition from a package name to the other is a huge work on a library
> like libedit. So, I won't rename libedit2 to libedit3.
> 
> 
> I'm not suggesting that but bumping the major or at least the minor.
> Before libedit2 was updated the code was from 2008, now it's from 2014;
> I think 6 years worth of changes justify this but I will open a new report.
Why not reporting this bug upstream?

Sylvestre


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

Bug#754079: nmu: lightspark_0.7.2-3.1

[Sylvestre Ledru]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu lightspark_0.7.2-3.1 . ALL . -m "Rebuild against the new version 
llvm-defaults (llvm 3.4)"

Thanks
Sylvestre


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

Bug#754080: nmu: ldc_1:0.13.0-1

[Sylvestre Ledru]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu ldc_1:0.13.0-1 . ALL . -m "Rebuild against the new version llvm-defaults 
(llvm 3.4)"

Thanks,
S


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

Bug#754081: vim-youcompleteme

[Sylvestre Ledru]

As discussed on IRC, I forgot:
nmu vim-youcompleteme_0+20140207+git18be5c2-1  . ALL . -m "Rebuild
against the new version llvm-defaults (llvm 3.4)"


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

Bug#753971: [Pkg-julia-devel] Bug#753971: Bug#753971: Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Sylvestre Ledru]

On 07/07/2014 16:44, Viral Shah wrote:
> On 07-Jul-2014, at 1:02 am, Sylvestre Ledru  wrote:
> 
>> On 07/07/2014 09:10, Viral Shah wrote:
>>> Julia support for LLVM 3.4 is only experimental and we will probably go
>>> directly to 3.5.
>> Do you have an eta on Julia-on-llvm-3.5 ? LLVM 3.5 branching is probably
>> going to happen this week.
> 
> We are currently in our julia 0.3 release cycle, and just about to release 
> 0.3-rc1. We already have support llvm-3.5 svn, but the julia release that 
> will use llvm 3.5 will be 0.4 is expected in December. 
The Debian freeze in planed in November. That is going to be too late.

> LLVM 3.4 changed the APIs (MCJIT and such) and also had a bunch of bugs that 
> made it difficult for us to use it. In fact we even have to apply patches to 
> LLVM 3.3 (but can work around those bugs with slightly worse code generation 
> in some cases, so that stock LLVM 3.3 can be used). Most of our patches are 
> in 3.5, and we should be able to move to it for our next release.
If you can provide patches separately from the 0.3 release, I guess that
would make Sébastien happy.

>>> Is it an option to include 3.3 in the Julia package in that case?
>>>
>> No. It had a maintenance burden on Debian that we don't want.
> 
> I really wish we can find a way.
Me too but 3.3 is already more than an year old. It is unmaintained
(unlike 3.4 which has point releases) and 3.5 will be part of Debian Jessie.
I cannot afford to maintain 4 versions of LLVM in parallel (3.3, 3.4,
3.5 and snapshot).

Sylvestre


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