bug#68627: Guix on Fedora overwrites dir file in /usr/local/share/info
Greetings, I installed Guix on top of Fedora via binary installation with the `guix-install.sh' shell script. I set SELinux to permissive mode, rebooted, ran `guix pull', `guix package -u`, and installed three packages: - hello - glibc-locales - guile Before installing Guix I compiled Emacs and installed various packages via melpa as well as separate programs with dnf (Fedora's package manager) that inlcude many info manuals in /usr/local/share/info. Before the Guix installation, every manual in /usr/local/share/info was being picked up and included in the `dir' file as expected. However, after installing Guix it has placed several info manuals in various languages in /usr/local/share/info and overwrote the dir file to include only Guix info manuals, all symlinked to /var/guix/profiles/per-user/root/current-guix/share/info. I now have significantly less manuals inside emacs when I browse for documentation via `M-x info'. Though I can open them with dired by pressing `I' this is significantly less convenient. I suspect this is either a bug or at the least undesired behavior from my perspective. Below is relevant information and attached is the directory listing of /usr/local/share/info. If anything else is needed please let me know, thank you. Fedora version: 39 Guix version/commit: 4532eb6389e0602c1aac2e452bbc085f251658a3 Emacs version: 29.1 /usr/local/share/info: drwxr-xr-x. 1 root root 4.1K Jan 17 23:15 . drwxr-xr-x. 1 root root 124 Jan 5 22:20 .. lrwxrwxrwx. 1 root root 63 Jan 17 23:15 images -> /var/guix/profiles/per-user/root/current-guix/share/info/images -rw-r--r--. 1 root root 284K Jan 2 02:31 asdf.info -rw-r--r--. 1 root root 54K Jan 2 01:42 auth.info -rw-r--r--. 1 root root 56K Jan 2 01:42 autotype.info -rw-r--r--. 1 root root 39K Jan 2 01:42 bovine.info -rw-r--r--. 1 root root 1.7M Jan 2 01:42 calc.info -rw-r--r--. 1 root root 341K Jan 2 01:42 ccmode.info -rw-r--r--. 1 root root 250K Jan 2 01:42 cl.info -rw-r--r--. 1 root root 113K Jan 2 01:42 dbus.info lrwxrwxrwx. 1 root root 60 Jan 17 23:15 dir -> /var/guix/profiles/per-user/root/current-guix/share/info/dir lrwxrwxrwx. 1 root root 63 Jan 17 23:15 dir.de -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.de lrwxrwxrwx. 1 root root 63 Jan 17 23:15 dir.es -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.es lrwxrwxrwx. 1 root root 63 Jan 17 23:15 dir.fr -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.fr lrwxrwxrwx. 1 root root 63 Jan 17 23:15 dir.ko -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.ko lrwxrwxrwx. 1 root root 63 Jan 17 23:15 dir.ru -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.ru lrwxrwxrwx. 1 root root 63 Jan 17 23:15 dir.sk -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.sk -rw-r--r--. 1 root root 60K Jan 2 01:42 dired-x.info lrwxrwxrwx. 1 root root 66 Jan 17 23:15 dir.pt_BR -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.pt_BR lrwxrwxrwx. 1 root root 66 Jan 17 23:15 dir.zh_CN -> /var/guix/profiles/per-user/root/current-guix/share/info/dir.zh_CN -rw-r--r--. 1 root root 78K Jan 2 01:42 ebrowse.info -rw-r--r--. 1 root root 158K Jan 2 01:42 ede.info -rw-r--r--. 1 root root 153K Jan 2 01:42 ediff.info -rw-r--r--. 1 root root 63K Jan 2 01:42 edt.info -rw-r--r--. 1 root root 230K Jan 2 01:42 efaq.info -rw-r--r--. 1 root root 91K Jan 2 01:42 eglot.info -rw-r--r--. 1 root root 100K Jan 2 01:42 eieio.info -rw-r--r--. 1 root root 750K Jan 2 01:42 eintr.info -rw-r--r--. 1 root root 4.7M Jan 2 01:42 elisp.info -rw-r--r--. 1 root root 2.8M Jan 2 01:42 emacs.info -rw-r--r--. 1 root root 36K Jan 2 01:42 emacs-gnutls.info -rw-r--r--. 1 root root 99K Jan 2 01:42 emacs-mime.info -rw-r--r--. 1 root root 61K Jan 2 01:42 epa.info -rw-r--r--. 1 root root 84K Jan 2 01:42 erc.info -rw-r--r--. 1 root root 79K Jan 2 01:42 ert.info -rw-r--r--. 1 root root 125K Jan 2 01:42 eshell.info -rw-r--r--. 1 root root 87K Jan 2 01:42 eudc.info -rw-r--r--. 1 root root 48K Jan 2 01:42 eww.info -rw-r--r--. 1 root root 87K Jan 2 01:42 flymake.info -rw-r--r--. 1 root root 62K Jan 2 01:42 forms.info -rw-r--r--. 1 root root 1.5M Jan 2 01:42 gnus.info lrwxrwxrwx. 1 root root 77 Jan 17 23:15 gnutls-guile.info.gz -> /var/guix/profiles/per-user/root/current-guix/share/info/gnutls-guile.info.gz lrwxrwxrwx. 1 root root 76 Jan 17 23:15 guile-avahi.info.gz -> /var/guix/profiles/per-user/root/current-guix/share/info/guile-avahi.info.gz lrwxrwxrwx. 1 root root 77 Jan 17 23:15 guile-gcrypt.info.gz -> /var/guix/profiles/per-user/root/current-guix/share/info/guile-gcrypt.info.gz lrwxrwxrwx. 1 root root 74 Jan 17 23:15 guile-git.info.gz -> /var/guix/profiles/per-user/root/current-guix/share/info/guile-git.info.gz lrw
bug#68619: dhcp-client-service-type uses end-of-life dhclient
Hello, I recently installed the Guix operating system and selected DHCP-based network configuration in the installer. Today I noticed that the DHCP client installed by default seems to be dhclient from ISC-DHCP. This is problematic as this DHCP implementation has reached its end-of-life in 2022 [1]. This is also mentioned in the Guix package description. The dhcp-client-service-type has a package configuration option, in theory, allowing usage with other DHCP clients. Unfortunately, it seems to require that the package provides /sbin/dhclient and I am not aware of any package that has this executable. In general, it seems there is no other DHCP client package available in Guix. Therefore, I believe the course of action here would be to: (a) package a different DHCP client (dhcpcd [2] may be a good candidate) and (b) make sure that dhcp-client-service-type is compatible with this client and uses it by default. I would argue that this is an important issue, as a DHCP client processes untrusted input from the local network and is thus subject to potential security vulnerabilities. Greetings, Sören [1]: https://www.isc.org/blogs/isc-dhcp-eol/ [2]: https://roy.marples.name/projects/dhcpcd
bug#68628: `guix pull` fails due to with-grafts in GUIX_BUILD_OPTIONS
When I invoke `guix pull` when `GUIX_BUILD_OPTIONS` contains a call for `--with-graft`, `guix pull` fails due to `with-graft` not being a valid option for `guix pull`: Command-line transcript: guix pull guix pull: error: with-graft=gnutls=gnutls@3.5.4: unrecognized option Having `guix pull` ignore `GUIX_BUILD_OPTIONS` may be a hack fix, but it could break other people's workflows since `guix pull` has some options for building (i.e: `--cores` and `--no-grafts`). Suggestions: Adding `with-graft` support to guix pull (if that's even applicable). Having guix-pull just ignore the option and return a warning. Split up GUIX_BUILD_OPTIONS into a per-command set of flags (i.e: GUIX_BUILD_OPTIONS_PULL).
bug#68635: cifs-utils: smbinfo and smb2-quota do not run
`smbinfo` and `smb2-quota` of the cifs-utils package refuse to run properly: ``` $ smbinfo /usr/bin/env: 'python3': No such file or directory $ smb2-quota /usr/bin/env: 'python': No such file or directory ``` We need to patch out the `/usr/bin/env python` thing. ~Jonathan
bug#53258: Python unable to find modules within a Singularity container created with guix pack
Hi Konrad, Konrad Hinsen writes: > Konrad Hinsen writes: > >> Patch at https://issues.guix.gnu.org/68241 > > If you want to test it without rebuilding tons of packages, here is a > version that grafts a patched Python onto the existing ones (as substitutes): > > https://codeberg.org/khinsen/guix/src/branch/graft-fix-python-sitecustomize I've applied your patch to core-updates. I trust that it fixed this issue based on your own testing. Closing; we can always reopen if we find it didn't fix every use cases or create a fresh issue. -- Thanks, Maxim
bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs
Hello, Maxim Cournoyer writes: > Hi Leo et al., > > Leo Famulari writes: > >> On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote: >>> I see now that I'm using an older version, although I would have >>> preferred the newer one. I refer to the variable name 'inkscape' from >>> my manifest file, and I expected that to point to the latest stable >>> version. However, it seems that one must use the 'inkscape-1.0' >>> variable to get the latest stable version. That's seems suboptimal. >>> >>> I wonder if the 'inkscape' variable should be renamed 'inkscape/stable' >>> (for use in packages such as 'dblatex/stable'), and then 'inkscape' >>> could be repurposed to point to the latest stable version. Thoughts? >> >> I think we should do this, or even remove the old Inkscape package now. >> >> I'm guessing the reason for keeping the older release series is that >> the Inkscape save-file format changed? > > The reason inksape@0.92 is still kept around is becauseInkscape@1 > doesn't build on ARM (more accurately, one of its dependencies, > lib2geom, doesn't). It's been a while since I looked at the issue, and > it seems there may have been some activity in lib2geom upstream to try > to address the problem, so we should revisit it. That's not relevant anymore, but our current inkscape 1.2 depends on imagemagick still. Seeing how it now links directly to it, I've added it to inputs as well in commit 552ebc47af and pushed to core-updates. Closing! -- Thanks, Maxim
bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs
Hello,
[...]
>>> On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
I see now that I'm using an older version, although I would have
preferred the newer one. I refer to the variable name 'inkscape' from
my manifest file, and I expected that to point to the latest stable
version. However, it seems that one must use the 'inkscape-1.0'
variable to get the latest stable version. That's seems suboptimal.
I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
(for use in packages such as 'dblatex/stable'), and then 'inkscape'
could be repurposed to point to the latest stable version. Thoughts?
>>>
>>> I think we should do this, or even remove the old Inkscape package now.
>>>
>>> I'm guessing the reason for keeping the older release series is that
>>> the Inkscape save-file format changed?
>>
>> The reason inksape@0.92 is still kept around is becauseInkscape@1
>> doesn't build on ARM (more accurately, one of its dependencies,
>> lib2geom, doesn't). It's been a while since I looked at the issue, and
>> it seems there may have been some activity in lib2geom upstream to try
>> to address the problem, so we should revisit it.
>
> That's not relevant anymore, but our current inkscape 1.2 depends on
> imagemagick still. Seeing how it now links directly to it, I've added
> it to inputs as well in commit 552ebc47af and pushed to core-updates.
I've applied some patches from Maxime and refined my understanding of
what this was about; it was not just about retaining a reference to
imagemagick listed from native-inputs, it was about retaining a
reference to imagemagick for the *stable* variant of inkscape/stable,
which meant we couldn't use the imagemagick/stable insecure variant.
Tentatively fixed in b4a6b1ba93844d7373c58237cb0b742352dec954 ("gnu:
inkscape/stable: Build stable variant without imagemagick support.")
which builds on a series from Maxime Devos. I haven't caught up with
rebuilding core-updates yet to validate it truly works, but we'll see
soon.
Thanks, Maxime!
--
Maxim
bug#47217: generic-html updater does not work with sqlite package
Hi, Ludovic Courtès writes: > Léo Le Bouter skribis: > >> + (properties >> +`((release-monitoring-url . "https://sqlite.org/download.html";))) > > Unfortunately this page uses JavaScript. Without JS, you get: > > sqlite-autoconf-3350200.tar.gz(2.82 > MiB) > > We’d need to find a web page that directly links to the tarball, but I > can’t seem to find such a page. Since the SQLite website doesn't seem amenable to discover new releases, perhaps we could switch the source to Git and let our git updater do its magic? -- Thanks, Maxim
bug#66753: grep 3.8 now needs pcre2 as input, not pcre
Hi,
Matt Beshara writes:
> Hi Guix people,
> I have been working on creating a package definition for
> pulseaudio-equalizer¹ and when built with the current definition of
> the grep package, it prints this error message when running:
>
> grep: Perl matching not supported in a --disable-perl-regexp build
> grep: write error: Broken pipe
>
> Searching for that error message, I came across this:
> https://trac.macports.org/ticket/65800
>
> So it seems that, for version 3.8, the pcre input package for grep
> should be changed to pcre2. I have made this change in a new
> definition which inherits grep and told my pulseaudio-equalizer
> package to use that as a propagated input, and that causes the error
> to go away. For the sake of completeness, here’s the definition I
> used:
>
> (define grep-fixed
> (package
>(inherit grep)
>(inputs (list pcre2
>
> Best wishes,
> Matt
This appears to have been fixed independently by spacecadet in commit
5b0cea02358044f0cc695bacc3f44db1e220239b ("gnu: grep: Fix PCRE matches
(grep -P).").
Closing!
--
Thanks,
Maxim
bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
tags 62064 + notabug quit Simon Tournier writes: > Hi, > > On Mon, 13 Mar 2023 at 21:11, paren--- via Bug reports for GNU Guix > wrote: > >> There's another important reason: >> >> rust != rust-1.60 > > Well, as discussed in [1] > > [bug#62643] [PATCH] gnu: rust-1.65: Rename package to rust-next. > > this report #62064 is not a bug but instead a wish list: upgrade the > Rust ecosystem. Therefore, I am in favor to close it. WDYT? Done. We're currently at rust 1.73 on core-updates. -- Thanks, Maxim
bug#59489: gdm: Accessibility icon missing in log in screen
Hi Dariqq, Dariqq writes: > Hi Maxim, > > > On 20.01.24 04:12, Maxim Cournoyer wrote: >> Since this is, as the name implies, intended for artwork or other >> non-functional "assets", perhaps these package should be propagated by >> the gdm package itself? Would that have achieve the same? >> > > > That's what I tried initially and confirmed again today that it > doesn't work for both inputs or propagated inputs. (the icon from > gnome-control-center is visible because the share directory will be > included XDG_DATA_DIRS from the wrapper script from the > glib-or-gtk-wrap phase but not he other packages). > After that the next most simple solution was the hacky workaround via > gnome-shell-assets. Maybe someone has a better idea for how to include > the extra packages? Ah, that's interesting. It means there's probably some environment variable that gets set and usefor the other things too, or perhaps it searches relatively to its binary. Ideally we could patch what it needs in the gdm package definition. A second option would be to wrap GDM with the paths such as XDG_DATA_DIRS it wants. > Also as I use the gnome-desktop via gnome-desktop-service-type all > these packages should already be in my system profile. So somehow the > environment is weird when shepherd starts gdm such that gdm can't find > the extra files but I don't know enough of both guix/shepherd and > gdm/gnome to figure out what the exact problem is. > >> This issue appears to have been discussed previously, although I can't >> find it anymore... >> > > I found https://issues.guix.gnu.org/28088 which is a bit related but > not exactly the same as there is no login manager involved. Thanks, that's the issue I remember seeing. I'd like to avoid abusing the gnome-shell-assets, so would welcome us further investigating the sources of GDM to get clues as to what/where it's looking and what it wants exactly, but otherwise with your explanation I think this can be a first step (apply this change as is). Does anyone have a problem with it? -- Thanks, Maxim
