Planet Conary

The local orienteering club, BOK, is organizing an A-meet (i.e. a national event), February 20-21. I’ve signed up to be one of the setter/vetters.

It’s very interesting how we decided to make sure we minimize the risk for mistakes when setting up controls, and in a way it’s an OCD-er’s dream. There are at least three setters that will go out and hang ribbons where the controls are placed. Then, two other persons (the vetters) have to go and vet (approve) the location chosen by the setter. Setters have the liberty to move the control from where the course designer suggested the location to be, for example if a feature is missing or is too dangerous to get to; vetters should try hard not to move controls, unless they were set wrong.

This gives you triple accountability for a control’s location, not to mention that some of the club members will have a practice run of the courses the week prior to the meet (which happens to be next weekend).

Today I spent more than 4 hours vetting. Now I am barely moving. Probably getting into the warm house after all that time in the balmy 34-36°F (1-2°C) did not help much. However, this is exactly what I need, hopefully the small injuries I’ve been accumulating over the past couple of months will eventually go away to let me go back to running on a more regular schedule.

I’ve also worked on a solution to download data from an Sportident box on a Linux computer (it might work on Windows too, since it’s written in python, and I believe pyserial does work on Windows. It has sound to alert users if their download was unsuccessful (more about that in a future post), and generates a PDF for the splits and total time; I think the printing part is going to be the one that will cause most of the problems, I seem to have bad luck with printers in general. (The printing part would definitely not work on Windows). At some point I will publish the code, maybe someone else has a use for it.

Making Light:

[F]amously-crackpot Whole Foods CEO John Mackey has now made himself sufficiently repellent that I very much doubt I’ll ever feel like spending a dime in one of his stores again. Not content with peddling rich-guy “libertarian” attacks on health-care reform, asserting that climate change is a fraud designed to “raise taxes and increase regulation, and in turn lower our standard of living and lead to an increase in poverty,” comparing unionization to herpes, and getting caught playing sockpuppet games on financial message boards, Mackey is now‌charging his employees more for food if they fail to meet his arbitrarily-chosen cholesterol, blood pressure, and body-mass index criteria.

The original article at Jezebel dryly observes:

Because if public health research has taught us anything, it’s that reducing people’s buying power totally makes them healthier. Stay classy, Whole Foods.

My name is Erik and I have am addicted to my Kindle.

The realization hit me this morning. I've been reading a pulpy 12 book or so sci fi series. My wife suggested it when I had strep throat as an easy read, and the books are fun, quick to read, and mindless enough to work well when I've been traveling. Oh, and they're all available on the Kindle.

Now, my wife owns most of these as trade paperbacks. That didn't stop me from buying them for the Kindle though. I could finish a book, turn on the wireless, and start the next one from the comfort (hah!) of an airport chair. I didn't have to shove a couple of paperbacks into my laptop bag, just the Kindle. Nevertheless, I now see that buying books we already owned was the first sign of addiction.

This morning I discovered that only the first 7 (or so) books are available on the Kindle. The rest of the series is not. Now, my wife does indeed own the rest. The true sign of my addiction is that I strongly suspect I won't read them. It's just too much trouble to read an actual book.

Now understand that we have piles of bookshelves full of dead trees. When we finished our attice, we lined a room with bookshelves and we've almost filled those up.

But jeez reading that way seems like a lot of trouble.

Fraser Speirs:

What you’re seeing in the industry’s reaction to the iPad is nothing less than future shock.

For years we’ve all held to the belief that computing had to be made simpler for the ‘average person’. I find it difficult to come to any conclusion other than that we have totally failed in this effort.

The iPad bashing reminds me of how hardcore gamers made fun of the Nintendo Wii near its release. Nintendo made a game system for non-gamers, and there are tons more of them than folks who care about polygons, shaders and fps. Nintendo made serious money on that system, and continues to do so because for every serious gaming enthusiast, there’s about four people who just want to play virtual bowling with their friends.

Case in point: my step-mother. She would love the iPad. As far as I know, all she has every used her computer for are the following tasks:

• Play solitaire (or some game like it)
• Read her email
• Browse the web

I don’t doubt there are many other people whose requirements for a personal computing device are about as pithy.

Yesterday I attended my first TriZPUG meeting to check out Kurt Grandis‘ talk on Fabric, “a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.”

It was pretty cool to see a bunch of guys who share the same interests take some time on a Thursday to hang out, drink beers, and chat about python, django, zope, and other stuff. After the original talk was over and some of the other lightening talks that succeeded it was over, a couple of things became very clear to me:

• There was a real need to make it easier for system administrators and OPS people to handle the difficult task of deploying and maintaining systems, cloud or not;
• Some of the tools and/or tool implementations presented were being used in an attempt to minimize this pain, but you were still pretty much had no control over what made its way to the systems in the end of the process;

Having been using rBuilder Online to manage and maintain my Transifex Appliance, and being somewhat “spoiled” with the ability of having fine grained control over the entire software stack and having the option of deploying my final “product” on several different cloud environments, I couldn’t help but offer to speak a bit about my experience. I sure hope my impromptu presentation didn’t come across as being “just a sell’s pitch” and I definitely tried my best not to sound like I was selling something. I truly feel that the technology developed here at rPath can solve many of the typical issues that people have getting their product through the many different life cycles and eventually out the door and into the hands of their customers!

Today I started going through Fabric’s documentation and am already making plans to include it in some of the test automation tools we’re developing here!

Anyhow, after my presentation there was a quick intro to epdb, the “Extended Python Debugger”, a very cool python debugger developed by an ex-rPathian and something I use on a daily basis! Turns out that the epdb currently packaged for Foresight Linux was outdated, so I spent a few minutes during my lunch today to update it. If you’re running Foresight, just run conary update epdb=:2-devel or wait for it to make its way to the stable label. If you’ve never heard of epdb, I strongly suggest you give it a try!

I’m working on building an HTPC based on Foresight and xbmc/boxee using Conary+rBuild. I could really use your help.

It’s called Tapatio. If you are interested in lending a hand with packaging, etc. please let me know by joining the mailing list.

Thank you.

So I did some digging around after giving my off-the-cuff lightning talk at TriZPUG tonight and it looks like some other ex-rpathers (Thanks Dugan and Gafton!) have forked epdb. There's also the the rPath tree synchronized from here but this tree is missing some of the latest changes. The dugan tree is "python setup.py installable" now, instead of using make, and some shortcut documentation has been created, so I don't have to make this post as long as I thought I was going to have to.

For those who didn't see my little demo, epdb is like pdb (the standard Python debugger), but it adds multi-line text input, history and tab completion, nested debugging from the debug prompt, shortcuts to introspecting code, and a very nice post mortem debugger. Last, but not least, it also contains a server and client for remote debugging. The docs are still pretty sparse, but hopefully more attention can help fix that. I'd also be happy to answer questions about it.

rBuild 1.2.1 is a maintenance release.

Bug Fixes:

• The product definition facade no longer uses the internal BaseDefinition class. (RBLD-289)
• The RbuilderClient class is kept around for backwards compatibility, and the _getRbuilderClient internal method has been made backward compatible with the earlier interface. (RBLD-290)
• searchPath entries without a troveName specification in the product definition are considered label search paths, and properly handled, both by the conary and the rmake facade. conaryfacade's internal _findPackageInGroups method was renamed to _findPackageInSearchPaths, to clearly indicate that packages are looked up on labels too. (RBLD-294)
• A dependency on urllib internals that is not consistent between Python versions has been resolved; previously, some successful calls to rBuilder resulted in errors. (RBLD-295)

Over at TPM, a longtime reader and former Republican Hill staffer takes the pulse of Obama and our current Congress and concludes that

This isn’t an argument about the merits of policy. It’s all politics. Ask yourself, is it easier to pass a difficult, complex legislative agenda when the country is under stress if the opposition party is seen as the Party of Bush, or if the opposition party is able to begin redefining itself as the party of populism, or of un-Washingtonism, or of fiscal restraint? Give the opposition party a fresh start, for free, and you’ve bought yourself all manner of trouble. That’s really the only transformative development Obama has presided over so far. (emphasis mine)

This is exactly why many of my Republican friends call themselves “conservative” instead of Republicans. This is why Michael Steele bumbles around begging the base to “come back” to the party fold. This is why Sarah Palin continues to be popular in spite of all her flaws. This is why Massachussetts voted Brown into office. This is why 2009 was the Summer of the Teabaggers.

Once the taint of eight years of Republican rule presided over by possibly the worst president in history is removed from the political petri dish as well as the American people’s collective memories, the culture of populism grows fast and furious into the strain of “conservative” that exists today. Not a new GOP, but something else entirely. Something that reflexively says “no” to everything proposed by the Democrats, no matter how reasonable or “bipartisan”.

We cannot live like this forever.

Just wanted to tease you guys out there about a new feature that the Transifex guys are working on these days: Translation Reviews! Have you ever wandered if your translations conform to the standard vocabulary that your team uses? Have you ever wanted someone to take a look at what you’ve done before sending in your final work for commit approval?

From Transifex v8.0 featutes

Now, mind you this is still very alpha code but that is probably a good thing since you can play with it and give your feedback on how to improve it. As always, you can get this in an easy to consume format by using the Transifex Appliance Developer edition… or you can join the Xfce translators who are already enjoying Transifex latest code!

Don’t let Ted Kennedy down.

In case you’ve missed it, the Xfce project has been using their own installation of Transifex to manage their translations online! Translators can now visit http://translations.xfce.org and keep up with the action!

From Transifex v8.0 featutes

I’ve been contributing with translations for the Brazilian Portuguese language for quite some time now, and have been a strong supporter for the Transifex project as well, so I was thrilled to learn they were “working together”! But there is a second reason why I’m mentioning this on my blog:

Turns out that Nick Schermer, maintainer for http://translations.xfce.org, is using my Transifex appliance too!!! Moreover, he chose to use the appliance built from the development branch to get the very latest bits being committed to the development branch of Transifex. It has been a win-win-win (yes, 3 times!) relationship so far for all parties involved, for:

• Xfce gets a ready to run, batteries included, Transifex appliance with all the latest and coolest features without having to build things by hand.
• Transifex gets tons of excellent feedback for this version still in development and work out all the kinks before the next release.
• My appliance has also enjoyed of tons of excellent feedback and is now more robust and ready for consumption.

From Transifex v8.0 featutes

Some of the cool features that you can expect from the next version of Transifex (and that the over 200 registered Xfce translators are already enjoying) are:

• Better support for Lotte, the online translations editor, and the removal of the 100-strings limitation;
• Automatic translation suggestions within Lotte;
• Support for translation teams;
• New timeline history for tracking contributors, teams, and projects activities;
• Top Translators “hit list” for your bragging rights

From Transifex v8.0 featutes

The Transifex Appliance (developer image) has been updated almost on a daily basis, so those out there already using it can keep it updated using the web based appliance management tool or running conary updateall. As always, you can expect a stable release the very same day that Transifex releases the upcoming 0.8 version! I’d love to hear from all of you appliance users out there. Just drop me a line or a comment here and I’ll do my best to improve your experience.

Conary 2.1.4 is a maintenance release.

Bug Fixes:

• A redundant check that could trigger an assertion error in the lazy cache code has been removed. (CNY-3331)

Conary 2.1.3 is a maintenance release.

New Features:

• Conary now stores RPM obsolete information as troveinfo data. (CNY-3328)

Bug Fixes:

• Building rpm capsules properly eliminates dependencies in the RPM namespace that are also discovered by Conary. (CNY-3318)

conary-policy 1.0.27 is a maintenance release.

• All destdir policies have been audited, and modified as necessary, to correctly handle capsules, in preparation for enabling destdir policies for capsules. (CNY-3320)
• The new WarnScriptSharedLibrary policy looks at capsule scripts for possible instances of modifying the ld.so.conf, when used with Conary 2.1.2 or later. (CNP-185)

Conary 2.1.2 is a maintenance release.

New Features:

• Conary now runs all destdir policies for capsule packages. Previously, it disabled destdir policies to avoid unintentional modification; now all destdir policies should take capsules into account and some destdir policies are required. (CNY-3320)
• Scripts from capsules are now written as files that are not packaged but are available for inspection during the packaging process, and policy can investigate script files. (CNY-3321)

Bug Fixes:

• Committing relative changesets with multiple specifications for a single fileId no longer causes a repository traceback when those specifications are part of different troves. (CNY-3316)

Our friends Gwenn and Nick Mangine are houseparents for an children’s home in Jacmel, Haiti and were there when the quake struck. They have a blog, and have been reporting on the aftermath. CNN even interviewed the Mangines and used their photographs for a story on Jacmel.

I recently released a plugin for XChat-GNOME (and XChat) which adds support for the messaging menu in Ubuntu. This was a fun little side project of mine, I use xchat-gnome very heavily and have really been craving integration with the messaging menu.

When I started working on this, I wanted to make sure it was a standalone plugin that didn’t need to be built inline with xchat sources and didn’t require changes to xchat. In the process I ran accross a couple pieces of the XChat plugin API that hadn’t been implemented in xchat-gnome yet. This meant of course I needed to patch xchat-gnome, and send those patches upstream.

Both of these were trivial changes to xchat-gnome, and I didnt expect any problem getting them accepted. I had to implement the “GUI FOCUS” command which has been merged already (bug).   And I had implement the win_ptr argument to xchat_get_info, which lets the plugin get a pointer to the GtkWindow (bug).

Overall I am very impressed with the plugin API for XChat, it is really awesome to be able to get access to the GtkWindow.

If you are running Lucid or Karmic, you can install it from from my xchat-gnome PPA:

sudo add-apt-repository ppa:ken-vandine/xchat-gnome
sudo apt-get update
sudo apt-get install xchat-gnome-indicator


If you use xchat instead of xchat-gnome, just change the package name in that last command:

sudo apt-get install xchat-indicator


To get the source, file bug reports or feature requests, check out the project page on launchpad.

Technically, I haven't owned a portable computer of my own until now. Sure, I've had work-issued laptops for the last few years, and I've borrowed laptops from friends from time to time. When I bought my mom's Asus EeePC, though, it was the first time I'd had one I could call mine. Everything else I own is a desktop system. :-)

For my Computer Science programming coursework at NCSU, I can easily do assignments at my desktop systems or from one of the campus computer labs. Once in a while, though, I'd like to grab a portable system and go somewhere else. I could use my work-issued MacBook, but if anything happens to it while I'm using it for something other than work, I could be held responsible for its replacement. Plus, even though it isn't but a 13" MacBook, it's still a little bigger than I want to haul around with me.

The EeePC had Xandros pre-installed, and I really like it. However, I didn't want the launcher. When I tried installing the advanced-mode Xandros, I was excited because it had the look and feel I wanted. Unfortunately, any minor change in software bricked the system. I gave up on Xandros after about half a dozen repair installs.

Having participated in the Foresight Linux project for some time, my next instinct was to try installing Foresight Linux Mobile Edition. After all, I have friends and colleagues that have used the EeePC and other netbooks with FL Mobile with much success.

I loved it... but I needed to customize it to my needs as a Java programmer.

My first instinct was the fall back on my Conary system building skills and use rBuilder Online to build a custom one-off of Foresight Mobile. However, the package structure was significantly different in some ways, and I didn't want to spend a lot of time figuring out how to make the system into a Java programmer's toolkit. So, I decided just to use my Conary system administration experience and add and remove packages until I had the system I wanted. Later, if I wanted to, I could capture this list of packages and create a "backup" system image of sorts using rBuilder Online.

For the following process, I used a combination of the Alt+F1 tty and runlevel 3 to drop to a command line as needed. I also made sure sudo was configured (in /etc/sudoers) so I could use it without providing a password.

I started by removing the launcher, which was included as a dependency of the desktop switcher:

$> sudo conary erase desktop-switcher
$> sudo conary erase netbook-launcher

Then, because I wanted to control my software at a command line instead of using the GNOME Package Kit tool, I removed the package kit:

$> sudo conary erase packagekit

Because I wanted to conserve space, I also removed some applications that I knew I would not use on this system. Most were modestly sized, so I probably could have done without removing them. (Browse the application launcher in the default GNOME install to see what GUI applications are installed, and determine which you want to keep and remove.) Here are the erase commands for the ones I removed:

$> sudo conary erase f-spot
$> sudo conary erase banshee
$> sudo conary erase pidgin

At this point, I was still using 58% of the 4 GB solid state drive. I considered replacing GNOME with xfce to save even more space and further reduce processing overhead. For now, though, I'm sticking with GNOME for familiarity's sake, and it seems to be running efficiently so far.

Next, I had to add my programming tools for Java. First, I needed the JDK for Java 6 (aka 1.6), which also brings in the JRE as a dependency:

$> sudo conary update sun-jdk

The install took a few minutes on the Eee PC. Stopping to check my disk space after the update, I was up to 68% used of my 4 GB. I wasn't concerned about room for my data, since I had an 8 GB SD card mounted at /data, ready for my programming work. However, the percentage made me doubtful I'd be able to install and use Eclipse as my IDE. I decided to give it a try, anyway.

I first tried installing just the runtime component (eclipse-sdk:runtime), but when I launched the application, it said it was missing some necessary jar files. Then I installed the eclipse-sdk package as shown here, which also brought in its dependencies: an earlier build of OpenSSL's library component, the Java components for Xalan and Xerces, and Python's runtime and library components:

$> sudo conary update eclipse-sdk:runtime

This install took less time, and it bumped me to 75% of the solid state drive used. I was happy I had the tools I needed installed, and decided the next item of business was to evaluate performance of Eclipse as my Java IDE on the Eee PC with my customized Foresight Mobile.

Before I did anything, I rebooted the system and confirmed everything was still in working order. Everything was fine. Yay!

Before I launched Eclipse, I wanted to set up a workspace directory on the 8 GB SD card. I wanted to be sure my Eclipse work was stored there instead of in my home directory on the solid state drive. I changed to root, changed the owner on /data was mounted, and made sure it was mounted correctly in /etc/fstab. Then, I created a directory there named eclipse-workspace-java6.

When I launched Eclipse, in the "Select a workspace" dialog, I pointed to my new /data/eclipse-workspace-java6 directory. The splash screen since everything is set to be full screen by default (it tiled instead of expanding). The view was the same as using Eclipse on any system, but it seemed to take up a lot of space. I'm sure I'll continue customizing the look and feel from here until it's like I want it.

As I've done a little bit of sample coding, I've noticed that Eclipse seems to work great on my EeePC. I haven't pushed the limited to see how it runs alongside Firefox and other programs, but I'm confident I at least have the Java Programmer System I was looking for.

On his latest post titled “Foresight Linux is dead?“, Thilo Pfennigs rightly asks the question that many of the current Foresight Linux users may be asking themselves. With the current stable release dated as of May 2009 and no explicit roadmap stating when the next release will be published, is it really safe to say that Foresight Linux is indeed dead?

In order to properly answer this question, one must first take a look at what the year of 2009 reserved for this young distribution. Born out of Ken Vandine’s desire to follow the GNOME project as close to the upstream source as possible and introduce all the latest and coolest applications out there to the desktop before anyone else, Foresight was for a while synonymous to bleeding edge Linux done right!

Powered by the revolutionary Conary package management system and a small but talented and determined crew of developers, Ken was able to ship a new version of the distribution the same day that a GNOME release was published, a feat that no other distribution was able to keep up, even those enjoying of large hordes of developers and user base. Foresight was the first distribution to include several trend setter applications out there to the default installation, such as Banshee, F-Spot, Tomboy, Gwibber, Pulse Audio, PackageKit, among many others! And since the distribution followed a rolling release cycle, users did not have to wait for a major release in order to get the very latest bits.

Even if DistroWatch’s numbers weren’t impressive, those who took the time to test drive the distribution fell in love with the community, package selection, and most likely the possibilities that the underlying Conary technology provided for those inclined to do a little packaging or package maintenance. If you were a GNOME user/fan and didn’t mind the small sized, hand picked repository of supported packages, then you’d probably feel right at home! Sure there were KDE, Xfce, Fluxbox, Openbox packages available but those were mostly supported by some of the core users who didn’t mind doing the heavy lifting.

Then came 2009 and with it the major financial crisis the shook many companies around the world, creating a massive layoff wave for most of the first quarter. Sadly, approximately 75% of the active developers that comprised Foresight’s core developer base were part of the many casualties, including Ken Vandine, the heart and soul of the distribution! By late February these developers had already joined the ranks of companies such as Red Hat and Novell to do package and kernel management. Ken himself was quickly nabbed by Canonical to join their Desktop Experience Team, concluding then the completely dismemberment of the seasoned Foresight team!

Deprived of its core developers who were now devoting their time to working for their respective new companies, Foresight’s run at being a bleeding edge distribution and being able to keep up with the release schedules of GNOME (and all of its dependencies) quickly spiraled down toward what looked like certain doom. António “Doniphon” Meireles, second in charge of the distribution and holder of all the knowledge related to how all parts worked together became the sole guardian and maintainer of all packages. Have you ever tried to sync up and maintain all the modules that make up the X.org stack by yourself? How about making sure that every single package in the repository is properly compiled and linked to a newer version of Python?

Unfortunately for many of our loyal users expected point releases stopped from happening on time and deadlines were never met. Having been using Foresight Linux as my primary and only distribution for the last 3 years, I myself started to wonder if 2009 would mark the end of it all.

It took a few months for the remaining developers and users to get over the deep scars left from the massive exodus suffered early last year, but our user base proved to be very resilient and new developers stepped up to fill in the gaps. António was still doing the heavy lifting but this new crop of developers took upon themselves to bring the distribution closer to its former shape.

Slowly but surely milestones were achieved and the development branch eventually caught up with the latest GNOME packages. As of 2 weeks ago the development branch was pretty stable and I believe that only a few minor issues with PolicyKit were blocking a new release. Some massive work has also been done to pave down the way for Foresight 3.0, a major move that will allow for a more modular platform that can be used to derive other distributions, leveraging the flexibility and functionality provided by Conary. Moreover, the “Boots” project was kicked off to bring a Fedora based distribution completely managed by Conary, which should free up the time our developers spend maintaining some of the more complex stacks of the operating system and let them focus on making your desktop “freaking cool!”

So to answer the original question posted by Thilo, “is Foresight Linux dead?” I can gladly say “Far from it!” I predict that the Foresight community will rally together in 2010 to get back to being the most GNOMEic and bleeding edge distribution out there! As the Foresight Community Manager I can honestly say that we have always been and will always be a niche distribution! We don’t have the man power that distributions such as Ubuntu, Fedora, Mandriva or OpenSuse have to provide the same level of documentation or user support. We obviously cannot afford to have the same depth of package variety in our repositories or  claim to have the expertise and time to resolve all issues that manage to get filed in our tracking system. But I can guarantee one thing: Foresight is here to stay!

If you want to try a revolutionary package management system and want to be part of a an exciting crew, come hang out with us on #foresight at Freenode. We will help you get started and I promise you that you’ll be able to contribute in no time.

Expect great things from Foresight Linux this 2010!

Thanks to Chris Calloway, TriZPUG has a planet now. I don't know why it's taken me so long to connect with this group of people (I've been working with Python for 5 years now), but it's a pretty cool group from what I've seen so far. Thanks for making me (a TurboGears guy) feel welcome among all you Zope/Plone/Django developers.

I spent the weekend, and Monday, and some of Tuesday, in the Virginia mountains. It's only about 3500' above sea level and really doesn't get that much snow. This weeks storm was a complete exception though. We made it up after a harrowing drive through driving snow (plows and salt were no match for it), and woke up to about two feet of snow on the ground. The snow kept falling until the early evening, for a total of around three feet. That is a lot of snow.

The driving wind kept up for a few more hours, and we woke up to clear skies on Sunday morning. We also woke up to massive snow drifts. Think six foot high snow drifts about four feet thick. My driveway was completely drifted in (which mattered very little given the condition of the roads). Fortunately, most of the people I was with were skiers and had easy slope access (where easy means trudging through waist high drifts for about ten feet).

Eventually we had to get to work on the driveway though. The driveway is heated, so the parts which weren't covered by drifts stayed somewhat clear. Here's a picture of what the rest looked like (the angle makes the drifts look a little smaller than they were; the tops were easily above my Mom's head).

This post should have be written a few months ago. xobj has been made available as open source on bitbucket

The xobj project provides an object reflector between various dynamic languages and XML. Currently, python and ActionScript 3 implementations are available.

Motivations

xobj was motivated by a few specific goals:

• Make the use of XML for object model interchange between client and server tiers less painful
• Allow your code to use real typed instances of classes rather than simple generic data structures
• Treat your code as the definition of schema rather than forcing an XMLSchema driven approach on your code.
• Read and write XML documents that will pass most XMLSchema structural validation requirements with relatively little effort on your part

It is not required to provide an XML schema to use xobj. Custom objects may be used for parts or all of the document, whether or not an XML schema is provided. Schema validation is optional. If new elements show up, they will be preserved across read/write; schema additions will not normally require code changes.

Implementation Notes

During XML decoding, xobj preserves namespaces, element ordering and tracks attributes vs elements so that re-encoded object graphs can comply with most of the common XMLSchema validation requirements. This observed metadata is attached to your object graph rather than hidden out of view.

For "whole cloth" generation of XML from object graphs that were not themselves decoded in the first place, you can provide the namespace, elements ordering and attribute metadata declaratively to facilitate XMLSchema conformance.

20 years ago, on this day, Romania’s president at the time, Nicolae Ceauşescu, fled under pressure from the large popular uprise which we call The Revolution.

Three days later, they were executed, after something that pretended to be a trial. Over the past days, a Romanian newspaper ran the timeline of the events, tracking the movements of Ceauşescu and his wife. The trial was filmed, and it exposed the truth about “revolutions”: in order to gain legitimacy, both for the Romanian people and for the foreign governments, they needed to show there was a trial. They also needed the former president executed, partly as an attempt to stop the attacks from terrorists (special forces allegedly trained by the former president as elite units that would protect him) against the population and the military forces.

20 years later, said terrorists are still nowhere to be found. The attacks were just various branches of the military not knowing what to do, and pulling the trigger against each other.

20 years later, the goal of the trial is ever more obvious: the new political class (which was really not that new to begin with) needed no roadblocks from the old president; they wanted the president eliminated, and they came up with a plan that would help their recognition from the rest of the world as a legitimate government.

The accusations against Ceauşescu were not sustainable in a real court. 20 years tend to erase some of the bad memories from the terrible times of his reign, so I may be missing a lot of the details about how bad it used to be (and, believe me, communist Romania was bad). But the new political class decided that the ends justify the means.

In the end, I personally believe that people give the institution of presidency too much credit. (And this applies not just to Romania, pre or post December 1989). I believe Ceauşescu was being presented with a very rosy picture about Romania, by the people around him, some of them who eventually were the ones to kill him. He was an old man, some argue he was senile, and the powers behind the curtain liked the status quo, until it became non-profitable. He was merely a symbol – the symbol of the extreme-left communism, in a Europe that was trying to get rid of the East-West separation. He probably truly believed in his ideas, completely oblivious to the real economic and social facts. His ignorance could be blamed on his age or medical conditions, but I would much rather blame it on his entourage that handled the smoke and mirrors.

December 22, 1989 – I remember that my parents were coming back from a visit from my grandparents, and I was home, alone, vacuuming and cleaning up for Christmas. And, for some unknown reason, I turned on the TV. This makes very little sense now for me, just like it probably does not make any sense for you – but we were only having 2 hours of TV per day, and most of it was just news anyway. There usually was nothing (as in no signal) on a Friday morning. And yet, there he was, talking about something I did not pay attention to. And then the audience (which was normally cheerful and would acclaim him after each sentence) started booing him. That was unheard of! An hour or so later, when my parents came home, they would not believe me.

And from that point on, Romania was glued to the TV – the same thing we all ignored for the most part until that day.

Having not posted since September, I thought it interesting that my new post today is related to my previous post. Basically, I had to get really comfortable finding and installing Python modules, and fixing issues with the installs, so I could make the script run on my local system.

One big thing I had to have (to run JIRAnemo) was SOAPpy, which was apparently called "SOAPy" (with one "p") until about 2003, and which hasn't had a new release since 2004 (stable) and 2005 (release candidate). Also, the dated documentation for SOAPpy is accurate in what you need, but out-of-date in its links to where to get it.

In hopes of helping those of you out there who are trying to get SOAPpy running, especially on Mac or Windows, here's the information about what I did on my Mac OS X Leopard install:

(1) Update your Python to 2.6.x (optional):
    (1.1) Download the newest Mac installer disk image for 2.6.x from:
        http://www.python.org
    (1.2) After installing the package, verify the command line the
        Python Launcher (under Applications/Python 2.6/ i=on the Mac)
        wants to use by default, such as: /usr/local/bin/pythonw
(2) Install the Python module pyXML:
    (2.1) Download it from:
        http://pyxml.sourceforge.net/topics/download.html
    (2.2) Unpack it, change to its directory, and install it to your 2.6.x version of Python:
        $> /usr/local/bin/pythonw setup.py install
(3) Install the Python module fpconst:
    (3.1) Download it from:
        http://pypi.python.org/pypi/fpconst/
    (3.2) Unpack it, cchange to its directory, and install it to your 2.6.x version of Python:
        $> /usr/local/bin/pythonw setup.py install
(4) Install the Python module Web Services for Python (ZSI)... may not need this, but I installed it anyway:
    (4.1) Download it from:
        http://sourceforge.net/projects/pywebsvcs/files/
    (4.2) Unpack it, change to its directory, and install it to your 2.6.x version of Python;
        use "sudo" to pass permissions to install to /usr/local/bin/:
        $> sudo usr/local/bin/pythonw setup.py install
(5) Install SOAPpy:
    (5.1) Download it from:
        http://sourceforge.net/projects/pywebsvcs/files/
    (5.2) Unpack it, cd into it, and install it to your 2.6.x version of Python:
        $> usr/local/bin/pythonw setup.py install
    (5.3) For each file that Python reports that the "__future__" import line needs to
        be at the beginning of the file, make that adjustment, and rerun the install.
        Repeat this process until the install completes successfully.
(6) Install lxml:
    (6.1) Download it from:
        http://codespeak.net/lxml/index.html#download
    (6.2) Unpack it, cd into it, and install it to your 2.6.x version of Python:
        $> usr/local/bin/pythonw setup.py install

Saw this last night on one of the local TV stations: “Happy Holiday’s!”

I’m sorry, I meant, on one of the local TV station’s. Because noun’s should have apostrophe’s.

Conary 2.1.1 is a maintenance release.

New Features

• Added repair command as an experimental feature. (CNY-1800)
• Files marked as "missingok" in encapsulated RPMs now have that status represented by a "MissingOkay" flag on the corresponding Conary file object. (CNY-3306)
• Files from encapsulated RPMs now have the mtime from the RPM recorded in troveInfo. The mtime of last change is still used to calculate fileIds, preserving knowledge of when meaningful file information has changed. (CNY-3307)
• Added support in verify and update paths for prelinked binaries. (CNY-3298)

Bug Fixes:

• Changeset reassembly for capsules ignores directories. (CNY-3305)
• Encapsulated symbolic links are represented as having the mode that will exist on the filesystem, even if that varies from the mode recorded in the capsule. (CNY-3304)
• Previously, getTroveLeavesByPath() didn't return leaves; it returned the most recent trove which includes that path. It now returns only leaves (most recent versions) that include that path, and if the path is only included in older versions, no troves are returned. (CNP-184)

Internal Changes:

• Database connection objects now have a close_fork() method that closes the connection without notifying the server.

Conary 2.1.0 is a new feature release.

New Features

• Conary now allows packages to be installed using foreign package managers via wrapped content called capsules. RPM capsule support is included in this release. (CNY-3217, CNY-3213)
• Added ignoreDependencies configuration option, which allows users to specify certain dependency classes which should be ignored during installs. The default is "abi rpmlib".
• The xz compression file format is now supported for decompressing sources. (CNY-3207)
• The changemail.py repository commit action module now takes an optional --maxsize argument and truncates changemail messages to fit. (CNY-3205)
• The Run build action now does path-based build requirement discovery like most build actions. (CNY-3222)
• Conary now allows identical files to be shared during installs and updates. Both troves own the shared files, and they must be updated at the same time when the shared files change.
• Conary now honors the no_proxy environment variable to allow direct connections to specific hosts and domains. (CNY-3246)
• Added excludeCapsuleContents config option for servers.
• Added ChangeSet.removeCommitted() to filter already-committed troves from a changeset.
• The bootstrap python module dependency discovery proxy now provides additional useful informational messages to aid debugging.
• Conary proxies are responsible for reassembling the content for changesets containing capsules. (CNY-3228, CNY-3259)
• The --capsules command line option modifies showchangeset, repquery, and query commands to display file information for capsules instead of for installed files.
• A new Conary proxy setting, injectCapsuleContentServers, controls changeset content injection for proxies talking only to hosts in this list. (CNY-3261)
• Conary no longer uses regular expressions to represent manifest files and other internally-generated lists of files matched by policy, and so will not raise OverflowError for manifests with many files, or from policy generated from source objects, on platforms with a restricted regular expression code size. (CNY-3282)
• The python dependency finder client has been modified to resolve incompatibilities on the client side with python 2.3. (CNY-3285)
• Conary can now read cpio archives directly. (CNY-3280)
• The Conary repository now provides a method for obtaining commit progress updates. "conary commit" now provides progress output. (CNY-3290)

Build Changes:

• When cooking groups where checkOnlyByDefaultDeps is set to False, added dependencies will now inherit the byDefault setting of the depending component. (CNY-3195)
• The imageGroup flag in group recipes now implies checkOnlyByDefaultDeps=False. (CNY-3195)
• Group search paths may now contain lists or tuples of troves to be considered as a single "bucket". (CNY-3286)

Bug Fixes:

• In-core changesets previously could be merged only once into a ReadOnlyChangeSet. After multiple merges, reset() previously failed to reset the underlying in-core changeset. This has been fixed.
• Conary no longer exits with an unhandled KeyError exception if an unknown dependency type is encountered in the local database. (CNY-3232)
• Decompression with xz is preferred over unlzma, as CNY-3194 intended. (CNY-3231)
• rpm2cpio now correctly handles rpm packages compressed with xz. (CNY-3234)
• Unpacking an RPM with addArchive or addCapsule now functions correctly even if the CPIO archive in the RPM contains a non-traversable directory. (CNY-3244)
• When running an external entitlement generator, use /dev/null for stdin instead of closing the file descriptor.
• Added logging to several source actions to ensure that some output is provided to make debugging build failures easier.
• Call lstat() instead of stat() to deal with circular links. (CNY-3251)
• Bootstrapping python dependencies now uses python source intead of a version-specific compiled python file.
• The addCapsule source action properly verifies GPG keys when a keyid argument is supplied. (CNY-3258)
• Commiting signed troves to repositories without signatures no longer causes repository tracebacks.
• Repositories no longer store duplicate file path information when a path is committed for the first time by a job which references it multiple times.
• Replacing a symlink with a regular file no longer creates the regular file as the target of the symlink.
• Local rollbacks properly restore file contents when the file was replaced by a non-regular file (such as a symlink)
• Cooks will no longer block indefinitely if a subprocess forks and does not exit. (CNY-3284)
• When startGroup is called, flags will now be properly copied from the parent group. (CNY-3287)
• Replacing a symlink which was part of a loop no longer causes a traceback.

Internal Changes:

• A repository's internal getfile function now avoids any database access when no files have been requested.
• Loading troveinfo data uses bulk operations, speeding up repository commits.
• Committing changesets now iterates over troves the changeset is relative to, rather than getting them one at a time, significantly reducing the number of sql calls.
• Conary now uses a single call when validating that file objects exist in the repository during a commit.
• Repository commits now handle file paths and file streams separately, in order to reduce the size of the temporary tables and the commit path.
• The number of SQL calls used to create the flavors needed by a repository commit has been dramatically reduced.
• No-operation SQL calls during repository commits when no redirects are being commited were eliminated.
• Repository commits now merge all dependencies from the temporary tables into the final tables at once rather than once per trove.
• Repository commits now update permission tables for all new troves at once.
• Updates to latest tables are now done for all troves at once, and are based on the current latest entries and the new trove. Formerly they were done one at a time based on everything in the repository (through a view).
• The rpmhelper.Header object can now produce dependency sets that represent what an RPM requires and provides.
• A new RPM dependency class has been added. This class is used to represent dependencies expressed in RPM packages that cannot be mapped directly to a native Conary dependency.
• Colons in dependency flags are now escaped as \: to allow deterministic thawing.
• CIL dependency parsing uses xml.etree.ElementTree, if available, instead of elementree.ElementTree.
• The LDFLAGS setting is now honored when linking binaries.
• Trove and TroveChangeSet objects now represent paths as directory/basename pairs.
• Changeset dict of absolute file object changes are now indexed more efficiently.
• StreamCollection classes can now choose to ignore the skipSet when freezing for a performance boost
• Dirnames/basenames are added as a single operation at the beginning of a repository commit to make the ids available for the files build removing the need for large, complex joins later.

conary-policy 1.0.26 is a maintenance release.

• When "file:" requirements are not not explicitly met by "file:" provides but the path exists in a trove, the new ResolveFileDependencies policy replaces the unsatisfied "file:" requirements with "trove:" requirements. (CNP-184)
• The XinetdConfigRequires policy now creates file: dependencies instead of trove: dependencies by default, depending on the ResolveFileDependencies policy to change to trove: dependencies on platforms for which the /usr/sbin/xinetd path is not explicitly provided. (CNP-183)

conary-policy 1.0.25 is a new feature release.

• Policies have been made capsule-aware and assume that the capsule will handle essentially all operations involving files in capsules. (PFM-506)
• The RemoveBootstrapTroveDependencies policy removes trove dependencies that are not satisfied within the packages being built as a bootstrap because they may be computed against an incompatibly-named set of host packages. (PFM-506)
• The PHPRequires policy now reports adding dependencies. (CNP-181)

rMake 2.0.1 is a maintenance release.

Bug Fixes:

• rMake has been modified to be aware of Conary versions 2.1.x for compatibility with the latest releases of Conary.

rMake 2.0.0 is a new feature release.

New Features:

• The "multi-node rmake" build cluster capability has been moved from an externally-provided plugin into rMake proper.
• Multi-line macros in build job configurations will no longer cause invalid conaryrc files to be created inside chroots. (RMK-996)
• The rMake server process now retains the capability to chroot after dropping privileges. (RMK-999)
• When properly configured, rMake will grant capabilities to programs in the chroot as directed by a file within the chroot. (RMK-1004)
• The /dev/full device is now available in build chroots.
• rMake will now utilize the python interpreter specified in the first line of the /usr/bin/conary that is installed in the chroot, rather than always using /usr/bin/python.
• rMake will now make all files installed in the chroot accessible to the build user (RMK-1006)
• Multinode rMake servers can now use an externally-managed message bus. (RMK-1011)

Bug Fixes:

• Don't cast disk usage info to int, since it may exceed XML-RPC limit. (RMK-997)
• The chroot caching feature no longer records raw binary digests in the server logfile. (RMK-1005)
• Cache all uid/gid lookups from external user database. (RMK-1010)

rBuild 1.2 is a maintenance release.

New Features:

• The "rbuild rebase" command now prevents users from rebasing a product-definition to a schema version that is not supported by the project's rBuilder. (RBLD-249)
• The "rbuild checkout" command now takes a --template option which is ignored unless the --new option is also provided or implied because the package does not yet exist. (RBLD-118)

API Changes:

• A new experimental API, rbuild.api1, enables external consumption of rBuild by easily initializing an rBuild handle. This API is subject to change, including removal or entire replacement. (RBLD-238)
• Added support for rBuilder REST interface to rBuilder facade. (RBLD-249)

Bug Fixes:

• Conary 2.0.40 introduced a fix for another bug that caused rBuild to no longer honor the "--debug-all" argument and not write tracebacks to the .rbuild/tracebacks/ directory; rBuild has been modified so that these features will be restored with Conary version 2.0.44 and later. (RBLD-230, RBLD-234)

In order to better follow what the Transifex guys are doing with their development and deployment of Transifex.net, I have finally made the switch from MySQL to PostgreSQL for the Transifex Appliance. Luckly I was able to corral diegobz during my lunch break and together we worked out the necessary changes to get things to work (and caught and fixed a minor issue along the way too!).

In the meantime, the appliance seems to be getting some nice and steady traffic, which I suspect will only increase, specially when a new version of Transifex hits the streets.

One of the cool new features you can expect is the addition of Translation Teams, yet another way to manage who has access to translate your project! Want to play with this new feature and also be the first one to test the new PostgreSQL addition? Download the Transifex Developer Kit today!

A little while ago I built the amazon mp3 downloader for Foresight. Well, amazon decided to have some more free albums today, and my wife (and kids) like Christmas music, so I went to grab them. Doing so made it blindingly obvious that my wrapper script should have passed the command line arguments onto the application itself.

A "conary update amazonmp3" will get you a version which is better integrated with firefox, and a "conary update amazonmp3=oot.rpath.org@fl:2" will get it for you if you haven't already installed it.

I’ve already mentioned on my Twitter account about our latest feat here at rPath, namely, “rPath Expands Operating System Coverage with Red Hat Enterprise Linux 4 and 5.” But the more I play with our technology, the more gaga I get at how simple we can make things!

So today I built a plain vanilla appliance based on the Red Hat Enterprise Linux Server 5 with just enough operating system and launched it on VMware vSphere 4. I then ssh’ed into this system and ran:

[root@sweet ~]#: conary update httpd
Including extra troves to resolve dependencies:
apr-util:rpm=1.2.7_6-1-1 apr:rpm=1.2.7_11-1-1 mailcap:rpm=2.1.23_1.fc6-1-1 postgresql-libs:rpm=8.1.4_1.1-1-1
Applying update job:
Install apr(:rpm)=1.2.7_11-1-1
Install apr-util(:rpm)=1.2.7_6-1-1
Install httpd(:rpm)=2.2.3_6.el5-1-1
Install mailcap(:rpm)=2.1.23_1.fc6-1-1
Install postgresql-libs(:rpm)=8.1.4_1.1-1-1
[root@sweet ~]# service httpd start
Starting httpd:                                            [  OK  ]
[root@sweet ~]# rpm -q httpd
httpd-2.2.3-6.el5

In case you missed it, I used conary to install the httpd RPM and the entire system is being managed by conary but compliant to what rpm expects! Christmas did come early this year!!!

I am back from Toronto and it was much warmer there than Dallas today. Fudcon was a great conference, even though the wireless infrastructure was not up to the task at the hotel or the conference site. Some points of interest:

- Attendance was great, and a massive number of talks were pitched for the barcamp.
- It was nice to get some face time with a number of people I don't normally see, and meet quite a few new people.
- There was a healthy interest in virtualization in general.
- Getting Fedora releases on EC2 is a priority, and there are a number of people excited to both use Fedora on EC2, and help us get it there.
- We have a lot of work to do for F13.
- Cynar (artichoke liqueur) is just as bad as it sounds.

All in all, the event was a success, with a great turn out and discussion. Thanks to those who put in a lot of time and effort to organize things and make sure it ran as smoothly as possible.

Had some time today during lunch to work on the Transifex Appliance and decided to play with the newly added feature of supporting subversion over https. So I launched the devel EC2 instance on Amazon Web Service and proceeded to add PCMan File Manager so that I could translate it online. Before you ask, yes: I do have commit access to the project and could have checked out the code locally and done the work as I usually do, but that’s not fun! Besides, being the good citizen that I am, I felt like testing this new feature (remember: this is only available on tip!) and providing some feedback.

After updating my appliance to run the latest code, I took a stab at trying to add PCManFM as a project and see if I could then work on trunk code. To make a long story short, the code did not play well with subversion repositories with invalid ssl certificates, and it fell flat on its face. A quick look at the Transifex log files via the appliance’s administrative interface, I was able to ping diegobz on #transifex and with a very subtle crack of a whip got him to look into the problem.

We then proceeded to test and validate some of the changes he made on the spot, and once we got it right, I updated the appliance to use the new code. From then on, it was a matter of creating the project:

Add the proper information to pull code from trunk (I set the Root attribute to https://pcmanfm.svn.sourceforge.net/svnroot/pcmanfm/trunk/ by the way):

Configure it for submission directly to the upstream project (I could also have chosen to send it as a patch via email to the mantainer):

And start working on my translations using the handy dandy Lotte editor:

A few minutes later I was submitting away my translation and getting it committed automatically to the upstream project! This is how translations should be done by the way: working directly with the upstream project.

The only time I had to ssh into the appliance and do manual configuration changes was when I entered my subversion credentials for SourceForge (that’s where PCManFM’s code is hosted) into the /usr/share/transifex/settings/80-vcs-extras.conf file. I added the following line and restarted the apache server:

SVN_CREDENTIALS = {’sourceforge.net’: (‘MY_SF_USER_NAME‘, ‘MY_PASSWORD‘)}

Yeah, I shouldn’t have to ssh into the appliance but I have bugged the Transifex guys about this and am trying to convince them to make this part of the project configuration process… It’s only a matter of time ’til they crack!

Anyhow, there’s some pretty cool new features scheduled to come out with the next release, like granular commit access…

… so, if you want to play with the latest Transifex code, make sure to download the Transifex Appliance Devel images and always keep it up to date using the web based administrative interface. If you’ve never used it, just point your browser to the appliance’s IP address but make sure to use https and add port 8003! For instance, https://ec2-75-101-171-187.compute-1.amazonaws.com:8003 *

* don’t bother trying this url for it will be shutdown soon

As always, feel free to ask me anything related to the appliance, and file issues and/or send your thank-you notes to the Transifex guys!

Pithless Thoughts: “It looks like ‘immigration policy’ has finally trumped Jesus Christ as the ‘reason for the season’.”

I have no words for this. However, it looks like the Salvation Army of Houston may have had an epiphany:

Families signing up their children for the Salvation Army’s Angel Tree program in the Houston area will no longer have to give a Social Security number.

Good on them, but they should have never gone there in the first place. Merry Christmas.

Due to several shortcomings of the stock formencode email validator, I forked it and extended the test suite. This fixes the two most glaring issues I know of, namely the inability to handle unicode strings (international domains), and several problems with input checking (e.g., allowing commas) where invalid e-mail addresses make it through.

I did not write most of the code, I just refined it and added tests to exercise it. Let me know if it's useful to you, and if you find problems with it.

We have been importing sets of RPMs into Conary capsule packages, and yesterday we announced why.

Capsules are simple. We wrap existing packages provided in some other format (RPM, in the first instance, but we expect others) in rich Conary metadata (file-based dependencies based on deep file inspection, groups, and so forth), and store the combination of the unmodified package and metadata in the Conary repository. To install the package on a Conary-managed system, Conary calls the native package management code.

This works amazingly well. You can even mix native Conary packages with capsules.

This capsule feature can even help find bugs in RPM packages!

As part of this work, we imported RPMs from the original Red Hat Enterprise Linux 5 ISO images into a repository and tried to build a Conary group containing those packages. Unfortunately, this group was not dependency-complete. It appears that during RHEL 5 development, several packages were built against Firefox 1.5.0.7. Then (I would suspect near the end of RHEL 5 development, though I haven't checked build dates) Firefox was updated to 1.5.0.9. Someone remembered that the yelp package would need to be rebuilt against Firefox 1.5.0.9 to function. No one, apparently, remembered that gnome-python2-extras also needed to be rebuilt against Firefox 1.5.0.9. I don't blame anyone for this; I wouldn't either. But with Conary, all we had to do was try to add all the packages to a group and Conary complained and told us exactly what was wrong. By contrast, RHEL 5 was released with gnome-python2-extras that included an RPATH entry referencing a directory that does not exist: a broken dependency. As far as RPM's more limited view of dependencies is concerned, RHEL 5 was dependency-complete, but the combination of Conary's deep file inspection and group dependency checking caught this bug immediately.

Dave Winer: “[The iPhone is] a lovely piece of art, run by a platform vendor with a shitty idea of users and developers and serviced by a phone company that can’t run a cellular phone network.”

Today is a pretty big day for us here at rPath. We've just announced support for Red Hat Enterprise Linux in our release management product offering. For the past year we've gotten significant interest from large organizations who want to use Conary's version control capabilities to manage their system deployment. Red Hat's incredible success has made their enterprise offerings a requirement for those businesses though, so they've been trying to find a way to get the best of Red Hat along with the best of rPath.

After scratching our heads for a while, we realized that what those folks want out of Conary isn't package installation, it's version control. They're looking for a way to organize sets of RPMs, define systems using versioned groups, and reliably update those systems once they're deployed. While we have previously imported operating systems (such as Novell SLES, CentOS, and Scientific Linux) we changed the packaging as part of that; doing that would (understandably) concern this set up of users who really do want RPM. But RPM does package installation, not version control, so why not marry Conary version control with RPM package installation to get the best of both worlds?

This line of thought led to capsules in Conary. They're really just a way of delegating the physical package management to another packaging system (RPM in this case) while using Conary to do the high level version orchestration. So Conary decides what gets installed, and RPM does the installation.

The packages themselves are represented as normal Conary components (rpmname:rpm), but the RPM itself gets stored in the repository instead of the contents of the individual files. When a changeset is generated, the entire RPM is sent down the wire and the conary client then passes the RPM package to RPM itself to do the install. If there are multiple RPMs they all go off to RPM simultaneously to make sure RPM can order everything properly.

What's this all mean to Red Hat Enterprise Linux users? It means that you can use Conary to define groups, rBuilder to build images, and Conary to apply updates. Strong version control, package repositories, and our deep dependency resolution are all preserved. It also means you can use RPM to query the system, install packages outside of Conary, and perform RPM system verifications. After all the installation path is identical to anaconda's, with a single RPM transaction installing the entire system for you. It's not a system that looks like Red Hat Enterprise Linux, it is Red Hat Enterprise Linux. After the system is installed the only difference is a Conary binary which can be used for package version orchestration.

If you still remember my pet project BillReminder and want to learn what’s going on with it, go check the project’s latest post!

A huge thanks to nosklo, Patryk, and Toms for their help, and if you’re looking for a young python project to help out, please consider looking at BillReminder!