Package Details: cmake-format 0.6.13-3

Git Clone URL: (read-only, click to copy)
Package Base: cmake-format
Description: Source code formatter for CMake listfiles
Upstream URL:
Licenses: GPL-3.0-or-later
Conflicts: python-cmakelang
Provides: python-cmakelang
Submitter: Martchus
Maintainer: Martchus (Martchus)
Last Packager: Martchus
Votes: 14
Popularity: 0.059098
First Submitted: 2018-12-05 15:56 (UTC)
Last Updated: 2024-05-13 12:55 (UTC)

Dependencies (6)

Sources (1)

Pinned Comments

Martchus commented on 2018-12-24 14:11 (UTC)

All my packages are managed at GitHub where you can also contribute directly: There also exist a binary repository:

Latest Comments

1 2 Next › Last »

Martchus commented on 2024-05-13 12:52 (UTC) (edited on 2024-05-13 12:57 (UTC) by Martchus)

I would have changed it on the next update I would have to do anyway but ok - I can also change it now. However, please note that this RFC is really nothing that needs to be implemented with urgency. Many official packages also haven't been changed yet.

EDIT: I updated the package so the orphan request can be dismissed.

Coelacanthus commented on 2024-01-16 16:40 (UTC)

Please follow RFC16 use SPDX identifier.

tpkessler commented on 2022-12-08 14:52 (UTC) (edited on 2022-12-08 14:56 (UTC) by tpkessler)

Hey! TU here. I agree with @Martchus that it's better to drop the python prefix. python-cmakelang has been merged into cmake-format.

Martchus commented on 2022-11-07 21:04 (UTC)

I think it is called cmake-format because that's what the whole project started with (and still the most important/popular outcome of the project). I guess it was only generalized later.

I've already filed a merge request to merge the other package into this but it hasn't been handled yet by a TU.

Spixmaster commented on 2022-11-07 17:10 (UTC)

The project name is confusing. I think it is cmake lang but the repository is named differently.

Spixmaster commented on 2022-11-07 17:09 (UTC)

@Martchus I am on your side concerning the python prefix. There should be none, see here. The rules state that no duplicates are allowed. One of both packages should be deleted.

Martchus commented on 2022-10-31 09:28 (UTC) (edited on 2022-10-31 09:29 (UTC) by Martchus)

The other package also seems broken as I suppose the setup tools should not just be a make dependency. It also doesn't execute the upstream testsuite.

I could add an additional provide here to mitigate any dependency issues.

Martchus commented on 2022-10-31 09:23 (UTC)

Since this package contains user facing tools and the used programming language is merely an implementation detail I'd avoid using the python- prefix in the name. Maybe internal Python modules could be split packages, though. So I would prefer to not delete this package.

Martchus commented on 2020-04-30 17:35 (UTC)

I was able to build the latest version. Do you build in a clean chroot? Otherwise the build system might pick up some tool for Debian packaging in your environment which doesn't work. That's just a guess. Without your full build log I can't say anything more specific.

vinci commented on 2020-04-30 11:15 (UTC)

The latest version gives me a CMake Error: CMake Error at cmake/debian.cmake:43 (add_dependencies): The dependency target "debs-Lysia-amd64" of target "debs" does not exist. Call Stack (most recent call first): CMakeLists.txt:29 (include)