[00:54] 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] bdmurray: hmmm possibly related to my /etc/update-manager/release-upgrades.d/local-mirrors.cfg no longer having the expected effect === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Adri2000_ is now known as Adri2000 === jhodapp|afk is now known as jhodapp === fginther` is now known as fginther [07:51] 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] tseliot: Done. [08:01] infinity: thanks === nobuto_ is now known as nobuto === ara is now known as Guest58311 [12:42] 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] We haven't started any trusty LTS builds yet [12:44] I was planning to do that after the livefs infrastructure changes are done [12:58] 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. === Ursinha is now known as Ursinha-afk [13:27] cjwatson: well, can we spin up mythubuntu trusty daily? mythbuntu have fixes in -updates that unbreak mythubuntu ubiqyity plugins. [13:28] (e.g. to prevent installer from crashing if one chooses vnc option) [13:28] ScottK: All copies skip binary NEW, it's a longstanding bug. [13:29] Sigh. [13:30] Well, s/bug/misfeature/ ... It's not trivial to fix, but it's on the TODO. [13:30] So CI train is both a backdoor for non-developers to upload and gets less scrutiny. [13:30] Pretty much means completely rewriting what a copy is. [13:30] could some archive admin let golang-udm out of NEW ? [13:32] infinity: that or deciding copy from CI train isn't the right way. [13:32] 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] AFAICT source only copy and rebuild would make it hit new. [13:32] Yes, it would. [13:33] But it would also invalidate to some extent the binary testing that was done, as well as being a waste of resources. [13:34] The tests get rerun anyway for migration from proposed don't they? [13:34] Different testing. Which is, indeed, also a problem IMO. [13:34] All the testing they do should be done at the -proposed stage, not before. [13:35] I agree it would cost some additional resources, but I don't think it would be a waste. === Ursinha-afk is now known as Ursinha [13:42] ScottK: So, I'm curious what the deep concern here is in this case. I assume the package rename was warranted. [13:42] 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] (or just P/C/R it out of existence, which is probably smarter than a transitional) [13:44] 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] Given new gets skipped, it doesn't matter. [13:44] bdmurray, picked up a new ceph bug whilst testing proposed yesterday/today - its not technically a regression compared to release - bug 1322498 [13:44] I mostly don't appreciate being ignored. [13:45] 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] 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] If someone had said CI train uploads skip new so it doesn't matter then I'd have said go for it. [13:48] ScottK: It landed in the distro 5 hours BEFORE your review. I'm not sure what responsiveness you were hoping for. [13:48] 6 hours, even. [13:50] infinity: OK. Then that's a different bug. [13:50] I've NFC why it's even sent out for review. [13:51] Thanks for pointing that out. [13:52] 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] 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] Cause that should probably halt it. [13:54] It doesn't check the reviews or status at all AIUI [13:54] 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] Also if it's automatically copied, the MP get automatically merged so people don't review stale proposals. [13:55] (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] Yep. [13:56] But in this case something should have marked it merged when it was copied. [13:56] Then I wouldn't have reviewed a stale proposal. [13:57] Hrm [13:57] Was this a source package upload through the train? [13:57] if it was the train you should file a bug ... [13:57] Laney: https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_fixpkgname/+merge/220601 [13:57] It was that. Whatever that means. Looks trainy. [13:57] infinity: I see it [13:58] Train can handle human uploads to its PPAs too [13:58] but I think you lose any merging-back if you do that [13:58] yeah [14:02] When direct uploads are being made and handled by the CI train, no bzr merges are made by the infrastructure [14:02] 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] then you make robru jobless :P [14:03] i guess he was the one who merged it and drove it through the train [14:03] (guessing by the landing time) [14:04] ScottK: branch merges happen at -proposed -> release copy stage, not during ppa -> proposed copy. [14:04] ogra_: https://ci-train.ubuntu.com/job/landing-016-2-publish/22/ [14:05] xnox: Why? Anyone I know that manages branches directly tags it when it's uploaded. [14:05] ah, so Timo himself [14:06] ScottK, and if the merge expoxes massive errors during autopkgtest ? [14:06] ScottK: during ppa -> -proposed, there is a separate branch available owned by bot. [14:06] Yet another misfeature. [14:07] you really dont want it to land in trunk before it passed testing [14:07] 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] ogra_: testing is meant to be complete by that time (ppa -> -proposed copy) [14:10] xnox, why do we have proposed->archive then ? [14:10] ogra_: that's britney migration. [14:10] and ADT. [14:10] testing the package itself is done by that time ... that doesnt mean it plays nicely with the archive [14:10] either manual testing needs to move during proposed->archive stage. [14:10] or its rdeps [14:10] (e.g. open a blocking bug) [14:11] ogra: It's already in the archive so what's the point of not making the cvs catch up. [14:12] ScottK, if issues are found in proposed so that the package gets dropped your branch will be out of sync [14:12] xnox: In this case it's a packaging branch so trunk moves on isn't relevant. [14:12] (note that i dont work on CI i'm just a consumer myself) [14:13] but i think it is logical to wait with merging till *all* testing is done ... [14:14] 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] but it isnt in the archive until britney lets it [14:14] ogra_: Yes it is. [14:15] ogra_: It's been uploaded to the archive, release pocket is irrelevant to packaging history. [14:15] we had removals from -proposed in the past, didnt we ? [14:15] On rare occasions, that doesn't mean the upload never existed. [14:16] 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] you shoudl probably involve some train developer/admin in this discussion ;) [14:16] You still want your VCS to reflect that, maybe someone wants to see what was reverted and why. [14:17] So someone else doesn't try the same broken thing two days later. :P [14:17] i'm sure there is a reason didrocks picked this way to workflow [14:17] s/to/of/ [14:18] if it couldnt be merged due to being dropped from proposed the MP histrory will reflect that [14:18] MP history isn't VCS history. [14:18] admittedly the changelog perhaps wont [14:18] Nor is it package history. [14:18] depending on the developer and how he works with changelogs [14:19] But I think I'm going to take my sick butt back to bed instead. :P [14:19] yeah, get better so we can meet next week :) [14:23] arges, Would you have time this morning to look at bug #1275656? [14:31] It does actually get committed to revision control when it hits -proposed, just to a different branch [14:31] I made the same initial objection but having it on a different branch actually does seem kind of sensible [14:32] Or at least defensible [14:32] rcj: i already did look at it and sponsored it. What changed? [14:33] xnox: I can have a look on Monday, I guess, but probably not today [14:33] 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] rcj: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=open-vm-tools I'll reject the older one [14:34] arges, thanks [14:35] rcj: the other one is here https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=open-vm-tools [14:35] arges, Thank you. [14:35] rcj: no problem [14:36] 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] as you can see above -proposed isnt irreversible [14:38] Well, I said defensible not that I necessarily agreed ... [14:38] I think this would make a lot more sense in git where you wouldn't have to dig out a separate URL [14:39] Then it'd be analogous to "master" and "next" [14:39] ogra_: For the package history it is. [15:30] 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] superm1: done (the upload axe, not the cdimage change which I will defer to cjwatson on) [15:58] thanks [15:59] 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] 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] ah, k [16:00] I'm assuming you don't want me to do a straight review->reject, so... :) [16:00] yeah, better not :) [16:00] 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] right ... and then you can do it in person anyway [16:01] which will be faster [16:01] (unless you want to discuss with me today why this one is using gc again after we sorted out nuntium using gccgo) [16:02] no, i was just forwarding the request [16:02] * slangasek nods [16:07] xnox: I think the answer to your question is "yes", but I wouldn't guess and let infinity answering [16:42] didrocks: sorry, i think i lost context =) [16:43] only question i had recently, was responded by colin.... [17:09] xnox, who cares about context as long as the answer is positive ;) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:37] why was libav rejected? [21:46] Logan_: it FTBFS on two archs. [21:46] Starting a transition on just some archs sucks. [21:48] right, I figured - just making sure === Ursinha is now known as Ursinha-afk [23:08] Logan_: is anybody looking into fixing libav? or shall i take a look. [23:10] the most I did in terms of looking into fixing it was triaging the appropriate bug for ppc64el :P [23:10] I'm not sure whether to report the arm64 issue upstream or not [23:11] xnox: but if you have any ideas on how to fix either, feel free to go ahead with patches [23:12] Logan_: ok, let me try. [23:17] xnox: I was going to look at it. [23:17] xnox: The simple fix is, well, simple. [23:18] infinity: disabling altivec? [23:19] Logan_: altivec on ppc64el and neon on arm64, yeah. [23:19] I see that as a stopgap tbh [23:20] As do I. siretart and I chatted about this last night. [23:21] would any collaboration with libav upstream help? [23:21] Just needs someone who knows both arches well to sit down with the code and sort out why it's broken. [23:22] I'm assuming similar reasons for both. The neon code probably assume armv7t2, and the atlivec code probably assume big-endian. [23:22] s/assume/assumes/g [23:23] "assume armv7t2" hm. i thought neon is compatible... [23:30] Or it could just be buggy assembly... [23:53] 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] (assuming that vc1 is not bust) [23:54] (*disabled = neon optimization of RV40 decoder that is) [23:56] hm, or is it bailing because rv40bias constants become undefined even if they are called...... i really have no clue in asm =(