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
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
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 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
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 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
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 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 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
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 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 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 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:
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
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 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/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 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 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
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 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 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 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
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/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
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 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 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
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 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
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 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
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 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 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 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
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 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 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 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 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 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
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 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
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
<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
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
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 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 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 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 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 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/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/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 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 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 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 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
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,
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
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".
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
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
68 matches
Mail list logo
