[00:44] <imgbot> [00:44] <imgbot> [02:09] <imgbot> [03:09] <imgbot> [03:44] <Mirv> morning
[03:44] <imgbot> [03:44] <imgbot> [03:51] <rsalveti> cjwatson: ogra_: bug https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1375555
[03:52] <rsalveti> jdstrand: ^ as you're always using the emulator (just heads up)
[04:19] <imgbot> [04:19] <imgbot> [06:50] <robru> camako: thanks for hitting the DEBUG flag, output clearly shows SILONAME being set, so yeah, you must have hit some kind of transient error during the deployment. everything looks fine on this end (well, except your build failing, but that's a separate issue. ;-)
[07:11]  * Mirv archived landed landings
[07:41] <lool> ToyKeeper: I dont know what network manager usually uses as test plan; what cyphermox_ told me to test is noted in the spreadsheet: that you see as many wifis around before and after the change
[09:15] <ogra_> cjwatson, bah, i messed up with ubuntu-touch-meta again, i copied it to rtm-proposed (had forgotten about the desktop deps) ... is it enough if i copy again but to the rtm archive or does it need archive admin action ?
[09:19] <Mirv> ^ that's the one-liner for bug #1373807
[09:32] <popey> Mirv: could yuou please upload http://s-jenkins.ubuntu-ci:8080/job/rssreader-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.shorts_0.2.330_all.click to the store
[09:42] <cjwatson> ogra_: what no!  don't copy directly to rtm
[09:42] <cjwatson> you can't anyway :)
[09:42] <ogra_> didnt we do that the last time ?
[09:42] <cjwatson> no
[09:42] <ogra_> and i think i see pitti do it all the time
[09:42] <cjwatson> pitti needs to stop that :)
[09:42] <ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-September/000410.html
[09:43] <ogra_> and steve too :)
[09:43] <cjwatson> I've asked him not to
[09:43] <ogra_> k
[09:43] <ogra_> can you push it through then
[09:43] <cjwatson> yes, the correct thing to do here is to tell proposed-migration to do it
[09:44] <cjwatson> pitti and slangasek can do that because they're archive admins, but shouldn't (may be accidental)
[09:44] <ogra_> right, so i did mindlessly the right thing, great :)
[09:44] <cjwatson> you can't because you're not
[09:44] <ogra_> ah, k
[09:45] <cjwatson> ogra_: you know what, I'd rather not force this, I'd rather finish my job of copying the dependencies
[09:46] <ogra_> ok, nothing urgent in there iirc
[09:47] <ogra_> cjwatson, oh, wait ... looking at the excuses page, the notes-app should actually be removed from desktop
[09:47] <cjwatson> *shrug*
[09:47] <cjwatson> copying it isn't a problem though
[09:47] <ogra_> indeed, but we want desktop to match touch
[09:48] <cjwatson> not my problem for now
[09:48] <ogra_> no, but one dep less for you
[09:48] <cjwatson> too late anyway
[09:48] <ogra_> heh, k
[10:03] <cjwatson> ok, all of rtm update_excuses should clear shortly
[10:04] <cjwatson> and ubuntu-touch-meta shouldn't be a problem in the future, at least until more desktop deps are added
[10:04] <cjwatson> ogra_: also pitti has said he stopped doing that ages ago after the last time I asked him :)
[10:12] <ogra_> ah, k
[10:12] <ogra_> i just saw the uploads on the changes ML
[10:16] <ogra_> sil2100, any idea what happened to the content of rtm-007 ?
[10:16] <ogra_> (i know it was there yesterday, now the PPA is empty)
[10:17] <bzoltan2> cjwatson: I have tested the new click with the named chroots. Fixed the QtCreator Ubuntu plugin for it https://code.launchpad.net/~bzoltan/qtcreator-plugin-ubuntu/support_named_chroots/+merge/236245
[10:17] <bzoltan2> cjwatson: Thank you for that feature. It enabled the automatic functional testing of the SDK tools.
[10:18] <sil2100> ogra_: let me take a look
[10:19] <ogra_> the dashboard still says "packages built"
[10:20] <sil2100> ogra_: ugh
[10:20] <sil2100> :o
[10:20] <cjwatson> bzoltan2: Great, thanks for the confirmation.  I've yet to be able to test click properly otherwise because of the emulator being broken at the moment.
[10:20] <ogra_> i have no prob starting over ... but i thought you might want to investigate :)
[10:21] <sil2100> ogra_: I have no idea what happened! I'll look into what's up, but you'll probably have to press build and list 'android-tools' there now to get those back in
[10:21] <bzoltan2> cjwatson: Yeps, I started my day with the broken emulator. Indeed it is more important.
[10:21] <ogra_> sil2100, no prob
[10:24] <ogra_> heh
[10:24] <cjwatson> bzoltan2: It's not my wheelhouse, but having a look at it to see if I can track down the broken object
[10:37] <Mirv> popey: shorts uploaded.
[10:37] <popey> thanks Mirv
[10:48] <t1mp> is there a problem with the makos (or something else) in CI?
[10:49] <t1mp> In this MR I get a different (seemingly unrelated) failure for every CI/autolanding run https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977
[10:51] <t1mp> cihelp ^
[10:54] <popey> Mirv: could you please upload calendar 484 to the store. http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.calendar_0.4.484_all.click
[10:54] <sil2100> camako: hey! You want me to perform a rebuild of i386 mir in rtm/20 ?
[10:55] <t1mp> elopio: do you have an idea what can cause the failures in https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977
[10:59] <mzanetti> trainguards: please reconfig silo 6 for me
[10:59] <sil2100> mzanetti: ACK!
[10:59] <mzanetti> thanks!
[11:01] <sil2100> mzanetti: ugh, this is taking awfully long
[11:01] <mzanetti> sil2100: there are quite a few branches in there
[11:02] <sil2100> mzanetti: ok, done, but just so you know:
[11:02] <sil2100> mzanetti: WARNING ubuntu-system-settings is already prepared for the same serie and destination in ubuntu/landing-002
[11:02] <sil2100> and
[11:02] <sil2100> WARNING qtmir is already prepared for the same serie and destination in ubuntu/landing-007
[11:02] <mzanetti> hmm
[11:02]  * mzanetti looks
[11:02] <sil2100> Please coordinate accordingly
[11:03] <mzanetti> sil2100: ok. not a problem for landing-007. but indeed need to coordinate with landing-002. thanks for the hint!
[11:03] <sil2100> yw :)
[11:25] <mzanetti> *boom*
[11:31] <bzoltan2> trainguards: I could use a Utopic silo for the  line 70
[11:31] <Mirv> bzoltan2: ok
[11:45] <cjwatson> emulator investigations have taken me to http://www.akkadia.org/drepper/tls.pdf .  if I do not emerge in a few hours then please send a search party
[11:45] <ogra_> lol
[11:46] <ogra_> cjwatson, i think rsalveti chnaged some TLS bits initially to make the emulator work at all ... not sure that was ever changed back
[11:46] <cjwatson> ogra_: well we should be able to track down and destroy the libraries that are using static TLS, since in general libraries shouldn't be
[11:48] <ogra_> ah, i think thats what he did back then
[11:52] <ogra_> cjwatson, hmm ... http://people.canonical.com/~ogra/touch-image-stats/256.changes ... not sue if you really want the fake-env installed, that came in with the last qtmir landing (by accident it seems)
[11:53] <ogra_> (some broken "or" dependency )
[11:53] <cjwatson> not installed on my test system
[11:58] <ogra_> hmm
[11:58] <ogra_> how did that end up in the changelog at all ... i dont see it in any of the manifests either
[11:59]  * cjwatson is walking through debugging steps from https://bugzilla.redhat.com/show_bug.cgi?id=1124987
[12:10] <cjwatson> wonder if this libc patch from RH would fix it
[12:10] <cwayne> sil2100: btw we'll likely need QA to do a pass over a custom tarball today in conjunction with a landing from jdstrand
[12:11] <sil2100> cwayne: oh, ok, since we're also waiting for test results for the new device tarball
[12:11] <cwayne> sil2100: ah, ok, cool, how much testing is left to do there?
[12:12] <sil2100> cwayne: not sure
[12:12] <sil2100> brendand, john-mcaleely: any news on the device tarball?
[12:13] <sil2100> kgunn: ping
[12:13] <kgunn> sil2100: hey
[12:14] <sil2100> kgunn: hey! So you mentioned that the utopic issue with videos not launching from the scope is related to media-hub - do you know if that landed in utopic already?
[12:15] <kgunn> sil2100: landed in utopic yes, but not on rtm...was waiting on qa as of last night
[12:16] <sil2100> Ok, well, it was basically a problem in utopic, so in this case it's good to know it's fixed
[12:17] <kgunn> sil2100: so you've confirmed those mediahub branches were in the image tested ?
[12:17] <brendand> kgunn, i just signed off 26
[12:17] <john-mcaleely> sil2100, none yet. been a morning of distractions
[12:23] <cjwatson> building a test glibc with Carlos's DTV_SURPLUS patch from RH to see if that fixes the emulator
[12:27] <jdstrand> rsalveti: thanks for the heads up! (I do love the emulator)
[12:38] <cjwatson> jdstrand: could you have a look over my proposal at the end of bug 1371574?
[12:40] <cwayne> john-mcaleely: sil2100: would it make sense to do a custom + device check? or do they need to be separate
[12:40] <john-mcaleely> cwayne, I think we should keep them separate
[12:42] <cwayne> probably makes the most sense
[12:43] <jdstrand> cjwatson: yes, I was getting through all me other irc pings so I could focus on yours :)
[12:43] <jdstrand> my*
[12:44] <cjwatson> heh
[12:50] <dbarth> hi trainguard, on line 51 i have finished testing the silo
[12:50] <sil2100> dbarth: you need a sync for RTM now, right?
[12:50] <dbarth> it's marked as "needs building", but of oxide was binary copied in the silo
[12:51] <sil2100> dbarth: ah, ACK
[12:51] <dbarth> sil2100: just next, yes; the line exists, but i still need to repeat the test on my rtm phone now
[12:52] <dbarth> sil2100: but to test from an rtm silo, i need the sync i guess ;)
[12:52] <dbarth> do a bin. copy if at all possible, otherwise, it's 5h at best
[12:52] <sil2100> dbarth: in theory, yes ;) Doing that anyway now
[12:52] <sil2100> All is a binary copy now
[12:52] <sil2100> So no worries ;)
[12:52] <dbarth> nice
[13:04] <john-mcaleely> sil2100, ogra_ brendand New device tarball
[13:05] <ogra_> you mean it passed and is released ?
[13:05] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20140929-d974fdc.tar.xz
[13:05] <ogra_> cool !
[13:05] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20140929-d974fdc.changes
[13:05] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20140929-d974fdc.ods
[13:05] <sil2100> brendand: ^ o/
[13:05] <john-mcaleely> I think it now needs your QA signoff
[13:05] <ogra_> ah
[13:05] <sil2100> john-mcaleely: thanks :)
[13:05] <brendand> john-mcaleely, can't access that file
[13:05] <john-mcaleely> note that at least one test was not performed because I lack the kit (a locked SIM(
[13:06] <brendand> john-mcaleely, the .ods file
[13:06] <john-mcaleely> brendand, doh. please try again :-)
[13:09] <Mirv> sil2100: I wonder how/if Oxide can be landed to utopic, since it's not in bug #1371635 list and is a new version
[13:10] <sil2100> Mirv: true, depends if this is a bugfix or not
[13:10] <Mirv> or maybe that is really small(ish) bugfix releae
[13:10] <Mirv> with oxide, I kind of assumed "huge things changing", but that doesn't look too bad
[13:11] <sil2100> From the changelog I see that there are many bugfixes there, but only bugfixes
[13:11] <sil2100> So this could be feasible for a release
[13:19] <jdstrand> rsalveti: hey, for preinstalled apps on the device (specifically not custom), where do the precached profiles live, in the device tarball? the rootfs?
[13:20] <Mirv> wget:ing and debdiff:ing two 300MB sources (compressed) makes one appreciated network, cpu and ssd speeds
[13:20] <ogra_> jdstrand, rootfs
[13:20] <jdstrand> ok, thanks
[13:20] <cjwatson> ha!  libc fix is enough
[13:21] <ogra_> jdstrand, iirc there is a hook for pre-generation in the livecd-rootfs package
[13:24] <Mirv> sil2100: did you add the oxide rtm line?
[13:25] <Mirv> I just fixed its fields so that status is correctly shown
[13:26] <sil2100> Mirv: yeah, I added it some time ago, what happened?
[13:27] <Mirv> sil2100: adding the rtm silo like that straight beneath the utopic silo is nice (I always do that), but you need to copy-paste C and N columns' special equation from another line
[13:27] <sil2100> uh?
[13:28] <sil2100> Mirv: but the line was there
[13:28] <sil2100> Mirv: I just assigned the silo for that
[13:28] <Mirv> sil2100: ah, ok, then it was someone else who added the newline originally
[13:28] <sil2100> Ah, maybe dbarth copied it that way, I didn't check if the formulas were like that
[13:28] <Mirv> anyway, FYI oxide debdiff (omitting chromium) http://pastebin.ubuntu.com/8466001/
[13:28] <sil2100> I just changed the sources list to a "sync:" and assigned :)
[13:29] <thostr_> Mirv: could we get a silo again for line 8?
[13:37] <fginther> t1mp, added comment on https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977
[13:48] <t1mp> fginther: thank you!
[13:48] <t1mp> fginther: so the solution, for now, is to wait for the fix in [1] to land in the image that is used for testing?
[13:54] <t1mp> fginther: ^ how can I know that the fix is in?
[13:55] <fginther> t1mp, the fix for [1] landed yesterday, but it did impact all of those results.
[13:55] <fginther> t1mp, the system-settle problem is new. Was trying to track down if this is being seen elsewhere
[13:55] <ogra_> fginther, t1mp, note that we see settle_after issues in image smoketesting too ... usually due to unity8-dash not settling properly
[13:56] <fginther> ogra_, thanks for that info
[13:56] <ogra_> :)
[13:56] <ogra_> there was also a bug for the dash about it leaking a lot of memory
[13:56] <ogra_> might be related
[13:56] <t1mp> ok, I'll do an empty commit to trigger CI again
[13:56] <fginther> t1mp, just re-approve the MP
[13:57] <t1mp> zsombi: ^ can you happrove https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/gc/+merge/235977 again?
[13:57] <zsombi> t1mp: nope :)
[13:58] <t1mp> zsombi: this is serious. No time for jokes ;)
[13:58] <zsombi> t1mp: nope :)
[14:02] <brendand> john-mcaleely, just getting started with the tarball - i was finishing a silo
[14:02] <john-mcaleely> brendand, great!
[14:21] <sil2100> ogra_: btw. since it's Tuesday again, could you lead the evening meeting? :)
[14:22] <ogra_> sil2100, since it's Tuesday again, indeed :)
[14:22] <sil2100> Thanks!
[14:24] <Laney> IT'S TUESDAY?!?!?!
[14:29] <ogra_> Laney, didnt they tell you ?
[14:30] <Laney> nobody tells me anything!
[14:30] <ogra_> evil !
[14:44] <thostr_> sil2100: can I get a silo again for line 8
[14:45] <sil2100> thostr_: sure :)
[14:45] <sil2100> thostr_: hmm, there are at least 2 silos with u-s-s right now
[14:46] <thostr_> sil2100: right, we'll sync once we now how it tests
[14:46] <sil2100> Ok
[14:49] <ogra_> hmm, the indicators look weird in the latest utopic image
[14:55] <cjwatson> ogra_,rsalveti,jdstrand: emulator should be unbusted in the next image build after glibc publishes
[14:56] <popey> Mirv: still about? can you upload that calendar click?
[14:57] <ogra_> cjwatson, cool, i'll make sure we get a build then
[14:57] <sil2100> ogra_: didn't we land that indicator-display thing in utopic?
[14:57] <ogra_> "that indicator-display thing" ?
[14:57] <ogra_> can you be more specific ?
[14:58] <ogra_> indicator-display is in both archives afaik
[14:58] <ogra_> and now also seeded in both images
[14:58] <jdstrand> cjwatson: cool, thanks!
[14:58] <ogra_> (with the next rtm build)
[14:58] <cjwatson> ogra_: glibc takes ~3h to build on armhf, and it'll presumably trigger All The Autopkgtests, so might just end up being tomorrow morning's run
[14:58] <ogra_> oh, yeah, sounds like it :)
[14:59] <jdstrand> cjwatson: and you now have a response to bug #1371574
[15:00] <cjwatson> ta
[15:00] <jdstrand> np
[15:00] <jdstrand> stepping into a meeting now, so won't be terribly responsive for a bit
[15:01] <cjwatson> jdstrand: will ponder, and likewise
[15:01] <jdstrand> k
[15:09] <brendand> ogra_, for silo 7 did you just test that the bugfix works?
[15:09] <ogra_> brendand, i did everything i described
[15:09] <ogra_> (see the spreadsheet)
[15:09] <cjwatson> ogra_: I guess if everything works tomorrow we should sync glibc through a silo into rtm; I can't point to a single change that caused this, it was a limit we tipped over, and we could tip over it in rtm at any time
[15:10] <ogra_> ok
[15:12] <brendand> ogra_, so it's not worth repeating any of the same tests i ran for the last android-tools-adbd landing?
[15:12] <ogra_> brendand, i only left QA signoff checked because the package has more than one fix included :)
[15:12] <jhodapp> sil2100, line 25 in the spreadsheet (silo 13) is ready to publish
[15:13] <ogra_> brendand, not really ... juust verifying the two bugs are fixed should be fine i think
[15:13] <sil2100> jhodapp: thank you!
[15:14] <jhodapp> sil2100, np! :)
[15:28] <Mirv> popey: sure
[15:29] <Mirv> thostr_: seems you've got it now
[15:29] <Mirv> popey: hmm, have I missed some link? my Debian hosting irssi crashed earlier today and I restarted
[15:30] <popey> Mirv: ah okay... yes
[15:30] <Mirv> popey: oh, yes I have!
[15:30] <Mirv> popey: found
[15:30] <popey> thanks
[15:31] <Mirv> done
[15:58] <rsalveti> cjwatson: thanks for fixing glibc
[16:00] <rsalveti> jdstrand: there are only two possible paths for preinstalled apps, either custom or rootfs
[16:00] <rsalveti> jdstrand: at least atm we're not shipping any app in the device tarball
[16:01]  * ogra_ hopes we'll (they*ll) never do 
[16:02] <ogra_> robru, meeting ?
[16:14] <jdstrand> rsalveti: ack, thanks
[16:16] <brendand> john-mcaleely, actually just hold on a little bit before pushing it
[16:16] <john-mcaleely> ogra_, sil2100 new device tarball pushed
[16:16] <john-mcaleely> brendand, ah
[16:16] <ogra_> merci !
[16:16] <brendand> john-mcaleely, give me 15-20 minutes more
[16:19] <john-mcaleely> brendand, sorry. I thought I could push, and I have
[16:19] <cwayne> sil2100: do you guys have time for a QA custom then?
[16:20] <brendand> john-mcaleely, ok well the thing i had trouble with is something you guys tested, so i expect it might be something else causing me trouble
[16:21] <john-mcaleely> brendand, ah, what?
[16:21] <brendand> john-mcaleely, anyway if we get bitten then we can always improve the test plan
[16:21] <brendand> john-mcaleely, video playback - yes i too don't see how the tarball could break that
[16:22] <john-mcaleely> brendand, that's super flaky, so some files are definately still broken
[16:23] <AlbertA2> trainguards: utopic landing-013 is ready to publish
[16:23] <brendand> john-mcaleely, it's one that worked earlier in the day
[16:23] <john-mcaleely> brendand, and we can break it in the device tarball, but I don't think this one has changes there.
[16:23] <john-mcaleely> brendand, hrm. not so good
[16:23] <john-mcaleely> brendand, +1 on iterating the test plan
[16:25] <brendand> john-mcaleely, in the worst case scenario are tarballs revertable?
[16:25] <john-mcaleely> brendand, yes, and I'd be happy to do that drill.
[16:25] <john-mcaleely> brendand, it's good practice :-)
[16:27] <brendand> john-mcaleely, ok phew - it's not the tarball but something that landed in #73
[16:27] <john-mcaleely> brendand, phew!
[16:27] <john-mcaleely> brendand, ah, there's a bug in the test plan. no slot for which build I tested against...
[16:27] <john-mcaleely> brendand, your master is view-only for me. can you revise it?
[16:29] <brendand> john-mcaleely, done. and i made a new tab - can you complete the name and copy the contents of the ods file in there?
[16:29] <john-mcaleely> brendand, sure
[16:30] <brendand> john-mcaleely, actually i was going to say my preference would be for you just to create new tabs in that doc for each test run
[16:31] <john-mcaleely> brendand, ok. I'll save each tab as an ods - otherwise I'm not publishing them :-)
[16:32] <brendand> john-mcaleely, i'll ignore that
[16:33] <john-mcaleely> brendand, fine by me
[16:40] <robru> pstolowski: ok you got utopic 24
[16:40] <pstolowski> robru, thank you
[16:40] <robru> pstolowski: you're welcome!
[16:42] <robru> kgunn: not sure what's going on in utopic-6 there. let me know if you need me to delete qtmir/u-s-s
[16:50] <mzanetti> trainguards: need another reconf of silo6 please
[16:50] <popey> fginther: did you see pings about music remix 2.0 needing to be added to jenkins?
[16:51] <robru> mzanetti: really a reconf, or do you just wan me to delete qtmir and u-s-s? (eg did you add MPs?)
[16:51] <cwayne> sil2100: brendand: heya, would you guys be able to test a custom tarball for release today? or would we need to wait for davmor2?
[16:51] <mzanetti> robru: yeah, that would be enough. I removed some mps
[16:52] <brendand> cwayne, i don't think it will happen today
[16:52] <robru> mzanetti: ok, clicked delete, that takes a few minutes to take effect.
[16:52] <mzanetti> robru: thanks
[16:52] <robru> mzanetti: you're welcome
[16:53] <jhodapp> robru, what does the status on utopic silo 13 mean exactly?
[16:53] <jhodapp> robru, I want to get that published
[16:54] <robru> jhodapp: it means it's in the proposed pocket ;-)
[16:54] <robru> jhodapp: it means it's been publish it's just not done yet
[16:54] <jhodapp> robru, ah, I guess I was referring more to the one package at least is not available in the destination message
[16:55] <robru> jhodapp: right, that's because one package at least is not available in the destination ;-)
[16:55] <jhodapp> robru, lol, ok...confusing me because there only being 1 package in my silo
[16:55] <jhodapp> robru, but I guess it's a generic message
[16:55] <robru> jhodapp: if it stays like that for more than an hour or two, you can click on the package name (the one where it says "in the proposed pocket", not the one in the upper list), and it'll show you the proposed migration page that might explain if there's any problems with the migration
[16:56] <jhodapp> robru, ok cool, thanks
[16:56] <robru> jhodapp: yeah it's a generic message, the one package you're publishing just isn't in release pocket yet, it's in proposed.
[16:56] <jhodapp> robru, ok, thanks for humoring my question :)
[16:57] <robru> jhodapp: you're welcome!
[17:06] <plars> mterry: did that unlock loop fix land yet?
[17:09] <mterry> plars, no but it did get approved
[17:55] <fginther> popey, yes. I'm just now getting to that
[18:01] <popey> fginther: awesome, thanks
[18:11] <robru> hehe
[18:24] <robru> That's odd, both my laptops lost Wi-Fi at the same time, but my phone is working fine
[18:30] <fginther> balloons, can you provide a review for: https://code.launchpad.net/~fginther/cupstream2distro-config/add-music-remix/+merge/236586
[18:31] <balloons> fginther, is the hook_source outdated now? I was noticing it on reminders
[18:32] <fginther> balloons, no, the special version of the pep8 pyflakes checker for reminders is still in that branch
[18:32] <balloons> fginther, ahh right.. to ignore the other plugins, gotcha
[18:32] <balloons> I approved, thanks
[18:33] <fginther> balloons, much thanks
[18:56] <sergiusens> robru: hey, can I get a silo for line 57? Not all MPs are approved, but I need to do some test builds
[18:57] <sergiusens> thanks
[18:58] <robru> sergiusens: you're welcome!
[19:07] <sil2100> Ok, now that was intense
[19:08] <sil2100> brendand, ogra_, cwayne: so the custom tarball sign-off has been moved to tomorrow? Or did someone else got assigned to the sign-off
[19:11] <cwayne> sil2100: sounds like it
[19:12] <sil2100> cwayne: maybe we could ask ToyKeeper? Or can you wait for tomorrow indeed?
[19:12] <ToyKeeper> Hmm?
[19:14] <ToyKeeper> If that's what I think it is, it's probably going to be 8+ hours of testing to cover all the click apps, and even then will probably have significant gaps.
[19:19] <cwayne> 8+ hours? davmor usually does it in like 2-ish..
[19:20] <sil2100> cwayne, ToyKeeper: I guess you would have to poke davmor or brendand about that
[19:20] <cyphermox_> sil2100, could you please sync urfkill from Silo ubuntu 11 to RTM 24? I think you have some Jenkins job to do that or is it purely juste the build job?
[19:21] <sil2100> cyphermox_: CI Train does it easily, let me take a look
[19:21] <brendand> cwayne, what's the urgency?
[19:22] <sil2100> cyphermox_: yeah, so I see all is configured properly - just press the build job and input 'urfkill' in the list of packages to rebuild
[19:22] <cwayne> brendand: no huge urgency except it'll pre-seed the aggregators as favorites, and it will go with jdstrand landing apparmor-easyprof
[19:22] <sil2100> It'll sync it up if a sync is needed
[19:23] <brendand> cwayne, so you won't die if it lands tomorrow :)
[19:23] <ToyKeeper> cwayne: I'm estimating 5+ hours for the AP tests, and a few more for manual exploration, plus extra time to check whether the bugs also existed before the change.
[19:24] <cwayne> brendand: I didn't even ask again to do it today sil2100 asked if it was going to happen today, calm down :)
[19:25] <sergiusens> cjwatson: robru the rtm silos only build for the 3 popular arches, right? Means a binary copy from rtm silos to ubuntu ones are not desirable, or am I overthinking here?
[19:25] <ToyKeeper> (depending on what actually changed, that is...  any unchanged click apps can skip the AP tests and get reduced manual testing, which speeds things up a lot)
[19:25] <brendand> cwayne, you calm down...
[19:25] <robru> sergiusens: you're right, it's better to binary copy from utopic to rtm
[19:26] <brendand> cwayne, i'm sure davmor2 will be happy to look at it
[19:26] <cwayne> brendand: that's fine, I'm not even trying to push for it today anymore! i accepted earlier when you said it probably wouldn't be today
[19:26] <cyphermox_> Sil2100 thanks
[19:27] <sergiusens> robru: so I'll tick "only copy source" since I'm doing it the other way around; not sure if the missing arches would be rebuilt (I think they are); but would be better if they are built from one place together
[19:28] <robru> sergiusens: right, I think the better solution is to start in utopic. there's some changes in the pipeline that'll make it easier to build in utopic first and then just publish to utopic and rtm simultaneously without even needing two different silos.
[19:29] <sergiusens> robru: well the big blockers (time wise) have to be at the beginning of the pipe and not end; qa signoff is one of those
[19:30] <robru> sergiusens: right, but everything will be faster if you only have one silo to test & publish rather than needing two.
[19:30] <sergiusens> robru: well if that is made irrelevant, the where to push is too as we only have one :-P
[19:30] <sergiusens> robru: and that's good news if true
[19:30] <robru> sergiusens: yep, sil2100 is working on it, hopefully should land soon-ish
[19:33] <sil2100> o/
[19:37] <robru> heh
[19:38] <sil2100> Oh uh!
[19:42] <robru> sil2100: quick, let's push it to production!
[19:42] <robru> ;-)
[19:44] <cjwatson> sergiusens: Yes, but it would work out - a binary copy from ubuntu-rtm to ubuntu would copy the binaries have have been built and rebuild the rest
[19:44] <cjwatson> sergiusens: Which doesn't really seem worse than rebuilding everything
[19:45] <cjwatson> *that have been built
[19:45] <cjwatson> robru: That sounds reasonable, indeed, if I'm guessing the implementation correctly
[19:46] <sil2100> ogra_, cjwatson: is the emulator in a fixed state right now?
[19:46] <cjwatson> sil2100: Fix is only in -proposed right now, pending doing something about autopkgtest failures
[19:46] <robru> cjwatson: yeah, basically the publish job just also does a binary copy
[19:47] <cjwatson> robru: Well, two binary copies rather than just one, presumably
[19:47] <robru> cjwatson: right, well, the publish job doesn't really do a binary copy, it just makes that rsync file so snakefruit can do a binary copy, but yeah
[19:47] <cjwatson> robru: It should probably have snakefruit do both
[19:48] <cjwatson> The reasons for that would be the same either way ...
[19:48] <robru> cjwatson: makes sense.
[19:48] <robru> sil2100: ^^ sounds like you need to be hacking on copy2distro ;-)
[19:48] <sil2100> No no
[19:48] <sil2100> No hacking needed
[19:49] <cjwatson> sil2100: The autopkgtest queue is way too full right now for it to be worth me looking at it for a bit.  If you desperately need the emulator to work, then you can boot it once, adb shell, grab the libc6/libc-bin/multiarch-support i386 binaries from LP utopic-proposed, dpkg -i, reboot
[19:49] <sil2100> What we'll do is simply the publish job will write 2 entries to the rsync file and we're done ;)
[20:04] <robru> sil2100: oh, can it be that easy? dear god
[20:14] <dbarth> robru: hey, do i need to make a special request to get the new language-pack into rtm?
[20:15] <dbarth> robru: i need 1:14.10+20140923 or superior to fix the accept-language headers with oxide
[20:15] <robru> dbarth: well if nobody requests it, it doesn't happen automatically, so... yes
[20:15] <dbarth> i can add a silo dependency for ex?
[20:16] <robru> dbarth: just make a regular landing request, and in source packages put 'sync:ubuntu,utopic language-pack' (or whatever the source package name is)
[20:16] <dbarth> adding an oxide dep update is a bit of a pain
[20:16] <dbarth> ok, perfect
[20:16] <dbarth> i'll put that in silo 18
[20:18] <robru> dbarth: ok you're going to want it to say 'sync:ubuntu,utopic oxide-qt language-pack' then and then you'll have to wait for oxide-qt to fully land in utopic, thenreconfigure and rebuild the rtm silo
[20:18] <dbarth> robru: rebuild? oxide is a binary copy (given the time it takes)
[20:19] <robru> dbarth: yeah but the build job will need to re run in order to do the binary copy for language-pack
[20:20] <dbarth> robru: ok
[20:20] <dbarth> robru: i copied your line in the cell, hope it's fine this way now
[20:21] <robru> dbarth: right, is 'language-pack' the source package name? i don't actually know
[20:22] <dbarth> checking
[20:23] <dbarth> robru: uh, there is a source package for each language:
[20:23] <dbarth> like https://launchpad.net/ubuntu/+source/language-pack-touch-de
[20:24] <dbarth> it's language-pack-touch-{...}
[20:24] <robru> dbarth: right so you need to list the source package names in that spreadsheet cell. it only works on source package names.
[20:24] <dbarth> uh ok, i need to find an example with the right list
[20:25] <robru> dbarth: but in the case of language-pack-touch-de it looks like the rtm version is actually newer than the utopic version so I'm not sure what you're trying to accomplish exactly
[20:27] <dbarth> robru: i just noticed that the problem with oxide accept-lang headers is fixed in utopic
[20:28] <dbarth> (it takes a langpack update techically)
[20:28] <dbarth> whereas it's still not fixed in rtm
[20:28] <dbarth> hmm
[20:28] <robru> dbarth: perhaps some other source package is responsible
[20:28] <robru> i don't actually know much about langpacks.
[20:28] <dbarth> not fixed in rtm #74
[20:28] <dbarth> so maybe i'm not on the right rtm channel
[20:31] <dbarth> robru: so i put it back to sync:16 for now
[20:32] <dbarth> will clarify tomorrow morning with pitti how to handle safely
[20:32] <robru> dbarth: ok no worries
[20:40] <robru> brb, lunch
[20:51] <ted> robru, I need a silo for integration work with mterry, line 77. Should that be "ready" or just not ready as it's actually not ready? :-)
[21:06] <robru> ted: "ready" means "give me a silo"
[21:06]  * ted doubles down on readiness
[21:07] <ted> robru, Ready! :-)
[21:08] <robru> ted: ok, 13
[21:09] <ted> robru, Great, thanks!
[21:10] <robru> ted: you're welcome!
[21:39] <bfiller> robru: silo 1 in ubuntu not showing up correctly in spreadsheet
[21:58] <robru> bfiller: what row?
[22:00] <robru> bfiller: i don't understand the state the spreadsheet is in. address-book-service seems landed?
[22:00] <robru> but the silo is there
[22:08] <barry> robru: finally got si 2.5 built in landing-002!  i am a good monkey
[22:08]  * robru gives barry a banana
[22:09] <barry> oo oo aa aa
[22:13] <camako> why are our CI mahines using kernels from 2012? Kind of old for an OS company...
[22:14] <robru> camako: because they're probably running precise, because it's an LTS, because any company would desire stability from a server?
[22:15] <camako> Robru, I have code that requires kernel >= 3.11.. and the unit tests are failing. What do I do?
[22:18] <robru> camako: uh, fix your code?
[22:18] <robru> i dunno
[22:18] <robru> camako: like make your unit tests conditional on the right kernel being present or something
[22:18] <camako> robru, lol... this was the "fix"
[22:18] <barry> camako: ping infinity (i think) or stgraber tomorrow and see if one of them can help you
[22:20]  * camako was hoping you'd say we can build/run on a newer kernel
[22:22] <robru> camako: i don't have any power over what system the buildfarm uses.
[22:23] <robru> camako: like you're talking about a PPA build right? that's not even part of the citrain system that I'm maintaining, that's into lp itself.
[22:23] <camako> robru, understood...
[22:24]  * camako goes back to revert the offending "fix"
[23:44] <robru> rsalveti: anpok_: kgunn: mzanetti: Mirv: poke because you guys have silos that are "Ready to build". any chance we could kick some of those builds off?