[00:44] ogra_: system-image doesn't include shim-signed because you can't have both grub-pc and grub-efi-amd64-signed; we want the latter but it's been an incremental process, requiring changes to udf first. Has udf efi support landed in all the right ppas? [00:45] only once it has should we change the grub seeding === chihchun_afk is now known as chihchun === devil is now known as Guest34774 [06:59] good morning === Guest34774 is now known as devil_ [07:29] good morning [07:34] lool: I love your snappy shell idea (as you know) and couldn't help stating a simple branch that gives it some life: lp:~mvo/snappy/snappy-console [07:59] mvo, i love it too, but please not on port 22 :) [08:02] ogra_: :) I love the idea of snappy console / repl / cli /shell and being able to interact with it this way. I also like the possiblities it opens up. the points raised in the mail thread are indeed good ones, so by default maybe not [08:05] mvo: awesome :-) [08:05] well... [08:05] you could have a "shell" command though :) [08:05] that gives you a shell session [08:14] ogra_: this is already in the proposal [08:15] "snappy cli" as a (hidden?) way to start the snappy shell, and "shell" from the cli as a way to start a real shell [08:16] lool, yeah, though pitti's argument still stands, ssh remote scripts would fail [08:18] I'm not sure about this [08:20] first, it would work with snappy commands, second, we could implement what people feel is important to get from a running snappy system there, third, there might be ways to reach a shell to run real commands [08:23] longsleep, image 0.3 ? not 3.0 ? :) [08:55] Good morning all; happy Fresh Veggies Day! 😃 === vrruiz_ is now known as rvr [09:36] mvo: is it possible you forgot a prereq on the console branch? [09:41] Chipaca: maybe, let me double check [09:43] Chipaca: indeed I did, sorry for that [09:43] mvo: apology accepted [09:54] mvo_: the comment i made in your decorator2 is for addressing in a later branch if at all :) [10:01] mvo_: you know what i'd like? 'snappy verify' to run verify hooks for the apps [10:04] morning [10:04] Chipaca: welcome back [10:04] rsalveti: hey :) [10:05] slangasek: the udf efi branch landed everywhere already [10:10] mvo__: ETOOMANYMVO [10:19] mvo__: commit messages === mvo__ is now known as mvo [10:23] Chipaca: thanks, yeah, adding those now, thanks a bunch for your reviews [10:24] mvo: wrt verify, i'm +1 on most of it, but uncomfortable with growing the already-too-large Part interface [10:24] oh dear [10:25] mvo: wrt verify, i'm +1 on most of it, but uncomfortable with growing the already-too-large Part interface [10:26] Chipaca: makes sense, let me try to think about alternatives then [10:26] mvo_: installed from a local meta already returns only SnapParts [10:26] mvo_: so a jfdi approach would be to do .(*SnapPart) on the parts returned by instlled [10:27] mvo_: a less jfdi approach would split Part into two interfaces, embed the local in the bigger one, and change Installed to return those [10:30] mvo_: another jfdi approach would be to tell me i'm wrong (or pyrrhically right) and go with the branch as writ [10:31] Chipaca: I dislike option (3) because you are right and ignoring that is bad(tm). the two-interfaces approach sounds like the cleanest, wdyt? [10:32] mvo_: i think you'll find it's a lot more code :) [10:32] Chipaca: heh :) probably I will hate myself for not taking the easy option [10:33] * mvo_ will try to fix his dsl before diving into the branch [10:33] mvo_: may i suggest you set a time limit, take a prod on the interfaces, and bail to the jfdi if it snowballs out of time? [10:33] Chipaca: ok, that sounds sensible [10:37] mvo_: and next time i embark on a refactor, remind me to do the same :) [10:37] heh :-D [10:37] promised! [10:38] Chipaca: \o/ thanks for bringing up the Part interface again :-) [10:39] sergiusens: the price of readable code is eternal vigilantism, or something like that [10:39] Chipaca: yup [10:40] mvo_: so, if you do this, can you add the Ports interface to the local interface? [10:40] it's not part of Parts today and doing the .(*SnapPart) check [10:41] sergiusens: yes [10:43] sergiusens: Frameworks might also be moved over, although i do envision a future in which remote parts have Frameworks() and thus the installer can be more helpful wrt that [10:46] Chipaca: i say we request the store to add support for it [10:46] and do nicer things [10:46] sergiusens: yeah, but you know the store guys [10:46] mvo_: any reason for https://trello.com/c/6n9Q3tVh/109-core ? [10:46] they're all like "oh no we can't break things because people will get upset" [10:46] :) [10:47] :-) [11:00] rsalveti: that looks like trello was playing tricks on me [11:01] mvo_: :-) [11:01] rsalveti: I removed it [11:01] mvo_: thanks [11:02] Chipaca: adding stuff doesn't break anything :-P [11:03] Chipaca: unless you add too much and make it unbearable :-) === chihchun is now known as chihchun_afk [11:14] How do I list all available snappy packages to install? [11:15] lord4163: snappy search [11:18] sergiusens: and then after I installed a package? [11:19] lord4163: snappy list [11:20] sergiusens: what can't I use the package now? [11:20] holy f*, I typed reboot in my kvm instance and it rebooted the host machine!?!?!?!?!?!? [11:38] So this snappy thing is for people missing Windows 95 I guess? [11:42] lord4163: it cetainly isn't for end users (core at least) [11:43] for who is it then? [12:20] lord4163: atm it's mainly for builders, which is why sergiusens said core [12:20] once we have more applications and so on, end users can simply consume that from the store [12:21] lord4163: typing reboot in your kvm instance can't reboot the host machine, fwiw [12:21] lord4163: if it can, i hear there's good money in selling the exploit [12:22] Chipaca: It did :P [12:22] lord4163: i believe you think it did, but i don't believe it did :) [12:23] Chipaca: Let's try it again then. [13:05] lord4163: how'd it go? [13:06] Chipaca: didn't work this time [13:06] Chipaca: but happened the first time? :P [13:07] sure it did [13:07] Now whole GNOME Boxes died [13:17] Chipaca: According to journalctl Fabian-PC login[1456]: FAILED LOGIN 1 FROM tty1 FOR kvm guest reboots host [13:17] mvo_, you mentioned duplicating a i18n.go file in each package. Does go tolerate sources that are symbolic links? Cause then you could avoid actual copies of the code at least [13:29] lord4163: i'm not sure what that means [13:33] sergiusens: why isn't setupCloudInit part of first boot? [13:33] mterry: nice idea, I don't know, I guess the package statement in the header is the problem [13:34] mvo_, ugh right [13:35] mvo_, i18n.G() is better than gettext.Gettext() though [13:35] but not as good as G() [13:35] Chipaca: because when I proposed to do that I was told not to [13:35] sergiusens: by whom, and why? [13:36] Chipaca: I wanted an oem snap entry to say cloud: on/off [13:36] Chipaca: and just disable the cloud-init job [13:36] cloud: very yes [13:36] cloud: extra strawberry [13:36] sergiusens: that seems sensible to me [13:36] sergiusens: what was the problem with it? [13:36] mvo_, you could add a i18n package, include a "InjectGettext()" function, then have every package's init() entry point set up a package-wide var for G? [13:37] mvo_, still copied code, but just a one-line init() maybe [13:38] mvo_: mterry: why not “. "yadda/yadda/i18n"”? [13:38] as long as i18n only exposed a single well-known function, that would seem ok to me [13:38] Chipaca, oh right! I forgot you could inline a package. Maybe that's good enough [13:39] * Chipaca would suggest using some non-ascii char for i18n's function, to avoid clashes and because it's extra twisted [13:43] mterry: mvo_: a function called Ꝇ would be nice (it's a capital broken l, because localization! :-p) [13:44] Chipaca, that'll catch on! [13:45] inorite [13:45] mterry: and then we can move tzdata to Ꜩ! [13:46] there are explicit broken letters in utf-8 ? [13:46] wow [13:46] ogra_: 💔 [13:47] hah [13:47] as letters just the L, though [13:47] Chipaca, there's potential here for a whole programming language, akin to brainfuck [13:48] mterry: dude. APL. [13:48] Chipaca, hah, yikes [13:50] mterry: on the other hand, finding all primes in APL is: (~R∊R∘.×R)/R←1↓ιR [13:50] mterry: so we might be on to something [13:52] * Chipaca adds APL to the list of things to never, never learn [13:52] sergiusens: ...? [13:53] lol@Chipaca and mterry [13:54] Chipaca: the ... means? [13:54] sergiusens: what was the problem with it? [13:57] sergiusens, hey, I tried again u-d-f, using DEBUG_DISK=1, I get a "(parted) mkpart system-a ext4 147456s 147455s" which errors out because the start is after the end (first number bigger) [13:57] sergiusens, that's on i386 if that makes a difference [13:58] seb128: --size 10? [13:59] sergiusens, no, why is that needed? isn't that for the writable partition? [14:00] seb128: well each of your a/b parts is now 4GiB instead of 1 [14:01] sergiusens, I don't have 10G free space on that machine, trying again on my other box which has more disk but that's on vivid and trying to build goget-u-t fails on undefined logger.Panicf [14:01] seb128: build as a deb? you need to build on wily [14:02] sergiusens, shrug, that box is vivid ... do you know what I need from wily? [14:02] I tried to update golang* and ubuntu-snappy-cli but that's not enough [14:03] seb128: golang-snappy-dev [14:03] sergiusens, I've the wily version of that [14:03] fgimenez: I'll be with you in a couple of minutes. [14:04] sergiusens, I'm trying a clean build [14:05] hi all [14:05] I'm writing a snap in Go [14:06] I am trying to open a yaml file that is at /apps/go-uploader.sideload/0.3/cnf [14:06] os.Getenv("SNAP_APP_DATA_PATH") send me to [14:06] elopio, ack [14:06] /var/lib/apps/go-uploader.sideload/0.3/cnf/ [14:06] any idea what I what I am doing wrong? [14:07] rickspencer3: you want another envvar [14:07] sergiusens, are the envvars documented somewhere? === chihchun_afk is now known as chihchun [14:09] rickspencer3: https://developer.ubuntu.com/en/snappy/guides/security-policy/ [14:10] Chipaca: thanks, was searching every doc [14:10] rickspencer3: listed, not documented, though [14:10] * sergiusens finds developer.ubuntu.com hard to navigate [14:10] nice [14:10] lol [14:10] Chipaca, do I want SNAP_APP_PATH ? [14:10] rickspencer3: yes [14:10] that one [14:10] ok [14:10] tbhanks [14:10] maybe someone could, you know, list out what each is for ;) [14:10] rickspencer3: or 'snappy install hello-world' and run hello-world.env [14:11] that was in one of the guides I can't seem to find [14:11] that sounds quite indirect [14:11] rickspencer3: i'll add that to the doc i'm writing :) [14:11] Chipaca: wrt yur question, we need this anyways for backwards compat (setupcloud) [14:32] ogra_: are you coming to the meeting? [14:33] elopio, yes :) === davidcalle_ is now known as davidcalle [14:42] rsalveti: ok, if the udf efi has landed, then we should also make the seed changes to add shim - probably retroactively to 15.04 as well? [14:43] * tedg watches carefully [14:43] Which seed exactly? [14:43] :-) [14:56] slangasek: didn't we add all that to 15.04 already a while back? [14:56] sergiusens: 'seed changes to add shim'? no [14:58] seb128: personal doesn't have cloud-init seeded, right? [15:00] rsalveti: do you think https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 will be merged at some point soon? It sounds like it causes no harm if you are running the typical debian install on your emmc with bbb, but helps enormously if you do not run the default image on emmc [15:02] elopio, i've pushed the latest changes https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748, ready for review? [15:03] fgimenez: I see output :) [15:04] elopio, at last! :) [15:05] fgimenez: yes, ready for review, thanks. [15:05] fgimenez: maybe you can add the newline here: [15:05] 256 \ No newline at end of file [15:07] elopio, ok done [15:30] sergiusens, it has, why? [15:32] balloons, elopio, fgimenez, ogra_: mail sent [15:32] thanks dholbach [15:33] seb128: hmm, I am now missing context [15:33] sergiusens, seb128: personal doesn't have cloud-init seeded, right? [15:33] sergiusens, https://launchpadlibrarian.net/209185916/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz [15:33] it's installed [15:35] seb128: is it inherited, planned or $reason? [15:37] sergiusens, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop#L68 [15:37] sergiusens, I guess we copied that from the ubuntu-core seed, we started from there [16:08] mvo_, Why does apt-cache show have seemingly two sections of data? [16:09] tedg: local and remote maybe? [16:09] * mvo_ needs to leave for dinner [16:09] Hmm, okay. Enjoy! [16:33] ok, so I'm working on making a snap for LXD, which for those who haven't heard about it is a container manager based on LXC. That means it's not going to be the simplest snap package in the universe :) [16:33] stgraber: :) [16:34] stgraber, dont look at the docker snap ... i heard people say thats a very bad example :) [16:34] perhaps the different kvm-launching snaps would be better [16:35] currently my main problem is that LXC contains hardcoded paths. I can obviously get it rebuilt to change those, but I just want to make sure I can rely on stuff being at a fixed filesystem location, say /apps//current/ and use that in my buil process [16:35] stgraber: note you can't write to /apps//current though [16:35] we have lvm snaps ? [16:35] *kvm [16:35] and if so, it looks like I'll need two builds, one for local dev (sideloaded) and one for the real thing, as one will have the .sideload suffix [16:35] Chipaca: yeah, that's fine [16:35] stgraber: it would be a lot better if you used the environ for those [16:36] how hardcoded are the paths? [16:36] configure args which wind up hardcoded in a .so [16:36] ugh [16:36] yeah, just de-hardcode them and allow them too be overridden by the $SNAP_* vars [16:37] yeah, not quite looking forward to have to carry patches against upstream for that though (and having upstream be aware of SNAP_ isn't acceptable) [16:37] that would be ideal :) or some LXD_* vars, and set those from these [16:37] stgraber: wrt upstream, LXD_ env vars should be ok with them? [16:37] right, just translate them :) [16:37] you need a shell wrapper anyway [16:37] stgraber: i hear they're a friendly bunch :) [16:37] Chipaca: "maybe" [16:37] jdstrand: hey i'm trying to modify my seccomp file for mir in place on the vm, but seems to fail on the same syscall...is there a way to update? [16:38] Chipaca: the problem is that part of usptream is setuid so we usually wipe our env clean [16:38] or do i have to rebuild/reinstall the snap? [16:38] tyhicks: ^ [16:38] stgraber: that makes sense [16:38] ogra_: what's bad about the docker snap? [16:38] tomconte, it is just a bad example i heard ... [16:38] anyway, will poke around some more, might end up just writting a quick LD_PRELOAD hack for those [16:38] since it has a bunch of exceptions a normal snap wouldnt be allowed to use [16:39] stgraber: do keep us updated if you can [16:39] and holler if you get stuck [16:39] ogra_: ah, I see, but is there a way to package docker in a "clean" way then? [16:40] tomconte, not sure ... i assume the existing docker snap will be updated at some point ... it comes from a time where not much was working in snappy ... nowadays you can get most features you need for a proper docker snap i suspect [16:41] ogra_: it'd still need custom security bits though [16:41] well, but a lot less hacks already i guess :) [16:42] * kgunn wonders, isn't it b/c docker is a framework.... [16:42] kgunn: you can temporarily update the seccomp whitelist for your snap [16:42] kgunn, that too ... but it actually comes from very early snappy days ... we didnt have any story for hardware access and the like back then [16:43] kgunn: what is the failing syscall? [16:43] kgunn: sc-logresolve might help [16:51] jdstrand: when does sc-logresolve print usage()? [16:52] Chipaca, when your patch landed that enables it ? [16:52] noted [16:52] * Chipaca branches it [16:53] but if i suddenly disappear it's because somebody found my runaway dog, not because security gremlins took me down [16:54] so if I set security-override, does that also turn off any cgroup config that's going on with snappy or is there some other thing I need to set to turn that off? [16:55] (LXC has code which will escape the cgroup, so even if I can't turn that off, the cgroup stuff won't apply to me, but that may confuse some things when my process moves out of the cgroup ;)) [17:01] ogra: thanks, asking b/c we were thinking of a snappy+docker image in azure instead of current full_ubuntu+docker [17:01] stgraber: i'd ask jdstrand that one [17:02] jdstrand: heya [17:02] jdstrand: so I'm doing an initial LXD packaging. That's obviously a framework and that's coming with more craziness that docker :) [17:02] jdstrand: so as a first pass, I'm trying to have everything run without any of the security stuff applied to it. So apparmor unconfined, no seccomp policy and no moving stuff into cgroups. [17:02] jdstrand: how do I do that? [17:03] jdstrand: (the client itself just needs networking, so that bit will be confined using default policies + networking) [17:04] jdstrand: eventually the daemon should be running under an apparmor policy, allowing to transition out to any profile we want (same as lxc-start) but still without any seccomp policy. [17:05] tomconte, well, i think you can just go ahead with that ... if docker gets updated it should be transparent to you [17:07] stgraber: the 'unconfined' security template is what you want for running without apparmor or seccomp confinement [17:07] stgraber: I don't recall a way to prevent the launcher from setting up the cgroup - let me look at that code [17:07] note that you need to bribe the store people to let your snap into the store then :) [17:08] I think stgraber is just wanting to get something running locally [17:08] and then we can decide on what to do for the confinement [17:08] (prior to uploading to the store) [17:08] yeah and that thing will be a framework anyway, so manual review was kinda always the plan :) [17:11] stgraber: it looks like the launcher is unconditionally applying the devices cgroup [17:12] I don't have a good workaround for you there [17:13] tyhicks: ok, well, as long as it doesn't get terribly confused when its cgroup ends up being empty, that should be fine [17:13] tyhicks: LXC has code that will trigger an absolute cgroup move for all controlers, so it'll escape whatever cgroup the launcher creates for it [17:14] ok [17:15] stgraber: sorry, was in a meeting [17:15] stgraber: so the launcher decides when it is going to do the cgroup thing [17:15] ogra_: https://code.launchpad.net/~chipaca/ubuntu-core-security/usaaage/+merge/262115 just for you :) [17:16] tyhicks: are you looking at the code now for that ^ [17:16] tyhicks: my comment, not Chipaca's :) [17:17] Chipaca: oh gosh, sc-logresolve patch. that thing is barely more than back-of-a-napkin as it is :P [17:18] jdstrand: :) [17:18] jdstrand: I already looked at the code - it sets up the devices cgroup unconditionally [17:18] jdstrand: st graber says that shouldn't be a problem for him at the moment [17:18] tyhicks: hmmm, what was I thinking of then... seccomp? [17:19] I know it is making a choice about something, cause docker was grumpy about said something [17:19] or at least, it was making a choice [17:19] I'm not sure about that [17:19] let me look again [17:22] Chipaca, LOL ! [17:22] stgraber, jdstrand: I guess if ("/var/lib/apparmor/clicks/%s.json.additional", appname) is empty it won't set up the devices cgroup [17:22] that's ringing a bell [17:23] it doesn't have to be empty - it just can't match a hardcoded string in the launcher [17:23] actually I think I documented that [17:23] but creating an empty file is the easiest [17:23] https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Cgroups [17:24] "Note: because device names are not always static and due to limitations in AppArmor (1350598, 1444679), the device cgroup mechanism is only used when hardware is assigned to a snap, at which point a general write rule for... Conversely, when no hardware is assigned to the app, then the strict AppArmor rules are in effect and an app-specific cgroup is not used. " [17:25] ah [17:25] right [17:25] so just make sure that ("/var/lib/apparmor/clicks/%s.json.additional", appname) doesn't exist [17:25] I knew there was a reason I wanted to write that down :) [17:25] tyhicks: right, and it won't by default [17:26] an oem snap or hw-assign needs to be used [17:26] got it [17:26] I <3 documentation :) [18:03] * lborda asks: any idea how do I get python-smbus in snappy ? i didn't find the package in the ports repo. [18:16] lborda: there isn't a python-smbus in ubuntu, even [18:16] lborda: but you could probably use the one from debian as a starting place [18:16] huh ? how can it be in debian but not ubuntu [18:17] Chipaca, yes there's only in debian https://packages.debian.org/wheezy/python-smbus [18:18] Chipaca, i am trying to get the pyglow working on the snappy image... have any of you tried with the pyglow ? [18:18] http://ports.ubuntu.com/pool/universe/i/i2c-tools/ [18:18] ogra_: [18:18] ｍａｇｉｃ [18:18] there is definitely a python-smbus [18:19] ogra_: but then why isn't there a python-smbus? [18:20] even my phone sees it [18:21] john@fogey:~$ apt-cache search python smbus [18:21] john@fogey:~$ [18:21] * Chipaca wonders [18:21] no universe ? [18:22] i would thought the the python-smbus package would have to be found inside the universe/p/ folder and not inside pool/universe/i/i2c-tools/ [18:22] the folders are sorted by source package name ;) [18:22] deb http://archive.ubuntu.com/ubuntu vivid universe [18:23] python-smbus is a binary [18:24] http://paste.ubuntu.com/11726399/ [18:24] Chipaca, oh, you have an archive.u.c entry on an armhf machine ? [18:25] no, this was on my desktop [18:25] amd64 [18:25] ah [18:25] * Chipaca just noticed there is still a debian ia64 port [18:26] well, my amd64 laptop finds it too [18:26] ogra@styx:~$ apt-cache policy python-smbus|grep archive [18:26] 500 http://archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages [18:27] ok, i'm going to close my computer and go have dinner and pretend weird things are not going on [18:27] because the gammon smells very good and i'm not going to let some silly smbus weirdness ruin it :) [18:27] Just to add to this, I used rmadison against python-smbus: [18:27] http://pastebin.ubuntu.com/11726413/ [18:28] (which is actually the right tool ... yay us ... ) [18:40] tyhicks: sorry, was out to lunch...yep, so this is what i'm seeing https://www.youtube.com/watch?v=dbl81P2Vae4 [18:40] and its munmap [18:40] that's the syscall [18:47] mvo__, so I guess with these gettext branches, we need to push a deb package for the gettext module to wily? [18:47] * mterry was just looking into adding a debian/ dir for snapcraft [18:49] kgunn: something's not right there - munmap is allowed in the default seccomp template (many things would break if we didn't allow munmap) [18:50] kgunn: the resolution isn't great but it looks like you're modifying a seccomp filter file in /apps/mir/snap1/meta/mir.seccomp - is that right? [18:53] tyhicks: correct [18:54] and i see it showing up in that copy as well as the one at [18:54] /writable/system-data/apps/mir/snap1/meta/mir.seccomp [18:59] kgunn: odd - the launcher looks for seccomp filter files in /var/lib/snappy/seccomp/profiles/ [19:01] tyhicks: ahha, i see that now...and it's missing, but it's filename is just mir_system-compositor-snap1 [19:01] i was expecting it to be mir.seccomp [19:02] tyhicks: so i'm guessing this is the file to modify... [19:02] kgunn: yeah, give that one a shot and let me know if it works [19:03] tyhicks: awesome thank you!....got a new syscall failure....perfect [19:03] tyhicks: at your earlier statement at it being strange, is it b/c i'm a framwork and having to create my own policy ? [19:04] e.g. i lose all the defaults out of the box when i create my own [19:04] tyhicks: and should i just start by copying some particular default file (template) of syscalls permitted ? [19:05] kgunn: ah, yes - now it makes sense [19:06] kgunn: this is the default template: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/view/head:/data/seccomp/templates/ubuntu-core/15.04/default [19:06] kgunn: ah, I meant to follow up with you [19:06] jdstrand: is there any way for a framework to reuse the default template? [19:06] (for seccomp) [19:08] what I have been recommending is installing hello-world.canonical from the store, then scp'ing /var/lib/snappy/seccomp/profiles/hello-world*env into meta/foo.seccomp then referencing foo.seccomp in "security-policy" [19:08] kgunn: so, in your case, on the device, do "sudo snappy install hello-world.canonical" [19:09] kgunn: then do: cd /var/lib/snappy/seccomp/profiles/ [19:09] kgunn: then, sudo cp hello-world.canonical_env_1.0.17 ./ [19:09] perfect guys...thanks, but struggling has helped it make sense [19:10] kgunn: then see if it works. if it doesn't, just add syscalls to the end of ./ until it does [19:13] one could also do: sed 's/^deny/# EXPLICITLY DENY/' /usr/share/seccomp/templates/ubuntu-core/15.04/default > your.seccomp [19:13] that is harder to remember [19:15] kgunn: iirc, that was all you needed from me yesterday (sorry I didn't see until you were eod) [19:46] jdstrand, regading rickspencer3's bug i actually wonder what image he runs there ... (might be one of the broken RPi ones for example) [19:47] ogra_, if you are talking about my net_admin denial ... it's an update amd64 image [19:47] ogra_: I confirmed it on amd64 snappy, vivid desktop and precise desktop [19:47] it is something else [19:47] (including system-image-cli -i should be mandatory for bug reporting on snappy ;) ) [19:47] jdstrand, ah, k [19:47] rickspencer3, thanks [19:48] ogra_: note, I advised rickspencer3 on what to put in the bug. This seems to be a golang thing but until we know what is tickling that denial, I didn't know where to put it, so we put it in the snappy project for now [19:48] ah [20:00] ogra_: kickinz1: fwiw, an apt-get update fixed it, whatever it had been [20:09] Chipaca, you seem like you would know [20:10] when do I use SNAP_APP_USER_DATA_PATH, [20:10] vs. SNAP_APP_DATA_PATH [20:10] ? [20:10] rickspencer3: i'm not particularly clear on the difference myself, *however* [20:10] nice [20:10] lol [20:10] rickspencer3: i do know that SNAP_APP_USER_DATA_PATH is owned by the user [20:10] rickspencer3: and SNAP_APP_DATA_PATH is owned by not-the-user [20:11] Chipaca, ok, if I wrote a program that saved files from sensor data, which envvar would I use for saving the file in? [20:11] (and consequently for uploading the file to the cloud service) [20:11] rickspencer3: is that a daemon, or a one-off? [20:11] rickspencer3: daemons will run as root [20:11] daemon [20:12] Chipaca, oh [20:12] well, it is a service [20:12] don't know if it is daemon per se [20:12] rickspencer3: so SNAP_APP_DATA_PATH should work [20:12] i meant service, yes [20:12] I declare it as a service, and then use for{time.sleep()} [20:12] ok [20:12] thanks Chipaca [20:13] use a time.Ticker, but yes [20:13] ? [20:13] rickspencer3: go? [20:13] Chipaca, yes, but the samples I saw said for{time.sleep()} ... time.Ticker sounds somewhat more sensible, though [20:14] rickspencer3: for long-lived processes, inside a loop, a time.Ticker is better [20:14] ok, I'll do some Googling and fix that up [20:14] time.Sleep is straightforward, but will incurr a higher gc overhead over time [20:14]