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
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: 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
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: 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: 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
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: 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’.
Vim helper config for Guix
I've been meaning to upstream my guix.git specific vimrc config file,
like the .dir-locals.el in the repo. It is architected so that it also
works in git worktrees.
jump-to-definition works with C+]
If you have guix.vim installed then :Guix defaults to using
./pre-inst-env guix from that worktree.
opening new files ignores the .go files when tab completing
Most of the line indentation works pretty well. Vim, by default for lisp
languages, hardcodes an indent as 2 spaces, and I haven't gotten around
to learning how to write an indentexpr to make it work for guix. As a
result some of the indentation is close but not quite correct, and there
are some cases where the indentation is straight up ignored. I think
that's the case inside g-expressions, but I don't remember.
I've also included a link to my vimrc¹ if anyone wants to see what I
have there.
¹ https://git.sr.ht/~efraim/guix-config/tree/master/item/vim
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
" This file is a per-project '.exrc' file.
" To easily use this file to extend the global .vimrc place it in the root of
" your project and then run:
" ':source .exrc' from the root of your project.
" Add lispwords which occur in the Guix source tree.
" NB: Vim hardcodes 2 as the indentation. See get_lisp_indent in src/indent.c
setlocal lispwords+=add-after
setlocal lispwords+=add-before
setlocal lispwords+=case
setlocal lispwords+=call-with-input-file
setlocal lispwords+=define
setlocal lispwords+=define*
setlocal lispwords+=define*-public
setlocal lispwords+=define-configuration
setlocal lispwords+=define-deprecated
setlocal lispwords+=define-deprecated/public
setlocal lispwords+=define-deprecated/public-alias
setlocal lispwords+=define-gexp-compiler
setlocal lispwords+=define-module
setlocal lispwords+=define-public
setlocal lispwords+=define-record-type
setlocal lispwords+=define-record-type*
setlocal lispwords+=define-syntax
setlocal lispwords+=define-values
setlocal lispwords+=lambda
setlocal lispwords+=lambda*
setlocal lispwords+=let
setlocal lispwords+=let*
setlocal lispwords+=let*-values
setlocal lispwords+=let-syntax
setlocal lispwords+=let-values
setlocal lispwords+=letrec
setlocal lispwords+=letrec*
setlocal lispwords+=letrec-syntax
setlocal lispwords+=match-lambda
setlocal lispwords+=match-lambda*
setlocal lispwords+=match-record
setlocal lispwords+=mixed-text-file
setlocal lispwords+=modify-inputs
setlocal lispwords+=modify-phases
setlocal lispwords+=modify-services
setlocal lispwords+=parameterize
setlocal lispwords+=plain-file
setlocal lispwords+=program-file
setlocal lispwords+=replace
setlocal lispwords+=set!
setlocal lispwords+=strip-keyword-arguments
setlocal lispwords+=substitute*
setlocal lispwords+=substitute-keyword-arguments
setlocal lispwords+=syntax-rules
setlocal lispwords+=unless
setlocal lispwords+=when
setlocal lispwords+=while
setlocal lispwords+=with-directory-excursion
setlocal lispwords+=with-extensions
setlocal lispwords+=with-fluids
setlocal lispwords+=with-imported-modules
setlocal lispwords+=with-input-to-file
setlocal lispwords+=with-output-to-file
setlocal lispwords+=with-parameters
setlocal lispwords+=wrap-program
setlocal lispwords+=wrap-script
" In this repository .go files are compiled guile objects, not golang.
set wildignore+=*.go
" This is for the tie-in with guix.vim.
" TODO: guix.vim needs to correctly export autoloaded_guix.
if match(&runtimepath, 'guix') != -1
let g:guix_binary = expand('%:p:h') . "/pre-inst-env guix "
endif
" Editorconfig.vim has been distributed with vim since 9.0.1799.
if (has('syntax') && has('eval') &&
\ has("patch-9.0.1799") &&
\ filereadable('.editorconfig') &&
\ (match(&runtimepath, 'editorconfig') != -1))
packadd! editorconfig
endif
if (has("cscope") && executable('global') && executable('find'))
" These two lines could go in a gtags.conf file.
call setenv('GTAGSLABEL', 'pygments')
silent! call system("find {gnu,guix} -name '*\.scm' -print > gtags.files")
if !filereadable("GTAGS")
" This is a blocking operation, but it needs to complete before
" 'cscope add' is run. In addition, there needs to be a 'trigger' of
" some sort to cause vim to recognize the cscope database is ready if
" vim is already open.
" First run can be very slow.
call system("gtags")
"let tags_job = job_start("gtags", {'exit_cb': execute('cscope add
GTAGS $PWD -a')})
else
call system('global --update')
"let tags_job = job_start('global --update', {'exit_cb':
execute('cscope add GTAGS $PWD -a')})
endif
execute('cscope add GTAGS $PWD -a')
endif
" This should make sure gtags isn't still running.
if and(has("cscope"), executable('global'))
autocmd BufWritePost *.scm {
call system('global --update')
execute('cscope a
