[12:15] <xnox> infinity: cjwatson: boost1.49 & 1.53 can be removed from the archive. See bug #1245005. Not sure what to do with unported projects. There are three easy fixes e.g. openwalnut/powerc binaries removal, blender & sflphone rebuilds in trusty-release without -proposed.
[12:15] <ubot2> Launchpad bug 1245005 in orthanc (Ubuntu) "Please remove boost1.49 & 1.53 from trusty-release" [Medium,Confirmed] https://launchpad.net/bugs/1245005
[12:17] <xnox> ember & orthanc are getting ported in debian/upstream - demote to proposed? (such that they can come back eventually, but remove boosts and cause them to go into dep-wait state or make them FTBFS in -proposed)
[12:44] <xnox> please reject kdeplasma-addons ^ it's actually for trusty....
[12:47] <cjohnston> lool: ping
[12:48] <cjohnston> I'm guessing your in Oakland so it's still early
[13:06] <stgraber> xnox: done
[13:28] <xnox> cjwatson: i have reverted ucommon back to gnutls2.6 with a one-liner patch. License-wise it seems to make sense to stay on the older gnutls.
[15:31] <xnox> please reject ^ ditto miss-upload.
[15:32]  * xnox upgrades devscripts
[15:33] <cjwatson> xnox: boost> probably best left to somebody not at a sprint and thus with an attention span longer than five minutes :-)  ucommon> thanks!  sipwitch> done
[15:34] <xnox> cjwatson: excellent. I've forwarded ucommon patch to debian with licensing reasoning....
[15:34] <stgraber> xnox: apparently someone beat me to the reject. Anyway, I was also about to suggest upgrading devscripts since I had that very issue happen to me a couple of times since we opened and I fixed it yesterday ;)
[15:35] <stgraber> someone still needs to teach lintian about trusty though, but that's a bit less of an issue
[15:37] <stgraber> lintian uploaded
[15:42] <lool> cjohnston: pong
[15:44] <cjohnston> lool: following up on my email about milestones and how to get it taken care of
[15:44] <lool> cjohnston: So I dont have a single person I can think of that has a stake on this; it's fuzzier
[15:44] <lool> cjohnston: If you need this now, just stick to your plan, if you want to gather more advice maybe mail ubuntu-devel@?
[15:45] <lool> cjohnston: alternatively, I was thinking we might want to discuss freezes and freeze dates at next vUDS
[15:45] <lool> but that's still some time away
[15:46] <cjohnston> right.. I'm going to need to delete the database to clear everything out of status if/when milestones are removed in order to fix status, so I'd rather get this done sooner rather than later.
[15:47] <cjohnston> freeze and freeze dates (unless they remain milestones) isn't hugely related...
[15:47] <lool> cjohnston: yeah; it just changes the meaning of the milestones a bit
[15:48] <lool> cjohnston: frankly, dont have much stake in this; just do the same as last cycle or what's simplest for you?
[15:48] <cjohnston> what we did last cycle would be great, and in the long run the simplest for me
[15:49] <cjohnston> lool: any idea who is able to remove the milestones from LP?
[15:49] <lool> probably folks here
[15:50] <cjwatson> huh, which milestones?
[15:50] <cjwatson> we deliberately added the freezes on request from the community
[15:51] <cjohnston> cjwatson: the freezes screw up status.ubuntu.com, which is why they were removed last cycle at the request of quite a few engineering managers and leads
[15:51] <cjwatson> uh, nobody told me
[15:51] <cjwatson> I think status.u.c should be fixed rather than screwing up community flavours
[15:52] <cjohnston> cjwatson: noone was willing to give developer time to fix it
[15:52] <xnox> cjohnston: make status ignore milestones which are not ubuntu-DD.DD, or move approximate to the closest one if/where needed.
[15:53] <xnox> cjohnston: community flavours care most to target bugs to milestones, rather than using status.u.c
[15:54] <cjwatson> I'm not really willing to break community flavours because of a code problem that doesn't honestly sound that hard to deal with
[15:54] <cjwatson> the monthly milestones were always something that only really Canonical cared about
[15:55] <ScottK> Please don't.  The milestones are working for us and s.u.c is irrelevant for Kubuntu.
[15:55] <ScottK> Yeah, those we don't need.
[15:55] <ScottK> I don't know of any other flavors are using s.u.c. though.
[18:12] <xnox> this is alsa-plugins split into universe package ^
[19:30] <rtg> infinity, we've got linux 3.12 and the important dkms packages staged in the c-k-t trusty pocket. would you have a look and copy those packages to -proposed ?
[19:38] <infinity> rtg: I can have a look later today, yeah.
[19:47] <xnox> I'm confused why britney eventually doesn't transition ucommon and I'm not sure what I can do for all of those tangled up packages to transition into -release pocket.
[19:50] <infinity> xnox: update_output seems pretty clear on the matter.
[19:53] <xnox> infinity: sipwitch building uninstallable sipwitch? but it is installable in up to date trusty-proposed chroot.
[19:54] <infinity> I'm poking it here.
[20:00] <infinity>  libexosip2-7 : Depends: libosip2-7 but it is not going to be installed
[20:00] <infinity>  liblinphone4 : Depends: libosip2-7 but it is not going to be installed
[20:00] <infinity>  siproxd : Depends: libosip2-7 but it is not going to be installed
[20:00] <infinity> xnox: ^-- I see at least those that need a transition.
[20:13] <xnox> ScottK: can you please undelete and reupload all the removed packages from sync that were reverse-depends off ucommon?
[20:14] <xnox> ScottK: i have patched ucommon in ubuntu to be using back gnutls2.6, and i'm struggling to find all the packages that were "synced & deleted"
[20:14] <xnox> ScottK: autosync is not picking them up, manual syncing also fails, and I have been manually reuploading them so far.
[20:19] <xnox> cjwatson: does auto-sync produce a list of packages that are not considered for syncing, because they were previously deleted from the archive?
[20:22] <cjwatson> xnox: It mails me such things, or you can use "auto-sync --dry-run --new-only"
[20:23] <cjwatson> Also if you just need to get the very same binaries back (they don't need to be rebuilt), it's better to just copy them back in
[20:23] <cjwatson> auto-sync will only mention them if there are newer versions in Debian though
[20:23] <cjwatson> You could do some kind of search for deleted publications maybe
[20:23] <xnox> cjwatson: needs a rebuild, since the old binaries are potentially tainted with gnutls2.8
[20:24] <cjwatson> k
[20:24] <xnox> cjwatson: ./auto-sync --dry-run --new-only You are not an archive administrator for Ubuntu.  Exiting.
[20:24] <xnox> cjwatson: =)))) i daubt i'll get those permissions just like that ;-)
[20:24] <cjwatson> xnox: look at the script
[20:25] <cjwatson> In fact I'm just going to disable that check for dry-run
[20:25] <cjwatson> (done)
[20:37]  * xnox finds shinny emacs stuff that was fixed to work again ^ =)
[21:39]  * infinity looks up and wonders how a no-change rebuild could produce NEW binaries.
[21:40] <infinity> Oh, cause it was removed from the archive?  Silly.  Who perpetrated this madness?
[21:40]  * ogra_ wonders whats up with mir
[21:41] <ogra_> do we have any blocks in place atm ?
[21:41] <infinity> ogra_: No, it can't migrate because it breaks the archive.
[21:41] <ogra_> huh ?
[21:42] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
[21:42] <Laney> → ust → update_output
[21:42] <ogra_> yes
[21:42] <infinity>     * i386: ltt-bin, lttng-tools, python-autopilot-trace
[21:42] <ogra_> sigh
[21:42] <ogra_> ok, more days without touch images then
[21:43] <infinity> Surely, this can't take "days" to fix.
[21:43] <cjwatson> infinity: I already pointed doko at demote-to-proposed instead of removing binaries
[21:44] <cjwatson> I don't know if he did this one - it was an old pattern people tended to follow
[21:44] <cjwatson> (Reasonably enough when we had nothing else)
[21:45]  * cjwatson enables daily (non-touch) image builds
[21:45] <cjwatson> Hopefully that'll work now
[21:47] <ogra_> good luck
[21:48] <infinity> ogra_: So, that needs a new upstream release of autopilot from the autolandy people.
[21:48] <infinity> ogra_: I'll fix ltt-control, since it isn't under autolander control.
[21:49] <ogra_> infinity, which cant happen because AP 1.4 is seemingly a non backwards compatible rewrite
[21:49] <infinity> Failing to see how that relates.
[21:49] <ogra_> (in case it depends on 1.4)
[21:49] <infinity> The version in Ubuntu just needs a rebuild for an ABI transition.
[21:49] <ogra_> ah
[21:49] <ogra_> i thought you meant the new AP
[21:49] <infinity> I could do that in-archive and let them sort the pieces. :P
[21:50] <ogra_> i think cyphermox  wants to take a look at it
[21:50] <cyphermox> at what?
[21:50] <ogra_> mir
[21:51] <Laney> haha
[21:51] <cyphermox> well
[21:51] <ogra_> well, ust
[21:51] <ogra_> (or did i misunderstand you in /ci/eng)
[21:51] <ogra_> *-ci-eng)
[21:51] <cyphermox> yeah, it was just to get to the conclusion to what was blocking it
[21:52] <ogra_> ah, k
[21:52] <cyphermox> and it seems like it's ust, because of ltt-control
[21:53] <infinity> cyphermox: I'm fixing ltt-control right now.
[21:53] <cyphermox> iok
[21:53] <infinity> cyphermox: But autopilot also needs a rebuild because python-autopilot-trace has a direct dep on liblttng-ust0.
[21:54] <cyphermox> alright, I'll take care of that now
[21:54] <infinity> cyphermox: I can do that in the archive directly, or someone can push something through autolander land.
[21:54] <cyphermox> I'll poke it in autolander land
[21:54] <xnox> cjwatson: ScottK did that round, but it was during early saucy time, i think.
[21:54] <infinity> cyphermox: (Please verify that a rebuild actually gets the right new dep on liblttng-ust2 before uploading.
[21:54] <cyphermox> yes
[21:54] <cyphermox> infinity: what was wrong with ltt-control?
[21:55] <infinity> cyphermox: Same thing, needs a rebuild for the liblttng-ust SONAME bump.
[21:55] <cyphermox> k
[21:55] <infinity> cyphermox: Just testing right now that a rebuild works and doesn't need any porting/fixing.
[21:57] <infinity> Well, I would be if this conference wireless wasn't thwarting my attempts to be useful.
[21:57] <cyphermox> so how did you read that it was the problem from excuses output?
[21:58] <infinity> cyphermox: Experience, I suppose.  You look at the binaries it says become uninstallable, then look at things transitioning in the rdeps.  It would probably be helpful if we made britney print "would remove: foo1 bar2" in the try/fail stanza, so it was more discoverable.
[21:58] <infinity> cjwatson: ^-- I'm guessing that wouldn't be hard, since it clearly already has the information internally at that point?
[21:59] <infinity> s/rdeps/deps/
[22:00] <infinity> Brain not here today.
[22:01] <cyphermox> cjwatson: ^ I may take a stab at this tonight, after team dinner if you don't mind me bugging you some more about archive stuff tomorrow ;)
[22:02] <cyphermox> perhaps there's be a way to get that kind of information in advance before we try to land things
[22:02] <infinity> In what sense?
[22:03] <infinity> You don't want to be running britney before you land just to run it again after you land.  Seems like a complete waste of time.
[22:04] <xnox> infinity: can you please denew linphone =) such that i can keep digging into these mini-transitions rabbit-hole that boost keeps hitting.
[22:04] <cyphermox> infinity: not necessarily running britney, just getting the information about what packages get removed or whatnot
[22:05] <infinity> cyphermox: But it wasn't the mir upload that removed packages. :P
[22:05] <cyphermox> I know
[22:05] <infinity> cyphermox: So, you're talking about seeing the entire state of the archive, which is exactly what britney does.
[22:05]  * infinity shrugs.
[22:05] <cyphermox> but eventually there will be some such breakage from autolanding
[22:05] <xnox> cyphermox: not sure it will work. there is significan't delay between builds in the ppa and the archive (which moves on)
[22:05] <infinity> So, it's happening at the right place, and the right time.
[22:05] <xnox> infinity: i guess it's interesting / or useful to have britney instance running on -proposed + pre-landing ppa.
[22:06] <infinity> cyphermox: Such breakage from autolanding happens every two weeks then the libmir* ABIs break.  We deal.  We transition.
[22:06] <xnox> infinity: which doesn't migrate packages.
[22:06] <infinity> s/then the/when the/
[22:06] <cyphermox> infinity: mir is another story
[22:07] <infinity> xnox: I guess I'm not actually seeing an argument for it being useful.  The point of integration with the archive is proposed, that's when you want to know if it all fits together.  Knowing "in advance" is a lie, because it might not be true by the time you land it.
[22:07] <xnox> cyphermox: well but it's the same type of problem =) i was rebuilding some packages in the archive from "auto-landing" to get them to pick up boost abi transition and etc. There are a many transitions on-going with some at times affecting some things that land. Sometimes it's easy sailing by.
[22:08] <xnox> infinity: true. i know it will be a lie.
[22:08] <cyphermox> no, but you'll have a chance at fixing any issues that would be caused by any combinatin of the crap from the PPA before we sync it to proposed.
[22:08] <infinity> Okay, I need to find a mirror that updates less than archive.u.c... The wireless here is so crap that I keep crossing the mirror pulse horizon in the middle of apt-get update.
[22:08] <cyphermox> maybe this just isn't the right example, but it made me think that we should at least check that things are installable in general
[22:10] <xnox> cyphermox: sure, you can run a jenkins job / test that takes all of packages form ppa and does $ apt-get install, with later -proposed enabled. But that will never be a full story, as things might be held up non-the-less because of things unrelated what's in the ppa.
[22:10] <cyphermox> xnox: I know, but that's outside of my control
[22:10] <cjwatson> infinity,cyphermox: yeah, it does that for hint failures but I think maybe somebody decided it'd be too verbose for normal use; worth a try
[22:10] <cyphermox> there's always the risk that some other random upload breaks things in various ways
[22:11] <xnox> cyphermox: e.g. packages in the ppa are all up-to-date with latest ABIs across all libries at all, yet 100 packages in universe are not. No matter how much PPA is rebuild, it will be held up in -proposed until the rest of 100 package in universe are fixed.
[22:11] <xnox> (and are installable)
[22:11] <infinity> cyphermox: I dunno.  I think the upstream merger should be doing one thing and one thing well (upstream CI), and archive integration should be happening in the archive.
[22:11] <cjwatson> this is what I've been talking with didrocks about for the last hour :)
[22:11] <xnox> which is partially the case in the current hold up.
[22:11] <infinity> cyphermox: But meh.
[22:12] <cjwatson> (kind of, anyway)
[22:13] <cyphermox> infinity: maybe.
[22:13] <cyphermox> autopilot is good, but I think I might do a manual upload and then sync changelog in
[22:13] <infinity> cyphermox: Trying to second-guess archive integration will be wrong often enough that people will still be asking the same "why am I stuck in a transition?" questions.
[22:17] <infinity> Sonofa... ltt-control is FTBFS.
[22:18] <infinity> ust-consumer.c:620:2: error: too many arguments to function 'ustctl_get_next_subbuf'
[22:18] <infinity> Looks like it was an API change, not just ABI.
[22:20] <cyphermox> fun
[22:20] <infinity> cyphermox: Want to look at that too?   :P
[22:36] <cyphermox> heh
[22:36] <cyphermox> yeah, there was a patch in BTS
[22:38] <cyphermox> infinity: thanks
[22:38] <infinity> slangasek: Holy poop, it got signed?
[22:38] <slangasek> infinity: yep, and I didn't even have to go nuclear
[22:38] <infinity> slangasek: Time to update and start over!
[22:39] <slangasek> ayup
[22:41] <slangasek> which I guess should involve an update to shim 0.5, and packaging fixes to make sure we can start integrating fallback.efi
[23:00] <cyphermox> infinity: liblttng-ust2 has a file conflict with liblttng-ust0 too :)
[23:51] <infinity> cyphermox: And no packaging-level conflict?
[23:52] <infinity> Apparently not.  Oops.
[23:52] <cyphermox> no? why would there be that?
[23:52] <cyphermox> ;)