Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Push new version to Hackage #74

Open
bgamari opened this Issue Nov 15, 2012 · 9 comments

Comments

Projects
None yet
5 participants

bgamari commented Nov 15, 2012

Currently the version on Hackage does not compile with GHC 7.6.

akaspin commented Dec 11, 2012

Bump

Contributor

jtdaugherty commented Dec 15, 2012

In order to push a new release to Hackage, we need to be sure cabal-dev works on the two most recent Haskell Platform releases in addition to GHC 7.6. It's pretty clear that we have GHC 7.6 out of the way. Care to help us out and test on HP 2012.4.0.0 and HP 2012.2.0.0? Also, it needs to be tested on at least Linux and Windows, with OS X being valuable, too.

Contributor

etrepum commented Jan 11, 2013

Well, the current hackage version definitely does not work on OS X with HP 2012.4.0.0 prior to this commit 80d7bc3#cabal-dev.cabal

Installing from source (415351d) appears to work fine (ghc 7.4.2, HP 2012.4.0.0, Mac OS X 10.8.2, used homebrew to install ghc and haskell-platform)

$ git clone https://github.com/creswick/cabal-dev.git && (cd cabal-dev; cabal install)
Cloning into 'cabal-dev'...
[…]
Linking dist/build/cabal-dev/cabal-dev ...
Installing executable(s) in /Users/bob/.cabal/bin
Contributor

etrepum commented Jan 11, 2013

Just my opinion, but I think you should probably just push what you have now. If you broke HP 2012.2.0.0 on some platform, I'm sure you'll hear about it eventually. Keeping up with HP 2012.4.0.0 and newer GHC is probably much more important, people with old versions can always target some old version of cabal-dev on hackage until any backwards compatibility issues are sorted out.

spockz commented Jan 26, 2013

I concur with etrepum, it is very inconvenient not to be able to build cabal-dev on a fresh HP2012.4.0.0 install.

Contributor

etrepum commented Feb 12, 2013

@jtdaugherty in #91 you mentioned that "some tests are failing" and this is the reason why there hasn't been a new release. Where can we find out more about the tests that are failing?

Contributor

jtdaugherty commented Feb 12, 2013

You can find out by running this from the root of the repository:

$ bin/runtests
Contributor

etrepum commented Feb 19, 2013

@jtdaugherty the failures seem to be timing related, probably cabal-dev is being executed in parallel with itself. I'll dig a bit deeper and submit a PR once I've figured it out.

Contributor

etrepum commented Feb 20, 2013

On further inspection, I believe that 00-index.cache is the problem in addSourceStaysSandboxed. Here's what I think is happening (all during the same second, let's call it M):

  • 00-index.tar is created with an empty index (withTempPackage), this file has an mtime of M.
  • 00-index.cache is created during the install that is expected to fail (withCabalDev assertExitsFailure ["install", pkgStr]). This file is empty and has an mtime of M.
  • 00-index.tar is updated with the new package (withCabalDev assertExitsSuccess ["add-source", packageDir])), the mtime does not change since the clock is still at M. The problem is here, 00-index.cache still exists and is still considered to be valid but it's actually stale (and empty).
  • The test fails at withCabalDev assertExitsSuccess ["install", pkgStr, "--verbose=" ++ showForCabal v] because the (empty) 00-index.cache is incorrectly considered to be valid since it has the same mtime (M) as 00-index.tar.

I think any operation that updates 00-index.tar should probably just remove the cache file. Also, this appears to be a cabal-install bug, not a cabal-dev bug. My recommendation would be to include a workaround in the test suite for cabal-dev (e.g. manually delete or refresh the cache after the add-source) and file a bug against cabal-install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment