=== chihchun is now known as chihchun_afk === kgunn is now known as Guest2511 === _salem is now known as salem_ === vying is now known as Guest58730 === chihchun_afk is now known as chihchun === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === salem_ is now known as _salem [04:36] morning [05:44] where can i find all the touch apps instead of categories? [05:56] good morning [05:56] I could need help with a build issue. I can compile telephony-service natively in mako with dpkg-buildpackage (it takes quite a while though). [05:56] But when trying to build it on my host PC (running Trusty) with sbuild, I get [05:56] The following packages have unmet dependencies: [05:56] qtdeclarative5-ubuntu-ui-toolkit-plugin:armhf : Depends: suru-icon-theme:armhf but it is not installable [05:56] which does not seem to make much sense (suru-icon-theme is platform-independent). Am I missing some PPA or such? [05:57] full build log in http://paste.ubuntu.com/7778754/ === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:39] Saviq: is piiramar's issue something you've seen in your cross-builds? it's not about transitional packages, but anyway about arch:all/any [07:40] Mirv, probably suru-icon-theme missing a M-A header [07:41] Mirv, yeah, it's missing Multi-Arch: foreign [07:42] Saviq: an all package would need that? [07:42] Mirv, I didn't think so, but looks like it [07:42] Mirv, https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages [07:43] gonna punt to xnox on #ubuntu-devel [07:43] Saviq: Mirv: makes sense, thanks [07:44] Saviq: wow, indeed, regardless of whether they're any or all. thanks! [07:44] piiramar, you can build ubuntu-themes with Multi-Arch: foreign locally and "inject" it into the sbuild from a local repo [07:44] yippee https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages [07:45] https://wiki.ubuntu.com/SimpleSbuild#Local_packages [07:45] wonder if allowed is better or foreign [07:46] allowed probably [08:01] pitti, where should I file bugs against dbusmock? [08:01] jgdx: ubuntu-bug python3-dbusmock will do [08:02] pitti, thanks [08:36] Good morning all; happy Friday and happy World Population Day! :-D === chriadam is now known as chriadam|away [08:46] piiramar, Mirv, https://code.launchpad.net/~saviq/ubuntu-themes/fix-multiarch/+merge/226418 [10:25] piiramar, with the suru theme in ppa:ci-train-ppa-service/landing-020 and with a change to telephony-service: lp:~saviq/telephony-service/fix-cross I could cross-build it now [10:26] hmm with the exception that it still tries to run tests [10:28] Saviq: thanks, I'll try that. the "inject local repo to sbuild" instructions above looked a bit scary. [10:30] piiramar, fortunately only a single-time setup step [10:40] seb128, hey, did you get to look at https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/1297418-apply-new-designs-to-background-panel/+merge/223571 once more? [10:41] jgdx, no, sorry I have been distracted by other things, it's next in my list, going to get to it in an hour or so [10:54] seb128, thanks! === chihchun is now known as chihchun_afk === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [11:44] hi,anyone has ported ubuntu-touch to samsung i9100g? === alan_g is now known as alan_g|lunch [12:21] Saviq: works fine, thanks for the quick fix [12:22] piiramar, cheers, here's the fixes for telephony-service https://code.launchpad.net/~saviq/telephony-service/fix-cross/+merge/226437 [12:22] !devices | zhs [12:22] zhs: You can find the full list of devices, official images, community images, and works in progress at https://wiki.ubuntu.com/Touch/Devices [12:23] zhsj, i think there is a very old and outdated port to that device === _salem is now known as salem_ [12:32] i find someone successfully port ubuntu-touch to i9100. So i tried to port my i9100g [12:33] that truly an old phone. but only that phone i have that allow me to do some test. === psivaa is now known as psivaa-lunch [12:46] hey guys, I'm getting what seems to be a Unity crash (jumps back into showing the rotating Ubuntu icon then loads up Unity again) whenever I try to access the 7digital scope on r125. How can I debug it and where should I report the crash on Launchpad? [12:50] hey guys who wrote the 7digital scope? In search I type Michael Jackson, I click on artists and I get a blank page. [12:50] davmor2: it just crashes for me when I open it [12:50] r125, utopic-proposed [12:51] JoshStrobl: it isn't crashing if you see the the spinning logo that is lightdm probably but why it would crash accessing a scope is beyond me [12:52] davmor2: it isn't the spinning app loading logo, it is the actual ubuntu logo you see when the phone is booting up and Unity is loading. [12:53] JoshStrobl: Yes which would be the phone rebooting effectively which would most likely be lightdm crashing abd restarting [12:53] and even [12:53] only happens when I launch the 7digital scope, no other scope does that. [12:54] scope works fine here for me so I'm not sure why you are seeing that [12:54] "works fine for me" right..therefore a bug totally must not exist /s [12:55] JoshStrobl: I'm not saying that, I'm saying I'm not sure why you are seeing that because it works fine here [12:57] JoshStrobl: It might be that you have an app installed that I don't and the two clash, it could be that your phone didn't flash cleanly, it could be ..... I can neither confirm or deny any of those though as I can't reproduce it [13:06] cjwatson: mvo_ : hi! Do you guys have any update on how should the click scope pass the store signatures to packagekit/pkcon? [13:10] MacSlow, could you attach /var/log/syslog (or /var/log/syslog.1) for bug 1340710? I'd like to see when it started, and messages on boot before it started [13:10] bug 1340710 in urfkill (Ubuntu) "/var/log/kern.log gets spammed with rfkill messages" [Medium,Incomplete] https://launchpad.net/bugs/1340710 [13:11] cyphermox_, okidoki === alan_g|lunch is now known as alan_g [13:15] cyphermox_, hm... syslog.1 bzip'ed is around 26 KBytes.. but syslog bzip'ed is still 5 MBytes (135 MBytes extracted) [13:15] that's fine, it just means it didn't rotate [13:15] cyphermox_, I'm not sure if lp will allow me such a big attachment [13:15] just send me syslog then; you can send by email if it's too big for lp.. or put it somewhere I can retrieve it [13:19] cyphermox_, attachments worked [13:21] alecu: sorry, haven't had time to look yet, will try to early next week [13:21] alecu, cjwatson: I'm happy to tackle it seems like we can either pass pairs of (click, signature) to the pk plugin or simply assume that each foo.click has a foo.signature file that can be used for the verificaiton [13:22] cjwatson, alecu: but of course I'm happy to wait for further input on this [13:25] mvo_: the plan had been to embed the signature in the click package itself [13:25] is that not workable for some reason? [13:25] mvo_: passing pairs sounds like the easiest solution of those two from the click scope pov (since the click scope will use some folder for download of the signature, and the download manager will probably download the .click in a different one) [13:26] mvo_: sorry, as I say I haven't had a chance to read up on this properly, but would like to before we do anything irreversible ... [13:26] cjwatson: afaiui, the signature that will be verified on the device is the store one, not the developers' [13:26] and I guess we don't want to have the store modify the package? [13:26] cjwatson: and the store does not want to modify the .click file [13:26] right [13:26] cjwatson: I have my info from https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning [13:26] I guess that's sort of justifiable [13:26] but sorry, I'll try to read through this properly on Monday [13:27] sure [13:27] cjwatson: no problem. I'm being annoying because I want to be sure that we'll be able to do all of this before RTM :-) [13:27] I will look at how to implement it but won't start before we discuss this further :) [13:28] mvo_,alecu: one thing I'm wondering is whether we could have the store concatenate the signature to the end of the .click file in transit (not unpack/repack or anything like that) [13:28] I *think* that the debsigs format would permit something like that but as I say I need to check [13:28] and that would save having to pass a pair of files around which I think will be cumbersome [13:28] indeed [13:29] cjwatson, alecu: I guess we can clarify with mdeslaur in the meantime if that option was considered (just appending the signature) [13:29] it should generally be possible to simply concatenate another ar element to the end; the thing I need to check is what happens in the event that there was already a signature there [13:30] but yeah, sorry, this sort of thing is why I haven't said go ahead yet :) [13:33] as far as I can see from debsigs.txt, the debsigs format is one ar element per signature [13:33] the developer could add a maintainer signature, we could add an origin or archive signature or whatever [13:33] and all of that *looks* like it's strictly concatenative [13:33] yeah, I was just reading the same file [13:36] yep, confirmed, debsigs --sign= just appends an ar element [13:36] alecu: can you find out if the store could store detached signatures and append them in transit, please? [13:36] given that I've checked that that's how the file format works [13:37] it looks like that's a relatively minor modification to https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning [13:37] but it would simplify things substantially at the packagekit plugin end [13:37] and it would let us use pre-existing tools to do the verification === Ursinha is now known as Ursinha-afk [14:02] cjwatson: mvo_ : sorry, was on a meeting. I'll talk to the store guys to find about concatenanting the files, thanks for checking. [14:02] thanks [14:02] alecu: failing that, maybe the scope could concatenate them before feeding them to pkcon? === Ursinha-afk is now known as Ursinha [14:04] cjwatson: that sounds doable too. === psivaa-lunch is now known as psivaa [14:14] karni, can you show it to cjwatson or mvo_ ? [14:14] sure [14:15] cjwatson: mvo_: hey guys. so I did a dist-upgrade today on my utopic PC here, and that's what I got: [14:15] http://paste.ubuntu.com/7780376/ [14:15] http://paste.ubuntu.com/7780381/ [14:15] * tedg 's webapp got rejected, is suing! [14:15] cjwatson: I've brought pindonga and james_w` from the store, to discuss appending the signature to the clicks. [14:16] * ogra_ didnt know you can buy pindonga and james_w` in stores :) [14:16] karni: bug 1334611 [14:16] bug 1334611 in click (Ubuntu) "Can't update click if we have previously installed packages for users that were later deleted" [High,In progress] https://launchpad.net/bugs/1334611 [14:16] :-) [14:16] what did you pay for the bundle ? [14:16] :) [14:16] special offer, buy a pindonga and get a free james_w [14:16] karni: cjwatson is always faster than me :) what he said [14:17] ogra_, :) [14:17] * karni looks [14:17] I should re-review that branch [14:17] cjwatson, there are several issues we need to consider for appending signatures to click files [14:17] cjwatson, 1) we don't really want to modify the click files [14:17] karni: you can try the attached branch if you want [14:18] cjwatson, 2) we need to make it very clear what the sha of the click file refers to (alecu said you considered this and said it should be the sha of the combined data) [14:18] pindonga: it's append-only, you can just cat the signature on the end [14:18] which makes things slightly more difficult, bc we need to compute the sha after appending the files [14:18] and right now it's being computed on upload of the click file [14:18] so as I say I guess I'm fine with the scope doing this having thought of that idea [14:18] I just don't want the scope to be passing two files through to pkcon [14:18] pindonga: yes, because the sha-512 is verified by the download manager, who will be getting the combined files [14:19] as long as the signature in the store is a debsigs-format ar element, not some other thing [14:19] cjwatson: what is the debsigs format? [14:19] so that it can be concatenated and then passed to debsig-verify [14:19] currently it is specified and implemented as a detached gpg sig [14:19] bzzzzt [14:19] please don't do that [14:20] it's done *with* gpg, but it's a format that's designed to allow embedding the sig into the package [14:20] which means we can use debsig-verify to handle the verification for us, with flexible policies and stuff [14:20] cjwatson, what do you mean? when I asked mdeslaur about this, we agreed the signature was plain gpg detached sig [14:20] I need that to be revisited [14:21] but it's done with gpg under the hood, so it shouldn't be hard [14:21] I posted about this months ago to -appstore-developers [14:21] cjwatson, yep, I read that thread, but it seems no agreement was reached :/ [14:21] that's not true [14:21] cjwatson, I won't discuss the security aspect of this... [14:21] whatever you and mdeslaur agree upon I can implement [14:21] we agreed that this was a reasonable format to use, but nobody had time to implement it at the time and we decided to use transport security for the time being [14:22] cjwatson: so we can pop off the signature and recover the original package with hash? [14:22] I just would like we have an agreement and stick to it [14:22] mvo_: can I patch the /lib/click/user.vala on the system (can't find this), or do I need to rebuild click? [14:22] the signature format should be easy for us to change [14:22] karni: you need to rebuild click, sorry. vala is compiled [14:22] mdeslaur: the signature is literally an extra ar element at the end; debsigs --sign= preserves the original package intact as a prefix of the output file [14:23] mvo_: ah.. in that case, I need to get back to my stuff. sorry I can't test it now :( [14:23] karni: just remove the bogus registrations from your click database - you don't need to recompile click [14:23] karni: you probably have something under /opt/click.ubuntu.com/.click/users/phablet/ which shouldn't exist if you don't have a phablet user [14:23] cjwatson: I know little how I would go about doing it [14:23] karni: no problem, as a workaround you could just re-add the user that you deleted for now (assuming that is what happend) [14:23] * karni looks [14:23] so remove that directory [14:24] mdeslaur: --sign can be anything and we can write policies based on that; I think we can just do debsigs --sign=store [14:25] actually, there's supposed to be an origin signature [14:25] so --sign=origin would be correct [14:25] that appends a _gpgorigin ar element to the end of the package [14:25] cjwatson: when we were talking about not modifying the package the developer uploaded, one of the reasons was to demonstrate that it was the very same file they uploaded [14:25] save that off, have the scope stick it back on after download? [14:26] cjwatson: if we are able to do that even if we append a signature, then I'm ok with adding a second one [14:26] cjwatson: mvo_: indeed, purged click'ed scopes from /opt/click.ubuntu.com/ and /opt/click.ubuntu.com/.click/users/ and it works, thanks guys [14:27] I put stuff there when testing, and indeed that affected click [14:27] * alecu likes having to avoid the scope downloading and verifying the hash of a second file, if it can all be part of the first. [14:27] karni: only the .click/users/ bit was necessary, but yeah [14:27] :) [14:27] mdeslaur: yeah, definitely - you can try it, cp foo.click foo.click.signed && debsigs --sign=origin --default-key=KEYID foo.click.signed and then confirm that foo.click is a prefix of foo.click.signed [14:28] unfortunately debsigs doesn't have a detached mode, but that would be easy enough to do if we decided we wanted that [14:28] cjwatson: you can append an arbitrary number of signatures? [14:28] I would definitely prefer to have a single file also [14:29] mdeslaur: yes [14:29] you get _gpgfoo _gpgbar etc. elements [14:30] so I expect maybe _gpgmaintainer _gpgorigin [14:30] (again, sorry I didn't get to reviewing this design before, been rather swamped ...) [14:30] I don't think this is too big a modification though [14:30] cjwatson, so we're aiming at using debsigs --sign instead of plain gpg for this? [14:31] right, if possible? [14:33] ok, let me reread the thread one sec, and I'll modify the wiki page [14:33] we then use a policy file along the lines of https://lists.launchpad.net/ubuntu-appstore-developers/msg00394.html, obviously with the store key [14:34] then customers can modify that to add extra policies, if say they only want to accept packages they've also signed [14:34] we want to avoid signing packages with the store key until they are published right? [14:34] sounds right [14:35] well, we need to sign them before we publish them (but just right before) [14:35] such customers can then do debsigs --sign=customername on top, and tweak their policy to require that sig [14:35] I think it's reasonable to assume that signing doesn't invalidate previous testing though [14:35] or various things like that [14:35] given that it's an append [14:35] right [14:36] pindonga: I think this can work ok, the signing step just changes to use debsigs and return the modified file [14:36] pindonga: sca then replaces the file in click-updown and re-computes the sha256 [14:37] james_w`: it's 512, right? [14:37] 512, yeah [14:37] great [14:37] pindonga: does htat sound right? === alan_g is now known as alan_g|tea [14:38] the sha512 would be invalid for a short while [14:39] annoyingly, debsigs --delete=origin doesn't recover the original file perfectly due to slight changes in the ar format; should possibly fix that [14:39] but that's just a bug in --delete [14:40] cjwatson, pindonga, james_w`, alecu: ok, I'm fine with debsigs, I'll modify the wiki. [14:40] great, thank you [14:40] cjwatson: yeah, that would be nice, but not a critical issue for now [14:40] cjwatson: thanks! [14:41] cjwatson: mvo_: mdeslaur: pindonga: james_w`: thanks for figuring this all out. [14:41] (the difference is 0x20 => 0x2f in four different header bytes) [14:42] yeah, good that its sorted [14:42] mvo_: so we'll then need to put a policy in place corresponding to the store's key - I wonder what package that belongs in [14:43] we should possibly also look at a small patch to debsigs to support delivering extra policies under /custom, if mdeslaur is OK with that [14:43] cjwatson: I was thinking we could have a new click-verify or somesuch [14:43] jhodapp, ping [14:43] mvo_: well, the thing I'm thinking of is that the policy is specific to the Ubuntu click store, and I don't know that I necessarily want click itself to hardcode that [14:43] maybe it would be OK [14:44] but I sort of want people to be able to reuse click elsewhere [14:44] maybe a new click-ubuntu-policy package? [14:44] cjwatson: right, I mean a extra source package, but the name is probably not ideal, so more like ubuntu-click-store-verify (or similar) maybe? [14:44] james_w`, cjwatson mdeslaur ok, let me double check all things to avoid confusion [14:44] it could be in the click source package well enough, just as long as it's possible to install click without it [14:45] 1. we sign the click pkg with debsigs --sign=xxx [14:45] pindonga: --sign=origin [14:45] cjwatson: re: /custom: possibly, we need to think about it a but first...we don't want users to be tricked into installing alternate stores, etc. [14:45] 2. we re-upload the signed pkg to click-updown [14:45] mdeslaur: yeah, click packages can't put stuff in /custom of course [14:45] cjwatson: ok, I see no downside in puting it into a extra source (except the slightly higher overhead) [14:45] 3. we have no longer a need for separate signature file [14:45] mvo_: I guess that's akin to apt vs. ubuntu-keyring [14:45] yes [14:45] cjwatson, origin is not supposed to be the developer's signature? [14:46] or is that maintainer? === alan_g|tea is now known as alan_g [14:47] pindonga: the debsigs docs say that every signed file must have an origin signature, and other types may be defined by policy; the (dated) example they provide is "For instance, Debian, Helix, and Progeny would each provide an origin signature" [14:47] cjwatson, but we plan on asking devs to sign their packages [14:48] so what will we use for that? [14:48] Right, so they'll use "maintainer" [14:48] Or if you prefer a slightly different name, at your discretion [14:48] so signtype can be any string? [14:48] Anything between 1 and 10 characters [14:49] (inclusive) [14:49] cjwatson, I wish we had talked earlier [14:49] sorry :/ [14:49] cjwatson, not anybody's fault [14:49] cjwatson, at least it's before RTM :) [14:50] the policy is looked up according to the origin signature, and may apply additional checks [14:50] I think the term "origin" comes from its use in apt archives, where it basically means the archive you're fetching from [14:50] slightly odd terminology but there you go [14:51] so 'origin' and 'maint'? [14:51] fine by me [14:54] cjwatson, pindonga: ok, wiki updated [14:55] mdeslaur, thx [14:55] cjwatson, can you go over it once more please and confirm we're happy with it? [14:55] I'll change things based on that later [14:56] pindonga: 'maint' is verified only by the store, right, not reverified on the device? [14:56] I guess it must be that way since we won't have developer keys on the device [14:56] correct [14:56] right, 'maint' is only by the store on upload [14:56] right now it's not verified at all :) [14:56] but eventually we'll verify it on upload [14:57] and once verification passes, we'll sign the pkg with the store's key [14:57] pindonga,mdeslaur: this looks great now, thanks [14:57] thanks cjwatson [14:58] cjwatson: so you'll add the debsig-verify step to packagekit? [14:58] mdeslaur: either mvo or I will, yes [14:58] great, thanks [14:59] mdeslaur, cjwatson: I can work on this really soon, it will be added to click install directly (or is there a reason against this?) [15:00] mvo_: needs to be in whatever runs as the different user...pkcon? [15:00] * mdeslaur can't remember [15:00] which different user? [15:00] clickpkg? [15:01] cjwatson: well, either root or clickpkg, but not the regular unprivileged user [15:01] mvo_: the only reason I can think against you landing that really soon is "the store not signing the packages yet" [15:01] right, click's packagekit plugin runs as root and calls click install as root; click install drops privileges to clickpkg at some point [15:01] right, my current plan was to make it part of click.install.ClickInstaller:audit() [15:02] that sounds about right [15:02] cjwatson: oh, ok, great...I wasn't sure which components ran where, thanks [15:02] alecu: heh :) fair point, I guess I mean "make it ready", I certainly do not want to break the store [15:02] mdeslaur: I've taken a look at the wiki, looks fine from the scope/download manager pov. [15:02] yeah, we'll need to take care about the transition but it should be workable [15:03] we can slot it in in a form that allows unsigned packages for the moment, I think [15:03] pindonga: do we have a public key already that I can use in the new ubuntu-click-store-policy [15:03] then verify anything that comes with the origin signature [15:03] mvo_, I don't know [15:03] then require the origin signature [15:03] cjwatson, mdeslaur ^ ? [15:04] uh, hmm [15:04] cjwatson: hrm, keys... :) [15:04] it should really be in our secure chain of trust [15:04] but that's going to require travel [15:04] bugger [15:04] we're gonna need some more USB sticks [15:05] I think we have to treat this the way we treat the archive key, with a secure sharded master and the ability to rollover [15:05] agreed? [15:05] yes [15:05] yes [15:06] so ... could somebody figure out a collection of shardholders? I'm a holder on several things already, but I can make a trip to London for this if needed [15:06] We could do it at the cloud sprint in early August, but that's probably too late [15:16] Wellark: so if I wanted to try hotspot, is the code already landed in the archive, or do I use a PPA or whatever? [15:18] cjwatson, jdstrand is there a mechanism to trigger a "cleanup" when an app is uninstalled [15:19] cjwatson: fwiw, I think I fixed the debsigs --delete= foo bug, they are the same for me now [15:19] pmcgowan: cleanup of what exactly? [15:20] cjwatson, the current example is I make some events with the calendar, then uninstall calendar, I now have no UI for the event management [15:20] so I'd like to offer to remove them all [15:20] pmcgowan: so I don't know the specifics here but in general it's the job of hooks to catch up after that kind of thing [15:20] https://click.readthedocs.org/en/latest/hooks.html [15:20] cyphermox_: it's better to grab the configuration file from the bug report and drop it under /etc/NetworkManager/system-connections [15:21] though there is no mechanism for that to be interactive [15:21] and then activate with nmcli [15:21] well, I suppose a hook could drop a note somewhere that something that's running in your session could pick up === gnu is now known as Guest51956 [15:21] cjwatson, I see [15:22] cyphermox_: there is UI code in the system settings also, but you would need to run system settings with USS_SHOW_ALL_UI=1 [15:23] cjwatson, what is in the way of it supporting UI? [15:27] pmcgowan: hooks don't always run in UI context [15:27] pmcgowan: so the approach I outlined is better - have the hook command in question leave a note somewhere that UI needs to be presented [15:28] that's also IMO more robust than supporting UI directly [15:28] cjwatson, so like the app scope would see that and afterword prompt the user to cleanup? [15:28] right, something like that, as I say I don't know the details here [15:28] yeah ok [15:29] somthing needs to be worked out === chihchun_afk is now known as chihchun [15:29] quit [15:29] will look for other examples, maybe not that much [15:29] I assume that there's some system package which is responsible for events [15:29] there is a service, and the indicators to some extent [15:30] So whatever that is would need to declare a hook which click packages such as calendar could attach to [15:30] Probably the service [15:30] And then it can ask something (maybe even the indicator?) to present a warning if the number of attached packages drops to zero [15:30] Something like that [15:30] yeah I see === chihchun is now known as chihchun_afk [15:50] can I run autopilot3 with phablet-test-run? [16:04] alex-abreu, Is there a way to disable the browser location dialog in a webapp? Seems like browser shouldn't be doing the prompting there. [16:05] tedg, why shouldn't it do the prompting in the webapp? [16:05] alex-abreu, Because the prompt would come from location service. It's not a webpage asking for permission, it's the whole app. [16:06] alex-abreu, The browser needs it to add fine-grained support beyond what location service knows, webapps don't. [16:08] tedg, mmh ... yeah possibly, could you file a bug? [16:08] alex-abreu, On which project? [16:09] tedg, lp:webbrowser-app w/ [webapp-container] in the title [16:12] alex-abreu, bug 1340822 [16:12] bug 1340822 in webbrowser-app "[webapp-container] Webapps should be able to disable the location permission dialog" [Undecided,New] https://launchpad.net/bugs/1340822 [16:12] tedg, thx [16:45] popey: my content-hub branch that ahazen needed for music-app has landed, it'll be in the next image [16:45] nice one, thanks [16:46] i'll look forward to importing music in music-app :) [16:48] ahayzen! my content-hub branch landed, should be in the next image [16:48] kenvandine, awesome work thanks :) [16:48] np [16:48] kenvandine, i'll try and work on our end over the weekend then all we'll need is support for reloading the models or something [16:50] ahayzen: ping if you need testing [16:50] popey, will do thanks :) === alan_g is now known as alan_g|EOW === ev_ is now known as ev === JoseeAntonioR is now known as jose === renato is now known as Guest85133 === ken_ is now known as kenvandine === Corey_ is now known as Corey === Guest85133 is now known as renato___ [18:16] fginther, ping [18:18] ahayzen, pong [18:19] fginther, i think there is a 'dead' job on jenkins ? http://91.189.93.70:8080/ [18:19] fginther, its been running for 6hrs (generic-land) [18:19] ahayzen, yep, let me see if I can put a stop to that [18:19] fginther, thanks [18:22] ahayzen, thanks for the notice. I added a job timeout to avoid this in the future (we'll see if it works as expected) [18:22] fginther, awesome thanks :) [19:21] barry: hey, out of spite; did my email come out of a bug report or did you reply to it? :-) [19:22] sergiusens: not sure i understand the question ;) i saw your comment in the bug report, and then followed up via the web [19:23] barry: I see what happened here [19:23] barry: I have saved your email as "Barry Warsaw <1335568@bugs.launchpad.net>" :-P [19:23] ah :) [19:24] barry: anyways, pmcgowan will want to make use of that; I forwarded your reply :-) [19:24] thanks [19:24] elopio, so you guys could use an auto importer for testing too right, like something that responds to shared contacts, etc? [19:24] sergiusens: sure thing! [19:25] i'm adding valid files to the test peer, debating if i should make the same peer handle export, import and share [19:25] or make 3 different ones [19:26] elopio, i'm leaning towards separate peers, then we could potentially have the test peers exchange content with each other [19:27] kenvandine: we will need that at some point, yes. I haven't seen the import case yet though. [19:27] making the peers exchange content would be nice. We could test them instead of the examples. [19:27] yeah [19:27] or actually, the tests for the examples should be done talking to the test peers. [19:28] right [19:28] and the test peers could be run to ask other test peers for content [19:28] but they need to be different so they can be started independent of each other with ubuntu-app-launch [19:28] via the hub [19:29] content-hub-test-importer --pictures content-hub-test-exporter [19:29] could ask for pictures from content-hub-test-exporter [19:29] would would automatically charge and exit [19:30] and content-hub-test-importer could return success/fail [19:31] this could even be very useful for development [19:33] barry, sergiusens awesome! [19:35] pmcgowan, sergiusens i am going to try to land system-image 2.3 next week [19:35] barry, very good [19:35] Is there a way to get adb shell to not put stderr into stdout ? [19:42] Solved that, but still not able to get wireshark to adequately grab packets :-( [19:42] This is what I have: wireshark -k -i <(adb shell dumpcap -P -w - "2>" /dev/null) [21:11] just upgraded my ubuntu. went to sounds and ringtons are not working but works if someone calls the phone. ringtone rings only once thought. [21:48] anyone asked kernel team to upload hammerhead kernel? [21:53] rpadovani: is there a bacon2d package somewhere I can install on Trusty? [21:53] mhall119, nope, you have to clone it from github, but it's a very fast process... kenvandine will package it for utopic in next weeks [21:54] rpadovani: clone the binary, or the source and then build it? [21:55] mhall119, the source: paste.ubuntu.com/7782221/ [21:57] thanks rpadovani [21:57] yw :-) [22:00] rpadovani: file:///home/mhall/projects/100balls/js/setup.js:9: TypeError: Property 'pushScene' of object Game(0x8f56b40) is not a function [22:00] oh, this is a good start :D let me see === salem_ is now known as _salem [22:06] mhall119, sorry, works for me and pushScene() it's a function of Game... The only thing, I see that I wrote qmake in instructions for installation. Actually, that does an error, the right command is 'qmake ..' [22:06] rpadovani: nvm, I updated the repo and re-built it, work snow [22:06] cool :-) [22:06] rpadovani: I was building from an old git clone of Bacon2D from when I was playing pathwind [22:07] 100balls is hard, you wouldn't think "drop balls into a cup" would be so difficult, or addictive, but it is :) [22:07] yeah, totally :-) I have it on Android, so why don't try to do a port? :-) [22:08]