| === kickinz1|afk is now known as kickinz1 | ||
| mvo | 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 |
|---|---|---|
| mvo | 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:45 |
| dholbach | good morning | 06:55 |
| === kickinz1 is now known as kickinz1|afk | ||
| pitti | Good morning | 08:20 |
| pitti | mvo: o/ Gruesse aus London (Bluefin) | 08:20 |
| mvo | pitti: hey, good morning! | 08:20 |
| pitti | mvo: wrt. the branch, I think there might still be something wrong | 08:20 |
| mvo | pitti: how is the jetlag :) ? | 08:20 |
| pitti | 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 |
| mvo | pitti: aha, ok | 08:21 |
| pitti | mvo: well, getting slightly better; the strong English breakfast tea helps :) | 08:21 |
| pitti | mvo: how is your's? | 08:21 |
| mvo | pitti: I did a end-to-end this morning and ttyS0 got assigned, but of course that is just the allow | 08:21 |
| mvo | pitti: I'm pretty tired :) but indeed, tea helps | 08:22 |
| pitti | mvo: yes, if you just install the rule, you need udevadm control --reload | 08:22 |
| pitti | mvo: ^ well, maybe; actually you might not need it for new .rules files | 08:22 |
| pitti | mvo: but for sure a new udev rule doesn't apply to already existing machines, you need to udevadm trigger those | 08:23 |
| mvo | pitti: aha, so udevadm trigger after the rules get installed? I will add that | 08:23 |
| pitti | mvo: udevadm trigger --verbose --name-match=ttyS0 | 08:23 |
| mvo | pitti: nice, thanks | 08:24 |
| pitti | mvo: the --verbose shows the triggered devices (you can leave this out on the final commit, of course) | 08:24 |
| pitti | mvo: that will re-apply the rules on an existing device, i. e. synthesize a "change" event | 08:24 |
| mvo | pitti: thanks, I will add that to my code | 08:26 |
| mvo | 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 |
| pitti | mvo: you can trigger everything too, yes | 08:26 |
| mvo | how horrible is that? | 08:26 |
| pitti | mvo: on a desktop this might lead to some undesired effects, like keyboard layouts getting reconfigured etc. | 08:27 |
| pitti | mvo: but for the most part it sohuld be okay | 08:27 |
| mvo | ok, thanks! so just udevadm trigger? | 08:27 |
| pitti | mvo: actually, it's much easier: | 08:27 |
| pitti | mvo: you can use the same udevadm trigger command as in my shell PoC | 08:27 |
| pitti | mvo: just without the --dry-run | 08:27 |
| pitti | mvo: that will trigger exactly those devices which got assigned to that app | 08:28 |
| mvo | pitti: sweet, thanks! | 08:28 |
| mvo | so just "udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=$APPNAME" :) ? | 08:28 |
| mvo | well, without the --dry-run | 08:28 |
| pitti | udevadm trigger --verbose --tag-match=snappy-assign --property-match=SNAPPY_APP=foo | 08:28 |
| pitti | mvo: right | 08:28 |
| mvo | pitti: \o/ | 08:29 |
| mvo | pitti: about the deny-all, will you look into this or should I do that once I finished the change above? | 08:29 |
| pitti | mvo: I'm looking into it | 08:29 |
| pitti | mvo: did you get the other fixes? | 08:29 |
| mvo | thanks! | 08:29 |
| mvo | pitti: some changes, nothing major, r32 is my latest version | 08:30 |
| mvo | pitti: I was working on a example snap, the go code and a end-to-end test | 08:30 |
| pitti | mvo: ah, I see you merged my stuff, good | 08:30 |
| mvo | pitti: yes, thank you very much for this! | 08:31 |
| pitti | $ echo > /dev/null | 08:41 |
| pitti | bash: /dev/null: Operation not permitted | 08:41 |
| pitti | mvo: ^ I took /dev/null out of the static list, and now get that | 08:41 |
| pitti | mvo: IOW, it's all good | 08:41 |
| pitti | mvo: just wanted to double-check | 08:41 |
| mvo | pitti: \\\o/// | 08:41 |
| mvo | (spide hug ;) | 08:41 |
| mvo | spider even | 08:41 |
| pitti | mvo: you have *that* many arms? you scare me! | 08:41 |
| * mvo hates jetlag | 08:41 | |
| mvo | and not even enough arms for a spider - oh well! | 08:42 |
| * mvo drops into koma | 08:42 | |
| asac | spider hug is nice ;) | 08:45 |
| * asac wonder if i heard that expression before | 08:45 | |
| mvo | probably not, its my jetlag speaking ;) | 08:46 |
| JamesTait | Good morning all; happy Monday, and happy Chinese Language Day! :-D | 09:08 |
| mvo | 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:27 |
| Chipaca | mvo: hardware is another kind of snap? | 09:28 |
| mvo | fwiw, thats the only open question otherwise I think all the bits for hardware assign from a oem snap are ready | 09:28 |
| pitti | mvo: ah, I didn't check -- did you happen to have the time to upload those fixes for the failed two units? | 09:28 |
| pitti | mvo: if not, where could I commit these changes? | 09:29 |
| Chipaca | mvo: or is it part of the oem kind? | 09:29 |
| mvo | pitti: I did, but it seems like its still broken because our pathes are writable only later | 09:29 |
| mvo | pitti: i.e. the seed path is RO when systemd needs it and only made writable later | 09:29 |
| pitti | mvo: ah, ok; that should be in devel-proposed? | 09:29 |
| Chipaca | mvo: if part of the oem, i think sergio was going to make them namespaceless | 09:29 |
| pitti | mvo: the tmpfiles.d thing ought to work now? | 09:29 |
| mvo | pitti: yes the path is writable but I think its too late | 09:29 |
| mvo | pitti: I think so, the only missing one was the random seed | 09:30 |
| pitti | mvo: ok, so that sounds like another one which we move to the initramfs, or we just mask the service entirely | 09:30 |
| mvo | 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 |
| mvo | asac: -^ thats right, right? | 09:30 |
| asac | right | 09:31 |
| mvo | 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 |
| asac | mvo: its not app id | 09:31 |
| asac | its part id | 09:31 |
| asac | can be any part ;) | 09:31 |
| asac | framework, app | 09:31 |
| asac | ubuntu-core maybe even | 09:31 |
| asac | (though the latter for sure not right now) | 09:32 |
| mvo | asac: ups, I can rename that, no problem | 09:32 |
| pitti | mvo: hm, that fix isn't in devel-proposed yet apparently (just flashed a fresh image) | 09:32 |
| mvo | pitti: let me check | 09:32 |
| mvo | 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:33 |
| * mvo tests | 09:34 | |
| pitti | mvo: I mean /var/lib/machines/ is missing as well, tmpfiles is failing | 09:36 |
| mvo | 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 |
| Chipaca | lool: you around? | 09:36 |
| mvo | pitti: I have that dir in r404 | 09:37 |
| mvo | pitti: what is your image id? | 09:37 |
| pitti | mvo: *brown paperbag* | 09:37 |
| pitti | mvo: no, I never forget to actually give a --channel option! | 09:37 |
| asac | mvo: hmm | 09:38 |
| pitti | mvo: image 404, nice! and it found it :) | 09:38 |
| mvo | pitti: :) no worries | 09:38 |
| asac | mvo: i think built-in field in oem snap allows both? | 09:38 |
| mvo | pitti: hahahahaha | 09:38 |
| asac | 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 |
| asac | if namespace is given, it obviously uses that | 09:40 |
| asac | if oem gives access to a part not even installed then thats a fail | 09:41 |
| pitti | mvo: ah, /var/lib/systemd/random-seed doesn't exist at all, I figure that might be a problem as well | 09:41 |
| asac | e.g. dont allow assigning hardware tos tauff that isnt getting installed in oemn | 09:41 |
| * asac also feels the jet | 09:41 | |
| pitti | mvo: merely touching the file is enough | 09:43 |
| pitti | mvo: then it actually gets mounted (that fails for nonexisting files), and now systemctl --failed is empty \o/ | 09:43 |
| mvo | pitti: nice | 09:44 |
| mvo | 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:46 |
| asac | mvo: ack .... lets just document it cleany | 09:49 |
| mvo | asac: cool, I will do that | 09:49 |
| Chipaca | mvo: about 'go remove pkg' only removing the active one, should purge do the same? | 09:57 |
| Chipaca | mvo: there is common code there i could factor out in a branch and make it behave like that, if so :) | 09:57 |
| mvo | 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 |
| Chipaca | i might put one of my cards back from 'in progress' to 'must do' and pick up that one, if asac can confirm | 10:06 |
| mvo | Chipaca: ok | 10:07 |
| asac | Chipaca: whats the question? | 10:07 |
| mvo | asac: Chipaca> mvo: about 'go remove pkg' only removing the active one, should purge do the same? | 10:07 |
| Chipaca | 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:07 |
| mvo | heh .) | 10:08 |
| asac | same behaviour | 10:08 |
| asac | whether its correct as is i dont know :) | 10:08 |
| asac | but lets stick to what we have (sound reasonable without thinking too hard) | 10:08 |
| Chipaca | asac: there's a card to change what we have slightly | 10:10 |
| Chipaca | asac: and what we have right now is slightly different behaviour for remove and purge | 10:10 |
| Chipaca | asac: so we should at least make them the same :) | 10:10 |
| Chipaca | asac: and while i'm at it, we can choose what 'the same' means :D | 10:10 |
| asac | Chipaca: what options do we have? | 10:12 |
| Chipaca | asac: if you have foo.canonical and foo.asac installed, should 'remove foo' remove both of them, or only the active one? | 10:13 |
| asac | 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 |
| asac | but might be wrong | 10:14 |
| asac | Chipaca: how does the world in snappy list look like? | 10:15 |
| asac | and snappy search | 10:15 |
| asac | i think those might give some guidance | 10:15 |
| asac | if you could paste those for both scenarios | 10:15 |
| Chipaca | asac: "snappy list" always shows the namespace | 10:17 |
| Chipaca | snappy search does not, if it's got an alias | 10:17 |
| Chipaca | snappy search seems to be missing the option to show all forks -- i thought we'd done that? | 10:20 |
| * Chipaca is confused | 10:20 | |
| mvo | Chipaca: I have that on image r404 amd64 | 10:21 |
| mvo | Chipaca: http://paste.ubuntu.com/10855388/ | 10:21 |
| Chipaca | asac: current output of search vs list: http://pastebin.ubuntu.com/10855402/ | 10:23 |
| Chipaca | mvo: yes, not sure why my snappy was an old one -- i'd probably been testing things for an old branch on there | 10:25 |
| mvo | no worries | 10:37 |
| mvo | good to raise it in case there are lurking issues :) | 10:37 |
| asac | any idwea what this 8nzc1x4iim2xj1g2ul64 43 Returns for store credit only. is ? | 10:47 |
| asac | Chipaca: ? | 10:47 |
| Chipaca | asac: a package | 10:48 |
| Chipaca | asac: it's called “Returns for store credit only.” | 10:48 |
| Chipaca | asac: the package name is 8nzc1x4iim2xj1g2ul64 | 10:48 |
| asac | why do we see that when searching for hello-world? | 10:49 |
| Chipaca | asac: i don't know. possibly because the icon is called 'hello.svg'? but i'm not certain | 10:50 |
| Chipaca | asac: elastic search question | 10:50 |
| asac | beuno: ^ is that a good package? | 10:50 |
| beuno | asac, Chipaca uploaded it! :) | 10:50 |
| Chipaca | that i did! :) | 10:50 |
| Chipaca | and it's very good. washes my dishes and everything. | 10:50 |
| asac | Chipaca: ok, as long as that is not a bug :) | 10:51 |
| Chipaca | indexing the icon filename might be a bug, but i'm not sure we can control that :) | 10:51 |
| Chipaca | beuno: ? | 10:51 |
| beuno | let me see why it matches | 10:51 |
| asac | Chipaca: what does that package do? | 10:51 |
| Chipaca | asac: uh... i think it's just 'hello world', renamed to something unique for testing purposes | 10:52 |
| asac | ic | 10:52 |
| Chipaca | asac: i wanted something i could be more or less sure nobody would find by accident | 10:52 |
| beuno | (this is why Chipaca should never be allowed to name things) | 10:52 |
| Chipaca | of course it turning up when looking for hello world defeats that :) | 10:52 |
| Chipaca | beuno: hey, only *one* of my kids has a completely unpronounceable name! | 10:53 |
| Chipaca | (for the brits, at least) | 10:53 |
| beuno | Chipaca, the package description is "This is a simple hello world example." | 10:53 |
| Chipaca | beuno: oops :) | 10:53 |
| Chipaca | i guess i'll have to upload a new version that fixes that | 10:53 |
| beuno | so ES is expecting an apologyu | 10:53 |
| asac | Chipaca: i could imagine remove|purge --active|--inactive ... and otherwise remove all that are there | 10:54 |
| Chipaca | beuno: good thing software is patient | 10:54 |
| asac | 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 |
| mvo | 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:55 |
| Chipaca | mvo: ^^ asac on remove removing everything by default | 10:56 |
| asac | 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 |
| mvo | 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:00 |
| * mvo gets lunch | 11:01 | |
| pitti | mvo: oh! | 11:01 |
| pitti | mvo: of course, that can't work | 11:01 |
| pitti | 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 |
| pitti | mvo: which is why your trigger didn't list any devices | 11:02 |
| pitti | mvo: so yeah, do a full trigger for now | 11:02 |
| ogra_ | and a "udevadm settle" to make sure you dont add races ;) | 11:02 |
| pitti | no, not necessary | 11:03 |
| pitti | well, maye for apps which need to access the hardware right away, so it's indeed better, yes | 11:03 |
| ogra_ | well, i always find that safer ... | 11:03 |
| mvo | pitti: thanks, will do | 11:04 |
| pitti | ogra_: right | 11:04 |
| ogra_ | (if you have some late processed rule that mangles the device again or some such ...) | 11:04 |
| === kickinz1|afk is now known as kickinz1 | ||
| asac | Chipaca: http://paste.ubuntu.com/10855615/ | 11:20 |
| asac | that one is a bit unhappy on snappy list | 11:20 |
| Chipaca | asac: ? | 11:21 |
| asac | Chipaca: see the paste | 11:21 |
| asac | snappy list isnt doing anything | 11:21 |
| Chipaca | asac: did you install anything? | 11:21 |
| asac | all other commands are also unhappy | 11:21 |
| asac | Chipaca: nope | 11:21 |
| asac | Chipaca: see the ls /apps/ | 11:21 |
| asac | fresh install of the image as in paste | 11:21 |
| asac | version version: 234 | 11:21 |
| asac | using beagleblack.canonical fwiw | 11:22 |
| Chipaca | asac: ok, i'll look into it in a bit | 11:22 |
| asac | Chipaca: sudo ubuntu-device-flash core --oem beagleblack.canonical --channel edge --output mysnappy-arm.img | 11:22 |
| asac | thats how i produdced it | 11:22 |
| Chipaca | thanks | 11:22 |
| * Chipaca gets some coffee | 11:24 | |
| asac | Chipaca: reproducible on amd64 kvm with sudo ubuntu-device-flash core --oem amd64.canonical --channel edge --output my-snappy.img | 11:25 |
| asac | guess that is quuicker to debug :) | 11:25 |
| asac | guess its the oem snap that makes snappy unhappy | 11:26 |
| * Chipaca builds | 11:28 | |
| mvo | 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 |
| mvo | asac: -^ first successful end-to-end :-D | 11:37 |
| asac | \o/ | 11:41 |
| asac | very good | 11:41 |
| asac | i guess with that ogra can write his heating appliance finally :) | 11:44 |
| asac | and start selling it :) | 11:44 |
| ogra_ | lol | 11:45 |
| ogra_ | i still have the prob that snappy cant properly handle the config in case of that app | 11:45 |
| lool | Chipaca: i'm around, what's up? | 11:51 |
| asac | ogra_: not sure what you mean | 11:52 |
| asac | what config? | 11:52 |
| Chipaca | 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 |
| asac | 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:52 |
| lool | Chipaca: less than 5 seconds | 11:53 |
| asac | which should be pretty snappy :) | 11:53 |
| asac | not suure if 5 seconds | 11:53 |
| lool | Chipaca: is 5 seconds too long for your use case? | 11:53 |
| asac | but not too far longer\ | 11:53 |
| lool | if it needs more than 5 seconds, then we shoudl have an API for it | 11:53 |
| Chipaca | lool: there was a stop-timeout, capped at 90 seconds*, but this is not that | 11:53 |
| lool | but the default should be less than 5 seconds | 11:53 |
| Chipaca | um, asac^ | 11:53 |
| mvo | heh :) I suggested 15s, Chipaca went with 2s | 11:53 |
| lool | 2s is a bit aggressive for a busy system shutting everything down | 11:54 |
| Chipaca | lool: I had it at 2 seconds, but mvo points out that a python process on bbb takes that long to start :) | 11:54 |
| ogra_ | 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 |
| mvo | yeah, I don't really mind, afterall there was a stop command before that already hit a timeout | 11:54 |
| ogra_ | we dont have any way to handle that scenario | 11:54 |
| ogra_ | apart from me writing higly complicated merge tools | 11:54 |
| lool | so basically we should leave processes enough time that they can save simple state, but not unload megabytes of data | 11:54 |
| Chipaca | mvo: note my ping to lool precedes my commit (and your review) :) | 11:55 |
| lool | if they need to finish a long running job, or request more time, they need an API to express that | 11:55 |
| lool | since we dont have that API for now, I'd rather we be conservative and leave it a bit longer for now | 11:55 |
| Chipaca | 5 seconds is fine, i think | 11:55 |
| lool | typically on the desktop you could do things like prompt the user, or show that some processes are still saving | 11:55 |
| lool | Chipaca: yup | 11:55 |
| lool | I believe it's also the shutdown timeout that sysv used years back :-) | 11:56 |
| Chipaca | this reminds me. pitti: https://twitter.com/SwiftOnSecurity/status/589981229895659520 | 11:57 |
| plorenz | 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:57 |
| mvo | yeah, 5s works for me, thanks! | 11:58 |
| Chipaca | plorenz: you wrote an apparmor file? | 11:58 |
| Chipaca | plorenz: initially? or was that because of the aa-exec error? | 11:58 |
| plorenz | Chipaca: i didn't initially - i just tried to solve that error ;) | 11:59 |
| Chipaca | ah :) | 11:59 |
| Chipaca | plorenz: that error looks a lot like an error we got while we were breaking things | 11:59 |
| Chipaca | plorenz: maybe you're running a broken image? | 11:59 |
| plorenz | Chipaca: could be, i'm running the raspberry pi image by lool from 15th april | 12:00 |
| Chipaca | mmmhmm | 12:00 |
| Chipaca | yah, that's probably got a broken snappy | 12:00 |
| lool | hmm really | 12:00 |
| plorenz | oh :/ is there a way to patch it? | 12:00 |
| Chipaca | plorenz: want to update the system? then you get new, more exciting broken bits :-p | 12:00 |
| lool | that's odd, we tested high level things liek docker on it | 12:01 |
| Chipaca | lool: oh? interesting | 12:01 |
| Chipaca | maybe i'm jumping to conclusions | 12:01 |
| lool | I need to finish a couple of things then I'll try a simple snap on rpi | 12:01 |
| Chipaca | plorenz: what are you doing when you get that error? | 12:01 |
| plorenz | lool: thank you :) docker runs fine, also webdm | 12:01 |
| lool | plorenz: perhaps tried an unmodified hello world; there might be a trivial typo that is causing a confusing error message | 12:02 |
| lool | right, so other snaps get a profile | 12:02 |
| plorenz | 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 |
| lool | 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 |
| lool | plorenz: I wonder if it's the underscore | 12:02 |
| lool | plorenz: try with - | 12:02 |
| lool | (that would be a bug we should catch, but wouldn't surprize me) | 12:02 |
| plorenz | let me try that | 12:03 |
| Chipaca | hmm, is _ valid in a binary? | 12:03 |
| Chipaca | nope | 12:03 |
| Chipaca | needs to match [a-zA-Z0-9+.-] | 12:03 |
| mvo | its not right now, we might relax the rules, they are rather strict right now | 12:04 |
| plorenz | oh okay - "snappy build" doesn't give me an error | 12:04 |
| Chipaca | mvo: apparmor uses _ as a separator, afaik | 12:04 |
| Chipaca | so we might need to pay more attention to some of the name mangling if we want it to be valid | 12:04 |
| Chipaca | asac: for i in /oem/*; do mv $i $i.canonical; done will fix your image | 12:05 |
| Chipaca | asac: it is indeed a problem with oem not having a namespace | 12:06 |
| Chipaca | sergiusens: ^ | 12:06 |
| plorenz | aah now it's running :) thanks a bunch! | 12:06 |
| Chipaca | plorenz: you probably don't have the review tools installed, which are the ones that would have told you about that normally | 12:07 |
| plorenz | Chipaca: how can i install them? | 12:08 |
| Chipaca | 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:08 |
| Chipaca | plorenz: click-reviewers-tool | 12:09 |
| Chipaca | plorenz: click-reviewers-tools, actually | 12:09 |
| plorenz | Chipaca: nice, it works :) thanks, and you're all doing a great job by the way! | 12:11 |
| Chipaca | plorenz: \o/ | 12:12 |
| asac | Chipaca: ok... thast odd, because i used beagleblack.canonical | 12:15 |
| asac | so lets wait for serge | 12:15 |
| Chipaca | asac: but if you look in /oem/ you'll see beagleblack, i expect | 12:15 |
| Chipaca | 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 |
| Chipaca | I must say, sleeping 12 hours does wonders for one's comprehension of stuff | 12:16 |
| mvo | Chipaca: could you give me a short summary of the problem or is it under control :) ? | 12:18 |
| Chipaca | mvo: snappy quits if it finds a namespaceless snap where it expects a namespaceful one | 12:18 |
| Chipaca | mvo: currently it expects oem snaps to be namespaceful | 12:18 |
| Chipaca | mvo: snappy quits | 12:18 |
| Chipaca | mvo: </summary> | 12:19 |
| mvo | thanks, makes sense | 12:19 |
| Chipaca | mvo: we need to either make oem snaps install themselves with a namespace, or make snappy treat them as frameworks wrt namespaces | 12:19 |
| Chipaca | mvo: or something in between :) but right now they're broken | 12:20 |
| Chipaca | are forks of oem snaps expected? | 12:20 |
| mvo | Chipaca: yeah, I am slightly leaning towards option (2) but lets wait for sergiusens and his input | 12:20 |
| Chipaca | i think sergio was too | 12:20 |
| mvo | asac: -^-^ | 12:20 |
| mvo | I have some stuff for review in he meantime ;) | 12:21 |
| Chipaca | maybe :-p | 12:21 |
| mvo | (and gave feedback) | 12:21 |
| * Chipaca looks | 12:21 | |
| asac | i dont know | 12:21 |
| asac | i would have thought that in /apps/ frameworks also have namespaces | 12:21 |
| Chipaca | mvo: i looked at your udev branch, and left it for somebody who actually knows udev | 12:21 |
| asac | just that the binaries dont | 12:21 |
| mvo | Chipaca: hahaha, so pitti needs to review it? thats fine :P | 12:21 |
| asac | i feel we should avoid special casing namespace behaviour for new things | 12:21 |
| Chipaca | mvo: the go code is good :) | 12:22 |
| asac | but leave it to you guys | 12:22 |
| Chipaca | asac: having namespaces in the files and directories impacts apparmor and such | 12:22 |
| Chipaca | asac: hence why it's out | 12:22 |
| pitti | mvo, Chipaca: please request a review from me, so that I'll get a mail | 12:22 |
| mvo | Chipaca: would you prefer both branches reviewed by a udev guy? or only the one that writes the rules? | 12:23 |
| Chipaca | asac: we had frameworks with namespaces but apparmor was all sad and aa-exec complained | 12:23 |
| Chipaca | mvo: i'm only just looking at the other one :) | 12:23 |
| mvo | ok, shout if I should ask for a additional reviewer for that :) | 12:23 |
| mvo | and thanks! | 12:23 |
| mvo | pitti: done, mail is out | 12:23 |
| Chipaca | mvo: do you need to cd to .Path as well as give u-c-l .Path as its first arg? | 12:24 |
| asac | Chipaca: ok. guess too late, but thought jdstrand said he could fix those namespace probs for frames | 12:28 |
| Chipaca | asac: the other option we had was to create symlinks | 12:29 |
| Chipaca | asac: which would've been worse, i think | 12:29 |
| mvo | Chipaca: probably not, I think we should kill the CD and the path too, I can simplify stuff | 12:34 |
| Chipaca | mvo: otoh it's closer to what will be done for them for services, with WorkingDirectory | 12:35 |
| asac | Chipaca: sure. if jdstrand couldnt do it cleanly then go for that thing for release | 12:35 |
| mvo | Chipaca: hm, good point, so I just kill it from the launcher for now | 12:35 |
| Chipaca | mvo: some things inline | 12:44 |
| mvo | Chipaca: I pushed the simplification now, thanks again (just omiting the baseDir in the launcher as first argument) | 12:44 |
| mvo | Chipaca: thanks, I check that out now | 12:44 |
| Chipaca | mvo: i see you missed the same thing i missed, wrt purge (and datadirs) | 12:52 |
| Chipaca | mvo: package.yaml is not in the data dirs ;) | 12:52 |
| Chipaca | mvo: and if you want to purge things that have been removed, looking for the package.yaml is not going to help | 12:52 |
| dholbach | asac, kirkland, lool, slangasek: I sent you a mail about UOS planning - it'd be good if you could respond soon | 12:53 |
| Chipaca | i guess i should put a comment there | 12:53 |
| mvo | Chipaca: yeah, please do , maybe my poor jetlag brain will see it then :) | 12:53 |
| mvo | 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:55 |
| kickinz1 | testing right now the last image. | 12:56 |
| jdstrand | fyi, we could fix the framework namespaces and make it work with apparmor | 13:03 |
| jdstrand | 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 |
| Chipaca | mvo: good idea wrt making the thing inactive while purging | 13:04 |
| jdstrand | 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:06 |
| pitti | mvo: reviewed | 13:07 |
| jdstrand | 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 |
| mvo | 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 |
| jdstrand | 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:07 |
| jdstrand | asac, Chipaca: ^ (re fwk stuff) | 13:08 |
| mvo | 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 |
| Chipaca | jdstrand: yep, you were quite clear on that; i skipped over that part when telling asac about it all | 13:08 |
| jdstrand | mvo: let me do the code cleanup first, then I can hand it to you | 13:08 |
| Chipaca | jdstrand: sorry :) | 13:08 |
| mvo | jdstrand: ok, either way is fine with me, I don't mind doing a cleanup along the way | 13:09 |
| jdstrand | s/he decided/we decided/ | 13:09 |
| mvo | jdstrand: looks good fwiw from a quick look over it | 13:09 |
| jdstrand | 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 | 13:10 |
| === plars is now known as plars- | ||
| mvo | 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:11 |
| jdstrand | (2. since apps would have to know the framework *namespace* to open(), they would have need...) | 13:12 |
| asac | 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 |
| jdstrand | mvo: I haven't and I want you to take it-- it wasn't ready to be reviewed just yet | 13:12 |
| asac | jdstrand: why does app need to know where framework is on disk? | 13:12 |
| jdstrand | asac: it depends on how the framwork is written. I said *if* a framework exposes a file | 13:13 |
| jdstrand | and people will do it cause that is easy enough to do | 13:13 |
| jdstrand | I literally just came online now-- why are we having this discussion now? | 13:14 |
| Chipaca | jdstrand: probably because we broke snappy on the image if it has an oem installed | 13:15 |
| jdstrand | let's fix that rather than reworking namespaces :) | 13:16 |
| jdstrand | 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:18 |
| jdstrand | and we are making it more difficult for consumers of the frameworks | 13:19 |
| jdstrand | (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:20 |
| jdstrand | I'm of the opinion that the dev experience is paramount and maintain my opinion that frameworks should not be namespaced | 13:22 |
| jdstrand | if we are adding namespace back to the name, I need to know soon so I can update click-apparmor | 13:23 |
| asac | mvo: Chipaca: i assume you guys have fixing regexps etc. for failures of self test in backlog? | 13:47 |
| asac | 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 |
| asac | Can not find '^No package 'fizzler' for ubuntu-core/devel.*' in 'Installing fizzler | 13:47 |
| jdstrand | 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 |
| mvo | jdstrand: no namespaces yet, sorry, if its important I can look into that next though | 13:49 |
| jdstrand | that's ok for now. we should add a trello card/file bug though for post 15.04 | 13:49 |
| tyhicks | jdstrand: sure | 13:59 |
| tyhicks | mvo: can I get a link to the branch? | 13:59 |
| mvo | tyhicks: its here https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk | 14:00 |
| sergiusens | mvo: Chipaca I am finally here! Landed, drove home, slept (not even unpacked); what the executive summary? | 14:00 |
| tyhicks | mvo: thanks! | 14:00 |
| mvo | sergiusens: no catastrophes so far :) | 14:00 |
| mvo | jdstrand: I wonder if http://paste.ubuntu.com/10856229/ would make sense? or is snappy build setting the wrong defaults here? | 14:01 |
| sergiusens | 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:02 |
| jdstrand | mvo: yes-- likely. let me check | 14:07 |
| jdstrand | we have to rework all this with the new world | 14:08 |
| * sergiusens puts on some wake up *faster* music | 14:09 | |
| jdstrand | mvo: is the Architecture field from DEBIAN/manifest used by snappy in any way? | 15:07 |
| mvo | jdstrand: no, 99% sure it does not | 15:07 |
| jdstrand | beuno: can you sync the store with r442? | 15:14 |
| beuno | jdstrand, sure | 15:14 |
| jdstrand | beuno, mvo, jodh (and asac): that ^ should fix the review tools for all warnings/errors for *default* snappy builds, except for hashes.yaml | 15:14 |
| jdstrand | security yaml/other checks are not in there (will pick those and hashes up later this week) | 15:15 |
| jdstrand | this is for 'type: app'. other types will have other issues (but again, will pick up this work later this week) | 15:16 |
| mvo | jdstrand: nice, thanks a bunch | 15:18 |
| jdstrand | dholbach: hey, are you up for uploading click-reviewers-tools based on the r442 branch? | 15:22 |
| dholbach | jdstrand, sure | 15:22 |
| jdstrand | dholbach: thanks! that doesn't have the big changes, but it has important small changes (see backscroll) | 15:23 |
| dholbach | cool - great work everyone | 15:23 |
| mvo | jdstrand: if you could ping me once the cleanup for the seccomp branch is done, that would be great | 15:24 |
| jdstrand | mvo: yes-- it is close. I have one last thing after the meeting) | 15:25 |
| mvo | jdstrand: no rush, I will get dinner and see what I can do after that | 15:25 |
| dholbach | jdstrand, uploaded and accepted :) | 15:30 |
| jdstrand | dholbach: thanks! | 15:33 |
| dholbach | anytime | 15:39 |
| sergiusens | asac: so amd64.canonical -> amd64 is fine? | 15:42 |
| sergiusens | forgot to get the explicit ack | 15:42 |
| asac | sergiusens: amd64-generic.canonical maybe? not sure | 15:42 |
| sergiusens | asac: okie dokie, will re upload then as that | 15:43 |
| asac | we dont use -generic for beagleblacks either | 15:43 |
| asac | PC-amd64.canonical :) | 15:43 |
| asac | :) | 15:43 |
| sergiusens | asac: ok, keep in mind it will be all lower case | 15:43 |
| asac | hmm | 15:43 |
| asac | just more ideas | 15:43 |
| asac | efi-amd64 | 15:43 |
| sergiusens | pc-amd64 or x86-amd64 | 15:43 |
| jdstrand | mvo: have we defined/implemented specifying no caps yet? | 15:44 |
| sergiusens | asac: oh, efi and legacy bios boot options would be implicit according to my discussions last week with slangasek | 15:44 |
| slangasek | they should absolutely not be separate channels/images | 15:45 |
| mvo | jdstrand: that should work if you put "caps: []" there | 15:45 |
| asac | slangasek: what you think about us naming oem snap that defines our amd64 generic base image pc-amd64 ? | 15:45 |
| mvo | jdstrand: I think there is even a test for it, I can search for the branch that implements it, one sec | 15:45 |
| asac | currently its named amd64.canonical :) | 15:45 |
| mvo | jdstrand: I nocited you pushed a new seccomp branch, does that mean I can hack away now ;) ? | 15:46 |
| slangasek | asac: why "pc"? | 15:46 |
| asac | not sure... beuno didnt like it | 15:46 |
| asac | to be just amd64 | 15:46 |
| asac | and the snap name feels weird to me too | 15:46 |
| slangasek | if this is just about the oem snap name and doesn't require me to change anything on the channels, I'm fine with it ;) | 15:47 |
| jdstrand | mvo: yes, though I will have another change or two for the override bits | 15:47 |
| slangasek | but why not 'generic-amd64'? | 15:47 |
| mvo | jdstrand: cool, want to merge my branch that makes the tests pass again? | 15:47 |
| slangasek | generic is nice and generic | 15:47 |
| asac | slangasek: thats cool | 15:47 |
| asac | thanks | 15:47 |
| jdstrand | mvo: yes please | 15:47 |
| jdstrand | mvo: where is that? | 15:47 |
| jdstrand | mvo: this is click_test.go? | 15:47 |
| asac | sergiusens: slangasek is the man from now on to pick those names :) | 15:47 |
| asac | generic-amd64 it is | 15:47 |
| slangasek | heh | 15:47 |
| asac | thing is that there wont be a generic-armhf | 15:48 |
| mvo | jdstrand: lp:~mvo/snappy/snappy.seccomp and there ./run-checks should hopefully work | 15:48 |
| asac | just beagleblack :_) | 15:48 |
| mvo | jdstrand: if not, shout at me :) | 15:48 |
| asac | but tahts fine | 15:48 |
| asac | slangasek: i thought maybe its ibmcompatible :) | 15:48 |
| slangasek | hah | 15:48 |
| asac | but guess thats not the term these days for all those amd64 machines, or is it? | 15:48 |
| mvo | jdstrand: still lacks tests for the new stuff, you can also do "cd snappy && go test" to just run the snappy speciific ones | 15:48 |
| mvo | jdstrand: I also ran your branch on my snappy test system and it worked nicely | 15:48 |
| slangasek | indeed, lots of these things are not very "personal computer" :) | 15:48 |
| mvo | jdstrand: anyway, I get some dinner now and will read scrollback, let me know if there is anything else that I can do, I will try hard to get the branch ready for review this evening so that we are really feature complete and that it all can land | 15:51 |
| plars | sergiusens: can an image be successfully built for BBB now, and if so, what are all the pieces we need? I know you said on friday that the beaglebone.sergiusens one is no longer the one to use? | 15:52 |
| sergiusens | plars: I need to release the udf I worked on during the weekend | 15:53 |
| slangasek | sergiusens: to properly support BIOS+EFI, ./diskimage/core_grub.go needs some concept of the target architecture. How should the interface to this look? | 16:00 |
| sergiusens | slangasek: architecture as in amd64 and armhf or a different layer of the arch concept? | 16:02 |
| sergiusens | slangasek: I can get that going quickly if not needed by today (as in, do it tomorrow) | 16:02 |
| slangasek | sergiusens: should only be amd64 vs. i386 vs. armhf, as far as I know | 16:05 |
| slangasek | I'm assuming the only ARM grub target we're supporting is efi | 16:06 |
| slangasek | oh, and arm64 | 16:06 |
| slangasek | which is definitely efi | 16:06 |
| beuno | jdstrand, review scripts are updated | 16:10 |
| sergiusens | slangasek: k; I can work on this tomorrow; mind creating a card with all the requirements under a checklist so I don't miss anything? | 16:11 |
| slangasek | sergiusens: hey, I wanted to hack on this, you're depriving me of the opportunity ;) | 16:12 |
| slangasek | I was just looking for guidance on where you wanted the architecture exposed in the interface | 16:12 |
| sergiusens | slangasek: ha, this needs some sort of refactor; but if you want to; feel free, just don't lose any hair :-) | 16:12 |
| sergiusens | slangasek: architecture is exposed in the oem structure as oem.Architecture() | 16:13 |
| slangasek | ok | 16:13 |
| sergiusens | but you might get lost with all the backwards compatibility code paths | 16:13 |
| slangasek | :-) | 16:13 |
| jdstrand | beuno: thanks! | 16:23 |
| sergiusens | asac: so I am going with x86-amd64 then for the oem package | 16:25 |
| jdstrand | mvo: ok, branch updated. going to do some more blackbox testing | 16:25 |
| mvo | jdstrand: cool, feel free to prpose for merging if you feel its ready, I will do a followup branch on that with added tests later tonight | 16:40 |
| mvo | jdstrand: this way maybe Chipaca or sergiusens can do a review and we can hopefully build a test image with the feature tonight and I can make the launcher "strict" again (i.e. fail if seccomp policy file can not be found) | 16:41 |
| slangasek | sergiusens: "x86-amd64"? do you mean "x86-64"? | 16:42 |
| slangasek | x86-amd64 is awfully confusing | 16:42 |
| sergiusens | slangasek: ok then | 16:43 |
| jdstrand | mvo: the launcher on the image applies seccomp policies? | 16:43 |
| sergiusens | slangasek: I really don't care; IOW, I just want to make the managers happy :-) | 16:43 |
| mvo | jdstrand: it does, if it finds them | 16:43 |
| slangasek | sergiusens: I thought the managers were already happy with generic-amd64 ;) | 16:43 |
| jdstrand | ah good, that will help me in testing our seccomp policy with existing snaps | 16:43 |
| jdstrand | (which is next on my list) | 16:44 |
| sergiusens | slangasek: heh, asac wasn't as it was inconsistent with beagleblack (no generic word in there) | 16:44 |
| mvo | jdstrand: cool! | 16:44 |
| slangasek | sergiusens: "<asac> but tahts fine" ;) | 16:45 |
| slangasek | sergiusens: anyway, I'm fine with either | 16:45 |
| sergiusens | slangasek: oh, I missed that; so choose which one; last change before I upload ;-) | 16:45 |
| slangasek | sergiusens: whichever one is quicker to implement! | 16:45 |
| slangasek | ;P | 16:45 |
| sergiusens | slangasek: lol, it's just a string | 16:45 |
| mvo | jdstrand: keep me updated, I will be a bit on-and-off in irc in the next ~1h or so | 16:45 |
| mvo | but will read scrollback | 16:46 |
| jdstrand | mvo: ok, I proposed a merge | 16:46 |
| mvo | ta | 16:46 |
| jdstrand | mvo: thanks for your help on this :) | 16:46 |
| sergiusens | mvo: btw, I fixed the error message for installing inexistent packages and removed the channel part as it was conceptually wrong (the channel is per package, not the system one) | 16:48 |
| jdstrand | oh shoot a conflict | 16:48 |
| * jdstrand fixes | 16:48 | |
| sergiusens | jdstrand: yay, nice to see one less warning :-) https://myapps.developer.ubuntu.com/dev/click-apps/2407/automated-review/ | 16:53 |
| sergiusens | jdstrand: mind to review btw :-D | 16:53 |
| jdstrand | done | 16:54 |
| jdstrand | mvo: ok, merge with trunk and conflicts resolved. there is one new test failure in purge_test.go that I left | 16:55 |
| jdstrand | merged* | 16:55 |
| sergiusens | beuno: alias for generic-amd64(.canonical) please? | 16:56 |
| jdstrand | mvo: I'm moving on to policy testing now (unless I get feedback from others on the branch) | 16:56 |
| mvo | jdstrand: ok, I take care of that, we can't (tarmac prevents that) merge with test failures, but no worries | 16:56 |
| beuno | sergiusens, can you ask nessita instead, otp for a while | 16:57 |
| sergiusens | beuno: sure, not sure who is able to do this still :-P | 16:57 |
| beuno | sergiusens, it's a state secret | 16:57 |
| sergiusens | lol | 16:58 |
| tyhicks | jdstrand, mvo: the snappy launcher review is just a general security team review or is it for a MIR? | 17:22 |
| jdstrand | tyhicks: both really | 17:22 |
| mvo | tyhicks: I'm not sure what the difference is, but the seeds will probably pull it into main. how is it looking so far? | 17:23 |
| tyhicks | mvo: sorry, just getting to it now | 17:23 |
| mvo | tyhicks: no problem, I'm just curious :) | 17:23 |
| jdstrand | tyhicks: this is sensitive code, so the MIR would need a security team review. we want to give it extra special review. whoever does the MIR can say that the security team already reviewed it and signed off | 17:24 |
| tyhicks | jdstrand: ack | 17:25 |
| nessita | hello all | 17:25 |
| jdstrand | tyhicks: the MIR review is 'can we maintain it?'. this is more than that | 17:29 |
| tyhicks | right | 17:29 |
| asac | sergiusens: slangasek: i guess we will get feedback on the naming decision one way another later | 17:43 |
| asac | e.g. loets go with what steve said | 17:43 |
| beuno | asac, already being done | 17:44 |
| tyhicks | mvo: should your launcher build tests pass during a build in an amd64 schroot? | 18:02 |
| tyhicks | mvo: the test_restrictions test fails for me: http://paste.ubuntu.com/10857373/ | 18:03 |
| mvo | tyhicks: let me try that in a schroot | 18:05 |
| tyhicks | (vivid-amd64 host and vivid-amd64 schroot) | 18:06 |
| mvo | tyhicks: do you see anything special in dmesg? | 18:07 |
| mvo | tyhicks: just tested on a trusty-schroot and it works here, but I had to install the build-depends, let me create a vivid-schroot | 18:08 |
| tyhicks | mvo: I don't see anything special in dmesg | 18:08 |
| mvo | tyhicks: what personality did you use for the schroot? | 18:09 |
| tyhicks | mvo: it is a slightly one-off schroot profile that the security team uses | 18:10 |
| tyhicks | mvo: if it builds for you in your vivid-schroot, I'll chase down my local issues | 18:11 |
| mvo | tyhicks: ok, I will try with one of the default ones, maybe you guys block something seccomp releated? the test just creates a empty profile, loads the seccomp filter and runs /bin/true and checks that it got killed | 18:11 |
| tyhicks | yeah - I was surprised that it didn't work | 18:12 |
| mvo | tyhicks: it works here with the desktop profile, I can try harder later once I finished my other work with a different profile | 18:21 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| tyhicks | mvo: no worries - I'll sort it out on my end | 18:23 |
| tyhicks | mvo: sorry for the distraction | 18:23 |
| mvo | no worries, I am super thankful for this review | 18:23 |
| === rickspencer3_ is now known as rickspencer3 | ||
| jdstrand | mvo: r404 on amd64 doesn't seem to have the launcher-- or if it does, I may be doing something wrong | 18:38 |
| jdstrand | mvo: /apps/bin/... still has aa-exec. I don't see an ubuntu-core-launcher package on the image | 18:38 |
| plars | ogra_: around? I'm still having weird issues with booting the beaglebone and wondering if you can help | 18:40 |
| mvo | jdstrand: yeah, sorry that has not landed, you can sudo /usr/bin/apt-get install ubuntu-core-launcher to get it and copy a new snappy manually or wait ~1-2h and I will try to get a new image out with seccomp | 18:41 |
| ogra_ | plars, i havent touched my bone in months ... | 18:41 |
| ogra_ | plars, bu i can try indeed :) | 18:42 |
| jdstrand | mvo: ack, thanks. I think there may be a bug in framework policy install that I'll try to track down for the moment | 18:42 |
| plars | ogra_: I'm just trying to sort out how to make it boot to the emmc when I have a snappy sd in the sd card slot | 18:43 |
| plars | ogra_: my understanding was that it *should* do that by default when you don't press the boot select button, but it appears to scan the sd card and boot to the sd by default | 18:43 |
| plars | ogra_: I've at least sorted out how to force it to boot to the SD when I hold the boot select button (as it should), but I need it to be selected based on that button ideally - so that we can keep a stable image on emmc and use it to flash a new snappy image on the sd, then force it to boot into sd | 18:44 |
| ogra_ | plars, you can forceit to SD by zeroing the first few bytes of the MMC | 18:45 |
| plars | ogra_: so is that where it's finding uboot? on those inaccessible partitions of the emmc? | 18:46 |
| plars | ogra_: I can force it to the sd just fine now, my problem is the opposite - I would like it to boot to the emmc by default unless I'm holding the s2 button | 18:46 |
| plars | so... ignore the sd card in the slot unless I press the button | 18:47 |
| plars | I think I could do it if I could modify the uboot environment, but there is no saveenv when I boot from the emmc. And any changes I make when booting the sd card and run saveenv, don't show up when I boot from emmc | 18:47 |
| ogra_ | plars, i have never done much with the bone ... only up to XM ... i got my first BBB when i strted doing stuff on snappy | 18:48 |
| ogra_ | plars, i suspect #beagle would be a better source of info, i dont knowmuch about the HW specifics | 18:48 |
| plars | ogra_: ack, thanks | 18:48 |
| ogra_ | (i.e. the zeroing of the MMC is the actual only BBB specific thing i know :) ) | 18:49 |
| mvo | jdstrand: fwiw, I removed all caps from hello-world, so no networkig there anymore and thats also a good example how to do it | 19:56 |
| jdstrand | mvo: cool, I tried [] here too and it worked fine | 19:57 |
| mvo | Chipaca: please let me know if there is anything else that the seccomp branch needs | 19:59 |
| Chipaca | mvo: i've not been able to look at it yet; got a long phonecall | 20:00 |
| Chipaca | am off of it now though :) | 20:00 |
| mcaley | mcaley here from GE Firstbuild… I’ve been working with kirkland and a few others to get snappy running to control a GE fridge from a pi. ive got the snap all working fine, now ready to put pi in the actual fridge. that means replacing hardwire connection with wifi. is there a correct way of doing rootfs stuff? I have seen several posts about remounting system_a r/w and loading the deb packages, but then I’ll have | 20:05 |
| mcaley | redo if it do a system update. i am running ubuntu-core 4. | 20:05 |
| AppleCIDR | Is Node.js available for Snappy Core? I can't find much information on it | 20:07 |
| ogra_ | AppleCIDR, https://ograblog.wordpress.com/2015/02/21/meet-node-snapper-a-helper-to-easily-create-snap-packages-of-your-node-js-projects/ | 20:08 |
| AppleCIDR | Fantastic! | 20:08 |
| mcaley | to get going really quick i just pulled my node and tarball as ogra has in his blog from a raspian build | 20:10 |
| ogra_ | yeah, that would surely work too | 20:11 |
| mcaley | ogra_ a couple of us at firstbuild want to build a qemu service for doing snappy builds that is hosted… any plans for somethign like that? | 20:11 |
| ogra_ | unless you need npm ... | 20:11 |
| mcaley | right | 20:11 |
| ogra_ | i dont have any such plans, no :) | 20:11 |
| ogra_ | if you add 24 more hours to the day i might find the time :) | 20:12 |
| mcaley | ok, we may take a stab…. | 20:12 |
| mcaley | :) | 20:12 |
| kirkland | mcaley: howdy! thanks for joining us here! | 20:21 |
| sergiusens | jdstrand: kickinz1 asac: plars http://blog.sergiusens.org/posts/Updates%20in%20snappy%20and%20ubunu-device-flash/ | 20:22 |
| kirkland | asac: lool: hiya! mcaley is looking for some help correctly configuring wifi in a snappy image -- can you point us to any documentation? | 20:23 |
| tyhicks | mvo: can src/overlay.[ch] go away? (the functions defined in that file are not used anywhere) | 20:33 |
| mvo | tyhicks: yes, that can be killed, its cruft right now (we probably will add somehting like this later but not now) | 20:34 |
| tyhicks | mvo: ack - I'll ignore that code | 20:34 |
| asac | mcaley: hey | 20:34 |
| mcaley | ho | 20:34 |
| asac | mcaley: so far we dont have built in wifi config feature; however we have wpasupplicant; | 20:34 |
| asac | mcaley: so if you do a framework you would use that one directly | 20:35 |
| mcaley | ok, np.. just wanted confirmation before i hacked it up | 20:35 |
| asac | right | 20:35 |
| mcaley | thx | 20:35 |
| asac | mcaley: so make your own config mechanism in your app and use ifconfdig up + wpasupplicant + dhclient :) | 20:35 |
| mvo | tyhicks: gone in r28 | 20:35 |
| asac | sergiusens: am i on wrong channel now that i have image 6? | 20:36 |
| asac | or is that rolling/edge rename now 6? | 20:36 |
| asac | on armhf | 20:36 |
| jdstrand | sergiusens: re blog> is 14.10 up to date? | 20:36 |
| asac | sergiusens: so i think with beagleblack oem snap | 20:36 |
| asac | the hostname doesnt work | 20:36 |
| asac | it still tells me @localhost on prompt | 20:36 |
| asac | but i saw in config its beagleboneblack as hostname | 20:37 |
| mvo | asac: hm, jodh worked on this a while ago, does /etc/hostname look correct? | 20:37 |
| asac | no | 20:37 |
| asac | but it looked ok on the previous image i had with beagleboneblack.sergiusens | 20:38 |
| asac | i think it broke in recent oem snap reconfigure | 20:38 |
| mvo | ok, then its something else | 20:38 |
| asac | maybe because of namespace rename | 20:38 |
| asac | (BeagleBoneBlack)ubuntu@localhost:~$ cat /etc/hostname | 20:38 |
| asac | localhost.localdomain | 20:38 |
| asac | hmm | 20:39 |
| asac | nevermind | 20:39 |
| asac | there is no hostname | 20:39 |
| asac | in http://paste.ubuntu.com/10858216/ | 20:39 |
| asac | yay | 20:40 |
| asac | i used ubuntu-core config to change hostname :)( | 20:40 |
| mvo | :) | 20:40 |
| asac | wonder if that persists across reboot | 20:41 |
| asac | http://paste.ubuntu.com/10858231/ | 20:42 |
| asac | sergiusens: how do i use udf to create an image without ubuntu user? guuess thats not supported yet? | 20:42 |
| mvo | it should, there was a bugfix for tihs | 20:42 |
| mvo | the reboot-hostname-persistance | 20:42 |
| mvo | no idea about the other | 20:43 |
| sergiusens | asac: if you do it through snappy config it would persist | 20:47 |
| asac | yeah | 20:48 |
| asac | let me reboot until we have auto reboot | 20:48 |
| asac | ok good hostnames persist across reboot | 20:50 |
| asac | now when there is new iamge i can try with upgrade even | 20:50 |
| * asac goes all-in and installs docker on his beagle | 20:51 | |
| * asac thinks SD cards are not made for big things | 20:51 | |
| asac | good docker seems to be running | 20:52 |
| asac | now i need instructions how to easily try it on arm | 20:52 |
| asac | kickinz1: do you have those ? | 20:52 |
| kickinz1 | asac, sorry, wasn't there. | 21:11 |
| kickinz1 | asac: what do you need? instructions to test docker on arm? | 21:12 |
| asac | kickinz1: how to install and use docker iamge for armhf | 21:14 |
| asac | woudl be nice | 21:14 |
| kickinz1 | You have a bbb with snappy? | 21:14 |
| asac | yep | 21:14 |
| asac | its running | 21:14 |
| asac | i have docker running too | 21:15 |
| asac | docker images | 21:15 |
| asac | REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE | 21:15 |
| kickinz1 | So for some smole tests, you can install docker on snappy then issue 'docker run -it armbuild/ubuntu' | 21:15 |
| kickinz1 | s/smole/smoke/ | 21:15 |
| * asac runs that command | 21:15 | |
| asac | ok itws pulling stuff | 21:15 |
| asac | kickinz1: so hgow do i use that imnage now? | 21:19 |
| * asac is docker illeterate | 21:19 | |
| asac | oh i think i am in it :) | 21:20 |
| asac | root@ed4e2b9bf2ea:/# | 21:20 |
| asac | hehe | 21:20 |
| kickinz1 | asac, if all the download was fine, yes you are in it. | 21:20 |
| * asac runs apt-get update | 21:20 | |
| asac | kickinz1: how can i reuse that container tomorrow? | 21:20 |
| asac | or lets say i log out | 21:20 |
| asac | can i relog-in? | 21:20 |
| kickinz1 | asac: yes, just issue a docker ps -a, you will see the conatiner with a random name and a unique id. | 21:21 |
| asac | kickinz1: is that running after boot? | 21:22 |
| asac | i see it now | 21:22 |
| asac | http://paste.ubuntu.com/10858375/ | 21:22 |
| asac | kickinz1: thats pretty cool | 21:22 |
| asac | however its suspicious | 21:22 |
| asac | hmm | 21:22 |
| asac | not sure why | 21:22 |
| asac | kickinz1: how can i log into that again? | 21:22 |
| mvo | asac: I triggered a new image build, it should contain all the new stuff, hardware assign support, purge support and seccomp launcher support. build for amd64 (r405) should be available in ~20min or so. I need some sleep but testing welcome, I also queued a full build in 30+min or so | 21:22 |
| kickinz1 | asac: yes, random names. | 21:22 |
| mvo | Chipaca: thanks again for your reviews, I get some rest now | 21:23 |
| Chipaca | mvo: rest is good | 21:23 |
| mvo | sergiusens: plesae mail me if you need reviews in my morning (in +7h) | 21:23 |
| * mvo waves | 21:23 | |
| asac | yay | 21:23 |
| asac | i started the container | 21:23 |
| kickinz1 | asac: docker start suspicious_sinoussi | 21:23 |
| asac | and attached | 21:23 |
| asac | success | 21:23 |
| kickinz1 | asac: ok | 21:24 |
| asac | kickinz1: does it always stop when i exit the shell? | 21:24 |
| kickinz1 | asac, yes in interactive mode. | 21:24 |
| asac | kickinz1: nowe that i started it | 21:24 |
| kickinz1 | asac, else you have to make it run a doeamon or a process. | 21:24 |
| asac | and attached will it be stopping again? | 21:24 |
| asac | ok | 21:24 |
| asac | dont woorry | 21:24 |
| asac | as long as i can get into that thing i am happy enough | 21:25 |
| * asac installs git-core in docker | 21:25 | |
| asac | heh | 21:25 |
| kickinz1 | asac: I have also a docker_template snap if you want to try docker containre as a service for snappy that will start at boot time. | 21:25 |
| kickinz1 | asac: http://bazaar.launchpad.net/~kick-d/+junk/docker_template/ | 21:26 |
| sergiusens | Chipaca: https://code.launchpad.net/~sergiusens/snappy/lockDownRemove/+merge/256849 | 21:35 |
| * Chipaca pulls out his big angry button of (-1) disapproval | 21:35 | |
| sergiusens | Chipaca: oops | 21:35 |
| asac | hmm so i am doing a wildcard search | 21:37 |
| asac | and it returns zero hits | 21:37 |
| Chipaca | sergiusens: hmmmm | 21:37 |
| sergiusens | Chipaca: want me to move mvo's changes back to snap.go? | 21:38 |
| Chipaca | wat? | 21:38 |
| sergiusens | Chipaca: then what is the hmm about? | 21:38 |
| asac | http://paste.ubuntu.com/10858447/ | 21:38 |
| asac | is that a problem? | 21:38 |
| asac | Chipaca: sergiusens ? | 21:38 |
| sergiusens | asac: are you on rolling or 15.04 is hello on rolling or 15.04? | 21:39 |
| asac | sergiusens: well i installed docker | 21:39 |
| asac | but search * | 21:39 |
| asac | returns zero | 21:39 |
| asac | too | 21:39 |
| Chipaca | sergiusens: i understand the objective of your branch is to not allow uninstalling preinstalled software | 21:39 |
| Chipaca | asac: pastebin that please | 21:39 |
| asac | sergiusens: http://paste.ubuntu.com/10858450/ | 21:39 |
| asac | Chipaca: http://paste.ubuntu.com/10858450/ | 21:39 |
| Chipaca | ta | 21:39 |
| sergiusens | Chipaca: want me to split it? | 21:40 |
| Chipaca | sergiusens: is that ^ the objective of the branch? | 21:40 |
| sergiusens | Chipaca: in file movement and new feature? | 21:40 |
| asac | how odften do we produce images? | 21:40 |
| sergiusens | Chipaca: yes it is | 21:40 |
| asac | can we increase that to every 1h ? | 21:40 |
| asac | for now? | 21:40 |
| asac | slangasek: ^ | 21:40 |
| Chipaca | sergiusens: what should the behaviour of that be? | 21:40 |
| asac | slangasek: i think for testing would be nice that we get new ones all the time :P | 21:40 |
| sergiusens | Chipaca: if the to be removed file is in built-in it can't be removed | 21:41 |
| Chipaca | sergiusens: that is: your branch lets you remove the software that was preinstalled, as long as you've installed a newer version | 21:41 |
| Chipaca | sergiusens: is that the right behaviour? | 21:41 |
| sergiusens | Chipaca: yeah, similar to the oem package; if you factory reset in the future, the original preinstall will always be there | 21:41 |
| Chipaca | sergiusens: ok | 21:42 |
| Chipaca | asac: you need to tell us how you created the image you're running, and when, and the output of system-image-cli -i would be nice as well | 21:42 |
| sergiusens | asac: I get all this http://paste.ubuntu.com/10858465/ | 21:42 |
| Chipaca | asac: because it's not the first time _today_ you've tinkered with an old/weird image :) | 21:43 |
| slangasek | asac: I'll do that for now; I don't know if that will cause a load problem across the buildds, we'll have to test and find out | 21:43 |
| sergiusens | asac: I did a 15.04 flash fwiw | 21:43 |
| sergiusens | Chipaca: if we need to request the output of s-i-cli we did something wrong with snappy [info|list] ;-) | 21:44 |
| sergiusens | both of those should be enough | 21:45 |
| Chipaca | sergiusens: both of those, or either of those? | 21:45 |
| asac | odd | 21:46 |
| Chipaca | sergiusens: (yes, you have a point, my bad, etc) | 21:46 |
| asac | Chipaca: sergiusens: sudo ubuntu-device-flash core rolling --oem beagleblack --channel edge --output my-snappy.img | 21:46 |
| === kickinz1 is now known as kickinz1|afk | ||
| sergiusens | asac: search only stopped working after installing docker? | 21:52 |
| slangasek | sergiusens: I really have no idea what's going on here, it looks like mastering the image is unreliable. I'm now sure that I've gotten a proper boot partition at least once using revision 160... but most of the time it fails | 21:53 |
| sergiusens | slangasek: show me your fixes; use 162 btw with what I have in the blog post | 21:55 |
| slangasek | sergiusens: this is with *no* changes from me; and I'm using 160 instead of 162 because I wasn't getting it to work with 162; and what blog post? | 21:56 |
| sergiusens | slangasek: or sudo ubuntu-device-flash core rolling --channel edge --output test.img | 21:56 |
| sergiusens | or s/rolling/15.04/ | 21:56 |
| sergiusens | slangasek: http://blog.sergiusens.org/posts/Updates%20in%20snappy%20and%20ubunu-device-flash/ | 21:56 |
| asac | sergiusens: didnt test before | 21:56 |
| asac | sergiusens: i have image 6 accordintg to channel.ini | 21:57 |
| sergiusens | asac: yeah, snappy list and snappy info give you that info | 21:57 |
| asac | channel: ubuntu-core/rolling/edge | 21:57 |
| asac | sergiusens: you say i should try flashing new? | 21:58 |
| asac | to check if its docker? | 21:58 |
| sergiusens | asac: to check if installing a framework breaks the world, yes | 21:58 |
| Chipaca | i have docker installed | 21:58 |
| Chipaca | on amd63 | 21:58 |
| Chipaca | or 64 | 21:58 |
| Chipaca | and it works | 21:58 |
| sergiusens | I'm installing docker now | 21:58 |
| sergiusens | on armhf | 21:58 |
| slangasek | sergiusens: I used this commandline; still the same problem: ubuntu-device-flash --verbose core 15.04 --channel edge -o system-image-test-proposed.img.raw --device generic_amd64 --developer-mode | 21:59 |
| sergiusens | slangasek: so no boot when doing that? Are you bzr bd'ing by any chance? | 22:00 |
| slangasek | sergiusens: yes, it's bzr bd | 22:00 |
| slangasek | sergiusens: and yes, no boot | 22:00 |
| sergiusens | slangasek: not sure if all the dependencies with the versions required are on vivid, can you make sure they match the ones on ppa:snappy-dev/images? | 22:00 |
| sergiusens | slangasek: or maybe try the u-d-f from ppa:snappy-dev/tools and tell me if you see the same | 22:01 |
| slangasek | ok, looking | 22:02 |
| asac | sergiusens: ok let me first try uninstall that | 22:02 |
| sergiusens | Chipaca: asac: installing docker indeed limits the results | 22:02 |
| Chipaca | hoo! | 22:02 |
| sergiusens | http://paste.ubuntu.com/10858541/ | 22:02 |
| sergiusens | Chipaca: I think I know why; if we pass the framework in the store, it might be filtering | 22:03 |
| sergiusens | to the store | 22:03 |
| tyhicks | jdstrand: a regular user will be able to run ubuntu-core-launcher, right? | 22:03 |
| jdstrand | tyhicks: yes | 22:03 |
| slangasek | sergiusens: golang-ar-dev, golang-yaml.v2 are at the same versions in ppa:snappy-dev/image as in vivid. golang-snappy-dev has a newer version in the ppa. So I'll take a look | 22:04 |
| tyhicks | jdstrand: thanks - I'm trying to decide the best way to sanitize the input arguments and wanted to confirm that before I spent too much time on it | 22:04 |
| asac | sergiusens: seems framework break search | 22:05 |
| asac | yes | 22:05 |
| sergiusens | asac: I guess we need to talk to the store guys; not sure if Chipaca is already playing with random queries to verify | 22:06 |
| asac | sergiusens: :) | 22:06 |
| sergiusens | I need to brb | 22:06 |
| asac | sergiusens: http://paste.ubuntu.com/10858559/ | 22:06 |
| asac | on beagle :) | 22:06 |
| asac | ghuess we should really refuse to install a new oem | 22:06 |
| jdstrand | tyhicks: np-- and thanks for looking at that | 22:06 |
| sergiusens | asac: that was working until all the switch work happened ;-) | 22:06 |
| sergiusens | asac: I guess we need to hardden our tests | 22:07 |
| asac | jojo | 22:07 |
| asac | want me to file something? | 22:07 |
| asac | or rather remember :P | 22:07 |
| sergiusens | tbh, I wasn't aware that today was last call and that we had until thursday for polish | 22:07 |
| jdstrand | Chipaca: ok, I figured out my issue. if I have a framework snap that has a binary that references a cap that is shipped by the framework policy of the same snap, then it fails to install | 22:07 |
| asac | sergiusens: :) | 22:07 |
| Chipaca | jdstrand: should that work? | 22:07 |
| asac | its important to last call early!! :P | 22:08 |
| sergiusens | asac: a task will do | 22:08 |
| asac | but not too early | 22:08 |
| sergiusens | asac: not really, then we do things in a hurry and miss stuff ;-) | 22:08 |
| asac | sergiusens: at least we have two days to fix those now | 22:08 |
| asac | better than zero | 22:08 |
| Chipaca | sergiusens: so this is a bug because frameworks should add to the list of results, not substract from it, correct? | 22:08 |
| jdstrand | Chipaca: it wasn't every really discussed, but I noticed with both docker and my test dbus framework that it is very handy | 22:09 |
| slangasek | sergiusens: upgraded golang-snappy-dev; same outcome | 22:09 |
| Chipaca | jdstrand: darn :) | 22:09 |
| jdstrand | Chipaca: let me see if it is just a simple ordering thing. if we unpack the framework policy first we should be ok | 22:09 |
| sergiusens | Chipaca: correct | 22:09 |
| sergiusens | brb | 22:09 |
| * Chipaca ponders dinner | 22:09 | |
| jdstrand | Chipaca: I'm right in this area of the code, so enjoy dinner. if needed, I'll file a bug | 22:10 |
| Chipaca | jdstrand: let me know, if it's just ordering i might sneak it in | 22:10 |
| jdstrand | yep | 22:10 |
| Chipaca | dinner will be quick either way :) | 22:10 |
| jdstrand | heh | 22:10 |
| asac | sergiusens: https://trello.com/c/8E2zsHNV/322-snappy-install-oem-must-fail-cleanly-if-run-on-running-snappy-system | 22:12 |
| asac | added | 22:12 |
| slangasek | sergiusens: so you're saying this command definitely works for you on amd64 with rev 162, and gives you a correct boot partition? 'ubuntu-device-flash --verbose core 15.04 --channel edge -o output.img' | 22:13 |
| * asac tries steves command | 22:13 | |
| asac | sergiusens: that command produces something for me that boots in kvm | 22:15 |
| asac | and is version 8 | 22:15 |
| asac | not 162 | 22:15 |
| asac | slangasek: http://paste.ubuntu.com/10858591/ | 22:16 |
| asac | sergiusens: sorryt .... wanted to highlight steve | 22:16 |
| asac | slangasek: ^ | 22:16 |
| slangasek | asac: rev 162 of ubuntu-device-flash | 22:17 |
| asac | kk using the package ... think udf could really benefit from udf version command :) | 22:19 |
| slangasek | and installing the package from the tools repo, I get this error - what's the fix?: 2015-04-20 22:18:27 ERROR snappy logger.go:199 generic-amd64 failed to install: unpack helper not found, do you have snappy installed in your PATH or GOPATH? | 22:19 |
| asac | 0.20snappy5-0ubuntu1 | 22:19 |
| asac | slangasek: so above i had troublbes because of missing depends of udf on the right snappy thing | 22:19 |
| asac | slangasek: sudo apt-get install ubuntu-snappy-cli | 22:19 |
| slangasek | asac: thanks | 22:20 |
| slangasek | btw, looks like we've inflicted a namespace collision on the archive now; command-not-found wants me to install the 'snappy' package for the snappy command, which is clearly wrong | 22:21 |
| Chipaca | snappy is a media player that gathers the power and flexibility of | 22:22 |
| Chipaca | GStreamer inside the ease of a minimalistic Clutter interface. | 22:22 |
| slangasek | ok, the version from the tools ppa works; and building rev 164 for myself works (at least once, so far) | 22:25 |
| slangasek | make that twice | 22:25 |
| slangasek | and now when I apply my diff, udf works as expected | 22:27 |
| lool | kirkland: wifi will be cmdline only wpasupplicant and such; I didn't set it up myself, but we made sure the low level tools are in the image | 22:44 |
| * Chipaca back | 22:44 | |
| jdstrand | Chipaca: arg, false alarm. I had a bug in my apparmor policy but all I got from snappy was 'exit status 1' so it took me far too long to figure out the issue | 22:53 |
| Chipaca | jdstrand: :( | 22:54 |
| jdstrand | tyhicks: hmm, I just ran ubuntu-core-launcher and it doesn't seem to be doing an aa_change_profile() correctly | 22:58 |
| jdstrand | tyhicks: I'm using what is in the ppa (https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages). let me pull that down and see if it is missing any changes | 22:58 |
| tyhicks | jdstrand: I have only invoked it in order to abuse it and haven't actually tested it in its intended mode | 23:00 |
| tyhicks | jdstrand: it just calls aa_change_onexec(argv[2]) | 23:01 |
| tyhicks | jdstrand: that shouldn't fail if 1) the profile is loaded and 2) argv[2] contains the correct profile name | 23:02 |
| jdstrand | tyhicks: we need to fail if the profile isn't loaded | 23:02 |
| tyhicks | jdstrand: agreed - is that not happening? | 23:03 |
| jdstrand | well, right now things are unconfined | 23:03 |
| jdstrand | but my vm seems weird. let me retry in a new vm | 23:04 |
| tyhicks | jdstrand: oh, I see the problem | 23:05 |
| tyhicks | if (getenv("SNAPPY_LAUNCHER_SKIP_APPARMOR") != NULL) { | 23:05 |
| tyhicks | // set apparmor rules | 23:05 |
| tyhicks | rc = aa_change_onexec(aa_profile); | 23:05 |
| tyhicks | jdstrand: that getenv() conditional is backwards | 23:06 |
| tyhicks | jdstrand: there are some other issues - I'll add that to my list and send out what I have so far before I go eod | 23:08 |
| jdstrand | sudo snappy install hello-world.jdstrand | 23:08 |
| jdstrand | hello-world.evil ; ls -1 /tmp/myevil.txt | 23:08 |
| jdstrand | Hello Evil World! | 23:08 |
| jdstrand | /tmp/myevil.txt | 23:08 |
| jdstrand | tyhicks: that sounds great. mvo went offline, so if you can send an email, that would be perfect | 23:09 |
| tyhicks | jdstrand: ack - that was my plan | 23:09 |
| tyhicks | jdstrand: so, a workaround for now is to set the SNAPPY_LAUNCHER_SKIP_APPARMOR env variable :) | 23:10 |
| sergiusens | slangasek: oh, sorry, forgot to mention the asac incidence | 23:12 |
| asac | guess it helped ;) | 23:13 |
| jdstrand | tyhicks: yep, thanks. I added a trello card for the apparmor issue but said to look at feedback from you | 23:13 |
| sergiusens | asac: yes, I did create a branch to dep on ubunut-snappy-cli now | 23:13 |
| tyhicks | jdstrand: is it ok to set NO_NEW_PRIVS? (it is currently being set but it'll prevent any AA profile transitions) | 23:13 |
| jdstrand | tyhicks: hmm, I had it setting NO_NEW_PRIVS cause I thought it would prevent some attacks. however, if we aren't allowing the seccomp or ptrace syscalls, we likely don't need it | 23:14 |
| tyhicks | jdstrand: I think it is a good thing until we want to start doing profile transitions | 23:15 |
| jdstrand | tyhicks: well, docker does them already | 23:15 |
| tyhicks | jdstrand: hrm... I bet docker won't work with this launcher | 23:15 |
| jdstrand | that is an interesting point. can you add it to your feedback? | 23:16 |
| tyhicks | yes | 23:16 |
| jdstrand | I figured we would use @unrestricted to the seccomp bits, but I'm guessing the cgroup parts will also be a problem | 23:16 |
| jdstrand | s/to the/for the/ | 23:16 |
| jdstrand | ok, I gotta run | 23:16 |
| tyhicks | jdstrand: NO_NEW_PRIVS is only a seccomp thing so it shouldn't affect the cgroup part | 23:17 |
| tyhicks | jdstrand: also, NO_NEW_PRIVS is set after the cgroup setup | 23:17 |
| tyhicks | jdstrand: bye! | 23:17 |
| sergiusens | asac: oh, fwiw, the 162 is the trunk revno :-) | 23:41 |
| asac | sergiusens: yeah ... thinking udf version could have nice info :) | 23:42 |
| Chipaca | raise your hand if you think “Make installing a framework restarting dependent apps services failing revert the installation, restarting dependent apps services” is only marginally less hard to follow than the quagmire of deferred failure handling it engenders | 23:56 |
| * sergiusens raises the hand just from failing to understand the sentence | 23:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!