Re: same package defined in multiple channels?

[Julien Lepiller]

Hi Andy,

They will all be available, and the one used will depend on the situation and 
how you use them.

Consider 'foo' is not only in different channels, but also in different modules 
(from the root of the channel, they are defined in different directories/files).

In that case, all versions are visible. From the command line, this is similar 
to other packages that may have multiple versions in a single channel. For 
instance 'guix install foo' will install the package with the greatest version 
numbes, fsom any channel. 'guix install foo@3' will select the one that has the 
greatest version, with major version starting with 3.

For dependencies, manifests or other scheme code, the story is different. Say 
'bar' in guix depends on foo, and 'baz' in 'mychannel' depends on foo.

The code in guix would have a use-module (gnu packages foo) and use 'foo' from 
this module as input for bar. It means it is always the guix's foo that is 
being used to build bar in guix.

Similarly, mychannel can choose to import (gnu packages foo) and use guix's 
version as dependency in baz, or (mychannel packages foo) to use its own 
version of foo.

The fact that foo is implemented in both channels doesn't replace dependencies 
in other channels: they are independent (unless they explicitly depend on 
another channel).

Or, are they?

Well, if a channel were to redefine the same module as another one, say 
mychannel defines a gnu/packages/foo.scm file, then all definitions in guix's 
foo.scm are shadowed (or the other way around depending on channel order) and:

- shadowed versions are no longer available on the command line
- dependents will use the only one that is visible to scheme, so dependencies 
can be rewritten that way.

Hope that makes things a bit clearer :)

Le 9 février 2024 09:15:02 GMT+01:00, Andy Tai  a écrit :
>Hi, I wonder if I have multiple Guix channels, and the same package is
>defined in multiple channels, of different versions, what would happen
>if I do guix pull?   Would the first package definition encountered in
>the first channel containing the definition of this package in the
>channel list be used, shadowing the other definitions in later
>channels?
>

Re: IRC

[Julien Lepiller]

Hi Gottfried,

It's a matter of personal preference. I use hexchat, others use emacs, …

I also have a bouncer (znc) on my server which stays connected for me.

HTH!

Le 18 janvier 2024 14:58:32 GMT+01:00, Gottfried  a écrit :
>Hi Guix,
>
>to use IRC
>
>what do I have to install?
>
>I guess: Pidgin
>or are there other clients I should prefer?
>
>what else?
>
>Is it enough to install that client or do I have to add something in my 
>config.scm?
>
>

Re: Correct way to protect `guix system vm` invocations from garbage collection?

[Julien Lepiller]

Hi Ben,

If by "as a service", you mean started by the Shepherd, you should be good: the 
vm path will become alive as it's part of the system.

Another solution would be to make it a gc root, which you can do by symlinking 
it in /var/guix/gc-roots

Le 6 janvier 2024 00:31:05 GMT+01:00, Ben Weinstein-Raun  a 
écrit :
>Hello!
>
>
>I'm working on setting up permanent virtual machines to run as services.
>In order for this to work, I think I need to be sure that the various
>inputs to the vm runner script are kept alive. This includes the kernel,
>the initrd, and the qemu binary.
>
>
>What's the easiest way to permanently mark an arbitrary store file (in
>this case, the `...-run-vm.sh` script) as "alive"? e.g. is there a way
>to add it to my user's profile, or some other gc-root? Or add it to a
>new profile altogether?
>
>Thanks!
>

Re: Laptop won’t boot after Guix install

[Julien Lepiller]

Hi Ian,

Something similar happened to me before. After reconfiguring a lot of times, 
the firmaware had no space left for EFI variables. I didn't notice the error 
message at first because guix system did succeed. Maybe you have some similar 
errors that don't lead to a failure? What does the last phase say, when 
installing the bootloader?

Le 6 janvier 2024 04:41:34 GMT+01:00, Ian Eure  a écrit :
>Hello,
>
>I have Guix running on one computer already, and wanted to set it up on 
>another, a ThinkPad L390 Yoga.  This was previously running Debian, but I 
>wiped it to put Guix on, by running `sudo dd if=/dev/urandom of=/dev/nvme0n1 
>bs=1M'.  After the Guix install, the laptop doesn’t boot -- the firmware shows 
>a boot device selection menu, rather than bootint into Guix.  The only entry 
>is the internal NVMe SSD, and choosing it does nothing -- the firmware can’t 
>figure out how to boot from it.  I tried two other third-party installers 
>based on Guix 1.4.0, and got the same result.  The installer boots and runs 
>fine, the install process appears to succeed, but after restarting, the 
>machine doesn’t boot.
>
>This is a very vanilla setup.  I used the graphical Guix installer, let it 
>partition things, and have one partition for everything.  I have no other OS 
>on this computer, I’m not dual-booting, net-booting, or anything else exotic.
>
>Secure boot is disabled in the BIOS.
>
>I tried updating the firmware on the laptop and restoring it to the default 
>settings -- no change.
>
>I tried wiping the partition table again, but using /dev/zero -- no change.
>
>If I boot the installer image and drop into its GRUB menu, I can chainload 
>GRUB off the internal SSD’s ESP, which lets me boot Guix.  So the installation 
>itself is fine, but the bootloader is broken.  After booting this way, I tried 
>`guix pull' and `sudo guix system reconfigure /etc/config.scm'.  This also 
>didn’t work -- the machine still will not boot.
>
>After digging in the ESP, I thought I’d found a clue: the GRUB payload is 
>placed at /EFI/Guix/grubx64.efi, and there’s no /EFI/BOOT/BOOTX64.EFI, which 
>is typically what a UEFI platform would look for to begin booting the OS.  
>But!  My existing Guix machine (a ThinkPad X13 Gen 2 AMD) *does* boot, but 
>*doesn’t* have a /EFI/BOOT/BOOTX64.EFI payload, either.  My Debian machine has 
>/EFI/BOOT/BOOTX64.EFI as well as /EFI/debian/grubx64.efi -- both files have 
>identical contents per sha256sum.  But but!  The X13 *also* has some Debian 
>files in the ESP, so it’s not 100% identical to the L390.  Not sure how those 
>got there.  It’s also a former Debian box, but I wiped it, and am surprised to 
>see anything remaining from that.
>
>My only hypothesis around this is that perhaps the EFI variables are messed 
>up, and resetting BIOS settings doesn’t clear them. That might make the BIOS 
>do something weird in its boot process; or make GRUB think some other OS is 
>installed, and install the bootloader wrong for a single-OS setup.
>
>Does anyone have any suggestions or advice?  Needing a USB stick to boot the 
>machine is a pain.
>
>Thanks,
>
> — Ian
>

Re: How to configure gitolite service?

[Julien Lepiller]

This is the public key that corresponds to the private key the admin uses to 
pull/push the configuration repo with:

git clone git@server:gitolite-admin

I don't understand why you talk about mail here, plain-file is a file-like 
object which creates a file in the store from a string. This is just the 
content of the pub key file. Here's what I use, where the pub key is available 
in the same directory as the guix configuration (typically, /etc/julien.pub):

(admin-pubkey (local-file "julien.pub"))

Le 5 décembre 2023 12:56:27 GMT+01:00, "Marek Paśnikowski" 
 a écrit :
>Dear all.
>
>I am in the process of setting up Gitolite.  My strategy is based on the 
>principles of Test Driven Development.
>
>Following the system reconfiguration errors, I have questions regarding the 
>minimal required code:
>
>(service gitolite-service-type
>  (gitolite-configuration
>(admin-pubkey
>  (plain-file "user.pub" "key" "mail"
>
>1. Which system user does the .pub file correspond to - git or (in my case) 
>marek? In other words, is the key owner the /git/ account which serves the 
>Gitolite instance; or is it the remote administrator account which logs into 
>the service?
>
>If it is the /git/ user, how do I inject the private key into the server's 
>profile?
>
>2. Does the mail address correspond to the same account as above?

Re: Using Guix challenge for critical software? (resend)

[Julien Lepiller]

If you already have substituted it, you could rebuild it:

guix build openssh --no-grafts --check

Le 29 novembre 2023 12:40:50 GMT+01:00, Steve George  a 
écrit :
>Hi,
>
>
>
>How can I use 'guix challenge' to test critical software or packages that are 
>deep in the dependency tree?
>
>
>
>As I understand it, the purpose of Guix challenge is to test whether "binaries 
>provided by this [substitution] server really correspond to the source code it 
>claims to build" (from the manual). The obvious check then is to build the 
>package myself locally and then check if the substitution server give the same 
>result. To do that I do this:
>
>
>
>$ guix shell --container --nesting --development cbonsai --network nss-certs 
>-- \
>
>guix build cbonsai --no-substitutes --no-grafts
>
>$ guix challenge --verbose cbonsai
>
>
>
>/gnu/store/mgc2i6yxm2zbqf8yx8x5f4ig4nbii2cv-cbonsai-1.3.1 contents match:
>
>  local hash: 1vws4ywn1gcgpnm1pfr5rz4hv769ccvnyj5drpnnway7bg0ckh28
>
>  
> https://ci.guix.gnu.org/nar/lzip/mgc2i6yxm2zbqf8yx8x5f4ig4nbii2cv-cbonsai-1.3.1:
>  1vws4ywn1gcgpnm1pfr5rz4hv769ccvnyj5drpnnway7bg0ckh28
>
>  
> https://bordeaux.guix.gnu.org/nar/lzip/mgc2i6yxm2zbqf8yx8x5f4ig4nbii2cv-cbonsai-1.3.1:
>  1vws4ywn1gcgpnm1pfr5rz4hv769ccvnyj5drpnnway7bg0ckh28
>
>
>
>1 store items were analyzed:
>
>- 1 (100.0%) were identical
>
>- 0 (0.0%) differed
>
>- 0 (0.0%) were inconclusive
>
>
>
>All good so far.
>
>
>
>But, how do I test something that I depend on like OpenSSH? As I'm using it 
>(and it's critical to my system) I already have it installed locally from the 
>Substitution servers. Consequently, if I try to build it Guix informs me I 
>have it already. I can't really remove it from my system, and I don't think 
>there's a way to build it locally without first removing it. >
>
>
>It seems at this point that I'm stuck. The only form of 'guix challenge' I can 
>do is to check whether the two Substitutions servers agree - but if I don't 
>trust the Guix developers this isn't a very good check.
>
>
>
>Is there some way to build the package locally (without first removing it)? Or 
>some clever way to run Guix challenge that I'm not seeing?
>
>
>
>Thanks,
>
>
>
>Futurile/Steve
>
>

Re: Unable to build "Ten Years Reproducibility Challenge" paper

[Julien Lepiller]

That's openssl failing due to a time-dependent test. Try making your system 
time something around 2010 and don't let ntpd set it back to today until 
openssl is built.

You could skip tests, but that would build a different derivation tree, so it 
might affect reproducibility (probably not): --without-checks=openssl

Le 29 octobre 2023 19:44:49 GMT+01:00, Suhail  a écrit :
>Hi Guix,
>
>I am relatively new to Guix. I recently came across this blog post:
>.
>
>In trying to build and run the evaluation as documented in
>, I'm
>encountering the following error (both on Guix package on OpenSUSE
>distribution as well as on Guix system in a VM):
>
>#+begin_example
>  $> guix time-machine -C channels.scm -- build -f guix.scm
>  Updating channel 'guix-past' from Git repository at 
> 'https://gitlab.inria.fr/guix-hpc/guix-past.git'...
>  Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>
>  ...
>
>  building /gnu/store/vsvpi0cy4g3s5w7p9rj3ixnw16jllmr1-guix-config.drv...
>  building /gnu/store/2igl2vvjmvg2qwizy5w0gvf63vsvb44x-guix-core.drv...
>  building 
> /gnu/store/0y3m9wj8qziblk743fjjxmn1iybm2zif-guix-config-modules.drv...
>  building /gnu/store/0ny9586ypfm7d7k9ly3s4i60hb3wczlj-guix-core-modules.drv...
>  building 
> /gnu/store/cscfsg5hmznn5rgk3q8affwc5445fqcd-openssl-1.1.1g.tar.xz.drv...
>  applying 6 grafts for pango-1.42.4 ...
>  building /gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv...
>  / 'check' phasebuilder for 
> `/gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv' failed with 
> exit code 1
>  build of /gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv 
> failed
>  View build log at 
> '/var/log/guix/drvs/vv/hn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv.gz'.
>  applying 7 grafts for graphviz-2.40.1 ...
>  cannot build derivation 
> `/gnu/store/8adwgdgaf6xcyhyyc5z9nvrql7bkgvhy-libgit2-1.0.0.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/kml3x6f5arzsqbqcf9n77dpw1mwszybr-guile3.0-git-0.3.0.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/bgyz3mib0bvpmxl1j0jp9x4jqqhw6416-guix-cli.drv': 1 dependencies 
> couldn't be built
>  cannot build derivation 
> `/gnu/store/cjqbylp554mhwhl8895z5n74q5998waq-guix-extra.drv': 1 dependencies 
> couldn't be built
>  cannot build derivation 
> `/gnu/store/ql55k991hvz4x9splndhwyzq9apnasig-guix-module-union.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/s9j6wb6jzqhfcwb8isjbalf6msdqq83b-guix-packages-base.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/mf05ss7j1hh06vnrkywkswvlgdzv2i8k-guix-packages.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/x1ci1v82ncj679gipnk3s5sszshl66fi-guix-system-tests.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/pm8y6k5kzcddk170h0biarmqi278m0ww-guix-system.drv': 1 dependencies 
> couldn't be built
>  cannot build derivation 
> `/gnu/store/nnv3zac8hj40kdz5i4bwwbfzqq5j6bi9-guix-cli-modules.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/2xilwplb6mzqsh4p5yym52f1q4l14lmc-guix-command.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/9g1cw0wxwi0jm7akmrf48hx6rxswx4nn-guix-extra-modules.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/v9zjw4gphv900swc8z450hal3farykwd-guix-packages-base-modules.drv': 
> 1 dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/fjqv9nagdnda38l68x6f82qlradx18a7-guix-packages-modules.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/m5z9ba7gra3qml9gzl6vh4d8fcq4qn20-guix-system-modules.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/i37g4wlrgwcaq5v2c4zrkaysfnf95spy-guix-system-tests-modules.drv': 
> 1 dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/fp7isyvw7g8kr2vhqgw4p45yckz0srd9-guix-40fd909e3.drv': 1 
> dependencies couldn't be built
>  cannot build derivation 
> `/gnu/store/x2fv84h6izjn8sh50nn55i2qp9h3hbzj-profile.drv': 1 dependencies 
> couldn't be built
>  guix time-machine: error: build of 
> `/gnu/store/x2fv84h6izjn8sh50nn55i2qp9h3hbzj-profile.drv' failed
>#+end_example
>
>As can be seen in the attached build log, it seems some tests for
>openssl are failing. I'm speculating that these tests are
>non-deterministic and perhaps overly rigid.
>
>Is there a way to tell Guix to either skip the 'check' build-phase for a
>specific dependency (or perhaps for the entire build invocation)? Any
>guidance?
>
>

Re: Ocamlfind doesn't find arbitrary library

[Julien Lepiller]

Le Thu, 21 Sep 2023 11:08:38 -0400,
Garek Dyszel  a écrit :

> Hi Guix,
> 
> While trying to get Coq to find a certain package that is part of its
> dependency chain, I stumbled upon the following seemingly-general
> problem. It seems that Ocaml packages are not in general detected by
> findlib.
> 
> Probably I'm missing something really simple because I'm not too
> familiar with Ocaml, but it looks to me to be maybe a Guix-specific
> problem.
> 
> Thanks for any and all help!
> Garek
> 
> ---
> Command from which this originates:
> --8<---cut here---start->8---
> $ guix shell ocaml-findlib ocaml-sha -- ocamlfind list

You have to add ocaml@4, otherwise Guix will not create the necessary
environment variables in the shell. With it, sha is listed.

> bigarray(version: [distributed with Ocaml])
> bytes   (version: [distributed with OCaml 4.02 or above])
> compiler-libs   (version: [distributed with Ocaml])
> compiler-libs.bytecomp (version: [distributed with Ocaml])
> compiler-libs.common (version: [distributed with Ocaml])
> compiler-libs.native-toplevel (version: [distributed with Ocaml])
> compiler-libs.optcomp (version: [distributed with Ocaml])
> compiler-libs.toplevel (version: [distributed with Ocaml])
> dynlink (version: [distributed with Ocaml])
> findlib (version: 1.9.5)
> findlib.dynload (version: 1.9.5)
> findlib.internal(version: 1.9.5)
> findlib.top (version: 1.9.5)
> ocamldoc(version: [distributed with Ocaml])
> stdlib  (version: [distributed with Ocaml])
> str (version: [distributed with Ocaml])
> threads (version: [distributed with Ocaml])
> threads.none(version: [internal])
> threads.posix   (version: [internal])
> unix(version: [distributed with Ocaml])
> --8<---cut here---end--->8---
> 
> 

Re: dune-based package design trouble

[Julien Lepiller]

Le Wed, 20 Sep 2023 09:52:03 +0200,
Erwan Jahier  a écrit :

> Hello,
> 
> I am a newguix tring to package some of his software.
> 
> Since I already  have opam packages, I used =guix  import opam=, that
> helped a  little. Of course,  my packages have dependancies,  and not
> all of them exist in the main guix repo.
> 
> I have  able to build  some of them  (ocaml-junit,
> ocaml-junit-alcotest, ocaml-yaml,  ocaml-functory,
> ocaml-conf-graphviz),   but  I  am  having trouble with
> ocaml-mlgmpidl, for  which the build  phase isn't  able to
> (ocaml-)find gmp (see below).  So I've tried to package ocaml-gmp,
> but I am stuck again.
> 
> The error  "/bin/sh: bad interpreter:  No such file or  directory" is
> raised  during the  build phase  that  runs a  =configure= script
> that refers to a non existing /bin/sh.
> 
> The  problem  is that  the  =patch-source-shebangs=  phase cannot  be
> applied, as this  =configure= script is generated and  run inside the
> build phase (via =dune build=).
> 
> I feel like it might be a dune expert question, but I try my luck
> here.
> 
> Erwan.
> 

It's not very clean, but this works:

(define-public ocaml-mlgmpidl
  (package
(name "ocaml-mlgmpidl")
(version "1.2.15")
(source (origin
  (method url-fetch)
  (uri
"https://github.com/nberth/mlgmpidl/archive/1.2.15.tar.gz;)
  (sha256
(base32
  "0hcaan4n5li0rnr55ilgxgd8w00lza9an6w4yj7v66dcb7plbasj"
   (build-system ocaml-build-system)
(arguments
 `(#:tests? #f;
#:phases
(modify-phases %standard-phases
  (replace 'configure
(lambda* (#:key outputs inputs #:allow-other-keys)
  (substitute* "configure"
((".*query gmp.*") "echo \"$camlidl_prefix\n\" \n")
(("camlidl_prefix=`\\$ocamlfind.*")
 (string-append "camlidl_prefix=\"" (assoc-ref inputs
"camlidl") "/lib/ocaml/site-lib/camlidl\"\n")))
  (invoke "./configure" "--prefix" (assoc-ref outputs
"out")))
(inputs (list perl ocaml-findlib camlidl gmp mpfr
ocaml-bigarray-compat))
(home-page
  
"https://www.inrialpes.fr/pop-art/people/bjeannet/mlxxxidl-forge/mlgmpidl/;)
(synopsis "OCaml interface to the GMP library")
(description #f)
(license license:lgpl2.1)) ; with linking exception
)

Re: guix on foreign distribution: /var/log/guix/* removal safe?

[Julien Lepiller]

Le 5 septembre 2023 01:56:08 GMT+02:00, Csepp  a écrit :
>
>Andy Tai  writes:
>
>> I run Guix on top of a foreign distribution (Fedora).  The directory
>> /var/log/guix contains  log files and keeps growing in size.  I wonder
>> if I can remove existing log files in /var/log/guix without any
>> harmful effect (with no guix pull or build in progress)?
>>
>> Thanks for info
>
>AFAIK yes.  I've done so a few times.
>

Yes, it's perfectly safe. You could setup a rotation job so you don't have to 
care about cleaning them manually. See your distro's documentation to learn how 
to do that ;)

Re: ocaml-stdlib-shims: setting paths for a Coq package

[Julien Lepiller]

Le 2 septembre 2023 20:52:21 GMT+02:00, Garek Dyszel  
a écrit :
>Hi Guix,
>
>While trying to package coq-elpi, one finds that Findlib is unable to
>find ocaml-stdlib-shims. The problem persists even if ocaml-stdlib-shims
>is located in the inputs and propagated-inputs fields.
>
>Trying to set OCAMLLIB using the following doesn't seem to work.
>(string-append "OCAMLLIB=$OCAMLLIB:" 
>   #$(this-package-input "ocaml-stdlib-shims"))
>
>Which environment variable should we be setting so that
>ocaml-stdlib-shims can be picked up by Coq?
>
>I can include the whole package file from which this question is
>originating if it would help, but there are about 20 packages in there;
>I don't want to force anybody to read it unless we really have to :)
>
>Garek
>
>
>Make flags for coq-elpi
>--8<---cut here---start->8---
>;; Most of the package definition omitted...
>(arguments ;;...
>`(#:make-flags ,#~(list (string-append "COQBIN="
>#$(this-package-input "coq-core")
>"/bin/")
> (string-append "ELPIDIR="
>#$(this-package-input "ocaml-elpi")
>"/lib/ocaml/site-lib/elpi")
> (string-append "COQLIBINSTALL="
>#$output
>"/lib/coq/user-contrib")
> (string-append "COQMF_COQLIB="
>#$output
> "/lib/ocaml/site-lib/coq")
> (string-append "OCAMLLIB=$OCAMLLIB:" 
>#$(this-package-input
>"ocaml-stdlib-shims"))
> (string-append "COQPLUGININSTALL="
>#$output
>"/lib/ocaml/site-lib")
> "OCAMLWARN=")
> ;;...
> ))
>--8<---cut here---end--->8---
>
>Adjusted arguments for ocaml-stdlib-shims (adding the phase install-meta
>doesn't seem to fix the problem)
>--8<---cut here---start->8---
>(define-public ocaml-stdlib-shims
>  (package
>(name "ocaml-stdlib-shims")
>(version "0.3.0")
>(source (origin
>  (method git-fetch)
>  (uri (git-reference
> (url "https://github.com/ocaml/stdlib-shims;)
> (commit version)))
>  (file-name (git-file-name name version))
>  (sha256
>   (base32
>"0gmg8w67j3ww17llk7hl4dx0vq7p50rn5s4ib9sy984k543rz59h"
>(build-system dune-build-system)
>(arguments
>`(#:phases
> (modify-phases %standard-phases
>   (delete 'configure)
>   (add-after 'install 'install-meta
> (lambda* (#:key outputs #:allow-other-keys)
>   (let ((out (assoc-ref outputs "out")))
> (with-output-to-file
> (string-append out 
> "/lib/ocaml/site-lib/stdlib-shims/META")
>   (lambda _
> (display
>  "package \"stdlib-shims\" (
>  description = \"Stdlib shims\"
>  requires = \"\"
>  archive(byte) = \"stdlib_shims.cma\"
>  archive(native) = \"stdlib_shims.cmxa\"
>  plugin(byte) = \"stdlib_shims.cma\"
>  plugin(native) = \"stdlib_shims.cmxs\"
>  )")
>(home-page "https://github.com/ocaml/stdlib-shims;)
>(synopsis "OCaml stdlib features backport to older OCaml compilers")
>(description "This package backports some of the new stdlib features to
>older compilers, such as the Stdlib module.  This allows projects that require
>compatibility with older compiler to use these new features in their code.")
>;; with ocaml-linking exception
>(license license:lgpl2.1+)))
>--8<---cut here---end--->8---
>

Hi Garek,

It should work with OCAMLPATH, not OCAMLLIB. If you use the ocaml-build-system 
or the dune-build-system, it should already be set. Otherwise, adding ocaml to 
your native-inputs should help.

Re: Guidance for packaging Java programs

[Julien Lepiller]

Le 28 juillet 2023 04:09:42 GMT+02:00, Bruno Victal  a écrit 
:
>Hi Julien,
>
>On 2023-07-13 18:48, Julien Lepiller wrote:
>> If you feel like helping, maybe an importer would be a good first step :). 
>> You should be able to get info from Maven Central (get the pom files, they 
>> are XML files and we have a module somewhere to handle them (guix build 
>> maven pom) I think). It should work for maven and gradle packages at least. 
>> Mapping maven name to guix names might also be challenging, but we can solve 
>> with an upstream-name property.
>> 
>> Here are some more resources if you want to learn more about Guix and Java:
>> 
>> I gave a talk about bootstrapping Maven in 2020:
>> 
>> https://xana.lepiller.eu/guix-days-2020/guix-days-2020-julien-lepiller-bootstrapping-maven-480.mp4
>
>Thanks! This was very helpful in providing an overview of the system.
>
>Can we say that the maven in Guix has already been “bootstrapped” or is there 
>something still missing?
>Given the large and non-trivial nature of just the “bootstrap” part, would it 
>make sense to split
>gnu/packages/maven.scm into maven-bootstrap.scm and maven-.scm 
>files to keep things manageable?

Maven itself is bootstrapped, along with the essential plugins. We're still 
missing many plugins. As long as we don't have maven-plugin-plugin, we need to 
build them "manually" in the same way we build other other plugins. It could be 
an interesting target for improving the situation.

>
>The maven-importer situation is quite unfortunate due to the often absent 
>source location, a quick glance
>here suggests that the best we might hope for is an automation-½ approach: 
>generate “skeleton” package
>definitions and manually fill-in the source & co.
>
>Some additional maven related questions:
>
>* What is 'sisu.sh' & 'components.sh' and when/what are they used for?

They are scripts to automatically generate some files that are required at 
runtime for "dependency injection". Normally, this generation is done by a 
maven plugin, but in the bootstrap, we can't use maven, so we managed to 
replace that with a small script.

>
>* Is it common for maven plugins to end up with package definitions
>that make heavy use of inherit? (a quick glance at gnu/packages/maven.scm
>gives the impression that it all looks very fragile due to the matryoshka-like
>inheritance rabbit-holes)

There's inheritance everywhere in java and maven packages. There shouldn't be 
that many layers though. Usually, there's a package definition and its 
bootstrap version or other components from the same source inherit from it.

If you find a way to simplify all that, it's more than welcome :)

Re: URISyntaxException building openjdk@10

[Julien Lepiller]

Which architecture are you building on, and which filesystem is your store on? 
This looks like something got corrupted, maybe check your filesystem or try and 
rebuild openjdk@9 (with --check --no-grafts). As Andreas mentions, it works on 
the build farm.

Le 24 juillet 2023 10:17:54 GMT+02:00, Andreas Enge  a écrit :
>Hello Greg,
>
>Am Thu, Jul 20, 2023 at 11:32:40AM -0400 schrieb Greg Hogan:
>> I have tried everything I could think of but have been unable to build
>> openjdk@10 since the final core-updates merge. Am simply running `guix
>> build openjdk` from a recent `guix pull`.
>
>openjdk and openjdk@10 are both available as substitutes. Maybe authorising
>the substitute servers will solve your problem?
>
>Also I have been rebuilding openjdk a few times before the core-updates
>merge since they required patches, and definitely it worked in the end.
>
>Andreas
>
>

Re: Guix System and WIFI / WLAN

[Julien Lepiller]

Hi Gottfried,

Trisquel and Guix have the same issue with wifi: lack of free driver/microcode. 
So, if this adapter works with Trisquel, driver/microcode is free and it works 
with Guix too :)

I used an Atheros-based dongle in the past (can't remember the exact reference, 
but probably this one) and it worked with Guix.

Le 18 juillet 2023 13:06:09 GMT+02:00, Gottfried  a écrit :
> Hi Guix,
>
>sorry for my simple question, but I didn't have this problem until now
>and a brief checking the archive didn't help me.
>
>How can I connect my laptop with Guix System to the internet with
>Wifi/WLAN (in german)?
>
>In the Trisquel Forum they suggest to buy a "AR9271 adapter" on ebay,
>connecting via usb to the laptop
>
>Does that work in Guix system as well?
>
>If not, what do I have to do?
>
>thanks for your help
>
>Gottfried 

Re: Guidance for packaging Java programs

[Julien Lepiller]

Le 13 juillet 2023 21:35:37 GMT+02:00, Bruno Victal  a écrit 
:
>Hi Julien,
>
>On 2023-07-13 18:48, Julien Lepiller wrote:
>> I've never seen anything like saxon-he sources. It looks like a bunch of zip 
>> files that contain java files with no build system. The ant-build-system 
>> might be able to build that, though no idea how much dependencies there 
>> could be.
>
>It looks like the Saxon-HE sources are actually “generated” from this 
>repository:
><https://saxonica.plan.io/projects/saxonmirrorhe/repository>

I see. We have two problems it seems: it uses gradle, for which there's no 
build system, and it also requires an older version of itself for some 
preprocessing. Might get tricky…

>
>> If you feel like helping, maybe an importer would be a good first step :). 
>> You should be able to get info from Maven Central (get the pom files, they 
>> are XML files and we have a module somewhere to handle them (guix build 
>> maven pom) I think). It should work for maven and gradle packages at least. 
>> Mapping maven name to guix names might also be challenging, but we can solve 
>> with an upstream-name property.[…]
>
>> To summarize, the main pain points are: lots of dependencies that can 
>> quickly go out of hand, source buildability is not great, as many ship their 
>> own versions of their dependencies (we need to snippet pre-built jars away, 
>> and find a workaround when the build fails to find them), and 
>> bootstrappability, as there can be quite a lot of dependency circles.
>
>I wonder if this is doable for the java uninitiated.
>(Why bother with Java when you can write in Guile? :D)
>An importer first would certainly be a step in the right direction, yes.
>(handcrafting package definitions for dependencies and dependencies of
>said dependencies is no fun)

Well, I don't write a lot of Java either :)

Re: Guidance for packaging Java programs

[Julien Lepiller]

Hi Bruno,

I'm glad to see some interest in Java :)

First, Java has its own build systems, somewhat like autotools/cmake/meson etc. 
In the past, ant was the most popular. It's somewhat similar to Make, as you 
specify build targets in a build.xml file. This case is well supported and we 
have a ant-build-system for that.

The first difficulty is that ant is-just like make, so it won't manage 
dependencies, and even not specify any. In the Java world, they either use the 
same solution as C, in that they don't care and it's your job to bring in 
dependencies until the build stops breaking (although it might sound bad, this 
is the good way of doing things for us), or they ship the binary of their 
dependencies and force you to use that. This is bad for us, since we want to 
build everything fsom source. It's just a bit more work, but nothing we can 
patch or snippet away usually.

Nowadays, ant is loosing "market share" in favor of Maven and Gradle. We have a 
working though probably too primitive maven-build-system which can build a 
maven project as long as you provide dependencies and plugins.

They are both also package managers, so they usually specify dependencies, 
which could be useful for an importer, but they often lack source information 
and there's a lot of bloat in these files (many unneeded dependencies stay 
there forever…).

Gradle is similar to Maven but it requires quite a lot of work still. The main 
issue is that it requires Kotlin, the programming language. Since Guix tries to 
bootstrap its compilers, we need a bootstrap of Kotlin. I tried to do that and 
after a lot of pain, managed to cleanly bootstrap a kotlin-1.0. I still need to 
work on adding more to the chain and get more recent versions, but that's pure 
crazyness at this point.

BiglyBT doesn't seem to have too mazy dependencies at first glance, maybe a 
better target, though it still requires some cleanup. Not sure what swt is, but 
we would need to build it ourselves.

Jing looks like it can use ant, but it also looks like it has a ton of 
lependencies. You could get lost in a rabbithole packaging that one :)

I've never seen anything like saxon-he sources. It looks like a bunch of zip 
files that contain java files with no build system. The ant-build-system might 
be able to build that, though no idea how much dependencies there could be.

I'd also like to get Mindustry at some point, but I don't see that happening 
any time soon : it uses gradle, and with custom plugins too, which means we 
can't even cheat and use something other than gradle :/

If you feel like helping, maybe an importer would be a good first step :). You 
should be able to get info from Maven Central (get the pom files, they are XML 
files and we have a module somewhere to handle them (guix build maven pom) I 
think). It should work for maven and gradle packages at least. Mapping maven 
name to guix names might also be challenging, but we can solve with an 
upstream-name property.

Here are some more resources if you want to learn more about Guix and Java:

I gave a talk about bootstrapping Maven in 2020:

https://xana.lepiller.eu/guix-days-2020/guix-days-2020-julien-lepiller-bootstrapping-maven-480.mp4

There's also my Kotlin bootstrap chain:

https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm

There's also a bootstrap of sbt (Scala Build Tool) from Scala, but Scala is not 
bootstrapped/able in that repo.

To summarize, the main pain points are: lots of dependencies that can quickly 
go out of hand, source buildability is not great, as many ship their own 
versions of their dependencies (we need to snippet pre-built jars away, and 
find a workaround when the build fails to find them), and bootstrappability, as 
there can be quite a lot of dependency circles.

HTH, and don't hesitate if you want to learn more!

Le 13 juillet 2023 19:00:07 GMT+02:00, Bruno Victal  a écrit 
:
>Hi all,
>
>I'm interested in seeing BiglyBT (an awesome BitTorrent client) [1],
>jing (a RELAX NG validator) [2], Saxon-HE (a free implementation of
>XSLT 2.0 + 3.0) [3] and Mindustry (an addicting tower-defense
>game) [4] packaged for Guix and I'd like to ask for some guidance
>with this subject.
>
>Though I'm not familiar with the language, this seldomly reveals to
>be a problem if the project uses GNU Autotools, Meson, CMake, etc.
>but I'm completely lost when it comes to Java. It's hard to understand
>what's happening, what are the dependencies, how the whole thing is
>assembled together or if I'm even staring at something supposed to be
>built at all. The lack of importers doesn't help either :(
>
>The impression I get is that overall the Guix Java subsystem/support
>seems to be quite barren which I suspect is in part due to the
>rather arcane build process involved. (the manual doesn't have much
>information on the topic as well)
>
>Does anyone have any insig

Re: desktop services

[Julien Lepiller]

Some desktop environments require a service, which would be added to the 
services fiild of your operating-system. They can't work otherwise. Most window 
managers (in my case, openbox), do not require a service type so you can simply 
add the package to the packages field of your operating system declaration.

I'm pretty sure cinnamon and kde are full-fledge desktop environments though, 
so if no service is documented, it means that you won't be able to start a 
session with them (yet).

You can try "guix show xfce" to list properties of that package, including 
dependencies (inputs).

Le 12 mai 2023 07:48:12 GMT+02:00, Gottfried  a écrit :
>Hi,
>
>1.
>In the manual 12.9.9 there are several desktop services mentioned
>
>But cinnamon-desktop and kde plasma-desktop is not mentioned,
>even though you can download the cinnamon and plasma-desktop packages.
>
>Are the mentioned desktop services like Gnome, XFCE, MATE only examples
>and cinnamon and plasma are not mentioned?
>or is the cinnamon and plasma desktop not available/working yet,
>even though the packages can be downloaded?
>
>2.
>You can download the desktop environment "XFCE 4.18.2"
>Additionally there are many other XFCE packages available for download.
>
>Are those additional packages completely separate packages
>which I can additionally install?
>or are some of them included in the  main "xfce 4.18.2" package?
>
>How can I know which packages are included in the main xfce 4.18.2 package? 
>Which command tells me that?
>in order not to install something twice?
>
>Or is it no problem to install something twice, Guix will tell me that
>and handle it.
>
>Kind regards
>
>Gottfried
>

Re: Guix website Czech translation

[Julien Lepiller]

In case you didn't see it, translation is performed on weblate, where anyone 
(such as yourself) can help with the translation: 
https://translate.fedoraproject.org/projects/guix/website/cs/

If you don't want to modify Kryštof's work, you can still post suggestions or 
comments on the translation.

There's no review process currently, but weblate allows this kind of workflow. 
I don't really like it though, since I've already come across bad translations 
(non-sensical!) in French that had been validated and became impossible for me 
to modify.

The only review that I make is that the translation doesn't break the build 
process. Which it did, but I found and fixed the issue :)

Le 11 mai 2023 01:33:47 GMT+02:00, wolf  a écrit :
>On 2023-05-10 22:51:56 +, Kryštof Šourek wrote:
>> Considering it's open source and basically volunteer work, there's probably 
>> no space for reviews.
>
>In open source, including volunteer work, there quite often is some review
>process.  My guess is it did not happen in this instance, but quite often there
>is some kind of review.
>
>> If by "bit of" you mean there are mistakes, it's probable there's going to 
>> be a few since I wasn't familiar with the weblate interface at first.
>
>Sure, there are some mistakes in formatting and such, but most of the things I
>did notice are flat out translation mistakes, so I'm unsure how that relates to
>you being not familiar to "weblate".
>
>Random example, what the hell is supposed to be "Guile Schéma"?  If you would 
>be
>translating a book "Programming in Python", would you really go with
>"Programovani v Krajte"?  Since when are names of programming languages
>translated?  "Spravce transakcnich balicku" is another example, what is that
>even supposed to mean?
>
>Also, side note, I'm not sure I would call GNU Project a "company", is that 
>from
>some official source, or how did you come up with it?  Same for "company" Guix.
>
>The whole thing just seems not that well made, can you get an adviser for your
>school project to proof read it before sending the patch with an update?
>
>> I intend on fixing them but if you would like to help, go ahead.
>
>I'm happy to hear that, I will leave it up to you then, after all, it's your
>school project. :)
>
>> 
>> Sent from Outlook for Android<https://aka.ms/AAb9ysg>
>> 
>> ____
>> From: wolf 
>> Sent: Thursday, 11 May 2023, 00:34
>> To: Julien Lepiller 
>> Cc: Kryštof Šourek ; help-guix@gnu.org 
>> Subject: Re: Guix website Czech translation
>> 
>> Hi,
>> 
>> On 2023-05-10 23:12:25 +0200, Julien Lepiller wrote:
>> > Le Wed, 10 May 2023 21:09:26 +0200,
>> > Julien Lepiller  a écrit :
>> >
>> > > It's a manual process. I'll update it as soon as possible.
>> > >
>> > > Le 10 mai 2023 14:55:30 GMT+02:00, "Kryštof Šourek via"
>> > >  a écrit :
>> > > >Hi,
>> > > >
>> > > >I've been working on a Czech language translation for the Guix
>> > > >website in the past week and I've finished it. I'm not sure how long
>> > > >it normally takes to get a translation online, but I have worked on
>> > > >this project as a part of voluntary work for a university subject.
>> > > >It would help me greatly if it came online as soon as possible. If
>> > > >it's not possible, no worries - I'll run it locally.
>> > > >
>> > > >Thank you for your time.
>> > > >
>> > > >Best regards,
>> > > >KS
>> > >
>> >
>> > Hi Kryštof Šourek,
>> >
>> > I just pushed your translation along with a new Lithuanian translation
>> > and an update to existing translations!
>> >
>> > You should be able to see it in less than an hour at
>> > https://guix.gnu.org/cs/. You should probably check that nothing looks
>> > horribly wrong, that links are working as expected, etc.
>> >
>> > Thanks for your hard work!
>> >
>> 
>> Out of curiosity, how are translations reviewed? I looked around the
>> guix-patches mailing list but failed to find corresponding thread (maybe I 
>> just
>> cannot search well). Since I'm Czech, I was curious and the homepage looks 
>> bit
>> of in few places, so I'm curious what the process is.
>> 
>> Thanks,
>> W.
>> 
>> --
>> There are only two hard things in Computer Science:
>> cache invalidation, naming things and off-by-one errors.
>>
>
>W.
>

Re: Guix website Czech translation

[Julien Lepiller]

Le Wed, 10 May 2023 21:09:26 +0200,
Julien Lepiller  a écrit :

> It's a manual process. I'll update it as soon as possible.
> 
> Le 10 mai 2023 14:55:30 GMT+02:00, "Kryštof Šourek via"
>  a écrit :
> >Hi,
> >
> >I've been working on a Czech language translation for the Guix
> >website in the past week and I've finished it. I'm not sure how long
> >it normally takes to get a translation online, but I have worked on
> >this project as a part of voluntary work for a university subject.
> >It would help me greatly if it came online as soon as possible. If
> >it's not possible, no worries - I'll run it locally.
> >
> >Thank you for your time.
> >
> >Best regards,
> >KS  
> 

Hi Kryštof Šourek,

I just pushed your translation along with a new Lithuanian translation
and an update to existing translations!

You should be able to see it in less than an hour at
https://guix.gnu.org/cs/.  You should probably check that nothing looks
horribly wrong, that links are working as expected, etc.

Thanks for your hard work!

Re: Guix website Czech translation

[Julien Lepiller]

It's a manual process. I'll update it as soon as possible.

Le 10 mai 2023 14:55:30 GMT+02:00, "Kryštof Šourek via"  a 
écrit :
>Hi,
>
>I've been working on a Czech language translation for the Guix website in the 
>past week and I've finished it.
>I'm not sure how long it normally takes to get a translation online, but I 
>have worked on this project as a part of voluntary work for a university 
>subject. It would help me greatly if it came online as soon as possible. If 
>it's not possible, no worries - I'll run it locally.
>
>Thank you for your time.
>
>Best regards,
>KS

Re: MATE Desktop fails

[Julien Lepiller]

Have you tried clearing gdm's cache? I think something like rm -rf ~/.cache/gdm 
might solve the issue. I'm not sure for your other questions.

Le 7 mai 2023 14:11:40 GMT+02:00, Gottfried  a écrit :
>Hi,
>
>I did a rollback on my guix system four times,
>
>but MATE was not recovered.
>
>it seems it is a gdm problem.
>
>-
>
>Am I the only one who has MATE-Desktop?
>
>-
>1.
>Is there a way to repair gdm
>or should I wait for a next update?
>
>2.
>Or should I install an other Desktop like LXDE
>
>3.
>Is the plasma-desktop already working?
>
>
>Kind regards
>
>Gottfried
>
>
>
>Am 06.05.23 um 10:22 schrieb Gottfried:
>> Hi,
>> 
>> since 2 days MATE Desktop doesn’t start properly.
>> The additional monitor doesn’t get a signal, so I have only the laptop.
>> 
>> Additionally on the screen the icons are different.
>> It seems like a basic, a save configuration.
>> 
>> I checked the cable of the monitor, it is o.k.
>> I checked the monitor with a different PC, it is o.k.
>> 
>> I did a "guix pull" on Thursday.
>> 
>> on Friday the problems occured.
>> 
>> Today I did a "guix pull" and a "sudo system reconfigure..." again,
>> it did not help.
>> 
>> When I started the "Enlightenment" Desktop, then the additional monitor 
>> worked.
>> 
>> So it is sure that MATE makes problems.
>> Does somebody have the same trouble?
>> 
>> 
>> Kind regards
>> 
>> Gottfried
>> 
>> 
>

Re: rollback

[Julien Lepiller]

This is the right command. It rolls back the system generation only, not the 
guix pull profile, which would be rolled back with "guix pull —roll-back". You 
don't need to roll it back though, only the system profile where MATE is 
installed.

Le 6 mai 2023 17:23:30 GMT+02:00, Gottfried  a écrit :
>Hi,
>since I can not use MATE Desktop now
>I am considering to rollback.
>
>It is not a question of packages like
>guix package --rollback
>
>but a question of MATE Desktop
>
>is this the right command to rollback one Generation of the system,
>
>because MATE is updated by the
>
>"$ sudo guix system reconfigure /etc/config.scm" ?
>
>sudo guix system roll-back
>
>AFAIU this command rolls back "guix pull" and the guix system wide updates.
>
>
>Kind regards
>
>Gottfried
>

Re: guix command line behavior upon network failure or package build failure

[Julien Lepiller]

Failing earlier might still be friendlier, as guix will not be working for 
nothing. When guix upgrade fails, nothing is upgraded, after all.

Guix has the --keep-going option you can use to continue downloading/building 
packages unrelated to the failure.

Le 16 avril 2023 08:48:41 GMT+02:00, Andy Tai  a écrit :
>The user facing guix command has two modes of failure as I have seen,
>when doing "guix upgrade" or "guix package -u":
>
>1. if when downloading substitutes, if downloading fails due to
>network conditions, the whole command errors out (exits)
>
>2. if some software has to be built locally, and if the build fails,
>the whole command errors out (exits)
>
>is it possible to have the guix command keeps going and finishes other
>works that may be unrelated to the failure, and finally prints out
>messages about the packages that failed to update?This would be
>more user friendly and makes guix more usable for end users. Thanks
>

Re: Newbie: What's the importance of *.drv, *.-builder, etc. files in /gnu/store?

[Julien Lepiller]

Going step by step, Guix performs the following.

First, it needs to download the original sources of the package. When creating 
a store item, most of the time, the guix daemon is involved.

The daemon's purpose is to take a lower-level representation of a build 
procedure and turn that into an isolated build environment. This is called a 
*derivation* and it is stored in the store as a `drv` file. For downloading a 
file, the derivation simply contains the URL to download and the daemon 
performs the download itself, so no isolated environment is required here.

Then, the package contains a directive that informs Guix there is some sort of 
change to make in the source. There is an issue in the upstream sources, and we 
need to apply a patch. A `.patch` file is a standard file used in many projects 
to represent one or more changes to a file or a directory. It's not specific to 
Guix.

To apply the file, the daemon needs to create an isolated build environment 
where it can apply the patch. Although a derivation can specify how to make a 
build environment (it specifies inputs (dependencies), the type of system, 
expected output, etc), it does not say *what* to do with it.

The guix daemon does not run inside the isolated build environment (the 
"build-side"), but it needs to run something in it to get things done, somehow. 
This is the role of the builder, which is created by Guix and is derived from 
the package definition. It's a standalone Guile script that is executed on the 
build-side.

On the build-side, the builder extracts the original archive, applies the patch 
and archives the result as a new `.tar.xz` file.

Now, Guix is ready to build transmission. To do so, it creates a new derivation 
`.drv` that instructs the daemon how to make the isolated environment for 
building it, and a builder `-builder` that the daemon will execute inside the 
environment. The build results in the transmission outputs.

To summarize, Guix needs to:

- Download original sources, which creates a derivation (drv) and results in 
downloading a tar.xz to the store.
- Put a patch (.patch) in the store from its own sources, which doesn't create 
a derivation. This is because a derivation can only refer to another store item.
- Apply the patch to the sources, which creates a derivation (.drv) and a 
builder (tar.xz-builder) that result in creating a modified tar.xz in the store.
- Build the transmission package, which creates a derivation (drv) and a 
builder (-builder) that result in the transmission outputs you wanted in the 
first place.

HTH!

Re: static-networking-service-type: Using a static network bridge

[Julien Lepiller]

Le Mon, 27 Mar 2023 19:37:53 +0200,
Denis 'GNUtoo' Carikli  a écrit :

> On Fri, 24 Mar 2023 18:14:48 +0100
> Julien Lepiller  wrote:
> 
> > The type should be a string, so "bridge" would be correct. However,
> > it's not supported by guile-netlink yet, sorry. Do you think you
> > could send me a scenario with iproute2 commands so I ean test an
> > implementation?  
> What is a scenario here?
> 
> If it's about reproducing a setup with bridges something like that is
> probably the easiest for the creation of the bridge:
> 
> +-->[eth0]<>Local
> network<-->Router<-->Internet |
> +--+v  +--+
> | VM1 [eth0]<--> [br0] <-->[eth0] VM2 |
> +--+   +--+
> 
> The bridge would be created with:
> > sudo ip link add br0 type bridge
> > ip link set dev br0 up  
> 
> Then the host eth0 can joint it like that:
> > sudo ip link set dev eth0 master br0
> > sudo ip link set dev eth0 up  

OK, I figured it out. So, bridges are actually supported in
guile-netlink, and here is how you would do that with guile-netlink:

> (link-add "br0" "bridge")
> (link-set "br0" #:master "eth0")

So, you should be able to add the bridge with

> (network-link (name "br0")
>   (type "bridge"))

However, I don't see link-set being used except for setting interfaces
UP in the networking-service in Guix, so I think this is not yet
supported. It should not be too difficult to do though.

Probably, adding some more optional fields in static-networking-link
for the arguments supported by link-set, then call link-set with these
arguments when they are set. Do you think you could come up with a
patch for that?

If you want to add an IP address to the new link, we probably also need
to reverse the link and addr order in network-set-up/linux.

With such a patch, you should then be able to write something like

> (network-link (name "br0")
>   (type "bridge")
>   (master "eth0"))

WDYT?

Re: Newbie: How to see progress during 'build' phase?

[Julien Lepiller]

When the build process for the package outputs percentages, we can know what 
the progress is, and guix will show a progress bar. However, many packages do 
not show progress, so we just spin a dash for every line of log the process 
outputs. If you want to see the logs and het hypnotized by it, you can use -v2.

Le 28 mars 2023 02:38:04 GMT+02:00, Rodrigo Morales 
 a écrit :
>I'm downloading and building some heavy packages in Guix. Therefore, the
>build phase usually takes more than 10 minutes. During that process, I
>see the message a slash character that is rotating and the message
>'build' phase. I wish I could see the progress of that phase?
>
>Is it possible to show the progress or at least information of the build
>phase? Is there a flag for the guix command that enables this behavior?

Re: static-networking-service-type: Using a static network bridge

[Julien Lepiller]

The type should be a string, so "bridge" would be correct. However, it's not 
supported by guile-netlink yet, sorry. Do you think you could send me a 
scenario with iproute2 commands so I ean test an implementation?

Le 24 mars 2023 00:08:50 GMT+01:00, Denis 'GNUtoo' Carikli 
 a écrit :
>On Wed, 22 Mar 2023 07:24:01 +0100
>Julien Lepiller  wrote:
>
>> You specified type twice, with #f the last time. Maybe that's tge
>> issue?
>Sorry my bad: I messed up the indentation, so it makes it look like
>type is specified twice.
>
>When doing sudo guix system reconfigure I get that:
>> guix system: warning: exception caught while executing 'start' on
>> service 'networking':
>> Throw to key `no-such-device' with args `("lan0")'.
>> guix system: warning: some services could not be upgraded
>> hint: To allow changes to all the system services to take effect, you
>> will need to reboot.
>
>So I'll try to rephrase and split the question: Is the following correct
>to create a bridge:
>> (network-link (name "lan0")
>>   (type 'bridge)
>>   (arguments '()))
>Or is that supposed to only work on existing interfaces? Or am I
>supposed to add something inside arguments to create the bridge?
>
>The issue is that I only managed to understand what to put in name and
>type with the Guix manual. The documentation describes arguments as
>"List of arguments for this type of link.", and it then point to "Link
>in Guile-Netlink Manual" which points to
>https://git.lepiller.eu/guile-netlink/manual/manual.html#Link
>
>But it doesn't tell how the correspondence between arguments and that
>manual section is made. Do arguments expect some string? some state
>(like IF_OPER_UP?), the same arguments than type-args?, a link datatype?
>
>Though the guile-netlink documentation is very easy to use to create a
>bridge and give it an address:
>> (link-add "lan0" "bridge")
>> (addr-add "lan0" "192.168.10.7/24")
>but I've no idea how to translate that in Guix configuration.
>
>As for making a device join a bridge I'm also unsure how to do that. I
>didn't find any infos for that in the Guix manual or the guile-netlink
>documentation, so maybe that's not supported?
>
>If that's not supported, udev can still be used to run commands with
>things like that:
>> (udev-rule "bridge.rules"
>> "SUBSYSTEM==\"net\", [some way to indentify the interface], \\
>> ACTION==\"add\", \\
>> RUN+=\"/run/current-system/[...]/ip link set dev $name master
>> lan0\""))
>and it works for other things (like changing MAC addresses with
>macchanger, etc).
>
>So does udev run late enough to already have the bridge interface
>created when something like that would run? Or is there something that
>could work with Guix static-networking-service-type somehow?
>
>Thanks a lot in advance for the help.
>
>Denis.

Re: How to properly upgrade Guix System & Home?

[Julien Lepiller]

Most likely, you're just seeing a weird behavior caused by grafts. To make a 
graft, guix needs the ungrafted package first, so it downloads it, grafts it 
and adds it to the profile. The grafted package is live, so it's protected 
against garbage collection. The ungrafted package is not, so it gets garbage 
coldected.

When you reconfigure, guix needs to download the ungrafted package before it 
figures out it already has the graft.

Since they have the same name and version, I think you're just cwnfusing the 
two :)

Le 22 mars 2023 18:11:45 GMT+01:00, Tanguy LE CARROUR  a 
écrit :
>Hi Guix,
>
>For quite some time, I'd been religiously upgrading my system weekly.
>My mantra was something along those lines:
>
>```console
>$ sudo guix system delete-generations
>$ guix package --delete-generations
>$ guix gc
>$ guix pull
>$ sudo guix system reconfigure my-system.scm
>$ guix package --upgrade
>```
>
>I was happy with it, but two recent events made me question my faith in this…
>
>1) I realized that there was a third `delete-generations`!
>
>Believe it or not, I didn't know about `guix pull --delete-generations`.
>Actually `guix pull --list-generations` was listing a **lot** of month
>old stuff.
>
>2) I migrated to Guix Home!
>
>Suddenly everything I thought I understood didn't seem to make any sense
>any more! For instance, I can do `guix home reconfigure` and `guix gc` in
>a loop and `guix home reconfigure` will keep on downloading things and
>`guix gc` will keep on deleting them!? And when I say "things", I mean
>packages that are explicitly declared in `my-home.scm` and that I actually use!
>When I compare `ls -l (which imv)` before and after a cycle
>(`guix home reconfigure` / `guix gc`), I have the same hash.
>Which make sense because I haven't `guix pull` in between. So, why is a `imv`
>garbage collected and re-downloaded/installed?!
>
>Does it make any sense? Am I the only one facing this issue? What's the
>proper way of upgrading a Guix System & Home?
>
>Any help would be very much appreciated!
>

Re: static-networking-service-type: Using a static network bridge

[Julien Lepiller]

You specified type twice, with #f the last time. Maybe that's tge issue?

Le 22 mars 2023 01:32:48 GMT+01:00, Denis 'GNUtoo' Carikli 
 a écrit :
>Hi,
>
>Is it possible to do something like that in a system configuration?:
>> ip link add lan0 type bridge
>> ip link set dev eth0 master lan0
>> ip addr add 192.168.1.5/24 dev lan0
>> ip route add default via 192.168.1.1 dev lan0
>
>I've tried it with something like that (with the IP addresses and "eth0"
>changed):
>> (service static-networking-service-type
>>   (list
>> (static-networking
>>   (addresses (list (network-address
>> (device "lan0")
>> (value "192.168.1.5/24"
>>(links (list (network-link (name "lan0")
>>(type 'bridge)
>>(arguments '()))
>>(network-link
>>(name "eth0")
>>(type #f)
>>(arguments '("master" "lan0")
>> (name-servers '("192.168.10.1"))
>> (routes (list (network-route (destination "default")
>>  (gateway "192.168.1.1")))
>but the issue is that the bridge isn't even created.
>
>Did I do something wrong, or is that configuration not supported?
>
>Denis.

Re: Newbie: Error when using "guix gc -D" to delete directory in /gnu/store

[Julien Lepiller]

First of all, you don't need to delete these files. Even if they exist in the 
store, they won't be foumd by other software unless they are currently 
installed in one of your profiles.

The error you get when you try to delete them means that one of the generations 
of one of your profiles still has a reference to them. You should have a look 
at the symlinks at /var/guix/profiles to fehure out which profile and which 
generetion that is.

Le 19 mars 2023 01:33:56 GMT+01:00, Rodrigo Morales 
 a écrit :
>Table of Contents
>_
>
>1. The context
>2. What I've tried
>3. Additional information
>4. The question
>
>
>1 The context
>=
>
>  I had previously installed the package `rime-data'. One of the files
>  that is installed by that package is called `wubi86.dict.yaml'.
>
>  I'm currently experimenting with `ibus' and I need all files that
>  exist in `/gnu/store' that are called `wubi86.dict.yaml' to be deleted
>  from my system. I've located those files, but when I try to delete
>  those files, I get the following error
>
>  ,
>  | guix gc -D /gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile
>  `
>
>  ,
>  | finding garbage collector roots...
>  | guix gc: error: cannot delete path
>`/gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile' since it is still
>alive
>  `
>
>  See next section to see what I've tried to delete those directories.
>
>
>2 What I've tried
>=
>
>  I know how to locate all files that are called `wubi86,dict.yaml' and
>  are located under `/gnu/store'
>
>  ,
>  | sudo updatedb
>  `
>
>  ,
>  | locate 'wubi86.dict.yaml'
>  `
>
>  ,
>  |
>/gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile/share/rime-data/wubi86.dict.yaml
>  |
>/gnu/store/b3f1s6nnj1rg7szcmb3n3y194ayhfgja-rime-data-0.38.20210802/share/rime-data/wubi86.dict.yaml
>  |
>/gnu/store/zj0cf20jk3qgl12451znx1n8rj13z2jg-profile/share/rime-data/wubi86.dict.yaml
>  `
>
>  If I try to delete any of those directories using `guix gc -D', I get
>  the same error (please see code blocks below)
>
>  ,
>  | guix gc -D /gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile
>  `
>
>  ,
>  | finding garbage collector roots...
>  | guix gc: error: cannot delete path
>`/gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile' since it is still
>alive
>  `
>
>  ,
>  | guix gc -D
>/gnu/store/b3f1s6nnj1rg7szcmb3n3y194ayhfgja-rime-data-0.38.20210802
>  `
>
>  ,
>  | finding garbage collector roots...
>  | guix gc: error: cannot delete path
>`/gnu/store/b3f1s6nnj1rg7szcmb3n3y194ayhfgja-rime-data-0.38.20210802' since
>it is still alive
>  `
>
>  ,
>  | guix gc -D /gnu/store/zj0cf20jk3qgl12451znx1n8rj13z2jg-profile/
>  `
>
>  ,
>  | finding garbage collector roots...
>  | guix gc: error: cannot delete path
>`/gnu/store/zj0cf20jk3qgl12451znx1n8rj13z2jg-profile' since it is still
>alive
>  `
>
>
>3 Additional information
>
>
>  I found [this thread] in the help-guix mailing list on the same
>  topic. In [this reply], someone mentions that it is possible to list
>  the referrers to see which directories are pointing to those
>  directories. This is the output of those command.
>
>  For the two directories that end in `*-profile', `guix gc --referrers'
>  print the directory itself.
>
>  ,
>  | guix gc --referrers /gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile
>  `
>
>  ,
>  | /gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile
>  `
>
>  ,
>  | guix gc --referrers /gnu/store/zj0cf20jk3qgl12451znx1n8rj13z2jg-profile/
>  `
>
>  ,
>  | /gnu/store/zj0cf20jk3qgl12451znx1n8rj13z2jg-profile
>  `
>
>  For the directory, that has the files from the package, a lot of files
>  ending with `drv' is shown.
>
>  ,
>  | guix gc --referrers
>/gnu/store/b3f1s6nnj1rg7szcmb3n3y194ayhfgja-rime-data-0.38.20210802
>  `
>
>  ,
>  | /gnu/store/0wr0x4v73wiks87843njqqf590fm0xix-glib-schemas.drv
>  | /gnu/store/252h4ryvdj3d3bgnm1v47s7838wn86nz-profile
>  | /gnu/store/4zpl6kqdb1ppnc0a1wbh50az8bhnzc4z-gtk-icon-themes.drv
>  | /gnu/store/7qjr2v4w4m8kp1mzax2w840mg489120m-emacs-subdirs.drv
>  | /gnu/store/8qjbmddr1x6v4pjwxm8i5alslxb7ca43-profile.drv
>  | /gnu/store/8ziy5i9svd645iinf850cnca82vb154s-ca-certificate-bundle.drv
>  | /gnu/store/a8n5pfdh03lwfrcpp6823bnwlgh5in13-xdg-desktop-database.drv
>  | /gnu/store/ascqql7fl3c7r784hpnqcam3x8f78dmg-info-dir.drv
>  | /gnu/store/bwlk4j71l97vk84pzdddra2fpvn9zvj5-fonts-dir.drv
>  | /gnu/store/d9dhmxg8b87jj8n797vyabdc2dimr2aw-ibus-rime-1.5.0
>  | /gnu/store/h4qckgajdkz7rm8yrwrxqv882mr1mnnm-emacs-rime-1.0.5
>  |
>/gnu/store/hlrfay6rcgh9c5wzzcj7wf7iwzf87msc-gdk-pixbuf-loaders-cache-file.drv
>  | /gnu/store/nbhwrpx1py3j4sivysv6xi5s4hx4ziqz-gtk-im-modules.drv
>  | /gnu/store/px3idmv8x0ws0zs2n7scgbi302af7iaw-xdg-mime-database.drv
>  | /gnu/store/qczdrj7c8wyszygw78yi9ngz46lhyylv-ibus-rime-1.5.0
>  | /gnu/store/zj0cf20jk3qgl12451znx1n8rj13z2jg-profile
>  `
>

Re: bad use of syntactic keyword

[Julien Lepiller]

Ah but the home-redshift-service-type is a home service, not a system service. 
It's meant to be used with guix home, not guix system.

Le 11 mars 2023 11:15:20 GMT+01:00, Gottfried  a écrit :
>Hi,
>thanks for help
>
>I have now got:
>
>> (service home-redshift-service-type
>>  (home-redshift-configuration
>>   (location-provider 'manual)
>>   (latitude 52.5);northern hemisphere
>>   (longitude 13.5))) ;Berlin
>> (modify-services %desktop-services
>>   (guix-service-type
>>config => (guix-configuration
>>  (inherit config)
>>  (extra-options (list "--gc-keep-derivations=yes" 
>> "--gc-keep-outputs=yes"
>> (sane-service-type _ => sane-backends)
>
>but running system reconfigure..
>I am getting now another message:
>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> error: home-redshift-service-type: unbound variable
>.
>I copied the "redshift-service-type" part
>from the manual into my config.scm
>so I don’t find the "unbound variable".
>
>Kind regards
>
>Gottfried
>
>
>
>Am 09.03.23 um 18:20 schrieb Julien Lepiller:
>> You have an extra closing parenthesis at the end of this line:
>> 
>> (extra-options (list "--gc-keep-derivations=yes" "--gc-keep-outputs=yes")
>> 
>> Remove one and adjust next lines if needed :)
>> 
>
>>> %base-initrd-modules)))
>>> 
>
>

Re: Mysteries of channel configuration during system reconfigure

[Julien Lepiller]

Le 11 mars 2023 01:16:21 GMT+01:00, Kyle Andrews  a écrit :
>
>Julien Lepiller  writes:
>
>> Does your /etc/channels.scm list the extra channels?
>
>At this point it does not. I "restored" a backup from my old computer
>into my home directory. Now I have several more channels than I had
>configured in generation one. Unfortunately, now my shepherd is broken
>just like on my old computer.
>
>I wish I understood how to experiment with e.g. virtual machines to
>better understand this process. However, there seems to be quite a large
>knowledge barrier. I also don't feel comfortable with my current
>capabilities exploring the Guix codebase to see what the relevant
>procedures are. There is a lot to learn!

I'm not sure what manages /etc/channels.scm, but I don't think Guix creates it? 
In any case, you use that file when pulling, so at the time you pull, you 
should list all the channels you want to use in that file.

>
>> "guix describe" will be more accurate about what channels your current
>> guix knows about.
>
>It's not clear to me what "your current guix" even is in my case. Does the 
>latest pull define the current guix?

It should, but what I meant by that is "whatever your shell believes it should 
run when you type guix"

>
>On my old computer guix system describe shows a slightly older revision
>of Guix channels than guix describe. Meanwhile, the root user's guix describe 
>shows just the one Guix channel with yet another commit.
>
>As a naive user, I'm understandably more scared that my computer will
>fail to boot if I upgrade, so I tend to run guix system reconfigure less
>frequently than guix pull.

If it fails to boot, you should still be able to select an older, known to 
work, generation at the grub screen. That's the magic of Guix :)

>
>> If you type "type guix" and "which guix", they should agree it's
>> ~/.config/guix/current/bin/guix, not something else like
>> ~/.guix-profile or ~/.guix-home or even /run/current-system
>
>I had never heard of the type command! I noticed type and which give
>different results for "type cd" and "which cd". I also noticed that which 
>--all guix shows two lines: the latter being /run/current-system.

cd is a builtin, so "type cd" should tell you that. "which" will only look for 
a binary in your $PATH, so it should report that it can't find it.

type itself is a builtin, and it will tell you what a binary is, according to 
the shell. Bash and other shells have a cache of command name to location. When 
you use "type guix" it should tell you where it finds guix, according to that 
cache. If it's different from "which guix", which only looks in $PATH, not in 
the shell cache, it means you should refresh that cache with "hash guix" (I 
think hash is also a builtin).

If which does not tell it's your pulled guix (ie. 
~/.config/guix/current/bin/guix), it means your $PATH is not set properly.

A guix command could come from different locations in your system. At least one 
is installed with your system at /run/current-system.

>
>I have to admit I'm not still sure what general insight I should be gleaning 
>from your statement, however it sounds like it is pretty neat.
>
>> If you reconfigure as the root user, you should pull as the root
>> user. If you use sudo, which is recommended, make sure that the above
>> works properly with sudo too.
>
>I'm curious to learn more about your rationale for this statement as I
>was successful at building a second generation only once I used the "sudo" 
>path with my non-root user.

Your user's and root's guix are different, as you noticed. So, I was just 
wondering whether you were doing something like su then reconfigure, or sudo 
guix. When you use su, you login as root, and use root's guix. When you sudo, 
you run the user program with root priviledges, which is quite different in 
that case.

With su, you run root's guix, so you should pull as root. With sudo, you run 
the user's guix, so you should pull as a user (don't pull with sudo, it will 
mess up rights in your home directory).

Also, I don't personnaly use the recommended way as I find sudo confusing. I 
wanted to make sure the above is correct, so does "guix describe" give you the 
same as "sudo guix describe"?

>
>Thanks for your help!

Re: Mysteries of channel configuration during system reconfigure

[Julien Lepiller]

guix system describe lists channels used to build your system, but they can be 
different from the ones currently known to guix.

Does your /etc/channels.scm list the extra channels?

"guix describe" will be more accurate about what channels your current guix 
knows about.

If you type "type guix" and "which guix", they should agree it's 
~/.config/guix/current/bin/guix, not something else like ~/.guix-profile or 
~/.guix-home or even /run/current-system

If you reconfigure as the root user, you should pull as the root user. If you 
use sudo, which is recommended, make sure that the above works properly with 
sudo too.

Le 9 mars 2023 03:50:29 GMT+01:00, Kyle Andrews  a écrit :
>
>Dear Guix,
>
>I am trying (and failing) to setup a new computer with Guix. I managed
>to get through the installation process with a configuration that boots
>into GNOME. However, the keyboard is messed up (I made a typo) and I
>don't yet have the desktop environment up and running I actually feel
>productive using. GNOME places too many extraneous demands on my
>attention. There is a lot going on and I find all the beeping
>unsettling. So I am typing this email on my old computer with Guix.
>
>One of the selling points in Guix marketing for me is that the system
>configuration should be self contained within /etc/config.scm and
>channels.scm. However, this appears to not be the case. There seems a
>third element hidden away which prevents me from running:
>
>```
>guix system reconfigure /etc/config.scm
>```
>
>This command errors out:
>
>```
>failed to load '/etc/config.scm'
>...
>no code for module ...
>```
>
>At the moment since I am still very early in setting up my new computer,
>I have to type everything so I'm not going to go into more detail than
>that. Suffice to say it doesn't see the modules I need from the extra
>channel. It did see them during the installation otherwise my computer
>would be in a far less usable state than it is.
>
>When I run the following command:
>
>```
>guix system describe
>```
>
>The addition channel gets listed. How can it be listed yet be unknown to
>the `guix system reconfigure` command?
>
>During the installation of my new computer I used guix pull -C
>/etc/channels.scm. I was struggling with the official documentation, so
>this was kind of an improvisation. Could doing this nonstandard action
>have lead to this nonstandard state? Can it be fixed? 
>
>I tried running the commands with the root user and with prefixing
>sudo. Neither variat produces the desired result: a new configuration
>with the correct keymap and my next steps towards setting up my desktop
>environment.
>
>Thanks in advance for your help!
>
>Cheers,
>Kyle
>

Re: bad use of syntactic keyword

[Julien Lepiller]

You have an extra closing parenthesis at the end of this line:

(extra-options (list "--gc-keep-derivations=yes" "--gc-keep-outputs=yes")

Remove one and adjust next lines if needed :)

Le 9 mars 2023 17:49:43 GMT+01:00, Gottfried  a écrit :
>Hi,
>
>after adding: "service redshift" to my config.scm
>
>running
>
>sudo guix system configure /etc/config.scm
>
>it says:
>
>guix system: Fehler: _: bad use of '_' syntactic keyword
>
>german Fehler = mistake
>
>I don’t know where is my mistake.
>
>here my config.scm:
>
>;; This is an operating system configuration generated
>;; by the graphical installer.
>
>(use-modules (gnu))
>(use-package-modules cups scanner)
>(use-service-modules cups desktop networking ssh xorg virtualization)
>
>(operating-system
>  (locale "de_DE.utf8")
>  (timezone "Europe/Berlin")
>  (keyboard-layout (keyboard-layout "de"))
>  (host-name "Tuxedo")
>  (users (cons* (user-account
>  (name "gfp")
>  (comment "Gfp")
>  (group "users")
>  (home-directory "/home/gfp")
>  (supplementary-groups
>'("wheel" "netdev" "audio" "video" "libvirt")))
>%base-user-accounts))
>  (packages
>(append
>  (list (specification->package "nss-certs"))  
>  %base-packages))
>  (services
>(append
>  (list (service mate-desktop-service-type)
>(service enlightenment-desktop-service-type)
>   (service cups-service-type
>   (cups-configuration
>   (web-interface? #t)
>   (extensions (list cups-filters 
> hplip
>   (service openssh-service-type)
>(service tor-service-type)
>(set-xorg-configuration
>  (xorg-configuration
>   (keyboard-layout keyboard-layout)))
>(service libvirt-service-type
> (libvirt-configuration
>  (unix-sock-group "libvirt")
>  (tls-port "16555")))
>(service virtlog-service-type
> (virtlog-configuration
>  (max-clients 1000)))
>(service home-redshift-service-type
> (home-redshift-configuration
>  (location-provider 'manual)
>  (latitude 52.5);northern hemisphere
>  (longitude 13.5))) ;Berlin
>(modify-services %desktop-services
> (guix-service-type
>   config => (guix-configuration
> (inherit config)
> (extra-options (list "--gc-keep-derivations=yes" 
> "--gc-keep-outputs=yes")
>   (sane-service-type _ => sane-backends
>
>  (bootloader
>(bootloader-configuration
>  (bootloader grub-efi-bootloader)
>  (targets (list "/boot/efi"))
>  (keyboard-layout keyboard-layout)))
>  (swap-devices
>   (list (swap-space
>  (target (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")
>  (file-systems
>(cons* (file-system
> (mount-point "/boot/efi")
> (device (uuid "BB77-FE3B" 'fat32))
> (type "vfat"))
>   (file-system
> (mount-point "/")
> (device
>   (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
> 'ext4))
> (type "ext4"))
>   %base-file-systems))
>  (initrd-modules (cons "virtio_scsi"; Needed to find the disk
>%base-initrd-modules)))
>
> 
>Thanks for help
>
>Kind regards
>
>Gottfried
>

Re: Newbie question: Why my system has so many shells.scm files?

[Julien Lepiller]

Another possibility is to use guix gc -R `readlink -f /path/to/a/profile`. Note 
that you have multiple profiles (system, user, pull, maybe home).

The command lists all live paths under a given store path. In this case, all 
that is accessible to the profile you asked for. It's granularity is the store 
path, not exact files, so even a store path is live and has a shells.scm in it, 
doesn't mean it's actually used.

Also, the shells.scm you found can be split in two categories. There are two 
different guile modules:

(gnu packages shells) has packages related to shells (bash, zsh, …)
(gnu home services shells) has service definitions for guix home that are 
related to shells (creating a bashrc for instance)

Some of the store paths you mention seem to be sources that could probably be 
garbage collected.

Le 5 mars 2023 02:04:45 GMT+01:00, "宋文武"  a écrit :
>Rodrigo Morales  writes:
>
>> Table of Contents
>> _
>>
>> 1. The context
>> 2. The question
>>
>>
>> 1 The context
>> =
>>
>>   Newbie user here. I'm curious about how `home-bash-configuration'
>>   works, so I wanted to jump to its definition. I know that one way of
>>   doing this is cloning the Guix repository and executing grep to search
>>   that string. In fact, I did this and found it in
>>   `gnu/home/services/shells.scm'.
>>
>>   Using common sense, I knew that that file also existed in my system,
>>   so I was wondering how I could have accomplished the same objective
>>   without having to download the Git repository, just in case some day I
>>   don't have internet connection
>>
>>   ,
>>   | locate shells.scm | grep '/gnu/store'
>>   `
>> [...]
>>
>> 2 The question
>> ==
>>
>>   How to know which of these files is currently being used by my
>>   system?  I'm sure not all of them are being used. I'm somewhat
>>   familiar with how generations work, but in other words, I'd like to
>>   know how to determine which of these files is the one that is being
>>   used by the current generation.
>
>First to find out what files are currently going to be used the system:
>
>  $ guix repl
>  > %load-path
>
>I got:
>```
>$1 = 
>("/gnu/store/sg5mf194lisl59b1bm3a7x6llf3vvhlv-guix-module-union/share/guile/site/3.0"
> "/gnu/store/qbqdkziw7222077fn4z2x5n91185ivis-guile-3.0.9/share/guile/3.0" 
>"/gnu/store/qbqdkziw7222077fn4z2x5n91185ivis-guile-3.0.9/share/guile/3.0" 
>"/gnu/store/qbqdkziw7222077fn4z2x5n91185ivis-guile-3.0.9/share/guile/site/3.0" 
>"/gnu/store/qbqdkziw7222077fn4z2x5n91185ivis-guile-3.0.9/share/guile/site" 
>"/gnu/store/qbqdkziw7222077fn4z2x5n91185ivis-guile-3.0.9/share/guile" 
>"/home/iyzsong/.config/guix/current/share/guile/site/3.0" 
>"/run/current-system/profile/share/guile/site/3.0"
>```
>
>In the first directory, it has:
>  
> /gnu/store/sg5mf194lisl59b1bm3a7x6llf3vvhlv-guix-module-union/share/guile/site/3.0/gnu/home/services/shells.scm
>  
>These scm files are guile modules, which will be used by the time 'guix' run.
>
>
>And to find out what the current generation are using, first you need to
>find out what guix version(s) being used.
>For system profile, /run/current-system/provenace or
>/run/current-system/channels.scm has the version (guix commit) info.
>For user profile, ~/.guix-profile/manifest have it in the provenance property.
>
>Then given the commit, how to get the files?
>
>If you 'guix pull' before as I did, it can be:
>```
>cd ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
>git checkout -f ${COMMIT}
>```
>
>Or 'guix pull --commit ${COMMIT}', or git clone a new guix repository...
>
>
>Hope this helps!
>

Re: Newbie user question: How to delete all files in /gnu/store related to a package definition?

[Julien Lepiller]

Hi Rodrigo,

>   ,
>   | finding garbage collector roots...
>   | guix gc: error: cannot delete path
> `/gnu/store/2j9gykgj0axgg193pd6hvrmnzqbz88nm-font-noto-color-emoji-2.034.drv'
> since it is still alive
>   | Exit code: 123
>   `

As it says, that store path is still alive, but why?

When you install a package, remove a package, or do anything in your
user profile, guix will create a new "generation" of the profile that
contains the same items as the previous generation, except for what you
asked it to do. So when removing a package with `guix remove foo`, you
cerate a new generation of the profile, where package "foo" is not
present.

Old generations of your profile are considered live, and are protected
against garbage collection, so you can roll back to them easily in case
something goes wrong with the new generation.

Try this:

guix package --roll-back

Now, you should be able to use your font again!

You can list the generations with

guix package --list-generations

and go back to the most recent one with

guix package --switch-generation= where  is the generation number
given in the previous command.

You can also remove old generations of your profile, for instance, all
but the current one:

guix package --delete-generations

and then, you should be able to collect that store path :)

HTH!

Re: package store directory in custom location

[Julien Lepiller]

Hi Andy,

so you could change the store location, but it would just create the same stone 
structure as /gnu/store elsewhere, with the same issues and no substitutes.

Instead you could try to create a relocatable pack of python, and untar it 
somewhere writable. There might be a small runtime penalty, but we're talking 
about python anyway :)

HTH!

Le 26 février 2023 02:03:01 GMT+01:00, Andy Tai  a écrit :
>Hi, is it possible to have  a /gnu/store/ directory for a package in a
>custom path?  A usage scenario is, say, to have a python interpreter,
>with its package directory that normally exists as
>/gnu/store/, to be somewhere I specified, so it would be
>possible to use that python with python's package manager to install
>python modules as site packages specific to this python (as it is not
>easy to have all python modules available as packages in Guix)
>
>If this python can only run from the /gnu/store/... directory, trying
>to install site packages would normally fail (as /gnu/store/... is
>read only to non root user) and not good practice anyway (as
>/gnu/store/... is not meant to be user touched but only managed by
>Guix)
>

Re: guix running advice: correct?

[Julien Lepiller]

Ah, the guix pull profile comming first is not absolute. It's simply that some 
users might have installed guix in their default profile, and if that profile 
comes before guix pull, that huix will be used. Any guix upgrade will then 
doongrade your profile.

This shouldn't be ppssible anymore, since guix should do the right thing now 
when setting the shell profile files, and it would warn if you attempted a 
dpongrade.

Le 5 février 2023 00:16:37 GMT+01:00, Kyle Andrews  a écrit :
>
>Julien Lepiller  writes:
>
>> Hi Andy,
>>
>> I'm the author of this advice. I think it's still correct. It's mostly
>> sanity checks that you would run to ensure you can get packages from
>> this channel. Most of it is scattered around the manual, mostly in the
>> manual installation documentation.
>>
>> ~/.config/guix/current is where your new guix (the one you pulled with
>> the channel) is installed. If it's not first in $PATH, you're at risk
>> that some other guix will be used instead.
>>
>> hash is a command that removes an entry from the shell's cache. If
>> this is your first pull, the guix you used comes from another location
>> that is recorded by the shell, so you have to clear the cache to use
>> the newly pulled guix. If your guix already comes from the correct
>> location, it'll be useless but it won't hurt.
>>
>> HTH!
>>
>> Le 3 janvier 2023 06:31:25 GMT+01:00, Andy Tai  a écrit :
>>>Hi, from this page
>>>https://framagit.org/tyreunom/guix-android/-/blob/master/README.md
>>>
>>>Important checks
>>>Make sure your guix environment is set up properly. You need to have
>>>~/.config/guix/current as the first item in your $PATH or you're going
>>>to run into troubles. Additionally, after running guix pull, make sure you
>>>run hash guix in any open terminal to make sure bash's cache is cleared of
>>>the old guix binary location.
>>>
>>>I wonder if the above is correct, as I do not recall seeing anything in
>>>Guix doc mentioning such advice or something to that effect (unless I
>>>missed it)
>
>Interesting. I too had never heard about this PATH recommendation and it
>seems contrary to some advice I do remember given in the cookbook about
>working with multiple profiles. For me, activating an extra profile
>places it's /bin and /sbin directories at the beginning of my PATH. I can
>only find ~/.config/guix/current/bin burried quite deep near the end.
>
>Do you have any advice on how regular end users could follow your
>recommendation?
>
>My naive hope would be that end users wouldn't have to think about
>it. Ideally if its that dangerous then updating the path would happen
>automatically when sourcing the etc/profile file inside a profile
>directory.
>
>Should the Guix Profiles in Practice section of the cookbook be updated
>to reflect this?
>
>
>
>

Re: grub-install failing while system reconfigure

[Julien Lepiller]

This happened to me recently. The system wouldn't even boot after that… It 
seems the issue is that grub appends some config in bios NV memory, which is 
separate from your EFI partition, and it filled up.

I found two potential solutions: remove the variables (somewhere in /sys I 
think) or enter bios and factory-reset it. After that, guix won't boot, so I 
had to use an installation disk and follow "entering a chroot" from the manual 
to reconfigure the system and finally boot. Grub now looks funny, but it worked 
:)

Le 15 janvier 2023 07:03:06 GMT+01:00, Akib Azmain Turja  a 
écrit :
>
>grub-install is saying no space left, but I still have much space
>available in both root and EFI partition.
>
>--8<---cut here---start->8---
>akib@gnu-guix:~/dotfiles$ sudo guix system reconfigure 
>~/dotfiles/guix/system-config.scm
>The following derivation will be built:
>  /gnu/store/ss6c3krd1wwbg7kybdr8pkrl7jy3cc79-grub.cfg.drv
>
>building /gnu/store/ss6c3krd1wwbg7kybdr8pkrl7jy3cc79-grub.cfg.drv...
>/gnu/store/i3bl3mpy92hwm6v1n74slvyvlgnpg85g-system
>/gnu/store/hhm7spb2xdd6i5ci8p6wjs9dalv9g18a-grub.cfg
>
>activating system...
>making '/gnu/store/i3bl3mpy92hwm6v1n74slvyvlgnpg85g-system' the current 
>system...
>setting up setuid programs in '/run/setuid-programs'...
>populating /etc from /gnu/store/dkr38kkqiykn86qxmqq0vmd86kf8v7qr-etc...
>The following derivation will be built:
>  /gnu/store/77k62g58nhi9kaxfryfa3b54a9i53gd6-install-bootloader.scm.drv
>
>building 
>/gnu/store/77k62g58nhi9kaxfryfa3b54a9i53gd6-install-bootloader.scm.drv...
>guix system: error: 
>'/gnu/store/ch9q9w5zbvgq8srr6dscq6hdf03pfqb4-grub-efi-2.06/sbin/grub-install 
>--boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' 
>exited with status 1; output follows:
>
>  Installing for x86_64-efi platform.
>  Could not prepare Boot variable: No space left on device
>  /gnu/store/ch9q9w5zbvgq8srr6dscq6hdf03pfqb4-grub-efi-2.06/sbin/grub-install: 
> error: efibootmgr failed to register the boot entry: Input/output error.
>
>--8<---cut here---end--->8---
>
>-- 
>Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
>Fediverse: akib@hostux.social
>Codeberg: akib
>emailselfdefense.fsf.org | "Nothing can be secure without encryption."

Re: Guix supported-systems option

[Julien Lepiller]

That's how it's done with some packages that need arch-specific things (inputs, 
build phases, …) so yes :)

Le 14 janvier 2023 23:01:49 GMT+01:00, phodina  a écrit 
:
>Hi Julien,
>
>> I think you have multiple packages with the same name and version, but 
>> different supported systems. Am I right?
>
>you are correct. I have multiple package definitions as shown in the attached 
>scheme file.
>
>The names and versions are exactly the same, just the origin differs and Guix 
>picks "randomly" one of them.
>
>I did as you suggested to rename the packages - append the arch. This works in 
>short term but I'd like to have one profile and just apply it on my laptop 
>(x86_64) as well as on Raspberry Pi (aarch64, recently added to Guix by 
>Stefan).
>
>Having different names will then not work or results in even bigger mess with 
>if statements.
>
>> Now, supported-systems does not mean "remove this package on other 
>> architectures", but rather "can't build this on other architectures". So 
>> it's perfectly possible that guix will arbitrarily select a package for a 
>> different architecture.
>
>Well this is the reason I ask. I though this has deeper meaning as to tell 
>Guix, okay you found a package with that name, but it's not for current 
>architecture. So keep looking and if you don't find any other return this one 
>with a warning that it's not supported.
>
>So the "right" way would be conditionally select the right origin for the 
>package and use just one package definition with list of supported systems, 
>right?
>
>
>Petr

Re: Guix supported-systems option

[Julien Lepiller]

I think you have multiple packages with the same name and version, but 
different supported systems. Am I right?

If that is the case, then guix will select a package based on the specification 
you give it, so if you give a name, it will select the package with that name 
and the highest version available. If multiple packages match this criteria, 
one is selected arbitrarily.

Now, supported-systems does not mean "remove this package on other 
architectures", but rather "can't build this on other architectures". So it's 
perfectly possible that guix will arbitrarily select a package for a different 
architecture.

I can see two solutions: as you mentionned, get source depending on 
architecture, that way the other architecture packages are not defined. Another 
possibility is to append say -x86_64 to the package name.

Does it make sense?

Le 14 janvier 2023 20:33:13 GMT+01:00, phodina via  a écrit :
>Hello,
>
>I have recently uncovered a "feature" that works little bit than described in 
>the manual,
>
>During definition of a new variable, package, there is an option called 
>supported-systems​ which defaults to %default-systems​.
>
>However, if the package is known to work on certain architecture the right 
>thing is to list the supported architectures, right?
>
>If I select package which is not supported by my current architecture and 
>build it I get notification like this one:
>`warning: package grafana@9.3.2 does not support x86_64-linux`
>
>So suppose I have the same package for different architectures, each has it's 
>own unique tarball.
>
>I've defined one package and inherited from it, changing the source​ for the 
>other and selecting the correct supported-systems​.
>Unfortunately, this approach fails as Guix does not select the right package I 
>want to use on the current system.
>
>So should the approach be to define just one variable for the package and then 
>conditionally select the right tarball/git for the package?
>
>Also is this considered bug or a feature?
>
>FIY I know the right way would be to build Grafana from source in this case 
>which would solve the issue I just wanted to know in general more about the 
>use case of the supported-systems​ option.
>
>
>Petr

Re: guix running advice: correct?

[Julien Lepiller]

Hi Andy,

I'm the author of this advice. I think it's still correct. It's mostly sanity 
checks that you would run to ensure you can get packages from this channel. 
Most of it is scattered around the manual, mostly in the manual installation 
documentation.

~/.config/guix/current is where your new guix (the one you pulled with the 
channel) is installed. If it's not first in $PATH, you're at risk that some 
other guix will be used instead.

hash is a command that removes an entry from the shell's cache. If this is your 
first pull, the guix you used comes from another location that is recorded by 
the shell, so you have to clear the cache to use the newly pulled guix. If your 
guix already comes from the correct location, it'll be useless but it won't 
hurt.

HTH!

Le 3 janvier 2023 06:31:25 GMT+01:00, Andy Tai  a écrit :
>Hi, from this page
>https://framagit.org/tyreunom/guix-android/-/blob/master/README.md
>
>Important checks
>Make sure your guix environment is set up properly. You need to have
>~/.config/guix/current as the first item in your $PATH or you're going
>to run into troubles. Additionally, after running guix pull, make sure you
>run hash guix in any open terminal to make sure bash's cache is cleared of
>the old guix binary location.
>
>I wonder if the above is correct, as I do not recall seeing anything in
>Guix doc mentioning such advice or something to that effect (unless I
>missed it)

Re: Possible sources of environment variables

[Julien Lepiller]

I don't use guix on a foreign distro, so maybe I don't remember properly, but I 
think your profile is automatically sourced from /etc/profile.d or similar.

Le 30 décembre 2022 18:12:32 GMT+01:00, Tirifto  a écrit :
>Hello! I have a small problem that’s a bit odd, perhaps. I have some 
>environment variables defined to include Guix-related paths, but I have no 
>idea where they’re being defined.
>
>I was sourcing the ‘~/.guix-profile/etc/profile’ file from my ‘~/.profile’, 
>but after I commented that part of my ‘~/.profile’ out, I’m still getting the 
>Guix-related paths in $GDK_PIXBUF_MODULE_FILE, $PATH, and $XDG_DATA_DIRS (all 
>of which are defined in the Guix profile file), but also in $INFOPATH (which 
>is not in the Guix profile file). I don’t remember ever defining these 
>variables anywhere; sourcing the Guix profile from my shell profile is all 
>that I recall ever doing.
>
>I do define some other Guix-related variables manually, but all of those 
>concern locales or certificates for various programs. I wish to undo the other 
>paths being set by/for Guix, to make my environment temporarily unaware of 
>Guix even being installed, for troubleshooting purposes, but I can’t find out 
>how.
>
>I’m running Guix as a supplementary package manager on OpenSUSE 15.4, with KDE 
>as my desktop environment. I suppose this might not be Guix at fault, but just 
>me overlooking something while setting it up, or the host system doing 
>something I’m not familiar with, but perhaps someone has had a similar 
>experience? Any clues would be much appreciated!
>
>Best of wishes
>// Tirifto
>
>
>

Re: How do I install a file with custom permissions?

[Julien Lepiller]

Hi Timo,

Files in the store are always world-readable and there's nothing you can do to 
change that. There has been discussions in the past about how to handle secrets 
in the store, but no solution so far.

One thing you can do, if wireguard allows it, is to have the pre-shared key in 
a separate file out of the store and simply point the config to that file 
(instead of using a file-like object). This is how we handle other secrets so 
far.

Le 29 novembre 2022 20:24:13 GMT+01:00, Timo Wilken  a écrit :
>Hi Guixers,
>
>I'm trying to patch the `wireguard-service-type' to accept pre-shared
>keys and add them to the generated config. This all seems to work
>fine, except that I can't get guix to generate a non-world-readable
>configuration file.
>
>I've tried adding a `(chmod port #o400)' call to the end of the lambda
>that generates the config file (gnu/services/vpn.scm lines 784-838),
>but that seems to have no effect -- the resulting file at
>/gnu/store/...-wireguard-config/wg0.conf is still
>world-readable. Adding `(chmod #$config-file #o400)' after the
>`call-with-output-file' call doesn't work either.
>
>What do I need to do to make guix install the generated config file
>with 0400 permissions?
>
>Cheers,
>Timo
>

Re: "Unsupported manifest format" error, likely corrupt store

[Julien Lepiller]

Don't bother with guix refresh, it's meant for huix devs.

If you have a previous generation of your profile, you could try and switch to 
it (guix package --roll-back), but you said that didn't work. You can also 
switch manually by repeating the steps Guix would take behind the scenes, 
manually.

You'll notice that ~/.guix-profile is a symlink to 
/var/guix/profiles/per-user/tyler/guix-profile. It itself is a symlink to the 
current generation, a file such as guix-profile-17-link. Change that last 
symlink to point to the previous generation instead, such as 
guix-profile-16-link. That's all you need to switch generation. Hopefully, that 
generation's manifest is not corrupted.

Le 26 novembre 2022 22:34:11 GMT+01:00, Tyler Wolf via  a 
écrit :
>Hello,
>
>Yesterday my PC lost power and when I turned it back on I started getting the 
>error "guix package: unsupported manifest format".
>
>I have tried using "guix time-machine" to revert to a working commit and try 
>again but this does not work. I have also tried a roll-back.
>
>I then can see that my ~/.guix-profile/manifest is empty, thus I think it is 
>safe to say that this is where the issue is originating, however I am unable 
>to rewrite this file, so I was wondering if there was any fix to this?
>
>I have tried everything that I can think of to repopulate this file, running 
>guix pull as well as pulling certain past commits that worked, however nothing 
>is fixing this error. Running pull works without errors, but the problem 
>persists.
>
>I think that my store must be corrupt, as if I run guix gc --verify=contents I 
>get a lot of path was modified, expected hash x, got y errors. I have tried 
>fixing this using repair flag for gc but it is unable to repair these.
>
>I also used the command "guix refresh" and saw that many packages needed to be 
>refreshed, however I cannot finish this command as I get the following error:
>
>Backtrace:
>13 (primitive-load "/home/tyler/.config/guix/current/bin/g…")
>In guix/ui.scm:
>2275:7 12 (run-guix . _)
>2238:10 11 (run-guix-command _ . _)
>In ice-9/boot-9.scm:
>1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
>1752:10 9 (with-exception-handler _ _ #:unwind? _ # _)
>In guix/store.scm:
>661:37 8 (thunk)
>2170:25 7 (run-with-store # …)
>In guix/scripts/refresh.scm:
>567:14 6 (_ _)
>In srfi/srfi-1.scm:
>634:9 5 (for-each # …)
>In guix/scripts/refresh.scm:
>367:10 4 (check-for-package-update # …)
>In srfi/srfi-1.scm:
>858:15 3 (any1 # …)
>In guix/gnu-maintenance.scm:
>842:10 2 (_ _ . _)
>In ice-9/boot-9.scm:
>1685:16 1 (raise-exception _ #:continuable? _)
>1685:16 0 (raise-exception _ #:continuable? _)
>
>Any help would be greatly appreciated.
>
>Thanks,Tyler Wolf

Re: What passes in the inputs to the lambda?

[Julien Lepiller]

Le Sun, 20 Nov 2022 15:10:09 -0600,
jgart  a écrit :

> In the following snippet, what passes in the inputs to the lambda?
> 
> (modify-phases %standard-phases
>   (replace 'unpack
> (lambda* (#:key inputs #:allow-other-keys)
>   (let* ((source (assoc-ref inputs "source"))
>  (guile-dir (assoc-ref inputs "guile"))
>  (guile (string-append guile-dir "/bin/guile")))
> (invoke guile "--no-auto-compile" source)
> (chdir "bootar"
> 

The lambda you're talking about is a build phase of some package. These
phases are passed in order to the build system's build procedure. The
exact arguments passed to this lambda therefore depend on the way the
build procedure calls the phases. For instance, we see this in the
gnu-build-system:

(define* (gnu-build name inputs
#:key
[...])
  [...]
  #~(gnu-build #:source source
   [...]))

This inner gnu-build is actually a reference to the build side's
gnu-build, not the host side (because it's gquoted (if that's a word
:p)), and it's defined in (guix build gnu-build-system):

(define* (gnu-build #:key [...] #:rest args)
  [...])

It calls the phases with this:

(apply proc args)

where proc is the phase (in this case, your lambda) and args is the
rest of keyword arguments that the definition of gnu-build captured.

HTH!

Re: what might be wrong with my nightly function?

[Julien Lepiller]

Haven't tested and you didn't share what was the issue. The obvious thing I see 
is #:olive-hash is (base32 "…") by default, so the origin uses (sha256 (base32 
(base32 "…"))) by default

Le 16 novembre 2022 02:37:10 GMT+01:00, jgart  a écrit :
>hi, what might be wrong with this function?
>
>;; let's tracking nightlies!
>(define* (make-olive-nightly
>   #:key (olive-commit "3302c3633c665fd32152217f254b53654945f2dd")
> (olive-hash (base32 
> "0pp6dxn53aw6iiy9wnbkkmg8mcqpx8wy6nify8j4hrzvzrmks82c")))
>(package (inherit olive)
>  (version (string-take olive-commit 7))
>  (source (origin
>   (method git-fetch)
>   (uri (git-reference
> (url "https://github.com/olive-editor/olive;)
> (commit olive-commit)))
>   (file-name (git-file-name name version))
>   (sha256
>(base32 olive-hash
>  (build-system cmake-build-system)
>  (arguments
>   `(,@(package-arguments olive)
> #:tests? #f
>
>(define-public olive-3302c36
>  (make-olive-nightly
>#:olive-commit "3302c3633c665fd32152217f254b53654945f2dd"
>#:olive-hash "0pp6dxn53aw6iiy9wnbkkmg8mcqpx8wy6nify8j4hrzvzrmks82c"))
>
>;; olive package
>
>
>(define-public olive
>  (let ((revision "2")
>   (commit "efa74c72a80522fdd85a56e7dee13e341b73de99"))
>(package
>  (name "olive")
>  (version (git-version "0.2.0" revision commit))
>  (source (origin
>   (method git-fetch)
>   (uri (git-reference
> (url "https://github.com/olive-editor/olive;)
> (commit commit)))
>   (file-name (git-file-name name version))
>   (sha256
>(base32
> "00zv1h9acf3z76ivy04272r4f6rv0yip4bx1vs5znajffnyaj0jm"
>  (build-system cmake-build-system)
>  (arguments
>   `(#:configure-flags '("-DCMAKE_CXX_FLAGS=-Wno-error=shadow")))
>  (inputs
>(list qtbase-5
> qtmultimedia
> qttools
> qtsvg
> ffmpeg
> opencolorio-2
> openimageio
>  portaudio
>  zlib
>  imath
> openexr-3
>  ilmbase))
>  (native-inputs
>(list pkg-config))
>  (home-page "https://olivevideoeditor.org;)
>  (synopsis "Free non-linear video editor")
>  (description
>"@code{olive} is a free and open source non-linear video editor.")
>  (license license:gpl3+
>
>
>

Re: guix search across core-updates?

[Julien Lepiller]

Hi jgart,

I think you could try with the time machine:

guix time-machine --branch=core-updates -- search …

Le 15 novembre 2022 06:45:35 GMT+01:00, jgart  a écrit :
>hi,
>
>how can I search for packages across the core-updates branch with `guix
>search` and without ./pre-inst-env?
>

Re: All 75 channel news entries are valid

[Julien Lepiller]

Hi jgart, are you trying to use -L in the guix repository? Use pre-inst-env 
instead.

Le 14 novembre 2022 23:44:02 GMT+01:00, jgart  a écrit :
>Hi,
>
>has anyone ever gotten this backtrace before? I was trying to update
>`emacs-crdt`:
>
> guix-shell  guix build -L . emacs-crdt
>guix build: warning: failed to load '(build-aux build-self)':
>no code for module (build-aux build-self)
>./build-aux/build-self.scm:19:0: warning: module name (build-self) does not 
>match file name 'build-aux/build-self.scm'
>hint: File `./build-aux/build-self.scm' should probably start with:
>
> (define-module (build-aux build-self))
>
>guix build: All 75 channel news entries are valid.
>guix build: warning: failed to load '(build-aux check-channel-news)':
>no code for module (build-aux check-channel-news)
>hint: File `./build-aux/check-channel-news.scm' should probably start with:
>
> (define-module (build-aux check-channel-news))
>
>checking final inputs for 'x86_64-linux'...
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>checking final inputs for 'aarch64-linux'...
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>checking final inputs for 'powerpc64le-linux'...
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>checking final inputs for 'i686-linux'...
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>checking final inputs for 'armhf-linux'...
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>checking final inputs for 'i586-gnu'...
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix/packages.scm:1616:38: warning: resolving './gnu/packages/ld-wrapper.in' 
>relative to current directory
>guix build: warning: failed to load '(build-aux 
>check-final-inputs-self-contained)':
>no code for module (build-aux check-final-inputs-self-contained)
>hint: File `./build-aux/check-final-inputs-self-contained.scm' should probably 
>start with:
>
> (define-module (build-aux check-final-inputs-self-contained))
>
>guix build: warning: failed to load '(build-aux compile-all)':
>Backtrace:
>In guix/store.scm:
>   1300:8 19 (call-with-build-handler # …)
>In guix/scripts/build.scm:
>587:2 18 (_)
>In srfi/srfi-1.scm:
>   673:15 17 (append-map _ _ . _)
>   586:17 16 (map1 ((argument . "emacs-crdt") (build-mode . 0) # # …))
>In guix/scripts/build.scm:
>   607:31 15 (_ _)
>In gnu/packages.scm:
>479:2 14 (%find-package "emacs-crdt" "emacs-crdt" #f)
>364:6 13 (find-best-packages-by-name _ _)
>   294:56 12 (_ "emacs-crdt" _)
>In unknown file:
>  11 (force #)
>In gnu/packages.scm:
>   241:33 10 (fold-packages # …)
>In guix/discovery.scm:
>   159:11  9 (all-modules _ #:warn _)
>In srfi/srfi-1.scm:
>   460:18  8 (fold # …)
>In guix/discovery.scm:
>   146:31  7 (_ _ ())
>116:5  6 (scheme-modules _ _ #:warn _)
>In srfi/srfi-1.scm:
>   691:23  5 (filter-map # . #)
>In guix/discovery.scm:
>   124:24  4 (_ . _)
>In guix/ui.scm:
>440:5  3 (warn-about-load-error "./build-aux/compile-all.scm" (…) …)
>In unknown file:
>   2 (display-error #f # "match" "…" …)
>In ice-9/boot-9.scm:
>  1685:16  1 (raise-exception _ #:continuable? _)
>  1685:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>Wrong number of arguments to #
>
>

Re: Regex Rules

[Julien Lepiller]

\\ is for inputing a single \ (it needs to be etcaped in guile strings). Then, 
the rest is a Guile regexp, wgicg you can liarn about at 
https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html.

The manual says it's POSIX regexp, whatever that means :)

Le 10 novembre 2022 03:04:12 GMT+01:00, jgart  a écrit :
>Hi,
>
>Where can I find all the regex rules for this style of regex?
>
>"\\$\\{PG_SHAREDIR\\}/extension"
>
>That's a snippet I took at random from guix/
>
>all best,
>
>jgart
>
>

Re: committer.scm

[Julien Lepiller]

Try calling it with pre-inst-env.

Le 1 novembre 2022 02:42:55 GMT+01:00, jgart  a écrit :
>Hi,
>
>Does anyone know how to use the committer.scm script or how it is intended to 
>be used?
>
>This is what my unstaged area looks like:
>
>$ guix-shell  git status
>On branch master
>Your branch is ahead of 'origin/master' by 4 commits.
>  (use "git push" to publish your local commits)
>
>Changes not staged for commit:
>  (use "git add ..." to update what will be committed)
>  (use "git restore ..." to discard changes in working directory)
>modified:   gnu/packages/crates-io.scm
>modified:   gnu/packages/rust-apps.scm
>
>no changes added to commit (use "git add" and/or "git commit -a")
>
>This is what it looks like when I call the script in a guix shell:
>
>$ ./etc/committer.scm
>committer.scm committer.scm.in
> guix-shell  etc/committer.scm the-way
>Backtrace:
>In ice-9/eval.scm:
>   721:20 19 (primitive-eval (use-modules ((sxml xpath) #:prefix …) …))
>In ice-9/psyntax.scm:
>  1218:36 18 (expand-top-sequence (#) …)
>  1210:19 17 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
>   259:10 16 (parse _ (("placeholder" placeholder)) (()) _ c (eval) …)
>In ice-9/boot-9.scm:
>  3935:20 15 (process-use-modules _)
>   222:29 14 (map1 (((sxml xpath) #:prefix xpath:) ((srfi srfi-1)) …))
>   222:29 13 (map1 (((srfi srfi-1)) ((srfi srfi-2)) ((srfi #)) (#) …))
>   222:29 12 (map1 (((srfi srfi-2)) ((srfi srfi-9)) ((srfi #)) (#) …))
>   222:29 11 (map1 (((srfi srfi-9)) ((srfi srfi-11)) ((srfi #)) (#) …))
>   222:29 10 (map1 (((srfi srfi-11)) ((srfi srfi-26)) ((ice-9 #)) # …))
>   222:29  9 (map1 (((srfi srfi-26)) ((ice-9 format)) ((ice-9 #)) # …))
>   222:29  8 (map1 (((ice-9 format)) ((ice-9 popen)) ((ice-9 #)) # …))
>   222:29  7 (map1 (((ice-9 popen)) ((ice-9 match)) ((ice-9 #)) (#) …))
>   222:29  6 (map1 (((ice-9 match)) ((ice-9 rdelim)) ((ice-9 #)) # #))
>   222:29  5 (map1 (((ice-9 rdelim)) ((ice-9 regex)) ((ice-9 #)) (#)))
>   222:29  4 (map1 (((ice-9 regex)) ((ice-9 textual-ports)) ((# #
>   222:29  3 (map1 (((ice-9 textual-ports)) ((guix gexp
>   222:17  2 (map1 (((guix gexp
>  3936:31  1 (_ ((guix gexp)))
>   3330:6  0 (resolve-interface (guix gexp) #:select _ #:hide _ # _ # …)
>
>ice-9/boot-9.scm:3330:6: In procedure resolve-interface:
>no code for module (guix gexp)
>
>

Re: Installation failed : "cannot build derivation" error and "Guix system: error: build of [..]"

[Julien Lepiller]

I don't see an error messahe below, am I missang something? Are you using 
latest or release? Release is quite old now, and bugs have been fixed in latest.

Le 13 octobre 2022 00:46:35 GMT+02:00, "jord...@librebits.info" 
 a écrit :
>Hello Guixers !
>
>My installation process is failing at very last stage of the graphical 
>installer, see the error message shown below :
>
>
>
>What am i missing ?
>
>Thanks, thanks, thanks
>
>Fenix

Re: duplicate package names in channels

[Julien Lepiller]

Build results are kind of content-addressed, so when two separate packages 
yield the same hash, it means they are the same package, and no rebuild is 
necessary.

For the other two questions, it depends from which perspective you're looking 
at. From the code point of view, there are no difference between packages from 
guix and a channel. When two packages yield a different hash, they are 
considered different, so both are built if needed. Also, the code has direct 
reference to a given package, you can't reference "whatever provides gcc", you 
have to reference a specific gcc package, either from a channel or from the 
main guix.

So from the code point of view, two packages may have the same name and even 
version, and this is never ambiguous. Because packages are stored as Guile 
variables and when you specify a variable name it can only reference one value.

From the user point of view, esp. the CLI, you seem to have noticed that guix 
will chose the highest version number when you ask for a package without an 
explicit version number. This does not change whether packages come from a 
channel or from guix.

When two packages have the same name and version, guix will arbitrarily (but 
reproducibly :p) chose one or the other.

HTH!

Le 30 septembre 2022 21:48:31 GMT+02:00, Fulbert  a écrit :
>Hello !
>
>I'm not sure if guix supports similar package names [and version number]
>provided in more than one “active” channels (declared in the list of
>'~/.config/guix/channels.scm, including %default-channels)…
>a) if 2 packages share their name, version and package definition,
>yielding the exact same result, thus sharing the same hash and
>/gnu/store/ storage-space (one “recognizing” the other hash, avoiding
>redondant build or conflict ?) ;
>b) if 2 packages share their name but not the version, thus yielding
>distinct hashes, could guix automatically choose the highest available
>version, similar to what guix does when it provides multiple versions of
>the same name package in the main 'guix channel ? ;
>c) if 2 packages share their name and version but do not yield the same
>result/hash (… that's the only case where I'm abble to see a conflict).
>
>As far as i understand, (c) would be problematic, thus (a) would require
>a pre-build of both and conflict management, which is unlikely(?) and
>consequently, (b) would require a user to remove manually a package in
>the additionnal channel before it leads to (a).
>
>So, my guess work gives NO, NO and NO, but I would be gratefull if
>someone could confirm, eventually with a pointer to the manual or other
>doc. (I am unable to check that for myself in the sources with any
>degree of comprehension, let alone certainty ^^)
>
>Thanks for guix and best regards,
>Fulbert
>

Re: How can I upgrade all the packages in my default profile?

[Julien Lepiller]

"guix upgrade", with no arguments, should do it.

Le 27 septembre 2022 18:07:36 GMT+02:00, jgart  a écrit :
>guix upgrade * or guix upgrade '*' don't work for me :(
>
>
>

Re: guix fails to remove the rust

[Julien Lepiller]

Generally, the actual error is the first one, not the last one:

"build failure may have been caused by lack of free disk space"

I suggest you run "guix gc -F 1M" which should free up just enough space for 
now :)

Le 25 août 2022 02:35:22 GMT+02:00, jgart  a écrit :
>guix remove rust   
>The following package will be removed:
>   rust 1.57.0
>
>The following derivation will be built:
>  /gnu/store/gq8d0nis2n1ni425yglwq70dinngsp9s-profile.drv
>
>guix remove: warning: at least 0.0 MB needed but only 0.0 MB available in 
>/gnu/store
>building CA certificate bundle...
>|note: build failure may have been caused by lack of free disk space
>builder for 
>`/gnu/store/bjn7psnf40n6f5i8id6xaabjqhj7s0dx-ca-certificate-bundle.drv' failed 
>with exit code 1
>build of /gnu/store/bjn7psnf40n6f5i8id6xaabjqhj7s0dx-ca-certificate-bundle.drv 
>failed
>View build log at 
>'/var/log/guix/drvs/bj/n7psnf40n6f5i8id6xaabjqhj7s0dx-ca-certificate-bundle.drv.bz2'.
>cannot build derivation 
>`/gnu/store/gq8d0nis2n1ni425yglwq70dinngsp9s-profile.drv': 1 dependencies 
>couldn't be built
>guix remove: error: build of 
>`/gnu/store/gq8d0nis2n1ni425yglwq70dinngsp9s-profile.drv' failed
>
>
>wdyt
>
>something with ca-certificate?
>

Re: Guix as a native-inputs ?

[Julien Lepiller]

I suppose once you get information about these channels, you could create an 
inferior with these channels, and evaluate your package in it.

Le 2 août 2022 19:10:31 GMT+02:00, Olivier Dion  a 
écrit :
>On Tue, 02 Aug 2022, Julien Lepiller  wrote:
>> If you're trying to access the build daemon from inside the package
>> build container, that must mean you have a derivation you're trying to
>> build. Instead of trying to circumvent the container (which is there
>> for a reason), you could:
>>
>> - write a bit of Scheme code that returns that derivation
>> - pass the result as an input.
>>
>> That way, you build that derivation outside the build environment, and
>> you can refer to the result inside the build environment.
>>
>
>Would that work if my package defines a Guix channel with variant of
>Guix packages in it?  That is, it would be possible to include these
>packages in as a derivation?
>
>-- 
>Olivier Dion
>oldiob.dev

Re: Guix as a native-inputs ?

[Julien Lepiller]

If you're trying to access the build daemon from inside the package build 
container, that must mean you have a derivation you're trying to build. Instead 
of trying to circumvent the container (which is there for a reason), you could:

- write a bit of Scheme code that returns that derivation
- pass the result as an input.

That way, you build that derivation outside the build environment, and you can 
refer to the result inside the build environment.

Le 2 août 2022 17:36:19 GMT+02:00, Olivier Dion via  a écrit 
:
>On Tue, 02 Aug 2022, "("  wrote:
>> On Tue Aug 2, 2022 at 2:41 PM BST, Olivier Dion wrote:
>>> There seems to be an issue after all.  When building with Guix, my
>>> script failed to access /var/guix/daemon-socket/socket with `guix
>>> shell'.  I guess there's probably some way to make it available for the
>>> build?
>> You're in a container with access to nothing but the store and /tmp. It's
>> not surprising that trying to access anything else doesn't work.
>
>Right that was my though.  Do you thin there is a way to expose the
>required files to the build container for accessing the Guix daemon?
>
>I have at least another case -- a guix+guile declarative build system --
>where I need to communicate with the Guix daemon in the build
>container.
>
>-- 
>Olivier Dion
>oldiob.dev
>

Re: how can I use "tor"

[Julien Lepiller]

Two issues:

First, the tor project is asking distros not to build the tor browser 
themselves. That includes Guix. That is because a build with Guix will make it 
distinguishable from the tor-browser built by the tor project.

Second, the tor-browser built by the tor project assumes FHS (/bir, /lib, etc) 
which guix doesn.t provide, so you can't run it directly.

Of course it's not great for anonymity since icecat is way more distinguishable 
than the tor-browser built by guix would be.

You could use different profiles in icecat, one with tor settings, one without. 
You can run icecat -P to select profiles.

Le 24 juillet 2022 12:20:25 GMT+02:00, Gottfried  a écrit :
>Thanks for clearing up.
>
>Would it be not a good idea to set up Tor Browser in Guix, that we would be 
>able to use Tor only for certain webbrowsing and Icecat for the normal usage?
>
>I don't know if somebody has time to do it.
>Gottfried
>
>
>
>Am 24.07.22 um 12:13 schrieb Julien Lepiller:
>> No, there's no tor-browser on guix. Tor is running as a separate daemon and 
>> changing the settings instruct icecat to connect through the tor daemon.
>> 
>> Le 24 juillet 2022 12:04:47 GMT+02:00, Gottfried  a 
>> écrit :
>>> Hi,
>>> thanks a lot. It worked.
>>>> You can't "run tor in icecat" that doesn't make sense. Maybe you meant 
>>>> something else?
>>> 
>>> Exactly, that what I meant. I can't run Tor in Icecat. It doesn't make 
>>> sense.
>>> 
>>> But in changing the settings in Icecat to using Tor, I understand, that it 
>>> is like this. Tor is used in Icecat and there is not a separate Tor 
>>> Browser. Am I right?
>>> 
>>> Gottfried
>>> 
>>> 
>>> 
>>> 
>>> Am 22.07.22 um 17:20 schrieb Julien Lepiller:
>>>> You can't "run tor in icecat" that doesn't make sense. Maybe you meant 
>>>> something else?
>>>> 
>>>> If you don't want icecat to use tor, keep your current settings.
>>>> 
>>>> For using tor in icecat, in your network settings:
>>>> 
>>>> Select "Manuelle Proxy-Konfiguration"
>>>> SOCKS host is localhost, SOCKS port is 9050
>>>> Select SOCKS v5
>>>> Select "Bei Verwendung von SOCKS v5 den Proxy für DNS-Anfragen verwenden"
>>>> 
>>>> Then check with the tor project URL I sent you that you are connecting 
>>>> through tor.
>>> 
>> 

Re: how can I use "tor"

[Julien Lepiller]

No, there's no tor-browser on guix. Tor is running as a separate daemon and 
changing the settings instruct icecat to connect through the tor daemon.

Le 24 juillet 2022 12:04:47 GMT+02:00, Gottfried  a écrit :
>Hi,
>thanks a lot. It worked.
>> You can't "run tor in icecat" that doesn't make sense. Maybe you meant 
>> something else?
>
>Exactly, that what I meant. I can't run Tor in Icecat. It doesn't make sense.
>
>But in changing the settings in Icecat to using Tor, I understand, that it is 
>like this. Tor is used in Icecat and there is not a separate Tor Browser. Am I 
>right?
>
>Gottfried
>
>
>
>
>Am 22.07.22 um 17:20 schrieb Julien Lepiller:
>> You can't "run tor in icecat" that doesn't make sense. Maybe you meant 
>> something else?
>> 
>> If you don't want icecat to use tor, keep your current settings.
>> 
>> For using tor in icecat, in your network settings:
>> 
>> Select "Manuelle Proxy-Konfiguration"
>> SOCKS host is localhost, SOCKS port is 9050
>> Select SOCKS v5
>> Select "Bei Verwendung von SOCKS v5 den Proxy für DNS-Anfragen verwenden"
>> 
>> Then check with the tor project URL I sent you that you are connecting 
>> through tor.
>

Re: how can I use "tor"

[Julien Lepiller]

You can't "run tor in icecat" that doesn't make sense. Maybe you meant 
something else?

If you don't want icecat to use tor, keep your current settings.

For using tor in icecat, in your network settings:

Select "Manuelle Proxy-Konfiguration"
SOCKS host is localhost, SOCKS port is 9050
Select SOCKS v5
Select "Bei Verwendung von SOCKS v5 den Proxy für DNS-Anfragen verwenden"

Then check with the tor project URL I sent you that you are connecting through 
tor.

Le 22 juillet 2022 16:57:40 GMT+02:00, Gottfried  a écrit :
>Thanks,
>
>I have taken a photo of my Icecat connection settings.
>
>In order not to make a mistake, I am asking again, how to fill in this 
>settings? (I still understand too little, that's why I prefer to ask before 
>making mistakes)
>
>As far as I understood you, Icecat will then run via Tor.
>Is it possible to run Tor separately from Icecat, because as I wrote, the Tor 
>Website discourages to use Tor in connection with other browsers.
>
>Gottfried
>
>
>
>Am 21.07.22 um 22:35 schrieb Julien Lepiller:
>> Hi Gottfried,
>> 
>> you don't have to install tor or run it manually. The service is
>> already running tor for you. To use Tor, you need to use a socks proxy
>> to localhost:9050.
>> 
>> You can configure icecat to connect to that proxy (and then check that
>> you're actually connected through tor: https://check.torproject.org/
>> should say "Congratulations").
>> 
>> For other apps, you can use torsocks to proxy traffic through them, eg:
>> 
>>torsocks wget \
>>http://c25o7knygjm3m67jy27yuynvv4pkfi25naucscmh4ubq2ggiig3v57ad.onion/
>> 
>> (that's my home page)
>> 
>> Or, if they support it, you can configure the socks proxy directly in
>> their configuration.
>> 
>> HTH!
>> 
>> Le Thu, 21 Jul 2022 17:49:29 +,
>> Gottfried  a écrit :
>> 
>>> Hi Guixers,
>>> 
>>> I installed "tor, tor-client, torsocks". and
>>> also I have "tor-service-type" in my config.scm.
>>> 
>>> Nevertheless it doesn't appear anywhere.
>>> 
>>> I would like to use the Tor server separately, not in Firefox, as Tor
>>> Website proposed.
>>> 
>>> gfp@Tuxedo ~$ tor
>>> Jul 21 19:30:24.097 [notice] Tor 0.4.7.8 running on Linux with
>>> Libevent 2.1.12-stable, OpenSSL 1.1.1q, Zlib 1.2.11, Liblzma 5.2.5,
>>> Libzstd 1.5.0 and Glibc 2.33 as libc.
>>> Jul 21 19:30:24.097 [notice] Tor can't help you if you use it wrong!
>>> Learn how to be safe at
>>> https://support.torproject.org/faq/staying-anonymous/
>>> Jul 21 19:30:24.098 [notice] Configuration file
>>> "/gnu/store/11azs9lmx363vi1vnz59aim5yp1rv2b9-tor-client-0.4.7.8/etc/tor/torrc"
>>> not present, using reasonable defaults.
>>> Jul 21 19:30:24.106 [notice] Opening Socks listener on 127.0.0.1:9050
>>> Jul 21 19:30:24.106 [warn] Could not bind to 127.0.0.1:9050: Address
>>> already in use. Is Tor already running?
>>> Jul 21 19:30:24.106 [warn] Failed to parse/validate config: Failed to
>>> bind one of the listener ports.
>>> Jul 21 19:30:24.106 [err] Reading config failed--see warnings above.
>>> 
>>> I guess, I have to set up other things as well, but I don't know what
>>> and how.
>>> 
>>> I didn't find enough information in the manual that makes it clear to
>>> me. I found that in the manual:
>>> 
>>> 10.8.4 Networking Services
>>> 
>>> Scheme Variable: tor-service-type
>>> This is the type for a service that runs the Tor anonymous networking
>>> daemon. The service is configured using a  record.
>>> By default, the Tor daemon runs as the tor unprivileged user, which
>>> is a member of the tor group.
>>> 
>>> Data Type: tor-configuration
>>> tor (default: tor)
>>> 
>>> The package that provides the Tor daemon. This package is expected to
>>> provide the daemon at bin/tor relative to its output directory. The
>>> default package is the Tor Project’s implementation.
>>> 
>>> config-file (default: (plain-file "empty" ""))
>>> The configuration file to use. It will be appended to a default
>>> configuration file, and the final configuration file will be passed
>>> to tor via its -f option. This may be any “file-like” object (see
>>> file-like objects). See man tor for details on the configuration file
>>> syntax.
>>> 
>>> hidden-services (default: '())
>>> The list of 

Re: how can I use "tor"

[Julien Lepiller]

Hi Gottfried,

you don't have to install tor or run it manually. The service is
already running tor for you. To use Tor, you need to use a socks proxy
to localhost:9050.

You can configure icecat to connect to that proxy (and then check that
you're actually connected through tor: https://check.torproject.org/
should say "Congratulations").

For other apps, you can use torsocks to proxy traffic through them, eg:

  torsocks wget \
  http://c25o7knygjm3m67jy27yuynvv4pkfi25naucscmh4ubq2ggiig3v57ad.onion/

(that's my home page)

Or, if they support it, you can configure the socks proxy directly in
their configuration.

HTH!

Le Thu, 21 Jul 2022 17:49:29 +,
Gottfried  a écrit :

> Hi Guixers,
> 
> I installed "tor, tor-client, torsocks". and
> also I have "tor-service-type" in my config.scm.
> 
> Nevertheless it doesn't appear anywhere.
> 
> I would like to use the Tor server separately, not in Firefox, as Tor 
> Website proposed.
> 
> gfp@Tuxedo ~$ tor
> Jul 21 19:30:24.097 [notice] Tor 0.4.7.8 running on Linux with
> Libevent 2.1.12-stable, OpenSSL 1.1.1q, Zlib 1.2.11, Liblzma 5.2.5,
> Libzstd 1.5.0 and Glibc 2.33 as libc.
> Jul 21 19:30:24.097 [notice] Tor can't help you if you use it wrong! 
> Learn how to be safe at 
> https://support.torproject.org/faq/staying-anonymous/
> Jul 21 19:30:24.098 [notice] Configuration file 
> "/gnu/store/11azs9lmx363vi1vnz59aim5yp1rv2b9-tor-client-0.4.7.8/etc/tor/torrc"
>  
> not present, using reasonable defaults.
> Jul 21 19:30:24.106 [notice] Opening Socks listener on 127.0.0.1:9050
> Jul 21 19:30:24.106 [warn] Could not bind to 127.0.0.1:9050: Address 
> already in use. Is Tor already running?
> Jul 21 19:30:24.106 [warn] Failed to parse/validate config: Failed to 
> bind one of the listener ports.
> Jul 21 19:30:24.106 [err] Reading config failed--see warnings above.
> 
> I guess, I have to set up other things as well, but I don't know what 
> and how.
> 
> I didn't find enough information in the manual that makes it clear to
> me. I found that in the manual:
> 
> 10.8.4 Networking Services
> 
> Scheme Variable: tor-service-type
> This is the type for a service that runs the Tor anonymous networking 
> daemon. The service is configured using a  record.
> By default, the Tor daemon runs as the tor unprivileged user, which
> is a member of the tor group.
> 
> Data Type: tor-configuration
> tor (default: tor)
> 
> The package that provides the Tor daemon. This package is expected to 
> provide the daemon at bin/tor relative to its output directory. The 
> default package is the Tor Project’s implementation.
> 
> config-file (default: (plain-file "empty" ""))
> The configuration file to use. It will be appended to a default 
> configuration file, and the final configuration file will be passed
> to tor via its -f option. This may be any “file-like” object (see
> file-like objects). See man tor for details on the configuration file
> syntax.
> 
> hidden-services (default: '())
> The list of  records to use. For any hidden service
> you include in this list, appropriate configuration to enable the
> hidden service will be automatically added to the default
> configuration file. You may conveniently create 
> records using the tor-hidden-service procedure described below.
> 
> socks-socket-type (default: 'tcp)
> The default socket type that Tor should use for its SOCKS socket.
> This must be either 'tcp or 'unix. If it is 'tcp, then by default Tor
> will listen on TCP port 9050 on the loopback interface (i.e.,
> localhost). If it is 'unix, then Tor will listen on the UNIX domain
> socket /var/run/tor/socks-sock, which will be made writable by
> members of the tor group.
> If you want to customize the SOCKS socket in more detail, leave 
> socks-socket-type at its default value of 'tcp and use config-file to 
> override the default by providing your own SocksPort option.
> 
> control-socket? (default: #f)
> Whether or not to provide a “control socket” by which Tor can be 
> controlled to, for instance, dynamically instantiate tor onion
> services. If #t, Tor will listen for control commands on the UNIX
> domain socket /var/run/tor/control-sock, which will be made writable
> by members of the tor group.
> 
> Scheme Procedure: tor-hidden-service name mapping
> 
> Define a new Tor hidden service called name and implementing mapping. 
> mapping is a list of port/host tuples, such as:
> 
>   '((22 "127.0.0.1:22")
> (80 "127.0.0.1:8080"))
> 
> In this example, port 22 of the hidden service is mapped to local
> port 22, and port 80 is mapped to local port 8080.
> 
> This creates a /var/lib/tor/hidden-services/name directory, where the 
> hostname file contains the .onion host name for the hidden service.
> 
> See the Tor project’s documentation for more information.
> 
> 
> I read several emails in the guix-help archive about Tor from 2019,
> but I don't know how to put that into practice.
> 
> Could somebody help me?
> 
> Gottfried
> 

Re: Finding Dependencies at Run Time

[Julien Lepiller]

My explanation must not have been clear. You can read more on search-paths at 
https://guix.gnu.org/manual/devel/en/html_node/Search-Paths.html#Search-Paths

Basically, it's a declaration on packages that specify which path-like 
environment variables they honor.

When building an environment/profile, guix will look at all the variable 
declarations of packages of that environment and create the corresponding 
variables.

So when building a package, guix creates an environment with all the 
dependencies (inputs) of the package, and the corresponding environment 
variables.

Similarly, when you install say python (that brings in its search-path 
definition) and python-numpy (that provides a python library), guix will know 
to set GUIX_PYTHONPATH properly for using numpy with python. Since numpy 
propagates its dependencies, they are also part of the environment and that's 
how numpy can find them.

Remember the difference between inputs and propagated inputs: they're the same, 
but when you create a profile, inputs are not part of the profile (so they need 
a direct store reference, such as RPATH or a wrapper), whereas propagated 
inputs are part of the profile, so an environment variable allows to find them.

Le 13 juillet 2022 20:51:18 GMT+02:00, Peter Polidoro  a 
écrit :
>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.
>
>> During the build, search-paths and native-search-paths are used to set up 
>> environment variables. If you use --keep-failed and interrupt a
>> build you'l find them in /tmp/guix-build-…/environment-variables.
>
>So search-paths and native-search-paths are set before the build and unset 
>after the build so they are unavailable during run-time? Or are 
>native-search-paths only available at build-time and search-paths available at 
>both build-time and run-time?
>
>Are the search-paths and native-search-paths absolute path values found by 
>automatically searching the directories in all of the inputs or native inputs, 
>looking for files or directories that match a pattern? So they are a way to 
>map relative paths into absolute paths to the dependency packages?
>
>> For others, the required search paths can be embedded in a wrapper, which 
>> defines environment variables before calling the actual program.
>
>So if a package needs run-time environment variables, then a package should 
>use wrap-program to attach them to a command? These are not found 
>automatically by searching the inputs, they must be manually defined using 
>explicit input paths?
>
>> For propagation, dependencies are found in the environment. It's less "pure" 
>> than the other ways, so we try to avoid resorting to that.
>> Unfortunately some programming languages don't really leave us a choice 
>> (like python…).
>
>So python packages are not using an environment variable, such as PYTHONPATH, 
>to find dependencies? How are they placed together into an environment so they 
>can find each other?

Re: Finding Dependencies at Run Time

[Julien Lepiller]

Maybe the general case is C programs rather than wrappers.

During the build, search-paths and native-search-paths are used to set up 
environment variables. If you use --keep-failed and interrupt a build you'l 
find them in /tmp/guix-build-…/environment-variables.

For C programs, LIBRARY_PATH is embedded as RPATH in the resulting binary or 
library.

For others, the required search paths can be embedded in a wrapper, which 
defines environment variables before calling the actual program.

For propagation, dependencies are found in the environment. It's less "pure" 
than the other ways, so we try to avoid resorting to that. Unfortunately some 
programming languages don't really leave us a choice (like python…).

Le 13 juillet 2022 19:47:45 GMT+02:00, Peter Polidoro  a 
écrit :
>
>> The mecanism depends a bit on the build system but for C programs, it's 
>> embeded at build-time in its RPATH. For applications, there are
>> wrappers 
>> (https://guix.gnu.org/manual/devel/en/html_node/Build-Utilities.html#Wrappers).
>
>So in general, packages use environment variables to find the absolute paths 
>of their dependencies in the store?
>
>In a package definition, are those dependency paths always set using 
>wrap-program? Are search-paths, native-search-paths, and setenv also used to 
>set those environment variables or are those used for something else?
>
>> Otherwise, we have to propagate run-time dependencies.
>
>So how else can packages propagate run-time dependencies besides environment 
>variables?

Re: Finding Dependencies at Run Time

[Julien Lepiller]

The information is all in the package. You can see for instance store paths 
that are embedded form a store path with:

guix gc --references /gnu/store/…

The mecanism depends a bit on the build system but for C programs, it's embeded 
at build-time in its RPATH. For applications, there are wrappers 
(https://guix.gnu.org/manual/devel/en/html_node/Build-Utilities.html#Wrappers). 
Otherwise, we have to propagate run-time dependencies.

The daemon is no longer involved once packages are built/substituted.

Le 13 juillet 2022 16:56:27 GMT+02:00, Peter Polidoro  a 
écrit :
>I apologize for a very basic question, but I could not find where this is 
>documented. If a paper or manual page describes this I would be happy to read 
>it.
>
>How, in general, does code in a Guix package find its dependency packages at 
>run time?
>
>Does it potentially work differently for each build system or is the same 
>approach used for all packages?
>
>Are absolute store paths of the dependencies saved at build time in 
>environment variables or symbolic links or something that are accessible to 
>the run time code?
>
>If code in a package looks for dependencies using relative paths, are copies 
>or links to the dependencies saved within the package? Or is that sort of 
>duplication always avoided? Are relative paths converted to absolute store 
>paths somehow?
>
>Is the Guix daemon needed at run time to help packages find each other or is 
>the information needed to resolve all of the dependencies saved into the 
>package at build time?
>
>Thanks!

Re: Package definition hash calculation

[Julien Lepiller]

I don't think it's documented.

I use guix.scm in my projects, so it's supported. I don't understand your issue 
with the hash then, because now it sounds that you're cloning the same commit 
everytime, so how do you get a different hash?

Le 11 juillet 2022 11:19:25 GMT+02:00, Zelphir Kaltstahl 
 a écrit :
>Hello Julien!
>
>I did create the release tag on the latest commit, which was also the master 
>branch. I thought there was some clever trick to get Guix to ignore the 
>`guix.scm` file, when calculating the hash sum, but apparently that is not the 
>case. I still wonder how I made the first version of the package though. I did 
>not know about `git-checkout` as `source` method. Thanks for that!
>
>I am unsure, whether my project must have a `guix.scm` file or not, to be a 
>valid Guix package in the end, when I add it to (update the entry in) 
>`gnu/packages/guile-xyz.scm`. Maybe a `guix.scm` in the project is not even 
>needed.
>
>Anyway, the idea makes sense to track the master using a checkout without a 
>hash sum, so that I don't have the problem of the hash changing any longer. 
>Just not sure it will work for updating the package in guix. I will try it.
>
>There is no information about `git-checkout`: 
>https://guix.gnu.org/manual/en/html_node/origin-Reference.html Is it elsewhere 
>in the docs?
>
>Best regards,
>Zelphir
>
>On 7/9/22 13:44, Julien Lepiller wrote:
>> When you use guix download, or url-fetch, the hash is computed over the 
>> entire file, whether it's a tarball that contains other files or whatever 
>> else doesn't matter. You can't exclude files from inside the tarball. It's 
>> just the checksum of the file.
>> 
>> What you describes sounds like you're downloading a tarball that's generated 
>> from your master instead of a particular commit. So everytime you push a 
>> change to guix.scm, it's a new commit and a different tar.gz (different 
>> checksum). So you're always chasing after the correct checksum, which won't 
>> work.
>> 
>> So you can have a guix.scm in your repo, but it can't refer to a generated 
>> tarball from master. Instead, you could make it refer to master and not have 
>> to provide a hash like so:
>> 
>> (source (git-checkout (url "https://…;)))
>> 
>> No more chasing afcer master :)
>> 
>> On July 9, 2022 1:09:27 PM GMT+02:00, Zelphir Kaltstahl 
>>  wrote:
>> 
>> Hello Guix users!
>> 
>> I feel a bit stupid to ask about this topic again, however, to me it is 
>> not really clear, what I need to do, when calculating the hash of a package, 
>> so that I can write it in the package definition.
>> 
>> I have a project (https://notabug.org/ZelphirKaltstahl/guile-fslib),  
>> which I have packaged before, but that was already a year ago or so, and I 
>> forgot the precise process involving the hashes.
>> 
>> I have the following questions:
>> 
>> (1) When I edit the `guix.scm` file and change the hash in there, make a 
>> tarball release on notabug, and then run `guix download > release>`, I get a new hash. If I edit the guix.scm file again and repeat 
>> the process, I get a new hash … endless loop of getting a new hash and 
>> changing the file accordingly. My guess is, that this is, because `guix 
>> download` does not exclude the `guix.scm` file. I would have to manually 
>> make a `tar.gz` and upload that as a release to notabug and then reference 
>> that. – Is this correct?
>> 
>> (2) I guess I should be using `guix hash --exclude-vcs --serializer=nar 
>> --format=??? .` instead, since my package definition makes use of the 
>> `git-fetch` method of fetching the package. I had totally forgotten about 
>> this, until I searched in old e-mails, reading old replies to previous 
>> questions I asked on this mailing list. I think it could be made clearer in 
>> the docs, which command to use in which case. However, now I am not sure 
>> which `--format=` I should use. I would guess `base32`, because in my 
>> package definition it says `(sha256 (base32 "..."))`. Is this correct? Or is 
>> the default fine?
>> 
>> (3) What is the recommended way to update a package's source code and 
>> then "in one go" calculate the hash, update the `guix.scm` and make a proper 
>> release, which only has the appropriate files in the tarball?
>> 
>> (4) Should a release tarball contain a `guix.scm` package definition? 
>> (My guess is not, since the hash in that file changes and that would change 
>> the tarball. Maybe I am overlooking things/magic though.)
>> 
>>   

Re: Package definition hash calculation

[Julien Lepiller]

When you use guix download, or url-fetch, the hash is computed over the entire 
file, whether it's a tarball that contains other files or whatever else doesn't 
matter. You can't exclude files from inside the tarball. It's just the checksum 
of the file.

What you describes sounds like you're downloading a tarball that's generated 
from your master instead of a particular commit. So everytime you push a change 
to guix.scm, it's a new commit and a different tar.gz (different checksum). So 
you're always chasing after the correct checksum, which won't work.

So you can have a guix.scm in your repo, but it can't refer to a generated 
tarball from master. Instead, you could make it refer to master and not have to 
provide a hash like so:

(source (git-checkout (url "https://…;)))

No more chasing afcer master :)

On July 9, 2022 1:09:27 PM GMT+02:00, Zelphir Kaltstahl 
 wrote:
>Hello Guix users!
>
>I feel a bit stupid to ask about this topic again, however, to me it is not 
>really clear, what I need to do, when calculating the hash of a package, so 
>that I can write it in the package definition.
>
>I have a project (https://notabug.org/ZelphirKaltstahl/guile-fslib), which I 
>have packaged before, but that was already a year ago or so, and I forgot the 
>precise process involving the hashes.
>
>I have the following questions:
>
>(1) When I edit the `guix.scm` file and change the hash in there, make a 
>tarball release on notabug, and then run `guix download `, 
>I get a new hash. If I edit the guix.scm file again and repeat the process, I 
>get a new hash … endless loop of getting a new hash and changing the file 
>accordingly. My guess is, that this is, because `guix download` does not 
>exclude the `guix.scm` file. I would have to manually make a `tar.gz` and 
>upload that as a release to notabug and then reference that. – Is this correct?
>
>(2) I guess I should be using `guix hash --exclude-vcs --serializer=nar 
>--format=??? .` instead, since my package definition makes use of the 
>`git-fetch` method of fetching the package. I had totally forgotten about 
>this, until I searched in old e-mails, reading old replies to previous 
>questions I asked on this mailing list. I think it could be made clearer in 
>the docs, which command to use in which case. However, now I am not sure which 
>`--format=` I should use. I would guess `base32`, because in my package 
>definition it says `(sha256 (base32 "..."))`. Is this correct? Or is the 
>default fine?
>
>(3) What is the recommended way to update a package's source code and then "in 
>one go" calculate the hash, update the `guix.scm` and make a proper release, 
>which only has the appropriate files in the tarball?
>
>(4) Should a release tarball contain a `guix.scm` package definition? (My 
>guess is not, since the hash in that file changes and that would change the 
>tarball. Maybe I am overlooking things/magic though.)
>
>I am feeling like I am stuck in what should be a simple process, because I 
>still have some points that are unclear to me. I try updating my guide to 
>packaging a pure Guile package when I learn new things, so that I can read up 
>next time I want to make a release or a new package, but a few things are 
>still missing or unclear.
>
>Thank you for all your help!
>
>Best regards,
>Zelphir
>
>-- 
>repositories: https://notabug.org/ZelphirKaltstahl
>
>

Re: package exists but not showing

[Julien Lepiller]

Can you show us "which guix"? Alse firefox is not part of guix, but it's in a 
channel. Maybe your channel configuration changed recently?

On July 8, 2022 6:34:57 AM GMT+02:00, Andy Tai  wrote:
>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?
>

Re: Trying to replicate guix packages list on another machine

[Julien Lepiller]

It's possible your packages on machine A are from various guix revisions, if 
you didn't run "guix update" or didn't use a manifest to install them.

Eg you run "guix install glibc" at revision A, pull revision B where glibc was 
updated to 2.34. When you list your packages, it still mentions glibc@2.33 
because you didn't update it. Then you try to replicate it on another machine 
by pulling revision B, but that old glibc is no longer available.

Manifests ensure that all packages are from the same revision, although if you 
pull a new guix without reinstalling the manifest, you'll have the same issue 
because you're confusing the guix version from which the package was installed, 
and the current guix version.

On June 27, 2022 3:49:58 PM GMT+02:00, Emmanuel Medernach 
 wrote:
>Hello,
>
>We are trying to replicate guix packages list on another machine. We are using 
>GUIX on a foreign distro.
>
>Here what we have on machine A:
>
>[Machine A]$ guix describe --format=channels
>(list (channel
>    (name 'guix)
>    (url "https://git.savannah.gnu.org/git/guix.git;)
>    (commit
>  "a0178d34f582b50e9bdbb0403943129ae5b560ff")
>    (introduction
>  (make-channel-introduction
>    "9edb3f66fd807b096b48283debdcddccfea34bad"
>    (openpgp-fingerprint
>  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")
>
>[Machine A]$ guix package --list-installed  | sort | awk '//{ print $1 "@" $2; 
>}'
>cmake@3.19.2
>gcc-toolchain@4.9.4
>glibc@2.33
>gsl@2.6
>icu4c@68.2
>make@4.3
>pcre@8.44
>zlib@1.2.11
>
>But on machine B:
>
>[Machine B]$ cat ~/.config/guix/channels.scm
>(list (channel
>    (name 'guix)
>    (url "https://git.savannah.gnu.org/git/guix.git;)
>    (commit
>  "a0178d34f582b50e9bdbb0403943129ae5b560ff")
>    (introduction
>  (make-channel-introduction
>    "9edb3f66fd807b096b48283debdcddccfea34bad"
>    (openpgp-fingerprint
>  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")
>
>[Machine B]$ guix install cmake@3.19.2 gcc-toolchain@4.9.4 glibc@2.33 gsl@2.6 
>icu4c@68.2 make@4.3 pcre@8.44 zlib@1.2.11
>guix install: error: glibc: package not found for version 2.33
>
>What are we doing wrong ? Please tell us what steps are missing to correctly 
>replicate guix packages to another machine ?
>
>Best regards,
>
>Emmanuel Medernach
>
>
>

Re: Additional channels pulled, but cannot install/update software

[Julien Lepiller]

Hi Simen,

Can you check that your "guix" actually comes from
~/.config/guix/current/bin/guix (and *not* ~/.guix-profile or
~/.guix-home, it's very important)?

`type guix` should tell you what it is. If it doesn't agree with `which
guix` and the location found by which is correct, try `hash guix` (no
output), then from that terminal you should get the new guix that you
pulled (not other terminals, you'd need to reboot for that).

It's usually a mistake to install the guix package with something like
"guix install guix" or "guix upgrade guix", because the guix package
that guix knows is necessarily from the past, so you're instead
downgrading your guix command.

On the guix system, and I think what the binary installer does, the
guix pull profile should come first in $PATH, but maybe something went
wrong in your case, or you made some changes?

Le Sat, 25 Jun 2022 20:49:23 +0200,
Simen Endsjø  a écrit :

> I'm having a problem where `guix pull` pulls all channels defined in
> ~/.config/guix/channels.scm, but somehow only guix is available
> thereafter. Any idea what might have happened? I have software
> installed through these channels which now cannot be updates as they
> don't exist in the main guix channel.
> 
> $ cat ~/.config/guix/channels.scm
> (cons* (channel
> (name 'nonguix)
> (url "https://gitlab.com/nonguix/nonguix;)
> (introduction
> (make-channel-introduction
> "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
> (openpgp-fingerprint
> "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"
> (channel
> (name 'flat)
> (url "https://github.com/flatwhatson/guix-channel.git;)
> (introduction
> (make-channel-introduction
> "33f86a4b48205c0dc19d7c036c85393f0766f806"
> (openpgp-fingerprint
> "736A C00E 1254 378B A982  7AF6 9DBE 8265 81B6 4490"
> %default-channels)
> 
> 
> $ guix describe --format=channels
> (list (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
> "a43c3b1818db4860ec81bf867b1e53b418a0acec")
> (introduction
> (make-channel-introduction
> "9edb3f66fd807b096b48283debdcddccfea34bad"
> (openpgp-fingerprint
> "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A
> 54FA")
> 
> 
> $ guix pull --list-generations
> # ...
> Generation 28Jun 24 2022 21:00:31 (current)
> nonguix 1a122e0
> repository URL: https://gitlab.com/nonguix/nonguix
> branch: master
> commit: 1a122e06fe046caebf39395edc797515861acd3b
> flat 657da22
> repository URL:
> https://github.com/flatwhatson/guix-channel.git branch: master
> commit: 657da22f0229b978b7bf4e4d476f59f17f6a175f
> guix a43c3b1
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: a43c3b1818db4860ec81bf867b1e53b418a0acec
> 

Re: what is the difference among files in /gnu/store

[Julien Lepiller]

Le Thu,  2 Jun 2022 18:24:20 +,
Gottfried  a écrit :

> Hi Julien,
> 
> thanks for your explanation
> 
> >> How did you get this list of store items?  
> 
> I simply used "catfish" to look for "TraditionalGreen" and it gave me 
> those 4 packages.

I see. In general, it's not very useful to figure out what the exact
store path for a file is. I'm not very familiar with Mate, but I
suppose it has some sort of theme chooser? You should use it and select
your favorite theme directly.

> 
> >> The second is the content of a system generation. You probably
> >> installed mate in your system :). The system generation is also
> >> the union of packages that you declared, so it includes mate, and
> >> consequently, the theme.  
> 
> When I installed Guix, it gave me only 3 options of desktops: MATE, 
> Enlightment and Awesome. That's why I installed all three of them.
> 
> I knew only MATE, I didn't know what Enlightment and Awesome was, so
> I installed them to get to know them. There was no Gnome, XFCE, KDE
> ... available. So I was wondering why some Guixers have e.g. Gnome or
> XFCE installed.
> Now checking in the Guix Packages I found Gnome and XFCE available,
> but no KDE. KDE, AFAIK isn't available at the moment. Is that right?

Correct, KDE is a bit difficult to package, and we don't have enough
people interested in making the effort.

> 
> >> If possible, please don't use a store path in your configuration.
> >> If you update the system, the new version will be at a different
> >> location (even if the version number is the same, as you've seen
> >> with mate-themes). It might get garbage-collected and will
> >> definitely get out of date. 
> 
> I didn't do anything. It was installed this way when I installed Guix 
> System.
> In which other location Guix will install the new version?

That's the problem: I don't know, because I can't predict it. A store
path looks like this:

/gnu/store/--/

The  and  parts are easy to understand. The  part
is a string that is derived from the  part of the dependencies of
the package. Every time the package is updated, or one of its
dependencies, or a dependency of a dependency, etc, is updated, the
 part changes.

That's why you have two "mate-themes" packages in your store. They're
both at the same version, but they were built with different packages,
because at least one of their dependencies is different.

After an update, guix will create a new store path for the new item.
Guix never updates anything in place, which guarantees that if
something works one day, it will always work.

> 
> >> Instead, you should reference a theme by its name only. If mate
> >> lets you, try to set the theme to "TraditionalGreen" and that will
> >> always be the latest version.  
> 
> In my home folder there is a hidden folder with the name
> .icons and another one with the name .themes.
> I thought that in one ot those my "themes" will be stored.
> But when I looked for them, catfish found them in /gnu/store.
> Those tho folders are empty.
> So if I would be able to install new themes, I thought to install
> them there, but I don't know if Guix will find them, because as far
> as I know Guix will look in /gnu/store.

Some themes come from guix packages, such as TraditionalGreen, but you
could install custom themes (outside of guix) in your .themes folder.
Mate will look both at this folder and in the store, at a location that
Guix will provide it (which is the location that contains the
up-to-date version).

If you select a store path directly, your config will always point to
that fixed version (remember a store path is immutable, it doesn't
change even with updates). So, you won't get updates. Instead, you
should just use the name of the theme, so Mate will look for a theme by
that name, and find it in the latest store path that Guix configured
for it. After an update, Guix will configure the new path and Mate will
be able to load the new version transparently.

> 
> Gottfried
> "hacking" on the basics
> 
> 
> Am 02.06.22 um 07:12 schrieb Julien Lepiller:
> > Hi Gottfried,
> > 
> > How did you get this list of store items?
> > 
> > The first one comes from "mate". That's a meta-package that
> > contains the union of a bunch of packages that are needed to run
> > mate.
> > 
> > The second is the content of a system generation. You probably
> > installed mate in your system :). The system generation is also the
> > union of packages that you declared, so it includes mate, and
> > consequently, the theme.
> > 
> > The last two are different versions of "mate-themes". I don't know
> >

Re: what is the difference among files in /gnu/store

[Julien Lepiller]

Hi Gottfried,

How did you get this list of store items?

The first one comes from "mate". That's a meta-package that contains the union 
of a bunch of packages that are needed to run mate.

The second is the content of a system generation. You probably installed mate 
in your system :). The system generation is also the union of packages that you 
declared, so it includes mate, and consequently, the theme.

The last two are different versions of "mate-themes". I don't know which is 
more recent.

If possible, please don't use a store path in your configuration. If you update 
the system, the new version will be at a different location (even if the 
version number is the same, as you've seen with mate-themes). It might get 
garbage-collected and will definitely get out of date.

Instead, you should reference a theme by its name only. If mate lets you, try 
to set the theme to "TraditionalGreen" and that will always be the latest 
version.

HTH!

On June 1, 2022 9:03:39 PM GMT+02:00, Gottfried  wrote:
>Hi guixers,
>
>e.g.
>
>I have in my MATE desktop a theme called "TraditionalGreen"
>
>There are several files.
>What is the difference?
>
>/gnu/store/09bi02ldaqsykdfi8szv225z4adl98hj-mate-1.24.1/share/themes/TraditionalGreen
>
>/gnu/store/65dvsqhxly3cs33m935amvg1wc38s1ii-system/profile/share/themes/TraditionalGreen
>
>/gnu/store/aqpb71z7nl1jbaxi7q2364x5hm2lsab9-mate-themes-3.22.21/share/themes/TraditionalGreen
>
>/gnu/store/y3cwrifdqvainwddij7zvk0lspvbpsia-mate-themes-3.22.21/share/themes/TraditionalGreen
>
>
>The 1. and 2. have a different Icon, it has something to do with a link 
>(Verknüpfung german).
>
>Which one is used for the desktop?
>
>I want to learn the basics!
>
>Gottfried

Re: Guix home, guix system, channels, some noob questions

[Julien Lepiller]

guix install something installs for the current user. Note that, if you do that 
as root, the package is also only available to root. The only way to install or 
remove a global package is through guix system and its configuration file.

I don't know how guix home interacts with other solutions.

We don't have a good solution for secrets. We advise to manage the 
"out-of-band" to make sure that you don't share the secret accidentally (eg. 
publishing your configuration with others) and that the secret doesn't end up 
in the store (it's world-readable).

On May 12, 2022 10:40:18 AM GMT+02:00, "Sébastien Rey-Coyrehourcq" 
 wrote:
>Thanks Julien,
>
>Ok i see, like you say jpoiret also say me that the concept are orthogonal, so 
>if i understand well :
>
>- adding emacs as system package, i suppose this is available for all users
>
>- adding emacs as home package, i suppose this is available only for me
>
>And *guix install something* install for which, system or home or both ?
>
>Some other general questions :
>
>- About dotfile management, is it possible to use chezmoi, yadm, stow in // of 
>guix home ?
>
>I'm interested by some example if you have.
>
>- About secrets management, i know this is very complicated in nix (there are 
>one hundred way to do the things, more or less secure), how that works if i 
>want to inject *secrets* into guix home scm file and maintain security when i 
>share or publish my config with/to others ?
>
>Thanks,
>
>Best regards
>
>
>Le 11/05/2022 à 17:48, Julien Lepiller a écrit :
>> Guix home and guix system are pretty similar as they are used to 
>> declaratively manage configuration. But, they are not mutually exclusive. 
>> Guix system is the only way to install and update the Guix System (hence the 
>> name ;)).
>> 
>> Guix home manages your user's configuration (in /home) while guix system 
>> manages the system's configuration (traditionally in /etc, though less true 
>> for guix). The two are acting in a very similar on two different things.
>> 
>> Also, you can use guix home on a foreign distro, or choose to not use guix 
>> home on the Guix System.
>> 
>> HTH!
>> 
>> On May 11, 2022 4:55:23 PM GMT+02:00, "Sébastien Rey-Coyrehourcq" 
>>  wrote:
>> 
>> Hi,
>> 
>> My other question remain about guix home / guix system relation, and 
>> sudo, but jpoiret found my main problem, my channels.scm are not well 
>> defined / not good ...
>> 
>> - I made (cons * (channel ...)) (cons* (channel ...)) etc.
>> 
>> - and .. the correct way is (cons * (channel ...) (channel ...))
>> 
>> Everything run fine now with *guix system reconfigure 
>> /.config/guix/system.scm*
>> 
>> Best
>> 
>> Le 11/05/2022 à 16:36, Sébastien Rey-Coyrehourcq a écrit :
>> 
>> Hi, Thanks Julien, I see on the doc that *sudo* run command as
>> user and not as root like other distro. So, to be sure, if i
>> run *sudo guix something*, i don't change user to run this
>> command isn't it ? Actually i only work with my account
>> "myuser" into group ("users","wheel",etc.) using or not using
>> *sudo* (this is not clear when i need or not) for running
>> *guix* command. About the commands with
>> /.config/guix/channels.scm (see content here
>> https://paste.debian.net/1240553)  : a) *guix describe* and
>> *sudo guix describe* and *sudo -E guix describe* return
>> Génération 7    11 mai 2022 16:01:25    (actuelle)   guix
>> d24ad39     URL du dépôt :
>> https://git.savannah.gnu.org/git/guix.git     branche : master
>>     commit : d24ad3949127a938cad306f0524c120afe5e2e4f b) *guix
>> system describe* return Génération 7    10 mai 2022
>> 12:39:34    (actuelle)   nom de fichier :
>> /var/guix/profiles/system-7-link   nom de fichier canonique :
>> /gnu/store/az1ff4ll80dbrbkayc4y0jqgnc2m37mp-system   étiquette
>> : GNU with Linux 5.17.5   chargeur de démarrage : grub-efi  
>> périphérique racine : /dev/mapper/cryptroot   noyau :
>> /gnu/store/0ffifgs0ixgz0bf1pcahkfdkx9f7h720-linux-5.17.5/bzImage
>>   canaux :     nonguix:   URL du dépôt :
>> https://gitlab.com/nonguix/nonguix   branche : master
>>   commit : 1de0c32142c54bc73af5556d5e45c77152b31f0f    
>> guix:   URL du dépôt :
>> https://git.savannah.gnu.org/git/guix.git   branche :
>> master   commi

Re: Guix home, guix system, channels, some noob questions

[Julien Lepiller]

Guix home and guix system are pretty similar as they are used to declaratively 
manage configuration. But, they are not mutually exclusive. Guix system is the 
only way to install and update the Guix System (hence the name ;)).

Guix home manages your user's configuration (in /home) while guix system 
manages the system's configuration (traditionally in /etc, though less true for 
guix). The two are acting in a very similar on two different things.

Also, you can use guix home on a foreign distro, or choose to not use guix home 
on the Guix System.

HTH!

On May 11, 2022 4:55:23 PM GMT+02:00, "Sébastien Rey-Coyrehourcq" 
 wrote:
>Hi,
>
>My other question remain about guix home / guix system relation, and sudo, but 
>jpoiret found my main problem, my channels.scm are not well defined / not good 
>...
>
>- I made (cons * (channel ...)) (cons* (channel ...)) etc.
>
>- and .. the correct way is (cons * (channel ...) (channel ...))
>
>Everything run fine now with *guix system reconfigure /.config/guix/system.scm*
>
>Best
>
>Le 11/05/2022 à 16:36, Sébastien Rey-Coyrehourcq a écrit :
>> Hi,
>> 
>> Thanks Julien,
>> 
>> I see on the doc that *sudo* run command as user and not as root like other 
>> distro. So, to be sure, if i run *sudo guix something*, i don't change user 
>> to run this command isn't it ?
>> 
>> Actually i only work with my account "myuser" into group 
>> ("users","wheel",etc.) using or not using *sudo* (this is not clear when i 
>> need or not) for running *guix* command.
>> 
>> About the commands with /.config/guix/channels.scm (see content here 
>> https://paste.debian.net/1240553)  :
>> 
>> a) *guix describe* and *sudo guix describe* and *sudo -E guix describe* 
>> return
>> 
>> Génération 7    11 mai 2022 16:01:25    (actuelle)
>>   guix d24ad39
>>     URL du dépôt : https://git.savannah.gnu.org/git/guix.git
>>     branche : master
>>     commit : d24ad3949127a938cad306f0524c120afe5e2e4f
>> 
>> b) *guix system describe* return
>> 
>> 
>> Génération 7    10 mai 2022 12:39:34    (actuelle)
>>   nom de fichier : /var/guix/profiles/system-7-link
>>   nom de fichier canonique : 
>> /gnu/store/az1ff4ll80dbrbkayc4y0jqgnc2m37mp-system
>>   étiquette : GNU with Linux 5.17.5
>>   chargeur de démarrage : grub-efi
>>   périphérique racine : /dev/mapper/cryptroot
>>   noyau : /gnu/store/0ffifgs0ixgz0bf1pcahkfdkx9f7h720-linux-5.17.5/bzImage
>>   canaux :
>>     nonguix:
>>   URL du dépôt : https://gitlab.com/nonguix/nonguix
>>   branche : master
>>   commit : 1de0c32142c54bc73af5556d5e45c77152b31f0f
>>     guix:
>>   URL du dépôt : https://git.savannah.gnu.org/git/guix.git
>>   branche : master
>>   commit : d775a24344d4a910f6a19072c595bdafcf104b6f
>>   fichier de configuration : 
>> /gnu/store/idr8ds86m69gbx217g5h3qm6m353wliz-configuration.scm
>> 
>> c) *guix home describe* return
>> 
>> 
>> Génération 1    10 mai 2022 16:59:14    (actuelle)
>>   nom de fichier : /var/guix/profiles/per-user/reyman/guix-home-1-link
>>   nom de fichier canonique : /gnu/store/3q599hyjkx8c5ywsdy2gqfmx2bjzgzmm-home
>>   canaux :
>>     flat:
>>   URL du dépôt : https://github.com/flatwhatson/guix-channel.git
>>   branche : master
>>   commit : 094746c1e2e90f2df1e598ab1fd0abb4d75ce84d
>>     guix:
>>   URL du dépôt : https://git.savannah.gnu.org/git/guix.git
>>   branche : master
>>       commit : 0f705472126f7b935e0783bcd8fec831b7a0593b
>>   fichier de configuration : 
>> /gnu/store/ip90ffd0bzlr7j6kw5ky2pgxpyq1x23c-configuration.scm
>> 
>> With jpoiret, i try to resolve the issue on chat, i also try to run manually 
>> *guix pull -C ./config/guix/channels.scm* without success.
>> 
>> A *command -v guix* return */home/myuser/.config/current/bin/guix*
>> 
>> Best regards,
>> 
>> SR
>> 
>> 
>> 
>> Le 11/05/2022 à 12:47, Julien Lepiller a écrit :
>>> Hi Sébastien,
>>> 
>>> When you run guix describe, it's running the guix for your user, which 
>>> miggt be different from the one you run when you use sudo. That could 
>>> explain why the modules are not found. I don't think guix home has anything 
>>> to do with that.
>>> 
>>> I noticed that the first time you use sudo -E, whereas you use only sudo on 
>>> step 5. Mayée that's why it fails?
>>> 
>>> I would run sudo guix describe and sudo -E guix describe to see how the two 
>>> might be diff

Re: Guix home, guix system, channels, some noob questions

[Julien Lepiller]

Hi Sébastien,

When you run guix describe, it's running the guix for your user, which miggt be 
different from the one you run when you use sudo. That could explain why the 
modules are not found. I don't think guix home has anything to do with that.

I noticed that the first time you use sudo -E, whereas you use only sudo on 
step 5. Mayée that's why it fails?

I would run sudo guix describe and sudo -E guix describe to see how the two 
might be different from your user's guix :)

HTH!

On May 11, 2022 11:09:19 AM GMT+02:00, "Sébastien Rey-Coyrehourcq" 
 wrote:
>Hi Guix people :)
>
>I'm starting guix, picking information when needed into documentation.
>
>I'm facing difficulties with channels.scm since i start using "guix home", i 
>read the doc page, but i need some other things to understand.
>
>Here my logic to start just after install :
>
>1 - I modify my //etc/guix/channels.scm/ file to add some modules : /nonguix/ 
>(my computer don't work well without) and /emacs-native-dep/ from flatwhatson 
>flat channel.
>
>2 - I /guix -E guix system reconfigure /etc/config.scm/, /guix pull/, and 
>everything goes well
>
>3 - Like explained in the doc, I run /guix home import ~/src/guix-config /that 
>generate /a //home-configuration.scm//
>/
>
>/4 - /Into /home-configuration.scm///i add the package htop and 
>/emacs-native-comp/
>
>5 - In the guix home doc the next command is /guix home reconfigure config.scm 
>/but this is probably a typo and i run /guix home reconfigure 
>~/src/guix-config/home-configuration.scm/
>
>6 - Everything goes well, emacs-native-dep compile during 1 hour, problems 
>arrive after that.
>
>7 - I'm moving the //etc/guix/config.scm/ and //etc/guix/channels.scm /to my 
>home /~/.config/guix/ , /and i run /sudo guix system reconfigure 
>~/.config/guix/system.scm///*, that fail*/, /it seems the module (nongnu and 
>emacs-native-dep) are not referenced, like the error say /"no code for module 
>( nongnu ..." /But when i run /guix system describe/, the corresponding 
>channel are well defined. /
>/
>
>After that, i try many thing, like moving channels.scm and system.scm back to 
>/etc/guix/ but every reconfigure command fail in link with channel/module not 
>recognized (emacs-native-dep or nongnu)
>
>- /guix home reconfigure ~/src/guix-config/home-configuration.scm/
>
>- /guix system reconfigure ~/.config/guix/system.scm/
>
>- /guix system reconfigure ~/etc/guix/config.scm/
>
>So my question is first, why that fail after switching to guix home ? and how 
>and where i need to define/set correctly the /channel.scm/ file to repair that 
>?
>
>For example, /guix system//describe/ and /guix home describe/ and /guix 
>describe/ return all different channel referenced, how i manage that ?
>
>I suppose there is a "workflow to use well guix home"? but this is not 
>actually in the doc. For example, perhaps after creating and switching to guix 
>home profile, running guix system is impossible or prohibited ? I suppose this 
>will be added in the future.
>
>Thanks a lot for your help.
>
>---
>
>Sebastien Rey-C
>
>
>//
>

Re: Help installing on Cubox-i/Arm Boards

[Julien Lepiller]

Hi Ryan!

Installing on armhf/aarch64 SBCs is not easy. I'm not sure the graphical 
installer is available for these platforms.

The tarball you found is for installing Guix, the package manager, on top of 
another distro. It's not the distro itself.

This blog post might help figuring out what you need for generating an 
installer image for your board: 
https://guix.gnu.org/en/blog/2019/guix-on-an-arm-board/

For generating the correct image from x86, you'll need to cross-compile the 
installer with --target=arm-linux-gnueabihf (for armhf).

Good luck!

On May 4, 2022 6:56:26 AM GMT+02:00, ryan  wrote:
>Hi all
>
>First of all I am completely new to quix (I use parabola Gnu/linux-
>libre), so my apologies if I ask some questions that might seem very
>obvious.
>
>I would like to build a disk image for a Cubox-i variant that I have,
>it currently has nothing on it. If setup guix on my x86_64
>device/laptop using the guided installer, can I build it from there
>easily using the instructions here?:
>https://guix.gnu.org/manual/en/html_node/Building-the-Installation-Image.html
>I also see there is a binary tarball, but not sure what to do with it?
>
>or am I jumping ahead? I see that uboot in guix is available for the
>cubox-i, but I am not sure where I need to start?
>
>Any help with getting guix setup on the armvh device would be most
>useful and appreciated.
>
>Many Thanks
>Ryan
>

Re: to run a package that isn't shown in the application menu

[Julien Lepiller]

In general, you can run the app from the command-line. Don't point directly to 
the store, because the path might change after an update.

However this is only a workaround. The proper solution is to fix the packaging. 
Which packages are lacking a launcher icon?

On March 9, 2022 7:17:10 PM GMT+01:00, Gottfried  wrote:
>Hi,
>
>I installed some packages, but they don't appear in the application menu 
>(no icon).
>
>Is there an other way (manual way) to run them?
>
>I tried to use a starter and point to a file in 
>/gun/store/application/bin/application
>but it says "file could not be found".
>
>Gottfried
>

Re: Guix website and CI is unavailable in Russia

[Julien Lepiller]

Hi!

I'm sorry to hear that you can't access the ci. At least, I don't think it's an 
intentional block from the Guix project. The website and ci are located at the 
MDC, in Berlin. We also have a second official build farm in Bordeaux, France. 
If you don't have it already configured, try it: https://bordeaux.guix.gnu.org.

Now if Russia decides to create its own great firewall, we might have a 
solution. There's already a mirror for Chinese users, so we could set one up 
for Russians if need be.

On March 1, 2022 12:21:46 AM GMT+01:00, w...@riseup.net wrote:
>Hello. Looks like Guix website (guix.gnu.org) and guix ci in cli (can't
>pull and install packages from ci.guix.gnu.org) doesn't work without a
>tor for some users from Russia including me. Gnu.org works fine without
>a tor.
>
>The website is not blocked by Russian government (at least looks like
>so):
>
>https://www.isitblockedinrussia.com/?host=guix.gnu.org
>
>As far as I know they block it by domain address, but I might be wrong.
>
>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. Everything works fine through tor for me and some
>ru users. It would be sad to stop using guix system because of war
>issues.
>
>Also it is kinda related to GNU's freedom #1, because not everyone can
>access the code and the compiled software via internet connection: "The
>freedom to study how the program works, and change it so it does your
>computing as you wish (freedom 1). Access to the source code is a
>precondition for this."
>
>On a related note, do you think it might be a good idea to make offline
>guix distribution? Looks like Russia has a danger of internet shutdowns
>or china-like internet limitations. It can be organized like
>/gnu/sources/ folder with source code of many packages and when package
>name is present them, guix would choose to build from source without
>trying to connect to the servers or something like it. Just an idea.
>
>Thanks in advance.
>
>
>

Re: text editor

[Julien Lepiller]

Hi Gottfried,

If you don't feel ready for emacs, I would suggest you try Gedit. It's
a graphical text editor with basic functionalities like syntax
highlighting. It won't do as much as emacs or vim, but it should be
very easy to use :)

Le Tue, 22 Feb 2022 18:14:32 +,
Gottfried  a écrit :

> Hi, thanks for Your email.
> I am not sitting the whole day in front of a computer, I am working
> in a technical job to help people.
> 
> So I didn´t have time to learn any computer language, emacs etc.
> because I didn´t need it for my life yet.
> 
> Which editor You would propose , I should use, to show which brackets 
> belong to each other, as you described in your email?
> 
> I guess emacs is too difficult for me to learn, because it would make 
> sense only, if I used it regularly.
> So it would be good a more simple editor.
> 
> gottfried
> 
> 
> 
> Date: Mon, 21 Feb 2022 20:34:05 + ()
> From: Jay Sulzberger 
> To: help-guix@gnu.org
> Subject: Re: scanner
> Message-ID: 
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> Dear Gottfried , I use an editor which allows me
> to check whether a bit of text is a well formed sexp, that is, a well
> formed Lisp expression.  I do not have Guile on the machine I am
> writing this on, but I am writing using Emacs.
> 
> Here is a syntactically, well, at the level of sexps, well formed
> version of your Guix expression:
> 
> (services
>(append
> (list (service mate-desktop-service-type)
>   (service enlightenment-desktop-service-type)
>   (service cups-service-type
>(cups-configuration
> (web-interface? #t)
> (extensions (list cups-filters
>   hplip
>   (service openssh-service-type)
>   (service tor-service-type)
>   (set-xorg-configuration
>(xorg-configuration
> (keyboard-layout keyboard-layout
> (modify-services %desktop-services
>  (sane-service-type _ => sane-backends
> 
> I got this by typing the following into an emacs buffer:
> 
> (services
>(append
>  (list (service mate-desktop-service-type)
>(service enlightenment-desktop-service-type)
>(service cups-service-type
>(cups-configuration
>(web-interface? #t)
> (extensions (list cups-filters
>hplip
>(service openssh-service-type)
>(service tor-service-type)
>(set-xorg-configuration
> (xorg-configuration
> (keyboard-layout keyboard-layout
> (modify-services %desktop-services
>  (sane-service-type _ => sane-backends))
> 
> which is, I think, the thing you sent to the help-guix list.
> 
> I then added a single parenthesis onto your expression and Emacs
> showed me that the new right parenthesis matched the left parenthesis
> on the second line of your expression.  That is, the left parenthesis
> in
> 
>(append
> 
> I then added one more right parenthesis, which Emacs showed me matched
> the first left parenthesis of your whole expression.  That is, the
> left parenthesis in
> 
> (services
> 
> Assuming Emacs is correct in matching parentheses, the result, as
> shown at top, is a Lisply correct sexp.  But it may, or may not, be a
> Guixly syntactically correct expression, because the Guix system may
> have more constraints on what it accepts as a command, beyond the
> constraint of being a proper sexp.
> 
> I remain, as ever, your fellow student of history and probability,
> Jay Sulzberger
> 
> 
> PS. I got the Lisp-traditional (well, a Lisp traditional) indentation
> of the (text representation of) the first expression by asking Emacs
> to perform:
> 
> indent-sexp
> 
> on an un-indented version.
> 
> PPS. Reading more carefully your post to help-guix, I now understand
> that you already completely grasp the main meat of my note.  But as a
> member in mostly good standing of the Emacs Tendency of the Front for
> Free Software, I send this note.
> 

Re: guile

[Julien Lepiller]

Le Tue, 22 Feb 2022 18:07:13 +,
Gottfried  a écrit :

> Hi,
> in order to learn to configure the config.scm file
> I would like to learn how it works.
> 
> Which website or article could help me to get an overview and learn 
> something about guile, because guix is build on guile, I understood.
> 
> gottfried
> 

The Guix Cookbook has a quick introduction to the basics of Guile, you
should check it out:

https://guix.gnu.org/cookbook/en/html_node/A-Scheme-Crash-Course.html

Re: Trouble configuring guix

[Julien Lepiller]

Hi Yasuaki,

That's great to hear about why you came to guix, but please don't advertise for 
non-free software on guix mailing lists :)

On February 20, 2022 3:03:07 AM GMT+01:00, Yasuaki Kudo  
wrote:
>Hi!,
>
>I just wanted to let you know I came to Guix for the exact same reason - 
>Nix was way too cryptic for me 
>
>I don't have any answer (sorry I am not familiar with what you 
>mentioned) but here's my configuration (I use Wayland and "Corrupt" 
>(meaning non-deblobbed, I guess) Linux)
>
>https://github.com/yugawara/workers-cafe/tree/main/workers-memo/guix
>
>-Yasu
>
>On 2/20/22 09:33, Cássio Tavares wrote:
>> Hello there!
>>
>> Well, I need help...
>>
>> ## Context:
>>
>>* I have just a little familiarity with Guile Scheme, because I'm a
>>  LilyPond user;
>>* I finally have a desktop that doesn't need non-libre drivers;
>>* Although I'm not in the Tech world, I love GNU's (and the FSF's)
>>  philosophy;
>>* I have been playing with Nix, but find it very cryptic -- not easy
>>  to understand at all.
>>
>>So, Guix seems to be the path I'm on now.
>>
>> ## Situation:
>>
>>I have several problems to fix, but the most important right now is
>>to get my keyboard to work with sddm, and I need sddm for
>>Wayland. So, without sddm, this works:
>>
>> ```
>>  ...
>>
>>  (define %this-keyboard  (keyboard-layout "br" "abnt2"))
>>
>>  ...
>>
>>  (operating-system
>>...
>>
>>(keyboard-layout  %this-keyboard)
>>
>>... )
>>
>> ```
>>
>>But `guix system reconfigure /etc/config.scm` fails when this is this:
>>
>> ```
>>  (use-modules
>>(gnu)
>>(gnu system nss)
>>(gnu services networking)
>>(gnu services sddm)
>>(gnu services cups)
>>(gnu services desktop)
>>(gnu services ssh)
>>(gnu services xorg))
>>
>>  ...
>>
>>  (define %this-keyboard (keyboard-layout  "br" "abnt2"))
>>
>>  ...
>>
>>  (operating-system
>>...
>>
>>(keyboard-layout  %this-keyboard)
>>
>>...
>>
>>(services
>>  (append
>>(list
>>  (service dhcp-client-service-type)
>>  (service ntp-service-type)
>>  (service gpm-service-type)
>>  (service cups-service-type)
>>  (service elogind-service-type)
>>  (service sddm-service-type
>>(sddm-configuration
>>  (display-server "wayland")
>>  (numlock "on")
>>  (theme "guix-simplyblack-sddm-theme")
>>  (xorg-configuration
>>(keyboard-layout %this-keyboard)
>>%base-services))
>>
>>... )
>>
>> ```
>>
>>Then, when I try to run `guix system reconfigure /etc/config.scm`, I
>>get this backtrace:
>>
>>> root@udu ~#
>>> Backtrace:
>>>   19 (primitive-load "/root/.config/guix/current/bin/guix")
>>> In guix/ui.scm:
>>>2229:7 18 (run-guix . _)
>>>   2192:10 17 (run-guix-command _ . _)
>>> In ice-9/boot-9.scm:
>>>   1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>>> In guix/status.scm:
>>> 829:3 15 (_)
>>> 809:4 14 (call-with-status-report _ _)
>>> In guix/scripts/system.scm:
>>>1256:4 13 (_)
>>> In ice-9/boot-9.scm:
>>>   1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
>>> In guix/store.scm:
>>>658:37 11 (thunk)
>>>1320:8 10 (call-with-build-handler # …)
>>>   2129:25  9 (run-with-store # …)
>>> In guix/scripts/system.scm:
>>> 827:2  8 (_ _)
>>> 703:8  7 (_ #)
>>> In gnu/system.scm:
>>>   1227:19  6 (operating-system-derivation _)
>>>748:11  5 (operating-system-services #< kernel:…>)
>>>782:20  4 (services _)
>>> In /etc/config.scm:
>>>185:14  3 (services #< kernel: #)
>>>185:14  2 (services #< name: "br" variant: "abnt…>)
>>> In ice-9/boot-9.scm:
>>>   1685:16  1 (raise-exception _ #:continuable? _)
>>>   1685:16  0 (raise-exception _ #:continuable? _)
>>>
>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> Wrong type to apply: #< name: "br" variant:
>> "abnt2" model: #f options: ()>
>>
>> ## Conclusion:
>>
>>Two things tell me that the problem is really in the keyboard
>>configuration within the configuration of the sddm service:
>>
>>* When I remove the `xorg-configuration` from the `sddm-configuration`,
>>  the reconfiguration returns no error, and the sddm service works
>>  normally.
>>* And in this setup, the keyboard works on the console, just not on the
>>  desktop environment.
>>
>> Best regards,
>> And thank you.
>>
>> Cassio
>>
>

Re: Trouble configuring guix

[Julien Lepiller]

Looking at the manual, I tgink this is the issue. sddm-configuration is a 
record type that has a field called xorg-configuration. This field expects a 
record of type xorg-configuration, but you pass it a keyboard configuration 
instead. I think this is what you need to do:

(sddm-configuration
  …
  (xorg-configuration
(xorg-configuration
  (keyboard-layout %this-keyboard

HTH!

On February 20, 2022 1:33:49 AM GMT+01:00, "Cássio Tavares" 
 wrote:
>Hello there!
>
>Well, I need help...
>
>## Context:
>
>  * I have just a little familiarity with Guile Scheme, because I'm a
>LilyPond user;
>  * I finally have a desktop that doesn't need non-libre drivers;
>  * Although I'm not in the Tech world, I love GNU's (and the FSF's)
>philosophy;
>  * I have been playing with Nix, but find it very cryptic -- not easy
>to understand at all.
>
>  So, Guix seems to be the path I'm on now.
>
>## Situation:
>
>  I have several problems to fix, but the most important right now is
>  to get my keyboard to work with sddm, and I need sddm for
>  Wayland. So, without sddm, this works:
>
>```
>...
>
>(define %this-keyboard  (keyboard-layout "br" "abnt2"))
>
>...
>
>(operating-system
>  ...
>
>  (keyboard-layout  %this-keyboard)
>
>  ... )
>
>```
>
>  But `guix system reconfigure /etc/config.scm` fails when this is this:
>
>```
>(use-modules
>  (gnu)
>  (gnu system nss)
>  (gnu services networking)
>  (gnu services sddm)
>  (gnu services cups)
>  (gnu services desktop)
>  (gnu services ssh)
>  (gnu services xorg))
>
>...
>
>(define %this-keyboard (keyboard-layout  "br" "abnt2"))
>
>...
>
>(operating-system
>  ...
>
>  (keyboard-layout  %this-keyboard)
>
>  ...
>
>  (services
>(append
>  (list
>(service dhcp-client-service-type)
>(service ntp-service-type)
>(service gpm-service-type)
>(service cups-service-type)
>(service elogind-service-type)
>(service sddm-service-type
>  (sddm-configuration
>(display-server "wayland")
>(numlock "on")
>(theme "guix-simplyblack-sddm-theme")
>(xorg-configuration
>  (keyboard-layout %this-keyboard)
>  %base-services))
>
>  ... )
>
>```
>
>  Then, when I try to run `guix system reconfigure /etc/config.scm`, I
>  get this backtrace:
>
>> root@udu ~#
>  > Backtrace:
>  >   19 (primitive-load "/root/.config/guix/current/bin/guix")
>  > In guix/ui.scm:
>  >2229:7 18 (run-guix . _)
>  >   2192:10 17 (run-guix-command _ . _)
>  > In ice-9/boot-9.scm:
>  >   1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>  > In guix/status.scm:
>  > 829:3 15 (_)
>  > 809:4 14 (call-with-status-report _ _)
>  > In guix/scripts/system.scm:
>  >1256:4 13 (_)
>  > In ice-9/boot-9.scm:
>  >   1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
>  > In guix/store.scm:
>  >658:37 11 (thunk)
>  >1320:8 10 (call-with-build-handler # …)
>  >   2129:25  9 (run-with-store # …)
>  > In guix/scripts/system.scm:
>  > 827:2  8 (_ _)
>  > 703:8  7 (_ #)
>  > In gnu/system.scm:
>  >   1227:19  6 (operating-system-derivation _)
>  >748:11  5 (operating-system-services #< kernel:…>)
>  >782:20  4 (services _)
>  > In /etc/config.scm:
>  >185:14  3 (services #< kernel: #)
>  >185:14  2 (services #< name: "br" variant: "abnt…>)
>  > In ice-9/boot-9.scm:
>  >   1685:16  1 (raise-exception _ #:continuable? _)
>  >   1685:16  0 (raise-exception _ #:continuable? _)
>  >
>  > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>  > Wrong type to apply: #< name: "br" variant:
>"abnt2" model: #f options: ()>
>
>## Conclusion:
>
>  Two things tell me that the problem is really in the keyboard
>  configuration within the configuration of the sddm service:
>
>  * When I remove the `xorg-configuration` from the `sddm-configuration`,
>the reconfiguration returns no error, and the sddm service works
>normally.
>  * And in this setup, the keyboard works on the console, just not on the
>desktop environment.
>
>Best regards,
>And thank you.
>
>Cassio
>

Re: install a Printer

[Julien Lepiller]

I tried your file, but I don't have the same issue. For me it fails with 
*cups-filters: unbound variable* (instead of cups-service-type). I only had to 
add this line near the top of the file (line 3):

(use-package-modules cups)

To make it available. Then the system builds.

On February 16, 2022 8:40:44 PM GMT+01:00, Gottfried  
wrote:
>This is the file content of /etc/config.scm file:  (*bold* are my 
>printer settings for better finding and reading)
>
>
>;; This is an operating system configuration generated
>;; by the graphical installer.
>
>(use-modules (gnu))
>(*use-service-modules cups* desktop networking ssh xorg)
>
>(operating-system
>   (locale "de_DE.utf8")
>   (timezone "Europe/Berlin")
>   (keyboard-layout (keyboard-layout "de"))
>   (host-name "Tuxedo")
>   (users (cons* (user-account
>   (name "gfp")
>   (comment "Gfp")
>   (group "users")
>   (home-directory "/home/gfp")
>   (supplementary-groups
>     '("wheel" "netdev" "audio" "video")))
>     %base-user-accounts))
>   (packages
>     (append
>   (list (specification->package "awesome")
>     (specification->package "nss-certs"))
>   %base-packages))
>   (services
>     (append
>   (list (service mate-desktop-service-type)
>     (service enlightenment-desktop-service-type)
>*(service cups-service-type**
>**            (cups-configuration**
>**                (web-interface? #t)**
>**                (extensions (list cups-filters hplip *
>         (service openssh-service-type)
>     (service tor-service-type)
>     (set-xorg-configuration
>   (xorg-configuration
>     (keyboard-layout keyboard-layout
>   %desktop-services))
>
>   (bootloader
>     (bootloader-configuration
>   (bootloader grub-efi-bootloader)
>   (target "/boot/efi")
>   (keyboard-layout keyboard-layout)))
>   (swap-devices
>     (list (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")))
>   (file-systems
>     (cons* (file-system
>  (mount-point "/boot/efi")
>  (device (uuid "BB77-FE3B" 'fat32))
>  (type "vfat"))
>    (file-system
>  (mount-point "/")
>  (device
>    (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
>  'ext4))
>  (type "ext4"))
>    %base-file-systems)))
>
>Am 16.02.22 um 18:01 schrieb Julien Lepiller:
>> Can you share again the content of your /etc/config.scm file?
>>
>> On February 16, 2022 5:04:02 PM GMT+01:00, Gottfried 
>>  wrote:
>>
>> Hello,
>>
>> thanks for Your email.
>>
>> I added cups to the service-modules (use-service-modules cups
>> desktop networking ssh xorg),
>>
>> after guix system reconfigure /etc/config.scm
>>
>> still it says:
>>
>> *Fehler: cups-service-type: Nicht gebundene Variable (Error:
>> cups-service-type: Unbound variable) *I don´t understand what that
>> means.*
>> *
>>
>> *I can´t**run: http://localhost:631*
>>
>> *my printer settings don´t recognise my printer yet.
>> *
>>
>> *
>> *
>>
>> Gottfried*
>> *
>>
>>
>>
>> Am 15.02.22 um 20:51 schrieb Julien Lepiller:
>>> You're all good. In addition to your modifications, you need to
>>> add cups to the list of service modules, at the top of the file:
>>>
>>> (use-service-modules cups desktop networking ssh xorg)
>>>
>>> HTH!
>>>
>>> On February 15, 2022 8:39:30 PM GMT+01:00, Gottfried
>>>  wrote:
>>>
>>> After:
>>>
>>> (list (service mate-desktop-service-type)
>>>     (service enlightenment-desktop-service-type)
>>> *(service cups-service-type**
>>> **            (cups-configuration**
>>> **                (web-interface? #t)**
>>> **                (extensions (list cups-filters hplip *
>>>         (service openssh-service-type)
>>>     (service tor-service-type)
>>>     (set-xorg-configuration
>>>

Re: install a Printer

[Julien Lepiller]

Can you share again the content of your /etc/config.scm file?

On February 16, 2022 5:04:02 PM GMT+01:00, Gottfried  
wrote:
>Hello,
>
>thanks for Your email.
>
>I added cups to the service-modules (use-service-modules cups desktop 
>networking ssh xorg),
>
>after guix system reconfigure /etc/config.scm
>
>still it says:
>
>*Fehler: cups-service-type: Nicht gebundene Variable (Error: 
>cups-service-type: Unbound variable) *I don´t understand what that means.*
>*
>
>*I can´t**run: http://localhost:631*
>
>*my printer settings don´t recognise my printer yet.
>*
>
>*
>*
>
>Gottfried*
>*
>
>
>
>Am 15.02.22 um 20:51 schrieb Julien Lepiller:
>> You're all good. In addition to your modifications, you need to add 
>> cups to the list of service modules, at the top of the file:
>>
>> (use-service-modules cups desktop networking ssh xorg)
>>
>> HTH!
>>
>> On February 15, 2022 8:39:30 PM GMT+01:00, Gottfried 
>>  wrote:
>>
>> After:
>>
>> (list (service mate-desktop-service-type)
>>     (service enlightenment-desktop-service-type)
>> *(service cups-service-type**
>> **            (cups-configuration**
>> **                (web-interface? #t)**
>> **                (extensions (list cups-filters hplip *
>>         (service openssh-service-type)
>>     (service tor-service-type)
>>     (set-xorg-configuration
>>   (xorg-configuration
>>     (keyboard-layout keyboard-layout
>>   %desktop-services))
>>
>> /etc# guix system reconfigure /etc/config.scm
>>
>> /etc/config.scm:43:14: Warnung: the 'target' field is deprecated,
>> please use 'targets' instead
>> guix system: Warnung: Vielleicht wollen Sie „guix pull“ ausführen
>> vor „guix system reconfigure“, um
>> aktuelle Pakete und Sicherheitsaktualisierungen zu bekommen.
>>
>> guix system: Warnung: Konnte die Provenienz von GNU Guix nicht
>> feststellen
>> Backtrace:
>> In ice-9/boot-9.scm:
>>     724:2 19 (call-with-prompt _ _ #> default-prompt-handle…>)
>> In ice-9/eval.scm:
>>     619:8 18 (_ #(#(#)))
>> In guix/ui.scm:
>>    2209:7 17 (run-guix . _)
>>   2172:10 16 (run-guix-command _ . _)
>> In ice-9/boot-9.scm:
>>   1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
>> In guix/status.scm:
>>     822:3 14 (_)
>>     802:4 13 (call-with-status-report _ _)
>> In guix/scripts/system.scm:
>>    1256:4 12 (_)
>> In ice-9/boot-9.scm:
>>   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
>> In guix/store.scm:
>>    658:37 10 (thunk)
>>    1320:8  9 (call-with-build-handler #> g…> …)
>>   2123:24  8 (run-with-store #> 7f227638a730> …)
>> In guix/scripts/system.scm:
>>     827:2  7 (_ _)
>>     703:7  6 (_ #)
>> In gnu/system.scm:
>>   1227:19  5 (operating-system-derivation _)
>>    748:11  4 (operating-system-services #<
>> kernel:…>)
>>    782:20  3 (services _)
>> In /etc/config.scm:
>>     29:33  2 (services #< kernel: #> linux-…>)
>>     In ice-9/boot-9.scm:
>>   1685:16  1 (raise-exception _ #:continuable? _)
>>   1685:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> *Fehler: cups-service-type: Nicht gebundene Variable*
>>
>> root@Tuxedo /etc#
>>
>>
>> There is still a mistake I guess.
>>
>> Thanks for helping, but please deal with it not today anymore.
>> "Lets call it a day".
>>
>>
>> Gottfried
>>
>>
>> Am 15.02.22 um 20:17 schrieb Julien Lepiller:
>>> Noticed the issue with what I typed (sorry not a the computer
>>> right now). Type this instead, at the same location:
>>>
>>> (service cups-service-type
>>> (cups-configuration
>>> (web-interface? #t)
>>> (extensions (list cups-filters hplip
>>>
>>> I added a closing parenthesis on the first line that shouldn't be
>>> here, and I forgot to wrap the value of the extensions (now it's
>>> a proper list instead of three values which is an error). Also
>>> check that the last closing parenthesis at the end of the fourth
>>>

Re: install a Printer

[Julien Lepiller]

You're all good. In addition to your modifications, you need to add cups to the 
list of service modules, at the top of the file:

(use-service-modules cups desktop networking ssh xorg)

HTH!

On February 15, 2022 8:39:30 PM GMT+01:00, Gottfried  
wrote:
>After:
>
>(list (service mate-desktop-service-type)
>     (service enlightenment-desktop-service-type)
>*(service cups-service-type**
>**            (cups-configuration**
>**                (web-interface? #t)**
>**                (extensions (list cups-filters hplip *
>         (service openssh-service-type)
>     (service tor-service-type)
>     (set-xorg-configuration
>   (xorg-configuration
>     (keyboard-layout keyboard-layout
>   %desktop-services))
>
>/etc# guix system reconfigure /etc/config.scm
>
>/etc/config.scm:43:14: Warnung: the 'target' field is deprecated, please 
>use 'targets' instead
>guix system: Warnung: Vielleicht wollen Sie „guix pull“ ausführen vor 
>„guix system reconfigure“, um
>aktuelle Pakete und Sicherheitsaktualisierungen zu bekommen.
>
>guix system: Warnung: Konnte die Provenienz von GNU Guix nicht feststellen
>Backtrace:
>In ice-9/boot-9.scm:
>     724:2 19 (call-with-prompt _ _ #)
>In ice-9/eval.scm:
>     619:8 18 (_ #(#(#)))
>In guix/ui.scm:
>    2209:7 17 (run-guix . _)
>   2172:10 16 (run-guix-command _ . _)
>In ice-9/boot-9.scm:
>   1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
>In guix/status.scm:
>     822:3 14 (_)
>     802:4 13 (call-with-status-report _ _)
>In guix/scripts/system.scm:
>    1256:4 12 (_)
>In ice-9/boot-9.scm:
>   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
>In guix/store.scm:
>    658:37 10 (thunk)
>    1320:8  9 (call-with-build-handler # …)
>   2123:24  8 (run-with-store # …)
>In guix/scripts/system.scm:
>     827:2  7 (_ _)
>     703:7  6 (_ #)
>In gnu/system.scm:
>   1227:19  5 (operating-system-derivation _)
>    748:11  4 (operating-system-services #< kernel:…>)
>    782:20  3 (services _)
>In /etc/config.scm:
>     29:33  2 (services #< kernel: #)
>In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>*Fehler: cups-service-type: Nicht gebundene Variable*
>
>root@Tuxedo /etc#
>
>
>There is still a mistake I guess.
>
>Thanks for helping, but please deal with it not today anymore. "Lets 
>call it a day".
>
>
>Gottfried
>
>
>Am 15.02.22 um 20:17 schrieb Julien Lepiller:
>> Noticed the issue with what I typed (sorry not a the computer right 
>> now). Type this instead, at the same location:
>>
>> (service cups-service-type
>> (cups-configuration
>> (web-interface? #t)
>> (extensions (list cups-filters hplip
>>
>> I added a closing parenthesis on the first line that shouldn't be 
>> here, and I forgot to wrap the value of the extensions (now it's a 
>> proper list instead of three values which is an error). Also check 
>> that the last closing parenthesis at the end of the fourth line closes 
>> the first one on the first line and you should be good!
>>
>>
>> On February 15, 2022 8:02:56 PM GMT+01:00, Julien Lepiller 
>>  wrote:
>>
>> Remove one closing parenthesis here: (service cups-service-type)
>>
>> On February 15, 2022 7:59:34 PM GMT+01:00, 
>> Gottfried  wrote:
>>
>> Hi, I did it, as You said, or did I do something wrong?
>> because the message was again: */etc/config.scm:25:2: Fehler:
>> (services (append (list (service mate-desktop-service-type)
>> (service enlightenment-desktop-service-type) (service
>> cups-service-type) (cups-configuration (web-interface? #t)
>> (extensions list cups-filters hplip))) (service
>> openssh-service-type) (service tor-service-type)
>> (set-xorg-configuration (xorg-configuration (keyboard-layout
>> keyboard-layout %desktop-services): invalid field
>> specifier* ;; This is an operating system configuration
>> generated ;; by the graphical installer. (use-modules (gnu))
>> (use-service-modules desktop networking ssh xorg)
>> (operating-system   (locale "de_DE.utf8")   (timezone
>> "Europe/Berlin")   (keyboard-layout (keyboard-layout "de"))  
>> (host-name "Tuxedo")   (users (cons* (user-account
>>   (name "gfp")   (comment
>> "

Re: install a Printer

[Julien Lepiller]

Noticed the issue with what I typed (sorry not a the computer right now). Type 
this instead, at the same location:

(service cups-service-type
 (cups-configuration
 (web-interface? #t)
 (extensions (list cups-filters hplip

I added a closing parenthesis on the first line that shouldn't be here, and I 
forgot to wrap the value of the extensions (now it's a proper list instead of 
three values which is an error). Also check that the last closing parenthesis 
at the end of the fourth line closes the first one on the first line and you 
should be good!


On February 15, 2022 8:02:56 PM GMT+01:00, Julien Lepiller  
wrote:
>Remove one closing parenthesis here: (service cups-service-type)
>
>On February 15, 2022 7:59:34 PM GMT+01:00, Gottfried  
>wrote:
>>Hi,
>>
>>I did it, as You said, or did I do something wrong?
>>
>>because the message was again:
>>
>>*/etc/config.scm:25:2: Fehler: (services (append (list (service 
>>mate-desktop-service-type) (service enlightenment-desktop-service-type) 
>>(service cups-service-type) (cups-configuration (web-interface? #t) 
>>(extensions list cups-filters hplip))) (service openssh-service-type) 
>>(service tor-service-type) (set-xorg-configuration (xorg-configuration 
>>(keyboard-layout keyboard-layout %desktop-services): invalid field 
>>specifier*
>>
>>;; This is an operating system configuration generated
>>;; by the graphical installer.
>>
>>(use-modules (gnu))
>>(use-service-modules desktop networking ssh xorg)
>>
>>(operating-system
>>   (locale "de_DE.utf8")
>>   (timezone "Europe/Berlin")
>>   (keyboard-layout (keyboard-layout "de"))
>>   (host-name "Tuxedo")
>>   (users (cons* (user-account
>>   (name "gfp")
>>   (comment "Gfp")
>>   (group "users")
>>   (home-directory "/home/gfp")
>>   (supplementary-groups
>>     '("wheel" "netdev" "audio" "video")))
>>     %base-user-accounts))
>>   (packages
>>     (append
>>   (list (specification->package "awesome")
>>     (specification->package "nss-certs"))
>>   %base-packages))
>>   (services
>>     (append
>>   (list (service mate-desktop-service-type)
>>     (service enlightenment-desktop-service-type)
>>*(service cups-service-type)**
>>**            (cups-configuration**
>>**                (web-interface? #t)**
>>**                (extensions list cups-filters hplip))) *
>>         (service openssh-service-type)
>>     (service tor-service-type)
>>     (set-xorg-configuration
>>   (xorg-configuration
>>     (keyboard-layout keyboard-layout
>>   %desktop-services))
>>
>>   (bootloader
>>     (bootloader-configuration
>>   (bootloader grub-efi-bootloader)
>>   (target "/boot/efi")
>>   (keyboard-layout keyboard-layout)))
>>   (swap-devices
>>     (list (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")))
>>   (file-systems
>>     (cons* (file-system
>>  (mount-point "/boot/efi")
>>  (device (uuid "BB77-FE3B" 'fat32))
>>  (type "vfat"))
>>    (file-system
>>  (mount-point "/")
>>  (device
>>    (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
>>  'ext4))
>>  (type "ext4"))
>>    %base-file-systems)))
>>
>>Gottfried
>>
>>
>>Am 15.02.22 um 19:34 schrieb Julien Lepiller:
>>> Almost. Right place, wrong parenthesis. Please read my first message 
>>> again and use the snippet I gave you. What you add must start with 
>>> "(service". Make sure the parenthesis are exactly at the same place I 
>>> showed you in the example, otherwise you're creating separate objects. 
>>> They're used to group things together. service, cups-service-type and 
>>> its configuration need to be in the same group.
>>>
>>> On February 15, 2022 7:29:19 PM GMT+01:00, Gottfried 
>>>  wrote:
>>>
>>> Hi,
>>>
>>> I did this:
>>>
>>> ;; This is an operating system configuration generated
>>> ;; by the graphical installer.
>>>
>>> (use-m

Re: install a Printer

[Julien Lepiller]

Remove one closing parenthesis here: (service cups-service-type)

On February 15, 2022 7:59:34 PM GMT+01:00, Gottfried  
wrote:
>Hi,
>
>I did it, as You said, or did I do something wrong?
>
>because the message was again:
>
>*/etc/config.scm:25:2: Fehler: (services (append (list (service 
>mate-desktop-service-type) (service enlightenment-desktop-service-type) 
>(service cups-service-type) (cups-configuration (web-interface? #t) 
>(extensions list cups-filters hplip))) (service openssh-service-type) 
>(service tor-service-type) (set-xorg-configuration (xorg-configuration 
>(keyboard-layout keyboard-layout %desktop-services): invalid field 
>specifier*
>
>;; This is an operating system configuration generated
>;; by the graphical installer.
>
>(use-modules (gnu))
>(use-service-modules desktop networking ssh xorg)
>
>(operating-system
>   (locale "de_DE.utf8")
>   (timezone "Europe/Berlin")
>   (keyboard-layout (keyboard-layout "de"))
>   (host-name "Tuxedo")
>   (users (cons* (user-account
>   (name "gfp")
>   (comment "Gfp")
>   (group "users")
>   (home-directory "/home/gfp")
>   (supplementary-groups
>     '("wheel" "netdev" "audio" "video")))
>     %base-user-accounts))
>   (packages
>     (append
>   (list (specification->package "awesome")
>     (specification->package "nss-certs"))
>   %base-packages))
>   (services
>     (append
>   (list (service mate-desktop-service-type)
>     (service enlightenment-desktop-service-type)
>*(service cups-service-type)**
>**            (cups-configuration**
>**                (web-interface? #t)**
>**                (extensions list cups-filters hplip))) *
>         (service openssh-service-type)
>     (service tor-service-type)
>     (set-xorg-configuration
>   (xorg-configuration
>     (keyboard-layout keyboard-layout
>   %desktop-services))
>
>   (bootloader
>     (bootloader-configuration
>   (bootloader grub-efi-bootloader)
>   (target "/boot/efi")
>   (keyboard-layout keyboard-layout)))
>   (swap-devices
>     (list (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")))
>   (file-systems
>     (cons* (file-system
>  (mount-point "/boot/efi")
>      (device (uuid "BB77-FE3B" 'fat32))
>  (type "vfat"))
>    (file-system
>  (mount-point "/")
>  (device
>    (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
>  'ext4))
>  (type "ext4"))
>    %base-file-systems)))
>
>Gottfried
>
>
>Am 15.02.22 um 19:34 schrieb Julien Lepiller:
>> Almost. Right place, wrong parenthesis. Please read my first message 
>> again and use the snippet I gave you. What you add must start with 
>> "(service". Make sure the parenthesis are exactly at the same place I 
>> showed you in the example, otherwise you're creating separate objects. 
>> They're used to group things together. service, cups-service-type and 
>> its configuration need to be in the same group.
>>
>> On February 15, 2022 7:29:19 PM GMT+01:00, Gottfried 
>>  wrote:
>>
>> Hi,
>>
>> I did this:
>>
>> ;; This is an operating system configuration generated
>> ;; by the graphical installer.
>>
>> (use-modules (gnu))
>> (use-service-modules desktop networking ssh xorg)
>>
>> (operating-system
>>   (locale "de_DE.utf8")
>>   (timezone "Europe/Berlin")
>>   (keyboard-layout (keyboard-layout "de"))
>>   (host-name "Tuxedo")
>>   (users (cons* (user-account
>>   (name "gfp")
>>   (comment "Gfp")
>>   (group "users")
>>   (home-directory "/home/gfp")
>>   (supplementary-groups
>>     '("wheel" "netdev" "audio" "video")))
>>     %base-user-accounts))
>>   (packages
>>     (append
>>   (list (specification->package "awesome")
>>     (specification->package "nss-certs"))
>>    

Re: install a Printer

[Julien Lepiller]

Almost. Right place, wrong parenthesis. Please read my first message again and 
use the snippet I gave you. What you add must start with "(service". Make sure 
the parenthesis are exactly at the same place I showed you in the example, 
otherwise you're creating separate objects. They're used to group things 
together. service, cups-service-type and its configuration need to be in the 
same group.

On February 15, 2022 7:29:19 PM GMT+01:00, Gottfried  
wrote:
>Hi,
>
>I did this:
>
>;; This is an operating system configuration generated
>;; by the graphical installer.
>
>(use-modules (gnu))
>(use-service-modules desktop networking ssh xorg)
>
>(operating-system
>   (locale "de_DE.utf8")
>   (timezone "Europe/Berlin")
>   (keyboard-layout (keyboard-layout "de"))
>   (host-name "Tuxedo")
>   (users (cons* (user-account
>   (name "gfp")
>   (comment "Gfp")
>   (group "users")
>   (home-directory "/home/gfp")
>   (supplementary-groups
>     '("wheel" "netdev" "audio" "video")))
>     %base-user-accounts))
>   (packages
>     (append
>   (list (specification->package "awesome")
>     (specification->package "nss-certs"))
>   %base-packages))
>   (services
>     (append
>   (list (service mate-desktop-service-type)
>     (service enlightenment-desktop-service-type)
>*(cups-service-type)**
>**        (cups-configuration)**
>**        (web-interface? #t)**
>**        (extensions list cups-filters hplip))) *
>         (service openssh-service-type)
>     (service tor-service-type)
>     (set-xorg-configuration
>   (xorg-configuration
>     (keyboard-layout keyboard-layout
>   %desktop-services))
>
>   (bootloader
>     (bootloader-configuration
>   (bootloader grub-efi-bootloader)
>   (target "/boot/efi")
>   (keyboard-layout keyboard-layout)))
>   (swap-devices
>     (list (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")))
>   (file-systems
>     (cons* (file-system
>  (mount-point "/boot/efi")
>  (device (uuid "BB77-FE3B" 'fat32))
>  (type "vfat"))
>    (file-system
>  (mount-point "/")
>  (device
>    (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
>  'ext4))
>  (type "ext4"))
>    %base-file-systems)))
>
>*Answer was:*
>
>*/etc/config.scm:25:2: Fehler: (services (append (list (service 
>mate-desktop-service-type) (service enlightenment-desktop-service-type) 
>(cups-service-type) (cups-configuration) (web-interface? #t) (extensions 
>list cups-filters hplip))) (service openssh-service-type) (service 
>tor-service-type) (set-xorg-configuration (xorg-configuration 
>(keyboard-layout keyboard-layout: invalid field specifier
>*
>
>  Gottfried
>
>
>
>Am 15.02.22 um 18:44 schrieb Julien Lepiller:
>> Hi,
>>
>> I'm sorry if my answer was confusing. Do not modify the 
>> use-service-modules form. Instead, insert the snippet I gave you at 
>> the same position as the other (service …) forms, for instance right 
>> below (service enlightenment-desktop-service-type)
>>
>> On February 15, 2022 6:31:46 PM GMT+01:00, Gottfried 
>>  wrote:
>>
>> Hi,
>>
>> I changed my
>>
>> /etc/config.scm file,to:
>> ;; This is an operating system configuration generated
>> ;; by the graphical installer.
>>
>> (use-modules (gnu))
>> (use-service-modules desktop networking ssh 
>> xorg*cups-service-type)(cups-configuration(web-interface? 
>> #t)(extensions list cups-filters hplip)))***
>> (operating-system
>>(locale "de_DE.utf8")
>>(timezone "Europe/Berlin")
>>(keyboard-layout (keyboard-layout "de"))
>>(host-name "Tuxedo")
>>(users (cons* (user-account
>>(name "gfp")
>>(comment "Gfp")
>>(group "users")
>>(home-directory "/home/gfp")
>>(supplementary-groups
>>  '("wheel" "netdev" "audio" "video")))
>> 

Re: install a Printer

[Julien Lepiller]

Hi,

I'm sorry if my answer was confusing. Do not modify the use-service-modules 
form. Instead, insert the snippet I gave you at the same position as the other 
(service …) forms, for instance right below  (service 
enlightenment-desktop-service-type)

On February 15, 2022 6:31:46 PM GMT+01:00, Gottfried  
wrote:
>Hi,
>
>I changed my
>
>/etc/config.scm file,to:
>;; This is an operating system configuration generated
>;; by the graphical installer.
>
>(use-modules (gnu))
>(use-service-modules desktop networking ssh 
>xorg*cups-service-type)(cups-configuration(web-interface? 
>#t)(extensions list cups-filters hplip)))***
>(operating-system
>   (locale "de_DE.utf8")
>   (timezone "Europe/Berlin")
>   (keyboard-layout (keyboard-layout "de"))
>   (host-name "Tuxedo")
>   (users (cons* (user-account
>   (name "gfp")
>   (comment "Gfp")
>   (group "users")
>   (home-directory "/home/gfp")
>   (supplementary-groups
> '("wheel" "netdev" "audio" "video")))
> %base-user-accounts))
>   (packages
> (append
>   (list (specification->package "awesome")
> (specification->package "nss-certs"))
>   %base-packages))
>   (services
> (append
>   (list (service mate-desktop-service-type)
> (service enlightenment-desktop-service-type)
> (service openssh-service-type)
> (service tor-service-type)
> (set-xorg-configuration
>   (xorg-configuration
> (keyboard-layout keyboard-layout
>   %desktop-services))
>   
>   (bootloader
> (bootloader-configuration
>   (bootloader grub-efi-bootloader)
>   (target "/boot/efi")
>   (keyboard-layout keyboard-layout)))
>   (swap-devices
> (list (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")))
>   (file-systems
> (cons* (file-system
>  (mount-point "/boot/efi")
>  (device (uuid "BB77-FE3B" 'fat32))
>  (type "vfat"))
>(file-system
>  (mount-point "/")
>  (device
>(uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
>  'ext4))
>  (type "ext4"))
>%base-file-systems)))
>
>
>*The answer was:*
>
>/etc/config.scm:5:0: Fehler: module (gnu services cups-service-type) not 
>found Hinweis: Der Befehl `guix system search cups-service-type' sucht 
>nach einem zu `cups-service-type' passenden Dienst. Wenn Sie eine 
>Ausgabe wie `location: gnu/services/foo.scm:188:2' sehen, fügen Sie 
>`foo' in Ihre `use-service-modules'-Form ein.
>
>Gottfried
>
>Am 15.02.22 um 17:54 schrieb Julien Lepiller:
>> Your service specification is not at the right place, and incorrect. 
>> You have to be careful with parenthesis, as they define the structure 
>> of things (similar to braces in other programming languages).
>>
>> The service specification needs to be inside the list, at the same 
>> level as all these (service …) forms. In the same way, you declare a 
>> service with (service foo-service-type ), and the 
>> configuration is usually a record, so it has parenthesis too.
>>
>> For records, you do:
>>
>> (
>> ( )
>> …)
>>
>> With as many fields as you want, as long as they exist. In your 
>> config, guix found (cups-service-type) at the same level as other 
>> fields of the operating-system, but operating-system doesn't support 
>> such a field directly, and the field does not have a value.
>>
>> Overall, try something like this, at the same parenthetical level as 
>> the other (service …) forms.
>>
>> (service cups-service-type)
>> (cups-configuration
>> (web-interface? #t)
>> (extensions list cups-filters hplip)))
>>
>> HTH!
>>
>>
>> On February 15, 2022 5:45:34 PM GMT+01:00, Gottfried 
>>  wrote:
>>
>> Hi,
>>
>> I tried to adjust my /etc/config.scm file, but I made some mistake.
>>
>> Could anybody help me please?
>>
>> here the file: (my changes are in bold letters)
>>
>> (I have installed cups, cups-filters, hplip in my guix system)
>>
>>
>> ;; This is an operating system configuration generated
>>
>> ;; by the graphical installer.
>>
>> (

Re: install a Printer

[Julien Lepiller]

Your service specification is not at the right place, and incorrect. You have 
to be careful with parenthesis, as they define the structure of things (similar 
to braces in other programming languages).

The service specification needs to be inside the list, at the same level as all 
these (service …) forms. In the same way, you declare a service with (service 
foo-service-type ), and the configuration is usually a record, 
so it has parenthesis too.

For records, you do:

(
  ( )
  …)

With as many fields as you want, as long as they exist. In your config, guix 
found (cups-service-type) at the same level as other fields of the 
operating-system, but operating-system doesn't support such a field directly, 
and the field does not have a value.

Overall, try something like this, at the same parenthetical level as the other 
(service …) forms.

(service cups-service-type)
   (cups-configuration
 (web-interface? #t)
 (extensions list cups-filters hplip)))

HTH!


On February 15, 2022 5:45:34 PM GMT+01:00, Gottfried  
wrote:
>Hi,
>
>I tried to adjust my /etc/config.scm file, but I made some mistake.
>
>Could anybody help me please?
>
>here the file: (my changes are in bold letters)
>
>(I have installed cups, cups-filters, hplip in my guix system)
>
>
>;; This is an operating system configuration generated
>
>;; by the graphical installer.
>
>(use-modules (gnu))
>(use-service-modules desktop networking ssh xorg *cups*)
>
>(operating-system
>   (locale "de_DE.utf8")
>   (timezone "Europe/Berlin")
>   (keyboard-layout (keyboard-layout "de"))
>   (host-name "Tuxedo")
>   (users (cons* (user-account
>   (name "gfp")
>   (comment "Gfp")
>   (group "users")
>   (home-directory "/home/gfp")
>   (supplementary-groups
>     '("wheel" "netdev" "audio" "video")))
>     %base-user-accounts))
>   (packages
>     (append
>   (list (specification->package "awesome")
>     (specification->package "nss-certs"))
>   %base-packages))
>   (services
>     (append
>   (list (service mate-desktop-service-type)
>     (service enlightenment-desktop-service-type)
>     (service openssh-service-type)
>     (service tor-service-type)
>     (set-xorg-configuration
>   (xorg-configuration
>     (keyboard-layout keyboard-layout
>   %desktop-services))
>*(cups-service-type)**
>**        (cups-configuration**
>**        (web-interface? #t**
>**        (extensions list cups-filters hplip*
>   (bootloader
>     (bootloader-configuration
>   (bootloader grub-efi-bootloader)
>   (target "/boot/efi")
>   (keyboard-layout keyboard-layout)))
>   (swap-devices
>     (list (uuid "51d5cd20-4513-4a02-9e35-df4338eccaa0")))
>   (file-systems
>     (cons* (file-system
>  (mount-point "/boot/efi")
>  (device (uuid "BB77-FE3B" 'fat32))
>  (type "vfat"))
>    (file-system
>  (mount-point "/")
>  (device
>    (uuid "4fb0ed7c-61ab-45eb-be0b-ff527b320e6d"
>  'ext4))
>  (type "ext4"))
>    %base-file-systems)))
>
>
>After running: sudo guix system reconfigure /etc/config.scm
>
>it said:
>
>35:16: Fehler: (cups-service-type): invalid field specifier     
>Fehler(german word means mistake)
>
>What do I have to change?
>
>
>Gottfried

Re: using german language

[Julien Lepiller]

You can speak German on this list, but as you guessed, you'll get answers only 
from German speakers :)

On February 13, 2022 9:56:56 AM GMT+01:00, Gottfried  
wrote:
>Hello,
>
>As a German native speaker I am asking if it makes sense to write in German.
>
>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?
>
>chloris
>
>

Re: Howddya specify max supported dependency version for a package?

[Julien Lepiller]

Simple unhelpful answer, you can't. Guix doesn't work like that. We don't 
specify package range or give a package any way to choose itt dependencies. 
When you specify a dependency, it's always a reference to a very specific 
packaqe (though the reference might evolve with newer guix revisions). It 
simplifies package management since there's no constraint solving or anything 
of the sort.

For your problem I see two potential solutions: fix the package to allow our 
current python version, though there might be a reason why it's not allowed, or 
package python 3.5 and use it instead of the current python version.

HTH

Le 16 janvier 2022 08:03:53 GMT+01:00, Jacob Hrbek  a 
écrit :
>(define-public qbittorrent
>   (package
>     (name "qbittorrent")
>     (version "4.2.5")
>     (source
>  (origin
>    (method git-fetch)
>    (uri (git-reference
>  (url "https://github.com/qbittorrent/qBittorrent;)
>  (commit (string-append "release-" version
>    (file-name (git-file-name name version))
>    (sha256
>     (base32 "1n613ylg6i9gisgk0dbr2kpfasyizrkdjff1r8smd4vri2qrdksn"
>     (build-system gnu-build-system)
>     (arguments
>  `(#:configure-flags
>    (list (string-append "--with-boost-libdir="
>     (assoc-ref %build-inputs "boost")
>     "/lib")
>  "--enable-debug"
>  "QMAKE_LRELEASE=lrelease")
>    #:modules ((guix build gnu-build-system)
>   (guix build qt-utils)
>   (guix build utils))
>    #:imported-modules (,@%gnu-build-system-modules
>    (guix build qt-utils))
>    #:phases
>    (modify-phases %standard-phases
>  (add-after 'install 'wrap-qt
>    (lambda* (#:key outputs inputs #:allow-other-keys)
>  (let ((out (assoc-ref outputs "out")))
>    (wrap-qt-program "qbittorrent" #:output out #:inputs 
>inputs))
>  #t)
>     (native-inputs
>  (list pkg-config qttools))
>     (inputs
>  `(("boost" ,boost)
>    ("libtorrent-rasterbar" ,libtorrent-rasterbar)
>    ("openssl" ,openssl)
>     ;; NOTE(Krey): Max supported version declared in 
>https://github.com/qbittorrent/qBittorrent/blob/5c0378a6845e3484023f4c76893ff9f0e5178460/src/base/utils/foreignapps.cpp#L269
>    ("python" ,python-wrapper)
>    ("qtbase" ,qtbase-5)
>    ("qtsvg" ,qtsvg)
>    ("zlib" ,zlib)))
>     (home-page "https://www.qbittorrent.org/;)
>     (synopsis "Graphical BitTorrent client")
>     (description
>  "qBittorrent is a BitTorrent client programmed in C++/Qt that uses
>libtorrent (sometimes called libtorrent-rasterbar) by Arvid Norberg.
>
>It aims to be a good alternative to all other BitTorrent clients out there.
>qBittorrent is fast, stable and provides unicode support as well as many
>features.")
>     (license l:gpl2+)))
>
>
>I am trying to make a patch to fix 
>https://github.com/qbittorrent/qBittorrent/issues/16139 which is caused 
>by us using an unsupported python version -> How can i specify that the 
>package is only allowed to use python 3.2 <= 3.5.0 ?
>
>-- 
>Jacob Hrbek
>

Re: Add VLAN with Guile Netlink link-add

[Julien Lepiller]

Thanks for the report! It looks like I didn't read the netlink documentation 
properly and forgot a part of the message. I think I just fixed that in 
guile-netlink 1.1.2. You can access it with --with-latest=guile-netlink ;)

Le 10 janvier 2022 12:29:38 GMT+01:00, Niklas Schmidt  a 
écrit :
>Dear Guix,
>
>I really appreciate the ability to declare a static-networking 
>configuration.
>
>I face some difficulties adding a 802.1Q VLAN interface using the Guile 
>Netlink package. I added guile-netlink to my operating system 
>definition's packages field.
>
>Running guile as root using su, I get the following error:
>
>   scheme@(guile-user)> (use-modules (ip link))
>   scheme@(guile-user)> (link-add "ens3.12" "vlan" #:type-args '((id .  12)))
>   ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>   ERROR:
> 1. : 22
>   
>   Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>   scheme@(guile-user) [1]> 
>
>
>The documentation [1] states:
>
>   Scheme Procedure: link-add name type [#:type-args '()]
>
> Add a new link with given name and type. Additional arguments can be 
> passed to control the state of the link at creation. type-args is an 
> association list containing additional values for the given type.
>
> When type is "vlan", type-args can contain a number associated with 'id: 
> the VLAN id to be created.
>
>It is unclear to me how to specify the hardware interface for which the 
>VLAN link is to be added. Maybe I am missing something?
>
>Calling the above command with "ens3" instead of "ens3.12" results in 
>the same error.
>
>I am able to add the link manually with iproute2 by executing
>
>   ip link add link ens3 name ens3.12 type vlan id 12
>
>and was able to verifiy that it works by assigning a static IPv4 
>address.
>
>If I run another command given in the documentation [1],
>
>   (link-add "v0p0" "veth" #:type-args '((peer . "v0p1")))
>
>that returns #t and creates the interface pair. So I think, Guile 
>Netlink generally works with my configuration.
>
>Has someone got a working code sample showing how to add VLANs using 
>Guile Netlink?
>I don't understand the internals of the Netlink kernel interface yet.  A 
>comment in the source code [2] says that every link type except veth and 
>vlan is not implemented in Guile Netlink. I am not sure whether the 
>functionality I whish to use is supported at all.
>
>My goal is to specify VLAN links in the links field of a 
>static-networking record.
>
>Im running Guix inside QEMU-KVM. If that would help, I am willing to 
>test this on real hardware.
>
>Thanks for advice.
>
>
>Greetings
>Niklas
>
>[1]: https://git.lepiller.eu/guile-netlink/manual/html_node/Link.html
>[2]: https://git.lepiller.eu/guile-netlink/tree/-/ip/link.scm
>

Re: Nginx with PHP and sqlite

[Julien Lepiller]

The manual has an example of how to use php fpm with nginx, using 
nginx-php-location for instance.

Le 19 décembre 2021 15:47:55 GMT-05:00, Andreas Enge  a écrit :
>Hello,
>
>I would like to create a website using PHP and sqlite; so far my server
>uses Nginx (and static pages), whereas the "web services" part of the Guix
>documentation only explains how to add PHP to Apache.
>
>Would anyone have a sample configuration for PHP with Nginx, preferably
>with sqlite as a database backend?
>
>Thanks for your help,
>
>Andreas
>
>

Re: Guix Merch?

[Julien Lepiller]

Le Sat, 11 Dec 2021 16:49:35 -0600,
Caleb Herbert  a écrit :

> I would like Guix stickers and pins!
> 

Hi everyone!

I have a few leftover stickers from Fosdem 2019, see attached picture.
Since they were meant to be distributed to folks at Fosdem, I'm
offering them for free. I can mail some of them to anyone interested if
you tell me which color you like and how much you want (don't ask for
too much, I only have 9 with white background and 7 with black
background). Send me your address and a promise to reimburse the stamp
price. I can also include an OSM France sticker if you're interested :)

Note that I'm not selling the stickers, I'm just proposing to send a
few to people who are interested. If you feel bad about asking for free
stickers, then you can also make a donation to Guix (via the FSF) or
Guix Europe.

Re: Run .deb or .rpm packages

[Julien Lepiller]

I don't think it's a good idea to use a .deb or .rpm with guix, as they contain 
precompiled software. Even considering free software, they are compiled with a 
giver system (probably ubuntu and fedora, respectively) that make them 
incompatible with guix. Even if you successfuly installed them, I'm afraid 
you'd get a confusing "file not found" anyway.

You should ask your government for the source code, and compile it for the guix 
system. Sorry that this is my best answer, it's probably not what you wanted to 
hear :/ 

Le 8 décembre 2021 14:46:24 GMT-05:00, "André A. Gomes" 
 a écrit :
>Gary Johnson  writes:
>
>> André A. Gomes  writes:
>>
>>> Hi Guix,
>>>
>>> I'm wondering if it's possible to install .deb or .rpm packages on the
>>> Guix system.
>>>
>>> For context, my government only provides me these solutions to install a
>>> authentication plugin that I use with my ID (smart) card.
>>>
>>> Thanks.
>>
>> Hi André,
>>
>> You can install the `dpkg` package with `guix package -i dpkg`. Hope
>> that helps.
>
>Indeed.  I should have said that I did that, and then encountered the
>following issue:
>
>--8<---cut here---start->8---
>$ sudo dpkg -i foo-package.deb 
>dpkg: error: unable to access the dpkg database directory 
>/gnu/store/902w5i1j38r33l6p871dyhng19zj1phk-dpkg-1.20.9/var/lib/dpkg: 
>Read-only file system
>--8<---cut here---end--->8---
>
>Any ideas?  I don't know much about .deb or .rpm.
>
>Thank you Gary.
>
>
>-- 
>André A. Gomes
>"Free Thought, Free World"
>

Re: downgrade issue on guix system

[Julien Lepiller]

Le 25 novembre 2021 07:06:19 GMT-05:00, Alexander Asteroth 
 a écrit :
>No I did not play around with branches. What I did was
>- changed my config
>- reconfigured
>- rebooted
>- failed
>- booted second last config
>- fixed config
>- reconfigured
>- rebooted
>- OK
>- pulled
>- added cups
>- reconfigured
>>>> ERROR
>
>I just tried again. Did a
>
>GUIX_PROFILE="~/.guix-profile" &&  . "$GUIX_PROFILE/etc/profile"
>hash guix
>guix system reconfigure .../config.scm

This is not enough: you need to also load the "current" profile. Check the 
output of "type guix" too.

>
>Same error.
>
>Is there a way to find out what goes wrong? And why I have something
>installed that is newer than what I get over the guix channel?

I think this is because you're not actually running guix from the latest you 
pulled. Make sure it's running from ~/.config/guix/current, not ~/.guix-profile 
nor /var/guix.

This should already be taken care of by default, but if this is your first guix 
pull you might need a reboot (or at least log out, and in again).

>
>-- Alex
>
>On Thu, Nov 25 2021, 06:53:59, Julien Lepiller  wrote:
>
>> Hi Alexander,
>>
>> Since you did a guix pull, you should have a newer version of guix than you 
>> had before, unless you played with branches. So the downgrade is worrying 
>> and you were right to stop there.
>>
>> Note that running guix pull will update guix in a separate profile. Make 
>> sure it's loaded: that you have ~/.config/guix/current/bin in your path and 
>> that "type guix" is this path. If not, fix
>> your $PATH and run "hash guix" (no output) and check again.
>>
>> Note that, if you're running reconfigure as root (instead as with sudo) 
>> you'll need to pull and do the above as root, since each user has a 
>> different guix current profile.
>>
>> HTH!
>>
>> Le 25 novembre 2021 06:38:29 GMT-05:00, Alexander Asteroth 
>>  a écrit :
>>
>>  Dear all,
>>
>> I just wanted to install cups service on my guix system. I recofigured
>> the system without an error one hour ago (introduced seperate home
>> filesystem) and now, when I try to add the cups service (I did a guix
>> pull in between as well) I get:
>>
>>  guix system: error: aborting reconfiguration because commit 
>> bd2aa8031babdca5f574fca52e025d6794f08d82 of channel 'guix' is not a 
>> descendant of
>>  7f974548ac20cab88b9bb589a5e1d85ee3b8d337
>> hint: Use `--allow-downgrades' to force this downgrade.
>>
>> I have no clue what caused that error therefor I also don't know if it's
>> a good idea to allow downgrades. ... or what es to do to resolve the
>> issue.
>>
>> Cheers,
>>
>> Alex
>

Re: downgrade issue on guix system

[Julien Lepiller]

Hi Alexander,

Since you did a guix pull, you should have a newer version of guix than you had 
before, unless you played with branches. So the downgrade is worrying and you 
were right to stop there.

Note that running guix pull will update guix in a separate profile. Make sure 
it's loaded: that you have ~/.config/guix/current/bin in your path and that 
"type guix" is this path. If not, fix your $PATH and run "hash guix" (no 
output) and check again.

Note that, if you're running reconfigure as root (instead as with sudo) you'll 
need to pull and do the above as root, since each user has a different guix 
current profile.

HTH!

Le 25 novembre 2021 06:38:29 GMT-05:00, Alexander Asteroth 
 a écrit :
>Dear all,
>
>I just wanted to install cups service on my guix system. I recofigured
>the system without an error one hour ago (introduced seperate home
>filesystem) and now, when I try to add the cups service (I did a guix
>pull in between as well) I get:
>
>> guix system: error: aborting reconfiguration because commit 
>> bd2aa8031babdca5f574fca52e025d6794f08d82 of channel 'guix' is not a 
>> descendant of 7f974548ac20cab88b9bb589a5e1d85ee3b8d337
>> hint: Use `--allow-downgrades' to force this downgrade.
>
>I have no clue what caused that error therefor I also don't know if it's
>a good idea to allow downgrades. ... or what es to do to resolve the
>issue.
>
>Cheers,
>
>Alex
>
>

Re: packages won't pass white space linting -- what am I doing wrong?

[Julien Lepiller]

Hi, it looks like the linter is correct: there is a tab at the beginning of the 
lines 31, 32 and following. We don't use tabs for identation, please replace 
them with spaces as suggested by the linter :)

Le 12 novembre 2021 02:02:17 GMT-05:00, Blake Shaw 
 a écrit :
>
>hiya guix,
>
>I have a set of packages ready to send upstream, but I can't seem to
>to get them to pass tabulation tests in the linter. as an example, I
>here is the package notcurses which builds and installs fine, yet while
>I wrote it using `guix-devel-mode` in emacs and its thus indented
>accordingly, when I lint it I get:
>
>```bash
>error: TODO:: unbound variable
>hint: Did you forget a `use-modules' form?
>
>~/src/rml/unguix/notcurses.scm:31:0: notcurses@2.4.9: tabulation on line 31, 
>column 0
>~/src/rml/unguix/notcurses.scm:32:0: notcurses@2.4.9: tabulation on line 32, 
>column 0
>[...] ;;and so on for each line until the end of the file.
>```
>the package definition is available here:
>https://git.sr.ht/~cybersyn/rml/tree/devel/item/unguix/notcurses.scm
>
>while it appears to look like other package definitions, I can't seem to
>figure out what the issue is. I tried disabling lispy-mode, a paredit
>like emacs mode, re-tabulating and linting again, but it produce the
>same result.
>
>could this perhaps be a bug in the linter?
>
>best,
>blake
>
>-- 
>“In girum imus nocte et consumimur igni”
>

Re: Help with a GraalVM package?

[Julien Lepiller]

Le 27 octobre 2021 06:15:27 GMT-04:00, Ekaitz Zarraga  a 
écrit :
>Hi Gary,
>
>> Hi Guix,
>>
>> Has anyone had any luck in building a package definition for GraalVM?
>>
>> Https://www.graalvm.org/
>
>Probably not, but it can be you, or maybe me in the near future.
>
>> I'm a Clojure programmer in my day job, and one of the areas I work in
>> Is (open source) high performance wildland fire modeling. GraalVM could
>> Really help me speed up my existing OpenJDK-based models as well as help
>> Me build other GraalVM-dependent Guix packages like the Clojure linter,
>> Clj-kondo.
>>
>> Any help with this task (or a pointer to a channel with a working
>> Package definition) would be much appreciated.
>>
>
>The guix documentation has a good explanation about how to make packages, but
>this one might be complex.
>
>I searched a little bit and I didn't find any guide on how to build GraalVM
>itself, if you can find me one I can try to guide you in making the package
>or at least we could evaluate how hard is it.
>
>Cheers,
>Ekaitz
>

Hi,

This is what I found: https://github.com/oracle/graal/blob/master/vm/README.md

That info is not easy to find. Why hide it in a subdirectory?… Also, I have no 
idea what this mx thing is.

Re: help: screen tearing in guix

[Julien Lepiller]

Hi,

I'd be interested in the content of that file. Where does it come from, can you 
share it? As a bonus, I would be able to use it and help you if I find out how 
to configure my system to use it :)

Le 22 octobre 2021 02:16:48 GMT-04:00, "Daniel Meißner" 
 a écrit :
>Hi dikasetyaprayogi,
>
>> hello fresh guixsd user here, i had a problem with screen tearing.
>>
>> usually in my other parabola gnu linux machine i just make intel anti
>> tearing conf in /etc/X11/xorg.conf.d/20-intel.conf and the problem
>> gone.
>>
>> when i do this in guix looks there is no effect, any way how to
>> integrate this to guixsd? thanks.
>
>The system configuration of Guix works a little differently from
>manipulating the config files directly.  Instead, the whole system
>configuration is done inside of an operating-system record in a Scheme
>file (see [1] for more info).  You can add your Xorg configuration to
>the xorg-configuration record field of your display manager (see [2])
>and then run `guix system reconfigure /path/to/your/config.scm'.  If you
>have installed Guix via its graphical installer you should find your
>system configuration at `/etc/config.scm'.
>
>Best
>Daniel
>
>1: 
>https://guix.gnu.org/de/manual/devel/en/html_node/Using-the-Configuration-System.html
>2: https://guix.gnu.org/de/manual/devel/en/html_node/X-Window.html#X-Window
>