[12:38] <plars> cjwatson, infinity: no desktop images since Saturday?
[12:38] <cjwatson> plars: being fixed
[12:38] <cjwatson> was due to bug 1184927
[12:39] <ubot2> Launchpad bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [High,Fix released] https://launchpad.net/bugs/1184927
[12:39] <cjwatson> in fact I was just about to kick off a rebuild
[12:41] <plars> cjwatson: how did libmailtools with the new dep make it through proposed with the missing dep? I was thinking there were pieces already in place to prevent things like this.
[12:41] <cjwatson> plars: -proposed doesn't guard against component mismatches
[12:41] <cjwatson> since they only break image builds, not (typically) upgrades, I don't mind too much
[12:42] <plars> ok, good to know
[12:42] <plars> thanks
[12:45] <cjwatson> (also, in practice the bulk of component mismatches cause package build failures, because the -dev isn't available to the build - doesn't apply to interpreted languages though)
[13:15] <ogra_> argl ... grmbl ...
[13:16]  * doko looks up Brehms Tierleben
[13:19] <ogra_> heh
[13:20]  * ogra_ forgot to move the PPA stuff out of the way when rolling ubuntu touch initrds .... another 2h waiting for a 2 line change until i can trigger a new build
[13:44] <ogra_> can someone let android-tools-adbd out of binary NEW please
[13:46] <seb128> ogra_, looking
[13:46] <ogra_> thx
[14:50] <plars> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1185053 seems to be affecting server cd images, yesterday's worked fine but todays does not
[14:50] <ubot2> Ubuntu bug 1185053 in plymouth (Ubuntu) "Saucy server images do not boot for 20130528" [Undecided,New]
[14:50] <plars> I suspect desktop images that just landed are going to have the same problem
[14:55] <cjwatson> plars: I'm looking at that right now; on the contrary I have no reason to believe desktop will be affected right now
[14:55] <cjwatson> And it sure isn't plymouth
[14:56] <plars> cjwatson: the builds seem to still get published to both pending and current, so we may want to switch the current for server at least back to yesterday's image
[14:56] <cjwatson> Let me investigate first
[14:56] <plars> cjwatson: ok, if there's anything I can do from my side let me know.
[14:56] <cjwatson> well, ok, yesterday's is there
[14:56] <cjwatson> symlink switched back
[14:57] <plars> cjwatson: indeed, the desktop install seems to be progressing
[15:41]  * ogra_ scratches head
[15:41] <ogra_> The following packages have unmet dependencies:
[15:41] <ogra_>  ubuntu-touch : Depends: android-tools-adbd but it is not installable
[15:42] <ogra_> android-tools-adbd was approved 90min ago ... so it should eb available
[15:44] <seb128> ogra_, not sure if the publisher is slow or something, it took over 2 hours for the gnome-desktop binaries to go from "accepted" to "available" this morning
[15:45] <ogra_> well, it was already in -propsed, wasnt it ? so it should only need one run
[15:45] <seb128> well, accepted from NEW to proposed should have been one run only as well
[15:45] <ogra_> i'm used to 2h for a full loop ....  but for -propsed to archive it shouldnt take that long
[15:45] <seb128> dunno what's going on, it's just an observation that things are being weird today
[15:45] <ogra_> jenkins seems to be broken
[15:46] <ogra_> but that shouldnt affect us i would think
[15:46] <cjwatson> seb128: there was a downtime for a database upgrade
[15:46] <cjwatson> which I think went on a bit longer than usual due to a new op rotating in
[15:46] <seb128> cjwatson, ah ok, that would explain it, thanks
[15:47] <cjwatson> I was watching at the time and there was nothing else odd
[15:47] <cjwatson> oh, one publisher run ran long
[15:47] <ogra_> https://launchpad.net/ubuntu/saucy/+queue?queue_state=3&queue_text=android
[15:47] <ogra_> that looks a bit weird
[15:47] <ogra_> the new binary wants to go to main ?
[16:07] <xnox> Can the i386 build of https://launchpad.net/ubuntu/+source/yade/0.97.0-1ubuntu1 be forced on a host with loads of free RAM?
[16:07] <xnox> "virtual memory exhausted: Cannot allocate memory"
[16:11] <cjwatson> xnox: I don't know that there's any difference between the available i386 builders in terms of RAM.  infinity might
[16:12] <cjwatson> xnox: A compile run that runs our builders out of memory is pretty unreasonable, though.  Consider splitting the translation unit - we've done that to packages in the past
[16:12] <slangasek> ogra_: the source is in main because of android-tools-fsutils; so unless someone overrode it at NEW time, the new binary package goes to the same component as the source; it can be demoted via component-mismatches, but OTOH, if it's seeded in ubuntu-touch, it probably should be in main?
[16:12] <slangasek> (I realize your comment implies that ubuntu-touch is currently not pinned to main, but that seems like something to fix)
[16:12] <ogra_> slangasek, it surely shall be in main at some point
[16:13] <ogra_> but wasnt urgent in the first place since we are building with a ton of universe packages anyway atm
[16:13] <slangasek> sure
[16:13] <ogra_> and i dont see anyone filing a ton of MIRs until we actually use saucy and people upload saucy etc etc
[16:13] <xnox> cjwatson: hmm... I think there was a builder with 12GB of ram, but yade was trying to build -j3. I'll flip it back to -j1 and try again at some point later.
[16:13] <cjwatson> On i386 you won't get 12GB of RAM for a single process anyway
[16:14] <slangasek> ogra_: yes - that's the #1 priority right now.
[16:14] <ogra_> right
[16:14] <ogra_> working on it :)
[16:14] <xnox> cjwatson: good point, i wonder if it's hitting the RAM limit in a translation unit as you suggested. Is it the case of adding intermediate convenience libraries to reduce the ram usage?
[16:15] <ogra_> the container flip will be done by friday ...  but cdimage wont be able to spit out the android zip we need yet ...
[16:15] <ogra_> (will be aa bit fiddly to install in the beginning due to that)
[16:15] <xnox> obviously on amd64 with 32GB it compiles just fine here & on the builds.
[16:16] <cjwatson> xnox: I don't know the source but you usually don't need convenience libraries, since these are typically objects that eventually get linked together anyway, so just splitting up the source file is often enough
[16:16] <cjwatson> ogra_: android-tools is out of date on powerpc so proposed-migration isn't promoting it to release
[16:17] <ogra_> hmpf
[16:17] <ogra_> can we override that
[16:17] <ogra_> ?
[16:17] <cjwatson> but since the last version built it should be quick to narrow down
[16:17] <cjwatson> Yes but I greatly prefer never to override such things
[16:20] <cjwatson> hm, can't easily remove the package because it will render livecd-rootfs uninstallable
[16:20] <xnox> ogra_: looks like adbd is failing on powerpc, and as far as I can tell adbd shouldn't need to be build on powerpc.
[16:21] <ogra_> yeah
[16:21] <ogra_> looks like a variable length issue
[16:21] <ogra_> in some usb code
[16:21] <cjwatson> it's a non-constant initialiser
[16:21] <cjwatson> which is not valid C
[16:21]  * xnox wonders is someone is planning to commercialise androidPOWER =) ..... nintendo?!
[16:22] <cjwatson> Though I thought GNU C permitted non-constant initialisers
[16:22] <ogra_> heh
[16:22] <cjohnston> infinity: ping
[16:22] <cjwatson> Oh, only for automatic variables, which this isn't
[16:23] <cjwatson> I love how this code goes to great care to handle endianness in such a way that if the endian conversion is non-trivial then it will fail to compile
[16:23] <tumbleweed> talking of builders and RAM, pypy has been stuck timing out for hours now https://launchpad.net/ubuntu/+source/pypy/2.0.2+dfsg-1/+build/4608301. don't know if it needs a boot
[16:23] <cjwatson> Simplest fix is probably just to build adbd only on the architectures you care about, indeed
[16:23] <ogra_> yeah
[16:24] <ogra_> can you make britney let it in as a one time so i dont have to wait for another 2h while the fix builds ?
[16:24] <cjwatson> tumbleweed: I've asked webops
[16:24] <ogra_> *one timer
[16:24] <tumbleweed> cjwatson: ta. unfortunately it'll have to be retried, unless we delete the current armhf binary
[16:24] <tumbleweed> it should build, it does on my chromebook
[16:25] <cjwatson> ogra_: done, but only for this version
[16:25] <ogra_> thanks !
[16:25] <cjwatson> you'll have to fix it if you want any further changes
[16:25] <ogra_> yeah, thats fine
[16:26] <cjwatson> tumbleweed: do you want it to retry straight away?
[16:26] <ogra_> i just want to trigger a new image while the fix builds
[16:26] <tumbleweed> cjwatson: sure
[16:26] <cjwatson> ogra_: you'll have to wait a publisher run or two anyway
[16:26] <ogra_> yeah
[16:26] <ogra_> ugh, two ?
[16:26] <ogra_> ok
[16:26] <tumbleweed> cjwatson: thanks. /me -> dinner
[16:26] <cjwatson> depends on timing of proposed-migration vs. publisher
[16:27] <cjwatson> yeah, given current proposed-migration runtime I can't make it finish before the next publisher even if I run it by hand
[16:27] <ogra_> yeah, dont bother
[16:27] <cjwatson> so ETA an hour
[16:27] <ogra_> yup
[16:29] <lamont> cjwatson: tumbleweed: it's removing the build tree now -- back over to you guys
[16:30] <cjwatson> ta, though I don't know whether it will need processes killing too
[16:30] <cjwatson> we'll see
[16:31]  * cjwatson fixes the Kubuntu image build failure
[16:51] <infinity> xnox: As cjwatson points out, that probably has nothing to do with available RAM, and everything to do with 32-bit addressing.
[17:17] <zul> can someone de-binary-new python3-testtools please?
[17:43] <Laney> I'd appreciate someone NEWing gtksourceview3 when it arrives tonight so that I can do the transition quickly in the morning tomorrow
[17:44] <Laney> pre-req-ish of eds which I'll be doing later in the week
[17:44] <Laney> seb128: ^ if you happen to be around
[17:44] <seb128> Laney, gtksourceview3? didn't we just transition that?
[17:45] <Laney> erm, sorry, gtkspell3
[17:45] <seb128> Laney, ah ok, will do
[17:45] <Laney> too many transitions on the brain
[17:45] <seb128> ;-)
[17:45] <seb128> the gnome-desktop3 one should be complete btw
[17:45] <Laney> this one is only like 4 packages
[17:45] <Laney> ah good
[18:37]  * tumbleweed prays to the buildd gods and retries pypy
[18:37] <stgraber> ;)
[19:40] <infinity> tumbleweed: It may work slightly better when we get some new buildd hardware in place.
[19:40] <infinity> tumbleweed: Its biggest issue is RAM usage and swap-death, right?
[19:44] <tumbleweed> infinity: yeah
[19:44] <tumbleweed> builds in 7 hours on a chromebook with 2GB RAM
[19:45] <tumbleweed> (once I switched to the 3/1GB memory layout)
[19:45] <infinity> tumbleweed: Kay, so it might not go too badly on highbank with 4G.
[19:45] <tumbleweed> yeah
[19:45] <infinity> tumbleweed: Does it parallelize too?
[19:45] <tumbleweed> no
[19:45] <tumbleweed> only the gcc bit
[19:45] <infinity> Kay.  So, the 4 cores are useless to it, but highbank's a bit faster than Panda, per-core.
[19:46] <infinity> And all that yummy RAM and fast(er) disk.
[19:46] <tumbleweed> the majority of build time is rpython -> C translation - one big serial python process


[02:40] <ibeardslee> yay! one less Unity gripe down and sorted
[19:58] <ibeardslee> morning
[21:14] <ajmitch> morning
[21:15] <hads> morning
[21:23] <mwhudson> morning
[21:25] <olly> morning
[21:59] <chilts> morning


[09:11] <tsdgeos> Cimi: how's the back?
[09:40] <Mirv> Saviq: ok Qt 5.4.0 Unity8 problem is probably because Oxide fails to build, because of which webbrowser fails to build, and unity8 depends on those. now that the symbols and ABI bumps are there in the landing PPA, things like these become more visible.
[09:41] <Mirv> unfortunately it means we still can't see how Unity8 would look with 5.4 :(
[09:45] <facundobatista> v
[09:46] <facundobatista> Holas
[09:46] <bpierre_> Hello, I am trying to build Unity 8 from 15.04, I ran ./build.sh -s without any issue, then ./build.sh, and I got these errors: http://paste.ubuntu.com/9538691/
[09:47] <bpierre_> It looks like some dependencies are missing, but since everything should have been installed by ./build.sh -s, I am hesitant to try to install them manually. Does anyone has any idea of what is happening?
[10:05] <vesar> mzanetti, any idea what's going wrong in pierre's setup^
[10:50] <sil2100> mzanetti: hey, you around?
[10:50] <sil2100> mzanetti: will you be taking care of silo 007 ubuntu-rtm in Saviq's stead?
[10:53] <Cimi> tsdgeos, worse than yesterday
[10:54] <tsdgeos> Cimi: dorg, :/
[10:58] <Cimi> tsdgeos, I have to go for some therapies, will be back in 1h - on the silo with the async branch only issue I see is the manage dash header colors
[10:59] <tsdgeos> Cimi: all that landed already :D
[10:59] <Cimi> tsdgeos, cool :D
[11:07] <mzanetti> sil2100: yes
[11:08] <mzanetti> vesar: well, missing dependencies
[11:09] <sil2100> mzanetti: so, silo 003 ubuntu-rtm has unity-scopes-shell in it and is ready to land (after QA sign-off), so probably you will have to rebuild it in silo 007 once that happens
[11:09] <mzanetti> ok
[11:12] <mzanetti> sil2100: actually there's an issue in that silo7...need to land something to vivid first
[11:12] <sil2100> mzanetti: what's the problem?
[11:12] <mzanetti> a bug found in testing the silo
[11:13] <mzanetti> tsdgeos: is this the fix for the issue Saviq mentioned in his mail? https://code.launchpad.net/~aacid/unity8/ellideManageDash/+merge/244831
[11:14] <tsdgeos> mzanetti: yep
[11:14] <tsdgeos> mzanetti: pstolowski's landing it to vivid
[11:14] <mzanetti> ack
[11:14] <tsdgeos> i find the need of Layout.fillWidth: true disturbing
[11:14] <pstolowski> tsdgeos, mzanetti currently building
[11:14] <mzanetti> tsdgeos: why?
[11:15] <mzanetti> pstolowski: nice, thank you. please keep me posted on this one
[11:15] <tsdgeos> mzanetti: i'd expect the column layout to do that already, or at least use the width as a maximum
[11:16] <mzanetti> tsdgeos: +1 for the width as a maximum... not so much for the fillWidth: true, as you might want to control which column stretches
[11:16] <tsdgeos> sure
[11:16] <tsdgeos> anyhow, it's just me complaining, the code should be fine :D
[11:16] <mzanetti> ok :)
[11:28] <sil2100> mzanetti, pstolowski: silo 007 is rather important to land for this milestone, so we'd really like it to be landable ;)
[11:28] <sil2100> Thanks guys!
[11:32] <pstolowski> sil2100, absolutely, i know
[11:34] <pstolowski> sil2100, when does the window close?
[11:41] <sil2100> pstolowski: by teh rules we should at least have all the fixes in silos by the end of today US TZ EOD
[11:43] <tsdgeos> dednick: added comment to https://code.launchpad.net/~nick-dedekind/unity8/lp1385331.led/+merge/241417
[11:43] <pstolowski> sil2100, what if we have another one in the queue (rtm landing 01). can we have multiple at eod?
[11:44] <pstolowski> sil2100, and also another one is still in qa testing
[11:44] <pstolowski> mzanetti, tsdgeos silo 10 has been built
[11:44] <tsdgeos> cool
[11:45] <mzanetti> pstolowski: is it already tested?
[11:46] <pstolowski> mzanetti, no, just built
[11:46] <tsdgeos> pstolowski: vivid right?
[11:46] <pstolowski> tsdgeos, yes
[11:47]  * tsdgeos flashes vivid and gives it a small deparments test
[11:48] <pstolowski> tsdgeos, pls check ebay/amazon scopes, they're pretty department-heavy
[11:48] <tsdgeos> ye
[11:48] <pstolowski> im also reflashing to test
[11:50] <vesar> mzanetti bpierre_ , Yeah I figured that out but shouldn't those dependencies be installed automatically when running the build setup. At least I can't recall I needed to manually install missing dependencies
[11:51] <mzanetti> vesar: yeah, should work in theory
[11:51] <mzanetti> haven't used it in a while
[11:52] <vesar> mzanetti, ok we'll try installing those missing ones manually. Cheers.
[11:52] <mzanetti> vesar: sudo apt-get build-dep unity8
[11:53] <mzanetti> vesar: please pastebin the output of ./build.sh if you want me to have a look why it doesn't work
[11:53] <mzanetti> ./build.sh -s
[11:58] <dednick> tsdgeos: ta
[12:01] <bpierre_> mzanetti: I am trying that now, thanks
[12:03] <mzanetti> bpierre_: looks like "./build.sh -s" fails for some reason for you. please pastebin the output of it
[12:04] <bpierre_> mzanetti: it’s compiling now, I think I just had to install these packages first
[12:05] <bpierre_> ./build.sh -s was working before, and I launched it again after the packages installation
[12:07] <Wellark> dednick: around?
[12:07] <Wellark> could we have a hangout on couple of things today?
[12:07] <Wellark> sim unlock dialog "blink" and dialog service
[12:10] <bpierre_> mzanetti: thanks very much, everything is working now!
[12:10] <mzanetti> bpierre_: great :)
[12:11] <dednick> Wellark: dont know what those are, but yes, we can.
[12:12] <Wellark> dednick: marvellous :)
[12:12] <dednick> Wellark: actually, what dialog service?
[12:12] <dednick> Wellark: i think you might be talking notifications?
[12:12] <Wellark> dednick: the discussion of splitting notifications and actual dialogs
[12:12] <Wellark> as in the dreaded pin unlock dialog
[12:12] <dednick> Wellark: right. is MacSlow not your man on thaT?
[12:13] <Wellark> dednick: sure. I just want to check something with you quickly that only affects unity8
[12:14] <dednick> Wellark: ok. now?
[12:14] <Wellark> but the primary topic is the "blink" you get with the pin unlock dialog on rtm
[12:14] <Wellark> dednick: sure
[12:14] <Wellark> let me just grab a cup of coffee
[12:14] <pstolowski> tsdgeos, uhm, something breaks with that silo
[12:14] <pstolowski> tsdgeos, go to amazon scope
[12:14] <pstolowski> tsdgeos, then baby products -> categories -> baby & toddler toys
[12:14] <pstolowski> tsdgeos, now, click '<Categories' to go back. no results  and no departments
[12:14] <pstolowski> tsdgeos, correction: results are there, but departments are missing
[12:16] <Wellark> dednick: https://plus.google.com/hangouts/_/g276vj2u5pydrnjbkxkovsjijia
[12:18] <tsdgeos> pstolowski: hmm, that's right
[12:18] <tsdgeos> let me see
[12:20] <pstolowski> tsdgeos, hmm, perhaps the scope is buggy
[12:22] <tsdgeos> why is it different on the phone than in the laptop?
[12:22] <tsdgeos> i get different layout :S
[12:26] <pstolowski> tsdgeos, yeah, no problems with ebay departments. the silo looks good to me
[12:27] <tsdgeos> pstolowski: let me see if i can repro the problem with unpatched unity8
[12:28] <Wellark> tsdgeos: did you still have the patch for compiling unity8 on utopic?
[12:28]  * Wellark should allocate some time during the holidays to upgrade all of the machines to vivid
[12:28] <pstolowski> tsdgeos, ok, great. i saw weird things before and i remember facundobatista told me about crazy stuff he needs to do to get stuff right there
[12:28] <tsdgeos> Wellark: not really sorry :/
[12:29] <Wellark> or! I could just grab utopic trunk for unity8
[12:29] <Wellark> yeah.. will do that
[12:30] <tsdgeos> pstolowski: yeah same error is in unpatched unity8
[12:30] <tsdgeos> so it should be fixed either in unity8 or in the scopes
[12:30] <tsdgeos> but is not a regression of this change
[12:30] <Wellark> Saviq: where is lp:unity8/utopic?
[12:30] <tsdgeos> Wellark: saviq's on holiday
[12:30] <tsdgeos> i don't think there is tbh
[12:31] <Wellark> lp:unity8/rtm-14.09 is probably what I want then
[12:31] <pstolowski> tsdgeos, agreed. other scopes work fine
[12:31] <pstolowski> tsdgeos, do you want to test anything else, or can i mark the silo as tested?
[12:33] <tsdgeos> pstolowski: i tested all i could think that may break, mark it as tested
[12:33] <tsdgeos> dandrader: wohoohho, summer holidays \o/
[12:34] <dandrader> tsdgeos, :D
[12:34] <facundobatista> pstolowski, tsdgeos, don't know what are you talking about, but if I can be of any help, just tell me!
[12:34] <dandrader> on countdown mode now :)
[12:35] <pstolowski> facundobatista: <pstolowski> tsdgeos, go to amazon scope
 tsdgeos, then baby products -> categories -> baby & toddler toys
 tsdgeos, now, click '<Categories' to go back. no results  and no departments
 tsdgeos, correction: results are there, but departments are missing
[12:35] <pstolowski> facundobatista, ^
[12:36]  * facundobatista checks
[12:36] <pstolowski> facundobatista, also, a couple of times while playing with amazon I got this in smart scopes proxy log:
[12:36] <pstolowski> facundobatista, [2014-12-16 12:18:33.143046] ERROR: SSRegistry: SmartScopesClient.get_search_results(): Failed to retrieve search results for query 39: unity::ResourceException: Error downloading https://dash.ubuntu.com/smartscopes/v2/amazon/search?q=&session_id=a0926175-c194-459a-ac1b-e05541f14a3d&query_id=0&platform=phone&department=Books%3A51546011&locale=en_US&filters=%7B%22sorting_primary_filter%22%3A%5B%22__featured__
[12:36] <pstolowski> %22%5D%7D%0A - server replied: Proxy Error
[12:38] <pstolowski> sil2100, silo 10 tested, can we get published asap?
[12:39] <pstolowski> mzanetti, ^
[12:44] <sil2100> pstolowski: o/
[12:44] <sil2100> pstolowski: https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731 unapproved!
[12:46] <sil2100> btw. pstolowski your team doesn't normally use top-approvals?
[12:48] <pstolowski> sil2100, uh, we do, an oversight
[12:49] <sil2100> Because if there are projects that don't do top-approvals, maybe we'll have to change the process and checks
[12:50] <dednick> tsdgeos: replied. not my fault! :)
[12:50] <dednick> tsdgeos: try cycling the screen on/off after the restart.
[13:01] <pstolowski> tsdgeos, can you top-approve that change^ ?
[13:06] <mzanetti> pstolowski: done
[13:07] <pstolowski> mzanetti, thanks!
[13:07] <pstolowski> sil2100, it's approved now
[13:40] <facundobatista> pstolowski, filed https://bugs.launchpad.net/ubuntu-rest-scopes/+bug/1403065 for the "proxy error" you mentioned, checking the other one
[13:41] <pstolowski> facundobatista, thanks
[13:54] <tsdgeos> dednick: sure a power cycle fixes it, but... is there nothing you can do?
[14:08] <facundobatista> pstolowski, and this is the bug for the other behaviour: https://bugs.launchpad.net/ubuntu-rest-scopes/+bug/1403072
[14:08] <pstolowski> facundobatista, ok, thanks
[14:15] <pstolowski> tsdgeos, mzanetti can you prepare a rtm branch for unity8 once silo 10 lands in vivid?
[14:15] <tsdgeos> i don't know how that works. mzanetti do you?
[14:15] <mzanetti> pstolowski: just waiting for it to cherry-pick the commit
[14:16] <pstolowski> ack
[14:25] <mzanetti> tsdgeos: I fail to find the place where we miss the elide mode
[14:25] <tsdgeos> whre?
[14:25] <mzanetti> https://code.launchpad.net/~aacid/unity8/ellideManageDash/+merge/244831
[14:25] <tsdgeos> mzanetti: remove "Layout.fillWidth: true" and run make tryDash
[14:25] <tsdgeos> see how it looks
[14:28] <tsdgeos> mzanetti: stuff merged
[14:39] <tsdgeos> mterry: you there?
[14:40] <mterry> tsdgeos, yup!
[14:41] <tsdgeos> mterry: how "urgent" is https://code.launchpad.net/~mterry/unity8/cleanup-greeter-dbus-test/+merge/244460 ?
[14:41] <tsdgeos> i'm a bit scared of those dbus-launch
[14:41] <tsdgeos> more when i remember Saviq mentioned he was having trouble precisely because of that in the branch he's doing to merge the tests as autopackage test
[14:41] <tsdgeos> or something
[14:41] <tsdgeos> is it ok for me to abstain and wait for next year? or we need to land this?
[14:42] <mterry> tsdgeos, it's just moving a dbus-launch call from one place to another (and adding it to the 2(?) existing tests that use that macro)
[14:42] <mterry> tsdgeos, there is another branch that deps on this one... let me find it
[14:42] <tsdgeos> mterry: you mean noone else is using add_binary_qml_test?
[14:43] <mterry> tsdgeos, ah.  https://code.launchpad.net/~mterry/unity8/test-early-disable/+merge/244461 deps on it.  So not urgent no
[14:43] <mterry> tsdgeos, one other test at least is.  Maybe two
[14:43] <mterry> tsdgeos, it's not a common macro, no
[14:43] <tsdgeos> mterry: right, 5 tests
[14:43] <tsdgeos> but the others don't use it
[14:44] <tsdgeos> i'm going to pass on this for the moment
[14:44] <mzanetti> pstolowski|lunch: tsdgeos: FYI. silo 7 building
[14:44] <tsdgeos> don't want to make it harder for Saviq than it is
[14:44] <willcooke> hrm, I think I might well have been disconnected when I sent this (if not, sorry for the spam):
 hey mzanetti - is there any way I can pass in an initial window size to an application running in u8 from the .desktop file?
 or poke it via cli to achieve the same
 (I'm happy with a hack)
[14:44] <mzanetti> willcooke: no, not yet
[14:45] <willcooke> mzanetti, no worries
[14:45] <willcooke> thx
[14:45] <mzanetti> willcooke: what's the use case?
[14:45] <mzanetti> willcooke: I guess I could try to set something more meaningful by default until we support the real thing
[14:45] <willcooke> mzanetti, it's a hacky one for xmit
[14:45] <willcooke> xmir
[14:46] <tsdgeos> kgunn: can you accept our invitation to bug control? or know who has to?
[14:46] <mzanetti> willcooke: so tell me a number and I'll default windows to that for now
[14:46] <kgunn> tsdgeos: lemme check, maybe there's a mail...
[14:46] <willcooke> mzanetti, it's fine, I can work around it.  I just restart metacity once I've resized the window and that takes care of it
[14:47] <mterry> tsdgeos, fair
[14:47] <kgunn> reminder i'm in jury pool waiting room...might disconnect abruptly
[14:47] <kgunn> and inet connection sucks
[14:50] <pstolowski|lunch> mzanetti, wait... i also need my part of the fix from silo 10...
[14:51] <mzanetti> oh
[14:52] <mzanetti> pstolowski: gimme a link please
[14:52] <mzanetti> albert's MP doesn't list it
[14:53] <pstolowski> tsdgeos, are we going to land the fix for tests + loaded=true fix in rtm? I'd think so?
[14:53] <tsdgeos> yes we should
[14:53] <pstolowski> tsdgeos, mzanetti ok i'll prepare scopes-shell MP
[14:53] <mzanetti> which one?
[14:54] <mzanetti> pstolowski: no
[14:54] <mzanetti> pstolowski: there's already everything
[14:54] <mzanetti> I just need to add that one branch
[14:54] <tsdgeos> https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731
[14:54] <mzanetti> rtm silo 7
[14:54] <tsdgeos> mzanetti: ↑
[14:54] <pstolowski> this is trunk
[14:54] <pstolowski> i need to cherry pick
[14:55] <mzanetti> pstolowski: oh.. indeed. unity-scopes-shell doesn't have a staging branch
[14:55] <mzanetti> so yes, need a new branch for it
[14:55] <mzanetti> pstolowski: let me know when you filed it
[14:55] <mzanetti> I've aborted the build
[14:57] <dednick> tsdgeos: think its a bug with unity-system-compositor. it offers the display state change, but no persistent property.
[14:59] <tsdgeos> dednick: i see
[14:59] <tsdgeos> dednick: so we bascially think the display is on?
[14:59] <pstolowski> mzanetti, tsdgeos actually, is it going to be approved for rtm if it's fixing test failure?
[14:59] <dednick> tsdgeos: yup
[14:59] <tsdgeos> pstolowski: don't understand the sentence
[15:00] <mzanetti> pstolowski: I only need a rtm branch for that one: https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731
[15:00] <mzanetti> nothing else
[15:00] <pstolowski> tsdgeos, we're not fixing rtm critical bug with the loaded=true change
[15:00] <mzanetti> exactly
[15:00] <pstolowski> mzanetti, i know
[15:00] <mzanetti> we can probably land that test fix I guess... but not with this silo
[15:00] <tsdgeos> well we are fixing one with the fix this fixes
[15:01] <tsdgeos> i.e. https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1343242
[15:01] <tsdgeos> if we're not landing that
[15:01] <tsdgeos> no we shouldn't land that fix
[15:02] <tsdgeos> mzanetti: which branches are we landing?
[15:02] <mzanetti> tsdgeos: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-007
[15:03] <pstolowski> mzanetti, right. we shouldn't land https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731 with this silo; this silo is just manage dash
[15:03] <mzanetti> you guys told me that is required for that last fix :D
[15:04] <pstolowski> sorry for confusion... too many silos in last ~3 days...
[15:04] <mzanetti> ack
[15:04] <tsdgeos> ok, so manage dash
[15:04] <mzanetti> so I'm going to build that now without further changes
[15:04] <tsdgeos> then it should not be in
[15:04] <tsdgeos> sorry
[15:04] <mzanetti> tsdgeos: yeah, manage dash and "loses focus when clicking on trusted session"
[15:05] <tsdgeos> :)
[15:05] <tsdgeos> go go
[15:05] <mzanetti> ok. buiklding
[15:05] <mzanetti> building
[15:06] <mzanetti> given this was the only issue saviq found for that branch I'm confident
[15:07] <pstolowski> mzanetti, + the fix for eliding child scopes, that's in, right?
[15:08] <mzanetti> yeah
[15:08] <mzanetti> well, that still counts as "new bottom edge"
[15:08] <mzanetti> but yes, I've cherry picked it to the rtm-staging branch
[15:19] <mzanetti> pstolowski: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-007-1-build/79/console
[15:20] <pstolowski> mzanetti, uhm, fixing
[15:22] <mzanetti> pstolowski: I guess it's this one: https://code.launchpad.net/~stolowski/unity-scopes-shell/manage-dash-rtm/+merge/244117
[15:22] <mzanetti> maybe not :D
[15:22] <mzanetti> sorry
[15:28] <dandrader> mzanetti, got my bluetooth mouse. are you able to connect it to the N7 or N10?
[15:28] <dandrader> s/it/yours
[15:28] <pstolowski> mzanetti, conflict fixed
[15:28] <mzanetti> pstolowski: thanks
[15:28] <mzanetti> dandrader: yes
[15:29] <dandrader> mzanetti, how do I do it?
[15:30] <mzanetti> pstolowski: silo building again
[15:30] <mzanetti> dandrader: so there are 3 ways atm :D
[15:30] <mzanetti> a) use qdbus to talk to bluez and do it in cmdline
[15:30] <mzanetti> b) compile my system-settings branch and install it on the device to do it graphically
[15:31] <mzanetti> c) install silo vivid/7 which has that branch already built
[15:31] <mzanetti> please make a selection for more details
[15:31] <dandrader> mzanetti, c
[15:31] <mzanetti> sudo apt-add-repository ppa:ci-train-ppa-service/landing-007
[15:32] <mzanetti> dandrader: ^
[15:32] <pstolowski> tsdgeos, so we also need to prepare silo for https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1343242
[15:32] <mzanetti> dandrader: then it should work with mice, however, BT keyboards will crash Bluez when connecting atm
[15:32] <dandrader> mzanetti, thanks!
[15:32]  * dandrader still doesn't have a bluetooh kbd
[15:33] <tsdgeos> pstolowski: we do
[15:39] <tsdgeos> pstolowski: i understand that what we do in unity8 land is have a bit rtm silo, so maybe wait for this silo to land and then prepare another one?
[15:39] <tsdgeos> mzanetti: ↑ ?
[15:40] <pstolowski> tsdgeos, we need to wait yes, but we should prepare branches (as many of them as possible) and silo already
[15:41] <pstolowski> tsdgeos, i realize you need to wait for *staging* branch to be freed for another silo
[15:41] <tsdgeos> i don't know as said i've never handled anything rtm-ish :D
[15:41] <tsdgeos> Saviq is a nice man that handles the pain for us
[15:45] <mzanetti> tsdgeos, pstolowski: yeah, I'll do that in a minute
[15:45] <mzanetti> pstolowski: we could always have a second staging branch :)
[15:45] <mzanetti> but yeah, still need to figure what the most efficient workflow is...
[15:46] <mzanetti> pstolowski: hmm... says it's still conflicting
[15:46] <pstolowski> mzanetti, i just recently opted for ditching devel+staging in our scopes-api... not without resistance... was really hard to have a good overview what's in the landing queue when everything was packed into a single branch
[15:46] <pstolowski> huh
[15:46] <mzanetti> right
[15:46] <mzanetti> pstolowski: now it's criss-cross
[15:47] <mzanetti> pstolowski: you should have merged it into your branch, and then merge that into the unity-team one
[15:47] <mzanetti> pstolowski: no problem though.. just merge yours too and we're good
[15:54] <pstolowski> mzanetti, ok, i'm not sure i did the right thing.. i've created a temp branch from rtm, merged dont-unfavorite-apps into it (with no conflicts), then merged my temporary branch into dont-unfavorite-apps-rtm and pushed it
[15:58] <mzanetti> pstolowski: I think what you'd have to do is to merge rtm into manage-dash-rtm, then push that to manage-dash-rtm
[15:58] <mzanetti> pstolowski: then merge manage-dash-rtm into dont-unfavorite-apps and push that
[15:59] <mzanetti> (because manage-dash-rtm is a prereq of dont-unfavorite-apps)
[16:00] <pstolowski> mzanetti, ah, i forgot about the prereq
[16:03] <pstolowski> mzanetti, i think you're right, got the same criss-cross error locally
[16:03] <pstolowski> mzanetti, ok, pushed both
[16:04] <mzanetti> cheers
[16:04] <mzanetti> rebuilding
[16:07] <mzanetti> tsdgeos: are you aware of any priorities on landing the other rtm branches?
[16:07] <tsdgeos> mzanetti: you mean what should we land earlier?
[16:07] <tsdgeos> not really
[16:07] <tsdgeos> everything is critical, no? :D
[16:07] <mzanetti> not in the bug tracker
[16:08] <mzanetti> the new bottom edge is just "high"
[16:08] <mzanetti> so...
[16:15] <tsdgeos> lol
[16:33] <mzanetti> tsdgeos: pstolowski: could you verify row 61 in the spreadsheet and tell me if the scope branches are good from your pov?
[16:33] <tsdgeos> url to that?
[16:34] <pstolowski> mzanetti, hey, you seem to be duplicating some of my row #58
[16:34] <mzanetti> tsdgeos: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&usp=drive_web&pli=1#gid=0
[16:34] <mzanetti> pstolowski: ah ok, looking
[16:34] <pstolowski> mzanetti, but i'm ok with that, feel free to merge
[16:34] <pstolowski> mzanetti, just rememver about the limit of fixes for rtm silo
[16:35] <mzanetti> pstolowski: yeah, I picked 3 bugs from unity8's list and added all the linked branches from those 3 bugs
[16:35] <tsdgeos> mzanetti: for bug 1384393 you need much moooooooooooore branches
[16:35] <tsdgeos> i'd leave that out tbh :D
[16:36] <mzanetti> pstolowski: I can do other fixes (not scope related) and leave the scope related ones to you and help you testing your silos
[16:36] <tsdgeos> well i mean you don't need them
[16:36] <tsdgeos> but they should land together
[16:36] <mzanetti> tsdgeos: I see
[16:36] <tsdgeos> up to moreAsyncDash
[16:36] <tsdgeos> it's all a big batch of dash changes
[16:36] <tsdgeos> i'd delay that one until we have Saviq imho
[16:39] <mzanetti> tsdgeos: which ones would you recommend?
[16:39] <mzanetti> tsdgeos: this is the list to pick from
[16:39] <mzanetti> the INPROGRESS ones are in the current silo already
[16:39] <tsdgeos> this = https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bugs?field.milestone%3Alist=68343 ?
[16:39] <pstolowski> mzanetti, so Departments fixes go with my silo?
[16:40] <mzanetti> pstolowski: I don't mind, we just have to agree on something :) did you start already with it?
[16:42] <mzanetti> tsdgeos: those branches are all linked together :D
[16:42] <pstolowski> mzanetti, i only prepared branches i owned for rtm. i need unity8 branches from you (staging2 or whatever ;))
[16:42] <tsdgeos> mzanetti: yeah...
[16:42] <tsdgeos> mzanetti: so yeah we can land moreAsyncDash and everything that goes below if you want, there's nothing much more to pick from tbh
[16:43] <tsdgeos> there's AllTheDashChanges, ManageDash, CloseSpread and https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1394208
[16:43] <tsdgeos> from what i can see
[16:43] <tsdgeos> so maybe we can just land ManageDash + CloseSpread and https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1394208 in one first
[16:44] <tsdgeos> and then try our luck with AllTheDashChanges ?
[16:44] <tsdgeos> what do you think?
[16:52] <mzanetti> tsdgeos: yeah, just found gerrys branches to
[16:52] <mzanetti> too
[16:52] <mzanetti> tsdgeos: ManageDash is already in the pipeline
[16:53] <pstolowski> mzanetti, tsdgeos guys, so how can we manage landing of departmens fix wrt unity8 branch?
[16:53] <mzanetti> pstolowski: I go with a non-scope related silo now as all the scope related branches are really interconnected. you can land whatever you want and then we'll sync back for the next one
[16:54] <tsdgeos> :)
[16:58] <pstolowski> mzanetti, ok. i'll wait with departments fix then.
[16:58] <tsdgeos> pstolowski: i think he said you land departments first (i think)
[16:58] <tsdgeos> mzanetti: ↑
[16:59] <pstolowski> tsdgeos, i can't without your unity8 fix.. can i?
[16:59] <tsdgeos> i thought you were also includin it :D
[16:59]  * tsdgeos is confused
[16:59] <tsdgeos> ah but you can't because we have to land the other stuff
[16:59] <mzanetti> pstolowski: ok... I guess I see what the issue is
[16:59] <tsdgeos> i see
[16:59]  * pstolowski 's mind is gonna blow
[16:59] <mzanetti> +1
[16:59] <mzanetti>  :D
[17:00] <mzanetti> ok. I do have space for one more fix in the silo
[17:00] <mzanetti> does that help?
[17:00] <pstolowski> \o/ take me take me pls pretty pls! :)
[17:00] <mzanetti> afaict if I pull in one of those dashes branch I'll pull in other fixes too somehow
[17:01] <tsdgeos> guys i'm going to eod, i hope you either don't need me or we can fix it tomorrow ;)
[17:01] <tsdgeos> right?
[17:01] <mzanetti> tsdgeos: ok
[17:02]  * tsdgeos waves
[17:02] <mzanetti> pstolowski: but do the unity8 and unity-scopes branches need to land together?
[17:02] <mzanetti> or just one before the other?
[17:03] <pstolowski> mzanetti, the three changes that need to land together with unity8 fix for departments are in row #58
[17:04] <mzanetti> pstolowski: down't we have to put the into the same silo then?
[17:05] <pstolowski> mzanetti, that but be ideal, otherwise my #58 needs to wait for one more unity8 landing
[17:07] <mzanetti> pstolowski: so you want to put lp:~aacid/unity8/deparment_jumping into 58, right?
[17:07] <pstolowski> mzanetti, yes, plus the other fix tsdgeos made to fix test failure
[17:08] <mzanetti> ok, works for me
[17:08] <mzanetti> I'll prepare the staging branch asap with that then
[17:08] <pstolowski> mzanetti, ok, cool
[17:09] <mzanetti> not sure if or why Saviq wants that single staging branch... but as I'm only taking over a few days I'd prefer to keep it "his way"
[17:11] <pstolowski> mzanetti, i guess because it reduces chances of conflicts to 0
[17:16] <pstolowski> mzanetti, silo 7 built
[17:20] <mzanetti> pstolowski: yeah, I'm testing already
[17:21] <mzanetti> manual test looking good
[17:21] <mzanetti> need to run automated ones still
[17:27] <pstolowski> mzanetti, how do you plan to keep just one staging branch without landing that silo 7 almost immediately?
[17:48] <mzanetti> pstolowski: afaict that's what saviq did
[17:48] <pstolowski> mzanetti, hmmm. that needs to pass qa
[17:49] <mzanetti> yeah... last time I did that it was rather quick (few hours)
[17:49] <mzanetti> so if I manage to approve silo7 soon I guess we'd be ready tomorrow morning
[17:49] <mzanetti> otherwise I'd start with a fresh branch
[17:54] <pstolowski> mzanetti, hmm i think we need everything by eod today
[17:55] <mzanetti> pstolowski: define "everything"
[17:56] <pstolowski> mzanetti, whatever you want in ota1
[17:57] <pstolowski> mzanetti, specifically, all the stuff we have pending in the spreadsheet already
[17:58] <mzanetti> pstolowski: ok, that's not possible for me
[17:58] <mzanetti> oh well
[17:58] <mzanetti> in that case I guess I create another branch
[17:59] <mzanetti> I have an ap test failing :/
[18:01] <mzanetti> phew... it was a config issue
[18:37] <hmsimha> I just noticed a UI issue that should probably be filed with launchpad, but I don't know the relevant names of the components it involves to check if it's already been filed.. can someone help me?
[18:38] <hmsimha> It involves the bar at the top of the screen (and the icons that you can click to interact with open applications -- for example with xChat it's the envelope icon)
[18:38] <hmsimha> and the applications icon list that appears when you move your mouse over to the left side of the screen
[18:40] <greyback> hmsimha: that's the "unity" project, the areas you're referring to is the "indicators"
[18:41] <hmsimha> greyback: yes, I was referring to unity's issue tracker on launchpad. The top bar and left area don't have their own names?
[18:42] <greyback> hmsimha: the top bar is the "panel" or "menu bar". The left area? Is that the colourful bar with icons along the left of the screen? If so, that's the "launcher"
[18:42] <hmsimha> yes, great! thanks
[18:43] <greyback> http://askubuntu.com/questions/10228/whats-the-right-terminology-for-unitys-ui-elements/19166#19166 is handy
[18:44] <hmsimha> greyback: excellent, thanks
[18:44] <greyback> welcome
[21:55] <pstolowski> mzanetti, hey, are you there?
[21:56] <mzanetti> pstolowski: yeah
[21:56] <mzanetti> pstolowski: I already merged the branch
[21:56] <mzanetti> you can go ahead and rebuild I think
[21:57] <pstolowski> mzanetti, cool
[21:58] <pstolowski> mzanetti, can you get somebody from your team to approve it?
[21:58] <mzanetti> pstolowski: saviq approves those himself usually (given it's just cherry picking) so I guess I can do so too


[00:00] <tsimonq2> mapreri: Because everything is in the Kubuntu packageset, Kubuntu Developers are basically Core Devs now. :P </sarcasm>
[00:21] <tsimonq2> Is zesty-security a thing?
[00:22] <tsimonq2> Ah yes nevermind
[00:37] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.2] has been marked as ready
[00:37] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.2] has been marked as ready
[05:12] -queuebot:#ubuntu-release- New binary: emacs-git-messenger [amd64] (zesty-proposed/none) [0.18-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: golang-github-nebulouslabs-bolt [amd64] (zesty-proposed/none) [1.0+git20160516.255.dfb2120-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: golang-github-go-openapi-spec [amd64] (zesty-proposed/none) [0.0~git20161119.0.f7ae86d-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: r-cran-urltools [ppc64el] (zesty-proposed/none) [1.6.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-urltools [amd64] (zesty-proposed/none) [1.6.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-urltools [i386] (zesty-proposed/none) [1.6.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-urltools [arm64] (zesty-proposed/none) [1.6.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-urltools [s390x] (zesty-proposed/none) [1.6.0-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-urltools [armhf] (zesty-proposed/none) [1.6.0-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-urltools [powerpc] (zesty-proposed/none) [1.6.0-1] (no packageset)
[06:28] -queuebot:#ubuntu-release- New: accepted emacs-git-messenger [amd64] (zesty-proposed) [0.18-1]
[06:28] -queuebot:#ubuntu-release- New: accepted golang-github-nebulouslabs-bolt [amd64] (zesty-proposed) [1.0+git20160516.255.dfb2120-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [arm64] (zesty-proposed) [1.6.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [i386] (zesty-proposed) [1.6.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [ppc64el] (zesty-proposed) [1.6.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted golang-github-go-openapi-spec [amd64] (zesty-proposed) [0.0~git20161119.0.f7ae86d-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [armhf] (zesty-proposed) [1.6.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [s390x] (zesty-proposed) [1.6.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [amd64] (zesty-proposed) [1.6.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted r-cran-urltools [powerpc] (zesty-proposed) [1.6.0-1]
[07:34] -queuebot:#ubuntu-release- New: accepted openldap [amd64] (zesty-proposed) [2.4.44+dfsg-3ubuntu2]
[07:49] -queuebot:#ubuntu-release- New: accepted diamond [amd64] (zesty-proposed) [4.0.515-3ubuntu1]
[08:09] -queuebot:#ubuntu-release- New binary: zaqar-ui [amd64] (zesty-proposed/universe) [1.0.0~rc1-2ubuntu1] (no packageset)
[14:22] -queuebot:#ubuntu-release- New source: recipes (zesty-proposed/primary) [0.12.0-0ubuntu1]