I think maintaining a mockup d-bus implementation might be more work than it’s worth, but I might look into it for my own use in a project I’m working on.
I had to patch a testcase that failed in Py27 while running tox. In test_authentication there’s a function named get_username that’s supposed (as far as I can tell) to return the username for the user logged in. Problem is in tox the environment seems to be cleaned so neither USERNAME or LOGNAME is set. I patched this by using getpass.getuser() instead, but I can see as well that in the authentication module the getpass import is mocked of with another mockup object defined in the same test “GetPass”. While the tests succeed now, is this a false-positive that should not pass or is my patch ok? Regarding the byte string issue, it’s not really an issue. The b’’ notation in 2.7 returns a string whereas in 3.x it returns a byte object, so using it to make sure the string is interpreted as a byte-type object in both 2 and 3 is ok. For reference, if unsure what object corresponds to Py3 you can look at the six module where some aliases are defined to ensure types are correct between both versions. On Thu, May 28, 2015 at 4:47 PM, Tom Cocagne <[email protected]> wrote: > With regard to the tests, I started out with the initial goal of > implementing a minimal DBus server in addition to the client that would > have *just* enough functionality to support the client-side unit tests. I > got it mostly working but then ran out of steam a while back and wound up > dropping support for it. Most of the tests pass when pointed at it but > there were some hangs in the signaling logic that I never got around to > figuring out. The code is still there and it probably wouldn't be overly > difficult to resurrect if anyone finds themselves in a bored and slightly > masochistic mood one weekend. > As to the string vs bytestring issues, that code was donated by another > contributor a while back. I've never had a reason to touch Python 3 so I'm > still a little in the dark on the nuances involved. You guys almost > certainly know better than I how to address these issues. As long as the > testing works out, I certainly won't complain about any changes you make in > that regard. > Tom > On Thu, May 28, 2015 at 5:12 AM, Elizaveta Guseva <[email protected]> wrote: >> Hello, >> >> Using tox I’m not getting that import error so try that and verify that >>> the issue still exists. >>> >> I checked with tox, and get only the 3 issues mentioned by you in python >> 3.4 >> >> I've also enabled issues on the repository. >> >> >> @Eliza: I would like to get started with fixing the unit tests so that we >>> can start working on the interface. If that’s okay with you? >>> >> Sure. >> >> I have looked into marshaling tests briefly. >> >> Errors seem to come from difference in bytearray format >> Changing strings to bytes make it work for 2.7 and 3.4 pythons. >> >> There's one more issue of the same nature: >> on the line 268 of test_marshal in the function* test_bytearray(self)* >> >> In the struct.pack*(fm*t, v1, v2 ....) format string *fmt* has changed >> meaning of 's': >> It used to convert between C-char and Python-string in 2.7 >> In python 3.4 it convert between C-char and Python-bytes. >> It seems to me, the byte mark b was missing in front of dbus signature on >> that line. >> At least, b stands in front of all other signatures... >> I might be wrong. >> >> I pushed the changes just in case. >> >> Eliza >> >> >> >> >> On Thu, May 28, 2015 at 3:36 AM, <[email protected]> wrote: >> >>> Yes I completely agree with you, the only thing according to me that is >>> worse than a bad code style is an inconsistent code style. >>> >>> @Eliza: I would like to get started with fixing the unit tests so that we >>> can start working on the interface. If that’s okay with you? >>> >>> @Tom: I was thinking about setting up a Travis worker for our fork to CI >>> our work. Have you tried this before? >>> I realize the entire test suite might not be able to be tested since it >>> depends on a d-bus connection, but I believe the parts >>> that can be tested should be tested. >>> >>> >>> >>> >>> On Wed, May 27, 2015 at 8:38 PM, Tom Cocagne <[email protected]> >>> wrote: >>> >>>> The existing codebase was written in adherence to the Twisted coding >>>> standard in case there was ever a call to merge it into the Twisted >>>> mainline. Personally, I abhor their coding standard but I think consistency >>>> with the surrounding codebase is generally worth the pain. I'm not >>>> interested in draconian adherence to the standard, especially since it >>>> seems unlikely to be merged at this point, but I'd appreciate it if the new >>>> code looked similar to the surrounding code in order to avoid jarring and >>>> potentially confusing differences for future developers. Make sense? >>>> >>>> Tom >>>> >>>> On Wed, May 27, 2015 at 2:57 AM, <[email protected]> wrote: >>>> >>>>> Hi Tom, thank you for your interest in participating in this project! >>>>> Of the top of my head there’s really nothing that needs explaining, the >>>>> code is well documented and structured in a logical fashion. >>>>> >>>>> Would you prefer us to keep the coding style consistent across the >>>>> project? >>>>> I noticed my coding style differs quite heavily from yours, I believe >>>>> however that a “guest” of a project should adapt to the already defined >>>>> style guidelines so I would have no trouble doing just that. >>>>> >>>>> — >>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>>> >>>>> >>>>> On Tue, May 26, 2015 at 7:44 PM, Tom Cocagne <[email protected]> >>>>> wrote: >>>>> >>>>>> Pontus & Eliza, >>>>>> >>>>>> Please consider me a resource for your efforts. I have little >>>>>> development time available and I wrote txdbus quite a while back but I >>>>>> should at least be able to answer some questions and serve as a sounding >>>>>> board for design and implementation ideas. Good luck! >>>>>> >>>>>> Tom Cocagne >>>>>> >>>>>> On Tuesday, May 26, 2015 at 2:07:32 AM UTC-5, Pontus Karlsson wrote: >>>>>>> >>>>>>> How are you running the tests? Using tox I’m not getting that import >>>>>>> error so try that and verify that the issue still exists. >>>>>>> >>>>>>> Could you enable issues on the repository and start an initial branch >>>>>>> for the abstraction? >>>>>>> >>>>>>> I suggest we keep a branch for the abstraction and when that’s done >>>>>>> we’ll start with the asyncio branch. >>>>>>> >>>>>>> I’ve added a Gitter room as well for general talks regarding how to >>>>>>> proceed, unless you prefer keeping those discussions in this mailing >>>>>>> list? >>>>>>> >>>>>>> — >>>>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>>>>> >>>>>>> >>>>>>> On Tue, May 26, 2015 at 6:34 AM, Elizaveta Guseva <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I've added you as collaborator to my fork. >>>>>>>> >>>>>>>> So for planing and dividing the work I suggest we start of by >>>>>>>>> mapping the work needed to be done and start creating issues on the >>>>>>>>> repository. >>>>>>>>> >>>>>>>> >>>>>>>> OK. That sounds like a plan. >>>>>>>> Last time I worked together with a collaborator. I kept a plan in >>>>>>>> the Wiki of gitHub in order to remember what was the last step and who >>>>>>>> is >>>>>>>> responsible for which task. >>>>>>>> I don't know if you'd like to use it for coordination. >>>>>>>> https://github.com/gelisa/txdbus/wiki/Plan >>>>>>>> >>>>>>>> I also keep some notes there too. Mainly for myself to keep track of >>>>>>>> things. You can disregard them >>>>>>>> >>>>>>>> My vacation doesn’t start until July really but I do have some spare >>>>>>>>> time on the evenings on which I will work on this. >>>>>>>>> >>>>>>>> That's fine. >>>>>>>> >>>>>>>> The first thing I noticed was that three tests fails on Python 3.4, >>>>>>>>> these seems to be related to string -> bytes differences in the socket >>>>>>>>> implementation which needs to be taken care of first. >>>>>>>>> >>>>>>>> >>>>>>>> Ugh, I run the tests too and saw them. I am going to look into it. >>>>>>>> Did you have issues with import >>>>>>>> UNIXServerEndpoint/UNIXClientEndpoint in Python 3.4? >>>>>>>> It's looks similar to the endpoints, which can be imported in the >>>>>>>> source file of Twisted 15.2.1. Which puzzles me. >>>>>>>> >>>>>>>> Eliza >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 25, 2015 at 2:59 AM, <[email protected]> wrote: >>>>>>>> >>>>>>>>> Actually I just remembered twisted can interact with the stdlib >>>>>>>>> logging library as well through >>>>>>>>> `twisted.python.log.PythonLoggingObserver`. >>>>>>>>> >>>>>>>>> So I would change it to using `logging` and in the twisted >>>>>>>>> interface implementation use that. >>>>>>>>> >>>>>>>>> That leaves us with twisted specific code only in: >>>>>>>>> * protocol.py >>>>>>>>> * client.py >>>>>>>>> * object.py >>>>>>>>> * endpoints.py >>>>>>>>> >>>>>>>>> And also the tests needs a bit of abstraction as well, preferably >>>>>>>>> by testing the D-Bus protocol implementation by itself. >>>>>>>>> >>>>>>>>> — >>>>>>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, May 25, 2015 at 8:41 AM, [email protected] < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> I forked the project yesterday (github.com/wolfhechel/txdbus) and >>>>>>>>>> had another look at it. >>>>>>>>>> >>>>>>>>>> The first thing I noticed was that three tests fails on Python >>>>>>>>>> 3.4, these seems to be related to string -> bytes differences in the >>>>>>>>>> socket >>>>>>>>>> implementation which needs to be taken care of first. >>>>>>>>>> >>>>>>>>>> Six is already a requirement so I would probably use that in order >>>>>>>>>> to normalise the output from the protocols. >>>>>>>>>> >>>>>>>>>> Second step would be to separate all Twisted related code into its >>>>>>>>>> own interfaces and place that code in its own package. >>>>>>>>>> >>>>>>>>>> From those interfaces I would create the abstraction and then >>>>>>>>>> create the asyncio implementation on top of that. >>>>>>>>>> >>>>>>>>>> As for the logging, two approaches came to mind: >>>>>>>>>> 1. Initialize logging alongside the event loop abstraction and >>>>>>>>>> pass the log object to all involved classes. >>>>>>>>>> 2. Setup a global logging object in txdbus.log and upon >>>>>>>>>> initalization setup the appropriate logging facility (default to >>>>>>>>>> stdlib >>>>>>>>>> logging). >>>>>>>>>> >>>>>>>>>> I would prefer alternative number 1 since IMHO global objects with >>>>>>>>>> common names (such as logger, log, logging) tend to collide with a >>>>>>>>>> lot of >>>>>>>>>> other packages and increase chances of circular import dependencies. >>>>>>>>>> >>>>>>>>>> Since this is really your project, do you wish to start your own >>>>>>>>>> fork so that the main code is held in your account? Otherwise I’ll >>>>>>>>>> just >>>>>>>>>> give you write permission in the fork I’ve already done. >>>>>>>>>> >>>>>>>>>> My vacation doesn’t start until July really but I do have some >>>>>>>>>> spare time on the evenings on which I will work on this. >>>>>>>>>> >>>>>>>>>> So for planing and dividing the work I suggest we start of by >>>>>>>>>> mapping the work needed to be done and start creating issues on the >>>>>>>>>> repository. >>>>>>>>>> >>>>>>>>>> — >>>>>>>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, May 24, 2015 at 11:33 PM, Elizaveta Guseva < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Ultimately it is your choice, but it sounds like there is >>>>>>>>>>>> interest in >>>>>>>>>>>> this project from the txdbus community, which never hurt a >>>>>>>>>>>> project's >>>>>>>>>>>> chances of success :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Awesome. For me, with my primary scientific programming >>>>>>>>>>> experience, help is never bad =) >>>>>>>>>>> >>>>>>>>>>> OK, I'll start with planning. Will keep you updated. >>>>>>>>>>> >>>>>>>>>>> *Pontus,* >>>>>>>>>>> >>>>>>>>>>> I will start figuring out how to abstract the event loop. >>>>>>>>>>> Do you have any specific plan of action in mind? >>>>>>>>>>> >>>>>>>>>>> With regards, to your plans of participation... >>>>>>>>>>> I don't have much of the collaborative coding experience. >>>>>>>>>>> I am not sure what would be the best way of work organization. >>>>>>>>>>> >>>>>>>>>>> Eliza >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sun, May 24, 2015 at 4:57 PM, Tycho Andersen <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Sat, May 23, 2015 at 09:42:21PM -0400, Elizaveta Guseva wrote: >>>>>>>>>>>> > Hi, >>>>>>>>>>>> > >>>>>>>>>>>> > *Pontus,* >>>>>>>>>>>> > >>>>>>>>>>>> > As I understood from the discussion you mentioned, the author >>>>>>>>>>>> of txbus >>>>>>>>>>>> > cogane wants to keep one code base in order to wait for kdbus >>>>>>>>>>>> merge. >>>>>>>>>>>> > >>>>>>>>>>>> > I think it's not compatible with asyncio, because asyncio >>>>>>>>>>>> isn't supported >>>>>>>>>>>> > in 2.7. >>>>>>>>>>>> >>>>>>>>>>>> asyncio is supported in 2.7 (and <3.3), just not as an stdlib >>>>>>>>>>>> module, >>>>>>>>>>>> so I don't think this is a big factor for us, as we already >>>>>>>>>>>> require >>>>>>>>>>>> users to install it (qtile's event loop is asyncio based no >>>>>>>>>>>> matter >>>>>>>>>>>> which version of python you're running). >>>>>>>>>>>> >>>>>>>>>>>> > Besides that as I saw from code txdbus relies not only on >>>>>>>>>>>> twisted event >>>>>>>>>>>> > loop but also on logger for example. I don't know how it would >>>>>>>>>>>> be possible >>>>>>>>>>>> > to separate twisted and asyncio in that framework without >>>>>>>>>>>> fork, to be. >>>>>>>>>>>> > >>>>>>>>>>>> > I'm also not sure if we should worry about kdbus anytime soon, >>>>>>>>>>>> judging from >>>>>>>>>>>> > the heated discussion about merge into kernel. Maybe I am >>>>>>>>>>>> wrong. >>>>>>>>>>>> > >>>>>>>>>>>> > *Tycho,* >>>>>>>>>>>> > >>>>>>>>>>>> > Where do you think is better to start from txdbus or >>>>>>>>>>>> python-dbus? >>>>>>>>>>>> > >>>>>>>>>>>> > Pontus listed files in txdbus which rely on Twisted. >>>>>>>>>>>> > >>>>>>>>>>>> > As for python-dbus, it's: >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > - *bus.py -- calls for abstract async from connection.py* >>>>>>>>>>>> > - _compat.py -- None >>>>>>>>>>>> > - *connection.py -- has abstract async function* >>>>>>>>>>>> > - *_dbus.py -- asks for abstract loop* >>>>>>>>>>>> > - *decorators.py -- calls for abstract async* >>>>>>>>>>>> > - exceptions.py -- None >>>>>>>>>>>> > - *_expat_introspect_parser.py -- None* >>>>>>>>>>>> > - >>>>>>>>>>>> > *gi_service.py -- uses gobjects * >>>>>>>>>>>> > - >>>>>>>>>>>> > *glib.py -- glib.. * >>>>>>>>>>>> > - gobject_service.py -- depricated >>>>>>>>>>>> > - lowlevel.py -- None >>>>>>>>>>>> > - *mainloop -- import from glib bindings* >>>>>>>>>>>> > - *proxies.py -- uses connections' abstract async* >>>>>>>>>>>> > - *server.py **-- asks for abstract loop* >>>>>>>>>>>> > - *service.py -- calls for abstract async* >>>>>>>>>>>> > - types.py -- None >>>>>>>>>>>> > >>>>>>>>>>>> > To me it seems python-dbus hid its gobject dependencies pretty >>>>>>>>>>>> well and it >>>>>>>>>>>> > might be rather easy to add asyncio without touching most of >>>>>>>>>>>> the code. >>>>>>>>>>>> >>>>>>>>>>>> It sounds to me like you might get some help doing it in txdbus, >>>>>>>>>>>> whereas you wouldn't doing it in dbus-python, which is a benefit. >>>>>>>>>>>> >>>>>>>>>>>> A pure python implementation also causes less of a problem with >>>>>>>>>>>> distribution, although again I'm not sure this is a big concern >>>>>>>>>>>> for us >>>>>>>>>>>> since the majority of our users are Linux with a handful of >>>>>>>>>>>> OpenBSD >>>>>>>>>>>> folks. >>>>>>>>>>>> >>>>>>>>>>>> Ultimately it is your choice, but it sounds like there is >>>>>>>>>>>> interest in >>>>>>>>>>>> this project from the txdbus community, which never hurt a >>>>>>>>>>>> project's >>>>>>>>>>>> chances of success :) >>>>>>>>>>>> >>>>>>>>>>>> Tycho >>>>>>>>>>>> >>>>>>>>>>>> > Eliza >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On Sat, May 23, 2015 at 6:54 AM, <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > > I’ve mentioned this on an issue in txdbus >>>>>>>>>>>> > > https://github.com/cocagne/txdbus/issues/11 and the author >>>>>>>>>>>> had some >>>>>>>>>>>> > > pretty good points on implementing a twisted/asyncio >>>>>>>>>>>> abstraction >>>>>>>>>>>> > > in the txdbus library. >>>>>>>>>>>> > > >>>>>>>>>>>> > > I would be willing to contribute to this as well if the >>>>>>>>>>>> decision is taken >>>>>>>>>>>> > > to simply work on top of txdbus. >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > On Wed, May 20, 2015 at 5:01 AM, Elizaveta Guseva < >>>>>>>>>>>> [email protected]> >>>>>>>>>>>> > > wrote: >>>>>>>>>>>> > > >>>>>>>>>>>> > >> Hello Pontus, >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> Oh, cool! Thanks a lot for your recommendation! >>>>>>>>>>>> > >> I will definitely look into it. >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> Eliza >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> On Tue, May 19, 2015 at 7:47 AM, Pontus Karlsson < >>>>>>>>>>>> > >> [email protected]> wrote: >>>>>>>>>>>> > >> >>>>>>>>>>>> > >>> Not sure on how far you've gotten on researching this, but >>>>>>>>>>>> as the model >>>>>>>>>>>> > >>> of asyncio is heavily inspired by the Twisted structure >>>>>>>>>>>> > >>> I would recommend trying to port txdbus >>>>>>>>>>>> > >>> <https://github.com/cocagne/txdbus> to asyncio. >>>>>>>>>>>> > >>> >>>>>>>>>>>> > >>> I was actually looking into doing this a month back and >>>>>>>>>>>> started to map >>>>>>>>>>>> > >>> the code structure and looking into what needs to be >>>>>>>>>>>> altered: >>>>>>>>>>>> > >>> >>>>>>>>>>>> > >>> - *authentication.py* - Zope interfaces, twisted logger >>>>>>>>>>>> > >>> - *bus.py* - twisted logger and Factory? >>>>>>>>>>>> > >>> - *client.py* - Heavy twisted usage >>>>>>>>>>>> > >>> - *endpoints.py* - Heavy twisted usage >>>>>>>>>>>> > >>> - error.py - No Twisted API usage >>>>>>>>>>>> > >>> - interface.py - No Twisted API usage >>>>>>>>>>>> > >>> - introspection.py - No Twisted API usage >>>>>>>>>>>> > >>> - marshal.py - No Twisted API usage >>>>>>>>>>>> > >>> - message.py - No Twisted API usage >>>>>>>>>>>> > >>> - *objects.py* - Zope interfaces, twisted defer >>>>>>>>>>>> > >>> - *protocol.py* - Zope interfaces, heavy twisted usage >>>>>>>>>>>> > >>> - *router.py* - Twisted log >>>>>>>>>>>> > >>> >>>>>>>>>>>> > >>> My recommended approach here is to fork it and abstract >>>>>>>>>>>> the event loop >>>>>>>>>>>> > >>> to work with both Twisted and asyncio. >>>>>>>>>>>> > >>> >>>>>>>>>>>> > >>> Den måndag 4 maj 2015 kl. 22:54:20 UTC+2 skrev Eliza >>>>>>>>>>>> Guseva: >>>>>>>>>>>> > >>>> >>>>>>>>>>>> > >>>> Hello all, >>>>>>>>>>>> > >>>> >>>>>>>>>>>> > >>>> First. Thanks a lot for choosing me as a student for your >>>>>>>>>>>> project!! >>>>>>>>>>>> > >>>> >>>>>>>>>>>> > >>>> As an international student in USA, I'm having some >>>>>>>>>>>> challenges with >>>>>>>>>>>> > >>>> bureaucratic system in my University. >>>>>>>>>>>> > >>>> It starts taking too long at the moment. So I'd better >>>>>>>>>>>> not wait even >>>>>>>>>>>> > >>>> longer and start communication now. >>>>>>>>>>>> > >>>> I have to warn: there might be issues with the system, >>>>>>>>>>>> but I'm trying >>>>>>>>>>>> > >>>> hard to get it work. >>>>>>>>>>>> > >>>> >>>>>>>>>>>> > >>>> On the brighter topic:) >>>>>>>>>>>> > >>>> As I understand it's time to read the documentation now. >>>>>>>>>>>> > >>>> Could you recommend me the reading, which suits the best >>>>>>>>>>>> for the >>>>>>>>>>>> > >>>> purposes of the project? >>>>>>>>>>>> > >>>> What source codes do you think, I should look into to get >>>>>>>>>>>> a better >>>>>>>>>>>> > >>>> understanding? >>>>>>>>>>>> > >>>> I will be asking questions, in the progress. >>>>>>>>>>>> > >>>> >>>>>>>>>>>> > >>>> Thanks a lot! >>>>>>>>>>>> > >>>> >>>>>>>>>>>> > >>> -- >>>>>>>>>>>> > >>> You received this message because you are subscribed to >>>>>>>>>>>> the Google >>>>>>>>>>>> > >>> Groups "qtile-dev" group. >>>>>>>>>>>> > >>> To unsubscribe from this group and stop receiving emails >>>>>>>>>>>> from it, send >>>>>>>>>>>> > >>> an email to [email protected]. >>>>>>>>>>>> > >>> For more options, visit https://groups.google.com/d/optout >>>>>>>>>>>> . >>>>>>>>>>>> > >>> >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> -- >>>>>>>>>>>> > >> You received this message because you are subscribed to a >>>>>>>>>>>> topic in the >>>>>>>>>>>> > >> Google Groups "qtile-dev" group. >>>>>>>>>>>> > >> To unsubscribe from this topic, visit >>>>>>>>>>>> > >> >>>>>>>>>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe >>>>>>>>>>>> . >>>>>>>>>>>> > >> To unsubscribe from this group and all its topics, send an >>>>>>>>>>>> email to >>>>>>>>>>>> > >> [email protected]. >>>>>>>>>>>> > >> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> > >> >>>>>>>>>>>> > > >>>>>>>>>>>> > > -- >>>>>>>>>>>> > > You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups >>>>>>>>>>>> > > "qtile-dev" group. >>>>>>>>>>>> > > To unsubscribe from this group and stop receiving emails >>>>>>>>>>>> from it, send an >>>>>>>>>>>> > > email to [email protected]. >>>>>>>>>>>> > > For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> > > >>>>>>>>>>>> > >>>>>>>>>>>> > -- >>>>>>>>>>>> > You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "qtile-dev" group. >>>>>>>>>>>> > To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> > For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "qtile-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to a topic >>>>>>>>>>> in the Google Groups "qtile-dev" group. >>>>>>>>>>> To unsubscribe from this topic, visit >>>>>>>>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe >>>>>>>>>>> . >>>>>>>>>>> To unsubscribe from this group and all its topics, send an email >>>>>>>>>>> to [email protected]. >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "qtile-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>> the Google Groups "qtile-dev" group. >>>>>>>> To unsubscribe from this topic, visit >>>>>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>>> [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to a topic in the >>>>>> Google Groups "qtile-dev" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "qtile-dev" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "qtile-dev" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "qtile-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "qtile-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the Google > Groups "qtile-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "qtile-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
