Just to let you know i fixed last glitchs to the framework and CEAN 2.0 is almost done. framework is stable and extensible enough. I'm waiting a minor contribution from bengt kleber and prepare the public repository for initial commit. so we'll have base to start working together. the framework handles everything from fetching sources to building self extractable installer, for whatever erlang version you want. user will be able to use cean in binary install only "a la debian" or build it's own repository and packages "a la gentoo" temporary new site is here: http://dev4.process-one.net:8888/ some links are still broken (archive not generated) but the big picture is ready.
so now i can focus on interraction with agner, and make sure all agner package can be processed 'as this'. this would give us the 1st step.
Yurii, do you want to write a converter from cean's .pub to agner.config ? may we discuss some merging convention ? example:
etorrent.pub {author, {"Jesper Louis Andersen", "jesper.louis.andersen...gmail.com"}}. {packager, {"Christophe Romain", "christophe.romain...process-one.net"}}. {category, ["net"]}. {depends, []}. {keywords, []}. %% used by search engine in addition to summary {summary, "Erlang Bittorrent Client"}. {abstract, "Etorrent is a bittorrent client implementation in Erlang focusing on fault-tolerance"}. {home, "https://github.com/jlouis/etorrent"}. {url, "git://github.com/jlouis/etorrent.git"}.
agner.config {name, "etorrent"}. {authors, ["Jesper Louis Andersen <jesper.louis.andersen...gmail.com>"]}. {description, "Etorrent is a bittorrent client implementation in Erlang focusing on fault-tolerance"}. {homepage, "http://github.com/jlouis/etorrent"}. {rebar_compatible, true}. {license, "BSD2", "COPYING"}. {erlang_versions, [otp_r14b, otp_r14b01, otp_r13b04]}. {url, {git, "https://github.com/jlouis/etorrent.git", {branch, "master"}}}.
depending on your local install, cean:install command will either: - just extract bfile-1.2.ez (erlang can load beams from .ez archive) - extract bfile-1.2.ez contents, this generates bfile-1.2/ebin - extract bfile-1.2.ez and bfile-1.2.src.zip, this generates bfile-1.2/ebin and bfile-1.2/src
that way, from one .epkg, user have choice of its own installation - binary only production installation - typical development installation
the installer generation script takes erlang minimalist VM, the lib you want to package and all its dependencies (by extracting corresponding .epkg) so binary and source packaging convention really matters now.
Martin, what is your opinion about this ? i just wanted to share my vision of the big picture. again i don't know ciconia enough to see how far we can share the packaging process. anyway there are some very cool features in ciconia such as release management. i think it would be terrific to merge the release management and the self extractble installer (as it supports postinstall.sh scripts) this would make cluster administration/deployment a child play (even something administrator could include in .rpc/.deb packaging)
After a lot of talk Martin and I decided to drop further development of ciconia. There are already several managers out there that have more traction. It didn't seem like a good idea for us to spend development time on yet a third. However, we still have a huge stake in this game as consumers of this information. Sinan, at the very least, will be handling its own dependencies very soon and have plugins for agner at least.
Eric
On Tue, Jul 12, 2011 at 4:43 PM, Christophe Romain
> Just to let you know i fixed last glitchs to the framework and CEAN 2.0 > is almost done. framework is stable and extensible enough. > I'm waiting a minor contribution from bengt kleber and prepare the > public repository for initial commit. so we'll have base to start > working together. > the framework handles everything from fetching sources to building self > extractable installer, for whatever erlang version you want. > user will be able to use cean in binary install only "a la debian" or > build it's own repository and packages "a la gentoo" > temporary new site is here: http://dev4.process-one.net:8888/ > some links are still broken (archive not generated) but the big picture > is ready.
> so now i can focus on interraction with agner, and make sure all agner > package can be processed 'as this'. this would give us the 1st step.
> Yurii, do you want to write a converter from cean's .pub to agner.config ? > may we discuss some merging convention ? > example:
> etorrent.pub > {author, {"Jesper Louis Andersen", "jesper.louis.andersen...gmail.com"}}. > {packager, {"Christophe Romain", "christophe.romain...process-one.net"}}. > {category, ["net"]}. > {depends, []}. > {keywords, []}. %% used by search engine in addition to summary > {summary, "Erlang Bittorrent Client"}. > {abstract, "Etorrent is a bittorrent client implementation in Erlang > focusing on fault-tolerance"}. > {home, "https://github.com/jlouis/etorrent"}. > {url, "git://github.com/jlouis/etorrent.git"}.
> agner.config > {name, "etorrent"}. > {authors, ["Jesper Louis Andersen <jesper.louis.andersen...gmail.com>"]}. > {description, "Etorrent is a bittorrent client implementation in Erlang > focusing on fault-tolerance"}. > {homepage, "http://github.com/jlouis/etorrent"}. > {rebar_compatible, true}. > {license, "BSD2", "COPYING"}. > {erlang_versions, [otp_r14b, otp_r14b01, otp_r13b04]}. > {url, {git, "https://github.com/jlouis/etorrent.git", {branch, "master"}}}.
> depending on your local install, cean:install command will either: > - just extract bfile-1.2.ez (erlang can load beams from .ez archive) > - extract bfile-1.2.ez contents, this generates bfile-1.2/ebin > - extract bfile-1.2.ez and bfile-1.2.src.zip, this generates > bfile-1.2/ebin and bfile-1.2/src
> that way, from one .epkg, user have choice of its own installation > - binary only production installation > - typical development installation
> the installer generation script takes erlang minimalist VM, the lib you > want to package and all its dependencies (by extracting corresponding > .epkg) so binary and source packaging convention really matters now.
> Martin, what is your opinion about this ? i just wanted to share my > vision of the big picture. again i don't know ciconia enough to see how > far we can share the packaging process. anyway there are some very cool > features in ciconia such as release management. > i think it would be terrific to merge the release management and the > self extractble installer (as it supports postinstall.sh scripts) this > would make cluster administration/deployment a child play (even > something administrator could include in .rpc/.deb packaging)
On Thu, Jul 14, 2011 at 10:05 AM, Eric Merritt <ericbmerr...@gmail.com> wrote: > Chris,
> After a lot of talk Martin and I decided to drop further development > of ciconia. There are already several managers out there that have > more traction. It didn't seem like a good idea for us to spend > development time on yet a third. However, we still have a huge stake > in this game as consumers of this information. Sinan, at the very > least, will be handling its own dependencies very soon and have > plugins for agner at least.
> Eric
> On Tue, Jul 12, 2011 at 4:43 PM, Christophe Romain > <christophe.rom...@process-one.net> wrote: >> Hi
>> Just to let you know i fixed last glitchs to the framework and CEAN 2.0 >> is almost done. framework is stable and extensible enough. >> I'm waiting a minor contribution from bengt kleber and prepare the >> public repository for initial commit. so we'll have base to start >> working together. >> the framework handles everything from fetching sources to building self >> extractable installer, for whatever erlang version you want. >> user will be able to use cean in binary install only "a la debian" or >> build it's own repository and packages "a la gentoo" >> temporary new site is here: http://dev4.process-one.net:8888/ >> some links are still broken (archive not generated) but the big picture >> is ready.
>> so now i can focus on interraction with agner, and make sure all agner >> package can be processed 'as this'. this would give us the 1st step.
>> Yurii, do you want to write a converter from cean's .pub to agner.config ? >> may we discuss some merging convention ? >> example:
>> etorrent.pub >> {author, {"Jesper Louis Andersen", "jesper.louis.andersen...gmail.com"}}. >> {packager, {"Christophe Romain", "christophe.romain...process-one.net"}}. >> {category, ["net"]}. >> {depends, []}. >> {keywords, []}. %% used by search engine in addition to summary >> {summary, "Erlang Bittorrent Client"}. >> {abstract, "Etorrent is a bittorrent client implementation in Erlang >> focusing on fault-tolerance"}. >> {home, "https://github.com/jlouis/etorrent"}. >> {url, "git://github.com/jlouis/etorrent.git"}.
>> agner.config >> {name, "etorrent"}. >> {authors, ["Jesper Louis Andersen <jesper.louis.andersen...gmail.com>"]}. >> {description, "Etorrent is a bittorrent client implementation in Erlang >> focusing on fault-tolerance"}. >> {homepage, "http://github.com/jlouis/etorrent"}. >> {rebar_compatible, true}. >> {license, "BSD2", "COPYING"}. >> {erlang_versions, [otp_r14b, otp_r14b01, otp_r13b04]}. >> {url, {git, "https://github.com/jlouis/etorrent.git", {branch, "master"}}}.
>> depending on your local install, cean:install command will either: >> - just extract bfile-1.2.ez (erlang can load beams from .ez archive) >> - extract bfile-1.2.ez contents, this generates bfile-1.2/ebin >> - extract bfile-1.2.ez and bfile-1.2.src.zip, this generates >> bfile-1.2/ebin and bfile-1.2/src
>> that way, from one .epkg, user have choice of its own installation >> - binary only production installation >> - typical development installation
>> the installer generation script takes erlang minimalist VM, the lib you >> want to package and all its dependencies (by extracting corresponding >> .epkg) so binary and source packaging convention really matters now.
>> Martin, what is your opinion about this ? i just wanted to share my >> vision of the big picture. again i don't know ciconia enough to see how >> far we can share the packaging process. anyway there are some very cool >> features in ciconia such as release management. >> i think it would be terrific to merge the release management and the >> self extractble installer (as it supports postinstall.sh scripts) this >> would make cluster administration/deployment a child play (even >> something administrator could include in .rpc/.deb packaging)
On your binary packages for linux and darwin. I don't actually think the architecture alone is sufficient to guarantee binary compatibility. At the very least you need the libc version number as well as the bitwidth (x86_64) though that is probably part of the architecture and you just don't have any x86_64 packages at the moment.
Right now you are using the Erlang Release number (R13, R14, etc). I personally would much rather see the erts version there, 5.6, 5.7. At the very least I would like there to be a symlink from the Release number to the erts version number. The erts version is a lot more meaningful to programatic consumers then the Release number is.
These are things I can think of in a quick glance as a consumer, along with some knowledge we have of several years of faxien support.
Eric
On Tue, Jul 12, 2011 at 4:43 PM, Christophe Romain
> Just to let you know i fixed last glitchs to the framework and CEAN 2.0 > is almost done. framework is stable and extensible enough. > I'm waiting a minor contribution from bengt kleber and prepare the > public repository for initial commit. so we'll have base to start > working together. > the framework handles everything from fetching sources to building self > extractable installer, for whatever erlang version you want. > user will be able to use cean in binary install only "a la debian" or > build it's own repository and packages "a la gentoo" > temporary new site is here: http://dev4.process-one.net:8888/ > some links are still broken (archive not generated) but the big picture > is ready.
> so now i can focus on interraction with agner, and make sure all agner > package can be processed 'as this'. this would give us the 1st step.
> Yurii, do you want to write a converter from cean's .pub to agner.config ? > may we discuss some merging convention ? > example:
> etorrent.pub > {author, {"Jesper Louis Andersen", "jesper.louis.andersen...gmail.com"}}. > {packager, {"Christophe Romain", "christophe.romain...process-one.net"}}. > {category, ["net"]}. > {depends, []}. > {keywords, []}. %% used by search engine in addition to summary > {summary, "Erlang Bittorrent Client"}. > {abstract, "Etorrent is a bittorrent client implementation in Erlang > focusing on fault-tolerance"}. > {home, "https://github.com/jlouis/etorrent"}. > {url, "git://github.com/jlouis/etorrent.git"}.
> agner.config > {name, "etorrent"}. > {authors, ["Jesper Louis Andersen <jesper.louis.andersen...gmail.com>"]}. > {description, "Etorrent is a bittorrent client implementation in Erlang > focusing on fault-tolerance"}. > {homepage, "http://github.com/jlouis/etorrent"}. > {rebar_compatible, true}. > {license, "BSD2", "COPYING"}. > {erlang_versions, [otp_r14b, otp_r14b01, otp_r13b04]}. > {url, {git, "https://github.com/jlouis/etorrent.git", {branch, "master"}}}.
> depending on your local install, cean:install command will either: > - just extract bfile-1.2.ez (erlang can load beams from .ez archive) > - extract bfile-1.2.ez contents, this generates bfile-1.2/ebin > - extract bfile-1.2.ez and bfile-1.2.src.zip, this generates > bfile-1.2/ebin and bfile-1.2/src
> that way, from one .epkg, user have choice of its own installation > - binary only production installation > - typical development installation
> the installer generation script takes erlang minimalist VM, the lib you > want to package and all its dependencies (by extracting corresponding > .epkg) so binary and source packaging convention really matters now.
> Martin, what is your opinion about this ? i just wanted to share my > vision of the big picture. again i don't know ciconia enough to see how > far we can share the packaging process. anyway there are some very cool > features in ciconia such as release management. > i think it would be terrific to merge the release management and the > self extractble installer (as it supports postinstall.sh scripts) this > would make cluster administration/deployment a child play (even > something administrator could include in .rpc/.deb packaging)
On a side note. I am working on a multiplatform build farm for Erlware. It might be very worth while for us to collaborate on that. I am not sure how you are doing it now.
On Tue, Jul 19, 2011 at 3:39 PM, Eric Merritt <ericbmerr...@gmail.com> wrote: > Christophe,
> On your binary packages for linux and darwin. I don't actually think > the architecture alone is sufficient to guarantee binary > compatibility. At the very least you need the libc version number as > well as the bitwidth (x86_64) though that is probably part of the > architecture and you just don't have any x86_64 packages at the > moment.
> Right now you are using the Erlang Release number (R13, R14, etc). I > personally would much rather see the erts version there, 5.6, 5.7. At > the very least I would like there to be a symlink from the Release > number to the erts version number. The erts version is a lot more > meaningful to programatic consumers then the Release number is.
> These are things I can think of in a quick glance as a consumer, along > with some knowledge we have of several years of faxien support.
> Eric
> On Tue, Jul 12, 2011 at 4:43 PM, Christophe Romain > <christophe.rom...@process-one.net> wrote: >> Hi
>> Just to let you know i fixed last glitchs to the framework and CEAN 2.0 >> is almost done. framework is stable and extensible enough. >> I'm waiting a minor contribution from bengt kleber and prepare the >> public repository for initial commit. so we'll have base to start >> working together. >> the framework handles everything from fetching sources to building self >> extractable installer, for whatever erlang version you want. >> user will be able to use cean in binary install only "a la debian" or >> build it's own repository and packages "a la gentoo" >> temporary new site is here: http://dev4.process-one.net:8888/ >> some links are still broken (archive not generated) but the big picture >> is ready.
>> so now i can focus on interraction with agner, and make sure all agner >> package can be processed 'as this'. this would give us the 1st step.
>> Yurii, do you want to write a converter from cean's .pub to agner.config ? >> may we discuss some merging convention ? >> example:
>> etorrent.pub >> {author, {"Jesper Louis Andersen", "jesper.louis.andersen...gmail.com"}}. >> {packager, {"Christophe Romain", "christophe.romain...process-one.net"}}. >> {category, ["net"]}. >> {depends, []}. >> {keywords, []}. %% used by search engine in addition to summary >> {summary, "Erlang Bittorrent Client"}. >> {abstract, "Etorrent is a bittorrent client implementation in Erlang >> focusing on fault-tolerance"}. >> {home, "https://github.com/jlouis/etorrent"}. >> {url, "git://github.com/jlouis/etorrent.git"}.
>> agner.config >> {name, "etorrent"}. >> {authors, ["Jesper Louis Andersen <jesper.louis.andersen...gmail.com>"]}. >> {description, "Etorrent is a bittorrent client implementation in Erlang >> focusing on fault-tolerance"}. >> {homepage, "http://github.com/jlouis/etorrent"}. >> {rebar_compatible, true}. >> {license, "BSD2", "COPYING"}. >> {erlang_versions, [otp_r14b, otp_r14b01, otp_r13b04]}. >> {url, {git, "https://github.com/jlouis/etorrent.git", {branch, "master"}}}.
>> depending on your local install, cean:install command will either: >> - just extract bfile-1.2.ez (erlang can load beams from .ez archive) >> - extract bfile-1.2.ez contents, this generates bfile-1.2/ebin >> - extract bfile-1.2.ez and bfile-1.2.src.zip, this generates >> bfile-1.2/ebin and bfile-1.2/src
>> that way, from one .epkg, user have choice of its own installation >> - binary only production installation >> - typical development installation
>> the installer generation script takes erlang minimalist VM, the lib you >> want to package and all its dependencies (by extracting corresponding >> .epkg) so binary and source packaging convention really matters now.
>> Martin, what is your opinion about this ? i just wanted to share my >> vision of the big picture. again i don't know ciconia enough to see how >> far we can share the packaging process. anyway there are some very cool >> features in ciconia such as release management. >> i think it would be terrific to merge the release management and the >> self extractble installer (as it supports postinstall.sh scripts) this >> would make cluster administration/deployment a child play (even >> something administrator could include in .rpc/.deb packaging)
To cover the glibc compatibility issue, we have two choice: - build against many version of glibc - build with most compatible version
for cean i choosed the second option. building under debian stable is generally a good option for this, except for few month when major glibc version switch. doing so, i had compatibility issue only 2 times in 6 years, so i'm quite happy with this simplist choice. moreover, CEAN being a build framework, if a user is not happy with binary dependencies and needs latest glibc linked binary, he can deploy the framework and build its own epkg, linked to its own bleeding edge glibc. i wanted to make cean as simple as possible. 90% users will be happy with binary compiled with same glibc as debian stable. while i can include glibc version is repository tree (to keep compatibility with erlware) i won't setup a complex build farm, so i'll keep build binary only against debian stable (libc-2.11.2 i think now) for bitwidh, i have linux-x86 and linux-amd64. maybe should i rename amd64 to x86_64, it's just a matter of choice here.
i thought for long about use of release number or ets number (as you are using) and i kept simplest choice as i could not find best option here. I finally concluded this is more a question of taste. your proposal to use erts version, and symlink release number is good, i can go this way for sure, so we'll have closer repository structure.
thanks for your feedback. I better understand your choices now and they make sense, i think i'll go this way.
to build binaries, i build on differnte boxes (linux-x86 linux-amd64 osx and some xen vm) windows is generated from binary tarball. cross compilation script is in progress for linux, i used it to crosscompile ejabberd installers for windows and linux. i'm also working on an cean package to .deb script converter, that way we could have benefits of debian's compilation farm.
> To cover the glibc compatibility issue, we have two choice: > - build against many version of glibc > - build with most compatible version
> for cean i choosed the second option. building under debian stable is > generally a good option for this, except for few month when major glibc > version switch. > doing so, i had compatibility issue only 2 times in 6 years, so i'm > quite happy with this simplist choice. moreover, CEAN being a build > framework, if a user is not happy with binary dependencies and needs > latest glibc linked binary, he can deploy the framework and build its > own epkg, linked to its own bleeding edge glibc.
I am completely fine with this approach. As long is its been considered and a solution that works introduced I am happy. The explicit solution doesn't actually matter a whole lot.
> i wanted to make cean as simple as possible. 90% users will be happy > with binary compiled with same glibc as debian stable. while i can > include glibc version is repository tree (to keep compatibility with > erlware) i won't setup a complex build farm, so i'll keep build binary > only against debian stable (libc-2.11.2 i think now) > for bitwidh, i have linux-x86 and linux-amd64. maybe should i rename > amd64 to x86_64, it's just a matter of choice here.
Actually, uname returns x86_64, this is the same thing that erlang:system_info(system_architecture) info returns. It just makes it awkward that a translation has to occur to access the packages. Minor yes, but inelegant.
> i thought for long about use of release number or ets number (as you are > using) and i kept simplest choice as i could not find best option here. > I finally concluded this is more a question of taste. > your proposal to use erts version, and symlink release number is good, > i can go this way for sure, so we'll have closer repository structure.
Cool.
> thanks for your feedback. I better understand your choices now and they > make sense, i think i'll go this way.
> to build binaries, i build on differnte boxes (linux-x86 linux-amd64 > osx and some xen vm) windows is generated from binary tarball. > cross compilation script is in progress for linux, i used it to > crosscompile ejabberd installers for windows and linux. > i'm also working on an cean package to .deb script converter, that way > we could have benefits of debian's compilation farm.
I was wanting to play Cloudant's new search feature so I was going to start by indexing Agner packages into a Cloudant database. Which means converting to JSON. I just did one and my agner package ends up as:
The changes are obvious, strings->binaries and the url's value was a tuple of three values, but that won't convert to json since for a {} it expect {key, value}.
Just throwing this out in case others like the idea of being able to convert easily to JSON and having a repo in CouchDB/Cloudant (easy replication/full-text search).
Tristan
On Tue, Jul 19, 2011 at 4:40 PM, Eric Merritt <ericbmerr...@gmail.com>wrote:
> On Tue, Jul 19, 2011 at 4:26 PM, Christophe Romain > <christophe.rom...@process-one.net> wrote: > > Eric,
> > To cover the glibc compatibility issue, we have two choice: > > - build against many version of glibc > > - build with most compatible version
> > for cean i choosed the second option. building under debian stable is > > generally a good option for this, except for few month when major glibc > > version switch. > > doing so, i had compatibility issue only 2 times in 6 years, so i'm > > quite happy with this simplist choice. moreover, CEAN being a build > > framework, if a user is not happy with binary dependencies and needs > > latest glibc linked binary, he can deploy the framework and build its > > own epkg, linked to its own bleeding edge glibc.
> I am completely fine with this approach. As long is its been > considered and a solution that works introduced I am happy. The > explicit solution doesn't actually matter a whole lot.
> > i wanted to make cean as simple as possible. 90% users will be happy > > with binary compiled with same glibc as debian stable. while i can > > include glibc version is repository tree (to keep compatibility with > > erlware) i won't setup a complex build farm, so i'll keep build binary > > only against debian stable (libc-2.11.2 i think now) > > for bitwidh, i have linux-x86 and linux-amd64. maybe should i rename > > amd64 to x86_64, it's just a matter of choice here.
> Actually, uname returns x86_64, this is the same thing that > erlang:system_info(system_architecture) info returns. It just makes it > awkward that a translation has to occur to access the packages. Minor > yes, but inelegant.
> > i thought for long about use of release number or ets number (as you are > > using) and i kept simplest choice as i could not find best option here. > > I finally concluded this is more a question of taste. > > your proposal to use erts version, and symlink release number is good, > > i can go this way for sure, so we'll have closer repository structure.
> Cool.
> > thanks for your feedback. I better understand your choices now and they > > make sense, i think i'll go this way.
> > to build binaries, i build on differnte boxes (linux-x86 linux-amd64 > > osx and some xen vm) windows is generated from binary tarball. > > cross compilation script is in progress for linux, i used it to > > crosscompile ejabberd installers for windows and linux. > > i'm also working on an cean package to .deb script converter, that way > > we could have benefits of debian's compilation farm.
>> to build binaries, i build on differnte boxes (linux-x86 linux-amd64 >> osx and some xen vm) windows is generated from binary tarball. >> cross compilation script is in progress for linux, i used it to >> crosscompile ejabberd installers for windows and linux. >> i'm also working on an cean package to .deb script converter, that way >> we could have benefits of debian's compilation farm.
>Do you do all this by hand?
the entire build is one command, and then i rsync the generated repository on the public one. this is a manual or cron action. the aim of the crosscompilation script is to include it automatically when building everything from one instance of the framework. (this will not be ready for CEAN 2.0 release anyway)
I am working on a multi-platform build farm for continuous integration, supporting at least the platforms you already support (its my next big project). If you are interested I can open it up to you and maybe we can both benefit.
On Tue, Jul 19, 2011 at 11:49 PM, Christophe Romain
<christophe.rom...@process-one.net> wrote: > i'll rename amd64 to x86_64
>>> to build binaries, i build on differnte boxes (linux-x86 linux-amd64 >>> osx and some xen vm) windows is generated from binary tarball. >>> cross compilation script is in progress for linux, i used it to >>> crosscompile ejabberd installers for windows and linux. >>> i'm also working on an cean package to .deb script converter, that way >>> we could have benefits of debian's compilation farm.
>> Do you do all this by hand?
> the entire build is one command, and then i rsync the generated > repository on the public one. this is a manual or cron action. > the aim of the crosscompilation script is to include it automatically > when building everything from one instance of the framework. (this will > not be ready for CEAN 2.0 release anyway)
>I am working on a multi-platform build farm for continuous >integration, supporting at least the platforms you already support >(its my next big project). If you are interested I can open it up to >you and maybe we can both benefit.
that would be terrific by the way, i worked on an import script from archive you generate to produce epkg as well, so we can share compilation efforts anyway.
i'll ping you shortly when i have modification we talked about in this thread ready. our repository model will merge nicely.
Just a reminder. I am not the Agner guy thats Yuri. I am one of the Erlware guys, we don't have a repository anymore, we are relying on you all. Hence my interest and support :)
Eric
On Wed, Jul 20, 2011 at 5:00 PM, Christophe Romain
<christophe.rom...@process-one.net> wrote: >> I am working on a multi-platform build farm for continuous >> integration, supporting at least the platforms you already support >> (its my next big project). If you are interested I can open it up to >> you and maybe we can both benefit.
> that would be terrific > by the way, i worked on an import script from archive you generate to > produce epkg as well, so we can share compilation efforts anyway.
> i'll ping you shortly when i have modification we talked about in this > thread ready. our repository model will merge nicely.
<christophe.rom...@process-one.net> wrote: >> Erlware guys, we don't have a repository anymore, we are relying on >> you all. Hence my interest and support :)
Agner could use some better search... So you can do queries based on categories (web, build tool, gui) and full text search on the describtions like Agner has on its site (gen_leader: A project to unify various implementations of the Erlang library gen_leader into a modern, robust single implementation). As well as the readme. And find apps/releases that rely on X app.
I WANT to build this, but just want a) backing b) where would we wanted it hosted c) is there a site I'd integrate it into.
Tristan
On Wed, Jul 20, 2011 at 5:40 PM, Eric Merritt <ericbmerr...@gmail.com>wrote:
> You may consider that obsolete. As soon as we get our current projects > ported we will be taking the repos down.
> On Wed, Jul 20, 2011 at 5:27 PM, Christophe Romain > <christophe.rom...@process-one.net> wrote: > >> Erlware guys, we don't have a repository anymore, we are relying on > >> you all. Hence my interest and support :)
> > hum OK > > my script uses http://repo.erlware.org/pub as input > > may i consider this as obsolet then ?
