Category Archives: debian
Open source, closed process
I just tried to report a bug to Ubuntu. Nothing major, just a missing package dependency: aptitude installed libnids-dev for me without installing libpcap-dev. My configure script then insists that nids.h was not found, whereas it is in fact clearly visible in /usr/include/nids.h. Turns out the test program fails because nids.h #includes pcap.h, which is not installed. Whoops!
OK, let’s do the Right Thing for a change: don’t just ignore it, report it. How do I report a Ubuntu bug? Aha, it’s at launchpad.net. Search for nids: nope, none of the 16 bugs listed is this one. OK, time to report a new bug.
This is where the problems go from straightforward to too difficult. To report a bug, I need to log in to launchpad. To log in, I need to create an account (it waffles on about OpenID, but it won’t accept my wordpress OpenID as a login). And to create an account, I need to solve a captcha. That is, one of those nasty eyesight tests.
I can’t do it. This one is nastier than ever.
Cycle the thing a few times, they’re all as bad. Try the audio version, but it’s silent (this is on a ubuntu machine). Looks like I can’t report a bug! 😮
I look on freenode, find #ubuntu-devel. Try asking there:
Just trying to report a bug (missing packaging dependency), but I can’t because I can’t even guess the launchpad captcha
The bug is, libnids-dev requires pcap-dev as a dependency
After a few minutes silence, start to blog this. But a few minutes more and someone replies:
first, I think you meant “libpcap-dev” instead of “pcap-dev”;
second, both these packages come unchanged from Debian, so it’s better to report this bug to bugs.debian.org
Ok, that looks like someone who knows what he’s talking about. Try a bug report to Debian. This fortunately turns out to be a much simpler process: their bug reporting site mentions a “reportbug” tool I can install with apt, and which appears to work nicely.
Ubuntu must be effectively in a bubble isolated from the big bad world!
Debian breaking Apache
Debian has a history of going its own way and confusing its users. So when someone @debian writes this, I fear what might follow, and I want to suggest they at least read and consider this before breaking expectations and invalidating the documentation/manuals all over again. But there’s no comment facility 😦
Anyone at Debian reading this? I know at least some of you appreciate the issue.
Lack of Entropy
Much has been said about the Debian/OpenSSL bug by people closer to it than I am. An expert view comes from Ben Laurie, who lays in to the Debian packagers for fixing an apparent bug locally, and not sharing it with upstream. In a second post, Ben clarifies some confusing issues, like whether OpenSSL is relying on uninitialised memory for entropy (not quite, but what it’s doing is not good either).
Ben’s wrath is well-deserved, but it seems to me there’s a fundamental reason why the OpenSSL folks must bear a share of the blame. Given the use of uninitialised memory, why wasn’t there a great big comment right there in the code, explaining it? Anything like that is sure to raise alarm bells in anyone reviewing the code, and send a programmer straight into fix-the-bug mode. And that’s an apparent-bug with a fix so simple that a compiler or runtime library could do it automatically. Don’t blame the Debian maintainer for fixing a blunder so trivial it must be a typo!
Why the “fix” went beyond just initialising that memory and broke it is beyond the scope of my (non-) research on the subject, and therefore this post.
UPDATE: Kudos to Michal Čihař for pointing out the upside to this sorry tale.
OK, I’ve re-licensed apr_dbd_mysql to permit distribution under the ASL 2.0 when aggregated with APR-UTIL. Due to the licensing incompatibility, this is necessary if it is to be aggregated. Which in turn makes life easier for end-users.
This follows recent discussion with the Debian packagers. The original problem is discussed in more detail here.
My attention has just been drawn to Debian bugs 395959/403541 re: packaging the MySQL driver in apr-util. This is a legal problem of meeting the terms of all licenses involved.
That’s bad, because I believe packagers such as Debian are precisely the people best placed to make this integration available to end-users. Speaking as a key holder of the intellectual property in question, maybe I can help. I just posted an entry to the Debian bug tracker, but I’m not sure how that works. So I’ll blog it here for the record.
Joachim has just drawn my attention to this report.
I am the original developer of the MySQL driver, and it was originally my decision to license it under the GPL. I’m also director of WebThing, and a member of the Apache Software Foundation (though not, in this message, speaking in an official capacity).
I’m not dogmatic about the licensing, and I’d be happy for it to change if it helps, subject to the constraints of the other licenses involved. Originally I’d have been more dogmatic about it, because apr_dbd_mysql released under the Apache license seems to risk undermining MySQL’s GPL rights, and I didn’t want to be responsible for that. However, MySQL AB has made it clear that they are happy to live with that: indeed, they explicitly name APR and the Apache license at http://www.mysql.com/company/legal/licensing/foss-exception.html
So the sticking point is no longer the GPL, but rather ASF policy, which does not permit us to distribute anything that would impose restrictions on our users, over and above those in the Apache License. The ASF takes the view that to take advantage of MySQL’s exception risks leaving our users in limbo. That clearly doesn’t apply to Debian: your primary license is after all the GPL.
A quick google reveals that some Linux distros have apr_dbd_mysql as a separate (RPM) package, and have presumably built apr-util to enable dynamic loading of a DBD driver. This seems to me an excellent solution.
I hope Debian will see a way to make this available for your users. If I can help, please ask.