| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1231 closed: pluginhandler: exclude `/snap/` from libraries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1231> | 01:50 |
|---|---|---|
| mup | PR snapcraft#1232 opened: nodejs plugin: switch to the newer LTS. (#1228) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1232> | 01:53 |
| mup | PR snapcraft#1233 opened: docs: update contribution guide <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1233> | 01:59 |
| Haxxa | Should I be using snap? Is it like docker or lxc? | 02:08 |
| mup | PR snapcraft#1234 opened: core: find the correct libraries as a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1234> | 02:17 |
| mup | PR snapd#3142 opened: daemon: Give the snap directories via GET /v2/system-info <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3142> | 02:53 |
| mup | PR snapcraft#1232 closed: nodejs plugin: switch to the newer LTS. (#1228) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1232> | 03:32 |
| _28Kb | can I list core interfaces and stuff to mess with im my ubuntu core 16? | 03:34 |
| _28Kb | I want to do some code and make my own snaps... how do I find those "system variables" that I want to call and controll? | 03:37 |
| _28Kb | to tell my core: do that and then that.. | 03:39 |
| _28Kb | and snacraft is not actually a snap? | 03:48 |
| _28Kb | snapcraft* | 03:48 |
| _28Kb | snap help | 03:49 |
| niemeyer | Forum going down for an update... please assume crash landing position. | 04:02 |
| niemeyer | We've landed successfully. Please calmly return to your cell phones. | 04:14 |
| morphis | robert_ancell: ping | 05:01 |
| robert_ancell | morphis, hi | 05:01 |
| morphis | robert_ancell: thanks for doing those changes! | 05:01 |
| robert_ancell | np | 05:01 |
| morphis | robert_ancell: just commented on the bug | 05:03 |
| robert_ancell | morphis, weird, is that the query you were doing from inside g-s? | 05:03 |
| morphis | robert_ancell: but why do we have extra code in gnome-software to query snapd? | 05:03 |
| morphis | robert_ancell: yes | 05:04 |
| morphis | let me give this another try | 05:04 |
| robert_ancell | morphis, it existed before snapd-glib existed and I haven't switched all the functions over yet (there seems to be a weird interaction with the g-s threading model I haven't solved) | 05:04 |
| morphis | ah ok | 05:05 |
| robert_ancell | morphis, so weird your g-s did a short read. Your response is the same length as mine. | 05:06 |
| robert_ancell | I'll have another look tomorrow | 05:06 |
| morphis | robert_ancell: tried it again now in my 17.04 VM and now it works with gnome-software | 05:06 |
| morphis | robert_ancell: I now removed rocket-chat and installed through gnome-software again and get the truncated message again | 05:07 |
| robert_ancell | morphis, this is 17.04 with standard snapd? | 05:07 |
| morphis | with 2.23.6 | 05:08 |
| morphis | robert_ancell: but I can debug through this a bit over my day | 05:09 |
| robert_ancell | morphis, cool | 05:10 |
| robert_ancell | gtg, bye all! | 05:10 |
| morphis | robert_ancell: bye! | 05:10 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 06:15 |
| zyga | mvo: hello | 06:16 |
| mvo | hey zyga - good morning | 06:17 |
| zyga | mvo: I just re-triggered tests on https://github.com/snapcore/snapd/pull/3126 (they failed on github connectivity before), once those land I will do another pass at merging master into open branches | 06:19 |
| mup | PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126> | 06:19 |
| zyga | mvo: yesterday's exercise was worthwhile as most open PRs got green | 06:19 |
| zyga | mvo: still, I have a question about one particular problem: | 06:19 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/3140 | 06:19 |
| mup | PR snapd#3140: overlord: increase prune test wait by x10 <Created by zyga> <https://github.com/snapcore/snapd/pull/3140> | 06:19 |
| zyga | mvo: I attempted a naive "fix" for this racy test | 06:19 |
| zyga | mvo: but was surprised when it just failed again after making it wait x10 longer | 06:20 |
| zyga | mvo: do you think it is worth mocking time all the way so that it is reliable? | 06:20 |
| zyga | mvo: or finding another approach at making it fail less | 06:20 |
| zyga | mvo: (it consistently fails in many PRs) | 06:20 |
| mvo | zyga: I have a look, I'm not really sure what the best course of action is | 06:22 |
| mvo | zyga: but I did notice that its one of the culprits for a lot of the failures too | 06:23 |
| zyga | mvo: maybe it could run in a loop | 06:23 |
| zyga | mvo: and any out of N tries could succeed | 06:23 |
| zyga | mvo: what surprised me is that making the timer longer has caused the test to fail everywhere in that particular run | 06:23 |
| zyga | mvo: did I misunderstand something about it? I would assume the opposite behavior | 06:24 |
| mvo | zyga: I need to look at the test, but we have one test that checks that purge happens only after a specific time, i.e. wait a little bit: change still there, wait a bit more: change gone - maybe it was this test, I need to look at it though to be sure | 06:25 |
| zyga | mvo: thanks, let me know when you chceked that | 06:26 |
| mvo | zyga: right after I finished my open review tabs :) | 06:27 |
| zyga | mvo: did you see this failure: | 06:55 |
| zyga | Apr 04 13:31:57 autopkgtest /usr/lib/snapd/snapd[13737]: hookmgr.go:380: DEBUG: Cannot report hook failure: cannot upload error report, return code: 500 | 06:55 |
| zyga | mvo: should we try to upload error reports in spread runs? | 06:55 |
| mvo | zyga: we should not, there is code that prevents this (i.e. checks if its run under spread). but we had a bug there before (some test nuked the snapd systemd config). maybe we have it again :/ | 06:56 |
| zyga | mvo: it seems so | 06:56 |
| zyga | mvo: but when you wrote that test, would it just fake the upload but say it did upload anyway | 06:56 |
| zyga | mvo: or would it skip the upload and the message entirely? | 06:57 |
| zyga | mvo: I prepared a tiny patch for this but I'm not sure if it should be sent: | 06:57 |
| zyga | http://paste.ubuntu.com/24318730/ | 06:57 |
| mvo | zyga: thanks, checking | 06:59 |
| mvo | zyga: aha, I think I found the issue, the wrong spot is checking for the snappy_testing :/ let me fix that | 07:00 |
| mvo | zyga: thanks for discovering! | 07:00 |
| zyga | mvo: perfect, thanks! | 07:01 |
| zyga | mvo: what's curious is that it fails infrequently | 07:01 |
| zyga | mvo: so we either submit most error reports successfuly | 07:01 |
| zyga | mvo: or something else is wrong | 07:01 |
| mvo | zyga: the normal snap install failures are all skipped, just the new hook failure stuff is not doing that :/ so its only very few tests plus daisy is usually reliable | 07:03 |
| zyga | mvo: so will the test stay as-is and we just print the message that the report got sent but not really send anything? | 07:03 |
| tvoss | mvo: after a quick chat with tyhicks yesterday, he would appreciate your feedback/commitment on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1660550. Once we have that, we can continue the MIR process | 07:07 |
| mup | Bug #1660550: [MIR] snapd in trusty <snapd (Ubuntu):Incomplete by ubuntu-security> <https://launchpad.net/bugs/1660550> | 07:07 |
| mvo | tvoss: sure, checking | 07:08 |
| tvoss | mvo: thx | 07:09 |
| mvo | updated | 07:10 |
| morphis | zyga, mvo: I've seen https://paste.ubuntu.com/24318373/ this morning when I tried to use snapd on a Ubuntu 16.04.2 live cd | 07:12 |
| tvoss | mvo: ack | 07:12 |
| morphis | zyga, mvo: after doing an apt upgrade though | 07:12 |
| zyga | morphis: looking | 07:26 |
| zyga | morphis: interesting | 07:26 |
| zyga | morphis: not sure if related but live CD has things that make snapd not work | 07:27 |
| zyga | morphis: not sure if it is overlayfs or aufs or something like that | 07:27 |
| zyga | morphis: did you get any apparmor denials for snap-confine? | 07:27 |
| zyga | morphis: if you did that would probably explain it | 07:27 |
| morphis | zyga: didn't checked that but after loading the apparmor profile for snap-confine I got the the libudev error | 07:30 |
| zyga | morphis: do you still have that environment around? | 07:33 |
| zyga | morphis: dmesg | grep DENIED | 07:33 |
| morphis | zyga: its easy to recreate | 07:33 |
| zyga | mvo: I'ld like to land https://github.com/snapcore/snapd/pull/3084 | 07:33 |
| mup | PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084> | 07:33 |
| morphis | but no, don't have it anymore | 07:33 |
| zyga | mvo: has 2 +1s | 07:33 |
| zyga | morphis: ok | 07:33 |
| zyga | morphis: I'll try it out today | 07:33 |
| mvo | zyga: yeah, I was wondering about the foreach() | 07:34 |
| mvo | zyga: otherwise it looks really great | 07:34 |
| morphis | zyga: thanks | 07:34 |
| mvo | zyga: but its not a blocker | 07:34 |
| zyga | mvo: looking at foreach | 07:34 |
| morphis | zyga, mvo: just tell me what you guys prefer, happy to change it again :-) | 07:34 |
| zyga | aha | 07:34 |
| morphis | zyga, mvo: need go for errands now but can change once I am back or do a followup PR | 07:35 |
| zyga | morphis: I think mvo means that the foreach is OK but the particular install command is different | 07:35 |
| zyga | ah | 07:35 |
| zyga | it even means we don't need foreach | 07:35 |
| zyga | yeah, less magic is fine with me ;) | 07:35 |
| zyga | morphis: if you can quickly push that change I'd love to merge it | 07:35 |
| mvo | zyga, morphis: lets just merge it and we do a followup, poor morphis had to do enough in this already :) but I'm super happy about the structure now, I think it looks really nice | 07:38 |
| zyga | mvo: +1 | 07:39 |
| jibel | mvo, morning | 07:39 |
| mvo | hey jibel! good morning | 07:40 |
| jibel | mvo, will you reupload a version of 2.23.6 with the fix for bug 1679616 ? or what is the plan there | 07:40 |
| mup | Bug #1679616: ADT failure in snapd 2.23.6+17.04 <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1679616> | 07:40 |
| jibel | mvo, because currently 2.23.6 is blocked in proposed and it'll block the srus too | 07:40 |
| mvo | jibel: this error should be fixed with the new spread, i.e. we just need to retrigger the adt runs, it should be fine without a new upload | 07:41 |
| mvo | jibel: hm, not sure how to do that for zesty, let me explore | 07:42 |
| jibel | mvo, ah good, can you re-run it please http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd I'm cannot | 07:42 |
| mvo | jibel: sure, let me do that | 07:42 |
| * zyga packs and goes to the library | 07:42 | |
| zyga | see you soon | 07:42 |
| mvo | jibel: done for 17.04 | 07:42 |
| mvo | zyga: enjoy | 07:42 |
| jibel | mvo, thanks! | 07:42 |
| zyga | mvo: can you do a sanity check and merge https://github.com/snapcore/snapd/pull/3126 ; I think it's okay but I want to be on the safe side :) | 07:47 |
| mup | PR snapd#3126: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126> | 07:47 |
| Chipaca | mvo— o/ | 07:50 |
| Chipaca | mvo— about #3141 | 07:50 |
| Chipaca | mvo— I think I'd rather have the current channels be foo/bar instead of having a nested structure | 07:51 |
| Chipaca | mvo— however I suspect ordering is going to be an issue with either approach | 07:52 |
| Chipaca | we can probably ignore ordering for a first pass though | 07:52 |
| Chipaca | hmm | 07:54 |
| === chihchun is now known as chihchun_afk | ||
| mvo | Chipaca: ok, I agree | 07:59 |
| mvo | Chipaca: I will rework :) | 07:59 |
| Chipaca | mvo— hold on | 07:59 |
| mvo | Chipaca: sure | 07:59 |
| Chipaca | mvo— the fact that not all snaps have a channel_maps_list is a blocker in my mind | 07:59 |
| Chipaca | mvo— what're you going to do for snaps that don't? | 08:00 |
| mvo | Chipaca: just use the fakeChannels as before | 08:00 |
| mvo | that was my thinking | 08:00 |
| Chipaca | :-( | 08:00 |
| mvo | and ensure that the store is aware of this cludge | 08:00 |
| mvo | kludge | 08:00 |
| mvo | Chipaca: but either way is fine, I can hold back too. but it seems the workaround is relatively cheap and I would love to land basic support soon(ish) (but maybe thats not wise, I'm just a bit impatient sometimes) | 08:01 |
| Chipaca | mvo— just cc'ed you on an email asking about that | 08:02 |
| Chipaca | mvo— the problem with sending a big fat list is twofold | 08:02 |
| mvo | Chipaca: thank you! | 08:02 |
| mup | PR snapd#3139 closed: tests: run gccgo only on ubuntu-16.04-64 <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3139> | 08:02 |
| Chipaca | mvo— one, it makes printing it nicely grouped by track harder | 08:03 |
| Chipaca | mvo— two, it makes sorting an issue | 08:03 |
| Chipaca | mvo— so, i propose this: keep on having "channels", using foo/bar, but *also* have a *list* of track names | 08:03 |
| Chipaca | tadaaa | 08:03 |
| mup | PR snapd#3084 closed: packaging: use templates for relevant systemd units <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3084> | 08:03 |
| Chipaca | mvo— finally, at least for a little bit, keep having the latest/foo appearing as foo in the channel map (either exclusively, or duplicated, i don't know) | 08:05 |
| mvo | Chipaca: *nod* | 08:05 |
| Chipaca | mvo— my assumption here is that the server knows what it's doing wrt ordering (note the channel map list is a list after all), and follow that order | 08:05 |
| * mvo nods | 08:07 | |
| mvo | Chipaca: thanks, I think this makes sense | 08:07 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | mvo— also it's the cheapest approach :-) | 08:08 |
| mvo | Chipaca: ha! that I also like | 08:08 |
| mup | PR snapd#3143 opened: data/systemd: tweak data/systemd/Makefile to be slightly simpler <Created by mvo5> <https://github.com/snapcore/snapd/pull/3143> | 08:12 |
| mup | PR snapd#3126 closed: store: handle EOF via url.Error check <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3126> | 08:16 |
| pstolowski | thank you! | 08:16 |
| JamieBennett | fgimenez: I want to push out 2.23.6 in the ubuntu-core snap today, can you do a validation of the beta channel please? | 08:21 |
| mvo | Chipaca: I updated the forum post to include what we just discussed, thanks again for your input | 08:21 |
| mvo | pstolowski: thank *you* - really nice work on that branch | 08:21 |
| Chipaca | mvo— I've adjusted to being back on IRC just fine, but not so much to the forum | 08:21 |
| * Chipaca looks | 08:22 | |
| pstolowski | mvo, yw. i hope it helps | 08:22 |
| mvo | Chipaca: no worries - fwiw, I made the forum entry a wiki so you can also edit it if you want/need | 08:22 |
| fgimenez | JamieBennett: sure on it | 08:22 |
| Chipaca | mvo— tweaked it because that's how i roll, but it seems fine | 08:25 |
| fgimenez | JamieBennett: we have rev 1940 of ubuntu-core in the beta channel, is that the version to be validated? | 08:25 |
| renat | Hi, guys=) | 08:26 |
| renat | It's Renat, from Screenly=) | 08:26 |
| morphis | Son_Goku: ping | 08:26 |
| renat | I have a question related to the network_setup_control interface. Do I need any additional interface/permission to run the netplan to generate the config after I update netplan config files? | 08:27 |
| mvo | Chipaca: what can I say | 08:27 |
| mvo | Chipaca: thank you! | 08:27 |
| JamieBennett | fgimenez: just checking now | 08:28 |
| Chipaca | mvo— you're welcome. Also, check your PMs :-) | 08:29 |
| JamieBennett | fgimenez: yes, r1940 | 08:29 |
| JamieBennett | Hey renat, I personally have no idea, maybe mvo knows more about this? | 08:30 |
| Chipaca | renat! | 08:31 |
| Chipaca | renat— did you get the image working? i'm left waiting for it to debug at my end | 08:31 |
| renat | Chipaca, I think - I missed something. The issue with a snapd and gadget snaps installed from the store is not resolved (or, I don't know about it=)) Even signing the model with the store owner's key didn't help=( | 08:33 |
| fgimenez | JamieBennett: thanks will let you know how it goes | 08:33 |
| Chipaca | renat— ack. When yo get around to it, if you send a link to the image our way we'll take a look (ogra and myself) | 08:34 |
| mvo | renat: you should be able to do read/write of netplan config when you have network_setup_control. | 08:34 |
| mvo | renat: did you try it and it did nt work? if so, what kind of denial did oyu get? | 08:34 |
| mvo | renat: you may need the extra network-control iface to actually apply the config though | 08:35 |
| renat | mvo, I didn't try, honestly. Just checked the interface file (network_setup_control.go) and I didn't see anything related to the netplan. network_control seems too poweful to me. | 08:36 |
| renat | I mean, netplan execution. There is only access to the netplan config dir. | 08:37 |
| renat | Hm. network control may do the trick for now, really. Thanks, mvo, I will try! | 08:38 |
| mvo | renat: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_setup_control.go#L27 mentions /etc/netplan but yeah, not netplan the binary | 08:38 |
| Chipaca | mvo— network_setup_control sounds like it should be able to run netplan (i mean, from the name :). Maybe it was an oversight? | 08:40 |
| mvo | Chipaca: worth checking with jdstrand | 08:41 |
| zyga | mvo: you now have conflicts in https://github.com/snapcore/snapd/pull/3111 | 08:43 |
| mup | PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111> | 08:43 |
| mvo | zyga: thanks, I have a look. there is a super strange error in there that kill the network-observer-test | 08:45 |
| zyga | mvo: aha, looking | 08:45 |
| mvo | zyga: which i have not tracked down, I have no idea where this issue comes from, looks like snap-exec gets killed from seccomp for trying to bind | 08:45 |
| mvo | zyga: but how my branch does trigger this is a bit a mystery | 08:45 |
| zyga | mvo: lets land this: https://github.com/snapcore/snapd/pull/3129/files | 08:47 |
| mup | PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129> | 08:47 |
| zyga | mvo: I added a tweak to debug output | 08:47 |
| zyga | mvo: we should be able to see seccomp kills better | 08:47 |
| zyga | mvo: and see what was connected | 08:47 |
| zyga | mvo: if you want I can cherry pick that to a separate branch | 08:47 |
| mvo | zyga: aha, interessting. fwiw, this PR is slightly strange, it seems to mix two things. but yeah, the extra debug output will be very useful | 08:48 |
| zyga | mvo: I added that to chase the failure i saw there | 08:50 |
| zyga | Chipaca: can you please have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170405_014746_f1886@/log.gz | 08:51 |
| zyga | there's a failure in tab completion there | 08:51 |
| zyga | + systemctl stop snapd.service snapd.socket | 08:51 |
| zyga | Job for snapd.service canceled. | 08:51 |
| zyga | ah, sorry | 08:51 |
| zyga | the error is: | 08:51 |
| zyga | + rm testdir/foo.snap bar.snap | 08:51 |
| zyga | rm: cannot remove 'testdir/foo.snap': No such file or directory | 08:51 |
| zyga | Chipaca: probably trivial to address | 08:51 |
| Chipaca | zyga— error in prepare | 08:52 |
| nanodrone | snappy vs flatpak (i came across it just like a few minutes ago), which one is better for a beginner? | 08:53 |
| Chipaca | zyga— that's probably not completion failing | 08:53 |
| zyga | pedronis: there's a failure in TestEnsureRefreshesAlreadyRanInThisInterval here, can you have a look https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170404_110852_3f885@/log.gz | 08:53 |
| zyga | pedronis: if that's just a race please let me know | 08:53 |
| Chipaca | nanodrone— you're asking us, we're going to say snappy :-) | 08:53 |
| fgimenez | mvo: regarding the 2.21 -> edge reexec scenario in spread-cron, after installing the missing debs from the ppa we are getting these errors https://travis-ci.org/snapcore/spread-cron/builds/218741347 iirc those are expected (some required changes haven't landed yet) if you could take a look to confirm that would be great | 08:53 |
| zyga | nanodrone: I think it doesn't matter if you are a beginner or not, it depends on what you want to do | 08:53 |
| zyga | nanodrone: snappy has wider scope | 08:54 |
| Chipaca | zyga— worse, I can't see why prepare failed :-/ | 08:54 |
| nanodrone | flatpak seems like a fedora/redhat project, and snappy seems more debian/ubuntu (i dont know much) | 08:54 |
| mvo | fgimenez: sure, checking | 08:55 |
| nanodrone | where's the snappy hello-world page? | 08:55 |
| zyga | nanodrone: if you trace the money (who is working on a payroll) then that is probably redhat / canonical, respectively but that doesn't matter in any way | 08:55 |
| zyga | nanodrone: everyone makes a living somehow | 08:55 |
| zyga | nanodrone: did you see snapcraft.io? | 08:55 |
| zyga | Chipaca: another interesting failure: we ran out of memory in a test on zesty: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170404_114038_f7ff1@/log.gz | 08:56 |
| zyga | tests/main/interfaces-snapd-control | 08:56 |
| nanodrone | of course. | 08:56 |
| zyga | aha | 08:56 |
| zyga | -- /tmp/go/src/golang.org/x/crypto/ssh/session.gotee: /tmp/autopkgtest.1y2jH6/integrationtests-stderr: No space left on device | 08:56 |
| zyga | no space left on device | 08:56 |
| zyga | may be a test bed failure more than our fault | 08:56 |
| nanodrone | but there's no hello world like flatpak, there should be one dont you think | 08:56 |
| nanodrone | i really liked that they have a hello world page. | 08:57 |
| pedronis | zyga: I don't understand what you are doing with your remark on PRs and failures? | 08:57 |
| zyga | nanodrone: what do you mean a 'hello world' page? | 08:57 |
| nanodrone | it makes it less scary to start learning fast | 08:57 |
| zyga | pedronis: I'm going through all the PRs that have failing tests | 08:57 |
| Chipaca | zyga— http://flatpak.org/hello-world.html | 08:57 |
| zyga | pedronis: and try to figure out what is wrong | 08:57 |
| nanodrone | just look at this and you'll know what i'm trying to say http://flatpak.org/hello-world.html | 08:57 |
| mvo | fgimenez: hm, maybe edge is a tiny bit outdated, we should definitly keep an eye on this though, afaics the last build is yesterday so this is probably ok but lets double check tomorrow | 08:57 |
| zyga | nanodrone: go to https://snapcraft.io/ and scroll to "hello-world" | 08:58 |
| zyga | nanodrone: and then read https://snapcraft.io/create/ | 08:58 |
| zyga | pedronis: some failures are racy tests | 08:58 |
| pedronis | zyga: yes | 08:58 |
| pedronis | so? | 08:58 |
| zyga | pedronis: some failures are buggy code or buggy tests | 08:58 |
| zyga | pedronis: I'm trying to make our tests less broken | 08:59 |
| nanodrone | i already did, but i'm saying shouldn't there be a big hello world link somewhere... | 08:59 |
| fgimenez | mvo: ok thanks | 08:59 |
| nanodrone | like at the very top | 08:59 |
| pedronis | zyga: well, no, I don't understand why you pointed me at that log? is it one my PRs, do you think I can help? I don't remember writing that test | 08:59 |
| Chipaca | nanodrone— the "create" link is at the very top though | 09:00 |
| zyga | nanodrone: I think it depends on who you are, the front page shows you what snaps are and how to use them, we have prominent links to instructions on how to create a snap | 09:00 |
| zyga | pedronis: aha, sorry | 09:00 |
| zyga | pedronis: I assumed you did as it was in the overlord/state engine parts | 09:00 |
| davidcalle | nanodrone: have you seen https://tutorials.ubuntu.com/tutorial/create-first-snap? That's less scary than create | 09:00 |
| davidcalle | (in terms of time investment) | 09:00 |
| nanodrone | no i haven't davidcalle | 09:00 |
| nanodrone | thanks. | 09:00 |
| Chipaca | davidcalle— I think nanodrone's point, which is valid, is that it's not easy to find that page | 09:01 |
| pedronis | zyga: no, I think mvo wrote that bit | 09:01 |
| zyga | pedronis: I see, thanks! | 09:01 |
| davidcalle | Chipaca: there is change coming next week on this front, tutorials being front and center | 09:01 |
| pedronis | zyga: anyway maybe better using a forum posts to collect these? or something, lots of micro pings on these are not helpful | 09:01 |
| davidcalle | Chipaca: nanodrone: so yeah, I fully agree | 09:02 |
| nanodrone | Chipaca, you know those huge COLORED DOWNLOAD links or SIGN UP links you see on websites, that kinda link i'm sure there's an ubuntu theme (?template) we can follow | 09:02 |
| nanodrone | it can be an orange creat/hello world link, super friendly | 09:02 |
| nanodrone | create* | 09:02 |
| Chipaca | nanodrone— the problem is that the snapcraft.io is not only for developers | 09:02 |
| nanodrone | who is it for then | 09:03 |
| Chipaca | so not everybody there will want to jump straight for creation | 09:03 |
| Chipaca | nanodrone— users? system integrators? | 09:03 |
| Chipaca | nanodrone— packagers? | 09:03 |
| zyga | pedronis: yeah, I'll start tracking those on the forum | 09:03 |
| pedronis | zyga: anyway I think most tests with a time.Sleep in them are potentially racy (there's probably only a couple where that is not true) | 09:04 |
| * zyga actually goes to the library now | 09:04 | |
| nanodrone | but i'm a user and a developer and i'm being referred to that site... | 09:04 |
| zyga | pedronis: yeah, I understand | 09:04 |
| zyga | ttyl | 09:04 |
| Chipaca | nanodrone— "not only for X" does not mean "not for X" | 09:05 |
| Chipaca | in any case i look forward to the new thing, davidcalle | 09:05 |
| nanodrone | so it's really broad | 09:05 |
| Chipaca | also i need to get back to work | 09:05 |
| nanodrone | either way i'm packaging using snap now. | 09:06 |
| nanodrone | time already invested. | 09:06 |
| mvo | zyga: happy to help with the test, is that the same prune one we talked about before? | 09:07 |
| pedronis | mvo: no, actually, is a new/modifired test in your refresh schedule branch | 09:07 |
| pedronis | so why zyga pinged me is even more mysterious | 09:07 |
| pedronis | mvo: but yes all Prune tests seem prone to fail because of slowness/raciness | 09:08 |
| mvo | pedronis: yeah, I have that on my list, just wanted to finish some other things first, I will also have a look at my branch failure thing (that is also on my list :) | 09:08 |
| zyga | re | 09:38 |
| zyga | ah, what a great idea to move and work at a library | 09:39 |
| zyga | it's summer all around :) | 09:39 |
| zyga | pedronis: I started the thread as suggested | 09:41 |
| zyga | I could use some reviews on https://github.com/snapcore/snapd/pull/3135 and definitely on https://github.com/snapcore/snapd/pull/3095 | 09:42 |
| mup | PR snapd#3135: interfaces/mount: add high-level Profile functions <Created by zyga> <https://github.com/snapcore/snapd/pull/3135> | 09:42 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 09:42 |
| pedronis | zyga: the issue why we don't mock the time is that the time is checked in a different package | 09:42 |
| morphis | Son_Goku, zyga: ok, I've found the problem why snapd.socket doesn't get enabled on Fedora | 09:43 |
| morphis | Son_Goku, zyga: the rpm macro only calls systemctl preset <unit> | 09:43 |
| morphis | and we don't install any preset file for systemd | 09:43 |
| morphis | so systemctl doesn't know what to do and leaves the units unstarted | 09:43 |
| pedronis | zyga: anyway I think I have an idea that might work for Prune, if it still doesn't work then we try to mock time | 09:44 |
| zyga | pedronis: thank you for the insight, if you comment on the forum I can try to implement your idea | 09:44 |
| zyga | morphis: I think the preset files cannot be installed by any random package, aren't they all collected in one special package? I reacall we got a pull request accepted there that aded snapd.socket and snapd.refresh.timer | 09:45 |
| zyga | morphis: and if I systemctl status snapd.socket it does say vendor preset: enabled | 09:45 |
| zyga | morphis: I'm installing Fedora 24 Server now, let's see what we get there | 09:46 |
| morphis | zyga: yeah its there | 09:46 |
| morphis | in /usr/lib/systemd/system-presets/90-default.preset | 09:46 |
| morphis | zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367932 | 09:46 |
| zyga | morphis: so I don't think I understand your comment, let me re-read | 09:47 |
| zyga | morphis: so we don't install any preset file, yes | 09:47 |
| zyga | morphis: should we? | 09:47 |
| morphis | no | 09:48 |
| morphis | its done by the system | 09:48 |
| morphis | and snapd.socket is already | 09:48 |
| morphis | if you install snapd you need to reboot, then snapd.socket is started | 09:48 |
| zyga | morphis: aha | 09:48 |
| zyga | morphis: so is this a bug in the preset system or in our %post script/ | 09:48 |
| morphis | but wondering if we're allowed to do systemctl start snapd.socket | 09:48 |
| morphis | zyga: presets only allow enable/disable as far as I know | 09:48 |
| morphis | https://www.freedesktop.org/software/systemd/man/systemd.preset.html | 09:49 |
| zyga | morphis: aha | 09:50 |
| zyga | morphis: let's ask what Son_Goku thinks, we can also ask for advice on the fedora mailing list | 09:50 |
| morphis | yeah that would be my next step, hardcoding a `systemctl start snapd.socket` in the spec file doesn't sound great | 09:51 |
| morphis | but let me see if I find other examples | 09:51 |
| zyga | morphis: I think it is not allowed | 09:51 |
| morphis | yeah most likely | 09:54 |
| morphis | zyga: ok, looks like this is the default, you need to reboot to get the service active, no direct start | 09:58 |
| morphis | zyga: same happens for lircd.socket for example | 09:58 |
| zyga | morphis: aha | 10:03 |
| zyga | morphis: we can say something like that in %post maybe, is there a way to signal this to the user? | 10:03 |
| morphis | zyga: not sure, asking on fedora-devel now | 10:05 |
| morphis | as even https://fedoraproject.org/wiki/Packaging:DefaultServices isn't saying anything about this | 10:05 |
| morphis | but would expect on systems like a server you want services to run out of the box after installation without manual work | 10:05 |
| pedronis | zyga: posted some diff pastebin in the forum | 10:06 |
| zyga | pedronis: thanks! | 10:06 |
| zyga | morphis: FYI, rebooting on f24 doesn't start the socket | 10:14 |
| zyga | morphis: vendor preset is disabled | 10:15 |
| morphis | zyga: can you check /usr/lib/systemd/system-presets/80-default.preset? | 10:15 |
| morphis | zyga: looks like they only submitted packages for 25 with https://bugzilla.redhat.com/show_bug.cgi?id=1367932 | 10:15 |
| mup | Bug #1680011 opened: snapd support for xdg-desktop-portal <Snappy:New> <https://launchpad.net/bugs/1680011> | 10:16 |
| zyga | morphis: looking | 10:17 |
| zyga | morphis: I have system-preset (not presets) and I have 90-default.preset (not 80), nothing in that directory mentions snapd | 10:19 |
| zyga | morphis: in general, I'd patch snap (client) to give a smarter message | 10:20 |
| zyga | morphis: the current one is terrible | 10:20 |
| zyga | morphis: installing hello-world just to see if it works | 10:20 |
| zyga | it does :) | 10:21 |
| nanodrone | zyga, what's the snappy 'core' that's downloaded at the very start? | 10:21 |
| zyga | morphis: so I'd change the narrative in client/*.go | 10:21 |
| zyga | nanodrone: it's a snap that provides base runtime environment for all other snaps | 10:21 |
| zyga | nanodrone: it contains the root filesystem, basic executables and basic libraries | 10:21 |
| zyga | nanodrone: on core systems (those that use snaps exclusively) it is also used as the actual root file system | 10:22 |
| zyga | nanodrone: over time it will shrink and get split into a core snap that has just skeleton rootfs and snapd, and one of many base snaps | 10:22 |
| nanodrone | wow... | 10:22 |
| zyga | nanodrone: (e.g. a base snap providing ubuntu 16.04 runtime, a base snap with fedora 26 runtime, etc) | 10:22 |
| zyga | nanodrone: a particular snap will then declare which base snap it was built against | 10:23 |
| zyga | nanodrone: so you can run 16-based apps alongside 18-based apps or fedora/yocto/etc | 10:23 |
| zyga | nanodrone: the core snap is already small but with this approach it will shrink significantly | 10:24 |
| Chipaca | jdstrand— you around? | 10:24 |
| nanodrone | who's programming this stuff, it sounds really awesome. | 10:24 |
| zyga | nanodrone: and it will be possible to build even smaller embedded devices, with stripped down base snaps | 10:24 |
| zyga | nanodrone: we also have kernel snaps but those are not used on classic systems (those that use regular distribution filesystem alongside snaps) | 10:24 |
| zyga | nanodrone: let me know if you have any more questions, feel free to post this conversation in the forum for others to find | 10:25 |
| nanodrone | ubuntu core comes to mind... lol | 10:25 |
| nanodrone | can i just publish my app now, is that okay? | 10:26 |
| zyga | nottrobin: snapd is made by a wide variety of individuals, you can see full development history on github.com/snapcore/snapd (e.g. here: https://github.com/snapcore/snapd/graphs/contributors | 10:26 |
| zyga | nanodrone: ^ | 10:26 |
| morphis | nanodrone: sure, the store is open for your apps :-) | 10:26 |
| zyga | sorry, tab completion error :) | 10:26 |
| zyga | nanodrone: in addition various parts of the core snap are made by 100s of people in various communities | 10:26 |
| morphis | nanodrone: https://snapcraft.io/docs/build-snaps/ will get your started | 10:27 |
| zyga | nanodrone: yes, you are welcome to publish your snaps at any time | 10:27 |
| nanodrone | this is huge, i can't wrap my head around this concept, and to think it actually works and i have access to it right now. | 10:27 |
| nanodrone | i've already built a snap | 10:27 |
| nanodrone | lol | 10:27 |
| nanodrone | it was easy. | 10:27 |
| morphis | :-D | 10:27 |
| zyga | nanodrone: they can be immediately installed on ubuntu/debian and deriviatives and also on fedora (currently in testing but should go out this week) and opensuse (not in the main archive yet, a separate system:snappy repo exists) | 10:28 |
| zyga | nanodrone: you are welcome :) | 10:28 |
| morphis | zyga: you saw https://bugs.launchpad.net/snappy/+bug/1680011 ? | 10:28 |
| mup | Bug #1680011: snapd support for xdg-desktop-portal <cross-distro> <Snappy:New> <https://launchpad.net/bugs/1680011> | 10:28 |
| zyga | nanodrone: snapd is also pretty portable so your application can easily be installed on a new distribution by simply working on packaging snapd there | 10:29 |
| morphis | zyga: wondering if there were already any conversations regarding support for portals | 10:29 |
| zyga | morphis: looking | 10:29 |
| nanodrone | i was really scared when i first saw the ~80megs core installation at first but after actually getting to know the basic concepts, i'm a fan... | 10:29 |
| zyga | morphis: intereting | 10:29 |
| zyga | nanodrone: note that the 80mb is shared by all the snaps you can currently install | 10:30 |
| nanodrone | maybe yall should mention this on the homepage | 10:30 |
| morphis | nanodrone: https://docs.ubuntu.com/core/en/ may help you to dive a bit deeper | 10:30 |
| zyga | nanodrone: and we also have delta updates so they should not be noticeable | 10:30 |
| zyga | morphis: so I see some benefits here and some issues | 10:30 |
| zyga | morphis: one is that we probably don't want to delegate security to a 3rd party trusted helper | 10:30 |
| zyga | morphis: let's start a thread about this and see what jdstrand and tyhicks think about it | 10:30 |
| nanodrone | just to be sure, is snapcraft.io the official homepage? | 10:30 |
| zyga | morphis: one think that feels like an obvious approach is to stack the helpers | 10:31 |
| morphis | nanodrone: yes | 10:31 |
| zyga | morphis: so that we can sit between snaps making requests and if we veto it ok relay that to platform helper | 10:31 |
| morphis | nanodrone: for snaps in general it is | 10:31 |
| zyga | nanodrone: yes | 10:31 |
| morphis | nanodrone: if you want more about Ubuntu Core https://docs.ubuntu.com/core/en/ is the official documentation | 10:31 |
| nanodrone | noted. thanks. | 10:32 |
| zyga | morphis: I'm curious about `.flatpak-info` | 10:32 |
| morphis | zyga: I guess it is similar to snap.yaml | 10:32 |
| zyga | morphis: aha, I see | 10:32 |
| zyga | morphis: so we'd have to generalize that aspect | 10:32 |
| zyga | morphis: I think if we can engage in portal development | 10:32 |
| zyga | morphis: that is something to consider | 10:32 |
| zyga | morphis: currently portals look too flatpak centric given their "xdg" branding (though that is to be expected) | 10:33 |
| morphis | zyga: so you say having an xdg-portal snap which overs all these services? | 10:33 |
| zyga | morphis: I think we can collaborate on those though | 10:33 |
| zyga | morphis: I wasn't thinking about that | 10:33 |
| zyga | morphis: I see some possiblities (making portals really generic and just adopting them) | 10:33 |
| zyga | morphis: implement portal api in snapd | 10:33 |
| morphis | I see | 10:33 |
| zyga | morphis: or put snapd as a proxy between platform portals and snaps | 10:34 |
| zyga | morphis: it depends on security aspects | 10:34 |
| zyga | morphis: on design considerations (does this block any cool ideas on first having an agreement with flatpak developers working on portals) | 10:34 |
| zyga | morphis: and usability considerations (is this what we want?) | 10:34 |
| zyga | morphis: let's start a thread about this or discuss on the bug report | 10:34 |
| pedronis | morphis: I tend there was a thread on a mailing list about portals | 10:35 |
| pedronis | s/tend/think/ | 10:35 |
| morphis | pedronis: ok, worth bringing this into the discussion | 10:35 |
| zyga | morphis: I would love if we could collaborate on shared technology with flatpak developers personally | 10:36 |
| tvoss | zyga, I think we want to have snapd being the ultimate source of anything trust in the system. That being said, a backend talking to snapd does not seem to be unreasonable. I'm working on a similar setup for PolicyKit | 10:36 |
| zyga | tvoss: I agree | 10:36 |
| morphis | tvoss: +1 | 10:36 |
| zyga | tvoss: I think that is not negociable as this is the root of trust on the system really | 10:37 |
| zyga | negotiable* | 10:37 |
| morphis | let me comment on the bug so we get that discussion started in the forum | 10:37 |
| * zyga jumps off IRC to work on some test improvements | 10:37 | |
| popey | ogra: remember the pinebook? https://www.pine64.org/?page_id=3707 - they just sent out pre-order emails. $99 for an arm laptop :) | 11:04 |
| popey | "We do not wish to discourage anyone from getting a Pinebook, as it is a good piece of hardware, but if you are looking for a device to replace your current work or school laptop, then perhaps it’s wise to look elsewhere." :) | 11:04 |
| * Chipaca ~> lunch | 11:08 | |
| ogra | popey, heh, yeah, it is closer to a chromebook i guess | 11:09 |
| Chipaca | popey— 99 for the 14", 89 for a 12"? | 11:10 |
| popey | yeah | 11:14 |
| Son_Goku | zyga, morphis: hardcoding starting the socket isn't allowed | 11:33 |
| morphis | Son_Goku: so what is the recommend way for the user here? reboot? | 11:34 |
| Son_Goku | well, actually, it looks like we could technically start the socket if the preset enables it | 11:37 |
| Son_Goku | I see that we do this for lvm2 | 11:37 |
| Son_Goku | morphis, zyga: systemd presets were designed for the provisioning use-case, so I guess I don't see a reason not to auto-start it | 11:42 |
| Son_Goku | since we *are* enabling it for F25 and up | 11:42 |
| morphis | Son_Goku: maybe we do a is-enabled check before we start it | 11:42 |
| sborovkov | Hi | 11:42 |
| sborovkov | What's going on here? | 11:43 |
| sborovkov | root@localhost:/home/pi# snap set core pi-config.disable-overscan=true | 11:43 |
| morphis | Son_Goku: so we respect if an administrator has a preset which disables snapd in contrast to the distro default | 11:43 |
| sborovkov | error: cannot perform the following tasks: | 11:43 |
| sborovkov | - Run configure hook of "core" snap (run hook "configure": awk: not an option: --sandbox) | 11:43 |
| Son_Goku | morphis: right | 11:43 |
| sborovkov | My snapd is: snapd 2.23.6+201704041910.git.e7f0423~ubuntu16.04.1 | 11:43 |
| morphis | sborovkov: is that on a stable core snap or edge? | 11:43 |
| sborovkov | morphis: stable. Should I upgrade to edge? | 11:43 |
| sborovkov | nvm | 11:44 |
| sborovkov | it's edge | 11:44 |
| sborovkov | installed: 16-2 (1632) 70MB - edge: 16-2 (1632) 70MB - | 11:44 |
| morphis | sborovkov: ok, but still a bug | 11:44 |
| sborovkov | morphis: manually trying to get pi-config from the REST api does not work as well | 11:45 |
| morphis | ogra, mvo: ^^ | 11:45 |
| sborovkov | >>> r = session.get('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', params={'keys': 'pi-config'}) | 11:46 |
| sborovkov | >>> r.text | 11:46 |
| sborovkov | '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"snap \\"core\\" has no \\"pi-config\\" configuration option"}}' | 11:46 |
| sborovkov | >>> | 11:46 |
| zyga | morphis: I like the is-enabled check | 11:47 |
| zyga | sborovkov: that's gawk/mawk | 11:47 |
| zyga | sborovkov: I think we fixed that (^ mvo ) | 11:47 |
| sborovkov | zyga: why is there no pi-config option returned by rest api though? | 11:49 |
| zyga | sborovkov: no idea | 11:49 |
| sborovkov | or it because nothing is set there. | 11:49 |
| morphis | zyga: me too | 11:49 |
| morphis | Son_Goku: is that an option for you? | 11:49 |
| Son_Goku | morphis: yes | 11:50 |
| Son_Goku | it's certainly better than what some other people have been doing | 11:50 |
| zyga | Son_Goku: I think we want to start it if enabled and patch snap to give useful advice if it's not started | 11:51 |
| zyga | Son_Goku: right now it's really barf-from-the-system | 11:51 |
| mvo | sborovkov: its because nothing is set there, only once you set something it will return something, its not (currently) smart enough to look at existing values that have not been set via the config. if that is something you need, it might be worth catching up with niemeyer so that we put it on the agenda | 11:51 |
| Son_Goku | snap will need to give useful advice anyway, since F24 won't have it | 11:51 |
| zyga | Son_Goku: can we push an update to F24 to enable it there too? | 11:52 |
| Son_Goku | no | 11:52 |
| zyga | Son_Goku: not ourselves I mean | 11:52 |
| zyga | Son_Goku: via the same process we used for F25 | 11:52 |
| sborovkov | mvo: well I guess, I can live with it not returning anything. And just handling that case. | 11:52 |
| zyga | pedronis: I applied your patch and got to the point were I think I understand how it works, I'll follow up with the 2nd test now | 11:53 |
| Son_Goku | zyga: yes, technically, but I think they don't like modifying presets for released distros | 11:53 |
| zyga | Son_Goku: I see | 11:53 |
| Son_Goku | remember that F25 got it because we requested it back before F25 was released | 11:53 |
| zyga | Son_Goku: I think that's fine | 11:53 |
| Son_Goku | and F24 EOLs a month after F26 releases anyway | 11:53 |
| zyga | Son_Goku: we can try but we should definitely patch snapd to just be nicer UX wise | 11:53 |
| Son_Goku | so it's not a terrible situation | 11:53 |
| zyga | Son_Goku: right | 11:53 |
| zyga | Son_Goku: exactyl | 11:53 |
| zyga | *exactly | 11:53 |
| zyga | morphis: the install instructions can say that on F24 we need to enable+start the services manually | 11:54 |
| sborovkov | One more question about rest API. Am I doing something wrong here? >>> r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', data={'pi-config.disable-overscan': 'true'}) ,"result":{"message":"cannot decode request body into patch values: invalid character \'p\' looking for beginning of value"}}' | 11:54 |
| sborovkov | Might be dumb question, but I am not working with REST apis very often :( | 11:54 |
| morphis | zyga: sounds good, will take care to update the instructions on snapcraft.io | 11:54 |
| zyga | sborovkov: no idea but I bet Chipaca knows | 11:54 |
| Son_Goku | morphis: don't forget I already have a PR for the Fedora instructions | 11:54 |
| zyga | meanwhile I'm going to get back to test reliability :) | 11:55 |
| sborovkov | Chipaca: hello :-) do you know what I might be doing wrong there? | 11:55 |
| morphis | Son_Goku: you have one? | 11:55 |
| Son_Goku | go look at snappy-docs :) | 11:55 |
| morphis | ah great! | 11:55 |
| morphis | didn't saw that one yet | 11:56 |
| davidcalle | Son_Goku: do you have any timing on when this will be mergeable btw? | 11:56 |
| morphis | Son_Goku: let me review | 11:56 |
| Son_Goku | davidcalle: Fedora bodhi updates can be pushed after five days of being in updates-testing with zero changes and not enough feedback | 11:56 |
| morphis | Son_Goku: really? | 11:57 |
| morphis | so karma is optional? | 11:57 |
| Son_Goku | morphis: karma makes it go faster | 11:57 |
| morphis | ah! | 11:57 |
| Son_Goku | I have autokarma enabled, so that means that if enough positive karma is set, bodhi will push immediately | 11:58 |
| zyga | morphis: I tested F24 and will give my +1 soon | 11:58 |
| zyga | morphis: did you see my feedback there? | 11:58 |
| zyga | morphis: we could look at bumping the progress bar library | 11:58 |
| morphis | zyga: yes | 11:58 |
| zyga | morphis: and perhaps do a survey to see where the libs in fedora are older than what we vendor | 11:58 |
| morphis | zyga: I am testing f24 currently too | 11:58 |
| zyga | morphis: it's just a _visible_ difference so I noticed | 11:58 |
| zyga | morphis: but we may be facing other issues | 11:58 |
| morphis | right, I already have that on my list | 11:59 |
| zyga | excellent! | 11:59 |
| morphis | zyga: would be good if we can automate that somehow | 11:59 |
| morphis | against any distro | 11:59 |
| morphis | (for those where we don't use vendor= | 11:59 |
| zyga | morphis: I bet you can | 11:59 |
| zyga | morphis: but I'd do it manually at least once too | 11:59 |
| morphis | zyga: let me do that :-) | 11:59 |
| morphis | zyga: btw. interesting is that docker for openSUSE uses vendoring | 12:00 |
| zyga | morphis: oh, who maintains the package? | 12:00 |
| Son_Goku | morphis: there was some SERIOUS drama being golang packaging | 12:00 |
| zyga | morphis: maybe it is a commercial thing | 12:00 |
| morphis | zyga: https://build.opensuse.org/package/view_file/Virtualization:containers/docker/docker.spec?expand=1 | 12:00 |
| Son_Goku | zyga: remember I told you about that | 12:00 |
| zyga | Son_Goku: no, I didn't | 12:00 |
| morphis | zyga: Copyright (c) 2017 SUSE LINUX GmbH, Nuernberg, Germany. | 12:00 |
| zyga | :-) | 12:00 |
| davidcalle | zyga: for now, until the above gets pushed, what's the missing command for fedora install, I'm deploying in a couple hours, so can be added right now | 12:01 |
| Son_Goku | zyga: you mentioned it here: https://new.zygoon.pl/post/state-of-snapd-support-across-distros/ | 12:01 |
| Son_Goku | davidcalle: the current instructions for Fedora are correct for now | 12:02 |
| Son_Goku | my PR revises it for the state it will be once they are merged into the repos | 12:02 |
| Son_Goku | zyga, morphis, davidcalle: if I don't get +6 karma before Friday, I think, I'll be able to push it manually | 12:03 |
| davidcalle | Ok, from reading up, I thought there was a missing command to start the services (in addition to enabling them) | 12:03 |
| morphis | zyga: sounds good | 12:03 |
| Son_Goku | davidcalle: in the instructions, no | 12:03 |
| davidcalle | Alright | 12:04 |
| zyga | Son_Goku: my memory is very rusty then :) | 12:04 |
| Son_Goku | zyga and morphis would like me to make it start them automatically from package install | 12:04 |
| zyga | Son_Goku: I should send a follow-up to that post | 12:04 |
| zyga | Son_Goku: as the reality now is much happier than before | 12:04 |
| Son_Goku | that's a different thing ;) | 12:04 |
| zyga | I just commented on https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4 | 12:04 |
| zyga | I didn't test snapd-glib in any way though | 12:04 |
| Chipaca | sborovkov, zyga, sorry was having lunch. What's the question? | 12:05 |
| zyga | I'll do F26 in the evening, I have to download the alpha ISOs and I have little power to spare on the installation now | 12:05 |
| zyga | Chipaca: some questions about the REST APIs earlier | 12:05 |
| zyga | Chipaca: about config specifically | 12:05 |
| Son_Goku | zyga: morphis and I already know there are issues with snapd-glib | 12:05 |
| Chipaca | ah, I don't know much about config; that's pstolowski | 12:05 |
| Son_Goku | zyga: hughsie is trying to use it and is getting weird/broken results | 12:05 |
| pstolowski | what's up? | 12:06 |
| Chipaca | pstolowski, sounds like the REST docs for config aren't enough for sborovkov here to apply them in the real world | 12:06 |
| zyga | I'll let you figure it out , scroll back to "13:54 < sborovkov> One more question about ..." | 12:06 |
| fgimenez | zyga: quick question about the core:network-bind plug, on a classic system with ubuntu-core installed, if i install a snap which declares a plug on network-bind before the transition happens, after the transition i see core:network-bind disconnected, is that the expected behaviour? | 12:06 |
| zyga | Son_Goku: about the extra APIs for figuring out where /snap directory is? | 12:06 |
| zyga | fgimenez: mhh | 12:06 |
| Son_Goku | zyga: no, that's a different thing | 12:07 |
| zyga | fgimenez: and it was connected before the transition? | 12:07 |
| Son_Goku | though I'm not sure if gnome-software needed that | 12:07 |
| morphis | zyga: ignore snapd-glib for now | 12:07 |
| zyga | morphis: ok | 12:07 |
| zyga | fgimenez: if it was then this does feel like a bug | 12:07 |
| morphis | Son_Goku, zyga: I am currently trying to get g-s/snapd-glib into shape | 12:07 |
| Son_Goku | okay | 12:07 |
| morphis | zyga: you should have a mail in your inbox about that topic | 12:07 |
| pedronis | fgimenez: seems a bug, bit strange we never noticed it? I thought the test were actually testing that case | 12:07 |
| zyga | morphis: aha | 12:08 |
| morphis | Son_Goku, zyga: but getting g-s requires some more work | 12:08 |
| pedronis | fgimenez: I mean the core transition spread tests, anyway seems a question for mvo | 12:08 |
| morphis | zyga, Son_Goku: as upstream isn't that happy with the current snap-support state | 12:08 |
| zyga | fgimenez, pedronis: we definitely move connections over from ubuntu-core to core but perhaps something else is intervening; I also recall that if you had both core snaps installed you'd not auto-connect | 12:08 |
| zyga | fgimenez: so if you are 100% sure it was connected before then this is a bug | 12:08 |
| Son_Goku | morphis, zyga: I'm not surprised | 12:08 |
| morphis | zyga, Son_Goku: list of bugs I filed so far https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bugs?field.tag=cross-distro | 12:08 |
| Son_Goku | morphis: you should connect those to gnome-software package in Fedora in LP | 12:09 |
| morphis | Son_Goku: not yet | 12:09 |
| zyga | morphis: it would be interesting to grow UI for connections in g-s | 12:09 |
| morphis | zyga: yes but I am wondering on which list that is | 12:09 |
| zyga | morphis: so that you can click on something "interface connections" and have something sensible there | 12:09 |
| fgimenez | zyga: before the transition core:network-bind is not llisted as plug, this is the complete sequence http://paste.ubuntu.com/24319937/ | 12:10 |
| pstolowski | sborovkov, i'm not familiar with that side of config (rest api) either, but quick look at the code where this error is thrown reveals that a json map is expected at this point | 12:10 |
| mvo | fgimenez: uh, that should not happen. there is even a test (xkcd-webserver iirc) that checks for this | 12:10 |
| pstolowski | sborovkov, i.e. data should be a json map | 12:11 |
| pstolowski | afaict | 12:11 |
| zyga | fgimenez: woah | 12:11 |
| zyga | fgimenez: that's so weird | 12:11 |
| zyga | note that network-bind is listed _twice_ | 12:12 |
| fgimenez | zyga: mvo if no snap declaring a plug on network-bind is installed, then after the transition you see ":network-bind core,test-snapd-python-webserver" | 12:12 |
| zyga | give me a sec | 12:12 |
| fgimenez | i mean ":network-bind core" | 12:12 |
| mvo | fgimenez: what did you do to reproduce? | 12:12 |
| sborovkov | pstolowski: well I tried r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', json={'pi-config.disable-overscan': 'true'}). That does nothing though, hmm. '{"type":"async","status-code":202,"status":"Accepted","result":null,"change":"27"}' | 12:13 |
| fgimenez | mvo: it's all in the paste, this is from a fresh 16.04.2, while validating ubuntu-core from beta | 12:13 |
| morphis | zyga: sounds like a good idea | 12:13 |
| pstolowski | sborovkov, mind creating a forum topic with that? | 12:14 |
| fgimenez | mvo: "apt install -y snapd" is missing, other than that is all there | 12:14 |
| zyga | fgimenez: do you have that system around? | 12:14 |
| zyga | fgimenez: can you get the raw response for GET /v2/interfaces | 12:14 |
| mvo | fgimenez: thank you | 12:14 |
| fgimenez | zyga: i can bring it up again, 1sec | 12:14 |
| pstolowski | sborovkov, actually nvm, let's try to figure out here | 12:14 |
| zyga | fgimenez: so what that looks like to me | 12:15 |
| zyga | fgimenez: is that the transition failed but we have both installed | 12:15 |
| zyga | fgimenez: note that we hide both "core" and "ubuntu-core" in the client | 12:15 |
| zyga | fgimenez: so that thing at the end is a plug, not a slot actually | 12:16 |
| zyga | fgimenez: so that's the disconnected "network-bind" plug on the core snap | 12:16 |
| zyga | (sorry I got confused earlier) | 12:16 |
| morphis | zyga, mvo: are you guys happy with https://github.com/snapcore/snapd/pull/3096 so that we can merge it? | 12:16 |
| mup | PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096> | 12:16 |
| zyga | fgimenez: still, really weird | 12:17 |
| zyga | morphis: checking | 12:17 |
| zyga | morphis: you need to get +1 from niemeyer on that | 12:17 |
| morphis | zyga: "Please feel free to merge when you're happy about the handling of these problems." | 12:17 |
| pstolowski | sborovkov, so looks like it worked, that should have triggerd your configure hook? | 12:17 |
| morphis | niemeyer: can you review https://github.com/snapcore/snapd/pull/3096 again? | 12:18 |
| mup | PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096> | 12:18 |
| zyga | morphis: yes but you'd have to override a review that requested changes to do that | 12:18 |
| niemeyer | Hellos | 12:18 |
| sborovkov | pstolowski: No. Since it did not set anything. Doing get after that: '{"type":"error","status-code":400,"status":"Bad Request","result":{"message":"snap \\"core\\" has no \\"pi-config\\" configuration option"}}' | 12:18 |
| niemeyer | morphis: Will do | 12:18 |
| zyga | fgimenez: I have a theory | 12:18 |
| morphis | niemeyer: thanks! | 12:18 |
| zyga | fgimenez: when we install new core over ubuntu-core | 12:18 |
| zyga | fgimenez: we briefly have both installed | 12:19 |
| zyga | fgimenez: and then auto-connects bail out | 12:19 |
| zyga | fgimenez: I think that's easy to test | 12:19 |
| morphis | Son_Goku: can you cross-check if we now have all PRs merged we need for fedora? | 12:19 |
| zyga | fgimenez: we should fix the auto-connect logic to skip ubuntu-core if core is installed | 12:19 |
| zyga | niemeyer: hey | 12:19 |
| Son_Goku | morphis: there's one issue we still need solved, and that's the thing with the constants | 12:19 |
| Son_Goku | there's no pr for that because you said you'd fix it properly | 12:20 |
| zyga | niemeyer: will you have the time to look at https://github.com/snapcore/snapd/pull/3095 today? | 12:20 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 12:20 |
| fgimenez | zyga: aha fwiw the core:network-bind plug seems to work fine (ie autoconnects) when no snap declaring a plug on network-bind is installed before the transition start | 12:20 |
| morphis | Son_Goku: ah right | 12:20 |
| morphis | Son_Goku: let me look into that today | 12:20 |
| zyga | fgimenez: ubuntu-core doesn't use it | 12:21 |
| zyga | fgimenez: so it's not connected | 12:21 |
| zyga | fgimenez: then you install core which currently does use network-bind | 12:21 |
| zyga | fgimenez: and since you have two provides auto-connect does nothing | 12:21 |
| niemeyer | morphis: Why is it bundling changes from retry? | 12:21 |
| niemeyer | morphis: That doesn't look right | 12:21 |
| morphis | ? | 12:21 |
| zyga | fgimenez: so you just install core but that plug just is left as-is | 12:21 |
| niemeyer | morphis: https://github.com/snapcore/snapd/pull/3096/files#diff-373b88c8996bc0465932cbb690320cf6 | 12:22 |
| mup | PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096> | 12:22 |
| zyga | niemeyer: that's my fault, sorry | 12:22 |
| morphis | niemeyer: yeah somebody updated my branch | 12:22 |
| zyga | niemeyer: we discussed that with mvo yesterday | 12:22 |
| morphis | niemeyer: just placed my last change on top of what was pushed | 12:22 |
| Son_Goku | zyga, morphis: https://paste.fedoraproject.org/paste/sVS0uNm4fHAmKSKVAlgi815M1UNdIGYhyRLivL9gydE= | 12:22 |
| Son_Goku | how does that look? | 12:22 |
| zyga | niemeyer: I can revert that there, at the time we hoped it would land in master and the extra EOF retry would fix the failures we (randomly) got there | 12:22 |
| Chipaca | zyga— is there a sh-friendly runtime way of knowing libexecdir? | 12:22 |
| morphis | Son_Goku: looks good to me | 12:22 |
| niemeyer | zyga: That's pretty dangerous.. the other branch was still unreviewed | 12:23 |
| zyga | Son_Goku: looks good to me | 12:23 |
| zyga | niemeyer: at the time it had only positive feedback and it looked as if it would land imminently | 12:23 |
| mvo | niemeyer: https://irclogs.ubuntu.com/2017/04/04/%23snappy.html#t11:42 | 12:24 |
| zyga | niemeyer: lesson learned | 12:24 |
| niemeyer | morphis: Right thing here now is to merge master on it, and then fix conflicts.. these unrelated lines must go away from the diff | 12:24 |
| fgimenez | zyga: so, going back to the initial question :) is that the expected behaviour, is it ok to have the core:network-bind plug disconnected in some cases after the transition? | 12:24 |
| niemeyer | morphis, zyga: The PR did change before landing | 12:24 |
| zyga | fgimenez: no, it's a bug | 12:24 |
| mvo | niemeyer: i.e. the same point was raised yesterday, no disagreement | 12:24 |
| pstolowski | sborovkov, can you execute your snap-set request again and check if 'snap changes' as well as journalctl show anything interesting? | 12:24 |
| morphis | niemeyer: fine with that | 12:24 |
| Son_Goku | morphis: if everything is dealt with, then I can propose to merge the snapd spec for Fedora for snapd 2.24 | 12:25 |
| zyga | mvo: I think we have one interesting bug in core transition | 12:25 |
| zyga | mvo: something that didn't affect us at the time | 12:25 |
| mvo | zyga: yeah, I was just reading backlog | 12:25 |
| niemeyer | mvo: *thumbs up* | 12:25 |
| zyga | mvo: if you are in the transition then none of the new plugs on core will be connected | 12:25 |
| zyga | mvo: I'll try to fix it today with something very simple but I wanted to let you know | 12:26 |
| niemeyer | zyga: About 3095, I will | 12:26 |
| mvo | zyga: \o/ | 12:26 |
| zyga | niemeyer: thank you | 12:26 |
| mvo | zyga: I was about to ask if you have an idea for a fix :) | 12:26 |
| zyga | mvo: yes, I would check if core and ubuntu-core are both installed and then totally ignore ubuntu-core when looking for auto-conncet candidates | 12:27 |
| zyga | mvo: it would then connect correctly unless I'm missing some detail | 12:27 |
| mvo | zyga: that sounds good | 12:27 |
| Son_Goku | morphis: the (bad? good?) news is that snapd-qt from snapd-glib isn't used at all by Plasma Discover | 12:27 |
| morphis | niemeyer: done | 12:27 |
| niemeyer | morphis: Looks great, thank you for the changes! | 12:28 |
| mvo | fgimenez, zyga: how to best track this? a new forum post? or should I just put it on the 2.24 release page? | 12:28 |
| morphis | niemeyer: np | 12:28 |
| sborovkov | pstolowski: Alright, so one of my commands worked. The one with typo in command. So I am trying to figure out which one. Or if there is just a big lag between execution of async request. | 12:28 |
| morphis | Son_Goku: :-) | 12:28 |
| * zyga -> quick walk before the standup | 12:28 | |
| morphis | a different story .. | 12:28 |
| zyga | see you soon | 12:28 |
| sborovkov | pstolowski: Apr 05 12:28:35 localhost.localdomain /usr/lib/snapd/snapd[1016]: task.go:303: DEBUG: 2017-04-05T12:28:35Z ERROR run hook "configure": awk: not an option: --sandbox | 12:28 |
| sborovkov | after post requests. | 12:29 |
| sborovkov | put* | 12:29 |
| Son_Goku | morphis, so I can update snapd and snapd-glib with the new changes (new scriptlet for snapd, new version for snapd-glib), but that will kick the update back out | 12:29 |
| Simooon | The snaps available using the "snap find" command are the same, regardless of what system I'm on, correct? | 12:29 |
| Son_Goku | and unless you have a number of people who have Fedora accounts to give karma on the new update, it's going to have to wait another week | 12:30 |
| fgimenez | mvo: not sure, maybe the branch with the fix could be added to the release page once it's up? | 12:30 |
| Son_Goku | morphis, on the other hand, the user experience improvement might be worth it | 12:32 |
| fgimenez | mvo: quick question, this problem showed up while validating the ubuntu-core snap on beta in order to promote it, other than that all looks fine, do you think we should continue with the promotion or wait for the fix? | 12:33 |
| mvo | fgimenez: I think the issue is independant of ubuntu-core, i.e. it will also manifest itself with the stable ubuntu-core. its core itself that is the problem | 12:35 |
| fgimenez | mvo: great thank you | 12:35 |
| mvo | fgimenez: do you see ill effects ? can you run snap config get core refresh.disabled | 12:35 |
| mvo | fgimenez: or do you get apparmor/seccomp denials in syslog if you do that on the system that you transitioned? | 12:36 |
| fgimenez | mvo: haven't checked, let me try | 12:36 |
| pstolowski | sborovkov, if you have an error in your configure script (if it exits with status 1), then this will abort entire change to the config, so the config option won't be set | 12:39 |
| sborovkov | pstolowski: why does it even set unsupported keys then? '{"type":"sync","status-code":200,"status":"OK","result":{"pi-config":{"disble-overscan":"false"}}} :-( | 12:42 |
| pedronis | so awk on that system doesn't have --sandbox? | 12:42 |
| pedronis | how is that possible | 12:43 |
| * pedronis is confused | 12:43 | |
| sborovkov | I don't know. zyga mentioned that it was fixed somewhere I think. | 12:45 |
| sborovkov | alright, I can set the options now. I guess I need to reboot to see if config.txt will change? | 12:45 |
| Chipaca | mawk vs gawk? | 12:45 |
| sborovkov | Or when that change is going to be triggered? | 12:45 |
| pedronis | Chipaca: yea, but it comes from core | 12:45 |
| pedronis | did we have the wrong one setup for a bit? | 12:45 |
| mvo | sborovkov: I'm not an expert for the pi config.txt details, but my understandig is that this is pretty lowlevel (firmware) so a reboot seems to be needed | 12:46 |
| Chipaca | pedronis— on classic you get a symlink | 12:46 |
| Chipaca | or used to, i haven't tracked that one | 12:46 |
| pedronis | so much fun for classic snaps | 12:46 |
| pedronis | /snap/core/current/usr/bin/awk -> /etc/alternatives/awk | 12:47 |
| pedronis | not that I think it's the issue here | 12:47 |
| Chipaca | niemeyer— is it expected that spread'd segfault? | 12:48 |
| Chipaca | http://pastebin.ubuntu.com/24320095/ | 12:48 |
| sborovkov | mvo: Ok I rebooted. Config.txt is unchanged. Hmm. | 12:48 |
| mvo | sborovkov: meh | 12:49 |
| mvo | sborovkov: the option did not get applied? | 12:49 |
| sborovkov | disregard that. I had typo in option name. | 12:49 |
| sborovkov | Let me recheck | 12:49 |
| sborovkov | why does it not reject arbitrary keys in such cases? | 12:49 |
| mvo | sborovkov: this indicates that we really need to validate those option names! | 12:49 |
| sborovkov | does that make sense? | 12:49 |
| fgimenez | JamieBennett: all seems to be fine with ubuntu-core at beta, there's a problem with the ubuntu-core -> core transition (see the backlog) but it's not specifically related to the ubuntu-core snap | 12:49 |
| niemeyer | Chipaca: Definitely not, thanks for the traceback | 12:49 |
| pstolowski | sborovkov, i'm not familiar with pi config, but in general you can make up any options as long as the configure script of given snap allows this and doesn't error out on something unknown (which is probably impossible to implement in configure script anyway because there is no way of getting all options afair) | 12:50 |
| mvo | sborovkov: its not doing it right now because we have no "schema" for the config currently. afaik niemeyer has some ideas about config validation so that we can reject invalid options (or option values) early | 12:50 |
| sborovkov | mvo: Ok I understand why I am going crazy here | 12:50 |
| sborovkov | So it does not work when I set proper name | 12:50 |
| sborovkov | any arbitrary name is working though | 12:50 |
| fgimenez | JamieBennett: if you want to take a look to the tests executed i've written a small spread task for this kind of validations https://github.com/fgimenez/validate_image/pull/6/files | 12:50 |
| sborovkov | >>> r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', json={"pi-config.disable-oasdfsdfverscan": "true"}) - works | 12:50 |
| mvo | sborovkov: what error do you get with the correct name? | 12:51 |
| Chipaca | niemeyer, I'd pretend to be surprised, but this endeavour has been hitting this kind of corner case weirdness all across the stack :-) | 12:51 |
| mvo | sborovkov: sorry for the trouble :/ | 12:51 |
| sborovkov | >>> r = session.put('http+unix://%2Frun%2Fsnapd.socket/v2/snaps/core/conf', json={"pi-config.disable-overscan": "true"}) no change | 12:51 |
| sborovkov | mvo: that's fine. I get no error. It just gets ignored | 12:51 |
| mvo | sborovkov: ok, let me try to reproduce | 12:51 |
| JamieBennett | fgimenez: so you are happy to us to promote to candidate and have jibel do a test? | 12:51 |
| niemeyer | Chipaca: Sorry for the pain there :) | 12:52 |
| sborovkov | mvo: https://hastebin.com/alovofejaz.scala | 12:52 |
| fgimenez | JamieBennett: yes, all looks fine | 12:53 |
| niemeyer | Chipaca: Some of them are pretty amazing I must say | 12:53 |
| Chipaca | sborovkov— so | 12:53 |
| JamieBennett | jibel: Are you the team OK to do a sanity check on the ubuntu-core snap? | 12:53 |
| Chipaca | sborovkov— you're getting 202 Accepted | 12:53 |
| Chipaca | sborovkov— do you then look at the change? | 12:53 |
| Chipaca | sborovkov— (sorry, jumping in because i happened to look at the pastebin, haven't been following) | 12:54 |
| Chipaca | 2m test startup time does that to me | 12:54 |
| niemeyer | Chipaca: We should suggest a replacement of Spotlight Awards by Breakage Awards.. I think that makes a lot more sense | 12:54 |
| sborovkov | Chipaca: look at the hastebin. If I set proper name it's accepted. next get returns no difference. With arbitrary key I see that it changes. | 12:54 |
| Chipaca | sborovkov— Accepted does not mean it worked | 12:54 |
| Chipaca | sborovkov— you need to look at the change to know that | 12:54 |
| sborovkov | Ah, alright, I will check | 12:55 |
| Chipaca | sborovkov— you get the change id as part of the 202 response | 12:55 |
| pedronis | sborovkov: it's an async api | 12:55 |
| Chipaca | sborovkov— and then you hit /v2/changes/<id> | 12:55 |
| Chipaca | (from memory) | 12:55 |
| jibel | JamieBennett, yes, when do you need it done? | 12:55 |
| JamieBennett | Well, I have published the core snap, just waiting for a validation of the ubuntu-core snap so when ever you are ready | 12:55 |
| jibel | JamieBennett, ubuntu-core not core, correct? | 12:55 |
| JamieBennett | jibel: right | 12:56 |
| sborovkov | Chipaca: '{"type":"sync","status-code":200,"status":"OK","result":{"id":"50","kind":"configure-snap","summary":"Change configuration of \\"core\\" snap","status":"Error","tasks":[{"id":"135","kind":"run-hook","summary":"Run configure hook of \\"core\\" snap","status":"Error","log":["2017-04-05T12:50:02Z ERROR run hook \\"configure\\": awk: not an option: --sandbox"],"progress":{"label":"","done":1,"total":1},"spawn-time":"2017-04-05T12:50:01.752141739Z"," | 12:56 |
| sborovkov | ready-time":"2017-04-05T12:50:02.953066325Z"}],"ready":true,"err":"cannot perform the following tasks:\\n- Run configure hook of \\"core\\" snap (run hook \\"configure\\": awk: not an option: --sandbox)","spawn-time":"2017-04-05T12:50:01.752253041Z","ready-time":"2017-04-05T12:50:02.953071898Z"}}' | 12:56 |
| pedronis | so the awk wrong | 12:56 |
| mvo | sborovkov: $ sudo snap set core pi-config.disable-overscan=true | 12:56 |
| mvo | error: cannot perform the following tasks: | 12:56 |
| mvo | - Run configure hook of "core" snap (run hook "configure": awk: not an option: --sandbox) | 12:56 |
| mvo | sborovkov: is what I get :/ I'm working on that no, sorry for this | 12:57 |
| Chipaca | maybe our awk is suddenly bb.awk or sth | 12:57 |
| Chipaca | on core rpi | 12:57 |
| * Chipaca looks at ogra | 12:57 | |
| Chipaca | :-D | 12:57 |
| sborovkov | mvo: Alright, I guess that's all related. Can you ping me when it gets fixed or there is some PR for this or whatever | 12:57 |
| ogra | heh, no, it is still gawk as always :) | 12:57 |
| Chipaca | mvo— this is an extra nice reason to move the python configure hook in; what's that blocked in again? | 12:58 |
| pedronis | it seems not to believe that | 12:58 |
| Chipaca | s/blocked in/blocked on/ | 12:58 |
| mvo | Chipaca: not sure if there is anything blocking, zyga did raise an issue with the context manager iirc | 12:58 |
| Chipaca | sigh | 12:59 |
| * Chipaca looks | 12:59 | |
| zyga | Chipaca: sorry, I think you want to fix/test that context manager | 12:59 |
| ogra | hmm, or not ... looks like the alternative points actually to mawk | 13:00 |
| mvo | Chipaca: lets talk aobut it during the standup | 13:01 |
| niemeyer | Sorry, omw | 13:02 |
| mvo | Chipaca: but +1 for python | 13:02 |
| ogra | mvo, mawk doesnt know --sandbox (dont ask why we ship mawk instead of gawk now) | 13:02 |
| mvo | ogra: yeah, I'm slightly uneasy without --sandbox, feels to me like going to python is indeed the easiest option | 13:02 |
| Chipaca | oh, standup | 13:02 |
| * Chipaca runs | 13:02 | |
| ogra | well, it is definitely a diff towards any normal ubuntu that we dont have gawk | 13:03 |
| ogra | jdstrand, mind taking a look at https://bugs.launchpad.net/snappy/+bug/1674509 (specifically my last comment) | 13:06 |
| mup | Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509> | 13:06 |
| Son_Goku | zyga, why is it that we don't modprobe squashfs as ExecStartPre for snapd.service? | 13:20 |
| ogra | (after checking /proc/filesystems first indeed :P ) | 13:21 |
| zyga | Son_Goku: mmmm, not sure, I think we used to have that | 13:22 |
| zyga | Son_Goku: but I didn't notice it is needed now | 13:22 |
| zyga | Son_Goku: I didn't test the cloud variants, just workstation _and_ server though | 13:22 |
| zyga | Son_Goku: but good catch, I think we should | 13:22 |
| Son_Goku | I guess would squashfs be loaded automatically when you attempt to mount? | 13:22 |
| Son_Goku | it would make sense, since you don't really need it if nothing is mounted... | 13:23 |
| mup | PR snapcraft#1207 closed: kernel plugin: stop duplicating initrd and image file, use symlinks f… <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1207> | 13:24 |
| Chipaca | zyga— sprinkled some exception handling to core#24, if you can take another peek | 13:26 |
| mup | PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24> | 13:26 |
| sborovkov | mvo: I submitted a bug for that btw. https://bugs.launchpad.net/snappy/+bug/1680088 | 13:27 |
| mup | Bug #1680088: Can't change Pi-config values using snap set command or via REST API <Snappy:New> <https://launchpad.net/bugs/1680088> | 13:27 |
| mvo | jibel: looks like http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd is happy again(except ubuntu-image, I did a retry on that, lets see if it was a fluke) | 13:28 |
| mvo | sborovkov: thank you! https://github.com/snapcore/core/pull/24 is one possible fix | 13:29 |
| mup | PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24> | 13:29 |
| mup | Bug #1680088 opened: Can't change Pi-config values using snap set command or via REST API <Snappy:New> <https://launchpad.net/bugs/1680088> | 13:29 |
| jibel | mvo, yup, I saw, thanks. | 13:30 |
| sborovkov | mvo: understood. Btw why is the full list of config.txt commands not supported? Should not be a lot of code to have them all there | 13:30 |
| jibel | mvo, why is 2.23.1 still in -proposed and not 2.23.6? | 13:31 |
| jibel | for t, x, y | 13:31 |
| mvo | sborovkov: its trivial to extend, we just went a conservative route, happy to add more if you need more | 13:31 |
| sborovkov | understood | 13:31 |
| mvo | jibel: I have no idea, I suspect because z is not updated yet :/( | 13:31 |
| mvo | sborovkov: I'm here for you :) just let me know which one you need, if it's not super dangerous I'm happy to add it | 13:32 |
| mvo | (dangerous as in "brick it") | 13:32 |
| Son_Goku | zyga, morphis: so I'm going to bump to 2.23.6-4 to add the test for starting socket+timer | 13:32 |
| Son_Goku | that will be for F25+ updates | 13:32 |
| ogra | mvo, for the moment, no dtoverlay option please ... | 13:32 |
| Son_Goku | and I'll simultaneously update snapd-glib to 1.10 | 13:32 |
| Son_Goku | and drop the karma requirement from +6 to +3 | 13:32 |
| mvo | ogra: you have veto on the PRs :) | 13:33 |
| ogra | (until we have a proper sotry for upgrating dtbs from the kernel snap into gadget) | 13:33 |
| ogra | ah, indeed :) | 13:33 |
| Son_Goku | for F24, snapd-glib will also be updated, and I will drop the karma requirement to +3 as well | 13:33 |
| sborovkov | mvo: haha, alright. I will check if we are using any other options. | 13:34 |
| mvo | sborovkov: thank you | 13:34 |
| zyga | Son_Goku: we shuold rally more people to give it a try | 13:34 |
| jibel | mvo, ah autopkgtest of snapcraft are failing on y & x, and for trusty need to poke the release team | 13:34 |
| Son_Goku | zyga: well clearly no one seems to give a damn :( | 13:35 |
| zyga | morphis, Son_Goku: we should look at (later perhaps) upstreaming kernel fixes we found recently (not apparomr related) and making them available in fedora as well | 13:35 |
| zyga | Son_Goku: I bet people will over time | 13:35 |
| zyga | Son_Goku: it's the firs time this is available | 13:35 |
| Son_Goku | zyga: if they are merged into mainline tree, you can request them to be backported into Fedora kernels | 13:35 |
| zyga | Son_Goku: that's good, I think those will be merged quickly | 13:35 |
| zyga | Son_Goku: I can recall bugs in clone and AT_SECURE | 13:35 |
| zyga | Son_Goku: and there's one more bug related to clone AFAIR | 13:35 |
| Son_Goku | zyga, morphis: all karma has reset on the updates | 13:40 |
| Son_Goku | zyga, morphis: https://forum.snapcraft.io/t/call-for-testing-snapd-2-23-on-fedora/127/7?u=conan_kudo | 13:48 |
| zyga | Son_Goku: yep, nice :) | 13:49 |
| mvo | ogra: I just had a look at the cloud-init thing, how about we merge it and create a new core right away (the usualy sync-lp, create core dance). this way we can verify now that it has no regressions. if that sounds good, could you pull the trigger(s)? | 13:52 |
| ogra | mvo, i can indeed ... but given that the self-tests already create a core snap by default, how about we hook up something that makes use of this snap too ;) (will indeed make the tests really long i guess) | 13:53 |
| ogra | (not right now, but as a long term plan indeed) | 13:53 |
| Son_Goku | wow, I got super lucky | 13:54 |
| Son_Goku | I managed to update the updates in time for bodhi mash | 13:54 |
| ogra | i'm also not sure if these changes need to go hand in hand with the ubuntu-core-config change that rharper has pending ... | 13:54 |
| Son_Goku | davidcalle: if zyga and morphis can rustle up people to test the updates, we might even be lucky enough to release to stable today | 13:55 |
| Son_Goku | today/tomorrow | 13:55 |
| Son_Goku | zyga, morphis: doc update PR: https://github.com/CanonicalLtd/snappy-docs/pull/60 | 13:55 |
| mup | PR CanonicalLtd/snappy-docs#60: [DO NOT MERGE YET] Revise content related to Fedora <Created by Conan-Kudo> <https://github.com/CanonicalLtd/snappy-docs/pull/60> | 13:55 |
| morphis | Son_Goku: I am on fedora 24 currently | 13:55 |
| morphis | and a 26 alpha1 is installing | 13:56 |
| Son_Goku | excellent | 13:56 |
| morphis | but I see I need to give 25 another try :-) | 13:56 |
| morphis | wish we had automation for this already :-) | 13:56 |
| morphis | Son_Goku: btw. how do you want to celebrate once we landed snapd? you have a blog you could post a story about this? | 13:56 |
| Son_Goku | I don't really have a blog or anything | 13:57 |
| Son_Goku | well, I technically do | 13:57 |
| Son_Goku | but I haven't updated it since 2009 :) | 13:57 |
| Son_Goku | http://pharaohtechblog.blogspot.com/ :P | 13:57 |
| fgimenez | zyga https://bugs.launchpad.net/snappy/+bug/1680097 i've updated the test to check for core:network-bind connected after the transition https://github.com/fgimenez/validate_image/pull/6/files | 13:58 |
| mup | Bug #1680097: core:network-bind plug is not connected after ubuntu-core -> core transition <Snappy:New> <https://launchpad.net/bugs/1680097> | 13:58 |
| morphis | Son_Goku: up to you :-) | 13:58 |
| zyga | fgimenez: thank you | 13:58 |
| fgimenez | zyga: np thank you! | 13:59 |
| mup | Bug #1680097 opened: core:network-bind plug is not connected after ubuntu-core -> core transition <Snappy:New> <https://launchpad.net/bugs/1680097> | 13:59 |
| zyga | Son_Goku: I think we should also celebrate with beer and a hangout together | 13:59 |
| zyga | Son_Goku: I would love to know if your nintendo switch is getting bent | 14:00 |
| zyga | Son_Goku: or if it gets hot while gaming | 14:00 |
| Son_Goku | it does get warm, but not "hot" | 14:01 |
| Son_Goku | and bent? don't think so | 14:01 |
| zyga | Son_Goku: did you see the article on slashdot where some devices started bending about a month after purchase? | 14:02 |
| zyga | Son_Goku: looks heat related | 14:02 |
| Son_Goku | eek | 14:03 |
| zyga | Son_Goku: yes | 14:03 |
| zyga | Son_Goku: nintendo WRAP | 14:03 |
| mvo | ogra: I'm all for doing more tests | 14:05 |
| mvo | ogra: I have no idea if it needs to be synced with the core config change, so maybe worth double checking first | 14:05 |
| rharper | ogra: mvo : the core config changes are also needed; in particular the ubuntu-core-config package will include the ds-identify policy file which configures cloud-init to ensure a datasource is present so it dones't needlessly run | 14:06 |
| mvo | ogra, zyga, Chipaca, niemeyer: what do you think needs to happen before https://github.com/snapcore/core/pull/24 can land? my (biased) opinion is that the python code is more readable and (much) more (unit) tested. but I'm open for concerns, maybe a good forum topic actually? | 14:07 |
| mup | PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24> | 14:07 |
| mvo | rharper: can we land one before the other or do they need to land strictly in sync? i.e. does landing them out-of-sync break anything? | 14:08 |
| Chipaca | mvo— any reason not to plop it on edge and see how it fares? especially in view of the mgawk thing | 14:08 |
| rharper | mvo: no; the final piece would be the snap prepare change which removes the writing of cloud-init.disabled | 14:08 |
| zyga | mvo: looking | 14:09 |
| mvo | Chipaca: not from my POV :) but I'm (super) biased, I have a thing with shell | 14:09 |
| Chipaca | mvo— you should play with expect for a while | 14:09 |
| rharper | as long as that file is present, then cloud-init won't run at all; so the remaining changes won't have an affect for users not enabling cloud-init | 14:09 |
| mvo | rharper: great, so we can just land things and eventually fix ubntu-image and it all works | 14:09 |
| Chipaca | mvo— tcl is awesome for making you appreciate the shell | 14:09 |
| mvo | Chipaca: lol | 14:09 |
| rharper | mvo: there may be some users of gadgets which supply a cloud.conf which could be affected since they wouldn;t have a cloud-init.disabled file in the image created | 14:10 |
| mvo | Chipaca: when I did that I was (more than once) abou to rewrite those tests, I did the gpg2 expect stuff and it was a PITA. but I guess nothing compared to your tab completion work | 14:10 |
| mvo | rharper: hm, do we have a way to notify them (or know about them)? | 14:10 |
| Chipaca | mvo, it's been a learning experience | 14:10 |
| Chipaca | it boils down to not a lot of code fortunately | 14:10 |
| mvo | Chipaca: a learning experience in zen like stoicism ;) ? | 14:11 |
| rharper | not sure; certainly we can poke on mailing list (like devices?) I don't think their behavior will change if they're supplying cloud-init config (via usb or cdrom, or the nocloud datasource) that all gets detected anyhow | 14:11 |
| Chipaca | mvo, well, I didn't know {} were quotes in tcl, for example | 14:11 |
| Chipaca | mvo, nor that you grouped things with []s | 14:12 |
| rharper | mvo: I was hoping there might be a way to have daily images or something with the changes together | 14:12 |
| Chipaca | e.g.: set back1 [string repeat "\b" [string length $::env(_KEY1)]] | 14:12 |
| Haxxa | Will snappy packages work under lxc containers in proxmox? I heard their may be some issues present at this time? | 14:12 |
| Chipaca | in python that would be: back1 = "\b".repeat(len(os.getenv("_KEY1"))) | 14:13 |
| Chipaca | close | 14:13 |
| zyga | mvo: I'm with you on the bias to drop shell | 14:13 |
| rharper | mvo: I've got to run to an appt; but please ping me here with any issues and i'll respond when I get back | 14:13 |
| zyga | mvo: python is a much safer and better language for this kind of functionality | 14:13 |
| zyga | Chipaca: why did you have to touch tcl? | 14:14 |
| Chipaca | zyga— expect is tcl | 14:14 |
| mvo | Haxxa: once https://github.com/snapcore/snapd/pull/3136 has landed lxd should be fine | 14:14 |
| mup | PR snapd#3136: snap-confine: add code o ensure that / or /snap is mounted "shared" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3136> | 14:14 |
| mvo | rharper: thank you! | 14:14 |
| morphis | zyga: how do you feel about https://paste.ubuntu.com/24320508/ ? | 14:15 |
| stevehope | I'm trying to learn a bit more about snap packaging and have some time if anyone could use a tester, know some python but snapcraft newcomer | 14:15 |
| Haxxa | mvo, wow this is hot of the press indeed - issue I guess it won't find its way into ubuntu for awhile and are their any preconditions for how old a kernel can be? proxmox is based on debian and thus host kernel is pretty old. | 14:17 |
| zyga | morphis: note that suse should be fine | 14:18 |
| morphis | zyga: yeah, though I didn't tried and we may have to drop the global /snap dir there | 14:19 |
| morphis | too | 14:19 |
| zyga | morphis: it's just fedora/centos/rhel that need more love | 14:20 |
| zyga | morphis: otherwise fine with me | 14:20 |
| zyga | morphis: and add "yet" to it | 14:20 |
| zyga | morphis: not *yet* supported | 14:20 |
| zyga | morphis: I hope we don't have to | 14:20 |
| zyga | mvo: I have a few low-priority comments on the python branch | 14:20 |
| zyga | mvo: but I honestly didn't read it in depth | 14:20 |
| zyga | mvo: so if you plan to push it through serious testing +10 | 14:21 |
| morphis | zyga: so you think we should leave suse in there? | 14:21 |
| morphis | I feel if we move it now closer to inclusion in suse we need to drop the global /snap directory | 14:21 |
| zyga | morphis: yes, it should work out of the box today | 14:21 |
| morphis | and with that it will stop working | 14:21 |
| zyga | morphis: maybe so maybe not | 14:21 |
| mvo | zyga: thank you, looking | 14:21 |
| fgimenez | jibel: JamieBennett ubuntu-core 1941 (i386) is ok on beta, ready on candidate for validation | 14:21 |
| morphis | zyga: ok, so we leave it for now and disable once that happens | 14:21 |
| zyga | morphis: s/once/if/ | 14:22 |
| King_InuYasha | zyga: yes you will have to | 14:23 |
| King_InuYasha | the /snap directory is _verboten_ in SUSE | 14:23 |
| King_InuYasha | and they don't have an exception process like Fedora does | 14:23 |
| zyga | King_InuYasha: you know what they say | 14:24 |
| zyga | King_InuYasha: rules are made to be broken :) | 14:24 |
| zyga | King_InuYasha: maybe it will not be that much vreboten ;) | 14:24 |
| King_InuYasha | well, the only reason rpmlint hasn't been rejecting your builds is because you weren't properly creating and owning /snap in the package | 14:24 |
| King_InuYasha | once you do that, OBS will refuse to allow your builds to succeed | 14:25 |
| Chipaca | zyga— os.path.sep is '/', not ':' :-) | 14:25 |
| zyga | King_InuYasha: it's like docker I think, where there is will there are means | 14:25 |
| King_InuYasha | uhh | 14:25 |
| King_InuYasha | no? | 14:25 |
| King_InuYasha | with Docker, the paths are changed | 14:26 |
| zyga | Chipaca: os.path.pathsep | 14:26 |
| zyga | correcting | 14:26 |
| King_InuYasha | and the vendoring thing was because of the feud with golang packagers | 14:26 |
| zyga | Chipaca: thanks! | 14:26 |
| Chipaca | np | 14:27 |
| zyga | King_InuYasha: I mean if SUSE really wants to embrace snaps they can allow /snap | 14:27 |
| zyga | King_InuYasha: it's entirely within their will | 14:27 |
| Chipaca | mvo— I'm going to pretend you're picking core#24 back up now :-) | 14:27 |
| mup | PR core#24: Rewrite meta/hooks/configure into python3 <Created by mvo5> <https://github.com/snapcore/core/pull/24> | 14:27 |
| pedronis | Chipaca: there's pathsep, seems a bit overkill (this things won't run on non unix) | 14:28 |
| Chipaca | ¯\_(ツ)_/¯ | 14:28 |
| zyga | pedronis: sure but it looks nicer :) | 14:28 |
| pedronis | does it? | 14:28 |
| pedronis | sep vs pathsep sounds super obscure | 14:28 |
| ogra | mvo, well, wh9ile i'm not particulary tied to shell for the config hook (you knwo i prefer it, but i can live with other langs there), i'm particulary sceptical about using python there ... remember that one of the reasons of re-writing snapd in go was that it sucked in python on embedded ... my fear is that the configure hook will easily exceed 100 lines at some point (especially if we add each and every boards gadget config to it over time) | 14:29 |
| ogra | and then just kill single core ARM boards with low ram | 14:29 |
| ogra | mvo, i wonder how hard would it be to do it in go instead ? | 14:29 |
| mcphail | zyga: are there reasons it needs to be /snap rather than /opt/snap? I've always wondered why the root directory gets polluted like that | 14:29 |
| zyga | mcphail: we cannot use /opt/snap everywhere | 14:29 |
| zyga | ah, time to run for kids | 14:30 |
| shuduo | zyga: hi, i'm reading https://snapcraft.io/docs/core/interfaces and confuse about "Creating an interface" part. To say, The OS snap exposes a number of interfaces to grant snaps access to system functions. You can extend this access by creating your own interfaces. | 14:31 |
| zyga | shuduo: hey | 14:31 |
| shuduo | zyga: does it mean anyone (end user) can add a new interface to snapd and make it working with all-snap system? | 14:31 |
| zyga | brb | 14:32 |
| kyrofa | shuduo, no, they must be supported in snapd, so that's saying "you can extend this by contributing your own interfaces" basically | 14:34 |
| shuduo | zyga: I suppose we only encourage requesting an interface via bugs.lp.net or submit a PR but always be reviewed by core team, right? | 14:34 |
| shuduo | kyrofa: ^ | 14:35 |
| zyga | shuduo: re | 14:35 |
| kyrofa | shuduo, that's the only way, yes | 14:35 |
| shuduo | zyga: I suppose we only encourage requesting an interface via bugs.lp.net or submit a PR but always be reviewed by core team, right? | 14:35 |
| zyga | shuduo: so the answer is simple: anyone can propose an interface for inclusion and once merged it will make its way to all the users | 14:35 |
| shuduo | zyga: kyrofa already answered me. :) | 14:35 |
| zyga | shuduo: yes | 14:35 |
| zyga | (sorry, I was going to my car) | 14:36 |
| shuduo | zyga, kyrofa thanks. one customer is asking "How to write our own interface that could act as a provider(slot) for multiple snaps ?" | 14:36 |
| kyrofa | shuduo, it's important to note that not only does the interface need to be supported in snapd, but the application the end-user is using must utilize that interface | 14:36 |
| kyrofa | shuduo, indeed, assuming it's not a slot already supported in snapd that they simply need to implement in their snap, they'd need to write and propose it | 14:37 |
| zyga | shuduo: it depends on what that interface is about | 14:37 |
| zyga | shuduo: we have existing interfaces that can be consumed by many snaps at the same time | 14:37 |
| shuduo | kyrofa: so the answer to customer is "no. or you can request it if it's common scenario". | 14:38 |
| zyga | shuduo: the best answer is "let's discuss this", it really depends on what you need the interface for | 14:39 |
| zyga | shuduo: central review is requred as it is the only way to ensure the system remains secure | 14:39 |
| shuduo | zyga: kyrofa. Customer requests "Example use case: Location Service/ Alarm Service in iOS/ Android. “ | 14:40 |
| zyga | shuduo: we have an interface for location services | 14:40 |
| zyga | shuduo: we have no notion of alarm service, you'd have to tell us what permission is needed for it | 14:40 |
| shuduo | zyga: is the location interface landed in latest snapd? | 14:41 |
| zyga | shuduo: it was there for months, the snap that uses the interface is separate though (it is not provided by core) | 14:41 |
| zyga | shuduo: not all interfaces have slots on the core snap | 14:42 |
| zyga | shuduo: but all interfaces are defined inside snapd | 14:42 |
| shuduo | zyga: so i can't see it from my desktop is expected. | 14:42 |
| zyga | shuduo: yes | 14:42 |
| kyrofa | zyga, let's say the "alarm service" they want is super wonky and non-generic. Would that still go become a built-in interface, just not implemented by the core snap? | 14:42 |
| zyga | shuduo: you should look at the snapd tree, at the interfaces/builtin directory | 14:42 |
| shuduo | zyga: got it. thanks! | 14:43 |
| zyga | shuduo: also writing an interface is 2nd step, you should just try to do something and see if you need any extra permissions | 14:43 |
| kyrofa | zyga, I guess the location service is a bit non-generic in that sense | 14:43 |
| zyga | shuduo: if in doubt ask in the forum (forum.snapcraft.io) | 14:43 |
| shuduo | zyga: okay. i will. | 14:44 |
| zyga | shuduo: good luck | 14:44 |
| mvo | ogra: I can create a forum topic to discuss, this way its easier to follow than irc. I'm not aganst go at all, just feels like more work to make the build per-architecture etc | 14:45 |
| mvo | Chipaca: yeah, I pick up the python stuff again | 14:45 |
| ogra | mvo, well, we're building the core snap pre arch anyway, it could just be part of that ... i just want to go back to the python issues we had before | 14:46 |
| ogra | mvo, i commented on the PR btw | 14:46 |
| ogra | *i just *dont* want to go back (indeed) | 14:46 |
| zyga | mvo: I gave my feedback on the PR now | 14:47 |
| zyga | I'll switch to another task | 14:47 |
| ogra | zyga, dude ... multi-tasking ... | 14:48 |
| ogra | :) | 14:48 |
| zyga | ogra: I just *swapped* to my car :) | 14:48 |
| ogra | lol | 14:48 |
| zyga | the car power adapter works very well though | 14:48 |
| zyga | I'm super happy with what I ended up with :) | 14:48 |
| mvo | zyga: I addressed some/most | 14:53 |
| zyga | mvo: offtopic, I was meaning to ask you: how do you disable touchpad while typing on your laptop? | 14:53 |
| mvo | zyga: I totally disabled mine, I only use the trackpad | 14:54 |
| zyga | mvo: how did you do that? | 14:56 |
| zyga | mvo: I really miss the fn+Fsomething that used to do it on older models | 14:56 |
| mvo | zyga: system-settings/mouse&touchpad/touchpad: "off" on the right hand side | 14:56 |
| mvo | zyga: yeah, I (much) prefer the old keyboard | 14:56 |
| mvo | zyga: I wish there was a model with that, I would buy it instantly | 14:57 |
| zyga | mvo: ohh, fantastic :) | 14:57 |
| zyga | mvo: I didn't see that option before :) | 14:57 |
| zyga | thanks! | 14:57 |
| Chipaca | if I make changes to interfaces/apparmor/template.go, is that picked up by the tests somehow? | 14:57 |
| zyga | x250 is so far really the best laptop I ever had, by far | 14:57 |
| Chipaca | spread tests i mean | 14:57 |
| zyga | Chipaca: yes | 14:57 |
| zyga | Chipaca: well | 14:57 |
| zyga | Chipaca: what do you mean picked up? | 14:57 |
| zyga | Chipaca: it gets used | 14:57 |
| zyga | Chipaca: if that what you mean | 14:57 |
| Chipaca | zyga— is it used in the core under test? | 14:58 |
| zyga | if that's what you meant | 14:58 |
| zyga | yes because we swap snapd with the one we built | 14:58 |
| zyga | and we refresh security on startup | 14:58 |
| zyga | Chipaca: and even if not, we install snaps in each test so it does get used | 14:59 |
| mup | PR snapd#3143 closed: data/systemd: tweak data/systemd/Makefile to be slightly simpler <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3143> | 14:59 |
| zyga | pedronis, mvo: https://github.com/snapcore/snapd/pull/3140 | 14:59 |
| mup | PR snapd#3140: overlord: fix TestEnsureLoopPrune not to be so racy <Created by zyga> <https://github.com/snapcore/snapd/pull/3140> | 14:59 |
| zyga | I can do the 2nd test as a separate branch on top, this will help people with random failures already | 15:00 |
| mvo | zyga: nice work | 15:00 |
| zyga | mvo: all the credit goes to pedronis :) | 15:01 |
| zyga | mvo: I just pasted and studied that code | 15:01 |
| mup | PR snapd#3096 closed: many: abstract path to /bin/{true,false} <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3096> | 15:22 |
| morphis | mvo: thanks! | 15:23 |
| mvo | morphis: thank oyu | 15:23 |
| mvo | you | 15:23 |
| mup | PR snapd#3144 opened: overlord,release: disable classic snap support for fedora/rhel/centos <Created by morphis> <https://github.com/snapcore/snapd/pull/3144> | 15:24 |
| morphis | mvo, zyga: ^^ | 15:24 |
| morphis | mvo: can you tag that one for 2.24? | 15:26 |
| morphis | only if you guys agree | 15:26 |
| mvo | morphis: done | 15:31 |
| morphis | mvo: thanks | 15:32 |
| zyga | shuduo: I replied on the forum | 15:35 |
| zyga | morphis:looking | 15:35 |
| morphis | zyga: adding a test case for snapstate.go still | 15:35 |
| Pharaoh_Atem | morphis, zyga: I can practically guarantee that suse will flip from true to false if we want it to get into Factory | 15:37 |
| zyga | morphis: have a look | 15:37 |
| zyga | Pharaoh_Atem: let's not use our crystall balls (sic!) yet :) | 15:37 |
| zyga | Pharaoh_Atem: once we get there | 15:38 |
| Sky_ | Hi everyone, I just want to know how to run the snaps | 15:39 |
| morphis | zyga: updated | 15:39 |
| zyga | Sky_: hey, snap install hello-world; hello-world | 15:39 |
| Pharaoh_Atem | zyga: I don't need a crystal ball | 15:39 |
| Pharaoh_Atem | you shouldn't assume optimism for this | 15:39 |
| zyga | Pharaoh_Atem: but you cannot say what SUSE the company will do | 15:39 |
| Sky_ | Then I get hello 2.10 from 'canonical' installed | 15:40 |
| Pharaoh_Atem | suse the company doesn't care, but opensuse the distribution does | 15:40 |
| zyga | Sky_: then run hello-world | 15:40 |
| Pharaoh_Atem | they're unlikely to include snapd in sle13 | 15:40 |
| zyga | Sky_: you've just ran your first snap :) | 15:40 |
| zyga | Pharaoh_Atem: I think we are fine where we are now, let's not worry too much | 15:40 |
| zyga | morphis: did you push? I don't see any changes | 15:41 |
| morphis | zyga: refresh, jsut added the snapstate test case | 15:41 |
| morphis | other fixes are coming | 15:41 |
| zyga | morphis: ah, great | 15:42 |
| Pharaoh_Atem | morphis: added comments | 15:42 |
| morphis | zyga: check again | 15:43 |
| zyga | morphis, Pharaoh_Atem commented again | 15:44 |
| zyga | sorry for not realizing this earlier | 15:44 |
| ogra | rharper, did you see my comment in the mail i CCed you on ? could you move your MP from the bzr tree of ubuntu-core-config to https://github.com/snapcore/core-build ? | 15:45 |
| zyga | is it reali-z-ing or reali-s-ing | 15:45 |
| morphis | zyga: good point | 15:45 |
| Pharaoh_Atem | realizing | 15:45 |
| zyga | ah, thanks :) | 15:45 |
| ogra | i think depends on the dictionary you use ;) | 15:45 |
| Pharaoh_Atem | unless your a barmy British idiot, then it's "realising" | 15:45 |
| Pharaoh_Atem | :) | 15:45 |
| Pharaoh_Atem | s/your/you' | 15:45 |
| Pharaoh_Atem | s/your/you're/ | 15:45 |
| zyga | Pharaoh_Atem: maybe after brexit UK will adopt US englishg | 15:45 |
| Pharaoh_Atem | haha | 15:45 |
| ogra | lol | 15:45 |
| Pharaoh_Atem | well, ours was the original English | 15:45 |
| ogra | suuure ... thats why they left after all ... to be more american :) | 15:46 |
| Pharaoh_Atem | they de-emphasized /z/ in UK English and writing to be more French | 15:46 |
| popey | Oi! | 15:46 |
| Pharaoh_Atem | though in contemporary UK English, /z/ is present in most dialects, and leaks in to Received Pronounciation from time to time | 15:46 |
| * ogra gets the popcorn | 15:47 | |
| Pharaoh_Atem | they still spell with "s" though, as a holdover from the Victorian era | 15:47 |
| mcphail | Pharaoh_Atem: I'm sure it was just an Oxford/Cambridge thing | 15:47 |
| Pharaoh_Atem | prior to the Victorian era, it was somewhat mixed | 15:47 |
| Pharaoh_Atem | Scots and Irish used spelling familiar to Americans, as their accents used /z/ and even today that remains the case for speech | 15:48 |
| Pharaoh_Atem | English and Welsh were mixed, though the affluent sections of England used the current UK English spellings more often | 15:49 |
| morphis | zyga: ok, this gets a bit more tricky, dirs and release have a dependency on each other | 15:50 |
| zyga | morphis: oooh :) | 15:52 |
| zyga | morphis: have fun untangling that | 15:52 |
| morphis | hah :-) | 15:52 |
| zyga | morphis: but I think that's the correct solution for this problem | 15:52 |
| zyga | morphis: you can move some logic so that deps go one way | 15:52 |
| morphis | yeah, I think I know what I do | 15:53 |
| morphis | I make the logic part of dirs so its a CurrentDirConfigSupportsClassicConfinement-thing | 15:53 |
| morphis | as that is what it really is | 15:53 |
| morphis | its not a distro specific thing its a setup thing | 15:53 |
| ogra | ooooh ! | 15:55 |
| ogra | the electron forum app actually integrates with the desktop notifications of unity8 properly °! | 15:55 |
| Pharaoh_Atem | that's... terrifying | 15:55 |
| * ogra just got a proper notification for a reply on the forum ... so awesome | 15:56 | |
| zyga | ogra: oooh | 15:57 |
| zyga | ogra: I need to try that | 15:57 |
| zyga | ogra: does it work on fedora? | 15:57 |
| ogra | zyga, no idea, i never used fedora in my life | 15:58 |
| zyga | ogra: really?! | 15:58 |
| zyga | ogra: why not, try it :) | 15:58 |
| zyga | ogra: at least a VM | 15:58 |
| ogra | RH 4.2 was the last redhat product i used | 15:58 |
| ogra | since then i never had to touch any | 15:58 |
| zyga | ogra: some nice things there | 15:59 |
| zyga | ogra: look at fedora server booting, really beautiful and fast | 15:59 |
| === chihchun is now known as chihchun_afk | ||
| * zyga breaks from coding and goes to read the forum | 16:00 | |
| zyga | niemeyer: for all the experiments we did as a team the forum is by far the clearest 'win-win' we did | 16:00 |
| zyga | pedronis: can I merge https://github.com/snapcore/snapd/pull/3140 now? | 16:00 |
| mup | PR snapd#3140: overlord: fix TestEnsureLoopPrune not to be so racy <Created by zyga> <https://github.com/snapcore/snapd/pull/3140> | 16:00 |
| zyga | (when green, I'm asking if you can +1 it( | 16:01 |
| morphis | zyga: check again | 16:03 |
| mup | PR snapcraft#1235 opened: Store API interactions for developer collaboration <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/1235> | 16:03 |
| zyga | aha | 16:04 |
| zyga | morphis: look again | 16:06 |
| zyga | morphis: +1 overall | 16:06 |
| morphis | zyga: thanks! | 16:19 |
| niemeyer | zyga: +1! | 16:20 |
| niemeyer | Wait.. I mean, .. | 16:20 |
| niemeyer | zyga: Indeed, the experiment is working well.. I didn't mean to +1 some PR :) | 16:20 |
| zyga | niemeyer: haha OK :) | 16:20 |
| zyga | niemeyer: it's just so great to see lots of people flock to the forum | 16:21 |
| niemeyer | Yeah, it's just so much nicer to learn about what's going on and to talk to people this way | 16:21 |
| zyga | niemeyer: about our discussion on security | 16:24 |
| zyga | niemeyer: http://source.android.com/security/bulletin/2017-04-01.html | 16:24 |
| zyga | niemeyer: that's a crazy baaaaaaaaaad list to be in | 16:24 |
| zyga | niemeyer: I think we need to find the right way forward | 16:25 |
| rharper | ogra: I can move it to core-build | 16:31 |
| ogra | rharper, thanks ! | 16:31 |
| niemeyer | zyga: Indeed | 16:36 |
| zyga | garage | 16:37 |
| zyga | checking if 3G works here | 16:37 |
| mup | PR core-build#5 opened: Update cloud-init configuration <Created by raharper> <https://github.com/snapcore/core-build/pull/5> | 16:39 |
| pedronis | zyga: it failed on the job taking too much in general :/ | 16:48 |
| pedronis | I have seen that happen more, haven't looked if it's machine allocation or something else | 16:48 |
| zyga | pedronis: yes, we have many tests sometimes | 16:53 |
| zyga | pedronis: that's all right, it is another cause of failure we know about | 16:53 |
| Chipaca | how is apparmorspeak for "can read stuff in this directory"? | 17:12 |
| Chipaca | (where stuff are shell scripts) | 17:12 |
| zyga | Chipaca: mmm | 17:14 |
| zyga | Chipaca: /path/to/dir/** r, | 17:14 |
| zyga | Chipaca: note that you may need /path/to/dir/ r, as well | 17:15 |
| zyga | (try) | 17:15 |
| Chipaca | zyga— ** means all subdirs also, no? | 17:15 |
| mup | PR snapd#3145 opened: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 17:17 |
| zyga | Chipaca: yes | 17:17 |
| zyga | Chipaca: if you just want stuff in one dir use one star | 17:17 |
| zyga | mvo: not sure if still around: https://github.com/snapcore/snapd/pull/3145 | 17:18 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 17:18 |
| zyga | mvo: I think we want this for 2.24 | 17:18 |
| zyga | we should close 2.23.6 milestone | 17:18 |
| zyga | Chipaca: can you have a look at that too, I bet the switch code can be simplified but I had no idea how | 17:20 |
| Chipaca | zyga— what's the deadline for branches for this release? | 17:21 |
| Chipaca | is it 20 minutes ago? | 17:21 |
| zyga | Chipaca: welll | 17:22 |
| zyga | mvo: what is it? | 17:22 |
| zyga | (I think we want this branch, it may break people upgrading) | 17:22 |
| Chipaca | i was asking for mine, not for yours -- mine is still too far away i fear :-( | 17:27 |
| zyga | Chipaca: oh, which one is that | 17:27 |
| zyga | Chipaca: can I help with review? | 17:27 |
| Chipaca | zyga— completion | 17:27 |
| Chipaca | zyga— was racing to get it out today, but alas | 17:28 |
| dougquaid | I'm having problems with mongo and rocketchat installed via snap. Where can I find their logs? They're not in the usual /var/log | 17:29 |
| Chipaca | dougquaid— they'll be under /var/snap/ | 17:29 |
| dougquaid | thanks | 17:29 |
| Chipaca | I'm going to go for a run, see if I find a different approach to this | 17:30 |
| dougquaid | I guess rocketchat-server doesn't have a log file. All I see in /var/snap/rocketchat-server is its mongo database files | 17:31 |
| Chipaca | dougquaid— I don't have rocketchat here (and i'm about to leave for a bit), but if you know the rocketchat unit name you can get the logs | 17:32 |
| Chipaca | dougquaid— try: | 17:32 |
| Chipaca | systemctl | grep rocket | 17:32 |
| Chipaca | that should get you the unit names | 17:32 |
| Chipaca | then, journalctl -u <the unit> | 17:32 |
| Chipaca | should get you the logs | 17:32 |
| dougquaid | awesome, thanks | 17:33 |
| dougquaid | systemctl | grep rocket retured 5 unit names, but journalctl -u on each of the 5 units returned no entries | 17:36 |
| zyga | Chipaca: good luck | 17:38 |
| zyga | dougquaid: are you on 14.04? | 17:39 |
| * zyga EODs for now | 17:40 | |
| dougquaid | zyga: 16.04 | 17:49 |
| dougquaid | My problem is that rocketchat won't start. Here's systemctl status: https://pastebin.com/D6mZktxV | 17:51 |
| pedronis | niemeyer: getting issues with tests taking too long quite frequently https://travis-ci.org/snapcore/snapd/builds/218925359 | 17:51 |
| zyga | dougquaid: I'm sorry I cannot help you today, I need to take a break now | 17:52 |
| dougquaid | zyga: no problem | 17:52 |
| mup | PR snapcraft#1234 closed: core: find the correct libraries as a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1234> | 18:18 |
| pepe__ | hi, I have a basic question while researching if snap fits our needs. Can it be used to package configured apps like an apache web server + mysql DB + perl web app? Anyone did this? | 18:26 |
| nacc | pepe__: well owncloud is snapped | 18:26 |
| pepe__ | nacc: thanks! will look into it. | 18:29 |
| nacc | pepe__: that seems like the closest to what you described, to me | 18:29 |
| nacc | pepe__: np | 18:29 |
| ogra | nacc, is it ? i thought nextcloud was snapped ;) | 18:36 |
| nacc | err, maybe i meant nextcloud :) | 18:37 |
| nacc | *cloud :) | 18:37 |
| ogra | heh | 18:37 |
| niemeyer | pedronis: That's definitely due to the merge of unit tests into spread | 19:05 |
| niemeyer | pedronis: We've padded our tests by 6-8 minutes on amd64 due to that | 19:06 |
| zyga | niemeyer: I wonder if we can run on VMs with less RAM now | 19:16 |
| zyga | niemeyer: and just run more of them | 19:16 |
| niemeyer | No, we can't | 19:17 |
| niemeyer | zyga: We need more than a machine needs to just run it | 19:18 |
| chani_ | hi guys a question is it possible to install snaps in docker containers | 19:20 |
| zyga | chani_: hi, I don't believe I tried; we recently made it possible to install snaps in LXD so it's definitely possible but I don't know if docker and snapd connected all the pieces | 19:21 |
| zyga | chani_: it also depende on the docker host (kernel) | 19:21 |
| chani_ | cool | 19:21 |
| zyga | chani_: if you try please share your experience here: https://forum.snapcraft.io/ | 19:22 |
| chani_ | yeah sure | 19:22 |
| chani_ | i have tried to install snap on docker with host as ubuntu 16.04 but no luck | 19:23 |
| chani_ | i was getting this error | 19:23 |
| chani_ | 2017/04/05 19:19:19.113943 main.go:220: WARNING: cannot create syslog logger error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd-snap.socket: connect: no such file or directory | 19:23 |
| chani_ | zyga: by the way have you documents the process with LXD some where | 19:25 |
| zyga | chani_: I think it was blogged about frequently a few weeks ago when it went live | 19:26 |
| zyga | chani_: technically some kernel features were needed (stacked apparmor) | 19:26 |
| zyga | chani_: and some integration points between lxd and snapd | 19:26 |
| zyga | chani_: what happens when you "sudo systemctl start snapd" | 19:26 |
| chani_ | zyga: it says no such file or directory | 19:28 |
| zyga | chani_: oh, that's curious | 19:29 |
| chani_ | zyga: "Failed to connect to bus: No such file or directory" | 19:29 |
| zyga | chani_: so your host is ubuntu 16.04? | 19:29 |
| zyga | chani_: and the guest? same? | 19:29 |
| chani_ | yes | 19:29 |
| zyga | chani_: ok, I'd suggest opening a forum topic | 19:30 |
| chani_ | yes both are 16.04 | 19:30 |
| zyga | chani_: I bet we'll get to the bottom of it | 19:30 |
| zyga | chani_: but I was about to close my laptop and read a book now (it's late) | 19:30 |
| chani_ | thanks zyga | 19:30 |
| zyga | chani_: and the forum has more feedback from diverse timezones | 19:30 |
| zyga | chani_: I think stgraber may help out as he is the lead dev of lxd | 19:31 |
| zyga | chani_: and I bet the rest of the snapd team will be eager to help too :) | 19:31 |
| chani_ | zyga: oh thats good to hear | 19:31 |
| chani_ | zyga: thanks again i will open a thread on forms | 19:32 |
| niemeyer | pedronis, zyga: I'll take a break outside now, and will be back later to dive into PRs and see what I can do to bring the total execution time down again | 19:32 |
| zyga | niemeyer: thanks, enjoy the rest of the sunshine :) | 19:32 |
| mup | PR snapd#3140 closed: overlord: fix TestEnsureLoopPrune not to be so racy <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3140> | 21:25 |
| mcphail | sabdfl: Is the plan for snaps to use Wayland? Can this offer the same containment as Mir? Or are we going to be using X for the immediate future? Curious to know how much to invest in snaps, but much less enthused if we are going to be relying on X | 21:25 |
| kyrofa | mcphail, that may be a better forum topic | 21:56 |
| mcphail | kyrofa: yes, maybe you're right | 22:00 |
| nacc | is it possible to tell me what/who is reserving the 'usd' snap? | 22:04 |
| kyrofa | nacc, I doubt it, but you can submit a complaint if you think you should have it | 22:05 |
| kyrofa | Dispute rather, heh | 22:05 |
| nacc | kyrofa: ok | 22:06 |
| nacc | "We can rename snaps to ensure their names match the expectations of most users. If you feel that needs to happen please fill a dispute by filling this form" | 22:06 |
| kyrofa | Yep, that one | 22:06 |
| nacc | where "this form" is not a link and is on the page for registering the snap | 22:06 |
| nacc | so ... no form :) | 22:06 |
| nacc | oih i see the page changed | 22:06 |
| nacc | subtle | 22:06 |
| mup | PR snapcraft#1210 closed: Add platforms for the nightly tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1210> | 22:40 |
| mup | PR snapcraft#1236 opened: snap: use the gpg tarball instead of git:// <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1236> | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!