- cabal-devel - Haskell.org

Hackage trac account
by Andres Löh 22 Feb '12

22 Feb '12

Hi. Sorry for spamming the mailing list. But I've had trouble logging in to the Hackage/Cabal trac already before the trac was disabled; and now that it's back up, I still can't login. I can't find anywhere an email address where to report it, and I don't fully understand who (if anyone) is responsible, so I'm sending this here. Could whoever has the permissions please reset my apparently existing account kosmikus? It doesn't seem to send me email when I click on password reminder, even though it claims to do so. Ideally, you'd also reset the mail address to either mail(a)andres-loeh.de or andres(a)well-typed.com. Thank you very much in advance. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

2 1

[Hackage] #919: hackage-mirror should handle errors more gracefully
by Hackage 21 Feb '12

21 Feb '12

#919: hackage-mirror should handle errors more gracefully -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- hackage-mirror against hackage.haskell.org fails with, {{{ $ hackage-mirror http://hackage.haskell.org/ http://bgamari:xxx@localhost:8080/ 17816 packages to mirror. mirroring PlslTools-0.0.1 hackage-mirror: Failed to upload package PlslTools-0.0.1, HTTP error code 400, Bad Request http://bgamari:...@localhost:8080/package/PlslTools-0.0.1/PlslTools-0.0.1.t… short tar trailer }}} While the source of the error is unclear, it's a sign that the error handling should be more robust. Perhaps failing packages should be skipped until it's very clear that something is horribly wrong (e.g. a heuristic like 10 packages fail in a row)? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/919> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #918: Working documentation builder
by Hackage 19 Feb '12

19 Feb '12

#918: Working documentation builder -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: high | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- Currently hackage-build is in the repository and can build documentation, but it depends upon a cabal-install patch adding haddock options to the "install" sub-command[1], {{{ 18:21 < dcoutts> he sent a patch for cabal-install 18:21 < dcoutts> and this relies on it 18:21 < bgamari> It was merged? 18:21 < dcoutts> the patch should be in the cabal-devel archives, or in the trac 18:22 < dcoutts> bgamari: I've not yet, I was going to see if it could be done nicer / more generically 18:22 < dcoutts> but perhaps I shouldn't bother 18:22 < dcoutts> the difficulty is it affects the ~/.cabal/config format too 18:22 < dcoutts> so it's harder to change later 18:22 < bgamari> ahh 18:23 < bgamari> Yes, I can understand your hesitance in that case }}} [1] http://www.haskell.org/pipermail/cabal- devel/2011-September/007782.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/918> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Patch for broken 'cabal configure --enable-tests'
by Thomas Tuegel 18 Feb '12

18 Feb '12

When we fixed dependency resolution for tests in cabal-install, I didn't make 'cabal configure' add the new resolver constraints when appropriate. As a result, 'cabal configure' was silently ignoring '--enable-tests' and '--enable-benchmarks'. The attached patch corrects this behavior. Thanks! -- Thomas Tuegel

1 0

Re: patch: --enable-tests and --only-dependencies
by Andres Löh 17 Feb '12

17 Feb '12

Hi Thomas. Modular solver support for optional stanzas is done. Regarding your patches, there's one aspect I don't understand: In Distribution/Client/Install.hs: configBenchmarks = toFlag False, configTests = toFlag (TestStanzas `elem` stanzas) You first had configBenchmarks analogous to configTests, then changed it back. I don't fully understand why the two should be handled differently. Could you please explain? Do you happen to know existing packages that make use of benchmark stanzas that I could use as test cases? The current diff to the trunk (all I intend to push) is here: http://www.andres-loeh.de/cabal-install-enable-tests-3.dpatch Thanks. Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

3 15

[PATCH] cabal-install: Handle getModificationTime for ghc-7.5
by Conrad Parker 17 Feb '12

17 Feb '12

Hi, the attached patch fixes compilation of cabal-install with current ghc master. Tested-with: ghc-7.0.3, ghc-7.2.1, ghc-7.4.1, ghc-7.5.20120216 Conrad.

1 0

[Hackage] #888: runTests deprecated message should be more helpful
by Hackage 16 Feb '12

16 Feb '12

#888: runTests deprecated message should be more helpful ----------------------------+----------------------------------------------- Reporter: dsfox | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It would be great if this message explained what the new testing interface was, where to find it, and optimally how to quickly create something more or less equivalent to the runTests function so we can get on with our lives. :) Warning: In the use of `runTests' (imported from Distribution.Simple, but defined in Distribution.Simple.UserHooks): Deprecated: "Please use the new testing interface instead!" -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/888> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

Re: Hackage 2 maintainership
by Duncan Coutts 15 Feb '12

15 Feb '12

On 14 February 2012 16:10, Ben Gamari <bgamari.foss(a)gmail.com> wrote: > It seems the first task will be to identify exactly what needs to be > done before we can begin the transition and record these tasks in a > single place. I don't have a particularly strong opinion concerning > where this should be (Trac, the Hackage wiki, the github issue tracker > that's been mentioned), but we should consolidate everything we have in > a single place. Right. Then we should see what milestones we need, and assign tickets to milestones. As we discussed yesterday, I think it makes sense to share the same trac for cabal and hackage due to cross-cutting issues. BTW, I also usually try to keep cabal-devel in the loop (cc'd), so as to let people participate or simply get visibility into what's going on. >> We did get another reasonable push at the time. In particular Max did >> a lot of good work. I'm not quite sure why it petered out again, I'd >> have to ask Max what went wrong, if it was my fault for letting things >> block on me or if it was just holidays/christmas. Maintaining momentum >> is hard. >> > This is quite true. I'll try to keep a constant push. > > On another note, how did your full mirroring go last night? Interrupted by the hackage.h.o server going down :-( I've restarted the mirroring. Currently less than 4000 packages left to go. I'd expect a few more hours. Then I can assess how many packages remain unmirrorable. Can also start continuous mirroring after that. Duncan

1 0

[Hackage] #911: Package uploading is completely unsecured
by Hackage 14 Feb '12

14 Feb '12

#911: Package uploading is completely unsecured -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- Right now, anyone can register an account (without passing any kind of CAPTCHA or anything, so bots will overrun the place quickly on a live site) and upload new packages to their heart's content. This is a major risk for several reasons (package installation can do evil stuff with custom build types, easy to use up tons of disk space, etc.) Of course, nothing can truly solve the security issue, but I suggest the following: 1. A simple but Hackage-specific CAPTCHA on the registration page (e.g. "What language are HackageDB packages written for?") — it's unlikely that spambots will target it specifically, and a simple but unique CAPTCHA will be stronger than a generic solution like reCAPTCHA which has a lot of effort going into breaking it (e.g. someone being paid to fill out CAPTCHAs isn't going to have any idea that the answer is "Haskell") 2. Limit package uploading to members of a group which only admins can add to This should be a simple change to the code. The workflow for a package uploader would be: 1. Register an account 2. Email the maintainer asking for a package upload This is basically the same as the Hackage1 registration process, but a bit easier for the maintainer. {{{ <dcoutts> bgamari, cmccann, elliott: so the auth system in the new design copes ok with package uploaders, what it does not cover well is casual users who might want to post reviews, vote etc, but not upload packages <dcoutts> since you probably want self-registration for those users <dcoutts> but for uploaders it's sensible to have a human in the loop <bgamari> Certainly <dcoutts> like we do in the current system <dcoutts> so there's an admin user group who can edit other groups <dcoutts> ie grant permissions [...] <dcoutts> elliott, cmccann: right, plus in the new system since there's a per-package uploader group then unknown users cannot subvert well known names (ie packages) <dcoutts> so in the new system malicious people can still upload *new* malicious packages <dcoutts> but cannot subvert e.g. base }}} An ideal solution would be something like: 1. Reasonable per-user quotas (liftable on request) for disk usage, to stop people spamming the system 2. Users by default can upload packages, but they're in a quarantine: not visible on the site or installable 3. Whenever a user uploads their first package, the maintainer gets an email and can check it out and approve the user (making their packages public) if it looks OK That would be nicer, but probably require a lot more coding than the simpler solution. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/911> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #915: Convert to modular use of type-safe URLs
by Hackage 14 Feb '12

14 Feb '12

#915: Convert to modular use of type-safe URLs -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/915> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2