=== mwhudson is now known as Guest60520
=== Guest60520 is now known as mwhudson_
=== ePierre__ is now known as ePierre
=== mwhudson is now known as Guest18633
=== ePierre__ is now known as ePierre
=== Guest18633 is now known as mwhudson_
=== mwhudson is now known as Guest42456
=== Guest42456 is now known as mwhudson_
=== pbek_ is now known as pbek
[08:56] <mvo> hey, I get import errors for the core18 github code import (https://code.launchpad.net/~mvo/snap-core18/github). it saysAssertionError: Invalid sha for <Commit 9e3923f554968dc57e72dc5e0362010616c0b287>: f6761bb6d9ea518f7b476d4ed68147c44b12d7b8   - anything I can do to fix or workaround?
[09:07] <wgrant> mvo: Are you deliberately doing a git->bzr import rather than a git->git one?
[09:08] <mvo> wgrant: I did not find the knob to enable snap builds from a git repo, if you can point me to it I will be very happy and use git
[09:08] <mvo> I mean git->git
[09:09] <cjwatson> mvo: Go to the branch you want to build it from
[09:09] <cjwatson> It's there, rather than on the repo
[09:09] <mvo> oh, ok. let me try that
[09:09] <mvo> thank you!
[09:10] <cjwatson> (Once we have a semi-decent branch picker, I might add it to the repo as well to reduce confusion)
[09:12] <mvo> cjwatson, wgrant going to the right place seems to have helped, I have a create-snap-package link now. thanks for your help!
[09:12] <cjwatson> Cool
[09:13] <cjwatson> The git->bzr thing is surely a bug, but whether anyone will ever get to it ...
[09:13] <mvo> cjwatson: yeah, I don't care about this at all, I just want the snap to build :)
[09:15] <mvo> I will delete the bzr branch once sergio removed his test-snap build from it (right now I can't because there is a snap build depending on it)
[09:15] <mvo> would it be possible to get a slight increase of the default build score for core18 ?
[09:16] <cjwatson> We could, but is it needed?  The build queue is pretty empty apart from test rebuilds on ARM, so it should be dispatched quickly anyway
[09:25] <mvo> yeah, it seems to be fine. it initially told me 1h wait on amd64 but that was a bit on the pessimistic side it seems
[09:27] <cjwatson> I poked a few builders back into action, which will have helped
[09:27] <mvo> heh
[09:27] <mvo> ok
[09:27] <mvo> thank you!
[11:19] <gpiccoli> Hi folks! I'm experiencing some timeouts while comment in Launchpad - after reloading the page about 8 times, I managed to get my comment published. Quick look on Google showed me a LP bug about this: #1657292
[11:20] <gpiccoli> It shows as fix released...but I just experienced the issue. Does anybody know the root cause?
[11:20] <gpiccoli> Thanks in advance
[11:43] <cjwatson> gpiccoli: It's some strange periodic internal postgresql thing that we've never managed to track down
[11:44] <gpiccoli> interesting cjwatson...so do you know the reason LP #1657292 is marked as Fix Released?
[11:44] <ubot5`> Launchpad bug 1657292 in Launchpad itself "timeout error on launchpad" [Undecided,Fix released] https://launchpad.net/bugs/1657292
[11:44] <gpiccoli> i mean...which fix?
[11:44] <cjwatson> gpiccoli: because some random person did that
[11:44] <gpiccoli> hahaha
[11:44] <gpiccoli> nifty!
[11:45] <cjwatson> like, the bug reporter closed their own bug
[11:45] <gpiccoli> Oh cool, and is it possible for me, after comment there, that no fix was released and the bug still happens?
[11:45] <cjwatson> of course it is
[11:45] <gpiccoli> cool, I'll do it =]
[11:45] <gpiccoli> tnx cjwatson
[11:45] <cjwatson> it's also useless :)
[11:46] <gpiccoli> oh...meaning noone will ever try to fix this ?
[11:46] <cjwatson> we know about it, but the best hope we have is to upgrade to a newer postgresql and hope that we get some more information that way
[11:46] <cjwatson> no, meaning that other people have already made the same comment
[11:46] <cjwatson> and there are other open bugs about the same thing
[11:47] <gpiccoli> really? I'll try to find some, worth to close the newer as dup of the older ones right?
[11:47] <gpiccoli> this one was my first google result
[11:48] <cjwatson> hmm, now I say that I can't find any
[11:49] <cjwatson> let me reopen this one and clean up the metadata to be vaguely useful
[11:49] <gpiccoli> Great cjwatson, thanks a lot
[11:53] <cjwatson> done
[12:01] <gpiccoli> tnx cjwatson
[15:30] <acheronuk> s390x builders need a poke?
[15:39] <cjwatson> acheronuk: I/O error trying to launch instances, won't be trivial to resolve, may take until tomorrow
[15:40] <acheronuk> cjwatson: ok. thanks for the info
[16:15] <ricotz> cjwatson, hi, are there issues with ppa uploads not working occasionally?
[16:16] <cjwatson> ricotz: You'll have to give examples
[16:17] <ricotz> cjwatson, trying to upload a larger package which takes 2 hours here which gets stuck at the end
[16:18] <ricotz> dput doesnt show an error, just gets stuck indefinitely
[16:19] <cjwatson> ricotz: We did hear of some problems with large uploads, not diagnosed yet.  It's worth trying whichever of SFTP or FTP you aren't currently using
[16:25] <ricotz> cjwatson, it is using ftp here
[16:25] <ricotz> using the default /etc/dput.cf
[16:32] <cjwatson> ricotz: OK, try SFTP instead as a workaround for the time being
[16:33] <ricotz> cjwatson, I see
[16:35] <ricotz> cjwatson, is this a recent problem or already randomly occurring in the past?
[16:37] <cjwatson> Somewhat recent as far as I can tell; I suspect it appeared when I upgraded txpkgupload to Twisted 16.5.0
[16:38] <cjwatson> Unfortunately I haven't had time to look into it yet
[16:38] <ricotz> alright, I was just hoping a retry could work, since the uploader machine doesn't have a registered ssh key
[16:39] <cjwatson> I'm afraid I don't know the exact conditions
[16:39] <cjwatson> You can certainly try ...
[16:42] <ricotz> ok, thanks
[16:55] <ricotz> cjwatson, the retry which was in progress worked out :)