=== luist_ is now known as luist === mnepton is now known as mneptok === LordOfTime is now known as LordOfTime|EC2 === TheMuso` is now known as TheMuso === iulian is now known as Guest48666 === _salem is now known as salem_ [02:29] jamesh :O [02:29] hmm? [02:30] I had a question, and I was referred to you to ask about it, you got a minute? [02:30] sure [02:31] Okay ^_^ [02:31] I am working on a simple script for IRC client hexchat which keeps track of unread message count in the unity launcher count [02:32] simple script: http://pastebin.com/GigD0P4t [02:32] My issue is that it works completely fine the first time, but I am unable to unload and reload the script; a reload causes an error, and just breaks [02:32] I have to restart hexchat commpletely to reload the script [02:32] do you know of anything that I need to/can reset that would allow me to reload the script without killing the hexchat? [02:33] what is the error? [02:34] upon unloading and reloading the script, I get this error: http://pastebin.com/raw.php?i=dzSafTK4 [02:35] If I were to guess, it would have something to do with hexchat's unnity launcher icon having already been hooked once or something, and it crashes if you try to do it a second time [02:35] not sure though [02:35] that is a bit weird. [02:36] Additional, when I unload the script the last unity count number remains on the icon [02:36] I don't have much experience with xchat/hexchat's Python support, but when you say you are reloading it, does that mean the entire Python runtime, or just the script [02:36] ? [02:36] just the script I think [02:37] it seems a bit surprising that those modules would be initialised a second time then [02:40] i.e. after the first time you import gi.repository.Unity, future imports should just pick the module object from sys.modules['gi.repository.Unity'] [02:42] hm [02:42] brb a second [02:51] also, it isn't obvious how your script would know when it is being unloaded, which might indicate why the read count doesn't change then. [02:52] hm. [02:53] * adie huggles [02:57] yeah jamesh, I guess I misunderstood what the issue was [02:57] I thought it was an issue with the unity launcher API, but apparently I cant "from gi.repository import Unity, Gio, GObject, Dbusmenu" twice for whatever reason [02:58] strippingn it down to just importinng those modules prevents it fromm loading a second time [03:00] so I guess I was wastinng your time :< sorry [03:05] adie: it certainly sounds like hexchat is doing something weird when you try to reload your script then. === Kk2 is now known as kk2 === salem_ is now known as _salem === udienz__ is now known as udienz [04:45] infinity: my recipe? I'm using mk-sbuild + apt-cacher-ng + some symlinks to /tmp in /var/lib/schroot (I have /tmp on tmpfs), nothing that fancy [04:45] infinity: but downloading sbuild schroots does sound like a nice idea [04:45] pitti: Oh, it wasn't you who was using distro chroots, then. Hrm. I wonder who that was. === halfie|zzz is now known as halfie [04:48] infinity: security team has distro schroots... [04:48] sarnold: Backed by the LP tarballs, I mean. [04:49] infinity: is that tarballs of the distros pre-installed? [04:49] sarnold: No, the tarballs used by LP buildds. [04:49] sarnold: eg: https://api.launchpad.net/1.0/ubuntu/raring/amd64 [05:43] c [06:01] * ScottK looks at lamont` and wonders what happened to the weekend. [06:11] stgraber: xnox: ogra_: slangasek: seems there's sort of a regression with the latest upstart [06:12] ofonod was started fine with mako before, and upstart-file-bridge is also running just fine [06:12] after update, ofonod is never started (it works fine with maguro though, might be a race somehow), and upstart-file-bridge starts but dies later on [06:17] from logs: upstart-file-bridge:string.c:396: Assertion failed in nih_str_split: str != NULL === geser_ is now known as geser [06:42] good morning === Guest48666 is now known as iulian === elmo__ is now known as elmo [08:20] rsalveti: is it reproducible with a grouper device? [08:20] pitti, hey, could you put https://code.launchpad.net/~peter.ahlgren/ubuntu/raring/obconf/fix-for-1179969/+merge/170065 as work in progress/needs work/rejected? [08:21] rsalveti: as a work around it should be possible to change upstart job (with an override file) to run upstart-file-bridge in foreground (remove expect stanzas & --daemon) [08:26] seb128: sounds like "rejected", done [08:26] pitti, danke [08:26] rsalveti, bah [08:27] * Laney just got a crash report for u-f-b in dist-upgrade ;-) [08:27] Yeah, lots of us did, there are a few dupe bugs for that already. [08:27] yep, just checked [08:28] So probably not touch specific. [08:29] xnox: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1197214 [08:29] Launchpad bug 1197214 in upstart (Ubuntu) "upstart-file-bridge crashed with SIGABRT in raise()" [Undecided,Confirmed] [08:30] infinity: just fixed it [08:30] jodh: That was quick. Thanks. [08:30] infinity: well, it's fixed upstream so next upload will include it. [08:31] is that worth an upload to backport it? [08:32] jodh: infinity: i have a workaround. On my system i was running upstart-file-bridge in foreground, switching to daemon triggered the bug. [08:32] I suspect it's worth someone pushing an upload soon, yeah. [08:32] seb128: infinity: I'll make one, after checking jodh's fix. I did TIL. [08:32] xnox: Thanks. [08:32] xnox, thanks [08:32] xnox: https://code.launchpad.net/~jamesodhunt/upstart/bug-1197225/+merge/172762 [08:41] * xnox runs all of my bridges in foreground [08:42] xnox, just backport that fix and install the update :p [08:42] seb128: yeah, merged upstream, tested properly, now running full test-suite.... uploading soon. === yofel_ is now known as yofel [08:48] seb128: infinity: uploaded. Last night the delay between upload and migration to release was... 5 hours. I blame latency in reverse-testing of the $world via autopkgtests. [08:48] xnox, thanks [08:49] (as it only takes 30minutes to build upstart on armhf) [08:49] It's not hugely urgent, just an annoying apport dialog. But I could force it to skip rdep tests. [09:09] Laney, stgraber, jodh: do you have an opinion on https://code.launchpad.net/~ted/gnome-session/upstart-unity/+merge/172664 ? [09:10] not really; does it work? [09:11] Laney, I didn't try yet, it was on my inbox this morning [09:11] I didn't follow up the details on what processes are upstart started nowadays [09:13] and the gnome-session-foo commands continue to work? [09:13] In principle it seems ok to me [09:13] I think the user session jobs were otherwise jiggled to make this work [09:13] let me play with it here, I was mostly listing it for comments or in case you guys knew about any gotcha there [09:13] unity's one will need patching too but I guess there will eb an MP for that [09:14] no, lies, it will not [09:17] grr, not getting applications returned in the home lens [09:20] xnox: No, it wasn't genuine latency, it was false latency due to a known bug with virtual package handling [09:20] xnox: I noticed at some point and forced it [09:20] Laney, bug mhr3 about it on #ubuntu-unity please [09:20] xnox: The actual autopkgtest only took a few minutes [09:20] xnox: jibel is working on the underlying bug [09:20] Laney, he will likely want a bustle log [09:20] cjwatson: interesting. thanks. [09:20] second [09:22] oh wow, my PC hard locked [09:23] xnox, I'm testing a fix that will land today. [09:38] pitti: sorry yesterday I forgot to ask you to approve nvidia-settings-319-updates (saucy, NEW, main) which goes together with the package you approved === fabo is now known as fabo_away [10:03] xnox/doko: any thoughts on https://code.launchpad.net/~jamesodhunt/upstart/fix-libupstart/+merge/172371 ? Possibly a gettext issue? [10:06] tseliot: oh, we need an -updates for the settings as well? looking [10:06] yep [10:07] tseliot: why does nvidia-settings-319 and -updates have a different orig.tar.gz? [10:07] pitti: well, it's the same code for now but it will change [10:08] yes, I mean nvidia-settings-319_319.32.orig.tar.gz and nvidia-settings-319-updates_319.32.orig.tar.gz differ (gz timestamp or so) [10:08] looks ok otherwise [10:09] didrocks, any idea when i can expect a build of https://code.launchpad.net/~phablet-team/phablet-tools/trunk ? seems the merge went in 4h ago [10:09] pitti: they are different tarballs yes. I didn't rename one adding -updates to it. I created the tarball again [10:09] ogra_: should be in tomorrow's dailies, any urgency? [10:10] tseliot: hm, nvidia-settings-{304,319} are in main, -310 is in universe; is that really free software? [10:10] didrocks, it is the one thing blocking us from switching to flipped by default (which was due on monday) [10:10] tseliot: I had assumed it was for restricted or multiverse [10:10] ogra_: ok, let me rerun a daily with this one then [10:10] * ogra_ hugs didrocks [10:10] thanks ! [10:10] pitti: -310 should be a transitional package which we still want in restricted [10:11] * didrocks hugs ogra_ back [10:11] jodh: Look into why libintl isn't being built with -fPIC, I guess [10:11] compiled, that is [10:11] tseliot: oh, seems -settings is indeed GPL? [10:11] pitti: yes, settings is GPL [10:12] none of the .c files have a copyright header, but there's a GPL2 COPYING [10:12] I thought you were referring to the drivers [10:12] tseliot: so -settings should go into main? [10:12] pitti: yep [10:12] tseliot: done [10:12] pitti: thanks a lot, now about 310 [10:12] pitti: is it nvidia-310? [10:13] tseliot: sorry, what? [10:13] tseliot: I was exclusively talking about nvidia-settings-* here [10:13] pitti: ok, never mind then. Thanks again [10:13] tseliot: heh, yay confusion :) thanks [10:15] jodh: Can I see configure output for the 64-bit system in question? [10:18] cjwatson: http://paste.ubuntu.com/5839892/ [10:20] Hey all. I prepared some patches for the heimdal package and got reprimanded for not following SRU directions :-/. I understand most of the concerns except for one: "please could your review the versioning you are using". Could anybody here tell me what versioning I should use? https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1191704 [10:20] Launchpad bug 1191704 in heimdal (Ubuntu) "KDCs complain about not having enough file handles for /var/lib/heimdal-kdc/heimdal" [Undecided,New] [10:21] marga: Under https://wiki.ubuntu.com/StableReleaseUpdates#Procedure, point 5.1. links to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging with examples of version numbers. [10:22] marga: since heimdal is at the same version number in precise/quantal/raring, use the example that encodes ubuntu release version number from a debian version number [10:23] ok, thanks. [10:23] actually precise is different, quantal/raring are exactly the same and saucy has a different debian revision. Still, I'll read the guidelines and follow them. Sorry for not finding them myself. [10:23] marga: 1.6~git20120403+dfsg1-2ubuntu0.12.04.1 is probably gonna be the version number for precise SRU. [10:24] marga: precise is indeed different =) getting cross-eyed looking at those version numbers. [10:25] So, should I leave it as it is for precise? [10:25] marga: so precise could use "ubuntu0.1" suffix, and quantal/raring need to use ubuntu0.13.04.1 / ubuntu0.13.10.1 [10:25] Ok, good. [10:25] I'll do this. Thanks. [10:25] np [10:51] didrocks, looking at the changelog at https://launchpad.net/ubuntu/saucy/+source/phablet-tools/0.14+13.10.20130703-0ubuntu1 ... does jenkins not use dch to append its "automatic snapshot" message ? looks a bit messy .. [10:52] (not highly important indeed, but it looks a bit mangled) [10:52] ogra_: it does [10:52] weird [10:52] it does that for every content [10:52] every commit messages removes lines, one entry per commit [10:53] ogra_: I bet sergiusens added in his commit message multiple * [10:53] yes, since it were multiple commits merged into one [10:53] ogra_: see: http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/revision/119 [10:53] yep [10:54] and as the decision was to take only commit messages to trunk, that's what we end up with :) [10:54] right ... if i call dch here on such a file it simply appends to it [10:54] yep, no magic reformatting [11:08] jodh, why does it try to link with libintl.a, and not libintl.la (or the system one)? Maybe first check the config.log why the tests have different outcome on i386 and amd64 === oSoMoN_ is now known as oSoMoN [11:09] doko: ok === MacSlow is now known as MacSlow|lunch [11:33] jodh: That looks like configure was run with --with-included-gettext [11:33] TBH, for projects that use gettext where I'm upstream, I switched to AM_GNU_GETTEXT_EXTERNAL a while back, and people can install gettext if they're really using a system that lacks it [11:33] Way less hassle all round [11:47] cjwatson: I think it must be distcheck that is adding --with-included-gettext, but seemingly only on 64-bit. [11:48] Might just be something about the set of packages installed. However, do you ever care about building upstart on a system that lacks gettext? [11:48] I'd argue you don't and that sidestepping the whole issue with AM_GNU_GETTEXT_EXTERNAL is the right thing to do. [12:06] Hi i am trying to compile gtk+3.0 source package on raring [12:07] did build-dep install and apt-get source gtk+3.0 [12:07] ./configure and make is resulting in these errors [12:08] undefinged reference to [12:08] can some one help did i miss a configure switch? i can see that the code exists in the gtk/ folder... just not getting compiled [12:09] the usual way to call the build system starts with 'debian/rules build', not ./configure and make [12:09] (you may want to remove the source directory and unpack it afresh now, though) [12:09] ah ... ok will try and report ... thanks === MacSlow|lunch is now known as MacSlow === ChrisTownsend1 is now known as ChrisTownsend [12:34] cjwatson, it worked thanks... === greyback is now known as greyback|lunch [12:51] When we sync from Debian, do we run dep8 tests? I have a failing dep8 test in puppet AFAICT - which is holding me back from introducing an unrelated delta (another test). === oSoMoN_ is now known as oSoMoN === greyback|lunch is now known as greyback [13:11] rbasak: talk to #ubuntu-release, it can be hinted to ignore dep8 failure. [13:11] rbasak: and yes, we run all autopkgtest =) [13:11] xnox: so we do normally do it? [13:12] rbasak: no, but we do have facility to ignore autopkgtest failure and migrate packages to -release. [13:12] Running DEP-8 tests is unrelated to where the package came from. [13:12] xnox: I wondered because I thought it might help me pin down the cause (ie. my environment vs. something broken elsewhere). [13:12] So in general we always run dep8 tests when we sync from Debian, right? [13:12] It doesn't matter where the package came from. [13:13] I actually found the cause since I asked that question, but it'd still be useful to understand in the future. [13:13] So "yes". [13:13] However, I don't see puppet on either http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html or https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ . [13:13] Here it was because apache2 is still on 2.2 in Ubuntu, and Debian have changed how it works in 2.4 and puppetmaster-passsenger won't work with the old one. It just so happens that zul did the merge yesterday but it hasn't gone through to saucy yet. [13:13] rbasak: you can run autopkg test exactly as in the jenkins lab using scripts from lp:auto-package-testing [13:14] Indeed, we're in the middle of the Apache 2.4 transition. If this is causing trouble, your best bet is really to help move the transition along faster, since it's likely to need a number of hands. [13:14] rbasak: apache2.4 is stuck in saucy-proposed with the rest of packages that are already using 2.4, until the remaining 2.2 ones are transitioned to 2.4 as well. [13:14] Is there a report for outstanding work? [13:15] rbasak: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958 [13:15] Debian bug 661958 in release.debian.org "transition: apache2 2.4" [Normal,Open] [13:15] see all the blocked bugs. === wedgwood_away is now known as wedgwood [13:19] xnox: thanks. What do we need in Ubuntu to get apache2 2.4 into saucy? All of those fixed, or a selection? [13:19] Probably all [13:20] Although I expect some will be removed rather than fixed - would prefer that to be as agreed with Debian though [13:20] I plan to be following along with removals [13:21] rbasak: so for apache2.4 to migrate, we need to well satisfy http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt see the last try to migrate apache2 together with a bunch of fixed packages. [13:22] rbasak: that gives a concise list of packages that are blocking transition. Those that are in main, are probably betters targets to help write patches for in debian and/or ubuntu. [13:23] xnox: thanks [13:27] * rbasak is struggling to understand that [13:28] * i386: 389-admin, 389-admin-console, 389-ds... [13:28] rbasak: yeah britney output is criptic. Given a package, it checks how many package where uninstallable before and after introducing said package. The number should stay the same or go down. If it goes up, they are listed. [13:28] Is that the list? Are all the packages in that list blocking migration, so it'll shrink as packages are fixed? [13:28] That means that promoting that set of packages (apache2 etc.) renders those packages uninstallable. [13:28] Fix them and that list will indeed shrink. [13:29] Got it. Thanks! === _salem is now known as salem_ [13:49] How does one download a package from debian NEW? I can't find the link [13:50] mterry: you can't, intentionally [13:50] See if there's a VCS listed [13:50] Laney, I thought that might be the case. OK [13:50] good idea === tkamppeter_ is now known as tkamppeter [14:32] So the dep8 test for puppetmaster-passenger fails for me because it uses apache 2.2 out of saucy. But if it were to use -proposed, it'd work because it'll pull in apache 2.4, right? And go through to saucy? [14:32] (assuming there aren't any other issues) [14:42] rbasak: you can always try it :) the tests on jenkins.qa.ubuntu.com should use -proposed [14:43] rbasak: indeed e.g. https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-apport/ARCH=amd64,label=adt/lastSuccessfulBuild/artifact/results/log shows it looking at -proposed [14:44] Thanks. I'll test against -proposed locally, and if that works then I'll upload. Worst case is that it'll end up stuck in -proposed, and I can guess it's no worse to wait if that happens. [14:45] you're going to be waiting either way, it seems === freeflyi1g is now known as freeflying [15:08] ogra_: Flipped Root Image ... would be a more FRUITy name [15:09] ogra_: Flipped Root Ubuntu Image for Touch === wedgwood is now known as wedgwood_away [15:09] sladen, haha === wedgwood_away is now known as wedgwood [15:11] cjwatson, click is telling me I don't have ubuntu-sdk-13.10. I swear I do. How to I tell it so? :-) [15:12] tedg: --force-missing-framework [15:12] tedg: I wasn't aware that any package delivered the necessary file in /usr/share/click/frameworks/ yet ... [15:13] Ah, I thought it was checking the debian package [15:13] ubuntu-sd [15:13] ubuntu-sdk [15:13] Nope [15:14] Can't load the system package database [15:14] Ah, okay. [15:14] Plus I'm not sure there's any guarantee that the current version is actually "13.10" yet [15:14] So for now, --force-missing-framework is rational [15:14] Yup, that's fine with me. I just thought it was user error :-) === Ursinha is now known as Ursinha-afk [15:47] cjwatson, Is there a way to know that camera-app.desktop is the desktop file? [15:48] cjwatson, I was expecting a manifest that'd either point to it, or a generic name. [15:49] tedg: Not hooked up yet, but I'm expecting the manifest to declare a hook (something like https://click-package.readthedocs.org/en/latest/hooks.html) naming the desktop file [15:50] So you might have "hooks": { "desktop": "camera-app.desktop" } [15:51] tedg: If you want to tell me where the file ought to be linked to, I could start on figuring out whether the current hooks interface can properly express that [15:51] (And whether any further actions need to be taken, or if it's just "make a symlink") [15:51] Hey guys, where is the source code of the bot that you guys use to sign-in patch pilots? [15:52] cjwatson, I think we'll want to build a new desktop file. i.e. replace the Exec line with something like "click-launch" or something so that we can add the apparmor profiles automagically. [15:52] cjwatson, Where we wouldn't want applications doing that themselves. [15:52] tedg: Ah. I was hoping we wouldn't have to do that, but oh well [15:52] smartboyhw: ask on #ubuntu-irc or check IRC topics on wiki.u.c, it's linked there somewhere. [15:52] I've been trying to avoid having to build a templating language into click [15:53] But we could use Exec lines to run sed over things, I suppose === _ffio_ is now known as bsd_freak [15:53] cjwatson, I don't think we'd have to do that. I think we could just read the desktop format and modify it. [15:53] Exactly. Sed or a utility, or whatever. [15:53] tedg: I thought the point was to hook this into application.upstart and have that apply the profile [15:54] cjwatson, Sure that works for the Unity usecase, but I don't think we'll get other DE's doing that. And it'd be nice if they could use Click as well. [15:55] tedg: i would have hoped, that xdg-open file://*.desktop works which takes the desktop file, applies any necessory apparmor/upstartfication and launches the desktop file. [15:55] tedg: OK, so if I can get a path-and-file-format-level spec for what I'm supposed to do here, I can have a go at implementing it [15:55] tedg: and based on the current DE it could do less or more.... [15:55] tedg: I'm expecting that the first couple of hooks we write here will need modifications to the core, since it's pretty minimal at the moment [15:55] tedg: cause inherently, launching a desktop file under upstart/apparmor is independent off using click package or .deb === kk2 is now known as Kk2 [15:56] One problem is that the path to the executable is not known [15:57] So either we need to substitute the installation path into the Exec field (could be hairy) or we need something that sticks the app's unpack directory on the front of $PATH before executing [15:57] (which then means your executable has to be at the top level of the app) [15:57] Yeah, that's why I was thinking something like "click-launch com.ubuntu.foo" [15:57] Right, but that just moves the problem around [15:57] It still needs to know what the entry point is [15:57] tedg: couldn't this be a function of the sdk? iirc, it creates a desktop file. why can't it create it to use your launcher? [15:58] jdstrand: That means that an app can be manually created to ignore the launcher, ignore apparmor profiles, etc. [15:58] cjwatson, Yes, but it means that we do it in a place that is independent of the DE. [15:58] jdstrand: Pretty sure your team would be unhappy about that [15:58] It's all contained in "click packages" [15:59] We could figure out the path that is relative to the right directory for the right version, etc. [15:59] tedg: Even so, we'd still need something to hook that into the list of installed applications [15:59] cjwatson: sure, but we could have an automatic check for that [16:00] Sure, and that would be putting the desktop file in /usr/share/applications. So that desktop file would be a generated one that would call back into the click system. [16:00] well, manual check first, that is made automatic later [16:00] jdstrand: The server isn't going to have any checks for 13.10 [16:00] jdstrand: So anything that can be mandated automatically rather than requiring checks is a very definite win [16:00] cjwatson: I realize that. everything is gated on manual review. there will be tools though for those reviewers, that would grow into automatic checks [16:00] tedg: Can't be /usr/share/applications/ - /usr will be read-only [16:00] jdstrand: Honestly, I would rather have a design that doesn't require checking [16:00] As a strong design principle [16:01] cjwatson, heh, okay, /opt/com.ubuntu.click/desktop-files :-) [16:01] tedg: Isn't there a ~/.local/share/applications/ or something? [16:01] I appreciate that point, but I thought that click was supposed to be generally reusable in other places [16:01] if it isn't, fine [16:01] cjwatson, yeah, we could do that as well. [16:01] tedg: We may end up having multiple click paths, so I'd like to avoid the dash/launcher/whatever having to know to look in click-specific paths [16:02] jdstrand: well, it is, but saying "click packages must be launched using 'click launch com.ubuntu.foo'" doesn't seem to impede that [16:02] cjwatson, Hmm, yeah. Seems like it shouldn't have to be per-user for some cases though. [16:03] jdstrand: And doing this kind of thing in the SDK means that it's hard to change [16:03] jdstrand: If we need to change some bit of the app/launcher glue (hopefully it would never change, but ...), then we have to rebuild all apps and it all gets very boring [16:03] cjwatson, I guess we could have the "installer" check to see if it's installed first. And perhaps some cases the install is just creating that desktop file. [16:04] cjwatson, What I worry about there though is that the hook effectively needs to run as the user then, not the click installer user. [16:04] I'm still thinking of how per-user apps ought to work [16:04] But I'm beginning to come round to the possibility that maybe most hooks actually want to run as the user [16:04] Because if the system partition is read-only, most system hooks can't do much anyway [16:04] Hmm, interesting. [16:05] However there's the matter of packages preinstalled on the system partition [16:05] Seems like those wouldn't be per-user, right? [16:05] One option is to have a "register" kind of step where you register the system-installed packages in a user's list [16:05] In bulk [16:05] cjwatson: er read-only> this is something sbeattie and I have been thinking about with apparmor profiles too. I had figured that they would be tucked in /opt somewhere as writable be the click package user [16:06] I don't have an implementation suggestion, but I'm not keen on loading user owned policy [16:06] OTOH I think I've heard people say that at least some core apps shouldn't be entirely removable (i.e. if you remove them it just means it flips back to the version in the system partition) [16:06] jdstrand: No, I agree on that part [16:06] So maybe we need both user and system hooks [16:08] Having to put things in /opt is annoying though, because /opt's layout is not really typically friendly to being loaded in bulk by the system. Do we have any subdirectory of /var or something that's guaranteed to be on the user-data partition? [16:08] (And that isn't transient, like something bind-mounted off /run) [16:08] maybe /var/cache? I've not been part of these image layout conversations though [16:08] I'm not sure, perhaps rsalveti has info there? [16:12] fwiw, I was not suggesting the sdk handle it, I was just tossing the idea out there. the 'click launch' seems fine (feels slightly out of scope though...) [16:13] jdstrand, tedg, stgraber is the person defining the image layout [16:13] zul, for python-amqp, why run just that one test? [16:13] as he implements the image based updates and readonly filesystem stuff now [16:13] mterry: havent figured out how to run the rest of the tests in a buildd yet [16:14] I can see it as in scope; at least for demonstration purposes. [16:14] k [16:14] I could implement it without it necessarily having to be the way apps end up being launched. [16:15] That said, "click launch" would run as a user, and the apparmor profile still has to have been generated and stashed somewhere first, so I don't think I can implement it yet. [16:16] cjwatson: sbeattie will be starting on the click hook imminently === wedgwood is now known as wedgwood_away === wedgwood_away is now known as wedgwood [16:17] cjwatson: the first cut for the demo may very well be putting it in /etc/apparmor.d, but we recognize that will need to change [16:17] jdstrand: Incidentally, what's the specific reason why user-owned policy is bad? I get that we don't want an app to be able to modify its own policy, but that's not quite the same as being user-owned [16:18] My understanding of the security policy is that we're principally trying to defend the user against malicious apps === bsd_freak is now known as babaji [16:19] cjwatson: you're right that they are different. loading policy is a privileged operation currently. one example of why it would be bad is that an unprivileged non-admin user would be able to modify one of these files and override system policy [16:20] or write new system policy [16:20] it is thorny. we don't have user profiles yet. we just can't allow it now [16:21] If you can override system policy, I can understand the restriction [16:22] user profiles are planned, but it is not for 14.04 [16:22] I just wanted to check that it wasn't actually a fig leaf - for example if you were trying to prevent the app from overwriting its own policy in the case of a policy leak, which could equally well be used to write a new desktop file for itself :) [16:23] sbeattie: For the record, don't worry too much about polishing the edge of your code that interfaces with click [16:23] it doesn't have to do with the app [16:23] jdstrand: OK, good, I understand correctly then [16:23] sbeattie: I more or less expect to have to munge the interface about a bit, and I'm happy to take a lump of code that does the policy-specific work and then deal with the integration [16:24] (In fact it's arguably easier for me to deal with it that way, just at the moment) [16:25] cjwatson: the desktop file is an interesting consideration though. where do we expect them to live? currently, we figure things in /opt will not be writable by the user (DAC would protect against that too, but this is another layer), and then app data is in XDG dirs. [16:26] but we don't want the .desktop file to be modifiable [16:26] jdstrand: This is one reason I'm hoping not to have to run any processing over them, because then the desktop file can just live in /opt [16:26] (by the app-- the user could if desired) [16:26] /opt is great by me :) [16:26] jdstrand: But, a desktop file in .local/share/applications/ wouldn't be modifiable by the app either, surely [16:26] (Or whatever) [16:27] .local/share/applications will not be allowed, and would be acceptable too [16:27] so long as it isn't in .local/share/ :) [16:27] I am on board with the general principle that an app should not be able to modify itself. We may have to argue about the details :) [16:27] * jdstrand nods [16:27] Oh, indeed, no, that wouldn't buy us anything even if I thought it were a good idea [16:27] though I think we are in agreement :) [16:28] I want to avoid anything where elements of the system have to iterate over lots of app directories, as much as possible [16:28] That kind of code tends to be really tedious and doesn't usually fit well with existing facilities [16:28] I don't particularly care on the implementation detail as long as it is cleanly separated from the app's writable area [16:29] cjwatson: yep, cool [16:29] I prefer models where bits of the app get linked or copied into single system- or user-owned directories [16:29] Ideally linked [16:30] cjwatson: I might mention, and I don't think this conflicts with anything we've said, we are trying to make it so apps can't enumerate what other apps are installed [16:31] cjwatson: an app shouldn't need read access for /usr/share/applications, /opt/.../wherever or .local/share/applications anyway, but thought I'd mention the principle [16:31] I guess then you need them not to be able to list either /opt/click.ubuntu.com or whichever directory we put the per-user links in, and you need them not to be able to execute /usr/bin/click [16:31] Or talk to the relevant PackageKit API [16:31] that's correct [16:31] that is all handled by default [16:31] Assuming that you're doing positive permissions rather than negative permissions, and I assume that because I believe you're generally sane :-), that shouldn't be a problem [16:32] that's accurate [16:32] well, sane is probably for discussion, but... === Ursinha-afk is now known as Ursinha [16:32] Just remember that the ability to list any directory that's used as the target of a hook might permit implicitly enumerating at least a subset of apps [16:34] I'm not up on "any directory that's used as the target of a hook" [16:35] our current templates will do things like /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/ [16:35] where @{APPNAME} and @{APPVERSION} are declared in the manifest [16:35] I also understand that the exact path may change, based on earlier discussions [16:36] we can't use .local/share/applications...it needs to be outside the home directory [16:36] mdeslaur: why, I feel like I missed something? [16:36] since the home directory can be encrypted, click packages needs to be able to clean out unused versions of packages [16:37] to do that, it needs to be able to enumerate what each user has [16:37] (ok, not the app confinement concern :) [16:37] s/the/a/ [16:37] no, not an app confinement concern [16:38] also, the launcher list is outside the home directory, and it presumably needs to fetch icons and stuff from the desktop files [16:38] because the lock screen launcher needs to work [16:38] target of a hook> What I mean is that if there's a system-provided hook that says "apps which provide the 'foo' facility get a named file symlinked into this directory", then enumerating that directory gives you a partial list of installed apps [16:39] mdeslaur: so, this is probably just chalked up to 'that will be handled via a system security update', but I hadn't really considered crafted/malicious icons [16:39] mdeslaur: .local/share/applications/ won't be the registry of what each user has [16:39] that could trigger stuff outside of confinement [16:40] jdstrand: meh, no different than anything else the app could provice [16:40] provide [16:40] cjwatson: oh, sorry, I misunderstood then [16:40] mdeslaur: It seems unfortunate that encrypting one's home directory wouldn't imply encrypting the list of which apps one has installed [16:41] mdeslaur: Existence proof: "pornview" [16:41] cjwatson: quite...but I'm not the one who decided to put your list of installed apps on the lock screen :P [16:41] mdeslaur: well, yes and know. taking the kernel out of it, the app is providing an image that is displayed outside of confinement by unity. most of what an app can do is within confinement [16:41] s/know/no/ [16:41] (weird typo) [16:41] mdeslaur: Although I suppose the actual app is in /opt/ anyway [16:42] mdeslaur: So I guess it should be somewhere outside /home, but in user-owned mode 700 directories, to at least discourage casual snooping [16:43] mdeslaur: Then click running as root can still prune things [16:43] cjwatson: yes...I believe the plan at some point was to use accountsservice to store that [16:43] mdeslaur: Huh, nobody told me. Reference? [16:43] tedg: ? [16:43] ^ [16:43] I'd been planning something really high-tech like, you know, a directory [16:44] cjwatson: I blame either a rumour from ted, or my faulty memory :P [16:44] And actually it would be a right pain to have to go and talk to some other service for click's registry of installed apps [16:44] cjwatson: oh, I was referring to the launcher items, not the list of installed apps [16:44] Oh, right. This is why I keep trying to get a spec out of Ted ;-) [16:45] squeeze harder :) [16:45] hehe [16:45] mdeslaur: (Your ideal lock screen makes the device invisible, right?) [16:46] cjwatson: hehe, well, I think the launcher on the lock screen is cool....as long as the paranoid/enterprise users can enable a "safe" lock screen in the settings somewhere [16:46] I don't include myself in the list of paranoid people :P [17:05] cjwatson: so I can't think of any reason not to put MokManager in the existing shim binary package; can you? [17:10] cjwatson: from the above conversation, the how to launch a click installed app from a DE is not solved, right? Do you know who owns that if so? [17:13]