Ghc and profile creation bug

Ghc and profile creation bug

[Andreas Enge]

Hello,

even after "make distclean; ./configure; make install", I obtain the following
with c833ab5 (and before):

$ guix package -n -u
Backtrace:                                           
In ice-9/boot-9.scm:
 157: 18 [catch #t #<catch-closure 1b09bc0> ...]
In unknown file:
   ?: 17 [apply-smob/1 #<catch-closure 1b09bc0>]
In ice-9/boot-9.scm:
  63: 16 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 15 [eval # #]
In ice-9/boot-9.scm:
2401: 14 [save-module-excursion #<procedure 1b26940 at ice-9/boot-9.scm:4045:3 ()>]
4050: 13 [#<procedure 1b26940 at ice-9/boot-9.scm:4045:3 ()>]
1724: 12 [%start-stack load-stack ...]
1729: 11 [#<procedure 1b3dea0 ()>]
In unknown file:
   ?: 10 [primitive-load "/usr/local/bin/guix"]
In guix/ui.scm:
 849: 9 [run-guix-command package "-n" "-u"]
In ice-9/boot-9.scm:
 157: 8 [catch srfi-34 #<procedure 3144980 at guix/ui.scm:221:2 ()> ...]
 157: 7 [catch system-error ...]
In guix/scripts/package.scm:
1002: 6 [#<procedure 3149870 at guix/scripts/package.scm:991:4 ()>]
 837: 5 [process-actions (# # # # ...)]
In guix/store.scm:
 977: 4 [run-with-store # ...]
In guix/profiles.scm:
 523: 3 [#<procedure 3d1ecf0 at guix/profiles.scm:523:2 (state)> #]
 527: 2 [#<procedure 3cf5270 at guix/profiles.scm:523:2 (t-57033)> #]
 411: 1 [ghc-package-cache-file #<<manifest> entries: (# # # # ...)>]
In unknown file:
   ?: 0 [scm-error misc-error #f ...]

ERROR: In procedure scm-error:
ERROR: No variable named ghc in #<interface (gnu packages haskell) 32fc480>

Andreas

Re: Ghc and profile creation bug

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> even after "make distclean; ./configure; make install", I obtain the following
> with c833ab5 (and before):
>
> $ guix package -n -u

[...]

> In guix/scripts/package.scm:
> 1002: 6 [#<procedure 3149870 at guix/scripts/package.scm:991:4 ()>]
>  837: 5 [process-actions (# # # # ...)]
> In guix/store.scm:
>  977: 4 [run-with-store # ...]
> In guix/profiles.scm:
>  523: 3 [#<procedure 3d1ecf0 at guix/profiles.scm:523:2 (state)> #]
>  527: 2 [#<procedure 3cf5270 at guix/profiles.scm:523:2 (t-57033)> #]
>  411: 1 [ghc-package-cache-file #<<manifest> entries: (# # # # ...)>]
> In unknown file:
>    ?: 0 [scm-error misc-error #f ...]
>
> ERROR: In procedure scm-error:
> ERROR: No variable named ghc in #<interface (gnu packages haskell) 32fc480>

I can’t reproduce it but Ricardo has the same problem, also after having
used “make install.”

I suspect an issue with .go/.scm timestamps, like the installed .go
having a newer mtime than the .scm even though it’s actually out of
sync.  Could you try to investigate in that direction?

TIA,
Ludo’.

Re: Ghc and profile creation bug

[Ludovic Courtès]

While debugging it with Taylan on IRC, it occurred to us that
guix/build-system/haskell.scm wasn’t getting installed, which is fixed
by ce6fc7d.  Can you confirm that this solves the problem?

Anyway, I recommend against using repeated “make install”, one reason
being that there can be leftovers if you don’t run “make uninstall”
beforehand.

“guix pull” is meant to be a handy way to deal with updates.  I agree
there are shortcomings (notably on my to-do list is the idea to switch
it from doing a full download to using git), but we should discuss them
and find a list of actions to take to address them.

Ludo’.

Re: Ghc and profile creation bug

[Andreas Enge]

On Sun, Apr 12, 2015 at 03:38:58PM +0200, Ludovic Courtès wrote:
> While debugging it with Taylan on IRC, it occurred to us that
> guix/build-system/haskell.scm wasn’t getting installed, which is fixed
> by ce6fc7d.  Can you confirm that this solves the problem?

It does, thanks a lot!

> Anyway, I recommend against using repeated “make install”, one reason
> being that there can be leftovers if you don’t run “make uninstall”
> beforehand.

It seems to be the good way of working in my "multi-user" setting. Why
should every user handle his own copy of guix? For instance, the daemon
needs to be installed in a system location to be started by the init system.
Anyway, "make install" needs to work.

> “guix pull” is meant to be a handy way to deal with updates.

Does this not interfere badly with git? I am running "make install" from my
latest stable master git branch, so that every user on the system has a recent
stable guix, with "stable" in the sense of a rolling release, not the latest
official relase. Then I use "./pre-inst-env" from my private branch in which
I am developing new packages.

Andreas

guix pull

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Apr 12, 2015 at 03:38:58PM +0200, Ludovic Courtès wrote:
>> Anyway, I recommend against using repeated “make install”, one reason
>> being that there can be leftovers if you don’t run “make uninstall”
>> beforehand.
>
> It seems to be the good way of working in my "multi-user" setting. Why
> should every user handle his own copy of guix? For instance, the daemon
> needs to be installed in a system location to be started by the init system.
> Anyway, "make install" needs to work.

Of course it has to work, no argument here.  :-)

However, it is stateful, which makes it easier to get into troubles (for
instance because a stale .scm file remains available, so ‘guix package
-A’ would show its contents, or because of obscure timestamp issues on
existing files, particularly if one tries
“make install INSTALL='install -C'”, etc.)

>> “guix pull” is meant to be a handy way to deal with updates.
>
> Does this not interfere badly with git? I am running "make install" from my
> latest stable master git branch, so that every user on the system has a recent
> stable guix, with "stable" in the sense of a rolling release, not the latest
> official relase.

Right, the model with “guix pull” is that each user is responsible for
updating their local Guix.  From the sysadmin’s viewpoint, this is bad,
because each user could have their own thing, and some could still be
installing old packages with security issues.  From the user’s
viewpoint, it’s total freedom.

Perhaps “guix pull” could honor sysadmin-handled updates, for those
cases where users do not want to run “guix pull” by themselves.  Say,
‘guix’ would look for ~/.config/guix/latest first, and then
/var/guix/latest.  Thoughts?

> Then I use "./pre-inst-env" from my private branch in which I am
> developing new packages.

Sure.

Thanks,
Ludo’.