Haskell's state in Arch & near future

Vesa Kaihlavirta

5 Nov 2011 5 Nov '11

12:44 p.m.

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

Show replies by date

Peter Hercek

5 Nov 5 Nov

7:22 p.m.

Hi Vesa, When doing all the changes could you assign all packages which depend on ghc to haskell group (or maybe some better group name) so that it is easy to postpone any haskell related update? For more info see: http://www.haskell.org/pipermail/arch-haskell/2011-October/001722.html The group needs to be added for both [extra], [community] and then [haskell] for it to make sense. The other haskell repository is: [haskell] Server = http://andromeda.kiwilight.com/$repo/$arch Magnus Therning maintains it. He is doing a great job. I have it before [community] in pacman.conf since it has gtk2hs with glade. I personally do not mind if we would move quicker than haskell platform. Though it means additional work so it is up to the maintainers. Dropping all haskell packages from aur is a good idea. Maybe we should leave there only one "dummy" package which would point haskell newbies to a description how to get additional haskell packages which a archlinux user would expect to be in aur. Peter. On 11/05/2011 01:44 PM, Vesa Kaihlavirta wrote:

...

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

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

Linus Arver

10:16 p.m.

On Sat, Nov 05, 2011 at 08:22:54PM +0100, Peter Hercek wrote:

...

Dropping all haskell packages from aur is a good idea. Maybe we should leave there only one "dummy" package which would point haskell newbies to a description how to get additional haskell packages which a archlinux user would expect to be in aur.

I also agree about dropping haskell packages from AUR. From my personal experience, 90% of haskell packages on AUR are broken because of outdated dependencies. Whoever is maintaining the "arch-haskell" account (some mystery person?) has been unable to keep up with the pace of "outdated" notifications, anyway --- probably due to the sheer volume/tediousness of the work. Besides, the cabal2arch utility already does exactly what the AUR packages do. You could certainly have a "dummy" package for newbies, and I think a big, bolded message in the Arch Wiki could go along with that nicely. -Linus

Magnus Therning

6 Nov 6 Nov

9:16 a.m.

On Sat, Nov 05, 2011 at 08:22:54PM +0100, Peter Hercek wrote: [...]

...

I personally do not mind if we would move quicker than haskell platform. Though it means additional work so it is up to the maintainers.

The main problem with actually getting the speed we'd like is that the speed of upstream developers is a limiting factor. With each package that is added to ArchHaskell we add yet another possible speed bump. Finding a solution is tricky, since the only option that doesn't require a lot of resources is dropping packages.

...

Dropping all haskell packages from aur is a good idea. Maybe we should leave there only one "dummy" package which would point haskell newbies to a description how to get additional haskell packages which a archlinux user would expect to be in aur.

IIRC yaourt can install packages directly from hackage. Is that still the case? If so I'll be more than happy to disown all AUR packages and close down the arch-haskell account. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

Leif Warner

8:28 p.m.

On Sun, Nov 6, 2011 at 1:16 AM, Magnus Therning wrote:

...

On Sat, Nov 05, 2011 at 08:22:54PM +0100, Peter Hercek wrote: [...]

...
I personally do not mind if we would move quicker than haskell platform. Though it means additional work so it is up to the maintainers.

The main problem with actually getting the speed we'd like is that the speed of upstream developers is a limiting factor. With each package that is added to ArchHaskell we add yet another possible speed bump. Finding a solution is tricky, since the only option that doesn't require a lot of resources is dropping packages.

I've noticed, when trying to update some things, that there's been a few packages moving past Haskell Platform and requiring GHC 7.2.1.

...

...
Dropping all haskell packages from aur is a good idea. Maybe we should leave there only one "dummy" package which would point haskell newbies to a description how to get additional haskell packages which a archlinux user would expect to be in aur.

IIRC yaourt can install packages directly from hackage. Is that still the case? If so I'll be more than happy to disown all AUR packages and close down the arch-haskell account.

/M

Yaourt doesn't do that, afaik. That was bauerbill I think. It's nice having the Haskell packages on AUR, but not if they're not kept up-to-date. Many of the arch-haskell PKGBUILDs that are "outdated" up there will still build fine if the dependencies on specific versions are removed. If we're going to the trouble to maintain working PKGBUILDs for the binary repo, why not sync those up to AUR, and disown the rest? -Leif

...

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

Magnus Therning

11:02 p.m.

On Sun, Nov 06, 2011 at 12:28:29PM -0800, Leif Warner wrote:

...

On Sun, Nov 6, 2011 at 1:16 AM, Magnus Therning wrote:

...
On Sat, Nov 05, 2011 at 08:22:54PM +0100, Peter Hercek wrote: [...]

...
I personally do not mind if we would move quicker than haskell platform. Though it means additional work so it is up to the maintainers.

The main problem with actually getting the speed we'd like is that the speed of upstream developers is a limiting factor. With each package that is added to ArchHaskell we add yet another possible speed bump. Finding a solution is tricky, since the only option that doesn't require a lot of resources is dropping packages.

I've noticed, when trying to update some things, that there's been a few packages moving past Haskell Platform and requiring GHC 7.2.1.

That's not such a big problem per se. The real issue is when some packages don't move up to 7.2.1 but we want to. In the past I've sent out emails to upstream maintainers to encourage them to update. So far that has worked fairly well, but I don't think that will be the case always. Then we're faced with the option of either keeping everything thing back, update the package ourselves, or drop the package completely. Neither option is very good.

...

...
...
Dropping all haskell packages from aur is a good idea. Maybe we should leave there only one "dummy" package which would point haskell newbies to a description how to get additional haskell packages which a archlinux user would expect to be in aur.

IIRC yaourt can install packages directly from hackage. Is that still the case? If so I'll be more than happy to disown all AUR packages and close down the arch-haskell account.

Yaourt doesn't do that, afaik. That was bauerbill I think. It's nice having the Haskell packages on AUR, but not if they're not kept up-to-date. Many of the arch-haskell PKGBUILDs that are "outdated" up there will still build fine if the dependencies on specific versions are removed.

Yes, you are right, it was bauerbill that did that.

...

If we're going to the trouble to maintain working PKGBUILDs for the binary repo, why not sync those up to AUR, and disown the rest?

That's absolutely an option, though if others do add packages to AUR, that we later add to [haskell] then we run the very real risk of having Haskell packages on AUR that don't build with each other. That's not a terrible situation in my opinion though. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

Peter Hercek

7 Nov 7 Nov

10:03 a.m.

On 11/07/2011 12:02 AM, Magnus Therning wrote:

...

That's not such a big problem per se. The real issue is when some packages don't move up to 7.2.1 but we want to. In the past I've sent out emails to upstream maintainers to encourage them to update. So far that has worked fairly well, but I don't think that will be the case always. Then we're faced with the option of either keeping everything thing back, update the package ourselves, or drop the package completely. Neither option is very good.

Such packages should be dropped by default. That is the only option since we do not have resources to overtake maintenance of all the packages as original maintainers will go unresponsive. There may be somebody in arch-haskell who needs the packages and he/she may want to overtake their maintenance. So it would be a good idea to post to arch-haskell which packages are going to be dropped if a new maintainer is not found in arch-haskell. Peter.

Magnus Therning

6 Nov 6 Nov

9:10 a.m.

On Sat, Nov 05, 2011 at 02:44:16PM +0200, Vesa Kaihlavirta wrote:

...

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.

I largely agree with this. HP has done much good for Haskell, but I feel it's mostly serves as a good starting point for people new to the language and its community. On platforms lacking good package management (and here I mean both tools and people) it plays a crucial role. On a platform like Arch, with good package management and a stated goal of being nimble and at the edge, it isn't needed as much.

...

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.

I really appreciate this, since a complete re-build of ArchHaskell's repo took a couple of days last time I attempted it--and we've added more even packages since.

...

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.

It is easy, but time consuming. Just fire any questions on this to the mailing list, or directly to me, and I'll try to answer as best I can.

...

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.

I agree fully. Since I got back to ArchHaskell I've not been very good with updating packages on AUR. The only packages that have received updates are the ones that are in our repo too, that means only about 300 packages get updates, out of roughly 2000 owned by the arch-haskell user. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

Adrien Haxaire

7 Nov 7 Nov

9:26 p.m.

Hello, I am using Arch for two weeks, mainly becaused I got bored of ubuntu and because of the good reputation it has in the Haskell community. I am new in Haskell too by the way. What I can say is that after playing a bit around with AUR I just dropped it and now use cabal for packages that are not in the repos. These few lines to say that I fully agree with your proposition. Best regards, Adrien Le 05/11/2011 13:44, Vesa Kaihlavirta a écrit :

...

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

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

Vesa Kaihlavirta

20 Nov 20 Nov

12:12 p.m.

Hey, Progress report. There's now a ghc-7.2.2-1 in testing, but there are some complications. Mainly, that version doesn't handle removing of older haskell-platform very nicely. Also, I've found out a little late that the 7.2 series is supposedly some sort of a "technology preview" branch. While I think it's totally irresponsible and moronic for the GHC devs to release a point release that's not supposed to be widely used, we'll have to think about if we really want 7.2 or do we wait for 7.4. Any opinions on that? --vk

Nicolas Pouillard

12:34 p.m.

On Sun, Nov 20, 2011 at 1:12 PM, Vesa Kaihlavirta wrote:

...

Hey,

Progress report.

There's now a ghc-7.2.2-1 in testing, but there are some complications. Mainly, that version doesn't handle removing of older haskell-platform very nicely.

Also, I've found out a little late that the 7.2 series is supposedly some sort of a "technology preview" branch. While I think it's totally irresponsible and moronic for the GHC devs to release a point release that's not supposed to be widely used, we'll have to think about if we really want 7.2 or do we wait for 7.4.

Any opinions on that?

I lean toward waiting for 7.4. This may be a way to let another chance to haskell-platform to survive. -- Nicolas Pouillard http://nicolaspouillard.fr

Felipe Almeida Lessa

1 p.m.

On Sun, Nov 20, 2011 at 10:34 AM, Nicolas Pouillard wrote:

...

I lean toward waiting for 7.4. This may be a way to let another chance to haskell-platform to survive.

+1 And 7.4 isn't really far away, is it? Cheers, -- Felipe.

Peter Simons

2:57 p.m.

Hi Vesa,

...

I've found out a little late that the 7.2 series is supposedly some sort of a "technology preview" branch. While I think it's totally irresponsible and moronic for the GHC devs to release a point release that's not supposed to be widely used [...].

actually, GHC 7.2.x is quite stable and it's perfectly alright to use it in production. It's been dubbed a "technology preview" because the compiler breaks backwards compatibility in ways that require library authors to update their code. Those who don't want to deal with that situation ought to stick to 7.0.4. However, those incompatibilities are not going to disappear by themselves. The 7.4.x release is not going to be different in that regard.

...

We'll have to think about if we really want 7.2 or do we wait for 7.4.

It comes down to the question: are you willing to patch lots of packages to fix compilation? If you don't want to do that, then you'll be stuck with 7.0.4 for quite some time. If you don't mind patching packages to fix compilation, then updating to 7.2.2 right now is a fine choice. Take care, Peter

Magnus Therning

4:44 p.m.

On Sun, Nov 20, 2011 at 03:57:04PM +0100, Peter Simons wrote:

...

Hi Vesa,

...
I've found out a little late that the 7.2 series is supposedly some sort of a "technology preview" branch. While I think it's totally irresponsible and moronic for the GHC devs to release a point release that's not supposed to be widely used [...].

actually, GHC 7.2.x is quite stable and it's perfectly alright to use it in production. It's been dubbed a "technology preview" because the compiler breaks backwards compatibility in ways that require library authors to update their code. Those who don't want to deal with that situation ought to stick to 7.0.4. However, those incompatibilities are not going to disappear by themselves. The 7.4.x release is not going to be different in that regard.

...
We'll have to think about if we really want 7.2 or do we wait for 7.4.

It comes down to the question: are you willing to patch lots of packages to fix compilation? If you don't want to do that, then you'll be stuck with 7.0.4 for quite some time. If you don't mind patching packages to fix compilation, then updating to 7.2.2 right now is a fine choice.

I'm under the impression that there already are rather a lot of packages that are updated to deal with changes in 7.2. I don't have any numbers on that though, are there any such numbers ready available? If so they could offer a good indication of the amount of work that an upgrade would require. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

Bernardo Barros

6:20 p.m.

Just an idea: update ghc in [testing] and then [extra] to 7.0.4 upload ghc 7.2.2 to a separate repo called [haskell-preview] Testing is very important, but a stable and robust version is also very important, so people that are able to test things can use the [haskell-preview] repo.

Peter Simons

8:36 p.m.

Hi Magnus,

...

I'm under the impression that there already are rather a lot of packages that are updated to deal with changes in 7.2. I don't have any numbers on that though, are there any such numbers ready available?

I am not aware of any statistics that estimate the percentage of packages broken with GHC 7.2.x, unfortunately, but even if we'd have those kind of statistics, the numbers might be deceptive. For instance, one of the packages that is broken is 'zlib'. zlib itself seems to compile fine, but the resulting package won't link when used by others. Now, that's just one package, but the effect of that particular problem is quite significant, because it cascades down the dependency chain. See http://hydra.nixos.org/job/nixpkgs/trunk/haskellPackages_ghc722.yesod for a concrete example. Furthermore, the problem exists the other way round, too. There are packages that build fine with 7.2.x, but won't compile with older GHC versions, such as 'yap' or the latest version of 'repa'. Whether that is a problem or not depends on what you're trying to do, obviously. Personally, I have come to prefer NixOS http://nixos.org/ for Haskell development, because it allows me to install any number of different GHC versions simultaneously. Take care, Peter

Magnus Therning

8:50 p.m.

On Sun, Nov 20, 2011 at 09:36:54PM +0100, Peter Simons wrote:

...

Hi Magnus,

...
I'm under the impression that there already are rather a lot of packages that are updated to deal with changes in 7.2. I don't have any numbers on that though, are there any such numbers ready available?

I am not aware of any statistics that estimate the percentage of packages broken with GHC 7.2.x, unfortunately, but even if we'd have those kind of statistics, the numbers might be deceptive. For instance, one of the packages that is broken is 'zlib'. zlib itself seems to compile fine, but the resulting package won't link when used by others. Now, that's just one package, but the effect of that particular problem is quite significant, because it cascades down the dependency chain. See

http://hydra.nixos.org/job/nixpkgs/trunk/haskellPackages_ghc722.yesod

for a concrete example.

I can't figure out what I'm looking at on that page, it looks like yesod fails to build. I assume that's due to zlib, since that's what you're talking about here. I assume there's a bug report upstream about the issue that would offer more useful information than a build log, or maybe a mail discussion somehwere?

...

Furthermore, the problem exists the other way round, too. There are packages that build fine with 7.2.x, but won't compile with older GHC versions, such as 'yap' or the latest version of 'repa'. Whether that is a problem or not depends on what you're trying to do, obviously.

For us that isn't a problem, the move to 7.2 would be one-way. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

Bernardo Barros

8:56 p.m.

Magnus: The testing I'm talkgin about is to build [community] with this *preview* release version of ghc. Then, you have to play with those packages to see if they are ready to use. GHC is outdated in [extra] in respect to the stable branch. Why not update it from 7.0.3 to 7.0.4 before?

Bernardo Barros

11:19 p.m.

Hello Vesa, You just updated an outdate version of xmonad{,contrib}, the last one is 0.10 (Nov 2011)

Vesa Kaihlavirta

21 Nov 21 Nov

7:27 a.m.

On Mon, Nov 21, 2011 at 1:19 AM, Bernardo Barros wrote:

...

Hello Vesa,

You just updated an outdate version of xmonad{,contrib}, the last one is 0.10 (Nov 2011)

That wasn't me... --vk

Bernardo Barros

6:55 p.m.

On Sun, Nov 20, 2011 at 11:27 PM, Vesa Kaihlavirta wrote:

...

On Mon, Nov 21, 2011 at 1:19 AM, Bernardo Barros wrote:

...
Hello Vesa,

You just updated an outdate version of xmonad{,contrib}, the last one is 0.10 (Nov 2011)

That wasn't me...

Aren't you the maintainer? https://www.archlinux.org/packages/community/x86_64/xmonad/ This version is very old actually (0.2), would be nice to have the new one (0.10).

Bernardo Barros

6:57 p.m.

Correction: 0.9.2 and 0.10, actually not so old, but still outdated.

Magnus Therning

5:07 a.m.

Den 20 nov 2011 21:56 skrev "Bernardo Barros" :

...

Magnus:

The testing I'm talkgin about is to build [community] with this *preview* release version of ghc. Then, you have to play with those packages to see if they are ready to

use. Bra, då vill vi ju ha samma sak. /M

Magnus Therning

9:21 a.m.

On Mon, Nov 21, 2011 at 06:07, Magnus Therning wrote:

...

Den 20 nov 2011 21:56 skrev "Bernardo Barros" :

...
Magnus:

The testing I'm talkgin about is to build [community] with this *preview* release version of ghc. Then, you have to play with those packages to see if they are ready to use.

Bra, då vill vi ju ha samma sak.

Ah, damn it. That shouldn't have been written in Swedish. That ought to teach me, trying to answer emails on the way to yoga morning practice at 6am is no good idea :-) "Good, then we want the same thing" is what I meant to write. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Adrien Haxaire

9:56 a.m.

On Mon, 21 Nov 2011 10:21:35 +0100, Magnus Therning wrote:

...

Ah, damn it. That shouldn't have been written in Swedish. That ought to teach me, trying to answer emails on the way to yoga morning practice at 6am is no good idea :-)

"Good, then we want the same thing" is what I meant to write.

/M

ha ha no problem when it is easily translatable with google :)

Magnus Therning

20 Nov 20 Nov

7:57 p.m.

On Sun, Nov 20, 2011 at 02:12:03PM +0200, Vesa Kaihlavirta wrote:

...

Hey,

Progress report.

There's now a ghc-7.2.2-1 in testing, but there are some complications. Mainly, that version doesn't handle removing of older haskell-platform very nicely.

Howcome? Also, any ETA on when the Haskell packages in [community] will be available compiled with GHC 7.2? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

Bernardo Barros

8:05 p.m.

All these are speculations or you guys did test?

Magnus Therning

8:16 p.m.

On Sun, Nov 20, 2011 at 12:05:08PM -0800, Bernardo Barros wrote:

...

All these are speculations or you guys did test?

Speculations on what? What tests are you talking about? I'd like to see all of [community]'s Haskell libs turn up in [community-testing] compiled with GHC7.2 so I can attempt a move of [haskell] onto that version of GHC. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@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

4979

Age (days ago)

4995

Last active (days ago)

List overview

Download

27 comments

10 participants

participants (10)

Adrien Haxaire
Bernardo Barros
Felipe Almeida Lessa
Leif Warner
Linus Arver
Magnus Therning
Nicolas Pouillard
Peter Hercek
Peter Simons
Vesa Kaihlavirta