[05:56] <didrocks> hey Mirv!
[05:59] <Mirv> morning didrocks
[05:59] <didrocks> Mirv: I just pinged the QA team as you can see the autopilot ati machine is down
[05:59] <didrocks> not sure if you tried to ping them already
[06:00] <Mirv> didrocks: not yet, I saw connection problems but wasn't sure if it was random so tried again. thanks for pinging.
[06:55] <Hargard> for those ubuntu developers out there am in college and ave decided to give it a go
[06:55] <Hargard> how do i go about it ??
[07:11] <Mirv> Hargard: http://www.ubuntu.com/download should get you started
[07:25] <jibel> good morning
[07:41] <didrocks> salut jibel!
[07:41] <Mirv> didrocks: ack for removal of libgles2-mesa-dev dependency? http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_powerd_0.13+13.10.20130806-0ubuntu1.diff seemingly not needed because a successful build happened
[07:41] <didrocks> ça va?
[07:41] <Mirv> no explanation in the merge request though
[07:41] <didrocks> jibel: thanks for restarting the ati machine btw :)
[07:42] <jibel> Salut didrocks , ça va et toi? plus reposé qu'hier?
[07:42] <jibel> didrocks, de rien
[07:42] <didrocks> Mirv: ok, let's trust then :) +1
[07:42] <didrocks> jibel: un peu mieux et un moins chaud!
[07:42] <jibel> didrocks, I still don't get why this machine and only this one goes down
[07:42] <Mirv> ok
[07:43] <didrocks> jibel: right, that's weird. I guess there is no way to have something able to restart it from magners?
[07:44] <jibel> didrocks, and each time when it starts the platform stack
[07:44] <jibel> didrocks, is there anything special with this stack?
[07:44] <didrocks> the only think I can see is that libhybris is installed and have opengles android drivers
[07:44] <jibel> didrocks, I can add a nagios check with an autorestart
[07:45] <didrocks> but it would be a 100% reproduceable if it was that one making everything failing
[07:45] <jibel> but I don't really fancy systems that tries to automatically fix themselves
[07:45] <didrocks> indeed
[07:45] <didrocks> jibel: just give me a way to restart it at least ;)
[07:46] <jibel> didrocks, connect to the CDU and electrically reboot it :)
[07:46] <didrocks> jibel: I have no idea how to do that TBH ;)
[07:46] <didrocks> an email would help
[07:50] <jibel> didrocks, honestly the qa prod team should do that, I'll send them an email
[07:51] <Mirv> didrocks: indicator-network and mir would need acking as well http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-network_0.5.0+13.10.20130806-0ubuntu1.diff + http://10.97.0.1:8080/view/cu2d/view/Head/view/Mir/job/cu2d-mir-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_mir_0.0.8+13.10.20130806-0ubuntu1.diff - should mir archs be just
[07:51] <didrocks> jibel: thanks! I tried to ping them this morning, but we have been stuck for 2 hours
[07:52] <didrocks> Mirv: +1 on both (your end of sentence have been cut though)
[07:52] <Mirv> didrocks: ah.. it was "should mir archs be just 'any' as well?"
[07:53] <didrocks> Mirv: no, we don't build Mir on powerpc on purpose
[07:53] <didrocks> (hence the lenghty list)
[07:53] <Mirv> didrocks: ok
[08:13] <Mirv> didrocks: the SDK team is now doing a separate source for non-build-needing Ubuntu Qt Creator plugin data files. does that (qtcreator-plugin-ubuntu-data) sound ok to you? or should we anticipate the hopeful combination of the plugin code into it in the name of this new source package? (still not possible at the moment)
[08:14] <didrocks> Mirv: hum -data is confonding
[08:14] <didrocks> Mirv: I would expect assets
[08:14] <didrocks> qtcreator-plugin-ubuntu isn't possible?
[08:14] <didrocks> even if we ship a qtcreator-plugin-ubuntu-data binary package
[08:15] <didrocks> (so that the day we can have real binary plugin code, we just skip to the same package)
[08:15] <Mirv> didrocks: it would be possible, although sligthly confusing as qtcreator-plugin-ubuntu binary package would still come from qtcreator source package, so far
[08:15] <didrocks> ship*
[08:15] <didrocks> Mirv: I can if you add a comment in debian/control, that's good enough
[08:15] <didrocks> s/can/think/
[08:16] <didrocks> maybe qtcreator-plugin-ubuntu-common for the binary package btw
[08:16] <Mirv> ok, sounds good to me, the end goal is to have it truly separate
[08:16] <Mirv> common makes sense
[08:16] <didrocks> right ;)
[08:16] <didrocks> thanks Mirv
[08:16] <Mirv> thanks for consultance
[08:36] <didrocks> seb128: team meeting reminder btw :)
[08:39] <seb128> didrocks, thanks
[08:40] <didrocks> yw ;)
[09:06] <didrocks> am I the only one with my sd card being in read only now?
[09:07] <didrocks> /dev/mmcblk0p1 on /media/didrocks/BE2C-ED51 type vfat (ro,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
[09:24] <seb128> didrocks, is that a desktop config?
[09:25] <didrocks> seb128: I'm on my desktop, yeah
[09:25] <didrocks> can't remount it rw
[09:26] <seb128> didrocks, wfm, I just put an sd in the laptop reader and it's rw for me
[09:26] <didrocks> $ ls -l /dev/mmcblk0
[09:26] <seb128> the other options are the same as yours
[09:26] <didrocks> brw-rw----+ 1 root disk 179, 8 août   6 11:25 /dev/mmcblk0
[09:26] <didrocks> I would need a pitti… :/
[09:26] <seb128> $ ls -l /dev/mmcblk0p1
[09:26] <seb128> brw-rw----+ 1 root disk 179, 1 août   6 11:25 /dev/mmcblk0p1
[09:26] <didrocks> ok, it's something else probably
[09:27] <seb128> you are sure you didn't toggle the security on the sdcard by accident?
[09:27] <seb128> the small plastic piece on the side
[09:27] <didrocks> I don't have that toggle
[09:27] <seb128> weird
[09:27] <didrocks> it's a micro-sd
[09:27] <didrocks> ah, but the adapater has one!
[09:29] <didrocks> seb128: ok, never noticed that switch, working now :)
[09:29] <seb128> didrocks, great ;-)
[09:29] <didrocks> (it seems that there is nothing blocking it anymore, so it's floating)
[09:36] <seb128> Mirv, hey
[09:36] <seb128> Mirv, are you looking at the stacks while sil2100 is on holidays?
[09:37] <seb128> Mirv, is there any problem with settings (it's still not published from what I can see)?
[09:50] <Mirv> seb128: hey, yes, I'm not sure what's it truly is about, but armhf fails repeatibly https://bugs.launchpad.net/ubuntu-system-settings/+bug/1208720
[09:50] <ubot2`> Ubuntu bug 1208720 in ubuntu-system-settings "FTBFS on armhf: Library '/system/lib/libGLESv2.so' not found (Segmentation fault)" [Undecided,New]
[09:50] <Mirv> was meaning to ping you as well
[09:51] <seb128> shrug
[09:52] <seb128> it's a mir fallout I'm pretty sure
[09:52] <seb128> didrocks, !!!!
[09:52] <seb128> RAOF, ^ does that ring a bell?
[09:52] <didrocks> it's what tvoss_ and RAOF are working on AFAIK
[09:53]  * ogra_ doesnt think thats easily solvable unless you have a mesa package that provides that file in that place 
[09:53] <Mirv> powerd dropped libgles dev dependency just
[09:53] <tvoss_> seb128, is that on armhf?
[09:54]  * ogra_ would just add such a link to libgles2-mesa-dev
[09:54] <Mirv> tvoss_: yes
[09:55] <seb128> tvoss_, yes
[09:55] <tvoss_> Mirv, why do you access the libgles at build time?
[09:56] <seb128> Mirv, is that the only component hitting that issue?
[09:56] <Mirv> seb128: so far yes
[09:57] <seb128> tvoss_, we don't, we just use qt5 stuff
[09:57] <seb128> tvoss_, something in the qt stack is bringing it for us...
[09:57] <tvoss_> seb128, so you are running a test or something at build time, right?
[09:57] <tvoss_> seb128, /system/lib/libGLESv2.so lives on the android side of things
[09:58] <ogra_> and is totally device specific
[09:58] <seb128> tvoss_, yes, that's in the tests (running the ui under xfvb-run)
[09:58] <ogra_> for all Xorg gles builds we use mesa ... if you really need such a thing, we should have a meas lib that provides the stubs you need
[09:58] <seb128> tvoss_, that was working until yesterday
[09:58] <tvoss_> seb128, the problem is that libhybris is installed ...
[09:59] <seb128> ogra_, well, I don't, it's a qt5 UI ran under xvfb-run
[09:59] <ogra_> ah
[09:59] <seb128> tvoss_, right, we build-depends on it because we use it to access device infos (serial number)
[09:59] <ogra_> well, even that should have a runtime mesa fallback then
[10:00] <ogra_> seb128, that wont work without having a full android counterpart in place
[10:00] <tvoss_> seb128, http://pastebin.ubuntu.com/5954397/ is the list of rdepends
[10:00] <tvoss_> seb128, why do you use it naked?
[10:00] <seb128> tvoss_, well, as said we directly build-depends on it
[10:00] <tvoss_> seb128, which function do you use?
[10:01] <seb128> #include <hybris/properties/properties.h>
[10:01] <seb128>         property_get("ro.serialno", serialBuffer, "");
[10:01] <seb128> tvoss_, ^
[10:01] <ogra_> that cant work
[10:01] <seb128> tvoss_, that can go away the day we have an Ubuntu backend for qtsystems
[10:01] <seb128> ogra_, yet it does ;-)
[10:01] <tvoss_> seb128, I think you need android-properties, too
[10:01] <ogra_> it cant ...
[10:02] <ogra_> (at build time i mean)
[10:02] <seb128> ogra_, go to system settings, about and look at "serial number"
[10:02] <tvoss_> ogra_, the hybris author was working on making it work
[10:02] <seb128> ogra_, it's rsalveti who told me to do that, and it has been working until today
[10:02] <ogra_> seb128, i mean in a package build or runtime test of a package build
[10:02] <ogra_> unless you actually build on a phone
[10:02] <seb128> ogra_, why? libhybris is there on amd64 and i386
[10:03] <seb128> why wouldn't it build?
[10:03] <seb128> sure it's not going to work
[10:03] <ogra_> there is no backend or properties system
[10:03] <seb128> by libhybris just return the fallback value on a desktop
[10:03] <seb128> that's the 3rd argument of the function
[10:03] <seb128> ""
[10:03] <seb128> by->but
[10:03] <tvoss_> seb128, it tries to resolve the libraries at startup time
[10:03] <RAOF> seb128: libhybris should not be built on i386 or amd64, because it can't ever work there.
[10:04] <ogra_> RAOF, wrong
[10:04] <ogra_> RAOF, there are pleny x86 based android devices
[10:04] <seb128> RAOF, you can have android on i386 ;-)
[10:04] <ogra_> and the plan is to support them
[10:04] <RAOF> Ah, fair enough. We *are* planning to support the crazy x86 android :)
[10:04] <seb128> well, that's orthogonal anyway
[10:04]  * ogra_ just had the same discussion with tvoss_ in #ubuntu-phablet ::) )
[10:04] <seb128> that's just an include, even if the function is not implemented on !armhf
[10:05] <seb128> things build
[10:05] <seb128> and runtime is doing the right thing
[10:05] <seb128> it returns a fallback value if there is no backend
[10:05] <seb128> not sure why we are arguing over that
[10:05]  * RAOF suspects that we actually want a new arch; android-i386, android-amd64, android-armhf.
[10:05] <seb128> the problem is the libegles build issue
[10:05] <seb128> -e
[10:05] <ogra_> RAOF, that wouldnt gain you anything since the android side isnt packaged
[10:05] <seb128> and that's new from today
[10:05] <RAOF> And the libgles runtime issue, as installing libhybris breaks mesa
[10:06] <tvoss_> ogra_, I think it was, slangasek mentioned that to me last week
[10:06] <seb128> RAOF, why wasn't it breaking it before today?
[10:06] <RAOF> It probably *was*, just that nothing was depending on libhybris?
[10:06] <seb128> RAOF, and can we go back to not breaking it?
[10:06] <ogra_> tvoss_, we have an android package we use ... it contains exactly the img files yoou find on cdimage
[10:06] <seb128> RAOF, no, system settings didn't change, we have been doing that for > 1 month
[10:06] <ogra_> tvoss_, we will never have it "properly" packaged or usable by a build system
[10:07] <RAOF> seb128: Not really; hybris' egl alternate needs to beat mesa's egl alternate on the phone.
[10:07] <RAOF> ogra_: Even without the base packaged, android-i386 would be useful; we could build-depend on libhybris [android-any]
[10:07] <ogra_> tvoss_, every binary in these packages would be fully device specific
[10:08] <ogra_> RAOF, that would mean a complete new arch
[10:08] <RAOF> Then android-i386 builds would get the correct dependencies, and i386 builds wouldn't pull in libhybris and break everything
[10:08] <seb128> shrug
[10:08] <RAOF> ogra_: Partial arch, surely?
[10:08] <ogra_> RAOF, hire 20 new devs and we can talk again
[10:08] <tvoss_> ogra_, sure
[10:08]  * ogra_ points to the pain lpia was
[10:08] <tvoss_> ogra_, what is your proposal to solve this then?
[10:09] <seb128> RAOF, we have been pulling it libhybris in for a month with daily builds every day and didn't get any issue
[10:09] <ogra_> tvoss_, have a porper mesa package providing that file linked
[10:09] <ogra_> everything else would be 100% HW specific
[10:09] <tvoss_> ogra_, the interesting bit is: it's not only gl
[10:09] <seb128> RAOF, something changed somewhere starting today
[10:09] <ogra_> (as android simply is 100% HW specific ... its an embedded build)
[10:10] <seb128> RAOF, don't make me spend the day tracking to down to the recent xorg/mesa uploads :p
[10:10] <ogra_> tvoss_, so we need other packages like that for the other purposes
[10:10] <RAOF> seb128: :)
[10:10] <tvoss_> seb128, when did you start pulling in hybris?
[10:10] <seb128> tvoss_, early july
[10:11] <seb128> tvoss_, RAOF: https://launchpad.net/ubuntu/+source/ubuntu-system-settings/0.1+13.10.20130712-0ubuntu1
[10:11] <seb128> and things have been working smoothly since, until today
[10:11] <tvoss_> seb128, so you could happily run your tests at build time until today?
[10:12] <seb128> yes
[10:12] <tvoss_> RAOF, the last package installing either mesa or hybris would win, right?
[10:12] <RAOF> tvoss_: No; mesa's alternate is priority 500, hybris' is 1000. Hybris always wins
[10:12] <seb128> tvoss_, RAOF: that's yesterday's build:
[10:12] <seb128> https://launchpadlibrarian.net/146708048/buildlog_ubuntu-saucy-armhf.ubuntu-system-settings_0.1%2B13.10.20130804-0ubuntu1_UPLOADING.txt.gz
[10:12] <seb128> "xvfb-run -a ./tst_plugins
[10:12] <seb128> libEGL warning: GLX/DRI2 is not supported
[10:12] <seb128> libEGL warning: DRI2: failed to create any config
[10:12] <seb128> libEGL warning: GLX: failed to load GLX"
[10:12] <seb128> we had those warnings
[10:13] <seb128> but not libgles error
[10:13]  * ogra_ bets it is platform-api, not hybris 
[10:13] <tvoss_> ogra_, then it is more likely to be qtubuntu
[10:13] <tvoss_> in this specific scenario
[10:13] <ogra_> or that, yeah
[10:14] <ogra_> just not hybris ... it didnt change in a while
[10:14] <RAOF> seb128: You didn't have libhybris installed during that build.
[10:14] <ogra_> qtubuntu changed sat, though
[10:14] <RAOF> seb128: So, now that something's pulling libhybris into your build environment, it's breaking it.
[10:14] <seb128> hum
[10:15] <seb128> what happened to that build-depends
[10:15] <seb128> and why is it not failing to build earlier since one the header is not installed
[10:16] <RAOF> Mysteries of the ages.
[10:16] <seb128> ok
[10:17] <seb128> RAOF, tvoss_: so what do you recommend doing? should whatever is bringing hybris in be fixed to not do that?
[10:17] <RAOF> Yes.
[10:17] <tvoss_> seb128, that was my proposal, but ogra is opposed to binding it to the architecture
[10:18] <RAOF> Well, I guess there's two options. Make libhybris not break everything when there isn't an underlying android system to delegate to, or not install libhybris unless there's an underlying android system to delegate to.
[10:18] <ogra_> i'm not opposed to fixing it :)
[10:18] <RAOF> The former seems simpler ;)
[10:18] <ogra_> i'm just opposed to break x86 android on purpose
[10:18] <RAOF> Gah. I meant the latter "don't install libhybris unless there's an android system"
[10:18] <tvoss_> RAOF, right :)
[10:19] <tvoss_> RAOF, as installation of hybris breaks things right now ...
[10:19] <ogra_> RAOF, thast what i was suggesting to tvoss_
[10:19]  * seb128 tries to figure out what is brining hybris in
[10:19] <tvoss_> ogra_, the trigger for "an underlying android system" is a bit difficult to model right now
[10:20] <ogra_> well, as long as the android container bits arent installed in your root you dont have android and should use a fallabck method
[10:20] <tvoss_> ogra_, how to detect that at package build time if not tying to the architecture then?
[10:21] <ogra_> at build time you *never* have any android in place
[10:21] <ogra_> and *always* need to use the fallback
[10:22] <czajkowski> good morning my favourite people :)
[10:22] <czajkowski> this bug, isn't against saucy, but has happened at least 4 times today https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/1107926  wondering is there anything I can do to help
[10:22] <ubot2`> Ubuntu bug 1107926 in bamf (Ubuntu) "bamfdaemon crashed with signal 5 in _XReply()" [Medium,Confirmed]
[10:23] <seb128> czajkowski, hey, try talking to Trevinho
[10:23] <Trevinho> czajkowski: see if you have debug symbols
[10:23] <tvoss_> ogra_, so effectively you are saying that no one should link against hybris for example, but dlopen/dlsym at runtime then
[10:23] <Trevinho> czajkowski: I mean, it would be nice if you could install them and get a better stacktrace
[10:24] <ogra_> tvoss_, no, i'm saying we need something like mesa to provide what you need at build time, like we do since armhf exists (we cant link against GLES stuff on arm, mesa provides a generic way for buildign GL and GLES stuff)
[10:24] <czajkowski> Trevinho: debug symbols?
[10:25] <Trevinho> czajkowski: yes, see https://wiki.ubuntu.com/DebuggingProgramCrash...
[10:25] <Trevinho> czajkowski: however I see there are some stack traces on the bug, let me check them first
[10:25] <czajkowski> Trevinho: cheers
[10:25] <ogra_> tvoss_, if you link against hybris, hybris-dev sneeds to provide the right stubs
[10:25] <ogra_> or use some other dep that does
[10:26] <tvoss_> ogra_, it does provide the stubs right now, perhaps we just need to be more clever in there and not trying to resolve symbols at load time automatically
[10:26] <ogra_> or enhance the stubs :)
[10:26] <tvoss_> seb128, why do you run the tests at buildtime on an armhf target if not on phone?
[10:26] <tvoss_> ogra_, I did the lazy loading trick in the platform api, working fine there
[10:27] <tvoss_> ogra_, that still leaves us with overriding the defaults issue though
[10:27] <ogra_> "the lazy loading trick" ?
[10:27] <tvoss_> ogra_, not resolve symbols from the android side automatically when the program starts but only on demand
[10:27] <ogra_> ah
[10:27] <seb128> tvoss_, those tests are from mardy, I'm not sure ... would you recommend those to be rather autopilot/CI tests?
[10:28] <ogra_> if they are HW dependent they have to
[10:28] <tvoss_> seb128, yup
[10:28] <seb128> ogra_, they are not
[10:28] <seb128> it's only a qt5 ui
[10:28] <seb128> we don't test backend code in those
[10:28] <ogra_> well, the data you collect is
[10:28] <seb128> well, those tests only test the UI bits
[10:29] <seb128> they don't depend on having a working backends or datas
[10:29] <tvoss_> seb128, but qou won't have a ui on armhf anyways
[10:30] <Mirv> didrocks: ack request for friends migration to UnityActions API http://10.97.0.1:8080/view/cu2d/view/Head/view/Friends/job/cu2d-friends-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_friends-app_0.91.3+13.10.20130806-0ubuntu1.diff
[10:30] <seb128> tvoss_, why not?
[10:30] <tvoss_> seb128, how would they if not running on a device?
[10:30] <seb128> tvoss_, well, the main UI is only qt stuff, it's building a grid of icons for the available plugins
[10:31] <seb128> it can run anywhere where qt5 is working
[10:31] <seb128> then the panels are not going to work, sure
[10:31] <ogra_> the bug is definitely that the qt stuff tries to attach to something completely HW specific then
[10:31] <seb128> ogra_, well, the thing is that libhybris being in just breaks qt/gles
[10:31] <ogra_> which brings me back to my mesa like statement :)
[10:32] <ogra_> hybris needs to fall back to meas gles or something similar
[10:32] <ogra_> *mesa
[10:32] <didrocks> Mirv: +1
[10:33] <tvoss_> ogra_, or we split hybris into core and something like hybris-egl, hybris-gles etc
[10:33] <tvoss_> ogra_, you could then runtime depend on it, but not build-time depend on it
[10:33] <ogra_> rvr, how would that solve the issue ?
[10:33] <ogra_> if the UI needs gles it still would fail
[10:33] <ogra_> it fails at runtime
[10:34] <ogra_> during a runtime test ... no ?
[10:34] <Trevinho> seb128: do you know if something changed in gdk_error_trap_{pop,push} recently?
[10:34] <seb128> Trevinho, "recently"?
[10:34] <Trevinho> seb128: let's say raring/saucy cycle...
[10:34] <seb128> Trevinho, not that I know of, we have been on gtk 3.8 for over a month
[10:34] <tvoss_> ogra_, nope, the runtime depends are actually different than the build depends, we could make lxc-andoroid-config runtime depend on -egl -gles etc. and only bring in that dependency very selectively
[10:35] <Trevinho> seb128: as that crash should be handled by gdk, without crashing actually..
[10:35] <ogra_> tvoss_, no, that would be wrong
[10:35] <tvoss_> ogra_, why is that?
[10:35] <ogra_> lxc-anroid-config is lower than UI level
[10:35] <ogra_> thats like making udev depend on some xserver stuff
[10:35] <seb128> Trevinho, hum, I don't know ... maybe ask on #gtk+?
[10:36] <Trevinho> seb128: ok...
[10:36] <Trevinho> seb128: also if I do a new release of libwnck can you import that in archives?
[10:36] <ogra_> tvoss_, again, i think we need hybris to fall back to mesa
[10:36] <seb128> Trevinho, sure
[10:36] <ogra_> and have a mesa package that provides the bits that are expected
[10:36] <Trevinho> seb128: cool
[10:37] <tvoss_> ogra_, again, I do agree with you but it's a significant amount of work and would result us in implementing "allow for multiple egl, gles vendor specific implementations" in mesa
[10:37] <tvoss_> ogra_, that's not something we can do easily right now
[10:37] <ogra_> tvoss_, i dont think it is so significant
[10:38] <ogra_> tvoss_, mesa already ships libGLESv2.so .... just not in the place the code expects it
[10:38] <tvoss_> ogra_, you cannot easily just symlink, the moment you open the so again, you risk running all of the global ctors again and such
[10:38] <ogra_> all you need is some links ... and for cleanness probanly a separate package so you dont mess up desktop
[10:39] <tvoss_> ogra_, I don't think that it is that easy, that's why I'm trying to find another solution
[10:40] <ogra_> LD_PRELOAD during build then ?
[10:43] <seb128> tvoss_, ogra_, RAOF: ok, so libmirclient1 is what brings libhybris on the builder
[10:44]  * seb128 scratches head on what to do next
[10:44] <ogra_> seb128, awesome so tvoss_ just needs to fix bug 1118903
[10:44] <ubot2`> Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged] https://launchpad.net/bugs/1118903
[10:44] <ogra_> :P
[10:44] <tvoss_> just (tm)
[10:45] <seb128> tvoss_, so your suggestion is to move those tests from build time to CI right?
[10:45] <tvoss_> seb128, if that's easily possible ... yes
[10:45] <seb128> didrocks, Mirv: is the CI for ubuntu-system-settings/armhf done on machines that have an android side?
[10:46] <ogra_> thats definitely planned
[10:46] <ogra_> (not sure if it is there yet)
[10:46] <seb128> planned != today
[10:46] <ogra_> yeah
[10:46] <seb128> I need system settings to keep landing
[10:46] <didrocks> seb128: if it's autopilot tests, right
[10:46] <seb128> I can't just say "we are not going to land updates until that happens"
[10:47] <seb128> didrocks, well, atm those tests are run at build time, I need to move them to be run somewhere that has an android side
[10:47] <didrocks> seb128: yeah, convert them to autopilot tests
[10:48] <ogra_> and move them to CI later once CI happens on actual target devices
[10:48] <seb128> didrocks, can I just make them autopkgtests? ;-) that's a "make test" in the build tree, not really autopilot material
[10:48] <didrocks> seb128: I don't think autopkgtests run on android hw
[10:48] <seb128> :-(
[10:50] <seb128> ogra_, you suggested earlier to LD_PRELOAD libgles right? I might just try that in the package build...
[10:50] <ogra_> no idea if that works though :) but i imagine it could
[10:50] <Mirv> I ran a build on my N4 and obviously it succeeded since there was the android side
[10:52] <ogra_> to test without android on a phone, remove /data, /system and /factory from fstab ... and echo manual >/etc/init/lxc-android-config.override  (and pbviously reboot)
[10:57] <seb128> ogra_, tvoss_, RAOF: thinking about it, I don't think it's something I can fix on system settings side ... if I understand correctly the problem, libmir is going to bring libhybris in on any armhf build, and we a load of packages, in the archive, running make check under xfvb-run that is going to hit that issue
[10:57] <ogra_> yes
[10:58] <ogra_> libmir is broken here
[10:58]  * didrocks didn't follow the whole discussion
[10:58] <ogra_> and the only proper fix is to fix the bug above
[10:58] <didrocks> but theorically, all !armhf are broken too, right?
[10:59] <didrocks> like everything that will use opengles?
[10:59] <ogra_> didrocks, nope, it will just fall back to mesa as it should if libhybris isnt pulled in
[10:59] <seb128> didrocks, well, libmirclient1 doesn't depends on libhyrbris on !armhf I think
[10:59] <didrocks> ok, but if you install it
[10:59] <ogra_> (at least i would assume this)
[10:59] <didrocks> you are screwed? ;)
[10:59] <seb128> I guess
[10:59]  * seb128 tries
[10:59] <tvoss_> ogra_, that's not true, it comes down to supporting installing mutliple vendor-specific gl implementations
[10:59] <ogra_> didrocks, right
[11:00] <ogra_> tvoss_, which you cant di at build time
[11:00] <ogra_> *do
[11:00] <tvoss_> ogra_, only if mesa supports it
[11:00] <ogra_> else you end up with HW specific binaries
[11:01] <didrocks> tvoss_: I don't think the u-s-c issue is that one though, we don't pull libhybris in it
[11:01] <ogra_> libmirclient1 needs a "libhybris | libmesa-gles-dev" or something like that .... and your environemnt needs to brovide the latter so that dep is fulfilled
[11:18] <Trevinho> seb128: so I've just released libwnck 3.4.6 (hopefully it will be here soon http://download.gnome.org/sources/libwnck/3.4/libwnck-3.4.6.tar.xz), it would be nice if you could put in archives as well... Let me know if you need a bug for tracking it
[11:18] <seb128> Trevinho, ok, will do
[11:18] <seb128> Trevinho, did you figure out the issue/change with gtk?
[11:35] <seb128> tvoss_, ogra_, RAOF: unity CI is broken as well:
[11:35] <seb128> https://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-autolanding/157/console
[11:35] <seb128> linkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
[11:35] <seb128> Segmentation fault
[11:35] <ogra_> see above :)
[11:35] <seb128> ogra_, the alternative depends is not going to fix that
 seb128: yeah, convert them to autopilot tests
 and move them to CI later once CI happens on actual target devices
[11:36] <ogra_> seb128, no, fixing bug 1118903 will
[11:36] <ubot2`> Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged] https://launchpad.net/bugs/1118903
[11:36] <seb128> ogra_, well, that's not going to happen this week for sure
[11:36] <ogra_> (which would result in some alternate depends)
[11:36] <ogra_> seb128, right, so go with autopilot for now
[11:37] <seb128> ogra_, I'm not converting half of the ubuntu archive to drop make check tests and use autopilot
[11:37] <seb128> let me email ubuntu-devel@ as a fyi meanwhile
[11:37] <seb128> in case others wonder what's going on
[11:38] <Trevinho> seb128: about the gdk change, no idea.. I've tried to one thing in libwnck, let's see if that fixes the problem
[12:01] <Mirv> didrocks: unity managed to get its tests passed finally, there'd be libunity version bump / symbol add change to ack: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.0.10+13.10.20130806-0ubuntu1.diff
[12:02] <didrocks> Mirv: ah sweet! looking good, +1 :)
[12:02] <Mirv> thanks again
[12:02] <didrocks> thanks to you!
[14:15] <rsalveti> seb128: sorry, trying to understand the long backlog, did you find out what was bringing libhybris as build-dep for ubuntu-system-settings?
[14:15] <rsalveti> seb128: ogra_: yeah, just the property system is fine, as that doesn't depend on hybris itself
[14:15] <rsalveti> it's a separated library
[14:16] <ogra_> rsalveti, the dep on libmirclient
[14:16] <rsalveti> oh, and it all started there :-)
[14:17] <rsalveti> yeah, forcing 'android' == 'armhf' is a big and annoying issue
[14:17] <seb128> rsalveti, xorg is
[14:17] <rsalveti> as it'll cause all these weird build-depends just for armhf
[14:17] <seb128> rsalveti, xorg depends on mir and libmirclient1 depends on libhybris on armhf
[14:17] <seb128> rsalveti, and we build-depends on qt, which brings in xorg, which brings in mir, which brings in libhybris
[14:18] <rsalveti> oh, the joy
[14:18]  * rsalveti looks for coffee 
[14:59] <kenvandine> seb128, can you do an easy review for me?  it's going to block getting some ubuntu-system-settings-online-accounts fixed
[14:59] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/mod_dir/+merge/178772
[14:59] <seb128> kenvandine, not sure, you don't do my easy reviews, why should I do yours :p
[14:59]  * seb128 is looking
[14:59] <kenvandine>  :-D
[15:00] <seb128> kenvandine, https://code.launchpad.net/~seb128/telephony-service/sounds-events-from-gsettings/+merge/178344 btw ;-)
[15:00] <seb128> ups
[15:00] <kenvandine> the accounts plugin is no longer getting loaded, since the path changed
[15:00] <kenvandine> and i uncovered the pkgconfig file is broken :)
[15:00] <seb128> kenvandine, https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-improve-display-name/+merge/178587 I meant
[15:01] <kenvandine> oh... i looked at that yesterday and forgot to give it an ack
[15:02] <asac> seb128: can you sit tight on not uploading new X without checking with olli?
[15:02] <asac> and kgunn?
[15:02] <asac> seb128: in general, please always coordinate any upload yuou do :)
[15:02] <asac> with them
[15:02] <seb128> asac, sure, can we do that the other way around too? they just broke armhf with their Mir work :p
[15:03] <seb128> asac, which broke unity7 and system settings (and other stuff)
[15:03] <asac> seb128: if you can phrase what you want from them, then yes
[15:03] <asac> :)
[15:03] <asac> so yeah
[15:03] <asac> seb128: was that the initial landing?
[15:03] <seb128> asac, yes
[15:03] <asac> right. for initial landing they shlould also have reached out to you :)
[15:03] <asac> but having both sides trying, will ensure that at least one side will do it
[15:03] <asac> :)
[15:04] <seb128> asac, when you say "new X", is that for new versions, or any upload (like trivial patches, bug fixes, etc)
[15:04] <kgunn> seb128: asac ack
[15:05] <kgunn> seb128: i think we just need a xmir smoke test added to whatever tests you currently run for uploading new x changes
[15:05] <kgunn> make sense ?
[15:05] <asac> seb128: any upload... just coordinate with your MIR friends :)
[15:06] <seb128> kgunn, asac: yep, that makes sense
[15:06] <seb128> kgunn, do you have any wiki/documentation on "how to test xmir"?
[15:06] <kgunn> seb128: right now ...smoke test is boot, make sure unity-system-compositor is running & unity7 is up (on free drivers that is)
[15:07] <kgunn> seb128: http://unity.ubuntu.com/mir/
[15:07] <seb128> kgunn, unity-system-compositor is not installed by default in saucy, does it mean th... thanks, that website has the infos I wanted ;-)
[15:08] <seb128> kgunn, asac: I will make sure we test xmir and let you know in advance of coming uploads so you have time to test as well
[15:08] <seb128> mlankhorst, ^
[15:08] <kgunn> seb128: yeah...today you have to install u-s-c
[15:08] <seb128> mlankhorst, before any xorg upload, please make sure to test xmir and check with the Mir guys that everything is ok for upload
[15:08] <mlankhorst> yeah was fun to find out from saucy-changes that xmir was uploaded :P
[15:08] <kgunn> but thats the hump we are trying to get over
[15:12] <mlankhorst> and a bit annoyed that a random snapshot of xxv-ati.git was uploaded to enable xmir support on, but I'm going to correct that by tagging a release of a random git snapshot of upstream xxv-ati.git :P
[15:15] <kgunn> mlankhorst: by random, you mean out of synch & not necessarily tested in the non-xmir config ?
[15:15] <kgunn> thats a good point
[15:16] <mlankhorst> yeah and by basing on a release it means other distros will support the same thing too
[15:16] <kgunn> RAOF: ^
[15:16] <mlankhorst> but I'm doing a release of xxv-ati shortly, it's just a lot of work :P
[15:17] <mlankhorst> testing if make distcheck passes, testing the unpatched debian, testing patched ubuntu, sending out release mail
[15:17] <kgunn> mlankhorst: i assume same applies to nouveau & intel
[15:18] <kgunn> or are we better coordinated on intel ?
[15:18] <mlankhorst> intel has someone doing regular releases, so it's less harmful
[15:18] <mlankhorst> on nouveau there isn't much development, so it stays closer to upstream already
[15:20] <kgunn> still we should have gone to the trouble right before the push into main to get on your git tag
[15:20] <mlankhorst> but yes I was hoping you at least tested it on the same hw without mir :P
[15:21] <kgunn> mlankhorst: we do test fallback....
[15:21] <kgunn> but not extensively...more like...it booted ? yea, good
[15:21] <mlankhorst> but I was hitting a crash on stopping xserver with mir + intel sna
[15:22] <mlankhorst> and didn't see a -dbg package for xmir, so valgrind on x becomes less useful
[15:30] <seb128> oh, it's meeting time
[15:31] <seb128> qengho, mlankhorst, tkamppeter, attente, (desrt?), (larsu?): hey, it's meeting time
[15:31] <seb128> short list this week with people in holidays and those are confs
[15:31] <seb128> I hope everybody is fine
[15:31] <seb128> let's get started
[15:31] <seb128> qengho, hey
[15:33] <seb128> ok, no qengho
[15:33] <seb128> mlankhorst, hey
[15:34] <seb128> going to be a short meeting it seems :p
[15:34] <seb128> tkamppeter, hey
[15:35] <tkamppeter> - Make sure cups-browsed always sets and removes queues on the local CUPS daemon, not on a remote one where client.conf is pointing to.
[15:35] <tkamppeter>  - GSoC 2013: Midterm evaluations.
[15:35] <tkamppeter>  - Bugs
[15:35] <tkamppeter>  - test installation of Ubuntu Touch on Nexus 7
[15:36] <seb128> tkamppeter, thanks
[15:36] <seb128> attente, hey
[15:36] <attente> seb128, hey
[15:36] <attente> debugging ibus-anthy not working with ibus 1.5
[15:36] <attente> cleaned up i-keyboard and have a working version under lightdm, plan is to distro-patch accountsservice for the time-being
[15:36] <attente> i-keyboard tests failing, no idea why
[15:36] <attente> (eof)
[15:37] <seb128> do you have a merge request for the lightdm indicator?
[15:38] <attente> seb128, not yet, i'd have to do one for the accountsservice patch first
[15:38] <seb128> ok
[15:38] <seb128> do you have an url for the failing test?
[15:39] <attente> cyphermox posted this yesterday: http://paste.ubuntu.com/5952631/
[15:39] <cyphermox> yeah, that's the best I could get from sbuild
[15:39] <seb128> weird
[15:39] <attente> thinking about it a bit more, i guess it's not related to missing ibus
[15:39] <seb128> seems like an XDG_RUNTIME_DIR issue maybe?
[15:40] <seb128> does it happen in a pbuilder? how can I reproduce?
[15:40] <cyphermox> it does fail in my PPA; I'll hack the rule file to cat that test log too so we know for sure whether it's the same thing
[15:40] <seb128> cyphermox, thanks
[15:40] <seb128> let me know when you get a log
[15:40] <cyphermox> seb128: apparently it doesn't fail in pbuilder
[15:41] <attente> yep, no problems using pbuilder on my end
[15:41] <seb128> ok, weird
[15:41] <seb128> let's wait for the ppa build log
[15:41] <seb128> attente, thanks
[15:41] <seb128> cyphermox, thanks as well ;-)
[15:41] <attente> thanks seb128
[15:42] <seb128> desrt, larsu: any of you around/wanting to do a status update (next week once you are back from GUADEC is fine too)?
[15:42] <larsu> seb128: I am, I think desrt is in a discussion
[15:42] <larsu> so here I go...
[15:42] <larsu> - GUADEC!
[15:42] <larsu> - indicator-messages: gave a branch to dednick that uses the new architecture
[15:42] <larsu> - indicator-sound: make it use the new MPRIS watching code I wrote (waiting for review)
[15:42] <larsu> - gsettings-qt: fix occasional crash on x86
[15:42] <larsu> eof
[15:43] <seb128> larsu, I hope GUADEC was/is good ;-)
[15:43] <seb128> thank for the gsettings-qt fix, that was driving me crazy
[15:43] <seb128> the settings app kept hitting it for me
[15:44] <larsu> seb128: thanks!
[15:44] <seb128> some days I think people just break i386 to make me move to a 64bits install :p
[15:44] <larsu> seb128: GUADEC was awesome, yes
[15:44] <larsu> lol
[15:45] <seb128> larsu, thanks
[15:45] <seb128> so, me
[15:45] <seb128> * system settings:
[15:45] <seb128> - some UI tweaks and bug fixes
[15:45] <seb128> - implemented the dash privacy option
[15:46] <seb128> - made the sound capplet write a real config (and read it/restore state), sent a merge request for the phone app to use those (waiting for review)
[15:46] <seb128> - reviews
[15:46] <seb128> * updated poppler to the new version (adding qt5 support), spent some time daily with the soname change/transition
[15:47] <seb128> * quite some settings backend discussions: silent mode/greeter config/file picker/reset
[15:47] <seb128> * spent at least a day going over the current missing feature and the things that block us/are missing, talking to people about those and filing bugs
[15:48] <seb128> * spent most of the day today in discussions about xmir/libhybris/armhf issues (breaking some of the build and CI), that's being resolved

[15:49] <larsu> wow, quick meeting today :)
[15:49] <seb128> yep
[15:49] <seb128> thanks everyone
[15:49] <seb128> didrocks, ^ your turn now or in 11 minutes, as you wish
[15:49] <didrocks> let's wait for the right time :)
[15:49] <didrocks> thanks seb128!
[15:49] <seb128> (did anyone had comments/questions/things to discussion meanwhile)
[15:49] <seb128> didrocks, yw
[15:49] <kenvandine> seb128, oh... maybe that is what is breaking the systems settings build on armhf
[15:50] <kenvandine> linker errors
[15:50] <seb128> kenvandine, it is, see my email to the ue list
[15:50] <kenvandine> damn
[15:50] <seb128> it's also breaking unity7 CI
[15:52] <kenvandine> :(
[15:53] <jasoncwarner__> hey everyone
[15:53] <seb128> kenvandine, well, hopefully that's fixed today, we can turn off the build tests otherwise if needed
[15:53] <seb128> jasoncwarner__, hey, how are you?
[15:53] <seb128> jasoncwarner, welcome back!
[15:53] <jasoncwarner> hey seb128 good, thanks. now that I'm (finally) home ;)
[15:53] <kenvandine> landing the fixes for the accounts panel depends on getting systems settings published... grrr
[15:53] <kenvandine> hey jasoncwarner!
[15:54] <jasoncwarner> hey kenvandine !
[15:54] <seb128> kenvandine, yeah, where would be the fun if we were not stucked on stuff like that
[15:54] <kenvandine> seb128, indeed...
[15:54] <kenvandine> seb128, so question for you
[15:55] <seb128> kenvandine, turn off the build tests if you really want to land the fix...
[15:55] <kenvandine> mardy has a branch for uss-online-accounts that adds a new clients API, so accounts plugins can build qml-plugins... etc
[15:55] <Mirv> kenvandine: FYI I pinged renato about the phone stack AP problem but didn't get reply https://bugs.launchpad.net/address-book-app/+bug/1208343
[15:55] <ubot2`> Ubuntu bug 1208343 in address-book-app "AP test address_book_app.tests.test_contactlist.TestContactList.test_contact_list failing" [Undecided,New]
[15:55] <robru> jasoncwarner attending a meeting? what??? ;-)
[15:56] <kenvandine> that also adds an OnlineAccountsPlugin.pc file to the uss-online-accounts package
[15:56] <kenvandine> so the clients can get paths, etc
[15:56] <kenvandine> i'd hate to add a -dev package just for that file :)
[15:57] <kenvandine> seb128, how do you feel about that being in the uss-online-accounts binary?
[15:57] <kenvandine> Mirv, thanks
[15:58] <Mirv> robru: how's your trip going?
[15:58] <jasoncwarner> hey robru !
[15:58] <robru> Mirv, GUADEC is amazing, thanks. so many cool people here. but the heat is a bit more than I can bear.
[15:59] <robru> jasoncwarner, hey!
[15:59] <Mirv> hey jason as well
[15:59] <seb128> kenvandine, that's fine, that package is not a lib
[15:59] <kenvandine> good :)
[15:59] <Mirv> robru: great, I'll be glad to read any GUADEC reports :)
[16:00] <robru> Mirv, actually I *just* sent one to warthogs ;-)
[16:00] <kenvandine> seb128, between mardy's changes and mine that are pending for the accounts plugin, we have a huge diff
[16:00] <kenvandine>  48 files changed, 3380 insertions(+), 127 deletions(-)
[16:00] <Mirv> robru: ooh!
[16:00] <Mirv> ok :00
[16:00] <didrocks> good morning robru, Mirv, kenvandine, cyphermox! metting time :)
[16:00] <seb128> kenvandine, quite some diff indeed!
[16:01] <robru> didrocks, *yawn*, good morning, ooooh soo early ;-)
[16:01]  * kenvandine waves
[16:01] <Mirv> \o
[16:01] <didrocks> robru: ahah, don't fake it! still in Europe right? :p
[16:01] <kenvandine> seb128, i hate to turn off the tests... but damn... i gotta land this!
[16:01] <robru> didrocks, lol, yeah. 6PM here in Brno... I could get used to having meetings at this time ;-)
[16:01] <didrocks> heh
[16:01] <cyphermox> morning
[16:01] <didrocks> hey cyphermox! welcome back from holidays ;)
[16:02] <didrocks> sil2100 is probably enjoying some sun and sand (or rather, enjoying unpacking his boxes for his new accomodation)
[16:02] <robru> didrocks, wait, no timo or lukasz?
[16:02] <didrocks> 18:01:13           Mirv | \o
[16:02] <didrocks> I see a timo :)
[16:02] <robru> wait, Mirv is timo?
[16:02] <cyphermox> yeah
[16:02] <Mirv> robru: yeah I just deduplicated myself
[16:03] <Mirv> it'd be nice of course if there'd be both Timo and me
[16:03] <didrocks> ahah
[16:03] <robru> whaaa?
[16:03] <cyphermox> oh, ah, perhaps I should say that I'll re-enable indicator-network tests in head/indicators, I noticed they are still disabled
[16:03] <didrocks> I see robru's world collapsing :)
[16:03] <Mirv> robru: :D
[16:03] <didrocks> cyphermox: excellent \o/
[16:03] <robru> Mirv, terribly sorry, this whole time I've had no idea who you were.
[16:03] <kenvandine> haha
[16:03] <Mirv> robru: hahaha :)
[16:03] <didrocks> let's start with Mirv thus!
[16:04] <didrocks> Mirv: any update? I see you are getting quite a lot of work on the spreadsheet :)
[16:04] <Mirv> yeah, a lot of stuff ongoing, maybe slightly too much to get everything done quickly enough. the latest is Qt Creator update I'm now working on, and there's also Qt 5.1 work that's not on the list like I updated qtmultimedia
[16:05] <didrocks> Mirv: should we take some load from you then?
[16:05] <Mirv> two items that'd be ready for review is u1db-qt MP to get it to sdk stack and qt3d sponsoring, for didrocks
[16:05] <didrocks> (I'm thinking a bout the new packages I added)
[16:05] <didrocks> can someone help on u1db-qt?
[16:05] <Mirv> didrocks: I'd welcome that, I don't see myself getting that far on the list immediately
[16:05] <didrocks> I'll look at qt3d
[16:05] <robru> didrocks, please assign me some work. I've had very little on my plate all week.
[16:06] <didrocks> robru: you were at GUADEC, that's why :)
[16:06] <didrocks> robru: are you back right now in crazy timezone?
[16:06] <didrocks> or wait for eow?
[16:06] <Mirv> didrocks: I mean, those two are ready, and seb reviewed u1db-qt, the only part missing is acceptance of the addition to the stack config
[16:06] <robru> didrocks, yeah, but I see desrt and larsu getting work done. GUADEC isn't a vacation ;-)
[16:06] <robru> didrocks, I fly home on friday.
[16:06] <didrocks> (like, can we assign you some work NOW that needs to be done urgently)
[16:06] <didrocks> ah excellent
[16:06] <didrocks> so, let me reshuffle a little bit the spreadsheet
[16:07] <robru> didrocks, how urgently? I need to run a couple errands after this meeting but I can do some work later tonight (within a few hours)
[16:07] <didrocks> robru: not that urgent :p
[16:07] <didrocks> robru: before eow
[16:07] <robru> didrocks, yeah, for sure, assign me some stuff for EOW please.
[16:07] <Mirv> thank you
[16:07] <didrocks> robru: so, I assign to you the u1db-qt review, the 3 new packages and indicator-keyboard to help cyphermox on it
[16:08] <didrocks> or rather, ubuntu-settings-components
[16:08] <didrocks> robru: sounds good? (look at the spreadsheet, just updated)
[16:08] <robru> didrocks, ok, put it in the spreadsheet and I'll look at it soon
[16:08] <didrocks> great :)
[16:08] <robru> didrocks, ok, great
[16:08] <didrocks> thanks robru
[16:08] <didrocks> hope that can help the poor Mirv ;)
[16:08] <cyphermox> indicator-keyboard will be done before eow
[16:09] <didrocks> cyphermox: good! and you think you can tackle the libcolumbus ABI transitioN?
[16:09] <cyphermox> yeah
[16:09] <didrocks> I CCed you on the email IIRC, right?
[16:09] <cyphermox> I might not have seen it if it landed yesterday
[16:09] <didrocks> yeah, it was yesterday
[16:09] <didrocks> still on email catchup? ;)
[16:09] <cyphermox> no
[16:09] <cyphermox> I got it
[16:09] <didrocks> great!
[16:10] <cyphermox> I don't keep my nose in email, it's too distracting
[16:10] <cyphermox> I only check a couple of times a day
[16:10] <didrocks> I think that's enough for now, I'd probably have still new packages this week and will ping you directly
[16:10] <cyphermox> should I do my update, if robru is done?
[16:10] <didrocks> I think so, please do yours :)
[16:11] <didrocks> - suburn because of ETOOMUCHSUN
[16:11] <didrocks> what else? :)
[16:11] <cyphermox> attente was waiting for a clearer logs for the failing tests in indicator-keyboard
[16:11] <cyphermox> attente: https://launchpadlibrarian.net/146919005/buildlog_ubuntu-saucy-amd64.indicator-keyboard_0.0.0-0ubuntu1~mtrudel2_UPLOADING.txt.gz
[16:11] <cyphermox> the tests fail, we need to fix those, then I'll be able to enable indicator-keyboard and add it for the autopilot testing and all, assuming it has tests :)
[16:12] <cyphermox> ^ despite the above, it really is a failed build
[16:12] <cyphermox> did some work reviewing indicator-network
[16:12] <didrocks> is it enabled for dailies?
[16:12] <attente> cyphermox, thanks
[16:12] <cyphermox> getting that ready to land on Touch asap, to cut down on delta on a bunch of things
[16:12] <didrocks> (I think it is, right?)
[16:12] <cyphermox> didrocks: indicator-keyboard? no
[16:12] <qengho> seb128: sorry! Wonky saucy breakage and I didn't see message.  From me:  1) another chromium version released.  2) Upstream released another. Testing. 3) In progress: Reenabling launchpad translation migration in and out.
[16:12] <didrocks> cyphermox: "indicator-network"
[16:12] <cyphermox> indicator-network yes
[16:12] <seb128> qengho, thanks
[16:13] <cyphermox> it landed this morning
[16:13] <didrocks> ok, nice to see finally an indicator for it! :)
[16:13] <cyphermox> we have a new nicer indicator-network that kind of works :)
[16:13] <didrocks> should we switch to it on desktop?
[16:13] <cyphermox> ahah
[16:13] <didrocks> or it's still just "kind" being "please don't"? ;)
[16:13] <cyphermox> let me get back up from the floor
[16:13] <didrocks> I take that as a no :p
[16:14] <kenvandine> hehe
[16:14] <cyphermox> soon :)
[16:14] <didrocks> sweet! nice progress :)
[16:14] <didrocks> let's catch up on those new components, I'm fearing more are coming, so let's get us tight :)
[16:14] <didrocks> (also, please help reviewing each other and don't wait for me, i'm already under ETOOMANYTHINGS ;))
[16:15] <didrocks> kenvandine: I see you are on the phone autopilot failures?
[16:15] <robru> didrocks, alright, will do.
[16:15] <didrocks> thanks robru, you may get some more pings during the week (and I'll ensure the spreadsheet is up to date)
[16:15] <kenvandine> didrocks, i was looking, but Mirv beat me to filing a bug :)
[16:15] <Mirv> if needed put some links to the spreadsheet others can click and review
[16:16] <didrocks> kenvandine: please poke as well upstream to get that fixed
[16:16] <kenvandine> i'm also trying to get settings published
[16:16] <kenvandine> it has fixes that are needed to land accounts stuff
[16:16] <didrocks> I was about to ask you that :)
[16:16] <didrocks> thanks!
[16:16] <didrocks> and cordova-qt, does it need landing soon?
[16:16] <kenvandine> builds broke because of the linker problem
[16:17] <didrocks> yeah, funny mir-related thing :)
[16:17] <kenvandine> annoying... :=D
[16:17] <robru> didrocks, victor already asked me to do some packaging for cordova... I have a couple branches in progress there, at least for cordovamobilespec
[16:17] <kenvandine> other than that, i've been doing all settings work
[16:17] <kenvandine> cellular stuff with ofono-qt
[16:18] <kenvandine> and accounts panel
[16:18] <didrocks> robru: please keep kenvandine in the loop on that so that you don't duplicate. And file the spreadsheet so that when I receive a request, I know that it's already handled :)
[16:18] <robru> didrocks, ok, updating now
[16:18] <didrocks> thanks
[16:18] <didrocks> great kenvandine!
[16:18] <kenvandine> i'm not really paying attention to the cordova stuff
[16:18] <kenvandine> that was just while i was filling in for sdk
[16:18] <didrocks> kenvandine: so it's in robru's hand now? :)
[16:18] <didrocks> ok
[16:18] <kenvandine> i guess :)
[16:18] <didrocks> my turn now
[16:19] <didrocks> so, I've spent a crazy amount of time on Mir
[16:19] <didrocks> Mir is default now, xorg is building on it
[16:19] <didrocks> like the drivers
[16:19] <didrocks> but it's not activated
[16:19] <didrocks> we need unity-system-compositor for that
[16:19] <didrocks> and once again a last minute issue appeared
[16:19] <didrocks> defined as well some criterias for it being default, and for it staying on the release
[16:20] <didrocks> on a more fun side, I've drafted the first version of the ui for system update
[16:20] <didrocks> and helping barry to define the API
[16:20] <didrocks> (we did a demo at the IoM)
[16:20] <didrocks> unity8 is now landed in the distro
[16:20] <didrocks> and finally, some warnings
[16:21] <didrocks> a little bit of reshuffling that I just pushed around dailies
[16:21] <didrocks> the goal is to prepare to have dailies every 3h
[16:21] <didrocks> but it also means:
[16:21] <didrocks> - as long as a stack isn't really building, you can still be able to do some manual publication
[16:22] <didrocks> - if you publish manually a stack, all reverse dependant stack that was waiting for this one to be published will be automatically published
[16:22] <didrocks> (to avoid having too many push buttons)
[16:22] <didrocks> I think we'll need to have a hangout about it if you don't mind
[16:22] <didrocks> maybe this week as robru is in a sane timezone finally? ;)
[16:22] <robru> didrocks, hah! I was going to ask if we can wait until I'm back home ;-)
[16:22] <didrocks> robru: as you wish, do you feel your connexion won't be enough?
[16:23] <robru> didrocks, no, connection is ok, just unbearably hot here, will feel more comfortable at home
[16:23] <robru> for video chatting ;-)
[16:23] <didrocks> ok, so I propose that we switch next week meeting for a hangout?
[16:23] <didrocks> robru: Mirv: kenvandine: cyphermox: wdyt? ^
[16:23] <robru> didrocks, ok
[16:23] <Mirv> ok
[16:23] <didrocks> at least, same hour, no need to stay late and so on
[16:23] <robru> yeah
[16:24] <kenvandine> sure
[16:24] <didrocks> ok, let's plan for it! ;)
[16:24] <didrocks> please think about marking your items as done, I'll archive in a few
[16:24] <didrocks> thanks everyone, have a good week!
[16:24] <robru> didrocks, great, thanks! bye bye for now!
[16:24] <didrocks> (and if you see daily-release being broken by my change today, a kind email is appreciated for my tomorrow's coffee time)
[16:24] <Mirv> thanks to you
[16:25] <didrocks> see you robru, Mirv ;)
[16:52] <kenvandine> didrocks, robru: can one of you review this https://code.launchpad.net/~ken-vandine/cupstream2distro-config/remove_dupe_from_phone/+merge/178570
[16:52] <didrocks> kenvandine: trusting you :)
[16:52] <didrocks> kenvandine: if you deploy, ensure you merge trunk first
[16:53] <didrocks> very important, dangerous changes in :)
[16:53] <kgunn> mlankhorst: wrt mir....do you get something similar to https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1208715
[16:53] <ubot2`> Ubuntu bug 1208715 in xorg-server (Ubuntu) "XMir fails to start on intel" [Undecided,New]
[16:53] <kenvandine> ok, i actually deployed this change yesterday :)
[16:53] <kgunn> mlankhorst: at least my recent comments
[16:53] <kgunn> bschaefer: ^
[16:54]  * bschaefer looks at bug
[16:54] <bschaefer> kgunn, hmm, well I can update my laptop here to test that
[16:55] <didrocks> kenvandine: ah, I probably remove it then
[16:55] <didrocks> kenvandine: I deployed from trunk 1h ago
[16:56] <kgunn> bschaefer: seems -testing ppa is fine....now the goal is to stabilize what's in main....not sure if xorg moved (or maybe we screwed up by not using what  was already in main, e.g. rebase xorg patches)
[16:56] <kgunn> bschaefer: would be good to have another data point - but i  suspect RAOF will need to have a look when he gets on
[16:57] <bschaefer> kgunn, alright, well it can never hurt to test main saucy with the testing ppa on intel, which I hope I don't get those intel errors
[16:57] <bschaefer> usually bad: intel_drv.so undefined symbol xmir_get_drm_info
[16:57]  * bschaefer restart lightdm