[07:54] <AceLan> Hi, is it possible to run camera-app on desktop environment? http://paste.ubuntu.com/9210403/ # This is what I got to run camera-app from desktop
[08:20] <dholbach> good morning
[08:43] <rpadovani> oSoMoN, o/ As you see, I didn't fix tests for my branch, I'm sorry - Also I don't think I have time this and next week. Do you want I push on a shared branch, so you can fix tests, or do you prefer to wait and I fix them as soon as I have some free time?
[08:46] <tsdgeos> Mirv: i could not reproduce any restart
[08:47] <tsdgeos> do you have any crash log? is there still any ppa with those dbus changes in?
[08:51] <oSoMoN> rpadovani, there’s no rush at this point, and I’m busy with other things, so take your time :)
[08:52] <rpadovani> oSoMoN, ok cool :-)
[09:03] <Mirv> tsdgeos: are you sure you used the PPA's version, since as of Friday the same version number is in archives? let me do a ubuntu6 to the 027 silo
[09:05] <Mirv> tsdgeos: the upstart logs I provided already, I've some .crash files but I cannot be sure if they were during testing that PPA or during my other PPA autopilot testing: http://people.canonical.com/~tjyrinki/qt532/possible-dbus/
[09:21] <tsdgeos> dpm: any idea of what may be wrong in https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1395640  ?
[09:21] <tsdgeos> Mirv: no, not totally sure
[09:23] <dpm> tsdgeos, no, I don't know, I actually think I reported it a while ago too
[09:25] <dpm> tsdgeos, I can't find my bug, perhaps I didn't report it in the end, but I had a conversation with Mirco about it. Could it be that the wrong domain is set?
[09:25] <tsdgeos> don't think so
[09:33] <tsdgeos> seb128: ↑↑ do you know how this works?
[09:35] <seb128> tsdgeos, dpm, I think it's https://code.launchpad.net/~seb128/indicator-power/update-translations-list/+merge/238258 ?
[09:35] <seb128> tsdgeos, dpm, bug #1391702
[09:35] <mardy> dednick: hi! Sorry for Friday, I got disconnected; let me know when we can resume the discussion (bug 1395028)
[09:36] <dpm> ah, thanks seb128
[09:36] <tsdgeos> seb128: this is very confuing
[09:36] <tsdgeos> make .pot creates a correct .pot file
[09:36] <seb128> tsdgeos, ?
[09:36] <dednick> mardy: no worries. whenever you want
[09:37] <tsdgeos> seb128: but something else is using po/POTFILES.in ?
[09:37] <seb128> tsdgeos, no, it's just that the fix landed in vivid/trunk
[09:37] <tsdgeos> do we have two scripts/lists in the same project to generate .pot files?
[09:37] <seb128> but not in rtm
[09:37] <seb128> where commit/branch do you run make pot on?
[09:37] <seb128> where do you see the issue?
[09:37] <tsdgeos> seb128: i'm in rtm packages
[09:38] <tsdgeos> apt-get source
[09:38] <tsdgeos> and make pot gave me the correct .pot
[09:38] <tsdgeos> but indeed that file is missing from POTFILES.in
[09:38] <seb128> weird
[09:38] <seb128> what command is make pot calling?
[09:39] <mardy> dednick: so, the main usecase is when A is a client application, B is an unconfined process (the Online Accounts interface), and C is another confined process (an Online Accounts plugin)
[09:39] <tsdgeos> seb128: http://paste.ubuntu.com/9211624/
[09:40] <seb128> ok, yeah
[09:40] <seb128> tsdgeos, that project uses cmake, so yeah, the ubuntu build and make pot run different command
[09:40] <tsdgeos> that's horrible
[09:40] <seb128> the Ubuntu build/dh-translations integration uses intltool-update
[09:40] <seb128> which relies on the POTFILES.in
[09:40] <seb128> the cmakery does its own thing
[09:41] <seb128> tsdgeos, we should probably commit something like that https://code.launchpad.net/~seb128/indicator-session/update-translation-template/+merge/240458 and delete the POTFILES.in
[09:41] <seb128> tsdgeos, that would make it update the pot with "make pot" rather than calling intltool-update
[09:41] <tsdgeos> having 1 place to do things is better
[09:41] <seb128> tsdgeos, what is?
[09:41] <tsdgeos> having 2 leads to confused people like me :D
[09:41] <seb128> right
[09:42] <seb128> cf what I just wrote
[09:42] <tsdgeos> yes
[09:42] <seb128> I'm going to do a mp for that
[09:42] <dednick> mardy: ok. i need to know exactly how the processes are dealing with prompt sessions. ie which process creates the prompt sessions.
[09:43] <tsdgeos> seb128: thing is i don't know enough of the debian/ubuntu side to give you the +1 of the .pot file ending in the correct place with the correct name the debian side needs
[09:43] <seb128> tsdgeos, dpm, meanwhile we should land https://code.launchpad.net/~seb128/indicator-power/update-translations-list/+merge/241617 for ota if we can
[09:43] <dednick> mardy: you said there were 2 prompt sessions?
[09:43] <tsdgeos> seb128: +1
[09:43] <seb128> tsdgeos, there is no "debian side", launchpad imports any .pot it finds in the builddir
[09:43] <seb128> but anyway, let it to me, I know what to do
[09:43] <tsdgeos> ah that's good :D
[09:45] <mardy> dednick: no, it's only one session; there is another non-UI process which creates the session and starts both processes B and C inside it
[09:45] <mandel> ogra_, when ever you have the time, can you build android tools with this patch => http://paste.ubuntu.com/9211691/
[09:45] <mandel> ogra_, is shorter that the previous one and AFAIK it should work
[09:45] <dednick> mardy: can you point me to the code?
[09:47] <ogra_> mandel, oh, i thought you would just call dbus-send and hand over the address to this
[09:47] <mardy> dednick: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/lp1380914-lite/files/head:/online-accounts-service/
[09:48] <mardy> dednick: mir-helper and ui-proxy
[09:48] <mandel> ogra_, no need AFAIK, I found the security setting and a workaround :P
[09:48] <ogra_> ah, cool
[09:48] <mandel> ogra_, I'd like to test it, afaik it should work
[09:48] <JamesTait> Good morning all; happy Monday, and happy Celebrate Your Unique Talent Day! :-D
[09:48] <mandel> ogra_, if we fake the userid the security thinks we are the good guy :)
[09:49] <mandel> ogra_, and we can call it etc.. if that is the case we can set the env var (so that we only look for it once and so that we can set it for testing) and do all the stuff
[09:49] <dednick> mardy: where is the second one coming from?
[09:51] <mardy> dednick: same code: see that in line 204 and followings, we resue the same trust session if the initiator PID is the same: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/lp1380914-lite/view/head:/online-accounts-service/mir-helper.cpp#L204
[09:51] <mardy> *reuse
[09:53] <dednick> mardy: where is the "re-use"? i seen it calling createPromptSession in setupPromptSession.
[09:54] <mandel> ogra_, sorry, I found a meme leak, fixed here => http://paste.ubuntu.com/9211814/
[09:54]  * mandel grabs coffee to stop making mistakes
[09:54] <dednick> mardy: oh, sorry, it's private vs public methods
[09:58] <dednick> mardy: is this easily reproducable on the phone image now? or need tht branch?
[09:59] <dednick> not really sure why it's not working. perhaps a unity8 upstart log might shed some light though
[10:00] <mardy> dednick: you need that branch, unfortunately. If you want, I could modify your trusted prompt examples (where were they?), it should be rather quick
[10:01] <dednick> mardy: lp:~nick-dedekind/+junk/trusted_sessions_app
[10:02] <dednick> mardy: not really sure why it's different though. maybe adding fd's twice is buggy or something. i think i only tested using multiple fds at once.
[10:04] <mardy> dednick: I remember that we agreed that there would be a limit on the number of trusted sessions, but not on the number of processes participating in it
[10:05] <dednick> mardy: right. can only have one trust session started by a single process, but there shouldnt be a problem nesting them or having multiple participants.
[10:06] <dednick> i mean one trust session per process.
[10:56] <Mirv> sil2100: thanks for the quick appmenu qt 5.4 branch! any idea about the problem I still saw with it in the PPA?
[10:58] <Mirv> sil2100: I must say I didn't yet upgrade my desktop to the qt 5.4 beta, but I'm doing that now..
[10:58] <sil2100> Mirv: hey! Let me take a look at that ;)
[10:58]  * sil2100 the same
[10:58] <Mirv> sil2100: ok, and of course there are more important stuff to do, but I'm happy to give you some coding fun :)
[11:01] <Mirv> I hope some of the bug I've seen so far go away with the release candidate, but that of course does not apply to changed API:s etc
[11:15] <ogra_> mandel, ervices.c: In function ‘is_phone_locked’:
[11:15] <ogra_> services.c:385:5: error: unknown type name ‘GDBusConnection’
[11:15] <ogra_>      GDBusConnection *connection = NULL;
[11:16] <ogra_> mandel, i assume the dbus header is missing ?
[11:16] <mandel> ogra_, uh.. let me double check, one sec
[11:16] <mandel> ogra_, #include <gio/gio.h>
[11:16] <mandel> ogra_, sorry
[11:17] <ogra_> np
[11:25] <ogra_> and another one ...
[11:25] <ogra_> services.c:473:5: error: expected ‘;’ before ‘setuid’
[11:25] <ogra_>      setuid(0);
[11:35] <ogra_> mandel, ...
[11:35] <ogra_> services.o: In function `is_phone_locked':
[11:35] <ogra_> /home/phablet/android-tools-4.2.2+git20130218/core/adbd/services.c:426: undefined reference to `g_dbus_connection_new_for_address_sync'
[11:35] <mandel> ogra_, wtf? I compiled al this correctly...
[11:36] <mandel> ogra_, `g_dbus_connection_new_for_address_sync' in in gio.h
[11:36] <mandel> is8
[11:36] <mandel> is*
[11:36] <ogra_> hmm
[11:37] <mandel> ogra_, let me try again
[11:37] <ogra_> do i perhaps need other includes in the makefile too ?
[11:41] <mandel> ogra_, I keep getting a bloody dpkg-source: info: the patch has fuzz which is not allowed, or is malformed when building every now and then :-/
[11:41] <mandel> ogra_, might need to point to the gir
[11:44] <mandel> ogra_, I need to swear.. puto quilt
[11:44] <mandel> ogra_, forgot to do a add debian/control
[11:44] <ogra_> dont do that in the quilt patch
[11:44] <ogra_> (dont do the makefile there either)
[11:44] <ogra_> that will make quilt a lot more cooperative ;)
[11:45] <mandel> ogra_, really? ahg...
[11:47] <mandel> ogra_, this has all changes => http://paste.ubuntu.com/9213217/
[11:47] <mandel> ogra_, make files etc..
[11:48] <popey> where did "--list-channels" go in ubuntu-device-flash!?
[11:48] <ogra_> mandel, no, it hasnt ... but thats fine :P
[11:48] <popey> aha, under query
[11:48]  * ogra_ assumes you also wanted "#include <gio/gio.h>" in the code 
[11:48] <mandel> ogra_, one sec, the dependency in coontrol is wrong
[11:48] <mandel> ogra_, true
[11:48] <mandel> ogra_, give me another try..
[11:49]  * mandel feels stupid
[11:49] <popey> ogra_: any idea what I'm doing wrong here? http://paste.ubuntu.com/9213233/
[11:50] <mandel> ogra_, I think is ok now = http://paste.ubuntu.com/9213248/
[11:52] <ogra_> builds with just the makefile change added (i assume the package already came in as a dep but will add it to debian/control anyway)
[11:55] <mandel> ogra_, sweet, is better to be explicit.. at least that is what I've learned ;)
[11:55] <mandel> ogra_, but I really really hate how quilt works in that package
[11:56] <ogra_> yep
[11:58] <sil2100> Mirv: hah, I see the problem with my branch, damn, I feel so stupid now ;)
[12:00] <ogra_> mandel, http://people.canonical.com/~ogra/ubuntu-touch/android-tools-adbd_4.2.2+git20130218-3ubuntu37_armhf.deb and the debdiff is http://paste.ubuntu.com/9213359/
[12:01] <mandel> ogra_, testing very eager to get this out of my plate ;)
[12:01] <ogra_> :)
[12:05] <ogra_> popey, you have to ask sergiusens_ about --list-channels, not sure where it went ...
[12:06] <ogra_> popey, try devel instead of 14.09 ... and also give the touch arg
[12:06] <ogra_> oh
[12:07] <ogra_> popey, heh, thats flo ... there was never any rtm promotion for any of the tablets
[12:07] <popey> ah
[12:07] <popey> thats why it's old and crusty then
[12:07]  * popey might put proposed on for the lolz
[12:07] <ogra_> well, there is nothing in it
[12:09] <popey> thanks ogra_
[12:11] <sergiusens> ogra_: hello
[12:11] <sergiusens> ogra_: you have a tail too :-P
[12:11] <ogra_> sergiusens, works :)
[12:11] <ogra_> minne is natiurally grown ;)
[12:12] <ogra_> (together with the goat feet and horns)
[12:13] <Mirv> sil2100: ok, problem found is half of problem solve, sounds good! :)
[12:15]  * sil2100 thinks how to test that now
[12:16] <mandel> ogra_, did you get my last message?
[12:17] <ogra_> mandel> ogra_, testing very eager to get this out of my plate ;)
[12:17] <ogra_> thats the last i see from you
[12:19] <mandel> ogra_, ok, so xchat went nuts when I changed wifi
[12:19] <mandel> ogra_, the package works as expected, there is only one thing I don't like, the client side says 'error: closed' when the screen is locked
[12:19] <mandel> ogra_, I asked rsalveti to take it for a spin too
[12:19] <ogra_> not much we can do about that i guess
[12:21] <rsalveti> right
[12:21] <mandel> ogra_, not really, we are lucky that it happens because the phone is closed lol
[12:21] <mandel> ogra_, would be great if it said 'device closed' lol
[12:23] <ogra_> sergiusens, did davmor2 point you to bug 1395682
[12:23] <ogra_> looks to me like a upower or MMC driver thing
[12:23] <sergiusens> ogra_: it's incomplete for a reason, but it hell ain't ciborium :-)
[12:24] <ogra_> :)
[12:24] <davmor2> sergiusens: I don't care I'm still blaming you :P
[12:24] <sergiusens> and I'm not fixing it
[12:24] <sergiusens> ;-)
[12:24] <davmor2> sergiusens: did you like the screenshot :)
[12:25] <sergiusens> or won't try too unless you collect all that info I asked for
[12:25] <sergiusens> will take you a week at least :-P
[12:25] <sergiusens> davmor2: yeah, the screenshot is useless to me
[12:27] <davmor2> sergiusens: you're so predictable ;)  I doubt some how that it will only take a week :)
[12:31] <sergiusens> davmor2: you have to read the manpages for all the commands ;-)
[12:32] <davmor2> sergiusens: man ciborium: No manual entry for ciborium well that was quick ;)
[12:33] <sergiusens> davmor2: not ciborium, udevadm and such ;-)
[12:33] <davmor2> erm no
[12:39] <mardy> dednick: hi :-) So, I see that your example code works, with multiple apps in the same session
[12:39] <mardy> dednick: mine doesn't because I'm reusing exactly the same fd, and not generating a new one
[12:41] <mardy> dednick: so, I'll try calling mir_prompt_session_new_fds_for_prompt_providers() as I add a new app to the session, then if all works I'll close the bug
[12:43] <mardy> dednick: mmm.... no, I'm actually requesting a new fd per each client... I'll investigate what it is, then
[13:31] <cwayne-afk> janimo: just occurred to me we should probably discuss here instead :)
[13:35] <janimo> cwayne, true :)
[13:35] <cwayne> janimo: so im building a mako image now
[13:36] <cwayne> shouldn't take too long
[13:36] <cwayne> got a pretty beefy desktop here :P
[13:36] <ogra_> cwayne, no, he is vega
[13:36] <ogra_> n
[13:37] <cwayne> ogra_: psh yeah right
[13:37] <ogra_> oh, i read "there"
[13:46] <cwayne> janimo: done
[13:46] <janimo> cwayne, built?
[13:48] <cwayne> yep
[13:48] <cwayne> seein stuff in out/target/product/mako
[13:49] <janimo> cwayne, good.
[13:49] <janimo> cwayne, you can now fastboot flash boot out/target/product/mako/boot.img
[13:49] <janimo> and fastboot flash recovery out/target/product/mako/recovery.img
[13:50] <janimo> or actually u-d-f could do that too if there is a working fastboot mode already
[13:50] <cwayne> done
[13:51] <cwayne> janimo: do i need to do the rootstock bits for the rootfs now?
[13:52] <janimo> cwayne, I have never used that. I was wondering how to only do it via u-d-f. Need to make a device tarball first
[13:52] <janimo> cwayne, a sec
[13:54] <janimo> cwayne, until I put it in a proper repo:  http://paste.ubuntu.com/9214939/
[13:54] <janimo> run it by passing it a conf file as the first argument
[13:55] <janimo> that file should contain DEVICE=mako
[13:55] <janimo> PARTITIONS="
[13:55] <janimo> recovery.img:recovery.img
[13:55] <janimo> boot.img:boot.img
[13:55] <janimo> "
[13:56] <janimo> you can make the tar.xz by hand of course, making sure you have /system/var/lib/lxc/android/system.img in it
[13:56] <janimo> but this script is preferred, it's what we have been using internally for making device tarballs
[13:56] <sergiusens> janimo: can't that just be a make target?
[13:57] <janimo> sergiusens, I preferred not adding new targets to the build system, so we carry fewer patches (slightly different for each OEM tree) and to have easier dev and maintenance of this scipt
[13:58] <janimo> it's a separate step, but we can have one command builds by having a top level shell script do make + mktarball+ whatever other postprocessing
[13:58] <cwayne> cwayne@boomer:~/Projects/ports/opo/out/target/product/mako$ ubuntu-device-flash --device-tarball device_mako.tar.xz --bootstrap --channel ubuntu-touch/devel-proposed
[13:58] <janimo> it is what we do for some OEM builds ATM
[13:58] <cwayne> janimo: ^ that look right?
[13:59] <janimo> cwayne, you may need --device mako too
[13:59] <janimo>  I think you need to be explicit when in bootstrap or recovery mode
[13:59] <cwayne> it got it somehow
[14:05] <cwayne> janimo: stuck at google screen :/
[14:07] <dednick> mardy: yeah, i looked at the fd thing and it seemed ok on first glance. Only difference is that i think my map is calling "mir_prompt_session_new_fds_for_prompt_providers(X)" where x is the number of prompts to be added, rather than calling "X * mir_prompt_session_new_fds_for_prompt_providers(1)".
[14:08] <Saviq> mardy, hey, can you tell me if bug #1352251 is a problem still?
[14:09] <mardy> Saviq: yes, at least it was last time I checked
[14:09] <mardy> Saviq: now I'm reflashing my device so I cannot check, but I'll do that tomorrow
[14:10] <mardy> Saviq: is your question about whether the bug has already been fixed, or about whther it should get fixed?
[14:11] <Saviq> mardy, the latter
[14:11] <Saviq> mardy, as with trusted prompts you only create the Mir connection when you create the UI
[14:12] <janimo> cwayne, it may be you need vendor blobs which we do not have in the repo
[14:12] <Saviq> since you need to talk to the trusted socket (IIRC)
[14:12] <janimo> and last I checked it was not clear where to get tem in the wiki
[14:12] <Saviq> mardy, so I'm wondering whether this problem is still valid for you
[14:12] <janimo> I know I added that info last year
[14:16] <janimo> cwayne, something like this, https://github.com/janimo/vendor_lge_mako but we need the 4.4 version now
[14:16] <cwayne> janimo: like this? https://developers.google.com/android/nexus/drivers#mako
[14:17] <janimo> cwayne, yes, those, not sure where those get unpacked, should be under /vendor/lge/mako
[14:17] <cwayne> were on 4.4.2 right
[14:17] <janimo> but apart from the actual blobs google provides, some makefiles are needed too, to hook them in
[14:18] <cwayne> ah, boo
[14:19] <Saviq> mardy, https://bugs.launchpad.net/qtmir/+bug/1352251/comments/7
[14:19] <janimo> cwayne, this is the most annoying part of the build I agree
[14:20] <janimo> cwayne, you could try building the kernel source for your device
[14:21] <janimo> the mako build was mostly for testing, it will probaly work once the vendor blobs are there
[14:21] <cwayne> janimo: yeah, so maybe ill just skip mako
[14:22] <cwayne> janimo: these two seem relevant to my interests: https://github.com/ubuntu-touch-oneplus-one
[14:23] <cwayne> janimo: but i still don't understand like where to put these
[14:23] <cwayne> and how to get a lunch combo out of it
[14:23] <cwayne> and stuff like that
[14:25] <janimo> cwayne, right, those along with the kernel should be the only device specific parts
[14:26] <janimo> one goes under device/oneplus/bacon
[14:26] <cwayne> so just git clone it there?
[14:26] <cwayne> that'd be the proprietary_vendor_oneplus right
[14:26] <janimo> the other under vendor/oneplus/bacon
[14:27] <janimo> cwayne, but the first step should be bringup of the Ubuntu kernel and recovery. This does not need the vendor bits
[14:27] <janimo> those are Android drivers and daemons for GPU and sensors and BT/Wifi which are only needed by the full system
[14:28] <janimo> the lunch combo is added by sourcing the .mk files under devices/ recursively
[14:28] <cwayne> alright, how do I do that?
[14:29] <janimo> and this repo should add that too
[14:29] <janimo> cwayne, https://github.com/ubuntu-touch-oneplus-one/android_device_oneplus_bacon/blob/cm-11.0/vendorsetup.sh
[14:29] <cwayne> ah, cool, except that it's for cm i guess
[14:29] <janimo> cwayne, but this repo is for a CM build, which has a different build system than AOSP hence some files are not going to work
[14:30] <cwayne> damn
[14:30]  * cwayne is worried this is all going to be too complicated for him
[14:30] <janimo> cwayne, so you will need to adapt the .mk files but not other to look like those under device/lge/mako or others in AOSP
[14:30] <janimo> cwayne, not complicated but tedious for sure
[14:30] <janimo> and error prone
[14:30] <cwayne> ah, i can handle tedious probably :)
[14:31] <cwayne> ok, so git clone the android_device_oneplus_bacon to device/oneplus/bacon?
[14:31] <janimo> cwayne, yes
[14:32] <cwayne> janimo: okies, done
[14:32] <janimo> cwayne, but yes, it is a bit annoying to figure out which CM files to put in which AOSP file
[14:32] <janimo> cm.mk is not needed at all for instance
[14:32] <cwayne> then git clone propritery_vendor_oneplus_bacon to vendor/oneplus/bacon
[14:32] <janimo> but its content is
[14:33] <cwayne> ah, okay
[14:34] <cwayne> so where do i move the content to
[14:34] <janimo> cwayne, those files include each other, and only one (device_full.sh ?) is sourced by the build
[14:34] <janimo> BoarConfig.mk is needed
[14:34] <janimo> cwayne, TBH I do not remember which does what, so I'd first have to read the mako ones to refresh my memory
[14:35] <janimo> cwayne, you could try that, by trying to put similar definitions where they are in mako
[14:35] <janimo> or wait till I can have a look at this too later today
[14:35] <janimo> cwayne, you could also try building the kernel which is orthogonal to all this
[14:35] <cwayne> jeeze
[14:36] <cwayne> i'll wait til you can have a look i suppose, I've got plenty of actual work to do :P
[14:36] <janimo> it should build as is (stock android), then add Ubuntu configs to it, then some Ubuntu patches (optional at this stage)
[14:36] <janimo> cwayne, ok. Porting to new can  take weeks even for people who have done it before, so do not get discouraged
[14:37] <janimo> hopefully we'll make that shorter by making the porting guide better and offering some tools to automate
[14:37] <cwayne> yeah
[14:37] <cwayne> i'm happy to be the guinea pig for the new guide :)
[14:37] <cwayne> ill be even happier if we get ubuntu on this beast of a phone
[14:37] <janimo> cwayne, but this is sort of actual work too, if it makes our process more fluid and gets more porters on board :)
[14:37] <cwayne> janimo: fair point :)
[14:37] <janimo> just not actual work assigned to you I guess :)
[14:38] <janimo> so I'll just ping you when I have better data and not have you waste too much time on this
[14:38] <cwayne> cool beans
[14:38]  * cwayne kicks off a cm build anyway just to see if it works
[15:22] <deneme> hi i have an question about ubuntu tocuh
[15:22] <deneme> can in install it to mto g
[15:22] <deneme> *moto g
[15:22] <lotuspsychje> !devices
[15:23] <deneme> for moto g it is working progress
[15:23] <deneme> so i cant install right now
[15:23] <deneme> am i right
[15:24] <deneme> can i try beta version something like that
[15:24] <lotuspsychje> deneme: you can also try the XDA forums, maybe someone got it working
[15:25] <popey> i love that quit message. makes me smile every time
[15:25] <deneme> it seems so risky
[15:26] <lotuspsychje> deneme: well for now most supported devices are nexus
[15:26] <lotuspsychje> deneme: perhaps the future will bring more support to devices
[15:26] <deneme> what do u think about firefox os
[15:26] <lotuspsychje> never tested it sorry
[15:27] <deneme> ok ty
[15:59] <elopio> diwic: ping. How can I know if a headset is plugged into the phone?
[16:01] <sil2100> Mirv: appmenu-qt5 should be good in the branch now
[16:01] <sil2100> (properly tested it with a qt 5.4.0-enabled PPA)
[16:01] <diwic> elopio, pactl list cards | grep available
[16:01] <sil2100> Mirv: I mean, it *builds* at least ;p
[16:02] <sil2100> Mirv: can't test it as I don't have a VM or a second machine to test it with 5.4.0 installed
[16:02] <sil2100> Mirv: but the code path should stay the same
[16:03] <diwic> elopio, or grep for the port name would probably be better, "grep -i headphone"
[16:04] <diwic> elopio, hmm, btw, not sure pulseaudio-utils is installed by default on the phone though...
[16:04] <elopio> diwic: cool, that's useful. I would like to fake a headset, so I can test some things from the sound indicator.
[16:04] <diwic> elopio, in which case you'll have to use the native API instead
[16:05] <elopio> diwic: I think I should do it using a dbus mock. Do you know of a better way to do it?
[16:05] <diwic> elopio, I don't know what a "dbus mock" is, but I don'PulseAudio
[16:05] <diwic> elopio, I don't think PulseAudio exposes that informaiton over dbus
[16:06] <diwic> elopio, at least not on the phone
[16:06] <diwic> elopio, are you going to write a "fake PulseAudio" to test the sound indicator?
[16:06] <elopio> hum, that will make it harder.
[16:07] <elopio> diwic: I don't want a fake pulseaudio if I can avoid it.
[16:07] <elopio> diwic: I just want an easy way to make the phone think it has a headset plugged.
[16:07] <diwic> elopio, hmm
[16:09] <diwic> elopio, can you fake something in sysfs?
[16:10] <diwic> elopio, i e manually modify /sys/class/switch/h2w/state
[16:10] <elopio> diwic: I cana try.
[16:10] <diwic> elopio, that's where PulseAudio reads it from on the phone
[16:10] <diwic> elopio, oh, but then you have to send uevents too...blah
[16:11] <elopio> diwic: I see 2 with headphones, 0 without.
[16:13] <diwic> elopio, yup, that sounds right
[16:13] <elopio> diwic: and I get an i/o error trying to write that file. And I would need root to make the change anyway, so that's not an easy way.
[16:13] <elopio> needing root in the middle of the tests makes it complicated.
[16:14] <diwic> elopio, ok. So either you want to intercept between pulseaudio and the kernel, in which case we're talking about sysfs like we do now
[16:15] <diwic> elopio, or just hack pulseaudio. That's probably the simplest. the code is in src/modules/alsa/alsa-extcon.c
[16:41] <mandel> barry, I pushed a number of changes for bug 1390205 can you take a look once the builds are done?
[16:42] <barry> mandel: yep,thanks
[16:42] <mandel> barry, no problem, took a little to find way it was happening
[16:45] <seb128> kenvandine, hey
[16:45] <kenvandine> hey seb128
[16:45] <seb128> kenvandine, did you notice that the flight mode/rotation lock/about settings listitems lost their icons in v?
[16:46] <kenvandine> seb128, no...
[16:46] <kenvandine> grr
[16:46] <seb128> kenvandine, can you look if that happens to you?
[16:46] <seb128> just saw that on my desktop
[16:46] <kenvandine> yes, i just did
[16:46] <kenvandine> i see the same
[16:46] <kenvandine> i wonder what happened
[16:46] <seb128> I guess it's a toolkit regression
[16:46] <kenvandine> yeah
[16:46] <seb128> let me chase that down
[16:47] <seb128> I just wanted to check if you looked at the issue before starting
[16:47] <kenvandine> seb128, there was a ubuntu-ui-toolkit-theme update in image 29
[16:48] <kenvandine> seb128, yes... there was changes to Switch
[16:49] <kenvandine> well SwitchStyle
[16:49] <kenvandine> "Use icons from theme"
[16:49] <kenvandine> but this is really a ListItem right?
[16:51] <seb128> kenvandine, correct
[16:52] <kenvandine> we use the icon from the suru theme
[16:52] <kenvandine> i wonder what other apps we can look at to compare
[16:52] <kenvandine> ah, the uitk gallery :)
[16:54] <kenvandine> seb128, oh... it's all busted
[16:55] <kenvandine> sigh
[16:55] <kenvandine> any ListItem with an icon has no icon
[16:55] <kenvandine> even in the uitk gallery
[16:55] <kenvandine> bzoltan, ^^^ is that known?
[16:58] <bzoltan> kenvandine: where is it?
[16:59] <kenvandine> bzoltan, seb128 just filed bug 1395793
[17:00] <seb128> bzoltan, it's a regression from friday's toolkit update, downgrading the deb fixes it
[17:01] <kenvandine> so has that version landed in rtm as well?
[17:02] <seb128> I doubt it
[17:02] <bzoltan> kenvandine:  no, we do not land UITK to RTM for long time
[17:03] <kenvandine> ok... i know vivid had been way behind rtm
[17:04] <bzoltan> kenvandine:  to RTM we land only for special request
[17:05] <bzoltan> seb128: kenvandine: is there any app what uses icons in listitems?
[17:05] <seb128> bzoltan, system settings
[17:05] <kenvandine> and the uitk showcase :)
[17:05] <kenvandine> at least
[17:05] <kenvandine> i'm sure there are others
[17:06] <seb128> messages could be
[17:06] <seb128> contacts as well
[17:06] <seb128> I didn't look at the code but their UI is list like with text and icons on the left
[17:09] <anpok> dekko
[17:09] <bzoltan> seb128:  where the system setting is using it?
[17:09] <seb128> bzoltan, on the main screen for the orientation lock/flight mode/about this device/reset device items
[17:10] <bzoltan> seb128:  OK, I am flashing the device and check it
[17:10] <seb128> bzoltan, you can test the small testcase from the bug if you want
[17:10] <seb128> on desktop
[17:11] <bzoltan> seb128:  I am not on vivid, yet
[17:11] <seb128> bzoltan, also cf #sdk discussion, I'm testing a branch from kalikiana which might fix it
[17:11] <seb128> bzoltan, you don't run the current toolkit version on your utopic?
[17:12] <bzoltan> seb128:  of course not
[17:13] <seb128> bzoltan, the concept of not running what you work on seems weird to me, but ok ;-)
[17:13] <bzoltan> seb128: hmm...
[17:14] <bzoltan> seb128:  target env !=  dev env
[17:14] <seb128> bzoltan, well, for sure I've ways/chroots to test all series of the stuff I work on
[17:14] <seb128> or VMs
[17:14] <bzoltan> seb128:  we have emulators and devices as targets, we use click chroot as rootfs for development
[17:14] <bzoltan> seb128:  I have both emulators and devices on vivid ...
[17:14] <seb128> bzoltan, yeah, and I'm surprised you don't have an handy way to run a test program against the trunk version of the toolkit
[17:15] <seb128> like you need to actually reinstall a device to test trunk
[17:15] <bzoltan> seb128:  but it is a very broadly spread misconception that the development environment should be runtime environment too
[17:15] <seb128> I though you would have an emulator ready to boot
[17:15] <bzoltan> seb128:  I have super handy way .. emulator
[17:15] <seb128> bzoltan, I never said that
[17:16] <seb128> so why don't you boot the emulator and try the 10 line qml example from the bug?
[17:17] <bzoltan> seb128:  there is no update mechanism for emulators... so I need to create an emulator what _might_ have the image with the UITK released to Vivid on Friday
[17:18] <bzoltan> seb128:  I had the latest UITK with Vivid on my device, but I have flashed it with RTM image today for other tests ... my other device is on Vivid I flashed last week.
[17:18] <seb128> bzoltan, ok, let's stop that discuss here, I find it fascinating that you don't have a trivial way to run a test program against trunk of the uitk but it's not my issue
[17:19] <bzoltan> seb128:  I do have...
[17:19] <seb128> it feels like that's the sort of things you should have wrapper/tools that let you do that in 10 seconds at any time
[17:19] <kalikiana> seb128: testing a branch of mine?
[17:19] <seb128> kalikiana, https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/imageSourceNotNOTIFYable/+merge/242655
[17:19] <kalikiana> ah
[17:19] <kalikiana> yes
[17:19] <seb128> kalikiana, it seems to fix https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1395793
[17:20] <kalikiana> seb128: hmmm if that's a side effect, I'd like to see if we can unit-test that explicitly
[17:20] <bzoltan> seb128:  I have like 6 different vivid/rtm setups ... I am testing branches and the staging like 24/7 ... in a bug report like this the first thing i do is a clean flash and brand new emulator. To be sure that I am testing the right stack.
[17:21] <seb128> bzoltan, k, I think your workflow is not efficent, you should maybe have a vivid installation in a VM, so you would just have to boot the VM and qmlscene the testcase, that would give you a trivial 15 seconds work way to confirm a bug
[17:21] <bzoltan> seb128:  When I have seen your report, I started to create a new emulator and flashing a device ... that is how fast I can do it.  My desktop is Utopic, because the target of the SDK tools _IS_ Utopic and Trusty.
[17:22] <bzoltan> seb128:  I have limited number of computers and limited resources .. I am testing the tools on Trusty and Utopic... testing the RTM and Vivid on devices/emulators.
[17:23] <bzoltan> seb128:  I am happy to explain to you how I work and why I choose certain workflow. I am happy to hear your suggestions... it is for sure possible to improve.
[17:23] <seb128> bzoltan, well my suggestion is easy, have a desktop VM with vivid you can boot easily
[17:24] <seb128> it's sometime easier to debug/test on a desktop than on a device
[17:24] <bzoltan> seb128: Simple said... The UITK I am testing on emulator and device, because there are the targets, not the desktop. The desktops I am using for tools validation... that is why I am using U and T on desktop.
[17:24] <seb128> but then it's just a suggestion, feel free to ignore it
[17:24] <seb128> bzoltan, well, most issues can be reproduced and debugged on desktop
[17:24] <seb128> bzoltan, like the one I reported, I reported it from a desktop and already confirmed that kalikiana's vcs fixes it
[17:25] <seb128> I didn't test on a device but I'm pretty confident that if the fix works on desktop it's going to work on the device
[17:25] <bzoltan> seb128:  I do not confirm bugs based on desktop only tests. So an emulator and device  test is mandatory for me.
[17:27] <seb128> k
[17:49] <mandel> barry, packages ready => v
[17:49] <mandel> barry, https://code.launchpad.net/~mandel/ubuntu-download-manager/adapt-network-changes/+merge/242083
[17:52] <barry> mandel: k, thx, might be a little while
[18:05] <mandel> barry, I have tested with the current vivid proposed and looks ok (gets downloaded and installed)
[18:05] <mandel> barry, yet the UI is utterly broken, I need to fix that crap
[18:17] <sil2100> Mirv: if you could test this branch and approve/top-approve it, would be great ;)
[19:12] <plars> ogra_: so I guess due to https://bugs.launchpad.net/ubuntu/+source/android-tools/+bug/1382559 we really need the new udf now? (recall we previously reverted it to the previous version)
[19:12] <ogra_> plars, oh, yeah
[19:12] <plars> :)
[19:13] <ogra_> but that also means rtm needs the new recovery
[19:13] <ogra_> or you keep the old UDF for rtm
[19:13] <ogra_> since the change will only land in OTA-1
[19:13] <plars> ogra_: yes, so we could still get to a bad state on our devices with rtm if use the new udf, and we will get them in an unreachable state if we use the old udf with vivid
[19:14] <plars> ogra_: oh, so it's not in the vivid images yet?
[19:14] <ogra_> i suspect you wont to keep them distinct somehow anyway
[19:14] <ogra_> they will be diverted all the time
[19:14] <plars> ogra_: what do you mean by distinct?
[19:14] <plars> ogra_: we don't use a different udf for different images
[19:15] <ogra_> plars, well, i suspect you will have to in the future
[19:15] <ogra_> devel and rtm will diverge more and more
[19:16] <ogra_> especially in recovery features i fear
[19:16] <plars> ogra_: that doesn't seem reasonable? do we really expect to need a different udf for them for any other reason than this bug? UDF isn't very friendly to run in this way
[19:16] <ogra_> well, many fixes and changes are held back from RTM
[19:16] <ogra_> and that amount will raise
[19:17] <plars> ogra_: I understand rtm is locked down, but couldn't this be handled in udf in some way that's compatible with either? or if not, then vivid could be made to match what's in rtm?
[19:17] <ogra_> probably ... sergiusens ?
[19:17] <plars> otherwise, we always run the risk of bricking a lot of devices
[19:18] <ogra_> i really suspect that this will only be the first time where you have some heavy divergence though
[19:18] <ogra_> rtm is a different distro ...
[19:21] <plars> ogra_: true, but I really don't think you guys want to maintain different tools for flashing different channels any more than the users of those tools (including ci) want to try to sort out which version has to be used with which channel
[19:21] <plars> so one version of the tool really has to work with all channels, with good deprecation if an api change is needed
[19:22] <ogra_> i think sergiusens had something like that in the drawer
[19:22] <ogra_> (deprecation test plans etc ... didnt we have a meeting at teh sprint ?)
[19:22] <sergiusens> ogra_: it is implemented
[19:23] <sergiusens> ogra_: but, as I said, the recovery pushed to rtm is broken
[19:23] <sergiusens> ogra_: so it needs updating
[19:23] <ogra_> sigh
[19:23] <sergiusens> before anything can be done
[19:23] <ogra_> that wont happen soon though
[19:24] <sergiusens> plars: the tool is deprecated correctly; this is the same problem we talk about every week
[19:24] <sergiusens> ogra_: it's really a one line fix that needs to land into rtm
[19:25] <ogra_> sergiusens, yes, that will not happen for at least another week
[19:25] <sergiusens> ogra_: well then this needs to wait until then
[19:25]  * ogra_ double sighs ... 
[19:25] <sergiusens> ogra_: not much we can do, really
[19:26] <ogra_> well, then let me roll back mandel's changes
[19:26] <ogra_> but later tonight, i wanted to stop working hours ago
[19:26] <plars> ogra_: sorry to bring bad news on that, just trying to avoid a fire drill when the next image lands :(
[19:27] <ogra_> plars, not your fault really ... i just ahd a really busy and rather bad day
[19:35] <sergiusens> ogra_: bad way to start the week indeed
[19:41] <ogra_> sergiusens, yeah, i should rather move with the fashion and develop stones in some organ instead :)
[19:43] <sergiusens> ogra_: believe me, that brings in a crappier situation than just a bad day ;-)
[19:44] <ogra_> yep
[19:44] <ogra_> thats what i meant ... in that light a bad day still seems ok
[20:07] <elopio> ping charles: I flashed 15.04 in my krillin, image #37. And when I play music, the sound indicator doesn't show the play/pause controls.
[20:07] <elopio> is that supposed to work?
[20:08] <charles> elopio, yeah it should. Could you open a ticket for it and assign it to me?
[20:08] <elopio> charles: sure.
[20:08] <charles> elopio, are you doing anything unusual to play the music?
[20:09] <elopio> charles: no. I have one song in the music folder. I open the music player, and play it.
[20:11] <charles> ok, sounds like a straightforward use case :)
[20:13] <elopio> charles: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1395863
[20:13] <charles> elopio, thanks
[20:13] <elopio> charles: the indicator detects if a song is playing calling mpris, right?
[20:14] <charles> elopio, right
[20:14] <ahayzen> elopio, was this reenabled in vivid? as i know it was disabled/reverted in rtm ?
[20:14] <elopio> ahayzen: I don't know.
[20:14] <charles> elopio, though tbh, ted's dug in this code more recently than me; he may be able to give more educated answers than me
[20:15] <charles> elopio, which is partially the reason I wanted the bug; it's been too long since I've dug into that code
[20:15] <ahayzen> elopio, because there were multiple bugs/features missing so it was reverted for rtm
[20:15] <elopio> ahayzen: I see. Do you have a bug number for that?
[20:15] <ahayzen> elopio, for the revert? or just the issues lol
[20:16] <charles> elopio, oop, we're on freenode, s/ted/tedg/
[20:17] <elopio> ahayzen: for the revert.
[20:18] <ahayzen> elopio, i'm searching and can't find it... in bug 1378048 Pat mentions that they are hidden
[20:18] <ahayzen> elopio, i'm not sure if there was a bug for the revert in the end...i think it just happened due to the number of bugs/features missing
[20:20] <elopio> ok, thanks. That's useful info.
[20:27] <tedg> elopio, It uses MPRIS, but the media service no longer exports that.
[20:27] <tedg> elopio, You can set an environment variable to turn it on, but the implementation is incomplete.
[20:28] <elopio> tedg: what env var is that?
[20:29] <tedg> elopio, I don't remember, if you look at the media hub changelog I'm sure it's there.
[20:36] <tedg> kenvandine, So it seems there's still one test failing, but I'm not sure why. Any ideas? https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/304/?
[20:36] <tedg> kenvandine, Is it getting more than one system settings instance?
[20:38] <barry> mandel: if you're still around.  tested and verified.  commented on the mp.  thanks!
[20:42] <kenvandine> tedg, i doubt it, i'll look
[20:43] <kenvandine> tedg, i think this is an example of why we need to refactor lots of tests
[20:44] <tedg> Heh, I just want to land my little patch, I don't care about refactoring tests! :-)
[20:45] <kenvandine> tedg, does this test pass on your device?
[20:45] <kenvandine> tedg, and have you had this error consistently?
[20:45] <tedg> kenvandine, I haven't done that with teh session change, let me try.
[20:45] <kenvandine> i suspect it might be environmental
[20:45] <kenvandine> and maybe just flaky
[20:47] <kenvandine> pull: /var/crash/_usr_bin_autopilot3.32011.crash -> /var/lib/jenkins/slaves/mako-05/workspace/generic-deb-autopilot-runner-vivid-mako/clientlogs/ubuntu_system_settings/_usr_bin_autopilot3.32011.crash
[20:48] <kenvandine> tedg, whatever happened, it caused autopilot3 to crash
[20:50] <veebers> kenvandine: Hmm, just had a quick look now "return codecs.latin_1_decode(input,self.errors)[0] -> TypeError: 'NoneType' does not support the buffer interface"
[20:51] <veebers> thomi: You were working on adding something to test tools to make debugging this type of error easier, right? ^^
[20:51] <kenvandine> tedg, unity8 crashed
[20:51] <kenvandine> that was probably the root cause
[20:51] <tedg> Ah, hmm.
[20:51] <tedg> I'm pretty sure that wasn't my test's fault :-)
[20:51]  * thomi looks
[20:51] <kenvandine> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/304/artifact/clientlogs/ubuntu_system_settings/whoopsie.log
[20:52] <kenvandine> no ubuntu-system-settings crash file though
[20:52] <thomi> veebers: wait, what am I looking at? https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/304/testReport/junit/ubuntu_system_settings.tests.test_sound/SoundTestCase/test_sound_page/ seems pretty straight-forward to me?
[20:53] <kenvandine> at least for me, that kind of error i need to back my way through the rest of the artifacts
[20:53] <kenvandine> that wasn't obvious to me that unity8 crashed
[20:53] <veebers> thomi: hmm perhaps I jumped the gun. I was being nosey at the autopilot crash file kenvandine suggested (Looking at https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/304/artifact/clientlogs/ubuntu_system_settings/_usr_bin_autopilot3.32011.crash)
[20:53] <tedg> Oh, uhg. RTM and those packages are vivid.
[20:54] <kenvandine> yeah, this CI run is vivid
[20:55] <thomi> veebers: right, basically someone's tried to add None as a text content, which is obviously not correct.
[20:56] <thomi> veebers: I have an open work item to make testtools raise an error when you add the content item, but I've not had time for that
[20:56] <veebers> thomi: ah right, that's what I had in mind. sweet
[21:17] <mandel> barry, looking
[21:27] <tedg> Uhg, nothing passes on my device.
[21:31] <tedg> kenvandine, They all fail on my device :-/
[21:31] <tedg> kenvandine, Not sure what to do with that result.
[21:32] <kenvandine> tedg, pastebin please
[21:34] <tedg> kenvandine, http://paste.ubuntu.com/9220998/
[21:34] <kenvandine> python3-evdev
[21:34] <kenvandine> install that
[21:35] <tedg> K
[21:35] <kenvandine> thomi, shouldn't something have a depends on that?
[21:35] <tedg> kenvandine, Already have the newest version.
[21:35] <thomi> kenvandine: autopilot-touch should depend on it, IIRC
[21:36] <kenvandine> 21:23:36.549 WARNING testcase:538 - Failed to create Touch device for bug lp:1297595 workaround: No module named 'evdev'
[21:37] <thomi> tedg: what does 'python3 -m autopilot.run -v' show?
[21:38] <tedg> thomi, phablet@ubuntu-phablet:~$ python3 -m autopilot.run -v
[21:38] <tedg> Autopilot Source Version: 1.5.0 Autopilot Package Version:
[21:38] <tedg> 1.5.0+15.04.20141031-0ubuntu1
[21:38] <kenvandine> tedg, and you're sure your device has python3-evdev right?
[21:38] <kenvandine> not looking for python-evdev
[21:39] <kenvandine> although that shouldn't be there
[21:39] <thomi> that looks correct to me. kenvandine is suggesting what I'd check next
[21:39] <kenvandine> UInput: ImportError("No module named 'evdev'",)
[21:39] <tedg> Uhg, you're right, I didn't put a 3 there.
[21:39] <kenvandine> :-D
[21:39] <thomi> heh
[21:39]  * tedg hates python 2.7
[21:39] <tedg> When can we remove it from the archive?
[21:40] <kenvandine> tedg, really? i'm surprised you added a version
[21:40] <kenvandine> you're such a hater :)
[21:40] <thomi> I was going to say the same thing!
[21:40] <kenvandine> :-p
[21:40] <thomi> tedg: you've got a reputation now :D
[21:41]  * tedg puts the snakes on a plane with Samuel L. Jackson.
[21:46] <kenvandine> :)
[21:48] <tedg> kenvandine, Okay, so all the tests passed.
[21:48] <tedg> \o/
[21:49] <kenvandine> woot
[21:49] <tedg> Not sure what the means for Jenkins though.
[21:49] <kenvandine> kick a rebuild in jenkins please
[21:49] <tedg> k
[22:26] <SturmFlut> mzanetti, popey: I rolled out mzanetti's last commit, the app store feed has pictures now. Works at least in Thunderbird and gReader
[22:26] <mzanetti> \o/
[22:27] <SturmFlut> You may have to refresh your caches
[22:27] <popey> ooh
[22:27] <SturmFlut> depending on the application
[22:29]  * ogra_ tries in liefrea
[22:30] <ogra_> nice !!
[22:32] <SturmFlut> > grep appstorediff /var/log/apache2/access.log | wc -l
[22:32] <SturmFlut> > 771
[22:33] <mzanetti> SturmFlut: hmm... isn't that just the amount of refreshes?
[22:33] <SturmFlut> 771 requests since yesterday. So this is what internet stardom feels like
[22:33] <SturmFlut> \o/
[22:34] <mzanetti> hmm... wonder how often thunderbird refreshes
[22:34] <SturmFlut> mzanetti: I see a lot of different IPs, and surprisingly many over IPv6
[22:34] <mzanetti> that's me
[22:34] <SturmFlut> and myself ;)
[22:35]  * mzanetti has a lot of troubles atm with his IPv6 connection
[22:35] <mzanetti> although its probably that shitty modem/router
[22:35] <SturmFlut> > grep appstorediff /var/log/apache2/access.log | awk '{print $1}' | sort | uniq | wc -l
[22:35] <SturmFlut> > 107
[22:36] <SturmFlut> mzanetti: Okay, found the "culprit"
[22:36] <mzanetti> ok. now filter out IPv6 address randomization and the daily switching IPv4 addresses of the others :D
[22:37] <SturmFlut> mzanetti: Do you know a guy named "Google WebCrawler"? He seems to like Ubuntu Touch a lot
[22:37] <popey> SturmFlut: you'll see at least 3 IPs for me, home, vps and a hotel in istanbul ☻
[22:37] <mzanetti> :D
[22:38] <mzanetti> so in the end it's probably just me, popey, the google crawler and yourself causing all the traffic
[22:38] <ogra_> popey, oh, *that* turkey ... i thought you fly to the US for thanksgiving parties when you said "off to turkey" :)
[22:39] <SturmFlut> so this is what it feels like to lose internet stardom
[22:39] <mzanetti> :D
[22:39] <ogra_> lol
[22:39] <ogra_> its only two days yet, aint it ?
[22:39] <mzanetti> well, it's up since a month or two, but only "announced" since two days, yeah
[22:39] <SturmFlut> ogra_: I was expecting "Gangnam Style" levels of stardom
[22:40] <ogra_> oh, billions of hits then ... :)
[22:40]  * SturmFlut was not joking about that monster server
[22:40]  * SturmFlut never jokes
[22:40]  * mzanetti confirms
[22:42] <mzanetti> what the!!!
[22:42] <mzanetti> phablet-screenshot only creates screenshots of the greeter, even though I see the device unlocked
[22:42] <mzanetti> lol
[22:43] <mzanetti> E_TOO_MANY_DEVICES
[22:43] <mzanetti> fail of the week
[22:44] <mzanetti> SturmFlut: works in shorts too: http://i.imgur.com/315FVhL.png
[22:45] <popey> haha ogra_
[22:46] <popey> SturmFlut: not seeing images in the shorts app here. forced a refresh but still no.
[22:46] <SturmFlut> mzanetti: I wish I had more time to work on it. But this week is again filled with business trips.
[22:46] <popey> and now i do!
[22:46] <popey> yay
[22:46] <mzanetti> SturmFlut: no worries... all is fine
[22:46] <popey> http://popey.mooo.com/screenshots/device-2014-11-25-004644.png
[22:46] <popey> how cool is that
[22:47] <popey> reading the rss feed for the store, on the phone
[22:47] <mzanetti> popey: what version of shorts is that?
[22:47] <mzanetti> looks like this here: http://i.imgur.com/315FVhL.png
[22:47] <popey> secret version :D
[22:47] <mzanetti> uhh
[22:47] <popey> oh change your view
[22:48] <popey> you're in list view, change to grid view
[22:48] <popey> the only difference I have is colour
[22:48] <mzanetti> yeah, grid works too
[22:48] <mzanetti> popey: and UbuntuShape--
[22:48] <popey> ya!
[22:49] <popey> feel free to review the branch :D https://code.launchpad.net/~qqworini/ubuntu-rssreader-app/color-experiment
[22:50] <SturmFlut> mzanetti: I do get bored by all those supercomputers sometimes ;)
[22:52] <mzanetti> do you have access to them from home? like in a way you can use them as private playground?
[22:54] <SturmFlut> mzanetti: Time on production machines is scarce, so it would be unfair to steal resources from scientific users. But we do have a lot of test clusters, and I use them a lot to test various things, also from home.
[22:54] <mandel> robru, the tests in silo 15 have to be done in a later img to ensure that we can upgrade :)
[22:55] <robru> mandel: are you saying I shouldn't publish it then?
[22:55] <SturmFlut> For example I currently use a machine with 40 cores and 512 GB of RAM as my build machine
[23:00] <mzanetti> that'll do
[23:01] <SturmFlut> mzanetti: I'll visit http://www.fz-juelich.de/ias/jsc/EN/Expertise/Supercomputers/JUQUEEN/Configuration/Configuration_node.html this week. There are only seven systems in the world which are faster.
[23:03] <sarnold> "Operating system: RedHat Linux V6.2"
[23:03] <sarnold> is that really RHL or is that actually RHEL? heh
[23:04] <SturmFlut> sarnold: RHEL, sadly
[23:04]  * mzanetti would be happy with an Orange Box :)
[23:04] <sarnold> mzanetti: mmmm :)
[23:04] <sarnold> SturmFlut: at least RHEL is from this decade :)
[23:05] <SturmFlut> mzanetti: Actually the Orange Box can easily be outperformend by a single dual-socket Xeon system, and the single system is even cheaper
[23:06] <mzanetti> yeah... mostly for learning purposes... I don't really have that many production use cases for this stuff :)
[23:06] <mzanetti> my laptop seems fast enough to compile unity8, which is what I do 90% of the time anyways :)
[23:08] <SturmFlut> sarnold: Supercomputers tend to run very recent operating systems. You need support for bleeding-edge hardware and the product cycles are very short. RedHat and SuSe have to backport an incredible amount of drivers into their enterprise kernels to make sure that they still run on all the newest enterprise hardware.
[23:08]  * mzanetti would think one doesn't buy a new supercomputer every year :D
[23:08] <SturmFlut> mzanetti: ...actually, we do
[23:08] <sarnold> SturmFlut: well, those were 'interaction nodes', I wondered if they juts got something working a decade ago and stuck with it even as they had to upgrade the software for the new hardware for the compute and io nodes along the way
[23:09] <SturmFlut> mzanetti: ...actually, we didn't buy one supercomputer this year, we bought two
[23:09] <sarnold> :D
[23:10] <SturmFlut> I do feel like a crazy person sometimes when I write/say stuff like this
[23:13] <SturmFlut> sarnold: It depends. Crazy people like Fujitsu, IBM, SGI and Cray build crazy systems. They run different operating systems on the login nodes than on the compute nodes, they have dedicated IO nodes, they have strange networks etc. Averybody else just buys a huge number of nodes with the same CPUs, installs RHEL or SLES and clusters everything together.
[23:13] <SturmFlut> s/Averybody/Everybody/
[23:15] <sarnold> SturmFlut: I did wonder if that was relatively 'commodity' or not; the 40gbps 5d torus isn't much vote one way or another but the 2.5 μsec latency sounds amazing... is that something you can get with standard ethernet sff connectors or does it require something much more fun? :)
[23:20] <mandel> robru, no, I'm saying you should published, just that if you look at the number of the img used is longer on purpose :)
[23:20] <mandel> robru, is not that I did not test it in the latest due to an error from my side
[23:21] <robru> mandel: oh ok. I thought you were saying we had to wait for the next image to come out in order to test it fully.
[23:21] <robru> mandel: ok I'll publish it
[23:21] <SturmFlut> sarnold: You can get down to 1,6 µsec with 40G Ethernet, and less than one µsec with FDR (56G) InfiniBand, but when you have to adress 50.000 nodes, your network gets so big that the number of switches between two nodes starts to add a lot of latency. 2,5 µsec worst-case latency is pretty good.
[23:22] <SturmFlut> sarnold: We use InfiniBand without exception, Ethernet is just crappy technology IMO
[23:23] <mandel> robru, the other way, that you can publish without fear that I tested it in the wrong img by accident, was done on purpose
[23:23] <mandel> robru, sorry if I repeat myself, bip is misbehaving
[23:23] <robru> mandel: alright, thanks for clarifying ;-)
[23:55] <sarnold> SturmFlut: do you do IP over IB? or do you use something else?