Bug#1050506: [Pkg-cmake-team] Bug#1050506: Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.5.0")

On Fri, Aug 25, 2023 at 10:15 AM Mathieu Malaterre wrote: > > Also, why do you think this is a CMake issue and not a VTK issue? > > As explained in my original report, this is a change of behavior in > current cmake 3.27. The problem is that VTK has its own copy of FindEXPAT that steps on private

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

On Fri, Jul 21, 2023 at 2:37 PM Brad King wrote: > The behavior change came from this CMake merge request: > * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538 > because the distutils variant is deprecated. This is now under discussion in an upstream CMake issue:

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

On Fri, Jul 21, 2023 at 11:21 AM Sebastiaan Couwenberg wrote: > On bookworm distutils is still used which returns: ... > On sid sysconfig is used which results: The behavior change came from this CMake merge request: * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538 because the

Bug#968672: libstdc++-10-dev patch for CUDA and __float128 needs update

Package: libstdc++-10-dev Version: 10.2.0-5 This patch: https://salsa.debian.org/toolchain-team/gcc/-/blob/10.2.0-5/debian/patches/cuda-float128.diff needs to be updated for new occurrences of `__float128` in `numbers` and `bits/stl_algobase.h`: ``` $ grep -r _GLIBCXX_USE_FLOAT128

Bug#959064: ignition-transport FTBFS in testing.

On 4/29/2020 10:40 PM, peter green wrote: The behavior of pkg-config has changed This lets though a -isystem parameter with a space which was previously suppressed And the space in said parameter breaks cmake. I think cmake should handle -isystem¹ and as this is reproducible without

Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build

On 12/7/18 7:44 AM, Jochen Sprickerhof wrote: >> Both are valid ways to link to the pthread library, which is all >> the `-pthread` flag does when used to drive linking. > > I don't agree. Quoting from my mail: > > "Define additional macros required" Macros are for compiling. It is not used

Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build

On 12/6/18 4:16 PM, Jochen Sprickerhof wrote: > after reading up on this, I think this needs fixing in cmake. > > So neither adding -lpthread, > nor adding /usr/lib/x86_64-linux-gnu/libpthread.so > seems correct to me. Both are valid ways to link to the pthread library, which is all the

Bug#912443: cmake: Generates wrong link flags on hurd-i386

On Wed, 31 Oct 2018 19:05:55 +0300 Dmitry Shachnev wrote: > Such a flag is a problem when the referenced .so file is actually a symlink. > GCC does not resolve it and generates a dependency literally on libsndio.so. Linking a library by absolute path is okay (and preferred) if the library has a

Bug#911088: cmake: Recognize /usr/include/x86_64-linux-gnu like /usr/include

On 10/15/2018 10:42 AM, Marc Glisse wrote: > It seems that cmake has special code to avoid adding -I/usr/include, > it would be good to extend it to the multiarch directory. I've opened an upstream issue here: * https://gitlab.kitware.com/cmake/cmake/issues/18455 It links to some related issues

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

On 04/24/2016 11:59 AM, Andreas Beckmann wrote: > On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain wrote: >> If I change all files except CustomCMakeInput.txt to have identical >> timestamps, then I can reproduce the bug as seen on the buildds: [snip] >> And finally, it seems I can avoid that

Bug#819072: closed by Sylvestre Ledru <sylves...@debian.org>

On 07/02/2016 03:54 PM, Debian Bug Tracking System wrote: > It has been closed by Sylvestre Ledru . I can confirm 3.8.1-3 works now. Thanks! However, it looks like 3.9 needs additional work due to more upstream changes. The changes needed to support it will likely be

Bug#819072: closed by Sylvestre Ledru <sylves...@debian.org> (Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1-1)

On 06/27/2016 02:49 PM, Sylvestre Ledru wrote: >> I'm not familiar enough with debian packaging infrastructure to know >> how to create this symlink and get it included in the llvm-3.8-dev >> package, but it should be pretty simple for those that know. >> >> Meanwhile the attached patch removes an

Bug#819072: closed by Sylvestre Ledru <sylves...@debian.org> (Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1-1)

On 06/23/2016 09:36 AM, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the llvm-3.8-dev package: > > #819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging > > It has been closed by Sylvestre Ledru

Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1~+rc1-1~exp1

On 06/09/2016 10:14 AM, Brad King wrote: > Here is an untested patch that uses the approach I suggested. I just noticed Antoine's report also mentions "sancov". It looks like that is built but not deployed in the same package as the CMake files in question. Here is a revised patch

Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1~+rc1-1~exp1

Hi Sylvestre, Thanks for taking care of this issue. On 06/09/2016 09:53 AM, Sylvestre Ledru wrote: > Le 09/06/2016 à 15:15, antoine.pierlot-gar...@scle.fr a écrit : >> (Similar to section 3 of Brad King's message #20 at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819072#20 ) > > A

Bug#820334: Segfaults caused by new DT_MIPS_RLD_MAP_REL tag and RPATH removers

On 04/09/2016 11:01 AM, Mathieu Malaterre wrote: > On Sat, Apr 9, 2016 at 2:14 PM, Aurelien Jarno wrote: >> You mean that cmake is not calling chrpath, but instead has an embedded >> copy? In that case I'll look at that later today. Yes, CMake has a separate implementation. It is not a copy of

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

On 04/06/2016 05:42 PM, Steven Chamberlain wrote: > | if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt > | IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt) > > If multi2-real.txt and multi2-stamp.txt are created within 1 second of > each other, the test will most

Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging

On 03/31/2016 04:26 PM, Sylvestre Ledru wrote: > many thanks. I will try to integrate that asap. Great! I can try installing a revised package to check it, when ready. > By the way, a side question, after the build with cmake, before the > "make install", is > it possible to remove the

Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging

On 03/24/2016 11:42 AM, Sylvestre Ledru wrote: >> CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include): >> include could not find load file: > As you are much more familiar than me on this, would you mind proposing a > patch? While I'm familiar with LLVM's CMake

Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging

Package: llvm-3.8-dev Version: 1:3.8-2 Severity: normal Dear Maintainer, Issues similar to those in bug #785931 have returned in the 3.8 package. When a CMake-based project does find_package(LLVM) on Debian one gets CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178

Bug#813875: insighttoolkit4: FTBFS on i386 (member reference base type 'void' is not a structure or union)

On 02/06/2016 06:34 AM, Gert Wollny wrote: > As you can see, this is actually a bug in castxml [snip] > would you please consider filing a bug upstream I've recorded the issue upstream here: https://github.com/CastXML/CastXML/issues/47 Please follow that for updates. -Brad

Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging

On 06/23/2015 10:51 AM, Sylvestre Ledru wrote: I guess 3.6.1-1 didn't fix the issue... sorry about that. For reference, upstream has made changes that affect the packaging of CMake files for llvm 3.7. See this thread/message for the changes needed in Debian: [PATCH] Make CMake files generated

Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging

On 05/20/2015 10:13 AM, Brad King wrote: On 05/20/2015 09:54 AM, Sylvestre Ledru wrote: I just updated 3.6.1-1 which should fix this issue. Indeed, I see the packaging change: http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.6/debian/rules?r1=1541r2=1577pathrev=1577 I

Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging

Package: llvm-3.6-dev Version: 1:3.6-2 Severity: normal Dear Maintainer, The issue reported in bug #735592 is not fully resolved (as reported in some follow-up posts in that issue). While that problem has been resolved in upstream LLVM 3.6, another problem is caused by Debian packaging. When a

Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging

On 05/20/2015 09:54 AM, Sylvestre Ledru wrote: I just updated 3.6.1-1 which should fix this issue. Could you check that? Indeed, I see the packaging change: http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.6/debian/rules?r1=1541r2=1577pathrev=1577 It fixes the content of

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

On 03/13/2015 12:20 PM, Ulf Wetzker wrote: The files contain bad internal filenames. CMake Error at /usr/share/llvm-3.5/cmake/LLVMConfig.cmake:43 (include): include could not find load file: /usr/lib/llvm-3.5/share/llvm/cmake/LLVMExports.cmake In LLVMConfig.cmake the variable

Bug#691948: cmake: Insists on using non-existent (when cross-compiling) --rdynamic flag

On 10/04/2014 08:58 AM, Mathieu Malaterre wrote: I think OP should have mentioned that the project is C-only, eg: Yes. Your --out-implib problem was due to trying to use the Linux host C++ compiler for cross-compiling to Windows. To build a project using C++ one would also need:

Bug#761516: cmake: decide on a place for third parties to install extra modules

On 09/14/2014 10:51 AM, Ximin Luo wrote: the following paths will automatically be picked up by CMake: /usr/(lib/arch|lib|share)/cmake/$package/ /usr/(lib/arch|lib|share)/$package/ /usr/(lib/arch|lib|share)/$package/(cmake|CMake)/ Correct.

Bug#761516: cmake: decide on a place for third parties to install extra modules

On 09/15/2014 02:12 PM, Ximin Luo wrote: So, what do you think Debian maintainers should do? Leave it to the upstreams. Use their discretion or what? I couldn't find any on my local system, but from the looks of it there are quite a few other packages that install these files, but they all

Bug#747306: SIGSEGV: cmGlobalGenerator::FindMakeProgram(cmMakefile*) ()

On 05/07/2014 08:58 AM, Mathieu Malaterre wrote: segmentation fault I just fixed this upstream and added a test: ctest_build: Do not crash on bad generator name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54111286 The hunk in Source/CTest/cmCTestBuildCommand.cxx could easily be

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

On 02/19/2014 04:54 PM, Sylvestre Ledru wrote: this patch fixes it. I will upload it when I have more stuff to upload (except if you need it soon) Thanks. I will wait for the next update and then try it again. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

On 02/14/2014 12:41 PM, Sylvestre Ledru wrote: I just uploaded a new snapshot release of llvm with your changes. Thanks. However, the files still do not appear as of 1:3.5~svn201412-1. I downloaded the package source and it does have the changes to the Makefile rules but the files still do not

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

On 01/24/2014 03:47 PM, Brad King wrote: I've prepared a more general-purpose series and posted it for upstream review on llvm-commits The series has been applied upstream trunk as of r201053: http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517/focus=175229 This issue should

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

On 01/22/2014 10:54 AM, Sylvestre Ledru wrote: wahou, that is excellent. Thanks! Are you going to submit them upstream ? (I can apply them if you need a contact). I've prepared a more general-purpose series and posted it for upstream review on llvm-commits:

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

.git.brad.k...@kitware.com In-Reply-To: 52e08268.2090...@debian.org References: 52e08268.2090...@debian.org From: Brad King brad.k...@kitware.com Date: Wed, 22 Jan 2014 10:00:50 -0500 Subject: [PATCH] Makefile: Build and install CMake package modules Teach the Makefile build system to generate and install

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

: deeda6e64171bff53b96d6d32f54f4741b1a0da9.1390405404.git.brad.k...@kitware.com In-Reply-To: 52daa3d3.8030...@debian.org References: 52daa3d3.8030...@debian.org From: Brad King brad.k...@kitware.com Date: Tue, 21 Jan 2014 09:50:53 -0500 Subject: [PATCH 1/2] Simplify LLVMConfig.cmake inclusion of LLVM-Config module The LLVMConfig.cmake

Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing

Package: llvm-3.5-dev Version: 1:3.5~svn197556-1 Severity: normal Dear Maintainer, The issue reported in archived bug #701153 is not fully resolved. The main problem still exists as of llvm-3.5-dev 1:3.5~svn197556-1. The cmake/modules/*.cmake files from the llvm source are installed including a

Bug#717144: Remove workaround-gcc296-bugs from ctest -T MemCheck

On 07/17/2013 07:15 AM, Modestas Vainius wrote: Yes, I do. I fail to see why you would point me to it. Just to be clear, I'm NOT against fixing this bug, I'm against fixing this bug via Debian patch. That's it. So either you report it upstream (which will be faster), or I will do it

Bug#700320: cmake: Cmake licensing may not be open source

On 02/11/2013 11:22 AM, Nigel Horne wrote: According to Copright.txt in cmake: CMake - Cross Platform Makefile Generator Copyright 2000-2011 Kitware, Inc., Insight Software Consortium All rights reserved. It's either open source or all rights reservered. The caveats underneath that notice

Bug#683484: cmake: Please add multiarch libdir into CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES

On 08/01/2012 03:48 AM, D. Barbier wrote: I use ${CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES} to remove system paths from RPATH. FYI, CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is not documented by CMake as a publicly available value. It is an internal implementation detail, though I doubt it is

Bug#667417: fixing __float128?

On 07/27/2012 02:17 AM, Mathieu Malaterre wrote: On Fri, Jul 27, 2012 at 4:13 AM, Steve M. Robbins st...@sumost.ca wrote: Hey ... is there a trick to fix #654718 similar to that for __int128? #undef _GLIBCXX_USE_FLOAT128 No, that is not the same problem. The __int128 fix told the *standard

Bug#675181: gccxml cannot parse limits under GCC 4.7.1

On 07/26/2012 05:31 AM, Mathieu Malaterre wrote: reopen 675181 severity grave retitle 675181 gccxml cannot parse limits under GCC 4.7.1 forwarded 675181 http://www.gccxml.org/Bug/view.php?id=13372 thanks Not sure if this is ideal to reopen the bug instead of creating a new one. But I

Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory

On 07/11/2012 03:40 AM, Evgeni Golov wrote: Dear cmake maintainers, could you please have a look at the bug (and build log) and guess why 2.8.9 stopped building the libraries in the mdrun target? Is it a bad cmake file or a regression in cmake? It is a regression in CMake AFAICT. I bisected

Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory

On 07/11/2012 02:29 PM, Brad King wrote: Try adding the flag -DCMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified to the CMake configuration step to work around the problem. Nevermind about this workaround. I had tested it with a leftover build of a good version during git bisect

Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory

On 07/11/2012 02:55 PM, Brad King wrote: This hunk: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732#patch4 Seems to have reversed a previous fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43cad3e4 of a problem similar to what we observe here. This should fix it: http

Bug#661676: CMake: Generated export file

On 2/29/2012 3:02 AM, Mathieu Malaterre wrote: Bug #661383 and #506992 describe the symptoms. Basically cmake internal mecanism to generating export file store full path to library [snip] IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE /usr/lib/libz.so;vtksys Right. CMake uses full paths for

Bug#600889: cmake: find_package(VTK) with additional version requirement fails

On 11/27/2010 09:39 AM, Kai Wasserbäch wrote: tag 600889 + upstream patch thanks Hello Michael, I've investigated the problem further and it seems like FindVTK.cmake is missing a case for handling the VTK 5.x case. I've prepared a patch (applies on top of FindVTK.cmake), which I've

Bug#600889: cmake: find_package(VTK) with additional version requirement fails

On 01/10/2011 05:04 PM, Brad King wrote: Debian can fix this for its VTK packages by adding such a file. A tutorial is here: http://www.cmake.org/Wiki/CMake_2.6_Notes#Package_Version_Files The issue should be filed with VTK upstream too. I thought this seemed familiar. It's already

Bug#496391: Fixed upstream, for real

Hi Folks, This bug was reported upstream and partly fixed in Dec 2008: http://www.gccxml.org/Bug/view.php?id=8083 There were *two* scripts with the problem. One was MIPSpro/find_flags, the other was gccxml_find_flags which was the one fixed (and later replaced by a C++ implementation

Bug#500883: vol_id doesn't recognize Adaptec 1220SA raid signature

Hi Folks, FYI, I'm also having this problem with a 'via' software raid controller. $ dpkg --status udev ~ Package: udev Status: install ok installed Priority: optional Section: admin Installed-Size: 804 Maintainer: Marco d'Itri [EMAIL PROTECTED]

Bug#494167: xvfb: crashes due to dbus/hal problems

Package: xvfb Version: 2:1.4.2-2 Severity: important I run tests of a project that needs an X server on a nightly basis. For years I've been running them off-screen using Xvfb. I start an instance: Xvfb :52 -screen 0 1024x768x24 -fbdir /tmp/xvfb.52 -ac and then run tests with DISPLAY=:52.

Bug#316932: apcupsd: problem still exists in 3.14.2-1

Hi Folks, I have a debian 'testing' system with /usr under lvm2 control and hit this problem. I've gotten killpower working with a slightly patched apcupsd 3.14.3-2, as follows: $ apt-get source apcupsd $ sudo apt-get build-dep apcupsd $ cd apcupsd-3.14.3 $ patch -p1

Bug#287579: vtk API changes

. As the Debian maintainer, are you Brad King recently fix the versioning in VTK CVS (before the 5.0) branch. And I believe everything is set properly using CMake: SOVERSION. Brad do you want to add anything ? I've been making several changes with the goal of bringing VTK into the modern world