Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#31864 - [cabal-install] 0.16.0 Fails immediately with own default configuration

Attached to Project: Arch Linux
Opened by Bardur Arantsson (ba_) - Tuesday, 09 October 2012, 17:03 GMT
Last edited by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 21:45 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Thomas Dziedzic (tomd123)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

Cabal-install 1.16.0 + Cabal 1.16.0 fails to work with its own default configuration.

Additional info:

cabal-install version 1.16.0
using version 1.16.0 of the Cabal library

Steps to reproduce:

$ rm -rf ~/.cabal # To force a new default config being written
$ cabal update # To write default config
Config file path source is default config file.
Config file /home/bardur/.cabal/config not found.
Writing default configuration to /home/bardur/.cabal/config
Downloading the latest package list from hackage.haskell.org
$ cabal install foo
cabal: Command.optionToFieldDescr: feature not implemented

Removing the "jobs" option from the config installed in ~/.cabal/config gets cabal-install up and running.

Do note the following two threads which seem to indicate that what's labeled as Cabal 0.16.0 is severely broken and there's a new Cabal + cabal-install combo out which should hopefully address this issue:

http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/9211
http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/9233
This task depends upon

Closed by  Thomas Dziedzic (tomd123)
Saturday, 13 October 2012, 21:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  pkgrel 2 adds a patch to remove the buggy line
Comment by Bernardo Barros (smoge) - Friday, 12 October 2012, 18:26 GMT
Also happens here. This is quite serious. Why no one has tested it before droping it into [extra]?
Comment by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 02:32 GMT
"Why no one has tested it before droping it into [extra]?"

Why are you assuming it wasn't tested?

It was in [testing] for a week and everyone who used it probably never rm -rf ~/.cabal

Anyways, I will look into upgrading cabal-install
Comment by Bernardo Barros (smoge) - Saturday, 13 October 2012, 02:35 GMT
Because after a major ghc update you have to remove ``~/.cabal''.
Thanks a bunch.
Comment by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 02:53 GMT
"you have to"

There is nothing that forces you to remove it, you only have to remove the libs, which are located in the .cabal/libs folder

also note that libs under the libs folder have a compiler version under each of them
Comment by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 03:18 GMT
Interesting, so it seems that the library (Cabal) provided by ghc is causing the bug..

I'm not sure what the best path is here:

Patch cabal that is in ghc and cause a mass rebuild of existing packages, or let this bug stay until the next ghc release.
Comment by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 03:52 GMT
Opened a bug upstream:
http://hackage.haskell.org/trac/ghc/ticket/7324

I'll wait and see what they have to say.
Comment by Bardur Arantsson (ba_) - Saturday, 13 October 2012, 06:31 GMT
Thanks for looking into this, Thomas.

My reading of the first post I linked to is that the Cabal library shipped with 7.6.1 is some "random" snapshot of the in-development Cabal 1.16.0 (which is recognized by everyone as happening to be broken), so patching the bundled Cabal up to 1.16.0.1 would probably be the most "correct" course of action.

Would this really lead to a huge number of rebuilds, though? Wouldn't it only be packages which actually *depend* on the Cabal library would require rebuilds? (Or does the Cabal hash "infect" the "base" package hash or something like that?)

It would be a real shame to have to wait until 7.6.2 to get a fix for this. There may be bugs that may be lurking in the bundled Cabal, but I'm not exactly sure *how* broken this Cabal snapshot is -- I immediately installed a new Cabal + cabal-install, using the broken one to bootstrap.
Comment by Bardur Arantsson (ba_) - Saturday, 13 October 2012, 06:38 GMT
Oh, wrt. waiting for 7.6.2: I don't think there's any set release date for that as of yet, so we may end up waiting a long time.
Comment by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 07:06 GMT
"Would this really lead to a huge number of rebuilds, though?"

Since Cabal ships with ghc, we would have to rebuild ghc with an updated Cabal library.
But rebuilding ghc requires rebuilding all haskell packages because haskell doesn't have a stable abi.

I will wait to see what upstream says before deciding on anything.
Comment by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 20:29 GMT
so upstream responded with:
https://github.com/haskell/cabal/commit/aa7d98f72f4a06ab2ab12defd046a21872a718d8

looks like the next cabal-install will have a workaround for this issue

Now to find when the next cabal-install release will happen

Loading...