Re: [arch-haskell] help upgrading packages
On 2014-05-15 23:18, Magnus Therning wrote: 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 s...@scientician.net 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? What I do for executable-only is pretty simple. I use stow to manage all non-distro software that I install, so I have one directory per package, like so: ~/stow/ghc-mod/lib/ghc-mod/src ~/stow/hums/lib/hums/src (etc.) Each of these directories contains a full sandbox with a locally-run cabal install. For each package I add a bin directory, so ~/stow/ghc-mod/bin and put in the necessary relative symlinks: ~/stow/ghc-mod-4.0.2/bin cpphs - ../lib/ghc-mod/.cabal-sandbox/bin/cpphs ghc-mod - ../lib/ghc-mod/.cabal-sandbox/bin/ghc-mod ghc-modi - ../lib/ghc-mod/.cabal-sandbox/bin/ghc-modi hlint - ../lib/ghc-mod/.cabal-sandbox/bin/hlint HsColour - ../lib/ghc-mod/.cabal-sandbox/bin/HsColour And finally use stow to merge the package into my ~ directory, so that all the bin/ symlinks end up in my ~/bin. (I use stow because I'm pretty pendantic about keeping packages separate from everything else in my $HOME, but you could also just have a ~/src with a sandbox for every package and add symlinks directly from your ~/bin into the sandboxes. It's just that since all my non-haskell non-distro self-built software is managed by stow, I chose to also use stow for this.) 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. I think we might be talking past each other... I'm afraid I don't understand what you mean by more manual work. Using sandboxes the way I've described above doesn't really work at all for executable + library situations. (So I offered a different solution to that problem, namely cabal-ifying your own package that depends on a library and installing your own package in a sandbox.) 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. If we want to get pendantic, it's probably best to say Cabal vs. cabal-install (which is where the cabal executable comes from, for those who don't know). I use cabal-install for all development with a .cabal file for each of my projects, I never use Cabal (the library) directly as I've never encountered a need to. I've not encountered many packages which use anything other than the standard boilerplate Setup.hs/Setup.lhs file. (Some packages with *really* complex build requirements do so, e.g. Gtk2hs, but I assumed that's not quite the level of complexity we're talking here.) Anyway, enough rambling on... Regards, ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson s...@scientician.net 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: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
On 2014-05-15 11:35, Magnus Therning wrote: On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson s...@scientician.net 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. 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. 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. :) Regards, ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
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 s...@scientician.net 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: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus What gets measured, gets done. -- Tom Peters pgpL8EJJFLR59.pgp Description: PGP signature ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
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. 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. Regards, ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
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 katel...@gmail.comwrote: 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 list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
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 katel...@gmail.com mailto:katel...@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
Re: [arch-haskell] help upgrading packages
On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser dawid.loub...@ibi.co.zawrote: 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]. 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. 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 katel...@gmail.comwrote: 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
Re: [arch-haskell] help upgrading packages
On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini tens...@gmail.com wrote: On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser dawid.loub...@ibi.co.za 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: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
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! regards, Dawid On 12/05/2014 15:47, Magnus Therning wrote: On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini tens...@gmail.com wrote: On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser dawid.loub...@ibi.co.za 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 ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
On Mon, May 12, 2014 at 4:02 PM, Dawid Loubser dawid.loub...@ibi.co.za 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: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
[arch-haskell] help upgrading packages
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
