bug#64734: Recursive hackage import fails

[Saku Laesvuori via Bug reports for GNU Guix]

close 64734
thanks


signature.asc
Description: PGP signature

bug#64734: Recursive hackage import fails

[Saku Laesvuori via Bug reports for GNU Guix]

> Hi,
> 
> > $ guix import hackage linear-generics --recursive
> 
> have you ever figured out what caused this?

Yes, I fixed it in https://issues.guix.gnu.org/67564 so this issue can
now be closed.

- Saku


signature.asc
Description: PGP signature

bug#68811: build hash inconsistency

[Saku Laesvuori via Bug reports for GNU Guix]

> Some more context might be useful:
> 
> Device A (which successfully built qutebrowser over a couple days)
> ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
> build qutebrowser --dry-run
> /gnu/store/i9ir7a26gv1ii98b4bzgvxp1sx0akind-qutebrowser-2.5.4
> 
> Device B (trying to avoid building qutebrowser)
> ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
> build qutebrowser --dry-run
> The following derivations would be built:
>   /gnu/store/6n9aq7l5x26xfgrbvws7gvscbzvq5gqn-qutebrowser-2.5.4.drv
>   /gnu/store/05wj7wf7bdlkm1ar58kpakvp52drrz7p-qtwebengine-5.15.10.drv
>   /gnu/store/7nmv55qqw62jwzrd650vm434s3wpi7i3-python-pyqtwebengine-5.15.9.drv

Those hashes are not comparable: i9ir..nd (A) is the hash of the built
store item and 6n9aq..qn (B) is the hash of the derivation that builds
the store item.

> I have noticed in the past that sometimes a package gets built twice
> with two hashes, so I went back and checked if device A had built the
> 6n9..5gqn qutebrowser store item reported by B in addition to the
> i9i..ind one A was reporting.  There was no 6n9..5gqn qutebrowser build
> on device A.  I don't believe I have never run guix gc on either device.

But I do think it is weird if the derivation is not present on the
machine that build qutebrowser. Would you mind sending the output of
`guix time-machine ... -- build --derivations ...` from both machines?
If they return a different hash you could maybe also check the returned
`/gnu/store/...-qutebrowser-2.5.4.drv` files to see what is the
difference between them.

- Saku


signature.asc
Description: PGP signature

bug#66746: LUKS password prompt invisible, prompts twice

[Saku Laesvuori via Bug reports for GNU Guix]

> Hi Caleb,
> 
> Caleb Herbert  writes:
> 
> > Hardware: ThinkPad X200
> > Firmware: Libreboot 2016
> > OS: Guix System
> >
> > Expected behavior:
> > Password prompt. Enter LUKS passphrase. Log into computer.
> >
> > Actual behavior:
> > Password prompt. Enter LUKS passphrase. Select boot option from GRUB menu. 
> > Hangs, no password prompt. Enter passphrase (again) anyway: Boots normally.
> 
> I think this is a combination of two things: first, we currently need to
> unlock the drive once for GRUB, and then once when Linux boots, hence
> the two password prompts.  This is a known limitation, but the usual
> workaround of adding a keyfile to the initrd wouldn't work in our case
> for security reasons: the keyfile would end up in the store and be
> world-readable, a disaster.

I believe a patch[1] enabling this is waiting for a review.

[1]: https://issues.guix.gnu.org/65002


signature.asc
Description: PGP signature

bug#66168: zsh home service breaks guix shell via ssh

[Saku Laesvuori via Bug reports for GNU Guix]

> > ```
> > $ ssh localhost
> > $ guix shell gnuplot
> > $ gnuplot
> > zsh: command not found: gnuplot
> > ```
> >
> > However (still within the ssh session)
> >
> > ```
> > $ guix shell gnuplot -- gnuplot
> > [gnuplot opens as expected]
> > ```
> >
> > and weirdly enough
> >
> > ```
> > $ guix shell --check gnuplot
> > guix shell: checking the environment variables visible from shell 
> > '/gnu/store/i4rj0banq044423if5xwb3df723g14r9-zsh-5.9/bin/zsh'...
> > guix shell: All is good!  The shell gets correct environment variables.
> > $ gnuplot
> > zsh: command not found: gnuplot
> > ```
> >
> > I don't really know what is happening here. Why does it work when
> > running the command directly and why does `guix shell --check` claim
> > that everything is correct when clearly something is wrong? If I
> > understand correctly `.zshenv` should be sourced in all these cases but
> > for some reason the problems only occur in some of them.
> >
> > Any ideas?
>
> My guess would be that sourcing /etc/profile should only happen once,
> but the SSH_CLIENT variable is inherited to the child shell which
> evaluates zshenv which in turn sources /etc/profile because SSH_CLIENT
> has non-zero length.  So /etc/profile is sourced twice.
> 
> This is just a wild guess though.

Seems to be about right. I had just assumed that guix shell would run
the command in a new shell (causing .zshenv to be sourced in all those
cases) but apparently it just calls the command directly. I haven't seen
any problems with sourcing /etc/profile multiple times because it
reloads both system and user profiles, but obviously it doesn't know
about guix shell profiles.

It seems that the default bash configuration only sources /etc/profile
if $SSH_CLIENT is non-empty and bash is used non-interactively.
Something similar could probably be done with zsh, but I would expect it
to still have this issue in certain situation. For example, I think
running a script like this

```
$ ssh host -- guix shell gnuplot <

signature.asc
Description: PGP signature

bug#66168: zsh home service breaks guix shell via ssh

[Saku Laesvuori via Bug reports for GNU Guix]

On Sat, Sep 23, 2023 at 12:19:10PM +0200, Malte Frank Gerdes wrote:
> I noticed that after connecting via ssh the profile that gets created
> when doing `guix shell' is not sourced, therefore the environment
> variables are not correct.  This seems to be because guix home inserts
> "[ -n \"$SSH_CLIENT\" ] && source /etc/profile" into the zshenv file.  I
> assume this is meant to ensure that /etc/profile is sourced because ssh
> does not start a login shell?

That is correct, it was added in 
because commands like `ssh host -- cmd` (and commands depending on ssh
such as `git pull/push`) failed. 


> Anyway, removing that line makes everything work normally.  So am i
> doing it wrong or is this actually unnecessary?

I can reproduce this:

```
$ ssh localhost
$ guix shell gnuplot
$ gnuplot
zsh: command not found: gnuplot
```

However (still within the ssh session)

```
$ guix shell gnuplot -- gnuplot
[gnuplot opens as expected]
```

and weirdly enough

```
$ guix shell --check gnuplot
guix shell: checking the environment variables visible from shell 
'/gnu/store/i4rj0banq044423if5xwb3df723g14r9-zsh-5.9/bin/zsh'...
guix shell: All is good!  The shell gets correct environment variables.
$ gnuplot
zsh: command not found: gnuplot
```

I don't really know what is happening here. Why does it work when
running the command directly and why does `guix shell --check` claim
that everything is correct when clearly something is wrong? If I
understand correctly `.zshenv` should be sourced in all these cases but
for some reason the problems only occur in some of them.

Any ideas?


signature.asc
Description: PGP signature

bug#65460: ghc/ghci are broken

[Saku Laesvuori via Bug reports for GNU Guix]

> > Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this 
> > be automatically brought in by `guix install ghc`? This does still feels 
> > like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs?

native-inputs are for buildtime inputs and here ghc needs a c toolchain
at runtime to compile another haskell program so gcc-toolchain should be
in "normal" inputs.

> I assume GHC can work with other toolchains, like Clang, so it's better
> to be explicit about what you want to use.

I think it would still be good to have a c toolchain as an input. Guix
packages are, if I understand correctly, supposed to work without having
to explicitly install their dependencies. If someone wants to use a
different c toolchain than the default, they can use a package
transformation to change it.

Maybe we could even have the current ghc as a hidden package and have
the public package wrap the hidden ghc adding gcc-toolchain to it's
environment, so that changing the c toolchain wouldn't require
rebuilding ghc.


signature.asc
Description: PGP signature

bug#48018: [PATCH core-updates 2/4] gnu: imagemagick: Fix converting webp images

[Saku Laesvuori via Bug reports for GNU Guix]

Fixes .

* gnu/packages/imagemagick.scm (imagemagick)[inputs]: Add libwebp.
---
The comments in the code imply that this could be applied to master, but
`guix refresh` claimed it to have over 3 000 dependents. Go figure.

 gnu/packages/imagemagick.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/imagemagick.scm b/gnu/packages/imagemagick.scm
index 169dc12f35..55e100a71c 100644
--- a/gnu/packages/imagemagick.scm
+++ b/gnu/packages/imagemagick.scm
@@ -158,6 +158,8 @@ (define-public imagemagick
(base32
 "0didbs10i9zb4dgripa851j7fivxb9jar7l3vvxz6i4kn6xvdv7r"))
   (patches (search-patches "imagemagick-Fix-tests.patch"
+(inputs (cons `("libwebp" ,libwebp)
+  (package-inputs imagemagick/stable)))
 (arguments
  (append (package-arguments imagemagick/stable)
  '(#:tests? #t)
-- 
2.41.0

bug#64775: /run should be cleaned on boot

[Saku Laesvuori via Bug reports for GNU Guix]

> > I vote for TMPFS, since that would also reduce flash wear.
> > Honestly I don't get why it's not already using TMPFS.
>
> One argument could be how much ram it takes:
> 
>   $ du -sc /run/*
>   12  /run/blkid
>   0   /run/booted-system
>   0   /run/current-system
>   1312/run/setuid-programs
>   524 /run/udev
>   1848total
> 
> That is with no explicit setuid programs configured, on a machine with a
> fairly minimal configuration.
> 
> Not a *huge* amount of ram, but not nothing, either...

I'd say it's effectively nothing for almost all devices capable of
running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
test one terminal window with only zsh running in it took almost 10
times as much ram.


signature.asc
Description: PGP signature

bug#64734: Recursive hackage import fails

[Saku Laesvuori via Bug reports for GNU Guix]

Importing hackage packages recursively fails with similar error to this:

```
$ guix import hackage linear-generics --recursive
Backtrace:
  11 (primitive-load "/home/saku/.config/guix/current/bin/gu…")
In guix/ui.scm:
   2309:7 10 (run-guix . _)
  2272:10  9 (run-guix-command _ . _)
In guix/scripts/import.scm:
90:11  8 (guix-import . _)
In guix/scripts/import/hackage.scm:
   129:26  7 (guix-import-hackage . _)
In guix/import/utils.scm:
651:3  6 (recursive-import _ #:repo->guix-package _ #:guix-name . #)
   613:31  5 (topological-sort _ # …)
   655:29  4 (_ _)
In unknown file:
   3 (remove # …)
In guix/import/utils.scm:
   635:39  2 (exists? #< name: "th-abstraction" dow…> …)
In guix/import/hackage.scm:
128:6  1 (hackage-name->package-name #< name: "t…>)
In unknown file:
   0 (string-prefix? "ghc-" #< name: "th-ab…> …)

ERROR: In procedure string-prefix?:
In procedure string-prefix?: Wrong type argument in position 2 (expecting 
string): #< name: "th-abstraction" downstream-name: 
"ghc-th-abstraction" type: regular min-version: any max-version: any>

```

I tried to find out what passes the `upstream-input` to
`hackage-name->package-name`, but only found out with `pk` that it seems
to only happen with the recursed dependencies and not with the root
package. I also tried to make `hackage-name->package-name` accept
`upstream-input` records but that a new error, so I assume the issue is
that something in the importer is returning `upstream-input` records
when it should return package names.

I could try to debug this further but I don't feel like I know enough
about debugging with guile nor about debugging scheme.


signature.asc
Description: PGP signature

bug#59508: mpv compiled without x11 support

[Saku Laesvuori via Bug reports for GNU Guix]

> I believe this was fixed by commit
> 78f03567f44f704dfbc03cb64368aa42a01e78ad, though not by adding
> ‘--enable-x11’ (see ).
> 
> Anyway it definitely works for me on X11.  Could you confirm?

Yes, that seems to have fixed it.

- Saku


signature.asc
Description: PGP signature

bug#59508: mpv compiled without x11 support

[Saku Laesvuori via Bug reports for GNU Guix]

The mpv package from (gnu packages video) is compiled without x11
support and fails with:

[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be 
unavailable.
[vo/gpu] Failed to commit ModeSetting atomic request (-13)
[vo/gpu/opengl] Failed to set CRTC for connector 95: Permission denied

when trying to play a video. This can be fixed by adding "--enable-x11"
to configure-flags (tested with guix shell).

I'm not sure  is that enough to make guix consider the package updated
(though I would assume so), so I didn't prepare a patch. Anyway the fix
is a trivial one line addition.

- Saku


signature.asc
Description: PGP signature