[Hackage] #150: haddock docs are installed insensibly in Windows
#150: haddock docs are installed insensibly in Windows ---+ Reporter: eivuokko |Owner: ijones Type: defect| Status: new Priority: normal|Milestone: Component: Cabal | Version: 1.1.6 Severity: normal| Keywords: Ghcversion: 6.4.2 | Difficulty: normal Platform: Windows | ---+ Haddock docs are not installed sensibly in Windows. They go under Common Files, which is silly; Their path doesn't contain compiler version, which makes it hard to install docs for same package version installed for different compilers/versions and they are not relocatable because * default uses absolute paths for references * with a lot of work they can refer to each other via relative paths, but ghc installation isn't installed in similar fashion. And then all packages must also be installed into same prefix. (ie user-only vs admin installs) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/150 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #55: should cabal-upload be a thin wrapper on cabal-install?
#55: should cabal-upload be a thin wrapper on cabal-install? ---+ Reporter: ijones|Owner: ijones Type: enhancement | Status: new Priority: normal|Milestone: Cabal-1.4 Component: cabal-upload | Version: Severity: normal| Resolution: Keywords:| Ghcversion: 6.2.1 Difficulty: normal| Platform: Linux ---+ Changes (by duncan): * component: cabal-get = cabal-upload * summary: should cabal-put be a thin wrapper on cabal-install = should cabal-upload be a thin wrapper on cabal- install? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/55 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #60: make cabal-get-bootstrap release
#60: make cabal-get-bootstrap release +--- Reporter: ijones |Owner: ijones Type: task | Status: new Priority: normal |Milestone: Cabal-1.2 Component: cabal-install | Version: Severity: major | Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: normal | Platform: Linux +--- Changes (by duncan): * component: cabal-get = cabal-install Comment: This is terribly out of date. But we should have a cabal-install release. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/60 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #64: enhance cabal-get to perform local installation tasks
#64: enhance cabal-get to perform local installation tasks +--- Reporter: ijones |Owner: ijones Type: enhancement| Status: new Priority: normal |Milestone: Component: cabal-install | Version: Severity: major | Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: hard | Platform: Linux +--- Changes (by duncan): * component: cabal-get = cabal-install -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/64 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #71: cabal-get should install packages locally
#71: cabal-get should install packages locally +--- Reporter: ijones |Owner: ijones Type: defect | Status: closed Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: invalid Keywords: | Ghcversion: 6.4.2 Difficulty: normal | Platform: Linux +--- Changes (by duncan): * component: cabal-get = cabal-install -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/71 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #5: convert non-preprocessor calls to use Distribution.Program
#5: convert non-preprocessor calls to use Distribution.Program ---+ Reporter: ijones|Owner: duncan Type: task | Status: closed Priority: normal|Milestone: Cabal-1.2 Component: Cabal | Version: Severity: refactor | Resolution: fixed Keywords:| Ghcversion: 6.2.1 Difficulty: normal| Platform: Linux ---+ Changes (by duncan): * resolution: = fixed * status: assigned = closed Comment: Done. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/5 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #63: implement thin tool for installing packages w/ correct version of cabal (cabal-setup)
#63: implement thin tool for installing packages w/ correct version of cabal (cabal-setup) --+- Reporter: ijones |Owner: dcoutts Type: enhancement | Status: new Priority: normal |Milestone: Cabal-1.2 Component: cabal-setup | Version: Severity: major| Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: hard | Platform: Linux --+- Changes (by duncan): * component: Cabal = cabal-setup -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/63 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #55: should cabal-upload be a thin wrapper on cabal-install?
#55: should cabal-upload be a thin wrapper on cabal-install? ---+ Reporter: ijones|Owner: ijones Type: enhancement | Status: new Priority: normal|Milestone: Cabal-1.4 Component: cabal-upload | Version: Severity: normal| Resolution: Keywords:| Ghcversion: 6.2.1 Difficulty: normal| Platform: Linux ---+ Comment (by [EMAIL PROTECTED]): I don't see the connection. cabal-upload is currently a small program that wraps a package in a request to the upload CGI script, while cabal-install fetches the files it needs via HTTP. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/55 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #148: Cabal should be able to produce DLLs in Windows
#148: Cabal should be able to produce DLLs in Windows -+-- Reporter: eivuokko|Owner: ijones Type: enhancement | Status: new Priority: normal |Milestone: Cabal-1.4 Component: Cabal | Version: HEAD Severity: normal | Resolution: Keywords: | Ghcversion: 6.4.2 Difficulty: hard ( 1 day) | Platform: Windows -+-- Changes (by duncan): * difficulty: normal = hard ( 1 day) * milestone: = Cabal-1.4 * version: 1.1.6 = HEAD * type: defect = enhancement Comment: http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html #win32-dlls-create -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/148 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #151: license file is not installed
#151: license file is not installed --+- Reporter: eivuokko |Owner: ijones Type: defect | Status: new Priority: normal |Milestone: Cabal-1.2 Component: Cabal| Version: HEAD Severity: normal | Resolution: Keywords: | Ghcversion: 6.4.2 Difficulty: very easy (1 hour) | Platform: Linux --+- Changes (by duncan): * difficulty: normal = very easy (1 hour) * milestone: = Cabal-1.2 * version: 1.1.6 = HEAD -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/151 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #149: Support for building and linking resource files in Windows
#149: Support for building and linking resource files in Windows --+- Reporter: eivuokko |Owner: ijones Type: enhancement | Status: new Priority: normal |Milestone: Cabal-1.4 Component: Cabal| Version: HEAD Severity: normal | Resolution: Keywords: | Ghcversion: 6.4.2 Difficulty: normal | Platform: Windows --+- Changes (by duncan): * milestone: = Cabal-1.4 * platform: Linux = Windows * version: 1.1.6 = HEAD -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/149 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #38: craft workaround for gentoo which allows them to generate package.conf file but not register
#38: craft workaround for gentoo which allows them to generate package.conf file but not register --+- Reporter: ijones |Owner: ijones Type: enhancement | Status: reopened Priority: high |Milestone: Component: Cabal| Version: Severity: normal | Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: normal | Platform: Linux --+- Changes (by [EMAIL PROTECTED]): * resolution: fixed = * status: closed = reopened Comment: The interface change is not documented in the User's Guide. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/38 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #152: sdist doesn't include install-includes
#152: sdist doesn't include install-includes --+- Reporter: [EMAIL PROTECTED] |Owner: Type: defect | Status: new Priority: high |Milestone: Cabal-1.2 Component: Cabal| Version: HEAD Severity: normal | Resolution: Keywords: | Ghcversion: 6.6 Difficulty: normal | Platform: Linux --+- Changes (by duncan): * milestone: = Cabal-1.2 * priority: normal = high * version: 1.1.6 = HEAD -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/152 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #118: Cabal eats leading '.'s from .cabal file
#118: Cabal eats leading '.'s from .cabal file
-+--
Reporter: [EMAIL PROTECTED] |Owner: ijones
Type: defect | Status: new
Priority: high|Milestone:
Component: Cabal | Version: 1.1.6
Severity: normal | Resolution:
Keywords: | Ghcversion: 6.6
Difficulty: normal | Platform: Linux
-+--
Changes (by duncan):
* priority: normal = high
Comment:
Yes, this is bad. It just bit me too in HEAD. I was using:
Library {
include-dirs: .
}
and that gets striped to nothing, which means we pass -I to ghc with no
following path (which makes ghc complain).
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/118
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #97: Should not create empty directories in setup install/copy
#97: Should not create empty directories in setup install/copy -+-- Reporter: duncan |Owner: ijones Type: defect | Status: closed Priority: low |Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Ghcversion: 6.4.2 Difficulty: normal | Platform: Mac OS -+-- Changes (by duncan): * resolution: = fixed * status: new = closed Comment: The include dir will now only be made and noted in the package registration info if we actually install some include files. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/97 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #41: convert 'tar' call in SrcDist.hs to use Distribution.Program
#41: convert 'tar' call in SrcDist.hs to use Distribution.Program -+-- Reporter: ijones |Owner: ijones Type: task| Status: closed Priority: normal |Milestone: Component: Cabal | Version: Severity: normal | Resolution: fixed Keywords: | Ghcversion: 6.2.1 Difficulty: easy| Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: new = closed Comment: Done. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/41 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #151: license file is not installed
#151: license file is not installed --+- Reporter: eivuokko |Owner: ijones Type: defect | Status: closed Priority: normal |Milestone: Cabal-1.2 Component: Cabal| Version: HEAD Severity: normal | Resolution: fixed Keywords: | Ghcversion: 6.4.2 Difficulty: very easy (1 hour) | Platform: Linux --+- Changes (by duncan): * resolution: = fixed * status: new = closed Comment: Done. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/151 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #118: Cabal eats leading '.'s from .cabal file
#118: Cabal eats leading '.'s from .cabal file
-+--
Reporter: [EMAIL PROTECTED] |Owner: ijones
Type: defect | Status: new
Priority: high|Milestone:
Component: Cabal | Version: 1.1.6
Severity: normal | Resolution:
Keywords: | Ghcversion: 6.6
Difficulty: normal | Platform: Linux
-+--
Comment (by nominolo):
The . - problem is a problem in filepath, not necessarily Cabal.
The problem is that it calls {{{normalize}}} which does this (IMO) illegal
transformation. A normalized path should always work. I think Neil fixed
this in the latest (unreleased) filepath, I haven't tested though. The
problem described in the original report should be fixed, though it's sad
we do not seem to have regression tests for this one.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/118
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #118: Cabal eats leading '.'s from .cabal file
#118: Cabal eats leading '.'s from .cabal file -+-- Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect | Status: closed Priority: high|Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Ghcversion: 6.6 Difficulty: normal | Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: new = closed Comment: Now fixed by not using normalize in a few places. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/118 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #150: haddock docs are not relocatable in Windows
#150: haddock docs are not relocatable in Windows -+-- Reporter: eivuokko|Owner: ijones Type: defect | Status: new Priority: normal |Milestone: Cabal-1.4 Component: Cabal | Version: HEAD Severity: normal | Resolution: Keywords: | Ghcversion: 6.4.2 Difficulty: hard ( 1 day) | Platform: Windows -+-- Changes (by duncan): * difficulty: very easy (1 hour) = hard ( 1 day) * milestone: Cabal-1.2 = Cabal-1.4 * priority: high = normal * summary: haddock docs are installed insensibly in Windows = haddock docs are not relocatable in Windows Comment: The default location has been improved. It doesn't contain the compiler however. But you can override that with --docdir=... Changing summary, priority difficulty to reflect the remaining part of the problem. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/150 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #7: add --ghc-args and such to configure
#7: add --ghc-args and such to configure
--+-
Reporter: ijones |Owner: ijones
Type: enhancement | Status: closed
Priority: high |Milestone: Cabal-1.2
Component: Cabal| Version: 1.1.3
Severity: normal | Resolution: fixed
Keywords: | Ghcversion: 6.2.1
Difficulty: very easy (1 hour) | Platform: Linux
--+-
Changes (by duncan):
* resolution: = fixed
* status: reopened = closed
Comment:
Now documented.
Also, I've added a {{{--prog-arg=}}} flag that behaves like
{{{--configure-option=}}}.
I've also made {{{--prog-args=}}} parse it's args more cleverly. Instead
of using words which breaks on files with embedded spaces we now use a
slightly more clever lexer that allows simple quoting with chars. eg:
{{{
splitArgs --foo=\C:\Program Files\Bar\ --baz
= [--foo=C:\Program Files\Bar, --baz]
}}}
so on the command line you'd use:
{{{
./setup configure --foo-args='--bar=some path with spaces'
}}}
That is the chars have to be passed to setup, so if necessary they have
to be escaped in the shell invocation.
The alternative of course is to use
{{{
./setup configure --foo-arg=--bar=some path with spaces
}}}
again, assuming your shell parses {{{--foo-arg=--bar=some path with
spaces}}} into a single argument {{{--foo-arg=--bar=some path with
spaces}}}.
Oh the joys of shell quoting.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/7
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #27: Document configurations syntax
#27: Document configurations syntax +--- Reporter: Simon Marlow [EMAIL PROTECTED] |Owner: nominolo Type: enhancement| Status: new Priority: high |Milestone: Cabal-1.2 Component: Cabal | Version: Severity: normal | Resolution: Keywords: | Difficulty: very easy (1 hour) Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by duncan): * difficulty: very hard = very easy (1 hour) * milestone: Cabal-1.4 = Cabal-1.2 * summary: Configurations = Document configurations syntax Comment: Configurations are now implemented, the latest syntax needs to be documented in the user guide. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/27 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #141: Cabal throws an ugly irrefutable pattern match failed error when confronted to an empty .cabal descriptor
#141: Cabal throws an ugly irrefutable pattern match failed error when
confronted to an empty .cabal descriptor
--+-
Reporter: mnislaih |Owner: mnislaih
Type: defect | Status: closed
Priority: low |Milestone:
Component: Cabal| Version: HEAD
Severity: minor| Resolution: fixed
Keywords: | Ghcversion: 6.6
Difficulty: very easy (1 hour) | Platform: Mac OS
--+-
Changes (by duncan):
* resolution: = fixed
* status: new = closed
Comment:
We now get
{{{
setup: Warning: No library or executable specified
Configuring ...
setup: Warning: No executables and no library found. Nothing to do.
setup: Warning: No exposed modules or executables in this package.
setup: Warning: No license-file field.
setup: Error: Missing field: name
setup: Error: Missing field: version
}}}
I suppose it could be better yet.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/141
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #153: Cabal makes empty data directories
#153: Cabal makes empty data directories
-+--
Reporter: guest |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal | Version: 1.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.4.2
Platform: Linux |
-+--
In http://www.haskell.org/pipermail/cvs-ghc/2007-September/038121.html
Sven writes:
{{{
The current Cabal used for building GHC has a small bug, it *always*
creates
the data directory, even if there are no data files in the package. Simple
fix:
*** /tmp/Install.hs 2007-09-09 14:56:50.0 +0200
--- Distribution/Simple/Install.hs 2007-09-09 12:57:21.0
+0200
***
*** 115,121
(putStrLn (directory ++ haddockPref pkg_descr ++
does exist: ++ show docExists))
when (dataFilesExist || docExists) $ do
- createDirectoryIfMissingVerbose verbosity True dataPref
flip mapM_ (dataFiles pkg_descr) $ \ file - do
let dir = takeDirectory file
createDirectoryIfMissingVerbose verbosity True (dataPref / dir)
--- 115,120
Nothing substantial, but this leads to lots of useless empty directories
when
GHC is installed. Feel free to apply this fix in the right repository...
(No
idea which)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/153
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #153: Cabal makes empty data directories
#153: Cabal makes empty data directories -+-- Reporter: guest |Owner: Type: defect | Status: closed Priority: normal |Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: new = closed Comment: Applied, thanks. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/153 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #104: setup install should configure and build if necessary
#104: setup install should configure and build if necessary -+-- Reporter: guest |Owner: ijones Type: task| Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (4 hours) Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * milestone: Cabal-1.2 = Comment: I'm not sure if cabal-install reduces the desire for this feature. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/104 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #24: Cabal shouldn't try to build GHCI libs on platforms without GHCI
#24: Cabal shouldn't try to build GHCI libs on platforms without GHCI
+---
Reporter: [EMAIL PROTECTED] |Owner: ijones
Type: defect | Status: new
Priority: normal |Milestone: Cabal-1.4
Component: Cabal | Version:
Severity: normal | Resolution:
Keywords: | Difficulty: hard
Ghcversion: 6.2.1 | Platform: Linux
+---
Changes (by duncan):
* ghcversion: = 6.2.1
* milestone: Cabal-1.2 = Cabal-1.4
* platform: = Linux
Comment:
ghc-6.8 has a flag that tells us various features about the ghc
installation. I think that the ghci support is one of these things. So we
could support this feature in ghc-6.8 and later.
If we do this, should we drop the existing --disable-library-for-ghci
flag? We could keep it if we tried the {{{ghc -e return ()}}}
suggestion.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/24
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #154: Cabal doesn't clean _stub files
#154: Cabal doesn't clean _stub files
-+--
Reporter: judahj |Owner:
Type: defect | Status: new
Priority: normal |Milestone: Cabal-1.2
Component: Cabal | Version: 1.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.6
Platform: Mac OS |
-+--
Running runhaskell Setup.hs clean doesn't clean _stub.{c,h} files in
Cabal-1.2.0. It does in 1.1.6.2.
The -stubdir flag might be useful here (introduced in ghc-6.6) for having
them created in the dist/build directory. (In both 1.2.0 and 1.1.6.2,
they're created next to the source .hs files.)
Related: [542].
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/154
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #155: show . readPackageDescription /= id
#155: show . readPackageDescription /= id
+---
Reporter: [EMAIL PROTECTED] |Owner: nominolo
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal | Version: HEAD
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.6
Platform: Linux |
+---
Hi,
if find the following a bit confusing:
Read and then print a cabal file (old style without configurations is
enough):
{{{
pkg - readPackageDescription normal foo.cabal -- :: IO
GenericPackageDescription
print pkg
}}}
That output is then not parsable by readPackageDescription, error:
{{{
Test.hs: foo-copy.cabal26: Parse of field 'executable' failed:
}}}
It seems that the Show instance of GenericPackageDescription generates a
string where the executables' entries cannot be parsed again.
Cheers,
Lennart K
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/155
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #134: Clean up hooks
#134: Clean up hooks -+-- Reporter: guest |Owner: ijones Type: task| Status: new Priority: high|Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: very hard (1 week) Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * difficulty: normal = very hard (1 week) * milestone: = Cabal-1.4 * type: defect = task -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/134 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
#98: cabal assumes -x option for linking +--- Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect | Status: new Priority: normal |Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (4 hours) Ghcversion: 6.6| Platform: Other Unix +--- Changes (by duncan): * difficulty: normal = easy (4 hours) * milestone: = Cabal-1.4 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #133: sdist and clean should never be given Maybe LocalBuildInfo
#133: sdist and clean should never be given Maybe LocalBuildInfo -+-- Reporter: guest |Owner: ijones Type: task| Status: new Priority: high|Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: hard ( 1 day) Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * difficulty: normal = hard ( 1 day) * milestone: = Cabal-1.4 * type: defect = task Comment: See also bug #134 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/133 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #103: feature request: preprocess files with ghc before haddock?
#103: feature request: preprocess files with ghc before haddock? ---+ Reporter: [EMAIL PROTECTED] |Owner: ijones Type: enhancement | Status: new Priority: normal|Milestone: Component: Cabal | Version: 1.1.6 Severity: normal| Resolution: Keywords:| Difficulty: normal Ghcversion: 6.6 | Platform: Linux ---+ Comment (by duncan): I don't think this is possible because ghc never gives us the source code output of top level TH splices, so there's no source that we can actually pass to haddock. Perhaps with haddock 2.0 using ghc more intimately this may become possible. In either case I think it's not something we can fix in Cabal. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/103 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #125: running Haddock with different options not possible
#125: running Haddock with different options not possible -+-- Reporter: [EMAIL PROTECTED] |Owner: ijones Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -+-- Comment (by duncan): There is now a configure --haddock-options flag that passes extra flags to haddock. Does this help at all? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/125 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #154: Cabal doesn't clean _stub files
#154: Cabal doesn't clean _stub files -+-- Reporter: judahj |Owner: Type: defect | Status: closed Priority: normal |Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Mac OS -+-- Changes (by duncan): * resolution: = fixed * status: new = closed Comment: Fixed, for ghc-6.6 and later at least by using -stubdir. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/154 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #125: running Haddock with different options not possible
#125: running Haddock with different options not possible -+-- Reporter: [EMAIL PROTECTED] |Owner: ijones Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -+-- Comment (by [EMAIL PROTECTED]): Cabal already runs haddock over all the modules, but it adds --hide options for the other modules. It would certainly be possible to add an option to turn that off. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/125 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #125: running Haddock with different options not possible
#125: running Haddock with different options not possible
-+--
Reporter: [EMAIL PROTECTED] |Owner: ijones
Type: enhancement | Status: new
Priority: normal |Milestone:
Component: Cabal | Version: 1.1.6
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.6 | Platform: Linux
-+--
Comment (by [EMAIL PROTECTED]):
This does help, indeed.
However, there is a related problem. If I want to build a documentation
for developers which exposes all private things, it is not enough to run
Haddock with {{{--ignore-all-exports}}}. Cabal has to run Haddock on all
modules of the package, not just the modules which are exposed. Could
such a feature be implemented as well?
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/125
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #125: running Haddock with different options not possible
#125: running Haddock with different options not possible -+-- Reporter: [EMAIL PROTECTED] |Owner: ijones Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -+-- Comment (by duncan): So can we open a new bug for that feature request and close this bug now? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/125 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #156: setup haddock: option to expose all modules
#156: setup haddock: option to expose all modules --+- Reporter: [EMAIL PROTECTED] |Owner: Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal| Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux| --+- (Requested by [EMAIL PROTECTED]) If I want to build a documentation for developers which exposes all private things, it is not enough to run Haddock with `--ignore-all- exports`. Cabal already runs haddock over all the modules, but it adds `--hide` options for modules that are not exposed. Could there be an option to turn this off, so that all modules appear in the documentation? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/156 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #125: running Haddock with different options not possible
#125: running Haddock with different options not possible -+-- Reporter: [EMAIL PROTECTED] |Owner: ijones Type: enhancement | Status: closed Priority: normal |Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -+-- Changes (by [EMAIL PROTECTED]): * resolution: = fixed * status: new = closed Comment: new request opened as #156 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/125 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #156: setup haddock: option to expose all modules
#156: setup haddock: option to expose all modules --+- Reporter: [EMAIL PROTECTED] |Owner: Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal| Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux --+- Changes (by [EMAIL PROTECTED]): * cc: = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/156 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #157: Haddock command fails when dependent documentation is not installed
#157: Haddock command fails when dependent documentation is not installed
--+-
Reporter: duncan |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal| Version: 1.2.0
Severity: normal | Keywords:
Difficulty: easy (4 hours) | Ghcversion: 6.4.2
Platform: Linux|
--+-
Cabal checks with ghc-pkg for where the .haddock file of dependent
packages should be. However even though ghc-pkg says it's there, it very
often isn't there. In this case we still ask haddock to use it, and
haddock justifiably complains.
Cabal should check that the .haddock file actually exists. If it does not,
Cabal should warn that links to this dependent package will not be
generated because the docs for this dependent package are not installed.
It should then not tell haddock to use that package.
Current behavior:
{{
$ runghc Setup.lhs haddock
Preprocessing library bytestring-0.9...
Running Haddock for bytestring-0.9...
haddock: /usr/share/doc/ghc-6.4.2/html/libraries/base/base.haddock:
openBinaryFile: does not exist (No such file or directory)
}}
Desired behavior:
{{
$ runghc Setup.lhs haddock
Preprocessing library bytestring-0.9...
Running Haddock for bytestring-0.9...
Warning: Documentation for package base is not installed. No links will be
generated.
Documentation created: dist/doc/html/bytestring/index.html
}}
Or something like that, I'm sure someone can think of a clear friendly
warning message
This should be an easy bug for some new Cabal hacker to have a go at. It
should just require modifying makeReadInterface in the
Distribution.Simple.Haddock module.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/157
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #157: Haddock command fails when dependent documentation is not installed
#157: Haddock command fails when dependent documentation is not installed -+-- Reporter: duncan |Owner: Type: defect | Status: closed Priority: normal |Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (4 hours) Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: new = closed -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/157 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #14: allow preprocessing for Main modules
#14: allow preprocessing for Main modules -+-- Reporter: ijones |Owner: duncan Type: defect | Status: closed Priority: high|Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: assigned = closed -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/14 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #158: if os(windows) does not work
#158: if os(windows) does not work
--+-
Reporter: duncan |Owner:
Type: defect | Status: new
Priority: high |Milestone: Cabal-1.2
Component: Cabal| Version: 1.2.0
Severity: normal | Keywords:
Difficulty: easy (4 hours) | Ghcversion: 6.4.2
Platform: Linux|
--+-
The {{{os}}} condition currently uses the {{{System.Info.os :: String}}}
to check if we're on the OS specified. This is bad and wrong since in GHC
at least on Windows this string is {{{mingw32}}}. For configurations
it's ok if this works:
{{{
if os(mingw32)
blah
}}}
but it's essential that this works:
{{{
if os(windows)
blah
}}}
At a bare minimum we should add an alias system, such that we can specify
{{{windows}}} and {{{solaris}}} rather than the cryptic {{{mingw32}}} and
{{{solaris2}}}. I suggest that comparisons also be case insensetive.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/158
Hackage http://example.com/
My example project___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #158: if os(windows) does not work
#158: if os(windows) does not work -+-- Reporter: duncan |Owner: Type: defect | Status: closed Priority: high|Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (4 hours) Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * status: new = closed * resolution: = fixed Comment: Fixed in Cabal HEAD. Should get moved to the 1.2 branch soon. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/158#comment:1 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #63: implement thin tool for installing packages w/ correct version of cabal (cabal-setup)
#63: implement thin tool for installing packages w/ correct version of cabal (cabal-setup) --+- Reporter: ijones |Owner: duncan Type: enhancement | Status: assigned Priority: normal |Milestone: Cabal-1.2 Component: cabal-setup | Version: Severity: major| Resolution: Keywords: | Difficulty: hard Ghcversion: 6.2.1| Platform: Linux --+- Changes (by duncan): * status: new = assigned * owner: dcoutts = duncan Comment: cabal-install works pretty well now I think. I've been using it for a while now. We just need to make a release of it along with Cabal-1.2 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/63#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #155: show . readPackageDescription /= id
#155: show . readPackageDescription /= id
+---
Reporter: [EMAIL PROTECTED] |Owner: nominolo
Type: defect | Status: assigned
Priority: normal |Milestone:
Component: Cabal | Version: HEAD
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.6| Platform: Linux
+---
Changes (by nominolo):
* status: new = assigned
Comment:
Well, first of all, we didn't have that property before. The counterpart
to {{{show}}} is {{{read}}}, not {{{readFoo}}}. We did however have the
property:
{{{
prop_idempParsePrint x = (r . s . r) x == r x
where r = readPackageDescription; s = showPackageDescription
}}}
I agree that this would be nice to have, though.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/155#comment:1
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #60: make cabal-get-bootstrap release
#60: make cabal-get-bootstrap release +--- Reporter: ijones |Owner: ijones Type: task | Status: closed Priority: normal |Milestone: Cabal-1.2 Component: cabal-install | Version: Severity: major | Resolution: invalid Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by duncan): * status: new = closed * resolution: = invalid Comment: This is so out of date it's irrelevant. What we need is a cabal-install release. This will not be bundled with ghc-6.8.1 as it's not ready. We'll do an independent release after ghc-6.8.1 and Cabal-1.2.0.x are out. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/60#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #62: implement new age cabal-get/put in order to make it possible to distribute cabal-get w/ cabal
#62: implement new age cabal-get/put in order to make it possible to distribute cabal-get w/ cabal +--- Reporter: ijones |Owner: ijones Type: task | Status: closed Priority: normal |Milestone: Cabal-1.2 Component: cabal-install | Version: Severity: major | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by duncan): * status: new = closed * resolution: = fixed Comment: Hackage is working well. cabal-install will be released some time after ghc-6.8.1. It will not be included in the Cabal package since it has more dependencies than the Cabal library. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/62#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #27: Document configurations syntax
#27: Document configurations syntax +--- Reporter: Simon Marlow [EMAIL PROTECTED] |Owner: nominolo Type: enhancement| Status: new Priority: high |Milestone: Cabal-1.2 Component: Cabal | Version: Severity: normal | Resolution: Keywords: | Difficulty: very easy (1 hour) Ghcversion: 6.2.1 | Platform: Linux +--- Comment (by duncan): I'm part way through doing this. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/27#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #155: show . readPackageDescription /= id
#155: show . readPackageDescription /= id +--- Reporter: [EMAIL PROTECTED] |Owner: nominolo Type: defect | Status: assigned Priority: normal |Milestone: Component: Cabal | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Comment (by duncan): This works now I think. Can someone check it and close this bug please. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/155#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #164: bad error message when using configuration flags that were not defined
#164: bad error message when using configuration flags that were not defined
--+-
Reporter: duncan |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal| Version: 1.2.0
Severity: minor| Keywords:
Difficulty: easy (4 hours) | Ghcversion: 6.4.2
Platform: Linux|
--+-
Using a flag in an if condition when that flag has not been previously
defined gives an unhelpful error message:
{{{
-- flag foo never declared:
if flag(foo)
blah:
else
other:
}}}
We get the error message:
{{{
cabal-setup: Environment not defined for all free vars
}}}
The error is reported by {{{Distribution.Configuration.simplifyCondTree}}}
but the error should probably be checked for much earlier.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/164
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
] ignore|record unused dynamic dependencies [-z initarray=function] name of function to be appended to the .initarray [-z initfirst] mark object to indicate that its .init section should be executed before the .init section of any other objects [-z interpose] dynamic object is to be an `interposer' on direct bindings [-z lazyload | nolazyload] enable|disable delayed loading of shared object dependencies [-z ld32=arg1,arg2,...] define arguments applicable to the 32-bit class of ld(1) [-z ld64=arg1,arg2,...] define arguments applicable to the 64-bit class of ld(1) [-z loadfltr] mark filter as requiring immediate loading of its filtees at runtime [-z muldefs]allow multiply-defined symbols [-z nocompstrtab] disable compression of string tables [-z nodefs] allow undefined symbol references [-z nodefaultlib] mark object to ignore any default library search path [-z nodelete] mark object as non-deletable [-z nodlopen] mark object as non-dlopen()'able [-z nodump] mark object as non-dldump()'able [-z now]mark object as requiring non-lazy binding [-z nopartial] expand any partially initialized symbols [-z noversion] don't record any version sections [-z origin] mark object as requiring $ORIGIN processing [-z preinitarray=function] name of function to be appended to the .preinitarray [-z redlocsym] reduce local syms in .symtab to a minimum [-z rescan] rescan archive list until no further member extraction occurs [-z text] disallow output relocations against text [-z textoff]allow output relocations against text [-z textwarn] warn if there are relocations against text [-z verbose]generate warnings for suspicious processings gmake[2]: *** [dist/build/HSbase-3.0.o] Error 1 }}} I could continue with a gnu linker only after cleaning up completely. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
#98: cabal assumes -x option for linking ---+ Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect| Status: new Priority: normal|Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal| Resolution: Keywords:| Difficulty: easy (4 hours) Ghcversion: 6.6 | Platform: Other Unix ---+ Comment (by guest): Omitting this line works under Solaris. Maybe this explains why my binaries are about 20% bigger. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
#98: cabal assumes -x option for linking ---+ Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect| Status: new Priority: normal|Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal| Resolution: Keywords:| Difficulty: easy (4 hours) Ghcversion: 6.6 | Platform: Other Unix ---+ Comment (by duncan): You misunderstand. The Makefile is generated by Cabal. So it's nothing to do with GHC's configure script and everything to do with Cabal deciding what the appropriate flags are. As it happens because of the Makefile stuff we'll have to fix it in two places in Cabal, once for the ordinary Cabal build stuff and once for where Cabal generates the Makefile. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98#comment:10 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
#98: cabal assumes -x option for linking ---+ Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect| Status: new Priority: normal|Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal| Resolution: Keywords:| Difficulty: easy (4 hours) Ghcversion: 6.6 | Platform: Other Unix ---+ Comment (by duncan): See also http://hackage.haskell.org/trac/ghc/ticket/1786#comment:2 where I describe one route to a fix. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #87: robustify release cabal-get
#87: robustify release cabal-get +--- Reporter: paolo |Owner: paolo Type: task | Status: new Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux +--- Comment (by nominolo): This seems to be obsolete. Can someone check please? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/87#comment:11 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #129: fetch fails without giving user feedback if the requested package does not exist
#129: fetch fails without giving user feedback if the requested package does not
exist
+---
Reporter: mnislaih |Owner: mnislaih
Type: defect | Status: closed
Priority: normal |Milestone:
Component: cabal-install | Version: HEAD
Severity: normal | Resolution: fixed
Keywords: | Difficulty: very easy (1 hour)
Ghcversion: 6.6| Platform: Mac OS
+---
Changes (by nominolo):
* status: assigned = closed
* resolution: = fixed
Comment:
The error message for {{{fetch}}} and {{{install}}} are the same now, in
cabal-install 0.4.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/129#comment:2
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #29: perform package dependency analysis for cabal-install
#29: perform package dependency analysis for cabal-install +--- Reporter: ijones |Owner: ijones Type: enhancement| Status: closed Priority: normal |Milestone: Cabal-1.4 Component: cabal-install | Version: HEAD Severity: normal | Resolution: fixed Keywords: | Difficulty: hard Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by nominolo): * status: new = closed * platform: = Linux * ghcversion: = 6.2.1 * resolution: = fixed Comment: Obsolete. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/29#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #54: if a package is already newest version, avoid downloading and installing it
#54: if a package is already newest version, avoid downloading and installing it +--- Reporter: ijones |Owner: ijones Type: defect | Status: closed Priority: normal |Milestone: Cabal-1.4 Component: cabal-install | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by nominolo): * status: new = closed * resolution: = fixed Comment: Works in cabal-install 0.4 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/54#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #87: robustify release cabal-get
#87: robustify release cabal-get +--- Reporter: paolo |Owner: paolo Type: task | Status: closed Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux +--- Changes (by duncan): * status: new = closed * resolution: = fixed Comment: Yes, this is pretty old. We've deployed hackageDB and made releases of cabal-upload and cabal-install. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/87#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #63: implement thin tool for installing packages w/ correct version of cabal (cabal-setup)
#63: implement thin tool for installing packages w/ correct version of cabal (cabal-setup) --+- Reporter: ijones |Owner: duncan Type: enhancement | Status: closed Priority: normal |Milestone: Cabal-1.2 Component: cabal-setup | Version: Severity: major| Resolution: fixed Keywords: | Difficulty: hard Ghcversion: 6.2.1| Platform: Linux --+- Changes (by duncan): * status: assigned = closed * resolution: = fixed Comment: cabal-setup is released on hackage. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/63#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #135: Epoch Support for Version Numbers
#135: Epoch Support for Version Numbers -+-- Reporter: [EMAIL PROTECTED] |Owner: nominolo Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.1.6 Severity: minor | Resolution: Keywords: | Difficulty: easy (4 hours) Ghcversion: 6.4.2 | Platform: Linux -+-- Comment (by duncan): The downside with this is that every dependency on the new foo-1.0 has to specify foo = 1:1.0. And they have to do this for ever more. There is no way to drop the epoch. It's not clear we want or need this. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/135#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #59: cabal-install should default to --user-install when running as non-root
#59: cabal-install should default to --user-install when running as non-root +--- Reporter: ijones |Owner: ijones Type: defect | Status: new Priority: normal |Milestone: Cabal-1.2 Component: cabal-install | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by duncan): * platform: = Linux * ghcversion: = 6.2.1 Comment: cabal-install-0.4.0 uses user install by default. One has to specify --global to get a global install. The downside is that root also has to specify this to get a global install. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/59#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
#98: cabal assumes -x option for linking ---+ Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect| Status: new Priority: normal|Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal| Resolution: Keywords:| Difficulty: easy (4 hours) Ghcversion: 6.6 | Platform: Other Unix ---+ Comment (by duncan): Latest cabal-1.2.x version has a fix. Can some Solaris user check that it works please? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #98: cabal assumes -x option for linking
#98: cabal assumes -x option for linking ---+ Reporter: [EMAIL PROTECTED] |Owner: ijones Type: defect| Status: closed Priority: normal|Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal| Resolution: fixed Keywords:| Difficulty: easy (4 hours) Ghcversion: 6.6 | Platform: Other Unix ---+ Changes (by guest): * status: new = closed * resolution: = fixed Comment: I could build `ghc-6.8.0.20071025` from the sources, now (after skipping http://hackage.haskell.org/trac/ghc/ticket/1805). Christian -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/98#comment:14 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #167: cabal-install should treat package names case insenitively in the UI wherever possible
#167: cabal-install should treat package names case insenitively in the UI
wherever possible
+---
Reporter: duncan |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
Component: cabal-install | Version: 1.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.4.2
Platform: Linux |
+---
Currently saying {{{cabal list haxml}}} works fine and returns hits for
{{{HaXml}}} which is good. The same does not apply when it comes to
{{{cabal list haxml}}}. So what it should do is to look case-insnesitively
for haxml. If the match is not exact case-sensitively and there are more
than one packages matching case-insensitively then it should abort with a
message listing the matches. This should not often happen since within any
single HackageDB server, we check that packages names are unique case-
insensitively but it's possible to get ambiguities if cabal-install has
been configured to use multiple repos.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/167
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #168: Behaviour of cabal-install with respect to upgradeable packages is unexpected
#168: Behaviour of cabal-install with respect to upgradeable packages is unexpected -+-- Reporter: guest |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | -+-- When an old version of a package is already installed, running cabal- install to install it should install the latest available version of the package, rather than complaining that the package is already installed. (Or at least interactively provide the option to do so.) Having it simply abort without doing anything is strange because in the most common case a user tries to install a package because they need it and do not already have it. If the package is already installed, that probably means that they do not have a recent enough version of the package. It would also make cabal-install more apt-like, which is probably a good thing, considering the obvious inspiration. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/168 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #167: cabal-install should treat package names case insenitively in the UI wherever possible
#167: cabal-install should treat package names case insenitively in the UI wherever possible +--- Reporter: duncan |Owner: Type: enhancement| Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux +--- Comment (by guest): I was under the impression we'd agreed that package names are case insensitive, but that doesn't seem to be written in the obvious place in the Cabal docs. Anyway, I think that foo-1.0 in one hackage and FOO-2.0 in another should be taken to be different versions of the same package. -- Ian Lynagh -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/167#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #167: cabal-install should treat package names case insenitively in the UI wherever possible
#167: cabal-install should treat package names case insenitively in the UI wherever possible +--- Reporter: duncan |Owner: Type: enhancement| Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux +--- Comment (by duncan): As I recall we agreed that hackage should enforce that there be no two packages with names that differ only by case. This was to allow distros to use lower case package names. I do not recall that we agreed to change the Eq instance for packages to make comparison case insensitive (this would have similar implications to redefining version equality in that == does not give the same result as comparing external representations). Currently ghc ghc-pkg treat package names case sensitively. I don't mind changing it to be case insensitive everywhere, but if we do it we should do it everywhere. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/167#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #170: pkg-config uses a more general version scheme
#170: pkg-config uses a more general version scheme
-+--
Reporter: duncan |Owner:
Type: defect | Status: new
Priority: low |Milestone:
Component: Cabal | Version: 1.2.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.4.2
Platform: Linux |
-+--
From {{{HsOpenSSL.cabal}}}
{{{
--PkgConfig-Depends: openssl = 0.9.7l
-- We really should use this instead of the configure
-- script but Cabal 1.2.2.0 can't handle the weird version
-- scheme of OpenSSL.
}}}
For example:
{{{
$ pkg-config --modversion openssl
0.9.8f
}}}
Currently Cabal tries to map pkg-config versions to the standard
{{{Version}}} type which only allows for a sequence of numbers.
pkg-config uses just strings to represent package versions. It uses code
lifted from rpm to compare version strings. See the {{{compare_versions}}}
function in {{{pkg-gconfig-0.22/pkg.c}}} from
http://pkgconfig.freedesktop.org/releases/pkg-config-0.22.tar.gz
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/170
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #160: PatternSignatures missing in Extensions
#160: PatternSignatures missing in Extensions -+-- Reporter: guest |Owner: Type: defect | Status: new Priority: high|Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (1 hour) Ghcversion: 6.6 | Platform: Linux -+-- Comment (by duncan): See also: http://www.haskell.org/pipermail/libraries/2007-November/008542.html which has the full list of extensions that ghc-6.8.1 introduced and which I propose to add to the Language.Haskell.Extensions enumeration. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/160#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #172: cabal-install segfaults
#172: cabal-install segfaults +--- Reporter: guest |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Old description: Using the newest library version on hackage, cabal update segfaults after downloading the package list from hackage. cabal install produces the error cabal: Data.ByteString.Lazy.index: index too large: 0 steps to reproduce the problem (at least for me): install the newest versions of Cabal (1.2.2.0), HTTP (3001.0.0), and zlib (0.4.0.1) from hackage, compile and install cabal-install (0.4.0) from hackage, create a directory called dist (to circumvent another problem with cabal-install), run cabal update, or cabal install New description: Using the newest library version on hackage, cabal update segfaults after downloading the package list from hackage. cabal install produces the error cabal: Data.ByteString.Lazy.index: index too large: 0 steps to reproduce the problem (at least for me): install the newest versions of Cabal (1.2.2.0), HTTP (3001.0.0), and zlib (0.4.0.1) from hackage, compile and install cabal-install (0.4.0) from hackage, create a directory called dist (to circumvent another problem with cabal-install), run cabal update, or cabal install os: Linux arch: i686 ghc: 6.6 zlib: 1.1.4 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/172#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #160: PatternSignatures missing in Extensions
#160: PatternSignatures missing in Extensions -+-- Reporter: guest |Owner: Type: defect | Status: new Priority: high|Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (1 hour) Ghcversion: 6.6 | Platform: Linux -+-- Comment (by guest): The thing is, this particular one is a regression - code that used to compile with Cabal on ghc 6.6.1 can't be compiled with Cabal on ghc 6.8.1, because the shipped Cabal doesn't have the PatternSignatures extension (which you didn't used to have to specify). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/160#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #172: cabal-install segfaults
#172: cabal-install segfaults
+---
Reporter: guest |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: cabal-install | Version:
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.6| Platform: Linux
+---
Old description:
Using the newest library version on hackage, cabal update segfaults
after downloading the package list from hackage. cabal install produces
the error
cabal: Data.ByteString.Lazy.index: index too large: 0
steps to reproduce the problem (at least for me): install the newest
versions of Cabal (1.2.2.0), HTTP (3001.0.0), and zlib (0.4.0.1) from
hackage, compile and install cabal-install (0.4.0) from hackage, create a
directory called dist (to circumvent another problem with cabal-install),
run cabal update, or cabal install
os: Linux
arch: i686
ghc: 6.6
zlib: 1.1.4
New description:
Using the newest library version on hackage, cabal update segfaults
after downloading the package list from hackage. cabal install produces
the error
cabal: Data.ByteString.Lazy.index: index too large: 0
steps to reproduce the problem (at least for me): install the newest
versions of Cabal (1.2.2.0), HTTP (3001.0.0), and zlib (0.4.0.1) from
hackage, compile and install cabal-install (0.4.0) from hackage, create a
directory called dist (to circumvent another problem with cabal-install),
run cabal update, or cabal install
os: Linux[[BR]]
arch: i686[[BR]]
ghc: 6.6[[BR]]
zlib: 1.1.4[[BR]]
Here are the last lines of the output of ltrace cabal update:
{{{
open64(/home/doserj/.cabal/packages/hac..., 2369, 0666) = 4
__fxstat64(3, 4, 0x909108)= 0
fcntl(4, 3, 0x909108, 1, 0x900060)= 34817
fcntl(4, 4, 34817, 1, 0x900060) = 0
__fxstat64(3, 4, 0xbfff8c90) = 0
isatty(4) = 0
ftruncate64(4, 0, 0, 0, 0)= 0
malloc(56)= 0x875aa30
inflateInit2_(0x875aa30, 31, 0x8285868, 56, 0) = -2
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
}}}
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/172#comment:2
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #171: Add command to automagically create an initial cabal package
#171: Add command to automagically create an initial cabal package --+- Reporter: guest|Owner: Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal| Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux --+- Comment (by duncan): What would be even cooler, once we have the dependency chasing infrastructure is to look for local source files and to generate the exposed module list from that, and the package dependencies and the build- tools etc. All it should need to ask for is the name and initial version number. The user could then go and remove modules from the exposed list if they thought there were better private. Indeed it should be possible to tell if it's an executable or a library by checking if there's a Main module. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/171#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #172: cabal-install segfaults
#172: cabal-install segfaults +--- Reporter: guest |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Comment (by duncan): Thanks, so it's clearly a bug in the zlib binding. For one thing we should not be calling inflateInit2 in such a way that it returns an error code and secondly in the situation that it does return an error we should raise an exception and not segfault. So this will require a bit of work, debugging with that version of zlib. As a workaround, you could modify the zlib.cabal package description to always use the bundled zlib-1.2.3 code rather than using the system zlib. Currently it only uses the bundled version on windows. In fact that would be an interesting experiment. My guess is that the behavior is slightly different between the zlib 1.1 and 1.2 series, though obviously it would be good if the zlib binding could work with both versions if that version is still widely deployed. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/172#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #173: cabal install installs files in wrong directory
#173: cabal install installs files in wrong directory
+---
Reporter: guest |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: cabal-install | Version:
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.6
Platform: Linux |
+---
cabal install installs into the directory
{{{
library/package-version/ghc-version/package-version/ghc-version/
}}}
it should probably only be
{{{
library/package-version/ghc-version/
}}}
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/173
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #174: cabal-install tries to upgrade the base package
#174: cabal-install tries to upgrade the base package +--- Reporter: duncan |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | +--- When using ghc-6.6.x, with some packages, cabal-install tries to upgrade the base package to satisfy dependnecies. This is obviously impossible. The dependency resolution mechanism needs to be taught this fact. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/174 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #174: cabal-install tries to upgrade the base package
#174: cabal-install tries to upgrade the base package +--- Reporter: duncan |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Comment (by guest): Replying to [ticket:174 duncan]: When using ghc-6.6.x, with some packages, cabal-install tries to upgrade the base package to satisfy dependnecies. This is obviously impossible. The dependency resolution mechanism needs to be taught this fact. Here's what I tried: $ cabal install fastcgi Data/List.hs:18:1: lexical error at character 'i' $ cabal info fastcgi Requested:fastcgi -any Using: fastcgi-3000.0.0 Depends:base =2.0, cgi =3000.0.0 Options: Location: http://hackage.haskell.org/packages/archive/fastcgi/3000.0.0/fastcgi-3000.0.0.tar.gz Local: *Not downloaded Requested:base =2.0 Installed: base-2.1.1 Requested:cgi =3000.0.0 Using: cgi-3001.1.5.1 Depends:base =3, old-time -any, old-locale -any, containers -any, base =23, network =2.0, parsec =2.0, mtl =1.0, xhtml =3000.0.0 Options: Location: http://hackage.haskell.org/packages/archive/cgi/3001.1.5.1/cgi-3001.1.5.1.tar.gz Local: *Not downloaded Requested:base =3 Using: base-3.0.0.0 Depends: Options: Location: http://hackage.haskell.org/packages/archive/base/3.0.0.0/base-3.0.0.0.tar.gz Local: /home/abram/.cabal/packages/hackage.haskell.org/base/3.0.0.0/base-3.0.0.0.tar.gz Requested:old-time -any Using: old-time-1.0.0.0 Depends:base -any, old-locale -any Options: Location: http://hackage.haskell.org/packages/archive/old- time/1.0.0.0/old-time-1.0.0.0.tar.gz Local: *Not downloaded Requested:base -any Installed: base-2.1.1 Requested:old-locale -any Using: old-locale-1.0.0.0 Depends:base -any Options: Location: http://hackage.haskell.org/packages/archive/old- locale/1.0.0.0/old-locale-1.0.0.0.tar.gz Local: *Not downloaded Requested:containers -any Using: containers-0.1.0.0 Depends:base -any, array -any Options: Location: http://hackage.haskell.org/packages/archive/containers/0.1.0.0/containers-0.1.0.0.tar.gz Local: *Not downloaded Requested:array -any Using: array-0.1.0.0 Depends:base -any Options: Location: http://hackage.haskell.org/packages/archive/array/0.1.0.0/array-0.1.0.0.tar.gz Local: *Not downloaded Requested:base =23 Installed: base-2.1.1 Requested:network =2.0 Installed: network-2.1.0.0 Requested:parsec =2.0 Installed: parsec-2.0 Requested:mtl =1.0 Installed: mtl-1.1.0.0 Requested:xhtml =3000.0.0 Using: xhtml-3000.0.2.1 Depends:base -any Options: Location: http://hackage.haskell.org/packages/archive/xhtml/3000.0.2.1/xhtml-3000.0.2.1.tar.gz Local: *Not downloaded These packages would be installed: base-3.0.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, array-0.1.0.0, containers-0.1.0.0, xhtml-3000.0.2.1, cgi-3001.1.5.1, fastcgi-3000.0.0 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/174#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #174: cabal-install tries to upgrade the base package
#174: cabal-install tries to upgrade the base package +--- Reporter: duncan |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Comment (by duncan): Replying to [comment:2 [EMAIL PROTECTED]: Maybe base-3.0.0.0 should be removed from HackageDB. I don't think that is the problem. Look at the output of cabal info, it thinks cgi depends on two versions of the base lib. It's just flattening the configurations incorrectly. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/174#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #174: cabal-install tries to upgrade the base package
#174: cabal-install tries to upgrade the base package +--- Reporter: duncan |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Comment (by guest): There are a number of issues here: * base should not be in HackageDB, since it is impossible to upgrade it. * The cgi package has been updated to use configurations to work with both base-2 and base-3, but fastcgi hasn't (it is updated in darcs, I just haven't gotten around to uploading it). * cabal-install picks the first working configuration. This has the result that fastcgi which dependes on base = 2.0 is configured to use the ''installed'' base-2.1.1, and cgi which can use either base version is configured to use the ''available'' base-3.0.0. If base was not in HackageDB, cgi would be configured correctly. There is a bug here, but it is not that configurations are flattened incorrectly. Rather, the problem is that cabal-install does not backtrack in the dependency resolution if it encounters an uninstallable package. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/174#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #175: cabal-install needs a new package dependency resolution algorithm
#175: cabal-install needs a new package dependency resolution algorithm +--- Reporter: duncan |Owner: Type: task | Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | +--- The current package dependency algorithm is pretty simple. It's main failing is that it cannot backtrack if it finds the solution is impossible. What we would like is a new dependency resolution algorithm that can backtrack. We would also like to be able to configure policy issues separately, perhaps as a parameter. It may also be handy to let users or the system add extra version constraints. The input is the set of available packages and the output is a list of packages to install, and the assignment of configuration flags to use for each one. As for the policy input, this might take the form of a function that picks between possible dependencies in a slot, this could then allow us to make choices like preferring installed packages over the latest available package version, or vica versa. See also symptoms of the existing system: * bug #168 -- lack of configurable policy * bug #174 -- lack of backtracking -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/175 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #176: Bad verbosity message lacks crucial detail
#176: Bad verbosity message lacks crucial detail --+- Reporter: guest|Owner: Type: enhancement | Status: new Priority: normal |Milestone: Component: Cabal| Version: HEAD Severity: minor| Keywords: Difficulty: very easy (1 hour) | Ghcversion: 6.6 Platform: Windows | --+- I wanted to run Cabal and get the maximum information for a bug report, so I did: runhaskell Setup sdist -v5 Setup: Bad verbosity 5 Which is a fine error message, but adding it to: Setup: Bad verbosity 5 (maximum allowed 3) Would save me doing a linear search to find the maximum value. (GHC version 6.8.1 with HEAD Cabal, but that's not a Trac approved combination) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/176 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows
#177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows
--+-
Reporter: guest|Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal| Version: 1.2.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.6
Platform: Windows |
--+-
Trying to build the HDBC-PostGreSQL database driver[1] revealed some poor
handling of pathames under Windows.
The package requires that the paths to postgre header and libraries files
be added to the .cabal file. My initial attempt was the obvious:
{{{
include-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program
Files\PostgreSQL\8.2\include\server, .
extra-lib-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program
Files\PostgreSQL\8.2\include\server
}}}
However, the package would not build. The include files pg_config.h and
some others were not found. Using single or double quotes did not help.
Finally, I moved the installation to C:\pgsql and updated the .cabal
file:
{{{
include-dirs: C:\pgsql\include, C:\pgsql\include\server, .
extra-lib-dirs: C:\pgsql\lib
}}}
And the package built. It seems the spaces in the first path caused the
problem.
For reference, this it the configure output on my machine:
{{{
Configuring HDBC-postgresql-1.0.1.0...
configure: Dependency base-any: using base-2.1.1
configure: Dependency mtl-any: using mtl-1.0.1
configure: Dependency HDBC=1.0.0: using HDBC-1.0.1
configure: Dependency parsec-any: using parsec-2.0
configure: Using install prefix: C:\Program Files
configure: Binaries installed in: C:\Program Files\Haskell\bin
configure: Libraries installed in: C:\Program Files\Haskell\HDBC-
postgresql-1.0.1.0\ghc-6.6.1
configure: Private binaries installed in: C:\Program Files\HDBC-
postgresql-1.0.1.0
configure: Data files installed in: C:\Program Files\Common Files\HDBC-
postgresql-1.0.1.0
configure: Using compiler: c:\ghc\ghc-6.6.1\bin\ghc.exe
configure: Compiler flavor: GHC
configure: Compiler version: 6.6.1
configure: Using package tool: c:\ghc\ghc-6.6.1\bin\ghc-pkg.exe
configure: Using ar found on system at: c:\ghc\ghc-6.6.1\bin\ar.exe
configure: Using haddock found on system at:
C:\haddock\haddock-0.8\haddock.exe
configure: No pfesetup found
configure: Using ranlib found on system at: c:\MinGW\bin\ranlib.exe
configure: Using runghc found on system at:
c:\ghc\ghc-6.6.1\bin\runghc.exe
configure: Using runhugs found on system at: C:\Program
Files\WinHugs\runhugs.exe
configure: No happy found
configure: No alex found
configure: Using hsc2hs: c:\ghc\ghc-6.6.1\bin\hsc2hs.exe
configure: No c2hs found
configure: No cpphs found
configure: No greencard found
}}}
Feel free to email me at jgbailey AT gmail DOT com for more info.
[1] Version 1.0.1.0 available at http://hackage.haskell.org/cgi-bin
/hackage-scripts/package/HDBC-postgresql-1.0.1.0. HDBC is also required. I
used 1.0.1, available at http://hackage.haskell.org/cgi-bin/hackage-
scripts/package/HDBC-1.0.1.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/177
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows
#177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows
-+--
Reporter: guest |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal | Version: 1.2.2.0
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.6 | Platform: Windows
-+--
Comment (by duncan):
The solution is to use in the field, like:
{{{
include-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program
Files\PostgreSQL\8.2\include\server, .
extra-lib-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program
Files\PostgreSQL\8.2\include\server
}}}
because spaces or ',' are allowed as field separators. Perhaps we should
reconsider this or if we cannot change due to backwards compatability we
could think about a warning. For example we might check if each directory
exists and in the warning message mention that directory names with spaces
have to use s.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/177#comment:1
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #178: register ignores configure's --interfacedir
#178: register ignores configure's --interfacedir ---+ Reporter: [EMAIL PROTECTED] |Owner: Type: defect| Status: closed Priority: normal|Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal| Resolution: fixed Keywords:| Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---+ Changes (by duncan): * status: new = closed * resolution: = fixed Comment: Fix in Cabal HEAD. We can push this one to the 1.2 branch too. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/178#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #178: register ignores configure's --interfacedir
#178: register ignores configure's --interfacedir -+-- Reporter: guest |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux -+-- Comment (by guest): This is under GHC 6.8.1; I didn't notice that option. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/178#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #178: register ignores configure's --interfacedir
#178: register ignores configure's --interfacedir
-+--
Reporter: guest |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal | Version: 1.2.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.4.2
Platform: Linux |
-+--
Create a little fake library directory (I made .../Setup.lhs,
.../testpkg.cabal, and .../TestPkg/Foo.hs).
{{{
ghc --make Setup.lhs -o setup -package Cabal
./setup configure --interfacedir=/
./setup register
cat dist/installed-pkg-config
}}}
This should result in a line saying
{{{
haddock-interfaces: /TestPkg.haddock
}}}
but actually generates
{{{
haddock-interfaces:
/usr/local/share/doc/TestPkg-1.0.0/html/TestPkg.haddock
}}}
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/178
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #178: register ignores configure's --interfacedir
#178: register ignores configure's --interfacedir ---+ Reporter: [EMAIL PROTECTED] |Owner: Type: defect| Status: new Priority: normal|Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal| Resolution: Keywords:| Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---+ Changes (by guest): * reporter: guest = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/178#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #179: support GHC's main-is extension
#179: support GHC's main-is extension
--+-
Reporter: duncan |Owner:
Type: enhancement | Status: new
Priority: normal |Milestone:
Component: Cabal| Version: 1.2.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.4.2
Platform: Linux|
--+-
Query on haskell-cafe: http://haskell.org/pipermail/haskell-
cafe/2007-November/034686.html
{{{
It seems the meaning of the -main-is switch for GHC and the Main-Is
build option for Cabal executables differ. With GHC, I can point to
any function main in any module, but in Cabal I must point to a
filename with precisely the module name Main. This is tying my hands
with regard to organizing a default executable and exposing some of
its functionality as a library. Is there a way to get around this
restriction?
Concretely, I want to point Cabal's Main-Is to Program/Main.hs
which starts with
module Program.Main where
instead of just
module Main where
}}}
So in GHC it has this meaning:
http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html
#options-linker
{{{
-main-is thing
The normal rule in Haskell is that your program must supply a
main function in module Main. When testing, it is often
convenient to change which function is the main one, and
the -main-is flag allows you to do so. The thing can be one of:
A lower-case identifier foo. GHC assumes that the main
function is Main.foo.
An module name A. GHC assumes that the main function
is A.main.
An qualified name A.foo. GHC assumes that the main
function is A.foo.
}}}
In Cabal the {{{main-is:}}} field specifies the '''file name''' of the
Main module.
GHC's {{{-main-is}}} flag is an extension to Haskell that is not supported
by the other Haskell implementations.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/179
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #179: support GHC's main-is extension
#179: support GHC's main-is extension
--+-
Reporter: duncan |Owner:
Type: enhancement | Status: new
Priority: normal |Milestone:
Component: Cabal| Version: 1.2.2.0
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.4.2| Platform: Linux
--+-
Comment (by duncan):
So the question is how would we support this extension? Perhaps by
specifying a module name for {{{main-is:}}} ? Would that be
distinguishable from a file name? It wouldn't have a file extension.
Perhaps it'd be better to be explicit and specify {{{main-module-is:
Foo.Bar}}}.
Note that we do need both a file name and a module name because we have to
pass that file to ghc since it's very common for people to use main
modules that are not called {{{Main.hs}}}.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/179#comment:1
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #180: configure should warn if a declared licence file is missing
#180: configure should warn if a declared licence file is missing
-+--
Reporter: duncan |Owner:
Type: defect | Status: new
Priority: low |Milestone:
Component: Cabal | Version: 1.2.2.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.4.2
Platform: Linux |
-+--
There are a few packages around which declare
{{{
license-file: LICENSE
}}}
but then that LICENSE file actually does not exist. Currently we do not
discover this until we try and install at which point we get the unhelpful
error:
{{{
setup: LICENCE: copyFile: does not exist (No such file or directory)
}}}
It would be much more helpful to users and developers alike if we warned
in the configure step if the file was missing.
This is partly a transitional issue, since older versions of Cabal did not
install license files at all, so it never noticed.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/180
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows
#177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows -+-- Reporter: guest |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Windows -+-- Comment (by [EMAIL PROTECTED]): Yes, this is documented behaviour, and can't be changed because we need to preserve backwards compatibility for the .cabal file format. But I also think space separators are a good thing, both for human editing and machine-generated field values. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/177#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #40: sdist runs tar, which is a problem under Windows
#40: sdist runs tar, which is a problem under Windows -+-- Reporter: ijones |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: normal |Milestone: Component: Cabal | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux -+-- Changes (by [EMAIL PROTECTED]): * summary: how well does sdist work in windows? is there a better way to find 'tar'? = sdist runs tar, which is a problem under Windows Comment: It makes sense to take sdist out of the library, as it's not essential for building, and would work better with these extra dependencies. But I'm not sure about bundling everything in an all-purpose program. Small special-purpose tools have fewer dependencies and avoid many coordination issues. More of them (cabal-deb, cabal-rpm, cabal-msi, etc) can be added by third parties without looking second class. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/40#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #40: sdist runs tar, which is a problem under Windows
#40: sdist runs tar, which is a problem under Windows
-+--
Reporter: ijones |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: normal |Milestone:
Component: Cabal | Version:
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.2.1 | Platform: Linux
-+--
Comment (by duncan):
Replying to [comment:6 [EMAIL PROTECTED]:
It makes sense to take sdist out of the library, as it's not essential
for building, and would work better with these extra dependencies.
Yes.
But I'm not sure about bundling everything in an all-purpose program.
Small special-purpose tools have fewer dependencies and avoid many
coordination issues. More of them (cabal-deb, cabal-rpm, cabal-msi, etc)
can be added by third parties without looking second class.
I don't think it is necessary to bundle everything into one program. I
think it is good to have everything unified under one command from a user
interface point of view. For example we should be able to set things up so
cabal-rpm, cabal-deb etc provide the rpm and deb commands for the cabal
tool.
{{{
$ cabal --help
}}}
should list all commands
{{{
$ cabal rpm
}}}
should call out to cabal-rpm or whatever helper is registered.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/40#comment:7
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #174: cabal-install tries to upgrade the base package
#174: cabal-install tries to upgrade the base package +--- Reporter: duncan |Owner: Type: defect | Status: new Priority: normal |Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6| Platform: Linux +--- Comment (by [EMAIL PROTECTED]): I added base-3.0.0.0 because I hoped to build Hugs with released packages. However the package doesn't work for that purpose, so I've removed it. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/174#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #181: cabal update fails to download package list
#181: cabal update fails to download package list
+---
Reporter: guest |Owner:
Type: defect | Status: new
Priority: normal |Milestone:
Component: cabal-install | Version: HEAD
Severity: major | Keywords: cabal update
Difficulty: normal | Ghcversion: 6.6
Platform: Windows|
+---
cabal update fails to download package list
{{{
cabal update
Downloading package list from server
'http://hackage.haskell.org/packages/archive'
cabal: user error (Codec.Compression.Zlib: premature end of compressed
stream)
cabal install bzlib
cabal: Data.ByteString.Lazy.index: index too large: 0
}}}
WinXp, GHC 6.8, Cabal 1.3.x
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/181
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
[Hackage] #182: Cabal can't find ld.exe on windows
#182: Cabal can't find ld.exe on windows --+- Reporter: guest|Owner: Type: defect | Status: new Priority: normal |Milestone: Component: Cabal| Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Windows | --+- On windows, cabal cannot find ld.exe: D:\private\haskell\MaybeT-0.1.0runghc Setup.hs configure -v3 Configuring MaybeT-0.1.0... Creating dist (and its parents) C:\ghc\ghc-6.8.1\bin\ghc.exe --numeric-version looking for package tool: ghc-pkg near compiler in C:\ghc\ghc-6.8.1\bin found package tool in C:\ghc\ghc-6.8.1\bin\ghc-pkg.exe C:\ghc\ghc-6.8.1\bin\ghc-pkg.exe --version Setup.hs: ld is required but it could not be found. On windows, installator of ghc adds only 'ghc\bin' directory to $PATH but ld.exe (as well as other gcc tools) is to be found in 'ghc\gcc-lib'. if one adds 'ghc\gcc-lib' to $PATH manually then everything works. Refer to this thread on haskell-cafe: http://www.haskell.org/pipermail /haskell-cafe/2007-November/034862.html GHC version 6.8.1 (such an entry in the pull down menu of this bug report does not exist!) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/182 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
