Bug#1066115: mpg123: FTBFS: error: implicit declaration of function ‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]
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 similar problem. I hope that explains why I took the route of this suboptimal shortcut. Best regards, Joachim
Bug#1066115: mpg123: FTBFS: error: implicit declaration of function ‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]
tag 1066115 + patch thanks Hi, attached is the debdiff for the NMU, uploaded to delayed/10. Similar to the previous NMU it adds -Wno-error=implicit-function-declaration to downgrade these errors back into warnings again. Best regards, Joachimdiff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog --- mpg321-0.3.2/debian/changelog 2020-07-23 17:22:42.0 +0200 +++ mpg321-0.3.2/debian/changelog 2024-03-21 21:39:07.0 +0100 @@ -1,3 +1,11 @@ +mpg321 (0.3.2-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add -Wno-error=implicit-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 --- mpg321-0.3.2/debian/rules 2020-07-23 17:22:42.0 +0200 +++ mpg321-0.3.2/debian/rules 2024-03-21 21:37:50.0 +0100 @@ -4,7 +4,7 @@ #export DH_VERBOSE=1 -export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -Wno-error=implicit-function-declaration -fcommon +export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -Wno-error=implicit-function-declaration -fcommon MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
Bug#854497: ext4magic: SIGSEGV while recovery from encrypted USB stick
Hi Markus, I also experienced this crash. I can confirm that your patch solved the problem, thanks! Best regards, Joachim
Bug#1026302: isystem: Specify path for system headers
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 library. However, for building (and linting) it, I need to tell the compiler (and linters) that the includes are not really system includes. I don't quite understand why you want/need -isystem for cppcheck. Is it just the minor inconvenience that you have to replace possible "-isystem" occurrences in your CFLAGS etc. by "-I"? Or is it the fact -isystem directories will be processes after -I directories? Also I don't understand "I need to tell ... are not really ..." in the last sentence. What does that mean in terms of actual compiler/cppcheck arguments? If you need to do something special (?) for the compiler, why is it not ok to do the same for cppcheck (maybe with s/-isystem/-I/)? It might help if you provide more details. Would you please add such an option? I myself will not add such an option. This a feature request for upstream. While I can forward your request (as I do with bug reports), it probably makes more sense if you report it directly upstream yourself. For such a request I'd expect more questions etc. from upstream and if you report the feature request yourself, then it's easier for you to argue for your case, instead of relying on me passing messages back and forth. Adjusting severity to "wishlist" (feature request). Best regards, Joachim
Bug#1024272: jhead: CVE-2021-34055: heap-buffer-overflow of exif.c in function Put16u
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.
Bug#1024712: jhead: New dependency on graphicsmagick-imagemagick-compat
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 missed that it makes that available as mogrify via the alternatives system. Since graphicsmagick uses "gm" and ...-compat is "just" a compatiblity package, I'm even considering using "imagemagick | imagemagick-6.q16hdri | graphicsmagick-imagemagick-compat" (different order plus ...hdri variant). Best regards, Joachim
Bug#1023303: jhead 1:3.06.0.1-3 deletes EXIF data
Hi Stefan, thanks for the image. I just uploaded -4 which fixes the problem. Best regards, Joachim
Bug#1023303: jhead 1:3.06.0.1-3 deletes EXIF data
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
Bug#1022028: jhead: CVE-2022-41751
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.
Bug#1012280: libcgal-demo: Please update suggested VTK version
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
Bug#1005696: cgal: -latomic not added on mipsel
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
Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32
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 [build-]depends on any package whose .debs are affected will be scheduled for autoremoval (assuming some bug has been filed). I'm aware of that. And "shortly" definitely means "before the autoremoval" (which is currently scheduled for 2022-01-01). Is there a particular reason for the urgency that I'm missing? Note that cppcheck is not a library, i.e., this wrong dependency should not spread out by delaying the upload a bit. (Fixing dpkg-shlibdeps and binNMUs is a different topic and is probably better discussed in #100421.) Best regards, Joachim
Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32
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
Bug#1000421: dpkg-shlibdeps: Wrong minimum version requirement on libc6
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 -rfakeroot -us -uc". $ grep Depends debian/cppcheck/DEBIAN/control Depends: libc6 (>= 2.29), [...] But running the binary with libc6 2.31 fails with cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by cppcheck) cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by /usr/lib/x86_64-linux-gnu/libstdc++.so.6) cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by /lib/x86_64-linux-gnu/libpthread.so.0) I believe that is the case because a certain symbol in the .bss section is ignored (this is the only symbol with 2.32 suffix): $ objdump -w -T ./debian/cppcheck/usr/bin/cppcheck | grep __libc_single_threaded 004670e0 gDO .bss 0001 GLIBC_2.32 __libc_single_threaded $ nm -D ./debian/cppcheck/usr/bin/cppcheck | grep __libc_single_threaded 004670e0 B __libc_single_threaded@@GLIBC_2.32 $ dpkg-shlibdeps ./debian/cppcheck/usr/bin/cppcheck; cat debian/substvars shlibs:Depends=libc6 (>= 2.29), [...] After hacking /usr/share/perl5/Dpkg/Shlibs/Objdump.pm:462 to read "defined => ($sect ne '*UND*') && ($sect ne '.bss')" (maybe not the right solution, just for demonstration): $ dpkg-shlibdeps ./debian/cppcheck/usr/bin/cppcheck; cat debian/substvars shlibs:Depends=libc6 (>= 2.32), [...] (Not really sure about the severity. I believe the resulting bugs in packagage using dpkg-shlipdeps are "serious".) Best regards, Joachim -- Package-specific info: System tainted due to merged-usr-via-aliased-dirs. -- System Information: Debian Release: 11.1 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev depends on: ii binutils 2.35.2-2 ii bzip2 1.0.8-4 ii libdpkg-perl 1.20.9 ii make 4.3-4.1 ii patch 2.7.6-7 ii perl 5.32.1-4+deb11u2 ii tar 1.34+dfsg-1 ii xz-utils 5.2.5-2 Versions of packages dpkg-dev recommends: ii build-essential 12.9 ii clang-11 [c-compiler]1:11.0.1-2 ii fakeroot 1.25.3-1.1 ii gcc [c-compiler] 4:10.2.1-1 ii gcc-10 [c-compiler] 10.2.1-6 ii gnupg2.2.27-2 ii gpgv 2.2.27-2 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2021.07.26 -- no debconf information
Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32
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 like to get some insights why the automatic mechanism did not work out.
I'm downgrading the severity, as the package can be easily made fully functional
by upgrading libc6 manually.
Best regards,
Joachim
Bug#1000024: cppcheck: depends on obsolete pcre3 library
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, Joachim
Bug#988986: ABI change in tinyxml2 8.1.0+dfsg-1
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
Bug#988986: cppcheck: Symbol `_ZTVN8tinyxml210XMLPrinterE' has different size in shared object, consider re-linking
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+dfsg-2, and migrated to testing. On 2021-05-20, tinyxml2 8.1.0+dfsg-1 was uploaded to unstable. Running "touch foo.cpp; cppcheck foo.cpp" works as expected in testing, but shows "_cppcheck: Symbol `_ZTVN8tinyxml210XMLPrinterE' has different size in shared object, consider re-linking" in unstable. $ echo _ZTVN8tinyxml210XMLPrinterE | c++filt vtable for tinyxml2::XMLPrinter Indeed, the diff both between versions of tinyxml shows that the vtable of XMLPrinter has been extended. Looks to me as this ABI change requires at least a library transition. Thinking a bit more about it ... This also changes the vtable of derived class (XMLPrinter is not final) in an incompatible way , which can be seen with the example in the contrib folder. Building against 8.0.0+dfsg-2 and running with 8.1.0+dfsg-1 leads to a crash. I wonder why upstream did not bump the SOVERSION. Best regards, Joachim
Bug#985671: CVE-2020-35636 CVE-2020-35628 CVE-2020-28636 CVE-2020-28601
tags 985671 + pending thanks
Bug#977328: false positive when passing variables to functions by address
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 positives for me. (I should retest some of my previous false positives that I've been suppressing and see if others are fixed; they probably are.) Ok, good to know. The first and third issue are fixed in the upstream master branch. For the second issue, upstream asked for a separate bug report which is at https://trac.cppcheck.net/ticket/10062#ticket .
Bug#977951: RM: zimpl -- ROM; Changed development model
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 form. While the license of zimpl itself is supposed to remain as before, I was not able to verify this due to that barrier (nor to investigate how easy it would be to unbundle zimpl from the larger software package). Best regards, Joachim
Bug#977328: false positive when passing variables to functions by address
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 943463. Now the tricky question: how frequent/annoying are these regressions with large code bases, i.e., with existing real-world code? Is version 2.3 a net improvement over version 2.2? Should we keep 2.3 out of testing for now (and possibly out of the upcoming release)?
Bug#977328: false positive when passing variables to functions by address
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, let me double-check ... The common theme in all three cases is that a variable is passed by address to another function (via adding its address to a struct or just directly), and cppcheck loses track of the fact that function may have changed its value. In the first case, I think the (void *) cast is the key. If it's removed, cppcheck understands the code correctly. (But this is sometimes required by badly-designed APIs.) Ok, confirmed. In the second case, something about adding retval to the test messes up its understanding of the data flow. Removing retval from the if() condition does not change anything for me. Could you double-check? The third case seems similar to the previous set of bugs, although note that it only happens with assignment. If that line is instead replaced with something like call_c(foo->flag), there is no error. I suppose you meant replacing "blah.flag = foo->flag;" by "call_c(foo->flag)"? This does not change anything for me. Is "call_b();" relevant in this test? Best regards, Joachim
Bug#966386: cppcheck: crashes with --clang option (.c)
-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 about that. I'll try to relay further input to the upstream bug tracker. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErX6NzLwwsr4xjsEVuPr/HEOIZ3EFAl8xeWYACgkQuPr/HEOI Z3GVchAA3DIxpEqS9zpNEJO0Nu+Pn9L/Vk5Gs8Biqs+egyeGr93jJ3Msiz0HndJy 5MdQUXWn+y3QLkSMlRWJNyNTEHoNEiqgFnzr07wkgR7mrdyPIOssROGodr0ybKVt L+1trN+DTxWcxRjDlRB1vtzUrqptLV9k38R0o0BQNwR3MH9JmqHH8rSZjAIkMYJe qs6x1pVY5l4S1uf+w9W7+G2FQm68FsieDx5NfoQ42V6lwdIGCTlZjxNWX5+M0xTj P081lPtSnYv7lJ4ZydUL2p5MJJQbKoZPMGc3HFpk8w+CtlQEu8RJeKOdG+N/3anm PcdDKcl6tkuAYLJ6H2lrYlqCdlbGbKoq8IT33WGiUgOUn1MN9CZ5sFHw3+vJBS5F GUOA/+FQiorImPkj04BBR2519isfSnyc77H3+Ml2pemih7JXlMqhzU02jFvtYDk5 +I9yD+w/K0A2aPV57GPulKZgSiomwy3aMPn1ra+jv7Gedck8TvXNUtGgy2aLdwD4 zdhKMe5IIneY5FAkqrddEW5jK6DLw9f0aCuYMt0QmUzRJNy69G15PFGHBXk/m7kA +MElU8o8pInYDVNmRSSYlgbMYMQe9zc7hfwiH0SX+NuG2RaN9k0gn5Zcw2w6rWjV 54PC2jNJbClqTkHfpmNAtQJhaB7DmlIHsVXs2O2ZA31R8e8OG7g= =cYnU -END PGP SIGNATURE-
Bug#966386: cppcheck: crashes with --clang option (.c)
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 you can see in the upstream bug, the build type Release seems to play an important part in my attempts to reproduce the bug. > As you can see from the CMake log it does detect that I have clang-tidy at > build time, which I don't think it would building the package since it > doesn't > appear to be a build-dep. Correct, but that should not be relevant here. I can also reproduce the crash if clang-tidy is installed at build time. (I'll probably add clang-tidy to Build-Depends in the next upload.) If you have further information to provide, please consider adding them to the upstream bug such that all information is in one place. Thanks! Best regards, Joachim
Bug#957563: mpg321: ftbfs with GCC-10
NMU uploaded to delayed/10. Basically mpg321_common.diff plus an additional fix for another FTBFS related to circular build dependencies. Updated diff attached. Best regards, Joachim diff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog --- mpg321-0.3.2/debian/changelog 2019-03-13 15:59:02.0 +0100 +++ mpg321-0.3.2/debian/changelog 2020-07-23 17:22:42.0 +0200 @@ -1,3 +1,15 @@ +mpg321 (0.3.2-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Export CFLAGS to make them take effect. + * Add -Wno-error=format-security to CFLAGS to disable 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 (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.3.2/debian/rules 2012-05-01 08:53:43.0 +0200 +++ mpg321-0.3.2/debian/rules 2020-07-23 17:22:42.0 +0200 @@ -4,7 +4,7 @@ #export DH_VERBOSE=1 -CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused +export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -fcommon MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS) @@ -24,15 +24,14 @@ endif touch configure-stamp -build: configure-stamp build-arch build-indep -build-arch: build-stamp -build-indep: build-stamp -build-stamp: build install +build: build-arch build-indep +build-arch: configure-stamp +build-indep: configure-stamp clean: dh_testdir dh_testroot - rm -f build-stamp configure-stamp + rm -f configure-stamp # Add here commands to clean up after the build process. [ ! -f Makefile ] || $(MAKE) distclean
Bug#966386: crashes with --clang option
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 able to reproduce it, since I tried with a C++ file, but the crash happens only with C. Best regards, Joachim
Bug#957563: mpg321: ftbfs with GCC-10
tag 957563 + patch
thanks
Attached is the patch mpg321_common.diff that adds -fcommon to CFLAGS (see
http://gcc.gnu.org/gcc-10/porting_to.html), plus adding "export" to make them
take effect, and demoting one error to warning again.
I've also attached the patch mpg321_extern.diff which fixes the actual cause
for the problem (builds fine, but didn't really test the resulting binary).
You might want to forward it to upstream.
Best regards,
Joachim
diff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog
--- mpg321-0.3.2/debian/changelog 2019-03-13 15:59:02.0 +0100
+++ mpg321-0.3.2/debian/changelog 2020-07-23 17:22:42.0 +0200
@@ -1,3 +1,13 @@
+mpg321 (0.3.2-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Export CFLAGS to make them take effect.
+ * Add -Wno-error=format-security to CFLAGS to disable the default from
+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
--- mpg321-0.3.2/debian/rules 2012-05-01 08:53:43.0 +0200
+++ mpg321-0.3.2/debian/rules 2020-07-23 17:22:42.0 +0200
@@ -4,7 +4,7 @@
#export DH_VERBOSE=1
-CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused
+export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -fcommon
MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details).
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update: 2020-07-23
--- mpg321-0.3.2.orig/mpg321.h
+++ mpg321-0.3.2/mpg321.h
@@ -116,7 +116,7 @@ extern char *playlist_file;
extern int quit_now;
extern char remote_input_buf[PATH_MAX + 5];
extern int file_change;
-int loop_remaining;
+extern int loop_remaining;
extern int status;
extern int scrobbler_time;
@@ -233,8 +233,8 @@ RETSIGTYPE handle_sigchld(int sig);
#define FFT_BUFFER_SIZE_LOG 9
#define FFT_BUFFER_SIZE (1 << FFT_BUFFER_SIZE_LOG) /* 512 */
/*Temporary data stores to perform FFT in */
-double real[FFT_BUFFER_SIZE];
-double imag[FFT_BUFFER_SIZE];
+extern double real[FFT_BUFFER_SIZE];
+extern double imag[FFT_BUFFER_SIZE];
typedef struct {
double real[FFT_BUFFER_SIZE];
@@ -258,10 +258,10 @@ fft_state *fft_init(void);
/* Output buffer process */
void frame_buffer_p();
/* Semaphore array */
-int semarray;
+extern int semarray;
/* Input/Output buffer position */
-int mad_decoder_position;
-int output_buffer_position;
+extern int mad_decoder_position;
+extern int output_buffer_position;
/* Output Frame including needed information */
typedef struct {
unsigned char data[4*1152];
@@ -285,10 +285,10 @@ typedef struct {
} decoded_frames;
/* Output frame queue pointer */
-output_frame *Output_Queue;
+extern output_frame *Output_Queue;
/* Shared total decoded frames */
-decoded_frames *Decoded_Frames;
+extern decoded_frames *Decoded_Frames;
#if defined(__GNU_LIBRARY__) && !defined(_SEM_SEMUN_UNDEFINED)
/* */
--- mpg321-0.3.2.orig/mpg321.c
+++ mpg321-0.3.2/mpg321.c
@@ -90,6 +90,7 @@ mad_timer_t current_time;
mpg321_options options = { 0, NULL, NULL, 0 , 0, 0};
int status = MPG321_STOPPED;
int file_change = 0;
+int loop_remaining = 0;
int remote_restart = 0;
int muted = 0;
char *id3_get_tag (struct id3_tag const *tag, char const *what, unsigned int maxlen);
@@ -104,6 +105,15 @@ extern http_file_length;
/* ALSA Volume Range */
extern long volume_min,volume_max;
#endif
+
+double real[FFT_BUFFER_SIZE];
+double imag[FFT_BUFFER_SIZE];
+int semarray;
+int mad_decoder_position;
+int output_buffer_position;
+output_frame *Output_Queue;
+decoded_frames *Decoded_Frames;
+
/* Get the next frame in the round buffer */
int getnext_place(int position)
{
Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"
forwarded 962236 https://savannah.nongnu.org/bugs/index.php?58504 thanks
Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"
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
Bug#961925: cppcheck-gui: reports errors from python when running python addons
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
Bug#960476: transition: tinyxml2
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 by , may conflict with libtinyxml2.so.8" Apparently this unexpected output causes the test to fail ... What is the best way to make progress here? Best regards, Joachim
Bug#923325: cppcheck: Memory leak no longer detected
notfound 923325 1.89-1 thanks
Bug#923325: cppcheck: Memory leak no longer detected
notfound 923325 1.89.1 thanks
Bug#952398: Add forward URL and upstream tag
forwarded 952398 http://trac.cppcheck.net/ticket/9657 tag 952398 + upstream forwarded 952400 http://trac.cppcheck.net/ticket/9658 tag 952400 + upstream thanks
Bug#946233: Non-deterministic build depending on presence of cmake
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 toolchain all the time. Adding a Build-Conflicts: would do the right thing, but might be a bit drastic. There seems to be another solution: pybuild supports "-s" or "--system" to select "distutils". Not sure how to make dh to pass arguments to pybuild ... But pybuild also supports the environment variable PYBUILD_SYSTEM. Just mentioning, I did not test that.
Bug#949800: libcgal-qt5-dev: Recommend qt?
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 > Severity: wishlist > > Dear Maintainer, > > I notice that libcgal-qt5-dev does not depend in any way on Qt and does > not even suggest installing any Qt packages. > > Before header-only, it depended on libcgal-qt5-13, which in turn > installed several Qt dependencies, although probably not enough to do > development. It looks like the Suggestions in libcgal-demo are the only > ones that actually install Qt dev packages. > > Do you think it would make sense to have libcgal-qt5-dev recommend some > Qt packages? I don't know how much one can do with this package without > Qt (I haven't tried). > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, > 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libcgal-qt5-dev depends on: > ii libcgal-dev 5.0-5+b1 > > libcgal-qt5-dev recommends no packages. > > libcgal-qt5-dev suggests no packages. > > -- no debconf information >
Bug#949944: cppcheck-htmlreport not packaged anymore in sid
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
Bug#949305: Build system selection is not deterministic
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 should be eliminated. See bug 946233 for an example where this shows up. Best regards, Joachim
Bug#946233: Non-deterministic build depending on presence of cmake
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 deployment. Ok, fine. I didn't want to suggest that the cmake build is better -- it is mainly about the discrepancy. After some debugging I found out why this happens: If you add "print (tmp_plugin, tmp_certainty)" in line 105 of /usr/bin/pybuild, you'll see that there is a tie between distutils and cmake and the first one tried wins. The order in which the plugins are tried is the file order in the directory /usr/share/dh-python/dhpython/build. In one chroot where I can reproduce the problem I see cmake first: $ ls -U1 /usr/share/dh-python/dhpython/build plugin_cmake.py plugin_custom.py base.py __init__.py plugin_distutils.py __pycache__ In another chroot where I can not reproduce the problem I see distutils first: $ ls -U1 /usr/share/dh-python/dhpython/build __init__.py plugin_distutils.py __pycache__ plugin_custom.py base.py plugin_cmake.py I guess the latter is also the case for the environment you used. I'll file a separate bug on dh-python. But since this is probably rather an implementation detail on their side, and for the being, I think a Build-Conflicts: cmake is in order for pygalmesh. Best regards, Joachim
Bug#949296: Fails with "Unknown DWARF DW_OP_255"
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 from stable. I can provide the cppcheck binary on request if you can't reproduce it. Best regards, Joachim -- System Information: Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dwz depends on: ii libc62.29-9 ii libelf1 0.176-1.1 dwz recommends no packages. dwz suggests no packages. -- no debconf information
Bug#949199: cppcheck-gui: Missing dependency on cppcheck
Control: tags -1 +pending Hi, right, cppcheck-gui needs the cfg files which are in package cppcheck. Joachim
Bug#949181: cppcheck: Improve debian/rules, reenabling parallel building
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. Joachim
Bug#948124: Fails with "Sectors have a size of zero"
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! sortFileSystem: Failed to open file system! main: Failed to sort file system! The current upstream release 1.6.2.605 works without problems. Best regards, Joachim -- System Information: Debian Release: 10.2 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fatsort depends on: ii libc6 2.28-10 fatsort recommends no packages. fatsort suggests no packages. -- no debconf information
Bug#944417: transition: cgal
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 sfcgal fixed by maintainer, all green but armhf (#946261) crrcsimNMU in delayed queue (#946114), 3 days to go openemsbinNMU would be sufficient, unrelated FTBFS (#946264), but not on autoremoval list (WHY?) k3dpatch in BTS (#946228), unrelated FTBFS (#946225), autoremoval in 6 days rheolefpatch in BTS (#946116), unrelated FTBFS (#944197), autoremoval in 10 days yade patch in BTS (#946223), unrelated FTBFS (#938859), autoremoval in 12 days, maintainer working on it pprepair removed from unstable and testing (#944775, #946133) prepairremoved from unstable and testing (#944776, #946134) Joachim
Bug#944417: transition: cgal
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
Bug#944417: transition: cgal
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 maintainer, but armhf and mips64el still missing crrcsimNMU in delayed queue (#946114), 4 days to go pygalmesh NMU in delayed queue (#946234), 5 days to go openemsbinNMU would be sufficient, unrelated FTBFS (#946264), autoremoval in ? days k3dpatch in BTS (#946228), unrelated FTBFS (#946225), autoremoval in 7 days rheolefpatch in BTS (#946116), unrelated FTBFS (#944197), autoremoval in 11 days yade patch in BTS (#946223), unrelated FTBFS (#938859), autoremoval in 11 days, maintainer working on it pprepair FTBFS, no patch known (#944775), autoremoval in 13 days prepairFTBFS, no patch known (#944776), autoremoval in 14 days (Due to changes in libboost-python1.67(.0|-dev) between -13 and -15, more packages FTBFS than previously reported (openems, k3d, yade)). Joachim
Bug#946234: [NMU] FTFBS with CGAL 5.0 (if cmake is absent)
> 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.
Bug#946264: openems: FTBFS (affects CGAL transition)
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/package.php?p=openems . This might be the same problem as in bug #944144, but I'm not sure. Best regards, Joachim
Bug#946114: FTFBS with CGAL 5.0 (NMU)
Uploaded to DELAYED/5-day.
Bug#944417: Bug#946119: binNMU for gudhi, openems, and pygalmesh
Hi Paul, On 05.12.19 10:20, Paul Gevers wrote: > Note: there is no need to create a new bug report for binNMU's that are > part of a transition with a transition bug. ok, thanks. > That said, mips64el and mipsel FTBFS, can you please check what's going on? I uploaded -4 which 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
Bug#946234: [NMU] FTFBS with CGAL 5.0 (if cmake is absent)
Source: pygalmesh Version: 0.4.0-1 Severity: serious Tags: ftbfs Control: block 944417 by -1 Hi, the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS (if cmake is not present, see the other bug I just filed). I intend to NMU the package with the attached diff to DELAYED/5-day. Best regards, Joachim diff -Nru pygalmesh-0.4.0/debian/changelog pygalmesh-0.4.0/debian/changelog --- pygalmesh-0.4.0/debian/changelog2019-08-18 18:42:35.0 +0200 +++ pygalmesh-0.4.0/debian/changelog2019-12-05 23:07:13.0 +0100 @@ -1,3 +1,11 @@ +pygalmesh (0.4.0-1.1) 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/watch to track upstream git tags, diff -Nru pygalmesh-0.4.0/debian/control pygalmesh-0.4.0/debian/control --- pygalmesh-0.4.0/debian/control 2019-08-18 18:42:35.0 +0200 +++ pygalmesh-0.4.0/debian/control 2019-12-05 23:07:13.0 +0100 @@ -5,7 +5,7 @@ Uploaders: Drew Parsons Build-Depends: debhelper-compat (= 12), dh-python, python3-all-dev, python3-setuptools, - libcgal-dev, + libcgal-dev (>= 5.0~), libeigen3-dev, pandoc, python3-meshio, diff -Nru pygalmesh-0.4.0/debian/patches/series pygalmesh-0.4.0/debian/patches/series --- pygalmesh-0.4.0/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ pygalmesh-0.4.0/debian/patches/series 2019-12-05 23:06:31.0 +0100 @@ -0,0 +1 @@ +use-cgal-in-header-only-mode.patch diff -Nru pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch --- pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch 1970-01-01 01:00:00.0 +0100 +++ pygalmesh-0.4.0/debian/patches/use-cgal-in-header-only-mode.patch 2019-12-05 23:07:13.0 +0100 @@ -0,0 +1,14 @@ +Index: pygalmesh-0.4.0/setup.py +=== +--- pygalmesh-0.4.0.orig/setup.py pygalmesh-0.4.0/setup.py +@@ -48,8 +48,7 @@ ext_modules = [ + get_pybind_include(), + get_pybind_include(user=True), + ], +-# CGAL_ImageIO for generate_from_inr +-libraries=["CGAL", "CGAL_ImageIO", "gmp", "mpfr"], ++libraries=["stdc++", "gmp", "mpfr"], + ) + ] +
Bug#946233: Non-deterministic build depending on presence of cmake
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--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:217: dh_auto_configure --buildsystem=cmake --builddirectory="/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build" -- -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.8 -DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8 cd .pybuild/cpython3_3.8_pygalmesh/build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.8 -DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8 ../../.. --- Without cmake: --- debian/rules build dh build --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:217: python3.8 setup.py config running config I: pybuild base:217: python3.7 setup.py config running config debian/rules override_dh_auto_build make[1]: Entering directory '/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0' dh_auto_build I: pybuild base:217: /usr/bin/python3.8 setup.py build running build running build_py creating /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/__about__.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/cli.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/main.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/__init__.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh [...] --- You should either add a Build-Depends or Build-Conflicts on cmake to make the build deterministic. With cmake, a binNMU would have been sufficient for the CGAL 5.0 transition. Without cmake (which is likely the case on the buildds), a sourceful upload is necessary. Best regards, Joachim
Bug#946229: [NMU] FTFBS with CGAL 5.0
Source: sfcgal
Version: 1.3.7-2
Severity: serious
Tags: ftbfs
Control: block 944417 by -1
Hi,
the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS. I
intend to NMU the package with the attached diff to DELAYED/5-day.
Best regards,
Joachim
diff -Nru sfcgal-1.3.7/debian/changelog sfcgal-1.3.7/debian/changelog
--- sfcgal-1.3.7/debian/changelog 2019-08-18 07:57:14.0 +0200
+++ sfcgal-1.3.7/debian/changelog 2019-12-05 21:34:40.0 +0100
@@ -1,3 +1,11 @@
+sfcgal (1.3.7-2.1) 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 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-1.3.7/debian/control
--- sfcgal-1.3.7/debian/control 2019-08-18 07:55:35.0 +0200
+++ sfcgal-1.3.7/debian/control 2019-12-05 21:34:40.0 +0100
@@ -6,7 +6,7 @@
Priority: optional
Build-Depends: debhelper (>= 9.20160114),
cmake,
- libcgal-dev (>= 4.10.1),
+ libcgal-dev (>= 5.0~),
libboost-all-dev,
libmpfr-dev,
libgmp-dev,
diff -Nru sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch
sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch
--- sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch 1970-01-01
01:00:00.0 +0100
+++ sfcgal-1.3.7/debian/patches/fix-ftbfs-with-cgal-5.x.patch 2019-12-05
21:34:40.0 +0100
@@ -0,0 +1,44 @@
+Description: Require C++14 and CGAL >= 5.0
+Author: Joachim Reichel
+Bug: https://github.com/Oslandia/SFCGAL/issues/198
+
+Index: sfcgal-1.3.7/CMakeLists.txt
+===
+--- sfcgal-1.3.7.orig/CMakeLists.txt
sfcgal-1.3.7/CMakeLists.txt
+@@ -1,6 +1,8 @@
+ cmake_minimum_required( VERSION 2.8 )
+ project( SFCGAL )
+
++set(CMAKE_CXX_STANDARD 14)
++
+ set( CMAKE_DEBUG_POSTFIX "d" )
+
+ #
+@@ -51,19 +53,19 @@ endif()
+
+ # 4.3 minimal
+ # 4.13 recommended
+-find_package( CGAL 4.3 COMPONENTS Core REQUIRED )
++find_package( CGAL COMPONENTS Core REQUIRED )
+ message( STATUS "CGAL ${CGAL_VERSION} found" )
+
+ include_directories( ${CMAKE_BINARY_DIR}/include )
+
+ # For CGAL versions < 4.3, we add a local directory that contains some
tweaked include files from unreleased versions
+ # They will overwrite files from the CGAL installation
+-if( "${CGAL_VERSION}" VERSION_LESS "4.3" )
+- include_directories( patches/CGAL-4.2 )
+-elseif( "${CGAL_VERSION}" VERSION_LESS "4.10")
+- include_directories( patches/CGAL-4.3 )
+- add_definitions( "-DCGAL_INTERSECTION_VERSION=1" )
+-endif()
++# if( "${CGAL_VERSION}" VERSION_LESS "4.3" )
++# include_directories( patches/CGAL-4.2 )
++# elseif( "${CGAL_VERSION}" VERSION_LESS "4.10")
++# include_directories( patches/CGAL-4.3 )
++# add_definitions( "-DCGAL_INTERSECTION_VERSION=1" )
++# endif()
+
+ #-- BOOST --
+ option( Boost_USE_AUTO_LINK "boost use autolink" OFF )
diff -Nru sfcgal-1.3.7/debian/patches/fix-linker-error.patch
sfcgal-1.3.7/debian/patches/fix-linker-error.patch
--- sfcgal-1.3.7/debian/patches/fix-linker-error.patch 1970-01-01
01:00:00.0 +0100
+++ sfcgal-1.3.7/debian/patches/fix-linker-error.patch 2019-12-05
21:34:40.00000 +0100
@@ -0,0 +1,82 @@
+Description: Force GMPXX as workaround for a linker error (used to be the
+ default for CGAL 4.x packages)
+Author: Joachim Reichel
+Bug: https://github.com/Oslandia/SFCGAL/issues/198
+
+Index: sfcgal-1.3.7/CMakeLists.txt
+===
+--- sfcgal-1.3.7.orig/CMakeLists.txt
sfcgal-1.3.7/CMakeLists.txt
+@@ -55,6 +55,7 @@ endif()
+ # 4.13 recommended
+ find_package( CGAL COMPONENTS Core REQUIRED )
+ message( STATUS "CGAL ${CGAL_VERSION} found" )
++add_definitions( "-DCGAL_USE_GMPXX=1" )
+
+ include_directories( ${CMAKE_BINARY_DIR}/include )
+
+Index: sfcgal-1.3.7/test/garden/CMakeLists.txt
+===
+--- sfcgal-1.3.7.orig/test/garden/CMakeLists.txt
sfcgal-1.3.7/test/garden/CMakeLists.txt
+@@ -7,7 +7,7 @@ set( REGRESS_NAME garden-test-SFCGAL )
+ add_executable( ${REGRESS_NAME} ${SFCGAL_REGRESS_GARDEN_TEST_SOURCES} )
+
+ target_link_libraries( ${REGRESS_NAME} SFCGAL)
+-target_link_libraries( ${REGRESS_NAME} ${CGAL_3RD_PARTY_LIBRARIES}
${Boost_LIBRARIES})
++target_link_libraries( ${REGRESS_NAME} gmpxx ${CGAL_3RD_PARTY_LIBRARIES}
${Boost_LIBRARIES})
+
+ set_target_p
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
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 difficult than necessary. Joachim
Bug#946228: FTBFS with CGAL 5.0
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 applying these two patches is not enough to unblock the transition due
to bug #946225.
Best regards,
Joachim
Index: k3d-0.8.0.6/CMakeLists.txt
===
--- k3d-0.8.0.6.orig/CMakeLists.txt
+++ k3d-0.8.0.6/CMakeLists.txt
@@ -7,7 +7,7 @@ IF(${CMAKE_MAJOR_VERSION} GREATER 3 OR $
CMAKE_POLICY(SET CMP0026 OLD)
ENDIF()
-set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD 14)
SET(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules")
Index: k3d-0.8.0.6/cmake/modules/K3DFindCGAL.cmake
===
--- k3d-0.8.0.6.orig/cmake/modules/K3DFindCGAL.cmake
+++ k3d-0.8.0.6/cmake/modules/K3DFindCGAL.cmake
@@ -7,11 +7,6 @@ FIND_PATH(K3D_CGAL_INCLUDE_DIR CGAL
)
MARK_AS_ADVANCED(K3D_CGAL_INCLUDE_DIR)
-FIND_LIBRARY(K3D_CGAL_LIBRARY CGAL
- DOC "The CGAL library"
- )
-MARK_AS_ADVANCED(K3D_CGAL_LIBRARY)
-
FIND_LIBRARY(K3D_MPFR_LIBRARY mpfr
DOC "The mpfr library"
)
@@ -22,7 +17,7 @@ FIND_LIBRARY(K3D_GMP_LIBRARY gmp
)
MARK_AS_ADVANCED(K3D_GMP_LIBRARY)
-IF(K3D_CGAL_INCLUDE_DIR AND K3D_CGAL_LIBRARY AND K3D_MPFR_LIBRARY AND
K3D_GMP_LIBRARY)
+IF(K3D_CGAL_INCLUDE_DIR AND K3D_MPFR_LIBRARY AND K3D_GMP_LIBRARY)
SET(K3D_CGAL_FOUND 1)
-ENDIF(K3D_CGAL_INCLUDE_DIR AND K3D_CGAL_LIBRARY AND K3D_MPFR_LIBRARY AND
K3D_GMP_LIBRARY)
+ENDIF(K3D_CGAL_INCLUDE_DIR AND K3D_MPFR_LIBRARY AND K3D_GMP_LIBRARY)
Index: k3d-0.8.0.6/modules/cgal/CMakeLists.txt
===
--- k3d-0.8.0.6.orig/modules/cgal/CMakeLists.txt
+++ k3d-0.8.0.6/modules/cgal/CMakeLists.txt
@@ -6,7 +6,6 @@ K3D_BUILD_MODULE(k3d-cgal)
K3D_CREATE_MODULE_PROXY(k3d-cgal)
TARGET_LINK_LIBRARIES(k3d-cgal
- ${K3D_CGAL_LIBRARY}
${K3D_MPFR_LIBRARY}
${K3D_GMP_LIBRARY}
${Boost_THREAD_LIBRARY}
Bug#946225: FTBFS related to Boost.Python
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 Stack (most recent call first): /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.15/Modules/FindBoost.cmake:2161 (find_package_handle_standard_args) cmake/modules/K3DFindBoost.cmake:9 (FIND_PACKAGE) CMakeLists.txt:254 (INCLUDE) This might have been caused by bug 945840. Best regards, Joachim -- System Information: Debian Release: 10.2 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#946223: [NMU] FTFBS with CGAL 5.0
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 applying these two patches is not enough due to bug #938859. What is your
planned timeline for an upload to unstable?
Best regards,
Joachim
-- System Information:
Debian Release: 10.2
APT prefers stable-debug
APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'),
(700, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: yade-2019.01a/CMakeLists.txt
===
--- yade-2019.01a.orig/CMakeLists.txt
+++ yade-2019.01a/CMakeLists.txt
@@ -299,7 +299,7 @@ IF(ENABLE_CGAL)
FILE(GLOB CGAL_SRC_LIB "lib/triangulation/*.cpp")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CGAL_DEFINITIONS} -DYADE_CGAL")
-SET(LINKLIBS
"${LINKLIBS};${CGAL_LIBRARIES};${GMP_LIBRARIES};${GMPXX_LIBRARIES};")
+SET(LINKLIBS "${LINKLIBS};${GMP_LIBRARIES};${GMPXX_LIBRARIES};")
MESSAGE(STATUS "Found CGAL")
SET(CONFIGURED_FEATS "${CONFIGURED_FEATS} CGAL")
Index: yade-2019.01a/cMake/FindCGAL.cmake
===
--- yade-2019.01a.orig/cMake/FindCGAL.cmake
+++ yade-2019.01a/cMake/FindCGAL.cmake
@@ -7,38 +7,26 @@
# This module defines
# CGAL_DEFINITIONS: compiler flags for compiling with CGAL
# CGAL_INCLUDE_DIR: where to find CGAL.h
-# CGAL_LIBRARIES: the libraries needed to use CGAL
# CGAL_FOUND: if false, do not try to use CGAL
-IF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+IF(CGAL_INCLUDE_DIR)
SET(CGAL_FOUND TRUE)
-ELSE(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+ELSE(CGAL_INCLUDE_DIR)
FIND_PATH(CGAL_INCLUDE_DIR CGAL/basic.h
/usr/include/
/usr/local/include/
$ENV{ProgramFiles}/CGAL/*/include/
$ENV{SystemDrive}/CGAL/*/include/
)
-FIND_LIBRARY(CGAL_LIBRARIES NAMES CGAL libCGAL
-PATHS
-/usr/lib
-/usr/local/lib
-/usr/lib/CGAL
-/usr/lib64
-/usr/local/lib64
-/usr/lib64/CGAL
-$ENV{ProgramFiles}/CGAL/*/lib/ms
-$ENV{SystemDrive}/CGAL/*/lib/ms
-)
-IF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+IF(CGAL_INCLUDE_DIR)
SET(CGAL_FOUND TRUE)
-MESSAGE(STATUS "Found CGAL: ${CGAL_INCLUDE_DIR}, ${CGAL_LIBRARIES}")
+MESSAGE(STATUS "Found CGAL: ${CGAL_INCLUDE_DIR}")
INCLUDE_DIRECTORIES(${CGAL_INCLUDE_DIR})
-ELSE(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+ELSE(CGAL_INCLUDE_DIR)
SET(CGAL_FOUND FALSE)
MESSAGE(STATUS "CGAL not found.")
-ENDIF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+ENDIF(CGAL_INCLUDE_DIR)
-MARK_AS_ADVANCED(CGAL_INCLUDE_DIR CGAL_LIBRARIES)
-ENDIF(CGAL_INCLUDE_DIR AND CGAL_LIBRARIES)
+MARK_AS_ADVANCED(CGAL_INCLUDE_DIR)
+ENDIF(CGAL_INCLUDE_DIR)
Index: yade-2019.01a/CMakeLists.txt
===
--- yade-2019.01a.orig/CMakeLists.txt
+++ yade-2019.01a/CMakeLists.txt
@@ -32,6 +32,8 @@
project(Yade C CXX)
cmake_minimum_required(VERSION 2.8.11)
+set(CMAKE_CXX_STANDARD 14)
+
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cMake")
INCLUDE(FindPythonInterp)
@@ -83,7 +85,7 @@ ELSE()
ENDIF()
ENDIF()
-SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -O2 --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall -std=c++11")
+SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -O2 --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall -std=c++14")
IF (DEBUG)
SET(CMAKE_VERBOSE_MAKEFILE 1)
Bug#946119: binNMU for gudhi, openems, and pygalmesh
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 'libcgal-dev (>= 5.0)' nmu openems_0.0.35+git20190103.6a75e98+dfsg.1-1 . ANY . -m 'Rebuild against libcgal-dev >= 5.0' dw openems_0.0.35+git20190103.6a75e98+dfsg.1-1 . ANY . -m 'libcgal-dev (>= 5.0)' nmu pygalmesh_0.4.0-1 . ANY . -m 'Rebuild against libcgal-dev >= 5.0' dw pygalmesh_0.4.0-1 . ANY . -m 'libcgal-dev (>= 5.0)' Best regards, Joachim
Bug#946116: FTBFS with CGAL 5.0
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,
Joachim
Index: rheolef-7.0/configure.ac
===
--- rheolef-7.0.orig/configure.ac
+++ rheolef-7.0/configure.ac
@@ -600,29 +600,10 @@ dnl is it a well-known C++ compiler ?
dnl-
RHEO_RECOGNIZE_CXX
if test x"${rheo_cxx}" = x"gnu"; then
-RHEO_GXX2011
-if test x"${rheo_gxx2011}" = x"yes"; then
- if test x"${rheo_have_float128}" = x"yes"; then
-CXXFLAGS="${CXXFLAGS} -std=gnu++11"
- else
-CXXFLAGS="${CXXFLAGS} -std=c++11"
- fi
-else
- RHEO_GXX2011_PRE
- if test x"${rheo_gxx2011_pre}" = x"yes"; then
-if test x"${rheo_have_float128}" = x"yes"; then
- CXXFLAGS="${CXXFLAGS} -std=gnu++0x"
-else
- CXXFLAGS="${CXXFLAGS} -std=c++0x"
-fi
- else
-CXXFLAGS="${CXXFLAGS} -ansi"
- fi
-fi
-CXXFLAGS="${CXXFLAGS} -Wall ${permissive_opts} -Wno-unused
-Wno-strict-aliasing -Wno-literal-suffix -Wno-deprecated-declarations"
+CXXFLAGS="${CXXFLAGS} -Wall ${permissive_opts} -Wno-unused
-Wno-strict-aliasing -Wno-literal-suffix -Wno-deprecated-declarations
-std=c++14"
LDFLAGS="${LDFLAGS} -Wl,--as-needed"
elif test x"${rheo_cxx}" = x"clang"; then
-CXXFLAGS="${CXXFLAGS} -Wall ${permissive_opts} -Wno-unused
-Wno-strict-aliasing -Wno-deprecated-declarations -Wno-deprecated-register
-std=c++11"
+CXXFLAGS="${CXXFLAGS} -Wall ${permissive_opts} -Wno-unused
-Wno-strict-aliasing -Wno-deprecated-declarations -Wno-deprecated-register
-std=c++14"
LDFLAGS="${LDFLAGS} -Wl,--as-needed"
fi
#echo "CXXFLAGS ${CXXFLAGS}"
Index: rheolef-7.0/configure.ac
===
--- rheolef-7.0.orig/configure.ac
+++ rheolef-7.0/configure.ac
@@ -1726,7 +1726,7 @@ with_cgal="yes"
rheo_incdir_cgal=""
rheo_libdir_cgal=""
#rheo_libs_cgal="-lCGAL_Core -lCGAL -lboost_thread"
-rheo_libs_cgal="-lCGAL -lgmp"
+rheo_libs_cgal="-lgmp"
AC_ARG_WITH(cgal-incdir,
[ --with-cgal-incdir[[=DIR]] the cgal computational geometry
includes directory (default=autodetect) ],
[ case "${withval}" in
@@ -1752,7 +1752,7 @@ AC_ARG_WITH(cgal-libdir,
[ rheo_libdir_cgal="" ]
)
AC_ARG_WITH(cgal-libs,
-[ --with-cgal-libs[[=LIBS]] the cgal computational geometry library
linker flags (default=-lCGAL) ],
+[ --with-cgal-libs[[=LIBS]] the cgal computational geometry library
linker flags (default=-lgmp) ],
[ case "${withval}" in
yes|no) with_cgal=${withval};;
*) rheo_libs_cgal=${withval}
Bug#946114: FTFBS with CGAL 5.0 (NMU)
Source: crrcsim Version: 0.9.13-3.1 Severity: serious Tags: ftbfs Control: block 944417 by -1 Hi, the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS. I intend to NMU the package with the attached diff to DELAYED/5-day. Best regards, Joachim diff -Nru crrcsim-0.9.13/debian/changelog crrcsim-0.9.13/debian/changelog --- crrcsim-0.9.13/debian/changelog 2018-12-22 00:02:57.0 +0100 +++ crrcsim-0.9.13/debian/changelog 2019-12-03 22:22:43.0 +0100 @@ -1,3 +1,11 @@ +crrcsim (0.9.13-3.2) 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 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-0.9.13/debian/control --- crrcsim-0.9.13/debian/control 2018-12-22 00:02:43.0 +0100 +++ crrcsim-0.9.13/debian/control 2019-12-03 22:22:43.0 +0100 @@ -9,7 +9,7 @@ libsdl1.2-dev, libboost-thread-dev, libplib-dev, - libcgal-dev, + libcgal-dev (>= 5.0~), libjpeg-dev, portaudio19-dev, Standards-Version: 4.1.4 diff -Nru crrcsim-0.9.13/debian/patches/10-cgal-use-header-only-mode.patch crrcsim-0.9.13/debian/patches/10-cgal-use-header-only-mode.patch --- crrcsim-0.9.13/debian/patches/10-cgal-use-header-only-mode.patch 1970-01-01 01:00:00.0 +0100 +++ crrcsim-0.9.13/debian/patches/10-cgal-use-header-only-mode.patch 2019-12-03 22:22:43.0 +0100 @@ -0,0 +1,13 @@ +Index: crrcsim-0.9.13/configure.ac +=== +--- crrcsim-0.9.13.orig/configure.ac crrcsim-0.9.13/configure.ac +@@ -232,7 +232,7 @@ if (test "x$ac_cv_header_CGAL_Exact_pre + has_CGAL="yes (found CGAL v3)" + fi + CGAL_CFLAGS=-frounding-math +-CGAL_LIBS=-lCGAL ++CGAL_LIBS= + AC_DEFINE([WINDDATA3D], [1], [Import code for wind data, needs CGAL, 0 to disable]) + else + has_CGAL="no (CGAL not found)" diff -Nru crrcsim-0.9.13/debian/patches/series crrcsim-0.9.13/debian/patches/series --- crrcsim-0.9.13/debian/patches/series2018-12-01 16:49:34.0 +0100 +++ crrcsim-0.9.13/debian/patches/series2019-12-03 22:22:43.0 +0100 @@ -7,3 +7,4 @@ 07-add-libgmp.patch 08-boost_thread-mt-change.patch 09-remove-extra-std-err.patch +10-cgal-use-header-only-mode.patch
Bug#944775: FTBFS with CGAL 5.0
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
Bug#944776: FTBFS with CGAL 5.0
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
Bug#944417: transition: cgal
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 about the upcoming transition and included my patches, but did not file bugs so far. I'm in contact with the openscad maintainer, but did not receive any feedback from the other maintainers. (The prepair/pprepair maintainer replied in the FTBFS bug reports to remove those two packages from testing if they block the transition.) The changes are trivial (require at least C++14, do not link with CGAL libraries anymore). I'm ready to NMU the rdeps. Joachim
Bug#944417: transition: cgal
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 available pprepair FTBFS, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944775, https://github.com/tudelft3d/pprepair/issues/55 prepairFTBFS, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944776, https://github.com/tudelft3d/prepair/issues/35 pygalmesh binNMU should be sufficient rheolefneeds source code changes, patch available, unrelated FTBFS, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944197 sfcgal needs source code changes, patch available yade needs source code changes, patch available
Bug#944775: FTBFS with CGAL 5.0
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/ . Upstream bug: https://github.com/tudelft3d/pprepair/issues/55 Severity important for now, will be increased once the transition starts. Regards, Joachim -- System Information: Debian Release: 10.1 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pprepair depends on: pn gdal-abi-2-4-0 ii libc6 2.28-10 ii libcgal13 4.14-2~deb10u1 ii libgcc1 1:8.3.0-6 pn libgdal20 ii libgmp102:6.1.2+dfsg-4 ii libgmpxx4ldbl 2:6.1.2+dfsg-4 ii libmpfr64.0.2-1 ii libstdc++6 8.3.0-6 Versions of packages pprepair recommends: pn prepair pprepair suggests no packages.
Bug#944776: FTBFS with CGAL 5.0
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: https://github.com/tudelft3d/prepair/issues/35 Severity important for now, will be increased to RC once the transition starts. Regards, Joachim -- System Information: Debian Release: 10.1 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#944417: transition: cgal
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 reverse dependencies: 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 available pprepair FTBFS, https://github.com/tudelft3d/pprepair/issues/55 prepairFTBFS, https://github.com/tudelft3d/prepair/issues/35 pygalmesh binNMU should be sufficient rheolefneeds source code changes, patch available, unrelated FTBFS, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944197 sfcgal FTBFS, https://github.com/Oslandia/SFCGAL/issues/198 yade needs source code changes, patch available Ben file: title = "cgal"; is_affected = .depends ~ "libcgal13" | .depends ~ "libcgal-qt5-14"; is_good = ! ( .depends ~ "libcgal13" | .depends ~ "libcgal-qt5-14" ); is_bad = .depends ~ "libcgal13" | .depends ~ "libcgal-qt5-14"; -- System Information: Debian Release: 10.1 Architecture: amd64 (x86_64)
Bug#944361: cgal: cgal 5.0 released
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 changes due to the header-only mode now being the default. Also, CGAL 5.0 will need to go to experimental first and needs a transition slot. Yes, the package is not on salsa yet. I plan to do that eventually, but wanted to wait for the outcome of the currently ongoing discussion about git packaging. Joachim
Bug#925782: Patch for bug 925782
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 @@ extern "C" {
#define TExceptionN(n) public: virtual const char *name() const { return #n; }
#define TExceptionM(m) public: virtual const char *message() const { return m; }
-#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; asprintf(, m, a); return buf; }
-#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; asprintf(, m, a,b); return buf; }
-#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; asprintf(, m, a,b,c); return buf; }
-#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; asprintf(, m, a,b,c,d); return buf; }
+#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a); return result != -1 ? buf : "asprintf failure"; }
+#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b); return result != -1 ? buf : "asprintf failure"; }
+#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b,c); return result != -1 ? buf : "asprintf failure"; }
+#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b,c,d); return result != -1 ? buf : "asprintf failure"; }
// base class of all exceptions
class TException {
Index: mp3check-0.8.7/tstring.cc
===
--- mp3check-0.8.7.orig/tstring.cc
+++ mp3check-0.8.7/tstring.cc
@@ -111,7 +111,7 @@ tstring::Rep *tstring::Rep::clone(size_t
tstring::Rep *tstring::Rep::create(size_t tmem) {
size_t m = sizeof(Rep) << 1;
while((m - 1 - sizeof(Rep)) < tmem) m <<= 1;
- Rep *p = new (m - 1 - sizeof(Rep)) Rep;
+ Rep *p = new (/*tag*/ true, m - 1 - sizeof(Rep)) Rep;
p->mem = m - 1 - sizeof(Rep); p->ref = 1; p->vulnerable = false;
return p;
}
Index: mp3check-0.8.7/tstring.h
===
--- mp3check-0.8.7.orig/tstring.h
+++ mp3check-0.8.7/tstring.h
@@ -71,9 +71,12 @@ class tstring {
// static methods
// operator new for this class
- static void * operator new (size_t size, size_t tmem) {
+ // add a tag parameter to ensure that the signature of the delete operator does not collide with the (void*,size_t) overload
+ static void * operator new (size_t size, bool /*tag*/, size_t tmem) {
return ::operator new (size + tmem + 1);}
- static void operator delete (void *p, size_t) {
+ static void operator delete (void *p, bool /*tag*/, size_t) {
+ ::operator delete (p); }
+ static void operator delete (void *p) {
::operator delete (p); }
// create a new representation
Bug#933848: FTBFS if cmake is installed or if built twice in a row
It seems to be that the cmake-related FTBFS was not addressed?
Bug#934179: libcgal13: update libCGAL_ImageIO shlibs to >= 4.14
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 up pygalmesh migration at the moment: > britney doesn't know to test the new pygalmesh and cgal packages > together in debci testing (I guess it will get round to testing them > together before too much longer). But AFAIUI the change won't be sufficient for migration. pycgalmesh would need an NMU to pick up the new shlibs constraint. Joachim
Bug#933986: nmu: pygalmesh_0.3.6-1
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 pygalmesh_0.3.6-1 . ANY . unstable . -m "Rebuild against libCGAL_ImageIO.so.14" Thanks, Joachim -- System Information: Debian Release: 10.0 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#933849: Cron job does not take htmldir from /etc/munin/munin.conf into account
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 location is configurable as htmldir in /etc/munin/munin.conf, which is not taken into account here. Best regards, Joachim -- System Information: Debian Release: 10.0 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages munin depends on: ii cron [cron-daemon] 3.0pl1-134 ii fonts-dejavu-core2.37-1 ii libdate-manip-perl 6.76-1 pn libdigest-md5-perl ii libfile-copy-recursive-perl 0.44-1 ii libhtml-template-perl2.97-1 ii libio-socket-inet6-perl 2.72-2 ii liblog-log4perl-perl 1.49-1 ii librrds-perl 1.7.1-2 pn libstorable-perl pn libtime-hires-perl ii liburi-perl 1.76-1 ii lsb-base 10.2019051400 ii munin-common 2.0.49-1 ii netbase 5.6 ii perl 5.28.1-6 ii rrdtool 1.7.1-2 ii systemd-sysv 241-5 Versions of packages munin recommends: ii libcgi-fast-perl 1:2.13-1 pn munin-doc ii munin-node2.0.49-1 Versions of packages munin suggests: ii apache2 [httpd]2.4.38-3 ii chromium [www-browser] 73.0.3683.75-1 ii elinks [www-browser] 0.13~20190125-3 ii firefox-esr [www-browser] 60.8.0esr-1~deb10u1 ii konqueror [www-browser]4:18.12.0-1 pn libapache2-mod-fcgid ii libnet-ssleay-perl 1.85-2+b1 ii w3m [www-browser] 0.5.3-37 -- no debconf information
Bug#933848: FTBFS if cmake is installed or if built twice in a row
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--buildsystem=pybuild I: pybuild base:217: dh_auto_clean --buildsystem=cmake dh_autoreconf_clean -O--buildsystem=pybuild dh_clean -O--buildsystem=pybuild [...] fakeroot debian/rules binary dh binary --with python3 --buildsystem=pybuild dh_testroot -O--buildsystem=pybuild dh_prep -O--buildsystem=pybuild dh_auto_install -O--buildsystem=pybuild I: pybuild base:217: dh_auto_install --buildsystem=cmake --builddirectory="/mnt/debian/packages/pygalmesh/pygalmesh-0.3.6/.pybuild/cpython3_3.7_pygalmesh/build" --destdir="/mnt/debian/packages/pygalmesh/pygalmesh-0.3.6/debian/python3-pygalmesh" -- dh_installdocs -O--buildsystem=pybuild Without cmake installed: fakeroot debian/rules clean dh clean --with python3 --buildsystem=pybuild dh_auto_clean -O--buildsystem=pybuild I: pybuild base:217: python3.7 setup.py clean running clean removing '/build/pygalmesh-0.3.6/.pybuild/cpython3_3.7_pygalmesh/build' (and everything under it) 'build/bdist.linux-amd64' does not exist -- can't clean it 'build/scripts-3.7' does not exist -- can't clean it [...] fakeroot debian/rules binary dh binary --with python3 --buildsystem=pybuild dh_testroot -O--buildsystem=pybuild dh_prep -O--buildsystem=pybuild dh_auto_install -O--buildsystem=pybuild I: pybuild base:217: /usr/bin/python3 setup.py install --root /build/pygalmesh-0.3.6/debian/python3-pygalmesh running install [... many more lines following ...] dh_installdocs -O--buildsystem=pybuild I don't understand why the bare existence of cmake causes the build process to behave differently. At least, the package should declare a Build-Conflicts: on cmake. 2) pygalmesh FTBFS when built twice in a row. This can be fixed by putting pygalmesh-from-inr.1 pygalmesh-volume-from-surface.1 in debian/clean. Best regards, Joachim -- System Information: Debian Release: 10.0 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#887057: Removal from testing
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
Bug#917630: cppcheck-gui reports "your installation is broken"
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 been fixed in 1.79-1. As a workaround, if you once started cppcheck-gui with the --data-dir=/usr/share/cppcheck/cfg option, it should no longer complain about a missing std.cfg file. However, I missed back then that the default is still wrong. I fixed that now in 1.86-1. Best regards, Joachim
Bug#905577: cppcheck: FTBFS on arm*, ppc64el and s390x (plus various ports) - test failure
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
Bug#898535: closed by Chow Loong Jin (Bug#898535: fixed in tinyxml2 6.2.0+dfsg-2)
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 do not see a bug report that requests a transition slot, nor any discussion on debian-release. Joachim
Bug#733303: cgdb: Package new upstream release 0.7.0 (2014-11-14)
Hi, please package version 0.7.0 (from 21-Mar-2017) which has support for vertical split mode (bug #733303). Joachim
Bug#883986: Bug 886670 fixed
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 file containing a main() function. If you decide not to use find_package(), you can run make on the generated Makefile to see the default flags. Joachim
Bug#886670: closed by Joachim Reichel (Bug#886670: fixed in cgal 4.12-1)
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=
>>
>> 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
>> needs to be installed at all.)
>
> In #883986 you wrote:
> You shouldn't drop ${CGAL_CXX_FLAGS_INIT} completely.
Yes, because the patch that I was refering to is wrong because you drop critical
flags like -frounding-math.
That does not change the fact that CGAL_CXX_FLAGS_INIT is an internal variable.
Joachim
Bug#886670: closed by Joachim Reichel (Bug#886670: fixed in cgal 4.12-1)
> 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 needs to be installed at all.) Users should use "find_package(CGAL ...)". This approach generated too many flags in the past but has been fixed now. Joachim
Bug#886670: closed by Joachim Reichel (Bug#886670: fixed in cgal 4.12-1)
> 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 -D_FORTIFY_SOURCE=2 -Wdate-time > -D_FORTIFY_SOURCE=2" ) The flags are still there, but they are not used when compiling programs using CGAL. E.g. when using cgal_create_cmake_script on a trivial foo.cpp file containing a main() function we get /usr/bin/c++ -DCGAL_USE_GMP -DCGAL_USE_GMPXX -DCGAL_USE_GMPXX=1 -DCGAL_USE_MPFR -isystem /usr/include/x86_64-linux-gnu -I/tmp/x -frounding-math -o CMakeFiles/foo.dir/foo.cpp.o -c /tmp/x/foo.cpp /usr/bin/c++ -rdynamic CMakeFiles/foo.dir/foo.cpp.o -o foo -lmpfr -lgmpxx -lgmp /usr/lib/x86_64-linux-gnu/libCGAL.so.13.0.2 -lmpfr -lgmpxx -lgmp Joachim
Bug#897127: psensor FTBFS on i386/armhf: FAIL: test-cppcheck.sh
See bug 898327. Joachim
Bug#898327: cppcheck: *** stack smashing detected ***: terminated
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
Bug#898535: Incompatible ABI change without SONAME bump
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 to crash when running with version 6.2.0. See bug 898327 for an example. Please discuss this with upstream. Maybe they could release 6.2.1 with bumped SONAME? Please inform the reverse dependencies of tinyxml2 about the problem. Joachim -- System Information: Debian Release: 9.4 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#898327: cppcheck: *** stack smashing detected ***: terminated
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 course more variables like other build dependencies. The problem also shows up with 1.82-1 in the snapshot archive, but not with 1.76.1-1 in stable. Debugging this problem is difficult since I can't reproduce it in a local build. I'm leaning towards a binNMU to see whether it was a temporary problem on the build machine. What do you think? Joachim
Bug#890305: cppcheck still depends on python:any
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 to be done? Joachim
Bug#445874: Fixed in 1:4.0.1+hg487+dfsg-1
notfound 445874 1:4.0.1+hg487+dfsg-1 thanks This bug was fixed in 1:4.0.1+hg487+dfsg-1. Joachim
Bug#886670: libcgal-dev: CGAL_CXX_FLAGS_INIT contains flags that shouldn't be there
tag 886670 pending thanks This will be fixed in CGAL 4.12 as part of a larger rewrite of the cmake scripts. Joachim
Bug#886670: libcgal-dev: CGAL_CXX_FLAGS_INIT contains flags that shouldn't be there
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: > > /usr/lib/x86_64-linux-gnu/cmake/CGAL/CGALConfig.cmake: > set(CGAL_CXX_FLAGS_INIT "-g -O2 > -fdebug-prefix-map=/build/cgal-d6DBFP/cgal-4.11=. -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > -frounding-math" ) > > The only flag that might be correct in this place is -frounding-math, > in case that is required for using CGAL. > > Exposing flags like -fdebug-prefix-map is simply wrong. > > (For #883986 the problem is the -g, that is also wrong here.) I agree and I have forwarded this as https://github.com/CGAL/cgal/issues/2734 > The severity might seem inflated, but this should be fixed > for fixing the RC #883986 FTBFS in openscad. However, I disagree about the severity. Since there is a simple workaround I've reset the severity to normal and removed the block relation. Joachim
Bug#883986: Don't drop -frounding-math
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
Bug#883550: cgal FTCBFS: configures for the build architecture
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
Bug#876521: FTBFS with CGAL 4.11
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 we can > keep postgis is testing. Don't worry, sfcgal was not the only reverse dependency that needs more than a binNMU. > Just raise the severity of this issue to serious when the transition > starts. That's the usual procedure for blocking issues and transitions. [0] The transition just started. Done. Best regards, Joachim
Bug#882658: transition: cgal
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: temporarily dropped its dependency on CGAL #876521 sfcgal: maintainer indicated he is willing to temporarily drop its dependency on CGAL when the transition starts #871811 rheolef: patch available (will NMU or sponsor upload if maintainer hasn't uploaded when the transition starts) Kind regards, Joachim Ben file: title = "cgal"; is_affected = .depends ~ /libcgal-qt5-12|libcgal12/ | .depends ~ /libcgal-qt5-13|libcgal13/; is_good = .depends ~ /libcgal-qt5-13|libcgal13/; is_bad = .depends ~ /libcgal-qt5-12|libcgal12/; -- System Information: Debian Release: 9.1 APT prefers stable-debug APT policy: (800, 'stable-debug'), (800, 'stable'), (700, 'testing-debug'), (700, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#876521: FTBFS with CGAL 4.11
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
Bug#871811: Bug#876521: FTBFS with CGAL 4.11
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
Bug#876524: FTBFS with CGAL 4.11
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
Bug#819947: cppcheck: will not compile when CXX=ccache g++
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
