On Sat, Feb 20, 2016 at 08:30:31PM -0500, Mark H Weaver wrote: > Mark H Weaver <m...@netris.org> writes: > > > Christopher Allan Webber <cweb...@dustycloud.org> writes: > > > >> Efraim Flashner writes: > >> > >>> On Sat, 20 Feb 2016 10:19:51 -0800 > >>> Christopher Allan Webber <cweb...@dustycloud.org> wrote: > >>> > >>>> Earlier today I tried doing a build without substitutes. I was > >>>> surprised to see this error: > >>>> > >>>> Starting download of > >>>> /gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0 > >>>> From > >>>> http://git.savannah.gnu.org/cgit/coreutils.git/patch/?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0... > >>>> patch 1.2MiB/s 00:00 | 1KiB > >>>> transferred > >>>> output path > >>>> `/gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0' > >>>> should have sha256 hash > >>>> `1dnlszhc8lihhg801i9sz896mlrgfsjfcz62636prb27k5hmixqz', instead has > >>>> `0zygncr1z1nswmny2vl1havfqswm40vzj0vjvhf5yndavhzr267j' > >>>> > >>>> From the coreutils definition: > >>>> (patches > >>>> (list (origin > >>>> (method url-fetch) > >>>> (uri > >>>> "http://git.savannah.gnu.org/cgit/coreutils.git/\ > >>>> patch/?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0") > >>>> (sha256 > >>>> (base32 > >>>> > >>>> "1dnlszhc8lihhg801i9sz896mlrgfsjfcz62636prb27k5hmixqz")) > >>>> (file-name "coreutils-tail-inotify-race.patch")))))) > >>>> > >>>> But indeed, it's not surprising that there's a hash mismatch... there's > >>>> nothing here! > >>>> > >>>> > >>>> http://git.savannah.gnu.org/cgit/coreutils.git/patch/?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0 > >>>> > >>> > >>> I updated coreutils on core-updates which included removing the patch from > >>> the package definition. > >> > >> Thanks! In case it's useful, here's a patch which includes the patch > >> itself rather than pulling it down via http. > > > > I fixed this differently, in commit 1a51cbc825, by simply removing the > > "/" before the "?" in the URL. > > I had to revert this, because it caused a full rebuild. > To be continued...
This seems like a strange result, given that the patch had the same hash and was stored with the same name. Does anyone have any insight on this issue? > > Mark >
