[01:41] <rsalveti> I can give it a try
[02:04] <imgbot> [02:30] <rsalveti> tedg: charles: asac: so hw alarms is partially completed with silo 14, works as expected on nexus 7 and I can hear the alarm ringing at the right time
[02:30] <rsalveti> it's not yet perfect as we don't have anyone holding a suspend blocker once the alarm is triggered, and not turning on the screen either
[02:30] <charles> rsalveti, \o/
[02:31] <charles> ted and I are seeing it work on the n4
[02:31] <charles> yea the not-turning-on-the-screen is something we talked about back in #phablet if you remember
[02:31] <rsalveti> I'd imagine we need to change powerd to also listen for alarms via /dev/alarm, and hold the lock for a few seconds (and turn on the screen)
[02:31] <charles> right
[02:32] <charles> I'd have to go back in scrollback but iirc you and ChickenCutlass and ricmm discussed making that change in powerd itself, same as how it listens for incoming calls
[02:32] <rsalveti> right, I believe that's how we'll end up doing it
[02:32] <rsalveti> but let's talk tomorrow to know how to proceed
[02:33] <rsalveti> but I believe we can already land the silo, it's an improvement already
[02:33] <charles> I agree, it's not a blocker for silo 14
[02:33] <charles> the other issue I'm seeing (or rather, hearing) is a 'stutter' in the alarm sound, https://bugs.launchpad.net/indicator-datetime/+bug/1320877
[02:34] <charles> ok
[02:34] <rsalveti> right, I think that will be solved once the powerd side is implemented
[02:34] <rsalveti> it's a race because the device is still trying to suspend
[02:34] <rsalveti> it wakes up but it'll try to suspend right after the alarm starts ringing
[02:34] <charles> rsalveti, should powerd be added to that ticket?
[02:35] <rsalveti> sure, that's my theory at least, let me try to reproduce here again
[02:35] <rsalveti> yeah, if the device is up the alarm plays fine
[02:36] <rsalveti> charles: can I mark your silo as tested then? can also land it
[02:36] <rsalveti> we can try to land the needed change in powerd tomorrow
[02:36] <charles> rsalveti, ted and I both passed it on the n4
[02:36] <rsalveti> great, I also validated it on nexus 7
[02:36] <charles> we were going to wait to make sure it passed on a tablet too, which you've done
[02:37] <charles> so afaict we're ready
[02:38] <rsalveti> great
[02:38] <rsalveti> argh, jenkins is still waiting for the arm64 build, that is never going to happen
[02:38] <charles> ok I've updated 1320877
[02:39] <charles> I'm going offline, I'll be back in ~11.5 hrs
[02:39] <rsalveti> charles: ok, only remaining issue
[02:40] <charles> yes?
[02:40] <rsalveti> charles: needs packaging change for it to depend on libplatform-hardware-api1-dev only on armhf, i386 and amd64
[02:40] <rsalveti> as we don't have that package for the other arches
[02:40] <rsalveti> and it might need build time changes to be smart enough and detect once it's available
[02:41] <rsalveti> otherwise it'll be blocked in proposed, as we currently have a working version for powerpc, ppc64el and arm64
[02:41] <rsalveti> and latest version from the ppa is not building any package for the above arches, because we don't have libplatform-hardware-api1-dev there
[02:43] <charles> hrm, that provides/usr/lib/i386-linux-gnu/libubuntu_platform_hardware_api.so
[02:43] <rsalveti> yup
[02:44] <charles> so we want to ifdef out all the hw alarm stuff and not link against that when we're outside of those three arches?
[02:44] <rsalveti> is there a way to not build the support for platform hardware api if not available during build-time?
[02:44] <rsalveti> charles: yeah
[02:44] <rsalveti> so we can still produce binary packages for those arches
[02:44] <charles> I thought platform-api fell back to stubs so that client apps didn't have to go through ifdef hell
[02:45] <rsalveti> well, not yet for every arch
[02:45] <charles> okay, I can do that
[02:45] <rsalveti> we could change platform-api to be generic enough with stubs and so on, but I'm afraid such change will take longer to land
[02:46] <charles> dyk where I could find an existing debian/control that does something similar? I haven't done this in debian packaging before.
[02:47] <rsalveti>                libplatform-hardware-api-headers,
[02:47] <rsalveti>                libplatform-hardware-api1-dev,
[02:47] <rsalveti> change then to:
[02:47] <rsalveti> libplatform-hardware-api-headers [armhf i386 amd64],
[02:48] <rsalveti> libplatform-hardware-api1-dev [armhf i386 amd64],
[02:48] <charles> aha
[02:48] <rsalveti> and during build time you just try to find if it's available or not
[02:48] <charles> yep, build time I've got
[03:07] <charles> so far so good on systems w/o alarm.h, now to try with alarm.h
[03:29] <imgbot> [03:30] <imgbot> [04:07] <charles> rsalveti, https://bazaar.launchpad.net/~charlesk/indicator-datetime/hw-alarms-api/revision/354
[06:21] <bzoltan> Mirv: are you in a position to be able to assign a silo to the line33?
[06:22] <bzoltan> Or maybe robru if still online
[07:00] <dpm> sil2100, would you be able to help bzoltan with his silo? ^
[07:00] <dpm> (and good morning :)
[07:08] <Mirv> rsalveti: no (testing emulator with 5.3), but I have that dependency problem with the gles packages I wrote about, so I couldn't even if I had the time
[07:11] <Mirv> dpm: assigned, even though bzoltan left
[07:11] <dpm> thanks Mirv!
[07:12] <Mirv> I'll kick a build too
[07:12] <dpm> awesome
[07:15] <vila> Mirv, sil2100, ogra_ : Hi guys ! Looks like I can't select any carrier anymore since... ~#71 (I'm at #76 now)
[07:17] <vila> Note that the automatic selection never worked for me
[07:37] <sil2100> vila: ouch
[07:37] <vila> sil2100: don't mention it ;)
[07:38] <ogra_> you are not the first one to claim that
[07:38] <ogra_> and i think there is a bug open for that
[07:39] <asac> rsalveti: charles: cool ... step by step :)
[07:40] <ogra_> vila, bug 1274618 ... see if it is the same
[07:40] <vila> ogra_: I saw some msgs on the u-phone ML but people seem to have recover, any idea on which project the bug was filed against... ::) ?
[07:45] <sil2100> Cellular seems to work fine here all the time at least
[07:47] <vila> ofono scripts fail with 'org.ofono.NetweorkRegistration doesn't exist (see added comment on bug)
[07:51] <ogra_> vila, that looks more like ofono isnt running
[07:53] <vila> ogra_: ps says there is an 'ofono -P stktest,provision,sao.udev.dun.smart,hfp' running
[07:53] <ogra_> ok ...
[07:53] <ogra_> so its not that
[07:53] <ogra_> any crash files in /var/crash ?
[07:56] <vila> 3 today for the scripts I just ran, the others are quite old
[07:57] <vila> ogra_: I'll remove them all and restart
[08:06] <vila> ogra_: weird msg in the system setting upstart log file (added to bug), is that relevant ?
[08:07] <vila> the /run/user/32011/signond/ dir is empty here
[08:15] <vila> seb128: regarding bug 1274618 , am I seeing the same bug (related at least) or should I file a new one ?
[08:17] <ricmm> seb128: hi seb
[08:18] <ricmm> seb128: any chance you could take a look at the platform-api MR from yesterday? the packaging review for the NEW ack
[08:18] <ricmm> we are blocking on that, and I think you are also blocking on that landing for something
[08:18] <ogra_> vila, bfiller is doing system settings now
[08:18] <vila> oops, sorry seb ;)
[08:18] <vila> bfiller: : regarding bug 1274618 , am I seeing the same bug (related at least) or should I file a new one ?
[08:27] <ogra_> sil2100, any idea what is up with silo 14 ? spreadsheet says it is building ...
[08:27] <sil2100> ogra_: let me see that
[08:28] <ogra_> (despite being testing done)
[08:28] <sil2100> ogra_: ah, yeah, if a job is aborted then CI Train will not pick up the state... it seems it drops some supported architectures?
[08:28] <ogra_> not sure if it ever built on these
[08:29] <seb128> ricmm, hey, was on the phone, looking at that in a bit
[08:29] <sil2100> ogra_: LP says it did...
[08:29] <seb128> vila: if you are seeing a bug already open, no need to file a new one
[08:30] <sil2100> ogra_: I wonder if they discussed that with cjwatson
[08:30] <sil2100> (or some other archive admin)
[08:31] <cjwatson> sil2100: rsalveti was working with charles in scrollback to get that fixed
[08:31] <cjwatson> this channel, about six hours back
[08:31] <ogra_> oh, and it seems that last change to debian/control is still missing if i see that right
[08:31] <sil2100> cjwatson: oh, ok, will have to look at the logs then.. so they intend to get it working for those archs? Since right now I just see a dep-wait on some mir libs
[08:32] <sil2100> ogra_: so I wouldn't call it 'testing done' ;)
[08:32] <sil2100> ogra_: meeting!
[08:32] <cjwatson> sil2100: yes
[08:32] <vila> seb128: thanks, abeato is guiding me to a workaround and a different bug anyway
[08:32] <vila> s/anyway/in th mean time/
[08:32] <cjwatson> or so it seemed to me from skimming the discussion anyway
[08:54] <vila> ogra_, sil2100 : my modem is back thanks to abeato, bug #1321627
[08:55] <ogra_> cool, glad you found it
[08:57] <Mirv> it might be just my network at QtCS but my system-image-cli claims system-image.ubuntu.com has invalid certificate
[08:57] <ogra_> yeah, sounds like a proxy issue
[08:57] <Mirv> I guess it's just that the mako doesn't have a proper connection, ubuntu-device-flash started just fine
[09:00] <popey> can someone please reproduce bug 1328536 - just run "ubuntu-bug unity8" on a device
[09:03] <brendand> sil2100, ogra_ - was there an autopilot landing recently?
[09:04] <brendand> sil2100, ogra_ skip has broken it seems
[09:04] <ogra_> brendand, on wed and thu ... for the upstart-app-launch rename
[09:04] <brendand> sil2100, ogra_ - at least for that one test
[09:05] <brendand> sil2100, ogra_ - right. i'll take a look and see if i can figure out what's going on
[09:05] <ogra_> https://launchpad.net/ubuntu/utopic/+source/autopilot/1.5.0+14.10.20140601-0ubuntu1
[09:05] <ogra_> https://launchpad.net/ubuntu/utopic/+source/autopilot-legacy/1.4.1+14.10.20140430-0ubuntu4
[09:06] <ogra_> http://launchpadlibrarian.net/176889634/autopilot_1.5.0%2B14.10.20140526.1-0ubuntu1_1.5.0%2B14.10.20140601-0ubuntu1.diff.gz
[09:06] <ogra_> and
[09:06] <ogra_> http://launchpadlibrarian.net/177001213/autopilot-legacy_1.4.1%2B14.10.20140430-0ubuntu3_1.4.1%2B14.10.20140430-0ubuntu4.diff.gz
[09:06] <ogra_> are the package diffs
[09:10] <ogra_> sil2100, i think bug 1321627deserves some of our attention ... given that there seem to be many people with similar 3G probs
[09:10] <ogra_> (like vila )
[09:10] <ogra_> :)
[09:13] <vila> ogra_: I can't agree more ;)
[09:14] <brendand> ok it looks like a test that is skipped still runs setUp. that's stupid
[09:16] <brendand> although it's probably a 'feature' of unittest rather than APs fault
[09:20] <sil2100> ogra_: oh, I wasn't aware of that one
[09:22] <brendand> sil2100, really interesting finding about the medai player failure
[09:22] <brendand> sil2100, if you look at the timestamps, media-hub-server crashes *just* exactly when the test starts
[09:22] <brendand> like 1 second after
[09:24] <sil2100> oh
[09:25] <brendand> sil2100, i can't reproduce it, but i think we can agree the test is not at fault
[09:25] <brendand> sil2100, do those crashes generate bugs automatically?
[09:25] <brendand> sil2100, or will i need to file one?
[09:26] <sil2100> brendand: no... we have to fill them in ourselves manually, but not sure if ogra_ didn't fill one in already
[09:26] <brendand> ogra_, did you?
[09:26] <sil2100> brendand: so in other words, it should basically skip this test but the crash makes the test failing?
[09:27] <brendand> sil2100, well the behaviour of unittest module in python is to always run setUp. for good and for bad
[09:28] <brendand> sil2100, and setUp launches the app and checks it can be accessed
[09:28] <brendand> sil2100, so if setUp fails then it won't get a chance to be skipped
[09:31] <sil2100> Now this is a funny case happening then ;)
[09:31] <sil2100> Thanks for looking into that!
[09:33] <ogra_> brendand, nope, didnt
[09:36] <brendand> ogra_, what's the project for media-hub-server?
[09:36] <brendand> ogra_, is it the mediaplayer itself?
[09:42] <sil2100> brendand: media-hub I suppose?
[09:45] <ogra_> yeah
[10:02] <brendand> sil2100, for the osk in web browser, it does appear, but i can't confirm if it's actually used. i'll look at the code a bit and also ask the AP folks later when they log on
[10:11] <seb128> ricmm, reviewed, it's mostly good but has some small issues
[10:41] <brendand> sil2100, here's that crash bug finally. https://bugs.launchpad.net/media-hub/+bug/1328859
[10:41] <brendand> sil2100, launchpad very kindly crashed and lost my report halfway through filing
[10:46] <sil2100> brendand: thanks! Murphy's law, as always ;)
[10:59] <asac> Saviq: is anyone checking the unity8 test failure?
[10:59] <asac> who from SDK team is lander besides zoltan?
[10:59] <asac> sil2100: ?
[11:00] <sil2100> asac: only Zoltan is the lander, we have bugs filled for this issue already
[11:01] <asac> sil2100: how long is his test failing?
[11:01] <sil2100> asac: but Zoltan and Saviq might be not too responsive because of the QDS
[11:01] <asac> QDS?
[11:01] <asac> sil2100: do we know when those test failures started?
[11:01] <asac> and which landing caused this?
[11:02] <sil2100> asac: just appeared now
[11:02] <sil2100> Qt Developer Summit
[11:03] <sil2100> asac: we don't know yet, things started getting more 'sensitive' after the Mir landing we had
[11:03] <sil2100> But we could not identify the source of why it started happening
[11:03] <sil2100> As these are generally only AP flakyness
[11:04] <asac> sil2100: so they dont happen on every image?
[11:05] <sil2100> No
[11:05] <sil2100> Most of them are random, and brendand and elopio are helping as much as they can to identify the causes
[11:07] <brendand> sil2100, nothing is random :)
[11:07] <brendand> sil2100, we just don't have enough info yet
[11:08] <brendand> we'll figure it out. we already realised about the media-server-hub crash
[11:24] <asac> bzoltan: are you guys investigating the uitoolkit AP failure?
[11:24] <ogra_> asac, there is a fix already
[11:24] <asac> ah
[11:24] <asac> ogra_: which component needs landing?
[11:24] <asac> uitoolkit itself?
[11:25] <ogra_> gimme a sec ... need to check if it is still the same failure
[11:25] <asac> :P
[11:26] <ogra_> hmm, it is still the same and there is an MP from elopio but i cant find a landing for it
[11:27] <ogra_> asac, bug 1326072
[11:28] <ogra_> seems it is merged into the staging branch but not in trunk
[11:28] <ogra_> and seems the whole UITK needs to land for it
[11:29] <asac> the whole?
[11:29] <asac> like no cherry pick possible?
[11:29] <ogra_> no idea how the SDK guys manage thes branches
[11:30] <ogra_> https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging has definitelly a bunch of newer commits already
[11:32] <ogra_> asac, aha, soli 6 seems to include it
[11:32] <ogra_> but it is untested
[11:32] <asac> soli :P
[11:32] <asac> solitude
[11:33]  * ogra_ wishes the changelog entry was more descriptive again ... ldoesnt talk about Xauthority at all
[11:33] <ogra_> heh, silo indeed :)
[11:45] <bzoltan1> ogra_: asac: I have tested the soli6 but I am not happy with the results...
[11:45] <bzoltan1> ogra_: asac:  but yes, that silo has the fix for that problem
[11:46] <asac> bzoltan1: what results do you get that make you not happy?
[11:46] <bzoltan1> asac:  do you want me to dig up the original MR what fixes that issue? I know which one it was, but I do not know what conflicts it will cause later with the staging branch
[11:48] <bzoltan1> asac: http://pastebin.ubuntu.com/7628182/ But I want to reflash my testing device and run these tests again...
[11:49] <sil2100> Damn, what's wrong with my WiFi router
[11:49] <asac> bzoltan1: dont worry. was just checking
[11:50] <ogra_> sil2100, the NSA got you !
[11:50] <asac> sil2100: maybe its not your roiuter, but your computer wifi modem :)
[11:50] <asac> is your phone going off as well?
[11:50] <bzoltan1> asac: few weeks back I started to enjoy that I could roll out UITK releases in 1-2 days, but now we are back at 1-2 weeks... and most of the times it is not about the components
[11:50] <asac> bzoltan1: what happened?
[11:51] <bzoltan1> asac:  mostly AP changes
[11:51] <sil2100> It looks like the wifi router has some problems, it's not the first time all my machines loose WiFi suddenly ;p
[11:51] <sil2100> brb, quick test-reset
[11:51] <asac> bzoltan1: AP changes? QA changed autopilot (the framework)?
[11:53] <asac> bzoltan1: was there a new ap release that makes your life harder?
[11:56] <bzoltan1> asac:  the UITK's own AP tests changed and the applications own AP tests are not really reliable
[11:57] <bzoltan1> asac:  simple said, we had problems with the AP itself, with the apps tests, with our own AP tests and the biggest change was the new header what flagged out poorly writen app tests
[12:30] <mhr3> Mirv / sil2100 any way to poke the hud sru? it's been in unapproved for 2 weeks now
[12:31] <seb128> mhr3, https://launchpad.net/~ubuntu-sru/+members is who you want to ping
[12:31] <seb128> mhr3, https://wiki.ubuntu.com/StableReleaseUpdates#Publishing suggest you can try asking cjwatson on wednesdays
[12:32] <seb128> mhr3, I guess I just sort of pinged for you there ;-)
[12:32] <seb128> (wouldn't mind seeing unity-settings-daemon approved as well, oem team is waiting on it)
[12:32] <mhr3> seb128, that's the way, i like it :)
[12:32] <seb128> ;-)
[12:32] <mhr3> aha aha
[12:33] <mhr3> http://www.youtube.com/watch?v=dd--tIkrVoA&feature=kp
[12:35] <rsalveti> Mirv: thanks, will take a look later today
[12:36] <rsalveti> charles: great, rebuilding the package now
[12:37] <rsalveti> sil2100: marked as tested yesterday before we found out that issue, moved to not tested now and rebuilding the silo
[12:38] <sil2100> rsalveti: o/
[12:38] <sil2100> rsalveti: thanks, good to hear that :)
[12:54] <bzoltan1> asac:  for example.. the CI dash shows that the calendar app has 22 all OK tests... I flashed the latest image few minutes ago and I have 4 failures on the Calendar ap on the stock image http://pastebin.ubuntu.com/7628432/
[12:58] <ogra_> bzoltan1, well, if you look at the test results from a few days you get a different picture
[12:59] <ogra_> looks like it constantly had flaky tests the last days
[12:59] <ogra_> it just happens that it didnt hit one today
[12:59] <bzoltan1> ogra_:  flaky tests are killing me...
[13:00] <asac> bzoltan1: just wanted to ask if always reproducible?
[13:00] <ogra_> bzoltan1, yeah, not only you ... but we still have some
[13:00] <asac> but guess that answers it
[13:03] <bzoltan1> elopio: http://paste.ubuntu.com/7628383/
[13:11] <alan_g> Ursinha: For the last few hours we've seen jobs failing in a system header file: https://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/. I assume something has changed in the build config: Can you help?
[13:14] <Ursinha> alan_g: I'll have a look
[13:15] <alan_g> thanks
[13:47] <sil2100> ogra_: I'll try to look into what we can do to get our stuff migrated to that canonistack instance
[13:48] <ogra_> ok
[13:48] <ogra_> imgbot will definitely need some work before i can move it somewhere
[13:48] <ogra_> it is a mess of separate scripts atm
[13:49] <sil2100> k, let's slowly work on that I guess, not need for haste
[13:49] <charles> rsalveti, any news?
[13:49] <ogra_> charles, you missed the second bit rsalveti mentioned above
 change then to:
 libplatform-hardware-api-headers [armhf i386 amd64],
 libplatform-hardware-api1-dev [armhf i386 amd64],
[13:50] <rsalveti> no, that was done already
[13:50] <rsalveti> :-)
[13:50] <rsalveti> charles: rebuilding
[13:50] <charles> rsalveti, ack
[13:50] <ogra_> rsalveti, i didnt see it in the PPA
[13:50] <rsalveti> charles: just missing ppc64el
[13:51] <rsalveti> ogra_: I triggered a rebuild this morning
[13:51] <rsalveti> my morning :-)
[13:51] <ogra_> ah
[13:51]  * ogra_ looked at it his morning ... 
[13:51] <ogra_> we should sync our monrings ;)
[13:51] <ogra_> *mornings
[13:52] <charles> ogra_, I pushed that 9 hours ago, you've had a long morning... :)
[13:52] <ogra_> i looked at it 5h ago or so
[13:53] <ogra_> but only at the debdiff in the PPA
[13:55] <sil2100> ogra_: ;)
[13:56] <sil2100> ogra_: rsalveti mentioned about a rebuild some time ago
[13:58] <ogra_> ah
[13:58] <ogra_> missed that, thanks
[14:05] <Ursinha> alan_g: so, gcc was updated from 4.8 to 4.9 and clang isn't happy; it's a known bug and it's fixed on llvm-toolchain-3.4 1:3.4.1-4 (not on ubuntu yet)
[14:06] <Ursinha> alan_g: possible workaround is to force gcc 4.8 on your side
[14:06] <Ursinha> alan_g: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872 for reference
[14:07] <alan_g> Ursinha: thanks. I assume there's no ETA for the fix?
[14:07] <alan_g> alf_: FYI ^
[14:08] <alf_> alan_g: thanks
[14:09] <Ursinha> alan_g: not that I know of, fginther just investigated and concluded that that was the problem, other builds might fail due to the same issue so I believe it shouldn't take long
[14:09] <Ursinha> but that's a guess
[14:11] <alan_g> Ursinha: thanks again. We'll figure it out.
[14:12] <stgraber> robru: "stgraber is missing the Job/Build permission" ...
[14:43] <charles> rsalveti, will you retest the hw alarms for tablet w/the new build?
[14:43] <rsalveti> charles: yup
[15:00] <robru> stgraber, bah, hang on
[15:01] <robru> stgraber, ok, i added core dev again, not sure why this isn't a permanent setting
[15:11] <robru> stgraber, you're on for landings today right? need any help?
[15:13] <stgraber> robru: I should be fine now that I can actually get stuff done
[15:15] <stgraber> mhr3: you've got silo 19 for mediascanner
[15:15] <robru> stgraber, k, feel free to ping me if you have any questions
[15:15] <mhr3> thx
[15:22] <xnox> sil2100: I want to become a lander! =)
[15:42] <robru> sil2100, ok, now that the session is over, please review my branch ;-) https://code.launchpad.net/~robru/cupstream2distro/add-core-dev-perms/+merge/222705
[15:43] <sil2100> robru: o/
[15:43] <sil2100> xnox: hah!
[15:43] <sil2100> xnox: wait, you're not a lander yet!!
[15:43] <sil2100> *!?
[15:43] <mterry> sil2100, can I get a silo for spreadsheet line 37?
[15:44] <sil2100> mterry: sure, just heard about the revert plan
[15:44] <sil2100> What's up?
[15:44] <sil2100> Since I remember QA saying things aren't bad as they are now
[15:44] <robru> mterry, noooooooooooo :-(
[15:45] <mterry> robru, I know  :(  But it will come back, though probably only for Desktop
[15:45] <mterry> robru, RTM is too close to take the risk for phone
[15:45] <robru> mterry, so we're going RTM with single-user-only phones then?
[15:45] <asac> my head is a bit messy today, did the alarm stuff land ?
[15:45] <mterry> robru, yeah -- I mean, I think that was always likely the plan, but we wanted the correct architecture in place anyway
[15:46] <ogra_> asac, nope
[15:46] <robru> mterry, ah ok,
[15:46] <ogra_> asac, needs a tester first ...
[15:46] <asac> ogra_: tester?
[15:47] <ogra_> asac, it was rebuilt with the final changes ...
[15:47] <asac> ogra_: ok, how long is that build done?
[15:47] <ogra_> dunno, i didnt check
[15:47] <xnox> sil2100: no, i am not a lander
[15:47] <mterry> sil2100, well anyway, I have a couple branches in line 37, this should revert the split greeter for now
[15:47] <ogra_> https://launchpad.net/~ci-train-ppa-service/+archive/landing-014/
[15:48] <ogra_> seems it built, the spreadsheet thinks it failed though
[15:48] <sil2100> xnox: let's change that in the nearest days then - core-devs themselves can anyway land stuff through CI Train but some basic training might be useful ;)
[15:49] <robru> sil2100, that can be true for real as soon as you review my branch ;-)
[15:49] <asac> ogra_: ok seems its not dangling, but rather fresh TODO :)
[15:49] <sil2100> robru: no no, your modification is for the landing team ;p core-devs are landers by default since longer
[15:49]  * asac wont ping folks to test for a bit
[15:49] <ogra_> asac, i think rsalveti confirmed to re-test after the rebuild
[15:50] <asac> xnox: awesome decision :)
[15:50] <asac> thanks!
[15:50] <asac> ogra_: how long waiting for a tester?
[15:50] <asac> < 1h <3h >6h
[15:50] <asac> err
[15:50] <asac> well you figure
[15:50] <ogra_> asac, until he has time and isnt in a session or important discussion i guess :)
[15:50] <robru> sil2100, we need to think up better names than "landers" and "landing team", too confusing
[15:51] <asac> ogra_: ok so charles and tedg already tested?
[15:51] <ogra_> dunno, who tested that
[15:51] <ogra_> i just saw the conversation between charles and rsalveti above
[15:52] <rsalveti> just waiting the ppc64el package to build
[15:53] <asac> robru: i had names once :)
[15:53] <rsalveti> oh, just completed :-)
[15:53]  * asac finds the slide deck
[15:53] <rsalveti> charles: ^
[15:53] <rsalveti> so once you re fine with mako, I'll cover flo
[15:53] <rsalveti> let me flash latest on it
[15:53] <sil2100> \o/
[15:58] <stgraber> mterry: shouldn't that last landing be marked as ready (I see you got a silo already though)?
[15:58] <mterry> stgraber, oh yeah let me mark
[15:58] <stgraber> tedg: is that indicator bugfix thingy ready to build? if so, please mark as ready (pinging because it's been on there unchanged for a while now)
[15:58] <robru> sil2100, so I just merged that MP and then deployed citrain, prepare job lost core dev perms again, what am I missing?
[16:00] <robru> sil2100, I guess the deploy job doesn't branch from bzr, how do I get the bzr branch code into jenkins?
[16:00] <tedg> stgraber, Jenkins failed on one of the branches and I rekicked it (branch conflict)
[16:00] <tedg> stgraber, Just waiting on that.
[16:01] <stgraber> tedg: ok
[16:03] <tedg> Ah, should be good now.
[16:25] <sil2100> robru: one moment, meeting ;)
[16:26] <sil2100> (not landing, different one)
[16:27] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/preload-publisher-indexes/+merge/222768 whee
[16:27] <cjwatson> Wonder how much of a dent that'll make in cron.ppa runtime
[16:28] <stgraber> we've ran out of silos, so new landings will have to wait for other people to finish theirs
[16:28] <seb128> tedg, is your indicator-session landing for logout on unity8 tested/ready to land? (we have 0 silos, looking what we could try to land to get some)
[16:28] <seb128> dbarth, ^ what about your 017 u-s-s-o-a one?
[16:28] <seb128> bfiller, ^ what about your ubuntu-keyboard bugfixes?
[16:29] <cjwatson> just looking at the hud SRU nowish
[16:29] <seb128> mandel, ^ what about dbus-cpp
[16:29] <seb128> cjwatson, thanks, if you could do unity-settings-daemon as well that would be great (oem is waiting on it, and it would free a silo)
[16:29] <cjwatson> depends on time but I'll try
[16:29] <seb128> thanks
[16:30] <seb128> bfiller, you also have a qtorganizer-eds bugfix in there ... can that be verified/landed? ;-)
[16:32]  * sil2100 back from meetings
[16:33] <sil2100> kgunn: hi! Would you mind if we clense your pre-flight silo 001?
[16:33] <sil2100> seb128: thanks for helping out whipping people :)
[16:33] <tedg> seb128, Trying to get a tester that has u8 desktop running, on my third :-/ bregma said he could test after UOS today, so hopefully soon.
[16:33] <dobey> :(
[16:33] <seb128> sil2100, yw
[16:34] <seb128> tedg, I've unity8 desktop running ... do I need unity8 changes or just plain utopic?
[16:34] <sil2100> rsalveti: hi! How's landing 14 proceeding?
[16:34] <sil2100> robru: getting back to your question
[16:34] <robru> thanks
[16:35] <tedg> seb128, Just utopic, then update indicator-session and then you should be able to logout.
[16:35] <seb128> tedg, great, testing
[16:35] <tedg> Woot!
[16:35] <kgunn> AlbertA: is loosing silo1 for display state changes ok ?
[16:36] <kgunn> figure sense we landed mir020 we might want to land this now... ?
[16:37] <AlbertA> kgunn: media hub mp is missing
[16:37] <sil2100> kgunn: if you can land it today it would be awesome
[16:37] <AlbertA> kgunn: and the powerd-cli to use the new display on requests interface
[16:37] <AlbertA> kgunn: which will be needed for autopilot tests
[16:37] <charles> rsalveti, tedg, I was afk for a bit. does datetime still need n4 testing?
[16:37] <kgunn> sil2100: go ahead and use silo1 as you need....looks like we're waiting
[16:37] <kgunn> on some other projects
[16:38] <AlbertA> kgunn: yeah
[16:38] <sil2100> kgunn: thanks! Once you have all the bits in place, just ping us again
[16:38] <kgunn> sure
[16:38] <kgunn> ta
[16:38] <AlbertA> kgunn: we'll request another one when the other pieces are in
[16:39] <robru> sil2100, can we use that -test job to run 'bzr pull' on the jenkins instance or something?
[16:39] <sil2100> robru: one moment, let me take a look on what happened
[16:39] <seb128> tedg, how is it supposed to work? indicator-session has no icon in unity8, it's listed in the headers of the indicator set, but picking logout does nothing
[16:40] <sil2100> robru: ah, I see the problem ;)
[16:40] <cjwatson> seb128: both hud and unity-settings-daemon accepted now
[16:40] <seb128> cjwatson, thanks a lot!
[16:40] <bfiller> seb128: I need to check with renato to see if he's finished his testing on that yet
[16:41] <seb128> bfiller, that would be nice, we are on 0 silo atm so everything new is locked pending on previous landing to be tested/landed/cleaned
[16:41] <bfiller> seb128: will do
[16:41] <sil2100> robru: ok, it's fine now - I see you didn't check DEPLOY_PREPROD_CITRAIN and DEPLOY_PROD_CITRAIN while doing the deploy
[16:41] <seb128> bfiller, thanks
[16:41] <sil2100> robru: it's required to do a bzr pull
[16:42] <tedg> seb128, I'm not entirely sure. charles ^
[16:42] <tedg> seb128, I thought it was just hit logout.
[16:42] <robru> sil2100, ah ok, I didn't understand those options on that job, thanks
[16:43] <mhr3_> robru, can i get 019 reassigned to line 40?
[16:43] <mhr3_> robru, i mean, i'm giving up 019
[16:43] <robru> mhr3_, alright
[16:43] <mhr3_> and want it back for another project :)
[16:44] <robru> mhr3_, ok, freeing now. it takes a bit, hopefully nobody else assigns before I can reassign it...
[16:44] <mhr3_> k, ty
[16:44] <robru> youre welcome
[16:48] <sil2100> robru: we really need an useful FAQ or docs for citrain ;p
[16:49] <robru> sil2100, yeah... wanna add some stuff to https://wiki.ubuntu.com/citrain/FAQ ?
[16:49] <sil2100> robru: would love to if I had the time ;p
[16:50] <robru> mhr3_, ok, got you in 15 actually, 1 free silo yay ;-)
[16:50] <robru> who's next in line for a silo?
[16:50] <mhr3_> heh, k
[16:51] <dbarth> seb128: not finished, so far i fail to co-install the 2 modules, but i may be missing a step
[16:51] <seb128> dbarth, what about the html5 one?
[16:52] <robru> silos 2, 4, 13, and 17 haven't seen any movement since last week, I'd like to free those ones...
[16:53] <dbarth> seb128: i just got it 4h ago
[16:53] <seb128> dbarth, ok, sorry, just looking at the list since we are out of silos ;-)
[16:53] <dbarth> seb128: if you need one, take the ussoa + signon one
[16:54] <seb128> dbarth, no, that's fine, just making sure things don't stay there for a week because it blocks others to get a silo
[17:01] <mandel> seb128, we are looking at dbus-cpp at the moment
[17:01] <seb128> mandel, thanks
[17:04] <robru> there are too many requests and not enough silos. I can't risk assigning something to somebody who isn't around and won't use the silo immediately. therefore silos will be assigned on a first-ping basis. whoever asks first, gets it first
[17:08] <mandel> seb128, robru kill silo 02 for dbus-cpp and I'll request it later, is not urgent
[17:08] <seb128> mandel, k
[17:09] <tedg> robru, sil2100, let's drop silo 13, we'll be able to land it next week with the u8 MR for the same feature.
[17:09] <robru> tedg, thanks!!
[17:09] <robru> mandel, also thanks ;-)
[17:09] <seb128> robru, can I get a silo for ubuntu-system-settings on l38?
[17:09] <robru> seb128, yes you can!
[17:09] <seb128> thanks
[17:10] <robru> seb128, you got 1
[17:10] <seb128> k
[17:15] <robru> bfiller, tedg, boiko, kgunn: i've gone through and marked all the unassigned silos as ready:no. if you are around and you really want a silo, please ping me.
[17:16] <tedg> robru, I'd like a silo for the bug fixes to lower down the MR queue, but it's not critical. If there's a lull, it'd be nice to work off the backlog.
[17:17] <robru> tedg, yes we have some silos free now, it's no problem to give you one, I just can't assign them without some sign that you're actually around to work on it, otherwise it's a waste to have silos idling for people who aren't around.
[17:19] <robru> tedg, ok you got silo 2. thanks for grouping indicators into one big one
[17:19] <tedg> robru, Cool, thanks!
[17:19] <robru> tedg, you're welcome!
[17:22] <sil2100> robru, ogra_: so, the plan is... let's try getting the alarm fix from rsalveti in as soon as possible
[17:22]  * rsalveti just got back from lunch
[17:22] <sil2100> Once that's in, let's kick a new image and consider it as a promotion candidate
[17:22] <rsalveti> let me validate the ppa
[17:22] <ogra_> ++
[17:22] <sil2100> If not, then we can promote 77 as we have green lights on that
[17:22] <robru> sil2100, sounds good
[17:22] <sil2100> rsalveti: thanks :)
[17:22] <rsalveti> charles: yeah, please test on n4
[17:23] <charles> rsalveti, k
[17:23] <robru> rsalveti, i've got an idle n4, want me to help test? what do I do?
[17:23] <rsalveti> robru: https://launchpad.net/~ci-train-ppa-service/+archive/landing-014
[17:24] <rsalveti> robru: use http://paste.ubuntu.com/7625773 to update lxc-android-config
[17:24] <robru> rsalveti, alright, on it
[17:24] <rsalveti> then set an alarm, suspend the device (make sure you don't have any usb cable connected to it)
[17:24] <rsalveti> and wait for it to wake up :-)
[17:24]  * sil2100 jumps out to the store for a moment
[17:25] <rsalveti> the alarm sound might but be that smooth, but that's known as we still need to change powerd in a way it blocks the suspend once the alarm is triggered
[17:25] <rsalveti> but the main different here is that you'll get something
[17:26] <robru> rsalveti, alright
[17:26] <robru> thanks
[17:32] <robru> rsalveti, what do you mean by "suspend the device"? does that mean just let the screen turn off?
[17:35] <charles> sigh. trying to set alarm, got this... https://i.imgur.com/UckEY8w.jpg
[17:36] <robru> charles, hm, I was able to set a couple alarms, but the interface for selecting the time was rubbish, very unresponsive.
[17:36] <charles> robru, it's being redesigned, nik90 is implementing the new design for rtm
[17:37] <robru> cool
[17:37] <charles> indeed
[17:37] <rsalveti> robru: yeah
[17:38] <robru> rsalveti, alright, alarm set for a couple minutes from now, will let you know ;-)
[17:38] <rsalveti> yeah, might be a different issue
[17:38] <charles> okay, after blowing away the alarm database and rebooting the phone, I'm able to set alarms now... testing
[17:40] <robru> rsalveti, alright, so I got this piano-y alarm tone, it sounds a bit crap, like a CD skipping, but it technically triggered at the right time. so that's what we want?
[17:41] <charles> yep, wfm as well
[17:41] <ogra_> do you actually let the phone lseep for a while so it is in deep sleep ?
[17:41] <charles> robru, the skipping CD is a different issue
[17:42] <robru> ogra_, how deep is deep sleep? I had my screen off for 5m
[17:42] <rsalveti> ogra_: the crap audio shows that the device was sleeping
[17:42]  * ogra_ only misses allarms if the phone was off for like 30min 
[17:42] <rsalveti> because it wakes up and then tries to sleep again
[17:42] <rsalveti> causing the audio issue
[17:42] <ogra_> i.e. i had all alarms go off in malta where i regulary used it
[17:42] <ogra_> yeah, i know that
[17:42] <rsalveti> to fix that we need changes in powerd
[17:42] <charles> robru, if you're interested https://bugs.launchpad.net/indicator-datetime/+bug/1320877/comments/3
[17:43] <charles> ogra_, hm, ok. Let's try with a 30+ min alarm too
[17:43] <rsalveti> ogra_: charles: tested with flo
[17:43] <rsalveti> flo always go to deep sleep in minutes
[17:43] <rsalveti> worked as expected
[17:43] <ogra_> ah, k
[17:44] <ogra_> right
[17:44] <ogra_> flo is different
[17:44] <rsalveti> no radio
[17:44] <rsalveti> modem I mean
[17:44] <rsalveti> charles: looks good, guess we can land it
[17:44] <rsalveti> let me do a watch-only build
[17:45] <ogra_> land it !
[17:46] <rsalveti> robru: ogra_: charles: DONE
[17:47] <ogra_> \o/
[17:47] <robru> rsalveti, should I publish then?
[17:47] <ogra_> asac, ^^
[17:47] <ogra_> there are your alarms
[17:47] <rsalveti> robru: done already
[17:47] <robru> oh great
[17:47] <rsalveti> asac: not yet perfect though, but getting there
[17:47] <charles> rsalveti, :D
[17:47] <rsalveti> you should hear something now at least :-)
[17:48] <rsalveti> cyphermox: this landing also unblocks lxc-android-config
[17:48] <rsalveti> so feel free to push your change
[17:48] <nik90> charles: are you guys discussing the wake from deep sleep when an alarm is being triggered?
[17:48] <ricmm> robru: can you reconf silo 7 for me please?
[17:48] <charles> rsalveti, are you handling the powerd changes for 1320877?
[17:48] <ricmm> dbus-cpp is added which needs a rebuild against gcc 4.9
[17:48] <ricmm> which was switched ON 2 hours ago
[17:48] <rsalveti> charles: our team will handle that
[17:48] <robru> ricmm, sure
[17:48] <ricmm> thanks
[17:49] <cyphermox> rsalveti: ah, thanks!
[17:49] <charles> rsalveti, ok
[17:49] <robru> ricmm, you're welcome!
[17:51] <robru> ahhhhhh... 3 free silos, and 2 just published will be free soon... such breathing room, it's great!
[17:52] <ricmm> robru: actually I think I can reconf myself
[17:52] <robru> ricmm, too late, I did it!
[17:52] <ricmm> heh
[17:52] <ricmm> alright great
[17:52] <ricmm> I'll build
[17:55] <cyphermox> rsalveti: robru: so, confirm line 26 is no longer blocked? I just set it back to Ready
[17:56] <robru> cyphermox, right, well lxc-a-c just got published, it's not free yet. are you able to base your upload on that one? if so I can assign you a silo
[17:58] <cyphermox> I can
[17:58] <robru> cyphermox, alright, you got silo 13
[18:07] <sil2100> robru, ogra_: once silo 14 migrates, remember to kick a new image :)
[18:07] <ogra_> sure
[18:07] <sil2100> davmor2: if you could then dogfood #78 we'll think of promoting it tomorrow
[18:12] <asac> rsalveti: will this help at all?
[18:12] <asac> rsalveti: what does "not perfect mean" :)?
[18:13] <ogra_> asac, sound playback will still stutter
[18:13] <asac> ogra_: ok. i wasnt after
[18:14] <asac> ogra_: i only want my alarm to ring in the morning so i can schdule morning calls again :)
[18:14] <asac> that works now?
[18:14] <ogra_> yes
[18:15] <ogra_> it will in 78
[18:15]  * asac  crosses fingers that that one gets promoted
[18:15] <asac> maybe i can start waking up early on friday :)
[18:16] <asac> that would be phabulous
[18:17] <rsalveti> asac: not yet perfect because we need to fix bug 1320877
[18:19] <asac> rsalveti: ah. yeah. i think a not predictable rythm helps me actually to not built up alarm-tolerance :P
[18:21] <rsalveti> :-)
[18:42] <robru> ogra_, hmmm, something goofy is going on with silo 14. citrain says it landed, launchpad and rmadison say the packages are not only not landed yet, but not even in proposed...
[18:42] <rsalveti> maybe there were just migrated
[18:42] <rsalveti> that happens when the migration is in place iirc
[18:43] <ogra_> robru, looks fishy
[18:43] <robru> rsalveti, usually when I check LP in the middle of a migration, it says there's two in the release pocket. but right now there's no LP or rmadison acknowledgement of the new packages at all
[18:43] <robru> ogra_, rsalveti: also, excuses says 'valid' on both new packages
[18:44] <cjwatson> have you checked +publishinghistory?
[18:44] <cjwatson> it's usually clearer for this kind of thing
[18:44] <cjwatson> there is certainly a window where the package will be absent from the normal source package page
[18:45] <robru> cjwatson, hmm, it does show up in the history
[18:45] <cjwatson> Right, https://launchpad.net/ubuntu/+source/lxc-android-config/+publishinghistory and https://launchpad.net/ubuntu/+source/indicator-datetime/+publishinghistory are as I'd expect
[18:45] <cjwatson> So that's busy migrating to release
[18:45] <robru> cjwatson, ok great, thanks for clearing that up. I guess just by chance I never saw a migration at exactly this stage before
[18:46] <cjwatson> proposed-migration does a copy and a delete, and the main source package page only shows things in the published state
[18:46] <cjwatson> so it'll look missing from there until the publisher starts
[18:47] <cjwatson> I reach for +publishinghistory pretty much as a reflex now as it actually fits my model of the world :)
[18:48] <ogra_> cjwatson, thats a recent thing, right ?
[18:49]  * ogra_ was caught by surprise by it a while ago when rmadison didnt show the package anymore all of a sudden)
[18:49] <robru> cjwatson, but we still need to trust rmadison as authoritative, right?
[18:50] <cjwatson> ogra_: no
[18:50] <cjwatson> robru: yes
[18:50] <cjwatson> that's what tells you what the image builder will see
[18:50] <cjwatson> ogra_: well if by recent you mean start of raring when proposed-migration was introduced
[18:51] <cjwatson> ogra_: windows tend to shift around a bit over time depending on various factors
[18:51] <ogra_> cjwatson, no recent like a few weeks ago ... right before malta i noticed it for the first time
[18:51] <cjwatson> no change at that point
[18:51] <cjwatson> I think you just got (un)lucky
[18:51] <ogra_> ah
[18:51] <ogra_> well
[18:51] <ogra_> :)
[18:51] <cjwatson> it's behaved that way for ages
[18:52] <ogra_> i never noticed
[18:52] <ogra_> probably i'm more patient usually and dont reload rmadison that often :)
[18:52] <cjwatson> ok, I should reread and clarify
[18:52] <cjwatson> LP not showing the package for a period is standard and normal
[18:53] <cjwatson> rmadison not showing it is bad luck
[18:53] <cjwatson> that happens if the publisher starts between the copy and the delete
[18:53] <robru> cjwatson, bad luck, as in, something went wrong?
[18:53] <cjwatson> no, just an exceptional event
[18:53] <ogra_> right
[18:53] <robru> cjwatson, can you estimate how long until it's resolved?
[18:53] <ogra_> 30min at most
[18:53] <robru> ah ok
[18:54] <cjwatson> robru: I don't see a problem, rmadison shows lxc-android-config ...
[18:54] <robru> I'll stop refresshing rmadison every 2s then ;-)
[18:54] <ogra_> cjwatson, indicator-datetime
[18:54] <ogra_> is the second package in the set
[18:54] <cjwatson> it shows that too
[18:54] <ogra_> not for me
[18:54] <robru> cjwatson, it shows me 0.170, we're waiting for 0.171 which is missing
[18:54] <cjwatson> sure, not the latest version, but it's not missing
[18:54] <ogra_> 13.10.0+14.10.20140611-0ubuntu1
[18:54] <ogra_> thats what you look for
[18:54] <cjwatson> nothing's broken there, it's just not fully processed
[18:54] <robru> cjwatson, the latest version is missing :-P
[18:54] <ogra_> right
[18:55] <cjwatson> normal condition
[18:55] <robru> alright, well I'm going to step out for lunch then, no point twiddling my thumbs for this.
[18:55] <cjwatson> with a bit more detail, what probably happened here is:
[18:55] <cjwatson> promote-to-release requested the copies
[18:56] <ogra_> robru, right, i'll take care (since i'll build the image anyway)
[18:56] <cjwatson> those are async, and the copy requests came back successfully
[18:56] <cjwatson> it then scheduled the delete
[18:56] <cjwatson> that's a synchronous request
[18:56] <cjwatson> then the copy job ran
[18:56] <cjwatson> in between the delete and the second stage of copying, the publisher started
[18:56] <cjwatson> so it processed the delete and copy out of expected order
[18:57] <cjwatson> which leaves the package temporarily absent from both the published utopic and utopic-proposed suites
[18:57] <ogra_> well, couldnt rmadison maintain a cache for one publisher run ?
[18:57] <cjwatson> No, not its job
[18:57] <cjwatson> rmadison shows you what is in the archive right now
[18:57] <cjwatson> It would be terrible if it stopped doing that because it would make things harder to debug
[18:58] <ogra_> true
[18:58] <cjwatson> The right way to improve this is to add an atomic move request to LP
[18:58] <cjwatson> That would be async, but it would always preserve the order
[18:58] <cjwatson> Probably just copyPackage(move=True)
[18:59] <cjwatson> Anyway, it's publishing right now, should be done in <20min
[19:00] <ogra_> yeah, i'm patient
[19:00] <cjwatson> And to further clarify what I said above: it's absolutely normal for the package to not show up in any published state in the LP UI for a while, but it's an unusual chance event if it goes missing from rmadison
[19:00] <cjwatson> Hope that makes sense
[19:00] <ogra_> it does
[19:01] <ogra_> i just never had it occur to me
[19:01] <ogra_> until a few weeks ago
[19:01] <cjwatson> It actually gets more probable as we make the publisher faster :)
[19:01] <ogra_> :)
[19:02] <cjwatson> I deployed a change a day or two ago which speeds up the germinate stage of the publisher (which runs at the end, typically in parallel with things like proposed-migration)
[19:02] <cjwatson> So that could have tweaked the probabilities
[19:05] <cjwatson> Anyway, I should do the atomic-move thing, since that would close this window for good.  Might see if I have time tomorrow
[19:20] <ogra_> [19:20] <sil2100> \o/
[19:20] <sil2100> YAY
[19:20] <sil2100> :)
[19:21] <ogra_> (bot should pick up in 5)
[19:27] <charles> ogra_: as a postscript to the discussion about sleep on different devices... I just had an alarm go off on my n4 after it had been unplugged and asleep for an hour :)
[19:27] <ogra_> charles, \o/
[19:27] <ogra_> cool !!!
[19:29] <imgbot> [19:30] <Ursinha> sil2100: hey :) are all unit tests passing for you on cu2d trunk?
[20:06] <cjwatson> ogra_,robru: https://bugs.launchpad.net/launchpad/+bug/1329052
[20:07]  * ogra_ subscribes
[20:08] <sil2100> Ursinha: hey!
[20:08] <sil2100> Ursinha: didn't try yet ;) Let me do that tomorrow
[20:09] <Ursinha> alright :P
[20:49] <imgbot> [20:49] <imgbot> [21:01] <dobey> ugh, i forgot the architecture fix i made for unity-scope-click isn't in trunk yet, so the package is held in proposed because of a binary dep that's not satisfiable on arm64 :-/
[21:10] <robru> dobey, can you clarify what's going on there? the version stuck in proposed contains your fix
[21:13] <dobey> robru: yes, it contains the fix for the gcc 4.9 issue. but the previous upload was held in proposed because we introduced a binary dep on ubuntu-sdk-libs, which is not built on arm64. i fixed this in our /devel branch, but apparently that hasn't made it to trunk yet. for the previous upload the migration was overridden
[21:14] <robru> dobey, ah, the previous upload introduced that. ok i was wondering about that, because your upload clearly couldn't cause that ;-)
[21:14] <robru> cjwatson, ^^ can we get a manual override on unity-scope-click in proposed?
[22:45] <robru> tedg, you around? what happened in silo 2? dbus-test-runner was never built
[22:46] <robru> Laney, ^
[22:47] <robru> so that MP is just syncing the archive to the trunk, no idea why this is in a silo.
[22:47] <robru> I'm removing it
[22:48] <cjwatson> dobey,robru: can't see any evidence of the previous upload having been forced
[22:48] <cjwatson> that said it does seem to be uninstallable on arm64 right now
[22:49] <cjwatson> how strange
[22:50] <robru> cjwatson, no idea, it's dobey's thing ;-)
[22:50] <cjwatson> I wonder if it was traded off against some other uninstallability (one reason I hate introducing them)
[22:51] <cjwatson> dobey: forced