+
+ * Improve patch decode_struct.maxpow (initialize with zero instead of
+-DBL_MAX).
+
+ -- Joachim Reichel Sat, 31 May 2025 13:23:29 +0200
+
+normalize-audio (0.7.7-20) unstable; urgency=medium
+
+ * Add patch to initialize decode_struct.maxpow (Closes: #1106841).
+
+ -- Joachim Reichel Fri, 30
For the record:
normalize-audio (0.7.7-21) unstable; urgency=medium
* Improve patch decode_struct.maxpow (initialize with zero instead of
-DBL_MAX).
-- Joachim Reichel Sat, 31 May 2025 13:23:29 +0200
Hi again,
ok, I'm convinced now that 0 is slightly better than -DBL_MAX. I'll prepare
another upload soon.
Regarding upstream: doesn't look like any development is still happening there.
There was a short exchange after I took over the package, but even with the
patches back then no new rele
Hi Thomas,
> A bad output looks like this:
$ normalize-audio -qn sweep.mp3
1938.4438dBFS -5.1133dBFS -1950.4438dB sweep.mp3
unfortunately I couldn't reproduce the issue at all, not a single time with
1 runs on Debian bookworm, trixie or sid. My package versions to compare:
Debian book
Package: www.debian.org
Severity: normal
X-Debbugs-Cc: reic...@debian.org
Hi,
comparing the commands at https://www.debian.org/Bugs/server-control and
https://www.debian.org/Bugs/server-refcard
show that the latter lacks many commands:
affects
archive
fixed
notfixed
outlook
summary
thanks
unarc
https://sourceforge.net/p/cppcheck/discussion/
i think the message could be improved!
It should be more like "Ignoring #include at line xxx" that would be a lot
more understandable
Possibly. You could suggest that on the cppcheck mailinglist (maybe check their
archives if that has been discussed before).
Best regards,
Joachim
tags 1099986 - pending patch
severity 1099986 normal
thanks
The patch has been applied in 2.17.1-2:
=
cppcheck (2.17.1-2) unstable; urgency=medium
* Disable autopkgtests on ppc64el, thanks to Michael Prokop (see #1099986).
=
Best regards,
Joachim
Hi Richard,
yes, that's expected as explained in the message from the second invocation.
There is no default include path in cppcheck. You can add it explicitly, but
typically you don't want to check the standard library headers. And if you try
it, you'll see that it will check only a subset o
I tried to debug this with a qemu image from
https://people.debian.org/~gio/dqib/, but failed to reproduce the issue.
For those worrying about their favorite reverse dependency of cppcheck showing
up on the autoremovals list: unless someone comes up with a way to reproduce/fix
this, I plan to
Hi ppc64el porters,
cppcheck has an autopkgtest regression on ppc64el (see #1099986 for details).
Any help would he highly appreciated.
Best regards,
Joachim
P.S: I'm not subscribed, please keep the bug (or me) on CC:.
tag 1099986 + help
thanks
Update:
I've been unable to reproduce the crash on platti (testing and sid).
In testing the autopkgtest fails since the upload of gcc-14 14.2.0-14:
https://ci.debian.net/packages/c/cppcheck/testing/ppc64el/
For sid there is less data, but a matching date range:
https:/
severity 1074118 serious
severity 1074119 serious
severity 1074380 serious
severity 1074381 serious
thanks
CGAL 6.0 has been uploaded to unstable. Raising severity to serious.
Best regards,
Joachim
Hi Francesco,
CGAL 6.0 has been uploaded to unstable. You might want to apply the diff in
experimental to the unstable version, too.
Best regards,
Joachim
Source: openfoam
Version: 1912.200626-2
Severity: minor
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
while investigating the consequences of uploading CGAL 6.0 I noticed that your
package declares a build-dependency on libcgal-dev, but apparently does not use
CGAL at all (-DNO_CGAL, use of C
Source: cloudcompare
Version: 2.11.3-7.1
Severity: minor
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
while investigating the consequences of uploading CGAL 6.0 I noticed that your
package declares a build-dependency on libcgal-dev and libcgal-qt5-dev, but
apparently does not use CGAL at all
Source: sfcgal
Version: 1.5.1-3
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github.com/CGAL/cga
Source: pygalmesh
Version: 0.10.6-2
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github.com/CGAL
Package: octave-iso2mesh
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github.com/CGAL/cgal/relea
Thanks for the heads up. The upcoming 3.10 release of GUDHI will support
CGAL 6.0, and should be out soon [1]. I'll get it packaged as soon as
it's out (the RC cycle for GUDHI is usually merely a matter of days).
Ok, very good.
PS: I see this bug was filed against GUDHI versions starting with
Package: slic3r-prusia
Version: slic3r-prusa
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github
Source: deal.ii
Version: 9.4.1-1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github.com/CGAL/cg
Package: openscad
Version: 2021.01-6
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github.com/CGA
Source: mshr
Version: 2019.2.0~git20200924.c27eb18+dfsg1-7
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1]
Source: gudhi
Version: 3.7.1+dfsg-1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: reic...@debian.org
Dear maintainer,
your package fails to build with cgal 6.0~beta1-1, which has recently been
uploaded to experimental. See [1] for the release notes with breaking changes.
[1] https://github.com/CGAL
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 sim
-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 l
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 m
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
tr
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 -rfak
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 lik
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,
Joachi
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 8.0.0+dfs
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 po
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, l
-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 a
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 yo
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
+dpkg-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
---
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 b
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 toolchai
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
shoul
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 de
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 fr
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.
Jo
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!
sortFil
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 maint
> 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
https://buildd.debian.org/status/
Uploaded to DELAYED/5-day.
ich should 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/wa
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 -O--b
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 diffic
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 Stac
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 app
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 . -m
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,
Joa
.
+ * 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 a
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 availa
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: htt
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 reve
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 non-trivial
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 holding
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 pygalmes
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 locati
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 -O--buil
1 - 100 of 320 matches
Mail list logo
