[linuxtools-dev] Inactive Commiter
Hello all, I have not been active on the project for a while; so to help prune inactive commiters I think that my commitership can be decommissioned. It has been a pleasure working with you all. Thanks, Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Systemtap 2.0 RC3 - An internal error occurred during: Fetch Systemtap Probe Documentation.
ah, yeah, I suspected that but forgot to ask. Thanks once again Sami! np :). Thanks for reporting the issue. The fix is in stable-2.0 and should be in RC4. ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Systemtap 2.0 RC3 - An internal error occurred during: Fetch Systemtap Probe Documentation.
java.lang.Error: Unresolved compilation problem: The method getStrippedTextPage() is undefined for the type ManPage It looks like you have an older version of o.e.l.man.core. I forgot to add a minimum version requirement. This should fix the problem https://git.eclipse.org/r/#/c/13693/ ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] make sure systemtap is installed pop-up
After Eclipse restarts I get a pop-up stating Make sure systemtap is installed I have not found any entries in bugzilla, are there any plans to remove this ? Yes. I'll fix this. ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] make sure systemtap is installed pop-up
I have not found any entries in bugzilla, are there any plans to remove this ? Yes. I'll fix this. I filed a bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=409505 ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Use of Java 6 classes break compile
Furthermore, the JDT preference set in the plugin's .settings/org.eclipse.jdt.core.prefs file is: org.eclipse.jdt.core.compiler.source=1.5 which explains why my system uses Java 5 to compile that plugin although I have Java 6 installed. How come my eclipse does not report these errors. What settings should I use to make sure I see errors like these. Should the isEmpty() be removed, or do you want to move the plugin to Java 6? I can open a bug if you'd like I don't see any reason not to move to 1.6 ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
[linuxtools-dev] Removing org.eclipse.linuxtools.systemtap.backup*
Hi, I have proposed a patch to delete org.eclipse.linuxtools.systemtap.backup-feature and org.eclipse.linuxtools.systemtap.backup.ui.editor: https://git.eclipse.org/r/#/c/8903/ I can't see any usage of these classes within linux tools. Does anyone know why they were created or if they are still needed ? Thanks, Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Gerrit reviews,
Please try to not submit for review patch series - gerrit doesn't handle them gracefully and it makes it really hard to review stuff. The problem is Gerrit makes it more difficult for the submitter to separate the patches than for the reviewer to review them in a series; for a bunch of patches to be submitted independently each one has to be done in an independent branch. For the reviewer the patch is marked with a depends on and a link to the parent patch. If needed the reviewer can review only the oldest patch until it is approved and committed then do the next. Or mark a patch as approved but not merge it and the submitter can go through an submit the patches after the series is approved. At least please don't make it for patches that can be easily separated like the recent systemtap series. That is true. For completely independent patches a branch should be created for each one. Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Gerrit reviews,
On 11/28/2012 04:43 AM, Aleksandar Kurtakov wrote: And please don't mix formatting changes with code changes as it becomes really hard to review what actually was changed. The only reason I did that was to avoid having more patches and creating a bigger series :). I actually believe that each patch should contain only one logical or formatting change. Gerrit highlights non white-space changes in darker red and darker green. This should catch most formatting changes and allow you to focus on actual code changes. Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Hudson integration with Gerrit
Hi Anna,
Can I take a look at the verification job config?
The trigger didn't work for awhile:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=384827
We got most of our settings from here:
http://wiki.eclipse.org/Gerrit#Verifying_Changes_on_Hudson_using_Gerrit_Trigger_Plugin
and http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Trigger
We have not had any problems with the trigger. The main problem was
getting Hudson to build the right commit on the right branch for which
we used the following execute shell build step before running maven:
#!/bin/sh -x
git fetch
git://git.eclipse.org/gitroot/linuxtools/org.eclipse.linuxtools
$GERRIT_REFSPEC
git checkout FETCH_HEAD
CODE=$?
if [ ${CODE} -ne 0 ]; then
git reset --hard
exit ${CODE}
fi
You should be able to view the configuration if you login:
https://hudson.eclipse.org/sandbox/job/linuxtools/
Hope this helps.
Sami
___
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Remote support for RPM plugin
I've only tested the patch using RemoteTools (that makes use of PTP - http://www.eclipse.org/ptp/). I see. What do I need to do to try it out then ? Install PTP ? I the process of creating the remote project similar to what I did in the screencast ? Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] API for 1.0
If you don't want to sign for something being an API please move it to org.eclipse.linuxtools.internal.subproject packages. I have done this for o.e.l.rpm*. I'll start pushing the patches one at a time shortly. ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
[linuxtools-dev] +1 for Krzysztof Daniel on technology.linux-distros by Sami Wagiaalla
Sami Wagiaalla voted: +1 +1 Voting summary: http://portal.eclipse.org/ ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Proposal: Update to Git branching policy
Thanks for proposing this, Severin. In general I like it. My only
concern is the difference between features and tags for releases. Will
people be confused by released/{stable-,}0.9 being the maintenance
branch for 0.9 micro releases?
[...]
Having said that, keeping stable-x branches and tags as they are now
and allowing feature branches of the form
features/component/my-cool-feature is fine as well.
I like the idea of keeping the stable stuff as is. People already
understand this model and there will be no confusion or explanation
needed. The rest of it could be kept under feature/ or experimental/
maybe with the name of the creator prefixed so you know whom to ask for
more info. So experimental/sami-my-cool-feature.
One thing to keep in mind is that the more complicated the final scheme
is the less encouraged people will be to create experimental branches.
Sami
___
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
[linuxtools-dev] Eclipse 3.7.1 built
The branch eclipse37 of eclipse build should now be able to fetch sources for and build eclipse 3.7.1. The sources can be downloaded here: http://www.eclipse.org/downloads/download.php?file=/technology/linuxtools/eclipse-build/3.7.x_Indigo/eclipse-3.7.1-src.tar.bz2 As usual: export JAVA_HOME ant Enjoy :) ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
[linuxtools-dev] +1 for Otavio Pontes on technology.linux-distros by Sami Wagiaalla
Sami Wagiaalla voted: +1 Great to have you Otavio. Voting summary: http://portal.eclipse.org/ ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Eclipse Build: Designating a stable branch eclipse37
On 10/06/2011 11:30 AM, Alexander Kurtakov wrote: On 18:23:55 Thursday 06 October 2011 sami wagiaalla wrote: On 10/05/2011 09:49 AM, akurtakov wrote: Shouldn't we build later milestone? Yup, I'll tackle M2 soon. This work will be reused for 3.7.1, at least the git fetch part. Sounds good. We can use the eclipse37 branch for that and cherry pick everything that is needed over. If all or most of the commits are need we can create an eclipse371 branch from master HEAD. The problem is that 3.7.1 is not tagged properly as can be read on platform releng list. Even Kim is waiting for component leads to tag it themself. I hoped that M2 is in better shape and use it for 3.7.1 once it's tagged. I don't know if this is helpful to you but I was able to fetch and build a recent tag: I20111005-0925 (M2 is now too old) http://download.eclipse.org/eclipse/downloads/drops/I20111011-0800/index.php I have not published the tarball or the build results but I can do so if that helps you. ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Eclipse Build: Designating a stable branch eclipse37
On 10/05/2011 09:49 AM, akurtakov wrote: Shouldn't we build later milestone? Yup, I'll tackle M2 soon. This work will be reused for 3.7.1, at least the git fetch part. Sounds good. We can use the eclipse37 branch for that and cherry pick everything that is needed over. If all or most of the commits are need we can create an eclipse371 branch from master HEAD. ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] [eclipse-build] Port to new arch with Bundle failed to resolve
You can find more information about how eclipse build works here:
http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build/Inner_Workings
That might help you debug the issue.
It will also be helpful to people on this list if you post your build
log somewhere online. It should be called build_Some time stamp.log
I also recommend that you try to build eclipse 3.7. The source tarball
can be found here:
http://download.eclipse.org/technology/linuxtools/eclipse-build/.
Sami
On 08/30/2011 12:02 AM, Xingxing Pan wrote:
Hi.
I'm building eclipse 3.6.2 on arch unicore32. At the build stage, I get
the following error:
/home/pxx/eclipse-build-master-unicore-0.0.2/bootstrap/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/genericTargets.xml:107:
Processing inclusion from feature org.eclipse.equinox.executable: Bundle
org.eclipse.equinox.launcher.gtk.linux.unicore32_1.0.200.201108301010
failed to resolve.:
[java] Host plug-in org.eclipse.equinox.launcher_[1.0.0,1.1.0) has
not been found.
But the directory org.eclipse.equinox.launcher.gtk.linux.unicore32 do
exist in build/eclipse-3.6.2-src/plugins.
The eclipse.buildConfig confused me and I googled no helpful info. Could
someone tell me what's going on?
Thank you.
build.properties:
#baseLocation=${basedir}/bootstrap
# Note: this is also in pdebuild.properties
buildId=M20110210-1200
buildTag=vI20100603-1500
label=3.6.2
testsBuildLabel=3.6.2
testframework=org.eclipse.test_3.3.0
p2.director.version=${testsBuildLabel}
testsBuildId=v20100211
featureToBuild=eclipse-build-feature
skipBase=true
skipFetch=true
individualSourceBundles=true
ws=gtk
os=linux
includeLaunchers=true
runPackager=true
groupConfigurations=true
p2.gathering=true
generate.p2.metadata=true
p2.generate.metadata=true
p2.metadata.repo = file:${repo}
p2.artifact.repo = file:${repo}
p2.flavor = tooling
p2.publish.artifacts=true
generateAPIDescription=false
collectingFolder=eclipse
archivePrefix=eclipse
generateFeatureVersionSuffix=true
bootclasspath=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
build.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
JavaSE-1.6=${bootclasspath}
CDC-1.0/Foundation-1.0=${bootclasspath}
CDC-1.1/Foundation-1.1=${bootclasspath}
OSGi/Minimum-1.0=${bootclasspath}
OSGi/Minimum-1.1=${bootclasspath}
OSGi/Minimum-1.2=${bootclasspath}
JRE-1.1=${bootclasspath}
J2SE-1.2=${bootclasspath}
J2SE-1.3=${bootclasspath}
J2SE-1.4=${bootclasspath}
J2SE-1.5=${bootclasspath}
JavaSE-1.6=${bootclasspath}
PersonalJava-1.1=${bootclasspath}
PersonalJava-1.2=${bootclasspath}
CDC-1.0/PersonalBasis-1.0=${bootclasspath}
CDC-1.0/PersonalJava-1.0=${bootclasspath}
CDC-1.1/PersonalBasis-1.1=${bootclasspath}
CDC-1.1/PersonalJava-1.1=${bootclasspath}
# Somehow bootclasspath isn't expanded when used by antRunner
JavaSE-1.6=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
CDC-1.0/Foundation-1.0=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
CDC-1.1/Foundation-1.1=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
OSGi/Minimum-1.0=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
OSGi/Minimum-1.1=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
OSGi/Minimum-1.2=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
JRE-1.1=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
J2SE-1.2=/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/jre/lib/jce.jar:/usr/lib/jvm/default-java/jre/lib/rt.jar:/usr/lib/jvm/default-java/jre/lib/jce.jar:/usr/lib64/jvm/java/jre/lib/rt.jar:/usr/lib64/jvm/java/jre/lib/jce.jar
[linuxtools-dev] Getting Rid of Changelogs
I have been thinking about this for a while, but was prompted by Andrew's email [1] to send a message to the list. Changelogs are pain to deal with, they don't automerge, and the authorship information is redundant. On the other hand I find them useful in two ways: they force me to go over my patch one more time, and they provide a structure for creating a good commit message (I copy and paste my Changelog entry in the commit message). So my suggestion is we get rid of Changelogs, follow the format outlined on the wiki [2] and referenced by Andrew's message [1], and perhaps add a requirement to have a bullet for each modified file. WDYT ? Sami [1] http://wiki.eclipse.org/Linux_Tools_Project/Git#Commit_messages [2] http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg01203.html ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Issue with eclipse-build-generatedScripts.tar.bz2
On 08/05/2011 11:19 AM, Niels Thykier wrote: Hi I tried building eclipse from the head of the eclipse-build master branch, but unfortunately it does not work on Debian systems because eclipse-build-generatedScripts.tar.bz2 contains paths only working on Fedora based systems. I am not entirely sure what causes it, but I suspect the generator might be following symlinks the symlinks we inject in the build directory. On a related note, I could not make regenerateBootstrapFiles.sh work (kept saying it could not find org.eclipse.osgi); I managed to manually fix up a eclipse-build-generatedScripts.tar.bz2 that works, but I have not committed it because my copy is now Debian-specific rather than Fedora-specific Can you post the patches somewhere public ? I don't know if the scripts in eclipse-build-generatedScripts.tar.bz2 are meant to be edited, but your patches might give some hints as to how things can be fixed. Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Problems with HEAD of eclipse-build
On 08/02/2011 10:46 AM, Niels Thykier wrote: Hi A recent commit [1] is causing me issues. My bad. That is my commit. First of; it breaks if built twice in a row (e.g build, clean, build) and secondly the links assumes that we are in a git checkout/clone. Yeah I was going to fix that by checking for the links. For the eclipse-build tarball, this would not work very well (there will be a directory where the links are to be created). I see. Personally I believe a better solution would be to move the parts into the eclipse-build directory in git so the link creation would not be needed. Would that be an acceptable compromise? I don't see why we cannot do this. Anyone ? If there is a reason why we cannot do this then checking for the links should solve the problem shouldn't it ? ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Problems with HEAD of eclipse-build
I don't see why we cannot do this. Anyone ? I don't think you can have multiple .project files in one directory and have them show up as separate Eclipse projects which they are and I believe need to be. I see. So we can check and if the directories or links are present we don't recreate them. That solves the problem for the tarball and the failure of the repeated build. Niels, how does that sound ? Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
Re: [linuxtools-dev] Problems with HEAD of eclipse-build
On 08/02/2011 11:16 AM, sami wagiaalla wrote: I don't see why we cannot do this. Anyone ? I don't think you can have multiple .project files in one directory and have them show up as separate Eclipse projects which they are and I believe need to be. I see. So we can check and if the directories or links are present we don't recreate them. That solves the problem for the tarball and the failure of the repeated build. Niels, how does that sound ? I have pushed he following fix: http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.eclipse-build.git/commit/?id=71bfe0f5ee55468d50ce1ede4b51bf7a2d40059f ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
[linuxtools-dev] Libhover support for libraries with GObject Introspection
Hi David, You have asked for adding libhover support for libraries with GObject Introspection enabled (http://overholt.ca/wp/?p=223cpage=1#comment-409707). I read through the link provided and here is what I understood: GObject introspection provides another mechanism for extracting documentation from introspection enabled libraries and that the extracted information is used to generate devhelp files. If that is the case then this is already supported since libhover supports devhelp already. Thanks, Sami ___ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
