mwhudsoner where can i get a good kernel snap from?02:13
mwhudsonah i think maybe my gadget snap was old or something02:19
=== JanC is now known as Guest35265
=== JanC_ is now known as JanC
=== chihchun_afk is now known as chihchun
zygagood morning07:06
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
mupPR snapd#1662 closed: client, cmd, daemon, osutil: support --yaml and --sudoer flags for create-user <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1662>07:33
mupPR snapd#1655 closed: integration-tests: look for ubuntu-device-flash on PATH before calling sudo <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1655>07:36
mupPR snapd#1602 closed: interfaces: add kernel-module interface for module insertion <Reviewed> <Created by arges> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1602>08:02
=== davmor2_Hols is now known as davmor2
ogra_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
ogra_(probably needs squashfs-tools and coreutils in stage-packages and adjusted paths)09:10
zygamwhudson: hey09:11
zygamwhudson: do you have access to snap-confine packaging on alioth?09:11
ogra_mvo, oops, sorry http://paste.ubuntu.com/23057792/ . the first one wasnt the cleaned up version09:13
mvoogra_: thanks! let me create a git branch09:15
ogra_the unsquashing takes about half the time vs cp ...09:16
ogra_and brings a (despite very ugly) progressbar for free ;)09:16
mvoogra_: its on github as "classic-snap"09:16
ogra_cool, i'll prepare a PR09:16
mvoogra_: thanks09:17
zygamwhudson: looking at the QA page it seems that you do, can you please add me to uploaders please09:22
mwhudsonzyga: sure09:22
mwhudsonzyga: are you a DM yet?09:22
zygamwhudson: I'd like to convert the package so that it is not a native package09:22
mwhudsonzyga: what email?09:22
zygamwhudson: no :/09:22
zygamwhudson: please try me@zygoon.pl09:22
zygamwhudson: all I need right now is to have write access to the git repo on alioth09:23
mwhudsonzyga: i can't grant that :/09:23
mwhudsonzyga: you need to be in collab-maint, and you need to be a DM for that09:23
mwhudsonzyga: however!09:23
mwhudsonzyga: if you push to github or something i can just merge --ff-only that09:23
zygaI did edit some packages in collab-maint AFAIR but perhaps that's my memory being rusty09:23
mwhudsonzyga: also, it already isn't a native package09:24
zygamwhudson: that's perfect then09:24
zygamwhudson: oh? it seems to be in the master branch09:24
mwhudsonbut i think i know what you mean09:24
mwhudsonzyga: master is just a mirror of github.com/snapcore/snap-confine09:24
mwhudsonzyga: the debian bits are in the 'debian' branch09:24
zygalet me run a quick spread test09:24
zygamwhudson: I pushed some updates to https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/master09:25
mwhudsonthe debian directory gets deleted in the upstream branch and then re-added in debian09:25
zygamwhudson: spread tests use that for constructing a package09:26
mwhudsonit would be a good deal less silly to not have the debian dir in master09:26
zygamwhudson: my branch will finally remove the debian directory from upstream packaging09:26
mwhudsonfrom my pov, other povs may differ09:26
zygamwhudson: I fully agree09:26
* mwhudson has not yet internalized how lp git urls work09:27
zygahehe, me neither09:27
mwhudsonah, third time lucky09:27
zygaif you look at https://git.launchpad.net/snap-confine/tree/debian09:27
zygayou will see that there are no patches09:27
zygathe debian directory doesn't have the apparmor profile anymore09:27
zygaand there are some slight changes to rules09:27
zygabut that's all09:28
zygaif you could merge that into alioth then my spread tests would work for sid, xenial and yakkety :)09:28
mwhudsonoh, it's based on an import-dsc09:28
mwhudsonzyga: uh can you send email about this?09:29
zygamwhudson: sure09:29
mwhudsonzyga: life is happening here09:29
zygamwhudson: do you directory?09:29
zygamwhudson: sent09:34
=== faenil is now known as faenil_
mupPR snapd#1676 opened: interfaces: bluez: add missing mount security snippet case <Created by morphis> <https://github.com/snapcore/snapd/pull/1676>09:46
mwhudsonzyga: ta09:51
ogra_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 work09:52
cjwatsonogra_: pass; perhaps a store problem of some kind09:52
cjwatsonogra_: but good to know it works now, thanks09:52
ogra_(but well, it works now, so all is fine)09:52
=== faenil_ is now known as faenil
mupPR snapd#1676 closed: interfaces: bluez: add missing mount security snippet case <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1676>10:05
mwhudsonzyga: i guess snapd will also not be a native package eventually :-)10:08
zygamwhudson: I'd like it not to be native package with the next debian upload10:14
zygamwhudson: if you can merge the changes from launchpad git branch that would be done too10:14
mwhudsonthe debian packaging is in an odd state i think10:15
mwhudsoni need to poke slangasek some more to get that organized iirc10:15
zygamwhudson: in which way?10:15
zygamwhudson: ok10:15
zygamwhudson: I'm glad to help, I'll apply to be a DM today10:15
mwhudsonzyga: cool, there is a new process!10:15
mwhudsonzyga: https://nm.debian.org/wizard/10:16
zyganew as in easier? :)10:16
* zyga does it right away10:16
mwhudsonzyga: do you know if there is any significant difference between the snap-confine packages in xenial and yakkety?10:27
mwhudsoni know some stuff got fixed as part of the SRU, but I *think* that got pushed into debian/yakkety too10:27
mupPR snapd#1677 opened: interfaces: bluez: add a few more tests to verify interface connection works <Created by morphis> <Conflict> <https://github.com/snapcore/snapd/pull/1677>10:34
morphiszyga: you were a bit too fast with merging that PR :-)10:34
morphiswas adding a few more tests for that10:34
zygamwhudson: mvo would know, I want to erase those differences10:35
zygamwhudson: I know mvo did cherry picks to ease the SRU process10:35
zygamorphis: oh :)10:35
zygamorphis: sorry then ;)10:35
zygamorphis: merging the 2nd one too10:35
morphiszyga: np, I didn't left a note so you couldn't know :-)10:35
zygamorphis: reviwed, thank you :-)10:36
ogra_mvo, hmm, did you foget to add the files to https://github.com/snapcore/classic-snap ? (i only see meta/snap.yaml)10:39
mvomorphis: 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 this10:39
mvoogra_: let me check10:40
mvoogra_: please pull again10:40
morphismvo, zyga: thanks10:40
ogra_better :)10:40
zygaI'd love to get a quick review on https://github.com/snapcore/snap-confine/pull/10210:41
mupPR snap-confine#102: Take upstream version from VERSION file <Created by zyga> <https://github.com/snapcore/snap-confine/pull/102>10:41
zygaanyone? :)10:41
morphiszyga: done10:44
=== Ivan is now known as Guest14900
zygamorphis: thank you11:02
morphiszyga: np11:02
zygamvo, mwhudson: https://github.com/snapcore/snap-confine/pull/10311:04
mupPR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>11:04
zygaand http://nm.debian.org/person/zyga11:05
morphissergiusens: can it be that the packaging logic in snapcraft doesn't include results of the organize statement?11:15
draglyIs it possible to add use a ppa for a snap's packages?11:15
morphissergiusens: see https://paste.ubuntu.com/23058108/11:16
SogatorI 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".11:46
=== Chipaca` is now known as Chipaca
zygaSogator: yes, I believe this is in the roadmap somewhere11:59
zygaSogator: there will be more details availble about particual developer11:59
jaceknwhich part of the installation process is responsible for creating $SNAP_USER_DATA directory? I noticed that whem my snap tries to start /root/snap/<snap-name>/x5/ does not exist and it causes problems12:15
mvoogra_: need help with that PR? I can merge your pastebin directly if that helps12:17
zygajacekn: that'd be snap-confine in the current SRU in ubuntu, later on it will be snapd itself12:33
zygajacekn: I believe the problem you are reporting is fixed in proposed now12:33
ogra_mvo, well, i'm heavily hit by the /dev/ptmx bug currently ... hard to test it that way12:37
morphismvo: I am wondering why I don't see my spread test executed in https://travis-ci.org/snapcore/snapd/jobs/15235699512:37
ogra_mvo, so i'm currently poking around in bin/shell ... https://github.com/ogra1/classic-snap12:37
zygaogra_: is this fixed by https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364 ?12:40
ogra_zyga, is that in any package yet ?12:40
mvoogra_: 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 packages12:41
mvomorphis: looking12:42
ogra_mvo, well, if we ever run confined ....12:42
zygaogra_: I don't know; mvo did you cherry pick that fix from master?12:43
mvozyga: what fix?12:43
ogra_how do i apply that manually if it isnt landed yet ?12:43
mvoogra_: I don't think so12:43
mvoogra_: yeah, you will have to manually get it12:44
mvoogra_: 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 snap12:45
mvoogra_: if its critical I can prepare a new SRU with that (its another regression?)12:45
ogra_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
mvomorphis: the file  tests/main/interfaces-bluez/spread.yaml  has to be  tests/main/interfaces-bluez/task.yaml12:46
morphismvo: ah12:47
mvoogra_: thanks, I think its fine to use the system ones, this is so low level there shouldn't be any practial difference12:47
ogra_i'll revert the branch then12:47
mupPR snapd#1678 opened: asserts: export DecodePublicKey <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1678>12:48
mvoogra_: thanks!12:49
ogra_hmm, whats the apparmor_parser line i need to re-gen the snap-confine profiile ?12:51
zygatimothy: hey, I've almost removed debian packaging of snap-confine12:51
ogra_(i hope bind mounting works, i cant write to /etc/apparmor.d/12:51
zygaogra_: apparmor_parser -r /etc/apparmor.d/the-file-there12:51
zygatimothy: please have a look at this https://github.com/snapcore/snap-confine/pull/10312:51
mupPR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>12:51
ogra_(classic)ubuntu@pi2:~$ cat create12:52
ogra_cat: standard output: Permission denied12:52
ogra_(classic)ubuntu@pi2:~$ sudo ls12:52
ogra_sudo: no tty present and no askpass program specified12:52
ogra_nope, no change12:52
zygatimothy: one thing you can see there is that it combines upstream source tarball with downstram packaging12:52
zygaogra_: is /dev/pmtx mounted?12:52
ogra_you mean /dev/pts :)12:53
zygatimothy: can you please point me to the location of arch packaging for snap-confine; I recalled you said it was in SVN somewhere12:53
zygammm, maybe, my tty subsystem know-how is rusty12:53
* zyga checks12:53
zygaogra_: how about /dev/pts/ptmx12:54
ogra_(classic)ubuntu@pi2:~$ mount|grep pts12:54
ogra_devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=666,ptmxmode=666)12:54
ogra_(classic)ubuntu@pi2:~$ ls /dev/pts/12:54
zygathat's okay12:55
ogra_seems that systemd-run somehow removes /dev/pts/012:55
zygaI don't know12:55
zygano, wait, each snap-confine started app gets private /dev/pts12:56
jaceknzyga: ack, thanks12:56
zygaperhaps that's the actual problem?12:56
ogra_zyga, well, we are running in devmode for classic12:57
ogra_does that still apply ?12:57
ogra_(i would guess snap-confine is completely suppressed in devmode)12:57
zygaogra_: NO12:58
zygano :_)12:58
ogra_aha, so it isnt confinement at all12:58
zygaogra_: in fact, snap confine doesn't care about devmode at all, snapd does12:58
zygaogra_: snap-confine does more than just confinement: http://www.zygoon.pl/2016/08/snap-execution-environment.html12:58
zygaogra_: one of the thing it does is sets up a private /dev/pts for your12:59
zygayour application process12:59
zygaperhaps for classic that is not desired12:59
ogra_and that has been deeply tested in alll-snap envs i guess ? :P12:59
zygaI think that now, with the mount profile support, we could have snapd *not* generate that for classic but do so for everyone else12:59
zygaogra_: yes12:59
zygaogra_: this code applies both on classic and in all snap13:00
jaceknzyga: also: https://bugs.launchpad.net/snapcraft/+bug/161326813:00
mupBug #1613268: SNAP_USER_DATA is not created automatically <Snapcraft:New> <https://launchpad.net/bugs/1613268>13:00
ogra_how ? we didnt have images til last week :P13:00
ogra_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 root13:00
ogra_(and has t been tesetd with systemd-run ... which classic uses to spawn the chroot)13:01
ogra_i have the feelling there are some bits clashing here13:01
zygaogra_: this code was unchanged for ages13:02
ogra_zyga, but since when do we use snap-confine in all-snap images ?13:02
ogra_i'm pretty sure we didnt use it with the last ones (which was about two months ago)13:03
ogra_and new images only exist since end of last week13:03
jdstrandogra_: hey, so, pc-kernel, pi2-kernel and dragonboard-kernel?13:03
ogra_jdstrand, yes please13:03
jdstrandogra_: any gadget snaps?13:04
ogra_jdstrand, nah, they change so rarely, i dont think we need them right now ... mvo ?13:04
ogra_ubuntu@dragonboard:~$ sudo ls -l /tmp/*classic* |wc -l13:12
ogra_it never cleans up ?13:14
zygaogra_: nope13:14
ogra_(snap-confine that is)13:14
zygaogra_: it's a known issue13:14
zygaogra_: (since uubntu-core-launcher days)13:14
ogra_ah, so it will ... at some point13:14
ogra_that fine then13:14
zygaogra_: 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
ogra_yeah, i thought switching to snap-confine would fix that already13:14
zygaogra_: I have an idea with vfork but I didnt' explore it yet13:14
zygaogra_: the switch was just a rename13:15
zygaogra_: and evolutionary changes since13:15
zygaogra_: it wasn't a rewrite of anything13:15
zygaogra_: the tmp directories you're seeing are all empty, correct/13:16
ogra_just wasting inodes13:16
ogra_(just makes debugging really hard (i.e. finding the right one) since there are so many)13:17
mupPR snapd#1677 closed: interfaces: bluez: add a few more tests to verify interface connection works <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1677>13:17
joc_fgimenez: ping13:17
zygaogra_: that's good, I'll try my idea when snap-confine is out of SRU pipe13:17
ogra_zyga, in any case the ptmx change doesnt seem to have any effect13:17
fgimenezjoc_, hey :)13:18
zygaogra_: can you rebuild snap-confine and change it in your test env easily?13:18
ogra_i dont get a tty and no /dev/pts/013:18
ogra_no, not easily13:18
zygaogra_: I'd like to check something about the pts error you are seeing13:18
zygaogra_: gah, too bad13:18
* zyga would love a snapd.snap with just a handful of executables13:18
joc_fgimenez: hi, i noticed you had a PR open for spread tests for serial-port interface13:18
ogra_i'd have to build the package, push it to the snappy-image ppa, rebuild the image etc13:19
cjwatsonAre 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
mvoogra_: 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
ogra_mvo, cat not working, sudo not works13:19
cjwatsonI guess you might call that subsubcommand13:19
joc_fgimenez: i have one open that adds extra functionality and changes the way it works a bit so can imagine they might break one another13:19
mvoogra_: works for me13:20
ogra_mvo, on arm ?13:20
mvoogra_: not on arm, interessting that this is arm specific, I can try tthat in a bit13:20
ogra_would be good ...13:20
fgimenezjoc_, 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
cjwatsonLike "lxc image ..."13:20
ogra_let me re-set my pi2 and try with the classic from the store ...13:20
ogra_cjwatson, like "snap install --devmore foobar" ?13:21
zygaogra_: so specifically sudo fails?13:21
joc_fgimenez: sounds good although i think i still need some reviews, https://github.com/snapcore/snapd/pull/166913:21
mupPR snapd#1669: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669>13:21
ogra_zyga, welll, there is no /dev/pts/0  ... so no tty ...13:21
cjwatsonogra_: Not really, there are no subcommands of "snap install"13:21
zygaogra_: please report a bug on snap-confine on launchpad, I'll take care of it13:22
zygaogra_: I can reproduce that anywhere13:22
cjwatsonogra_: I mean like "lxc image list" vs. "lxc list"13:22
cjwatsonogra_: Where "lxc image" is itself a thing that dispatches to its own subcommands13:22
ogra_cjwatson, ah, i dont think snappd has any "multi word" commands13:22
ogra_i thought you meant options13:22
ogra_only toplevel with options afaik13:23
zygaogra_: snapd doesn't care13:23
zygaogra_: snap for bzr should just fork13:23
fgimenezjoc_, 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 functionallity13:24
jdstrandroadmr: hi! the possible review tools update is a reality in r709 :)13:24
roadmrjdstrand: cool! I'll put that in the pipeline13:24
* ogra_ sighs ... classic.create on the pi2 takes ages ...13:25
joc_fgimenez: great :)13:25
cjwatsonogra_: Looks like go-flags supports subcommands, so it looks not too hard to do at least13:25
ogra_(using the classic from the store)13:25
jdstrandroadmr: thank you :)13:25
ogra_cjwatson, i think we use subcommands in ubuntu-device-flash (source is goget-ubuntu-touch)13:25
ogra_multiple actually13:25
mupPR snapd#1605 closed: asserts: introduce support for assertions with no authority, implement serial-request <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1605>13:26
jdstrandahoneybun: 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:26
cjwatsonogra_: Just the top-level set of commands, I think, which is the same level of nesting as snap.  Never mind, I'll figure something out13:27
ogra_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
ogra_mvo,  the symptoms are:13:35
ogra_(classic)ubuntu@pi2:~$ sudo ls13:35
ogra_sudo: no tty present and no askpass program specified13:35
ogra_(classic)ubuntu@pi2:~$ cat .bashrc13:35
ogra_cat: standard output: Permission denied13:35
ogra_(classic)ubuntu@pi2:~$ ls /dev/pts/13:35
ogra_no /dev/pts/013:35
ogra_(so sudo isnt wrong when complaining about no tty)13:35
mvoogra_: thank you, booting my pi2 now13:36
ogra_this is also interesting:13:38
ogra_(classic)ubuntu@pi2:~$ ls /dev/std*13:38
ogra_ls: cannot access '/dev/stderr': Permission denied13:38
ogra_ls: cannot access '/dev/stdin': Permission denied13:38
ogra_ls: cannot access '/dev/stdout': Permission denied13:38
zygaogra_: that's interesting13:39
zygaogra_: ls -ld /dev /dev/stderr13:39
ogra_(classic)ubuntu@pi2:~$ ls -ld /dev/std*13:40
ogra_lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stderr -> /proc/self/fd/213:40
ogra_lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stdin -> /proc/self/fd/013:40
ogra_lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stdout -> /proc/self/fd/113:40
ogra_(classic)ubuntu@pi2:~$ ls -ld /proc/self/fd/*13:40
ogra_ls: cannot access '/proc/self/fd/255': No such file or directory13:40
ogra_ls: cannot access '/proc/self/fd/3': No such file or directory13:40
ogra_lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/0 -> /dev/pts/013:40
ogra_lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/1 -> /dev/pts/013:40
ogra_lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/2 -> /dev/pts/013:40
ogra_(and /dev/pts/0 is missing, like i said above)13:41
zygait all makes sense13:42
zygaogra_: 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 snapd13:42
zygaogra_: but I worry this might be something we have to ack with jdstrand first13:43
mvoogra_: on my pi2 (fresh image) http://paste.ubuntu.com/23058387/ - what do I need to do to trigger the issue13:43
zygajdstrand: later on when you have time13:43
ogra_mvo, hmm13:44
ogra_mvo, i upgraded my image to rev 24913:44
mvoogra_: I'm on r249 as well13:45
mvoogra_: via a serial port though, how do you access it?13:45
* mvo looks13:45
ogra_let me try serial13:45
jdstrandogra_: did you see what docker did to work around this?13:45
ogra_mvo,  WOAH !13:46
ogra_ubuntu@pi2:~$ sudo classic.shell13:46
ogra_(classic)ubuntu@pi2:~$ sudo ls13:46
ogra_[sudo] password for ubuntu:13:46
ogra_so it is ssh induced somehow13:46
mvoogra_: aha, but I see the same issue with ssh13:46
mvoogra_: thanks, that was the missing piece13:46
ogra_any idea what it actualyl is ?13:46
mvoogra_: yes, there is a open bug13:47
zygawow, curious indeed13:47
jdstrandyou're talking about bug #1611493 correct?13:47
mupBug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493>13:47
mvojdstrand: yes13:47
mvojdstrand: thats the one13:47
jdstrand"The work-around identified there (use "script -qc <cmd> /dev/null") works in snaps too."13:47
mvojdstrand: I wonder if there is something else we can do, I have not looked into this enough yet though to really have an opinion13:48
jdstrand"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
zygamvo: the page talks about bind mountint /dev/console13:48
mvojdstrand: oh, sweet13:48
zygaas a workaround13:49
ogra_jdstrand, well, that nests ttys13:49
jdstrandit's a workaround13:49
ogra_extremely ugly13:49
mvojdstrand: we can check the fix in our image ppa13:49
jdstrandthe fix is in glibc aiui13:49
ogra_and forces you in classic.shell to log out twice13:49
* ogra_ tried the script hack already and indeed it works ... 13:50
jdstrandI suspect an openpty() would work13:50
mvoyeah, I think we want the glibc fix13:50
jdstrandbut this is an area I'm not super versed in13:50
ogra_i still dont get why ssh causes it though13:50
ogra_but iit works fine oon native ttys13:50
* ogra_ has the slight feeling thats not the same as the above bug 13:51
mvoogra_: native are real ttys13:51
ogra_oh, ok13:51
mvoogra_: if you look at stdout its pointing to /dev/ttyAMA013:51
ogra_yeah, got it13:51
mvojdstrand: how much will you hate me if I upload a glibc with the fix to our image ppa for testing the fix?13:52
ogra_mvo, how much will iinfinity hate you should be the question13:52
jdstrandI wouldn't hate that-- it is 'just' the image ppa. might want to get tyhicks' thoughts on this (or another member of the security team who has more experience with ttys). tyhicks, for your reference, mvo wants to apply https://sourceware.org/ml/libc-alpha/2016-08/msg00249.html to glibc to test a fix for bug #161149313:53
mupBug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493>13:53
ogra_jdstrand, "just" ... the ubuntu-core that creates goes to LTS installs ;)13:54
ogra_(once it moved to the stable channel)13:54
jdstrandhence the quotes13:54
mvoogra_: the "once ... " caveat is kind of important here ;)13:54
ogra_heh, yeah, indeed13:54
ogra_well, long term stable should not use PPAs at alll13:54
ogra_thats at least my plan13:54
mvohappy to hold the horses for now, but I'm keen to get this fixed, we hit it in other contextes too13:55
ogra_but there are still many SRUs in the way first13:55
ogra_(nothing for RTM anyway ... but for GA)13:55
mvoI think we are doing well so far and the goal is to push it into our packaging (or upstream) once we verified that it indeed fixes the issue13:55
jdstrandtyhicks: if you need me to look at it, I'm happy to, just would need to push this ahead of the other stuff I'm working on13:55
ogra_mvo, just go ahead then13:55
ogra_mvo, also ... if snap-confine actually wraps classic.shell ... do we actually need any of the bind mounting for sys, proc, dev and devpts in the script ?13:56
ogra_sounds like duplication13:57
ogra_at least by what zyga said above13:57
jdstrandtyhicks: note, this is only for testing in !stable-- it sounds like they would wait on the upstream fix to be applied before pushing to stable (and pursuing an SRU)13:59
mvoogra_: I think we still need it, but feel free to play around and if not, even better, I will be happy if we can drop it13:59
camakoCan I get more reviews on this one? https://github.com/ubuntu/snappy-playpen/pull/20514:02
mupPR ubuntu/snappy-playpen#205: Mesa demos <Created by camako> <https://github.com/ubuntu/snappy-playpen/pull/205>14:02
mupPR snapd#1678 closed: asserts: export DecodePublicKey <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1678>14:09
mupPR snapd#1460 closed: interfaces: mpris updates (fix unconfined introspection, add name attribute) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1460>14:12
* ogra_ sighs ... i somehow messed up my github setup and cant make a PR 14:19
mupPR snapd#1673 closed: partition: Revert "clear snap_try_{kernel,core} on success" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1673>14:30
* ogra_ sighs, i'm going crazy ... 14:47
ogra_mvo, i can not make github recognize the switch to unsquashfs :/ it is never shwing up in my PR14:48
* ogra_ wasted the last hour on that crap :/14:48
ogra_ERR !14:49
ogra_mvo, when did you merge that in ? i just notice that you seemingly already added my code ...14:49
ogra_geez !14:49
mvoogra_: I did? let me check14:51
ogra_mvo, yeah ... https://github.com/snapcore/classic-snap/blob/master/bin/create has all my code already14:53
mvoogra_: hm, that was a mistake, yeah, create has the unsquashfs bits in there already14:53
mvoogra_: hm, I can fix that, I would like to have a proper history14:53
ogra_and i was thinking i'm going crazy14:53
mvoogra_: give me a minute14:53
ogra_(or am to dumb for github (which i am probably anyway ... ))14:54
mvoogra_: embrace it, git is great14:54
mvoogra_: (its really not, bzr has a so much nicer UI, but the world has moved on)14:54
ogra_mvo, well, if it does what i want it is okayish :)14:54
ogra_but trying to create a PR for something that is already there is kind of not working ... :P14:55
mvoogra_: please try now14:55
ogra_i can only view the former PR14:58
ogra_i guess i need to delete my fork and re-fork14:59
ogra_it whines about "snapcore:master and ogra1:master are entirely different commit histories. "15:00
* ogra_ starts over 15:00
mupPR snapd#1679 opened: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679>15:03
ogra_mvo, there you go https://github.com/snapcore/classic-snap/pull/215:09
mupPR classic-snap#2: switch to snapcraft.yaml (so we can eventually have launchpad builds for all arches), do not use cp -a but unsquashfs to speed up create <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/2>15:09
zygaogra_: I would recommend using longer commit messages, with newlines, so that tig/git log is easier to parse15:10
ogra_zyga, well, i would have used two PRs but i'm at a level of annoyance from github that i just want it gone now15:11
zygaogra_: you can still edit that, just give it a try15:11
zygaogra_: I know tools can be frustrating15:12
ogra_zyga, i am wasting nearly 2h already for 5 lines of code, i wont touch that stuff anymore for today, really15:12
zygaogra_: just a friendly note, don't take it personally15:12
ogra_LP never frustrated me like that15:12
ogra_zyga, i do take it personally, i *know* there is code hidden  in github somwhere that has "if user = ogra1; do annoy()" ... there must be !15:13
zygaogra_: what did you try to do?15:13
ogra_zyga, i tried to do a PR of code that was accidentially already merged15:13
ogra_and then messed up my branch completely a few times during the attempts15:14
draglyzyga: Thanks for all the help earlier with getting qt-based apps working with snap-confine. I now have a heavy Qt application running after installing it with a snap package on a VirtualBox machine. Amazing!15:17
mupPR snapd#1672 closed: tests: add serial-port interface spread test <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/1672>15:18
zygadragly: woot, that's great15:20
zygadragly: what's the app?15:21
ogra_zyga, mvo regarding https://github.com/snapcore/snapd/pull/1679 ... you are aware that you potentially enforce a PATH thet the sysadming changed in /etc/sudoers (also, do all distros use the same secure_path ? you might need per-distro files here for other distros)15:22
mupPR snapd#1679: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679>15:22
* ogra_ thinks that should rather come from a postinst script that checks the existing secure_path in /etc/sudoers and assembles something from that for /etc/sudoers.d/snapd15:23
ogra_(since you completely wipe whatever was in /etc/sudoers by default)15:24
mvoogra_: hm, that is a bit terrible indeed15:27
mvoogra_: fwiw, I don't postinst will help because the path may be modied in /etc/sudoers after snapd got installed and the assemble magic was run15:27
ogra_jdstrand once explaied to me why it would be more terrible to allow /etc/sudoers.d/ snippets to extend secure_path randomly ... but i forgot15:28
ogra_mvo, well, at least you would catch that on snapd updates ...15:28
mvoogra_: true15:28
ogra_defintely no ideal either15:28
mvoogra_: if we put it low in the numbering, we could suggest that sysadmins use /etc/sudoers.d/99-local for all local overrides, but that is not ideal either (sudoders already has the suggestion to not edit this file)15:29
ogra_mvo, yeah ... i guess it isnt very common to change it ... except for the hardcore "hardening" sysarmins that probably only aloow a certain dir in the path or so15:31
ogra_but these guys will whine ...15:31
draglyzyga: A molecular dynamics visualization software named Atomify LAMMPS: https://github.com/ComputationalPhysics/atomify-lammps/releases/tag/2.0.215:31
zygaogra_: I'm aware of per-distro secure path15:31
zygadragly: awesome!15:32
ogra_("i installed snapd and suddenly all my users can access /usr/local via sudo which i prevented !!!")15:32
zygaogra_: I think we have to do something more fine grained there, I didn't give it much though though15:33
ogra_zyga, yeah ... the prob is that it isnt designed for fine grained :)15:33
ogra_on putrpose apparently15:34
mvoogra_: hm, I don't see much alternatives - either break PATH for everyone when using sudo (what we have now). or break a few people who use sudoers directly even if sudoers explains that this file should not be used like this15:34
ogra_mvo, yeah ... go with a low number for now and lets see if anykone screames15:34
ogra_i assume we wont convince sudo upstream to make the path extensible/appendable15:35
mvoogra_: I guess the alternative is to make our sudo package include /snap/bin15:35
ogra_probably there would be some complex way through pam though15:36
ogra_mvo, yeah, thats the other option15:36
mvoif we do that the mentioned problem goes away but we will also trigger a conffile prompt for anyone who has customized it. maybe the right punishment ;) for not using sudoers.d15:37
ogra_clever move :)15:37
* zyga mutters something about /usr/lib vs /etc15:41
mhall119sergiusens: is there any way to make a cleanbuild lxc container persistent?15:50
=== chihchun is now known as chihchun_afk
jdstrandmvo (cc tyhicks): you are adjusting sudo's secure_path via something in /etc/sudoers.d?15:51
mvojdstrand, tyhicks: not yet, but I pushed a PR for it https://github.com/snapcore/snapd/pull/167915:53
mupPR snapd#1679: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679>15:53
mvojdstrand, tyhicks: happy to hear alternative ideas how we can have /snap/bin in the PATH when sudo is used15:54
jdstrandI don't think I like that15:54
mvojdstrand: having /snap/bin in the sudo path at all?15:54
mvojdstrand: or just this way of adding it?15:55
jdstrandbecause for 12 years people know to look in /etc/sudoers to adjust secure_path if they need to. now they would adjust it only to have it overriden to what is in snapd. they two might go out of sync, etc15:55
jdstrandfor 15.04 we used ubuntu-core-config to adjust /etc/sudoers to include it last in the path15:55
jdstrandthe PR also doesn't consider that other distros may not set secure_path or that they may have a different one than Ubuntu15:56
jdstrandmvo: as for setting it at all, I'm not thrilled about adding it to root's secure_path, no, but I'm not sure there is a choice. if we are doing it, I think I prefer /etc/sudoers is modified for Ubuntu15:57
jdstrandtyhicks: thoughts? ^15:57
mvojdstrand: ok, fair enough, I will paste this into the PR and close it, I'm fine with modifying sudo15:58
jdstrandtyhicks: (background, upstream doesn't have support for appending to secure_path)15:58
mupPR snapd#1679 closed: debian: add /snap/bin to the secure-path <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1679>15:58
tyhicksjdstrand: I agree - modifying /etc/sudoers at the distro level is the better solution since the PR isn't appropriate for other distros15:59
mhall119zyga: ping, checking on the status of (A) setting runtime envvars for snaps and (B) the serial-port plug (needed by arduino IDE to run without -devmode)16:00
tyhicksjdstrand, mvo: I've been looking at the tty patch for libc - upstream is still discussing the appropriate change and it seems to me that it is still a little early to apply one of the several patches that have been sent to the list16:02
jdstrandtyhicks: thanks16:02
draglyzyga: Is it possible to install snap-packages without sudo? Or will it be in the future?16:02
mhall119dragly: if you use "snap login" you can then install without sudo16:02
jdstrandtyhicks: oh, and thanks for that too :)16:02
* jdstrand wonders if there is an openpty() option that could be done16:03
draglymhall119: Cool! I'll try that.16:03
tyhicksthey're rapidly iterating on the correct change - I wouldn't be surprised if they settle on something this week16:04
jdstrandah, cool16:04
tyhicksthere are still open questions and no updated patch for https://sourceware.org/ml/libc-alpha/2016-08/msg00333.html16:07
draglymhall119: That worked flawlessly. Thanks!16:11
mhall119happy to help :)16:17
dobeysnappy doesn't use debsig-verify right?16:24
kyrofadobey, indeed, that was 15.0416:37
ahoneybunjdstrand: it's not a security thing I think16:44
ahoneybunI added python-dbus to stage and still the same error16:44
ahoneybunoh noes soee16:45
soeeahoneybun: sup ? :)16:45
ahoneybunmhall119: still hanging around?16:51
ahoneybunhttp://pastebin.ubuntu.com/23059037/ | AttributeError: 'NoneType' object has no attribute 'get_bus'16:53
=== allesz_ is now known as allessz
rtsisykI'm trying to pack my daemon using snapcraft. I use git source and cmake as the build system. How to add `git describe --long --always` content to a file in the source tree before invoking cmake?17:14
rtsisyksnapcraft strips .git folder from the source tree, so my cmake scripts fails to retrieve version for git17:16
rtsisykI need to put `git describe --long --always` result to the source directory in order to build package.17:17
rtsisykany ideas?17:26
rtsisykI failed to find a proper example in snappy-playground17:26
rtsisykis it possible to use existing Debian package to build snappy package?17:28
mhall119ahoneybun: yup17:31
rtsisykahh, there are no tags in clonned git repo! I need `git fetch --tags`.17:36
gc_snapHi! Is it possible to unregister a snap from the ubuntu store?17:39
mupPR snapcraft#730 opened: Clarification of make plugin help text <Created by mikemccracken> <https://github.com/snapcore/snapcraft/pull/730>17:42
ahoneybunmhall119: worked on any snap with python?17:50
rtsisykhttps://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources.py#L164-L186 both cases don't work for me.17:51
mhall119ahoneybun: yeah, hello-unity17:51
mupPR snapd#1680 opened: overlord/assertstate,daemone: reorg how the assert manager exposes the assertion db and adding to it <Created by pedronis> <https://github.com/snapcore/snapd/pull/1680>17:51
ahoneybunmhall119: http://pastebin.ubuntu.com/23059037/17:52
rtsisykI tried to put snapcraft.yml into the source directory of my app, but snapcraft still tries to copy sources to parts/myapp/src using git clone --depth 117:52
ahoneybunany thing from this?17:52
kyrofartsisyk, I'm not quite sure what you're asking here17:59
kyrofaCan I see your YAML?17:59
ahoneybunsergiusens: thanks a lot for the telegram update18:00
rtsisykkyrofa: I'm sorry, I found problem in my cmake script, s/${GIT} describe --long HEAD/${GIT} -C ${CMAKE_SOURCE_DIR} describe --long/g.18:01
rtsisyknow I can build my binary18:01
rtsisykwhat is about init scripts?18:01
* ahoneybun wonders if his issue is from all the "No libraries to exclude this release" lines18:01
kyrofartsisyk, ah, okay18:01
kyrofaahoneybun, are you running on yak?18:02
rtsisykI have systemd .service file, is it useful for snappy?18:02
kyrofartsisyk, no, snapd will generate those based on the information you give it18:02
ahoneybunI am kyrofa18:02
kyrofaahoneybun, yeah, bad idea18:02
kyrofaahoneybun, we recommend running snapcraft on the same distro you're targeting, or slightly older. Newer and you may very well run into libc issues, not to mention the one you're hitting now: there's no core snap based on y18:03
ahoneybunwell it installed ubuntu-core18:04
ahoneybunsnaps run fine here18:04
rtsisyk@kyrofa: my service file have support for multi-instance and so on.18:04
nothalrtsisyk: No such command!18:04
kyrofaahoneybun, sure, but I'm talking about building them18:04
ahoneybunif anything I can throw the yaml on my laptop with xenial18:05
kyrofaahoneybun, snapd bundle a lot of dependencies but not all of them. Notably libc18:05
gc_snapI'm sorry if this was answered earlier... is it possible to remove a snap from the store (provided I uploaded it, of course)18:05
mhall119ahoneybun: are you using the desktop/gtk(2|3) part?18:06
ahoneybundesktop/gtk3 after18:06
ahoneybunadded python3-dbus in stage and built18:06
ahoneybunstill there18:08
mhall119ahoneybun: my guess is you're missing a gstreamer plugin18:08
mhall119ahoneybun: see https://github.com/pithos/pithos/blob/master/pithos/pithos.py#L17518:08
ahoneybunyaml : http://pastebin.ubuntu.com/23059200/18:09
mhall119self.player is None on line 177, which means it's not being set properly on line 17518:09
ahoneybuncan't find that in packages.ubuntu.com18:10
mhall119ahoneybun: try adding rygel-playbin to your stage-packages18:14
ahoneybunwhere did you get that ?18:16
mhall119apt-cache search "playbin"18:16
mhall119also, apt-cache depends --recurse pithos |grep -i playbin18:16
ahoneybunbut why that package18:17
ahoneybunI need to know18:17
rtsisykwhere I can find snapcraft.yml example for daemons?18:19
mhall119hey, I only have edge and beta available as channels for my app in the store, how do I get stable?18:20
kyrofartsisyk, please read through this: http://snapcraft.io/create/18:20
kyrofartsisyk, it'll walk you through apps and daemons18:21
kyrofartsisyk, but here's another example, one of the snapcraft demos: https://github.com/snapcore/snapcraft/blob/master/demos/shout/snapcraft.yaml18:22
ahoneybunsame thing18:25
rtsisykthanks. My daemon needs a config file provided by user to start...18:26
powersjmhall119, does your app run in confinement mode strict?18:28
mhall119ahoneybun: in that cause, it could be that gstreamer needs some setting to tell it where to find it18:28
powersjor still require devmode? I believe if devmode is required you are limited to beta and edge18:28
mhall119powersj: devmode, is that the cause?18:29
mhall119something should tell the developer this, it's not obvious18:29
powersjmhall119, yeah see 2nd paragraph under Developer mode here: http://snapcraft.io/docs/core/usage18:29
mhall119I meant something in the sore18:30
renato__guys, Hey I am creating a EDS snap it is working nice as normal app. But I changed the service to run as daemon and the apps are not staring18:30
renato__this is the full log, http://paste.ubuntu.com/23059185/18:31
renato__sergiusens, ^^^ any idea about that?18:32
mhall119ok, it's on the upload form too, maybe I'm just being thick18:32
kyrofamhall119, yeah it does, right next the channel selection dialog18:34
kyrofaAh, yeah you saw that, sorry18:34
mhall119kyrofa: it doesn't say it here though: https://myapps.developer.ubuntu.com/dev/click-apps/5719/upload/19776/edit/18:35
mhall119which is where I was looking and thinking "where is stable?"18:35
kyrofamhall119, ah, then yes, I agree!18:35
kyrofamhall119, mention it to the store folks18:36
kyrofarenato__, to make sure I understand, you were previously able to run these things as apps, but now that they're services, they don't work?18:36
kyrofarenato__, were you running the apps with sudo, or as a normal user?18:37
wililupyin my snapcraft.yaml, if I need a specific branch from a git, how would I do that?18:37
mhall119kyrofa: who are the store folks these days?18:37
mhall119it used to be I just complained to beuno a lot18:37
kyrofamhall119, nessita is always my go-to. She knows all18:37
kyrofaShe can at least get you to where you need to go :)18:37
nessitamhall119, hi! how can I help?18:38
nessitakyrofa, and thanks for all those nice words!18:38
renato__kyrofa, yes it was running nice as normal snaps  apps.18:38
mhall119nessita: can we get the text about devmode limiting channels from the upload form added also to https://myapps.developer.ubuntu.com/dev/click-apps/5719/upload/19776/edit/18:38
renato__kyrofa, yes I am runinng with root using my dev version of snap18:38
nessitamhall119, would you please create a bug so we can track the request there?18:39
mhall119nessita: lp:software-center-agent still?18:39
kyrofarenato__, like, you `sudo su -` then run the apps?18:39
kyrofarenato__, or you ran them as a normal, unprivileged user?18:39
nessitamhall119, yes, thank you18:39
renato__kyrofa, I run the app without sudo. But install it with sudo18:40
rtsisykcan i use svg for "icon:"?18:40
kyrofaOf course18:40
kyrofartsisyk, you can! svg or png18:40
rtsisykhow to check icon for packaged snap file?18:40
kyrofarenato__, okay. And it seems you're using SNAP_USER_DATA?18:40
kyrofartsisyk, I don't quite understand what you're asking18:41
renato__kyrofa, I am not sure what this SNAP_USER_DATA is :D18:41
kyrofarenato__, ah, then just $HOME perhaps18:41
renato__kyrofa, this is my snapcraft file: http://paste.ubuntu.com/23059245/18:42
kyrofarenato__, a big difference between apps and services is that apps run as whoever ran them, and services run as root18:42
renato__kyrofa, humm this can be the problem, I need the service running on user session18:42
kyrofaWhich means the user-specific data directory (SNAP_USER_DATA) is in /root/snap/<snap>/<revision>18:42
kyrofaAh indeed18:42
renato__kyrofa, I need to connect with dbus session18:42
kyrofarenato__, snapd doesn't currently have a concept of user services18:43
renato__kyrofa, ok this is the problem then18:43
kyrofarenato__, definitely18:43
rtsisykDEPRECATED: 'license' defined in snapcraft.yaml18:44
kyrofaniemeyer, I seem to remember a conversation about user services. Did anything ever come of that conversation?18:44
mhall119kyrofa: nessita: how can I publish both an amd64 and i386 snap?18:46
rtsisykhttps://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute/  This page does not exist. Well, obviously this page exists. But the page you requested does not exist. This page is just here to tell you that the page you requested does not exist.18:48
rtsisykI can't register proper name18:50
mupPR snapd#1667 closed: many: implement snapctl command <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1667>19:23
mupBug #1613420 opened: no way to run daemons on user session  <Snappy:New> <https://launchpad.net/bugs/1613420>19:42
niemeyerkyrofa: No, not much20:03
mupPR snapcraft#731 opened: Factor parts config into snapcraft/internal/parts.py <Created by josepht> <https://github.com/snapcore/snapcraft/pull/731>20:36
dobeywhat's the equivalent in snap, of "click info $package" ?21:14
kgunnkyrofa: ping21:57
kyrofakgunn, pong, how are you?21:58
kgunnkyrofa: good man how are you21:58
kyrofakgunn, I'm doing well!21:58
kgunnkyrofa: hey i was wondering, if i wanna snap up some stuff (say..unity8) and i don't really need to build it...just pull what's in archive21:59
kgunncan i just leave nil21:59
kgunn(nil plugin)21:59
kyrofakgunn, just using stage-packages?21:59
kgunnand then list all the pkgs in stage?21:59
kgunnyeah..that's the thinking21:59
kyrofakgunn, sure, but there are limitations there, e.g. postinst scripts aren't run etc.21:59
kgunnkyrofa: oh yeah...i know i'll have to add a wrapper scriptfor launch22:00
kyrofakgunn, packages in the archive may also be looking for files in e.g. /etc/ that are now in $SNAP/etc/, and so on22:00
kgunnah, but yeah, that's a good point22:00
kyrofakgunn, but yeah, as long as you're okay with those debs essentially being tar files (i.e. they're just unpacked into the snap), then you should be good22:00
kgunnkyrofa: k i'll prolly just give it a go and deal with pathing weirdness as and when i hit it22:01
kyrofaYeah it's an easy path to try anyway as long as the packages don't make heavy use of postinst22:01
kyrofakgunn, e.g. don't even try doing apache22:02
kgunnkyrofa: sounds like experience ?22:02
kyrofaYeah that was my initial foray into snapping. Should have started with something easier22:03
kgunni figure u8 will be a mess22:03
kgunnshould be fun22:03
kyrofaYeah you'll be even more familiar with it than you are now!22:04
kgunnkyrofa: thanks for the advice...dropping for a bit22:04
kyrofakgunn, any time, have a good one!22:04
mupPR snapd#1681 opened: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1681>23:14

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!