bug#64741: CUPS: fix the PATH settings for filters
Hello,
I would like to propose the attached patch for the `cups-filters` package. The
point is to add the paths for `coreutils` and `sed` to the PATH setting in the
wrapper scripts so that the filters can find them. Maybe other packages should
be added, at least this patch fixes the issue I was facing.
About my specific case: I want to use the printing service of my university,
an instance of PaperCut. This is as simple as setting an LPD queue at the
right address with the PPD printer driver provided by the university (a Ricoh
IM C5500 PS in my case, if that makes any difference). After switching to Guix
system a few months ago, this stopped working: print jobs were sent with no
error message but they all appeared as 1 page in PaperCut and nothing actually
came out of the printers. I finally took the time to explore the logs and it
appears that CUPS at some point calls `foomatic-rip` and that this filter
fails, as shown in these extracts from `/var/log/cups/error_log`:
```
I [18/Jul/2023:16:34:10 +0200] [Job 12] Started filter
/gnu/store/nhjpc32034v6186v37l51j0z2jq8xlkm-cups-server-bin/lib/cups/filter/foomatic-rip
(PID 27451)
[...]
D [18/Jul/2023:16:34:21 +0200] [Job 12] Starting process \"renderer\"
(generation 2)
D [18/Jul/2023:16:34:21 +0200] [Job 12] JCL: \033%-12345X@PJL
D [18/Jul/2023:16:34:21 +0200] [Job 12]
D [18/Jul/2023:16:34:21 +0200] [Job 12]
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash: line
5: date: command not found
D [18/Jul/2023:16:34:21 +0200] [Job 12]
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash: line
5: sed: command not found
D [18/Jul/2023:16:34:21 +0200] [Job 12]
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash: line
5: date: command not found
D [18/Jul/2023:16:34:21 +0200] [Job 12]
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash: line
5: sed: command not found
D [18/Jul/2023:16:34:21 +0200] [Job 12]
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash: line
5: cat: command not found
D [18/Jul/2023:16:34:21 +0200] [Job 12] renderer exited with status 127
D [18/Jul/2023:16:34:21 +0200] [Job 12] Process is dying with \"Encountered
error Broken pipe during fwrite\", exit stat 1
[...]
D [18/Jul/2023:16:34:21 +0200] [Job 12] PID 27451
(/gnu/store/nhjpc32034v6186v37l51j0z2jq8xlkm-cups-server-bin/lib/cups/filter/foomatic-rip)
stopped with status 1.
```
So `foomatic-rip` actually needs `date`, `sed` and `cat` but does not find
them. The issue with required tools is known in Guix because the package
definition for `cups-filters` already adds paths for `ghostscript-with-cups`
and `grep`. The patch just adds necessary inputs for those, and it makes
printing work for me. I don't know what other tools the filters might require
in other situations.
On a different level, I am surprised that the failure above does not lead to
an actual user-visible error by CUPS. A corrupted job is actually sent
silently (probably with some error messages mixed with the printing job or
with malformed printing commands) although the filter does return an error
code. Maybe this should be sent upstream as a CUPS bug?
--
Emmanuel
diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm
index 9d81a0aa07..301fdcdb35 100644
--- a/gnu/packages/cups.scm
+++ b/gnu/packages/cups.scm
@@ -198,9 +198,11 @@ (define-public cups-filters
(wrap-program file
`("PATH" ":" prefix
(,(string-append
+ #$(this-package-input "coreutils") "/bin:"
#$(this-package-input "ghostscript-with-cups")
bug#56556: texlive-babel-dutch with and without texlive-hyphen-dutch: No hyphenation patterns were preloaded
Hi, De Ludovic Courtès le 07/04/2023 à 12:33: > > I don't really know how we could fix this: maybe build the formats with > > all the hyphenation packages enabled? > > The intertubes suggest running ‘fmtutil --all’ to get hyphenations > packages straight. Is this something we should do in the TeX Live > profile hook for example? > > Emmanuel, is this what you had in mind when you wrote about compilation > of hyphenation patterns above? Indeed ! Doing that is the job of fmtutil and it should be used for building environments that include parts of TeXlive. -- Emmanuel
bug#56556: TeXlive packaging issues
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#44877: bug#62140: enable LVM in Grub
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#62140: enable LVM in Grub
Hello, De Maxim Cournoyer le 23/03/2023 à 13:48: > It seems to me that since we produce grub.cfg ourselves if there's something > to add there for LVM support (which I'm not sure there is -- apparently it > already works for you ?), it should be explicitly coded in (gnu bootloader > grub). It does not work for me, that is why I reported this! The system does not boot unless I manually add `insmod lvm` in `grub.cfg` because Grub does not find the partition that contains the store. So I agree something has to be done there. > info '(grub) Changes from GRUB Legacy' mentions that "* GRUB 2 can read > files directly from LVM and RAID devices.", so I would think there's nothing > special to do? As I understand it, this just means that Grub 2 has a module for reading LVM devices and a module for reading RAID devices. But it still has to load them somehow (unless there is a way to include them statically so they are available from the beginning). -- Emmanuel
bug#44877: bug#62140: enable LVM in Grub
De Michael Rohleder le 13/03/2023 à 14:56: > Hello Emmanuel! > > Thx for the report! > > I think this is bug 44877, maybe we can/should merge it. > Here [1] is a patch (and testcase). > > > [1] https://issues.guix.gnu.org/60442 Indeed, it seems to be the same issue. However, the patch sets the value of `GRUB_PRELOAD_MODULES`, which afaik is used by `grub-mkconfig` to produce `grub.cfg`, but there seems to be code in `grub.scm` that also produces `grub.cfg`, and no call to `grub-mkconfig` there. I'm not sure I understand how all this works anyway… -- Emmanuel
bug#62139: Grub resource files should be in the EFI partition
Hello Guix, The installation process for Grub should put the resource files, notably keymaps and locales, in the EFI partition, so that they can be used early in the boot process, before any user interaction. In the context of full-disk encryption, this is very important because in the current state of things, one has to enter the passphrase using the default US layout before the proper keymap can be loaded from the encrypted store. One can manage working around that with a bit of training, but having to enter a passphrase with an incorrect keymap is objectively a broken behaviour. I have no experience hacking Guix so I don't know how to try and patch grub.scm to implement that, but I would be happy to learn… -- Emmanuel
bug#62141: Grub: set terminal_output earlier
Hello Guix, In the generated `grub.cfg`, it would be an improvement to set the `terminal_output` before any user input is required by Grub, for proper interaction. In my case, the laptop has a HiDPI display and Grub starts with a graphical terminal in 3840x2160 resolution with extremely small characters. Then it asks for the LUKS passphrase (I use full-system encryption) before setting the output mode specified in the configuration. Not only is it unreadable, but Grub is also known to be particularly slow with high resolutions [1], which makes interaction painful, in case some emergency prompt happens (which it does in the current state of things, cf. other bug reports). [1] https://askubuntu.com/questions/1227735/grub-is-extremely-slow-1-second-per-key-input My current method is to edit `grub.cfg` by hand after each `guix system reconfigure` to move the lines between `if loadfont unicode; then` and `terminal_output gfxterm` at the beginning, but this is not a viable solution. -- Emmanuel
bug#62140: enable LVM in Grub
Hello Guix, Unless I missed something in the configuration process, the `grub.cfg` generated by `guix system reconfigure` does not enable LVM, even if the store is in an LVM volume. The immediate consequence is that Grub cannot load its data files nor boot the system. The fix is as simple as adding `insmod lvm` in `grub.cfg` before any `search` command, which I do by hand on each `reconfigure`, but obviously Guix itself should do that. I looked at `grub.scm` to see where things happen, and I see no mention of LVM in this file. This surprises me because I am probably not the only one using it. Actually, I use LVM on LUKS for full-system encryption, but this is probably not rare either. -- Emmanuel
