August 2008 - cabal-devel

[Hackage] #261: Marking packages deprecated
by Hackage 05 Nov '09

05 Nov '09

#261: Marking packages deprecated ----------------------------+----------------------------------------------- Reporter: nibro | 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: | ----------------------------+----------------------------------------------- There should be a way to mark a package as '''deprecated''' so it doesn't show up on the main Hackage listing. If a newer package, with the same name, is uploaded then the older packages will in effect be defunct. But if you don't have a newer package with the same name, there is currently no way to "get rid of" packages that are no longer valid. There may be several reasons for why you would want to do this, likely most often because the contents of the package are superceded by functionality in some other package, with a different name. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/261> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #282: profiling versions of libraries not managed well
by Hackage 30 Sep '09

30 Sep '09

#282: profiling versions of libraries not managed well ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: profiling Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ At the moment, if you want profiling builds of libraries which you have already installed, the only way to get them is to unregister and rebuild with profiling turned on. This is especially inconvenient when you have a program that depends on many different libraries... Ideally, I could just add a flag to rebuild a program with profiling, regardless of whether I'd installed profiling versions or not... Any ideas on how this should be managed? What configurations should be allowed? How do we make sure the same library version is used for the profiling build as was used for the normal build? When do we just give up and make the user figure it out? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/282> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #320: cooperation with Windows Vista's User Access Control
by Hackage 20 Sep '09

20 Sep '09

#320: cooperation with Windows Vista's User Access Control ----------------------------+----------------------------------------------- Reporter: Toxaris | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Windows | ----------------------------+----------------------------------------------- Installation of a cabal package under Windows Vista with UAC activated may fail even when working as administrator, because cabal doesn't request the necessary rights to write to, e.g., "c:\Program Files\Haskell\<whatever>". A workaround is to start an "Administrator console" to start Cabal from a process which already acquired admin privileges. Cabal should request the necessary rights instead of failing. cabal-install should check in advance whether the target destination is writeable and fail early or request the necessary rights. (currently, cabal-install fails after compiling all dependencies. After starting cabal-install again from an Administrator console, everything has to be build again). {{{ C:\Downloads\Haskell\typeof-0.1.1>runhaskell Setup install Setup: C:\Program Files\Haskell\doc\typeof-0.1.1: copyFile: permission denied (P ermission denied) }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/320> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #240: setup install does not preserve MacOS X resource forks
by Hackage 11 Sep '09

11 Sep '09

#240: setup install does not preserve MacOS X resource forks ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- I use the attached Setup.lhs file to do some Mac-related magic (which I unfortunately do not understand) on files built with wxhaskell on MacOS X. The key point about this magic is that it allows me to run a GUI from the command line. Without doing the magic, the GUI will open, but it will not react to any user interaction. I think the problem is that whatever mechanism we use to copy the binary over (say to /usr/local/bin) does not preserve the magic. That is, if I run it directly after a runhaskell Setup install, I get the non-reactive GUI. If I do a cp geni /usr/local/bin by hand, then the GUI reacts, presumably because on MacOS X cp also copies the magic over. Sorry for being so vague. Let me know if I can help in any way. -- Eric Kow -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/240> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #274: Add a 'build from sdist tarball' feature
by Hackage 23 Aug '09

23 Aug '09

#274: Add a 'build from sdist tarball' feature ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I've often seen Darcs repos where the sdist tarball was incomplete, or where a person had a tarball which was incomplete. I think this is because most people just never use the tarball; if they do ever use it, it's because it's what was downloaded from Hackage. The reason is that doing so is much more complex than 'configure; build; install': you need to configure, create an sdist tarball, cd into dist/; do a tar -xvf or whatever of the correct tarball; cd into *that* - and then you can configure/build/install. Assuming it is a working tarball. Now, of course you can automate it. After the first dozen times, I wrote myself a shellscript to do all that for me: function build_sdist { clean_configure && sdist && cd dist/ && untar *.tar.gz && cd `ls -t ./ | grep "/" | head -n 1` && clean_configure && build && hinstall; haddock && hinstall; } (This is pretty long and imperfect, but it would be even longer if all the other aliases and function definitions were included; I think they're pretty straightforwardly named though, so I haven't included them.) It seems to me that this would be, at the very least, a useful adjunct to cabal check - if it makes sense to see whether various fields are filled out sanely, surely it makes sense to see whether needed files are included/listed? It might be even better to make the normal 'runhaskell Setup build' do it from sdist, but this is harder to code (besides the forgoing, you'd need to copy in the configuration from the top-level, from when the user ran 'runhaskell Setup configure' and added whatever options) and possibly more confusing ("But Foo.hs *is* there, right there in src/! Why can't Cabal find it?"). So I'd be satisfied to do something like 'cabal checkdist'. -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/274> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #199: when installing a new version of GHC, there should be a way to upgrade my packages
by Hackage 18 Jul '09

18 Jul '09

#199: when installing a new version of GHC, there should be a way to upgrade my packages ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ If I have version 6.6 of GHC installed, with packages foo, bar, and bang, and I install ghc 6.8, I'd like a way to automatically install foo, bar, and bang. This could be part of GHC's installation script possibly, or maybe a feature of cabal install. cabal can check the installed packages for the previous version of GHC and "cabal install" them. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/199> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

[Hackage] #330: Take non-haddock documentation in account
by Hackage 01 Jul '09

01 Jul '09

#330: Take non-haddock documentation in account ----------------------------+----------------------------------------------- Reporter: fons | 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: | ----------------------------+----------------------------------------------- The generation and installation of Non-Haddock documentation (README and INSTALL files, LaTeX and Docbook tutorials/guides, Haskell examples using the package in question) is not currently taken in account by Cabal. Making Cabal understand how to generate documentation for all those formats would probably be too ambitious, but it could be eased (e.g. letting the user provide Makefiles instead of creating custom hooks). More importantly, the installation of documentation would be much easier with a new package property such as "doc-files" ("data-files" nor "extra- source-files" are semantically suitable). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/330> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #325: SHGetFolderPath requiered to configure cabal 1.4
by Hackage 30 Jun '09

30 Jun '09

#325: SHGetFolderPath requiered to configure cabal 1.4 ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- i try to install cabal with ghc 6.8.3 on XP. i get the error message GHCi could not find the following symbols SHGetFolderPath i saw some old bugs mentioning this problem - what is a current fix? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/325> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #273: Provide a stable address for current Haddock documentation
by Hackage 11 Jun '09

11 Jun '09

#273: Provide a stable address for current Haddock documentation ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- Documentation for version 0.1.1 of the Derive package is at http://hackage.haskell.org/packages/archive/derive/0.1.1/doc/html/ - but as soon as I upload a new version any documentation links will become out of date. It would be very useful if there was a stable URL where the documentation of the latest version of a package could be found. -- Neil Mitchell -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/273> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #318: Library cannnot be used when registered in-place on OS X
by Hackage 08 Jun '09

08 Jun '09

#318: Library cannnot be used when registered in-place on OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Mac OS | ---------------------------------+------------------------------------------ I built and registered a library --inplace using cabal-install on Mac OS X 10.5.4 using cabal-install 0.5.1 and Cabal 1.4.0.1. I was unable to then use the package afterwards. It failed at link-time with: {{{ Linking Main ... ld: in /... blah .../lib/dist/build/lib-0.1.a, archive has no table of contents collect2: ld returned 1 exit status }}} After talking to Beelsebob and dcoutts on #haskell, I used '''ranlib''' on lib-0.1.a, and it worked. According to dcoutts: "it's because we run ranlib when we install it, but not when we first generate it." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/318> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 14