I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again. I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what? What are other Haskell developers here doing currently? kind regards, Dawid Loubser On 12/05/2014 08:49, Nicola Squartini wrote:

http-conduit and its dependencies moved from haskell-happstack to haskell-core and at that time the package release number reset to one. You have to manually uninstall and reinstall those packages.

Nicola

On Sun, May 11, 2014 at 11:49 PM, Michael Katelman mailto:katelman@gmail.com> wrote:

I was hoping someone might help me with an issuing I'm having doing a system upgrade. When I run pacman -Syu, I get:

:: Synchronizing package databases... haskell-core is up to date haskell-happstack is up to date core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than haskell-core (0.8.1.3-2) warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core (0.8.1-2) warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core (0.2.7-1) warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core (0.1.4-1) warning: haskell-connection: local (0.2.1-3) is newer than haskell-core (0.2.1-2) warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core (0.5.2-1) warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than haskell-core (0.0.9-1) warning: haskell-crypto-numbers: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than haskell-core (0.2.4-1) warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than haskell-core (0.4.2.2-1) warning: haskell-crypto-random: local (0.0.7-4) is newer than haskell-core (0.0.7-1) warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than haskell-core (0.2.1.1-2) warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core (2.1.2-2) warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core (0.1.0.4-2) warning: haskell-publicsuffixlist: local (0.1-7) is newer than haskell-core (0.1-2) warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core (0.1.3-1) warning: haskell-socks: local (0.5.4-10) is newer than haskell-core (0.5.4-2) warning: haskell-x509: local (1.4.11-5) is newer than haskell-core (1.4.11-2) warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core (1.4.4-2) warning: haskell-x509-validation: local (1.5.0-9) is newer than haskell-core (1.5.0-2) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: haskell-connection: requires haskell-network=2.4.2.2-60 :: haskell-connection: requires haskell-tls=1.2.6-5 :: haskell-connection: requires haskell-x509=1.4.11-5 :: haskell-connection: requires haskell-x509-store=1.4.4-9 :: haskell-connection: requires haskell-x509-validation=1.5.0-9 :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59 :: haskell-cookie: requires haskell-text=1.1.1.1-1 :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3 :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4 :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2 :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60 :: haskell-http-client-tls: requires haskell-tls=1.2.6-5 :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1 :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2 :: haskell-http-conduit: requires haskell-http-types=0.8.4-4 :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3 :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5 :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1 :: haskell-socks: requires haskell-network=2.4.2.2-60 :: haskell-x509-system: requires haskell-x509=1.4.11-5 :: haskell-x509-system: requires haskell-x509-store=1.4.4-9

I really have no idea what to do with this or what would have caused it. I'm sure it's some important misunderstanding on my part. Any help would be greatly appreciated.

-Mike

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org mailto:arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini wrote:

On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser wrote:

...

I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again.

Normally this should never happen. It's because Haskell is very strict on dependencies (despite being lazy on other things). In this case the reason was that those packages were added to the repository [haskell-core] with initial release number set to 1, although they had been in [haskell-happstack] already for some time and their release number was higher. I removed those immediately from [haskell-happstack] to avoid duplicate work, but they must also be manually removed from local, since pacman always keeps the highest version-release.

In order to avoid this kind of issues in the future we should either have a policy to coordinate work between different haskell repositories, or merge everything into a unique repository and call it simply [haskell].

Indeed. This is entirely my fault! I have not been keeping track of what is available in any other repos at all. I was even under the impression that there were no other maintained repos at the moment. Clearly I am completely wrong :(

...

I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what?

Personally I don't like installing things using cabal-install because in my opinion the distro package manager should always be in charge.

The same goes for me. Occasionally I revert to installing a package for the local user only, but not even then do I use `cabal install` to do that, I prefer running `./Setup.hs configure,build,install` myself. I do mean to look into using `cabal` myself at some point, because I keep on hearing good things about it. So far every time I've tried it I've run into something weird, most recently it was trying to install an older version of a lib than was needed, and I already had the newer version installed on my system too. A lot of terrifyingly clever people swear by it though, so there has to be something I'm missing out on! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On Mon, May 12, 2014 at 4:02 PM, Dawid Loubser wrote:

I'm afraid that I am not one of those 'terrifyingly clever' people you speak of, Magnus, but in the past I have had a world of pain trying to use a mixture of packages between cabal and pacman.

Had a very happy time using just pacman until haskell-buildwrapper disappeared recently, and I could no longer use my favourite Haskell IDE :-( I don't want to even try installing it using cabal, becuase then I'll be back in package-dependency hell.

I have to say, I appreciate your efforts into making Haskell easy to use on Arch so very much - I don't mean to complain at all!

Create a new issue for it on the github page[1], or even better dig into `cblrepo`, add it yourself, and send me a pull request ;) /M [1]: https://github.com/archhaskell/habs/issues -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson wrote:

On 2014-05-12 15:47, Magnus Therning wrote: [--snip--]

...

The same goes for me. Occasionally I revert to installing a package for the local user only, but not even then do I use `cabal install` to do that, I prefer running `./Setup.hs configure,build,install` myself.

I do mean to look into using `cabal` myself at some point, because I keep on hearing good things about it. So far every time I've tried it I've run into something weird, most recently it was trying to install an older version of a lib than was needed, and I already had the newer version installed on my system too. A lot of terrifyingly clever people swear by it though, so there has to be something I'm missing out on!

Gah! Just try it!

All I needed to install build-wrapper (which I think was the inital "problem" package in this thread) was to do

$ mkdir somewhere/buildwrapper $ cd somewhere/buildwrapper $ cabal sandbox init $ cabal install buildwrapper

Add "somewhere/buildwrapper" to $PATH. Bonus points for using "stow" or similar. The key point in the above recipe is to *NOT* have all kinds of libraries installed system-wide (aka. via pacman). It usually works better that way.

Surely you should then `cabal install` the tool so you don't end up with a complete sandbox with every dependency of buildwrapper's in it, no? For some packages you would have to keep the sandbox around and do it your way though, e.g. `pandoc` since it contains both a library and executables.

Disclaimer: I haven't actually used buildwrapper personally, but one assumes that it just acts as an executable and doesn't install things into its own environment or other weird things.

Personally I think `cabal` really shines when doing more serious Haskell development than I do. I never test my Haskell packages on anything other than the GHC that's in [haskell-core], and neither do I test them against any other versions of packages than what's found in [haskell-core]. My Haskell development is completely in my free time and for fun. I think that if I ever am lucky enough find myself using Haskell professionally I'd quickly see more use in what `cabal` has to offer. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On Thu, May 15, 2014 at 05:29:13PM +0200, Bardur Arantsson wrote:

On 2014-05-15 11:35, Magnus Therning wrote:

...

On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson wrote:

...

On 2014-05-12 15:47, Magnus Therning wrote: [--snip--]

All I needed to install build-wrapper (which I think was the inital "problem" package in this thread) was to do

$ mkdir somewhere/buildwrapper $ cd somewhere/buildwrapper $ cabal sandbox init $ cabal install buildwrapper

Add "somewhere/buildwrapper" to $PATH. Bonus points for using "stow" or similar. The key point in the above recipe is to *NOT* have all kinds of libraries installed system-wide (aka. via pacman). It usually works better that way.

Surely you should then `cabal install` the tool so you don't end up with a complete sandbox with every dependency of buildwrapper's in it, no?

You *do* need to keep the sandbox around (or at least parts of it). That's where the last "cabal install" line installs to.

Well, wouldn't you want the binary installed somewhere else, so you don't need to keep the sandbox around? Or do you build all your haskell tools (hlint, hoogle, buildwrapper, hasktags, ghc-mod, etc) in the same sandbox?

...

For some packages you would have to keep the sandbox around and do it your way though, e.g. `pandoc` since it contains both a library and executables.

If you want to use a sandboxed thing as a library then you need to develop "inside" the sandbox, so e.g. you'd just create a little cabal file for your project which declares all the dependencies and use cabal to build your project.

That's indeed the case, but that's *not* the point I was trying to make. If a package only consists of executables you can use the `install` target of the Cabal file to install them. If a package consists of both a library and executables it's more manual work.

...

...

Disclaimer: I haven't actually used buildwrapper personally, but one assumes that it just acts as an executable and doesn't install things into its own environment or other weird things.

Personally I think `cabal` really shines when doing more serious Haskell development than I do. I never test my Haskell packages on anything other than the GHC that's in [haskell-core], and neither do I test them against any other versions of packages than what's found in [haskell-core]. My Haskell development is completely in my free time and for fun. I think that if I ever am lucky enough find myself using Haskell professionally I'd quickly see more use in what `cabal` has to offer.

Cabal also works beautifully for "hobby" type development. Once you've created a cabal file you hardly ever need to touch it again. :)

But it's overkill. Do keep in mind that Cabal and `cabal` are two different things. Of course I use Cabal in all my packages, but I don't use `cabal` at all. The main reason I see for using `cabal` would be when I need to maintain compatibility with multiple versions of GHC and or packages I depend on. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus What gets measured, gets done. -- Tom Peters

Thanks, all! I ultimately did the same thing: removing and re-installing the entire Haskell ecosystem. It seems happy now :) -Mike On Mon, May 12, 2014 at 5:24 AM, Dawid Loubser wrote:

I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again.

I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what?

What are other Haskell developers here doing currently?

kind regards, Dawid Loubser

On 12/05/2014 08:49, Nicola Squartini wrote:

http-conduit and its dependencies moved from haskell-happstack to haskell-core and at that time the package release number reset to one. You have to manually uninstall and reinstall those packages.

Nicola

On Sun, May 11, 2014 at 11:49 PM, Michael Katelman wrote:

...

I was hoping someone might help me with an issuing I'm having doing a system upgrade. When I run pacman -Syu, I get:

:: Synchronizing package databases... haskell-core is up to date haskell-happstack is up to date core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than haskell-core (0.8.1.3-2) warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core (0.8.1-2) warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core (0.2.7-1) warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core (0.1.4-1) warning: haskell-connection: local (0.2.1-3) is newer than haskell-core (0.2.1-2) warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core (0.5.2-1) warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than haskell-core (0.0.9-1) warning: haskell-crypto-numbers: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than haskell-core (0.2.4-1) warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than haskell-core (0.4.2.2-1) warning: haskell-crypto-random: local (0.0.7-4) is newer than haskell-core (0.0.7-1) warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than haskell-core (0.2.1.1-2) warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core (2.1.2-2) warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core (0.1.0.4-2) warning: haskell-publicsuffixlist: local (0.1-7) is newer than haskell-core (0.1-2) warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core (0.1.3-1) warning: haskell-socks: local (0.5.4-10) is newer than haskell-core (0.5.4-2) warning: haskell-x509: local (1.4.11-5) is newer than haskell-core (1.4.11-2) warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core (1.4.4-2) warning: haskell-x509-validation: local (1.5.0-9) is newer than haskell-core (1.5.0-2) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: haskell-connection: requires haskell-network=2.4.2.2-60 :: haskell-connection: requires haskell-tls=1.2.6-5 :: haskell-connection: requires haskell-x509=1.4.11-5 :: haskell-connection: requires haskell-x509-store=1.4.4-9 :: haskell-connection: requires haskell-x509-validation=1.5.0-9 :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59 :: haskell-cookie: requires haskell-text=1.1.1.1-1 :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3 :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4 :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2 :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60 :: haskell-http-client-tls: requires haskell-tls=1.2.6-5 :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1 :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2 :: haskell-http-conduit: requires haskell-http-types=0.8.4-4 :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3 :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5 :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1 :: haskell-socks: requires haskell-network=2.4.2.2-60 :: haskell-x509-system: requires haskell-x509=1.4.11-5 :: haskell-x509-system: requires haskell-x509-store=1.4.4-9

I really have no idea what to do with this or what would have caused it. I'm sure it's some important misunderstanding on my part. Any help would be greatly appreciated.

-Mike

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

_______________________________________________ arch-haskell mailing listarch-haskell@haskell.orghttp://www.haskell.org/mailman/listinfo/arch-haskell

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell