| 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 | 00:54 |
|---|---|---|
| slangasek | bdmurray: hmmm possibly related to my /etc/update-manager/release-upgrades.d/local-mirrors.cfg no longer having the expected effect | 01:30 |
| === 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 | ||
| tseliot | hi, can and admin reject xorg-server-lts-saucy from precise-proposed, please? (I forgot to include the previous release in the diff) | 07:51 |
| infinity | tseliot: Done. | 08:01 |
| tseliot | infinity: thanks | 08:01 |
| === nobuto_ is now known as nobuto | ||
| === ara is now known as Guest58311 | ||
| 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:42 |
| cjwatson | We haven't started any trusty LTS builds yet | 12:43 |
| cjwatson | I was planning to do that after the livefs infrastructure changes are done | 12:44 |
| 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. | 12:58 |
| === Ursinha is now known as Ursinha-afk | ||
| xnox | cjwatson: well, can we spin up mythubuntu trusty daily? mythbuntu have fixes in -updates that unbreak mythubuntu ubiqyity plugins. | 13:27 |
| 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:28 |
| ScottK | Sigh. | 13:29 |
| 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:30 |
| 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:32 |
| infinity | But it would also invalidate to some extent the binary testing that was done, as well as being a waste of resources. | 13:33 |
| 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:34 |
| ScottK | I agree it would cost some additional resources, but I don't think it would be a waste. | 13:35 |
| === Ursinha-afk is now known as Ursinha | ||
| 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:42 |
| infinity | (or just P/C/R it out of existence, which is probably smarter than a transitional) | 13:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| ScottK | If someone had said CI train uploads skip new so it doesn't matter then I'd have said go for it. | 13:47 |
| 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:48 |
| ScottK | infinity: OK. Then that's a different bug. | 13:50 |
| ScottK | I've NFC why it's even sent out for review. | 13:50 |
| ScottK | Thanks for pointing that out. | 13:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 13:58 |
| 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:02 |
| 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:03 |
| 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:04 |
| ScottK | xnox: Why? Anyone I know that manages branches directly tags it when it's uploaded. | 14:05 |
| ogra_ | ah, so Timo himself | 14:05 |
| 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:06 |
| 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:07 |
| xnox | ogra_: testing is meant to be complete by that time (ppa -> -proposed copy) | 14:09 |
| 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:10 |
| ScottK | ogra: It's already in the archive so what's the point of not making the cvs catch up. | 14:11 |
| 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:12 |
| ogra_ | but i think it is logical to wait with merging till *all* testing is done ... | 14:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| rcj | arges, Would you have time this morning to look at bug #1275656? | 14:23 |
| 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:31 |
| cjwatson | Or at least defensible | 14:32 |
| arges | rcj: i already did look at it and sponsored it. What changed? | 14:32 |
| 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:33 |
| rcj | arges, thanks | 14:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| cjwatson | Then it'd be analogous to "master" and "next" | 14:39 |
| ScottK | ogra_: For the package history it is. | 14:39 |
| 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:30 |
| slangasek | superm1: done (the upload axe, not the cdimage change which I will defer to cjwatson on) | 15:58 |
| superm1 | thanks | 15:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| ogra_ | no, i was just forwarding the request | 16:02 |
| * slangasek nods | 16:02 | |
| didrocks | xnox: I think the answer to your question is "yes", but I wouldn't guess and let infinity answering | 16:07 |
| xnox | didrocks: sorry, i think i lost context =) | 16:42 |
| xnox | only question i had recently, was responded by colin.... | 16:43 |
| ogra_ | xnox, who cares about context as long as the answer is positive ;) | 17:09 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| Logan_ | why was libav rejected? | 21:37 |
| ScottK | Logan_: it FTBFS on two archs. | 21:46 |
| ScottK | Starting a transition on just some archs sucks. | 21:46 |
| Logan_ | right, I figured - just making sure | 21:48 |
| === Ursinha is now known as Ursinha-afk | ||
| xnox | Logan_: is anybody looking into fixing libav? or shall i take a look. | 23:08 |
| 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:10 |
| Logan_ | xnox: but if you have any ideas on how to fix either, feel free to go ahead with patches | 23:11 |
| xnox | Logan_: ok, let me try. | 23:12 |
| infinity | xnox: I was going to look at it. | 23:17 |
| infinity | xnox: The simple fix is, well, simple. | 23:17 |
| Logan_ | infinity: disabling altivec? | 23:18 |
| infinity | Logan_: altivec on ppc64el and neon on arm64, yeah. | 23:19 |
| Logan_ | I see that as a stopgap tbh | 23:19 |
| infinity | As do I. siretart and I chatted about this last night. | 23:20 |
| 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:21 |
| 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:22 |
| xnox | "assume armv7t2" hm. i thought neon is compatible... | 23:23 |
| infinity | Or it could just be buggy assembly... | 23:30 |
| 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:53 |
| xnox | (*disabled = neon optimization of RV40 decoder that is) | 23:54 |
| xnox | hm, or is it bailing because rv40bias constants become undefined even if they are called...... i really have no clue in asm =( | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!