pwclient breaking on a Form Feed character
Hi All, Been trying to get a patch but been unable due to: Traceback (most recent call last): File "pwclient", line 827, in main() File "pwclient", line 780, in main action_get(rpc, patch_id) File "pwclient", line 301, in action_get s = rpc.patch_get_mbox(patch_id) File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in single_request return self.parse_response(response) File "/usr/lib64/python2.7/xmlrpclib.py", line 1487, in parse_response p.feed(data) File "/usr/lib64/python2.7/xmlrpclib.py", line 558, in feed self._parser.Parse(data, 0) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 283, column 1 After going quite a bit of debugging I noticed the patch has a ^L (FF) in the diff. After deleting this out of the diff pwclient was able to get the patch. This bug was present on Python3/2. Ben ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Lost pull requests...
On Mon, 2018-01-15 at 13:25 -0500, David Miller wrote: > I've noticed for a while now that various pull requests are not > being recognized by patchwork.ozlabs.org and therefore don't > end up in the patchwork queue. > > Even ones I send myself are having this problem. All I am doing > is putting the contents of "git request-pull ..." into an email > and adding some other informative text to the beginning. > > I attach two examples of pull requests that patchwork at ozlabs > didn't queue up. > > Thanks! Here's our issue: https://github.com/git/git/commit/e66d7c37a5f The regex we used to detect these mails was case sensitive. I can submit a patch to simply make this case insensitive, which should resolve this issue. However, I also noticed that the file, as downloaded by my email client (Evolution), has CRLF line endings. $ file ~/Downloads/net_pull.txt /home/sfinucan/Downloads/net_pull.txt: ASCII text, with CRLF, CR line terminators I can't see how this would happen with 'git-request-pull', so can I safely assume it's my email client messing up here? Cheers, Stephen ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: pwclient breaking on a Form Feed character
On Wed, 2018-01-17 at 11:46 +, Benjamin Copeland wrote: > Hi All, > > Been trying to get a patch but been unable due to: > > Traceback (most recent call last): > File "pwclient", line 827, in > main() > File "pwclient", line 780, in main > action_get(rpc, patch_id) > File "pwclient", line 301, in action_get > s = rpc.patch_get_mbox(patch_id) > File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ > return self.__send(self.__name, args) > File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request > verbose=self.__verbose > File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request > return self.single_request(host, handler, request_body, verbose) > File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in > single_request > return self.parse_response(response) > File "/usr/lib64/python2.7/xmlrpclib.py", line 1487, in > parse_response > p.feed(data) > File "/usr/lib64/python2.7/xmlrpclib.py", line 558, in feed > self._parser.Parse(data, 0) > xml.parsers.expat.ExpatError: not well-formed (invalid token): line > 283, column 1 > > After going quite a bit of debugging I noticed the patch has a ^L > (FF) in the diff. After deleting this out of the diff pwclient was > able to get the patch. > > This bug was present on Python3/2. Have you got a link to the offending patch? This will allow me to fix the issue and put together a fix to prevent regressions. Stephen ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH v2] Avoid timezone confusion
On Tue, 2018-01-16 at 18:58 +0100, vkaba...@redhat.com wrote: > From: Veronika Kabatova > > Patchwork saves patches, comments etc with UTC timezone and reports > this time when opening the patch details. However, internally generated > processes such as events are reported with the instance's local time. > There's nothing wrong with that and making PW timezone-aware would add > useless complexity, but in a world-wide collaboration a lot of confusion > may arise as the timezone is not reported at all. Instance's local time > might be very different from the local time of CI integrating with PW, > which is different from the local time of person dealing with it etc. > > Use UTC everywhere by default instead of UTC for sumbissions and local > timezone for internally generated events (which is not reported). > > Signed-off-by: Veronika Kabatova What effect does this have on existing information in the database? Does this mean they'll all remain UTC+12 or are they stored in UTC format already? The Django docs [1] would lead me to suggest the former, given that we don't have USE_TZ set to True. I guess you can test that by setting up a deployment, creating information, then switching this option over. I'd do this myself but I'm not going to have time this week :( Stephen [1] https://docs.djangoproject.com/en/2.0/topics/i18n/timezones/ ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH v2] Avoid timezone confusion
On Wed, 2018-01-17 at 19:18 +, Stephen Finucane wrote: > On Tue, 2018-01-16 at 18:58 +0100, vkaba...@redhat.com wrote: > > From: Veronika Kabatova > > > > Patchwork saves patches, comments etc with UTC timezone and reports > > this time when opening the patch details. However, internally > > generated > > processes such as events are reported with the instance's local > > time. > > There's nothing wrong with that and making PW timezone-aware would > > add > > useless complexity, but in a world-wide collaboration a lot of > > confusion > > may arise as the timezone is not reported at all. Instance's local > > time > > might be very different from the local time of CI integrating with > > PW, > > which is different from the local time of person dealing with it > > etc. > > > > Use UTC everywhere by default instead of UTC for sumbissions and > > local > > timezone for internally generated events (which is not reported). > > > > Signed-off-by: Veronika Kabatova > > What effect does this have on existing information in the database? > Does this mean they'll all remain UTC+12 or are they stored in UTC > format already? The Django docs [1] would lead me to suggest the > former, given that we don't have USE_TZ set to True. > > I guess you can test that by setting up a deployment, creating > information, then switching this option over. I'd do this myself but > I'm not going to have time this week :( Might be relevant. https://gist.github.com/aaugustin/2971450 Stephen > Stephen > > [1] https://docs.djangoproject.com/en/2.0/topics/i18n/timezones/ > ___ > Patchwork mailing list > Patchwork@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/patchwork ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Lost pull requests...
From: Stephen Finucane Date: Wed, 17 Jan 2018 19:09:29 + > On Mon, 2018-01-15 at 13:25 -0500, David Miller wrote: >> I've noticed for a while now that various pull requests are not >> being recognized by patchwork.ozlabs.org and therefore don't >> end up in the patchwork queue. >> >> Even ones I send myself are having this problem. All I am doing >> is putting the contents of "git request-pull ..." into an email >> and adding some other informative text to the beginning. >> >> I attach two examples of pull requests that patchwork at ozlabs >> didn't queue up. >> >> Thanks! > > Here's our issue: > > https://github.com/git/git/commit/e66d7c37a5f > > The regex we used to detect these mails was case sensitive. I can > submit a patch to simply make this case insensitive, which should > resolve this issue. However, I also noticed that the file, as > downloaded by my email client (Evolution), has CRLF line endings. > >$ file ~/Downloads/net_pull.txt > /home/sfinucan/Downloads/net_pull.txt: ASCII text, with CRLF, CR line > terminators > > I can't see how this would happen with 'git-request-pull', so can I > safely assume it's my email client messing up here? Here is the attachment again, sent as Application/Octet-Stream instead of Text/Plain, see if it makes a difference: net_pull.txt Description: Binary data ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Lost pull requests...
On Wed, 2018-01-17 at 14:26 -0500, David Miller wrote: > From: Stephen Finucane > Date: Wed, 17 Jan 2018 19:09:29 + > > > On Mon, 2018-01-15 at 13:25 -0500, David Miller wrote: > >> I've noticed for a while now that various pull requests are not > >> being recognized by patchwork.ozlabs.org and therefore don't > >> end up in the patchwork queue. > >> > >> Even ones I send myself are having this problem. All I am doing > >> is putting the contents of "git request-pull ..." into an email > >> and adding some other informative text to the beginning. > >> > >> I attach two examples of pull requests that patchwork at ozlabs > >> didn't queue up. > >> > >> Thanks! > > > > Here's our issue: > > > > https://github.com/git/git/commit/e66d7c37a5f > > > > The regex we used to detect these mails was case sensitive. I can > > submit a patch to simply make this case insensitive, which should > > resolve this issue. However, I also noticed that the file, as > > downloaded by my email client (Evolution), has CRLF line endings. > > > >$ file ~/Downloads/net_pull.txt > > /home/sfinucan/Downloads/net_pull.txt: ASCII text, with CRLF, CR > line terminators > > > > I can't see how this would happen with 'git-request-pull', so can I > > safely assume it's my email client messing up here? > > Here is the attachment again, sent as Application/Octet-Stream > instead > of Text/Plain, see if it makes a difference: Yup, now we've got plain old ASCII, as expected. $ file ~/Downloads/net_pull.txt /home/sfinucan/Downloads/net_pull.txt: ASCII text I'll send out the patch shortly and backport to stable/2.0 once that's done. From there, it's up to Jeremy and the Ozlabs peeps to drag it in for patchwork.ozlabs.org. Stephen ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH] parser: Handle 'git-request-pull' mails from Git 2.14.3
Make the regex case insensitive to catch both 'git' and 'Git'. Signed-off-by: Stephen Finucane Fixes: #159 --- patchwork/parser.py| 2 +- .../mail/0017-git-pull-request-git-2-14-3.mbox | 164 + patchwork/tests/test_parser.py | 7 + 3 files changed, 172 insertions(+), 1 deletion(-) create mode 100644 patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox diff --git a/patchwork/parser.py b/patchwork/parser.py index 3acc6096..ac7dc5fe 100644 --- a/patchwork/parser.py +++ b/patchwork/parser.py @@ -833,7 +833,7 @@ def parse_pull_request(content): git_re = re.compile(r'^The following changes since commit.*' + r'^are available in the git repository at:\n' r'^\s*([\S]+://[^\n]+)$', -re.DOTALL | re.MULTILINE) +re.DOTALL | re.MULTILINE | re.IGNORECASE) match = git_re.search(content) if match: return match.group(1) diff --git a/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox b/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox new file mode 100644 index ..0c92b604 --- /dev/null +++ b/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox @@ -0,0 +1,164 @@ +Subject: [GIT] Networking +From: David Miller +To: torva...@linux-foundation.org +CC: a...@linux-foundation.org, net...@vger.kernel.org, +linux-ker...@vger.kernel.org +Date: Wed, 10 Jan 2018 17:21:11 -0500 (EST) +Sender: netdev-ow...@vger.kernel.org +X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) + + +1) BPF speculation prevention and BPF_JIT_ALWAYS_ON, from Alexei + Starovoitov. + +2) Revert dev_get_random_name() changes as adjust the error code returns + seen by userspace definitely breaks stuff. + +3) Fix TX DMA map/unmap on older iwlwifi devices, from Emmanuel + Grumbach. + +4) From wrong AF family when requesting sock diag modules, from + Andrii Vladyka. + +5) Don't add new ipv6 routes attached to the null_entry, from Wei + Wang. + +6) Some SCTP sockopt length fixes from Marcelo Ricardo Leitner. + +7) Don't leak when removing VLAN ID 0, from Cong Wang. + +8) Hey there's a potential leak in ipv6_make_skb() too, from Eric + Dumazet. + +Please pull, thanks a lot. + +The following changes since commit ef7f8cec80a0ba7bd00ece46844c8994117dc910: + + Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-08 20:21:39 -0800) + +are available in the Git repository at: + + git://git.kernel.org/pub/scm/linux/kernel/git/davem/net + +for you to fetch changes up to ccc12b11c5332c84442ef120dcd631523be75089: + + ipv6: sr: fix TLVs not being copied using setsockopt (2018-01-10 16:03:55 -0500) + + +Alexei Starovoitov (3): + selftests/bpf: fix test_align + bpf: prevent out-of-bounds speculation + bpf: introduce BPF_JIT_ALWAYS_ON config + +Andrii Vladyka (1): + net: core: fix module type in sock_diag_bind + +Cong Wang (1): + 8021q: fix a memory leak for VLAN 0 device + +Daniel Borkmann (1): + bpf: avoid false sharing of map refcount with max_entries + +David S. Miller (5): + Merge branch 'Ether-fixes-for-the-SolutionEngine771x-boards' + Merge git://git.kernel.org/.../bpf/bpf + Merge branch 'sctp-Some-sockopt-optlen-fixes' + Merge tag 'wireless-drivers-for-davem-2018-01-09' of git://git.kernel.org/.../kvalo/wireless-drivers + Merge branch 'mlxsw-couple-of-fixes' + +Emmanuel Grumbach (1): + iwlwifi: pcie: fix DMA memory mapping / unmapping + +Eric Dumazet (1): + ipv6: fix possible mem leaks in ipv6_make_skb() + +Jakub Kicinski (1): + nfp: always unmask aux interrupts at init + +Jiri Pirko (1): + mlxsw: spectrum_qdisc: Don't use variable array in mlxsw_sp_tclass_congestion_enable + +John Fastabend (1): + bpf: sockmap missing NULL psock check + +Kalle Valo (1): + Merge ath-current from git://git.kernel.org/.../kvalo/ath.git + +Kornilios Kourtis (1): + doc: clarification about setting SO_ZEROCOPY + +Loic Poulain (1): + wcn36xx: Fix dynamic power saving + +Madalin Bucur (1): + of_mdio: avoid MDIO bus removal when a PHY is missing + +Marcelo Ricardo Leitner (3): + sctp: GFP_ATOMIC is not needed in sctp_setsockopt_events + sctp: add a ceiling to optlen in some sockopts + sctp: make use of pre-calculated len + +Mathieu Xhonneux (1): + ipv6: sr: fix TLVs not being copied using setsockopt + +Mike Rapoport (1): + docs-rst: networking: wire up msg_zerocopy + +Nicolai Stange (1): + net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg() + +Sergei Shtylyov (2): + SolutionEngine771x: fix Ether platform data + SolutionEngine771x: add Ether TSU resource + +Wei Wang (1): + ipv6: remove null_entry before adding default route + +Xiongfeng Wang (2): + net: caif: us
Re: Lost pull requests...
From: Stephen Finucane Date: Wed, 17 Jan 2018 19:29:33 + > I'll send out the patch shortly and backport to stable/2.0 once that's > done. From there, it's up to Jeremy and the Ozlabs peeps to drag it in > for patchwork.ozlabs.org. Thank you. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: pwclient breaking on a Form Feed character
On 17 January 2018 at 19:13, Stephen Finucane wrote: > On Wed, 2018-01-17 at 11:46 +, Benjamin Copeland wrote: >> Hi All, >> >> Been trying to get a patch but been unable due to: >> >> Traceback (most recent call last): >> File "pwclient", line 827, in >> main() >> File "pwclient", line 780, in main >> action_get(rpc, patch_id) >> File "pwclient", line 301, in action_get >> s = rpc.patch_get_mbox(patch_id) >> File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ >> return self.__send(self.__name, args) >> File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request >> verbose=self.__verbose >> File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request >> return self.single_request(host, handler, request_body, verbose) >> File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in >> single_request >> return self.parse_response(response) >> File "/usr/lib64/python2.7/xmlrpclib.py", line 1487, in >> parse_response >> p.feed(data) >> File "/usr/lib64/python2.7/xmlrpclib.py", line 558, in feed >> self._parser.Parse(data, 0) >> xml.parsers.expat.ExpatError: not well-formed (invalid token): line >> 283, column 1 >> >> After going quite a bit of debugging I noticed the patch has a ^L >> (FF) in the diff. After deleting this out of the diff pwclient was >> able to get the patch. >> >> This bug was present on Python3/2. > > Have you got a link to the offending patch? This will allow me to fix > the issue and put together a fix to prevent regressions. https://patches-gcc.linaro.org/patch/411/ > > Stephen ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Lost pull requests...
On 18/01/18 06:09, Stephen Finucane wrote: The regex we used to detect these mails was case sensitive. I can submit a patch to simply make this case insensitive, which should resolve this issue. However, I also noticed that the file, as downloaded by my email client (Evolution), has CRLF line endings. $ file ~/Downloads/net_pull.txt /home/sfinucan/Downloads/net_pull.txt: ASCII text, with CRLF, CR line terminators I can't see how this would happen with 'git-request-pull', so can I safely assume it's my email client messing up here? Hence my patch from a few days ago (which I need to resubmit) - Thunderbird also saves with CRLF line endings. -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnel...@au1.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH] parser: Handle 'git-request-pull' mails from Git 2.14.3
Stephen Finucane writes: > Make the regex case insensitive to catch both 'git' and 'Git'. > > Signed-off-by: Stephen Finucane > Fixes: #159 > --- > patchwork/parser.py| 2 +- > .../mail/0017-git-pull-request-git-2-14-3.mbox | 164 > + > patchwork/tests/test_parser.py | 7 + > 3 files changed, 172 insertions(+), 1 deletion(-) > create mode 100644 patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox > > diff --git a/patchwork/parser.py b/patchwork/parser.py > index 3acc6096..ac7dc5fe 100644 > --- a/patchwork/parser.py > +++ b/patchwork/parser.py > @@ -833,7 +833,7 @@ def parse_pull_request(content): > git_re = re.compile(r'^The following changes since commit.*' + > r'^are available in the git repository at:\n' You could also have used 'the [gG]it repository', but your way means that if someone decides to be 'cool' and send 'ThE fOlLoWinG cHaNgEs SiNcE cOMMit'... we will catch that too, which is probably better. Reviewed-by: Daniel Axtens I'm happy to poke the OzLabs admins on irc once this is merged - they are more than capable of dealing with a local patch so a release is probably not a prerequisite here. Regards, Daniel > r'^\s*([\S]+://[^\n]+)$', > -re.DOTALL | re.MULTILINE) > +re.DOTALL | re.MULTILINE | re.IGNORECASE) > match = git_re.search(content) > if match: > return match.group(1) > diff --git a/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox > b/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox > new file mode 100644 > index ..0c92b604 > --- /dev/null > +++ b/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox > @@ -0,0 +1,164 @@ > +Subject: [GIT] Networking > +From: David Miller > +To: torva...@linux-foundation.org > +CC: a...@linux-foundation.org, net...@vger.kernel.org, > +linux-ker...@vger.kernel.org > +Date: Wed, 10 Jan 2018 17:21:11 -0500 (EST) > +Sender: netdev-ow...@vger.kernel.org > +X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) > + > + > +1) BPF speculation prevention and BPF_JIT_ALWAYS_ON, from Alexei > + Starovoitov. > + > +2) Revert dev_get_random_name() changes as adjust the error code returns > + seen by userspace definitely breaks stuff. > + > +3) Fix TX DMA map/unmap on older iwlwifi devices, from Emmanuel > + Grumbach. > + > +4) From wrong AF family when requesting sock diag modules, from > + Andrii Vladyka. > + > +5) Don't add new ipv6 routes attached to the null_entry, from Wei > + Wang. > + > +6) Some SCTP sockopt length fixes from Marcelo Ricardo Leitner. > + > +7) Don't leak when removing VLAN ID 0, from Cong Wang. > + > +8) Hey there's a potential leak in ipv6_make_skb() too, from Eric > + Dumazet. > + > +Please pull, thanks a lot. > + > +The following changes since commit ef7f8cec80a0ba7bd00ece46844c8994117dc910: > + > + Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-08 > 20:21:39 -0800) > + > +are available in the Git repository at: > + > + git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > + > +for you to fetch changes up to ccc12b11c5332c84442ef120dcd631523be75089: > + > + ipv6: sr: fix TLVs not being copied using setsockopt (2018-01-10 16:03:55 > -0500) > + > + > +Alexei Starovoitov (3): > + selftests/bpf: fix test_align > + bpf: prevent out-of-bounds speculation > + bpf: introduce BPF_JIT_ALWAYS_ON config > + > +Andrii Vladyka (1): > + net: core: fix module type in sock_diag_bind > + > +Cong Wang (1): > + 8021q: fix a memory leak for VLAN 0 device > + > +Daniel Borkmann (1): > + bpf: avoid false sharing of map refcount with max_entries > + > +David S. Miller (5): > + Merge branch 'Ether-fixes-for-the-SolutionEngine771x-boards' > + Merge git://git.kernel.org/.../bpf/bpf > + Merge branch 'sctp-Some-sockopt-optlen-fixes' > + Merge tag 'wireless-drivers-for-davem-2018-01-09' of > git://git.kernel.org/.../kvalo/wireless-drivers > + Merge branch 'mlxsw-couple-of-fixes' > + > +Emmanuel Grumbach (1): > + iwlwifi: pcie: fix DMA memory mapping / unmapping > + > +Eric Dumazet (1): > + ipv6: fix possible mem leaks in ipv6_make_skb() > + > +Jakub Kicinski (1): > + nfp: always unmask aux interrupts at init > + > +Jiri Pirko (1): > + mlxsw: spectrum_qdisc: Don't use variable array in > mlxsw_sp_tclass_congestion_enable > + > +John Fastabend (1): > + bpf: sockmap missing NULL psock check > + > +Kalle Valo (1): > + Merge ath-current from git://git.kernel.org/.../kvalo/ath.git > + > +Kornilios Kourtis (1): > + doc: clarification about setting SO_ZEROCOPY > + > +Loic Poulain (1): > + wcn36xx: Fix dynamic power saving > + > +Madalin Bucur (1): > + of_mdio: avoid MDIO bus removal when
Re: [PATCH] parser: Handle 'git-request-pull' mails from Git 2.14.3
Reviewed-by: Andrew Donnellan On 18/01/18 06:39, Stephen Finucane wrote: Make the regex case insensitive to catch both 'git' and 'Git'. Signed-off-by: Stephen Finucane Fixes: #159 --- patchwork/parser.py| 2 +- .../mail/0017-git-pull-request-git-2-14-3.mbox | 164 + patchwork/tests/test_parser.py | 7 + 3 files changed, 172 insertions(+), 1 deletion(-) create mode 100644 patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox diff --git a/patchwork/parser.py b/patchwork/parser.py index 3acc6096..ac7dc5fe 100644 --- a/patchwork/parser.py +++ b/patchwork/parser.py @@ -833,7 +833,7 @@ def parse_pull_request(content): git_re = re.compile(r'^The following changes since commit.*' + r'^are available in the git repository at:\n' r'^\s*([\S]+://[^\n]+)$', -re.DOTALL | re.MULTILINE) +re.DOTALL | re.MULTILINE | re.IGNORECASE) match = git_re.search(content) if match: return match.group(1) diff --git a/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox b/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox new file mode 100644 index ..0c92b604 --- /dev/null +++ b/patchwork/tests/mail/0017-git-pull-request-git-2-14-3.mbox @@ -0,0 +1,164 @@ +Subject: [GIT] Networking +From: David Miller +To: torva...@linux-foundation.org +CC: a...@linux-foundation.org, net...@vger.kernel.org, +linux-ker...@vger.kernel.org +Date: Wed, 10 Jan 2018 17:21:11 -0500 (EST) +Sender: netdev-ow...@vger.kernel.org +X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) + + +1) BPF speculation prevention and BPF_JIT_ALWAYS_ON, from Alexei + Starovoitov. + +2) Revert dev_get_random_name() changes as adjust the error code returns + seen by userspace definitely breaks stuff. + +3) Fix TX DMA map/unmap on older iwlwifi devices, from Emmanuel + Grumbach. + +4) From wrong AF family when requesting sock diag modules, from + Andrii Vladyka. + +5) Don't add new ipv6 routes attached to the null_entry, from Wei + Wang. + +6) Some SCTP sockopt length fixes from Marcelo Ricardo Leitner. + +7) Don't leak when removing VLAN ID 0, from Cong Wang. + +8) Hey there's a potential leak in ipv6_make_skb() too, from Eric + Dumazet. + +Please pull, thanks a lot. + +The following changes since commit ef7f8cec80a0ba7bd00ece46844c8994117dc910: + + Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-08 20:21:39 -0800) + +are available in the Git repository at: + + git://git.kernel.org/pub/scm/linux/kernel/git/davem/net + +for you to fetch changes up to ccc12b11c5332c84442ef120dcd631523be75089: + + ipv6: sr: fix TLVs not being copied using setsockopt (2018-01-10 16:03:55 -0500) + + +Alexei Starovoitov (3): + selftests/bpf: fix test_align + bpf: prevent out-of-bounds speculation + bpf: introduce BPF_JIT_ALWAYS_ON config + +Andrii Vladyka (1): + net: core: fix module type in sock_diag_bind + +Cong Wang (1): + 8021q: fix a memory leak for VLAN 0 device + +Daniel Borkmann (1): + bpf: avoid false sharing of map refcount with max_entries + +David S. Miller (5): + Merge branch 'Ether-fixes-for-the-SolutionEngine771x-boards' + Merge git://git.kernel.org/.../bpf/bpf + Merge branch 'sctp-Some-sockopt-optlen-fixes' + Merge tag 'wireless-drivers-for-davem-2018-01-09' of git://git.kernel.org/.../kvalo/wireless-drivers + Merge branch 'mlxsw-couple-of-fixes' + +Emmanuel Grumbach (1): + iwlwifi: pcie: fix DMA memory mapping / unmapping + +Eric Dumazet (1): + ipv6: fix possible mem leaks in ipv6_make_skb() + +Jakub Kicinski (1): + nfp: always unmask aux interrupts at init + +Jiri Pirko (1): + mlxsw: spectrum_qdisc: Don't use variable array in mlxsw_sp_tclass_congestion_enable + +John Fastabend (1): + bpf: sockmap missing NULL psock check + +Kalle Valo (1): + Merge ath-current from git://git.kernel.org/.../kvalo/ath.git + +Kornilios Kourtis (1): + doc: clarification about setting SO_ZEROCOPY + +Loic Poulain (1): + wcn36xx: Fix dynamic power saving + +Madalin Bucur (1): + of_mdio: avoid MDIO bus removal when a PHY is missing + +Marcelo Ricardo Leitner (3): + sctp: GFP_ATOMIC is not needed in sctp_setsockopt_events + sctp: add a ceiling to optlen in some sockopts + sctp: make use of pre-calculated len + +Mathieu Xhonneux (1): + ipv6: sr: fix TLVs not being copied using setsockopt + +Mike Rapoport (1): + docs-rst: networking: wire up msg_zerocopy + +Nicolai Stange (1): + net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg() + +Sergei Shtylyov (2): + SolutionEngine771x: fix Ether platform data + SolutionEngine771x: add Ether TSU resource + +Wei Wang (1): + ipv6: re
