[08:27]  * ogra_ gets coffee
[08:28] <sil2100> So tired...
[08:32]  * popey stabs 2fa
[08:36]  * Mirv had some login.ubuntu.com problems earlier and webops were looking at it
[08:37] <popey> yeah, needs a lot of refreshes
[08:56] <ogra_> sil2100, if you decide to promote anything during teh evening meeting, just leave a ping around, i'll promote it later then
[09:05] <ogra_> brendand, popey, so looking at the console log of the failing filemanager tests i noticed something ...
[09:05]  * popey crosses fingers
[09:05] <ogra_> it seems to redefine $HOME suring the tests all the time ... to a tmpdir ...
[09:05] <ogra_> but i also see:
[09:05] <ogra_> void DirModel::setPath(const QString&) DirModel(0x739038) path or url may not exist or cannot be read: "~"
[09:06] <popey> ʘ‿ಠ
[09:06] <ogra_> so it seems the test (or the filemanager itself) tries to use ~/
[09:06] <ogra_> i'm not sure that expands to $HOME correctly
[09:07] <brendand> ogra_, i see that too. i'll try and find if the test is doing it
[09:07] <ogra_> (i.e. it might read this from PAM instead of the environment, so you get expansion of the variable for what hopme was set to at login time)
[09:08] <ogra_> doe it actually use a fake $HOME when you test locally too =
[09:08] <ogra_> ?
[09:18] <popey> ogra_: sil2100 brendand i just ran the filemanager tests on flo with qt53 and it passed
[09:18] <popey> Ran 24 tests in 563.684s
[09:18] <popey> OK
[09:19] <popey> so only change was a) make image writable [may have affected tests?] and b) upgrade to qt5.3
[09:19] <brendand> popey, i run it with writable image too
[09:19] <popey> k
[09:19] <brendand> popey, do it again :)
[09:19]  * popey reboots
[09:19] <popey> hah
[09:21] <sil2100> :O
[09:21] <cjwatson> 14197 07:00:01      \_ /usr/bin/python /home/ubuntu-archive/cu2d/cupstream2distro//copy2distro --no-filter
[09:21] <cjwatson> I suspect that's probably hung ... killing it
[09:22] <cjwatson> (we had an rsync hung from around the same time too, so I guess some network problem)
[09:23]  * ogra_ noticed network issues with the image builders too
[09:31] <popey> brendand: passed second time
[09:31] <popey> thats it, land qt 5.3!
[09:31]  * popey runs again
[09:39] <brendand> popey, wow, how lucky is that
[09:43] <sil2100> Saviq: I see a new landing for unity8 - but I see it's already assigned in silo 008
[09:43] <sil2100> Saviq: any possibility of releasing 008 before that?
[09:45] <Saviq> sil2100, unlikely
[09:45] <Saviq> sil2100, there's an issue with indicator-session there that makes the whole silo useless
[09:46] <sil2100> Saviq: should I free this silo then? Or do you still intend to work on this with bregma in the nearest time?
[09:46] <Saviq> sil2100, we will, this week for sure
[09:46] <Saviq> sil2100, and the new unity8 landing should be real quick
[09:47] <sil2100> Saviq: ok, since you're the lander for both, I do 'override' and just sync up the changes then
[09:50] <Saviq> sil2100, thanks
[09:51] <brendand> sil2100, did we discuss the address-book-app failures at all?
[09:52]  * ogra_ doesnt think so 
[09:52] <popey> brendand: failed on the 3rd go, hangs forever
[09:52] <ogra_> we also missed the changes (though they are minor and mostly not affecting us)
[09:53] <brendand> ogra_, looks like that was a mistake. there were two failures and it seems they were genuine
[09:53] <brendand> ogra_, it's not possible to type into the text fields in the contact editor
[09:54] <ogra_> oh
[09:54] <ogra_> that indeed sounds liek a real bug
[09:54] <ogra_> *like
[09:55] <brendand> hmmm, wait. well there is a bug there
[09:56] <brendand> but it looks like the AP tests don't catch it because they don't use the keyboard
[09:57] <sil2100> brendand: we discussed them last week, I have a bug for those
[09:57] <sil2100> brendand: will poke bfiller about those today
[10:04] <brendand> ok, looks like it was just some momentary strangeness. i'll file a bug if it happens again
[10:05] <sil2100> brendand: I tried running those address-book-app AP tests on my device when filling in the bug but they passed twice
[10:36] <ogra_> popey, looking at your bootcharts ... your system never goes properly to idle, else the new chart would stop *a lot* earlier
[11:01] <ogra_> brendand, so running the filemanagerr test locally with exactly the same args:
[11:01] <ogra_> phablet-test-run -A '--timeout-profile=long' -v -o test-out -f subunit -a /var/crash -a /home/phablet/.cache/upstart filemanager
[11:01] <ogra_> doesnt print any of these "~" messages
[11:01] <ogra_> oh, wait
[11:02] <ogra_> i see it in the apps own log
[11:03] <ogra_> aha
[11:03] <ogra_>                 page: FolderListPage {
[11:03] <ogra_>                     objectName: "folderPage"
[11:03] <ogra_>                     folder: "~"//modelData
[11:03] <ogra_>                 }
[11:04] <ogra_> line 103 hardcodes ~
[11:04] <ogra_> (looking at /usr/share/click/preinstalled/com.ubuntu.filemanager/0.3.193/qml/filemanager.qml)
[11:07] <ogra_> aha, line 75 has it too
[11:07] <ogra_> property var folderTabs: ["~"]
[11:14] <ogra_> hmm, and looking at the test code it never exports HOME= but only sets it via initctl
[11:14]  * Mirv wonders if boiko is going to land the address book stuff today
[11:14] <ogra_> (it uses the export for desktop tests of the same package)
[11:14] <Mirv> (it includes an Qt 5.3 related fix)
[11:14] <Mirv> yes, just the one sil2100 is looking at :)
[11:15] <sil2100> Mirv: do you know if it also touches our autopilot issues?
[11:15] <Mirv> sil2100: no, I don't know, I'm just interested in that crash fix and I haven't looked at the other MR:s
[11:16] <sil2100> Damn, the spreadsheet is not auto-updating again...
[11:16] <sil2100> It's barfing out on fetching the backend webpage with an 'unexpected error'
[11:32] <sil2100> It's something I can do nothing to fix...
[11:33] <sil2100> brb
[11:40] <popey> ogra_: which? wopr or deep-thought?
[11:40] <ogra_> popey, the long boot
[11:40] <ogra_> the short one has an awful gap
[11:41] <ogra_> it could boot 10sec faster if you would utilize CPU and disk in the middle
[11:41] <ogra_> (by shuffling stuff around)
[11:41] <popey> i just wiped my laptop clean ☻
[11:42] <ogra_> also none of your systems seems to run ureadahead at all ... it wastes *a lot* if you dont run that
[11:42] <popey> even on ssd?
[11:42] <popey> i dont recall disabling that
[11:42] <ogra_> even SSDs like it if you load everything into RAM at once and can read from there during the further process
[11:43] <davmor2> popey: if you open file browser on mako do you very briefly get the flo portrait tablet view?
[11:43] <ogra_> SSDs might be fast ... but RAM is still faster :)
[11:44] <davmor2> ogra_: Rom is faster :P
[11:44] <ogra_> lol
[11:44] <ogra_> right
[11:44] <popey> davmor2: kinda, yes
[11:46] <davmor2> popey: I'm wondering if autopilot is faster than my finger and can start running on the wrong view
[11:46] <popey> dont think so
[11:47] <popey> the ap doesn't appear at all with broken tests
[11:47] <popey> you just get the unity loading dots
[11:47]  * ogra_ is pretty sure the issues are related to the $HOME setting 
[11:47] <popey> ogra_: is it easy to patch the tests to prove that?
[11:47] <ogra_> popey, i tried but then it cant find the click anymore
[11:47] <popey> just replace ~ with /home/phablet ?
[11:47] <popey> in the filemanager tests only
[11:48] <ogra_> autopilot/filemanager/tests/__init__.py
[11:48] <popey> yes
[11:48] <ogra_> there is a line setting it
[11:48] <popey> i fudged $HOME in there and it failed differently
[11:48] <popey> which is obviously wrong
[11:48] <popey> needs to be the tmp home ?
[11:48] <ogra_> conditionally based on if the package is click or not
[11:48] <ogra_> right
[11:49] <ogra_>         if self.test_type == 'click':
[11:49] <ogra_>             self.useFixture(toolkit_fixtures.InitctlEnvironmentVariable(
[11:49] <ogra_>                             HOME=temp_dir))
[11:49] <ogra_>         else:
[11:49] <ogra_>             self.useFixture(fixtures.EnvironmentVariable('HOME',
[11:49] <ogra_>                                                          newvalue=temp_dir))
[11:49] <ogra_> i was trying to make it set it in both places for the click case
[11:50] <ogra_> but that ends in  WARNING **: Unable to find keyfile for application 'com.ubuntu.filemanager_filemanager_0.3.193'
[11:51] <ogra_> what the app code would need would be reading the env var and putting it in there ... but i'm not sure QMl can do that easily
[11:51] <ogra_> ("there" being the hardcoded places(
[11:52] <dbarth> sil2100: o/ hi, i'm marking silo 14 has verified
[11:53] <sil2100> dbarth: o/ Ok, let me check that
[11:53] <dbarth> for reference, this requires 2 updates to pre-installed click packages to fully fix the issue
[11:53] <dbarth> 1 gmail webapp update (correcting an extra url path)
[11:53] <dbarth> and 1 faceook webapp update (to avoid a UX regression on switching to external links)
[11:53] <dbarth> both webapps have been pushed to the store for review
[11:54] <dbarth> you can land silo 14 as soon as you want (it won't break the apps), but you may want to get those 2 other updates in the same image though
[11:54] <ogra_> Mirv, see my conversation with popey ... is there any easy way to use $HOME in QML without having a C++ provider that reads it first ?
[11:56] <davmor2> sil2100: 83 is looking as good as any I've seen recently
[11:56] <sil2100> davmor2: great to hear that :)
[11:57] <davmor2> sil2100: however phone still dies with no warnings
[11:57] <ogra_> dies ?
[11:58] <ogra_> when, how ?
[11:58] <sil2100> davmor2: awww... well, we didn't expect this to be fixed, we just *hoped* it has improved with the indicator landing
[11:58] <davmor2> ogra_: when there is suddenly no battery left
[11:58] <ogra_> oh
[11:58] <sil2100> ogra_: I think davmor2 means the no-battery-death
[11:58] <ogra_> yeah
[11:58] <ogra_> thats expected
[11:58] <ogra_> right, we have bogs open for that
[11:58] <ogra_> *bugs too
[11:58] <popey> has anyone else noticed nm clinging onto the furthest access point away?
[11:58] <popey> mine is always attached to the farthest one when i boot up
[11:58] <ogra_> i thought some other ddeath we dont know about yet
[11:59] <ogra_> popey, talk to cyphermox
[12:00] <davmor2> popey: which connection did you setup first it will maybe stay connected to that one as preferred
[12:00] <popey> no idea
[12:01] <popey> from the dates in /etc/NetworkManager/system-connections it wasn't the oldest, but newest
[12:11] <Mirv> ogra_: maybe ask on #ubuntu-app-devel
[12:11] <Mirv> the SDK guys might know
[12:11] <ogra_> yeah, will do
[12:19] <Mirv> uh, new webbrowser-app, I have to be again trigger-happy in Qt PPA once it has been m&c:d
[12:32] <Mirv> some news from Qt 5.3 land: address-book now passes completely (but the fix should still land for real too). calendar app seems to be duplicate of current image bug, so not really new.
[12:33] <Mirv> sil2100: is there a bug tracking the calendar app failures, I don't see it on the landing team mails?
[12:33] <sil2100> Mirv: I think we didn't add that yet, it wasn't happening all the time last week
[12:34] <sil2100> Mirv: but a bug should be present, one moment
[12:34] <Mirv> it seems there are several bugs about it
[12:34] <Mirv> not sure if there's master bug
[12:35] <Mirv> but well, bug #1329821 matches this newest run exactly so I can mark my bug a duplicate of that
[12:35] <sil2100> Mirv: sadly there is no bug for this one failure, but I guess there is one root cause of all of them
[12:36] <Mirv> yeah probably
[12:36] <Mirv> there's 6 separate bugs at https://bugs.launchpad.net/ubuntu-calendar-app/+bugs?orderby=-importance&memo=75&start=75
[12:40] <Mirv> popey: do you happen to have your qt 5.2 device within reach? I think that blabble would be worth testing there since according to automated testing it doesn't work there either.
[12:44] <popey> blabble works fine on 5.2
[12:44]  * sil2100 goes prepare lunch
[12:44] <Mirv> popey: ok, can you update bug #1327667 accordingly? it was just that it had a crash folder also on the stock image testing tarballs of yours.
[12:45] <Mirv> popey: and to ping bomb you more, maybe test inews again bug #1327680 since I just marked it as Invalid, plus railroad & blackjack which I marked as incomplete earlier since they seemed to work for me bug #1327595
[12:48] <Mirv> elopio: hi! zsombi & co were interested in whether you completed the UITK testing successfully, as it's currently marked as not tested and therefore not getting published?
[12:50] <Mirv> elopio: well zoltan is mentioning that he'd consider rebuilding from newest staging and testing again
[12:52] <Mirv> elopio: aaand he's doing it (updating the MP with latest staging including your swipe fixes)
[12:52] <Mirv> elopio: the Qt 5.3 testing btw showed some swipe failures at http://q-jenkins.ubuntu-ci:8080/job/qt-release-gatekeeper/1/#showFailuresLink - maybe your branch would fix those too?
[12:56] <ogra_> sil2100, did oyu notice the ubuntu-touch-meta upload ? i think we should have an image build soon so we can see what the language pack switch gained us
[13:00] <sil2100> ogra_: oh, right, it was around noon
[13:00] <sil2100> Damn missed that one completely
[13:00] <sil2100> ogra_: yeah, an image would be good now - I guess there's nothing specific we're waiting for right now
[13:00] <sil2100> Just normal landings happening
[13:00] <popey> Mirv: 5.3 call?
[13:00] <sil2100> So you can kick a new image
[13:51] <ogra_> sil2100, image triggered (sorry, had a distracting phone call)
[13:57] <ogra_> popey, FYI ... a bootchart should always use all available CPu if possible to boot as fast as possible ... also take a look at the disk how it loads all files very early in the boot due to ureadahead http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-utopic-83.png
[13:59] <ogra_> (the interesting bits in a bootchart are the two graphs at the top ... the rest is mostly just there to confuse you ;) )
[13:59] <imgbot> [14:06] <mhr3> sil2100, my latest silo request will probably take a while to land, consider it non-blocking, i'll keep rebuilding the components
[14:07] <mhr3> sil2100, will also need a few reconfs
[14:08] <sil2100> Ok
[14:08] <Mirv> boiko: hi, are you landing the telephony-service/address-book-app today? it'd be nice to have for Qt 5.3
[14:09] <sil2100> hmm.. unity8 again ;p Grrr
[14:09] <sil2100> But since you promise to take care of it, I give you an override
[14:10] <boiko> Mirv: any specific landing you need? we are landing the first round of new designs today
[14:20] <elopio> fginther: maybe, it will be useful to have another gatekeeper job like the qt one for the toolkit. What do you say?
[14:22] <fginther> elopio, let me have a conversation with the rest of the team first to see where we are on capacity and usage, etc.
[14:22] <Mirv> boiko: landing-001, specifically https://code.launchpad.net/~renatofilho/telephony-service/fix-phonenumber-crash/+merge/222797
[14:22] <Mirv> boiko: I've made manual build of that branch to the Qt 5.3 PPA which fixes all address book app issues on 5.3, but getting it landed to archives would help in getting rid of that temporary build
[14:27] <elopio> fginther: yes, thanks.
[14:28] <boiko> Mirv: that's being tested, this will land soon
[14:29] <Mirv> boiko: thanks, great
[14:32] <mhr3> sil2100, so, where's my silo?
[14:33] <sil2100> mhr3: hmmm, one moment, I guess the spreadsheet might have not auto-updated itself
[14:33] <sil2100> Let me check
[15:14] <imgbot> [15:14] <imgbot> [15:15] <sil2100> o/
[15:25] <ogra_> 40MB fat lost in the tarball \o/
[15:25] <ogra_> (from 508 down to 470MB)
[15:25] <davmor2> ogra_: that or it's forgotten libs ;)
[15:26] <ogra_> nah, its dropped desktop translations
[15:35] <sil2100> I love whenever the image is slimmed down
[15:49] <elopio> ping doanac. It seems that this crash was not traced:
[15:49] <elopio> http://ci.ubuntu.com/smokeng/utopic/touch/mako/78:20140611.1:20140530/8530/unity8/1241528/
[15:49] <elopio> is jenkins configured to do whoopsie-upload-all before storing the artifacts?
[15:50] <doanac> elopio: we should upload any .crash files that are generated on the target. I see a link to a crash file: http://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/282/artifact/clientlogs/unity8/_usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash/*view*/
[15:51] <doanac> is that not what you are needing?
[15:53] <elopio> doanac: no. Saviq says that we need to trace that crash on the device that generated it.
[15:53] <Saviq> elopio, not exactly the same device, but at least one with the same packages on it
[15:53] <elopio> " otherwise the .crash file is missing details"
[15:54] <Saviq> yeah, it doesn't even contain the version of the package
[15:54] <Saviq> or the symbols that are otherwise available on device
[15:55] <doanac> elopio: Saviq: k. I think we may need to update phablet-test-run for this. I believe we call phablet-test-run and just tell it to pull everything under /var/crash
[15:55] <Saviq> doanac, at some point at least it also did whoopsie-upload-all
[15:55] <Saviq> doanac, which would have processed the files and upload them to errors.u.c
[15:56] <doanac> Saviq: okay. looking at p-t-r now, there's no reference to whoopsie.
[15:56] <doanac> i can take a stab at an MP today. i just need to call "whoopsie-upload-all" after running a test?
[15:57] <Saviq> doanac, afaict, yes, but probably make sure to time it out in case there's network failure or something of the sort
[15:57] <doanac> Saviq: ack - good point.
[15:57] <Saviq> or well, jenkins would time it out anyway, wouldn't it
[15:57] <doanac> yeah, but jenkins has a big timeout. we should make this a little more fine grained
[15:57] <Saviq> yup
[15:57] <doanac> Saviq: any ideas on what a sensible timeout would be?
[15:58] <Saviq> doanac, I'd say a few minutes
[15:58] <doanac> k. i'll see what i can do. thanks
[15:58] <Saviq> doanac, just try crashing unity8
[15:58] <Saviq> (i.e. kill -11 `pidof unity8`)
[15:58] <doanac> smart :)
[15:58] <Saviq> and see how long that takes to complete whoopsie-upload-all, multiply by 10
[15:58] <Saviq> there's your number
[15:59] <elopio> thanks Saviq and doanac.
[15:59] <elopio> Saviq: I'll mark the bug as incomplete waiting for it to happen again after doanac's tracing.
[15:59] <Saviq> tx
[16:06] <dbarth> hi again
[16:06] <dbarth> i updated silo 11 / line 21 to add another bugfix for the same target project
[16:06] <dbarth> can i get a silo reconfig?
[16:07] <dbarth> sil2100 ^^ if still in your shift
[16:08] <robru> dbarth, on it
[16:08] <dbarth> thanks robru
[16:09] <robru> dbarth, you're welcome! Ok, it's done, go ahead with build
[16:09] <dbarth> cool
[16:12]  * popey pokes davmor2 with hangout chat
[16:13] <mhr3> robru, can i get reconf of 014?
[16:14] <robru> yes!
[16:18] <robru> mhr3, alright, you are go for build
[16:18] <mhr3> robru, ty
[16:18] <robru> mhr3, you're welcome
[16:19] <sil2100> popey: thanks for the presentation, this design looks really nice
[16:19] <robru> mhr3, just to let you know, I *just* pulled the trigger on a unity8 publish job, so you'll have to rebuild unity8 in a couple hours once that fully lands & merges
[16:19] <davmor2> popey: so I can't repro that swiping either way which way triggered it for you?
[16:19] <mhr3> robru, sure, i know
[16:19] <robru> k
[16:21] <popey> davmor2: lock phone, unlock phone
[16:21] <popey> sil2100: np
[16:26] <robru> slangasek, hey, I lost track of the landing rotation, is it my day today?
[16:27] <slangasek> robru: I was just asking that myself :)
[16:27] <slangasek> robru: was the rotation you, barry, stgraber?
[16:27] <slangasek> if so, I think it's stgraber's
[16:27] <robru> slangasek, yeah. barry did it friday. makes sense
[16:27] <robru> slangasek, we should document this somewhere ;-)
[16:27] <slangasek> (and sorry for not calendaring this up)
[16:27] <barry> yeah, a calendar would be nice :)
[16:28] <barry> have fun with "every 3 other business days" in gcal :)
[16:28] <robru> yeah that sounds like a pain.
[16:28] <robru> barry, on the other hand "every 3 other days" is pretty easy to do.... ;-)
[16:29] <barry> robru: true.  i did that in my own canonical calendar, and then adjusted for business days until the end of june
[16:29] <slangasek> barry: nah, I'll just do a SPREADSHEET
[16:29] <robru> slangasek, oh yes please, we need more spreadsheets ;-)
[16:29] <slangasek> I knew you'd approve
[16:30] <robru> slangasek, make sure you load it with scripts that query and poll other services, so we can push it to gdocs limit and have it go down constantly...
[16:30] <barry> slangasek: also make sure it uses some obscure @c.c address for us so we'll have no access and won't be able to make google's corporate login work for unknown reasons
[16:31] <barry> (monday is snark day)
[16:33] <sil2100> o/
[16:33] <robru> barry, ugh, I just tried making my own calendar, but when I adjust each week, it doesn't adjust the ones after the one I adjusted, making the repeat almost totally useless.
[16:33] <sil2100> slangasek: is the rotation thing documented anywhere? Would be nice to know who's currently 'on'
[16:34] <slangasek> sil2100: no, that's the current discussion topic :-)
[16:34] <robru> slangasek, yeah could we just have like a wiki page for this?
[16:34] <slangasek> robru: that would be fine.  You want to set one up?
[16:34] <robru> slangasek, yes! ;-)
[16:34] <slangasek> ta ;)
[16:35] <slangasek> I clearly was overthinking this and should've just gone with a wiki page from the start
[16:35] <sil2100> slangasek, robru: set it up under citrain/ I guess?
[16:35] <robru> sil2100, yep, on it
[16:35] <sil2100> Thanks ;)
[16:36] <sil2100> Oh! Wait, actually...
[16:36] <sil2100> robru: https://wiki.ubuntu.com/citrain/LandingTeam <- maybe a section could be added here?
[16:36] <sil2100> Or you think a separate page would be better?
[16:36] <robru> sil2100, oh I already started a separate page
[16:36] <slangasek> oops, well, too late now, wikis are immutable
[16:36] <sil2100> Ok, let's link it to this page later on
[16:36] <sil2100> slangasek: :D
[16:36] <robru> sil2100, nah I can put it in there
[16:38] <robru> sil2100, slangasek : https://wiki.ubuntu.com/citrain/LandingTeam ok here's this week for now
[16:38] <robru> we can expand it as we go
[16:38] <slangasek> robru: thanks :)
[16:39] <robru> slangasek, thanks for not making a spreadsheet ;-)
[16:39] <slangasek> sil2100: this does kind of leave you with no relief, though, which wasn't quite what I had in mind
[16:39] <slangasek> sil2100: does the fact that stgraber+barry start 3h earlier help?
[16:39] <slangasek> (earlier than robru)
[16:40] <robru> slangasek, well, it was always that way, now it's just codified.
[16:40] <slangasek> right
[16:40] <sil2100> slangasek: hey, yeah :) Of course it's helpful, good for a beginning!
[16:40] <robru> slangasek, I was assuming that at some point some EU Foundations Team members would rotate in for sil2100
[16:49] <robru> brb, grabbing some breakfast
[16:59] <sil2100> ogra_: !
[17:00] <sil2100> ogra_: could you promote #83?
[17:00]  * sil2100 noticed that he sent the e-mail by mistake without ogra_ pressing the promotion button yet
[17:00] <ogra_> heh, perfect timing to ask in the half time break :)
[17:00] <sil2100> :P
[17:00] <sil2100> Quick! Everyone is waiting for it already!
[17:00] <sil2100> The e-mail is ouuut!
[17:00] <ogra_> haha
[17:00]  * sil2100 panics
[17:00] <ogra_> promotion script running
[17:01] <ogra_> [17:02]  * ogra_ goes back to the game
[17:03] <sil2100> \o/
[17:03] <sil2100> ;)
[17:03] <sil2100> Have fun
[17:05] <sil2100> ogra_: https://plus.google.com/109159869108744115904/posts/SzyTXh8jkzA <- for after the match ;)
[17:05] <popey> yay!
[17:12] <sil2100> See you tomorrow o/
[17:18] <robru> mhr3, a ha, nice job merging 12 before building 14 ;-)
[17:23] <robru> barry, you got 12 and 17
[17:23] <robru> oops
[17:23] <robru> I mean, bfiller you got 12 and 17
[17:23] <bfiller> robru: thanks!
[17:24] <robru> bfiller, you're welcome!
[17:32] <kgunn> robru: i got something happening i don't quite understand
[17:32] <robru> kgunn, what's up?
[17:32] <kgunn> robru: so we built mir & its rdepends...but unity-mir wouldn't install, kept locking for old mir...so i said "i'll show you"...and force rebuild
[17:33] <kgunn> on unity-mir only, but then
[17:33] <kgunn> https://launchpadlibrarian.net/177724734/buildlog_ubuntu-utopic-i386.unity-mir_0.4%2B14.10.20140616.3-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:33] <kgunn> it fails to build, looking for platform-api v2 ...but platform-api v2 is in that ppa!
[17:33] <kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+packages
[17:33] <robru> hmmmm
[17:34] <kgunn> robru: maybe it doesn't work how i think it works?...anyway...open to ideas
[17:34] <robru> kgunn, yeah that error message is confusing, usually it's caused by some other more distant dep being broken somehow
[17:35] <robru> trying to remember how to troubleshoot that
[17:35] <kgunn> robru: stranger still....it actually built just fine earlier this morning
[17:35] <kgunn> with no complaints
[17:35] <robru> kgunn, yeah, could be something landed in between to break it
[17:36] <kgunn> robru: force rebuild all ?
[17:36] <kgunn> should i
[17:36] <robru> kgunn hang on
[17:36] <kgunn> ok
[17:36]  * kgunn is gonna go run/workout, bbiab
[17:37]  * camako will take over from kgunn
[17:39] <robru> camako, yeah, try a full rebuild, but I'm still looking at this
[17:39] <camako> robru, ok will do
[17:42] <elopio> Only three errors on #84 :D
[17:43] <elopio> things are getting easier.
[17:45] <robru> mhr3, you got 18
[17:46] <mhr3> thx
[17:58] <ogra_> elopio, oh, wow !!
[18:08] <camako> robru, force_build failed.... same issue
[18:08] <camako> kgunn ^^
[18:08] <robru> bah
[18:09] <elopio> ping robru. I'm testing silo 006 but with phablet-click-test-setup I get:
[18:09] <elopio> pull-lp-source: Error: Failed to download: https://launchpad.net/ubuntu/+archive/primary/+files/ubuntu-ui-toolkit_0.1.47+14.10.20140616-0ubuntu1.dsc: 404 Not Found
[18:10] <elopio> what's primary? shouldn't it use the path to the silo?
[18:11] <robru> elopio: phablet-click-test-setup? what?
[18:11] <elopio> robru: anything. phablet-click-test-setup --click com.ubuntu.calculator;
[18:11] <robru> elopio: no, phablet-click-test-setup doesn't know anything about silos, it tries to download the tests from the archive. but they're not in the archive so it's only in the silo.
[18:12] <Mirv> elopio: edit phablet-click-test-setup and remove the line regarding basic_packages that tells about ui-toolkit. you can install the -autopilot .deb package from PPA instead.
[18:12]  * Mirv waves good night
[18:12] <Mirv> (bug #1280279)
[18:12] <robru> elopio: I think you need to run phablet-click-test-setup before installing the silo contents. you'll have the older version of the tests but it'll test the new package
[18:12] <Mirv> or robru's version, run it before indeed
[18:12] <robru> mirv, thanks
[18:13] <elopio> Mirv: thanks.
[18:13] <robru> mirv, elopio, depends if you're testing the tests themselves, or if you're testing the code. mirv's way tests the newest tests, my way runs old tests on new app code
[18:14] <robru> camako: are you sure it's the same error? looks different to me, maybe I'm not looking at the right thing
[18:29] <robru> camako sorry for the delay, infinity fixed it, should be working now
[18:33] <camako> robru, yes it was the same error... Should I kick another rebuil_all?
[18:34] <robru> camako: no
[18:38] <camako> robru, last build failed for mir and unity-mir... So build those two then?
[18:38] <robru> camako: no
[18:38] <camako> ?
[18:39] <robru> camako: those two failed waiting for platform-api, platform-api failed waiting for something else. platform-api needs to get fixed first
[18:41] <robru> camako: sorry I'm doing like 10 things right now. What I'm being told is that doing a rebuild from CI Train won't fix this because that causes a new upload that will fail in the same way. You have to dig into the PPA and trigger the rebuild from there
[18:41] <robru> camako: https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+build/6103560 so if you click retry from here, it should work
[18:42] <robru> but wait
[18:42] <robru> infinity-already did unity-mir
[18:43] <camako> robru, in the morning everything built successfully
[18:43] <camako> but we had package installation problems
[18:44] <infinity> unity-mir is fine now.  Retrying mir/armhf, but the failure there looked a bit more suspicious.  We'll see how it fares on a second go.
[18:47] <camako> infinity, do I need to start the build or you started already?
[18:48] <infinity> camako: Retrying the build is saner than reuploading.
[18:48] <infinity> camako: The build is in progress right now.
[18:48] <infinity> https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+build/6103560
[18:48] <camako> infinity, thanks...
[18:49] <infinity> The failure on this one was a failure to link, though, which may well be an actual bug, not a package skew issue.  We'll see.
[18:49] <camako> ok
[18:50] <infinity> And same failure again.
[18:50] <infinity> CMakeFiles/mirprotobuf.dir/google_protobuf_guard.cpp.o: In function `void std::call_once<void (&)()>(std::once_flag&, void (&)())':
[18:50] <infinity> /usr/include/c++/4.8/mutex:779: undefined reference to `std::__get_once_mutex()'
[18:50] <infinity> /usr/include/c++/4.8/mutex:783: undefined reference to `std::__set_once_functor_lock_ptr(std::unique_lock<std::mutex>*)'
[18:50] <infinity> /usr/include/c++/4.8/mutex:790: undefined reference to `std::__set_once_functor_lock_ptr(std::unique_lock<std::mutex>*)'
[18:51] <infinity> CMakeFiles/mirprotobuf.dir/google_protobuf_guard.cpp.o: In function `__gthread_mutex_unlock':
[18:51] <infinity> /usr/include/arm-linux-gnueabihf/c++/4.8/bits/gthr-default.h:778: undefined reference to `std::__once_functor'
[18:51] <infinity> collect2: error: ld returned 1 exit status
[18:51] <infinity> src/shared/protobuf/CMakeFiles/mirprotobuf.dir/build.make:153: recipe for target 'lib/libmirprotobuf.so.0' failed
[18:51] <infinity> make[3]: *** [lib/libmirprotobuf.so.0] Error 1
[18:51]  * camako hasn't seen this error before... will look into it
[19:02] <camako> kgunn, ^^ .... cross compile works... has to do with cross vs native incompatibility... Dunno why built ok earlier tho..
[19:08] <rsalveti> robru: can I get a landing for line 40?
[19:08] <rsalveti> *silo
[19:08] <robru> rsalveti sure
[19:09] <robru> rsalveti: you got 19
[19:09] <rsalveti> robru: thanks
[19:09] <robru> rsalveti: you're welcome!
[19:14] <robru> brb, need to reboot
[19:17] <kgunn> camako: i'm back, gonna reboot real quick
[19:31] <robru> damn  my system is just glitching out today
[19:37] <slangasek> infinity: so, where'd you get to in this unity-mir investigation?
[19:39] <slangasek> I see that g++ 4.9.0-3ubuntu5 (depends: g++-4.8) is used for the build; could it be that g++-4.8 headers are incompatible with new libstdc++?
[19:42] <infinity> slangasek: s/unity-mir/mir/ I assume?  After making unity-mir happy (that was just version skew in the PPA), mir was FTBFS on armhf, which I punted to upstream.
[19:43] <infinity> slangasek: It's entirely possible the g++ headers are incompatible on ARM, worth looking into.
[19:44] <infinity> slangasek: Given that GCC only guarantees backward compatibility at runtime, not compile time, I wouldn't put it past them to have changed removed/mangled something.
[19:44] <infinity> s/changed//
[19:46] <slangasek> infinity: right, mir.  Which upstream did you punt this to?
[19:47] <infinity> slangasek: camako and kgunn were discussing it above (ish).
[19:47] <slangasek> infinity: so 'mir' upstream
[19:47] <infinity> slangasek: Right.
[19:48] <slangasek> infinity: which is how I wound up back here. ;)
[19:48] <infinity> Whee!
[19:49] <slangasek> fwiw, __get_once_mutex() is bounded by #ifndef _GLIBCXX_HAVE_TLS
[19:49] <slangasek> which I'm pretty sure we have
[19:50] <infinity> slangasek: We certainly should.
[19:51] <infinity> slangasek: I'd done no investigation aside from highlighting the problematic lines in the build log.
[19:51] <infinity> slangasek: Is this being punted back to us as "your toolchain sucks, yo'?
[19:52] <infinity> s/'/"/
[19:52] <slangasek> infinity: nothing so concrete; kgunn had just asked if gcc-4.9 had settled
[19:52] <slangasek> and this may well be fallout from that; trying to reproduce the problem now
[19:53] <infinity> slangasek: Yeah, has it?  I'd love to switch back. :P
[19:53] <slangasek> infinity: no, you get an orderly transition of the C++11-using packages; talk to tvoss if you want to volunteer to help :)
[19:54] <infinity> slangasek: Ahh, so, we'll transition C++-11 libs first, then flip the default compiler again?
[19:54] <slangasek> yes
[19:54]  * infinity nods.
[19:54] <infinity> That shouldn't take long, in theory.  Unless spreadsheets slow us down. :P
[20:00] <mhr3> robru, ping?
[20:00] <mhr3> robru, can you try to just rebuild https://launchpad.net/~ci-train-ppa-service/+archive/landing-018/+build/6103541 pls?
[20:00] <mhr3> there's some super weird error
[20:01] <robru> checking
[20:01] <robru> infinity, slangasek hey guys, is this related ^^ looks similar to me
[20:03] <mhr3> is the new libstdc++ now built with 4.9?
[20:03] <infinity> robru: That's the same error, yes.
[20:03] <infinity> mhr3: Yeah, it is.
[20:03] <mhr3> that explains it then
[20:04] <mhr3> robru, so i guess no need to rebuild it until there's a proper fix
[20:04] <robru> mhr3, yeah
[20:09] <boiko> robru: hi, I was looking at the update excuses, and there it says dialer-app was not considered, anything I should do?
[20:09] <boiko> robru: this is regarding landing-001
[20:10] <robru> boiko, yeah you should ping pitti about that: https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1330360
[20:10] <robru> boiko, or I guess you could just add that one line to your debian/control like pitti wants, and then drop that block-proposed tag from that bug, and then republish
[20:12] <boiko> robru: it seems he filled the bug as an example, I don't think he really meant to block dialer-app, /me trying to avoid the trouble of having to republish
[20:13] <boiko> robru: as pitti is not around, I think it might be easier if I just add that tag to debian/control
[20:13] <robru> boiko, well it won't get through proposed as long as block-proposed is on the bug. so delete that tag and then it'll migrate. but make sure you talk to pitti about it, because you guys are just stepping on each other's toes now, it's not good communication
[20:13] <robru> yeah
[20:13] <boiko> robru: should I do anything on the silo? other than rebuilding dialer-app when I finish the changes
[20:14] <robru> boiko, hmm, nope. silo is fine. you just need to rebuild to get that new line in the package, then I'll re-publish.
[20:14] <boiko> robru: ok, should I also mark the change as fixing the bug?
[20:16] <robru> boiko, ... yes
[20:16] <robru> boiko, no wait
[20:17] <robru> boiko, http://bazaar.launchpad.net/+branch/dialer-app/revision/151 pitti pushed to your trunk already
[20:18] <robru> boiko, I don't know what the hell is going on. pitti made a "release" here: http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/revision/152 but that never made it into ubuntu
[20:18] <slangasek> robru, infinity, mhr3: what is this '__once_functor'?  I don't find that in the /usr/include/c++/4.8/functional in the archive
[20:19] <robru> slangasek, never heard of it.
[20:19] <robru> but I'm not a C++ guy, no idea
[20:19] <slangasek> ok; I don't think we should assume this is related to the other mir failure, just yet
[20:20] <slangasek> oh, although std::__once_functor does appear in both build failures (it's just not the first failure, on the mir build)
[20:20] <robru> slangasek, well in both cases the build only failed on armhf, other arches built fine. so it seems like there's something wrong with just that arch
[20:21] <robru> boiko, don't rebuild anything, I'm going to drop that tag and let your package migrate.
[20:21] <boiko> robru: ok, thanks!
[20:22] <dobey> robru: the problem is new libstdc++ which is built against gcc 4.9
[20:22] <dobey> robru: so things trying to link it go boom
[20:22] <dobey> slangasek: ^^
[20:23] <slangasek> robru: yes.  I'm looking now to see if the build failure is reproducible with a cross-build, given that none of the libstdc++s here show those symbols
[20:23] <slangasek> dobey: er, I'm well aware of the current state of the toolchains; "go boom" is not what is supposed to happen
[20:27] <kgunn> slangasek: mir cross compile was fine
[20:27] <kgunn> i just tried native compile locally, and it go boom
[20:27] <kgunn> on top of devel-proposed
[20:28] <dobey> kgunn: because you have libstdc++6 4.9, and gcc 4.8, i guess
[20:28] <dobey> that is what happened in the PPA for unity-scope-click silo anyway
[20:29] <slangasek> dobey: yes, and *that's supposed to be supported*; we need to get to the bottom of why this is causing a build failure
[20:29] <dobey> slangasek: the problem is that it has libstdc++6-4.9 and libstdc++4.8-dev, but not libstdc++6-4.8
[20:29] <dobey> afaict
[20:29] <kgunn> yeah...that'd make sense
[20:30] <slangasek> hmm
[20:31] <dobey> seems libstdc++-4.8-dev depends only on "libstdc++6" which i guess is pulling -4.9 instead of -4.8 for some reason
[20:31] <slangasek> that could be; though I still don't see these symbols in any version of libstdc++
[20:31] <slangasek> yes, it only depends on libstdc++6 because that's supposed to work
[20:31] <slangasek> there is no -4.8 version of the library anymore
[20:34] <kgunn> slangasek: now's probably not the time to be asking such things...but how come there's no 4.8 version available to downgrade to ?
[20:34]  * kgunn figures there's some special reason
[20:34] <slangasek> kgunn: because library transitions are one way
[20:34] <slangasek> and the soname didn't change
[20:34] <dobey> slangasek: yay templates
[20:34] <slangasek> and it didn't change because the ABI didn't change
[20:35] <slangasek> dobey: templates don't generate undefined references
[20:35] <kgunn> slangasek: ah got it....ABI didn't change _allegedly_ :)
[20:35] <slangasek> kgunn: right ;)  and from everything I'm seeing so far, this failure is not due to an ABI chnage
[20:35] <slangasek> change
[20:36] <dobey> ugh, the bzr branch just has gcc tar.xz inside it :(
[20:49] <boiko> robru: so, will the migration happen on its own now for dialer-app?
[20:49] <robru> boiko, it should as far as I know
[20:49] <boiko> robru: ok
[20:49] <robru> (which, I should clarify, isn't very far)
[20:49] <boiko> robru: :)
[20:50] <boiko> robru: update excuses still say it won't migrate because of that bug
[20:50] <boiko> robru: but I don't know much about this either
[20:50] <robru> infinity, regarding ^^ 'block-proposed' tag on a bug, is it enough to delete that tag, or does anything else special need to happen?
[20:56] <slangasek> robru: rather than closing the bug?
[20:56] <slangasek> removing the tag will automatically have the effect, but I'd be wary of doing it this way
[20:57] <slangasek> as that implies the bug that someone marked as a blocker hasn't been fixed yet
[20:57] <robru> slangasek, right, well technically it hasn't.
[20:57] <robru> ;-)
[20:58] <robru> brb, phone
[21:01] <robru> slangasek, sorry
[21:02] <robru> slangasek, so the situation is that, pitti did a push to trunk + manual upload (fine) but then blocked his manual upload with this bug, and now that is blocking boiko, who also wants to do a release right now
[21:03] <robru> slangasek, it was poorly coordinated, everybody stepping on everybody's feet, so I figured I'd just unblock and let boiko go ahead. the only problem is that translations in dialer-app will regress for an image or two, but it'll sort itself out after a couple days, didn't seem worth blocking to me
[21:03] <robru> slangasek, so the bug should stay open, because this translation issue is real, but I didn't want to block boiko's landing
[21:08] <robru> slangasek, but https://wiki.ubuntu.com/ProposedMigration doesn't explain how to unblock such a bug, you say removing the tag is enough, but it hasn't migrated yet
[21:32] <infinity> robru: Removing the tag is enough.
[21:33] <infinity> robru: proposed-migration just hasn't run (or completed) since you removed the tag.  Note the datestamp at the top.
[21:34] <robru> infinity, ok, thanks. thought it ran every half hour or so
[21:34] <infinity> robru: It runs whenever proposed changes, which is a bug/misfeature I'm going to fix.
[21:34] <infinity> robru: But it also sometimes runs a long time, if a big transition is confusing it.
[21:34] <robru> ah
[21:34] <infinity> robru: Not sure if the current delay is the former or the latter, just got back from lunch and I'm multitasking in a meeting.
[21:35] <robru> infinity, ok well this isn't a huge rush if you're busy
[21:36] <robru> just whenever ;-)
[21:36]  * infinity nods.
[21:45] <cjwatson> robru: live logs are in http://people.canonical.com/~ubuntu-archive/proposed-migration/utopic/ so you can tell the difference between "hasn't run for ages" and "currently in the middle of massive run"
[21:45] <cjwatson> in case that helps
[21:45] <robru> cjwatson, it does, thanks
[21:45] <robru> cjwatson, err, except that 404s
[21:45] <robru> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/utopic/
[21:46] <robru> ;-)
[21:46] <cjwatson> Er right sorry
[21:46] <cjwatson> That one
[21:46] <cjwatson> Looks like the latest run finished a minute ago
[21:46] <robru> boiko_, ah, excellent ^ dialer-app is valid now
[21:47] <cjwatson> And migrated click-apparmor and dialer-app
[21:48] <cjwatson> 34 minutes between starts of last two runs, sassenfrassen, must prod mvo to finish getting ftparchive source caching deployed
[21:51] <boiko_> robru: cjwatson: thanks! :)
[21:53] <robru> boiko_, you're welcome
[23:23] <slangasek> robru, kgunn: I can't reproduce this mir ftbfs at all on the utopic porter machine
[23:23] <slangasek> I'm giving it a retry
[23:24] <slangasek> (tested with an up-to-date porter chroot on shedir, using both the mir from the archive and the one from the ppa)
[23:33] <slangasek> robru, kgunn: ah - I believe this was an issue fixed upstream in gcc-4.9 between 4.9.0-6 and 4.9.0-7, and doko hadn't flagged it because it was part of the upstream update rather than anything he knew broke mir specifically
[23:33] <slangasek> so it looks like it's fixed as of today, and armhf was the only arch FTBFS because it's the slowest to build
[23:35] <slangasek> I can certainly confirm that the latest libstdc++6 does have the symbols in question
[23:36] <infinity> slangasek: That doesn't make much sense, as none of the arches built against 4.9.0-7, since it's in proposed.
[23:36] <robru> slangasek, so a rebuild should work but it was just slightly out of date earlier today?
[23:36] <infinity> slangasek: Unless the bug only existed on armhf in the first place.
[23:36] <robru> slangasek, yeah the silos have -proposed disabled
[23:37] <slangasek> infinity: ah; could be arch-specific, to be sure
[23:37] <slangasek> robru: but in that case, see previous conversation with infinity re: -proposed should be enabled
[23:37] <josharenson> cjohnston, is there an easy (correct) way to add a canonistack machine to the ci lab vpn?
[23:37] <infinity> Anyhow, I have a proper reproduction env here, I'll try a build without proposed, then enable proposed and upgrade the toolchain and try again.
[23:38] <robru> slangasek, is that in this channel? I don't see it
[23:38] <infinity> robru: You and I very briefly brought it up on #distro.
[23:39] <robru> infinity, I didn't conclude from that exchange that I was supposed to enable -proposed
[23:39] <robru> thought you were just making an observation
[23:39] <infinity> robru: Well, that was more of a general process issue, in that proposed should always be enabled.  There was no indication that it would fix THIS issue.
[23:39] <slangasek> robru: you shouldn't immediately enable it on infinity's say-so ;), but this is an inconsistency with how we do all builds for the archive
[23:40] <slangasek> and in this case it turns out the inconsistency he noticed stands a good chance of being the cause of the build failures
[23:41] <robru> slangasek, so, to be clear, are you telling me to enable proposed for the silos? Because that's a thing I can do if necessary.
[23:41] <infinity> The uniqeuness in snowflakery of ci-train (and airline) customers needs to be minimized, especially as more and more people are asked to use it.
[23:41] <slangasek> robru: if you could do it for *this* silo, at least temporarily, that should let us unblock
[23:42] <infinity> slangasek: I'm verifying that claim right now, BTW.
[23:42] <slangasek> robru: and then we should get buy-in from the rest of the team about making this change more generally/permanently
[23:42] <robru> slangasek, can you explain to me why this is just a temporary change and not a permanent one for all silos? I never understood why -proposed wsan't enabled originally or what the implications are
[23:42] <robru> ok
[23:42] <slangasek> robru: because I don't know who set it up this way initially and don't want to be in a revert war :)
[23:43] <robru> slangasek, heh, ok, well 16 now has proposed enabled, should I start a rebuild?
[23:43] <slangasek> robru: yes, please!
[23:43] <infinity> robru: reTRY, not rebuild.
[23:43] <infinity> (Assuming rebuild means what I think it means)
[23:43] <robru> right, that one
[23:44] <slangasek> infinity: and it looks like gcc-4.9 proposed-migration is merely held up by the lack of gerbil chow for the powerpc buildds
[23:44] <robru> slangasek, brb, off to buy some more gerbil chow
[23:44] <infinity> slangasek: I could easily move that build to sagari, I hadn't expected there to be any urgency.
[23:45] <slangasek> robru: this also impacted the unity-scope-click build failure, so when you have a chance you probably want to do the same for that silo
[23:45] <slangasek> infinity: it's 14h in already, is it worth it now?
[23:45] <robru> oh right
[23:46] <robru> buh, neither mhr3 nor camako are around to ping. ok, time for an email
[23:46] <infinity> slangasek: It might be close.  Hard to say.  But the whole build end-to-end is under 2h on sagari.
[23:46] <slangasek> hmm, what do you need to ping them for?
[23:46] <infinity> Turns out that GCC parallelises REALLY WELL.
[23:46] <robru> slangasek, to let them know that their failed builds are being retried
[23:47] <infinity> robru: Can't they just be pleasantly surprised when it all works? :)
[23:47] <infinity> I certainly don't tell people every time I retry a build in the distro.
[23:47] <slangasek> infinity: I'd say leave it alone, it's not critical-path if we're already reconfiguring for -proposed
[23:47] <infinity> Which is often.
[23:47] <robru> infinity, well in theory they're just twiddling their thumbs waiting for this...
[23:47] <slangasek> robru: ah, right - I'm with infinity, let them find out in the morning ;)
[23:48] <robru> infinity, well this is quite exceptional from my perspective. usually when builds fail it's because of upstream breakage, not distro breakage
[23:48] <robru> "usually when *CI Train* builds fail..."
[23:48] <infinity> slangasek: I do believe my test build with upgraded libstdc++ is past the point of anger, so your eyeball guess looks correct.
[23:49] <infinity> robru: Builds fail for a lot of reasons.  The reason I got involved in this at all was a completely different issue, for instance.
[23:49] <robru> infinity, right, and that original issue was also not caused by the upstream ;-)
[23:49] <infinity> robru: And sometimes someone clever comes along and retries a build because they know it'll succeed now, and sometimes it's fundamentally broken and I expect the uploader to fix it, but I never ping in the former case, I just let it happen.
[23:50] <infinity> robru: Up to you, of course, but this process already has too much formality in it.
[23:50] <robru> infinity, well when people ask me to fix something, I consider it polite to let them know that it's been fixed.
[23:50] <robru> even if I didn't fix it myself (thanks guys)
[23:50] <infinity> I'm mildly concerned about this silo now being half-proposed and half-not, but if it's not accidentally involved in a transition or anything, it shuld be fine.
[23:51] <robru> infinity, what kind of transition? it's mir 0.3.0 release, which is a fairly major point release for em
[23:51] <infinity> robru: No, I mean if other bits they depend on are transitioning.
[23:51] <infinity> robru: Then armhf would depend on the new -proposed libs, and !armhf wouldn't.
[23:52] <robru> infinity, can we check that? I'm not familiar with what libs mir depends on, let alone what's transitioning in proposed right this second
[23:52] <robru> infinity, are you suggesting that a complete rebuild would be better? ;-)
[23:53] <robru> reupload
[23:53] <infinity> slangasek: FWIW, the last gcc-4.9 build on an Xserve was 16h5m, so looks like adare has less than 2h to go.
[23:53] <infinity> robru: Nah.  Britney will yell at us if it's broken.
[23:53] <robru> infinity, ok great
[23:57] <infinity> robru: When you copy this silo to -proposed, give me a poke.  There's an ABI bump in libmirserver, and I'll need to apply overrides.
[23:58] <robru> infinity, ok, well I guess that'll be tomorrow, upstreams need to do testing before I'll publish
[23:58]  * infinity nods.