Hi Andreas,
usually I would have implemented your suggestion (and I don't mind anyone
implementing it), but I'm not really keen on investing in a dependency that
hasn't seen a single upstream release in 12 years and where the last upload was
an NMU four years ago from myself dealing with a
-function-declaration to CFLAGS to disable
+new defaults from dpkg-buildflags (Closes: #1066115).
+
+ -- Joachim Reichel Thu, 21 Mar 2024 20:39:07 +
+
mpg321 (0.3.2-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru mpg321-0.3.2/debian/rules mpg321-0.3.2/debian/rules
Hi Markus,
I also experienced this crash. I can confirm that your patch solved the problem,
thanks!
Best regards,
Joachim
severity 1026302 wishlist
thanks
Hi Alex,
Similar to GCC's -isystem to specify a path to check for system headers,
it would be very useful to tell cppcheck where to find system headers.
I'm writing a library, whose headers include eachother using <> since
it's intended to be used as a system
found 1024272 1:3.00-8
thanks
The bug exists probably since a long time ago. Let's use the current oldstable
version for tracking purposes.
Hi Gregor,
[...] > Now I'm wondering if changing the runtime dependency to
"graphicsmagick-imagemagick-compat | imagemagick" would achieve the
same while allowing the user to choose (or keep) one of the two
implementations?
good point! I noticed that imagemagick contains mogrify-im6.q16, but
Hi Stefan,
thanks for the image. I just uploaded -4 which fixes the problem.
Best regards,
Joachim
Hi Stefan,
it would have been helpful if you had attached an image that shows this
behavior. I have an idea what the problem might be, but having access to your
test case for verification would be good. Feel free to send it directly to my
email address if you prefer.
Best regards,
Joachim
found 1022028 1:3.00-8
thanks
The bugs exist probably since the features were added a long time ago. Let's use
the current oldstable version for tracking purposes.
Hi Francois,
thanks for the report. This change also gets rid of a lot of cmake warnings
related to VTK! I'll upload a fixed version later today.
Best regards,
Joachim
Hi,
On 2/14/22 09:54, Sebastiaan Couwenberg wrote:
Just adding -latomic to LDFLAGS was not sufficient, to workaround this issue
-Wl,--no-as-needed also needed to be added to CXXFLAGS.
Do you really mean CXXFLAGS? Or should that read LDFLAGS?
Best regards,
Joachim
Hi Ian,
On 28.11.21 19:21, Ian Jackson wrote:
Joachim Reichel (cppcheck maintainer):
I'll upload a new version cppcheck with a workaround shortly
Would you mind both prioritising this fix ? FTAOD it's not just
cppcheck that is scheduled for autoremoval. Any package which
transitively
The root case of the problem has now been identified (see bug #100421). I'll
upload a new version cppcheck with a workaround shortly (and before the
autoremoval kicks in) -- just wanting to wait a bit more for a potential new
upstream release.
Best regards,
Joachim
Package: dpkg-dev
Version: 1.20.9
Severity: serious
Control: affects -1 cppcheck
Hi,
dpkg-shlibdeps calculates too low minimum version requirements for cppcheck on
libc6 (see bug 1000146).
To reproduce, build cppcheck 2.6-1 in unstable chroot without cleaning up,
e.g., "dpkg-buildpackage
severity 1000146 serious
thanks
Hi Alejandro,
I was able to reproduce the problem. It's unclear to me why "${shlibs:Depends}"
does not produce a ">= 2.32" constraint and I've asked on the debian-mentors
list for comments. Obviously, I could add that constraint manually, but I would
first
forwarded 124 https://trac.cppcheck.net/ticket/10610#ticket
thanks
Hi Matthew,
I created an upstream feature request at
https://trac.cppcheck.net/ticket/10610#ticket . As last resort we could also
build cppcheck without dependency on PCRE by disabled rules support.
Best regards,
For the missing major version/SONAME change I've created an issue in the upstream github project:
https://github.com/leethomason/tinyxml2/issues/867
Best regards,
Joachim
reassign 988986 tinyxml2
severity 988986 serious
retitle 988986 ABI change in tinyxml2 8.1.0+dfsg-1
found 988986 8.1.0+dfsg-1
thanks
Hi Chow,
it seems that there's an ABI change in tinyxml2 8.1.0+dfsg-1.
cppcheck 2.3-1 was uploaded to unstable on 2020-12-17, compiled against tinyxml2
tags 985671 + pending
thanks
On 15.12.20 20:13, Russ Allbery wrote:
2.3 was a net improvement for me, although the code base on which I've
tested it is not all that large (about 35K lines including comments). I
think it's fine to move to 2.3 in the upcoming release. This falls within
the "normal" level of cppcheck false
Package: ftp.debian.org
Severity: normal
Hi,
please remove zimpl from unstable.
Never versions >= 3.3.7 are no longer separately available, but only as part of
a larger software package. Access to this larger package requires acceptance of
a non-free license (academic use only) through some web
tag 977328 +upstream
forwarded 977328 https://trac.cppcheck.net/ticket/10037#ticket
thanks
Ok, I forwarded the modified tests to the upstream bug tracker.
Btw the first test also fails with cppcheck 2.2, while the second and third
test are regressions. On the other hand, cppcheck 2.3 fixes bug
Hi Russ,
On 14.12.20 01:23, Russ Allbery wrote:
> (Apologies, I haven't reported these upstream since they want bug
> reporters to catch them on IRC to get a Trac account created.)
Yes, the problems with account creation are very unfortunate. I'll forward
your test cases, but before doing so,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09.08.20 20:15, John Scott wrote:
> Sorry for the noise, I spoke too soon. Their main page says it normally
> takes days to get an account which must be requested over IRC [1]. For a
> one-time comment that's a big leap to take.
Right, I forgot
On 09.08.20 04:00, John Scott wrote:
> I saw upstream said they couldn't reproduce with the development tree, so I
> was going to try bisecting this. However when I build non-Debianized Cppcheck
> 2.1 using the following default options, I can't reproduce the crash and it
> seems to work.
As
the default from
+dpkg-buildflags as workaround for some build error.
+ * Add -fcommon to CFLAGS (Closes: #957563).
+ * Remove circular build dependencies around build-stamp which make the
+package FTBFS in clean environments.
+
+ -- Joachim Reichel Thu, 23 Jul 2020 17:22:42 +0200
+
mpg321
tag 966386 +upstream
forwarded 966386 https://trac.cppcheck.net/ticket/9820#ticket
thanks
Hi Scott,
I forwarded the bug to the upstream bug tracker. I'll add the Suggests: clang
to cppcheck (was only there for cppcheck-gui).
Including your command-line would have been nice. Initially, I was not
buildflags as workaround for some build error.
+ * Add -fcommon to CFLAGS (Closes: #957563).
+
+ -- Joachim Reichel Thu, 23 Jul 2020 17:22:42 +0200
+
mpg321 (0.3.2-3) unstable; urgency=medium
* Fix compilation error
diff -Nru mpg321-0.3.2/debian/rules mpg321-0.3.2/debian/rules
--- mpg321-0.
forwarded 962236 https://savannah.nongnu.org/bugs/index.php?58504
thanks
tag 962236 + upstream
forwarded 962236
https://savannah.nongnu.org/bugs/index.php?58504
thanks
Hi Francesco,
thanks for your report. I forwarded it as bug (or rather feature request)
#58504.
Best regards,
Joachim
Hi Jiri,
indeed, this must have slipped when updating to cppcheck 2.0. Setting
PYTHONPHOME to /usr seems to work as well and should work in the more general
case of other python interpreters. Will upload a fixed package shortly.
Best regards,
Joachim
Looks like tinyxml2 is ready to migrate except for autopkgtest regressions in
ignition-fuel-tools and ignition-msgs:
https://tracker.debian.org/pkg/tinyxml2
These "regressions" seem to be caused by testing both packages in isolation
and not together. ld emits a warning
"libtinyxml2.so.6, needed
notfound 923325 1.89-1
thanks
notfound 923325 1.89.1
thanks
forwarded 952398 http://trac.cppcheck.net/ticket/9657
tag 952398 + upstream
forwarded 952400 http://trac.cppcheck.net/ticket/9658
tag 952400 + upstream
thanks
The bug number for dh-python is #949305.
I don't see how the dh-python bug is blocking a fix here, so I'll leave
setting the tag to you. In addition, if they decide to rank "cmake" higher
than "distutils" (e.g. when sorting the plugins alphabetically), then your
package will use the wrong
Control: tags -1 +pending
Hi Marc,
yes, good catch. I'm adding qtbase5-dev, libqt5opengl5-dev, and
libqt5svg5-dev, which contain the #include'd headers and also pull in tools
like moc.
Best regards,
Joachim
On 25.01.20 09:40, Marc Glisse wrote:
> Package: libcgal-qt5-dev
> Version: 5.0-5+b1
Control: tags -1 +pending
Hi Michal,
> It seems that cppcheck-htmlreport is not packaged anymore in the cppcheck
> package from sid, see https://packages.debian.org/sid/amd64/cppcheck/filelist.
yes, right. Thanks for reporting.
Best regards,
Joachim
Package: dh-python
Version: 4.20191017
Severity: normal
Hi,
the order in which /usr/bin/pybuild tests the build system plugins depends on
the order of files in the directory /usr/share/dh-python/dhpython/build. If two
plugins have the same certainty, the first one wins. This non-determinism
Hi Drew,
I just saw your reply by accident. It seems you did not copy me. Note that the
submitter does not receive mails to n...@bugs.debian.org. Either use
nnn-submitter@b.d.o. or add me directly.
> I checked with Nico upstream, cmake is not intended for building
> pygalmesh for python module
Package: dwz
Version: 0.13-5
Severity: normal
Hi,
when building cppcheck 1.90-1 or -2 on amd64, dwz fails with "Unknown DWARF
DW_OP_255" (make sure to disable the workaround in debian/rules).
I've backed up the cppcheck binary on which this happens. This can also be
reproduced with dwz 0.12-3
Control: tags -1 +pending
Hi,
right, cppcheck-gui needs the cfg files which are in package cppcheck.
Joachim
Control: tags -1 +pending
Hi,
weird, I believe I had parallel builds working in my environment. And I'm not
sure why override_dh_auto_configure did not work for me.
Anyway, it is now much simpler and cleaner. The rules for override_dh_missing
and override_dh_auto_clean can also be removed.
Package: fatsort
Version: 1.3.365-1+b1
Severity: important
Hi,
fatsort 1.3.365-1+b1 always fails for me with
$ fatsort /dev/sdh1
check_bootsector: Sectors have a size of zero!
read_bootsector: This is not a FAT boot sector or sector is damaged!
openFileSystem: Failed to read boot sector!
Update on the current state:
cloudcompare binNMU successful, all green
gudhi binNMU successful, all green
mshr binNMU successful, all green
openfoam binNMU successful, all green
openscad fixed by maintainer, all green
pygalmesh fixed by maintainer, all green
Hi Paul,
could you please trigger another binNMU for gudhi on mips64el? There was a
problem in CGAL that I fixed in 5.0-5.
Thanks,
Joachim
Update on the current state:
cloudcompare binNMU successful, all green
mshr binNMU successful, all green
openfoam binNMU successful, all green
openscad fixed by maintainer, all green
gudhi binNMU successful, but mips64el still missing
sfcgal fixed by
> Upstream 0.5.0 now builds against CGAL 5, so we only need an upload here.
What do you mean with "only"? Is there already a package for the new upstream
ready to be uploaded?
NMU uploaded to DELAYED/5-day.
Source: openems
Version: 0.0.35+git20190103.6a75e98+dfsg.1-1
Severity: serious
Tags: ftbfs
Control: block 944417 by -1
Hi,
the transition to CGAL 5.0 started (see bug #944417). A binNMU would have been
sufficient, but your package FTBFS for unrelated reasons. See
Uploaded to DELAYED/5-day.
hould fix this.
> On 04-12-2019 00:02, Joachim Reichel wrote:
>> please schedule binNMUs for gudhi, openems, and pygalmesh to support the
>> cgal_5.0 transition (see bug #944417).
Looking at the logs for pygalmesh I noticed that a binNMU will most likely not
work (see bug #946234). I'll prepare an NMU.
Joachim
) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch to fix FTBFS with CGAL >= 5.0 (Closes: #xx).
+ * Add Build-Depends: libcgal-dev (>= 5.0~).
+
+ -- Joachim Reichel Thu, 05 Dec 2019 23:07:13 +0100
+
pygalmesh (0.4.0-1) unstable; urgency=medium
* set debian
Source: pygalmesh
Version: 0.4.0
Severity: normal
Hi,
as already pointed in bug #933848: the build system behaves completely
different based on the presence or absence of cmake.
With cmake:
---
debian/rules build
dh build --with python3 --buildsystem=pybuild
dh_update_autotools_config
to fix FTBFS with CGAL >= 5.0 (Closes: #xx).
+ * Add Build-Depends: libcgal-dev (>= 5.0~).
+
+ -- Joachim Reichel Thu, 05 Dec 2019 21:34:40 +0100
+
sfcgal (1.3.7-2) unstable; urgency=medium
* Bump Standards-Version to 4.4.0, no changes.
diff -Nru sfcgal-1.3.7/debian/control sfcgal
Hi,
it seems to me that other packages are also affected:
- k3d FTBFS (bug #946225)
- yade FTBFS (apparently fixed in experimental, see bug #938859)
Even though these packages needs to be fixed, it might be a good idea not to
break them right way and make e.g. the cgal_5.0 transition more
Source: k3d
Version: 0.8.0.6-8
Severity: serious
Tags: ftbfs
Control: block 944417 by -1
Hi,
the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS.
Attached are two patches that fix the problem. In addition, one needs to add
"Build-Depends: libcgal-dev (>= 5.0~).
But just
Source: k3d
Version: 0.8.0.6-8
Severity: serious
Tags: ftbfs
Hi,
your package FTBFS:
CMake Error at
/usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find Boost (missing: python) (found suitable version "1.67.0",
minimum required is "1.42")
Call
Source: yade
Version: 2019.01a-3
Severity: serious
Tags: ftbfs
Control: block 944417 by -1
Hi,
the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS.
Attached are two patches that fix the problem. In addition, one needs to add
"Build-Depends: libcgal-dev (>= 5.0~).
Just
Package: release.debian.org
Severity: normal
Control: block 944417 by -1
Hi,
please schedule binNMUs for gudhi, openems, and pygalmesh to support the
cgal_5.0 transition (see bug #944417).
nmu gudhi_3.0.0+dfsg-3 . ANY . -m 'Rebuild against libcgal-dev >= 5.0'
dw gudhi_3.0.0+dfsg-3 . ANY .
Source: rheolef
Version: 7.0-3
Severity: serious
Tags: ftbfs
Control: block 944417 by -1
Hi,
the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS.
Attached are two patches to fix the problem, however, the build fails at a
later stage due to bug #944197.
Best regards,
.
+ * Add patch to fix FTBFS with CGAL >= 5.0 (Closes: #xx).
+ * Add Build-Depends: libcgal-dev (>= 5.0~).
+
+ -- Joachim Reichel Tue, 03 Dec 2019 22:22:43 +0100
+
crrcsim (0.9.13-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru crrcsim-0.9.13/debian/control crrcsim-
Control: severity -1 serious
Control: tag -1 ftbfs
Control: block 944417 by -1
The CGAL transition has started (see bug #944417). Raising the severity to RC.
Joachim
Control: severity -1 serious
Control: tag -1 ftbfs
Control: block 944417 by -1
The CGAL transition has started (see bug #944417). Raising the severity to RC.
Joachim
Control: tags -1 -moreinfo
Hi Paul,
On 02.12.19 21:34, Paul Gevers wrote:
> Have those patches been submitted to the BTS? Are the maintainers of
> these packages aware of this? Are the changes trivial and are you ready
> to NMU them (except rheolef)?
I've contacted the maintainers on Nov. 11th
Update:
crrcsimneeds source code changes, patch available
gudhi binNMU should be sufficient
k3dneeds source code changes, patch available
openemsbinNMU should be sufficient
openscad needs source code changes, patch available
pgrouting needs source code changes, patch
Package: pprepair
Version: 0.0~20170614-dd91a21-3+b1
Severity: important
Tags: upstream
Hi,
pprepair fails to build with CGAL 5.0 in experimental since it uses features
that have been removed in CGAL 5.0. See first item under "2D Triangulations" at
https://www.cgal.org/2019/10/31/cgal50-beta2/ .
Source: prepair
Version: 0.7.1-3+b2
Severity: important
Tags: upstream
Hi,
prepair fails to build with CGAL 5.0 in experimental since it uses features
that have been removed in CGAL 5.0. See first item under "2D Triangulations" at
https://www.cgal.org/2019/10/31/cgal50-beta2/ .
Upstream bug:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi,
I'd like to request a transition slot for CGAL 5.0. The CGAL library is now
header-only, i.e., the two library packages "libcgal13" and "libcgal-qt5-14"
are now gone.
Status of
tag 944361 +pending
thanks
Hi,
I did not see any release announcement for CGAL 5.0 final yet, only for Beta 2.
Thanks for your offer to help, but I'm already working on updating the packaging
and in contact with upstream to get the last problems fixed. Updating the
packaging requires
tag 925782 + patch
thanks
Hi,
attached is a patch that fixes the FTBFS with g++-9.
Best regards,
Joachim
Index: mp3check-0.8.7/texception.h
===
--- mp3check-0.8.7.orig/texception.h
+++ mp3check-0.8.7/texception.h
@@ -38,10 +38,10
It seems to be that the cmake-related FTBFS was not addressed?
Hi Drew,
On 07.08.19 21:02, Drew Parsons wrote:
> With the ABI bump in libCGAL_ImageIO.so.14, I think the shlibs for
> CGAL needs to be updated in libcgal13.shlibs, probably
> libCGAL_ImageIO 14 libcgal13 (>= 4.14)
right, that is missing. I'll add that shortly.
> Possibly that's what's
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Hi,
I uploaded a new version of cgal which bumped the SOVERSION of
libCGAL_ImageIO.so and was not aware that there is nowadays a reverse
dependency of this library in Debian.
nmu
Package: munin
Version: 2.0.49-1
Severity: normal
/etc/cron.d/munin contains this entry
27 03 * * * munin if [ -d /var/cache/munin/www ]; then find
/var/cache/munin/www/ -type f -name "*.html" -mtime +30 -delete; find
/var/cache/munin/www/ -mindepth 1 -type d -empty -delete; fi
That
Source: pygalmesh
Version: 0.3.6-1
Severity: serious
1) pygalmesh FTBFS if cmake is installed. Actually the build succeeds, but the
resulting binary package is almost empty.
With cmake installed:
fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
dh_auto_clean
Due to bugs 870406 and 887057 the following packages are scheduled for removal
from testing on 2019-03-11:
gjay, mp3cd, mp3roaster, mpg321, normalize-audio, ripit, terminatorx
Is anyone working on these bugs?
Joachim
Hi Marc,
a similar problem has been reported before, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861594 and
https://trac.cppcheck.net/ticket/8042 .
It is intentional that cppcheck-gui terminates if the --data-dir option is
supplied (the setting is persistent). The documentation has
Hi Adrian,
thanks for looking into it! Actually I'm testing right now a similar patch where
the declaration of v2 a few lines below is adjusted in a similar way. Upload
should happen shortly.
Joachim
On 03.08.2018 06:03, Debian Bug Tracking System wrote:
> Changes:
> tinyxml2 (6.2.0+dfsg-2) unstable; urgency=medium
> .
>* [7fdca1f] Rename package for abi break (Closes: #898535)
How do you plan to deal with the breakage that results from the renaming? Did
you already ask for binNMUs? I
Hi,
please package version 0.7.0 (from 21-Mar-2017) which has support for
vertical split mode (bug #733303).
Joachim
Bug 886670 has now been fixed, so you could use find_package(CGAL ...) instead
of accessing internal variables like CGAL_CXX_FLAGS_INIT. find_package() will no
longer inject internal flags that were used to build CGAL itself.
For a simple example run cgal_create_cmake_script on a trivial foo.cpp
On 30.06.2018 13:39, Adrian Bunk wrote:
> On Mon, Jun 25, 2018 at 10:10:09PM +0200, Joachim Reichel wrote:
>>> I noticed because this problem still affects #883986.
>>>
>>> And the build logs at [1] also show plenty of the cgal -fdebug-prefix-map=
>>
>&
> I noticed because this problem still affects #883986.
>
> And the build logs at [1] also show plenty of the cgal -fdebug-prefix-map=
Users are not supposed to use internal variables like CGAL_CXX_FLAGS_INIT. They
contain values that were used to build CGAL. (I need to check whether the files
> Doesn't seem to be fixed:
>
> $ grep CGAL_CXX_FLAGS_INIT
> /usr/lib/x86_64-linux-gnu/cmake/CGAL/CGALConfig.cmake
> set(CGAL_CXX_FLAGS_INIT "-g -O2
> -fdebug-prefix-map=/build/cgal-KLLrNy/cgal-4.12=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time
See bug 898327.
Joachim
Hi Jakub,
I confirm that the crash goes away if libtinyxml2-6 is downgraded to
6.0.0+dfsg-1. Thanks for finding the real cause!
I've filed bug 898535 against tinyxml2. I've added a versioned Build-Depends to
cppcheck as workaround.
Joachim
Source: tinyxml2
Version: 6.2.0+dfsg-1
Severity: grave
Tags: upstream
Hi,
the layout of tinyxml::XMLDocument has been changed between version 6.0.0 and
6.2.0 (addition of _parsingDepth member). Unfortunately, the SONAME has not
been bumped. This can cause applications built against version 6.0.0
Hi Jakub,
I can reproduce this on i386 with the binary package from the archive (but not
on amd64). I'm not able to reproduce the problem if I build the package myself
in an up-to-date sid chroot.
It also does not happen if I use g++ 7.3.0-15 which was used on the autobuilder,
but there are of
tag 890305 -pending
tag 890305 +help
thanks
Hi,
I did the suggested change but I still get
Depends: [...] python3:any (>= 3.5~), python:any, python3-pygments
in the cppcheck binary package. And there is still the lintian warning about the
old python version.
Is there something else that needs
notfound 445874 1:4.0.1+hg487+dfsg-1
thanks
This bug was fixed in 1:4.0.1+hg487+dfsg-1.
Joachim
tag 886670 pending
thanks
This will be fixed in CGAL 4.12 as part of a larger rewrite of the cmake
scripts.
Joachim
severity 886670 normal
unblock 883986 by 886670
tag 886670 upstream
forwarded 886670 https://github.com/CGAL/cgal/issues/2734
thanks
On 08.01.2018 20:35, Adrian Bunk wrote:
> While looking into fixing #883986 I ran into the following problem
> due to openscad using CGAL_CXX_FLAGS_INIT:
>
>
You shouldn't drop ${CGAL_CXX_FLAGS_INIT} completely. If you want to avoid the
troublesome flags, you should at least include -frounding-math, which is
strictly needed for CGAL.
Joachim
tag 883550 + pending
thanks
I'm not aware that cross-compiling was ever succesfully tested. My guess is that
CMAKE_CROSSCOMPILING is just a hint that it was attempted, but not completed.
Joachim
severity 876521 serious
thanks
On 12.11.2017 22:20, Sebastiaan Couwenberg wrote:
> You shouldn't have waited for this issue to request the transition slot.
> As I said before, I'll remove the SFCGAL dependency from PostGIS if this
> issue is not resolved when the CGAL transition starts. That way
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi,
I'd like to request a transition slot for CGAL due to an SONAME change. BinNMUs
are sufficient for the reverse dependencies except for the following three:
#876524 yade:
Hi Sebastiaan,
any news here? SFCGAL is now the only remaining reverse dependency that affects
the upload of CGAL 4.11.
Unless you have information that changes the picture in the near-term future I
would like to go on and request a transition slot for CGAL 4.11.
Kind regards,
Joachim
Hi Sebastiaan,
any news here? SFCGAL is now the only remaining reverse dependency that affects
the upload of CGAL 4.11.
Unless you have information that changes the picture in the near-term future I
would like to go on and request a transition slot for CGAL 4.11.
Kind regards,
Joachim
Hi Anton,
what's the status here? Can you please link the upstream bug report?
rheolef has been removed from testing and sfcgal is just an optional reverse
dependency of PostGIS, so yade is the only reverse dependency that is still
blocking the transition.
Kind regards,
Joachim
forwarded 819947 http://trac.cppcheck.net/ticket/8238
tag 819947 upstream
thanks
Hi Ilya,
I've forwarded the problem to upstream since I don't like to carry this as a
Debian-specific patch. (Sorry for taking that long -- somehow this fell through
the cracks several times.)
Joachim
1 - 100 of 294 matches
Mail list logo
