bug#71645: llhttp package in guix contains generated sources

[Jelle Licht]

Hi all,

Our llhttp package contains generated sources.  Running:

--8<---cut here---start->8---
ls $(guix build llhttp --source)/src
--8<---cut here---end--->8---

shows the existence of a llhttp.c file, which is a generated file.

To the best of my understanding, few in the wider community
generates these files from the (JavaScript) sources.

We currently end up doing this in the (hidden) llhttp-bootstrap package,
which uses the last version of Node.js that could be built without
depending on llhttp to build llhttp (which is then used as an input for
building more recent versions of Node.js).

Kind regards,
Jelle

bug#71065: Emacs packages that override built-in features ignored when compiled

[Jelle Licht]

Hi all,

What I think happens is that Emacs code that is compiled against an
(Emacs) feature that is available as both a built-in and provided
(propagated) input seems to 'compile' Emacs code against the built-in
version.

Case in point:
Built-in jsonrpc feature for Emacs 29.3 has the following slot:
-events-buffer-scrollback-size  t   'eieio--unbound

The version of jsonrpc as packaged in emacs-jsonrpc (and also propagated by
our emacs-eglot package):
-events-buffer-config   t   '(:size nil :format full)

Reproducer:

Run:

guix shell --container --preserve=TERM emacs emacs-eglot -- emacs -nw -Q,
`M-x describe-symbol` -> jsonrpc-connection -> notice that the help
buffer lists the details from the built-in jsonrpc class, while the link
to "jsonrpc.el" at the top of the *Help* buffer links (correctly) to the
more recent version (as propagated by emacs-eglot), which makes me think
it's not a load-path issue.

AFAICT this means that we will run into issues once a library
(e.g. emacs-eglot) starts depending on slots present in the (propagated)
emacs-jsonrpc, but not the built-in jsonrpc version.

Thanks,
 - Jelle

bug#65720: Guile-Git-managed checkouts grow way too much

[Jelle Licht]

Hi Ludo,

> 
> On 4 Sep 2023, at 23:49, Ludovic Courtès  wrote:
> 
> Of course having to re-clone entire repositories every 9 months is
> ridiculous, but storing gigabytes of packs is worse IMO (I’m
> specifically thinking about the Guix repo, which every users copies via
> ‘guix pull’).

Please ignore if it doesn’t make sense, or would not make a practical 
difference for the current issue, but wouldn’t a local clone do the trick here? 
As in, clone from the ‘clogged’ local repo, move over fresh clone to old 
location.

Kr, Jelle

bug#64280: Editorconfig and dir-locals in guix source tree contradict each other

[Jelle Licht]

Hi all,

I found my Emacs using a fill-column value of 85 while hacking on the
guix source tree.

Turns out it's an interaction between the emacs package
editorconfig-mode (which I use). Easy workaround: turn this mode off
when hacking on guix.

A contradiction between .dir-locals.el and the .editorconfig file in
guix exists:

 max_line_length of 85 in .editorconfig for most files in guix 
vs
 fill-column of 78 in dir-locals.el for all files in guix

I don't know which of these values is supposed to be leading, or whether
they configure the exact same thing in all situations.

Cheers,
 Jelle

bug#63921: Activation snippets in reverse order, prevent boot

[Jelle Licht]

"pelzflorian (Florian Pelz)"  writes:

> Hi Ludo, hi all.
>
[snip]

> The following works for me now …
>
> (modify-services %base-services
>  (delete login-service-type)
>  (delete mingetty-service-type)
>  (delete mingetty-service-type)
>  (delete mingetty-service-type)
>  (delete mingetty-service-type)
>  (delete mingetty-service-type)
>  (delete mingetty-service-type))

Thanks for the workaround! Is this "thou shall delete N times, and
_exactly_ N times" effect of the recently pushed change functioning as
intended?  It imho seems pretty brittle and verbose compared to how
things were before.

- Jelle

bug#63530: Missing library in package procps

[Jelle Licht]

Hello,

Gabriel Wicki  writes:

> A little more hacking leads me to the conclusion that (probably with
> version 4 but it's not exactly clear from the changelog) procps has made
> some significant changes to it's API.  So, unless igt-gpu-tools (and
> probably others) are fixed upstream they remain broken.  Fixes through
> simple regex-magic in our build-phases might be possible, but I am not
> confident enough in the matter to guarantee that the package would not
> just build but be broken in a more specific manner.
>
> Is there an easy way to check which dependents of procps are actually
> broken currently?  Or is it really just igt-gpu-tools?
>
> There's two ways to go (I'd be happy for some input and volunteer to do
> the actual leg-work):
>  1. Add an additional procps-3 package with the older API to fix the
>  broken packages.
>  2. Leave it as-is and wait for an upstream change of the currently
>  broken packages.

I have found the upstream issue:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/116

We can wait it out until the release, which will be out Soon (tm), or we
make use of the patch that debian applies to igt-gpu-tools so it can
work with the new libproc2 API:

https://salsa.debian.org/xorg-team/app/intel-gpu-tools/-/blob/067ddd789fd80c12972fb92db8f93fadbdc4530e/debian/patches/libproc2_library

AFAICS, this would not lead to a world-rebuild.

Thoughts?
- Jelle

bug#62529: Keychain package lacks reference to several command line utilities

[Jelle Licht]

The `keychain' script, as packaged by the package of the same name, is
missing references to several command line utilities.

A nonexhaustive list:
- cat
- (g)awk
- sed
- ps (currently found via procps being a propagated input)

Cheers,
Jelle

bug#62527: Nonreproducible error while grafting kdeclarative

[Jelle Licht]

While running some random guix command which had to build and/or graft
some store items, I ran into a failure:

--8<---cut here---start->8---
applying 43 grafts for kdeclarative-5.98.0 ...
[snip]
View build log at 
'/var/log/guix/drvs/yq/3if54r360b6mhf7hdzlrlz02zl3rl1-kdeclarative-5.98.0.drv.gz'.
--8<---cut here---end--->8---

Contents of referenced log file:
--8<---cut here---start->8---
grafting '/gnu/store/57m41maa1wi5iv7075cvkcxyvnw155yc-kdeclarative-5.98.0' -> 
'/gnu/store/0irfgfan5ggqyr4mzdmjygknp58x27fa-kdeclarative-5.98.0'...
ERROR: In procedure car: Wrong type argument in position 1 (expecting pair): 221
--8<---cut here---end--->8---

Simply trying again with `guix build kdeclarative' works out fine:

--8<---cut here---start->8---
The following graft will be made:
   /gnu/store/yq3if54r360b6mhf7hdzlrlz02zl3rl1-kdeclarative-5.98.0.drv
applying 43 grafts for kdeclarative-5.98.0 ...
grafting '/gnu/store/57m41maa1wi5iv7075cvkcxyvnw155yc-kdeclarative-5.98.0' -> 
'/gnu/store/0irfgfan5ggqyr4mzdmjygknp58x27fa-kdeclarative-5.98.0'...
successfully built 
/gnu/store/yq3if54r360b6mhf7hdzlrlz02zl3rl1-kdeclarative-5.98.0.drv
/gnu/store/0irfgfan5ggqyr4mzdmjygknp58x27fa-kdeclarative-5.98.0
--8<---cut here---end--->8---

I can't seem to reproduce the error again. Both my RAM and SSD seem to
be in good health. I'm using an ext4 file system /w luks FDE on the SSD.

Perhaps there are other packages that have this happen as well, or
perhaps it's just bad luck on my end :-).

- Jelle

bug#62174: Cannot use modules with an inferior kernel.

[Jelle Licht]

Robby Zambito  writes:

> Liliana Marie Prikler  writes:
>> I think you should try to pin the kernel modules as well.  If that
>> still doesn't work as intended (it very well might), we have a proper
>> case of something that should work but doesn't.
>>
>> Cheers
>
> Thanks for the suggestion. I tested with the following:
>
> ```
> (define-values (rz/linux rz/linux-kernel-modules)
>   (let* ((channels
>   (list   (channel
>(name 'guix)
>(url "https://git.savannah.gnu.org/git/guix.git;)
>(commit "d37b467631d5b0e965ea933b8bda8448993580e9"
>(inferior (inferior-for-channels channels))
>(kernel-version "6.1.15"))
> (values (first (lookup-inferior-packages inferior "linux-libre" 
> kernel-version))
>   (list (first (lookup-inferior-packages inferior 
> "v4l2loopback-linux-module"))
>
> (operating-system
>   ...
>   (kernel rz/linux)
>   (kernel-loadable-modules rz/linux-kernel-modules)
>   ...)
> ```
>
> But I receive a different error now:
>
> ```
> running profile hook of type 'linux-module-database'...
> Backtrace:
>1 (primitive-load "/gnu/store/7ha0kn8fz8yfi26m3m8997wlc8m?")
> In ice-9/boot-9.scm:
>2007:7  0 (error _ . _)
>
> ice-9/boot-9.scm:2007:7: In procedure error:
> Specified Linux kernel and Linux kernel modules are not all of the same 
> version
> ```
>
> However, if I use the most recent kernel version available in the
> inferior...
>
> ```
> (define-values (rz/linux rz/linux-kernel-modules)
>   (let* ((channels
>   (list   (channel
>(name 'guix)
>(url "https://git.savannah.gnu.org/git/guix.git;)
>(commit "d37b467631d5b0e965ea933b8bda8448993580e9"
>(inferior (inferior-for-channels channels))
>  (kernel-version "6.2.2"))
> (values (first (lookup-inferior-packages inferior "linux-libre"))
>   (list (first (lookup-inferior-packages inferior 
> "v4l2loopback-linux-module"))
> ```
>
> It actually works! So it seems that the problem is specifically with
> using kernel modules with a kernel version other than the latest
> linux-libre kernel from an inferior. I also tried using a specific
> kernel version without an inferior like so:
>
> ```
> (operating-system
>   ...
>   (kernel (specification->package "linux-libre@6.1.15"))
>   (kernel-loadable-modules (list 
> (specification->package"v4l2loopback-linux-module")))
>   ...)
> ```
>
> And that works as well.
>
> TL;DR: The issue has been narrowed down to using kernel modules with a
> kernel from an inferior besides the latest kernel from that inferior.

I believe our kernel-loadable-modules is backed by a service with type
linux-builder-service-type. It seems that the
linux-builder-configuration->system-entry only deals gracefully with
modules that are filtered by "(package? mod)" in order to rewrite the
package with "package-for-kernel".

So there are some things we'd need to do to ensure your use case works:
- Get linux-builder-configuration->system-entry to support packages from
an inferior.

Can you try to wrap your kernel module package like such [untested],
with rz/linux being the kernel inferior package you actually want:

--8<---cut here---start->8---
(kernel rz/linux)
(kernel-loadable-modules
  (map
(lambda (mod) (package-for-kernel lz/linux mod))
rz/linux-kernel-modules))
--8<---cut here---end--->8---

If this doesn't work, we also need to make package-for-kernel support
packages from an inferior for both the kernel and module argument, or
create an alternative implementation that deals
`linux-builder-configuration->system-entry' can dispatch to for this
specific case.

Good luck!
- Jelle

bug#62177: [PATCH] [WIP] update node to version 16

[Jelle Licht]

Hi Dr. Arne,

"Dr. Arne Babenhauserheide"  writes:

> Hi,
>
>
> this is an initial stab at getting node to version 16.
[snip]

Issue 59188 (https://issues.guix.gnu.org/59188) already updates node to
the 18.X LTS series. Would that version also work for you, or do you
have a specific need for the 16.X series? I ask because the "active" LTS
version is 18, while the 16 "maintenance" LTS window already closes on
2023-09-11, which is (IMHO) pretty soon.

- Jelle

bug#61497: emacs-lsp-treemacs unused leftover icons in sources

[Jelle Licht]

Liliana Marie Prikler  writes:

> Am Dienstag, dem 14.02.2023 um 02:06 +0100 schrieb Jelle Licht:
>> Commit e0d2ec418bb on master removed icons that are unclearly
>> licensed
>> from the sources of emacs-lsp-treemacs. Quoted here: 
>> 
>> --8<---cut here---start->8---
>> gnu: emacs-lsp-treemacs: Remove unclearly licensed icons.
>> 
>> emacs-lsp-treemacs bundles icons with unclear licenses.
>> See also <https://github.com/emacs-lsp/lsp-treemacs/issues/123>.
>> --8<---cut here---end--->8---
>> 
>> Some icons are still left in the sources, in the 'icons/vscode'
>> directory' of the source tarball one builds by running `guix build
>> --source emacs-lsp-treemacs'. I have never used vscode, and am
>> unfamiliar with the licensing situation of it and its related icons.
>> 
>> In case these icons are also unclearly licensed, I propose we follow
>> the same strategy as done earlier by Liliana, and remove the vscode
>> icons entirely.  If the icons are actually licensed under an
>> unproblematic license, it would be nice if they were installed when
>> running `guix install emacs-lsp-treemacs', and the license property
>> of the package updated to reflect this fact.
> From what I could gather, vscode-icons [1] are actually CC-BY, but used
> without proper attribution in this package.  As for why they're unused,
> I mostly forgot to whitelist them.
>
> Cheers
>
> [1] https://github.com/microsoft/vscode-icons

Fixed + pushed to master in #61649 / 3f222cd5ad,
closing this issue.

- Jelle

bug#61513: emacs-next@29.0.60 self-reports as version 30.0.50

[Jelle Licht]

Hi guix,

Since commit 6f0c905324 on master, the version of our emacs-next package
was bumped to 29.0.60(-0.ac7ec87).

Yet:
--8<---cut here---start->8---
jlicht@revint ~$ guix shell --pure emacs-next -- emacs --version
GNU Emacs 30.0.50
--8<---cut here---end--->8---

Is this some peculiarity of the Emacs's development cycle, or did we end
up having a "emacs-next-next" package?

Kind regards,
- Jelle

bug#61497: emacs-lsp-treemacs unused leftover icons in sources

[Jelle Licht]

Commit e0d2ec418bb on master removed icons that are unclearly licensed
from the sources of emacs-lsp-treemacs. Quoted here: 

--8<---cut here---start->8---
gnu: emacs-lsp-treemacs: Remove unclearly licensed icons.

emacs-lsp-treemacs bundles icons with unclear licenses.
See also .
--8<---cut here---end--->8---

Some icons are still left in the sources, in the 'icons/vscode'
directory' of the source tarball one builds by running `guix build
--source emacs-lsp-treemacs'. I have never used vscode, and am
unfamiliar with the licensing situation of it and its related icons.

In case these icons are also unclearly licensed, I propose we follow the
same strategy as done earlier by Liliana, and remove the vscode icons
entirely.  If the icons are actually licensed under an unproblematic
license, it would be nice if they were installed when running `guix
install emacs-lsp-treemacs', and the license property of the package
updated to reflect this fact.

Thanks for any insight,
- Jelle

bug#61262: Mako build fixed

[Jelle Licht]

I went ahead and pushed the solution posted with issue #61213 to master,
but thanks everyone and anyone who {reported,fixed} this issue!

- Jelle

bug#60725: guix lint thinks 2019111-0.7e76d75 is older than 20191111

[Jelle Licht]

Maxim Cournoyer  writes:

> retitle 60725 support the special '~' character in our version parser
> thanks
>
> Jelle Licht  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> Hi Guix,
>>>
>>> If you run 'guix lint emacs-enh-ruby-mode', it'll print this:
>>>
>>> --8<---cut here---start->8---
>>> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 2019
>>> --8<---cut here---end--->8---
>> In this particular case, 2019111 seems to have been a typo in the first
>> place.  (It misses out on a '1' in our package record).
>
> Thanks!  With this typo fixed, 'guix lint' doesn't suggest a downgrade
> anymore.
>
>> AFAIK, any sane versioning scheme would assert that 2019 > 
>> 2019111-anything.
>
> That's not currently the case with Guix.  Guix package version strings
> are documented has having the requirement to be 'monotonically
> increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than
> '43', the final release.

I agree with your assesment, but note that my example (again) had one
"1" less, in which case Guix does the right thing :-).

>
> I'll keep this bug open (and retitle it), because implementing ~ would
> be useful (GNOME makes use of that scheme, and it's understood by rpm,
> dpkg, pkg-config, etc.).

Fixing our versioning code so  "123" > "123-alpha2" will also bring us
(more) in line with Semantic Versioning.

- Jelle

bug#60725: guix lint thinks 2019111-0.7e76d75 is older than 20191111

[Jelle Licht]

Maxim Cournoyer  writes:

> Hi Guix,
>
> If you run 'guix lint emacs-enh-ruby-mode', it'll print this:
>
> --8<---cut here---start->8---
> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 2019
> --8<---cut here---end--->8---
In this particular case, 2019111 seems to have been a typo in the first
place.  (It misses out on a '1' in our package record).

AFAIK, any sane versioning scheme would assert that 2019 > 2019111-anything.

bug#60065: fwupd can not find required polkit actions

[Jelle Licht]

The package description for fwupd looks for polkit actions in the polkit
output. There are multiple ways to patch this.

--8<---cut here---start->8---
(add-before 'configure 'set-polkit-rules-dir
  ;; Locate actions in our {output,etc-dir}, not that of the polkit 
input.
  (lambda _
(setenv "PKG_CONFIG_POLKIT_GOBJECT_1_ACTIONDIR"
;; This makes it 'Just Work':
;; (string-append #$output "/share/polkit-1/actions")
;; This only makes it work when we extend 
polkit-service-type:
(string-append "/etc/polkit-1/actions")
)))
--8<---cut here---end--->8---

Example service definition: 
--8<---cut here---start->8---
(define (fwupd-shepherd-service package)
  "Return a Shepherd service to start fwupd."
  (list (shepherd-service
 (requirement '(dbus-system))
 (provision '(fwupd))
 (start #~(make-forkexec-constructor
   (list #$(file-append package "/libexec/fwupd/fwupd"
 (stop #~(make-kill-destructor)

(define-public fwupd-service-type
  (service-type
   (name 'fwupd)
   (description "Setup the firmware update deamon.")
   (default-value fwupd)
   (extensions
(list
 (service-extension profile-service-type list)
 (service-extension polkit-service-type list)
 (service-extension dbus-root-service-type list)
 (service-extension shepherd-root-service-type
fwupd-shepherd-service)
--8<---cut here---end--->8---

If we go for the first fix, the polkit-service-type extension is not
required. If we go for the /etc fix, the polkit-service-type extension
is required. I know too little about polkit to make an informed choice
here, so with some guidance I could work on a patch to close this issue.

- Jelle

bug#52979: Modular texlive has problems finding fonts

[Jelle Licht]

Jelle Licht  writes:

> As discussed on #guix on IRC, several folks including myself ran into
> issues getting the following some-file.tex:
>
> --8<---cut here---start->8---
> \documentclass[11pt]{article}
> \begin{document}
> Hello friends
> \end{document}
> --8<---cut here---end--->8---
>
> ... to typeset with the following manifest.scm:
> --8<---cut here---start->8---
> (specifications->manifest
>  '("texlive-base"
>"texlive-fonts-ec"
>"texlive-amsfonts"
>"texlive-fira"
>"texlive-inconsolata"))
> --8<---cut here---end--->8---
>
> ... with command: 
> `guix shell --pure coreutils grep sed gawk -m manifest.scm -- pdflatex 
> some-file
>
> Note that the monolithic texlive seems to work:
> `guix shell --pure coreutils grep sed gawk texlive -- pdflatex some-file'
>
> On IRC, rekado /w strace identified that texlive does not seem to be
> entering the subdirectory containing the font files, as it seems to be
> loading texlive-bin's texmf.cnf, instead of the one generated by
> `(@ (guix profiles) texlive-configuration)'.
The first part here is correct, the second part is not;

It seems texlive's kpathsea uses a heuristic to determine if a directory
is a 'leaf node', where it checks whether there are exactly 2 links in
there[1]; since symlinks do not count towards the link count, a directory
filled with only symlinks to other directories is seen as a leaf node,
and traversal subsequently ends there.

This heuristic is a performance optimisation, as simply doing stat calls
of everything in a directory is slow, according the the kpathsea
authors.

We can disable this optimisation by setting ST_NLINK_TRICK at compile
time. Alternatively, we could try to figure out a way in which our
directory-of-symlinks also contains at least one file.


[1]: That is, "." and ".."

bug#52979: Modular texlive has problems finding fonts

[Jelle Licht]

As discussed on #guix on IRC, several folks including myself ran into
issues getting the following some-file.tex:

--8<---cut here---start->8---
\documentclass[11pt]{article}
\begin{document}
Hello friends
\end{document}
--8<---cut here---end--->8---

... to typeset with the following manifest.scm:
--8<---cut here---start->8---
(specifications->manifest
 '("texlive-base"
   "texlive-fonts-ec"
   "texlive-amsfonts"
   "texlive-fira"
   "texlive-inconsolata"))
--8<---cut here---end--->8---

... with command: 
`guix shell --pure coreutils grep sed gawk -m manifest.scm -- pdflatex some-file

Note that the monolithic texlive seems to work:
`guix shell --pure coreutils grep sed gawk texlive -- pdflatex some-file'

On IRC, rekado /w strace identified that texlive does not seem to be
entering the subdirectory containing the font files, as it seems to be
loading texlive-bin's texmf.cnf, instead of the one generated by
`(@ (guix profiles) texlive-configuration)'.

It seems some of the talks in the guix-maintenance repository can
currently also not be built for the same or similar reason.

bug#50356: python-hy / python-funcparserlib / tox config file

[Jelle Licht]

Vinicius Monego  writes:

> Em sex, 2021-09-17 às 14:32 +0200, Jelle Licht escreveu:
>> 
>> Hello Andreas,
>> 
>> Andreas Reuleaux  writes:
>> 
>> > Hi,
>> > 
>> > python-hy fails to install for me - because there are issues with
>> > python-funcparserlib, as I understand (or tox - cf the end of the
>> > log below).
>> > 
>> 
>> It seems the hy and funcparserlib devs are coordinating new releases;
>> perhaps we can resolve this issue by updating both python-
>> funcparserlib
>> and python-hy to their respective 1.0.0 releases once they are out.
>> 
>> - Jelle
>> 
>
> The problem is that funcparserlib 0.3.6 (which is the most recent
> release at the moment) is incompatible with the Python version in Guix.
> There is an alpha for funcparserlib 1.0.0 in PyPI. I updated to this
> and Hy to 0.20.0 and it does work aside from 3 Hy tests failing (from a
> total of 621).

The develpoers of hy also have a 1.0a3 alpha release; does your package
of funcparserlib work with that?

> The developer of funcparserlib expects to release 1.0.0 in the winter
> holidays so we may be able to fix this in the next week or so.

There is no ETA for hy yet, the devs are shaking up many things.

- Jelle

bug#50909: clojure-tools-cli outdated

[Jelle Licht]

Hey Florian,

Florian Hoertlehner  writes:

> The guix package clojure-tools-cli is outdated. The gnu guix repo has 0.4.2.
> This version is from 2019.
> There is a package on "nongnu" channel called "clojure-tools" which has the
> up to date version 1.10.3.943.

The package you are talking about is not built from sources, nor
properly bootstrapped. While it is free software, it is currently not a
candidate for inclusion in Guix proper. I am sorry to say you will be
stuck with the current situation for now.

Additionally, since there is some overlap between the folks frequenting
the Channel That Shall Not Be Named and here, it makes more sense to use
support channels on that side for issues such as these.

Thanks for showing your interest in Clojure hacking on Guix :)!
 - Jelle

p.s. I will leave this issue open for now, as our package is outdated

bug#50356: python-hy / python-funcparserlib / tox config file

[Jelle Licht]

Hello Andreas,

Andreas Reuleaux  writes:

> Hi,
>
> python-hy fails to install for me - because there are issues with
> python-funcparserlib, as I understand (or tox - cf the end of the log below).
>

It seems the hy and funcparserlib devs are coordinating new releases;
perhaps we can resolve this issue by updating both python-funcparserlib
and python-hy to their respective 1.0.0 releases once they are out.

- Jelle

bug#47007: dcb640f02b broke guix environment --container

[Jelle Licht]

Ludovic Courtès  writes:

> Here’s a more sensible patch for you to try.  This time it should
> correctly determine the necessary mount flags based on statfs(2) info.
>
> Could you apply it and report back?

I can confirm that it does what it says on the tin :-).

Thanks again!
 - Jelle

bug#47007: dcb640f02b broke guix environment --container

[Jelle Licht]

Ludovic Courtès  writes:

> Hi,
>
> Jelle Licht  skribis:
>
>> I only tried this on x86_64 guix systems, one with Linux kernel 5.11.2,
>> and also on a Linux-libre kernel 4.14.223.
>>
>> Running the equivalent of a `git bisect' starting some months back to
>> today's master, and with the following test to select bad/good bisect 
>> revisions:
>>
>> `./pre-inst-env guix environment --ad-hoc --container --no-cwd --network 
>> hello'

This was intended to be, in case that was unclear:
`./pre-inst-env guix environment --ad-hoc --container --no-cwd --network hello 
-- hello'

>> [snip]
>> guix environment: error: mount: mount 
>> "/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16" on 
>> "/tmp/guix-directory.Ji7KNW//gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16":
>>  Operation not permitted
>
> Could you run:
>
>   ./pre-inst-env strace -f -o log guix environment --container
>
> and send the ‘log’ file (or the bits around the mount(2) calls)?

I ran it using a `guix pull'ed guix on the master branch, commit
c4195a10783. I hope that's fine.

There you go:
--8<---cut here---start->8---
26123 stat("/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
26123 mkdir("/tmp", 0777)   = -1 EEXIST (File exists)
26123 mkdir("/tmp/guix-directory.9IH6jJ", 0777) = -1 EEXIST (File exists)
26123 mkdir("/tmp/guix-directory.9IH6jJ/gnu", 0777) = 0
26123 mkdir("/tmp/guix-directory.9IH6jJ/gnu/store", 0777) = 0
26123 
mkdir("/tmp/guix-directory.9IH6jJ/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16",
 0777) = 0
26123 mount("/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16", 
"/tmp/guix-directory.9IH6jJ//gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16",
 0x15a2060, MS_RDONLY|MS_BIND|MS_RELATIME, NULL) = 0
26123 mount("/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16", 
"/tmp/guix-directory.9IH6jJ//gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16",
 0x15a20f0, MS_RDONLY|MS_REMOUNT|MS_BIND|MS_RELATIME, NULL) = -1 EPERM 
(Operation not permitted)
--8<---cut here---end--->8---

> Could you also show /proc/mounts?

--8<---cut here---start->8---
none /proc proc rw,relatime 0 0
none /dev devtmpfs rw,relatime,size=3944948k,nr_inodes=986237,mode=755 0 0
none /sys sysfs rw,relatime 0 0
/dev/sda1 / ext4 rw,relatime,data=ordered 0 0
none /dev/pts devpts rw,relatime,gid=996,mode=620,ptmxmode=000 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
/dev/sda1 /gnu/store ext4 ro,noatime,data=ordered 0 0
none /run/systemd tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /sys/fs/cgroup tmpfs rw,relatime 0 0
cgroup /sys/fs/cgroup/elogind cgroup rw,relatime,name=elogind 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,relatime,pids 0 0
none /var/cache/fontconfig tmpfs ro,relatime 0 0
cgroup2 /sys/fs/cgroup/unified cgroup2 
rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
tmpfs /run/user/1001 tmpfs 
rw,nosuid,nodev,relatime,size=790824k,mode=700,uid=1001,gid=997 0 0
--8<---cut here---end--->8---

FWIW, I only have this issue on Guix System: on my Ubuntu 20.04.2 things
JustWork(tm)

Thanks for taking a look,
 - Jelle

bug#47007: dcb640f02b broke guix environment --container

[Jelle Licht]

Hello guix,

I only tried this on x86_64 guix systems, one with Linux kernel 5.11.2,
and also on a Linux-libre kernel 4.14.223.

Running the equivalent of a `git bisect' starting some months back to
today's master, and with the following test to select bad/good bisect revisions:

`./pre-inst-env guix environment --ad-hoc --container --no-cwd --network hello'

leads me to believe that the following commit broke something.

dcb640f02b * file-systems: 'mount-file-system' preserves source flags for bind 
mounts.

Did this commit expose an existing (but silent) issue, or did it
introduce something new?

For completeness' sake, the output of the guix environment invocation on
'bad' revisions:

--8<---cut here---start->8---
guix environment: error: mount: mount 
"/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16" on 
"/tmp/guix-directory.Ji7KNW//gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16":
 Operation not permitted
--8<---cut here---end--->8---

I think kozo[m] on irc was hunting the very same issue as well:
http://logs.guix.gnu.org/guix/2021-03-08.log#035557

Thanks,
 - Jelle

bug#46569: python can't find internal pip modules in environment from manifest

[Jelle Licht]

Maxim Cournoyer  writes:

> Hi Jelle,
>
> Jelle Licht  writes:
>
>> Python can not load all pip-related python modules when loaded from a
>> manifest file, yet seems to work fine when loaded 'directly' as part of
>> a `guix environment'-invocation.
>>
>>
>> Provided that we have a file in `hi.py':
>>
>> import pip
>> print("halfwaypoint")
>> import pip._internal.index.package_finder
>> print("I made it!")
>>
>>
>> and a `manifest.scm' with:
>>
>> (use-modules (gnu) (guix packages)
>>   (gnu packages python)
>>   (gnu packages python-xyz))
>>
>> (packages->manifest (list python python-pip))
>>
>>
>> I can get the expected output by running:
>> `guix environment --pure --ad-hoc python python-pip -- python3 hi.py' =>
>>> halfwaypoint
>>> I made it!
>
> It seems that two pip versions don't cohabit very well.  The same
> happens if you install pip via 'pip install --user pip' (e.g., to
> ~/.local/bin) and try to use it.
>
> You could try using the pip version that comes bundled with Python
> itself (e.g, not installing python-pip in the same profile); if it's the
> only one, it should work.

It doesn't, though, with the exact same error message as above.

Does my example (hi.py) work for you?

bug#46569: python can't find internal pip modules in environment from manifest

[Jelle Licht]

Jelle Licht  writes:

> Jelle Licht  writes:
> This fails:
> guix environment --ad-hoc python-pip python -- python3 hi.py
>
> This works:
> guix environment --ad-hoc python python-pip -- python3 hi.py

This should be the other way around, pasting error on my end.

bug#46569: python can't find internal pip modules in environment from manifest

[Jelle Licht]

Jelle Licht  writes:

> Python can not load all pip-related python modules when loaded from a
> manifest file, yet seems to work fine when loaded 'directly' as part of
> a `guix environment'-invocation.
>
>
> Provided that we have a file in `hi.py':
> --8<---cut here---start->8---
> import pip
> print("halfwaypoint")
> import pip._internal.index.package_finder
> print("I made it!")
> --8<---cut here---end--->8---
>
> and a `manifest.scm' with:
>
> --8<---cut here---start->8---
> (use-modules (gnu) (guix packages)
>(gnu packages python)
>(gnu packages python-xyz))
>
> (packages->manifest (list python python-pip))
> --8<---cut here---end--->8---
>
> I can get the expected output by running:
> `guix environment --pure --ad-hoc python python-pip -- python3 hi.py' =>
>> halfwaypoint
>> I made it!
>
> Yet, when I run the following:
> `guix environment --pure -m manifest.scm -- python3 hi.py' =>
>
> --8<---cut here---start->8---
> halfwaypoint
> Traceback (most recent call last):
>   File "hi.py", line 4, in 
> import pip._internal.index.package_finder
>   File 
> "/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/__init__.py",
>  line 40, in 
> from pip._internal.cli.autocompletion import autocomplete
>   File 
> "/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/cli/autocompletion.py",
>  line 8, in 
> from pip._internal.cli.main_parser import create_main_parser
>   File 
> "/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/cli/main_parser.py",
>  line 11, in 
> from pip._internal.commands import (
>   File 
> "/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/commands/__init__.py",
>  line 6, in 
> from pip._internal.commands.completion import CompletionCommand
>   File 
> "/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/commands/completion.py",
>  line 6, in 
> from pip._internal.cli.base_command import Command
>   File 
> "/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/cli/base_command.py",
>  line 26, in 
> from pip._internal.index import PackageFinder
> ImportError: cannot import name 'PackageFinder' from 'pip._internal.index' 
> (/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/index/__init__.py)
> --8<---cut here---end--->8---
>
> Why is there a difference in the first place? Shouldn't both approaches work?

Using diffoscope, I found the (practical) difference:

$GUIX_ENVIRONMENT/bin/pip3 is
│ │ -destination: 
/gnu/store/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2/bin/pip3
│ │ +destination: 
/gnu/store/d75bwzbla5ybhs0mdw80qy94mawnhhsw-python-pip-20.2.4/bin/pip3

If you make sure that `python-pip' precedes the `python' package in the
manifest, things work out fine. Likewise for the following --ad-hoc
example:

This fails:
guix environment --ad-hoc python-pip python -- python3 hi.py

This works:
guix environment --ad-hoc python python-pip -- python3 hi.py

So it seems the order in which guix sees packages when building profiles
determines how collisions are resolved, good to know :-).

Is the python-included pip package supposed to be broken like this, though?
 - Jelle

bug#46569: python can't find internal pip modules in environment from manifest

[Jelle Licht]

Python can not load all pip-related python modules when loaded from a
manifest file, yet seems to work fine when loaded 'directly' as part of
a `guix environment'-invocation.


Provided that we have a file in `hi.py':
--8<---cut here---start->8---
import pip
print("halfwaypoint")
import pip._internal.index.package_finder
print("I made it!")
--8<---cut here---end--->8---

and a `manifest.scm' with:

--8<---cut here---start->8---
(use-modules (gnu) (guix packages)
 (gnu packages python)
 (gnu packages python-xyz))

(packages->manifest (list python python-pip))
--8<---cut here---end--->8---

I can get the expected output by running:
`guix environment --pure --ad-hoc python python-pip -- python3 hi.py' =>
> halfwaypoint
> I made it!

Yet, when I run the following:
`guix environment --pure -m manifest.scm -- python3 hi.py' =>

--8<---cut here---start->8---
halfwaypoint
Traceback (most recent call last):
  File "hi.py", line 4, in 
import pip._internal.index.package_finder
  File 
"/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/__init__.py",
 line 40, in 
from pip._internal.cli.autocompletion import autocomplete
  File 
"/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/cli/autocompletion.py",
 line 8, in 
from pip._internal.cli.main_parser import create_main_parser
  File 
"/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/cli/main_parser.py",
 line 11, in 
from pip._internal.commands import (
  File 
"/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/commands/__init__.py",
 line 6, in 
from pip._internal.commands.completion import CompletionCommand
  File 
"/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/commands/completion.py",
 line 6, in 
from pip._internal.cli.base_command import Command
  File 
"/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/cli/base_command.py",
 line 26, in 
from pip._internal.index import PackageFinder
ImportError: cannot import name 'PackageFinder' from 'pip._internal.index' 
(/gnu/store/4m5vhlq61qnj36rq60l83xcmgj3mx92j-profile/lib/python3.8/site-packages/pip/_internal/index/__init__.py)
--8<---cut here---end--->8---

Why is there a difference in the first place? Shouldn't both approaches work?

- Jelle

bug#43796: Privacy policy

[Jelle Licht]

Hello,

"pelzflorian (Florian Pelz)"  writes:

> IANAL but I think Guix needs a privacy policy for both its website and
> the Guix software in general.
Thanks for looking into this.

IANAL but I do not think it makes sense to have such a privacy policy at
this moment in time. I'd rather have a person with legal expertise look
at this situation and do the following:

1. Notice that we do need such a policy
2. Draft (or at least proof read) this policy.

The reason for this is two-fold: I think there are enough 'legal' texts
on the Internet of questionable enforcability/applicability, and doing
things this way creates a cargo-cult mentality.

Compare to the questionable habit of unconditionally adding the "The
content of this email is confidential ..."-esque spam outgoing email
(even if that mail is addressed to a public mailing list).

If others disagree in principle or in practice with me on this, that is
fine too of course :-)

- Jelle

bug#43254: emacs-helpful does not build: tests fail

[Jelle Licht]

Pierre Neidhardt  writes:

> Looks like an upstream issue:
>
> https://github.com/Wilfred/helpful/issues/248

Fixed on master with 47640ca67d2bf33d061a1a48527e0a6bf3fbdcf8.

- Jelle

bug#41655: emacs-general fails to build

[Jelle Licht]

"bdju" via Bug reports for GNU Guix  writes:

> guix (GNU Guix) cef87bfea8a842d7dcf9a44c2305478fa6cca9b2
>
> I will attempt to attach the build log. I tried pasting the contents and
> it crashed my mail client. Also, paste.debian.net is down.
> Feel free to advise me on how to send the log in the future, perhaps
> this method is not good.
I've added my log for now:
https://paste.debian.net/1150472/

There are some weird control characters in the log, which might explain
why your mail client did not know how to deal with it.

It seems that it no longer builds since 41a2d6a8 updated emacs-evil;
Updating `emacs-general' to a more recent commit seems to be a bit of
work, as the build system now relies on `makem.sh'.

bug#40558: (no subject)

[Jelle Licht]

elaexuo...@wilsonb.com writes:

> With the patch to texlive-amsfonts the above typesets just fine; however, 
> metafont ends up generating cmmi10.657pk and cmr10.657pk font files. Is this 
> expected? Typsetting it from the texlive installation of my foreign distro 
> doesn't call out to metafont at all.

As I mentioned earlier, I am not a tex expert at all. I have no clue,
but if my patch makes spooky things happen, we should probably hold off
on applying it.

- Jelle

bug#40558: Modular TexLive "Insufficient extension fonts" and duplicate fonts

[Jelle Licht]

Jelle Licht  writes:

> The eror message is:
> " ! Math formula deleted: Insufficient extension fonts."
[snip]
> AFAIK, and from looking at the full (and correctly working)
> texlive-texmf build, the cmex7.tfm in `euler' is not correctly build.
> My best guess is that this happens because cmex has both a mf file and a
> afm file in `guix build --source texlive-amsfonts'. The one 'built'
> using afm2tfm seems to be broken and/or not matching other metadata
> generated, as given by this example.


I have found a workaround for my immediate problem, but I'm not nearly
enough of a tex guru to foresee any issues my changes might cause.

After some trial and error that took longer than I'm willing to admit, I
have the following snippet:
 
--8<---cut here---start->8---
diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index cd461314b5..363c7a318c 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -1108,7 +1108,7 @@ Taco Hoekwater.")
  ;; convert the afm files instead.
  (let ((build (string-append (getcwd) "/build-fonts/euler")))
(mkdir build)
-   (with-directory-excursion "fonts/afm/public/amsfonts/"
+   (with-directory-excursion "fonts/afm/public/amsfonts/euler"
  (for-each (lambda (font)
  (format #t "converting afm font ~a\n" 
(basename font ".afm"))
  (invoke "afm2tfm" font
--8<---cut here---end--->8---

With this patch applied, I can make use of the modular texlive system
from the comfort of Emacs + org. It could be that there are other 'ghost
fonts' haunting up the place. 

The following...
--8<---cut here---start->8---
guix refresh -l texlive-amsfonts
Building the following 1438 packages would ensure 3202 dependent packages are 
rebuilt
--8<---cut here---end--->8---

makes me think this is very much a disruptive change. I'm not in a hurry
to get this upstreamed, but if anyone could reproduce the problem (and
my fix...), I would be more confident in pushing it.

- Jelle

bug#40558: Modular TexLive "Insufficient extension fonts" and duplicate fonts

[Jelle Licht]

I think I found a bug in our amsfonts texlive package. I will describe
my journey in finding this bug, as I still do not have clear picture
on the why/when/what is going on. I think I also saw several other
people running into this issue the last few months, so either way I am
happy to have found something reproducible that at least demonstrates
that I am sane :).

The eror message is:
" ! Math formula deleted: Insufficient extension fonts."

If you, like me, want to use Emacs' org-mode capabilities and export to
pdf using latex, by default you will generate an intermediate .tex file
that uses the ulem package. Using this package leads to the
aforementioned error message.

(Skip everything after this if you do not care about my descent into madness)

I used a profile containing the following (relevant) texlive packages:
--8<---cut here---start->8---
texlive-base
texlive-latex-preview   
texlive-latex-base  
texlive-latexconfig 
texlive-fonts-ec
texlive-latex-oberdiek  
texlive-latex-wrapfig   
texlive-generic-ulem
texlive-latex-capt-of   
texlive-latex-hyperref
texlive-amsfonts
texlive-fontinst
texlive-metafont-base   
texlive-unicode-data
texlive-pstool  
texlive-cm  
texlive-cm-super
texlive-latex-amscls
texlive-fonts-latex 
texlive-latex-amsmath   
--8<---cut here---end--->8---


I ran both `strace pdflatex working 2> working-strace.log' and `strace
pdflatex broken 2> broken-strace.log' See the attached `working.tex'
and `broken.tex' for tiny examples that demonstrate this.

The relevant part of the diff between straces:

* Working:
--8<---cut here---start->8---
access("/home/jlicht/.guix-profile/share/texmf-dist/fonts/tfm/public/amsfonts/cmex7.tfm",
 R_OK) = 0
stat("/home/jlicht/.guix-profile/share/texmf-dist/fonts/tfm/public/amsfonts/cmex7.tfm",
 {st_mode=S_IFREG|0444, st_size=940, ...}) = 0
openat(AT_FDCWD, 
"/home/jlicht/.guix-profile/share/texmf-dist/fonts/tfm/public/amsfonts/cmex7.tfm",
 O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0444, st_size=940, ...}) = 0
read(6, 
"\0\353\0\2\0\0\0\177\0#\0\6\0\16\0\3\0\0\0\0\0\34\0\r\27#\260\255\0p\0\0"..., 
4096) = 940
close(6)= 0
openat(AT_FDCWD, "working.pdf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
write(1, " [1", 3)  = 3
--8<---cut here---end--->8---

* Broken:
--8<---cut here---start->8---
access("/home/jlicht/.guix-profile/share/texmf-dist/fonts/tfm/public/amsfonts/euler/cmex7.tfm",
 R_OK) = 0
stat("/home/jlicht/.guix-profile/share/texmf-dist/fonts/tfm/public/amsfonts/euler/cmex7.tfm",
 {st_mode=S_IFREG|0444, st_size=1312, ...}) = 0
openat(AT_FDCWD, 
"/home/jlicht/.guix-profile/share/texmf-dist/fonts/tfm/public/amsfonts/euler/cmex7.tfm",
 O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0444, st_size=1312, ...}) = 0
read(6, 
"\1H\0\21\0\0\0\332\0*\0\20\0\20\0\6\0\0\0\0\0\0\0\6d\235jM\0\240\0\0"..., 
4096) = 1312
close(6)= 0
write(1, "\n", 1)   = 1
write(1, "! Math formula deleted: Insuffic"..., 54) = 54
--8<---cut here---end--->8---

We see that a different file is used when resolving the same font!
Furthermore, one of these fonts is a totally different size than the
other.


If we run: `guix build --check texlive-amsfonts | grep cmex7', we see:
--8<---cut here---start->8---
Font metrics written on 
/tmp/guix-build-texlive-amsfonts-49435.drv-0/source/build-fonts/cmex7.tfm.
Output written on 
/tmp/guix-build-texlive-amsfonts-49435.drv-0/source/build-fonts/cmex7.600gf 
(128 characters, 30684 bytes).
Transcript written on 
/tmp/guix-build-texlive-amsfonts-49435.drv-0/source/build-fonts/cmex7.log.
converting afm font cmex7
cmex7 CMEX7
`build-fonts/cmex7.600gf' -> 
`/gnu/store/hrxlw7s1d8q0z5kipizjr7ib49bw4hjp-texlive-amsfonts-49435/share/texmf-dist/fonts/tfm/public/amsfonts/cmex7.600gf'
`build-fonts/cmex7.tfm' -> 
`/gnu/store/hrxlw7s1d8q0z5kipizjr7ib49bw4hjp-texlive-amsfonts-49435/share/texmf-dist/fonts/tfm/public/amsfonts/cmex7.tfm'
`build-fonts/euler/cmex7.tfm' -> 
`/gnu/store/hrxlw7s1d8q0z5kipizjr7ib49bw4hjp-texlive-amsfonts-49435/share/texmf-dist/fonts/tfm/public/amsfonts/euler/cmex7.tfm'
--8<---cut here---end--->8---

AFAIK, and from looking at the full (and correctly working)
texlive-texmf build, the cmex7.tfm in `euler' is not correctly build.
My best guess is that this happens because cmex has both a mf file and a
afm file in `guix build --source texlive-amsfonts'. The one 'built'
using afm2tfm seems to be broken and/or not matching other metadata
generated, as given by this example.

Thanks for reading along, I hope we will find a solution to this, as
non-modular texlive is simply the worst :).


working.tex

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

Hi

Brice Waegeneire  writes:

> Hello,
>
> Arun Isaac  writes:
>> FWIW, I fixed our ansible package in
>> https://issues.guix.info/issue/33777 . This is not a general solution,
>> but at least our ansible package works at the moment.
>
> If this bug is about ansible malfunctioning then it should be closed,
> Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
> it myself successfully with the command from the IRC report[0] (linked
> in the merged issue[2]).
> On the other hand If it's about fixing it with the new wrap-script from
> Ricardo I can send a patch, but the derivation will need guile as a new
> input.

I would be okay with closing it, as ansible works fine right now. If the
current solution is deemed too brittle, or if the intent behind the new
wrap-script is that we use it everywhere we can, then not of course.

- Jelle

bug#38715: Issue with guile-email: unbound variable

[Jelle Licht]

Arun Isaac  writes:

>> My best guess is that this has something to do with a circular
>> reference between guile modules, but I am not certain on how to easily
>> debug (and fix) this.
>
> I updated the guile-email package two days ago. I hope that is not what
> introduced this problem, and I don't see how it could have. Even `guix
> build guile-email` on the terminal fails with a guile-email unbound
> variable error.

I do not think it was that commit, as I found the offending commit:
c7b2b539802eaa3f969e212c98eb671a1a75e9f3

This is the commit that adds mumimu to gnu/packages/mail.scm, as well as
to the inputs of mumi. Reverting this commit (at least) solves the issue
I had in the first mail.

Could it be that the reference to guile-email in the version field of
mumimu created this issue?
--8<---cut here---start->8---
(version (git-version (package-version guile-email) revision commit))
--8<---cut here---end--->8---

- Jelle

bug#38715: Issue with guile-email: unbound variable

[Jelle Licht]

Hey guix,

Pretty recently, it seems something weird is happening when playing with
guix on the REPL.

On master, 5a947e118fb72b8fb1fd0c8d0b783fc7cde0c461:

--8<---cut here---start->8---
$ guix repl
> (use-modules (gnu packages gnupg))
While compiling expression:
error: guile-email: unbound variable.
--8<---cut here---end--->8---

Loading up the `(gnu packages mail)' module first seems to work around
the compilation error. My best guess is that this has something to do
with a circular reference between guile modules, but I am not certain on
how to easily debug (and fix) this.

- Jelle

bug#38568: Org Mode (as a dependency) is borked

[Jelle Licht]

Hey Guix, 

Org-mode seems to still have some byte compilation issues when used as a
dependency for other packages. The specific symptom is extremely similar
to the one reported and fixed at [http://issues.guix.info/issue/38479].

To reproduce:
 1) Install emacs-org-jira in your profile, and set it up (lots of
annoying steps with API tokens, authinfo etc etc)
 2) Run `M-x org-jira-get-boards':
--8<---cut here---start->8---
org-jira--render-board: Symbol’s function definition is void: 
org-outline-overlay-data
--8<---cut here---end--->8---

To see the issue without reproducing it (using bash):
--8<---cut here---start->8---
$ grep -rni 'org-outline-overlay-data' $(guix build emacs-org-jira)
--8<---cut here---end--->8---

This gives:
--8<---cut here---start->8---
Binary file org-jira.elc matches
--8<---cut here---end--->8---

Byte-compiling the org-jira.el file manually gives an .elc file without
a reference to `org-outline-overlay-data'. This leads me to believe that
the previously posted fix for #38479 could be extended to make sure
Emacs' built-in packages are at the trailing end of EMACSLOADPATH, so
after any other packages. 

Regards,
Jelle



 

bug#37309: ‘ssh-daemon’ service fails to start at boot

[Jelle Licht]

Hi Giovanni,


Giovanni Biscuolo  writes:

> Hi Jelle,
>
> Jelle Licht  writes:
>
> [...]
>
>> I think I am also running into a similar issue on my spinning rust based
>> T400. Is there a workaround available that does the above,
>
> I added `(extra-content "ListenAddress 0.0.0.0")` to my
> openssh-configuration, to only listen on IPv4 addresses:
>
> --8<---cut here---start->8---
> (service openssh-service-type
> (openssh-configuration
>  (port-number 22)
>  (extra-content "ListenAddress 0.0.0.0")
>  (authorized-keys
>   `(("g" ,(local-file "keys/ssh/g.pub"))
> ("hydra",(local-file "keys/ssh/hydra.pub"))
> --8<---cut here---end--->8---
>
> I tried to reboot several times one machine I can use for testing and it
> works for me: please can you try and report if this also works for you?

This, in combination with setting the pid-file-timeout to 30 seconds,
made everything work! I guess it is a combination of fun IPv6
interactions with extremely slow and busy spinning rust.

Thank you!

This does still like a workaround instead of a proper fix though; is
there something we can do to mitigate these issues in the first place?

- Jelle

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

[Jelle Licht]

Maxim Cournoyer  writes:

> [...]
> I've tested these changes with a Gnome VM and the EMACSLOADPATH is now
> reduced to just the Emacs' lisp directory as well as the
> share/emacs/site-lisp directory of any profile.  Thanks for the great
> ideas :-).

Would this still allow Emacs to load packages from Guix' environments as well?

bug#37309: ‘ssh-daemon’ service fails to start at boot

[Jelle Licht]

Hey 宋文武, Giovanni,

iyzs...@member.fsf.org (宋文武) writes:

> [...]
> Yes, I think when 'ssh-daemon' failed to start, shepherd should respawn
> it until success or disable it, but by look at the code of
> 'make-forkexec-constructor', when using 'pid-file' (as 'ssh-ademon'
> does), and a timeout (default to 5s %pid-file-timeout) is reached, the
> processes got a 'SIGTERM' and return '#f' as its running state, which
> won't be respawn (it's not a pid number) I guess...
>
> To ludo: Is my analysis correct?  It's not clear to me how to fix it so
> 'ssh-daemon' can be respawn though...

I think I am also running into a similar issue on my spinning rust based
T400. Is there a workaround available that does the above, or is that
analysis of the situation not correct either?

Thanks,

Jelle

bug#34526: Updating node.js

[Jelle Licht]

Christopher Lemmer Webber  writes:

> That's fair.
>
> I have a personal project that requires that I use a newer version of
> Node (at least version 11).  So if anyone has a recipe on how to get
> Node running, even the wrong way per Guix standards, maybe useful to
> post to this bug in the meanwhile?  It might also still help advance
> this bug.

I tried my hand at building llhttp (again...) using our existing nodejs
+ Sucrase (an alternative TypeScript transpiler that does not have too
many dependencies), but it seems that the devs of llhttp use
semi-advanced TypeScript constructs that are at the moment not supported
by Sucrase's transformers. To be specific, I am talking about "Moving
types"[1].

Does anyone know of any other TypeScript transpilers? They do not need
to do typechecking, as long as they allow generation of (valid)
JavaScript files.

- Jelle

[1]: https://basarat.gitbooks.io/typescript/docs/types/moving-types.html

bug#38190: Icecat 68.2.0-guix0-preview3 does not play H264/MP4

[Jelle Licht]

On latest master, with the following icecat package:
 icecat 68.2.0-guix0-preview3   out 
/gnu/store/zqzhirykpqhay8n768aqqg4xplrmpfwz-icecat-68.2.0-guix0-preview3

On the console (via ) I find the following message on websites with
embedded videos:

 The video on this page can’t be played. Your system may not have the
 required video codecs for: video/mp4; codecs="avc1.42E01E mp4a.40.2

bug#37759: network-manager-openvpn broken since network-manager-applet update

[Jelle Licht]

Commit 8fc3a337ab420dc9f80472ce057eae603fc892d3, the update of
network-manager-applet to 1.8.24, broke network-manager-openvpn:

--8<---cut here---start->8---
checking for LIBNM_GTK... no
configure: error: Package requirements (libnm-gtk >= 1.7.0) were not met:

No package 'libnm-gtk' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBNM_GTK_CFLAGS
and LIBNM_GTK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
command 
"/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" 
"./configure" 
"CONFIG_SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash"
 
"SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" 
"--prefix=/gnu/store/0rgybwyxiy7b74byqr3ld303l7iy99jx-network-manager-openvpn-1.8.4"
 "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" 
"--enable-absolute-paths" "--localstatedir=/var" failed with status 1
builder for 
`/gnu/store/jbbzxdd8jqjdp7hj1jskd09cyggrrl0k-network-manager-openvpn-1.8.4.drv' 
failed with exit code 1
--8<---cut here---end--->8---

I already verified that updating network-manager-openvpn to the latest
release (1.8.10) does not fix this issue.

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Jelle Licht]

Bengt Richter  writes:

> [snip]
> ...
> [19:40 ~/bs]$ ping guix.gnu.org
> ping: guix.gnu.org: Name or service not known
I actually have this sometimes as well. Are you on a less-than-stellar
WiFi-connection perhaps? I noticed the default (nscd?) configuration on
Guix systems caches 'negative' results for quite a while.

Could you try this command again after issuing:
`sudo herd invalidate nscd hosts'?

HTH!
- Jelle

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Jelle Licht]

> [snip]
> I didn't have time to refresh it to our current version - it's just in the 
> mail:
>
> https://www.mail-archive.com/bug-guix@gnu.org/msg11776.html

Closing, this was fixed a while ago in commit
40557aeab594907bf56b0a2a367061dbdd19f4aa.

bug#37421: [PATCH] gnu: node: Disable tests that fail with openssl@1.1.1d.

[Jelle Licht]

Tobias Geerinckx-Rice  writes:

> Ludovic Courtès 写道：
>> Could we take a look at what these failures are about to see how 
>> bad
>> that might be?
>
> Jelle Licht 写道：
>> Interestingly enough, https://github.com/nodejs/node/issues/3881 
>> notes
>> issues with exactly these two tests. Perhaps there is a 
>> regressions in
>> our case?
>
> Thanks, and indeed!  That is _quite_ the coincidence…
>
> Unfortunately, I don't see any mention of a time-out in my logs & 
> the truncation of the backtrace
>
>   at Object. (…/test/parallel/test-crypto-dh.js:124:8)
>   at Module._compile (internal/modules/cjs/loader.js:701:30)
>   at Object.Module._extensions..js 
>   (internal/modules/cjs/loader.js:712:10)
>   at Module.load (internal/modules/cjs/loader.js:600:32)
>   at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
>   at Function.Module._load (internal/modules/cjs/loader.js:531:3)
>   at Function.Module.runMain 
>   (internal/modules/cjs/loader.js:754:12)
>   at startup (internal/bootstrap/node.js:283:19)
>   at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)
>   ...
>
> happens at run time: grepping the output of ‘--keep’ doesn't 
> reveal a more complete one :-(
>
> I don't know how to hack the tests to spit out more.  Someone who 
> knows node/js more than I do needs to step in and save us.  Is 
> that you, Jelle? :-)

I believe in learning by doing, so I'll have a go at it somewhere early
next week :-).

For now, I think it makes sense to push this patch so we can have a
(hopefully) working and secure ungoogled-chromium.

>
> Kind regards,
>
> T G-R

bug#37421: [PATCH] gnu: node: Disable tests that fail with openssl@1.1.1d.

[Jelle Licht]

Ludovic Courtès  writes:

> Hello,
>
> Tobias Geerinckx-Rice via Bug reports for GNU Guix 
> skribis:
>
>> Work around .
>>
>> * gnu/packages/node.scm (node)[arguments]: Disable failing tests.
>
> [...]
>
>> + ;; FIXME: These tests fail with openssl@1.1.1d.
>> + (for-each delete-file
>> +   '("test/parallel/test-crypto-binary-default.js"
>> + "test/parallel/test-crypto-dh.js"))
>
> It may be the best short-term solution.
Agreed, if ungoogled-chromium works with this that would probably be the
best option.
>
> Could we take a look at what these failures are about to see how bad
> that might be?

Interestingly enough, https://github.com/nodejs/node/issues/3881 notes
issues with exactly these two tests. Perhaps there is a regressions in
our case?

bug#37386: ungoogled-chromium broken because of openssl update

[Jelle Licht]

Commit cf065aba1ec14bdacab7a5a6bddbdfd7661cd409 seems to have broken
node, which subsequently broke ungoogled-chromium. It should still be
possible to upgrade node to the latest LTS version 10.16.3, but this
requires an upgrade to the following rebuild-the-world packages:
- libuv
- nghttp2

What do we do?

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Jelle Licht]

Hi S_W, Maxim

Tomáš Čech  writes:

> Hi Ludo,
> [...]
>
> But with Maxim's DBus related patches and my NM patch it seemed to be
> starting daemons at least.

Do you still have the patches for these changes lying around? I am
trying to get network-manager-vpnc packaged+working, but it seems this
issue will also need to be solved first.
>
> Best regards,
>
> S_W

All the best,

Jelle

bug#34754: evil-magit 20190224 has missing dependency

[Jelle Licht]

It seems the recently pushed evil-magit update is incomplete. Loading
and subsequently enabling it leads to a warning and degraded/no of
functionality:

--8<---cut here---start->8---
Debugger entered--Lisp error: (void-function transient-suffix-put)
--8<---cut here---end--->8---

I *think* it might simply be resolved by packaging the relatively new
transient package[1]. It might be a bit more involved as we still have
an 'older' (=non-master) version of magit packaged as well.

[1]  https://github.com/magit/transient

bug#27217: texlive is too big

[Jelle Licht]

Pierre Neidhardt  writes:

> For posterity, here is a python importer for tlpdb:
>
> https://github.com/amaxwell/tlutility/blob/master/parse_tlpdb.py
>
> (Thanks to Henkjan for sharing this.)
>
> Jelle, did you work on the importer any further after FOSDEM?
> Can you share the file, I'm afraid I lost the link :p

As a matter of fact, I did! I am not at home with my guix-related work
right now. The short of it, is that I created a simple record type
(e.g. `tlpdb-package'). The tlpdb-parser we worked on at FOSDEM was able
to generate these structures from the tlpdb file, although translating
tlpdb-package records into actual guix packages was a step I did not
work on yet.

One of the problems I ran into was exactly what Ricardo described; the
fact that sources for texlive packages currently have a slight semantic
mismatch with what we have for most guix packages. If we have a solution
for this, the result of *any* of our importers would look a lot nicer.

bug#34526: Updating node.js

[Jelle Licht]

Daniel Gerber  writes:

>   [snip]
> What about statically linking llhttp's C "sources" included in
> node?   Building v11.10.0 succeeds with this:
>

You could do this, of course, but afaics this is not acceptable for
inclusion in Guix proper.

I don't really see any way forward between convincing the fine node
folks to see the 'error of their ways', or to implement a ABI-compatible
replacement for llhttp that we can actually bootstrap.

bug#34565: ungoogled-chromium contains Widevine DRM

[Jelle Licht]

Jason Self  writes:

> Leo Famulari wrote:
>> To clarify this general point about Guix for anyone who is reading
>> along, as a matter of policy the end user does not receive non-free
>> source code from Guix.
>
> Right; the source is downloaded from commondatastorage.googleapis.com
> but that is a technicality. What I'm saying is that the recipe should
> be updated to cause it to download an already-cleaned up version
> directly from Guix (it could be hosted somewhere on gnu.org for example
> but exactly where can be up for negotiation) and that this excuse of

I would argue that this way of thinking is one of the issues Guix and
the broader reproducible builds community is trying to solve (in an
ethical way). Practical software freedom also includes the possibility
of not being dependent on even the gnu.org infrastructure.

> "they're getting it elsewhere" shouldn't be usable as an excuse to
> sidestep the FSDG. It's still causing the user to download the software
> due to the recipes provided by Guix.

The implied tone of your message comes across as needlessly
aggressive. I am not sure if the GNU Kind Communications Guidelines
apply here, but I still urge you to give the broader Guix community the
benefit of the doubt in that they are committed to the FSDG and
everything it entails.

This is like arguing that curl could be used to download proprietary
software; An unmodified Guix will never present a user with non-free
software. If it does, this can be considered a bug and should be fixed
ASAP. Your proposal implies that someone else still downloads the
nonfree upstream sources to modify them, so I see this as even more of a
case of working around the spirit of the FSDG.

>
>> The tools provided by Guix to access source code only return source
>> code that is freely licensed. If the sources have to be modified to
>> ensure this, the unodified source code is not provided to the user.
>
> It's still being downloaded into their computer and then being cleaned
> up after the fact. If there weren't freedom problems with it there
> wouldn't be a need for a clean-up program (ungoogled-chromium in this
> case) to be running -- as a process on the user's computer -- to do
> this.

I do not really get the point you are trying to make, because the
software has to be downloaded at some point in time. Offering a
transparent solution in the form of the Guix store, where the
problematic bits of software only exist in a transient state seems like
it improves the situation across the board.

Whether this fits the letter of the FSDG is an interesting discussion to
be had, but arguing that it goes against the core principles is simply
silly :).

>
> And inhttps://www.gnu.org/distros/free-system-distribution-guidelines.
> htmlwe have:
>
> "For instance, a free system distribution must not contain browsers that 
> implement EME, the browser functionality designed to load DRM modules."
>
> So that should make it quite clear.

I feel most folks here agree on this, at least, so if ungoogled-chromium
still implements a functioning EME, that is a bug.

Respectfully yours,
- Jelle

bug#34526: Updating node.js

[Jelle Licht]

Daniel Gerber  writes:

> Notes on v11.10.0:
> - it does support openssl@1.1.1
> - it ships with libuv 1.26.0 (1.24.0 in guix)
> - some previously bundled deps are absent from tarball
> - NODE_EXPERIMENTAL_HTTP is a no-op / always defined
>
> There is an issue with the alternative http parser, `llhttp`. The
> choice of parser is at runtime, and one compile flag,
> --shared-http-parser, configures both. Building fails with:

> [snip]

> ../src/http_parser_adaptor.h:5:21: fatal error: llhttp.h: No such
> file or directory
> ```
>
> AFAIU, either llhttp has to be made a separate package and listed
> in inputs, or http-parser linked statically. Or should the missing
> -I../deps/llhttp/include argument be passed here somehow -- maybe
> patching node.gypi?

It seems that llhttp includes a build step for generating C-files using
TypeScript, making it a non-starter for proper packaging in Guix.

See https://github.com/nodejs/llhttp/issues/14 for more details, but
sadly no solution.

>
> I have not tried to build 10.15.1(LTS), which presumably has the
> same issues as in #32095.
>
> Also, should previous version branches (8.x, 9.x) be kept in guix?

As long as they are still supported by upstream, I see no issue with
this. The 8.x LTS is still maintained through the end of 2019.

I am not sure the 9.X series is still supported. If not, it might make
more sense to remove it instead of updating it.

bug#33285: Installing, then removing, a package yields a different profile

[Jelle Licht]

Ricardo Wurmus  writes:

> [snip]
>
> I think it’s fine to leave it as it is, then.  “--install” and
> “--remove” are stateful and should be expected to have quirks like this.
> (E.g. upgrading Guix in between two “--install”s can lead to
> a mosaic of a profile that could not be produced any other way.)

This seems like a very reasonable perspective on this issue, so I
concur. Should we state this explicitly somewhere in the manual?

bug#34047: gnu: emacs-closql: Hash mismatch.

[Jelle Licht]

Oleg Pykhalov  writes: 

[...]  HEAD is now at 012b94f Release version 1.0.0 r:sha256 
hash mismatch for 
/gnu/store/vy3m2n81i2ncpf65fnsq513dkwypzvr5-emacs-closql-1.0.0-checkout: 
  expected hash: 
  0cy44d1fxkvah6fhjkn3mp6gzzrjmws1c4c20ayrma74y9xich3v actual 
  hash:   1xhpfjjkjqfc1k2rj77cscclz5r7gpvv3hi202x178vdcpipjwar 
hash mismatch for store item 
'/gnu/store/vy3m2n81i2ncpf65fnsq513dkwypzvr5-emacs-closql-1.0.0-checkout' 
build of 
/gnu/store/vrjbbp4n0kda1b7y98szwpv3n0pxm7nk-emacs-closql-1.0.0-checkout.drv 
failed View build log at 
'/var/log/guix/drvs/vr/jbbp4n0kda1b7y98szwpv3n0pxm7nk-emacs-closql-1.0.0-checkout.drv.bz2'. 
killing process 14669 cannot build derivation 
`/gnu/store/ykn80wrvznp2fp069yj9v7lnys7vqv6r-emacs-closql-1.0.0.drv': 
1 dependencies couldn't be built guix build: error: build 
failed: build of 
`/gnu/store/ykn80wrvznp2fp069yj9v7lnys7vqv6r-emacs-closql-1.0.0.drv' 
failed 


You are totally right, my bad. Thanks for catching this!  Fixed in 
b03131902e2618de10d6be15531ca2b44717d397 on master.   For the 
interested, a snippet from IRC explaining my mistake: 
--8<---cut here---start->8--- 
2019-01-15 21:55  It _probably_ had something to do with 
the fact 
 that I was messing around with several 
 versions of emacs-closql before settling 
 on the final one, but not updating the 
 hash
2019-01-15 21:55  (which then worked because of the fun 
and 
 interesting ways in which 
 already-downloaded sources are 
 referenced, I guess?) 

[...] 


2019-01-15 21:55  jlicht: i see!
2019-01-15 21:56  jlicht: it'd be nice to check the diff 
and explain 
  in the commit log next time, just to be 
  on the safe side!

2019-01-15 21:56  anyway, I took some time to verify that that new
 hash is the actual one we want, using some vpn's
 and some contact with coworkers. My apologies for
 any bad dreams it may have given people
--8<---cut here---end--->8---

Thanks again Oleg for being so attentive.

bug#33616: biber build failure

[Jelle Licht]

Danny Milosavljevic  writes:

> [...]
> Result: FAIL
> Failed 16/43 test programs. 132/1061 subtests failed.

I pushed 41a010875ba4108e666f11fc111cf5bb5dcf5464 some days ago, and
biber seems to build correctly now. Could you check whether it now works
for you?

Thanks

bug#32293: wrap-program with non-colon separtor produces incorrect bash substitutions

[Jelle Licht]

Hi all,

While working to package some lua-related stuff, I need to deal with the
LUA_PATH environment variable. This variable uses `;' as a separator, and
as such, I wanted to wrap one of my programs

--8<---cut here---start->8---
...
(wrap-program (string-append out "/bin/fennel")
   `("LUA_PATH" ";" prefix (,path)))
...
--8<---cut here---end--->8---

... which gives me the following snippet for the fennel script:

--8<---cut here---start->8---
export 
LUA_PATH="/gnu/store/3yjzvzwczi37snccrxbw7xsmbns1qc7a-fennel-1-1.f2a3d3b/share/lua/5.3/?.lua${LUA_PATH;+;}$LUA_PATH"
--8<---cut here---end--->8---

... which is not a correct bash substitution. I _think_ the first `;' in
`{LUA_PATH;+;}' needs to be a colon instead, at least if `wrap-program'
is only used to generate bash-compliant wrappers.

It seems this can be (easily?) fixed around guix/build/utils.scm:1055,
but any changes I made there had me starting to build bash and other
things from scratch.

bug#31227: emacs-lispy is broken

[Jelle Licht]

Fixed in e5d57c1c0 on master.

2018-05-04 15:49 GMT+02:00 Jelle Licht <jli...@fsfe.org>:

> *https://github.com/abo-abo/lispy/pull/427
> ^ is the correct link; sorry for the typo
>
> 2018-05-04 15:48 GMT+02:00 Jelle Licht <jli...@fsfe.org>:
>
>> I ran into something similar using emacs-lispy. Perhaps my PR also fixes
>> your issue?
>>
>> https://github.com/abo-abo/lispy/pull/426
>>
>>
>>
>> 2018-04-20 17:56 GMT+02:00 Clément Lassieur <clem...@lassieur.org>:
>>
>>> Hi,
>>>
>>> emacs-lispy is broken (void-variable hydra-lispy-x on load) since commit
>>> b5904fcc34596e0aabb85020808b746e4c8b39a0.
>>>
>>> Clément
>>>
>>>
>>>
>>>
>>
>

bug#31227: emacs-lispy is broken

[Jelle Licht]

*https://github.com/abo-abo/lispy/pull/427
^ is the correct link; sorry for the typo

2018-05-04 15:48 GMT+02:00 Jelle Licht <jli...@fsfe.org>:

> I ran into something similar using emacs-lispy. Perhaps my PR also fixes
> your issue?
>
> https://github.com/abo-abo/lispy/pull/426
>
>
>
> 2018-04-20 17:56 GMT+02:00 Clément Lassieur <clem...@lassieur.org>:
>
>> Hi,
>>
>> emacs-lispy is broken (void-variable hydra-lispy-x on load) since commit
>> b5904fcc34596e0aabb85020808b746e4c8b39a0.
>>
>> Clément
>>
>>
>>
>>
>

bug#31227: emacs-lispy is broken

[Jelle Licht]

I ran into something similar using emacs-lispy. Perhaps my PR also fixes
your issue?

https://github.com/abo-abo/lispy/pull/426



2018-04-20 17:56 GMT+02:00 Clément Lassieur :

> Hi,
>
> emacs-lispy is broken (void-variable hydra-lispy-x on load) since commit
> b5904fcc34596e0aabb85020808b746e4c8b39a0.
>
> Clément
>
>
>
>

bug#31299: Ansible depends on $0, which does not work for wrapped python scripts.

[Jelle Licht]

Ansible currently is broken.
As noted by sturm/Guest2732 on #guix, running any `ansible-'
commands leads ansible to think that we are calling the `ansible' script
directly, instead of via a `ansible-' script.

This is related to [1], and possibly might be solved by [2].


[1]: http://lists.gnu.org/archive/html/bug-guix/2017-05/msg00015.html
[2]: http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00017.html

bug#31190: Ansible doesn't build

[Jelle Licht]

I pushed my version of the patches that fix our ansible build as
`09e3cf583437ce421215dd28d2b94f574458b311'
and `acc6e6955f5d481cf984cafb0459d3489feda99e' to master.

bug#31190: Ansible doesn't build

[Jelle Licht]

2018-04-17 22:56 GMT+02:00 Marius Bakke <mba...@fastmail.com>:

> Jelle Licht <jli...@fsfe.org> writes:
>
> > From f770998d0f0b56180e0c9a12f0946a77d7ff61a5 Mon Sep 17 00:00:00 2001
> > From: Jelle Licht <jli...@fsfe.org>
> > Date: Tue, 17 Apr 2018 21:31:05 +0200
> > Subject: [PATCH] gnu: ansible: Add missing inputs
> >
> > * gnu/packages/admin.scm (ansible)[native-inputs]: Add python2-bcrypt and
> >   python2-pynacl.
> > ---
> >  gnu/packages/admin.scm | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
> > index aed997e5b..07401af72 100644
> > --- a/gnu/packages/admin.scm
> > +++ b/gnu/packages/admin.scm
> > @@ -73,6 +73,7 @@
> >#:use-module (gnu packages pkg-config)
> >#:use-module (gnu packages popt)
> >#:use-module (gnu packages python)
> > +  #:use-module (gnu packages password-utils)
> >#:use-module (gnu packages python-crypto)
> >#:use-module (gnu packages python-web)
> >#:use-module (gnu packages terminals)
>
> This introduces a circular dependency between (gnu packages admin) and
> (gnu packages password-utils).  Perhaps we should move python-bcrypt to
> python-crypto.scm.  Thoughts?
>

Makes sense to me. The `python-py-bcrypt' package is already located there
so it would make sense to have similar packages in the same place.

bug#31190: Ansible doesn't build

[Jelle Licht]

2018-04-17 11:40 GMT+02:00 Clément Lassieur <clem...@lassieur.org>:

> starting phase `check'
> running "python setup.py" with command "test" and parameters ()
> running test
> Searching for pynacl>=1.0.1
> Reading https://pypi.python.org/simple/pynacl/
> Download error on https://pypi.python.org/simple/pynacl/: [Errno -2] Name
> or service not known -- Some packages may not be found!
> Couldn't find index page for 'pynacl' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading https://pypi.python.org/simple/
> Download error on https://pypi.python.org/simple/: [Errno -2] Name or
> service not known -- Some packages may not be found!
> No local packages or working download links found for pynacl>=1.0.1
> error: Could not find suitable distribution for
> Requirement.parse('pynacl>=1.0.1')
> phase `check' failed after 0.5 seconds
> builder for `/gnu/store/4mmlsi4rw7iwaw1nghkixbx859vi24ad-ansible-2.4.2.0.drv'
> failed with exit code 1
> @ build-failed /gnu/store/4mmlsi4rw7iwaw1nghkixbx859vi24ad-ansible-2.4.2.0.drv
> - 1 builder for 
> `/gnu/store/4mmlsi4rw7iwaw1nghkixbx859vi24ad-ansible-2.4.2.0.drv'
> failed with exit code 1
> guix build: error: build failed: build of `/gnu/store/
> 4mmlsi4rw7iwaw1nghkixbx859vi24ad-ansible-2.4.2.0.drv' failed
>
>
>
>
The attached patches should fix this issue, but I am currently not able to
build them myself.
Could someone review + verify them?

- Jelle
From 1c978fad25da3847d55fd6879a4473e84a9b02ff Mon Sep 17 00:00:00 2001
From: Jelle Licht <jli...@fsfe.org>
Date: Tue, 17 Apr 2018 21:29:41 +0200
Subject: [PATCH] gnu: Add python2-pynacl.

* gnu/packages/python-crypto.scm (python2-pynacl): New variable.
---
 gnu/packages/python-crypto.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/packages/python-crypto.scm b/gnu/packages/python-crypto.scm
index ace0891a7..9d5c35cac 100644
--- a/gnu/packages/python-crypto.scm
+++ b/gnu/packages/python-crypto.scm
@@ -587,6 +587,9 @@ Networking and Cryptography library.  These libraries have a stated goal
 of improving usability, security and speed.")
 (license license:asl2.0)))
 
+(define-public python2-pynacl
+  (package-with-python2 python-pynacl))
+
 (define-public python2-pgpdump
   (package
 (name "python2-pgpdump")
-- 
2.17.0

From f770998d0f0b56180e0c9a12f0946a77d7ff61a5 Mon Sep 17 00:00:00 2001
From: Jelle Licht <jli...@fsfe.org>
Date: Tue, 17 Apr 2018 21:31:05 +0200
Subject: [PATCH] gnu: ansible: Add missing inputs

* gnu/packages/admin.scm (ansible)[native-inputs]: Add python2-bcrypt and
  python2-pynacl.
---
 gnu/packages/admin.scm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index aed997e5b..07401af72 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -73,6 +73,7 @@
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages popt)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages password-utils)
   #:use-module (gnu packages python-crypto)
   #:use-module (gnu packages python-web)
   #:use-module (gnu packages terminals)
@@ -1522,7 +1523,9 @@ of supported upstream metrics systems simultaneously.")
(patches (search-patches "ansible-wrap-program-hack.patch"
 (build-system python-build-system)
 (native-inputs
- `(("python2-pycrypto" ,python2-pycrypto)
+ `(("python2-bcrypt" ,python2-bcrypt)
+   ("python2-pycrypto" ,python2-pycrypto)
+   ("python2-pynacl" ,python2-pynacl)
("python2-httplib2" ,python2-httplib2)
("python2-passlib" ,python2-passlib)
("python2-nose" ,python2-nose)
-- 
2.17.0

bug#30896: Guix pull problems on armhf

[Jelle Licht]

I have been running the binary Guix installation on top of Armbian 
on my

Rockchip RK3288 (armhf) based computing platform.

Up till about ~8 days ago, guix pull worked as intended. Recently,
running guix pull leads to the following error message
`./guix/build/pull.scm:44:20: ./guix/build/pull.scm:44:20: Throw 
to key

`match-error' with args `("match" "no matching pattern"' [1]


I already checked that re{moving,naming} 
`$HOME/.config/guix/latest'
does not change anything. Neither does running `./pre-inst-env 
guix

pull' from a git checkout.

[1]: For the full log, see: https://paste.debian.net/1015219/

--
Jelle Licht

bug#29892: dvtm does not properly export terminfo

[Jelle Licht]

Hello,

2018-01-01 18:19 GMT+01:00 Ludovic Courtès <l...@gnu.org>:

> Hi!
>
> Jelle Licht <jli...@fsfe.org> skribis:
>
> > As far as I can see, the current version of dvtm does not work properly
> > with programs such as htop etc.
> >
> > To reproduce:
> > ```
> > $ guix package -i dvtm
> > $ dvtm
> > $ htop
> > ```
> > It only worked properly once I added something like:
> > `export TERMINFO_DIRS="/home/jelle/.guix-profile/share/terminfo"`.
> >
> > Would a proper fix be to simply add a native-search-path declaration to
> the
> > dvtm package? If so, I can prepare a patch this weekend.
>
> ‘TERMINFO_DIRS’ is a search path of ncurses.  However, because search
> paths of dependencies are not honored, it doesn’t get set:
>
>   https://bugs.gnu.org/22138
>
> This is what we should fix.
>
Fixing this properly seems like it would take effort indeed.


>
> It would feel wrong to add ‘TERMINFO_DIRS’ as a search path of dvtm and
> everything that depends on ncurses.
>

Am I correct in assuming that as a temporary (personal) workaround, I can
just
install ncurses in my profile as well?

Perhaps guix can warn if you install a package which has a dependency
with a search path like ncurses? Or would this be too much of a hassle
to implement?

It would not solve the issue, but at least prevent people from
not understanding why their packages are not working. WDYT?

>
> Thanks,
> Ludo’.
>

- Jelle

bug#29892: dvtm does not properly export terminfo

[Jelle Licht]

As far as I can see, the current version of dvtm does not work properly
with programs such as htop etc.

To reproduce:
```
$ guix package -i dvtm
$ dvtm
$ htop
```
It only worked properly once I added something like:
`export TERMINFO_DIRS="/home/jelle/.guix-profile/share/terminfo"`.

Would a proper fix be to simply add a native-search-path declaration to the
dvtm package? If so, I can prepare a patch this weekend.

Thanks,
Jelle

bug#29890: guix package --search broken due to texinfo error

[Jelle Licht]

Hello all,

since d596fea5fd (gnu: Add ledger-agent), I believe that searching packages
on the command line user either `guix package -s '  or `guix package
--search=' is broken. I believe something is going wrong with the
description field of the ledger-agent package, as I can see a stacktrace
shows some texinfo parser problem regarding the use of "--connect" in the
ledger-agent package.

Kind regards,
Jelle

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Jelle Licht]

2017-11-30 23:41 GMT+01:00 Adam Van Ymeren :

> I haven't had time to dig in to this further, but in case anyone wants
> to fix rustc-1.16.0, it's broken after the upgrade of jemalloc to 5.0.1.
>
> Reverting commit 475b99fa5cf402430aa93a40e406e854ad2ff6e4 which reverts
> jemalloc back to 4.5.0 causes rustc to build successfully again.  It has
> been broken for some time.
>
> https://hydra.gnu.org/job/gnu/master/rustc-1.16.0.x86_64-linux
>
>
>
>
It seems that the bundled copy of jemalloc in the rustc repo is currently
pinned at 4.5.0 partially
because of this specific issue as well.

I did find an issue on the rust GH repo [0], and it seems this also affects
the nix-rust project,
who seem to have the same errors as our currently failing build [1].

A temporary workaround could be to have a custom version of jemalloc with
the c++ features disabled
by building with `--disable-cxx'. Alternatively, we could just make use of
jemalloc 4.5.0 for rustc only
until this is all sorted our by upstream.

[0]: https://github.com/rust-lang/rust/issues/43586
[1]: https://gist.github.com/marmistrz/a6e503a5491df80a493030e0a0e702d2

bug#28840: openrct2 cannot find data-path

[Jelle Licht]

Ludovic Courtès <l...@gnu.org> writes:

> Hello,
>
> Jelle Licht <jli...@fsfe.org> skribis:
>
>> Rutger Helling <rhell...@mykolab.com> writes:
>>
>>> Hi Ludo and Jelle,
>>>
>>> I've attached a patch that fixed the issue for me by changing some
>>> references from /usr/share to /gnu/store/-openrct2-0.1.1/share.
>>> I can now run openrct2 without the additional parameter.
>>
>> I can confirm that Rutger's patch works as intented.
>
> Awesome.  Could you push it?

Pushed as 2e205c619334 on master.

bug#28840: openrct2 cannot find data-path

[Jelle Licht]

Rutger Helling  writes:

> Hi Ludo and Jelle,
>
> I've attached a patch that fixed the issue for me by changing some
> references from /usr/share to /gnu/store/-openrct2-0.1.1/share.
> I can now run openrct2 without the additional parameter.

I can confirm that Rutger's patch works as intented.

bug#28840: openrct2 cannot find data-path

[Jelle Licht]

Hi Ludo,

No, I am talking about resources such as shaders and
language packs, which seem to be included in openrct2 itself.
IOW, even *with* the data files from the proprietary rct2, our current
openrct2
does not run without the command line flags I added to my first posting :-).

Cheers,
Jelle

2017-10-20 18:01 GMT+02:00 Ludovic Courtès <l...@gnu.org>:

> Hi Jelle,
>
> Jelle Licht <wordemp...@gmail.com> skribis:
>
> > The recently committed (and awesome) openrct2 built correctly,
> > but cannot currently find the needed language and shader files
> > for the game and therefore crashes. To make it work, I currently
> > have to invoke it via a command like
> > `--openrct-data-path=/gnu/store/-openrct2-0.1.1/share/openrct2/',
> > which imho is not optimal.
> >
> > I dove into the source of openrct, and it seems there are still
> > some vestiges of the cmake flag we want, namely
> > ORCT2_RESOURCE_DIR. Sadly, support for configuring this variable
> > seems to have been removed about 4 months ago.
> >
> > I opened an issue upstream regarding this[1], but maybe there is
> > an easy workaround we can use until a fix is hopefully released.
> > I was thinking of either a phase which calls `wrap-program', or
> > adding the required flag back via a short snippet.
>
> Are you talking about the game assets, or is it something different?
>
> (Did you see the discussion at
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28794#8>?)
>
> Cheers,
> Ludo’.
>

bug#28840: openrct2 cannot find data-path

[Jelle Licht]

The recently committed (and awesome) openrct2 built correctly,
but cannot currently find the needed language and shader files
for the game and therefore crashes. To make it work, I currently
have to invoke it via a command like
`--openrct-data-path=/gnu/store/-openrct2-0.1.1/share/openrct2/',
which imho is not optimal.

I dove into the source of openrct, and it seems there are still
some vestiges of the cmake flag we want, namely
ORCT2_RESOURCE_DIR. Sadly, support for configuring this variable
seems to have been removed about 4 months ago.

I opened an issue upstream regarding this[1], but maybe there is
an easy workaround we can use until a fix is hopefully released.
I was thinking of either a phase which calls `wrap-program', or
adding the required flag back via a short snippet.

- Jelle


[1]: https://github.com/OpenRCT2/OpenRCT2/issues/6473


p.s. Besides these rather small issues, I can confirm that OpenRCT2
works.

bug#27257: python-apsw bundles a version of SQLite

[Jelle Licht]

2017-06-05 19:27 GMT+02:00 Danny Milosavljevic <dan...@scratchpost.org>:

> Hi Jelle,
>
> On Mon, 5 Jun 2017 18:32:10 +0200
> Jelle Licht <jli...@fsfe.org> wrote:
>
> > Some possible directions on resolving this issue:
> > - Debug the multiple thousand lines of test code to see exactly where/how
> > the test fails when using the system SQLite library
> > - Package the right version of the SQLite amalgation [1] that is now
> > bundled, although the amalgation should be functionally equivalent to the
> > normal SQLite version.
>
> I see that apsw bundles SQLite 3.9.2.  Does it work when you replace it
> with the external version 3.9.2 - amalgation or not ?
>
Getting version 3.9.2 to build turned out to be a bit of a hassle; some
nonsense about a fossil(?) generated manifest missing or what not.

>
> I don't necessarily mean permanently - just to find out whether the tests
> work normally then.
>
> Also, Perhaps diff the bundled SQLite 3.9.2 and the released SQLite 3.9.2
> amalgation of the same version ?
>
A diff between bundled SQLite 3.9.2 and release 3.9.2. amalgation reveals
no (functional) differences, so at least there will be no extra set of
patches to maintain.

> [...]
>

It seems that the actual upstream for apsw at [1] has continued development
since we packaged it.
Incidentally, our sqlite package is a bit outdated. If I update sqlite to
the latest version (3.20.1), as well as change the python-apsw upstream to
[1], the package seems to build and pass the `check' phase with no issues.

[1] : https://github.com/rogerbinns/apsw

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

The current ansible package is still brokenin the same way.

Is there already an acceptable way of working around this problem?
Otherwise I could send my (extremely hacky) workaround that adds a specific
condition in the ansible source code to check for .ansible-real.

Thanks,
Jelle

2017-05-03 12:04 GMT+02:00 Ludovic Courtès <l...@gnu.org>:

> Jelle Licht <jli...@fsfe.org> skribis:
>
> > I had some problems getting current ansible package to work. It seems
> that
> > the bin/ansible script which is created as part of the
> python-build-system
> > via a call to `wrap-program' interferes with certain expectations ansible
> > has regarding how it and its subcommands are called.
> >
> > This mechanism does not work well with our generated created
> .ansible-real.
> > See [1] for a similar issue that has since been worked around in the
> newest
> > version of ansible.
> >
> > For now, I have a similar workaround that add some guix-specific checks
> to
> > ansible looking for being called as .ansible-real, though I do consider
> > this a hack. This problem is indicative of a bigger issue: the fact that
> > wrap-program currently leads to subtle bugs for lots of scripts. There
> has
> > been some noise on #guix about solving this problem in general.
>
> For the record, the discussion is visible here:
> <https://gnunet.org/bot/log/guix/2017-05-02#T1370586>.
>
> I think it’s bad for a program to rely on argv[0], but I also think
> those .thing-real are kinda ugly.  :-)
>
> Ludo’.
>

bug#27257: python-apsw bundles a version of SQLite

[Jelle Licht]

The version of python-apsw (and of course python2-apsw) come with a bundled
copy of SQLite.
The bundled version seems to be a special single-source-file version [1].

I have tried deleting the bundled copy in a new phase, and this allows
python-apsw to build with the system SQLite libraries instead (someone
prematurely added sqlite as an input already, it was just never used).

This leads to a new problem, where that one of the VFS tests uses about 14
gigs of memory, and seems to hang as well. I am not sure if this is
indicative of any real issues when using python-apsw, and as such I am not
confident that just deleting the bundled copy of SQLite will help us, as it
might lead to an unusable package.

Some possible directions on resolving this issue:
- Debug the multiple thousand lines of test code to see exactly where/how
the test fails when using the system SQLite library
- Package the right version of the SQLite amalgation [1] that is now
bundled, although the amalgation should be functionally equivalent to the
normal SQLite version.

Thanks,
Jelle

[1]: https://www.sqlite.org/amalgamation.html

bug#27212: [PATCH] file-systems: Improve error handling in the iso9660 case - fixes boot problem.

[Jelle Licht]

Leo Famulari  writes:

> On Sat, Jun 03, 2017 at 08:25:00PM +0200, Danny Milosavljevic wrote:
>> Hi,
>>
>> sorry for the slip-up.
>>
>> The error handling in 203a9455c4695152fc5d0085bffeead9ce3216c2 was improved
>> for the case when there's no iso9660 primary volume descriptor anywhere and 
>> no
>> terminator either.  In that case the CD is broken.
>>
>> But if there's no iso9660 volume descriptor AT ALL (primary or not) it's not 
>> a
>> fatal error for guix gnu/build/file-systems.scm - it just means we picked the
>> wrong filesystem type and should try the next one.  This case was not handled
>> correctly and this patch addresses this.
>>
>> I'd like help with testing this patch.  If someone with a fast computer could
>> apply this patch, then run make check-system, and then, if everything worked,
>> run guix system reconfigure /etc/config.scm , that would be great (my 
>> computer
>> is building guix master for the last 3 days and probably needs 4 more - so no
>> idea whether the patch works).
>
> I don't have access to a fast GuixSD system today.
>
> How about reverting the original change now, so that we can reduce the number 
> of
> people who hit the bug. Then we can test the revised commit afterwards.

Good news! My system boots again after applying your patch and
reconfiguring. The make check-system fails a network related test, but
only because of an unrelated problem, as this already happened before
any of these problems started.

- Jelle

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

Hi,

I had some problems getting current ansible package to work. It seems that
the bin/ansible script which is created as part of the python-build-system
via a call to `wrap-program' interferes with certain expectations ansible
has regarding how it and its subcommands are called.

This mechanism does not work well with our generated created .ansible-real.
See [1] for a similar issue that has since been worked around in the newest
version of ansible.

For now, I have a similar workaround that add some guix-specific checks to
ansible looking for being called as .ansible-real, though I do consider
this a hack. This problem is indicative of a bigger issue: the fact that
wrap-program currently leads to subtle bugs for lots of scripts. There has
been some noise on #guix about solving this problem in general.

Thanks,
Jelle

[1]: https://github.com/ansible/ansible/issues/22261

bug#23723: patch-shebang phase breaks symlinks

[Jelle Licht]

Seems like a good policy in general.
I'll apply your patch and fix up node then.
Thanks a lot for the quick follow up.
- Jelle
On Jun 14, 2016 9:57 AM, "Ludovic Courtès" <l...@gnu.org> wrote:

> Jelle Licht <jli...@fsfe.org> skribis:
>
> > Ludovic Courtès <l...@gnu.org> writes:
> >
> >> Jelle Licht <jli...@fsfe.org> skribis:
> >>
> >>> Ludovic Courtès <l...@gnu.org> writes:
> >>>> Hello!
> >>>>
> >>>> Jelle Licht <jli...@fsfe.org> skribis:
> >>>>
> >>>>> It seems that the patch-shebang functionality does not deal
> gracefully
> >>>>> with symlinks: it just overwrites them!
> >>>>>
> >>>>> After struggling somewhat with getting the recently packaged node
> 6.0.0
> >>>>> to behave, I found out that `patch-shebang' in (guix build
> >>>>> gnu-build-system) does not work properly on symlinks.
> >>>>
> >>>> There’s ‘patch-shebangs’ (plural) in this file, but it explicitly
> >>>> touches only regular files (see ‘list-of-files’).
> >>>>
> >>>
> >>> It seems I made a mistake when writing the bug report; I am talking
> >>> about the `patch-shebang' defined in (guix build utils). My apologies.
> >>>
> >>> Also, seeing as my experience with the stat utility and similarly
> styled
> >>> programming libraries was lacking, I decided to play around with the
> >>> definition of `list-of-files': It actually does include symlinks, as
> >>> (stat:type (stat "some-symlinked-file")) gives us a plain old 'regular.
> >>> Looking into this a bit more, it seems that calling `stat' gives the
> >>> exact same results on both the linked-to-file and the symlink to that
> >>> file.
> >>>
> >>> For the particular problem I ran into to be fixed, it is imperative
> that
> >>> `list-of-files' of `patch-shebangs' includes the symlink; it does after
> >>> all need to be patched. The way this patching currently happens just
> >>> clobbers symlinks.
> >>
> >> My bad, indeed, ‘list-of-files’ should use ‘lstat’ instead of ‘stat’.
> >
> > This would be one way of fixing this bug. I'd rather see that
> > `patch-shebang' in (guix build utils) checks for symlinks, and if so,
> > patches the actual file instead of the symlink. This is the approach I
> > currently use in my tree to use node 6.0. Would there be any downside to
> > this approach?
>
> Both would work, but I think the “spirit” is that symlinks are supposed
> to be transparent, and tools/procedures that operate on files shouldn’t
> try to do anything smart about symlinks.  Thus I have a slight
> preference for pushing the smartness to the edges.  WDYT?
>
> Thanks,
> Ludo’.
>

bug#23723: patch-shebang phase breaks symlinks

[Jelle Licht]

Ludovic Courtès <l...@gnu.org> writes:

> Jelle Licht <jli...@fsfe.org> skribis:
>
>> Ludovic Courtès <l...@gnu.org> writes:
>>> Hello!
>>>
>>> Jelle Licht <jli...@fsfe.org> skribis:
>>>
>>>> It seems that the patch-shebang functionality does not deal gracefully
>>>> with symlinks: it just overwrites them!
>>>>
>>>> After struggling somewhat with getting the recently packaged node 6.0.0
>>>> to behave, I found out that `patch-shebang' in (guix build
>>>> gnu-build-system) does not work properly on symlinks.
>>>
>>> There’s ‘patch-shebangs’ (plural) in this file, but it explicitly
>>> touches only regular files (see ‘list-of-files’).
>>>
>>
>> It seems I made a mistake when writing the bug report; I am talking
>> about the `patch-shebang' defined in (guix build utils). My apologies.
>>
>> Also, seeing as my experience with the stat utility and similarly styled
>> programming libraries was lacking, I decided to play around with the
>> definition of `list-of-files': It actually does include symlinks, as
>> (stat:type (stat "some-symlinked-file")) gives us a plain old 'regular.
>> Looking into this a bit more, it seems that calling `stat' gives the
>> exact same results on both the linked-to-file and the symlink to that
>> file.
>>
>> For the particular problem I ran into to be fixed, it is imperative that
>> `list-of-files' of `patch-shebangs' includes the symlink; it does after
>> all need to be patched. The way this patching currently happens just
>> clobbers symlinks.
>
> My bad, indeed, ‘list-of-files’ should use ‘lstat’ instead of ‘stat’.

This would be one way of fixing this bug. I'd rather see that
`patch-shebang' in (guix build utils) checks for symlinks, and if so,
patches the actual file instead of the symlink. This is the approach I
currently use in my tree to use node 6.0. Would there be any downside to
this approach?

>
> I think a patch like attached should solve the problem.  WDYT?
>
> We can apply it to core-updates-next if that’s fine with you.
>
> Thanks,
> Ludo’.

If this is the approach you'd rather follow, that is okay with me as
well. I just think that a phase that transparently patches all files in
bin/sbin, whether they are actual files or symlinks, would be more
useful.

Greetings,
- Jelle

bug#23723: patch-shebang phase breaks symlinks

[Jelle Licht]

Hi Guix,

It seems that the patch-shebang functionality does not deal gracefully
with symlinks: it just overwrites them!

After struggling somewhat with getting the recently packaged node 6.0.0
to behave, I found out that `patch-shebang' in (guix build
gnu-build-system) does not work properly on symlinks.

To illustrate, in this specific case, there was an executable
script included with the node tarball, namely
`lib/node-modules/npm/bin/npm-cli.js' with an env-based shebang:
`/usr/bin/env node'.

As the `node' executable will only be available after the `install'
phase of the build system, it is not patched before hand. During the
`install' phase, a symlink is created from `bin/npm' to
`lib/node-modules/npm/bin/npm-cli.js' (in the store output directory
this time, of course). Then the `patch-shebangs' phase finds this
symlink and proceeds to patch it. Instead of transparently following the
symlink and patching the `npm-cli.js' script, the `npm' symlink is
overwritten with a shebang-patched copy of `npm-cli.js'.

For node, this is a problem because of how node loads run-time
dependencies; load paths are resolved relative to the actual file, not
the symlink.

- Jelle