Re: ./pre-inst-env with extra channels
I though that this should work, but it didn't. I just got a bunch of warning about out of date ".go" compiled scheme files, and an exit code of 1, and nothing more. Nothing to STDOUT or STDERR: ./pre-inst-env guix system -L ~/.config/guix/current/share/guile/site/3.0 build /etc/guix/configuration.scm
Re: ./pre-inst-env with extra channels
Come to think about it, I did this in the past, but I wanted a less roundabout way of get it to work. For anyone else in a similar position looking for options, this does work :)
./pre-inst-env with extra channels
How can I use the Guix version of my Git clone, alongside its packages, services, etc. while still using extra channels? Sample run: a build of my current system works: $ guix system build /etc/guix/configuration.scm /gnu/store/gfn6hpim1njlnr0d3p6mmvc4zgqmgqw6-system But when trying to use the code from my clone, it fails to recognize the extra channels, available in the system-wide /etc/guix/channels.scm file: $ ./pre-inst-env guix system build /etc/guix/configuration.scm guix system: error: failed to load '/etc/guix/configuration.scm': ice-9/boot-9.scm:3330:6: In procedure resolve-interface: no code for module (xyz euandreh queue)
Bash completion in "guix home"
After installing the `bash-completion` package in my home.scm via "guix home", the completion files weren't being loaded. I found them at $HOME_ENVIRONMENT/profile/etc/bash_completion.d/, and I have fixed it by manually loading them: for f in "$HOME_ENVIRONMENT"/profile/etc/bash_completion.d/*; do . "$f" done However, shouldn't this be done by guix home itself? Maybe inside $HOME_ENVIRONMENT/setup-environment? Does this work already and I've done something wrong with my environment to disable it? If this is a bug in guix home, I'm willing to write the patch that fixes it.
Re: guix pull; guix package -u; sudo guix system reconfigure /etc/config.scm
> When I did it two days ago it took 6 hours. I couldn't swich off my > laptop. You can switch your laptop. Whatever was fully compiled or downloaded before stopping the upgrade will be kept, and running it again will pick it up from there.
Re: Can't serve a custom channel on a HTTPS repository
I've just registered one: https://issues.guix.gnu.org/50606
Re: Can't serve a custom channel on a HTTPS repository
Final conclusion: libgit does support bare repositories served via HTTP, but only when using Git's "Smart HTTP", but not the "Dumb HTTP" [0]. Take Guix's channel served on Savannah: $ curl -I https://git.savannah.gnu.org/git/guix.git/info/refs HTTP/1.1 200 OK Content-Type: text/plain $ curl -I https://git.savannah.gnu.org/git/guix.git/info/refs?service=git-upload-pack HTTP/1.1 200 OK Content-Type: application/x-git-upload-pack-advertisement In this case, Savannah is honouring Git's query params, and speaking the "Smart HTTP" protocol. The problem came when I tried serving a bare Git repository over HTTP using the "Dumb HTTP" protocol, and that libgit doesn't implement [1]: $ curl -I https://euandreh.xyz/package-repository.git/info/refs HTTP/2 200 content-type: text/plain; charset=UTF-8 $ curl -I https://euandreh.xyz/package-repository.git/info/refs?service=git-upload-pack HTTP/2 200 content-type: text/plain; charset=UTF-8 [0]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols [1]: https://github.com/libgit2/libgit2/issues/4652#issuecomment-390903142 --- So my suggestion is that Guix understands how to fetch from channels that are just tarballs. Right now channels are married to Git, and specifically, libgit's reimplementation of Git. This is limiting for people who: 1) want to have bare Git repositories served via HTTP, but using only the "Dumb protocol"; 2) want to have Guix channels on things other than Git, like Mercurial, Fossil, BitKeeper, etc.; 3) want to distribute only the tarball of the channel, and not the repository where the code of the channel lives. I see Guix channels understanding tarballs as a solution to the above. One could argue that other DVCS would be treated as second class, since no authentication or caching would be done, but I find this reasonable, and also decoupled from the choices of the channel provider. As long as they can produce a tarball with Guile files, iit works. This is a much lower bar to creating and maintaining Guix channels.
Re: Can't serve a custom channel on a HTTPS repository
FYI, I did send a message to the mailing list. I'm waiting on an answer, and I'll try to make the possible solution more broadly available, if a can end up with one. https://lists.gnu.org/r/savannah-hackers-public/2021-08/msg0.html
Re: Can't serve a custom channel on a HTTPS repository
I will try the savannah-hackers-public mailing list too.
Re: Can't serve a custom channel on a HTTPS repository
Does your Guix channel work on the Dumb HTTP repository?
Re: Can't serve a custom channel on a HTTPS repository
After searching a bit through the archives, all I found was message [0] of divoplade themself talking about this issue. However, isn't the Guix main channel an HTTPS bare repository itself? Being so, it may be more an issue with my installation than an issue with Guix or an underlying Git library. >From the description of Git protocols [1], I understood that the main Guix channel is served via the "Dumb HTTP" protocol. I'm just not yet sure how it does it, and how I can replicate. So it may be that the a Git repository served via the "Dumb HTTP" protocol can work as a Guix channel, but I just don't know how yet. I couldn't identify any special header or file in the Guix bare repository on Savannah [2], so that's why I'm stuck at this point. [0]: https://yhetil.org/guix/db1fe1b8a41fdc3784d4f5156e61682c19628121.ca...@divoplade.fr/t/#u [1]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols [2]: https://git.savannah.gnu.org/git/guix.git/
Re: Can't serve a custom channel on a HTTPS repository
Is this question more appropriate to the guix-devel mailing list?
Re: Can't serve a custom channel on a HTTPS repository
Was anybody else able to configure a Guix channel over a bare Git HTTPS repository, like the main Guix channel? How did you do accomplish it? Was any extra server configuration required?
Re: Can't serve a custom channel on a HTTPS repository
> This is a frustrating known issue. Bare git repositories cannot be > cloned with libgit2, which is what guile-git uses. The thing is, the bare HTTPS Git repository from Guix itself does work. I imagined that if this is an issue with guile-git, there is a server-side workaround, since the main "guix" channel is served as a bare Git HTTPS repository [0]. I do have CGit and the Git daemon installed on the server, but I wanted to *remove* them, and keep just the HTTPS one. So I'm wondering how Guix itself can accomplish that, and what I can do to replicate it. [0]: https://git.savannah.gnu.org/git/guix.git
Can't serve a custom channel on a HTTPS repository
Hi! I have the following "channels.scm" file: (cons* (channel (name 'xyz-euandreh) (url "git://euandreh.xyz/package-repository.git") (branch "main") (introduction (make-channel-introduction "d749e053e6db365069cb9b2ef47a78b06f9e7361" (openpgp-fingerprint "5BDA E9B8 B2F6 C6BC BB0D 6CE5 81F9 0EC3 CD35 6060" %default-channels) And I'm using "guix time-machine" with it: $ guix time-machine -C channels.scm -- environment --ad-hoc hello This works very well this way. However if I change the Git URL to HTTPS, it stops working: diff --git a/channels.scm b/channels.scm --- a/channels.scm +++ b/channels.scm @@ -1,7 +1,7 @@ (cons* (channel (name 'xyz-euandreh) - (url "git://euandreh.xyz/package-repository.git") + (url "https://euandreh.xyz/package-repository.git;) (branch "main") (introduction (make-channel-introduction $ guix time-machine -C channels.scm -- environment --ad-hoc hello guix time-machine: error: Git error: invalid content-type: 'application/octet-stream' The server is configured to serve over HTTPS and the Git protocol, and I can successfully clone either way: $ cd /tmp/ $ git clone git://euandreh.xyz/package-repository.git git # works $ git clone https://euandreh.xyz/package-repository.git https # also works I see that the "%default-channel-url" [0] Guile variable points to a bare HTTPS Git repository, and that the "Content-Type" header of those files is also "application/octet-stream": (define %default-channel-url ;; URL of the default 'guix' channel. "https://git.savannah.gnu.org/git/guix.git;) It seems that I also need some kind of extra HTTPS header configuration. Is this an issue with the "guile-git" library? Does Savannah has any special treatment of HTTPS repositories, or guile-git requests? What configuration I'm missing from the server to be able to serve over HTTPS only? [0]: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/channels.scm?id=68ce40cad7782e75d665283fbe67b330d9a6fdcd#n175
Re: How to call a local function from a mcron job?
That makes sense. I'll try it later and report back. Thanks!
etc/profile from Guix pack is a noop when $GUIX_PROFILE is defined
Hi Guix!
In a chat with civodul on IRC the other day we discussed about the
generated etc/profile profile created by the "guix pack" command. It is
my understanding that it falls just a very tiny bit short on making
tarballs a great application bundle. This happens because of how
$GUIX_PROFILE is treated on the generated profile. Here's the output of
an interactive session:
--8<---cut here---start->8---
$ echo $GUIX_PROFILE
/home/andreh/.config/guix/current
$ tar xf `guix pack -RR -S /bin=bin -S /etc=etc guile gnutls guile-json`
$ cat etc/profile
# Source this file to define all the relevant environment variables in Bash
# for this profile. You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
# GUIX_PROFILE=/path/to/profile ; \
# source /path/to/profile/etc/profile
#
# When GUIX_PROFILE is undefined, the various environment variables refer
# to this specific profile generation.
export
PATH="${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/bin${PATH:+:}$PATH"
export
GUILE_LOAD_PATH="${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
export
GUILE_LOAD_COMPILED_PATH="${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/lib/guile/3.0/site-ccache:${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/share/guile/site/3.0${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
$ echo $GUILE_LOAD_PATH
/home/andreh/.config/guix/current/share/guile/site/3.0
$ source etc/profile
$ echo $GUILE_LOAD_PATH
/home/andreh/.config/guix/current/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0
$ GUIX_PROFILE= source etc/profile
$ echo $GUILE_LOAD_PATH
/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0
--8<---cut here---end--->8---
By using $GUIX_PROFILE and falling back to the /gnu/store/...-profile
path, the environment variables declarations won't work in a case: when
$GUIX_PROFILE is already defined. In my case, what ended up happening
is that $GUILE_LOAD_PATH wasn't being enriched by the file, and ended up
with a duplicate entry of $HOME/.config/guix/current. I was able to
achieve the desired behaviour by making $GUIX_PROFILE undefined, but it
felt like a pitfall to me. I was left with the impression that this
wasn't the desired behaviour.
My previous mental model was that I could take a tarball generated by
"guix pack", source the profile and the binaries would be added to
$PATH. Now I feel I have to remember this detail: remember to prefix
the "source" command with "GUIX_PROFILE= ", and this should work
regardless of the environment.
Is this the desired behaviour? Am I missing something?
How to call a local function from a mcron job?
Hi Guix! I wrote a Guile function that works like a script that take no arguments and interacts with the filesystem, something like: (define (my-fn) ...) It is a wrapper over other functions defined in the same file, and calls them in the right order. Then I wanted to make this function run as a mcron job, and I tried: (define my-fn-job #(job "* * * * *" my-fn)) But that doesn't work. At reconfigure time, Guix complains about not knowing the variable 'my-fn': Unbound variable: my-fn I tried wrapping it in a '(with-imported-modules ...)' call, but the code isn't in a module, but in the same file. I guess that putting all my code from 'my-fn' and all the functions it calls inlined in a lambda in the job definition would solve it, but it feels wrong to me. Is there a way to reference it from the job, without embedding all the scheme code in the job definition?
Re: Manual: why not restart service over killing the process
Christopher Baines writes: > You're sort of right, but you've got the downsides the wrong way around. > > The key bit with the kill call is the SIGHUP but, not that it's not > SIGKILL. The current situation won't kill the NGinx process, but instead > just get it to reload the certificate (at least that's the intention). > > The restart action would "kill" the process, in that it would send it > SIGTERM and the the shepherd would start a new NGinx process, and this > has the potential of interrupting whatever is using NGinx. > > Does that make sense? Hmm, great answer! Makes sense, and the SIGHUP signal really is indeed better for this case. Thanks for the informational response!
Manual: why not restart service over killing the process
Hi! The manual suggests a deploy-hook for the certbot-service-type that looks like this: (define %nginx-deploy-hook (program-file "nginx-deploy-hook" #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read))) (kill pid SIGHUP Instead of requiring the deploy-hook to know the path of the PID file, why not restart the Shepherd service instead? Something like this: (define %nginx-deploy-hook (program-file "nginx-deploy-hook" (with-imported-modules '((gnu services herd)) #~(begin (use-modules (gnu services herd)) (restart-service 'nginx) If I understood correctly, those would result in equivalent outcomes, and I tend to find the latter a more elegant approach. It is a bit longer, but I like more restarting the service rather than killing the process. Is there any downside I'm missing? I can send a patch to the manual if this seems reasonable.
Re: How to select git:send-email output in config.scm?
Tobias Geerinckx-Rice writes:
> Indeed, my first mail was too hurried & my longer mail didn't
> address this part at all...
>
> (packages
> (append
> (list (list git "send-email")
> (list git "gui"); just another example
> foo
> ...)
> (map specification->package
>'("git"
> "bar"
> ...)
>
> PACKAGES takes a list of, well, packages -- *or* (package output)
> sublists! This is not well-documented: it's mentioned in
> gnu/system.scm, but not in the manual under ‘operating-system
> Reference’. I will add it there. Thank you for pointing it out.
Thanks for the explanation, now I could make it work.
> If you want to go one step further, get rid of APPEND, and MAP
> everything: it's not hard to write a procedure similar to
> specification->package+output that returns a list instead of
> multiple values (hint: take a look at DEFINE-VALUES). There might
> well already be one hiding somewhere. I don't know.
>
> For today, at least, I'll leave this as an excercise for the
> reader. :-p
Challenge accepted! :)
I was able to put handle both cases with a single function. I wasn't
able to get rid of map, though. Here's what I got so far:
--8<---cut here---start->8---
(use-modules (gnu)
(srfi srfi-1))
(operating-system
(packages
(append
(map (lambda (spec)
(if (not (string-contains spec ":"))
(specification->package spec)
(let ((spec-pair (string-split spec #\:)))
(list (specification->package (first spec-pair))
(second spec-pair)
'("git"
"git:send-email"))
%base-packages))
...))
--8<---cut here---end--->8---
Any suggestions?
Re: How to select git:send-email output in config.scm?
> Use specification->package+output.
I tried that, and it indeed doesn't complains about 'unknown package'
anymore. However, send-email is still not installed after a system
reconfigure:
--8<---cut here---start->8---
$ sudo guix system reconfigure guix.scm
...
$ git send-email *.patch
git: 'send-email' is not a git command. See 'git --help'
--8<---cut here---end--->8---
What am I missing here?
I've attached the full file to make it clearer.
;; This is an operating system configuration generated
;; by the graphical installer.
(use-modules (gnu))
(use-service-modules desktop networking ssh xorg nix)
(operating-system
(locale "en_US.utf8")
(timezone "America/Sao_Paulo")
(keyboard-layout (keyboard-layout "br" #:options '("caps:swapescape")))
(host-name "velhinho-guix-system")
(users (cons* (user-account
(name "andreh")
(comment "andreh")
(group "users")
(home-directory "/home/andreh")
(supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts))
(packages
(append
(map specification->package+output
'("nss-certs" ;; suggested by Guix
"help2man" ;; used in Guix development
"strace"
"wget"
"xclip"
"autojump"
"git"
"git:send-email"
"rlwrap"
"myrepos"
"borg"
"bash-completion"
"vlc"
"youtube-dl"
"sox"
"jq"
"calibre"
"notmuch"
"isync"
"xset"
"bluez"
"playerctl"
"xmessage"
"alsa-utils"
"icecat" ; not firefox FIXME
"git-remote-gcrypt"
"git-crypt"
"the-silver-searcher"
"fd"
"ranger"
"seahorse"
"nautilus"
"git-annex"
"emacs"
"gettext"
"openssh"
"gnupg"
"nvi"
"tmux"
"direnv"
"pinentry-gnome3"
"pinentry"
"keepassxc"
"recutils"
"owncloud-client" ; FIXME: nextcloud
"xterm"
"htop"
;; xmonad
"xmonad"
"ghc"
"ghc-xmonad-contrib"
"gcc-toolchain"
"glibc"
"xmobar"
"dmenu"))
%base-packages))
(services
(append
(list (service gnome-desktop-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout
%desktop-services))
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")
(keyboard-layout keyboard-layout)))
(mapped-devices
(list (mapped-device
(source
(uuid "67a25dfa-ed48-4466-89f3-e291365df104"))
(target "cryptroot")
(type luks-device-mapping
(file-systems
(cons* (file-system
(mount-point "/")
(device "/dev/mapper/cryptroot")
(type "btrfs")
(dependencies mapped-devices))
(file-system
(mount-point "/boot/efi")
(device (uuid "1B26-9F4E" 'fat32))
(type "vfat"))
%base-file-systems)))
.
How to select git:send-email output in config.scm?
Hi guix!
How can I selecet the git:send-email output in my "operating-system"
declaration inside config.scm?
Right now I only have the git package, but I don't know which output it
is selecting. I guess the git:out one?
I tried adding it just like that to my config.scm declaration:
--8<---cut here---start->8---
(packages
(append
(map specification->package
'("git"
"git:send-email"
...)
--8<---cut here---end--->8---
But when running guix system reconfigure, it complains about it, saying:
--8<---cut here---start->8---
guix system: error: git:send-email: unknown package
guix system: error: failed to load 'guix.scm':
ice-9/boot-9.scm:222:17: In procedure map1:
--8<---cut here---end--->8---
However, running "guix environment --ad-hoc git:send-email" does work.
I got a bit confused by that. On IRC pkill9 mentioned that "git" is a
package, but "git:send-email" is an output. But isn't "git" the same as
"git:out"?
How can I declare that I want the "git:send-email" output also installed
in my config.scm?
Re: guix environment shebang interpreter
ml...@posteo.de writes: > But, one answer there has a possible solution for you: > https://unix.stackexchange.com/a/399698 > > --8<--- > #!/bin/sh - > > if [ "$1" != "--really" ]; then exec bash --posix -- "$0" --really "$@"; > fi > > shift > > # Processing continues > --->8--- > > It lets the script `exec` itself with the right arguments! So maybe put > > exec guix environment --ad-hoc PKG1 PKG2 ... -- INTERPRETER "$0" > "$@" > > there? Hmm, I guess that works. It's a bit ugly but does the job. Thanks for the link. I also just wanted to check for the existance of such functionality in Guix already, before pursuing alternatives. Thanks Moritz :)
Re: Guix as a package manager for Emacs
zimoun writes: > Maybe you can give a try to Guix Home Manager. :-) > > https://framagit.org/tyreunom/guix-home-manager H, that looks interesting! I'll take a look at it, thanks for the link :) signature.asc Description: PGP signature
Re: Guix as a package manager for Emacs
zimoun writes: > The easiest way to achieve similar is to use a manifest file, IMHO. > > Let consider the file below named '/tmp/my-emacs-config.scm', then it > is easy to create a profile (or environment): > >guix package -m /tmp/my-emacs-config.scm -p /tmp/my-profile > > and the Emacs living in this very profile should be correctly setup-ed > for your needs. Therefore let source the profile or whatever and done. > :-) At first I though guix would install the packages, but Emacs would be unable to look them up on the store. I didn't realize the final profile would setup Emacs to correctly look them up. So I was missing an 'emacsWithPackage' tool that would do that binding, but it doesn't actually seem necessary. Using a manifest seems a good solution, I'll try it out. Thanks for the code snippet too. Hopefull I'll get it working and write/blog about it. :) signature.asc Description: PGP signature
Re: Guix as a package manager for Emacs
zimoun writes: > The formatting failed! :-( > > I let you use Emacs to reformat correctly. :-) Challenge accepted! signature.asc Description: PGP signature
Re: Guix as a package manager for Emacs
Pierre Neidhardt writes: > Hi! Hello :) > I'm not sure this is the answer you are looking for, but with Guix you > can simply install the desired "emacs-*" packages. So if I were to add the 'emacs' and 'emacs-evil-collection' packages, I could just require the packages? I'll try this next and report back if I encounter any problem. I actually considered this possibility, but ruled this out because it sounded too simple xD.
Guix as a package manager for Emacs
Hi Guix! How can I get in Guix something similar to Nix's emacsWithPackages: https://nixos.org/nixpkgs/manual/#sec-emacs-config It shows how to use Nix's packaging capabilities to setup and configure Emacs, instead of having "use-package" (or similar tools) downloading and installing packages. I found some previous messages and discussions in the lists archives, but couldn't find guidance on how to proceed. How can I accomplish it with Guix? Thanks :)
Re: guix import texlive fails because of svn
Ricardo Wurmus writes: > Looking at the strace output I see that SVN complains about the temp > directory already existing. This happens in download-svn-to-store in > guix/svn-download.scm where we generate a temporary directory and pass > it as an argument to build:svn-fetch. > > Yes, this must be a bug. Hi Ricardo, This looks like a good opportunity for me to try to start hacking on Guix itself. I've contributed with some patches to packages before, but I'd also like to start working on Guix. I'll try to fix the issue in the next days and prepare a patch. How does that sound? Just saying this so we don't work on the same issue and have duplicate effort.
Re: guix import texlive fails because of svn
> I'm afraid that I've had no success in getting this working. I'm still > unable to 'guix import' packages from TeXlive. If you find a solution, > please let me know! Sure I will!
Re: Files not .gitignored when contributing to Guix
Efraim Flashner writes: > IIRC the reason for having it this way is if the .po files are added to > .gitignore then it messes with the guix snapshots and releases. > Unfortunately I don't remember more than that. Snapshots as in release snapshots?
Re: Files not .gitignored when contributing to Guix
Julien Lepiller writes: > You should do "git checkout po" after your first make. You won't be annoyed > by that anymore afterwards. Thanks, I'm still familiarizing myself with the GNU Autotools workflow, and I would do a full git clean every time I wanted to hack on Guix source code, only realizing later that I shouldn't be running ./bootstrap and ./configure on every git pull. This way the po/ files would get modified every time. Thanks :)
guix environment shebang interpreter
Hi Guix! Is there a Guix equivalent of the nix-shell shebang? Sample from Nix documentation (https://nixos.org/nix/manual/#use-as-a-interpreter): --8<---cut here---start->8--- #!/usr/bin/env nix-shell #!nix-shell -i perl -p perl perlPackages.HTMLTokeParserSimple perlPackages.LWP use HTML::TokeParser::Simple; ... --8<---cut here---end--->8--- Can I already accomplish this with Guix? If so, how? I tried searching previous discussions of this topic on Guix mailing lists, but couldn't find any. If this was disscussed before, could anyone point me to the thread? Thanks!
Files not .gitignored when contributing to Guix
Hi Guix! When running the setup steps to prepare a patch, I find myself with a dirty repository of changed files. Is this expected behaviour? I couldn't find guidance regarding that on the manual or the mailing list archives (only a similar issue[0]), and I wonder if is there a way to avoid it, or should I just get used to it? Is there something missing for things being this way that I didn't get yet? The output of make spits some warning regarding outdated .po files. If the dirty files are generated, should they even be commited in the repository if they are derived data? Looking at the diff, it confirms this hypothesis: the diff of the .po files contain mostly generated translation strings and timestamps. The setup steps I use are: --8<---cut here---start->8--- cd $GUIX_REPO git clean -ffdx guix environment guix --ad-hoc help2man git strace ./bootstrap ./configure --localstatedir=/var make --8<---cut here---end--->8--- At the end the dirty files are: --8<---cut here---start->8--- $ git status Sur la branche master Modifications qui ne seront pas validées : (utilisez "git add ..." pour mettre à jour ce qui sera validé) (utilisez "git restore ..." pour annuler les modifications dans le répertoire de travail) modifié : po/guix/cs.po modifié : po/guix/da.po modifié : po/guix/de.po modifié : po/guix/eo.po modifié : po/guix/es.po modifié : po/guix/fr.po modifié : po/guix/hu.po modifié : po/guix/pl.po modifié : po/guix/pt_BR.po modifié : po/guix/sr.po modifié : po/guix/sv.po modifié : po/guix/vi.po modifié : po/guix/zh_CN.po modifié : po/packages/da.po modifié : po/packages/de.po modifié : po/packages/eo.po modifié : po/packages/es.po modifié : po/packages/fr.po modifié : po/packages/hu.po modifié : po/packages/pl.po modifié : po/packages/pt_BR.po modifié : po/packages/sr.po modifié : po/packages/vi.po modifié : po/packages/zh_CN.po aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a") --8<---cut here---end--->8--- I'm looking to a better way to handle this situation (that I find a bit of a nuisance right now) or maybe just an explanation behind the way things currently are. Thanks :) EuAndreh [0]: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00387.html
Re: guix import texlive fails because of svn
Hi Matthew I had the same problem some days ago: https://lists.gnu.org/archive/html/help-guix/2020-01/msg00017.html The logs are really similar, and we both performed the same svn command successfully. I still am unable to run the TeX Live importer though. Were you able to make it work after sending this message to the list?
"guix import texlive fontspec" is broken
Hi Guix!
the Guix TeX Live importer is broken for me:
--8<---cut here---start->8---
$ guix import texlive fontspec
redirection vers « https://ctan.org/xml/1.2/pkg/fontspec »...
Backtrace:
11 (primitive-load "/home/andreh/.config/guix/current/bin/…")
In guix/ui.scm:
1806:12 10 (run-guix-command _ . _)
In guix/scripts/import.scm:
116:11 9 (guix-import . _)
In guix/scripts/import/texlive.scm:
91:19 8 (guix-import-texlive . _)
In guix/memoization.scm:
98:0 7 (_ # ("fontspec" "latex") _)
In unknown file:
6 (_ # …)
In guix/store.scm:
625:10 5 (call-with-store #)
In guix/import/texlive.scm:
148:23 4 (_ #)
In guix/utils.scm:
664:8 3 (call-with-temporary-directory #)
In guix/svn-download.scm:
160:14 2 (_ "/tmp/guix-directory.HSWcZg")
In guix/build/svn.scm:
39:2 1 (svn-fetch _ _ _ #:svn-command _ #:recursive? _ # _ # _)
In guix/build/utils.scm:
652:6 0 (invoke _ . _)
guix/build/utils.scm:652:6: In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
--8<---cut here---end--->8---
I tried running the SVN command that throwed (I tried to guess it from
the error log) and it ran successfully:
--8<---cut here---start->8---
$ svn export --non-interactive --trust-server-cert -r 49435
svn://www.tug.org/texlive/tags/texlive-2018.2/Master/texmf-dist/source/latex/fontspec
/tmp/guix-directory.WtLohP
A/tmp/guix-directory.WtLohP
A/tmp/guix-directory.WtLohP/fontspec-api.dtx
A/tmp/guix-directory.WtLohP/fontspec-closing.dtx
A/tmp/guix-directory.WtLohP/fontspec-code-load.dtx
A/tmp/guix-directory.WtLohP/fontspec-code.ltx
A/tmp/guix-directory.WtLohP/fontspec-doc-api.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-enc.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-featset.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-fontsel.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-intro.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-luatex.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-opentype.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-style.sty
A/tmp/guix-directory.WtLohP/fontspec-doc-xetex.tex
A/tmp/guix-directory.WtLohP/fontspec-enc.dtx
A/tmp/guix-directory.WtLohP/fontspec-example.tex
A/tmp/guix-directory.WtLohP/fontspec-feat-aat.dtx
A/tmp/guix-directory.WtLohP/fontspec-feat-opentype.dtx
A/tmp/guix-directory.WtLohP/fontspec-fontload.dtx
A/tmp/guix-directory.WtLohP/fontspec-graphite.dtx
A/tmp/guix-directory.WtLohP/fontspec-interfaces.dtx
A/tmp/guix-directory.WtLohP/fontspec-internal.dtx
A/tmp/guix-directory.WtLohP/fontspec-keyval.dtx
A/tmp/guix-directory.WtLohP/fontspec-lang.dtx
A/tmp/guix-directory.WtLohP/fontspec-lua.dtx
A/tmp/guix-directory.WtLohP/fontspec-math.dtx
A/tmp/guix-directory.WtLohP/fontspec-msg.dtx
A/tmp/guix-directory.WtLohP/fontspec-opening.dtx
A/tmp/guix-directory.WtLohP/fontspec-opentype.dtx
A/tmp/guix-directory.WtLohP/fontspec-patches.dtx
A/tmp/guix-directory.WtLohP/fontspec-scripts.dtx
A/tmp/guix-directory.WtLohP/fontspec-user.dtx
A/tmp/guix-directory.WtLohP/fontspec-vars.dtx
A/tmp/guix-directory.WtLohP/fontspec-xfss.dtx
A/tmp/guix-directory.WtLohP/fontspec.dtx
A/tmp/guix-directory.WtLohP/fontspec.ins
A/tmp/guix-directory.WtLohP/fontspec.ltx
Exported revision 49435.
--8<---cut here---end--->8---
So I would guess the problem would be to the inputs to the build
environment that 'guix import texlive' is using, but I didn't dive into
the source code.
I picked the fontspec package because it is the example used in the
manual for the TeX Live importer, but it failed for me with other
packages too.
Any thoughts on this?
Thanks,
EuAndreh :)
Unreproducible packages visibility
Hello Guix! I know that making all packages reproducible is a current ongoing effort, and I've seen a few bug reports in debbugs about specific unreproducible packages. Is there a way to know about all unreproducible packages? Something similar to how Debian reports[0] it's packages. [0]: https://tests.reproducible-builds.org/debian/reproducible.html signature.asc Description: PGP signature
