[00:30] cprov: sergiusens: hey, sorry, I couldn't access quassel for quite a while. Indeed, I had a typo on my exported var :/ [00:30] sorry for the noise. [00:39] PR snapd#2071 opened: interfaces,overlord/interfaces: switch to use declaration-based checking for auto-connect [01:26] PR snapd#2072 opened: cmd/snap: have 'snap autoimport' consider unmounted devices [01:29] PR snapd#2068 closed: many: preparations for switching most of autoconnect to use the declarations [01:50] elopio cprov I am not oposed to a tools/staging_env.sh that one can source setting up the env and PS1 ;-) [01:51] sergiusens: that's a grand idea [01:53] cprov elopio I am on and off, but here's a bug just in case it falls off the radar LP: #1630083 [01:53] Bug #1630083: Provide sourceable script to work with the staging environment === JanC_ is now known as JanC [04:07] PR snapd#2073 opened: client, cmd/snap, daemon: add is-managed command [06:25] zyga: udev rules are all about events; so both a boot aand udevadm trigger will run every rule, so just attach it to teh "add" event of a device which provides the GPIO pins? [06:26] zyga: /sys/class/gpio/export, is that really a global thing? that doesn't sound like something you should change in udev rules then [06:26] or was that just simplifid/a template path? [06:33] PR snapd#2074 opened: add /users endpoint and auto run `snap create-user --known` for unowned devices [06:37] * kalikiana found bug 1576303 whilst trying to listen to Japanese music on the VLC snap [06:37] Bug #1576303: Needs fontconfig integration [06:39] good morning [06:53] morning [06:57] pitti: it wasn't simplified, that's the actual thing [06:57] could anyone educate me how to call /sbin/ifconfig in a snap app? i see some relative discussion in https://bugs.launchpad.net/snappy/+bug/1615124 but no idea how to use and which interface is right one. thanks [06:57] Bug #1615124: apps should be able to run /usr/bin/shuf by default [07:17] PR snapd#2073 closed: client, cmd/snap, daemon: add is-managed command [07:23] Bug #1630145 opened: out of disk space needs better handling [07:43] PR snapd#2075 opened: cmd/snap: add version command, same as --version [07:46] PR snapd#2026 closed: client, cmd: connect fixes [07:50] zyga: ping [07:56] pitti, hello! would you approve snap-confine into xenial-proposed, please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snap-confine [08:12] morphis_: hey [08:12] zyga: hey! [08:12] morphis_: sorry, I'm laggy, not slept much last night [08:13] zyga: np :-) [08:13] zyga: you already did the PR to fix the mount problem we have with the udisks2 snap? [08:13] was looking for it but didn't found one? [08:13] s/one/one?/ [08:13] morphis_: no, though almost, I need to work on the all-snap side of the problem [08:13] zyga: what is different there? [08:14] morphis_: the initial fs is / [08:15] morphis_: https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9 [08:15] morphis_: I need to finish one more bit for snapd and then I'm back to confine, we're freezing this week [08:15] (well, today) [08:15] zyga: actually this is required to be fixed before the freeze [08:17] morphis_: we can still change images after today so it will get fixed [08:17] morphis_: it will be in the released images [08:17] dpkg: error processing archive /var/cache/apt/archives/snapd_2.15.2ubuntu1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snap 2013-11-29-1ubuntu2 [08:17] :) [08:18] zyga: so by when? last week you said there will be a PR later that day [08:18] Skuggen: I think it is a known issue, I think it was fixed but perhaps that's not the case [08:18] morphis_: I spent literelly two weeks on this issue [08:18] morphis_: there's lots of hard edges there [08:18] zyga: https://bugs.launchpad.net/ubuntu/+source/snap/+bug/1589037 just confirmed so far [08:18] Bug #1589037: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.5 [08:18]

[08:19] zyga: good, so do you need any further help? Lean suggested to ask Seth to help you with any further problems on the mount namespace [08:19] morphis_: I'd love some help on that if you want to, we know how it works now but the all-snap is significantly different that someone has to sit on it and push through the issues [08:19] morphis_: well, the mount namespace has been released, this is /media sharing [08:20] morphis_: it's not a problem of "how do we do it" anymore, that part is solved [08:20] morphis_: this is just some extra coding time that's required now [08:20] zyga: so what the actual issues? [08:21] morphis_: take that branch and iterate on an all-snap system, it needs to be tweaked to use different rootfs_dir and the apparmor profile needs to be adjusted [08:21] morphis_: then if it doesn't crash the kernel and /proc/self/mountinfo looks sane then we're good [08:22] morphis_: apparmor profile needs to be cleaned up a little as it it now full of redundant rules [08:22] morphis_: it just need polish [08:22] zyga: which branch? [08:22] morphis_: https://github.com/snapcore/snap-confine/commits/media-sharing [08:22] morphis_: I don't recommend anthing but a full blown VM [08:23] morphis_: one line wrong and you hose your box [08:25] morphis_: it would be amazing if we managed to run spread on master (not this branch) on an all-snap system [08:25] morphis_: in qemu or linode [08:25] morphis_: if you could get that, it would save me a lot of time [08:25] morphis_: I think qemu is easier and I would find it sufficient [08:27] zyga: I must say I don't see where the actual rootfs change would come into this code change [08:27] morphis_: look at the new struct [08:27] it is called... [08:28] rootfs_dir :) [08:28] https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9#diff-0ec19215f6a6c97084d2e4eb5e0b54ccR546 [08:28] ah [08:28] zyga: there seem to be a lot other TODO's [08:29] morphis_: specifically? [08:29] I count atleast three from the commit message [08:29] morphis_: ah, some of those are stale [08:29] morphis_: if spread passes you're in good shape [08:29] morphis_: I think /etc needs love on actual sharing [08:30] morphis_: it works but I think it's setup wrong [08:32] zyga: so what else do you have on your plate which prevents you from finishing this? [08:32] morphis_: just one branch on snapd, carry over from last night [08:33] https://github.com/snapcore/snapd/pull/2066 specifically [08:33] PR snapd#2066: many: abbreviated forms of disconnect [08:36] zyga: which would mean you will get back to the snap-confine later today? [08:37] morphis_: yes, totally [08:37] morphis_: nothing else on my plate [08:37] zyga: I don't really have much time to support here and it looks like you're the best to get this fixed quickly [08:37] zyga: so how much more time you need to finish this? [08:39] morphis_: I think one more day, I bet the non-all snap version will be 100% done today, including nice aa profile, the all-snap is probably trivial but maybe there are dragons, I didn't try yet [08:40] zyga: non-all snap is not really the problem, we need this for all-snap [08:40] in the end we want both but all-snap should be IMHO the priority [08:41] morphis_: it needs to work in both cases but I think we're very very close [08:42] yeah [08:42] morphis_: just figuring out the sequence of do's and don'ts was the hard part :) [09:04] How does snappy figure out dependencies for simple binary inclusions? run ldd? [09:17] PR snapd#2076 opened: asserts: limit model to only lowercase until we can implement case insensitive/preserving headers [09:19] Skuggen: yes, i think so [09:49] sergiusens: ping [10:05] could anyone educate me how to call /sbin/ifconfig in a snap app? i see some relative discussion in https://bugs.launchpad.net/snappy/+bug/1615124 but no idea how to use and which interface is right one. thanks [10:05] Bug #1615124: apps should be able to run /usr/bin/shuf by default [10:08] shuduo: hey [10:09] zyga: hi [10:09] shuduo: please use the network-control interface [10:09] :-) [10:10] zyga: yes, i added it but snappy-debug still report "Log: apparmor="ALLOWED" operation="create" profile="snap.connman.connman//null-/sbin/ifconfig" pid=7741 comm="ifconfig" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none" [10:11] so i guess some lines needed in snapcraft.yaml too [10:11] hmmm [10:11] that may depend on what you use ifconfig for [10:11] can you pease file a bug on snappy (on launchpad) with more informatio [10:11] it is much better than figuring it out here, most of the team is busy working on the release [10:11] and some last few bits for it [10:12] zyga: okay. understand. i will. do you know if any exist snap use ifconfig then i can refer to? [10:12] shuduo: I don't know, sorry [10:13] zyga: no worry. thanks. [10:19] ppisati, regarding the question in bug 1627643 i think you ned to ask mwhudson or pitti [10:19] Bug #1627643: oops on pi3 (seemingly wlan related)

[10:20] (not sure it is actually possible at all to run nplan on a xeianl classic install) [10:20] *xenial [10:24] ogra_: does it need yakkety? [10:24] ogra_: it will be soon, see bug 1627641 [10:24] Bug #1627641: Backport netplan to xenial

Progress by pitti> [10:24] ogra_: i can build a yakkey img if needed [10:25] ppisati, well, the userspace would be totally different and we dont have yakkety snappy [10:25] (i mean snappy images ... classic + snap might work) [10:27] ogra_: yeah, but you said 'not sure it is actually possible at all to run nplan on a xeianl classic install' so i thought you needed some yakkety bits [10:27] ppisati, yes, netplan :) [10:27] (and its dependencies) [10:40] ppisati, i also have the impression it is somehow related to firstboot i seem to not get the oops on second boot either here === hikiko is now known as hikiko|ln [10:46] morphis hello hello [10:50] ogra_: but do you actually get an oops? because on first boot, my wifi doesn't get any ip and nothing is printed out [10:50] ogra_: just a generic 'Fail to blabla' from nplan [10:50] ogra_: and upon reboot, my wifi associated immediately [10:50] ppisati, i only see the wifi interface very rarely (every 10th boot or so) [10:50] but no oops at all [10:50] most of the time there is the oops and the device isnt shown at all in console-conf [10:51] so it's before the config phase the oops [10:51] the prob iss that a reboto breaks the image completely [10:51] *reboot [10:52] (the snappy firstboot stuff only runs after console-conf completed ... and it breaks if it gets re-run on an already booted image) [11:01] niemeyer, mvo, bug 1630145 made me think ... unrelated to diskspace, snapd should probably run with an oom_score_adj "- 500" value ... so it doesnt get killed early on OOM events [11:01] Bug #1630145: out of disk space needs better handling [11:15] PR snapd#2077 opened: overlord/devicestate,docs/hooks.md: switch prepare-device/registration opts to use nesting, some hook docs [11:20] mvo, niemeyer, i filed bug 1630208 for the above [11:20] Bug #1630208: snapd should be excluded from OOM [11:21] oh interesting [11:21] Bug #1630208 opened: snapd should be excluded from OOM === hikiko|ln is now known as hikiko [12:00] PR snapd#2064 closed: interfaces/builtin: add autopilot-introspection [12:01] sergiusens: hey! small quetsion, I can't find the bug reference anymore, but I'm pretty sure there was one on organize: not supporting globbing (so that you can dump the copy plugin in favor of… dump!), do you think you have time working on tihs? [12:01] this* [12:02] didrocks it is already released [12:02] oh [12:02] it's the version in -proposed? [12:03] that's probably why I couldn't find it :) [12:03] didn't check for closed ones [12:04] didrocks https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_pluginhandler.py#L676 [12:04] didrocks should be in -updates since 3 or 4 weeks ago [12:05] sergiusens: interesting, I was sure I tried a couple of weeks ago [12:06] sergiusens: so "*" : "www/" should work from what I see in the test [12:06] didrocks yes [12:06] didrocks if not, we have anew bug :-( [12:07] sergiusens: oh, I did try ".": "www" as in the copy plugin [12:07] probably [12:07] * didrocks gives it a try [12:08] oh, different semantics indeed [12:08] I prefer *, makes more sense IMHO [12:12] sergiusens: so, I'm getting: Trying to organize file '*' to 'www', but 'www' already exists [12:13] something (I guess snapcraft) did create indeed a "www" file [12:13] I want to put everyting in www [12:13] maybe the syntax is rather: "*": "www/" [12:16] sergiusens: that did it! Thanks a lot :) [12:30] didrocks \o/ [12:32] shuduo: please file a bug at https://bugs.launchpad.net/snappy/+filebug with steps to reproduce. you should be using 'plugs: [network-control]' to use ifconfig, however, connman is doing something different with ifconfig that isn't included in the policy atm [12:33] jdstrand, hi, thanks for the thorough review. I have pushed changes to the PR, with a couple of questions too [12:35] ok [12:35] thanks :) [12:35] sergiusens, I was wondering about your opinion on using config flags to set file paths when compiling using autotools snapcraft plugin [12:35] jdstrand: it's a customer's app intend to do what connman doing. i'm trying to get source code. [12:35] sergiusens, we are checking $SNAP in some programs to know if it is part of a snap or not [12:36] sergiusens, maybe using a standard configure flag would be better and make changes more palatable for merging in upstreams [12:36] shuduo: it's possible to debug via irc. do you have time now? [12:38] jdstrand: i have time but don't have source code. is it possible? :) [12:38] abeato that's what we did for click; a nice configure flag we can standarize on would be great practice; all these configure flags are just convention after all [12:39] shuduo: yes, I'll give you rules to add and you tell me what you see in the logs [12:39] jdstrand: good [12:39] sergiusens, promoting a couple of standard configure flags would certainly be great :) [12:39] shuduo: first off, does your app require devmode for other things or are you using devmode only for this one denial? [12:40] sergiusens, maybe paths to data, to daemon data, and to current snap [12:41] jdstrand: i already use devmode in yaml and also installation. [12:42] shuduo: you misunderstand. must you use devmode? I'd prefer to use strict mode for policy debugging but if your app doesn't work at all in strict mode, then we can leave it [12:42] jdstrand: okay. let me modify it. [12:43] jdstrand: i thought if devmode works then i can try strict mode. [12:45] shuduo: you are doing the right thing. but for security policy development I prefer strict mode [12:46] jdstrand: i changed it to strict and scanlog output is http://pastebin.ubuntu.com/23274922/. [12:47] shuduo: can you give the output of 'snap interfaces'? [12:48] jdstrand: http://pastebin.ubuntu.com/23274935/ [12:48] shuduo: please connect the interfaces with: [12:49] sudo snap connect connman:firewall-control ubuntu-core:firewall-control [12:49] sudo snap connect connman:network-control ubuntu-core:network-control [12:49] sudo snap connect connman:network-manager ubuntu-core:network-manager [12:50] (though I wonder about that last one-- is it supposed to talk to NetworkManager? [12:50] ) [12:53] jdstrand: now output is http://pastebin.ubuntu.com/23274944/ [12:54] seems no complain for ifconfig [12:54] shuduo: ok, so your snap has a little bit of work to do to make ListOfServers.txt relocatable, but we can hopefully work around that [12:54] shuduo: oh, would you have seen the ifconfig denial by this point? [12:56] jdstrand: no ifconfig denial now. [12:57] shuduo: ok, so maybe you just needed to connect the interfaces. you need to do that in devmode too [12:57] jdstrand: in ubuntu desktop, the app will create a file ListOfServvers.txt in working directory. [12:57] (in devmode if you don't connect, the accesses that are against policy are allowed, but logged. to make the logging go away, connect the interfaces) [12:59] shuduo: you should 'cd "$SNAP_DATA"' before starting-- or choose one of the other SNAP_* variables [12:59] shuduo: and by 'you', I mean your snap [13:00] jdstrand: so i guess i need a wrapper to 'cd "$SNAP_DATA"', right? [13:01] shuduo: yes [13:04] jdstrand: in strict mode, the app will exit with "Failed to open default display". In devmode, it exit with "XOpenIM() failed. Unable to find fonts. check your FontConfig configuration." i claimed unity7 in snapcraft.yaml. anything missed? [13:04] PR snapd#2078 opened: daemon: fix login API to return local macaroons [13:06] shuduo: we are getting out of my area of expertise (I work on security policy). I suspect you need to use the desktop/gtk3 part [13:06] shuduo: eg: [13:06] parts: [13:06] jdstrand: hey, how are you [13:06] something: [13:06] ... [13:06] after: [desktop/gtk3] [13:06] meh [13:06] parts: [13:06] something: [13:06] ... [13:07] after: [desktop/gtk3] [13:07] shuduo: something like that ^, but will need others in the channel to help if that doesn't work for you [13:07] zyga: hi! :) [13:08] jdstrand: okay. thanks a lot! [13:17] PR snapd#2079 opened: tests: use test snap from the store in the content interface test === rokf_ is now known as rokf [13:51] PR snapd#2080 opened: daemon: do not hardcode UID in userLookup [13:52] ogra_: would you by any chance now where the ubuntu-core snaps are built for stable and edge? [13:55] lool, we only build edge and propagate it ATM ... [13:55] lool, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core [13:56] lool, plan is to have all PPA bits SRUed by GA and then build beta/candidate without the PPA ... but keep edge on PPA with daily builds [13:56] ogra_: is there a cron scheduling this daily? [13:56] lool, yep [13:57] oh we even build it on s390x and ppc64el [13:57] ogra@lillypilly:~$ crontab -l [13:57] 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1 [13:57] 0,30 * * * * /home/ogra/public_html/ubuntu-core-builds/generate-core.sh >>/home/ogra/public_html/ubuntu-core-builds/generate.log 2>&1 [13:57] ogra@lillypilly:~$ [13:57] ogra_: ah I see we do the extra ppa thing in livecd-rootfs [13:57] snappy-dev/image snappy-dev/edge [13:57] right [13:58] for beta/candidate we'll have a branch with this dropped [13:59] and edge has daily github builds of master I guess [13:59] https://launchpad.net/~snappy-dev/+archive/ubuntu/edge [13:59] ouch loads of stuff in https://launchpad.net/~snappy-dev/+archive/ubuntu/image [13:59] lool, https://wiki.ubuntu.com/QATeam/OSSnapPromotion [13:59] thats the long term plan [14:00] lool, well, you want https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial [14:01] ogra_: if I look at xenial, there are 3 uploads from you which are superseded that we might be able to drop [14:01] https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [14:01] lool, not yet ... they are in -propposed (LP UI lies) [14:01] apart from snapcraft i think [14:01] that can actually be dropped [14:02] ah, no, not yet [14:02] but yeah, i check it every day [14:02] ogra_: ok, nice [14:02] for initramfs-tools i'm waiting til cyphermox and lamont are done with theit ipv6 hackery before even attempting to land the fixtrc fix [14:03] *their [14:03] i dont want to cause mid-air clashes of uploads there [14:03] I wonder if we should have snap-confine from edge too [14:03] it's recent in the image PPA though [14:03] pitti: did you had a chance to check https://code.launchpad.net/~jocave/netplan/+git/netplan/+merge/307531 ? sorry for the nudge, its somewhat urgent for the team that works on that [14:04] lool, perhaps [14:04] lool, thats a zyga decision :) [14:05] lool, oh, and on a sidenote we also have daily images built from the edge snap http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ [14:05] s/snap/snaps/ [14:06] ah that's useful [14:06] albeit I can just switch to edge ubuntu-core if I need that [14:06] (these builds happen on my home desktop and get rsynced though ... waiting for infinity to get use dailies on cdimage) [14:06] s/use/us/ [14:29] PR snapd#2080 closed: daemon: do not hardcode UID in userLookup [14:31] PR snapd#2078 closed: daemon: fix login API to return local macaroons [14:32] pitti: hi, i would appreciate some feedback on this as soon as you can https://code.launchpad.net/~jocave/netplan/+git/netplan/+merge/307531 [14:35] zyga: did you get the extra info you requested on the udev rules? [14:37] PR snapd#2077 closed: overlord/devicestate,docs/hooks.md: nest prepare-device configuration options [14:44] ogra_: have you tried the new snapcraft in proposed? [14:45] elopio, not yet, i'll pull it in for the next build before EODing [14:45] thanks for the remonder (totally forgot about that) [14:45] *reminder [14:47] PR snapcraft#848 opened: `sign-build` to prompt users for key selection [15:02] kyrofa: ping [15:06] elopio, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core is now building with the new snapcraft ... if s390x finishes without failure the fix is good to go [15:07] joc: replied [15:11] PR snapd#2081 opened: snap: relax auto-import test [15:15] ogra_: thanks. Let us know when done to add the verification-done tag [15:16] PR snapd#2082 opened: overlord,daemon,snap: support gadget config defaults [15:16] elopio, done :) https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5985 [15:16] (all arches ... so i dont think there are regressions either) [15:26] Bug #1630281 opened: fltk-based app snap exit with "XOpenIM() failed" [15:30] morphis_, pong [15:31] kyrofa: hey! [15:31] kyrofa: I was trying the configuration hook today with one of my snaps but I somehow miss steps to see if it was actually run or if something has failed [15:31] kyrofa: if a hook prints something to stdout where should this appear? [15:33] morphis_, I believe it gets swallowed unless the hook encounters an error. Try exiting non-zero [15:33] tried that [15:34] but snap set didn't return with an error [15:34] PR snapd#2083 opened: cmd/snap: generate account-key revocation requests [15:34]