Re: guix shell readline issue with R
Edouard Klein writes: > Here is a script that restores the ctrl-C behaviour of R, whithin a guix > shell. > > I must admit I don't exactly understand the finer points of why it works, but > just trapping SIGINT in the script is enough for R to behave. > > My intuition is SIGINT is sent to the whole group. The script > interrupts R. If we trap it in the script, it does nothing. R gets it as well > and acts on it like you expect. Thanks, Edouard! Your script worked perfectly just as you described. I was sorely missing that `set -m' call and passing true from the bash function. I also really like your idea for the shebang line. Best Regards, Kyle
Re: guix shell readline issue with R
Edouard Klein writes: > Hi Kyle, > > > Running > guix shell r > > and then > R > > will get you the C-c handling you want. Hi Edouard, I wrote another reply, but forgot to comment on this because I feel like I am missing something here. It would be really convenient if I could just write a shell script like that. For me the first command hijacks the execution so that the script cannot invoke R. Is there a workaround avoiding -- which would let me automate that with a script? Cheers, Kyle
Re: guix shell readline issue with R
Edouard Klein writes: > Hi Kyle, > > > Running > guix shell r > > and then > R > > will get you the C-c handling you want. > > There is indeed readline support with guix shell r -- R: > up arrow to get history, c-E, c-A for end of line, start if line, etc. > > I think maybe the problem lies not with readline but with the way > signals are handled. I can't seem to understand exactly how, but I would > look into that direction. > > Cheers, > > Edouard. Thanks Edouard for pointing out that the problem is signals-related and not readline related. I spent a little time refreshing my memory about signals, looking at the following shell scripting references. => https://linuxcommand.org/lc3_wss0150.php => https://mywiki.wooledge.org/SignalTrap I tried using tools like trap, wait, and exec, but haven't yet found an approach that worked. I placed a basic R manifest here if anyone would like to try: => https://paste.debian.net/1284782/ Basically my shell script was: ``` #!/bin/sh guix shell -m /tmp/manifest.scm -- R --no-save --quiet --no-restore ``` In the R REPL I interactively test the problem with: ``` while(TRUE) Sys.sleep(1) C-c C-c ``` Cheers, Kyle > Kyle Andrews writes: > >> Dear Guix, >> >> When I run `guix install r` and then start an R process I get a >> readline-enabled >> REPL where I can abort commands with C-c C-c while keeping the process alive >> afterwards. When I run R from `guix shell r -- R` I don't get any readline >> support in R. Pressing C-c immediately aborts the process. This is >> inconvenient >> for interactive exploration. Is there a way to make guix shell work the same >> way >> as if the R command was installed into a profile? >> >> Thanks for your help, >> Kyle
guix shell readline issue with R
Dear Guix, When I run `guix install r` and then start an R process I get a readline-enabled REPL where I can abort commands with C-c C-c while keeping the process alive afterwards. When I run R from `guix shell r -- R` I don't get any readline support in R. Pressing C-c immediately aborts the process. This is inconvenient for interactive exploration. Is there a way to make guix shell work the same way as if the R command was installed into a profile? Thanks for your help, Kyle
Re: Alternatives to --emulate-fhs on foreign distros
Thanks so much! That is perfect. On April 22, 2023 4:36:08 PM EDT, Maxim Cournoyer wrote: >Hi Kyle, > >Kyle writes: > >> Dear Maxim, >> >> Unfortunately, I don't see /usr/bin/env when I look inside the file system >> resulting from: >> >> guix shell coreutils --container >> > >For this use case, I use the --symlink option, like so: >'--symlink=/usr/bin/env=bin/env'. > >-- >Thanks, >Maxim
Re: Alternatives to --emulate-fhs on foreign distros
Note that the easiest standalone TXR script I could think of is: ``` #!/usr/bin/env txr #(output) Hi @(end) ``` I am betting you probably could include that in a package to reproduce the issue. On April 21, 2023 2:35:30 PM EDT, Kyle wrote: >Its kind of hard to test. The easiest I have managed has been to see that I >don't get the error with --emulate-fhs in my call, and the script that fails >starts with: > >#!/usr/bin/env txr > >To simplify things, I made a self contained txr script and wrapped that up in >my test R package. Sure enough, after building the package I checked its store >directory. Guix did not patch the path to the path to the env utility in that >case. >
Re: Alternatives to --emulate-fhs on foreign distros
Its kind of hard to test. The easiest I have managed has been to see that I don't get the error with --emulate-fhs in my call, and the script that fails starts with: #!/usr/bin/env txr To simplify things, I made a self contained txr script and wrapped that up in my test R package. Sure enough, after building the package I checked its store directory. Guix did not patch the path to the path to the env utility in that case.
Re: Alternatives to --emulate-fhs on foreign distros
Dear Maxim, Unfortunately, I don't see /usr/bin/env when I look inside the file system resulting from: guix shell coreutils --container I don't understand how to apply "system" configuration to a guix shell container other than crudely through --emulate-fhs. Since noone has needed it so far, maybe that's not that helpful if /bin/bash was made available? On April 20, 2023 8:56:47 AM EDT, Maxim Cournoyer wrote: >Hi Kyle, > >Kyle Andrews writes: > >> Dear Guix, >> >> The (many) shell scripts in my software depend on bashisms. In the >> code right now I typically use /usr/bin/env bash since I had read that >> was the most portable way of referencing a shell. However, I really >> don't think I have a good handle on what my choices are. Maybe the >> tedious solution of just typing `bash script.sh' in all of the system >> calls referencing this scripts might be the right approach in the long >> run? > >Use /usr/bin/env. It's available on all mainstream distributions, and >it's also available on Guix System, so it should work everywhere. > >-- >Thanks, >Maxim
Re: Alternatives to --emulate-fhs on foreign distros
"(" writes:
> Kyle writes:
>> The context is that my R package calls a bunch of shell scripts stored
>> inside it. I am getting errors about
>> /usr/bin/env not being available (e.g. bad interpreter: no such file or
>> directory), so was thinking that their
>> shebangs were not getting patched. It's not clear to me how thorough Guix is
>> being at finding these.
>
> Hmm. Can you show me an example of one of these scripts? (The
> R-BUILD-SYSTEM *does* seem to include 'PATCH-SHEBANGS...)
You are right about this. I created a minimal reproducible R package with a
basic shell script included and the shebangs were patched. I'm still trying to
figure out the actual cause of my shell errors.
Re: Alternatives to --emulate-fhs on foreign distros
The context is that my R package calls a bunch of shell scripts stored inside
it. I am getting errors about /usr/bin/env not being available (e.g. bad
interpreter: no such file or directory), so was thinking that their shebangs
were not getting patched. It's not clear to me how thorough Guix is being at
finding these.
On April 19, 2023 11:10:44 AM EDT, "(" wrote:
>
>Kyle Andrews writes:
>> The (many) shell scripts in my software depend on bashisms. In the code right
>> now I typically use /usr/bin/env bash since I had read that was the most
>> portable way of referencing a shell. However, I really don't think I have a
>> good
>> handle on what my choices are. Maybe the tedious solution of just typing
>> `bash
>> script.sh' in all of the system calls referencing this scripts might be the
>> right approach in the long run?
>
>``/usr/bin/env bash'' will automatically be substituted for the path to
>an available ``/bin/bash'' in the store. (If that's what you're talking
>about here; not sure what the context is exactly.)
Alternatives to --emulate-fhs on foreign distros
Dear Guix,
The (many) shell scripts in my software depend on bashisms. In the code right
now I typically use /usr/bin/env bash since I had read that was the most
portable way of referencing a shell. However, I really don't think I have a
good handle on what my choices are. Maybe the tedious solution of just typing
`bash script.sh' in all of the system calls referencing this scripts might be
the right approach in the long run?
Should I be aiming to automatically patch my source code to point to a specific
bash? Why doesn't this happen automatically? Is there a way to upgrade from
/bin/sh to bash within a shell script? I know I can use --emulate-fhs to ensure
that /bin/bash and /usr/bin/env bash are available, but that seems to preclude
including the software directly in Guix without a container.
I'm curious what other options might be. The main bashism I use is default
environment variables ${FOO:-bar}. On a native Guix system I could just add
/usr/bin/env back in. However, that doesn't seem to be possible with only Guix
shell. Maybe I am wrong here?
Thanks,
Kyle
Re: How to copy a file to the package /bin folder using the r-build-system?
"(" writes:
> [[PGP Signed Part:Undecided]]
> Heya,
>
> On Sun Apr 9, 2023 at 4:15 AM BST, Kyle Andrews wrote:
>> > (lambda _
>> > (mkdir (string-append #$output "/bin"))
>> > (copy-file "inst/bin/r"
>> > (string-append #$output "/bin/r")))
>>
>> This perfect makes sense now and is much more concise.
>
> Actually, you can even do:
>
> ```
> (lambda _
> (install-file "inst/bin/r"
> (string-append #$output "/bin")))
> ```
That is nice and intentional!
>> ```
>> $ guix build -L dev r-littler
>> ...
>> ld: cannot find -lz
>> collect2: error: ld returned 1 exit status
>> ...
>> ```
>>
>> I know I have seen that error before, but I thought it was fixed by
>> importing compression, prefixing (guix licenses) to prevent a
>> namespace collision, and including zlib in the package inputs.
>
> I think (!) you also need to import (gnu packages pkg-config) and add
> PKG-CONFIG to NATIVE-INPUTS.
That fixed it! Thanks!
> -- (
Re: How to copy a file to the package /bin folder using the r-build-system?
Simon Tournier writes: > Hi, > > On ven., 31 mars 2023 at 23:21, Kyle Andrews wrote: > >>(let ((out (assoc-ref outputs "out"))) >> ;;; TODO: this doesn't work! >> ;; copy site-library/littler/bin/r to bin/r >> (copy-file >> (string-append out "site-library/littler/src/r") >> (string-append out "/bin/r" > > I guess what you want is: > > --8<---cut here---start->8--- > (let* ((out (assoc-ref outputs "out")) > (out/bin (string-append out "/bin"))) > (mkdir out/bin) > (copy-file "inst/bin/r" > (string-append out/bin "/r" > --8<---cut here---end--->8--- Gotcha. That must mean my mental model should be that "out" refers to the directory in the store, while the working directory is inside of the decompressed source directory. I probably should have inferred that would almost always be the case since most build-systems will (re-)use 'unpack. I also made the mistake of now always starting my path strings with a forward slash. > > And I would write, > > (lambda _ > (mkdir (string-append #$output "/bin")) > (copy-file "inst/bin/r" > (string-append #$output "/bin/r"))) This perfect makes sense now and is much more concise. > > > Well, using one or the other, I get: > > --8<---cut here---start->8--- > $ guix shell -L /tmp/foo r-littler -C -- r --help > > Usage: r [options] [-|file] > > Launch GNU R to execute the R commands supplied in the specified file, or > from stdin if '-' is used. Suitable for so-called shebang '#!/'-line scripts. > > Options: > -h, --help Give this help list > --usage Give a short usage message > -V, --versionShow the version number > -v, --vanillaPass the '--vanilla' option to R > -t, --rtemp Use per-session temporary directory as R does > -i, --interactiveLet interactive() return 'true' rather than 'false' > -q, --quick Skip autoload / delayed assign of default libraries > -p, --verbosePrint the value of expressions to the console > -l, --packages list Load the R packages from the comma-separated 'list' > -d, --datastdin Prepend command to load 'X' as csv from stdin > -L, --libpath dirAdd directory to library path via '.libPaths(dir)' > -e, --eval expr Let R evaluate 'expr' > > --8<---cut here---end--->8--- > Thanks! I had been "toggling" back and forth between (packages->manifest (list r-littler)) and r-littler. In other words, the former gets uncommented when running guix shell -m littler.scm while the latter gets uncommented when used with guix build -f r-littler with the former getting commented. I can see from your example how writing a module would obviate the need to edit the source file over and over with the promise that alternatives can be illustrated at the same level. Sadly, when I tried to take that idea and run with it I got an unexpected error. ``` $ guix build -L dev r-littler ... ld: cannot find -lz collect2: error: ld returned 1 exit status ... ``` I know I have seen that error before, but I thought it was fixed by importing compression, prefixing (guix licenses) to prevent a namespace collision, and including zlib in the package inputs. ``` $ diff littler.scm dev/littler.scm 1,11c1,11 < (use-modules < (guix packages) < (guix download) < (gnu packages statistics) < (gnu packages compression) < (gnu packages icu4c) < (guix gexp) < (guix build-system r) < (gnu packages cran) < (gnu packages autotools) < ((guix licenses) #:prefix license:)) --- > (define-module (littler) > #:use-module (guix packages) > #:use-module (guix download) > #:use-module (gnu packages statistics) > #:use-module (gnu packages compression) > #:use-module (gnu packages icu4c) > #:use-module (guix gexp) > #:use-module (guix build-system r) > #:use-module (gnu packages cran) > #:use-module (gnu packages autotools) > #:use-module ((guix licenses) #:prefix license:)) 47,50d46 < < ;; (packages->manifest (list r r-littler)) < < r-littler ``` Meanwhile, your command ran the same for me as it did for you. ``` guix shell -L dev r-littler -C -- r --help ``` What am I missing?
Advice on handling optional dependencies or packaging yp-tools
source (origin (method git-fetch) (uri (git-reference (url "https://github.com/epicsdeb/epics-base.git;) (commit "c595b238d04c7f5aaa739c9a6976487709d952bd"))) (file-name (git-file-name name version)) (sha256 (base32 "0knck7gw6m93881vm7hqf50wl9ccka3rqny71k7p88z59vhfdyri" (build-system gnu-build-system) (arguments (list #:phases #~(modify-phases %standard-phases (delete 'configure (native-inputs (list pkg-config perl)) (description #f) (home-page #f) (synopsis #f) (license #f)) ``` It seems to have a whole configuration directory instead of just a ./configure script. Another issue is that this package uses a custom license and I'm not sure whether it is a variant of one of the existing licenses or if there needs to be an additional entry in Guix licenses. That was a bit of a mouthful. Obviously, after packaging epics, libcom would also need to be packaged. I will stop there and see if anyone thinks they might be able to offer some advice. Thanks, Kyle
How to copy a file to the package /bin folder using the r-build-system?
Dear Guix, I want to package the littler R package. Unlike most R packages, this one provides an executable (a little r to complement the big R) that should go on the PATH rather than be tucked away into site-library where it cannot be used. Surprisingly, to me, when the command below fails ... ``` guix build -K -f littler.scm ``` ... the resulting temporary directory skips directly to the littler folder wheras the /gnu/store builds show the output inside of site-library. The /tmp output also looks different, lacking a bin/ folder like in the /gnu/store/*littlr* builds. How do I go about getting r out of site-library/littler/bin/r in there using the r-build-system? Here is what I have right now: ``` (use-modules (guix packages) (guix download) (gnu packages statistics) (gnu packages compression) (gnu packages icu4c) (guix gexp) (guix build-system r) (gnu packages cran) (gnu packages autotools) ((guix licenses) #:prefix license:)) (define-public r-littler (package (name "r-littler") (version "0.3.18") (source (origin (method url-fetch) (uri (cran-uri "littler" version)) (sha256 (base32 "1lp6a62g3yhzr4pv9kynibv7k9pd546w6hifs1aficyxbyg4dgqq" (properties `((upstream-name . "littler"))) (build-system r-build-system) (arguments (list #:phases #~(modify-phases %standard-phases (add-after 'install 'add-to-path (lambda* (#:key inputs outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out"))) ;;; TODO: this doesn't work! ;; copy site-library/littler/bin/r to bin/r (copy-file (string-append out "site-library/littler/src/r") (string-append out "/bin/r" (inputs (list icu4c)) (native-inputs (list r-simplermarkdown automake autoconf zlib)) (home-page "https://github.com/eddelbuettel/littler;) (synopsis "R at the Command-Line via 'r'") (description "This package provides a scripting and command-line front-end is provided by r (aka littler') as a lightweight binary wrapper around the GNU R language and environment for statistical computing and graphics. While R can be used in batch mode, the r binary adds full support for both shebang'-style scripting (i.e. using a hash-mark-exclamation-path expression as the first line in scripts) as well as command-line use in standard Unix pipelines. In other words, r provides the R language without the environment.") (license license:gpl2+))) ;; (packages->manifest (list r r-littler)) r-littler ``` I'm grateful for any assistance! Best Regards, Kyle
Re: Need some help packaging parts of a scientific workflow
Thanks, Philip! Your descriptions really made it click for me.
Might you give a small example of what you mean by adding an error phase? That
sounds like an important debugging strategy, but I can't quite grasp what it
would actually look like. I'm curious what kinds of data you are printing out.
On March 23, 2023 5:30:11 PM EDT, Philip McGrath
wrote:
>Hi Kyle,
>
>On Wed, Mar 22, 2023, at 5:29 PM, Kyle Andrews wrote:
>> Dear Guix,
>>
>> Part of my scientific workflow involves compiling a small Racket script
>> for a command line program into its executable and placing that on
>> PATH.
>
>I am always glad to hear of more people using Guix and Racket together!
>
>> I had bundled this script inside an R package which made sure it
>> got compiled and everything was correctly configured at library load
>> time.
>>
>
>Tangential to your actual question, I think this is not necessarily a terrible
>practice. There is not much difference between running `my-script` and running
>`racket -y "path/to/my-script.rkt"`, and, if you do that or `raco make` during
>the build process of your R package, you'll get compiled files properly. There
>are tradeoffs to weigh, including support for R users without Guix. But there
>are also good reasons to decide to separate the Racket script from the R
>library, so that's what I'll explain below.
>
>> From reading the documentation a lot, I think the actual compilation
>> step can be done using the "invoke" procedure like so:
>>
>> ```
>> (invoke "raco" "exe" "{package_location}/custom-shell-tool.rkt")
>> ```
>>
>> What I'm struggling with the most is understanding all the boilerplate
>> code I need to place around that fundamental call.
>>
>
>I'll start with a working example suitable for `guix build -f`, then answer
>your specific questions.
>
>```
>;; SPDX-License-Identifier: (CC0-1.0 OR (Apache-2.0 OR MIT))
>;; SPDX-FileCopyrightText: Philip McGrath
>
>(use-modules
> (gnu packages racket)
> (guix build-system copy)
> (guix gexp)
> (guix packages))
>
>(package
> (name "racket-hello")
> (version "1.0")
> (source (plain-file "hello.rkt"
> "#lang racket (displayln '|Hello from Racket!|)"))
> (inputs (list racket))
> (build-system copy-build-system)
> (arguments
> (list
>#:install-plan #~'(("hello" "bin/"))
>#:phases
>#~(modify-phases %standard-phases
>(add-before 'install 'build
> (lambda args
>(invoke "raco" "exe" "hello.rkt"))
> (home-page #f)
> (synopsis "Hello world in Racket")
> (description
> "This is a trivial example of using @code{raco exe} with Guix.")
> (license #f))
>```
>
>In fact this package would be a reasonable candidate for
>`trivial-build-system`, but I've stuck with `copy-build-system` because the
>boilerplate for `trivial-build-system` is very different than for all other
>build systems.
>
>Likewise, I'm assuming you know how you want to build your executable, but you
>might consider the `--launcher` flag for `raco exe` and an explicit call to
>`raco make`: in particular, it might take use less total disk space than an
>ELF executable.
>
>Note that you do have to use `racket`, not `racket-minimal`, because
>`racket-minimal` doesn't include the `raco exe` command.
>
>> (source
>> (local-file "package_location")) ; how to refer to local files?
>
>In general, `local-file` is the right mechanism; specifics depend on your
>situation, including how you are expecting your package definition to be used.
>For a single file, `(local-file "path/to/script.rkt")` is probably what you
>want, where the path is relative to the Guile file containing the `local-file`
>expression. For a directory, consider the `#:recursive?` and `#:select?`
>arguments.
>
>> (invoke "raco" "exe"
>> (string-append
>> #$package-folder ; how to refer to the build itself?
>> "custom-shell-tool.rkt"))
>
>The `unpack` phase from `gnu-build-system` handles this: if the package source
>is a directory, you're inside a copy of it; if it's a file, you're in a
>temporary directory containing it.
>
>>
>> I'm especially interested in figuring out how I can productively learn
>> to experiment productively with this stuff for myself.
>>
>
>Personally, I often insert a phase that calls `error` to stop the build,
>perhaps printing out interesting values first, and use `guix build
>--keep-failed` to explore the build environment.
>
>-Philip
Need some help packaging parts of a scientific workflow
Dear Guix,
Part of my scientific workflow involves compiling a small Racket script
for a command line program into its executable and placing that on
PATH. I had bundled this script inside an R package which made sure it
got compiled and everything was correctly configured at library load
time.
>From hanging around here for a bit, I have learned this practice is
probably a bad thing for reproducibility. I should separate my support
programs out from my R package rather than leaving them bundled in.
>From reading the documentation a lot, I think the actual compilation
step can be done using the "invoke" procedure like so:
```
(invoke "raco" "exe" "{package_location}/custom-shell-tool.rkt")
```
What I'm struggling with the most is understanding all the boilerplate
code I need to place around that fundamental call.
Below is a text-painting of the state of my misunderstanding:
```
(package
(name "custom-shell-tool")
(version "1")
(source
(local-file "package_location")) ; how to refer to local files?
(build-system copy-build-system)
(arguments
(list
#:phases
#~(modify-phases %standard-phases
(add-before 'install 'compile
(lambda _
(invoke "raco" "exe"
(string-append
#$package-folder ; how to refer to the build itself?
"custom-shell-tool.rkt"))
#:install-plan
#~'(("custom-shell-tool" "bin/")))
(home-page #f)
(synopsis
"A custom shell tool needed only for the niche workflows I write")
(description "This package is different from the ones in Guix.")
(license #f))
```
Would you please help me translate this text painting into a working
package?
I'm especially interested in figuring out how I can productively learn
to experiment productively with this stuff for myself.
Thanks for your help,
Kyle
Re: open config.scm with sudo and gedit or emacs
Hi Gottfried, I had some success editing things owned by the root user in emacs using Tramp. The syntax a bit confusing. You search for the file in the usual way in Emacs, but you delete all the text it fills in for you and instead replace it with: ``` /sudo:$USER@localhost:/etc/config.scm ``` You can replace $USER with your username. On March 11, 2023 12:05:01 PM EST, Sergiu Ivanov wrote: >Hi Gottfried, > >Gottfried [2023-03-11T11:33:33+0100]: >> >> because of my limited knowledge >> when opening my config.scm file with sudo >> I can do it only with nano > >The strategy I personally prefer is to edit a file in my home directory >and then sudo cp to /etc/config.scm. > >More concretely, I store my system configuration in >~/.config/guix/system-config.scm. I edit it with Emacs, as I would edit >any other normal file. When I am done editing, I do what essentially is > >sudo cp ~/.config/guix/system-config.scm /etc/config.scm > >I use Emacs's Dired mode + Tramp to actually do the copy, but that's >inessential to the strategy. > >One advantage of this approach is that you can version your local file >using Git or some other version control system (VCS). Even without VCS, >editing a local copy of your system configuration may prevent some >silly mistakes. > >- >Sergiu >
Re: Mysteries of channel configuration during system reconfigure
Julien Lepiller writes: > guix system describe lists channels used to build your system, but > they can be different from the ones currently known to guix. That seems consistent with what I have observed. > Does your /etc/channels.scm list the extra channels? At this point it does not. I "restored" a backup from my old computer into my home directory. Now I have several more channels than I had configured in generation one. Unfortunately, now my shepherd is broken just like on my old computer. I wish I understood how to experiment with e.g. virtual machines to better understand this process. However, there seems to be quite a large knowledge barrier. I also don't feel comfortable with my current capabilities exploring the Guix codebase to see what the relevant procedures are. There is a lot to learn! > "guix describe" will be more accurate about what channels your current > guix knows about. It's not clear to me what "your current guix" even is in my case. Does the latest pull define the current guix? On my old computer guix system describe shows a slightly older revision of Guix channels than guix describe. Meanwhile, the root user's guix describe shows just the one Guix channel with yet another commit. As a naive user, I'm understandably more scared that my computer will fail to boot if I upgrade, so I tend to run guix system reconfigure less frequently than guix pull. > If you type "type guix" and "which guix", they should agree it's > ~/.config/guix/current/bin/guix, not something else like > ~/.guix-profile or ~/.guix-home or even /run/current-system I had never heard of the type command! I noticed type and which give different results for "type cd" and "which cd". I also noticed that which --all guix shows two lines: the latter being /run/current-system. I have to admit I'm not still sure what general insight I should be gleaning from your statement, however it sounds like it is pretty neat. > If you reconfigure as the root user, you should pull as the root > user. If you use sudo, which is recommended, make sure that the above > works properly with sudo too. I'm curious to learn more about your rationale for this statement as I was successful at building a second generation only once I used the "sudo" path with my non-root user. Thanks for your help!
Re: Mysteries of channel configuration during system reconfigure
SeerLite writes: > `sudo guix system reconfigure` and any `guix package` command will (by > default) use the generation shown in `guix describe`. On first boot, > this generation _will_ be different from the one you had in the live > system. This is because the generation is saved at > ~/.config/guix/current on every `guix pull` and that file will be gone > together with the live system. That behavior doesn't make sense to me, but I have accepted it for now. As I tried to explain in my question, I *had* performed a guix pull -C ... before attempting to reconfigure the system. However, I think I only tried to do that from the /root user. Since then I have tried to pull from the sudo. This did in fact allow `guix system reconfigure` to run. > You have two options: > > 1. Get the channels you want correctly set up in > ~/.config/guix/channels.scm and run `guix pull` with your user in the > running system. IIRC this takes a while because it'll download the > whole Guix checkout again (the one used to install would have > disappeared along with the rest of the live system). > 2. Run guix pull -C /run/current-system/channels.scm. This will pull > the exact generation used to build the system. This will also take > time. This /run/current-system folder is interesting. When I searched the Info pages I saw also that it is related to files stored under /var/guix. Unfortunately, I was not able to glean the overarching rationale for these directories. > Note that you could also copy /run/current-system/channels.scm to > ~/.config/guix/channels.scm but you have to be careful remove the > commit lines, otherwise all your `guix pull`s will pull the exact same > commits and you'll stay on an outdated system. I appreciate this tip. > Maybe it could be clarified in the manual that another `guix pull` is > needed after the first boot. Or maybe the installation could be > optimized so that the checkout is copied from the live system to the > installed system. I think it needs to be clarified that this process has to be done from a *normal* user account in the *wheel* group. It seems the root user cannot perform this step. >> When I run the following command: >> ``` >> guix system describe >> ``` >> The addition channel gets listed. How can it be listed yet be >> unknown to >> the `guix system reconfigure` command? > > Because it was indeed the channel and commit the system was built > from. It has nothing to do with your "current powers". That all > depends on what generation of Guix you're using AKA what comes up in > `guix describe` This unnecessary tie in between the system state and a particular user's software profile was really tripping me up. > I hope my explanation was helpful! Thanks!
Mysteries of channel configuration during system reconfigure
Dear Guix, I am trying (and failing) to setup a new computer with Guix. I managed to get through the installation process with a configuration that boots into GNOME. However, the keyboard is messed up (I made a typo) and I don't yet have the desktop environment up and running I actually feel productive using. GNOME places too many extraneous demands on my attention. There is a lot going on and I find all the beeping unsettling. So I am typing this email on my old computer with Guix. One of the selling points in Guix marketing for me is that the system configuration should be self contained within /etc/config.scm and channels.scm. However, this appears to not be the case. There seems a third element hidden away which prevents me from running: ``` guix system reconfigure /etc/config.scm ``` This command errors out: ``` failed to load '/etc/config.scm' ... no code for module ... ``` At the moment since I am still very early in setting up my new computer, I have to type everything so I'm not going to go into more detail than that. Suffice to say it doesn't see the modules I need from the extra channel. It did see them during the installation otherwise my computer would be in a far less usable state than it is. When I run the following command: ``` guix system describe ``` The addition channel gets listed. How can it be listed yet be unknown to the `guix system reconfigure` command? During the installation of my new computer I used guix pull -C /etc/channels.scm. I was struggling with the official documentation, so this was kind of an improvisation. Could doing this nonstandard action have lead to this nonstandard state? Can it be fixed? I tried running the commands with the root user and with prefixing sudo. Neither variat produces the desired result: a new configuration with the correct keymap and my next steps towards setting up my desktop environment. Thanks in advance for your help! Cheers, Kyle
Re: Using an alternative python to build python modules
Simon Tournier writes: > (I let aside the inferior part that you do not need, IMHO.) I hope you are right. I will keep thinking about it and will try to revisit some of my assumptions. > The computational environment you create with Conda is totally > inconsistent in regard to the Python version label. The Conda > resolver works using the version label. Consider this scenario: > > A library X version x.y builds with Python interpreter version p.q and > you are interested by library A depending on library X version x.y and > also by some Python libraries and the Python interpreter version b.d, > then library X is not rebuilt with Python interpreter version b.d. > Somehow, Conda exploits some binary compatibility, roughly what Guix > names grafts. :-) > > Other said, Conda is not building and then serving all the matrix of > possible combinations. Somehow Conda cheats when Guix not. Well, I am > not saying that cheating is not practical, instead I think that by using > this kind of cheat, the reproducibility becomes harder by design because > it lacks a fine control of the complete DAG. That makes sense. However, I see scientists using conda as a way to get up and running quickly with any kind of development environment at all for the packages that interest them. I just wish there was a low complexity path to go from that chaos to a reproducible specification once the scientist has established their proof of concept was a success. That said, I am very impressed by how much complex scientific software is already available in Guix. For example, during this email I was going to make an example of rdkit only to find that it was already packaged!. I had struggled for a long time to get that installed on centos7 outside of a conda environment before I became comfortable with them. Of course, there are still some big gaps in the chemistry packages, especially for widely used for Density Functional Theory-based calculations like ABINIT and Quantum Espresso. I suppose it should only take one person rolling up their sleeves. => https://www.abinit.org/ => https://www.quantum-espresso.org/ > This lead to the other point… > >> I'm just wishing that this >> approach will work in the near future. So, please don't let anyone >> include it yet :) > > …rewrite on the fly the DAG is cheap with Guix but build it is not. :-) That makes sense. > I agree that a similar feature as Conda where you can specify the Python > version and a list of Python library, yeah this feature would help > people from Conda in convincing them that Guix is more suitable. > However, for most of the scientific applications I know, the version of > Python is not really something pertinent – other said, that’s a fun > feature but useless in practise, IMHO, just a dumb collective practise > inherited from the poor Python ecosystem, and for sure it does not help > for reproducing the computational environment (end of my grumbles :-)). Again, I hope you are right. I really appreciate all your guidance.
Re: Using an alternative python to build python modules
Kyle Andrews writes: > Kyle Andrews writes: > >> There seems to be some secret Guile incantation I am overlooking. Could >> you give me a hint of what this could be? > > Tobias pointed out to me that the Guile developers could be to blame > here. They appear a bit too preoccupied with prematurely optimizing the > speed of code with the result that it has already been made inaccessible > before users have a fighting chance to interactively study it to > understand how it works. > > The workflow described in the Guile manual seems like it would be > perfect. It suggests I should be able to just modify the source code and > reload it into the running environment. Unfortunately, I don't know how > to associate my running environment via the Guix REPL with my git > checkout. Reading a few hours later I apologize that I came off a bit harshly. I am grateful to guile writers for sharing their work. I appreciate that it is a challenging task making a computing system which is approachable while also being fast when it needs to be. There will always be some room left for additional improvement. I am starting to feel intense pressure to move on to my next project. My colleagues just don't get it. I do, and I really really want to show them that reproducible research can be done without much trouble even for scientific workflows mixing R and python packages and scripts, which are probably the most complex workflows "in the wild" in my neck of the woods. So, even if they don't get it yet, they might in a few months when their projects break as the software ecosystem moves on to the next fad. It always does. >From a broader perspective, sometimes the only way for people to get things is if they see a lot of pressure from other peers in their field to do it. If it is perceived as a "go do" and not as an arduous journey with a realistic prospect of failure, then it will get done. I want to make sure it's the former. To that end, I want there to be an entry in the cookbook for this. I just sent a patch outlining my ideas for what the scope should be. Of course, since I can't actually figure it out yet, it's more of a draft at present. Honestly, I couldn't get my poor ancient laptop to even finish compiling the inferior - much less try using that inferior with your package-with-explicit-python. I'm just wishing that this approach will work in the near future. So, please don't let anyone include it yet :)
Re: Using an alternative python to build python modules
Kyle Andrews writes: > There seems to be some secret Guile incantation I am overlooking. Could > you give me a hint of what this could be? Tobias pointed out to me that the Guile developers could be to blame here. They appear a bit too preoccupied with prematurely optimizing the speed of code with the result that it has already been made inaccessible before users have a fighting chance to interactively study it to understand how it works. The workflow described in the Guile manual seems like it would be perfect. It suggests I should be able to just modify the source code and reload it into the running environment. Unfortunately, I don't know how to associate my running environment via the Guix REPL with my git checkout.
Re: Using an alternative python to build python modules
Simon Tournier writes: > > You might be interested by the unexported procedure from (guix > build-system python) Thanks, Simon. Wojtek already suggested this procedure to me and I have been trying to understand it. Unfortunately, I am stuck earlier than I originally thought. I can't figure out how to call it at all. I was hoping it could be accessed via th `@@` procedure which I could think of as analogous to the `:::` procedure in R which supposedly performs a similar action. ``` repl> (define pwep (@@ (guix build-system python) package-with-explicit-python)) ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: package-with-explicit-python: unbound variable ``` I am starting the REPL via the `guix repl --listen=tcp:37146` command and am able to execute `,use (guix build python)` inside of the guile running in geiser. There seems to be some secret Guile incantation I am overlooking. Could you give me a hint of what this could be? Thanks, Kyle
Re: Using an alternative python to build python modules
Dear Edouard and Wojtek,
Thank you very much for your generous suggestions!
I would like to give you an update to share the state of my still
incomplete understanding after thinking about them.
With regards to this sort of thing:
```
(package-input-rewriting/spec
`(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)
```
I did not try this yet because I don't understand it yet. My confusion
stems from the fact that python is not in the transitive inputs of any
python package.
```
(use-modules (gnu packages) (gnu packages python))
,pretty-print (package-transitive-inputs python)
```
How could modifying the graph have any effect?
Instead I tried to go down the package-with-python2 route since it APTED
claimed it was tested on python 2.7. Unfortunately, I ran into many
other errors where different python packages in the transitive inputs of
python-numpy failed because they were using various python 3 syntaxes.
Now I am trying to figure out how to best go about trying with python 3
instead. One issue I am not sure how to get around is the
python?-variant property convention. It is not clear to me how to write
one for an inferior python for use with
`package-with-explicit-python'.
I will keep you posted if I make any breakthroughs. I'm really eager to
be able to replace conda with guix.
Best Regards,
Kyle
Edouard Klein writes:
> As an example in this line of thought, a long time ago I submitted a
> patch (since then reverted as it broke a lot of things) to use an
> obsolete version of a python module, which was the only one that worked
> with a specific module that hadn't updated its dependencies:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=32ba87c14fd5e5b54d95211cd9a159d568ce7c67
>
> Look at the following lines:
>
> #+begin_src scheme
> (define-public prompt-toolkit-2-instead-of-prompt-toolkit
> (package-input-rewriting/spec
>`(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)
> #+end_src
>
> If instead of replacing "python-prompt-toolkit" with
> python-prompt-toolkit-2, you could replace "python" with the version of
> python you want to use, package-input-rewriting would then handle the
> work of changing the python package anywhere it appears in any
> dependency of your manifest.
>
> You can then end your manifest with
> (python-3.6-instead-of-python python-apted)
>
> Cheers,
>
> Edouard.
>
>
> Wojtek Kosior via writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi Kyle,
>>
>> Have you looked at the (package-input-rewriting) procedure described
>> towards the bottom of "Defining Package Variants"[1]?
>>
>> You might also like to look at the not-exported
>> (package-with-explicit-python) proc defined in
>> guix/build-system/python.scm[2]. It is used to produce python2 variants
>> of packages but I suppose it would also work for swapping the minor
>> versions of python3.
>>
>> Good luck with your task :)
>>
>> Wojtek
>>
>> [1] https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html
>> [2]
>> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/python.scm?id=b544f460989a6189af111bb3ff6752cabdf23abc#n82
>>
>> -- (sig_start)
>> website: https://koszko.org/koszko.html
>> PGP: https://koszko.org/key.gpg
>> fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A
>>
>> ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷
>> c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
>> ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ?
>> U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
>> -- (sig_end)
>>
>>
>> On Fri, 17 Feb 2023 21:27:39 +
>> Kyle Andrews wrote:
>>
>>> Dear Guix,
>>>
>>> I want to use the python-apted package in my manifest. That package is
>>> not in Guix, but can readily be fetched from:
>>>
>>> ```
>>> guix import pypi APTED > python-apted.scm
>>> ```
>>>
>>> I just had to prefix the following modules to turn that into a package
>>> definition as well as a manifest.
>>>
>>> ```
>>> (use-modules (guix packages)
>>> (guix download)
>>> (guix licenses)
>>> (guix profiles)
>>> (gnu packages)
>>> (guix build-system python))
>>> ```
>>>
>>> During my original testing of my scientific workflow I discovered that
>>> there was a bug introduced to the APTED package which was caused by a
>>> change in how python worked under the hood. As a result, the APTED
>>> package only advertises compatibility with python versions less than
>>&g
Using an alternative python to build python modules
Dear Guix, I want to use the python-apted package in my manifest. That package is not in Guix, but can readily be fetched from: ``` guix import pypi APTED > python-apted.scm ``` I just had to prefix the following modules to turn that into a package definition as well as a manifest. ``` (use-modules (guix packages) (guix download) (guix licenses) (guix profiles) (gnu packages) (guix build-system python)) ``` During my original testing of my scientific workflow I discovered that there was a bug introduced to the APTED package which was caused by a change in how python worked under the hood. As a result, the APTED package only advertises compatibility with python versions less than 3.7. So, I would like to use python 3.6 to be on the safe side. I also want to include 60+ other packages in my manifest which are "current" with the Guix repository and included within it. For situations like this it would be really convenient if it were possible to pass a version of python to python-build-system. Then, I hope all I would have to do is pass another another defined variant of the python package (e.g. called python-3.6) into that build-system argument. For example: ``` (build-system python-build-system #:python python-3.6) ``` That would be quite convenient and in line with the level of complexity I was faced with when I took the conda approach before trying to use Guix. Unfortunately, this functionality doesn't seem to be provided out of box and I am seeking help in the hopes that there is an easy way to do it. Am I thinking about this right? Thanks, Kyle P.S. APTED claims to also be able to run on top of python-2.7 so maybe that fact could be used to simplify this specific issue. I just wanted to discuss the general problem first because I really want Guix to gain broad traction within the scientific community. P.P.S. Here is a pretend manifest where I would love guidance on how to make python-apted get built in the context of python-2.7 or ideally python-3.6 even though the latest version of python is python-3.9 (where APTED doesn't always work). ``` (use-modules (guix packages) (guix download) (guix licenses) (guix profiles) (gnu packages) (guix build-system python)) (define-public python-apted (package (name "python-apted") (version "1.0.3") (source (origin (method url-fetch) (uri (pypi-uri "apted" version)) (sha256 (base32 "1sawf6s5c64fgnliwy5w5yxliq2fc215m6alisl7yiflwa0m3ymy" (build-system python-build-system) (arguments '(#:tests? #f)) (home-page "https://github.com/JoaoFelipe/apted;) (synopsis "APTED algorithm for the Tree Edit Distance") (description "APTED algorithm for the Tree Edit Distance") (license expat))) (concatenate-manifests (list (specifications->manifest (list "r" "r-dplyr" "r-reticulate")) (packages->manifest (list python-apted ```
Re: guix pack isolation
Simon Tournier writes: > About squashfs (Singularity container), you can try: > > guix pack -f squashfs python python-numpy bash-minimal -S /bin=bin > > which will produce a compressed squashfs that you then import with > Singularity. This is pretty much what I had tried minus the `-S /bin=bin' part which I don't understand. Thankfully, reading the manual informs me that: ``` ‘guix pack -f squashfs’ always implies ‘-S /bin=bin’ ``` So, atleast I don't have to understand it yet. > I do not have Singularity at hand, let demo with Docker > which is very similar. Too bad! My system admistrators are against running Docker on the cluster. The "relocatable" option didn't seem relevant to me since it wouldn't apply any file system isolation. > $ docker run -ti python-python-numpy-bash:latest python3 The arguments in this command atleast gave me an idea. Maybe I am just ignorant about how singularity works? I didn't know what -ti could possibly mean without first looking them up. Maybe I just need to add some additional arguments to singularity exec? Arguments in the manual which look particularly interesting to me are: --contain --containall --bind=/path/to/shared/file/system/location --no-home --workdir => https://docs.sylabs.io/guides/3.1/user-guide/cli/singularity_exec.html If you or anyone else have have any tips on how to best mimic the behavior of the analogous `guix shell' command with an `singularity exec' call I would use if guix was available, I am all ears. Thanks, Kyle
Re: attempt to create a profile
Simon Tournier writes: > I am using multiple profiles and I barely hit collisions. Given one > specific revision of Guix, collisions should not be possible – it means > something is wrong somewhere with package definition; although, maybe it > is impossible to avoid some collisions with large number of packages, > anyway. :-) > > Most of the time, collisions happen when the profile are coming from > different revision of Guix. And try to combine several profiles from > different revision is, IMHO, some source of troubles impossible to > solve. I had in mind my troubles where mixing multiple profiles gave me headaches finding documentation. For example, I have one profile for emacs related packages and one profile for routine R related packages. I still cannot see the info documentation for the info related packages unless I go about creating a dedicated environment. See (nota)bug #55709. Similarly, I am currently trying to work through an issue with my email configuration. Frustratingly many man page references don't go anywhere or just don't exist because there is confusion about where to look for this. That is quite confusing behavior for new users. => https://issues.guix.gnu.org/55709 In my case I am hopeful there must be some way to extend the man and info paths when multiple profiles are activated, and maybe that would resolve my particular issue. I would love a suggestion to be placed in the cookbook about this.
Re: attempt to create a profile
This makes a lot more sense to me than sequentially sourcing $SOME/etc/profile files as currently mentioned in the cookbook. Thanks for sharing! The fact that guix package supports multiple -p arguments got me excited enough to try out a similar command with guix shell. ``` guix shell -p $HOME/my/profile/emacs -p $HOME/my/profile/rstats --container guix shell -p $HOME/my/profile/rstats -p $HOME/my/profile/emacs --container ``` Both commands ran for me. However, the first environment didn't provide Emacs. The second did provide even though it didn't run because there was no X11 available and so it errored out. It seems that multiple -p arguments to guix shell doesn't really work like I would hope. Ideally it would produce the same sort of system environment as is produced by eval'ing `guix package --search-paths` with multiple profiles. 宋文武 writes: > Kyle Andrews writes: > >> In my case I am hopeful there must be some way to extend the man and info >> paths when multiple profiles are activated, and maybe that would resolve >> my particular issue. I would love a suggestion to be placed in the >> cookbook about this. > > Hello, you can merge search-paths from multiple profiles with: > > --8<---cut here---start->8--- > # Honor system-wide environment variables > source /etc/profile > > # Merge search-paths from multiple profiles, the order matters. > eval "$(guix package --search-paths \ > -p $HOME/.config/guix/profiles/a \ > -p $HOME/.config/guix/profiles/b \ > -p $HOME/.config/guix/current \ > -p $HOME/.guix-profile \ > -p /run/current-system/profile)" > > # Prepend setuid programs. > export PATH=/run/setuid-programs:$PATH > --8<---cut here---end--->8--- > > As discussed in #20255 and #61358.
guix pack isolation
Dear Guix, I am wondering how I can/should go about isolating containers created using `guix pack`. Right now they are inheriting configurations from my personal user folder. My system administrators are still quite skeptical about installing Guix, but they have made it convenient to submit singularity container jobs via SLURM. Otherwise, I would prefer to use `guix shell` because it seems to make it easy to create a fully isolated container. Is this a case where the best idea is to make a container first with `guix shell` and then create the pack inside of that container? Are there other approaches I should be trying? Thanks, Kyle
Re: attempt to create a profile
Simon Tournier writes: > Hi, > > On Wed, 28 Dec 2022 at 15:09, Gottfried wrote: > >> Which commands can I use to enter and close my new profile? > > To enter, you just need to ’source path/to/some-profile/etc/profile’. > > However, you cannot “deactivacte“; unset the environment variables and > restore the previous ones. Maybe, the easiest is: > >bash >source path/to/some-profile/etc/profile >…do some stuff… >exit > > Instead, you can run > > guix shell -p path/to/some-profile/etc/profile > …do some stuff… > exit > > which does the same thing as above. > > >> ...and also at start up that I can choose which profile to open? > > What do you mean by “choose”? > > >> guix package --profile=/home/gfp/projects/musescore-3.6.2.guix-profile >> >> and beforehand I created the directory "projects" and >> "Musescore-3.6.2" in the directory "projects" >> in my /home/gfp/ directory >> (I did that because it said: " >> file or directory was not found" >> >> but it didn't work. >> "warning: nothing to do" was the answer. >> >> Where was my mistake? > > It is missing the option -i (or -m). For instance, > > guix package -i musescore -p projects/musescore-3.6.2.guix-profile > > > Cheers, > simon Thank you Gottfried for asking this question and thank you Simon for providing these examples. I didn't realize I could use guix shell with an already installed and named profile. This suggests a follow-up question: Is it possible to use guix shell to activate multiple existing profiles in a particular order to explicitly test for incompatibilities when combining profiles? I have been using multiple existing profiles mainly in the hope it would spare my poor underpowered and aging laptop the burden of having to do a long system update ordeal all at once. This seemed to me especially useful when there would be conflicts which would require uninstalling something and then redoing a lot of work. However, it has not worked out as well as I could have hoped. For one thing, I have found Emacs to be quite confused as to whether some documentation or command completions are available or not. For another thing, I found that if there was an explicitly recognized problem, it would usually be related to an issue with package definitions on my personal channel or in the main Guix channel and I would then have to run guix pull. After do that operation, I believed I would have to update everything again anyway. I had just read a discussion on this forum where it was mentioned that mixing guix executables from different guix generations would be asking for trouble and that the only way to make sure things would work correctly was to keep ~/.config/guix/current/bin~ at the front of our PATH. Maybe this is an example where this issue is relevant? I have had many issues which I have reported but these have all turned out to be unreproducible in a single dedicated profile. In conclusion, I'm a bit surprised that activating multiple profiles at once is so easily found and recommended in the cookbook. It seems to me like there are many underemphasized gotchas with respect to reproducibility and usability which come from it and as far as I can tell, the main developers of Guix do not use it that way. If it is going to be recommended as atleast a possibility for advanced users, then it would be nice to be able to formally test that usage through ~guix shell~.
Re: guix running advice: correct?
Julien Lepiller writes: > Hi Andy, > > I'm the author of this advice. I think it's still correct. It's mostly > sanity checks that you would run to ensure you can get packages from > this channel. Most of it is scattered around the manual, mostly in the > manual installation documentation. > > ~/.config/guix/current is where your new guix (the one you pulled with > the channel) is installed. If it's not first in $PATH, you're at risk > that some other guix will be used instead. > > hash is a command that removes an entry from the shell's cache. If > this is your first pull, the guix you used comes from another location > that is recorded by the shell, so you have to clear the cache to use > the newly pulled guix. If your guix already comes from the correct > location, it'll be useless but it won't hurt. > > HTH! > > Le 3 janvier 2023 06:31:25 GMT+01:00, Andy Tai a écrit : >>Hi, from this page >>https://framagit.org/tyreunom/guix-android/-/blob/master/README.md >> >>Important checks >>Make sure your guix environment is set up properly. You need to have >>~/.config/guix/current as the first item in your $PATH or you're going >>to run into troubles. Additionally, after running guix pull, make sure you >>run hash guix in any open terminal to make sure bash's cache is cleared of >>the old guix binary location. >> >>I wonder if the above is correct, as I do not recall seeing anything in >>Guix doc mentioning such advice or something to that effect (unless I >>missed it) Interesting. I too had never heard about this PATH recommendation and it seems contrary to some advice I do remember given in the cookbook about working with multiple profiles. For me, activating an extra profile places it's /bin and /sbin directories at the beginning of my PATH. I can only find ~/.config/guix/current/bin burried quite deep near the end. Do you have any advice on how regular end users could follow your recommendation? My naive hope would be that end users wouldn't have to think about it. Ideally if its that dangerous then updating the path would happen automatically when sourcing the etc/profile file inside a profile directory. Should the Guix Profiles in Practice section of the cookbook be updated to reflect this?
Re: Fwd: PinePhone Pro & Guix
I'm very excited about this! Thank you so much for your efforts! Having a modified SXMO using Emacs wherever possible running on a Guix powered PinePhone would be my dream come true. "jgart" writes: > Sorry! I forgot to change the Subject for the digest. I hope this works... > > Forwarded message --- > From: "jgart" > To: help-guix@gnu.org > CC: phod...@protonmail.com, gnu...@cyberdimension.org, > forevercomput...@gmail.com, fah...@gmail.com > Sent: December 28, 2022 10:51 PM > Subject: Re: Help-Guix Digest, Vol 85, Issue 50 > >>> Hi all, I'm trying to write a guix code that will generate images >>> for pinephone pro. Can anyone share the config .scm file if anyone >>> has done it? Thanks. > > Hi Guixers, > > I would ask fare, I've cc'ed fare, who's using Pinephone Pro with Guix System. > > https://github.com/fare/guixcfg/blob/313e6d5e619b7ed551154eda29957b60d0221b7e/deepness.scm#L1 > > I started packaging sxmo stuff for Guix a while back. > > We have a few things here: > > https://packages.guix.gnu.org/packages/sxmo-st/0.8.4.1 > > There's some sxmo stuff in guixrus. I'll upstream them this week: > > https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L214 > https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L233 > https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L255 > > all best, > > jgart > > https://whereis.みんな
Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e
zimoun writes: > I fetch from yhetil.org (Git) and then convert to MailDir because I use > Notmuch as indexer (and reader :-)). And I do not want to duplicate the > storage. Therefore, after fetching and converting, the Git repo is > garbage collected, > > --8<---cut here---start->8--- > echo $head > $gitdir/shallow > $git gc --quiet --prune=all > --8<---cut here---end--->8--- > > https://gitlab.com/zimoun/my-conf/-/blob/master/.local/bin/sync-public-inboxes.sh#L94-99 > > For instance, the current size of guix-patches on my machine is 152K > compared to the complete guix-patches Git repo of 277M. Nice. Maintaining a shallow clone certainly makes sense. > Well, I have not investigated much with ’grokmirror’ and > ’public-inbox-fetch’ and maybe it would also work smoothly with the same > trick; avoiding many manual plumbing. I haven't used it myself (unsurprisingly I have an interest in keeping yhetil.org's inboxes replicated on my local machine), but I think you can keep grokmirror clones shallow by hooking up its grok-pi-piper to the post-update hook. Here's a relevant bit from grokmirror's docs: --8<---cut here---start->8--- [DEFAULT] # To start piping public-inbox messages into your inbox, simply # install procmail and add the following line to your ~/.procmailrc: # DEFAULT=$HOME/Maildir/ # You can now read your mail with "mutt -f ~/Maildir/" pipe = /usr/bin/procmail # Once you've successfully piped the messages, you generally # don't need them any more. If you set shallow = yes, then # the repository will be configured as "shallow" and all succesffully # processed messages will be pruned from the repo. # This will greatly reduce disk space usage, especially on large archives. # You can always get any number of them back, e.g. by running: # git fetch _grokmirror master --deepen 100 shallow = yes --8<---cut here---end--->8---
Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e
On 12/05/22 09:45:41 +0100, zimoun wrote:
> Personally, I use “git clone” from a public-inbox instance [1].
>
> git clone --mirror https://yhetil.org/guix-patches/1 \
> guix-patches/git/1.git
>
> where ’1’ can be also replace by ’0’ for the very old ones.
In the case of guix-patches, there's not a 0.git. I started it at 1.git
to leave open the possibility of adding 0.git with the messages I was
missing from the beginning of the list's history (from Feb 12, 2017 to
March 27, 2017). I'm not sure I'm ever going to do so at this point
and, even if I did, reserving 0.git doesn't have much advantage over
just adding the old messages on top of the existing epoch, so I probably
should have just started it at 0.git.
> Then the conversion from Git commit to maildir is done by a small script
> [2], where all the job reads:
>
> --8<---cut here---start->8---
> # Extract the message from each commit in the range and store it
> # in the Maildir for notmuch to consume.
> $git rev-list $range | while read sha; do
> # : fatal: path 'm' does not exist in
> # and it can also raise issues with notmuch, as:
> # Note: Ignoring non-mail file: $maildir/new/$sha
A tree can either have m or d ("deleted" messages):
https://public-inbox.org/public-inbox-v2-format.html
So you should be able to avoid this error by skipping d's.
> $git show $sha:m > $maildir/new/$sha
> done
> --8<---cut here---end--->8---
>
> (Maybe better could be done and more robust are around.)
No need to change what works, of course, but
https://public-inbox.org/clients.html mentions l2md and impibe as tools
for converting public-inbox archives to Maildir.
* https://git.kernel.org/pub/scm/linux/kernel/git/dborkman/l2md.git
* https://leahneukirchen.org/dotfiles/bin/impibe
In terms of cloning archives, plain cloning and fetching with Git is
fine, but, if you have public-inbox locally, you can instead use
public-inbox-clone and public-inbox-fetch, which will handle some
details for you (e.g, cloning underlying epochs and recognizing that new
epochs have been added):
$ public-inbox-clone https://yhetil.org/guix-patches
Another option for fetching that's nice if you're mirror multiple repos
is grokmirror:
* https://git.kernel.org/pub/scm/utils/grokmirror/grokmirror.git/about/
* example setup for guix:
https://yhetil.org/guix-patches/878scww903@kyleam.com/
Both grokmirror and public-inbox-clone/fetch make use of the manifests
that are published for public-inbox archives:
$ curl -fSsL https://yhetil.org/manifest.js.gz | gzip -d | \
jq -r 'keys | .[] | select(contains("guix"))'
/guix-bugs/git/0.git
/guix-devel/git/0.git
/guix-patches/git/1.git
/guix-science/git/0.git
/guix-user/git/0.git
Then there's of course also public-inbox's lei (local email interface).
I won't get into that, but, for anyone interested, here are messages
where I've given some examples:
* https://yhetil.org/emacs-devel/87wnh22w7o@kyleam.com
* https://yhetil.org/guix-devel/87y1zcljq3@kyleam.com
Re: Exporting patches without prerequisite patch id
kiasoc5 writes: > I have some commits on my local guix repo like this: > > (master) HEAD -> A -> B -> C > > When I do `git format-patch -3 --base=auto` I get prerequisite patch > ids in some of the patches. But I want to each patch to depend only on > HEAD. In other words I want to export patches like so: > > HEAD -> A > HEAD -> B > HEAD -> C > > How do I do this? `git-format-patch --base` doesn't support lying about the state by leaving out the prerequisite patch IDs, as far as I know. If you have a string of commits that you want to post as single patches where only base-commit is listed, the approach would be to split each of those off into separate, independent branches on top of the base commit. a / base - b \ c
Re: how can I find the terminal output
I have never used the command script, but I thought you might benefit from installing the tldr utility: whose name is short for "too long didn't read" It gives examples instead of all the unwanted details that man pages throw at you first even though they don't make a lick of sense without the right background knowledge and perspective. There are many implementations, but I like tealdeer. guix install tealdeer Then type: tldr script That produces a few examples for me. On May 7, 2022 11:42:28 AM EDT, zimoun wrote: >Hi, > >On Fri, 06 May 2022 at 20:18, Gottfried wrote: > >> How do I have to use "script"? > >Only you can answer. ;-) The question is: what is your needs? Do you >need to record and track the output for each command? > >Personally, I only do that for the very rare cases when I am demoing. >Otherwise, I only redirect the output of a command to a file using ’>’. > > >> Do I have to enter "script" in the terminal before I start other >> commands, so that it will start to log my shell? > >Yes. > >> or can I, after a command with output, enter "script" and it will log my >> output in a file typescript? > >No. > >However, you can redo the same command to append the output to a >previous ’typescript’. For instance, in your terminal: > >ls >script >ls >exit >pwd >script -a >cd /tmp/ >ls >pwd >exit > >Then the file ’typescript’ contains the session (input and output) >between ’script’ and ’exit’ (included). Therefore, the first ’pwd’ will >be not recorded. > > > >> I tried several times, but it didn't work. It didn't record anything, >> when I opened the file typescript. >> >> So can you show me an example how to use it? >> What Options are useful? > >Well, have you read the manpage of ’script’? Type ’man script’. > > >Hope that helps, >simon >
Re: Seeking suggestions for fixing the R gpg package
Thanks so much, that worked! It was not at all clear to me that such a dependency existed or that if it did it would not already be encapsulated by GPGME itself. On May 6, 2022 4:56:00 AM EDT, zimoun wrote: >Hi, > >On Thu, 05 May 2022 at 13:37, Kyle Andrews wrote: > >> (propagated-inputs (list r-askpass r-curl)) >> (native-inputs (list pkg-config r-knitr gpgme)) > >[...] > >> 8<- >> Error: package or namespace load failed for ‘gpg’: > >I have looked at all the details, but ’gpg’ seems required, no? > >Maybe try to add it as native-inputs. > > >Cheers, >simon
Seeking suggestions for fixing the R gpg package
Hi, I want to use the R package gpg which provides bindings to GPGME from within Guix. Most of the time packaging R things is really easy thanks to the handy `guix import cran' command. Unfortunately, something is breaking with GPGME which is making this not work as I expected. Unfortunately, I don't really have any experience with dealing with this problem. Can anyone suggest how they would go about debugging this? I opened a bug report on the R gpg, but I don't really know if that's the appropriate place. There I included the Guix build error report. The key problem seems to be that > error: GPGME setting OpenPGP path/home error: Invalid crypto engine https://github.com/jeroen/gpg/issues/14 My non-working package code is below: 8<- (use-modules (guix packages) (guix download) (guix build-system r) (guix git-download) ((guix licenses) #:prefix license:) (gnu packages pkg-config) (gnu packages compression) (gnu packages gnupg) (gnu packages maths) (gnu packages cran) (gnu packages statistics) (gnu packages gcc)) (define-public r-gpg (package (name "r-gpg") (version "1.2.6") (source (origin (method url-fetch) (uri (cran-uri "gpg" version)) (sha256 (base32 "17rvi3qff2kanqr3g20dzhn48bfh5sv57g0wsamndzcif7rhjhby" (properties `((upstream-name . "gpg"))) (build-system r-build-system) (propagated-inputs (list r-askpass r-curl)) (native-inputs (list pkg-config r-knitr gpgme)) (home-page "https://github.com/jeroen/gpg;) (synopsis "GNU Privacy Guard for R") (description "Bindings to GnuPG for working with OpenGPG (RFC4880) cryptographic methods. Includes utilities for public key encryption, creating and verifying digital signatures, and managing your local keyring. Some functionality depends on the version of GnuPG that is installed on the system. On Windows this package can be used together with 'GPG4Win' which provides a GUI for managing keys and entering passphrases.") (license license:expat))) ->8 The build of the R package seemed to go fine. It only fails when it tries to test that the package can be loaded into an R session. 8<- Using PKG_CFLAGS=-I/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/include -I/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/include -I/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/include Using PKG_LIBS=-L/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/lib -lgpgme -L/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/lib -lassuan -L/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/lib -lgpg-error ** libs gcc -I"/gnu/store/fm6grlr7rvb176ls6kkamadim64w3jli-r-minimal-4.1.3/lib/R/include" -DNDEBUG -I/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/include -I/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/include -I/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/include -I/usr/local/include -fpic -g -O2 -c encrypt.c -o encrypt.o gcc -I"/gnu/store/fm6grlr7rvb176ls6kkamadim64w3jli-r-minimal-4.1.3/lib/R/include" -DNDEBUG -I/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/include -I/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/include -I/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/include -I/usr/local/include -fpic -g -O2 -c engine.c -o engine.o gcc -I"/gnu/store/fm6grlr7rvb176ls6kkamadim64w3jli-r-minimal-4.1.3/lib/R/include" -DNDEBUG -I/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/include -I/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/include -I/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/include -I/usr/local/include -fpic -g -O2 -c keys.c -o keys.o gcc -I"/gnu/store/fm6grlr7rvb176ls6kkamadim64w3jli-r-minimal-4.1.3/lib/R/include" -DNDEBUG -I/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/include -I/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/include -I/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/include -I/usr/local/include -fpic -g -O2 -c keysig.c -o keysig.o gcc -I"/gnu/store/fm6grlr7rvb176ls6kkamadim64w3jli-r-minimal-4.1.3/lib/R/include" -DNDEBUG -I/gnu/store/33x095pip87pxcn23cz8k96jq6bka51s-gpgme-1.15.1/include -I/gnu/store/imh6q627pj1jpcxdzjpvdwmlwh8kl5kw-libassuan-2.5.5/include -I/gnu/store/pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42/include -I/usr/local/include -fpic -g -O2 -c options.c -o options.o gcc -I"/gnu/store/fm6grlr7rvb176ls6kkamadim64w3jli-r-minimal-4.1.3/lib/R/include" -DNDEBUG
How to offload builds only when some of the offload build servers are available
Dear Guix, How can I configure the offload functionality to check whether the build machines specifiec in ~/etc/guix/machines.scm~ are available first; and if they are not (e.g. because I am roaming outside my local network) just proceed with builds locally so that I don't have to remember to pass --no-offload? Thanks, Kyle
Re: Using emacs library with guix environment
jgart writes: > I'm only able to properly source the library into the environment if I run > the following: > > `guix environment emacs-commander --ad-hoc emacs-commander` > > Why do I have to provide emacs-commander twice to the environment command? I believe the key package that the first emacs-commander (the one before --ad-hoc) brings in is emacs along with its corresponding EMACSLOADPATH. Notice that $ guix environment --pure --ad-hoc bash emacs-commander -- sh -c 'echo $EMACSLOADPATH' outputs nothing. Now if emacs is added as an ad-hoc package: $ guix environment --pure --ad-hoc bash emacs-commander emacs -- sh -c 'echo $EMACSLOADPATH' /gnu/store/qg6rsw6w587aykln2dzssr43nl6jq1a1-profile/share/emacs/site-lisp Or another test, dropping --pure to be closer to your initial snippet: $ guix environment --ad-hoc emacs-commander -- \ emacs -Q --batch --eval '(print (locate-library "commander"))' nil # add emacs as ad-hoc package $ guix environment --ad-hoc emacs-commander emacs -- \ emacs -Q --batch --eval '(print (locate-library "commander"))' "/gnu/store/kr9cnw5c9nydiilb25w3q5bnp5c1zvca-emacs-commander-0.7.0/share/emacs/site-lisp/commander-0.7.0/commander.elc"
Re: Workflow with mu4e + magit for sending patchsets to guix?
Pierre Neidhardt writes:
> --8<---cut here---start->8---
> (defvar ambrevar/known-mailing-list-archives
> '(("help-guix@gnu.org" . "guix-user")
> ("guix-de...@gnu.org" . "guix-devel")
> ("debbugs.gnu.org" . "guix-bugs"))
> "Alist of mail adresses and their Yhetil name.
[...]
Thanks.
> Note that I've set two entries, one that prefer guix-patches over
> guix-bugs because they seem to use the same recipient domain
Eric Wong has been working on adding an "external index" to public-inbox
that allows operating on a collection of inboxes.
https://public-inbox.org/meta/20201027075453.19163-...@80x24.org/
https://public-inbox.org/meta/20201126194543.GA30337@dcvr/
The feature is still being cooked, but I got around to trying it out
this weekend, and it seems to work nicely.
Anyway, that feature helps here because it allows all Guix-related lists
to be exposed under a single inbox. You can now construct a URL without
worrying about which particular list the message is from:
https://yhetil.org/guix/87k0u8v42a@ambrevar.xyz
Re: Workflow with mu4e + magit for sending patchsets to guix?
zimoun writes: > On Mon, 16 Nov 2020 at 21:36, Kyle Meyer wrote: > >>> 4. !! send-email --to=guix-patc...@gnu.org -cover-letter.patch >>> 5. Wait and refresh my inbox >>> 6. !! send-email --to=12...@gnu.org 000?-*.patch >> >> Yeah, 4-6 are tricky and debbugs-specific. For other projects, it could >> just be 'send-email *.patch' once sendemail.to is configured to point to >> the list's address. >> >> For 6, using '--no-thread --in-reply-to=...' will retain the same >> threading you'd see if you weren't using debbugs (i.e didn't have to do >> the two-step send). [...] > To me, today the main annoyance is the selection of the patches at the > step #6. For example, avoid to resend unrelated patches, as: > > - 000?-*.patch could resend the -cover-letter.patch > - *.patch could resend -cover-letter.patch and 0001-Foo-bar.patch > if I am currently sending v2-0001-Foo-bar.patch > - any previous patchset remaining. Yeah, I agree about that being the most annoying aspect, but I'd say that core problem comes from the need for a two-step send. That's a quirky enough divergence from the standard workflow that I think any solution/helper here is unlikely to be in the scope of Magit. But that doesn't mean I don't think it'd be nice to come up with a helper. > Recent example inside my > guix-artwork checkout: > --8<---cut here---start->8--- > -cover-letter.patch > 0001-website-Add-conference-announcement.patch [...] > 0001-website-Update-manifest.patch > tiny.patch > v2-0001-website-Add-conference-announcement.patch [...] > v4-0001-website-Release-conference-schedule.patch > --8<---cut here---end--->8--- > > That’s why time to time I create an output directory and put the series > in. But the -cover-letter.patch (or vN--cover-letter.patch) is > still annoying because it blocks the simple *.patch. Nothing simpler > than * could be done, I see you regexp integrist. :-) Yeah, I'd guess a directory per topic and version is pretty common to make selecting the patches simply DIR/* (again, assuming a normal one-step send-email process). > I am thinking loud. One option (some setq) could be added to Magit > format-patch, and do under the hood: > > - create -cover-letter.patch in the root directory > - create folder v1 (default), otherwise v2 … vN and put the series >in. > > This would be configurable via Magit variables, say: > > magit-send-email-workflow t > magit-format-patch-directory-prefix “v” As I said, I'm not sold on this being something that fits Magit proper, but I'll help write a helper :) > Then, the sequence, > > W C-m l C-m c > W C-m v2 c > W C-m l C-m v3 c > > would produce the final tree: > > + > +- .git > +- -cover-letter.patch > +- v3--cover-letter.patch > +- v1 > +- 0001-Foo-Bar.patch Here's a command that gets you close to that layout. It adds an additional "/" directory on top of the structure you show above. The name is reads from the caller (with a default completion value of the current branch name). It also depends on the caller having an upstream branch set (which I think is a good thing), but you could rework it to avoid it. --8<---cut here---start->8--- (defun my/magit-patch-create-split-directory (name args files) "Create patches in a split layout. Call `git format-patch ARGS -- FILES`, splitting the cover letter off from the main patches. A standard format-patch calls creates a layout like -cover-letter.patch 0001-commit-1-subj.patch 0002-commit-2-subj.patch ... in the directory specified by `--output-directory=' or the current directory. This command expands the structure as NAME |-- -cover-letter.patch `-- vN |-- 0001-commit-1-subj.patch |-- 0002-commit-1-subj.patch where NAME is a name for the series and N is the version specified via `--reroll-count='. The cover letter will have a \"vN-\" prefix after the first version. The motivation for the above layout is to make it easier to send the cover letter to a Debbugs list and, once a bug number is assigned, follow up with the remaining patches: $ git send-email --to=$debbugs-list NAME/-cover-letter.patch $ # [ wait for mail ] $ git send-email --to=$bug-address-from-mail \\ --in-reply-to=$cover-letter-message-id --no-thread NAME/vN/*" (interactive (cons (read-string "Series name: " nil nil (magit-get-current-branch)) (let ((args (transient-args 'magit-patch-create))) (list (seq-filter #'stringp args)
Re: Workflow with mu4e + magit for sending patchsets to guix?
Kyle Meyer writes: >> C-m l > > If you follow the convention of writing a cover letter only for > multi-patch series, you can drop the 'C-m l' because by default git will > generate a cover letter when there is more than one commit. Sorry, I was mistaken: generating a cover letter for a multi-patch series is _not_ git's default behavior. That requires setting format.coverLetter to "auto" in your git configuration.
Re: Workflow with mu4e + magit for sending patchsets to guix?
zimoun writes:
> Hi Chris
>
> +CC Kyle since they probably knows the status [1].
Sorry, I have no good news for you :/
> On Mon, 16 Nov 2020 at 15:28, Christopher Lemmer Webber
> wrote:
>
>> I've been making patchset series of emails to guix-patches manually.
>> I'm sure this is the wrong thing to do. I use mu4e + magit and know
>> others have a similar setup.
>>
>> What do you all do?
>
> I am sending really few patches so my workflow is probably not
> optimized. What I do is from magit-status:
>
> 1. Select the commits
I'd suggest always setting an upstream for topic branches. Then the
range you're interested in is almost always "@{upstream}.." (which can
be shortened to "@{u}.."). Or you can add something like this to
Magit's popup [1]:
;;
https://git.kyleam.com/emacs.d/tree/lisp/km-magit.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n836
(defun km/magit-patch-create-from-upstream ( args)
(interactive (list (transient-args 'magit-patch-create)))
(if-let ((upstream (magit-get-upstream-branch)))
(apply #'magit-run-git "format-patch" upstream args)
(user-error "No upstream branch")))
(transient-append-suffix 'magit-patch-create "c"
'("u" "@{upstream}.." km/magit-patch-create-from-upstream))
Most of my magit customizations never find their way upstream (they tend
to be very tailored to me), but something like the command above would
probably be good to add.
> 2. W c
> C-m b origin/master RET
Yay, base commit :) Note that with the upstream set, you can select
"auto" here. Or you can configure format.useAutoBase to "whenAble" and
not bother setting the option for each invocation.
> C-m l
If you follow the convention of writing a cover letter only for
multi-patch series, you can drop the 'C-m l' because by default git will
generate a cover letter when there is more than one commit.
> c
> 3. Edit the cover letter
> 4. !! send-email --to=guix-patc...@gnu.org -cover-letter.patch
> 5. Wait and refresh my inbox
> 6. !! send-email --to=12...@gnu.org 000?-*.patch
Yeah, 4-6 are tricky and debbugs-specific. For other projects, it could
just be 'send-email *.patch' once sendemail.to is configured to point to
the list's address.
For 6, using '--no-thread --in-reply-to=...' will retain the same
threading you'd see if you weren't using debbugs (i.e didn't have to do
the two-step send).
Also, not helpful for mu4e users, but since I know simon uses notmuch...
notmuch has a really handy notmuch-show-stash-git-send-email. I have a
variant for step 5 above. If you call it visiting the acknowledgment
message, it will copy
--to="nn...@debbugs.gnu.org" --in-reply-to="message-id"
to your kill ring.
https://git.kyleam.com/emacs.d/tree/lisp/km-mail.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n225
> AFAIK, there is no ’send-email’ support with Magit. [...]
>
> What I have understood is that Magit-forge should implement ’send-email’
> as a backend (forge) but it has not happened yet. Or I missed the
> news. :-)
Right, there's no send-email support in Magit (or any of the extensions
under its organization). I of course can't speak for Jonas, but I'm not
aware of any movement or concrete plans on that front. I think the most
recent thread to touch on this is actually the one you opened early this
year about extending format-patch options:
<https://github.com/magit/magit/issues/4028>.
And, sadly I guess, my view is still similar to what I said there:
send-email has of course come up a number of times before (gh-1756 and
gh-1800 are the most relevant, I think), and tackling that requires a
vision that I don't really have. Perhaps due to a lack of
imagination, I can't think of an implementation on Magit's side that
would improve the simple send-email command that I run. In terms of
sending mail, the most involved thing that I need to do is get the
--to/--ccs and --in-reply-to from an existing thread, but in my view
that's outside of Magit's scope.
I don't know. Maybe I should try to think harder about it.
A final note of hope: as a lurker on the notmuch list, I've noticed that
Jonas has starting doing some patch-based contributions. So, perhaps
he'll get an itch and do his amazing Jonas thing.
Re: Guix completion in Emacs
Pierre Neidhardt writes: > It works on and off for me, sometimes with the same error. > I haven't figured out yet how to reproduce this issue reliably. Part of the reason it may have been breaking for me was that I was placing an additional git checkout of guix on my guile %load-path. I don't remember why I thought I might need to do that.
Re: Printer configuration
Wiktor Żelazny writes: > On Fri, Jun 26, 2020 at 06:12:23PM -0400, Kyle Andrews wrote: > >> I figured out how to successfully print a document using ~libreoffice >> --headless -p test.odt~. So, I think my printer problem is actually >> reflecting a problem with system-config-printer. > > Or perhaps the difference is that that print job did not have to involve > rastertoqpdl. Have you tried something like > >lpr a-simple-text-file.txt > > ? > Yes, I did. That worked too! > Of course, I second Tobias in advising you to try localhost:631. CUPS > may figure out some smart configuration for you. I was able to print a test page through the CUPS web interface as well. So, this further points to system-config-printer being buggy. > Good luck, > > WŻ Thanks for all your help. Kyle
Re: Printer configuration
Wiktor Żelazny writes: > On Fri, Jun 26, 2020 at 02:13:14PM -0400, Kyle Andrews wrote: >> >> Wiktor Żelazny writes: >> >> > Does /gnu/store/.../cups/filter/rastertoqpdl exist? >> >> Yes, it exists in the splix package, but not in the cups package. >> Looking at the Guix source code I saw that ~system-config-printer~ (in >> ~guix/gnu/packages/gnome.scm~) takes input from cups on build, but not >> from splix or other print drivers. Could that be part of the problem? > > I wouldn’t be surprised. On the other hand, it does not import other > extensions, such as hplip and foomatic-filters, either. > > Did you run guix system reconfigure after adding the packages to > config.scm? Did you try removing and adding the printer again > afterwards? > > Does a /var/guix/profiles/system/profile/lib/cups/filter/rastertoqpdl > symlink exist in your filesystem? I think you could try changing the > rastertoqpdl path defined in the system-config-printer configuration (or > CUPS configuration, assuming it’s just a CUPS GUI frontend) from > /gnu/store/… to that path. /gnu/store/ contents are volatile. Again, > just guessing; perhaps the path is hardcoded into the CUPS/splix build > and uneditable. > > WŻ Hi WZ, > Did you run guix system reconfigure after adding the packages to > config.scm? Did you try removing and adding the printer again > afterwards? I did reconfigure, but I didn't try removing and adding the printer again. > Does a /var/guix/profiles/system/profile/lib/cups/filter/rastertoqpdl > symlink exist in your filesystem? I think you could try changing the > rastertoqpdl path defined in the system-config-printer configuration (or > CUPS configuration, assuming it’s just a CUPS GUI frontend) from > /gnu/store/… to that path. /gnu/store/ contents are volatile. Again, > just guessing; perhaps the path is hardcoded into the CUPS/splix build > and uneditable. It does appear to exist. Actually, I figured out how to successfully print a document using ~libreoffice --headless -p test.odt~. So, I think my printer problem is actually reflecting a problem with system-config-printer. Kyle
Re: Printer configuration
Wiktor Żelazny writes: > On Fri, Jun 26, 2020 at 12:56:08PM -0400, Kyle Andrews wrote: > >> I observed no change in the error I get when trying to print a test >> page. > > Does /gnu/store/.../cups/filter/rastertoqpdl exist? > > Is the user printing the test page a member of the lp group (lpadmin > might also help)? > > WŻ Hi WZ, Thanks for following up. > Does /gnu/store/.../cups/filter/rastertoqpdl exist? Yes, it exists in the splix package, but not in the cups package. Looking at the Guix source code I saw that ~system-config-printer~ (in ~guix/gnu/packages/gnome.scm~) takes input from cups on build, but not from splix or other print drivers. Could that be part of the problem? > Is the user printing the test page a member of the lp group (lpadmin > might also help)? The user is in the lp group. I didn't know about lpadmin. I will add that group as well and see if it changes anything. The CUPS localhost page was behaving strangely (stalling on load) when I tried to click the administration tab. Thanks for the tip! Kyle
Re: Printer configuration
Wiktor Żelazny writes: > On Thu, Jun 25, 2020 at 10:11:36PM -0400, Kyle Andrews wrote: > >> (use-modules ... >> (gnu packages cups) >> ...) > >> (service cups-service-type >> (cups-configuration >> (extensions >> (list hplip-minimal cups-filters splix)) >> (server-name host-name) >> (host-name-lookups #t) >> (web-interface? #t))) > > Hi Kyle, > > Just a wild guess, but how about declaring cups and splix in the > `packages` part of your config.scm? > > WŻ Thanks for the suggestion, WZ! I gave it a shot adding cups and splix into my default packages. Unfortunately, even after completely restarting the computer I observed no change in the error I get when trying to print a test page.
Re: Printer configuration
Kyle Andrews writes: > Dear Guix, > > Could you help me get my printer working? > > I setup my cups service: > > ... > (use-modules ... >(gnu packages cups) > ...) > (use-service-modules ... cups ...) > ... > (service cups-service-type > (cups-configuration > (extensions >(list hplip-minimal cups-filters splix)) > (server-name host-name) > (host-name-lookups #t) > (web-interface? #t))) > ... > > Then I reconfigured my system and restarted. Now I can access the CUPS > page on localhost:631. However, I could not figure out that interface > for the life of me. Instead, I found out I could install the > `system-config-printer' package which provided a setup utility that > actually made sense, giving me hope of falling into a "pit of > success". It detected my printer, great! Unfortunately, it failed to > print a test page, popping up a warning box with the text: > > Printer 'SCX-4200' requires the '/gnu/store/.../cups/filter/rastertoqpdl' > program but it is not currently installed. > > I'm not sure what to do now. Thanks in advance for any suggestions on > how to resolve this. > > Best Regards, > Kyle After sending I realized there were two pieces of information I forgot to include that might be of interest towards diagnosing the difficulty: 1.) The printer is a SCX-4200 and is listed as working on openprinting.org. 2.) the slice of the error message I showed was incomplete: the guix package where rastertoqpdl is being searched for is in cups, yet the tool is clearly available in the splix package. Why is system-config-printer looking in the wrong package? How can I make the service see both? Thanks, Kyle
Printer configuration
Dear Guix, Could you help me get my printer working? I setup my cups service: ... (use-modules ... (gnu packages cups) ...) (use-service-modules ... cups ...) ... (service cups-service-type (cups-configuration (extensions (list hplip-minimal cups-filters splix)) (server-name host-name) (host-name-lookups #t) (web-interface? #t))) ... Then I reconfigured my system and restarted. Now I can access the CUPS page on localhost:631. However, I could not figure out that interface for the life of me. Instead, I found out I could install the `system-config-printer' package which provided a setup utility that actually made sense, giving me hope of falling into a "pit of success". It detected my printer, great! Unfortunately, it failed to print a test page, popping up a warning box with the text: Printer 'SCX-4200' requires the '/gnu/store/.../cups/filter/rastertoqpdl' program but it is not currently installed. I'm not sure what to do now. Thanks in advance for any suggestions on how to resolve this. Best Regards, Kyle
Guix completion in Emacs
Hello Everyone, I am unable to conditional tab completion of Guix commands when in shell-mode or eshell-mode in Emacs. In other words, I can tab-complete the major modules e.g. ~guix package~, but cannot tab complete ~--arguments~ to them. When I try I see an error: guix-geiser-eval: Error in evaluating guile expression: ice-9/boot-9.scm:1669:16: In procedure raise-exception: error: help-string: unbound variable Certainly this stuff isn't broken for everyone, is it?
Re: How configure my desktop to use a static ip address?
Thanks to generous help from several people in the #guix IRC channel, I
learned that the trick I was missing was that I could actually use
Network Manager to setup a static IP once the router has been configured
to reserve it. This generates a ~*.nmconnection~ configuration file
into:
: /etc/NetworkManager/system-connections
Then a simple-service etc-service can be added to the services list in
~/etc/config.scm~ to make that reproducible. I still need to figure out
exactly how to do that, but I have some leads.
guix-vits suggested that to simplify the generation of the configuration
file in /etc, I could store the file alongside ~/etc/config.scm~ and
reference it using some code like:
(define (cat-file path)
(use-modules (ice-9 textual-ports))
(with-input-from-file path (lambda _ (get-string-all
(current-input-port)
(define %nm-static-connection (cat-file
"/etc/nm-static-profile.nmconnection"))
(operating-system
...
(services
(cons*
(simple-service 'nm-static-connection
etc-service-type
`(("NetworkManager/system-connections/nm-static-profile.nmconnection"
,%nm-static-connection
...))
I haven't tested it quite yet, but it makes some sense to me. If you
think this is not exactly the right approach, please let me
know.
Kyle Andrews writes:
> Dear Guix,
>
> I would like to setup my desktop computer so that I can easily
> synchronize it with my laptop via ssh and sshfs. Ideally, I would like
> to be able to do this from anywhere in the world behind
> e.g. AirVPN. However, honestly I know next to nothing about
> networking. So, I'm looking for guidance on how I can get there from
> here. Hopefully, you can help me and others who are looking to setup
> something similar.
>
> I've managed to setup the openssh-service which allows me to connect via
> SSH to my desktop on my local network if I go over to it and type ~ip
> address~ to learn the current IP address assigned to it. However,
> frequently I run into this scary message when trying to connect:
>
> @@@
> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>
> While I have gotten into the routine of editing ~/.ssh/known_hosts and
> deleting the previous entry, I would like to resolve the issue for
> good. From my reading I think the best way to do that would be to set up
> a static IP for my desktop. I think to do that I need to . Do I need to
> modify my /etc/config.scm to use
> static-networking-service? If so, how? Do I also need to modify my
> router configuration?
Re: Could anyone please package RStudio?
Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Kyle Andrews writes: >> >>> […] Below I provide >>> links to the NixOS RStudio package along with Rekado's package of an >>> older version of RStudio (which also didn't build for me). >> >> The rstudio-server package in the guix-bimsb channel[1] can be built >> again. I’m going to work on getting this older version into Guix first, >> and then try to upgrade it later. > > [1]: > https://github.com/BIMSBbioinfo/guix-bimsb/blob/master/bimsb/packages/staging.scm#L106 I tried installing rstudio again from guix-bimsb, but it failed for me at building the qtwebkit package. Unfortunately, I don't think I saved the details. I'm eager to see rstudio available through the official guix repo so the installation process can be much faster and less stressful on my aging laptop.
Re: Emacs, distro with guix as package manager and guix.d
On my guix (d441a6455051d70d7ff0d951c7e68318499b1739), a quick search (guix\\.d[^a-z]) using the silver-searcher reveals several additional packages and documentation makes references to these directories including several emacs packages as well as: cedille in gnu/packages/cedille uim in gnu/packages/xorg ghc-hindent in gnu/packages/haskell-xyz Ricardo Wurmus writes: > Jelle Licht writes: > >> Ricardo Wurmus writes: >> >>> >>> The guix.d directory has been removed. What version of Guix are you using? >> >> `guix build emacs-ess' still seems to result in a guix.d >> directory. Perhaps this is because it uses a different build system? > > Yes, this would need to be updated.
Re: Emacs, distro with guix as package manager and guix.d
emacs-ess build ESS version 17.11 which is significantly out-of-date as well. The latest release is 18.10. Pierre Neidhardt writes: > If I recall correctly, a number of packages had to be updated after the > transition to the new build system. I suppose that emacs-ess was left aside.
Re: Could anyone please package RStudio?
Ricardo Wurmus writes: > Hi Kyle, Hi Ricardo, > It’s on my list to eventually package a more recent version of Rstudio. > I’ve been using the older version for quite some time at the institute, > but it’s possible that with recent upgrades to Guix the package no > longer builds. > > One obstacle to adding RStudio to Guix is that Java to JavaScript > compiler that hasn’t been packaged yet. In my package definition we’re > using the prebuilt Jar as a blob. I read a little about these Google GWT (http://www.gwtproject.org/gettingstarted.html) and Google GIN (https://gwtplus.github.io/google-gin/site/index.html) packages. Both pieces of software are licensed asl2.0. From what I could tell reading the documentation for GWT, it doesn't appear to need to be built. Atleast with my monkey patching I noticed it complaining that: Buildfile: build.xml does not exist! The same thing happens with GIN, but I have never used either of these tools so I'm in the dark with respect to their typical behavior. I tried to build both of these packages, but I don't really know what I'm doing. I put the package definitions I wrote in a snippet on the Debian pastebin here: https://paste.debian.net/1128951 Maybe it may at least save someone a minute or two? > I won’t be able to work on this soon (probably not before March), but I > can lend a hand to whoever would like to package RStudio now. Thanks for the offer of help. I look foward to when RStudio is merely a ~guix install rstudio~ away. Best Regards, Kyle
Could anyone please package RStudio?
Dear Guix, Now that Qt 5.12 and qtwebengine have been added to Guix, would an experienced packager be able to add RStudio to Guix? It appears that all of the dependencies referenced in the NixOS package definition are also packaged for Guix. Many thousands of R users are enthusiastic about Reproducible Research* and if RStudio were available to interface with the impressive set of R packages from CRAN already available, it would make Guix a very attractive choice for many R users. I've tried tackling packaging it myself, but as primarily an applied R user and not a system administrator the RStudio IDE appears much more complicated than packaging an R library. This IDE is AGPL licensed and is split into two parts a server and a desktop version. Below I provide links to the NixOS RStudio package along with Rekado's package of an older version of RStudio (which also didn't build for me). - https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/r-modules/wrapper-rstudio.nix - https://github.com/NixOS/nixpkgs/blob/f024caa7a8f274a16048e71c30e1bac9e75c0ab4/pkgs/applications/editors/rstudio/default.nix - https://github.com/BIMSBbioinfo/guix-bimsb/blob/master/bimsb/packages/staging.scm * For example, so notes on reproducible research in R from Karl Broman: https://kbroman.org/Tools4RR Thanks for any and all developments on this front. I am extremely grateful for all the work everyone in this community has done to bring Guix so far. If there is anything I can do to help with getting this packaged, please let me know. I'm eager to get on with my research, but I would love to be able to do that from Guix so that I will know for sure I will be able to reproduce my work :) Thanks, Kyle
