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
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 quit
Hi,
I set up a mail reflector that forwards comments from AUR to this
mailing list. Is that service still required?
Take care,
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi Magnus,
I reckon all this means that you won't be needing a cron job to sync
~magnus/h4a to ~haskell/ anymore, right? I can create one, of course,
but that would mean that Nicolas would have to push updates to the
directories in magnus home, or they would be overwritten every time the
cron job
Hi Magnus,
> As I've mentioned both earlier here and in an earlier email to the
> list I don't have enough access to the server hosting [archhaskell],
> so for the time being I'm publishing the updated builds in a private
> repository on the same server.
if you think that would help, then I c
Hi guys,
I have come to realize that I can no longer commit significant time and
effort to this project. I may be able to perform another few occasional
updates, but I cannot do so on a regular basis. Does anyone feel able to
take over maintenance of HABS and, by extension, AUR?
Take care,
Peter
Duh, wrong mailing list! I'm sorry guys, please disregard my previous message.
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi guys,
is anyone aware of a reason why perl should *not* be passed as a build
input to util-linux-ng (other than the fact that doing so would trigger
a re-build of stdenv)?
Assuming that making the change would be okay, where could I make it? Is
the stdenv-updates branch still active?
Take car
Hi guys,
we have a new release of cabal2arch, the binary repository for x86 has
been re-built, and all updated PKGBUILDs have been uploaded to AUR. As
far as I can tell, the transition to GHC 7.0.3 is complete.
Take care,
Peter
___
arch-haskell mailin
Hi Fabio,
> Note that I tried makeworld script and rsync failed to connect to
> andromeda.kiwilight.com but I can ping the server.
the rsync server was down, apparently, but Kaiting has fixed the
problem. Rsync should now work fine.
Take care,
Peter
__
Hi Leif,
> Should we put these instructions up on the README of the GitHub project
> for HABS / ArchHaskell ?
you are right, we probably should. I didn't do it at the time, because I
had the impression that various contributors were using all kinds of
different ways to work on HABS, and I didn'
Hi Magnus,
> Isn't this still the same workflow you had when you wrote [1]?
no, it's not.
Take care,
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi Fabio,
> Packages must be tested. Before updating AUR I would compile the
> needed dependencies and only that, faster then makeword.
why do you assume that your builds would be faster than makeworld?
>> I'll try to describe my work-flow briefly: [...]
>
> The work flow can feet, but kno
Hi Fabio,
> yesterday I submitted a patch to HABS repository just because I met
> some out-of-date packages in AUR. Then I read the "story" of this
> group in this mailing list and thought that I can give some help. I
> think I can take responsibility for a bunch of packages and care for
> up
Hi,
as far as I remember, haskell-binary used to be in [extra], but now it's
gone. Does anyone know what happened?
Take care,
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi Leif,
> Was wondering if we should make a tool or if we already have one to see
> which packages we maintain have updates available.
I use the following short program to do that:
http://github.com/peti/arch-haskell/blob/master/scripts/find-updates.hs
> One thing that could be done woul
Hi Leif,
> So, I was thinking of firing up a Large (7.5 GB) EC2 instance to
> compile it.
that's a nice idea. :-)
> Does a similar option exist for 32-bit?
No, I'm afraid not. I have two ArchLinux boxes available that I use for
building the i686 repository, but neither machine has more than
Hi Leif,
> I was trying to add the IDE Leksah, and some of the parts have
> dependencies on specific versions of haddock. Haddock is provided by
> the ghc package, but it's not listed in ghc-pkg list.
why would it be necessary for Haddock to be listed by ghc-pkg? The way I
see it, "cabal confi
Hi guys,
I was informed by Kaiting -- who kindly hosts the binary repository on
his server --, that the andromeda.kiwilight.com URL is considered
obsolete. Instead, the binary repository should be configured as
follows:
[haskell]
Server = http://www.kiwilight.com/haskell/$arch
The old URL is
Hi Linus,
if we'd change cabal2arch to set '-p' by default (in addition to
'--enable-shared', which we already set), then all library packages
are going to be compiled *4 times*. Compile times will be twice as
much as they are today. That is a fairly significant change, which
is going to affect al
Hi Mathew,
>> Is there any specific package currently not included in HABS that
>> you would like to see supported?
>
> My main issue was basically with packages such as yesod [...].
indeed, yesod currently doesn't compile. If you happen to have any fixes
or patches you could share to remedy
Hi Mathew,
thank you for sharing your thoughts and insights.
> I guess I am creating this thread due to the frustrations of using
> cabal2arch/AUR for haskell packages (instead of using the standard
> cabal install).
Your frustration is quite understandable. A number of PKGBUILD files
publish
Hi Greg,
Sifflet is now up-to-date in habs and on AUR.
Take care
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi guys,
the binary repositories for both i686 and x86_64 are now up-to-date.
(Thanks to Nicolas Pouillard for building the 64 bit binaries!)
Several packages had to be dropped from HABS because of build errors
after the recent update to ghc 7.0.2. These packages are:
agda-executable
haskell
Hi Leif,
> I submitted a pull request for yesod and a number of other things:
> https://github.com/archhaskell/habs/pull/47. Do I also need to drop a
> note here for it to get noticed, or what is the preferred way of
> notifying about such things?
as of now, I don't receive e-mail notificatio
Hi guys,
the following packages don't build anymore because of version conflicts:
agda-executable
haskell-agda
haskell-authenticate
haskell-dbus-core
haskell-libxml-sax
haskell-sifflet-lib
haskell-yesod-auth
haskell-yesod-core
haskell-yesod-fo
Hi guys,
a new version of cabal2arch v0.8.0 is available that supports ghc 7.0.2.
All PKGBUILD files in habs have been re-built with that version; the Git
repository has those files. Also, these updates were uploaded to AUR.
The binary repository for i686 is being re-built as we speak. The
updat
Hi Magnus,
> If you say 'yes' then I'll hand over the ownership of the ArchHaskell
> github group, and send you the remaining passwords that Don handed
> over to me.
well, it feels a little odd to resolve the situation like this, but
maybe you are right and it's the best choice. Yes, please se
Hi Magnus,
> Do you want to be the owner/leader and, by the looks of it, the
> sole regular contributor to the ArchHaskell project?
I'm not sure what you mean. Are you asking me whether I want you to quit
working on this project? If that is the case, then I believe that this
question is somewha
Well, now I know what happened:
> $ git push --dry-run -v
> Pushing to g...@github.com:archhaskell/cabal2arch
> ERROR: Permission to archhaskell/cabal2arch.git denied to peti.
> fatal: The remote end hung up unexpectedly
Magnus Therning has by mistake broken the x86_64 repository ...
Hi,
I just tried to push a fix for cabal2arch issue #27, but apparently
Github won't allow me to upload the change:
$ git push --dry-run -v
Pushing to g...@github.com:archhaskell/cabal2arch
ERROR: Permission to archhaskell/cabal2arch.git denied to peti.
fatal: The remote end hung up unexp
Hi Magnus,
> What do changes do you propose we make to our tool chain to
> support patching of packages?
the cabal2arch utility (or rather, the underlying archlinux
library) needs the ability to accept three kind of patches and
bake them into the generated output:
1) diffs that ought to be ap
Hi Peter,
> I already proposed [writing a script which keeps the last two
> versions of everything] but there was no response and it looks like
> it is still an issue.
yes, this is still an issue. If you have the chance to write a script
that can automatically expire old files from the binary
Hi Rémy,
>> [1]: http://hackage.haskell.org/package/darcs-2.5.1
>
> Very good, I will update it in [staging] soon.
would it be possible to send a quick announcement to this list when
GHC7 support in [staging] is considered complete, i.e. ready to be
moved to [extra]?
Take care,
Peter
__
Hi Magnus,
> I would suggest we don't add any new packages that currently don't
> build with GHC7. What do you say?
yes, I think that's reasonable.
On a similar notion, do we currently have (non-HP) packages in HABS that
don't build with GHC7? If that is the case, then I would like to inform
t
Magnus,
your recent update of the i686 tree screwed up the symlinks for 'repo.db'
again, which in turn broke my build. Furthermore, you've again deleted older
versions of the updated packages even though I repeatedly asked you not to.
This is the third or fourth time that this is happening -- des
Hi Magnus,
> [The symlinks] have never disappeared on my system, but then I never
> have found a need for them either.
the reason why we need those symlinks is that the repository is served
to the public being called 'haskell', but we build it under the name of
'repo'. Consequently, Pacman expe
Hi,
I've synchronized the i686 repository with the current state of HABS.
The following packages are new:
haskell-ansi-terminal-0.5.5-4
haskell-ansi-wl-pprint-0.6.3-3
haskell-hostname-1.0-1
haskell-language-haskell-extract-0.1.2-4
haskell-test-framework-0.3.3-4
haskell-test-framework-
Hi Magnus,
> Let's just keep them in the script; there's a bit risk they go missing
I have maintained the repository using those two symlinks for 3 months
or so, and I've never had a problem with them "going missing". On what
occasion did those symlink disappear on your system?
Take care,
Peter
Hi Magnus,
there seems to be a misunderstanding. I created the missing symlinks
from repo.db.tar.gz to haskell.db.tar.gz in both the i686 and the x86_64
repository, so the change you made in that commit is no longer required.
You can use the exact same repository for building in a chroot sandbox
a
Hi Nicolas,
> I don't know how you (the team) sync the repository, but I find it
> easier to remove the old version and add the new at the same time.
I rsync the repository from andromeda into my local chroot sandbox, then I
run 'makeworld', and then I rsync the modified repository back to the
Hi guys,
yesterday, I tried to install "haskell-pandoc" on a Linux/i686 machine,
but Pacman was unable to download that binary package, because the file
haskell-pandoc-1.6.0.1-2-i686.pkg.tar.xz
had been deleted from the server, probably because an update to version
1.8.0.1-1 had become availab
Hi guys,
it appears that there are plenty of web pages about ArchHaskell that
contain obsolete or even misleading information. A quick search revealed
the following URLs:
* http://wiki.archlinux.org/index.php/Haskell_package_guidelines
This page contains plenty of obsolete information that s
Hi Nicholas,
> I updated the qthaskell PKGBUILD so it fetches and builds the latest
> version.
the new version is now available on AUR. Thank you very much!
Take care,
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.o
FYI: the i686 repository is now again in synch with HABS.
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi Magnus,
> I updated a few package (all that could be easily upgraded really):
> https://github.com/archhaskell/habs/commit/4e7eb5b8e01ccf4c4c9f77030559ad83f8a23dc8
thanks a lot!
> Would someone please build and update the i686 binary repo?
I got a build error, apparently, because haskell-
Hi Leif,
> There's an awful lot of packages in that dropped list that I use. I could
> maintain PKGBUILDs for them myself, either on HABS or AUR directly.
that would be really great. Yes, please help us maintain those packages!
The contents of the HABS tree determines what goes into the binary
Hi Peter,
>>[haskell]
>>Server = http://andromeda.kiwilight.com/$repo/$arch
>
> It looks like the packages there do not have specified the exact
> version (including pkgrel) in their dependency info (as an example I
> looked at haskell-yesod). If it would be included then pacman can
Hi guys,
updated versions of cmdargs, crypto-api, data-default, and hlint are
available in the binary repository and on AUR. I've also bumped the
$pkgrel of cabal2arch, puremd5, tagged, and yesod to force re-builds so
that they take advantage of the new versions.
BTW, I asked the aur-general guys
Hi guys,
the AUR package haskell-haskore [1] was marked out-of-date by palmfron.
Now, technically that package is not "out-of-date", because the version
we distribute on AUR -- 0.1.0.4 -- is the latest one. Still, there is
something wrong with that package: it doesn't compile [2]. As far as I
can
Hi Magnus,
> They've all been uploaded to AUR.
I saw it. Thanks a lot!
> Peter, I'm guessing you've already upgraded the i686 repo, right?
The build process took a while, but I've uploaded the new binaries to
the server a few minutes ago. As far as I can tell, the Git repository,
the binary r
Hi Magnus,
> Are you uploading the source packages to AUR as well, or do you want
> me to do it?
it would help me a lot if you could do it.
> I'll tag them up as follows:
>
> 0.7.7 -
> https://github.com/archhaskell/cabal2arch/commit/02f5bec78dfd415db8bca5215b7526558e42e20a
> 0.3.6 -
Hi Magnus,
> So, what are your thoughts. Should I continue hacking on this?
there already is a tool that can figure out which versions of a
given set of packages are compatible with each other: cabal-install.
The code of that utility features an algorithm to compute something
that's called "Ins
Hi Magnus,
> Are [cabal2arch and archlinux] in a state where new versions can be
> released right now?
only recently, Remy has added the "platform-provides.txt" feature to
these tools, which constitutes a major change in behavior. It's best
illustrated by looking at the diff that results from r
The following message is a courtesy copy of an article
that has been posted to gmane.comp.lang.haskell.cafe as well.
Hi guys,
those of you who use the ArchLinux distribution might be interested to know
that a team of volunteers has put together a binary package repository that
complements the set
Hi Magnus,
> To conclude, I'm perfectly all right with your comments and questions
> above, however from your tone I'm getting the feeling that are irritated
> with me.
personally, I would prefer to describe my impressions as concern. The
reasons for my concern are simple. For the longest time
Hi guys,
there are 3 (more or less) separate efforts going on that are loosely organized
under term "ArchHaskell":
1) the ArchLinux library,
2) the cabal2arch utility, and
3) the habs repository of PKGBUILD files.
In the last couple of months, the ArchLinux library has been developed mostly
Hi Magnus,
> To be very blunt, I said your EXPERIENCE is invaluable. In your
> initial email you didn't recount that experience in a way that
> clearly pointed out what wasn't working. That means your initial
> email wasn't invaluable, because there was nothing in it that I could
> act on.
y
Hi Rémy,
> I added [ArchPackage] because I thought it was a better type for the
> output of the conversion function (since the output is really a
> PKGBUILD + Maybe an install script), but I didn't use it yet. I'd
> prefer keeping it for the moment.
you are right. I agree that this type is a
Hi Magnus,
> I was probably too vague, because I was waiting for you to provide
> more information.
well, if you have any concrete questions, then please ask me! I cannot
possibly know that you are waiting for more information unless you tell me
about it.
> In your initial email you say thin
hat one?
Take care,
Peter
>From 35c1314d5e029dc449a78c0fdc2d539ad99e3737 Mon Sep 17 00:00:00 2001
From: Peter Simons
Date: Sun, 9 Jan 2011 22:24:16 +0100
Subject: [PATCH] Distribution/ArchLinux/PkgBuild.hs: the ArchPackage data type
is obsolete
---
Distribution/ArchLinux/PkgBuild.hs | 26
Hi Magnus,
I have the impression that you are avoiding the substance of my original
article in this thread. I posted that very long and very detailed message,
because I believe that it's vital to understand the problems we have to
solve before we try to solve them. I would love to hear your opinio
we bumped the $pkgrel of haskell-sdl when --enable-shared
was activated:
| commit 678ab5f30a159d2c44c48cd7670891421310eb93
| Author: Peter Simons
| Date: Fri Dec 24 11:17:37 2010 +0100
|
| Regenerated all PKGBUILD files that didn't set "--enable-shared" with the
| latest
Hi Tasha,
> I would actually characterize this problem as a lack of people with
> access to [extra] who care about the Haskell packages or have the free
> time/resources to get a turnaround on issues consistently to a few days
> at most.
yes, you are right. I completely agree. It would be qui
Hi Magnus,
> do you think that our earlier discussion was on target, i.e. did we
> correctly identify the real pain points [...]?
I'm not quite sure what the problems were that we identified in earlier
discussions, but I believe that the points I just explained in my
previous posting are fairly
Hi Tasha,
> Most Haskell packages in [extra] really shouldn't be getting updated
> in the sense of a version bump (from what I understand) until a new
> version of the HP comes out or there's an official policy change.
this is true for HP packages, of course. However, [extra] and [community]
c
Hi Magnus,
> https://github.com/archhaskell/cabal2arch/issues#issue/20
thank you for tackling this problem.
> I think that we should remove the data files completely from the
> packages and only host them at a well-known URL (on kiwilight.com or
> haskell.org).
The notion that those files
Hi Magnus,
> Now you make me think that I might have missed something, but surely
> parsec version 2.2 wouldn't satisfy the former, but would satisfy the
> latter.
yes, this is true, of course.
It is impossible to map that Cabal expression to Pacman without losing
some information. In this pa
Hi Rémy,
> I perfectly remember agreeing with you on this.
oh, apparently I wasn't paying attention. :-( I am sorry.
> I even sent a patch doing this. Should I file a pull request or
> commit directly instead?
Personally, I'm fine with committing the patch you posted earlier. It
seems to do
Hi Xyne,
> If the 2.1.* series is still in the repos then use
> ('parsec>=2.1.0' 'parsec<2.2').
I don't understand why you propose setting that upper bound. Won't this
restriction mean that the PKGBUILD file will have to be re-generated when
we update to parsec 3? Why do you think that behavior
Hi Xyne,
> depends=('foo>=a' 'foo<=b').
thank you very much for the clarification. Now, the only issue left is
how to translate a specification like "parsec >= 3.0 || == 2.1.*". Since
you know Pacman very well, I wonder whether you'd have a suggestion?
Take care,
Peter
___
Hi Magnus,
>> the gist of this issue is that "parsec >= 3.0 || == 2.1.*" is translated to
>> "parsec>=3.0", which is just plain wrong. Now, wouldn't it be easiest to
>> modify cabal2arch so that it translates that specification to "parsec>=2.1"?
>> A straight-forward algorithm to accomplish th
Rémy Oudompheng writes:
> https://github.com/archhaskell/cabal2arch/issues#issue/19.
the gist of this issue is that "parsec >= 3.0 || == 2.1.*" is translated to
"parsec>=3.0", which is just plain wrong. Now, wouldn't it be easiest to
modify cabal2arch so that it translates that specification to
First of all, merry Christmas everyone!
I tried to take a look at the following report:
> from http://aur.archlinux.org/packages.php?ID=27809
> Kamek wrote:
>
> I get:
> Configuring data-binary-ieee754-0.4.2.1...
> Preprocessing library data-binary-ieee754-0.4.2.1...
> Preprocessing execut
Hi Rémy,
> I have fixed those when building packages for GHC7, I'll backport it
> to the current extra packages.
great, thank you very much!
Take care,
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listi
Hi Rémy,
> As you may have noticed, ghc-7* was moved to [staging] by other devs.
> I began rebuilding current versions of libraries when they were
> compatible. I would like your approval to do the following:
>
> deepseq 1.1.1.0 -> 1.1.0.1
> mtl 1.1.0.2 -> 1.1.1.0
personally, I am all for i
Hi,
can someone with access to [extra] please update haskell-text to
version 0.10.0.0? The old version is blocking other updates, such
as haskell-yesod, etc.
Take care,
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org
Hi Xyne,
> The [kiwilight] server will almost certainly be accessed via ssh. He
> hasn't replied yet with details but I expect to hear back from him
> soon.
are there any new developments?
Take care,
Peter
___
arch-haskell mailing list
arch-haskell
Hi Magnus,
>> Once package FOO is installed, and linked to local versions of its
>> dependencies, there is not much we can do to prevent that an update
>> to FOO's dependencies breaks the *local* system if it's upgraded.
>
> Why can't we bump $pkgrel of those packages that depend on FOO?
Um,
Hi Magnus,
> We would hopefully go to great lengths to make sure that all packages
> on AUR can be built and installed together.
ah, very cool. That is what I was believe we should do, too.
> However, once package FOO is installed, and linked to local versions
> of its dependencies, there i
Hi Xyne,
> Kaiting Chen wrote:
>
>> Hi Xyne, so you know that for a while I've been trying to get a new
>> server up on EC2. It's just about done, so if you guys don't mind being
>> test subjects I'd like to set you up there. Note that the new server is
>> built on ephemeral storage and thus
Hi Xyne,
> "haskell-foo" would contain foo 1.4, foo 1.5 and whatever other
> versions of foo that one could reasonably expect.
the idea is intriguing.
This kind of setup means, though, that when a new version foo 1.6 comes
out, re-building haskell-foo consists of builds of foo 1.4, 1.5, and 1.
Hi Magnus,
>>> AFAICS there are roughly two sides to consider. Packages delivered in
>>> binary format, and packages delivered in source format (AUR).
>>>
>>> Binary: The burden falls on the developers who provide the binary
>>> packages to make sure that all binary packages are mutually
>>>
Hi Xyne,
> If Cabal can install different versions alongside each other, can't
> we do that with Pacman too?
Pacman cannot install two different versions of the same package at the
same time, where "package" really means "$pkgname". Cabal, however, can
do that. We can work around this limitatio
Hi Xyne,
> The idea was to provide a consistent set of PKGBUILDs with
> topological rebuilds and updates.
yes, that was my understanding, too. In [1], I put together a build
process that automates this procedure to some degree. The heart of the
system is the file "PKGLIST", which specifies the
Hi Peter,
> Hmm, what we would need is so that when haskell-pandoc is being built
> it's PKGFILE is updated so that it requires haskell-http 4000.0.9
> exactly. Then an attempt to uninstall haskell-hp-http later would
> require an uninstallation of haskell-pandoc too.
fortunately, Pacman does
Hi Magnus,
> AFAICS there are roughly two sides to consider. Packages delivered in
> binary format, and packages delivered in source format (AUR).
>
> Binary: The burden falls on the developers who provide the binary
> packages to make sure that all binary packages are mutually
> compatible.
Hi Magnus,
> http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
I completely agree that the naming scheme is sound. I don't see, however,
how other packages are going to use it. Could you show us a concrete
example, please? What does a package like, say haskell-pandoc, depend on?
Hi guys,
there seems to be a lack of coordination. It feels like we are wandering
off into all kinds of different directions. I would like to think that
there is a common goal that we are trying to achieve, but I'm not sure
whether that is the case. Maybe it would be helpful if everyone involved
i
Hi Rémy,
> Can you quickly tell me if everybody agrees on me uploading these
> packages:
>
> - haskell-parallel (version 3.1.0.1)
> - haskell-hp-parallel (version 2.2.0.1, provides haskell-parallel=2.2.0.1)
I'd rather have haskell-parallel-2.2.0.1 in [extra].
The distinction between haskell
Hi Xyne,
> Why does haskell-parallel in [extra] depends on a later version of
> haskell-deepseq than what is availabe in [extra]? The package simply
> cannot be installed because of this.
on top of this, [extra] ships parallel-3.1.0.1, which is way ahead of
the version haskell-platform require
Hi Magnus,
> This is a minor point, but is the new version of archlinux (0.3.5) really
> API compatible with the previous version (0.3.4)?
yes, I believe it is. I certainly tried to make all changes in a backwards
compatible manner.
> If the answer is 'no', then the newer version ought to be
Hi guys,
I have released the current state of archlinux and cabal2arch on
Hackage, but not yet on AUR so that we have the chance to test the new
release a little.
In a couple of days, I'd like to re-generate all our PKGBUILD files with
the current version of the tool chain to ensure that the file
Hi Magnus,
> I'd like a scheme where both HP and bleeding edge of packages can be
> installed, side by side.
to accomplish that, the version number must become part of the ArchLinux
package name. For example:
parsec 2.0 ==> parsec_2_0 (provides: parsec2, parsec)
parsec 2.1.0.0
Vesa, Remy,
it's my understanding that [extra] is supposed to conform to haskell
platform. As of now, it doesn't because of haskell-parellel-3.1.0.1-1.
I didn't get any responses to my inquiry, so I wonder whether either of
you has any intentions to remedy that problem?
Take care,
Peter
___
Hi guys,
> http://hpaste.org/41115/hp_for_arch
as far as I can tell, [extra] is only three packages away from providing
haskell-platform. If that could be achieved, i.e. if all required
packages were available individually in binary form, then I prefer that
solution over a conglomerate like the
Hi guys,
I have updated a bunch of packages on AUR and in the habs repository. We
almost conform to haskell-platform. The only thing missing right now is a
proper version of haskell-parallel. The [extra] tree ships version 3.x, but
the standard says that version 2.2.0.1 ought to be used.
Vesa, ca
Hi guys,
how does http://aur.archlinux.org/packages.php?ID=26279 fit into all this?
Take care
Peter
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
Hi guys,
>> Apparently, we only have haskell-parsec-3.1 now. Oopsie?
>
> That's certainly a mistake: Haskell Platform requires parsec ==2.1.0.1
yes, the recent update to parsec 3.1.0 broke not just darcs; there are
many packages that depend on parsec 2. For me, an attempt to build
"sifflet" ju
Hi Magnus,
> The situation now is that 'cabal2arch' (or rather 'archlinux') again
> knows what packages are provided by the 'ghc' package. Resulting in a
> list that has to be maintained by a person who isn't intimately
> involved in packaging 'ghc' [...]. AFAICS this also forces a
> re-relea
1 - 100 of 106 matches
Mail list logo
