| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Plugins don't work. One issue was the missing "lib/ghc-8.6.3/settings",
caused by the use of a throwaway GHC installation. This could be
mitigated by switching to a permanent GHC installation (e.g. by creating
a separate AUR package for GHC pinned to 8.6).
However, plugins in Gitit are still not usable because they cannot be
compiled without libraries. Bundling libraries with this package isn't
a good idea because
1. it can only be achieved by turning this into a binary package due to
limitations of Haskell's build tools, and
2. even if problem 1 is fixed, the plugins are limited to just the
bundled libraries.
Remark on problem 1: It is necessary have to bundle the gitit libraries
and all its dependencies. makepkg requires packages to be built in a
"staged" directory ($pkgdir) that isn't the final destination of these
files. Since cabal sandboxes are not relocatable ( see for example
https://github.com/haskell/cabal/issues/4097 ), nor does cabal support
building in staged sandboxes, the only solution would be to package
gitit as a binary tarball, which is undesirable.
As a result, plugin support will be disabled entirely, which shaves off
like 60MiB of space. Users who wish to use gitit with plugins should
consider building and running gitit with cabal + ghc-pristine. For
example:
sudo pacman -S --needed cabal-install ghc-static git mailcap zlib
curl -L https://aur.archlinux.org/cgit/aur.git/snapshot/ghc-pristine.tar.gz | tar -xz
(cd ghc-pristine && makepkg -i)
git clone https://github.com/jgm/gitit
cd gitit
cabal v2-update
cabal v2-configure --with-compiler=/usr/share/ghc-pristine/bin/ghc
cabal v2-run -- gitit -f example.conf
|
|
|
|
gitit is not yet compatible with GHC 8.6 yet. While that is being
fixed, this is a temporary workaround.
|
|
|
|
This way, the build() part will no longer require an Internet
connection. It also effectively freezes the sources of all dependencies
other a few boot libraries, improving reproducibility.
|
|
|
|
For now, we avoid parsec 3.1.12.0 until incompatibility is fixed. See:
https://github.com/jgoerzen/missingh/issues/42
https://github.com/haskell/parsec/issues/88
|
|
|
|
- Force Pandoc >= 1.19.2.2 because lower versions are broken for Cabal 2.0
( https://github.com/jgm/pandoc/issues/3876 )
- Source from Hackage, which also provides us a unique tarball name
- Enable --force-reinstalls
|
|
Switching back to cabal due to a bug in stack (see jgm/gitit#599 and
commercialhaskell/stack/#848 ) that's impossible to cleanly work around.
A local .cabal/config file is used to avoid contamination from the
user's ~/.cabal/config file. ghc-pristine prevents trouble caused by
the haskell-* packages, which lack the static libraries we need (that
was the original reason we switched to stack).
The presence of data files complicates this a lot: while "cabal copy"
does copy the data files of gitit, it doesn't copy the data files of
other dependent libraries (e.g. filestore). Therefore, we need to copy
all the data files straight from the .cabal-sandbox. To avoid conflicts
with other packages, we namespace all the data files under
/usr/share/gitit. And to avoid copying the docs, we re-override docdir
to something else. Cabal still installs the man pages and we can't
re-override that, so we just rm it during packaging.
Lastly, "cabal install" doesn't have a --destdir, and the --prefix has
to be the sandbox. This means the binaries will definitely store the
wrong path for data files. Thankfully, --enable-relocatable avoids
hardcoded paths entirely, so we just need to preserve relative paths.
At this point there's no reason to bother using "cabal copy", so we may
as well use "cabal install" and avoid the configure and build steps.
gitit only has one executable anyway!
|
|
Some other minor fixes:
- Improve error message about BUILDDIR being too small
- Create $pkgdir/usr/bin if absent (otherwise stack install fails)
- Add $pkgdir/usr/bin to PATH to avoid warnings from stack
|
|
TL;DR: Make sure your BUILDDIR has at least 8 GiB of space.
Switched from cabal to stack because cabal lacks isolation.
Cabal uses the global package database, so linking is affected by what
packages the user has installed at the time of build. One can't exactly
ignore the global database because the boot packages are needed. One
could ask for all the haskell-* system packages to be installed, but
that's a lot of tedious bookkeeping and we still have to deal with the
packages that aren't available through pacman, which would be stuck
inside the sandbox (unless one could somehow statically link those
libraries and dynamically link the system packages).
All in all, building using cabal sandboxes has become too complicated
due to the presence of dynamic-only system libraries in Arch. Stack
works out to be a bit simpler now, even though it involves reinstalling
ghc, incurring a dependency on stack, and having a large BUILDDIR.
Oh well.
|
|
See: https://github.com/jgm/gitit/blob/136b470c3d0ba691422c0979659de68f4edc175d/README.markdown#idle
|
|
|
|
|
|
|