Monthly Archives: August 2013

This version features a lot of stuff that I wanted to add to py3status for a long time and which I had in a small todo floating around. After the recent i3wm 4.6 release, I found it the perfect time to implement them while benefiting from the new click event support from i3bar.

The idea of allowing py3status users to have their modules respond to clicks got my head fuzzing and I started slowly to implement my whole todo while adding some great new features thanks to the enhanced i3bar protocol.

I ended up rewriting (again) completely (and slowly) py3status 🙂 But it’s for its own good, and yours hopefully. I strongly encourage you to have a look at the empty_class.py and pomodoro.py examples as they showcase the new on_click system.

You can already benefit from this bump without modifying your modules thanks to the default middle click event which forces a refresh of the module’s method you click on (handy isn’t it?).

changelog

support for i3bar click_events, they’re dispatched to user-written py3status classes based on their name/instance

add support for on_click methods in user-written modules to handle i3bar click_events (see the pomodoro example)

default is to clear the method’s cache (force a refresh) if you middle click (button 2) on a method’s output and the module does not support click_events

rewrite pomodoro example to showcase the on_click usage

use i3-nagbar to display warnings/errors to the user and also log them to syslog

new user-written module output ordering mechanism is more intuitive as it uses strictly numeric then alphabetical sorting

use select/poll() to implement a non-blocking I/O reading mechanism on threads

new Events thread is responsible for reading i3bar JSONs and dispatching them to the correct user module (click_events)

each user-written module is started and executed in its own thread

remove the pointless -d option

add a –debug option to be verbose in syslog (useful for debugging your modules)

add a real CHANGELOG

add a proper LICENSE file

make sure all examples are PEP8 compatible

update the empty_class example to explain on_click and kill usage

Note for Gentoo users : starting with this release, py3status is now available in portage so you don’t need my overlay anymore.

mongodb-2.4.6

The folks at 10gen discovered a severe bug in the mongoDB chunk migration process on sharded environments.

Basically, depending of the size of your documents, there was a chance that some get lost during data migration ! Relax tho, this case affected only the chunks containing documents which size are in the range of 16,776,185 and 16,777,216 bytes (inclusive) so this means that if you don’t have quite big documents in your cluster, you have not been affected by this bug.

Still, as a maintainer and production user of mongoDB, this is not the kind of news I like to hear especially when thinking of you Gentoo users. On top of this, I had the bad surprise to experience again the stale replication bug that was supposed to be fixed on 2.4.5 on my production cluster.

So I decided this was time for a major cleanup of the mongoDB ebuilds in portage to make sure we’re not shipping known broken versions of mongoDB to you guys. I thus :

dropped all obsolete <mongodb-2.2 ebuilds (I warned about this quite some time ago now)

dropped the known bugged versions of mongodb (<2.2.6 and <2.4.6)

cleaned up all obsolete files in $FILESDIR

added, on the v2.4.6 ebuild, the embedded-v8 USE flag as a user convenience so you can now have packages requiring v8-3.19 and mongodb installed on your machine. I added an explicit warning about this as this is not the way to go on normal usage as this is against Gentoo policy.

other highlights

Resolved sharding migration issue that produced excessive small chunks

Resolved C++ client shutdown issues

pymongo-2.6

This one is quite interesting as it brings both new and improved features as well as some bug fixes. Also note that they fixed some gevent compatibility stuff.

highlights / explanations

The max_pool_size option actually means what it says now. Pymongo will open at most this number of sockets to your servers. Do remember that if you share a connection between threads, then your (max_pool_size+1) thread will wait for a socket to be freed before being able to process your command.

waitQueueMultiple and waitQueueTimeoutMS options will help you define how much and how long you want a process to wait for a socket to be available before raising an exception.

Pymongo automatically splits batch inserts into 48MB chunks so you don’t have to worry about pushing a huge list of documents for insertion.

Support for aggregation cursors (for use with dev version 2.5.1, not used on production now)

Support for exhaust cursors. When you queried a large amount of data, the client had to ask the server for each batch of results. An exhaust cursor will instead stream batches to the client as quick as possible. This make pulling large sets of data faster and more reliable than before !

Looks like rabbitMQ upstream likes to bump their stuff right after I catch-up with my bumps 🙂 You are strongly advised to upgrade to this version since it fixes a quite important bug introduced by 3.1.4.

highlights

fix crash in the delegate mechanism leading to various crashes, and intra-cluster incompatibility between RabbitMQ 3.1.4 and other members of the 3.1.x series (since 3.1.4)

It’s been more than 3 months since the last version bump of rsyslog, I’m sorry about that (special kudos to @Opportunist for his patience). Since June 6th, we have a new stable 7.4 branch of rsyslog containing all the bugfixes and improvements made in the 7.3 dev branch.

So here comes the catch-up to current v7.4.3. Please note that as upstream do not support older branches, I will soon remove them from portage and close related bugs.