That makes perfect sense, thanks! I've merged it. I will prepare a release for voting, later today or tomorrow.
On 12/3/15 7:09 AM, Igor Bondarenko wrote: > I have just checked with "forget password" feature to generate emails. > > For me messages are showing, but only if you have two in a row. What I mean > by that is that when first message is getting send I don't see and output, > unless I trigger second message send and then outmail shows *both*. > > Seems like a problem with buffering stdout. `python -u` helps! > > Created a merge request > https://forge-allura.apache.org/p/allura/git/merge-requests/54/ > > > > On Wed, Dec 2, 2015 at 10:06 PM, Dave Brondsema <[email protected]> wrote: > >> Igor, can you check and see if `docker-compose logs outmail` works for >> you? It >> isn't working for me now. Not sure if it's a new issue or old, but might >> be >> good for us to figure it out too before a release. >> >> Messages are getting to the smtpd DebuggingServer; I checked by connecting: >> `docker exec -it allura_outmail_1 bash` then installing strace and >> watching that >> process. Nothing prints to stdout/logs though. >> >> On 12/2/15 7:33 AM, Igor Bondarenko wrote: >>> Fix for it is in master. You might want to rebuild your images. >>> >>> https://forge-allura.apache.org/p/allura/tickets/8028/ >>> >>> On Tue, Dec 1, 2015 at 12:17 PM, Igor Bondarenko <[email protected]> >> wrote: >>> >>>> I have run into this myself a couple of times. Stopping and deleting all >>>> containers with "docker-compose rm -f" after requirements update and >> then >>>> starting them again with "docker-compos up -d" fixed that for me. >>>> >>>> I agree it's annoying and we should do something about it. virtualenv >>>> sounds good if we can set PATH to avoid activating it manually on every >>>> command. >>>> >>>> On Mon, Nov 30, 2015 at 10:35 PM, heith seewald <[email protected]> >> wrote: >>>> >>>>> I'm not sure why that started happening -- but I do think using a >> virtual >>>>> env is a good solution. >>>>> >>>>> On Mon, Nov 30, 2015 at 3:31 PM, Dave Brondsema <[email protected]> >>>>> wrote: >>>>> >>>>>> I was rebuilding my docker environment and ran into a problem. We >>>>> install >>>>>> directly into the system python location (no virtualenv needed if in >>>>>> docker), >>>>>> and that location /usr/local/lib/python2.7 is shared between our >>>>>> containers so >>>>>> they all have the same packages installed at once. This had been >>>>> working >>>>>> fine >>>>>> for me. >>>>>> >>>>>> With my rebuild, I started getting errors with the version of "six" >>>>>> because the >>>>>> system comes with an older version of "six" and ubuntu has pip set up >> to >>>>>> not >>>>>> override that: >>>>>> >>>>>> Downloading/unpacking six==1.7.3 (from -r requirements.txt (line 45)) >>>>>> Downloading six-1.7.3-py2.py3-none-any.whl >>>>>> ... >>>>>> Found existing installation: six 1.5.2 >>>>>> Not uninstalling requests at /usr/lib/python2.7/dist-packages, >> owned >>>>>> by OS >>>>>> >>>>>> This also happens with "chardet" and "requests" but they happen to be >>>>>> newer than >>>>>> what we list in requirements.txt And we can't just use the older >>>>> version >>>>>> of >>>>>> "six" because paster throws this error: >>>>>> >>>>>> ... >>>>>> pkg_resources.VersionConflict: (six 1.5.2 >>>>>> (/usr/lib/python2.7/dist-packages), >>>>>> Requirement.parse('six>=1.6.1')) >>>>>> >>>>>> I tried using ubuntu 15.10 instead of 14.04 (LTS) but it runs into >>>>> issues >>>>>> with >>>>>> "requests", quite possibly because the versions are wrong with that >> too. >>>>>> >>>>>> We wouldn't want to use wrong versions of any packages anyway, even if >>>>> we >>>>>> could >>>>>> somehow force it to work. >>>>>> >>>>>> So, I am thinking we should actually use a virtualenv inside the >>>>>> containers, so >>>>>> we get the packages we want and don't get interference from the system >>>>>> packages. >>>>>> It should be easy to add that to the build steps, but it'll probably >>>>> mean >>>>>> longer commands when running paster commands, to make sure you're in >> the >>>>>> venv. >>>>>> Unless we can find some way to always set the PATH. >>>>>> >>>>>> I don't know why this started happening all of a sudden though. Any >>>>>> ideas? We >>>>>> should fix before making a release, since our recommended installation >>>>>> path no >>>>>> longer works :( >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dave Brondsema : [email protected] >>>>>> http://www.brondsema.net : personal >>>>>> http://www.splike.com : programming >>>>>> <>< >>>>>> >>>>> >>>> >>>> >>> >> >> >> >> -- >> Dave Brondsema : [email protected] >> http://www.brondsema.net : personal >> http://www.splike.com : programming >> <>< >> > -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
