So, I’ve lately not been blogging or generally doing anything other than being lazy. Now that the next semester of college is starting to ramp up in the near future I’ve decided to attempt to jump-start my productivity. The first step was updating my machines into a usable environment which meant clobbering portage blockers and such until I had my world fully updated to the latest ~amd64 and my developer chroot to the latest stable amd64. The latter was a bit more work, with tons of perl blockages and fetch restricted packages on the java side. All in all not too bad, after a series of
emerge -avuD world --keep-going; revdep-rebuild; dispatch-conf
the chroot was sane again and ready for developer work. Now I can stop slacking so much and help squish some amd64 bugs. (Also, why isn’t –keep-going default? Sigh, maybe I’ll just alias it along with nice and ionice.)
Besides working on Gentoo I’ll be ramping development back up on my two pet projects: GPytage and Zito.
GPytage is currently undergoing a near complete rewrite to support recursive folders and file structures under /etc/portage/. Currently reading in all the files and constructing the internal database is functional and so is a basic UI. Saving still needs to be reimplemented among a variety of other things. I plan to eventually redo all of the accelerator shortcuts into something more sane and to recode glade-based dialogs and windows into pure pygtk.
Zito is currently still in development and undergoing Internationalization refactoring. After that is done, some code tidying and perhaps UI changes are due. I’m still at a loss on how to actually package something like Zito being a java project. I know Ant can do it, but I’m still not exactly sure how to use Ant in the sense of coding a build and install file for it. Seems quite a pain setting up the XML file for Ant.
On a related note, I can say that I am fairly happy with bzr now. I used to be a large git supporter, but many git commands require extensive knowledge of syntax, flags to pass, and just isn’t as user friendly. Bzr I’ve found is very easy to work with and I have not had any problems with it so far. Most of my projects I’ve converted locally to bzr repositories. In my observation, Bzr knows what “the right thing to do” is most of the time and prevents most repository screwups.

#1 by Jacob Godserv on August 10, 2009 - 9:21 am
FYI, you can add EMERGE_DEFAULT_OPTS=”–keep-going” to your make.conf if you want.
(And, I’m glad to hear you “get” bzr. Most people I talk to don’t appreciate it.)