[arch-haskell] Current procedure to install Hakyll (with deps)

gdweber at iue.edu gdweber at iue.edu
Sat Jul 28 03:16:12 CEST 2012

Building the packages for hakyll, hamlet, and kin
turned out to be easier than I expected
-- for some reason, the process automatically selected the right flags
and the right version of blaze-html to depend on.  

However, it seems that what Fabio Riga has done on this
is much farther along than what I've managed to do,
so I think I'm going to abandon this line of effort
and use his packages -- which I hope will soon be
integrated into the main [haskell] repository.

I have a couple of other questions relating to how I might
make any further contributions to the [haskell] repo.

1.  Due to Magnus's preference for taking pre-built packages
and patches, rather than accepting "pull" requests through github,
I'm inclined to think that my maintaining a fork of the
habs project on github is not serving any useful purpose,
and I'm thinking of deleting the fork.  Any objections?

This urge to delete is compounded by my unfamiliarity with git and
receiving increasingly bizarre error messages,
for example, today when I tried to push to my own

     $ git push myfork hakyll

     ! [rejected]        hakyll -> hakyll (non-fast-forward)
    error: failed to push some refs to 'https://github.com/gdweber/habs.git'
    hint: Updates were rejected because the tip of your current branch is behind
    hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
    hint: before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I can't understand how my local branch can be behind the remote,
since I'm the only one pushing to the remote!
I'm really spoiled by darcs, and the more I use git,
the less it makes sense.

2.  Also I'm wondering if instead of a fork (or just a clone) of
archhaskell/habs, and a "topic branch" in git for what I want to add,
it might be better to create a completely different repo,
such as Fabio has done for [haskell-extra] --


-- in which the packages from [haskell] are treated
as "distribution packages" in cblrepo.

What are the pro's and con's of this approach?


On 2012-Jul-11, Magnus Therning wrote:
> On Wed, Jul 11, 2012 at 12:54 AM,  <gdweber at iue.edu> wrote:
> > On 2012-Jun-12, Mateusz Loskot wrote:
> >> On 12 June 2012 11:53, Magnus Therning <magnus at therning.org> wrote:
> >> > On Tue, Jun 12, 2012 at 12:07 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
> >> > [...]
> >> >> So, here comes my question:
> >> >> Considering I'm interested in Hakyll, could anyone recommend where
> >> >> should I grab all the related packages and required dependencies from?
> >> >
> >> > Don't use AUR!
> >>
> >> OK, I won't.
> >>
> >> > Check to see how many of the dependencies are in [haskell], if all are
> >> > there: profit!
> >>
> >> I will try this option tonight.
> >>
> >> > If only a few are missing you can always raise a bug to
> >> > get them added (I look favourable upon existence of patches +
> >> > pre-built packages).
> >>
> >> I'm usually happy to contribute too, though in case of Haskell I'm
> >> green as Irish grass.
> >
> > I, too find, the Hakyll package interesting.
> >
> > I am interested in contributing a hakyll packages and its missing
> > dependencies, provided I can get some feedback on my previous
> > attempted contribution (of OpenGL).
> >
> > A few questions and comments:
> >
> > 1.  Installing the latest version of Hakyll,,
> > would require upgrading blaze-html
> > and reinstalling (probably breaking, warns cabal install --dry-run)
> > pandoc.  It seems best to aim at hakyll, which is
> > the latest version that can use blaze-html 0.4.* (we are at
> The latest version of blaze-html either requires a few other updates,
> or breaks other packages at the moment.  I can't remember which it is,
> but you can easily see check by attempting to add it using `cblrepo`.
> Settling for an older version of hakyll is all right for the moment.
> > 2.  Hakyll has a "previewServer" flag, which, if True (the default),
> > also depends on snap-core and snap-server.  Making a hakyll package
> > with the previewServer would require 21 new packages, including hakyll
> > itself.  Without the previewServer, it would require only 5 new packages.
> > So I think I would plan *at first* to provide the package *without* the
> > previewServer.
> Good point.
> > 3.  Assuming cblrepo does not automatically set the previewServer
> > flag to False, I think the best way to do this would be a patch
> > for the PKGBUILD?
> Either a patch to the PKGBUILD or a patch to the .cabal.
> If you come up with a good way to pass in flags when running `cblrepo
> add` then please let me know :)
> > 4.  One of the dependencies is hamlet, which requires another flag
> > setting, blaze_html_0_5 to be False, in order to use blaze-html < 0.5.
> > Again, a PKGBUILD patch?
> Or .cabal patch.
> /M
> -- 
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: magnus at therning.org   jabber: magnus at therning.org
> twitter: magthe               http://therning.org/magnus
> _______________________________________________
> arch-haskell mailing list
> arch-haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/arch-haskell

Gregory D. Weber, Ph. D.                            :
Associate Professor of Informatics                 / \
Indiana University East                           0   :
Tel. (765) 973-8420; FAX (765) 973-8550              / \
http://mypage.iu.edu/~gdweber/                      1  []

More information about the arch-haskell mailing list