December 2012 - cabal-devel

darcs patch: Add a new checkout Command (and 1 more)
by Joachim Breitner 20 Jul '13

20 Jul '13

Hi, the small feature implemented by the attached patches could make it more convenient for people to quickly and easily contribute to hackage packages. Do you want me to open a ticket for this or can you appl yit right away? Thanks, Joachim 2 patches for repository http://darcs.haskell.org/cabal-install: Sun Nov 7 12:35:32 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a new checkout Command Given a package name, this uses the SourceRepo field of the newest versionf of that pacakge to figure out the repository location and calls the right VCS invocation. Sun Nov 7 12:43:35 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a --dry-run flag to cabal checkout

2 3

hackage trac
by Ian Lynagh 05 Apr '13

05 Apr '13

Hi all, A few IPs were hammering http://hackage.haskell.org/trac/hackage/wiki/HackageDB today which (is probably what) caused abbot to become inaccessible. /srv/trac/hackage/db/trac.db is 613MB, which seems rather suspicious: /srv/trac/ghc/db/trac.db is only 359MB. I wonder if it is full of spam? I'm also not able to load http://hackage.haskell.org/trac/hackage/wiki/HackageDB?action=history (it just times out). Could someone take a look please? Or perhaps the Cabal wiki should be moved elsewhere (github?) and the trac instance disabled? Thanks Ian

6 11

Adding tests for cabal-install
by Mikhail Glushenkov 01 Jan '13

01 Jan '13

Hi all, I'm currently looking into #1159, and I'd really like to add some unit tests for the UserConstraints parser. The problem is that I can't access modules defined under Distribution.Client.* without doing unnecessary recompilation. Would it be fine if I split cabal-install into library and executable parts in the following fashion: Library cabal-install Build-depends: ... ... Executable cabal-install Main-is: Main.hs Build-depends: cabal-install == N.N, ... ... Test-suite unit-tests Build-depends: cabal-install == N.N, ... ... -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4 6

hackage-server: index format
by Antoine Latter 20 Dec '12

20 Dec '12

Hi folks, The index tar-ball on Hackage has an odd naming convention. Package descriptions are given paths of the form: ./$pkg/$version/$pkg.cabal including the leading "./". I'm guessing that this is done as a method of distinguishing non-package meta-data. Is this a convention we need to preserve? Thanks, Antoine

6 12

current hackage 2 status
by Duncan Coutts 18 Dec '12

18 Dec '12

Hi folks, You may have noticed the steady stream of hackage 2 patches. The new server is up again at: http://new-hackage.haskell.org/ Key points: * We've got live mirroring going (sync every 30 min). * All the old accounts are imported and the per-package maintainer groups are populated. * Package deprecation info is imported * Distro info is imported * Currently uploading is disabled (pending review of authentication & authorisation code). * Documentation is not imported (Ian demoed this before, just haven't got round to it yet for this instance) * The data backup system is much improved. In general the switch over plan remains that we run the two servers in parallel for long enough to sort out remaining issues (with help from the kind folks who volunteered as admins). There was some discussion before about user accounts and the issue of per-package maintainer groups. So the system I envisage for user accounts is that anyone can make an account, but to be added to the uploaders group will require approval from a volunteer administrator (technically speaking there are not yet any features that need an account but don't involve uploading, but I'm assuming some future social features will need this). I do think the per-package maintainer groups are important for security, and now that we can automatically populate them from the old hackage data, I don't think that's a problem. Still missing is a proper process for new account creation. That is, account creation with email validation and all that. There's a couple of options here. We can build it into the server, or we can make a separate page/script to do that (which would make accounts using the appropriate curl -X PUT commands against the server). -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

license cabal field for language bindings?
by Herbert Valerio Riedel 17 Dec '12

17 Dec '12

Hello Cabal Devs, Since the recurring topic of software licenses is being discussed on haskell-cafe again, I was wondering what the .cabal license-field should be for packages linking _directly_ to C-libraries, such as Haskell language bindings to C-libraries. To be more specific: As a side-effect of the ongoing discussion, Michael Snoyman implemented a web-based tool for computing the transitive license multiset[1] which made me wonder whether the .cabal license field should describe only the license of the source code proper distributed with the package or whether it should also take into account the licenses of the wrapped/linked libraries? E.g. * http://hackage.haskell.org/package/hfann is advertised as BSD3, but the FANN library[2] is actually LGPL. * http://hackage.haskell.org/package/igraph is advertised as BSD3 but the underlying igraph library is GPL2+ [3]. In these cases Michael's license-tool has no chance to report reliable information about the involved licenses, as the LGPL/GPL license is not mentioned in the cabal meta-data. In order to help describe cabal package's licenses more accurate, would it be conceivable to have either a) the license field take a list of licenses, b) in case of FFI bindings, set the license field to the more restricting license type, or c) introduce an additional field 'x-license' for specifying the external non-Haskell library's license? PS: A separate but related issue was raised in the haskell-cafe discussion: Many packages depend on the cpphs library as a hack, although they only need the cpphs executable (and therefore don't link against the cpphs package). This also skews the result that tools like [1] report, as the cpphs library is LGPLed which doesn't matter if only the cpphs executable was actually used for building the package. [1]: http://packdeps.haskellers.com/licenses [2]: http://leenissen.dk/fann/wp/ [3]: http://igraph.sourceforge.net/license.html Cheers, hvr

2 1

patch applied (hackage-server): "Add a log timing function and use it in the package state loading"
by devnull＠community.haskell.org 16 Dec '12

16 Dec '12

Sun Dec 16 14:51:20 GMT 2012 Duncan Coutts <duncan(a)community.haskell.org> * Add a log timing function and use it in the package state loading Ignore-this: c29a834df997c2bb0720fb6036c764a5 M ./Distribution/Server/Features/Core.hs -5 +7 M ./Distribution/Server/Framework/Cache.hs -16 +7 M ./Distribution/Server/Framework/Logging.hs -1 +12

1 0

patch applied (hackage-server): "Make a few feature's expensive cache init operations asynchronous"
by devnull＠community.haskell.org 16 Dec '12

16 Dec '12

Sun Dec 16 14:27:22 GMT 2012 Duncan Coutts <duncan(a)community.haskell.org> * Make a few feature's expensive cache init operations asynchronous Ignore-this: 3272cd4c79d739bfa6919e9e7c874374 Should parallelise startup a bit M ./Distribution/Server/Features/Core.hs +2 M ./Distribution/Server/Features/Html.hs +2 M ./Distribution/Server/Features/NameSearch.hs +2

1 0

patch applied (hackage-server): "Extend debug and logging infrastructure"
by devnull＠community.haskell.org 16 Dec '12

16 Dec '12

Sun Dec 16 14:05:47 GMT 2012 Duncan Coutts <duncan(a)community.haskell.org> * Extend debug and logging infrastructure Ignore-this: e8618d92e85f8a5af4aa13de90d9b507 Add better log functions and pass verbosity into each feature. Add logging to feature initialisation. M ./Distribution/Server.hs -4 +3 M ./Distribution/Server/Features.hs -5 +8 M ./Distribution/Server/Features/Core.hs -2 +6 M ./Distribution/Server/Features/Distro.hs -2 +5 M ./Distribution/Server/Features/Documentation.hs -2 +6 M ./Distribution/Server/Features/DownloadCount.hs -3 +5 M ./Distribution/Server/Features/HaskellPlatform.hs -2 +5 M ./Distribution/Server/Features/Html.hs -3 +8 M ./Distribution/Server/Features/Mirror.hs -1 +4 M ./Distribution/Server/Features/NameSearch.hs -4 +10 M ./Distribution/Server/Features/PackageContents.hs -3 +5 M ./Distribution/Server/Features/PackageList.hs -1 +4 M ./Distribution/Server/Features/Packages.hs -3 +6 M ./Distribution/Server/Features/PreferredVersions.hs -2 +6 M ./Distribution/Server/Features/ReverseDependencies.hs -3 +7 M ./Distribution/Server/Framework.hs +2 M ./Distribution/Server/Framework/Cache.hs -12 +13 A ./Distribution/Server/Framework/Logging.hs M ./Distribution/Server/Framework/Types.hs -1 +4 M ./Main.hs -43 +43

1 0

patch applied (hackage-server): "Don't parse all the .cabal files when loading the data"
by devnull＠community.haskell.org 16 Dec '12

16 Dec '12

Sun Dec 16 10:33:22 GMT 2012 Duncan Coutts <duncan(a)community.haskell.org> * Don't parse all the .cabal files when loading the data Ignore-this: d9596e748145330dd552c3298d66ef94 M ./Distribution/Server/Packages/Types.hs -4 +1

1 0