New cpanspec coming soon

I haven't released a new version of cpanspec in quite a while, but I have been working on it off and on with the help of several other people.  The big feature that I added was dependency extraction from tests, but I wasn't happy with the results of it.  Luckily, other people made it better, plus knocked a bunch of stuff off my TODO list.

The current list of changes looks like this:

• Extract dependencies from tests.
• Add script detection (patch from Jeff Fearn).
• Lots and lots of patches from Dennis Kaarsemaker and Gavin Carr:
• Drop cpanget and add the functionality to cpanspec.
• Check the search path for rpm, rpmbuild, etc.
• Add CC0 licence.
• Change %{optimize} to %{optflags}.
• Make tarball directory version component optional.
• Add an option to print the generated specfile to stdout
• Allow building rpms for slightly older perl versions
• Check all build requirements against CPAN
• Stop losing dependency version information for Module::Build, ExtUtils::MakeMaker, etc.
• Strip any version comparison operator from the 'perl' build requirement
• Add entries from configure_requres in META.yml as build dependencies
• Detect scripts better
• Don't let Module::AutoInstall run interactively
• Add a simple blacklisting mechanism

In my light testing, this version has been working beautifully, but I'd really like to hear some more positive feedback before I push this out into Fedora, so if you package Perl modules, give it a try and let me know what you think.

Why developers suck as admins

So Fedora 12 allows regular users to install packages as long as a) the user is logged in on the console, and b) they are signed and from a trusted repository.

I think it's great that we can enable this functionality, and I'd even argue that it should be on by default on the Live spins (and installs from the Live spins), but in the general case this is a horrible idea.

I've seen a few arguments why this doesn't matter. For example, anyone with local console access already owns the box, right? Well, console access != physical access. Think, well, anything in a server room (systems in locked cabinets attached to a KVM, or virtual machines). While this gives more ammo to us old-timers for not putting X on our servers (I'm looking at you, skvidal), the reality is that it's not realistic to expect all servers to run without a GUI.

I don't want to re-hash the whole (long) thread linked to above, but I think it is important to point out some of the solid reasons why this change is a bad idea.

• The installation of one package shouldn't change the behavior of the system. (This one package changes the behavior of the system, plus allows for other packages to be installed that could do the same.) If you take into account that unintended dependencies tend to pull in random stuff during upgrades, this becomes especially important.
• Can we really guarantee that there are no signed packages available that are exploitable, all the time?
• This is a major change in behavior from Fedora 11 that did not go through the Feature Process, unless I'm missing something.
• Possibly even worse, if this "feature" makes it into RHEL 6, you run the risk of a lot of semi- and non-technical sysadmins having yet another security decision made for them, probably without their knowledge. (How many are aware of ctrl-alt-del, console users being able to shutdown/reboot, grub allowing kernel options ("single", for example) unless you set a password, etc.? Of course I've never understood the logic of all of that being open, but magic sysrq being off by default.)
• At the very least, this is a DoS attack vector, although more likely due to somebody screwing up and installing a bunch of packages rather than somebody intentionally trying to fill /, /usr, or /var.

Oh, and about the title... Developers of software get stuck into a mindset of "make my software work, no matter what", and, on a related note, tend to have tunnel vision about the use cases for their software. One of the things I love about Fedora is that we have a lot of sysadmins who happen to be coders, so we tend to find a good balance between "usability" (AKA letting the developers go nuts) and maintenance/security. This one slipped by us, but I hope the decision will be made to push an update with a more sane default. [Update: It was.]

Note for amavisd-new users

I just pushed amavisd-new 2.6.4 to rawhide. The major new change in this version is the introduction of a script called amavisd-snmp-subagent. To quote the release notes...

- newly supplied with the package is a program amavisd-snmp-subagent,
 acting as a SNMP AgentX, exporting amavisd statistical counters database
 (snmp.db) as well as a child process status database (nanny.db) to a
 SNMP daemon supporting the AgentX protocol (RFC 2741), such a NET-SNMP.

 It is similar to combined existing utility programs amavisd-agent
 and amavisd-nanny, but instead of writing results as text to stdout,
 it exports data to a SNMP server running on a host (same or remote),
 making them available to SNMP clients (such a Cacti or mrtg) for
 monitoring or alerting purposes.

See the release notes for more details.

Since this script introduces new dependencies, I made a sub-package for it, which includes an init script. All of this is completely untested, so if anyone would like to try it out, please grab it from rawhide (or koji until it shows up there) and let me know how it goes.

Hey, spot!

After reading spot's post, I wanted to try out chromium. Shortly after installing it, I realized that name resolution stopped working.

The problem? Installing chromium.i586 pulled in nss-mdns.i586 on my x86_64 system. I installed nss-mdns.x86_64 and the problem went away.

Whee!

Want to use chromium on x86_64? Do this:

cat > /etc/yum.repos.d/chromium.repo <<'END'
[chromium]
name=Chromium Test Packages
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
enabled=0
gpgcheck=0
END

yum --enablerepo=chromium install chromium nss-mdns.x86_64

I don't know what I would do without Google and bugzilla.

Eric Sandeen is my new favorite person.

I'm finally watching a Fedora 11-based custom live CD boot...

Shiny

I love this effect.



I highly recommend perusing the gallery. Kara has some great stuff (although I think this is the only Fedora-related photo, and it was a happy accident).

Help!

My life has apparently hit a point where finding 5 minutes for anything is next to impossible. I seem to need to be in no less than 4 places at any given time. My contributions to Fedora are suffering as a result.

I really, really hope this is a temporary(-ish) situation, so I'd rather not orphan my packages (but I will if it is for the best). In the mean time though, I need some help, bad. It's been a couple of releases since I've been able to look at any of my non-Perl-related packages seriously, especially the GUI stuff. Luckily most of them don't need updates often, but right now I'm being harassed in bugzilla about font guidelines.

If any of you generous Fedora folk would happen to have some free time to bail me out and take care of that (or any other bugs I've forgotten about), I will forever be in your debt.

I'm not dead (yet)

So the month of September was consumed by work. If I've been less than responsive lately, blame the 12+ hours/day, 7 days/week lately. (Whee!) And to top it all off, since I've been trying to slack off a little this week (working, say, only 10 hours/day), I finally had some time to migrate my desktop to some bigger hard drives, but now that's turned into a nightmare. (It's a long story, involving 2 dead RAID cards, and now either some bad hard drives that passed burn-in testing fine, or a flaky RAID card.)

To make a long story short, if you really need to contact me, email isn't going to work that great. Without procmail to filter all the Fedora lists, linux-kernel, etc., I just get too much mail to find anything sent to me directly unless I get really lucky. Hopefully after my new RAID rebuilds (which is apparently going to take until tomorrow), I can get the rest of my data moved over, and get my system back up Monday or Tuesday.

It would be really nice to have working email again by the time I head over to Columbus for the Ohio LinuxFest on Thursday. (I'll be teaching a one-day LPI certification prep class there on Friday with Don Corbet.) If you email me and don't get a response in a reasonable amount of time, call the shop... They can always get a message to me.

One good bit of news from the day job though... I need to thank everyone who has worked on the livecd-tools package. I've managed to solve some rather large problems with a heavily customized live CD that I can hand to our employees. If there's a Fedora BoF at OLF, I'll share details then. (Some of it might make sense for a generic live CD.)

SELinux

For the record, I've always been of the opinion that SELinux was a great idea, and it would be incredibly useful. I personally think there are just too many moving parts on the average server (much less desktop) to properly define everything processes on the system are allowed to do.

Over the last couple of days, I helped a client set up new nameservers. The client in question is a university (a small one, but still...), so, as nameservers go, theirs are fairly high-volume.

To make a long story short, we wanted to go nuts with locking down these nameservers, so I left SELinux enabled, installed bind-chroot, etc. I had one real problem... SELinux wouldn't let me mount a separate filesystem at /var/named. Once I figured out this was happening and found the audit message in dmesg, I ran audit2why and got a somewhat helpful explanation and suggestion for a solution. Still, I can't help but feel like it's a bug that I can't mount a filesystem there...

Other than that, things went pretty smoothly. I went to the trouble of making sure all the config files, zone files, etc. were all labelled properly, which was a little painful, but once I figure out how, it wasn't all that bad. I just had to train myself to do "ls -laZ" instead of just "ls -la" to verify things. I even wrote a little script to reset permissions, owners, and labels all at once. It went something like this:

#!/bin/sh

usage() {
   echo "Usage: $( basename $0 ) --reference=RFILE file1 [ file2 [...] ]" >&2
   exit 1
}

if [ $# -lt 2 ] ; then
   usage
fi

chown "$@" || usage
chmod "$@" || usage
chcon "$@" || usage

(My thanks to whoever decided that all three of those commands should have a "--reference=RFILE" option. :-)

The SELinux tools are pretty decent now, but this little exercise pretty much just reinforced my opinion that SELinux is only useful if the sysadmin is willing to invest some time in setting everything up properly.

I hate to be negative... Seriously though, I still see software installation instructions that tell users to "chmod 777" some directory to make things work. (The last time I saw that, it was instructions for some software that was distributed as an rpm. It was sad on so many levels...) Software developers generally suck (IMHO), and most people who do system administration aren't much, if any, better. And that's with our, what, almost 40-year-old security infrastructure? Users aren't even waiting to have a problem... They just immediately turn off security. It's no wonder that most Fedora troubleshooting tips start by having the user disable SELinux.

Anyway, I can't decide if I'm just whining here, if I'm trying to tell a story, or if I'm trying to make a point... I think my point is not that SELinux is bad, but we need to set expectations appropriately. It is a tiny bit unrealistic to expect our packagers to get everything to work right with SELinux. And that's the part we can control... The users just aren't going to get it, period. Maybe ever.

sigh

Success!

$ rpm -q rakudo parrot
rakudo-0.6.3-1.fc9.x86_64
parrot-0.6.3-1.fc9.x86_64
$ perl6 -e '"Hello".say;'
Hello
$ perl6 -v
This is Rakudo Perl 6, revision 0 built on parrot 0.6.3
for x86_64-linux-thread-multi.

Copyright 2006-2008, The Perl Foundation.



YAPC::NA 2008 round-up

On the first day of YAPC, I gave a talk titled Perl on Fedora.



(Google Docs lost a little formatting in translation, but I've cleaned that up, and I think the results look substantially better than what I actually presented.)

It was the first talk I've given at a conference. I thought it went reasonably well, but I've made a mental note to prepare much further in advance next time, and to learn how to make a presentation that doesn't look lame. (I think I may have a tiny bit of PowerPoint envy.)

On the second day, David Wheeler took some time to talk with me about the Bricolage package I've been working on. It turns out it might actually work as-is, at least for PostgreSQL. I have some work to do to make it work for other databases.

On the third day, I finally got some time to work on my Parrot package. I got it to build with the latest version of Parrot, then broke it to add sub-packages for all the various languages I could figure out how to build. Hopefully Real Soon Now I'll have a rakudo (Perl 6) package, plus packages for a bunch of other random languages like bf.

Packaging Bricolage

I've been very occasionally working the last several years on packaging Bricolage, a CMS written in Perl (and implemented using Mason). Unfortunately, until very recently, Bricolage would only work on Apache 1 (and mod_perl 1). That has (finally) changed with the recent release of Bricolage 1.11.0.

Recently, I've been putting in a lot of time just trying to build a package, and I finally have something that will build and install (source rpm). I don't pretend even for a moment that it will work, but at least it's a start. (It also doesn't make rpmlint at all happy, but I'll get to that...)

At this point, I could really use some help getting the package to work, testing it, etc., so it can be submitted for review.

imapsync

I'm working on a job today where we might need to use imapsync. I didn't see it in Fedora (or in the package review queue), so I whipped up a package for it (unpacked). I doubt I'll have time to submit it soon, so if anyone wants to run with it, you have my blessing. (Cc me on the bugzilla request so I'm aware of it though, please.)

There are some UTF-8 warnings from rpmlint that need to be fixed. See the comments at the beginning of imapsync.spec.

YAPC::NA 2008 abstract

This talk will cover the current state of Perl development in Fedora (and, by extension, RHEL, CentOS, etc.). Topics will include the following:

• Status of Perl on Fedora
  
  • Perl SIG
  
  
  • Number of Perl modules available in Fedora and EPEL
  
  
  • What we have and what we're missing
  
  
  • Licensing


• Using Perl packages
  
  • Using virtual rpm dependencies
  
  
  • yum, repoquery, etc.


• Packaging Perl modules
  • Generating packages using cpanspec
  
  
  • Building packages with rpmbuild
  
  
  • Using mock
  
  
  • Checking for problems with rpmlint
  
  
  • Submitting packages for inclusion in Fedora

And the fun continues...

I have desktop effects in KDE 4! For a while, it seemed like no matter what I tried, kwin gave the following error:

Failed to create Scene object. Compositing disabled

The solution was to turn off Xinerama and switch to using TwinView. I can't say that I'm thrilled with that, but since I only have two monitors on one video card at the moment, it does work.

Oh, and I'm learning to like the yum-skip-broken plugin... It makes yum a fair bit slower than usual, but a slow (but working) "yum --skip-broken update" is better than a failed "yum update".

Rawhide eats babies - Film at 11

So since moving into the new store, I haven't been doing as much Fedora work as I'd like (or need to). I thought I might kick myself in gear a little if I tried actually running rawhide on my personal desktop.

As an aside, I should note that the box in question has been hand-upgraded since Slackware 2.0 in July of 1994 when it was a 386SX/16. Sometime in 1995 or 1996, I converted the box from a.out to ELF by hand. Then a few months later I installed rpm so I could install some interesting applications that were available in Red Hat Linux. (By this point I was running RHL on all of my newer systems.) At some point, I converted my initscripts over to RHL-style SysVinit and ran almost entirely RHL packages. I never ran the installer for upgrades (doing upgrades by hand with rpm at first, with apt later) until I upgraded from FC1/i386 to FC3/x86_64. Since then, all my upgrades have been done with yum. (Oh, and the box that started life as a 386SX/16 is now a dual dual-core Opteron 265. I think it is on its 8th motherboard. I'm about due for the 9th, but that's another story...)

So, anyway, I was running Fedora 8, fully updated, so I tried just doing "yum --enablerepo=*development update" (the "*" so I'd get livna too). That didn't work for some reason I don't remember now, so I thought I'd try breaking up the upgrade into smaller, more managable chunks. I started by doing "yum --enablerepo=*development update yum* rpm*". That didn't exactly work.

At least rpm still worked. I manually updated apt. It was working fine for a little while (although dist-upgrade wouldn't quite work due to some confusion between packages being renamed/replaced, multilib weirdness, etc.) but then when I finally came up with a small transaction for it to run (hoping to get yum working again by upgrading python and a few other things), it complained about size mismatch on some packages on my local mirror. After holding some of them to try to get around the problem, all of a sudden apt-get would hang on any command and suck 100% of the CPU.

So, understandably a bit frustrated at this point, I decided to try smart out. The GUI crashed repeatedly. It filled up /var copying repodata off my NFS-mounted mirror. When I finally got around all that, it had the same problems "apt-get dist-upgrade" did.

So I gave up on smart and decided to try to get yum working. Obviously there was just a missing dependency somewhere, probably just on the newer python in rawhide, but unfortunately the newer python required a newer openssl, which means upgrading just about everything. So after cleaning up a bunch of unnecessary i386 packages, I cheated and installed the newer python, openssl, and a few other things with "rpm -Uvh --nodeps". (Note: Don't try this at home. I'm a professional.) Guess what? After all that yum blew up with the same error as before.

So back to apt. I uninstalled apt entirely, moved my /etc/apt/ out of the way, and reinstalled apt. I recreated the bare minimum configuration that I needed. After that, apt-get worked again! (Something finally worked right!) I did a "apt-get -f install", which sucked in most of the packages from rawhide, and it worked! And yum even worked! Next, I tried "apt-get upgrade". That worked, although it held back a lot of packages. When I tried "apt-get dist-upgrade", I started getting size mismatch errors again.

So I went back to yum. A yum update got me completely upgraded. Time to actually start testing...

I restarted X. Well, I tried to restart X. Guess what? The nvidia binary driver doesn't play nice with the newer Xorg server. So I tried nv and nouveau. Neither would drive my second monitor. (I run a dual-DVI 7800GT.) So I went back to the nvidia binary driver and downgraded X to the Fedora 8 version. Luckily, that actually worked.

I have a whole list of things that are messed up in KDE 4(.0.0, as I'm sure every KDE fan including myself would be quick to point out). In no particular order:

• In general, things (panel, desktop stuff) aren't Xinerama-aware.
• The panel won't auto-hide, resize, or otherwise not be in the foreground.
• The Oxygen kwin theme doesn't seem to be configurable. It's nice and all, but the window borders are way too wide, and I'd really like a color change in the title bar or something else really obvious to let me know which window has the focus. That, or somebody needs to implement focus-follows-eyes.
  
• Desktop effects don't work for me. I'm still trying to figure this one out. (Could be related to this. I'm still using version 100.14.19 of the nvidia driver from livna. The 169.07 driver made etqw crash.)

In other news, Firefox (or, as it refers to itself, Minefield) looks nice. It seems to run really well in fact. Unfortunately, the only extension I use that has been updated for Firefox 3 is Flashblock. Ironically, the flash plugin isn't actually working though. (In the process of upgrading, I ditched 32-bit Firefox for the 64-bit Firefox though, so I might just need to work a little to get nspluginwrapper working. At least I hope that's all it is...) (UPDATE: The applix-libs package installed in 1998 was mistakenly providing libXt.so.6, libSM.so.6, libICE.so.6, and various other things it shouldn't have. Apparently I had removed the correct versions while upgrading. Reinstalling those libraries made flash work again.)

On another positive note, I ran (package naming guidelines-violating) OpenOffice.org not-quite-2.4.0 briefly to look at a resume someone sent me, and it looked nice and ran fast, so no complaints there.

Oh, and etqw hangs after a while, but it started doing that on Fedora 8 + updates a couple of weeks ago, so I expected that. (It crashed entirely with 169.07. Backing off just the nvidia update made it only hang. Good thing I still have an un-updated laptop I can run the game on... :-)

Goodbye Perl6::Bible. Hello Perl6::Doc.

Ralf and I seem to have discovered independently at nearly the same time that the Perl6::Bible "module" is finally being replaced with Perl6::Doc. I have a perl-Perl6-Doc package sort of ready, but I am not sure what to do about a few things.

1. Do we bother to obsolete the perl-Perl6-Bible package? I wouldn't be surprised if I was the only person who bothered installing it.
2. If we obsolete the perl-Perl6-Bible package, should we symlink the p6doc script to p6bible on the off chance that anyone was using the p6bible script?
3. What do we do about the name conflict with the p6doc script included with Pugs?
   

cpanspec 1.74

I released cpanspec 1.74 this morning. There's some information about it on the Fedora wiki, but the short version is that cpanspec generates spec files (or, optionally, rpms) for Perl packages on CPAN. As an example, you could build a source rpm for String::Random like this:

$ cpanspec -v -s String::Random
Updating /home/steve/.cpan/sources/modules/02packages.details.txt.gz...
Fetching /home/steve/.cpan/sources/modules/02packages.details.txt.gz from http://www.cpan.org/modules/02packages.details.txt.gz...
Fetching String-Random-0.22.tar.gz from http://www.cpan.org/authors/id/S/ST/STEVE/String-Random-0.22.tar.gz...
Trying to fetch description from String-Random-0.22/lib/String/Random.pm...
Writing perl-String-Random.spec...
Building source rpm from perl-String-Random.spec
Wrote: /home/steve/src/fedora/rpms/cpanspec/devel/tmp/perl-String-Random-0.22-1.fc7.src.rpm

Unlike most other automated (or semi-automated) solutions for building spec files for Perl modules, cpanspec actually gets the Summary, License, URL, description, and dependencies (if available) from the CPAN metadata and other sources. In many cases, packages generated with cpanspec are completely done and ready to use (or submit for package review).

Obviously there are a few things cpanspec doesn't handle well. See BUGS and TODO. Patches always welcome. :-)

More Perl 6 modules

I know it isn't what I'm supposed to be working on, but I happened to be looking through the list of Perl 6-on-Perl 5 modules on CPAN. I ran the list through cpanspec --follow and came up with another 51 packages.

As I have time, I'll go through the pile, clean them up, and start submitting them for review.

Week in review

Yikes. I seem to have spaced off making any updates this week. Oops.

Earlier this week I updated my pugs package to a svn checkout. It builds fine now, but I still have a ton of rpmlint warnings to address.

In Fedora news, all but one of the packages I submitted last week has been reviewed and approved. I also spent some time working on building my packages for EPEL. That's going to get a lot easier once the Module::Build package's dependencies get worked out.

There's been a lot more progress on the new store. We have permits now, and all the electrical and plumbing in the floor is done. We should have a floor on Tuesday, so either Wednesday or Thursday they should be building walls.

This past Thursday was Emma's 6th birthday. I took her to see the Cardinals/Cubs game. That turned out to be a lot of fun... The Cardinals won 11 to 1, with home runs from Rolen and Pujols and a grand slam from Chris Duncan. Emma seemed to especially enjoy all the fireworks. :-)