- cabal-devel - Haskell.org

Library version choosing of cabal sandbox build
by Daniel Trstenjak 16 Jul '14

16 Jul '14

Hi, if I'm having a cabal file without an upper bound for a library, the newest available version of the library is 3, there's a local/user installation of the version 2 of the library, which version of the library is a cabal sandbox build supposed to use? In my case I can see that version 2 of the library is used. If this is intended, how can I ensure that always the newest version is used independent of any local/user installations? Thanks! Greetings, Daniel

4 12

Procedure for updating GHC submodule pointer to Cabal
by Edward Z. Yang 04 Jul '14

04 Jul '14

Hello all, I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407) and this functionality requires concurrent changes to GHC and Cabal. However, GHC is currently tracking 1.20, but Cabal HEAD has marched on. My question is, if I am to do this development on HEAD, what is the standard operating procedure for retargeting GHC to a recent version of Cabal? Of course I have to go and validate the build, but are there any other considerations? Is this recorded anywhere? Thanks, Edward

3 2

InstalledPackageInfo, IPI641, IPI642
by Edward Z. Yang 30 Jun '14

30 Jun '14

Hello all, I am currently adding support for packages to reexport modules (proper) from other packages, but I've run into a nasty bit of BC in Cabal that I don't quite understand; namely, InstalledPackageInfo, IPI641 and IPI642. So, I understand in principle why we might want these data structures: GHC is compiled with a specific version of Cabal, but one might want to use a version of cabal-install with a different version of Cabal. What I don't understand is why we have both InstalledPackageInfo and IPI642. Additionally, what is the procedure for making changes to the IPI format? This seems to have only been done once before, and I am not sure how the current scheme generalizes. Thanks, Edward

1 0

Re: Any more bug fixes for the next cabal-install 1.20 release?
by Johan Tibell 26 Jun '14

26 Jun '14

This is what I have so far: - 086a62e82d9dc3bfa66b57d738ba9f94a641ffad Don't attempt to rename dist if it is already named correctly - a46df9dbfe14df0df60c8cc401221c4128ad675e Remove an unnecessary 'createDirectoryIfMissing' call. (cherry picked from commit 5c46e7853a09a484698064824b7bf72c5c761993) - 5b63fce601997009376522c5de9b11275c3681ee Treat all flags of a package as interdependent. - 302b0dce271bf194b42afa3f90c57cffff35cc72 Print full build log instead of only the last 10 lines - ffd67e5e630766906e6f4c6655c067a79f739150 Allow template-haskell to be upgradable again Note that the commit IDs are different since these are cherry-picked form master. On Tue, Jun 24, 2014 at 5:41 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 2014-06-24 09:38, Johan Tibell wrote: > > I'm making another cabal-install release from the 1.20 branch to fix some > > more solver issues. In particular, I'm releasing this commit > > > > 3f777568 Treat all flags of a package as interdependent. > > > > Are there any other bug fixes *already in master* that are safe/useful > > enough to include in the next cabal-install 1.20 release? > > > > -- Johan > > > > > > Any chance of getting 2cbe6498650c9bf676571ba5321b8fd6b9ad512e in? > > Seems pretty useful and harmless, but then I'm probably biased ;). > > Regards, > >

2 5

Any more bug fixes for the next cabal-install 1.20 release?
by Johan Tibell 24 Jun '14

24 Jun '14

I'm making another cabal-install release from the 1.20 branch to fix some more solver issues. In particular, I'm releasing this commit 3f777568 Treat all flags of a package as interdependent. Are there any other bug fixes *already in master* that are safe/useful enough to include in the next cabal-install 1.20 release? -- Johan

1 0

ETag support broken on hackage.haskell.org
by Gintautas Miliauskas 16 Jun '14

16 Jun '14

Hi, first of all, a shout out to all ZuriHac2014 folks, thanks for the gentle introduction to the deeper trenches of Haskell infrastructure! I spent a bit of time looking into why "cabal update" always redownloads the entire package list even though the code has explicit support for etags, and it looks like etags are broken on the server side. The server does serve "Etag" headers, but does not react to If-None-Match: $ curl -I --header 'If-None-Match: "1ea6c9a3168b9c186d5bbafd065ce5ec"' hackage.haskell.org/packages/index.tar.gz HTTP/1.1 200 OK Server: nginx/1.6.0 Date: Mon, 09 Jun 2014 23:22:49 GMT Content-Type: application/x-gzip Content-Length: 7193838 Connection: keep-alive Content-MD5: 1ea6c9a3168b9c186d5bbafd065ce5ec ETag: "1ea6c9a3168b9c186d5bbafd065ce5ec" Last-modified: Mon, 09 Jun 2014 23:10:44 GMT In this case the server is supposed to return a 304 code because the ETag matches, but it returns the usual 200. Here's a well-behaved server for comparison: $ curl -I --header 'If-None-Match: f89ef04efbcb1bbd413c9170523beeb1' http://upload.wikimedia.org/ HTTP/1.1 304 Not Modified Last-Modified: Thu, 03 Oct 2013 22:29:34 GMT Etag: f89ef04efbcb1bbd413c9170523beeb1 X-Timestamp: 1380839374.33426 X-Object-Meta-Mtime: 1366745378.0 Content-Type: text/html X-Varnish: 2552484147 2541352860, 2937266545 2853346814, 523731362 Via: 1.1 varnish, 1.1 varnish, 1.1 varnish Accept-Ranges: bytes Date: Mon, 09 Jun 2014 23:29:36 GMT Age: 38954 Connection: keep-alive X-Cache: cp1064 hit (336), cp3010 hit (1791), cp3007 frontend miss (0) Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, X-Varnish Note the 304 return code. I do not know about the configuration in use on the server, but something seems to be wrong there. There are some nginx bug reports [1] about similar issues, not sure if they are relevant here. [1] https://github.com/rgrove/rawgit/issues/13 Best regards, -- Gintautas Miliauskas

3 4

Shell Monad and my zurihac2014 project
by Greg Horn 13 Jun '14

13 Jun '14

Hello all, My Zurihac2014 project was to address https://github.com/haskell/cabal/issues/975. I thought the cleanest way was to make two passes: 1. put executeInstallPlan into a Shell Monad to force printing debug/status messages through the monad, and track the current status of the parallel build. and 2. Use this information to write a nice UI I have implemented (1) and here is the pull request https://github.com/haskell/cabal/pull/1940. I'd appreciate if someone could make a thorough code review as it's my first commit to cabal and I only understand a small corner of the code base. If this is accepted then I also look forward to working on (2), probably based on ncurses. Best, Greg

1 0

Re: Broken documentation on Hackage.
by selinger＠mathstat.dal.ca 08 Jun '14

08 Jun '14

Good point. But could you remind me what package this Makefile is in? As far as I remember, this Makefile is for the private use of package authors, and is not included in any publicly available code. -- Peter Serge Kosyrev wrote: > > Peter, > > A notable detail we should consider is -- not sending the user password > unencrypted over the wire: > > --- Makefile 2014-06-08 18:13:44.205418114 +0400 > +++ Makefile.orig 2014-06-08 18:32:50.999706699 +0400 > @@ -27,7 +27,7 @@ > tar -Hustar -zcf ${PACKAGE}-${VERSION}-docs.tar.gz ${PACKAGE}-${VERSION}-docs > > doc-upload: ${PACKAGE}-${VERSION}-docs.tar.gz > - echo -n "Hackage password for ${HACKAGE_USER}: "; read PASSWORD; curl -X PUT -H 'Content-Type: application/x-tar' -H 'Content-Encoding: gzip' --data-binary @${PACKAGE}-${VERSION}-docs.tar.gz http://${HACKAGE_USER}:$$PASSWORD@hackage.haskell.org/package/${PACKAGE}-${VERSION}/docs > + echo -n "Hackage password for ${HACKAGE_USER}: "; read PASSWORD; curl -X PUT -H 'Content-Type: application/x-tar' -H 'Content-Encoding: gzip' --data-binary @${PACKAGE}-${VERSION}-docs.tar.gz https://${HACKAGE_USER}:$$PASSWORD@hackage.haskell.org/package/${PACKAGE}-${VERSION}/docs > > install: dist/setup/setup > cabal install > > -- > с уважениeм, > Серёга Косырев >

1 0

Re: Broken image?
by Duncan Coutts 04 Jun '14

04 Jun '14

Cheers! Fixed. I've stashed copies of all the Cabal logo files in http://www.haskell.org/cabal/images/ (FYI the cabal website is a darcs repo) On Tue, 2014-04-08 at 13:19 -0700, Jonan Scheffler wrote: > Who can fix this? > On Apr 8, 2014 11:47 AM, <cabal-devel-owner(a)haskell.org> wrote: > > > You are not allowed to post to this mailing list, and your message has > > been automatically rejected. If you think that your messages are > > being rejected in error, contact the mailing list owner at > > cabal-devel-owner(a)haskell.org. > > > > > > > > ---------- Forwarded message ---------- > > From: Jonan Scheffler <jonanscheffler(a)gmail.com> > > To: cabal-devel(a)haskell.org > > Cc: > > Date: Tue, 8 Apr 2014 11:47:02 -0700 > > Subject: Broken image? > > The Cabal logo image on http://www.haskell.org/cabal/ is broken. Is there > > someplace I could put in an issue/PR? > > > > Jonan > > -- > > Jonan Scheffler > > @1337807 <http://twitter.com/1337807> > > jonanscheffler(a)gmail.com > > (503) 985-6626 > > > >

1 0

cabal-install-1.20.0.2 binaries needed for Windows and Linux
by Johan Tibell 30 May '14

30 May '14

Hi all, There's some important bug fixes in Cabal-1.20.0.1 and cabal-install-1.20.0.2 and I'd like to upload some binaries to make it easier for users to upgrade. Could someone build me a Windows binary? We could also use Linux binaries, but that's less important. Please make sure you use the versions above* and that you include the architecture (x86 or x86-64) in the email you send to me. Thanks! * Double check using cabal --version before emailing. -- Johan

2 1