[01:19] <duflu> smspillaz, ping
[01:26] <duflu> smspillaz, nevermind. See email
[07:30] <sil2100> didrocks: morning! Still waiting for some stacks to move on and finish (apps waiting on friends etc.), but could you ACK webcreds in the meantime? I guess the change from using rm to -X is ok? http://10.97.0.1:8080/view/cu2d/view/Head/view/WebCreds/job/cu2d-webcred-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_gnome-control-center-signon_0.1.7~+13.10.20130723-0ubuntu1.diff
[07:30] <didrocks> sil2100: I know, I had to relaunch everything
[07:30] <didrocks> sil2100: you didn't finish to debug yesterday when you saw lightdm not starting?
[07:31] <didrocks> sil2100: hum, -X .la, should be -X.la, can you check that the binary is shipping the right files? (not sure what the space is doing)
[07:32] <didrocks> sil2100: also, we remove the other rm debian/*/usr/lib/*.la
[07:33] <sil2100> didrocks: I couldn't access the test machines, and since you said that lightdm is ok, I thought that there is no problem - I relunched the unity testing so that mhr3 could see what was going on
[07:33] <sil2100> didrocks: did it start crashing?
[07:33] <sil2100> didrocks: could it be that https://bugs.launchpad.net/lightdm/+bug/1203711 started happening?
[07:34] <didrocks> sil2100: ligthdm was ok with last night version
[07:35] <didrocks> sil2100: but then, the iso was refrshed
[07:35] <didrocks> with the "bad" lightdm version
[07:35] <didrocks> which has been fixed afterward in distro
[07:35] <sil2100> didrocks: right, and probably it got refreshed without the latest fix...
[07:35] <didrocks> sil2100: I wonder why you can't access btw, everyone can
[07:35] <sil2100> Right, which was still in -proposed probably ;/
[07:35] <didrocks> and it's the same account
[07:35] <didrocks> sil2100: no, the fix was even not uploaded
[07:35] <sil2100> didrocks: I know, I'm trying today
[07:36] <didrocks> sil2100: so, I fixed and blacklisted yesterday's chroot
[07:36] <sil2100> didrocks: it wasn't? I saw a -proposed version with the fix in the +source
[07:36] <didrocks> sil2100: yeah, but at the time the image was recreated, it was not even uploaded yet ;)
[07:36] <didrocks> and so, that's why I relaunched all the -check after relaunching it
[07:36] <didrocks> (and we loose several hours)
[07:36] <didrocks> I hope we can still make it in today's image
[07:37] <didrocks> sil2100: I'm stopping unity7, -check
[07:37] <didrocks> sil2100: we'll get to it later on, I need to give the machine to tvoss_ to debug Mir
[07:37] <sil2100> didrocks: geh, the same problem with logging into the machines! I guess maybe my ssh-agent is making some problems, maybe I'm forwarding my keys and this is making problems
[07:37] <sil2100> didrocks: ok
[07:37] <didrocks> sil2100: all the rest run, I think it's just a question of manual publishing
[07:37] <sil2100> didrocks: fine with me
[07:37] <didrocks> sil2100: hum, let's see together in a few, ok?
[07:37] <didrocks> but yeah
[07:38] <didrocks> I think you are forwarding your keys
[07:38] <didrocks> when you ssh to the intel machine
[07:38] <didrocks> try with -vvvv
[07:38] <didrocks> to see if it access a forwarded ssh key
[07:38] <didrocks> it should just ask for a password normally
[07:38] <didrocks> (once on magners)
[07:39] <didrocks> sil2100: ATI machine off FYI
[07:39] <didrocks> (the jenkins part)
[07:56] <Saviq> didrocks, http://ubuntuone.com/0DJgwKFpgQoN0LNKfK7qMF :0
[07:57] <didrocks> Saviq: downloading ;)
[07:57] <didrocks> (better to be good, no teaser, nothing, just waiting for the download :p)
[07:57] <Saviq> didrocks, yeah, it's kinda big ;)
[08:05] <Cimi> I have issues overriding a module..
[08:05] <Cimi> cimi@carina-vm:~/Development/unity/unity8.wallpaper/builddir$ pastebinit ../tests/mocks/GSettings/qmldir
[08:05] <Cimi> http://paste.ubuntu.com/5903298/
[08:06] <Cimi> Saviq, is that correct? ^
[08:06] <Saviq> Cimi, « QML2_IMPORT_PATH=../tests/mocks qmlplugindump GSettings 1.0 » ?
[08:06] <Cimi> and this is the cmakelists add_qml_test(. Shell IMPORT_PATHS ${CMAKE_BINARY_DIR}/plugins ${CMAKE_BINARY_DIR}/tests/mocks ${qmltest_DEFAULT_IMPORT_PATHS}
[08:06] <Cimi>                      ENVIRONMENT "LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/tests/mocks/LightDM/single")
[08:07] <Cimi> Saviq, http://paste.ubuntu.com/5903308/
[08:08] <didrocks> Saviq: I'm still at the start of the video, seeing autopilot running… ;)
[08:08] <Cimi> Saviq, in GSettings dir I only have GSettings.qml and that qmldir
[08:09] <Saviq> Cimi, yeah, that's correct
[08:10] <Saviq> Cimi, looks fine, push to a branch please?
[08:10] <Cimi> ok
[08:13] <Cimi> lp:~unity-team/unity8/unity8.background_gsettings_tests
[08:13] <Cimi> Saviq, ^
[08:20] <Saviq> Cimi, your import paths don't include the source dir, so it's not looking in there
[08:20] <Saviq> Cimi, either you need to copy to ${CMAKE_BINARY_DIR}/...
[08:20] <Saviq> Cimi, or add ${CMAKE_SOURCE_DIR}/tests/mocks to the paths
[08:21] <Cimi> Saviq, I added
[08:21] <Cimi> Saviq, look ^^
[08:21] <Saviq> Cimi, well, it's not there in the branch you've sent me
[08:21] <Cimi> add_qml_test(. Shell IMPORT_PATHS ${CMAKE_BINARY_DIR}/plugins ${CMAKE_BINARY_DIR}/tests/mocks ${qmltest_DEFAULT_IMPORT_PATHS}
[08:21] <tsdgeos> :/
[08:22] <Cimi> Saviq, yous ure?
[08:22] <tsdgeos> i've used gerry's instructions to get a unity-mir usable phone
[08:22] <Saviq> Cimi, yeah, and where's SOURCE in there?
[08:22] <tsdgeos> and now the phone gets stuck at the "Google" step
[08:22] <tsdgeos> where's gerryyyyyyyyyy
[08:22] <Saviq> Cimi, and why do you have tests/mocks twice?
[08:23] <seb128> Saviq, speaking about gsettings, did you see https://code.launchpad.net/~larsu/gsettings-qt/add-cpp-library/+merge/175901 ?
[08:23] <Saviq> seb128, yeah, never got to it yet, though
[08:23] <seb128> Saviq, ok, as long as it's on your list somewhere... ;-)
[08:23]  * seb128 wants that to land so it can send a patch for the phone-app to read the ringtone from gsettings
[08:23] <Saviq> Cimi, but anyway - just export the plugin to the binary dir
[08:23] <seb128> then teach system setting to change the value
[08:23] <Cimi> Saviq, I'm using source?
[08:24] <Saviq> Cimi, see the QMenuModel mock
[08:24] <Cimi> now
[08:24] <Cimi> or I copy cmakelists of mock
[08:24] <Cimi> as you guys prefer
[08:24] <Cimi> Saviq, ^
[08:25] <Saviq> Cimi, see QMenuModel's CMakeLists.txt
[08:25] <Saviq> Cimi, and do the same
[08:25] <Cimi> ok
[08:28] <tsdgeos> Saviq: any idea who do i ask about unity-mir stuff if gerry/ricmm are not around?
[08:29] <Cimi> Saviq, new issue
[08:30] <Cimi> Saviq, so maybe it works
[08:30] <Cimi> Saviq, problem is that the property I need is schema.id
[08:30] <Cimi> Saviq, and if you see GSettings.qml
[08:30] <Cimi> I cannot set id because it complains...
[08:30] <Saviq> tsdgeos, probably no one in this timezone
[08:31] <Saviq> Cimi, ugh, right, with 'id' I don't think you'll be able to go with QML-only
[08:31] <Cimi> *happiness*
[08:31] <Saviq> Cimi, QML will prevent you from doing that, I'm afraid
[08:31] <Cimi> ok, will fallback to c++
[08:34] <larsu> Cimi: you have a schmema with a key named 'id'?
[08:34] <Cimi> larsu, ?
[08:34] <Cimi> larsu, I'm mocking gsettings module
[08:34] <Cimi> larsu, for tests
[08:35] <larsu> Cimi: ah, I thought you were _using_ GSettings, sorry :)
[08:37] <Saviq> tsdgeos, while you're waiting, you could do wear your Qt hat and review https://code.launchpad.net/~larsu/gsettings-qt/add-cpp-library/+merge/175901 :)
[08:37] <seb128> Saviq, is there a way to do "text: "%s something" % string" in qml?
[08:37] <Saviq> seb128, "%1 something".arg(strin)
[08:37] <Saviq> g
[08:37] <tsdgeos> Saviq: actually i just realized the phone is not "stuck"
[08:38] <Saviq> tsdgeos, yeah, I imagine the shell just didn't start
[08:38] <tsdgeos> i.e. yes it's stuck in the "google" screen
[08:38] <tsdgeos> but i can adb shell
[08:38] <Saviq> tsdgeos, ↑ see who just joined? ;)
[08:38] <larsu> seb128: javascript doesn't have that afaik
[08:38] <tsdgeos> but still don't know what are the next steps
[08:38] <larsu> seb128: but you can use "abc" + x + "def"
[08:38] <tsdgeos> so i need greybackkkkkkkkkkkkkkkkkkk
[08:38] <Saviq> larsu, QString().arg() is there in QML's JS
[08:38] <Saviq> larsu, as "string" is QString
[08:38] <larsu> Saviq: javascript strings are QStrings?
[08:38] <larsu> Saviq: ah, neat
[08:38] <seb128> larsu, I can't use the "a" + "b", that's not gettext friendly
[08:38] <Saviq> yup
[08:38] <larsu> seb128: listen to Saviq!
[08:39] <seb128> in some locales the order is reverses
[08:39] <seb128> reversed
[08:39] <larsu> right, there's always that
[08:39] <Saviq> yeah, concatenation == EVIL
[08:41] <larsu> anyway, why are you guys mocking GSettings? Are you mocking all of your deps?
[08:42] <Saviq> larsu, because we need to test how we react to a changed setting
[08:42] <Saviq> larsu, so yes, we're mocking stuff like that
[08:42] <larsu> Saviq: you can do that with GSettings as well (use the memory backend)
[08:42] <larsu> I'm doing that in GSetting's tests
[08:42] <tsdgeos> larsu: you are not deleting the QGSettings you create in componentComplete, no?
[08:42] <Saviq> larsu, that's for integration, yes
[08:43] <Saviq> larsu, but we're doing kind-a-unit tests
[08:43] <Saviq> larsu, each component tested in isolation
[08:43] <larsu> Saviq: fair enough. Just seems a bit excessive to me :)
[08:43] <Saviq> larsu, btw, wrong indent on patch line 377
[08:43] <larsu> tsdgeos: I'm not? /me checks
[08:44] <larsu> tsdgeos: I'm creating it with 'this' as parent - I thought QObject deletes children for me?!
[08:44] <larsu> Saviq: oops, thanks
[08:44] <tsdgeos> larsu: right-y
[08:46] <tsdgeos> larsu: also there's a few "this->" that will make C++ purists a bit icky :D
[08:48] <larsu> tsdgeos: how big of an issue is that? (It's all over the rest of the code base as well, I'd rather keep it consistent tbh)
[08:48] <tsdgeos> it's not an issue
[08:48] <tsdgeos> it's jus stylistic
[08:48] <tsdgeos> +t
[08:49] <larsu> well, I'm maintaining it for now ;)
[08:49] <larsu> Saviq: fixed the whitespace
[09:17] <sil2100> bregma, Trevinho: hi guys, we still have the unity powerpc FTBFS, Brandon tried to find the cause, had some hypothesis but couldn't test it properly in the end - could you guys take a look at that as well? I can forward Brandon's e-mail if anything
[09:17] <sil2100> bregma, Trevinho: it's a failing unit test
[09:17] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4798459
[09:20] <Saviq> $3.3M
[09:20] <tsdgeos> sil2100: do you know that if the fact mouse wheel does not work anymore in the volume indicator is on purpose or a bug?
[09:21] <tsdgeos> Saviq: in case you haven't seen it http://ubuntu-edge.info/ is cool
[09:21] <sil2100> tsdgeos: I would personally guess that is a bug
[09:21] <sil2100> tsdgeos: could you fill in a bug for that? We probably don't have an AP test for that, where we probably should!
[09:21] <Saviq> tsdgeos, yeah, I did
[09:21] <tsdgeos> sil2100: against which project?
[09:23] <sil2100> tsdgeos: indicator-sound would make sense
[09:24] <sil2100> tsdgeos: but I would guess it might be related to some other package as well
[09:24] <tsdgeos> well let's file it there
[09:24] <tsdgeos> and see if anyone reads it :D
[09:25] <sil2100> tsdgeos: I'll poke the indicator guys about that as well - what version of indicator-sound do you have?
[09:25] <tsdgeos> ii  indicator-sound                                 12.10.2+13.10.20130722-0ubuntu1                 amd64        System sound indicator.
[09:26] <sil2100> I have the previous version and scrolling doesn't work as well! Strange
[09:27] <sil2100> Maybe something in the core indicators changed
[09:31] <seb128> sil2100, tsdgeos: it's a bug, I pointed it to larsu on the merge request for the port to gmenu
[09:31] <seb128> not sure we got a bug report for it though
[09:32] <tsdgeos> seb128: well i just created one
[09:32] <seb128> tsdgeos, thanks
[09:34] <Saviq> larsu, btw, no tests for QGSettings? ;)
[09:36] <larsu> Saviq: no exhaustive tests, but the qml module uses QGSettings now, too. So functional tests are there :)
[09:36] <Saviq> larsu, k
[09:36] <Saviq> larsu, only thing I was thinking - schemas have descriptions sometimes, right?
[09:36] <Saviq> larsu, do you think it would ever be useful to expose those?
[09:37] <Saviq> seb128, ↑ question for you, too
[09:37] <larsu> Saviq: yes, as soon as someone asks for them (I already expose some of the metadata through the the choices() method)
[09:38] <seb128> Saviq, I've never seen those exposed anywhere in a "normal UI" (only in the config editor in GNOME)
[09:38] <Saviq> seb128, yeah, that's what I thought
[09:38] <Saviq> larsu, ok, so looks good from my PoV
[09:39] <larsu> Saviq: thanks for having a look
[09:39] <Saviq> tsdgeos, you're doing a full code review of qgsettings? or did, already?
[09:40] <tsdgeos> Saviq: i had a look at the patch, the patch looks ok, did not have a full look at the code itself, want me to?
[09:40] <Saviq> tsdgeos, yeah, I meant the MR
[09:40]  * tsdgeos  is trying to get the unity-mir thing to start
[09:40] <Saviq> tsdgeos, did you catch greyback in the end?
[09:41] <tsdgeos> yes
[09:41] <Saviq> k
[09:41] <greyback> Saviq: yep, I'm here
[09:41] <greyback> tsdgeos: luck?
[09:41] <tsdgeos> greyback: on it
[09:41] <greyback> ok
[09:46] <tsdgeos> larsu: in GSettingsSchemaQml::choices would it make sense to switch the ifs?
[09:47] <tsdgeos> i.e. first check for if (parent->priv->settings == NULL) and then for if (!parent->contains(key))
[09:47] <tsdgeos> it's what the old code did, no?
[09:49] <larsu> tsdgeos: if parent->priv->settings is NULL, contains() always returns false
[09:49] <tsdgeos> seb128: larsu: https://bugs.launchpad.net/bugs/1204036 fwiw
[09:49] <seb128> tsdgeos, thanks
[09:49] <larsu> tsdgeos: because the variantmap is only populated when the settings object is created
[09:49] <larsu> tsdgeos: just responded, thanks for filing it
[09:50] <tsdgeos> larsu: sure, just saying that since this was "porting" maybe it made sense to keep the old order of the ifs, and probably checking for  parent->priv->settings is 0.00000001% faster than contains :D
[09:50] <tsdgeos> feel free to ignore
[09:51] <larsu> tsdgeos: ya, fair enough. I'll switch 'em
[09:55] <tsdgeos> http://paste.ubuntu.com/5903563/ :/
[09:56] <tsdgeos> what is this bt? http://paste.ubuntu.com/5903565/
[10:03]  * tsdgeos looks at qconf_types_to_qvariant and cries
[10:03] <tsdgeos> in how many places we have copypasted code like that
[10:04] <tsdgeos> :-/
[10:04] <tsdgeos> 3? 4?
[10:05] <tsdgeos> can someone from unity-api land finally create a lib for it
[10:05] <tsdgeos> please please please
[10:05] <larsu> tsdgeos: everyone should copy that one. It's the most comprehensive, most sane, and written by desrt
[10:05] <larsu> tsdgeos: no, a library is overkill. Copying is good enough.
[10:10] <tsdgeos> larsu: i disagree, there will be bugs and improvements to make, copying code is just horrible maintaiince wise
[10:18] <larsu> tsdgeos: not really, it's just two files that aren't used in many places. I'd be fine with a bzr submodule kind of thing though
[10:18] <larsu> but then the places that do need this kind of functionality probably have very different needs
[10:18] <larsu> qvariant <-> gvariant is just not a good mapping, despite the name
[10:19] <tsdgeos> larsu: well, dee-qt has something similar and not sure what else i was reviewing a few months ago had a copy of the dee-qt code
[10:19] <tsdgeos> and now this has a indepently written thing that does the same
[10:19] <larsu> tsdgeos: well, this is copied from qconf, not newly written
[10:19] <tsdgeos> sure
[10:19] <larsu> (and qconf is dead now)
[10:20] <tsdgeos> i'm just saying that there's at least 3 or 4 copies of similar code floating around
[10:20] <tsdgeos> i rememer adding code in one of them to support arrays or something and then stumbling upon a different one and wondering why my code had been removed
[10:20] <tsdgeos> unless i realized it was a different file
[10:21] <larsu> I understand that. I'm saying it's not that big of a deal :) Also, I'm not opposed to putting it in a shared bzr submodule
[10:21] <larsu> but *please* don't make this a lib
[10:23] <tsdgeos> what's the problem with a lib?
[10:25] <mhr3> +1 for lib
[10:25] <larsu> I think the overhead of maintaing a library for these couple of functions (and source/binary compatibility) is not worth it
[10:25] <larsu> let me ask the other way around: what's the problem with a submodule?
[10:26] <mhr3> larsu, it will get copied around without a reference to the original, ie won't be updated
[10:27] <mhr3> so not much of a difference to current copying
[10:27] <larsu> mhr3: submodules point to a bzr repo, no? All you need to do is to bump the revision number every now and then
[10:28] <mhr3> ehm, can bzr even do such thing?
[10:28] <larsu> I don't know, I assumed so...
[10:28]  * larsu should check this out before making bold claims
[10:28] <mhr3> :)
[10:31] <larsu> mhr3: I guess you're right: https://bugs.launchpad.net/bzr/+bug/267770
[10:31] <larsu> I take everything back and advocate copying files around again!
[10:31]  * larsu hides
[10:34] <tsdgeos> greyback: aloha
[10:34] <tsdgeos> greyback: http://paste.ubuntu.com/5903563/
[10:34] <larsu> tsdgeos: in any case, this shouldn't affect this merge, that code was in there before. If you feel strongly about it, please file a bug (or write that library ;) )
[10:34] <tsdgeos> larsu: sure, i'm not blocking this merge anyhow
[10:35] <tsdgeos> it was just a "let's shout and see if someone agrees/it sticks"
[10:35] <greyback> tsdgeos: if you do an "apt-get upgrade", does it want to update any package with "platform-api" in the name?
[10:35] <larsu> Saviq: tsdgeos is fine with it, you too? Can you approve it please?
[10:35] <greyback> tsdgeos: crash is due to Mir API change, the platform-api package you're using was not updated to this new API, hence crash
[10:36] <tsdgeos> greyback: but but but i just flashed this phone 3 hours ago
[10:37] <greyback> tsdgeos: welcome to my world :)
[10:37] <tsdgeos> it's a grey world!
[10:38]  * tsdgeos upgrades and sees if that helps
[10:39] <tsdgeos> yeeeee
[10:39] <tsdgeos> did not crash
[10:39] <greyback> tsdgeos: see unity on screen?
[10:39] <tsdgeos> took a good while
[10:39] <tsdgeos> but yeeeeeeeeeeees
[10:39] <greyback> it's blocking on HUD
[10:39] <greyback> dunno why, it's annoying though
[10:40] <greyback> tsdgeos: so be nice, it's pretty crappy as yet. Any app-related animations are all broken, and input doesn't get to apps yet. All on my todo list
[10:41]  * tsdgeos does the evil face/grin
[10:41] <tsdgeos> now really, what you need me to do? :-)
[10:42] <greyback> tsdgeos: unity-mir. src/modules/Unity/ApplicationManager/application_manager.cpp - I want you to add the dbus api to that
[10:42] <greyback> the API: http://studio.sketchpad.cc/EEd2PSjTRn
[10:43] <tsdgeos> greyback: oka, there's a blueprint i should get myself assigned?
[10:44] <greyback> tsdgeos: yes https://blueprints.launchpad.net/unity8/+spec/unity-mir
[10:45] <tsdgeos> BOOM firefox BOOM
[10:48] <tsdgeos> greyback: ok, snatched that blueprint item from you
[10:48] <greyback> tsdgeos: magic, thanks.
[10:50] <greyback> tsdgeos: instead of always starting up unity8 to test, this might be handy: lp:~gerboland/+junk/qml-demo-shell/
[10:51] <tsdgeos> ok
[10:58] <sil2100> greyback: hi! Since enabling autolanding might take a moment due to the requirement for modified platform-api and qtubuntu, could you maybe take a look at the packaging changes branch I made? I would merge in manually then ;)
[10:58] <sil2100> greyback: https://code.launchpad.net/~sil2100/unity-mir/packaging_cleanup/+merge/176239
[10:58] <greyback> sil2100: certainly
[10:58] <sil2100> greyback: (since I'll need Francis to do anything concrete)
[11:08] <sil2100> eeeg
[11:08] <sil2100> eeh
[11:09] <sil2100> mhr3: hi!
[11:09] <sil2100> mhr3: you know what's pissing me off today? Guess
[11:09] <mhr3> sil2100, environmental issues?
[11:10] <mhr3> sil2100, harvesting wood in jungles?
[11:10] <mhr3> sil2100, hunger?
[11:10] <sil2100> mhr3: ;D
[11:10] <sil2100> mhr3: sadly, it's something much worse than that
[11:10] <mhr3> :-O
[11:11] <mhr3> much worse?
[11:11] <mhr3> is our planet dieing?
[11:11] <sil2100> mhr3: WORSE! Unity ati testing
[11:11] <sil2100> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/575/label=autopilot-ati/console
[11:11] <sil2100> mhr3: intel had 13 failures, ONLY 13!
[11:11] <sil2100> mhr3: but ati? It seems to be stuck AGAIN
[11:12] <mhr3> sil2100, when was X/mesa last updated?
[11:14] <mhr3> sil2100, i think compiz is crashing regularly there
[11:14] <sil2100> hm, I guess there was some X update some weeks ago
[11:14] <mhr3> that's why the tests take ages
[11:14] <sil2100> I'll try logging in
[11:15] <mhr3> trying as well
[11:16] <mhr3> sil2100, it seems like the container is dead
[11:16] <sil2100> mhr3: compiz seems to run at least 30 minutes
[11:16] <mhr3> jibel, could you check the ati machine? i can't attach to it
[11:16] <sil2100> I ssh'ed to it
[11:16] <sil2100> But hm
[11:16] <sil2100> Right
[11:16] <mhr3> you did?
[11:21] <mhr3> jibel, did you just kill it, or did the kernel do it? :)
[11:24] <mhr3> dmesg says kernel did
[11:32] <nic-doffay> tsdgeos, similar question to yesterday. Any idea where the logic is contained for when you swipe left or right between scopes?
[11:35] <tsdgeos> nic-doffay: is there any logic besides calling "showHeader"?
[11:36] <nic-doffay> tsdgeos, I see the GenericScopeView has showHeader when onMovementStarted is called...
[11:36] <nic-doffay> Is that the movement for the left/right swipe?
[11:36] <tsdgeos> yeah
[11:36] <tsdgeos> all the dashes do
[11:37] <tsdgeos> ./Dash/DashVideos.qml:38:    onMovementStarted: categoryView.showHeader()
[11:37] <tsdgeos> ./Dash/DashMusic.qml:37:    onMovementStarted: categoryView.showHeader()
[11:37] <tsdgeos> etc
[11:39] <Trevinho> sil2100: I've seen that test failing there... I'll check asap if we don't have a better solution before
[11:39] <Trevinho> sil2100: the problem is testing it... Do we have a fast way (other than building a VM)?
[11:40] <sil2100> Trevinho: hmmm, not sure, maybe we could somehow enable powerpc in some PPA and get it building there, but I guess that wouldn't be faster ;/
[11:41] <Trevinho> sil2100: no it doesn't seem at all
[11:42] <seb128> sil2100, Trevinho: just turn off the buggy test on ppc to unblock?
[11:42] <Trevinho> seb128: it's probably easier to disable it for everybody... but that's a final possibility
[11:43] <seb128> well, don't block on ppc for weeks
[11:43] <seb128> do you need access to a porter box? try asking infinity, he might be able to help
[11:43] <seb128> he gave access to charles recently to debug an indicator test
[11:43] <Trevinho> seb128: ah, that would be cool
[11:45] <sil2100> seb128: we're not blocking on ppc for weeks, we're blocking on different issues in unity for weeks! I'm starting to wonder what's wrong with unity and ati
[11:46] <didrocks> sil2100: are the integration tests ok?
[11:47] <didrocks> apart from that powerpc issue?
[11:47] <mhr3> sil2100, got my msg?
[11:47] <mhr3> xchat really doesn't like switching network
[11:50] <greyback> sil2100: unity-mir packaging changes approved, thank you
[11:51] <sil2100> greyback: thanks!
[11:52] <sil2100> greyback: saaadly, it seems we'll have to wait with enabling autolanding as well
[11:52] <sil2100> jibel: ping
[11:53] <greyback> sil2100: boo :(
[11:54] <mhr3> sil2100, the second testing is still in progress so will pastebin the previous results once it finishes
[11:54] <sil2100> mhr3: ACK
[11:55] <mhr3> meanwhile.. lunch
[11:55] <sil2100> didrocks: sooo, mhr3 did some research and we think we're encountering the same recordmydesktop issue as before (which caused jibel to disable it) - but this time only on ati
[11:56] <sil2100> didrocks: mhr3 ran unity AP tests on his ati machine in his office and there was all fine, ~17 failures he had - he's re running it
[11:56] <sil2100> didrocks: we had 13 failures on intel
[11:56] <mhr3> sil2100, 16! :)
[11:56] <sil2100> didrocks: so what we would propose is to fix the powerpc FTBFS and manually publish unity FINALLY if the last test run is ok
[11:56] <sil2100> didrocks: in the meantime trying to resolve with jibel what's going on here
[11:57] <sil2100> (filling in a bug)
[12:05] <sil2100> jibel, didrocks, mhr3: https://bugs.launchpad.net/otto/+bug/1204080
[12:05] <sil2100> I would also add the unity project to that
[12:05] <sil2100> (just in case)
[12:05] <didrocks> sil2100: ok, keep me posted about your progress with jibel
[12:06] <sil2100> didrocks: would you be ok with the manual publishing for now?
[12:07] <didrocks> sil2100: if it pass on intel with few tests failing, yes
[12:12] <Saviq> mzanetti, need your opinion
[12:13] <mzanetti> Saviq: shoot
[12:13] <Saviq> mzanetti, https://code.launchpad.net/~diegosarmentero/unity8/app-preview/+merge/174419
[12:13] <Saviq> mzanetti, lines 1486 and down
[12:13] <Saviq> mzanetti, on the one hand it's not testing much
[12:13] <Saviq> mzanetti, but on the other it does test that the values are where you expect them to be
[12:14]  * mzanetti reads
[12:14] <Saviq> mzanetti, the other thing - line 1256
[12:14] <Saviq> mzanetti, should we a) test under LANG=C or b) use i18n in tests?
[12:17] <mzanetti> Saviq: for the first one I need a bit more time to run the test and understand how it works
[12:17] <jibel> sil2100, pong
[12:17] <mzanetti> Saviq: for the second one: good question. I'd probably go for LANG=C and have a separate test suite for i18n
[12:18] <sil2100> jibel: hi!
[12:19] <sil2100> jibel: did you look at that bug I filled? I know it's probably not too detailed, but we're not sure what's going on
[12:19] <sil2100> Trevinho: hi! Did you disable that test or maybe fix it?
[12:20] <jibel> sil2100, yes, I think you're right, I'll increase the memory limit to 6G. We'll se if it improves the situation
[12:20] <sil2100> Trevinho: maybe I could just quickly disable that test in overall? Since we'd like to get it released
[12:20] <sil2100> But damn, again waiting for everyting to rebuild, shit ;/
[12:21] <jibel> sil2100, done on ATI
[12:21] <jibel> you can re-run the tests if you wish
[12:22] <sil2100> jibel: ok, thanks! Would prefer to have one more fix in before doing that
[12:25] <sil2100> Ok, I'm a bit irritated now
[12:30] <sil2100> Trevinho, mhr3, didrocks, anyone: https://code.launchpad.net/~sil2100/unity/disable_failing_test/+merge/176370
[12:30] <sil2100> Since it'll take forever to get this merged, as armhf is building forever
[12:30] <sil2100> Then another 2 hour wait for it to build in the PPA
[12:31] <sil2100> This is so irritating
[12:31] <Trevinho> sil2100: approved
[12:33] <sil2100> Trevinho: thanks! Sorry for the quick hack, but I'm getting desperate
[12:33] <Trevinho> sil2100: yeah, i guess
[12:37] <mzanetti> Saviq: hmm... I think the reviews test would be more useful with different review texts/users
[12:37] <mzanetti> Saviq: so it would also check the ordering
[12:39] <tvoss_> Saviq, ping
[12:41] <Saviq> tvoss_, pong
[12:41] <Saviq> mzanetti, yeah, of course
[12:41] <Saviq> mzanetti, and ideally data-driven, too
[12:41] <tvoss_> Saviq, hey there :) x-check: no zeitgeist on the phone, correct?
[12:41] <mzanetti> Saviq: yes, I agree
[12:42] <Saviq> tvoss_, not yet, but I assumed we'll need/have it
[12:42] <Saviq> tvoss_, otherwise everyone and their dog will have to maintain a "Recent" log at varying performance quality
[12:42] <tvoss_> Saviq, we need it, but it's quite massive in terms of resource usage
[12:43] <tvoss_> Saviq, fair point, but zeitgeist is what? python iirc
[12:43] <Saviq> tvoss_, is it?
[12:43] <Saviq> tvoss_, vala, it seems
[12:44] <tvoss_> Saviq, ack, still bad, but better than python :)
[12:45] <Saviq> tvoss_, and then, if everyone kept their own event log, would that actually be better for resources than zg?
[12:45] <tvoss_> Saviq, no, but I still wonder how much sense Zeitgeist make in a content-siloed world
[12:45] <thostr_> Saviq: tvoss_: for music or media in general we might be able to use mediascanner as well
[12:46] <Saviq> tvoss_, doesn't matter, IMO
[12:46] <Saviq> tvoss_, it's just an event log
[12:46] <Saviq> tvoss_, what you put in there is your decision
[12:46] <tvoss_> Saviq, okay
[12:46] <Saviq> tvoss_, granted, we need to silo data *inside* zg so that apps can't look at each other's data
[12:46] <tvoss_> Saviq, how does a scope use it then?
[12:47] <Saviq> tvoss_, scope reads the events it's interested in, matches to $data_source, DONE
[12:48] <Saviq> tvoss_, obviously there's a question of sharing that data between $apps
[12:48] <tvoss_> Saviq, okay, so we would need security to look at it?
[12:49] <Saviq> tvoss_, probably
[12:49] <mzanetti> Saviq: I'd be ok with the autopilot-refactor merge now. What about the get_grid_units() runtime error? shall we leave it as is (no problem for me)?
[12:49] <Saviq> mzanetti, I think yes
[12:49] <mzanetti> Saviq: ok. I'll approve
[12:50] <Saviq> tvoss_, OTOH we can just say that's a shared data repository
[12:50] <Saviq> tvoss_, and you should only put data that you really need there
[12:50] <tvoss_> Saviq, I think we should talk to the security guys
[12:50] <Saviq> tvoss_, and data that doesn't pose any security issues if others get access to it
[12:53] <Saviq> asac, didrocks - we're approving the first set of unity8 integration tests, what's the next step?
[12:53] <mhr3> sil2100, something bad happened with the second run
[12:53] <asac> Saviq: nice... so we wanted to wait until we hit all green
[12:53] <asac> before adding more
[12:54] <mhr3> autopilot itself crashed... pretty weird
[12:54] <asac> but if yhou say your stuff is green, we could give it a one time try next run and see
[12:54] <asac> most likely :)
[12:54] <asac> Saviq: so what shall we run?
[12:54] <asac> can you give me the phablet-test-run command ?
[12:55] <Saviq> well, it's still in Approved, not merged yet ;)
[12:56] <Saviq> asac, but it's going to be `phablet-test-run -i -n -p unity8-autopilot unity8`
[12:56] <asac> Saviq: is that stuff already in the image?
[12:57] <asac> i thought we haltetd propagating new unity stuff for now
[12:57] <Saviq> asac, yeah, it is not
[12:57] <Saviq> asac, as I said - only Approved now
[12:57] <asac> i guess we should try to turn it on
[12:57] <asac> but be prepared to back it out
[12:57] <asac> you think thtas easy?
[12:57] <asac> how would you go about backing out?
[12:57] <asac> after landing new unity and stuff goes fully red
[12:58] <Saviq> asac, we could remove from ppa:ubuntu-unity/next
[12:58] <Saviq> asac, but would need to make sure that the previous version is still there
[12:59] <asac> Saviq: thats not backing out i feel
[12:59] <asac> thats more like "lets test more before we land"
[13:00] <Saviq> asac, what you mean by "backing out"?
[13:00] <Saviq> asac, how do we do a test-run then?
[13:00] <didrocks> Saviq: in some hangouts, but will get to you after that
[13:00] <Saviq> asac, without releasing into the ppa or the image, for that matter?
[13:00] <Saviq> didrocks, cheers
[13:01] <asac> Saviq: a real backout i mean
[13:01] <asac> e.g. we test and test and feel its ready
[13:01] <asac> we finally land
[13:01] <asac> and stuff explodes
[13:01] <asac> what do we do?
[13:01] <asac> only thing that brings us back to green in a guaranteed timeframe is to backout :)
[13:01] <asac> so having a backout plan would be nice to hav for all major stuff
[13:01] <mhr3> sil2100, i'll just run it again
[13:02] <asac> not sure if thats possible right now
[13:02] <asac> but wanted to check
[13:02] <asac> if you would have an idea
[13:02] <Saviq> asac, well, because we've stopped unity8 landing in the ppa
[13:02] <mhr3> sil2100, meanwhile here's results from the first run http://paste.ubuntu.com/5904030/
[13:02] <Saviq> asac, there's a few commits in there already that are not yet in the image
[13:02] <asac> right and those never passed our tests
[13:03] <asac> so we dont know what happens
[13:03] <asac> what we know is that its best to know how to get back to today in case the next push to ppa breaks it
[13:03] <asac> aka backout
[13:03] <Saviq> asac, well, yeah, that's why I said we need the current packages held
[13:04] <Saviq> asac, or we can revert everything between the last release
[13:04] <asac> you cannot go back
[13:04] <asac> you would have to reupload a revert revisionj
[13:04] <asac> its a limitation of archive/ppas etc.
[13:05] <Saviq> asac, well, yeah, that's what we can do
[13:06] <Saviq> asac, OTOH truth is that because we've not tested any unity8 to this point, what's the difference between reverting and just disabling the tests again...
[13:06] <Saviq> asac, assuming manual testing would pass
[13:07] <Saviq> asac, or, well, we fix it if it breaks
[13:11] <asac> Saviq: its about establishing a culture of no breakage on dashboard and learning how to get back to green in a guaranteed timeframe ... etc.
[13:11] <nic-doffay> tsdgeos, sorry having some hardware issues here.
[13:12] <nic-doffay> What triggers those onMovements thought tsdgeos ?
[13:12] <nic-doffay> *though
[13:12] <asac> there will always be reasons not to stay green, but all those reasons must stand back for the higher goal of convincing folks that we can deliver features safely, all the time
[13:13] <tsdgeos> nic-doffay: meeting,
[13:13] <nic-doffay> tsdgeos, k no worries
[13:28] <kgunn> MacSlow: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-phone
[13:28] <kgunn> ...i took the liberty some time ago to put your name by it :)
[13:29] <kgunn> also..you can always use launchpad.net/~macslow/+upcomingwork
[13:29] <mzanetti> mterry: remember the bug that om26er reported about the greeter not locking?
[13:29] <mzanetti> mterry: I just flashed my phone and now I have it too
[13:29] <om26er> its like happening every 2hours for me
[13:29] <MacSlow> kgunn, doh... forgot about that :)
[13:30] <mterry> mzanetti, stop it!  :)
[13:30] <mzanetti> mterry: yeah... just wanted to ask if you've already seen/fixed it as I've been away for a week
[13:30] <mterry> mzanetti, nope, I haven't seen it/fixed it.  :-/
[13:30] <mterry> mzanetti, how was your time off, btw?
[13:31] <mzanetti> mterry: awesome! it was a really great akademy. and the QCS was really nice too.
[13:32] <mzanetti> mterry: the 40°C killed me at times... but good thing is you get 2 new t-shirts a day at such conferences so I managed to get through :D
[13:32] <mterry> mzanetti, heh, I need to go to a conference again.  My t-shirt supply is wearing out.  Darn lack of UDS's...
[13:33] <mzanetti> mterry: good point.. I'm a bit sad that there are no saucy shirts around
[13:33] <mterry> mzanetti, we usually sell some from the store.  I wonder if we will have saucy-specific shirts by release time, or if all shirts are going to be unversioned now
[13:33] <greyback> Saviq: standup?
[13:37] <sil2100> mhr3: thanks!
[13:38] <sil2100> SHIIIT
[13:38] <sil2100> fginther: arrrghh, having problems with the armhf merger!
[13:38] <mterry> Has the meeting not started?
[13:38] <sil2100> fginther: https://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-autolanding/139/console
[13:38] <mterry> Or am I having mumble problems?
[13:38] <sil2100> fginther: again the ERROR:pbuilderjenkins:Error during build execution problem
[13:38] <sil2100> fginther: does it need fixing or re-approving is enough?
[13:38] <sil2100> fginther: (hello btw.)
[13:39]  * sil2100 is a bit nervous because of the unity stalling
[13:39] <sil2100> fginther: could we anyway merge it in without waiting for armhf to build correctly?
[13:40] <sil2100> fginther: this is a change that only disables a test, so it doesn't change anything in the code besides that, so it makes no sense for us to wait 2 hours for armhf
[13:40] <fginther> sil2100, hello! Will look in a second
[13:40] <mzanetti> mterry: can you hear us?
[13:40] <greyback> mterry: we don't hear you
[13:41] <mterry> shoot.   Skip me and I'll reconnect
[13:42] <sil2100> fginther: many thanks! I'd like to get this merged and released ASAP ;)
[13:44] <fginther> sil2100, This "W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_saucy_universe_binary-armhf_Packages  Hash Sum mismatch" is an error communicating with the archive. Please just re-approve.
[13:46] <sil2100> fginther: can we somehow force a skip of armhf for this merge btw.?
[13:46]  * sil2100 has 3vil requests
[13:46] <fginther> sil2100, hmmm, give me a minute
[13:51] <fginther> sil2100, you still there?
[13:52] <sil2100> fginther: yes! Had a phone call
[13:54] <Saviq> tsdgeos, do you know what "[aacid] plugins/HudClient/volumepeakdetector.cpp: TODO" means in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-hud-2-ui ?
[13:54] <tsdgeos> Saviq: testing it
[13:55] <Saviq> tsdgeos, ah
[13:55] <tsdgeos> it's hard to test, need to feed it fake data via pulse or something and then verify the values are good
[13:55] <tsdgeos> maybe the test part got lost when it moved from somewhere else
[13:56] <tsdgeos> isn't that dupe?
[13:56] <tsdgeos> i have
[13:56] <tsdgeos>  add tests for volumepeakdetector
[13:56] <tsdgeos> iin https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-hud-2-ui
[13:56] <tsdgeos> or you just renamed it?
[13:56] <kgunn> Saviq: so all the new hud work items are really tweaks right? no new functionality per se
[13:57] <Saviq> kgunn, yeah
[13:57] <Saviq> kgunn, just low hanging fruit
[13:57] <Saviq> kgunn, the only bigger thing is the preview
[13:58] <Saviq> kgunn, but as you've seen I put it in non-milestoned WI
[14:00] <Saviq> tedg, greyback, hangout?
[14:00] <Saviq> tedg, why U not on irc.c.c?
[14:00] <tedg> Saviq, yes, just a sec... finishing a call.
[14:01] <tedg> Saviq, I am, "ted"
[14:01] <Saviq> sneaky!
[14:01] <Saviq> I type "ted" and press <Tab>, nothing happens!
[14:02] <tedg> Saviq, I started the chat
[14:03] <Saviq> greyback, ping
[14:03] <Saviq> ?
[14:03] <greyback> Saviq: coming..
[14:04] <greyback> Saviq: tedg I can't find a link anywhere, please paste it to me
[14:05] <sil2100> mhr3: restarted the unity stack, let's keep our fingers crossed - this time the tests might even pass as jibel increated the memory limit
[14:05] <kenvandine> jibel, can you please add views in jenkins for the thin-client and click-package stacks under head?
[14:05] <mhr3> sil2100, the 3rd round of testing finished here, 17failures this time
[14:06] <jibel> sil2100, if really tests hit the limit again, we'll have to disable rmd for unity and find a real solution other than pushing the wall
[14:07] <sil2100> jibel: ACK
[14:07] <sil2100> mhr3: awesome
[14:07] <mhr3> sil2100, http://paste.ubuntu.com/5904195/
[14:07] <sil2100> mhr3: I guess if we get some problems during this run we'll publish anyway
[14:08] <sil2100> mhr3: since we anyway have to wait until everything builds before publishing, so maybe it'll manage to finish the AP tests as well
[14:08] <sil2100> mhr3: if not, we'll use your results and publish manually muhaha :E
[14:08] <mhr3> sil2100, are you taking care of opening bugs for these / or pinging Trevinho/bschafer?
[14:12] <sil2100> mhr3: for what issues you mean?
[14:12] <mhr3> sil2100, in the pastebin
[14:13] <sil2100> mhr3: I'll poke the guys once we have a release, yes :D
[14:13] <mhr3> sil2100, k, thx
[14:14] <jibel> kenvandine, done on private jenkins, CCed you on RT to do the same on public instance.
[14:14] <kenvandine> jibel, thanks!
[14:15] <tsdgeos> Saviq: i duplicated my "inprogress" tasks to a done (code) and a inprogress (get code into qt)
[14:15] <tsdgeos> s/tasks/blueprint items
[14:15] <mhr3> tedg, ping? i was told hud uses the appmanager api, how it that exposed? do you need to link with mir or unity has a dbus interface or...?
[14:17] <sil2100> tsdgeos: btw. did you fill in that bug for the scroll-not-working for indicator-sound?
[14:17] <tsdgeos> sil2100: yes
[14:18] <sil2100> tsdgeos: can you give me the link? Maybe tedg will know more what's up?
[14:18] <tsdgeos> sil2100: larsu said "was known"
[14:19] <tsdgeos> port to gmenumodel or something
[14:19] <sil2100> Ah, cool!
[14:19] <sil2100> tsdgeos, larsu: I wonder if we could have an AP test for the mouswheel scroll on indicator-sound
[14:20] <larsu> sil2100: sure we could
[14:20] <larsu> it would fail right now though :P
[14:20] <Saviq> tsdgeos, cheers
[14:21] <sil2100> :D
[14:21] <Saviq> didrocks, free?
[14:21] <tedg> mhr3, Not yet, greyback is working on the Application API, I think it'll just be a DBus interface.
[14:22] <mzanetti> kgunn: ping
[14:22] <mhr3> tedg, ah
[14:22] <mhr3> greyback, can you keep me in the loop about that
[14:22] <greyback> mhr3: ApplicationManager will have a dbus API. What do you need?
[14:22] <didrocks> Saviq: in another hangout, I'll ping you back as soon as it's finished
[14:22] <mhr3> greyback, apparently we need a scope to expose the info back to shell :P
[14:22] <greyback> mhr3: http://studio.sketchpad.cc/EEd2PSjTRn is the proposed API
[14:22] <greyback> mhr3: for an apps scope?
[14:23] <mhr3> yes
[14:23] <greyback> mhr3: ok, let me know if that API is ok. jamesh had a look and approved
[14:23] <mhr3> greyback, ok cool
[14:38] <sil2100> mhr3: unity AP tests are running on jenkins, so far so good!
[14:39] <mhr3> sil2100, we have a nice saying for this
[14:40] <mhr3> something along the lines of "don't say hop before jumping over"
[14:40] <didrocks> Saviq: I'm "free the fish" ;)
[14:40] <sil2100> Right, in Poland we have the same thing ;)
[14:40] <didrocks> sil2100: mhr3: did you get any interesting fix?
[14:40] <didrocks> or it's just a "let's try"
[14:40] <sil2100> didrocks: well, in a way, yes
[14:40] <didrocks> on the interesting fix? ;)
[14:41] <Saviq> didrocks, so, we now have a set of AP tests to run
[14:41] <Saviq> didrocks, how do we try them out?
[14:41] <sil2100> didrocks: we disabled the failing powerpc test to unblock FTBFS, and jibel bumped the memory limit
[14:41] <didrocks> Saviq: we can add them to daily release and test them
[14:41] <didrocks> Saviq: what I need is the autopilot package name (unity8-autopilot)
[14:41] <didrocks> Saviq: and a command to run (unity8_autopilot?)
[14:42] <Saviq> didrocks, yeah, but will we break *everything* in case of failure?
[14:42] <Saviq> didrocks, autopilot run unity8
[14:42] <didrocks> sil2100: ah, let's cross fingers
[14:42] <mhr3> sil2100, bumped the mem limit? wasn't it about disabling rmd?
[14:42] <didrocks> Saviq: yeah, so just "unity8" ;)
[14:42] <didrocks> Saviq: what do you mean, by breaking "everything"
[14:42] <sil2100> didrocks: soooo, we might have a proper test result - if not, we publish anyway since mhr3 made manual tests, 2 test runs on ati and the results are: 16 failures and 17 failures
[14:42] <sil2100> So it's all in my tolerance threshold ;p
[14:42] <Saviq> didrocks, at worst it will be limited to our stack, right?
[14:42] <sil2100> While intel had 13
[14:42] <didrocks> sil2100: the results are a little bit higher than what it was
[14:42] <Saviq> didrocks, which will go into manual publishing and we'll just not push unity8?
[14:42] <didrocks> sil2100: so please, ensure it will go down then :)
[14:43] <didrocks> Saviq: yeah, if tests doesn't pass, nothing will publish
[14:43] <didrocks> Saviq: it will not push unity8
[14:43] <didrocks> we can force the publication just in case
[14:43] <didrocks> but it will block first
[14:43] <Saviq> didrocks, yup
[14:43] <Saviq> didrocks, ok, let's flip the switch, then :)
[14:43] <didrocks> sil2100: time for that? ^
[14:44] <didrocks> Saviq: do we need to do anything special, we are in an unity7 session though
[14:44] <didrocks> so, do we need to kill anything and run unity8
[14:44] <sil2100> !
[14:44] <didrocks> or do running the autopilot tests do that?
[14:44] <sil2100> Publication of unity8 ;p?
[14:44] <didrocks> sil2100: having first tests running I guess :)
[14:44] <didrocks> so listing binaries from the stack
[14:44] <didrocks> test package
[14:45] <didrocks> and test to run :)
[14:45] <sil2100> didrocks: should I stop unity testing then?
[14:45] <Saviq> didrocks, no, we should be able to just start unity8 in a window currently
[14:46] <didrocks> sil2100: no no, we can let that run and prepare the unity8 config menawhile :)
[14:46] <didrocks> Saviq: so, the AP tests do that
[14:46] <didrocks> we just need to "run autopilot unity8"
[14:46] <didrocks> (in the unity7 desktop session)
[14:46] <Saviq> didrocks, yup
[14:48] <didrocks> Saviq: excellent
[14:48] <didrocks> sil2100: so having time for that configuration change? I can review it, shouldn't be a big deal I guess :) ^
[14:49] <sil2100> didrocks: sure ;)
[14:49] <didrocks> sil2100: Saviq: let's keep next at the target until we land successfully once, right?
[14:50] <sil2100> I'll have to check the branch and such
[14:50] <didrocks> then, we can look to dive into distro :)
[14:50] <sil2100> I mean, tests and such
[14:50] <sil2100> ;p
[14:50] <didrocks> yep ;)
[14:50] <Saviq> didrocks, well, MIR for unity8 is still away for some time ;)
[14:50] <didrocks> sil2100: should be unity8-autopilot package and "unity8" as the autopilot command
[14:51] <didrocks> Saviq: right, people are still ok to go to next?
[14:51] <sil2100> I see the test_suite: indeed
[14:51] <Saviq> didrocks, for the time being, yes
[14:51] <didrocks> ok :)
[14:51] <Saviq> didrocks, but we're pushing to change that asap
[14:51] <didrocks> sil2100: really? :p
[14:51] <didrocks> sil2100: I probably mislead with an IRC discussion ;)
[14:51] <didrocks> Saviq: ack!
[14:55] <sil2100> didrocks: brb in 5 minutes just! Need to jump outside to pick something up in front of my flat ;p
[15:02] <sil2100> https://code.launchpad.net/~sil2100/cupstream2distro-config/add_check_to_unity8/+merge/176407 <- work in progress, will have to check dependencies of dependencies
[15:10] <didrocks> bregma: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-2.2check/
[15:20] <mhr3> bregma, too many crashes in the AP testing, the question is whether it's caused by recordmydesktop, or there's a regression in unity/nux
[15:20] <mhr3> bregma, could you look at it pls?
[15:21] <mhr3> bregma, i wouldn't be too surprised if unity was doing overzealous free-ing in some cases after all the mem fixes
[15:22] <mhr3> but then again it might be X/drivers/recordmydesktop, fwiw i didn't see it crash on my machine and i'm running from daily build ppa
[15:23] <bregma> the oom-killer doesn't usually imply overzealous frees
[15:59] <sil2100> mhr3: HA!
[15:59] <sil2100> Just opened it as well!
[15:59] <sil2100> Still it's above our threshold, but at least it works - once armhf finished building I do a manual publish!
[15:59] <sil2100> mhr3: \o/
[15:59] <sil2100> \o\
[15:59] <sil2100> /o/
[16:00] <mhr3> sil2100, compiz still got killed a few times, that will be resonsible for a few failures
[16:00] <sil2100> Bummer
[16:03] <mhr3> sil2100, interesting difference http://imgur.com/TAzZVam
[16:04] <mhr3> you can pretty much see the crashes :)
[16:04] <sil2100> ;D
[16:04] <mhr3> eh, yea... you could if screenshotting worked
[16:10] <mhr3> so once again
[16:10] <mhr3> http://imgur.com/xSLXaL5
[16:10] <mhr3> sil2100, ^ now you can see them :)
[16:11] <sil2100> I wonder what causes those failures
[16:11] <mhr3> i don't want to know :P
[16:11] <sil2100> Let's leave it to the unity guys ;p
[16:12] <davmor2> sil2100: is playing stickman goalie
[16:18] <mhr3> sil2100, so is publishing to s underway? can we expect new stack tomorrow?
[16:18] <sil2100> mhr3: we just going to finish our desktop meeting and I'm on it
[16:20] <mhr3> finally some good news
[16:29] <sil2100> mhr3: let's browse through again through those failing AP tests and check if any of them are blockers or not
[16:29] <sil2100> mhr3: and let me fill a bug for compiz crashes, at least a non-detailed one
[16:30] <sil2100> mhr3: too bad the machines are not logging to /var/crash ;/
[16:30] <mhr3> sil2100, we still don't know whether they're "real" or recordmydesktop+lxc
[16:30] <sil2100> No apport dumps ;/
[16:34] <sil2100> mhr3: oh oh, I see one test left gedit open, so this might cause some failures as well
[16:35] <mhr3> sil2100, see, and there were still just 17failures :)
[16:35] <mhr3> sil2100, so perhaps not everything is dark and gloom
[16:36] <mhr3> sil2100, so do you want to go over all of them?
[16:36] <mhr3> hangout?
[16:39] <sil2100> mhr3: I guess it's not needed
[16:40] <sil2100> mhr3: I see that we have 16 threshold, so we're below that - we of course broke the other threshold, the number of regressions ;p
[16:40] <sil2100> But well, let's just take a blind eye on that
[16:40] <mhr3> there's a limit on number of regressions?
[16:42] <sil2100> Yes, if there's too many regressions in relation to previous successfull runs, it notes a run as failed if there's a too big difference (over 6 new failures)
[16:42] <sil2100> But, pssst, let's just say it's ok today
[16:42] <sil2100> I browsed through the vids and those seem mostly issues with AP
[16:43] <sil2100> WHAT THE FUCK
[16:43] <sil2100> armhf FTBFS
[16:43] <sil2100> Trevinho: damn you for all those unit tests! DAMN YOU!
[16:43] <sil2100> :D
[16:43] <sil2100> https://launchpadlibrarian.net/145690384/buildlog_ubuntu-saucy-armhf.unity_7.0.2%2B13.10.20130723.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:43] <sil2100> I'm trying a re-run
[16:44] <Trevinho> sil2100: oh... :P
[16:44] <sil2100> But THIS, this just pissed me off! We were soo close to release ;/ Now again we need to wait another 2 freaking hours for armhf to finish
[16:44] <Trevinho> sil2100: oh, that ramonly fails on slow hardware
[16:44] <sil2100> Trevinho: noooo~!
[16:44] <Trevinho> sil2100: in case we can increase the timeout for that, but it's already pretty high
[16:45] <Trevinho> sil2100: but it actually wasn't failing for looooong time on CI or Autolanders
[16:45] <sil2100> didrocks: what would happen if I published unity without a armhf binary in the daily-build PPA? Is there a binary copy made?
[16:45] <sil2100> Trevinho: indeed! I didn't see it failing on the previous run as well
[16:45] <sil2100> It seems unity is cursed
[16:45] <sil2100> Something doesn't want it released
[16:45] <didrocks> sil2100: it will try to rebuild on armhf in proposed
[16:46] <didrocks> sil2100: if it fails as well, it will be blocked on proposed
[16:46] <sil2100> didrocks: so, can I just proceed with the publish step without armhf built? Since the problem seems to be a 'slow machine' random thing
[16:46] <didrocks> sil2100: yes you can, but ensure it won't stay stuck in proposed
[16:46] <didrocks> and it's really a random thing
[16:46] <didrocks> that will get fixed
[16:47] <Trevinho> sil2100: however I know that tests can be annoying, but if we want quality checks we need them, This also made us to improve some other components such as libunity and libdee... So, I know it can be disappointing, but we have to. On the other side we must prevent any false-negative result...
[16:47] <mhr3> Trevinho, unless there's a threading race :P
[16:47] <Trevinho> mhr3: yeah :)
[16:47] <sil2100> Trevinho: we know we know ;) I'm just mad because it was hindering my release! :P
[16:47] <didrocks> sil2100: but if it's getting stuck, and we only deliver half of the thing, we need to ensure there is no ABI break that were not spotted
[16:48] <didrocks> sil2100: so warning to ensure you don't break a bunch of our users :)
[16:48] <Trevinho> sil2100: in the mean time, it's fine if you set the timeout for that test to 30 seconds... It pass here in just less than one... but arm seems so slow
[16:48]  * sil2100 is very desperate
[16:50] <mhr3> Trevinho, hm... arm isn't that slow, there'll be a rare threading issue
[16:51] <Trevinho> mhr3: probably....
[16:53] <sil2100> didrocks: ekhm ;) I know it's late, but maybe you could do some packaging ACKs?
[16:54] <sil2100> didrocks: it's rather safe as mhr3 is using daily-build unity for some time now
[16:54] <didrocks> sil2100: right, but let's imaging armhf can't be build in distro as well
[16:54] <didrocks> so, it will get stuck in -proposed
[16:54] <didrocks> the rest will migrate to the release pocket
[16:54] <didrocks> and it's not a tested experienced
[16:55] <mhr3> sil2100, it scares that you point it out, shouldn't that be the case for anyone who does unity changes?
[16:55] <sil2100> mhr3: I guess it should! ;)
[16:56] <sil2100> didrocks: right, but this test never failed before, and between this run and the previous one there were no changes in trunk actually
[16:56] <Saviq> greyback, btw, didn't read properly but we're not having "2 independent scenegraphs" - that's the whole problem ;)
[16:56] <Saviq> greyback, we have "2 interdependent scenegraphs"
[16:56] <didrocks> sil2100: if you stay to ensure it's not blocked in proposed, I'm fine
[16:56] <didrocks> so that we don't wake up with thousands of broken laptop :)
[16:57] <didrocks> or play it safe and so, the rebuild should pass? ;)
[16:57] <sil2100> didrocks: ok, so let's do it like this - could you check the changes, ACK them and I'll wait for the armhf bits to finish building in the PPA
[16:57] <didrocks> ok
[16:57] <didrocks> seems safer to me
[16:57] <sil2100> If it passes, then we'll have a safer release ;p
[16:57] <sil2100> And I'll publish then
[16:57] <didrocks> indeed ;)
[16:57] <sil2100> didrocks: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/108/artifact/packaging_changes_libunity_7.0.9+13.10.20130723-0ubuntu1.diff <- libunity ABI break, oh noes
[16:58] <greyback> Saviq: well depends on how you define dependency. The scene graphs don't need each other. But the QML engine will be controlling both of them
[16:58] <didrocks> sil2100: hum, still libunity9
[16:58] <didrocks> sil2100: is that a real ABI break, what will be impacted?
[16:58] <Saviq> greyback, yeah, that could be
[16:58] <sil2100> mhr3: ^
[16:59] <sil2100> didrocks: I see a lot of symbols removed, so hm
[16:59] <didrocks> sil2100: like, this is an example, if libunity pass in the release pocket, will old unity still work
[16:59] <mhr3> sil2100, it's hiding all unity_internal_*
[16:59] <didrocks> (and old scopes)
[16:59] <didrocks> mhr3: not only apparently?
[16:59] <sil2100> Ok, so it's safe?
[16:59] <didrocks> - unity_dee_result_set_construct@Base 7.0.0daily13.05.31ubuntu.unity.next
[16:59] <sil2100> mhr3: - unity_dee_result_set_construct@
[16:59] <didrocks> -> not really internal :p
[16:59] <Saviq> dandrader|lunch, hey, when's your EOD today?
[16:59] <mhr3> didrocks, and moving to internal what should have been :)
[16:59] <sil2100> Is that internal ?
[16:59] <sil2100> Ah
[16:59] <sil2100> hmmm
[16:59] <didrocks> mhr3: but it doesn't shift any struct?
[16:59] <mhr3> no
[16:59] <didrocks> ok ;)
[17:00] <didrocks> sil2100: so +1
[17:00] <sil2100> didrocks: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/108/artifact/packaging_changes_nux_4.0.2+13.10.20130723-0ubuntu1.diff <- nux ABI break ;p
[17:00] <didrocks> what a surprised… :p
[17:00] <didrocks> surprise*
[17:00] <sil2100> didrocks: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/108/artifact/packaging_changes_unity-lens-friends_0.1.3+13.10.20130723-0ubuntu1.diff <- version bump
[17:00] <didrocks> sil2100: +1 on nux
[17:01] <didrocks> sil2100: fine on lens-friends
[17:01] <sil2100> didrocks: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/108/artifact/packaging_changes_unity_7.0.2+13.10.20130723.1-0ubuntu1.diff <- ok, this one is big, still didn't finish checking it ;/ But I guess it's also related to the nux and libunity bumps
[17:02] <didrocks> urgh wrap and sort :/
[17:02] <didrocks> that really sucks :/
[17:02] <sil2100> Yes, it makes the diff unreadable ;/
[17:03] <sil2100> xserver-xorg-video-dummy dep was added
[17:03] <didrocks> sil2100: ok, sounds legit (and in main)
[17:05] <didrocks> sil2100: anything else to +1?
[17:05] <sil2100> didrocks: that's all :)
[17:05]  * sil2100 waits for armhf
[17:05] <didrocks> ok, great! :)
[17:05] <didrocks> good luck ;)
[17:05] <sil2100> didrocks: thanks!
[17:05] <sil2100> :)
[17:05] <didrocks> yw, thank to you!
[17:10] <sil2100> bschaefer, bregma, Trevinho, andyrock: hi guys! https://bugs.launchpad.net/unity/+bug/1204188 <- could you take a look in some free time?
[17:10] <sil2100> So that we can get the number of failures down \o/
[17:10] <sil2100> Thanks!
[17:10] <bregma> sil2100, already working on it, but don;t get your hopes too high :)
[17:10] <bschaefer> someone mentioned free time?!
[17:11] <bregma> bschaefer, yes, we're shipping you a new lot but it's being held at the border
[17:11] <bschaefer> bregma, haha, i need my fix
[17:11] <bschaefer> sil2100, cool, Ill try to take a look at some point ....
[17:11] <sil2100> Thanks guys, could you assign someone etc. to that bug? So that we can get it 'formalized' ;p
[17:12] <bregma> sil2100, it's more likely there are at least 17 individual bugs that need to be addressed
[17:14] <sil2100> bregma: right, I just filled in one so that it's documented in any way, that distro knows why we might be delaying some things
[17:14] <bregma> sil2100, we'll take care of it
[17:18] <Trevinho> sil2100: mh, not sure they really depend on us or on the indicator team
[17:18] <Trevinho> sil2100: the latests indicators stack seems a litlte unstable here yet..
[17:33] <dandrader|lunch> Saviq,  around 22:00 UTC I guess
[17:36] <sil2100> Trevinho: uuuh, well, then I'll have to harrass them to put more AP tests!
[17:37] <sil2100> Trevinho: or, maybe, it would be a good idea to refresh the list of tests ran on indicators? Let me note that down
[17:38] <Trevinho> sil2100: I mean, we changed nothing on that side, so... it seems more likely to be an indicators issue, but this statement is not based on real local testing here... just an impression
[17:42] <Saviq> dandrader|lunch, wanted to drop on you a potential Hud issue, but it seems it's not our fault in the end ;)
[18:13] <bschaefer> sil2100, hey, soo i've this ibus 1.5 fix, and you poked around the ibus AP tests quite a bit
[18:13] <bschaefer> mind doing a review?
[18:13] <bschaefer> (if you have any freetime...)
[18:13] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/lp.1203106-fix
[19:43] <TitusJ> hi everbody!
[22:20] <marlinc> https://plus.google.com/102031545913933941769/posts/7rE4eq5GBiW