patchwork:stable/1.1

Last commit made on 2017-05-15
Get this branch:
git clone -b stable/1.1 https://git.launchpad.net/patchwork

Branch merges

Branch information

Name:
stable/1.1
Repository:
lp:patchwork

Recent commits

0a85e54... by Florian Fainelli on 2017-05-11

lib/apache2: Update location to wsgi python script

Commit 8fe68d96f18e ("wsgi: Move wsgi file to expected location")
relocated lib/apache2/patchwork.wsgi to patchwork/wsgi.py but did not
update the Apache2 example configuration file under
lib/apache2/patchwork.wsgi.conf.

Fixes: 8fe68d96f18e ("wsgi: Move wsgi file to expected location")
Signed-off-by: Florian Fainelli <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>
(cherry picked from commit 114ff6061d4005b2458e75da52f3a6cf4ae19bf5)

48c0e00... by Doug Anderson <email address hidden> on 2016-11-19

views: Don't munge the 'From' field of patches

At the moment patchwork always uses the official submitter name (as
patchwork understands it) as the "From" for patches that you receive.
This isn't quite what users expect and has some unfortunate
consequences.

The biggest problem is that patchwork saves the "official" name for an
email address the first time it sees an email from them. If that name
is wrong (or was missing) patchwork will be confused even if future
emails from this person are fixed. There are similar problems if a
user changes his/her name (get married?).

It seems better to just have each patch report the actual "From" that
was used to send that patch. We'll still return the submitter in
'X-Patchwork-Submitter' just in case someone wants it.

Conflicts:
 patchwork/tests/test_mboxviews.py

Reported-by: Wolfram Sang <email address hidden>
Signed-off-by: Doug Anderson <email address hidden>
Signed-off-by: Stephen Finucane <email address hidden>
(cherry picked from commit d365402fb98dfb2c4aea4b58346096f85bdfa0c3)

db885f9... by Stephen Finucane <email address hidden> on 2017-01-31

travis: Integrate on stable branch

This helps us detect regressions on the branch.

Signed-off-by: Stephen Finucane <email address hidden>
StableOnly

45a2c2c... by Stephen Finucane on 2016-03-24

tests: Don't override 'settings.DEBUG'

This isn't used, so remove it.

Signed-off-by: Stephen Finucane <email address hidden>
Closes-bug: #30
(cherry picked from commit aec764b7c5c8250185025f5b4d7c8fc47d9e3533)

cdeeaa7... by Robin Jarry on 2016-12-15

pwclient: Fix encoding problems

All data returned by the xmlrpc object is unicode decoded with 'utf-8' (on
python 3, unicode == str). Add from __future__ import unicode_literals
to make sure that everything is unicode and avoid surprises.

On python 2, printing unicode to stdout causes it to be encoded to str
(byte string) with the 'ascii' codec:

  >>> print some_unicode_string
  ...
  UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142'
  in position 468: ordinal not in range(128)

Work around ths by avoiding any explicit call to unicode() and by
replacing sys.stdout and sys.stderr by unicode-aware file objects (as
returned by io.open()).

Guess the encoding of stdout and stderr by looking at (in that order):
sys.stdout.encoding, locale.getpreferredencoding(), the PYTHONIOENCODING
environment variable. If no encoding is defined, assume 'utf-8' as
output encoding.

Conflicts:
    patchwork/bin/pwclient

Tested-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Stephen Finucane <email address hidden>
(cherry picked from commit 046419a3bf8f012fcb019c3ec8d78653da685908)

cfe8b7b... by Thomas Monjalon <thomas.monjalon@6wind.com> on 2016-12-13

pwclient: Fix Python 3 encoding of received strings

The conversion encode("utf-8") makes a byte stream which is
poorly printed with Python 3.
However this encoding is required for Popen.communicate() but must be
done after str.join() which applies to a real string.

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Stephen Finucane <email address hidden>
(cherry picked from commit 52654da17967a930a3cac962fc654e0d5de2855b)

Conflicts:
 patchwork/bin/pwclient

0d0d5c5... by Thomas Monjalon <thomas.monjalon@6wind.com> on 2016-12-13

pwclient: Support proxy configuration

The environment variables http_proxy and https_proxy can be used
to configure the HTTP transport.

The TCP connection is made with the proxy host, whereas the original host
is maintained in the HTTP POST URI via "handler" in "send_request".

The send_request() method of xmlrpclib has a different signature
and behaviour in Python 2 and 3.

Fixes #47

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Stephen Finucane <email address hidden>
(cherry picked from commit 53fe8b16431833b7bff6271c41ca8b79b0a7701e)

3141f74... by Thomas Monjalon <thomas.monjalon@6wind.com> on 2016-12-13

pwclient: Rework HTTP authentication

Transform the HTTP authentication class into a generic transport class.
The credentials become optional so this transport class is always used.

A side effect is to fix the Python 3 support for the authentication.
Fixes #59

It will help to bring proxy support while combining http/https and
authentication cases.

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Stephen Finucane <email address hidden>
(cherry picked from commit 0bcb1bf6466461043bcb84c4856166105d5d5738)

424617b... by Stephen Finucane on 2016-09-25

Revert "Allow assigning of any user as delegate"

This reverts commit e0fd7cd91a5fbe0a0077c46bea870ccd09c8920d.

This change does not scale with a larger number of lists, and clearly
needs more work. Revert until such a time as this is carried out.

Signed-off-by: Stephen Finucane <email address hidden>
(cherry picked from commit 198139e4112cf337ffea403000441931b4ddad06)

6703cb5... by Daniel Axtens on 2016-09-19

parser: parse headers containing invalid characters or codings

If there is a non-ascii character in a header, parsing fails,
even on Py27.

This has huge Py2/Py3 complexities. The Py3 email package has tools
to handle this - we just need to use them. Py2, on the other hand,
needs a lot of hand-holding, as explained in the comments.

Additionally, support headers that claim an encoding, but fail to
decode with that encoding.

This is handy for mails with malformed headers containing weird
bytes.

Signed-off-by: Daniel Axtens <email address hidden>
Reported-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Stephen Finucane <email address hidden>
(cherry picked from commit 6625d4b0dcdf1820b73227c40118625d4db9e130)