Community
Participate
Working Groups
The delta-pack should contain the o.e.core.filesystem bundle for aix.ppc64 to allow handling of symbolic links on AIX. It seems to be simply omitted from the delta-pack packaging. This is also the case in Indigo (probably Helios also), so is probably just a packaging script error.
It appears the bundle to handle symbolic links in AIX ppc64 isn't being built at all (which explains why it's not showing in the delta-pack or other zips), so I changed the summary. The code to handle this was added during Helios (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=293185#c8) but apparently it is not being built and is not referenced in the platform feature. I believe we need to add this to the build and produce the bundle in order for users wanting symbolic links to work on aix.ppc64 to function.
In master, I've updated the platform feature to "pull in" the fragment: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=ab1fa1e509c5ae58df689f4d89668bd4db95666e (There was also a tiny change to the feature's pom.xml file, not that I know why "exclude" is necessary, but I just mimiced what was done for aix.ppc). And I updated the core map file so PDE knows where to pull it from http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=342eb21b151acc5c6e2f072963ae7981ba893c3b http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=2b5d3f05ebb3f94cc5d615a75272c50fb7388c2b I did the map commit to two steps, since I'm not positive what to use as the initial version. I was going to simply use v0-0, at first, but it seems both of these fragments (aix.ppc and aix.ppc64) are both in the same git project, so I feared it would appear as "no change" to the scripts that check if repo has changed or not ... so instead of v0-0 decided to use the same, existing tag as for the aix.ppc entry as the starting point for the aix.ppc64 entry, namely v20120913-140028. We'll see if it builds at all in tonight's (11/14) nightly build, but even if so, will need to confirm I-build carefully since that's where the tag will come more into play. (At worse, a core resources committer might have to "touch" a file there, so it looks like a recent update but think it will be fine as is). I think the delta-pack will take care of itself once the fragment is "in the build". Once "head build" is confirmed, we can back port to maintenance.
Thanks David. We also had a request to look into the same issue for these platforms: solaris.sparcv9 and linux.ppc64 Can we tell if similar actions should happen for those?
(In reply to comment #3) > Thanks David. We also had a request to look into the same issue for these > platforms: > solaris.sparcv9 and linux.ppc64 > Can we tell if similar actions should happen for those? Just those two? Yep. Let's see how the nightly does with the one addition and if that works, I'll add two more on Thursday ... and THEN we'll back port.
Nightly seems well. Its repo and the delta pack contain org.eclipse.core.filesystem.aix.ppc64_1.1.0.N20121114-2000.jar (of course, others will need to run/inspect it to make sure it is correct ... but, it is there). I'll look at solaris.sparcv9 and linux.ppc64 now.
(In reply to comment #5) > I'll look at solaris.sparcv9 and linux.ppc64 now. I see solaris.sparcv9 appears to exist already: eclipse.platform.resources/bundles/org.eclipse.core.filesystem/fragments/org.eclipse.core.filesystem.solaris.sparcv9 So, assuming we could just add that to feature and map as we did for aix64. But, I don't see any filesystem fragments for linux.ppc64; only linux.ppc. Szymon, am I missing it? Not exist? Able to create?
(In reply to comment #6) > I see solaris.sparcv9 appears to exist already: > > eclipse.platform.resources/bundles/org.eclipse.core.filesystem/fragments/org. > eclipse.core.filesystem.solaris.sparcv9 > > So, assuming we could just add that to feature and map as we did for aix64. > > But, I don't see any filesystem fragments for linux.ppc64; only linux.ppc. > > Szymon, am I missing it? Not exist? Able to create? Right. I have no access to such machine/compiler and I do not plan to build it.
I've pushed changes for aix.ppc64 and and sparcv9 for master, R3_8_maintenance, and R4_2_maintenance. So, will mark as fixed. But feel free to proofread :) plenty of opportunities for typos (took me 2 or 3 tries, but think I got them all). And we'll need to re-verify after tagged builds (I and M) next week.
I must have messed up the map file change or something, and caused the Nightly to fail with .... platform_eclipse_platform_resources_git/bundles/org.eclipse.core.filesystem.solaris.sparcv9 does not exist Maybe wrong tag? I'll investigate and restart a nightly if its an obvious fix.
I had originally copied the map entry for "sparc" for "sparcv9" but in fact sparcv9 is in a different directory ... I had to add "org.eclipse.core.filesystem/fragments/" to the path in the map entry. (I knew all along where it was and just wasn't paying close attention). I fixed in master and the two maintenance branches.
Two steps forward, one step back ... next failure was Processing inclusion from feature org.eclipse.platform: Bundle org.eclipse.core.filesystem.solaris.sparcv9_1.1.0.N20121115-2100 failed to resolve.
I see in "master", I had forgotten to change the "arch" value in the feature.xml entry to "sparcv9" ... leaving it as "sparc" from the copy/paste. I had caught this in the maintenance branches ... but ... guess I confused myself by the time I got back to fixing it in master. Next try at 10 PM
(In reply to comment #3) > Thanks David. We also had a request to look into the same issue for these > platforms: > solaris.sparcv9 and linux.ppc64 > Can we tell if similar actions should happen for those? linux.ppc64 has been answered in other comments. In bug 396653 John says "no" to sparcv9. So ... unless I'm misunderstanding, I'll work towards removing the sparcv9 changes I made. (As indicated in bug 396653, more work would be required to get sparcv9 "built right" ... in the repo, etc.)
(In reply to comment #7) > (In reply to comment #6) > > I see solaris.sparcv9 appears to exist already: > > > > eclipse.platform.resources/bundles/org.eclipse.core.filesystem/fragments/org. > > eclipse.core.filesystem.solaris.sparcv9 > > > > So, assuming we could just add that to feature and map as we did for aix64. > > > > But, I don't see any filesystem fragments for linux.ppc64; only linux.ppc. > > > > Szymon, am I missing it? Not exist? Able to create? > > Right. I have no access to such machine/compiler and I do not plan to build > it. Symon, any reason for not plan to build it besides you not having access to the machine/compiler?
(In reply to comment #14) > (In reply to comment #7) > > (In reply to comment #6) > > > I see solaris.sparcv9 appears to exist already: > > > > > > eclipse.platform.resources/bundles/org.eclipse.core.filesystem/fragments/org. > > > eclipse.core.filesystem.solaris.sparcv9 > > > > > > So, assuming we could just add that to feature and map as we did for aix64. > > > > > > But, I don't see any filesystem fragments for linux.ppc64; only linux.ppc. > > > > > > Szymon, am I missing it? Not exist? Able to create? > > > > Right. I have no access to such machine/compiler and I do not plan to build > > it. > > Symon, any reason for not plan to build it besides you not having access to > the machine/compiler? Of course not. If you can help and build the lib, I will push it to the repo.
Created attachment 224892 [details] PPC64 native library Here is the core.filesystem native library compiled on PPC64.
(In reply to comment #16) > Created attachment 224892 [details] > PPC64 native library > > Here is the core.filesystem native library compiled on PPC64. Thanks Bogdan. I added a new fragment for linux.ppc64, updated platform.resources repo, but can't push changed to platform.releng. David, could you add the fragment to org.eclipse.platform-feature? Thanks.
(In reply to comment #17) > (In reply to comment #16) > > Created attachment 224892 [details] > > PPC64 native library > > > > Here is the core.filesystem native library compiled on PPC64. > > Thanks Bogdan. I added a new fragment for linux.ppc64, updated > platform.resources repo, but can't push changed to platform.releng. David, > could you add the fragment to org.eclipse.platform-feature? Thanks. Yes. But since maintenance builds are "in progress" today, I'd prefer to wait. And, then given vacations/holiday schedules it may be January before its done (as we discussed on IM). This doesn't give us much time before Juno SR2, but I think it will be enough -- hopefully some kind adopters will be willing to give it a quick test in January :) [I'm assuming this goes into maintenance, as well as Kepler, as we've done for aix.ppc64.]
(In reply to comment #18) > Yes. But since maintenance builds are "in progress" today, I'd prefer to > wait. And, then given vacations/holiday schedules it may be January before > its done (as we discussed on IM). This doesn't give us much time before Juno > SR2, but I think it will be enough -- hopefully some kind adopters will be > willing to give it a quick test in January :) [I'm assuming this goes into > maintenance, as well as Kepler, as we've done for aix.ppc64.] Yes, it goes to the maintenance too.
(In reply to comment #17) > (In reply to comment #16) > > Created attachment 224892 [details] > > PPC64 native library > > > > Here is the core.filesystem native library compiled on PPC64. > > Thanks Bogdan. I added a new fragment for linux.ppc64, updated > platform.resources repo ... When you "added/updated the platform.resources repo" you also added a new .project file, at the "root" of the repo. This had the effect, for me, using EGit, when I said to "import existing projects" (from git explorer view) I expected to get the one new fragment project added to my workspace, but instead I got a whole new "eclipse.platform.resources" _project_, with a "bundles" directory and "tests" directory. Normally .project files should not exist at the root a repository. (If a person wanted the whole thing in work space with bundles and tests directories, they'd select the option "import as general project" ... and, yes, Eclipse tries to be helpful and creates a new .project file there ... but, in my experience, these should not normally be checked in. So, first question is, was this intentional? If not, guess we can open a new bug to remove it. Not sure I need it removed to make project in updating the maps and feature.xml files. Was just unexpected and took me a while to figure out what was going on.
Also, looks like the linux.ppc64 fragment was not added to the R3_8_maintenance branch. Even if exactly the same, it needs to be in both branches since this is one of the repositories that's "auto-tagged". (i.e. examined for changes, which then updates maps). I'll bet you were told ... "its easy ... just add a fragment" :)
(In reply to comment #21) > Also, looks like the linux.ppc64 fragment was not added to the > R3_8_maintenance branch. Even if exactly the same, it needs to be in both > branches since this is one of the repositories that's "auto-tagged". (i.e. > examined for changes, which then updates maps). Done: http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=f95d109356ef1f18c857168ded2c9d70d9a4eb6b And I deleted the .project at the repository root.
(In reply to comment #22) > (In reply to comment #21) > > Also, looks like the linux.ppc64 fragment was not added to the > > R3_8_maintenance branch. Even if exactly the same, it needs to be in both > > branches since this is one of the repositories that's "auto-tagged". (i.e. > > examined for changes, which then updates maps). > > Done: > > http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/ > ?id=f95d109356ef1f18c857168ded2c9d70d9a4eb6b > > And I deleted the .project at the repository root. Thanks, John, but I think you changed the core.map. That's fine (though, I could have done that). What I meant was the fragment itself, is missing from R3_8_maintenance branch: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/tree/bundles?h=R3_8_maintenance And a "resource committer" needs to do that. Don't think I have the authority. = = = Another issue: I see we are not including the fragment for 32 bit ppc. Is that on purpose? Or a long term overlooked error? = = = = Thanks,
And, sigh, the "old" platform feature we use for R3_8_maintenance eclipse.platform.releng/oldfeatures/org.eclipse.platform-feature for some reason won't "import" into my workspace. I can see it in my .git directory ... and it does have a .project file. Mysterious.
(In reply to comment #24) > And, sigh, the "old" platform feature we use for R3_8_maintenance > > eclipse.platform.releng/oldfeatures/org.eclipse.platform-feature > > for some reason won't "import" into my workspace. > I can see it in my .git directory ... and it does have a .project file. > > Mysterious. nm. It was there, just "closed" (for some reason) and I had closed projects filtered out of view. I'll get the hang of this eventually :/
Ok, I think I've made all the required "releng" changes. I removed the "sparcv9" fragment from all 3 streams (core.map and platform feature). And, I've added linux.ppc64 to all three streams (core.map and platform feature). Remaining work, make sure the fragment itself is in R3_8_maintenance. We have until Wednesday's M-builds! The N-builds and Tuesday's I-build while be covered by what is in master. Remaining question, just to be explicit, I'm assuming we do not need to include linux.ppc fragment. As far as I can tell, from history, we have not done so in the past ... just seemed odd ... so thought best to be explicit about it. If needed, easy to add from releng point of view, assuming the existing one is valid ... but, of course, someone would have to test it, etc., to confirm and none of us on core team work with linux PPC systems, as far as I know.
(In reply to comment #26) > > Remaining question, just to be explicit, I'm assuming we do not need to > include linux.ppc fragment. To answer my own question, the answer is "no", we don't need it. Checking the N build, I see we do NOT build a linux 32 bit PPC platform any longer, only 64. The linux.ppc64 fragment was in the right platform download, and was in the delta-pack, so think we are good to go ... except for committing the fragment itself to R3_8_maintenance by Wednesday's M-builds (or, those builds will fail). Thanks all.
I cherry-picked 9709a20bb803a0afcf67c8a44d85400ee0521355 into the R3_8_maintenance branch: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?h=R3_8_maintenance&id=8e0ac61bbee733e05c4037026fd9b2f1c87b3648
I think we're done here.
I verified the linux.ppc64 fragment exists in this week's M-builds and delta pack. I don't mark as "verified" (yet) since would appreciate the adopters who plan to use these to test them out and confirm the fragments actually _work_ (as expected). At that point they can mark as verified. Thanks for everyone's help getting this done.
I can't find a backport bug for 3.8.x stream. So I think we should change the target of this bug to 3.8.2.
This was also back-ported to 3.6.2+ stream: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?h=R3_6_maintenance&id=8e3c434b5c915fd68730eea303d74677a5f11d8f http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?h=R3_6_maintenance&id=57ce84b8e782adedf0033c7a0922cba4183d2032 http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?h=R3_6_maintenance&id=6022aa23796241788ea97a3641816b7e838e71d0
*** Bug 350860 has been marked as a duplicate of this bug. ***
