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:
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
Create a setup.py file describing your package, as in the
simple example or the more detailed
setup script page.
For a sample standalone script with a desktop file and icon, you can
take a look at my
Starting from the Python setup script,
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 firstname.lastname@example.org:/tmp/.
Then, as root on the device, install it with
rpm -i /tmp/PyTopo-1.0-1.noarch.rpm.
To see a working example, you can browse my latest
(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:
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.
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
Packaging Guide. Clearly, that will need a separate article.
[ 18:44 May 20, 2011
More programming |
permalink to this entry |
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 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!)
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).
[ 23:58 Nov 17, 2004
More linux |
permalink to this entry |