Community
Participate
Working Groups
See http://download.eclipse.org/eclipse/downloads/drops4/I20160419-0800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt 1. rt.equinox.framework/features/org.eclipse.equinox.executable.feature classifier-root.gtk.solaris.sparc: not present in baseline classifier-root.gtk.solaris.x86: not present in baseline no-classifier: different META-INF/ECLIPSE_.RSA: different The main artifact has been replaced with the baseline version. The following attached artifacts have been replaced with the baseline version: [root.gtk.linux.x86, root.gtk.linux.x86_64, root.gtk.linux.ppc64, root.gtk.linux.s390, root.win32.win32.x86_64, root.gtk.aix.ppc, root.gtk.linux.ppc, root.gtk.linux.s390x, root.gtk.aix.ppc64, root.gtk.hpux.ia64, root.gtk.solaris.x86_64, root.win32.win32.x86, root.cocoa.macosx.x86_64, root.gtk.linux.ppc64le] The following attached artifacts are not present in the baseline and have been removed: [root.gtk.solaris.sparc, root.gtk.solaris.x86] I am not sure what to make of this "comparator error". That is, not sure if it is significant, or not. But, we shouldn't get any, so we should examine how qualifier is set for the executable feature.
A quick peak shows the feature is versioned as follows. org.eclipse.equinox.executable.feature.group 3.6.300.v20160414-1953 This might, in part, be due to the "off schedule" I-build I did on the weekend. Has there been changes (say, pom only changes?) since 04/14?
This comparator error showed up again in http://download.eclipse.org/eclipse/downloads/drops4/I20160427-0400/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt I would suggest touching the feature version (if not incrementing it minor version) to avoid the warning. I am guessing there is less harm that usual in this case, since it sounds like it is merely leaving out the platforms we no longer build, but to be sure, the feature should be 'touched'.
New Gerrit change created: https://git.eclipse.org/r/71519
Gerrit change https://git.eclipse.org/r/71519 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=82312793d230c2f4669d72f8e1d34a544edebd1b
I touched the feature.
Fixed in I20160427-1200.
Appears again in I20160428-0800
I changed title a bit, as the comparator error is back, and I think we will always see them, since root.gtk.solaris.sparc and root.gtk.solaris.x86 are somehow being "put back" in each current build. The end result (as delivered) seems to not have them included since the message from Tycho implies they were removed. 1. rt.equinox.framework/features/org.eclipse.equinox.executable.feature classifier-root.gtk.solaris.sparc: not present in baseline classifier-root.gtk.solaris.x86: not present in baseline no-classifier: different META-INF/ECLIPSE_.RSA: different The main artifact has been replaced with the baseline version. The following attached artifacts have been replaced with the baseline version: [root.gtk.linux.x86, root.gtk.linux.x86_64, root.gtk.linux.ppc64, root.gtk.linux.s390, root.win32.win32.x86_64, root.gtk.aix.ppc, root.gtk.linux.ppc, root.gtk.linux.s390x, root.gtk.aix.ppc64, root.gtk.hpux.ia64, root.gtk.solaris.x86_64, root.win32.win32.x86, root.cocoa.macosx.x86_64, root.gtk.linux.ppc64le] The following attached artifacts are not present in the baseline and have been removed: [root.gtk.solaris.sparc, root.gtk.solaris.x86] But I think whatever "puts them back" should be fixed for RC1.
While not directly related to this bug (sorry to piggyback) but is related to "cleaning up lower level scripts" (I am guessing). I see messages in the log such as the following: [WARNING] Mirror tool: Problems resolving provisioning plan.: [Unable to satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to org.eclipse.swt.gtk.linux.aarch64 [3.105.0.v20160427-1439].; Unable to satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to org.eclipse.swt.gtk.linux.arm [3.105.0.v20160427-1439].; Unable to satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to org.eclipse.swt.gtk.solaris.sparc [3.105.0.v20160427-1439].; Unable to satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to org.eclipse.swt.gtk.solaris.x86 [3.105.0.v20160427-1439].] These typically do not hurt anything, as far as I know, but would be best to minimize such warnings.
New Gerrit change created: https://git.eclipse.org/r/71644
(In reply to Eclipse Genie from comment #10) > New Gerrit change created: https://git.eclipse.org/r/71644 This is an attempt at removing the extra solaris x86 and sparc stuff.
New Gerrit change created: https://git.eclipse.org/r/71729
(In reply to Eclipse Genie from comment #12) > New Gerrit change created: https://git.eclipse.org/r/71729 A local test build still showed an issue, which might be the way I do local test builds, but was enough for me to take a look. I think the key it to remove 'root' references in the build.properties file. (You might want to "comment out" the sparc one, since we presumably will be getting a replacement, but I just deleted it in my Gerrit commit.
(In reply to David Williams from comment #9) > While not directly related to this bug (sorry to piggyback) but is related > to "cleaning up lower level scripts" (I am guessing). > I see messages in the log such as the following: > > [WARNING] Mirror tool: Problems resolving provisioning plan.: [Unable to > satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to > org.eclipse.swt.gtk.linux.aarch64 [3.105.0.v20160427-1439].; Unable to > satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to > org.eclipse.swt.gtk.linux.arm [3.105.0.v20160427-1439].; Unable to satisfy > dependency from org.eclipse.swt 3.105.0.v20160427-1439 to > org.eclipse.swt.gtk.solaris.sparc [3.105.0.v20160427-1439].; Unable to > satisfy dependency from org.eclipse.swt 3.105.0.v20160427-1439 to > org.eclipse.swt.gtk.solaris.x86 [3.105.0.v20160427-1439].] > I have opened bug 492748 for these SWT issues.
(In reply to David Williams from comment #13) > (In reply to Eclipse Genie from comment #12) > > New Gerrit change created: https://git.eclipse.org/r/71729 > > A local test build still showed an issue, which might be the way I do local > test builds, but was enough for me to take a look. > > I think the key it to remove 'root' references in the build.properties file. > > (You might want to "comment out" the sparc one, since we presumably will be > getting a replacement, but I just deleted it in my Gerrit commit. David, you object to my more aggressive clean up of the unused fragments? https://git.eclipse.org/r/71644
(In reply to Thomas Watson from comment #15) > (In reply to David Williams from comment #13) > > (In reply to Eclipse Genie from comment #12) > > > New Gerrit change created: https://git.eclipse.org/r/71729 > > > > A local test build still showed an issue, which might be the way I do local > > test builds, but was enough for me to take a look. > > > > I think the key it to remove 'root' references in the build.properties file. > > > > (You might want to "comment out" the sparc one, since we presumably will be > > getting a replacement, but I just deleted it in my Gerrit commit. > > David, you object to my more aggressive clean up of the unused fragments? > > https://git.eclipse.org/r/71644 No, not at all. I think it is a good idea. I was just trying to explain how (I think) things end up "in the feature" even though the feature doesn't include it).
(In reply to David Williams from comment #13) > (In reply to Eclipse Genie from comment #12) > > New Gerrit change created: https://git.eclipse.org/r/71729 > > A local test build still showed an issue, which might be the way I do local > test builds, but was enough for me to take a look. > FWIW, my local test build "passed" the comparator issue with these lines removed from the build.properties file.
(In reply to Thomas Watson from comment #15) > David, you object to my more aggressive clean-up of the unused fragments? > > https://git.eclipse.org/r/71644 I know now why you asked this question. I was under the impression, somehow, the Gerrit patch was already applied. Thus, when I still got the error locally, I took a quick glance at the patch and I did not see "build.properties" there. So, I was wrong on several counts. Apologies for the confusion.
FYI, there was another (probably unrelated) comparator error in I20160501-2000. See http://download.eclipse.org/eclipse/downloads/drops4/I20160501-2000/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt Namely, 4. rt.equinox.bundles/features/org.eclipse.equinox.serverside.sdk no-classifier: different META-INF/ECLIPSE_.RSA: different META-INF/ECLIPSE_.SF: different feature.xml: different The main artifact has been replaced with the baseline version. I have not looked in detail at this one, but in my experience, when only the feature.xml differs, but does not otherwise cause build problems, it has been because the "install-size" or "download-size" changed by a byte or two. No idea why that is, but hardly worth worry about. I'd recommend if you "see for two or more days" (especially after fixing the main issue of this bug) then I would just touch the feature and not be concerned with exactly what's different. But, you are free to analyze it detail, if you'd like.
Gerrit change https://git.eclipse.org/r/71644 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=38c7472358b829dac4ef35dddf53e71d909b3576
I have merged Tom's patch which removes all the remnants of the old Solaris builds. David, can you please run a local test build and check whether the comparator errors are gone? (There has been a qualifier update from SWT and I'm hoping the SWT error is also gone).
(In reply to Arun Thondapu from comment #21) > I have merged Tom's patch which removes all the remnants of the old Solaris > builds. > > David, can you please run a local test build and check whether the > comparator errors are gone? (There has been a qualifier update from SWT and > I'm hoping the SWT error is also gone). In my local test build, there were no comparator errors for launchers or SWT, so will mark as fixed. To actually "verify" this bug, though, it will take two I-builds which have the same qualifier (no other changes) to make sure the contents and qualifier are "constant". If not obvious, this is because this change will increment qualifier and if the qualifier is unique then there will never be a qualifier error. So, it is only on the second turn of the wheel that we'd know "everything stayed the same". Thanks!
Adding review+ for RC1.
Verified in I20160504-0035.
