Re: Error handling when 'guix substitute' dies
Dear Ludo, I ran the command in a loop on 4 machines for around 2 hours doing 1 request per machine per second but no errors occured... On 29 Mar 2024, at 16:10, Ludovic Courtès wrote: > Hello, > > Ada Stevenson skribis: > >>> diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm >>> index 37cd08e289..3af0bf0019 100755 >>> --- a/guix/scripts/substitute.scm >>> +++ b/guix/scripts/substitute.scm >>> @@ -494,7 +494,9 @@ (define* (download-nar narinfo destination >>> (define (try-fetch choices) >>> (match choices >>> (((uri compression file-size) rest ...) >>> - (guard (c ((and (pair? rest) (http-get-error? c)) >>> + (guard (c ((and (pair? rest) >>> + (or (http-get-error? c) >>> + (network-error? c))) >>> (warning (G_ "download from '~a' failed, trying next >>> URL~%") >>> (uri->string uri)) >>> (try-fetch rest))) >>> >>> I’ll go ahead with this change if there are no objections. >> Looks good to me! Thanks for looking into this :) > > OK, I’ll push it shortly, but… > > Lars Bilke skribis: > >> thanks Ada for bringing this issue up again. I get the same error on >> `guix pull` almost always when I am on my enterprise >> network. Re-running `guix pull` a second time also almost always then >> runs fine. I checked with our IT: nothing suspicious on the network, >> i.e. no firewall blocking. >> >> I never experienced the error on my home network. > > … your reports make me think there’s a bug lurking somewhere that > perhaps only manifests under some precise networking or timing > conditions. > > Could the two of you run the following command in a loop to see whether > it’s easy to reproduce that GnuTLS error? > > guile -c '(use-modules (guix http-client) (ice-9 binary-ports)) > (get-bytevector-all (http-fetch > "https://ci.guix.gnu.org/nix-cache-info;))' > > If you can reproduce it, could you capture the strace output of the > process? You would run the command above prefixed by: > > strace -o log.strace -s 300 … > > Thanks in advance! > > Ludo’.
Google Summer of Code Inquiry
Hello Zachary, just wanted to chime in. Since last week I have some working code to generate AppImages with guix pack. I was planning on tidying this up for submission over the next weeks. There is still work to do regarding documentation, adding options specific to the AppImage format, building the AppImageKit runtime from source and a lot of testing. However, I believe that the remaining effort is around 8-10 hours. I am happy to hand the code over to you to finish up and co-mentor (though this patch would be my first contribution to guix) if you think this is appropriate. I do not wish to discourage from contribtuting to the project, just hoping to avoid duplicated efforts Best Sebastian PS: this is also my first message sent to a mailing list, hope it makes it through ok. Please point out any errors or breackes in netiquette
Re: Coordinators for patch review session on Tuesday
Hi, This is just to say that I went to review [2], but ended up making the changes myself, so I've submitted modified patches for those packages. Hopefully they're of a quality that's worth pushing. I'm going to be busy this weekend, but I'll see if I get time to do some reviewing later on. It's actually quite fun! Kind regards, Christina [2] https://debbugs.gnu.org/cgi-bin/bugreport.cgi?users=guix;bug=56576 On 03/04/2024 12:00, Christina O'Donnell wrote: Hi Steve, On 02/04/2024 21:23, Steve George wrote: Hi Christina - thanks for coming along today - I hope it was useful. Yes I did find it helpful. Since I'm the least experienced out of everyone there, I just stayed quiet and tried to absorb as much as I could. It was good to see that not everyone was using Emacs, and I'm going to try to start using Efraim's vi script for GTAGS in Guile. There's good instructions on the Wiki on how to review patches: https://libreplanet.org/wiki?title=Group:Guix/PatchReviewSessions2024 I would love feedback on how to improve them! There's plenty of patches to review, I've been keeping a list of them for the patch review calls: https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;users=guix And the wiki page references some other reports. Please pick some patches and have a go - if you want someone else to look at them feel free to ping here or on IRC! Thank you for writing this up in so much depth! I've reviewed [1] and tried to tag it as reviewed-looks-good, though I don't think that has gone through. If you or someone else could take a look at it then I'd appreciate that. I plan on reviewing some more patches this evening. Kind regards, Christina [1] https://debbugs.gnu.org/cgi-bin/bugreport.cgi?users=guix;bug=65938
Re: PyTorch with ROCm
Hello, Ludovic Courtès writes: > Yeah, we could think about a transformation option. Maybe > ‘--with-configure-flags=python-pytorch=-DAMDGPU_TARGETS=xyz’ would work, > and if not, we can come up with a specific transformation and/or an > procedure that takes a list of architectures and returns a package. I think that would work for python-pytorch itself, but it would need to be set for all ROCm dependencies as well. It would be good to make sure that the targets for a package are a subset of the intersection of the targets specified for its dependencies. - Many tests assume a GPU to be present, so they need to be disabled. >>> >>> Yes. I/we’d like to eventually support that. (There’d need to be some >>> annotation in derivations or packages specifying what hardware is >>> required, and ‘cuirass remote-worker’, ‘guix offload’, etc. would need >>> to honor that.) >> >> That sounds like a good idea, could this also include CPU ISA >> extensions, such as AVX2 and AVX-512? > > That’d be great, yes. Don’t hold your breath though as I/we haven’t > scheduled work on this yet. If you’re interested in working on it, we > can discuss it of course. I am definitively interested, but am not familiar with Cuirass. Would this also require support by the build daemon to determine which hardware is available? >> I think the issue is simply that elf-file? just checks the magic bytes >> and has-elf-header? checks for the entire header. If the former returns >> #t and the latter #f, an error is raised by parse-elf in guix/elf.scm. >> It seems some ROCm (or tensile?) ELF files have another header format. > > Uh, never came across such a situation. What’s so special about those > ELF files? How are they created? After checking again, I noticed that the error actually only occurs for rocblas. :) Here, the problematic ELF files are generated by Tensile [1], and are installed in lib/rocblas/library (by library/src/CMakeLists.txt, which calls a CMake function from the Tensile package). They are shared object libraries for the GPU architecture(s) [2]. Tensile uses `clang-offload-builder` (from rocm-toolchain) to create the files, and it seems to me that the "ELF" header comes from there, but I don't know why it is special. Thanks, David [1] https://github.com/ROCm/Tensile/blob/17df881bde80fc20f997dfb290f4bb4b0e05a7e9/Tensile/TensileCreateLibrary.py#L283 [2] https://github.com/ROCm/Tensile/wiki/TensileCreateLibrary#code-object-libraries
Re: Should we include nss-certs out of the box?
Hi Maxim, On Wed, Apr 03 2024, Maxim Cournoyer wrote: > I applaud the idea to have the users make a conscious decision Who does? > It apparently even makes it impossible to run 'guix pull' More than that, the references to online sources in our package declarations are useless. Would it be possible to install nss-certs from source? > [nss-certs would] be in the basic set of an operating-system packages That strikes me as rational but it would be valuable to hear from the other side---if there is one. Kind regards Felix
Re: Should we include nss-certs out of the box?
On Wednesday, April 3rd, 2024 at 1:06 PM, Maxim Cournoyer wrote: > Is anyone opposed to having nss-certs in %base-packages? I applaud that plan. Not only that, I think that Guix should warn if you don't have nss-certs in your profile on a foreign distro (with a mechanism to suppress that, ofc) Lacking the nss-certs package causes all manner of trouble and is a stumbling block to adoption. It's practically a dependency; the ability to operate without it is kind of a party trick. Ryan
Should we include nss-certs out of the box?
Hi, It's been Guix policy to let people choose whether to install or not TLS root certificates and which one to their machine. While I applaud the idea to have the users make a conscious decision about it, in practice I suppose very few of us choose to *not* install any as that basically breaks using web browsers, especially ones like IceCat which (by default) ensures HTTPS is used on every page. It apparently even makes it impossible to run 'guix pull', if I am to believe bug#62026. Should we do as in bug#62026 and have this package be part of the recommended basic installation? It'd be in the basic set of an operating-system packages (via its default %base-packages set). It could still be manipulated via the Guix API (filtered out/replaced with something else). Is anyone opposed to having nss-certs in %base-packages? -- Thanks, Maxim
Re: Coordinators for patch review session on Tuesday
Hi Steve, On 02/04/2024 21:23, Steve George wrote: Hi Christina - thanks for coming along today - I hope it was useful. Yes I did find it helpful. Since I'm the least experienced out of everyone there, I just stayed quiet and tried to absorb as much as I could. It was good to see that not everyone was using Emacs, and I'm going to try to start using Efraim's vi script for GTAGS in Guile. There's good instructions on the Wiki on how to review patches: https://libreplanet.org/wiki?title=Group:Guix/PatchReviewSessions2024 I would love feedback on how to improve them! There's plenty of patches to review, I've been keeping a list of them for the patch review calls: https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;users=guix And the wiki page references some other reports. Please pick some patches and have a go - if you want someone else to look at them feel free to ping here or on IRC! Thank you for writing this up in so much depth! I've reviewed [1] and tried to tag it as reviewed-looks-good, though I don't think that has gone through. If you or someone else could take a look at it then I'd appreciate that. I plan on reviewing some more patches this evening. Kind regards, Christina [1] https://debbugs.gnu.org/cgi-bin/bugreport.cgi?users=guix;bug=65938
