Re: Better support remote deployment
On 2023-11-16 16:23:00 +0100, Ludovic Courtès wrote: > Hi, > > Maxim Cournoyer skribis: > > > Felix Lechner writes: > > [...] > > >> How about a 'remote-user-profile'? > > > > 'guix package' is already the command we use to create profiles; maybe > > it could accept a '--remote' argument to operate on a remote machine? > > Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package > > -m manifest.scm' can already accomplish? :-) > > Doing that confuses ‘guix package’ because it’d try to perform the > effectful part (switching symlinks) locally, even though everything was > built on another machine. (It’s also slow due to RPC round trips, as > Efraim wrote.) > > But yeah, I think we could do something along these lines by isolating > the effectful bits and evaluating them remotely when needed, like we did > to achieve code sharing between ‘guix deploy’ and ‘guix system > reconfigure’. > > That said, I wonder if this would really be more convenient than SSH’ing > into the target machine and running the commands right there. Perhaps > I’m missing something about the use case? I was following the debate, but maybe I have missed something, so I will put forward my use case as well. I have two properties I would like to have from a "remote deploy" mechanism, and they are not satisfied by SSH-ing to the machine and running the commands there. 1. No need for `guix pull'. I run (a little) custom Guix, so running `guix pull' is somewhat expensive. I do not want to do it just to deploy something (be it a system, or home, or profile). 2. No need to copy over the definitions. My configurations are part of a git repository, which I would like to keep local to just my development machine. So rsync-ing it over to the remote machine in order to run command there is something I would like to avoid. If, however, I can build a profile locally, `guix copy' it over, and *then* SSH into the machine and somehow activate the profile (be it home or regular profile), that would work for me. Is that currently possible? > > Ludo’. > Thanks, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
"random check" approach to Guix QA?
Hi, currently Guix QA tries to rebuild all dependent packages impacted by a change (in majority of cases updates to a new version of a package). When there are a large number of dependent packages like say 500 or 1000 or more, rebuilding all that takes a long time and often the rebuild cannot complete, leaving the patch submission dangling with no results. For some things where safety is important, for example import food safety, the regulatory authority may use random check or random sampling as a way to check for safety, in case that there is no resource to physically check every package. Can the same approach be borrowed here, so when there is large number of impacted packages from a patch, say larger than 200, Guix QA just randomly select a subset sample out of these packages and build them, and in case of (new) failures ask the submitter to fix the (new) failure? And repeat this as needed. This way patches can go thru the QA process more quickly.
Re: $EDITOR and “guix edit”
Am Montag, dem 20.11.2023 um 10:40 +0100 schrieb Simon Tournier: > Hi, > > On Thu, 16 Nov 2023 at 17:04, Liliana Marie Prikler > wrote: > > > > It’d be nice to support these as well. However, how do we know > > > we’re dealing with kate or VSCode? By checking the basename of > > > $EDITOR? Kinda ugly and brittle, but probably better than > > > nothing. > > > > Maybe we can check for a guix_editor shell function and invoke that > > rather than EDITOR if defined? > > Yeah, from my point of view, the two alternatives [1] are: > > 1. do we tweak “guix edit” for behaving differently depending on > $EDITOR? > > or > > 2. do we provide some wrappers for the issues that already popped > up? > > Where #1 is what Ludo suggests and #2 is what Liliana suggests. :-) > > Well, see below the code [2] that we concretely need for VSCode. The > question is: > > 1. Do we put this code in guix/scripts/edit.scm? And trigger on the > basename of EDITOR? > > or > > 2. Do we put this code in some etc/vscode-wrapper that user can > install? (or that we could automatically installl) Or maybe revamp > it > for calling this code via some shell function? With VSCode et al. not being Guix packages, I see little point in providing these wrappers through Guix itself. With kate we could at least install a "kate-for-guix-edit" wrapper through the package or something. Cheers
Re: [maintenance] Compressed JSON files and served file extension?
TL;DR the filename shouldn't contain the .gz extension, and the HTTP standard
is crap ("If no Accept-Encoding field is present in a request, the server MAY
assume that the client will accept any content coding.").
use curl --compressed
the details:
the Content-Encoding response header instructs the client on how to decode the
__transfer payload__ that the server is serving.
i.e. proper HTTP clients should automatically decode the content as instructed
by the Content-Encoding response header, or at the very least warn that they do
not understand the response encoding...
but that should not happen, because the HTTP request can contain an
Accept-Encoding header that tells the server what the client understands, and
it defaults to unprocessed raw data ('identity')...
except that the standard allows the server to ignore the Accept-Encoding
request header.
well, this is the theory, but both wget and curl don't automatically decode the
content. curl at least can be instructed to do so, which arguably should be its
default:
curl --compressed https://guix.gnu.org/sources.json | less
--verbose can be used to inspect the reques/response headers (printed to
stderr):
curl --verbose https://guix.gnu.org/sources.json >/dev/null
curl --verbose --compressed https://guix.gnu.org/sources.json >/dev/null
here's a detailed discussion of this very question:
https://stackoverflow.com/questions/8364640/how-to-properly-handle-a-gzipped-page-when-using-curl
so, in an ideal world wget and curl should transparently decode the content
according to the Content-Encoding response header, and nginx should not respond
with a compressed content when the client is not sending an Accept-Encoding
request header.
the pragmatic solution is to use curl --compressed in scripts, and/or add it to
your ~/.curlrc:
# to automatically decode responses with some of
# the supported Content-Encoding
compressed
HTH,
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“We need people in our lives with whom we can be as open as possible. To have
real conversations with people may seem like such a simple, obvious suggestion,
but it involves courage and risk.”
— Thomas Moore (1940–)
Re: core-updates?
Hi Andy, On Mon, Nov 20 2023, Andy Tai wrote: > I have a two-line addition patch that may cause rebuilds of > 10K packages What's the patch, please? Kind regards Felix
Re: Confusing overview of mailing lists
On Thu, Nov 16, 2023 at 02:37:43AM +0100, Erik Grun wrote: > Hello, Guix, > > For some time now I've been using Guix on a few test machines. I have to > say, that I really like it. So much so, that I've now finally wanted to get > involved a bit closer. So I went to this page[1] with the overview of all > the mailing lists. > > Personally I find the links to the mailing list archives on the "Contact" > page a bit confusing. Because on the first look it appears, as if those list > are "archived". It looks even more so since not every list has the > "(Archive)" behind its name. > > My suggestion would be, to remove the archive links altogether from that > page. I mean, one can still get to the archives, when one goes to the > respective mailing list. > > If this topic doesn't fit here, please move it to the correct list (and keep > me in the CC). > > Best regards, > > Erik (egnun) > > [1] https://guix.gnu.org/en/contact I looked at the two links. Perhaps we could change it to (past archives), although I understand we refer to the mailing list archive when we're referring to previous mails sent to that mailing list. Alternatively, we could just get rid of it, that extra link only saves 1 click if you wanted to go and see the archives. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: $EDITOR and “guix edit”
Hi, On Thu, 16 Nov 2023 at 17:04, Liliana Marie Prikler wrote: >> It’d be nice to support these as well. However, how do we know we’re >> dealing with kate or VSCode? By checking the basename of $EDITOR? >> Kinda ugly and brittle, but probably better than nothing. > > Maybe we can check for a guix_editor shell function and invoke that > rather than EDITOR if defined? Yeah, from my point of view, the two alternatives [1] are: 1. do we tweak “guix edit” for behaving differently depending on $EDITOR? or 2. do we provide some wrappers for the issues that already popped up? Where #1 is what Ludo suggests and #2 is what Liliana suggests. :-) Well, see below the code [2] that we concretely need for VSCode. The question is: 1. Do we put this code in guix/scripts/edit.scm? And trigger on the basename of EDITOR? or 2. Do we put this code in some etc/vscode-wrapper that user can install? (or that we could automatically installl) Or maybe revamp it for calling this code via some shell function? WDYT? Cheers, simon --8<---cut here---start->8--- #!/usr/bin/env -S guix repl -q -- ;; -*- mode: scheme -*- !# ;;; Copyright © 2023 Simon Tournier ;;; ;;; ;;; VSCode does not respect the convention: ;;; ;;; $EDITOR +line file ;;; ;;; and instead relies on: ;;; ;;; code --goto file:line ;;; ;;; ;;; This wrapper is a workaround. It is Scheme but it could be whatever else ;;; as Bash, Python, etc. It uses "guix repl" although no Guix library is ;;; required. Because we assume the invokation, ;;; ;;; EDITOR=./vscode-wrapper guix edit foo bar ;;; ;;; relying on "guix repl" allows to easily get Guile. ;;; (use-modules (ice-9 match) ((ice-9 string-fun) #:select (string-replace-substring)) ((ice-9 ftw) #:select (scandir)) ) (define %vscode--goto (let* ((vscode-server (string-append (getenv "HOME") "/.vscode-server")) (code (if (file-exists? vscode-server) ;; Maybe Remote-SSH (let* ((vscode-server/bin (string-append vscode-server "/bin")) (hash ;Guess the correct identifier (car (scandir vscode-server/bin (lambda (file) (not (member file (list "." ".." (lambda (x y) (> (stat:mtime (lstat (string-append vscode-server/bin "/" x))) (stat:mtime (lstat (string-append vscode-server/bin "/" y (vscode (string-append vscode-server/bin "/" hash "/bin/remote-cli/code")) (run/user/uid (string-append "/run/user/" (number->string (getuid (socket ;Guess the correct socket, if required (car (scandir run/user/uid (lambda (file) (string-prefix? "vscode-ipc" file)) (lambda (x y) (< (stat:mtime (lstat (string-append run/user/uid "/" x))) (stat:mtime (lstat (string-append run/user/uid "/" y) ;; : Check VSCode API for something more robust (if (getenv "VSCODE_IPC_HOOK_CLI") vscode (string-append "VSCODE_IPC_HOOK_CLI=" socket " " vscode))) ;; No Remote-SSH, try to find the local one in PATH (search-path (string-split (getenv "PATH") #\:) "code" ;(format #t "~a~%" code) (string-append code " --goto "))) (define +line-files (match (command-line) ((wrapper rest ...) (if (eqv? 0 (modulo (length rest) 2)) rest (begin (write "Error with 'guix edit'") (exit 1)) (define files (let loop ((files:lines '()) (lst +line-files)) (if (null? lst) (reverse files:lines) (match lst ((n file rest ...) (loop (cons (string-append file ":" (string-replace-substring n "+" "")) files:lines) rest)) (catch 'system-error (lambda () (for-each (lambda (file) (system (string-append %vscode--goto file))) files)) (lambda _ (write "failed to launch!"))) -
Re: [maintenance] Compressed JSON files and served file extension?
Hi, On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès wrote: >> However, now I get: >> >> $ wget https://guix.gnu.org/sources.json > > If you open it in a browser though, it’s fine, because browsers and in > fact many HTTP clients other than wget, honor ‘Content-Encoding’: [...] > That said, if you become aware of actual breakage, we can revisit this! Could we have a self-consistent name? The expected extension when a file is Gziped compressed is .gz. Why not put it? 1. It costs us nothing. 2. How to read the file is then clearer. Cheers, simon
Re: Request-For-Comment process: concrete implementation
Hi Ludo, Thanks for giving a look. On Thu, 16 Nov 2023 at 16:03, Ludovic Courtès wrote: > Thanks for starting the discussion! I think that getting such a process > in place is key to sustain friction-less development of Guix, giving > everyone a chance to have their voice heard. Do you have comments on the current proposal? About points where you think they could be improved? As wording? Or process? Or else? Cheers, simon
core-updates?
Hi, I hope core-updates is the mean for some patches to get merged; I have a two-line addition patch that may cause rebuilds of 10K packages but I would think asking for a feature branch for such a patch is overkill. so I sent it to target core-updates and hope this can be a quicker way for it to get in.
