We need a STFU option
The Debian Project recognises that on occasion the General Resolution process is dominated by a vocal minority of the project members, while the majority are uninterested in the topic under discussion. Without wishing to curtail the democratic process it is felt that it should be possible for the silent majority to indicate its desire to move on from the topic of a GR rather than continuing to rehash the same arguments ad infinitum. In order to facilitate this the project resolves to add a further option to all ballets, "No Further Discussion".
It is hoped that in the event of the "No Further Discussion" option being the winner of any vote that the project as a whole will accept that discussion of the subject of the vote is not considered to be a worthwhile use of project time or resources, and that we should therefore concentrate on more important matters.
(I thought about signing this post, but decided against it)Perl regex help
Dear Lazyweb, please put me out of my misery.
I have a string that looks something like:
a b c foo {0 1 2} fred {3 4 5} {{5 4 3} {2 1 0}} quux
I want to output:
a
b
c
foo
{0 1 2}
fred
{3 4 5}
{{5 4 3} {2 1 0}}
quux
(actually I want each line to be an array element, but that's obviously easy)
Can I do this with a Perl regex? Originally I thought I was going to have to walk the string like I would in C, but some playing around (and local help) got me to:
my $match = qr/(?:\s*[^\{\}\s]+\s*|\{(?R)\})/;
while ($cur =~ m/($match)\s+(.*)/o) {
print $1, "\n";
$cur = $2;
}
which sort of gets me there, except I get
{0 1 2} fred {3 4 5} {{5 4 3} {2 1 0}}
as one line instead of 4.
What obvious thing am I missing here?
FDMI success
This is the point where I should be writing something witty and intelligent about the election going on across the pond, but I can't think of anything worth saying. If you can, go and vote. Even if you think your side is going to win, go and bloody do it anyway.
Anyway. Today I achieved FDMI success; my code successfully registered my test cluster against the fabric switch it's connected to and reported various bits of information about itself. Hardly earth shattering but does at least indicate that I'm beginning to understand some details of Fibre Channel at the packet level and how to make our code send/receive them. Go 'bama me.
(FDMI is the Fabric Device Management Interface and a way for Fibre Channel devices to report things like their manufacturer, serial number, OS, HBA model and driver/firmware versions to a management controller on the switch fabric. It's not a complex protocol in any manner, but there's a distinct lack of clear Fibre Channel documentation around that's at a lower level than "So you want to hook up a SAN?")
NM gets longer and longer
If you ask the old timers about how they got started in Debian they'll tell you about sending off an email saying they wanted to get involved and having an account setup the same day. By the time I got round to joining it was during tbm's blitz when NM opened up again and it took only a few days to get through the process. When I first AMed, back in 2002, it took anywhere from a few days to a few months to process an applicant. I've recently started AMing again and so far my NM and I have exchanged 9 mails over the course of 2 weeks and still aren't through Philosophy and Procedures.
This isn't due to any failing on the part of my NM. It's just that there's a lot more "paperwork" to get through these days. There's currently a lot of discussion going on about the idea of introducing new classes of Debian involvement. I think that's something that's definitely worth looking at; it's already in existence for Debian Maintainers vs Debian Developers. However anything new that's introduced really needs to make some effort to be lighter than NM; someone who just wants to handle a few packages is going to get put off by too many hoops and the current NM process is already largely constrained by available AM time rather than anything else. I don't pretend to know what the right solution is, but I think anyone attempting to produce one should be praised for that rather than attacked.
Shrinking the keyring
Apparently I'm supposed to be blogging once a day, every day, for November. I missed yesterday and doubt I'll have something to say every day, but let's try...
Today I have been playing with the export-clean and import-clean options to gnupg, in particular in conjunction with the debian-keyring. The options result in only signatures that can be verified (ie that are from keys that exist in your keyring) being allowed, and remove signatures other than the revocation from revoked keys/uids.
Why is this interesting to me? Well, a number of reasons:
- It makes key updates a hell of a lot easier. It cuts down on the number of new signatures to check, for example.
- It cuts down on the keyring size, meaning smaller uploads for me and smaller downloads for everyone else. The .deb goes from 20M to 6.6M and the installed debian-keyring.gpg from 24M to 7.6M. That's a signficant saving.
- It makes for "cleaner" keys; only signatures that we know are valid end up remaining on the keys, anything invalid is removed.
(Note I haven't actually rolled any of this out, it's just something I've been playing with locally at present to get a feel for the savings/benefits to be had.)
subscribe via RSS