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
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: e
ily 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 à 1
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
> >
> &
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
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)
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 (u
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 i
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
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/
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
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.
M
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
Cl
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.
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
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 mat
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/includ
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: stretc
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/jla
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
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 hierarchica
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 t
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,
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:
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 c
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 un
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 o
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 o
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 so I can compile my application with
this version of the compiler.
I still think the include is an upstream bug that should
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
Indeed, clang does not
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.
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
32 matches
Mail list logo
