| jdstrand | we should probably just document how to use the oem config bits and remove hw-assign | 00:04 |
|---|---|---|
| asac | jdstrand: so for me hw-assign is about drafting rules for development | 00:11 |
| asac | you do hw-assign app /dev/null | 00:11 |
| asac | this creates a rule with path=/dev/null :) | 00:11 |
| jdstrand | that was how I saw it too | 00:12 |
| jdstrand | yes, that used to work | 00:12 |
| jdstrand | now with the cgroups and launcher, it doesn't | 00:12 |
| asac | you could also do hw-assign --kernel=ttyS* --with-tag=... | 00:12 |
| asac | this will just create the same rules we havae | 00:12 |
| asac | just "runtime rules | 00:12 |
| asac | :" | 00:12 |
| asac | once you are happy you can dumb them and copy them into your oem config :) | 00:12 |
| jdstrand | right, we'd need to define the cli experience for that | 00:12 |
| asac | jdstrand: sure i am saying this would be mapped into that | 00:12 |
| asac | udev engine | 00:12 |
| * jdstrand nods | 00:13 | |
| jdstrand | right, if we didn't remove hw-assign, we would have to integrate it | 00:13 |
| jdstrand | the trello card currently says update it for cgroups | 00:13 |
| asac | ack | 00:13 |
| asac | think that can be SRU'd the advanced CLI is then future | 00:14 |
| jdstrand | yeah, that sounds fine | 00:14 |
| asac | fine | 00:14 |
| jdstrand | heh | 00:14 |
| asac | jdstrand: so you say that apps have now zero device nodes? | 00:18 |
| jdstrand | no, they have a few | 00:18 |
| asac | wasnt there a default set of nodes that we wanted to assign | 00:18 |
| asac | where can i find that? | 00:18 |
| jdstrand | /dev/null, /dev/full, /dev/zero, etc | 00:18 |
| asac | that list :) | 00:18 |
| jdstrand | it is hardcoded in the launcher | 00:18 |
| jdstrand | let me get the link | 00:18 |
| jdstrand | asac: http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/main.c#L57 | 00:19 |
| asac | jdstrand: ok, did you upload new -security? | 00:23 |
| jdstrand | I am about to | 00:24 |
| jdstrand | it will be a few minutes | 00:24 |
| asac | hmm | 00:26 |
| asac | so the go webserver does not start anymore | 00:26 |
| jdstrand | asac: sudo grep DEN /var/log/syslog ; sudo sc-logresolve /var/log/syslog | 00:28 |
| jdstrand | I can try here | 00:28 |
| asac | Apr 22 00:24:44 localhost kernel: [ 6546.952744] audit: type=1326 audit(1429662284.103:45): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2682 comm="sed" exe="/bin/sed" sig=31 arch=c000003e syscall=137(statfs) compat=0 ip=0x7f9a1d0a4017 code=0x0 | 00:29 |
| asac | jdstrand: statfs | 00:29 |
| jdstrand | ah we added statvfs earlier | 00:29 |
| jdstrand | I'll fix and see if there are any other stat* that we missed | 00:30 |
| asac | jdstrand: so python xckd server also has no port open | 00:30 |
| asac | root 1244 1 0 00:29 ? 00:00:00 /usr/bin/python3 /apps/xkcd-webserver.canonical/0.4/bin/xkcd-webserver | 00:30 |
| asac | it is running though | 00:30 |
| asac | or wait | 00:31 |
| jdstrand | what does logresolve say about that? | 00:31 |
| jdstrand | fyi, the final syscall list hasn't been uploaded yet. tyhicks and I have been reviewing it today | 00:31 |
| asac | its fine | 00:31 |
| asac | python works | 00:32 |
| asac | just didnt have right port forward | 00:32 |
| asac | and was to stupid for lsof | 00:32 |
| jdstrand | which is what I am preparing now. it changes some things around wrt to the networking bits that could have blocked it, but the new upload won't block it | 00:32 |
| jdstrand | ok, good | 00:32 |
| asac | its odd | 00:32 |
| asac | lsof doesnt have a hit on 80\ | 00:32 |
| asac | e.g. no hit on liten | 00:32 |
| asac | LISTEN | 00:32 |
| asac | oha | 00:33 |
| asac | i dont see the LISTEN ports as normal user | 00:33 |
| asac | guess thats a feature? | 00:33 |
| asac | as root i see it | 00:33 |
| jdstrand | that is normal | 00:33 |
| asac | http://paste.ubuntu.com/10864024/ | 00:34 |
| jdstrand | yeah | 00:34 |
| jdstrand | I don't know why otoh, but that is consistent with my experience | 00:34 |
| asac | jdstrand: its not on my normal desktop :) | 00:36 |
| asac | maybe admin group | 00:36 |
| asac | good | 00:36 |
| asac | jdstrand: added statfs and fstatfs to seccomp | 00:36 |
| asac | and now go is running | 00:36 |
| jdstrand | cool | 00:37 |
| asac | slangasek: is there a new image supposed to happen now? | 00:38 |
| asac | iirc it should be about time :) | 00:38 |
| asac | jdstrand: not sure if fstatfs is needed, but saw fstatvfs so thought it makes sense | 00:39 |
| slangasek | asac: next one fires off in 16 minutes | 00:39 |
| asac | jk | 00:39 |
| asac | k | 00:39 |
| jdstrand | asac: it does, there are also statfs64 and fstatfs64 that I am adding | 00:40 |
| asac | right | 00:40 |
| jdstrand | I'm also downloading the latest linux-libc-dev to see if we are missing anything else | 00:41 |
| jdstrand | interesting, a new syscall 'switch_endian' | 00:44 |
| asac | heh | 00:46 |
| asac | guess docker might want to use that later | 00:46 |
| jdstrand | it is something for powerpc | 00:46 |
| asac | sure | 00:46 |
| asac | jdstrand: so i am lost currently how our mir etc. framework can easily be tested without hw-assign | 00:50 |
| jdstrand | asac: it is probably also broken under the launcher | 00:50 |
| asac | jdstrand: you mean if you assign the right devnodes it still doesnt work? | 00:51 |
| jdstrand | because aiui, it uses a hadn-crafted policy | 00:51 |
| asac | jdstrand: well, there are two things... a) policy and b) access to dri devnodes | 00:51 |
| asac | do you know what the policy hacks look like? | 00:52 |
| jdstrand | hw-assign does nothing with udev atm (hence the trello card). the launcher looks at udev to add devices to the cgroups | 00:52 |
| asac | right | 00:52 |
| jdstrand | it may not. I have not seen the branch | 00:52 |
| asac | but we need some cli so folks can test mir | 00:52 |
| asac | without having to put togehter a full appliance | 00:52 |
| asac | jdstrand: where do we put the udev rules? | 00:52 |
| asac | /lib/udev/rules.d/80-snappy-assign.rules | 00:53 |
| jdstrand | but if they use hw-assign, it is broken cause hw-assign and udev don't do anything. if it uses hand-crafted policy, it is broken because nothing tells the launcher to add the devices to the cgroups | 00:53 |
| asac | sure i get that | 00:53 |
| asac | saying that hw-assign should just add new udev rules :) | 00:53 |
| asac | lol | 00:53 |
| jdstrand | yes, it should :) | 00:53 |
| jdstrand | hence the aforementioned trello card :) | 00:54 |
| jdstrand | hehe | 00:54 |
| asac | so | 00:54 |
| jdstrand | anyway, yeah | 00:54 |
| asac | what does a udev rule look like? | 00:54 |
| asac | that just matches the path? | 00:54 |
| jdstrand | so, that is going to be in snappy somewhere | 00:55 |
| jdstrand | I see that http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/snappy-app-dev is a script to add files to the cgroups | 00:55 |
| asac | https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-oem-hardware-snap | 00:56 |
| jdstrand | hw-access could call out to that | 00:56 |
| jdstrand | but, I think that is being removed (no matter, the same functionality could be added to hw-assign | 00:56 |
| asac | well hwassign should add the proper rules imo | 00:57 |
| jdstrand | if hw-assign is going to be persitent, use, it should add the udev rules | 00:57 |
| jdstrand | s/use/yes/ | 00:57 |
| jdstrand | it is probably pretty easy to add come to think of it-- all of it is already in snappy | 00:58 |
| asac | hmm | 00:58 |
| asac | so an oem snap can ship binaries? | 00:58 |
| asac | wow | 00:58 |
| jdstrand | I was not aware of that either | 00:59 |
| * jdstrand jots that down to ask about later | 00:59 | |
| asac | sergiusens: where are our oem snap sources | 01:00 |
| asac | i dont see them in ~snappy-dev | 01:00 |
| asac | jdstrand: ok somethign worrying: http://paste.ubuntu.com/10864146/ | 01:11 |
| asac | hello-world.jdstrand failed to install: exec: "sc-filtergen": executable file not found in $PATH | 01:11 |
| jdstrand | indeed | 01:12 |
| jdstrand | that looks similar to the fs issues I keep talking about | 01:12 |
| asac | ? | 01:12 |
| jdstrand | what does dmesg say? | 01:12 |
| asac | jdstrand: thats when running udf | 01:13 |
| jdstrand | udf | 01:13 |
| asac | dmesg doesnt say much | 01:13 |
| asac | [10770.939947] systemd-udevd[10485]: failed to execute '/tmp/test.sh' '/tmp/test.sh': No such file or directory | 01:13 |
| asac | :) | 01:13 |
| asac | not sure what that is | 01:13 |
| jdstrand | I guess you need to have ubuntu-core-security-utils on your host | 01:13 |
| jdstrand | I'm not sure where you are seeing that | 01:14 |
| jdstrand | on the host or in the guest? | 01:14 |
| asac | hmm. thats not in the ppa it seems | 01:14 |
| asac | jdstrand: on the host | 01:14 |
| asac | when running udf | 01:14 |
| jdstrand | ubuntu-core-security-utils is a part of ubuntu-core-security | 01:14 |
| asac | to produce an image with stuff preinstalled | 01:14 |
| jdstrand | I see | 01:14 |
| jdstrand | so, you should be able to install ubuntu-core-security-utils from vivid | 01:15 |
| asac | i am on trusty though | 01:15 |
| asac | so this has to go into tools ppa's | 01:15 |
| asac | for all supported things | 01:15 |
| asac | and dependency need adding | 01:15 |
| jdstrand | sergiusens: ^ | 01:15 |
| asac | do we need to run this stuff? | 01:16 |
| jdstrand | I've been a little surprised how much need to be on the host for udf | 01:16 |
| asac | i mean those sc-... commands? | 01:16 |
| jdstrand | I don't know | 01:16 |
| asac | jdstrand: i think udf just runs snappy tool | 01:16 |
| jdstrand | I guess it is preinstalling the snap via the host tools | 01:16 |
| asac | right | 01:16 |
| asac | but the apparmor stuff is done on first boot | 01:16 |
| asac | this one should be done similar i gues | 01:16 |
| jdstrand | it seems it would be much safer to use the tools in the image | 01:16 |
| asac | s?? | 01:16 |
| asac | no? | 01:16 |
| asac | well | 01:16 |
| jdstrand | I agree | 01:16 |
| asac | i think its wrong | 01:17 |
| jdstrand | but, we don't have the systemd unit file to do that yet | 01:17 |
| asac | to do what? | 01:17 |
| jdstrand | which was one of the things I mentioned earlier | 01:17 |
| asac | i think appamor is run on first boot, no? | 01:17 |
| jdstrand | apparmor is run on every boot | 01:17 |
| jdstrand | on first boot it will notice that there isn't policy for the snaps | 01:17 |
| asac | hmm. i mean the stuff that you run when package gets installled | 01:18 |
| asac | okk | 01:18 |
| jdstrand | and it will call aa-clickhook and everything is fine. niext time, the policy won't have to be regenerated | 01:18 |
| asac | shouldnt sc do all the same? | 01:18 |
| asac | i thought we would have same semantics | 01:18 |
| jdstrand | seccomp doesn't have that | 01:18 |
| jdstrand | click had that nice quality | 01:18 |
| jdstrand | so we have to reimplement it for seccomp and then again for apparmor when it moves away from click | 01:18 |
| jdstrand | this morning I was talking about updating policy via a unit if the seccomp policy changed | 01:19 |
| jdstrand | that unit would solve this problem too | 01:19 |
| jdstrand | asac: sc and aa should have the same semantics. aa is still implemented as a hook tool. sc is not. aa will be made to not once we clean it up in 15.10 | 01:20 |
| asac | yes, but what i thought you said was that we would follow same approach for sc | 01:21 |
| asac | anyway | 01:21 |
| asac | so now we have to add unit? | 01:21 |
| asac | and figure how to get rid of sc invocation in snappy install? | 01:21 |
| jdstrand | what I said was that we would implement the new approach so we only have one thing to migrate when we drop the click methodology | 01:22 |
| jdstrand | sc is new approach | 01:22 |
| jdstrand | aa is old | 01:22 |
| jdstrand | you still need sc invocation on snappy install so that the policy is in place when a service or binary is started prior to reboot | 01:22 |
| asac | so now we have two approaches... in future never do two approaches | 01:23 |
| asac | always one and then move both over | 01:23 |
| asac | so we need unit | 01:23 |
| asac | and special case in snappy to not run anything if its on host tool | 01:23 |
| asac | not sure how to do that | 01:23 |
| asac | sergiusens: any idea? | 01:24 |
| jdstrand | asac: well, you say the two approaches thing. the reality is that it would have taken as much time to do the old approach for sc as the new, and it seemed silly to do the old only two weeks later to undo it | 01:24 |
| asac | i know, but the new approach makes things more complex | 01:25 |
| asac | so we should have done that | 01:25 |
| jdstrand | not really | 01:25 |
| jdstrand | there is a unit for apparmor | 01:25 |
| jdstrand | it is just a different unit | 01:25 |
| asac | hmm | 01:25 |
| asac | anyway, what needs doing now? | 01:25 |
| asac | we need to fix this for sure somehow | 01:25 |
| jdstrand | I don't think this two approaches thing is something to worry about | 01:25 |
| jdstrand | I will implement the unit as I said I would this morning | 01:26 |
| asac | ok | 01:26 |
| asac | and how to fix snappy tool? | 01:26 |
| jdstrand | I helped with the launcher all day today | 01:26 |
| asac | right | 01:26 |
| jdstrand | that we need serguisens on | 01:26 |
| asac | sergiusens: see above, we need the snappy install not call sc- stuff if run through udf | 01:26 |
| asac | e.g. on host | 01:26 |
| asac | and defer that to the first boot/unit | 01:26 |
| jdstrand | maybe it is as simple as unpacking and not running the tools if doing a preinstall | 01:27 |
| jdstrand | right | 01:27 |
| asac | i dont think they will like just unpacking | 01:27 |
| asac | they were super happy that snappy install was finally able to run on host tool | 01:27 |
| asac | cross | 01:27 |
| jdstrand | that's fine-- just saying, whatever doesn't need the tools | 01:27 |
| asac | i think it does logic | 01:27 |
| asac | the sc tools yes | 01:27 |
| jdstrand | that didn't come out right | 01:28 |
| asac | so we dont want to run the sc- tools if on host | 01:28 |
| asac | if cross | 01:28 |
| asac | not sure how we do the decision on appamor | 01:28 |
| jdstrand | yes, do everything except run these bits. that said, these bits could run on the host-- they are not complicated tools | 01:28 |
| asac | but we run them on first boot anyway | 01:28 |
| asac | i dont want to add more stuff to tools ppa really | 01:28 |
| asac | think that starts to become nasty | 01:29 |
| asac | need to be tested and done for trusty etc. | 01:29 |
| jdstrand | I was more talking about unblocking you now | 01:29 |
| asac | i am not blocked. but tomorrow we have to get things together | 01:29 |
| asac | so we should do it right right away | 01:30 |
| jdstrand | ok, 15.04.7 uploaded to image ppa and archive | 01:30 |
| asac | yep saw that | 01:30 |
| jdstrand | go-example-webserver wrks | 01:30 |
| asac | thx | 01:30 |
| asac | great | 01:30 |
| asac | check 1 :) | 01:30 |
| jdstrand | I'll work on the unit tomorrow. that will give me insight as to what needs to happen with apparmor when we switch it to the new | 01:32 |
| asac | jdstrand: generateSeccompPolicy | 01:32 |
| asac | is that the whole function to kill? | 01:32 |
| asac | on cross? | 01:32 |
| jdstrand | let me check | 01:33 |
| asac | is the unit difficult? | 01:34 |
| jdstrand | addOneSecurityPolicy() can exit early if run under udf | 01:34 |
| jdstrand | it shouldn't be | 01:34 |
| asac | addOne | 01:35 |
| asac | isnt matching | 01:35 |
| jdstrand | that is in snappy/click.go | 01:35 |
| jdstrand | in trunk | 01:35 |
| asac | ah | 01:35 |
| jdstrand | hmm | 01:37 |
| jdstrand | no, it's ok | 01:37 |
| jdstrand | I thought namespaces might trip me up, but it won't | 01:37 |
| asac | jdstrand: is there a script you can give us to run after boot so we can test this in the morning? | 01:38 |
| jdstrand | that is what I need to write | 01:39 |
| asac | jdstrand: you say we can run those tools on host? | 01:40 |
| asac | to shortcut? | 01:40 |
| jdstrand | I don't see why not | 01:40 |
| jdstrand | I installed several images today with udf | 01:40 |
| jdstrand | I have ubuntu-core-security-utils installed | 01:40 |
| asac | jdstrand: did you try snaps with built-in? | 01:41 |
| asac | normal images work | 01:41 |
| jdstrand | I did not | 01:41 |
| asac | it just busts if we have built-in stuff | 01:41 |
| jdstrand | I don't know how to do that | 01:41 |
| asac | jdstrand: run udf with --oem ./... | 01:42 |
| asac | and use http://people.canonical.com/~asac/tmp/generic-amd64_1.1_all.snap | 01:42 |
| asac | locally | 01:42 |
| asac | udf ... --developer-mode ... --oem ./generic-amd64_1.1_all.snap | 01:42 |
| asac | that one tries to install hello-world.jdstrand | 01:42 |
| asac | sudo ubuntu-device-flash core rolling --developer-mode --channel edge --oem ./oem-hardware-assign_1.0_all.snap --enable-ssh -o outputamd64.img | 01:43 |
| asac | jdstrand: that command | 01:43 |
| asac | give it a spin | 01:43 |
| jdstrand | just grab fyi, I just installed ubuntu-core-security-utils and ubuntu-core-security-seccomp from the image ppa and python3-yaml from the archive in a trusty vm fine | 01:45 |
| * jdstrand adjusts the deps for ubuntu-core-security-utils | 01:45 | |
| jdstrand | curious why ${python3:Depends} didn't do it for me | 01:46 |
| jdstrand | ./oem-hardware-assign_1.0_all.snap failed to install: snappy package not found | 01:49 |
| jdstrand | I don't know where that is | 01:50 |
| asac | jdstrand: sorry wrong name | 01:50 |
| asac | uuse the one | 01:50 |
| asac | you downloaded | 01:50 |
| asac | ./generic-amd64_1.1_all.snap | 01:50 |
| asac | not ./oem-hardware-assign_1.0_all.snap | 01:50 |
| asac | sudo ubuntu-device-flash core rolling --developer-mode --channel edge --oem ./generic-amd64_1.1_all.snap --enable-ssh -o outputamd64.img | 01:50 |
| jdstrand | oh right, duh | 01:50 |
| asac | heh | 01:50 |
| jdstrand | asac: it failed in some other manner, but it seems like it probably got past sc-filtergen | 01:54 |
| jdstrand | http://paste.ubuntu.com/10864267/ | 01:54 |
| asac | jdstrand: thats probasbly becauuse your system is busted | 01:54 |
| asac | reboot | 01:54 |
| asac | jdstrand: wait | 01:55 |
| asac | jdstrand: so remember that udf does not use a chroot anymore afaik | 01:55 |
| asac | its just run on host with path etc. | 01:55 |
| asac | not sure what your tools are doing | 01:55 |
| asac | if you are sure your system is still alive | 01:55 |
| asac | then reboot :) | 01:55 |
| jdstrand | I was running sbuild at the time. it had a problem related to unmounting | 01:55 |
| asac | good | 01:56 |
| jdstrand | it might've been the systemd shared mount space stuff | 01:56 |
| asac | ok how does it look now? | 01:56 |
| * jdstrand is trying again | 01:56 | |
| jdstrand | it reported breaking differently, but still a umount issue | 01:57 |
| asac | i would suggest to reboot | 01:57 |
| jdstrand | I can reboot, but it will be a minute | 01:57 |
| asac | sure, better than giving up :) | 01:57 |
| * jdstrand has a lot of context atm | 01:57 | |
| jdstrand | you could also try installing the tools I mentioned on trusty | 01:58 |
| asac | this will mess my system a lot | 01:59 |
| asac | but ok | 01:59 |
| asac | utils? | 01:59 |
| === c74d3 is now known as c74d | ||
| jdstrand | ubuntu-core-security-utils ubuntu-core-security-seccomp from the ppa | 02:00 |
| jdstrand | you will also need python3-yaml | 02:00 |
| jdstrand | and seccomp | 02:00 |
| jdstrand | that should be it | 02:00 |
| asac | yay | 02:01 |
| * jdstrand uploads 15.04.8 to add Depends on python3-yaml | 02:01 | |
| asac | it worked :) | 02:01 |
| jdstrand | good! | 02:01 |
| asac | too bad | 02:04 |
| asac | hw assign is broken anyway | 02:04 |
| asac | jdstrand: sent mail | 02:05 |
| asac | i drop off | 02:06 |
| jdstrand | ok, good night | 02:06 |
| jdstrand | jeex it must be late there | 02:06 |
| jdstrand | jeez* | 02:07 |
| asac | i think autopilot jsut udpated :) | 02:10 |
| asac | yay | 02:10 |
| asac | it atuomatically rebooted | 02:10 |
| asac | nice | 02:11 |
| asac | good to end day like that :) | 02:11 |
| asac | lol | 02:11 |
| asac | cu in a bit | 02:11 |
| jdstrand | hehe | 02:12 |
| jdstrand | nice :) | 02:12 |
| === timchen1` is now known as timchen119 | ||
| === kickinz1|afk is now known as kickinz1 | ||
| kickinz1 | o/ | 05:12 |
| dholbach | good morning | 07:11 |
| dholbach | dpm, davidcalle will work on refinements for the raspi bits, the channels and the start page - those are going to be most important pieces, later on we might look into importing stuff like you did | 08:55 |
| dholbach | dpm, great work | 08:55 |
| davidcalle | dholbach, +1 | 08:56 |
| dholbach | davidcalle, sorry | 08:57 |
| dholbach | I meant to say... | 08:57 |
| dholbach | "davidcalle and I" | 08:57 |
| * dholbach needs another coffee :) | 08:57 | |
| plorenz | hi, i'm running snappy ubuntu on my raspberry pi 2 (by lool) and for some reason, the system only shows 116 MB of RAM available although it should be 1 GB of RAM. i guess it's a problem with GPU memory split, but i can't find a setting. can anybody help me please? | 08:58 |
| davidcalle | dholbach ;) | 08:58 |
| JamesTait | Good morning all; happy Earth Day! :-D | 09:03 |
| dpm | dholbach, ack, thanks! | 09:10 |
| dholbach | davidcalle, I updated https://developer.ubuntu.com/en/snappy/guides/channels/ - do you feel it's clearer in the regard we discussed earlier? | 09:12 |
| dholbach | davidcalle, also... I'm considering extending the image at the bottom to explain the transition from alpha to beta, etc - wdyt? | 09:13 |
| davidcalle | dholbach, not sure if the image needs to be extended. The table on top looks good, I still think you should add a wget and a udf examples under it, to make it clear what to do with this channel/release combination. | 09:39 |
| davidcalle | dholbach, the page works well for me, especially with the table called a cheatsheet | 09:39 |
| dholbach | davidcalle, ah yes, that's right - I'll add an example, but I'm not sure about wget/udf instructions - wouldn't we have to update the instructions as well whenever thing change again or images get updated? | 09:41 |
| davidcalle | dholbach, that's true, I forgot udf was a moving target. But for wget, it would be mostly to show off how the path is composed (http://cdimage.ubuntu.com/ubuntu-core/15.04/edge/ubuntu-15.04-snappy-armhf-bbb.img.xz), to show people they can compose the img path based on what they need. | 09:44 |
| === erkules_ is now known as erkules | ||
| dholbach | that makes sense | 09:45 |
| dholbach | unfortunately we don't have http://cdimage.ubuntu.com/ubuntu-core/rolling/ yet | 09:46 |
| davidcalle | dholbach, implementation detail :p | 09:46 |
| dholbach | all right, I'll figure it out, thanks for the feedback | 09:46 |
| sergiusens | dholbach: davidcalle we have finalized u-d-f, it won't be moving again except for bug fixes | 09:47 |
| davidcalle | dholbach, I'd like to say something like "if it's documented, it needs to exist ASAP" ;-) | 09:47 |
| davidcalle | sergiusens, oh cool :) | 09:48 |
| dholbach | davidcalle, ok, updated - thanks again | 09:55 |
| dholbach | davidcalle, are you working on the start page now? | 10:06 |
| dholbach | davidcalle, I added channel info for the kvm case - does it look all right to you? do you think it helps like that? | 10:30 |
| davidcalle | dholbach, I'm starting now. It looks right to me, so these are the final paths? edge at cdimages.ubuntu.com/ubuntu-snappy and stable, beta, rc at releases.ubuntu.com? | 10:46 |
| davidcalle | dholbach, also, we talked about this earlier, but I'm not sure we had a definitive answer : are cloud images going to follow the naming scheme for release? (or should we just use the stable image names they provide tomorrow?) | 10:51 |
| davidcalle | dholbach, don't mind the lat question, I've found what I'm looking for. | 10:52 |
| davidcalle | last* | 10:52 |
| yngves | Wondering if something is broken in the new Docker 1.6 package? I keep getting "aa-exec: ERROR: profile 'docker_docker_1.6.0.002' does not exist" when invoking Docker. | 11:24 |
| dholbach | davidcalle, I'll ping the cloud guys and point them to the page - AFAIK those are the final paths, yes | 11:33 |
| davidcalle | dholbach, thanks | 11:34 |
| dholbach | a review with Steve and Alex later on should let us know if we're on the right track or not :) | 11:34 |
| * davidcalle starts getting confused about the naming scheme again. | 11:40 | |
| asac | ppisati: hey, how is the cape going? | 11:43 |
| dholbach | davidcalle, in the case of OVA, do you think we should explain the URL scheme - or just add the box with the links? | 11:46 |
| davidcalle | dholbach, I've done both | 11:46 |
| dholbach | ok... I personally would've thought that the box would be enough, but maybe just leave it in there and we talk about it later on together :) | 11:47 |
| davidcalle | dholbach, the scheme of cloud-images is a bit different | 11:50 |
| dholbach | oh! did you find out how it works there? | 11:52 |
| ppisati | asac: i've got the original image to work, but once i compile the TI kernel, it doesn't boot on my board | 11:53 |
| ppisati | yesterday i spent the entire day doing test for the release | 11:54 |
| asac | ppisati: why do we need TI kernel? | 11:54 |
| asac | if we have it working with our generic one? | 11:54 |
| asac | ok have to go for lunch | 11:54 |
| asac | bbiab | 11:54 |
| ppisati | asac: because first you get a piece of hw working with the code that supports it | 11:55 |
| ppisati | asac: then you derive a delta from it etc | 11:55 |
| davidcalle | dholbach, I think so | 11:56 |
| dholbach | davidcalle, I added a box like this to the bbb docs too | 12:11 |
| dholbach | davidcalle, it gets placed in the wrong area though | 12:11 |
| dholbach | davidcalle, do you have an idea how to fix it? | 12:12 |
| davidcalle | dholbach, I'm fixing | 12:15 |
| dholbach | davidcalle, if we ever do a sprint together, you should do a workshop on how to fix stuff like that :-) | 12:16 |
| dholbach | I'd make sure to get a seat in the first row! | 12:17 |
| davidcalle | dholbach, why not :) Fixed. I'm confused by the fact that if you download both images (15.04/stable and 15.04/edge), you have no way to differentiate the files by their names. | 12:19 |
| dholbach | davidcalle, we should note this down | 12:20 |
| davidcalle | dholbach, I've also left a comment on the card regarding the other tasks. | 12:23 |
| dholbach | thanks | 12:23 |
| dholbach | davidcalle, do you feel we're done with the page now, barring any changes we might need to do after a meeting with Alex and Steve and potentially the cloud guys? | 12:24 |
| davidcalle | dholbach, yep | 12:24 |
| dholbach | cool | 12:24 |
| * dholbach hugs davidcalle | 12:24 | |
| dholbach | good work | 12:24 |
| davidcalle | dholbach, same :) | 12:26 |
| dholbach | asac, slangasek: whenever you have time, davidcalle and I would review https://developer.ubuntu.com/snappy/start/ and https://developer.ubuntu.com/snappy/guides/channels with you | 12:32 |
| dholbach | asac, mvo, sergiusens: I'm still not quite sure which ppa to recommend? right now there's 'beta', 'tools', 'tools-proposed' (and probably unrelated: 'image') | 12:36 |
| dholbach | asac, mvo, sergiusens: what kind of changes do you anticipate to land in which of the PPAs | 12:36 |
| dholbach | I'm still not sure how to explain the four PPAs to users | 12:36 |
| sergiusens | dholbach: tools has latest and greatest and always breaks, beta is for users; but I want to get rid of that as it's too confusing | 12:37 |
| dholbach | sergiusens, ok... so I just recommends 'beta' for nowß? | 12:38 |
| plorenz | sergiusens: do you know how i can increase my available ram with snappy on the raspberry pi 2? | 12:38 |
| sergiusens | dholbach: yes | 12:39 |
| sergiusens | plorenz: no | 12:39 |
| dholbach | thanks sergiusens! | 12:42 |
| dholbach | can somebody review and land https://code.launchpad.net/~dholbach/snappy/markdown-doc-fixes/+merge/257080? | 13:09 |
| sergiusens | dholbach: done | 13:19 |
| asac | pitti: is there an easy way on the cli to query for devices that got assigned to the app? | 13:19 |
| asac | pitti: from the app point of view? | 13:19 |
| asac | udev query | 13:19 |
| sergiusens | dholbach: would be nice to use the ```[code] annotation eventually :-) | 13:19 |
| dholbach | sergiusens, did you see r416 on the MP as well? I pushed another commit | 13:20 |
| dholbach | sergiusens, I've never seen any ```[code] notation | 13:20 |
| dholbach | thanks Chipaca | 13:23 |
| sergiusens | dholbach: github markdown being the engine I refer to | 13:23 |
| dholbach | ah ok | 13:23 |
| sergiusens | dholbach: https://help.github.com/articles/github-flavored-markdown/#syntax-highlighting | 13:24 |
| dholbach | cool | 13:24 |
| dholbach | I hope one day a bunch of people get together and figure out one markdown standard to rule them all | 13:24 |
| sergiusens | dholbach: that's easy; github :-P | 13:24 |
| dholbach | right | 13:24 |
| sergiusens | standards are hard in an ever moving fast paced world | 13:25 |
| pitti | asac: yes, cat /sys/fs/cgroup/snappy.appname*/devices.list | 13:33 |
| pitti | asac: this gives you the real actual ACL | 13:33 |
| pitti | asac: you can also get a list of devices tagged for the app with udevadm | 13:33 |
| pitti | asac: udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=$APPNAME | 13:34 |
| asac | pitti: so jdstrand is a bit unhappy to allow apps to ask for what they can talk to this way | 13:41 |
| asac | i think its super useful for some app to say "give me all the devs that are of type X and that i am allowed to use" | 13:42 |
| asac | pitti: so trigger is doing the query? | 13:42 |
| pitti | asac: well, so far that's coming from OEM.yaml, so not from the app? | 13:42 |
| asac | pitti: but an app needs too know what it can talk to | 13:42 |
| asac | at best using the closest to current practices | 13:42 |
| pitti | asac: why shouldn't we allow the apps to query for what they can access? either by devices.list or udev? | 13:42 |
| pitti | they can just try and open everything in /dev/ after all | 13:43 |
| asac | pitti: jdstrand doesnt like that this leaks info about what is installed | 13:43 |
| asac | i think its a bug that we can address later :) | 13:43 |
| asac | but we should allow apps to query udev | 13:43 |
| pitti | asac: oh, you mean the udevadm? | 13:43 |
| asac | pitti: not sure | 13:43 |
| dholbach | https://code.launchpad.net/~dholbach/snappy/more-markdown-fixes/+merge/257094 | 13:43 |
| pitti | asac: oh, we need to | 13:43 |
| jdstrand | pitti: I'm fine with apps trying to open things in /dev | 13:43 |
| pitti | asac: but right now the apps aren't confied at all | 13:43 |
| asac | pitti: only thing i know is that i want to tell a story on how an app that we assigned access to | 13:44 |
| asac | can find the usb devices that it can now poke | 13:44 |
| jdstrand | pitti: I'm less fine about an app querying udev and being able to see all the tags, and therefore, enumerate installed apps on the system | 13:44 |
| pitti | asac: that udevadm on the shell or libudev in C should be fairly adequate for that query | 13:44 |
| asac | right | 13:44 |
| asac | pitti: but jdstrand wants to take powers away from us to not allow to use libudev :P | 13:44 |
| asac | which i think is not good for real life :P | 13:45 |
| pitti | well, not querying sysfs at all is a no-go IMHO | 13:45 |
| asac | right :) | 13:45 |
| asac | i agree!! | 13:45 |
| asac | so i think for me this is a must | 13:45 |
| pitti | so you could at most restrict the access there | 13:45 |
| asac | and we need to figure later how to make things even better | 13:45 |
| asac | right | 13:45 |
| asac | we can try to make udev smarter later | 13:45 |
| jdstrand | well hold on | 13:45 |
| asac | to hide stuff :) | 13:45 |
| pitti | but quite frankly, this is by faaaaaar not the most problem we are having :) | 13:45 |
| pitti | 'impotant' | 13:45 |
| jdstrand | sysfs is another conversation | 13:46 |
| * ogra_ thought you were planning something like the trust-store we have on the phone | 13:46 | |
| asac | its the same kinda | 13:46 |
| asac | ogra_: thats a higher level | 13:46 |
| ogra_ | why | 13:46 |
| pitti | well, libudev just queries /sys and /run/udev/ | 13:46 |
| asac | no time to argue | 13:46 |
| ogra_ | jus integrate something like that with udev | 13:46 |
| * jdstrand notes that I am not taking powers away from using libudev. apps don't currently have it. I am trying to understand what the access gives | 13:46 | |
| asac | jdstrand: apps on normal ubuntu have it | 13:47 |
| jdstrand | asac: apps on touch do not | 13:47 |
| pitti | libudev itself is just conveience; you can't do anything with it that you can't already do with /sys and /run/udev/ | 13:47 |
| asac | right, but they dont want to poke devices :) | 13:47 |
| pitti | so we need to restrict /run/udev/ if we want to restrict app access | 13:47 |
| jdstrand | if we allow this and don't fix udev to restrict the access, then on touch we regress | 13:47 |
| asac | we should restrict it | 13:47 |
| asac | later | 13:47 |
| asac | smart | 13:47 |
| pitti | that might break some apps, but might be appropriate | 13:47 |
| asac | not sure how | 13:47 |
| asac | is there a way we can restrict it? | 13:47 |
| ogra_ | polkit ? | 13:48 |
| ogra_ | via udev-acl | 13:48 |
| asac | e.g. is /run/udev/ content compatible with apparmor? | 13:48 |
| jdstrand | pitti: is it fair to say that if I use udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=hellow-world.sideload under confinement I can see what read only access is required? | 13:48 |
| asac | jdstrand: you need read access to /sys and to /run/udev i think | 13:49 |
| jdstrand | pitti: is there a udev daemon? | 13:49 |
| asac | yeah | 13:49 |
| asac | i think there is and that could later mediate | 13:49 |
| jdstrand | pitti: as in, udevadm talks to a daemon? | 13:49 |
| asac | not sure if libudev is going through that, but could be! | 13:49 |
| pitti | jdstrand: there is udevd, but udevadm query and libudev don't talk to it | 13:49 |
| pitti | as I said, it's just reading /sys and /run/udev (for the properties and tags) | 13:50 |
| asac | ah bummer :) | 13:50 |
| asac | jdstrand: yeah so short term we woudl have to open access for those friends | 13:50 |
| asac | to those directories | 13:50 |
| asac | and then later see how to make libudev go through mediation or make /run/udev so that the app info can be confined | 13:50 |
| pitti | we also don't yet start apps under its own pid namespace, so presumably apps can already see what other apps are running? | 13:50 |
| jdstrand | well, in the future to resrict this, we would want to have a tool that talks to an out of process helper, perhaps udevd, then udevd asks libapparmor for the label of the client, then filters the query results to be only those for the app | 13:51 |
| ogra_ | and "those friends" would be aware that their apps break at some point ? | 13:51 |
| jdstrand | then we remove access to /run/udev, etc | 13:51 |
| pitti | again, there is *no* point in restricting libudev as such | 13:51 |
| dholbach | Chipaca, sergiusens: any idea why https://code.launchpad.net/~dholbach/snappy/more-markdown-fixes/+merge/257094 might be unhappy? | 13:51 |
| asac | jdstrand: can you do a find on /run/udev after tagging something? | 13:51 |
| asac | jdstrand: i think its a simple pattern match to hide that | 13:51 |
| asac | i think the app name is really in the tagname on disk | 13:52 |
| jdstrand | pitti: we have restricted access in /proc, but there are some leaks there that we plan to address. I'm concerned about adding more and more stuff that leaks info about the system. if we understand what needs to be done, that is fine | 13:52 |
| asac | right | 13:53 |
| asac | but we have to take a holistic look at that later :P | 13:53 |
| pitti | "private process namespace" :) | 13:53 |
| ogra_ | i dont really get that ... there is such a mechanism via polkit and udev--acl already, why dont we use it ? | 13:53 |
| pitti | now that we have a launcher, we can easily add that, and private /tmp and such | 13:54 |
| asac | thats too high level. we work on primitives to hard wire access here | 13:54 |
| jdstrand | we can't use polkit because no one can do the authorization | 13:54 |
| pitti | ogra_: that doesn't restrict visibility | 13:54 |
| asac | polkit or such can be built on top | 13:54 |
| ogra_ | pitti, thats indeed true, but access ... | 13:54 |
| pitti | also, it's logind plus ACLs | 13:54 |
| ogra_ | ah, right, i'm a bit behind :) | 13:54 |
| pitti | ogra_: access restriction is already in the lanucher nw | 13:54 |
| pitti | now | 13:54 |
| sergiusens | dholbach: hmm, outage or godeps changed | 13:54 |
| pitti | that's what mvo and I worked on last week | 13:54 |
| ogra_ | ok | 13:54 |
| ogra_ | the launcher = ubuntu-app-launch ? | 13:55 |
| pitti | yes | 13:55 |
| ogra_ | ro did you re-implement that | 13:55 |
| ogra_ | awesome :) | 13:55 |
| jdstrand | ogra_: the snappy launcher is ubuntu-core-launcher. how this will work on touch is less clear, but either ubuntu-core-launcher is updated to do UAL-y things, or the other way around | 13:56 |
| ogra_ | ah, so it is a separate thing ... k | 13:57 |
| jdstrand | for now | 13:57 |
| jdstrand | pitti, asac: ftr, right this second, we don't leak anything in /proc on snappy (we do on touch, but there is a bug on that). udevadm will change that, but it sounds like that is what is required, so I'll document all this | 14:01 |
| asac | jdstrand: given that we have to revisit all this holistically anyway for next releases i really think its fine to have leak about apps that have hw assigned for the time being. | 14:02 |
| asac | jdstrand: we could in future use a crypto token for assign that is only known to the core system itself and the app? | 14:02 |
| asac | so instead of SNAPPY_APP:=.... | 14:03 |
| jdstrand | fyi, udevadm doesn't work under the launcher | 14:03 |
| jdstrand | I'd prefer to wait on designing how to fix it for when we are interested in fixing it. way to much to do today | 14:04 |
| jdstrand | pitti: do you know why udevadm would fail under our cgroups implementation? | 14:05 |
| pitti | jdstrand: no, it shouldn't have anythign to do with the devices cgroup; when I tried mvo's MP even sudo worked there | 14:06 |
| pitti | jdstrand: how does it fail? | 14:06 |
| jdstrand | I get apparmor denials under aa-exec but nothing under the launcher other than the app saying: udevadm: Operation not permitted | 14:06 |
| pitti | apparmor? syscalls failing? (strace) | 14:06 |
| pitti | sorry, deeply in release prep/testing mode right now | 14:06 |
| jdstrand | no, none of that. I'll keep poking | 14:06 |
| davidcalle | dholbach, back o/ | 14:06 |
| pitti | jdstrand: ok, so stracing it might be insightful? | 14:07 |
| asac | pitti: just last thing: to query on cli i would use trigger? | 14:07 |
| asac | or adm? | 14:07 |
| asac | err ignore | 14:08 |
| pitti | asac: trigger --dry-run is nice for getting a list of devices that have certain names/attributes/properties/tags | 14:08 |
| dholbach | davidcalle, I looked into importing the snappy internal docs and fixed a few bits in the markup to make it easier for us to import it "as is" | 14:08 |
| pitti | query is good for getting info about a particular dev | 14:08 |
| pitti | asac: ^ | 14:09 |
| asac | nice | 14:09 |
| asac | thanks | 14:09 |
| davidcalle | dholbach, yes, seen it, I'm starting on the meta one | 14:09 |
| dholbach | davidcalle, looking at 'oem' now | 14:09 |
| dholbach | davidcalle, one problem we're going to have is linking from files to each other | 14:10 |
| dholbach | davidcalle, we could wrap dpm's instructions into a small python script | 14:10 |
| davidcalle | dholbach, there are a lot of links? | 14:10 |
| asac | jdstrand: https://pastebin.canonical.com/130117/ | 14:10 |
| asac | those i am getting | 14:10 |
| dholbach | ... which could replace a mention of "security.md" with a proper link to its location on the website | 14:10 |
| dholbach | davidcalle, not too many | 14:10 |
| asac | jdstrand: udevadm trigger --verbose --dry-run --tag-match=snappy-assign | 14:11 |
| dpm | dholbach, yes, and feel free to improve it, I just wrote a few one-liners to make it simpler, but could be more elegant | 14:11 |
| asac | jdstrand: maybe its working if you have the /dev as r ? | 14:11 |
| davidcalle | dholbach, let's assume their path is guides/<name> | 14:11 |
| davidcalle | dholbach, a script is fine too :) | 14:11 |
| asac | jdstrand: yeah so /dev/** | 14:11 |
| dholbach | davidcalle, to keep stuff in sync I just thought that it'd be nice if we had a self-contained script that won't grow into a chaotic monster (~50 lines) which would take an .md file from the branch and turn it into exactly what we need to paste into the text box of django cms | 14:11 |
| asac | not just /dev/* | 14:11 |
| dholbach | dpm, that was no criticism - thanks a lot for figuring stuff out so far already! :) | 14:12 |
| davidcalle | dholbach, oh right, keeping stuff in sync after that. | 14:12 |
| dholbach | yep | 14:12 |
| davidcalle | dholbach, then absolutely :) | 14:12 |
| dpm | dholbach, I didn't interpret it as criticism, just saying I'm not particularly proud of the one-liners :) | 14:12 |
| dpm | but I did it between other things this morning, and I thought I'd put something together real quick | 14:13 |
| dholbach | davidcalle, dpm: I'll put the oem article online, and could then look into writing such a script | 14:13 |
| dpm | cool | 14:13 |
| davidcalle | Ok | 14:13 |
| dpm | dholbach, I noticed a few typos and markdown syntax errors on the config.md script that I fixed on the final HTML. I think the original docs might need some fixes. | 14:14 |
| dholbach | asac, slangasek: davidcalle and I still around for a review of /snappy/start and /snappy/guides/channels - we have a meeting coming up in 45m though | 14:14 |
| dholbach | dpm, https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/changes :) | 14:14 |
| dholbach | dpm, there might be more though | 14:15 |
| dpm | dholbach, nice, good work :) | 14:15 |
| jdstrand | pitti: it was an apparmor issue but there was no denial. kernel rate limiting may have been in effect | 14:16 |
| davidcalle | dpm, dholbach, moving on to frameworks | 14:18 |
| dholbach | https://code.launchpad.net/~dholbach/snappy/even-more-markdown-fixes/+merge/257112 | 14:27 |
| sergiusens | mvo: want to remerge trunk on your branch? | 14:37 |
| sergiusens | mvo: it conflicts with the packageYaml removal from the signature in oemHwUDRules you did in another branch | 14:37 |
| dholbach | dpm, davidcalle: I'll mail the snappy lists to help out with a docs review for the release tomorrow and tell them to either respond on list or ping davidcalle and me on IRC - does that sound all right to you? | 14:38 |
| dholbach | ... or file bugs on developer-ubuntu-com | 14:38 |
| dholbach | maybe that's the best option | 14:38 |
| * dholbach reviews bug list | 14:38 | |
| mvo | sergiusens: I updated the branch, thanks again and also removed println() | 14:52 |
| sergiusens | jdstrand: can you ack https://code.launchpad.net/~mvo/snappy/snappy-add-apparmor-override/+merge/257076 ? | 14:55 |
| sergiusens | you have needs info there | 14:55 |
| jdstrand | I thought I did | 14:55 |
| sergiusens | given we are so close to release I don't want to override | 14:56 |
| jdstrand | ah, I was trying to test it. that is what I was working on when the meeting came | 14:56 |
| dholbach | https://code.launchpad.net/~dholbach/snappy/even-more-markdown-fixes/+merge/257112 | 15:04 |
| dholbach | oops | 15:05 |
| Chipaca | dholbach: “ARM or X86 devices such as the Beaglebone Black” is probably unfortunate word order | 15:06 |
| Chipaca | dholbach: or unfortunate lack of oxford comma, | 15:06 |
| Chipaca | or something :) | 15:06 |
| * genii armors his X86 | 15:06 | |
| dholbach | Chipaca, good find - fixed, thanks! | 15:09 |
| dholbach | we inherited quite a few docs, trying to get on top of things everywhere :) | 15:09 |
| Chipaca | man, i had to use wdiff to see machanisms -> mechanisms in that diff | 15:10 |
| dholbach | Chipaca, yeah, sorry - I always use bzr diff --using=wdiff for commits like that :) | 15:11 |
| Chipaca | heh :) | 15:11 |
| Chipaca | dholbach: updates on in `oem` package | 15:11 |
| sergiusens | Chipaca: oh, I just commented the same | 15:12 |
| dholbach | sergiusens, pushed a change to fix your comment | 15:16 |
| Chipaca | dholbach: hmm | 15:16 |
| * Chipaca tries something | 15:16 | |
| Chipaca | dholbach: so, in pandoc, instead of ```yaml, you'd do ~~~ {.yaml} | 15:21 |
| Chipaca | dholbach: you then need css to do the highlighting, but it's something | 15:21 |
| Chipaca | dholbach: you can also use -B for the content before the body, and -A for after | 15:21 |
| dholbach | oh nice | 15:21 |
| dholbach | I'll take a look | 15:22 |
| sergiusens | dholbach: Chipaca does pandoc have some form of syntax checker we can enable in ./run-checks? | 15:24 |
| dholbach | Chipaca, do I need to close the ~~~ {.yaml} tag somehow? | 15:24 |
| Chipaca | dholbach: yes, ~~~ on its own line | 15:24 |
| dholbach | right | 15:24 |
| Chipaca | dholbach: http://pandoc.org/README.html#extension-fenced_code_blocks | 15:25 |
| Chipaca | it's actually 3 or more ~s | 15:25 |
| Chipaca | sergiusens: i didn't think markdown had the idea of 'bad syntax' | 15:26 |
| sergiusens | Chipaca: markdown itself, no; maybe pandoc does | 15:26 |
| Chipaca | also, you can tell pandoc to use markdown_github | 15:26 |
| Chipaca | which would probably make sergiusens wet himself | 15:26 |
| sergiusens | oh neat | 15:26 |
| Chipaca | so don't tell him that | 15:26 |
| sergiusens | we should do that | 15:26 |
| sergiusens | lol | 15:26 |
| dholbach | haha | 15:26 |
| sergiusens | it is the markdown style everyone uses | 15:27 |
| dholbach | I'll leave this open for discussion for the team | 15:27 |
| dholbach | I don't care too much | 15:27 |
| dholbach | as long as we have something which spits out raw html I can paste into developer.u.c's djangocms, I'm happy | 15:27 |
| sergiusens | dholbach: is it fully automated now? | 15:28 |
| sergiusens | dholbach: or html that you copy paste? | 15:28 |
| dholbach | the latter | 15:28 |
| dholbach | automating this fully will be too much work right now | 15:28 |
| sergiusens | dholbach: maybe adding a form to upload a raw html file will allow full automation | 15:29 |
| sergiusens | oh | 15:29 |
| sergiusens | I thought it wouldn't be too hard | 15:29 |
| dholbach | the content right now lives in a database | 15:29 |
| sergiusens | just a uri you can post to or put to change the resources | 15:29 |
| sergiusens | and django would save it to the db | 15:29 |
| dholbach | if you want access, then yes, you have a page where you can copy/paste | 15:29 |
| dholbach | sergiusens, Chipaca: can somebody make a decision on if we want to use github markdown or something else? | 15:30 |
| dholbach | I don't care too much | 15:30 |
| dholbach | but it'd be good to decide this | 15:30 |
| dholbach | maybe it'd also allow us to change the .rst doc to an .md doc | 15:31 |
| Chipaca | whatever's the path of least work | 15:31 |
| dholbach | AFAIR it was just tables which stopped it from using regular markdown | 15:31 |
| dholbach | maybe tables work in github markdown? | 15:31 |
| Chipaca | pandoc's take on github markdown might not be github markdown | 15:31 |
| Chipaca | just to keep things clear | 15:31 |
| dholbach | ok | 15:32 |
| Chipaca | dholbach: i don't think we need to change anything more than the minimum to get things to look right on our website, now | 15:32 |
| Chipaca | dholbach: next week we can talk grand designs | 15:32 |
| dholbach | +1 | 15:32 |
| * dholbach moves on | 15:32 | |
| dholbach | :) | 15:32 |
| dholbach | I'll file a bug on snappy | 15:32 |
| sergiusens | dholbach: easy | 15:33 |
| sergiusens | Chipaca: mvo jodh http://www.poll-maker.com/poll299911x1d4b4d87-11 | 15:33 |
| Chipaca | hahahah | 15:34 |
| Chipaca | sergiusens: that's sweet | 15:34 |
| Chipaca | sergiusens: markdown_phpextra (PHP Markdown Extra) | 15:34 |
| Chipaca | footnotes, pipe_tables, raw_html, markdown_attribute, fenced_code_blocks, definition_lists, intraword_underscores, header_attributes, abbreviations. | 15:34 |
| Chipaca | markdown_github (Github-flavored Markdown) | 15:34 |
| Chipaca | pipe_tables, raw_html, tex_math_single_backslash, fenced_code_blocks, auto_identifiers, ascii_identifiers, backtick_code_blocks, autolink_bare_uris, intraword_underscores, strikeout, hard_line_breaks | 15:34 |
| Chipaca | markdown_mmd (MultiMarkdown) | 15:34 |
| Chipaca | pipe_tables raw_html, markdown_attribute, link_attributes, raw_tex, tex_math_double_backslash, intraword_underscores, mmd_title_block, footnotes, definition_lists, all_symbols_escapable, implicit_header_references, auto_identifiers, mmd_header_identifiers | 15:34 |
| Chipaca | markdown_strict (Mar | 15:34 |
| Chipaca | ... | 15:34 |
| Chipaca | :) | 15:34 |
| sergiusens | Chipaca: mark down strict is nice | 15:35 |
| sergiusens | I like strict | 15:35 |
| Chipaca | no you don't | 15:35 |
| Chipaca | :D | 15:36 |
| mvo | sergiusens: haha | 15:36 |
| * Chipaca stops having fun with sergiusens | 15:36 | |
| mvo | I guess the fact that we talk markdown now means we can release, right? | 15:36 |
| mvo | :P | 15:36 |
| Chipaca | mvo: +1 | 15:36 |
| * mvo hugs dholbach, Chipaca, sergiusens | 15:36 | |
| sergiusens | Chipaca: it's bad tat we are having some fu and mvo is still crunching at it | 15:36 |
| * sergiusens hugs back | 15:37 | |
| * Chipaca joins the hug party | 15:37 | |
| dholbach | hugs! :) | 15:37 |
| * dholbach hugs you all | 15:37 | |
| * sergiusens wonders if it's beer'o clock already | 15:37 | |
| Chipaca | sergiusens: it is in germany! | 15:37 |
| dholbach | asac, slangasek: are you going to have time to review the start and channels pages any time soon? | 15:38 |
| mvo | Chipaca: hahaha, beerclock=[0-24] in germany | 15:41 |
| Chipaca | mvo: that also :) but i meant it was after 5pm | 15:52 |
| jdstrand | asac, pitti: fyi, I profiled 'udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=<appname>'. it requires this rule: '/run/udev/data/* r,'. This actually gives away far more info than what apps are installed | 16:00 |
| jdstrand | asac, pitti: eg "The files in this directory reveal all kinds of information about the hardware, UUIDs of partitions, the MAC address of ethernet interfaces and more. This is enough information for a malicious snap to conduct data mining and identify individual systems and breaks our privacy model." | 16:00 |
| jdstrand | this is bug #1447237 | 16:00 |
| asac | dholbach: the image links would be nice to have them right on top | 16:04 |
| asac | of the section | 16:04 |
| asac | like in getting started on baeglebone black | 16:04 |
| davidcalle | dholbach, hangout dropped for me | 16:04 |
| asac | sergiusens: i assume avahi wont work unless you have webdm or did we move that to core system? | 16:05 |
| jdstrand | asac: so, we've worked extremely hard on touch to not reveal things such as the mac address | 16:05 |
| sergiusens | asac: no, it's not in core on request from high above | 16:07 |
| asac | jdstrand: could we argue that only apps that get hw assign can read this? | 16:08 |
| jdstrand | asac: so we have a couple of choices. accept the information disclosure, but have someone get on the restriction soon or don't allow reading /run/udev/data/*. Interestingly, if you call udevadm without -property-match=SNAPPY_APP=<appname>, you don't need /run/udev/data/* | 16:08 |
| asac | jdstrand: in the end this would put the decision into the yard of the guy that makes the system | 16:08 |
| asac | and touch could for instance just allow only their framework to access that | 16:08 |
| asac | and they can still realize their model | 16:08 |
| jdstrand | asac: yes, we can adjust mvo's branch to do that | 16:09 |
| asac | jdstrand: would this make you feel more comfortable? | 16:09 |
| jdstrand | it would | 16:09 |
| jdstrand | I would downgrade the priority significantly | 16:09 |
| asac | lets do that i guess... later we have to look how to make udev better | 16:09 |
| asac | i think udev coul dhave different data directories | 16:09 |
| asac | one with /snappy/ and one with /crazy/data/ | 16:10 |
| asac | or wait | 16:10 |
| asac | i think we could even restrict acces to the devices in there that the snapp has assigned? | 16:10 |
| jdstrand | most hardware assigned things are frameworks and trusted. if a system builder preinstalls, that is also a form of trust (though different). a user that opts in is saying opting into this | 16:10 |
| asac | jdstrand: right | 16:10 |
| jdstrand | asac: I put ideas in the bug | 16:10 |
| asac | yep | 16:11 |
| asac | cool | 16:11 |
| asac | lets do that | 16:11 |
| asac | jdstrand: will the hw-assign cli work same way? i think its fine and maybe we even disable that in non-developer mode eventually | 16:11 |
| jdstrand | asac: it will | 16:11 |
| jdstrand | ok, I'll update the policy for the safe access and then talk to mvo about this one extra access | 16:12 |
| jdstrand | that will be a very small addition | 16:12 |
| === vmayoral|pc is now known as vmayoral | ||
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| fionnan | anyone getting this `profile 'docker_docker_1.6.0.0.002' error does not exist` on a fresh snappy install? https://bpaste.net/show/5fb0130cf91c | 18:15 |
| yngves | fionnan: Yes, I do. | 20:40 |
| yngves | fionnan: There definitely is no AppArmor policy of that name in the package. I hacked my way around it by changing the last line of /apps/bin/docker to read: aa-exec -p docker-default -- /apps/docker/1.6.0.002/bin/docker "$@" | 20:42 |
| yngves | fionnan: A very ugly hack. Hope it gets fixed. | 20:42 |
| fionnan | yngves: cheers! | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!