Hacking away on Thermostat

About a month back I’ve started hacking away on Thermostat. It’s an instrumentation and monitoring tool for the HotSpot Java virtual machine. Here is a list of features which have been implemented so far and here is a rough timeline of what’s coming. Suggestions about features you’d like to see are always welcome!

My contributions so far have been mostly to get started on a basic Eclipse plug-in-based Thermostat client. Here is a short screencast showing it in action (Webm format):

http://jerboaa.fedorapeople.org/demo/thermostat/eclipse_prototype_20120816.webm

Keep your eyes peeled for updates on this 🙂

Advertisement

Screencasts on Fedora Packager for Eclipse: Vol 3, Initiating Koji Builds

Fedora Packager for Eclipse brings Fedora RPM packaging tools into Eclipse. Think of it as a GUI for fedpkg 🙂 In two earlier posts, I’ve shown you how you can import Fedora Git projects into Eclipse and how to prepare a brand new Fedora package suitable to be submitted for review. This screencast shows you how you can initiate Koji builds for your packages.

Those of you who don’t know what Koji is it’s the system Fedora uses for building the RPMs for the distro in a well defined environment. All packages shipped in Fedora get built that way. You’ll also see in the screencast how can you swiftly initiate Koji builds for secondary architectures, such as ARM and PowerPC (it’s about 4 minutes into the screencast). It’s a brand new feature coming with our next 0.4 release of Fedora Packager for Eclipse. With this implemented, adding user defined Koji instances to the available list in Fedora Packager for Eclipse is as easy as implementing the

org.fedoraproject.eclipse.packager.koji.instance

extension point. Cool stuff! Many kudos to Andrew Robinson for implementing this.

You can test-drive the upcoming version by downloading the Fedora Packager for Eclipse 0.4 RPM from Koji (produced via an SRPM based scratch-build as shown in the screencast). And here it is (OGV format):

http://jerboaa.fedorapeople.org/demo/eclipse-fedorapackager/koji-builds.ogv

Enjoy!

Developing Gimp with Eclipse CDT

A colleague of mine has posted a tutorial as to how to build and develop Gimp using Eclipse CDT. Very cool, check it out!

Screencasts on Fedora Packager for Eclipse: Vol 2, Cloning Fedora Git Projects

Fedora Packager for Eclipse can be used to maintain your Fedora packages as well as for preparing new packages for review. Today I wanted to show you how you can import Fedora packages into your Eclipse workspace. Once you have it there you are ready to edit the .spec file, test your modifications using Fedora Packager for Eclipse and commit changes to the Git repository using EGit. Without further ado, here is the link to the ~2:30 minutes long screencast (OGV format):

http://jerboaa.fedorapeople.org/demo/eclipse-fedorapackager/import_fedora_git_projects.ogv

Enjoy!

Enabling Image Icons in Eclipse

I think icons make sense and in general terms improve software usability if used properly. This applies to Eclipse as well. If you happen to use the context menu a lot, say for committing things to Git, you might be used to this:

No image icons in Eclipse

Note the plain context menu, which does not show any icons. Contrast this with this:

Image icons show in the context menu et. al.

Yay, icons show up 🙂 For those of you who wonder how to enable icons in Eclipse, here is how you can do this (assumes Fedora 15 and Gnome 3).

$ sudo yum install gnome-tweak-tool
$ gnome-tweak-tool

Then go to “Interface” and turn on “Menus Have Icons”. It should look like this:

Gnome tweak tool with menu icons turned on

Edit (2015-01-28): If you want to do this in Fedora 20+ use the following. Taken from [1]:

Install dconf-editor and open dconf-editor:

$ sudo yum install dconf-editor
$ dconf-editor

Navigate to key org.gnome.settings-daemon.plugins.xsettings and change overrides from:

{}

to

{'Gtk/MenuImages': <1>}

[1] http://forums.fedoraforum.org/showthread.php?p=1680581#post1680581

Screencasts on Fedora Packager for Eclipse: Vol 1, Fedora RPM Projects

I’m going to do a series of screencasts on Fedora Packager for Eclipse (v0.2 and later). The first one is on “Fedora RPM projects” which makes it easy for you to come up with a .spec file and SRPM from scratch, based on another SRPM – e.g. from a different distro – or feature.xml or pom.xml (Python eggs and Ruby gems would be also cool to support). Once you have a .spec file and an SRPM, you can upload them somewhere and get them reviewed via the usual process. Without further ado, here it is (OGV format):

http://jerboaa.fedorapeople.org/demo/fedora-rpm-project/fedora_rpm_projects.ogv

Fedora Packager for Eclipse 0.3 will have a conversion tool to migrate “Fedora RPM projects” to “Fedora Git” projects (these are projects which you can import via CTRL+ALT+F I) It’s also planned to provide an easy way to upload a “Fedora RPM project” for review. Anyhow, so far the first screencast 🙂

What do you think? Is there a feature you are missing desperately? Let us know. Happy packaging! 😉

Code review is a good thing

I recently stumbled upon David Trowbridge’s blog post about code review which pretty much sums up how I feel about code review. Yes, code review will slow down development and you should have the back-up from management but it’s definitely worth it. Go start implementing code review now 😉

Fedora Packager for Eclipse 0.2 released

The Fedora Packager for Eclipse development team is proud to announce our 0.2 release. What’s Fedora Packager for Eclipse? I’m glad you asked. In a nutshell it can be seen as an IDE for Fedora packaging. It helps you creating RPM packages for Fedora. Some might call it a GUI for fedpkg, although we don’t use it under the covers 😉 A picture says more than a thousand words. Here is a screenshot:

Fedora Packager for Eclipse Screenshot

This release includes a lot of new cool features and even more bug-fixes and usability improvements. So what is it that’s new in Fedora Packager for Eclipse you ask? Here is a brief run-down of the coolest new features:

• Local Fedora RPM project support
• Keyboard shortcuts
• SRPM based Koji scratch builds
• Improved mock based builds.
• SRPM import
• Better Bodhi integration

For a more detailed list of new features and bug-fixes see our release notes. Our updated Fedora Packager for Eclipse user guide explains new and old features in detail. Fedora Packager for Eclipse 0.2 will be part of the upcoming Fedora 16 release. Can’t wait? Get it right now from rawhide (note that you will have to upgrade to Eclipse Indigo from rawhide for it to work):

$ sudo yum update --enablerepo=rawhide eclipse-fedorapackager

If you already have Eclipse Indigo you can alternatively install it from our p2 repository. Get it while it’s hot 🙂 We look forward to your feedback and hope you’ll like it! Many kudos to everyone involved making this our best release so far. Enjoy!

Generating Passwords

Here is a little snippet to generate some throw-away passwords in a script. You may have to install sharutils.

$ dd if=/dev/urandom count=1 2> /dev/null | uuencode -m - | sed -ne 2p | cut -c-8

Neat!

Debugging Eclipse dropins

Chris Aniszczyk wrote a handy little blog post about debugging Eclipse dropins a while back which I’d like to share.

Why is this useful? That’s how packaged Eclipse plug-ins are installed in Fedora (for example). In a nutshell, a directory is dropped into a dropins directory system Eclipse knows about when an RPM is installed (e.g. by using yum). The name dropins kind of makes sense 🙂 When Eclipse is started the next time it checks timestamps on files and directories in those dropin-directories and if something has changed, will try to install them. No problem you say? Not quite. First note that all dropins installed bundles get marked as optional, so no error is reported when dropins reconciliation fails. Here is a scenario: Say the bundle you just installed using yum could not be resolved (for whatever reason), then Eclipse will just omit those unresolved bundles, since they’re optional anyway and just starts with bundles the user had installed previously. This is a problem, since the user thinks the plug-in is installed – the yum installation succeeded, after all – but in fact, the *real* installation happens when Eclipse starts the next time. This really is a very brief explanation of the problem and by no means complete. Take home message: one shouldn’t use dropins but use the p2 director to install Eclipse plug-ins instead.

In any case it’s useful to be able to discover dropins problems and this is what Chris described in his blog post. It’s fairly straight forward. Just create a .options file in your current working directory, put the following content into it and start Eclipse with: $ eclipse -debug -consolelog -clean (you might want to consider removing ~/.eclipse as well). The only required option is debug, but the other ones are useful as well.

org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true

After that you should see very verbose output which should give you hints as to why some plug-ins don’t show up in Eclipse. Happy debugging!