Community
Participate
Working Groups
N20130724-2000. 1 error and 11 failures in resource tests. http://download.eclipse.org/eclipse/downloads/drops4/N20130724-2000/testresults/html/org.eclipse.core.tests.resources_linux.gtk.x86_6.0.html
Created attachment 233778 [details] Test result
Might be caused by the fix for bug 373232.
(In reply to comment #2) > Might be caused by the fix for bug 373232. Will check that.
Do I read it correctly that only x86 version is affected?
(In reply to comment #4) > Do I read it correctly that only x86 version is affected? They passed on Mac OS X. Windows 7 sill pending: http://download.eclipse.org/eclipse/downloads/drops4/N20130724-2000/testResults.php
Not exactly the answer I was looking for. Download page http://download.eclipse.org/eclipse/downloads/drops4/N20130724-2000/ lists Eclipse GTK x86 with failed tests and x64_64 all green. That makes me wonder whether only GTK x86 is affected or maybe tests are run only for GTK x86.
(In reply to comment #6) > Not exactly the answer I was looking for. Download page > http://download.eclipse.org/eclipse/downloads/drops4/N20130724-2000/ lists > Eclipse GTK x86 with failed tests and x64_64 all green. That makes me wonder > whether only GTK x86 is affected or maybe tests are run only for GTK x86. I agree, it's misleading. Green does not mean that tests ran and are green. The page I gave you has all configs that we actually test.
.so files were built on newer GLIBC than run on. Binaries have to be built oldest supported GLIBC to prevent such problems. Assuming that SWT min is core.resources min .so files have to be rebuild on RHEL 5 (as swt is built), this should be low enough to work everywhere swt can be used on.
Q: what machine are linux tests run on ? OS version, GLIBC version, GLib version, GTK version.
(In reply to comment #8) > .so files were built on newer GLIBC than run on. Binaries have to be built > oldest supported GLIBC to prevent such problems. > Assuming that SWT min is core.resources min .so files have to be rebuild on > RHEL 5 (as swt is built), this should be low enough to work everywhere swt > can be used on. How is SWT related to core tests? (In reply to comment #9) > Q: what machine are linux tests run on ? OS version, GLIBC version, GLib > version, GTK version. The attached test result file should have some of that info.
Per Luna [1] plan Linux reference platforms are RHEL 6, Suse 11 and Ubuntu 12.04. I think the Foundation uses Suse. Rebuilding *.so on RHEL 5 should indeed solve the problem (I hope to get this done today, but it all depends how much time will I need to get RHEL5). [1] http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_4.xml
Per hudson configuration, linux tests are run on SLES 11, x86_64.
(In reply to comment #10) > (In reply to comment #8) > > .so files were built on newer GLIBC than run on. Binaries have to be built > > oldest supported GLIBC to prevent such problems. > > Assuming that SWT min is core.resources min .so files have to be rebuild on > > RHEL 5 (as swt is built), this should be low enough to work everywhere swt > > can be used on. > > How is SWT related to core tests? Not directly but I would expect natives shiped with platform to have the same minimum requirements. > > > (In reply to comment #9) > > Q: what machine are linux tests run on ? OS version, GLIBC version, GLib > > version, GTK version. > > The attached test result file should have some of that info.
Meanwhile I have reverted to the previous binaries: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=8ff4648d73bb0c5ca9d8f572267f6e8cd2a2ad14
New libs build using RHEL 5.9 https://git.eclipse.org/r/#/c/14878/
Szymon, John, any chance for releasing those libs?
Actually, this bug points a very important problem. Building of the native libraries is not defined at all. It would be very helpful if these builds happen on foundation machines with well known library versions. On behalf of Red Hat, we would like to donate RHEL subscription so we can get RHEL 5 VM(s) accessible by committers so builds can be done in known way (at least for linux native bits) and eventually automate this. For this to happen I would need to know the RHN account of some representative of the foundation so subscriptions can be assigned. This proposal wasn't taken earlier with the argument that foundation uses SLES and administrating another platform is unwanted. Here stands a very important question do we want to build native bits on the foundation or not? Should teams building native parts (swt, launcher, filesystem, net) change their build systems to SLES instance provided by foundation with all(if any) changes needed on development site (incl. different min version and etc.) or foundation should take my proposal and provide a RHEL 5 instance to get environment that closely mimics the current one? In short do we want to create churn for developers or for sysadmins. Either way is fine as long as we start to see movement on the topic.
Adding Mike and Denis to comment on comment 17.
I think everyone would like to see natives built at the foundation rather than by random committers on their own hardware. Until then LTS can only build the Java parts and therefore does not have a complete support solution. Meanwhile, what we have typically done is try to build natives on the oldest possible hardware/OS, with the presumption that this will enable our natives to run on the widest possible range of versions. This is especially true in core.filesystem where our natives are quite trivial and really should be able to run on very old platforms. I should also mention we have had the convention in core.filesystem to have a file BUILD_INFO.txt at the root of the fragment to document as much detail as possible about the compile environment for the current natives used in production. If you are contributing new natives in the short term can you please provide a patch or updated contents for that file.
Thinking more about it, I would rather not hijack this bug about test failures to dive into the general problem of building natives with CBI. There are already a number of open CBI bugs on the topic, such as bug 377115 and bug 377116. Let's just keep this focused on the short term problem of getting a clean test run.
> This proposal wasn't taken earlier with the argument that foundation uses > SLES and administrating another platform is unwanted. This still holds true -- we don't want to add maintenance burden if it is not required. As I recall, I was curious to know why RHEL was a requirement, but I cannot remember the answer. > Here stands a very important question do we want to build native bits on the > foundation or not? Yes. I've cc'd myself to bug 377116 to discuss the requirements for building the natives on Foundation hardware.
(In reply to comment #21) > > This proposal wasn't taken earlier with the argument that foundation uses > > SLES and administrating another platform is unwanted. > > This still holds true -- we don't want to add maintenance burden if it is > not required. As I recall, I was curious to know why RHEL was a requirement, > but I cannot remember the answer. The answer is that swt and I assume equinox.launcher do their builds on RHEL and even min version is aligned to RHEL version. Silenio, should be able to give more details. > > > Here stands a very important question do we want to build native bits on the > > foundation or not? > > Yes. > > I've cc'd myself to bug 377116 to discuss the requirements for building the > natives on Foundation hardware.
(In reply to comment #22) > (In reply to comment #21) > > > This proposal wasn't taken earlier with the argument that foundation uses > > > SLES and administrating another platform is unwanted. > > > > This still holds true -- we don't want to add maintenance burden if it is > > not required. As I recall, I was curious to know why RHEL was a requirement, > > but I cannot remember the answer. > > The answer is that swt and I assume equinox.launcher do their builds on RHEL > and even min version is aligned to RHEL version. Silenio, should be able to > give more details. > SWT and eclipse launcher libraries have always been built on RHEL machines (RHEL 4 for a long time and more recently RHEL 5). I believe the reason we use RHEL is because its default desktop is GNOME. SLED default desktop is KDE which has not been our priority. I do not think that RHEL machines are the requirement, the requirement is the GTK version and C runtime installed on the machine. Currently, we need GTK 2.10. I believe SLED 10 would be the equivalent distro to RHEL 5 but it has GTK 2.8 which may cause compilation problems on SWT.
New patch in gerrit : https://git.eclipse.org/r/#/c/14878/
I think it would be good to release this patch before SR1 work will steal all the attention.
I must have mistakenly added this bug to the security list. Undoing; apologies for the noise.
It looks like this was already fixed: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=8ff4648d73bb0c5ca9d8f572267f6e8cd2a2ad14
