Wednesday, November 25, 2015

virt-manager 1.3.0 released!

Last night I released virt-manager-1.3.0. Not too much exciting in this release, just a lot of little improvements and bug fixes.

The highlights:
  • Git hosting moved to
  • Switch translation infrastructure from transifex to
  • Add dogtail UI tests and infrastructure
  • Improved support for s390x kvm (Kevin Zhao)
  • virt-install and virt-manager now remove created disk images if VM install startup fails
  • Replace urlgrabber usage with requests and urllib2
  • virt-install: add --network virtualport support for openvswitch (Daniel P. Berrange)
  • virt-install: support multiple --security labels
  • virt-install: support --features kvm_hidden=on|off (Pavel Hrdina)
  • virt-install: add --features pmu=on|off
  • virt-install: add --features pvspinlock=on|off (Abhijeet Kasurde)
  • virt-install: add --events on_lockfailure=on|off (Abhijeet Kasurde)
  • virt-install: add --network link_state=up|down
  • virt-install: add --vcpu placement=static|auto

Monday, May 4, 2015

virt-manager 1.2.0 released!

Today I released virt-manager-1.2.0. You can read the release announcement here:

This release includes:
  • OVMF/AAVMF Support (Laszlo Ersek, Giuseppe Scrivano, Cole Robinson)
  • Improved support for AArch64 qemu/kvm
  • virt-install: Support --disk type=network parameters
  • virt-install: Make --disk $URL just work
  • virt-install: Add --disk sgio= option (Giuseppe Scrivano)
  • addhardware: default to an existing bus when adding a new disk (Giuseppe Scrivano)
  • virt-install: Add --input device option
  • virt-manager: Unify storagebrowser and storage details functionality
  • virt-manager: allow setting a custom connection row name
  • virt-install: Support --hostdev scsi passthrough
  • virt-install: Fill in a bunch of --graphics spice options
  • Disable spice image compression for new local VMs
  • virt-manager: big reworking of the migration dialog

Look out for future posts on the first 4 line items :)

Monday, April 13, 2015

Fedora 22 Virt Test Day is Thu Apr 16!

A reminder that the Fedora 22 Virt Test Day is this coming Thu Apr 16. Check out the test day landing page:

It's a great time to make sure your virt workflow is still working correctly with the latest packages in Fedora 22. No requirement to run through test cases on the wiki, just show up and let us know what works (or breaks).

Updating to a development release of Fedora scares some people, but it's NOT required to help out with the test day: you can test the latest virt bits on the latest Fedora release courtesy of the virt-preview repo. For more details, as well as easy instructions on updating to Fedora 22, see:

Though running latest Fedora 22 on a physical machine is still preferred :)

If you want to help out, pop into #fedora-test-day on Thursday and give us a shout!

Wednesday, April 8, 2015

python-bugzilla 1.2.0 released

I've just released python-bugzilla-1.2.0. This release includes:
  • Add bugzilla new/query/modify --field flag (Arun Babu Neelicattu)
  • API support for ExternalBugs (Arun Babu Neelicattu, Brian Bouterse)
  • Add new/modify --alias support (Adam Williamson)
  • Bugzilla.logged_in now returns live state (Arun Babu Neelicattu)
  • Fix getbugs API with latest Bugzilla releases
I'd like to expand a bit more on a couple of these changes.

bugzilla new/query/modify --field flag

Arun had a good idea about adding a generic --field option to the CLI. Rather than depend on /usr/bin/bugzilla to grow a specific command line option for some new custom bugzilla field, you can use --field to get your work done.

For example, Red Hat bugzilla has a custom field called 'cf_pm_score' that's used for internal RHEL workflow. However /usr/bin/bugzilla doesn't have any explicit command line support for this field.

But if you wanted to alter the cf_pm_score field from the command line, you can now do:

bugzilla modify $BUGID --field cf_pm_score=100

Of course, for popular bugzilla fields we should make sure the command line tool has an explicit and document option, but this takes the pressure off of us to add an option for every custom Red Hat extension.

Bugzilla.logged_in now returns live state

A recurring problem people hit with the bugzilla API is receiving unexpected results because they aren't actually logged into bugzilla. This often happens when their cached bugzilla token has expired. For most operations the bugzilla API doesn't give any error in this case, and there's historically been no simple API to ask 'am I actually logged in?'

The Bugzilla API class has long had a property 'logged_in' that wasn't very useful, only returning True for a very specific circumstance. Arun extended this with a heuristic to determine if we are _actually_ logged in to bugzilla.

So if you have any scripts that talk to the python-bugzilla API and depend on actually being logged in, add a check at the top of your code to bail out if logged_in == False and save yourself some future confusion :)

IIRC the next major version of bugzilla does provide some API support in this area, so hopefully we can expand on this when newer bugzilla version are deployed.

Tuesday, March 31, 2015

bodhi-push-updates: Script for easily pushing updates to stable

I wrote a helper script that saves some clicks if you need to push a bunch of pending Fedora package updates to stable. I figure it's useful for other folks too so I published it here:

Description from the README:
Basically works like this:
  • Query all your pending updates
  • Filter out the ones that haven't reached the testing timeout, by looking for the 'can be pushed to stable' comment from bodhi.
  • For each appropriate update:
    • Show the update karma
    • Filter out bodhi process comments ('pushed to testing' etc.)
    • Filter out PASSED taskotron messages
    • Show the remaining comments
    • Prompt the user if they'd like to push this update to stable
  • Push all the requested updates to stable
So if you push a lot of updates this can save a bit of time clicking around in the web UI or invoking bodhi manually from the command line.

Saturday, February 28, 2015

cubietruck setup, though my card reader is flaky

Finally setup my cubietruck that I purchased late last year. Here it is under my desk running Fedora 21:

Riveting, I know.

I mostly just followed bits from Rich's and Kashyap's blog posts, and the Fedora ARM install instructions. I used this serial adapter, though note you need to make sure to make sure the TX pin on the board is wired to the RX pin USB end, and vice versa. Probably obvious to some people but I would have been stumped if I hadn't seen it mentioned in an Amazon review.

Everything is working now but my hardware has a bit of a malfunction that I mentioned in this fedora-arm thread. Basically the device can boot off the SD card, but linux doesn't detect it. If I wiggle the card around a lot while inserting it I can get linux to detect it about 1/5 of the time, but after rebooting the device is back to not being detected. In the thread, Hans guessed that the card-detect pin is flaky or not connecting well, but it doesn't affect the cubieboard firmware which just ignores that pin and assumes the device is present.

Since I was planning on using a SATA drive anyways, this isn't that big of a deal, just delete everything on the SD card except u-boot, and the SATA drive will be used /boot and /. But if I ever want to update u-boot on the SD card, I'll have to go through the whole wiggle process again and manually 'dd' it into place using the steps on the Fedora install page.

Monday, February 16, 2015

Fedora 22 Virt Test Day scheduled for Thu Apr 16

Just a quick note that the Fedora 22 Virt Test Day is scheduled for Thursday April 16th. The inprogress landing page is at:

If you're interested in helping out please mark your calendars.

Friday, February 13, 2015

git up: The better git pull

A while ago I stumbled across a nice git extension 'git up'. The README synopsis lays out the motivation:
git pull has two problems:
  • It merges upstream changes by default, when it's really more polite to rebase over them, unless your collaborators enjoy a commit graph that looks like bedhead.
  • It only updates the branch you're currently on, which means git push will shout at you for being behind on branches you don't particularly care about right now.
Solve them once and for all.
As implied above, git-up will update all your branches that are tracking a remote branch. This often comes in handy in fedora git repos:

 [crobinso@colepc openbios (master)]$ fedpkg pull  
 Already up-to-date.  
 [crobinso@colepc openbios (master)]$ git up  
 Fetching origin  
 f20  fast-forwarding...  
 master up to date  
 returning to master  

Another useful bit is that it will stash and unstash uncommitted changes. Often times I find myself doing this:

 [crobinso@colepc ~]$ cd src/virt-manager/  
 # Hack some minor bug fix  
 [crobinso@colepc virt-manager (master *)]$   
 # Oops, I should pull first, maybe the issue is fixed  
 [crobinso@colepc virt-manager (master *)]$ git pull  
 Cannot pull with rebase: You have unstaged changes.  
 Please commit or stash them.  
 [crobinso@colepc virt-manager (master *)]$ git up  
 Fetching origin  
 stashing 1 changes  
 master up to date  
 [crobinso@colepc virt-manager (master *)]$   

Nowadays I don't even attempt the pull, git up is my reflex. (And yes I should just make it a reflex that I switch to a branch before doing any hacking...)

Nice to see that nowadays git-up is packaged in fedora, so grab it with sudo yum install rubygem-git-up

Friday, January 9, 2015

Using git-remote-hg with bitbucket

Occasionally I want to contribute to a project using mercurial on (like pylint). Since I always forget the steps, I'm documenting here how I've managed that without having to actually use mercurial.
  • From, log in, find the repo you want to contribute to, use the web UI to fork it under your account.
  • yum install git-remote-hg
  • Clone your fork using git
    • Generic format is: git clone hg::$URL
    • So for my fork of astroid, the command looks like: git clone hg::ssh://
  • Create a git branch, the name must start with 'branches/' to make mercurial happy when we eventually push things. So something like: git checkout -b branches/myfix
  • Make your changes in the branch
  • Push the branch to your repo: git push origin branches/myfix
  • Use the bitbucket web UI to submit a pull request.
  • That's it.
Though I haven't figured out how to update a pull request... instead I've resorted to closing the first request, creating a new branch on my fork, and submitting a brand new pull request. There's probably some nicer automagic way but I haven't figured it out.

(Hopefully in the near future more of the python ecosystem will move to git.)