[08:00] <gusch> Saviq: ping
[08:00] <Saviq> gusch, pong
[08:00] <gusch> Saviq: what size should the app icons be, and where should they be installed?
[08:01] <gusch> Saviq: because the icons are not square ...
[08:01] <Saviq> gusch, yeah, they are not square in the new Unity, either
[08:03] <Saviq> gusch, i.e. they're not meant to be square
[08:03] <gusch> Saviq: so installing to 256x256 or 128x128 is not very logical ...
[08:03] <Saviq> gusch, put them in /usr/share/icons/{64,128,256...}
[08:03] <gusch> Saviq: there are some in "128", but they are 144x134
[08:04] <Saviq> gusch, I'm not really sure what's the guideline here :/
[08:04] <Saviq> gusch, but I'd render them to 128x*, preserving aspect width
[08:05] <Saviq> and put in the respective dirs
[08:05] <gusch> Saviq: ok - I'll do that then
[08:18] <didrocks> sil2100: compiz sponsored on quantal, sorry it was so long, but other priorities :) Thanks!
[08:18] <didrocks> popey: FYI ^
[08:19] <popey> \o/
[08:20] <popey> thanks didrocks
[08:21] <tsdgeos> Saviq: so what approach do you want to take with the todo/fixme reduction? i see kgunn created a document for it but it's mostly skeleton so not sure how to proceed here
[08:22] <Saviq> tsdgeos, I think we should go through them and identify those that can be gotten rid of now
[08:22] <Saviq> tsdgeos, with little effort (and only those that won't go away soon anyway, like the bunch in Dash*.qml)
[08:23] <Saviq> tsdgeos, and put your findings in the doc with some convention
[08:23] <Saviq> to mark those that we don't care about and those that should be fixed sooner than later
[08:24] <Saviq> tsdgeos, that sound sane?
[08:24] <tsdgeos> Saviq: so first go through them all, try to annotate into easy/hard+reason and then once we have that go through the list and fix the easy ones?
[08:25] <Saviq> tsdgeos, that sounds perfect
[08:25] <tsdgeos> okidoki
[08:25] <tsdgeos> might take a good while :D
[08:25] <Saviq> tsdgeos, we'll then go through the remaining ones and sprout work items
[08:25] <Saviq> tsdgeos, yeah, I was surprised by the amount of them...
[08:26] <sil2100> didrocks: \o/ Tghanks!
[08:26] <didrocks> sil2100: thanks to you! :)
[08:26] <sil2100> It was a busy period, so no worries ;)
[08:30] <davidcalle> didrocks, hey
[08:31] <didrocks> salut davidcalle!
[08:31] <davidcalle> didrocks, lp projects are here, now, we have to move branches
[08:32] <didrocks> davidcalle: yeah! sounds a good plan, you are planning to do it today?
[08:32] <didrocks> davidcalle: when doing that, we need to change the daily release configuration files
[08:32] <didrocks> and redeploy
[08:34] <davidcalle> didrocks, I'll do it in a moment
[08:36] <didrocks> great ;)
[08:37] <tsdgeos> Saviq: so did you agree with ted in a way to move forward the hudclient-2 thing? anyone that uses the ./build -s thing now gets something that doesn't build
[08:37]  * davidcalle branches and pushes 
[08:37] <Saviq> tsdgeos, no I didn't, it's not built anywhere
[08:37] <Saviq> tsdgeos, that I know
[08:38] <tsdgeos> right
[08:38] <tsdgeos> so we need to get it build asap
[08:38] <tsdgeos> right?
[08:38] <Saviq> tsdgeos, well, trunk is fine until new hud is built
[08:39] <tsdgeos> Saviq: not if you use ./build_unity -u, no?
[08:39] <tsdgeos> that'll get you a hud that gives you hudclient2 instead of hudclient1
[08:39] <Saviq> tsdgeos, fine in the CI / autolanding sense
[08:39] <tsdgeos> sure
[08:39] <tsdgeos> maybe we want to change build so it gives us the last rev that provides hudclient1?
[08:40] <tsdgeos> i mean people that read http://www.omgubuntu.co.uk/2013/04/how-to-run-unity-next-on-your-desktop are going to get a failure :D
[08:40] <Saviq> hmm that's a good idea
[08:40] <Saviq> to have a "safe_rev" numbers in build
[08:40] <Saviq> and pull those in
[08:40] <Saviq> and update them as needed
[08:41] <Saviq> tsdgeos, will do
[08:41] <davidcalle> didrocks, shouldn't we create a project group to have a place where we can have an overview of all our scopes?
[08:42] <tsdgeos> Saviq: great :)
[08:42] <davidcalle> (branches are here)
[08:43] <didrocks> davidcalle: yeah, sounds like a good plan :)
[08:43] <davidcalle> didrocks, I don't have rights to do that, do you mind making one?
[08:44] <didrocks> davidcalle: I think you need to ping on #launchpad, I don't as well
[08:44] <davidcalle> didrocks, ok. Any preference for the name? Ubuntu-scopes, unity-scopes?
[08:46] <didrocks> davidcalle: unity-scopes makes sense to me :)
[08:46] <davidcalle> didrocks, sounds good to me
[08:46] <duflu> didrocks: Compiz project cleanup is now *done*. Feel free to hide/freeze/whatever lp:compiz/raring
[08:47] <duflu> Hmm and "trunk" ?
[08:47] <didrocks> duflu: lp:compiz/raring can be removed
[08:48] <didrocks> duflu: I already point to lp:compiz/0.9.9 since tonight
[08:48] <duflu> didrocks: Cool. Though I don't have permissions to mess with the "raring" series
[08:48] <duflu> Everything's so fine-grained now you can't always tell who does
[08:50] <didrocks> duflu: I don't know as well
[08:51] <dednick> Saviq: getting error in build setup while sshing into device after flashing device.
[08:51] <dednick> ssh_exchange_identification: Connection closed by remote host
[08:51]  * sil2100 somehow missed the switch from lp:compiz/raring to lp:compiz/0.9.9
[08:52] <Saviq> dednick, can you ssh to the device?
[08:52] <duflu> sil2100: Twas not announced. I just did it yesterday/today
[08:52] <dednick> Saviq: no.
[08:52] <Saviq> dednick, did you ./run_on_device -s first?
[08:52] <sil2100> duflu: ah, ok ;) Anyway, rebasing the merge you pointed out a few hours ago
[08:52] <Saviq> dednick, and did you enable network even before that?
[08:53] <dednick> Saviq: yes. installed the ssh keys, but code resync causes the error.
[08:53] <duflu> sil2100: Sorry, I did ask lots of people. Forgot you.
[08:53] <Saviq> dednick, you need to be able to ssh to the device
[08:53] <Saviq> dednick, `ssh phablet@127.0.0.1 -p 2222` should work, IIRC
[08:54] <dednick> Saviq: it doesnt.  ssh_exchange_identification: Connection closed by remote host
[08:54] <Saviq> dednick, `adb shell`, `ubuntu_chroot shell`
[08:54] <Saviq> dednick, you're in Ubuntu, make sure ssh is installed and all
[08:55] <Saviq> dednick, you can also use `phablet-network-setup -i` to setup ssh and there's some more info spat out, too
[08:59] <dednick> Saviq: yeah, that was it. flashed it and didnt realise ssh wasnt installed
[09:00] <Saviq> dednick, ./run_on_device -s installs ssh
[09:00] <Saviq> dednick, but you need network first, so maybe that was the issue
[09:02] <dednick> Saviq: i forgot that flashing the device would remove the wifi access
[09:04] <tsdgeos> lol, kgunn added
[09:04] <tsdgeos> g_action_group_activate_action(ag, action.toUtf8().constData(), g_variant_new_double(value.toDouble()));
[09:04] <tsdgeos> to the TODO list of things to fix
[09:04] <tsdgeos> i was wondering why
[09:04] <tsdgeos> then realized it
[09:04] <tsdgeos> value."toDo"uble()
[09:05] <Saviq> lol
[09:10] <duflu> Heh. Try egrep '\<TODO\>' instead
[09:10] <sil2100> duflu: resubmitted both branches, since the previous one had a conflict due to the branch switch - but it now should be ok ;)
[09:11] <duflu> sil2100: OK, but I'm not offering to re-join the compiz effort. Although I would often like to, I am focussed on Mir. That was a once-off project cleanup to keep everyone on the right track
[09:14] <duflu> Even updating all the bugs I got a predictable number of emails in response... "can you help me with Compiz?"
[10:08] <Saviq> dednick, can you do https://code.launchpad.net/~saviq/unity/phablet.protect-local-build-revisions/+merge/156793 please?
[10:09] <dednick> Saviq: sure
[10:10] <Saviq> dednick, pushed a whitespace fix
[10:12] <dednick> Saviq: does this fix a current build issue with the hud? mhr3 was just having issues building with trunk unity/phablet.
[10:13] <dednick> Saviq: but his issue may have to do with something else.
[10:14] <Saviq> dednick, yes it does
[10:14] <Saviq> dednick, HUD bumped API version in trunk, but didn't yet build packages
[10:14] <Saviq> dednick, so we have MPs to fix it, but can't yet merge into trunk as it won't build
[10:15] <dednick> mhr3:  can you try 'build -s' with with lp:~saviq/unity/phablet.protect-local-build-revisions
[10:15] <mhr3> on it
[10:15] <Saviq> mhr3, if your error was related to hud-client-2 missing, that will fix
[10:15] <Saviq> mhr3, we got out of sync with HUD API versions, the usual, you know...
[10:15] <mhr3> Saviq, nope, it was about test-voice failing to link
[10:16] <Saviq> mhr3, so failure in HUD itself?
[10:16] <mhr3> yea
[10:16] <Saviq> mhr3, ok, please ping if it doesn't go away
[10:16] <mhr3> k
[10:22] <dednick> Saviq: new script works for me. +1
[10:22] <Saviq> dednick, cheers
[10:24] <tsdgeos> Saviq: with "move to persistent storage" you mean saving the searches (and results?) on disk?
[10:24] <Saviq> tsdgeos, yes
[10:25] <tsdgeos> ok
[10:25] <Saviq> tsdgeos, not results
[10:25] <Saviq> tsdgeos, just search terms
[10:25] <tsdgeos> ok
[10:25] <tsdgeos> so we can hint them next time?
[10:25] <Saviq> tsdgeos, yes
[10:25] <Saviq> tsdgeos, we should probably interface with Zeitgeist there
[10:25] <tsdgeos> ok
[10:36] <mhr3> Saviq, your branch didn't help me, disabled the voice tests and now it builds (i guess it's because i'm building on Q)
[10:37] <Saviq> mhr3, might be, will test on Q
[10:37] <Saviq> mhr3, thanks
[10:41] <mhr3> Saviq, ideas what /home/miso/projects/phablet/main.cpp:64:11: error: ‘class QQuickView’ has no member named ‘setTitle’
[10:41] <mhr3>  is about?
[10:41] <mhr3> same for setFlags
[10:41] <Saviq> mhr3, are you using ppa:canonical-qt5-edgers/qt5-proper?
[10:41] <mhr3> yep
[10:41]  * mhr3 double checks
[10:42] <Saviq> mhr3, that was an API change before Qt5 release
[10:42] <Saviq> mhr3, so please make sure you upgrade from that ppa
[10:42] <mhr3> Saviq, hmm, using it and nothing to upgrade :/
[10:43] <Saviq> mhr3, http://qt-project.org/doc/qt-5.0/qtgui/qwindow.html#title-prop http://qt-project.org/doc/qt-5.0/qtgui/qwindow.html#flags-prop
[10:43] <Saviq> mhr3, they're definitely there
[10:44] <Saviq> mhr3, QQuickView inherits QWindow, btw
[10:44] <Saviq> mhr3, /me tries Q
[10:45] <mhr3> yea, i see it in /usr/include, guess it's picking up something older from somewhere
[10:45] <mhr3> the question is what from where :)
[10:46] <Saviq> mhr3, /opt/qt5?
[10:46] <mhr3> Saviq, indeed
[10:46] <Saviq> mhr3, make sure you have all stuff from there dropped
[10:46] <Saviq> mhr3, and that your PATH does not include it anymore
[10:47] <mhr3> removing everything that installed things in there
[10:53] <popey> hmm. update manager has frozen on me
[10:58] <seb128> popey, cf #ubuntu-desktop, is that the same issue?
[10:59] <popey> yes, thanks
[10:59] <seb128> popey, did you kill stuff yet?
[10:59] <seb128> if not hold on
[11:02] <tsdgeos>                 showRemoteDetails = true
[11:02] <tsdgeos>                 showRemoteDetails = (frame.height - column.minimumHeight) >= labelRemotePostTime.height
[11:02] <tsdgeos> wops :D
[11:03] <mhr3> Saviq, yey, it all built! :)
[11:03] <Saviq> mhr3, :)
[11:31] <Cimi> Saviq, shall I proceed with components testing?
[11:31] <Cimi> mzanetti, what can I test of PageHeader?
[11:31] <Saviq> Cimi, mzanetti is out until Friday
[11:31] <Saviq> Cimi, and nic-doffay was working on PageHeader tests
[11:32] <Cimi> ok
[11:33] <Cimi> Saviq, those responsive things then
[11:33] <Cimi> grid and flow
[11:33] <Saviq> Cimi, aren't there tests for them already?
[11:34] <Saviq> Cimi, not for the flow there are not
[11:34] <Saviq> Cimi, what's the bottom bar status then?
[11:35] <Cimi> Saviq, yes they are already
[11:35] <Cimi> not for flow though
[11:35] <Cimi> Saviq, status... I thought I had to wait for SDK?
[11:35] <Cimi> Saviq, however
[11:35] <Saviq> Cimi, that's a status, sure, but would be good to get an update
[11:35] <Cimi> Saviq, I might add my findings
[11:36] <Saviq> Cimi, I saw they were chatting about it later yesterday
[11:36] <Saviq> Cimi, so please find out what's the status on their side, and if needed we'll merge your stuff with a huge "FIXME: this should come from SDK"
[11:37] <Cimi> Saviq, ok
[11:38] <tvoss> Saviq, ping
[11:39] <Saviq> Cimi, and responsive flow does not have tests
[11:39] <Saviq> tvoss, pong
[11:39] <Cimi> Saviq, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1163395/comments/1
[12:25] <gusch> Saviq: have you seen th update? https://code.launchpad.net/~schwann/gallery-app/gallery-app-app-icon/+merge/156659
[12:26] <Saviq> gusch, otp, will look in a bit
[12:51] <fginther> didrocks, good afternoon
[12:52] <didrocks> fginther: hey! nice work yesterday :)
[12:52] <didrocks> I saw you removed the --pin-ppa, this is not supported?
[12:53] <fginther> didrocks, thanks, the results could have been better :-(
[12:53] <didrocks> oh?
[12:53] <fginther> --pin-ppa requres a ppa argument
[12:53] <didrocks> ah
[12:53] <fginther> which wasn't passed in any of the exisiting jobs that I found
[12:53] <didrocks> ok, well, it's the same ppa that we should ping
[12:53] <didrocks> pin*
[12:53] <didrocks> so easy to modify
[12:54] <didrocks> fginther: what else did fail?
[12:54] <fginther> didrocks, so the --enable-ppa and --pin-ppa should use the same ppa?
[12:54] <didrocks> fginther: right
[12:55] <fginther> didrocks, I was hoping for better test results :-)
[12:55] <didrocks> ah ok ;)
[12:55] <didrocks> fginther: there is one more modification we need to do
[12:55] <didrocks> fginther: we need to add a --test-package
[12:55] <didrocks> or rather
[12:55] <didrocks> --test-packages
[12:55] <didrocks> we will pass unity-autopilot for unity* tests
[12:55] <didrocks> foo-autopilot bar-autopilot for others
[12:56] <fginther> didrocks, ack
[12:57] <didrocks> fginther: I'm doing the change in the daily release side to pass the "testpackages" parameter to your job
[12:57] <fginther> didrocks, wouldn't we just add that to 'packages'?
[12:57] <didrocks> fginther: no, because even if we use the full "dist-upgrade from ppa"
[12:57] <didrocks> this install needs to be done independently
[12:57] <didrocks> and not filtered
[12:57] <fginther> ok
[12:57] <didrocks> (the "packages" are redirected in a file and filtered)
[13:35] <mterry> fginther, who do I bring utah problems to?
[13:36] <fginther> mterry, sent you a message
[13:43] <fginther> didrocks, the testpackages changes are ready
[13:43] <didrocks> fginther: doing my side, was debugging something else :)
[13:43] <didrocks> fginther: once sec!
[13:43] <fginther> didrocks, no problem, also fixed the missing --pin-ppa
[13:43] <didrocks> \o/
[13:45] <bregma> didrocks, I have a 7.0.0 unity release ready (using 'make dist') with updated AUTHORS and ChangeLog file and release tag (no code changes)...  should I push that directly to lp:unity?
[13:46] <didrocks> fginther: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/files/140?start_revid=140
[13:47] <didrocks> bregma: you can get it under merge and autoprooving it
[13:47] <bregma> does the automerger handle tags?
[13:48] <didrocks> bregma: the upstream merger? I doubt it though
[13:48] <didrocks> fginther: ? ^
[13:49] <fginther> didrocks, bregma I think the answer is no. the automerger just does a bzr merge and a bzr push
[13:49] <didrocks> bregma: if you are sure nothing else is merger and that your  branch is building in a pbuilder, you can directly push :)
[13:49] <didrocks> merging*
[13:50] <didrocks> fginther: ok, deployed on raring oif/indicator/unity
[13:50] <fginther> didrocks, excellent
[13:50] <didrocks> fginther: do you want to try on something? to ensure the right parameters are sent? like oif?
[13:50] <fginther> didrocks, yes
[13:50] <bregma> what do you mean by "nothing else is merging"... as in there is no automerge in progress, or just no other changes in my merge?
[13:50] <didrocks> bregma: no automerge in progress
[13:51] <fginther> bregma, unity is not currently building on jenkins
[13:51] <bregma> it's a maze of twisty little passages, all different
[13:52] <bregma> I will push right now, then upload the tarball, and wheee
[14:01] <Saviq> MacSlow, just a quick note - have a look at BorderImage for the value bar in a confirmation notification
[14:02] <Saviq> MacSlow, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-borderimage.html
[14:16] <didrocks> fginther: ok, I'm moving the head job to this format
[14:16] <didrocks> fginther: and the 100scope ppa
[14:16] <didrocks> sounds good to you?
[14:19] <fginther> didrocks, yes, I think so. I noticed a typo in the job, but it should be an easy fix
[14:19] <Saviq> tedg, hey, what's the status of HUD packages?
[14:19] <fginther> didrocks, I'll rerun the oif stack after fixing it to make sure
[14:19] <didrocks> fginther: ok, the utah-jenkins change seems good to me FYI :)
[14:20] <fginther> didrocks, thanks for looking
[14:20] <didrocks> yw :)
[14:23] <paulliu> Hi all, Want to get some comments for this MR. And would like to know if this unittest sounds. https://code.launchpad.net/~paulliu/unity/phablet-add_unit_test/+merge/156859
[14:28] <tedg> Saviq, Not sure, alesage doesn't seem to be in yet.  He was working on it last night, I don't see packages anywhere, but I'm unsure of the status.
[14:28] <Saviq> paulliu, please make sure you update https://code.launchpad.net/~paulliu/share-app/desktop_file_tweak/+merge/156560
[14:28] <paulliu> Saviq: yeah..you want it released, right?
[14:29] <Saviq> paulliu, yes, but we need the two more hints in there
[14:29] <paulliu> Saviq: ok.
[14:29] <paulliu> Saviq: wait.
[14:30] <MacSlow> Saviq, hm... ok... was initially searching for something else... but that might work as well... just need to think of a way to "port" the original cairo drawing-code to an image to be used as source
[14:30] <Saviq> MacSlow, well, you can use a rectangle with a border, but if I see correctly there's a gradient?
[14:31] <MacSlow> Saviq, yes... there's a subtle but important gradient (to give it a bit of depth)
[14:32] <Saviq> MacSlow, yeah, so I'd go for BorderImage and stretched Image for the filling
[14:32] <MacSlow> Saviq, but I've an idea already how this could work with such a BorderImage item
[14:33] <MacSlow> Saviq, I'll see to fix the remaining issues with the other branch by tomorrow.
[14:33] <Saviq> MacSlow, k
[14:37] <Saviq> paulliu, can you also do:
[14:37] <Saviq>   - in webapps-demo package: /usr/share/applications/music-player-mockapp.desktop should have "Music" as Name instead of "Music Player"
[14:37] <Saviq>   - in webapps-demo package: remove fake notepad app, especially file notepad-mockapp.desktop
[14:40] <paulliu> ok.
[14:40] <paulliu> Saviq: wait.
[14:40] <Saviq> paulliu, waiting ;)
[14:49] <didrocks> fginther: so pushed the modification on head + experimental
[14:49] <fginther> didrocks, does that take care of all the stacks now?
[14:49] <didrocks> mterry: you now have some example for the phablet stacks on head ^
[14:50] <didrocks> fginther: what do you mean?
[14:50] <fginther> didrocks, I mean all all of the check jobs now using the generic autopilot job?
[14:50] <didrocks> fginther: the stack was different set of packages and ppas, I guess we addressed both
[14:50] <didrocks> fginther: yeah
[14:50] <didrocks> fginther: let's wait for tomorrow
[14:50] <didrocks> before killing the others :)
[14:51] <mterry> didrocks, thanks
[14:52] <mterry> didrocks, why are there both packages and testpackages fields?
[14:53] <didrocks> mterry: packages are the packages we need to install by default on the system (the binary packages generated by this stack)
[14:53] <didrocks> mterry: when we install them, we filter that we only install those
[14:53] <didrocks> and don't pull anything else
[14:53] <didrocks> (or we fail the job on puropose)
[14:54] <didrocks> purpose*
[14:56] <mterry> didrocks, so I need to list all dependencies too then, not just the top packages?
[14:56] <didrocks> mterry: all the binary packages that we are going to install on this stack (and their deps if they are not installed by default)
[14:57] <didrocks> mterry: basically, we filter to avoid the following case:
[14:57] <didrocks> indicator built with bamf3
[14:57] <didrocks> procude bamf 3.1
[14:57] <didrocks> produce*
[14:57] <didrocks> then we build unity
[14:57] <didrocks> it will grab 3.1
[14:57] <didrocks> but some of the stack will fail
[14:57] <didrocks> and we don't know that we need to publish both at the same time :)
[14:58] <MacSlow> Saviq, with the BorderImage the bar looks pretty clean/correct now... created two SVGs based on the old cairo-code
[14:58] <Saviq> MacSlow, render them to PNGs
[14:58] <Saviq> MacSlow, it's cheaper on the GPU
[14:59] <MacSlow> Saviq, ok
[14:59] <paulliu> Saviq: https://code.launchpad.net/~paulliu/webapps-demo/desktop_file_tweak2/+merge/156876
[15:00] <Saviq> paulliu, cheers
[15:03] <mterry> didrocks, well, for a start, I'm just adding platform-api to the platform stack.   (my other autopilot tests will want that installable)
[15:03] <didrocks> mterry: yeah, and so add the files for the autopilot generic job
[15:04] <didrocks> mterry: and the autopilot job that needs to be started
[15:04] <mterry> didrocks, hmm?  platform-api doesn't have autopilot jobs
[15:05] <didrocks> mterry: does it need some?
[15:05] <mterry> didrocks, when will the head stack build again?
[15:05] <didrocks> mterry: when you decoment #schedule: :-)
[15:05] <didrocks> uncomment*
[15:05] <mterry> didrocks, it's xnox's package to shepherd, I'm not sure.  But I'd guess it's not a gui thing
[15:06] <didrocks> mterry: do we have integration tests on it?
[15:06] <didrocks> mterry: is xnox working on finishing that?
[15:06] <mterry> didrocks, it's got a tests directory...
[15:06] <didrocks> I don't want that we daily release something before meeting our criterias
[15:06] <mterry> didrocks, he merged a packaging branch to it.  xnox, is platform-api ready for daily release?
[15:07] <didrocks> xnox: if so, please file things in the google doc I shared with you: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVVX1BOYm1qdUtyX2xUNmdwWlhTS0E#gid=0
[15:07] <didrocks> this is done for that :)
[15:07] <didrocks> (and we need yes everywhere or a no should be justified)
[15:07] <mterry> didrocks, this is just to a PPA, so while I agree we don't want to release crap, it's less of a quality expectation
[15:08] <didrocks> mterry: well, we should take the PPA as distro
[15:08] <didrocks> mterry: I know how it goes then, and we'll have to flip the switch without finishing that
[15:08] <didrocks> so we have a one-time opportunity to get things right
[15:08] <mterry> didrocks, :)
[15:09] <didrocks> mterry: and remember we will release the iso from the ppa first :)
[15:12] <kgunn> tsdgeos: hey, bregma said his team is available as soon as 13.04 is wrapped up...and we thot fixme/todo's might be a good spot to help
[15:12] <xnox> mterry: didrocks: ack, will add to spreadsheet. Not sure there are any tests for it, as it's a wrapper api for different plug implementations, with the only currently implemented one is for libhybris, which does not have tests yet per se.
[15:13] <xnox> mterry: didrocks: autopilot style tests should be done on things that build on top of platform-api, imho.
[15:13] <kgunn> tsdgeos: he was just wanting a preview of what's to come...are you using that spreadsheet i made
[15:13] <kgunn> ?
[15:13] <didrocks> xnox: as long as we are clear on the state and "no test" is acceptable in your opinion :)
[15:13] <didrocks> xnox: yeah, I do agree, did you talk about it with upstream?
[15:13] <mterry> xnox, is src/android/tests/ useful?
[15:13] <tsdgeos> kgunn: yep
[15:13] <mterry> or does that need android to run?
[15:14] <xnox> didrocks: did not "talk to upstream about it". I should discuss if it's feasible to test it more, somehow.
[15:14] <xnox> mterry: will double check those.
[15:14] <didrocks> xnox: yeah, that's part of the job for the WI ;)
[15:14] <xnox> =D
[15:14] <kgunn> tsdgeos: cool..i'll just share that with him...wanted to make sure it'd be relevant :)
[15:14] <didrocks> xnox: so please once you talk with them, file the rationale for the "Not yet" and what will be done ;)
[15:15] <didrocks> xnox: if the cells are not enough, we can create a doc or a wiki
[15:15] <tsdgeos> kgunn: the TODO part is "done", working on the FIXME one
[15:15] <tsdgeos> kgunn: i've tried to be as through as possible on the evaluation, but some of them seemed like "i'd have to solve it to see if it's a 5 minute or 5 days job"
[15:16] <tsdgeos> then mostly went to the "5 day" side and be happy if it took you 5 minute :D
[15:16] <kgunn> tsdgeos: sure...totally understandable
[15:17] <didrocks> xnox: so, to sum up, for the "no", you are working on them, right? ;)
[15:17] <didrocks> (as you didn't mark TODO everywhere) ;)
[15:18] <didrocks> like "missing libhybris" should be "upload libhybris to the ppa" ;)
[15:18] <didrocks> thanks xnox ;)
[15:18] <didrocks> xnox: you are doing libhybris, isn't it?
[15:18] <didrocks> or is it sergio?
[15:19] <xnox> didrocks: I really really prefer autolanding libhybris somehow =) even in the sense that it's not a "true" auto-land.
[15:19] <xnox> didrocks: generally package maintainance this way is awesome =)
[15:19] <xnox> didrocks: I don't think I was on the hook for libhybris.
[15:19] <didrocks> xnox: let me look at the blueprints, one sec :)
[15:19] <didrocks> xnox: the tradeoff for autolanding is that we need good tests ;)
[15:20] <didrocks> or it's the far far far west ;)
[15:21] <didrocks> xnox: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-ubuntu-touch-porting is telling that it's rsalveti
[15:21] <didrocks> xnox: do you mind checking with him and take the issue to get it daily landing if needed?
[15:22] <didrocks> as this is what is blocking everything, from what I'm hearing, mostly
[15:22] <didrocks> xnox: we can have some "on daily releasing demand" for components we are not upstream for
[15:22]  * didrocks should document the procedure
[15:26] <Saviq> paulliu, please release https://code.launchpad.net/~paulliu/unity-lens-applications/phablet/+merge/155464 too
[15:37] <paulliu> Saviq: ok
[16:38] <didrocks> hey bschaefer!
[16:39] <bschaefer> didrocks, hello!
[16:39] <didrocks> bschaefer: so I still don't get what you mean ;) what exactly has an ABI break? :)
[16:39] <didrocks> bschaefer: do you have a stack trace? when is it crashing?
[16:39] <didrocks> seb128: FYI ^
[16:39] <bschaefer> didrocks, when running the unity tests yeah
[16:39]  * bschaefer gets log
[16:39] <didrocks> bschaefer: we are running them everyday :)
[16:39] <bschaefer> didrocks, and looking at the changelog libgcc1 was updated march 28th
[16:40] <didrocks> or are those tests not run during build?
[16:40] <bschaefer> didrocks, the ones that aren't built
[16:40] <bschaefer> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1162886
[16:40] <didrocks> bschaefer: do you mind checking with doko? I doubt it only impact us if it's libgcc1
[16:40] <bschaefer> didrocks, stacktrace: http://paste.ubuntu.com/5668678/
[16:40]  * bschaefer isn't sure who doko is
[16:41] <didrocks> bschaefer: ubuntu toolchain maintainer
[16:41] <bschaefer> didrocks, full stacktrace: http://paste.ubuntu.com/5668696/
[16:41] <bschaefer> didrocks, yeah, let me go find his email
[16:41] <didrocks> bschaefer: IRC?
[16:42] <didrocks> #ubuntu-devel ;)
[16:42] <bschaefer> didrocks, to many rooms! I checked a few and didn't see him :)
[16:42] <didrocks> ;)
[16:42] <didrocks> #ubuntu-devel is still the main one for ubuntu development
[16:43] <bschaefer> didrocks, I only recently started to log into that room!
[16:43] <didrocks> ;)
[16:44] <tedg> Saviq, Uploaded!  https://launchpad.net/~indicator-applet-developers/+archive/hud-phablet
[16:45] <bschaefer> didrocks, he says hes not aware of any :(
[16:47] <didrocks> bschaefer: I saw, see #ubuntu-devel ;)
[16:47] <seb128> bschaefer, I doubt there is any ABI break
[16:47] <didrocks> I would doubt as well gcc has one
[16:47]  * bschaefer wonders why recompiling fixes problem
[16:47] <seb128> we didn't see any issue anywhere else and those libs didn't change around the time your issue started
[16:47] <didrocks> there was one last cycle due to C++11, but it was removed
[16:48] <seb128> bschaefer, can you run that test under valgrind?
[16:48] <bschaefer> but if it were an ABI break it should seg fault 100% of the time as well...
[16:48] <bschaefer> seb128, yeah let me get that info
[16:48] <seb128> bschaefer, right, ABI break don't manifest by making some % of the runs fail
[16:49] <bschaefer> seb128, yeah, I was also getting it while restarting unity sometimes as well, but not very often
[16:52]  * bschaefer has to rebuild unity to get it to crash again
[17:15] <davmor2> Hey guys u1 local music isn't showing cover art in the music lens
[17:20] <davmor2> here is an image of what I mean http://ubuntuone.com/59a6BHVg5sHOdGoPKtmoh9
[17:20] <bschaefer> seb128, it seems to not want to crash going through valgrind :(
[17:24] <seb128> bschaefer, is there any invalid read/write in the log?
[17:25] <seb128> bschaefer, often valgrind will workaround the segfault but still catch errors
[17:25] <bschaefer> seb128, o alright, let me check...also the part that is calling fontconfig is running in its own thread
[17:26] <seb128> bschaefer, fontconfig is not thread safe in the current raring version
[17:26] <bschaefer> seb128, hmm well its called through umm gtk_load something I have to look it up really quick
[17:27] <seb128> bschaefer, the next major version will be thread safe (e.g not for raring)
[17:27] <bschaefer> seb128, hmm i wonder if that could be the problem, also where is libfontconfig1 vs lp:fontconfig?
[17:27] <bschaefer> seb128, as lp:fontconfig fixes my crash, where libfontconfig1 does not in raring
[17:28] <bschaefer> seb128, heres the log, and I don't seen any invalid read/writes: http://paste.ubuntu.com/5674245/
[17:28] <seb128> bschaefer, oh, you use lp:fontconfig, that's upstream trunk which is thread safe
[17:28] <seb128> bschaefer, so yeah, that would make sense
[17:28] <bschaefer> seb128, sooo that fixes it shoot...
[17:29] <bschaefer> seb128, this is what we call: gtk_icon_info_load_icon(task->icon_info, &task->error);
[17:29] <bschaefer> with a nice comment above it:       // careful here this is running in non-main thread
[17:29] <seb128> yeah, don't do that...
[17:29] <seb128> it's late to get new fontconfig in raring
[17:29] <bschaefer> haha...welllll alright Ill have to look into removing that thread then
[17:29] <seb128> thanks
[17:29] <bschaefer> seb128, cool though, thanks for helping me look into this!
[17:30] <seb128> bschaefer, np, sorry I didn't understand earlier that you were running trunk fontconfig
[17:31] <seb128> I though you were saying that a rebuild of the same version was fixing it
[17:32] <bschaefer> oo noo, i tried to mention lp:fontconfig, but i've been confused about the crash for a bit :)
[17:33] <bschaefer> seb128, mentioning the thread part was the real problem anyway :)
[17:33] <seb128> bschaefer, I'm not using to uptodate upstream import
[17:33] <seb128> you wrote lp:fontconfig and I read ubuntu:fontconfig
[17:33] <seb128> e.g the current ubuntu version :p
[17:33] <seb128> but yeah
[17:33] <seb128> glad we figured it out
[17:33] <bschaefer> ooo haha, right that makes sense
[17:34]  * bschaefer isn't use to all the lingo yet
[17:34] <bschaefer> or rather unaware of possibly ambiguities
[17:34] <bschaefer> possible*
[17:34] <seb128> it makes me regret a bit to not have updated fontconfig to the new version with the threadsafe fixes this cycle
[17:34] <seb128> oh, well
[17:34] <seb128> next cycle ;-)
[17:35] <bschaefer> seb128, yup :), looks like this is has been using its own thread since rev:2364 very strange...
[17:35]  * bschaefer wonders if this crash has been going on for a while
[18:17] <Saviq> tedg, and will that get to ppa:phablet-team or?
[18:20] <tedg> Saviq, Not sure how we want that to work exactly.
[18:21] <tedg> Saviq, Was kinda waiting for it to build first :-)
[18:21] <tedg> Saviq, Perhaps making it dependent on both would make sense.
[18:49] <bschaefer> seb128, well looking into this more, removing the thread usage will cause this to regress: https://bugs.launchpad.net/unity/+bug/828582
[18:50] <bschaefer> seb128, sooo its going to cause a big regression in the dash loading speed :(
[18:51] <seb128> bschaefer, the merge linked in this bug is from 2012-01-25
[18:52] <seb128> which is 1.5 years old and before the LTS
[18:52] <bschaefer> seb128, yes, which is where the threads was introduced
[18:52] <seb128> do we get much real world report about that issue or is it mostly tests?
[18:52] <bschaefer> seb128, but the recent change in glib
[18:52] <bschaefer> deprecated some functions
[18:53] <bschaefer> seb128, its rare for it to crash, and I've only gotten it like twice on trunk unity
[18:53] <Marlinc> Does any of you want to help me by completing this survey? It is about clipboard usage http://goo.gl/drqfR
[18:53] <bschaefer> seb128, like 1/100 compiz --replace ccp rare
[18:53] <seb128> bschaefer, hum, what about glib changes?
[18:53] <seb128> is the issue due to changes that are to accomodate the new glib?
[18:54] <bschaefer> seb128, well glib went from 2.34 -> 2.36 causing ... let me get the change
[18:54] <bschaefer> seb128, https://bugs.launchpad.net/unity/+bug/1100658
[18:55] <bschaefer> andyrock, might now know a bit more about the new changes as well...but they both are using threads
[18:55] <seb128> does reverting that change workaround the issue?
[18:55] <bschaefer> seb128, thats what im trying to look into, im looking at compiling gcc with glib2.34
[18:55] <bschaefer> err
[18:55] <bschaefer> compiling unity with glib2.34
[18:56] <seb128> why?
[18:56] <seb128> those functions are deprecated
[18:56] <seb128> they are still there
[18:56] <seb128> just build without G_DISABLE_DEPRECATED
[18:56] <andyrock> bschaefer, compile unity with glib2.36
[18:56] <andyrock> but try to use the deprecated function
[18:56] <andyrock> *s
[18:56] <andyrock> yeah
[18:56] <bschaefer> ooo
[18:56] <bschaefer> i mis interpreted what andyrock as was saying...
[18:56] <seb128> glib never breaks compat
[18:56]  * bschaefer didn't know about that flag
[18:56] <andyrock> bschaefer, ahahahah np ;)
[18:57] <seb128> so they don't drop anything
[18:57] <seb128> they just deprecate stuff
[18:57] <bschaefer> andyrock, haha
[18:57] <seb128> but that's a build flag away
[18:57] <bschaefer> right, that makes sense, I  thought they removed it completely haha...
[18:58] <andyrock> bschaefer, btw are you sure there is a problem with "my" glib 2.36 thread code?
[18:58] <andyrock> there was little documentation on how to use it
[18:58] <bschaefer> andyrock, no i have not confirmed that, I just know this problem only started about last week
[18:58] <bschaefer> andyrock, and that other thread code has been around for 1.5 years...
[18:59] <andyrock> not the situation should be better
[19:00] <bschaefer> andyrock, well... it could be the new version is doing threading differently
[19:00] <andyrock> sorry my fault, i wanted to say: maybe the problem is "my" glib 2.36 thread code etc. etc
[19:00] <andyrock> bschaefer, ^^^
[19:00] <bschaefer> the glib stuff, causing the non-thread safe libfontconfig to crash
[19:00] <bschaefer> andyrock, right, we can look at the new code as well, lets see if reverting it fixes it :)
[19:00] <bschaefer> andyrock, if soo, then lets look at the new thread code to see if something is missing
[19:01] <andyrock> ok
[19:01]  * bschaefer forgot to turn off errors for warnings...lets rebuild agian
[19:01] <bschaefer> again*
[19:10] <bschaefer> andyrock, seg fault
[19:10] <bschaefer> hmmm
[19:11] <andyrock> using the old code path?
[19:11] <bschaefer> andyrock, yup
[19:11] <andyrock> :/
[19:11] <andyrock> same bt?
[19:11] <bschaefer> andyrock, yeaah
[19:11]  * bschaefer wonders what glib is doing differently now
[19:12] <bschaefer> andyrock, hmmm well I also don't think its your code either cause lp:fontconfig fixes it
[19:13] <bschaefer> andyrock, soo I guess the decision now is how big of a problem is this out side of the test?
[19:13]  * bschaefer reverts changes and does a lot of compiz --repalces...
[19:14] <bschaefer> seb128, ^ using the old glib functions didn't fix it...
[19:14] <seb128> bschaefer, https://errors.ubuntu.com/?package=compiz is a good place to ask that question
[19:14] <bschaefer> seb128, thanks!
[19:14]  * bschaefer forgot about errors.ubuntu.com
[19:15] <seb128> the number of 13.04 users is low compared to other series though
[19:16] <seb128> so it's not making numbers very useful :-(
[19:16] <bschaefer> seb128, yeah, but hopefully its enough to see if this crash is common or not
[19:19] <seb128> bschaefer, the fallback option is to declare it's not an issue until it shows up in there and figure a SRU plan if it does
[19:20] <bschaefer> seb128, yeah, that is what im thinking, but it never hurts to double check through these things
[19:24] <bschaefer> seb128, and I don't see it...so Ill keep an eye on the errors, ill lower the priority of the test failing bug report as well
[19:24] <bschaefer> seb128, thanks for all the information!
[19:24] <seb128> bschaefer, thanks for investigating the issue
[19:25] <seb128> the good news is that it will be fixed after raring with the new fontconfig ;-)
[19:25] <bschaefer> seb128, yup! Im excited for that :)
[19:29] <bschaefer> andyrock, hmm what should we do about the GetManyIcons gtest?
[19:29] <bschaefer> andyrock, as its quite annoying to have to re-run make check when it seg faults
[19:33] <seb128> bschaefer, we shouldn't keep tests that segfault, they break automated testing and it takes hours to run the whole build/tests again
[19:33] <bschaefer> seb128, yup, I disable it, with a comment to revert onces we have the new libfontconfig1
[19:34] <bschaefer> ill*
[19:57] <mhall119> Saviq: is there a specific reason to call qmlscene from a .desktop's Exec line, instead of having a separate script in /usr/bin/ that does it?
[19:58] <mhall119> also, isn't Architecture=any the right value for non-compiled apps?
[19:58] <Saviq> mhall119, no, any will build it for... any arch
[19:58] <Saviq> mhall119, all will build them for all
[19:58] <Saviq> once
[19:58] <Saviq> mhall119, when using bash a separate process is spawned
[19:58] <Saviq> mhall119, that's no longer associated with the original desktop file
[19:59] <mhall119> that doesn't really clear it up for me, in my mind any="one package for any arch", and all="one package for each arch"
[19:59] <Saviq> mhall119, any="a package _per_ arch"
[19:59] <Saviq> mhall119, all="one package for all arches"
[19:59] <mhall119> completely opposite of what I thought, thanks
[20:00] <Saviq> mhall119, our app management can only deal with a single process for now
[20:00] <mhall119> Saviq: ok
[20:00] <mhall119> Saviq: just wanted to check before approving these MPs
[20:01] <Saviq> mhall119, here are the three packaged up http://ubuntuone.com/4ICFnTBsks7QTgjreBROo1
[20:02] <Saviq> mhall119, pmcgowan is onto the MPs, too
[20:03] <Saviq> mhall119, you should be able to just install those and they should show up in the apps installed category (search for them if they don't fit in the two rows)
[20:04] <mhall119> Saviq: is search working in the apps lens now?
[20:04] <Saviq> mhall119, just for the installed ones, yes
[20:05] <mhall119> I mean, video and music lenses gave me a search option before, but apps lens didn't
[20:05] <Saviq> mhall119, it's new
[20:05] <Saviq> mhall119, not ideal but does the job (i.e. all the other categories are hardcoded still)
[20:06] <kgunn> Saviq: and you say i don't sleep
[20:07] <Saviq> kgunn, it's only 10pm, at least I won't be back up in 7 hrs ;)
[20:07] <mhall119> Saviq: is it enough to apt-get dist-upgrade on my device, or do I need to flash a new image?
[20:07] <Saviq> mhall119, shell should be fine, couldn't tell for anything else
[20:09] <mhall119> ok
[20:17] <kgunn> dandrader: ping
[20:18] <dandrader> kgunn, pong
[20:19] <kgunn> dandrader: hey, was thinking you might want a little break from just unit test slog
[20:19] <kgunn> dandrader: we have a "user story" we've targeted for end of april..."closing apps from the dash"
[20:20] <kgunn> dandrader: i understand we have code for it
[20:21] <kgunn> dandrader: basically we just need to port that code over (update as / if needed)
[20:21] <kgunn> dandrader: test it, create a test for it & land it
[20:22] <kgunn> dandrader: whenever you get to a stopping point with whatever you're doing now...
[20:22] <kgunn> dandrader: cool?
[20:23] <Saviq> dandrader, one important thing that I believe happened between that branch and now is the tablet, which added support for side stage apps in the apps Running category
[20:23] <dandrader> kgunn, sounds good. I can start on it already first thing in the morning.
[20:23] <Saviq> so it might require some hacking around
[20:24] <dandrader> This afternoon I was just poking at Panel indicators code, didn't start to write its test yet