=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === phoenix_firebrd is now known as murthy === epod is now known as luk3yx === StoneTable is now known as aisrael === Mirv__ is now known as Mirv [06:16] morning [06:17] starting later today, had to drive kids to school === iliv_ is now known as iliv === chiluk_ is now known as chiluk [07:02] Hey mborzecki [07:02] Friday comes so quickly lately [07:02] zyga: hey [07:04] morning [07:08] pstolowski: hey hey [07:09] btw. godbus and our unit tests are a bit messy [07:10] PR snapd#6046 closed: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY [07:10] Thank [07:17] PR snapd#6045 closed: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available [07:22] need coffee [07:47] Chipaca: what do you think about https://github.com/snapcore/snapd/pull/6042#discussion_r228421624 ? [07:47] PR #6042: overlord/standby: fix a race between standby goroutine and stop [07:50] mborzecki: not a lot [07:51] mborzecki: coffee hasn't kicked in [07:52] Chipaca: heh same here :) [08:00] mborzecki: so [08:01] mborzecki: that channel in the test still has the same race [08:01] mborzecki: unless i'm missing something :-) [08:01] let me apply it locally to test [08:02] Chipaca: ok [08:05] mborzecki: hm, the patch won't [08:05] won't patch i mean [08:05] Chipaca: doesn't apply? [08:05] right [08:06] sec, i'll give you a link then [08:06] Chipaca: https://github.com/bboozzoo/snapd/commit/ed331c0c44b8fd776cca49ed1e8a34060eb682e9 [08:07] mborzecki: did you know you can add ".diff" to the end of that? [08:07] omg, really? :) [08:07] yep :) [08:08] damn, it works [08:08] anyone for a trivial remove PR https://github.com/snapcore/snapd/pull/6047 ? [08:08] PR #6047: cmd: remove remnants of sc_should_populate_mount_ns [08:09] sorry for starting late [08:09] I feel so sleepy [08:09] yesterday was good though, some useful things got done [08:11] https://github.com/snapcore/snapd/pull/6019 needs a 2nd review [08:11] PR #6019: ifacestate: optimize disconnect hooks [08:12] Chipaca: you commented on https://github.com/snapcore/snapd/pull/6016 before, a formal +1 or -1 would help to decide [08:12] PR #6016: [RFC] move various name validation helpers to snap/name package [08:12] zyga: there was a chunk of discussion of the pr, i need to re-read it a bit [08:13] thanks, sure [08:13] disclaimer: I'm not trying to be pushy, just looking at PRs top to bottom [08:14] so i'm reading dbus spec and find this: It could be ASCII or UTF-8, but could also be ISO Latin-1 or any other encoding. [08:15] aka. surpsise string [08:15] PR snapd#5958 closed: NOT-REVIEW: tests: Add debug info main suite [08:15] PR snapd#6008 closed: client, daemon, cmd/snap: indicate that services are socket/timer activated [08:16] mborzecki: aka what were they thinking? [08:16] mborzecki: what could be? [08:18] Chipaca: linux security label [08:18] ah [08:18] pstolowski: is https://github.com/snapcore/snapd/pull/5962/files read y for review? [08:19] PR #5962: ifacestate/hotplug: hotplug handlers [08:19] mborzecki: about standby, I wonder about the need of the nested goroutine [08:19] zyga: yes [08:20] Chipaca: hm maybe, i wrote that before morning coffee [08:20] mborzecki: it seems to me (but i could be wrong) that the second (outer) goroutine and the stopDone channel are spurious [08:20] mborzecki: want to merge your changes, and i push more onto it? i've got a couple of tweaks (one of them, dropping that outer goroutine) but otherwise lgtm [08:21] ogra_: can you please check https://github.com/snapcore/snapd/pull/5915 [08:21] PR #5915: interfaces/network-setup-control: allow calling netplan generate/apply [08:21] i'm not convinced the channel dance is better than the wait, in that i'm not sure it's racy in the same way (just less likely because it's using the 200ms wait from the standby instead of an external 50ms wait) but if you are, i'm happy [08:21] Chipaca: you want to merge the whole PR or should i just push that patch to the branch? [08:22] mborzecki: to the -proposal branch? [08:22] ok [08:22] mborzecki: I don't mind [08:22] mborzecki: I already pushed to yours:-) [08:23] mborzecki: i do that, and then you merge once we agree? [08:23] Chipaca: sgtm [08:24] mborzecki: could you please check https://github.com/snapcore/snapd/pull/5789 [08:24] PR #5789: snap: only show "next" refresh time if its after the hold time [08:25] Chipaca: can you look at https://github.com/snapcore/snapd/pull/5712 - it is green and has two reviews, I wonder if we should just merge it [08:25] (perhaps re-triggering tests to see if it really passes now) [08:25] PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates [08:28] zyga: no plz [08:30] zyga: samuele hasn't merged it because it needs more tests [08:30] k [08:30] I'll add blocked [08:31] zyga: add a comment about why, then :-) [08:31] zyga: 1 sec let me give you a link [08:31] done [08:31] oh? [08:32] just comment on the PR :) [08:32] zyga: https://irclogs.ubuntu.com/2018/10/04/%23snappy.html#t19:52 [08:33] ta [08:33] commented also [08:33] PR snapd#5885 closed: Adding DPDK interface for DPDK Snap [08:34] with a few simple reviews we will be on one page [08:36] PR snapd#6047 closed: cmd: remove remnants of sc_should_populate_mount_ns [08:37] Chipaca: can we merge https://github.com/snapcore/snapd/pull/6025 or would you rather wait until Gustavo sees it? [08:37] PR #6025: Add go.mod files [08:37] * zyga goes to review https://github.com/snapcore/snapd/pull/6034 [08:37] zyga: it feels like he should be at least aware of it, n'eh? [08:38] PR #6034: many: save media info when installing, show it when listing [08:38] yep, I'll add blocked [08:38] zyga: and tag him please [08:38] zyga: 6034, tag it for pedronis please [08:38] zyga: thank you :-) [08:38] k [08:40] mborzecki: tell me what you think of that (re 6042) [08:44] degville: morning sir [08:58] Chipaca: morning! [09:00] degville: was just wanting to check if you'd had time to look at the changes to https://github.com/snapcore/snapd/pull/5955/files [09:00] PR #5955: cmd/snap, tests: snapshots for all [09:00] Chipaca: yes, sorry - looking now. [09:01] degville: ok no problem [09:01] degville: thank you [09:07] PR snapd#6049 opened: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection [09:07] Chipaca: zyga: hope this may fix userd/dbus issues we're seeing in tests [09:07] ^^ [09:07] looking [09:07] mmm [09:10] mborzecki: I'm not familiar with private connections, can you explain that a little more? [09:10] the code looks fine [09:10] just not sure I understand the problem enough to give meaningful vote [09:10] zyga: that's just a separate connection, i.e. with the changes the DBus test suite and userd use separate connections [09:11] for test suite I sort of understand [09:11] but for userd I don't [09:11] separate from what/ [09:11] from nothing else atm [09:12] aha [09:14] mborzecki: the problem is that the dbus module shares the connection? [09:14] Chipaca: yes [09:14] ie two things doing dbus.SessionBus() get the same thing [09:15] yup [09:15] ahh [09:15] and then one of them closes it and the other one says 'wuuut' [09:15] that's wonky [09:15] +1 then [09:15] and if you do say go test -count=n it breaks too [09:15] yeh :-) [09:17] now i need to remind myself of what i was doing before i started fixing those tests :) [09:18] can you review https://github.com/snapcore/snapd/pull/6048 before doing that :D [09:18] PR #6048: cmd/snap-exec: don't fail on some try mode snaps [09:22] Chipaca: now that i see it, `opineReady <- struct{}{}` could be just `close(opineReady)`, but otherwise +1 [09:23] actually I'll push that [09:26] Chipaca: pushed [09:26] mborzecki: :-D [09:26] so now zyga and pstolowski must approve :P [09:27] which one? [09:27] zyga: #6042 [09:27] PR #6042: overlord/standby: fix a race between standby goroutine and stop [09:27] mborzecki: after the media PR from John [09:27] brb, coffee [09:30] Chipaca: don't remember, did we already have a pr for blocking installing confined snaps with --classic? [09:31] or was it you working on this? [09:32] mborzecki: #6039 [09:32] PR #6039: snapstate: do not allow classic mode for strict snaps [09:33] not super happy with that pr [09:33] but i can only so much [09:33] but, no error kind, meaning no user-facing error message [09:33] heh, surising that someone actually tries to install snaps like this [09:33] mborzecki: it's the same person that 'rm -rf /' on a core system to see if they could break it [09:34] :-D [09:34] (hint: they could) [09:34] i think rm -rf / doesn't work anymore [09:34] not without some extra --foo switch [09:34] well, they had to add the --extra-foo [09:34] --no-preserve-root [09:35] popey: hush you'll blow your cover [09:35] --i-know-what-im-doing --honest [09:35] mborzecki: the fix to that was making things immutable, but testing it is a pain [09:35] well, there should be a switch for dd to :P [09:36] mborzecki: so we've got a chattr implementation to do it, but didn't get to _actuallly_ do it :-/ [09:36] mborzecki: linux is going soft in its old age [09:37] these days you can't even mkfs /dev/sda without it saying "are you sure dude?" [09:37] haha [09:50] #6039 unit tests are passing locally, but not on travis [09:50] PR #6039: snapstate: do not allow classic mode for strict snaps [09:50] hm maybe something new in master [09:52] another question... If I install a snap from the store, then install a development version of it (using --dangerous), would the pre-refresh hook run? [09:52] pstolowski: ^^ [09:54] tomwardill: yes [09:54] pstolowski: lovely, thankyou [09:55] Chipaca: I reviewed the media PR [09:56] looking at https://github.com/snapcore/snapd/pull/6042/ [09:56] PR #6042: overlord/standby: fix a race between standby goroutine and stop === chrisccoulson_ is now known as chrisccoulson [10:25] looking at it as well [10:25] zyga: https://play.golang.org/p/lRvxLmTlypq [10:26] right, I get that but I think the wording is unintuitive [10:27] ah ok [10:27] * Chipaca goes to the gym [10:30] * Chipaca really goes [10:40] #6019 needs 2nd review [10:40] and is green [10:40] PR #6019: ifacestate: optimize disconnect hooks [10:41] shall we land #6042? or does anyone want another look? [10:41] PR #6042: overlord/standby: fix a race between standby goroutine and stop [10:41] PR snapd#6049 closed: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection [10:59] * pstolowski lunch [11:23] Chipaca: do you have any tests skipped in overlord/snapstate? [11:24] mborzecki, hey, about the error on + systemctl restart snapd.socket [11:24] Job for snapd.socket failed. [11:24] cachio: hi, any progress there? [11:25] mborzecki, well, it is fixed if I restart snapd.service too [11:25] It is like a race with the dependencies [11:26] I see in the logs that snapd.seeded.service fails to restart [11:26] and then snapd.socket fails too [11:26] it is happening mostly on debian [11:27] is it a good solution to restart the snapd.service as well? [11:28] hm i think snapd.seeded fails because the socket failed [11:29] cachio: if you restart snapd.service then it won't be socket activated in the tests anymore [11:29] I am restarting both in fact [11:29] snapd and snapd.socket? [11:29] mborzecki, does it make sense? [11:29] yes [11:30] cachio: show abou systemctl stop snapd && systemctl restart snapd.socket ? [11:30] maybe it's snapd proper and systemd racing to creat the socket? [11:30] yes, systemctl restart snapd.{service,socket} [11:32] PR snapd#6050 opened: overlord/snapstate: run tests for classic snaps even on systems that don't support classic [11:33] mborzecki, this is the error https://paste.ubuntu.com/p/6mNsDRNRYy/ [11:34] that's why I restarted first the snapd service [11:36] Chipaca: joining us for snapd catchup? [11:38] * popey assumes not [11:53] popey: sorry :-( [11:53] popey: was mvo there? [11:53] mborzecki: tests skipped where? [11:56] mborzecki: $ grep -r '\.Skip(' overlord/snapstate/ | sort | uniq -c [11:56] 12 overlord/snapstate/snapstate_test.go: c.Skip("no support for classic") [11:56] Chipaca: right, but if you run go test overlord/snapstate then there are no tests skipepd on your system, right? [11:56] mborzecki: a ver...? [11:58] mborzecki: OK: 461 passed [11:58] mborzecki: compare with go test -v -short cmd/snap: OK: 330 passed, 13 skipped [11:58] ./cmd/snap i mean [11:58] mborzecki: why? [11:59] Chipaca: #6050 makes all of overlord/snapstate run on my system [11:59] PR #6050: overlord/snapstate: run tests for classic snaps even on systems that don't support classic [11:59] why wouldn't it? [12:00] does your system not support classic? [12:00] Chipaca: no, arch does not [12:00] aw [12:01] i can add symlink, but the tests shouldn't rely on that [12:01] right [12:01] given they should be setting global root to some tmpdir, they could create the symlink in there [12:03] dang i need to make lunch for the troop [12:03] brb [12:04] PR snapd#6048 closed: cmd/snap-exec: don't fail on some try mode snaps [12:05] Chipaca: np, sadly not [12:10] off to pick up the kids [12:23] zyga, that netplan PR requires some extra time for re-doing my snap with changed profile etc ... that will still take a bit ... though jdstrand pointed to a thread where it all has been tested, we should probably just use that as input [12:23] ogra: thanks, anytime you can do it is fine [12:24] greyback, yo ! ... i'm trying to get a simple SDL2 pictureviewer to work natively on mir-kiosk, i belive everything is correct but i still end up with "SDL Failed to create window: failed to create a window surface" when trying to start the app [12:24] greyback, the tutorials are rather sparse in that regsrd [12:25] *regard [12:25] ogra: for a reason :) Every toolkit can/wil be different [12:26] ogra: if you test on your desktop, does it work? So run miral-kiosk, then set the wayland socket env var, and run that sdl app [12:26] greyback, well, i dont want to use xwayland (which i surely could as fallback) ... [12:27] greyback, hmm whats that var ? do i need to explicitly set it in a kiosk launcher ? (i see the wayland-0 socket) [12:28] ogra: ofc. Pure SDL2 should work on top of Mir. I've not tried it in a while. What app? [12:28] imv ... but with a wrapper etc [12:28] ogra: that mir kiosk launcher script will take care of the env var for oyu [12:28] which one ? i wrote my own :) [12:29] ogra: "miral-app" [12:29] well, how do i get that into my snap ? [12:29] mir-kiosk surely doesnt ship it [12:30] ogra: nope it doesn't. I'm not worrying about snaps just yet, I want to check that sdl app runs on top of Mir at all [12:30] well, where is the source for miral-app so i can pull it into my snap ? [12:30] greyback: what sdl2 apps have you tried? [12:31] https://tutorials.ubuntu.com/tutorial/wayland-kiosk#3 is really sparse ... [12:31] err https://tutorials.ubuntu.com/tutorial/wayland-kiosk#0 [12:31] ogra: https://github.com/MirServer/mir/blob/master/examples/miral-shell/miral-run.sh [12:32] ogra: yes you're right, it is sparse [12:33] Chipaca: i was going to raise this at the meeting btw. https://forum.snapcraft.io/t/ubuntu-core-doesnt-batch-reboots/8174/1 [12:33] ogra: ^ I mentioned before that core reboots multiple times, this shows it [12:34] popey: tbh I didn't. I snapped gtk2/3 and qt4/5. I know sdl2 works on mir, I never tried snapping one [12:34] be nice to have some hello world level tutorials of those [12:34] which aren't massively wordy tomes [12:34] Chipaca, mborzecki, zyga, cachio I'll probably miss the standup, need to pick up my daughter returning from school trip [12:34] just "here's the yaml, here's the snap, done" [12:34] pstolowski: ack [12:35] popey: agreed [12:35] popey: here's the jam, here's the snack, done [12:35] ;-) [12:38] cprov: is there any more comprehensive docs on using surl than the readme? [12:39] surl? [12:39] curl? [12:40] * diddledan hurls the surl with a curl making it whirl. [12:41] https://github.com/cprov/surl / https://snapcraft.io/surl [12:43] yeah, that readme needs moar details [12:43] popey, yeah, saw the post [12:44] e.g. what is the `-a` parameter for? does it accept anything other than `stg-reg`? what does `stg-reg` even mean? [12:44] greyback, ok, now after setting MIR_SOCKET and WAYLAND_DISPLAY (i made sure i can see and access the files they point to), i get "SDL Failed to Init: wayland not available" [12:45] diddledan: oi! I was first in the queue! :D [12:45] popey: 2x2? [12:45] :) [12:45] * diddledan holds popey's hand and stands along side to go in together like good little boys [12:46] oh, surl is nice :) [12:47] Chipaca: did you see that a? [12:57] re [12:57] surl? small curl? [12:59] zyga: which a? [12:59] the one before b ? [12:59] sorry, not a ;) surl [12:59] zyga: i have not. Have you seen icdiff? [12:59] no I have not [13:00] now we're even [13:00] * Chipaca heads to the standup [13:00] or is that stands for the standup [13:21] greyback, ogra: Re: chromium-mir-kiosk rotation issue – here are my findings https://forum.snapcraft.io/t/cross-post-chromium-mir-kiosk-in-portrait-mode-rotated-mir-kiosk-layout/8175 [13:23] dot-tobias, did you consider simply not using i3 ? [13:25] dot-tobias: thanks for that excellent post. [13:25] ogra: I do, but I am completely out of my depth here when it comes to display servers and the likes. And I need to get a portrait mode-kiosk running ASAP because the beta testers are already waiting 😄 [13:26] dot-tobias: I'll see what I can figure out now then [13:26] dot-tobias: you're making a product with it? [13:27] dot-tobias, well, i have the mirkiosk snap in the store that i'm planning to do an appliance with soon ... but i wot start on the integration work before next week ... then i'll hit (and hopefully solve) the same issues [13:28] currently i'm sadly struggling with unexpected SDL2 issues for a native wayland slideshow appliance (picture-frame appliance) [13:29] err [13:29] s/mirkiosk/magicmirror/ [13:29] silly typo ... too much mir in my head now [13:30] ogra: 😄 Excited to see how you'll tackle these issues (with way more proficiency in this stack) [13:31] i'll probably simply hack around the issues i hit ... like using matchbox or openbox if they can behave more dynamic than i3 ... or hacking xrandr calls into the launcher or some such :) [13:32] ogra: I am excited to see magicmirror as a snap, I've got a Pi display on it's way to me atm [13:32] i also still have to solve some issues with magicmirror itself ... getting the modules in a writable area while keeping the runtime code readonly seems extremely hard without patching upstream [13:33] i initially tried to simply ship all available modules by default ... but somehow a 6.2GB source tree resulted from that (and a 700MB snap) ... that feels a bit like overkill :) [13:34] degville: writing is hard. Maybe I'll just replace the help text with emoji. [13:34] degville: 📸🖒 [13:34] Chipaca: yeah. [13:34] +1 [13:35] ogra: I'd probably try and get a config variable or something upstreamed at that point [13:35] but I've no idea how feasible that is [13:35] yeah [13:36] i havent talked to upstream yet ... the prob is that the code uses relative paths inside ... like ... everywhere [13:36] foo=../../bar ... and such [13:36] as soon as you operate with a symlink into $SNAP_DATA these relative paths break [13:37] ogra: keeping in mind i have no context, layouts might help [13:37] sigh ... so mir and SDL2 seems like a no-go ... and i dont really want the 120MB overhead adding the desktop launcher and xwayland stuff :(((( [13:38] Chipaca, they do, but are they not holding my snap upload anymore at the review steap ? [13:38] *step [13:38] ogra: My use-case is a smart mirror as well 😊 And layouts (plus massive help from zyga) helped tremendously to cope with Rails and its assumption that everything lives inside its root directory. [13:39] Chipaca, developing on core requires a painful amount of patience since all features i need to use make my packages go stuck until jdstrand finds the time to review ... [13:39] so i always try to find a way around experimental features if possible [13:40] it typically means my turnaround time for finishing a demo extends by about a week [13:41] PR snapd#6051 opened: cmd/snap-update-ns: parse the -u command line option