<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 23, 2023, 8:22 AM Erich Ritz via SlackBuilds-users <<a href="mailto:slackbuilds-users@slackbuilds.org" target="_blank" rel="noreferrer">slackbuilds-users@slackbuilds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Dimitris and Andrew and list,<br>
<br>
I don't know if this message is more appropriate for the slackrepo maintainer or the youtube-dl maintainer.<br>
<br>
When trying to build youtube-dl with slackrepo it fails with:<br>
<br>
Building network/youtube-dl (update for version 2021.12.17+20230618_07af47960) 2023-06-23 14:25:18<br>
Removing old source files ... <br>
Downloading source files ...<br>
Verifying source files ... <br>
Running youtube-dl.SlackBuild ... ETA 14:26:??<br>
env MAKEFLAGS='-j176 -l89' nice -n 5 bash ./youtube-dl.SlackBuild<br>
tar: /tmp/slackrepo/etr/slackrepo.MOV0A0/slackbuild_youtube-dl/youtube-dl-2021.12.17+20230618_07af47960.tar.xz: Cannot open: No such file or directory<br>
tar: Error is not recoverable: exiting now<br>
network/youtube-dl: youtube-dl.SlackBuild failed (status 2) 14:25:20<br>
Unmounting chroot ... <br>
:-( network/youtube-dl FAILED )-:<br>
<br>
slackrepo downloads the source file, but it is saved with a "%2B" instead of "+" in the filename. This is due to curl not doing URL decoding. Note these (partial) excerpts from curl's man page:<br>
<br>
-J, --remote-header-name<br>
There's no attempt to decode %-sequences (yet) in the provided file name,<br>
so this option may provide you with rather unexpected file names.<br>
-O, --remote-name<br>
There is no URL decoding done on the file name. If it has %20 or other<br>
URL encoded parts of the name, they will end up as-is as file name.<br>
<br>
But I can see why slackrepo chooses to use curl instead of wget for sourceforge (as pointed out by a comment in srcfunctions.sh of slackrepo):<br>
<br>
$ wget --content-disposition <a href="https://downloads.sourceforge.net/project/dslackw/src/youtube-dl-2021.12.17%2B20230618_07af47960.tar.xz2023-06-23" rel="noreferrer noreferrer noreferrer" target="_blank">https://downloads.sourceforge.net/project/dslackw/src/youtube-dl-2021.12.17%2B20230618_07af47960.tar.xz<br>
2023-06-23</a> 10:14:19 (1.09 MB/s) - ‘youtube-dl-2021.12.17+20230618_07af47960.tar.xz?viasf=1’ saved [1172376/1172376]<br>
<br>
sourceforge "helpfully" tacks on "?viasf=1" to the filename.<br>
<br>
What's the best way forward? If I remember correctly SBo policy allows for (if not encourages) the use of the "--content-disposition" flag for wget and similarly the "-J" flag for curl. However, these break the filename in this case. Should slackrepo do its own URL decoding when using curl? Should slackrepo use wget for sourceforge and rename the files (stripping off "?viasf=1")? Should SBo discourage URL encoding in filenames?<br>
<br>
Erich</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Have you tried the download_basename pragma in your hintfile?</div><div dir="auto"><br></div><div dir="auto">download_basename — provide a symlink for source downloads using the URL's basename, for the benefit of SlackBuilds that don't expect content-disposition to be respected.</div><div dir="auto"><br></div><div dir="auto">Jeremy</div></div>