Re: lang/ghc 8.6.4
On Fri, May 31, 2019 at 6:30 AM Matthias Kilian wrote: > The cabal / hackage / library people are clueless if it comes to > version limits in dependencies and when which part of a library > should be bumped. Instead of correcting this, they invented a > mechanism to publish "revised" meta data for a package via hackage. Thanks for your detailed explanation. I understand now. And to be clear, devel/hs-async is currently building fine using the packages posted at the start of this thread. I am interested in updating cabal-install to 2.4.1.0. I definitely understand wanting to keep the number of hs-ports low, and fixing cabal-install should help. To try to help, I have updated a few more ports. I have attached the diff since I think my mail client will mangle it. The changes: devel/hs-tar: Updated to 0.5.1.0, hackage patch added security/hs-cryptohash-sha256: Hackage patch added, revision bumped security/hs-hackage-security: Updated to 0.5.3.0, hackage patch added This is the first time that I have done this, so I hope I did it right; I did my best to read the documentation carefully. (Is there an easy way to get MODGHC_PACKAGE_KEY? I ended up having to do a run of "make update-plist" to get the new one from the file names, edit the Makefile, and then run "make update-plist" again.) Note that devel/hs-mtl, devel/hs-parsec, devel/hs-text, and devel/hs-stm are now core libraries included in ghc (https://www.haskell.org/platform/contents.html), and so I think those ports can be removed and packages that depend on them explicitly need to have those dependencies removed. The new cabal-install 2.4.1.0 has a new dependency, resolve, which has not been packaged. I'd be happy to also do that soon, but I need to study the documentation more before trying to make a new port. Best, Daniel On Fri, May 31, 2019 at 6:30 AM Matthias Kilian wrote: > > On Thu, May 30, 2019 at 06:37:50PM -0400, Daniel Moerner wrote: > > Thanks a lot for your work on this. I just built some of ghc 8.6.4 on > > a machine running -current using your patches. > > > > Unfortunately, devel/hs-async doesn't build with this version of ghc > > and base (4.12): > > > > Configuring async-2.2.1... > > [...] > > Setup: Encountered missing dependencies: > > base >=4.3 && <4.12, hashable >=1.1.1.0 && <1.3, stm >=2.2 && <2.5 > > > > Looking into this a bit, hackage says that async 2.2.1 supports base > > (>=4.3 && <4.13) (https://hackage.haskell.org/package/async), but this > > just seems to be a mistake in hackage. At present async supports base > > 4.12 only in git (and there's a fairly old issue request for a new > > release https://github.com/simonmar/async/issues/89). > > The cabal / hackage / library people are clueless if it comes to > version limits in dependencies and when which part of a library > should be bumped. Instead of correcting this, they invented a > mechanism to publish "revised" meta data for a package via hackage. > For async-2.2.1, the "revised" package description can be found at > > http://hackage.haskell.org/package/async-2.2.1/async.cabal > > If you compare this against the package description contained in the > distfile (or at > http://hackage.haskell.org/package/async-2.2.1/src/async.cabal), you'll > see that the revised onealready as less strict dependencies (but of > course, this will fail again with the next update of ghc): > > --- async.cabal-dist Fri May 31 11:09:12 2019 > +++ async.cabal-hackage Fri May 31 11:10:12 2019 > @@ -1,5 +1,6 @@ > name:async > version: 2.2.1 > +x-revision: 2 > -- don't forget to update ./changelog.md! > synopsis:Run IO operations asynchronously and wait for their > results > > @@ -50,14 +51,14 @@ > if impl(ghc>=7.1) > other-extensions: Trustworthy > exposed-modules: Control.Concurrent.Async > -build-depends: base >= 4.3 && < 4.12, hashable >= 1.1.1.0 && < > 1.3, stm >= 2.2 && < 2.5 > +build-depends: base >= 4.3 && < 4.13, hashable >= 1.1.1.0 && < > 1.4, stm >= 2.2 && < 2.6 > > test-suite test-async > default-language: Haskell2010 > type: exitcode-stdio-1.0 > hs-source-dirs: test > main-is:test-async.hs > -build-depends: base >= 4.3 && < 4.12, > +build-depends: base >= 4.3 && < 4.13, > async, > stm, > test-framework, > > See http://hackage.haskell.org/package/async-2.2.1/revisions/ for that > concept of 'revised' package descriptions. > > In other words: when doing operating system distribution packages > (like our ports), you have to fetch the distfile *and* also watch > for revised package descriptions, and if there are differences, > patch the package description contained in the distfile. An example > of this ist devel/hs-echo/patches/patch-echo_cabal in our ports > tree. > > The haskell eco system is extremely hostile to people who try to > provide operating system distribution packages -- t
Re: lang/ghc 8.6.4
On Thu, May 30, 2019 at 06:37:50PM -0400, Daniel Moerner wrote: > Thanks a lot for your work on this. I just built some of ghc 8.6.4 on > a machine running -current using your patches. > > Unfortunately, devel/hs-async doesn't build with this version of ghc > and base (4.12): > > Configuring async-2.2.1... > [...] > Setup: Encountered missing dependencies: > base >=4.3 && <4.12, hashable >=1.1.1.0 && <1.3, stm >=2.2 && <2.5 > > Looking into this a bit, hackage says that async 2.2.1 supports base > (>=4.3 && <4.13) (https://hackage.haskell.org/package/async), but this > just seems to be a mistake in hackage. At present async supports base > 4.12 only in git (and there's a fairly old issue request for a new > release https://github.com/simonmar/async/issues/89). The cabal / hackage / library people are clueless if it comes to version limits in dependencies and when which part of a library should be bumped. Instead of correcting this, they invented a mechanism to publish "revised" meta data for a package via hackage. For async-2.2.1, the "revised" package description can be found at http://hackage.haskell.org/package/async-2.2.1/async.cabal If you compare this against the package description contained in the distfile (or at http://hackage.haskell.org/package/async-2.2.1/src/async.cabal), you'll see that the revised onealready as less strict dependencies (but of course, this will fail again with the next update of ghc): --- async.cabal-dist Fri May 31 11:09:12 2019 +++ async.cabal-hackage Fri May 31 11:10:12 2019 @@ -1,5 +1,6 @@ name:async version: 2.2.1 +x-revision: 2 -- don't forget to update ./changelog.md! synopsis:Run IO operations asynchronously and wait for their results @@ -50,14 +51,14 @@ if impl(ghc>=7.1) other-extensions: Trustworthy exposed-modules: Control.Concurrent.Async -build-depends: base >= 4.3 && < 4.12, hashable >= 1.1.1.0 && < 1.3, stm >= 2.2 && < 2.5 +build-depends: base >= 4.3 && < 4.13, hashable >= 1.1.1.0 && < 1.4, stm >= 2.2 && < 2.6 test-suite test-async default-language: Haskell2010 type: exitcode-stdio-1.0 hs-source-dirs: test main-is:test-async.hs -build-depends: base >= 4.3 && < 4.12, +build-depends: base >= 4.3 && < 4.13, async, stm, test-framework, See http://hackage.haskell.org/package/async-2.2.1/revisions/ for that concept of 'revised' package descriptions. In other words: when doing operating system distribution packages (like our ports), you have to fetch the distfile *and* also watch for revised package descriptions, and if there are differences, patch the package description contained in the distfile. An example of this ist devel/hs-echo/patches/patch-echo_cabal in our ports tree. The haskell eco system is extremely hostile to people who try to provide operating system distribution packages -- they think everyone just uses cabal-install. That's the reason I try to keep the number of hs-ports as low as possible (but to still provide some more or less useful tools like darcs or xmonad). Ciao, Kili
Re: lang/ghc 8.6.4
Hi, Thanks a lot for your work on this. I just built some of ghc 8.6.4 on a machine running -current using your patches. Unfortunately, devel/hs-async doesn't build with this version of ghc and base (4.12): Configuring async-2.2.1... [...] Setup: Encountered missing dependencies: base >=4.3 && <4.12, hashable >=1.1.1.0 && <1.3, stm >=2.2 && <2.5 Looking into this a bit, hackage says that async 2.2.1 supports base (>=4.3 && <4.13) (https://hackage.haskell.org/package/async), but this just seems to be a mistake in hackage. At present async supports base 4.12 only in git (and there's a fairly old issue request for a new release https://github.com/simonmar/async/issues/89). Best, Daniel
Re: lang/ghc 8.6.4
Hi, On Sun, May 26, 2019 at 11:23:55PM -0700, Greg Steuck wrote: > I've updated a couple dozen more ports after having slacked for 2 months: > https://github.com/blackgnezdo/ports/commits/ghc_864_may26 Thanks (and, well, I'm slacking even more than you). I really hope to get a try of it, but first I want to experiment a little bit with replacing all the @exec/@unexec plist entries for registering and unregistering the hs packages (in ghc *and* the hs-ports) by @define-tag/@tag. @espie gave me some hints; the idea is: - after building the port, in the fake stage, create the package description and install it straight into lib/ghc/package.conf.d (with the proper file name) and include that into the plist, - use (via @define-tag / @tag to run ghc-pkg recache *once* after installation / deletion or updates. Don't ve afraid -- if I successfully test this with ghc-8.2 and two or three hs-ports, I'll just add all the necessary changes to your work (and send you diffs for it). Ciao, Kili
Re: lang/ghc 8.6.4
Mass import averted. It's easy enough to patch up the old version of hs-dbus. hs-dbus.patch.gz Description: application/gzip
lang/ghc 8.6.4
I've updated a couple dozen more ports after having slacked for 2 months: https://github.com/blackgnezdo/ports/commits/ghc_864_may26 I'm attaching a jumbo patch against ports-current. I confess to not following the proper protocol and building stuff on 6.5. I'm also probably making tons of other rookie mistakes which I'd appreciate to have pointed out. The status of the effort is: x11/hs-dbus won't go in easy. The old version is old enough that patching it to compile is probably a fool's errand. The new version has a large set of dependencies which aren't currently imported and will take a bit of effort to get in. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 ghc-8.6.4-may26.patch.gz Description: application/gzip