Shallow Thoughts : tags : redhat

Packaging Python for MeeGo (or other RPM-based distros)

Writing Python scripts for MeeGo is easy. But how do you package a Python script in an RPM other MeeGo users can install?

It turned out to be far easier than I expected. Python and Ubuntu had all the tools I needed.

First you'll need a .desktop file describing your app, if you don't already have one. This gives window managers the information they need to show your icon and application name so the user can run it. Here's the one I wrote for PyTopo: pytopo.desktop.

Of course, you'll also want a desktop icon. Most other applications on MeeGo seemed to use 48x48 pixel PNG images, so that's what I made, though it seems to be quite flexible -- an SVG is ideal.

With your script, desktop file and an icon, you're ready to create a package.

Create a setup.py file describing your package, as in the distutils simple example or the more detailed distutils setup script page. For a sample standalone script with a desktop file and icon, you can take a look at my PyTopo setup.py.

Starting from the Python setup script, Python's distutils can generate RPM or even Windows packages -- assuming you have the appropriate tools installed on your machine.

I'm on an Ubuntu (Debian-based) machine, and all the docs imply you have to be on an RPM-based distro to make an RPM. Happily, that's not true: Ubuntu has RPM tools you can install.

$ sudo apt-get install rpm

Then let Python do its thing:

$ python setup.py bdist_rpm

Python generates the spec file and everything else needed and builds a multiarch RPM that's ready to install on MeeGo. You can install it by copying it to the MeeGo device with scp dist/PyTopo-1.0-1.noarch.rpm meego@address.of.device:/tmp/. Then, as root on the device, install it with rpm -i /tmp/PyTopo-1.0-1.noarch.rpm. You're done!

To see a working example, you can browse my latest PyTopo source (only what's in SVN; it needs a few more tweaks before it's ready for a formal release). Or try the RPM I made for MeeGo: PyTopo-1.0-1.noarch.rpm. I'd love to hear whether this works on other RPM-based distros.

What about Debian packages?

Curiously, making a Debian package on Debian/Ubuntu is much less straightforward even if you're starting on a Debian/Ubuntu machine. Distutils can't do it on its own. There's a Debian Python package recipe, but it begins with a caution that you shouldn't use it for a package you want to submit. For that, you probably have to wade through the Complete Ubuntu Packaging Guide. Clearly, that will need a separate article.

Tags: python, meego, programming, rpm, redhat
[ 18:44 May 20, 2011    More programming | permalink to this entry | ]

Fedora Core 3

Fedora Core 3 is finally out, so I tried it this evening.

The install itself went apparently smoothly, looking just like a normal Redhat graphical install, with a few new options, such as SElinux (which I turned off).

The first problem came during the first boot of the newly installed system, when the boot process complained that fsck.ext3 was finding errors on hda2.

hda2, on this disk, is a SuSE partition: I didn't tell the FC3 installer about it at all, so, correctly, it's not mentioned in /etc/fstab; and it's reiser, so FC3 has no business running fsck.ext3 on it!

It dumped me into a single-user shell, in which mount shows / as mounted "rw,defaults", but any attempt to modify anything on the root partition complains "Read-only file system". I got around that with mount -o rw,remount / -- it turns out that typing "mount" doesn't actually give an accurate picture of mounted filesystems, and cat /proc/mounts is better.

Now able to edit /etc/fstab, I noticed the "LABEL=/" and "LABEL=/boot" entries that Redhat is so fond of, and speculated that this is what was causing the problems. After all, there are several other OSes installed on this system (a Redhat 7.3 and a SuSE 9.1) and either or both of them might already have claimed the label "/". So I changed the fstab entries to /dev/hda6 and /dev/hda1. A reboot, and voila! things worked and I found myself in the first-time boot configuration process.

(Note: Redhat bug 76467 seems to cover this; I've added a comment describing what I saw.)

I really wish Redhat would get over this passion for using disk partition labels, or at least detect when the labels it wants to use are already taken.

Onward through hardware configuration. It didn't detect my LCD monitor, but that was easy to correct. It correctly detected and configured the sound card. It didn't try to configure a printer. At the end of hardware configuration, it took me to a graphical login screen (no option for non-graphical login was offered), and I logged in to a gnome desktop, with a rather pretty background and some nicely small and professional looking taskbars. The default gnome theme looks nice, and the font in the terminal app (gnome-terminal) is very readable on this 1280x1024 monitor. The default browser is Firefox, one of the 1.0 preview releases, with nice looking fonts.

The first step was to try and configure a printer. Double-clicking on the "Computer" desktop icon offered only my two optical drives, the hard drive, and "Network". The Redhat menu in the panel, though, offered "System Settings->Printer", which ran printconf-gui, which revealed that FC3 had in fact autodetected my Epson Photo 700 and configured it. Strangely, printconf-gui's "Test" menu was greyed out, so I wasn't able to "print a test page" that way. I tried quitting printconf-gui, restarting it (still grey), left-clicking on the printer (still grey), right-clicking on the printer (nothing test-y in the context menu) -- and the Test menu finally ungreyed! The test page printed beautifully -- centered on the page, something Debian's CUPS setup has never managed.

Clicking on the red ! in the taskbar took me to up2date; clicking through the screens ended up updating only the kernel, apparently because updates aren't auto-selected and I have to manually "Select all" in order to update anything. Once I figured this out, up2date, via yum, got started updating the other 75 available packages. But it only got halfway through before it hung (the window wouldn't repaint). It turned out that kill -1 on the up2date process didn't help, but kill -1 on the /usr/bin/python -u /usr/sbin/up2date made the window wake up and start updating again. I had to repeat this several times during the multi-hour update. Then it died, apparently with no memory of which systems it had already updated.

A Fedora expert suggested that I should

• Go to /etc/yum.repos.d and add .us.west to the end of the url in every file that has a mirrorlist entry, then
• Use yum -y update instead of up2date, because up2date doesn't seem to work right for anyone.

Indeed, that seems to be working much better, and it turns out that I can move the RPMs already downloaded from /var/spool/up2date to /var/cache/yum/updates-released/packages so I don't have to re-download them (whew!)

Mixed review

So overall, FC3 gets a mixed review. The installer is pretty good. It's a bit light on feedback: for instance, not telling me that a printer was configured (or giving me an option to change it), which would have added a warm fuzzy since it turned out it handled it so well; or not giving me a non-graphical login option. The desktop look is clean and usable.

OTOH, the boot totally failed due to the LABEL=/ problem, and up2date totally failed. A novice user, wiping out the disk, wouldn't see the partitioning problem, but if up2date is as flaky as it seems (everyone I talked to has had problems with it) it's hard to understand why they don't just use yum directly, and offer more mirror options (up2date only gave me a choice of one server, which was obviously overloaded).

Tags: linux, redhat, fedora
[ 23:58 Nov 17, 2004    More linux | permalink to this entry | ]