- arch-haskell - Haskell.org

Package INSTALL scriptlets do not generate a working haddock index (gen_contents_index broken)
by Matthew Cox 03 Dec '12

03 Dec '12

The /usr/share/doc/ghc/html/libraries/gen_contents_index script is broken and causes haddock to emit broken links in the resulting documentation index for the local ghc pkg tree. Here's the fix: - NAME_VERSION=`echo "$HADDOCK_FILE" | sed 's#/.*##'` - HADDOCK_ARG="--read-interface=${NAME_VERSION},$HADDOCK_FILE" + HADDOCK_ARG="--read-interface=$(dirname $HADDOCK_FILE),$HADDOCK_FILE" The eager match on sed causes it to strip all but the first component of the package documentation path. Presumably this is broken upstream and needs to be fixed by them, but I'd like to confirm it's not caused by us before I pester the ghc-dev list. Matt

2 1

Script to manage secondary repository
by Fabio Riga 22 Nov '12

22 Nov '12

Hi all, a long time ago I wrote about a script to keep a repository of Haskell packages that depends on [haskell] repo. This script is what helped me producing [haskell-extra] and now [haskell-web]. In my intentions, this should permit a group of people to manage relatively small repository that should merge into a single big one. The script is actually a wrapper over cblrepo, with some calls to cabal-install. It needs some more functionality in order to be useful to someone besides me, but I publish it to persuade Magnus that this way is possible. Here you are: https://github.com/EffeErre/cbladmin Any comment is welcome. Fabio ps. I also uploaded [habs-web] source files here: https://github.com/EffeErre/habs-web and it also is in sync with hackage!

2 1

Fwd: [Haskell-cafe] How to determine correct dependency versions for a library?
by Ramana Kumar 21 Nov '12

21 Nov '12

Is the Gentoo stuff mentioned below reusable by us at all? And presumably we might want to get in on any consolidation of effort? ---------- Forwarded message ---------- From: Michael Orlitzky <michael(a)orlitzky.com> Date: Sun, Nov 18, 2012 at 1:15 AM Subject: Re: [Haskell-cafe] How to determine correct dependency versions for a library? To: haskell-cafe(a)haskell.org Replying somewhere random in the thread. Linux distributions have to solve this same problem. We first need to decide what Hackage's function is supposed to be: (1) A dumb repository to host Haskell code (2) A collection of Haskell packages that work together In reality it's (1), but the existence of cabal-install supposes (2). The way that distributions handle this is to assign maintainers to each and every package in the distro, and require them all to be actively maintained. Packages that don't build or have unresponsive upstreams are removed. Maintainers who don't do their jobs are removed after a while, too. The end result is that there are somewhat fewer packages /visible/ to the user, but a comparable amount /available/, since what's in the distro is what actually would have worked if the user tried to build it himself. I think there's value to having (1), but that we shouldn't expect (2) at the same time. Tons of work goes into QA'ing packages to work together. Someone needs to be responsible for making sure that things work; right now no one is, so they don't. Running a "Haskell distro" on a parallel Hackage would be a lot of work but Arch, Debian, Gentoo, etc. already have to do essentially that. It may make sense to either consolidate the effort, or reuse what work is already being done. The gentoo-haskell[1] project already keeps a list of packages that are known to build from source together. Something like prefix[2] for example could be used to install packages that have been vetted rather than just pulling a tarball with the right name directly from Hackage. Or if that's too much trouble, we could write a reverse hackport[3] that creates a second Hackage full of stuff known to work in the various distributions. No solution will be great at first, but we have the "benefit" that it doesn't work right now either so maybe nobody will notice. Without everyone duplicating the QA effort, I think things would shape up quickly. [1] https://github.com/gentoo-haskell/gentoo-haskell [2] http://www.gentoo.org/proj/en/gentoo-alt/prefix/ [3] http://hackage.haskell.org/package/hackport _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Our IRC room
by Magnus Therning 20 Nov '12

20 Nov '12

As has been mentioned before on the list the IRC room, #arch-haskell, is currently "unmanaged". Don, who got the room created, is unresponsive at the moment so I'm guessing we'll have to look for some other way to re-gain control of the room. I'm not a heavy IRC user myself, and I don't really know how to proceed with this. I had a short chat with one of the freenode OPs, and he suggested that the #arch-haskell room should be handed over to the people managing the other #arch-X rooms. That sounds like a good idea to me, but I'm probably not the best person to judge this solution. Is it a good suggestion? Does someone know who's managing the ArchLinux IRC rooms on freenode? /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

3 5

Installing Leksah
by Eric Velten de Melo 31 Oct '12

31 Oct '12

I'm having an awful time trying to install Leksah in Arch. I tried other times before, I never suceeded. When trying with cabal, eventually I figured I had to install gtk2hs-buildtools. 'cabal install gtk2hs-buildtools' gives an error like this: " [ 7 of 41] Compiling C2HSConfig ( c2hs/toplevel/C2HSConfig.hs, dist/build/gtk2hsC2hs/gtk2hsC2hs-tmp/C2HSConfig.o ) c2hs/toplevel/C2HSConfig.hs:110:1: Unacceptable result type in foreign declaration: CInt When checking declaration: foreign import ccall safe "static bitfield_direction" bitfield_direction :: CInt " Installing from the AUR, after ignoring some upper bound dependencies, I eventually came to the same kind of problem compiling haskell-gio: " [ 2 of 24] Compiling System.GIO.Types ( dist/build/System/GIO/Types.hs, dist/build/System/GIO/Types.o ) System/GIO/Types.chs:1025:1: Unacceptable result type in foreign declaration: CULong When checking declaration: foreign import ccall unsafe "static g_output_stream_get_type" g_output_stream_get_type :: CULong " Is there a sane way to install it without going through all this trouble? Thanks, Eric

4 4

Re: [arch-haskell] [Haskell-cafe] GHC maintenance on Arch
by Magnus Therning 29 Oct '12

29 Oct '12

Please stay on topic, this is *not* a discussion about Haskell Platform[1], it's a discussion on ArchHaskell[2]. Please read up on the mailing list archives first, and then, if you still feel there's a need to discuss HP in ArchHaskell (which isn't the same thing as Arch itself) then please start a new thread. /M [1]: http://www.haskell.org/platform/ [2]: https://wiki.archlinux.org/index.php/ArchHaskell On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning <magnus(a)therning.org> > wrote: >> >> Now I'm going to run the risk of upsetting you quite a bit by being >> completely blunt. > > > Indeed. > >> >> You come across in your mail like someone who has thought through your >> own situation, but fail to see the larger picture. You do know *your* > > > May I ask you a question, then? > > Does the Haskell Platform have any reason to exist? > > Supposedly, the Haskell community backs the Haskell Platform as the way that > most users should be using the Platform. Yet we have here a vendor platform > which does not support it, and newcomers who notice this and question it are > chastised for not thinking about the needs of other people. This suggests > that the Haskell Platform is unimportant and perhaps disruptive to some > significant group of people... is this so? > > And then, looking at your own message, I must ask: have you considered that > the Platform is aimed at the great many people who do not have large amounts > of expertise maintaining their own personal Haskell ecosystem. Or are your > needs so important that these people must in fact be told to deal? > > Or, to phrase in your own words: > >> You come across in your mail like someone who has thought through your >> own situation, but fail to see the larger picture. > > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b(a)gmail.com ballbery(a)sinenomine.net > unix/linux, openafs, kerberos, infrastructure http://sinenomine.net > -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 0

Re: [arch-haskell] [Haskell-cafe] GHC maintenance on Arch
by Magnus Therning 29 Oct '12

29 Oct '12

Hello Timothy, Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* Haskell needs, and you know what *you* would want from a project like ArchHaskell. Then however you completely fail to realise that these are *your needs*, not anyone else's, but still you suggest that ArchHaskelll is broken because it doesn't provide a system that solves *your* problems. I suggest you take your insights of your situation and try to find a solution that works for you, and it sounds like you're on the way already with cabal-install. If you have suggestions on how to improve ArchHaskell *within the goals of the project* (which includes the general goals of ArchLinux) that would make ArchHaskell more usable to you, then you are more than welcome. However, if all you do is suggest that we completely change the goals of ArchHaskell because they don't align with your needs, then we thank you for your input, but ask you to not hold your breath for any changes. /M On Sun, Oct 28, 2012 at 9:49 PM, <timothyhobbs(a)seznam.cz> wrote: > Hello, > Who is in charge of the ghc and haskell packages on Arch linux? The current > system isn't working. > > Arch linux tends to update packages very quickly. > > For ghc, always having the latest ghc isn't a good thing. At least if you > actually want to get some work done. A majority of the time the latest GHC > is unusable. This is because the packages in hackage simply don't keep up. > With the current ghc version(7.6.1) even some basic packages in hackage are > not upgraded yet. > > Right now, a large number of other haskell related packages are in the arch > repos. Other than gtk2hs, I think these packages are pointless duplications. > In the other cases, it has been my experience that it is simpler to maintain > these packages through cabal rather than through pacman. Support for these > packages in Arch should probably be dropped. > > If you want to get work done in Arch with haskell, you should only install > ghc and cabal-install(right now, you'll have to search the Internet for the > old binaries, because the arch repos usually don't keep the old versions > around). Then you should add these packages to "IgnorePkg =" in pacman.conf > this way things won't break every couple of months. You can then choose to > upgrade when you wish. > > I hope that someone who is involved with the haskell Arch stuff reads this. > The current model needs to be rethought. Linux should be sane by default, > but I've lost many many hours learning that arch's relationship with haskell > is not so :( Probably the best solution would be to make Arch automatically > keep two versions of ghc around at any given time. > > Thank you for your time, > Timothy Hobbs > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 0

haskell-extra move to ghc-7.6
by Fabio Riga 28 Oct '12

28 Oct '12

Hi all, for everyone interested, I started porting [haskell-extra] in sync with [haskell]. I decided to call it [haskell-web], because web-frameworks are the main target. You can use it adding these lines in your pacman.conf: [haskell-web] Server = http://archhaskell.mynerdside.com/$repo/$arch At the moment there are about 80 packages: yesod, snap, happstack and all their dependencies. In the next days I'll try to port the rest. There is only x86_64, as I need packages from main [haskell] repo and at the moment i686 is not in sync. Magnus, could you please fix this? Please tell me if anything is wrong... Fabio

1 1

Re: [arch-haskell] [Haskell-cafe] GHC maintenance on Arch
by Rickey Visinski 28 Oct '12

28 Oct '12

Fyi, the is a specific arch-haskell mailing list which will probably get you a better answer to your question. I cc'd them for you. ~Rickey On Sun, Oct 28, 2012 at 5:24 PM, Clark Gaebel <cgaebel(a)uwaterloo.ca> wrote: > Personally, I like the latest version of GHC being in the repository, as > that's the version I normally use. > > What packages aren't working for you on 7.6? I find that they get updated > pretty quickly, and if you run into any that aren't, feel free to send the > authors a pull request. Almost everything is on github. > > - Clark > > On Sun, Oct 28, 2012 at 4:49 PM, <timothyhobbs(a)seznam.cz> wrote: > >> Hello, >> Who is in charge of the ghc and haskell packages on Arch linux? The >> current system isn't working. >> >> Arch linux tends to update packages very quickly. >> >> For ghc, always having the latest ghc isn't a good thing. At least if >> you actually want to get some work done. A majority of the time the latest >> GHC is unusable. This is because the packages in hackage simply don't keep >> up. With the current ghc version(7.6.1) even some basic packages in >> hackage are not upgraded yet. >> >> Right now, a large number of other haskell related packages are in the >> arch repos. Other than gtk2hs, I think these packages are pointless >> duplications. In the other cases, it has been my experience that it is >> simpler to maintain these packages through cabal rather than through >> pacman. Support for these packages in Arch should probably be dropped. >> >> If you want to get work done in Arch with haskell, you should only >> install ghc and cabal-install(right now, you'll have to search the Internet >> for the old binaries, because the arch repos usually don't keep the old >> versions around). Then you should add these packages to "IgnorePkg =" in >> pacman.conf this way things won't break every couple of months. You can >> then choose to upgrade when you wish. >> >> I hope that someone who is involved with the haskell Arch stuff reads >> this. The current model needs to be rethought. Linux should be sane by >> default, but I've lost many many hours learning that arch's relationship >> with haskell is not so :( Probably the best solution would be to make Arch >> automatically keep two versions of ghc around at any given time. >> >> Thank you for your time, >> Timothy Hobbs >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Probably a historic moment: all packages caught up with Hackage
by Magnus Therning 24 Oct '12

24 Oct '12

I just wanted to inform everyone that as of this morning [haskell] is *on* the edge of Hackage, i.e. % cblrepo updates % In other words, all packages in [haskell] are, at the moment, the very latest ones. I don't think this has ever happened before, there's always been some dependency preventing a complete catch-up. It doesn't contribute to world peace or anything, but it did at least make me happy this morning :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

4 3