[00:27] <Saviq> robru, didn't the train properly handle the case where MPs got removed from a silo? I mean with a default build job, should it not notice that there's an MP missing?
[00:27] <Saviq> had to explicitly tell it which projects to build
[00:28] <robru> Saviq: uh it iterates over the branches that are there and checks them for new commits, I guess if you remove an MP it wouldn't notice that
[00:46] <Saviq> robru, ok, I'll file a bug, thought it would
[00:46] <Saviq> robru, uh oh https://requests.ci-train.ubuntu.com/#/ticket/938
[00:46] <robru> Saviq: lp:cupstream2distro
[00:47] <Saviq> robru, yup, will do, tomorrow
[00:47] <robru> Ooh Jesus
[00:49] <robru> Saviq: ah, looks like you caught it mid-rollout, one old script in memory calling a new script that updated out from under it. I triggered a DIFF_ONLY, should fix it right up
[00:49] <Saviq> robru, ack,
[00:52] <robru> Looks good now
[01:57] <Saviq> robru, btw, any idea why unity-api does not have a packaging diff generated? just content.diff ↑?
[02:00] <robru> Saviq: because there are no packaging changes.
[02:00] <Saviq> robru, so changelog/cmakelists are not considered packaging any more?
[02:01] <Saviq> right, changelog would always trigger, duh
[02:01] <robru> Saviq: anymore? "packaging" diff only includes debian/ and excludes changelog
[02:01] <Saviq> robru, ok maybe I'm confused, but would swear CMakeLists.txt were considered before
[02:01] <Saviq> robru, anyway, wfm
[02:02] <robru> Saviq: I dunno maybe years ago. it's been just debian/ for a long time
[07:35] <robru> heh
[08:52] <Saviq> Mirv, morning, can I please ask you to press the ♻s on https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html and https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-051/excuses.html
[08:56] <Mirv> Saviq: sure
[08:58] <Mirv> Saviq: doh, unity-api is in main and I haven't yet applied for core-dev. the qtmir-gles shows a weird "You submitted an invalid request: Package qtmir-gles does not have any test results" that I haven't seen before
[08:58] <Mirv> sil2100: please retry the regression from https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html
[08:58] <sil2100> Mirv: on it
[08:58] <Saviq> Mirv, you not core-dev!? *gasp*
[08:58] <Mirv> sil2100: plus try if you get the same weird message as me from https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-051/excuses.html
[08:58] <sil2100> Saviq: exactly! I have no idea why Mirv didn't apply yet ;)
[08:58] <Mirv> Saviq: sorry :) I got so much PPU rights in addition to MOTU I'm too comfortable, but I really need to do the application
[09:01] <sil2100> Mirv: uh, same message
[10:05] <Saviq> sil2100, Mirv, so no idea about qtmir-gles in https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-051/excuses.html ? shall I talk to pitti?
[10:06] <Saviq> also, https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html is over an hour old now, any idea when would that get updated?
[10:36] <Mirv> Saviq: sorry, yes ping and quote the error we're getting on trying to retry it
[10:37] <Mirv> Saviq: it updates from my pov randomly :) roughly hourly, sometimes quicker. now updated 30min ago.
[10:37] <Saviq> Mirv, yeah, with dozens still "in progress" and nowhere to be seen in http://autopkgtest.ubuntu.com/running.shtml
[10:38] <Saviq> well, maybe not dozens :P
[10:38] <Saviq> asked about both
[10:53] <robru> Saviq: qtmir-gles is in running.shtml
[10:54] <Saviq> robru, yeah, pitti just restarted them
[10:56] <robru> Ah
[11:04] <cjwatson> Can I have some train advice please?  https://requests.ci-train.ubuntu.com/#/ticket/960 needs an upgrade fix to avoid problems for apt users in xenial (it was a one-character typo in the Replaces field).  Can I put this through the same not-quite-completely-landed silo without incurring another pass through QA?
[11:05] <robru> cjwatson: well you'd have to clear that with qa, technically everything targeting vivid overlay goes through them
[11:06] <robru> cjwatson: strictly speaking any rebuild will clear the qa signoff on the ticket
[11:06] <robru> If you ask them nicely they might just wave it through
[11:07] <cjwatson> robru: OK.  Is there some way I could just cause the change to go to xenial?  I could just manually upload to xenial-proposed ...
[11:07] <cjwatson> It's not particularly vital to have in the overlay since that won't typically be upgraded using apt
[11:07] <robru> cjwatson: yeah you could just upload to xenial.
[11:08] <cjwatson> All right, let's go with that for expediency's sake
[11:08] <robru> cjwatson: just make sure you sync to trunk after a xenial upload
[11:08] <cjwatson> robru: Yeah, I'll sync it all up after it lands
[11:09] <robru> Thanks
[13:32] <Saviq> robru, oh, you strip <foo> from bileto comments? could we instead html-entity it?
[13:33] <Saviq> jibel, silo 51 is good for QA, britney complains about a regression (known flaky test), but that actually re-ran already, just the results were not updated for over an hour ;/
[13:34] <Saviq> there's a design ACK on it, too
[13:38] <Mirv> Saviq: it's now updated but there is remaining issue (unity8 not considered) which I believe I can fix
[13:38] <Saviq> Mirv, right, that's a leftover binary, was hoping that this would go away
[13:39] <Mirv> Saviq: it won't automatically, but it will now that I manually deleted the superseded sources from the PPA
[13:39] <Saviq> ah ctrl+r!
[13:39] <Saviq> Mirv, ack
[13:39] <Mirv> I ran into the same problem with my Qt PPA
[13:39] <Saviq> any case, jibel ↑ 051 ready for testing, despite britney being sloooooow
[13:40]  * Saviq worried looking at "ready for testing" queue :(
[13:43] <Mirv> Saviq: it took me ~2 weeks to get one of my silos into the queue when it was ready the whole time :) now the train is much more likely to get there with the automated signoff.
[13:43] <Mirv> yeah the queue is long, but priority silos will get priority treatment
[13:43] <Saviq> Mirv, well, I'm happy with the approach altogether, not so much with the overhead
[13:46] <Saviq> and the waiting, most of all
[14:22] <morphis> cjwatson: any idea why my silo packages in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-000/+packages waiting for publication since 20min?
[14:23] <cjwatson> morphis: 20 minutes isn't that long
[14:23] <morphis> really?
[14:23] <morphis> had it faster in mind
[14:23] <cjwatson> morphis: the cron job in question tries to run every five minutes and typically takes around ten, IIRC
[14:23] <sil2100> Sometimes it can take longer, depends on how busy the publishers are
[14:23] <morphis> ah I see
[14:23] <morphis> thanks!
[14:23] <cjwatson> morphis: so 20 minutes is in the normal worst-case ballpark
[14:24] <morphis> ok
[14:26] <dobey> hmm, i wonder how long it will take the valid candidates to get through proposed now and have the MPs merged
[14:27] <sil2100> dobey: the scopes-api bits?
[14:29] <sil2100> hmmm
[14:31] <cjwatson> dobey: hahaha.  multiple entwined transitions here
[14:31] <cjwatson> there's a big complicated openmpi transition that it's welded to, unfortunately
[14:32] <cjwatson> morphis: Possibly some networking problem on the PPA publisher, though, it's working but very slowly
[14:33] <morphis> cjwatson: wonderful :-)
[14:33] <dobey> sil2100, cjwatson: i wonder if i should force merge the scopes-api silo, so we can get other silos moving along again, then
[14:34] <cjwatson> dobey: possibly, although I'd recommend not actually trying to publish anything else to the relevant set of packages in order to avoid complicating this set of transitions even further
[14:36] <dobey> hmm
[14:40] <sil2100> cjwatson, dobey: I would opt for only force-merging this silo to unblock development, but as per cjwatson's recommendation not landing any other scope silos before this migrates
[14:41] <sil2100> I see a big list of uninstallable packages in the update_output, I'm worried it'll take some time for all the transitions to get resolved
[14:42] <cjwatson> sil2100: it's actually fairly close I think, update_output can be a bit misleading here because it excludes anything not a valid candidate
[14:43] <sil2100> A force-merge would at least allow building other silos
[14:43] <cjwatson> but it's certainly painful to analyse
[14:43] <sil2100> Yeah, looks scary
[14:43] <sil2100> ;)
[14:47] <sil2100> cjwatson: btw. do you know who I should poke about questions regarding mailing-list support in launchpad?
[14:50] <cjwatson> sil2100: I guess if I don't know then William is your most likely option
[14:51] <sil2100> wgrant: hey! I would need to create a semi read-only mailing list in Launchpad - either with posting requiring moderation or with some other approach
[14:52] <sil2100> wgrant: do you know if I could create something like that in LP?
[14:52] <wgrant> sil2100: LP mailing lists are rather inflexible, unfortunately. There are no facilities for anything like that.
[14:58] <sil2100> wgrant: hmm, ok, thanks
[15:27] <pstolowski> sil2100, hey, any idea what the above status of silo 65 means ^?
[15:27] <sil2100> hm, never saw it before, let me take a look
[15:31] <dobey> sil2100: i guess merging 37 might help here?
[15:32] <sil2100> Ah, let's merge that one indeed, I guess it should be ok
[15:34] <Saviq> Mirv, doesn't seem like that helped in silo 51
[15:34] <dobey> sil2100: i guess you need to do the merge/clean, since it claims i don't have job permission :)
[15:36] <morphis> cjwatson: some were moved but the important ones still sit there for close to two hours now
[15:38] <cjwatson> morphis: network issues, being worked on
[15:38] <morphis> ah ok
[15:53] <dobey> wow, http 412
[15:54] <dobey> well that confused the train
[16:00] <Mirv> Saviq: weird. sil2100 any other ideas with silo 51 excuses not considered? it was exactly what I explained to you that I resolved by removing superseded packages from the PPA.
[16:00] <Mirv> but for some mysterious reason it's not helping here
[16:13] <davmor2> sil2100: 926 could that be a priority for merging please morphis wantsssssssessss it the precioussssss </smegol_impression>
[16:14] <morphis> davmor2: :-)
[16:16] <sil2100> morphis: eeek! Approve teh branchezzz
[16:17] <sil2100> (review and approve)
[16:17] <morphis> tvoss, greyback__: can one of you approve the platform-api changes in https://requests.ci-train.ubuntu.com/#/ticket/926 ?
[16:20] <tvoss> morphis, done
[16:20] <morphis> sil2100: ^^
[16:24] <dobey> sil2100: hmm, i think you need to merge/clean silo 37 again perhaps?
[16:28] <sil2100> o/
[16:29] <sil2100> morphis: still one merge needs approval...
[16:29] <sil2100> brb in a minute
[16:30] <morphis> sil2100: done
[16:47] <morphis> cjwatson: any information available when the network problems will be solved?
[16:55] <dobey> oh bah
[16:55] <dobey> sil2100: hrmm, i got the ppa/bzr version mismatch error now too :(
[17:01] <cjwatson> morphis: well, we've been working with IS, but it looks like a DOS, so you know
[17:01] <morphis> cjwatson: perfect :-)
[17:02] <dobey> ick :-/
[17:02] <cjwatson> morphis: the publisher is definitely still chugging along, so it'll get there, it's just tough for it to download files from the librarian over its saturated link
[17:03] <morphis> I see
[18:17] <kgunn> trainguards ^ sorry, unfamiliar with that one?
[18:19] <kgunn> i do see a weird warning here
[18:19] <kgunn> https://launchpad.net/ubuntu/xenial/+source/mir
[18:19] <kgunn> "Mir 0.19.2 is older than the current packaged version. Launchpad may be missing release information for the 0.19 series or this package is linked to the wrong Mir series."
[18:20] <kgunn> oh...nvmd i think i know
[18:25] <cjwatson> morphis: all right, so this is an amusing self-DOS; the main libreoffice PPA has done on the order of 100GB outbound over the last hour, which has kind of flatlined everything else.  we think the best approach is to just wait for it to calm down
[18:26] <morphis> cjwatson: ohh
[18:26] <morphis> cjwatson: close to week so have to wait anyway :-)
[18:26] <cjwatson> yeah, I don't think it's worth trying anything more complicated last thing on a Friday
[18:41] <robru> So I guess most of the "ppa/bzr version mismatch" statuses are just due to ppas being slow to publish packages, should sort itself out
[18:58] <dobey> robru: ah, i guess slow to consume rather than publish. took forever for the uploads to show up for mine. then status was weird with "needs building" and had to do a diff_only rebuild to get it to look at the ppa again. now i just have to wait forever for the binaries to publish :-/
[18:59] <robru> dobey: uh, no? diff only just generates diffs. it doesn't "make it look at the ppa again". the train looks at the ppa every 15 minutes forever.
[18:59] <Trevinho> robru: what's that error?
[18:59] <Trevinho> ^
[18:59] <dobey> robru: oh; well then why did it say "needs building" instead of showing the built status?
[18:59] <Trevinho> (ppa/bzr version mismatch)
[19:00] <dobey> Trevinho: DDoS
[19:00] <robru> dobey: "needs building" is a ppa build status.
[19:00] <dobey> robru: yes; but why would it show that *while* it is building?
[19:00] <robru> dobey: "needs building" means "ppa has your source package but all the buildds are busy"
[19:00] <robru> dobey: if that was the status for one of the arches then that would be reported as the status for the entire build.
[19:01] <dobey> 75% were already built :)
[19:01] <dobey> oh
[19:02] <robru> dobey: train has priorities the list of possible ppa build states when it decides which ones to report. so eg "failed to build" is highest, if any arch is a failure then the whole thing is considered a failure. "needs building" is in that priority order higher than "currently building" and 'successfully built' so if 75% succeed and a couple are still
[19:02] <robru> building and one is "needs building", the whole thing is reported as needs building.
[19:02] <robru> dobey: the idea is that a failure needs to be reported asap but a success isn't a success until all arches succeed
[19:03] <robru> Trevinho: ppas are slow to publish packages, it means it's looking at a ppa and it's not seeing the package it just uploaded there. it's just slow, it'll fix itself
[19:03] <Trevinho> robru: fine, thanks :)
[19:05] <robru> yw
[19:09] <kgunn> trainguards ok back to being stumped ^
[19:09] <kgunn> the ppa/bzr version mismatch thing
[19:09] <robru> bruh
[19:16] <kgunn> robru: is that a bruh like "you should know better" or a bruh like "tell me about it" ?
[19:16] <kgunn> :)
[19:16] <dobey> bruh, read the room ;)
[19:17] <robru> kgunn: it's like "bruh we were just talking about that"
[19:17] <kgunn> oh my bad
[19:17] <robru> kgunn: "bruh I'm writing documentation because I don't want to explain this a third time in 20 minutes"
[19:17]  * kgunn recedes with tail between legs
[19:18] <dobey> robru: we can start an office pool on whether it will take 20 minutes for another complaint about that status ;)
[19:18] <dobey> robru: or maybe just change that status to "Waiting for uploaded source to appear in PPA (foo/series)
[19:22] <robru> dobey: yeah I dunno, because the same message could also appear if it fails to push the bzr branch.
[19:22] <robru> dobey: the point is that it's comparing the remote bzr branch to the remote ppa and the versions don't match. it doesn't really have a way of knowing which one is wrong.
[19:28] <robru> dobey: kgunn: Trevinho: https://wiki.ubuntu.com/citrain/LandingProcess#PPA.2BAC8-bzr_version_mismatch
[19:30] <dobey> now you just need a scripted reply of "see the topic" whenever someone asks about it ;)
[19:31] <robru> heh
[20:01] <Saviq> robru, hey, any idea how to convince britney to consider unity8 here https://requests.ci-train.ubuntu.com/#/ticket/938? it's complaining about a package from a previous build (that was removed by now)
[20:01] <Saviq> or jibel, did you have a look to force that into QA-ready ↑?
[20:10] <dobey> Saviq: launchpad publishing is very slow today, so it might catch up after the binary publish finishes
[20:10] <dobey> oh, but looks like it has finished
[20:13] <robru> dobey: Saviq I dunno, that britney run is from nearly an hour ago...
[20:14] <dobey> could be the same network saturation causing problems though
[20:14] <robru> Saviq: how long has it been since the packages were deleted?
[20:14] <Mirv> robru: it's not the britney run delay. I deleted the packages 5h ago...
[20:14] <robru> oh, that's a lot
[20:15] <dobey> it's been like 1.5 hrs waiting for binaries to publish in my silo
[20:15] <Mirv> dobey: oh... well that's abnormal
[20:15] <robru> i dunno man
[20:16] <dobey> Mirv: yeah. apparently this is what happens when the network gets saturated and the publisher can't publish things, though :)
[20:17] <robru> dobey: "can't publish" also including "can't delete"?
[20:18] <dobey> robru: i would presume so, yes
[20:18] <robru> hm
[20:19] <dobey> but it really shouldn't matter if old binaries are around, if the new ones are there
[20:25] <Mirv> it does in train britney currently if binary package is removed in new version. the superseded source needs to be deleted manually
[20:26] <Mirv> happened to my qtbase and now Saviq's unity8 silo
[20:27] <robru> dobey: yeah I'm not sure why britney is looking at superceded sources. I guess it's some difference in how ppa package indexes look compared to -proposed (like I guess -proposed doesn't keep those in the indexes and ppas do)
[20:34] <dobey> oh, it removed binary packages from debian/control? ok, yeah that is a bit different too
[20:35] <cjwatson> dobey: not sure I'd describe it as a DDoS, though there's certainly a distributed element :)
[20:37] <cjwatson> Mirv: yeah, last completed run was on the order of five hours ago :-/
[21:01] <robru> cjwatson: all of the "ppa/bzr version mismatch" messages cleared up though, implying that packages got published in ppas?
[21:02] <cjwatson> robru: it's making gradual progress, but it's still very gradual
[21:02] <robru> ah
[21:02] <cjwatson> running at a couple of percent of the usual speed
[21:02] <dobey> robru: i think finding the source uploads is a different process from publishing binaries?
[21:03] <cjwatson> it's the same publisher, it just depends on how much is available to publish
[21:03] <cjwatson> I mean even pretty much the same bit of the publisher
[21:03] <dobey> oh
[21:04] <cjwatson> accepting source/binaries is a different phase from publishing source/binaries; but the ppa/bzr business depends on the source part of the latter
[21:04] <dobey> it's seemed like source uploads get picked up faster than binaries are getting published, so i presumed there was some relevant difference there
[21:11] <cjwatson> dobey: they'd get picked up for build earlier, assuming public PPAs
[21:11] <cjwatson> dobey: but I don't believe the train looks at that bit; ICBW
[21:12] <cjwatson> dobey: oh; no, I stand corrected, you're right; the train looks for either Pending or Published builds
[21:13] <cjwatson> s/builds/publications/
[21:13] <dobey> ah ok
[21:13] <cjwatson> both will still have been very slow since the whole process is serial
[22:04] <cjwatson> PPA publishing issues should hopefully improve very shortly
[22:37] <robru> Saviq: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html well this looks better, just needs somebody to retry that regression
[22:37] <Saviq> oh oh, mterry ↑↑ :D
[22:47] <alesage> robru question: any harm in landing the same MP twice?  I suppose it's just a vacuous merge?  seeing the same branch in 16 and 38
[22:48] <Saviq> sil2100, I'll trade you ↑↑ recycle https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html please? ;)
[22:49] <robru> alesage: depends what it is i think. When one silo lands the other will need to be rebuilt which may cause conflicts.
[22:49] <alesage> robru, ack
[22:49] <sil2100> o/
[22:49] <robru> alesage: i mean the silo needs to be rebuilt anyway so worst case you just remove the duplicate before the rebuild
[22:50] <Saviq> oh crap, just missed req1000
[22:50] <sil2100> Clickedy clicked
[22:50] <alesage> robru, ok will advise
[22:50] <Saviq> sil2100, https://requests.ci-train.ubuntu.com/#/ticket/1001
[22:50] <sil2100> Saviq: hah :)
[22:50] <sil2100> Thanks ;)
[22:50] <Saviq> jhodapp, congrats on request 1000! :D
[22:50] <sil2100> I still need to copy mir etc.
[22:51] <robru> Oh god we're already over 1000 tickets? You maniacs are burning through them so fast! Those numbers will overflow at 9 quintjiliion you know, stop wasting them!
[22:54] <sil2100> Let's start using letters
[22:54] <sil2100> AZ12BJ doesn't sound confusing at all
[22:55] <mterry> Saviq, still need that press?
[22:55] <robru> sil2100: after the postgres db overflows at 9223372036854775807 I'll switch it to UUIDs i guess
[22:56] <mterry> Saviq, looks like no
[22:56] <jhodapp> Saviq, ha!
[22:56] <Saviq> mterry, no, sil hooked me up, thanks
[22:56] <jhodapp> thanks :)
[22:56] <jhodapp> Saviq, what'd I win?
[22:56] <Saviq> robru, customer for you ↑
[22:58] <robru> What?
[22:59] <Saviq> robru, what did jhodapp win for grabbing req 1000
[22:59] <robru> Saviq: he wins one internet for the day
[23:00] <jhodapp> robru, one whole internet to myself!?
[23:00] <robru> jhodapp: you got it, buddy!
[23:00] <Saviq> robru, btw, did you even start thinking about git support in train? I started looking around citrain code to see how quickly this could be hacked in
[23:00] <Saviq> and it doesn't look bad
[23:01] <jhodapp> robru, thanks :)
[23:01] <sil2100> Saviq: ok, should be good to build
[23:01] <sil2100> The silo that is
[23:01] <robru> Saviq: yeah I've been thinking about it. There are some unanswered questions about how it will work. My top priority is getting ephemeral silos, then git after that
[23:01]  * sil2100 goes to sleep
[23:01] <sil2100> o/
[23:01] <Saviq> robru, can you remind me why http://code.launchpad.net/~ci-train-bot/ branches have the project name in them?
[23:02] <Saviq> I mean ~/$project/$project-$distro-$release-landing-$silo
[23:02] <Saviq> why the double $project?
[23:02] <robru> Saviq: they don't have the project name in them, they have the source package name in them. Ctrl+f for "gles" and you'll see the difference
[23:03] <Saviq> robru, right!
[23:05] <robru> Saviq: so you probably saw the Branch class, right? In theory it would be easy to write a sister class that implements the same api but wrapping git instead of bzr, but the thing is that isn't a class that gets instantiated, it's a mixin that gets inherited, so I'm not sure how to have a class conditionally inherit from a bzr or git class as needed. Will
[23:05] <robru> probably need to be split out into separate classes with some logic for choosing which one to use when.
[23:06] <robru> Saviq: also the lp api exposes different properties for bzr MPs as git MPs and i don't have a clear idea of what parts in the code would be affected by those differences. It's not fully contained inside Branch class.
[23:07] <Saviq> hum
[23:07] <Saviq> robru, ack, will try and have a look when I find some time
[23:08] <robru> Saviq: talk to barry also, he expressed some interest in working on that
[23:09] <Saviq> robru, ack
[23:52] <Saviq> robru, any idea what happened here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-046/+packages ?
[23:53] <Saviq> robru, it says it's waiting for unity-api >= 0.105, which is in the "emergency snapshot PPA" as added by sil
[23:53] <Saviq> same for UITK
[23:54] <Saviq> granted, the qtmultimedia missing dep is valid, so the others might be red herrings
[23:54] <robru> Saviq: emergency snapshot ppa doesn't have anything to do with anything?
[23:54] <Saviq> robru, yes it does, sil modified that silo to have the snapshot ppa as dep, not overlay
[23:55] <robru> oh, well
[23:55] <robru> Saviq: like, just now? lp will retry depwaits every 1.5 hours or so
[23:55] <Saviq> robru, before I even started the build
[23:56] <Saviq> robru, even the build log says the ppa is added https://launchpadlibrarian.net/238313480/buildlog_ubuntu-vivid-amd64.unity8_8.11+15.04.20160212-0ubuntu1_BUILDING.txt.gz
[23:56] <Saviq> maybe they didn't publish yet, that snapshot is somewhat new
[23:57] <Saviq> robru, that's probably it, will likely resolve itself soon
[23:57] <robru> Saviq: yeah could be same old publisher issues.
[23:57] <robru> Saviq: i just retried one arch to see what happens, but yeah depwaits will be retried automatically so as long as you're sure all the deps are in the ppa it should be fine eventually
[23:58] <Saviq> robru, yup, tx