Re: simple song named "Guix"

[Felix Lechner via]

Hi Gottfried,

On Fri, May 03 2024, gfp wrote:

> I put the song down in "Musescore 3.6.2"
> and recorded it with "obs"

I hoped to listen to your song again, but the Tuxedo page is no longer
accessible.  Did you upload the song somewhere else?  Thanks!

Kind regards
Felix

Re: Cuirass: Could not find repository

[Richard Sent]

Roman Scherer  writes:

> Hello Guix,
>
> I'm trying to run a Cuirass server for my channels. I have setup
> Cuirass and can build packages in my channels. So far so good.
>
> What I would like to do next is to build a manifest with my channel
> and my modified version of the Guix channel that contains patches that
> aren't upstreamed.

> Do you have any ideas what the problem could be?
>
> Thanks, Roman.
>

If it's of any help, I noticed that when I ran $ guix time-machine -C
channels.scm -- describe, where channels.scm contains:

--8<---cut here---start->8---
;; channels listed in "images" specification
(list (channel
   (name 'guix)
   (url "https://github.com/asahi-guix/guix.git;)
   (branch "main")
   (introduction
(make-channel-introduction
 "f802d404b7229704190c821f89afd987be6a6905"
 (openpgp-fingerprint
  "D226 A339 D8DF 4481 5DDE  0CA0 3DDA 5252 7D2A C199"
  (channel
   (name 'asahi)
   (branch "main")
   (url "https://github.com/asahi-guix/channel.git;)
   (introduction
(make-channel-introduction
 "3eeb493b037bea44f225c4314c5556aa25aff36c"
 (openpgp-fingerprint
  "D226 A339 D8DF 4481 5DDE  0CA0 3DDA 5252 7D2A C199")
--8<---cut here---end--->8---

I got the following error:

--8<---cut here---start->8---
building /gnu/store/29gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv...
/builder for `/gnu/store/29gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv' failed to 
produce output path `/gnu/store/mi8c5dgwiznqwyxcsk0pwnm2a4x52m5g-asahi'
build of /gnu/store/29gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv failed
View build log at 
'/var/log/guix/drvs/29/gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv.gz'.
--8<---cut here---end--->8---

And the log:

--8<---cut here---start->8---
(repl-version 0 1 1)
WARNING: (asahi guix system desktop): imported module (gnu services) overrides 
core binding `delete'
(exception %exception (non-self-quoting 140736755930640 "#< 
components: (#< location: #< file: 
\"/gnu/store/bny0sjiy9cixb8ghhsirlgjkmxf1z001-channel-f020a1a/src/asahi/guix/system/desktop.scm\"
 line: 96 column: 2>> #< format: \"modify-services: service 
'~a' not found in service list\\n\" arguments: (sddm)>)>"))
--8<---cut here---end--->8---

My guess is that's because %desktop-services only conditionally includes
sddm-service-type depending on %current-target-system or
%current-system. See (gnu services desktop). And yet
%gnome-desktop-services unconditionally deletes it.
https://github.com/asahi-guix/channel/blob/main/src/asahi/guix/system/desktop.scm

Perhaps that's relevant, perhaps it's not. I could see it potentially
causing odd behavior, although I can't see how it connects to the error
you observed.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Re: LuaTeX/luaotfload doesn't find any fonts (using fontspec) on Guix?

[Nicolas Goaziou via]

Hello,

Benjamin Slade  writes:

>> This doesn't seem good as the store is not writable.
>
>> I read[¹] that "texmf.cnf" and "texmfcnf.lua" might be misconfigured. In
>> particular, `kpsewhich -var-value=TEXMFCACHE' reports a store location.
>> At the very least, I think TEXMFCACHE in "texmf.cnf" should be set to
>> $TEXMFVAR instead of $TEXMFSYSVAR;$TEXMFVAR as it is the case currently.
>> I'm not sure it will help, tho.
>
> I will try to see if there is anything that can be done in terms of
> local/home configuration.
>
> I wonder if there's a reasonable upstream/Guix fix for the luatex
> package definition.

What I wrote above is actually wrong. $TEXMFSYSVAR does not point to the
store, but to "{/gnu/...", which means "lualatex" creates a "{"
directory in the current working directory. It is silly (and has been
reported already[¹]), but at least the cache can be written to the disk.

I'm not sure yet there's a problem on the Guix side. Font configuration
can be tricky.

[¹]  

Regards,
-- 
Nicolas Goaziou

Re: LuaTeX/luaotfload doesn't find any fonts (using fontspec) on Guix?

[Benjamin Slade]

On Tue, 07 May 2024 19:25:35 +0200 (1 day, 21 hours, 55 minutes ago), Nicolas 
Goaziou  wrote:

> Hello,

Hi Nicolas,

Thanks for this! 


> This doesn't seem good as the store is not writable.

> I read[¹] that "texmf.cnf" and "texmfcnf.lua" might be misconfigured. In
> particular, `kpsewhich -var-value=TEXMFCACHE' reports a store location.
> At the very least, I think TEXMFCACHE in "texmf.cnf" should be set to
> $TEXMFVAR instead of $TEXMFSYSVAR;$TEXMFVAR as it is the case currently.
> I'm not sure it will help, tho.

I will try to see if there is anything that can be done in terms of local/home 
configuration.

I wonder if there's a reasonable upstream/Guix fix for the luatex package 
definition.

I would really like to be able to get this working; I do a lot of work which 
requires LuaTeX and being able to work with additional fonts, and currently 
this means I cannot do this work on any of my Guix machines, it seems.

best,
 —Benjamin
 --
 '(Dr Benjamin Slade (he/him)
 (website . ) 
 `(pgp_fp: ,(B20E 444C FA80 B5F8 15FA  4AD8 6FBF CD68 3B05 2B84))
   "sent by [mu4e] 1.12.5 in [Emacs] 30.0.50 with [org-msg] on 
[EndeavourOS] [Linux]")


[mu4e] 

[Emacs] 

[org-msg] 

[EndeavourOS] 

[Linux] 

Cuirass: Could not find repository

[Roman Scherer]

Hello Guix,

I'm trying to run a Cuirass server for my channels. I have setup
Cuirass and can build packages in my channels. So far so good.

What I would like to do next is to build a manifest with my channel
and my modified version of the Guix channel that contains patches that
aren't upstreamed.

When I do this, I see the following build error:

-
Computing Guix derivation for 'aarch64-linux'...
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/bzl05y4790frz38hv9mj1a0m91451akf-profile.drv
  /gnu/store/rwy6nr20rdc3krkpj45kbr4d3snsqkc0-asahi.drv
  /gnu/store/s8qlz8g581vvhdhh8qrmrpglmq7nndpv-inferior-script.scm.drv
  /gnu/store/wydr6pvfc0llx0d9hq41gn2cyzj8qwc1-profile.drv
The following profile hooks will be built:
   /gnu/store/2v1i8qwsxsin0ssgvjbghqq7hx81kqr4-ca-certificate-bundle.drv
   /gnu/store/8xgz94zkjayz5amxc4f16crxv7qgjda7-fonts-dir.drv
   /gnu/store/9akz81fhpkpz073mgxf5mnabwnpfg30g-info-dir.drv
   /gnu/store/k2f0m1qv0vvm4cz9f21yp1y3i23s513y-guix-package-cache.drv
   /gnu/store/s9nch31jiapln29c03an5sb4gk85yxzj-emacs-subdirs.drv
building path(s) `/gnu/store/ny6s2b4652xmqvjl44ban7ra3398zn7v-asahi'
(repl-version 0 1 1)
WARNING: (asahi guix system desktop): imported module (gnu services) overrides 
core binding `delete'
WARNING: (asahi guix system desktop): imported module (gnu services) overrides 
core binding `delete'
(values (value 
"/gnu/store/ny6s2b4652xmqvjl44ban7ra3398zn7v-asahi/share/guile/site/3.0"))
building path(s) 
`/gnu/store/hkk0778ql8ms9a0w5314s1r15qbvclpn-ca-certificate-bundle'
building path(s) `/gnu/store/29gz6ym8mgkb0qmvzlz5dmjyms4qlgss-emacs-subdirs'
building path(s) `/gnu/store/q6rs8i12gx68h3wcvx6f1pr4ndy5gxbs-fonts-dir'
building path(s) `/gnu/store/wk1hg6kfzgxqz5scimxkxsvv0ab05yyx-info-dir'
building path(s) `/gnu/store/dkb8539cx85833bpnils35shsvnv0bca-profile'
building path(s) 
`/gnu/store/c1wyvrxgwqgm6vsfv8xsgdsdzbq6a1w6-inferior-script.scm'
building path(s) 
`/gnu/store/b878q40rwkmi2b1fyd4aj4z14fpc914x-guix-package-cache'
(repl-version 0 1 1)
Generating package cache for 
'/gnu/store/dkb8539cx85833bpnils35shsvnv0bca-profile'...
(values (value 
"/gnu/store/b878q40rwkmi2b1fyd4aj4z14fpc914x-guix-package-cache/lib/guix/package.cache"))
building path(s) `/gnu/store/xvlilpg0pk9yqj1rhymc4jnh83clx3si-profile'
In thread:
uncaught throw to %exception: (#< arguments: (git-error 
# code: -3 message: "could not find repository at 
'/gnu/store/xphccxyczx2706ikpz77iq10xjpcq9wc-guix-cf5f7a8'" class: 6>>) 
inferior: # stack: ((#f ("ice-9/boot-9.scm" 
1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) (raise-exception 
("ice-9/boot-9.scm" 1684 16)) (#f ("guix/git.scm" 438 13)) 
(update-cached-checkout ("guix/git.scm" 536 29)) (latest-channel-instance 
("guix/channels.scm" 416 18)) (latest-channel-instances ("guix/channels.scm" 
553 23)) (#f ("guix/store.scm" 2053 38)) (#f ("guix/build-system/channel.scm" 
42 2)) (#f ("guix/packages.scm" 2009 11)) (#f ("guix/store.scm" 2009 8)) (#f 
("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 917 13)) 
(run-with-store ("guix/store.scm" 2181 25)) (call-with-build-handler 
("guix/store.scm" 1301 8)) (map/accumulate-builds ("guix/store.scm" 1383 11)) 
(#f ("guix/store.scm" 2066 12)) (#f ("guix/gexp.scm" 912 4)) (#f 
("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 1204 2)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("guix/gexp.scm" 917 13)) 
(run-with-store ("guix/store.scm" 2181 25)) (call-with-build-handler 
("guix/store.scm" 1301 8)) (map/accumulate-builds ("guix/store.scm" 1383 11)) 
(#f ("guix/store.scm" 2066 12)) (#f ("guix/gexp.scm" 912 4)) (#f 
("guix/gexp.scm" 1071 2)) (#f ("guix/gexp.scm" 1204 2)) (#f ("guix/gexp.scm" 
298 22)) (#f ("guix/store.scm" 2009 8)) (#f ("gnu/services.scm" 724 2)) 
(run-with-store ("guix/store.scm" 2181 25)) (call-with-build-handler 
("guix/store.scm" 1301 8)) (map/accumulate-builds ("guix/store.scm" 1383 11)) 
(#f ("guix/store.scm" 2066 12)) (#f ("gnu/services.scm" 431 2)) (run-with-store 
("guix/store.scm" 2181 25)) (#f ("gnu/system.scm" 1661 9)) (#f 
("guix/store.scm" 2053 38)) (#f ("guix/gexp.scm" 298 22)) (#f ("guix/store.scm" 
2009 8)) (run-with-store ("guix/store.scm" 2181 25)) (#f ("gnu/ci.scm" 447 18)) 
(map1 ("srfi/srfi-1.scm" 585 17)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1 
("srfi/srfi-1.scm" 585 29)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (cuirass-jobs ("gnu/ci.scm" 505 4)) (#f 
("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(call-with-prompt ("ice-9/boot-9.scm" 723 2)) (#f (#f #f #f)) (#f 
("guix/repl.scm" 98 21)) 

Re: authenticating git checkouts

[Simon Josefsson via]

Simon Josefsson via  writes:

> jas@kaka:~/src/libntlm$ guix git authenticate
> guix git: successfully authenticated commit 
> a94c085b17dd72904d8913411e1e85477e12
> jas@kaka:~/src/libntlm$ git commit -m"maint: Mention guix git introductory 
> commit." README.md 
> [master 4f64fd9] maint: Mention guix git introductory commit.
>  1 file changed, 8 insertions(+)
> jas@kaka:~/src/libntlm$ guix git authenticate
> Authenticating commits a94cfff to 4f64fd9 (1 new commits)...
> ▕██▏guix
>  git: fel: commit 4f64fd94d5e11b0f9226a3e15cae69ef9fdbb585 not signed by an 
> authorized key: A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2
> jas@kaka:~/src/libntlm$ 

I forgot to show git log output here, proving that this git commit was
actually signed: see below.  I suspect there is some primary vs subkey
confusion, but maybe it could be some parsing issue?  I'm using guix on
Trisquel 11 with fairly old gpg and git.

jas@kaka:~/src/libntlm$ git log -1 --show-signature
commit 4f64fd94d5e11b0f9226a3e15cae69ef9fdbb585 (HEAD -> master)
gpg: Signatur gjord tor  9 maj 2024 10:49:27 CEST
gpg:  med EDDSA-nyckeln A3CC9C870B9D310ABAD4CF2F51722B08FE4745A2
gpg: Korrekt signatur från "Simon Josefsson " 
[förbehållslös]
Author: Simon Josefsson 
Date:   Thu May 9 10:49:27 2024 +0200

maint: Mention guix git introductory commit.
jas@kaka:~/src/libntlm$ 

/Simon


signature.asc
Description: PGP signature

authenticating git checkouts

[Simon Josefsson via]

Hi

I read https://guix.gnu.org/blog/2024/authenticate-your-git-checkouts/
and wondered why I hadn't tried that long ago, but better late than
never, and thanks for writing this blog post to nudge us in the right
direction!

I tried to adopt this approach for the libntlm project, but failed.
Chronological list of first impression thoughts I had:

x) How about introducing an enforcable file-name convention for the key
filenames?  While using human readable names like 'alice.key' looks
nice, it isn't possible to look at content of the filename and determine
what the filename should be.  The filename doesn't appear to convey any
important information, so I think it would be better to have it be
reproducible.  You could use some transliteration of the e-mail address,
but I think there are corner cases here.  So how about merely using the
primary PGP fingerprint value?  For me it would be
B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE.key assuming PGP fingerprints
are specified as case sensitive.

x) How about using ASCII armored PGP blobs instead of binary PGP files
for the *.key files?  While storing binary files in git mostly work
these days, I ran into a CRLF-related problem for a small binary file in
git on Windows lately, so it still seems to happen sometimes.  I tried
this, but it seems 'guix git authenticate' doesn't cope with ASCII
armored PGP keys:

Backtrace:
  12 (primitive-load "/home/jas/.config/guix/current/bin/guix")
In guix/ui.scm:
   2312:7 11 (run-guix . _)
  2275:10 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
  1747:15  7 (with-exception-handler # …)
In guix/scripts/git/authenticate.scm:
   309:10  6 (_)
In guix/git-authenticate.scm:
403:4  5 (authenticate-repository # _ # # …)
In srfi/srfi-1.scm:
   460:18  4 (fold # …)
In guix/git-authenticate.scm:
   255:29  3 (_ _ #< ids: # fingerprints:…>)
In unknown file:
   2 (open-bytevector-input-port #f #)
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:
In procedure open-bytevector-input-port: Wrong type argument in position 1 
(expecting bytevector): #f

x) How about exporting minimal keys rather than keys with a bunch of
signatures on?  This makes the key files a bit more reproducible.  The
downside is that it kills the web-of-trust key authentication process,
so maybe actually recommend NOT using minimal keys?  I'm mixed on this,
and this probably needs more discussion.  Maybe minimizing the keys are
more GDPR-compliant :-)  Doing so also reduces size:

jas@kaka:~/src/libntlm$ gpg --export si...@josefsson.org > jas.key
jas@kaka:~/src/libntlm$ ls -la jas.key 
-rw-rw-r-- 1 jas jas 105243 maj  9 10:28 jas.key
jas@kaka:~/src/libntlm$ gpg --export-options export-minimal --export 
si...@josefsson.org > jas.key
jas@kaka:~/src/libntlm$ ls -la jas.key 
-rw-rw-r-- 1 jas jas 3534 maj  9 10:28 jas.key
jas@kaka:~/src/libntlm$ 

x) How about support of non-PGP formats?  You could put PGP keys in a
sub-directory pgp/foo.key and allow for future expansion as ssh/bar.key
or x509/baz.key etc.

x) The 'name' field in .guix-authenticate doesn't seem to be necessary
at all?  Maybe not even suggest including it.

x) While using s-exp's for .guix-authenticate are fine, I don't think
this will go down well with the git crowd.  How about a yet another YAML
format a'la git?  Let's call it ~/.gitauthenticate:

gpg-introduction-commit = a94c085b17dd72904d8913411e1e85477e12
gpg-introduction-keyid = "B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"
gpg-keyring-branch = gpg-keyring

This could be extended for ssh and x509 too:

ssh-introduction-commit = a94c085b17dd72904d8913411e1e85477e12
ssh-introduction-keyfile = "ssh-ed25519 
C3NzaC1lZDI1NTE5ILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE 
cardno:FFFE42315277"
ssh-keyring-branch = ssh-keyring

x509-introduction-commit = a94c085b17dd72904d8913411e1e85477e12
x509-introduction-keyfile = 0xA7C7D7A7
x509-keyring-branch = x509-keyring

and $someone can write a new tool 'git-authenticate'.

x) Running this command:

guix git authenticate 2e6e8027c75942450a0e4ae0f58e876715782cae "B1D2 BD13 75BE 
CB78 4CF4  F8C4 D73C F638 C53C 06BE"

sets up .git/config properly, but running it again with a different git
commit does not alter .git/config, which was a bit unexpected.  Is this
intentional?  The second invocation exit fine but running 'guix git
authenticate' again failed.  Removing the configuration from .git/config
and re-running both commands made it work, but this feels a bit unsafe.

5) The implementation seems confused by PGP subkeys.  Verifying the
initial commit after adding .guix-authenticate works fine:

jas@kaka:~/src/libntlm$ git log -1 -p 
commit 2e6e8027c75942450a0e4ae0f58e876715782cae (HEAD -> master)
Author: Simon Josefsson 
Date:   Thu