[00:35] PR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis [00:38] PR snapcraft#1043 opened: tests: fix the CLA launchpadlib install in travis [01:10] anybody know the localhost login details for ubuntu snap core ? [01:10] I downloaded the ova from here http://cloud-images.ubuntu.com/snappy/devel/core/current/devel-core-amd64-cloud.ova?_ga=1.214375895.1790561723.1484162457 === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [03:23] PR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis [03:29] PR snapcraft#1044 opened: tests: use python2 to check the CLA === chihchun_afk is now known as chihchun === JanC is now known as Guest39941 === JanC_ is now known as JanC [06:13] Bug #1655834 opened: Support factory reset [07:11] PR snapd#2544 closed: interfaces: implement login-control interface [07:47] o/ [07:49] hey mvo [07:50] hey zyga [08:57] PR snapd#2554 closed: tests: add end-to-end store test for classic confinement [08:57] PR snapd#2605 closed: overlord,overlord/snapstate: have UpdateMany retire/enable auto-aliases even without new revision [09:11] PR snapd#2469 closed: interfaces: upower-observe: refactor to allow snaps to provide a slot [09:14] PR snapd#2616 opened: tests: test classic confinement `snap list` and `snap info` output [09:26] PR snapd#2617 opened: tests: switch more tests to MATCH [09:38] stokachu https://github.com/snapcore/snapcraft/blob/master/snaps_tests/__init__.py#L180 [09:46] sergiusens, https://github.com/juju/juju/blob/staging/snapcraft.yaml [09:50] PR snapcraft#1038 closed: misc: delete bzr ignore [10:03] icey https://bugs.launchpad.net/bugs/1655832 [10:03] Bug #1655832: App name in snapcraft.yaml must match case of .desktop file [10:05] yeah sergiusens? [10:47] PR snapd#2618 opened: tests: run all spread tests with SNAP_REEXEC={0,1} [11:30] PR snapd#2606 closed: overlord/snapstate: share code between Update and UpdateMany, so that it deals with auto-aliases correctly [11:48] sergiusens: I think I got the linker flags in [11:51] PR snapcraft#928 closed: Add missing dependencies to install_requires [12:02] jdstrand: FYI, snap-alter-ns won't be setuid root, it will just be started by snapd (like snap-discard-ns) [12:02] jdstrand: we can choose to confine it but I wanted to make sure you know this [12:03] PR snapd#2567 closed: debian: skip snap-confine unit tests on nocheck [12:04] PR snapd#2619 opened: many: update 14.04 branch to top of master [12:05] PR snapd#2616 closed: tests: test classic confinement `snap list` and `snap info` output [12:06] PR snapd#2620 opened: store: export userAgent. daemon: print store.UserAgent() on startup [12:25] how do i get into the shell of a snap again? [12:25] snap run --shell conjure-up doesn't seem to do what i need === ben_r_ is now known as ben_r === hikiko_ is now known as hikiko [12:42] stokachu: `snap run --shell the-snap` should do what you need [12:42] stokachu: how is it not? [12:42] that is, what do you need, and what are you getting? [12:43] so im building juju inside my snap but I think the problem is hte juju binary isn't getting copied into the snap [12:43] still working that out [12:43] stokachu: that gives me more questions, but doesn't answer mine :-D [12:44] yea sorry still trying to understand what im doing [12:46] Chipaca: http://dpaste.com/361CKWW basically trying to expose the juju binary alongside conjure-up [12:47] mvo: do you know if there is a clear reason why every systemd service unit snapd generates wants the network-online.target? [12:47] stokachu: you did "snap run --shell conjure-up" [12:47] Chipaca, yea [12:47] stokachu: what did that do? and what did you expect it to do? [12:47] it brought me into a new shell and i was looking for the juju binary that wasn't there [12:49] stokachu: i'm missing somemething, i fear [12:50] Chipaca, sorry, i built my conjure-up snap while pulling in the juju part from the wiki, in the end i want to be able to run both conjure-up and juju binaries from that single snap [12:51] stokachu: "snap run --shell conjure-up" is giving you a shell in the environment that apps in the conjure-up snap would see [12:51] stokachu: (modulo connections) [12:51] Chipaca, ok, now im trying to figure out why that juju one isn't showing up in the file list [12:51] Chipaca, using --classic [12:51] morphis: no clear reason [12:51] morphis: if that is a problem we can kill it [12:51] stokachu: when you say "in the file list", you mean in the snap? [12:52] Chipaca, yea [12:53] should it be conjure-up.juju as the command name? [12:53] yes [12:53] how can i make it just juju? with an alias? [12:53] stokachu: yes [12:54] stokachu: but: is juju in conjure-up something users are expected to interact with? [12:54] Chipaca, yea, juju needs to talk to the agent installed inside that snap [12:54] PR snapd#2619 closed: many: update 14.04 branch to top of master [12:55] mvo: not a urgent thing to fix but it conflicts with network-manager when I add a Alias=NetworkManager.Service in the generated unit file [12:55] as it then has a cycle of dependencies === mcphail_ is now known as mcphail [13:19] trying to get this juju binary include but hitting http://dpaste.com/2XNXGRW [13:20] the part im pulling in is https://github.com/juju/juju/blob/juju-2.0.2/snapcraft.yaml === beowulf_ is now known as beowulf === hikiko_ is now known as hikiko|ln [13:35] zyga: any idea about https://paste.ubuntu.com/23786689/? I am using a 3.4 kernel here so could be something not well supported by that ancient kernel but would like to understand this a bit more [13:54] PR snapd#2620 closed: store: export userAgent. daemon: print store.UserAgent() on startup [14:04] morphis: looking [14:04] morphis: 3.4 [14:04] morphis: mount namespaces [14:05] morphis: do you see /proc/self/ns ? [14:05] morphis: if not then 3.4 is too old [14:05] I honestly don't expect 3.4 to work [14:11] https://paste.ubuntu.com/23786828/ [14:12] PR snapd#2618 closed: tests: run some spread tests with SNAP_REEXEC={0,1} [14:12] morphis: there's no mnt entry there [14:12] morphis: the error is confusing but 3.4 is too old [14:12] morphis: and there's no way to solve it easily without a major feature in snap-confine [14:13] (I discussed this a while ago but this is 2-3 weeks to do) [14:13] morphis: what is the HW if you can disclose this? [14:13] zyga: I see [14:14] morphis: if I end up writing this I'd like to know if I have it on my desk === hikiko|ln is now known as hikiko [14:20] zyga: see PM [14:28] morphis: got it now [14:28] morphis: if we chat on rocket I get better notification [14:53] zyga, snapstore supports delta downloads now right? [14:59] PR snapd#2617 closed: tests: switch more tests to MATCH [15:00] zyga: :-) [15:03] stokachu: yes but the client needs a special variable to enable that [15:04] zyga, when will that get enabled by default? [15:04] stokachu: I don't know, that's a question to chipaca (not on IRC now) and nessita [15:04] ok thanks [15:04] zyga, no, *you're* not on irc [15:04] oh [15:04] odd [15:04] tab tab gave me nothing, sorry about that [15:04] :) [15:05] we don't have delta downloads enabled by default [15:05] because of the xdelta3 dependency [15:05] Chipaca, is that something that is in the works to be done soon? [15:06] stokachu, it's paperwork [15:06] but afaik it's moving forwards [15:06] so it'll get done in time [15:06] i mean: the code is there [15:06] Chipaca, ah ok awesome [15:06] and you can even use it if you set the right env var [15:07] cool is it documented anywhere? [15:07] dunno. SNAPD_USE_DELTAS_EXPERIMENTAL=1 in snapd's environ will do it [15:07] cool thanks [15:08] and, you need xdelta3 [15:10] jdstrand: hey [15:12] jdstrand: did you read about the new BFP attachments to cgroups? [15:19] zyga: yes. I assume you are refering to the comment in the 'ip netns' PR. I just commented there [15:19] jdstrand: actually no, I read the article on LWN [15:19] jdstrand: I'll check the PR [15:21] zyga: the pr doesn't mention bpf, but it was talking about network mediation, so I thought you were going there [15:24] hi could i get someone to take a look at https://myapps.developer.ubuntu.com/dev/click-apps/5479/rev/26/? [15:25] stokachu: I will [15:25] jdstrand, ty! [15:28] PR snapd#2621 opened: osutil.GetenvBool now takes an extra, optional, argument [15:29] stokachu: done. you need to press the release button [15:29] jdstrand, perfect ty, do i need to worry about getting additional reviews if i need to push a new snap? [15:30] stokachu: not now (I granted that). check your email [15:30] jdstrand, ok great, thank you again [15:30] np [15:36] jdstrand, sudo snap install conjure-up --edge --classic <- am i missing anything here? [15:36] says snap isn't found [15:37] oh isee [15:37] release button at the bottom [15:38] hmm not sure what im missing now === chihchun is now known as chihchun_afk [15:41] maybe there is a delay [15:44] http://paste.ubuntu.com/23787291/ snap info does show it in the edge channel as well [15:52] stokachu: some confusion but installing classic snaps from the store doesn't work in 2.20 or before (we are fixing it in 2.21) [15:53] pedronis, ah [15:53] pedronis, np i can just work with the blob itself for now [15:55] stokachu: the workaround to try it is to use "snap download snap-name" "snap ack *.assert" "snap install *.snap" [15:55] pedronis, ah perfect, that'll work [15:55] sorry for the incovenience [15:56] np i know it's very new [15:59] stokachu: there is an issue with snapd and the store when using --classic. I don't recall the details. I think sergiusens has a workaround [16:00] ah, I see you already got an answer to that :) [16:00] jdstrand, :D [16:00] i can still corner sergiusens tomorrow unless he's hiding from me [16:03] roadmr: hi! can you pull r824 of the tools? this is just updates to data/ for 2.21 interfaces and whitelisting some approved kernel and gadget snaps [16:04] jdstrand: sure thing [16:04] roadmr: thanks! I *think* this will be it for a while (famous last words) [16:05] PR snapd#2520 closed: many: fix abbreviated forms of disconnect [16:15] PR snapd#2622 opened: asserts: Improve error message when key is not valid at the given time [16:28] hi [16:28] when will rhel/centos be supported [16:30] PR snapd#2621 closed: osutil.GetenvBool now takes an extra, optional, argument [16:34] Cust0sLim3n, perhaps SamYaple or zyga know if thats actually planned ... fedora is surely supported (with limitiations in the confinement) [16:34] hello Cust0sLim3n: https://github.com/snapcore/snapd/wiki/Distributions [16:36] thanks elopio [16:39] Cust0sLim3n: hey [16:39] Cust0sLim3n: CentOS needs some packaging work [16:39] Cust0sLim3n: Fedora has two blocking issues that we've struggled with [16:39] Cust0sLim3n: both are on the backlog but I expect ~1-2 weeks before I start working on that [16:40] zyga, is there some repo with stuff for CentOS / Fedora builds ? [16:40] Cust0sLim3n: please have a look at http://www.opera.com/pl/computer/neon [16:40] er [16:40] paste fail [16:40] http://github.com/snapcore/snapd/wiki/Distributions [16:40] Cust0sLim3n: there was COPR but it is no longer used as development moved to Fedora git [16:41] zyga, cool thanks [16:41] Cust0sLim3n: CentOS should be easier (no selinux on services by default) but it needs separate packaging permissions [16:41] Cust0sLim3n: if you are interested we could work together to revive copr and build a centos package there [16:41] Cust0sLim3n: I cannot commit 100% of my time to it this or next week but I will help you out [16:42] zyga, don't really have time - really need it for RHEL though - but I think in meantime I will just use software collections on rhel or something - still have to see [16:42] zyga, just thought it would be nice to use snappy instead of SCL [16:43] Cust0sLim3n: what software are you most interested in? [16:43] Cust0sLim3n: we'll get there, it's just a busy schedule all the time [16:44] zyga, its for commercial use with our C/C++ software on linux that I want it [16:46] zyga, but its not critical enough for us to dedicate allot of time to it - so it was mainly just if I somehow missed it being available it would have been nice - but otherwise we will just use SCL or package directly [16:46] Cust0sLim3n: how do software collections help you? [16:50] jdstrand: hey - new interfaces API: https://github.com/snapcore/snapd/pull/2613/files [16:50] PR snapd#2613: interfaces: add new interface API [16:51] jdstrand: with initial review from gustavvo [16:51] jdstrand: I think it is likely to land soon [16:51] jdstrand: once it does expect a flag day where all the interfaces and backends are ported to provisional APIs like spec.AddSnippet() (that directly replaces returning a snippet) [16:52] I'll be looking at that in a little bit [16:52] jdstrand: and then dedicated changes to backends like mount, kmod, systemd that are well defined and have just a few interfaces [16:52] jdstrand: then we can discuss apparmor/seccomp [16:52] jdstrand: I think there's no rush on aa/sc but we can see what we'd like to do by porting one or two interfaces over to more semantic APIs [16:53] jdstrand: e.g. in seccomp we could do spec.Allow(seccomp.open) rather spec.AddSnippet("open") [16:53] jdstrand: in apparmor we could do (but in short cases IMHO) spec.Allow("/path/to/file", "r") or even spec.Allow("/path/to/file", apparmor.Read) [16:54] jdstrand: thanks! [16:55] zyga, makes it easier to work with multiple library and application versions and allows us to be less dependent on library versions shipping with OS - so if we want newer boost version for building with than is available on RHEL by default we can package it with SCL [16:56] zyga: keep in mind, I've not looked at this at all yet, but please, please, please keep in mind that the resulting security policy needs to be auditable. that means policy, structure and comments all need to be in place. I maintain my concerns that this will impede security audits since the review will have to do profile dumps to see what is happening [16:56] jdstrand: I keep this in mind and keep reminding everyone about it :-) [16:56] tyhicks: fyi ^ [17:00] PR snapd#2623 opened: tests: add test ensuring manual pages are shipped [18:00] ogra_: hi! I noticed that the bbb kernel is a few versions behind the most recent USNs [18:01] ogra_: is your automated script not working right? [18:14] jdstrand, that one isnt automated ... i'll kick off a new build [18:16] ogra_: fyi, you can automate it if you want. I just added an exception for it in the review tools (though this upload will need a review, when the store syncs it won't any more) [18:16] ok [18:41] PR snapd#2624 opened: Re-associate with pid-1 mount namespace if required [18:46] tyhicks: good news, I think I know what the kernel bug is about :) [18:46] (the one with oops on one thing I did a while ago) [18:46] well, fingers crossed [18:46] at the very least I can give you a way to reproduce easily [18:47] jdstrand, jjohansen: ^^ [18:47] (oops in apparmor) [18:47] on the up side it is *not* Friday yet [18:48] ogra_: thanks for the pi image...one question, anyway we could change pi3 console config to not require ethernet cable? [18:49] i set up wifi fine, but then it loops back and demands i set up via ethernet [18:49] kgunn, i think there is an old bug open for this ... [18:49] ah [18:49] * kgunn thot pi2 didn't have wifi chip [18:49] and that was the reason [18:50] you can set it up initially with eth0, then reboot, ssh in and run "sudo console-conf" and disabe eth0 and switch to wlan0 ... that works fine for me [18:50] it is only the very first boot where it fails [18:50] ogra_: out of interest why are we use pi2 kernel on pi3 are there phyiscally no differences between then? [18:50] (but indeed you need network on the very first boot to set up the user) [18:51] ogra_: you can use the serial console [18:51] ogra_: on a pi :) [18:51] davmor2, the kernel is identical ... but th ebootloaders are not (namely there is a different u-boot.bin ) [18:51] jjohansen: this is not what we talked about yesterday, but zyga is seeing an oops with https://github.com/snapcore/snapd/pull/2624. I have a feeling many of your concerns about changing the mount namespace would apply to this pr [18:51] PR snapd#2624: Re-associate with pid-1 mount namespace if required [18:51] zyga, for what ? [18:51] ogra_: to do the 1st boot dance [18:51] jdstrand: that branch is buggy but perhaps this is causing the oops [18:51] zyga, and that magically pulls the login data via serial ? [18:51] jdstrand: testing again with the fix [18:51] ogra_: oooooho [18:51] :D [18:52] ogra_: I should have gotten that beer [18:52] you need network to be able to finish console-conf once [18:52] hah [18:52] jdstrand: anything I should know about? [18:52] once it is finished, switching networks is easy [18:53] zyga: you should wait for jjohansen. he had concerns regarding changing namespaces and open fds and likely some other concerns [18:54] jdstrand: will he be around today? [18:55] zyga: this came up in the context of snap-alter-ns, but I think they would apply to this [18:55] jdstrand: hmm hmm, can you tell me how would snap-alter-ns be affected? we could presumably do all the open() calls after we re-associate [18:55] (just worried if I should be worried) [18:55] zyga: he should be. he has been sick though. not sure when he'll be online [18:56] zyga: need to wait for jjohansen. we were going to chat today. may as well make it all 3 of us [18:56] (or maybe tomorrow) [18:56] jjohansen: I'm sorry to hear that, I hope you get better [18:57] jdstrand: if he's around can you please PM me on telegram (I get notifications on my phone this way) [18:57] I'd like to listen to understnad this problem better [18:57] zyga: you can listen to irc then? [18:59] jdstrand: if the converstation is on IRC then that's much easier :) [19:00] zyga: it will be, yes [19:02] jdstrand: somewhat offtopic, I think there's a separate bug, kernel doesn't let me bind() the mount namespace FD if I don't run as root despite having all the capabilities; I will need to investigate that in ~10 days. Do you know if this is by design (by any chance)? [19:04] zyga: I don't, sorry [19:04] * zyga will dig through the kernel then [19:05] hi there! How I can submit a snap package both for armhf and amd64? I have both snaps already built. [19:05] alvarolb: just send them to the store [19:05] alvarolb: you can use snapcraft for that [19:05] alvarolb: or use the web UI [19:05] alvarolb: both snaps need to have the same snap name / snap id [19:05] alvarolb: and (hopefully) different architecture entries [19:06] yes, but if I upload the amd64 [19:06] alvarolb, they will both be assigned different revisions and the store will know what arch they are. And snapd won't let a snap for the wrong arch be installed [19:06] then it replaces the armhf [19:06] alvarolb: it doesn't really replace them [19:06] alvarolb: just try it, you will have to publish each one [19:06] alvarolb: then you should be able to install them :) [19:07] Ok, so I upload both versions to the same snap package, and it should work [19:07] ogra_: re eth, ack...except i don't have eth cable access here at my communal office space :-P [19:07] it does not show that the snap is available for both platforms [19:07] alvarolb, then run `snapcraft status ` and you'll see where each arch has its own channel map [19:08] kgunn, ah, damned [19:09] kgunn, well, we dont have a solution beyond this yet [19:10] you could try a wifi dongle, perhaps that works better [19:10] ok, thanks for the support! [19:15] PR snapd#2433 closed: tests: run all snap-confine tests in c-unit-tests task [19:36] jdstrand: can you take a look at this error for me? http://paste.ubuntu.com/23788349/ [19:36] I suspect that it's not really a problem with the limits, but rather the snap's inability to check what the limits are, due to confinement [19:38] mhall119: Jan 12 14:31:59 mhall-thinkpad snap[5671]: /snap/couchbase-server-community/x1/couchbase-server-snap: line 166: exec: erl: not found [19:38] mhall119: limits seem to be a separate issue [19:39] mhall119: look at dmesg | DENIED please [19:39] er [19:39] dmesg | grep DENIED [19:40] zyga: nothing from couchbase there, I have another issue with it not finding the 'erl' binary that I need to fix [19:49] so in a classic snap how would i copy a file to my HOME dir? [19:49] mhall119: then I'd say it dies on that problem now [19:49] not the home dir of the snap [19:50] stokachu: classic snap or in the classic confinement of some snap/ [19:50] zyga, in the classic confinement [19:50] stokachu: snaps that have confinement: classic don't get HOME redirection [19:50] stokachu: HOME is real :) [19:51] stokachu: try it, [19:51] hmm so if i do a cp file ~/test from the snap it doesn't show up in my HOME dir [19:51] stokachu: https://github.com/snapcore/snapd/wiki/Environment-Variables#home [19:51] stokachu: can you use "snap run --shell $SNAP_NAME.appname" and go to $HOME [19:52] stokachu: or just echo $HOME [19:52] stokachu: if that's a bug I can (still) fix it [19:53] zyga, hmm ok $HOME shows my user (ubuntu) /home/ubuntu when i do a snap run --shell conjure-up [19:53] need to check out my code then, because things like os.expanduser in python should work as normal correct? [19:54] yea must be something in my code [19:54] * stokachu back to drawing board [19:58] ogra_: this may be a different bug (wifi), I ran console-conf after first boot like you mentioned but [19:58] wlan0 option dissapears [20:00] stokachu: I hope so, we don't change anything else [20:00] ogra_: I guess a reboot fixed that :) [20:00] zyga, hah [20:05] jdstrand: hey, so I made some progress but got stuck; I don't see any apparmor denials (the process is in devmode), I don't see anything in the kernel log but when I open /proc/1/ns/mnt I get EACCES [20:05] jdstrand: I did an experiment where I just nsenter around and this worked OK [20:05] jdstrand: I suspect apparmor is causing this [20:06] jdstrand: can you please have a look at https://github.com/snapcore/snapd/pull/2624/files#diff-5f1642833244a655796f5f4230f68fdbR207 [20:06] PR snapd#2624: Re-associate with pid-1 mount namespace if required [20:06] jdstrand: and tell me if I need to adjust the apparmor profile in some special way (in the same pull request) [20:06] PR snapcraft#1045 opened: Handle parser errors better [20:06] jdstrand: note, I *don't* get a DENIED anywhere :-( [20:06] jdstrand: (thinking about it now I want to point out that while the process running snap-confine is in devmode, snap-confine itself is obviously confined) [20:07] jdstrand: perhaps my change is not applied to the snap-confine I'm runnning from the (repackaged) core snap? [20:08] jdstrand: still thinking aloud, looking at /sys/kernel/security/apparmor/profiles I see [20:08]