Patchwork is a web-based patch tracking system designed to facilitate the contribution and management of contributions to an open-source project.

Related tags

SCMpatchwork
Overview

Patchwork

Requirements Status Codecov Build Status Documentation Status

Patchwork is a patch tracking system for community-based projects. It is intended to make the patch management process easier for both the project's contributors and maintainers, leaving time for the more important (and more interesting) stuff.

Patches that have been sent to a mailing list are "caught" by the system, and appear on a web page. Any comments posted that reference the patch are appended to the patch page too. The project's maintainer can then scan through the list of patches, marking each with a certain state, such as Accepted, Rejected or Under Review. Old patches can be sent to the archive or deleted.

Currently, Patchwork is being used for a number of open-source projects, mostly subsystems of the Linux kernel. Although Patchwork has been developed with the kernel workflow in mind, the aim is to be flexible enough to suit the majority of community projects.

Requirements

Patchwork requires reasonably recent versions of:

  • Python 3
  • Django
  • Django REST Framework
  • Django Filters

The precise versions supported are listed in the release notes.

Development Installation

Docker is the recommended installation method for a Patchwork development environment. To install Patchwork:

  1. Install Docker and docker-compose.

  2. Clone the Patchwork repo:

    $ git clone https://github.com/getpatchwork/patchwork.git
    
  3. Create a .env file in the root directory of the project and store your UID and GID attributes there:

    $ cd patchwork && printf "UID=$(id -u)\nGID=$(id -g)\n" > .env
    
  4. Build the images. This will download a number of packages from the internet, and compile several versions of Python:

    $ docker-compose build
    
  5. Run docker-compose up:

    $ docker-compose up
    

The Patchwork instance will now be deployed at http://localhost:8000/.

For more information, including helpful command line options and alternative installation methods, refer to the documentation.

Talks and Presentations

  • Mailing List, Meet CI (slides) - FOSDEM 2017
  • Patches carved into stone tablets (slides) - Kernel Recipes Conference 2016
  • A New Patchwork (slides) - FOSDEM 2016
  • Patchwork: reducing your patch workload (slides) - Linux Plumbers Conference 2011

Additional Information

For further information, refer to the documentation.

Contact

For bug reports, patch submissions or other questions, use the mailing list.

Comments
  • Influence the display for the maximum number of search results

    Influence the display for the maximum number of search results

    Searches are supported by this software. The number of presented search results can be limited on a web page. I would occasionally like to increase the corresponding maximum. Can the row count be specified by an URL parameter?

    question 
    opened by elfring 15
  • Add anchors to message sections

    Add anchors to message sections

    opened by elfring 14
  • [v2.2.0] failure to migrate from stable/2.1

    [v2.2.0] failure to migrate from stable/2.1

    Migrations fail to apply when moving from stable/2.1 to v2.2.0-rc1.

    To reproduce:

    $ manage.py makemigrations --merge

    Note that makemigrations fails w/o --merge with:

    CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0027_auto_20200203_2113, 0039_unique_series_references in patchwork).
    To fix them run 'python manage.py makemigrations --merge'
    

    But I guess it's expected since https://github.com/getpatchwork/patchwork/commit/9f72eb793dfb6e9d7ff54465d4b07291e9a75e38?

    $ manage.py migrate

    Result:

    Operations to perform:
      Apply all migrations: admin, auth, authtoken, contenttypes, patchwork, sessions, sites
    Running migrations:
      Applying admin.0003_logentry_add_action_flag_choices... OK
      Applying auth.0009_alter_user_last_name_max_length... OK
      Applying auth.0010_alter_group_name_max_length... OK
      Applying auth.0011_update_proxy_permissions... OK
      Applying patchwork.0027_remove_series_ordering... OK
      Applying patchwork.0028_add_comment_date_index... OK
      Applying patchwork.0029_add_list_covering_index... OK
      Applying patchwork.0030_add_submission_covering_index... OK
      Applying patchwork.0031_add_patch_series_fields... OK
      Applying patchwork.0032_migrate_data_from_series_patch_to_patch... OK
      Applying patchwork.0033_remove_patch_series_model... OK
      Applying patchwork.0034_project_list_archive_url... OK
      Applying patchwork.0035_project_list_archive_url_format... OK
      Applying patchwork.0036_project_commit_url_format... OK
      Applying patchwork.0037_event_actor... OK
      Applying patchwork.0038_state_slug... OK
      Applying patchwork.0039_unique_series_references...Traceback (most recent call last):
      File "path/to/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
        return self.cursor.execute(sql, params)
    psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "patchwork_patch_series_alt_id_number_a3184a59_uniq"
    DETAIL:  Key (series_id, number)=(5464, 2) already exists.
    
    
    The above exception was the direct cause of the following exception:
    
    Traceback (most recent call last):
      File "manage.py", line 12, in <module>
        execute_from_command_line(sys.argv)
      File "path/to/venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
        utility.execute()
      File "path/to/venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 375, in execute
        self.fetch_command(subcommand).run_from_argv(self.argv)
      File "path/to/venv/lib/python3.7/site-packages/django/core/management/base.py", line 323, in run_from_argv
        self.execute(*args, **cmd_options)
      File "path/to/venv/lib/python3.7/site-packages/django/core/management/base.py", line 364, in execute
        output = self.handle(*args, **options)
      File "path/to/venv/lib/python3.7/site-packages/django/core/management/base.py", line 83, in wrapped
        res = handle_func(*args, **kwargs)
      File "path/to/venv/lib/python3.7/site-packages/django/core/management/commands/migrate.py", line 234, in handle
        fake_initial=fake_initial,
      File "path/to/venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 117, in migrate
        state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
      File "path/to/venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
        state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
      File "path/to/venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 245, in apply_migration
        state = migration.apply(state, schema_editor)
      File "path/to/venv/lib/python3.7/site-packages/django/db/migrations/migration.py", line 124, in apply
        operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
      File "path/to/venv/lib/python3.7/site-packages/django/db/migrations/operations/special.py", line 190, in database_forwards
        self.code(from_state.apps, schema_editor)
      File "/var/www/patchwork/patchwork/migrations/0039_unique_series_references.py", line 56, in merge_duplicate_series
        patch.save()
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/base.py", line 741, in save
        force_update=force_update, update_fields=update_fields)
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/base.py", line 779, in save_base
        force_update, using, update_fields,
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/base.py", line 851, in _save_table
        forced_update)
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/base.py", line 900, in _do_update
        return filtered._update(values) > 0
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/query.py", line 760, in _update
        return query.get_compiler(self.db).execute_sql(CURSOR)
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/sql/compiler.py", line 1462, in execute_sql
        cursor = super().execute_sql(result_type)
      File "path/to/venv/lib/python3.7/site-packages/django/db/models/sql/compiler.py", line 1133, in execute_sql
        cursor.execute(sql, params)
      File "path/to/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 99, in execute
        return super().execute(sql, params)
      File "path/to/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 67, in execute
        return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
      File "path/to/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
        return executor(sql, params, many, context)
      File "path/to/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
        return self.cursor.execute(sql, params)
      File "path/to/venv/lib/python3.7/site-packages/django/db/utils.py", line 89, in __exit__
        raise dj_exc_value.with_traceback(traceback) from exc_value
      File "path/to/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
        return self.cursor.execute(sql, params)
    django.db.utils.IntegrityError: duplicate key value violates unique constraint "patchwork_patch_series_alt_id_number_a3184a59_uniq"
    DETAIL:  Key (series_id, number)=(5464, 2) already exists
    

    Environment:

    Django==2.2.10
    django-filter==2.2.0
    djangorestframework==3.10.3
    pkg-resources==0.0.0
    psycopg2-binary==2.8.4
    pytz==2019.3
    sqlparse==0.3.1
    

    While the log provided is for Debian 10 (Python 3.7.3), the same failure occurs on Debian 9 (Python 3.5.3) as well.

    EDIT: I use database engine django.db.backends.postgresql_psycopg2.

    bug 
    opened by alialnu 12
  • Show bundle in browser

    Show bundle in browser

    Right now clicking on "download" downloads the file. Firefox 55.

    I'd really prefer just seeing it in browser as is - this way I can run "git am" and simply cut-n-paste from browser to the terminal and avoid downloading/saving/opening/deleting temporary files. Same request about "diff" and "mbox" buttons in the individual patches.

    The workaround I used before (2 firefox addons) to show files in a browsers won't work anymore in a month or two as Firefox is migrating to the new addons api. Or is there any other workaround?

    wontfix enhancement 
    opened by aik 12
  • Parsing of patches in series are racy

    Parsing of patches in series are racy

    Any idea why series name sometimes get lost? In some patchsets one of the patches has "Untitled series #N" title, e.g. patch [1] being lost from [2].

    [1] https://patchwork.ozlabs.org/patch/1021139/ [2] https://patchwork.ozlabs.org/project/ltp/list/?series=84657&state=*

    bug 
    opened by pevik 9
  • SQL migration guide in upgrade docs is not clear

    SQL migration guide in upgrade docs is not clear

    First of all, I dont have any experiance with django so sorry if I'm taking wrong assumptions.

    I'm are running an older master checked out at 20150420 with Django v1.5 which I tried to update. I've read the documentation on how to upgrade but it seems not very clear coming from and older version than 1.0. Here are the steps I followed:

    manage.py migrate

    This will run ok until it will error on 0001_initial (some table already exists). I converted this file to sql with the following cmd:

    manage.py sqlmigrate patchwork 0001_initial

    After looking at the generated SQL, it looks I'm only missing the part defined at 015-add-patch-tags.sql so i have manually imported it into my db.

    Then looking at my db, I'm also missing all other parts from the following migration scripts, so I generated the missing SQL and imported it into my db.

    This ends up in a working upgraded patchwork except runserver complained about some outstanding migration which i resolved by running:

    manage.py migrate --fake

    Now my question is, is this the correct procedure or did I miss/forget something? And will I in the future be able to just run:

    manage.py migrate

    bug enhancement 
    opened by clandmeter 9
  • git-pw sometimes fetches same patch in series for two different patch numbers

    git-pw sometimes fetches same patch in series for two different patch numbers

    When running git-pw patch apply on the first URL below it applies ok but the second URL still fetches the first patch.

    https://patchwork.yoctoproject.org/project/oe/patch/[email protected]/

    https://patchwork.yoctoproject.org/project/oe/patch/[email protected]/

    Is there a client-side fix or is there something up with Patchwork?

    opened by sc00beyd00 7
  • `Internal Server Error` when updating a patch via REST

    `Internal Server Error` when updating a patch via REST

    Hello,

    First, thank you for working on this very useful tool!

    I'm a user of Patchwork on patchwork.kernel.org with an account allowing me to modify status for one project.

    On kernel.org, they are using the version 2.2.5 (recently updated?). Since yesterday, I'm not able to update patches from the command line with git-pw:

    $ git-pw --debug patch update --delegate martineau 12447551
    2021-08-20 09:10:50,747 - git_pw.patch - DEBUG - Updating patch: id=12447551, commit_ref=None, state=None, archived=None
    2021-08-20 09:10:50,751 - git_pw.config - DEBUG - Retrieved 'server' setting from git-config
    2021-08-20 09:10:50,752 - git_pw.config - DEBUG - Retrieved 'server' setting from cache
    2021-08-20 09:10:50,756 - git_pw.config - DEBUG - Retrieved 'project' setting from git-config
    2021-08-20 09:10:50,756 - git_pw.config - DEBUG - Retrieved 'project' setting from cache
    2021-08-20 09:10:50,756 - git_pw.config - DEBUG - Retrieved 'project' setting from cache
    2021-08-20 09:10:50,756 - git_pw.config - DEBUG - Retrieved 'project' setting from cache
    2021-08-20 09:10:50,757 - git_pw.api - DEBUG - GET https://patchwork.kernel.org/api/1.1/users/
    2021-08-20 09:10:50,761 - git_pw.config - DEBUG - Retrieved 'token' setting from git-config
    2021-08-20 09:10:50,761 - git_pw.config - DEBUG - Retrieved 'token' setting from cache
    2021-08-20 09:10:50,764 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): patchwork.kernel.org:443
    2021-08-20 09:10:51,454 - urllib3.connectionpool - DEBUG - https://patchwork.kernel.org:443 "GET /api/1.1/users/?q=martineau&project=mptcp HTTP/1.1" 200 169
    2021-08-20 09:10:51,455 - git_pw.api - DEBUG - Got response
    2021-08-20 09:10:51,456 - git_pw.config - DEBUG - Retrieved 'server' setting from cache
    2021-08-20 09:10:51,456 - git_pw.config - DEBUG - Retrieved 'server' setting from cache
    2021-08-20 09:10:51,456 - git_pw.api - DEBUG - PATCH https://patchwork.kernel.org/api/1.1/patches/12447551/, data=[('delegate', 127271)]
    2021-08-20 09:10:51,456 - git_pw.config - DEBUG - Retrieved 'token' setting from cache
    2021-08-20 09:10:51,456 - git_pw.config - DEBUG - Retrieved 'token' setting from cache
    2021-08-20 09:10:51,458 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): patchwork.kernel.org:443
    2021-08-20 09:10:52,136 - urllib3.connectionpool - DEBUG - https://patchwork.kernel.org:443 "PATCH /api/1.1/patches/12447551/ HTTP/1.1" 500 27
    2021-08-20 09:10:52,138 - git_pw.api - ERROR - Server error. Please report this issue to https://github.com/getpatchwork/patchwork
    Traceback (most recent call last):
      File "/usr/local/bin/git-pw", line 8, in <module>
        sys.exit(cli())
      File "/usr/lib/python3/dist-packages/click/core.py", line 829, in __call__
        return self.main(*args, **kwargs)
      File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
        rv = self.invoke(ctx)
      File "/usr/lib/python3/dist-packages/click/core.py", line 1259, in invoke
        return _process_result(sub_ctx.command.invoke(sub_ctx))
      File "/usr/lib/python3/dist-packages/click/core.py", line 1259, in invoke
        return _process_result(sub_ctx.command.invoke(sub_ctx))
      File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
        return ctx.invoke(self.callback, **ctx.params)
      File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
        return callback(*args, **kwargs)
      File "/usr/local/lib/python3.9/dist-packages/git_pw/patch.py", line 196, in update_cmd
        patch = api.update('patches', patch_id, data)
      File "/usr/local/lib/python3.9/dist-packages/git_pw/api.py", line 372, in update
        return _patch(url, data).json()
      File "/usr/local/lib/python3.9/dist-packages/git_pw/api.py", line 176, in _patch
        _handle_error('update', exc)
      File "/usr/local/lib/python3.9/dist-packages/git_pw/api.py", line 174, in _patch
        rsp.raise_for_status()
      File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
        raise HTTPError(http_error_msg, response=self)
    requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: https://patchwork.kernel.org/api/1.1/patches/12447551/
    

    I was going to report this issue to kernel.org sysadmins but the messages above suggest me to report it here. Please note that I can curl the last URL mentioned above without issues. From what I see in git_pw/patch.py:196, it is doing an update operation, so not a GET I guess.

    Do you think it is due to Patchwork itself or the way it has been deployed and configured?

    opened by matttbe 7
  • RFC-2822 comments not handled in in-reply-to

    RFC-2822 comments not handled in in-reply-to

    RFC 2822 defines a "comment or folding white space" which is permitted to be inserted before or after the message-id in an In-Reply-To field (or in message-id or references)[1]. Neither the python email module nor patchwork seem to remove these comments, leading to lost email due to message id mismatches.

    Example: Emacs creates reply mails with fields like this:

    In-Reply-To: <[email protected]> (message from John Doe)
    

    Testing (on patchwork 2.2 at least) has shown that manually removing the (...) part before sending causes patchwork to properly match emails to the correct patches.

    [1] https://tools.ietf.org/html/rfc2822#section-3.6.4

    bug 
    opened by djdelorie 7
  • Workflow questions

    Workflow questions

    Hi,

    We are currently exploring the use of Patchwork for the GDB project, to be able to better track pending patches and reduce the number of patches that fall between the cracks. We actually had a Patchwork instance (an older version) in the past, but it hasn't been very helpful to us. Because of the amount of manual work required to change patches to the appropriate state (especially to mark them as closed), the patches would just stay open forever and Patchwork couldn't really be used anymore to track which patches needed attention.

    So I am wondering how people use Patchwork to track patches in projects that have a large volume of patches, and looking for advice on how to do so efficiently.

    For example, can Patchwork handle multiple versions of a patch or series, automatically marking previous versions as "superseded" when a new version is sent? My brief testing has found that it doesn't, the second series is treated as a completely separate series as the first one (which I expected, I don't see how Patchwork could magically know that they are related).

    I have seen that there is a git hook that allows closing patches based on git commits. That sounds nice, but I am a bit skeptical on how well that works in practice, given that the hook hashes the diff of the patch and sends that hash to the server. If the patch was modified (even a simple rebase) before it was pushed, how can the server identify the patch to close properly? I'd be curious to get some feedback from people using it "in production".

    I have tried to do some testing using the patchwork-update-commits script before asking, but I couldn't get it to work so far.

    On the design page of the doc, we have well noted this design goal:

    Don’t pollute the project’s changelogs with Patchwork poop
    
    A project’s changelogs are valuable - we don’t want to add Patchwork-specific metadata.
    

    We were a bit surprised to read that, since having a tag in the patch comment (that stays the same across versions), like Gerrit does with its Change-Id, is a very effective way to uniquely identify a patch. And it's not like it makes the change log less readable. It would surely make tracking versions of patches and automatically closing merged patches much more robust.

    Is the door completely closed from allowing Patchwork to identify patches using something such as a Change-Id? If a project is fine with having this information in their patches and can benefit from better patch tracking, they could use it, but it wouldn't force other projects to use it.

    Thanks!

    question 
    opened by simark 7
  • Displaying patch rejections

    Displaying patch rejections

    Counters can be displayed for three tags below the column header “A/R/T”. :crystal_ball: How do you think about to present the information how often patches got rejected?

    opened by elfring 7
  • Series view

    Series view

    Some patchwork instances constantly have more than 100 patches active, a series view would go a long way in giving people a quick overview. Using this view to perform actions on all patches at once would be a big win.

    enhancement 
    opened by kuba-moo 0
  • Allow non-delegates to claim interest in a series

    Allow non-delegates to claim interest in a series

    Currently maintainers have no idea if patch is in some reviewer's TODO / interest queue. Add support for non-maintianer users to mark patches as "review coming". Record time of marking so that stale marks can be removed. Automatically remove the marking if a review tag or comment arrives from a given person.

    enhancement 
    opened by kuba-moo 0
  • Pin django-debug-toolbar to latest version 3.8.1

    Pin django-debug-toolbar to latest version 3.8.1

    This PR pins django-debug-toolbar to the latest release 3.8.1.

    Changelog

    3.8.1

    ------------------
    
    * Fixed release process by re-adding twine to release dependencies. No
    functional change.
    

    3.8.0

    ------------------
    
    * Added protection against division by 0 in timer.js
    * Auto-update History panel for JavaScript ``fetch`` requests.
    * Support `HTMX boosting &lt;https://htmx.org/docs/#boosting/&gt;`__ and
    `Turbo &lt;https://turbo.hotwired.dev/&gt;`__ pages.
    * Simplify logic for ``Panel.enabled`` property by checking cookies earlier.
    * Include panel scripts in content when ``RENDER_PANELS`` is set to True.
    * Create one-time mouseup listener for each mousedown when dragging the
    handle.
    * Update package metadata to use Hatchling.
    * Fix highlighting on history panel so odd rows are highlighted when
    selected.
    * Formalize support for Python 3.11.
    

    3.7.0

    ------------------
    
    * Added Profiling panel setting ``PROFILER_THRESHOLD_RATIO`` to give users
    better control over how many function calls are included. A higher value
    will include more data, but increase render time.
    * Update Profiling panel to include try to always include user code. This
    code is more important to developers than dependency code.
    * Highlight the project function calls in the profiling panel.
    * Added Profiling panel setting ``PROFILER_CAPTURE_PROJECT_CODE`` to allow
    users to disable the inclusion of all project code. This will be useful
    to project setups that have dependencies installed under
    ``settings.BASE_DIR``.
    * The toolbar&#x27;s font stack now prefers system UI fonts. Tweaked paddings,
    margins and alignments a bit in the CSS code.
    * Only sort the session dictionary when the keys are all strings. Fixes a
    bug that causes the toolbar to crash when non-strings are used as keys.
    

    3.6.0

    ------------------
    
    * Remove decorator ``signed_data_view`` as it was causing issues with
    `django-urlconfchecks &lt;https://github.com/AliSayyah/django-urlconfchecks/&gt;`__.
    * Added pygments to the test environment and fixed a crash when using the
    template panel with Django 4.1 and pygments installed.
    * Stayed on top of pre-commit hook and GitHub actions updates.
    * Added some workarounds to avoid a Chromium warning which was worrisome to
    developers.
    * Avoided using deprecated Selenium methods to find elements.
    * Raised the minimum Django version from 3.2 to 3.2.4 so that we can take
    advantage of backported improvements to the cache connection handler.
    

    3.5.0

    ------------------
    
    * Properly implemented tracking and display of PostgreSQL transactions.
    * Removed third party panels which have been archived on GitHub.
    * Added Django 4.1b1 to the CI matrix.
    * Stopped crashing when ``request.GET`` and ``request.POST`` are neither
    dictionaries nor ``QueryDict`` instances. Using anything but ``QueryDict``
    instances isn&#x27;t a valid use of Django but, again, django-debug-toolbar
    shouldn&#x27;t crash.
    * Fixed the cache panel to work correctly in the presence of concurrency by
    avoiding the use of signals.
    * Reworked the cache panel instrumentation mechanism to monkey patch methods on
    the cache instances directly instead of replacing cache instances with
    wrapper classes.
    * Added a :meth:`debug_toolbar.panels.Panel.ready` class method that panels can
    override to perform any initialization or instrumentation that needs to be
    done unconditionally at startup time.
    * Added pyflame (for flame graphs) to the list of third-party panels.
    * Fixed the cache panel to correctly count cache misses from the get_many()
    cache method.
    * Removed some obsolete compatibility code from the stack trace recording code.
    * Added a new mechanism for capturing stack traces which includes per-request
    caching to reduce expensive file system operations.  Updated the cache and
    SQL panels to record stack traces using this new mechanism.
    * Changed the ``docs`` tox environment to allow passing positional arguments.
    This allows e.g. building a HTML version of the docs using ``tox -e docs
    html``.
    * Stayed on top of pre-commit hook updates.
    * Replaced ``OrderedDict`` by ``dict`` where possible.
    
    Deprecated features
    ~~~~~~~~~~~~~~~~~~~
    
    * The ``debug_toolbar.utils.get_stack()`` and
    ``debug_toolbar.utils.tidy_stacktrace()`` functions are deprecated in favor
    of the new ``debug_toolbar.utils.get_stack_trace()`` function.  They will
    removed in the next major version of the Debug Toolbar.
    

    3.4.0

    ------------------
    
    * Fixed issue of stacktrace having frames that have no path to the file,
    but are instead a string of the code such as
    ``&#x27;&lt;frozen importlib._bootstrap&gt;&#x27;``.
    * Renamed internal SQL tracking context var from ``recording`` to
    ``allow_sql``.
    

    3.3.0

    ------------------
    
    * Track calls to :py:meth:`django.core.caches.cache.get_or_set`.
    * Removed support for Django &lt; 3.2.
    * Updated check ``W006`` to look for
    ``django.template.loaders.app_directories.Loader``.
    * Reset settings when overridden in tests. Packages or projects using
    django-debug-toolbar can now use Django’s test settings tools, like
    ``override_settings``, to reconfigure the toolbar during tests.
    * Optimize rendering of SQL panel, saving about 30% of its run time.
    * New records in history panel will flash green.
    * Automatically update History panel on AJAX requests from client.
    

    3.2.4

    ------------------
    
    * Revert PR 1426 - Fixes issue with SQL parameters having leading and
    trailing characters stripped away.
    

    3.2.3

    ------------------
    
    * Changed cache monkey-patching for Django 3.2+ to iterate over existing
    caches and patch them individually rather than attempting to patch
    ``django.core.caches`` as a whole. The ``middleware.cache`` is still
    being patched as a whole in order to attempt to catch any cache
    usages before ``enable_instrumentation`` is called.
    * Add check ``W006`` to warn that the toolbar is incompatible with
    ``TEMPLATES`` settings configurations with ``APP_DIRS`` set to ``False``.
    * Create ``urls`` module and update documentation to no longer require
    importing the toolbar package.
    

    3.2.2

    ------------------
    
    * Ensured that the handle stays within bounds when resizing the window.
    * Disabled ``HistoryPanel`` when ``RENDER_PANELS`` is ``True``
    or if ``RENDER_PANELS`` is ``None`` and the WSGI container is
    running with multiple processes.
    * Fixed ``RENDER_PANELS`` functionality so that when ``True`` panels are
    rendered during the request and not loaded asynchronously.
    * HistoryPanel now shows status codes of responses.
    * Support ``request.urlconf`` override when checking for toolbar requests.
    

    3.2.1

    ------------------
    
    * Fixed SQL Injection vulnerability, CVE-2021-30459. The toolbar now
    calculates a signature on all fields for the SQL select, explain,
    and analyze forms.
    * Changed ``djdt.cookie.set()`` to set ``sameSite=Lax`` by default if
    callers do not provide a value.
    * Added ``PRETTIFY_SQL`` configuration option to support controlling
    SQL token grouping. By default it&#x27;s set to True. When set to False,
    a performance improvement can be seen by the SQL panel.
    * Added a JavaScript event when a panel loads of the format
    ``djdt.panel.[PanelId]`` where PanelId is the ``panel_id`` property
    of the panel&#x27;s Python class. Listening for this event corrects the bug
    in the Timer Panel in which it didn&#x27;t insert the browser timings
    after switching requests in the History Panel.
    * Fixed issue with the toolbar expecting URL paths to start with
    ``/__debug__/`` while the documentation indicates it&#x27;s not required.
    

    3.2

    ----------------
    
    * Moved CI to GitHub Actions: https://github.com/jazzband/django-debug-toolbar/actions
    * Stopped crashing when ``request.GET`` and ``request.POST`` are
    dictionaries instead of ``QueryDict`` instances. This isn&#x27;t a valid
    use of Django but django-debug-toolbar shouldn&#x27;t crash anyway.
    * Fixed a crash in the history panel when sending a  JSON POST request
    with invalid JSON.
    * Added missing signals to the signals panel by default.
    * Documented how to avoid CORS errors now that we&#x27;re using JavaScript
    modules.
    * Verified support for Python 3.9.
    * Added a ``css`` and a ``js`` template block to
    ``debug_toolbar/base.html`` to allow overriding CSS and JS.
    

    3.2a1

    ------------------
    
    * Fixed a regression where the JavaScript code crashed with an invalid
    CSS selector when searching for an element to replace.
    * Replaced remaining images with CSS.
    * Continued refactoring the HTML and CSS code for simplicity, continued
    improving the use of semantic HTML.
    * Stopped caring about prehistoric browsers for good. Started splitting
    up the JavaScript code to take advantage of JavaScript modules.
    * Continued removing unused CSS.
    * Started running Selenium tests on Travis CI.
    * Added a system check which prevents using django-debug-toolbar without
    any enabled panels.
    * Added :meth:`Panel.run_checks() &lt;debug_toolbar.panels.Panel.run_checks&gt;` for
    panels to verify the configuration before the application starts.
    * Validate the static file paths specified in ``STATICFILES_DIRS``
    exist via :class:`~debug_toolbar.panels.staticfiles.StaticFilesPanel`
    * Introduced `prettier &lt;https://prettier.io/&gt;`__ to format the frontend
    code.
    * Started accessing history views using GET requests since they do not
    change state on the server.
    * Fixed a bug where unsuccessful requests (e.g. network errors) were
    silently ignored.
    * Started spellchecking the documentation.
    * Removed calls to the deprecated ``request.is_ajax()`` method. These calls
    were unnecessary now that most endpoints return JSON anyway.
    * Removed support for Python 3.5.
    

    3.1

    ----------------
    
    * Fixed a crash in the history panel when sending an empty JSON POST
    request.
    * Made ``make example`` also set up the database and a superuser
    account.
    * Added a Makefile target for regenerating the django-debug-toolbar
    screenshot.
    * Added automatic escaping of panel titles resp. disallowed HTML tags.
    * Removed some CSS
    * Restructured the SQL stats template.
    * Changed command line examples to prefer ``python -m pip`` to ``pip``.
    

    3.0

    ----------------
    
    * Added an ``.editorconfig`` file specifying indentation rules etc.
    * Updated the Italian translation.
    * Added support for Django 3.1a1. ``fetch()`` and ``jQuery.ajax`` requests are
    now detected by the absence of a ``Accept: text/html`` header instead of the
    jQuery-specific ``X-Requested-With`` header on Django 3.1 or better.
    * Pruned unused CSS and removed hacks for ancient browsers.
    * Added the new :attr:`Panel.scripts &lt;debug_toolbar.panels.Panel.scripts&gt;`
    property. This property should return a list of JavaScript resources to be
    loaded in the browser when displaying the panel. Right now, this is used by a
    single panel, the Timer panel. Third party panels can use this property to
    add scripts rather then embedding them in the content HTML.
    * Switched from JSHint to ESLint. Added an ESLint job to the Travis CI matrix.
    * Debug toolbar state which is only needed in the JavaScript code now uses
    ``localStorage``.
    * Updated the code to avoid a few deprecation warnings and resource warnings.
    * Started loading JavaScript as ES6 modules.
    * Added support for :meth:`cache.touch() &lt;django.core.caches.cache.touch&gt;` when
    using django-debug-toolbar.
    * Eliminated more inline CSS.
    * Updated ``tox.ini`` and ``Makefile`` to use isort&gt;=5.
    * Increased RESULTS_CACHE_SIZE to 25 to better support AJAX requests.
    * Fixed the close button CSS by explicitly specifying the
    ``box-sizing`` property.
    * Simplified the ``isort`` configuration by taking advantage of isort&#x27;s
    ``black`` profile.
    * Added :class:`~debug_toolbar.panels.history.HistoryPanel` including support
    for AJAX requests.
    
    **Backwards incompatible changes**
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    * Loading panel content no longer executes the scripts elements embedded in the
    HTML. Third party panels that require JavaScript resources should now use the
    :attr:`Panel.scripts &lt;debug_toolbar.panels.Panel.scripts&gt;` property.
    * Removed support for end of life Django 1.11. The minimum supported Django is
    now 2.2.
    * The Debug Toolbar now loads a `JavaScript module`_. Typical local development
    using Django ``runserver`` is not impacted. However, if your application
    server and static files server are at different origins, you may see CORS
    errors in your browser&#x27;s development console. See the &quot;Cross-Origin Request
    Blocked&quot; section of the :doc:`installation docs &lt;installation&gt;` for details
    on how to resolve this issue.
    
    .. _JavaScript module: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
    

    2.2

    ----------------
    
    * Removed support for end of life Django 2.0 and 2.1.
    * Added support for Python 3.8.
    * Add locals() option for SQL panel.
    * Added support for Django 3.0.
    

    2.1

    ----------------
    
    * Changed the Travis CI matrix to run style checks first.
    * Exposed the ``djdt.init`` function too.
    * Small improvements to the code to take advantage of newer Django APIs
    and avoid warnings because of deprecated code.
    * Verified compatibility with the upcoming Django 3.0 (at the time of
    writing).
    

    2.0

    ----------------
    
    * Updated :class:`~debug_toolbar.panels.staticfiles.StaticFilesPanel` to be
    compatible with Django 3.0.
    * The :class:`~debug_toolbar.panels.profiling.ProfilingPanel` is now enabled
    but inactive by default.
    * Fixed toggling of table rows in the profiling panel UI.
    * The :class:`~debug_toolbar.panels.profiling.ProfilingPanel` no longer skips
    remaining panels or middlewares.
    * Improved the installation documentation.
    * Fixed a possible crash in the template panel.
    * Added support for psycopg2 ``Composed`` objects.
    * Changed the Jinja2 tests to use Django&#x27;s own Jinja2 template backend.
    * Added instrumentation to queries using server side cursors.
    * Too many small improvements and cleanups to list them all.
    
    **Backwards incompatible changes**
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    * Removed support for Python 2.
    * Removed support for Django&#x27;s deprecated ``MIDDLEWARE_CLASSES`` setting.
    * Restructured :class:`debug_toolbar.panels.Panel` to execute more like the
    new-style Django MIDDLEWARE. The ``Panel.__init__()`` method is now passed
    ``get_response`` as the first positional argument. The
    :meth:`debug_toolbar.panels.Panel.process_request` method must now always
    return a response. Usually this is the response returned by
    ``get_response()`` but the panel may also return a different response as is
    the case in the :class:`~debug_toolbar.panels.redirects.RedirectsPanel`.
    Third party panels must adjust to this new architecture.
    ``Panel.process_response()`` and ``Panel.process_view()`` have been removed
    as a result of this change.
    
    The deprecated API, ``debug_toolbar.panels.DebugPanel``, has been removed.
    Third party panels should use :class:`debug_toolbar.panels.Panel` instead.
    
    The following deprecated settings have been removed:
    
    * ``HIDDEN_STACKTRACE_MODULES``
    * ``HIDE_DJANGO_SQL``
    * ``INTERCEPT_REDIRECTS``
    * ``RESULTS_STORE_SIZE``
    * ``ROOT_TAG_ATTRS``
    * ``TAG``
    

    1.11

    -----------------
    
    * Use ``defer`` on all ``&lt;script&gt;`` tags to avoid blocking HTML parsing,
    removed inline JavaScript.
    * Stop inlining images in CSS to avoid Content Security Policy errors
    altogether.
    * Reformatted the code using `black &lt;https://github.com/ambv/black&gt;`__.
    * Added the Django mail panel to the list of third-party panels.
    * Convert system check errors to warnings to accommodate exotic
    configurations.
    * Fixed a crash when explaining raw querysets.
    * Fixed an obscure Unicode error with binary data fields.
    * Added MariaDB and Python 3.7 builds to the CI.
    

    1.10.1

    -------------------
    
    * Fixed a problem where the duplicate query detection breaks for
    unhashable query parameters.
    * Added support for structured types when recording SQL.
    * Made Travis CI also run one test no PostgreSQL.
    * Added fallbacks for inline images in CSS.
    * Improved cross-browser compatibility around ``URLSearchParams`` usage.
    * Fixed a few typos and redundancies in the documentation, removed
    mentions of django-debug-toolbar&#x27;s jQuery which aren&#x27;t accurate
    anymore.
    

    1.10

    -----------------
    
    * Removed support for Django &lt; 1.11.
    * Added support and testing for Django 2.1 and Python 3.7. No actual code
    changes were required.
    * Removed the jQuery dependency. This means that django-debug-toolbar
    now requires modern browsers with support for ``fetch``, ``classList``
    etc. The ``JQUERY_URL`` setting is also removed because it isn&#x27;t
    necessary anymore. If you depend on jQuery, integrate it yourself.
    * Added support for the server timing header.
    * Added a differentiation between similar and duplicate queries. Similar
    queries are what duplicate queries used to be (same SQL, different
    parameters).
    * Stopped hiding frames from Django&#x27;s contrib apps in stacktraces by
    default.
    * Lots of small cleanups and bug fixes.
    

    1.9.1

    ------------------
    
    * Fix erroneous ``ContentNotRenderedError`` raised by the redirects panel.
    

    1.9

    ----------------
    
    This version is compatible with Django 2.0 and requires Django 1.8 or
    later.
    
    Bug fixes
    ~~~~~~~~~
    
    * The profiling panel now escapes reported data resulting in valid HTML.
    * Many minor cleanups and bug fixes.
    

    1.8

    ----------------
    
    This version is compatible with Django 1.11 and requires Django 1.8 or
    later.
    
    **Backwards incompatible changes**
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    * ``debug_toolbar.middleware.show_toolbar`` (the default value of setting
    ``SHOW_TOOLBAR_CALLBACK``) no longer returns ``False`` for AJAX requests.
    This is to allow reusing the ``SHOW_TOOLBAR_CALLBACK`` function to verify
    access to panel views requested via AJAX. Projects defining a custom
    ``SHOW_TOOLBAR_CALLBACK`` should remove checks for AJAX requests in order to
    continue to allow access to these panels.
    
    Features
    ~~~~~~~~
    
    * New decorator ``debug_toolbar.decorators.require_show_toolbar`` prevents
    unauthorized access to decorated views by checking ``SHOW_TOOLBAR_CALLBACK``
    every request. Unauthorized access results in a 404.
    * The ``SKIP_TEMPLATE_PREFIXES`` setting allows skipping templates in
    the templates panel. Template-based form widgets&#x27; templates are
    skipped by default to avoid panel sizes going into hundreds of
    megabytes of HTML.
    
    Bug fixes
    ~~~~~~~~~
    
    * All views are now decorated with
    ``debug_toolbar.decorators.require_show_toolbar`` preventing unauthorized
    access.
    * The templates panel now reuses contexts&#x27; pretty printed version which
    makes the debug toolbar usable again with Django 1.11&#x27;s template-based
    forms rendering.
    * Long SQL statements are now forcibly wrapped to fit on the screen.
    

    1.7

    ----------------
    
    Bug fixes
    ~~~~~~~~~
    
    * Recursive template extension is now understood.
    * Deprecation warnings were fixed.
    * The SQL panel uses HMAC instead of simple hashes to verify that SQL
    statements have not been changed. Also, the handling of bytes and text
    for hashing has been hardened. Also, a bug with Python&#x27;s division
    handling has been fixed for improved Python 3 support.
    * An error with django-jinja has been fixed.
    * A few CSS classes have been prefixed with ``djdt-`` to avoid
    conflicting class names.
    

    1.6

    ----------------
    
    The debug toolbar was adopted by Jazzband.
    
    Removed features
    ~~~~~~~~~~~~~~~~
    
    * Support for automatic setup has been removed as it was frequently
    problematic. Installation now requires explicit setup. The
    ``DEBUG_TOOLBAR_PATCH_SETTINGS`` setting has also been removed as it is now
    unused. See the :doc:`installation documentation &lt;installation&gt;` for details.
    
    Bug fixes
    ~~~~~~~~~
    
    * The ``DebugToolbarMiddleware`` now also supports Django 1.10&#x27;s ``MIDDLEWARE``
    setting.
    

    1.5

    ----------------
    
    This version is compatible with Django 1.10 and requires Django 1.8 or later.
    
    Support for Python 3.2 is dropped.
    
    Bug fixes
    ~~~~~~~~~
    
    * Restore compatibility with sqlparse ≥ 0.2.0.
    * Add compatibility with Bootstrap 4, Pure CSS, MDL, etc.
    * Improve compatibility with RequireJS / AMD.
    * Improve the UI slightly.
    * Fix invalid (X)HTML.
    

    1.4

    ----------------
    
    This version is compatible with Django 1.9 and requires Django 1.7 or later.
    
    New features
    ~~~~~~~~~~~~
    
    * New panel method :meth:`debug_toolbar.panels.Panel.generate_stats` allows
    panels to only record stats when the toolbar is going to be inserted into
    the response.
    
    Bug fixes
    ~~~~~~~~~
    
    * Response time for requests of projects with numerous media files has
    been improved.
    

    1.3

    ----------------
    
    This is the first version compatible with Django 1.8.
    
    New features
    ~~~~~~~~~~~~
    
    * A new panel is available: Template Profiler.
    * The ``SHOW_TOOLBAR_CALLBACK`` accepts a callable.
    * The toolbar now provides a :ref:`javascript-api`.
    
    Bug fixes
    ~~~~~~~~~
    
    * The toolbar handle cannot leave the visible area anymore when the toolbar is
    collapsed.
    * The root level logger is preserved.
    * The ``RESULTS_CACHE_SIZE`` setting is taken into account.
    * CSS classes are prefixed with ``djdt-`` to prevent name conflicts.
    * The private copy of jQuery no longer registers as an AMD module on sites
    that load RequireJS.
    

    1.2

    ----------------
    
    New features
    ~~~~~~~~~~~~
    
    * The ``JQUERY_URL`` setting defines where the toolbar loads jQuery from.
    
    Bug fixes
    ~~~~~~~~~
    
    * The toolbar now always loads a private copy of jQuery in order to avoid
    using an incompatible version. It no longer attempts to integrate with AMD.
    
    This private copy is available in ``djdt.jQuery``. Third-party panels are
    encouraged to use it because it should be as stable as the toolbar itself.
    

    1.1

    ----------------
    
    This is the first version compatible with Django 1.7.
    
    New features
    ~~~~~~~~~~~~
    
    * The SQL panel colors queries depending on the stack level.
    * The Profiler panel allows configuring the maximum depth.
    
    Bug fixes
    ~~~~~~~~~
    
    * Support languages where lowercase and uppercase strings may have different
    lengths.
    * Allow using cursor as context managers.
    * Make the SQL explain more helpful on SQLite.
    * Various JavaScript improvements.
    
    Deprecated features
    ~~~~~~~~~~~~~~~~~~~
    
    * The ``INTERCEPT_REDIRECTS`` setting is superseded by the more generic
    ``DISABLE_PANELS``.
    

    1.0

    ----------------
    
    This is the first stable version of the Debug Toolbar!
    
    It includes many new features and performance improvements as well a few
    backwards-incompatible changes to make the toolbar easier to deploy, use,
    extend and maintain in the future.
    
    You&#x27;re strongly encouraged to review the installation and configuration docs
    and redo the setup in your projects.
    
    Third-party panels will need to be updated to work with this version.
    
    Links
    • PyPI: https://pypi.org/project/django-debug-toolbar
    • Changelog: https://pyup.io/changelogs/django-debug-toolbar/
    opened by pyup-bot 0
  • Unicode patch email rejected

    Unicode patch email rejected

    This patch on libc-alpha did not appear in patchwork as it crashed during parsing:

    https://sourceware.org/pipermail/libc-alpha/2022-October/142506.html

    Here's the backtrace at the point of the crash:

    Error when parsing incoming email: OperationalError(1366, "Incorrect string value: '\\xF0\\x91\\x82\\x80 0...' for column `patchwork`.`patchwork_patch`.`content` at row 1")
    Traceback (most recent call last):
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/utils.py", line 84, in _execute
        return self.cursor.execute(sql, params)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/mysql/base.py", line 73, in execute
        return self.cursor.execute(query, args)
      File "/path/to/patchwork/lib/python3/lib64/python3.6/site-packages/MySQLdb/cursors.py", line 206, in execute
        res = self._query(query)
      File "/path/to/patchwork/lib/python3/lib64/python3.6/site-packages/MySQLdb/cursors.py", line 319, in _query
        db.query(q)
      File "/path/to/patchwork/lib/python3/lib64/python3.6/site-packages/MySQLdb/connections.py", line 254, in query
        _mysql.connection.query(self, query)
    MySQLdb._exceptions.OperationalError: (1366, "Incorrect string value: '\\xF0\\x91\\x82\\x80 0...' for column `patchwork`.`patchwork_patch`.`content` at row 1")
    
    The above exception was the direct cause of the following exception:
    
    Traceback (most recent call last):
      File "/path/to/patchwork/patchwork.sourceware.org/patchwork/management/commands/parsemail.py", line 60, in handle
        result = parse_mail(mail, options['list_id'])
      File "/path/to/patchwork/patchwork.sourceware.org/patchwork/parser.py", line 1191, in parse_mail
        state=find_state(mail),
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/manager.py", line 85, in manager_method
        return getattr(self.get_queryset(), name)(*args, **kwargs)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/query.py", line 447, in create
        obj.save(force_insert=True, using=self.db)
      File "/path/to/patchwork/patchwork.sourceware.org/patchwork/models.py", line 554, in save
        super(Patch, self).save(**kwargs)
      File "/path/to/patchwork/patchwork.sourceware.org/patchwork/models.py", line 385, in save
        super(EmailMixin, self).save(*args, **kwargs)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/base.py", line 754, in save
        force_update=force_update, update_fields=update_fields)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/base.py", line 792, in save_base
        force_update, using, update_fields,
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/base.py", line 895, in _save_table
        results = self._do_insert(cls._base_manager, using, fields, returning_fields, raw)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/base.py", line 935, in _do_insert
        using=using, raw=raw,
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/manager.py", line 85, in manager_method
        return getattr(self.get_queryset(), name)(*args, **kwargs)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/query.py", line 1254, in _insert
        return query.get_compiler(using=using).execute_sql(returning_fields)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1397, in execute_sql
        cursor.execute(sql, params)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/utils.py", line 66, in execute
        return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
        return executor(sql, params, many, context)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/utils.py", line 84, in _execute
        return self.cursor.execute(sql, params)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/utils.py", line 90, in __exit__
        raise dj_exc_value.with_traceback(traceback) from exc_value
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/utils.py", line 84, in _execute
        return self.cursor.execute(sql, params)
      File "/path/to/patchwork/lib/python3/lib/python3.6/site-packages/django/db/backends/mysql/base.py", line 73, in execute
        return self.cursor.execute(query, args)
      File "/path/to/patchwork/lib/python3/lib64/python3.6/site-packages/MySQLdb/cursors.py", line 206, in execute
        res = self._query(query)
      File "/path/to/patchwork/lib/python3/lib64/python3.6/site-packages/MySQLdb/cursors.py", line 319, in _query
        db.query(q)
      File "/path/to/patchwork/lib/python3/lib64/python3.6/site-packages/MySQLdb/connections.py", line 254, in query
        _mysql.connection.query(self, query)
    django.db.utils.OperationalError: (1366, "Incorrect string value: '\\xF0\\x91\\x82\\x80 0...' for column `patchwork`.`patchwork_patch`.`content` at row 1")
    

    The backtrace was attained using the following change to the sourceware instance, maybe something like this could be useful for general purpose logging too:

     
     PYTHONPATH="${PATCHWORK_BASE}:${PATCHWORK_BASE}/lib/python:$PYTHONPATH" \
         DJANGO_SETTINGS_MODULE="$DJANGO_SETTINGS_MODULE" \
    -    "$PW_PYTHON" "$PATCHWORK_BASE/manage.py" parsemail "$@"
    +    "$PW_PYTHON" "$PATCHWORK_BASE/manage.py" parsemail \
    +    "$@" >> $PATCHWORK_BASE/patchwork-mailstat.log 2>&1
     
     # NOTE(stephenfin): We must return 0 here. When parsemail is used as a
     # delivery command from a mail server like postfix (as it is intended
    
    opened by siddhesh 6
Releases(v3.1.1)
  • v3.1.1(Sep 30, 2022)

  • v3.0.6(Sep 30, 2022)

  • v3.1.0(Jul 15, 2022)

    The v3.1.0 release is one of the smaller releases. For full information on the options available, you should look at the full release notes in detail. The below are the highlights:

    • Added the ability to mark comments as addressed/unaddressed, allowing maintainers to track work items.
    • Added two new event types to the /events API: cover-comment-created and patch-comment-created.
    • Added support for recent versions of Python (3.10) and Django (3.2, 4.0), while dropping support for older Python (3.6) and Django (2.2, 3.0, 3.1) versions.

    For further information on these features and the other changes in this release, review the full release notes. You can also refer to the documentation for this release.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.5(May 11, 2022)

  • v3.0.4(Oct 27, 2021)

  • v2.2.6(Oct 27, 2021)

  • v3.0.3(Jul 26, 2021)

  • v2.2.5(Jul 26, 2021)

  • v3.0.2(Feb 24, 2021)

  • v2.2.4(Feb 24, 2021)

  • v3.0.1(Feb 24, 2021)

  • v3.0.0(Feb 20, 2021)

    The v3.0.0 release mostly focuses on important structural fixes and removal of Python 2.7, setting us up nicely for future features. For full information on the options available, you should look at the full release notes in detail. The below are the highlights:

    • Removal of Python 2.7 support.
    • Removal of the Submission module in favour of distinct Patch and Cover models, resolving problems initially introduced in v2.0.0.

    For further information on these features and the other changes in this release, review the full release notes. You can also refer to the documentation for this release.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.3(Dec 13, 2020)

  • v2.2.2(May 25, 2020)

  • v2.2.1(Apr 14, 2020)

  • v2.1.6(Apr 14, 2020)

  • v2.2.0(Apr 5, 2020)

    The v2.2.0 release includes many new features and bug fixes. For full information on the options available, you should look at the full release notes in detail. The below are the highlights:

    • User-driven events now have an actor associated with them
    • Patches URLs are now formatted using message IDs by default
    • It's now possible to track relationships of between multiple versions of the same patches
    • pwclient is no longer packaged with Patchwork. It is instead available from PyPI.

    For further information on these features and the other changes in this release, review the full release notes.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.0-rc2(Mar 16, 2020)

  • v2.2.0-rc1(Feb 27, 2020)

  • v2.1.5(Sep 24, 2019)

  • v2.1.4(Jul 5, 2019)

  • v2.0.4(Jul 5, 2019)

    This release fixes a number of bugs found in the v2.0 release, in particular CVE-2019-13122. Unless there is a good reason you cannot upgrade, we recommend using v2.1.4 instead.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.3(Jun 5, 2019)

  • v2.1.2(May 3, 2019)

    This release fixes a number of bugs found in the v2.1 release. It also upgrades supported dependencies to include django-rest-framework 3.9 and django-filters 1.1.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.1(Oct 14, 2018)

  • v2.1.0(Jun 19, 2018)

    This release is a minor release and, as such, focuses on improvements to existing features over sweeping changes. However, that doesn't mean there's nothing to be excited about. Notable highlights of v2.1.0 include:

    • Significant performance enhancements
    • Usability improvements courtesy of REST API v1.1
    • Support for newer versions of Python and Django

    ...and many others. You can see the full list of changes in the release notes. You can also refer to the documentation for this release.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.3(Jun 14, 2018)

  • v2.1.0-rc2(Jun 14, 2018)

  • v2.0.2(May 17, 2018)

  • v2.1.0-rc1(May 17, 2018)

Trac is an enhanced wiki and issue tracking system for software development projects (mirror)

About Trac Trac is a minimalistic web-based software project management and bug/issue tracking system. It provides an interface to the Git and Subvers

Edgewall Software 442 Dec 10, 2022
The new home of rabbitvcs

RabbitVCS RabbitVCS is a set of graphical tools written to provide simple and straightforward access to the version control systems you use. We curren

RabbitVCS 349 Dec 05, 2022
Mirror of Apache Allura

Apache Allura Allura is an open source implementation of a software "forge", a web site that manages source code repositories, bug reports, discussion

The Apache Software Foundation 106 Dec 21, 2022
Patchwork is a web-based patch tracking system designed to facilitate the contribution and management of contributions to an open-source project.

Patchwork Patchwork is a patch tracking system for community-based projects. It is intended to make the patch management process easier for both the p

Patchwork 220 Nov 29, 2022
docker run klaus / pip install klaus — the first Git web viewer that Just Works™.

klaus: a simple, easy-to-set-up Git web viewer that Just Works™. (If it doesn't Just Work for you, please file a bug.) Super easy to set up -- no conf

Jonas Haag 638 Dec 24, 2022
ViewVC is a browser interface for CVS and Subversion version control repositories.

ViewVC - Version Control Browser Interface ViewVC is a browser interface for CVS and Subversion version control repositories. It generates templatized

ViewVC 270 Dec 30, 2022
🦉Data Version Control | Git for Data & Models

Website • Docs • Blog • Twitter • Chat (Community & Support) • Tutorial • Mailing List Data Version Control or DVC is an open-source tool for data sci

Iterative 10.9k Jan 09, 2023
A simple version control system built on top of Git

Gitless Gitless is a version control system built on top of Git, that is easy to learn and use: Simple commit workflow Track or untrack files to contr

Gitless 1.7k Dec 22, 2022
git-cola: The highly caffeinated Git GUI

git-cola: The highly caffeinated Git GUI git-cola is a powerful Git GUI with a slick and intuitive user interface. Copyright (C) 2007-2020, David Agu

git-cola 2k Dec 30, 2022