Hi Martijn, Yes, upgrading will obviously fix things (we do use 0.14 on our development machines), but we have not set up any infrastructure for building a custom cabal on production servers. We just use the one from the Ubuntu repositories, which uses Cabal 1.10.1.0 on oneiric. So until we upgrade to precise I guess we have a problem. Erik On Wed, Jul 18, 2012 at 5:24 PM, Martijn Schrage wrote:

Hi Erik,

A similar thing happened to me with the GraphViz package. As Duncan explained to me, the problem is that Cabal-1.10.0.0 (and I believe also 1.10.1.0) incorrectly reports an error when conditionals are used in test suites.

Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with Cabal-1.14.0) should fix the problem. Unfortunately, this means your build will not work on a fresh Haskell Platform v2012.2.0.0, until HUnit is patched in the hackage index.

Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com)

On 18-07-12 16:26, Erik Hesselink wrote:

...

Hi all,

All cabal installs using cabal-install-0.10.2 are currently failing for us. This is due to the cabal file for HUnit-1.2.5.0, which was recently uploaded to hackage. The ouput I'm getting from cabal is just:

Reading available packages... Resolving dependencies... cabal: Couldn't read cabal file "HUnit/1.2.5.0/HUnit.cabal"

If I unpack HUnit-1.2.5.0 and call 'cabal configure', I get:

cabal: HUnit.cabal:57: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0

The relevant lines from the cabal file are:

Test-Suite hunit-tests-optimize-0 Type: exitcode-stdio-1.0

These look fine to me.

Does anyone have any idea how to go about fixing this (on hackage at least)? Could this package temporarily be removed, to avoid breaking everyone's cabal?

Erik

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

CCing: Ross Paterson and Richard G. On Wed, Jul 18, 2012 at 05:54:44PM +0200, Martijn Schrage wrote:

...

Hi Martijn,

Yes, upgrading will obviously fix things (we do use 0.14 on our development machines) Well, to me it wasn't entirely obvious that upgrading to Cabal-1.10.2.0 fixes the problem for cabal-install-0.12, and I still

On 18-07-12 17:37, Erik Hesselink wrote: think this is a good solution for most people that use version 2012.2.0.0 of the platform.

I'd suggest you ask Duncan to patch the hackage repository, and maybe contact the maintainer of HUnit to prevent future problems.

This also breaks all travis-ci builds. I think it is critical to refrain from using conditionals in test-suite stanzas for some time + fix the "broken" release on Hackage. Is there a way to make this issue more well-know. Would a warning on the upload page help? @Richard FYI: Just uploading a new package won't solve this issue. Cheers, Simon

-- Martijn

...

, but we have not set up any infrastructure for building a custom cabal on production servers. We just use the one from the Ubuntu repositories, which uses Cabal 1.10.1.0 on oneiric. So until we upgrade to precise I guess we have a problem.

Erik

On Wed, Jul 18, 2012 at 5:24 PM, Martijn Schrage wrote:

...

Hi Erik,

A similar thing happened to me with the GraphViz package. As Duncan explained to me, the problem is that Cabal-1.10.0.0 (and I believe also 1.10.1.0) incorrectly reports an error when conditionals are used in test suites.

Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with Cabal-1.14.0) should fix the problem. Unfortunately, this means your build will not work on a fresh Haskell Platform v2012.2.0.0, until HUnit is patched in the hackage index.

Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com)

On 18-07-12 16:26, Erik Hesselink wrote:

...

Hi all,

All cabal installs using cabal-install-0.10.2 are currently failing for us. This is due to the cabal file for HUnit-1.2.5.0, which was recently uploaded to hackage. The ouput I'm getting from cabal is just:

Reading available packages... Resolving dependencies... cabal: Couldn't read cabal file "HUnit/1.2.5.0/HUnit.cabal"

If I unpack HUnit-1.2.5.0 and call 'cabal configure', I get:

cabal: HUnit.cabal:57: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0

The relevant lines from the cabal file are:

Test-Suite hunit-tests-optimize-0 Type: exitcode-stdio-1.0

These look fine to me.

Does anyone have any idea how to go about fixing this (on hackage at least)? Could this package temporarily be removed, to avoid breaking everyone's cabal?

Erik

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Ross, can you fix this on Hackage? My suggested solution is to again just remove the test-suite sections from the cabal file, if that is fine with Richard. The current situation is unfortunate, as it breaks almost all installs from Hackage with cabal-install 0.10.2 / Cabal 1.10.1.0, e.g. you can not even upgrade cabal-install anymore: $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library $ cabal install cabal-install Resolving dependencies... cabal: Couldn't read cabal file "HUnit/1.2.5.0/HUnit.cabal" Cheers, Simon

On Fri, Jul 20, 2012 at 10:02:18AM +0100, Ross Paterson wrote:

On Fri, Jul 20, 2012 at 09:34:16AM +0100, Simon Hengel wrote:

...

Hi Ross, can you fix this on Hackage? My suggested solution is to again just remove the test-suite sections from the cabal file, if that is fine with Richard.

I'll modify the packages in-place if there's a consensus on what to do.

I think Richard gave his consent. Is there still anything we need to sort out? BTW: Here is a reddit story on the issue: http://www.reddit.com/r/haskell/comments/x16h7/hackage_b0rked_for_cabal_0102... Cheers, Simon

On Wed, Jul 25, 2012 at 12:22 PM, Ross Paterson wrote:

As I understand it, the plan is to modify the following packages in hackage in-situ to remove the test sections (which contain the troublesome conditionals):

HUnit-1.2.5.0 bloomfilter-1.2.6.10 codemonitor-0.1 codemonitor-0.2 fixhs-0.1.4 leksah-server-0.12.0.3 leksah-server-0.12.0.4 leksah-server-0.12.0.5 pqc-0.5 pqc-0.5.1

Does anyone object?

No objections, but some impatience. ;-) Cheers, /Niklas

On Mon, Jul 30, 2012 at 3:33 PM, Ross Paterson wrote:

On Mon, Jul 30, 2012 at 01:46:24PM +0100, Niklas Broberg wrote:

...

On Wed, Jul 25, 2012 at 12:22 PM, Ross Paterson wrote:

As I understand it, the plan is to modify the following packages in hackage in-situ to remove the test sections (which contain the troublesome conditionals):

HUnit-1.2.5.0 bloomfilter-1.2.6.10 codemonitor-0.1 codemonitor-0.2 fixhs-0.1.4 leksah-server-0.12.0.3 leksah-server-0.12.0.4 leksah-server-0.12.0.5 pqc-0.5 pqc-0.5.1

Does anyone object?

No objections, but some impatience. ;-)

OK, done.

I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it again? For the future: is there any way to prevent this from happening? Perhaps a check in hackage? I'd be willing to implement this if people think this is a good idea, and I'm pointed in the right direction. Erik

On Mon, Aug 27, 2012 at 7:52 PM, Bryan O'Sullivan wrote:

On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink wrote:

...

I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it again?

Hang on a second.

The reason you're seeing build breakage is that the .cabal files of the broken packages were edited in-place without communicating with any of the package authors.

I understand that the collective intentions around this were good, but by "fixing" things without telling anyone, package maintainers have no way to know that anything has happened. Now we are seeing the problem begin to recur as people issue new releases that don't incorporate those changes.

So. Let's have a little conversation about how to handle this sustainably before wasting more of Ross's time.

Yes, you are right. So the question is how long to support systems with the old cabal 0.10. This is the one included with the previous haskell platform (and thus lots of linux distro's), which is less than a year old. But it's also pretty old, since there weren't any cabal releases for a while. The other question is how useful test suites in a released package are. Aren't they much more useful (and used more often) in source repositories? If we do agree that we want to prevent this problem for a while (which I'm not sure about), we should probably do it by preventing uploads for packages like this. That way, package maintainers will know what is going on, just like with the other 'package quality' issues hackage enforces. Erik

On Mon, Aug 27, 2012 at 11:39 AM, Erik Hesselink wrote:

Yes, you are right. So the question is how long to support systems with the old cabal 0.10. This is the one included with the previous haskell platform (and thus lots of linux distro's), which is less than a year old. But it's also pretty old, since there weren't any cabal releases for a while.

That's a very awkward situation. At least in the future, Johan and I have a proposal to make this class of problem more avoidable by introducing a regular release schedule. See the thread that starts here for details: http://www.haskell.org/pipermail/cabal-devel/2012-August/008987.html For the state of things today, it's not obvious to me what to do. It's burdensome to ask package authors to remove stuff from their packages because it can't be handled by a broken version of cabal, especially since there's no upper bound on how long that broken version will be floating around. We'd essentially be giving up on this feature semi-permanently, which would make me sad because it's so useful. Just as unappealing is the idea of breaking builds for people who, through no fault of their own, are using the broken cabal. However, at least this class of people has the incentives aligned to do something about their problem: either upgrade cabal-install or their distro. The other question is how useful test suites in a released package

are. Aren't they much more useful (and used more often) in source repositories?

They're certainly useful in source repositories, and we have historically chosen not to make a distinction between what's in a source repo and what gets shipped to end users via cabal, which makes sense to me.

On Aug 27, 2012 8:40 PM, "Erik Hesselink" wrote:

The other question is how useful test suites in a released package are. Aren't they much more useful (and used more often) in source repositories?

Having tests available in a released package allows one to verify that the software is functional in its current configuration / state on your system; this seems extremely useful to me.

On Mon, Aug 27, 2012 at 10:52:59AM -0700, Bryan O'Sullivan wrote:

On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink wrote:

...

I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it again?

Hang on a second.

The reason you're seeing build breakage is that the .cabal files of the broken packages were edited in-place without communicating with any of the package authors.

I understand that the collective intentions around this were good, but by "fixing" things without telling anyone, package maintainers have no way to know that anything has happened. Now we are seeing the problem begin to recur as people issue new releases that don't incorporate those changes.

For the record, abstract-deque was neither one of the packages fixed previously, nor does its .cabal file even contain a test section at all, much less one with a conditional. So if cabal-install-0.10 is failing to read it, it is because of some different problem. But I agree with Bryan in principle that we need a more principled approach. -Brent

Well, this one looks like it was my fault because I never read this thread and this morning I uploaded that package (abstract-deque) with the conditional in the test-suite. The reason this conditional isn't there now is that the package was hacked in place to remove tests, which is fine. Actually, as a maintainer I'm not really clear on how to test this behavior. I tried "cabal configure" with cabal-install-0.10.2 as in the original post and I couldn't reproduce the problem.

For the record, abstract-deque was neither one of the packages fixed previously, nor does its .cabal file even contain a test section at all, much less one with a conditional. So if cabal-install-0.10 is failing to read it, it is because of some different problem. But I agree with Bryan in principle that we need a more principled approach.

-Brent

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan wrote:

On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan wrote:

...

The reason you're seeing build breakage is that the .cabal files of the broken packages were edited in-place without communicating with any of the package authors.

Not to flog a dead horse, but:

Just yesterday we had a communication from someone on the Gentoo Linux packaging team that their checksum validation for the bloomfilter package was failing. This problem arose because of the hand-editing of the package, but confusion arose in the bug report due to misattribution of the source of the error.

https://github.com/haskell/cabal/issues/1017

Hand-editing uploaded tarballs: just don't do it, kids!

Not to flog a dead horse, but: All our builds broke again yesterday due to this bug. The package was iteratee-0.8.9.3, though given the vocal opposition of Bryan O'Sullivan, I won't advocate fixing it in place just now. I've built the test in the Cabal library to reject packages with conditionals in the test-suites section. I'm just not sure if we want to implement this on hackage, and for how long. I'm not quite sure how old this cabal version is that is causing the problems, but the haskell platform it comes with is 2011.2, which means the second quarter of 2011, so that is a little over a year old. It comes with Ubuntu 11.10, which is less than a year old. I was going to argue to support versions of cabal (and GHC) for at least a year. That means that if you're on Ubuntu, which has releases every 6 months, you have 6 months to upgrade. However, that year has already expired for cabal 0.10, or is about to expire if you count the Ubuntu release it came with. So what do others think? Does the haskell community want to support anything other than the bleeding edge? If so, for how long? Regards, Erik

Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with Cabal-1.14.0) should fix the problem.

Currently you would have to do the upgrade manually, as `cabal-install cabal-install` won't work (or alternatively edit your local ~/.cabl/packages/hackage.haskell.org/00-index.tar). See my other mail to this thread. Cheers, Simon