[02:13] er where can i get a good kernel snap from? [02:19] ah i think maybe my gadget snap was old or something === JanC is now known as Guest35265 === JanC_ is now known as JanC === chihchun_afk is now known as chihchun [07:06] good morning === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:33] PR snapd#1662 closed: client, cmd, daemon, osutil: support --yaml and --sudoer flags for create-user [07:36] PR snapd#1655 closed: integration-tests: look for ubuntu-device-flash on PATH before calling sudo [08:02] PR snapd#1602 closed: interfaces: add kernel-module interface for module insertion === davmor2_Hols is now known as davmor2 [09:10] mvo, i was looking into classic on the weekend ... http://paste.ubuntu.com/23057787/ has proposed change for classic.create, do you have branch anywhere = [09:10] ? [09:10] (probably needs squashfs-tools and coreutils in stage-packages and adjusted paths) [09:11] mwhudson: hey [09:11] mwhudson: do you have access to snap-confine packaging on alioth? [09:13] mvo, oops, sorry http://paste.ubuntu.com/23057792/ . the first one wasnt the cleaned up version [09:15] ogra_: thanks! let me create a git branch [09:16] the unsquashing takes about half the time vs cp ... [09:16] and brings a (despite very ugly) progressbar for free ;) [09:16] ogra_: its on github as "classic-snap" [09:16] cool, i'll prepare a PR [09:17] ogra_: thanks [09:22] mwhudson: looking at the QA page it seems that you do, can you please add me to uploaders please [09:22] zyga: sure [09:22] zyga: are you a DM yet? [09:22] mwhudson: I'd like to convert the package so that it is not a native package [09:22] zyga: what email? [09:22] mwhudson: no :/ [09:22] mwhudson: please try me@zygoon.pl [09:23] mwhudson: all I need right now is to have write access to the git repo on alioth [09:23] zyga: i can't grant that :/ [09:23] zyga: you need to be in collab-maint, and you need to be a DM for that [09:23] hmmm [09:23] zyga: however! [09:23] zyga: if you push to github or something i can just merge --ff-only that [09:23] I did edit some packages in collab-maint AFAIR but perhaps that's my memory being rusty [09:24] zyga: also, it already isn't a native package [09:24] oh [09:24] mwhudson: that's perfect then [09:24] mwhudson: oh? it seems to be in the master branch [09:24] but i think i know what you mean [09:24] zyga: master is just a mirror of github.com/snapcore/snap-confine [09:24] aaaah [09:24] cool [09:24] zyga: the debian bits are in the 'debian' branch [09:24] let me run a quick spread test [09:24] :-) [09:25] mwhudson: I pushed some updates to https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/master [09:25] the debian directory gets deleted in the upstream branch and then re-added in debian [09:26] mwhudson: spread tests use that for constructing a package [09:26] it would be a good deal less silly to not have the debian dir in master [09:26] mwhudson: my branch will finally remove the debian directory from upstream packaging [09:26] from my pov, other povs may differ [09:26] mwhudson: I fully agree [09:27] * mwhudson has not yet internalized how lp git urls work [09:27] hehe, me neither [09:27] ah, third time lucky [09:27] if you look at https://git.launchpad.net/snap-confine/tree/debian [09:27] you will see that there are no patches [09:27] the debian directory doesn't have the apparmor profile anymore [09:27] and there are some slight changes to rules [09:28] but that's all [09:28] if you could merge that into alioth then my spread tests would work for sid, xenial and yakkety :) [09:28] oh, it's based on an import-dsc [09:29] zyga: uh can you send email about this? [09:29] mwhudson: sure [09:29] zyga: life is happening here [09:29] mwhudson: do you directory? [09:29] :D [09:29] directly* [09:34] mwhudson: sent === faenil is now known as faenil_ [09:46] PR snapd#1676 opened: interfaces: bluez: add missing mount security snippet case [09:51] zyga: ta [09:52] cjwatson, just fYI i havent seen failed promotions anymore (there were some oops timeouts on the weekend though), seems to all work fine, i wonder why the first few days this didnt work [09:52] ogra_: pass; perhaps a store problem of some kind [09:52] ogra_: but good to know it works now, thanks [09:52] (but well, it works now, so all is fine) === faenil_ is now known as faenil [10:05] PR snapd#1676 closed: interfaces: bluez: add missing mount security snippet case [10:08] zyga: i guess snapd will also not be a native package eventually :-) [10:14] mwhudson: I'd like it not to be native package with the next debian upload [10:14] mwhudson: if you can merge the changes from launchpad git branch that would be done too [10:15] the debian packaging is in an odd state i think [10:15] i need to poke slangasek some more to get that organized iirc [10:15] mwhudson: in which way? [10:15] mwhudson: ok [10:15] mwhudson: I'm glad to help, I'll apply to be a DM today [10:15] zyga: cool, there is a new process! [10:16] zyga: https://nm.debian.org/wizard/ [10:16] new as in easier? :) [10:16] ooooh [10:16] hopefully [10:16] * zyga does it right away [10:27] zyga: do you know if there is any significant difference between the snap-confine packages in xenial and yakkety? [10:27] i know some stuff got fixed as part of the SRU, but I *think* that got pushed into debian/yakkety too [10:34] PR snapd#1677 opened: interfaces: bluez: add a few more tests to verify interface connection works [10:34] zyga: you were a bit too fast with merging that PR :-) [10:34] was adding a few more tests for that [10:35] mwhudson: mvo would know, I want to erase those differences [10:35] mwhudson: I know mvo did cherry picks to ease the SRU process [10:35] morphis: oh :) [10:35] morphis: sorry then ;) [10:35] morphis: merging the 2nd one too [10:35] zyga: np, I didn't left a note so you couldn't know :-) [10:36] morphis: reviwed, thank you :-) [10:39] mvo, hmm, did you foget to add the files to https://github.com/snapcore/classic-snap ? (i only see meta/snap.yaml) [10:39] morphis: yeah, what zyga said, I cherry picked bit to make the sru easier for me, but once we use a common packaging I'm happy to drop this [10:40] ogra_: let me check [10:40] ogra_: please pull again [10:40] mvo, zyga: thanks [10:40] better :) [10:41] I'd love to get a quick review on https://github.com/snapcore/snap-confine/pull/102 [10:41] PR snap-confine#102: Take upstream version from VERSION file [10:41] anyone? :) [10:44] zyga: done === Ivan is now known as Guest14900 [11:02] morphis: thank you [11:02] zyga: np [11:04] mvo, mwhudson: https://github.com/snapcore/snap-confine/pull/103 [11:04] PR snap-confine#103: Use downstream packaging in spread tests [11:05] and http://nm.debian.org/person/zyga [11:15] sergiusens: can it be that the packaging logic in snapcraft doesn't include results of the organize statement? [11:15] Is it possible to add use a ppa for a snap's packages? [11:16] sergiusens: see https://paste.ubuntu.com/23058108/ [11:46] I am not sure if this is the right place to ask but: Will the ubuntu store/snap store gain a functionality that shows if a snap package is made by the program's developer? Like, I wouldn't trust a "financial transaction" snap by "givemonies". === Chipaca` is now known as Chipaca [11:59] Sogator: yes, I believe this is in the roadmap somewhere [11:59] Sogator: there will be more details availble about particual developer [12:15] which part of the installation process is responsible for creating $SNAP_USER_DATA directory? I noticed that whem my snap tries to start /root/snap//x5/ does not exist and it causes problems [12:17] ogra_: need help with that PR? I can merge your pastebin directly if that helps [12:33] jacekn: that'd be snap-confine in the current SRU in ubuntu, later on it will be snapd itself [12:33] jacekn: I believe the problem you are reporting is fixed in proposed now [12:37] mvo, well, i'm heavily hit by the /dev/ptmx bug currently ... hard to test it that way [12:37] mvo: I am wondering why I don't see my spread test executed in https://travis-ci.org/snapcore/snapd/jobs/152356995 [12:37] mvo, so i'm currently poking around in bin/shell ... https://github.com/ogra1/classic-snap [12:40] ogra_: is this fixed by https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364 ? [12:40] zyga, is that in any package yet ? [12:41] ogra_: aha, ok. fwiw, I think its ok to use the coreutil and squashfs tools from the core not sure why we need those in stage packages [12:42] morphis: looking [12:42] mvo, well, if we ever run confined .... [12:43] ogra_: I don't know; mvo did you cherry pick that fix from master? [12:43] zyga: what fix? [12:43] https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364 [12:43] how do i apply that manually if it isnt landed yet ? [12:43] ogra_: I don't think so [12:44] ogra_: yeah, you will have to manually get it [12:45] ogra_: hm, when we add the confinement profile we can just include unsquashfs in there, that seems to be ok, I don't see the benefit of adding the binary into the snap [12:45] ogra_: if its critical I can prepare a new SRU with that (its another regression?) [12:46] mvo, well, i'lll remove the stage-packages again (i just found it cleaner to ship our own ... but in the end it might not make any difference) [12:46] morphis: the file tests/main/interfaces-bluez/spread.yaml has to be tests/main/interfaces-bluez/task.yaml [12:47] mvo: ah [12:47] ogra_: thanks, I think its fine to use the system ones, this is so low level there shouldn't be any practial difference [12:47] i'll revert the branch then [12:48] PR snapd#1678 opened: asserts: export DecodePublicKey [12:49] ogra_: thanks! [12:51] hmm, whats the apparmor_parser line i need to re-gen the snap-confine profiile ? [12:51] timothy: hey, I've almost removed debian packaging of snap-confine [12:51] (i hope bind mounting works, i cant write to /etc/apparmor.d/ [12:51] ) [12:51] ogra_: apparmor_parser -r /etc/apparmor.d/the-file-there [12:51] thx [12:51] timothy: please have a look at this https://github.com/snapcore/snap-confine/pull/103 [12:51] PR snap-confine#103: Use downstream packaging in spread tests [12:52] (classic)ubuntu@pi2:~$ cat create [12:52] cat: standard output: Permission denied [12:52] (classic)ubuntu@pi2:~$ sudo ls [12:52] sudo: no tty present and no askpass program specified [12:52] (classic)ubuntu@pi2:~$ [12:52] nope, no change [12:52] timothy: one thing you can see there is that it combines upstream source tarball with downstram packaging [12:52] ogra_: is /dev/pmtx mounted? [12:53] you mean /dev/pts :) [12:53] timothy: can you please point me to the location of arch packaging for snap-confine; I recalled you said it was in SVN somewhere [12:53] mmm, maybe, my tty subsystem know-how is rusty [12:53] * zyga checks [12:54] ogra_: how about /dev/pts/ptmx [12:54] (classic)ubuntu@pi2:~$ mount|grep pts [12:54] devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=666,ptmxmode=666) [12:54] (classic)ubuntu@pi2:~$ ls /dev/pts/ [12:54] ptmx [12:55] that's okay [12:55] hmmmm [12:55] seems that systemd-run somehow removes /dev/pts/0 [12:55] I don't know [12:56] removes? [12:56] no, wait, each snap-confine started app gets private /dev/pts [12:56] zyga: ack, thanks [12:56] perhaps that's the actual problem? [12:57] zyga, well, we are running in devmode for classic [12:57] does that still apply ? [12:57] (i would guess snap-confine is completely suppressed in devmode) [12:58] ogra_: NO [12:58] no :_) [12:58] aha, so it isnt confinement at all [12:58] ogra_: in fact, snap confine doesn't care about devmode at all, snapd does [12:58] ogra_: snap-confine does more than just confinement: http://www.zygoon.pl/2016/08/snap-execution-environment.html [12:59] ogra_: one of the thing it does is sets up a private /dev/pts for your [12:59] your application process [12:59] perhaps for classic that is not desired [12:59] and that has been deeply tested in alll-snap envs i guess ? :P [12:59] I think that now, with the mount profile support, we could have snapd *not* generate that for classic but do so for everyone else [12:59] ogra_: yes [13:00] ogra_: this code applies both on classic and in all snap [13:00] zyga: also: https://bugs.launchpad.net/snapcraft/+bug/1613268 [13:00] Bug #1613268: SNAP_USER_DATA is not created automatically [13:00] how ? we didnt have images til last week :P [13:00] i recognize it applies to both, but should it behave the same on both is my question ... and has it been tested with a majorly readonly root [13:01] (and has t been tesetd with systemd-run ... which classic uses to spawn the chroot) [13:01] i have the feelling there are some bits clashing here [13:02] ogra_: this code was unchanged for ages [13:02] zyga, but since when do we use snap-confine in all-snap images ? [13:03] i'm pretty sure we didnt use it with the last ones (which was about two months ago) [13:03] and new images only exist since end of last week [13:03] ogra_: hey, so, pc-kernel, pi2-kernel and dragonboard-kernel? [13:03] jdstrand, yes please [13:04] ogra_: any gadget snaps? [13:04] jdstrand, nah, they change so rarely, i dont think we need them right now ... mvo ? [13:12] ubuntu@dragonboard:~$ sudo ls -l /tmp/*classic* |wc -l [13:12] 115 [13:12] URGH [13:12] ! [13:14] it never cleans up ? [13:14] ogra_: nope [13:14] (snap-confine that is) [13:14] ogra_: it's a known issue [13:14] ogra_: (since uubntu-core-launcher days) [13:14] ah, so it will ... at some point [13:14] that fine then [13:14] ogra_: I'd like to fix it but it's not trvial (or I didn't find a trivial way to fix it yet) [13:14] yeah, i thought switching to snap-confine would fix that already [13:14] ogra_: I have an idea with vfork but I didnt' explore it yet [13:15] ogra_: the switch was just a rename [13:15] ogra_: and evolutionary changes since [13:15] heh [13:15] ogra_: it wasn't a rewrite of anything [13:16] ogra_: the tmp directories you're seeing are all empty, correct/ [13:16] yep [13:16] just wasting inodes [13:17] (just makes debugging really hard (i.e. finding the right one) since there are so many) [13:17] PR snapd#1677 closed: interfaces: bluez: add a few more tests to verify interface connection works [13:17] fgimenez: ping [13:17] ogra_: that's good, I'll try my idea when snap-confine is out of SRU pipe [13:17] zyga, in any case the ptmx change doesnt seem to have any effect [13:18] joc_, hey :) [13:18] ogra_: can you rebuild snap-confine and change it in your test env easily? [13:18] i dont get a tty and no /dev/pts/0 [13:18] no, not easily [13:18] ogra_: I'd like to check something about the pts error you are seeing [13:18] ogra_: gah, too bad [13:18] * zyga would love a snapd.snap with just a handful of executables [13:18] fgimenez: hi, i noticed you had a PR open for spread tests for serial-port interface [13:19] i'd have to build the package, push it to the snappy-image ppa, rebuild the image etc [13:19] Are there any examples of CLI anywhere in snapd that use a subcommand pattern? E.g. snap foo bar --options, snap foo baz --options, etc. [13:19] ogra_: fwiw, I did a quick test with classic on amd64 and it seems to be working for me, what kind of failure do you see? [13:19] mvo, cat not working, sudo not works [13:19] I guess you might call that subsubcommand [13:19] *working [13:19] fgimenez: i have one open that adds extra functionality and changes the way it works a bit so can imagine they might break one another [13:20] ogra_: works for me [13:20] mvo, on arm ? [13:20] ogra_: not on arm, interessting that this is arm specific, I can try tthat in a bit [13:20] would be good ... [13:20] joc_, great to know thanks! i can retarget it to your branch so that it lands with the test added (ideal case :) which is your branch? [13:20] Like "lxc image ..." [13:20] let me re-set my pi2 and try with the classic from the store ... [13:21] cjwatson, like "snap install --devmore foobar" ? [13:21] ogra_: so specifically sudo fails? [13:21] fgimenez: sounds good although i think i still need some reviews, https://github.com/snapcore/snapd/pull/1669 [13:21] PR snapd#1669: interface: add usb device support to serial-port [13:21] zyga, welll, there is no /dev/pts/0 ... so no tty ... [13:21] ogra_: Not really, there are no subcommands of "snap install" [13:22] ogra_: please report a bug on snap-confine on launchpad, I'll take care of it [13:22] ogra_: I can reproduce that anywhere [13:22] ogra_: I mean like "lxc image list" vs. "lxc list" [13:22] ogra_: Where "lxc image" is itself a thing that dispatches to its own subcommands [13:22] cjwatson, ah, i dont think snappd has any "multi word" commands [13:22] i thought you meant options [13:23] only toplevel with options afaik [13:23] ogra_: snapd doesn't care [13:23] ogra_: snap for bzr should just fork [13:24] :D [13:24] joc_, cool thanks i'll propose it shortly, if it needs further changes after merging just ping me, we can work together to keep the test up to date with the functionallity [13:24] roadmr: hi! the possible review tools update is a reality in r709 :) [13:24] jdstrand: cool! I'll put that in the pipeline [13:25] * ogra_ sighs ... classic.create on the pi2 takes ages ... [13:25] fgimenez: great :) [13:25] ogra_: Looks like go-flags supports subcommands, so it looks not too hard to do at least [13:25] (using the classic from the store) [13:25] roadmr: thank you :) [13:25] cjwatson, i think we use subcommands in ubuntu-device-flash (source is goget-ubuntu-touch) [13:25] multiple actually [13:26] PR snapd#1605 closed: asserts: introduce support for assertions with no authority, implement serial-request [13:26] ahoneybun: hey, you pinged me about pithos-- sorry I'm not familiar with pithos. it seems like 'self.player' somehow didn't get initialized correctly. Did you come to me because there was a security denial? [13:27] ogra_: Just the top-level set of commands, I think, which is the same level of nesting as snap. Never mind, I'll figure something out [13:35] mvo, ok, i verified again, broken on the pi2 and dragonboard with the last classic from the store (so definitely not my hackery that broke it, which i feared) [13:35] mvo, the symptoms are: [13:35] (classic)ubuntu@pi2:~$ sudo ls [13:35] sudo: no tty present and no askpass program specified [13:35] (classic)ubuntu@pi2:~$ cat .bashrc [13:35] cat: standard output: Permission denied [13:35] re [13:35] and: [13:35] (classic)ubuntu@pi2:~$ ls /dev/pts/ [13:35] ptmx [13:35] no /dev/pts/0 [13:35] (so sudo isnt wrong when complaining about no tty) [13:36] ogra_: thank you, booting my pi2 now [13:38] this is also interesting: [13:38] (classic)ubuntu@pi2:~$ ls /dev/std* [13:38] ls: cannot access '/dev/stderr': Permission denied [13:38] ls: cannot access '/dev/stdin': Permission denied [13:38] ls: cannot access '/dev/stdout': Permission denied [13:39] ogra_: that's interesting [13:39] ogra_: ls -ld /dev /dev/stderr [13:40] (classic)ubuntu@pi2:~$ ls -ld /dev/std* [13:40] lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stderr -> /proc/self/fd/2 [13:40] lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stdin -> /proc/self/fd/0 [13:40] lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stdout -> /proc/self/fd/1 [13:40] (classic)ubuntu@pi2:~$ ls -ld /proc/self/fd/* [13:40] ls: cannot access '/proc/self/fd/255': No such file or directory [13:40] ls: cannot access '/proc/self/fd/3': No such file or directory [13:40] lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/0 -> /dev/pts/0 [13:40] lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/1 -> /dev/pts/0 [13:40] lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/2 -> /dev/pts/0 [13:41] (and /dev/pts/0 is missing, like i said above) [13:42] aaaah [13:42] it all makes sense [13:42] ogra_: please report the bug as I said, I think I can at least come up with a hack to confirm my hypothesis, then a proper fix via snapd [13:43] ok [13:43] ogra_: but I worry this might be something we have to ack with jdstrand first [13:43] ogra_: on my pi2 (fresh image) http://paste.ubuntu.com/23058387/ - what do I need to do to trigger the issue [13:43] jdstrand: later on when you have time [13:44] mvo, hmm [13:44] mvo, i upgraded my image to rev 249 [13:45] ogra_: I'm on r249 as well [13:45] weird [13:45] ogra_: via a serial port though, how do you access it? [13:45] ssh [13:45] * mvo looks [13:45] let me try serial [13:45] ogra_: did you see what docker did to work around this? [13:46] mvo, WOAH ! [13:46] ubuntu@pi2:~$ sudo classic.shell [13:46] (classic)ubuntu@pi2:~$ sudo ls [13:46] [sudo] password for ubuntu: [13:46] so it is ssh induced somehow [13:46] ogra_: aha, but I see the same issue with ssh [13:46] ogra_: thanks, that was the missing piece [13:46] any idea what it actualyl is ? [13:46] hmmm [13:47] ogra_: yes, there is a open bug [13:47] wkw [13:47] lw [13:47] wow, curious indeed [13:47] you're talking about bug #1611493 correct? [13:47] Bug #1611493: No TTY in snaps. [13:47] jdstrand: yes [13:47] jdstrand: thats the one [13:47] "The work-around identified there (use "script -qc /dev/null") works in snaps too." [13:48] jdstrand: I wonder if there is something else we can do, I have not looked into this enough yet though to really have an opinion [13:48] https://github.com/lxc/lxc/issues/554#issuecomment-238694912 [13:48] "This is a known bug in glibc and @hallyn has send a fix to glibc (https://sourceware.org/ml/libc-alpha/2016-08/msg00307.html). It just needs to be applied." [13:48] mvo: the page talks about bind mountint /dev/console [13:48] *mounting [13:48] jdstrand: oh, sweet [13:49] as a workaround [13:49] jdstrand, well, that nests ttys [13:49] it's a workaround [13:49] extremely ugly [13:49] jdstrand: we can check the fix in our image ppa [13:49] the fix is in glibc aiui [13:49] and forces you in classic.shell to log out twice [13:50] * ogra_ tried the script hack already and indeed it works ... [13:50]