Dear all:
After one weeks great work.
Julien had release the new toolchain release.
please take a look of this Page.
http://wiki.openmoko.org/wiki/Toolchain
Bobby Martin ??:
From: Ian Darwin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
I did mention when I jumped in that I was talking
On Mon, May 05, 2008 at 05:55:43PM -0400, Ian Darwin wrote:
You completely misunderstood what I said. Storing the file name, URL
*and* its MD5 lets you be sure you are able to reproduce the build. And
What I meant to say here was: Storing the file name, URL
and the MD5 of the *source* tarball
From: Ian Darwin [EMAIL PROTECTED]
I did mention when I jumped in that I was talking about a slightly
different problem than what you seem to be trying to solve. That said...
Storing your MD5s will let you know *if* you are repeating a build. It
will not (reasonably) let you repeat a
Hugo Mills wrote:
On Sat, May 03, 2008 at 08:21:27PM -0400, Lally Singh wrote:
Just out of curiosity, would maven be completely out of the question?
Yes.
Please, for the love of all that's holy, no.
I work with maven in my job. It's the most horrible misbegotten
misdesigned piece of
On Sunday 04 May 2008 22:17, Ian Darwin wrote:
You want repeatable builds? Write a build system that saves the
complete name and MD5 of every file, and checks every file that it
downloads before using it, every time.
Pssst:
http://hudson.gotdns.com/wiki/display/HUDSON/Fingerprint
AVee
--
From: Ian Darwin [EMAIL PROTECTED]
SNIP
While I might not have worded it quite that way, I have considered writing
a paper with the title Maven Considered Harmful. But it would be too short
to publish as a paper... The main problem is, as Hugo mentioned,
dependencies can change without
Just out of curiosity, would maven be completely out of the question?
Package up the dependent tarballs into maven projects, and list the OM
stack as depending on specific versions of them. Maven can wrap up
the complexity of finding all the various packages for people who just
want to download
On Sat, May 03, 2008 at 08:21:27PM -0400, Lally Singh wrote:
Just out of curiosity, would maven be completely out of the question?
Please, for the love of all that's holy, no.
I work with maven in my job. It's the most horrible misbegotten
misdesigned piece of hideousness I've ever had
Huh, we've had the exact opposite experience over here.
The trick that's worked here is to recognize the top-level app is
little more than a shell for the plugins. I download the source of
the plugins when there's a problem, and ping the maven listserv. The
documentation needs help, a *lot* of
On Fri, 2008-05-02 at 07:02 +0200, Joachim Steiger wrote:
i do not really get what you mean by labels.
when buildhost successfully finished a build there is a new image.
else, there is not.
if it cannot compile all dependencies then it logically cannot package it.
i think i know what you
There are some documentation you can find on wiki.
Here is the links.
OpenEmbeded is used to make the distribution. BitBake is the useful
command of OE, and being used to build and maintain a number of embedded
Linux distributions. You can use this.
Now, we mainly use this.
On Fri, May 2, 2008 at 12:02 AM, Joachim Steiger [EMAIL PROTECTED] wrote:
Bobby Martin wrote:
On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Well, there is buildhost.openmoko.org
http://buildhost.openmoko.org which builds
This is all good and well, however there's one inherently problematic issue to
consider here. Continuous integration is very good and very possible (and we
need and will to use it to improve quality), however where it really shines
is, when the complete stack is under your control.
Bobby Martin wrote:
What I mean by a label (sometimes called a tag) is that your build
process uses
your revision control systems' commands to apply a label to all files
before the
build process starts. In svn, you use the svn copy command to tag
files, like so:
svn copy
Michael 'Mickey' Lauer wrote:
This is all good and well, however there's one inherently problematic issue
to
consider here. Continuous integration is very good and very possible (and we
need and will to use it to improve quality), however where it really shines
is, when the complete stack
On Fri, May 2, 2008 at 9:20 AM, Joachim Steiger [EMAIL PROTECTED] wrote:
Michael 'Mickey' Lauer wrote:
This is all good and well, however there's one inherently problematic
issue to
consider here. Continuous integration is very good and very possible
(and we
need and will to use it to
I haven't been on a project where we pulled a significant amount of code
from repositories not under our control, and I agree that changes things
slightly. It seems to me that it's more reason, not less, for CI, though.
(Really, I think you're already on the same track...)
atleast for QA
On Thursday 01 May 2008 18:01:38 Bobby Martin wrote:
I sent this before to openmoko-devel and was greeted with a deafening
silence, so I'm resending to a broader audience. As evidenced by a recent
post to openmoko-devel by saurabh gupta, one of the GSoC selectees, this
really is a problem.
I sent this before to openmoko-devel and was greeted with a deafening
silence, so I'm resending to a broader audience. As evidenced by a recent
post to openmoko-devel by saurabh gupta, one of the GSoC selectees, this
really is a problem. The longer it's put off, the more potential benefits
(in
On Thu, 2008-05-01 at 11:01 -0500, Bobby Martin wrote:
I sent this before to openmoko-devel and was greeted with a deafening
silence, so I'm resending to a broader audience. As evidenced by a
recent post to openmoko-devel by saurabh gupta, one of the GSoC
selectees, this really is a problem.
On Thu, May 1, 2008 at 11:18 AM, Thomas Wood [EMAIL PROTECTED] wrote:
On Thu, 2008-05-01 at 11:01 -0500, Bobby Martin wrote:
I sent this before to openmoko-devel and was greeted with a deafening
silence, so I'm resending to a broader audience. As evidenced by a
recent post to
On Thu, 2008-05-01 at 11:29 -0500, Bobby Martin wrote:
I understand that your answer may well be the reason things are as
they are, but I disagree strongly with the sentiment.
To my mind, the first step after you have an early prototype of a
system that works is to set up a continuous
On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED] wrote:
Well, there is buildhost.openmoko.org which builds images nightly. I've
been asking for the toolchain to be fixed and updated and I believe
Julian has this on his TODO list.
Regards,
Thomas
Thanks for pointing that
On Thu, May 1, 2008 at 11:54 AM, Bobby Martin [EMAIL PROTECTED]
wrote:
On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED]
wrote:
Well, there is buildhost.openmoko.org which builds images nightly. I've
been asking for the toolchain to be fixed and updated and I believe
Bobby Martin wrote:
On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Well, there is buildhost.openmoko.org
http://buildhost.openmoko.org which builds images nightly. I've
been asking for the toolchain to be fixed and updated and
25 matches
Mail list logo
