For awhile now I've noticed that things in my home dir aren't setup optimally for my work flow. I've been trying to run with SELinux enabled and I run into development problems when I try to run web applications out of my home directory. Various parts of my home directory are version controlled separately due to the software projects they're part of, but not as a whole.

What I'd like is to setup some other place for "projects" (Mozdev code and docs, other software projects, RPM building, etc) and then version control my home dir.

The problem is I'm not sure how much this helps me. Things like IM clients still are going to want to log things to ~/.somedir/log which is evil. SELinux contexts for files in /home/myprojects is still going to be wrong; I'm not going to be able to run webapps out of there, either. Moving my docs out of my home dir might be a pain due to xdg-user-dirs needing to be setup correctly to point at the document dir

I'd really love to have a lean, mean homedir that is version controlled that I can port around between boxes. Have people attempted this before? What about the above problems?

by Wellington Grey

Jocelyn's definitely going to be a vi user; when she's done typing she immediately hits 'escape' and will pound 'escape' repeatedly when things aren't acting the way she thinks they should.

I finally have all my boxes upgraded to F8 (via yum; viva la Live Upgrage SIG!). It really wasn't as bad as I anticipated, and in fact, probably much better than my anaconda-based upgrade for F7 since I had all my third-party repos enabled for the upgrade and didn't have many stragglers after it was all done.

Two of my home servers were still running FC-6 (!!). These boxes presented some problems getting upgraded since they were running some more esoteric package sets. My one server gave me fits of problems with getting unmet dependencies for packages that clearly existed. This one was an x86_64 box and was giving me a "missing dependency" for glibc.i686. /me shrugs. "yum upgrade" rather than "yum upgrade yum* rpm*" seemed to get it fixed. I did have to remove a number of packages beforehand, but that didn't bother me much.

Overall I am very impressed with the F8 release. My statements earlier about Fedora not having enough direction were apparently completely without merit, or were just the result of not having enough first-hand experience with what had been going on. Hopefully I'll be able to give a bigger hand to development for F9 and keep the great work going.

I recently (last night) started using Konversation for IRC instead of Kopete and as the title says, it's miles above its main Kompetition (sorry - couldn't resist).

The biggest problem with using Kopete for IRC is that it's mainly an IM program. There's probably only one bug that dramatically makes the difference, but it's a big one. When chatting with people over IM (one-on-one) it's much nicer to have their name and picture beside each IM. Doing that over IRC is hideous.

Of course, Konversation has support for other things I've been missing in Kopete; namely the ability to highlight messages based on arbitrary things (other than my nick) - like my name. And it's generally just much more IRC-y than Kopete.

Of course, Konversation does have its own bugs, but they can be dealt with much better than not being able to read my IRC session.

Since yum isn't capable of downgrading the correct package, I decided to try smart.

And after a couple hours (literally) of computing transactions, it worked.

Now, there's definitely some cleanup to do, but it's pretty good. Unfortunately smart isn't available for RHEL 5 yet (I've emailed rpmforge to request it), but things are looking pretty good.

The biggest problem is that yum doesn't work. After quickly fixing the python-elementtree package, yum now says:
# yum clean all
Loading "installonlyn" plugin

Could not find any working storages.

Fortunately, here's how to fix it.

For me it was:
# rpm -Uvh sqlite-3.3.6-2.i386.rpm python-sqlite-1.1.7-1.2.1.i386.rpm

And here's the config I used for smart:
smart channel --add "Silfreed.net" type=rpm-md priority=-3 baseurl=http://www.silfreed.net/download/repo/rhel/5/i386/silfreednet -y
smart channel --add "Dries" type=rpm-md priority=-5 baseurl=http://ftp.belnet.be/packages/dries.ulyssis.org/redhat/el5/en/i386/dries/RPMS -y
smart channel --add "Dag" type=rpm-md priority=-5 baseurl=http://apt.sw.be/redhat/el5/en/i386/dag/ -y
smart channel --add "EPEL" type=rpm-md priority=-2 baseurl=http://download.fedora.redhat.com/pub/epel/5/i386 -y
smart channel --add "CentOS Base" type=rpm-md baseurl=http://mirror.centos.org/centos/5/os/i386/ -y
smart channel --add "CentOS Updates" type=rpm-md baseurl=http://mirror.centos.org/centos/5/updates/i386/ -y
smart channel --add "CentOS Addons" type=rpm-md baseurl=http://mirror.centos.org/centos/5/addons/i386/ -y
smart channel --add "CentOS Extras" type=rpm-md baseurl=http://mirror.centos.org/centos/5/extras/i386/ -y

Figured I'd try upgrading again; this time from CentOS 4.5 to 5. When 4.5 came out I quickly tried just pushing the new centos-release and centos-release-notes packages onto the server and do a 'yum upgrade', but it failed trying to meet dependencies (kernel and kudzu, I believe).

So now it's coming time to do some maintenance to Argo and I'd like to upgrade to CentOS 5 finally. I did some research, and it doesn't sound any easier than before.

First, some packages in CentOS 4.5 are newer than what's available in 5.0. This means even anaconda will have problems (I've experienced this before upgrading from an updated FC6 to F7). That thread basically says it's probably easier to wait for 5.1 to come out, then update before 4.6 comes out.

Then there's the problem of yum not working after and upgrade.

And of course there's the guy who had various breakage doing the update manually.

So I'll probably try to do the upgrade manually on my firewall first just to see how it goes. I guess the worst-case scenario is that I have to install CentOS 5 onto some new drives for Argo, then copy the data over from the existing drives. Not the most ideal upgrade path, but it's an upgrade path.

For awhile now my file server has been running Fedora Core 6. I never have a good time to upgrade it to Fedora 7 because I'm always using it.

In the beginning I had envisioned running multiple VMs on it for compiling packages; it's an x86_64 box, so I would gain an arch (currently only i386) and would be to compile both the Intel architectures on one box. I'd free up space on my laptop since I wouldn't have 4 VMs sitting on it (that rarely work with VMWare anyway).

The problem has been that he Xen kernels have locked up my file server for awhile. I'm not sure when it started, but things would just hang when udev was starting.

The recent kernel-xen-2.6.20-1.3001 package seems to have fixed that though. So I setup a bunch of VMs one day and got them updated.

Well, all but a FC6 VM. For some reason I constantly have problems running that as a domU.

Unfortunately I then realized that my ivtv drivers weren't loading because there weren't any packages available. My file server also serves as my MythTV backend, so there was a day there were I missed some recordings. Axel's moving this week, so kernel packages have been stalled while he gets things situated. So, I'm back to a regular 2.6.22 kernel.

One thing I did notice is that the tickless support in 2.6.22 definitely helps on this server - it keeps things much cooler than the 2.6.20 kernel does.

Oh, and the VMs I'm running (or want to run) include:
Fedora Core 6 x86_64: not working
Fedora 7 x86_64: working
CentOS3.9 x86_64: wouldn't install
CentOS4.5 x86_64: working
CentOS5.0 x86_64: working

So I still need to get FC6 and CentOS3 installed, but things are going pretty well, I think. After the ivtv drivers are available I should be back to trying to get things going.

South Park Mac vs. PC. Funny, true stuff.