Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of substitutes

[Blake Shaw]

Hi Christopher,

Here in Singapore download speed has gone from bad to worse over the
last two weeks, so bad that I was having to --fallback often and wound
up setting up a cuirass instance to continuously build a collection of
manifests I'm working with (which solved the issue). Not at my machine
atm but will wget stellarium and send the results when I am.

Best,
Blake

---
Blake Shaw
Director, SWEATSHOPPE
sweatshoppe.org
---

On Fri, May 20, 2022 at 11:09 PM Christopher Baines  wrote:
>
> Hey!
>
> So the nar-herder came in to existence at the end of last year (2021)
> and while the main use at the time was addressing the lack of storage on
> bayfront, I also hoped to improve the situation regarding mirrors for
> substitutes.
>
> I'm not in a great situation to test this though, as my usual internet
> connection is slow enough that a closer mirror probably won't make much
> difference.
>
> So, one thing that I'd be interested in, is hearing from anyone who
> thinks they get worse download performance from bordeaux.guix.gnu.org or
> ci.guix.gnu.org than they get when downloading other
> things. Importantly, it would be good to know roughly where
> (geographically) the machine doing the downloading is, and some data to
> show the difference.
>
> For example, I'm in the United Kingdom in Europe, and this is the output
> from wget downloading a ~200M file from bordeaux.guix.gnu.org:
>
>   → wget 
> https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   --2022-05-20 16:49:56--  
> https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 2a0c:e300::58, 
> 185.233.100.56
>   Connecting to bordeaux.guix.gnu.org 
> (bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected.
>   HTTP request sent, awaiting response... 200 OK
>   Length: 208615205 (199M) [text/plain]
>   Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’
>
>   078vr3r8mn3yrwzwxw64 100%[==>] 198.95M  4.24MB/sin 
> 46s
>
>   2022-05-20 16:50:43 (4.31 MB/s) - 
> ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’ saved 
> [208615205/208615205]
>
>
> Also, I've setup a US based (Hetzner data center, east coast) mirror of
> bordeaux.guix.gnu.org:
>
>   https://bordeaux-us-east-mirror.cbaines.net/
>
> So, I'd also be interested in seeing how that performs for people, and
> how it compares against bordeaux.guix.gnu.org, which is hosted in France
> in Europe.
>
> Here's my output from wget:
>
>   → wget 
> https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   --2022-05-20 16:50:44--  
> https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   Resolving bordeaux-us-east-mirror.cbaines.net 
> (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48
>   Connecting to bordeaux-us-east-mirror.cbaines.net 
> (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected.
>   HTTP request sent, awaiting response... 200 OK
>   Length: 208615205 (199M) [text/plain]
>   Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’
>
>   078vr3r8mn3yrwzwxw64 100%[==>] 198.95M  4.17MB/sin 
> 47s
>
>   2022-05-20 16:51:32 (4.22 MB/s) - 
> ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’ saved 
> [208615205/208615205]
>
>
> Now, performance is probably a bit more complicated than just download
> speed. The US mirror holds the narinfo information locally, which should
> enable it to respond to requests more quickly, reducing latency, but
> this is a little harder to test.
>
> Thanks,
>
> Chris

Re: libvirt: A potential problem in the package and looking for guidance

[Maxime Devos]

Allan Adair schreef op ma 23-05-2022 om 21:44 [+0200]:
> (define-public libvirt-with-qemu-bridge-helper
>   (package
>     (inherit libvirt)
>     (name "libvirt-with-qemu-bridge-helper")

This fixes only a variant of the libvirt library itself, it doesn't
cause your modified  version to be used. You may need to modify the
package definition of 'libvirt' instead.  Another method is to set the
'libvirt' field of 'libvirt-configuration' to your 'libvirt-with-qemu-
bridge-helper'.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: see which X11 config is being used

[Théo Maxime Tyburn]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Théo Maxime Tyburn  skribis:
>
>> thanks, that helped! I just learned by scrolling the guix-devel archives
>> that log files are conventionaly gathered in /var/log in guix. I wasn’t
>> aware of that. Is it documented somewhere ?
>
> I don’t think it’s documented; it’s a traditional Unix convention I
> think.

Yes it seems indeed. I have somehow missed that.

>Perhaps we should explain it somewhere in the manual, maybe next
> to ‘syslog-service-type’?

What about:

Following the Unix tradition, logs are generally put in
/var/log/. This is for exemple the case for the logs from Xorg, slim, mcron, 
lightdm,
gdm, and docker.

I am not sure where to put it though. Under Services for sure. Near syslog 
could make sense
but at the same time it is not where I would have looked. Also syslog
doesn’t determines where logs from all these programs are put. Or does
it? If not, maybe it could have a place directly on the Services page.

This is the content of %default-syslog.conf

--8<---cut here---start->8---
# Log all error messages, authentication messages of
# level notice or higher and anything of level err or
# higher to the console.
# Don't log private authentication messages!
*.alert;auth.notice;authpriv.none   /dev/console
 
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none  /var/log/messages
 
# Like /var/log/messages, but also including "debug"-level logs.
*.debug;mail.none;authpriv.none /var/log/debug
 
# Same, in a different place.
*.info;mail.none;authpriv.none  /dev/tty12
 
# The authpriv file has restricted access.
authpriv.*  /var/log/secure
 
# Log all the mail messages in one place.
mail.*  /var/log/maillog
--8<---cut here---end--->8---

Or maybe it could be even better to have a page where all the
similarities and particularities of guix are listed. Like what follows
the Unix convention and what doesn’t. Maybe the list of what follows
the Unix convention would be too long, but the particuliarities would
surely be nice to have.

>
> Thanks,
> Ludo’.

Cheers,
Théo

Re: libvirt: A potential problem in the package and looking for guidance

[Allan Adair]

Thanks! Looks like I was on a good track. The only reference that I could
find to /usr/libexec/qemu-bridge-helper was in the meson.build file of the
libvirt package. I wrote a package variant that looks like this, to test:

(define-public libvirt-with-qemu-bridge-helper
  (package
(inherit libvirt)
(name "libvirt-with-qemu-bridge-helper")
(arguments
 (substitute-keyword-arguments (package-arguments libvirt)
   ((#:phases phases)
#~(modify-phases #$phases
;; libvirt needs to be able to find qemu's bridge helper
;; this is hacky, perhaps a patch on meson.build would be
better.
(add-after 'unpack 'find-qemu-bridge-helper
  (lambda* (#:key inputs #:allow-other-keys)
(let* ((qemu (assoc-ref inputs "qemu")))
  (substitute* "meson.build"
(("/usr/libexec/qemu-bridge-helper")
 (format #f "~a/libexec/qemu-bridge-helper"
qemu))
(inputs
 (modify-inputs (package-inputs libvirt)
(append qemu)

However the effort was fruitless, and my efforts on this are currently on
pause. If I am able to fix it I plan to submit a patch.

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi,

Am Montag, dem 23.05.2022 um 16:14 +0300 schrieb Andrew Tropin:
> The discussion seems too heated and bloated, it's hard to reasonably
> address arguments mentioned around, so I'll just post some thoughts
> and a possible way to somehow proceed.
> 
> I suggest to split the bigger idea into smaller pieces, play with the
> implementation locally/in fork/branch and see how it goes:
> 
> 1. home-profiles-paths-service-type.  It will allow to add code for
> sourcing profiles in setup-environment script and thus implement
> workflows with multiple profiles.  Such profiles can be managed
> externally or in the future built as a part of home environment.
How about home-profile-loader-service-type as a name instead?  That
would imply that it's purpose is to load profiles.

> 2. home-[additional-]profiles-service-type.  It will allow to build
> profiles from list of packages, optionally add a profile to
> home-profiles-paths.  It will make ~/.guix-
> home/profiles/{emacs,web,etc}
> 
> To make it possible for other service to utilize multiple profiles,
> this service will be extandable with values like that:
> 
> `((default . ,(list curl wget))
>   (web . ,(list browser-ad-block-plugin))
>   (emacs . ,(list emacs emacs-cider emacs-modus-themes)))
I don't think I agree with this choice.  To satisfy both my own use
case of serving profiles in different locations from another and
another issue being raised w.r.t. configuring the location of the
.guix-home profile, I think we should make a triple of location,
optional short name, and manifest (which may be generated from packages
implicitly).  WDYT?

> 3. Maybe migrate ~/.guix-home/profile to ~/.guix-
> home/profiles/default.
Kinda agree, but with the caveat in (2).  Uniformity or chaos should be
a user choice :)

> I still can see a lot of potential problems related to search paths,
> however part of them can be solved by duplicating packages in
> different profiles or using dummy packages like emacs-consumer:
> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56
Or by making search paths first class in manifests, as also discussed
elsewhere.

> [...]
> Liliana, if you still into it, I suggest to start with something
> similiar to what I described above, share the draft implementation
> and intermediate results/impression in a separate thread and continue
> the further discussion.
Considering the above, I think a rough roadmap would be:
1. Implementing home-profiles-service-type (to build the profiles)
2. Implementing home-profile-loader-service-type
3. ???
4. Deprecate the existing home-profile-service-type in favor of the new
profile service type pair and/or implement it in terms of it.
where (1) and (2) could be done by two people/teams in parallel.

Given that the task has been simplified, I think I might start coding
on it, but I can't promise any particular deadline.  At the moment,
both my day job and review work delay any other contributions towards
Guix.

Cheers

Re: wishlist: “repack” generations history of profile

[zimoun]

Hi Ludo,

On Mon, 23 May 2022 at 17:42, Ludovic Courtès  wrote:

> Exactly!  ‘guix pull’ profiles are entirely reproducible: we can rebuild
> them from the output of ‘guix describe’.
>
> So ‘guix gc’ (or something) could automatically remove old generation
> symlinks and instead store the output of ‘guix describe’.  That way,
> ‘--list-generations’ or ‘--switch-generations’ could transparently
> display the info or rebuild the generation.

I have in mind to remove all except the manifest file.

--8<---cut here---start->8---
$ tree -L 1 $(readlink -f ~/.config/guix/current)
/gnu/store/jfnnd975724kdr8q61z4fwabrm4qvzff-profile/
├── bin -> /gnu/store/fnfzidl79gjdki2d8v2ghn6a42n75rqc-guix-58f372776/bin
├── etc
├── lib
├── manifest
└── share

4 directories, 1 file
--8<---cut here---end--->8---

After ’guix gc’ (or something), it would read:

--8<---cut here---start->8---
/gnu/store/jfnnd975724kdr8q61z4fwabrm4qvzff-profile/
└── manifest

0 directories, 1 file
--8<---cut here---end--->8---

And similarly for regular profile, it would become after ’guix gc’ (or
something)

--8<---cut here---start->8---
$ tree -L 1 $(readlink -f ~/.guix-profile)
/gnu/store/3kglj010azkdydsgn6inmxqa3d24yz8a-profile
└── manifest

0 directories, 1 file
--8<---cut here---end--->8---

instead of the 7 directories I get today.


Well, I am not enough familiar with various internals as the SQL
database and the daemon to have an opinion about the technical issues.

Or maybe, it is easier to remove as today but save the relevant
information elsewhere.  WDYT?


> System and Home generations are usually, but not necessarily,
> reproducible: usually the channel info + config file are enough to
> rebuild them, but in theory the config file might refer to resources not
> known to Guix (e.g., SSH key files, modules, whatever).  That said, we
> could arrange so that ‘guix gc -d’ keeps the metadata around.
>
> For regular profiles, we might do the same, but no guarantee we can
> rebuild them, unless all the packages come from the same channels (which
> is the case if the profile was built with ‘guix package -m’).

Yes.  The same limitation as --export-manifest and --export-channels.
Somehow, if the full history is kept, we should be able to reproduce.
However, it could be slow or inefficient.


Today, I manually store the output of “guix describe” before I
manipulate a profile.  This channels.scm output is tracked by Git as
part of my project.  Then I run “git log” to find the previous state of
interest and go back using,

guix time-machine -C channels.scm -- shell -m manifest.scm

which is fine and works well.  Probably the good practise. :-)

Instead of this external tracking, I would like to allow this workflow:

guix package -p project --list-generations
guix package -p project --switch-generation=12

whatever the sysadmin collect about the old generations.


Cheers,
simon

Re: The case for moving raw binaries

[Liliana Marie Prikler]

Am Montag, dem 23.05.2022 um 17:10 +0200 schrieb Ludovic Courtès:
> Hi!
> 
> Liliana Marie Prikler  skribis:
> 
> > "raw binaries" (henceforth rawbins) are the unwrapped binaries that
> > Guix leaves behind in $PACKAGE/bin with the .$WRAPPER-real name. 
> > This practise causes several issues.  For one, those rawbins are
> > visible in the shell by typing a dot and using tab completion. 
> > What's more, in some build systems there might be two (or even
> > more) off them. 
> > This makes a generic wrap after wrap pattern almost impossible to
> > achieve.
> 
> One solution we haven’t yet used to its full potential is ‘wrap-
> script’, an alternative to ‘wrap-program’ that Ricardo added to (guix
> build utils) a while back.
> 
> Its advantage is that it does not create a new file.  It only works
> for scripts, and only in some languages, but using it more widely may
> already improve the situation noticeably.
Speaking of wrap-script, for Guile in particular wouldn't it make sense
to use sh as a wrap-script wrapper with the #! exec hack?

Re: wishlist: “repack” generations history of profile

[zimoun]

Hi Liliana,

On Sat, 21 May 2022 at 13:30, Liliana Marie Prikler  
wrote:

> I think we should implement this as a single --keep=stuff operator,

[...]

> I'm not so sure if I understand the generation bit correctly, but with
> the switch proposed above, you'd --keep=generations, which keeps just
> enough data to make switch-generation work "lazily".

>From my understanding, this operator would add complexity and I am not
convinced that being so fine-grained is necessary.

Basically, the workflow is:

guix package -m foo.scm
guix package -m bar.scm
guix pull
guix package -m baz.scm
guix gc -d 3m
guix pull
guix package -m bong.scm

and “guix gc” potentially remove all of the generation “foo.scm” (say
generation 1).  Instead, I would like to remove the content only to save
space but keep the meta (basically the internal manifest).  This way,
the store would not fully contain the items but it would be possible to
have,

guix package --switch-generation=1

rebuilding the missing items for the generation 1.

Today, it is not possible to keep the history of generations and delete
the store items of old generations.  I am proposing to have an option
for “guix gc” allowing that: keep the history and the ability to switch
and in the same time remove the old items.


Cheers,
simon

Re: Finding a “good” OpenPGP key server

[Maxime Devos]

Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]:
> [... guix refresh -u stuff failing due to not finding the key ...]
> I’m not sure what a good solution is (other than looking for the key
> manually on Savannah or on some random key server).

Alternatively, why use key servers at all?  WDYT of something like

(package
  (name "gnurl")
  [...]
  (properties
;; Keys that are considered ‘trustworthy’ for signing releases
;; of gnurl.
`((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
  ;; Locations of PGP key (possibly with some of them pointing to
  ;; the same key)
  (pgp-key-locations
,(savannah-pgp-key USER-ID) ... ; most signers are on savannah.gnu.org
,(local-file "[...]/someone.pub") ; not easily available from the Web   

"https://rando/key.pub;
"ipfs://.../..." "gnunet://..." ; download key via P2P networks

The first part (permitted-pgp-signing-keys) has been suggested previously and
seems mostly orthogonal, but the second part is new.  It would reduce
the dependency on central infrastructure.  We could consider key servers
to be ‘merely’ another fallback.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

Re: libvirt: A potential problem in the package and looking for guidance

[Maxime Devos]

Ludovic Courtès schreef op ma 23-05-2022 om 17:28 [+0200]:
> Hi,
> 
> Allan Adair  skribis:
> 
> >    File "/gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-
> > 7.9.0/lib/python3.9/site-packages/libvirt.py", line 1353, in create
> >  raise libvirtError('virDomainCreate() failed')
> > libvirt.libvirtError: '/usr/libexec/qemu-bridge-helper' is not a suitable
> > bridge helper: No such file or directory
> > 
> > 
> > Because the package is searching specifically for "/usr/libexec/qemu-
> > bridge-helper", I think this is a bug in the package definition. "/usr"
> > should probably be a prefix from the store, right?
> > 
> > Any comments or suggestions?
> 
> Presumably that “/usr/libexec/qemu-bridge-helper” reference is
> hard-coded in the source.  The solution in situations like this is to
> replace it (using ‘substitute*’) by the absolute file name of the
> corresponding program in /gnu/store.
> 
>   (substitute* "some/file.py"
>     (("/usr/libexec/qemu-bridge-helper")
>  (search-input-file inputs "/bin/qemu-bridge-helper")))

Additionally, you can do
"grep -RF /usr/libexec 
/gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-7.9.0"
in a shell to find the name of the source file to substitutify.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: The case for moving raw binaries

[Maxime Devos]

Ludovic Courtès schreef op ma 23-05-2022 om 17:10 [+0200]:
> One solution we haven’t yet used to its full potential is ‘wrap-script’,
> an alternative to ‘wrap-program’ that Ricardo added to (guix build
> utils) a while back.
> 
> Its advantage is that it does not create a new file.  It only works for
> scripts, and only in some languages, but using it more widely may
> already improve the situation noticeably.

Some time ago I wrote a variant of 'wrap-script' for perl scripts -- it
supported adjusting the load paths without touching any environment
variables, so it doesn't interfere with subprocesses (in contrast to
'wrap-program'), but setting arbitrary environment variables is not
(yet) supported.  It wasn't suitable for general usage yet and was
unpublished, but if anyone is interested, I could dig through git
branches & stashes to find it again.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Lxqt 1.1.0 < 17

[kiasoc5]

The newest version of lxqt is 1.1.0, which was released in April [1].

The version of the lxqt metapackage in guix is 17. I think this refers to 
0.17.0 which was an older release. Wanted to mention this for whoever wants to 
update it, since (I think?) guix does not allow downgrades (1.1.0 < 17).

Thanks!

1. https://github.com/lxqt/lxqt/releases/tag/1.1.0

Re: wishlist: “repack” generations history of profile

[Ludovic Courtès]

Hello!

zimoun  skribis:

> The question is what to do when we delete?
>
> I am proposing to delete the content, i.e., all but keep the meta, i.e.,
> the file manifest.  We could have an option soft (keep meta) and hard
> (remove all, meta included, as today) for guix gc.

Exactly!  ‘guix pull’ profiles are entirely reproducible: we can rebuild
them from the output of ‘guix describe’.

So ‘guix gc’ (or something) could automatically remove old generation
symlinks and instead store the output of ‘guix describe’.  That way,
‘--list-generations’ or ‘--switch-generations’ could transparently
display the info or rebuild the generation.

System and Home generations are usually, but not necessarily,
reproducible: usually the channel info + config file are enough to
rebuild them, but in theory the config file might refer to resources not
known to Guix (e.g., SSH key files, modules, whatever).  That said, we
could arrange so that ‘guix gc -d’ keeps the metadata around.

For regular profiles, we might do the same, but no guarantee we can
rebuild them, unless all the packages come from the same channels (which
is the case if the profile was built with ‘guix package -m’).

Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Kaelyn]

Hi,

--- Original Message ---
On Monday, May 23rd, 2022 at 7:39 AM, Ludovic Courtès  wrote:


> Hi,
>
> Ludovic Courtès l...@gnu.org skribis:
>
> > Anyway, the situation is confusing; there’s no point in having two
> > slightly different variants. I suggest we check with Alex off-list to
> > get a better understanding of what they want. Worst case, we can
> > cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
> > in discussions around Emacs-Guix or Guix development.
>
>
> Emailed Alex off-list and didn’t get a reply.
>
> So we’re on our own like grownups, but that’s fine, I’m sure we’ll
> manage. :-)
>
> First, we need to cherry-pick relevant commits from gitlab.com. Any
> takers? If you Giovanni or anyone else is willing to help, we can grant
> commit access so we share the work. Another way to help is by listing
> commits that should be applied.
>
> Volunteers?

I'd be happy to help with the efforts! I just took a few minutes and checked 
both repos out into a single working tree, and there aren't many commits unique 
to each repository. The official savannah repo has 5 commits since they 
diverged, with the 3 oldest looking like variations of the 6 oldest in the 
gitlab repo. Likewise, not counting the 6 just mentioned, there are 4 unique 
commits in the gitlab repo. Those 4 commits are:

* c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
'guix-package-use-name-at-point' variable (12 months ago)
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
ago)
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
months ago)
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' 
command (1 year, 3 months ago)

Cheers,
Kaelyn

P.S For full reference, the remotes are:
gitlab  https://gitlab.com/emacs-guix/emacs-guix.git
officialgit://git.savannah.gnu.org/guix/emacs-guix.git

`git merge-base gitlab/master official/master` returns the hash:
41fba4eec845e050be92bfe76c0f7980bbe821bd

The commits since the merge-base in the savannah repo:
* c9c5cb0 - (HEAD -> master, official/master) elisp/profiles: Support Home 
profiles. (3 months ago)
* 94fcf1f - elisp/prettify: Recognize "/zstd" in nar URLs. (4 months 
ago)
* 825ab77 - Remove all references to the GuixSD name. (1 year, 4 months 
ago)
* a42f66c - elisp: Support geiser @0.12.x (1 year, 4 months ago)
* d61d827 - scheme: Remove @@ for Guile 3.x support. (1 year, 4 months 
ago)

And the commits in the gitlab repo since the merge-base:
* c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add 
'guix-package-use-name-at-point' variable (12 months ago)
* e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months 
ago)
* 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 
months ago)
* fbc2bbc - elisp/ui-package: Use thing at point for 'guix-packages-by-name' 
command (1 year, 3 months ago)
* 057e3a6 - Remove all references to the "GuixSD" name (1 year, 4 months 
ago)
* bb2a053 - elisp/repl: Support geiser 0.12.x (1 year, 5 months ago)
* 753dbb0 - scheme: Remove "@@" from 'log-url' (1 year, 5 months ago)
* 66695d0 - scheme: Remove "@@" from "pack" symbols (1 year, 5 months ago)
* 20cb235 - scheme: Remove "@@" from 'operating-system-firmware' (1 year, 5 
months ago)
* 307aa05 - scheme: Remove "@@" from 'search-path-environment-variables' (1 
year, 5 months ago)

>
> Thanks,
> Ludo’.

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

[Ludovic Courtès]

Hello,

Efraim Flashner  skribis:

> On Sun, May 15, 2022 at 11:22:05PM +0200, Ludovic Courtès wrote:

[...]

>> Yes, so what do you mean?  Should we keep the old 3.3.1 for use on
>> non-x86_64 platforms?  Would that even work?
>
> I'll add 3.4.8 for non-x86_64 platforms and see if I can do something
> about the rust inputs for python-cryptography, to shorten the graph a
> bit and note which crates are "locked" in their current versions.

OK.

>> Besides, since mrustc was updated on ‘staging’, does that new version
>> better support platforms other than x86_64?
>
> I hear we should be able to do aarch64 with our new version of mrustc
> but I haven't tried building it yet on my machines.

On i686 as well maybe?

> I'd leave it as a happy bonus for now and leave aarch64 with the C
> counterparts for this round, rather than relying on the rust bootstrap
> chain, considering how much RAM it can use.

Yup, makes sense.  We can try that eventually on a branch.

Ludo’.

Re: libvirt: A potential problem in the package and looking for guidance

[Ludovic Courtès]

Hi,

Allan Adair  skribis:

>   File "/gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-
> 7.9.0/lib/python3.9/site-packages/libvirt.py", line 1353, in create
> raise libvirtError('virDomainCreate() failed')
> libvirt.libvirtError: '/usr/libexec/qemu-bridge-helper' is not a suitable
> bridge helper: No such file or directory
>
>
> Because the package is searching specifically for "/usr/libexec/qemu-
> bridge-helper", I think this is a bug in the package definition. "/usr"
> should probably be a prefix from the store, right?
>
> Any comments or suggestions?

Presumably that “/usr/libexec/qemu-bridge-helper” reference is
hard-coded in the source.  The solution in situations like this is to
replace it (using ‘substitute*’) by the absolute file name of the
corresponding program in /gnu/store.

  (substitute* "some/file.py"
(("/usr/libexec/qemu-bridge-helper")
 (search-input-file inputs "/bin/qemu-bridge-helper")))

HTH!

Ludo’.

Re: RFC: Configurable placing of the ~/.guix-home symlink

[Ludovic Courtès]

Hi,

EuAndreh  skribis:

>> It would be up to users to make sure then that whatever “home
>> environment profile” they use has its startup files actually loaded.
>
> What do you mean by that?  The user in this case must ensure that
> $HOME_ENVIRONMENT/{setup-environment,on-first-login} are loaded?

Yes, that’s what I meant.  Similar to what one has to do when using
multiple package profiles.

Ludo’.

Re: ‘staging’ branch is open!

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 15 May 2022 at 22:55, Ludovic Courtès  wrote:
>
>> I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST.
>> How does that sound?
>
> LGTM.  The branch is now frozen and receive only fixes, right?

An update: ci.guix wasn’t building much lately due to a bug that was
finally fixed a few days ago:

  https://issues.guix.gnu.org/55441

However, to quote Forest Gump, “shit happens”, and indeed it happened to
us: we lost SSH access to berlin.guix.gnu.org about the time we were
going to reconfigure it so it has that bug fix.

So, while working on it, the schedule itself is frozen.  :-)

Hopefully we’ll get a clearer picture in the coming days…

Ludo’.

Re: see which X11 config is being used

[Ludovic Courtès]

Hi,

Théo Maxime Tyburn  skribis:

> thanks, that helped! I just learned by scrolling the guix-devel archives
> that log files are conventionaly gathered in /var/log in guix. I wasn’t
> aware of that. Is it documented somewhere ?

I don’t think it’s documented; it’s a traditional Unix convention I
think.  Perhaps we should explain it somewhere in the manual, maybe next
to ‘syslog-service-type’?

Thanks,
Ludo’.

Re: The case for moving raw binaries

[Ludovic Courtès]

Hi!

Liliana Marie Prikler  skribis:

> "raw binaries" (henceforth rawbins) are the unwrapped binaries that
> Guix leaves behind in $PACKAGE/bin with the .$WRAPPER-real name.  This
> practise causes several issues.  For one, those rawbins are visible in
> the shell by typing a dot and using tab completion.  What's more, in
> some build systems there might be two (or even more) off them.  This
> makes a generic wrap after wrap pattern almost impossible to achieve.

One solution we haven’t yet used to its full potential is ‘wrap-script’,
an alternative to ‘wrap-program’ that Ricardo added to (guix build
utils) a while back.

Its advantage is that it does not create a new file.  It only works for
scripts, and only in some languages, but using it more widely may
already improve the situation noticeably.

Ludo’.

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR  skribis:

> Oh… thank you so much for your answer! Looks like the proper way to go!
> I'll try to update GnuPG package definition to integrate one or several
> of those patches.
> Or maybe we should first figure out it this is the right thing to do?!
>
> Guix, thoughts!?

I have mixed feelings about applying the patch, dunno.

While discussing this on the Fediverse, I learned two things:

  1. keyserver.ubuntu.com is a reliable key server that includes user
 IDs, so it’s a good choice for ‘guix refresh’ and similar uses;

  2. keys.openpgp.org publishes users IDs if you explicitly consent to
 do so via the web interface at ;
 that doesn’t help much for the ‘guix refresh’ use case though.

Ludo’.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Anyway, the situation is confusing; there’s no point in having two
> slightly different variants.  I suggest we check with Alex off-list to
> get a better understanding of what they want.  Worst case, we can
> cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
> in discussions around Emacs-Guix or Guix development.

Emailed Alex off-list and didn’t get a reply.

So we’re on our own like grownups, but that’s fine, I’m sure we’ll
manage.  :-)

First, we need to cherry-pick relevant commits from gitlab.com.  Any
takers?  If you Giovanni or anyone else is willing to help, we can grant
commit access so we share the work.  Another way to help is by listing
commits that should be applied.

Volunteers?

Thanks,
Ludo’.

antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

[Maxime Devos]

Hi,

I've set up the channel things for the antioxidant repo,
so now you can put the following in channels.scm:

(use-modules (guix ci))

(cons
 (channel
  (name 'antioxidated-packages)
  (url "https://notabug.org/maximed/cargoless-rust-experiments;)
  (introduction
   (make-channel-introduction
"020851ad649480ee4769b77a947642e993ea5956"
(openpgp-fingerprint
 "C1F3 3EE2 0C52 8FDB 7DD7  011F 49E3 EE22 1917 25EE"
 (list (channel-with-substitutes-available
%default-guix-channel
"https://ci.guix.gnu.org;)))


do "guix pull" and "guix shell antioxidated-castor -- castor" to
run a 'castor' build (*) with antioxidant-build-system.  (Warning:
some crates were updated or added without checking the source code
diff for malware!)

(*) A graphical web browser for Gemini using the GTK stack,
implemented in Rust.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2021-10-03 12:50, Liliana Marie Prikler wrote:

> Hi Guix,
>
> it's been a while since the discussion of whether or not to collect
> multiple profiles into a single directory [1].  This suggestion takes
> inspiration from that, but goes a vastly different route.  Instead of
> using environment variables to control Guix, it takes advantage of the
> recently added Guix Home, even if it is still a technical preview.
>
> So, what's the proposition?  I suggest we modify home-profile-service-
> type (or add a new service) such that it takes a list of  
> records instead of a list of packages.  This record would be defined as
>
>   (define-record-type*  home-profile
> make-home-profile home-profile? this-home-profile
> (location home-profile-location) ; string, e.g. $HOME/.guix-profile
> (short-name home-profile-short-name) ; string or #f, if given
>  ; construct a symlink in
>  ; /var/guix/.../per-user/
> (manifest %home-profile-manifest) ;  or #f
> (packages home-profile-packages) ; list of  or #f
>  ; fallback for manifest
> (enabled? home-profile-enabled?) ; boolean, default #t
> [...])
>
>   (define (home-profile-manifest home-profile)
> (or (%home-profile-manifest home-profile)
> (and=> (home-profile-packages home-profile) 
>packages->manifest
>
> On init/reconfigure, `guix home' creates/updates all home-profiles
> which have a home-profile-manifest that is not #f and links them to the
> appropriate locations.  It also creates a shell startup script that
> loads those profiles that are enabled?, even if they have no manifest
> (this can be used to e.g. declare a pull profile, which `guix home'
> can't manage).  
>
> Some existing home services would need to be adapted towards this
> multiple profile usage.  For instance, home-fontconfig-service-type
> would need to accept a list of directories, rather than hardcode its
> value.
>
> What do y'all think?
>
> 
>
>

The discussion seems too heated and bloated, it's hard to reasonably
address arguments mentioned around, so I'll just post some thoughts and
a possible way to somehow proceed.

I suggest to split the bigger idea into smaller pieces, play with the
implementation locally/in fork/branch and see how it goes:

1. home-profiles-paths-service-type.  It will allow to add code for
sourcing profiles in setup-environment script and thus implement
workflows with multiple profiles.  Such profiles can be managed
externally or in the future built as a part of home environment.

2. home-[additional-]profiles-service-type.  It will allow to build
profiles from list of packages, optionally add a profile to
home-profiles-paths.  It will make ~/.guix-home/profiles/{emacs,web,etc}

To make it possible for other service to utilize multiple profiles, this
service will be extandable with values like that:

`((default . ,(list curl wget))
  (web . ,(list browser-ad-block-plugin))
  (emacs . ,(list emacs emacs-cider emacs-modus-themes)))

3. Maybe migrate ~/.guix-home/profile to ~/.guix-home/profiles/default.
  
I still can see a lot of potential problems related to search paths,
however part of them can be solved by duplicating packages in different
profiles or using dummy packages like emacs-consumer:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56

Also, I can see potential complication of Guix Home in general due to
multiple profiles capabilities and I still not sure that it worth the
benefits mentioned below:

I agree that multiple profiles can be benifitial for both better package
organization/structuring needs and faster build/reconfigure times.

I also see some demand from people requesting such a feature.

Liliana, if you still into it, I suggest to start with something
similiar to what I described above, share the draft implementation and
intermediate results/impression in a separate thread and continue the
further discussion.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature