bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[Liliana Marie Prikler]

Hi

Am Donnerstag, dem 20.01.2022 um 00:03 + schrieb John Hamelink:
> Hi there,
> 
> I'm experiencing an issue with the emacs-next package on my Guix
> foreign setup where the cursor (*not* Emacs point) is very dark. It's
> perfectly legible against the default Emacs theme, but nonetheless it
> is not respecting the settings of the rest of my system. To make
> things worse, I'm currently using (and enjoying!) the modus-vivendi
> theme.
> 
> My host machine is running Arch GNU/Linux with a tiling window
> manager. I set my cursor style using xsetroot like so:
> 
> xsetroot -xcf /usr/share/icons/Adwaita/cursors/left_ptr 16
Corrected your xsetroot invocation there :P

> I tried installing the adwaita-icon-theme, gnome-themes-standard, and
> gnome-themes-extra packages in an attempt at installing the correct
> theme, but that didn't help.
> 
> I'm not entirely sure what the issue is, but after speaking with some
> folks at #guix, it was suggested to me that this may in fact be a
> bug. The other option discussed is that Guix needs its own cursor
> settings, but I'm too early on in my journey with Guix (maybe 2 hours
> of experience using the Guix binary) to know how set that up - if that
> is indeed the case, some pointers on what to read would be very
> warmly received!
It turns out this issue is actually related to another issue of Guix'
Emacs on foreign distros, which is it not finding timezones.  Since
I've found a permanent solution to both, I will close that bug and pat
myself on the back for doing so.

The main issue here is that foreign distros with systemd really cut
down on their use of environment variables, whereas Guix (System) makes
prominent use of them.  In the case of the other bug, TZDIR was unset,
in the case of yours it was XCURSOR_PATH.

Writing an override configuration file with the following contents

--8<---cut here---start->8---
# ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf
[Service]
Environment=TZDIR='/usr/share/zoneinfo'
Environment=XCURSOR_PATH='/usr/share/icons'
--8<---cut here---end--->8---

fixed this for me, although I should specify that I previously only had
TZDIR set and bound XCURSOR_PATH interactively in the shell (I am
typing this just as I found the fix and haven't yet had the opportunity
to restart my X session).

Now one thing I don't quite get is the interaction with GNOME Shell. 
With my current setup as detailed above, Emacs inherits whichever
cursor was set in GNOME at the time of launch for the entire process
duration -- i.e. even if the corresponding GNOME setting changes.  
I'm pretty sure in your setup with xsetroot there's nothing else
setting the cursor, so it ought to be displayed correctly after that. 
If not, you might have to play around with cursor themes in other ways
(refer to [1]).

Cheers


[1] https://wiki.archlinux.org/title/Cursor_themes

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 09:03 + schrieb John Hamelink:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > It turns out this issue is actually related to another issue of
> > Guix' Emacs on foreign distros, which is it not finding timezones. 
> > Since I've found a permanent solution to both, I will close that
> > bug and pat myself on the back for doing so.
> 
> Allow me to join in! That worked perfectly for me. Thank you :)
Good to hear.  Note that you can also write to bug-d...@debbugs.gnu.org
yourself, you don't need my permission to do so ;)  Anyway, done.

In order to avoid future instances of this issue, we should probably
drop a paragraph or two about it in the manual or (more likely) the
cookbook.  I'll get to that when I do.

Cheers

bug#48300: Emacs cursor theme is not inherited from the OS when using foreign Guix

[John Hamelink]

Hi Liliana,


Liliana Marie Prikler  writes:

> It turns out this issue is actually related to another issue of Guix'
> Emacs on foreign distros, which is it not finding timezones.  Since
> I've found a permanent solution to both, I will close that bug and pat
> myself on the back for doing so.

Allow me to join in! That worked perfectly for me. Thank you :)

Best,
JH


signature.asc
Description: PGP signature

bug#53339: [version-1.4.0] Package with texlive-updmap.cfg and texlive-amsfonts failing to find Euler

[Ricardo Wurmus]

elaexuo...@wilsonb.com writes:

> Attached patch on top of version-1.4.0 attempts to typset PDF docs for the
> metamath package. However, the below error results, which seems to indicate
> that the Euler fonts are not found, despite texlive-amsfonts existing in the
> texlive-updmap.cfg input.
>
> 
> (/gnu/store/s952x1vkbbcprklzlzimn3m2dn53mjx9-texlive-amsfonts-59745/share/texmf-dist/tex/latex/amsfonts/ueuf.fd)
> kpathsea: Running mktextfm eufm10
> mkdir: cannot create directory ?././homeless-shelter?: Permission denied
> mktextfm: mktexdir 
> /homeless-shelter/.texlive2021/texmf-var/fonts/tfm/ams/euler failed.
> kpathsea: Appending font creation commands to missfont.log.
> 
> ! Font U/euf/m/n/10=eufm10 at 10.0pt not loadable: Metric (TFM) file not 
> found.
> 

This is a problem with the texlive-amsfonts package.  The tlpdb says
that it should provide eufm10.tfm, but it doesn’t.

We’re building the fonts from source:

--8<---cut here---start->8---
   ;; Frustratingly, not all fonts can be created this way.  To
   ;; generate eufm8.tfm, for example, we first scale down
   ;; eufm10.afm to eufm8.pl, and then generate the tfm file 
from
   ;; the pl file.
   (setenv "TEXINPUTS"
   (string-append ":" build "//:"
  (getcwd) 
"/fonts/afm/public/amsfonts//:"
  (getcwd) "/source/latex/amsfonts//:"))
   (with-directory-excursion build
 (for-each (match-lambda
 (((target-base target-size)
   (source-base source-size))
  (let ((factor (number->string
 (truncate/ (* 1000 target-size)
source-size
(invoke "tex"
"-interaction=scrollmode"
(string-append "\\input 
fontinst.sty "
   "\\transformfont{" 
target-base "}"
   "{\\scalefont{" 
factor "}"
   "{\\fromafm{" 
source-base "}}} "
   "\\bye")))
  (invoke "pltotf"
  (string-append target-base ".pl")
  (string-append target-base ".tfm"))
  (delete-file (string-append target-base 
".pl"

   '((("eufm8" 8) ("eufm10" 10))

 (("eufb6" 6) ("eufb7" 7))
 (("eufb8" 8) ("eufb10" 10))
 (("eufb9" 9) ("eufb10" 10))

 (("eufm6" 6) ("eufb7" 7))
 (("eufm9" 9) ("eufb10" 10))

 (("eurb6" 6) ("eurb7" 7))
 (("eurb8" 8) ("eurb10" 10))
 (("eurb9" 9) ("eurb10" 10))

 (("eurm6" 6) ("eurm7" 7))
 (("eurm8" 8) ("eurm10" 10))
 (("eurm9" 9) ("eurm10" 10)
--8<---cut here---end--->8---

As you can see, we’re not building eufm10.tfm from the pl file.  Oops.
Fixing this is easy, but any change to texlive-amsfonts will require
rebuilding the world — unless we use grafts.

We can avoid these problems by checking that all texlive packages
produce all the outputs that the tlpdb specifies.  The texlive importer
already works with the tlpdb; we’d just need some sort of automatic
test.  We could do this as part of an optional build phase.

-- 
Ricardo

bug#53369: guix pull command fails on a torified bash shell

[Maxime Devos]

Girish schreef op wo 19-01-2022 om 15:47 [+]:
> When I run `guix pull` command the following error is generated:
> 
> In procedure scm_lreadr: #:16:144: Unknown # object: #\<

Does it only print that, or is there also some backtrace?
To investigate the issue, the backtrace would be useful.

Greetings
Maxime.


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

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P . de Morais Neto via Bug reports for GNU Guix]

Hello.  So the solution to the bug is for the user to manually write the
file ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf ?

I would like to know a little more about that.  What is the advantage of
specifying the environment variables on that file instead of ~/.profile?

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 08:27 -0300 schrieb Jorge P.de Morais
Neto:
> Hello.  So the solution to the bug is for the user to manually write
> the file ~/.config/systemd/user/gnome-shell-
> x11.service.d/override.conf ?
> 
> I would like to know a little more about that.  What is the advantage
> of specifying the environment variables on that file instead of
> ~/.profile?
> 
> Kind regards,
>   Jorge
In my personal experience, the value did not get sourced correctly when
I put it into .bash_profile.  I do not know about .profile, but I guess
you'll run into similar issues.  In either case, evaluation order is
something you might want to consider.

Now the advantage of doing this at all is that you get finer control
over which environment variables are set when.  It doesn't really make
sense to e.g. set the font path when you're in a terminal.  The
disadvantage is that it's obscure and brittle -- the value TZDIR will
only be correctly set inside GNOME in this example, for other desktop
environments you'd have to copy the definitions.  What if you're
launching just a terminal session?  Don't ask me.

I'm pretty sure there's some systemd file where you can put these
instead, but in the years of using it up to encountering Guix I've
never needed such a thing and now that I do use Guix, I'm quite content
with Shepherd as my PID 1.  I still remember some of systemd's major
features that I miss from shepherd, like socket activation or the
ability to control GNOME Shell at all, but ask me about some incredibly
mundane task like setting a timer and I'll have to consult a manual on
that.

Cheers

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P . de Morais Neto via Bug reports for GNU Guix]

I have defined TZDIR on ~/.profile and so far it's working.  Let's see
if it continues to work well.

And how will other users know how to fix the problem?  Will Guix's
manual be updated?  There could also be a message in the Emacs package
description.

Regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

bug#53368: .guix-authorizations 'version' field documentation

[Maxime Devos]

Hi,

Christopher Rodriguez schreef op wo 19-01-2022 om 09:40 [-0500]:
> Hey all,
> 
> I've just been able to clone my authenticated personal repository for
> the first time in a few weeks because I was confusing the `version`
> field of `(authorizations …` to be a file version field as opposed to
> the version of the API being used.
> 
> For clarity, I'm working on a patch that will edit the section of the
> manual to clearly specify that this is the API version (will submit
> soon). It currently has a comment in the example source that reads
> "current file format version", which lead me to this mistake. Nowhere
> else in the text is the `version` field mentioned.
> 
> However, as a Lisper, I feel as though the symbol itself could easily
> be more descriptive by using `api-version` or something similar rather
> than just a generic `version`. It would help prevent other newcomers
> from going through the confusion I've just had.
> 
> What do You think?

'version' does denote a file format version.  Calling it an API version
is somewhat inaccurate, because it is not a application _programming_
interface -- you can't write Scheme code in .guix-authorizations,
only S-exps that match the file format.

While it is the version of the file format, it is not the version of
the file, which I believe is were the confusion came from?

Also, changing 'version' to 'api-version' would probably prevent old
versions of Guix (that only recognise 'version') from pulling new
versions of Guix (that would have an 'api-version' in their
.guix-authorizations) (untested).

Greetings,
Maxime.


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

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P . de Morais Neto via Bug reports for GNU Guix]

Hi.
Em [2022-01-20 qui 13:59:55+0100], Liliana Marie Prikler escreveu:

> Updating package descriptions with a list of quirky annoyances on
> foreign distros is surely overkill.  We don't even put CVEs in there,
> instead describing those to ignore in a property.

What "property" is that?  I am interested in knowing about CVE in Guix
packages.

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

bug#53380: Screenshot of backtrace

[Mathieu Othacehe]

Hello,

> I could not copy the text so sending the screenshot from my phone.

Thanks for the report. Did you use the 1.3.0 release installer? If yes
could you please try the latest installer available here:
https://guix.gnu.org/en/download/latest/ and report back?

Mathieu

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 09:29 -0300 schrieb Jorge P.de Morais
Neto:
> I have defined TZDIR on ~/.profile and so far it's working.  Let's
> see if it continues to work well.
> 
> And how will other users know how to fix the problem?  Will Guix's
> manual be updated?  There could also be a message in the Emacs
> package description.
By reading the manual (or cookbook).  Updating package descriptions
with a list of quirky annoyances on foreign distros is surely overkill.
We don't even put CVEs in there, instead describing those to ignore in
a property.

I'll write up an appropriate entry once I've figured out how I want to
word it.  However, I'd like to also state for the record, that a lack
of such is not really a bug in Guix.  Applications packaged in Guix not
only honour the environment variables they're supposed to honour, they
sometimes even have more of them.  The trouble comes from implicit
defaults being assumed (and therefore not set) by the foreign distro.

Cheers

bug#41603: How To Resolve "guile: warning: failed to install locale"

[Rostislav Svoboda]

> It seems the local build aspect is broken for me for glibc-locales so to
> solve this, as root I did:
>
> # guix archive --authorize < \
>  ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
>
> It seems to have fixed my issue.

Confirming. Executing `guix archive ...` helps. However there's no
ci.guix.gnu.org.pub under that path. In my case the
ci.guix.gnu.org.pub I used is:

sha256sum $(find /root/.cache/ -name ci.guix.gnu.org.pub)
0f7e51614eac75353196b650e73b7b559824b0f78935da0d6717ddd1792f
/root/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/substitutes/ci.guix.gnu.org.pub

(Be careful, I must admit I don't really know what I've been doing
with that `guix archive` command).

And then the commands I executed are:

sudo su  # become root
guix archive --authorize < $(find /root/.cache/ -name ci.guix.gnu.org.pub)
exit # exit the root shell
guix pull# not sure if this is needed, but it shouldn't do any harm
guix install glibc-locales

bug#53397: --dry-run not effective on 'guix pull'

[Maxim Cournoyer]

Hello,

The 'guix pull' command a --dry-run option, per "guix pull --help", but
it doesn't work:

--8<---cut here---start->8---
$ guix pull --commit=1995920f687020720d22bf8656fdde5ea1908747 --dry-run
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'sfl-packages' from Git repository at 
'https://gitlab.com/Apteryks/sfl-guix-channel'...
Building from these channels:
  sfl-packageshttps://gitlab.com/Apteryks/sfl-guix-channel  6385881
  guix  https://git.savannah.gnu.org/git/guix.git   1995920
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building 
/gnu/store/z3s04zx6cncpfffqhg1g8fkzyiiran54-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... |^C
--8<---cut here---end--->8---

Thanks,

Maxim

bug#53326: snap: Fails to build (hash mismatch)

[Maxime Devos]

Nicolas Goaziou schreef op di 18-01-2022 om 14:21 [+0100]:
> Hello,
> 
> Maxime Devos  writes:
> 
> > Since 'snap' has a history of mutating tags in-place, maybe it would
> > would be a good idea to replace (string-append "v" version) with the
> > actual commit string (and not a tag name), to avoid future breakage
> > and help "guix time-machine" users?
> 
> AFAIK, this is the first time it happens for this project. I'd rather
> keep tags for now and revisit that decision if it happens again.
> 
> WDYT?

Personally, I would change to commits after the first time it happens,
to avoid having to keep count.

Anyway, I asked upstream 
whether this will happen again.  Let's wait for a response?

Greetings,
Maxime.


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

bug#53326: snap: Fails to build (hash mismatch)

[Nicolas Goaziou]

Hello,

Maxime Devos  writes:

> Anyway, I asked upstream 
> whether this will happen again.  Let's wait for a response?

Upstream answered. It was an exception. So I guess all is fine.

Thanks for bringing it up to upstream.

Regards,
-- 
Nicolas Goaziou

bug#36667: (No Subject)

[Attila Lendvai]

Empty Message

bug#53397: --dry-run not effective on 'guix pull'

[Maxim Cournoyer]

Hi again,

Maxim Cournoyer  writes:

> Hello,
>
> The 'guix pull' command a --dry-run option, per "guix pull --help", but
> it doesn't work:
>
> $ guix pull --commit=1995920f687020720d22bf8656fdde5ea1908747 --dry-run
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Updating channel 'sfl-packages' from Git repository at 
> 'https://gitlab.com/Apteryks/sfl-guix-channel'...
> Building from these channels:
>   sfl-packageshttps://gitlab.com/Apteryks/sfl-guix-channel  6385881
>   guix  https://git.savannah.gnu.org/git/guix.git   1995920
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> building 
> /gnu/store/z3s04zx6cncpfffqhg1g8fkzyiiran54-compute-guix-derivation.drv...
> Computing Guix derivation for 'x86_64-linux'... |^C

It seems I should have been a bit more patient.  The full command read
as:

--8<---cut here---start->8---
$ guix pull --commit=1995920f687020720d22bf8656fdde5ea1908747 --dry-run
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'sfl-packages' from Git repository at 
'https://gitlab.com/Apteryks/sfl-guix-channel'...
Building from these channels:
  sfl-packageshttps://gitlab.com/Apteryks/sfl-guix-channel  6385881
  guix  https://git.savannah.gnu.org/git/guix.git   1995920
Computing Guix derivation for 'x86_64-linux'... -

 \
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivations would be built:
   /gnu/store/y89p6mxyng59ql27bzkz6mpl29f4d42a-profile.drv
   /gnu/store/0zfzgpdir6xhnwhnshlam85mcld7ynnb-sfl-packages.drv
   /gnu/store/25rvqdz96f16hqnhlli6aajhcap70k40-guix-1995920f6.drv
   /gnu/store/ijail6rcqvl3nl115qwka2whn8l5mi24-guix-daemon.drv
   /gnu/store/wnr4j0hcjcfzcxc8jd8k44av5982nir2-guix-command.drv
   /gnu/store/dvlcml6mk0iy7zfjwyc3md0ahw6gghvd-guix-module-union.drv
   /gnu/store/yvisngmzfq2hprmhbwi1671y10zswmvh-guix-1995920f6-modules.drv
   /gnu/store/p5b0y71lhmlsga7f643acgcw50klr34q-guix-config-modules.drv
   /gnu/store/qvxcm42f8bdzj62l34jhyd53kci695mb-guix-config-source.drv
   /gnu/store/wjimxiq7npfrdhyzw61q50x6392pfc7c-config.scm.drv
   /gnu/store/slzxkifcrwx6vn1q0dkjgfsfbkij3hpy-guix-config.drv
   /gnu/store/pf123iw6bmf9c19lim91p4m16r0b9gl8-guix-core-modules.drv
   /gnu/store/zsrz3yk8r8261svnk80sd4407vn70wpq-guix-packages-modules.drv
   /gnu/store/ach8s5bsb30n04v584fnhfiq83nrkiy6-inferior-script.scm.drv
   /gnu/store/2ykcwnrmypv2sywjlqi548sjs3k3n47v-profile.drv
   /gnu/store/31p0x6jps8l8p7z5kkkncj8mpca9pyz6-inferior-script.scm.drv

2.2 MB would be downloaded
--8<---cut here---end--->8---

So the derivations had to be computed before the build plan could be
printed (which makes sense in retrospect).

Apologies, closing!

Maxim

bug#53339: [version-1.4.0] Package with texlive-updmap.cfg and texlive-amsfonts failing to find Euler

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> elaexuo...@wilsonb.com writes:
>
>> Attached patch on top of version-1.4.0 attempts to typset PDF docs for the
>> metamath package. However, the below error results, which seems to indicate
>> that the Euler fonts are not found, despite texlive-amsfonts existing in the
>> texlive-updmap.cfg input.
>>
>> 
>> (/gnu/store/s952x1vkbbcprklzlzimn3m2dn53mjx9-texlive-amsfonts-59745/share/texmf-dist/tex/latex/amsfonts/ueuf.fd)
>> kpathsea: Running mktextfm eufm10
>> mkdir: cannot create directory ?././homeless-shelter?: Permission denied
>> mktextfm: mktexdir 
>> /homeless-shelter/.texlive2021/texmf-var/fonts/tfm/ams/euler failed.
>> kpathsea: Appending font creation commands to missfont.log.
>> 
>> ! Font U/euf/m/n/10=eufm10 at 10.0pt not loadable: Metric (TFM) file not 
>> found.
>> 
>
> This is a problem with the texlive-amsfonts package.  The tlpdb says
> that it should provide eufm10.tfm, but it doesn’t.

It now does.

Commit 374464a3bbd38f43784af0cdf54ddceed93e41bd adds a new
texlive-amsfonts/fixed and adds it to the replacement field of
texlive-amsfonts, so it should be grafted.

> We can avoid these problems by checking that all texlive packages
> produce all the outputs that the tlpdb specifies.  The texlive importer
> already works with the tlpdb; we’d just need some sort of automatic
> test.  We could do this as part of an optional build phase.

Commit 5ecb4acdcb95478c6efe63bf9caa4db6bda82aba implements the most
basic check.  We can’t use it during the build, because tlpdb currently
needs modules that aren’t available on the build side (e.g. those to
build texlive-bin and look up a file it provides), but it can be used in
a REPL:

,use (guix import texlive)
(files-differ? 
"/gnu/store/aiknpz049bqbr73s58yaqk3ln7hq8n4x-texlive-amsfonts-fixed-59745/share/"
 "amsfonts")

This should return the empty list.  As should this, which lists files
that should not have been installed according to the tlpdb:

(files-differ? 
"/gnu/store/aiknpz049bqbr73s58yaqk3ln7hq8n4x-texlive-amsfonts-fixed-59745/share/"
 "amsfonts" #:direction 'extra)

The fixed package installs exactly the files it is supposed to and
nothing more.

Could you please try again?

-- 
Ricardo

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello,

Em quinta-feira, 20 de janeiro de 2022, às 08:27:38 -03, Jorge P.  de 
Morais Neto via Bug reports for GNU Guix escreveu:
> Hello.  So the solution to the bug is for the user to manually write the
> file ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf ?
> 
> I would like to know a little more about that.  What is the advantage of
> specifying the environment variables on that file instead of ~/.profile?

I don’t know if this applies to all distributions, but at least in Ubuntu, 
the GNOME on Wayland and KDE on Wayland desktop sessions are started 
without a shell being invoked at any point, so ~/.profile and related files 
don’t get evaluated.

In KDE, the way to define environment variables that will be set in the 
Wayland session is to put a shell script in ~/.config/plasma-workspace/env/.

I hadn’t figured out how to do it in GNOME when I briefly searched for it. 
This systemd override file seems to be the solution.

-- 
Thanks,
Thiago

bug#53339: [version-1.4.0] Package with texlive-updmap.cfg and texlive-amsfonts failing to find Euler

[elaexuotee--- via Bug reports for GNU Guix]

Ricardo Wurmus  wrote:
> 
> Ricardo Wurmus  writes:
> 
> > elaexuo...@wilsonb.com writes:
> >
> >> Attached patch on top of version-1.4.0 attempts to typset PDF docs for the
> >> metamath package. However, the below error results, which seems to indicate
> >> that the Euler fonts are not found, despite texlive-amsfonts existing in 
> >> the
> >> texlive-updmap.cfg input.
> >>
> >> 
> >> (/gnu/store/s952x1vkbbcprklzlzimn3m2dn53mjx9-texlive-amsfonts-59745/share/texmf-dist/tex/latex/amsfonts/ueuf.fd)
> >> kpathsea: Running mktextfm eufm10
> >> mkdir: cannot create directory ?././homeless-shelter?: Permission 
> >> denied
> >> mktextfm: mktexdir 
> >> /homeless-shelter/.texlive2021/texmf-var/fonts/tfm/ams/euler failed.
> >> kpathsea: Appending font creation commands to missfont.log.
> >> 
> >> ! Font U/euf/m/n/10=eufm10 at 10.0pt not loadable: Metric (TFM) file 
> >> not found.
> >> 
> >
> > This is a problem with the texlive-amsfonts package.  The tlpdb says
> > that it should provide eufm10.tfm, but it doesn’t.
> 
> It now does.

That was quick.

> Commit 374464a3bbd38f43784af0cdf54ddceed93e41bd adds a new
> texlive-amsfonts/fixed and adds it to the replacement field of
> texlive-amsfonts, so it should be grafted.
> 
> > We can avoid these problems by checking that all texlive packages
> > produce all the outputs that the tlpdb specifies.  The texlive importer
> > already works with the tlpdb; we’d just need some sort of automatic
> > test.  We could do this as part of an optional build phase.

Okay. I see that commit on master.
Building again, however, the original problem persists:

! Font U/euf/m/n/10=eufm10 at 10.0pt not loadable: Metric (TFM) file not 
found.

The new texlive-amsfonts/fixed don't need to list eufm10 targets?

> Commit 5ecb4acdcb95478c6efe63bf9caa4db6bda82aba implements the most
> basic check.  We can’t use it during the build, because tlpdb currently
> needs modules that aren’t available on the build side (e.g. those to
> build texlive-bin and look up a file it provides), but it can be used in
> a REPL:
> 
> ,use (guix import texlive)
> (files-differ? 
> "/gnu/store/aiknpz049bqbr73s58yaqk3ln7hq8n4x-texlive-amsfonts-fixed-59745/share/"
>  "amsfonts")
> 
> This should return the empty list.  As should this, which lists files
> that should not have been installed according to the tlpdb:
> 
> (files-differ? 
> "/gnu/store/aiknpz049bqbr73s58yaqk3ln7hq8n4x-texlive-amsfonts-fixed-59745/share/"
>  "amsfonts" #:direction 'extra)
> 
> The fixed package installs exactly the files it is supposed to and
> nothing more.

Both of those files-differ? invocations do indeed return empty lists for me. As 
a
sanity check, I re-confirmed that the document typesets within a texlive --pure
environment. So what gives?

$ guix time-machine --commit=4821e3eb4edd532bb236973a986e609634d0ab28 -- shell 
--pure texlive findutils
bash-5.1$ find -L $GUIX_ENVIRONMENT -name '*eufm10*'
/gnu/store/r0dn677n122jqi3wh0sp3b3kpjavyv2r-profile/share/texmf-dist/fonts/afm/public/amsfonts/euler/eufm10.afm
/gnu/store/r0dn677n122jqi3wh0sp3b3kpjavyv2r-profile/share/texmf-dist/fonts/tfm/public/amsfonts/euler/eufm10.tfm
/gnu/store/r0dn677n122jqi3wh0sp3b3kpjavyv2r-profile/share/texmf-dist/fonts/type1/public/amsfonts/euler/eufm10.pfb
/gnu/store/r0dn677n122jqi3wh0sp3b3kpjavyv2r-profile/share/texmf-dist/fonts/type1/public/amsfonts/euler/eufm10.pfm

but...

$ ./pre-inst-env guix shell texlive-asmfosnts  # on commit 
fad6a742351a599219dabcd152327afc39e4e3cf
$ find -L $GUIX_ENVIRONMENT -name '*eufm10*'
/gnu/store/77vyrxxaa7xn0wfmam20477nakc7v5di-profile/share/texmf-dist/fonts/afm/public/amsfonts/euler/eufm10.afm
/gnu/store/77vyrxxaa7xn0wfmam20477nakc7v5di-profile/share/texmf-dist/fonts/tfm/public/amsfonts/euler/eufm10.tfm
/gnu/store/77vyrxxaa7xn0wfmam20477nakc7v5di-profile/share/texmf-dist/fonts/type1/public/amsfonts/euler/eufm10.pfb
/gnu/store/77vyrxxaa7xn0wfmam20477nakc7v5di-profile/share/texmf-dist/fonts/type1/public/amsfonts/euler/eufm10.pfm

Is my package definition just missing something obvious?

bug#53404: Bash completions provided by nvme-cli producing syntax error

[elaexuotee--- via Bug reports for GNU Guix]

Hello Guix,

Installing nvme-cli into my user profile causes the following error to show at
bash login:

bash: 'intel': syntax error: operand expected (error token is "'intel'")

Starting bash with xtrace enabled places the error at
share/bash-completion/completions/nvme:11:

readonly _plugin_subcmds=(
[intel]="id-ctrl internal-log lat-stats \
set-bucket-thresholds lat-stats-tracking \
...

With a cursory glance, that looks like perfectly valid bash. Sourcing the file
directly produces a different set of errors:

$ guix shell --pure nvme-cli
bash-5.1$ source 
/gnu/store/z3jasjly9s8lmb7scwqbsqfxd0cj5a26-profile/share/bash-completion/completions/nvme
bash: supported-log-pages: command not found
bash: --clear-host-side-blks: command not found
bash: 
/gnu/store/z3jasjly9s8lmb7scwqbsqfxd0cj5a26-profile/share/bash-completion/completions/nvme:
 line 1387: unexpected EOF while looking for matching `"'
bash: 
/gnu/store/z3jasjly9s8lmb7scwqbsqfxd0cj5a26-profile/share/bash-completion/completions/nvme:
 line 1406: syntax error: unexpected end of file

Is anyone else seeing the original error?

Unrelated, but I also notice that the outputs contain dracut definitions. Might
be worth tightening this package up a little?

Cheers,
B. Wilson