[ISSUE] packages broken by cmake build-style change

[ISSUE] packages broken by cmake build-style change

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

New issue by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/45679

Description:
cc @sgn

the following packages were broken by using cmake-bootstrap by default in the build-style:

- [ ] grpc
- [ ] sysdig

there are definitely more, but these are the ones I saw when doing rebuilds for openssl. this can be fixed by simply adding `cmake` to hostmakedepends, but the build-style doesn't seem to account for this

### example error
```
[8/206] Performing download step (download, verify and extract) for 'jq'
FAILED: jq-prefix/src/jq-stamp/jq-download /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/jq-download 
cd /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src && /usr/libexec/xbps-src/bin/cmake -P /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/download-jq.cmake && /usr/libexec/xbps-src/bin/cmake -P /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/verify-jq.cmake && /usr/libexec/xbps-src/bin/cmake -P /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/extract-jq.cmake && /usr/libexec/xbps-src/bin/cmake -E touch /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/jq-download
-- Downloading...
   dst='/builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-1.6.tar.gz'
   timeout='none'
   inactivity timeout='none'
-- Using src='https://download.falco.org/dependencies/jq-1.6.tar.gz'
CMake Error at jq-stamp/download-jq.cmake:170 (message):
  Each download failed!

    error: downloading 'https://download.falco.org/dependencies/jq-1.6.tar.gz' failed
          status_code: 1
          status_string: "Unsupported protocol"
          log:
          --- LOG BEGIN ---
          Protocol "https" not supported or disabled in libcurl

  Closing connection -1



          --- LOG END ---
```

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1685140294

Comment:
I would count those as not a bug of cmake-bootstrap.

I think it's always better to download all archives ourselves then put them into the correct places.

(I think for now, it's only broken for `https` but I also want to disable `http` and `ftp` too, see #45654)

Re: packages broken by cmake build-style change

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1685161289

Comment:
it seems musikcube is also broken by this, but in a different, more subtle way, at the end of do_build, it does this:
```
[100%] Built target musikcube
[post-build] started...
[post-build] BUILD_TYPE=None, not stripping
[post-build] patching library rpath entries...
[patch-rpath] patching Linux .so files...
chmod: cannot access './bin/lib/*': No such file or directory
chmod: cannot access './bin/plugins/*': No such file or directory
chmod: cannot access './bin/*.so': No such file or directory
/builddir/musikcube-3.0.0/script/patch-rpath.sh: line 19: patchelf: command not found
/builddir/musikcube-3.0.0/script/patch-rpath.sh: line 25: patchelf: command not found
/builddir/musikcube-3.0.0/script/patch-rpath.sh: line 28: patchelf: command not found
/builddir/musikcube-3.0.0/script/patch-rpath.sh: line 29: patchelf: command not found
[post-build] staging static assets...
[post-build] re-running 'cmake .' to re-index compiled artifacts
/builddir/musikcube-3.0.0/script/post-build.sh: line 29: cmake: command not found
[post-build] finished
[100%] Built target postbuild
```
which seems to result in all the plugins not being built

Re: packages broken by cmake build-style change

[motorto]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

New comment by motorto on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1688952516

Comment:
`imhex` tests fails because it can't find the `ctest` binary.

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 160 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1697521520

Comment:
- [ ] gnuradio-nrsc5

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868581829

Comment:
I'm trying to create a template for uebezugpp and the thing tries to fetch dependencies from the internet, which ultimately fails by this. It needs GSL & CLI11 as mentioned in [#45368](https://github.com/void-linux/void-packages/issues/45368).

```
# Template file for 'ueberzugpp'
pkgname=ueberzugpp
version=2.9.2
revision=1
build_style=cmake
configure_args="-DENABLE_WAYLAND=ON -DENABLE_OPENGL=ON"
hostmakedepends="pkg-config"
makedepends="chafa-devel extra-cmake-modules libopencv-devel libsixel-devel libvips-devel openssl-devel tbb-devel wayland-devel wayland-protocols xcb-util-image-devel xcb-util-renderutil-devel"
short_desc="Drop in replacement for ueberzug"
maintainer="Marcin Puc <tranzystorek.io@protonmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/jstkdng/ueberzugpp"
changelog="https://github.com/jstkdng/ueberzugpp/releases"
distfiles="https://github.com/jstkdng/ueberzugpp/archive/refs/tags/v${version}.tar.gz"
checksum=a658ccdb82c50ebd3bf31ecaaa79bcbb66bae756c3b588d4208c94a17f127f42
conflicts="ueberzug"
```

Re: packages broken by cmake build-style change

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

New comment by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868595162

Comment:
> I think it's always better to download all archives ourselves then put them into the correct places.

It'd be nice it the errors were less cryptic, I got hit by that when packaging contour #47845, and instead of knowing I had to download the resource manually, I had many hours of fruitless and frustrating debugging. I only learned of this issue when someone asked me if I already had a PR that packages GSL which the previous message asks for (ironically, the PR in which I hit this awful "bug").

There's barely any info online about that cryptic error message that cmake barfs up, and all that info says is that cmake is compiled "without ssl support". The build-style obscures the existence and usage of `cmake-bootstrap`, so what one checks is the run-depends of `cmake`, in which both curl and libssl obviously are present. The whole thing has 100% the appearance of a bug.

This mad goose chase could easily be avoided by a patched error message, especially in a `-bootstrap` package that should only be used in xbps-src.

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868601731

Comment:
In my case, adding cmake to hostmakedepends didn't result in the package building correctly and I don't really know why.

```
=> ueberzugpp-2.9.2_1: installing host dependencies: pkg-config-0.29.2_3 cmake-3.27.6_1 cmake-bootstrap-3.27.6_1 ninja-1.11.1_4 ...
=> ueberzugpp-2.9.2_1: installing target dependencies: chafa-devel-1.12.5_1 extra-cmake-modules-5.112.0_1 libopencv-devel-4.6.0_6 libsixel-devel-1.10.3_1 libvips-devel-8.14.4_2 openssl-devel-3.1.4_2 tbb-devel-2020.U3_2 wayland-devel-1.22.0_1 wayland-protocols-1.32_1 xcb-util-image-devel-0.4.1_1 xcb-util-renderutil-devel-0.3.10_1 ...
=> ueberzugpp-2.9.2_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> ueberzugpp-2.9.2_1: running pre-configure hook: 01-override-config ...
=> ueberzugpp-2.9.2_1: running pre-configure hook: 02-script-wrapper ...
=> ueberzugpp-2.9.2_1: running do_configure ...
CMake Deprecation Warning at build/_deps/cli11-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at build/_deps/nlohmann_json-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Using the multi-header code from /builddir/ueberzugpp-2.9.2/build/_deps/nlohmann_json-src/include/
-- Version: 10.1.0
-- Build type: None
-- Build spdlog: 1.12.0
-- Build type: None
CMake Error at /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
  OPENGL_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.27/Modules/FindOpenGL.cmake:545 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:110 (find_package)


-- Configuring incomplete, errors occurred!
=> ERROR: ueberzugpp-2.9.2_1: do_configure: 'CFLAGS="-DNDEBUG ${CFLAGS/ -pipe / }" CXXFLAGS="-DNDEBUG ${CXXFLAGS/ -pipe / }" cmake ${cmake_args} ${configure_args} ${LIBS:+-DCMAKE_C_STANDARD_LIBRARIES="$LIBS"} ${LIBS:+-DCMAKE_CXX_STANDARD_LIBRARIES="$LIBS"} ${wrksrc}/${build_wrksrc}' exited with 1
=> ERROR:   in do_configure() at common/build-style/cmake.sh:77

```

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868601731

Comment:
In my case, adding cmake to hostmakedepends didn't result in the package building correctly and I don't really know why. Looking at the error, there's only a warning about cmake-3.27 not being supported for CLI11, but it's somehow something related to opengl that stops it (keep in mind It's my first template).

```
=> ueberzugpp-2.9.2_1: installing host dependencies: pkg-config-0.29.2_3 cmake-3.27.6_1 cmake-bootstrap-3.27.6_1 ninja-1.11.1_4 ...
=> ueberzugpp-2.9.2_1: installing target dependencies: chafa-devel-1.12.5_1 extra-cmake-modules-5.112.0_1 libopencv-devel-4.6.0_6 libsixel-devel-1.10.3_1 libvips-devel-8.14.4_2 openssl-devel-3.1.4_2 tbb-devel-2020.U3_2 wayland-devel-1.22.0_1 wayland-protocols-1.32_1 xcb-util-image-devel-0.4.1_1 xcb-util-renderutil-devel-0.3.10_1 ...
=> ueberzugpp-2.9.2_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> ueberzugpp-2.9.2_1: running pre-configure hook: 01-override-config ...
=> ueberzugpp-2.9.2_1: running pre-configure hook: 02-script-wrapper ...
=> ueberzugpp-2.9.2_1: running do_configure ...
CMake Deprecation Warning at build/_deps/cli11-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at build/_deps/nlohmann_json-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Using the multi-header code from /builddir/ueberzugpp-2.9.2/build/_deps/nlohmann_json-src/include/
-- Version: 10.1.0
-- Build type: None
-- Build spdlog: 1.12.0
-- Build type: None
CMake Error at /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
  OPENGL_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.27/Modules/FindOpenGL.cmake:545 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:110 (find_package)


-- Configuring incomplete, errors occurred!
=> ERROR: ueberzugpp-2.9.2_1: do_configure: 'CFLAGS="-DNDEBUG ${CFLAGS/ -pipe / }" CXXFLAGS="-DNDEBUG ${CXXFLAGS/ -pipe / }" cmake ${cmake_args} ${configure_args} ${LIBS:+-DCMAKE_C_STANDARD_LIBRARIES="$LIBS"} ${LIBS:+-DCMAKE_CXX_STANDARD_LIBRARIES="$LIBS"} ${wrksrc}/${build_wrksrc}' exited with 1
=> ERROR:   in do_configure() at common/build-style/cmake.sh:77

```

Re: packages broken by cmake build-style change

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

New comment by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868607120

Comment:
@d4r1us-drk don't use `cmake` in templates, you want to get dependencies from xbps or add them to distfiles if they're resources or they're specific to the project you're packaging
For GSL, you'll be able to simply add it to `makedepends` once #47845 gets merged (as `guidelines-support-library`).
For CLI11, check its not already available in the repos, and if not, make a template for it (in the same PR but separate commit).

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868634468

Comment:
I was just trying to do what OP said:

> this can be fixed by simply adding cmake to hostmakedepends

Gonna try to do all of that later. Enjoy holidays bros.

Re: packages broken by cmake build-style change

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868637502

Comment:
it "fixes" it by hiding the fact that the build system is trying to download things when it's better to do the downloads ourselves as distfiles

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868659765

Comment:
> There's barely any info online about that cryptic error message that cmake barfs up, and all that info says is that cmake is compiled "without ssl support".

Where did you see that?

Trying building your PR:


> CMake Error at src/libunicode/CMakeLists.txt:17 (file):
>  **file DOWNLOAD** cannot compute hash on failed download
>
>    **status: [1;"Unsupported protocol"]**

The error seems to be clear that some `file(DOWNLOAD)` run into `unsupported protocol`.

Re: packages broken by cmake build-style change

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

New comment by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868666080

Comment:
> The error seems to be clear that some `file(DOWNLOAD)` run into `unsupported protocol`.

Exactly, HTTPS is never an "unsupported protocol" for a normal cmake build, which is what a normal packager would expect is used when not knowing about cmake-bootstrap.

How would one expect this error message, when there's no indication anywhere that 1) the `cmake-bootstrap` package exists, that 2) the `cmake` build style uses it instead of `cmake`, and 3) that `cmake-bootstrap` is a minimal cmake build that builds without support for downloading? 3 obscure yet critical facts hidden behind opaque machinery.

If cmake in xbps-src is supposed to not support downloads at all, then the error message should be that, "This cmake-bootstrap build does not support downloads", or the like

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868667688

Comment:
> it "fixes" it by hiding the fact that the build system is trying to download things when it's better to do the downloads ourselves as distfiles

Yup I agree with controlling dependencies, but the error message is odd.

> If cmake in xbps-src is supposed to not support downloads at all, then the error message should be that, "This cmake-bootstrap build does not support downloads", or the like

Totally agree with this.

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868668748

Comment:
3468a5f0bc3c19b3abe54c8d17310eb90679cc79

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868669012

Comment:
It supports `file(DOWNLOAD)` but only `file://` protocol.

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868669407

Comment:
> If cmake in xbps-src is supposed to not support downloads at all, then the error message should be that, "This cmake-bootstrap build does not support downloads", or the like

It supports `file(DOWNLOAD)` but only `file://` protocol.

Re: packages broken by cmake build-style change

[sgn]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868669012

Comment:
It supports `file(DOWNLOAD)` but only `file://` protocol.

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868670076

Comment:
> [3468a5f](https://github.com/void-linux/void-packages/commit/3468a5f0bc3c19b3abe54c8d17310eb90679cc79)

that was fast

> It supports `file(DOWNLOAD)` but only `file://` protocol.

Is there a way I can create a working template for ueberzugpp, or do I need to wait until GSL and CLI11 are packaged?

Re: packages broken by cmake build-style change

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

New comment by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868688606

Comment:
> https://github.com/void-linux/void-packages/commit/3468a5f0bc3c19b3abe54c8d17310eb90679cc79

Thanks!

> Is there a way I can create a working template for ueberzugpp, or do I need to wait until GSL and CLI11 are packaged?

For CLI11, I recommend trying to package it yourself, it doesn't look complex and is header-only; it might not need anything more than the cmake build style, a couple of `configure_args`, and a vlicense. If you do that, have it be added in a separate commit in the same PR as ueberzugpp. You can ping me in the PR you make if you need help, and don't hesitate to open a PR as draft.

For GSL, I recommend waiting for the PR to get merged (there will be problems if two PR get merged that add the same package). Although, if you're comfortable enough with git and make sure to use a draft PR, you could temporarily pull my GSL commit from the contour PR. Your PR would still have to wait for GSL to merge, but you'd be able to build and test the package.

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-1868690422

Comment:
Great, thanks for the guidance, I'm gonna try to package CLI11. Although it's my first time doing this I think I can manage it.

Re: [ISSUE] [CLOSED] packages broken by cmake build-style change

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

Closed issue by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/45679

Description:
cc @sgn

the following packages were broken by using cmake-bootstrap by default in the build-style:

network download:
- [x] grpc
- [x] sysdig
- [x] OpenRCT2
- [x] mixxx

other:
- [x] musikcube

there are definitely more, but these are the ones I saw when doing rebuilds for openssl. this can be fixed by simply adding `cmake` to hostmakedepends, but the build-style doesn't seem to account for this

### example error
```
[8/206] Performing download step (download, verify and extract) for 'jq'
FAILED: jq-prefix/src/jq-stamp/jq-download /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/jq-download 
cd /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src && /usr/libexec/xbps-src/bin/cmake -P /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/download-jq.cmake && /usr/libexec/xbps-src/bin/cmake -P /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/verify-jq.cmake && /usr/libexec/xbps-src/bin/cmake -P /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/extract-jq.cmake && /usr/libexec/xbps-src/bin/cmake -E touch /builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-stamp/jq-download
-- Downloading...
   dst='/builddir/sysdig-0.31.5/sysdig-0.31.5/build/jq-prefix/src/jq-1.6.tar.gz'
   timeout='none'
   inactivity timeout='none'
-- Using src='https://download.falco.org/dependencies/jq-1.6.tar.gz'
CMake Error at jq-stamp/download-jq.cmake:170 (message):
  Each download failed!

    error: downloading 'https://download.falco.org/dependencies/jq-1.6.tar.gz' failed
          status_code: 1
          status_string: "Unsupported protocol"
          log:
          --- LOG BEGIN ---
          Protocol "https" not supported or disabled in libcurl

  Closing connection -1



          --- LOG END ---
```

Re: packages broken by cmake build-style change

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-2063214253

Comment:
probably safe to close this now, as we don't seem to have any other breakages noticed.

Re: packages broken by cmake build-style change

[ibhagwan]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

New comment by ibhagwan on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-2065746355

Comment:
@d4r1us-drk, if you're still interested in ueberzugpp take a look at https://github.com/void-linux/void-packages/issues/45368#issuecomment-2065745648

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-2067773532

Comment:
> @d4r1us-drk, if you're still interested in ueberzugpp take a look at [#45368 (comment)](https://github.com/void-linux/void-packages/issues/45368#issuecomment-2065745648)

Sorry I can't, I'm not using Void at the moment, I accidentally locked my BIOS and I can't turn off secure boot, so I'm stuck in Fedora (I don't have any other computers either unfortunately).

Re: packages broken by cmake build-style change

[d4r1us-drk]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

New comment by d4r1us-drk on void-packages repository

https://github.com/void-linux/void-packages/issues/45679#issuecomment-2067773532

Comment:
> @d4r1us-drk, if you're still interested in ueberzugpp take a look at [#45368 (comment)](https://github.com/void-linux/void-packages/issues/45368#issuecomment-2065745648)

Sorry I can't, I'm not using Void at the moment, I accidentally locked my BIOS (forgot the password I should say) and I can't turn off secure boot, so I'm stuck in Fedora (I don't have any other computers either unfortunately).