[02:03] <liveuser> Hello. Is this the IRC channel for snapcraft?
[02:03] <liveuser> I want to edit a snap, but it appears to be read-only.
[02:03] <liveuser> This is my first snap, how do I get around this? I need to edit a bash script included in the snap.
[02:04] <liveuser> The internet says run it in "Classic" containment
[02:04] <liveuser> but I have no idea where the snapcraft.yaml is located
[02:04] <liveuser> Also, what happens to the files when I'm examining the hard drive from a live instance?
[02:05] <liveuser> I went into my /snap directory, found the program, and the directory is empty
[02:05] <liveuser> This is a lot of effort just to edit a bash script. :c
[02:56] <mz_> I have installed snapd, snapcraft.　Then installed snap package hello-word.But when run "hello-world.env",output "command not find",why?
[04:00] <mwhudson> mz_: you might need to log out and in again to get /snap/bin on $PATH?
[06:44] <zyga> good morning
[06:48]  * zyga slowly tunes into Polish weather and timezone
[07:00] <mup> PR snapd#3578 closed: store: talk to api.snapcraft.io for purchases <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3578>
[09:25] <davidcalle> elopio: for you to have a look https://github.com/canonical-websites/tutorials.ubuntu.com/pull/283
[09:29]  * zyga -> breakfast
[09:58]  * Chipaca needs more coffee today
[10:00] <mvo> pstolowski: hey, we do generate the snapctl cookies on startup now in master, right? I was doing the following: "snap run --shell hello && snapctl get foo" but I get an "invalid snap cookie requested" error. is this expected?
[10:04] <pstolowski> mvo, hey, yes, this change landed in master. snapd generates them if missing. so no, that's not expected
[10:05] <mvo> pstolowski: ok, I dig a bit to see what is going on
[10:05] <pstolowski> mvo, i'm looking at this too, may have a few questions in a sec
[10:05] <mvo> pstolowski: but the usage above should work, right? i.e. if I run inside the snap environment I should be able to use snapctl get?
[10:06] <mvo> pstolowski: fwiw, I see snap-cookies in the state
[10:06] <mvo> pstolowski: including one for "hello"
[10:11] <mvo> pstolowski: meh, it maybe that I have not everything updated to master, looks my snap-confine is too old
[10:11] <pstolowski> mvo, hmm wait, the snapctl.. part is not run the context of the hello snap, is it?
[10:12] <mvo> pstolowski: it should be, snap run --shell hello should give me the exact environment that "hello" would run in. but like I said, I tink my snap-confine is out-of-date
[10:13] <pstolowski> mvo, one other thing to check is if /var/lib/snapd/cookie/ has a cookie file for hello snap (both snap-cookies and /var/lib/snapd/cookie should be in sync)
[10:22] <mup> PR snapd#3549 closed: many: expose services commands for snap services <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3549>
[10:22] <mup> PR snapd#3552 closed: daemon: implement service commands <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3552>
[10:22] <mup> PR snapd#3554 closed: client: wrap services calls <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3554>
[10:24] <mvo> pstolowski: yep, sorry for the noise, all is fine, I my system was not using master for everything
[10:25] <pstolowski> mvo, np, good to hear it's fine, thanks
[10:27] <davidcalle> Saviq: for you https://github.com/canonical-websites/developer.ubuntu.com/pull/305
[10:32] <pstolowski> davidcalle, hi David!
[10:33] <davidcalle> pstolowski: hey o/
[10:33] <davidcalle> (on my way to lunch, but I'm around)
[10:34] <pstolowski> davidcalle, fyi, we have just landed support for install & remove hooks in snapd master. and some more hooks are in the pipeline and will probably land in next few weeks
[10:34] <pstolowski> davidcalle, so we may need to update the docs
[10:36] <davidcalle> brilliant!
[10:37] <Saviq> davidcalle, ack!
[11:59] <mup> PR snapd#3586 opened: client, daemon: rest api to reconfigure snapd with a custom store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3586>
[12:00]  * zyga -> break
[12:01] <Son_Goku> what wait
[12:03] <Son_Goku> niemeyer: what is snapd#3586?
[12:03] <mup> PR snapd#3586: client, daemon: rest api to reconfigure snapd with a custom store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3586>
[12:03] <Son_Goku> dare I hope that this means arbitrary stores could be configured without patching and recompiling snapd?
[12:07] <niemeyer> Son_Goku: This is about hosting of local stores in environments that can't talk to the open net
[12:08] <niemeyer> It's a sort of proxy pretty much, and changes the system altogether, so won't be very good at handling what you describe.. at least not yet
[12:10] <Son_Goku> niemeyer: I see
[12:22] <davidcalle> pstolowski: what are the other hooks?
[12:22] <zyga> re
[12:23] <davidcalle> (in the pipeline, I mean)
[12:24] <pstolowski> davidcalle, in the pipeline: refresh hook and interface hooks (executed when you 'snap connect ..' 2 snaps)
[12:24] <davidcalle> ty
[12:25] <davidcalle> pstolowski: I'll send you a PR to look over the doc update (probably not before tuesday, though)
[12:26] <pstolowski> davidcalle, sure. keep in mind this stuff just started landing and it will become available in next release(s)
[12:27] <davidcalle> pstolowski: +1
[12:27] <pstolowski> davidcalle, so a few weeks away i suppose. nb, i'll be off for next 2 weeks
[12:29] <davidcalle> pstolowski: I'll be off for three weeks in 10 days, but we'll manage something ;)
[12:29] <ogra_> three weeks!
[12:30] <ogra_> vive la france ? :)
[12:30] <davidcalle> Ahaha
[12:30] <Chipaca> ogra_: we get twenty something days too (but the custom here is to not take them all together)
[12:31] <ogra_> yeah
[12:32]  * davidcalle raises his 2y and 3y old kids card
[12:54] <zyga> 2017-07-13T14:46:32+02:00 ERROR cannot create alias symlink: symlink etcd.etcdctl /snap/bin/etcdctl: file exists
[12:54] <zyga> hmmm
[13:27]  * zyga happily switches to the interfaces branch
[13:28] <zyga> at least something I can bash and smash _and_ see a result
[13:29] <cachio> mvo, some change introducing in 2.26 is making tests fail when we do "systemctl stop snapd.service snapd.socket"
[13:29] <cachio> mvo, I'll research it
[13:30] <zyga> mvo, niemeyer: question about the idea to use and release "RC"s rather than releases, what will the core snap version look like then?
[13:30] <ogra_> same as the final one, no ?
[13:31] <ogra_> after all the version doesnt get modified when core migrates from beta->candidate->stable
[13:31] <mvo> cachio: thank you - where do you see that?
[13:31] <niemeyer> I don't have a strong opinion.. if we intend to release the same build assuming the candidate "tastes good" we'll need to preserve the final version on it though
[13:31] <niemeyer> What ogra_ said, basically
[13:31] <cachio> mvo, two builds failed on master
[13:31] <ogra_> i guess it would simply just be ahead one version bump
[13:31] <zyga> yes
[13:32] <zyga> though that looks "less nice"
[13:32] <cachio> mvo, this is the last one https://travis-ci.org/snapcore/snapd/builds/253090762#L3796
[13:32] <ogra_> while edge is jumping between git and release versions as needed
[13:32] <zyga> maybe we could alter the version in a snap revision assertion?
[13:32] <zyga> (purely presentation-wise)
[13:33] <ogra_> do you really think people look at it that much that it is worth it ?
[13:33] <mvo> cachio: hm, "Job for snaps.service canceled" is a bit dry as an error message :/
[13:33] <zyga> ogra_: not on core
[13:33] <zyga> ogra_: but maybe, not sure
[13:33] <ogra_> i'd say also not on classic ... except when they run snap --version to copy/paste that into bugs :)
[13:33] <cachio> mvo, yes, it started yesterday and it happened on different tests
[13:34] <cachio> mvo, trying to reproduce it now
[14:46]  * zyga tried to write "spans" and kept typing "snaps"
[14:50] <Chipaca> zyga: snaps span pan-sass pans
[14:52] <ogra_> schnaps !
[14:53] <Chipaca> ogra_: a bit early for me
[14:53] <ogra_> but helps to get things back in order ;)
[14:54] <ogra_> (or totally out of order ... a matter of volumes ... )
[15:05] <Pharaoh_Atem> so... snapd-glib 1.15 for fedora, thanks to robert-ancell:
[15:05] <Pharaoh_Atem> * F24: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5d326072db
[15:05] <Pharaoh_Atem> * F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f3da5ab6fc
[15:05] <Pharaoh_Atem> * F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8ba37dcc1c
[15:19]  * zyga dinner
[15:21] <mvo> fwiw, I branched 2.27 now and will update the forum topic
[15:21] <mvo> if anyone absolutely needs something in 2.27 shout!
[15:23] <Pharaoh_Atem> mvo: do we have an upstream changelog for 2.27 yet?
[15:23] <Pharaoh_Atem> I figured I'd experiment with shipping an upstream-ish changelog entry in the package changelog
[15:24] <mvo> Pharaoh_Atem: I will write a short (highlights) changelog into the forum soon, the auto-generated one is part of debian/changelog, I will push the branch in a little bit
[15:24] <Pharaoh_Atem> mvo: I was wondering if maybe we should also push a variant of that into the fedora spec
[15:24] <mvo> its based on current master, so the new install/remove hooks are part of it (thanks to pstolowski)
[15:25] <mvo> Pharaoh_Atem: sure, I can do that, its mostly automatic, I will need to look at how changelogs work in spec files :)
[15:26] <Pharaoh_Atem> they're pretty simple :)
[15:26] <Pharaoh_Atem> I'm guessing though that you probably don't have rpmdevtools on your computer, right?
[15:27] <Pharaoh_Atem> https://build.opensuse.org/package/show/home:Pharaoh_Atem:debrpm/rpmdevtools :)
[15:27] <mvo> Pharaoh_Atem: apt list rpmdevtools gives me an empty list
[15:29] <mvo> Pharaoh_Atem: how does http://paste.ubuntu.com/25082523/ look?
[15:29] <mvo> Pharaoh_Atem: hm, not good at all I suppose, missing the date and revision, right?
[15:29] <mvo> eh version
[15:29] <Pharaoh_Atem> yeah
[15:29] <Pharaoh_Atem> you're missing the header
[15:29] <Pharaoh_Atem> note the entry below yours
[15:29] <mvo> Pharaoh_Atem: yeah
[15:30] <Pharaoh_Atem> you can also indent multiple levels
[15:30] <Pharaoh_Atem> changelogs are mostly freeform
[15:30] <mvo> Pharaoh_Atem: how do you guys represent "rc" versions. 2.27~rc1 ?
[15:30] <Pharaoh_Atem> officially, Fedora uses 0.rc1.1 in the Release field
[15:30] <Pharaoh_Atem> but you can use ~rc1
[15:30] <Pharaoh_Atem> that's totally acceptable
[15:31] <Pharaoh_Atem> and in fact, I'm okay with that
[15:31] <Pharaoh_Atem> so just use 2.27~rc1 and leave the Release value at 0%{?dist}
[15:31] <mvo> Pharaoh_Atem: so http://paste.ubuntu.com/25082538/ ?
[15:31] <Pharaoh_Atem> so the changelog entry version would be 2.27~rc1-0
[15:31] <Pharaoh_Atem> looks good
[15:31] <Pharaoh_Atem> though I think you're the author :)
[15:32] <mvo> Pharaoh_Atem: aha, so this is the author, not the uploader? sure, I can fix the field
[15:32] <Pharaoh_Atem> it can be either
[15:32] <Pharaoh_Atem> but I prefer author of change :)
[15:32] <Pharaoh_Atem> besides, I'll just have a 2.27-1 entry when I release into Fedora :)
[15:32] <mvo> Pharaoh_Atem: sounds good
[15:32] <zyga> re
[15:32] <mvo> Pharaoh_Atem: thanks for your help! I
[15:33] <Pharaoh_Atem> np
[15:33] <Pharaoh_Atem> this is my particular experiment with having upstream changelogs along with maintainer ones
[15:33]  * zyga hugs both Pharaoh_Atem and mvo 
[15:33] <Pharaoh_Atem> historically speaking, I've never been a fan of them, but enough people ask for them now that I'll see how it plays out
[15:34] <mvo> Pharaoh_Atem: sure, I will keep this in mind (or try) - just let me know if the experiment does not pan out
[15:34] <mvo> (and you want the short maintainer ones back)
[15:35] <Pharaoh_Atem> mvo: My preference would be that you'd do the following structure for the entry
[15:35] <Pharaoh_Atem> * @DATE@ @AUTHOR@ - @VERSION@
[15:35] <Pharaoh_Atem> - New release
[15:35] <Pharaoh_Atem>   - Entry details
[15:35] <Pharaoh_Atem> you can indent freeform just like you do with debian changelogs
[15:35] <Pharaoh_Atem> the idea is to just make it clear
[15:35] <Pharaoh_Atem> and adjust the Version: tag to be the same as @VERSION@ :)
[15:36] <Pharaoh_Atem> I still plan on using the highlights for the updateinfo data used for bodhi updates
[15:36] <mup> PR snapd#3587 opened: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3587>
[15:37] <Pharaoh_Atem> mvo: is that alright with you?
[15:38] <mvo> Pharaoh_Atem: sure!
[15:38] <Pharaoh_Atem> we can tweak as needed going forward
[15:38] <Pharaoh_Atem> I think that as long as the entries are prepared alongside, it'll go pretty well
[15:39] <zyga> wa
[15:39] <zyga> :w
[15:39] <mvo> Pharaoh_Atem: https://github.com/snapcore/snapd/blob/release/2.27/packaging/fedora/snapd.spec#L638 I pressume?
[15:39] <mvo> zyga: :!
[15:39] <Pharaoh_Atem> :)
[15:39] <Pharaoh_Atem> perfect
[15:39] <Pharaoh_Atem> mvo: you can also adjust the version field: https://github.com/snapcore/snapd/blob/release/2.27/packaging/fedora/snapd.spec#L51
[15:40] <Pharaoh_Atem> unless you don't plan on tagging 2.27~rc3
[15:44] <Pharaoh_Atem> mvo: could you also adjust the Version field?
[15:45] <Pharaoh_Atem> something I'm thinking of trying is having COPR track branches to offer pre-release builds from Git directly
[15:46] <Pharaoh_Atem> no biggie if you don't want to, though
[15:46] <Pharaoh_Atem> I'm can just track myself
[15:52] <mvo> Pharaoh_Atem: aha, the version is not taken automatically from the changelog?
[15:52] <Pharaoh_Atem> mvo: nope
[15:53] <Pharaoh_Atem> in fact, you can leave the version off entirely and put it in the changelog text
[15:53] <mvo> Pharaoh_Atem: ok, updating this
[15:53] <Pharaoh_Atem> some people prefer that
[15:53] <Pharaoh_Atem> again, I debate about it myself
[15:53] <Pharaoh_Atem> technically, RPM is actually only aware of @DATE@ @AUTHOR
[15:53] <Pharaoh_Atem> err @AUTHOR@
[15:53] <mvo> Pharaoh_Atem: hm, ok. no idea :) if I can leave it off, thats nice because it means less things to remember
[15:54] <Pharaoh_Atem> mvo: if you do that, please put it in the changelog text :)
[15:54] <Pharaoh_Atem> it helps so people know what it's associated with
[15:54] <Pharaoh_Atem> so you can do "New upstream release 2.27~rc3"
[15:54] <Pharaoh_Atem> which is probably okay for both Debian and Fedora changelogs
[15:57] <mvo> Pharaoh_Atem: sounds good. updated. I think its ok to now upload this just yet to fedora I hope we have a real 2.27 early next week
[15:57] <Pharaoh_Atem> awesome
[15:58] <Pharaoh_Atem> mvo: sorry if I seem like I'm being picky, but I'm excited that with Fedora actually plugged into the CI (admittedly not doing a lot), it'd be nice if it was also bumped in a similar manner for releases
[15:59] <Pharaoh_Atem> mvo: hold on
[15:59] <Pharaoh_Atem> this is wrong
[15:59] <Pharaoh_Atem> https://github.com/snapcore/snapd/commit/9610a9260e80cd059394d9ef5c729f5698064ef1
[15:59] <Pharaoh_Atem> the Version: does need to be filled in
[15:59] <Pharaoh_Atem> I meant that
[15:59] <Pharaoh_Atem> * Thu Jul 13 2017 Michael Vogt <mvo@ubuntu.com> [ - 2.27~rc3 ]<= not mandatory
[16:00] <Pharaoh_Atem> I misunderstood you
[16:00] <Pharaoh_Atem> Version: is mandatory
[16:00] <Pharaoh_Atem> the version in the changelog entry header is not
[16:00] <mvo> Pharaoh_Atem: aha, ok
[16:00] <Pharaoh_Atem> rpm doesn't use that at all for anything
[16:00] <mvo> Pharaoh_Atem: let me fix that
[16:00] <Pharaoh_Atem> mvo: sorry for that :)
[16:02]  * Pharaoh_Atem sighs in relief
[16:02] <Pharaoh_Atem> mvo: awesome, now it's right
[16:03] <mup> PR snapcraft#1404 closed: cleanbuild: ensure we enter a shell on failures on --debug <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1404>
[16:35] <mup> PR snapd#3588 opened: tests: fix how package lists are updated for opensuse and fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3588>
[16:38] <zyga> Pharaoh_Atem: can you have a look at ^
[16:38] <zyga> Pharaoh_Atem: it smells like that metadata-update you mentioned
[17:33] <mup> PR snapcraft#1357 closed: tests: do not break a systems `bzr whoami` <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1357>
[17:51] <noise][> FYI, we are having an issue with snap downloads, investigating
[17:52] <pstolowski> niemeyer, wrt #3569 when writing the tests I found out that some of the unmarshall -> decoder+usenumber change were not actually needed, so I reverted them. moreover, I found that the changes to state.go are most likely not needed either - the end-to-end spread test execute without state.go changes proves that, however one unit test disagrees and I need to understand why, but probably it's a problem with how this unit test is implemented
[17:53] <pstolowski> niemeyer, long story short.. the change may become 2x shorter and a single problematic unit test led me to some dead ends
[17:53] <niemeyer> pstolowski: Nice, that's good news I guess
[17:54] <niemeyer> pstolowski: Why are those cases not needed?
[17:54] <niemeyer> pstolowski: Without digging in much, it felt like a good thing that we were preserving the numbers as originally fed
[17:56] <pstolowski> niemeyer, they apparently don't affect the data format (thanks to json.RawMessage I guess?). the critical part is snap-get/snapctl-get and config/transaction
[18:02] <pstolowski> it's getting late here.. ttyt o/
[19:11] <Pharaoh_Atem> mvo: what's this "profilese" you speak of? :P https://github.com/snapcore/snapd/commit/7cb1b27c546bce219114010fe9c8f4d0e6a48071
[19:45] <davidcalle> elopio: https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-travis-ci
[22:14] <mwhudson> is chipaca on leave currently?