| mwhudson | er where can i get a good kernel snap from? | 02:13 |
|---|---|---|
| mwhudson | ah i think maybe my gadget snap was old or something | 02:19 |
| === JanC is now known as Guest35265 | ||
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 07:06 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR 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 |
| mup | PR 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 |
| mup | PR 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_ | ? | 09:10 |
| ogra_ | (probably needs squashfs-tools and coreutils in stage-packages and adjusted paths) | 09:10 |
| zyga | mwhudson: hey | 09:11 |
| zyga | mwhudson: 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 version | 09:13 |
| mvo | ogra_: thanks! let me create a git branch | 09: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 |
| mvo | ogra_: its on github as "classic-snap" | 09:16 |
| ogra_ | cool, i'll prepare a PR | 09:16 |
| mvo | ogra_: thanks | 09:17 |
| zyga | mwhudson: looking at the QA page it seems that you do, can you please add me to uploaders please | 09:22 |
| mwhudson | zyga: sure | 09:22 |
| mwhudson | zyga: are you a DM yet? | 09:22 |
| zyga | mwhudson: I'd like to convert the package so that it is not a native package | 09:22 |
| mwhudson | zyga: what email? | 09:22 |
| zyga | mwhudson: no :/ | 09:22 |
| zyga | mwhudson: please try me@zygoon.pl | 09:22 |
| zyga | mwhudson: all I need right now is to have write access to the git repo on alioth | 09:23 |
| mwhudson | zyga: i can't grant that :/ | 09:23 |
| mwhudson | zyga: you need to be in collab-maint, and you need to be a DM for that | 09:23 |
| zyga | hmmm | 09:23 |
| mwhudson | zyga: however! | 09:23 |
| mwhudson | zyga: if you push to github or something i can just merge --ff-only that | 09:23 |
| zyga | I did edit some packages in collab-maint AFAIR but perhaps that's my memory being rusty | 09:23 |
| mwhudson | zyga: also, it already isn't a native package | 09:24 |
| mwhudson | oh | 09:24 |
| zyga | mwhudson: that's perfect then | 09:24 |
| zyga | mwhudson: oh? it seems to be in the master branch | 09:24 |
| mwhudson | but i think i know what you mean | 09:24 |
| mwhudson | zyga: master is just a mirror of github.com/snapcore/snap-confine | 09:24 |
| zyga | aaaah | 09:24 |
| zyga | cool | 09:24 |
| mwhudson | zyga: the debian bits are in the 'debian' branch | 09:24 |
| zyga | let me run a quick spread test | 09:24 |
| zyga | :-) | 09:24 |
| zyga | mwhudson: I pushed some updates to https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/master | 09:25 |
| mwhudson | the debian directory gets deleted in the upstream branch and then re-added in debian | 09:25 |
| zyga | mwhudson: spread tests use that for constructing a package | 09:26 |
| mwhudson | it would be a good deal less silly to not have the debian dir in master | 09:26 |
| zyga | mwhudson: my branch will finally remove the debian directory from upstream packaging | 09:26 |
| mwhudson | from my pov, other povs may differ | 09:26 |
| zyga | mwhudson: I fully agree | 09:26 |
| * mwhudson has not yet internalized how lp git urls work | 09:27 | |
| zyga | hehe, me neither | 09:27 |
| mwhudson | ah, third time lucky | 09:27 |
| zyga | if you look at https://git.launchpad.net/snap-confine/tree/debian | 09:27 |
| zyga | you will see that there are no patches | 09:27 |
| zyga | the debian directory doesn't have the apparmor profile anymore | 09:27 |
| zyga | and there are some slight changes to rules | 09:27 |
| zyga | but that's all | 09:28 |
| zyga | if you could merge that into alioth then my spread tests would work for sid, xenial and yakkety :) | 09:28 |
| mwhudson | oh, it's based on an import-dsc | 09:28 |
| mwhudson | zyga: uh can you send email about this? | 09:29 |
| zyga | mwhudson: sure | 09:29 |
| mwhudson | zyga: life is happening here | 09:29 |
| zyga | mwhudson: do you directory? | 09:29 |
| zyga | :D | 09:29 |
| zyga | directly* | 09:29 |
| zyga | mwhudson: sent | 09:34 |
| === faenil is now known as faenil_ | ||
| mup | PR snapd#1676 opened: interfaces: bluez: add missing mount security snippet case <Created by morphis> <https://github.com/snapcore/snapd/pull/1676> | 09:46 |
| mwhudson | zyga: ta | 09: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 work | 09:52 |
| cjwatson | ogra_: pass; perhaps a store problem of some kind | 09:52 |
| cjwatson | ogra_: but good to know it works now, thanks | 09:52 |
| ogra_ | (but well, it works now, so all is fine) | 09:52 |
| === faenil_ is now known as faenil | ||
| mup | PR 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 |
| mwhudson | zyga: i guess snapd will also not be a native package eventually :-) | 10:08 |
| zyga | mwhudson: I'd like it not to be native package with the next debian upload | 10:14 |
| zyga | mwhudson: if you can merge the changes from launchpad git branch that would be done too | 10:14 |
| mwhudson | the debian packaging is in an odd state i think | 10:15 |
| mwhudson | i need to poke slangasek some more to get that organized iirc | 10:15 |
| zyga | mwhudson: in which way? | 10:15 |
| zyga | mwhudson: ok | 10:15 |
| zyga | mwhudson: I'm glad to help, I'll apply to be a DM today | 10:15 |
| mwhudson | zyga: cool, there is a new process! | 10:15 |
| mwhudson | zyga: https://nm.debian.org/wizard/ | 10:16 |
| zyga | new as in easier? :) | 10:16 |
| zyga | ooooh | 10:16 |
| mwhudson | hopefully | 10:16 |
| * zyga does it right away | 10:16 | |
| mwhudson | zyga: do you know if there is any significant difference between the snap-confine packages in xenial and yakkety? | 10:27 |
| mwhudson | i know some stuff got fixed as part of the SRU, but I *think* that got pushed into debian/yakkety too | 10:27 |
| mup | PR 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 |
| morphis | zyga: you were a bit too fast with merging that PR :-) | 10:34 |
| morphis | was adding a few more tests for that | 10:34 |
| zyga | mwhudson: mvo would know, I want to erase those differences | 10:35 |
| zyga | mwhudson: I know mvo did cherry picks to ease the SRU process | 10:35 |
| zyga | morphis: oh :) | 10:35 |
| zyga | morphis: sorry then ;) | 10:35 |
| zyga | morphis: merging the 2nd one too | 10:35 |
| morphis | zyga: np, I didn't left a note so you couldn't know :-) | 10:35 |
| zyga | morphis: 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 |
| mvo | 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:39 |
| mvo | ogra_: let me check | 10:40 |
| mvo | ogra_: please pull again | 10:40 |
| morphis | mvo, zyga: thanks | 10:40 |
| ogra_ | better :) | 10:40 |
| zyga | I'd love to get a quick review on https://github.com/snapcore/snap-confine/pull/102 | 10:41 |
| mup | PR snap-confine#102: Take upstream version from VERSION file <Created by zyga> <https://github.com/snapcore/snap-confine/pull/102> | 10:41 |
| zyga | anyone? :) | 10:41 |
| morphis | zyga: done | 10:44 |
| === Ivan is now known as Guest14900 | ||
| zyga | morphis: thank you | 11:02 |
| morphis | zyga: np | 11:02 |
| zyga | mvo, mwhudson: https://github.com/snapcore/snap-confine/pull/103 | 11:04 |
| mup | PR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103> | 11:04 |
| zyga | and http://nm.debian.org/person/zyga | 11:05 |
| morphis | sergiusens: can it be that the packaging logic in snapcraft doesn't include results of the organize statement? | 11:15 |
| dragly | Is it possible to add use a ppa for a snap's packages? | 11:15 |
| morphis | sergiusens: see https://paste.ubuntu.com/23058108/ | 11:16 |
| Sogator | 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". | 11:46 |
| === Chipaca` is now known as Chipaca | ||
| zyga | Sogator: yes, I believe this is in the roadmap somewhere | 11:59 |
| zyga | Sogator: there will be more details availble about particual developer | 11:59 |
| jacekn | 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/<snap-name>/x5/ does not exist and it causes problems | 12:15 |
| mvo | ogra_: need help with that PR? I can merge your pastebin directly if that helps | 12:17 |
| zyga | jacekn: that'd be snap-confine in the current SRU in ubuntu, later on it will be snapd itself | 12:33 |
| zyga | jacekn: I believe the problem you are reporting is fixed in proposed now | 12:33 |
| ogra_ | mvo, well, i'm heavily hit by the /dev/ptmx bug currently ... hard to test it that way | 12:37 |
| morphis | mvo: I am wondering why I don't see my spread test executed in https://travis-ci.org/snapcore/snapd/jobs/152356995 | 12:37 |
| ogra_ | mvo, so i'm currently poking around in bin/shell ... https://github.com/ogra1/classic-snap | 12:37 |
| zyga | ogra_: is this fixed by https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364 ? | 12:40 |
| ogra_ | zyga, is that in any package yet ? | 12:40 |
| mvo | 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:41 |
| mvo | morphis: looking | 12:42 |
| ogra_ | mvo, well, if we ever run confined .... | 12:42 |
| zyga | ogra_: I don't know; mvo did you cherry pick that fix from master? | 12:43 |
| mvo | zyga: what fix? | 12:43 |
| ogra_ | https://github.com/snapcore/snap-confine/commit/6cdff0d4f5c1cdd0d09a0079e8b8381956eec364 | 12:43 |
| ogra_ | how do i apply that manually if it isnt landed yet ? | 12:43 |
| mvo | ogra_: I don't think so | 12:43 |
| mvo | ogra_: yeah, you will have to manually get it | 12:44 |
| mvo | 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 |
| mvo | ogra_: 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 |
| mvo | morphis: the file tests/main/interfaces-bluez/spread.yaml has to be tests/main/interfaces-bluez/task.yaml | 12:46 |
| morphis | mvo: ah | 12:47 |
| mvo | 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 |
| ogra_ | i'll revert the branch then | 12:47 |
| mup | PR snapd#1678 opened: asserts: export DecodePublicKey <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1678> | 12:48 |
| mvo | ogra_: thanks! | 12:49 |
| ogra_ | hmm, whats the apparmor_parser line i need to re-gen the snap-confine profiile ? | 12:51 |
| zyga | timothy: hey, I've almost removed debian packaging of snap-confine | 12:51 |
| ogra_ | (i hope bind mounting works, i cant write to /etc/apparmor.d/ | 12:51 |
| ogra_ | ) | 12:51 |
| zyga | ogra_: apparmor_parser -r /etc/apparmor.d/the-file-there | 12:51 |
| ogra_ | thx | 12:51 |
| zyga | timothy: please have a look at this https://github.com/snapcore/snap-confine/pull/103 | 12:51 |
| mup | PR 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 create | 12:52 |
| ogra_ | cat: standard output: Permission denied | 12:52 |
| ogra_ | (classic)ubuntu@pi2:~$ sudo ls | 12:52 |
| ogra_ | sudo: no tty present and no askpass program specified | 12:52 |
| ogra_ | (classic)ubuntu@pi2:~$ | 12:52 |
| ogra_ | nope, no change | 12:52 |
| zyga | timothy: one thing you can see there is that it combines upstream source tarball with downstram packaging | 12:52 |
| zyga | ogra_: is /dev/pmtx mounted? | 12:52 |
| ogra_ | you mean /dev/pts :) | 12:53 |
| zyga | 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 |
| zyga | mmm, maybe, my tty subsystem know-how is rusty | 12:53 |
| * zyga checks | 12:53 | |
| zyga | ogra_: how about /dev/pts/ptmx | 12:54 |
| ogra_ | (classic)ubuntu@pi2:~$ mount|grep pts | 12: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 |
| ogra_ | ptmx | 12:54 |
| zyga | that's okay | 12:55 |
| zyga | hmmmm | 12:55 |
| ogra_ | seems that systemd-run somehow removes /dev/pts/0 | 12:55 |
| zyga | I don't know | 12:55 |
| zyga | removes? | 12:56 |
| zyga | no, wait, each snap-confine started app gets private /dev/pts | 12:56 |
| jacekn | zyga: ack, thanks | 12:56 |
| zyga | perhaps that's the actual problem? | 12:56 |
| ogra_ | zyga, well, we are running in devmode for classic | 12:57 |
| ogra_ | does that still apply ? | 12:57 |
| ogra_ | (i would guess snap-confine is completely suppressed in devmode) | 12:57 |
| zyga | ogra_: NO | 12:58 |
| zyga | no :_) | 12:58 |
| ogra_ | aha, so it isnt confinement at all | 12:58 |
| zyga | ogra_: in fact, snap confine doesn't care about devmode at all, snapd does | 12:58 |
| zyga | ogra_: snap-confine does more than just confinement: http://www.zygoon.pl/2016/08/snap-execution-environment.html | 12:58 |
| zyga | ogra_: one of the thing it does is sets up a private /dev/pts for your | 12:59 |
| zyga | your application process | 12:59 |
| zyga | perhaps for classic that is not desired | 12:59 |
| ogra_ | and that has been deeply tested in alll-snap envs i guess ? :P | 12:59 |
| zyga | 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 |
| zyga | ogra_: yes | 12:59 |
| zyga | ogra_: this code applies both on classic and in all snap | 13:00 |
| jacekn | zyga: also: https://bugs.launchpad.net/snapcraft/+bug/1613268 | 13:00 |
| mup | Bug #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 :P | 13: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 root | 13: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 here | 13:01 |
| zyga | ogra_: this code was unchanged for ages | 13: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 week | 13:03 |
| jdstrand | ogra_: hey, so, pc-kernel, pi2-kernel and dragonboard-kernel? | 13:03 |
| ogra_ | jdstrand, yes please | 13:03 |
| jdstrand | ogra_: 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 -l | 13:12 |
| ogra_ | 115 | 13:12 |
| ogra_ | URGH | 13:12 |
| ogra_ | ! | 13:12 |
| ogra_ | it never cleans up ? | 13:14 |
| zyga | ogra_: nope | 13:14 |
| ogra_ | (snap-confine that is) | 13:14 |
| zyga | ogra_: it's a known issue | 13:14 |
| zyga | ogra_: (since uubntu-core-launcher days) | 13:14 |
| ogra_ | ah, so it will ... at some point | 13:14 |
| ogra_ | that fine then | 13:14 |
| zyga | 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 |
| ogra_ | yeah, i thought switching to snap-confine would fix that already | 13:14 |
| zyga | ogra_: I have an idea with vfork but I didnt' explore it yet | 13:14 |
| zyga | ogra_: the switch was just a rename | 13:15 |
| zyga | ogra_: and evolutionary changes since | 13:15 |
| ogra_ | heh | 13:15 |
| zyga | ogra_: it wasn't a rewrite of anything | 13:15 |
| zyga | ogra_: the tmp directories you're seeing are all empty, correct/ | 13:16 |
| ogra_ | yep | 13:16 |
| ogra_ | just wasting inodes | 13:16 |
| ogra_ | (just makes debugging really hard (i.e. finding the right one) since there are so many) | 13:17 |
| mup | PR 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: ping | 13:17 |
| zyga | ogra_: that's good, I'll try my idea when snap-confine is out of SRU pipe | 13:17 |
| ogra_ | zyga, in any case the ptmx change doesnt seem to have any effect | 13:17 |
| fgimenez | joc_, hey :) | 13:18 |
| zyga | ogra_: 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/0 | 13:18 |
| ogra_ | no, not easily | 13:18 |
| zyga | ogra_: I'd like to check something about the pts error you are seeing | 13:18 |
| zyga | ogra_: gah, too bad | 13:18 |
| * zyga would love a snapd.snap with just a handful of executables | 13:18 | |
| joc_ | fgimenez: hi, i noticed you had a PR open for spread tests for serial-port interface | 13:18 |
| ogra_ | i'd have to build the package, push it to the snappy-image ppa, rebuild the image etc | 13:19 |
| cjwatson | 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 |
| mvo | 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 |
| ogra_ | mvo, cat not working, sudo not works | 13:19 |
| cjwatson | I guess you might call that subsubcommand | 13:19 |
| ogra_ | *working | 13: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 another | 13:19 |
| mvo | ogra_: works for me | 13:20 |
| ogra_ | mvo, on arm ? | 13:20 |
| mvo | ogra_: not on arm, interessting that this is arm specific, I can try tthat in a bit | 13:20 |
| ogra_ | would be good ... | 13:20 |
| fgimenez | 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 |
| cjwatson | Like "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 |
| zyga | ogra_: so specifically sudo fails? | 13:21 |
| joc_ | fgimenez: sounds good although i think i still need some reviews, https://github.com/snapcore/snapd/pull/1669 | 13:21 |
| mup | PR 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 |
| cjwatson | ogra_: Not really, there are no subcommands of "snap install" | 13:21 |
| zyga | ogra_: please report a bug on snap-confine on launchpad, I'll take care of it | 13:22 |
| zyga | ogra_: I can reproduce that anywhere | 13:22 |
| cjwatson | ogra_: I mean like "lxc image list" vs. "lxc list" | 13:22 |
| cjwatson | ogra_: Where "lxc image" is itself a thing that dispatches to its own subcommands | 13:22 |
| ogra_ | cjwatson, ah, i dont think snappd has any "multi word" commands | 13:22 |
| ogra_ | i thought you meant options | 13:22 |
| ogra_ | only toplevel with options afaik | 13:23 |
| zyga | ogra_: snapd doesn't care | 13:23 |
| zyga | ogra_: snap for bzr should just fork | 13:23 |
| zyga | :D | 13:24 |
| fgimenez | 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 |
| jdstrand | roadmr: hi! the possible review tools update is a reality in r709 :) | 13:24 |
| roadmr | jdstrand: cool! I'll put that in the pipeline | 13:24 |
| * ogra_ sighs ... classic.create on the pi2 takes ages ... | 13:25 | |
| joc_ | fgimenez: great :) | 13:25 |
| cjwatson | ogra_: Looks like go-flags supports subcommands, so it looks not too hard to do at least | 13:25 |
| ogra_ | (using the classic from the store) | 13:25 |
| jdstrand | roadmr: thank you :) | 13:25 |
| ogra_ | cjwatson, i think we use subcommands in ubuntu-device-flash (source is goget-ubuntu-touch) | 13:25 |
| ogra_ | multiple actually | 13:25 |
| mup | PR 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 |
| jdstrand | 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:26 |
| cjwatson | 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: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 ls | 13:35 |
| ogra_ | sudo: no tty present and no askpass program specified | 13:35 |
| ogra_ | (classic)ubuntu@pi2:~$ cat .bashrc | 13:35 |
| ogra_ | cat: standard output: Permission denied | 13:35 |
| zyga | re | 13:35 |
| ogra_ | and: | 13:35 |
| ogra_ | (classic)ubuntu@pi2:~$ ls /dev/pts/ | 13:35 |
| ogra_ | ptmx | 13:35 |
| ogra_ | no /dev/pts/0 | 13:35 |
| ogra_ | (so sudo isnt wrong when complaining about no tty) | 13:35 |
| mvo | ogra_: thank you, booting my pi2 now | 13:36 |
| ogra_ | this is also interesting: | 13:38 |
| ogra_ | (classic)ubuntu@pi2:~$ ls /dev/std* | 13:38 |
| ogra_ | ls: cannot access '/dev/stderr': Permission denied | 13:38 |
| ogra_ | ls: cannot access '/dev/stdin': Permission denied | 13:38 |
| ogra_ | ls: cannot access '/dev/stdout': Permission denied | 13:38 |
| zyga | ogra_: that's interesting | 13:39 |
| zyga | ogra_: ls -ld /dev /dev/stderr | 13: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/2 | 13:40 |
| ogra_ | lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stdin -> /proc/self/fd/0 | 13:40 |
| ogra_ | lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stdout -> /proc/self/fd/1 | 13:40 |
| ogra_ | (classic)ubuntu@pi2:~$ ls -ld /proc/self/fd/* | 13:40 |
| ogra_ | ls: cannot access '/proc/self/fd/255': No such file or directory | 13:40 |
| ogra_ | ls: cannot access '/proc/self/fd/3': No such file or directory | 13:40 |
| ogra_ | lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/0 -> /dev/pts/0 | 13:40 |
| ogra_ | lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/1 -> /dev/pts/0 | 13:40 |
| ogra_ | lrwx------ 1 ubuntu ubuntu 64 Aug 15 13:40 /proc/self/fd/2 -> /dev/pts/0 | 13:40 |
| ogra_ | (and /dev/pts/0 is missing, like i said above) | 13:41 |
| zyga | aaaah | 13:42 |
| zyga | it all makes sense | 13:42 |
| zyga | 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:42 |
| ogra_ | ok | 13:43 |
| zyga | ogra_: but I worry this might be something we have to ack with jdstrand first | 13:43 |
| mvo | ogra_: on my pi2 (fresh image) http://paste.ubuntu.com/23058387/ - what do I need to do to trigger the issue | 13:43 |
| zyga | jdstrand: later on when you have time | 13:43 |
| ogra_ | mvo, hmm | 13:44 |
| ogra_ | mvo, i upgraded my image to rev 249 | 13:44 |
| mvo | ogra_: I'm on r249 as well | 13:45 |
| ogra_ | weird | 13:45 |
| mvo | ogra_: via a serial port though, how do you access it? | 13:45 |
| ogra_ | ssh | 13:45 |
| * mvo looks | 13:45 | |
| ogra_ | let me try serial | 13:45 |
| jdstrand | ogra_: did you see what docker did to work around this? | 13:45 |
| ogra_ | mvo, WOAH ! | 13:46 |
| ogra_ | ubuntu@pi2:~$ sudo classic.shell | 13:46 |
| ogra_ | (classic)ubuntu@pi2:~$ sudo ls | 13:46 |
| ogra_ | [sudo] password for ubuntu: | 13:46 |
| ogra_ | so it is ssh induced somehow | 13:46 |
| mvo | ogra_: aha, but I see the same issue with ssh | 13:46 |
| mvo | ogra_: thanks, that was the missing piece | 13:46 |
| ogra_ | any idea what it actualyl is ? | 13:46 |
| zyga | hmmm | 13:46 |
| mvo | ogra_: yes, there is a open bug | 13:47 |
| zyga | wkw | 13:47 |
| zyga | lw | 13:47 |
| zyga | wow, curious indeed | 13:47 |
| jdstrand | you're talking about bug #1611493 correct? | 13:47 |
| mup | Bug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493> | 13:47 |
| mvo | jdstrand: yes | 13:47 |
| mvo | jdstrand: thats the one | 13:47 |
| jdstrand | "The work-around identified there (use "script -qc <cmd> /dev/null") works in snaps too." | 13:47 |
| mvo | 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 |
| jdstrand | https://github.com/lxc/lxc/issues/554#issuecomment-238694912 | 13: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 |
| zyga | mvo: the page talks about bind mountint /dev/console | 13:48 |
| zyga | *mounting | 13:48 |
| mvo | jdstrand: oh, sweet | 13:48 |
| zyga | as a workaround | 13:49 |
| ogra_ | jdstrand, well, that nests ttys | 13:49 |
| jdstrand | it's a workaround | 13:49 |
| ogra_ | extremely ugly | 13:49 |
| mvo | jdstrand: we can check the fix in our image ppa | 13:49 |
| jdstrand | the fix is in glibc aiui | 13:49 |
| ogra_ | and forces you in classic.shell to log out twice | 13:49 |
| * ogra_ tried the script hack already and indeed it works ... | 13:50 | |
| jdstrand | I suspect an openpty() would work | 13:50 |
| mvo | yeah, I think we want the glibc fix | 13:50 |
| jdstrand | but this is an area I'm not super versed in | 13:50 |
| ogra_ | i still dont get why ssh causes it though | 13:50 |
| ogra_ | but iit works fine oon native ttys | 13:50 |
| * ogra_ has the slight feeling thats not the same as the above bug | 13:51 | |
| mvo | ogra_: native are real ttys | 13:51 |
| ogra_ | oh, ok | 13:51 |
| mvo | ogra_: if you look at stdout its pointing to /dev/ttyAMA0 | 13:51 |
| ogra_ | yeah, got it | 13:51 |
| mvo | jdstrand: 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_ | hah | 13:52 |
| ogra_ | mvo, how much will iinfinity hate you should be the question | 13:52 |
| jdstrand | I 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 #1611493 | 13:53 |
| mup | Bug #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 |
| jdstrand | hence the quotes | 13:54 |
| mvo | ogra_: the "once ... " caveat is kind of important here ;) | 13:54 |
| ogra_ | heh, yeah, indeed | 13:54 |
| ogra_ | well, long term stable should not use PPAs at alll | 13:54 |
| ogra_ | thats at least my plan | 13:54 |
| mvo | happy to hold the horses for now, but I'm keen to get this fixed, we hit it in other contextes too | 13:55 |
| ogra_ | but there are still many SRUs in the way first | 13:55 |
| mvo | +1 | 13:55 |
| ogra_ | (nothing for RTM anyway ... but for GA) | 13:55 |
| mvo | I 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 issue | 13:55 |
| jdstrand | tyhicks: 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 on | 13:55 |
| ogra_ | mvo, just go ahead then | 13: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 duplication | 13:57 |
| ogra_ | at least by what zyga said above | 13:57 |
| jdstrand | tyhicks: 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 |
| mvo | ogra_: 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 it | 13:59 |
| camako | Can I get more reviews on this one? https://github.com/ubuntu/snappy-playpen/pull/205 | 14:02 |
| mup | PR ubuntu/snappy-playpen#205: Mesa demos <Created by camako> <https://github.com/ubuntu/snappy-playpen/pull/205> | 14:02 |
| mup | PR snapd#1678 closed: asserts: export DecodePublicKey <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1678> | 14:09 |
| mup | PR 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 | |
| mup | PR 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 PR | 14: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 |
| mvo | ogra_: I did? let me check | 14:51 |
| ogra_ | mvo, yeah ... https://github.com/snapcore/classic-snap/blob/master/bin/create has all my code already | 14:53 |
| mvo | ogra_: hm, that was a mistake, yeah, create has the unsquashfs bits in there already | 14:53 |
| mvo | ogra_: hm, I can fix that, I would like to have a proper history | 14:53 |
| ogra_ | and i was thinking i'm going crazy | 14:53 |
| mvo | ogra_: give me a minute | 14:53 |
| ogra_ | (or am to dumb for github (which i am probably anyway ... )) | 14:54 |
| mvo | ogra_: embrace it, git is great | 14:54 |
| mvo | ogra_: (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 ... :P | 14:55 |
| mvo | ogra_: please try now | 14:55 |
| ogra_ | i can only view the former PR | 14:58 |
| ogra_ | i guess i need to delete my fork and re-fork | 14:59 |
| ogra_ | it whines about "snapcore:master and ogra1:master are entirely different commit histories. " | 15:00 |
| * ogra_ starts over | 15:00 | |
| mup | PR 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/2 | 15:09 |
| mup | PR 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 |
| zyga | ogra_: I would recommend using longer commit messages, with newlines, so that tig/git log is easier to parse | 15: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 now | 15:11 |
| zyga | ogra_: you can still edit that, just give it a try | 15:11 |
| zyga | ogra_: I know tools can be frustrating | 15:12 |
| ogra_ | zyga, i am wasting nearly 2h already for 5 lines of code, i wont touch that stuff anymore for today, really | 15:12 |
| zyga | ogra_: just a friendly note, don't take it personally | 15:12 |
| ogra_ | LP never frustrated me like that | 15: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 |
| zyga | ogra_: what did you try to do? | 15:13 |
| ogra_ | :) | 15:13 |
| ogra_ | zyga, i tried to do a PR of code that was accidentially already merged | 15:13 |
| ogra_ | and then messed up my branch completely a few times during the attempts | 15:14 |
| dragly | zyga: 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 |
| mup | PR 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 |
| zyga | dragly: woot, that's great | 15:20 |
| zyga | dragly: 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 |
| mup | PR 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/snapd | 15:23 | |
| ogra_ | (since you completely wipe whatever was in /etc/sudoers by default) | 15:24 |
| mvo | ogra_: hm, that is a bit terrible indeed | 15:27 |
| ogra_ | yeah | 15:27 |
| mvo | ogra_: 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 run | 15: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 forgot | 15:28 |
| ogra_ | mvo, well, at least you would catch that on snapd updates ... | 15:28 |
| mvo | ogra_: true | 15:28 |
| ogra_ | defintely no ideal either | 15:28 |
| mvo | ogra_: 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 so | 15:31 |
| ogra_ | *sysadmins | 15:31 |
| ogra_ | but these guys will whine ... | 15:31 |
| dragly | zyga: A molecular dynamics visualization software named Atomify LAMMPS: https://github.com/ComputationalPhysics/atomify-lammps/releases/tag/2.0.2 | 15:31 |
| zyga | ogra_: I'm aware of per-distro secure path | 15:31 |
| zyga | dragly: awesome! | 15:32 |
| ogra_ | ("i installed snapd and suddenly all my users can access /usr/local via sudo which i prevented !!!") | 15:32 |
| zyga | ogra_: I think we have to do something more fine grained there, I didn't give it much though though | 15:33 |
| ogra_ | zyga, yeah ... the prob is that it isnt designed for fine grained :) | 15:33 |
| ogra_ | on putrpose apparently | 15:34 |
| ogra_ | -t | 15:34 |
| mvo | ogra_: 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 this | 15:34 |
| ogra_ | mvo, yeah ... go with a low number for now and lets see if anykone screames | 15:34 |
| ogra_ | -e | 15:34 |
| ogra_ | i assume we wont convince sudo upstream to make the path extensible/appendable | 15:35 |
| mvo | ogra_: I guess the alternative is to make our sudo package include /snap/bin | 15:35 |
| ogra_ | probably there would be some complex way through pam though | 15:36 |
| ogra_ | mvo, yeah, thats the other option | 15:36 |
| mvo | if 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.d | 15:37 |
| ogra_ | haha | 15:37 |
| ogra_ | clever move :) | 15:37 |
| * zyga mutters something about /usr/lib vs /etc | 15:41 | |
| mhall119 | sergiusens: is there any way to make a cleanbuild lxc container persistent? | 15:50 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | mvo (cc tyhicks): you are adjusting sudo's secure_path via something in /etc/sudoers.d? | 15:51 |
| mvo | jdstrand, tyhicks: not yet, but I pushed a PR for it https://github.com/snapcore/snapd/pull/1679 | 15:53 |
| mup | PR snapd#1679: debian: add /snap/bin to the secure-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/1679> | 15:53 |
| mvo | jdstrand, tyhicks: happy to hear alternative ideas how we can have /snap/bin in the PATH when sudo is used | 15:54 |
| jdstrand | I don't think I like that | 15:54 |
| mvo | jdstrand: having /snap/bin in the sudo path at all? | 15:54 |
| mvo | jdstrand: or just this way of adding it? | 15:55 |
| jdstrand | because 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, etc | 15:55 |
| jdstrand | for 15.04 we used ubuntu-core-config to adjust /etc/sudoers to include it last in the path | 15:55 |
| jdstrand | the PR also doesn't consider that other distros may not set secure_path or that they may have a different one than Ubuntu | 15:56 |
| jdstrand | mvo: 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 Ubuntu | 15:57 |
| jdstrand | tyhicks: thoughts? ^ | 15:57 |
| mvo | jdstrand: ok, fair enough, I will paste this into the PR and close it, I'm fine with modifying sudo | 15:58 |
| jdstrand | tyhicks: (background, upstream doesn't have support for appending to secure_path) | 15:58 |
| mup | PR 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 |
| tyhicks | jdstrand: I agree - modifying /etc/sudoers at the distro level is the better solution since the PR isn't appropriate for other distros | 15:59 |
| mhall119 | zyga: 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 |
| tyhicks | jdstrand, 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 list | 16:02 |
| jdstrand | tyhicks: thanks | 16:02 |
| dragly | zyga: Is it possible to install snap-packages without sudo? Or will it be in the future? | 16:02 |
| mhall119 | dragly: if you use "snap login" you can then install without sudo | 16:02 |
| jdstrand | tyhicks: oh, and thanks for that too :) | 16:02 |
| * jdstrand wonders if there is an openpty() option that could be done | 16:03 | |
| dragly | mhall119: Cool! I'll try that. | 16:03 |
| tyhicks | they're rapidly iterating on the correct change - I wouldn't be surprised if they settle on something this week | 16:04 |
| jdstrand | ah, cool | 16:04 |
| tyhicks | there are still open questions and no updated patch for https://sourceware.org/ml/libc-alpha/2016-08/msg00333.html | 16:07 |
| dragly | mhall119: That worked flawlessly. Thanks! | 16:11 |
| mhall119 | happy to help :) | 16:17 |
| dobey | snappy doesn't use debsig-verify right? | 16:24 |
| kyrofa | dobey, indeed, that was 15.04 | 16:37 |
| ahoneybun | jdstrand: it's not a security thing I think | 16:44 |
| ahoneybun | I added python-dbus to stage and still the same error | 16:44 |
| ahoneybun | oh noes soee | 16:45 |
| soee | ahoneybun: sup ? :) | 16:45 |
| ahoneybun | mhall119: still hanging around? | 16:51 |
| ahoneybun | http://pastebin.ubuntu.com/23059037/ | AttributeError: 'NoneType' object has no attribute 'get_bus' | 16:53 |
| rtsisyk | hi | 17:12 |
| === allesz_ is now known as allessz | ||
| rtsisyk | I'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 |
| rtsisyk | snapcraft strips .git folder from the source tree, so my cmake scripts fails to retrieve version for git | 17:16 |
| rtsisyk | I need to put `git describe --long --always` result to the source directory in order to build package. | 17:17 |
| rtsisyk | any ideas? | 17:26 |
| rtsisyk | I failed to find a proper example in snappy-playground | 17:26 |
| rtsisyk | is it possible to use existing Debian package to build snappy package? | 17:28 |
| mhall119 | ahoneybun: yup | 17:31 |
| rtsisyk | ahh, there are no tags in clonned git repo! I need `git fetch --tags`. | 17:36 |
| gc_snap | Hi! Is it possible to unregister a snap from the ubuntu store? | 17:39 |
| mup | PR snapcraft#730 opened: Clarification of make plugin help text <Created by mikemccracken> <https://github.com/snapcore/snapcraft/pull/730> | 17:42 |
| ahoneybun | mhall119: worked on any snap with python? | 17:50 |
| rtsisyk | https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources.py#L164-L186 both cases don't work for me. | 17:51 |
| mhall119 | ahoneybun: yeah, hello-unity | 17:51 |
| mup | PR 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 |
| ahoneybun | mhall119: http://pastebin.ubuntu.com/23059037/ | 17:52 |
| rtsisyk | I 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 1 | 17:52 |
| ahoneybun | any thing from this? | 17:52 |
| kyrofa | rtsisyk, I'm not quite sure what you're asking here | 17:59 |
| kyrofa | Can I see your YAML? | 17:59 |
| ahoneybun | sergiusens: thanks a lot for the telegram update | 18:00 |
| rtsisyk | kyrofa: 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 |
| rtsisyk | now I can build my binary | 18:01 |
| rtsisyk | what is about init scripts? | 18:01 |
| * ahoneybun wonders if his issue is from all the "No libraries to exclude this release" lines | 18:01 | |
| kyrofa | rtsisyk, ah, okay | 18:01 |
| kyrofa | ahoneybun, are you running on yak? | 18:02 |
| rtsisyk | I have systemd .service file, is it useful for snappy? | 18:02 |
| kyrofa | rtsisyk, no, snapd will generate those based on the information you give it | 18:02 |
| ahoneybun | I am kyrofa | 18:02 |
| kyrofa | ahoneybun, yeah, bad idea | 18:02 |
| ahoneybun | well... | 18:02 |
| kyrofa | ahoneybun, 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 y | 18:03 |
| ahoneybun | well it installed ubuntu-core | 18:04 |
| ahoneybun | snaps run fine here | 18:04 |
| rtsisyk | @kyrofa: my service file have support for multi-instance and so on. | 18:04 |
| nothal | rtsisyk: No such command! | 18:04 |
| kyrofa | ahoneybun, sure, but I'm talking about building them | 18:04 |
| ahoneybun | if anything I can throw the yaml on my laptop with xenial | 18:05 |
| kyrofa | ahoneybun, snapd bundle a lot of dependencies but not all of them. Notably libc | 18:05 |
| gc_snap | I'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 |
| mhall119 | ahoneybun: are you using the desktop/gtk(2|3) part? | 18:06 |
| ahoneybun | desktop/gtk3 after | 18:06 |
| ahoneybun | added python3-dbus in stage and built | 18:06 |
| ahoneybun | still there | 18:08 |
| mhall119 | ahoneybun: my guess is you're missing a gstreamer plugin | 18:08 |
| mhall119 | ahoneybun: see https://github.com/pithos/pithos/blob/master/pithos/pithos.py#L175 | 18:08 |
| ahoneybun | yaml : http://pastebin.ubuntu.com/23059200/ | 18:09 |
| mhall119 | self.player is None on line 177, which means it's not being set properly on line 175 | 18:09 |
| ahoneybun | can't find that in packages.ubuntu.com | 18:10 |
| mhall119 | ahoneybun: try adding rygel-playbin to your stage-packages | 18:14 |
| ahoneybun | where did you get that ? | 18:16 |
| mhall119 | apt-cache search "playbin" | 18:16 |
| mhall119 | also, apt-cache depends --recurse pithos |grep -i playbin | 18:16 |
| ahoneybun | but why that package | 18:17 |
| ahoneybun | I need to know | 18:17 |
| rtsisyk | where I can find snapcraft.yml example for daemons? | 18:19 |
| mhall119 | hey, I only have edge and beta available as channels for my app in the store, how do I get stable? | 18:20 |
| kyrofa | rtsisyk, please read through this: http://snapcraft.io/create/ | 18:20 |
| kyrofa | rtsisyk, it'll walk you through apps and daemons | 18:21 |
| kyrofa | rtsisyk, but here's another example, one of the snapcraft demos: https://github.com/snapcore/snapcraft/blob/master/demos/shout/snapcraft.yaml | 18:22 |
| ahoneybun | same thing | 18:25 |
| ahoneybun | mhall119: | 18:25 |
| rtsisyk | thanks. My daemon needs a config file provided by user to start... | 18:26 |
| powersj | mhall119, does your app run in confinement mode strict? | 18:28 |
| mhall119 | ahoneybun: in that cause, it could be that gstreamer needs some setting to tell it where to find it | 18:28 |
| powersj | or still require devmode? I believe if devmode is required you are limited to beta and edge | 18:28 |
| mhall119 | powersj: devmode, is that the cause? | 18:29 |
| mhall119 | something should tell the developer this, it's not obvious | 18:29 |
| powersj | mhall119, yeah see 2nd paragraph under Developer mode here: http://snapcraft.io/docs/core/usage | 18:29 |
| mhall119 | I meant something in the sore | 18:30 |
| mhall119 | store | 18: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 staring | 18:30 |
| renato__ | this is the full log, http://paste.ubuntu.com/23059185/ | 18:31 |
| renato__ | sergiusens, ^^^ any idea about that? | 18:32 |
| mhall119 | ok, it's on the upload form too, maybe I'm just being thick | 18:32 |
| kyrofa | mhall119, yeah it does, right next the channel selection dialog | 18:34 |
| kyrofa | Ah, yeah you saw that, sorry | 18:34 |
| mhall119 | kyrofa: it doesn't say it here though: https://myapps.developer.ubuntu.com/dev/click-apps/5719/upload/19776/edit/ | 18:35 |
| mhall119 | which is where I was looking and thinking "where is stable?" | 18:35 |
| kyrofa | mhall119, ah, then yes, I agree! | 18:35 |
| kyrofa | mhall119, mention it to the store folks | 18:36 |
| kyrofa | renato__, 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 |
| kyrofa | renato__, were you running the apps with sudo, or as a normal user? | 18:37 |
| wililupy | in my snapcraft.yaml, if I need a specific branch from a git, how would I do that? | 18:37 |
| mhall119 | kyrofa: who are the store folks these days? | 18:37 |
| mhall119 | it used to be I just complained to beuno a lot | 18:37 |
| mhall119 | :) | 18:37 |
| kyrofa | mhall119, nessita is always my go-to. She knows all | 18:37 |
| nessita | heh | 18:37 |
| kyrofa | She can at least get you to where you need to go :) | 18:37 |
| nessita | mhall119, hi! how can I help? | 18:38 |
| nessita | kyrofa, and thanks for all those nice words! | 18:38 |
| renato__ | kyrofa, yes it was running nice as normal snaps apps. | 18:38 |
| mhall119 | nessita: 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 snap | 18:38 |
| nessita | mhall119, would you please create a bug so we can track the request there? | 18:39 |
| mhall119 | nessita: lp:software-center-agent still? | 18:39 |
| kyrofa | renato__, like, you `sudo su -` then run the apps? | 18:39 |
| kyrofa | renato__, or you ran them as a normal, unprivileged user? | 18:39 |
| nessita | mhall119, yes, thank you | 18:39 |
| renato__ | kyrofa, I run the app without sudo. But install it with sudo | 18:40 |
| rtsisyk | can i use svg for "icon:"? | 18:40 |
| kyrofa | Of course | 18:40 |
| kyrofa | rtsisyk, you can! svg or png | 18:40 |
| rtsisyk | great! | 18:40 |
| rtsisyk | how to check icon for packaged snap file? | 18:40 |
| kyrofa | renato__, okay. And it seems you're using SNAP_USER_DATA? | 18:40 |
| kyrofa | rtsisyk, I don't quite understand what you're asking | 18:41 |
| renato__ | kyrofa, I am not sure what this SNAP_USER_DATA is :D | 18:41 |
| kyrofa | renato__, ah, then just $HOME perhaps | 18:41 |
| renato__ | kyrofa, this is my snapcraft file: http://paste.ubuntu.com/23059245/ | 18:42 |
| kyrofa | renato__, a big difference between apps and services is that apps run as whoever ran them, and services run as root | 18:42 |
| renato__ | kyrofa, humm this can be the problem, I need the service running on user session | 18:42 |
| kyrofa | Which means the user-specific data directory (SNAP_USER_DATA) is in /root/snap/<snap>/<revision> | 18:42 |
| kyrofa | Ah indeed | 18:42 |
| renato__ | kyrofa, I need to connect with dbus session | 18:42 |
| kyrofa | renato__, snapd doesn't currently have a concept of user services | 18:43 |
| renato__ | kyrofa, ok this is the problem then | 18:43 |
| kyrofa | renato__, definitely | 18:43 |
| rtsisyk | DEPRECATED: 'license' defined in snapcraft.yaml | 18:44 |
| kyrofa | niemeyer, I seem to remember a conversation about user services. Did anything ever come of that conversation? | 18:44 |
| mhall119 | kyrofa: nessita: how can I publish both an amd64 and i386 snap? | 18:46 |
| rtsisyk | https://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 |
| rtsisyk | I can't register proper name | 18:50 |
| mup | PR snapd#1667 closed: many: implement snapctl command <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1667> | 19:23 |
| mup | Bug #1613420 opened: no way to run daemons on user session <Snappy:New> <https://launchpad.net/bugs/1613420> | 19:42 |
| niemeyer | kyrofa: No, not much | 20:03 |
| mup | PR snapcraft#731 opened: Factor parts config into snapcraft/internal/parts.py <Created by josepht> <https://github.com/snapcore/snapcraft/pull/731> | 20:36 |
| dobey | what's the equivalent in snap, of "click info $package" ? | 21:14 |
| kgunn | kyrofa: ping | 21:57 |
| kyrofa | kgunn, pong, how are you? | 21:58 |
| kgunn | kyrofa: good man how are you | 21:58 |
| kyrofa | kgunn, I'm doing well! | 21:58 |
| kgunn | kyrofa: 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 archive | 21:59 |
| kgunn | can i just leave nil | 21:59 |
| kgunn | (nil plugin) | 21:59 |
| kyrofa | kgunn, just using stage-packages? | 21:59 |
| kgunn | and then list all the pkgs in stage? | 21:59 |
| kgunn | yeah..that's the thinking | 21:59 |
| kyrofa | kgunn, sure, but there are limitations there, e.g. postinst scripts aren't run etc. | 21:59 |
| kgunn | kyrofa: oh yeah...i know i'll have to add a wrapper scriptfor launch | 22:00 |
| kyrofa | kgunn, packages in the archive may also be looking for files in e.g. /etc/ that are now in $SNAP/etc/, and so on | 22:00 |
| kgunn | ah, but yeah, that's a good point | 22:00 |
| kyrofa | kgunn, 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 good | 22:00 |
| kgunn | kyrofa: k i'll prolly just give it a go and deal with pathing weirdness as and when i hit it | 22:01 |
| kyrofa | Yeah it's an easy path to try anyway as long as the packages don't make heavy use of postinst | 22:01 |
| kyrofa | kgunn, e.g. don't even try doing apache | 22:02 |
| kgunn | hehe | 22:02 |
| kgunn | kyrofa: sounds like experience ? | 22:02 |
| kyrofa | :P | 22:03 |
| kyrofa | Yeah that was my initial foray into snapping. Should have started with something easier | 22:03 |
| kgunn | lol | 22:03 |
| kgunn | i figure u8 will be a mess | 22:03 |
| kgunn | should be fun | 22:03 |
| kyrofa | Yeah you'll be even more familiar with it than you are now! | 22:04 |
| kgunn | kyrofa: thanks for the advice...dropping for a bit | 22:04 |
| kyrofa | kgunn, any time, have a good one! | 22:04 |
| mup | PR 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!