There is something fishy with rpmbuild 4.16 (fetched from rpmdevtoolset 9.1, on a clean fedora-33 machine) with URL/Source0 being (can post the complete .spec if necessary):
# eos-rockdb.spec [...] Version: 6.11.4 URL: https://github.com/facebook/rocksdb.git Source0: https://github.com/facebook/rocksdb/archive/v%{version}.tar.gz
I could not find a pattern yet, but the following holds and it is reproducible:
rpmbuild --version # RPM version 4.16.0 dnf builddep --nogpg -y eos-rocksdb.spec rpmbuild -ba --undefine=_disable_source_fetch eos-rocksdb.spec # you'd get # warning: Downloading https://github.com/facebook/rocksdb/archive/v6.11.4.tar.gz to /root/rpmbuild/SOURCES/v6.11.4.tar.gz # curl: (23) Failure writing output to destination # error: Couldn't download https://github.com/facebook/rocksdb/archive/v5.7.3.tar.gz
Downgrading to rpmbuild 4.15.1 solves:
rpmbuild --version # RPM version 4.15.1 dnf builddep --nogpg -y eos-rocksdb.spec rpmbuild -ba --undefine=_disable_source_fetch eos-rocksdb.spec # [...] OK
Also running an explicit spectools before rpmbuild solves:
spectools
dnf builddep --nogpg -y eos-rocksdb.spec spectool -g -R eos-rocksdb.spec rpmbuild -ba --undefine=_disable_source_fetch eos-rocksdb.spec # [...] OK
Running on some other sparse project still succeeds, for both v4.16 and v4.15; the only variables at this point being "URL/Source0:"
May be related to https://pagure.io/rpmdevtools/issue/49
rpmbuild 4.16 (fetched from rpmdevtoolset 9.1, on a clean fedora-33
This sounds like you're asking for trouble :(
warning: Downloading https://github.com/facebook/rocksdb/archive/v6.11.4.tar.gz to /root/rpmbuild/SOURCES/v6.11.4.tar.gz
The answer is here: curl is trying to download to /root/ which looks like it is not writable for the current user (and probably a bad idea anyway to put downloaded stuff there???).
spectool from rpmdevtools 9+ does not use curl at all. So the error must come from RPM itself, where you're using an franken-unsupported-version.
DISCLAIMER: issue in the wrong repo, can be closed; move the "complain" to the rpm repo.
rpm
Ehm.. I may have not get that :)
Let's quickly shift from the sloppy bad practice - the result of which are clearly understood here - I beg pardon and invite future readers to pay attention to that.
This was not the problem:
[root@9cab35594357]# id uid=0(root) gid=0(root) groups=0(root) [root@9cab35594357]# ls -la /tmp/ [...] drwxrwxrwt. 1 root root 20 Oct 21 07:21 . drwxrwxrwt. 2 root root 6 Oct 21 07:21 topdir [root@9cab35594357]# rpmbuild --define "_topdir /tmp/topdir/" -ba --undefine=_disable_source_fetch eos-rocksdb.spec warning: Downloading https://github.com/facebook/rocksdb/archive/v5.7.3.tar.gz to /tmp/topdir/SOURCES/v5.7.3.tar.gz curl: (23) Failure writing output to destination error: Couldn't download https://github.com/facebook/rocksdb/archive/v5.7.3.tar.gz
This excludes the first objection. You could reproduce this, couldn't you? :)
So, I spent some time to dig more into that. (rpmdev-)spectool, or the whole rpmdevtools suite are not to blame; on the contrary they may help to workaround.
Long story short, these guys should be the responsible: https://github.com/rpm-software-management/rpm/commit/ca26c221e5d92b4908c5a07d2bba36f80379b43b https://github.com/rpm-software-management/rpm/commit/a55cb376fa9d9f785081fa13802edc3743a879ca
Prior to rpm v4.16.0 official release, rpmbuild would happily create %_sourcedir for you; it just doesn't anymore. (rpmdev-)spectool executed right before rpmbuild creates the path for you, that's why it was a valid workaround. And mkdir comes handy likewise, indeed.
I have the impression that the change was not advertised enough, let's see what happen at rpm once more people will be bitten by that. Will move the issue there to trade for some feedback.
Login to comment on this ticket.