From: 0x5c <0x5c@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: packages broken by cmake build-style change
Date: Sun, 24 Dec 2023 22:17:46 +0100 [thread overview]
Message-ID: <20231224211746.PFfEmnOKt34T1ZcRcJkP485njIrwkQU_xLjNXMZflFk@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-45679@inbox.vuxu.org>
[-- 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.
next prev parent reply other threads:[~2023-12-24 21:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-20 0:25 [ISSUE] " classabbyamp
2023-08-20 0:30 ` sgn
2023-08-20 2:51 ` classabbyamp
2023-08-22 21:24 ` motorto
2023-08-29 14:10 ` sgn
2023-12-24 19:35 ` d4r1us-drk
2023-12-24 21:17 ` 0x5c [this message]
2023-12-24 22:08 ` d4r1us-drk
2023-12-24 22:11 ` d4r1us-drk
2023-12-24 22:53 ` 0x5c
2023-12-25 1:00 ` d4r1us-drk
2023-12-25 1:07 ` classabbyamp
2023-12-25 1:56 ` sgn
2023-12-25 2:10 ` 0x5c
2023-12-25 2:13 ` d4r1us-drk
2023-12-25 2:15 ` sgn
2023-12-25 2:16 ` sgn
2023-12-25 2:17 ` sgn
2023-12-25 2:17 ` sgn
2023-12-25 2:19 ` d4r1us-drk
2023-12-25 3:03 ` 0x5c
2023-12-25 3:07 ` d4r1us-drk
2024-04-18 7:33 ` [ISSUE] [CLOSED] " classabbyamp
2024-04-18 7:33 ` classabbyamp
2024-04-19 4:43 ` ibhagwan
2024-04-20 20:24 ` d4r1us-drk
2024-04-20 20:25 ` d4r1us-drk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231224211746.PFfEmnOKt34T1ZcRcJkP485njIrwkQU_xLjNXMZflFk@z \
--to=0x5c@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).