Spec URL: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec SRPM URL: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.0-0.1.200910091648.fc12.src.rpm Description: The aim of the parallel tools platform project is to produce an open-source industry-strength platform that provides a highly integrated environment specifically designed for parallel application development. The project will provide: - a standard, portable parallel IDE that supports a wide range of parallel architectures and runtime systems - a scalable parallel debugger - support for the integration of a wide range of parallel tools - an environment that simplifies the end-user interaction with parallel systems Koji build (devel/F13): http://koji.fedoraproject.org/koji/taskinfo?taskID=1748225
I'm not sure I would bother with the gcj AOT bits, I don't think that any other part of eclipse is currently built that way.
Good point. * Fri Oct 16 2009 Orion Poplawski <orion.com> - 3.0.0-0.2.200910091648 - Remove gcj - eclipse is not built with it. Spec URL: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec SRPM URL: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.0-0.2.200910091648.fc12.src.rpm
* Thu Oct 22 2009 Orion Poplawski <orion.com> - 3.0.0-0.3.200910162113 - Update to 200910162113 Spec URL: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec SRPM URL: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.0-0.3.200910162113.fc12.src.rpm
* Tue Oct 27 2009 Orion Poplawski <orion.com> - 3.0.0-0.4.200910232110 - Update to 200910232110 http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.0-0.4.200910232110.fc12.src.rpm
I'm taking this one.
Rpmlint is really angry on this package: 1 packages and 0 specfiles checked; 66 errors, 149 warnings Most of the problems are W: devel-file-in-non-devel-package which I doubt are really useful but I may be wrong. There are also sources for libaif and maybe other libraries included in the binary rpm. One more problem I see is that fragments for other OSs (aix, macosx) and archs different(ppc, x86_64) than the build one (x86) get installed. Let me know if you think some of these are needed and if yes why?
May need to wait until we are really composing F-13 as rawhide to get farther, but: - Looks like this isn't a noarch package. - Latest from upstream seems to be needing cdt 6.0.2 which isn't released yet too. - Looks like it may only be libaif, which I don't see released anywhere else, in which case I would think it would be permissible to package in here. Have to see how it is used too. Thanks, will post back when things have settled a little.
* Thu Jan 21 2010 Orion Poplawski <orion.com> - 3.0.1-0.1.v201001152110 - Update to 3.0.1 snapshot - Split package - Make noarch http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.1-0.1.v201001152110.fc12.src.rpm - The primary development location for libaif is here in ptp. - The devel-file/non-exec I would ignore. Some PTP packages ship the sources for code that is then compiled on the end user's machine. - The other OS/archs stuff consists of a small shell script used to build the shipped sources on the installed machine. I could patch them out but it doesn't seem worth it. Still need to handle replacing the existing photran packages (they now have a lower version number).
http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.1-0.2.v201001152110.fc12.src.rpm http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec * Thu Jan 21 2010 Orion Poplawski <orion.com> - 3.0.1-0.2.v201001152110 - Make photran versions 5.0.1, rephraserengine 1.0.1 So that should take care of the version issues.
http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.1-1.fc13.src.rpm http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec * Fri May 28 2010 Orion Poplawski <orion.com> - 3.0.2-1 - Update to 3.0.1 final - Rework dependencies Alexander - do you still have time for this?
Sorry Orion, I wouldn't have time for it until maven is ready. I'm leaving the bug for someone with more time.
* Tue Jun 1 2010 Orion Poplawski <orion.com> - 3.0.2-0.1.v201004302110 - Update snapshot - Add patch from cvs to fix exception in MPI project wizard http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-3.0.2-0.1.v201004302110.fc13.src.rpm http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec
I'm not going to be able to get to this until Eclipse Helios is released upstream. At first glance, though, things look good. rpmlint is quite unhappy with a lot of stuff, though.
rpmlint by category: eclipse-ptp-debug-sdm.noarch: W: devel-file-in-non-devel-package /usr/share/eclipse/dropins/org.eclipse.ptp.debug.sdm/plugins/org.eclipse.ptp.debug.sdm_3.0.2.201006011254/include/dbg_event.h A couple of the component contain source code that is compiled on target machines (that my not be the machine where PTP is installed). eclipse-ptp-debug-sdm.noarch: E: non-executable-script /usr/share/eclipse/dropins/org.eclipse.ptp.debug.sdm/plugins/org.eclipse.ptp.debug.sdm_3.0.2.201006011254/libaif/missing 0644L /bin/sh Essentially same as above. I'm a bit puzzled as to why they don't have execute permissions, but that is how they are installed. eclipse-ptp-debug-sdm.noarch: E: zero-length /usr/share/eclipse/dropins/org.eclipse.ptp.debug.sdm/plugins/org.eclipse.ptp.debug.sdm_3.0.2.201006011254/libaif/ChangeLog Again related, upstream must have some boilerplate templates. Really don't cause a problem. eclipse-ptp-isp.noarch: W: spelling-error %description -l en_US interleavings -> interleaving, inter leavings, inter-leavings with the possible exception of the above, these are all fine. And I really don't have a problem with this one.
Sorry it's taken me so long to get back to this, Orion. Things actually look pretty good and I'm very impressed with the cleanliness of the .spec for this monster package! I'm building on top of the rawhide packages (Helios stuff) and get this build error in the org.eclipse.ptp.pldt.openmp.analysis plugin: 87. ERROR in /home/overholt/rpmbuild/BUILD/org.eclipse.ptp-v201004302110/tools/org.eclipse.ptp.pldt.openmp.analysis/src/org/eclipse/ptp/pldt/openmp/analysis/PAST/PASTPragma.java (at line 22) public class PASTPragma extends PASTNode implements IASTPreprocessorPragmaStatement ^^^^^^^^^^ The type PASTPragma must implement the inherited abstract method IASTPreprocessorPragmaStatement.isPragmaOperator() Have you seen this before? My only comment on the .spec is that the %descriptions are kind of long. I presume you just generated these from the feature files? I agree with the rpmlint reasons you give above (although I haven't re-examined its output since it doesn't build for me ATM). I'll go through the rest of the packaging guidelines but things seem alright. You can probably bump the release to 1 since this version of PTP was presumably released with Helios in June. Again, apologies for taking so long to get back to this.
Okay, if we are working with Helios, we should bump to PTP 4.0.X. I've put a preliminary src.rpm and spec here: http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-4.0.2-1.fc13.src.rpm http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec The problem now is that my previous method for determining what features to build and in what order no longer works. The "master" feature.xml only lists a few items. Any ideas on how to pursue this? I suppose there must be some build tool that goes out and analyzes the dependencies to produce the proper build order.
I presume PTP is building from one master feature ... maybe you don't have the correct one? I'm downloading one of their builds now and I'll see if I can figure it out. I wrote the following before comment #16. I've gone through the packaging guidelines and things look pretty good to me. - licensing fine - Build/Requires okay - files section good - dependencies correct - %clean present - macros clean - versioning and sub-package dependencies looks okay - taking over providing of eclipse-photran looks correct - no locale files - no rpath - no .desktop file - no users/groups - not a web app. - all code built, none bundled - code, not content - no scriptlets - file locations correct - builds (except that one plugin) on x86_64 (for noarch) - can't test installation ATM - can't run rpmlint ATM
I think this is the master feature you want: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ptp/releng/org.eclipse.ptp.master/feature.xml?view=markup&revision=1.47&root=Tools_Project&sortby=rev This releng "plugin" is also of interest as it looks like it contains the maps they use and the shell scripts they use. I think Mat Booth created a shell script that reads .map files to do CVS exports. Look in eclipse-emf to see if I'm right. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ptp/releng/org.eclipse.ptp.releng/?root=Tools_Project&sortby=rev
(In reply to comment #18) > I think this is the master feature you want: > > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ptp/releng/org.eclipse.ptp.master/feature.xml?view=markup&revision=1.47&root=Tools_Project&sortby=rev Yeah, that's what I used before, but now it doesn't contain all of the features and if I build in the order listed the org.eclipse.ptp.core feature fails because it is missing org.eclipse.ptp.utils stuff. Looks like at revision 1.45 they "removed duplicate features". > This releng "plugin" is also of interest as it looks like it contains the maps > they use and the shell scripts they use. I think Mat Booth created a shell > script that reads .map files to do CVS exports. Look in eclipse-emf to see if > I'm right. > > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ptp/releng/org.eclipse.ptp.releng/?root=Tools_Project&sortby=rev I'll take a look.
(In reply to comment #19) > (In reply to comment #18) > > I think this is the master feature you want: > > > > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ptp/releng/org.eclipse.ptp.master/feature.xml?view=markup&revision=1.47&root=Tools_Project&sortby=rev > > Yeah, that's what I used before, but now it doesn't contain all of the features > and if I build in the order listed the org.eclipse.ptp.core feature fails > because it is missing org.eclipse.ptp.utils stuff. Looks like at revision 1.45 > they "removed duplicate features". Weird. I briefly looked at the list of features in their master zip and what's included in the cascaded list of that master feature and I thought they were all covered. Maybe something with flattendependencies in build.properties?
Yeah, I imagine the build system in use is able to handle it. I could build the master feature but then I end up with a single zip/package. Perhaps I could unpack it in the proper way? Build the master then find out what's in it and "build" those (which should be somewhat fast if the class/jars are still around)?
I'm pretty sure PTP uses PDE Build like we do. You probably could do re-packaging like you're suggesting. Or you could manually move the files to the sub-package locations :)
In releng/org.eclipse.ptp.releng/build.sh they build with: cd tools cvs -d:pserver:anonymous.org:/cvsroot/eclipse \ checkout -r v20100423 org.eclipse.releng.basebuilder cd .. # Let's go! java -jar tools/org.eclipse.releng.basebuilder/plugins/org.eclipse.equinox.launcher.jar \ -ws gtk -arch ppc -os linux -application org.eclipse.ant.core.antRunner $* Args are "" From http://wiki.eclipse.org/Platform-releng-faq it appears that it is able to determine build order.
What does their build.xml look like? PDE Build should indeed be able to determine build order without a problem.
Created attachment 442053 [details] releng/org.eclipse.ptp.releng/build.xml We'll here is the main build.xml file (I think). It appears that I may be able to build the feature list from that with: features=$(grep 'tagmodule.*-feature' releng/org.eclipse.ptp.releng/build.xml | sed -e 's/^.* value="//' -e 's/-feature".*$//') But the build order still isn't correct.
They're building their master feature. See this line in build.xml: <ant antfile="build.xml" dir="${pde.build.scripts}"> <property name="builder" value="${basedir}/master" /> </ant> If you can't get pdebuild.sh to work, you could always run this directly with something like: eclipse -nosplash -application org.eclipse.ant.core.antRunner \ -Dbuilder=$(pwd)/master \ -f %{_libdir}/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_*/scripts/build.xml
+ eclipse -nosplash -application org.eclipse.ant.core.antRunner -Dbuilder=/scratch/orion/redhat/eclipse-ptp-4.0.2/org.eclipse.ptp-ptp_4_0/releng/org.eclipse.ptp.releng/master -f /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/build.xml CompilerOracle: exclude org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith CompilerOracle: exclude org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init> CompilerOracle: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate CompilerOracle: exclude org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding CompilerOracle: exclude org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile CompilerOracle: exclude org/python/pydev/ui/filetypes/FileTypesPreferencesPage.getDottedValidSourceFiles Buildfile: /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/build.xml main: preBuild: BUILD FAILED /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/build.xml:32: The following error occurred while executing this line: /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/build.xml:47: Directory /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/build creation was not successful for an unknown reason No idea how to get more info.
-debug -consolelog It looks like it's trying to create the build directory in the PDE Build scripts directory. Passing something like -data with a location in which to work would probably help. Note that what I said 2 comments ago wasn't intended to be a proper solution but rather a pointer to what _may_ work :)
Yeah, but pdebuild has been failing due to dependency ordering. Gotten farther with the latest, but now it wants to checkout the project with cvs. Going to take a patched build script I think. Execute:Java13CommandLauncher: Executing 'cvs' with arguments: '-d:pserver:anonymous.org:/cvsroot/tools' '-q' 'export' '-r' 'ptp_4_0' 'org.eclipse.ptp/releng/org.eclipse.ptp.master/feature.xml' The ' characters around the executable and arguments are not part of the command. [null] Exiting /scratch/orion/redhat/eclipse-ptp-4.0.2/org.eclipse.ptp-ptp_4_0/results/retrieve.xml. [ant] Exiting /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/genericTargets.xml. [ant] Exiting /scratch/orion/redhat/eclipse-ptp-4.0.2/org.eclipse.ptp-ptp_4_0/releng/org.eclipse.ptp.releng/master/customTargets.xml. [antcall] Exiting /usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/build.xml. Going back to pdebuild - I wonder if there is some issue with not being able to pick up features that have already been built. In the following build, I build ptp.utils, ptp.services, ptp.remote, then ptp. In the ptp build I get an error that it can't find ptp.utils: [javac] 1. ERROR in /var/tmp/orion/redhat/eclipse-ptp-4.0.2/org.eclipse.ptp-ptp_4_0/core/org.eclipse.ptp.proxy.protocol/src/org/eclipse/ptp/proxy/runtime/server/ElementIDGenerator.java (at line 16) [javac] import org.eclipse.ptp.utils.core.RangeSet; [javac] ^^^^^^^^^^^^^^^^^^^^^ [javac] The import org.eclipse.ptp.utils cannot be resolved Or perhaps ptp.proxy.protocol isn't correctly specifying that it requires ptp.utils? http://koji.fedoraproject.org/koji/taskinfo?taskID=2438000
Looking through the logs some more I see some clean statements that are cleaning up utils and other stuff: all.features: all.plugins: properties: init: clean: [delete] Deleting directory /builddir/build/BUILD/org.eclipse.ptp-ptp_4_0/core/org.eclipse.ptp.utils.core/@dot [delete] Deleting: /builddir/build/BUILD/org.eclipse.ptp-ptp_4_0/core/org.eclipse.ptp.utils.core/utils_core.jar [delete] Deleting directory /builddir/build/BUILD/org.eclipse.ptp-ptp_4_0/core/org.eclipse.ptp.utils.core/temp.folder Perhaps that is the issue?
Sorry, I don't know about the clean stuff. I think Mylyn (eclipse-mylyn) may do something similar to what you want to do with building multiple inter-dependent features. The CDT's .spec (eclipse-cdt) also builds multiple inter-dependent features by jamming the output of one into the other.
Okay, so the magic needed seems to be "-Dnoclean=true". This allows me to build features that are needed by other features earlier. So, the next question is how many binary packages should this really be broken up into?
FYI - the "org.eclipse.ptp" feature contains: eclipse/features/org.eclipse.ptp.core_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.debug.sdm_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.etfw_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.external_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.pldt_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.remote_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.remote.remotetools_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.remotetools_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.rm.ibm.ll_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.rm.ibm.pe_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.rm.mpich2_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.rm.openmpi_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.rm.pbs_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.rm.slurm_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.services_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.utils_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp.pldt.lapi_4.0.3.201009011159/feature.xml eclipse/features/org.eclipse.ptp_4.0.3.201009011159/feature.xml And org.eclipse.ptp.core consists other things as well. Lots of layers it seems.
I'm glad you got past the clean stuff. We generally recommend to break things up along feature lines. However, if you don't think Fedora users would ever install some of the smaller features, I think it's fine to break it up along larger feature lines.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2443163 http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-4.0.2-1.fc13.src.rpm http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec * Wed Sep 1 2010 Orion Poplawski <orion.com> - 4.0.3-0.1.v201009010938 - Update snapshot - Re-work build I put all of the core ptp components into the main ptp package. There is a ptp-master package that will pull in all of the other packages.
It looks like there are a few inter-dependency errors: Error: Package: eclipse-ptp-etfw-tau-fortran-4.0.3-0.1.RC2b.fc15.noarch (/eclipse-ptp-etfw-tau-fortran-4.0.3-0.1.RC2b.fc15.noarch) Requires: eclipse-photran = 6.0.2-0.1.RC2b.fc15 Available: eclipse-photran-5.0.0-0.4.200910081739.fc13.noarch (fedora) Error: Package: eclipse-ptp-remote-rse-4.0.3-0.1.RC2b.fc15.noarch (/eclipse-ptp-remote-rse-4.0.3-0.1.RC2b.fc15.noarch) Requires: eclipse-ptp-remote = 4.0.3-0.1.RC2b.fc15 The former can be avoided with a bunch of disablerepo flags to yum localinstall but the latter looks to be a problem.
http://www.cora.nwra.com/~orion/fedora/eclipse-ptp-4.0.3-0.2.RC2b.fc13.src.rpm http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec * Thu Sep 2 2010 Orion Poplawski <orion.com> - 4.0.3-0.2.v201009010938 - Fix remote-rse deps http://koji.fedoraproject.org/koji/taskinfo?taskID=2443893 This should fix the second one. As for the first, why aren't you getting eclipse-photran-6.0.2-0.1.RC2b.fc15 from the build as well?
(In reply to comment #37) > http://koji.fedoraproject.org/koji/taskinfo?taskID=2443893 I got these RPMs and it installs fine. The upgrade from the existing eclipse-photran packages works, too. You've shown that it builds in koji which is great. I'm satisfied that build and install items in the review checklist are good to go. rpmlint still complains about a bunch of stuff (see attachment for full details): eclipse-photran.noarch: I: enchant-dictionary-not-found en_US No idea what's up here. eclipse-ptp.noarch: W: incoherent-version-in-changelog 4.0.3-0.2.v201009010938 ['4.0.3-0.2.RC2b.fc15', '4.0.3-0.2.RC2b'] Please fix this. As for the other rpmlint errors and warnings, I'm fine with the zero-length files if they're stubs but would like to see upstream queried as to why they're shipping them. The .c/.h files as you said are compiled on target machines so they're fine to ship as is. I wonder if upstream doesn't know about p2 touchpoints to do chmod operations ... either way, I don't see a big deal with the configure and various .sh scripts not having the execute bit set. eclipse-ptp.src: W: strange-permission finddeps.sh 0755L eclipse-ptp.src: W: strange-permission makesource.sh 0755L These are fine in my book since you use them to generate stuff for the build. eclipse-ptp.src: W: invalid-url Source0: org.eclipse.ptp-ptp_4_0.tar.gz I don't know what's wrong with this.
I will be on vacation for a bit starting today so I wanted to get the list of remaining todo items listed: - fix changelog versioning to satisfy rpmlint - see if you can get rpmlint to be okay with the supposed dictionary and source0 URL issues - contact upstream about the permissions of their .sh files If those are taken care of, this package will be approved.
(In reply to comment #38) > eclipse-photran.noarch: I: enchant-dictionary-not-found en_US > > No idea what's up here. You need to install hunspell-en and/or aspell-en I think. > eclipse-ptp.noarch: W: incoherent-version-in-changelog 4.0.3-0.2.v201009010938 > ['4.0.3-0.2.RC2b.fc15', '4.0.3-0.2.RC2b'] > > Please fix this. Done. > As for the other rpmlint errors and warnings, I'm fine with the zero-length > files if they're stubs but would like to see upstream queried as to why they're > shipping them. The .c/.h files as you said are compiled on target machines so > they're fine to ship as is. I wonder if upstream doesn't know about p2 > touchpoints to do chmod operations ... either way, I don't see a big deal with > the configure and various .sh scripts not having the execute bit set. I'll ping upstream about this. > eclipse-ptp.src: W: strange-permission finddeps.sh 0755L > eclipse-ptp.src: W: strange-permission makesource.sh 0755L > > These are fine in my book since you use them to generate stuff for the build. > > eclipse-ptp.src: W: invalid-url Source0: org.eclipse.ptp-ptp_4_0.tar.gz > > I don't know what's wrong with this. It wants a url (e.g. http://....). We don't have one, but we document how to generate the source tarball.
(In reply to comment #40) > (In reply to comment #38) > > eclipse-photran.noarch: I: enchant-dictionary-not-found en_US > > > > No idea what's up here. > > You need to install hunspell-en and/or aspell-en I think. Correct you are :) > > eclipse-ptp.noarch: W: incoherent-version-in-changelog 4.0.3-0.2.v201009010938 > > ['4.0.3-0.2.RC2b.fc15', '4.0.3-0.2.RC2b'] > > > > Please fix this. > > Done. rpmlint can confirm that http://www.cora.nwra.com/~orion/fedora/eclipse-ptp.spec is fixed. > > As for the other rpmlint errors and warnings, I'm fine with the zero-length > > files if they're stubs but would like to see upstream queried as to why they're > > shipping them. The .c/.h files as you said are compiled on target machines so > > they're fine to ship as is. I wonder if upstream doesn't know about p2 > > touchpoints to do chmod operations ... either way, I don't see a big deal with > > the configure and various .sh scripts not having the execute bit set. > > I'll ping upstream about this. Great, thanks. > > eclipse-ptp.src: W: strange-permission finddeps.sh 0755L > > eclipse-ptp.src: W: strange-permission makesource.sh 0755L > > > > These are fine in my book since you use them to generate stuff for the build. > > > > eclipse-ptp.src: W: invalid-url Source0: org.eclipse.ptp-ptp_4_0.tar.gz > > > > I don't know what's wrong with this. > > It wants a url (e.g. http://....). We don't have one, but we document how to > generate the source tarball. Yeah, I just don't remember seeing that for other packages that have no full URLs like this. It's not a big deal. This package is approved. Thanks for the hard work, Orion! Please update https://fedoraproject.org/wiki/Features/F14EclipseHelios when it's built for F14 and rawhide.
New Package SCM Request ======================= Package Name: eclipse-ptp Short Description: Eclipse Parallel Tools Platform Owners: orion Branches: f14 f13 f12 InitialCC:
I'm sure you know this, Orion, but for F13 and F12 you'll need to build the Galileo version of PTP.
Yup. I'm hoping to whip my 3.0.X package into shape for those.
Git done (by process-git-requests).
rawhide build complete. F-14 building. Thanks everyone.
Package Change Request ====================== Package Name: eclipse-ptp New Branches: el6 Owners: orion InitialCC: