From Fedora Project Wiki

No edit summary
No edit summary
Line 1: Line 1:
=Introduction=
{{lang|en|zh-cn|page=Eclipse_Fedora_Packager_User_Guide}}


There are many ways to generate help content in Eclipse. One particular method involves generating your help content from the wiki which allows you to crowdsource your documentation. By having your documentation on the wiki, you lower the barrier of entry for people to contribute documentation. The purpose of this wiki entry is to guide you through an example of how you can crowdsource your documentation using Mylyn WikiText.
= What is Eclipse Fedora Packager? =


=What is WikiText=
Eclipse Fedora Packager is a plug-in for Eclipse. It helps Fedora packagers who are used to IDEs (such as Eclipse IDE), to package their Fedora RPMs from within Eclipse without needing to resort to the command line. (at least for the most part :-) ).


Mylyn WikiText provides an extensible framework and tools for parsing, editing and presenting lightweight markup. On top of that, it has a wiki text editor for Eclipse and Ant tasks for converting lightweight markup to HTML and other formats. In this specific example, we will be using WikiText's ability to convert Mediawiki content into Eclipse help content.
'''Some features included in the Eclipse Fedora Packager are:'''


[[Image:What-is-wikitext.png]]
* Conveniently clone Fedora Git projects
* RPM-spec-file editor with syntax highlighting, auto-completion and changelog support (<Ctrl>+<Alt>+C keyboard shortcut)
* Download source files and upload new source files
* Prepare local builds (execute %prep section of your spec-file only)
* Create source RPM files based on current spec-file
* Execute local builds
* Push builds to Koji (the Fedora build system)
* Mock builds
* Push Bodhi updates
* Eclipse Git support (via EGit, please refer to EGit documentation)


=A Simple Example=
Eclipse Fedora Packager has been available for Fedora users since F14. Want to try it out? Issue the following command to install it:


The best way to learn is by doing. As an example, we will take this wiki entry and create some Eclipse help content from it. To accomplish this, we will use Ant so you can easily integrate this into a build if you wish.
<pre>
yum install eclipse-fedorapackager
</pre>
 
= Using Eclipse Fedorapackager =
 
Since Fedora 14, the Git version control system for keeping track of files required for Fedora packaging is used. See the [https://fedoraproject.org/wiki/Dist_Git_Project dist-git documentation] for in depth information about dist-git. Fortunately, how dist-git works when using the Eclipse Fedora Packager plug-in is unimportant. There is only a slightly different approach for doing packaging work compared to what might have been used with CVS instead of Git.


==Setting up the Classpath==
== Initial Setup ==


The first order of business is to setup your Ant classpath so you can use the WikiText Ant tasks.
This step is only required to be completed once for a new Fedora packager or if using a new machine that does not have required FAS certificates set up. When it is certain this is correct it is safe to skip this step. The following explains how to set up those certificates for a [https://admin.fedoraproject.org/accounts/ FAS account]?


You can [http://www.eclipse.org/downloads/download.php?file=/tools/mylyn/update/weekly/mylyn-wikitext-standalone-latest.zip download] the WikiText SDK which contains the jars you'll need. In our case, we only need the org.eclipse.mylyn.wikitext.core_1.3.0.I20100116-0000-e3x.jar and org.eclipse.mylyn.wikitext.mediawiki.core_1.3.0.I20100116-0000-e3x.jar since we are only working with Mediawiki. If we were working with something like confluence, we would have to grab the respective JAR and put it on our classpath.
First, install the <code>fedora-packager</code> RPM package:


In the end, your Ant file will look something like the snippet below.
<pre>
yum install fedora-packager
</pre>


<pre style="width: 60em;">
Then run the following command and simply follow the instructions provided:  
<path id="wikitext.tasks.classpath">
<fileset dir="lib">
<include name="org.eclipse.mylyn.wikitext.*core*.jar"/>
</fileset>
</path>


<taskdef classpathref="wikitext.tasks.classpath"
<pre>
resource="org/eclipse/mylyn/internal/wikitext/mediawiki/core/tasks/tasks.properties"/>
$ fedora-packager-setup
<taskdef classpathref="wikitext.tasks.classpath"
resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties"/>
</pre>
</pre>


==Converting to Eclipse Help==
Once this is done Eclipse Fedorapackager is ready for use. Fire up Eclipse. Let's get started. Yay!


After we have setup the classpath for our task, we need to go and fetch the wiki content and convert it to Eclipse help. This is accomplished via the '''mediawiki-to-eclipse-help Ant''' task.
== Importing a Fedora Git Project ==


In the end, your Ant file will look something like the snippet below.
Getting started is easy. Go to "File" => "Import" => "Git" => "Projects from Fedora Git". This will clone the desired Git repository and create necessary local branches. For convenience, the "Git Repositories" view will also open once the clone process has finished.  


<pre style="width: 60em;">
[[Image:ImportFedoraGit.png|Fedora Git Import]]


<mediawiki-to-eclipse-help
Here's how the Fedora Git import dialog looks like. Next, specify the package name that will then be prepared for you.
    wikiBaseUrl="http://wiki.eclipse.org"
 
validate="true"
[[Image:SelectPackageNameGit.png|Select Package Name]]
failonvalidationerror="true"
 
prependImagePrefix="images"
Once the new project has been created something akin to the following is seen. Note the branches in the Git Repository view and "[eclipse-fedorapackager master]" right beside the project name. In this case, ''eclipse-fedorapackager'' refers to the Git repository name and ''master'' to the currently checked out branch.
formatoutput="true"
 
defaultAbsoluteLinkTarget="doc_external"
[[Image:GitProjectBranchesView.png|Git Branch View]]
    dest="${basedir}"
 
    title="Crowdsourcing Documentation"
== Fedora Packaging Work ==
    generateUnifiedToc="false">
 
    <path name="DocumentationGuidelines/Example"  
After a Fedora Git project has been created, all files required for packaging the desired release can be found in the created Eclipse project directly. For example, files for release Fedora 13 correspond to files present in the Eclipse project one switched to branch '''f13/master'''. Files in branch '''master''' correspond to '''Fedora rawhide''', the current development release of Fedora. The following is a brief description of things to consider doing while packaging up some software. Working in a different sequence works, but keep in mind that before trying a Koji build '''push your locally committed changes to the public repository'''.
                title="Crowdsourcing Documentation"
 
                generateToc="true"/>
=== Uploading Source Files Required for a Package ===
    ...
 
</pre>
In order to upload new sources in Eclipse Fedora Packager, first download upstream sources and place the downloaded sources in the same folder as the Eclipse project. If this is done outside of Eclipse, don't forget to refresh the project afterwards (F5) so that the file actually shows up. A slick way to download sources is to use RPM editor functionality directly. See its [http://wiki.eclipse.org/Linux_Tools_Project/SpecfileEditor/User_Guide documentation] for more information on this. Once the new source file is available in the project, it can be uploaded to the lookaside cache by right-clicking on the file=> "Fedora Packager" => Upload This File => Replace/Add File. This either adds the file to the sources required to build the package or replaces the current content of the <code>sources</code> file to contain a single line with the MD5 sum of the file selected.


When the Ant task is executed... the wiki content will be transformed into HTML and a respective Eclipse help TOC XML will be generated.
A valid certificate is required to upload to the lookaside cache. If it has expired, a new one can be created by issuing the following command on a terminal:


[[Image:Crowdsourcing-toc.png]]
<pre>
$ fedora-cert -n
</pre>


When you self-host and launch Eclipse Help in the self-hosted instance, you should see this content there as shown below.
=== Downloading Source Files Required for a Package ===


[[Image:Crowdsourcing-help-content.png]]
To download the required source files for an existing package in order to build it, right-click on the spec-file => "Fedora Packager" => Download Sources. This downloads all sources listed in the file <code>sources</code>.


==Source Code==
=== Using the Spec-File Editor ===


The full source code for this example is available on [http://github.com/caniszczyk/mylyn-wikitext-examples GitHub].
Eclipse Fedora Packager uses the RPM Editor and ChangeLog plug-in from the Eclipse Linux Tools project (http://www.eclipse.org/linuxtools). For instance, a new ChangeLog entry can easily be created in the spec-file by using the <CTRL>+<ALT>+C keyboard shortcut (though a good idea is to set appropriate “ChangeLog” preferences first). Using <CTRL>+<SPACE> auto-completes locally installed packages. Also, rpmlint can be run by right-clicking on the spec-file => “Run Rpmlint”. For more information have a look at the spec-file editor screencast: http://www.eclipse.org/downloads/download.php?file=/technology/linuxtools/videos/specfile-demo.ogg or at the "Specfile Editor User Guide": Help => Help Contents => Specfile Editor User Guide.


=Other Approaches=
=== Committing Changes to the Local Git Repository ===


There are two main approaches when it comes to crowdsourcing documentation: '''wiki-based''' and '''file-based'''.
After the spec-file, patches etc. have been added/changed, commit those changes to the repository. This is done by:


In this example, we focus on the wiki-based approach as it's the most collaborative approach. Anyone can contribute to documentation easily and the changes are instantly available online for people to see. The downside to this approach is that contributions are a bit less controlled which could impact quality depending on how a project structures its documentation process and depending on the wiki you choose, version history may be a bit harder to manage.  
# Selecting the files to commit (alternatively select the Fedora Git project and select desired ''unstaged'' files when the commit dialog is shown)
# Right-click, "Team" => "Commit..."


In the file-based approach, the origin of the content is only in the SCM and is transformed during build-time. The plus side to this is it's managed by your existing version control system. The two major downsides are that changes aren't immediately available to your users and that it's much harder to contribute to the documentation since you need to have commit access. There are merits to both approaches and it really depends on your needs. Thankfully, examples for both approaches can be found in the [[#Eclipse.org Reference Projects]] section.
[[Image:GitCommit.png|Git Commit]]


=Tips and Tricks=
=== Switching Branches (Git Checkout) ===


You can use <pageAppendum> to add some extra information to your documentation.  
Switching branches is as easy as double-clicking on the desired local branch to be worked on. The currently checked out branch is indicated to the left of the project name. Make sure to commit, revert, or stash changes before switching to a different branch. Refer to the [http://www.kernel.org/pub/software/scm/git/docs/ Git] and [http://wiki.eclipse.org/EGit/User_Guide EGit] documentation for more information on this.


It's common to add a blurb about how to update the documentation so users can be informed that the documentation they are reading has been generating from the wiki.
=== Prepare Sources for a Local Build ===


=Eclipse.org Reference Projects=
Eclipse Fedora Packager will download and prepare sources by right-clicking on the spec-file => “Fedora Packager” => “Prepare Sources for Build”.


If you're looking for other examples on how to crowdsource your documentation at Eclipse, the best place is to look and see what other Eclipse.org projects are doing.
[[Image:PrepareSourcesForBuild.png|Prepare Sources for Build]]


==Mylyn==
=== Build RPM for a Local Architecture ===


The Mylyn project uses two wiki pages on Eclipsepedia for its documentation: [[Mylyn/User Guide]] and [[Mylyn/FAQ]].
This is a great way to test if the spec-file actually builds at all. Once the RPM has been successfully built locally, it is recommended further testing be carried out on the spec-file by completing a build in a chroot'ed environment using <code>mock</code>. Both ways are supported by Eclipse Fedora Packager.


Each of these have their own Help table of contents, which are arranged into a common document via a top-level table of contents with links.
The RPM can be built locally by selecting the spec-file => right-click => “Fedora Packager” => “Build for Local Architecture”. Output of the RPM build will appear on the Eclipse console.


You can browse the source code [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mylyn/org.eclipse.mylyn.help.ui/?root=Mylyn_Project here]. Pay attention to [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mylyn/org.eclipse.mylyn.help.ui/build-helper.xml?root=Mylyn_Project&view=markup build-helper.xml], which drives the generation tasks, and [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mylyn/org.eclipse.mylyn.help.ui/toc.xml?root=Mylyn_Project&view=markup toc.xml], which links the generated table of contents into a single document.
Using mock-builds is a great way to test the “Requires/BuildRequires” of a spec-file. Select the spec-file => right-click => “Fedora Packager” => “Local Build Using Mock”. Be aware that this may take a long time (>20 minutes) and requires the mock package to be installed. Use Eclipse's “Run in Background” functionality for convenience.


==EGit==
=== Make Locally Committed Changes Public (Git Push) ===


The EGit project uses a single wiki page on Eclipsepedia for its [http://wiki.eclipse.org/EGit/User_Guide documentation].
The changes are ready to be pushed (or published) publicly when the locally committed changes are satisfying. Remember, Git allows history to be rewritten before changes are made public. See the [http://www.kernel.org/pub/software/scm/git/docs/ Git] and [http://wiki.eclipse.org/EGit/User_Guide EGit] documentation for more information. To bring the local repository in sync with ''origin'':


Check out the '''org.eclipse.egit.doc''' plug-in.
# Select the Fedora Git project
# Right-click, "Team" => "Push..."
# Select the Git repository to be pushed to (usually this is kept unchanged)
# Select the Git references to be pushed
# Carry out the push operation


==Xtext==
The Git push dialog.


The Xtext project uses a Textile and Wikitext for its documentation. The code is available in the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/plugins/org.eclipse.xtext.doc/?root=Modeling_Project org.eclipse.xtext.doc] plug-in. The documentation is sourced from various Textile files stored in source control and then transformed at build-time. This is different from the previous two examples which used the wiki as the source of documentation.
[[Image:GitPushDialog.png|Git Push Dialog]]


Pay attention to the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/plugins/org.eclipse.xtext.doc/customBuild.xml?root=Modeling_Project&view=markup customBuild.xml] and the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/plugins/org.eclipse.xtext.doc/doc/?root=Modeling_Project doc] folder.
Select the Git references to push. In this example, branches ''master'' and ''f14/master'' will get pushed. Keep in mind that source and destination references are the same for Eclipse Fedora Packager. Clicking the “Add all branches spec” button is a convenience that pushes all commits to all local branches.


==OSEE==
[[Image:SelectGitReferencesToPush.png|Select Git References]]


For modularity reasons, the OSEE project has multiple help projects which generate Eclipse online help from different parts of the [[OSEE#Documentation|OSEE wiki]]. The central help plugin is [https://dev.eclipse.org/svnroot/technology/org.eclipse.osee/trunk/plugins/org.eclipse.osee.framework.help.ui/ org.eclipse.osee.framework.help.ui], which contains a [https://dev.eclipse.org/svnroot/technology/org.eclipse.osee/trunk/plugins/org.eclipse.osee.framework.help.ui/build-helper.xml build-helper.xml] file that calls <tt>mediawiki-to-eclipse-help</tt> and specifies the different help chapters:
=== Pushing a Build to Koji ===


<source lang="xml">
Once satisfied with a spec-file, upload the sources of the package, commit the changes to the local repository, and then push the local changes to the remote repository. When this is done, push a build to Koji by right-clicking the spec-file => “Fedora Packager” => “Push to Koji”.
<mediawiki-to-eclipse-help wikiBaseUrl="${osee.help.doc.url.base}"
validate="true" failonvalidationerror="true" prependImagePrefix="images"
formatoutput="true" defaultAbsoluteLinkTarget="osee_external" dest="${basedir}"
navigationimages="true" title="OSEE User's Guide"
generateUnifiedToc="true">
<path name="OSEE/Users_Guide/Getting_Started" title="Introduction" />
<path name="OSEE/Users_Guide/Concepts" title="Concepts" />
<path name="OSEE/Users_Guide/Features" title="Features" />
<path name="OSEE/Users_Guide/Tips" title="Tips" />
<path name="OSEE/Users_Guide/New" title="New" />
<stylesheet url="book.css" />
<pageAppendum>
= Updating This Document =


This document is maintained in a collaborative wiki. If you wish to
[[Image:EclipseFedoraPackagerPushBuildToKoji.png]]
update or modify this document please visit {url}
</pageAppendum>
</mediawiki-to-eclipse-help>
</source>


Classpath/taskdef setup is performed in [https://dev.eclipse.org/svnroot/technology/org.eclipse.osee/trunk/plugins/org.eclipse.osee.framework.help.ui/scripts/help-build-common.xml help-build-common.xml]. Another example of an OSEE help plugin is [https://dev.eclipse.org/svnroot/technology/org.eclipse.osee/trunk/plugins/org.eclipse.osee.ats.help.ui/ org.eclipse.osee.ats.help.ui], which uses the libraries and taskdefs from org.eclipse.osee.framework.help.ui.
Eclipse will pop up a message with the Koji URL to track your build. This is an example of how the message may look:


== PsychoPath XPath 2.0 Processor ==
[[Image:KojiBuildPopupMessage.png|Koji Popup Dialog]]


The [[PsychoPathXPathProcessor/UserManual | PsychoPath Processor documentation]] is maintained on the eclipse wiki.  The documentation is then generated into DocBook format using Mylyn WikiText.  The documentation is then cleaned up as some of the conversions do not necessarily fit our specific needs.  The Docbook Project's XSL stylesheets are then used to generate the help into a variety of formats including eclipse help.
This should be enough information to track the builds.


* See [[Authoring_Eclipse_Help_Using_DocBook]] for more information on using Docbook to generate the final output produced by WikiText.
=== Pushing a Bohi Update ===


== XSL Tools ==
After successfully building the RPMs, use Eclipse Fedora Packager to push an update for those packages. To do so, select the spec-file => right click => "Fedora Packager" => "Bodhi Update". When creating a Bodhi update using Eclipse Fedora Packager, similar information is required as needed by the Bodhi Web interface. Once an update has successfully been created, the pushed update will be visible on the Bodhi updates website. The status of updates can also be tracked there.


Like the Psychopath Processor, the webtools [[XSLT_Project | XSL Tools documentation]] is also available on the wiki and generated back into DocBook format using Mylyn WikiText.
= Feedback/Reporting Bugs =


* See [[Authoring_Eclipse_Help_Using_DocBook]] for more information on using Docbook to generate the final output produced by WikiText.
If a bug is found in the Eclipse Fedora Packager, please feel free to open a ticket at https://fedorahosted.org/eclipse-fedorapackager/report/1 (a FAS username is required to create tickets). Alternatively, try [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&component=eclipse-fedorapackager&product=Fedora&classification=Fedora this query] on RedHat Bugzilla in order to find already existing bugs. Thanks!

Revision as of 18:10, 27 May 2011

What is Eclipse Fedora Packager?

Eclipse Fedora Packager is a plug-in for Eclipse. It helps Fedora packagers who are used to IDEs (such as Eclipse IDE), to package their Fedora RPMs from within Eclipse without needing to resort to the command line. (at least for the most part :-) ).

Some features included in the Eclipse Fedora Packager are:

  • Conveniently clone Fedora Git projects
  • RPM-spec-file editor with syntax highlighting, auto-completion and changelog support (<Ctrl>+<Alt>+C keyboard shortcut)
  • Download source files and upload new source files
  • Prepare local builds (execute %prep section of your spec-file only)
  • Create source RPM files based on current spec-file
  • Execute local builds
  • Push builds to Koji (the Fedora build system)
  • Mock builds
  • Push Bodhi updates
  • Eclipse Git support (via EGit, please refer to EGit documentation)

Eclipse Fedora Packager has been available for Fedora users since F14. Want to try it out? Issue the following command to install it: 

yum install eclipse-fedorapackager

Using Eclipse Fedorapackager

Since Fedora 14, the Git version control system for keeping track of files required for Fedora packaging is used. See the dist-git documentation for in depth information about dist-git. Fortunately, how dist-git works when using the Eclipse Fedora Packager plug-in is unimportant. There is only a slightly different approach for doing packaging work compared to what might have been used with CVS instead of Git.

Initial Setup

This step is only required to be completed once for a new Fedora packager or if using a new machine that does not have required FAS certificates set up. When it is certain this is correct it is safe to skip this step. The following explains how to set up those certificates for a FAS account?

First, install the fedora-packager RPM package: 

yum install fedora-packager

Then run the following command and simply follow the instructions provided: 

$ fedora-packager-setup

Once this is done Eclipse Fedorapackager is ready for use. Fire up Eclipse. Let's get started. Yay!

Importing a Fedora Git Project

Getting started is easy. Go to "File" => "Import" => "Git" => "Projects from Fedora Git". This will clone the desired Git repository and create necessary local branches. For convenience, the "Git Repositories" view will also open once the clone process has finished.

Fedora Git Import

Here's how the Fedora Git import dialog looks like. Next, specify the package name that will then be prepared for you.

Select Package Name

Once the new project has been created something akin to the following is seen. Note the branches in the Git Repository view and "[eclipse-fedorapackager master]" right beside the project name. In this case, eclipse-fedorapackager refers to the Git repository name and master to the currently checked out branch.

Git Branch View

Fedora Packaging Work

After a Fedora Git project has been created, all files required for packaging the desired release can be found in the created Eclipse project directly. For example, files for release Fedora 13 correspond to files present in the Eclipse project one switched to branch f13/master. Files in branch master correspond to Fedora rawhide, the current development release of Fedora. The following is a brief description of things to consider doing while packaging up some software. Working in a different sequence works, but keep in mind that before trying a Koji build push your locally committed changes to the public repository.

Uploading Source Files Required for a Package

In order to upload new sources in Eclipse Fedora Packager, first download upstream sources and place the downloaded sources in the same folder as the Eclipse project. If this is done outside of Eclipse, don't forget to refresh the project afterwards (F5) so that the file actually shows up. A slick way to download sources is to use RPM editor functionality directly. See its documentation for more information on this. Once the new source file is available in the project, it can be uploaded to the lookaside cache by right-clicking on the file=> "Fedora Packager" => Upload This File => Replace/Add File. This either adds the file to the sources required to build the package or replaces the current content of the sources file to contain a single line with the MD5 sum of the file selected.

A valid certificate is required to upload to the lookaside cache. If it has expired, a new one can be created by issuing the following command on a terminal: 

$ fedora-cert -n

Downloading Source Files Required for a Package

To download the required source files for an existing package in order to build it, right-click on the spec-file => "Fedora Packager" => Download Sources. This downloads all sources listed in the file sources.

Using the Spec-File Editor

Eclipse Fedora Packager uses the RPM Editor and ChangeLog plug-in from the Eclipse Linux Tools project (http://www.eclipse.org/linuxtools). For instance, a new ChangeLog entry can easily be created in the spec-file by using the <CTRL>+<ALT>+C keyboard shortcut (though a good idea is to set appropriate “ChangeLog” preferences first). Using <CTRL>+<SPACE> auto-completes locally installed packages. Also, rpmlint can be run by right-clicking on the spec-file => “Run Rpmlint”. For more information have a look at the spec-file editor screencast: http://www.eclipse.org/downloads/download.php?file=/technology/linuxtools/videos/specfile-demo.ogg or at the "Specfile Editor User Guide": Help => Help Contents => Specfile Editor User Guide.

Committing Changes to the Local Git Repository

After the spec-file, patches etc. have been added/changed, commit those changes to the repository. This is done by:

  1. Selecting the files to commit (alternatively select the Fedora Git project and select desired unstaged files when the commit dialog is shown)
  2. Right-click, "Team" => "Commit..."

Git Commit

Switching Branches (Git Checkout)

Switching branches is as easy as double-clicking on the desired local branch to be worked on. The currently checked out branch is indicated to the left of the project name. Make sure to commit, revert, or stash changes before switching to a different branch. Refer to the Git and EGit documentation for more information on this.

Prepare Sources for a Local Build

Eclipse Fedora Packager will download and prepare sources by right-clicking on the spec-file => “Fedora Packager” => “Prepare Sources for Build”.

Prepare Sources for Build

Build RPM for a Local Architecture

This is a great way to test if the spec-file actually builds at all. Once the RPM has been successfully built locally, it is recommended further testing be carried out on the spec-file by completing a build in a chroot'ed environment using mock. Both ways are supported by Eclipse Fedora Packager.

The RPM can be built locally by selecting the spec-file => right-click => “Fedora Packager” => “Build for Local Architecture”. Output of the RPM build will appear on the Eclipse console.

Using mock-builds is a great way to test the “Requires/BuildRequires” of a spec-file. Select the spec-file => right-click => “Fedora Packager” => “Local Build Using Mock”. Be aware that this may take a long time (>20 minutes) and requires the mock package to be installed. Use Eclipse's “Run in Background” functionality for convenience.

Make Locally Committed Changes Public (Git Push)

The changes are ready to be pushed (or published) publicly when the locally committed changes are satisfying. Remember, Git allows history to be rewritten before changes are made public. See the Git and EGit documentation for more information. To bring the local repository in sync with origin:

  1. Select the Fedora Git project
  2. Right-click, "Team" => "Push..."
  3. Select the Git repository to be pushed to (usually this is kept unchanged)
  4. Select the Git references to be pushed
  5. Carry out the push operation

The Git push dialog.

Git Push Dialog

Select the Git references to push. In this example, branches master and f14/master will get pushed. Keep in mind that source and destination references are the same for Eclipse Fedora Packager. Clicking the “Add all branches spec” button is a convenience that pushes all commits to all local branches.

Select Git References

Pushing a Build to Koji

Once satisfied with a spec-file, upload the sources of the package, commit the changes to the local repository, and then push the local changes to the remote repository. When this is done, push a build to Koji by right-clicking the spec-file => “Fedora Packager” => “Push to Koji”.

EclipseFedoraPackagerPushBuildToKoji.png

Eclipse will pop up a message with the Koji URL to track your build. This is an example of how the message may look:

Koji Popup Dialog

This should be enough information to track the builds.

Pushing a Bohi Update

After successfully building the RPMs, use Eclipse Fedora Packager to push an update for those packages. To do so, select the spec-file => right click => "Fedora Packager" => "Bodhi Update". When creating a Bodhi update using Eclipse Fedora Packager, similar information is required as needed by the Bodhi Web interface. Once an update has successfully been created, the pushed update will be visible on the Bodhi updates website. The status of updates can also be tracked there.

Feedback/Reporting Bugs

If a bug is found in the Eclipse Fedora Packager, please feel free to open a ticket at https://fedorahosted.org/eclipse-fedorapackager/report/1 (a FAS username is required to create tickets). Alternatively, try this query on RedHat Bugzilla in order to find already existing bugs. Thanks!

Retrieved from "https://fedoraproject.org/w/index.php?title=Eclipse_How_to_Maintain_Fedora_Package_User_Guide&oldid=238321"