bug#62513: network-manager updated to unstable version?

[John Kehayias via Bug reports for GNU Guix]

Hi Guix,

(cc'ing Maxim as author of last few network-manager version updates.)

I noticed a recent up date to network-manager to 1.43.4 (previously 1.41.2 and 
1.40.0) but can't find a record of that release. In their docs there is no 
mention of anything newer than the 1.42 release [0, 1] and they mention the 
even-numbered releases being the stable series [2]. Indeed, Arch only has 
1.42.4 in their repos [3]. I only see "dev" tags for these 1.43 versions in 
their gitlab.

Should we be on a 1.42.y version instead?

I noticed this because the update to 1.43.4 has an issue with my (wired) 
connection not resuming from sleep when previously it did. I have to restart 
the service. I had some logs I can dig up, but in discussing on IRC (no logs 
that day it seems) there was nothing out of the ordinary and the shepherd 
service seemed normal.

I've since reconfigured to a commit before the most recent version change, 
namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot reproduce the issue 
so seems due to newer versions of network-manager after 1.41.2 at least.

Note that this may have been reported upstream [4], but I haven't tested with 
the current stable release. So this may be a separate (upstream) issue.

Anyway, the first question is what version we should have of network-manager?

Thanks!
John


[0 
]

[1] 

[2] 

[3] 

[4] 

bug#51826: qt packages (e.g. pcmanfm-qt) missing wayland qt module

[Maxim Cournoyer]

Hello,

"bdju"  writes:

> I am running Guix System with Sway
> guix (GNU Guix) 33a80e111096b05af3d60576dfcb2d67099dc60e
>
> Running `QT_QPA_PLATFORM=wayland pcmanfm-qt` results in failure to
> launch and the following errors:
>
> ```
> 21:50:38.413|qt.qpa.plugin|W|Could not find the Qt platform plugin "wayland" 
> in ""
> 21:50:38.413|default|F|This application failed to start because no Qt 
> platform plugin could be initialized. Reinstalling the application may fix 
> this problem.
>
> Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, 
> offscreen, vnc, xcb.
>
> zsh: abort  QT_QPA_PLATFORM=wayland pcmanfm-qt

I believe the modern manifestation of this problem was #57742, now fixed
on the staging branch (see commit e4ef2db8fda85a469a6fc89bf3c46c9d7e8d44ea).

-- 
Thanks,
Maxim

bug#53011: Possible to Update qtbase-5 to v5.15.8?

[Maxim Cournoyer]

Hi,

Jaft  writes:

> Partially because it's the latest version but primarily because there's a bug 
> in the current version for QTwebengine.
> As detailed at r/qutebrowser - Comment by u/The-Compiler on ”WebGL
> blacklisted on Guix”, most text gets broken
> (https://bugs.chromium.org/p/chromium/issues/detail?id=1164975); I
> haven't tried other browsers but I've experienced this with
> Qutebrowser, currently.
> It seems the issue was addressed in QT v5.15.7 so an update to, at least, 
> that would, theoretically, solve the problem.

I've updated the Qt 5 packages to 5.15.8 on staging; feel free to give
it a shot in the next week or so, after which I'll consider merging the
staging branch to master if there are no blockers.

-- 
Thanks,
Maxim

bug#28644: Pulseview with modular qt

[Maxim Cournoyer]

Hi,

phodina  writes:

> Hi,
>
> recently I used Pulseview to debug eMMC issues.
>
> I was also surprised why they are some icons and others are missing.
>
> Based on the code some are implemented as png and some as svg.
>
> I tried to add the qtsvg-5 but it did not work and made the resulting 
> derivation larger.
>
> Therefore there are 2 possibilites:
>
> - Add support for SVG by adding qtsvg-5 and any additional packages [1]
> This would be preferable as the images are displayed in the time series and 
> the bitmaps will look ugly.
>
> 2. Convert all into pngs
> This will save size but will require a big patch (which will be mostly binary)
> What do you think?

Option 1 (simply adding qtsvg-5) sounds more reasonable to me.

-- 
Thanks,
Maxim

bug#57742: QT plugins from profile not found (QT_PLUGIN_PATH)

[Maxim Cournoyer]

Hi,

Antero Mejr  writes:

> This allows extension of QT_PLUGIN_PATH.
> QT programs will now work under Wayland when qt-wayland is installed.
>
> * guix/build/qt-utils.scm (variables-for-wrapping)[QT_PLUGIN_PATH]: Add prefix
> value to 'wrap-program' procedure call for QT_PLUGIN_PATH variable.
> ---
> Tested using Wayland and X (via XWayland), using plugin paths for QT5, QT6, or
> both. In all cases, QT selects the correct plugin if it's present anywhere in
> QT_PLUGIN_PATH.
>
>  guix/build/qt-utils.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/guix/build/qt-utils.scm b/guix/build/qt-utils.scm
> index 2e47f1bc02..b503659521 100644
> --- a/guix/build/qt-utils.scm
> +++ b/guix/build/qt-utils.scm
> @@ -89,7 +89,7 @@ (define exists? (match file-type
>  '("XDG_CONFIG_DIRS" suffix directory "/etc/xdg")
>  ;; We wrap exactly to avoid potentially mixing Qt5/Qt6 components, which
>  ;; would cause warnings, perhaps problems.
> -`("QT_PLUGIN_PATH" = directory
> +`("QT_PLUGIN_PATH" prefix directory
>,(format #f "/lib/qt~a/plugins" qt-major-version))
>  `("QML2_IMPORT_PATH" = directory
>,(format #f "/lib/qt~a/qml" qt-major-version))

Already fixed on my staging :-).

I'll merge staging into master as soon as it catches up to master
according to https://ci.guix.gnu.org/.  Help welcome!

-- 
Thanks,
Maxim

bug#57742: QT plugins from profile not found (QT_PLUGIN_PATH)

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Hello,
>
> Marek Paśnikowski  writes:
>
>> Hello.
>>
>> I found a piece of QT documentation on handling of plugins [1].
>>
>> Is it helpful to achieving working Plasma Desktop on Guix?
>>
>> Maxim - I was able to only find your email address; I don't think the
>> other participants of this Debbugs issue will receive a copy of this
>> message.
>>
>> Best Regards,
>> Marek Paśnikowski
>>
>> [1]: 
>> https://doc.qt.io/qt-6.2/deployment-plugins.html#loading-and-verifying-plugins-dynamically
>
> The upstream bug I had opened,
> https://bugreports.qt.io/browse/QTBUG-107459, has now been closed as
> "Believed not to be a problem.", so it's indeed supposed to work.
>
> I'll try looking into reverting some of the changes made when Qt 6 was
> introduced; there may be warnings, if I recall correctly, but since it's
> advertised as something supported, let's put it to the test!

So I finally tried it in guix/build/qt-utils.scm:

--8<---cut here---start->8---
@@ -87,9 +88,7 @@ (define exists? (match file-type
   "/applications" "/cursors" "/fonts" "/icons" "/glib-2.0/schemas"
   "/mime" "/sounds" "/themes" "/wallpapers")
 '("XDG_CONFIG_DIRS" suffix directory "/etc/xdg")
-;; We wrap exactly to avoid potentially mixing Qt5/Qt6 components, which
-;; would cause warnings, perhaps problems.
-`("QT_PLUGIN_PATH" = directory
+`("QT_PLUGIN_PATH" prefix directory
   ,(format #f "/lib/qt~a/plugins" qt-major-version))
 `("QML2_IMPORT_PATH" = directory
   ,(format #f "/lib/qt~a/qml" qt-major-version))
--8<---cut here---end--->8---

And I see, as I had originally found:

--8<---cut here---start->8---
$ ./pre-inst-env guix shell --pure qtwayland@5 qtbase@5 jami 

[...]

[env]$ echo $QT_PLUGIN_PATH 
/gnu/store/06r23gkwlkzgivf411sk231sbvy5ghcm-profile/lib/qt5/plugins
maxim@hurd ~/src/guix [env]$ jami   
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqeglfs.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqlinuxfb.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqminimal.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqminimalegl.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqoffscreen.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqvnc.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/rpn3knqgk81c27va7bxrpayv0dv5s4kr-qtwayland-5.15.8/lib/qt5/plugins/platforms/libqwayland-egl.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/rpn3knqgk81c27va7bxrpayv0dv5s4kr-qtwayland-5.15.8/lib/qt5/plugins/platforms/libqwayland-generic.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/rpn3knqgk81c27va7bxrpayv0dv5s4kr-qtwayland-5.15.8/lib/qt5/plugins/platforms/libqwayland-xcomposite-egl.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/rpn3knqgk81c27va7bxrpayv0dv5s4kr-qtwayland-5.15.8/lib/qt5/plugins/platforms/libqwayland-xcomposite-glx.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforms/libqxcb.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-maxim'
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platformthemes/libqgtk3.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platformthemes/libqxdgdesktopportal.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
qt.core.plugin.loader: In 
/gnu/store/047ay09ng8kvvbk2h51hbm5mf7x4garg-qtbase-5.15.8/lib/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so:
  Plugin uses incompatible Qt library (5.15.0) [release]
Using Qt runtime version: 6.3.2

(jami

bug#56678: certbot mcron job fails

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Hello,
>
> ‘certbot-service-type’ defines an mcron job that invokes ‘certbot’ with
> a fairly long list of arguments.  However, that command line appears
> to be incorrect, or at least it is on bayfront.guix where I tested it:
>
> ludo@bayfront ~/src/maintenance/hydra$ sudo herd schedule mcron 100|grep -B1 
> certbot
> Thu Jul 21 12:51:00 2022 +0200
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> --
> Fri Jul 22 00:45:00 2022 +0200
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> --
> Fri Jul 22 12:36:00 2022 +0200
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> ludo@bayfront ~/src/maintenance/hydra$ ls -l 
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> -r-xr-xr-x 1 root root 789 Jan  1  1970 
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> ludo@bayfront ~/src/maintenance/hydra$ sudo less 
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> #!/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile 
> --no-auto-compile
> !#
> (begin (use-modules (ice-9 match)) (let ((code 0)) (for-each (match-lambda 
> ((name . command) (begin (format #t "Acquiring or renewing certificate: ~a~%" 
> name) (set! code (or (apply system* command) code) (quote 
> (("bayfront.guix.gnu.org" 
> "/gnu/store/y2n10m4qkyb6vgx980c6jkjd132ln8xx-certbot-1.18.0/bin/certbot" 
> "certonly" "-n" "--agree-tos" "--webroot" "-w" "/var/www" "--cert-name" 
> "bayfront.guix.gnu.org" "-d" 
> "bayfront.guix.gnu.org,bordeaux.guix.gnu.org,logs.guix.gnu.org,bayfront.guix.info,hpc.guix.info,guix-hpc.bordeaux.inria.fr,coordinator.bayfront.guix.gnu.org"
>  "--email" "ludovic.cour...@inria.fr" "--deploy-hook" 
> "/gnu/store/1wj7gy7n8r0nfx2i79afpr7n7xyhyzjx-nginx-deploy-hook" code))
> ludo@bayfront ~/src/maintenance/hydra$ sudo su -c 
> /gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
> Acquiring or renewing certificate: bayfront.guix.gnu.org
> Saving debug log to /var/log/letsencrypt/letsencrypt.log
> Missing command line flag or config entry for this setting:
> Please choose an account
> Choices: ['guix-hpc.bordeaux.inria.fr@2017-09-04T08:51:13Z (48c5)', 
> 'localhost@2016-12-03T21:08:38Z (00bc)']
> Ask for help or search for solutions at https://community.letsencrypt.org. 
> See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with 
> -v for more details.
>
> What should we do about “Please choose an account”?

Apologies for not seeing this one before opening #62491  I guess they
are the same?  If so, let's merge the reports.

-- 
Thanks,
Maxim

bug#56556: TeXlive packaging issues

[Emmanuel Beffara]

Hello Guix,

I would like to share a few thoughts on how TeXlive is currently handled in
Guix. The package `texlive` contains all of TeXlive, it works fine but it is
arguably too big to be practical. The documentation rightfully says

> We recommend using the modular package set because it is much less
> resource-hungry. 

Yet assembling modular sets is problematic for various reasons.

Firstly, unless I am missing something, creating a manifest with the right set
of packages is tedious: one has to guess the Guix package that matches each
LaTeX package, and the correspondence is not obvious. Thankfully, with a
working installation, `tlmgr show something.sty` helps finding the TeXlive
package that contains the file and `guix search texlive something` finds the
corresponding Guix package if there is one (it could be named
`texlive-something` or `texlive-latex-something`, this feels somewhat
inconsistent). When trying to compile a complex document, doing that for every
package and dependency is time-consuming (compile, read compilation errors,
install more packages, restart).

Secondly, many packages are missing. Apparently, `(gnu packages tex)` contains
an arbitrary set of common packages, likely defined by people who needed them
and had the skill to produce a patch for them. It is fairly easy to produce
new definitions using `guix import texlive something` and adjusting the
result, still it feels more complicated than it ought to be. Considering how
well TeXlive is organized, it should be possible to automatically extract the
set of all packages in a given release and turn the result into a big
comprehensive Guile module.

Besides, importing TeXlive "collections" could be a useful intermediate
between taking the whole system and picking packages individually.

Thirdly, formats are apparently not handled right. The main issue is with
hyphenation (hence the cc on an open issue): hyphenation patterns need to be
compiled into the formats to be available in documents, so the format files
should be built depending on which `texlive-hyphen-something` packages are
installed. Currently this is not the case:

```
$ guix shell --pure coreutils texlive-base texlive-latex-base -- /bin/sh -c 
'realpath $GUIX_TEXMF/web2c/pdflatex.fmt'
/gnu/store/m1vh5mm4gjlqzaylfxmxbx5g3j20k8wn-texlive-latex-base-59745/share/texmf-dist/web2c/pdflatex.fmt
$ guix shell --pure coreutils texlive-base texlive-latex-base 
texlive-hyphen-base texlive-hyphen-french -- /bin/sh -c 'realpath 
$GUIX_TEXMF/web2c/pdflatex.fmt'
/gnu/store/m1vh5mm4gjlqzaylfxmxbx5g3j20k8wn-texlive-latex-base-59745/share/texmf-dist/web2c/pdflatex.fmt
```

If the format is always the same, then no modular installation can do any
hyphenation, as reported in https://issues.guix.gnu.org/56556. There might be
other things than hyphenation that require similar treatment.

That said, I don't know what would be the best way to contribute.

-- 
Emmanuel

bug#62163: Suppress logging shepherd evaluation in mcron.log

[Bruno Victal]

Hi Ludo’,

On 2023-03-28 17:25, Ludovic Courtès wrote:
> 
> Nope. :-)  What is ‘my-heartbeat-job’ doing?

It queries shepherd to see if a service is running and sends a restart if 
required.
It looks like this:  (#$task is what will perform the actual checks)

--8<---cut here---start->8---
(define* (heartbeat-supervisor #:key (name #f) service task
   #:allow-other-keys)
  ;; Query service status and restart if needed.
  (program-file
   (format #f "~@[~a-~]heartbeat-supervisor.scm" name)
   (with-imported-modules (source-module-closure
   '((gnu services herd)))
 #~(begin
 (use-modules (gnu services herd)
  (srfi srfi-1))

 (define (is-service-running? sym)
   (lambda (x)
 (and (live-service-running x)
  (memq sym (live-service-provision x)

 (let ((running? (not (null?
   (any (is-service-running? '#$service)
(current-services))
   (when running?
 (case (status:exit-val (system* #$task))
   ((0) #t)
   ((125)
(format #t "Heartbeat worker error~%"))
   (else
(format #t "Issuing restart for service '~a'~%" '#$service)
(restart-service '#$service)

 (exit)
--8<---cut here---end--->8---


This message also shows up if you're using certbot-service-type,
so it's not specific to the snippet above.


Cheers,
Bruno

bug#62163: Suppress logging shepherd evaluation in mcron.log

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Bruno Victal  writes:
>
>> Upon mcron job completion, /var/log/mcron.log is spammed with:
>> “shepherd: Evaluating user expression (and (defined? (quote transient?)) 
>> (map (# ?) ?))”
>>
>> These shepherd lines should be suppressible.
>>
>>
>> /var/log/mcron.log snippet:
>>
>> 2023-03-13 16:52:00 243 my-heartbeat-job job: running...
>> 2023-03-13 16:52:00 243 my-heartbeat-job job: Healthcheck: OK
>> 2023-03-13 16:52:00 243 my-heartbeat-job job: shepherd: Evaluating user 
>> expression (and (defined? (quote transient?)) (map (# ?) ?)).
>> 2023-03-13 16:52:00 243 my-heartbeat-job job: completed in 0.087s
>>
>
> I think this was already fixed in Shepherd on its master branch.  Ludo,
> could you please confirm?

Nope. :-)  What is ‘my-heartbeat-job’ doing?

The “Evaluating…” message occurs when using the ‘eval’ action of the
‘root’ service, as in “herd eval root '(+ 2 2)'”.

Ludo’.

bug#62406: “! failing-command” pattern in shell tests is wrong

[Ludovic Courtès]

Hi Eric,

Eric Bavier  skribis:

> The purpose of d89343 was to ease visual parsing of the tests.  I mentioned
> having used the '!' syntax in my own shell tests, but I realize now that I
> was not relying on `set -e` like guix is.
>
> I'll consider a few options.

Neat.  I guess we could have a ‘lib.sh’ with an ‘expect_fail’ function
or something.

> Do we have a known issue where this is causing a test to not to catch
> a failure?

No; I noticed it while writing a new test that I expected to fail.

Thanks for your feedback!  Shell semantics are definitely weird.  :-)

Ludo’.

bug#62476: ‘guix substitute’ poorly handles premature TLS termination

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I got a report showing this:
>
>> $ guix shell …
>> […]
>> substitute: mise à jour des substituts depuis « https://ci.guix.gnu.org »... 
>>   0.0 %guix substitute: erreur : Erreur TLS dans la procédure « handshake » 
>> : La connexion TLS n’a pas été terminée correctement.
>> guix shell: erreur : 
>> `/gnu/store/aca6i8lqgdfy0gwd4m8ql3kv5a0gp6c9-guix-command substitute' died 
>> unexpectedly
>
> This corresponds to GnuTLS exception ‘error/premature-termination’ while
> connecting to a substitute server, from ‘fetch-narinfos’.
>
> Why ‘handshake’ fails, I don’t know, but at any rate ‘guix substitute’
> shouldn’t error out when that happens; preferably, it should skip that
> substitute server and keep going, like it does for other transient
> networking errors in ‘call-with-connection-error-handling’.

Fixed in af91c2d540ef437e3f663b2c18c76dc2b94e13d2.

Ludo’.

bug#62140: enable LVM in Grub

[Maxim Cournoyer]

Hi,

Emmanuel Beffara  writes:

> Hi,
>
> De Maxim Cournoyer le 24/03/2023 à 13:24:
>> OK, thanks for explaining.  Could you please try
>> https://issues.guix.gnu.org/60442 (by applying the patch to a local guix
>> checkout, building it, then 'sudo -E ./pre-inst-env sudo guix system
>> reconfigure /path/to/your/config.scm)?  The test suite was broken it
>> seems (it passed without the fix), but perhaps the fix still does work?
>
> I did as you suggested, and unfortunately the patch has no observable effect
> on my system.

Thanks for testing it!

> I can't say it comes as a surprise. Indeed, what the patch does is set the
> environment variable `GRUB_PRELOAD_MODULES` before calling `grub-install`,
> which is expected to have no effect: this variable is used by `grub-mkconfig`
> to generate a `grub.cfg`, but the code in Guix assembles a Grub configuration
> file itself and never calls `grub-mkconfig`. The same applies to the variable
> `GRUB_ENABLE_CRYPTODISK`, by the way. Maybe the way `grub.cfg` is produced has
> changed at some point in history ?

I'm not sure, but I agree it's confusing to have extraneous setenv
there if they serve no purpose (and my understanding is the same as
yours: I don't see how that'd work).

> The only hypothesis I can make is that it would influence `grub-install` by
> preloading the given modules in the installed image, but that is not the case.
> According to Grub's documentation, passing `--modules=...` to `grub-install`
> would have this effect, but I'm not sure it is the right approach.

Since we already generate a custom grub.cfg, the right approach is
probably to add any needed directive directly to it.

-- 
Thanks,
Maxim

bug#44877: bug#62140: enable LVM in Grub

[Emmanuel Beffara]

Hi,

De Maxim Cournoyer le 24/03/2023 à 13:24:
> OK, thanks for explaining.  Could you please try
> https://issues.guix.gnu.org/60442 (by applying the patch to a local guix
> checkout, building it, then 'sudo -E ./pre-inst-env sudo guix system
> reconfigure /path/to/your/config.scm)?  The test suite was broken it
> seems (it passed without the fix), but perhaps the fix still does work?

I did as you suggested, and unfortunately the patch has no observable effect
on my system.

I can't say it comes as a surprise. Indeed, what the patch does is set the
environment variable `GRUB_PRELOAD_MODULES` before calling `grub-install`,
which is expected to have no effect: this variable is used by `grub-mkconfig`
to generate a `grub.cfg`, but the code in Guix assembles a Grub configuration
file itself and never calls `grub-mkconfig`. The same applies to the variable
`GRUB_ENABLE_CRYPTODISK`, by the way. Maybe the way `grub.cfg` is produced has
changed at some point in history ?

The only hypothesis I can make is that it would influence `grub-install` by
preloading the given modules in the installed image, but that is not the case.
According to Grub's documentation, passing `--modules=...` to `grub-install`
would have this effect, but I'm not sure it is the right approach.

-- 
Emmanuel

bug#62493: xelatex won't render fonts correctly without full texlive

[Ricardo Wurmus]

We seem to be missing the xetex package that provides files for font mapping:

--8<---cut here---start->8---
$ info tex-text.tec
tlmgr.pl: cannot find package tex-text.tec, searching for other matches:

Packages containing `tex-text.tec' in their title/description:

Packages containing files matching `tex-text.tec':
xepersian:
texmf-dist/fonts/misc/xetex/fontmapping/xepersian/persian-tex-text.tec
xetex:
texmf-dist/fonts/misc/xetex/fontmapping/base/tex-text.tec
--8<---cut here---end--->8---

I was under the impression that we did have a xetex package, but I can’t
find it now.

-- 
Ricardo

bug#62493: xelatex won't render fonts correctly without full texlive

[Ricardo Wurmus]

FWIW, it does work with lualatex:

  guix shell --container texlive-base texlive-fontspec -- lualatex test.tex

-- 
Ricardo