ghc-7.10 and F24 plans
by Jens-Ulrik Petersen
Hi,
I would like to move ghc to 7.10.2 for F24,
and I have started working on this locally in the background:
some needed version bumps have gone to package git already
(but not koji - please don't build any unless you can do
all the necessary legwork (ie rebuilding)). I also updated fhbuild
in fedora-haskell-tools to work better.
I am using ghc and ghc-rpm-macros from my ghc-7.10.2 copr to test all this.
As expected various packages need updating and new deps
to build with ghc-7.10. Here are the current remaining problems:
Important:
(new packages in [ ] have filed package reviews - see below)
```
* haskell-platform epoch? :-(
* pandoc: needs [filemanip] and cmark (filed review for [libcmark]
(CommonMark in C))
* Agda needs geniplate-mirror (replaces geniplate)
* nats to be retired (subsumed by base-4.8)
* hashed-storage fails → darcs
* haskell-platform epoch? :-(
* pandoc-citeproc (new deps) -> hakyll
* hledger-lib (new deps) → hledger
* snap-core (needs [time-locale-compat]) → snap-server → hakyll
* warp (newer deps) → scotty
* git-annex (compile): needs [sandi]
* idris (fails/new deps)
* hlint needs: [extra]
* shake needs: [extra] js-flot js-jquery
* bustle fails
```
Less important:
```
- shelly (new deps)
- happstack-server (BuildingBlocks error)
- haddock needs haddock-api
- ↳ leksah-server (we don't have leksah anymore though)
- ltk (dep vers)
- glade (ambiguity) → bluetime
- citeproc-hs (compile)
- monad-unify fails (not in Stackage): Alternative deriving
- IOSpec fails (Applicative)
- hint (System.IO.UTF8)
- concrete-typerep
- cmdtheline
- brainfuck (compile)
```
(some of these could just be dropped IMO).
Next I want to rework fhbz since cblrepo no longer works for me: my
idea now is that it should diff our version with the latest package
version on Stackage and report if there any are new deps. If there
aren't then it should be good to go.
Various package reviews are needed/blocking ghc-7.10:
old-locale: https://bugzilla.redhat.com/show_bug.cgi?id=1263904
old-time: https://bugzilla.redhat.com/show_bug.cgi?id=1263905
(Note the results above assume these two packages or there would be
many more failures, ie these are critical blockers)
[filemanip]: https://bugzilla.redhat.com/show_bug.cgi?id=1264288
[libcmark]: https://bugzilla.redhat.com/show_bug.cgi?id=1266429 (C package)
[extra]: https://bugzilla.redhat.com/show_bug.cgi?id=1266847
mtl-compat (maybe can be patched around?):
https://bugzilla.redhat.com/show_bug.cgi?id=1245021
[sandi]: https://bugzilla.redhat.com/show_bug.cgi?id=1256051
[time-locale-compat] https://bugzilla.redhat.com/show_bug.cgi?id=1256057
Some more reviews will be needed from the above lists.
Do please help, so that we are not blocked until Xmas! :)
I think we should still try to do a Haskell Package Review Activity
Week soon to help catch up. If you look everywhere in the Distro
fields in Hackage you can see Fedora is behind the rest. :-(
Thanks,
Jens
7 years, 11 months
Copr group
by Ben Boeckel
Jens, do you want to create the haskell-sig group on Copr? We can move
updates there and make other repos for things like git-annex, yesod, and
hledger, It seems that I am not part of the haskell-sig in FAS though?
Or at least it isn't showing up.
--Ben
7 years, 11 months
Re: packaging "stack" for Fedora
by Jens-Ulrik Petersen
> > $ sudo dnf copr install petersen/stack
Oops, s/install/enable/
> > $ sudo dnf install stack
> > $ stack install hledger
8 years
Re: packaging "stack" for Fedora
by Jens-Ulrik Petersen
Hi Sitaram,
(I am copying the Fedora Haskell list since this may be interesting for
others too.)
I guess firstly you're after a newer version of hledger than the one
available in Fedora?
(BTW if you msg ".who owns hledger" in #fedora-devel - zodbot will tell you
the owner directly.)
I have a stack copr you can use:
https://copr.fedoraproject.org/coprs/petersen/stack/
eg
$ sudo dnf copr install petersen/stack
$ sudo dnf install stack
$ stack install hledger
Yes eventually we/I want to get stack into main Fedora, but there are a lot
of new dependencies needed.
Hope that helps,
Jens
2015/11/08 午前3:15 "Sitaram Chamarty" <sitaramc(a)gmail.com>:
> Hi,
>
> I got your email by asking on #fedora-devel about who maintains the RPM
> for "cabal-install".
>
> I was trying to install a package called "hledger" today (it's author is
> in the CC of this email). I managed it using 'cabal', but it seems the
> easier method involves something called "stack".
>
> I was wondering if it would be possible to package stack also. The
> "stack" repo is at https://github.com/commercialhaskell/stack (but you
> probably knew that already).
>
> Note that I am not a Haskell-literate person so I don't really know all
> this; hence the CC to Simon ;-)
>
> regards
> sitaram
>
>
8 years
packaging taffybar and problem with dummy package
by Martin Bukatovic
Dear Haskell list,
I have a problem with packaging taffybar project from hackage. Using
cabal-rpm I was able to build it (including all dependencies not yet available
in fedora 22) as you can see my haskell copr:
https://copr.fedoraproject.org/coprs/marbu/haskell/
But I stumbled into corner case I'm not sure how to resolve. While my
priority is to get it work in the copr, I would like to resolve it in a
clean way which would be acceptable in a future fedora packaging review.
Taffybar requires (among others) network module. And since version 2.6,
this module was split into 2 modules: network and network uri. The
problem is that upstrem suggests that hackage projects which would like
to be buildable with both versions (before and after the split) should
use define following cabal flag:
http://hackage.haskell.org/package/network-uri-2.5.0.0
Since Fedora 22 provides ghc-network-2.4.2.3-1.fc22 (and if I checked
dist-git right, this is also the version which will be shipped for f23),
I need to set this network-uri flag to False. Which means that to
satisfy cabal requirement for network-uri < 2.6, I need to use network-uri
module in version 2.5 (it's just empty placeholder package). And as I
understand it, it was a deliberate decision motivated by some hackage
details I don't see into:
https://github.com/haskell/network-uri/pull/22
Anyway disabling the flag helps during build (as you can see in the
copr), but when I try to install it, I can't:
~~~
# rpm -qa "ghc-network-uri*"
ghc-network-uri-2.5.0.0-1.fc22.i686
ghc-network-uri-devel-2.5.0.0-1.fc22.i686
# dnf install ghc-taffybar-devel
Last metadata expiration check performed 0:33:16 ago on Mon Nov 2 21:42:11 2015.
Error: nothing provides
ghc-devel(network-uri-2.5.0.0-57c8091ea57afec62c051eda2322cc2f) needed by ghc-taffybar-devel-0.4.5-2.fc22.i686
~~~
This is likely related to the fact that both ghc-network-uri packages
are empty, without any haskell binaries. So whatever ghc-devel macro
tries to find, it there is nothing in these packages by definition.
I could have just patch the cabal file like this:
https://github.com/marbu/specfiles/commit/8bb2ecc43ba3bed9d6df9654fd21730...
but that would not solve the problem for other packages which (possibly)
requires network-uri module and contains network-uri flag as suggested
by upstream.
So my questions are:
1) Is there any way how to make the dummy package work as intended?
2) Since I'm new to haskell packaging, I would like to know if this kind
of issue is common or expected.
If both answers are just "no", I can probably just patch the cabal file after
all and call it a day :)
Thanks for the help.
--
Martin Bukatovic
8 years, 1 month
