- arch-haskell - Haskell.org

Dropping (most of) AUR?
by Magnus Therning 10 Nov '11

10 Nov '11

A great many Haskell packages on AUR are out of date, whether marked as such or not. Only the 300 or so packages in [haskell] receives any sort of love, but even that is very spotty. Based on this I think it's most honest to disown the vast majority of packages on AUR owned by arch-haskell. Any thoughts or comments on this? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

4 9

haskell-chart and haskell-gtk
by gdweber＠iue.edu 28 Oct '11

28 Oct '11

A recent update of haskell-gtk, I believe, has broken haskell-chart: [root@tramp ~]# pacman -S haskell-chart warning: haskell-chart-0.14-22 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... Targets (1): haskell-chart-0.14-22 Total Download Size: 0.00 MB Total Installed Size: 13.21 MB Proceed with installation? [Y/n] y (1/1) checking package integrity [#######################] 100% (1/1) checking for file conflicts [#######################] 100% ghc-pkg: cannot find package Chart-0.14 error: command failed to execute correctly (1/1) upgrading haskell-chart [#######################] 100% Reading package info from stdin ... done. Chart-0.14: dependency "gtk-0.12.1-1f324b14e956836525290e5acd551748" doesn't exist (use --force to override) [root@tramp ~]# -- 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 []

1 1

haskell/haskell-glade 0.12.1-1 related problems
by Peter Hercek 27 Oct '11

27 Oct '11

arch: x86_64 haskell/haskell-glade 0.12.1-1 does not seem to be rebuilt against the latest community/haskell-gtk 0.12.1-1 There was some renamin probably so conflicts appear now. My guess would be that community packages got haskell prefix instead of gtk2hs? Not really sure. Anyway the renames lead to conflicts and mixing packages from [community] and [haskell]. You probably will not have any problems if you do not use haskell-glade. I solved it by just by putting [haskell] before [community] in pacman.conf. Which probably is a good thing in general. Peter.

2 1

Broken dependencies for happstack, how can I help again?
by Fabio Riga 21 Oct '11

21 Oct '11

Hello everybody, some time ago I helped adding some package in the repo, and was just starting to understand how to do this when Peter dropped maintaining the repo in favour of Magnus. Magnus introduced this new method with cblrepo, that (it seems to me) automate the updating process, so the group didn't need my work for updating "manually" the packages. Unfortunately today pacman rejected to update my system because happstack-server now need an old version of a package already present. haskell-happstack-server: require haskell-hslogger=1.1.0 (in community there's 1.1.5) Why the requiring a fixed version, when the cabal file doesn't? Is there a way to solve the problem without modifying manually the PKGBUILD? If I do modify the PKGBUILD manually how can I make this available to the repo? I also would like to help adding some more package, but I still don't know how to do this with cblrepo. Thanks for your work, I hope this can help. Cheers Fabio

3 5

Re: [arch-haskell] creation of haskell (or ghc) pacman group
by Magnus Therning 20 Oct '11

20 Oct '11

On Thu, Oct 20, 2011 at 14:29, Peter Hercek <phercek(a)gmail.com> wrote: > Yes, I like the fact we have specific versions in dependencies ... including > pkgrel which is not there always. If I understand Simon Marlow correctly > here > http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/20002 > then it is not sure that we will have the same ABI even when compiling > exactly the same code (with the same compiler). My practical experience is > that when one compiles the same code with the same compiler then the result > is almost always the same. Anyway, pkgrel change can also mean different > compiling options which definitely can change ABI. So I think pkgrel should > be in all dependencies too. In fact pacman dependencies are dependencies > between binary packages so they should be exact (contrary to source code > dependencies in cabal). Indeed. I've planned to work on adding pkgrel handling to cblrepo, but haven't gotten that far yet. Currently these cases are caught iff the person updating habs uses cblrepo properly, this isn't ideal. > AFAIK, exact pacman dependencies will detect all the problems when > installing a binary package. But detection and ease of you is a bit > different. I typically have a bit modified ghc itself (mostly to get > collored stderr which interleaves with stdout correctly and some other > details). So it is not uncommon I want to postpone ghc update and that means > all haskell related update. For such a case I want to ignore everything > haskell related during updates. I could put in pacman.conf only > "IngnorePkg=ghc" but then pacman will spit a ton of warnings about what > other packages cannot be updated too and whether I'm aware of it. I happened > to have sometimes my own changes to gtk2hs too. This would be another case > when I would like to postpone any haskell related update. For this e.g. > "IgnoreGroup=haskell" would be really useful. So who can use this group? > AFAIK only people who sometimes have modified haskell packages on their > systems or because of their own development want to postpone haskell updates > a bit. Well and possibly people who want to install everything haskell > related as I mentioned below. That's a rather specialised use-case AFAIU. The ArchHaskell team only controls the [haskell] repo, so a group would only exist there. It's just as easy to install everything from a single repo using the output from `pacman -Sl haskell` then. For the use-case of installing all Haskell packages a group only be worthwhile if it existed in the official Arch repos as well. > I do not have any tool for this. It would need to follow history in > core/extra/community which (in the worst case) can be obtained from the web > interface or the git of package definitions. I hope there is a better way > since this will not catch binary recompiles. But maybe there is a different > way around it. We could just ignore e.g. community (if we have all comunity > packages in habs), name packages the same (or maybe putting the community > package names in provides is enough?) and put [haskell] source before > [community] source in pacman.conf. There should be coordination between > extra/community/haskell package sources. Who maintains extra and community? > They should know more. habs shouldn't contain any packages that are in community, but it needs to know about them (needs to know the exact version, and in the future the pkgrel too). This in order to put in proper dependencies. > Anyway my call to create haskell (or ghc) group was not only for [haskell] > but also for community/extra. The Arch devs on the list will have to weigh in on this. It does seem to be a slightly out-of-the-ordinary use of a group. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

2 1

creation of haskell (or ghc) pacman group
by Peter Hercek 20 Oct '11

20 Oct '11

Hi, This is a call to create pacman group with name haskell (or ghc or something similar). All packages which depend on ghc would belong to the group. The reason why I would like to see this is to allow disabling update of any ghc dependency easily in pacman.conf. It would be cool if something like "IgnoreGroup = haskell" in /etc/pacman.conf would postpone update of any ghc dependency. Normally non-haskell packages do not need this but since haskell has no backward binary compatibility it can be really useful sometimes. If somebody installs everything from haskell, then this would also allow installing everything at once (using the group name). Although for this to work we might need first to make sure there are no duplicates between extra/community/haskell repositories. Not sure how trying to install whole group would behave when it hits duplicates (like e.g. gtk2hs-gtk in community and haskell-gtk2hs-gtk in haskell (well, the one in haskell is more useful since it provides glade bindings too)). Any opinions? Can we do it next time there is some big update? Peter.

2 3

mirroring arch haskell
by Piyush P Kurur 17 Oct '11

17 Oct '11

Hi, I am part of a team who run an arch linux mirror for indian sites. Does it make sense to mirror the haskell repository ? If so how do I go about setting it up. Specifically whom should I contact before starting to rsync. Regards ppk

1 0

Another update done (x86_64 only)
by Magnus Therning 08 Oct '11

08 Oct '11

I've just finished compiling the bunch of updates that were performed during my absence. 130 packages updated, and I've only had time to compile for x86_64 yet. The packages are in my private repo[1], since I still don't have proper access to the server. If some one with access would copy it over to [haskell] then I'd very much appreciate it. I'll probably get around to compiling for i686 this weekend. It would of course be very much appreciated if someone else beat me too it though ;) /M [1] [h4a]: http://www.kiwilight.com/~magnus/$repo/$arch -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

2 3

Re: [arch-haskell] Upgrading Yesod conflicts with JSONb
by Leif Warner 11 Sep '11

11 Sep '11

I left an issue at https://github.com/snoyberg/data-object-json/issues/2 Said he had no plans to convert from JSONb, but he'd accept a pull request. Aeson's JSON type does't look much different than JSONb's type: http://hackage.haskell.org/packages/archive/aeson/0.3.2.11/doc/html/Data-Ae… It also offers ToJSON and FromJSON classes for conversion to other types. That's a bit moot for the moment, though - it turns out JSONb works fine with attoparsec 0.9, despite the cabal file restrictions. I left an issue about it up: https://github.com/solidsnack/JSONb/issues/2 We can wait on the cabal file being updated, or just patch it ourselves in the meantime. -Leif On Thu, Sep 8, 2011 at 12:20 PM, Nicolas Pouillard < nicolas.pouillard(a)gmail.com> wrote: > On Thu, Sep 8, 2011 at 7:49 PM, Leif Warner <abimelech(a)gmail.com> wrote: > > Sorry, I meant I had to delete their descriptions from cblrepo.db, to > > maintain a consistent build set. JSONb requires attoparsec 0.8, the > > other upgrades required attoparsec be upgraded to 0.9. > > Ok, could you contact Michael Snoyman <michael(a)snoyman.com> the maintainer > of > data-object-json could be upgraded to using JSONb? He is very active and > might > help to resolve this issue. > > -- > Nicolas Pouillard > http://nicolaspouillard.fr >

1 1

My inactivity
by Magnus Therning 09 Sep '11

09 Sep '11

I've been rather inactive lately. It's for a good reason, but I forgot to communicate it. About two months ago I and my family left the UK for Sweden (my home country). Since then it's been a rather hectic time with settling in, finding a place to live, moving our stuff (twice), starting a new job, assembling furniture from IKEA, etc. At the moment we live in our own place, but we still don't have a reliable and fast internet connection. The ETA on the connection is 21 September. That means it'll be a few more weeks until I can get back to working with ArchHaskell properly. I'm very happy to see that Nicolas and Leif continue to work with it. Ideally you haven't even noticed my absence :-) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 0