[00:20] <cjwatson> I am not completely sure that LP forbids copying source+binaries from a PPA to the primary archive if you aren't an archive admin.  I suspect it doesn't actually forbid this but should.
[00:21] <cjwatson> It should be possible to test on staging; the publisher won't run, but the copy job will (eventually).
[00:21] <cjwatson> (Tests that need the publisher to run need to be done on dogfood.paddev.net with assistance from an LP developer.)
[00:21] <tsimonq2> cjwatson: As far as I remember, the only way to do that is through the CI Train.
[00:21] <tsimonq2> Otherwise an archive admin is needed.
[00:22] <tsimonq2> (And that sort of thing would be documented in the CI Train logs publicly anyways.)
[00:22] <cjwatson> tsimonq2: From code inspection I believe that you are mistaken, but feel free to prove me wrong.
[00:23] <cjwatson> (I think your understanding is how it *should* work, but ...)
[00:23] <tsimonq2> Well, anybody with upload access can use the tool, but an archive admin has to approve it because it comes from a PPA.
[00:24] <tsimonq2> (I remember this from when we had problems landing something with the CI Train so I asked Gianfranco to use copy-package and he needed to poke an archive admin.)
[00:25] <tsimonq2> cjwatson: Maybe there's an edge case I'm not accounting for, but as far as I remember, that's how it works.
[00:26] <cjwatson> tsimonq2: I don't believe any of the above is true.
[00:27] <tsimonq2> cjwatson: Which part of it?
[00:27] <cjwatson> tsimonq2: Any of the last three lines :)
[00:27] <cjwatson> Well, it's true that anyone with upload access can also copy.  The rest is AFAIK false.
[00:27] <tsimonq2> cjwatson: It would help if I could access staging.launchpad.net. ;P
[00:27] <cjwatson> There may have been some other reason that approval was required.
[00:27] <cjwatson> staging is always down at the weekend for restoration from a production dump.
[00:28] <cjwatson> It takes a couple of days.
[00:28] <tsimonq2> Alright.
[00:28] <tsimonq2> Will it be back tomorrow?
[00:28] <cjwatson> Hopefully.
[00:28] <tsimonq2> Alright, I'll check back with you once it's back up and once I've tested this.
[00:28] <tsimonq2> Any quirks I should be aware of when using staging for this sort of thing versus production?
[00:29] <tsimonq2> (Publisher shouldn't be needed for this.)
[00:30] <cjwatson> LP staging uses SSO staging for auth, but otherwise not that I can immediately think of.  Oh, you won't be able to build test packages to copy, so you'll have to pick something already built.
[00:30] <cjwatson> If it doesn't work you can always use dogfood instead.
[00:31] <tsimonq2> I might actually just use dogfood so I have the ability to test rebuild a package in a PPA with Backports enabled.
[00:31] <tsimonq2> cjwatson: How would I get copy-package to work with dogfood then?
[00:32] <cjwatson> -l dogfood
[00:32] <tsimonq2> Alright.
[00:32] <cjwatson> As I say you may need dev assistance - a lot of the usual cron jobs don't always run.
[00:32] <tsimonq2> Alright.
[00:33] <cjwatson> Upload processing runs frequently, as does the copier.  The PPA publisher doesn't currently, but can.
[00:33] <cjwatson> https://paste.ubuntu.com/26205792/ (obviously substituting your username) works for uploads.
[00:34] <cjwatson> All details subject to change as dogfood is a developer playground.
[00:34] <tsimonq2> Alright.
[00:34] <tsimonq2> cjwatson: Is that for PPAs or archive uploads?
[00:34] <tsimonq2> (Would it be the same with s/upload/ppa/ ?)
[00:36] <cjwatson> Keep the FQDN the same, but you can upload to any archive that you have access to that way - it takes an archive reference following dogfood-sftp: on the dput command line.
[00:36] <cjwatson> i.e. the same syntax that you see at the end of copy-package --help
[00:36] <tsimonq2> Alright.
[00:37] <cjwatson> (Except possibly a leading "ppa:" might not work, I forget.)
[00:37] <tsimonq2> I'll play with it.
[00:42] <tsimonq2> cjwatson: Could you please let my packages build? :)
[00:42] <cjwatson> ?
[00:43] <cjwatson> That shouldn't block on us ...
[00:43] <cjwatson> Oh, conceivably all the builders are down
[00:43] <tsimonq2> As far as I can tell, the Launchpad builders for several arches are on Manual.
[00:44] <cjwatson> We often use dogfood for testing new builder clouds and such.
[00:44] <tsimonq2> Oh, I can see that.
[00:45] <cjwatson> I've turned on a couple.
[00:45] <cjwatson> Er, or not.
[00:45] <cjwatson> Now I have.
[00:48] <cjwatson> (You might find it less time-consuming to use smaller packages for testing things like copies, though ...)
[00:48] <tsimonq2> (I did realize that after the fact, but oh well.)
[00:49] <tsimonq2> s/realize/remember/
[01:01] <tsimonq2> cjwatson: Ftr, this is an example of a copy including binaries from a Bileto PPA: https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/5.9.2-3ubuntu1/+publishinghistory
[01:01] <tsimonq2> cjwatson: Looking back in logs, Gianfranco executed "./copy-package --from=ppa:ci-train-ppa-service/ubuntu/3020 --from-suite=bionic --to=ubuntu --to-suite=bionic-proposed --include-binaries qtdeclarative-opensource-src"
[01:04] <cjwatson> tsimonq2: That was held for approval simply because bionic wasn't fully open yet at that time.
[01:04] <cjwatson> Proves nothing much - all uploads were held for approval.
[01:04] <tsimonq2> cjwatson: Oh, good point.
[01:04] <tsimonq2> Er, wait... was it?
[01:05] <cjwatson> Ah, hm, I'm wrong.
[01:05] <tsimonq2> Yep: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html
[01:10] <cjwatson> tsimonq2: So ... was it in fact held in unapproved?  I see no mention of it in #ubuntu-release IRC logs around that time.
[01:11] <tsimonq2> cjwatson: If I remember correctly, yes.
[01:13] <cjwatson> [2017-11-02 15:41:15,521: INFO/Worker-2] Running <PlainPackageCopyJob to copy package qtdeclarative-opensource-src from ~ci-train-ppa-service/ubuntu/3020, RELEASE pocket, in ubuntu bionic to ubuntu, PROPOSED pocket, in ubuntu bionic, including binaries> (ID 39344156) in status Waiting
[01:13] <cjwatson> [2017-11-02 15:41:21,426: DEBUG/Worker-2] Packages copied to Primary Archive for Ubuntu:
[01:13] <cjwatson> And in fact more clearly:
[01:13] <cjwatson> [2017-11-02 15:41:21,163: DEBUG/Worker-2]   Subject: [ubuntu/bionic-proposed] qtdeclarative-opensource-src 5.9.2-3ubuntu1 (Accepted)
[01:13] <cjwatson> tsimonq2: This upload was not held for approval.
[01:14] <tsimonq2> cjwatson: Could it be that CI Train PPA uploads are whitelisted?
[01:14] <cjwatson> tsimonq2: It is possible (even probable) that Bileto required an archive admin to sign it off, but that's it deliberately going over and above Launchpad's checks.
[01:15] <tsimonq2> cjwatson: But isn't this intentional for the function of Bileto?
[01:16] <cjwatson> tsimonq2: Sure, Bileto has to run its copies with somewhat elevated privileges and thus has to do some checks itself first, but that mechanism wasn't used here.
[01:17] <cjwatson> tsimonq2: It looks like Gianfranco did the copy manually and thus bypassed Bileto's checks.
[01:17] <tsimonq2> cjwatson: Hm, so this makes me wonder. When doing `./copy-package -l dogfood -s zesty --from=ppa:tsimonq2/ubuntu/testing-backports --to=ubuntu --to-suite=zesty-proposed vlc` I get "The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?" which makes me think that a proper mechanism *is* in place.
[01:18] <tsimonq2> Er...
[01:18] <tsimonq2> This database is from before I joined MOTU.
[01:18] <tsimonq2> So that makes sense.
[01:18] <cjwatson> tsimonq2: There are checks that you're permitted to upload, but those checks don't include anything that cares about whether you used the --include-binaries flag, AFAICS.
[01:18] <cjwatson> That's all I'm saying here.
[01:19] <tsimonq2> cjwatson: Right, so could you add me to MOTU on dogfood so I can try this one more time? (Unless I'm misunderstanding you here?)
[01:19] <cjwatson> Your test was wrong anyway, since you didn't use --include-binaries.
[01:20] <tsimonq2> Right, and I've now included that.
[01:21] <cjwatson> tsimonq2: Added you to ~motu on DF
[01:22] <tsimonq2> cjwatson: Oh, look: https://dogfood.paddev.net/ubuntu/zesty/+queue?queue_state=1
[01:22] <tsimonq2> So it does indeed show up as a sync in unapproved.
[01:23] <cjwatson> tsimonq2: Oh, look: https://dogfood.paddev.net/ubuntu/+series
[01:23] <cjwatson> zesty is CURRENT
[01:23] <cjwatson> you need to test artful
[01:23] <tsimonq2> Indeed.
[01:24] <cjwatson> (otherwise you're just testing the "is this an SRU?" logic)
[01:24] <tsimonq2> Gotcha.
[01:24]  * cjwatson -> bed
[01:24] <tsimonq2> o/
[15:00] <rbasak> !dmb-ping
[17:53] <tumbleweed> jbicha: ah, yes, teela is short of disk space
[19:10] <tsimonq2> ahasenack: Congrats!
[19:11] <ahasenack> thanks tsimonq2
[19:17] <tsimonq2> //
[19:17] <tsimonq2> 
[20:11] <tumbleweed> jbicha: ok, it should update again today
[20:16] <jbicha> thank you :)
[21:41] <rlink> An SRU of mine was promoted from xenial-proposed to -updates, but was pulled after 10% propagation because of an end-user error report.  I got an email with a link to the error report, but don't have authorization to see it.  Filled out the form requesting access, and it's been pending for a week.  Little help here?
[21:46] <jbicha> bdmurray: are you around? ^
[21:46] <jbicha> rlink: a lot of people are on holiday break
[21:55] <coreycb> RAOF: hi, if you are around tomorrow (tues) could you take a look at neutron in the xenial upload queue? that one is hot for a customer.