Patchwork

lp:patchwork

Created by Jeremy Kerr on 2015-11-06 and last modified on 2019-09-18
Get this branch:
bzr branch lp:patchwork

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Patchwork Devs
Project:
Patchwork
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at https://github.com/getpatchwork/patchwork.git.

The next import is scheduled to run in 1 minute.

Last successful import was 5 hours ago.

Import started 5 hours ago on alnitak and finished 5 hours ago taking 20 seconds — see the log
Import started 12 hours ago on alnitak and finished 12 hours ago taking 20 seconds — see the log
Import started 18 hours ago on alnitak and finished 18 hours ago taking 20 seconds — see the log
Import started on 2019-09-21 on alnitak and finished on 2019-09-21 taking 20 seconds — see the log
Import started on 2019-09-21 on alnitak and finished on 2019-09-21 taking 20 seconds — see the log
Import started on 2019-09-20 on alnitak and finished on 2019-09-20 taking 20 seconds — see the log
Import started on 2019-09-20 on alnitak and finished on 2019-09-20 taking 20 seconds — see the log
Import started on 2019-09-20 on alnitak and finished on 2019-09-20 taking 20 seconds — see the log
Import started on 2019-09-19 on alnitak and finished on 2019-09-19 taking 20 seconds — see the log
Import started on 2019-09-19 on alnitak and finished on 2019-09-19 taking 20 seconds — see the log

Recent revisions

1592. By Daniel Axtens on 2019-09-18

parsearchive, mail: use repr() to get a human readable exception

Currently if we have particular types of error in mail parsing
in parsearchive or parsemail, we print exc.message, which doesn't
always work:

  Traceback (most recent call last):
    File ".../patchwork/management/commands/parsearchive.py", line 90, in handle
      obj = parse_mail(msg, options['list_id'])
    File ".../patchwork/parser.py", line 961, in parse_mail
      raise ValueError("Missing 'Message-Id' header")
  ValueError: Missing 'Message-Id' header

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
    File "manage.py", line 11, in <module>
      execute_from_command_line(sys.argv)
    File ".../django/core/management/__init__.py", line 381, in execute_from_command_line
      utility.execute()
    File ".../django/core/management/__init__.py", line 375, in execute
      self.fetch_command(subcommand).run_from_argv(self.argv)
    File ".../django/core/management/base.py", line 323, in run_from_argv
      self.execute(*args, **cmd_options)
    File ".../django/core/management/base.py", line 364, in execute
      output = self.handle(*args, **options)
    File ".../patchwork/management/commands/parsearchive.py", line 100, in handle
      logger.warning('Invalid mail: %s', exc.message)
  AttributeError: 'ValueError' object has no attribute 'message'

repr(exc) will work. Use it.

Signed-off-by: Daniel Axtens <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>

1591. By Daniel Axtens on 2019-09-18

tests: make test suite pass with XML-RPC disabled

Handy for development purposes.

Signed-off-by: Daniel Axtens <email address hidden>
Reviewed-by: Stephen Finucane <email address hidden>

1590. By Andrew Donnellan <email address hidden> on 2019-09-13

templates: Use 'static' rather than 'statictags' library

statictags is being renamed to static, use of {% load statictags %} is
deprecated and will break in Django 3.

Signed-off-by: Andrew Donnellan <email address hidden>
Signed-off-by: Daniel Axtens <email address hidden>

1589. By Stephen Finucane <email address hidden> on 2019-09-10

requirements: Use compatible MINOR releases

'~= 2.2' will match '2.2.N', '2.3.N', etc. but not '3.0.N'. What we want
in most cases is to match '2.2.N' only. Ensure this is the case.

Signed-off-by: Stephen Finucane <email address hidden>
Fixes: c90473ea ("requirements: Switch to compatible releases")

1588. By Stephen Finucane <email address hidden> on 2019-09-10

requirements: Switch to compatible releases

In commit ab0c443691, we switched from using commit ranges to fixed
ranges. This was a good idea in so far as it ensures we're providing an
application with dependencies that are guaranteed to work. However,
Patchwork as a project isn't active enough to warrant the continued busy
work effort necessary to keep bumping these versions and it's probably
about time to abandon the experiment. However, rather than switching
back to version ranges, use the compatible releases feature introduced
in PEP 440 [1]. This gives us most of the benefits of ranges but with a
nicer syntax.

[1] https://www.python.org/dev/peps/pep-0440/#compatible-release

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

1587. By pyup-bot <email address hidden> on 2019-09-09

Update sphinxcontrib-openapi from 0.4.0 to 0.5.0

1586. By Stephen Finucane <email address hidden> on 2019-09-09

Add support for django-debug-toolbar 2.0

We retain support for 1.11 when running with Python 2.7.

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

1585. By Stephen Finucane <email address hidden> on 2019-09-09

Add support for djangorestframework 3.10

This is necessary for proper Django 2.2 support. We retain support for
older versions since 3.10 is Python 3-only.

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

1584. By Stephen Finucane <email address hidden> on 2019-09-09

docs: Use '>=' in OpenAPI schema template

This is consistent with how we're doing checks for v1.2 and reads a
little better, IMO.

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

1583. By pyup-bot <email address hidden> on 2019-09-09

Update mysqlclient from 1.3.14 to 1.4.4

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers