Re: how to use r-keras?
Hi Simon, > On sam., 30 mars 2024 at 00:27, Ricardo Wurmus wrote: > >>> $ guix shell r r-keras -C python-minimal r-reticulate tensorflow >> >> Is this with tensorflow from guix-science? The old Tensorflow 1.9 in >> Guix does not provide Keras. Only the more recent one in Guix Science >> does. > > Using Guix 929ddec, it fails as reported previously; using > tensorflow@1.9.0. Let try with tensorflow@2.13.1. > > Well, although I have guix.bordeaux.inria.fr as substitutes, I had to > rebuild tensorflow. Ouch! This appears to be a common problem, but we don't know why. It's probably related to the bazel-build-system. You'll get substitutes only if you use `--no-grafts'. > Then I get this: > > --8<---cut here---start->8--- > $ guix time-machine -C channels.scm -- shell -C r r-keras -C > python-minimal r-reticulate tensorflow@2.13.1 You need python-tensorflow (also from guix-science), not just the tensorflow library. -- Ricardo
Re: how to use r-keras?
Simon Tournier writes: > Trying to run “r-keras”, I am a bit puzzled. > > [2. text/x-verbatim] > $ guix shell r r-keras -C python-minimal r-reticulate tensorflow Is this with tensorflow from guix-science? The old Tensorflow 1.9 in Guix does not provide Keras. Only the more recent one in Guix Science does. The Python bindings for tensorflow are provided by python-tensorflow. (I don't know how to use r-keras.) -- Ricardo
Re: [ext] Re: guix on nfs based systems
Hi Etienne, > I think we've arrived at the limit of how I understand the daemon to work, > and GUIX_DAEMON_SOCKET. I think I understand that you > are using a single node (hpc of sort I imagine), where users create sessions, > and within which you provide the guix command, having > set up GUIX_DAEMON_SOCKET to a unix-domain socket (to that same node / > itself). That makes total sense in the context of the single > node. Did I get that right? No, we provide Guix on *all* cluster nodes and workstations, but they all talk to a single guix-daemon, which is the sole manager of /gnu. We provide a default Guix for all those who haven’t yet run “guix pull” at /gnu/remote/bin/guix. That location is on the PATH on all machines. This script does three things: - it sets GUIX_DAEMON_SOCKET to http://guix-node: - it removes “gc” from the arguments and prints a warning (this is not enough to prevent GC, but it works well enough) - it looks for the user’s “guix” in /home/who/.config/guix/current/bin; if it exists it execs that “guix” with the arguments; otherwise it executes the shared default Guix. > The issue with profiles you are mentioning is interesting; I haven't > quite thought it through yet. I think I would personally want users to > be able to create profiles (for reproducibility reasons) but I guess > it would work the same way with guix shells built from manifests, > maybe slightly less easy to interact with, I don't know. In my experience, profiles always end up growing in a stateful manner. People use them to satisfy old habits of installing, removing, and upgrading packages, and inevitably they run into conflicts because they install new packages to a profile built with an older version of Guix. Yes, using manifests would avoid that, but if you’re already using manifests you might as well use “guix shell -m”. For long-term reproducibility we recommend recording the current channels with “guix describe -f channels” and add the output to version control. With “guix time-machine -C channels.scm -- shell -m manifest.scm” people can restore the environment in the future. -- Ricardo Wurmus System administrator BIMSB - Scientific Bioinformatics Platform Max Delbrueck Center for Molecular Medicine email: ricardo.wur...@mdc-berlin.de tel: +49 30 9406 1796
Re: guix on nfs based systems
"Etienne B. Roesch" writes: > Hiccups: we provide home dirs as nfs drives through the network. Using guix, > we are thinking of creating one nfs drive, shared by all > users, to contain /var/guix and /gnu/store, symlinked from /. > As I understand, that should work, until a user decides to run "guix gc" > (which would clear wrongly assumed unused profiles) or maybe > until a user decides to launch several vms (which is theoretically possible, > but doesn't happen often). I would strongly discourage the use of profiles in users’ home directories. When introducing Guix we now only demo “guix shell”, which is preferrable in most cases. “guix gc” is problematic when profile links are in locations that the daemon cannot read. > Efraim suggested using a shared daemon ssh-ing GUIX_DAEMON_SOCKET. We > would probably run this on a separate vm. We are however unsure how it > would behave when /var/guix/daemon-socket/socket is itself on an nfs. We only export /var/guix/profiles, not anything else in /var/guix. Using GUIX_DAEMON_SOCKET with a network port (make “guix-daemon” listen on that port) is all we ever needed. -- Ricardo Wurmus System administrator BIMSB - Scientific Bioinformatics Platform Max Delbrueck Center for Molecular Medicine email: ricardo.wur...@mdc-berlin.de tel: +49 30 9406 1796
Re: guix on nfs based systems
Hi Etienne, FWIW at the MDC we’ve been doing the same: on all nodes mount /gnu read-only, mount /var/guix read-write; provide a “guix” executable that sets GUIX_DAEMON_SOCKET and disables/discourages “guix gc”. > Thanks! That's really helpful! How robust is your system to bandwidth > fluctuations and network hiccups? Network reliability has never been an issue for us when it comes to Guix. We serve /gnu redundantly with pacemaker so that we can take down one of the two Guix servers (they are VMs) without affecting availibility of programs and files on /gnu. > How big is your store, /gnu, /var/guix? We have about 2TB for /gnu. We never run “guix gc” because the Guix servers have no access to all the users’ shares, so it would be overly aggressive in determining garbage. > How many users do you have? About 200. -- Ricardo Wurmus System administrator BIMSB - Scientific Bioinformatics Platform Max Delbrueck Center for Molecular Medicine email: ricardo.wur...@mdc-berlin.de tel: +49 30 9406 1796
Re: ibus + ibus-libpinyin in Gnome
Maxim Cournoyer writes: >> I wonder if we can do better here to provide a working configuration out >> of the box. If even the author of the patch to add support for the >> GUIX_GTK3_IM_MODULE_FILE variable cannot remember setting it then we >> probably cannot expect users of input methods to figure this out by >> themselves. >> >> Perhaps some desktop service or home service should exist that sets >> these variables for the user (either in /etc/environment or per >> session)? > > Perhaps this should rather be the role of a search path specification? > That'd be ideal. The GUIX_GTK3_IM_MODULE_FILE variable is attached to gtk+, but a search path specification would require explicit installation of the gtk+ package. In other words, it would not really help here as gtk+ is rarely ever explicitly installed. -- Ricardo
Re: ibus + ibus-libpinyin in Gnome
Hi, Luis Felipe writes: >> The GTK_IM_MODULE environment variable is set to “ibus”. I export it in >> the shell and launch “soffice” or “icecat” from there. > > Hmm, I don't have GTK_IM_MODULE set in my ~/.profile (don't remember > why I removed it...). I have these: > > # GUIX RELATED VARIABLES TO WORK AROUND BUG #35610 > # https://issues.guix.gnu.org/issue/35610 > # export > > GUIX_GTK2_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-2.0/2.10.0/immodules-gtk2.cache" > export > GUIX_GTK3_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache" Oh… I remember these from commit 234e7980b54ef37e9a24440ec7219c81d6288a71. After setting GUIX_GTK3_IM_MODULE_FILE everything is good. Thank you so much for reminding me about these variables! I wonder if we can do better here to provide a working configuration out of the box. If even the author of the patch to add support for the GUIX_GTK3_IM_MODULE_FILE variable cannot remember setting it then we probably cannot expect users of input methods to figure this out by themselves. Perhaps some desktop service or home service should exist that sets these variables for the user (either in /etc/environment or per session)? -- Ricardo
ibus + ibus-libpinyin in Gnome
Hi Guix, I’m still struggling with ibus + ibus-libpinyin on Gnome. ibus-libpinyin works in the gnome-shell input field, but the input method doesn’t work in any of the applications such as icecat, console, or soffice. The GTK_IM_MODULE environment variable is set to “ibus”. I export it in the shell and launch “soffice” or “icecat” from there. ibus and ibus-libpinyin are installed in the system profile as well as the user profile. I previously had installed them only in the user profile, but then added them to the system profile because I want to be sure that any required environment variables are set in all contexts, even when launching applications from the Gnome shell. Do you have any ideas how to best debug this? I could strace the applications and see if any of them mention a failure to talk to ibus, but I’d like to avoid having to sift through all that noisy trace output for massive GTK applications. -- Ricardo
Re: Meaning of symbol prefixed with "#$"
Hi, > Thanks so much for your suggestion! Can I ask for a name for these > notations, #~ and #$? I would like to learn more about them, but they > are difficult to Google for. These are syntax for “gexp” and “ungexp”. The Guix manual explains them in great detail in the section 9.12 G-Expressions. If you need more detail you can find it here: https://inria.hal.science/hal-01580582/en -- Ricardo
Re: Meaning of symbol prefixed with "#$"
(Moving this to help-guix instead of guile-user.)
"N. Y." writes:
> (arguments
> '(#:phases (modify-phases %standard-phases
> (add-after 'unpack 'amend-version
> (lambda _
> (substitute* "setup.py"
> (("versioneer.get_version\\(\\)")
> (string-append "\"" #$version "\"")
You can only use #$ inside an expression starting with #~. This should
work:
--8<---cut here---start->8---
(arguments
(list
#:phases
#~(modify-phases %standard-phases
(add-after 'unpack 'amend-version
(lambda _
(substitute* "setup.py"
(("versioneer.get_version\\(\\)")
(string-append "\"" #$version "\""
--8<---cut here---end--->8---
--
Ricardo
Re: Does define-command automatically add the subcommand to the guix CLI?
jgart writes: > Does define-command automagically add the subcommand to the guix CLI? > > For example, guix-format: > > https://github.com/bqv/rc/blob/live/guix/scripts/format.scm#L21 No, you need to set GUIX_EXTENSIONS_PATH. -- Ricardo
Re: add-ons in Icecat and Chromium
Gottfried writes: > Cambridge Dictionary and Oxford Advanced Learner's Dictionary have a: > Mozilla Public License 2.0 > Is that proprietäry software? No, the MPL2.0 is a free software license. You can also take a look at the non-exhaustive list of free licenses in guix/licenses.scm. -- Ricardo
Re: fatal empty ident name (for <>) not allowed
jgart writes: > On Sat, 12 Nov 2022 14:19:44 +0100 Ricardo Wurmus wrote: >> How do you apply the patches? > > How you showed me ;() > > wget -O- https://issues.guix.gnu.org/issue/58898/attachment/9/ | git am You’re working with an incomplete attachment. wget -O- https://issues.guix.gnu.org/issue/58898/patch-set/ | git am (and skip whatever empty commit there might be) -- Ricardo
Re: fatal empty ident name (for <>) not allowed
jgart writes: > Does anyone happen to know what this error is about? > > Applying: * gnu/packages/lisp.scm (carp): New variable. > fatal: empty ident name (for <>) not allowed > > It happens when I try to apply v8 of this patch: > > https://issues.guix.gnu.org/58898#9 See https://stackoverflow.com/questions/41832926/git-empty-ident-name-for-not-allowed How do you apply the patches? -- Ricardo
Re: guix builds the old guix version
Hi Adam, > I pulled the guix channel, reconfigured my system and cleaned my storage. > But when I am trying to "guix build guix", I am getting this version > guix-1.3.0-32.682639c which is old. What I need to do to build an > actual guix version? (for now it is b4e3e02) This is expected. The Guix repository contains a package definition for “guix”, which is a particular version, which necessarily must be older than the version of Guix you’ve pulled. The “guix” package can be used as a library by other packages, and it is updated occasionally. If you really do need to build the current version of Guix with Guix then do guix build -e '((@ (gnu packages package-management) current-guix))' There are only few valid use cases that require one to build the latest version of Guix that are not served better by using “guix pull”. -- Ricardo
Re: guix lint inline in your editor emacs?
jgart writes: > does `guix lint` work inline in your editor as you type, with geiser? I wouldn’t recommend it because some of the checks that “guix lint” performs are really expensive. But generally you can run any kind of check with flycheck. -- Ricardo
Re: I tried to upgrade vis but...
jgart writes: > I tried to upgrade vis but visidata was also upgraded... how comes? > > $ guix upgrade vis > guix upgrade: warning: package 'emacs-vis' no longer exists > The following packages will be upgraded: >vis 0.7 → 0.8 >visidata (dependencies or package changed) “guix upgrade” takes a regular expression. Use ^ and $ to match the beginning or end of a word. -- Ricardo
Re: make clean-go breaks my build environment
jgart writes: > after running `make clean-go` the build gets consistently stuck on > this message: > > WARNING: Use of `load' in declarative module (guix ui). Add #:declarative? > #f to your define-module invocation. > WARNING: (guix build python-build-system): imported module (guix build utils) > overrides core binding `delete' These are warnings, not errors. What do you mean by “gets […] stuck”? “make clean-go” is only supposed to delete .go files. -- Ricardo
Re: Guix package manager installed
Hi Gottfried, > I am very thankful for all the Guixers who worked and are working for > Guix, also for the manual... > > because against all hope I was able to install the Guix package > manager on another laptop on top of Trisquel on the basis of the > manual. Congratulations! > 1. As far as I understand it I have to do > > guix pull > > and a > > guix package -u > > but no > > sudo guix system reconfigure /etc/config.scm > > because there is no /etc/config.scm file > > Is that right? Correct. For the package manager all you need is “guix pull” and “guix upgrade” (or “guix package -u” or “guix package -m” etc). The configuration file at /etc/config.scm is for an operating system declaration. The “guix system” command deals with instances of Guix System, the GNU+Linux distribution. If you do not use Guix System you don’t have any system to reconfigure. You can still use “guix system” to build virtual machines and containers, but “guix system reconfigure” is not useful on a “foreign distribution”. > Where is the relevant file for the guix package manager I installed? The behavior of “guix pull” depends on an optional channels file, either at /etc/guix/channels.scm or ~/.config/guix/channels.scm. If you don’t have either of these files Guix will use sensible defaults. > 2. Do I regularly have to do a "sudo guix pull" for root? > > or is it enough that I did it once for setting up guix? If you actualy use Guix with the root user account then yes. For convenience you could link your user’s “guix” so that it is the same for the root user; then you only need to take care of running “guix pull” for your main user account. -- Ricardo
Re: no C_INCLUDE_PATH env variable defined : I can't compile C applications
Mohamed Amine LEGHERABA via writes: > When I do "echo $C_INCLUDE_PATH" in my bash prompt (either my account or > root), I have nothing. > > When I run a custom guix shell (with gcc-toolchain) and I run "echo > $C_INCLUDE_PATH", > I have "/gnu/store/1p21dbv408cb45zcc15v7wj0q7x99rz2-profile/include" > > Without this env variable, C programs can't use "linux/limits.h" or > other kernel related libraries. Any idea how to solve this problem ? You say that “guix shell” sets the variable as expected. Its value depends on the packages you add to the “guix shell” invocation. You can also augment it manually to add whatever include directories you need. -- Ricardo
Re: Guitar-to-USB cable in Guix System
Luis Felipe writes: > [[PGP Signed Part:Undecided]] > Hi, > > I recently found that these kinds of cables exist. Apparently, they > allow you to connect the guitar very easily and cheaply to the > computer, and you could simply start recording in applications like > Audacity or Ardour. > > Anyone knows if these kinds of cables work on Guix System (or any other libre > distribution)? They should work as long as they are USB class-compliant devices. Often they are advertised as working on mac and Windows alike without having to install drivers. In that case they likely are class-compliant and should work just fine.
Re: Python subprocess fails to execute Pip-installed module
Pradana Adrinusa AUMARS writes: > Running: > > import ray > ray.init() > > fails since Python's subprocess needs to run an executable located in > > ~/.local/lib/python3.9/site-packages/ray/core/src/ray/gcs/gcs_server > > So the error is narrowed down to: > > import subprocess > subprocess.Popen(["/home/user/.local/lib/python3.9/site-packages/ray/core/src/ray/gcs/gcs_server"]) Do you get an error message? Does this executable exist? -- Ricardo
Re: New ,build command sets the wrong path for guix daemon
Joshua Branson writes: > But do the same in a geiser repl, and I am running into trouble: > > #+BEGIN_SRC org > ,m (gnu services mail) > scheme@(gnu services mail)> ,use (guix) > scheme@(gnu services mail)> > While executing meta-command: > ERROR: > 1. : > file: "/usr/local/var/guix/daemon-socket/socket" Is this the location where your guix-daemon listens for connections? If not you’ve configured your Guix with the wrong localstatedir and/or prefix. -- Ricardo
Re: Help-Guix Digest, Vol 83, Issue 10
Peter Polidoro writes: >> GTK+ comes with broadwayd, which lets you use the browser to render >> the >> GUI. Here’s a quick example: >> >> guix shell gtk+:bin -- broadwayd :5 & >> GDK_BACKEND=broadway BROADWAY_DISPLAY=:5 guix shell abiword -- >> abiword >> >> Then visit http://127.0.0.1:8085/ in your browser. > > This is really interesting, thank you! > > When I try to run this, however, I get the error: > > $ guix shell gtk+:bin -- broadwayd :5 & GDK_BACKEND=broadway > BROADWAY_DISPLAY=:5 guix shell abiword -- abiword > > [1] 4066 > Listening on /run/user/1000/broadway6.socket > > (abiword:4094): Clutter-Gtk-ERROR **: 13:31:52.255: *** Unsupported > backend. > > $ guix describe --format=channels > (list (channel >(name 'guix) >(url "https://git.savannah.gnu.org/git/guix.git;) >(branch "master") >(commit > "3657b4daeafab8d3935191d57653b8331e395897") >(introduction > (make-channel-introduction >"9edb3f66fd807b096b48283debdcddccfea34bad" >(openpgp-fingerprint > "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A > 54FA") Works for me with (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git;) (branch "master") (commit "b86867417fa76384eae76fcef099cf4d133bb20d") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA") and $ guix shell gtk+:bin -- broadwayd :5 & $ GDK_BACKEND=broadway BROADWAY_DISPLAY=:5 guix shell abiword -- abiword $ icecat http://localhost:8085 -- Ricardo
Re: OnlyOffice?
Yasuaki Kudo writes: > For our IT worker cooperative in preparation, one of my areas of > interest is the realistic partial alternative to Google and Microsoft > office suite, for a specific market segment. […] Is this for an Office suite accessible throught the web browser? > Has anyone here tried to build or assess the possibility of Guix > package for OnlyOffice? I hadn’t heard of OnlyOffice before, so I don’t know. But if you want web access there may be a way to use the existing Office suite packages and expose them through the browser. GTK+ comes with broadwayd, which lets you use the browser to render the GUI. Here’s a quick example: guix shell gtk+:bin -- broadwayd :5 & GDK_BACKEND=broadway BROADWAY_DISPLAY=:5 guix shell abiword -- abiword Then visit http://127.0.0.1:8085/ in your browser. -- Ricardo
Re: locales do not work
t...@envs.net writes: > i am using guix on debian (installed with the installer from apt) > the trouble is that some programs don't translate or can't handle filenames > containing unicode and guix prints this warning: >>hint: Consider installing the `glibc-locales' package and defining >>`GUIX_LOCPATH', along these lines: >> guix install glibc-locales >> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" > > even thought i have installed this (and added the letter line to my .profile) > the problem persists. > $GUIX_LOCPATH is indeed accessible: >>$ ls $GUIX_LOCPATH/2.33/$LANG/ Are the programs in question linked with glibc 2.33 or have they been installed with an old version of Guix that came with an earlier version? What’s your locale? -- Ricardo
Re: Retain shell history in a guix container
jgart writes: > Does anyone know how I can retain the shell history in a guix container? Make the shell write its history to a location that exists outside of the container. -- Ricardo
Re: lock files
jgart writes: > Does Guix have a concept of lock files? > > Or, why doesn't Guix need lock files? Guix uses lock files. See for example “call-with-file-lock” in (guix build syscalls). But the question and its answer tells you very little about Guix. -- Ricardo
Re: How to get versionless URL of package on Guix?
kiasoc5 writes: > The url for packages on guix.gnu.org/packages/ includes the version > number. > > Is there a URL for a package without a version number? AFAIK there is not, but we could generate it by changing the code for the website: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages -- Ricardo
Re: How can I upgrade all the packages in my default profile?
jgart writes: > guix upgrade * or guix upgrade '*' don't work for me :( Just “guix upgrade”, according to the manual. It also optionally takes a regular expression, but “*” is not a valid regular expression, so it matches nothing. -- Ricardo
Re: derivation args question
jgart writes:
> What do the four arguments represent here:
>
> Derive([("out","/gnu/store/c6mqyc4db5s0p01dkd3cmklh2n9vbskc-ed-1.16","","")],
> ^ ^^^^ ^^
>
> What do the two arguments represent here:
>
> [("/gnu/store/041ciykg427wkwjy4yjfb5mfv93fvzvp-make-mesboot-3.82.drv",["out"]),
>
“arguments” isn’t quite the right word; derivations are just data, and
the individual sub-structures describe different things, e.g. the
expected outputs when computing the derivation, its inputs, etc. I
suggest using the REPL to explore derivations:
--8<---cut here---start->8---
$ [env] guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> ,use (guix derivations)
scheme@(guix-user)> (read-derivation-from-file
"/gnu/store/71jrsadxb5qpkkzhaszslrpfzwqmpk0b-python-blake3-0.3.1.drv")
$1 = #
/gnu/store/fgm5d5x2v0a0l9vxv706wy0glhi0laz5-python-blake3-0.3.1 7fb0d4560870>
scheme@(guix-user)> (derivation-outputs $1)
$2 = (("out" . #< path:
"/gnu/store/fgm5d5x2v0a0l9vxv706wy0glhi0laz5-python-blake3-0.3.1" hash-algo: #f
hash: #f recursive?: #f>))
scheme@(guix-user)> (derivation-builder-arguments $1)
$3 = ("--no-auto-compile" "-L"
"/gnu/store/yq32nyaywiff5kqc2lx6x91p02syncap-module-import"
"/gnu/store/zix1p80p9w8d2d3v0r7pbxp9lp1kvwp6-python-blake3-0.3.1-guile-builder")
scheme@(guix-user)> (derivation-inputs $1)
$4 = (#< drv: #
/gnu/store/r5f9s153ds84l3zw9bvq2p48cpr6y4bg-module-import-compiled
7fb0d549efa0> sub-derivations: ("out")> #< drv: #
/gnu/store/2vqzhlk85r3nfb6irnb26f3ggxp0130y-python-blake3-0.3.1 7fb0d45608c0>
sub-derivations: ("out")> #< drv: #
/gnu/store/qar3sks5fwzm91bl3d3ngyrvxs7ipj5z-python-3.9.9 7fb0d54af8c0>
sub-derivations: ("out")> #< drv: #
/gnu/store/iw4ka5iqagcj9cb4a5mlmhkfwp1j22vd-python-3.9.9-idle
/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9
/gnu/store/akhfk7wq2i8bkxlv8i6ra10cy0b7iq6l-python-3.9.9-tk 7fb0d5451be0>
sub-derivations: ("out")> #< drv: #
/gnu/store/h9gnccx1wy555k766s4z74jnj5w1yp0z-guile-2.0.14-debug
/gnu/store/hnr4r2d0h0xarx52i6jq9gvsrlc3q81a-guile-2.0.14 7fb0d614f550>
sub-derivations: ("out")>)
scheme@(guix-user)>
--8<---cut here---end--->8---
The module (guix derivations) defines these records and accessors, which
can be used to explore the contents of derivations:
--8<---cut here---start->8---
(define-immutable-record-type
(make-derivation outputs inputs sources system builder args env-vars
file-name)
derivation?
(outputs derivation-outputs) ; list of name/ pairs
(inputs derivation-inputs) ; list of
(sources derivation-sources) ; list of store paths
(system derivation-system) ; string
(builder derivation-builder) ; store path
(args derivation-builder-arguments) ; list of strings
(env-vars derivation-builder-environment-vars) ; list of name/value pairs
(file-name derivation-file-name)) ; the .drv file name
(define-immutable-record-type
(make-derivation-output path hash-algo hash recursive?)
derivation-output?
(path derivation-output-path) ; store path
(hash-algo derivation-output-hash-algo); symbol | #f
(hash derivation-output-hash) ; bytevector | #f
(recursive? derivation-output-recursive?)) ; Boolean
(define-immutable-record-type
(make-derivation-input drv sub-derivations)
derivation-input?
(drv derivation-input-derivation) ;
(sub-derivations derivation-input-sub-derivations)) ; list of strings
--8<---cut here---end--->8---
--
Ricardo
Re: cyrus-sasl-2.1.27.drv No such file or directory
Hi Jérémy, > After the 10 Years Guix, I booted my Guix powered laptop and tried to > upgrade. But here is the error I encountered : > >guix upgrade: erreur : opening file >`/gnu/store/0mslj3djv3fivm0yr8ga190rnpl68r4q-cyrus-sasl-2.1.27.drv': >No such file or directory Consider running “guix gc --verify=repair,contents” to be sure that there is no corruption in the store. -- Ricardo
Re: Why is the scheme record needed?
jgart writes: >> It is a Scheme representation of a derivation, which also has an on-disk >> representation. > > Why was the scheme representation of a derivation needed? You can search the “guix” directory in the source tree for “derivation-” to see the many ways that we’re accessing parts of the Scheme representation of derivation files. We’re accessing the expected output location, the list of inputs, we using its fields to build narinfos, etc. The only alternative is to hit the disk every time we want to know something about a derivation and parse the file repeatedly. That would be very unwise. >> Everything that the daemon is asked to build must be compiled to a >> derivation on disk first. From the perspective of the daemon there are >> no first-class packages, only derivations. Much of what Guix as a >> library does is to turn package values into derivation files and >> builders to feed them into the daemon. > > Why are the bags needed? What do the bags solve in the system? The manual says: --8<---cut here---start->8--- Under the hood, build systems first compile package objects to “bags”. A “bag” is like a package, but with less ornamentation—in other words, a bag is a lower-level representation of a package, which includes all the inputs of that package, including some that were implicitly added by the build system. This intermediate representation is then compiled to a derivation (*note Derivations::). --8<---cut here---end--->8--- Bags are an implementation detail. -- Ricardo
Re: Cuirass still there after removing and reboot
Hi Olivier, > I've removed the cuirass service from my operating system configuration. > After rebooting and many generations later, I still see cuirass in the > root's services. I have to manually do `sudo herd stop cuirass` at > every boot.. > > Any idea? I suggest looking at the system service graph with “guix system shepherd-graph” or “guix system extension-graph” to see where it comes from. -- Ricardo
Re: How does a gexp relate to a derivation?
jgart writes: > On Sat, 17 Sep 2022 17:43:17 +0200 Ricardo Wurmus wrote: >> ;;; >> ;;; 2. Gexps embed information about the derivations they refer to. > > Why do gexps embed information about the derivations they refer to? That’s the whole point. Otherwise you could just use quasiquote / unquote. I recommend the paper on Gexps that walks you through the alternatives and motivates the design of Gexps: https://hal.inria.fr/hal-01580582/en -- Ricardo
Re: Why is the scheme record needed?
jgart writes: > Why is the scheme record needed? It is a Scheme representation of a derivation, which also has an on-disk representation. > How does it function in Guix? Everything that the daemon is asked to build must be compiled to a derivation on disk first. From the perspective of the daemon there are no first-class packages, only derivations. Much of what Guix as a library does is to turn package values into derivation files and builders to feed them into the daemon. -- Ricardo
Re: How does a gexp relate to a derivation?
> How does a gexp relate to a derivation? The module comment of (guix gexp) says this: --8<---cut here---start->8--- ;;; This module implements "G-expressions", or "gexps". Gexps are like ;;; S-expressions (sexps), with two differences: ;;; ;;; 1. References (un-quotations) to derivations or packages in a gexp are ;;; replaced by the corresponding output file name; in addition, the ;;; 'ungexp-native' unquote-like form allows code to explicitly refer to ;;; the native code of a given package, in case of cross-compilation; ;;; ;;; 2. Gexps embed information about the derivations they refer to. ;;; ;;; Gexps make it easy to write to files Scheme code that refers to store ;;; items, or to write Scheme code to build derivations. --8<---cut here---end--->8--- -- Ricardo
Re: German language mistake in the answer if I do a : guix package --upgrade --dry-run
Gottfried writes: > "Die folgenden Pakete würden aktualisiert:" > > It should be: > > "Die folgenden Pakete würden aktualisiert werden:" > > It's missing one word at the end: "werden". Both of these sentences are correct here, though the second one is more common in colloqial use. In the first sentence “würde” is the Konjunktiv II form of “werden”, whereas “würde” + inf. verb in the second sentence is a pattern to avoid modification of the verb. Personally, I prefer the first variant, because it is correct grammar and a little more elegant. -- Ricardo
Re: Setting up a development environment for guile-g-golf based software in KDE
Luis Felipe writes: > [[PGP Signed Part:Undecided]] > On Friday, September 2nd, 2022 at 18:30, Luis Felipe > wrote: > >> In my case (guix 16a6cbe), the example doesn't work at all, >> regardless of the desktop environment or whether I use a pure >> environment or container without grafts. > > Hmm, I changed "gtk" to "gtk@4" and now it runs. Which is weird. > > I noticed, though, that there are several GLib-GIO-CRITICAL errors related to > dbus. Adding "dbus" to the package list make them go away. I had to run the guile-gi example under “dbus-launch” to make the errors disappear. guile-gi works fine with grafts and GTK4; g-golf requires grafts to be disabled because it doesn’t address problems with gobject introspection that is triggered by the presence of grafts. -- Ricardo
Re: Setting up a development environment for guile-g-golf based software in KDE
Jérémy Korwin-Zmijowski writes: > I want to build a GUI for Gnome (using guile-g-golf (and gtk)). > > When under Gnome my small "Hello World" (from the manual example > script) window shows up. > > When under KDE (Plasma) nothing shows up but errors in the terminal : > >$ guix shell guile gtk guile-g-golf -- ./hello-world >(guile:10978): GLib-GObject-WARNING **: 12:19:06.388: cannot >register existing type 'GdkPixbuf' >(guile:10978): GLib-GObject-CRITICAL **: 12:19:06.388: >g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE >(instance_type)' failed >(guile:10978): GLib-GObject-CRITICAL **: 12:19:06.388: >g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE >(instance_type)' failed >(guile:10978): GLib-CRITICAL **: 12:19:06.388: g_once_init_leave: >assertion 'result != 0' failed When using g-golf make sure to disable grafts: guix shell --pure --no-grafts \ guile guile-g-golf gtk@4 The same problem was found in guile-gi first: https://github.com/spk121/guile-gi/issues/96 -- Ricardo
Re: Environment issue with guix home, my default guix profile, and loading sbcl-alexandria
jgart writes: > All the sbcl related packages and emacs and emacs-sly packages are installed > via guix home. Are you loading .guix-home/profile/etc/profile to set environment variables? > I have a few emacs packages not related to common lisp installed via my > default profile. > > On the Ubuntu laptop, sbcl cannot find the alexandria package. Sounds like a search path problem. -- Ricardo
Re: Enterprise Guix Hosting?
"Thompson, David" writes:
>> Using a shared /gnu/store as a big cache for all containers can be a
>> real asset. We can learn lessons from the HPC experience here.
>
> What might have a positive impact is if Guix had an answer to 'docker
> compose'. Most of the pieces are there already. Such a tool could be
> combined with 'guix shell' so you could get all the tools needed for
> local development *and* automatically start any necessary daemons,
> like database servers, in isolated containers.
Yes, this would be useful.
Another thing that seems to be missing is a way to supervise and manage
running containers. I use a shepherd instance for this with
container-specific actions like this:
(define %ip
(let ((loc #f))
(lambda ()
"Return the absolute file name of the ip command."
(or loc
(let ((value (which "ip")))
(set! loc value)
value)
(define (launch container-id script)
(herd "root" "eval"
(format #false
"~s"
`(begin
(use-modules (srfi srfi-2)
(ice-9 popen)
(ice-9 rdelim)
(ice-9 match))
(define (guix-container id script)
(make
#:provides (list
(string->symbol (string-append "guix-container-"
id)))
#:docstring "Run a Guix System container"
#:start
;; TODO: Using /bin/sh -c is ugly, but
;; without it the container would be stuck in the early boot
process.
(make-forkexec-constructor
`("/bin/sh" "-c" (string-join (list "exec" script ,@args)
#\space)))
#:stop (make-kill-destructor)
#:actions
(make-actions
(pid
"Show the PID of the system container."
(lambda (running)
(let ((pid (call-with-input-file
(format #false "/proc/~a/task/~a/children"
running running)
read)))
(display (match pid
((? eof-object?) "")
(_ pid))
(ip
"Show the IP address of the system container."
(lambda (running)
(let* ((pid (number->string
(call-with-input-file
(format #false
"/proc/~a/task/~a/children"
running running)
read)))
(ns (format #false "guix-~a" pid))
(ip ,(%ip))
(address
(catch #true
(lambda ()
(let* ((pipe (open-pipe* OPEN_READ
ip "netns" "exec" ns
"ip" "-o" "-4"
"-family" "inet"
"addr" "show"
"dev" (format #false
"ceth-~a" pid)))
(output (read-line pipe)))
(match (string-tokenize output)
((number if "inet" ip . rest) ip)
(_ ""
(lambda _ ""
(display address
(up
"Connect network for the system container."
(lambda (running)
(let* ((pid (number->string
(call-with-input-file
(format #false
"/proc/~a/task/~a/children"
running running)
read)))
(ns (format #false "guix-~a" pid))
(host (format #false "veth-~a" pid))
(client (format #false "ceth-~a" pid))
(ip ,(%ip))
(sys (lambda args
(or (zero? (apply system* args))
(error args)
;; Make existing network namespace available to ip netns
(sys ip "netns" "attach" ns pid)
;; Create veth pair and move the client side into the
container.
(sys ip "link" "add" host "type" "veth" "peer" "name"
Re: Am I doing it all wrong?
jgart writes: > Hi, > > This is what I do to work on GNU Guix on a foreign distro: > > git clone https://git.savannah.gnu.org/git/guix.git > > cd guix > guix shell -D guix --container -- ./bootstrap > guix shell -D guix --container -- ./configure --localstatedir=/var > guix shell -D guix --container -- make > guix shell --container --network coreutils vis ripgrep rlwrap -D guix > --share=/var/guix/ > > Should I be doing anything differently in the above for setting up a dev > environment for guix hacking? Why do you keep exiting and entering the container for each command? And: why use a container at all when “guix shell --pure” would be more than enough? I’d just start a new shell *once* and then run the commands inside of the shell session. -- Ricardo
Re: Enterprise Guix Hosting?
Hi Yasu > Our idea is at the coop is that we want to develop software > development acceleration tools, and a major part would be > container-less software provisioning so that composition would not > mean more and more layers of technical debt... Don’t discount containers too soon. Guix has “guix system container”, which spins up lightweight Guix System containers that share /gnu/store. You only need to set up a bridge interface on the host and create a network device pair and move one end into the container’s net namespace. You can do containers and compose them without layers upon layers of file system blobs. The reasons why this is not commonly done on existing commercial platforms: - container images are often provided from different origins, so there is no trust and thus no way to have them share the same files or common packages - without reproducible builds trust cannot be established - container images are erroneously considered a requirement for isolation, but it is not actually required to use them even in the presence of an unshared mount namespace. Using a shared /gnu/store as a big cache for all containers can be a real asset. We can learn lessons from the HPC experience here. -- Ricardo
Re: Two copies of same library in store after cleaning generations and gc
"Mike Jones" writes: > If I rebuild my profile with --no-grafts, the mesa used by programs and > the one in the profile are the same, so I'll just put this down to some > weirdness with grafting. This sounds like grafts working as intended. Do you also have more than one instance of icecat – one using the graft and one without? (Due to deduplication in /gnu/store this is not as wasteful as it may seem.) -- Ricardo
Re: "user with UID not found" error
Christopher Batten writes: > So my sysadmin and I are worried about turning on caching in NSCD and > SSSD at the same time? Are you running both and have you seen any > issues? We have been running SSSD and NSCD together since a number of years on all cluster nodes and all RHEL servers. There haven’t been any problems due to caching. I suppose you could also configure NSCD to cache entries only for a second to force it to talk to SSSD more often. We never felt the need to change the default configuration. -- Ricardo
Re: "user with UID not found" error
Hi Chris, >>> Or do you recommend a different way to run NSCD and SSSD at the same time >>> on RHEL/CentOS systems? >> >> You only need to start it. We don't use it as a cache. We are only >> interested in its network interface for use with glibc. […] > We turned off all NSCD caching: > > % grep enable-cache /etc/nscd.conf > # enable-cache > enable-cachepasswd no > enable-cachegroup no > enable-cachehosts no > enable-cacheservicesno > enable-cachenetgroupno Sorry, it appears that I was wrong about the role of caching. Our cluster nodes (running CentOS) have this nscd config: --8<---cut here---start->8--- enable-cache passwd yes enable-cache group yes enable-cache hosts no enable-cache netgroup no --8<---cut here---end--->8--- So while we don’t rely on caching per se, nscd needs to be configured to cache passwd and group so that it actually fetches this type of information from the system directories (e.g. LDAP). Sorry for the confusion! -- Ricardo
Re: "user with UID not found" error
>Or do you recommend a different way to run NSCD and SSSD at the same time on >RHEL/CentOS systems? You only need to start it. We don't use it as a cache. We are only interested in its network interface for use with glibc. -- Ricardo
Re: Correct way to install perl-anyevent-i3?
Chris Keschnat via writes: > So I added =perl-anyevent-i3= to the package definition (in the > =operating-system=). > After a =guix system reconfigure= and a reboot, =i3-save-tree= is still > giving the same error. > > There seems to be something wrong with the load path > (I don't know perl terminology, but I hope it is clear what I mean). You’ll need to add this to the Perl load path, which is controlled with the PERL5LIB environment variable. When Perl is installed in the same profile this variable will be set automatically. -- Ricardo
Re: Old packages in GUIX under Debian stable
Alexander Asteroth writes: > I verified that the version of the guix binary is from my current > profile, the environment variables are freshly set from current > profile as well. Do you mean the ~/.config/guix/current profile or some other profile? What does “type guix” say? And what does “guix describe” say? -- Ricardo
Re: "user with UID not found" error
Hi Christopher, > Turns out we are using SSSD not NCSD on our Linux systems. It seems to be > working fine: You will need to run NSCD if you want Guix software to be able to talk to the system’s SSSD. The reason is that SSSD works by having applications load a library whereas NSCD implements a network protocol. Software built with Guix cannot load the system libary due to ABI conflict, but it *can* talk to NSCD over the network. The system NSCD talks to the system SSSD, so there’s no problem there. -- Ricardo
Re: "user with UID not found" error
Hi Christopher, > I am a new guix user, and we are enjoying using guix our research and > teaching. However, ever since I installed guix on our server I have been > seeing this error: > > % guix pull > user with UID 317241 not found You need to run the system’s nscd daemon. -- Ricardo
Re: fixing sticky package
András Vöröskői writes: > I do not use bash. My fish config.fish has the following relevant lines: > set GUIX_PROFILE $HOME/.config/guix/current; fenv source > $GUIX_PROFILE/etc/profile > set GUIX_PROFILE $HOME/.guix-profile; fenv source $GUIX_PROFILE/etc/profile > > fenv is just a wrapper, so fish can handle bash scripts. etc/profile sets variables differently dependent on whether $GUIX_PROFILE is set or not. This appears to be the problem here, because you say that “which” returns a location in /gnu/store (instead of ~/.guix-profile). If you can see /gnu/store/… in the output of “env” that’s the cause of the problem. -- Ricardo
Re: fixing sticky package
Hi András, > I have done something like this: > 1. I have zig@0.10 installed in my profile. > 2. Started a guix shell -m guix.scm which has zig@0.9 > 3. Run zig version and it reported 0.10.0 What does your ~/.bashrc look like? What does “guix shell --check” say? > However when I run `which zig` it finds `zig` in /gnu/store. This indicates that GUIX_PROFILE was not set when the environment variables in etc/profile were set. When GUIX_PROFILE is set the environment variables are set relative to the location it specifies; when it is not set the /gnu/store locations will be used, which is rarely what you want. -- Ricardo
Re: Finding Dependencies at Run Time
"Philip McGrath" writes: > On Thu, Jul 14, 2022, at 4:25 AM, Ricardo Wurmus wrote: >> Peter Polidoro writes: >> >>> Your explanations are very helpful, thank you, and your links made me >>> realize that devel version of the manual has lots of information that >>> I could not find in the stable version of the manual. >> >> We recommend using the manual that comes with Guix, because it matches >> the particular version of Guix you have installed. You can use any Info >> reader to view the manual and the cookbook. >> > > I mentioned this somewhere before, but I would love to be able to install a > local copy of the HTML manual with the nice styling used on the website. You can build all HTML and PDF versions of the manual with ./pre-inst-env guix build -f doc/build.scm from a Guix checkout. This will take a little while. The convenience of using the Info document is that it is installed with “guix pull”, so it will always match your current version of Guix. The Info document is also more accessible than the HTML version because of the manually curated index (hit “i” in your Info reader and type away to get to a topic more quickly). -- Ricardo
Re: Finding Dependencies at Run Time
Peter Polidoro writes: > Your explanations are very helpful, thank you, and your links made me > realize that devel version of the manual has lots of information that > I could not find in the stable version of the manual. We recommend using the manual that comes with Guix, because it matches the particular version of Guix you have installed. You can use any Info reader to view the manual and the cookbook. -- Ricardo
Re: gajim FAILS
jgart writes: > On Wed, 13 Jul 2022 20:13:11 -0500 jgart wrote: > > Here's some new error output from Gajim: > > λ ps aux | grep gajim > jgart 990 11.3 0.9 636060 148352 ? Sl 21:24 0:04 > /gnu/store/1m48ama708vh9cjn79yw6cj8sgg7pa1b-python-wrapper-3.9.9/bin/python > /gnu/store/40m247zwdlb2pfasla7limgxs7zqawzq-gajim-1.4.6/bin/.gajim-real > jgart 1043 0.0 0.0 6472 2296 pts/0S+ 21:25 0:00 grep gajim > λ kill -9 990 > λ gajim > unsupported locale setting > No translations found for en_US What is your locale? Have you set GUIX_LOCPATH? -- Ricardo
Re: Why do we force the lazy python?
jgart writes: > Why do we check if python is a promise and then "force" it? See the comment in this definition: (define package-with-python2 ;; Note: delay call to 'default-python2' until after the 'arguments' field ;; of packages is accessed to avoid a circular dependency when evaluating ;; the top-level of (gnu packages python). (package-with-explicit-python (delay (default-python2)) "python-" "python2-" #:variant-property 'python2-variant)) -- Ricardo
Re: package exists but not showing
Andy Tai writes: > Hi, I am running the latest mainline guix on top of Fedora. After doing > > guix pull && guix package -u > > I run into this situation: > > $ hash guix > $ which firefox > ~/.guix-profile/bin/firefox > $ guix show firefox > guix show: error: firefox: package not found > $ guix package --list-installed|grep firefox > firefox 100.0.2 out > /gnu/store/wmlyxw4jx2d75cwn2hv5g99b61jwpinz-firefox-100.0.2 > $ > > I wonder if this is a valid state for guix? It is a valid state. You could for example do this: guix time-machine -C channels-with-firefox -- install firefox That would install firefox into your profile, but when you then do “guix show firefox” it would print an error, because *this* Guix doesn’t know anything about the “firefox” package. What is installed is separate from what Guix knows about. All this tells you is that the package you installed was provided by a different version of Guix (with possibly different channels) than the version of Guix you are using to run “guix show”. -- Ricardo
Re: hpcguix-web
Gottfried writes: > if I install hpcguix-web and add it in my config.scm > > what is the difference and the benefits to look up my packages in the > browser > https://hpc.guix.info/browse? The primary purpose for this is visibility and outreach. People who don’t use Guix yet can see what packages the latest version of Guix has to offer. We’re using it for the Guix HPC project, which is a project to popularize Guix in scientific computing environments. You can get the same information on the command line or with the Emacs interface. There is no other advantage. -- Ricardo
Re: Modular texlive and xelatex
Andreas Enge writes: > Hello, > > I am considering moving from the monolithic texlive distribution > (which is not easy to update with an essentially full hard drive...) > to the modular one, but do not find >share/texmf-dist/tex/xelatex/xunicode/xunicode.sty > > Does anyone know if this exists in some package? The tlpdb says that this file is provided by the xunicode package – which we don’t have yet. [time passes] We now have texlive-xunicode as of commit 793ce82c9d5ead8457da9cec8d1d8afc12704f10. -- Ricardo
Re: Web Browsers Report being "Unable to Connect" after Wi-Fi Connection Drop Period
"Wamm K. D." writes: > The consequence is that I've noticed a particular behavior relatively > frequently: when the connection drops, the browser I'm using will get > stuck thinking that it cannot connect to the internet once the internet > connection comes back, sometimes (especially if I tried to load a page > while the internet connection was down). Trying to load any other page > results in the "Unable to Connect" (or equivalent) page. When this happens again, please visit “about:networking#dns” and clear the DNS cache. Maybe this helps. On Guix System there’s also nscd, which has its own cache. It’s possible that a lookup failure is cached there as well. To clear the nscd cache use “sudo herd invalidate nscd”. -- Ricardo
Re: Questions regarding substitutes with debug output
zimoun writes: > Hi, > > On Fri, 29 Apr 2022 at 22:08, Ricardo Wurmus wrote: > >>>> (with-channels %my-channels >>>> (package >>>> (name "yay") >>>> … >>>> (inputs >>>> (list foo bar baz)) ;these are all looked up in %my-channels > > [...] > >> We already have all the tools for WITH-CHANNELS — that’s (guix >> inferior). We just don’t have a convenient syntax to do this without a >> lot of boilerplate. > > Indeed. Where %my-channels would refer to a channels.scm file, right? A list of channels rather than a file. > What seems still missing is a way to select these variants from the > channel. > > I am proposing to somehow add a field to ’properties’. WDYT? Can we not infer this when adding package modules to the load path? Doing this once per channel seems better than having channel maintainers add this to every package. -- Ricardo
Re: A package search engine for a curated list of channels
Mekeor Melire writes: > An alternative would be to implement some kind of isolation. But > channels and package declarations are just scheme/guile code, so they > will probably always be able to run arbitrary commands on the server. Guile has some sandboxing features. It would be an option to evaluate channel modules in a restricted environment with (ice-9 sandbox). That would benefit all of Guix. > Another approach would be isolation. For each channel, we could run > hpcguix-web inside a Docker-container so that there's some isolation. > Then, we'd need to run another web-service which "bundles" the > packages.json files of all single-channel, dockerized hpcguix-web > instances. But: > > (1.) Does Docker really offer sufficient isolation? No more than “guix shell -C”. There’s no good reason to use Docker when you already have Guix. The Docker service exists for when you have a Docker container image that you must use, not because its containerization is superior to “guix shell -C”. -- Ricardo
Re: Questions regarding substitutes with debug output
Olivier Dion writes: > On Fri, 29 Apr 2022, Ricardo Wurmus wrote: >>> Even if I were to import locally defined packages, their dependencies >>> would come from the Guix's main channel! >> >> What would you think about WITH-CHANNELS that would accept a list of >> channels and evaluate any package reference in its body within an >> inferior of those channels? >> >> E.g. >> >> (with-channels %my-channels >> (package >> (name "yay") >> … >> (inputs >> (list foo bar baz)) ;these are all looked up in %my-channels >> … >> (license gpl3+))) > > What about dependencies? Says I have the following graph: > > G <- Guix's channel > C <- My channel > > P@V <- My package at version V from C > D@U <- Dependency of P at version U from G > > The `guix time-machine` allows me to pin the commits of G and C and thus > pinning V and U. Would that work the with WITH-CHANNELS ? Exactly the same way. The first argument to WITH-CHANNELS would be (cons C G) and thus P and D would be picked from the set of C and G. C and G can be specified with exact commits or branches, just like the --channels option to “guix time-machine”. We already have all the tools for WITH-CHANNELS — that’s (guix inferior). We just don’t have a convenient syntax to do this without a lot of boilerplate. -- Ricardo
Re: Questions regarding substitutes with debug output
Olivier Dion writes: > On Fri, 29 Apr 2022, zimoun wrote: >> Hi Olivier, >> >> On Thu, 28 Apr 2022 at 10:11, Olivier Dion via wrote: >>> On Thu, 28 Apr 2022, zimoun wrote: >> >>> In my case, I prefer to avoid using package object directly. As >>> mentioned in GWL' manual, the version of Guix running GWL and the >>> version of Guix used by GWL (the inferior) might not be the same. Thus, >>> it is not okay for reproducibility in the long term. In my case, I use >>> `guix time-machine --channels` as the inferior. >> >> You wrote: >> >> I need to specify the package programmatically as a string in >> Guile. More specifically in the process packages field of Guix >> Workflow Language. >> >> so I do not understand why it would be an issue to deal with the package >> instead of the specification string. Because your need seems «to >> specify the package programmatically». :-) > > Because importing the package using use-modules would yield the package > from the instance of Guix driving the workflow instead of using the > package of the inferior! GWL will lookup for package in the inferior > context when the package is a specification. > > Even if I were to import locally defined packages, their dependencies > would come from the Guix's main channel! What would you think about WITH-CHANNELS that would accept a list of channels and evaluate any package reference in its body within an inferior of those channels? E.g. (with-channels %my-channels (package (name "yay") … (inputs (list foo bar baz)) ;these are all looked up in %my-channels … (license gpl3+))) -- Ricardo
Re: Questions regarding substitutes with debug output
Olivier Dion writes: > On Thu, 28 Apr 2022, Ricardo Wurmus wrote: >> Olivier Dion writes: >> >>> In my case, I prefer to avoid using package object directly. As >>> mentioned in GWL' manual, the version of Guix running GWL and the >>> version of Guix used by GWL (the inferior) might not be the same. Thus, >>> it is not okay for reproducibility in the long term. In my case, I use >>> `guix time-machine --channels` as the inferior. >> >> The process itself could specify channels to use for its environment. >> Then it would be self-contained and reproducible without having to rely >> on time-machine. > > Is this already supported in GWL? I'm not sure if I understand how you > would do this. How would it be different from using time-machine? It is not yet supported in GWL, but it would only be a small change. The GWL has support for inferiors but currently only uses the “invoking” Guix for packages. We could use a different set of channels per process definition. Each process runs in its own environment; it doesn’t have to be all done with the same version of Guix. Whether or not to support this is merely a question of how easily workflows and processes can be reused or integrated in other workflows. -- Ricardo
Re: Questions regarding substitutes with debug output
Olivier Dion writes: >> Therefore, since your question is rooted from GWL: >> >> I need to specify the package programmatically as a string in >> Guile. More specifically in the process packages field of Guix >> Workflow Language. >> >> maybe GWL could also accept a symbol instead of a name string. Well, I >> have not used GWL since many months and I do not remember but I think it >> is doable. Ricardo? > > In my case, I prefer to avoid using package object directly. As > mentioned in GWL' manual, the version of Guix running GWL and the > version of Guix used by GWL (the inferior) might not be the same. Thus, > it is not okay for reproducibility in the long term. In my case, I use > `guix time-machine --channels` as the inferior. The process itself could specify channels to use for its environment. Then it would be self-contained and reproducible without having to rely on time-machine. -- Ricardo
Re: Questions regarding substitutes with debug output
zimoun writes: > Therefore, since your question is rooted from GWL: > > I need to specify the package programmatically as a string in > Guile. More specifically in the process packages field of Guix > Workflow Language. > > maybe GWL could also accept a symbol instead of a name string. Well, I > have not used GWL since many months and I do not remember but I think it > is doable. Ricardo? GWL accepts specifications or package values, so you could use (@ (my packages foo) gcc) to prefer that over some other package with the same name. -- Ricardo
Re: A package search engine for a curated list of channels
Hi Mekeor, > it would be nice to be able to search for a package (and/or a service) > by name or description etc. through many channels. AFAIK, there's no > such search engine yet. Please correct me if I'm wrong. > > I'm considering to implement it. I'd suggest to approach it with a > server where (1) Guix is installed; (2) a long list of channels is > activated; (3) a cron-job or so which regularly runs `guix pull`; (4) a > web-api-service written in Guile which leverages the Guix-library in > order to search for packages (-- I guess it'd be calling the > `guix-package*` function from /guix/scripts/package.scm?); (5) a > simplistic front-end web-site which talks to the web-api. See https://github.com/UMCUGenetics/hpcguix-web. It handles the constant updates to all Guix channels and the search. You’re welcome to contribute to it, e.g. to add an API, suggest changes in how results are displayed, etc. An example deployment can be found at https://guix.mdc-berlin.de Guix has a service for it that makes deployment easy. You’ll see that it lists packages from guix-science and other channels, e.g. https://guix.mdc-berlin.de/package/rstudio-server -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Vagrant Cascadian writes: > My best guess is some difference in actual board model, card model, etc. > > $ lspci > 00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express > Root Port > 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA > Controller (rev 02) My SATA controller differs: 01:00.0 SATA controller: JMicron Technology Corp. Device 0585 It’s good to know that it works for a different PCIe card. Maybe I can find some more information about the differences. > Is your board a v2.1 ? The version is clearly printed on the board next > to the CPU. I'm not sure what the differences are with the v2 model, or > if there are newer variants. Yes, my board is V2.1 from 2018. -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Hi Vagrant, > On 2022-04-02, Ricardo Wurmus wrote: >> Vagrant Cascadian writes: >>> I was able to get it to work! With your updated patch to disable openssl >>> (and rebasing against newer u-boot), and the phase modifying the config >>> and the the rockchip include file to add support for SCSI devices. >>> >>> The netbsd patches weren't needed with 2022.04-rc5. >> >> Oh, that’s great! > > It really is, thanks for getting it as far as you did! > > Although very mildly disappointed that this might deprioritize making > split /boot in guix a reality. :) > > >> Do you have patches for the u-boot upgrade that I could test? > > https://www.aikidev.net/~vagrant/guix/u-boot-2022.04-rc5-with-rockpro64-scsi.patch Thank you! >> Are you using a PCIe card with your rockpro64? > > Yup. Pretty sure it's whatever PCIe dual-port sata card I bought right > along with the rockpro64. I’ve got that one, too. > U-boot is still on microSD, but it loads the kernel+initrd+dtb from > SCSI. The scsi target ends up pretty low in the boot order, so you have > to either manually set the boot_targets or make sure your mmc/nvme > devices aren't bootable (e.g. change partition type, rename boot > extlinux.conf, etc.): > > Hit any key to stop autoboot: 0 > => printenv boot_targets > boot_targets=mmc1 mmc0 nvme0 scsi0 usb0 pxe dhcp sf0 > => setenv boot_targets scsi0 > => boot > scanning bus for devices... > SATA link 0 timeout. > Target spinup took 0 ms. > AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode > flags: 64bit ncq stag led clo pmp pio slum part ccc sxs > Device 0: (1:0) Vendor: ATA Prod.: Faspeed F510-120 Rev: O080 > Type: Hard Disk > Capacity: 114473.4 MB = 111.7 GB (234441648 x 512) > > Device 0: (1:0) Vendor: ATA Prod.: Faspeed F510-120 Rev: O080 > Type: Hard Disk > Capacity: 114473.4 MB = 111.7 GB (234441648 x 512) > ... is now current device > Scanning scsi 0:2... > Found /boot/extlinux/extlinux.conf > Retrieving file: /boot/extlinux/extlinux.conf > Ignoring unknown command: UI > 1: GNU with Linux-Libre 5.17 > Retrieving file: > /gnu/store/fxrc92smbx16k29fw8yz1s0mi7nslnan-raw-initrd/initrd.cpio.gz > Retrieving file: > /gnu/store/z5kqlcqf4r0hpyj6cdkcylh3gmcp4x9x-linux-libre-5.17/Image > append: root=/dev/sda2 > gnu.system=/gnu/store/fz4g427hcdjp70wh7rjh88vrvwi8r5yp-system > gnu.load=/gnu/store/fz4g427hcdjp70wh7rjh88vrvwi8r5yp-system/boot > modprobe.blacklist=usbmouse,usbkbd quiet > Retrieving file: > /gnu/store/z5kqlcqf4r0hpyj6cdkcylh3gmcp4x9x-linux-libre-5.17/lib/dtbs/rockchip/rk3399-rockpro64.dtb Hmm, unfortunately, this is not working for me :( I applied the patch, built u-boot-rockpro64-rk3399 with ./pre-inst-env guix build u-boot-rockpro64-rk3399 and got /gnu/store/xw7nyd0fvg9rlsyhxbbk0hg5k18q5pd9-u-boot-rockpro64-rk3399-2022.04-rc5 I then wiped the old partitions on the microsd card with sudo wipefs -f -a /dev/sdb and copied the two files with dd: export where=/gnu/store/xw7nyd0fvg9rlsyhxbbk0hg5k18q5pd9-u-boot-rockpro64-rk3399-2022.04-rc5 sudo dd seek=64 obs=512 conv=notrunc if=$where/libexec/idbloader.img of=/dev/sdb sudo dd seek=16384 obs=512 conv=notrunc if=$where/libexec/u-boot.itb of=/dev/sdb sudo sync Moved the microsd to the rockpro64 slot and powered it on. u-boot comes up in the expected version, and since it successfully fails to boot from the microsd card it falls through to scanning for SCSI devices. Immediately after listing connected devices (even when none are connected to the PCIe card) a long error message appears, the display goes blank, and the CPU seemingly gets stuck. I can reliably reproduce this by typing on the u-boot console: pci enum scsi scan I don’t think the PCIe card is broken, because I can use it just fine after booting from USB. Maybe I made a mistake that would seem really obvious to others? -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Vagrant Cascadian writes: >> I think it should be possible to patch u-boot to initialize the PCIe >> card and boot from the attached disk (with the patched u-boot residing >> on the microsd card). I tried the relevant subset of the netbsd >> patches, but the CPU keeps resetting after (successfully) enumerating >> the PCI devices. >> >> I hope I can make some more time for this soon and overcome that last >> hurdle — and then write a cookbook entry for all this :) > > I was able to get it to work! With your updated patch to disable openssl > (and rebasing against newer u-boot), and the phase modifying the config > and the the rockchip include file to add support for SCSI devices. > > The netbsd patches weren't needed with 2022.04-rc5. Oh, that’s great! Do you have patches for the u-boot upgrade that I could test? Are you using a PCIe card with your rockpro64? -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Hi Vagrant, > On 2022-03-02, Ricardo Wurmus wrote: >> I got myself a rockpro64 board. > ... >> So I then decided to build my own system and install a new u-boot onto >> the microSD card. Here’s the system I built: > ... >> (bootloader (bootloader-configuration >>(bootloader u-boot-rockpro64-rk3399-bootloader) >>;; SD card/eMMC (SD priority) storage >>(target "/dev/mmcblk1"))) > > You need to leave a pretty generous gap at the partition table of your > microSD, either a GPT partition table with various partitions for the > various u-boot bits: > > http://opensource.rock-chips.com/wiki_Partitions > > or an MBR partition table with the first partition starting at sector > 32768, and the previous sectors empty. > > Otherwise, the u-boot installation may clobber parts of your partition > table or vice-versa. Thank you, this was interesting. I still don’t quite understand how the partition layout relates to what Guix does when it writes the files to the offsets. I tried building this exact partition table (the default settings of partitioning tools force some other sector alignment, which makes this impossible without overriding alignment settings in expert mode) and then used dd to write the u-boot files to the partitions, but I wasn’t successful as the microsd card seemed not to work at all. Using dd to copy the two files to the expected offsets did let me into u-boot and allowed me to boot from USB. I haven’t yet tried putting the system on a partition on the microsd card, because I’m still confused about how I should build the partition table. > Also, if you have a different u-boot installed to SPI or eMMC, those > will take priority over microSD on most rockchip platforms. Good to know. No u-boot has been installed to SPI yet. >> Does it perhaps install the u-boot files at the wrong offsets? How >> would I begin to debug this? > > It is also entirely possible something is wrong with rockpro64 u-boot > offsets or u-boot itself ... been a while since I've tested. When I used the same offsets with dd it works fine. So I’m clearly missing some information about how to prepare the microsd card. -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Hi, >> I mounted the target disk (an SSD) at /mnt, made sure that the microSD >> card was inserted, unmounted, and available at /dev/mmcblk1, and then >> ran >> >>guix system init config.scm /mnt >> >> This was successful. >> >> Unfortunately, rebooting failed. There is seemingly no activity at all >> when I power on the board, so something’s not right with how u-boot was >> installed on the microSD card. >> >> Does it perhaps install the u-boot files at the wrong offsets? How >> would I begin to debug this? >> >> I’d appreciate any hints. > > Sorry, I don't have any clue to offer, but were you able to solve or > workaround your problem? Not quite, but I’ve learned more and understand the problem better. I manually copied the two u-boot files to the expected offsets on the microsd card, and that let me boot Guix System from USB. But I have so far been unsuccessful in my attempts to do this automatically as part of “guix system init” (I haven’t tried this much) or to successfully patch u-boot to boot from the SSD on the PCIe card (I have tried this a lot). My next step is to attempt to install the whole system onto the microsd card, just to end up with a usable system. If that works then nothing is wrong with Guix (except for a lack of documentation), but it would be a disappointing workaround. I think it should be possible to patch u-boot to initialize the PCIe card and boot from the attached disk (with the patched u-boot residing on the microsd card). I tried the relevant subset of the netbsd patches, but the CPU keeps resetting after (successfully) enumerating the PCI devices. I hope I can make some more time for this soon and overcome that last hurdle — and then write a cookbook entry for all this :) -- Ricardo
Re: Packaging existing software for Guix
Hi, Cássio Tavares writes: >1. If I submit an issue with a package request, does it take long for >the package to be made available? It can take quite some time when you don’t have someone to review the package. You are welcome to send me issue numbers with your patches and I’ll review them more quickly. >2. Can someone with only a very basic understanding of the Scheme (and >the functional paradigm) package software successfully enough to submit it >to the Guix project? Yes. Ignore the language. Most of the package definition is just data. You can even write a package definition as JSON first and then have Guix convert it to the Guix DSL. >3. Would that be very time-consuming (because my work is in a very >different area)? Is the learning curve steep? It depends on the software. If an application follows well-established conventions it can be trivial to package it. On the other hand, some software can be nearly impossible to package (e.g. Tensorflow 2). Nixpkgs is often not a good template, because more often than not they are cutting corners when it comes to bootstrapping or building from source. >4. As far as I could understand, when defining a package from a git >repository, I have to specify the package version and commit. Does this >mean that I will forever have to check for new versions and edit the >package definition to update it? Yes, just like with any other source code. You can make Guix use a different source with transformations on the command line, but we try to keep things up-to-date. >5. Is there a relatively simple way to port packages from other distros >into Guix? Could this be an automated process? Not from other distros but from upstream repositories; see “guix import”. If you want a fun project you could work on extending “guix import” to import from distro archives. -- Ricardo
Re: Missing LaTeX font (R related)
TK writes: > After some more investigation, I think I narrowed down the > issue. Package texlive-inconsolata indeed installs the `t1-zi4r-0' > font. However, the `map' for that font exists only under dvips, not in > the pdftex subdir. We’re generating these map files based on the contents of the profile. We’re using a profile hook for this. > I am not a TeX magus, but it is indicative that the file on the > official TeXLive repo > https://tug.org/svn/texlive/trunk/Master/texmf-dist/fonts/map/pdftex/updmap/pdftex.map > does contain `zi4' entries. We don’t use that file because it contains *everything*; instead we generate it in a profile hook so that it only contains entries that correspond to what has actually been installed. > Shouldn't the installation of texlive-inconsolata put the > corresponding entries into `pdftex.map'? Yes, it should. > Any hints on where to go from here? When I do guix shell -C texlive-base texlive-inconsolata I see that $GUIX_ENVIRONMENT/share/texmf-dist/fonts/map/pdftex/updmap/pdftex.map contains entries for the inconsolata fonts. (The profile hook depends on texlive-base.) -- Ricardo
Re: Missing LaTeX font (R related)
TK writes: > `!pdfTeX error: pdflatex (file t1-zi4r-0): Font t1-zi4r-0 at 540 not found` > > A web search reveals that t1-zi4r-0 is an inconsolata font, but installing > "texlive-inconsolata" package does not sort this issue out. The texlive-inconsolata package does indeed include that font: /gnu/store/…-texlive-inconsolata-59745/share/texmf-dist/fonts/tfm/public/inconsolata/t1-zi4r-0.tfm > Is granular texlive install even possible on Guix? :) Yes, it is. -- Ricardo
Re: Guix for Corporate "Batch Jobs"?
Phil writes: > I don't think GWL can memoize > different processes in a workflow tho - so running a workflow several > times results in all workflow processes being run, as far as I know. By default GWL caches outputs that have already been computed. Currently there’s only one way to skip computation and that is through files. When a computation results in a file the output is cached; if the output exists already then the computation is not re-rerun unless explicitly requested. (The GWL needs even more caching to avoid recomputing build scripts, but that’s a separate issue.) -- Ricardo
Re: information about new packages in guix available
Hi Gottfried, > I would like to know when new packages, (I don't mean updates to > packages), in guix are available. Whenever you run “guix pull” it will print information about new and updated packages. You should run “guix pull” somewhat regularly anyway, so that you can get fixes for security vulnerabilities. > It would safe time to be informed and not look sometimes at the guix > packages available in https://guix.gnu.org/de/packages/ I suggest using “guix package --list-available” or “guix search” instead. -- Ricardo
Re: Guix website and CI is unavailable in Russia
Ricardo Wurmus writes: > w...@riseup.net writes: > >> I want to ask guix server location and ask is it some kind of ban from >> guix server side or not? Maybe guix server provider or government bans >> some russian ips now. […] > I’ll ask around. At the MDC level there’s an unrelated recent ban of some Russian IP ranges in place due to massively increased port scans and intrusion attempts since about one week. I hope you can use the Chinese mirror for the time being. -- Ricardo
Re: Guix website and CI is unavailable in Russia
Hi, w...@riseup.net writes: > I want to ask guix server location and ask is it some kind of ban from > guix server side or not? Maybe guix server provider or government bans > some russian ips now. On the Guix side we don’t block anyone with a firewall. The data centre is in Berlin and it uses infrastructure of the Deutsches Forschungsnetz (DFN). The DFN has not announced any network wide bans of connection attempts from Russia. The institute hosting the servers is the MDC and it is a member of the Helmholtz Association. The Helmholtz Association announced on February 25 that they would implement unspecified measures to freeze all scientific collaboration with institutions in Russia. I haven’t been informed of any specific decisions in this area, but it is possible that access restrictions have been demanded at that level. I’ll ask around. -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Vagrant Cascadian writes: > [[PGP Signed Part:Undecided]] > On 2022-03-02, Ricardo Wurmus wrote: >> I got myself a rockpro64 board. > ... >> So I then decided to build my own system and install a new u-boot onto >> the microSD card. Here’s the system I built: > ... >> (bootloader (bootloader-configuration >>(bootloader u-boot-rockpro64-rk3399-bootloader) >>;; SD card/eMMC (SD priority) storage >>(target "/dev/mmcblk1"))) > > You need to leave a pretty generous gap at the partition table of your > microSD, either a GPT partition table with various partitions for the > various u-boot bits: > > http://opensource.rock-chips.com/wiki_Partitions > > or an MBR partition table with the first partition starting at sector > 32768, and the previous sectors empty. > > Otherwise, the u-boot installation may clobber parts of your partition > table or vice-versa. Do I need to prepare the microSD card at all? There’s no documentation in the manual, so I have no idea what to do with it prior to “guix system init”. Looking at the code I assumed that the disk-image-installer procedures take care of placing whatever blobs are needed at the expected locations. > Also, if you have a different u-boot installed to SPI or eMMC, those > will take priority over microSD on most rockchip platforms. There is no other u-boot installed. The machine does not show any activity when powered on without microSD card. >> (kernel linux-libre) >> (kernel-arguments >>(list "console=ttyS2")) ; UART2 connected on the Pi2 bus > > I assume you're using a serial console. The rockchip platforms usually > default 150 for baud ... usually I use: > > screen /dev/ttyUSB0 150 > > Oh, now that I think about it, you might also want to set the speed for > your console in kernel-arguments: > >(kernel-arguments > (list "console=ttyS2,150")) I’m not yet using a serial console, but I’ll come back to this later if necessary. >> Does it perhaps install the u-boot files at the wrong offsets? How >> would I begin to debug this? > > It is also entirely possible something is wrong with rockpro64 u-boot > offsets or u-boot itself ... been a while since I've tested. Hmm, okay. Thanks for the hints! -- Ricardo
Re: cannot boot from microSD card on aarch64 machine
Efraim Flashner writes: > Are you sure the primary device is /dev/mmcblk1? On my pine64 it's > mmcblk0. There is no /dev/mmcblk0 when I boot either Guix System (from USB) or armbian (from microsd). /dev/mmcblk1 is the microSD card, at least in a booted system. The device name only matters for the installation of u-boot, doesn’t it? It has no impact on any runtime behavior, or does it? > I'd start by putting u-boot and the image on the sd-card and see if Guix > boots up that way. If it works then there's a larger chance there's a > mistake somewhere in a config. Okay. > Perhaps you need to mark the USB drive as a dependency for your root > partition? I don’t want to boot from USB going forward. I only do this so the microSD card is not used for the system. I want to have u-boot on the microsd card and then boot the system from SSD. > Actually, better idea. Try it with linux-libre-arm64-generic for the > kernel. I haven't tried recently but in the past I haven't been able to > use the linux-libre kernel with my pine64 and needed the arm64-generic > version. Okay, I’ll do that. At least I know that this one works, because that’s what the pinebook pro image uses — and that one works fine (from USB). But at this point I’m not even complaining about the kernel, because nothing at all happens when I power on the machine. U-boot does not seem to start. -- Ricardo
cannot boot from microSD card on aarch64 machine
Hi, I got myself a rockpro64 board. I put armbian (Armbian_21.08.1_Rockpro64_bullseye_current_5.10.60.img) on a microSD card to check that it’s all working correctly. Then I downloaded the latest Guix System image for a pinebook pro and dd’d it to a USB drive. With the armbian microSD card inserted (which contains an old version of u-boot) I can boot from USB into Guix System. So I then decided to build my own system and install a new u-boot onto the microSD card. Here’s the system I built: --8<---cut here---start->8--- (operating-system (host-name "foo") (timezone "Europe/Berlin") (locale "en_US.utf8") (bootloader (bootloader-configuration (bootloader u-boot-rockpro64-rk3399-bootloader) ;; SD card/eMMC (SD priority) storage (target "/dev/mmcblk1"))) (kernel linux-libre) (kernel-arguments (list "console=ttyS2")) ; UART2 connected on the Pi2 bus (file-systems (cons (file-system (device "my-root") (title 'label) (mount-point "/") (type "ext4")) %base-file-systems)) ...) --8<---cut here---end--->8--- The actual system also has one more initrd module, which I can’t remember now, but that shouldn’t matter. I mounted the target disk (an SSD) at /mnt, made sure that the microSD card was inserted, unmounted, and available at /dev/mmcblk1, and then ran guix system init config.scm /mnt This was successful. Unfortunately, rebooting failed. There is seemingly no activity at all when I power on the board, so something’s not right with how u-boot was installed on the microSD card. Does it perhaps install the u-boot files at the wrong offsets? How would I begin to debug this? I’d appreciate any hints. -- Ricardo
Re: Emacs
Hi Gottfried, > leider gibt es bei Guix fast nur Programme in Englisch, wenn man sie > installiert, dann ist die Benutzeroberfläche in Englisch. Wenn ein Programm Übersetzungen mit sich bringt, dann sollte es die Benutzeroberfläche auch z.B. auf Deutsch geben. > Als ich z.B. Manjaro Linux benutzte, habe ich z.B. nach LibreOffice > gesucht und sofort erschien ein zweites Programm, nämlich eine > Übersetzung ins Deutsche. So installierte ich beide und habe ein > LibreOffice in deutscher Sprache. LibreOffice hat soweit ich weiss separate “Sprachpakete”. Ich weiss nicht, ob wir die schon in Guix haben. > Wenn ich ein neues Programm wie Emacs lernen will, dann will ich mich > nicht mit einem englischen Menü herumschlagen, von dem ich wenig > verstehe. Dann habe ich doppelt soviel zu lernen. Leider ist Emacs kaum übersetzt. Weder die Menüs, noch die Handbücher. -- Ricardo
Re: Are Guix and its install script incompatible with guix pack on purpose?
Denis 'GNUtoo' Carikli writes:
> [[PGP Signed Part:Undecided]]
> Hi,
>
> In the installation script we have:
>> if [[ -e "/var/guix" || -e "/gnu" ]]; then
>> _err "${ERR}A previous Guix installation was found. [...]
>> exit 1
>> fi
>> [...]
>> mv "${tmp_path}/gnu" /
>
> Guix pack also install its files in /gnu, so if we somehow installed
> something built with guix pack we can't install Guix anymore.
>
> I've no idea why it's done in this way though as the git history
> doesn't tell and there is no comments either.
>
> Is installing software made with Guix pack incompatible with Guix on
> purpose?
No.
“guix pack -RR” lets you unpack the archive wherever you want, so you
may want to use that.
You cannot have a /gnu/store directory managed by Guix *and also* place
whatever you want there. When Guix manages /gnu/store it will remove
things that it doesn’t know about.
--
Ricardo
Re: installing a package not from GNU
Hi Gottfried, > I wanted to install a package "gtkhash" which I could not find in GNU > packages. > How can I install it? > After downloading it and trying to install it, it said: unknown package > > guix install gtkhash-1.4 > guix install: Fehler: gtkhash-1.4: Unbekanntes Paket Guix only knows of packages for which there is a package definition. There is no package definition for gtkhash. Guix unfortunately cannot just take any tarball and build it. The good news is that writing a package definition (and optionally adding it to Guix) can be straight forward. This is the build system file: https://github.com/tristanheaven/gtkhash/blob/master/meson.build There we see that it needs a bunch of things (like nettle, blake2, zlib, mbedtls, openssl, etc) for which we should have packages. Packaging it may be a little tricky because of the many dependencies, but it looks doable. We could do this together if you want. Another thing I felt the need to clarify: Guix has thousands of packages that are not GNU packages. I think you meant that there is no package definition for gtkhash in gnu/packages/*.scm, which is correct. -- Ricardo
Re: U-Boot for Raspberry Pi
Reza Alizadeh Majd writes: > On Mon, 21 Feb 2022 12:14:50 +0100 > Ricardo Wurmus wrote: > > >> >>mmc-block or mmc_block? > > based on the following thread I thought that it might be the issue with > module name, so I tested with both mmc_block an mmc-block. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34902 > > unfortunately neither of those worked for me and I received the error > message I mentioned before. > >> >>What does the directory contain? If the module doesn’t exist you’ll >>have to build a kernel with a configuration that enables this module. >> > > $ find /gnu/store/*-linux-libre-arm64-generic-5.14.15/lib/modules -name > '*mmc*' > /gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc > /gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc/host/mmc_spi.ko > /gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc/host/of_mmc_spi.ko > > so it seems that the module is actually not available. is that because > of the the libre kernel restrictions? What restrictions? The list of modules depends largely on the kernel configuration. I encourage you to check if you need to add something to the kernel configuration and build your own kernel. -- Ricardo
Re: U-Boot for Raspberry Pi
Reza Alizadeh Majd writes:
> however the previously mentioned issue in this thread about
> the `mmc_block` kernel module still persists during the build:
>
> adding the following kernel modules:
>
> (initrd-modules (append (list "mmc_block" "rtsx_pci_sdmmc" "rtsx_pci")
> %base-initrd-modules))
>
>
> I receive following error:
>
> Backtrace:
>5 (primitive-load "/gnu/store/gdz17k41dvf1b38y9wzs8assi9n?")
> In ice-9/eval.scm:
> 619:8 4 (_ #f)
>626:19 3 (_ #)
>293:34 2 (_ #(# #))
> In srfi/srfi-1.scm:
>586:17 1 (map1 ("mmc-block" "rtsx_pci_sdmmc" "rtsx_pci" "ahci" ?))
> In gnu/build/linux-modules.scm:
> 257:5 0 (find-module-file _ _)
>
> gnu/build/linux-modules.scm:257:5: In procedure find-module-file:
> kernel module not found "mmc-block"
> "/gnu/store/8pms0r4zvqxx6bqaz8rw2h3ynjfynqdx-linux-libre-arm64-generic-5.14.15/lib/modules"
mmc-block or mmc_block?
What does the directory contain? If the module doesn’t exist you’ll
have to build a kernel with a configuration that enables this module.
--
Ricardo
Re: U-Boot for Raspberry Pi
Reza Alizadeh Majd writes: > it seems that the `--system=aarch64-linux` doesn't work as expected to > cross-compile the image for RPi. Are you using qemu-binfmt-service-type? -- Ricardo
Re: Guix OS + Wayland + Gnome Questions
Yasuaki Kudo writes: > I run Wayland + Gnome on my Guix OS. (See attached files for detailed > configuration) > > Q1. How do I Lock Screen? > > Q2. How do I take Screenshots? > > Q3. Should I not bother with Wayland and use X11 (or whatever that's > called that is the default)? I started to use Wayland because > there was significant lag in repeated (that happens automatically when > a key is pressed for a few seconds) keystrokes in terminal > applications. I just went back from Wayland to X11 because with Gnome this all feels too buggy. I had constantly shifting window frames when switching windows, screen blanking whenever I’d watch a video with mpv for long enough, could not use the Gnome screen keyboard, and was no longer able to use peek for recording videos. -- Ricardo
Re: Is mkdir-p a directory outside of /gnu/store.... possible?
James Smith via writes: > I am using the guix package manager on Debian. > I guix package --install-from-file-myapp.scm and during the install process I > would like to > > (mkdir-p "$HOME/.config/myapp") and then > (system* (cp "/gnu/store/.../myapp/config.txt" "$HOME/.config/myapp")) During the build you have no access to anything but the eventual output directory under /gnu/store. -- Ricardo
Re: guix pull
Gottfried writes: > Hinweis: Nachdem Sie `PATH' festgelegt haben, sollten Sie `hash guix' > ausführen, damit Ihre Shell `/root/.config/guix/current/bin/guix' > verwendet. > > What does it mean? > > How do I "PATH"... Your shell (by default that’s GNU Bash) has a few builtin commands, but when you type something like “ls” or “guix” it has to search for an executable of that name on your disk. It searches the directories that are listed on the PATH environment variable. You can see the value of PATH by running echo $PATH This will be a colon-separated list of directories that can be expected to contain executables. When you type “guix” and hit enter your shell visits the directories listed in this PATH variable one by one until it finds an executable with the name “guix”. It then remembers the location so that it doesn’t have to do all that work again. The hint above tells you to put ~/.config/guix/current/bin *first* on the list of directories in the PATH variable, so that when the shell goes to search for “guix” it will look there first and find ~/.config/guix/current/bin/guix — and not /usr/local/bin/guix or whatever else might exist on your disk. Since bash might have already remembered that “guix” corresponds to “/usr/local/bin/guix” you need to tell it to forget about that and look again. That’s what “hash guix” does. You can set PATH permanently by adding or modifying a line in the ~/.bash_profile file, which is read once when Bash starts. Or you can set it just in the current shell session. In any case, setting this variable is done like this: export PATH=/home/gottfried/.config/guix/current/bin:$PATH This changes the value of PATH so that “/home/gottfried/.config/guix/current/bin” appears first, followed by the current value of PATH. You can add this line to the bottom of ~/.bash_profile and then start a new shell session (e.g. by logging out and in again). -- Ricardo
Re: guix pull
Gottfried writes: > If I do a guix pull at root, than the guix system is for root updated, I > understood, > > does it mean that's it, and I don´t need to do a > > guix system reconfigure /etc/config.scm, which I do for the user? There seems to have been a misunderstanding; sorry for confusing you. “guix pull” only updates the “guix” command. It does so by installing a new version of Guix (+ whatever channels you may have configured) to ~/.config/guix/current. You can then use that new “guix” command to upgrade or install new software. “guix system reconfigure config.scm” on the other hand changes the operating system according to the configuration file “config.scm”. There’s only one system-wide operating system. This action can only be performed by the “root” user because it affects *all* users on the same machine. -- Ricardo
Re: guix pull
Gottfried writes: > Should I do a guix pull basically in my user account? > > Or should I do a guix pull basically in the root account? > > As far as I understood if I do a gux pull in my user account, it has > no influence to the root account? This is correct. As far as Guix is concerned “root” is just another user account. > But If I do a guix pull only in my user account, it would mean, as far > as I understand it, the root account would not get security updates? Correct. Note that “guix pull” alone doesn’t upgrade any installed packages. It only gives you a new version of Guix which has access to updated packages. > What should be the procedure? You can have all users on the machine share the same guix and/or the same profile and upgrade just that. On a single-user system it also makes sense to just not install any software for the root user. -- Ricardo
Re: Stuck at scheme prompt when booting
coralg...@tuta.io writes: > Thank you for sharing those commands. > > I was able to start bash but at that point in the start up process > chattr is not available. Can you access /gnu/store already? Or unlock the disk with cryptsetup? -- Ricardo
Re: mailing list and Evolution / Email client and: Guix, compared with Trisquel/Guix
Zelphir Kaltstahl writes: > I don't see how Trisquel would invariably load incompatible stuff. All > you do is put the guix profile on the path and from the guix profile > there are symlinks to the gnu store. Whatever you install in the guix > profile will then be on the path, but that is just normal, I guess. I > don't see any issue that I would not have with a different tool > installing software. I also haven't seen incompatible stuff yet. Might > be just me installing usually well known software, that has been > tested more thoroughly and not having run into the edge cases yet. I’ve seen a lot of users run into problems like that. The usual suspect is one of the XDG_* variables. There may also be problems with caches that are loaded by programs from Guix *and* the system, and with standard locations that can affect the behavior of applications. One problem manifests itself as a crash when displaying a file dialog, for example. These are not unavoidable, but it’s certainly surprising and annoying when it happens. Of course, Guix is still a very helpful tool, no matter what distro you happen to use underneath. -- Ricardo
Re: using german language
Hi, [- mail...@gnu.org] > As a German native speaker I am asking if it makes sense to write in German. There are a few German native speakers reading these lists (I read and write German, too, but I’m lousy with email). If you’re uncomfortable expressing yourself in English it’s fine to use another language that you are more comfortable with. Sometimes it’s better to optimize communication than it is to maximize reach. > I suppose, if I will write in German, only some people can read it, > and I would get help only from some people. Is that right? Or will it > be translated for English speaking people? There is not automatic translation. -- Ricardo
Re: mailing list and Evolution /Email client and: Guix compared with Trisquel/Guix
Gottfried writes: > What`s the difference to install GNU Guix as a system or install > Trisquel and Guix on top of it? What is the advantage of both > possibilities? With Guix System you get all the services from Guix System. You can boot older generations of your system, and there is no “state” shared between generations of your system. Any time you upgrade your system (with “guix system reconfigure /path/to/my/config.scm”) Guix builds a new, independent system. Any time you boot you can select the latest or a previous generation of your system, and when booting the selected system is initialized from scratch (it copies files from /gnu/store to /etc, creates user accounts, etc). What’s great about this Guix System approach in my opinion: - you have a safety net and can recover from bad upgrades - changes to the system are not permanent unless you make them so - changes to one system generation don’t affect older system generations There is still a potential for complication when changing hardware (e.g. an old generation expecting a certain disk to appear, but you no longer have a disk with that label, so you can’t boot that old generation without hassle), but overall it takes the fear out of upgrading. > I installed Guix as my System because if I had installed Trisquel I > would have older software. And to add Guix on top of Trisquel seemed > to me not so beneficiary and may be leading to inconsistency. To be on > the save side I installed Guix as my System in order to run smoothly. Good choice! When you use Guix on top of Trisquel you’re still using a lot of software from Trisquel, which has the potential of conflicting with your software from Guix — especially with search paths and environment variables that invariably end up causing Trisquel to load incompatible stuff from Guix or vice versa. -- Ricardo
