Re: Build and upgrade times for heavier packages on old hardware

[Csepp]

Oleander via  writes:

> Hello everyone,
> I'm considering disabling substitutes on my current Guix system
> running on an old Thinkpad with an i5-2520M, 10GB of ram and an SSD.
>
> Considered that many of you might be running Guix on something similar
> due to the compatibility between coreboot/libreboot and old Thinkpads,
> how long would it take approximately to build and upgrade packages
> like:
>
> linux-libre
> gcc
> icecat
> Emacs
> Wayland/Sway
> X11
> EXWM
> texlive-base
> pandoc
> alacritty
>
> ?
>
> Thank you,

Prohibitively.
The word that comes to mind is: "prohibitively".

Re: Using cross-compiled packages (e.g. x86_64-linux-gnux32 on x86_64-linux-gnu)

[Csepp]

Sven Hartrumpf  writes:

> Hello.
>
>> Sven Hartrumpf writes:
>>
>>> Hello.
>>>
>>> I want to cross-compile some packages for the x32 ABI
>>> (because it can speed up one of my performance-critical applications).
>>> Thanks to Efraim’s recent changes, I can simply use
>>>
>>>   # guix build lz4 –target=x86_64-linux-gnux32
>>> (lz4 is only a simple example, not the one which is important for me :-)
>>>
>>> What is a good or simple way to use the resulting binaries
>>> (which I find under /gnu/store/…/bin/lz4)?
>>> My user-land binaries are mainly x86_64-linux-gnu, only few will be
>>> x86_64-linux-gnux32.
>>>
>>> Greetings
>>> Sven
>
> Csepp wrote, 2024-01-26:
>
>> Don’t they run as normal?
>
> They do.
> I was looking for a way to prefer some x32 binaries over the 64bit ones.
>
>> If the question is about installing them in a profile, you could put them
>> in a manifest. Or you could try grafting them into existing packages if you
>> want them to use them in scripts. But be careful that you don’t mix
>> libraries into that.
>
> For many packages, I will have two builds in /gnu/store , e.g.
>
>   # file /gnu/store/*zstd*/bin/zstd
> /gnu/store/p61ifh74s4n4jg7c1j1f2gw2c235lna0-zstd-1.5.5/bin/zstd: ELF 64-bit 
> LSB
> executable, x86-64, version 1 (SYSV), dynamically linked, interpreter
> /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/ld-linux-x86-64.so.2,
> for GNU/Linux 2.6.32, stripped
> /gnu/store/yf15abzz51wfapi699g1xp02lklkis5z-zstd-1.5.5/bin/zstd: ELF 32-bit 
> LSB
> executable, x86-64, version 1 (SYSV), dynamically linked, interpreter
> /gnu/store/dxxbn44p9lfy7pbpj82kj68rk2mixn89-glibc-cross-x86_64-linux-gnux32-2.35/lib/ld-linux-x32.so.2,
> for GNU/Linux 2.6.32, stripped
>
>> But as far as using them goes, I’m pretty sure you can just run them. Guix
>> is actually really nice for this use case, because you don’t have to
>> manually manage a different sysroot for every ABI. I’ve used this property
>> at work to cross-build an ARM package and transfer it to a Raspberry Pi. It
>> just worked.
>
> Yes.
> But thhe use of –target for building x32 binaries is somewhat different from 
> cross-compilation
> because the resulting binaries can (and should) be run on the host system. 
> And of course,
> a profile can only referenced one version and that will be the 64bit version.
>
> I came up with a naive solution which works for me (as a Guix System 
> beginner).
> I explicitly put links in ~/.local/bin/x86_64-linux-gnux32/ to the x32 
> binaries I prefer.
> (~/.local/bin/x86_64-linux-gnux32/ is the first element in my PATH).
>
> Greetings
> Sven

I recommend looking into package transformations (especially how grafts work) 
and/or managing multiple profiles.
If you want to have the x32 variants in your profile, I think you can do that 
with a manual graft.

Re: Using cross-compiled packages (e.g. x86_64-linux-gnux32 on x86_64-linux-gnu)

[Csepp]

Sven Hartrumpf  writes:

> Hello.
>
> I want to cross-compile some packages for the x32 ABI
> (because it can speed up one of my performance-critical applications).
> Thanks to Efraim’s recent changes, I can simply use
>
>   # guix build lz4 –target=x86_64-linux-gnux32
> (lz4 is only a simple example, not the one which is important for me :-)
>
> What is a good or simple way to use the resulting binaries
> (which I find under /gnu/store/…/bin/lz4)?
> My user-land binaries are mainly x86_64-linux-gnu, only few will be
> x86_64-linux-gnux32.
>
> Greetings
> Sven

Don’t they run as normal?
If the question is about installing them in a profile, you could put them in a 
manifest.  Or you could try grafting them into existing packages if you want 
them to use them in scripts.  But be careful that you don’t mix libraries into 
that.
But as far as using them goes, I’m pretty sure you can just run them.  Guix is 
actually really nice for this use case, because you don’t have to manually 
manage a different sysroot for every ABI.  I’ve used this property at work to 
cross-build an ARM package and transfer it to a Raspberry Pi.  It just worked.

Re: Anyone got distrobox working?

[Csepp]

your friendly localhost admin  writes:

> Fredrik Salomonsson  writes:
>
>> Hi,
>>
>> I noticed that guix has [distrobox][0] packaged but it does not seem to
>> work.
>> …
>
> I have a partial fix pending that I have used successfully to create an Arch 
> container and run some nontrivial pacman commands in it.
> 
>
> Podman should also be updated, because rootless containers seem to get stuck 
> in a stopping state, and newer releases might have a fix for that.

I slightly messed up, distrobox-init should not be wrapped, nor should its 
shebang line be replaced, otherwise it won’t execute inside the container, 
because there is no /gnu/store in there.  But that is easy enough to fix, just 
bind mount Guix’s folders too:

distrobox create –additional-flags ’–mount type=bind,src=/gnu,target=/gnu 
–mount type= bind,src=/var/guix,target=/var/guix’ –image 
quay.io/toolbx-images/ubuntu-toolbox:22.04 –name ubuntu-22-toolbox

Re: Setting package name/version using package transformations

[Csepp]

Steve George  writes:

> Hi,
>
> I’m exploring creating ’package variants’ through the ’package 
> transformation’ options to guix build [0]
>
> I can’t figure out how to build a package variant and give it a different name
>
> The most common sort of ’package variant’ I can imagine is where the user 
> wants a different (later) version of the source than is available in Guix. An 
> example is Calcurse where Guix’s archive has 4.5.1 and upstream has 4.8.1. I 
> can use the –with-source package transformation to build the later version 
> from the upstream source location:
>
>   $ guix shell –container –nesting –network –development calcurse –no-grafts 
> nss-certs
>   [env]$ guix build calcurse 
> –with-source= 
> –no-substitutes –no-grafts
>
> This will create a calcurse package which I can install and it contains 
> calcurse 4.8.1
>
> $ guix package –list-installed
> calcurse4.8.1   out 
> /gnu/store/af4nwvbcd8rbix4vcvamblmbf3ns9wsz-calcurse-4.8.1
>
> Maybe it’s due to my previous Linux experiences, but the next thing I wanted 
> to do was give the package a different name and/or different version number 
> so I would know it was a local build. In Debian/Ubuntu I would have named the 
> package -futurile and probably given it a different version number 
> so I could control when it was upgraded. I cannot figure out how to do either 
> of these using a package transformation, rather than defining my own package 
> file etc.
>
> 1. Can a package be given a different name with a transformation?

Not as far as I know.

> Manual says –with-source=package=source, I tried:
>
> # nope - unknown package calcurse-futurile
> guix build calcurse-futurile 
> –with-source=calcurse= 
> –no-substitutes –no-grafts
>
> # kinda works
> guix build calcurse 
> –with-source=calcurse-futurile=
>  –no-substitutes –no-grafts
>
> The second builds the ’calcurse’ package, but it no longer uses the updated 
> source (so I get v4.5.1). I can guess that this is because it has to be a 
> valid package name from the archive and calcurse-futurile isn’t one.

That’s correct.  The transformation can act on packages other than the build 
target, which is why you need to name what package (and optionally what version 
of that package) you are attempting to transform.
For example I might want to run:
guix build –with-latest=ffmpeg vlc
That would build VLC with the latest ffmpeg everywhere in the dependency tree.

> 2. Can a package be given a different version number with a transformation?
> I can give a package a different version number, but the field is 
> constrained. There’s no way to use characters other than hypen and dot, so 
> you can’t use tilde or full colon for example.
>
> # this works
> guix build calcurse 
> –with-source=calcurse@5.4.8.1=
>  –no-substitutes –no-grafts
>
> # not allowed colons or tilde in the field so no ’epoch’ ala Debian
> # it breaks the if you have anything other than .xx.xxx
> guix build calcurse –with-source=calcurse@5:4.8.1
> guix build calcurse –with-source=calcurse@4.8.1~futurile
>
> I eventually found a way to to change the package name, byt giving a name as 
> part of the version:
>
> # this seems to change the package name?
> guix build calcurse 
> –with-source=calcurse@futurile-0.1=
>  –no-substitutes –no-grafts
>
> guix package –list-installed
> calcurse-futurile   0.1 out 
> /gnu/store/40bprd6gvwf94x42fxdlf739y55p7xip-calcurse-futurile-0.1
>
> This seems to take the first part of the name after the @, up to a hyphen and 
> make it part of the package name. I’m a bit confused about why this works. 
> The manual says –with-source=package@version=source, but this seems to be 
> package@custom_name-version=source - I guess I don’t understand the formats 
> of the –with-source field?
>
> Maybe I have a misunderstanding of the scope of usage for ’package 
> transformations’ in the cli - am I twisting it to do something that it 
> shouldn’t be?
>
> Thanks,
>
> Futurile
>
> [0] 
> 

I think you are only changing the version field in this case

I’m not sure if what you are trying to accomplis is actually needed.  If you 
are worried about accidentally upgrading the transformed package, take a look 
at the output of guix package –export-manifest.

Re: GuixSD automated installation

[Csepp]

Ian Eure  writes:

> Hello,
>
> On Debian, you can create a preseed file containing answers to all the 
> questions
> you’re prompted for during installation, and build a new install image which
> includes it.  When booted, this installer skips any steps which have been
> preconfigured, which allows for either fully automated installation, or partly
> automated (prompt for hostname and root password, but otherwise automatic).
>
> Does Guix have a way to do something like this?  The declarative config is 
> more
> or less the equivalent of the Debian preseed file, but I don’t see anything 
> that
> lets you build an image that’ll install a configuration.
>
> I see there’s `guix deploy’, but that requires an already-installed GuixSD to
> work, which isn’t helpful for getting it installed in the first place.
>
> Thanks,
>
>  — Ian

guix system image is maybe closer, but it doesn’t automate everything that the
installer does.
But the installer can be used as a Scheme library, at least in theory.  The way
I would approach the problem is by creating a Shepherd service that runs at boot
from the live booted ISO.

Re: Shepherd user services that run on startup?

[Csepp]

Ben Weinstein-Raun  writes:

> Hello! I'm fairly new to using Guix System, and I have a lot of questions.
>
> One is: Is it possible to run a shepherd user service at system start, 
> rather than at login?
>
> My guess is that this is at least possible, by defining a system-level 
> service that starts a shepherd for each user. Would that work?
>
> Anyone have tips on how to go about building this, if so? Especially: 
> What's the easiest way to ensure that a guix service knows the list of 
> users-with-login-shells on the system? And easiest way to run a 
> `shepherd` instance as each such user on startup? I'm working on writing 
> a service definition, but as this is my first from-scratch service (guix 
> or shepherd), and one of my first lisp projects since reading SICP 15 
> years ago, it's slow going (even with the reference manual and source 
> code of other services).
>
>
> And, of course, is there a simpler way?
>
>
> (I also asked this question on the r/guix subreddit, but haven't heard 
> anything yet, and figured I'd ask here too)

Not a direct answer, but this seems similar to systemd's linger
functionality, that might be worth taking a look at.

Re: Resize Filesystem Service

[Csepp]

#+OPTIONS: html-postamble:nil H:5 num:nil ^:{} toc:nil author:nil email:nil 
tex:dvipng d:nil
#+STARTUP: hidestars indent inlineimages
:PROPERTIES:
:reply-to: nil
:attachment: nil
:alternatives: (utf-8)
:END:

Efraim Flashner  writes:

> [[PGP Signed Part:Undecided]]
> On Thu, Dec 07, 2023 at 09:25:43AM +, Wicki Gabriel (wicg) wrote:
>> Hi
>>
>> Thanks for the input, Felix. I finally managed to get it to work (with
>> additional input from ludo). I attach the service to this mail. If people
>> think this might be a nice-to-have in upstream guix i'll happily craft a
>> patch.
>>
>> g
>> 
>> From: Felix Lechner 
>> Sent: Monday, December 4, 2023 9:18 PM
>> To: Wicki Gabriel (wicg) ; help-guix@gnu.org 
>> 
>> Subject: Re: Resize Filesystem Service
>>
>> Hi Gabriel,
>>
>> On Mon, Dec 04 2023, Wicki Gabriel wrote:
>>
>> > I crafted the service in the file attached but this doesn't work and i
>> > neither know where to look nor how to debug the issue.
>>
>> Writing services is probably more complex than it should be, but it can
>> be done.
>>
>> Please have a look at the cachefilesd-service [1] which I wrote together
>> with Bruno Victal (mirai) and which was accepted, or the Heimdal
>> Kerberos services that are still waiting for review. [2]
>>
>> My most immediate suggestion is that I would use define-configuration
>> even when no serialization (which helps write configuration files) is
>> needed. Also, you have to think carefully about where to place the
>> G-Expressions, which can be tough to wrap your mind arround. Finally, I
>> would use "file-append" instead of string-append for some of the
>> configurable executable paths.
>>
>> Kind regards
>> Felix
>>
>> [1] 
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/linux.scm#n492
>> [2] https://issues.guix.gnu.org/67555
>
>> (define-module (services resize-fs)
>>   #:use-module (guix gexp)
>>   #:use-module (guix records)
>>   #:use-module (gnu packages bash)
>>   #:use-module (gnu packages disk) ; parted
>>   #:use-module (gnu packages linux); e2fsprogs
>>   #:use-module (guix build utils)
>>   #:use-module (guix packages)
>>   #:use-module (gnu services)
>>   #:use-module (gnu services configuration)
>>   #:use-module (gnu services shepherd)
>>   #:export (resize-fs-configuration
>> resize-fs-configuration?
>> resize-fs-configuration-parted
>> resize-fs-configuration-e2fsprogs
>> resize-fs-configuration-device
>> resize-fs-configuration-partition
>> resize-fs-configuration-end
>> resize-fs-service-type))
>>
>> (define-configuration/no-serialization resize-fs-configuration
>>   (parted
>>(file-like parted)
>>"The parted package to use.")
>>   (e2fsprogs
>>(file-like e2fsprogs)
>>"The e2fsprogs package providing the resize2fs utility.")
>>   (device
>>(string "/dev/mmcblk0") ;; #f may be preferrable here to prevent 
>> accidental resizing of wrong file-system
>>"The device containing the partition to be resized.")
>>   (partition
>>(number 2)
>>"The partition number that is to be resized.")
>>   (end
>>(string "100%")
>>"The end position of the resized partition as understood by the parted \
>>   utility (e.g. \"100%\", \"500M\" or \"16GiB\")."))
>>
>> (define (resize-fs-script config)
>>   (match-record
>>   config  (parted e2fsprogs device partition 
>> end)
>> (let ((parted-bin (file-append parted "/sbin/parted"))
>>   (resize2fs  (file-append e2fsprogs "/sbin/resize2fs"))
>>   (device+partition (string-append device "p" (number->string 
>> partition
>>   (mixed-text-file "resize-fs.sh"
>>"#!/bin/sh
>> echoerr() { printf \"$*\\n\" >&2 ; }
>>
>> cmd() {
>> " parted-bin " " device " ---pretend-input-tty <> device+partition "
>> resizepart
>> " (number->string partition) "
>> Yes
>> " end "
>> EOF
>> }
>>
>> set -o errexit
>> set -o pipefail
>>
>> echoerr hello from resize-fs script
>>
>> if cmd; then
>>   echoerr \"Resizing successful\"
>> else
>>   echoerr \"resize-script returned $?\"
>> fi
>> "
>>
>> (define (resize-fs-shepherd-service config)
>>   "Return a list of  for resize-fs-service for CONFIG"
>>   (let ((resize-script (resize-fs-script config)))
>> (shepherd-service
>>  (documentation "Resize a file-system.  Intended for Guix Systems that 
>> are booted from an image")
>>  (provision '(resize-fs))
>>  (requirement '(user-processes))
>>  (one-shot? #t)
>>  (respawn? #f)
>>  (start #~(make-forkexec-constructor
>>(list #$(file-append bash "/bin/sh") #$resize-script))
>>
>> (define resize-fs-service-type
>>   (service-type
>>(name 'resize-fs)
>>(description "Resize a partition.")
>>(extensions
>> (list
>>  (service-extension shepherd-root-service-type
>> (compose list resize-fs-shepherd-service
>>(default-value 

Re: 32-bit Python interpreter on a 64-bit system (ARM)

[Csepp]

“Wicki Gabriel (wicg)”  writes:

> Hello!
>
> Due to dynamic linkage to a library that is only provided for ARMv6 
> architecture
> (32-bit) my Python application that is developed for a 64-bit ARM architecture
> refuses to work (I load the library with ctypes). According to the internet 
> this
> could be solved by running that script with a 32-bit interpreter which - of
> course - is readily available in Guix.
> How can I declare on the package (or on the system level if necessary) that 
> this
> specific script needs the interpreter of a different architecture than the
> system/package is built for?
>
> To give you an example, the end-product will be a whole system configuration
> with packages and services and whatnot, that will be generated throught guix
> system image my-img.scm –system=aarch64-linux​ but this one package must make
> use of the armhf-linux Python ELF.
>
> Thanks for any ideas and input!

Maybe a cursed idea and completely untested, but you could wrap the expression
that evaluates to the Python package with a block that temporarily changes the
current-system or target-system parameters.  I think there is already a Guile
function for this, most likely named with-parameters.

Re: Turning off tests leads to a different store item

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Suhail  writes:
>
>> Felix Lechner via  writes:
>>
>>> On Tue, Oct 31 2023, Julien Lepiller wrote:
>>>
 You could skip tests, but that would build a different derivation
 tree, so it might affect reproducibility
>>>
>>> Those shortfalls are a consequence of our packaging habits. In an ideal
>>> world, would running a test suite ever build a different derivation?
>
> You seem to be confusing 'derivation', which is the build recipe
> description that a package "compiles" to, with the package output, the
> result of executing the derivation.
>
> While I wouldn't expect the package output to change unless tests are
> installed when disabling the test suite, the derivation changes to
> account for the different build arguments used (e.g. that #:tests? #t vs
> #:tests? #f).
>
> Running tests *may* cause the output derivation to be different.  I
> remember a bug in Python that would cause some time stamps to be
> embedded in the .pyc when running the test suite (!).  I think it's
> safer to assume that a derivation with test enabled is not the same as a
> derivation with tests disabled.
>
> There was the "Intensional Store" RFC in Nix that tried to address that
> [0]; it may be worth reading but it looks like it comes with a lot of
> caveats and complexity.
>
> [0]  https://github.com/NixOS/rfcs/pull/17

Another way would be to run tests separately, but that might be even
more complicated.
I had the idea of simply exporting the build directory into a separate
output, or maybe only that would be an output and the regular package
just takes that as an input and only runs the install step, and the
test "package" just runs the test target.

Re: How to create a package written in Go

[Csepp]

jean franco osvarcha  writes:

> Hello guix users.
>
> I wanted to package the program nwg-look to edit my theme icons and
> others through a graphical interface because I am currently using
> Tiling Window Manager.
> nwg-look is written in GO and its repository is at
> [[https://github.com/nwg-piotr/nwg-look]], theoretically its
> compilation is simple because you only have to do one:
>
> -make build
> -sudo make install

Yggdrasil is similar, I suggest using that as a template.
Sadly the Go importer doesn't handle Go module files on the CLI
interface, but you can:
a) use sed/grep/etc to get the package names from the go.mod files and
feed them into guix import go -r (xargs can help)
b) look into how the importer is implemented, it might have a go.mod
parser in there that you could use.

> and reading the Makefile I can also do this manually:
>
> build:
> go build -v -o bin/nwg-look .
>
> install
> mkdir -p $(DESTDIR)/usr/share/nwg-look
> mkdir -p $(DESTDIR)/usr/share/nwg-look/langs
> mkdir -p $(DESTDIR)/usr/bin
> mkdir -p $(DESTDIR)/usr/share/applications
> mkdir -p $(DESTDIR)/usr/share/pixmaps
> cp stuff/main.glade $(DESTDIR)/usr/share/nwg-look/
> cp langs/* $(DESTDIR)/usr/share/nwg-look/langs/
> cp stuff/nwg-look.desktop $(DESTDIR)/usr/share/applications/
> cp stuff/nwgg-look.svg $(DESTDIR)/usr/share/pixmaps/
> cp bin/nwg-look $(DESTDIR)/usr/bin
>
> Which you could do this manually but it is not suitable in SDGuix.
> Reading the documentation in the Manual and the Cookbook I could only
> rely on small sample examples to which I could come up with this
> ~nwg-look-osv.scm~ file.

Just call make DESTDIR=$output install, you don't need to replicate the
install steps.  Sudo is not necessary.

> (use-modules (guix licenses)
> (guix utils)
> (guix packages)
> (guix download)
> (guix build-system go)
> (gnu packages golang)
> (gnu packages xorg)
> (gnu packages gtk)
> (gnu packages pkg-config))
>
> (package
> (name "nwg-look-osv")
> (version "0.2.4")
> (source (origin
> (method url-fetch)
> (uri (string-append 
> "https://github.com/nwg-piotr/nwg-look/releases/download/; "v" version 
> "/nwg-look-v" version "_x86_64"
> ".tar.gz"))
> (sha256
> (base32
> "1iphamazdsvl1cp59y8sxa3iswradna6z6rmm25nmpy3nxxbkapc"
> (build-system go-build-system)
> (synopsis "This application is a part of the nwg-shell project")
> (description
> "GTK3 settings editor adapted to work in the wlroots environment")
> (home-page "https://github.com/nwg-piotr/nwg-look/;)
> (arguments
> '(#:import-path "https://github.com/nwg-piotr/nwg-look/;))
> (inputs
> (list go
> gtk+
> xcur2png
> pkg-config))
> (license gpl3+))

You need to put all the Go dependencies into the propagated-inputs
field.  Or just putting them in inputs might also be fine.
Remember, Guix packages don't have access to the network during builds,
so Go can't automatically download dependencies.

> But I can't get it to compile and install, if I do it manually in a
> ~guix shell go gtk+ xcur2png pkg-config~ and compile it on my own it
> does but I don't know how to install it and create the manifest.
> I don't have much notion in Go and packaging in Guix, but I guide from
> all the examples of others packages, I tried to do it with
> trivial-build-system but it was messing me up, if anyone has a help or
> comment I'm happy to answer.

Yes, it works in guix shell because you have network access and Go
circumvents the distro packages.

> Sorry for my english I'm using a translator DeepL

It's quite alright, although I can't make any guarantees about how well
my message will get translated.

Re: Cannot remove package from profile

[Csepp]

guix.an...@simplelogin.com writes:

> I removed the package emacs-flycheck, but it's still present in my
> Guix profile.
>
> guix package reports the package is not installed:
>
> $ guix package --list-installed='.*flycheck.*'
> $
>
> However emacs-flycheck is still in the profile's manifest:
>
> $ rg flycheck ~/.guix-profile/
> /home/fidel/.guix-profile/manifest
> 1889: ("emacs-flycheck"
> 1892: "/gnu/store/010xh6idfp7zs0hdla3fkcqi3fvgzr84-emacs-flycheck-32"
>
> And guix gc will refuse to delete the path:
>
> $ guix gc -D
> /gnu/store/010xh6idfp7zs0hdla3fkcqi3fvgzr84-emacs-flycheck-32
> finding garbage collector roots...
> guix gc: error: cannot delete path
> `/gnu/store/010xh6idfp7zs0hdla3fkcqi3fvgzr84-emacs-flycheck-32' since
> it is still alive
>
> Rightfully the profile is referring that path:
>
> $ guix gc --referrers
> /gnu/store/010xh6idfp7zs0hdla3fkcqi3fvgzr84-emacs-flycheck-32
> /gnu/store/3kqvnv23dk91f1dgfjj2hwfas5w2sbfp-emacs-subdirs
> /gnu/store/y84j3fk8kqky6wynxvk612iw38p6h8b6-profile
>
> I deleted all generations with guix gc --delete-generations, which
> removed all emacs-flycheck paths except that one. I have tried guix
> pull and upgrade, to no avail.
>
> This is with Guix in Ubuntu 22.04.
>
> $ guix --version
> guix (GNU Guix) 0024ef320eed89468369ece3df05064a2afaabd1
>
> I'm at the end of the rope, I will appreciate any support on how to
> fix this or how to find the root of the problem. Should I file a bug?
>
> Fidel Ramos
> https://fidelramos.net/

Is it a propagated-input of another package?

Re: passing installation options via manifest

[Csepp]

OLIVER HENRIOT  writes:

> Hi Guix! 
>
> Is it possible to pass a flag (e.g.
> '--without-tests=python-distributed') to guix package from a manifest,
> that is without having to specify it on the command line? I have been
> unable to work out the syntax from the various resources I have read.
>
> Thanks! 
>
> Oliver 
>
> Oliver Henriot OSUG - ISTerre 
> ISDeform / RENAg 
>
>
> 1381 rue de la piscine 
> 33 (0)4 57 42 18 62 
> [ https://www.isterre.fr/ | isterre.fr ] [ http://www.univ-grenoble-alpes.fr/ 
> ] 

https://guix.gnu.org/en/manual/devel/en/html_node/Defining-Package-Variants.html
search for: options->transformation

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

[Csepp]

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.

Re: Serializing service config to YAML

[Csepp]

TakeV  writes:

> [[PGP Signed Part:Undecided]]
> Hello there!
>
> I am attempting to create a service to run a package (specifically
> this https://github.com/superseriousbusiness/gotosocial) via shepherd.
> I have the config defined as specified in the complex configuration
> part of the manual, and I was wondering if there are any existing
> examples of serializing configurations to YAML? Right now I have
> everything passing directly into the command line, and being able to
> serialize to a config and pass that in would be much cleaner, I
> believe.
>
> Thanks!
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x640A6795ECDAAC2F.asc]...
>
> [[End of PGP Signed Part]]

Grepping through the source code didn't reveal any meaningful references
to yaml.
There is an ad-hoc config generator in gnu/services/web.scm that
generates a tailon-config.yml, but at a quick glance it doesn't seem to
be a generic converter.  But maybe it's a good starting point?
I checked guile-libyaml but it is only a parser and doesn't support
serializing Scheme into YAML as far as I can tell.

Re: Howto disable unit test runs, when building custom Python packages

[Csepp]

Timothy Washington  writes:

> I'm trying to figure out "Howto disable unit test runs, when building
> custom Python packages".
> I am trying to create a custom guix package of maurosoria/dirsearch
> .
> Using this config
> ,
> "guix build" seems to work, except that it runs the project's unit tests.
> But iIt fails when running the project's unit tests, with these logs
> .
>
> Details are in this SO post
> 
> .
> But basically, when building a custom (Github hosted) Python package, how
> can we disable unit test runs?
>
> Thanks
> Tim

Usually it should be as simple as:
(arguments '(#:tests? #f))
If it runs the tests as part of the build step, then you'll need to
either create a patch for it, use a custom source, or use substitute* to
patch it programmatically.

Re: Whta is the significance of ~/.cache/guix/profiles?

[Csepp]

Unstable Horse  writes:

> Good day, people.
>
> I'm trying to GC my system for the first time, and after running this
> command:
>
> guix gc --list-roots | sort -u
>
> Among the expected roots such as guix-profile-*-link and 
> current-guix-*-link I also see dozens of lines like this one:
>
> /home/user/.cache/guix/profiles/wjel4twocqclznutccv2mx65a5rxpb6e7lluegd
> zsksvdy3lp74a
>
> with just the hash and no name. What are they for? Is it safe to just
>
> rm -rf ~/.cache/guix/profiles
>
> once in a while, or should I leave them be?

Just guessing based on a quick check of the contents of it on my
machine:  probably serves as a cache of guix shell profiles.

Re: guix pull: computing Guix derivation takes forever

[Csepp]

akib via  writes:

> I've just installed Guix on a partition of my new HDD.  After the
> installation I logged in to my user account on a Linux console and
> executed 'guix pull'.  After that it pulled the repository and
> computed Guix derivation, but stuck while updating substitutes.  So I
> thought something is wrong and restarted the command.  Now the pull
> operation always stucks while computing Guix derivation.  There is no
> sign of activity according to top.

Is this maybe related to the CC'd bug?
There the freeze happens later, during the building phase for
packages-base, but it seems like the symtoms are the same.
Does this happen every time you try?
Could you get a backtrace with GDB?
I think the incantation was:
set logging on
thread apply all backtrace
quit

And then the output should be gdb.txt.

Re: Guix on mobile phones

[Csepp]

Felix Lechner  writes:

> Hi Csepp,
>
> On Wed, May 24, 2023 at 4:40 AM Csepp  wrote:
>>
>> Either the upgrade should fail until all substitutes become available or
>> it should do a partial upgrade.
>
> Do Guix System or Guix Home offer such an adaptive resolver? I'd love
> to have it!
>
> Kind regards
> Felix

As far as I know they do not.

Re: Guix on mobile phones

[Csepp]

"W. T. Meyer"  writes:

> Caleb Herbert  writes:
>
>> I hope there's a way to suppress compiling from source. I don't want
>> to be compiling stuff on a mobile device.
>
> I think offloading build processes to another machine defined in
> /etc/guix/machines.scm would be a more useful solution than to suppress
> building things from source.
>
> For initially provisioning a system one could probably try to make use
> of guix system image to create an initial base image of Guix for a
> respective mobile device to keep the amount of work to be done at said
> device to a minimum.
>
> - Wilko

This assumes that everyone has access to an offload machine.
Based on my experience with Guix on a netbook, there absolutely needs to
be a way to disable building things locally.  There is no point in
wasting battery life, storage space, and bandwidth on eg. trying to
build Icecat on a machine with 1GB of RAM.
Either the upgrade should fail until all substitutes become available or
it should do a partial upgrade.

Re: guix weather

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> what is the command for checking my manifest "lilypond.scm" with guix
> weather?
>
> guix weather -m lilypond.scm
> does not work
>
> guix weather -m lilypond.scm=/home/gpf/Projekte/Lilypond
> does not work either
>
> my "lilypond.scm" file is in: /home/gpf/Projekte/Lilypond/
>
>
> Kind regards
>
> Gottfried
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x61FAF349C9FB7F94.asc]...
>
> [[End of PGP Signed Part]]

If it's a valid manifest, then guix weather -m /path/to/the/manifest.scm
If that doesn't work, then either you are using the wrong path or it's
not a valid manifest file.


If it can't find the file using a relative path (ie.: one that does not
start with a slash) then you should use an absolute path, like so:
/home/gpf/Projekte/Lilypond/lilypond.scm

This:
lilypond.scm=/home/gpf/Projekte/Lilypond
is definitely not going to work.  Guix uses that syntax for package
transformations, not files.

Re: Message by a novice

[Csepp]

宋文武  writes:

>> sudo apt update
>
> guix package --upgrade
>
>> sudo apt upgrade
>
> guix pull

These are flipped.  apt update is guix pull, apt upgrade is guix
upgrade.
But you also want to periodically run guix system reconfigure to upgrade
the base system, including the kernel.

Also: some people put all their packages in the system config, don't do
that.

Also also: i686 support is not very good on Guix.  I run it on an old
netbook and it's a pretty miserable experience.  I'm sticking with it
only because I want to improve the situation of Guix on low end
machines.
If you want a distro for old limited hardware, I'd recommend Alpine, or
maybe the 32bit Arch fork.  Alpine is especially very stable in my
experience and can run on a potato and also on a big server.
But do try Guix first, maybe it will work on your hardware better than
it worked on mine.
Just keep in mind that currently Guix is:
 * memory intensive, guix pull needs at least around 1GB RAM
 * IO intensive, due to lots of disk reads, noticably slow if you don't
 use an SSD or fast HDD with lots of RAM for cache
 * storage intensive, it doesn't yet do a good job of splitting packages
 like Alpine does, and there are often accidentally referenced
 dependencies that get installed, even though they are not needed, so
 packages can take up quite a lot of space.  The smallest install I
 could manage so far was around 3.5 GB.  Assume that an upgrade increase
 space usage by a factor of at least two, possibly more as packages
 themselves grow.  It usually won't actually need that much extra space
 due to deduplication, but if you haven't upgraded in a while, there
 might be very few common store items between profile generations.  Also
 this leads to it being:
 * network intensive, but this is being worked on as part of GSoC.
 Packages that didn't really change still need to be redownloaded,
 leading to very high bandwidth usage, which is exacerbarated by the
 substitute servers being pretty slow.  The distributed substitutes
 project will hopefully change that.


Still, it's a really cool distro, and I do recommend trying it out, but
as someone who has struggled to use it on old hardware, I thought you
should know the risks.

Re: how can I use the "keep going" command when updating packages

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> thanks for your help
>
>> 'guix package --upgrade . --keep-going' to
>>> upgrade everything, or 'guix package --keep-going --upgrade' for the
>>> same effect.

I'm pretty sure --keep-going just means trying to *build* everything.
If you don't want to upgrade a profile and skip packages that don't
build, you have to explicitly use --do-not-upgrade.
So:
guix upgrade --do-not-upgrade=one-package --do-not-upgrade='(this-one|or-this)'

Keep in mind that it treats its arguments as regular expressions.

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

[Csepp]

Might also make sense to keep retrying.  When downloading fails, proceed
to a derivation that needs to be built locally, and maybe when a local
build fails, try to see if the substitute server built it in the
meantime, and just download that.

On lower end machines with slow disks, having to re-run the derivation
computations is a pretty big problem, this would eliminate one cause of
it.

Julien Lepiller  writes:

> 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: internet connection freezes

[Csepp]

"("  writes:

> Gottfried  writes:
>> Is there a command to restart the internet connection,
>> so that I don’t have to restart the laptop?
>
> Assuming you have a fairly conventional networking setup, here you go:
>
>   sudo herd restart networking
>
> If that doesn't work, maybe try this (not sure if it'll make a
> difference, though):
>
>   sudo herd restart wpa-supplicant

This might be related to the NetworkManager bug the popped up a few
weeks ago, in which case a restart won't help, but mucking around in
nmtui or nm-applet might.

Re: Why installing some packages results in two directories containing binaries in /gnu/store?

[Csepp]

Rodrigo Morales  writes:

> Table of Contents
> _
>
> 1. TL; DR
> 2. Installation of packages and resulting files
> .. 1. aria2c
> .. 2. transmission
> .. 3. htop
> 3. Question
>
>
> 1 TL; DR
> 
>
>   I have installed three packages: `transmission', `aria2c' and
>   `htop'. These three packages install a binary.. I've noticed that
>   `transmission' and `aria2c' create two directories with the same
>   folder structure in `/gnu/store'. I'm now trying to understand what's
>   the reason behind this.
>

Fairly sure this is due to grafts.

Re: guix home

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> has everybody of you installed his personal environment "guix home"
>
> or is there somebody who hasn’t?
> If so, why?
>
> I am going to shape my configuration
> and checking out what others do
> to find the best solution for my case.

I'm using it on my netbook, but not on my other two main machines.
Honestly, I would suggest not using it, it's pretty rough around the
edges currently.  It is also not documented how to uninstall it.

Re: getting loginctl to work

[Csepp]

Martin Castillo  writes:

> Hi,
>
> I have guix system installed and want `loginctl poweroff` to work. I'm
> logged in via ssh. The vm is started using
> qemu-system-x86_64   -drive media=disk,file=geex-unenc.img,format=raw
> -bios /usr/share/ovmf/x64/OVMF.fd  -m 2G   -smp 3 -nic
> user,model=virtio-net-pci,hostfwd=tcp::2223-:22 -enable-kvm
>
>
> Currently loginctl does not work:
> $ strace -o loginctl.str loginctl poweroff
> returns 1 and prints no errors.
> loginctl.str shows some partial error message. I don't know how to get
> loginctl or dbus to be more verbose and show me the error.
> /var/log/secure does not show anything regarding that error.
>
> $ loginctl list
> SESSION UID USER SEAT  TTY
>  c1 983 gdm  seat0 tty7
>
> 1 sessions listed.
>
>
> First I tried configuring %base-services plus elogind-service-type,
> but it didn't work, so I tried %desktop-services, and it still doesn't
> work, but I'm sure it should. My (approximate) configuration.scm is
> attached.
>
>
> Martin
>
> [2. text/x-scheme; configuration.scm]...
>
> [3. application/vnd.pg.format; loginctl.str]...

Could it be that something is holding an inhibit lock on shutdown?  I
think ssh can do that.  It might even be automatic??
Try running elogind-inhibit with no arguments.

Re: image converter and resizer

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
> thanks for your help.
>
>> Did you maybe type the wrong name, maybe "magik" instead of "magick"?
>
> This could be, even I tried several times and checked the name.
>
>
> I created a manifest with photoflare and imagemagick
> and both packages were installed.
>
> When I enter this profil
> I can open photoflare,
> but I can’t open imagemagick.
> bash doesn’t find it.
>
> I don’t know why.
>
> I still installed:
> julia-imagemagick
> julia-imagemagick-jll
>
> but still I can’t open it.

Those are for the Julia language, they are not what you want installed.
Use the package named "imagemagick".

If it still doesn't show up, that might be a bug.  I've ran into some
weird behavior where packages are reported as installed but aren't
visible in the profile.  But so far it hasn't happened with guix shell
profiles.

Re: image converter and resizer

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> thanks for your help.
>
> converseen is a nice and easy to use programme,
> in which you can  convert an image/picture/photo with some klicks.
>
> And also many images at once.
>
> You simply choose/load all the images, tick them,
>
> and with one other tick you convert all of them at once
> in choosing beforehand how much and to what kind you would like to
> convert them.
>
> So if it doesn’t take too much time for somebody to build it for Guix
> I would be happy.

Not a proper upstreamable package yet, but you can build it locally in a
few minutes:


converseen.scm
Description: package definition

Save it as converseen.scm, install it with:
guix package --install-from-file=converseen.scm

Re: image converter and resizer

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> I was checking on the guix website among packages,
> but the package imagemagick didn’t exist there.
>
> So how did you know that it is there?
>
> Or are there additional packages which are not mentioned there,
> but you can build them?

The package is definitely there.
https://packages.guix.gnu.org/search/?query=imagemagick

Did you maybe type the wrong name, maybe "magik" instead of "magick"?

Re: attempt to create a profile

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> I wanted to create a profile with "Musescore 3.6"
> but 3 times it failed during building process.
>
> So I had to create the profile with "Musescore 4".
>
> Now I have Musescore 4 in my main profile and in my Musescore profil.
>
> So the problem is now, how do I know when opening "Musescore" which
> one will open.
> Using the menu it opens "musescore 4" in my main profile
> Using an icon it opens "musescore 3.6" the earlier version, which I
> need as well.
>
> 1.
> if I enter "musescore" in my bash
> it doesn’t open this package.
> Why?
> If this profile is open/sourced, it should open this package.
> Other packages from my main profile like icecat, gedit, pluma open
> immeadiately.
>
> ..
> Today, without doing anything
> I did a:
> guix package -p /home/gfp/Projekte/Musescore/guix-profil
>
> and the outcome was:
>
> gfp@Tuxedo ~$ guix package -p /home/gfp/Projekte/Musescore/guix-profil
> --list-installed
> musescore 4.0 out 
> /gnu/store/7iwmb7qf56ybrl0ayzyr3w14h3azdg8p-musescore-4.0
> gfp@Tuxedo ~$
> ..
> This means I was already in this profile, or better to say, both
> profiles were open at the same time
> without sourcing it today.

It means that that profile has that package installed.
Running the above command does not activate the profile, it just
inspects it.

> This means for me that, when I tried to source this profile earlier,
> I opened it, but didn’t manage to close it.

There is no (easy) way to close a profile if it was sourced.
If you used guix shell to enter it, closing it is as easy as exiting the
shell.

> 2.
> Is it better to close it, or leave several profiles open at the same time?

There is no "better".  It depends on what you are doing.  Also I'm not
sure what you think closing a profile means.  Are you talking about
having multiple profiles opened in the same shell?  Or all the profiles
open in all the shells?
But honestly I don't think you have to worry about this if you only have
one or two profiles in addition to the default user level and system
level ones.
And if you do want to worry: the worst thing that can happen with lots
of profiles open in the same shell is that you get confused about which
package comes from which profile.

> 3.
> Is it a problem when both/more profiles are always open?

If you want them to literally always be open, just merge them with your
default profile, otherwise you are just asking for trouble.
If you mean "often" and not "always", then no, it's just that the mental
overhead increases.

> 4.
> what does it mean for my bash/MATE terminal?
> Shouldn’t I be able to open "musescore" in both profiles?
> Is so, what do I have to enter in the bash to open this or that "musescore"

The terminal emulator does not matter, only the bash process it runs
matters.
If you run the musescore command, its location is looked up in the PATH
environment variable.  The profile that was loaded last "wins".  That's
why I recommend thinking of profiles not so much as being opened and
closed, but as being stacked on top of each other.  Whatever is at the
top of the stack is what bash (and other programs) look at first.
If multiple profiles in your "stack" provide the same command, then the
easiest way to refer to a specific one is by using its path in the
profile:
~/.guix-profile/bin/musescore: this is the one in your default profile
/home/gfp/Projekte/Musescore/guix-profil/bin/musescore: this is the one
in your custom profile

ps.: I'd appreciate if you kept the threads in bottom-reply order,
because it's much harder to refer back to previous messages if you
don't.

Re: attempt to create a profile

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> thanks for your help.
>
> I tried to open this profile,
>
> by
>
>> gfp@Tuxedo ~$  source /home/gfp/Projekte/Musescore/guix-profil/etc/profile
>> 
> or
>
>> gfp@Tuxedo ~$ guix shell -p /home/gfp/Projekte/Musescore/guix-profil
>
> but it didn’t happen anything.

It's normal, it normally doesn't show anything.

> How can I know, that I am now in this profile?
>
> Shouldn’t bash show me something?

If you directly source the etc/profile script, GUIX_PROFILE does not get
defined, so bash doesn't know you loaded a profile.
Which is actually "correct", since sourcing it is not the same as
entering it using guix shell/environment.  Sourcing directly modifies
the running process's environment variables, so exiting bash would not
get you back to a default environment, it would most likely just close
the terminal emulator.  But if you are in a genuine `guix shell`,
running the exit builtin command gets you back to the process where guix
shell was run from.

If you used guix shell then I'm pretty sure it should show someting.
Running `guix shell -p ~/.guix-profile -- bash` does show the [env]
prompt for me, so either your bash is configured differently or your
login shell is not bash.  For example, my login shell is Zsh, which
doesn't have the same customization, I had to add a similar prompt hack
myself.

> And when I opened the package "musescore" it opened the package
> musescore in my other profile.
> So I guess I am not in this profile.

Did you open it from bash or from a desktop app launcher?
The environment variables are only changed locally in the bash process
you ran source from, or the bash process that guix shell spawned.
If you did run it from there and it launched the wrong one, then could
you post the output of

guix package -p /home/gfp/Projekte/Musescore/guix-profil --list-installed

?

Maybe you accidentally mixed up which version is installed in which
profile, it happens.

Re: attempt to create a profile

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Zimoun,
>
>>  What does it mean in my case?
>>> It means that you can activate the profile containing the Musescore
>>> package using
>>>  source /home/gfp/Projekte/Musescore/etc/profile
>>> or either
>>>  guix shell -p /home/gfp/Projekte/Musescore
>>> Does it make sense?
>
> No
>
>
> This was the output:
>
> gfp@Tuxedo ~$ export LC_ALL=C
>
> gfp@Tuxedo ~$  source /home/gfp/Projekte/Musescore/etc/profile
> -bash: /home/gfp/Projekte/Musescore/etc/profile: No such file or directory

This should have been:
gfp@Tuxedo ~$  source /home/gfp/Projekte/Musescore/guix-profil/etc/profile

Zimoun left out the guix-profil part.

> gfp@Tuxedo ~$ guix shell -p /home/gfp/Projekte/Musescore

Again, this should be:
gfp@Tuxedo ~$ guix shell -p /home/gfp/Projekte/Musescore/guix-profil

> What does: [env] mean?

It means you are in a guix shell.  In the olden this was called guix
environment, which is where "env" comes from.  Guix has some Bash
customizations built in that make it detect if GUIX_ENVIRONMENT is set
and modifies the shell prompt.

Re: creating a profile with Musescore 4

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> I did a
>
> guix package -i musescore -p projects/musescore.guix-profile
>
> and it created a profile
> ..
> then I loaded it
>
> export GUIX_PROFILE=/projects/musescore
>
> .
>   but:
>
>  source "${GUIX_PROFILE}/etc/profile"
>
> did not work
>
> "no directory was found"
> .
>
> How can I source my new profile?
>
> Because I couldn’t enter in it yet.
>
>
> Kind regards
>
> Gottfried
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x61FAF349C9FB7F94.asc]...
>
> [[End of PGP Signed Part]]

Here is the error:
> export GUIX_PROFILE=/projects/musescore
/projects/musescore does not exist.

What you probably wanted to do was
export GUIX_PROFILE=$PWD/projects/musescore

My preference is to name all profiles ".guix-profile" and only have at
most one profile per directory.
This way I can load any of them by cd-ing to the directory and run
GUIX_PROFILE="$PWD/.guix-profile" source ".guix-profile/etc/profile"

Re: libgit2 shallow clone (was Re: Packaging Grafana)

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On dim., 15 janv. 2023 at 12:12, Csepp  wrote:
>
>> Honestly, I think our Go importer needs to be rewritten to just use Go's
>> libraries instead of trying to replicate all functionality in Guile.  It
>> does a lot of... let's say sub-optimal things currently, like cloning
>> full git repos, when Go is smart enough to only clone what it needs for
>> dependency resolution.
>
> About cloning, the core of the issue is not Guile but libgit2.  Guix
> relies on guile-git which is just libgit2.  And sadly, libgit2 does not
> support shallow clone or depth fetch option.  See libgit2 issue#3058.
>
> If I read correctly, Go relies on plain Git, instead.
>
> Therefore, sadly we cannot do better than full Git repository clone.
>
> It would be difficult switch from libgit2 to plain Git; as discussed in
> this thread [2].
>
>
> 1: <https://github.com/libgit2/libgit2/issues/3058>
> 2: <https://yhetil.org/guix/87cz9fpw4x@gmail.com>
>
> Cheers,
> simon

It would be worth it for importers.  If I remember correctly, the
reasoning for writing importers as Guile modules is reducing Guix's
closure size, but that's nonsense when it comes to importing packages,
because 99.% of the time you are going to be using the language's
tooling anyways, because you will want to actually compile those
imported packages.
The Rust importer already loads guile-json or whatever at runtime, there
is nothing wrong with having a similar runtime-only dependency on the Go
compiler.

Re: guix shell set user groups to access security token

[Csepp]

Alexander Asteroth  writes:

> Dear all,
>
> I'm trying to get my security token software (sealone) to work under
> guix SD. The software is unfortunately not available in source and seems
> to expect a FSH filesystem. I therefore tried to run it in guix shell. A
> first trial was:
>
> guix shell -CFD ungoogled-chromium gcc:lib --expose=/dev
>
> in this environment I can execute the software and the tokes get's
> connected but reports some error condition and is not usable. It might
> have to do with the user not beeing in group cdrom which usually is
> necessary to access /dev/sg0.
>
> Any idea how to set the groups the user is member of in guix shell?
> Or any other idea how I could get such software to work under guix?
>
> Cheers,
> Alex

Bit of an ugly hack but what I usually do is chown devices I'm working
with to myself.
Haven't tried that in a guix container but in theory it should work.

Re: Packaging Grafana

[Csepp]

phodina via  writes:

> Hi Guix,
>
> Grafana [1] is an awesome tool to visualize and analyze various kind of data.
>
> It's FOSS project under AGPL3+.
>
> The small drawback is it's written in Go and Typescript.
>
> As far as I understand for Go there's the file go.mod​ describing the
> dependencies [2] and for Typescript there's file package.json​.[3]
>
> I've tried to use the guix import​ command, however, it fails to add even the 
> Go dependencies.
>
> Also since the dependency chain is obviously huge how should the porting be 
> done?
>
> Any experience porting some similar package with dos and don'ts?
>
> The short term solution at least in my case is to use the prebuilt
> static binary which works after running patchelf on it. That's also
> how Nix package looks like. [4]
>
> Here's what the importer returns:
>
> $ guix import go -r github.com/grafana/grafana
> (define-public go-github-com-grafana-grafana
> (package
> (name "go-github-com-grafana-grafana")
> (version "5.4.5+incompatible")
> (source (origin
> (method git-fetch)
> (uri (git-reference
> (url "https://github.com/grafana/grafana;)
> (commit (go-version->git-ref version
> (file-name (git-file-name name version))
> (sha256
> (base32
> "1rgcy21amrh6syf21p2gpdbwzc2mcjw6wsbhwwr7v40rdx12rmcm"
> (build-system go-build-system)
> (arguments
> '(#:import-path "github.com/grafana/grafana"))
> (home-page "https://github.com/grafana/grafana;)
> (synopsis "")
> (description
> "@@url{https://grafana.com,Website} | 
> @@url{https://twitter.com/grafana,Twitter}
> | @@url{https://community.grafana.com,Community & Forum}") (license 
> license:asl2.0)))
>
> 1 https://grafana.com/
> 2 https://github.com/grafana/grafana/blob/main/go.mod
> 3 https://github.com/grafana/grafana/blob/main/package.json
> 4 
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/monitoring/grafana.nix
>
> 
> Petr

Honestly, I think our Go importer needs to be rewritten to just use Go's
libraries instead of trying to replicate all functionality in Guile.  It
does a lot of... let's say sub-optimal things currently, like cloning
full git repos, when Go is smart enough to only clone what it needs for
dependency resolution.

Re: attempt to create a profile

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Simon,
>
>
>>  ...and also at start up that I can choose which profile to open?
>>> What do you mean by “choose”?
>>> 
>
>
> I meant when I am starting Guix, I can choose to use MATE desktop or
> Enlightenment Desktop.
> If there is also the option to choose a certain profile, in case I
> have more profils.

There is not, you don't have to worry.  Desktop environments are
unrelated to profiles.

Re: Strange error when adding module gnu/packages/engineering

[Csepp]

Reza Housseini  writes:

> [[PGP Signed Part:Undecided]]
> Hello Guixers
>
> I'm in the process of adding a package to guix. When starting the
> build with ./pre-inst-env guix build openfoam-org I get the error:
>
> error: tcc: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: googletest: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: bzip2: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: binutils: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: gcc-4.9: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: gnutls: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: xz: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: gnu-make: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: binutils: unbound variable
> hint: Did you forget a `use-modules' form?
>
> error: ffmpeg-5: unbound variable
> hint: Did you forget a `use-modules' form?
>
> Throw to key `unbound-variable' with args `("resolve-interface" "no
> binding `~A' in module ~A" (shared-mime-info (gnu packages gnome))
> #f)'.
> Backtrace:
> In guix/store.scm:
>661:37 19 (thunk)
>1300:8 18 (call-with-build-handler # …)
> In guix/scripts/build.scm:
> 587:2 17 (_)
> In srfi/srfi-1.scm:
>673:15 16 (append-map _ _ . _)
>586:17 15 (map1 ((argument . "openfoam-org") (build-mode . 0) # …))
> In guix/scripts/build.scm:
>607:31 14 (_ _)
> In gnu/packages.scm:
> 479:2 13 (%find-package "openfoam-org" "openfoam-org" #f)
> 364:6 12 (find-best-packages-by-name _ _)
>294:56 11 (_ "openfoam-org" _)
> In unknown file:
>   10 (force #)
> In gnu/packages.scm:
>241:33  9 (fold-packages # …)
> In guix/discovery.scm:
>159:11  8 (all-modules _ #:warn _)
> In srfi/srfi-1.scm:
>460:18  7 (fold # …)
> In guix/discovery.scm:
>149:19  6 (_ _ ())
> 116:5  5 (scheme-modules _ _ #:warn _)
> In srfi/srfi-1.scm:
>691:23  4 (filter-map # . #)
> In guix/discovery.scm:
>124:24  3 (_ . _)
> In guix/ui.scm:
> 321:2  2 (report-unbound-variable-error _ #:frame _)
> 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:
> Throw to key `match-error' with args `("match" "no matching pattern"
> (unbound-variable "resolve-interface" "no binding `~A' in module ~A"
> (shared-mime-info (gnu packages gnome)) #f))'.
>
> when removing the module gnu/packages/engineering.scm from the
> use-modules list the error disappears but I can't obviously not build
> the package without this dependency (cgns).
>
> The package builds fine otherwise (inside another channel).
>
> What I am doing wrong here?
>
> Cheers,
> Reza

Just to rule out the obvious things:
did you perform a clean rebuild?
ie.: make clean, or git clean -fxd, the bootstrap, configure, make

Also could you send the patch containing your additions?

My guess is that the Guix feature that auto-suggests what module to
import when there is an unbound variable error is matching the list
caught from the exception but its patterns don't cover it.  Maybe it has
an extra element or something?

Also, getting the commit from git that yours builds on might be helpful.

Re: installing of two versions of package Musescore

[Csepp]

Wojtek Kosior  writes:

> [[PGP Signed Part:Undecided]]
> Hi Gottfried,
>
>> 3.  I want to have "Musescore3.6.2" as the name of this profile, so that 
>> I quickly now what is in there. Is that possible? If not how this 
>> profile is specified to see the difference to my main profile?
>> 
>> 4.  what should I write in  "path/to/profile"
>> because AFAIU the profile will be in
>> /etc/
>> 
>> like this?:
>> 
>> profileMusescore3.6.2
>> 
>> /etc/profileMusescore3.6.2
>> 
>> "guix package --profileMusescore3.6.2=/etc/profileMusescore3.6.2"
>
> Good news for you — the profile does not need to reside under `/etc/`.
> In fact, it would be abnormal to have a non-root user's profile there
> since `/etc/` is usually only writeable by root.
>
> User's profiles usually live somewhere under the user's HOME directory.
> I'd personally choose a path like `~/.guix-profiles/musescore-3.6.2`.
> Someone else would perhaps use `~/.config/guix/Musescore3.6.2`. Just
> pick what you like the most.

I usually put them in project specific directories, like so:
"$HOME/Graphics/.guix-profile"
"$HOME/Projects/Advent of Code/2022/.guix-profile"
and so on...

I find that it's much easier to use than if they were centralized under
one directory, because this way they are close to the project they
correspond to.

Also, a useful command to know:
guix package --list-profiles

Re: Help with DBus Tests Failing for Python Package

[Csepp]

Jaft  writes:

> So I tried a different tactic and, noticing the error said the issue was 
> ~dbus-session~ didn't exist, did this, instead:
>
>> (arguments (list #:phases #~(modify-phases %standard-phases
>>   (add-before 'check 'start-xserver
>> (lambda _
>>   ;; Tests require a running dbus-daemon.
>>   (system "dbus-daemon &")
>>   ;; For missing '/etc/machine-id'.
>>   (setenv "DBUS_FATAL_WARNINGS" "0"))
>> (inputs    (list python python-pygobject))
>> (native-inputs (list xorg-server-for-tests))
>
> This works much better and the 232 tests get run; most, even pass…except 4. 
> The output is thus:
>
>> test_get_object_path (tests.test_proxy.DBusProxyTestCase)
>> Test get_object_path. ... ok
>>
>> ==
>> FAIL: test_async_calls (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus async calls with fds.
>> --
>> Traceback (most recent call last):
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line 
>>420, in test_async_calls
>> self._run_test()
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line 
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _call_hello_async has finished with 1
>>
>> ==
>> FAIL: test_properties (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus properties with fds.
>> --
>> Traceback (most recent call last):
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line 
>>457, in test_properties
>> self._run_test()
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line 
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _set_pipes has finished with 1
>>
>> ==
>> FAIL: test_signals (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus signals with fds.
>> --
>> Traceback (most recent call last):
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line 
>>481, in test_signals
>> self._run_test()
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line 
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _trigger_signal has finished with 1
>>
>> ==
>> FAIL: test_sync_calls (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus sync calls with fds.
>> --
>> Traceback (most recent call last):
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line 
>>398, in test_sync_calls
>> self._run_test()
>>   File 
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line 
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _call_hello_sync has finished with 1
>>
>> --
>> Ran 232 tests in 681.414s
>>
>> FAILED (failures=4)
>> Test failed: 
>> error: Test failed: > failures=4>
>> error: in phase 'check': uncaught exception:
>> %exception #< program: "python" arguments: ("-c"
>> "import setuptools, tokenize;__file__='setup.py';f=getattr(tokenize,
>> 'open', open)(__file__);code=f.read().replace('\r\n',
>> '\n');f.close();exec(compile(code, __file__, 'exec'))" "test")
>> exit-status: 1 term-signal: #f stop-signal: #f>
>
> It doesn't look like enough to clearly tell /why/ things failed (and
> looking through the source of the particular failing tests isn't much
> clearer, for me, unfortunately) but maybe someone's run across a
> similar experience, before, that might indicate something to try.

Just a guess but maybe you should wrap the check phase in dbus-run-session.

Re: Drafting a Guix blog post on the FHS container

[Csepp]

Jim Newsome  writes:

> Sorry for (presumably) breaking threading; I came across this online
> and don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:
>
>
> ```
> guix shell \
>   --container \
>   --network \
>   --emulate-fhs \
>   --preserve='^DISPLAY$'
>   --share=/run/user/$(id -u)/gdm \
>   openssl@1 \
>   libevent \
>   pciutils \
>   dbus-glib \
>   bash \
>   libgccjit \
>   libcxx \
>   gtk+ \
>   coreutils \
>   grep \
>   sed \
>   file \
>   alsa-lib \
>   -- \
>   ./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to
> get access to the display. I'm not sure the second parameter is
> universally correct; I reverse-engineered it via roughly `ps aux |
> grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.
>
> -Jim
>
> [Tor Browser Bundle]: https://www.torproject.org/download/

Any idea how to use this for running appimages?  Or anything that
requires FUSE in general?

Re: installing of two versions of package Musescore

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Csepp
>
> thanks for your answer
>
>> I'd leave 3.6.2 in my default profile.
>
> Does this mean, every time I am doing a
>
> guix pull
>
> and
>
> guix package --upgrade
>
> I have to add:
>
>  --do-not-upgrade musescore
>
> so that musescore stays at the version 3.6.2 ?
>
> (If I forget to add this, than it will upgrade to version 3.4
> and I can than only switch back one generation and do the
> guix package --upgrade --do-not-upgrade musescore
> again)
> Is it like this?
>
> Gottfried

Well, it will also not upgrade its dependencies in that case.  If you
want to use an old version forever, sure, you can use --do-not-upgrade,
but you could also pin the source to an old version.
For that you would use the --with-branch=musescore=v3.6.2
transformation... I think.
I recommend reading the info page on defining package variants.

Re: installing of two versions of package Musescore

[Csepp]

Gottfried  writes:
> But which version?
> Should I put the version 3.6.2 in my new profile to keep it,
I'd leave 3.6.2 in my default profile.

> 
>
> When using "Guix shell", AFAIU, I would have to do it on a daily basis,
> because every time I switch off my laptop,
> its lost. Is it like that?

No, it is only lost when `guix gc` is run.

Re: installing of two versions of package Musescore

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Csepp,
>
> this was anyhow my question.
>
>>> In general you do not need to install packages under development in your
>>>> main profile.  It would be better to either put it in a separate profile
>>>> or use a temporary shell every time and put the package definition in a
>>>> manifest or script.
>
>
> Until now I installed everything in my main profile
>
> 1.  I don't know yet how to create a profile/manifest.
>
> I was reading the cookbook and the manual already several times about
> that, but it seems to me difficult.

A simple way to do it is:
```
guix shell --export-manifest python python-sympy | tee guix.scm
```

It even works with transforms, so let's say you were working on getting
the newest version of Cutter running:
```
guix shell --export-manifest --with-latest=cutter cutter | tee guix.scm
```

> 2.  If I create an other profile through a manifest
> what is the benefit of it in my case?

You can load the profile separately and it should be overlaid on top of
your normal profile, shadowing the Musescore binary from it.
The advantage of a persistent profile (as opposed to a manifest on its
own) is that it will survive garbage collection, so you won't be
building the same package again and again.

Another benefit is that you can upgrade them separately.  This is why I
have TeXlive installed in a separate profile, because it is a several
gigabyte download, so I'd rather not have to wait for it every time I
upgrade my default profile.

> 3.  I would have to put all my 60 packages there (how?) and if I
> download an other package, would I have to create the manifest again
> and again?

No.  Profiles are not chroots, or containers, or VMs, or anything like
that.  Profiles can be composed.  In fact, if you are using Guix System,
you are already using two profiles stacked on top of each other: the
system profile at /run/current-system and your default user profile at
$HOME/.guix-profile.
Packages installed in your system profile do not have to be installed in
your user profile.  You *can* install them in it, but it's not
necessary.
Similarly, if you install a different version of Musescore in a separate
profile, that only has to contain Musescore and nothing else.
I have a graphics profile and it only contains a few programs, like
Blender, Inkscape, etc.  But for example it does not have Emacs in it,
because Emacs is loaded by my default user profile at
$HOME/.guix-profile.

> 4.  And if I want to update the packages, lets say every second week,
> then I would have to create the manifest again every second week.

No, the manifest file stays the same.  It's just a list of packages.
To upgrade a persistent profile you can just use the usual method:
```
guix package --upgrade --profile=/path/to/profile
```

If you don't want to make a persistent profile, you can instead do:
```
guix shell --manifest=guix.scm
```

> 5.  Would I then have to uninstall all my installed packages in the
> main profile, in order not to have it twice?

No, see above.
Also having multiple version of a package installed is not a problem on
Guix, only if they are in the same profile.  You can have as many
conflicting version as you want, they won't concflict if they are not in
the same profile.

> 6.  How could I then use my manifest? Which commands would I have to
> use to open it and to use my packages?

For a temporary shell (see above on how to create guix.scm):
```
guix shell --manifest=guix.scm
```

For a persistent profile:
```
# first create the profile
guix package --profile=/path/to/profile
# then load it
export GUIX_PROFILE=/path/to/profile
source "${GUIX_PROFILE}/etc/profile"
# alternatively:
source /path/to/profile/etc/profile
# there are some subtle differences between the two
```

Caveat for persistent profiles:
if you modify the profile (for example by installing a new package in
it) then you might have to load it again.
More precisely: if the list of environment variables in the profile
changes, you have to reload it.  Otherwise if the GUIX_PROFILE
environment variable was defined correctly when you first loaded it,
then you don't have to reload it.

Re: installing of two versions of package Musescore

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Guix,
>
> I tried to download the new version of Musescore, Version 4
> Even thought 100 % available, it wanted to build it locally, but
> failed. (takes 75 minutes)
> I tried it again, it failed.
> next day I tried it again, it failed.
>
> I checked the Musescore Forum etc
> and there are big problems with the new Musescore 4 in Linux.
> Several people complained.
>
> How can I now keep the Version 3.6.2
> and additionally install the new version 4.0 in future,
> so that my current version 3.6.2 does not get lost.
>
> The new version 4.0 needs improvements.
>
>
> Kind regards
>
> Gottfried
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x61FAF349C9FB7F94.asc]...
>
> [[End of PGP Signed Part]]

You could pass --do-not-upgrade=musescore if you want to keep it at the
same version in your main profile.
In general you do not need to install packages under development in your
main profile.  It would be better to either put it in a separate profile
or use a temporary shell every time and put the package definition in a
manifest or script.

Re: Trying to build lilypond but guix downloads firefox?

[Csepp]

jgart  writes:

> Hi,
>
> Is there a reason why I would see this in stdout when I run ./pre-inst-env 
> guix build lilypond?
>
> substituting 
> /gnu/store/n6w5qizdwx2kpas061dcn5gdgvaqlwr1-firefox-91.13.0esr.source.tar.xz...
>
> Just trying to understand why guix would try to download firefox when I try 
> to build lilypond...
>
> all best,
>
> jgart

Did you by any chance paste the wrong sha256 when upgrading lilypond?
Firefox is not even officially packaged, so that's the only thing I can
think of.

Re: Compiling vterm: cc: command not found

[Csepp]

Chris Keschnat via  writes:

> Hello, after todays ~guix pull~, I cannot compile vterm anymore. I do not
> seem to have ~cc~ installed (anymore?). Am I missing a package? I have
> ~make~, ~cmake~, ~gcc~, and ~gcc-toolchain~ installed and didn't change
> anything on that front.
>
>
> Steps to reproduce (following the "Manual installation" from the docs[1]):
>
> #+begin_src sh
>
>   git clone https://github.com/akermu/emacs-libvterm.git
>   cd emacs-libvterm
>   mkdir -p build
>   cd build
>   cmake ..
>   make
>
> #+end_src
>
>
> Results in:
>
> #+begin_src sh
>
>   [  8%] Performing update step for 'libvterm'
>   [ 16%] No patch step for 'libvterm'
>   [ 25%] No configure step for 'libvterm'
>   [ 33%] Performing build step for 'libvterm'
>   CC src/encoding.c
>   /home/ck/.guix-profile/bin/libtool: line 1933: cc: command not found
>   make[3]: *** [Makefile:63: src/encoding.lo] Error 1
>   make[2]: *** [CMakeFiles/libvterm.dir/build.make:86: 
> libvterm-prefix/src/libvterm-stamp/libvterm-build] Error 2
>   make[1]: *** [CMakeFiles/Makefile2:112: CMakeFiles/libvterm.dir/all] Error 2
>   make: *** [Makefile:91: all] Error 2
>
> #+end_src
>
> [1] https://github.com/akermu/emacs-libvterm
>
>
> Thanks
>
> Chris

Without having looked at the package, what I would recommend and what I
usually try in a case when something tries to use cc is set the CC
environment variable or configure flag.  Its value should ideally be
#$(cc-for-target).
So you would have something like in modify-phases:
(add-before 'configure 'set-cc
(lambda _ (setenv "CC" #$(cc-for-target

Re: fatal empty ident name (for <>) not allowed

[Csepp]

jgart  writes:

> Does anyone happen to know what this error is about?
>
> Applying: * gnu/packages/lisp.scm (carp): New variable.
> fatal: empty ident name (for <>) not allowed
>
> It happens when I try to apply v8 of this patch:
>
> https://issues.guix.gnu.org/58898#9

The <> makes me think of the '(ice-9 cut) module but I haven't seen this
error.

Re: can't update - mkdir: file already exists

[Csepp]

t...@envs.net writes:

> hi, i'm trying to update and i'm getting this error:
>
> guix substitute: error: mkdir: Файл вже існує
> substitution of 
> /gnu/store/61aikkrkxcm07ajrzgl6531lvacb3b5h-guix-packages-base failed
> guix pull: error: corrupt input while restoring archive from # 7f121d0953f0>
>
> файл вже існує = file already exists

Oh I think I've seen this before.  Did substitution from ci.guix.gnu.org
fail halfway through the download and it tried bordeaux?

Re: committer.scm

[Csepp]

jgart  writes:

> On Tue, 01 Nov 2022 07:57:28 +0100 Julien Lepiller  wrote:
>> Try calling it with pre-inst-env.
>
> Ohhh, yes that was it. I stopped calling it with pre-inst-env for some reason 
> ;()
>
> THNX
>
> Now I just need to see how I am going to sort these 150+ crates in an 
> automated fashion...

If you have some graph theory and Guix know-how you might be able to get
my commit sorter script working.  Currently it's broken, as in it does
not sort commits in the way they should be sorted, but it has a lot of
useful bits already.
(use-modules
 (gnu installer utils)
 (graph topological-sort)
 (guix build utils)
 (ice-9 exceptions)
 (ice-9 hash-table)
 (ice-9 match)
 (ice-9 popen)
 (ice-9 rdelim)
 (oop goops)
 (srfi srfi-1)
 (srfi srfi-13)
 (srfi srfi-2)
 (srfi srfi-26)
 (gnu packages)
 (guix packages))

(with-exception-handler
exception-irritants
  (lambda ()
(package-propagated-inputs
 (module-ref
  (reload-module (resolve-module '(gnu packages ocaml-mirage) #:ensure #f))
  'ocaml-ppx-cstruct)))
  #:unwind? #t
  #:unwind-for-type )

(define from-commit "raingloom/mirageos-rebase")
(define to-commit "after-dune")

;; The set (sorted list) of variables (symbols) we care about.
(define variables-of-interest
  ;; starts out as #f to catch errors
  (make-parameter #f))

(define variable->commit-mapping
 (make-parameter #f))

(define dependency-digraph
  (make-parameter #f))

(define commit->log-index
  (make-parameter #f))

(define (with-input-from-make thunk)
  (lambda _
(with-input-from-port
(open-pipe* OPEN_READ "make")
  thunk)))

(define (set-current-commit! commit)
  (invoke "git" "checkout" commit))

(define (missing-variable-on-line line)
  (and-let*
  ((words (string-split line #\space))
   (prefixed-var (find-tail (cut string=? "variable" <>) words))
   ;; so cadr doesn't error
   (prefixed-var-ok? (equal? 2 (length prefixed-var)))
   (var-quoted (cadr prefixed-var))
   (var-quoted-ok? (and (string-suffix? "'" var-quoted)
(string-prefix? "`" var-quoted)))
   (var (string-drop-right (string-drop var-quoted 1) 1)))
var))

(define (with-input-from-command thunk command)
  ;; TODO this is ugly, but run-external-command-with-handler does not return
  ;; the value that the handler returns, only the command's exit status
  (define ret #f)
  (define (handler port)
(set! ret (with-input-from-port port thunk)))
  (run-external-command-with-handler handler command)
  ret)

(define (current-commit-missing-definitions)
  (define (go)
(let ((line (read-line)))
  (if (eof-object? line)
  '()
  (let ((variable (missing-variable-on-line line)))
(if variable
(cons variable (go))
(go))
  (map string->symbol
   (with-input-from-command go '("make"

(define (name->commit name)
   (define (go)
 (define hash (read-line))
 (unless (eof-object? (read-line))
   (error "unexpected additional output"))
 hash)
   (with-input-from-command
go
`("git" "show" "--format=%H" "--quiet" ,name)))

(define (current-commit)
  (name->commit "HEAD"))

(define (commits-since commit-name)
  (define commit (name->commit commit-name))
  (define (go)
(let ((line (read-line)))
  (cond
   ((eof-object? line) (error "ancestor commit does not exist"))
   ((string=? line commit) '())
   (else (cons line (go))
  (reverse (with-input-from-command go '("git" "log" "--format=%H"

(define (files-changed commit)
  (cdr (with-input-from-command
read-lines
`("git" "show" "--oneline" "--name-only" ,commit

(define (module-file? file)
  (string-suffix? ".scm" file))

(define (path->module path)
  "Assumes PATH is a valid Scheme file."
  (let* ((components-rev (reverse (string-split path #\/)))
 (base (car components-rev))
 (last-component (string-drop-right base (string-length ".scm"
(map string->symbol (reverse (cons last-component (cdr components-rev))

(define (modules-changed commit)
  (map path->module
   (filter module-file?
   (files-changed commit

(define (touch-changed-files! commit)
  (apply invoke (cons "touch" (files-changed commit

(define (commits+missing-definitions commits)
  (map (lambda (commit)
 (set-current-commit! commit)
 (touch-changed-files! commit)
 (cons commit (current-commit-missing-definitions)))
   commits))

(define (set-insert set x)
  "Insert element X into the sorted list SET."
  (match set
(() (list x))
((a) (if (< a x)
 (list a x)
 (list x a)))
((a b . rest)
 (cond
  ((and (< a x) (< x b)) (cons* a x b rest))
  ((equal? a x) set)
  ((< x a) (cons* x a (cdr set)))
  (else (cons a (set-insert (cdr set) x)))

(define (add-dependent! dependency-graph commit dependent)
  (assoc-set! dependency-graph commit
  (set-insert 

Re: make clean-go breaks my build environment

[Csepp]

"Philip McGrath"  writes:

> On Wed, Nov 2, 2022, at 3:48 AM, jgart wrote:
>> On Wed, 02 Nov 2022 08:20:09 +0100 Ricardo Wurmus  wrote:
>>> 
>>> jgart  writes:
>>> 
>>> > after running `make clean-go` the build gets consistently stuck on
>>> > this message:
>>> >
>>> > WARNING: Use of `load' in declarative module (guix ui).  Add 
>>> > #:declarative? #f to your define-module invocation.
>>> > WARNING: (guix build python-build-system): imported module (guix build 
>>> > utils) overrides core binding `delete'
>>> 
>>> These are warnings, not errors.  What do you mean by “gets […] stuck”?
>>
>> I mean that instead of getting a quick build now that the guile object
>> files are gone it just gets stuck indefinitely at that warning.
>
> Try `make clean-go && make && echo hooray`. My guess is that your
> build is finishing successfully (`make` exits with status 0) and the
> last output just happens to be those warning messages.
>
> If by “gets […] stuck” you mean that `make` never exits, that would indeed be 
> a problem.
>
> This is legitimately confusing, though! A good reason to figure out how not 
> to trigger those warnings.

I regularly get a locked up make on my i686 machine when trying to build
from source, so this does not seem that unlikely to me.  What seems to
happen in my case is there are two make subprocesses, both taking little
CPU time and both with a D status in htop.  I've basically given up
trying to build Guix from source on i686 because of bugs like this.

Re: How to use/install rust nightly on guix ?

[Csepp]

Mohamed Amine LEGHERABA  writes:

> Yes Csepp I'm interested by your tutoriel on how to create a chroot
> Arch on Guix, It will allow me to run several "exotic"
> languages/programs on my computer (including rust nigthly).
>
> Thanks,
> Mohamed Amine LEGHERABA

Here is the current version.  => https://bugs.archlinux.org/task/46169


Download bootstrap chroot
=> 
http://quantum-mirror.hu/mirrors/pub/archlinux/iso/2021.11.01/archlinux-bootstrap-2021.11.01-x86_64.tar.gz
Extract it somewhere.

Final boot script.
Important!!! Run with `sudo -E`. The "-E" is important. Or just hardcode the 
path to your home directory.
```
#!/bin/sh
set -ex

cd "$(dirname "$0")"
mount --bind root.x86_64 root.x86_64
mount -o bind "$HOME" root.x86_64/home/user/host-home

# delete these two if you are not using Guix, or modify them if you are using 
Nix
mount -o bind,ro /gnu/store root.x86_64/gnu/store
mount -o bind,ro /var/guix root.x86_64/var/guix

bash root.x86_64/bin/arch-chroot root.x86_64 /bin/env -i bash -l

# again, delete them
umount -l root.x86_64/var/guix
umount -l root.x86_64/gnu/store

umount -l root.x86_64/home/user/host-home
umount -l root.x86_64
```

First time, on the host system:
```
# write down this number, it will be important
echo $UID

sudo mount --bind root.x86_64 root.x86_64
sudo bash root.x86_64/bin/arch-chroot root.x86_64 /bin/env -i bash -l
```

First time setup inside guest:
```
# enable some mirrors
sed -i 's/^#\(.*\.hu.*\)/\1/' /etc/pacman.d/mirrorlist
# set up timezone
ln -s /usr/share/zoneinfo/Europe/Budapest /etc/localtime
# initalize package manager
pacman-key --init
pacman-key --populate archlinux
# install development packages
pacman -Syu --needed git base-devel
# optional if you are using Guix, otherwise not really:
pacman -S base
# (if you are using Guix or Nix, you can just mount their store and use their 
packages)
# create store mount point
mkdir -p /gnu/store
mkdir -p /var/guix
# create a non-root user. the UID thing is important, it lets you share your 
host's home directory in the guest.
useradd -m -u $UID_OF_HOST_USER user
# optional: ignore all security precautions and enable passwordless sudo for 
this user?
# maybe don't do this?
echo 'user ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
# alternatively, add a password
usermod -aG wheel user
passwd user
echo "%wheel ALL=(ALL:ALL) ALL" >> /etc/sudoers
# change to a login shell of the new user
su -l user
# create host home mount
mkdir ~/host-home
# install yay
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

# now you can install anything, like, say, Infer.
yay -Sy infer

# link to host guix. ignore if your host system isn't Guix.
(cd ~/.config; ln -s ../host-home/.config/guix ~/.config/guix)
ln -s host-home/.guix-profile ~/.guix-profile/
```

I wrote it in a way that is hopefully usable to others, but it's still
not exactly a polished how-to guide, so if you have any questions, feel
free to ask them.
There are a bunch of gotchas that I probably forgot to mention, like how
having Guix's environment variables active can mess with Arch's
upgrades.

Re: How to use/install rust nightly on guix ?

[Csepp]

"("  writes:

> On Sat Oct 29, 2022 at 1:29 PM BST, Mohamed Amine LEGHERABA via wrote:
>> Hello guys,
>> Any ideas for the best way to install rust nightly on guix ? I don't find it 
>> in the guix channel, neither rustup.
>> I need rust nightly to compile a certain project (this one : 
>> https://github.com/paritytech/substrate).
>
> You can't. Rustup doesn't work on Guix/Nix, as it assumes FHS. You'd
> have to package rust-nightly, but it'll take ages to build...
>
> -- (

Well, you *might* be able to get it working with an FHS container and
maybe an overlay mount.
What I would personally do is install Arch in a chroot and install
rustup there.  You can even use Guix within the chroot if you bind mount
it.
If you want to try that, I have a more detailed how-to that I can send.

Re: program prepared with `guix pack` unusable by end users

[Csepp]

Wojtek Kosior via  writes:

> [[PGP Signed Part:Undecided]]
> My problem has been solved. It turned out the Python interpreter
> contained within the pack was finding an older version of `hydrilla`
> Python package installed in `~/.local/lib/python3.9/site-packages` and
> that older version was missing the `console_scripts` entry point that
> was being loaded. It's worth mentioning that Python interpreter gives
> `~/.local/lib/python3.9/site-packages` priority over the paths that
> Guix adds to GUIX_PYTHONPATH.
>
> The solution was to patch the wrapper script for each of the commands
> my package provides. Definition of PYTHONNOUSERSITE enviroment variable
> stops Python from looking at local site packages.
>
> You can see my fix here[1]. I most importantly needed to add the
> following to #:phases of my package definition
>
>> (add-after 'wrap 'prevent-local-package-interference
>>   (lambda* (#:key outputs #:allow-other-keys)
>> (match-let _ . dir)) outputs))
>>   (for-each (lambda (prog-name)
>>   (substitute* (string-append dir "/bin/" prog-name)
>> (("^#!/.*$" shabang)
>>  (string-append shabang
>> "export PYTHONNOUSERSITE=1\n"
>> '("hydrilla"
>>   "hydrilla-server"
>>   "hydrilla-builder"
>>   "haketilo")
>
> It's worth noting that this problem is not exclusive to `guix pack` or
> to my particular package. Users of other Python programs could in some
> circumstances experience similar issues. Which makes me think -
> shouldn't the default behavior be changed? Perhaps by making Python
> give paths from `GUIX_PYTHONPATH` priority over those in user site
> packages directory? Should I report this as a bug to bug-g...@gnu.org?
>
> Best,
> Wojtek
>
> [1]
> https://git.koszko.org/pydrilla/commit/?h=koszko=f7c4dff95e88d58d61c51b2a6b94c90e2e4e0c4b
>
>
> -- (sig_start)
> website: https://koszko.org/koszko.html
> PGP: https://koszko.org/key.gpg
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!   #17: blessed Jolenta Helena
> Poznaj świętych krakowskich!  #17: błogosławiona Jolenta Helena
> https://pl.wikipedia.org/wiki/Jolenta_Helena
> -- (sig_end)
>
>
> On Mon, 17 Oct 2022 15:36:48 +0200
> Wojtek Kosior via  wrote:
>
>> Hello again after a break,
>> 
>> > Well, then I tried to reproduce your failure in order to understand what
>> > is going wrong but I hit this:
>> >
>> > [...]
>> > 
>> > That’s because your package ’python-pyopenssl-for-haketilo’ inherit from
>> > ’python-pyopenssl’ defined in (gnu packages python-crypto).  The issue
>> > is that the ’origin’ also inherits
>> > 
>> >(origin
>> >  (inherit (package-source base))
>> >  
>> > and thus
>> > 
>> >(patches (search-patches 
>> > "python2-pyopenssl-openssl-compat.patch"
>> > 
>> > does not make sense anymore because this patch is against 21.0.0 and
>> > your variant is about 22.0.0.  
>> 
>> Thank you for your time spent on trying this out.
>> 
>> The error is surely a result of us using different Guix versions. In the
>> version I had the pyOpenSSL version was 20.0.1 and no patch was being
>> used yet[1].
>> 
>> Another user also had problems building from source under a different
>> Guix version. I knew this would happen but I didn't have a ready
>> solution before. I now came up with a Makefile that organizes most
>> common development tasks in my project into rules that call `guix
>> time-machine` under the hood[2]. This should be a general solution for
>> this kind of problems.
>> 
>> > Well, further investigations about what could be wrong for “guix pack”
>> > needs a way to reproduce. :-)  Could you fix or point a working
>> > example in your Git repository?  
>> 
>> As for troubleshooting the creation of Hydrilla 3.0-beta1 pack, one can
>> get the same enviroment I was using by pulling Guix from commit
>> fd00ac7e27c8a6d4b4d4719b4f8797bdce204623. Although most list users here
>> probably know how to achieve this, I'm putting this here for convenience
>> 
>> > guix time-machine
>> > --commit=fd00ac7e27c8a6d4b4d4719b4f8797bdce204623 --
>> > 
>> 
>> Anyway, the main problem could probably be also troubleshooted by
>> experimenting with the pack I made available[3] as it is also the one
>> that is known to have caused problems.
>> 
>> Thank you again,
>> Wojtek
>> 
>> [1]
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-crypto.scm?id=fd00ac7e27c8a6d4b4d4719b4f8797bdce204623#n650
>> [2]
>> https://git.koszko.org/pydrilla/commit/?h=koszko=ed2e14dd6ced4f64b6ac707c5998b38a78e6d7ad
>> [3] https://hydrillabugs.koszko.org/projects/haketilo/wiki/Releases#Files
>> 
>> -- (sig_start)
>> website: https://koszko.org/koszko.html
>> PGP: https://koszko.org/key.gpg
>> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> 
>> Meet Kraków saints!   #13: blessed 

Re: Help packaging R Quarto Cli

[Csepp]

zimoun  writes:

> Hi Sébastien,
>
> On lun., 24 oct. 2022 at 13:43, Sébastien Rey-Coyrehourcq
>  wrote:
>
>> I’m trying to package Quarto Cli (
>>  ), used in combination with
>> Pandoc to publish -reproducible- scientific document : website, blog,
>> etc.
>
> Well, after a quick look I think it is not easy to package because it is
> TypeScript and the story between JavaScript and Guix is not really
> smooth. :-)
>
>
>> I first think this is a classic gnu build : ./configure && make &&
>> make install BUT, there is a problem because the ./configure script
>> bootstrap “Deno” during the run of configure.sh.
>
> Assuming “Deno“ (a modern runtime for JavaScript and TypeScript written
> in Rust) is packaged by Guix, the build system for packaging Quarto
> would not clear to me.
>
>
>> Because this download and compilation of Deno occur during
>> ./configure.sh running, guix cannot patch the  #!/bin/bash path, so
>> ./configure failed. Deno seems also not packaged into guix.
>>
>> Do you have an idea to resolve this ? Perhaps we could try all
>> together to do this.
>
> Hum, maybe package deno. ;-)  Well, 
>
> guix import crate deno -r
>
> is a starting point.  But Deno, neither Quarto, are easy to package for
> Guix.
>
>
> Cheers,
> simon

There is a channel for free software that is not easily bootstrappable
that this might be suitable for:
https://github.com/guix-science/guix-science
That is where RStudio is packaged for example.

Re: How to avoid downloading qtbase:debug

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Csepp  writes:
>
>> kiasoc5  writes:
>>
>>> Dear Guix,
>>>
>>> =guix shell qtbase= downloads the entire debug output of qtbase even
>>> though I didn't write down qtbase:debug. That's hundreds of megabytes
>>> of bandwith I didn't want to use. How do I avoid downloading the debug
>>> output? Is this a bug?
>>
>> I think it should be considered a bug.  guix shell always downloads
>> every output of all the packages.
>
> Yes, that's annoying.  I think it has to do with grafts; when a package
> must be grafted, all its output must be available.  Grafts complicates
> many things, but unfortunately they are necessary to provide timely
> security updates.
>
> I don't see a bug anymore for that one, we should try to improve things
> here; feel free to report it to bug-g...@gnu.org, perhaps with a title
> like "grafts cause all outputs to be downloaded".  Perhaps a solution
> would be making graft derivations substitutable (currently they happen
> on the local machine).

Could you write it?  It's clear you know much more about what's going on
under the hood.

Re: How to avoid downloading qtbase:debug

[Csepp]

kiasoc5  writes:

> Dear Guix,
>
> =guix shell qtbase= downloads the entire debug output of qtbase even
> though I didn't write down qtbase:debug. That's hundreds of megabytes
> of bandwith I didn't want to use. How do I avoid downloading the debug
> output? Is this a bug?

I think it should be considered a bug.  guix shell always downloads
every output of all the packages.

Re: I have to log in my Guix twice in order to start it

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Guixers,
>
> since the last updating config.scm
>
> I have to log in twice in order to start Guix.
>
> If I log in then the same log in screen appears, where I have to put
> in my password again.
>
> Then Guix starts.
>
> What could be the problem?
>
> Gottfried
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x61FAF349C9FB7F94.asc]...
>
> [[End of PGP Signed Part]]

Just to clarify, what display manager and desktop environment?  I guess
GDM and Gnome, but better be sure.

Re: how to fix this G-exp?

[Csepp]

zimoun  writes:

> Hi,
>
> I am missing something and I do not find my way, so maybe someone could
> explain me what I am doing wrong.

I'll try. UwU

> Let start with this example.
>
> (use-modules (srfi srfi-1)
>  (ice-9 match)
>  (guix packages)
>  (gnu packages))
>
> (define (package+propagated-inputs package)
>   (match (package-transitive-propagated-inputs package)
> (((labels packages) ...)
>  (cons package packages
>
>
> (define (something)
>   42)
>
So this will take one of these values with the later edits you talk
about:
42
'(42)
'(42 42)
And this is used...
>
> (define (an-example)
>
>   (define build
> (with-extensions (package+propagated-inputs
>   (specification->package "guile-json"))
>   (with-imported-modules '((guix build utils)
>(json))
> #~(begin
> (use-modules (guix build utils)
>  (json))
>
> (define that
>   #+(something))
...here!  The later use of "that" is not important.
>...
When you spliced (not sliced) it, you got:
```
(define that (42))
```
As you can see, that is an unqouted list.  The fix should be pretty
simple: just add an extra quote.  Haven't tested it, but one of these
should work:
```
(define (something) ''(42))
;; or
(quote #+(something))
```

I'm pretty sure I've run into this in a service definition and used the
latter.

Re: Package inputs specific to an output

[Csepp]

Olivier Dion via  writes:

> Hi,
>
> Is there a way to make a package that has inputs that will only be
> installed when a given output is selected?
>
> For example, I have a library that has a set of inputs for linking
> against them.  The project also come with optional executable tools that
> use the library but also other inputs.  I don't want these extra inputs
> to be installed along the library if the user does not want the tools.

Normal inputs are only installed iff the package references them.
Propagated inputs are the ones that are "always installed" (they also
show up in the profile), I'm not aware of any way to make them only be
referenced from certain outputs, but in general packages should try to
avoid using them and use regular inputs whenever possible.

Re: Question about the use of GNU Guix in production

[Csepp]

Daniel Riesner  writes:

> Hello,
>
> although for now I only quickly tried GNU Guix in a vm, but more in
> depth have read the well written GNU Guix manual, I'm quite fascinated
> by it. Having a bit of a background in DevOps working among other
> things with infrastructure as code tool Terraform and the method of
> GitOps, I came to like declarative configuration. To me it seems for
> operating services, it brings e.g. greater transparency in
> collaboration and better ways to test and rollback changes in case of
> failure. Concerning the more political aspects, in many places I
> prefer free software and more decentralized services. Since I'm
> currently looking for a job, besides academic institutions, are there
> any companies known to use GNU Guix, which maybe even have open
> positions preferably in Germany or remote? Or do you maybe know of any
> places where such offers are shared as it is done e.g. for NixOS in
> their discourse forum?
>
> Best wishes
> Daniel Riesner

I've seen at least one job offer on one of the mailing lists (probably
the developer one), but it's not a common sight.

Re: tor

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
>> Word of warning: if you want to stay anonymous, you should use Tor
>>> Browser or Tails.  Icecat is a bad choice, it has few users and its
>>> developers added some custom code that makes it very easy to figure out
>>> your aren't running vanilla Firefox.
>
> As far as I understand it:
>
> How can I use Tor Browser or Tails in Guix?
>
> I would have to use Tails through a usb-stick, without installing it
> on the harddisk - am I right?
>
> How could I use Tor Browser with Guix?
>
> Gottfried
>
>
> Am 28.08.22 um 14:09 schrieb Csepp:
>> Gottfried  writes:
>> 
>>> [[PGP Signed Part:Undecided]]
>>> Hi Guixers,
>>>
>>> I installed "tor".
>>>
>>> Do I also need "tor-client" and "torsocks"?
>>>
>>> I don't know what they are for.
>>>
>>> I don't want to have too many packages, so if I don't need them to run
>>> tor, I can uninstall them.
>>>
>>> Gottfried
>>>
>>> [2. OpenPGP public key --- application/pgp-keys; 
>>> OpenPGP_0x61FAF349C9FB7F94.asc]...
>>>
>>> [[End of PGP Signed Part]]
>> You can just use tor and set your browser or whatever to use it as a
>> proxy.  Torsocks mostly does the same thing.  Kind of.  (Not really.)
>> Word of warning: if you want to stay anonymous, you should use Tor
>> Browser or Tails.  Icecat is a bad choice, it has few users and its
>> developers added some custom code that makes it very easy to figure out
>> your aren't running vanilla Firefox.
>
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x61FAF349C9FB7F94.asc]...
>
> [[End of PGP Signed Part]]

Tails itself has docs on how you can use it, Guix doesn't matter in that
case.
For Tor Browser, your best bets are containers of some sort.  I have
Arch and Debian chroots for running software that Guix can't run yet.
Maybe it has a Flatpak?  I think there might be some info on the mailing
list about running it, I know I've seen others discuss it.

Personally, I use Tails from a USB stick, it's the most secure of all
the alternatives.

Re: tor

[Csepp]

Gottfried  writes:

> [[PGP Signed Part:Undecided]]
> Hi Guixers,
>
> I installed "tor".
>
> Do I also need "tor-client" and "torsocks"?
>
> I don't know what they are for.
>
> I don't want to have too many packages, so if I don't need them to run
> tor, I can uninstall them.
>
> Gottfried
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x61FAF349C9FB7F94.asc]...
>
> [[End of PGP Signed Part]]

You can just use tor and set your browser or whatever to use it as a
proxy.  Torsocks mostly does the same thing.  Kind of.  (Not really.)

Word of warning: if you want to stay anonymous, you should use Tor
Browser or Tails.  Icecat is a bad choice, it has few users and its
developers added some custom code that makes it very easy to figure out
your aren't running vanilla Firefox.

Re: Build particular Rust version

[Csepp]

Matthew James Kraai  writes:

> Hi,
>
> Is it possible to build Rust 1.58.1 without updating the `rust`
> definition?  If so, how do I do so?
>
> If I apply this patch:
>
> ```
> diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
> index 67dc5cdaf3..61d6686b64 100644
> --- a/gnu/packages/rust.scm
> +++ b/gnu/packages/rust.scm
> @@ -644,10 +644,14 @@ (define rust-1.56
> rust-1.55 "1.56.1" 
> "04cmqx7nn63hzz7z27b2b0dj2qx18rck9ifvip43s6dampx8v2f3"))
>  
>  (define rust-1.57
> +  (rust-bootstrapped-package
> +   rust-1.56 "1.57.0" 
> "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim"))
> +
> +(define rust-1.58
>(let ((base-rust
>   (rust-bootstrapped-package
> -  rust-1.56 "1.57.0"
> -  "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim")))
> +  rust-1.57 "1.58.1"
> +  "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8")))
>  (package
>(inherit base-rust)
>(outputs (cons "rustfmt" (package-outputs base-rust)))
> ```
>
> and run `./pre-inst-env guix build rust@1.58.1`, it outputs
>
> ```
> guix build: error: rust: package not found for version 1.58.1
> ```

I haven't tried building Rust, but at a glance it seems like the new
package inherits its version field from base-rust.
Guix doesn't really care what symbol you assign the package to, only the
version field matters.  You could write (define-public
this-is-definitely-php rust-base) and it would still show up in `guix
search rust`.

Re: Am I doing it all wrong?

[Csepp]

jgart  writes:

> Hi,
>
> This is what I do to work on GNU Guix on a foreign distro:
>
> git clone https://git.savannah.gnu.org/git/guix.git
>
> cd guix
> guix shell -D guix --container -- ./bootstrap
> guix shell -D guix --container -- ./configure --localstatedir=/var
> guix shell -D guix --container -- make
> guix shell --container --network coreutils vis ripgrep rlwrap -D guix 
> --share=/var/guix/
>
> Should I be doing anything differently in the above for setting up a dev 
> environment for guix hacking?

You probably want to invoke ./configure like so:
./configure --sysconfdir=/etc/ --localstatedir=/var/

Otherwise if you reconfigure the system from the local checkout you will
run into some "fun" behaviour.

Re: Am I doing it all wrong?

[Csepp]

"("  writes:

> On Sat Aug 27, 2022 at 9:56 PM BST, ( wrote:
>>   guix shell -D guix -- sh <>   ./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)
>>   EOF
>
> You could wrap it in a sh function:
>
>   gsh() {
>   guix shell $@ -- sh
>   }
>
>   gsh -D guix <   ./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)
>   EOF
>
> -- (

Did you test that one?  Because I'm pretty sure it won't work, you
aren't passing the heredoc file descriptor to sh but guix shell.
Also, that should probably be "$@", just in case.

Because Bash is garbage. :)

Re: What Python IDE are you using?

[Csepp]

Luis Felipe  writes:

> [[PGP Signed Part:Undecided]]
> On Tuesday, August 23rd, 2022 at 16:52, Luis Felipe 
>  wrote:
>
>> Hi raingloom,
>> 
>
>> On Tuesday, August 23rd, 2022 at 11:34, Csepp raingl...@riseup.net wrote:
>> 
>
>> > kakoune + kak-lsp + python-lsp-server + python-black + mypy, maybe a
>> > kakoune editorconfig plugin too
>> > 
>
>> > I load it in a guix shell and blamo, nice editor with pretty much every
>> > IDE functionality you could dream of.
>> > 
>
>> > I've used this for multiple projects at uni, IMHO it works pretty well.
>> 
>
>> Oh, I didn't know about kakoune. I'll put it on the list. Thanks, raingloom 
>> :)
>
> I think I'm going to explore vim further as my fallback editor. It
> seems like that's the first step to understand kakoune (I couldn't get
> started with kakoune Get started! document :]).
>
> raingloom, did you move from vim to kakoune? If that was the case, did you 
> found something annoying when programming Python in vim?
>
> [2. application/pgp-keys; publickey - luis.felipe...@protonmail.com - 
> 0x12DE1598.asc]...
>
> [[End of PGP Signed Part]]

I went through the vim tutorial a few years ago, tried neovim for a
while, but haven't used it in years.  I tend to switch between editors.
Before Kakoune I used Acme for a long time, which inspired some features
of Kakoune.  I also use Emacs quite a bit.
I tried Kakoune mostly because I really liked the ideas in Acme but
didn't like how anti-keyboard it was.  The simple orthogonal
configuration language and its focus on multiple selections were very
appealing too.  I don't like old editors with crusted up config
languages and UX conventions.  I could never really "git gud" at neovim,
so I abandoned it, but Kakoune just "clicked" after 1-2 afternoons of
noodling around in it.

Re: Packaging Idris2

[Csepp]

cont...@phfrohring.com writes:

> Dear Guixers,
>
> I've a working package of `idris2' here:
> .
> It builds on previous work: .
> Would it help to send it to `guix-patc...@gnu.org'?
>
> —PHF

Looks very good IMHO, please do send it.

If the bootstrapping thing is a problem we can always do that later, it
should be as easy as "unvendoring" the scripts.  If I remember
correctly, the precise version they were generated from is documented
and saved somewhere on the project's or Edwin Brady's Github.

Re: What Python IDE are you using?

[Csepp]

Luis Felipe  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> I've been using Emacs Elpy as my Python IDE for a long time now, but
> it's been failing to work properly for a while (currently,
> autocompletion doesn't work; before that linting was not working).
>
> What do you use to program in Python? Is the IDE you use dependable or does 
> it present these kinds of frequent problems too?
>
> So far I've tried GNOME Builder, but it's pretty much like using
> Gedit: just syntax highlighting. GNOME Builder's features have never
> worked when I've tried them out.
>
> I'm currently checking an IDE called Pyzo. And next will try Emacs
> lsp-mode. So if you have had a good/bad experience with these, I'd
> appreciate if you could comment about it.
>
> Thanks in advance,
>
>
> ---
> Luis Felipe López Acevedo
> https://luis-felipe.gitlab.io/
>
> [2. application/pgp-keys; publickey - luis.felipe...@protonmail.com - 
> 0x12DE1598.asc]...
>
> [[End of PGP Signed Part]]

kakoune + kak-lsp + python-lsp-server + python-black + mypy, maybe a
kakoune editorconfig plugin too

I load it in a guix shell and blamo, nice editor with pretty much every
IDE functionality you could dream of.

I've used this for multiple projects at uni, IMHO it works pretty well.

Re: Packaging Idris2

[Csepp]

"("  writes:

> Hi Andreas,
>
> On Sat Aug 20, 2022 at 11:01 PM BST, Andreas Reuleaux wrote:
>>   You bootstrap it from scheme (chez or racket), as comes within the Idris2 
>> tarball
>>   (and built with Idris 2 itself: Idris2 -> Chez Scheme / Racket).
>
> Since this Scheme is pregenerated, it cannot really count as source code. So
> we need to find a version of Idris2 that can still be built with Idris1, then
> try to build a later version with that Idris2, and keep going until we get to
> the latest version, like our rustc bootstrap process.
>
> -- (

Yup.

And there are already patches and channels floating around that do that.
Anyways, if you want to work on Idris 2, I highly recommend looking at
them.  Otherwise you are doing work that has already been done.  Which
is fine if you are only doing this as an exercise, but if you are
serious about packaging Idris 2, you should know about the issues that
have come up with it.

ps.: pls no benchmarks without hardware info. :)
I know what I'm talking about when I say it takes too many resources on
my machine and I'm aware that more powerful computers exist and that Idris
2 compiles itself faster than Idris 1 does.

Re: Packaging Idris2

[Csepp]

Pierre-Henry Fröhring  writes:

> Well, I went from a `guix shell --container' up to `make test' passing ;
> assuming a `chez-scheme' backend (no `node' nor `racket'). It boils down
> to a shell session looking like:
>
> ┌
> │ $ cd ~/src/
> │ $ git clone g...@github.com:idris-lang/Idris2.git
> │ $ cd Idris2
> │ $ ./build_idris
> └
> Listing 1: session
>
> I guess that an idea would be to « translate » this session into a Guix
> Package. What's the best option here? To torture the `gnu-build-system'
> until it accepts to build Idris2 or should I take the
> `trivial-build-system' route?
> Thank you.
> ― PHF
>
> ┌
> │ #! /usr/bin/env bash
> │ set -euo pipefail
> │ IFS=$'\n\t'
> │ 
> │ cat <<'EOF' >manifest.scm
> │ (specifications->manifest
> │  '("gcc@12.1.0"
> │"chez-scheme"
> │"gmp"
> │"coreutils"
> │"bash"
> │"make"
> │"findutils"
> │"git"
> │"diffutils"
> │"glibc"
> │"sed"
> │"gawk"
> │"binutils"))
> │ EOF
> │ 
> │ cat <<'EOF' >build_idris_in_container
> │ set -euo pipefail
> │ IFS=$'\n\t'
> │ 
> │ echo 'Idris build configuration'
> │ set -x
> │ export PREFIX=/tmp/idris2
> │ export SCHEME=chez-scheme
> │ export CC=gcc
> │ export INTERACTIVE=''
> │ set +x
> │ echo
> │ 
> │ echo 'PATHS configuration'
> │ set -x
> │ export LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib:$PREFIX/lib
> │ export PATH=$PATH:$PREFIX/bin
> │ set +x
> │ echo
> │ 
> │ echo 'Bootstrap'
> │ make bootstrap
> │ echo
> │ 
> │ echo 'Install'
> │ make install
> │ echo
> │ 
> │ echo 'Self-host'
> │ make clean
> │ make all
> │ make install
> │ echo
> │ 
> │ echo 'Test'
> │ make test
> │ echo
> │ 
> │ echo 'Clean'
> │ rm -v manifest.scm
> │ rm -v build_idris_in_container
> │ echo
> │ EOF
> │ 
> │ guix shell -C -m manifest.scm -- bash ./build_idris_in_container
> └
> Listing 2: build_idris

I'm pretty sure Lendvai Attila has a WIP package that was supposed to be
submitted as a patch "soon", which was like a year ago.

Anyways, there are definitely already Idris 2 patches floating around
the mailing list so I'd prefer if discussion was moved there.
I'm also interested in getting it packaged, but building it takes a lot
of time.
The Scheme bootstrap seed can be generated with Idris 1, true.  But
compiling Idris 2 with Idris 1 takes such an ungodly amount of time and
RAM that expecting people to do so is maybe not a great idea.  I
certainly will not be working on that.  Last time I built it I needed at
least 16 gigs of swap.  I have better use cases for my SSD.

Re: Deploy to guix machine

[Csepp]

Reza Housseini  writes:

> [[PGP Signed Part:Undecided]]
> Hi list
>
> I have a server running guix system, with this configuration
>
> (list (machine
>(operating-system my-server)
>(environment managed-host-environment-type)
>(configuration (machine-ssh-configuration
>(host-name "my-host")
>(system "x86_64-linux")
>  (identity "~/.ssh/id_card.pub")

Try replacing "~" with (getenv "HOME")?  I don't see anything in the
manual about it auto-expanding tildes like Bash does.

Re: substitute for Skype

[Csepp]

Akib Azmain Turja  writes:

> [[PGP Signed Part:Undecided]]
> Benjamin Slade  writes:
>
>> Depending on the exact use case, there are some other possibilities
>> that don't run "natively" on Guix, but are still free software and
>> could be installed from Flatpak or Nix. E.g. the Signal client for
>> desktop and Matrix Element.
>>
>> Though, actually, I think the Nheko client for Matrix (available as
>> a Guix package) also has voice/video call support though I haven't
>> tried it before.
>>
>> --Ben
>
> What about XMPP (Jabber)?  Dino, a XMPP client, supports encrypted video
> chat from version 0.3, and it's packaged in Guix.  As XMPP is
> decentralized, the users don't need to have an account on your server.

XMPP and Matrix are both federated, if your guests don't already have
accounts somewhere, they will need to register somewhere.

There is work on making Matrix fully peer to peer, but it's not yet done.

Tox and Jami are fully peer to peer, so you only need a client, no
server needed.  When I last used Tox it kind of sucked if you wanted to
log in from multiple machines, so, keep that in mind if you want
persistent text chat as well.
Matrix solves this issue, you can log in from any number of clients,
even simultaneously.
XMPP... well if you want encryption, it's pretty janky.  OMEMO became
desynced for me with both Dino and Gajim and never recovered, so new
messages could not be decrypted by all participants.  Based on that, I
would recommend against XMPP for persistent chat rooms.
Of course if you only use Dino for video chat and don't care about chat
history, this is less of an issue.

Re: Configuring geiser for load paths of Guix environment

[Csepp]

Olivier Dion via  writes:

> Hi,
>
> Say I have a .guix.scm in my project with something like
> (specifications->manifest (list "guile" "guile-fibers" "guile-gcrypt"))
>
> If I want to develop with Geiser, it needs to find these modules in its
> load paths.  My solution to this problem is the following .geiser at the
> project root:
>
> ;; -*-Scheme-*-
> (let* ((port ((@@ (ice-9 popen) open-input-pipe)
>   "guix shell -m .guix.scm -- /bin/sh -c 'echo 
> $GUIX_ENVIRONMENT'"))
>(profile ((@@ (ice-9 rdelim) read-line) port)))
>   (add-to-load-path (string-append profile "/share/guile/site/3.0"))
>   (set! %load-compiled-path
> (cons (string-append profile "/lib/guile/3.0/site-ccache")
>   %load-compiled-path)))
>
> I'm wondering if someone has a better solution to this?

I'm not an Emacs guru, so this might suck, but what I did is simply set
the related variable.  Forgot what it was, but its contents were "guile"
and I changed it to '("guix" "repl") and it worked.  You could probably
do something like '("guix" "shell" "-m" "guix.scm" "--" "guile") .

Re: guix shell (environment) 32-bit

[Csepp]

Gareth Lagerwall  writes:

> Hi there,
>
> Is it possible to set up a 32-bit shell, with 32-bit applications, on a
> 64-bit guix OS? I seem to recall the filesystem being a possible option
> when configuring a shell maifest, but just wanted to confirm.
>
> Kind Regards
>
> Gareth
> --
>
> *Gareth Lagerwall, PhD*
> Candidate Engineer
> Email: gareth.lagerw...@gmail.com
>
> "Problems cannot be solved by the same level of awareness that created
> them" Albert Einstein

It Just Works TM.

```
$ uname -m
x86_64
$ guix shell --system=i686-linux hello -- hello
Hello, world!
```

Not sure what you mean by filesystem, filesystems don't have anything to
do with guix shell as far as I know.

Re: Correct way to install perl-anyevent-i3?

[Csepp]

Chris Keschnat via  writes:

> Hello,
> I have =i3-wm= installed via a package under =operating-system=.
> Calling =i3-save-tree= gives the following error:
>
> #+begin_src sh
>
>   $ i3-save-tree
>   Can't locate AnyEvent/I3.pm in @INC (you may need to install the 
> AnyEvent::I3 module) (@INC contains: 
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0/lib/perl5/site_perl/5.34.0/x86_64-linux-thread-multi
>  
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0/lib/perl5/site_perl/5.34.0
>  
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0/lib/perl5/5.34.0/x86_64-linux-thread-multi
>  /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0/lib/perl5/5.34.0) at 
> /run/current-system/profile/bin/i3-save-tree line 19.
>   BEGIN failed--compilation aborted at 
> /run/current-system/profile/bin/i3-save-tree line 19
>
> #+end_src
>
>
> So I added =perl-anyevent-i3= to the package definition (in the 
> =operating-system=).
> After a =guix system reconfigure= and a reboot, =i3-save-tree= is still 
> giving the same error.
>
> There seems to be something wrong with the load path
> (I don't know perl terminology, but I hope it is clear what I mean).
>
> The locations are as follows:
>
> #+begin_src sh
>
>   $ which i3
>   /run/current-system/profile/bin/i3
>   $ ls -l /run/current-system
>   lrwxrwxrwx 1 root root 50 27.07.2022 15:19 /run/current-system -> 
> /gnu/store/nv9h5bdfyz3hzv11c7c2kaxiiqkv84ds-system
>   $ locate I3.pm
>   
> /gnu/store/d3xis9wkrmi2lrpkb61cl31nsyrpm921-perl-anyevent-i3-0.17/lib/perl5/site_perl/5.34.0/AnyEvent/I3.pm
>
> #+end_src
>
> PS: I had started with installing =perl-anyevent-i3= under my normal user. 
> The errors were similar.
>
> I am unsure how to proceed and grateful for any hints.
>
> Thank you
> Chris

What happens if you also include perl in the packages field?

Re: Substitute not being used

[Csepp]

Saku Laesvuori  writes:

> [[PGP Signed Part:Undecided]]
> I'm trying to install telegram-desktop and I *think* guix should be able
> to substitute it, but instead it tries to build it. (which then
> consistently fails, which is why I started looking into it)
>
> $ guix describe
> Generation 11 Jul 25 2022 10:15:41(current)
>   guix 2367469
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: 236746900f062b34c857c4aab21709bcf1448ac7
>
> There is a build for telegram-desktop for x86_64-linux
> (https://ci.guix.gnu.org/build/1119886/details) that is part of an
> evaluation on the same commit that my guix is on.
>
> One confusing thing I've noticed while looking into this is that when
> guix starts building telegram-desktop it says it's building
>
> /gnu/store/aqhqhza58lzkvzxrspzbf8v9ssqvkxri-telegram-desktop-2.9.3.drv
>
> but the derivation on ci.guix.gnu.org is
>
> /gnu/store/gz50dz1rfaik7s33d22r2lmyzwd7f7bm-telegram-desktop-2.9.3.drv
>
> Can someone explain what's happening here and what I have misunderstood?
>
> [[End of PGP Signed Part]]

An explanation I've heard is that the bordeaux signing key is not
authorized by default or something.  I've had similar issues and could
not figure out a way to solve it, not even with that info.

Re: how can I use "tor"

[Csepp]

Just a heads up, if you want proper anonymity, IceCat is almost
certainly a bad choice. All the weird custom addons and source level
modifications and the fact that very few people use it makes it *easier*
to de-anonymize you.
But if you just want to unblock some things or use onion addresses to
get around NATs, IceCat will be fine.
If you want actual anonymity, Tor Browser and Tails are better choices.

Julien Lepiller  writes:

> 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  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 
 

Re: fixing sticky package

[Csepp]

András Vöröskői  writes:

> Hi,
>
> I have done something like this:
> 1. I have zig@0.10 installed in my profile.
> 2. Started a guix shell -m guix.scm which has zig@0.9
> 3. Run zig version and it reported 0.10.0
> 4. guix remove zig@0.10
> 5. zig version still reports 0.10.0
>
> At that point I have switched to panic mode, exited from everything, but
> now when I run `guix package -I` it reports an only `zls` and `git-minimal`
> installed, which is fine.
> However when I run `which zig` it finds `zig` in /gnu/store.
>
> If I try to `guix remove zig` it says zig is not found in profile.
>
> How can I remove zig from my profile?
>
> Thanks,

guix shell runs a program (a shell by default) in a temporary
environment that has some packages added.
guix remove is an alias of guix package --remove, which works on
persistent stateful profiles, like ~/.guix-profile.
You told it to create a new profile generation with zig removed, which
it did.  But that does not affect the temporary profile that was also
active.
To modify the list of packages in a guix shell profile, you can either
source additional search paths, or exit the guix shell and run it again
with a different manifest or package list.

Re: error failed to load

[Csepp]

mj lane  writes:

> Hi Guix!
> I can't do, what's the point of a mistake a failed to load
>
>  guix package --export-manifest
> guix package: warning: failed to load '(cuirass base)':
> no code for module (mailutils mailutils)
> guix package: warning: failed to load '(cuirass http)':
> no code for module (squee)
> guix package: warning: failed to load '(cuirass mastodon)':
> no code for module (mastodon)
> guix package: warning: failed to load '(cuirass remote)':
> no code for module (simple-zmq)
> WARNING: (cuirass scripts register): imported module (fibers) overrides
> core binding `sleep'
> guix package: warning: failed to load '(cuirass scripts remote-server)':
> no code for module (simple-zmq)
> guix package: warning: failed to load '(cuirass scripts remote-worker)':
> no code for module (simple-zmq)
> WARNING: (cuirass scripts web): imported module (fibers) overrides core
> binding `sleep'
> ;; This "manifest" file can be passed to 'guix package -m' to reproduce
> ;; the content of your profile.  This is "symbolic": it only specifies
> ;; package names.  To reproduce the exact same profile, you also need to
> ;; capture the channels being used, as returned by "guix describe".
> ;; See the "Replicating Guix" section in the manual.
>
> (specifications->manifest
>   (list ".."))
>
> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.
>
> Hope that helps
> Mlan

Did you modify any environment variables used by Guile or Guix? I've
seen similar errors when I've done that.

Re: How do I verify my hashes?

[Csepp]

Vagrant Cascadian  writes:

> [[PGP Signed Part:Undecided]]
> On 2022-07-09, jg...@dismail.de wrote:
>> Today Bonface mentioned to me that I should be cloning my packages and
>> verifying the hashes with `git hash-object` or `git hash` iirc?
>
> probably "guix hash"
>
>> Do others do this when packaging?
>>
>> My workflow currently is the lazy way:
>>
>> 1. I change the version in the package definition.
>>
>> 2. build the package
>>
>> 3. package blows up on stdout
>>
>> 4. I retrieve the hash and add it
>>
>> 5. profit!
>
> Profit, for whom? Whoever injected the cryptocurrency malware? :P
>
>
> My workflow for git-based things is typically:
>
> 1. git clone https://example.org/someproject.git && cd someproject
>
> 2. git co -b VERSION-local VERSION
>
> 3. git diff OLDVERSION..NEWVERSION
>
> 4. git clean -dfx # make sure the working tree is totally clean
>
> 5. guix hash -rx .
>
> Step 3, even if I don't completely understand the code, I can at least
> check for (problematic) license changes or maybe something "obviously"
> wrong.
>
> Similar steps for tarballs-based projects, though you may need to unpack
> and/or diffoscope the sources for step 3.
>
>
> I don't have a good idea how to verify pypi or similar origins... but
> you could at least double-check the sources of the old and new versions
> with something like:
>
> 1. guix build --source # before you update the hash
>
> 2. update version, build, get new hash, update hash ...
>
> 3. guix build --source # after updating the hash
>
> 4. diffoscope OLDSOURCE NEWSOURCE
>
> And do a best effort check for issues...
>
>
> live well,
>   vagrant
>
> [[End of PGP Signed Part]]

Hmm, would some sort of package history command be useful here?
Maybe something that would walk the git history (fine grained) or just
previous generations of guix pull (coarse grained) and try to present
some useful changelog.

Git repos can be ginormous (ever tried cloning LLVM? yikes.) so
something that was a bit smarter and did a shallow fetch with only the
commits that are packaged would save some storage and prolong the life
of SSDs.