Is anyone still using this com.google.collect bundle, for Juno?
Normally, we in Orbit would never consider removing a bundle this late in
the cycle, but this bug has fallen through the cracks.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371396
The original creators of com.google.collect
Hi,
Since yesterday night a number of unit tests in the the rap runtime
jobs [1] fail when trying to delete files from /tmp. I've never seen
such failures before and there hasn't been any change in the code, so
I assume that some change in the environment may have triggered it?
It's always the
The only recent change to Hudson that I am aware of is the addition of 2
extra build slots on Slave1 to help relieve the build load.
-Matt.
--
Eclipse WebMaster - webmas...@eclipse.org
Questions? Consult the WebMaster FAQ at
http://wiki.eclipse.org/index.php/Webmaster_FAQ
View my status
Greetings folks. The IP Log submission deadline for Juno is today.
If your project has CQs that still need to be processed, please hold off
submitting until the CQs have been approved.
There are some resources to help you sort out your logs.
The Downloads Report [1] compares the contents of
It turned out that the problem was on our side [1], sorry for
suspecting the server!
We had two similar builds scheduled at the same time and both were
accessing the same temp dir, one deleting the other's files - how
stupid :-/
Thank you anyway,
Ralf
[1] 380420: Build failures on Eclipse
Compiled 2012-05-23T12:07
build.eclipse.org
- Usage exceeding 1GB for: Hudson master jobs and workspace (2012-05-23T10:00)
20.0G emf-emfstore-integration
3.6G skalli
3.0G cbi-pdt-2.2-helios
2.9G JUnit-win2
2.6G cbi-pdt-3.0-indigo
2.4G papyrus-0.8-EYY-maintenance
2.3G
Here it is, nearly 5 PM on +3 day, and we haven't had a green build all
day!?
I've been assuming people were tending to the issues and fixing things
up ... but ... without some quick communication here, I'm going to start
disabling projects in order to get a good build.
Please let us know if
Hi David, all,
I am sorry, I made a change in the agregator, but it seems my new
updates sites do not have the right MD5.
And I don't understand, since I did not change my Maven-signing-plugin
configuration.
I am doing one last try, and then I was about to email you about this
(or about to
Thanks to all the last minute fixes and getting a clean build. I've
disabled the aggregation build and assume we are ready for RC1, unless
someone comes up with a blocking problem that justifies a respin.
My main concern is that there are still two projects still disabled:
amp.b3aggrcon
