liuxgwhen i build my snap project, I get the the same file from two different parts with the same path. I do not know how to resolve the issue.02:12
qengholiuxg: In your parts, use "stage:" to exclude it from one or both. """stage: [ -usr/share/haxored.txt, -var/tmp/no ]"""02:16
liuxgqengho, thanks. I might have a try.02:17
liuxgqengho, thanks. you solved my  problem :)02:35
=== chihchun_afk is now known as chihchun
dholbachhey hey07:19
=== Al_ is now known as Guest68546
didrocksgood morning dholbach!07:21
dholbachsalut didrocks07:21
seb128hey dholbach!07:24
dholbachsalut seb12807:32
dholbachdidrocks, want to hang out and chat in a bit?07:35
didrocksdholbach: I have a meeting at 10am, so either now or this afternoon (as we have the doc meeting at 11am)07:36
didrocksI'm fine with both :)07:36
dholbachlet's quickly chat now07:36
dholbachand we can still talk later on07:36
mupPR snapd#1607 opened: changed snapd to snap <Created by liu-xiao-guo> <https://github.com/snapcore/snapd/pull/1607>07:38
qengholiuxg: What version of snapd do you have?07:43
qenghodavidcalle had same question. :)07:45
=== davmor2_ is now known as davmor2
dholbachcan somebody please help with https://github.com/ubuntu/snappy-playpen/pull/197?08:01
mupPR ubuntu/snappy-playpen#197: Add Kodi snap for stable release <Created by dgmvecuador> <https://github.com/ubuntu/snappy-playpen/pull/197>08:01
mupPR snapcraft#702 opened: Use the new snapcraft.io mailing list as contact information <Created by seb128> <https://github.com/snapcore/snapcraft/pull/702>08:09
liuxgqengho, http://paste.ubuntu.com/21735507/08:12
qenghoHmm! Should snapcraft provide something like "dh strip"?08:24
qengholiuxg: haole. I have no idea of the difference.08:37
mupPR snapcraft#703 opened: Update the completion list of commands <Created by seb128> <https://github.com/snapcore/snapcraft/pull/703>08:45
liuxgqengho, with snapd, it does not work. I think the documents there are outdated. some of the them have the "snappy" there.08:49
didrocksqengho: that's what we discussed and yeah, snapcraft is supposed to provide stripping in the "snap" stage09:06
mupBug #1608244 changed: implement low level usb interface for snaps requiring libusb <Snappy:New> <https://launchpad.net/bugs/1608244>09:14
=== chihchun is now known as chihchun_afk
mupPR snapcraft#704 opened: Slightly tweak the "no jar files" errors (lp: #1606352) <Created by seb128> <https://github.com/snapcore/snapcraft/pull/704>10:09
=== chihchun_afk is now known as chihchun
jamespagehi all10:48
jamespagenot sure if I'm just missing something, but  what's the norm for configuration files for a snap?10:49
ogra_jamespage, there currently inst an actual norm ... i usually create them on first start of an app or daemon from the wrapper scripts ... in 15.04 we used to have a "snappy config" command that could handle yaml create a config10:53
jamespageogra_, hmm ok - so I'm having a stab at some openstack snaps10:55
jamespageogra_, should I be using /etc/nova/ for example ?10:55
jamespageor should that be in a snap specific location?10:56
ogra_no, you should always use $SNAP for readonly data and $SNAP_DATA (daemons) or $SNAP_USER_DATA (apps) for writable stuff10:56
ogra_and teach your app to use its config from there ...10:57
jamespageogra_, ack10:58
jamespageogra_, can I use those in the snapcraft.yaml ?10:59
ogra_no, only at runtime i think11:00
jamespageogra_, I was thinking like "command: usr/bin/nova-api-os-compute --config-dir=$SNAP_DATA/nova.conf.d11:01
morphiszyga: ping11:03
ogra_jamespage, well, i'm not sure if $SNAP_DATA survives that when the command is being moved into the generic wrapper, you have to try :)11:04
jamespageogra_, ack - will poke and see11:05
=== chihchun is now known as chihchun_afk
Son_Gokumorphis, zyga will not return until Wednesday evening11:22
morphisSon_Goku: ah ok, thanks11:22
Son_Gokuhe's on his way to Krakow for family things and Flock11:22
Son_GokuFedora's conference11:22
Son_Gokuhe's intentionally not taken his laptop with him, either11:22
Son_Gokuso there's literally no way to contact him unless you have his phone number :)11:23
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
sborovkovHi. I am using log-observe interface to read system journal. Running unconfined but anyway I am getting this messages. Is this normal?13:00
sborovkovapparmor="ALLOWED" operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/1156d1fe87df441482d57dcd197ca7d5/system.journal" pid=751 comm="python3" r13:00
sborovkovapparmor="ALLOWED" operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/1156d1fe87df441482d57dcd197ca7d5/system@1d2eed63da7b4c60b090256983be47bb-0000000000000ea7-00053901f4ca5813.journal"13:01
sborovkovI am just polling for changes in system log using systemd's python API13:01
jdstrandsborovkov: yes. notice those say 'ALLOWED'. reading systemd logs is allowed as of snapd 2.0.1013:10
sborovkovAh, I though that's because of me running unconfined. Understood13:26
ogra_cjwatson, hmm, is there any way for me to get the info if my snap had proposed enabled ... beyond grepping sources.list from my makefile (like ... an env var ) ?13:46
mupPR snapcraft#705 opened: parser - Remove namespacing and subparts <Created by josepht> <https://github.com/snapcore/snapcraft/pull/705>13:51
mhall119sergiusens: how do I run the snapcraft test suite in a clean lxc?14:05
kyrofamhall119, just the units? Or everything?14:14
kgunnjdstrand: hey, i've done another update to mir interface per your feedback wrt snippets for connected plug/slot for the client14:19
kgunnjdstrand: would you mind just quickly eyeballing and telling me if i'm on the right path14:19
mupPR snapd#1229: Add in an application-lifecycle interface <Created by ted-gould> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1229>14:19
kgunnnot that one! ^14:19
kgunnjdstrand: this one https://github.com/snapcore/snapd/pull/129914:20
mupPR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299>14:20
SamYapleyo yo. so I have a PR with a failing test and I can't access the IP to see the details of the failing test14:21
mupPR snapcraft#663: Improve python2 test coverage <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/663>14:21
SamYapleits just packing anyway14:21
mhall119kyrofa: the snaps really, so I can try and fix https://github.com/snapcore/snapcraft/pull/68814:22
mupPR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>14:22
jdstrandkgunn: it's coming along. I noticed though in PermanentPlugSnippet() you have the mirPermanentSlotAppArmor and mirPermanentSlotSecComp policy14:23
kyrofamhall119, try python3 -m unittest integration_tests.test_nodejs_plugin from the root of snapcraft14:24
jdstrandkgunn: your permanent slot variables should go in your permanent slot function, your connected slot policy in your connected slot function, your permenent plug policy in your permanent plug function and your connected plug policy in your connected plug function14:24
kyrofamhall119, that's one of the failures14:24
kgunnjdstrand: right, it's just a variable name ...14:25
kgunni'll correct that14:25
mhall119kyrofa: I get ImportError: No module named 'fixtures'14:25
kgunnjdstrand: i was really wondering if i had the snippet part right14:25
kyrofamhall119, ah, yeah check debian/control, make sure you have the right dependencies. python3-fixtures for that one14:25
jdstrandkgunn: well... mirPermanentSlotAppArmor says "Allow operating as the Mir server". that needs to be what PermanentSlotSnippet() uses, not what PermanentPlugSnippet (which is what it is doing now)14:26
mhall119kyrofa: thanks, doing that now14:27
jdstrandkgunn: so don't change the names of the variables. use the variables in the correct functions14:27
kgunnjdstrand: that's just it...if i move it, it will not work14:27
jdstrandthings aren't all correct14:27
jdstrandI'll spell it out14:28
didrocksjdstrand: hey! Is it known that latest version of snappy-debug is failing auditing syslog despite the plug being connected? http://paste.ubuntu.com/21762803/14:28
didrocks(I guess the issue is in snapd interface not giving the correct permission)14:28
jdstrandPermanentPlugSnippet() should use mirPermanentSlotAppArmor and mirPermanentSlotSecComp. right now it is returning nil, nil for apparmor and seccomp, so the server won't start14:29
jdstrandkgunn: ^14:29
jdstrandkgunn: next, ConnectedSlotSnippet() is returning nil, nil. It should be returning mirConnectedSlotAppArmor14:30
jdstrandkgunn: next, ConnectedPlugSnippet is returning nil, nil. it should be using mirConnectedPlugAppArmor and mirConnectedPlugSecComp14:30
jdstrandkgunn: and finally, PermanentPlugSnippet(), it should return nil, nil, but is not14:31
jdstrandkgunn: what this does is on install, permanent slot policy is auto-generated for anything using 'slots: [ mir ]'. ie, your server would 'slots: [ mir ]' and be allowed to start14:32
jdstrandkgunn: then a client that uses 'plugs: [ mir ]' is connected with 'sudo snap connect client:mir mir-server:mir', then the connected slot ploicy is added to the mir server's policy for connecting to the client, and connected plug policy is added to the client for talking to the server14:33
jdstrandkgunn: does that make sense?14:33
jdstranddidrocks: you need to run it as root14:34
kgunnjdstrand: so let me ask you a very direct question, would you expect me to be able to launch my server and run a client the way it is currently implemented?14:34
jdstranddidrocks: well, actually, I think you can run it without root, just won't have the sysctl work14:35
jdstranddidrocks: the thing you pointed out is known and is fixed in snap-confine 1.0.3914:35
jdstranddidrocks: which is in xenial-proposed14:35
didrocksjdstrand: hum, IIRC, it was failing even as root when I tried it in front of a client, let me retry14:36
jdstranddidrocks: snap-confine 1.0.38 introduced a regression that was fixed in the next upload to xenial-propsed. basically, take the newest version in xenial-proposed and it will work again14:36
didrocksjdstrand: ah, ok, so regression, but fixed in -proposed14:36
jdstranddidrocks: yes, because /var/log was not bind mounted into the runtime14:36
didrocksjdstrand: that explains why I didn't see any denials in /var/log/syslog, thanks for confirming! :)14:37
jdstrandkgunn: it depends on the yaml. your implementation is backwards wrt plugs and slots14:37
jdstrandkgunn: your policy variables are correct. where they are used is backwards14:38
kgunnjdstrand: this is my server yaml14:38
jdstrandkgunn: yeah, that's wrong14:39
kgunnjdstrand: btw - i always knew it was backwards from what i was told (which is what's been disturbing me)14:39
jdstrandkgunn: the server should 'slots: [ mir ]'14:39
kgunnjdstrand: damn it! :)14:39
jdstrandkgunn: the slot side provides an implementation of the interface. your mir server snap is an implementation of a mir server14:39
jdstrandkgunn: the server side slots. the client side plugs into the slot to use it14:40
jdstrandkgunn: so, if you s/slots/plugs/ in your yaml, and then follow what I laid out in backscroll, it should only then be down to fine-tuning the policy14:40
mupPR snapd#1608 opened: tests: add snapd-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1608>14:44
mhall119sergiusens: ping, what's the rationale behind stripping common path prefixes when unpacking a tarball in snapcraft?14:57
mupPR snapd#1609 opened: overlord/devicestate: first pass at device registration logic <Created by pedronis> <https://github.com/snapcore/snapd/pull/1609>15:26
mupBug #1608572 opened: There is no easy way to know what port snapweb is listening to <Snappy:New> <https://launchpad.net/bugs/1608572>15:29
kgunnjdstrand: thanks for that, i always knew it wasn't right, i just didn't think the yaml was wrong...so thanks for helping15:33
jdstrandkgunn: my pleasure!15:34
kgunnjdstrand: and just to be sure...on the client side15:34
kgunnthat is correct ^15:34
kgunnplugs [mir]15:35
jdstrandkgunn: yes, server slots and client plugs15:36
kgunnjdstrand: don't know how i overlooked that all this time15:36
jdstrandit isn't the most obvious thing in the world. zyga (hi!) has a blog series that is helpful, but you shouldn't have to read it now after our discussion here (though by all means do so if you want, it is good :)15:37
jdstrandhe is going to be writing another blog entry on creating interfaces I think soon15:37
mupPR snapd#1610 opened: store: soft-refresh discharge macaroon from store when required <Created by matiasb> <https://github.com/snapcore/snapd/pull/1610>15:39
mupPR snapd#1611 opened: tests: add locale-control write spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1611>16:20
* ogra_ just opened the gnome disk utility on a machine with a lot of snaps installed 16:26
mupPR snapd#1527 closed: overlord/state,overlord/ifacestate: define basic infrastructure for and then setting up serialising of interface mgr tasks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1527>16:31
mupBug #1608608 opened: Snapweb avahi service is still called webdm.local <Snappy:New> <https://launchpad.net/bugs/1608608>16:42
=== ehbello_ is now known as ehbello
mupPR snapd#1612 opened: interfaces: add /proc/version_signature to appamor template <Created by arges> <https://github.com/snapcore/snapd/pull/1612>17:35
=== Al_ is now known as Guest14149
elopiokyrofa: josepht: I looked at the code. By fake, I mean just to make sure that shutil.copystat was called.19:00
kyrofaelopio, that doesn't seem overly fragile to you?19:00
elopiomock.patch('shutil.copystat') and that's it.19:00
elopiokyrofa: yes, it is.19:00
kyrofaelopio, but the best option, you think?19:00
elopioso also add a manual test that does chown, builds an os snap, and verifies the ownership.19:00
elopiowe might find ways to automate that manual test, probably as an integration test. But that's worth only if it takes a considerable amount of time to run it.19:01
kyrofaelopio, sounds good. How do we document such manual tests?19:02
elopiokyrofa: we have a file called manual-tests.md19:02
kyrofaelopio, oh. How handy!19:02
elopioI see that ogra_ has a bug with steps to reproduce this. Ideally, we automate what ogra is doing, but all his links take me to "page not found".19:04
josephtelopio: okay, thanks for the direction :)19:09
stokachustill running into this ugly loop: https://paste.ubuntu.com/21797159/19:10
stokachumy snapcraft.yaml https://www.irccloud.com/pastebin/B3cVKFT7/19:11
stokachuit works in snap try mode, but not installing from snap store19:11
stokachuusing snapcraft 2.13.119:11
kyrofastokachu, interesting... are there symlinks somewhere in the /home/adam/snap/conjure-up/x1 path?19:15
stokachukyrofa: only thing i can think of is we use os.makedirs in some areas of the code19:16
stokachumainly creating directories in ~/.cache/conjure-up if they dont exist19:16
stokachukyrofa: https://github.com/conjure-up/conjure-up/tree/patch-dl-function this is the branch if you have time to try it out yourself19:17
stokachudoes the git source support a branch?19:19
kyrofastokachu, yes, using the source-branch keyword19:20
stokachulemme try that, i was trying to remove a wget dep and was pulling master during snapcraft rather than that branch19:20
kyrofastokachu, this does seem to be coming from your source somewhere, not snapd. I suggest trying to figure out which line exactly is busting19:21
stokachukyrofa: how do you debug this?19:21
kyrofastokachu, well first of all, does the application support some sort of --debug flag or something else that would enable stack traces?19:22
stokachukyrofa: yes19:22
kyrofastokachu, I'd start there19:23
kyrofaCan you pastebin the output of `conjure-up -h --debug` (or whatever)?19:23
stokachuthat pastebin above was from just running conjure-up -h19:24
stokachudont worry about it ill try to figure it out on my own19:24
kyrofaSure, but it's still swallowing the trace19:24
ogra_elopio, oh, which bug is that ?19:27
elopioogra_: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/160590319:28
mupBug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):In Progress by joetalbott> <https://launchpad.net/bugs/1605903>19:28
elopioogra_: could you please document the steps to reproduce that?19:28
ogra_elopio, sure19:30
ogra_hmm, though thats a  bit tricky .. the image PPA has the fix backported already ...19:31
ogra_to actually repro it you would need a copy of the PPA with the patches snapcraft removed ...19:31
elopioogra_: don't worry. Just mention that it will not fail because the ppa is patched. It is nice that it actually passes already :)19:35
ogra_elopio, i added a comment with instructions ... but it is non-trivial  due to the PPAs involved19:36
ogra_added a note :)19:37
ogra_if anyone feels like, you guys can also just upload snapcraft to that PPA ... every snappy-dev member has upload access19:38
ogra_happy to do test builds19:38
josephtelopio: fwiw, I think we can just have a test that does 'snapcraft build; sudo chown nobody:nogroup <some-file>; snapcraft prime' and ensure that 'prime/<some-file>' isn't owned by root19:47
josephtelopio: a manual test, I mean19:47
elopiojosepht: sure, that works.19:48
elopioat some point we need to make sure that we never break ogra's workflow, but I have the feeling that it will be a test in ubuntu-core-snap.19:48
ogra_feel free to make a merge proposal ... the branch is owned by snappy-dev ... we all are members ;)19:50
kyrofaI need my new house... internet is sooo flaky out here19:50
ogra_still not moved ?19:50
kyrofaogra_, the move has multiple stages :P19:50
kyrofaogra_, made it across the country, but crashing with in-laws while we're waiting for the house to close19:51
kyrofaNeeding to run snapcraft + 30k downloads/occasional complete connection death = kill me now19:51
ogra_right, you said so in heidelberg ... i thought thaat phase would be over eventually :)19:52
kyrofaYeah, another month19:52
* kyrofa cries19:52
ogra_kyrofa, sudo snap install packageproxy ... point your sources.list to localhost:9999 ...19:52
elopiokyrofa: mosh + byobu + canonistack.19:53
kyrofaHmm... canonistack might be a good idea. As long as it doesn't eat my VM before I'm done with it :P19:53
kyrofaogra_, what is packageproxy?19:54
ogra_kyrofa, a snap using approx ...19:54
* kyrofa wants a `snap show` command or something19:54
ogra_it sets up a local package proxy on your machine, so packages only get downloaded once19:54
kyrofaogra_, ah, that's handy19:55
kyrofaogra_, you should put the cache in SNAP_COMMON now, not SNAP_DATA19:57
ogra_i used it all the time for local image buiulds ... i'D go crazy when having to download gigs for every build when i do like 20 in a row19:57
kyrofaogra_, unless you really want it versioned?19:57
ogra_kyrofa, yeah, i need to re-work that snap a lot... it is originatig from 15.04 :)19:57
kyrofaOh, nice19:57
ogra_(i have a 15.04 snappy server with it running in active use here :) )19:58
ogra_i only did a few quick hacks to make it series 16 compatible ... but it should actiually be re-done completely ... i'm kind of waiting for the new config interface first though19:58
ogra_in the 15.04 version you could actually manage all aspects of its config with snappy config commands19:59
kyrofaogra_, ah, right20:00
stokachukyrofa: so i have juju as a stage-package but i can't get it to run juju version20:27
kgunnogra_: hey , i bet i missed an incantation change...this used to work sudo ubuntu-device-flash --verbose core 16 --channel edge -o xen_aug1.img --developer-mode --gadget=canonical-pc --kernel=canonical-pc-linux --os=ubuntu-core --size=520:27
stokachuthats where it is hanging at20:27
kgunnbut now complains no hw description in gagdet20:28
stokachu /snap/conjure-up/x6/usr/bin/juju: 3: exec: juju: Argument list too long20:29
kyrofakgunn, I think the gadget yaml format changed...20:50
invapidif the source code is updated, how do you make a snap build using the new source code?20:51
invapidjust rm -rf stage/ # ??20:52
kyrofainvapid, if it's just a single part in the snap, run `snapcraft clean <part> && snapcraft`20:54
invapidhmm, must not be snapcrafts fault then21:07
kyrofainvapid, what's happening?21:08
invapidstill debugging, but source code changes aren't getting compiled21:10
invapidI assume it's just cached somewhere21:10
kyrofainvapid, even with the clean command I just gave you?21:11
kyrofaHuh... odd. Yeah that will completely remove the source cache that snapcraft keep in parts/<partname>/src21:12
mhall119kyrofa: sergiusens: https://github.com/snapcore/snapcraft/pull/688 is passing now21:12
mupPR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>21:12
kyrofainvapid, is the source kept locally? Or is it on the internet somewhere?21:12
mupPR snapd#1446 closed: interfaces/builtin: add dbus-bind interface <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1446>21:12
invapidahh - the "part" isn't pull from the source being modified21:12
invapidthanks kyrofa figured it out21:13
kyrofainvapid, ah ha! Good deal21:13
kgunnjdstrand: ok, had time to get back to interface work...so i've cleaned it up and was testing, server is starting fine, mir-server:mir connection under slot...the mir-client:mir connection is listed under plug like expected21:54
kgunnbut there's an aa denail on client for open/read of /usr/share/applications, so i added /usr/share/applications r, to connected plug21:55
kgunnbut denial is still there...21:55
kgunnam i missing something21:55
kyrofakgunn, did you reinstall the snap after making the plug modification in snapd?21:56
kgunnkyrofa: yep, removed / installed21:56
kyrofakgunn, yep, that's the length of my knowledge :P21:56
kgunn(even rebooted the vm, cause snapd was pissed :)21:56
kyrofakgunn, how are you testing your dev tree of snapd, by the way?21:57
kgunnkyrofa: https://docs.google.com/document/d/1fhRDn8KkeOICgO3fxDwFbqPmultEuL18ThKaa-pjyzc/21:58
kgunngranted i'm on a 2 week old image21:59
kgunn(was too lazy to grab the experimental udf and build a new one)21:59
kgunnmaybe i should do that now21:59
kyrofakgunn, that plug isn't in master, right? It's completely new?22:01
kgunnkyrofa: correct...it's the mir interface (which is a perma slot for server, and connected plug for client22:03
kyrofakgunn, okay. I was thinking maybe you were hitting the re-execution stuff, but then it wouldn't work at all22:04
kgunnhmm...experimental u-d-f not happy22:04
mupPR snapd#1613 opened: add dbus-app interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>22:05
kgunnmmm, can't run VM while you run experimental udf22:05
jdstrandkgunn: you would need '/usr/share/applications/ r,' (trailing slash is important)23:02
jdstrandkgunn: but I'm not sure that should be there, but fine to add now and we can discuss in PR23:02
jdstrandkgunn: also, nice! :)23:02

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