Categories: Life at home, 161 wordsSend feedback • PermalinkBusy, busy times here at rPath! There have been interviews (Did I mention that we're hiring?) and some of them have actually resulted in new faces around the office. Among them is a new addition to the rBuilder team: Scott (deployer of what could be one of the first Linux-based cybercafes back in the mid-90s) -- welcome, Scott!
Channeling my tech-writer past (Did I mention that we're hiring? A tech writer? Hello?), I've put together Conary Day-to-Day, which is an overview of the commands the sysadmin of a Conary-based system would need to maintain said system. I also linked to it on the Conary wiki, under "End-User Docs". Feedback is welcome -- ping me on #conary (I'm yeliaB).
What's in store next? Well, we've scheduled time tomorrow night for giving rBuilder Online a little lovin'. More about that later. Oh, and the rBuilder team looks like it's going to get a little bigger in a few weeks. More about that later, too!
Categories: Life at home, 319 wordsSend feedback • PermalinkThis afternoon, my cell phone rang as I sat in my father-in-law's den, working on his computer (even though I may not be an uber-geek at rPath, I still serve as the family support technician on all computer-related matters).
On the other end of the phone was Matt. As I reinstalled a printer driver for my father-in-law, Matt told me that Digg had done an article on us, and that rBuilder Online was doing its best to handle the load. He and some of the rBuilder team had made some changes to help the site better weather the storm.
As I typed, I explained the situation to my father-in-law like this:
Imagine you're making dinner for your family when the doorbell rings. It's friend of yours, unexpectedly come to visit. Being the gracious host you are, you pull out an extra plate, some silverware, and a glass, and invite them to join you for dinner. Your dinner portions might be a little bit smaller than anticipated, but you should be able to give your guest -- and your family -- a decent dinner nonetheless.
Now imagine that a major newspaper printed a front page article on what a wonderful dinner you were having, and how you love to entertain unexpected guests. I looked at my father-in-law, "What do you think dinner will be like?"
He shot me a glance. "Not many people gonna be eating."
I nodded, and noted that, even with this kind of thing happening to us, rBuilder Online had added more people to its community in twelve hours than had joined in the last month. At least the dinner had not been a complete disaster.
And to all our new friends from Digg that dropped by for dinner and had to be turned away: Sorry we ran out of food, but if you come back a bit later, we'll be sure to set out a plate for you.
Categories: Work at rPath, 741 wordsSend feedback • PermalinkIn the back of my mind, I knew it was going to happen eventually. I didn't know when, exactly. And I didn't know who, precisely. But I knew it was coming.
The when ended up being a couple days ago. The who ended up being Michael, as he announced that he'd been looking over everyone's blog here at rPath. He called my name and, as I turned toward him, said one word:
"August?"
Instantly just about everyone in Engineering made the "you did it" sound. You know the sound -- it's that sound that everyone in Mrs. Morash's second-grade room made when, after Mrs. Morash left the room for a moment, you decided to perform a goofy impression of Mrs. Morash at her desk except, as you went to shake your finger at Stewie Martin to stop picking his nose, your hand accidentally (really!) knocked her favorite little ceramic doggie off the desk and onto the floor, where it smashed into about a bajillion pieces, and then everbody made the sound, and Mrs. Morash came back in and...
Ahem.
Anyway, everybody made the sound, and I knew that I hadn't been doing my part on the blogging front.
(Side note: It's not like there's some sort of "blog every N days or else" checklist at rPath. It's just that we all felt it was time for us to start letting people know a bit more about who we are, and just how incredibly cool this stuff we're building really is. We figured the best way to do that would just be for everyone to blog about stuff that comes up as part of their day-to-day work.)
Given that my last blog entry was back in August (early August, at that), I clearly had some catching up to do.
So I'm sorry about the silence over the past four months (dang, that sounds bad), but here's what's been keeping me busy during that time (in no particular order, and just touching on the high points):
- All sorts of random work on what was then known as "the website" but is now called rBuilder Online. This random work included everything from acting as clueless newbie (ok, maybe not so much acting) to help determine what parts of rBuilder Online could be streamlined, to writing some of the various snippets of text on the site, to even hacking a bit on some of the templates here and there.
- Feeling the pain of being a bit too close to the bleeding edge with respect to the software on my laptop.
- Reinstalling said laptop after vowing that anything pushed to our public Conary repository was more than sufficiently "bleeding edge" for me, thank you very much. And yes, my laptop has been much happier since taking this vow. Thanks for asking!
- Acting as a second set of eyes reviewing various Conary announcements.
- Working with a web design firm retained to help us make rBuilder Online look better than a group of engineers with no real artistic talent ever could.
- Participating in discussions that eventually led to the documenting of a process for generating and deploying keys for the signing of packages by rPath employees.
- Submitting and/or contributing to various Bugzilla reports related to rBuilder Online.
- Running out and buying a Windows box so we can test rBuilder Online on more than just Linux boxes running Firefox.
- Reading many resumes, interviewing many candidates, and attending many meetings concerning said candidates. Need I mention that we're hiring?
- Working on a document introducing Conary to sysadmins with Conary-based systems. (Coming soon to a website near you!)
- Getting horribly sick and being out for a couple weeks, followed by another month of "The Sinusitus From the Black Lagoon". No, it wasn't as fun as it sounds...
- Learning more about wikis, and how we might improve ours.
Those of you that had stumbled over my wiki page might think that the amount of actual writing listed above is pretty slim for someone billing themselves as "the company's resident wordsmith", and you'd be right. The reason for my dearth of writing output is that I was asked to lead the team of developers working on rBuilder Online, which was an honor I could not pass up. I mean, these guys are incredibly sharp, and just a lot of fun to work with -- how could I say no?
What does this mean for rPath's writing needs? Well, did I mention that we're hiring?
Categories: Work at rPath, 1005 words1 feedback • PermalinkThe other day I built my first package using Conary, and it was an eye-opening experience.
Sitting in the rpath offices, I get to hear many interesting things from the engineers. But there was one comment in particular that I thought was especially interesting (I'm paraphrasing here):
"When we find something that the packager would normally have to handle on their own, we try to come up with ways of having Conary do it for them. That way, we can solve the problem once, and it makes packaging that much easier."
I got to experience the implications of this philosophy firsthand.
The software I chose for my first packaging attempt using Conary was Zile -- a *very* small (~100K) editor that supports a surprisingly large subset of the basic Emacs key sequences.
Side note to those of you that have just now gone, "Ah ha! An Emacs user!":
Yes, I am a long-term (~25 years) member of the Cult of the Iron Pinky. I hold no ill-will toward the
:wqClan, and will countenance no ill-will in return. Keep a sense of humor, and one of these days Uncle Ed will tell you the story of how vi trounced Emacs (yes, we lost) in a paintball match at the '98 Linux Expo, ok?Back to our regularly-scheduled post.
I felt that Zile would be a handy little editor to have around for those of us that use Emacs more than vi, and wanted a small-footprint editor (either for quick editing tasks, or to put on something like a dedicated firewall/appliance box).
To get started, I downloaded the Zile tarball from SourceForge, and took a look. The
INSTALLfile noted that it was built using the "./configure/make/make install" drill that is pretty darn common these days.I also noted that, by default, it wanted to install everything in
/usr/local/-- I'd have to deal with that (there's just no sense in packaging software so that it installs in/usr/local/), but I thought I'd just hack together a quick recipe file (Conary's equivalent to RPM's spec file) first, and try a quick local cook (build, for you RPM types in the audience).Here's the first iteration of my Zile recipe file, in its entirety:
class zile(PackageRecipe):name = "zile"
version = "2.2.2"def setup(r):
r.addArchive('http://unc.dl.sourceforge.net/sourceforge/zile/zile-%(version)s.tar.gz')r.Configure()
r.Make()
r.MakeInstall()
Seemed pretty simple. I figured that I'd need to do some additional tweaking to get something ready for prime-time, but hey -- why not give it a try?
I typed
cvc cook zile.recipeand hit return.I watched as the tarball specified by
r.addArchivewas downloaded (after downloading, it was automatically cached on my machine so subsequent cooks using the same tarball wouldn't need to download it each time.) Then the build started...and completed...and a changeset file was written.My first Conary package was built!
But what did the package look like? Was it even usable? After all, I really didn't do anything other than to tell Conary what I was packaging, where to find it, and the basic steps required to build and install it. There had to be more to it than this...
To figure out what else I needed to do, I installed the changeset file using
conary update.Hmmmm, no errors there.
Then, I typed
zileand up came Zile's startup screen. It worked!Looking a bit more closely, I saw that all the right things were done with the software, right down to changing the default install path from
/usr/local/to/usr/. This software was packaged and ready to go.I was amazed -- this was nothing like my past experiences packaging software with RPM.
Emboldened by my speedy success, I asked my coworkers if I could have commit access to our repository on contrib.rpath.com. Nobody laughed hysterically at the thought, so officemate Michael created a username/password on the contrib repository for me.
Three commands later (
cvc add zile.recipe ; cvc commit ; cvc cook zile), and my baby was cooked, with the source and binaries committed into the contrib repository, and ready for anyone to install.(You can check out my handiwork here.)
To make sure people knew what Zile was, I used a neat feature of Conary repositories -- a single mouse click, and the Zile's description text from freshmeat.net was added to the contrib repository.
While all this was easy, Zile is a pretty small and simple app. Is all software as easily packaged as Zile? Honestly, no -- you're not going to cook something like glibc or a kernel using a recipe this simple. But think about how much software out there builds with just
./configure ; make ; make install. For software that builds as easily as Zile, packaging using Conary can be just this easy.I looked over my recipe again, now that it was publicly available. I made some minor tweaks to it, and recooked/committed.
There -- until the time upstream releases a new version, I was done with Zile.
Later, I noticed that Michael made some changes to my recipe. He must've seen the commit emails that are generated when I committed Zile to the contrib repository. I looked over the recipe, and my jaw dropped.
He actually made it simpler:
class zile(AutoPackageRecipe):name = "zile"
version = "2.2.2"buildRequires = [ 'libtermcap:devel' ]
def unpack(r):
r.addArchive('http://unc.dl.sourceforge.net/sourceforge/%(name)s/%(name)s-%(version)s.tar.gz')
(Michael explained that I really should've included a
buildRequiresline right from the start as he showed me how to use the output ofconary showcsto display the libraries required by my Zile changeset file.)Looking at Michael's recipe, it struck me that here was that philosophy in action -- the
./configure ; make ; make installsequence is pretty common, so why force packagers to explicitly specify it time after time after time? Instead, modify Conary to make this common situation that much easier to package.And everyone is happier.
Categories: Work at rPath, 122 wordsSend feedback • PermalinkThere I was, getting rid of blog spammers (a situation that is becoming disturbingly frequent for me) and complaining loudly, when officemate Tim asked me if I'd seen the search terms people had used to get to my blog.
As I looked over his shoulder, I saw terms that made sense:
conary repositoriesrpath blogblog balding(well, it makes sense if you know what I look like)...and so on.
But then, there were some others that, quite frankly, make me wonder about some of you people out there on the Intarweb:
soccer mom's night outrubberboot skinmuddy french maidAt least I can take comfort in the fact that they definitely didn't find what they were looking for here... :-)