January 2009 - cabal-devel

[Hackage] #348: Wrong login details for `cabal upload' is not handled gracefully
by Hackage 12 Jan '09

12 Jan '09

#348: Wrong login details for `cabal upload' is not handled gracefully ----------------------------+----------------------------------------------- Reporter: chrisdone | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Example: [[BR]] chris@chrisdesktop:~/haskell/lojban$ cabal upload dist/lojban-0.0.tar.gz[[BR]] Hackage username: foo[[BR]] Hackage password: bar[[BR]] Uploading dist/lojban-0.0.tar.gz...[[BR]] cabal: bsAuthGen wanted -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/348> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #450: Bug in GLUT's build: configure
by Hackage 11 Jan '09

11 Jan '09

#450: Bug in GLUT's build: configure ----------------------------+----------------------------------------------- Reporter: Peaker | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: major | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- This is a glut package bug, but I could not find any web page with which to report glut bugs, so I am hoping this here will get to the right people. GLUT's build has a configure script. When that script says: "libGLUT... yes/no" its not actually looking just for libGLUT, but for various other libs such as libXmu. Additionally, when it fails to find these other libraries, and gets a "no", it still finishes the configure and build "successfully", but without the proper -l flags in the package description. This results in linkage failures of GLUT programs later. In my opinion the fix should include: A. Look for libXmu and any other such library in a separate configure item, so its clear what's missing. B. Failure to find necessary libraries should fail the configure/build/install, and not continue as if successful, only to fail later. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/450> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): On Windows, if gcc isn't where we expect it then keep looking
by Ian Lynagh 09 Jan '09

09 Jan '09

Fri Jan 9 07:35:07 PST 2009 Ian Lynagh <igloo(a)earth.li> * On Windows, if gcc isn't where we expect it then keep looking M ./Distribution/Simple/GHC.hs -2 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090109153507-3fd76-60348692…

1 0

[Hackage] #444: Simple builds ignore .buildinfo
by Hackage 07 Jan '09

07 Jan '09

#444: Simple builds ignore .buildinfo ----------------------------+----------------------------------------------- Reporter: awick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- It would be convenient if Simple builds would look for buildinfo files, instead of just ignoring them. It's sometimes convenient to have the configure script run as a separate phase (for example, when you're configuring a bunch of separate cabal packages) instead of re-running the same configure tests every time, and this would help. There's an obvious workaround (setting the type to 'Configure' and then adding an empty 'configure' script), but this is tedious. I've attached a simple example. The .buildinfo file tells Cabal to build Test2 in addition to Test1. If you set the type to Simple, it only builds Test1. If you set it to 'Configure', it runs the empty configure script and then builds both Test1 and Test2. It'd be nicer if 'Simple' caused both Test1 and Test2 to be built, as well. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/444> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #441: cabal update does not update dependent components
by Hackage 07 Jan '09

07 Jan '09

#441: cabal update does not update dependent components ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ When I run `cabal update` it updates one-or-more package(s). But does not rebuild/reinstall dependent packages. It must be done manually. I think it would be part of the job. (As I saw it in the ''gentoo world''. :)) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/441> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #440: cabal update ignores configured haddock
by Hackage 07 Jan '09

07 Jan '09

#440: cabal update ignores configured haddock ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ When I run `cabal update` it refresh the packages, but does not generate the haddock documentation. This is what i have in the {{{~/.cabal/config}}} file: {{{ .. documentation: True }}} This is what i got in the {{{~/.cabal/packages/hackage.haskell.org/build- reports.log}}} file: {{{ .. install-outcome: InstallOk docs-outcome: NotTried }}} If I rerun the `cabal install <pkg> --reinstall` command, it generates the documentation right. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/440> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #342: Allow automatic resolving of conditionals on more than just build-depends
by Hackage 07 Jan '09

07 Jan '09

#342: Allow automatic resolving of conditionals on more than just build-depends -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the `build-depends` field. The others are: * C libs (`extra-libraries`) * C headers (`includes`) * other build tools (`build-tools`) * pkg-config packages (`pkgconfig-depends`) * MacOS X frameworks (`frameworks`) And we may end up with more, like Windows assemblies. If we know (by domain-specific means) what dependencies are available then we should be able to automatically resolve flag conditions that depend on them. So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too. Currently `finalizePackageDescription` takes a `Maybe (PackageSet pkg)` as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what `finalizePackageDescription` turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for `Dependency -> [PackageId]` but how should we do it when we have multiple namespaces and some require version constraints and others do not. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/342> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #443: remove package
by Hackage 05 Jan '09

05 Jan '09

#443: remove package ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Remove package now is a handy work. (Register out from ghc-pkg and remove the files.) I expect a `cabal uninstall` command, which might warn me if a dependent package is still on the machine. (Just mention one advantage of not make it by hand.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/443> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1