[02:25] PR snapd#4371 opened: tests: add support on tests for cm3 gadget [06:02] morning [06:38] zyga-ubuntu: hey [06:41] mborzecki: good mornin [06:41] :) [06:41] mborzecki: my last day this year [06:41] taking the rest of the year off? [06:44] yes [06:44] though I need to check again, but that's the plan [06:45] that's so nice, wish i had that many days of vacation left :) [06:46] haha, I wish I hadn't [06:46] the weather was better in the summer [06:56] mborzecki: and I have three carry-over days [06:58] mvo is not around yet [06:58] yesterday I took a detour to play with base-18 [06:58] it was really fun, especially now that we can test boot it [07:02] that'll be based on 18.04? [07:10] yep [07:10] try it [07:10] it should work for you :) [07:16] zyga-ubuntu: do you have any prs in need of review that you'd like to close before you go? [07:18] mborzecki: yes, the two that are open [07:18] #4315 #4329? [07:18] PR #4315: cmd/snap-update-ns: add execWritableMimic [07:18] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [07:24] yes [07:29] PR snapd#4361 closed: devicestate: fix misbehaving test when using systemd-resolved [07:31] PR snapd#4360 closed: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 for 2.30 [07:38] hmm [07:38] the github merge conflict resolution tool is weird [07:38] it always has to run twice [07:38] WT? [07:38] look at 4343 [07:38] last two commits [07:38] one is empty, one is the real merge [07:40] zyga-ubuntu: posted some comments to 4329 [07:42] thanks, replied; I'll add the enum [07:43] ok, thanks [07:43] zyga-ubuntu: btw. what did you mean here: https://github.com/snapcore/snapd/pull/4354#discussion_r155448107 ? [07:43] PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare [07:45] morning o/ [07:45] o/ [08:25] pstolowski: hey [08:25] pstolowski: some small conflicts on your PRs [08:25] pstolowski: good morning :) [08:26] zyga-ubuntu, morning! ok, looking [09:12] drat my seageate disks [09:12] I will never buy from that vendor again [09:23] zyga-ubuntu: did they break for good? [09:23] no, just definitely started to fail [09:40] PR snapd#4343 closed: interfaces: rename sanitize methods [10:15] PR snapcraft#1797 closed: tests: update the snap name already registered for store tests [10:18] PR snapcraft#1757 closed: Saving snap-build assertion as '.build' [10:21] a little bit more [10:22] and I should have spread support for base 18 [10:28] man, iteration is painful [10:28] snapcraft clean, snapcraft takes a good chunk of time [10:40] whee, another boot attempt [10:46] ogra@pi3:~$ snap set core service.rsyslog.disable=false [10:46] error: cannot perform the following tasks: [10:46] - Run configure hook of "core" snap (run hook "configure": [--root / enable rsyslog.service] failed with exit status 1: Synchronizing state of rsyslog.service with SysV init with /lib/systemd/systemd-sysv-install... [10:46] Executing /lib/systemd/systemd-sysv-install enable rsyslog [10:46] insserv: warning: current start runlevel(s) (empty) of script `rsyslog' overrides LSB defaults (2 3 4 5). [10:46] insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' overrides LSB defaults (0 1 6). [10:46] Failed to execute operation: Unit file is masked [10:46] ) [10:46] hmm [10:48] (this is on edge, latest core) [10:48] i guess mvo's new config handling broke .. [10:49] (looks like it tries to call "enable" before "unmask") [11:04] ogra_: look at the code it doesn't seem like that, Unmask is called before Enable [11:04] *looking [11:05] pedronis, yeah, i had a week old hanging core iwith a Doing task [11:05] aborting and manually refreshing fixed it [11:06] (see bug 1736922 (already closed again)) [11:06] Bug #1736922: new config handling breaks re-enabling of rsyslog [11:12] * kalikiana considers fixedly-postmenopausal-tamesha as a runner up for most ridiculous pet name of the week [11:18] hmmm [11:18] so why are services not starting [11:18] I systemctl enable stuff [11:18] and yet it's not up [11:22] brr [11:22] need warm tea [11:25] it's 5C outside, that's warmer than on Monday :) === mborzeck1 is now known as mborzecki [11:28] PR snapd#4314 closed: interfaces: use ConnectedPlug/ConnectedSlot types (step 2) [11:29] mborzecki: mwhudson recently complained about how warm it is in new zaeland [11:29] *ea [11:31] yay, all interface hooks prerequisites landed :) [11:44] sigh [11:44] little by little [11:44] PR snapd#4366 closed: interfaces/removable-media: also allow 'k' (lock) [11:44] PR snapd#4367 closed: interfaces/removable-media: also allow 'k' (lock) for 2.30 [11:44] does anyone have any idea why a certain unit is not started? [11:44] when systemd says "vendor preset: enabled" [11:46] nothing in syslog ? [11:46] well [11:46] not sure what to look for [11:46] this is very barren still [11:46] typically stdout from units goes there [11:46] I have a minimal 18 base [11:47] ogra_: I doubt it is started [11:47] it works when started manually [11:51] I'll read it the hard way [11:52] zyga-ubuntu, hey, I'll be 5 minutes late today [11:52] cachio: that's ok [11:52] cachio: we're still starting in one hour [11:52] right? [11:52] PR snapd#4372 opened: snap: YAML and data structures for app before/after ordering [11:52] trivial PR ^^ [11:53] done [11:53] zyga-ubuntu, yea === kennyloggins is now known as CoderEurope [11:56] cachio: did you manage to figure something out with the rpi test that was failing? === CoderEurope is now known as kennyloggins [12:03] aha [12:03] so it seems (maybe) that it is snapcraft [12:13] gah [12:13] no, [12:13] WTF [12:15] so, /etc/systemd/system is empty after booting [12:16] but it's not empty in the core snap [12:16] WTF [12:16] ah [12:17] all is clear now [12:17] thats system-data [12:17] sooooo [12:18] /etc/systemd/system should be handled via writaable-paths [12:21] (in synced mode FWIW) [12:30] Hey folks. snap set core proxy.https=https://my.proxy:3128 does seem to have any affect, on 2.29 or 2.30, on classic. Is this a Known Issue? [12:34] gah s/affect/effect [12:41] bloodearnest: yes, except proxy.store all the other core config are core only, now that handling has been moved we need to decide which one make sense/are sane on classic too [12:41] ok [12:42] bloodearnest: it's not a regression, always been like this so far [12:42] thx [12:43] pedronis: ok. Related question, assuming some future where proxy.https can be set on classic, is there a way for another snap to access core config, via snapctl inside the snap, or similar? [12:45] bloodearnest, snapd's systemd unit sources /etc/environment ... if you have your proxy settings in there and restart snapd it should just pick that up [12:45] (that indeed assumes a system wide proxy) [12:46] bloodearnest: not at the moment, a snap would need snapd-control and go through the REST api directly or use snap (I don't remember if we make available there) [12:47] pedronis, i suspect even then you would miss access to core-support (which the config hook uses) ... or would that be just internally used when calling set/get ? [12:47] ? [12:48] you can do snap get core [12:48] or the equivalent with the REST api [12:48] not sure how core-support (which is not needed anymore) relates [12:48] ah, wh is it not needed anymore ? [12:48] *why [12:49] because the hook is going away [12:49] oh, indeed, silly me [12:49] as far as I know we have core-support just for the configure hook inside core [12:49] it is snapd itself now [12:49] right [12:49] for allowing the shelling out to particular system binaries [12:50] but indeed ... not needed when snapd manages it ... thanks ! [12:50] yea, that's why I said not sure, but if you have snapd-control you can use the REST api [12:50] but there's no other way to peek at other snap configs atm [12:50] nor any special exception around core config [12:53] bloodearnest: there is some idea that snapctl should give access to some safe system information (not specifically config keys) but nothing has happened yet of that === alan_g is now known as alan_g|lunch [13:05] cachio: standup [13:05] pstolowski: standup [13:11] * ogra_ wonders when this "snap list" on his non-networked kvm will return ... it is sitting there since several minutes now [13:11] dont we have a timeout ? [13:12] ogra_: i saw that recently on a machine which had selinux blocking. it didnt timeout, ever [13:12] just sits there, and journalctl shows selinux blocking errors [13:12] well, its a kvm core image nad my host has somehow messed up the forwarding ... [13:13] so the kvm machine thinks it has network but i cant ping anything outside [13:13] it still sits there btw ... [13:13] worth a look in the journal/syslog anyway [13:13] seems to never time out [13:14] PR snapd#4371 closed: tests: add support on tests for cm3 gadget [13:15] wow [13:15] http://paste.ubuntu.com/26132566/ [13:15] so snapd crashes (it then restarts though and seems to run proper) [13:15] oh, it finally returned the list ... only took really long [13:15] :) [13:16] over 10 min [13:17] but that above was only on boot ... the actual "snap list" call doesnt produce any log output === chihchun is now known as chihchun_afk [13:18] sadly even snap changes hangs [13:19] hmpf [13:26] ann: if anyone pinged me in the past 2 hours I lost it === chihchun_afk is now known as chihchun [13:33] mvo: some more progress, spread now starts the vm but fails to log in because /home is synced and that kills my test-only /home/ubuntu directory; I removed most of writable paths (including home), let's see what this looks like [13:34] zyga-ubuntu, dnot forget writable-paths has individual settings (two way, three way merge or completely persistent) the single dirs behave differently usually [13:34] ogra_: right, I have a custom conifg [13:34] *config [13:35] this is just a temporary step [13:35] towards something I can spread test and test boot rapidly [13:35] and in the end get a working environment for interation [13:35] I think we want to remove writable-paths entirely [13:35] yeah, i get that [13:35] (eventually) [13:35] just pointing out a synced dir thats now not synced might break the world :) [13:36] yep, that's all "fine" - we're far away from base-18 working [13:36] heh [13:36] what about doing base-16 first ? [13:36] I need to move the initramfs help [13:36] ogra_: I think that's less interesting as that can stay as a copy of current core forever [13:36] since you will need the split for upgrades [13:37] well, using the base-16 and then shrinking it would be my way forward [13:37] (towards -18) [13:37] not sure [13:37] I think there are lots of challenges in 18 that need to be tackled [13:37] and this is also involving migration [13:37] I want to just do 18 as a clean slate first [13:39] pedronis: zyga: ok, thanks for the info [13:39] sigh ... this snapd in kvm really misbehaves [13:39] error: cannot communicate with server: Post http://localhost/v2/snaps/firstboot-setup: EOF [13:39] for a snap remove ... [13:40] snapd crashed? [13:40] it is running ... the network forwarding outside the VM is broken ... [13:41] so it thinks it is online but i cant ping the outside world (i can ping my lkvm gateway though) [13:41] that makes snapd really misbehave [13:41] ping is broken in user networking [13:41] just don't ping [13:41] $ ps ax|grep snapd [13:41] 965 ? Ssl 0:00 /usr/lib/snapd/snapd [13:42] $ snap remove firstboot-setup [13:42] error: cannot communicate with server: Post http://localhost/v2/snaps/firstboot-setup: EOF [13:42] thats what i get [13:42] oh ? ping is broken ? since where [13:42] any snapd logs? [13:42] ogra_: since forever in user networking, check that if you want to know why [13:42] ogra_: but that's irrelevant for snapd [13:43] 2017/12/07 13:40:14.783948 daemon.go:306: started snapd/2.30~rc1+git467.c2f9631~ubuntu16.04.1 (series 16) ubuntu-core/16 (amd64) linux/4.4.0-102-generic. [13:43] zyga-ubuntu what version of go are you using for snapd? [13:43] looks like it started just fine (thats the last line in the journal) [13:43] sergiusens: 1.6 [13:44] sergiusens: on core [13:44] across the board? [13:44] sergiusens: and reexec [13:44] sergiusens: whatever-is-there on various distros [13:44] ah, the client on whatever the distro is I guess [13:44] sergiusens: kind of, the client on your distro execs the reexec 1.6 binary most of the time [13:48] ogra_, hey [13:48] hey cachio [13:48] ogra_, I was discussing with plars about if we could have ubuntu core images bot beta [13:49] cachio, sure. why not [13:49] ogra_, it could be manually/automatically triggered when a new core snap is in beta [13:50] ogra_, so then we can use those images in testflinger [13:50] cachio, you would need to talk to foundations to get a beta build at http://cdimage.ubuntu.com/ubuntu-core/16/ [13:50] sil2100 does them i think [13:50] ogra_, good [13:50] (unless you will roll them yourself indeed) [13:50] (its always just an ubuntu-image call away anyway ;) ) [13:51] ogra_, where is the code that we use to create the stable / edge images? [13:51] cachio, also a question for foundations ... i only do the images at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ for which the build scripts are local [13:52] (local meaning on my PC) [13:52] ogra_, ah, ok [13:52] ha [13:52] I now know a little bit more about how spread starts up [13:52] ogra_, great, I'll talk to sil2100 in that case [13:52] yeah [13:52] ogra_, tx [13:52] or slangasek ... either of them should be able to point you to the official scripts [13:54] * kalikiana off for lunch in 10min [13:54] * kalikiana getting hungry [13:56] zyga-ubuntu: sorry, in a meeting, nice progress. looking at your open PRs now [13:56] mvo: ok, just need to add sudo right [13:56] mvo: I'll open a 2nd pr for spread [13:57] (for this project, spread is ok) [13:58] mvo: if that's ok with you, i'd like to rebase #4357 on top of #4372 and skip all 'validation' pathes in this PR [13:58] PR #4357: wrappers: autogenerate After/Before in systemd's service files for apps [13:58] PR #4372: snap: YAML and data structures for app before/after ordering === alan_g|lunch is now known as alan_g [14:11] mvo: it works now :) [14:11] mvo: shall I expand the existing PR [14:11] mvo: or do you want to see a 2nd one [14:12] PR snapd#4340 closed: snap: YAML and app validation parts of after/before app startup ordering [14:12] PR snapd#4373 opened: snap: app startup after/before validation [14:13] mborzecki: +1 [14:13] zyga-ubuntu: either way is fine [14:13] zyga-ubuntu: whatever is easier for you [14:13] k [14:17] PR core#66 closed: 500-create-xdg.binary: use "set -o pipefail" [14:18] mvo: the PRs are split now, would appreciate another review :) [14:20] mvo: done [14:20] mvo: please try it :) [14:20] mvo: same PR [14:20] mvo: just look at my master [14:20] mvo: commit history (especially last one) has usage instructions [14:21] mvo: I'll polish this now, slightly, enough to start fixing the issues we see (and add tests) [14:21] mborzecki: great, will look [14:21] zyga-ubuntu: same here [14:21] mvo: thanks [14:21] zyga-ubuntu: \o/ [14:22] i'm off to pick up the kids, afk for now [14:26] jdstrand: hey, I've pushed my WIP to https://github.com/snapcore/snapd/pull/4365/files, can I ask you a couple of things? (1) Am I going too far, enabling proper Wayland compositors, which allows hardware access like Mir has? (2) I've duplicated much of what Mir slot has. is that kosher, or would a shared subclass interface be do-able? [14:26] PR #4365: interfaces/mir: allow Wayland socket and non-root sockets [14:26] zyga-ubuntu: ^^ your opinion also welcome [14:27] greyback: ack [14:43] mvo: ok, I think base-18#8 is ready for review [14:43] mvo: once it lands we can really iterate and propose tests [14:43] zyga-ubuntu: \o/ [14:45] mvo: I'll try to enable travis now [14:45] actually [14:45] hmmm [14:45] I think this will be harder than I anticipated [14:45] unless travis can just run things on top of xenial (maybe) [14:45] why wouldnt it ? [14:46] all y teste run on top of a xenail chroot in travis [14:46] *all my tests [14:46] I need qemu [14:46] and spread [14:47] and kpartx and other maic [14:47] ouch [14:47] may be too much [14:47] yeah [14:47] well, let me grab a coffee and try [14:47] or maybe [14:47] break for lunch and then come back fresh [14:47] ogra_: btw, feedback on base-18 appreciated [14:47] zyga-ubuntu, where do you hide it ? [14:48] ogra_: snapcore/base-18 [14:48] ogra_: see PR #8 [14:48] i wonder why i didnt get PR mail for that [14:52] ogra_: it's brand new [14:53] zyga-ubuntu, you dont install ubuntu-core-config ? [14:53] hwo do you get writable-paths right then ? [14:53] ogra_: I don't even know what is there [14:53] ogra_: note that for testing I steal core-16 intird [14:54] well, it only does a debootstrap minbase and one hook installs systemd and nssswitch [14:54] zyga-ubuntu, right, that will be broken since it wont fint /etc/system-image/writable-paths in the target rootfs [14:54] the initrd needs that [14:54] I think this is a _very_ early core :) [14:54] interesting that you get it to boot at all [14:55] zyga-ubuntu, well, it should badly error before mounting the rootfs when it doesnt find the writable-paths file ... if it doesnt you found actually a bug in the initrd :) [14:55] ogra_: ogra_ I add one [14:55] ogra_: I added that file [14:56] ogra_: anyway, this is really held-with-strings for now [14:56] yeah, understood [14:56] ogra_: I plan to integrate inird code here so that base-18 is separate from base-16 [14:56] ogra_: and then let us iterate with confidence (tests) [14:56] i dont see where you add the file though [14:56] ogra_: hooks [14:56] ogra_: btw, this also includes a small, hand coded ubuntu-image [14:57] PR snapd#4308 closed: packaging/arch: install snap-mgmt tool [14:57] ogra_: again, all optimized for getting started and getting results quickly [14:57] ogra_: I expect everything to change [14:57] zyga-ubuntu, oh, i was looking ast the tree, not the last PR [14:58] ahh [14:59] wow [14:59] re [14:59] what? [14:59] * ogra_ shades his eyes from "create-image" [15:00] is it shiny? [15:00] well ... [15:00] :) [15:00] ogra_: I'd say it's simple [15:00] ogra_: simplest one yet :) [15:01] mvo: updated the comment [15:01] mvo: shall I remove the dist-upgrade too? [15:01] mvo: and note that you have to merge it as I don't have permissions [15:02] mvo: does it work for you :) ? [15:02] (that's most interesting) [15:05] a review for 4372 would be great, should be an easy win :) [15:06]