| liuxg | when 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 |
|---|---|---|
| qengho | liuxg: In your parts, use "stage:" to exclude it from one or both. """stage: [ -usr/share/haxored.txt, -var/tmp/no ]""" | 02:16 |
| liuxg | qengho, thanks. I might have a try. | 02:17 |
| liuxg | qengho, thanks. you solved my problem :) | 02:35 |
| === chihchun_afk is now known as chihchun | ||
| dholbach | hey hey | 07:19 |
| === Al_ is now known as Guest68546 | ||
| didrocks | good morning dholbach! | 07:21 |
| dholbach | salut didrocks | 07:21 |
| seb128 | hey dholbach! | 07:24 |
| dholbach | salut seb128 | 07:32 |
| dholbach | didrocks, want to hang out and chat in a bit? | 07:35 |
| didrocks | dholbach: I have a meeting at 10am, so either now or this afternoon (as we have the doc meeting at 11am) | 07:36 |
| didrocks | I'm fine with both :) | 07:36 |
| dholbach | let's quickly chat now | 07:36 |
| dholbach | and we can still talk later on | 07:36 |
| didrocks | sure! | 07:36 |
| mup | PR snapd#1607 opened: changed snapd to snap <Created by liu-xiao-guo> <https://github.com/snapcore/snapd/pull/1607> | 07:38 |
| qengho | liuxg: What version of snapd do you have? | 07:43 |
| qengho | davidcalle had same question. :) | 07:45 |
| davidcalle | :) | 07:46 |
| === davmor2_ is now known as davmor2 | ||
| dholbach | can somebody please help with https://github.com/ubuntu/snappy-playpen/pull/197? | 08:01 |
| mup | PR ubuntu/snappy-playpen#197: Add Kodi snap for stable release <Created by dgmvecuador> <https://github.com/ubuntu/snappy-playpen/pull/197> | 08:01 |
| mup | PR 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 |
| liuxg | qengho, http://paste.ubuntu.com/21735507/ | 08:12 |
| qengho | Hmm! Should snapcraft provide something like "dh strip"? | 08:24 |
| qengho | liuxg: haole. I have no idea of the difference. | 08:37 |
| mup | PR snapcraft#703 opened: Update the completion list of commands <Created by seb128> <https://github.com/snapcore/snapcraft/pull/703> | 08:45 |
| liuxg | qengho, with snapd, it does not work. I think the documents there are outdated. some of the them have the "snappy" there. | 08:49 |
| didrocks | qengho: that's what we discussed and yeah, snapcraft is supposed to provide stripping in the "snap" stage | 09:06 |
| mup | Bug #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 | ||
| mup | PR 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 | ||
| jamespage | hi all | 10:48 |
| jamespage | not 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 config | 10:53 |
| ogra_ | *isn't | 10:53 |
| jamespage | ogra_, hmm ok - so I'm having a stab at some openstack snaps | 10:55 |
| jamespage | ogra_, should I be using /etc/nova/ for example ? | 10:55 |
| jamespage | or 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 stuff | 10:56 |
| ogra_ | and teach your app to use its config from there ... | 10:57 |
| jamespage | ogra_, ack | 10:58 |
| jamespage | ogra_, can I use those in the snapcraft.yaml ? | 10:59 |
| ogra_ | no, only at runtime i think | 11:00 |
| jamespage | ogra_, I was thinking like "command: usr/bin/nova-api-os-compute --config-dir=$SNAP_DATA/nova.conf.d | 11:01 |
| jamespage | " | 11:01 |
| morphis | zyga: ping | 11: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 |
| jamespage | ogra_, ack - will poke and see | 11:05 |
| === chihchun is now known as chihchun_afk | ||
| Son_Goku | morphis, zyga will not return until Wednesday evening | 11:22 |
| morphis | Son_Goku: ah ok, thanks | 11:22 |
| Son_Goku | he's on his way to Krakow for family things and Flock | 11:22 |
| Son_Goku | Fedora's conference | 11:22 |
| morphis | ah | 11:22 |
| Son_Goku | he's intentionally not taken his laptop with him, either | 11:22 |
| Son_Goku | so 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 | ||
| sborovkov | Hi. I am using log-observe interface to read system journal. Running unconfined but anyway I am getting this messages. Is this normal? | 13:00 |
| sborovkov | apparmor="ALLOWED" operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/1156d1fe87df441482d57dcd197ca7d5/system.journal" pid=751 comm="python3" r | 13:00 |
| sborovkov | apparmor="ALLOWED" operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/1156d1fe87df441482d57dcd197ca7d5/system@1d2eed63da7b4c60b090256983be47bb-0000000000000ea7-00053901f4ca5813.journal" | 13:01 |
| sborovkov | I am just polling for changes in system log using systemd's python API | 13:01 |
| jdstrand | sborovkov: yes. notice those say 'ALLOWED'. reading systemd logs is allowed as of snapd 2.0.10 | 13:10 |
| sborovkov | Ah, I though that's because of me running unconfined. Understood | 13: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 |
| mup | PR snapcraft#705 opened: parser - Remove namespacing and subparts <Created by josepht> <https://github.com/snapcore/snapcraft/pull/705> | 13:51 |
| mhall119 | sergiusens: how do I run the snapcraft test suite in a clean lxc? | 14:05 |
| kyrofa | mhall119, just the units? Or everything? | 14:14 |
| kgunn | jdstrand: hey, i've done another update to mir interface per your feedback wrt snippets for connected plug/slot for the client | 14:19 |
| kgunn | jdstrand: would you mind just quickly eyeballing and telling me if i'm on the right path | 14:19 |
| kgunn | https://github.com/snapcore/snapd/pull/1229 | 14:19 |
| mup | PR snapd#1229: Add in an application-lifecycle interface <Created by ted-gould> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1229> | 14:19 |
| kgunn | not that one! ^ | 14:19 |
| kgunn | jdstrand: this one https://github.com/snapcore/snapd/pull/1299 | 14:20 |
| mup | PR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299> | 14:20 |
| SamYaple | yo yo. so I have a PR with a failing test and I can't access the IP to see the details of the failing test | 14:21 |
| SamYaple | https://github.com/snapcore/snapcraft/pull/663 | 14:21 |
| mup | PR snapcraft#663: Improve python2 test coverage <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/663> | 14:21 |
| SamYaple | its just packing anyway | 14:21 |
| mhall119 | kyrofa: the snaps really, so I can try and fix https://github.com/snapcore/snapcraft/pull/688 | 14:22 |
| mup | PR 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 |
| jdstrand | kgunn: it's coming along. I noticed though in PermanentPlugSnippet() you have the mirPermanentSlotAppArmor and mirPermanentSlotSecComp policy | 14:23 |
| kyrofa | mhall119, try python3 -m unittest integration_tests.test_nodejs_plugin from the root of snapcraft | 14:24 |
| jdstrand | kgunn: 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 function | 14:24 |
| kyrofa | mhall119, that's one of the failures | 14:24 |
| kgunn | jdstrand: right, it's just a variable name ... | 14:25 |
| kgunn | i'll correct that | 14:25 |
| mhall119 | kyrofa: I get ImportError: No module named 'fixtures' | 14:25 |
| kgunn | jdstrand: i was really wondering if i had the snippet part right | 14:25 |
| kyrofa | mhall119, ah, yeah check debian/control, make sure you have the right dependencies. python3-fixtures for that one | 14:25 |
| jdstrand | kgunn: 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 |
| mhall119 | kyrofa: thanks, doing that now | 14:27 |
| jdstrand | kgunn: so don't change the names of the variables. use the variables in the correct functions | 14:27 |
| kgunn | jdstrand: that's just it...if i move it, it will not work | 14:27 |
| jdstrand | things aren't all correct | 14:27 |
| jdstrand | I'll spell it out | 14:28 |
| didrocks | jdstrand: 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 |
| jdstrand | PermanentPlugSnippet() should use mirPermanentSlotAppArmor and mirPermanentSlotSecComp. right now it is returning nil, nil for apparmor and seccomp, so the server won't start | 14:29 |
| jdstrand | kgunn: ^ | 14:29 |
| jdstrand | kgunn: next, ConnectedSlotSnippet() is returning nil, nil. It should be returning mirConnectedSlotAppArmor | 14:30 |
| jdstrand | kgunn: next, ConnectedPlugSnippet is returning nil, nil. it should be using mirConnectedPlugAppArmor and mirConnectedPlugSecComp | 14:30 |
| jdstrand | kgunn: and finally, PermanentPlugSnippet(), it should return nil, nil, but is not | 14:31 |
| jdstrand | kgunn: 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 start | 14:32 |
| jdstrand | kgunn: 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 server | 14:33 |
| jdstrand | kgunn: does that make sense? | 14:33 |
| jdstrand | didrocks: you need to run it as root | 14:34 |
| kgunn | jdstrand: 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 |
| jdstrand | didrocks: well, actually, I think you can run it without root, just won't have the sysctl work | 14:35 |
| jdstrand | didrocks: the thing you pointed out is known and is fixed in snap-confine 1.0.39 | 14:35 |
| jdstrand | didrocks: which is in xenial-proposed | 14:35 |
| didrocks | jdstrand: hum, IIRC, it was failing even as root when I tried it in front of a client, let me retry | 14:36 |
| jdstrand | didrocks: 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 again | 14:36 |
| didrocks | jdstrand: ah, ok, so regression, but fixed in -proposed | 14:36 |
| jdstrand | didrocks: yes, because /var/log was not bind mounted into the runtime | 14:36 |
| didrocks | jdstrand: that explains why I didn't see any denials in /var/log/syslog, thanks for confirming! :) | 14:37 |
| jdstrand | kgunn: it depends on the yaml. your implementation is backwards wrt plugs and slots | 14:37 |
| jdstrand | kgunn: your policy variables are correct. where they are used is backwards | 14:38 |
| kgunn | jdstrand: this is my server yaml | 14:38 |
| kgunn | http://bazaar.launchpad.net/~mir-team/+junk/mir-server-snap/view/head:/snapcraft.yaml | 14:38 |
| jdstrand | kgunn: yeah, that's wrong | 14:39 |
| kgunn | jdstrand: btw - i always knew it was backwards from what i was told (which is what's been disturbing me) | 14:39 |
| jdstrand | kgunn: the server should 'slots: [ mir ]' | 14:39 |
| kgunn | jdstrand: damn it! :) | 14:39 |
| jdstrand | kgunn: the slot side provides an implementation of the interface. your mir server snap is an implementation of a mir server | 14:39 |
| jdstrand | kgunn: the server side slots. the client side plugs into the slot to use it | 14:40 |
| jdstrand | kgunn: 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 policy | 14:40 |
| mup | PR snapd#1608 opened: tests: add snapd-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1608> | 14:44 |
| mhall119 | sergiusens: ping, what's the rationale behind stripping common path prefixes when unpacking a tarball in snapcraft? | 14:57 |
| mup | PR snapd#1609 opened: overlord/devicestate: first pass at device registration logic <Created by pedronis> <https://github.com/snapcore/snapd/pull/1609> | 15:26 |
| mup | Bug #1608572 opened: There is no easy way to know what port snapweb is listening to <Snappy:New> <https://launchpad.net/bugs/1608572> | 15:29 |
| kgunn | jdstrand: thanks for that, i always knew it wasn't right, i just didn't think the yaml was wrong...so thanks for helping | 15:33 |
| jdstrand | kgunn: my pleasure! | 15:34 |
| kgunn | jdstrand: and just to be sure...on the client side | 15:34 |
| kgunn | http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/snapcraft.yaml | 15:34 |
| kgunn | that is correct ^ | 15:34 |
| kgunn | right? | 15:34 |
| kgunn | plugs [mir] | 15:35 |
| jdstrand | kgunn: yes, server slots and client plugs | 15:36 |
| kgunn | jdstrand: don't know how i overlooked that all this time | 15:36 |
| kgunn | :-/ | 15:36 |
| jdstrand | well | 15:36 |
| jdstrand | it 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 |
| jdstrand | he is going to be writing another blog entry on creating interfaces I think soon | 15:37 |
| mup | PR snapd#1610 opened: store: soft-refresh discharge macaroon from store when required <Created by matiasb> <https://github.com/snapcore/snapd/pull/1610> | 15:39 |
| mup | PR snapd#1611 opened: tests: add locale-control write spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1611> | 16:20 |
| ogra_ | EEEK! | 16:26 |
| * ogra_ just opened the gnome disk utility on a machine with a lot of snaps installed | 16:26 | |
| mup | PR 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 |
| mup | Bug #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 | ||
| mup | PR 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 | ||
| elopio | kyrofa: josepht: I looked at the code. By fake, I mean just to make sure that shutil.copystat was called. | 19:00 |
| kyrofa | elopio, that doesn't seem overly fragile to you? | 19:00 |
| elopio | mock.patch('shutil.copystat') and that's it. | 19:00 |
| elopio | kyrofa: yes, it is. | 19:00 |
| kyrofa | elopio, but the best option, you think? | 19:00 |
| elopio | so also add a manual test that does chown, builds an os snap, and verifies the ownership. | 19:00 |
| elopio | we 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 |
| kyrofa | elopio, sounds good. How do we document such manual tests? | 19:02 |
| elopio | kyrofa: we have a file called manual-tests.md | 19:02 |
| kyrofa | elopio, oh. How handy! | 19:02 |
| elopio | I 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 |
| josepht | elopio: okay, thanks for the direction :) | 19:09 |
| stokachu | still running into this ugly loop: https://paste.ubuntu.com/21797159/ | 19:10 |
| stokachu | my snapcraft.yaml https://www.irccloud.com/pastebin/B3cVKFT7/ | 19:11 |
| stokachu | it works in snap try mode, but not installing from snap store | 19:11 |
| stokachu | using snapcraft 2.13.1 | 19:11 |
| kyrofa | stokachu, interesting... are there symlinks somewhere in the /home/adam/snap/conjure-up/x1 path? | 19:15 |
| stokachu | kyrofa: only thing i can think of is we use os.makedirs in some areas of the code | 19:16 |
| stokachu | mainly creating directories in ~/.cache/conjure-up if they dont exist | 19:16 |
| stokachu | kyrofa: https://github.com/conjure-up/conjure-up/tree/patch-dl-function this is the branch if you have time to try it out yourself | 19:17 |
| stokachu | does the git source support a branch? | 19:19 |
| kyrofa | stokachu, yes, using the source-branch keyword | 19:20 |
| stokachu | lemme try that, i was trying to remove a wget dep and was pulling master during snapcraft rather than that branch | 19:20 |
| kyrofa | stokachu, this does seem to be coming from your source somewhere, not snapd. I suggest trying to figure out which line exactly is busting | 19:21 |
| stokachu | kyrofa: how do you debug this? | 19:21 |
| kyrofa | stokachu, well first of all, does the application support some sort of --debug flag or something else that would enable stack traces? | 19:22 |
| stokachu | kyrofa: yes | 19:22 |
| kyrofa | stokachu, I'd start there | 19:23 |
| stokachu | heh | 19:23 |
| kyrofa | Can you pastebin the output of `conjure-up -h --debug` (or whatever)? | 19:23 |
| stokachu | that pastebin above was from just running conjure-up -h | 19:24 |
| stokachu | dont worry about it ill try to figure it out on my own | 19:24 |
| stokachu | thanks | 19:24 |
| kyrofa | Sure, but it's still swallowing the trace | 19:24 |
| kyrofa | Okay | 19:24 |
| ogra_ | elopio, oh, which bug is that ? | 19:27 |
| elopio | ogra_: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1605903 | 19:28 |
| mup | Bug #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 |
| elopio | ogra_: could you please document the steps to reproduce that? | 19:28 |
| ogra_ | elopio, sure | 19:30 |
| elopio | ty. | 19: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 |
| ogra_ | *patched | 19:31 |
| elopio | ogra_: 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 involved | 19: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 access | 19:38 |
| ogra_ | happy to do test builds | 19:38 |
| josepht | elopio: 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 root | 19:47 |
| josepht | elopio: a manual test, I mean | 19:47 |
| elopio | josepht: sure, that works. | 19:48 |
| elopio | at 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 |
| kyrofa | I need my new house... internet is sooo flaky out here | 19:50 |
| ogra_ | still not moved ? | 19:50 |
| kyrofa | ogra_, the move has multiple stages :P | 19:50 |
| kyrofa | ogra_, made it across the country, but crashing with in-laws while we're waiting for the house to close | 19:51 |
| kyrofa | Needing to run snapcraft + 30k downloads/occasional complete connection death = kill me now | 19:51 |
| ogra_ | right, you said so in heidelberg ... i thought thaat phase would be over eventually :) | 19:52 |
| kyrofa | Yeah, another month | 19:52 |
| * kyrofa cries | 19:52 | |
| ogra_ | kyrofa, sudo snap install packageproxy ... point your sources.list to localhost:9999 ... | 19:52 |
| elopio | kyrofa: mosh + byobu + canonistack. | 19:53 |
| kyrofa | Hmm... canonistack might be a good idea. As long as it doesn't eat my VM before I'm done with it :P | 19:53 |
| kyrofa | ogra_, what is packageproxy? | 19:54 |
| ogra_ | kyrofa, a snap using approx ... | 19:54 |
| * kyrofa wants a `snap show` command or something | 19:54 | |
| ogra_ | it sets up a local package proxy on your machine, so packages only get downloaded once | 19:54 |
| kyrofa | ogra_, ah, that's handy | 19:55 |
| ogra_ | https://github.com/ogra1/packageproxy | 19:55 |
| kyrofa | ogra_, you should put the cache in SNAP_COMMON now, not SNAP_DATA | 19: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 row | 19:57 |
| kyrofa | ogra_, 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 |
| kyrofa | Oh, nice | 19: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 though | 19:58 |
| ogra_ | in the 15.04 version you could actually manage all aspects of its config with snappy config commands | 19:59 |
| kyrofa | ogra_, ah, right | 20:00 |
| stokachu | kyrofa: so i have juju as a stage-package but i can't get it to run juju version | 20:27 |
| kgunn | ogra_: 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=5 | 20:27 |
| stokachu | thats where it is hanging at | 20:27 |
| kgunn | but now complains no hw description in gagdet | 20:28 |
| kgunn | pointers? | 20:28 |
| stokachu | /snap/conjure-up/x6/usr/bin/juju: 3: exec: juju: Argument list too long | 20:29 |
| kyrofa | kgunn, I think the gadget yaml format changed... | 20:50 |
| invapid | if the source code is updated, how do you make a snap build using the new source code? | 20:51 |
| invapid | just rm -rf stage/ # ?? | 20:52 |
| kyrofa | invapid, if it's just a single part in the snap, run `snapcraft clean <part> && snapcraft` | 20:54 |
| invapid | hmm, must not be snapcrafts fault then | 21:07 |
| kyrofa | invapid, what's happening? | 21:08 |
| invapid | still debugging, but source code changes aren't getting compiled | 21:10 |
| invapid | I assume it's just cached somewhere | 21:10 |
| kyrofa | invapid, even with the clean command I just gave you? | 21:11 |
| invapid | yep | 21:11 |
| kyrofa | Huh... odd. Yeah that will completely remove the source cache that snapcraft keep in parts/<partname>/src | 21:12 |
| mhall119 | kyrofa: sergiusens: https://github.com/snapcore/snapcraft/pull/688 is passing now | 21:12 |
| mup | PR 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 |
| kyrofa | invapid, is the source kept locally? Or is it on the internet somewhere? | 21:12 |
| mup | PR snapd#1446 closed: interfaces/builtin: add dbus-bind interface <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1446> | 21:12 |
| invapid | ahh - the "part" isn't pull from the source being modified | 21:12 |
| invapid | thanks kyrofa figured it out | 21:13 |
| kyrofa | invapid, ah ha! Good deal | 21:13 |
| kgunn | jdstrand: 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 expected | 21:54 |
| kgunn | but there's an aa denail on client for open/read of /usr/share/applications, so i added /usr/share/applications r, to connected plug | 21:55 |
| kgunn | but denial is still there... | 21:55 |
| kgunn | am i missing something | 21:55 |
| kgunn | ? | 21:55 |
| kyrofa | kgunn, did you reinstall the snap after making the plug modification in snapd? | 21:56 |
| kgunn | kyrofa: yep, removed / installed | 21:56 |
| kyrofa | kgunn, yep, that's the length of my knowledge :P | 21:56 |
| kgunn | (even rebooted the vm, cause snapd was pissed :) | 21:56 |
| kyrofa | Hahaha | 21:56 |
| kyrofa | kgunn, how are you testing your dev tree of snapd, by the way? | 21:57 |
| kgunn | kyrofa: https://docs.google.com/document/d/1fhRDn8KkeOICgO3fxDwFbqPmultEuL18ThKaa-pjyzc/ | 21:58 |
| kgunn | granted i'm on a 2 week old image | 21:59 |
| kgunn | (was too lazy to grab the experimental udf and build a new one) | 21:59 |
| kgunn | maybe i should do that now | 21:59 |
| kyrofa | kgunn, that plug isn't in master, right? It's completely new? | 22:01 |
| kgunn | kyrofa: correct...it's the mir interface (which is a perma slot for server, and connected plug for client | 22:03 |
| kgunn | ) | 22:04 |
| kyrofa | kgunn, okay. I was thinking maybe you were hitting the re-execution stuff, but then it wouldn't work at all | 22:04 |
| kgunn | hmm...experimental u-d-f not happy | 22:04 |
| mup | PR snapd#1613 opened: add dbus-app interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 22:05 |
| kgunn | mmm, can't run VM while you run experimental udf | 22:05 |
| jdstrand | kgunn: you would need '/usr/share/applications/ r,' (trailing slash is important) | 23:02 |
| jdstrand | kgunn: but I'm not sure that should be there, but fine to add now and we can discuss in PR | 23:02 |
| jdstrand | kgunn: also, nice! :) | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!