SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux
_whitelogger has joined #crux
lavaball has joined #crux
lavaball has quit [Remote host closed the connection]
gub_ has joined #crux
mrms_ has joined #crux
hirigara1 has joined #crux
hirigara1 has quit [Changing host]
hirigara1 has joined #crux
mrms has quit [*.net *.split]
gub has quit [*.net *.split]
hirigaray has quit [*.net *.split]
mrms_ is now known as mrms
gub_ is now known as gub
<farkuhar>
The response to curl issue 17554 implies that pkgmk has been making the wrong assumption about exit status when the upstream file is not found and --retry 3 is passed. Apparently, it took until version 8.14 for curl to satisfy its own unit tests; previous versions were all returning nonzero for that particular combination of flags and failure mode.
<farkuhar>
Supposing that the curl unit tests were changed between 8.13 and 8.14, and the older behaviour is really what we should expect, then pkgmk's error handling is not at fault. But if curl's test 1634 is correctly written, then pkgmk will have to change how it handles the curl exit status, or the flags that are passed to curl.
lavaball has joined #crux
<farkuhar>
In the section of curl(1) that explains --retry-all-errors, it says "curl does not return error for transfers with an HTTP response code that indicates an HTTP error", giving 404 not found as an example response that is not regarded as an error. Combining --retry 3 with --fail is only supposed to toggle whether the connection is attempted again after an HTTP error, it's not meant to toggle the exit status
<farkuhar>
(which according to unit test 1634 was supposed to be 0).
<farkuhar>
curl is not the only third-party utility whose API is subject to questionable assumptions by pkgmk. The invocation of find(1) during the compression of man-pages, for example, assumes that the non-POSIX operand -printf will be recognized. Replacing core/findutils with its suckless implementation sbase would require rewriting that section of pkgmk.
<farkuhar>
The -printf extension to find(1) is not unique to the GNU project, but a number of popular implementations (including that of OpenBSD) do not recognize that operand. It might be worthwhile to clean up those sections of pkgmk that rely on non-POSIX extensions of coreutils and findutils.
<farkuhar>
Actually it's the strip_files function in pkgmk (not the compress_manpages function) that relies on a non-POSIX extension of find(1). In any case, the hidden dependency on GNU extensions has the side-effect of restricting user choices, so they cannot easily swap out {coreutils,findutils,util-linux} with suckless {sbase,ubase}.