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