this area. 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
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
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
wit
a3d3.8030...@debian.org>
References: <52daa3d3.8030...@debian.org>
From: Brad King
Date: Tue, 21 Jan 2014 09:50:53 -0500
Subject: [PATCH 1/2] Simplify LLVMConfig.cmake inclusion of LLVM-Config module
The LLVMConfig.cmake file we generate already hard-codes include and lib
paths under the
<83cb7d3898947b7b38eaf6960a3b0022bf0c7266.1390495723.git.brad.k...@kitware.com>
In-Reply-To: <52e08268.2090...@debian.org>
References: <52e08268.2090...@debian.org>
From: Brad King
Date: Wed, 22 Jan 2014 10:00:50 -0500
Subject: [PATCH] Makefile: Build and install CMake package mo
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:
http://thread.gmane.org/gmane.co
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 issu
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
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 backpo
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 bise
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"
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.
Thi
On 07/26/2012 05:31 AM, Mathieu Malaterre wrote:
> reopen 675181
> severity grave
> retitle 675181 gccxml cannot parse 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 bel
On 07/27/2012 02:17 AM, Mathieu Malaterre wrote:
> On Fri, Jul 27, 2012 at 4:13 AM, Steve M. Robbins 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 library* he
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
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
> th
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
>
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
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 temporary
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 lik
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 patch
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
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 .
There is
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
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
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
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=1541&r2=1577&pathrev=1577
It fixes the content
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
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:
-DCMAKE_CXX_
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=15
On 09/14/2014 10:51 AM, Ximin Luo wrote:
> the following paths will automatically be picked up by CMake:
>
> /usr/(lib/|lib|share)/cmake/$package/
> /usr/(lib/|lib|share)/$package/
> /usr/(lib/|lib|share)/$package/(cmake|CMake)/
Correct.
>> http://www.cmake.org/cmake/help/git-master/manual/cmake
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
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
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 (includ
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 packa
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 h
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 ch
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 incompatible
with the 3.8 p
On Mon, Jul 29, 2024 at 1:57 AM Lucas Nussbaum wrote:
> Source: cmake
> Version: 3.30.1-1
...
> 492/721 Test #501: RunCMake.file-DOWNLOAD
> ..***Failed
...
> stdout does not match that expected.
This is due to a change in curl's output introduced in curl 8.9.
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
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 dist
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:
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]>
Arc
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 anyway
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 < ~/apcupsd-lvm.pat
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".
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'v
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 seem
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
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
ignition-t
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 `-pthread
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 dur
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 pr
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 /usr/
On Wed, Nov 13, 2024 at 11:28 AM Hefee wrote:
> But if I do (with an empty test.qml):
> ...
> If parses fine with 3.30.5 and fails with 3.31.0.
Thanks! With that I can reproduce the problem locally.
I'll track it down.
-Brad
On Wed, Nov 13, 2024 at 8:24 AM Hefee wrote:
> 3.31.0 does care about non existing directories in
> INTERFACE_INCLUDE_DIRECTORIES
> 3.30.5 do not care about non-existing directories.
I don't think that specific diagnostic has changed.
With this example:
```
cmake_minimum_required(VERSION 3.30)
p
On Wed, Nov 13, 2024 at 11:38 AM Brad King wrote:
> > If parses fine with 3.30.5 and fails with 3.31.0.
> I can reproduce the problem locally. I'll track it down.
The change in behavior is due to CMake 3.31 fixing this bug:
* https://gitlab.kitware.com/cmake/cmake/-/issues/25
On Fri, Nov 15, 2024 at 3:11 AM Sune Stolborg Vuorela wrote:
> I think it is going to affect all of Qt6-packages, not just Qt6Declarative. At
> least from a quick glance over other of my Qt6*Targets.cmake with private dev
> things have the same thing.
This is not a new diagnostic. Most of the oth
On Fri, Nov 15, 2024 at 2:45 AM Andrius Merkys wrote:
> find_package(ZLIB REQUIRED)
> Resulting CMakeCache.txt does not contain neither
> ZLIB_INCLUDE_DIRS nor ZLIB_LIBRARIES.
Those are not expected to be in the cache. FindZLIB
sets them as normal variables that are available to the
caller of `fi
On Thu, Nov 14, 2024 at 7:14 AM Sune Stolborg Vuorela wrote:
> > * https://gitlab.kitware.com/cmake/cmake/-/issues/25728
> I suggest we upload a cmake with that fix reverted as a short term solution
> while figuring out what to do with the rest of it
> What does the cmake maintainers say?
I'd rath
Although this was exposed by a change to CMake, whose compatibility
concerns can be discussed on the CMake side, there is a bug in
ParaView's CMake code. I've opened an upstream issue:
* https://gitlab.kitware.com/paraview/paraview/-/issues/22806
-Brad
On Fri, Nov 22, 2024 at 12:29 PM Brad King wrote:
> there is a bug in ParaView's CMake code
I've posted a patch to the ParaView issue:
* https://gitlab.kitware.com/paraview/paraview/-/issues/22806#note_1596824
Further discussion is needed there to select a final change
for upst
On Thu, Nov 21, 2024 at 6:39 PM Drew Parsons wrote:
> cmake 3.31...introduced a regression handling -Wl in LDFLAGS.
I don't think there is a regression of that in general, but a bug fix in
CMake 3.31 did expose a bug in a line of CMake code in ParaView.
I've opened an issue on the CMake side to di
The original failure was fixed by CMake 3.31.4.
The current failure is visible in the lfortran test log:
> autopkgtest [16:12:29]: test project1-plain: - - - - - - - - - - stderr - - -
> - - - - - - -
> CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
> Compatibility with
On Sun, Dec 22, 2024 at 3:39 AM Paul Gevers wrote:
> With a recent upload of cmake the autopkgtest of lfortran fails in
> testing when that autopkgtest is run with the binary packages of cmake
> from unstable. It passes when run with only packages from testing.
For reference, CMake 3.31 introduced
On Wed, Feb 26, 2025 at 11:39 AM John David Anglin wrote:
> Binutils ld has a new warning...it causes the following tests to fail
> ...
>actual-stderr> /usr/bin/ld: warning: exec has a LOAD segment with RWX
> permissions
CMake's tests fail due to this unexpected incidental output from the too
On Tue, Feb 25, 2025 at 4:30 AM Timo Röhling wrote:
> >Do you think it'd be feasable to package CMake 4.0 for trixie?
> Probably not.
I agree. It's too rushed.
I will probably do several more release candidates for CMake 4.0.0.
> the cost of broken backwards compatibility is significant...
> 41
On Sat, Mar 29, 2025 at 4:27 PM Lucas Nussbaum wrote:
> /build/reproducible-path/cmake-3.31.6/Source/cmCurl.cxx:178:26: error:
> invalid conversion from ‘long int’ to ‘CURL_NETRC_OPTION’ [-fpermissive]
CMake was accidentally using an undocumented type from a curl header,
which an update to curl r
68 matches
Mail list logo
