- arch-haskell - Haskell.org

Xmonad version?
by Magnus Therning 15 Dec '11

15 Dec '11

What's the reason for keeping the xmonad version in Arch at 0.9? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

1 0

Another update in the works
by Magnus Therning 07 Dec '11

07 Dec '11

Please refrain from pushing any changes to the git repo for the time being. Per usual I'll send another email when the update is done. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 0

apkg: Fetch, build, and install packages from Hackage
by Matthew Farkas-Dyck 26 Nov '11

26 Nov '11

Hello all: I have written a tool to fetch, build, and install packages, and all packages they need, and so on. Packages are fetched straight from Hackage and installed with pacman. I plan to enable it to fetch from the local filesystem and AUR but so far this seems broken. (Hackage fetch is not broken.) https://aur.archlinux.org/packages.php?ID=54339 https://gitorious.org/apkg I know that someone asked of late on arch-haskell of just such a tool, so I hope that it will be found useful. -- strake

1 0

Updating
by Magnus Therning 25 Nov '11

25 Nov '11

I'm currently removing a few gtk-related packages from [haskell] since these packages already exist in [community]. Please hold off any modifications to the repo until I've finished doing this. /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

2 4

Update in progress
by Magnus Therning 24 Nov '11

24 Nov '11

I'm doing another update for [haskell], in fact it's only a re-build in response to a couple of packages due to a change in [community]. Please refrain from making any other updates while I'm busy with this. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 1

Haskell's state in Arch & near future
by Vesa Kaihlavirta 21 Nov '11

21 Nov '11

Hey, I'm writing to inform you about some action I'm planning to takeregarding our Haskell packages. Current======= The current status is this: we have in extra repo the "HaskellPlatform" package which depends on 24 haskell libraries plus ghc,cabal-install, alex and happy. Maintaining all these is relativelycumbersome (although it could be made a bit nicer by some cleverscripting) and in my opinion goes a bit against the simplicity clauseof our beloved distro. A bit worse is that our dependance on the haskell-platform means thatwe cannot upgrade ghc as soon as we could. The current platformdepends on ghc-7.0.3, and the platform's website informs helpfully:"Next release: July 2011". People have been wishing for ghc-7.2.1(released on 9 August 2011) for quite some time. Future====== The actions I'm about to do are following: - remove haskell-platform and all its libs from extra - only keep ghc in extra - alex, happy and cabal-install and the libs they need (5-10) go to community Since a ghc upgrade usually calls for a rebuild of every library thathas been built on it, this and any future ghc rebuild will have aminimum of 2 week bug-free staging period to allow all packagemaintainers at least some time to rebuild everything that's needed. Haskell binary repo=================== I've heard that there's a separate package repo for many haskellpackages. That seems like a good idea, especially if it's easy tolaunch a rebuild of everything, and if it works well enough. I'd liketo hear about that, if anyone maintaining it happens to be listening. AUR=== My humble opinion is that we do not need to support any of thehaskell- packages in AUR in any significant way, as cabal-install doesa far better job there than our silly wrapper around it. If people wantto maintain them, fine. --vk

10 27

shared libs problem
by Bernardo Barros 20 Nov '11

20 Nov '11

Hello, Why some packages give errors and converted to pkgbuilds? hosc and data-binary-ieee75, for example, build fine with cabal here, but not with makepkg -sfi /usr/bin/ld: cannot find -lHSbinary-0.5.0.2-ghc7.0.3 collect2: ld returned 1 exit status Who did you fix that?

1 1

Update in progress
by Magnus Therning 19 Nov '11

19 Nov '11

I'm upgrading a few packages, so please refrain from pushing any changes to the repo until further notice. Hopefully this'll be a quick one. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

1 1

Re: [arch-haskell] How to determine whether a package is in or out in [haskell]?
by Nicolas Pouillard 12 Nov '11

12 Nov '11

On Fri, Nov 11, 2011 at 11:12 PM, Magnus Therning <magnus(a)therning.org> wrote: > On Fri, Nov 11, 2011 at 10:50:03PM +0100, Nicolas Pouillard wrote: >> On Fri, Nov 11, 2011 at 10:40 PM, Magnus Therning <magnus(a)therning.org> wrote: >>> On Fri, Nov 11, 2011 at 10:26:54PM +0100, Nicolas Pouillard wrote: >>>> On Fri, Nov 11, 2011 at 9:42 PM, Magnus Therning <magnus(a)therning.org> wrote: >>> [...] >>>>>> Moreover I'm not fond of this kind of race. >>>>> >>>>> Neither am I, but I see no way easy way of addressing that. >>>> >>>> A way to quickly sending notices that a change is in progress. >>> >>> Send it where? To the mailing list? >> >> Or something more realtime like IRC (#archhaskell) > > Mailing list is the only viable solution given the build times > required for some updates. Multi-hour builds that are announced in > IRC simply won't work. I'll use the mailing list for now. I do not see why but anyway mailing list is fine as well. >>AUR votes could be took in account as well if we could download them. > > You point out the obvious problem with using AUR. A package has to > already exist on AUR for a user to be able to cast a vote on it. In > our case, who's going to upload to AUR to begin with? I agree AUR is not a good fit for archhaskell. > No, I think we need another place for voting, one where we can add a > list of all package on Hackage, without doing much work and without > committing to do any future work. Ideally that place would be Hackage > itself. Do you happen to know some other place that we could use for > this? There is two kind of votes. The kind of votes we find on AUR and will find on Hackage, these are permanent and might not be completely useful in the long run. The other kind of votes I was referring to is more one periodic basis. Where we ask, say on the mailing list, for users to vote for packages from Hackage. Then we can use this info to both remove packages and add new ones. -- Nicolas Pouillard http://nicolaspouillard.fr

1 0

Re: [arch-haskell] How to determine whether a package is in or out in [haskell]?
by Magnus Therning 11 Nov '11

11 Nov '11

On Fri, Nov 11, 2011 at 10:26:54PM +0100, Nicolas Pouillard wrote: > On Fri, Nov 11, 2011 at 9:42 PM, Magnus Therning <magnus(a)therning.org> wrote: [...] >>> Moreover I'm not fond of this kind of race. >> >> Neither am I, but I see no way easy way of addressing that. > > A way to quickly sending notices that a change is in progress. Send it where? To the mailing list? >> I'm a >> strong believer in only pushing changes once they build, and the only >> way of making sure of that is to make the build. Building ~50 >> packages takes quite a while. > > Yes but you pushed the x86_64 while the i686 was not fully built. > > I recommend the following: > > * build one arch > * git push > * build the other > * push both Good suggestion, I will adopt this. [...] > Currently, there are not much users. And I want this repo to at > least suit my needs otherwise I will simply build them for my use. I > prefer to have the side effect of being potentially useful for > someone else. Fair enough, but I still ask of you to consider that every package you add will result in longer build times and that affects everyone who works on keeping [haskell] up-to-date. >>> So for me we move out broken packages that we cannot quickly fix >>> if they are not much used. >> >> How do we find out if they aren't used? > > I don't know. Maybe we can GC with a kind of vote/lease system. > Imagine the following use case: > > $ cblrepo vote agda haskell-pandoc ... > > Which would transitively mark these packages as used (or add a voice to them, or > put a timestamp). > > $ git commit ; git push > > Everyone does the same and then: > > $ cblrepo remove `cblrepo unused` > $ cblrepo clearvotes I'm not sure I understand the thinking behind this, but I suspect this would mean that only people with commit access to our habs repo may vote. Or did I get that wrong? /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

1 0