Your habs-extra repo works really well. Thanks for making it, and for mentioning it! I hope it will get merged soon :) On Wed, Sep 19, 2012 at 6:22 PM, Ramana Kumar wrote:

On Wed, Sep 19, 2012 at 6:04 PM, Fabio Riga wrote:

...

Alle 15 e 37 del 18/09/12, Ramana Kumar si espresse così:

...

I would like you to consider adding http-conduit to the [haskell] repo. I have submitted a pull request which does this at archhaskell/habs on github. I maintain a [haskell-extra] repository that include http-conduit. This repo is builded with cblrepo and depends on [haskell]. You can find more information here:

https://github.com/EffeErre/habs-extra

Cheers, Fabio

Thanks a lot for this information! Is it written down in any wikis or other places where we can learn about [haskell]? I will try your repo now and let you know about any issues.

Are there concrete plans to merge it into the main [haskell] repo (i.e. to merge habs-extra into habs)? If not, can we start to make some? What are the blocking factors?

...

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

On Mon, Sep 24, 2012 at 11:51 PM, Fabio Riga wrote:

Are there concrete plans to merge it into the main [haskell] repo (i.e. to

...

merge habs-extra into habs)? If not, can we start to make some? What are the blocking factors?

There are no concrete plans. The main blocking factor is lack of time.

I hereby offer a portion of my time. It would be economical for you and Magnus to prioritise making it easy for me (and other newcomers) to spend their time usefully on the arch-haskell project. That means: write down the immediate next steps in a public prominent place (I suggest the Arch Haskell page on the Arch Linux wiki), and, as possible (I realise you are busy!), spend time replying to the mailing list (not doing so badly so far) and to people on the IRC channel. I am specifically interested in knowing more about the multi-distro approach, whereby many people can maintain small pieces of arch-haskell but it can still be collected into one big repo to point pacman at. Is there a quick way to generate the list of packages on hackage that are not yet packaged for Arch? I would like to try, for example, taking the first (or most interesting) 10 packages on that list, packaging them and making them into my repo, then connecting it up to the arch-haskell ecosystem.

For the way [habs] works, one mantainer have to compile all pakages. This is a LOT of work, and I understand why Magnus rarely accepts new packages. [habs-extra] has the intent to address this problem, see my other reply for this.

I hereby offer my resources to "compile all pakages" on the condition that [haskell] gets better quicker, and until we sort out a better way to make it better (e.g. the distributed approach).

Cheers, Fabio

______________________________**_________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/**mailman/listinfo/arch-haskellhttp://www.haskell.org/mailman/listinfo/arch-haskell

Are any of the people with commit access to habs on this list? What about merging in habs-extra? On Thu, Sep 20, 2012 at 7:39 AM, DeWitt, Michael wrote:

On Sep 19, 2012 1:05 PM, "Fabio Riga" wrote:

...

Alle 15 e 37 del 18/09/12, Ramana Kumar si espresse così:

...

I would like you to consider adding http-conduit to the [haskell] repo. I have submitted a pull request which does this at archhaskell/habs on github. I maintain a [haskell-extra] repository that include http-conduit. This repo is builded with cblrepo and depends on [haskell]. You can find more information here:

https://github.com/EffeErre/habs-extra

Cheers, Fabio

Oh wow, this repo is better than Christmas. Thanks for all the work!

Michael

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

On Mon, Sep 24, 2012 at 5:14 PM, wrote:

...

Are any of the people with commit access to habs on this list? What about merging in habs-extra?

Honestly, I've kinda given up on this group because it seems the people in charge don't really care. I've got my own little hackage->pkgbuild system running that so far works great for my needs. Once I'm a little more confident of its performance, I may release it to a wider audience.

Cool :) There's no reason not to simply reuse the arch-haskell name and resources (e.g. this list, the irc channel, the arch wiki pages) to revive/restart. (Maybe too many people associate arch-haskell with useless now, but I think we can turn that around...) I encourage you to release your stuff early, to get contributions from others (like me) even before it's "ready". Currently I am using [haskell] and [haskell-extra] and it is fine for my needs. The first is from arch-haskell (xsounds.org/~haskell) and the second is from Fabio Riga (archhaskell.mynerdside.com). Both are built using cblrepo. What are you using? Is it superior?

In data 24.09.2012 18:14:35, tam@hiddenrock.com ha scritto:

Honestly, I've kinda given up on this group because it seems the people in charge don't really care. I've got my own little hackage->pkgbuild system running that so far works great for my needs. Once I'm a little more confident of its performance, I may release it to a wider audience. What do you mean with "they don't care"? Why don't you try and help, instead of reinventing the wheal?

Fabio

On Tue, Sep 25, 2012 at 1:47 AM, wrote:

...

What do you mean with "they don't care"? Why don't you try and help, instead of reinventing the wheal?

By "they don't care", I mean that, over the last two months, the mailing list has seen only three messages from anyone with commit rights to the arch-haskell repo. You may note that I and another member of the list *have* offered to help [1][2] and got no response. Given the rarity of updates to the arch-haskell repo and my unbridled hatred for trying to reverse engineer undocumented processes that SHOULD be documented, I figured my needs would be more expeditiously filled by taking matters into my own hands.

I am very sorry for not having responded to [1]. I had planned to do it, but forgot about it. As for [2] I didn't understand that as an email that I actually needed to weigh in on, I simply agreed with what it says. Apparently I got that one completely wrong.

In retrospect, saying "they don't care" was overzealous on my part. It is, however, evident that the powers-that-be don't have time to maintain the repo in a way that is useful to me, so I fixed the problem for myself (which, you may note, is how the open source community works: the source speaks, do-ocracy, etc, etc).

So I'll continue tinkering with my solution and, when it is sufficiently robust, I hope to release it to a wider audience. And yes, there will be more-than-adequate documentation. It's possible I may get bored or run into an obstacle I'm too lazy to overcome or be introduced to a glorious extant solution, in which case I'll convert. But until then, this is what solves my problems better than anything else I know of. That's kinda how the open source model works.

That sounds good, it would however be interesting to find out what your criteria is (what you are looking for) and how your tool satisfies them. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

I am very sorry for not having responded to [1]. I had planned to do it, but forgot about it.

It's cool. I think my previous message conveyed more angst on my part than I truly feel, so please don't think I'm up in arms about this.

That sounds good, it would however be interesting to find out what your criteria is (what you are looking for) and how your tool satisfies them.

I'll work on it, but I'm super-slammed right now and I may not have time to prepare a sufficient reply for a bit. I'm not ignoring you. ;) pete

On Wed, Oct 3, 2012 at 7:49 PM, wrote:

...

That sounds good, it would however be interesting to find out what your criteria is (what you are looking for) and how your tool satisfies them.

A few things:

- The documentation was so sparse, I thought it would be less effort to implement from scratch than try to figure out how the current system worked. In retrospect, I believe I was correct in this, not least because I'm not sufficiently expert at Haskell to efficiently figure out precisely what cabal2arch is doing.

Had you bothered reading the documentation that *does* exist you would have found out that we don't use cabal2arch to package for ArchHaskell any longer.

- cabal2arch treats all cabal dependencies as '=' and does not honor '<=' or '>=' which is a pain in the ass because it requires rebuilding everything when one package version changes. It's entirely likely there's a good reason for this; I didn't dig in because the idea offends me as it completely undermines the point of libraries in the first place. So I'm living on the edge with my implementation in this regard.

This is a requirement that comes from how GHC builds and links. Yes, you are most definitely living on the edge if you recompile required packages without also recompiling the packages that require them.

- cabal2arch uses a hard-coded list of libraries provided by ghc, but this seems redundant due to the Arch ghc package's "provides" (which I assume came to be after cabal2arch was written).

Indeed, and our current tool, cblrepo, has moved that list into an external database.

- I don't have a good alternate solution to the hard-coded list of library providers. I think maintaining this list is far more reasonable than the ghc-provides list, though, because it's specific to the intersection of Arch Linux and Haskell, whereas ghc provides is not.

That is an area where our current tool is lacking. At the moment that mapping in handled through patches to the generated PKGBUILDs, which isn't very elegant at all, but it works.

- I have probably made some erroneous assumptions here, but given the combination of lack of documentation, lack of response to the mailing list, and my substandard knowledge of Haskell, I figured the best way to solve my problem (ie, to install stuff from hackage I wanted to play with) was to roll my own. I am not upset at the aforementioned lacks; I enjoy the work and I enjoy the learning; please do not infer any angst from me here.

IMNSHO it is rather simple to do this for a couple of packages. However, as the set of packages grow it becomes more and more obvious that some sort of tool support is necessary. Do you think that what you put together would allow maintaining a repo of 150+ Haskell packages by a (very) small group (sometimes so small that it is a single individual)? The reason I'm asking is because we've found that cabal2arch isn't such a tool, but cblrepo comes a bit closer to it.

As I said previously, I do plan to make my stuff generally available, but I haven't had time to add a baseline of polish so that people can actually use it relatively autonomously. ;)

Let us know when you've put it out for us to have a look :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

In data 25.09.2012 08:17:54, Magnus Therning ha scritto:

On Mon, Sep 24, 2012 at 6:08 PM, Ramana Kumar wrote:

...

Are any of the people with commit access to habs on this list? What about merging in habs-extra?

There is a combination of reasons for my reluctance to accept new packages into HABS and [haskell], Fabio points out the main one in another reply. This means that merging in habs-extra is a BIG deal and unlikely to happen. I also like to see just how Fabio gets on with it. We had a discussion earlier where I expressed my doubts about the idea of splitting up ArchHaskell into several repos. Fabio pressed on with it, so I'm hoping to at some point be converted and have my doubts dispelled :-)

I think that the way I wrote made me misunderstood: I do believe that it should be only one [habs] repository, but with cblrepo many maintainers could manage a small amount of packages, then simply copy the resulting Arch package in the main repo. Maintainers should compile only their package. A script should ensure that everything is in sync. I wrote a very messy script. I would like to have the time to clean it before show you with an example what I mean. I should find some time before the week-end. Fabio