xmonad fails to recompile on guix system

DoneSubmitted by Charlie Ruppe.
Details
5 participants
  • Lars-Dominik Braun
  • Xinglu Chen
  • raingloom
  • Charlie Ruppe
  • zimoun
Owner
unassigned
Severity
normal
C
C
Charlie Ruppe wrote on 23 Mar 01:13 +0100
(address . bug-guix@gnu.org)
CAOgs06eE3y8LbBvjWs89+uLt5WGKCLWo+PVE8i-MT58hMOxzGw@mail.gmail.com
Package: guixVersion: 1.2.0-17.ec7fb6
I am trying to recompile xmonad with a fairly simple xmonad.hsThe package itself builds, installs, and runs correctly, but it throwserrors when recompiling my configuration. Configuration is very short butis pasted here: http://paste.debian.net/1190543/
The same error is thrown when attempting to compile xmonad with ghcdirectly, and inside and out of xmonad's build environment.
The following is the error that is printed when attempting to recompilexmonad from within the build environment for xmonad within the directory~/.xmonad/ containing xmonad.hs
[env]$ xmonad --recompileXMonad will use ghc to recompile, because "/home/fever/.xmonad/build" doesnot 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 08:47 +0200
(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 installingghc@8.6. Looking at haskell-build-system all Haskell libraries arecurrently built with version 8.6, whereas the newest GHC versionavailable (and thus installed by `guix install`) is 8.8.
I feel that either xmonad should depend on the correct GHC or allGHC versions not used to build libraries should be hidden to avoid thissituation.
Lars
R
R
raingloom wrote on 1 Aug 19:51 +0200
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 +0200Lars-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 isalways a mess because Guix tries to build the old version from sourceinstead of using the next version.
L
L
Lars-Dominik Braun wrote on 15 Sep 09:42 +0200
(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 commit39b43d0d0428474a1d0bf58779d0135163b9c6e3.
Cheers,Lars
Closed
Z
Z
zimoun wrote on 15 Sep 10:58 +0200
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 thinkthis '-next' is not something we should introduce and generalize.Well, who knows if these '-next' will be the real next. ;-) Mycomment is also about guile-next, emacs-next and python-next. Notingthat gcc-toolchain does not have a '-next'; packages are built using7.5.0 but "guix install gcc-toolchain" will install 11.2.0 and then itcould 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 Haskellbuild-system. Idem for the others guile-next, python-next etc.. Andany 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 13:02 +0200
(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 easiestworkaround 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 languageecosystems, but all packages in general. Right now running ‘guixinstall rsync’ installs the ‘rsync-next’ package, but I would expect itto install the package that the ‘rsync’ variable is bound to.
-----BEGIN PGP SIGNATURE-----
iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmFB0tcVHHB1YmxpY0B5b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5DvgP/jHDAgzWeOjfRQ8hYqc+ULnmRRv5a5Ycmo3ACmJrLbH5ZiM5WV6dKPO5CnB0f6KIxz2VESPvM7MNmMZSJn2AIR1MdTchO49LUmzcOxlbzQY4TP6onuAVcLgT6gqXWCquho3QAzEm1t1WQ0JMZzKj6ZRpqCnwTkIrnMUOdoa00M7a2TR/JxF2FCRyKdwrskpyWAdmfLFjs2jNWhZDphHcc19+pWSyPyTQY+5gvFhizNxke8QIMULMMbOOZ99MpzF7G9pL6QhgQjeAlgvL36v0SfLT6946vF5/7K8a6JeBqp6BG5boXb+mjxIboAqrfUfY7YbTQeIAZMFIvxcBhnpiHIO55+/9uyssZ0WVS62ePdN1guSUuobBiYp9nmIapwdSI8To0fR8RS7eTnsROxW4plZi1dBXF0wP0WYkp1P3WGsQXoNYrfz8kAwWdGipsyUmNPYbEpmrztBMYDvlJAw3zOiseBDBEvn9e6XBX9VGmLN7W0aUzM4qucOeqhGXmVjrFfd+qXX2v4GYxWyhTZe6tEniW4/GczNC37MG3eyJG00YGHKQVcynbfAjsTIEg2hzHh9NKypa1cxzbN+/ozPzalMHSs9ZNutFy9n7MghKWBLwoO20ojG/i72voBVk3jxXDjZUpxvT7Ee6lBLVErfnADcJ2Tvo+Etjqf7vnFI+o/BH=v3eC-----END PGP SIGNATURE-----
Z
Z
zimoun wrote on 15 Sep 10:08 +0200
(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 expectedand 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 symbolname does not matter from a CLI point of view; and usually not so muchfrom 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 latestversion. It is what happens with 'rsync'; so to be in agreement withthe '-next' approach, the name should be 'rsync-next' and not 'rsync'.
Anyway, we all agree that something is odd. :-)
Cheers,simon
?
Your comment

Commenting via the web interface is currently disabled.

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