=== chihchun_afk is now known as chihchun [01:50] PR snapcraft#1231 closed: pluginhandler: exclude `/snap/` from libraries [01:53] PR snapcraft#1232 opened: nodejs plugin: switch to the newer LTS. (#1228) [01:59] PR snapcraft#1233 opened: docs: update contribution guide [02:08] Should I be using snap? Is it like docker or lxc? [02:17] PR snapcraft#1234 opened: core: find the correct libraries as a snap [02:53] PR snapd#3142 opened: daemon: Give the snap directories via GET /v2/system-info [03:32] PR snapcraft#1232 closed: nodejs plugin: switch to the newer LTS. (#1228) [03:34] <_28Kb> can I list core interfaces and stuff to mess with im my ubuntu core 16? [03:37] <_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:39] <_28Kb> to tell my core: do that and then that.. [03:48] <_28Kb> and snacraft is not actually a snap? [03:48] <_28Kb> snapcraft* [03:49] <_28Kb> snap help [04:02] Forum going down for an update... please assume crash landing position. [04:14] We've landed successfully. Please calmly return to your cell phones. [05:01] robert_ancell: ping [05:01] morphis, hi [05:01] robert_ancell: thanks for doing those changes! [05:01] np [05:03] robert_ancell: just commented on the bug [05:03] morphis, weird, is that the query you were doing from inside g-s? [05:03] robert_ancell: but why do we have extra code in gnome-software to query snapd? [05:04] robert_ancell: yes [05:04] let me give this another try [05:04] 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:05] ah ok [05:06] morphis, so weird your g-s did a short read. Your response is the same length as mine. [05:06] I'll have another look tomorrow [05:06] robert_ancell: tried it again now in my 17.04 VM and now it works with gnome-software [05:07] robert_ancell: I now removed rocket-chat and installed through gnome-software again and get the truncated message again [05:07] morphis, this is 17.04 with standard snapd? [05:08] with 2.23.6 [05:09] robert_ancell: but I can debug through this a bit over my day [05:10] morphis, cool [05:10] gtg, bye all! [05:10] robert_ancell: bye! === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:15] good morning [06:16] mvo: hello [06:17] hey zyga - good morning [06:19] 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] PR snapd#3126: store: handle EOF via url.Error check [06:19] mvo: yesterday's exercise was worthwhile as most open PRs got green [06:19] mvo: still, I have a question about one particular problem: [06:19] mvo: https://github.com/snapcore/snapd/pull/3140 [06:19] PR snapd#3140: overlord: increase prune test wait by x10 [06:19] mvo: I attempted a naive "fix" for this racy test [06:20] mvo: but was surprised when it just failed again after making it wait x10 longer [06:20] mvo: do you think it is worth mocking time all the way so that it is reliable? [06:20] mvo: or finding another approach at making it fail less [06:20] mvo: (it consistently fails in many PRs) [06:22] zyga: I have a look, I'm not really sure what the best course of action is [06:23] zyga: but I did notice that its one of the culprits for a lot of the failures too [06:23] mvo: maybe it could run in a loop [06:23] mvo: and any out of N tries could succeed [06:23] mvo: what surprised me is that making the timer longer has caused the test to fail everywhere in that particular run [06:24] mvo: did I misunderstand something about it? I would assume the opposite behavior [06:25] 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:26] mvo: thanks, let me know when you chceked that [06:27] zyga: right after I finished my open review tabs :) [06:55] mvo: did you see this failure: [06:55] 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] mvo: should we try to upload error reports in spread runs? [06:56] 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] mvo: it seems so [06:56] mvo: but when you wrote that test, would it just fake the upload but say it did upload anyway [06:57] mvo: or would it skip the upload and the message entirely? [06:57] mvo: I prepared a tiny patch for this but I'm not sure if it should be sent: [06:57] http://paste.ubuntu.com/24318730/ [06:59] zyga: thanks, checking [07:00] zyga: aha, I think I found the issue, the wrong spot is checking for the snappy_testing :/ let me fix that [07:00] zyga: thanks for discovering! [07:01] mvo: perfect, thanks! [07:01] mvo: what's curious is that it fails infrequently [07:01] mvo: so we either submit most error reports successfuly [07:01] mvo: or something else is wrong [07:03] 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] 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:07] 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] Bug #1660550: [MIR] snapd in trusty [07:08] tvoss: sure, checking [07:09] mvo: thx [07:10] updated [07:12] 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] mvo: ack [07:12] zyga, mvo: after doing an apt upgrade though [07:26] morphis: looking [07:26] morphis: interesting [07:27] morphis: not sure if related but live CD has things that make snapd not work [07:27] morphis: not sure if it is overlayfs or aufs or something like that [07:27] morphis: did you get any apparmor denials for snap-confine? [07:27] morphis: if you did that would probably explain it [07:30] zyga: didn't checked that but after loading the apparmor profile for snap-confine I got the the libudev error [07:33] morphis: do you still have that environment around? [07:33] morphis: dmesg | grep DENIED [07:33] zyga: its easy to recreate [07:33] mvo: I'ld like to land https://github.com/snapcore/snapd/pull/3084 [07:33] PR snapd#3084: packaging: use templates for relevant systemd units [07:33] but no, don't have it anymore [07:33] mvo: has 2 +1s [07:33] morphis: ok [07:33] morphis: I'll try it out today [07:34] zyga: yeah, I was wondering about the foreach() [07:34] zyga: otherwise it looks really great [07:34] zyga: thanks [07:34] zyga: but its not a blocker [07:34] mvo: looking at foreach [07:34] zyga, mvo: just tell me what you guys prefer, happy to change it again :-) [07:34] aha [07:35] zyga, mvo: need go for errands now but can change once I am back or do a followup PR [07:35] morphis: I think mvo means that the foreach is OK but the particular install command is different [07:35] ah [07:35] it even means we don't need foreach [07:35] yeah, less magic is fine with me ;) [07:35] morphis: if you can quickly push that change I'd love to merge it [07:38] 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:39] mvo: +1 [07:39] mvo, morning [07:40] hey jibel! good morning [07:40] mvo, will you reupload a version of 2.23.6 with the fix for bug 1679616 ? or what is the plan there [07:40] Bug #1679616: ADT failure in snapd 2.23.6+17.04 [07:40] mvo, because currently 2.23.6 is blocked in proposed and it'll block the srus too [07:41] 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:42] jibel: hm, not sure how to do that for zesty, let me explore [07:42] 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] jibel: sure, let me do that [07:42] * zyga packs and goes to the library [07:42] see you soon [07:42] jibel: done for 17.04 [07:42] zyga: enjoy [07:42] mvo, thanks! [07:47] 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] PR snapd#3126: store: handle EOF via url.Error check [07:50] mvo— o/ [07:50] mvo— about #3141 [07:51] mvo— I think I'd rather have the current channels be foo/bar instead of having a nested structure [07:52] mvo— however I suspect ordering is going to be an issue with either approach [07:52] we can probably ignore ordering for a first pass though [07:54] hmm === chihchun is now known as chihchun_afk [07:59] Chipaca: ok, I agree [07:59] Chipaca: I will rework :) [07:59] mvo— hold on [07:59] Chipaca: sure [07:59] mvo— the fact that not all snaps have a channel_maps_list is a blocker in my mind [08:00] mvo— what're you going to do for snaps that don't? [08:00] Chipaca: just use the fakeChannels as before [08:00] that was my thinking [08:00] :-( [08:00] and ensure that the store is aware of this cludge [08:00] kludge [08:01] 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:02] mvo— just cc'ed you on an email asking about that [08:02] mvo— the problem with sending a big fat list is twofold [08:02] Chipaca: thank you! [08:02] PR snapd#3139 closed: tests: run gccgo only on ubuntu-16.04-64 [08:03] mvo— one, it makes printing it nicely grouped by track harder [08:03] mvo— two, it makes sorting an issue [08:03] mvo— so, i propose this: keep on having "channels", using foo/bar, but *also* have a *list* of track names [08:03] tadaaa [08:03] PR snapd#3084 closed: packaging: use templates for relevant systemd units [08:05] 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] Chipaca: *nod* [08:05] 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:07] * mvo nods [08:07] Chipaca: thanks, I think this makes sense === chihchun_afk is now known as chihchun [08:08] mvo— also it's the cheapest approach :-) [08:08] Chipaca: ha! that I also like [08:12] PR snapd#3143 opened: data/systemd: tweak data/systemd/Makefile to be slightly simpler [08:16] PR snapd#3126 closed: store: handle EOF via url.Error check [08:16] thank you! [08:21] 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] Chipaca: I updated the forum post to include what we just discussed, thanks again for your input [08:21] pstolowski: thank *you* - really nice work on that branch [08:21] mvo— I've adjusted to being back on IRC just fine, but not so much to the forum [08:22] * Chipaca looks [08:22] mvo, yw. i hope it helps [08:22] Chipaca: no worries - fwiw, I made the forum entry a wiki so you can also edit it if you want/need [08:22] JamieBennett: sure on it [08:25] mvo— tweaked it because that's how i roll, but it seems fine [08:25] JamieBennett: we have rev 1940 of ubuntu-core in the beta channel, is that the version to be validated? [08:26] Hi, guys=) [08:26] It's Renat, from Screenly=) [08:26] Son_Goku: ping [08:27] 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] Chipaca: what can I say [08:27] Chipaca: thank you! [08:28] fgimenez: just checking now [08:29] mvo— you're welcome. Also, check your PMs :-) [08:29] fgimenez: yes, r1940 [08:30] Hey renat, I personally have no idea, maybe mvo knows more about this? [08:31] renat! [08:31] renat— did you get the image working? i'm left waiting for it to debug at my end [08:33] 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] JamieBennett: thanks will let you know how it goes [08:34] 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] renat: you should be able to do read/write of netplan config when you have network_setup_control. [08:34] renat: did you try it and it did nt work? if so, what kind of denial did oyu get? [08:35] renat: you may need the extra network-control iface to actually apply the config though [08:36] 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:37] I mean, netplan execution. There is only access to the netplan config dir. [08:38] Hm. network control may do the trick for now, really. Thanks, mvo, I will try! [08:38] 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:40] mvo— network_setup_control sounds like it should be able to run netplan (i mean, from the name :). Maybe it was an oversight? [08:41] Chipaca: worth checking with jdstrand [08:43] mvo: you now have conflicts in https://github.com/snapcore/snapd/pull/3111 [08:43] PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd [08:45] zyga: thanks, I have a look. there is a super strange error in there that kill the network-observer-test [08:45] mvo: aha, looking [08:45] 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] zyga: but how my branch does trigger this is a bit a mystery [08:47] mvo: lets land this: https://github.com/snapcore/snapd/pull/3129/files [08:47] PR snapd#3129: interfaces/mount: add InfoEntry type [08:47] mvo: I added a tweak to debug output [08:47] mvo: we should be able to see seccomp kills better [08:47] mvo: and see what was connected [08:47] mvo: if you want I can cherry pick that to a separate branch [08:48] 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:50] mvo: I added that to chase the failure i saw there [08:51] 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] there's a failure in tab completion there [08:51] + systemctl stop snapd.service snapd.socket [08:51] Job for snapd.service canceled. [08:51] ah, sorry [08:51] the error is: [08:51] + rm testdir/foo.snap bar.snap [08:51] rm: cannot remove 'testdir/foo.snap': No such file or directory [08:51] Chipaca: probably trivial to address [08:52] zyga— error in prepare [08:53] snappy vs flatpak (i came across it just like a few minutes ago), which one is better for a beginner? [08:53] zyga— that's probably not completion failing [08:53] 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] pedronis: if that's just a race please let me know [08:53] nanodrone— you're asking us, we're going to say snappy :-) [08:53] 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] nanodrone: I think it doesn't matter if you are a beginner or not, it depends on what you want to do [08:54] nanodrone: snappy has wider scope [08:54] zyga— worse, I can't see why prepare failed :-/ [08:54] flatpak seems like a fedora/redhat project, and snappy seems more debian/ubuntu (i dont know much) [08:55] fgimenez: sure, checking [08:55] where's the snappy hello-world page? [08:55] 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] nanodrone: everyone makes a living somehow [08:55] nanodrone: did you see snapcraft.io? [08:56] 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] tests/main/interfaces-snapd-control [08:56] of course. [08:56] aha [08:56] -- /tmp/go/src/golang.org/x/crypto/ssh/session.gotee: /tmp/autopkgtest.1y2jH6/integrationtests-stderr: No space left on device [08:56] no space left on device [08:56] may be a test bed failure more than our fault [08:56] but there's no hello world like flatpak, there should be one dont you think [08:57] i really liked that they have a hello world page. [08:57] zyga: I don't understand what you are doing with your remark on PRs and failures? [08:57] nanodrone: what do you mean a 'hello world' page? [08:57] it makes it less scary to start learning fast [08:57] pedronis: I'm going through all the PRs that have failing tests [08:57] zyga— http://flatpak.org/hello-world.html [08:57] pedronis: and try to figure out what is wrong [08:57] just look at this and you'll know what i'm trying to say http://flatpak.org/hello-world.html [08:57] 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:58] nanodrone: go to https://snapcraft.io/ and scroll to "hello-world" [08:58] nanodrone: and then read https://snapcraft.io/create/ [08:58] pedronis: some failures are racy tests [08:58] zyga: yes [08:58] so? [08:58] pedronis: some failures are buggy code or buggy tests [08:59] pedronis: I'm trying to make our tests less broken [08:59] i already did, but i'm saying shouldn't there be a big hello world link somewhere... [08:59] mvo: ok thanks [08:59] like at the very top [08:59] 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 [09:00] nanodrone— the "create" link is at the very top though [09:00] 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] pedronis: aha, sorry [09:00] pedronis: I assumed you did as it was in the overlord/state engine parts [09:00] nanodrone: have you seen https://tutorials.ubuntu.com/tutorial/create-first-snap? That's less scary than create [09:00] (in terms of time investment) [09:00] no i haven't davidcalle [09:00] thanks. [09:01] davidcalle— I think nanodrone's point, which is valid, is that it's not easy to find that page [09:01] zyga: no, I think mvo wrote that bit [09:01] pedronis: I see, thanks! [09:01] Chipaca: there is change coming next week on this front, tutorials being front and center [09:01] zyga: anyway maybe better using a forum posts to collect these? or something, lots of micro pings on these are not helpful [09:02] Chipaca: nanodrone: so yeah, I fully agree [09:02] 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] it can be an orange creat/hello world link, super friendly [09:02] create* [09:02] nanodrone— the problem is that the snapcraft.io is not only for developers [09:03] who is it for then [09:03] so not everybody there will want to jump straight for creation [09:03] nanodrone— users? system integrators? [09:03] nanodrone— packagers? [09:03] pedronis: yeah, I'll start tracking those on the forum [09:04] 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] but i'm a user and a developer and i'm being referred to that site... [09:04] pedronis: yeah, I understand [09:04] ttyl [09:05] nanodrone— "not only for X" does not mean "not for X" [09:05] in any case i look forward to the new thing, davidcalle [09:05] so it's really broad [09:05] also i need to get back to work [09:06] either way i'm packaging using snap now. [09:06] time already invested. [09:07] zyga: happy to help with the test, is that the same prune one we talked about before? [09:07] mvo: no, actually, is a new/modifired test in your refresh schedule branch [09:07] so why zyga pinged me is even more mysterious [09:08] mvo: but yes all Prune tests seem prone to fail because of slowness/raciness [09:08] 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:38] re [09:39] ah, what a great idea to move and work at a library [09:39] it's summer all around :) [09:41] pedronis: I started the thread as suggested [09:42] 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] PR snapd#3135: interfaces/mount: add high-level Profile functions [09:42] PR snapd#3095: cmd/snap-update-ns: add C preamble for setns [09:42] zyga: the issue why we don't mock the time is that the time is checked in a different package [09:43] Son_Goku, zyga: ok, I've found the problem why snapd.socket doesn't get enabled on Fedora [09:43] Son_Goku, zyga: the rpm macro only calls systemctl preset [09:43] and we don't install any preset file for systemd [09:43] so systemctl doesn't know what to do and leaves the units unstarted [09:44] 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] pedronis: thank you for the insight, if you comment on the forum I can try to implement your idea [09:45] 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] morphis: and if I systemctl status snapd.socket it does say vendor preset: enabled [09:46] morphis: I'm installing Fedora 24 Server now, let's see what we get there [09:46] zyga: yeah its there [09:46] in /usr/lib/systemd/system-presets/90-default.preset [09:46] zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367932 [09:47] morphis: so I don't think I understand your comment, let me re-read [09:47] morphis: so we don't install any preset file, yes [09:47] morphis: should we? [09:48] no [09:48] its done by the system [09:48] and snapd.socket is already [09:48] if you install snapd you need to reboot, then snapd.socket is started [09:48] morphis: aha [09:48] morphis: so is this a bug in the preset system or in our %post script/ [09:48] but wondering if we're allowed to do systemctl start snapd.socket [09:48] zyga: presets only allow enable/disable as far as I know [09:49] https://www.freedesktop.org/software/systemd/man/systemd.preset.html [09:50] morphis: aha [09:50] morphis: let's ask what Son_Goku thinks, we can also ask for advice on the fedora mailing list [09:51] yeah that would be my next step, hardcoding a `systemctl start snapd.socket` in the spec file doesn't sound great [09:51] but let me see if I find other examples [09:51] morphis: I think it is not allowed [09:54] yeah most likely [09:58] zyga: ok, looks like this is the default, you need to reboot to get the service active, no direct start [09:58] zyga: same happens for lircd.socket for example [10:03] morphis: aha [10:03] morphis: we can say something like that in %post maybe, is there a way to signal this to the user? [10:05] zyga: not sure, asking on fedora-devel now [10:05] as even https://fedoraproject.org/wiki/Packaging:DefaultServices isn't saying anything about this [10:05] but would expect on systems like a server you want services to run out of the box after installation without manual work [10:06] zyga: posted some diff pastebin in the forum [10:06] pedronis: thanks! [10:14] morphis: FYI, rebooting on f24 doesn't start the socket [10:15] morphis: vendor preset is disabled [10:15] zyga: can you check /usr/lib/systemd/system-presets/80-default.preset? [10:15] zyga: looks like they only submitted packages for 25 with https://bugzilla.redhat.com/show_bug.cgi?id=1367932 [10:16] Bug #1680011 opened: snapd support for xdg-desktop-portal [10:17] morphis: looking [10:19]