From duncan.coutts at worc.ox.ac.uk Fri Feb 1 11:43:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 1 11:42:23 2008 Subject: patch applied (cabal): Fix haddock markup Message-ID: <20080201164309.GA27741@haskell.galois.com> Thu Jan 31 11:38:04 PST 2008 Duncan Coutts * Fix haddock markup M ./Distribution/Simple/Setup.hs -1 +1 From trac at galois.com Fri Feb 1 13:46:23 2008 From: trac at galois.com (Hackage) Date: Fri Feb 1 13:45:40 2008 Subject: [Hackage] #228: Cryptic error when a package does not exist Message-ID: <042.3bdfdea60561b0cc481cd528622d6d6c@localhost> #228: Cryptic error when a package does not exist ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ {{{ $ cabal install foo cabal: user error (Unresolved dependencies: foo -any) }}} I expect a clearer error message here. Not sure about the exact wording, maybe ?No such package available: foo? or ?No such package to fetch: foo?. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Feb 1 21:17:30 2008 From: trac at galois.com (Hackage) Date: Fri Feb 1 21:16:43 2008 Subject: [Hackage] #228: Cryptic error when a package does not exist In-Reply-To: <042.3bdfdea60561b0cc481cd528622d6d6c@localhost> References: <042.3bdfdea60561b0cc481cd528622d6d6c@localhost> Message-ID: <051.8005f8202414946d37057e755a3bde7a@localhost> #228: Cryptic error when a package does not exist ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Already fixed in development version: {{{ $ cabal install foo cabal: There is no package named foo }}} I can highly recommend upgrading to the development version. There are many improvements. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri Feb 1 21:47:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 09:35:26 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <1201790602.13130.39.camel@localhost> References: <1196338485.21580.41.camel@localhost> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> <20080104170826.GA7601@matrix.chaos.earth.li> <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> <79d7c4980801051514m106a4f47r3128b5d13a60a05@mail.gmail.com> <20080106155654.GA1616@matrix.chaos.earth.li> <79d7c4980801100625w29126a81s72148ffbe8146847@mail.gmail.com> <1201790602.13130.39.camel@localhost> Message-ID: <1201920435.13130.129.camel@localhost> On Thu, 2008-01-31 at 14:43 +0000, Duncan Coutts wrote: > On Thu, 2008-01-10 at 14:25 +0000, Alistair Bayley wrote: > > > the comment block (like cabal does) > > - don't indent code relative to comments, because Haddock doesn't like this > > Hmm, we will have to find another solution to this because the H98 unlit > spec clearly states that '>' is to be replaced with a ' ', not just > deleted. So if haddock barfs on code like: > > -- a comment > > some code So I downloaded takusen and tried this. Haddock does indeed barf. The problem is worse though because we do not know how much to indent by to fix things. a comment >some code a comment > some code These are both valid literate Haskell. If we make comments indent by one or two spaces then we break one or the other of these examples. The latter style with two spaces is more common so we should probably go with that until haddock can be fixed. I'm cc'ing David for his opinion on the matter. Duncan From trac at galois.com Sat Feb 2 12:04:51 2008 From: trac at galois.com (Hackage) Date: Sat Feb 2 12:04:01 2008 Subject: [Hackage] #220: detect inconsistent package dependencies In-Reply-To: <043.7ddc3c41e9638027d31fa79b93a70586@localhost> References: <043.7ddc3c41e9638027d31fa79b93a70586@localhost> Message-ID: <052.5cde39463f9bf25639dba0c3cc44a116@localhost> #220: detect inconsistent package dependencies ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): This is a serious problem, package developers have responed by hard-coding package versions which they happen to know work with ghc-6.8.2 without hitting this problem. For example [http://hackage.haskell.org/cgi-bin/hackage- scripts/package/yi-0.3 yi-0.3] specifies: {{{ build-depends: bytestring ==0.9.0.1 -- >= 0.9 && < 0.9.0.4 }}} It is clear that the real dependency is {{{>= 0.9 && < 0.9.1}}} because the API is exactly the same for the `0.9.0.x` series. However because `yi` depends on the `ghc` package, with `ghc-6.8.2` we would hit the problem that the `ghc` package is built with `bytestring-0.9.0.1`. So hard coding the `bytestring` version is a quick fix but it means of course that this package will not work with any other version of ghc and cannot take advantage of rebuilding the ghc package to use a different bytestring version. The solution is for the package manger to resolve this problem and not for packages to hard code binary dependencies, they should stick to api dependencies. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Sat Feb 2 12:47:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 12:46:59 2008 Subject: GHC's CPP and Cabal's unlit Message-ID: <1201974458.13130.148.camel@localhost> -------- Forwarded Message -------- > From: David Waern > To: Duncan Coutts > Subject: Re: GHC's CPP and Cabal's unlit > Date: Sat, 2 Feb 2008 16:43:10 +0100 > > 2008/2/2, Duncan Coutts : > > > > On Thu, 2008-01-31 at 14:43 +0000, Duncan Coutts wrote: > > > On Thu, 2008-01-10 at 14:25 +0000, Alistair Bayley wrote: > > > > > > > the comment block (like cabal does) > > > > - don't indent code relative to comments, because Haddock doesn't like this > > > > > > Hmm, we will have to find another solution to this because the H98 unlit > > > spec clearly states that '>' is to be replaced with a ' ', not just > > > deleted. So if haddock barfs on code like: > > > > > > -- a comment > > > > > > some code > > > > So I downloaded takusen and tried this. Haddock does indeed barf. The > > problem is worse though because we do not know how much to indent by to > > fix things. > > I just checked with Haddock 2 and it also doesn't accept > "mis-indented" comments. Fixing this might be possible but it would > need modifications to the GHC parser. It might be better to look at > the indentation level of the code, and use that for the comments. > > David From duncan.coutts at worc.ox.ac.uk Sat Feb 2 14:16:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 14:16:00 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <1201920435.13130.129.camel@localhost> References: <1196338485.21580.41.camel@localhost> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> <20080104170826.GA7601@matrix.chaos.earth.li> <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> <79d7c4980801051514m106a4f47r3128b5d13a60a05@mail.gmail.com> <20080106155654.GA1616@matrix.chaos.earth.li> <79d7c4980801100625w29126a81s72148ffbe8146847@mail.gmail.com> <1201790602.13130.39.camel@localhost> <1201920435.13130.129.camel@localhost> Message-ID: <1201979808.13130.163.camel@localhost> On Sat, 2008-02-02 at 02:47 +0000, Duncan Coutts wrote: > So I downloaded takusen and tried this. Haddock does indeed barf. The > problem is worse though because we do not know how much to indent by to > fix things. > > I'm cc'ing David for his opinion on the matter. So the problem is actually quite tricky. If we follow the unlit spec then we must replace '>' by ' '. It is tempting to replace it by "" but that is not enough, we would have to replace "> " by "" too and that is definitely wrong because it would break code like this: >topLevel = ... > where ... We'd end up breaking this code by unliting it to: topLevel = ... where ... So I think we really have to follow the unlit spec. We are free to play with the indenting of comments. We can assume that most bird track style code uses "> " and most \being{code} style uses no indenting at all. So that makes things tricky, we would have to indent comments by two spaces before/after/near bird track code, and by none before/after/near latex style code. That seems possible if a bit unpleasant. Any better ideas? Duncan From duncan.coutts at worc.ox.ac.uk Sat Feb 2 23:28:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 23:27:43 2008 Subject: patch applied (cabal): Tweak the ghc-options: -O -O2 messages again Message-ID: <20080203042834.GA25219@haskell.galois.com> Fri Feb 1 03:31:21 PST 2008 Duncan Coutts * Tweak the ghc-options: -O -O2 messages again M ./Distribution/PackageDescription/QA.hs -4 +4 From duncan.coutts at worc.ox.ac.uk Sat Feb 2 23:28:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 23:27:44 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock Message-ID: <20080203042835.GA25241@haskell.galois.com> Sat Feb 2 20:23:08 PST 2008 Duncan Coutts * Fudge comment indentation in unliting to work with haddock The rule is, if we see any bird track style code then we will indent all comments by two spaces so that it should line up with the code. Otherwise we use no indentation so that it'll work with latex style literate files. This makes it work for takusen (once you change the '.' lines to be blank). M ./Distribution/Simple/PreProcess/Unlit.hs -23 +56 From trac at galois.com Sun Feb 3 06:30:05 2008 From: trac at galois.com (Hackage) Date: Sun Feb 3 06:29:14 2008 Subject: [Hackage] #229: Build C sources using the system's C compiler directly Message-ID: <042.c92d605aa9d60c8a6419db751bf0a4ed@localhost> #229: Build C sources using the system's C compiler directly ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Currently Cabal builds C sources by going via ghc. On some platforms this introduces some limitations (Windows especially, I think). See this conversation for an example where it would be useful: http://www .mail-archive.com/haskell-cafe@haskell.org/msg37179.html -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sun Feb 3 07:41:09 2008 From: trac at galois.com (Hackage) Date: Sun Feb 3 07:40:18 2008 Subject: [Hackage] #229: Build C sources using the system's C compiler directly In-Reply-To: <042.c92d605aa9d60c8a6419db751bf0a4ed@localhost> References: <042.c92d605aa9d60c8a6419db751bf0a4ed@localhost> Message-ID: <051.6ca879ead898ccb19137fa1108cba2b0@localhost> #229: Build C sources using the system's C compiler directly ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by guest): * cc: fmartini@gmail.com (added) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 4 12:42:57 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 12:42:03 2008 Subject: [Hackage] #230: setup haddock ignores LANGUAGE CPP pragma Message-ID: <056.45d15ff8c2e034deee028d0000361418@localhost> #230: setup haddock ignores LANGUAGE CPP pragma ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- `setup haddock` preprocesses sources with cpp if `CPP` is included in the `extensions` field, but not if a source file starts with {{{ {-# LANGUAGE CPP #-} }}} This is confusing, because that works with `setup build`. -- Ticket URL: Hackage Hackage: Cabal and related projects From igloo at earth.li Mon Feb 4 15:05:38 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Feb 4 15:04:45 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock In-Reply-To: <20080203042835.GA25241@haskell.galois.com> References: <20080203042835.GA25241@haskell.galois.com> Message-ID: <20080204200537.GA12620@matrix.chaos.earth.li> On Sat, Feb 02, 2008 at 08:28:35PM -0800, Duncan Coutts wrote: > Sat Feb 2 20:23:08 PST 2008 Duncan Coutts > * Fudge comment indentation in unliting to work with haddock > The rule is, if we see any bird track style code then we will indent all > comments by two spaces so that it should line up with the code. Otherwise > we use no indentation so that it'll work with latex style literate files. > This makes it work for takusen (once you change the '.' lines to be blank). I haven't been following exactly what's been going on with this, but this sounds very wrong to me. Is this problem caused by using invisible spaces for comment continuation, or did using '.' have the same problem? Thanks Ian From alistair at abayley.org Mon Feb 4 16:01:05 2008 From: alistair at abayley.org (Alistair Bayley) Date: Mon Feb 4 16:00:09 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock In-Reply-To: <20080204200537.GA12620@matrix.chaos.earth.li> References: <20080203042835.GA25241@haskell.galois.com> <20080204200537.GA12620@matrix.chaos.earth.li> Message-ID: <79d7c4980802041301k75ad087et2730cd8516d28ca9@mail.gmail.com> On 04/02/2008, Ian Lynagh wrote: > On Sat, Feb 02, 2008 at 08:28:35PM -0800, Duncan Coutts wrote: > > Sat Feb 2 20:23:08 PST 2008 Duncan Coutts > > * Fudge comment indentation in unliting to work with haddock > > The rule is, if we see any bird track style code then we will indent all > > comments by two spaces so that it should line up with the code. Otherwise > > we use no indentation so that it'll work with latex style literate files. > > This makes it work for takusen (once you change the '.' lines to be blank). > > I haven't been following exactly what's been going on with this, but > this sounds very wrong to me. Is this problem caused by using invisible > spaces for comment continuation, or did using '.' have the same problem? The problem is that Haddock expects comments to be indented to the same level as the code. If not then it gives a parse error. My solution was to not indent the birdtrack code, but Duncan pointed out that this is not consistent with the H98 spec, and also can break some code. So now we indent comments by two spaces instead. Obviously won't work for code that's indented with ">" rather than "> ", so you can't Haddock comment such code, but at least it won't break existing code. Alistair From igloo at earth.li Mon Feb 4 16:37:02 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Feb 4 16:36:06 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock In-Reply-To: <79d7c4980802041301k75ad087et2730cd8516d28ca9@mail.gmail.com> References: <20080203042835.GA25241@haskell.galois.com> <20080204200537.GA12620@matrix.chaos.earth.li> <79d7c4980802041301k75ad087et2730cd8516d28ca9@mail.gmail.com> Message-ID: <20080204213702.GA15428@matrix.chaos.earth.li> On Mon, Feb 04, 2008 at 09:01:05PM +0000, Alistair Bayley wrote: > On 04/02/2008, Ian Lynagh wrote: > > On Sat, Feb 02, 2008 at 08:28:35PM -0800, Duncan Coutts wrote: > > > Sat Feb 2 20:23:08 PST 2008 Duncan Coutts > > > * Fudge comment indentation in unliting to work with haddock > > > The rule is, if we see any bird track style code then we will indent all > > > comments by two spaces so that it should line up with the code. Otherwise > > > we use no indentation so that it'll work with latex style literate files. > > > This makes it work for takusen (once you change the '.' lines to be blank). > > > > I haven't been following exactly what's been going on with this, but > > this sounds very wrong to me. Is this problem caused by using invisible > > spaces for comment continuation, or did using '.' have the same problem? > > The problem is that Haddock expects comments to be indented to the > same level as the code. Ah, I see. A more-correct thing to do might be to indent to the same depth as the next token? That would have the additional advantage of being able to document nested functions. > code. So now we indent comments by two spaces instead. Obviously won't > work for code that's indented with ">" rather than "> ", so you can't > Haddock comment such code Not with literate comments, but you can if you use Haskell comments on birdtrack lines, presumably. In fact, I hadn't appreciated that non-Haskell comments would end up being picked up by haddock. Thanks Ian From duncan.coutts at worc.ox.ac.uk Mon Feb 4 17:18:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 4 17:17:43 2008 Subject: patch applied (cabal): Rewrite the Makefile and build the user-guide using xsltproc like ghc does Message-ID: <20080204221838.GA17321@haskell.galois.com> Mon Feb 4 09:26:34 PST 2008 Duncan Coutts * Rewrite the Makefile and build the user-guide using xsltproc like ghc does M ./Makefile -148 +83 A ./doc/fptools.css From duncan.coutts at worc.ox.ac.uk Mon Feb 4 17:18:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 4 17:17:43 2008 Subject: patch applied (cabal): Split Distribution.PackageDescription into three other modules Message-ID: <20080204221840.GA17343@haskell.galois.com> Mon Feb 4 13:33:06 PST 2008 Duncan Coutts * Split Distribution.PackageDescription into three other modules New D.PackageDescription.Types with the types and simple utils New D.PackageDescription.Parse module for parsing and printing functions. The sanity check code is moved into the existing QA module. The public api of Distribution.PackageDescription remains the same. M ./Cabal.cabal +2 M ./Distribution/PackageDescription.hs -1078 +30 A ./Distribution/PackageDescription/Parse.hs M ./Distribution/PackageDescription/QA.hs -4 +111 A ./Distribution/PackageDescription/Types.hs From duncan.coutts at worc.ox.ac.uk Mon Feb 4 17:18:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 4 17:17:45 2008 Subject: patch applied (cabal): Move PackageDescription unit tests into a dedicated module Message-ID: <20080204221841.GA17360@haskell.galois.com> Mon Feb 4 14:10:28 PST 2008 Duncan Coutts * Move PackageDescription unit tests into a dedicated module and make the unit test module build again. The PackageDescription module no longer needs CPP. M ./Distribution/PackageDescription.hs -372 M ./Makefile -5 +5 M ./tests/ModuleTest.hs -42 +19 A ./tests/PackageDescriptionTests.hs From duncan.coutts at worc.ox.ac.uk Mon Feb 4 18:53:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 4 18:52:33 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock In-Reply-To: <20080204213702.GA15428@matrix.chaos.earth.li> References: <20080203042835.GA25241@haskell.galois.com> <20080204200537.GA12620@matrix.chaos.earth.li> <79d7c4980802041301k75ad087et2730cd8516d28ca9@mail.gmail.com> <20080204213702.GA15428@matrix.chaos.earth.li> Message-ID: <1202169209.13130.255.camel@localhost> On Mon, 2008-02-04 at 21:37 +0000, Ian Lynagh wrote: > Ah, I see. > > A more-correct thing to do might be to indent to the same depth as the > next token? That would have the additional advantage of being able to > document nested functions. True. I'm happy to see a patch like that. One way to do it might be to groupBy the line kind. By walking over those blocks you'd might have enough lookahead to see what the indent level should be. > > code. So now we indent comments by two spaces instead. Obviously won't > > work for code that's indented with ">" rather than "> ", so you can't > > Haddock comment such code > > Not with literate comments, but you can if you use Haskell comments on > birdtrack lines, presumably. Sure, that's always worked because it gets unlited. > In fact, I hadn't appreciated that non-Haskell comments would end up > being picked up by haddock. That's what this whole thing is about, allowing haddock markup in the comment sections of .lhs files. eg: http://darcs.haskell.org/takusen/Database/Enumerator.lhs Duncan From trac at galois.com Mon Feb 4 18:56:53 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 18:55:56 2008 Subject: [Hackage] #230: setup haddock ignores LANGUAGE CPP pragma In-Reply-To: <056.45d15ff8c2e034deee028d0000361418@localhost> References: <056.45d15ff8c2e034deee028d0000361418@localhost> Message-ID: <065.b4cf3ef60942936945964b79a4af37df@localhost> #230: setup haddock ignores LANGUAGE CPP pragma ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-2.0 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------------+----------------------------------------- Changes (by duncan): * milestone: => Cabal-2.0 Comment: Of course that's because it is GHC that interprets the `{-# LANGUAGE CPP #-}` pragma and not Cabal. Long term I think Cabal should notice `LANGUAGE` pragmas. It'd allow it to check that all extensions are declared in the `.cabal` file and it'd allow Cabal to do the cpping itself rather than using ghc's cpp. I'm assigning it to milestone 2.0 because it should be easy enough if we're already reading .hs files to do module chasing. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 4 19:19:08 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 19:18:12 2008 Subject: [Hackage] #230: setup haddock ignores LANGUAGE CPP pragma In-Reply-To: <056.45d15ff8c2e034deee028d0000361418@localhost> References: <056.45d15ff8c2e034deee028d0000361418@localhost> Message-ID: <065.54a8e3f699006de6ffc8feace49535f9@localhost> #230: setup haddock ignores LANGUAGE CPP pragma ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-2.0 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------------+----------------------------------------- Comment (by ross@soi.city.ac.uk): `Distribution.Simple.Hugs.getOptionsFromSource` may be useful. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 4 20:15:22 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 20:14:26 2008 Subject: [Hackage] #231: "buildable: False" should fail the current configuration Message-ID: <043.a071118351c7cca17e2f58787dbe11fc@localhost> #231: "buildable: False" should fail the current configuration ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Currently resolving configurations does not take account of the `buildable` field. It should act rather like `build-depends: non- existant`, though with a different error message. If possible the error message should relate to the guard condition expression (the conjunction if there are several nested guards). At the moment it is not considered at all and we don't notice that the package cannot be built until the build step, rather than the configure step. One problem is that it's not clear if `buildable: False` is always fatal. People sometimes do that for test executables that are not supposed to be installed. So what should the behaviour be? The lib or only exe failing to configure must be an error. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 4 20:20:33 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 20:19:36 2008 Subject: [Hackage] #232: implement extended syntax for package version ranges Message-ID: <043.9dc7ddafd560f5be87400ac3e0433964@localhost> #232: implement extended syntax for package version ranges ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Revised proposal: http://www.haskell.org/pipermail/cabal- devel/2008-January/001786.html Reproduced here: In order to make it easy for package package authors to describe correct and robust dependencies we (Duncan Coutts and I) propose the following syntactical extension to version range specifications in package files. == Wildcards == {{{ ~ 1.2.* ~~> >= 1.2 && < 1.3 }}} in general {{{ ~ x.y.* ~~> >= x.y && < x.(y+1) }}} The "~" operator should be read as "in the range of". Another option would have been "-", but this is used to specify exact versions in other parts of the Cabal infrastructure , e.g., "cabal install xmonad-0.5". This is the most common specification of package dependencies. The assumption is that changes in the last version number indicate only backwards compatible changes, as is suggested in the new package versioning policy [1]. The use of "*" matches the common usage as a wildcard character. == Upward Ranges == {{{ ~ 1.2.1+ ~~> >= 1.2.1 && < 1.3 }}} in general {{{ ~ x.y.z+ ~~> >= x.y.z && < x.(y+1) }}} The idea here is that sometimes packages need a certain patch level or, as in Cabal's case, a stable release and possible further bugfixes. In those cases the wildcard notation is too liberal, however the explicit range description would be too noisy (and possibly error prone). (Also, using "+" instead of "*" serves as better visual distinction.) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 4 20:22:03 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 20:21:06 2008 Subject: [Hackage] #209: Implement "package()" configurations predicate In-Reply-To: <043.8761cb32d23121f07ba068aea57ebda7@localhost> References: <043.8761cb32d23121f07ba068aea57ebda7@localhost> Message-ID: <052.98287eb743628ce4cc8cb4d650bab24f@localhost> #209: Implement "package()" configurations predicate ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * owner: => nominolo -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 4 20:22:16 2008 From: trac at galois.com (Hackage) Date: Mon Feb 4 20:21:17 2008 Subject: [Hackage] #231: "buildable: False" should fail the current configuration In-Reply-To: <043.a071118351c7cca17e2f58787dbe11fc@localhost> References: <043.a071118351c7cca17e2f58787dbe11fc@localhost> Message-ID: <052.c838a2023e29b64a5dc2edddfbe4b7cf@localhost> #231: "buildable: False" should fail the current configuration ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * owner: => nominolo -- Ticket URL: Hackage Hackage: Cabal and related projects From Malcolm.Wallace at cs.york.ac.uk Tue Feb 5 07:33:37 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Feb 5 07:32:39 2008 Subject: patch applied (cabal): nhc98 does not have System.Posix.Internals Message-ID: <20080205123337.GA5796@haskell.galois.com> Tue Feb 5 04:05:16 PST 2008 Malcolm.Wallace@cs.york.ac.uk * nhc98 does not have System.Posix.Internals M ./Distribution/Compat/TempFile.hs +5 From duncan.coutts at worc.ox.ac.uk Tue Feb 5 14:58:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 5 14:58:00 2008 Subject: patch applied (cabal): Move cabalVersion, setupMessage and a bunch of paths into differnt modules Message-ID: <20080205195859.GA15260@haskell.galois.com> Tue Feb 5 11:02:30 PST 2008 Duncan Coutts * Move cabalVersion, setupMessage and a bunch of paths into differnt modules New Distribution.Simple.BuildPaths module similar to the .InstallDirs module to hold all the paths and filenames used during a build. It's currently somewhat of a miscellaneous collection. M ./Cabal.cabal +1 M ./Distribution/Make.hs -1 +1 M ./Distribution/Simple.hs -4 +5 M ./Distribution/Simple/Build.hs -5 +5 A ./Distribution/Simple/BuildPaths.hs M ./Distribution/Simple/Configure.hs -3 +5 M ./Distribution/Simple/GHC.hs -3 +4 M ./Distribution/Simple/Haddock.hs -5 +6 M ./Distribution/Simple/Hugs.hs -2 +5 M ./Distribution/Simple/Install.hs -2 +3 M ./Distribution/Simple/JHC.hs -3 +4 M ./Distribution/Simple/NHC.hs -3 +5 M ./Distribution/Simple/PreProcess.hs -5 +5 M ./Distribution/Simple/Register.hs -7 +8 M ./Distribution/Simple/SrcDist.hs -3 +3 M ./Distribution/Simple/Utils.hs -1 +14 From duncan.coutts at worc.ox.ac.uk Tue Feb 5 14:59:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 5 14:58:01 2008 Subject: patch applied (cabal): Finish moving build path functions Message-ID: <20080205195901.GA15282@haskell.galois.com> Tue Feb 5 11:24:39 PST 2008 Duncan Coutts * Finish moving build path functions M ./Distribution/Simple/Hugs.hs -1 +1 M ./Distribution/Simple/LocalBuildInfo.hs -26 M ./Distribution/Simple/SetupWrapper.hs -1 +1 M ./Distribution/Simple/Utils.hs -58 +3 From duncan.coutts at worc.ox.ac.uk Tue Feb 5 14:59:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 5 14:58:02 2008 Subject: patch applied (cabal): Rearrange PackageDescription some more Message-ID: <20080205195902.GA15298@haskell.galois.com> Tue Feb 5 11:43:41 PST 2008 Duncan Coutts * Rearrange PackageDescription some more Previously we moved the types into Distribution.PackageDescription.Types. Now all the remaining utils have been removed from D.PackageDescription we can move D.PackageDescription.Types back to D.PackageDescription. Also move D.Configuration to be D.PackageDescription.Configuration and move the types used for GenericPackageDescription into D.PackageDescription and move the functions that convert GenericPackageDescription -> PackageDescription into the D.PackageDescription.Configuration module. ./Distribution/Configuration.hs -> ./Distribution/PackageDescription/Configuration.hs ./Distribution/PackageDescription/Types.hs -> ./Distribution/PackageDescription.hs R ./Distribution/PackageDescription.hs M ./Distribution/PackageDescription/Configuration.hs -85 +155 M ./Distribution/PackageDescription/Parse.hs -3 +2 From duncan.coutts at worc.ox.ac.uk Tue Feb 5 14:59:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 5 14:58:06 2008 Subject: patch applied (cabal): Finish moving GenericPackageDescription into PackageDescription module Message-ID: <20080205195904.GA15314@haskell.galois.com> Tue Feb 5 11:50:51 PST 2008 Duncan Coutts * Finish moving GenericPackageDescription into PackageDescription module and fix up remaing imports. hcOptions is back in the PackageDescription module but with a different type. GenericPackageDescription now derives Show as having the separate pretty printer is inconvenient and in any case it is incomplete. M ./Distribution/PackageDescription.hs -15 +119 M ./Distribution/PackageDescription/QA.hs -14 +2 M ./Distribution/Simple.hs +7 M ./Distribution/Simple/Configure.hs -3 +6 M ./Distribution/Simple/GHC.hs -1 +1 M ./Distribution/Simple/Haddock.hs -2 +6 M ./Distribution/Simple/Hugs.hs -7 +5 M ./Distribution/Simple/JHC.hs -1 +1 M ./Distribution/Simple/NHC.hs -2 +2 M ./Distribution/Simple/SetupWrapper.hs -5 +3 From duncan.coutts at worc.ox.ac.uk Tue Feb 5 14:59:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 5 14:58:06 2008 Subject: patch applied (cabal): Fix up Cabal.cabal after module renaming Message-ID: <20080205195906.GA15330@haskell.galois.com> Tue Feb 5 11:53:16 PST 2008 Duncan Coutts * Fix up Cabal.cabal after module renaming M ./Cabal.cabal -2 +1 From duncan.coutts at worc.ox.ac.uk Wed Feb 6 09:28:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 6 09:27:19 2008 Subject: patch applied (cabal): Replace moduleToFilePath with findFileWithExtension Message-ID: <20080206142819.GA32676@haskell.galois.com> Tue Feb 5 17:45:54 PST 2008 Duncan Coutts * Replace moduleToFilePath with findFileWithExtension moduleToFilePath encouraged bad error handling and becuase it was specific to module names it made it hard to treat modules and main.hs files uniformly. This is one step towards using the same code paths for modules and main.hs files so that main.hs files always work properly with pre-processors etc. M ./Distribution/Simple/GHC.hs -8 +16 M ./Distribution/Simple/Haddock.hs -6 +9 M ./Distribution/Simple/Hugs.hs -8 +9 M ./Distribution/Simple/NHC.hs -4 +6 M ./Distribution/Simple/PreProcess.hs -10 +12 M ./Distribution/Simple/SrcDist.hs -1 +1 M ./Distribution/Simple/Utils.hs -44 +1 From duncan.coutts at worc.ox.ac.uk Wed Feb 6 09:28:22 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 6 09:27:21 2008 Subject: patch applied (cabal): fix --package-conf= is correct when creating register.sh Message-ID: <20080206142822.GA32699@haskell.galois.com> Tue Feb 5 13:02:21 PST 2008 marco-oweber@gmx.de * fix --package-conf= is correct when creating register.sh M ./Distribution/Simple/Register.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Wed Feb 6 09:28:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 6 09:27:23 2008 Subject: patch applied (cabal): Fix --package-conf= for unregister too Message-ID: <20080206142824.GA32715@haskell.galois.com> Wed Feb 6 06:20:23 PST 2008 Duncan Coutts * Fix --package-conf= for unregister too M ./Distribution/Simple/Register.hs -1 +1 From pgavin at gmail.com Thu Feb 7 12:10:59 2008 From: pgavin at gmail.com (Peter Gavin) Date: Thu Feb 7 12:09:57 2008 Subject: ranlib Message-ID: <47AB3BA3.5000701@gmail.com> The makefiles generated by cabal don't run ranlib on libraries. This is a big problem since GHC uses the makefile generator :) I've attached a patch that fixes things. I tested it by replacing the Cabal tree in a ghc snapshot; everything seems to build ok. Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-devel-ranlib.dpatch.bz2 Type: application/octet-stream Size: 16185 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080207/a6f5ab22/cabal-devel-ranlib.dpatch-0001.obj From duncan.coutts at worc.ox.ac.uk Fri Feb 8 07:26:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 8 07:25:21 2008 Subject: ranlib In-Reply-To: <47AB3BA3.5000701@gmail.com> References: <47AB3BA3.5000701@gmail.com> Message-ID: <1202473578.21103.98.camel@localhost> On Thu, 2008-02-07 at 12:10 -0500, Peter Gavin wrote: > The makefiles generated by cabal don't run ranlib on libraries. This is > a big problem since GHC uses the makefile generator :) > > I've attached a patch that fixes things. I tested it by replacing the > Cabal tree in a ghc snapshot; everything seems to build ok. Could you be more specific? As I understand it, building GHC does indeed work on most platforms currently. So what are the symptoms exactly and on what platform? Duncan From pgavin at gmail.com Fri Feb 8 08:31:15 2008 From: pgavin at gmail.com (Peter Gavin) Date: Fri Feb 8 08:30:08 2008 Subject: ranlib In-Reply-To: <1202473578.21103.98.camel@localhost> References: <47AB3BA3.5000701@gmail.com> <1202473578.21103.98.camel@localhost> Message-ID: <47AC59A3.1080904@gmail.com> Duncan Coutts wrote: > On Thu, 2008-02-07 at 12:10 -0500, Peter Gavin wrote: >> The makefiles generated by cabal don't run ranlib on libraries. This is >> a big problem since GHC uses the makefile generator :) >> >> I've attached a patch that fixes things. I tested it by replacing the >> Cabal tree in a ghc snapshot; everything seems to build ok. > > Could you be more specific? As I understand it, building GHC does indeed > work on most platforms currently. So what are the symptoms exactly and > on what platform? Sorry, I should've given more information. I'm trying to build under Mac OSX 10.5, which requires that ranlib is run on vanilla libraries (unlike e.g. Linux). When cabal builds a library on its own it ends up running ranlib, but the makefile generated by ./setup makefile does *not* run ranlib. The GHC build uses the cabal-generated makefile, so the build fails. (The GHC version I'm using is the darcs tree at http://darcs.haskell.org/ghc-6.8/.) Pete From pgavin at gmail.com Fri Feb 8 09:17:43 2008 From: pgavin at gmail.com (Peter Gavin) Date: Fri Feb 8 09:16:36 2008 Subject: ranlib In-Reply-To: <47AC6318.6070803@dfki.de> References: <47AB3BA3.5000701@gmail.com> <1202473578.21103.98.camel@localhost> <47AC59A3.1080904@gmail.com> <47AC6318.6070803@dfki.de> Message-ID: <47AC6487.1030102@gmail.com> Christian Maeder wrote: > Peter Gavin wrote: >> Sorry, I should've given more information. I'm trying to build under >> Mac OSX 10.5, which requires that ranlib is run on vanilla libraries > > I think, running ranlib (after moving .ar files) is only needed on PPC > macs (not on i386). Am I right? (I only ask out of curiosity) > Well, actually, both archs need it. I never owned any of the PPC macs, actually, just an intel mac. In any case, I don't remember having this problem on 10.4, but I had a different version of MacPorts running then also. The 10.5 version of MacPorts' GHC won't build on Leopard, either. Hopefully this should fix that. Pete From duncan.coutts at worc.ox.ac.uk Fri Feb 8 15:41:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 8 15:40:23 2008 Subject: patch applied (cabal): Fix a bug where the destdir prefix got included in the prog prefix and suffix Message-ID: <20080208204130.GA28950@haskell.galois.com> Fri Feb 8 11:26:13 PST 2008 Duncan Coutts * Fix a bug where the destdir prefix got included in the prog prefix and suffix Previously all members of InstallDirs were paths so it was safe to prefix them all with the destdir, but now we've also got these two non-paths, so we have to not apply the prefix to them. Perhaps the program prefix and suffix should just be PathTemplates on their own and not part of InstallDirs. Reported by MarcWeber while hacking on Haskell packages for Nix. M ./Distribution/Simple/InstallDirs.hs -1 +7 From phigley at gmail.com Sat Feb 9 16:50:52 2008 From: phigley at gmail.com (Peter Higley) Date: Sat Feb 9 16:49:40 2008 Subject: patch applied (cabal): Fix a bug where the destdir prefix got included in the prog prefix and suffix In-Reply-To: <20080208204130.GA28950@haskell.galois.com> References: <20080208204130.GA28950@haskell.galois.com> Message-ID: <6a7a1ebb0802091350y30163ad8g2ce473feccfd9c68@mail.gmail.com> I didn't like putting prefix and suffix in InstallDirs either. I was just following the path of least resistance! I'll look into moving them out of there. Peter On Feb 8, 2008 12:41 PM, Duncan Coutts wrote: > Fri Feb 8 11:26:13 PST 2008 Duncan Coutts > * Fix a bug where the destdir prefix got included in the prog prefix and > suffix > Previously all members of InstallDirs were paths so it was safe to prefix > them all with the destdir, but now we've also got these two non-paths, so > we have to not apply the prefix to them. Perhaps the program prefix and > suffix > should just be PathTemplates on their own and not part of InstallDirs. > Reported by MarcWeber while hacking on Haskell packages for Nix. > > M ./Distribution/Simple/InstallDirs.hs -1 +7 > > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20080209/f317bc32/attachment.htm From phigley at gmail.com Sun Feb 10 03:25:34 2008 From: phigley at gmail.com (Peter Higley) Date: Sun Feb 10 03:24:21 2008 Subject: Patch to get cabal-install compiling Message-ID: <6a7a1ebb0802100025v3dc92959x7722d6af936fd0a6@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: FixedImports.dpatch Type: application/octet-stream Size: 11113 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080210/7de4e877/FixedImports-0001.obj From duncan.coutts at worc.ox.ac.uk Sun Feb 10 12:27:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 12:26:15 2008 Subject: patch applied (cabal-install): Rename ResolvedPackage to ResolvedDependency Message-ID: <20080210172728.GA15755@haskell.galois.com> Sun Jan 20 06:47:54 PST 2008 Duncan Coutts * Rename ResolvedPackage to ResolvedDependency M ./Hackage/Dependency.hs -11 +11 M ./Hackage/Info.hs -8 +8 M ./Hackage/Install.hs +1 M ./Hackage/Types.hs -8 +8 From duncan.coutts at worc.ox.ac.uk Sun Feb 10 12:27:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 12:26:16 2008 Subject: patch applied (cabal-install): Fixed imports to correspond to the latest arrangement of Distribution.PackageDescription. Message-ID: <20080210172731.GA15777@haskell.galois.com> Sat Feb 9 23:07:30 PST 2008 phigley@gmail.com * Fixed imports to correspond to the latest arrangement of Distribution.PackageDescription. M ./Hackage/Config.hs -1 +1 M ./Hackage/Dependency.hs -2 +3 M ./Hackage/Install.hs -1 +1 M ./Hackage/RepoIndex.hs -1 +1 M ./Main.hs -2 +1 From duncan.coutts at worc.ox.ac.uk Sun Feb 10 20:56:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 20:55:08 2008 Subject: patch applied (cabal): Unify sanity and other checks and separate IO checks Message-ID: <20080211015624.GA27911@haskell.galois.com> Sun Feb 10 16:38:30 PST 2008 Duncan Coutts * Unify sanity and other checks and separate IO checks And rename from QA so we no longer pretend to assure anything :-) We now distinguish different kinds of tests with a PackageCheck type so the caller gets to decide which kinds of checks are relevant to the context. This PackageCheck type should be extensible if we want to add more kinds or more info besides a brief human readable explanation. ./Distribution/PackageDescription/QA.hs -> ./Distribution/PackageDescription/Check.hs M ./Cabal.cabal -1 +1 M ./Distribution/PackageDescription/Check.hs -186 +199 M ./Distribution/Simple/Configure.hs -20 +14 M ./Distribution/Simple/SrcDist.hs -14 +21 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211003830-adfee-57699c5ec277e6a5b2be3890dc4624bbaf3663f0.gz From duncan.coutts at worc.ox.ac.uk Sun Feb 10 20:56:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 20:55:09 2008 Subject: patch applied (cabal): Note the form of jhc --version output Message-ID: <20080211015626.GA27934@haskell.galois.com> Sun Feb 10 16:44:23 PST 2008 Duncan Coutts * Note the form of jhc --version output M ./Distribution/Simple/Program.hs +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211004423-adfee-f96fafa0debb16ba850d306ca659ad9656857e25.gz From duncan.coutts at worc.ox.ac.uk Sun Feb 10 20:56:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 20:55:10 2008 Subject: patch applied (cabal): Move ppField(s) utils into ParseUtils module Message-ID: <20080211015627.GA27951@haskell.galois.com> Sun Feb 10 16:46:05 PST 2008 Duncan Coutts * Move ppField(s) utils into ParseUtils module and stop exporting various internal stuff from PackageDescription.Parse which was previously being used by the sanity checking code. M ./Distribution/InstalledPackageInfo.hs -10 +3 M ./Distribution/PackageDescription/Parse.hs -33 +5 M ./Distribution/ParseUtils.hs -2 +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211004605-adfee-a6ce869368190a30ee842ec8dd581b320dce2d43.gz From duncan.coutts at worc.ox.ac.uk Sun Feb 10 20:56:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 20:55:13 2008 Subject: patch applied (cabal): Bump version to 1.3.4 Message-ID: <20080211015629.GA27969@haskell.galois.com> Sun Feb 10 17:20:54 PST 2008 Duncan Coutts * Bump version to 1.3.4 Various recent api changes M ./Cabal.cabal -2 +2 M ./Makefile -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211012054-adfee-4d2168cc9e3d65cc6a7956cdb5ba1dae98f02691.gz From duncan.coutts at worc.ox.ac.uk Sun Feb 10 21:11:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 10 21:09:57 2008 Subject: patch applied (cabal-install): Bump version and required Cabal version Message-ID: <20080211021115.GA28431@haskell.galois.com> Sun Feb 10 17:21:51 PST 2008 Duncan Coutts * Bump version and required Cabal version Due to recent Cabal api changes M ./cabal-install.cabal -2 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080211012151-adfee-c4a8561955b1613b53f89d18a907370b8e38b70d.gz From trac at galois.com Mon Feb 11 05:45:23 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 05:44:07 2008 Subject: [Hackage] #233: case of Boolean values "true" and "false" should not matter Message-ID: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> #233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The Cabal documentation does not specify the formatting of Boolean values "true" and "false". Hence it seems reasonable to assume that case does not matter, as it does not matter for any field name. However, the ghc- based implementation of Cabal seems to only accept init-caps "True" and "False". -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 06:28:17 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 06:26:58 2008 Subject: [Hackage] #233: case of Boolean values "true" and "false" should not matter In-Reply-To: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> References: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> Message-ID: <051.7759a252d6381a92de6e55255b673a3b@localhost> #233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: worksforme Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by guest): * status: new => closed * resolution: => worksforme Comment: Cabal always accepted both lower-case and capitalized, but never things like "TRue" or "FaLse". It works fine in Cabal HEAD. --Thomas -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Mon Feb 11 11:50:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 11 11:48:55 2008 Subject: patch applied (cabal): Document main-is behaviour with preprocessors Message-ID: <20080211165011.GA10870@haskell.galois.com> Mon Feb 11 08:18:54 PST 2008 Duncan Coutts * Document main-is behaviour with preprocessors M ./doc/Cabal.xml -3 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211161854-adfee-46adbcdd3cbc3745c9a114121a46ead10285d512.gz From duncan.coutts at worc.ox.ac.uk Mon Feb 11 11:50:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 11 11:48:57 2008 Subject: patch applied (cabal): Add lots of new package checks Message-ID: <20080211165013.GA10893@haskell.galois.com> Mon Feb 11 08:28:31 PST 2008 Duncan Coutts * Add lots of new package checks Check that Setup.(l)hs exists. Check for ./configure file if build-type: Configure Check for duplicate modules in library and executables. Check ghc-options and cc-options for -I -l -L flags that should be elsewhere Check for lots of insane ghc-options that people have used in real packages. Check for old ghc -f flags that correspond to extensions M ./Distribution/PackageDescription/Check.hs -12 +168 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211162831-adfee-95a3d5492a7b94f3aa693b7ca02b4d0b1fca4ca8.gz From trac at galois.com Mon Feb 11 11:50:43 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 11:49:29 2008 Subject: [Hackage] #191: Hackage should check for common QA problems in ghc-options In-Reply-To: <043.1d79ebe82ae9b2113d9c0b7033be1a00@localhost> References: <043.1d79ebe82ae9b2113d9c0b7033be1a00@localhost> Message-ID: <052.1dce1dfe242b56ff8ccaea6aa0e81536@localhost> #191: Hackage should check for common QA problems in ghc-options ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.1 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Most of these implemented and a few more. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 11:50:49 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 11:49:33 2008 Subject: [Hackage] #217: Main modules in .hsc files are not included in sdist In-Reply-To: <042.f5302da82783fd9583528cc5b8ad4592@localhost> References: <042.f5302da82783fd9583528cc5b8ad4592@localhost> Message-ID: <051.89c94cd02c8dbda655abd34ce830faa4@localhost> #217: Main modules in .hsc files are not included in sdist ----------------------------+----------------------------------------------- Reporter: gwern | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: reopened => closed * resolution: => fixed Comment: Now documented too. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 12:30:14 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 12:28:55 2008 Subject: [Hackage] #233: case of Boolean values "true" and "false" should not matter In-Reply-To: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> References: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> Message-ID: <051.8de683d29205e5c2b0fb3aaf1f13ff7c@localhost> #233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: closed => reopened * resolution: worksforme => Comment: Doesn't work for me: {{{ flag foo default: false }}} gives {{{ $ cabal configure cabal: Foo.cabal:28: Parse of field 'default' failed: }}} And this makes sense given the parser being used: {{{ , simpleField "default" (text . show) parseReadS flagDefault (\val fl -> fl{ flagDefault = val }) }}} `parseReadS` just uses `read` so is case sensitive. The `buildable` field also uses `parseReadS` as a parser. I think we have the same problem for other enumerations like `build-type`, `tested-with`, `license` and `extensions` though it's not so clear in those cases if it should be case sensitive or not. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 12:58:59 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 12:57:42 2008 Subject: [Hackage] #233: case of Boolean values "true" and "false" should not matter In-Reply-To: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> References: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> Message-ID: <051.6870d807833d3c07562402334fef310c@localhost> #233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): Sorry I got that confused with parsing booleans in conditions. The attached patch should fix the issue at least for boolean fields. --Thomas -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 15:49:26 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 15:48:08 2008 Subject: [Hackage] #234: track installed files to allow uninstall Message-ID: <043.33fa68a027c1459f6e970a856b4ef84c@localhost> #234: track installed files to allow uninstall -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- `cabal-install` needs to be able to track all the files it installs so that it'll be possible to uninstall packages. The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. `cabal-install` could use that to write out a manifest file and use that later to allow uninstalling. One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 15:49:35 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 15:48:18 2008 Subject: [Hackage] #235: cabal list should also list installed packages Message-ID: <043.578e56899aefe7f9ea7d800e6eed09ef@localhost> #235: cabal list should also list installed packages ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Currently `cabal list foo` only looks at the available packages and not at the installed ones. The `cabal list` command output needs improving. It currently lists all available versions of available (but not installed) packages. That's both too much and too little info. We want to know for each matching package the installed versions and we probably do not need to know every single available version. There are already `RepoIndex` and `LocalIndex` types for doing lookups so this task is just to format the information nicely. See the `Hackage.List` module in `cabal-install`. For reference you might like to look at what other similar tools do. For example Gentoo's `esearch` utility gives us: {{{ $ esearch xmonad [ Results for search key : xmonad ] [ Applications found : 2 ] * x11-wm/xmonad Latest version available: 0.5-r1 Latest version installed: 0.5 Size of downloaded files: [no/bad digest] Homepage: http://www.xmonad.org/ Description: A lightweight X11 window manager License: BSD * x11-wm/xmonad-contrib Latest version available: 0.5-r1 Latest version installed: [ Not Installed ] Size of downloaded files: [no/bad digest] Homepage: http://www.xmonad.org/ Description: Third party extentions for xmonad License: BSD }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 15:50:48 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 15:49:34 2008 Subject: [Hackage] #106: Two new commands: list and uninstall In-Reply-To: <042.554de9a5a5b537dfc51c3e135ea8111d@localhost> References: <042.554de9a5a5b537dfc51c3e135ea8111d@localhost> Message-ID: <051.2f40c866d8d5fae4be358a5a834e0a84@localhost> #106: Two new commands: list and uninstall ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: duplicate Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * status: new => closed * resolution: => duplicate Comment: Split into two tickets of rather different difficulty #235 for the list feature and #234 for tracking installed files to allow for later uninstall. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 16:05:56 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 16:04:42 2008 Subject: [Hackage] #218: Data-files have no way of being installed conditionally In-Reply-To: <042.30d33a546fbfd9d6f249aabed33af980@localhost> References: <042.30d33a546fbfd9d6f249aabed33af980@localhost> Message-ID: <051.595dbb4538c1bdbd9f50ca4710f8283d@localhost> #218: Data-files have no way of being installed conditionally ----------------------------+----------------------------------------------- Reporter: guest | Owner: nominolo Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * owner: => nominolo Comment: Presumably this is just a matter of changing data-files to be in the BuildInfo rather than the PackageDescription and putting in code to move it from the global section for all the existing packages that specify it there. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 16:38:22 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 16:37:02 2008 Subject: [Hackage] #107: ijones suggestions for HAC07 In-Reply-To: <043.fa1e824bdfb156369ccb78f23f9c82fc@localhost> References: <043.fa1e824bdfb156369ccb78f23f9c82fc@localhost> Message-ID: <052.d94a4e88a8df0b07d3f030c4beaf39fd@localhost> #107: ijones suggestions for HAC07 --------------------------+------------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: misc | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux --------------------------+------------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 16:43:31 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 16:42:11 2008 Subject: [Hackage] #233: case of Boolean values "true" and "false" should not matter In-Reply-To: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> References: <042.27247b1f3d8cfa19dc588b37976c07f1@localhost> Message-ID: <051.6f71013db933b709ee09bc949d95c8fa@localhost> #233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: reopened => closed * resolution: => fixed Comment: Patch applied. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Mon Feb 11 16:43:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 11 16:42:17 2008 Subject: patch applied (cabal): Allow lower-case spellings for boolean fields. Message-ID: <20080211214333.GA16411@haskell.galois.com> Mon Feb 11 09:51:17 PST 2008 Thomas Schilling * Allow lower-case spellings for boolean fields. M ./Distribution/PackageDescription/Parse.hs -2 +2 M ./Distribution/ParseUtils.hs -1 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080211175117-75a80-58f42949c9d295269fc366f7bff2a4785432a6d9.gz From trac at galois.com Mon Feb 11 16:48:51 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 16:47:33 2008 Subject: [Hackage] #236: Installed package config refers to nonexisting haddock interface and html files Message-ID: <045.bb479c6583b14e7600faa1144eb6f51d@localhost> #236: Installed package config refers to nonexisting haddock interface and html files ----------------------------+----------------------------------------------- Reporter: kolmodin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Cabal generates the {{{haddock-interfaces}}} and {{{haddock-html}}} package fields even if the haddock documentation is not built nor installed. Instead of assuming haddock is used, it should add the fields iff needed upon register (install = copy + register), where enough information should be available to make a more clever installation. Example {{{ghc-pkg describe binary}}} built without haddock: {{{ name: binary version: 0.4.1 license: BSD3 copyright: maintainer: Lennart Kolmodin, Don Stewart stability: provisional homepage: http://www.cse.unsw.edu.au/~dons/binary.html package-url: description: Efficient, pure binary serialisation using lazy ByteStrings. Haskell values may be encoded to and form binary formats, written to disk as binary, or sent over the network. Serialisation speeds of over 1 G\/sec have been observed, so this library should be suitable for high performance scenarios. category: Data, Parsing author: Lennart Kolmodin exposed: True exposed-modules: Data.Binary Data.Binary.Put Data.Binary.Get Data.Binary.Builder hidden-modules: import-dirs: /usr/lib/binary-0.4.1/ghc-6.8.2 library-dirs: /usr/lib/binary-0.4.1/ghc-6.8.2 hs-libraries: HSbinary-0.4.1 extra-libraries: extra-ghci-libraries: include-dirs: includes: depends: base-3.0.1.0 bytestring-0.9.0.4 base-3.0.1.0 containers-0.1.0.1 array-0.1.0.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/share/doc/binary-0.4.1/html/binary.haddock haddock-html: /usr/share/doc/binary-0.4.1/html }}} Both {{{/usr/share/doc/binary-0.4.1/html/binary.haddock}}} and {{{/usr/share/doc/binary-0.4.1/html}}} are (rightfully) missing in the installation. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 19:41:50 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 19:40:39 2008 Subject: [Hackage] #58: allow darcs repo to be specified in cabal file In-Reply-To: <043.6583bf82ef1497f4ce27dc570194f6ee@localhost> References: <043.6583bf82ef1497f4ce27dc570194f6ee@localhost> Message-ID: <052.e30a09963293d1ec10bed43967980f0a@localhost> #58: allow darcs repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by dons): * cc: dons@galois.com (added) Comment: We need support for arbitrary repo types, beyond just git. So something like: {{{ source: http://foo.org/code.git }}} That is, an untyped url without information about what type of repo it is. '''Or''' we include type information about the source: {{{ source: http://foo.org/code.git source-type: git }}} It shouldn't be constrained to just darcs, in any case. Besides darcs, probably the most common case is google code's svn repos, in fact. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 19:46:27 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 19:45:10 2008 Subject: [Hackage] #88: Stripping In-Reply-To: <055.8a351a03965fd17ad383f63cc40bfd0d@localhost> References: <055.8a351a03965fd17ad383f63cc40bfd0d@localhost> Message-ID: <064.29e6f82ac9c6007da74b1acbcaf1f8e5@localhost> #88: Stripping ---------------------------------+------------------------------------------ Reporter: bjorn@bringert.net | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: ---------------------------------+------------------------------------------ Changes (by dons): * cc: dons@galois.com (added) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 19:48:57 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 19:47:38 2008 Subject: [Hackage] #216: need a way to specify the foreign libraries a package depends on In-Reply-To: <056.50c203ebc5dcfd75c1c54a254cb11c5b@localhost> References: <056.50c203ebc5dcfd75c1c54a254cb11c5b@localhost> Message-ID: <065.d61641be01cfcdeae38e447eae811927@localhost> #216: need a way to specify the foreign libraries a package depends on ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: major | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ----------------------------------+----------------------------------------- Changes (by dons): * cc: dons@galois.com (added) Comment: In addition, we can see the lack of checking for the existence of C libs breaking test builds on hackage, and breaking cabal-install downloads. pcre-light is a good example: no way to test pcre.h is available, without resorting to autoconf. One solution here might be to reuse/duplicate autoconf functionality to check if extra-libraries are available? -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 19:52:30 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 19:51:11 2008 Subject: [Hackage] #183: Provide "library-rank" in hackage In-Reply-To: <042.f01e142252f09b036b5a2a5f1c4cd6e9@localhost> References: <042.f01e142252f09b036b5a2a5f1c4cd6e9@localhost> Message-ID: <051.85e8d3b8e431b1cb061ab47fa6d08cc5@localhost> #183: Provide "library-rank" in hackage --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux --------------------------------+------------------------------------------- Changes (by dons): * cc: dons@galois.com (added) Comment: there's a range of quality / popularity metrics we'd like to implement. Others include: * most dependend upon * most downloaded * code coverage above a cerain percent (e.g.. 75% minimum) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 19:58:05 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 19:56:51 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages Message-ID: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- Many libraries have documentation online, other than the hackage information. We need a way to tie all the blog and online tutes to the relevant library. Support a way for authenticated users to add links to tutorials, online docs, RSS feeds and other project specific information. Example: ohloh's code metric site: http://www.ohloh.net/projects/6869?p=xmonad allows adding "Links" by registered users to the project docs, wikis etc. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Feb 11 20:21:28 2008 From: trac at galois.com (Hackage) Date: Mon Feb 11 20:20:17 2008 Subject: [Hackage] #215: Overhaul support for package's tests In-Reply-To: <043.b38effe8d2ff8e635643eacee1342b9e@localhost> References: <043.b38effe8d2ff8e635643eacee1342b9e@localhost> Message-ID: <052.317554ebb5c93ac18489d0ea10874a46@localhost> #215: Overhaul support for package's tests ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by dons): * cc: dons@galois.com (added) -- Ticket URL: Hackage Hackage: Cabal and related projects From phigley at gmail.com Mon Feb 11 23:37:02 2008 From: phigley at gmail.com (Peter Higley) Date: Mon Feb 11 23:35:42 2008 Subject: Program prefix and suffix moved out of InstallDirs Message-ID: <6a7a1ebb0802112037o25bf25d2t65d1d621240adbd1@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: StandAlonePrefixSuffix.dpatch Type: application/octet-stream Size: 55614 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080211/2c61456f/StandAlonePrefixSuffix-0001.obj From trac at galois.com Tue Feb 12 03:14:30 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 03:13:13 2008 Subject: [Hackage] #183: Provide "library-rank" in hackage In-Reply-To: <042.f01e142252f09b036b5a2a5f1c4cd6e9@localhost> References: <042.f01e142252f09b036b5a2a5f1c4cd6e9@localhost> Message-ID: <051.13086df3fcc966dc692929f10ddf2f04@localhost> #183: Provide "library-rank" in hackage --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux --------------------------------+------------------------------------------- Changes (by guest): * cc: ndmitchell@gmail.com (added) Comment: Additional ideas for metrics: * % of exported definitions with haddock comments (should be 100%) * Bonus points for being -Wall safe, unless specific warnings have been deliberately excluded (shows they care and think about warnings) I would say haddockness is more important than coverage, and coverage is more important than -Wall. -- Ticket URL: Hackage Hackage: Cabal and related projects From alistair at abayley.org Tue Feb 12 03:47:30 2008 From: alistair at abayley.org (Alistair Bayley) Date: Tue Feb 12 03:46:13 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock In-Reply-To: <1202169209.13130.255.camel@localhost> References: <20080203042835.GA25241@haskell.galois.com> <20080204200537.GA12620@matrix.chaos.earth.li> <79d7c4980802041301k75ad087et2730cd8516d28ca9@mail.gmail.com> <20080204213702.GA15428@matrix.chaos.earth.li> <1202169209.13130.255.camel@localhost> Message-ID: <79d7c4980802120047xe0ec0cdv16e392c18ea37f58@mail.gmail.com> > That's what this whole thing is about, allowing haddock markup in the > comment sections of .lhs files. eg: > http://darcs.haskell.org/takusen/Database/Enumerator.lhs I've (finally) tested this with Takusen source and it seems to work well. Any further testing you'd like me to try? Alistair From duncan.coutts at worc.ox.ac.uk Tue Feb 12 04:26:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 12 04:25:38 2008 Subject: patch applied (cabal): Fudge comment indentation in unliting to work with haddock In-Reply-To: <79d7c4980802120047xe0ec0cdv16e392c18ea37f58@mail.gmail.com> References: <20080203042835.GA25241@haskell.galois.com> <20080204200537.GA12620@matrix.chaos.earth.li> <79d7c4980802041301k75ad087et2730cd8516d28ca9@mail.gmail.com> <20080204213702.GA15428@matrix.chaos.earth.li> <1202169209.13130.255.camel@localhost> <79d7c4980802120047xe0ec0cdv16e392c18ea37f58@mail.gmail.com> Message-ID: <1202808412.21103.136.camel@localhost> On Tue, 2008-02-12 at 08:47 +0000, Alistair Bayley wrote: > > That's what this whole thing is about, allowing haddock markup in the > > comment sections of .lhs files. eg: > > http://darcs.haskell.org/takusen/Database/Enumerator.lhs > > I've (finally) tested this with Takusen source and it seems to work > well. Great. > Any further testing you'd like me to try? I'm happy as it is. If we want more there's Ian's suggestion about doing a slightly more sophisticated indenting pass. Duncan From trac at galois.com Tue Feb 12 04:29:16 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 04:28:01 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.0f37881711ca8bf27913cf07e0729cee@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by duncan): The project description is haddock markup so adding links is already possible. Perhaps that'd be enough if it was well known. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 04:31:35 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 04:30:17 2008 Subject: [Hackage] #216: need a way to specify the foreign libraries a package depends on In-Reply-To: <056.50c203ebc5dcfd75c1c54a254cb11c5b@localhost> References: <056.50c203ebc5dcfd75c1c54a254cb11c5b@localhost> Message-ID: <065.b130eb340967bb7f7a30f519d15db335@localhost> #216: need a way to specify the foreign libraries a package depends on ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: major | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ----------------------------------+----------------------------------------- Comment (by duncan): See also #177, suggestion that we can at least check at configure time if all required C libs and header files can be found. Of course that does not relate them back to what packages those C libs belong to, but it'd give better error messages. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 04:38:55 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 04:37:36 2008 Subject: [Hackage] #58: allow darcs repo to be specified in cabal file In-Reply-To: <043.6583bf82ef1497f4ce27dc570194f6ee@localhost> References: <043.6583bf82ef1497f4ce27dc570194f6ee@localhost> Message-ID: <052.f9de07ae51dc3b63f7a148d419821371@localhost> #58: allow darcs repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): Isn't it vital to know what kind of repo we're dealing with, otherwise how do we know automatically which tool to use? For example if it's darcs (or another supported scm) then we can make darcs-graph activity graphs and other fun things. That's not possible if one has to somehow inspect the content at the other end of the url to guess what kind of repo it is. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 05:57:50 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 05:56:30 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.bad4c2a23552fca1307ea818569bdadb@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by nominolo): Hm, maybe we should split the description field into short-description and long-description or similar. Or, like in Emacs introduce the convention that the first 80 characters or the first sentence are a short description of the respective package, to be used in overview pages. If people adds lots and lots of links to the description field, the layout of the package site on Hackage might also be less functional since some information would move down. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 06:29:25 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 06:28:07 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.fdb493378ca0ade7a32b3b77f1339647@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by ross@soi.city.ac.uk): The package list uses the Synopsis field (plain text), rather than Description (haddock markup). -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 08:51:32 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 08:50:14 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.c69fe7c9d18a70b379af67f9da5ebaa3@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by nominolo): Ok, then how about a two-column layout? The text goes on the left and the meta information on the right. This way all the important information would stay on top, and authors are free to add more information into the Description part. (At the same time we'd make the text column narrower, which is good, too.) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 08:53:25 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 08:52:04 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.005672b29b60ac0fae56a333ca402bdb@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by ross@soi.city.ac.uk): I see Don wanted users to be able to add the links to a package after upload. They'd probably want to add text too, so what's required is essentially a wiki page for each package, though I'm not sure what's the best way to provide that. The hackageDB password file is in the same Apache format used by Trac, so that could be a possibility. See also #57. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 08:55:07 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 08:53:45 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.41f8a6f299a4fc64a2fc78f5d85425e7@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by ross@soi.city.ac.uk): Replying to [comment:4 nominolo]: > Ok, then how about a two-column layout? The text goes on the left and the meta information on the right. This way all the important information would stay on top, and authors are free to add more information into the Description part. (At the same time we'd make the text column narrower, which is good, too.) Are you referring to the package list or the page for an individual package? -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Feb 12 09:03:07 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 09:01:50 2008 Subject: [Hackage] #237: Support addition of links to Cabal project pages In-Reply-To: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> References: <041.b6e71a88c1ef9c8f4f9d066cce2c45e6@localhost> Message-ID: <050.2d1085362b499f6278eccaddec943364@localhost> #237: Support addition of links to Cabal project pages --------------------------------+------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by nominolo): Replying to [comment:6 ross@soi.city.ac.uk]: > Are you referring to the package list or the page for an individual package? To the page for the individual package. -- Ticket URL: Hackage Hackage: Cabal and related projects From byorgey at gmail.com Tue Feb 12 12:48:29 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Tue Feb 12 12:47:09 2008 Subject: darcs patch: add x-* extension field parsing for PackageDescriptions Message-ID: <22fcbd520802120948gd16bb8as3f5b10770d9fbcb7@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: add-x-extension-field-parsing.dpatch Type: application/octet-stream Size: 57253 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080212/3e37d975/add-x-extension-field-parsing-0001.obj From duncan.coutts at worc.ox.ac.uk Tue Feb 12 20:08:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 12 20:07:30 2008 Subject: Program prefix and suffix moved out of InstallDirs In-Reply-To: <6a7a1ebb0802112037o25bf25d2t65d1d621240adbd1@mail.gmail.com> References: <6a7a1ebb0802112037o25bf25d2t65d1d621240adbd1@mail.gmail.com> Message-ID: <1202864932.21103.153.camel@localhost> On Mon, 2008-02-11 at 20:37 -0800, Peter Higley wrote: > Here is the new and improved code for handling prefix and suffix. > InstallDirs is now all installation related directories, as implied by > the name. Looks great, thanks. Applied. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 12 20:13:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 12 20:11:51 2008 Subject: darcs patch: add x-* extension field parsing for PackageDescriptions In-Reply-To: <22fcbd520802120948gd16bb8as3f5b10770d9fbcb7@mail.gmail.com> References: <22fcbd520802120948gd16bb8as3f5b10770d9fbcb7@mail.gmail.com> Message-ID: <1202865193.21103.155.camel@localhost> On Tue, 2008-02-12 at 12:48 -0500, Brent Yorgey wrote: > Tue Feb 12 12:41:38 EST 2008 Brent Yorgey > * Add x-* extension field parsing (trac #210) Thanks! Applied. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 12 20:15:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 12 20:14:24 2008 Subject: patch applied (cabal): Moved --program-prefix and --program-suffix out of InstallDirs Message-ID: <20080213011547.GA23263@haskell.galois.com> Mon Feb 11 20:26:31 PST 2008 phigley@gmail.com * Moved --program-prefix and --program-suffix out of InstallDirs The program prefix and suffix have been moved out of InstallDirs so that InstallDirs is now all directories. The prefix and suffix have been moved into LocalBuildInfo as stand-alone PathTemplate flags. M ./Distribution/Simple/Configure.hs -1 +3 M ./Distribution/Simple/Install.hs -8 +11 M ./Distribution/Simple/InstallDirs.hs -25 +7 M ./Distribution/Simple/LocalBuildInfo.hs -2 +14 M ./Distribution/Simple/Setup.hs -7 +18 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080212042631-05ce6-8b606f012d1d5751debf9fb93e6a8b9e48b1bab9.gz From duncan.coutts at worc.ox.ac.uk Tue Feb 12 20:15:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 12 20:14:26 2008 Subject: patch applied (cabal): Add x-* extension field parsing (trac #210) Message-ID: <20080213011548.GA23286@haskell.galois.com> Tue Feb 12 09:41:38 PST 2008 Brent Yorgey * Add x-* extension field parsing (trac #210) M ./Distribution/PackageDescription.hs -3 +12 M ./Distribution/PackageDescription/Parse.hs -19 +61 M ./Distribution/ParseUtils.hs -1 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080212174138-bd4d7-db7df57706a52709534c3d46e5110907d4868025.gz From trac at galois.com Tue Feb 12 20:16:05 2008 From: trac at galois.com (Hackage) Date: Tue Feb 12 20:14:42 2008 Subject: [Hackage] #210: Enable access to the x- extension fields, as simple [(String, String)] name-value pairs In-Reply-To: <043.1b77f52bfb10122d1738237bc70690b4@localhost> References: <043.1b77f52bfb10122d1738237bc70690b4@localhost> Message-ID: <052.2739a239481d21d10f862160bbb7de75@localhost> #210: Enable access to the x- extension fields, as simple [(String, String)] name-value pairs ----------------------------+----------------------------------------------- Reporter: duncan | Owner: byorgey@gmail.com Type: enhancement | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: {{{ Tue Feb 12 17:41:38 GMT 2008 Brent Yorgey * Add x-* extension field parsing (trac #210) }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Wed Feb 13 11:02:35 2008 From: trac at galois.com (Hackage) Date: Wed Feb 13 11:01:10 2008 Subject: [Hackage] #238: haddock2 is not passed -D__HADDOCK__ or cpp-options Message-ID: <056.125da9c40afd60b181f7efe8b7c3d420@localhost> #238: haddock2 is not passed -D__HADDOCK__ or cpp-options ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- With haddock-1, Cabal invokes cpp, passing it ARCH and OS defines, -D__HADDOCK__ and the contents of cpp-options. However haddock-2 invokes cpp itself via the GHC API, which passes this cpp the ARCH and OS defines, but it doesn't get the others. It might also be a good idea to give __HADDOCK__ a numeric value, because GHC extensions need not be hidden from the new one. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Wed Feb 13 13:20:45 2008 From: trac at galois.com (Hackage) Date: Wed Feb 13 13:19:21 2008 Subject: [Hackage] #238: haddock2 is not passed -D__HADDOCK__ or cpp-options In-Reply-To: <056.125da9c40afd60b181f7efe8b7c3d420@localhost> References: <056.125da9c40afd60b181f7efe8b7c3d420@localhost> Message-ID: <065.327b76b3f3b7d1a0e7a4dec28748efa9@localhost> #238: haddock2 is not passed -D__HADDOCK__ or cpp-options ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------------+----------------------------------------- Comment (by duncan): I thought we wanted to avoid using -DHADDOCK precisely because haddock-2.0 can parse everything that ghc can, and so people should not need cpp hacks. Even if we use -DHADDOCK=2 we'll end up seeing the old workaround code that people show to haddock-0.x. We should be passing the cpp-options of course. IMHO, we should still make Cabal do the pre-processing rather than have ghc do it, but that's part of a larger task. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Wed Feb 13 15:13:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 13 15:11:54 2008 Subject: patch applied (cabal-install): -Wall clean Message-ID: <20080213201318.GA13011@haskell.galois.com> Wed Feb 13 11:33:25 PST 2008 Duncan Coutts * -Wall clean M ./Hackage/Dependency.hs -1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080213193325-adfee-8a4d097d94204b7e4b1996f01fdfd4c84105aba4.gz From duncan.coutts at worc.ox.ac.uk Wed Feb 13 15:13:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 13 15:11:55 2008 Subject: patch applied (cabal-install): Use setupMessage for consistency in downloading message Message-ID: <20080213201319.GA13034@haskell.galois.com> Wed Feb 13 11:33:46 PST 2008 Duncan Coutts * Use setupMessage for consistency in downloading message M ./Hackage/Fetch.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080213193346-adfee-57ef1df760a6454fd53ed4d72e28361981765208.gz From duncan.coutts at worc.ox.ac.uk Wed Feb 13 15:18:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 13 15:16:38 2008 Subject: patch applied (cabal): Don't re-export Compiler from Distribution.Simple.Setup Message-ID: <20080213201801.GA13149@haskell.galois.com> Wed Feb 13 11:27:56 PST 2008 Duncan Coutts * Don't re-export Compiler from Distribution.Simple.Setup M ./Distribution/Simple/Haddock.hs -1 +3 M ./Distribution/Simple/Setup.hs -4 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080213192756-adfee-20507ab754eb4aca5ec6d0f45380774858e596c6.gz From trac at galois.com Thu Feb 14 06:40:51 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 06:39:24 2008 Subject: [Hackage] #239: security hole: anyone can replace a package Message-ID: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- It is possible for any registered user to upload a new version of a package without reference to the actual maintainer of the package. The new upload can even have the same name and version number as an existing package. Not only does this allow a malicious or misguided person to arbitrarily change or remove good code: there is also no notification on the webpage of the package about who uploaded it - only the author/maintainer fields of the cabal file. Needless to say, the latter may not be very happy that their name is associated with a corrupt package that they did not upload or authorise. Recently, a significant number of packages have been uploaded without their maintainers' knowledge, so this could be a real problem. A quick fix would be to list the uploader's name against every package, so that the paranoid user can make an informed decision about its status. Ultimately the decision about whether to trust a package is a social and community issue, but the lack of transparency in discovering relevant information is a technical problem that does have a solution. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Feb 14 07:04:44 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 07:03:21 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> Message-ID: <051.30db426133a1777060b6f1ff6a7cc63f@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by ross@soi.city.ac.uk): It used to reject repeat uploads, but people complained. It can easily be turned on again. Putting the uploader and upload date on the package page is also in the works. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Feb 14 07:07:44 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 07:06:17 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> Message-ID: <051.e408bec856495f11e28220497e68124f@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by duncan): Replying to [comment:1 ross@soi.city.ac.uk]: > It used to reject repeat uploads, but people complained. What were the complaints? People are not satisfied with just uploading a new version? Is there something else that would satisfy them perhaps, like allowing hiding old/obsolete/broken versions in the web UI. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan at haskell.org Thu Feb 14 07:22:19 2008 From: duncan at haskell.org (Duncan Coutts) Date: Thu Feb 14 07:20:54 2008 Subject: darcs patch: Update to latest Cabal lib API and use n... (and 1 more) Message-ID: <20080214122052.51C30324076@www.haskell.org> Wed Feb 13 20:13:47 GMT 2008 Duncan Coutts * Update to latest Cabal lib API and use new package checking code Compiles but otherwise totally untested. Wed Feb 13 20:17:11 GMT 2008 Duncan Coutts * Reject uploading the same version of a package again -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 14426 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080214/bd1ec137/attachment.bin From trac at galois.com Thu Feb 14 08:34:47 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 08:33:21 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> Message-ID: <051.ac810ad8414e6cbaa41d595d34e33717@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by guest): The point of Malcolm's issue isn't uploading packages with the same version or not - that's irrelevant. It's someone who isn't the maintainer uploading the package - if they bump the version number they can still upload it. For what its worth, I want to upload packages with the same version, so please don't apply the rejecting patch. But I do want to stop anyone but me uploading packages for anything that I'm the maintainer of! -- Neil Mitchell -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Feb 14 08:51:04 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 08:49:35 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> Message-ID: <051.5da903dca618e38b08716191e5c8f627@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by duncan): It's not a trivial balance about who should be allowed to upload a package. By uploading to a public repo package authors are surrendering a little bit of control. If people start relying on a package then we want that package to continue even if the original uploader goes AWOL. So it is not clear that we would always want to restrict uploads to be the declared maintainer (or whoever uploaded it first). One could imagine a system where there is a list of allowed uploaders for a package and existing people could add others to that set. But whatever we do like that it has to be overridable for the cases when a package maintainer disappears. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Feb 14 08:54:02 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 08:52:33 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> Message-ID: <051.d31aaa21ba5231ab8de256a34fc0124b@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by guest): Yes, let it be overridden by a trusted admin type person. And let me say who I think can upload my package. But I shouldn't be allowed to upload a package on behalf of someone else without them knowing. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Feb 14 13:01:37 2008 From: trac at galois.com (Hackage) Date: Thu Feb 14 13:00:13 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> Message-ID: <051.bce3b5a345fba2bdbd0056d7a80b355d@localhost> #239: security hole: anyone can replace a package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------+------------------------------------------- Comment (by ross@soi.city.ac.uk): Yes, the security model is basic: if you have been (manually) registered you can upload any package, but your actions are published and logged. It's not designed to cope with malice, except that anyone who misbehaves can be deregistered. I think that restricting duplicate uploads ought to be done before too long. And the uploader info is needed on the package page (as is other info). But those things won't increase security for people using cabal- install (because it picks the most recent version, and they don't see the package page), and they won't prevent non-maintainer uploads. To do that we'd need to record ownership for packages, with human authorization the first time each package is uploaded and more administrative intervention if a package becomes dormant. These things would be extra costs on both users and administrators. Maybe we'd need to formalize a dispute resolution procedure. There's also the question of whether maintainers have a right to control uploads of their packages that should be policed by hackagedb. Alternatively we could just put up some notices about upload etiquette and talk to each other. We need to weigh what security would actually be achieved by a particular setup against the costs. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri Feb 15 01:09:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 01:08:21 2008 Subject: [Hackage] #239: security hole: anyone can replace a package In-Reply-To: <051.bce3b5a345fba2bdbd0056d7a80b355d@localhost> References: <042.18e4b7842ecfea759f6aa86a8d01deb6@localhost> <051.bce3b5a345fba2bdbd0056d7a80b355d@localhost> Message-ID: <1203055791.21103.245.camel@localhost> > I think that restricting duplicate uploads ought to be done before too > long. And the uploader info is needed on the package page (as is other > info). But those things won't increase security for people using cabal- > install (because it picks the most recent version, and they don't see the > package page) This in itself is something we should revisit at some point. If things are being managed more like a distribution we'd want the ability to designate some branch as the "current" or "best" version which may not necessarily be the highest version. For example Gentoo has two mechanisms, there is a way to designate packages as bleeding edge or tested and stable (and there is a protocol for transferring packages from one state to the other). Users can select whether they want to live on the bleeding edge, either globally or on a per-package basis. Additionally there is a "masking" system to prevent the package manager from considering certain versions at all. Within those constraints, the package manager tries to pick the highest version. Duncan From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:16:56 2008 Subject: patch applied (cabal): getInstalledPackages now returns full InstalledPackageInfo Message-ID: <20080215131825.GA29327@haskell.galois.com> Fri Feb 15 01:15:36 PST 2008 Duncan Coutts * getInstalledPackages now returns full InstalledPackageInfo rather than just PackageIdentifier. This will enable us to do lots more in future, for example detecting inconsistent package depends, doing our own cpp pre-processing or module chasing. M ./Distribution/InstalledPackageInfo.hs -2 +2 M ./Distribution/Simple/Configure.hs -4 +9 M ./Distribution/Simple/GHC.hs -40 +55 M ./Distribution/Simple/JHC.hs -2 +10 M ./Distribution/Simple/SetupWrapper.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080215091536-adfee-9c70db38382c29aec4807c3fe4cc75dbe1e97d12.gz From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:16:57 2008 Subject: patch applied (cabal): Add some more common utils we'll need in a sec and make use of intercalate Message-ID: <20080215131827.GA29352@haskell.galois.com> Fri Feb 15 01:24:43 PST 2008 Duncan Coutts * Add some more common utils we'll need in a sec and make use of intercalate Have to define it locally since it only appeared in Data.List recently. M ./Distribution/PackageDescription/Check.hs -2 +2 M ./Distribution/PackageDescription/Parse.hs -3 +3 M ./Distribution/ParseUtils.hs -1 +2 M ./Distribution/Simple/Configure.hs -2 +3 M ./Distribution/Simple/JHC.hs -5 +5 M ./Distribution/Simple/Utils.hs -2 +42 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080215092443-adfee-ba67fc91b561af94fd878cdad22a28d39e675222.gz From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:17:00 2008 Subject: patch applied (cabal): Simplify configure code by relying on ghc >= 6.4 Message-ID: <20080215131829.GA29371@haskell.galois.com> Fri Feb 15 01:26:28 PST 2008 Duncan Coutts * Simplify configure code by relying on ghc >= 6.4 We changed to require ghc >= 6.4 a while ago, this is just a simplification that was missed at the time. M ./Distribution/Simple/Configure.hs -8 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080215092628-adfee-a387197a93a3cd68dbb56ef039e2d0bbd290d9a0.gz From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:17:00 2008 Subject: patch applied (cabal): Add InstalledPackageIndex type and use it in place of [InstalledPackageInfo] Message-ID: <20080215131830.GA29390@haskell.galois.com> Fri Feb 15 04:40:51 PST 2008 Duncan Coutts * Add InstalledPackageIndex type and use it in place of [InstalledPackageInfo] The new index module is adapted from the similar module in cabal-install but with renamed functions and extended to work with full InstalledPackageInfo rather than just PackageIdentifier. So the getInstalledPackages functions now return an InstalledPackageIndex. M ./Cabal.cabal +1 M ./Distribution/Simple/Configure.hs -14 +18 M ./Distribution/Simple/GHC.hs -2 +6 A ./Distribution/Simple/InstalledPackageIndex.hs M ./Distribution/Simple/JHC.hs -4 +6 M ./Distribution/Simple/SetupWrapper.hs -4 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080215124051-adfee-6455fca9fcfe82bb5f9a0c2c7a4f5d6367e3ae2d.gz From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:17:04 2008 Subject: patch applied (cabal): Make the GHC.Makefile private Message-ID: <20080215131832.GA29407@haskell.galois.com> Fri Feb 15 05:04:59 PST 2008 Duncan Coutts * Make the GHC.Makefile private M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080215130459-adfee-fa880cf761886ce24f90fc1ae47c46104f86c71a.gz From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:17:05 2008 Subject: patch applied (cabal): Bump version to 1.3.5 due to more api changes Message-ID: <20080215131834.GA29427@haskell.galois.com> Fri Feb 15 05:05:13 PST 2008 Duncan Coutts * Bump version to 1.3.5 due to more api changes M ./Cabal.cabal -2 +2 M ./Makefile -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080215130513-adfee-533261411aac9f36ccc35182a24875893959dbbb.gz From duncan.coutts at worc.ox.ac.uk Fri Feb 15 08:18:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 15 08:17:09 2008 Subject: patch applied (cabal-install): Update to Cabal lib api changes Message-ID: <20080215131841.GA29458@haskell.galois.com> Fri Feb 15 05:11:42 PST 2008 Duncan Coutts * Update to Cabal lib api changes The InstalledPackageIndex replaces our Hackage.LocalIndex module M ./Hackage/Dependency.hs -19 +17 M ./Hackage/Fetch.hs -2 +2 M ./Hackage/Info.hs -2 +2 M ./Hackage/Install.hs -3 +3 R ./Hackage/LocalIndex.hs M ./Hackage/Setup.hs -1 M ./Hackage/Upgrade.hs -2 +2 M ./cabal-install.cabal -2 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080215131142-adfee-7967fa102b4ff74ce0d3ef5165d59b478ee3