Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-20 Thread Daniel Axtens
>> socket.error: [Errno 111] Connection refused
>
> This looks like what would happen if you tried to use pwclient when our
> web server was down.  This happens every now and then for very short
> periods of time when we do updates to various things (including
> libraries that the web server itself depends on).
>
> Do the developers:  maybe it is worth catching this error in particular
> and giving some reasonable message (or, optionally,trying again after a
> short wait - or both).

Yep. So I want to rewrite pwclient to use the new API - this will mean
we can drop XMLRPC and also help to fix the issue where a patch with ^L in
it will break pwclient. When I do that, I will fix this. I have opened
https://github.com/getpatchwork/patchwork/issues/172 to help me
remember.

Regards,
Daniel

> -- 
> Cheers,
> Stephen Rothwell
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-20 Thread Stephen Rothwell
Hi Jeff,

On Tue, 20 Mar 2018 15:28:46 -0700 Jeff Kirsher  
wrote:
>
> Thanks and so far it looks like it is fixed, I will continue to
> monitor it though.  I did notice pwclient throwing some errors, such
> as:
> 
> Traceback (most recent call last):
>   File "/home/jtkirshe/bin/pwclient", line 827, in 
> main()
>   File "/home/jtkirshe/bin/pwclient", line 780, in main
> action_get(rpc, patch_id)
>   File "/home/jtkirshe/bin/pwclient", line 300, in action_get
> patch = rpc.patch_get(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 1311, in single_request
> self.send_content(h, request_body)
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1459, in send_content
> connection.endheaders(request_body)
>   File "/usr/lib64/python2.7/httplib.py", line 1038, in endheaders
> self._send_output(message_body)
>   File "/usr/lib64/python2.7/httplib.py", line 882, in _send_output
> self.send(msg)
>   File "/usr/lib64/python2.7/httplib.py", line 844, in send
> self.connect()
>   File "/usr/lib64/python2.7/httplib.py", line 821, in connect
> self.timeout, self.source_address)
>   File "/usr/lib64/python2.7/socket.py", line 575, in create_connection
> raise err
> socket.error: [Errno 111] Connection refused

This looks like what would happen if you tried to use pwclient when our
web server was down.  This happens every now and then for very short
periods of time when we do updates to various things (including
libraries that the web server itself depends on).

Do the developers:  maybe it is worth catching this error in particular
and giving some reasonable message (or, optionally,trying again after a
short wait - or both).
-- 
Cheers,
Stephen Rothwell


pgpHhR5yOOflo.pgp
Description: OpenPGP digital signature
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-20 Thread Jeff Kirsher
On Tue, Mar 20, 2018 at 5:19 AM, Jeremy Kerr  wrote:
> Hi all,
>
> Good news: with the logging we had in place recently (and a fix to
> correct error reporting), it looks like we've found the problem with
> parsing emails from a series. This issue was recently addressed by
> Daniel, so I've updated patchwork.ozlabs.org to run the current
> stable/2.0 branch, which has fixes for these. Hopefully this resolves
> the issue with dropped patches.
>
> The update should also make the mail parser a little more robust against
> transient failures too.
>
> Let me know how things go over the next few days.
>
> Thomas and Dave: please keep using the custom addresses you've
> configured for the incoming mail feed; this will allow me to keep an eye
> on things on my side too. Assuming everything goes fine, we can revert
> to the usual address next week.
>

Thanks and so far it looks like it is fixed, I will continue to
monitor it though.  I did notice pwclient throwing some errors, such
as:

Traceback (most recent call last):
  File "/home/jtkirshe/bin/pwclient", line 827, in 
main()
  File "/home/jtkirshe/bin/pwclient", line 780, in main
action_get(rpc, patch_id)
  File "/home/jtkirshe/bin/pwclient", line 300, in action_get
patch = rpc.patch_get(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 1311, in single_request
self.send_content(h, request_body)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1459, in send_content
connection.endheaders(request_body)
  File "/usr/lib64/python2.7/httplib.py", line 1038, in endheaders
self._send_output(message_body)
  File "/usr/lib64/python2.7/httplib.py", line 882, in _send_output
self.send(msg)
  File "/usr/lib64/python2.7/httplib.py", line 844, in send
self.connect()
  File "/usr/lib64/python2.7/httplib.py", line 821, in connect
self.timeout, self.source_address)
  File "/usr/lib64/python2.7/socket.py", line 575, in create_connection
raise err
socket.error: [Errno 111] Connection refused

So I downloaded a new copy of pwclient (in case it needed to be
updated) and the above error has only happened once.  Thought I would
make you aware of it, just in case it was not expected.

-- 
Cheers,
Jeff
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-20 Thread Thomas Petazzoni
Hello Jeremy,

On Tue, 20 Mar 2018 20:19:01 +0800, Jeremy Kerr wrote:

> Good news: with the logging we had in place recently (and a fix to
> correct error reporting), it looks like we've found the problem with
> parsing emails from a series. This issue was recently addressed by
> Daniel, so I've updated patchwork.ozlabs.org to run the current
> stable/2.0 branch, which has fixes for these. Hopefully this resolves
> the issue with dropped patches.
> 
> The update should also make the mail parser a little more robust against
> transient failures too.
> 
> Let me know how things go over the next few days.
> 
> Thomas and Dave: please keep using the custom addresses you've
> configured for the incoming mail feed; this will allow me to keep an eye
> on things on my side too. Assuming everything goes fine, we can revert
> to the usual address next week.

Thanks a lot for this debugging effort! We'll monitor how patchwork
behaves in the next days and give you some feedback (good or bad).

Thanks again!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-20 Thread Jeremy Kerr

Hi all,

Good news: with the logging we had in place recently (and a fix to
correct error reporting), it looks like we've found the problem with
parsing emails from a series. This issue was recently addressed by
Daniel, so I've updated patchwork.ozlabs.org to run the current
stable/2.0 branch, which has fixes for these. Hopefully this resolves
the issue with dropped patches.

The update should also make the mail parser a little more robust against
transient failures too.

Let me know how things go over the next few days.

Thomas and Dave: please keep using the custom addresses you've
configured for the incoming mail feed; this will allow me to keep an eye
on things on my side too. Assuming everything goes fine, we can revert
to the usual address next week.

Cheers,


Jeremy
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-14 Thread Jeff Kirsher
On Mon, Mar 12, 2018 at 2:23 PM, Peter Korsgaard  wrote:
>> "daggs" == daggs   writes:
>
> Hi,
>
>  > happened to me too (not rejection), I've sent 4 patches in hope that
>  > they will be reviewed on the hackathon but I don't see them in
>  > patchwork.
>
> I guess you are referring to these patches?
>
> http://lists.busybox.net/pipermail/buildroot/2018-March/215615.html
>
> If so, they made it to the list atleast. We'll get to them sooner or
> later.
>
>> do I need to resend the patches?
>
> Until we have a fix for patchwork I would prefer not, changes are that
> one or more patches will be missed anyway.
>

This is getting to be very frustrating, at least from a maintainers
standpoint.  Consistently I am seeing only a few patches from a series
show up in patchworks.  Most recently less than 10 minutes ago with
the intel-wired-lan project, I attempted to resend a series of patches
that someone else sent on Monday, just because patchworks did not pick
it up the first time.  Now it only picked up 2 of the 7 patches.  Will
this issue be resolved any time soon?

-- 
Cheers,
Jeff
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-12 Thread Peter Korsgaard
> "daggs" == daggs   writes:

Hi,

 > happened to me too (not rejection), I've sent 4 patches in hope that
 > they will be reviewed on the hackathon but I don't see them in
 > patchwork.

I guess you are referring to these patches?

http://lists.busybox.net/pipermail/buildroot/2018-March/215615.html

If so, they made it to the list atleast. We'll get to them sooner or
later.

> do I need to resend the patches?

Until we have a fix for patchwork I would prefer not, changes are that
one or more patches will be missed anyway.

-- 
Bye, Peter Korsgaard
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-12 Thread Daniel Axtens
Hi Jeremy,

> Hi Daniel,
>
>> We have quite a few of these sitting in our queue :-(
>
> After a bit of time with some extra debug enabled for the buildroot mail
> feed, I see this for the failed parsemail invocations where we've
> returned a temp-fail:
>
>   No handlers could be found for logger 
> "patchwork.management.commands.parsemail"
>
> If you recall, we had to alter the logging configuration for the ozlabs
> instance:
>
>   --- a/patchwork/settings/production.py
>   +++ b/patchwork/settings/production.py
>   @@ -70,7 +70,7 @@
>STATIC_URL = '/static/'
>
>
>   -LOGGING = {
>   +_LOGGING = {
>'version': 1,
>'disable_existing_loggers': False,
>'formatters': {
>
> [this was your suggested fix an issue with parsemail failing with the
> shipped LOGGING configuration, but I don't have the specifics of that..]
>
Ergh, I was wondering when that would come back to bite us.

Would you mind sending me a copy of your LOGGING stanza (or just the
whole production.py file, appropriately redacted)? I have no idea how
yours fails as production.py is site specific and not managed by git.

Regards,
Daniel

> So, it appears that this workaround needs to be reworked?
>
> Regards,
>
>
> Jeremy
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-11 Thread Jeremy Kerr
Hi Daniel,

> We have quite a few of these sitting in our queue :-(

After a bit of time with some extra debug enabled for the buildroot mail
feed, I see this for the failed parsemail invocations where we've
returned a temp-fail:

  No handlers could be found for logger 
"patchwork.management.commands.parsemail"

If you recall, we had to alter the logging configuration for the ozlabs
instance:

  --- a/patchwork/settings/production.py
  +++ b/patchwork/settings/production.py
  @@ -70,7 +70,7 @@
   STATIC_URL = '/static/'
   
   
  -LOGGING = {
  +_LOGGING = {
   'version': 1,
   'disable_existing_loggers': False,
   'formatters': {

[this was your suggested fix an issue with parsemail failing with the
shipped LOGGING configuration, but I don't have the specifics of that..]

So, it appears that this workaround needs to be reworked?

Regards,


Jeremy
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-11 Thread Stephen Rothwell
Hi all,

On Sat, 10 Mar 2018 12:58:06 +0100 Peter Korsgaard  wrote:
>
> Any news on this? We still see missing mails, and I even received a
> temporary bounce from the patchwork addres this morning:
> 
> 
> This is the mail system at host ozlabs.org.
> 
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> 
> For further assistance, please send mail to postmaster.
> 
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> 
>The mail system
> 
>  (expanded from
> ): temporary failure

We have quite a few of these sitting in our queue :-(

I have extended the maximum time a mail can sit in the queue before it
is rejected to 12 days, so please see if you can figure out why these
mails are being TEMPFAILed before then (otherwise more mails may be
lost to patchwork).

-- 
Cheers,
Stephen Rothwell


pgp5qOGwnyyes.pgp
Description: OpenPGP digital signature
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-03-10 Thread Peter Korsgaard
> "Thomas" == Thomas Petazzoni  writes:

Hi Daniel,

 >> Andrew mentioned to me that we might have a race condition, and so I had
 >> a quick poke at loading patches in parallel. Sure enough I was able to
 >> easily hit an issue at least on the MySQL backend. (OzLabs uses postgres
 >> but it's still a good data-point as it shows we're not handling this
 >> sort of thing in code.)
 >> 
 >> This is quite possibly related to your issue - I will do some more
 >> investigation and let you know how we go.

 > Thanks a lot for the follow-up details on this.

 > I think it's worth mentioning that it seems to be a relatively "recent"
 > regression, probably within the last 6 months or so. In the past, we
 > were clearly not seeing such a problem, and all patches were properly
 > recorded. The problem is frequent enough that we would have noticed.

Any news on this? We still see missing mails, and I even received a
temporary bounce from the patchwork addres this morning:


This is the mail system at host ozlabs.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

 (expanded from
): temporary failure

Reporting-MTA: dns; ozlabs.org
X-Postfix-Queue-ID: 3zvfxM6m0Nz9sZ8
X-Postfix-Sender: rfc822; buildroot-boun...@busybox.net
Arrival-Date: Mon,  5 Mar 2018 10:53:10 +1100 (AEDT)

Final-Recipient: rfc822; patchwork-incoming-buildr...@bilbo.ozlabs.org
Original-Recipient: rfc822;incoming-buildr...@patchwork.ozlabs.org
Action: failed
Status: 4.3.0
Diagnostic-Code: x-unix; temporary failure

-- 
Bye, Peter Korsgaard
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-16 Thread Stephen Rothwell
Hi Andrew,

On Sat, 17 Feb 2018 14:29:04 +1100 Andrew Donnellan 
 wrote:
>
> On 17/02/18 01:49, Thomas Petazzoni wrote:
> > Thanks a lot for the follow-up details on this.
> > 
> > I think it's worth mentioning that it seems to be a relatively "recent"
> > regression, probably within the last 6 months or so. In the past, we
> > were clearly not seeing such a problem, and all patches were properly
> > recorded. The problem is frequent enough that we would have noticed.  
> 
> We have, anecdotally, noticed some regressions in database performance 
> in patchwork 2.0 which might increase the likelihood of hitting race 
> conditions. Hmm.

Not to mention the load problems we have on ozlabs.org ...

-- 
Cheers,
Stephen Rothwell


pgpS77wPinXl_.pgp
Description: OpenPGP digital signature
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-16 Thread Andrew Donnellan

On 17/02/18 01:49, Thomas Petazzoni wrote:

Thanks a lot for the follow-up details on this.

I think it's worth mentioning that it seems to be a relatively "recent"
regression, probably within the last 6 months or so. In the past, we
were clearly not seeing such a problem, and all patches were properly
recorded. The problem is frequent enough that we would have noticed.


We have, anecdotally, noticed some regressions in database performance 
in patchwork 2.0 which might increase the likelihood of hitting race 
conditions. Hmm.


--
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: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-16 Thread Daniel Axtens
Hi Thomas,

Andrew mentioned to me that we might have a race condition, and so I had
a quick poke at loading patches in parallel. Sure enough I was able to
easily hit an issue at least on the MySQL backend. (OzLabs uses postgres
but it's still a good data-point as it shows we're not handling this
sort of thing in code.)

This is quite possibly related to your issue - I will do some more
investigation and let you know how we go.

Regards,
Daniel

> Hello,
>
> On Wed, 14 Feb 2018 14:56:56 +1100, Andrew Donnellan wrote:
>
>> > Can we do something about this ? We're really happy otherwise by the
>> > patchwork instance at ozlabs.org, and we would hate having to run our
>> > own instance :-/  
>> 
>> We've done some digging...
>> 
>> https://patchwork.ozlabs.org/patch/872845/
>> https://patchwork.ozlabs.org/patch/872846/
>> 
>> These are the other two patches in the series, and yet patchwork has 
>> assigned them two different series, so evidently something screwy is 
>> happening there.
>> 
>> sfr took a look at the mail logs for us, it looks like:
>> 
>> - all 3 emails were received and processed by our SMTP system
>> - patch 2 was received first, and patches 1 and 3 were received during 
>> the same second a couple of seconds later
>> 
>> Patch 3 has not hit the database at all, it's possible we've hit some 
>> race condition somewhere that prevented it from being saved at the same 
>> time as patch 1, or perhaps we ran into something completely 
>> different... we're going to add some extra logging to see if we can 
>> capture more info next time this happens.
>> 
>> Many apologies for the inconvenience!
>
> As asked by Jeremy, I've changed the patchwork e-mail address to which
> the Buildroot patches are being sent, so that you can add more logging,
> but only for Buildroot stuff.
>
> Regarding the patches not properly assigned to series, we have already
> seen that many times, even in situations were no patches are lost. Some
> patches in the series are properly marked as being part of the series,
> and some are not. It feels like if some patches are received before the
> cover letter, patchwork gets confused, but that's just a guess. It
> doesn't happen very often, but it does happen. However, this is a lot
> less annoying that "losing" patches.
>
> Thanks!
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> http://bootlin.com
> ___
> 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: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-14 Thread Thomas Petazzoni
Hello,

On Wed, 14 Feb 2018 14:56:56 +1100, Andrew Donnellan wrote:

> > Can we do something about this ? We're really happy otherwise by the
> > patchwork instance at ozlabs.org, and we would hate having to run our
> > own instance :-/  
> 
> We've done some digging...
> 
> https://patchwork.ozlabs.org/patch/872845/
> https://patchwork.ozlabs.org/patch/872846/
> 
> These are the other two patches in the series, and yet patchwork has 
> assigned them two different series, so evidently something screwy is 
> happening there.
> 
> sfr took a look at the mail logs for us, it looks like:
> 
> - all 3 emails were received and processed by our SMTP system
> - patch 2 was received first, and patches 1 and 3 were received during 
> the same second a couple of seconds later
> 
> Patch 3 has not hit the database at all, it's possible we've hit some 
> race condition somewhere that prevented it from being saved at the same 
> time as patch 1, or perhaps we ran into something completely 
> different... we're going to add some extra logging to see if we can 
> capture more info next time this happens.
> 
> Many apologies for the inconvenience!

As asked by Jeremy, I've changed the patchwork e-mail address to which
the Buildroot patches are being sent, so that you can add more logging,
but only for Buildroot stuff.

Regarding the patches not properly assigned to series, we have already
seen that many times, even in situations were no patches are lost. Some
patches in the series are properly marked as being part of the series,
and some are not. It feels like if some patches are received before the
cover letter, patchwork gets confused, but that's just a guess. It
doesn't happen very often, but it does happen. However, this is a lot
less annoying that "losing" patches.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-13 Thread Andrew Donnellan

On 14/02/18 09:19, Thomas Petazzoni wrote:

Patches 1/3 and 2/3 in this series have been recorded, but not Patch
3/3.

This is really getting annoying for the Buildroot project, and we may
potentially "miss" contributions because of this: we entirely rely on
patchwork as our TODO-list, so if a patch is missing in patchwork, we
will forget about it. When only a few patches within a series are
missing, we obviously notice. But for single patches, when they are not
recorded, we simply miss them entirely.

Can we do something about this ? We're really happy otherwise by the
patchwork instance at ozlabs.org, and we would hate having to run our
own instance :-/


We've done some digging...

https://patchwork.ozlabs.org/patch/872845/
https://patchwork.ozlabs.org/patch/872846/

These are the other two patches in the series, and yet patchwork has 
assigned them two different series, so evidently something screwy is 
happening there.


sfr took a look at the mail logs for us, it looks like:

- all 3 emails were received and processed by our SMTP system
- patch 2 was received first, and patches 1 and 3 were received during 
the same second a couple of seconds later


Patch 3 has not hit the database at all, it's possible we've hit some 
race condition somewhere that prevented it from being saved at the same 
time as patch 1, or perhaps we ran into something completely 
different... we're going to add some extra logging to see if we can 
capture more info next time this happens.


Many apologies for the inconvenience!


Andrew

--
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: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-06 Thread Daniel Axtens
Jeremy Kerr  writes:

> Hi Andrew,
>
>> jk, any idea whether there's something particular about the ozlabs.org
>> instance that could be causing it to drop these patches?
>
> We're running plain upstream with regards to the parsing code; so if it
> parses we should be fine there.
>
> Assume the parsing is OK, there are a couple of reasons for potential
> drops:
>
>   - the database server was down at the time of parse. This is quite
> infrequent, but can happen during database upgrades. The last one of
> those was at 2018-01-27 05:08:30 UTC, so doesn't look like the case
> here
>
>   - after the update to 2.x, database load has significantly increased;
> there have been occasions where db connections are rejected due to
> this. The recent patchwork update should address some issues there,
> but I'm not sure whether we're back to optimal db behaviour now...

(FYI and slightly off-topic:)

Not yet - I'm tracking 2 distinct things:

 - a join is required to do any operation at all on patches, even
   listing them (join of sumbission and patch tables is required to get
   the project of a patch, as the project field belongs to the
   submission table).

 - massive api slowness, tracked on github and with some proposed
   patches on list.

Regards,
Daniel

>
> Cheers,
>
>
> Jeremy
> ___
> 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: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-06 Thread Thomas Petazzoni
Hello,

On Tue, 6 Feb 2018 17:03:50 +0800, Jeremy Kerr wrote:

> We're running plain upstream with regards to the parsing code; so if it
> parses we should be fine there.
> 
> Assume the parsing is OK, there are a couple of reasons for potential
> drops:
> 
>   - the database server was down at the time of parse. This is quite
> infrequent, but can happen during database upgrades. The last one of
> those was at 2018-01-27 05:08:30 UTC, so doesn't look like the case
> here
> 
>   - after the update to 2.x, database load has significantly increased;
> there have been occasions where db connections are rejected due to
> this. The recent patchwork update should address some issues there,
> but I'm not sure whether we're back to optimal db behaviour now...

Could it be that the e-mail hasn't been received? Could you check on
the server the logs, and see if the mail has been received at all?
Perhaps it was dropped due to spam detection or something like that.

It would be useful to understand if those e-mails that made it to the
mailing list were received by the patchwork server. We are really
seeing lots of patches being not recorded by patchwork, which makes it
a lot less usable :-/

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-06 Thread Jeremy Kerr


Hi Andrew,


jk, any idea whether there's something particular about the ozlabs.org
instance that could be causing it to drop these patches?


We're running plain upstream with regards to the parsing code; so if it
parses we should be fine there.

Assume the parsing is OK, there are a couple of reasons for potential
drops:

 - the database server was down at the time of parse. This is quite
   infrequent, but can happen during database upgrades. The last one of
   those was at 2018-01-27 05:08:30 UTC, so doesn't look like the case
   here

 - after the update to 2.x, database load has significantly increased;
   there have been occasions where db connections are rejected due to
   this. The recent patchwork update should address some issues there,
   but I'm not sure whether we're back to optimal db behaviour now...

Cheers,


Jeremy
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-06 Thread Andrew Donnellan

On 06/02/18 08:45, Thomas Petazzoni wrote:

Is there anything that can be done about this ? An example of
Message-Id that was not recorded is:

  Message-Id: 
<8027bae45d8e041c8a1e0bc714ab378ff984ded3.1517820133.git.yann.morin.1...@free.fr>


I've scraped the buildroot archives to see if there's anything obviously 
wrong with that particular message ID - it appears to parse fine.


jk, any idea whether there's something particular about the ozlabs.org 
instance that could be causing it to drop these patches?


--
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: patchwork.ozlabs.org down, and e-mails not recorded

2018-02-05 Thread Thomas Petazzoni
Hello,

On Mon, 8 Jan 2018 09:10:44 +0100, Thomas Petazzoni wrote:

> > Hmm, looking at the patch list, I also see that patch 2/3 in that series 
> > (https://patchwork.ozlabs.org/patch/852063/) wasn't correctly identified 
> > in the same series as patch 1 
> > (https://patchwork.ozlabs.org/patch/852062/) which is a bit weird.  
> 
> Note: this issue happened again yesterday. In this series of 4 patches:
> 
>   http://lists.busybox.net/pipermail/buildroot/2018-January/210935.html
> 
> Only patches 2/4 and 4/4 have been recorded by patchwork:
> 
>   https://patchwork.ozlabs.org/patch/856422/
>   https://patchwork.ozlabs.org/patch/856423/

This is still happening, and pretty badly. Sometimes almost entire
series are skipped. Most recent example is this series:

  http://lists.busybox.net/pipermail/buildroot/2018-February/213111.html

It has 15 patches and a cover letter, and all what patchwork recorded
is:

  https://patchwork.ozlabs.org/patch/869198/
  https://patchwork.ozlabs.org/patch/869197/

Only two patches out of 15 + a cover letter. Not great.

Is there anything that can be done about this ? An example of
Message-Id that was not recorded is:

 Message-Id: 
<8027bae45d8e041c8a1e0bc714ab378ff984ded3.1517820133.git.yann.morin.1...@free.fr>

Thanks a lot,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-01-08 Thread Thomas Petazzoni
Hello,

On Mon, 8 Jan 2018 10:33:21 +1100, Andrew Donnellan wrote:

> > Also, since a few weeks, we have seen that patchwork misses some
> > patches that are sent on the Buildroot mailing list. The mails are sent
> > on the mailing list, they are in the mailing list archives, but
> > patchwork does not record them.
> > 
> > An example is:
> > 
> >http://lists.busybox.net/pipermail/buildroot/2017-December/209885.html
> > 
> > PATCH 3/3 was not recorded by patchwork, while other patches in the
> > series have been.  
> 
> Hmm, looking at the patch list, I also see that patch 2/3 in that series 
> (https://patchwork.ozlabs.org/patch/852063/) wasn't correctly identified 
> in the same series as patch 1 
> (https://patchwork.ozlabs.org/patch/852062/) which is a bit weird.

Note: this issue happened again yesterday. In this series of 4 patches:

  http://lists.busybox.net/pipermail/buildroot/2018-January/210935.html

Only patches 2/4 and 4/4 have been recorded by patchwork:

  https://patchwork.ozlabs.org/patch/856422/
  https://patchwork.ozlabs.org/patch/856423/

Even though all 4 patches have been received through the mailing list.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: patchwork.ozlabs.org down, and e-mails not recorded

2018-01-07 Thread Andrew Donnellan

On 06/01/18 07:43, Thomas Petazzoni wrote:

Hello,

Just a quick note to let you know that from here, patchwork.ozlabs.org
seems to be down at this time (or awfully slow).


bilbo (i.e. ozlabs.org) required a reboot a couple of days ago for a 
kernel upgrade iirc.


ajd@bilbo:~$ uptime
 10:27:36 up 2 days,  1:10,  5 users,  load average: 1.38, 1.96, 1.64



Also, since a few weeks, we have seen that patchwork misses some
patches that are sent on the Buildroot mailing list. The mails are sent
on the mailing list, they are in the mailing list archives, but
patchwork does not record them.

An example is:

   http://lists.busybox.net/pipermail/buildroot/2017-December/209885.html

PATCH 3/3 was not recorded by patchwork, while other patches in the
series have been.


Hmm, looking at the patch list, I also see that patch 2/3 in that series 
(https://patchwork.ozlabs.org/patch/852063/) wasn't correctly identified 
in the same series as patch 1 
(https://patchwork.ozlabs.org/patch/852062/) which is a bit weird.




This again happened today. The first send of:

   http://lists.busybox.net/pipermail/buildroot/2018-January/210797.html

only had a few of its patches recorded by patchwork. It was resent a
few minutes later:

   http://lists.busybox.net/pipermail/buildroot/2018-January/210858.html

and then all the patches got recorded.

This is quite annoying. Is there a way to look in the patchwork logs
what has happened with those patches ?


I don't have access to the patchwork logs myself - jk, any thoughts?

--
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