Re: [git pull] Please pull powerpc.git merge branch

? 67181f5c (Jeremy Kerr 2013-06-10 11:37:25 +0800 193) utc_timestamp = (patch.date - 67181f5c (Jeremy Kerr 2013-06-10 11:37:25 +0800 194) datetime.datetime.utcfromtimestamp(0)).total_seconds() Best, -- Konstantin Ryabitsev Senior Systems Administrator Linux Foundation

[PATCH] Add a config option to FORCE_HTTPS_LINKS

In situations where SSL is terminated at the load-balancer, we cannot rely on guessing the scheme based on whether patchwork itself was accessed via http or https, since the last-leg is always going to be done over http. Unfortunately, wrongly using http:// URLs results in unusable .pwclientrc

Patchwork for (legal) public patch archive

with no project admins (basically) -- is there any other tools you may be aware of that are able to receive mailing list traffic and create a static archive of any patches seen? Best regards, - -- Konstantin Ryabitsev Linux Foundation Collab Projects Montréal, Québec -BEGIN PGP SIGNATURE- Version

Re: Is it possible to change Patchwork username?

count is also acceptable since I > don't have any valuable > data within my account yet. Please email helpd...@kernel.org. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation ___ Patchwork mailing list Pa

RFC: Access patch by message-ID

ure. :) Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork

Re: RFC: Access patch by message-ID

On Tue, May 29, 2018 at 12:37:11PM +1000, Daniel Axtens wrote: Seems like it would be easy to implement a way to access a patch by Message-ID, but there is no such option currently. I would very much like to have something like that, which would allow us to link from a public-inbox archive

Postmortem upgrading patchwork.kernel.org 1.0->2.1

Hello, patchwork list! About a week ago I performed the upgrade of patchwork.kernel.org from version 1.0 to version 2.1. This is my war story, since it didn't go nearly as smooth as I was hoping. First, general notes to describe the infra: - patchwork.kernel.org consists of 74 projects and,

RFE: permalink to submissions using list-id/message-id (GH issue 106)

Hi, all: I'm largely duplicating what I wrote in the GitHub issue 106 (https://github.com/getpatchwork/patchwork/issues/106) just to reiterate a personal plea. :) One of the side-effects of moving the LKML project to a dedicated instance was the fact that I discovered just how many people

Re: [RFC PATCH] 3x improvement in patch listing

On Thu, Aug 09, 2018 at 11:55:16AM +1000, Stewart Smith wrote: Out of interest, does the kernel.org instance back onto PostgreSQL or MySQL? We have one of each. The original instance patchwork.kernel.org is on MySQL (well, MariaDB), because that's the database cluster we have in our PDX DC.

Re: [RFC PATCH] 3x improvement in patch listing

On Wed, Aug 08, 2018 at 05:40:06PM +1000, Stewart Smith wrote: There's two main bits that are really expensive when composing the list of patches for a project: the query getting the list, and the query finding the series for each patch. Stewart: Thanks for working on this! Do you think this

Re: Database consistency issues

On Thu, Aug 09, 2018 at 01:16:25AM +1000, Daniel Axtens wrote: SELECT id, submission_id FROM patchwork_comment WHERE submission_id=9896319; +--+---+ | id | submission_id | +--+---+ | 20810589 | 9896319 | +--+---+ 1 row in

Re: Database consistency issues

On Thu, Aug 09, 2018 at 02:01:11AM +1000, Daniel Axtens wrote: In the case of Patchwork 1.1.3, I am more confused - the Comment model has a foreign key to Patch here. So if you try to delete Patch you should have got a referential integrity error like I did with e.g. Events. (Patchwork pre 2.0

Database consistency issues

row in set (0.00 sec) MariaDB [KORG_PATCHWORK]> SELECT * FROM patchwork_submission WHERE id=9896319; Empty set (0.00 sec) There don't appear to be any foreign key constraints on the patchwork_comment table -- would that be the side-effect of migration? Regards, -- Konstantin Ryabitsev Di

RFC: allow rest api to filter patches by hash

Hi, all: I was looking into integrating git with some of the projects so that applied patches can be auto-accepted and archived and I found out that while the XMLRPC API knows how to look up a patch by its hash, the REST API is not able to filter patches by hash. The main reason I wanted to stick

RFE: Ability to retrieve only non-superseded series

Hello: It would be handy to have an ability on the REST API side of things to retrieve series containing patches matching only certain states, such that if all patches in series v1 are marked as "superseded", then it's filtered out of the returned results when querying /series/. Unless I'm

Re: [PATCH v3] Move to msgid based URLs

. Partially-closes: #106 Reported-by: Konstantin Ryabitsev Reported-by: Linus Torvalds Reported-by: Stephen Finucane Signed-off-by: Daniel Axtens --- v1->v2: Move to msgid by default Add release note Add tests Rebase: rebased on top of master. Tested bundles. I'll apply it in the n

Re: Debugging dropped mails

On Tue, Apr 09, 2019 at 08:20:19PM +0200, Petr Vorel wrote: > any idea how can I debug dropped mails in patchwork instances? > Few weeks ago I started to be unable to get patches to patchwork.ozlabs.org > and > patchwork.kernel.org. Sometimes only gmail.com address is having troubles, > sometimes

Re: RFE: use patchwork to submit a patch

On Fri, Nov 08, 2019 at 03:12:51PM +0100, Dmitry Vyukov wrote: > Just to clarify: syzbot does not do this on purpose. It generates and > hands off unwrapped lines. The "format=flowed; delsp=yes" part was > done by somebody else. Looks like vger received it already mangled:

Re: RFE: use patchwork to submit a patch

On Fri, Nov 08, 2019 at 03:25:00PM +0100, Dmitry Vyukov wrote: > > Would you like a mail sending account so you can use mail.kernel.org > > as > > your outgoing smtp? We promise we won't do anything that nasty. :) > > > > -K > > You know that we also serve Fuchsia, Akaros, FreeBSD, NetBSD,

[PATCH] Improve pull request URL matching regex

) The proposed change deals with these edge-cases. Signed-off-by: Konstantin Ryabitsev --- patchwork/parser.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patchwork/parser.py b/patchwork/parser.py index c794f09..d25c0df 100644 --- a/patchwork/parser.py +++ b/patchwork/parser.py

Re: DB-murdering API query (index suggestions needed)

On Sat, Nov 16, 2019 at 12:48:33AM +1100, Daniel Axtens wrote: > > GET > > /api/1.1/patches/?project=62=2019-11-01T00:00:00_page=100=6150 > > > > > > The query behind this takes about 1 minute to run on a 20-core HT Xeon > > system and requires creating a huge temporary file (there are 18375

DB-murdering API query (index suggestions needed)

Hi, all: Today, the DB behind patchwork.kernel.org was in a semi-permanent state of suffering due to someone trying to suck down all patches in the linux-arm-kernel project. This is what the API request looked like: GET /api/1.1/patches/?project=62=2019-11-01T00:00:00_page=100=6150 The

[PATCH v2] Improve pull request URL matching regex

newlines. Signed-off-by: Konstantin Ryabitsev --- patchwork/parser.py | 4 +- .../0023-git-pull-request-newline-in-url.mbox | 48 +++ patchwork/tests/test_parser.py| 9 3 files changed, 59 insertions(+), 2 deletions(-) create mode

Re: RFE: use patchwork to submit a patch

On Tue, Oct 15, 2019 at 07:32:41PM +0300, Laurent Pinchart wrote: Well, this is largely what GitGitGadget does (https://gitgitgadget.github.io), and we could go that route, sure. I'm reluctant only because, quoth: GitGitGadget itself is a GitHub App that is backed by an Azure Function

Re: RFE: use patchwork to submit a patch

On Sat, Oct 12, 2019 at 09:19:11AM +0200, Greg KH wrote: This is basically why SMTP sucks in my view -- and it's worthless trying to pick fights with IT departments, because they are told to do so by lawyers. So, I want to take SMTP out of the equation: 1. provide a way for someone to submit a

Re: RFE: use patchwork to submit a patch

On Tue, Oct 15, 2019 at 09:35:27AM -0400, Theodore Y. Ts'o wrote: On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote: Now, if we had a way to send and receive upstream patches via a web site, that would actually make things easier. Alas, for those corporations who choose to enable

Re: RFE: use patchwork to submit a patch

On Mon, Oct 14, 2019 at 11:28:59AM -0300, Mauro Carvalho Chehab wrote: Yeah, our current security model is based at the maintainer for him to do his duties, properly reviewing the patch. Yet, at the example that Daniel gave: Instead of: if ((permissions == allowed) && other_stuff) {

Re: [PATCH] api: support filtering patches by hash

m/linux/kernel/git/mricon/korg-helpers.git/tree/git-patchwork-bot.py?id=104e7374e1be8458e6d2e82478625a7bf8c822ff > > Cc: Konstantin Ryabitsev > Signed-off-by: Daniel Axtens Acked-by: Konstantin Ryabitsev -K ___ Patchwork mailin

Re: Deduplication of patchwork mail content?

On Wed, Oct 09, 2019 at 05:35:03PM +1100, Daniel Axtens wrote: > Hi sfr, jk, Konstantin and any other admins lurking, > > I'm in the process of reworking the patchwork db schema to avoid one of > our very big and very annoying (and slow) JOINs. > > While I'm at it, it occurred to me that for

Re: [PATCH 3/3] [PW3] Remove XML-RPC API

On Fri, Oct 18, 2019 at 01:41:49PM +1100, Daniel Axtens wrote: It's been deprecated since 2.0 with the new REST API. That API is now pretty solid, and git-pw is good. Drop the old API. I believe the only thing I was not able to do with the REST API is look up patches by patch hash. Is this

RFE: use patchwork to submit a patch

Hi, all: I would like to propose a new (large) feature to patchwork with the goal to make the process of submitting a patch easier for newbies and people generally less familiar with patch-based development. This was discussed previously on the workflows list:

Re: RFE: use patchwork to submit a patch

On Fri, Oct 11, 2019 at 08:38:49AM +1100, Daniel Axtens wrote: Hi Konstantin, tl;dr: I think a git-to-email bridge is a good step. I'm not sure why patchwork would be the thing to build it on top of, and I'm worried that it would slow us both down. I'm very open to being convinced though. In

Re: RFE: use patchwork to submit a patch

On Thu, Oct 10, 2019 at 03:07:29PM -0300, Mauro Carvalho Chehab wrote: - the patch submission screen has a succession of screens: 1. a screen with a single field allowing a user to paste a URL to their fork of the git repository. This will raise the bar, as it will force all developers

Re: [PATCH] Fix issue with delegation of patch via REST API

On Wed, 9 Oct 2019 at 12:58, Bjorn Helgaas wrote: > > On Thu, Oct 3, 2019 at 4:22 PM Bjorn Helgaas wrote: > > > > I can't get patchwork delegation via git-pw to work either on ozlabs > > or kernel.org. Any hints on where to look or more data to collect? > > This magically started working on

Re: RFE: use patchwork to submit a patch

On Fri, Oct 11, 2019 at 10:57:02AM +0200, Greg KH wrote: So other than that minor thing, sounds interesting. It's hard to determine just how difficult the whole "set up git and send a patch out" process is for people these days given the _huge_ numbers of new contributions we keep getting, and

Re: RFE: use patchwork to submit a patch

On Fri, Oct 11, 2019 at 09:23:08PM +, Eric Wong wrote: (This is the same reason I generally disagree with Eric Wong about preserving SMTP as the primary transmission protocol -- I've heard lots of complaints both from kernel developers and especially from people trying to contribute to CAF

[PATCH] Handle pull requests with random trailing space

Another fix for copy-pasted pull requests, this time for cases when something is copy-pasted from a terminal and retains all the bogus trailing whitespace. Example: https://lore.kernel.org/r/043eb5b2-a302-4de6-a3e8-8238e4948...@ti.com Signed-off-by: Konstantin Ryabitsev --- patchwork/parser.py

Patch [2/5] not part of the rest of the series

Hello: I have a rather strange case here: https://patchwork.kernel.org/project/linux-rdma/list/ If you look for "258273" in the page, you will find an oddball situation where a [v2,2/5] is randomly recorded as part of "Untitled series", even though the rest of the patches in that series are

Re: Patch [2/5] not part of the rest of the series

On Thu, Mar 19, 2020 at 03:28:32PM +, Stephen Finucane wrote: > > I have a rather strange case here: > > > > https://patchwork.kernel.org/project/linux-rdma/list/ > > > > If you look for "258273" in the page, you will find an oddball situation > > where a [v2,2/5] is randomly recorded as

0039_unique_series_references migration needs optimization

Hello: I may be venting some frustration, but I'm now 4 hours into a 2.1 -> 2.2 upgrade. The following query from 0039 has now been running over 3 hours: COMMAND: Query TIME: 10921 STATE: Sending data INFO: DELETE a FROM patchwork_seriesreference a

Re: 0039_unique_series_references migration needs optimization

On Tue, 13 Oct 2020 at 13:15, Konstantin Ryabitsev wrote: > I may be venting some frustration, but I'm now 4 hours into a > 2.1 -> 2.2 upgrade. The following query from 0039 has now been running > over 3 hours: > > COMMAND: Query > TIME: 10921 >

Parsing mail on a different system

Hello: Quick question -- does parsemail need to run on the same system where the frontend runs, or can this be done on another system that just writes to the same database? -K ___ Patchwork mailing list Patchwork@lists.ozlabs.org

Re: Parsing mail on a different system

On Wed, Oct 28, 2020 at 11:31:49AM +1100, Daniel Axtens wrote: > > I think we may be oversetimating how many people out there run > > patchwork. :) My general concern was to make sure that parsemail doesn't > > do things like clear django data. If, to your knowledge, all it does is > > write to

Re: UTF-8-challenged checkpatch on patchwork

On Tue, Dec 01, 2020 at 10:36:43AM -0800, Jakub Kicinski wrote: > > Not sure if this is a bug in requests or not, but the corruption is > > introduced in .text. Here's POC: > > > > > > #!/usr/bin/env python3 > > import requests > > > > pmbx = > >

Re: Introduction + Importing git mailing list archives

On Wed, Jun 16, 2021 at 05:14:23PM -0400, Raxel Gutierrez wrote: > I set up my development environment for Patchwork through the manual > installation steps. Since I am focusing on the Git project, I am > trying to set up a test instance using the Git mailing list archive. I > was able to

Re: Patchwork gets confused about authorship

On Thu, May 20, 2021 at 09:04:43PM +0200, Yann E. MORIN wrote: > > There's not even an X-Original-From: or anything like that, which would help > > avoid this problem, since Patchwork will recognize this situation and > > correctly substitute the list From with the original From. > > OK, so if we

Re: Patchwork gets confused about authorship

On Thu, May 20, 2021 at 06:15:51PM +0200, Yann E. MORIN wrote: > Hello, > > With recently noticed that patchwork gets confused about the authorship > of some patches. I wouldn't say that it's patchwork that gets confused about the authorship. If you examine the headers, it's clear that the list

Re: Patchwork gets confused about authorship

On Thu, May 20, 2021 at 12:39:43PM -0700, Jonathan Nieder wrote: > > It's only required if there is no DKIM signature on the original message > > (see > > my musings on this subject here: > > https://people.kernel.org/monsieuricon/subspace-mailing-list-server#appeasing-dmarc > > ) > > > > If

Re: Pain points in Git's patch flow

On Mon, Apr 19, 2021 at 09:49:46PM +0200, Sebastian Schuberth wrote: > > To watch a particular filename, the "dfn:" prefix may be used. > > The prefixes supported for a particular instance are documented in > > , and you > > can watch multiple files by

Re: Pain points in Git's patch flow

On Mon, Apr 19, 2021 at 07:54:37AM +0200, Sebastian Schuberth wrote: > > of these proposed alternatives involve moving away from something that's > > a distributed system today (E-Mail infrastructure, local clients), to > > what's essentially some website run by a centralized entity, in some > >

Re: Autodelegation based on more complex rules

On Wed, Feb 17, 2021 at 02:15:23PM +, Ali Alnubani wrote: > > I suggest that you do this outside of patchwork, using procmail and > > filtering > > hooks to set X-Patchwork-Delegate. This is what we do at kernel.org, though > > we > > don't directly parse the MAINTAINERS file. You can see our

Re: Autodelegation based on more complex rules

On Mon, Feb 15, 2021 at 12:14:47PM +, Ali Alnubani wrote: > Hi all, > > There are currently 2 ways in Patchwork to autodelegate patches. Patchwork > can either parse the hint header (X-Patchwork-Delegate), or it can lookup > the fnmatch-formatted rules for the project. > > Projects using a

2.2.5 release api-1.1 500 errors

Hello: After the 2.2.2->2.2.5 upgrade, we seem to be getting lots of /api/1.1/ errors for PATCH calls: PATCH /api/1.1/patches/{id}/ switching to /api/1.2/ seems to fix it, but requires other client app fixes for API incompatibility. Some of the others returning 500 errors are: GET

Re: PaReD: a patch relations detector for patchwork

On Sat, Sep 04, 2021 at 08:04:48AM +0200, Lukas Bulwahn wrote: > For completeness, I need to mention that Konstantin's b4 tool also > detects the "latest patch series" when you ask it to pick a patch > series from a kernel mailing list. I do not know how it determines > that (and I hope that

Re: Feature request: mbox for series

On Thu, Sep 16, 2021 at 08:51:21AM +0200, Rafał Miłecki wrote: > Could you consider support for downloading mbox for all patches in a > series? I'd like to use "curl | git am" to download & apply all > patches at once. That would save me quite some time of copying URLs of > single patches.

Re: [PATCH 1/2] REST: Don't error if a versioned field we would remove is absent

On Fri, 20 Aug 2021 at 17:59, Stephen Finucane wrote: > > We remove fields that shouldn't be seen on old versions of the API. > > This was done with `pop(field name)`, which will throw an exception > > if the named field is absent from the data. However, sometimes if > > a patch request is via an

Re: [PATCH 1/2] REST: Don't error if a versioned field we would remove is absent

On Wed, Oct 27, 2021 at 05:00:34PM +0100, Stephen Finucane wrote: > v2.2.6 is available now. Let me know if there are any issues. Thanks! > Somewhat related: are there any large blockers preventing you moving to > v3.0.x? > Is it the major version bump or removal of Python 2.7 support that's >

Re: PyPatchwork

On Tue, Feb 21, 2023 at 11:21:49AM -0800, Tedd Ho-Jeong An wrote: > Hi > > I wrote the python library to use Patchwork REST API for my own project > and I would like to share with Patchwork community. This is nice, thank you for putting that together! -K

Re: [Patchwork-maintainers] patchwork.ozlabs.org downtime for maintenance - 15/16 August

On Tue, Jan 16, 2024 at 11:05:42AM -0600, Rob Herring wrote: > > This improved things, but it seems like the DT PW has gotten slower > > again in the last few weeks. It's taking ~12sec to load the patch > > list. > > I'm still seeing this slowness and now to add to that intermittent 503 errors.