=== kickinz1|afk is now known as kickinz1 [06:45] pitti: hi, if you have a moment, I would greatly appreciate you help with udev :) I work on a end-to-end test of the new hardware assign feature, I created a snap with an assign rule for ttyS0 and on install it generates the following rule: http://paste.ubuntu.com/10854819/ but the subsequent udevadm info seems to not show the snappy-assign tag, is there anything that I'm missing here? [06:45] pitti: hm, to be exact I have the tag after a reboot, so I guess I need to trigger a re-read of the udev rules(?) [06:55] good morning === kickinz1 is now known as kickinz1|afk [08:20] Good morning [08:20] mvo: o/ Gruesse aus London (Bluefin) [08:20] pitti: hey, good morning! [08:20] mvo: wrt. the branch, I think there might still be something wrong [08:20] pitti: how is the jetlag :) ? [08:21] mvo: I didn't get any /dev/null failures while the ACL setting was still broken, so I wonder if the "deny all" rule was actually applied [08:21] pitti: aha, ok [08:21] mvo: well, getting slightly better; the strong English breakfast tea helps :) [08:21] mvo: how is your's? [08:21] pitti: I did a end-to-end this morning and ttyS0 got assigned, but of course that is just the allow [08:22] pitti: I'm pretty tired :) but indeed, tea helps [08:22] mvo: yes, if you just install the rule, you need udevadm control --reload [08:22] mvo: ^ well, maybe; actually you might not need it for new .rules files [08:23] mvo: but for sure a new udev rule doesn't apply to already existing machines, you need to udevadm trigger those [08:23] pitti: aha, so udevadm trigger after the rules get installed? I will add that [08:23] mvo: udevadm trigger --verbose --name-match=ttyS0 [08:24] pitti: nice, thanks [08:24] mvo: the --verbose shows the triggered devices (you can leave this out on the final commit, of course) [08:24] mvo: that will re-apply the rules on an existing device, i. e. synthesize a "change" event [08:26] pitti: thanks, I will add that to my code [08:26] pitti: I guess I need to write code that maps all the matches in the yaml to the udevadm trigger ? or can I do a global trigger? [08:26] mvo: you can trigger everything too, yes [08:26] how horrible is that? [08:27] mvo: on a desktop this might lead to some undesired effects, like keyboard layouts getting reconfigured etc. [08:27] mvo: but for the most part it sohuld be okay [08:27] ok, thanks! so just udevadm trigger? [08:27] mvo: actually, it's much easier: [08:27] mvo: you can use the same udevadm trigger command as in my shell PoC [08:27] mvo: just without the --dry-run [08:28] mvo: that will trigger exactly those devices which got assigned to that app [08:28] pitti: sweet, thanks! [08:28] so just "udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=$APPNAME" :) ? [08:28] well, without the --dry-run [08:28] udevadm trigger --verbose --tag-match=snappy-assign --property-match=SNAPPY_APP=foo [08:28] mvo: right [08:29] pitti: \o/ [08:29] pitti: about the deny-all, will you look into this or should I do that once I finished the change above? [08:29] mvo: I'm looking into it [08:29] mvo: did you get the other fixes? [08:29] thanks! [08:30] pitti: some changes, nothing major, r32 is my latest version [08:30] pitti: I was working on a example snap, the go code and a end-to-end test [08:30] mvo: ah, I see you merged my stuff, good [08:31] pitti: yes, thank you very much for this! [08:41] $ echo > /dev/null [08:41] bash: /dev/null: Operation not permitted [08:41] mvo: ^ I took /dev/null out of the static list, and now get that [08:41] mvo: IOW, it's all good [08:41] mvo: just wanted to double-check [08:41] pitti: \\\o/// [08:41] (spide hug ;) [08:41] spider even [08:41] mvo: you have *that* many arms? you scare me! [08:41] * mvo hates jetlag [08:42] and not even enough arms for a spider - oh well! [08:42] * mvo drops into koma [08:45] spider hug is nice ;) [08:45] * asac wonder if i heard that expression before [08:46] probably not, its my jetlag speaking ;) [09:08] Good morning all; happy Monday, and happy Chinese Language Day! :-D [09:27] asac, Chipaca, sergiusens: so the hardware yaml looks like this right now: http://bazaar.launchpad.net/~mvo/snappy/snappy-hardware-yml-to-udev/view/head:/snappy/snapp_test.go#L1127 - my question is if we should include the namespace in the app-id, i.e. should it be exclusive to the app.namespace or is app ok (frameworks can not be forked so for most of the use-cases this is probably ok). but I want to double check [09:28] mvo: hardware is another kind of snap? [09:28] fwiw, thats the only open question otherwise I think all the bits for hardware assign from a oem snap are ready [09:28] mvo: ah, I didn't check -- did you happen to have the time to upload those fixes for the failed two units? [09:29] mvo: if not, where could I commit these changes? [09:29] mvo: or is it part of the oem kind? [09:29] pitti: I did, but it seems like its still broken because our pathes are writable only later [09:29] pitti: i.e. the seed path is RO when systemd needs it and only made writable later [09:29] mvo: ah, ok; that should be in devel-proposed? [09:29] mvo: if part of the oem, i think sergio was going to make them namespaceless [09:29] mvo: the tmpfiles.d thing ought to work now? [09:29] pitti: yes the path is writable but I think its too late [09:30] pitti: I think so, the only missing one was the random seed [09:30] mvo: ok, so that sounds like another one which we move to the initramfs, or we just mask the service entirely [09:30] Chipaca: the app-id can be any app, the idea is that e.g. robot-maker has a robot-oem and a robot-framework and assign the /dev/robot-brain in the oem to the robot-framework app [09:30] asac: -^ thats right, right? [09:31] right [09:31] pitti: yeah, there was a simiilar issue before iirc, but I don't remember the details right now without looking in the bzr log [09:31] mvo: its not app id [09:31] its part id [09:31] can be any part ;) [09:31] framework, app [09:31] ubuntu-core maybe even [09:32] (though the latter for sure not right now) [09:32] asac: ups, I can rename that, no problem [09:32] mvo: hm, that fix isn't in devel-proposed yet apparently (just flashed a fresh image) [09:32] pitti: let me check [09:33] pitti: hm, I see it at the end of /etc/system-image/writable-paths, /var/lib/systemd/random-seed but the dir is missing, thats probably the problem [09:34] * mvo tests [09:36] mvo: I mean /var/lib/machines/ is missing as well, tmpfiles is failing [09:36] asac: so should I add the namespace there when I create the launcher? i.e. if I install hello-world from canonical should the part-id be hello-world.canonical? or should it be namespaceless? if you say any partid it seems we want the namespace. which makes sideloading a bit ugly and also that the oem snap needs to know the namespace of the final store package but that is probably ok [09:36] lool: you around? [09:37] pitti: I have that dir in r404 [09:37] pitti: what is your image id? [09:37] mvo: *brown paperbag* [09:37] mvo: no, I never forget to actually give a --channel option! [09:38] mvo: hmm [09:38] mvo: image 404, nice! and it found it :) [09:38] pitti: :) no worries [09:38] mvo: i think built-in field in oem snap allows both? [09:38] pitti: hahahahaha [09:40] mvo: i think semantic should be like the install ... if no namespace is given it resolves to what really got installed and usese that [09:40] if namespace is given, it obviously uses that [09:41] if oem gives access to a part not even installed then thats a fail [09:41] mvo: ah, /var/lib/systemd/random-seed doesn't exist at all, I figure that might be a problem as well [09:41] e.g. dont allow assigning hardware tos tauff that isnt getting installed in oemn [09:41] * asac also feels the jet [09:43] mvo: merely touching the file is enough [09:43] mvo: then it actually gets mounted (that fails for nonexisting files), and now systemctl --failed is empty \o/ [09:44] pitti: nice [09:46] asac: hm, so not allowing parts that are not installed is tricky as the oem part is installed first right now and then the others, at this point I really would like to keep it simple. I think I go with the namespace as this should not cause any problems and we can expand later(?) [09:49] mvo: ack .... lets just document it cleany [09:49] asac: cool, I will do that [09:57] mvo: about 'go remove pkg' only removing the active one, should purge do the same? [09:57] mvo: there is common code there i could factor out in a branch and make it behave like that, if so :) [10:06] Chipaca: I think purge and remove should behave the same, yeah, asac is of course the ultimate authority here but unless he says otherwise I think thats sensible [10:06] i might put one of my cards back from 'in progress' to 'must do' and pick up that one, if asac can confirm [10:07] Chipaca: ok [10:07] Chipaca: whats the question? [10:07] asac: Chipaca> mvo: about 'go remove pkg' only removing the active one, should purge do the same? [10:07] asac: should purge and remove behave in the same way wrt how its argument is interpreted? ie whether 'remove foo' should remove all forks or just the active one, etc [10:08] heh .) [10:08] same behaviour [10:08] whether its correct as is i dont know :) [10:08] but lets stick to what we have (sound reasonable without thinking too hard) [10:10] asac: there's a card to change what we have slightly [10:10] asac: and what we have right now is slightly different behaviour for remove and purge [10:10] asac: so we should at least make them the same :) [10:10] asac: and while i'm at it, we can choose what 'the same' means :D [10:12] Chipaca: what options do we have? [10:13] asac: if you have foo.canonical and foo.asac installed, should 'remove foo' remove both of them, or only the active one? [10:14] Chipaca: hmm. might be difficult, but one half of me thinks that we shoujld remove whatever the foo alias points to currently in store [10:14] but might be wrong [10:15] Chipaca: how does the world in snappy list look like? [10:15] and snappy search [10:15] i think those might give some guidance [10:15] if you could paste those for both scenarios [10:17] asac: "snappy list" always shows the namespace [10:17] snappy search does not, if it's got an alias [10:20] snappy search seems to be missing the option to show all forks -- i thought we'd done that? [10:20] * Chipaca is confused [10:21] Chipaca: I have that on image r404 amd64 [10:21] Chipaca: http://paste.ubuntu.com/10855388/ [10:23] asac: current output of search vs list: http://pastebin.ubuntu.com/10855402/ [10:25] mvo: yes, not sure why my snappy was an old one -- i'd probably been testing things for an old branch on there [10:37] no worries [10:37] good to raise it in case there are lurking issues :) [10:47] any idwea what this 8nzc1x4iim2xj1g2ul64 43 Returns for store credit only. is ? [10:47] Chipaca: ? [10:48] asac: a package [10:48] asac: it's called “Returns for store credit only.” [10:48] asac: the package name is 8nzc1x4iim2xj1g2ul64 [10:49] why do we see that when searching for hello-world? [10:50] asac: i don't know. possibly because the icon is called 'hello.svg'? but i'm not certain [10:50] asac: elastic search question [10:50] beuno: ^ is that a good package? [10:50] asac, Chipaca uploaded it! :) [10:50] that i did! :) [10:50] and it's very good. washes my dishes and everything. [10:51] Chipaca: ok, as long as that is not a bug :) [10:51] indexing the icon filename might be a bug, but i'm not sure we can control that :) [10:51] beuno: ? [10:51] let me see why it matches [10:51] Chipaca: what does that package do? [10:52] asac: uh... i think it's just 'hello world', renamed to something unique for testing purposes [10:52] ic [10:52] asac: i wanted something i could be more or less sure nobody would find by accident [10:52] (this is why Chipaca should never be allowed to name things) [10:52] of course it turning up when looking for hello world defeats that :) [10:53] beuno: hey, only *one* of my kids has a completely unpronounceable name! [10:53] (for the brits, at least) [10:53] Chipaca, the package description is "This is a simple hello world example." [10:53] beuno: oops :) [10:53] i guess i'll have to upload a new version that fixes that [10:53] so ES is expecting an apologyu [10:54] Chipaca: i could imagine remove|purge --active|--inactive ... and otherwise remove all that are there [10:54] beuno: good thing software is patient [10:55] Chipaca: i think having a name that is more descriptive would look nicer ... or have at least a better description stating "package with random name for testing purpose" [10:55] pitti: hm, there seems to be still something missing in the udev foo, in the following pastebin I run udevadm trigger -v and still do not see ttyS0 even though the rule is availalbe and I called udevadm control --reload :/ details in http://paste.ubuntu.com/10855524/ - do you have any idea(s)? [10:56] mvo: ^^ asac on remove removing everything by default [11:00] note that i dont have super strong feelings, just that if i look at list it feels to me that if i type remove hello-world i would expedcrt both to disappear [11:00] pitti: so I had to do "udevadm control --reload-rules" and "udevadm trigger" to make it appear, is that correct? it seems the trigger is a bit broad but using the specific trigger appears to not cut it [11:01] * mvo gets lunch [11:01] mvo: oh! [11:01] mvo: of course, that can't work [11:02] mvo: if the devices *had* a tag already, we wouldn't need the trigger; the new rule is the thing that adds the tag in the first place [11:02] mvo: which is why your trigger didn't list any devices [11:02] mvo: so yeah, do a full trigger for now [11:02] and a "udevadm settle" to make sure you dont add races ;) [11:03] no, not necessary [11:03] well, maye for apps which need to access the hardware right away, so it's indeed better, yes [11:03] well, i always find that safer ... [11:04] pitti: thanks, will do [11:04] ogra_: right [11:04] (if you have some late processed rule that mangles the device again or some such ...) === kickinz1|afk is now known as kickinz1 [11:20] Chipaca: http://paste.ubuntu.com/10855615/ [11:20] that one is a bit unhappy on snappy list [11:21] asac: ? [11:21] Chipaca: see the paste [11:21] snappy list isnt doing anything [11:21] asac: did you install anything? [11:21] all other commands are also unhappy [11:21] Chipaca: nope [11:21] Chipaca: see the ls /apps/ [11:21] fresh install of the image as in paste [11:21] version version: 234 [11:22] using beagleblack.canonical fwiw [11:22] asac: ok, i'll look into it in a bit [11:22] Chipaca: sudo ubuntu-device-flash core --oem beagleblack.canonical --channel edge --output mysnappy-arm.img [11:22] thats how i produdced it [11:22] thanks [11:24] * Chipaca gets some coffee [11:25] Chipaca: reproducible on amd64 kvm with sudo ubuntu-device-flash core --oem amd64.canonical --channel edge --output my-snappy.img [11:25] guess that is quuicker to debug :) [11:26] guess its the oem snap that makes snappy unhappy [11:28] * Chipaca builds [11:37] pitti: thanks again, the snappy hwassign stuff works now end to end, I just tested it with https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-oem-hardware-snap/+merge/256800, ubuntu-core-launcher from the PPA and the snappy from my branch and I got access to /dev/ttyS0 [11:37] asac: -^ first successful end-to-end :-D [11:41] \o/ [11:41] very good [11:44] i guess with that ogra can write his heating appliance finally :) [11:44] and start selling it :) [11:45] lol [11:45] i still have the prob that snappy cant properly handle the config in case of that app [11:51] Chipaca: i'm around, what's up? [11:52] ogra_: not sure what you mean [11:52] what config? [11:52] lool: hello! have you any suggestions around how long we should wait between TERMing and KILLing a process that's been asked to stop and hasn't? [11:52] Chipaca: i think there was a field that folks could configure, but we wanted to set a maximum time theyh are allowed to request [11:53] Chipaca: less than 5 seconds [11:53] which should be pretty snappy :) [11:53] not suure if 5 seconds [11:53] Chipaca: is 5 seconds too long for your use case? [11:53] but not too far longer\ [11:53] if it needs more than 5 seconds, then we shoudl have an API for it [11:53] lool: there was a stop-timeout, capped at 90 seconds*, but this is not that [11:53] but the default should be less than 5 seconds [11:53] um, asac^ [11:53] heh :) I suggested 15s, Chipaca went with 2s [11:54] 2s is a bit aggressive for a busy system shutting everything down [11:54] lool: I had it at 2 seconds, but mvo points out that a python process on bbb takes that long to start :) [11:54] asac, fhem has all its config files inside the webroot and offers the user a web way to edit them ... i cant leave the files in the snappy package location (because they wouldnt be editable) and snappy wouldnt merge a new upstrema config with sme altered bits on upgrades ... [11:54] yeah, I don't really mind, afterall there was a stop command before that already hit a timeout [11:54] we dont have any way to handle that scenario [11:54] apart from me writing higly complicated merge tools [11:54] so basically we should leave processes enough time that they can save simple state, but not unload megabytes of data [11:55] mvo: note my ping to lool precedes my commit (and your review) :) [11:55] if they need to finish a long running job, or request more time, they need an API to express that [11:55] since we dont have that API for now, I'd rather we be conservative and leave it a bit longer for now [11:55] 5 seconds is fine, i think [11:55] typically on the desktop you could do things like prompt the user, or show that some processes are still saving [11:55] Chipaca: yup [11:56] I believe it's also the shutdown timeout that sysv used years back :-) [11:57] this reminds me. pitti: https://twitter.com/SwiftOnSecurity/status/589981229895659520 [11:57] hi - i wrote a simple shell script and built a snap file from it. after installing, i always get an error from app armor telling me "aa-exec: ERROR: profile 'testprojekt_mway_hello_1.0.0' does not exist". i wrote an app armor file choosing the default template and it is also installed, so what am i doing wrong? [11:58] yeah, 5s works for me, thanks! [11:58] plorenz: you wrote an apparmor file? [11:58] plorenz: initially? or was that because of the aa-exec error? [11:59] Chipaca: i didn't initially - i just tried to solve that error ;) [11:59] ah :) [11:59] plorenz: that error looks a lot like an error we got while we were breaking things [11:59] plorenz: maybe you're running a broken image? [12:00] Chipaca: could be, i'm running the raspberry pi image by lool from 15th april [12:00] mmmhmm [12:00] yah, that's probably got a broken snappy [12:00] hmm really [12:00] oh :/ is there a way to patch it? [12:00] plorenz: want to update the system? then you get new, more exciting broken bits :-p [12:01] that's odd, we tested high level things liek docker on it [12:01] lool: oh? interesting [12:01] maybe i'm jumping to conclusions [12:01] I need to finish a couple of things then I'll try a simple snap on rpi [12:01] plorenz: what are you doing when you get that error? [12:01] lool: thank you :) docker runs fine, also webdm [12:02] plorenz: perhaps tried an unmodified hello world; there might be a trivial typo that is causing a confusing error message [12:02] right, so other snaps get a profile [12:02] Chipaca: well, i have a script mway_hello and declared it as binary. i then run "testprojekt.mway_hello" and the error appears [12:02] plorenz: it sounds like there's a typo (like a name mismatch between this and that) but that we dont catch it for you [12:02] plorenz: I wonder if it's the underscore [12:02] plorenz: try with - [12:02] (that would be a bug we should catch, but wouldn't surprize me) [12:03] let me try that [12:03] hmm, is _ valid in a binary? [12:03] nope [12:03] needs to match [a-zA-Z0-9+.-] [12:04] its not right now, we might relax the rules, they are rather strict right now [12:04] oh okay - "snappy build" doesn't give me an error [12:04] mvo: apparmor uses _ as a separator, afaik [12:04] so we might need to pay more attention to some of the name mangling if we want it to be valid [12:05] asac: for i in /oem/*; do mv $i $i.canonical; done will fix your image [12:06] asac: it is indeed a problem with oem not having a namespace [12:06] sergiusens: ^ [12:06] aah now it's running :) thanks a bunch! [12:07] plorenz: you probably don't have the review tools installed, which are the ones that would have told you about that normally [12:08] Chipaca: how can i install them? [12:08] plorenz: (they lag a little behind, so sometimes will tell you things are wrong when they aren't, or viceversa, but are in general useful) [12:09] plorenz: click-reviewers-tool [12:09] plorenz: click-reviewers-tools, actually [12:11] Chipaca: nice, it works :) thanks, and you're all doing a great job by the way! [12:12] plorenz: \o/ [12:15] Chipaca: ok... thast odd, because i used beagleblack.canonical [12:15] so lets wait for serge [12:15] asac: but if you look in /oem/ you'll see beagleblack, i expect [12:16] asac: sergio knew this was going to be an issue. Because of your error I finally understood something he said on Friday :D [12:16] I must say, sleeping 12 hours does wonders for one's comprehension of stuff [12:18] Chipaca: could you give me a short summary of the problem or is it under control :) ? [12:18] mvo: snappy quits if it finds a namespaceless snap where it expects a namespaceful one [12:18] mvo: currently it expects oem snaps to be namespaceful [12:18] mvo: snappy quits [12:19] mvo: [12:19] thanks, makes sense [12:19] mvo: we need to either make oem snaps install themselves with a namespace, or make snappy treat them as frameworks wrt namespaces [12:20] mvo: or something in between :) but right now they're broken [12:20] are forks of oem snaps expected? [12:20] Chipaca: yeah, I am slightly leaning towards option (2) but lets wait for sergiusens and his input [12:20] i think sergio was too [12:20] asac: -^-^ [12:21] I have some stuff for review in he meantime ;) [12:21] maybe :-p [12:21] (and gave feedback) [12:21] * Chipaca looks [12:21] i dont know [12:21] i would have thought that in /apps/ frameworks also have namespaces [12:21] mvo: i looked at your udev branch, and left it for somebody who actually knows udev [12:21] just that the binaries dont [12:21] Chipaca: hahaha, so pitti needs to review it? thats fine :P [12:21] i feel we should avoid special casing namespace behaviour for new things [12:22] mvo: the go code is good :) [12:22] but leave it to you guys [12:22] asac: having namespaces in the files and directories impacts apparmor and such [12:22] asac: hence why it's out [12:22] mvo, Chipaca: please request a review from me, so that I'll get a mail [12:23] Chipaca: would you prefer both branches reviewed by a udev guy? or only the one that writes the rules? [12:23] asac: we had frameworks with namespaces but apparmor was all sad and aa-exec complained [12:23] mvo: i'm only just looking at the other one :) [12:23] ok, shout if I should ask for a additional reviewer for that :) [12:23] and thanks! [12:23] pitti: done, mail is out [12:24] mvo: do you need to cd to .Path as well as give u-c-l .Path as its first arg? [12:28] Chipaca: ok. guess too late, but thought jdstrand said he could fix those namespace probs for frames [12:29] asac: the other option we had was to create symlinks [12:29] asac: which would've been worse, i think [12:34] Chipaca: probably not, I think we should kill the CD and the path too, I can simplify stuff [12:35] mvo: otoh it's closer to what will be done for them for services, with WorkingDirectory [12:35] Chipaca: sure. if jdstrand couldnt do it cleanly then go for that thing for release [12:35] Chipaca: hm, good point, so I just kill it from the launcher for now [12:44] mvo: some things inline [12:44] Chipaca: I pushed the simplification now, thanks again (just omiting the baseDir in the launcher as first argument) [12:44] Chipaca: thanks, I check that out now [12:52] mvo: i see you missed the same thing i missed, wrt purge (and datadirs) [12:52] mvo: package.yaml is not in the data dirs ;) [12:52] mvo: and if you want to purge things that have been removed, looking for the package.yaml is not going to help [12:53] asac, kirkland, lool, slangasek: I sent you a mail about UOS planning - it'd be good if you could respond soon [12:53] i guess i should put a comment there [12:53] Chipaca: yeah, please do , maybe my poor jetlag brain will see it then :) [12:55] kickinz1: btw, is the latest image good for you or do you still run into issue of stuff that does not work? I think we fixed the issues we know so it would be great if you could tell us if you need more or if its looking good [12:56] testing right now the last image. [13:03] fyi, we could fix the framework namespaces and make it work with apparmor [13:04] he decided not to because it would make it so that namespaces had to be exposed to the apps that depended on them-- in two ways: [13:04] mvo: good idea wrt making the thing inactive while purging [13:06] 1. if a namespace was in the framework name and the framework policy allowed access to a file in the dir (eg, /apps/fwk.jdstrand/foo), then the framework policy would have something like '/apps/fwk.jdstrand/foo r,' in policy, then *apps* would have to use things like open('/apps/fwk.jdstrand') [13:07] mvo: reviewed [13:07] 2. since apps would have to know the framework to open(), they would then need to have in their yaml 'frameworks:\n - fwk.jdstrand' [13:07] jdstrand: hey, I can work on your seccomp branch and fix/update the tests if you want, my hwassign stuff is done (except for reviewer feedback and final testing) [13:07] this breaks several qualities of namespaces-- they can't be forked, they must be toplevel and apps shouldn't have to know the namespace [13:08] asac, Chipaca: ^ (re fwk stuff) [13:08] pitti: thanks a lot! a detailed code reivew from you is not needed, the improtant part is that the udev rules look valid in code and tests and nothing is obviously stupid [13:08] jdstrand: yep, you were quite clear on that; i skipped over that part when telling asac about it all [13:08] mvo: let me do the code cleanup first, then I can hand it to you [13:08] jdstrand: sorry :) [13:09] jdstrand: ok, either way is fine with me, I don't mind doing a cleanup along the way [13:09] s/he decided/we decided/ [13:09] jdstrand: looks good fwiw from a quick look over it [13:10] mvo: I'm not happy with a few of the interfaces. I'm happy to handoff, there is just some 'this works now but is ugly' bits in there. let me take out the ugly. it won't take long then I'll handoff === plars is now known as plars- [13:11] jdstrand: ok, no problem. don't get me wrong, I don't want to steal it from you or anything. I just figured with the questions about the click-reviewers-tools floating around this morning that this is also somehting that you probably want to work on and need time for :) (not sure if you have seen the backlog) [13:12] (2. since apps would have to know the framework *namespace* to open(), they would have need...) [13:12] jdstrand: thats not clear to me... i thought that frameworks would export the parts that apps would refer to in PATH or LD_LIBRARY_PATH etc. [13:12] mvo: I haven't and I want you to take it-- it wasn't ready to be reviewed just yet [13:12] jdstrand: why does app need to know where framework is on disk? [13:13] asac: it depends on how the framwork is written. I said *if* a framework exposes a file [13:13] and people will do it cause that is easy enough to do [13:14] I literally just came online now-- why are we having this discussion now? [13:15] jdstrand: probably because we broke snappy on the image if it has an oem installed [13:16] let's fix that rather than reworking namespaces :) [13:18] look, if people want to have .namespace in the fwk, we can fix apparmor (requires some patches). however, if we do we are redefining some qualities of frameworks [13:19] and we are making it more difficult for consumers of the frameworks [13:20] (yes, we could have an alias for a fwk, but are apps supposed to depend on an aliased name for a framework? I think not-- if the alias changed all those apps could break) [13:22] I'm of the opinion that the dev experience is paramount and maintain my opinion that frameworks should not be namespaced [13:23] if we are adding namespace back to the name, I need to know soon so I can update click-apparmor [13:47] mvo: Chipaca: i assume you guys have fixing regexps etc. for failures of self test in backlog? [13:47] https://jenkins.qa.ubuntu.com/job/vivid-core_devel_proposed-genericamd64-smoke-selftest/45/artifact/results/core-ubuntu-core_devel-proposed-generic_amd64-404-results/log/*view*/ [13:47] Can not find '^No package 'fizzler' for ubuntu-core/devel.*' in 'Installing fizzler [13:49] tyhicks: hey, we need someone to review mvo's launcher branch with highest priority. it includes seccomp, cgroups and I think namespace (for /dev/pts). can you work with mvo and get soemone on that? (sorry for the short notice) [13:49] jdstrand: no namespaces yet, sorry, if its important I can look into that next though [13:49] that's ok for now. we should add a trello card/file bug though for post 15.04 [13:59] jdstrand: sure [13:59] mvo: can I get a link to the branch? [14:00] tyhicks: its here https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk [14:00] mvo: Chipaca I am finally here! Landed, drove home, slept (not even unpacked); what the executive summary? [14:00] mvo: thanks! [14:00] sergiusens: no catastrophes so far :) [14:01] jdstrand: I wonder if http://paste.ubuntu.com/10856229/ would make sense? or is snappy build setting the wrong defaults here? [14:02] mvo: Chipaca oh, oem; it's weird since I've been working with them with my branches (which I couldn't push yesterday as I had no ssh at the airport and no proxy I could use to get over that) [14:07] mvo: yes-- likely. let me check [14:08] we have to rework all this with the new world [14:09] * sergiusens puts on some wake up *faster* music [15:07] mvo: is the Architecture field from DEBIAN/manifest used by snappy in any way? [15:07] jdstrand: no, 99% sure it does not [15:14]