From ryan at ryant.org Wed Mar 2 20:20:08 2016 From: ryan at ryant.org (Ryan Thomas) Date: Wed, 2 Mar 2016 20:20:08 +0000 Subject: ANN: Cabal and cabal-install 1.22 versions released Message-ID: Hi all, I have released the following versions of Cabal and cabal-install. Cabal - 1.22.8.0 cabal-install - 1.22.9.0 These are tagged in the repo, updated on the downloads site and uploaded to hackage. Cheers, ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Sat Mar 19 07:35:09 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 19 Mar 2016 18:35:09 +1100 Subject: Running the Cabal tests Message-ID: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> Hi all, I hacked together what I thought was a neat little feature (a 3 line diff) and thought I'd add a test. Thats when I figured out I couldn't even run the tests. Reading `Cabal/tests/Readme.md` I see I need to set the environment var: > * `CABAL_PACKAGETESTS_GHC` is the path to the GHC you compiled Cabal with > * `CABAL_PACKAGETESTS_GHC_PKG` is the path to the ghc-pkg associated with this GHC > * `CABAL_PACKAGETESTS_HADDOCK` is the path to the haddock associated with this GHC > * `CABAL_PACKAGETESTS_GHC_VERSION` is the version of your GHC > * `CABAL_PACKAGETESTS_DB_STACK` is a PATH-style list of package database paths, The first four are obvious and easy, but I have no idea how to set the last one. Clues? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mikhail.glushenkov at gmail.com Sat Mar 19 14:57:42 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Sat, 19 Mar 2016 15:57:42 +0100 Subject: Running the Cabal tests In-Reply-To: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> Message-ID: Hi, On 19 March 2016 at 08:35, Erik de Castro Lopo wrote: > Hi all, > > I hacked together what I thought was a neat little feature (a 3 line diff) > and thought I'd add a test. Thats when I figured out I couldn't even run > the tests. > > Reading `Cabal/tests/Readme.md` I see I need to set the environment var: Setting those vars shouldn't be *required*. Try to follow steps in HACKING.md (i.e. compile a Setup script manually and run './Setup [configure --enable tests | build | test]'). > The first four are obvious and easy, but I have no idea how to set the last one. It should look approx. like this: 'CABAL_PACKAGETESTS_DB_STACK=clear:global:/path/to/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d'. This assumes that you installed the version of Cabal you're testing into a sandbox under '/path/to/.cabal-sandbox'. From ezyang at mit.edu Sun Mar 20 01:34:19 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 19 Mar 2016 18:34:19 -0700 Subject: Running the Cabal tests In-Reply-To: References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> Message-ID: <1458436513-sup-2922@sabre> Excerpts from Mikhail Glushenkov's message of 2016-03-19 07:57:42 -0700: > Hi, > > On 19 March 2016 at 08:35, Erik de Castro Lopo wrote: > > Hi all, > > > > I hacked together what I thought was a neat little feature (a 3 line diff) > > and thought I'd add a test. Thats when I figured out I couldn't even run > > the tests. > > > > Reading `Cabal/tests/Readme.md` I see I need to set the environment var: > > Setting those vars shouldn't be *required*. Try to follow steps in > HACKING.md (i.e. compile a Setup script manually and run './Setup > [configure --enable tests | build | test]'). package-tests currently has a dumb hack to figure out these environment variables: it tries to read out the local build information associated with your build of Cabal. Unfortunately, this format is extremely backwards incompatible, which means any time someone changes the LBI data structure, the data becomes unreadable (spouting the error you've seen here.) Not too long ago, this problem never happened, because Cabal shipped with a 'Custom' build script which forced Cabal to be built *twice*; once to build the Setup script with the local source copy of Cabal, and then again for the actual Cabal hosted build. We stopped doing this because it was quite a pain to wait for Cabal to be built twice, but it did solve the problem of the LBI being wrong. Right now, Cabal is not bootstrapped in this way, which means that the LBI is whatever version of Cabal you have running, which probably is incompatible with the development version of Cabal, which means error. Probably the right way to fix this problem is to make the LBI serialization format more BC-friendly but this doesn't help poor users who are trying to dev Cabal with a Cabal that is not the most recent one. > > The first four are obvious and easy, but I have no idea how to set the last > one. > > It should look approx. like this: > 'CABAL_PACKAGETESTS_DB_STACK=clear:global:/path/to/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d'. > This assumes that you installed the version of Cabal you're testing > into a sandbox under '/path/to/.cabal-sandbox'. We should doc this. If you're not running any tests which need to build against the Cabal you just compiled (so, really, just tests involving Custom or the library test suite) then you can even just say 'clear:global' and the right thing should happen. Edward From mle+hs at mega-nerd.com Sun Mar 20 02:24:34 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 20 Mar 2016 13:24:34 +1100 Subject: Running the Cabal tests In-Reply-To: <1458436513-sup-2922@sabre> References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> <1458436513-sup-2922@sabre> Message-ID: <20160320132434.370b87e892b5052c0778b27d@mega-nerd.com> Edward Z. Yang wrote: > package-tests currently has a dumb hack to figure out these environment > variables: it tries to read out the local build information associated > with your build of Cabal. Thank you Ed. That explains some bizare behaviour I'm seeing. > Unfortunately, this format is extremely backwards incompatible, Not only that, but the assumption that we're currently testing with the same version of GHC that cabal-install was compiled with is really not very sound. For instance in my Jenkins build instance I have a number of GHC versions installed in /usr/lib/ghc-7.8/ , /usr/lib/ghc-7.10 and /usr/lib/ghc-8.0 but I only have one version of cabal-install in /usr/bin that was compiled with ghc-7.10. Since cabal-install is supposed to be buildable with the last two verions of GHC, I've been trying to build it in my Jenkins instance with ghc-7.8. Building has been fine, but I'm now trying to get tests working and that's when I ran into this problem. So, do you think package-tests can be fixed so it will work the way I'm trying to use it or should I just have GHC version specific versions of cabal-install when I want to build and run the tests for cabal? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ezyang at mit.edu Sun Mar 20 02:48:31 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 19 Mar 2016 19:48:31 -0700 Subject: Running the Cabal tests In-Reply-To: <20160320132434.370b87e892b5052c0778b27d@mega-nerd.com> References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> <1458436513-sup-2922@sabre> <20160320132434.370b87e892b5052c0778b27d@mega-nerd.com> Message-ID: <1458441818-sup-1028@sabre> Excerpts from Erik de Castro Lopo's message of 2016-03-19 19:24:34 -0700: > Edward Z. Yang wrote: > > > package-tests currently has a dumb hack to figure out these environment > > variables: it tries to read out the local build information associated > > with your build of Cabal. > > Thank you Ed. That explains some bizare behaviour I'm seeing. > > > Unfortunately, this format is extremely backwards incompatible, > > Not only that, but the assumption that we're currently testing with the > same version of GHC that cabal-install was compiled with is really not > very sound. Actually, the package test suite doesn't have to make this assumption (it just does so by default). If you add CABAL_PACKAGETESTS_WITH_GHC you can specify a version of GHC to do the tests with, distinct from the GHC version Cabal was built with. (It works best if the GHC versions match, however, because if you build Cabal with ghc-7.10 and then run the test suite with ghc-7.8 none of the tests which assume there is a Cabal library available for ghc-7.8 will work.) > Since cabal-install is supposed to be buildable with the last two verions > of GHC, I've been trying to build it in my Jenkins instance with ghc-7.8. > Building has been fine, but I'm now trying to get tests working and that's > when I ran into this problem. > > So, do you think package-tests can be fixed so it will work the way I'm > trying to use it or should I just have GHC version specific versions of > cabal-install when I want to build and run the tests for cabal? Well, for your specific problem, manually feeding in the environment variables OR switching to 'build-type: Custom', should be enough. Edward From mle+hs at mega-nerd.com Sun Mar 20 03:37:54 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 20 Mar 2016 14:37:54 +1100 Subject: Running the Cabal tests In-Reply-To: <1458441818-sup-1028@sabre> References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> <1458436513-sup-2922@sabre> <20160320132434.370b87e892b5052c0778b27d@mega-nerd.com> <1458441818-sup-1028@sabre> Message-ID: <20160320143754.6b72ee5461511e27dfb20944@mega-nerd.com> Edward Z. Yang wrote: > Actually, the package test suite doesn't have to make this assumption > (it just does so by default). If you add CABAL_PACKAGETESTS_WITH_GHC > you can specify a version of GHC to do the tests with, distinct from > the GHC version Cabal was built with. (It works best if the GHC > versions match, however, because if you build Cabal with ghc-7.10 and > then run the test suite with ghc-7.8 none of the tests which assume > there is a Cabal library available for ghc-7.8 will work.) Ok, that gets me closer. I now get three package-test failing (out of 60): GhcPkgGuess/Symlink: FAIL expected: is version 9999999 in output: Configuring SameDirectory-0.1.0.0... Setup: Cannot find the program 'ghc'. User-specified path '/home/erikd/Git/Haskell/cabal-erikd/Cabal-1.25.0.0/tests/PackageTests/GhcPkgGuess/Symlink/./ghc' does not refer to an executable and the program is not on the system path. GhcPkgGuess/SymlinkVersion: FAIL expected: is version 9999999 in output: Configuring SameDirectory-0.1.0.0... Setup: Cannot find the program 'ghc'. User-specified path '/home/erikd/Git/Haskell/cabal-erikd/Cabal-1.25.0.0/tests/PackageTests/GhcPkgGuess/SymlinkVersion/./ghc' does not refer to an executable and the program is not on the system path. GhcPkgGuess/SymlinkGhcVersion: FAIL expected: is version 9999999 in output: Configuring SameDirectory-0.1.0.0... Setup: Cannot find the program 'ghc'. User-specified path '/home/erikd/Git/Haskell/cabal-erikd/Cabal-1.25.0.0/tests/PackageTests/GhcPkgGuess/SymlinkGhcVersion/./ghc' does not refer to an executable and the program is not on the system path. These test don't fail when I'm building with ghc-7.10 (which was also used to build GHC). Should these tests fail like that? Maybe I should build cabal twice, once with ghc-7.8 to make sure it builds and once with ghc-7.10 where I can run the tests as well. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Sun Mar 20 04:15:45 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 20 Mar 2016 15:15:45 +1100 Subject: Running the Cabal tests In-Reply-To: <20160320143754.6b72ee5461511e27dfb20944@mega-nerd.com> References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> <1458436513-sup-2922@sabre> <20160320132434.370b87e892b5052c0778b27d@mega-nerd.com> <1458441818-sup-1028@sabre> <20160320143754.6b72ee5461511e27dfb20944@mega-nerd.com> Message-ID: <20160320151545.b84a36a4698f5149301824ee@mega-nerd.com> Erik de Castro Lopo wrote: > These test don't fail when I'm building with ghc-7.10 (which was also used to > build GHC). Should these tests fail like that? Correction, these tests pass with ghc-7.10 on my laptop and fail on my Jenkins box. My laptop and Jenkins box are both x86_64/linux running Debian. They have identical packages for ghc-7.10 and cabal-install. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ezyang at mit.edu Sun Mar 20 05:35:22 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 19 Mar 2016 22:35:22 -0700 Subject: Running the Cabal tests In-Reply-To: <20160320151545.b84a36a4698f5149301824ee@mega-nerd.com> References: <20160319183509.cbefd79ebdfe0232f37f8e9a@mega-nerd.com> <1458436513-sup-2922@sabre> <20160320132434.370b87e892b5052c0778b27d@mega-nerd.com> <1458441818-sup-1028@sabre> <20160320143754.6b72ee5461511e27dfb20944@mega-nerd.com> <20160320151545.b84a36a4698f5149301824ee@mega-nerd.com> Message-ID: <1458451290-sup-471@sabre> I would not worry too much about these; they're a bit touchy due to the use of symlinks. If you could figure out why they are failing that would be helpful though! Edward Excerpts from Erik de Castro Lopo's message of 2016-03-19 21:15:45 -0700: > Erik de Castro Lopo wrote: > > > These test don't fail when I'm building with ghc-7.10 (which was also used to > > build GHC). Should these tests fail like that? > > Correction, these tests pass with ghc-7.10 on my laptop and fail on my Jenkins > box. My laptop and Jenkins box are both x86_64/linux running Debian. They have > identical packages for ghc-7.10 and cabal-install. > > Erik