[05:56] hey Mirv! [05:59] morning didrocks [05:59] Mirv: I just pinged the QA team as you can see the autopilot ati machine is down [05:59] not sure if you tried to ping them already [06:00] didrocks: not yet, I saw connection problems but wasn't sure if it was random so tried again. thanks for pinging. [06:55] for those ubuntu developers out there am in college and ave decided to give it a go [06:55] how do i go about it ?? [07:11] Hargard: http://www.ubuntu.com/download should get you started [07:25] good morning [07:41] salut jibel! [07:41] 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] ça va? [07:41] no explanation in the merge request though [07:41] jibel: thanks for restarting the ati machine btw :) [07:42] Salut didrocks , ça va et toi? plus reposé qu'hier? [07:42] didrocks, de rien [07:42] Mirv: ok, let's trust then :) +1 [07:42] jibel: un peu mieux et un moins chaud! [07:42] didrocks, I still don't get why this machine and only this one goes down [07:42] ok [07:43] jibel: right, that's weird. I guess there is no way to have something able to restart it from magners? [07:44] didrocks, and each time when it starts the platform stack [07:44] didrocks, is there anything special with this stack? [07:44] the only think I can see is that libhybris is installed and have opengles android drivers [07:44] didrocks, I can add a nagios check with an autorestart [07:45] but it would be a 100% reproduceable if it was that one making everything failing [07:45] but I don't really fancy systems that tries to automatically fix themselves [07:45] indeed [07:45] jibel: just give me a way to restart it at least ;) [07:46] didrocks, connect to the CDU and electrically reboot it :) [07:46] jibel: I have no idea how to do that TBH ;) [07:46] an email would help [07:50] didrocks, honestly the qa prod team should do that, I'll send them an email [07:51] 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] jibel: thanks! I tried to ping them this morning, but we have been stuck for 2 hours [07:52] Mirv: +1 on both (your end of sentence have been cut though) [07:52] didrocks: ah.. it was "should mir archs be just 'any' as well?" [07:53] Mirv: no, we don't build Mir on powerpc on purpose [07:53] (hence the lenghty list) [07:53] didrocks: ok === thumper is now known as thumper-afk [08:13] 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] Mirv: hum -data is confonding [08:14] Mirv: I would expect assets [08:14] qtcreator-plugin-ubuntu isn't possible? [08:14] even if we ship a qtcreator-plugin-ubuntu-data binary package [08:15] (so that the day we can have real binary plugin code, we just skip to the same package) [08:15] 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] ship* [08:15] Mirv: I can if you add a comment in debian/control, that's good enough [08:15] s/can/think/ [08:16] maybe qtcreator-plugin-ubuntu-common for the binary package btw [08:16] ok, sounds good to me, the end goal is to have it truly separate [08:16] common makes sense [08:16] right ;) [08:16] thanks Mirv [08:16] thanks for consultance === mpt_ is now known as mpt [08:36] seb128: team meeting reminder btw :) [08:39] didrocks, thanks [08:40] yw ;) [09:06] am I the only one with my sd card being in read only now? [09:07] /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] didrocks, is that a desktop config? [09:25] seb128: I'm on my desktop, yeah [09:25] can't remount it rw [09:26] didrocks, wfm, I just put an sd in the laptop reader and it's rw for me [09:26] $ ls -l /dev/mmcblk0 [09:26] the other options are the same as yours [09:26] brw-rw----+ 1 root disk 179, 8 août 6 11:25 /dev/mmcblk0 [09:26] I would need a pitti… :/ [09:26] $ ls -l /dev/mmcblk0p1 [09:26] brw-rw----+ 1 root disk 179, 1 août 6 11:25 /dev/mmcblk0p1 [09:26] ok, it's something else probably [09:27] you are sure you didn't toggle the security on the sdcard by accident? [09:27] the small plastic piece on the side [09:27] I don't have that toggle [09:27] weird [09:27] it's a micro-sd [09:27] ah, but the adapater has one! [09:29] seb128: ok, never noticed that switch, working now :) [09:29] didrocks, great ;-) [09:29] (it seems that there is nothing blocking it anymore, so it's floating) [09:36] Mirv, hey [09:36] Mirv, are you looking at the stacks while sil2100 is on holidays? [09:37] Mirv, is there any problem with settings (it's still not published from what I can see)? [09:50] 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] Ubuntu bug 1208720 in ubuntu-system-settings "FTBFS on armhf: Library '/system/lib/libGLESv2.so' not found (Segmentation fault)" [Undecided,New] [09:50] was meaning to ping you as well [09:51] shrug [09:52] it's a mir fallout I'm pretty sure [09:52] didrocks, !!!! [09:52] RAOF, ^ does that ring a bell? [09:52] 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] powerd dropped libgles dev dependency just [09:53] seb128, is that on armhf? [09:54] * ogra_ would just add such a link to libgles2-mesa-dev [09:54] tvoss_: yes [09:55] tvoss_, yes [09:55] Mirv, why do you access the libgles at build time? [09:56] Mirv, is that the only component hitting that issue? [09:56] seb128: so far yes [09:57] tvoss_, we don't, we just use qt5 stuff [09:57] tvoss_, something in the qt stack is bringing it for us... [09:57] seb128, so you are running a test or something at build time, right? [09:57] seb128, /system/lib/libGLESv2.so lives on the android side of things [09:58] and is totally device specific [09:58] tvoss_, yes, that's in the tests (running the ui under xfvb-run) [09:58] 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] tvoss_, that was working until yesterday [09:58] seb128, the problem is that libhybris is installed ... [09:59] ogra_, well, I don't, it's a qt5 UI ran under xvfb-run [09:59] ah [09:59] tvoss_, right, we build-depends on it because we use it to access device infos (serial number) [09:59] well, even that should have a runtime mesa fallback then [10:00] seb128, that wont work without having a full android counterpart in place [10:00] seb128, http://pastebin.ubuntu.com/5954397/ is the list of rdepends [10:00] seb128, why do you use it naked? [10:00] tvoss_, well, as said we directly build-depends on it [10:00] seb128, which function do you use? [10:01] #include [10:01] property_get("ro.serialno", serialBuffer, ""); [10:01] tvoss_, ^ [10:01] that cant work [10:01] tvoss_, that can go away the day we have an Ubuntu backend for qtsystems [10:01] ogra_, yet it does ;-) [10:01] seb128, I think you need android-properties, too [10:01] it cant ... [10:02] (at build time i mean) [10:02] ogra_, go to system settings, about and look at "serial number" [10:02] ogra_, the hybris author was working on making it work [10:02] ogra_, it's rsalveti who told me to do that, and it has been working until today [10:02] seb128, i mean in a package build or runtime test of a package build [10:02] unless you actually build on a phone [10:02] ogra_, why? libhybris is there on amd64 and i386 [10:03] why wouldn't it build? [10:03] sure it's not going to work [10:03] there is no backend or properties system [10:03] by libhybris just return the fallback value on a desktop [10:03] that's the 3rd argument of the function [10:03] "" [10:03] by->but [10:03] seb128, it tries to resolve the libraries at startup time [10:03] seb128: libhybris should not be built on i386 or amd64, because it can't ever work there. [10:04] RAOF, wrong [10:04] RAOF, there are pleny x86 based android devices [10:04] RAOF, you can have android on i386 ;-) [10:04] and the plan is to support them [10:04] Ah, fair enough. We *are* planning to support the crazy x86 android :) [10:04] well, that's orthogonal anyway [10:04] * ogra_ just had the same discussion with tvoss_ in #ubuntu-phablet ::) ) [10:04] that's just an include, even if the function is not implemented on !armhf [10:05] things build [10:05] and runtime is doing the right thing [10:05] it returns a fallback value if there is no backend [10:05] 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] the problem is the libegles build issue [10:05] -e [10:05] RAOF, that wouldnt gain you anything since the android side isnt packaged [10:05] and that's new from today [10:05] And the libgles runtime issue, as installing libhybris breaks mesa [10:06] ogra_, I think it was, slangasek mentioned that to me last week [10:06] RAOF, why wasn't it breaking it before today? [10:06] It probably *was*, just that nothing was depending on libhybris? [10:06] RAOF, and can we go back to not breaking it? [10:06] tvoss_, we have an android package we use ... it contains exactly the img files yoou find on cdimage [10:06] RAOF, no, system settings didn't change, we have been doing that for > 1 month [10:06] tvoss_, we will never have it "properly" packaged or usable by a build system [10:07] seb128: Not really; hybris' egl alternate needs to beat mesa's egl alternate on the phone. [10:07] ogra_: Even without the base packaged, android-i386 would be useful; we could build-depend on libhybris [android-any] [10:07] tvoss_, every binary in these packages would be fully device specific [10:08] RAOF, that would mean a complete new arch [10:08] Then android-i386 builds would get the correct dependencies, and i386 builds wouldn't pull in libhybris and break everything [10:08] shrug [10:08] ogra_: Partial arch, surely? [10:08] RAOF, hire 20 new devs and we can talk again [10:08] ogra_, sure [10:08] * ogra_ points to the pain lpia was [10:08] ogra_, what is your proposal to solve this then? [10:09] RAOF, we have been pulling it libhybris in for a month with daily builds every day and didn't get any issue [10:09] tvoss_, have a porper mesa package providing that file linked [10:09] everything else would be 100% HW specific [10:09] ogra_, the interesting bit is: it's not only gl [10:09] RAOF, something changed somewhere starting today [10:09] (as android simply is 100% HW specific ... its an embedded build) [10:10] RAOF, don't make me spend the day tracking to down to the recent xorg/mesa uploads :p [10:10] tvoss_, so we need other packages like that for the other purposes [10:10] seb128: :) [10:10] seb128, when did you start pulling in hybris? [10:10] tvoss_, early july [10:11] tvoss_, RAOF: https://launchpad.net/ubuntu/+source/ubuntu-system-settings/0.1+13.10.20130712-0ubuntu1 [10:11] and things have been working smoothly since, until today [10:11] seb128, so you could happily run your tests at build time until today? [10:12] yes [10:12] RAOF, the last package installing either mesa or hybris would win, right? [10:12] tvoss_: No; mesa's alternate is priority 500, hybris' is 1000. Hybris always wins [10:12] tvoss_, RAOF: that's yesterday's build: [10:12] https://launchpadlibrarian.net/146708048/buildlog_ubuntu-saucy-armhf.ubuntu-system-settings_0.1%2B13.10.20130804-0ubuntu1_UPLOADING.txt.gz [10:12] "xvfb-run -a ./tst_plugins [10:12] libEGL warning: GLX/DRI2 is not supported [10:12] libEGL warning: DRI2: failed to create any config [10:12] libEGL warning: GLX: failed to load GLX" [10:12] we had those warnings [10:13] but not libgles error [10:13] * ogra_ bets it is platform-api, not hybris [10:13] ogra_, then it is more likely to be qtubuntu [10:13] in this specific scenario [10:13] or that, yeah [10:14] just not hybris ... it didnt change in a while [10:14] seb128: You didn't have libhybris installed during that build. [10:14] qtubuntu changed sat, though [10:14] seb128: So, now that something's pulling libhybris into your build environment, it's breaking it. [10:14] hum [10:15] what happened to that build-depends [10:15] and why is it not failing to build earlier since one the header is not installed [10:16] Mysteries of the ages. [10:16] ok [10:17] RAOF, tvoss_: so what do you recommend doing? should whatever is bringing hybris in be fixed to not do that? [10:17] Yes. [10:17] seb128, that was my proposal, but ogra is opposed to binding it to the architecture [10:18] 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] i'm not opposed to fixing it :) [10:18] The former seems simpler ;) [10:18] i'm just opposed to break x86 android on purpose [10:18] Gah. I meant the latter "don't install libhybris unless there's an android system" [10:18] RAOF, right :) [10:19] RAOF, as installation of hybris breaks things right now ... [10:19] RAOF, thast what i was suggesting to tvoss_ [10:19] * seb128 tries to figure out what is brining hybris in [10:19] ogra_, the trigger for "an underlying android system" is a bit difficult to model right now [10:20] 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] ogra_, how to detect that at package build time if not tying to the architecture then? [10:21] at build time you *never* have any android in place [10:21] and *always* need to use the fallback [10:22] good morning my favourite people :) [10:22] 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] Ubuntu bug 1107926 in bamf (Ubuntu) "bamfdaemon crashed with signal 5 in _XReply()" [Medium,Confirmed] [10:23] czajkowski, hey, try talking to Trevinho [10:23] czajkowski: see if you have debug symbols [10:23] ogra_, so effectively you are saying that no one should link against hybris for example, but dlopen/dlsym at runtime then [10:23] czajkowski: I mean, it would be nice if you could install them and get a better stacktrace [10:24] 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] Trevinho: debug symbols? [10:25] czajkowski: yes, see https://wiki.ubuntu.com/DebuggingProgramCrash... [10:25] czajkowski: however I see there are some stack traces on the bug, let me check them first [10:25] Trevinho: cheers [10:25] tvoss_, if you link against hybris, hybris-dev sneeds to provide the right stubs [10:25] or use some other dep that does [10:26] 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] or enhance the stubs :) [10:26] seb128, why do you run the tests at buildtime on an armhf target if not on phone? [10:26] ogra_, I did the lazy loading trick in the platform api, working fine there [10:27] ogra_, that still leaves us with overriding the defaults issue though [10:27] "the lazy loading trick" ? [10:27] ogra_, not resolve symbols from the android side automatically when the program starts but only on demand [10:27] ah [10:27] tvoss_, those tests are from mardy, I'm not sure ... would you recommend those to be rather autopilot/CI tests? [10:28] if they are HW dependent they have to [10:28] seb128, yup [10:28] ogra_, they are not [10:28] it's only a qt5 ui [10:28] we don't test backend code in those [10:28] well, the data you collect is [10:28] well, those tests only test the UI bits [10:29] they don't depend on having a working backends or datas [10:29] seb128, but qou won't have a ui on armhf anyways [10:30] 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] tvoss_, why not? [10:30] seb128, how would they if not running on a device? [10:30] tvoss_, well, the main UI is only qt stuff, it's building a grid of icons for the available plugins [10:31] it can run anywhere where qt5 is working [10:31] then the panels are not going to work, sure [10:31] the bug is definitely that the qt stuff tries to attach to something completely HW specific then [10:31] ogra_, well, the thing is that libhybris being in just breaks qt/gles [10:31] which brings me back to my mesa like statement :) [10:32] hybris needs to fall back to meas gles or something similar [10:32] *mesa [10:32] Mirv: +1 [10:33] ogra_, or we split hybris into core and something like hybris-egl, hybris-gles etc [10:33] ogra_, you could then runtime depend on it, but not build-time depend on it [10:33] rvr, how would that solve the issue ? [10:33] if the UI needs gles it still would fail [10:33] it fails at runtime [10:34] during a runtime test ... no ? [10:34] seb128: do you know if something changed in gdk_error_trap_{pop,push} recently? [10:34] Trevinho, "recently"? [10:34] seb128: let's say raring/saucy cycle... [10:34] Trevinho, not that I know of, we have been on gtk 3.8 for over a month [10:34] 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] seb128: as that crash should be handled by gdk, without crashing actually.. [10:35] tvoss_, no, that would be wrong [10:35] ogra_, why is that? [10:35] lxc-anroid-config is lower than UI level [10:35] thats like making udev depend on some xserver stuff [10:35] Trevinho, hum, I don't know ... maybe ask on #gtk+? [10:36] seb128: ok... [10:36] seb128: also if I do a new release of libwnck can you import that in archives? [10:36] tvoss_, again, i think we need hybris to fall back to mesa [10:36] Trevinho, sure [10:36] and have a mesa package that provides the bits that are expected [10:36] seb128: cool [10:37] 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] ogra_, that's not something we can do easily right now [10:37] tvoss_, i dont think it is so significant [10:38] tvoss_, mesa already ships libGLESv2.so .... just not in the place the code expects it [10:38] 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] all you need is some links ... and for cleanness probanly a separate package so you dont mess up desktop [10:39] ogra_, I don't think that it is that easy, that's why I'm trying to find another solution [10:40] LD_PRELOAD during build then ? [10:43] 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] seb128, awesome so tvoss_ just needs to fix bug 1118903 [10:44] Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged] https://launchpad.net/bugs/1118903 [10:44] :P [10:44] just (tm) [10:45] tvoss_, so your suggestion is to move those tests from build time to CI right? [10:45] seb128, if that's easily possible ... yes [10:45] didrocks, Mirv: is the CI for ubuntu-system-settings/armhf done on machines that have an android side? [10:46] thats definitely planned [10:46] (not sure if it is there yet) [10:46] planned != today [10:46] yeah [10:46] I need system settings to keep landing [10:46] seb128: if it's autopilot tests, right [10:46] I can't just say "we are not going to land updates until that happens" [10:47] 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] seb128: yeah, convert them to autopilot tests [10:48] and move them to CI later once CI happens on actual target devices [10:48] didrocks, can I just make them autopkgtests? ;-) that's a "make test" in the build tree, not really autopilot material [10:48] seb128: I don't think autopkgtests run on android hw [10:48] :-( [10:50] ogra_, you suggested earlier to LD_PRELOAD libgles right? I might just try that in the package build... [10:50] no idea if that works though :) but i imagine it could [10:50] I ran a build on my N4 and obviously it succeeded since there was the android side [10:52] 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] 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] yes [10:58] libmir is broken here [10:58] * didrocks didn't follow the whole discussion [10:58] and the only proper fix is to fix the bug above [10:58] but theorically, all !armhf are broken too, right? [10:59] like everything that will use opengles? [10:59] didrocks, nope, it will just fall back to mesa as it should if libhybris isnt pulled in === MacSlow is now known as MacSlow|lunch [10:59] didrocks, well, libmirclient1 doesn't depends on libhyrbris on !armhf I think [10:59] ok, but if you install it [10:59] (at least i would assume this) [10:59] you are screwed? ;) [10:59] I guess [10:59] * seb128 tries [10:59] ogra_, that's not true, it comes down to supporting installing mutliple vendor-specific gl implementations [10:59] didrocks, right [11:00] tvoss_, which you cant di at build time [11:00] *do [11:00] ogra_, only if mesa supports it [11:00] else you end up with HW specific binaries [11:01] tvoss_: I don't think the u-s-c issue is that one though, we don't pull libhybris in it [11:01] 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] 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] Trevinho, ok, will do [11:18] Trevinho, did you figure out the issue/change with gtk? [11:35] tvoss_, ogra_, RAOF: unity CI is broken as well: [11:35] https://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-autolanding/157/console [11:35] linkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found [11:35] Segmentation fault [11:35] see above :) [11:35] ogra_, the alternative depends is not going to fix that [11:35] seb128: yeah, convert them to autopilot tests [11:35] and move them to CI later once CI happens on actual target devices [11:36] seb128, no, fixing bug 1118903 will [11:36] Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged] https://launchpad.net/bugs/1118903 [11:36] ogra_, well, that's not going to happen this week for sure [11:36] (which would result in some alternate depends) [11:36] seb128, right, so go with autopilot for now [11:37] ogra_, I'm not converting half of the ubuntu archive to drop make check tests and use autopilot [11:37] let me email ubuntu-devel@ as a fyi meanwhile [11:37] in case others wonder what's going on [11:38] 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] 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] Mirv: ah sweet! looking good, +1 :) [12:02] thanks again [12:02] thanks to you! === tvoss_ is now known as tvoss|lunch === MacSlow|lunch is now known as MacSlow === ritz_ is now known as ritz|zzz === m_conley_away is now known as m_conley === tvoss|lunch is now known as tvoss|hungry === tvoss|hungry is now known as tvoss_ [14:15] 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] seb128: ogra_: yeah, just the property system is fine, as that doesn't depend on hybris itself [14:15] it's a separated library [14:16] rsalveti, the dep on libmirclient [14:16] oh, and it all started there :-) [14:17] yeah, forcing 'android' == 'armhf' is a big and annoying issue [14:17] rsalveti, xorg is [14:17] as it'll cause all these weird build-depends just for armhf [14:17] rsalveti, xorg depends on mir and libmirclient1 depends on libhybris on armhf [14:17] rsalveti, and we build-depends on qt, which brings in xorg, which brings in mir, which brings in libhybris [14:18] oh, the joy [14:18] * rsalveti looks for coffee [14:59] seb128, can you do an easy review for me? it's going to block getting some ubuntu-system-settings-online-accounts fixed [14:59] https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/mod_dir/+merge/178772 [14:59] kenvandine, not sure, you don't do my easy reviews, why should I do yours :p [14:59] * seb128 is looking [14:59] :-D [15:00] kenvandine, https://code.launchpad.net/~seb128/telephony-service/sounds-events-from-gsettings/+merge/178344 btw ;-) [15:00] ups [15:00] the accounts plugin is no longer getting loaded, since the path changed [15:00] and i uncovered the pkgconfig file is broken :) [15:00] kenvandine, https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-improve-display-name/+merge/178587 I meant [15:01] oh... i looked at that yesterday and forgot to give it an ack [15:02] seb128: can you sit tight on not uploading new X without checking with olli? [15:02] and kgunn? [15:02] seb128: in general, please always coordinate any upload yuou do :) [15:02] with them [15:02] asac, sure, can we do that the other way around too? they just broke armhf with their Mir work :p [15:03]