August 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-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

[Hackage] #935: implementation of Distribution.Version.invertVersionRange
by Hackage 26 Oct '12

26 Oct '12

#935: implementation of Distribution.Version.invertVersionRange ----------------------------------+----------------------------------------- Reporter: dsf | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 7.4.1 Platform: | ----------------------------------+----------------------------------------- Attached is an implementation of a function to return the complement of a VersionRange. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/935> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Hackage2 server ready for testing
by Ian Lynagh 07 Sep '12

07 Sep '12

Hi all, All the bugs identified in the Hackage 2 server as blockers have now been fixed, and I have a mirror of Hackage running here: http://new-hackage.haskell.org/ I suggest that we proceed with: * A 3 week testing period, to be announced on haskell@ and libraries@ * Assuming no new blocking bugs are found which justify additional testing time, disable uploads to the Hackage 1 server * Throw the testing Hackage 2 instance away, and make a new mirror from the Hackage 1 server * Point hackage.haskell.org at the new Hackage 2 instance I think that a 3 week testing period will be sufficient as I expect most testing will happen in the first week or two, or the last few days, so any extra time is essentially wasted. I was actually initially going to propose 2 weeks, but given the timing of ICFP et al I think an extra week is justified. The reason I propose throwing away this test instance is that I think it's important that people are able to test uploading, and therefore uploading dummy packages and dummy versions should be encouraged. Does that plan sound reasonable to everyone? Is anyone willing to volunteer to be an admin for the new Hackage server please? (people need to have an admin add their account to the uploaders group before they can upload). A couple more notes: The mirror is a week or two old, so the latest package uploads won't be on it. I don't plan to set up continuous mirroring, as I think it may be more useful for people to be able to upload new versions to both servers themselves, for testing. The documentation builder has built (or failed to build) docs for the latest versions of all packages, but it's still working through older versions. It will therefore take up to 35mins before it notices that a new package has been uploaded, and builds docs for it. Finally, I would like to thank the Industrial Haskell Group (http://industry.haskell.org/) for funding this work. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 14

Re: Hackage 2
by Ian Lynagh 06 Sep '12

06 Sep '12

[moving to cabal-dev@] On Thu, Aug 30, 2012 at 08:13:01PM -0400, Leon Smith wrote: > Ok, I tried to upload the most recent version of postgresql-simple, and I > couldn't because I'm not the maintainer for that package. > > Has anybody ever uploaded a package that they shouldn't have on the old > Hackage? Is this security really necessary at this stage in the game? > > I'm very much of the philosophy that, given that we must approve > accounts, that we rely on social processes instead of technical solutions > for these types of access control issues until (and unless) experience > proves that we do need some kind of technical solution. But by then, > hopefully we'll have a better idea of what we need. I wasn't involved in the design of that, so I wonder if someone who was could comment? The most analogous large system I'm familiar with is Debian, which AFAIK has no technical measures to stop any developer uploading any package, but is careful about who it allows to become a developer. Perhaps it is redundant to have both the "uploaders" group and the "per-package uploaders" functionality enabled, and even if the software continues to support both, we should only enable one or the other on the central Hackage site? In which case, which do we want? If we do stay with the "per-package uploaders" feature, then I wonder whether we should have a special case for packages with an empty access list (i.e. all currently existing packages), such that anyone can upload a new version of them, and anyone doing so becomes the sole uploader for that package? That would avoid the admins having to get involved for every package, as well as every person. Thanks Ian

8 18

Re: Agreeing on a UI for sandboxes
by Mikhail Glushenkov 04 Sep '12

04 Sep '12

Hi, On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > Perhaps a separate command, cabal init-sandbox, would be the best > approach. Running that command would create the right package > environment for running in a sandbox and the remaining commands would > then use that sandbox. Separating init-sandbox from configure prevents > the user from removing the sandbox preference when reconfiguring for > some other reason (e.g. to add --enable-tests). To get out of the > sandbox the user would edit the package environment file. One problem with a separate sandbox-init command is that it gives you two ways to specify configure flags. E.g. you can do $ cabal sandbox-init -w /path/to/compiler-1 $ cabal install --only-dependencies and then run $ cabal configure -w /path/to/compiler-2 which will rewrite the package environment file, but then fail due to dependencies not being installed (since we are now using a different compiler). It can also be a bit non-obvious that when you run 'configure' after 'sandbox-init' it uses the configure flags given to 'sandbox-init' earlier (saved in the package environment file). >> I wouldn't change it yet. If at all, it should be a flag per >> add-source. Not everything you add-source are libraries you >> necessarily actively develop at the time. And I guess you can >> add-source not only local packages, right? > > I'm worried about making cabal even more cumbersome to use. [...] > If the use manually has to rebuild dependencies every time the change > even when using a sandbox we have essentially no improvement over > status quo and or cabal-dev. We can make automatic updating of dependencies the default and current behaviour optional. In any case, we need to agree how to update dependencies automatically. A naive algorithm is to just reinstall everything (which is what cabal-dev does). We can try to be a bit smarter and do something like the following: For each dependency added with add-source: If the dependency has already been configured and there is no need to reconfigure: Either just run 'cabal build' and reinstall only if the produced lib/exe is newer than the one we have installed, or get a list of all source files for each target (is this possible?) and rebuild&reinstall only if there is some source file newer than the installed target. Otherwise just configure, build and install. Also, should this happen each time the user runs 'cabal build' or only when running 'cabal install'? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

2 14

Uploading imported package to hackage 2
by Erik Hesselink 01 Sep '12

01 Sep '12

On Fri, Aug 31, 2012 at 11:12 AM, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Fri, Aug 31, 2012 at 2:13 AM, Leon Smith <leon.p.smith(a)gmail.com> wrote: >> Ok, I tried to upload the most recent version of postgresql-simple, and I >> couldn't because I'm not the maintainer for that package. > > What is your account name? I can add you as a maintainer for this package. I've experimented with this a bit. As an admin, I cannot edit the maintainers list. I had to add myself to the trustees group. Then I added myself as the maintainer of one of my packages. However, uploading a new version still failed. I cannot find a way to upload one of the existing imported packages. Does anyone have an idea why? Erik

2 4

patch applied (hackage-server): "Allow admins to add/remove admins"
by devnull＠community.haskell.org 30 Aug '12

30 Aug '12

Thu Aug 30 22:58:07 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Allow admins to add/remove admins Ignore-this: 552762da705aee949c063df88e07e445 This fix feels a little unsatisfactory to me. groupResourceAt will modify adminGroupDesc, but it will not modify the nested copies of adminGroupDesc in the canAddGroup/canRemoveGroup lists. I think it's the right fix given the existing system, though. M ./Distribution/Server/Features/Users.hs -2 +2

1 0

Re: Build failed in Jenkins: cabal #56
by Johan Tibell 29 Aug '12

29 Aug '12

On Wed, Aug 29, 2012 at 11:12 AM, Jenkins <jenkins(a)johantibell.com> wrote: > PackageTests/BuildDeps/InternalLibrary0/: > : [Failed] > error should say 'library which is defined within the same package.' > expected: True > but got: False I suspect that this test might be flaky as I've seen it go from passing to failing and back between builds which introduced changes that shouldn't affect this test. I've CCed the original test author. Anyone else knows what's going on here? -- Johan

1 2

Re: Agreeing on a UI for sandboxes
by Johan Tibell 29 Aug '12

29 Aug '12

Hi all, On Wed, Aug 29, 2012 at 3:38 PM, David Terei <dave.terei(a)gmail.com> wrote: > Hi All, > > So my uniformed 2cents. > > I'd really hate having to use normal'ish cabal commands prefixed with > 'sandbox'. I.e., configure-sandbox, build-sandbox... are all horrible. I should have clarified this point. These commands are temporary and hidden and will be removed once we settled on a UI. They exist so we can play around with the mechanism (i.e. sandbox) before we have a real UI for it. Sorry about the confusion. -- Johan

1 0