When building python-2.6 on MirBSD, building the select module (which uses the kqueue backend on this platform) fails. This is because EVFILT_TIMER is not available on the platform.

The proposed patch is for python-2.6 but should apply to tip too.

This was discovered when building the python package from NetBSD pkgsrc, so the patch is taken from there.

Hello,

According to http://fxr.watson.org/fxr/ident?v=NETBSD;im=3;i=EVFILT_TIMER EVFILT_TIMER is defined on NetBSD.
As for MirBSD, with all due respect, it really looks like a niche platform, definitely not officially supported by Python.
Of course, this patch is so trivial and small that it can easily be merged, but it would be nice if MirBSD defined it in its header file instead (it's not the first problem due to kqueue-incompatibilities between on BSD platforms, see for example issue #12181 and issue #6419).

There are actually only two things that need to be touched for supporting MirBSD: This and the Configure script. I was planning to submit the Configure patches separately, I just started with this patch as it is so trivial.

Since this patch alone won't be enough to support MirBSD (and is required only for MirBSD), I suggest you to post the complete patch, and rename this issue "add support for MirBSD platform", or something along those lines.
That way, we can consider this as a feature request, and apply it in one chunk, if accepted.
However, I think that the current consensus is somewhat hostile to adding support for so-called "exotic platforms", so I can't guarantee this will be included (posting the whole patch will certainly help making a decision).
I'm adding Martin to the noisy list, he'll probably give you more insight on this.

As requested, here is the full patch for MirBSD support. The diff was taken against version 2.7.2. It is really quite easy, you just need to handle MirBSD like OpenBSD. 

With this patch, I can successfully compile and run Python on MirBSD. Even though it is a rather exotic platform, I encourage you to take these changes, as they are quite minimal.

Hello Benny,

> As requested, here is the full patch for MirBSD support. The diff was taken against version 2.7.2. It is really quite easy, you just need to handle MirBSD like OpenBSD.
> With this patch, I can successfully compile and run Python on MirBSD. Even though it is a rather exotic platform, I encourage you to take these changes, as they are quite minimal.

Indeed, it's quite short and manageable, but see
http://bugs.python.org/issue11937, especially Martin's and Terry's
comments:
"""
Guido established a policy a few years ago that we should rather not
incorporate support for every minority platform for which people
contribute patches. While I'd personally agree that an Interix port
would certainly be "fun", pragmatically, I'm -1 on having the code in
the code basis, and propose to close this issue as "won't fix".

We would certainly be happy to link to gentoo prefix from the "other
ports" page on python.org.
"""

and

"""
Markus, I agree with Martin that this patch would go against current
policy and should be closed. Rather than close it myself, I will try
to persuade you to do so.
[...]
"""

This patch is much simpler and cleaner though (OTOH, it's so simple it
shouldn't be too much work for MirBSD folks to keep this patch in
sync).

I agree that the patch is quite small. I am regularly building new Python versions (using pkgsrc) so I can maintain the patch for future releases.

Ok, closing this as "won't fix", them.

Hmm, I thought I was making an argument _for_ applying the patch. As I see it, these are benefits of merging the patch:

1. Being able to compile an unmodified upstream Python on MirBSD.
2. The patches in pkgsrc become smaller.
3. Future Python versions contain the support out of the box.

The only downside is having to add a few lines to configure and selectmodule.c ...

You said "I can maintain the patch for future releases". This sounds like a reasonable solution: you keep maintaining the patch; if you want python.org to link to your patch, we can certainly arrange that. By the "no minority platforms" policy, MirBSD is just too small to be officially supported.

Technically, I recommend to maintain the patch in a Mercurial clone, perhaps hosted on bitbucket. Then you do a merge every time python.org makes a release, and everybody can fetch the code base at any point easily.