- arch-haskell - Haskell.org

Thoughts on using docker to build?
by Magnus Therning 18 Sep '14

18 Sep '14

I've lately been considering moving away from using `makechrootpkg` when building packages for ArchHaskell. I've been playing with docker, and the last few updates have been built using a few helper scripts I've put together. Does anyone on the list have any thoughts on docker? Would you consider it suitable and a good replacement for the chroots that have been used in the past? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich

2 1

Pandoc fails creating document with citation styles
by Ray Rashif 11 Sep '14

11 Sep '14

Hi guys I must admit that Haskell is unfamiliar territory and requires far more time to debug -- time that I do not have. For this reason I must seek your help in troubleshooting an issue with pandoc, citations and citation styles. A while ago when the Haskell stuff were all in the official repos I successfully used pandoc with citations (--biblio) and *.csl style files (--csl $file). [1] Now that I have moved over to using the arch-haskell repos (after a hiatus from markdown), I see that this no longer works: ~$ pandoc test.md -o test.pdf --biblio test.bib --csl apa.csl pandoc-citeproc: error while parsing the XML string pandoc: Error running filter pandoc-citeproc In fact, none of the example styles included inside haskell-pandoc-citeproc works and they output the same error. You may get the test files from [1] and one or more csl files to test from /usr/share/i386-linux-ghc-7.8.3/pandoc-citeproc-0.5/tests/. I also reported this upstream [2] and it looks like the problem is downstream -- either my system, the dependency chain, or a packaging error somewhere. I would appreciate it if someone else could first reproduce the error, and then we can try to fix it. Thanks! Regards [1] https://bugs.archlinux.org/task/35657 [2] https://groups.google.com/forum/#!msg/pandoc-discuss/76DoTPISouA/6uAyjvTz82… -- GPG/PGP ID: C0711BF1

2 4

is there some easy way to ignore all haskell- packages?
by Martin DeMello 04 Sep '14

04 Sep '14

I regularly get into version pinning conflicts with my haskell- packages. The current one has been going on for some days now: $ sudo pacman -Syu :: Synchronizing package databases... core is up to date haskell-core is up to date haskell-happstack is up to date infinality-bundle is up to date infinality-bundle-fonts is up to date extra is up to date community is up to date :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: haskell-lens: requires haskell-aeson=0.7.0.6-9 :: haskell-lens: requires haskell-attoparsec=0.11.3.4-5 :: haskell-lens: requires haskell-bifunctors=4.1.1.1-14 :: haskell-lens: requires haskell-comonad=4.2.2-1 :: haskell-lens: requires haskell-contravariant=1.1-1 :: haskell-lens: requires haskell-free=4.9-7 :: haskell-lens: requires haskell-profunctors=4.2.0.1-1 :: haskell-lens: requires haskell-scientific=0.3.2.2-1 :: haskell-lens: requires haskell-semigroupoids=4.2-1 I don't so much mind that this is happening, as that it blocks my entire rest-of-system upgrade. Is there any easy way to recursively ignore everything that is unsatisfiable? martin

5 6

Pandoc 1.13.0.1
by Jonathan Plona 22 Aug '14

22 Aug '14

My apologies if this is a duplicate, I'm not sure if it went through before: It looks like a new version of pandoc has been released. Any chance to get a new build in the arch-haskell repo? Thanks.

2 1

Issue with i686 packages
by Nicola Squartini 31 Jul '14

31 Jul '14

Hi Magnus, I'm trying to build updated packages for [haskell-happstack] and I get this kind of errors: $ ./makeahpkg -c -a i686 $(<buildorder) [...] ==> Making package: haskell-fb 1.0.2-6 (Wed Jul 30 15:18:26 CEST 2014) ==> Retrieving sources... -> Found fb-1.0.2.tar.gz ==> Validating source files with sha256sums... fb-1.0.2.tar.gz ... Passed ==> Making package: haskell-fb 1.0.2-6 (Wed Jul 30 15:18:27 CEST 2014) ==> Checking runtime dependencies... ==> Installing missing dependencies... error: target not found: haskell-conduit-extra=1.1.3-1 error: target not found: haskell-monad-logger=0.3.7-4 ==> ERROR: 'pacman' failed to install missing dependencies. ==> ERROR: Build failed, check /home/nicola/haskell-happstack/i686-chroot/build/build [...] and similar others for other packages. The build process ran flawless for x86_64. I assume there is some problem with the i686 packages after today's update of habs. Thanks Nicola

2 4

Bootstrapping a cblrepo.db / custom repository
by Rudy Matela 29 Jul '14

29 Jul '14

Hello All, First of all, many thanks to Magnus Therning for maintaining the arch-haskell repository and it's tools. It saved a lot of time for me (both fighting cabal and compiling packages). I'm planning to use cblrepo to create a new repository from scratch. So, I have a question: How to use cblrepo to bootstrap a new repository? (Is it even intended to use for that purpose.) Or, more broadly, what's the best way to bootstrap an arch (-haskell) repository? For example, suppose I want a repository with just template-haskell: $ mkdir habs-bootstrap $ cd habs-bootstrap $ cblrepo add template-haskell,2.9.0.0 Failed to satisfy the following dependencies for template-haskell: base ==4.7.* containers ==0.5.* pretty ==1.1.* Shouldn't the dependencies here be added by default? Guessing here that it is not possible because of inability to guess package types (--ghc-pkg / --distro-pkg). I've also tried: $ cblrepo add -g base,4.7.0.1 That was ok, but: $ cblrepo add template-haskell,2.9.0.0 Failed to satisfy the following dependencies for template-haskell: containers ==0.5.* pretty ==1.1.* Containers and pretty are provided by GHC. Should I add GHC in my repository? That does not seem to be the case with haskell-happstack [1]: it has array on it's db (it is also provided by ghc). Regards, Rudy [1]: https://github.com/tensor5/haskell-happstack PS: Which kind of setup do you all use, in general, to maintain your own packages not provided by haskell-core? So far I've been using my own fork of archhaskell/habs, but I kinda loose the work (on cblrepo.db) when merging with Magnus' branch, needing to re-add all my packages.

3 3

NodeJS dependency
by Alois Cochard 19 Jul '14

19 Jul '14

Hi folks, I'm just switching to your awesome [haskell-core] repo (thanks for the effort, this is extremely useful!). But I'm a bit surprised than when re-installing my xmonad... I got a dependency on NodeJS inferred? Is there some form of haskell-webscale integration that I'm not aware of? ;-) Thanks! -- *A\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

2 2

How cblrepo decides when to add 'haskell-' prefix?
by Rafał Babinicz 19 Jul '14

19 Jul '14

After cloning habs repo, syncing hackage db with 'cblrepo sync' and adding yeganesh with 'cblrepo add --ghc-version=7.8.3-1 -u https://hackage.haskell.org/package/yeganesh-2.5/yeganesh.cabal' I see different behavior with 'cblrepo pkgbuild taffybar' and 'cblrepo pkgbuild yeganesh'. Former one generates haskell-taffybar with adjusted PKGBUILD for that name, but latter generates regular 'yeganesh' without any haskell-yeganesh. I cannot find any important difference in cblrepo.db and also grepping through source code, I can't find any other references to taffybar than in cblrepo.db which looks similar to yeganesh's entry. Can you clarify in README of cblrepo or habs - how to generate haskell-* package? I've built xmobar and yeganesh with makeahpkg for x86_64 and i686 and I want to contribute, but I'm totally lost here. Should I change names and PKBUILDS by hand? Why cblrepo pkgbuild generates different results for similar packages in cblrepo.db? Thanks in advance for any help.

3 2

Re: [arch-haskell] Automatic Dependency Resolution
by Profpatsch 18 Jul '14

18 Jul '14

Not a reply, since I just subscribed to this list. > I have looked at stackage. AFAIU it is basically a place to host a > subset of Hackage (plus the possibility to patch packages). If I've > understood that correctly it means stackage is of VERY limited use to > us in maintain Arch Haskell. As far as I understand it their big advantage is that each version is completely coherent, a snapshot of packages that work together. They pipe it through Jenkins and send mails to each package maintainer of packages that don’t build. So they automated the process and accept new packages. Maybe this can be used? e.g. basing Archhaskell on it and just manage the remaining packages manually while slowly integrating them into Stackage? -- Proudly written in Mutt with Vim on Archlinux. Q: Why is this email five sentences or less? A: http://five.sentenc.es

1 0

Re: [arch-haskell] [habs] Automatic dependency resolution (#154)
by Magnus Therning 18 Jul '14

18 Jul '14

Moving this to the mailing list, because this is turning into a discussion. :-) On Thu, Jul 17, 2014 at 02:29:13PM -0700, Profpatsch wrote: > I see. > > I don’t understand how getting a coherent set of package version is > possible manually by hand, though. I’d assume that’s exactly the > kind of things where computers excel. Have you looked at > [stackage](http://www.stackage.org/)? It is possible, but it's a lot of work. Which is exactly why I started working on `cblrepo` in the first place. `cblrepo` does check that dependencies are satisfied, and it reports when they are not. What it doesn't do though is automatically satisfy the missing dependencies. I simply haven't found a need for that. (Patches are welcome, though.) I have looked at stackage. AFAIU it is basically a place to host a subset of Hackage (plus the possibility to patch packages). If I've understood that correctly it means stackage is of VERY limited use to us in maintain Arch Haskell. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0