From the response to a bug report by me about a completely wrong version of mod_perl 2:
I'm afraid you will be out of luck here, if I understand the issues correctly. The official release of mod_perl 2.0 never made it to Sarge, the 1.999.21-1 packages in Sarge is a pre-release. The problem was that shortly before mod perl2 went stable, the upstream developers decided to rename lots of things in the API, and Sarge shipped the old API. Thus, mod perl 2.0 as shipped with Sarge won't run in the rest of the world, and vice-versa. Also, the documentation will be confusing. [...] So, well, this isn't a good situation, but it is something we have to live with.
What? They must have lost their minds. Once again, for clarity: the mod_perl 2 version in Debian Sarge—the current stable Debian—is not compatible with the old mod_perl 1 version or the real mod_perl 2 version because it is a 1.99something with a quite different API. Applications based on it are not portable from the old version and not portable to the new version. Anyone who wants to work with Debian Sarge, Apache2, and mod_perl must first get a backport because the version included is simply completely wrong.
This is absurd. Sure, mod_perl 2 wasn't ready for release on time, but the version currently in Sarge is simply garbage. Instead of removing it, an intermediate version is included, making life difficult for anyone who wants to port mod_perl applications to Apache 2—and doubly so, because with the next release, they'll have to port again.
And then the knockout punch last night:
The only valid complaint in this bug report is the fact that we don't include pre-2.0 API docs in sarge. Debian makes absolutely no guarantees that the version of a package shipped in a stable release will match whatever the current API is on its upstream website.
Summary: we don't understand anything and insist on behaving like complete idiots. Instead of at least removing the junk release—which is also classified as "don't use" by upstream—the missing documentation is now listed as a wishlist bug.
As every year, the long night of museums in MĂĽnster took place again. However, something must have happened compared to last year. Last year, the interest was indeed great, but it could still be described as quite bearable. In the museums, one could move through the rooms - albeit with more visitors than usual. Only the Picasso Museum was already overcrowded last year and was only allowed to enter in groups.
This time, that was unthinkable - the State Museum of Art and Culture is not exactly small. Nevertheless, one could no longer get into some rooms because of the sheer number of people - who then, with guided tours, turned into real visitor traffic jams, making entire parts of the museum inaccessible.
Absolutely crazy the whole thing. Real hordes of people moved through the city and blew the collective attack on the museums. Somehow slightly surreal the whole thing
Philip J. Eby hacks again. This time, a parser for configuration languages whose syntax is based on Python. Particularly interesting: with the parser, you can beautifully build abstract languages that use Python for code in parts - you can convert Python blocks contained in it from the token form back into cleanly formatted and indented Python code. The parser, of course, knows all the edge cases of source formatting in Python and can handle them as well.
This is interesting because with Python, unfortunately, you don't have a macro language and therefore cannot directly map your own syntax extensions and languages with domain-specific syntax and semantics to Python - but you can build a translator for such DSLs via this parser and then convert them back into Python. Add a bit of import magic and you would have something like poor-mans-macros for Python ...