[00:09] <nacc> slangasek: and i just worked through all of the TIL from yakkety, i think i hit them all; will check again after that pile of syncs and merges gets sponsored
[06:43] <cyphermox> nacc: what's up?
[06:44] <pitti> nacc: I retried the armhf regressions
[07:02] <xnox> infinity, https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1593592
[08:27] <seb128> could somebody from the SRU team review the network-manager items in the xenial queue? they are waiting for a while and currently the LTS versions of those plugins don't work at all because we didn't update them to match the nm version
[08:27] <pitti> I'll have a look
[08:28] <seb128> pitti, hey, thanks!
[08:29] <seb128> pitti, how are you? still having a productive week?
[08:29] <seb128> pitti, did you watch the game yesterday evening?
[08:30] <pitti> seb128: hm, is that the correct bug actually? bug 1297849
[08:30] <pitti> I thought there was another one, with xenial tasks
[08:30] <pitti> seb128: yeah, we did watch it, but was rather boring..
[08:31] <pitti> ah, it should have referred to bug 1576726 as well
[08:31] <seb128> pitti, I don't know why Aron picked that one but it has SRU info&co
[08:31] <seb128> happyaron, ^
[08:32] <pitti> meh, I was missing that; this is awfully bad
[08:32]  * pitti goes ahead and updates the bugs
[08:32] <seb128> sorry, do you want me to reupload with another bug reference?
[08:33] <happyaron> yes..?
[08:34] <seb128> happyaron, see what pitti said
[08:34] <pitti> bugs updated
[08:34] <seb128> pitti, thanks
[08:36] <happyaron> k
[08:36] <xnox> cjwatson, infinity - W: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/us.ports.ubuntu.com_ubuntu-ports_dists_yakkety_InRelease
[08:36] <xnox> i think it's broken for the first 9h59m of the day
[08:37] <happyaron> was trying to use one report for all the 1.2.0 SRUs
[08:37] <xnox> Date: Fri, 17 Jun 2016  8:06:11 UTC
[08:37] <xnox> vs
[08:37] <xnox> Date: Fri, 17 Jun 2016 03:15:36 UTC
[08:37] <seb128> happyaron, right, but you used 1297849 for the openconnect one which is an older bug?
[08:38] <xnox> wgrant, ^^^^
[08:38] <seb128> pitti, thanks for the review
[08:38] <seb128> pitti, is there anything you want us to change/fix on the bugs/uploads?
[08:38] <pitti> seb128: nah, it's fine
[08:38]  * pitti reviews a couple of other things in the queue
[08:38] <seb128> k, sorry if there was an issue with the bugs
[08:38]  * seb128 hugs pitti
[08:39]  * pitti hugs seb128 back :)
[08:40] <sarnold> tvoss: looks like internal irc is dying..
[08:40] <sarnold> tvoss: does ps auxwZ show any security contexts for the processes involved?
[08:42] <tvoss> sarnold, checking
[08:43] <tvoss> sarnold, yup, most of them show 'unconfined'
[08:51] <Odd_Bloke> I see that a test rebuild of xenial is currently under way.  Can someone educate me (or point me to somewhere I can educate myself): why do we do test rebuilds, and why are we doing one now?
[08:51] <wgrant> xnox: LP has always done that. Has apt changed recently?
[08:52] <Laney> xnox: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
[08:52] <wgrant> Odd_Bloke: Test rebuilds are done periodically to ensure that packages are still buildable. In this case it's probably to test a gcc SRU.
[08:52] <Laney> perhaps this apt should be removed in the meantime
[08:52] <Laney> or uploaded with that change reverted
[08:52] <Laney> juliank: ^- thoughts?
[08:53] <wgrant> Odd_Bloke: There are usually a few done during a series' development to check that we don't release binaries that we can't fix later.
[08:54] <xnox> Odd_Bloke, because if the mega toolchain updates in xenial-proposed/updates? =) e.g. there is gcc point release, python point release, ruby point release, binutils updated....
[08:54] <xnox> and we are redoing a test rebuild with that new toolchain, which is aimed for xenial SRU
[08:55] <xnox> Odd_Bloke, there was a session about this, here at the Athens Core sprint =)
[09:10] <slangasek> nacc: php-defaults -> php-horde-{imp,ldap} looks to have passed; did you get someone to retry those, then?
[09:12] <GunnarHj> pitti: Hi Martin, wonder if you can take a look at bug #1592162 and the ubuntu-docs item in the xenial queue. There are several other bugs mentioned in the changelog, but I'd prefer not to create xenial tasks for those if possible, so the verification can be done at one place.
[09:29] <juliank> Laney: That only affects 1.3~exp2 in proposed AFAICT, so we can drop that from proposed for now
[09:30] <juliank> But does that really use proposed packages?
[09:30] <Laney> juliank: Right - I didn't know if you wanted the other fixes to go into yakkety, or not
[09:30] <Laney> buildds
[09:30] <Laney> sorry, got a call now, brb
[09:31] <juliank> I'm not sure how long it takes to fix this in libstdc++6, maybe we should revert it in the mean time for 1.3~exp3
[09:31] <xnox> wgrant, whilst it's valid to have " ", "0", "1", "2". however currently in yakkety i cannot upgrade for 9h59m of UTC time.
[09:32] <xnox> wgrant, could you hack launchpad to start using leading "0" instead of leading " " despite, " " being valid?
[09:32] <xnox> juliank, 1.3~exp2 is on devac02 for me
[09:33] <xnox> juliank, it's in yakkety-proposed.
[09:33] <xnox> ... so affect all yakkety builds
[09:37] <wgrant> xnox: I'd really prefer that the apt regression be fixed rather than hacking around the regression in permanent LP code.
[09:37] <wgrant> (it's also faster to fix apt)
[10:07] <Laney> juliank: If it's okay with you I'll upload an apt with that commit reverted, and we can sync exp3 over that once it's available
[10:20] <cjwatson> wgrant: I think we probably should change LP, but not because of the apt regression (and I think we should get apt sorted out first), but rather because using %H rather than %k would match apt-ftparchive
[10:23] <rbasak> Do you have a pointer to the apt regression please? The new apt in proposed is causing the pdns mysql dep8 test to fail, but I haven't figured out if it's just due to non-determinism changing configure ordering or a bug in apt yet.
[10:24] <Laney> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1593583
[10:24] <rbasak> Thanks
[10:24] <rbasak> I guess that sounds unrelated.
[10:25] <Laney> Unless you're seeing messages about date parsing, I'd say so
[10:28] <wgrant> cjwatson: But being gratuitously different finds bugs in standard libraries!
[10:33] <cjwatson> wgrant: True, I guess.  I also happen to think the "maybe one space, maybe two" form is ugly though :)
[10:33] <wgrant> cjwatson: I can't disagree.
[10:44] <slangasek> @pilot in
[11:36]  * dholbach hugs mwhudson and slangasek 
[11:55] <GunnarHj> slangasek: Hi Steve, saw that you are piloting, and wonder if you can take a look at bug #1592162 and the related ubuntu-docs item in the xenial queue (already uploaded). The changelog includes several other bugs, but my wish is to concentrate the verification to the one I just mentioned, where it all is explained. Is that ok?
[12:09] <juliank> Laney: Fine with me, I ask DonKult if there's any gotcha, let's see what he says
[12:13] <Laney> juliank: It's uploaded - we can sync the next fix
[12:13] <Laney> (I presume this bug affects experimental too)
[12:22] <slangasek> GunnarHj: please remove the other bug references from the changelog in that case, because otherwise it becomes difficult to track / determine the verification status of the bugs
[12:23] <slangasek> GunnarHj: (so, this should be an upload without the bug references, and a reject of the one currently in queue)
[12:23] <GunnarHj> slangasek: Ok. Can you reject the current upload?
[12:25] <slangasek> GunnarHj: done
[12:26] <GunnarHj> slangasek: Thanks!
[13:43] <rbasak> nacc_: around? When you get a reconstruct now that we have the importer, do you just end up tagging a commit that the importer imported?
[13:45] <rbasak> nacc: also https://git.launchpad.net/~nacc/ubuntu/+source/sg3-utils/log/?h=merge&id=reconstruct/1.40-0ubuntu1 is interesting. It looks odd, but is correct.
[13:45] <rbasak> when you *tag* a reconstruct I mean.
[14:08] <seb128> @pilot in
[14:46] <slangasek> tkamppeter: hi, so I'm hitting EOD here at sprint, but I wanted to at least briefly update you regarding the lsb printing stuff
[14:47] <slangasek> tkamppeter: I'm having a hard time deciding on a path forward here, because I notice all of the openprinting.org LSB packages declare a dependency on the full LSB, not just on the printing module
[14:48] <slangasek> tkamppeter: and we *know* that we don't implement the full LSB, due to Qt, which is precisely why the LSB packages were being dropped from Debian
[14:49] <slangasek> tkamppeter: so, how much of the LSB do the openprinting packages actually need?  Could they be changed to declare that they only need core+printing?  Do they need more, and if so which pieces?
[14:56] <nacc_> rbasak: hey
[14:56] <nacc_> slangasek: yep, pitti hit them, thanks!
[14:56] <nacc_> cyphermox: i found some stray changes to debian/ that don't seem like delta we want to carry -- but wanted to double-check with you
[14:57] <nacc_> cyphermox: https://git.launchpad.net/~nacc/ubuntu/+source/sg3-utils/commit/?h=merge&id=a3e87b386e479e8160b71dc37909e011717e3226
[14:58] <nacc_> rbasak: that would only be the case if the original commit wasn't a merge
[15:05] <rbasak> nacc: I don't follow. What do you mean by original commit?
[15:06] <nacc> rbasak: `usd-merge reconstruct <commitish> <commitish>` takes each commit between the two cherry-picks them so they are linear
[15:07] <nacc> rbasak: so reconstruct is tree-identical to some tagged commit
[15:07] <rbasak> Oh, yes of course, sorry.
[15:07] <nacc> rbasak: (presuming our process and an imported version is the tip of the ubuntu/yakkety)
[15:07] <rbasak> So if there are merge commits, then the reconstruct will end up being not one of the imported ones.
[15:07] <rbasak> Got you, thanks.
[15:07] <nacc> rbasak: but it's not commit-identical, since we altered the parenting
[15:07] <nacc> rbasak: yeah
[15:08] <rbasak> I've got the beginnings of a cloner/linter BTW. It flags sg3-utils because "usd-merge tag ubuntu/(devel)" doesn't do what you did, because we're intentionally throwing away the latest sync :)
[15:08] <nacc> rbasak: and reconstruct does that check to ensure it's tree-identical to the original commit, as well
[15:08] <nacc> rbasak: yeah, i wondered about that :)
[15:09] <nacc> rbasak: and awesome to hear!
[15:16] <nacc> pitti: apologies, just filed LP: #1593768 so php-defaults won't break php-radius anymore
[15:18] <nacc> rbasak: also, sorry for bombarding you with MRs
[15:19] <nacc> rbasak: most are pretty trivial, i hope
[15:21] <rbasak> nacc: it's fine. That's prompted me to write the tool. Might as well write the script then run it six times or whatever :)
[15:21] <nacc> rbasak: :) i almost wrote it myself when i was submitting it `usd-merge review` or whatever, that just did the sanity checks
[15:22] <nacc> rbasak: i mean it couldn't necessarily verify the only change to control is metadata or changelog is ubuntu versions, but it can verify the only changes are to both, for instance
[15:23] <rbasak> nacc: I might commit my script to wip/review or something in git master or something, so everyone can make use of it early. It's hacky and has copy and pasting involved etc but it seems better to me to do it this way than have it in a separate branch. Sound oK?
[15:23] <nacc> rbasak: totally fine with me!
[15:25] <rbasak> nacc: https://git.launchpad.net/~nacc/ubuntu/+source/sg3-utils/commit/?h=merge&id=0785667f26f3901c65e62f378adba0d89ecb2dff has only upstream changes. I didn't think that would be in logical at all?
[15:28] <nacc> rbasak: a good point -- it was part of the old delta (in that it was part of the tree in that version) because upstream was cherry-picked down ahead of Debian (from Debian git)
[15:29] <nacc> rbasak: i guess i could have dropped it from reconstruct in logical, is that what you mean?
[15:29] <rbasak> nacc: right
[15:29] <nacc> rbasak: i did end up dropping it in the rebase, since Debian moved past the same upstream
[15:29] <nacc> rbasak: you're right; i tend to keep logical/ complete for some reason, but i should have trimmed it down to ... logical ... changes
[15:29] <rbasak> nacc: I think it is semantically part of reconstruct and deconstruct, but not logical.
[15:29] <rbasak> :-)
[15:30] <nacc> rbasak: yep, I just always worry about losing track of bits of delta in the rebase to new/debian; so i find it easier to drop there (not trusting myself to have decided what was or wasn't logically part of the delta)
[15:30] <nacc> rbasak: i guess i know better now, but i didn't before :)
[15:31] <rbasak> When we can lint logical that should be easier. Then you'll be able to trust that logical is correct more easily.
[15:31] <nacc> rbasak: yep, agreed
[15:31] <nacc> rbasak: want me to fix-up and send a new MR? or since you're mid-review, i guess you've got a handle on it?
[15:32] <nacc> rbasak: ah i remember why
[15:32] <nacc> rbasak: acc'g to our workflow, logical/ is supposed to match old/ubuntu exactly except for changelog and metadata
[15:32] <rbasak> No need to fix this up. It doesn't impede my review at all, just a little surprising from the process perspective.
[15:32] <nacc> rbasak: we might have changed that, but i thik that was my sanity check
[15:32] <rbasak> Sorry, I've probably forgotten about my addendum because a new upstream is an edge case. Changes not to debian/ for 3.0 (quilt) packages are fine to ignore too.
[15:33] <nacc> rbasak: yep, that makes sense -- we have a better definition of the 'logical' now, i think
[15:34] <nacc> rbasak: i'll work today on fleshing out the public wiki page, and maybe we can clarify that there
[15:34] <nacc> dholbach: jgrimm mentioned to me that you might be antoher good person to pull into our git-based workflow
[15:35] <dholbach> nacc, I'm not sure - how can I help?
[15:35] <nacc> dholbach: oh no help needed, more of an fyi: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
[15:35] <dholbach> ah yes, I saw the edits of the page
[15:35] <nacc> dholbach: might be a nice piece to have for new community members
[15:35] <dholbach> yes it is
[15:35] <nacc> dholbach: who do know git, but don't know packaging as well
[15:36] <dholbach> maybe we could have a discussion about it on ubuntu-devel@ about it?
[15:36] <dholbach> if we want to make it the default
[15:36] <dholbach> and update our docs accordingly
[15:36] <dholbach> I know packaging.u.c is still referring to bzr-lp
[15:36] <rbasak> I don't think we're quite ready for that yet - the importer is only run by nacc (or theoretically by me though I haven't done it yet) on demand.
[15:37] <nacc> dholbach: yeah it's probably not ready for prime-time yet :)
[15:37] <nacc> dholbach: but eventually :)
[15:37] <dholbach> it might be good to discuss it already
[15:37] <nacc> dholbach: my plan was to keep fleshing out that wiki page and then send it ubuntu-devel
[15:37] <rbasak> We should probably get to the stage before we are running it automatically before we recommend it for general use.
[15:37] <dholbach> to see what kind of feedback people have
[15:37] <dholbach> nacc, nice!
[15:37] <dholbach> good work!
[15:37] <rbasak> dholbach: discuss it already> certainly
[15:37] <dholbach> <3
[15:37] <nacc> dholbach: we also want to work on the side rbasak has been working on, which is more of the review of merges/development all in git
[15:37] <dholbach> ok
[15:37] <dholbach> I haven't used git-lp yet O:-)
[15:38] <nacc> dholbach: just wanted to get it on your radar, thanks!
[15:38] <dholbach> thank YOU :)
[15:49] <cjwatson> nacc: I don't suppose I can persuade any of you folks to work on bits of the LP side of this?
[15:50] <rbasak> cjwatson: what's the roadmap for the LP side of this, OOI?
[15:50] <cjwatson> rbasak: enotime
[15:50] <cjwatson> rbasak: or do you mean what are the items on it?
[15:51] <rbasak> cjwatson: no, I mean if you did have time, what work needs doing?
[15:51] <rbasak> Right :)
[15:51] <cjwatson> rbasak: can you see https://trello.com/c/KPGdVNXf/275-add-dgit-support-to-launchpad ?
[15:51] <cjwatson> oh wait, that doesn't have the checklist
[15:51] <nacc> cjwatson: i'd be happy to at least try and help!
[15:52] <rbasak> FWIW, I don't think I have a suitable Trello account
[15:52] <cjwatson> rbasak,nacc: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html is still basically right
[15:52] <cjwatson> modulo dgit-specific stuff, although I do think that if you could make your stuff dgit-compatible or even using dgit then that would be great
[15:53] <rbasak> I still need to study dgit again. In fact, as it's a Friday afternoon, I might do that now.
[15:53] <nacc> cjwatson: yeah, i jokingly suggested renaming to ugit as a move towards combining them :)
[15:54] <rbasak> Certainly the last four items of that list coincide with our goals I think.
[15:54] <nacc> rbasak: agreed
[15:54] <cjwatson> rbasak,nacc: http://paste.ubuntu.com/17435877/ is my work-in-progress patch to dgit to use the LP API
[15:54] <cjwatson> I think your importer would plug in well provided that it constructs compatible trees
[15:54] <cjwatson> might well be worth talking with Ian about it
[15:55] <rbasak> Is there a public dgit tree somewhere I can poke at?
[15:55] <rbasak> Or do I need to use dgit to clone one?
[15:55] <cjwatson> git://anonscm.debian.org/dgit-repos/repos/dgit.git
[15:56] <rbasak> http://anonscm.debian.org/cgit/dgit-repos/dgit.git - No repositories found
[15:56] <cjwatson> is that right?  I think so
[15:56] <rbasak> But I don't mean a tree for dgit itself
[15:56] <cjwatson> oh I see
[15:56] <rbasak> I mean a tree that is what a package looks like when fetched with dgit
[15:56] <rbasak> Aha
[15:56] <rbasak> https://browse.dgit.debian.org/
[15:57] <cjwatson> ah well done, I was just looking for that
[15:58] <cjwatson> also dgit(1) and dgit(7) describe some of it
[15:59] <cjwatson> anyway, the next big thing on the LP list is to hook archive upload permissions up to permission to push to lp:ubuntu/+source/thing
[15:59] <rbasak> That's "* Archive-permission-based ACLs for target-default package repositories" I think?
[16:00] <cjwatson> that's a very well-bounded task that somebody could take on and would learn a bit about how the LP git code works while they're there
[16:00] <cjwatson> yep
[16:00] <cjwatson> it's probably about two weeks for a complete LP newbie provided they have prior Python experience
[16:00] <cjwatson> maybe a week
[16:01] <cjwatson> and I can mentor
[16:01] <rbasak> I'd enjoy that I think. So would nacc probably.
[16:01] <rbasak> We need to discuss our priorities I think though.
[16:02] <cjwatson> Yep.
[16:02] <rbasak> And who'd want to turn down the opportunity of being mentored by cjwatson :-)
[16:02] <cjwatson> Heh ;-)
[16:03] <seb128> shrug at the sponsoring queue
[16:03] <seb128> Laney, there is a stack of "appstream icon for ..." bugs with only images attached and no details, no diff, nothing
[16:04] <seb128> is that a result of one of our call for appstream improvements?
[16:04] <Laney> yes
[16:04] <seb128> should we just unsubscribe sponsors since those are not really in sponsoring state
[16:04] <seb128> like no explanation nor diff
[16:04] <seb128> they sit there since march
[16:04] <Laney> they take a bit of work to sponsor
[16:05] <nacc> rbasak: cjwatson: sorry got distracted by something else; agreed, this sounds like a good intersection point!
[16:05] <Laney> since the problem often is not that the icon is missing
[16:05] <Laney> it's sometimes random other issues
[16:05] <seb128> it feels like those bugs don't have enough data that anyone feels like sponsoring
[16:06] <seb128> also I don't think many of us feel qualified at deciding if a random icon should represent a program
[16:06] <seb128> should be an upstream decision
[16:07] <rbasak> """If  you  are  a  quilt  user you need to know that dgit's git trees are
[16:07] <rbasak>        `patches applied  packaging  branches'  and  do  not  contain  the  .pc
[16:07] <rbasak>        directory (which is used by quilt to record which patches are applied)."""
[16:07] <slangasek> @pilot out
[16:07] <rbasak> I'm not very keen on that.
[16:07] <rbasak> Who made the call for contributions? That person presumably has some expectation over how to handle sponsorship?
[16:09] <cjwatson> rbasak: Ah, now, that's one of the reasons I specifically like dgit :-)  For maintenance purposes I think it has to be paired with something like git-dpm.
[16:09] <Laney> seb128: The icons being "random" wasn't really the problem that I encountered
[16:09] <cjwatson> I don't think I would be interested in using something that wasn't compatible with git-dpm.
[16:09] <Laney> If you don't think they are useful then by all means get rid of them
[16:09] <Laney> The alternative is to actually figure it out on a case by case basis
[16:09] <seb128> Laney, well, I picked https://bugs.launchpad.net/ubuntu/+source/jedit/+bug/1558671 and I don't understand what the request is about
[16:09] <rbasak> I considered handling quilt out-of-scope for my initial merge workflow. Using commits with quilt fully popped doesn't seem to have impeded this at all.
[16:10] <seb128> Laney, there is just a .svg attached to the bug and no debdiff nor package changes
[16:10] <rbasak> I understand how git-dpm is a big improvement for someone using git to actually maintain a quilt patchset.
[16:10] <Laney> seb128: Ship it in the hicolor scalable directory
[16:10] <Laney> There were mails about this to devel-announce and devel
[16:10] <rbasak> It might be tricky to find a clean way to integrate this all though.
[16:11] <seb128> Laney, right, but I don't even know the icon license nor if upstream would be happy to have that icon representing their program
[16:11] <Laney> Fine
[16:11] <seb128> Laney, thanks
[16:11] <Laney> You don't have to look at it
[16:11] <Laney> just get rid of them
[16:11] <seb128> no, it's fine
[16:11] <seb128> it's just that sit in the queue since march
[16:11] <seb128> but I'm going to do like the others and let them here
[16:12] <seb128> somebody eventual can pick them
[16:12] <seb128> eventually
[16:13] <Laney> I doubt that anybody except me ever will
[16:13] <Laney> This stuff needs to get less bus factory
[16:14] <Laney> but I'll try to deal with some of them next shift
[16:16] <seb128> thanks
[16:16] <seb128> the issue there is also that most people don't know about appstream
[16:16] <seb128> I know email were sent, I read them but the details didn't stick
[16:17] <seb128> and those bugs are not actable without investment to figure out how things work, what should be done exactly etc
[16:17] <seb128> they are a bit poor form for sponsoring requests
[16:17] <seb128> like the contributors let us the work to figure out the details and do the packaging and testing
[16:20] <Laney> http://article.gmane.org/gmane.linux.ubuntu.devel/39405
[16:22] <seb128> I guess it would help to put that url in the bugs description ;-)
[16:22] <seb128> but yeah I remember
[16:23] <seb128> well, for some reason they are not being picked up -:/
[16:23] <seb128> but sponsoring activity seems a bit low recently as well
[16:23] <seb128> oh well
[16:23]  * seb128 sponsors a few more items to help getting the queue lower than 110
[16:27] <rbasak> slangasek: re bug 1593768, sorry, I was "syncpackage: Please wait for the sync to be successful before closing bugs."
[16:27] <rbasak> I'm never sure what to wait for exactly, BTW. Proposed accept email? Release pocket accept email?
[16:28] <rbasak> It'd be nice if syncpackage could tell LP the -b argument and have LP handle it like a changelog mention.
[16:30] <nacc> slangasek: thanks as always for the sponsorships!
[16:30] <seb128> @pilot out
[16:32] <cjwatson> rbasak: Yeah, that's bothered me for a while, since technically it should be Release accept but who wants to wait for that
[16:34] <cjwatson> Needs a bugs= parameter to Archive.copyPackage, I guess, and then propagate that all the way down the stack to close_bugs_for_sourcepackagerelease
[16:39] <tkamppeter> slangasek, the LSB printing packages from Epson are simply print filters in reality, no GUI no network backends, ... they should simply work with lsb-printing.
[16:43] <rbasak> cjwatson: glad you agree. Add it that enotime backlog :-P
[18:15] <nacc> can someone retrigger the tests for phpseclib -> php-horde-mapi (new version landed in yakkety)
[18:16] <nacc> also, php-random-compat -> php-symfony-polyfill (s390x) seems stuck. It says in progress, but I don't see it in the queue?
[18:17] <nacc> finally, the php-horde-support -> php-horde-group (ppc64el) failure seems to be a testbed failure, can it also be retried
[18:22] <nacc> woo, php-defaults finally transitioned out of excuses :)
[18:52] <nacc> hrm, same issue with php-horde-stream -> php-horde-mime (ppc6el) (test says in progress, but it's not in the queue?)
[18:53] <nacc> down to 73 mentions of php in excuses :)
[19:08] <rharper> shagu
[19:22] <nacc> rbasak: do we want to send the icinga2 delta to debian (mysql 5.7 related)
[19:22] <nacc> rbasak: i think if we did and they took it, we can sync icinga2 in yakkety