Hi Ludo, Simon, et interested .. On +2022-10-04 12:11:52 +0200, Ludovic Courtès wrote: > Hi, > > Matthieu Haefele skribis: > > > Le 03/10/2022 à 16:03, Ludovic Courtès a écrit : > > [...] > > >> You should be able to get around it by first building things locally: > >> > >> guix build --no-substitutes \ > >> $(guix gc --derivers /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4) > >> > >> This is going to take a while though… > >> > >> I’m sorry this upgrade turns out to be so painful. We know what to work > >> on next. > >> > > Problems at fetching the kernel sources apparently... > > > > (base) mhaefele@mdlspc113:m2-mms-hpc (master)*$ guix build --no-substitutes \ > >>     $(guix gc --derivers /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4) > > The following derivations will be built: > >   /gnu/store/16c8c8hm1qdn6xz8014939mirc7c4d4j-guile-2.2.4.drv > >   /gnu/store/06pscnfdljxnyb673pqyhnvz1x5rjl1l-libgc-7.6.6.drv > > /gnu/store/4k028mc8dnnx478dirgx90rpby465jqr-ld-wrapper-boot3-0.drv > >   /gnu/store/agrwc0hhkxjb96z66nb6hakimb4a2vg3-module-import.drv > > [...] > > > Starting download of /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz > > From https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz... > > download failed "https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz" 404 "Not Found" > > [...] > > > Starting download of /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz > > From https://mirror.hydra.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg... > > In procedure connect: Network is unreachable > > You can fetch it with: > > wget -O linux-libre-4.14.67-gnu.tar.xz \ > https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg > guix download file://$PWD/linux-libre-4.14.67-gnu.tar.xz > > Let’s see if you can proceed from there. > > At any rate, it’s a good lesson for us developers, so thanks for > persevering. > > Ludo’. > As you know, particular upstream kernels can be found like --8<---------------cut here---------------start------------->8--- $ lynx -dump -listonly https://kernel.org/pub/linux/kernel/v4.x/ | egrep 4.14.67\|sha256 558. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.67 3155. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.gz 3156. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.sign 3157. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz 7177. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/patch-4.14.67.xz 9018. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc --8<---------------cut here---------------end--------------->8--- Well, you noticed the extra pattern in the search, I'm sure. :) What's interesting about sha256sums.asc is that you can do this: --8<---------------cut here---------------start------------->8--- $ wget -q -O- https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc|egrep 4\\.14\\.67 93b4ea4816a8a73e4ba2d9c26dc622035b1b504010f1048c0455a190a653166e ChangeLog-4.14.67 a53d3a3b5877e1847fb34ecb75aabce2a1bf3cc0ee7236cf2aef02f0ecf83433 linux-4.14.67.tar.gz 3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba linux-4.14.67.tar.xz 42c7ff27d7cefbf0b4e313c757db1f2cfa2d65fa22cbe908c24aafafc995bd5f patch-4.14.67.xz --8<---------------cut here---------------end--------------->8--- Which provides a little menu of relevant things. E.g, we can choose to download the .xz tarball and verify it like --8<---------------cut here---------------start------------->8--- $ time wget -q https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz real 0m47.015s user 0m2.381s sys 0m3.720s $ sha256sum linux-4.14.67.tar.xz 3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba linux-4.14.67.tar.xz --8<---------------cut here---------------end--------------->8--- IMO it would significantly enhance the security and trust assurances provided by guile and guix repos to adopt this practice from kernel.org. It is cheap and easy to implement, and provides an integrity check which can coexist with others provided in various distro VCSs and package management systems. UIAM it would also provide another option in writing a package definition in the part that defines how to get the source and check hashes. (who wants to show how it would look for the hello pachage? :) WDYT? For me, a really trusted well known figure like GkH or Linus as signer is reassuring, but I think whoever the person is is less important than providing a verifiable public coherent snapshot (if race-careful) listing of hash names for the set of files. People can then discuss the file contents and make references unambigously by hash (and discuss duplicate hashes with different file names associated :) A file identified by hash and creating trouble will soon have discussion on the net, but unless its content is unambiguously specified by its name people can't be certain they're talking about the exact same thing. That obviously the role of the hash as verifiable name here. Any decent search engine should then be able to list discussions citing the hash for you. Then we can have lists of discussions, signed by a curator ... :-p -- Regards, Bengt Richter PS. A cloned guile or guix repo is of course a directory, and selected files could be given a sha256sums.asc index and be tracked by git, updated at at specially significant commit times. Or is that crazy? WDYT?? Also, would there be places in the https://ci.guix.gnu.org/ tree that it would make sense to put sha256sums.asc instances in? E.g., What directory does https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg appear in by ordinary file name?