Bug#1067113: libhiredis-dev: cmake config incompatible with upstream

[Sylvain Joubert]

Package: libhiredis-dev
Version: 1.2.0-6
Severity: normal
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

The CMake config provided by this package seems incompatible with the upstream
one.
Currently, the package provides data under the name "Hiredis" with a capital
leading H, while upstream is named "hiredis" lowercase
".../cmake/Hiredis/HiredisConfig{,Version}.cmake" vs.
".../cmake/hiredis/hiredis-config.cmake" (see
https://github.com/redis/hiredis/blob/master/CMakeLists.txt#L137-L150)

This means that a client CMake project can't switch transparently between an
Debian install and a custom cmake build of hiredis.

Could you rename the cmake configuration provided by Debian to match upstream,
or even build hiredis using the official CMake support?

Thanks.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libhiredis-dev depends on:
ii  libhiredis1.1.0  1.2.0-6

libhiredis-dev recommends no packages.

libhiredis-dev suggests no packages.

-- no debconf information

Bug#1043011: clazy: Incompatibility with gcc/libstdc++ version 13

[Sylvain Joubert]

Package: clazy
Version: 1.11-4
Severity: important
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

Using clazy on Debian testing with the newly updated libstdc++ to version 13 I
now get the following error:

/usr/bin/../lib/gcc/x86_64-linux-
gnu/13/../../../../include/c++/13/chrono:2320:48: error: call to consteval
function 'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant
expression
static constexpr unsigned fractional_width = {_S_fractional_width()};
  ^

I believe this is due to the use of an older clang/llvm version (14) that does
not properly/completely implements 'consteval'.
Updating the used clang/llvm to a newer version should fix the issue.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clazy depends on:
ii  clang-141:14.0.6-12
ii  libc6   2.37-6
ii  libclang-cpp14  1:14.0.6-12
ii  libgcc-s1   13.1.0-9
ii  libllvm14   1:14.0.6-12
ii  libstdc++6  13.1.0-9

clazy recommends no packages.

clazy suggests no packages.

-- no debconf information

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Sylvain Joubert]

Ok, I just figured out why you probably can't reproduce the issue: you need
to use clang as a compiler.
If you use `CXX=clang++-14 cmake [...]` as a configure command line you'll
likely trigger the error.

And the required package providing OpenMP for clang must match the clang
version used: if I install libomp-13-dev while using clang++-14 for example
I'll still get the error.

With this additional info I get that the issue is triggered with a
non-default setup, so I'm not sure how or even if it can be fixed
correctly. Especially given that the proper dependency is heavily dependent
on the clang version used/installed.
Given that understanding I'd be fine with leaving things as is. And maybe
it's the upstream MathGL2Config.cmake that needs a rework to deal more
easily with various setups.

Anyway, thanks for taking a look.

Le mer. 31 août 2022 à 10:03, Sylvain Joubert  a
écrit :

> Hi,
> Here is the minimal CMakeLists.txt that reproduces the issue:
>
> cmake_minimum_required(VERSION 3.22.0)
> project(mgl_test LANGUAGES CXX)
> find_package(MathGL2 REQUIRED)
>
> If the packages libomp-dev and libomp-XX-dev that it drags (libomp-11-dev
> on stable, libomp-14-dev on my testing setup) are not installed I get the
> initial reported error.
>
>
> Le mar. 30 août 2022 à 22:03, Rafael Laboissière  a
> écrit :
>
>> Control: tags -1 moreinfo
>>
>> * Sylvain Joubert  [2022-03-02 11:17]:
>>
>> >  Package: libmgl-dev
>> >  Version: 8.0.1-1
>> >  Severity: normal
>> >
>> > Dear Maintainer,
>> >
>> > Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm
>> facing the
>> > following error:
>> >
>> >  CMake Error at
>> /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
>> >  (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
>> OpenMP_CXX_LIB_NAMES)
>> >  Call Stack (most recent call first):
>> >  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
>> >  (_FPHSA_FAILURE_MESSAGE)
>> >   /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
>> >  (find_package_handle_standard_args)
>> >   /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
>> >  (find_package)
>> >   /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
>> >  [...]
>> >
>> > It appears the libmgl-dev package is missing a dependency on an OpenMP
>> > related package. Installing libomp-dev fixes the issue though I'm not
>> > sure this is the correct package to depend on.
>>
>> Thank you for the bug report.
>>
>> Could you please provide an example that trigger the bug? For
>> inspiration, look at Bug #1004218 [1] or #1004219 [2].
>>
>> Best,
>>
>> Rafael Laboissière
>>
>>   [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218
>>   [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219
>>
>

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Sylvain Joubert]

Hi,
Here is the minimal CMakeLists.txt that reproduces the issue:

cmake_minimum_required(VERSION 3.22.0)
project(mgl_test LANGUAGES CXX)
find_package(MathGL2 REQUIRED)

If the packages libomp-dev and libomp-XX-dev that it drags (libomp-11-dev
on stable, libomp-14-dev on my testing setup) are not installed I get the
initial reported error.


Le mar. 30 août 2022 à 22:03, Rafael Laboissière  a
écrit :

> Control: tags -1 moreinfo
>
> * Sylvain Joubert  [2022-03-02 11:17]:
>
> >  Package: libmgl-dev
> >  Version: 8.0.1-1
> >  Severity: normal
> >
> > Dear Maintainer,
> >
> > Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm
> facing the
> > following error:
> >
> >  CMake Error at
> /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
> >  (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
> OpenMP_CXX_LIB_NAMES)
> >  Call Stack (most recent call first):
> >  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
> >  (_FPHSA_FAILURE_MESSAGE)
> >   /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
> >  (find_package_handle_standard_args)
> >   /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
> >  (find_package)
> >   /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
> >  [...]
> >
> > It appears the libmgl-dev package is missing a dependency on an OpenMP
> > related package. Installing libomp-dev fixes the issue though I'm not
> > sure this is the correct package to depend on.
>
> Thank you for the bug report.
>
> Could you please provide an example that trigger the bug? For
> inspiration, look at Bug #1004218 [1] or #1004219 [2].
>
> Best,
>
> Rafael Laboissière
>
>   [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218
>   [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219
>

Bug#1014064: libqpid-proton-cpp12-dev: Missing CMake config files

[Sylvain Joubert]

Package: libqpid-proton-cpp12-dev
Version: 0.37.0-1+b1
Severity: normal
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

While the pkg-config *.pc files are provided by this package, the relevant
CMake config files are not.
This make the library impossible to use in a standard CMake way (using
find_package)

I believe the same issue also applies to the libqpid-proton11-dev package

The missing files should be in /usr/lib/cmake/ProtonCpp/ and in
/usr/lib/cmake/Proton/ for libqpid-proton11-dev

Sylvain.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libqpid-proton-cpp12-dev depends on:
ii  libqpid-proton-cpp12  0.37.0-1+b1
ii  libqpid-proton11-dev  0.37.0-1+b1

libqpid-proton-cpp12-dev recommends no packages.

libqpid-proton-cpp12-dev suggests no packages.

-- no debconf information

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Sylvain Joubert]

Package: libmgl-dev
Version: 8.0.1-1
Severity: normal
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm facing the
following error:

CMake Error at
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
  Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
(find_package_handle_standard_args)
  /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
  [...]

It appears the libmgl-dev package is missing a dependency on an OpenMP related
package.
Installing libomp-dev fixes the issue though I'm not sure this is the correct
package to depend on.

Thanks,
Sylvain


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmgl-dev depends on:
ii  libgl-dev 1.4.0-1
ii  libgsl-dev2.7.1+dfsg-3
ii  libmgl-fltk8  8.0.1-1
ii  libmgl-glut8  8.0.1-1
ii  libmgl-mpi8   8.0.1-1
ii  libmgl-qt5-8  8.0.1-1
ii  libmgl-wnd8   8.0.1-1
ii  libmgl-wx88.0.1-1
ii  libmgl8   8.0.1-1
ii  libpng-dev1.6.37-3

libmgl-dev recommends no packages.

libmgl-dev suggests no packages.

-- no debconf information

Bug#996551: llvm-13-dev: Missing dependency to libomp-13-dev

[Sylvain Joubert]

Package: llvm-13-dev
Version: 1:13.0.0-6
Followup-For: Bug #996551
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

I believe this bug still exists in version 1:13.0.0-6 with the same error.
With a quick glance at the patch/fix I believe the regex that comments the
relevant
line is at fault (using 'omp-device-info' while the actual file/target name is
'llvm-omp-device-info')


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700,
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages llvm-13-dev depends on:
ii  libc6  2.32-4
ii  libclang-cpp13 1:13.0.0-6
ii  libffi-dev 3.4.2-3
ii  libgcc-s1  11.2.0-9
ii  libllvm13  1:13.0.0-6
ii  libncurses-dev [libtinfo-dev]  6.2+20201114-4
ii  libstdc++6 11.2.0-9
ii  libtinfo-dev   6.2+20201114-4
ii  libxml2-dev2.9.12+dfsg-5
ii  libz3-dev  4.8.12-1+b1
ii  llvm-131:13.0.0-6
ii  llvm-13-tools  1:13.0.0-6

llvm-13-dev recommends no packages.

llvm-13-dev suggests no packages.

Bug#996551: llvm-13-dev: Missing dependency to libomp-13-dev

[Sylvain Joubert]

Package: llvm-13-dev
Version: 1:13.0.0-5
Severity: important
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

With the recent move of llvm-omp-device-info from llvm-X to libomp8-dev, done
in llvm-toolchain-13 (1:13.0.0-4),
this package should now depend on libomp-X-dev

The current situation is that llvm-X-dev references llvm-omp-device-info as
part of an installed targets in its cmake
configuration, but since it no longer provides that file any attempt to use the
LLVM cmake package results in an error:

CMake Error at /usr/lib/llvm-13/lib/cmake/llvm/LLVMExports.cmake:1501
(message):
  The imported target "llvm-omp-device-info" references the file
 "/usr/lib/llvm-13/bin/llvm-omp-device-info"
  but this file does not exist.  Possible reasons include:
  * The file was deleted, renamed, or moved to another location.
  * An install or uninstall procedure did not complete successfully.
  * The installation package was faulty and contained
 "/usr/lib/llvm-13/lib/cmake/llvm/LLVMExports.cmake"
  but not all the files it references.

Manually installing libomp-X-dev fixes the problem.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700,
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages llvm-13-dev depends on:
ii  libc6  2.32-4
ii  libclang-cpp13 1:13.0.0-5
ii  libffi-dev 3.4.2-2
ii  libgcc-s1  11.2.0-9
ii  libllvm13  1:13.0.0-5
ii  libncurses-dev [libtinfo-dev]  6.2+20201114-4
ii  libstdc++6 11.2.0-9
ii  libtinfo-dev   6.2+20201114-4
ii  libxml2-dev2.9.12+dfsg-5
ii  libz3-dev  4.8.12-1+b1
ii  llvm-131:13.0.0-5
ii  llvm-13-tools  1:13.0.0-5

llvm-13-dev recommends no packages.

llvm-13-dev suggests no packages.

Bug#904446: clang-6.0: fails to link a sanitized binary with gold

[Sylvain Joubert]

Package: clang-6.0
Version: 1:6.0.1-2
Severity: important

Dear Maintainer,

First, I'm not really sure clang is at fault here since this issue requires a
specific combination involving the clang++ compiler, the gold linker and the
sanitizers options.
Basically, with a specific combination of these tools the link step produces a
warning, which may result in a link error if '-Wl,--fatal-warnings' is used.

  $ cat main.cpp
  int main(){ return 0; }

  $ /usr/bin/clang++-6.0 -o main.o -c main.cpp -fsanitize=address

  $ /usr/bin/clang++-6.0 -o main main.o -fsanitize=address -fuse-ld=gold
  /usr/bin/ld.gold: warning: discarding version information for
__libc_stack_end@GLIBC_2.2.5, defined in unused shared library
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (linked with --as-needed)

* Using clang-6.0 (as a C compiler) or clang++-7 (1:7~svn331965-1) does not
solve the issue
* Using g++-8 instead of clang++-6.0 works fine
* Using '-fuse-ld=bfd', '-fuse-ld=lld' or no flags (bfd default) works fine
* Using another ('undefined', 'thread' or 'memory') sanitizer is also broken
while no sanitizers works fine

Sylvain



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages clang-6.0 depends on:
ii  binutils 2.31.1-1
ii  libc62.27-5
ii  libc6-dev2.27-5
ii  libclang-common-6.0-dev  1:6.0.1-2
ii  libclang1-6.01:6.0.1-2
ii  libgcc-7-dev 7.3.0-25
ii  libgcc1  1:8.1.0-10
ii  libjsoncpp1  1.7.4-3
ii  libllvm6.0   1:6.0.1-2
ii  libobjc-7-dev7.3.0-25
ii  libstdc++-7-dev  7.3.0-25
ii  libstdc++6   8.1.0-10

Versions of packages clang-6.0 recommends:
ii  libomp-dev6.0.1-1
ii  llvm-6.0-dev  1:6.0.1-2
ii  python2.7.15-3

Versions of packages clang-6.0 suggests:
pn  clang-6.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#880952: maven: Version display does not disable bold/color output in non-interactive context

[Sylvain Joubert]

Source: maven
Followup-For: Bug #880952

I've checked upstream (which I should have done first) and it seems version
3.5.2 has fixed the issue (at least the piped one).

So I guess this issue can be turned into an upgrade to 3.5.2 wishlist.

Thanks.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'stable-updates'), (980, 'testing'), 
(970, 'stable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#880952: maven: Version display does not disable bold/color output in non-interactive context

[Sylvain Joubert]

Package: maven
Version: 3.5.0-6
Severity: normal

Dear Maintainer,

The command line 'mvn -v' outputs its first line in bold, which is fine in
interactive contexts.
However, it still outputs bold in a non-interactive context such as piped into
another command or called from a script/3rd-party tool to be processed.

The following command 'mvn -v | cat' should not output bold text.
Also note that, in my opinion, 'mvn -v -B' should also disable bold/color
output, but don't.

Sylvain



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages maven depends on:
ii  default-jre-headless [java7-runtime-headless]2:1.8-59
ii  libjansi-java1.16-1
ii  libmaven3-core-java  3.5.0-6
ii  openjdk-8-jre-headless [java7-runtime-headless]  8u151-b12-1

maven recommends no packages.

maven suggests no packages.

-- no debconf information

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

[Sylvain Joubert]

Package: clang-4.0
Version: 1:4.0.1~+rc1-1
Followup-For: Bug #862328

Hi,

After some digging, here is what I've come up with:

1- Dependencies

I think that ClangConfig.cmake (and the symlinks,... described above) and its
two sibling files should be provided by libclang-x.y-dev not by clang-x.y.
Most of the targets provided by this CMake file are installed with
libclang-x.y-dev so that makes much more sense (and LLVMConfig.cmake is
provided by llvm-x.y-dev)
However, some target artifacts are provided by other packages as well:
- clang (executable) by clang-x.y
- clang-format (executable) by clang-format-x.y

If these artifacts are not installed during configure, CMake will error-
complain about that.
I'm not really sure what's the best approach here but, as is, the package
providing ClangConfig.cmake must depends on clang-x.y and clang-format-x.y in
order to work.

2- Fixing find_package(Clang)

Install ClangConfig.cmake and siblings in /usr/lib/llvm-x.y/lib/cmake/clang
(instead of /usr/share/llvm-x.y/cmake)
Add a symlink /usr/share/clang-x.y/cmake -> /usr/lib/llvm-x.y/lib/cmake/clang

This matches what's done for LLVMConfig.cmake
This way find_package(Clang) can automatically find the config files.
To be consistent with LLVMConfig.cmake the symlink can instead be put in
/usr/lib/clang-x.y/cmake

3- Fixing CLANG_INSTALL_PREFIX

Apply the attached patch (fix-cmake-clang-confix.patch based on the 5.0
snapshot) to ClangConfig.cmake in the clang sources to fix the prefix location

With that ClangConfig.cmake and siblings can correctly compute the path of the
target artifacts

4- Fixing clang executable name

The targets files expect the clang executable to be named and located in
/usr/lib/llvm-x.y/bin/clang-x.y but the rules file (line 374) strips its
version suffixes.

I'm not sure why this was done but I guess we can either:
- not rename the executable (and fix /usr/bin/clang-x.y symlink and maybe
others)
- fix the ClangTargets-*.cmake file post generation to strip the version suffix


With these changes, one should be able to use the provided ClangConfig.cmake
and its targets.
I'm not really able to test that much more, nor provide a full patch for the
packaging repo but I can test any .deb that would have such fixes (including
the 5.0 snapshots).

Regards,
Sylvain



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-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 clang-4.0 depends on:
ii  binutils 2.28-4
ii  libc62.24-10
ii  libc6-dev2.24-10
ii  libclang-common-4.0-dev  1:4.0.1~+rc1-1
ii  libclang1-4.01:4.0.1~+rc1-1
ii  libgcc-6-dev 6.3.0-16
ii  libgcc1  1:6.3.0-16
ii  libjsoncpp1  1.7.4-3
ii  libllvm4.0   1:4.0.1~+rc1-1
ii  libobjc-6-dev6.3.0-16
ii  libstdc++-6-dev  6.3.0-16
ii  libstdc++6   6.3.0-16

Versions of packages clang-4.0 recommends:
ii  llvm-4.0-dev  1:4.0.1~+rc1-1
ii  python2.7.13-2

Versions of packages clang-4.0 suggests:
pn  clang-4.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information
diff --git a/cmake/modules/CMakeLists.txt b/cmake/modules/CMakeLists.txt
index be6d1d7257..b97afbf7c0 100644
--- a/cmake/modules/CMakeLists.txt
+++ b/cmake/modules/CMakeLists.txt
@@ -28,16 +28,7 @@ set(CLANG_CONFIG_LLVM_CMAKE_DIR)
 set(CLANG_CONFIG_EXPORTS_FILE)
 
 # Generate ClangConfig.cmake for the install tree.
-set(CLANG_CONFIG_CODE "
-# Compute the installation prefix from this LLVMConfig.cmake file location.
-get_filename_component(CLANG_INSTALL_PREFIX \"\${CMAKE_CURRENT_LIST_FILE}\" 
PATH)")
-# Construct the proper number of get_filename_component(... PATH)
-# calls to compute the installation prefix.
-string(REGEX REPLACE "/" ";" _count "${CLANG_INSTALL_PACKAGE_DIR}")
-foreach(p ${_count})
-  set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE}
-get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" 
PATH)")
-endforeach(p)
+set(CLANG_CONFIG_CODE "set(CLANG_INSTALL_PREFIX \"${CMAKE_INSTALL_PREFIX}\")")
 set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/${CLANG_INSTALL_PACKAGE_DIR}")
 set(CLANG_CONFIG_LLVM_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}")
 set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake")

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

[Sylvain Joubert]

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

Considering the following CMake script:

cmake_minimum_required(VERSION 3.2)
project(clangconfig)
find_package(Clang REQUIRED)

one gets:

CMake Error at CMakeLists.txt:3 (find_package):
  By not providing "FindClang.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Clang", but
  CMake did not find one.

  Could not find a package configuration file provided by "Clang" with any of
  the following names:

ClangConfig.cmake
clang-config.cmake

  Add the installation prefix of "Clang" to CMAKE_PREFIX_PATH or set
  "Clang_DIR" to a directory containing one of the above files.  If "Clang"
  provides a separate development package or SDK, be sure it has been
  installed.

Additionnally, when explicitly providing Clang_DIR with
/usr/share/llvm-4.0/cmake, one gets:

CMake Error at /usr/share/llvm-4.0/cmake/ClangConfig.cmake:17 (include):
  include could not find load file:

/usr/lib/cmake/clang/ClangTargets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:3 (find_package)

I'm guessing some paths needs to be updated in order to handle the Debian
repackaging.

Sylvain



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-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 clang-4.0 depends on:
ii  binutils 2.28-4
ii  libc62.24-10
ii  libc6-dev2.24-10
ii  libclang-common-4.0-dev  1:4.0.1~+rc1-1
ii  libclang1-4.01:4.0.1~+rc1-1
ii  libgcc-6-dev 6.3.0-16
ii  libgcc1  1:6.3.0-16
ii  libjsoncpp1  1.7.4-3
ii  libllvm4.0   1:4.0.1~+rc1-1
ii  libobjc-6-dev6.3.0-16
ii  libstdc++-6-dev  6.3.0-16
ii  libstdc++6   6.3.0-16

Versions of packages clang-4.0 recommends:
ii  llvm-4.0-dev  1:4.0.1~+rc1-1
ii  python2.7.13-2

Versions of packages clang-4.0 suggests:
pn  clang-4.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#834492: clang-3.9: "non-virtual thunk" abi_tag mangling is different from g++

[Sylvain Joubert]

2016-08-16 11:34 GMT+02:00 Sylvestre Ledru :

> You could report this bug upstream?
> http://llvm.org/bugs/
>

Done: https://llvm.org/bugs/show_bug.cgi?id=28997
Though, I'm not sure how to appropriately mark the Debian bug to link to
the upstream bug.

Bug#834492: clang-3.9: "non-virtual thunk" abi_tag mangling is different from g++

[Sylvain Joubert]

Package: clang-3.9
Version: 1:3.9~+rc1-1~exp1
Severity: important

Dear Maintainer,

The new mangling behavior of clang++ for GCC abi_tag attribute seems to be
different from the g++ one on some edge cases.

Consider the following code:
$ cat classes.hpp
#include 

struct Mother
{
  virtual ~Mother() {};
  int bar;
};

struct Father
{
  virtual std::string get_foo()  = 0;
};

class Derived:
  public Mother,
  public Father
{
public:
  std::string get_foo();
};

$ cat classes.cpp
#include "classes.hpp"

std::string Derived::get_foo() { return ""; }

$ cat main.cpp
#include "classes.hpp"

struct Final:
  public Derived
{
};

int main()
{
  Final().get_foo();
}

When compiling the classes with clang++ and trying to link the executable with
g++ one gets the following link error:
$ clang++-3.9 -c classes.cpp && g++-5 main.cpp classes.o
/tmp/cchpctTt.o:main.cpp:vtable for Final : erreur : référence à « non-
virtual thunk to Derived::get_foo() » non définie
collect2: error: ld returned 1 exit status

And it seems this symbol is mangled differently by clang++ and g++:
$ clang++-3.9 -c classes.cpp && nm -C classes.o | grep get_foo
 T Derived::get_foo[abi:cxx11]()
0070 T non-virtual thunk to Derived::get_foo[abi:cxx11]()

$ g++-5 -c classes.cpp && nm -C classes.o | grep get_foo
 T Derived::get_foo[abi:cxx11]()
0065 T non-virtual thunk to Derived::get_foo()



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-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 clang-3.9 depends on:
ii  binutils 2.26.1-1
ii  libc62.23-4
ii  libc6-dev2.23-4
ii  libclang-common-3.9-dev  1:3.9~+rc1-1~exp1
ii  libclang1-3.91:3.9~+rc1-1~exp1
ii  libgcc-6-dev 6.1.1-10
ii  libgcc1  1:6.1.1-10
ii  libllvm3.9   1:3.9~+rc1-1~exp1
ii  libobjc-6-dev6.1.1-10
ii  libstdc++-6-dev  6.1.1-10
ii  libstdc++6   6.1.1-10

Versions of packages clang-3.9 recommends:
ii  llvm-3.9-dev  1:3.9~+rc1-1~exp1
ii  python2.7.11-2

Versions of packages clang-3.9 suggests:
pn  clang-3.9-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#800460: mathgl: Test program fails to build, syntax error in header

[Sylvain Joubert]

Le 15/04/2016 21:37, Dimitrios Eftaxiopoulos a écrit :


C++11 features have been disabled at configuration time, so the package
builds without enabling theese features. Hence I cannot see the point of using
the compilation option -std=cpp.



I understand that C++11 have been disabled to make mathgl compiles fine 
by Debian. And I'm fine with that.


However, the -std=c++11 option is not for mathgl, it is required by *my* 
code, i.e. user code that uses mathgl. And, that, I cannot not change.


I know that Debian does not (yet) compile its packages with the C++11 
options but using it in user code is quite common for a while now.
In the current state of the package, one cannot use the mathgl library 
with C++11 code wich is, in my opinion (and at least in my use case) a 
big problem.


Thanks,
Sylvain

Bug#800460: mathgl: Test program fails to build, syntax error in header

[Sylvain Joubert]

Package: libmgl-dev
Version: 2.3.4-1+b1
Followup-For: Bug #800460

Dear Maintainer,

Your last test example effectively compiles fine.
However, that was not the exact repro steps of the bug report.

Compiling in C++11 mode still fails.
$ g++ -lmgl -std=c++11 test.cpp

I have checked the /usr/include/mgl2/config.h file but I still see the two
defines at '1' lines 22 and 27

Thanks for your time,
Sylvain



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-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 libmgl-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]  11.1.2-1
ii  libgsl-dev   2.1+dfsg-2
ii  libmgl-fltk7.4.1 2.3.4-1+b1
ii  libmgl-glut7.4.1 2.3.4-1+b1
ii  libmgl-mpi7.4.1  2.3.4-1+b1
ii  libmgl-qt5-7.4.1 2.3.4-1+b1
ii  libmgl-wnd7.4.1  2.3.4-1+b1
ii  libmgl-wx7.4.1   2.3.4-1+b1
ii  libmgl7.4.1  2.3.4-1+b1
ii  libpng12-dev [libpng-dev]1.2.54-4+b1

libmgl-dev recommends no packages.

libmgl-dev suggests no packages.

-- no debconf information

Bug#808839: fop: Exception java.lang.IllegalArgumentException: URI is not hierarchical

[Sylvain Joubert]

Package: fop
Version: 1:2.1-1
Followup-For: Bug #808839

Dear Maintainer,

The issue is still reproducible with the last version from sid.
The behavior is still the same, it is triggered by the use of the jlatexmath
plugin with any *.fo file.

Thanks



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-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 fop depends on:
ii  default-jre-headless [java2-runtime-headless]2:1.7-52.1
ii  libfop-java  1:2.1-1
ii  openjdk-7-jre-headless [java2-runtime-headless]  7u91-2.6.3-1

Versions of packages fop recommends:
ii  libsaxon-java  1:6.5.5-10

Versions of packages fop suggests:
pn  fop-doc  

-- no debconf information

Bug#808839: Info received (fop: Exception java.lang.IllegalArgumentException: URI is not hierarchical)

[Sylvain Joubert]

I finally took some time to debug this and it seems the problem may be 
related to libjlatexmath-fop-java.


In my setup I use LaTeX formatting from a docbook file to produce a PDF
file with fop and jlatexmath fop plugin.
My invocation of fop is prefixed by:
FOP_HYPHENATION_PATH=/usr/share/java/jlatexmath-fop.jar

When I remove this environment variable my document is generated without
errors (even though the LaTeX code is obviously not rendered)
It seems that the last update of the libjlatexmath-fop-java plugin is 
quite old and in between fop was upgraded to version 2.0


Could the issue be coming from the jlatexmath plugin not working with 
new fop version?

Bug#808839: fop: Exception java.lang.IllegalArgumentException: URI is not hierarchical

[Sylvain Joubert]

Package: fop
Version: 1:2.0+dfsg-5
Followup-For: Bug #808839

Dear Maintainer,

Thanks for taking a look at this.
Unfortunately I already have this package installed so that does not change
anything.

$ aptitude versions gsfonts-x11
Paquet gsfonts-x11 :
p   0.22  stable  800
i   0.24  testing,unstable990



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-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 fop depends on:
ii  default-jre-headless [java2-runtime-headless]2:1.7-52.1
ii  libfop-java  1:2.0+dfsg-5
ii  openjdk-7-jre-headless [java2-runtime-headless]  7u91-2.6.3-1

Versions of packages fop recommends:
ii  libsaxon-java  1:6.5.5-10

Versions of packages fop suggests:
pn  fop-doc  

-- no debconf information

Bug#808839: fop: Exception java.lang.IllegalArgumentException: URI is not hierarchical

[Sylvain Joubert]

Package: fop
Version: 1:2.0+dfsg-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since I've updated my fop version (to 1:1.1.dfsg2-1) I can't use it anymore as
I get the following error:

[ERROR] FOP - Exception java.lang.IllegalArgumentException: URI is not hierarchical
at java.io.File.(File.java:418)
at org.apache.fop.fonts.FontCache.addFont(FontCache.java:335)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.getFontInfoFromCustomFont(FontInfoFinder.java:157)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:269)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:110)
at
org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at
org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at
org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75)
at
org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107)
at org.apache.fop.cli.Main.startFOP(Main.java:186)
at org.apache.fop.cli.Main.main(Main.java:217)

I also get these warnings just before, maybe it's related:

[INFO] Type1FontLoader - No Unicode mapping for glyph: AFM Char: 153 (anglearc)
[INFO] Type1FontLoader - No Unicode mapping for glyph: AFM Char: 166 (diameter)
[WARN] FOUserAgent - Unable to load font file:
file:/usr/share/fonts/X11/Type1/c059036l.pfb. Reason:
java.io.FileNotFoundException: Neither an AFM nor a PFM file was found for
file:/usr/share/fonts/X11/Type1/c059036l.pfb
[WARN] FOUserAgent - Unable to load font file:
file:/usr/share/fonts/truetype/noto/NotoSerifKhmer-Bold.ttf. Reason:
java.lang.ArrayIndexOutOfBoundsException: 342
[WARN] FOUserAgent - Unable to load font file:
file:/usr/share/fonts/truetype/noto/NotoSerifKhmer-Regular.ttf. Reason:
java.lang.ArrayIndexOutOfBoundsException: 342
[WARN] FOUserAgent - Unable to load font file:
file:/usr/share/fonts/truetype/noto/NotoSansKhmer-Regular.ttf. Reason:
java.lang.ArrayIndexOutOfBoundsException: 223
[WARN] FOUserAgent - Unable to load font file:
file:/usr/share/fonts/truetype/noto/NotoSansKhmer-Bold.ttf. Reason:
java.lang.ArrayIndexOutOfBoundsException: 223

For now, the only workaround I've found is to downgrade fop to its 'stable'
version (1:2.0+dfsg-4)



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-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 fop depends on:
ii  default-jre-headless [java2-runtime-headless]2:1.7-52.1
ii  libfop-java  1:2.0+dfsg-4
ii  openjdk-7-jre-headless [java2-runtime-headless]  7u91-2.6.3-1

Versions of packages fop recommends:
ii  libsaxon-java  1:6.5.5-10

Versions of packages fop suggests:
pn  fop-doc  

-- no debconf information

Bug#800460: mathgl: Test program fails to build, syntax error in header

[Sylvain Joubert]

Source: mathgl
Version: 2.3.3+svn1216-1
Followup-For: Bug #800460

Dear Maintainer,

The problem still exists in the last version of the package.
The two defines are still set to 1 and the test example does not compile.

Regards.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-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#800460: mathgl: Test program fails to build, syntax error in header

[Sylvain Joubert]

Package: libmgl-dev
Version: 2.3.3-3
Followup-For: Bug #800460

Dear Maintainer,

The simple test example from the original post still fails to compile with the
lastest version.
It still requires to use -std=gnu++11 or similar language extensions to work.

Especially, in /usr/include/mgl2/config.h, MGL_HAVE_TYPEOF and
MGL_HAVE_C99_COMPLEX are still defined to '1' which seems to require the above
flags.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-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 libmgl-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]  10.6.8-1
ii  libgsl0-dev  1.16+dfsg-4
ii  libmgl-fltk7.4.0 2.3.3-3
ii  libmgl-glut7.4.0 2.3.3-3
ii  libmgl-mpi7.4.0  2.3.3-3
ii  libmgl-qt7.4.0   2.3.3-3
ii  libmgl-wnd7.4.0  2.3.3-3
ii  libmgl-wx7.4.0   2.3.3-3
ii  libmgl7.4.0  2.3.3-3
ii  libpng12-dev [libpng-dev]1.2.50-2+b2

libmgl-dev recommends no packages.

libmgl-dev suggests no packages.

-- no debconf information

-- 

--
This message and any attachments are the property of The CoSMo Company; 
they are strictly confidential and intended solely for the addressees. If 
you are not the intended recipient of this message, please delete it and 
immediately notify the sender. Any use not in accordance with the purpose 
of this message and any dissemination or disclosure, either whole or 
partial, is prohibited except with formal approval.

Ce message et toutes les pieces jointes sont la propriete de The CoSMo 
Company ; ils sont etablis a  l'intention exclusive de ses destinataires et 
sont confidentiels. Si vous recevez ce message par erreur, merci de le 
detruire et d'en avertir immediatement l'expediteur. Toute utilisation non 
conforme a  sa destination, toute diffusion ou toute publication, totale ou 
partielle est interdite, sans autorisation expresse.

Bug#786618: swig3.0: Infinite recursive call of ccache-swig3.0 to itself

[Sylvain Joubert]

Package: swig3.0
Version: 3.0.2-1
Severity: important

Dear Maintainer,

Calling ccache-swig3.0 directly is not working properly, it hangs up after a
while (~30s on my computer) with the following error:

$ ccache-swig3.0 -V
/usr/bin/ccache-swig3.0: error while loading shared libraries: libz.so.1:
cannot open shared object file: Error 24

I've strace'd the call and identified that ccache-swig3.0 calls itself
recursively until the system refuses to continue.
After taking a quick look at the ccache-swig source code (which is based on a
very old version of ccache btw) it appears that the executable name MUST be
ccache-swig exactly, otherwise it will consider being called in place of a
compiler (in that case one called ccache-swig3.0) and will try to execute it
(which in that case will reproduce indefinitely what I've just described).

Note that ccache-swig2.0 has the same issue and the only way to make ccache-
swig* work is either to manually provide a ccache-swig symlink or to install
the swig package to do it but in that case I'm stuck with swig 2.0.

In any case, the swig package should not be required to be able to use any of
the swigX.Y packages



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'stable-updates'), (980, 'testing'), 
(970, 'stable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-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
Init: systemd (via /run/systemd/system)

Versions of packages swig3.0 depends on:
ii  libc6   2.19-18
ii  libgcc1 1:5.1.1-5
ii  libpcre32:8.35-3.3
ii  libstdc++6  5.1.1-5
ii  zlib1g  1:1.2.8.dfsg-2+b1

swig3.0 recommends no packages.

Versions of packages swig3.0 suggests:
pn  swig3.0-doc   none
pn  swig3.0-examples  none

-- 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#778567: qt5-default: wrongly in section libs

[Sylvain Joubert]

Package: qt5-default
Version: 5.3.2+dfsg-4+b1
Severity: normal

Dear Maintainer,

Please consider moving qt5-default to the libdevel section since:
- this package provides development facilities
- qt4-default is already in the libdevel section
- it makes deborphan list the package in its standard configuration (without '
--libdevel' option)

Regards



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'stable-updates'), (980, 'testing'), 
(970, 'stable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-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
Init: systemd (via /run/systemd/system)

Versions of packages qt5-default depends on:
ii  qtbase5-dev  5.3.2+dfsg-4+b1
ii  qtchooser47-gd2b7997-2

qt5-default recommends no packages.

Versions of packages qt5-default suggests:
ii  qt5-qmake  5.3.2+dfsg-4+b1
ii  qtbase5-dev-tools  5.3.2+dfsg-4+b1

-- 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#776605: ninja-build: man page is not up-to-date

[Sylvain Joubert]

Package: ninja-build
Version: 1.5.1-0.1
Severity: normal

Dear Maintainer,

While the current version is 1.5.1 (ninja --version),
the man page of ninja(1) mentions version 1.3.4
Please update the man page so that users are not confused.



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'stable-updates'), (980, 'testing'),
(970, 'stable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-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
Init: systemd (via /run/systemd/system)

Versions of packages ninja-build depends on:
ii  libc6   2.19-13
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

ninja-build recommends no packages.

ninja-build suggests no packages.


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

Bug#761375: clang: Typo in package description mentioning 2001 C++ standard instead of 2011

[Sylvain Joubert]

Package: clang
Version: 1:3.4-23
Severity: minor

Dear Maintainer,

The various packages related to clang (including clang, clang-3.4, clang-3.5)
mention support for version 2001 of the C++ standard:

Clang implements all of the ISO C++ 1998 and 2001 standards and also provides
a partial support of C++1y.

I believe this is a typo and it should say 2011



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'stable-updates'), (980, 'testing'), 
(970, 'stable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-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

Versions of packages clang depends on:
ii  clang-3.4  1:3.4.2-8

clang recommends no packages.

clang suggests no packages.

-- 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#755907: pax-utils: lddtree shows wrong libraries for 32-bits objects on a 64-bit machine

[Sylvain Joubert]

Package: pax-utils
Version: 0.2.3-2
Severity: important

Dear Maintainer,

I have been trying to use lddtree on a 32-bits binary (executable or library is
irrelevant) but the output is completely wrong.
Unlike ldd which displays the correct 32-bits dependencies, lddtree shows the
64-bits versions of them making it unusable for these kind of objects.

Here are simple repro steps:

$ cat main.c
int main(void)
{
  return 0;
}
$ cc -m32 main.c -o 32.out
$ file 32.out
32.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=b566e1cb538e8bdfe845a0d5ca659109f7a810df, not stripped
$ ldd 32.out
linux-gate.so.1 (0xf777f000)
libc.so.6 = /lib32/libc.so.6 (0xf75a8000)
/lib/ld-linux.so.2 (0xf778)
$ lddtree 32.out
32.out = ./32.out (interpreter = /lib/ld-linux.so.2)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 = /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'stable-updates'), (980, 'testing'),
(970, 'stable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-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

Versions of packages pax-utils depends on:
ii  libc62.19-7
ii  libcap2  1:2.24-1

pax-utils recommends no packages.

Versions of packages pax-utils suggests:
pn  paxctl  none


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

Bug#738540: libmgl-dev: clang cannot be used to compile an application using mathgl

[Sylvain Joubert]

Package: libmgl-dev
Version: 2.2-1
Severity: important
Tags: upstream

Dear Maintainer,

When trying to compile an application using libmgl-dev with clang I get the
following compilation error:

/usr/include/mgl2/define.h:27:10: fatal error: 'omp.h' file not found
#include omp.h

Indeed, clang does not support OpenMP yet.

I traced back the include in the Mathgl sources and it seems:
1. This include is useless since there is no call in the sources to any of the
OpenMP functions
2. Even if mathgl sources want to make use of the OpenMP API, the omp.h
include should not have been provided to the end-user. IMHO, it should have
stayed in C++ source files not in headers provided to the user.

I think this is an upstream bug, but in the mean time there may be a Debian fix
to allow users to compile their application with clang. One may consider
rebuilding mathgl with OpenMP support deactivated and maybe activate the
pthread support since it is the alternate way provided by mathgl.

Thanks!



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-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

Versions of packages libmgl-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]  9.2.2-1
ii  libgsl0-dev  1.16+dfsg-1
ii  libmgl-fltk7.1.0 2.2-1
ii  libmgl-glut7.1.0 2.2-1
ii  libmgl-mpi7.1.0  2.2-1
ii  libmgl-qt7.1.0   2.2-1
ii  libmgl-wnd7.1.0  2.2-1
ii  libmgl-wx7.1.0   2.2-1
ii  libmgl7.1.0  2.2-1
ii  libpng12-dev [libpng-dev]1.2.50-1

libmgl-dev recommends no packages.

libmgl-dev suggests no packages.

-- 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#738540: libmgl-dev: clang cannot be used to compile an application using mathgl

[Sylvain Joubert]

I've found an alternative in Debian which will avoid rebuilding mathgl: 
I have updated my compiler to clang-3.4 (I previously used clang-3.3).
clang-3.4 is able to find omp.h so I can compile my application with 
this version of the compiler.


I still think the omp.h include is an upstream bug that should be 
reported/fixed.



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

Bug#711318: closed by Mathieu Malaterre ma...@debian.org (Bug#711318: fixed in xslthl 2.1.0-3)

[Sylvain Joubert]

Thanks for the fix.

However, I think the symlink is done the wrong way.
xslthl.jar is the real file and xslthl-x.y.z.jar points to it, I would 
have expected the opposite and xslthl.jar be the symlink instead of the 
real file.



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

Bug#711318: libxslthl-java: Missing symlink for xslthl.jar

[Sylvain Joubert]

Package: libxslthl-java
Version: 2.1.0-2
Severity: important

Dear Maintainer,

The symlink /usr/share/java/xslthl.jar previously pointing to
/usr/share/java/xslthl-x.y.z.jar seems
to be missing.

It prevents to use it without knowing the exact version number as expected from
the Debian java policy:
http://www.debian.org/doc/packaging-manuals/java-policy/x104.html

Thanks.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.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

Versions of packages libxslthl-java depends on:
ii  libsaxon-java   1:6.5.5-10
ii  libsaxonb-java  9.1.0.8-3
ii  libxalan2-java  2.7.1-7

libxslthl-java recommends no packages.

libxslthl-java suggests no packages.

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