=== morphis2 is now known as morphis [06:42] <RikMills> packages built 7 hours ago, still not published. idle x86 builders, but 44 jobs in the queue. [06:43] <RikMills> not nagging. I don't envy LP engineers sometimes! [06:44] <wgrant> Those 44 jobs are stuck because the publisher is, let's see [07:45] <oSoMoN> good morning launchpad! [07:45] <oSoMoN> I filed bug #1836010 re- the question I asked yesterday about webhooks [07:45] <ubot5> bug 1836010 in Launchpad itself "Webhook for package builds" [Undecided,New] https://launchpad.net/bugs/1836010 [08:44] <cjwatson> oSoMoN: Confused, because I already gave you the existing bug yesterday, didn't I? [08:44] <cjwatson> I guess this is slightly different [08:58] <oSoMoN> cjwatson, sorry I must have missed your message yesterday [08:59] <oSoMoN> what was the existing bug? [09:03] <cjwatson> You referred to it actually [09:03] <cjwatson> I've just added a backlink from https://bugs.launchpad.net/launchpad/+bug/1638333 [09:03] <ubot5> Ubuntu bug 1638333 in Launchpad itself "Webhook for archive having new binary package" [Low,Triaged] [09:08] <oSoMoN> cjwatson, thanks. I guess I should have started by looking for existing bugs before asking my question yesterday [09:09] <oSoMoN> cjwatson, does the use case make sense? [09:11] <cjwatson> It's reasonable, just not sure when we'd fit it in. (Though it's probably not completely inaccessible for a new developer) === mitya57_ is now known as mitya57 [10:01] <Nakato> Is there anyone here able to help me out with launchpad erroring out on a bug submission? [10:02] <cjwatson> Nakato: Do you have an OOPS ID? [10:02] <Nakato> cjwatson: OOPS-be239c7023dce658b606040ab1522a2f [10:02] <ubot5> https://oops.canonical.com/?oopsid=OOPS-be239c7023dce658b606040ab1522a2f [10:03] <cjwatson> Nakato: There's no source package in Ubuntu called "linux-snap" [10:04] <Nakato> Oh, okay, where can I file a bug for https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/Makefile ? [10:04] <cjwatson> Nakato: I don't know, you'll have to ask the kernel team [10:04] <ginggs> Is there a known problem uploading to PPA? I keep getting [Errno 104] Connection reset by peer [10:04] <cjwatson> Nakato: Try #ubuntu-kernel [10:05] <cjwatson> ginggs: Could be related to the rollout we did to make the uploader IPv6-ready I suppose [10:05] <cjwatson> ginggs: Are you using FTP? [10:05] <ginggs> cjwatson: yes, using ftp [10:10] <cjwatson> ginggs: Can you try stracing it from your end? Since it's FTP the trace shouldn't contain any secrets [10:10] <cjwatson> ginggs: strace -f -s 1024 -tt [10:16] <ginggs> cjwatson: it seems to be disconnected after PASV [10:16] <ginggs> let me know if i should send the trace somewhere [10:18] <cjwatson> ginggs: cjwatson@canonical.com please [10:19] <cjwatson> ginggs: In the meantime you should be able to use SFTP [10:20] <Nakato> Is it a bug that I was able to get to that bug-submission page that errored out? I started at this url: https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial then clicked "bugs" in the title, then "Report a bug". [10:23] <cjwatson> Nakato: Yes, it's https://bugs.launchpad.net/launchpad/+bug/1635118 [10:23] <ubot5> Ubuntu bug 1635118 in Launchpad itself "Submitting bug for non-existent distro source package triggers OOPS on submission, should not allow you to start" [Critical,Triaged] [10:24] <Nakato> Thanks cjwatson [10:24] <cjwatson> The fix that caused it was for a more important problem, so it needs some more digging rather than just reverting the change that introduced it [10:53] <ginggs> cjwatson: SFTP worked, thanks [10:56] <cjwatson> ginggs: strace> interesting - I have a nearly identical strace here except I get a proper response to PASV and everything works fine [10:59] <cjwatson> ginggs: What time zone is this strace in? [11:00] <ginggs> south africa, GMT +2 [11:00] <cjwatson> Thanks, even after all this time my interhemisphere timezone guessing still sucks [11:06] <RikMills> normal ftp stalled here as well. sftp succeeded [11:31] <cjwatson> I really don't understand this - it works fine for me, with the company VPN disabled [11:32] <cjwatson> Try "telnet ppa.launchpad.net 21", then "USER anonymous", "PASS testing", "PASV" and see what you get? [11:44] <ginggs> cjwatson: Connection closed by foreign host. [11:44] <cjwatson> What the heck is going on [11:45] <cjwatson> ginggs: Could I see the full transcript of that telnet session? [11:45] <ginggs> cjwatson: so at home, earlier today, dput was just stalling and never timing out. now at the office i'm getting the connection closed [11:45] <cjwatson> Including the "Trying ..." line at the start [11:46] <ginggs> https://paste.ubuntu.com/p/pwDvKDkWbk/ [11:47] <cjwatson> For me it's fine from home and from chiark, hangs from master.debian.org [11:50] <GyrosGeier> if I send "QUIT" right after PASV, I get 550 Requested action not taken: internal server error [11:50] <GyrosGeier> 221 Goodbye. [11:50] <GyrosGeier> so two responses to one command [11:54] <cjwatson> GyrosGeier: FTP permits multiple replies [11:54] <cjwatson> GyrosGeier: See RFC 959 section 4.2 [11:54] <cjwatson> GyrosGeier: "Every command must generate at least one reply, although there may be more than one" [11:57] <cjwatson> GyrosGeier: I don't know if it's correct in this case, but it seems to be permitted in general, even though it's bizarre. But presumably in your case PASV had already produced a response? [12:23] <cjwatson> ginggs: Would you mind filing a bug on https://bugs.launchpad.net/txpkgupload about this? I managed to reproduce it in an environment where I might be able to debug it [12:23] <cjwatson> Maybe [12:24] <ginggs> cjwatson: doing [12:25] <cjwatson> Also confirmed that reverting the recent deployment fixes it, so now just to work out why [12:29] <GyrosGeier> cjwatson, yes, it did [12:29] <GyrosGeier> there was 30 seconds pause after the PASV, which got a positive reply [12:30] <ginggs> cjwatson: LP: #1836059 [12:30] <ubot5> Launchpad bug 1836059 in txpkgupload "dput via ftp to ppa.launchpad.net failure" [Undecided,New] https://launchpad.net/bugs/1836059 [12:30] <GyrosGeier> so I'd say the error was definitely in response to the QUIT [12:31] <cjwatson> ginggs: thanks [12:32] <ginggs> cjwatson: np [12:38] <cjwatson> Huh, running txpkgupload on a different port makes it go away [12:38] <cjwatson> I wonder if we're managing to confuse some conntrack nonsense or something [12:39] <cjwatson> Oh, or maybe the problem is a leading ::ffff: in the PASV response [13:50] <cjwatson> ginggs,RikMills,GyrosGeier: Worked around for now [13:51] <RikMills> ty [15:40] <ginggs> cjwatson: workaround working, ta!