An Open Letter to Paul Corner

This is a copy of a message I have attempted to send to the "bdi4emc-help" mailing list three times over the past few days. That message still hasn't appeared in subscribers' mailboxes or on the archive —but several "testing" messages have. Whatever the reason for that, I've decided to publish the e-mail here, but with the content unchanged but using HTML markup as appropriate. Update: Paul Corner has said that he censored the post, apparently because I dared to bring up the subject of open access to his CVS server. Update 2: After I escalated things by claiming the inability to rebuild AXIS constituted a GPL Violation, Matt Timmermans has sent me instructions to build the python-axis deb, and I apologized to Paul, but my requests for instructions to build other GPL packages that Paul Corner builds and includes on bdi4emc have been ignored. Maybe someday the documentation will be added.

The immediate context is that Paul rebuild his emc and python2.3-axis packages, but the python2.3-axis package was unusably broken. In my message of May 9 I wrote with a patch to axis that I believed would fix the problem, and talked about the reasons my automated system (which tests the development version of AXIS against Paul's emc 1.0-39) didn't detect the problem. This is what Paul referred to as a "diatribe" in his reply, also on the 9th.

The larger context is that I am also a contributor to emc2, and that there's a great deal of tension between the bdi4emc camp and the emc2 camp. bdi4emc and emc2 are both decendants of the original emc code, but the emc2 camp has continuity with the original emc board of directors. To add to the confusion, bdi4emc is an entire Linux distribution, while emc2 is just an application (with special kernel requirements).

On Tuesday 09 May 2006 04:32, Jeff Epler wrote:
> > Earlier this evening, a bdi4emc user on the #emc IRC channel reported
> > that the bdi4emc package of axis 1.2.1-1 doesn't run.
On Tue, May 09, 2006 at 11:41:20PM +0100, Paul wrote:
> <diatribe snipped>

That honestly wasn't supposed to read like a diatribe. I was hoping to make it clear that I have undertaken no small amount of work in the hopes that I'd catch early any compatability problems between axis and bdi4emc.

As a hint to readers: The rest should read as though I am exasperated. I feel like I've been rebuffed for trying to help the users of bdi4emc. I feel like I am asking simple questions and making simple requests, but getting the runaround for no reason I can understand. I feel like Paul is trying to "snow me" about something, and I have no idea why (or even exactly what).

All the same, I'm trying to keep this message based on facts, with lots of "here's what I type, here's what the system prints". As a result, the message is pretty long. My professionalism may falter at moments (as in the IRC log paul alludes to at the end of his message), and I hope you'll forgive me when it does.

On Tuesday 09 May 2006 04:32, Jeff Epler wrote:
> > In hindsight, there are two major problems:  First, because the steps
> > necessary to produce identical packages to the ones Paul makes are not
> > published,

On Tue, May 09, 2006 at 11:41:20PM +0100, Paul wrote:

> Which part of `dpkg-buildpackge` is "unpublished" ?

I don't know. That's why I'm asking. Here's what happens when I try to use dpkg-buildpackage to rebuild your emc and python-axis packages:

$ apt-get source emc python-axis; sudo apt-get build-dep emc python-axis
[snipped; everything looks OK]
$ cd emc-1.0
$ dpkg-buildpackage -rfakeroot -uc -us
dpkg-buildpackage: source package is emc
dpkg-buildpackage: source version is 1.0-46
dpkg-buildpackage: source maintainer is Paul Corner <>
dpkg-buildpackage: host architecture is i386
 fakeroot debian/rules clean
/usr/bin/dpkg-buildpackage: line 175: debian/rules: No such file or directory

$ cd python-axis-1.2.1 $ dpkg-buildpackage -rfakeroot -uc -us dpkg-buildpackage: source package is python-axis dpkg-buildpackage: source version is 1.2.1-2 dpkg-buildpackage: source maintainer is Paul Corner <> dpkg-buildpackage: host architecture is i386 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp rm -f debian/PKG-INFO env EMCROOT=/usr/local/emc /usr/bin/python2.3 clean --all Traceback (most recent call last): File "", line 133, in ? emcplat = os.getenv("PLAT", find_emc_plat(emcroot)) File "setup/", line 50, in find_emc_plat for plat in ['nonrealtime'] + os.listdir(emcplatdir): OSError: [Errno 2] No such file or directory: '/usr/local/emc/emc/plat' make: *** [clean] Error 1

On Tue, May 09, 2006 at 11:41:20PM +0100, Paul wrote:
> FYI ALL python-axis files with the exception of the change log have been 
> supplied by Jeff Epler - In addition, the source tarball can be found in the 
> repository, so claims that "files are missing" are false.

I don't think I made that specific claim in my last message, but I have probably made one very much like it in the past.

Why would I say that there are files missing? One reason is that when I try to build the packages, it fails with the error

No such file or directory
Another is that the header file "rs274ngc_return.hh" (among others) is required to build axis, but "apt-file search rs274ngc_return.hh" doesn't list it as coming from any package. (it is in the files installed by 'apt-get source emc'—which is one reason I keep harping on the question of building both packages—but this doesn't put the header files in a place where the above 'cd python-axis-1.2.1; dpkg-buildpkg' process would find them) Similarly, axis will link with the library 'rcs' and the file 'rs274.o', and these aren't in any package either.

It also seems that there must be files missing in the emc source. Take this passage from the Debian New Maintainers' Guide:

There is a new subdirectory under the program's source directory, it's called `debian'. There are a number of files in this directory that we should edit in order to customize the behavior of the package. The most important of them are `control', `changelog', `copyright' and 'rules', which are required for all packages. (emphasis mine)
One of those files, debian/rules, is the very one listed in the above error trying to rebuild the emc package.

On Tue, May 09, 2006 at 11:41:20PM +0100, Paul wrote:
> `man dpkg` documents all the steps taken to build the axis packages.

Weird, I didn't know that dpkg specifically mentioned how to build my package...

$ man dpkg | less +/axis
Pattern not found  (press RETURN)
oh, I guess it doesn't.

OK, the manpage mentions something about "-b" to build. You must mean

$ dpkg -b python-axis-1.2.1
dpkg-deb: failed to open package info file `python-axis-1.2.1/DEBIAN/control' for reading: No such file or directory
nope, that's not it.
$ cd python-axis-1.2.1; dpkg -b .
dpkg-deb: failed to open package info file `DEBIAN/control' for reading: No such file or directory
that's not it, either.

Since you bring up Ubuntu, here are the commands to rebuild emc2 and emc2-axis on that OS:

$ sudo apt-get build-dep emc2 emc2-axis
$ apt-get source emc2 emc2-axis
$ cd emc2-2.0.0; dpkg-buildpackage -uc -us -rfakeroot
$ cd ../emc2-axis-1.3a2; dpkg-buildpackage -uc -us -rfakeroot

This writes the .deb packages emc2, emc2-dev, and emc2-axis. This shorter variant works too:

$ sudo apt-get build-dep emc2 emc2-axis
$ fakeroot apt-get -b source emc2 emc2-axis

Even though it's on ubuntu, this follows exactly the commands documented in the "apt howto":

I really don't understand why this has been such an issue. We're writing paragraphs and paragraphs about how to build the emc and python-axis packages, while you could simultaneously show your superiority over me and make me shut up by simply supplying the commandlines to rebuild these packages.

Here, I'll include some "$" signs for you to write the commands after:


C'mon, Paul, shut me up about this issue for once and for all.

On Tuesday 09 May 2006 04:32, Jeff Epler wrote:
> > Second, because the development process of bdi4emc is largely opaque,

On Tue, May 09, 2006 at 11:41:20PM +0100, Paul wrote:

> Aside from a core set of packages, much of what is included has been at the 
> request of numerous users. For example, axis, along with several libraries 
> not used by anything else, was added at the request of Jeff Epler.
> Evilwm and xfce4 were included because other users asked for a lightweight 
> alternative to KDE.
> There is currently some 20-30Megs of space available on the disk, so there is 
> room for additional packages should anyone request them. This has been a 
> standing offer since the launch of BDI-2.04.

I think you must have misunderstood me. I'm not asking for additional packages to be included on your CD. I'm not even a BDI user, except for the time I spend trying to make sure AXIS works with your distribution. If you chose to include AXIS as a favor to me, and not because it improves the experience of your users, then simply remove it.

What I am asking for is public access to the CVS/SVN/whatever tree for the software you develop: emc itself, mainly. I'm asking for you to publish the instructions so that anyone can rebuild an emc and python-axis package, with or without modifications. You clearly thought that public CVS was a big deal a month ago when emc2 development moved to a new CVS server:

If it is the intention of the board to alienate developers and restrict access of the code to a handful of the "in crowd", you will succeed.

What's the situation today? Well, everyone has read access to the emc2 CVS server[1] and all old developers were offered write access to the new server[2]. You can browse the up-to-the-minute development version, as well as the entire project history, right in your web browser[3]. We test continually on Ubuntu as well as BDI versions from 2.18 to BDI4[4]. We make regular source releases[5], and the instructions to obtain and build the source code are featured prominently on our wiki[6]. The decision to move the CVS server looks more and more right every day that sourceforge CVS is still not 100% restored[7].

For your version of emc? Back in January, after I bitched and moaned and kicked and screamed, you added some source to your apt repository, but for some reason I still can't understand you refuse to tell anyone how to actually duplicate the debian packages you build. You stopped using the public CVS server on sourceforge to host your version of emc, and you threw some kind of fit I still don't understand when you were offered developer access to the new CVS server. If you have a super-secret CVS server somewhere, you're not telling anyone about it.

That is the kind of thing I mean when I talk about a transparent vs opaque development process. I can only ask you to be open in your development practices. But back in April, you talked like you thought transparency was important. Why don't your actions match your words?

On Tuesday 09 May 2006 04:32, Jeff Epler wrote:
> > I very much want to keep axis running on new versions of bdi4emc,
> > because I believe it's the best GUI available for emc.  However, it is
> > sometimes a frustrating process.  If you can see a way to improve
> > things, please let me know.
On Tue, May 09, 2006 at 11:41:20PM +0100, Paul wrote:
> Numerous suggestions, some you probably won't like... May be when you give 
> BDI-4 an equal billing to Ubuntu as a suitable base for emc2...

By "you" you can't mean me; I don't set the direction for emc2. And I came to this discussion wearing my "AXIS lead developer" hat, not my "one of many emc2 contributors" hat. But if you want to bring this up..

As I said above, we test daily on Ubuntu as well as BDI versions from 2.18 to BDI4. Emc2 builds flawlessly on BDI4, both on the compile farm and when users follow the build instructions clearly documented on our wiki:

In the absence of debs, I've advocated using "--enable-run-in-place" so that emc2 installs no files outside the emc2/ directory, but I've also made it known in the past that I think we should incorporate patches to improve the build process of the .debs and in particular to make it work on other distros and kernel versions. I wrote this in a reply to you on the emc-developers list:

If you have patches or advice about how the emc2 debian/ directory can be enhanced so it does not hard-code kernel version numbers, please let the emc2 developers know. I'd be pleased to incorporate any patches that improve the packaging of emc2 into .debs.

You wrote back with a tarball (which sourceforge unfortunately doesn't archive)

Unfortunately I got nothing but silence when I asked you for more information about the changes:

I haven't had time to digest this yet, so it's quite possible that I'm missing something. What is the file 'rules.modules' for, and why does it appear to be a binary file?
(further research indicates that 'rules.modules' is typically a make-format file, very similar to the debian/rules file)

I don't remember if I did this at the time, but I did try it just now, even though I don't understand it all. Your changes make 'dpkg-buildpackage' fail (at least on ubuntu):

$ dpkg-buildpackage -uc -us -rfakeroot
[lines snipped]
 debian/rules build
make: *** No rule to make target `build'.  Stop.

It's not too late to revive this discussion. I'm still the first to admit I'm not an expert at debian packaging—nobody contributing to emc2 development came with any debian know-how, so we've done the best we can: we've produced packages that build consistently and easily on one OS, and made sure that "configure && make" works for a wide variety of other systems. With an infusion of good advice from a debian packaging wizard I'm sure we can improve things.

>  Then there is the IRC log from 31-3-06...

I haven't seen you on IRC for ages—why not join us some time? Just make sure you use a name we'll recognize.


Entry first conceived on 12 May 2006, 16:21 UTC, last modified on 15 January 2012, 3:46 UTC
Website Copyright © 2004-2021 Jeff Epler