[00:54] <slangasek> bdmurray: remind me how update-manager determines which sources are third-party?  I just had it disable archive.ubuntu.com on an attempted upgrade to utopic
[01:30] <slangasek> bdmurray: hmmm possibly related to my /etc/update-manager/release-upgrades.d/local-mirrors.cfg no longer having the expected effect
[07:51] <tseliot> hi, can and admin reject xorg-server-lts-saucy from precise-proposed, please? (I forgot to include the previous release in the diff)
[08:01] <infinity> tseliot: Done.
[08:01] <tseliot> infinity: thanks
[12:42] <superm1> slangasek: currently http://cdimages.ubuntu.com/mythbuntu/precise/ appears to be building still daily, can you change it so that the LTS's that build daily will be the trusty LTS instead at this point?
[12:43] <cjwatson> We haven't started any trusty LTS builds yet
[12:44] <cjwatson> I was planning to do that after the livefs infrastructure changes are done
[12:58] <ScottK> Do CI train packages somehow skip binary New?  qtdeclarative-opensource-src grew a new binary in the last upload and I don't see where it hit new.
[13:27] <xnox> cjwatson: well, can we spin up mythubuntu trusty daily? mythbuntu have fixes in -updates that unbreak mythubuntu ubiqyity plugins.
[13:28] <xnox> (e.g. to prevent installer from crashing if one chooses vnc option)
[13:28] <infinity> ScottK: All copies skip binary NEW, it's a longstanding bug.
[13:29] <ScottK> Sigh.
[13:30] <infinity> Well, s/bug/misfeature/ ... It's not trivial to fix, but it's on the TODO.
[13:30] <ScottK> So CI train is both a backdoor for non-developers to upload and gets less scrutiny.
[13:30] <infinity> Pretty much means completely rewriting what a copy is.
[13:30] <ogra_> could some archive admin let golang-udm out of NEW ?
[13:32] <ScottK> infinity: that or deciding copy from CI train isn't the right way.
[13:32] <infinity> ScottK: All copies have this particular problem, and we're not going to stop using them entirely, so it's a bug that needs fixing.
[13:32] <ScottK> AFAICT source only copy and rebuild would make it hit new.
[13:32] <infinity> Yes, it would.
[13:33] <infinity> But it would also invalidate to some extent the binary testing that was done, as well as being a waste of resources.
[13:34] <ScottK> The tests get rerun anyway for migration from proposed don't they?
[13:34] <infinity> Different testing.  Which is, indeed, also a problem IMO.
[13:34] <infinity> All the testing they do should be done at the -proposed stage, not before.
[13:35] <ScottK> I agree it would cost some additional resources, but I don't think it would be a waste.
[13:42] <infinity> ScottK: So, I'm curious what the deep concern here is in this case.  I assume the package rename was warranted.
[13:42] <infinity> ScottK: The broken one only existed in utopic, so the earlier it's fixed, the sooner they can drop the transitional one and pretend like it never happened.
[13:43] <infinity> (or just P/C/R it out of existence, which is probably smarter than a transitional)
[13:44] <infinity> ScottK: Your review didn't raise any technical arguments for why it was bad, just that it should wait to be less of a hassle.
[13:44] <ScottK> Given new gets skipped, it doesn't matter.
[13:44] <jamespage> bdmurray, picked up a new ceph bug whilst testing proposed yesterday/today - its not technically a regression compared to release - bug 1322498
[13:44] <ScottK> I mostly don't appreciate being ignored.
[13:45] <jamespage> bdmurray, I have a tested fix but wanted to check whether I should let bug 1278466 release first or stack it ontop of the existing proposed package
[13:46] <ScottK> If comments from people who aren't on their team are going to be ignored, let's quit pretending there's community involvement.
[13:47] <ScottK> If someone had said CI train uploads skip new so it doesn't matter then I'd have said go for it.
[13:48] <infinity> ScottK: It landed in the distro 5 hours BEFORE your review.  I'm not sure what responsiveness you were hoping for.
[13:48] <infinity> 6 hours, even.
[13:50] <ScottK> infinity: OK.  Then that's a different bug.
[13:50] <ScottK> I've NFC why it's even sent out for review.
[13:51] <ScottK> Thanks for pointing that out.
[13:52] <infinity> I suspect it's a bit of a disconnect between CI train reusing LP MPs for its own test-and-approve process (probably a good thing, component reuse, for the win) and the fact that that's also spamming real people who subscribe to those packages. :/
[13:53] <infinity> Though I *am* curious what the CI stuff does if a real person registers a negative review before the bot returns a positive one.
[13:53] <infinity> Cause that should probably halt it.
[13:54] <Laney> It doesn't check the reviews or status at all AIUI
[13:54] <infinity> Laney: Yeah, that would seem to me to be a problem.  A bot-driven MP like this should still allow humans to play along.
[13:55] <ScottK> Also if it's automatically copied,  the MP get automatically merged so people don't review stale proposals.
[13:55] <infinity> (Obviously not in this case, where Scott was 6h too late, but let's assume he got a review in before someone hit the big red publish button, that button should tell them "hey, a human had an issue on this MP, dude")
[13:55] <ScottK> Yep.
[13:56] <ScottK> But in this case something should have marked it merged when it was copied.
[13:56] <ScottK> Then I wouldn't have reviewed a stale proposal.
[13:57] <Laney> Hrm
[13:57] <Laney> Was this a source package upload through the train?
[13:57] <ogra_> if it was the train you should file a bug ...
[13:57] <infinity> Laney: https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_fixpkgname/+merge/220601
[13:57] <infinity> It was that.  Whatever that means.  Looks trainy.
[13:57] <Laney> infinity: I see it
[13:58] <Laney> Train can handle human uploads to its PPAs too
[13:58] <Laney> but I think you lose any merging-back if you do that
[13:58] <ogra_> yeah
[14:02] <sil2100> When direct uploads are being made and handled by the CI train, no bzr merges are made by the infrastructure
[14:02] <Laney> I think if I was going to upload it then I'd have just pushed the branch instead of creating a merge proposal
[14:02] <ogra_> then you make robru jobless :P
[14:03] <ogra_> i guess he was the one who merged it and drove it through the train
[14:03] <ogra_> (guessing by the landing time)
[14:04] <xnox> ScottK: branch merges happen at -proposed -> release copy stage, not during ppa -> proposed copy.
[14:04] <Laney> ogra_: https://ci-train.ubuntu.com/job/landing-016-2-publish/22/
[14:05] <ScottK> xnox: Why? Anyone I know that manages branches directly tags it when it's uploaded.
[14:05] <ogra_> ah, so Timo himself
[14:06] <ogra_> ScottK, and if the merge expoxes massive errors during autopkgtest ?
[14:06] <xnox> ScottK: during ppa -> -proposed, there is a separate branch available owned by bot.
[14:06] <ScottK> Yet another misfeature.
[14:07] <ogra_> you really dont want it to land in trunk before it passed testing
[14:07] <xnox> ScottK: the idea is that, when things were getting stuck in -proposed -> -release migration, the trunk would move on, without migrating previous release... or something.
[14:09] <xnox> ogra_: testing is meant to be complete by that time (ppa -> -proposed copy)
[14:10] <ogra_> xnox, why do we have proposed->archive then ?
[14:10] <xnox> ogra_: that's britney migration.
[14:10] <xnox> and ADT.
[14:10] <ogra_> testing the package itself is done by that time ... that doesnt mean it plays nicely with the archive
[14:10] <xnox> either manual testing needs to move during proposed->archive stage.
[14:10] <ogra_> or its rdeps
[14:10] <xnox> (e.g. open a blocking bug)
[14:11] <ScottK> ogra: It's already in the archive so what's the point of not making the cvs catch up.
[14:12] <ogra_> ScottK, if issues are found in proposed so that the package gets dropped your branch will be out of sync
[14:12] <ScottK> xnox: In this case it's a packaging branch so trunk moves on isn't relevant.
[14:12] <ogra_> (note that i dont work on CI i'm just a consumer myself)
[14:13] <ogra_> but i think it is logical to wait with merging till *all* testing is done ...
[14:14] <ScottK> ogra: Once it's in the archive it's part of the history of the package.  Not merging and pretending it never happened is just modifying history to ignore what actually happened.
[14:14] <ogra_> but it isnt in the archive until britney lets it
[14:14] <infinity> ogra_: Yes it is.
[14:15] <infinity> ogra_: It's been uploaded to the archive, release pocket is irrelevant to packaging history.
[14:15] <ogra_> we had removals from -proposed in the past, didnt we ?
[14:15] <infinity> On rare occasions, that doesn't mean the upload never existed.
[14:16] <infinity> The right way forward is always forward, even if that's a full revert of the code and a new changelog entry saying "revert the last upload".
[14:16] <ogra_> you shoudl probably involve some train developer/admin in this discussion  ;)
[14:16] <infinity> You still want your VCS to reflect that, maybe someone wants to see what was reverted and why.
[14:17] <infinity> So someone else doesn't try the same broken thing two days later. :P
[14:17] <ogra_> i'm sure there is a reason didrocks picked this way to workflow
[14:17] <ogra_> s/to/of/
[14:18] <ogra_> if it couldnt be merged due to being dropped from proposed the MP histrory will reflect that
[14:18] <infinity> MP history isn't VCS history.
[14:18] <ogra_> admittedly the changelog perhaps wont
[14:18] <infinity> Nor is it package history.
[14:18] <ogra_> depending on the developer and how he works with changelogs
[14:19] <infinity> But I think I'm going to take my sick butt back to bed instead. :P
[14:19] <ogra_> yeah, get better so we can meet next week :)
[14:23] <rcj> arges, Would you have time this morning to look at bug #1275656?
[14:31] <cjwatson> It does actually get committed to revision control when it hits -proposed, just to a different branch
[14:31] <cjwatson> I made the same initial objection but having it on a different branch actually does seem kind of sensible
[14:32] <cjwatson> Or at least defensible
[14:32] <arges> rcj: i already did look at it and sponsored it. What changed?
[14:33] <cjwatson> xnox: I can have a look on Monday, I guess, but probably not today
[14:33] <rcj> arges, ah, the v3 patches from 5/21 are uploaded now?  How do I check these things so that I don't bother you?
[14:33] <arges> rcj: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=open-vm-tools I'll reject the older one
[14:34] <rcj> arges, thanks
[14:35] <arges> rcj: the other one is here https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=open-vm-tools
[14:35] <rcj> arges, Thank you.
[14:35] <arges> rcj: no problem
[14:36] <ScottK> cjwatson: I don't understand why.  Once it's in the archive, it's irreversibly there.  Not merging the branch just means the VCS and the archive are out of sync.
[14:38] <ogra_> as you can see above -proposed isnt irreversible
[14:38] <cjwatson> Well, I said defensible not that I necessarily agreed ...
[14:38] <cjwatson> I think this would make a lot more sense in git where you wouldn't have to dig out a separate URL
[14:39] <cjwatson> Then it'd be analogous to "master" and "next"
[14:39] <ScottK> ogra_: For the package history it is.
[15:30] <superm1> can someone axe the mythtv upload in trusty-proposed?  upstream decided to land some patches upstream that fix it more nicely that I would like to test instead
[15:58] <slangasek> superm1: done (the upload axe, not the cdimage change which I will defer to cjwatson on)
[15:58] <superm1> thanks
[15:59] <ogra_> slangasek, do you feel like reviewing another go package ... golang-udm is sitting in NEW since ~1 week now ... and we wannt to work on MMS stuff in malta next week
[15:59] <slangasek> ogra_: I had already reviewed it and spotted some issues that I needed to talk with sergiusens about, unfortunately since he's already in Malta it's been hard to catch him online
[16:00] <ogra_> ah, k
[16:00] <slangasek> I'm assuming you don't want me to do a straight review->reject, so... :)
[16:00] <ogra_> yeah, better not :)
[16:00] <slangasek> anyway, I will try to send an email to him today with my questions, but I guess for all intents and purposes nothing's going to progress on this until Monday now
[16:01] <ogra_> right ... and then you can do it in person anyway
[16:01] <ogra_> which will be faster
[16:01] <slangasek> (unless you want to discuss with me today why this one is using gc again after we sorted out nuntium using gccgo)
[16:02] <ogra_> no, i was just forwarding the request
[16:02]  * slangasek nods
[16:07] <didrocks> xnox: I think the answer to your question is "yes", but I wouldn't guess and let infinity answering
[16:42] <xnox> didrocks: sorry, i think i lost context =)
[16:43] <xnox> only question i had recently, was responded by colin....
[17:09] <ogra_> xnox, who cares about context as long as the answer is positive ;)
[21:37] <Logan_> why was libav rejected?
[21:46] <ScottK> Logan_: it FTBFS on two archs.
[21:46] <ScottK> Starting a transition on just some archs sucks.
[21:48] <Logan_> right, I figured - just making sure
[23:08] <xnox> Logan_: is anybody looking into fixing libav? or shall i take a look.
[23:10] <Logan_> the most I did in terms of looking into fixing it was triaging the appropriate bug for ppc64el :P
[23:10] <Logan_> I'm not sure whether to report the arm64 issue upstream or not
[23:11] <Logan_> xnox: but if you have any ideas on how to fix either, feel free to go ahead with patches
[23:12] <xnox> Logan_: ok, let me try.
[23:17] <infinity> xnox: I was going to look at it.
[23:17] <infinity> xnox: The simple fix is, well, simple.
[23:18] <Logan_> infinity: disabling altivec?
[23:19] <infinity> Logan_: altivec on ppc64el and neon on arm64, yeah.
[23:19] <Logan_> I see that as a stopgap tbh
[23:20] <infinity> As do I.  siretart and I chatted about this last night.
[23:21] <Logan_> would any collaboration with libav upstream help?
[23:21] <infinity> Just needs someone who knows both arches well to sit down with the code and sort out why it's broken.
[23:22] <infinity> I'm assuming similar reasons for both.  The neon code probably assume armv7t2, and the atlivec code probably assume big-endian.
[23:22] <infinity> s/assume/assumes/g
[23:23] <xnox> "assume armv7t2" hm. i thought neon is compatible...
[23:30] <infinity> Or it could just be buggy assembly...
[23:53] <xnox> infinity: well, looking at that file the bits that blow up on arm64 are in the conditional CONFIG_RV40_DECODER, below it there is also CONFIG_VC1_DECODER so possibly just RV40_DECODER could be disabled on arm64
[23:53] <xnox> (assuming that vc1 is not bust)
[23:54] <xnox> (*disabled = neon optimization of RV40 decoder that is)
[23:56] <xnox> hm, or is it bailing because rv40bias constants become undefined even if they are called...... i really have no clue in asm =(