- cabal-devel - Haskell.org

patch applied (hackage-server): "Remove an empty directory"
by devnull＠community.haskell.org 13 Jul '12

13 Jul '12

Fri Jul 13 14:19:08 BST 2012 Ian Lynagh <igloo(a)earth.li> * Remove an empty directory Ignore-this: cbc419c5f38680cf6b56bc60af2e8112 R ./Distribution/Server/Auth/

1 0

patch applied (hackage-server): "Remove some uses of the deprecated withHackageAuth" and 2 others
by devnull＠community.haskell.org 13 Jul '12

13 Jul '12

Fri Jul 13 13:13:26 BST 2012 Ian Lynagh <igloo(a)earth.li> * Remove some uses of the deprecated withHackageAuth Ignore-this: 181054b28f6a34c507b99bc1c24247d2 M ./Distribution/Server/Features/Users.hs -21 +17 Fri Jul 13 13:46:33 BST 2012 Ian Lynagh <igloo(a)earth.li> * Remove all uses of withHackageAuth Ignore-this: 12f14eb19693b975bb2e797d7f1f2eeb M ./Distribution/Server/Features/BuildReports.hs -29 +27 M ./Distribution/Server/Features/Html.hs -3 +1 M ./Distribution/Server/Features/Mirror.hs -4 +2 M ./Distribution/Server/Features/Tags.hs -1 +2 M ./Distribution/Server/Features/Upload.hs -7 +8 M ./Distribution/Server/Features/Users.hs -3 +3 Fri Jul 13 13:48:43 BST 2012 Ian Lynagh <igloo(a)earth.li> * Remove deprecated withHackageAuth Ignore-this: b4088fce8beb172b12a8c58b719c0bba M ./Distribution/Server/Framework/Auth.hs -16

1 0

patch applied (hackage-server): "Add the beginnings of a very high-level test"
by devnull＠community.haskell.org 13 Jul '12

13 Jul '12

Fri Jul 13 12:31:03 BST 2012 Ian Lynagh <igloo(a)earth.li> * Add the beginnings of a very high-level test Ignore-this: 2cfcfa2d4c620596b7a6d2d4b84d11e8 M ./hackage-server.cabal +14 A ./tests/HighLevelTest.hs A ./tests/Run.hs

1 0

patch applied (hackage-server): "Add a --ip option, to specify the IP that the server listens on"
by devnull＠community.haskell.org 11 Jul '12

11 Jul '12

Wed Jul 11 21:54:23 BST 2012 Ian Lynagh <igloo(a)earth.li> * Add a --ip option, to specify the IP that the server listens on Ignore-this: d045df6d573940bb6ae21540f5d9a7d3 For now, only IPv4 is supported. M ./Distribution/Server.hs -12 +25 M ./Main.hs -3 +34

1 0

hackage search
by Ian Lynagh 11 Jul '12

11 Jul '12

Hi all, abbot just had a load average in the 90s, and was being rather unresponsive. Looking at the mrtg graphs it looks like the load peak followed a bandwidth peak: http://abbot.haskell.org/mrtg/daily.html I killed these two processes: 23603 www-data 20 0 4927m 3.2g 668 D 1 41.2 2:48.36 search 23663 www-data 20 0 3777m 2.4g 256 D 0 30.8 2:29.82 search and the LA is dropping. I'm not sure if B/W is about to start going up again as a result. Thanks Ian

1 0

patch applied (hackage-server): "Fix warnings"
by devnull＠community.haskell.org 06 Jul '12

06 Jul '12

Fri Jul 6 17:31:00 BST 2012 Ian Lynagh <igloo(a)earth.li> * Fix warnings Ignore-this: 17366aae138b401f4122e504b3f246d3 M ./BuildClient.hs -14 +20 M ./Distribution/Client.hs -23 +28 M ./Distribution/Server.hs -2 +4 M ./Distribution/Server/Features/BuildReports.hs -3 +5 M ./Distribution/Server/Features/BuildReports/Backup.hs -6 +6 M ./Distribution/Server/Features/BuildReports/BuildReports.hs +1 M ./Distribution/Server/Features/BuildReports/State.hs +1 M ./Distribution/Server/Features/Check.hs -3 +3 M ./Distribution/Server/Features/Core.hs -3 +4 M ./Distribution/Server/Features/Distro.hs -4 +4 M ./Distribution/Server/Features/Documentation.hs -2 +2 M ./Distribution/Server/Features/Html.hs +2 M ./Distribution/Server/Features/LegacyRedirects.hs -13 +11 M ./Distribution/Server/Features/Mirror.hs -2 +5 M ./Distribution/Server/Features/PackageList.hs -3 +2 M ./Distribution/Server/Features/PreferredVersions.hs -3 +4 M ./Distribution/Server/Features/Tags.hs -3 +3 M ./Distribution/Server/Features/Upload.hs +2 M ./Distribution/Server/Features/Users.hs -7 +8 M ./Distribution/Server/Framework/Auth.hs -17 +17 M ./Distribution/Server/Framework/BackupDump.hs -1 +2 M ./Distribution/Server/Framework/BackupRestore.hs +1 M ./Distribution/Server/Framework/Instances.hs +2 M ./Distribution/Server/Framework/Resource.hs -15 +15 M ./Distribution/Server/Packages/State.hs +1 M ./Distribution/Server/Packages/Types.hs -1 M ./Distribution/Server/Pages/Package.hs -6 +6 M ./Distribution/Server/Pages/Recent.hs -2 M ./Distribution/Server/Users/State.hs +1 M ./Distribution/Server/Util/AsyncVar.hs -1 +2 M ./Distribution/Server/Util/ContentType.hs -1 +2 M ./Distribution/Server/Util/ServeTarball.hs -2 +2 M ./Main.hs -2 +2 M ./MirrorClient.hs -69 +69

1 0

patch applied (hackage-server): "Update safecopy and acid-state dependencies"
by devnull＠community.haskell.org 06 Jul '12

06 Jul '12

Fri Jul 6 14:35:30 BST 2012 Ian Lynagh <igloo(a)earth.li> * Update safecopy and acid-state dependencies Ignore-this: c14ec775819459767a72312fcccf95ad Based on a patch from Jeremy Shaw <jeremy(a)seereason.com> M ./Distribution/Server/Acid.hs -16 +17 M ./Distribution/Server/Users/Backup.hs -1 +1 M ./hackage-server.cabal -2 +2

1 0

Hackage 2 status
by Ian Lynagh 03 Jul '12

03 Jul '12

Hi all, I'm planning to spend some time, on behalf of the Industrial Haskell Group, working on Hackage 2 in the coming weeks. As such, I've been trying to work out what the blockers are in terms of actually getting the hackage 2 server live. I've started from the "Current TODOs" section of http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0 and the rest of this mail is a brief description of what I've found out, and my conclusions. Active tickets against Hackage 2 -------------------------------- There are currently 8 tickets: #911 Package uploading is completely unsecured high #916 Verify that HTTP interface is fully/properly implemented high #918 Working documentation builder high #426 .cabal files should be stored next to tarballs, potentially overriding in-tarball version normal #913 New HTML theme normal #914 Fix acid-state usage normal #919 hackage-mirror should handle errors more gracefully normal #915 Convert to modular use of type-safe URLs low Now #913 I assume is not a blocker. #919 I assume is also not a blocker. And #914 and #915 are improvements to the internals, so presumably also not blockers. #426 is not supported by Hackage 1 as far as I can see, so is not a blocker as it is not a regression. So that leaves 3 tickets as blockers: #911: We need to do something here. With Hackage 1, it takes manual approval before you can upload packages, and at the very least Hackage 2 should match that. I have the impression that that is already possible (by restricting package upload to a group, and requiring accounts to be added to that group by an admin), but I haven't confirmed that yet. #916: At the very least, Hackage 2 needs to support URLs that Hackage 1 supported (unless a conscious decision has been made not to). Ideally we would get the URLs right on the initial release, so that people don't start using the wrong ones. Doesn't sound hard, so may as well do before the switchover. #918: This is the main missing functionality currently missing from the user's point of view. HackageDB --------- I don't think there are any blockers on this page. HackageToDo ----------- Package builds: Not a regression, so not a blocker. Haddocking: See #918 above. Hoogle database: Not a regression, so not a blocker. HsColour: Hackage 1 supports this. Should be done as part of #918. Testing builds: Not a regression, so not a blocker. Running testsuites: Not a regression, so not a blocker. Packages properties: Meta info is already available, so not a blocker. Queries: Not a regression, so not a blocker. Show respository: Small regression; May as well fix. README markup etc: Not a regression, so not a blocker. Uploads: All sub opints either mentioned already or new features. Not blockers. DOAP: Not a regression, so not a blocker. Gateways: Should support the existing "Distributions" files. Documentation needs love ------------------------ I'm not sure whether user or developer documentation is intended here. Without more details, I'll treat this as not a blocker. Further context --------------- I didn't see any other blockers in the old mails linked to. Conclusion ---------- I think the following are the blockers for deploying Hackage 2: * #911 upload perms; may be good enough already * #916 check URLs are OK * #918 build haddock (and HsColour) docs * Show source respository on package pages * Support the existing "Distributions" files, and show info on package pages (plus enough testing to give us confidence in it, of course). Does that match other people's opinions? Did I miss anything? Thanks Ian

4 6

hackage2 account approvals (Re: Hackage 2 status)
by Conrad Parker 03 Jul '12

03 Jul '12

On 3 July 2012 03:14, Duncan Coutts <duncan.coutts(a)googlemail.com> wrote: > On Mon, 2012-07-02 at 12:25 +0100, Ian Lynagh wrote: >> Hi all, >> >> I'm planning to spend some time, on behalf of the Industrial Haskell >> Group, working on Hackage 2 in the coming weeks. > > [..] > >> So that leaves 3 tickets as blockers: >> >> #911: We need to do something here. With Hackage 1, it takes manual >> approval before you can upload packages, and at the very least Hackage 2 >> should match that. I have the impression that that is already possible >> (by restricting package upload to a group, and requiring accounts to be >> added to that group by an admin), but I haven't confirmed that yet. > > Right, I don't think we need to do any more than make sure uploaders are > in the appropriate group. It *should* currently be the case that only > accounts in the package group can upload, and the first time you upload > a new named package then you get added as the initial member of the new > package group. > > Currently for testing purposes anyone can register an account and can > then upload new packages. We have two options here: restrict account > creation to be manual like in hackage 1, or add a new system-wide > "uploaders" group for accounts that are authorised to upload new > packages and have a manual admin step to add people to the uploaders > group. The latter will allow for registered users who are not uploaders > which would be useful later to allow things like non-anonymous > commenting etc. I think we should avoid manual approvals; I know several people who have excellent, working, used in-production, cabalified Haskell code but for whatever reason they are reluctant to request an account -- however they have code on github. Allowing random users to upload code only really becomes a problem when poorly named or insecure packages pollute the global namespace; perhaps admin approval should only be on global naming, not on account creation and upload. Conrad.

2 1

Flag auto-detection
by Roman Cheplyaka 08 Jun '12

08 Jun '12

The Cabal user's guide says: By default, Cabal will first try to satisfy dependencies with the default flag value and then, if that is not possible, with the negated value. Does this not hold for the extra-libraries? In a cabal file I have Flag docs-only default: False Library if ! flag(docs-only) extra-libraries: ole32 oleaut32 The command % cabal configure -fdocs-only completes successfully, while simple % cabal configure fails due to the unmet dependencies. Why doesn't Cabal flip the flag when it can't find those libraries? -- Roman I. Cheplyaka :: http://ro-che.info/

1 0