From ml.richard.vezina at gmail.com Thu Oct 1 17:51:28 2015 From: ml.richard.vezina at gmail.com (=?UTF-8?Q?Richard_V=C3=A9zina?=) Date: Thu, 1 Oct 2015 11:51:28 -0400 Subject: [pytest-dev] pytest plugin pytest-session_to_file Message-ID: Hello, I just create this : https://pypi.python.org/pypi/pytest-session_to_file/0.1.0 Git repo: https://github.com/BuhtigithuB/pytest-session_to_file Could someone review it and make comment and eventually update the pytest plugin index page and include it there... Pytest Plugins Index not have been updated since june 30 https://pytest.org/latest/plugins_index/index.html :) Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Oct 1 17:55:23 2015 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 01 Oct 2015 15:55:23 +0000 Subject: [pytest-dev] pytest plugin pytest-session_to_file In-Reply-To: References: Message-ID: Hi Richard, Thanks for the pointer. We have to integrate the plugin_index script into the gendoc Makefile target. Cheers, Bruno. On Thu, Oct 1, 2015 at 12:51 PM Richard V?zina wrote: > Hello, > > I just create this : > > https://pypi.python.org/pypi/pytest-session_to_file/0.1.0 > Git repo: https://github.com/BuhtigithuB/pytest-session_to_file > > Could someone review it and make comment and eventually update the pytest > plugin index page and include it there... > > Pytest Plugins Index not have been updated since june 30 > https://pytest.org/latest/plugins_index/index.html > > :) > > Richard > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raphael at hackebrot.de Wed Oct 7 13:29:51 2015 From: raphael at hackebrot.de (Raphael Pierzina) Date: Wed, 7 Oct 2015 13:29:51 +0200 Subject: [pytest-dev] Feedback on Cookiecutter Pytest Plugin Message-ID: Hi there, At EuroPython 2015 Andreas and I sprinted on a Cookiecutter [1] template that helps you to get started with writing Pytest plugins. I am reaching out to you as I would love to get some feedback. I warmly welcome you to submit issues and PRs. Please let me know if you feel the need for a certain feature or encounter any problems with the template. https://github.com/pytest-dev/cookiecutter-pytest-plugin Up to this point it provides the following features: - Installable PyPI package featuring a setup.py. - Test suite running Tox and Pytest that makes sure your plugin is working as expected - Working example code for a fixture, a cli option, as well as a pytest.ini option - Comprehensive README.rst file that contains useful information about your plugin - Optional documentation with either Sphinx or MkDocs - Choose from several licenses, such as MIT, BSD-3, or GNU GPL v3.0 Thank you! Raphael [1]: https://github.com/audreyr/cookiecutter A command-line utility that creates projects from cookiecutters (project templates). E.g. Python package projects, jQuery plugin projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Oct 7 18:05:52 2015 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 7 Oct 2015 18:05:52 +0200 Subject: [pytest-dev] pytest 2.8.2 released Message-ID: <20151007160552.GF3107@tonks> Hey, I'm happy to announce pytest 2.8.2 has been released. In case you wonder, pytest is a widely used mature test runner both for unit and functional test purposes in python. See http://pytest.org for documentation and examples. Among other things, this release fixes a regression introduced in 2.8.1 when using parametrize with encoded byte strings: - fix #1085: proper handling of encoding errors when passing encoded byte strings to pytest.parametrize in Python 2. Thanks Themanwithoutaplan for the report and Bruno Oliveira for the PR. - fix #1087: handling SystemError when passing empty byte strings to pytest.parametrize in Python 3. Thanks Paul Kehrer for the report and Bruno Oliveira for the PR. - fix #995: fixed internal error when filtering tracebacks where one entry was generated by an exec() statement. Thanks Daniel Hahler, Ashley C Straw, Philippe Gauthier and Pavel Savchenko for contributing and Bruno Oliveira for the PR. Thanks to all who contributed to this release, among them: Bruno Oliveira Demian Brecht Florian Bruhin Ionel Cristian M?rie? Raphael Pierzina Ronny Pfannschmidt holger krekel There are still some regressions open from 2.8, among them an issue when using objects with a custom __getattr__ with Python 2.6: https://github.com/pytest-dev/pytest/issues/1035 Fixes for those issues are in progress, and there hopefully will be a 2.8.3 release soon. Thanks for flying pytest and sorry for the turbulences! ;) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From me at the-compiler.org Wed Oct 7 20:16:51 2015 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 7 Oct 2015 20:16:51 +0200 Subject: [pytest-dev] First release of pytest-vw! Message-ID: <20151007181650.GG3107@tonks> Hey, I'm happy to announce the first release of pytest-vw, a pytest plugin which makes failing test cases succeed in continuous integration tools. See https://github.com/The-Compiler/pytest-vw for more information. Of course, any similarities with a current event concerning (but not limited to) a multinational automobile manufacturer are purely coincidental. (In all seriousness: This was mainly to try the excellent cookiecutter[1] and cookiecutter-pytest-plugin[2] projects - it's also inspired by (read: a blatant ripoff of) PHPunit VW) [1] https://github.com/audreyr/cookiecutter [2] https://github.com/pytest-dev/cookiecutter-pytest-plugin [3] https://github.com/hmlb/phpunit-vw Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ml.richard.vezina at gmail.com Wed Oct 14 05:26:54 2015 From: ml.richard.vezina at gmail.com (=?UTF-8?Q?Richard_V=C3=A9zina?=) Date: Tue, 13 Oct 2015 23:26:54 -0400 Subject: [pytest-dev] pytest plugin pytest-session_to_file In-Reply-To: References: Message-ID: I finally get time to figure out why my packaging were failing... So here the first fully working version of pytest_session2file : https://pypi.python.org/pypi/pytest-session2file/0.1.5 Richard On Thu, Oct 1, 2015 at 11:55 AM, Bruno Oliveira wrote: > Hi Richard, > > Thanks for the pointer. We have to integrate the plugin_index script into > the gendoc Makefile target. > > Cheers, > Bruno. > > On Thu, Oct 1, 2015 at 12:51 PM Richard V?zina < > ml.richard.vezina at gmail.com> wrote: > >> Hello, >> >> I just create this : >> >> https://pypi.python.org/pypi/pytest-session_to_file/0.1.0 >> Git repo: https://github.com/BuhtigithuB/pytest-session_to_file >> >> Could someone review it and make comment and eventually update the pytest >> plugin index page and include it there... >> >> Pytest Plugins Index not have been updated since june 30 >> https://pytest.org/latest/plugins_index/index.html >> >> :) >> >> Richard >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldar.abusalimov at gmail.com Fri Oct 16 15:05:39 2015 From: eldar.abusalimov at gmail.com (Eldar Abusalimov) Date: Fri, 16 Oct 2015 16:05:39 +0300 Subject: [pytest-dev] [ANN] pytest-travis-fold plugin Message-ID: Hi, I'm pleased to announce a new pytest-travis-fold plugin that provides better look and feel when using Travis CI. Once installed it makes captured stdout / stderr sections of failing tests appear folded in the Travis CI build log view. To enable it, add this install step to .travis.yml: install: - pip install pytest-travis-fold You may install it either through .travis.yml, tox.ini, setup.py requirements, ... - whatever you find appropriate. In any case it won't interfere with your dev environment; it is only activated when it detects the Travis CI environment, or by using the --travis-fold command line switch (in general, you won't need it though). GitHub: https://github.com/abusalimov/pytest-travis-fold PyPI: https://pypi.python.org/pypi/pytest-travis-fold I'd be happy to get your feedback!? -- Best regards, Eldar Sh. Abusalimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldar.abusalimov at gmail.com Sun Oct 18 22:44:11 2015 From: eldar.abusalimov at gmail.com (Eldar Abusalimov) Date: Sun, 18 Oct 2015 23:44:11 +0300 Subject: [pytest-dev] [ANN] pytest-travis-fold plugin In-Reply-To: References: Message-ID: Hi again, I've just discovered that installing a package through .travis.yml while using tox doesn't work as expected since tox creates a fresh venv each time. I updated setup howto in the README and released v1.0.1. Duplicating installation steps here to avoid the confusion: When using tox, add the package to the 'deps' list in your tox.ini: [testenv] deps = pytest-travis-fold If you **don't** use tox and invoke py.test directly from .travis.yml, you may install the package as an additional 'install' step:: install: - pip install -e . - pip install pytest-travis-fold script: py.test Sorry for spamming the mailing list. On Fri, Oct 16, 2015 at 4:05 PM, Eldar Abusalimov < eldar.abusalimov at gmail.com> wrote: > Hi, > > I'm pleased to announce a new pytest-travis-fold plugin that provides > better look and feel when using Travis CI. Once installed it makes captured > stdout / stderr sections of failing tests appear folded in the Travis CI > build log view. > > > To enable it, add this install step to .travis.yml: > > install: > - pip install pytest-travis-fold > > You may install it either through .travis.yml, tox.ini, setup.py > requirements, ... - whatever you find appropriate. In any case it won't > interfere with your dev environment; it is only activated when it detects > the Travis CI environment, or by using the --travis-fold command line > switch (in general, you won't need it though). > > > GitHub: https://github.com/abusalimov/pytest-travis-fold > PyPI: https://pypi.python.org/pypi/pytest-travis-fold > > > I'd be happy to get your feedback!? > > > -- > Best regards, > Eldar Sh. Abusalimov > -- Regards, Eldar -------------- next part -------------- An HTML attachment was scrubbed... URL: From eisensheng at mailbox.org Mon Oct 19 23:17:24 2015 From: eisensheng at mailbox.org (Arthur Skowronek) Date: Mon, 19 Oct 2015 23:17:24 +0200 Subject: [pytest-dev] pytest-capturelog status/merging to core? In-Reply-To: References: <20150925094316.GB26059@merlinux.eu> <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks> <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de> <20150925175526.GE26059@merlinux.eu> Message-ID: <56255DE4.2050104@mailbox.org> Hi anyone, the motivation for me behind forking the original plugin was to slightly extend the provided API and to welcome patches and thus resurrect the plugin from an unmaintained state. I was simply fed up with how many python projects become abandoned. As far as this goes I'm not sure if I'm even allowed to say much about the project since my contribution to it amounts to a bare minimum. I understand myself as a mere gateway that takes care of patches, documents them and manages releases of new versions. A role that can be fulfilled by anyone on the list here. So I'm not important at all in making a decision here. With this out of the way I still would like to state my opinion though. It would be nice if the plugin could stay separated from the core package. At least I am a huge fan of the modular plugin system as it can be found in pytest. I find such a modular design more preferable compared to a monolithic project that comes with everything attached. Such a large project makes it harder for users to track what was changed between versions and keep track of changes important to them. They don't need to care at all if the API was changed but they don't use the plugin. Also different contributors stated that they still would like to improve the code base and add more functionality. It would be nice to give them their freedom to break the API if necessary to create something even more usable with a sleeker API. I'm looking forward to it. As far as the naming goes I can understand that it makes sense to rename the plugin to pytest-logging. The current name was chosen just to avoid naming conflicts on the PyPI. But over time I've grown attached to it. :) I hoped that we could find someone that would draw a nice dream catcher as a logo for us that would decorate the documentation I also wanted to write. Maybe we can a find a compromise here, something like pytest-logging-catcher or so? Thus I'm suggesting the following game plan: * Releasing the current development state as 1.2 It matured well enough and it will mark the last release of the 1.x API family which stays compatible to the existing API of the plugin and future versions of pytest. I would also like to stay consistent to semver as it appears to me to be a sane specification for treating versioning. * Renaming the project to pytest-logging(-catcher) This step speaks for itself. * Move under the pytest-dev organization This should be the home of the plugin after all. * Granting Access to PyPI and Github to more maintainers I would love to recommend Eldar Abusalimov as a maintainer for the plugin. He contributed by far more than compared to me and he knows what he does. * Providing some nice documentation aside from the Readme Hell yeah. Optionally: * Taking my exit As stated above I don't see where I fit in the bigger picture. I'm not important to continue the project at all. My day job keeps me busy enough so I won't be able to land bigger improvements on the plugin. All I can offer is to merge patches and take care of other issues. Then again these chores can be done by anyone else with more time on his/her hands. Please let me know what you think about these points. Thanks! Greetings, Arthur -- Arthur Skowronek M: eisensheng at mailbox.org From eldar.abusalimov at gmail.com Tue Oct 20 02:24:50 2015 From: eldar.abusalimov at gmail.com (Eldar Abusalimov) Date: Tue, 20 Oct 2015 03:24:50 +0300 Subject: [pytest-dev] pytest-capturelog status/merging to core? In-Reply-To: <56255DE4.2050104@mailbox.org> References: <20150925094316.GB26059@merlinux.eu> <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks> <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de> <20150925175526.GE26059@merlinux.eu> <56255DE4.2050104@mailbox.org> Message-ID: Hi Arthur, Please don't underestimate your contribution. Without your initial effor we probably would still be grumbling and using the obsolete plugin. ;-) One thing I'd like to mention is that pytest-catchlog _is not_ fully compatible with the old pytest-capturelog at the moment, although differences are minimal (set_level <-> setLevel, etc.). As for the name, I'm fine with both pytest-catchlog and pytest-logging options. On Tue, Oct 20, 2015 at 12:17 AM, Arthur Skowronek wrote: > Hi anyone, > > the motivation for me behind forking the original plugin was to slightly > extend the provided API and to welcome patches and thus resurrect the > plugin from an unmaintained state. I was simply fed up with how many > python projects become abandoned. As far as this goes I'm not sure if I'm > even allowed to say much about the project since my contribution to it > amounts to a bare minimum. I understand myself as a mere gateway that > takes care of patches, documents them and manages releases of new > versions. A role that can be fulfilled by anyone on the list here. So I'm > not important at all in making a decision here. > > With this out of the way I still would like to state my opinion though. > > It would be nice if the plugin could stay separated from the core > package. At least I am a huge fan of the modular plugin system as it can > be found in pytest. I find such a modular design more preferable compared > to a monolithic project that comes with everything attached. Such a large > project makes it harder for users to track what was changed between > versions and keep track of changes important to them. They don't need to > care at all if the API was changed but they don't use the plugin. > > Also different contributors stated that they still would like to improve > the code base and add more functionality. It would be nice to give them > their freedom to break the API if necessary to create something even more > usable with a sleeker API. I'm looking forward to it. > > As far as the naming goes I can understand that it makes sense to rename > the plugin to pytest-logging. The current name was chosen just to avoid > naming conflicts on the PyPI. But over time I've grown attached to it. :) > I hoped that we could find someone that would draw a nice dream catcher as > a logo for us that would decorate the documentation I also wanted to > write. Maybe we can a find a compromise here, something like > pytest-logging-catcher or so? > > Thus I'm suggesting the following game plan: > > * Releasing the current development state as 1.2 > > It matured well enough and it will mark the last release of the 1.x API > family which stays compatible to the existing API of the plugin and future > versions of pytest. I would also like to stay consistent to semver as it > appears to me to be a sane specification for treating versioning. > > * Renaming the project to pytest-logging(-catcher) > > This step speaks for itself. > > * Move under the pytest-dev organization > > This should be the home of the plugin after all. > > * Granting Access to PyPI and Github to more maintainers > > I would love to recommend Eldar Abusalimov as a maintainer for the > plugin. He contributed by far more than compared to me and he knows what > he does. > > * Providing some nice documentation aside from the Readme > > Hell yeah. > > Optionally: > > * Taking my exit > > As stated above I don't see where I fit in the bigger picture. I'm not > important to continue the project at all. My day job keeps me busy enough > so I won't be able to land bigger improvements on the plugin. All I can > offer is to merge patches and take care of other issues. Then again these > chores can be done by anyone else with more time on his/her hands. > > > Please let me know what you think about these points. Thanks! > > > Greetings, > Arthur > > -- > Arthur Skowronek > M: eisensheng at mailbox.org > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- Regards, Eldar -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Tue Oct 20 06:20:42 2015 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 20 Oct 2015 06:20:42 +0200 Subject: [pytest-dev] pytest-capturelog status/merging to core? In-Reply-To: <56255DE4.2050104@mailbox.org> References: <20150925094316.GB26059@merlinux.eu> <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks> <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de> <20150925175526.GE26059@merlinux.eu> <56255DE4.2050104@mailbox.org> Message-ID: <20151020042042.GR29343@tonks> Hey, * Arthur Skowronek [2015-10-19 23:17:24 +0200]: > It would be nice if the plugin could stay separated from the core package. > At least I am a huge fan of the modular plugin system as it can be found in > pytest. I find such a modular design more preferable compared to a > monolithic project that comes with everything attached. Such a large project > makes it harder for users to track what was changed between versions and > keep track of changes important to them. They don't need to care at all if > the API was changed but they don't use the plugin. > > Also different contributors stated that they still would like to improve the > code base and add more functionality. It would be nice to give them their > freedom to break the API if necessary to create something even more usable > with a sleeker API. I'm looking forward to it. I used to have a different stance on this - but after reconsidering, I agree it'd be best to have a "recommended" plugin (i.e. catchlog, as it's maintained and under pytest-dev) rather than merge things into core. > As far as the naming goes I can understand that it makes sense to rename the > plugin to pytest-logging. The current name was chosen just to avoid naming > conflicts on the PyPI. But over time I've grown attached to it. :) I hoped > that we could find someone that would draw a nice dream catcher as a logo > for us that would decorate the documentation I also wanted to write. Maybe > we can a find a compromise here, something like pytest-logging-catcher or > so? FWIW, I'm -1 on renaming anything. There's already enough confusion with why there's catchlog and capturelog, and now renaming catchlog to logging will IMHO just increase that confusion. I love the idea with the dream catcher! > * Granting Access to PyPI and Github to more maintainers > > I would love to recommend Eldar Abusalimov as a maintainer for the plugin. > He contributed by far more than compared to me and he knows what he does. +1 if he's okay with that. I'm happy to be some kind of co-maintainer if you want, maybe with some similar workflow like with pytest core - everything happens via PRs so there's someone who can review the code. > Optionally: > > * Taking my exit > > As stated above I don't see where I fit in the bigger picture. I'm not > important to continue the project at all. My day job keeps me busy enough > so I won't be able to land bigger improvements on the plugin. All I can > offer is to merge patches and take care of other issues. Then again these > chores can be done by anyone else with more time on his/her hands. I think everyone has less time on their hands than desired - so I'd personally like to keep you as maintainer/gatekeeper/releaser/ whateveryoucallit as well. Doesn't hurt to have someone more involved - even though you might end up not actually *doing* much in practise anymore, if you prefer. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From flub at devork.be Tue Oct 20 13:52:46 2015 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 20 Oct 2015 12:52:46 +0100 Subject: [pytest-dev] [ANN] pytest-travis-fold plugin In-Reply-To: References: Message-ID: On 18 October 2015 at 21:44, Eldar Abusalimov wrote: > > Sorry for spamming the mailing list. It's not spamming, you're more then welcome to use the list to announce and talk about your plugin. Thanks for contributing to the py.test ecosystem! Floris From eisensheng at mailbox.org Tue Oct 20 22:26:18 2015 From: eisensheng at mailbox.org (Arthur Skowronek) Date: Tue, 20 Oct 2015 22:26:18 +0200 Subject: [pytest-dev] pytest-capturelog status/merging to core? In-Reply-To: <20151020042042.GR29343@tonks> References: <20150925094316.GB26059@merlinux.eu> <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks> <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de> <20150925175526.GE26059@merlinux.eu> <56255DE4.2050104@mailbox.org> <20151020042042.GR29343@tonks> Message-ID: <5626A36A.40501@mailbox.org> > FWIW, I'm -1 on renaming anything. There's already enough confusion > with why there's catchlog and capturelog, and now renaming catchlog to > logging will IMHO just increase that confusion. Good point. I would also recommend to consider this. > +1 if he's okay with that. I'm happy to be some kind of co-maintainer > if you want, maybe with some similar workflow like with pytest core - > everything happens via PRs so there's someone who can review the code. Sorry, I thought it was obvious that you'll also be included in the maintainer group since you approached me long before and you're among the most experienced with pytest itself and currently involved with pytest-catchlog. :) The PR workflow is how I usually work and prefer to work so I'm perfectly fine with this. Having someone else looking over the change set and sharing his opinion/experience is always a benefit. > I think everyone has less time on their hands than desired - so I'd > personally like to keep you as maintainer/gatekeeper/releaser/ > whateveryoucallit as well. > > Doesn't hurt to have someone more involved - even though you might end > up not actually *doing* much in practise anymore, if you prefer. I would be glad to help out this way if this level of engagement is enough and still desired. -- Arthur Skowronek M: eisensheng at mailbox.org From eldar.abusalimov at gmail.com Wed Oct 21 02:04:01 2015 From: eldar.abusalimov at gmail.com (Eldar Abusalimov) Date: Wed, 21 Oct 2015 03:04:01 +0300 Subject: [pytest-dev] pytest-capturelog status/merging to core? In-Reply-To: <20151020042042.GR29343@tonks> References: <20150925094316.GB26059@merlinux.eu> <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks> <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de> <20150925175526.GE26059@merlinux.eu> <56255DE4.2050104@mailbox.org> <20151020042042.GR29343@tonks> Message-ID: ?Hi,? > * Granting Access to PyPI and Github to more maintainers > > > > I would love to recommend Eldar Abusalimov as a maintainer for the > plugin. > > He contributed by far more than compared to me and he knows what he does. > > +1 if he's okay with that. > ? > ? > I'm happy to be some kind of co-maintainer? ?Sure, why not.? ?FWIW, I've submitted a PR that gets the backward compatibility ?with pytest-capturelog back: https://github.com/eisensheng/pytest-catchlog/pull/11 -- Regards, Eldar -------------- next part -------------- An HTML attachment was scrubbed... URL: