xmonad fails to recompile on guix system

  • Done
  • quality assurance status badge
Details
5 participants
  • Lars-Dominik Braun
  • Xinglu Chen
  • raingloom
  • Charlie Ruppe
  • zimoun
Owner
unassigned
Submitted by
Charlie Ruppe
Severity
normal
C
C
Charlie Ruppe wrote on 23 Mar 2021 01:13
(address . bug-guix@gnu.org)
CAOgs06eE3y8LbBvjWs89+uLt5WGKCLWo+PVE8i-MT58hMOxzGw@mail.gmail.com
Package: guix
Version: 1.2.0-17.ec7fb6

I am trying to recompile xmonad with a fairly simple xmonad.hs
The package itself builds, installs, and runs correctly, but it throws
errors when recompiling my configuration. Configuration is very short but

The same error is thrown when attempting to compile xmonad with ghc
directly, and inside and out of xmonad's build environment.

The following is the error that is printed when attempting to recompile
xmonad from within the build environment for xmonad within the directory
~/.xmonad/ containing xmonad.hs

[env]$ xmonad --recompile
XMonad will use ghc to recompile, because "/home/fever/.xmonad/build" does
not exist.
Error detected while loading xmonad configuration file:
/home/fever/.xmonad/xmonad.hs

xmonad.hs:1:1: error:
Could not find module ‘XMonad’
Perhaps you meant DsMonad (needs flag -package-key ghc-8.6.5)
Use -v to see a list of the files searched for.
|
1 | import XMonad
| ^^^^^^^^^^^^^

xmonad.hs:2:1: error:
Could not find module ‘XMonad.Config.Desktop’
Use -v to see a list of the files searched for.
|
2 | import XMonad.Config.Desktop
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Please check the file for errors.

xmonad: xmessage: executeFile: does not exist (No such file or directory)
Attachment: file
L
L
Lars-Dominik Braun wrote on 26 Jul 2021 08:47
(name . Charlie Ruppe)(address . ruppe.charlie@gmail.com)(address . 47335@debbugs.gnu.org)
YP5amSFnOO/CvkSq@noor.fritz.box
Hi,

I’m seeing the same issue, but it works when explicitly installing
ghc@8.6. Looking at haskell-build-system all Haskell libraries are
currently built with version 8.6, whereas the newest GHC version
available (and thus installed by `guix install`) is 8.8.

I feel that either xmonad should depend on the correct GHC or all
GHC versions not used to build libraries should be hidden to avoid this
situation.

Lars
R
R
raingloom wrote on 1 Aug 2021 19:51
Re: bug#47335: Hide GHC not used for building Was: xmonad fails to recompile on guix system
(name . Lars-Dominik Braun)(address . lars@6xq.net)
20210801195135.49063b16@riseup.net
On Mon, 26 Jul 2021 08:47:53 +0200
Lars-Dominik Braun <lars@6xq.net> wrote:

Toggle quote (17 lines)
> Hi,
>
> I’m seeing the same issue, but it works when explicitly installing
> ghc@8.6. Looking at haskell-build-system all Haskell libraries are
> currently built with version 8.6, whereas the newest GHC version
> available (and thus installed by `guix install`) is 8.8.
>
> I feel that either xmonad should depend on the correct GHC or all
> GHC versions not used to build libraries should be hidden to avoid
> this situation.
>
> Lars
>
>
>
>

I'd be very much in favor of the latter, or maybe rename it to ghc-next.
I have some profiles ghc pinned to a version and upgrading those is
always a mess because Guix tries to build the old version from source
instead of using the next version.
L
L
Lars-Dominik Braun wrote on 15 Sep 2021 09:42
(name . raingloom)(address . raingloom@riseup.net)
YUGj74a7XA+WxzQg@noor.fritz.box
Hi,

Toggle quote (4 lines)
> I'd be very much in favor of the latter, or maybe rename it to ghc-next.
> I have some profiles ghc pinned to a version and upgrading those is
> always a mess because Guix tries to build the old version from source
> instead of using the next version.
I renamed ghc@8.8 to ghc-next in commit
39b43d0d0428474a1d0bf58779d0135163b9c6e3.

Cheers,
Lars
Closed
Z
Z
zimoun wrote on 15 Sep 2021 10:58
CAJ3okZ2A5g41YcBF4SJ1=edcsk6GucqshVz2JSdhfkUcWy3U-Q@mail.gmail.com
Hi,

On Wed, 15 Sept 2021 at 09:43, Lars-Dominik Braun <lars@6xq.net> wrote:

Toggle quote (8 lines)
> > I'd be very much in favor of the latter, or maybe rename it to ghc-next.
> > I have some profiles ghc pinned to a version and upgrading those is
> > always a mess because Guix tries to build the old version from source
> > instead of using the next version.
>
> I renamed ghc@8.8 to ghc-next in commit
> 39b43d0d0428474a1d0bf58779d0135163b9c6e3.

Well, I am late to the party and probably out of point but I think
this '-next' is not something we should introduce and generalize.
Well, who knows if these '-next' will be the real next. ;-) My
comment is also about guile-next, emacs-next and python-next. Noting
that gcc-toolchain does not have a '-next'; packages are built using
7.5.0 but "guix install gcc-toolchain" will install 11.2.0 and then it
could lead to the same issue as the one reported with GHC, I guess.

Instead of this '-next' trick, we should find a better mechanism where
"guix install ghc" would install the default GHC used by the Haskell
build-system. Idem for the others guile-next, python-next etc.. And
any other version should be installed using the explicit mention,
i.e., "guix install ghc@8.8", IMHO.

Cheers,
simon
X
X
Xinglu Chen wrote on 15 Sep 2021 13:02
(address . 47335-done@debbugs.gnu.org)
87v932rtig.fsf@yoctocell.xyz
On Wed, Sep 15 2021, zimoun wrote:

Toggle quote (26 lines)
> Hi,
>
> On Wed, 15 Sept 2021 at 09:43, Lars-Dominik Braun <lars@6xq.net> wrote:
>
>> > I'd be very much in favor of the latter, or maybe rename it to ghc-next.
>> > I have some profiles ghc pinned to a version and upgrading those is
>> > always a mess because Guix tries to build the old version from source
>> > instead of using the next version.
>>
>> I renamed ghc@8.8 to ghc-next in commit
>> 39b43d0d0428474a1d0bf58779d0135163b9c6e3.
>
> Well, I am late to the party and probably out of point but I think
> this '-next' is not something we should introduce and generalize.
> Well, who knows if these '-next' will be the real next. ;-) My
> comment is also about guile-next, emacs-next and python-next. Noting
> that gcc-toolchain does not have a '-next'; packages are built using
> 7.5.0 but "guix install gcc-toolchain" will install 11.2.0 and then it
> could lead to the same issue as the one reported with GHC, I guess.
>
> Instead of this '-next' trick, we should find a better mechanism where
> "guix install ghc" would install the default GHC used by the Haskell
> build-system. Idem for the others guile-next, python-next etc.. And
> any other version should be installed using the explicit mention,
> i.e., "guix install ghc@8.8", IMHO.

Agreed, but I guess using the ‘-next’ suffix was be the easiest
workaround for now.

Maybe running ‘guix install ghc’ should install the GHC package that the
‘ghc’ variable refers to. Then this would not only apply to language
ecosystems, but all packages in general. Right now running ‘guix
install rsync’ installs the ‘rsync-next’ package, but I would expect it
to install the package that the ‘rsync’ variable is bound to.
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmFB0tcVHHB1YmxpY0B5
b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5DvgP/jHDAgzWeOjfRQ8hYqc+ULnmRRv5
a5Ycmo3ACmJrLbH5ZiM5WV6dKPO5CnB0f6KIxz2VESPvM7MNmMZSJn2AIR1MdTch
O49LUmzcOxlbzQY4TP6onuAVcLgT6gqXWCquho3QAzEm1t1WQ0JMZzKj6ZRpqCnw
TkIrnMUOdoa00M7a2TR/JxF2FCRyKdwrskpyWAdmfLFjs2jNWhZDphHcc19+pWSy
PyTQY+5gvFhizNxke8QIMULMMbOOZ99MpzF7G9pL6QhgQjeAlgvL36v0SfLT6946
vF5/7K8a6JeBqp6BG5boXb+mjxIboAqrfUfY7YbTQeIAZMFIvxcBhnpiHIO55+/9
uyssZ0WVS62ePdN1guSUuobBiYp9nmIapwdSI8To0fR8RS7eTnsROxW4plZi1dBX
F0wP0WYkp1P3WGsQXoNYrfz8kAwWdGipsyUmNPYbEpmrztBMYDvlJAw3zOiseBDB
Evn9e6XBX9VGmLN7W0aUzM4qucOeqhGXmVjrFfd+qXX2v4GYxWyhTZe6tEniW4/G
czNC37MG3eyJG00YGHKQVcynbfAjsTIEg2hzHh9NKypa1cxzbN+/ozPzalMHSs9Z
NutFy9n7MghKWBLwoO20ojG/i72voBVk3jxXDjZUpxvT7Ee6lBLVErfnADcJ2Tvo
+Etjqf7vnFI+o/BH
=v3eC
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 15 Sep 2021 10:08
(name . Xinglu Chen)(address . public@yoctocell.xyz)
CAJ3okZ36Zbh9bNkkyJbjj6cFEPwadRzbQ0X9nZYxuJ5JGpn4Dw@mail.gmail.com
Hi,

On Wed, 15 Sept 2021 at 13:02, Xinglu Chen <public@yoctocell.xyz> wrote:

Toggle quote (3 lines)
> Agreed, but I guess using the ‘-next’ suffix was be the easiest
> workaround for now.

Yeah but more than often, the workarounds remain longer than expected
and thus they cannot be considered as workaround. ;-)

Toggle quote (6 lines)
> Maybe running ‘guix install ghc’ should install the GHC package that the
> ‘ghc’ variable refers to. Then this would not only apply to language
> ecosystems, but all packages in general. Right now running ‘guix
> install rsync’ installs the ‘rsync-next’ package, but I would expect it
> to install the package that the ‘rsync’ variable is bound to.

Well, the name has to be distinguished from the symbol. The symbol
name does not matter from a CLI point of view; and usually not so much
from a regular user perspective.

What really matters, IMHO, is the name and the version. Basically,
"guix install foo" will install the latest version of the package
'foo'. To avoid this, the trick is to tweak to the name of the latest
version. It is what happens with 'rsync'; so to be in agreement with
the '-next' approach, the name should be 'rsync-next' and not 'rsync'.

Anyway, we all agree that something is odd. :-)

Cheers,
simon
?
Your comment

This issue is archived.

To comment on this conversation send an email to 47335@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 47335
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch