Greg has it all correct.
But nothing prevents Alibaba from publishing under coordinates that they
control.
It needs to be clear however that it is alibaba publishing there, not
Apache.
On Tue, May 8, 2018, 13:56 Greg Stein wrote:
> Hi all,
>
> I wanted to send a note that Infra has seen a coup
I can't comment on the ActiveMQ builds, but I can say that Jenkins is
really flaky lately. Last time I counted (last week), we had 20% of the
Drill and Mahout builds failing due to issues with Jenkins. It is also
common if you look into the build queues to see jobs that normally take 20
minutes t
Is anybody else out there ?
Any hints about what the problem is?
On Mon, Mar 25, 2013 at 11:32 PM, Andy Seaborne wrote:
> On 24/03/13 06:28, Ted Dunning wrote:
>
>> I see a continuing pattern of jobs failing on Jenkins. This happens with
>> Mahout-Quality and Drill-Physica
I see a continuing pattern of jobs failing on Jenkins. This happens with
Mahout-Quality and Drill-Physical-Plan. Both jobs are totally stable on
other platforms and do not involve non-deterministic tests. In any case,
these failures can occur long before the tests even start. Failures seem
to o
Thanks for this.
On Wed, Feb 6, 2013 at 10:39 AM, Jesse Glick wrote:
> To Ted Dunning’s request for the bug number—searching on bugs.sun.comseems to
> be broken, and as I no longer work for Oracle I cannot use the
> internal search tool. Fortunately I managed to dig it up using other means:
>
Do you have a reference to the bug?
This is still a very early version of java 7. It would be good to update
it.
On Tue, Feb 5, 2013 at 5:49 PM, Jesse Glick wrote:
> On 02/05/2013 07:30 PM, sebb wrote:
>
>> a pure Java application should not be able to cause a JVM crash
>>
>
> Depends entirely
Thanks. It helped.
On Mon, Feb 4, 2013 at 11:58 PM, Niklas Gustavsson wrote:
> On Tue, Feb 5, 2013 at 2:32 AM, Ted Dunning wrote:
> > There are three builds running on ubuntu4. Two have been running for
> over
> > 30 hours. One has been running for nearly 8 hours.
>
&g
This is an ancient JRE. The current series is 1.7.0_11 while the JRE in
the stack trace mentioned here is from the original release. Many serious
problems were noted in early Java 7 builds.
I seriously doubt that making a bug report against this version of the JDK
will be useful.
On the other h
That time makes it look like the leap second issue.
On Mon, Jul 2, 2012 at 11:12 PM, Todd Lipcon wrote:
> Our Precommit build (https://builds.apache.org/job/PreCommit-Admin/)
> appears to have stopped running at 7/2 5PM. I've manually triggered it a
> couple times since, but otherwise not runnin
Thanks enormously.
On Sat, Apr 2, 2011 at 1:35 PM, Niklas Gustavsson wrote:
> On Sat, Apr 2, 2011 at 10:16 PM, Ted Dunning
> wrote:
> > It looks to me that since March 24, the Mahout build fails on solaris1
> and
> > succeeds on solaris2. This isn't a clear cu
It looks to me that since March 24, the Mahout build fails on solaris1 and
succeeds on solaris2. This isn't a clear cut pattern just yet, but it
smells like solaris1 is misconfigured somehow.
https://hudson.apache.org/hudson/job/Mahout-Quality/buildTimeTrend
On Sat, Apr 2, 2011 at 11:18 AM, Apac
Sure. Will do.
On Fri, Feb 4, 2011 at 6:18 AM, Niklas Gustavsson wrote:
> On Sat, Jan 29, 2011 at 6:02 PM, Ted Dunning
> wrote:
> > Is there a way to revert to previous maven in the mean time? Are there
> > other build machines running older versions?
>
> We have no
Even if the trademark stuff is marginally relevant, having the redirect in
place actually lets us change the real name
sooner rather than later and thus be more cautious rather than less.
On Thu, Feb 3, 2011 at 3:35 PM, Benson Margulies wrote:
> So I claim that the trademark business is not relev
+1 for builds as the domain name.
On Thu, Feb 3, 2011 at 1:30 PM, Uwe Schindler wrote:
> +1! Just simple: builds.apache.org?
>
I haven't a clue.
Is there a way to revert to previous maven in the mean time? Are there
other build machines running older versions?
On Sat, Jan 29, 2011 at 6:43 AM, Niklas Gustavsson wrote:
> On Sat, Jan 29, 2011 at 7:08 AM, Ted Dunning
> wrote:
> > The Mahout build started
The Mahout build started doing this a few days ago. Any ideas?
https://hudson.apache.org/hudson/job/Mahout-Quality/buildTimeTrend
> [INFO] Apache Mahout . FAILURE
> [16.513s]
> [INFO] Mahout Build Tools SKIPPED
> [INFO] Mahou
I seems to occur much more often on one solaris slave than the other. Does
that help diagnose it?
On Tue, Oct 19, 2010 at 12:21 AM, Niklas Gustavsson wrote:
> On Tue, Oct 19, 2010 at 8:27 AM, Uwe Schindler wrote:
> > Since yesterday morning the clover xml parsing is again sometimes broken
> on
Over the last two days Mahout-Quality has had 4 successful builds and no
failures from solaris1 and 7 builds with 4 failures from solaris2. A quick
chi^2 test indicates that this is a significant difference at p < 0.02.
I think solaris2 has something wrong. I also think that this changed two
day
I concur that the current situation is worlds better than it was.
On Sun, Oct 3, 2010 at 4:30 AM, Niklas Gustavsson wrote:
> On Sun, Oct 3, 2010 at 3:05 AM, Jukka Zitting
> wrote:
> > If we can't fix the ssh problems, perhaps trying another slave launch
> > method might help?
>
> We previously u
Started by timer
Building remotely on ubuntu1
hudson.util.IOException2: remote file operation failed:
/home/hudson/hudson-slave/workspace/mahout-nightly at
hudson.remoting.chan...@4c8e32ea:ubuntu1
at hudson.FilePath.act(FilePath.java:749)
at hudson.FilePath.act(FilePath.java:735)
; If that is easily shoveled around to other projects then it probably
> does everything I am looking to do.
>
> On Mon, Sep 27, 2010 at 8:47 PM, Ted Dunning
> wrote:
> > How is this different from the Hadoop patch plugin? There, patches added
> to
> > JIRA are checked out
How is this different from the Hadoop patch plugin? There, patches added to
JIRA are checked out and built with problems reported back to JIRA.
On Mon, Sep 27, 2010 at 5:43 PM, Benson Margulies wrote:
> In some 'day job' environments I've worked in, the infrastructure
> included a 'pre-flight' a
I talked some with Benson off-list.
It seems that he does indeed want a pre-commit builder. This is similar in
intent to the system used in Hadoop and related projects where adding a
patch to JIRA triggers a build.
There would be several ways to skin Benson's cat. Something along the lines
he i
Ouch. It sounds like the easiest optimization would be to not do this
computation if the dependencies for the current job have not changed.
That would be easier than doing the correct thing which would be to
propagate simply changes until the system reaches something unchanged.
On Tue, Sep 21, 2
Will do.
On Sun, Sep 19, 2010 at 1:17 AM, Niklas Gustavsson wrote:
> On Sun, Sep 19, 2010 at 1:20 AM, Ted Dunning
> wrote:
> > Hudson also thinks that I am logged in as System. That doesn't seem
> right.
>
> This is a known bug in Hudson and has been reported
Restart seems to have helped. The Mahout job gets scheduled now although it
is running very slowly (2 minutes to start checking out code). That may be
part of a startup transient load.
On Sat, Sep 18, 2010 at 4:25 PM, Gav... wrote:
>
>
> > -Original Message-
> >
One additional point of information, while I was inexplicably logged in as
System, I tried sending a trivial groovy script to the slaves I thought were
problematic. They gave the same SSH connection problem stack trace.
On Sat, Sep 18, 2010 at 4:23 PM, Gav... wrote:
> Or do you think the build
nt to help resolve
> it.
>
> Thanks
>
> Gav...
>
>
> > -Original Message-
> > From: Ted Dunning [mailto:ted.dunn...@gmail.com]
> > Sent: Sunday, 19 September 2010 9:12 AM
> > To: builds@apache.org
> > Subject: hudson confused again
> >
&
Hudson also thinks that I am logged in as System. That doesn't seem right.
I am seeing on all Mahout builds. Changing to ubuntu has the same issue. I
suspect that this is the reason that the build queue is so short.
Started by user tdunning
Building remotely on solaris1
hudson.util.IOException2: remote file operation failed:
/export/home/hudson/hudson-slave/workspace/
Thanks so much. Hopefully both measures (by the Hudson team and by you)
will bear fruit.
On Sat, Sep 18, 2010 at 1:00 PM, Niklas Gustavsson wrote:
> On Sat, Sep 18, 2010 at 8:29 PM, Ted Dunning
> wrote:
> > Does anybody have an idea why these fall over sooo often?
>
> There a
Does anybody have an idea why these fall over sooo often?
On Sat, Sep 18, 2010 at 1:26 AM, Niklas Gustavsson wrote:
> On Sat, Sep 18, 2010 at 9:26 AM, Antoine Toulme
> wrote:
> > Can someone revive ubuntu1 ? It shows offline
>
> Fixed now.
>
> /niklas
>
tionary.com/knickerbockers>
*get one's knickers in a twist* *Slang* to become agitated, flustered, or
upset
On Sun, Sep 12, 2010 at 12:39 PM, Niklas Gustavsson wrote:
> On Wed, Sep 8, 2010 at 3:00 AM, Ted Dunning wrote:
> > Has Hudson got his knickers in a twist?
>
> I actually hav
Yeah... saw that occasionally as well, but refresh usually fixed it.
On Tue, Sep 7, 2010 at 8:32 PM, Luciano Resende wrote:
> On Tue, Sep 7, 2010 at 6:00 PM, Ted Dunning wrote:
> >
> > Has Hudson got his knickers in a twist?
> > https://hudson.apache.org/hudson/job/Hive-tr
issue a few days ago I think.
>
> On Tue, Sep 7, 2010 at 18:00, Ted Dunning wrote:
>
> > Has Hudson got his knickers in a twist?
> >
> > https://hudson.apache.org/hudson/job/Hive-trunk-h0.18/
> >
> > gets a 500 error persistently.
> >
> > Likewise so does https://hudson.apache.org/hudson/computer/ubuntu1/
> >
>
Has Hudson got his knickers in a twist?
https://hudson.apache.org/hudson/job/Hive-trunk-h0.18/
gets a 500 error persistently.
Likewise so does https://hudson.apache.org/hudson/computer/ubuntu1/
The ubuntu1 build machine seems wedged. It has two builds that are listed
as having been running for the last 18 hours.
The Hudson build queue also appears to be growing without bound, possible
because of this.
k that this is a new problem.
On Tue, Sep 7, 2010 at 4:14 AM, Niklas Gustavsson wrote:
> On Tue, Sep 7, 2010 at 8:13 AM, Ted Dunning wrote:
> > Twice in a row.
> >
> > and now I have kicked off another try ... and we get the same problem.
>
> Looking at the build
Twice in a row.
and now I have kicked off another try ... and we get the same problem.
[INFO] [checkstyle:checkstyle {execution: default-cli}]
[INFO]
[ERROR] BUILD ERROR
[INFO] --
39 matches
Mail list logo
