/srv/irclogs.ubuntu.com/2016/10/06/#snappy.txt

jdstrandkyrofa: note that process-control can be used for setpriority until seccomp arg filtering policy is available00:02
mupPR snapd#2105 opened: snapstate: only import defaults from gadget on install <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2105>02:34
blrfor a cmake snap, is there any way I can specify which directory the source lives in within the repo I have set to 'source'?02:47
blroh nvm, found it 'source-subdir' :)02:48
dholbachgood morning06:32
didrocksgood morning dholbach06:36
pbekGood morning, dholbach ^_^06:36
dholbachsalut didrocks, hey pbek06:37
morphis__zyga: ping07:10
aragood morning zyga07:45
arazyga, any updates on snap-confine 1.0.43 in xenial-proposed? is that happening?07:45
arapedronis, morning! found the issue why it wasn't connecting to staging. The env variable is SNAPPY_USE_STAGING_STORE (rather than USE_STAGING_STORE only, that we talked yesterday)07:53
arapedronis, it works that way, thanks a lot for your help yesterday!07:53
pedronisara: yes, I think I pinged late about that, sorry I recalled from memory and memory had dropped the prefix08:09
mupPR snapd#2106 opened: tests: exclude all-snap arm systems for the snap-connect test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2106>08:13
=== ant_ is now known as Guest48995
Chipacaogra_, o/08:39
zygamorphis__: hey, I'm working on some more fixes, I'll be pushing code at each airport I'm at today, I'll write an update in the evening before I depart on the final connection08:46
morphis__zyga: awesome! thanks a lot!08:46
zygaara: I don't know, if you can please work with jdstrand to get this into yakkety and sru https://github.com/snapcore/snap-confine/releases/tag/1.0.4308:46
zygaara: no packaging changes required08:46
zygamorphis__: as a precaution I added support for offline testing so I'm good on the (long) journey ;)08:47
morphis__zyga: ok08:58
Chipacasilly core-m going to sleep in funky ways09:18
Chipacaogra_, i got the dragonboard working wiht the nexdock :-)09:18
Chipacaogra_, do i get a putty medal09:19
mupPR snapcraft#857 opened: Document the grade option <Created by dholbach> <https://github.com/snapcore/snapcraft/pull/857>09:43
ogra_Chipaca, heh09:44
mupPR snapd#2103 closed: store: send correct JSON type of string for expected payment amount <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2103>09:50
mupPR snapd#2107 opened: many: add payment-declined error kind <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2107>09:57
mvomwhudson: if you or cyphermox could merge https://launchpadlibrarian.net/288530592/subiquity_0.0.19~xenial_0.0.19~xenial+mvo1.diff.gz that would be great10:18
mupPR snapcraft#855 closed: tools: script to talk to the staging servers <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/855>10:31
sergiusensdholbach hey hey; are you a bash completion master? I wish you are and can look into allowing file completion, it drives me nuts :-P10:40
dholbachsergiusens, I'm not :-/11:00
dholbachsergiusens, but I can see if I can find something11:01
sergiusensdholbach heh, cwayne did the original contrib, we should pester him ;-)11:11
cwaynesergiusens: uh oh what'd I do11:12
sergiusenscwayne bash completion :-)11:15
sergiusensyou are up early ;-)11:15
cwaynesergiusens: :)11:17
cwaynei can take a look at expanding it, sure11:17
cwaynewhat specifically are you lookin for?11:18
sergiusenscwayne we have a bug report from dholbach LP: #163092211:19
mupBug #1630922: Bash completion for "push" is incomplete <Snapcraft:New> <https://launchpad.net/bugs/1630922>11:19
sergiusenscwayne but basically anything that takes a file as an argument has me banging the tab key to no avail :-)11:20
ogra_get a new tab key :P11:20
ppisatiogra_: where can i download pi2-kernel_15.snap? i need the physical file to change some of its content (and regenerate an image)11:21
ogra_ppisati, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel11:22
ppisatiogra_: ta11:22
ogra_(click on "Successfully built")11:22
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
mupPR # closed: snapd#2033, snapd#2058, snapd#2065, snapd#2072, snapd#2083, snapd#2087, snapd#2091, snapd#2096, snapd#2104, snapd#2105, snapd#2106, snapd#210712:12
jdstrandara (cc zyga): do you want me to upload 1.0.43 to yakkety and xenial?12:13
arajdstrand, please, apparently .42 (in xenial-proposed) had a regression, so it is never going to be go to -updates12:14
jdstrandI see12:15
jdstrandara: ok, I'll do that now and ping you12:16
arajdstrand, thanks!12:16
mupBug #1630976 opened: Incomplete home directory mapping <Snappy:New> <https://launchpad.net/bugs/1630976>12:20
mupPR # opened: snapd#2033, snapd#2058, snapd#2065, snapd#2072, snapd#2083, snapd#2087, snapd#2091, snapd#2096, snapd#2104, snapd#2105, snapd#2106, snapd#210712:25
jdstrandara: do you have the bug for the regression?12:29
arajdstrand, let me check, zyga mentioned yesterday on this same channel, let me check the backlog12:29
arajdstrand, https://bugs.launchpad.net/snap-confine/+bug/163047912:33
mupBug #1630479: PATH is not set after namespace is initialized <Snappy Launcher:Fix Committed by zyga> <snap-confine (Ubuntu):In Progress by zyga> <https://launchpad.net/bugs/1630479>12:33
jdstrandzyga: can you make sure this is in 1.0.44: http://paste.ubuntu.com/23284317/12:34
jdstrandara: thanks!12:34
jdstrandzyga: also http://paste.ubuntu.com/23284321/12:35
zygajdstrand: sure12:37
zygajdstrand: re, .43, yes, let's please get it into yakkety and xenial12:37
zygajdstrand: will mount options=(ro rbind) /snap/{,ubuntu-}core/*/var/lib/** -> /var/lib/**,12:41
zygajdstrand: will that cover /snap/core/current//var/lib/logrotate -> /var/lib/logrotate12:42
zygajdstrand: or do I need some /**/ to cover directories?12:42
stubWhat do I do here? https://pastebin.canonical.com/167232/ . It seems the python3 pulled in by the python plugin does not patch the python3 pulled in as a stage package in another part (that embeds a Python interpreter)12:46
jdstrandzyga: /snap/{,ubuntu-}core/*/var/lib/** would cover it. is ../** needed though? can you use /snap/{,ubuntu-}core/*/var/lib/logrotate/ -> /var/lib/logrotate/ instead?12:49
mupPR snapd#2108 opened: devicestate: merge overlord/boot into devicestate <Created by mvo5> <https://github.com/snapcore/snapd/pull/2108>12:50
zygawell , we don't know which directories there are there12:51
zygawe're seeing a failure in autopkgtests12:51
zyga cannot bind mount /snap/core/current//var/lib/logrotate -> /var/lib/logrotate with flags 0x85007. errmsg: Permission denied12:51
zygano apparmor denial log though, we'd have to reproduce it now12:51
zygaI was wondering if apparmor changed in any way12:51
zygathe mount happens with the following flags MS_RDONLY | MS_REC | MS_SLAVE | MS_NODEV | MS_NOSUID12:52
zygabut AFAIK apparmor doesn't model all of them12:52
jdstrandzyga: re don't know> this is an old conversation. is it truly dynamic now and we don't know or is it just to ease future maintenance? if the former, we need a glob rule, if the later, let's continue adding more specific rules12:55
jdstrandzyga: you probably need: /snap/{,ubuntu-}core/*/var/lib/*/ -> /var/lib/*/12:56
stubhuh. The only difference is munged shebang lines. I think I saw the python plugin messing around with shebangs12:56
zygajdstrand: ack, I'll try to reproduce this and fix it when I'm in korea with better network12:56
jdstrandzyga: ie, the trailing '/' (and you don't need **/, just */ iirc the mirrored /var/lib code12:57
jdstrand)12:57
zygathanks!12:58
zygathis doesn't explain why adt fails but at least I have more knowledge12:58
jdstrandzyga: looking at that source mount (/snap/{,ubuntu-}core/*/var/lib/*/), we should be able to enumerate those since we know what is in the core snap. however, would we list everything in /var/lib or would we skip stuff? iirc, there are things we would skip, so a more exact match would be best (though I'd be ok with a glob rule with deny rules for what we wouldn't mount from /snap/{,ubuntu-}core/*/var/lib/*/)13:00
zygajdstrand: jdstrand overdue gift from the plane13:00
zygageeez net is slow from the phone13:01
zygajdstrand: https://github.com/snapcore/snap-confine/pull/16613:01
mupPR snap-confine#166: Allow running qemu spread tests offline <Created by zyga> <https://github.com/snapcore/snap-confine/pull/166>13:01
jdstrandwoo!13:01
zygaIll merge things on the plane13:01
zygajust adding remotes13:01
mupBug #1616605 changed: Cannot open files from NFS drive mounted in /media <snapd-interface> <Snappy:Fix Released by ssweeny> <https://launchpad.net/bugs/1616605>13:02
didrocksjdstrand: hey! I see that to be able to run the "ping" command, we need one of those interfaces: firewall-control, network-control, network-observe13:03
didrocksjdstrand: so, it means, there is no interface that autoconnects to enable pinging a remote server?13:03
didrocks(I guess there are security implications…)13:03
mupPR snapd#2033 closed: many: move firstboot code into the snapd daemon <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2033>13:08
jdstranddidrocks: that's correct. it has to do with the fact that it is setuid and what that would mean with 'safe' policy13:08
jdstranddidrocks: however, there are several things here to consider: 1) snaps can test for connectivity using other means that don't need setuid (eg, perform a GET / on http), 2) recent kernels allow ping to be used without setuid, so the snap could ship that ping, 3) snap declarations will allow autoconnecting interfaces after the snap is approved, d) I *might* be able to make something work now that the seccomp arg filtering feature landed13:11
didrocksjdstrand: actually, I'm just trying to ship some toolbox for health check that consul would use. ping utility is one of them. Is there any ping tool that you know for 2)?13:12
didrocksjdstrand: also, I just tried to network-observe + connect the socket, I'm still getting ping: icmp open socket: Operation not permitted13:13
didrocks(but nothing in scanlogs now)13:13
didrocks(and nothing in syslogs)13:13
jdstranddidrocks: you mean s/socket/interface/?13:13
didrocksinterface, yeah, sorry13:14
didrocks:network-observe                   consul13:14
jdstrandtyhicks: what is the status of setuid-less ping?13:16
jdstranddidrocks: note, tyhicks will be online in a bit13:16
didrocksjdstrand: that would be great as a simple utility for use with health checks ;)13:16
didrockshowever, in the fact that there is no log in syslog and that error ^ I'm puzzled13:17
jdstranddidrocks: there was this: http://tinyurl.com/h6obc5g13:17
jdstranddidrocks: what ping is it using? the system ping or its own ping? if its own ping, does it work with sudo?13:18
didrocksjdstrand: it's coming from a stage-package I took (can use another one if needed): iputils-ping13:19
didrockslet me try with sudo13:19
didrocksyep, works with sudo13:19
jdstranddidrocks: the problem with that ping is it requires kernel support. I forget the details of the earliest kernels, so an old 3.10 kernel (for example) might not work with this ping13:19
didrocks$ uname -a13:19
didrocksLinux n1 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux13:19
didrocksnot that old :)13:19
jdstranddidrocks: right, so with stage-packages, the setuid bits are (correctly) stripped13:19
didrocksah, that's the reason why…13:20
didrocksok, making sense then13:20
jdstranddidrocks: but the ping in stage-packages doesn't have the patch for setuid-lessness13:20
didrocksso, I guess the setuid-less ping is the only way13:20
jdstranddidrocks: well, use /bin/ping from the core snap instead of stage-packages13:20
jdstranddidrocks: that will work with network-observe13:20
didrocksok, let me give it try!13:21
didrocksjdstrand: indeed, works perfectly with that + network-observe13:21
jdstrandit might be fun to have a part or something with the patched ping. iirc, the patch to ping went upstream and it was accepted. that patch just didn't make it into Debian/Ubuntu yet. tyhicks would need to confirm13:22
didrocksthanks a lot, that would do it for now :)13:22
didrocksoh ok13:22
didrocksyeah, I'm creating some sort of general "utility" part/content-interface13:22
didrocksto be used as health check toolbox13:22
jdstranddidrocks: compiling upstream ping from source might be the way to go then if connecting network-observe is onerous13:23
didrocksjdstrand: yeah, sounds like it. do you have the link for the official upstream source (I find some github and such…), and debian/copyright doesn't point to a working ftp13:25
jdstranddidrocks: fyi, I added exploring 'd' (hehe, meant '4' in my list) to the card on implementing seccomp arg filtering policy. that card is down a ways cause of various critical cards13:25
jdstranddidrocks: I'll defer to tyhicks there. iirc, he submitted the patch13:26
didrocksoki :)13:26
didrocksjdstrand: yeah, no worry, thanks for helping, at least, I have options and I am unblocked :)13:26
jdstrandcool13:27
mbenzogra: I am trying to port minicom from 15.04 to UC16 and need to access tty devices, isn't there a serial-port plug?13:41
ogra_mbenz, i think there is ....https://github.com/snapcore/snapd/blob/master/docs/interfaces.md look for serial13:42
ogra_needs the user to manually connect though13:42
didrocksogra_: our discussion was that it's not listed via snap interfaces though, even being in the code13:43
didrocksis that ubuntu-core doesn't provide the slot?13:43
ogra_didrocks, hmm, thats a zyga question i fear13:44
mbenzogra: I will look at doc but some background on what I have tried. I added the plug in yaml and install but see '-' listed as slot and trying to connect gives a failure unlike using modem-manager which works but doesn't have access to /dev/ttySx13:44
ogra_righ, smells like something is missing here13:45
ogra_as didrocks said13:45
mbenzshould I work with zyga or log a bug?13:46
ogra_well, perhaps it is known, i guess zyga had enough pings from us to notice the discussion once he checks IRC again ;)13:47
ogra_wait for him ... then log a bug if he thinks you should13:47
mbenzok13:47
mbenzfor now I will just run in devmode and debug lock file and config file locations13:48
jdstrandtyhicks: as it happens, I am preparing a snap-confine upload and so I can remove the owner check from '@{PROC}/*/mountinfo r,' if that would help things. please advise14:00
jdstrandtyhicks: oh, I see you said to drop it in comment #414:00
tyhicksjdstrand: thanks! could you also add the rule in comment #5?14:06
tyhicksjdstrand: @{PROC}/[0-9]*/attr/current w,14:06
tyhicksjdstrand, didrocks: re setuid-less ping, the patches landed in upstream iputils but we don't yet have a new enough iputils in any of our releases14:20
tyhicksjdstrand, didrocks: it isn't as simple as that, though14:20
tyhicksjdstrand, didrocks: setuid-less ping doesn't have full functionality so there's decisions to be made about whether that loss of functionality is ok, if we need to have multiple packages (one for setuid, one for no setuid), etc.14:21
tyhicksjdstrand, didrocks: also, you can't ship your own setuid-less ping in a snap until Ubuntu opens up the net.ipv4.ping_group_range sysctl to a range that includes our normal user's gid14:25
jdstrandtyhicks: hmm, so a snap that build iputils from upstream still wouldn't work cause of the sysctl, which we could allow setting, but probably in network-control, a non-auto-connected interface14:28
jdstrandtyhicks: yes, already done. about to upload this: http://paste.ubuntu.com/23284740/14:29
jdstrandtyhicks: fyi, https://github.com/snapcore/snap-confine/pull/16714:29
mupPR snap-confine#167: drop 'owner' check on mountinfo and allow write to @{PROC}/[0-9]*/attr/current <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/167>14:29
didrockstyhicks: hum, ok, so I'm going with the ubuntu-core ping version now, with the correct interface14:29
jdstrandtyhicks: if you +1 that PR, I'll commit it14:30
tyhicksjdstrand: I've +1'ed14:31
tyhicksdidrocks: yeah, that's your best option right now14:31
tyhicksjdstrand: we wouldn't want to allow a snap to set the sysctl, we'd want to set it ourselves14:32
tyhicksjdstrand: the least risky option would be set it at the distro level but continue to ship the setuid ping14:32
tyhicksjdstrand: that would allow snaps to ship their own setuid-less ping14:33
jdstrandtyhicks: technically, it could be at the core snap level14:33
tyhicksjdstrand: yeah, it could be14:34
jdstrandara (cc zyga): uploaded snap-confine 1.0.43-0ubuntu1 to yakkety just now. aiui, autopkgtests have a long queue due to glibc upload. I'll work on xenial now14:39
arajdstrand, thanks!14:39
mupPR snapd#2105 closed: snapstate: only import defaults from gadget on install <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2105>14:44
mupPR snapd#2109 opened: tests: update tests now that we do not have snapd.boot-ok anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/2109>15:09
didrockshum, the consul snap is already taken, I think it's you elopio?15:09
didrockselopio: I have a working version of it (which does a little bit than --help or local dev agent) and want to upload it to the store, do you mind add me to collaborators if it's really you? :)15:10
jdstrandara (cc zyga and tyhicks): ok, snap-confine 1.0.43 with https://github.com/snapcore/snap-confine/pull/167 uploaded to both yakkety and xenial-proposed. yakkety is building, xenial-proposed needs a member of the sru team and the bugs to be done15:13
mupPR snap-confine#167: drop 'owner' check on mountinfo and allow write to @{PROC}/[0-9]*/attr/current <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snap-confine/pull/167>15:13
jdstrandara: at this point, I think my part for helping zyga is done?15:14
arajdstrand, thanks!15:14
tyhicksjdstrand: thank you!15:16
jdstrandnp15:18
mupPR snapd#2106 closed: tests: enable tests related to the home interface in all-snaps <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2106>15:22
mupPR snapd#2109 closed: tests: update tests now that we do not have snapd.boot-ok anymore <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2109>16:27
mupPR snapd#2110 opened: overlord/devicestate: don't bail out on the first error in DeviceManager.Ensure, subcalls are fairly orthogonal <Created by pedronis> <https://github.com/snapcore/snapd/pull/2110>16:35
jdstrandroadmr: hey. ok, I'm going to start work on the review tools for snap declarations now16:42
jdstrandroadmr: and wanted to sync up. is now a good time?16:42
mupPR snapcraft#854 closed: Decouple state handling from plugin options <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/854>16:43
zygajdstrand: https://launchpad.net/~command-not-found-developers/+member17:15
zygaer17:15
zygabad link17:15
zygaI meant this: http://paste.ubuntu.com/23285366/17:15
jdstrandzyga: you mean that is what you wanted uploaded instead of what I did?17:17
zygajdstrand: no, that's just a patch we should probably add to .43's debian packaging17:19
zygajdstrand: I found this on the plane17:19
zygajdstrand: not sure why it broke, it definitely used to work17:19
zygajdstrand: maybe a fault in how tests were set up17:20
zygathis is strictly packaging, the upstream release is OK17:20
zygajdstrand: I merged some of your branches on the plane17:21
jdstrandzyga: fyi, 1.0.42-0ubuntu3 on yakkety has 75517:23
jdstrandzyga: can you file a bug? I'd like to see the yakkety version migrate. I need to focus on snap declarations now, but can circle back to this maybe later today/tomorrow17:24
zygajdstrand: sure, thanks!17:26
zygajdstrand: I will, filing bugs on the plane is harder than sbuilding fixes :)17:26
roadmrjdstrand: hello! Sorry, I was out but i'm back. Sure, let's chat17:28
zygaroadmr: o/17:28
roadmrhello zyga17:28
zyga(just saying hi :)17:28
roadmrzyga: hello :) how are you doing?17:28
zygaroadmr: good, sprinting, patching, hacking :)17:29
roadmryou hacker :)17:29
roadmrzyga: awesome work btw, congrats17:30
roadmrjdstrand: (or if you're e.g. out lunching or something, we could sync later today)17:30
jdstrandroadmr: hey, so my plan is to embed the snapd base declaration for now. then take the snap declaration as a command line argument. on initial upload, the store would provide an empty snap declaration. after that, whatever is saved via the store ui. is this what you had in mind?17:31
jdstrandroadmr: no, I'm here17:31
roadmrjdstrand: ohai :)17:31
roadmrjdstrand: no, our code would pass the meat of the plugs and slots, it's how we've coded it right now17:32
jdstrandroadmr: sorry, that is what I meant17:32
roadmrjdstrand: we had a call earlier today where the issue of "how is it serialized?" came up, which applies to the tools as well17:32
jdstrandroadmr: can you paste me an example of what it will feed to the tools?17:32
roadmrjdstrand: so on initial upload or if the snap-declaration has no plugs/slots, we call crt without the --plugs or --slots arguments17:33
jdstrandthat works fine17:33
jdstrandroadmr: oh, you are splitting up --slots and --plugs?17:34
roadmrjdstrand: yes, that's why I meant by the "meat"17:34
roadmrjdstrand: because if not, I'd have to pass you a blob containing both plugs and slots which you'd have to parse...17:34
roadmrjdstrand: and I'd have to massage it too, since I'd have to aggregate both headers somehow17:35
jdstrandroadmr: I was thinking you'd do --decl=... and that would just have slots: and plugs:17:35
roadmrjdstrand: we could modify our code to give you the snap-declaration document in its entirety17:35
jdstrandwell I haven't gotten very far, so I can adjust17:35
jdstrandroadmr: what is in --plugs and --slots?17:36
roadmrjdstrand: yea... ok so what we'd pass is a json representation of slots/plugs, as edited my the reviewer17:36
jdstrandjson?17:36
=== fginther` is now known as fginther
roadmrjdstrand: yep. I guess it could be a collapsed-in-one-line json thing17:36
jdstrandroadmr: so the store has 'Edit declaration assertion'17:37
jdstrandroadmr: and two text areas17:37
roadmrjdstrand: so the workflow is: we call crt with either --plugs/slots or not. If c-r-t says there's trouble with the payload (say, this payload would cause the snap to not install), the reviewer is expected to craft a suitable payload in those fields17:38
jdstrandroadmr: what goes in there? the yaml-esque payload and you convert that to json for the tools?17:38
roadmrjdstrand: then redo the crt review (there's a button for that) and once it passes, it approves the snap17:38
roadmrjdstrand: no, the json payload goes there. We'll never edit the yamlesque version by hand17:38
jdstrandthe json payload17:39
jdstrandhmm17:39
roadmrjdstrand: what happens is, once the tools are happy with the json payload, we update the snap-declaration, passing a dict built from that json (essentially plugs=json.loads(the_json_payload))17:39
roadmrjdstrand: then the snap-declaration will have the yamlesque thing. But the store keeps a copy of the original JSON for human editing17:39
roadmrjdstrand: now, on subsequent upload, I pass the tools the json; if they're happy, then automated review just passes and I don't update the assertion at all (since it's supposed to already have that payload)17:40
jdstrandroadmr: I have some concerns that the reviewer needs to enter json instead of yaml, since the declaration spec uses yaml17:40
roadmrjdstrand: hehe what I keep hearing about that is "it's not really yaml" :)17:41
jdstrandroadmr: plugs and slots are just dicts17:41
roadmrjdstrand: that leaves us in a weird situation because we could help the reviewer by at least superficially validating json or pure-yaml syntax, but if it's some yamloid thing, the thought of crafting a custom validator sounds painful17:42
roadmrjdstrand: yes; one characteristic of the json is that it has to parse to a dict. For example, '"string yay"' is valid json but won't result in a dict17:42
zygaroadmr: json doesn't *have to* parse to a dict, most parses can just return any valid json type17:43
roadmrzyga: yes, I meant for this particular case, because SAS does expect a dictionary/map17:43
jdstrandroadmr: ok, let's backburner this discussion since it is only something the reviewer would see and for the moment, that would be me17:43
roadmrjdstrand: sure17:44
jdstrandroadmr: alright, so the tools gets no --plugs or --slots on initial upload. after that the store will give a json file for --plugs and/or --slots?17:44
jdstrandroadmr: then the tools do its thing. if the tools are not happy, what do you want it to do, exit with error? (I can use a particular error code if that helps)17:45
roadmrjdstrand: so we could give you an inline string --plugs='{"foo": "bar", ...}' *or* we could point to a file containing the separated payload --plugs=/tmp/plugs-for-snap-XXXXX.json)17:46
roadmrjdstrand: yes, that sounds good, we can check for that error code and say "needs to edit the payload".17:46
jdstrandroadmr: I think a file would be best. that string might get long and hit an argv limit17:46
jdstrandroadmr: what should we do if there are errors/warnings in addition to a payload error?17:47
roadmrjdstrand: I think the tools output a jsony thingy with the results too, right? if you could have a specific key there with a meaningful message (e.g. plugs don't allow use of interface FOO which the snap wants to use") that'd make reviewers' (you!) jobs much easier17:47
roadmrjdstrand: ok, let's aim for passing you a file17:48
jdstrandroadmr: the tools can do that helpful stuff no problem (we do that already). as for the json thingy, are you already passing --json to the tools?17:49
roadmrjdstrand: I think we are! let me check17:50
roadmrjdstrand: yes, /path/to/click-review --json /path/to/package.snap17:50
roadmrjdstrand: a new invocation would be /path/to/click-review --json --plugs /path/to/plugs.json --slots=/path/to/slots.json /path/to/package.snap17:51
jdstrandroadmr: if so, this is easy. I will add this code to a new file (sr_declaration.py) which means it'll automatically get put into an area you can process (eg, decl-snap-v2)17:52
jdstrandok good17:52
roadmrawesome :)17:52
jdstrandroadmr: these are the return codes currently:17:52
jdstrandRETURN CODES17:52
jdstrand  0     found no errors or warnings17:52
jdstrand  1     checks not run due to fatal error17:52
jdstrand  2     found errors and/or warnings17:52
jdstrand  3     found warnings17:52
mupPR snapd#2111 opened: snap: ignore /dev/loop addings from udev <Created by mvo5> <https://github.com/snapcore/snapd/pull/2111>17:52
jdstrandroadmr: add '4  found snap declartion conflicts'17:53
roadmrjdstrand: sounds good to me. It'd be for correctness only because I checked and we don't use the return code at all :(17:54
roadmrjdstrand: we rely entirely on the json output17:54
jdstrandroadmr: the question then is, should I return 2 if have snap decl conflicts + errors/warnings?17:54
roadmrjdstrand: yes, sounds like 2 encompasses "other errors *and* snap decl conflicts" fine17:54
jdstrandroadmr: ok, then I return 4 if just snap decl conflicts and 2 if other conflicts. we can revisit that17:54
jdstrandok cool17:55
roadmrtotally, that makes sense17:55
jdstrandroadmr: what is the status of the store today? I imagine you are just waiting on me so you can uncomment the code to pass --slots and --plugs?17:56
roadmrjdstrand: yes, but we also need to fix the "parse json and pass the dict to SAS" (so: please DON'T edit those plugs/slots fields :)17:57
jdstrandnp17:57
roadmrjdstrand: the code to pass --slots/--plugs is behind a toggle so we can flip it quickly if we break something17:58
roadmrjdstrand: but right now it won't work really because it passes inline strings17:58
jdstrandroadmr: ok, so, is this ok as part of the json output: http://paste.ubuntu.com/23285610/17:59
roadmrjdstrand: perfect!17:59
jdstrandroadmr: ok, great17:59
jdstrandI think that is everything17:59
jdstrandat least on my end18:00
jdstranddo you have questions or is there anything else I need to know about?18:00
roadmrjdstrand: I think this is clear, just a few tweaks to what we were envisioning18:00
jdstrandok, I'll get to work on this. I will ask for a review when ready'18:01
roadmrjdstrand: thanks! I'll summarize in the design doc we have and get cracking18:03
roadmr\o/18:03
jdstrandroadmr: great :)18:04
roadmrthis is awesome, almost as awesome as when sas started exploding due to me having created a bad payload \o/18:04
jdstrandhaha :)18:10
mupPR snapd#2112 opened: systemd: Correct the mount arguments when mounting with squashfuse <Created by tyhicks> <https://github.com/snapcore/snapd/pull/2112>18:15
=== Pharaoh_Atem is now known as Conan_Kudo
=== Conan_Kudo is now known as Pharaoh_Atem
om26erHi! Where can I find documentation on how to consume the gpio interface ?18:19
jdstrandroadmr: in the json output, lets use snap.v2_declaration instead of snap.v2_decl18:20
jdstrand  "snap.v2_declaration": {18:20
jdstrand    "error": {},18:20
jdstrand    "info": {},18:20
jdstrand    "warn": {}18:20
jdstrand  }18:20
roadmrjdstrand: sounds good, noted18:22
mupPR snapcraft#844 closed: Add `snapcraft history` <Created by maxiberta> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/844>18:28
sergiusensmaxiberta mind fixing snapcraft#84518:29
mupPR snapcraft#845: Add `snapcraft status` <Created by maxiberta> <Conflict> <https://github.com/snapcore/snapcraft/pull/845>18:29
sergiusens?18:29
tyhickszyga: thanks for the review! do you know if there's going to be another snapd release and upload before yakkety is released?18:29
riverloopHey, I tried building a snap of mpv using the examples from snappy-playpen on GitHub.18:41
riverloopI successfully built the snap but mpv can't access any files when I try to play something using it.18:42
riverloopI tried also playing a YouTube url. ffmpeg showed some error.18:42
riverloopWhat may be the reason?18:42
tyhicksniemeyer: hi - I'm looking for some guidance on getting https://github.com/snapcore/snapd/pull/2112 into yakkety18:47
mupPR snapd#2112: systemd: Correct the mount arguments when mounting with squashfuse <Created by tyhicks> <https://github.com/snapcore/snapd/pull/2112>18:47
tyhicksniemeyer: everything is in place, except for that small change, for snaps to work in unprivileged lxd containers18:47
tyhicksniemeyer: I don't know if there's another snapd upload planned before yakkety's release, if I should apply that patch to what's in yakkety-proposed and make a new upload, or if you're fine with including that fix in an SRU18:48
mupPR snapd#2110 closed: overlord/devicestate: don't bail out on the first error in DeviceManager.Ensure, subcalls are fairly orthogonal <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2110>18:50
mupPR snapd#2111 closed: snap: ignore /dev/loop addings from udev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2111>18:50
niemeyertyhicks: I think it's fine to see it in an SRU and in master18:50
niemeyertyhicks: let me response to the PR there18:50
tyhicksthank you18:50
niemeyertyhicks: Done, let me know what you think18:52
pedronisjdstrand: about JSON, as I understand that was the agreement in the meetings we had (there's no official tooling to parse fragments of assertion format atm)18:58
tyhicksniemeyer: Thanks. We can deliver the fix in a post-yakkety-release SRU. Until then, only root inside of a yakkety container will be able to run snap commands.19:03
mupPR snapcraft#858 opened: python plugin: allow usage of bzr <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/858>19:19
tyhicksratliff, jgrimm: fyi, it looks like we'll deliver the last piece of the snaps in lxd containers story (the snapd bug fix for bug #1630789) as an SRU after yakkety is released ^19:25
mupBug #1630789: normal users can't run snaps inside of LXD containers <verification-needed> <Snappy Launcher:Fix Committed by jdstrand> <Snappy:In Progress by tyhicks>19:25
mup<snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Triaged> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1630789>19:25
jgrimmtyhicks, ack. thanks for following up!19:25
tyhicksnp!19:26
niemeyertyhicks: Hmm19:33
niemeyertyhicks: Post yakkety release?19:33
tyhicksniemeyer: maybe I misunderstood what you were saying by, "I think it's fine to see it in an SRU and in master"19:34
tyhicksniemeyer: I thought you were saying that we should wait until after yakkety is released and then SRU that fix into yakkety-updates as part of the next snapd SRU19:34
niemeyertyhicks: I was suggesting we can SRU this in X, probably next week19:35
tyhicksniemeyer: ah! yes, we're in the process of SRU'ing everything into X19:35
niemeyertyhicks: and naturally in yakkety.. but it's October already, so I might be missing what the timeframe is for Yakkety19:35
tyhicksniemeyer: today is final freeze for yakkety19:35
tyhicksniemeyer: I can make a small yakkety snapd upload containing only that change, if you'd like me to19:36
niemeyertyhicks: I think this is okay.. the only point of using squashfuse is for that one case anyway, so if it breaks it won't get any worse19:37
niemeyermvo: What do you think?19:37
tyhicksoh, there he is19:37
tyhicks:)19:37
tyhicksmvo, niemeyer: here's the debdiff that I would upload: https://paste.ubuntu.com/23286012/19:39
tyhicksI've tested it with inside of a lxd container as well as outside of a container19:40
niemeyertyhicks: +119:40
tyhicksthanks, I'll wait for mvo to have a look as well19:40
niemeyertyhicks: It would be really nice to see a spread test exercising this logic (cheaply, if possible)19:41
mvotyhicks: yeah, looks fine, thank you19:41
tyhicksniemeyer: would I need to mock a container environment or would the spread test set up a lxd container?19:42
tyhicksI'm going to go ahead and proceed with this upload and will try to get a spread test ready for trunk19:42
tyhicksthanks mvo!19:42
=== rcj` is now known as rcj
=== rcj is now known as Guest46240
=== Guest46240 is now known as rcj
=== drizztbsd is now known as timothy
mupPR snapd#2096 closed: tests: check for failure creating user on managed ubuntu-core systems <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2096>20:58
lutostagso I have snaps installed and now there is an extra dir in my home directory 'snap' is this expected?21:01
nacclutostag: yes21:02
lutostaghmm... not my favorite, any way to make it live elsewhere?21:02
nacclutostag: i don't believe so, as there are some variables that rely on it (iirc)21:05
lutostagnacc: ok, thanks for the info. Appreciate it21:05
mupBug #1631159 opened: No way to simply list available snaps via snapd <Canonical System Image:New> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1631159>21:17
mupBug #1631165 opened: no ability to move snap directory out of $HOME <Snappy:New> <https://launchpad.net/bugs/1631165>21:30
=== drizztbsd is now known as timothy
mupPR snapcraft#845 closed: Add `snapcraft status` <Created by maxiberta> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/845>22:17
SuperJonotronI have manged to get a snap all wrapped up and deployed but when it runs it needs to run with root privelidges, I can't run the snap with "sudo snapname", doesn't recognize the snap, if i run it just as a user, it's fine but doesn't have root privelidges and when it hits those parts in the application I get "sudo: no tty present and no askpass program specified"23:57
SuperJonotronis there a way to handle this kind of thing in the yaml? or during install?23:57
naccSuperJonotron: why does it need to run as root?23:58
SuperJonotronsome bash scripts, at least one I know of personally, needs to be run as root23:59

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