From duncan.coutts at googlemail.com Wed Jun 4 13:31:22 2014 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed, 04 Jun 2014 14:31:22 +0100 Subject: Broken image? In-Reply-To: References: Message-ID: <1401888682.19882.335.camel@dunky.localdomain> 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, 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 at haskell.org. > > > > > > > > ---------- Forwarded message ---------- > > From: Jonan Scheffler > > To: cabal-devel at 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 > > jonanscheffler at gmail.com > > (503) 985-6626 > > > > From selinger at mathstat.dal.ca Sun Jun 8 17:06:40 2014 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Sun, 8 Jun 2014 14:06:40 -0300 (ADT) Subject: Broken documentation on Hackage. In-Reply-To: <87k38rnzxp.fsf@andromedae.feelingofgreen.ru> Message-ID: <20140608170640.203A98C016F@chase.mathstat.dal.ca> 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 at 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 at hackage.haskell.org/package/${PACKAGE}-${VERSION}/docs > > install: dist/setup/setup > cabal install > > -- > ? ???????e?, > ?????? ??????? > From gintautas.miliauskas at gmail.com Mon Jun 9 23:34:26 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Tue, 10 Jun 2014 01:34:26 +0200 Subject: ETag support broken on hackage.haskell.org Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Jun 10 07:54:54 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 10 Jun 2014 09:54:54 +0200 Subject: ETag support broken on hackage.haskell.org In-Reply-To: References: Message-ID: We need to figure out if nginx or the hackage-server is to blame here. On Tue, Jun 10, 2014 at 1:34 AM, Gintautas Miliauskas < gintautas.miliauskas at gmail.com> wrote: > 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 > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.coutts at googlemail.com Tue Jun 10 09:38:08 2014 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue, 10 Jun 2014 10:38:08 +0100 Subject: ETag support broken on hackage.haskell.org In-Reply-To: References: Message-ID: I'm pretty sure it's the hackage-server. I think we simply don't have code yet to react to the if-none-match. Happstack has some util for the time-based conditionals, but not the etag one. So it should just be a matter of us adding a combinator that both serves the etag and reacts to the if-none-match header. Then we'd go and use that in all the places where we currently serve etags. At the same time, it's probably worth making that caching combinator also take an optional timestamp and "valid for" time, so we can do all our caching things in one call in each resource handler. On 10 June 2014 08:54, Johan Tibell wrote: > We need to figure out if nginx or the hackage-server is to blame here. > > > On Tue, Jun 10, 2014 at 1:34 AM, Gintautas Miliauskas > wrote: >> >> 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 >> >> _______________________________________________ >> cabal-devel mailing list >> cabal-devel at haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel >> > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From gintautas.miliauskas at gmail.com Tue Jun 10 21:14:03 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Tue, 10 Jun 2014 23:14:03 +0200 Subject: ETag support broken on hackage.haskell.org In-Reply-To: References: Message-ID: I just checked and indeed hackage-server is ignoring the If-none-match header. I'll see if I can make it work. On Tue, Jun 10, 2014 at 11:38 AM, Duncan Coutts < duncan.coutts at googlemail.com> wrote: > I'm pretty sure it's the hackage-server. I think we simply don't have > code yet to react to the if-none-match. Happstack has some util for > the time-based conditionals, but not the etag one. So it should just > be a matter of us adding a combinator that both serves the etag and > reacts to the if-none-match header. Then we'd go and use that in all > the places where we currently serve etags. At the same time, it's > probably worth making that caching combinator also take an optional > timestamp and "valid for" time, so we can do all our caching things in > one call in each resource handler. > > On 10 June 2014 08:54, Johan Tibell wrote: > > We need to figure out if nginx or the hackage-server is to blame here. > > > > > > On Tue, Jun 10, 2014 at 1:34 AM, Gintautas Miliauskas > > wrote: > >> > >> 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 > >> > >> _______________________________________________ > >> cabal-devel mailing list > >> cabal-devel at haskell.org > >> http://www.haskell.org/mailman/listinfo/cabal-devel > >> > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > > > -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita at karetnikov.org Fri Jun 13 02:57:50 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Fri, 13 Jun 2014 06:57:50 +0400 Subject: Proposal: cabal-install: verify OpenPGP signatures In-Reply-To: <87iopjuq7j.fsf@karetnikov.org> (Nikita Karetnikov's message of "Tue, 06 May 2014 15:00:32 +0400") References: <87eh0fafsq.fsf@karetnikov.org> <1399287343.18197.190.camel@dunky.localdomain> <87iopjuq7j.fsf@karetnikov.org> Message-ID: <87zjhh349d.fsf@karetnikov.org> I created a repository on Gitorious and pushed a couple of commits to the openpgp branch [1]. (There is nothing related to cabal-install yet, so apologies for off-topic.) [1] https://gitorious.org/hackage-server/hackage-server/commits/openpgp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From gregmainland at gmail.com Fri Jun 13 17:02:57 2014 From: gregmainland at gmail.com (Greg Horn) Date: Fri, 13 Jun 2014 19:02:57 +0200 Subject: Shell Monad and my zurihac2014 project Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gintautas.miliauskas at gmail.com Mon Jun 16 21:40:41 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Mon, 16 Jun 2014 23:40:41 +0200 Subject: ETag support broken on hackage.haskell.org In-Reply-To: References: Message-ID: Hi, I spent some time looking into this and was able to get etags checking to work, see [1] [1] https://github.com/haskell/hackage-server/pull/236 However, my approach only deals with etags only for the index tarball. I poked around for quite a while seeing if there is a more general solution, but could not find anything useful. The thing is, support for computing etags is hand-coded for the index tarball, so a more generic mechanism does not make much sense. Plus, servePackagesIndex is the only logical place to handle etags in the request, since further down we do not have access to the request and further up we do not have access to the tarball object which embeds the md5sum. On Tue, Jun 10, 2014 at 11:38 AM, Duncan Coutts < duncan.coutts at googlemail.com> wrote: > I'm pretty sure it's the hackage-server. I think we simply don't have > code yet to react to the if-none-match. Happstack has some util for > the time-based conditionals, but not the etag one. So it should just > be a matter of us adding a combinator that both serves the etag and > reacts to the if-none-match header. Then we'd go and use that in all > the places where we currently serve etags. At the same time, it's > probably worth making that caching combinator also take an optional > timestamp and "valid for" time, so we can do all our caching things in > one call in each resource handler. > > On 10 June 2014 08:54, Johan Tibell wrote: > > We need to figure out if nginx or the hackage-server is to blame here. > > > > > > On Tue, Jun 10, 2014 at 1:34 AM, Gintautas Miliauskas > > wrote: > >> > >> 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 > >> > >> _______________________________________________ > >> cabal-devel mailing list > >> cabal-devel at haskell.org > >> http://www.haskell.org/mailman/listinfo/cabal-devel > >> > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > > > -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita at karetnikov.org Sat Jun 21 15:56:05 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Sat, 21 Jun 2014 19:56:05 +0400 Subject: Proposal: cabal-install: verify OpenPGP signatures In-Reply-To: <87zji9fstm.fsf@karetnikov.org> (Nikita Karetnikov's message of "Fri, 23 May 2014 00:43:01 +0400") References: <87eh0fafsq.fsf@karetnikov.org> <1399287343.18197.190.camel@dunky.localdomain> <87zji9fstm.fsf@karetnikov.org> Message-ID: <87d2e28dey.fsf@karetnikov.org> > If a package is signed, the maintainers have the permission to sign. If > it?s necessary to add a maintainer, the uploader lists a username in a > file, signs it, and uploads. (Is there a better way to achieve the same > thing?) The server checks the signature, parses the file, and adds the > usernames to the maintainers group. > Since it?s important to sign the file locally, there should be a > convenience tool allowing to select the usernames. This is too complicated and has some drawbacks. I?m currently working on the following: 1. It should be possible to upload a signature while uploading a package. The server must check that the signature corresponds to the uploader?s key. 2. If it?s necessary to add a new maintainer, the initial uploader must sign the public key of the said maintainer. (This will be checked by cabal-install.) For ?cabal-install?: 1. A warning must be raised if a package that was signed previously is not signed. 2. If a package is signed but was not signed previously, ?cabal-install? must check its signature and add the public key to the cache. 3. If a package was signed but now is signed with a different key, ?cabal-install? must check whether this key is signed with the previously-known key corresponding to this package, then verify the signature. If not, a warning must be raised. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From johan.tibell at gmail.com Tue Jun 24 07:38:27 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 24 Jun 2014 09:38:27 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Jun 24 19:55:06 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 24 Jun 2014 21:55:06 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? In-Reply-To: <53A99C2D.2020405@scientician.net> References: <53A99C2D.2020405@scientician.net> Message-ID: 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 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, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue Jun 24 20:35:35 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 24 Jun 2014 22:35:35 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? In-Reply-To: References: <53A99C2D.2020405@scientician.net> Message-ID: Hi Johan, On 24 June 2014 21:55, Johan Tibell wrote: > This is what I have so far: > > [...] > a46df9dbfe14df0df60c8cc401221c4128ad675e Remove an unnecessary > 'createDirectoryIfMissing' call. (cherry picked from commit > 5c46e7853a09a484698064824b7bf72c5c761993) Sorry, it looks like that change was incorrect. I'm working on a better fix. From the.dead.shall.rise at gmail.com Tue Jun 24 21:12:41 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 24 Jun 2014 23:12:41 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? In-Reply-To: References: <53A99C2D.2020405@scientician.net> Message-ID: Hi, On 24 June 2014 22:35, Mikhail Glushenkov wrote: > Hi Johan, > > On 24 June 2014 21:55, Johan Tibell wrote: >> This is what I have so far: >> >> [...] >> a46df9dbfe14df0df60c8cc401221c4128ad675e Remove an unnecessary >> 'createDirectoryIfMissing' call. (cherry picked from commit >> 5c46e7853a09a484698064824b7bf72c5c761993) > > Sorry, it looks like that change was incorrect. I'm working on a better fix. OK, you can just revert that commit. That call was actually necessary. From johan.tibell at gmail.com Tue Jun 24 21:13:51 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 24 Jun 2014 23:13:51 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? In-Reply-To: References: <53A99C2D.2020405@scientician.net> Message-ID: Fixed the 1.20 branch. Please revert in master yourself. On Tue, Jun 24, 2014 at 11:12 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On 24 June 2014 22:35, Mikhail Glushenkov > wrote: > > Hi Johan, > > > > On 24 June 2014 21:55, Johan Tibell wrote: > >> This is what I have so far: > >> > >> [...] > >> a46df9dbfe14df0df60c8cc401221c4128ad675e Remove an unnecessary > >> 'createDirectoryIfMissing' call. (cherry picked from commit > >> 5c46e7853a09a484698064824b7bf72c5c761993) > > > > Sorry, it looks like that change was incorrect. I'm working on a better > fix. > > OK, you can just revert that commit. That call was actually necessary. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue Jun 24 21:54:08 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 24 Jun 2014 23:54:08 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? In-Reply-To: References: <53A99C2D.2020405@scientician.net> Message-ID: Hi, On 24 June 2014 23:13, Johan Tibell wrote: > Fixed the 1.20 branch. Please revert in master yourself. Already done. From johan.tibell at gmail.com Thu Jun 26 07:25:42 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 09:25:42 +0200 Subject: Any more bug fixes for the next cabal-install 1.20 release? In-Reply-To: References: <53A99C2D.2020405@scientician.net> Message-ID: I've released cabal-install-1.20.0.3. On Tue, Jun 24, 2014 at 11:54 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On 24 June 2014 23:13, Johan Tibell wrote: > > Fixed the 1.20 branch. Please revert in master yourself. > > Already done. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita at karetnikov.org Fri Jun 27 14:57:56 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Fri, 27 Jun 2014 18:57:56 +0400 Subject: Proposal: cabal-install: verify OpenPGP signatures In-Reply-To: <87zjhh349d.fsf@karetnikov.org> (Nikita Karetnikov's message of "Fri, 13 Jun 2014 06:57:50 +0400") References: <87eh0fafsq.fsf@karetnikov.org> <1399287343.18197.190.camel@dunky.localdomain> <87iopjuq7j.fsf@karetnikov.org> <87zjhh349d.fsf@karetnikov.org> Message-ID: <87oaxel7rf.fsf@karetnikov.org> I?ve just pushed a bit more code [1]. Now it?s possible to upload an ASCII-armored OpenPGP signature, which is optional, while uploading a package or a package candidate. If a signature is present, the download link will be shown in the ?Downloads? list. Questions: 1. ?backup? doesn?t work yet. Should I use symlinks and a shared directory (see ?Distribution/Server/Framework/BackupDump.hs?)? 2. Is there a need to provide ?SafeCopy? instances for the types that have been changed? If so, then which ones should be instantiated? Also, I made a mistake in 328c38a. Public keys must have their own page(s) since ?name-contact? requires authorization. (I?ll fix it). Any feedback is appreciated. Note that a development version of hOpenPGP is required for now (see the comment in the cabal file). [1] https://gitorious.org/hackage-server/hackage-server/commits/openpgp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From ezyang at mit.edu Mon Jun 30 10:24:28 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 30 Jun 2014 11:24:28 +0100 Subject: InstalledPackageInfo, IPI641, IPI642 Message-ID: <1404123656-sup-1703@sabre> 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