January 2009 - FreeBSD-haskell

Comments on use of bsd.haskell.mk
by wahjava.ml＠gmail.com 04 Feb '09

04 Feb '09

Hi everyone, Apologies for being unre{sponsive,achable} in the last few days. Anyways, I've *finally* gone through bsd.haskell.mk submitted by Jacula, and tried porting devel/hs-utf8-string-ghc to it and with little bit of struggle with documentation I was successful. Following are the Makefile and pkg-plist of the updated port. ,---- Makefile | PORTNAME= utf8-string | PORTVERSION= 0.3.4 | CATEGORIES= devel haskell | MASTER_SITES= ${MASTER_SITE_HACKAGE} | PKGNAMEPREFIX= hs- | PKGNAMESUFFIX= -ghc | | MAINTAINER= wahjava(a)gmail.com | COMMENT= Support for reading/writing UTF8 strings for Haskell programs | | USE_CABAL= distrsimple:full docs hc:full lhs genreg profile:full | | .include <bsd.port.mk> `---- ,---- pkg-plist | %%D_LIBSUBDIR_REL%%/Codec/Binary/UTF8/Generic.hi | %%PROFILE%%%%D_LIBSUBDIR_REL%%/Codec/Binary/UTF8/Generic.p_hi | %%D_LIBSUBDIR_REL%%/Codec/Binary/UTF8/String.hi | %%PROFILE%%%%D_LIBSUBDIR_REL%%/Codec/Binary/UTF8/String.p_hi | %%D_LIBSUBDIR_REL%%/Data/ByteString/Lazy/UTF8.hi | %%PROFILE%%%%D_LIBSUBDIR_REL%%/Data/ByteString/Lazy/UTF8.p_hi | %%D_LIBSUBDIR_REL%%/Data/ByteString/UTF8.hi | %%PROFILE%%%%D_LIBSUBDIR_REL%%/Data/ByteString/UTF8.p_hi | %%D_LIBSUBDIR_REL%%/Data/String/UTF8.hi | %%PROFILE%%%%D_LIBSUBDIR_REL%%/Data/String/UTF8.p_hi | %%D_LIBSUBDIR_REL%%/HSutf8-string-0.3.4.o | %%D_LIBSUBDIR_REL%%/System/IO/UTF8.hi | %%PROFILE%%%%D_LIBSUBDIR_REL%%/System/IO/UTF8.p_hi | %%D_LIBSUBDIR_REL%%/libHSutf8-string-0.3.4.a | %%PROFILE%%%%D_LIBSUBDIR_REL%%/libHSutf8-string-0.3.4_p.a | %%D_LIBDIR_REL%%/%%D_REG%% | %%NOPORTDOCS%%%%DOCSDIR%%/LICENSE | %%NOPORTDOCS%%@dirrm %%DOCSDIR%% | @dirrm %%D_LIBSUBDIR_REL%%/System/IO | @dirrm %%D_LIBSUBDIR_REL%%/System | @dirrm %%D_LIBSUBDIR_REL%%/Data/String | @dirrm %%D_LIBSUBDIR_REL%%/Data/ByteString/Lazy | @dirrm %%D_LIBSUBDIR_REL%%/Data/ByteString | @dirrm %%D_LIBSUBDIR_REL%%/Data | @dirrm %%D_LIBSUBDIR_REL%%/Codec/Binary/UTF8 | @dirrm %%D_LIBSUBDIR_REL%%/Codec/Binary | @dirrm %%D_LIBSUBDIR_REL%%/Codec | @dirrm %%D_LIBSUBDIR_REL%% | @dirrm lib/utf8-string-0.3.4 | @exec %%REG_CMD%% | @unexec %%UNREG_CMD%% `---- Now, I've a (C)omment, (Q)uestion and (S)uggestion regarding that bsd.haskell.mk w.r.t. to the above port stuff: Q. As clear from the below output, the updated ports installs libraries in the ${PREFIX}/lib/${PORTNAME}-${PORTVERSION}/${GHC_VER} instead of the older ${PREFIX}/lib/${GHC_VER}/cabal. Is this convention going to be followed from now onwards, hmm... ? I'm a n00b in the Haskell world, so I'm not sure about this convention thingie, but anyhow package worked fine in that other location too, due to package registration script :). ,---- | abbe [hs-utf8-string-ghc] monte-cristo% pkg_info -xL utf8-string |fgrep lib | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Codec/Binary/UTF8/Generic.hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Codec/Binary/UTF8/Generic.p_hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Codec/Binary/UTF8/String.hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Codec/Binary/UTF8/String.p_hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Data/ByteString/Lazy/UTF8.hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Data/ByteString/Lazy/UTF8.p_hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Data/ByteString/UTF8.hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Data/ByteString/UTF8.p_hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Data/String/UTF8.hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/Data/String/UTF8.p_hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/HSutf8-string-0.3.4.o | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/System/IO/UTF8.hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/System/IO/UTF8.p_hi | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/libHSutf8-string-0.3.4.a | /usr/local/lib/utf8-string-0.3.4/ghc-6.8.3/libHSutf8-string-0.3.4_p.a | /usr/local/lib/utf8-string-0.3.4/register.sh `---- C. The bsd.haskell.mk seems to be good enough, but few things I've not understood esp. the workings and theory of the "funky" part due to my lack of category-theory background. So pardon me for my n00bness atm but I'll try to understand this, as the theory part interests me too :). S. The best way to test out the bsd.haskell.mk is by porting more and more ports to it. So I recommend we should port existing ports and new ports to the bsd.haskell.mk way and push to the 'infrastructure' branch (or any other special branch created for the purpose). And until bsd.haskell.mk makes into the official ports tree, we should also keep porting new/updated ports in the current way. Although this will be a bit time consuming, but this will be helpful in testing bsd.haskell.mk and improving it wherever it lacks. And whenever bsd.haskell.mk goes into the tree, the haskell ports can also be submitted. And IIRC, Samy mentioned on the IRC that he is running GHC 6.10.1 on his "centrino" box. Samy if you need some testers, could you please push your port to the repo so we can start working with it. And also will I be able to install multiple versions of GHC side-by-side, hmm...? Thanks -- Ashish SHUKLA

4 6

Development Plans
by Samy Al Bahra 26 Jan '09

26 Jan '09

A majority of our infrastructure is now ready to begin collaborating our FreeBSD Haskell efforts. I present here a proposal for collaborating our work in the git repository[1]. The following branches seem to be necessary, master branch) This will be a ``read-only'' branch consisting of daily merges of the FreeBSD ports repository. It will never be committed to otherwise. ports branch) This will consist of updates and minor changes to the ports we each maintain. This branch can be seen as being in a constant state of ``slush''. Ports committers may use this branch to commit our ``minor'' work with much ease. Commits will be made on a port-by-port basis and must be ordered based on dependency. For example, if I wish to commit a port A which depends on port B then I would first commit port B and then port A. This will make it easy for ports committers to generate diffs for their local repositories. ghc branch) With no doubt, GHC maintenance is central to our project. I would be creating a ghc meta-port in this branch and move current ghc to ghc-6-8. After this, I will be porting over ghc-6-10. The ``ghc'' port will always be pointing to the latest stable ghc release in ports. Every GHC update might involve changing/modifying legacy ports to point to the older versions of GHC they depend on (if necessary). infrastructure branch) This branch would contain our experimental work with bsd.haskell.mk. It would involve mainly bsd.haskell.mk changes for now. Once it is committed to the FreeBSD ports project, its changes will bubble back here (master -> ports -> ghc -> infrastructure) from FreeBSD itself. At this point, we would be ready to do the massive sweeping changes to the FreeBSD ports in the ports branch in a small step-wise manner (which should mean a non-disruptive experience for FreeBSD Haskell users). I propose that the ports branch merge in changes on a regular basis from the master branch, the ghc branch merge changes from the ports branch and the infrastructure branch merge in changes from the ghc branch. This is based on multiple factors including relative ease of merging a branch's work upstream. The infrastructure branch will also always depend on GHC which will always serve the needs of the ports branch which will always be similar to the master branch (as it involves no sweeping changes). The following simple diagram might help describe this, FreeBSD Project -> Master -> Ports -> GHC -> Infrastructure ^ | | | | | | | | | '-<-----<-----V----<---V---<----V-----<-----V The following issues need to be addressed, github mirror: Ashish, could you give us the URL to the github mirror? Should this be a weekly mirror? Daily? Mailing list usage: This is really just a note to certain people (cough, cough, pgj@) that you should generally have the "To" line set to the mailing list and CC: individuals involved. If the "To" line is not set properly some mail clients will not be able to respond properly. This has already resulted in several lost messages. Let's get the ball rolling! What do you guys think of the above proposal? If we are in agreement, I can go ahead and work on the proper commit scripts for the master branch and create the following branches. I plan to begin the GHC work immediately. We should be able to work mostly in parallel this way. 1: git://git.applicative.org/haskell/ports Regards. -- Samy Al Bahra <sbahra(a)applicative.org>

4 5

Periodic Update Summary for Hackage Ports
by HackageDB Port Checking Service 24 Jan '09

24 Jan '09

Current Time: Sun Jan 25 00:00:25 UTC 2009 The list of ports to be updated: darcs 2.0.2 -> 2.2.0 (haskell(a)FreeBSD.org) glut 2.1.1.1 -> 2.1.1.2 (haskell(a)FreeBSD.org) haddock 2.1.0 -> 2.4.1 (haskell(a)FreeBSD.org) hscolour 1.10.1 -> 1.11 (jacula(a)gmail.com) lhs2tex 1.13 -> 1.14 (mainland(a)apeiron.net) utf8-string 0.3.3 -> 0.3.4 (wahjava(a)gmail.com) x11 1.4.1 -> 1.4.5 (haskell(a)FreeBSD.org) xmonad 0.8 -> 0.8.1 (matt.guegan(a)free.fr) xmonad-contrib 0.8 -> 0.8.1 (matt.guegan(a)free.fr) 9 ports total.

1 0

Re: [Freebsd-haskell] Development Plans
by Jacula Modyun 21 Jan '09

21 Jan '09

Sorry but the two links of my Prs are incorrect: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124047 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126012 Giuseppe ;-)

1 0

Some Topics to Discuss...
by Gabor PALI 21 Jan '09

21 Jan '09

Hi there, Since we have an own mailing list at last, I would like to raise some issues to be discussed. I do not why, but I prefer e-mail over any other communication method, because it is stored (at several places) and I have time to process the input and produce the output :) (And it also strikes a balance between the different time zones we live in.) So, excuse me I am using this method, but I feel this the most "official" way to discuss any effort-related issue (but please, refute me if I am wrong...) I have collected some issues (without the claim for completeness) to start some threads and discussions on this list. Feel free to pick any of the items to answer or express your ideas (even in a separate thread) or raise other issues. Sorry in advance if I touch things those have been settled on IRC. I think the problems and the decisions regarding them should be documented somehow, anyway. - Range of ports we maintain: In my opinion, it would be useful to identify which type of ports we maintain: in my first thoughts, it would be interesting to maintain GHC and libraries (mostly found on HackageDB [1]), but not complete applications (like Pandoc, that is also available via HackageDB, but it is a standalone application (however, it incorporates a library...) and it does not include the "hs-" prefix in its port name in the FreeBSD ports tree). So, in brief: I suggest to add and maintain "hs-*" packages and lang/ghc. (More than enough :P) - MAINTAINER field of the ports we maintain: To uniformize the effort, I suggest to set the maintainer all of the maintained ports to "freebsd-haskell(a)haskell.org" (address of this list), so any of the members could easily fix and add new ports, etc. If somebody new wants to tackle these ports, he or she should contact us first and then delegate his or her patches though this list, and so on. - Elimination of the "-ghc" suffix: Samy advised to get rid of those "-ghc" suffixes in the port names. I asked haskell(a)freebsd.org guys about this suffix, and Volker told me that it was used to identify the ports that had been ported to GHC exactly. Since GHC is the center of our efforts, I clearly agree with the elimination these suffixes. (I do not whether it has been already done meanwhile, though.) But we have to be careful with this, because many ports depend on hs- ports, so this kind of "refactorizaton" might result a huge patch (what it is not necessarily encouraged by FreeBSD porters)(?) As a side note: packages with the "-ghc" suffix use a different destination directory, I hope you know this. I think this should be also be unified. - Composition of a "bsd.haskell.mk": It is a must, nobody can deny. In the first round, I do not think it should be placed right in the "ports/Mk" directory, because people at the BSD# Project [2] (I think I am going to refer them many times) store their own ".mk" file at the heart of their ports, lang/mono [3]. In my opinion, following this behavior would save the initial efforts from the burden of several port management tests and tasks ("experimental ports build" -- Mark Linimon mentioned these in the PR where a bsd.haskell.mk was offered [4]). So, I suggest to add this file to the lang/ghc port first. About its structure: I suggest to employ some "build magic" to make its invocation automatic. For example, every port with the "hs-" prefix (or in the "haskell" category) could automagically include this .mk file. I do not think it would be hard to implement as this technique has been already used by bsd.xorg.mk [5] (e.g. around line 53). The actual structure of this file should be derived from the current hs-* ports -- I think it is easy, because many of these ports have a lot of constructs in common, so I would say (without experimenting with anything) their Makefiles could be even reduced to about 2-5 lines(!) (including the port name and version, may be the dependencies) in an optimal case by a good .mk file. (But I am naive! :)) I think this approach could even make us re-think whether a cabal2port converter is really needed. - Interference(?) with cabal-install: A few months ago, I created a preliminary port for cabal-install [6]. I think this or something like that should be added to our collection, so "the real bleeding edge" users do not have to wait for us with the ports. It is okay, but it raises(?) an interesting problem: what if somebody starts to use both the ports _and_ cabal-install and even accidentally mixes them? (E.g. installs something with pkg_add then updates it from cabal-install or deletes it, and so on -- vice versa) At the moment, I do not see any trivial solution to this problem, so any comments would be welcome. - Merging our ports with the official FreeBSD ports tree: port trees out of the official FreeBSD port tree (like KDE, GNOME, BSD# etc.) use different techniques to merge ("engraft") their trees. Ashish mentioned that FreeBSD does not have a standard method for implemeting this when I mentioned the famous marcusmerge(8) [7] earlier. He was not happy with this approach, but I found another meanwhile, called portshaker [8] (from BSD#). I have not tried it yet, but it is a yet another way to solve this problem. - Quarterly Status Report: A short note on that we could advertise ourselves in the recent FreeBSD Quarterly Status Report. However the submission date past (Jan 14, 2009) for the latest one, but as I taught, I think there might be a chance to push one more simple report to Brad :) If I got some nods, I post a draft here and then to monthly@. Of course, it is not a tragedy if we miss this, we can supply it later on. - Things to be Committed: I am (still) happy to tinderbuild and commit Haskell port patches, but please, send me them in email if possible. Note that I am not a ports committer, but with the help of Martin Wilke (miwi@) I can work with these patches. Of course, the more (active) committers on this list the better :) - GHC 6.8.10: What is up with GHC? What are the exact obstacles to get the latest version ported? Has anybody tried it? (I am just curious.) That is all for today. Thanks for your attention. Cheers, :g [1] http://hackage.haskell.org/packages/hackage.html [2] http://www.mono-project.com/Mono:FreeBSD [3] http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/bsd.mono.mk [4] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126012 [5] http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.xorg.mk?annotate=1.8 [6] http://people.freebsd.org/~pgj/patches/2008-11-01/cabal-install-freebsd.tar… [7] http://www.marcuscom.com/marcusmerge.8.html [8] http://bsd-sharp.googlecode.com/files/portshaker-0.0.8.tar.gz

3 5

Re: [Freebsd-haskell] (Automatically) Watching Hackage Updates?
by Gabor PALI 19 Jan '09

19 Jan '09

Hello, On Sun, Jan 18, 2009 at 4:00 PM, Samy Al Bahra <sbahra(a)repnop.org> wrote: > This sounds great. By the way, you might want to set the "To" line to > the mailing list and instead CC the individuals involved, atleast for > archiving reasons. I added most of the ports from the haskell category, so my small script watches 30 hackage ports at the moment. Some comments: - the following ports are omitted: - devel/haddock-docs port is not added as it is coupled with its hackage port. - is graphics/hs-HGL-ghc the same as graphics/hs-hgl? - watching devel/hs-drift is not supported yet (too tricky for the script). - x11-toolkits/hs-frantk is not on hackage. - x11-toolkits/hs-gtk2hs is not on hackage. - devel/hs-hat is not on hackage and it will be deleted anyway. - devel/hs-hpl is not on hackage and it will be deleted anyway. - devel/hs-hdoc is not on hackage. - devel/hs-hmake is not on hackage. - devel/hs-hscolour-docs port is not added as it is coupled with its hackage port. - devel/hs-hdoc is not on hackage. - ports for compilers/interpreters (ghc, hugs, ohugs, nhc98). - devel/asdlgen (not a real haskell package). - the script will only send mail if there is any port to be updated. - maintainers are added in parenthesis. - no CCing for now, sending output directly to this list. - the script runs from freefall weekly (every Sunday 0:00 UTC). :g

2 1

Periodic Update Summary for Hackage Ports
by HackageDB Port Checking Service 18 Jan '09

18 Jan '09

Current Time: Sun Jan 18 21:27:01 UTC 2009 The list of ports to be updated: alex 2.2 -> 2.3.1 (haskell(a)FreeBSD.org) cpphs 1.5 -> 1.6 (haskell(a)FreeBSD.org) glut 2.1.1.1 -> 2.1.1.2 (haskell(a)FreeBSD.org) haddock 2.1.0 -> 2.4.1 (haskell(a)FreeBSD.org) happy 1.17 -> 1.18.2 (haskell(a)FreeBSD.org) haxml 1.13.3 -> 1.19.4 (haskell(a)FreeBSD.org) lhs2tex 1.13 -> 1.14 (mainland(a)apeiron.net) x11 1.4.1 -> 1.4.5 (haskell(a)FreeBSD.org) xmonad 0.8 -> 0.8.1 (matt.guegan(a)free.fr) xmonad-contrib 0.8 -> 0.8.1 (matt.guegan(a)free.fr) zip-archive 0.1.1.1 -> 0.1.1.3 (haskell(a)FreeBSD.org) 11 ports total.

1 0

(Automatically) Watching Hackage Updates?
by Gabor PALI 18 Jan '09

18 Jan '09

Hello, Does anybody know a method for watching Haskell package updates automatically? I am thinking of a method where I can receive an email or an RSS feed, etc, on every update of a given hackage. That would make easier to maintain hs-* ports (at least for me). In a normal case, that would be a mailing list, but I do not think every hackage has an own list :) However, hackage.haskell.org may have a method for providing such information. May be upload log [1] is for that. :g [1] http://hackage.haskell.org/packages/archive/log

2 2

Things to do (re: Some Topics to Discuss...)
by Samy Al Bahra 17 Jan '09

17 Jan '09

Hello, For some reason, I did not receive Gabor's e-mail. This has made it hard for me to respond properly to his e-mail. As such, I have copy pasted portions of his e-mail for convenience. > - MAINTAINER field of the ports we maintain: To uniformize the effort, > I suggest to set the maintainer all of the maintained ports to > "freebsd-haskell at haskell.org" (address of this list), so any of the > members could easily fix and add new ports, etc. If somebody new > wants to tackle these ports, he or she should contact us first and > then delegate his or her patches though this list, and so on. This is a bad idea. Certain individuals are *responsible* for certain ports. Since FreeBSD-haskell is a public list, this means that anyone may respond and accept incoming patches of ports. I suggest that we stick to having individual maintainers for now and switch maintainers once bsd.haskell.mk is ready to a private mailing list consisting of us initial porters. > - Composition of a "bsd.haskell.mk": It is a must, nobody can deny. > In the first round, I do not think it should be placed right in the > "ports/Mk" directory, because people at the BSD# Project [2] (I think > I am going to refer them many times) store their own ".mk" file at the > heart of their ports, lang/mono [3]. In my opinion, following this > behavior would save the initial efforts from the burden of several > port management tests and tasks ("experimental ports build" -- Mark > Linimon mentioned these in the PR where a bsd.haskell.mk was offered > [4]). So, I suggest to add this file to the lang/ghc port first. This sounds good. > I think this approach could even make us re-think whether a > cabal2port converter is really needed. No, it doesn't. Unless we have implemented a query-complete *.cabal parser in bsd.haskell.mk, there will remain to be massive productivity boosts with such a thing (ones much greater than having a bsd.haskell.mk when it comes to Cabal). > - Merging our ports with the official FreeBSD ports tree: port trees > out of the official FreeBSD port tree (like KDE, GNOME, BSD# etc.) use > different techniques to merge ("engraft") their trees. Ashish > mentioned that FreeBSD does not have a standard method for implemeting > this when I mentioned the famous marcusmerge(8) [7] earlier. He was > not happy with this approach, but I found another meanwhile, called > portshaker [8] (from BSD#). I have not tried it yet, but it is a yet > another way to solve this problem. We discussed this, and we have agreed to use a git respository. We will need to discuss these initial issues and a separate collection of e-mails will be sent out in order to tackle these issues in detail. We will make it easy for you to generate patches on a per-port basis and per-branch based on dependency. Since none of us are committers, how exactly you decide to merge is irrelevant to us as long as it doesn't involve breaking things. :-P We will need to discuss some details in a separate thread in order to keep requirements/methods crystal clear. > Quarterly Status Report: A short note on that we could advertise > ourselves in the recent FreeBSD Quarterly Status Report. However the > submission date past (Jan 14, 2009) for the latest one, but as I > taught, I think there might be a chance to push one more simple report > to Brad :) If I got some nods, I post a draft here and then to > monthly at . Of course, it is not a tragedy if we miss this, we can > supply it later on. I think this is a bad idea. Let us get some serious work under our belt before advertising our efforts. > - GHC 6.8.10: What is up with GHC? What are the exact obstacles to > get the latest version ported? Has anybody tried it? (I am just > curious.) This is a non-trivial issue. This will be discussed in a separate thread as to keep requirements/directions crystal clear. I suggest an overhaul of how these ports are structured to begin with in order to save ports which do not build or function properly with GHC 6.10. Regards. -- Samy Al Bahra [http://repnop.org]

4 3

GHC 6.10.x
by Gabor PALI 16 Jan '09

16 Jan '09

On Sat, Jan 17, 2009 at 1:08 AM, Gabor PALI <pgj(a)freebsd.org> wrote: [..] > - GHC 6.8.10: What is up with GHC? What are the exact obstacles to > get the latest version ported? Has anybody tried it? (I am just > curious.) I should have queried the PR database first and I should have learnt to type (of course, I wanted to write GHC 6.10.x -- sorry) :P See [1][2]. :g [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/130217 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/130218

1 0