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 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.
