| 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:03 |
| 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:04 |
| 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:05 |
| mz_ | I have installed snapd, snapcraft.　Then installed snap package hello-word.But when run "hello-world.env",output "command not find",why? | 02:56 |
| === elfgoh_ is now known as elfgoh | ||
| mwhudson | mz_: you might need to log out and in again to get /snap/bin on $PATH? | 04:00 |
| zyga | good morning | 06:44 |
| * zyga slowly tunes into Polish weather and timezone | 06:48 | |
| 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> | 07:00 |
| === JanC_ is now known as JanC | ||
| davidcalle | elopio: for you to have a look https://github.com/canonical-websites/tutorials.ubuntu.com/pull/283 | 09:25 |
| * zyga -> breakfast | 09:29 | |
| === chihchun_afk is now known as chihchun | ||
| * Chipaca needs more coffee today | 09:58 | |
| 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:00 |
| pstolowski | mvo, hey, yes, this change landed in master. snapd generates them if missing. so no, that's not expected | 10:04 |
| 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:05 |
| mvo | pstolowski: fwiw, I see snap-cookies in the state | 10:06 |
| mvo | pstolowski: including one for "hello" | 10:06 |
| === matteo` is now known as matteo | ||
| 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:11 |
| 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:12 |
| 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:13 |
| 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:22 |
| mvo | pstolowski: yep, sorry for the noise, all is fine, I my system was not using master for everything | 10:24 |
| pstolowski | mvo, np, good to hear it's fine, thanks | 10:25 |
| davidcalle | Saviq: for you https://github.com/canonical-websites/developer.ubuntu.com/pull/305 | 10:27 |
| pstolowski | davidcalle, hi David! | 10:32 |
| davidcalle | pstolowski: hey o/ | 10:33 |
| davidcalle | (on my way to lunch, but I'm around) | 10:33 |
| 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:34 |
| davidcalle | brilliant! | 10:36 |
| Saviq | davidcalle, ack! | 10:37 |
| 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> | 11:59 |
| * zyga -> break | 12:00 | |
| Son_Goku | what wait | 12:01 |
| 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:03 |
| niemeyer | Son_Goku: This is about hosting of local stores in environments that can't talk to the open net | 12:07 |
| 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:08 |
| Son_Goku | niemeyer: I see | 12:10 |
| davidcalle | pstolowski: what are the other hooks? | 12:22 |
| zyga | re | 12:22 |
| davidcalle | (in the pipeline, I mean) | 12:23 |
| pstolowski | davidcalle, in the pipeline: refresh hook and interface hooks (executed when you 'snap connect ..' 2 snaps) | 12:24 |
| davidcalle | ty | 12:24 |
| davidcalle | pstolowski: I'll send you a PR to look over the doc update (probably not before tuesday, though) | 12:25 |
| pstolowski | davidcalle, sure. keep in mind this stuff just started landing and it will become available in next release(s) | 12:26 |
| davidcalle | pstolowski: +1 | 12:27 |
| pstolowski | davidcalle, so a few weeks away i suppose. nb, i'll be off for next 2 weeks | 12:27 |
| davidcalle | pstolowski: I'll be off for three weeks in 10 days, but we'll manage something ;) | 12:29 |
| ogra_ | three weeks! | 12:29 |
| 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:30 |
| ogra_ | yeah | 12:31 |
| * davidcalle raises his 2y and 3y old kids card | 12:32 | |
| 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 | 12:54 |
| * zyga happily switches to the interfaces branch | 13:27 | |
| zyga | at least something I can bash and smash _and_ see a result | 13:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| cachio | mvo, trying to reproduce it now | 13:34 |
| * zyga tried to write "spans" and kept typing "snaps" | 14:46 | |
| Chipaca | zyga: snaps span pan-sass pans | 14:50 |
| ogra_ | schnaps ! | 14:52 |
| Chipaca | ogra_: a bit early for me | 14:53 |
| ogra_ | but helps to get things back in order ;) | 14:53 |
| ogra_ | (or totally out of order ... a matter of volumes ... ) | 14:54 |
| 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:05 |
| === chihchun is now known as chihchun_afk | ||
| * zyga dinner | 15:19 | |
| 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:21 |
| 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:23 |
| 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:24 |
| mvo | Pharaoh_Atem: sure, I can do that, its mostly automatic, I will need to look at how changelogs work in spec files :) | 15:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| Pharaoh_Atem | mvo: is that alright with you? | 15:37 |
| 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:38 |
| 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:39 |
| Pharaoh_Atem | unless you don't plan on tagging 2.27~rc3 | 15:40 |
| Pharaoh_Atem | mvo: could you also adjust the Version field? | 15:44 |
| Pharaoh_Atem | something I'm thinking of trying is having COPR track branches to offer pre-release builds from Git directly | 15:45 |
| Pharaoh_Atem | no biggie if you don't want to, though | 15:46 |
| Pharaoh_Atem | I'm can just track myself | 15:46 |
| mvo | Pharaoh_Atem: aha, the version is not taken automatically from the changelog? | 15:52 |
| Pharaoh_Atem | mvo: nope | 15:52 |
| 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:53 |
| 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:54 |
| 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:57 |
| 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:58 |
| 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 | 15:59 |
| 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:00 |
| * Pharaoh_Atem sighs in relief | 16:02 | |
| Pharaoh_Atem | mvo: awesome, now it's right | 16:02 |
| 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:03 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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:35 |
| zyga | Pharaoh_Atem: can you have a look at ^ | 16:38 |
| zyga | Pharaoh_Atem: it smells like that metadata-update you mentioned | 16:38 |
| 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:33 |
| noise][ | FYI, we are having an issue with snap downloads, investigating | 17:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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 | 17:56 |
| pstolowski | it's getting late here.. ttyt o/ | 18:02 |
| === rumble is now known as grumble | ||
| Pharaoh_Atem | mvo: what's this "profilese" you speak of? :P https://github.com/snapcore/snapd/commit/7cb1b27c546bce219114010fe9c8f4d0e6a48071 | 19:11 |
| davidcalle | elopio: https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-travis-ci | 19:45 |
| mwhudson | is chipaca on leave currently? | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!