=== JanC_ is now known as JanC [05:11] morning [05:40] mvo: hi [05:46] hey mborzecki [05:46] mvo: https://github.com/snapcore/snapd/pull/5756 looks like an easy win [05:47] mborzecki: indeed, thank you. technically this needs a review from jamie from security but I'm not sure its really needed for such a trivial one [05:48] mborzecki: how are tests this morning? [05:48] mvo: yeah, those files are just manufacturer an product human readable strings :) [05:49] mvo: hard to tell, restarted a few jobs, but those were failures from yday [05:50] Good morning [05:52] Mborzecki I could use some HO time today [05:52] I found a case that doesn’t work (not trespassing, that is ok) [05:52] And I wanted to discuss if [05:52] It [05:52] zyga: ok [05:53] zyga: good morning [05:54] mborzecki: I will merge once tests are green [05:54] Essentially the case is this: you have a symlink a->b in writable space, you want a->c instead [05:54] Hey. School saga day two [05:54] Today we just bail [05:55] I was thinking we should I link and symlink [05:55] I link and symlink === chihchun_afk is now known as chihchun [06:40] build has failed [06:40] Build #24748 was borken [06:40] hm we're not out of the woods yet [06:43] wonder if we could use the fakestore in those tests [06:49] mvo: can you upload the release files to github? [06:50] mborzecki: yes, sorry, will do so in a minute [06:50] mvo: thanks! [06:51] also looks like master has a problem building on various arches in master :/ oh well, I look at this in a little bit too [06:57] mborzecki: done [06:57] mvo: thank you [06:58] mvo: i'll drop snapd.failure.service and snap-failure at the package level for now [06:58] mborzecki: please do [06:59] a siminiar thing will be needed for fedora (neal if offline?) and opensuse (cc zyga) [07:16] arch package updated [07:16] re [07:16] what's the problem? [07:16] btw, I'm entirely re-working suse packaging [07:17] it's a bit of a sad/happy story that I can share during the standup [07:19] zyga: https://aur.archlinux.org/cgit/aur.git/commit/?h=snapd&id=a23bdc8eb207c2a1312d74377dfcf8e56e25094f [07:19] mornings [07:20] * zyga looks [07:20] hey pawel :) [07:20] * zyga is working from a restaurant garden today [07:20] ahhh [07:20] I see [07:20] thank you for sharing mborzecki [07:21] pstolowski: hey [07:21] btw. have you noticed something about ohmygiraffe, or maybe it's our pulseaudio interface [07:22] when i restart pulseaudio (pulseaudio -k) and start ohmygiraffe after that, there's no sound [07:23] mborzecki: probably different filename/cookie value [07:24] zyga: right, but it's read from .pulse-cookie [07:25] is it? [07:25] it's unlikely [07:27] zyga: i'd gues .pulse-cookie contains the cookie, it's different each time pulseaudio starts, but at the same time i'd expect libpulse to read and use the new cookie [07:27] but the cookie is in a dot file in HOME [07:27] so it's probably not read from that [07:27] probably read from the x server root window [07:28] the log with PULSE_LOG=4 shows it's trying /run/user/1000/snap.ohmygiraffe/pulse/native to no avail [07:29] and $XDG_RUNTIME_DIR/pulse is indeed empty [07:29] i have a vague recollection we fied that in desktop helpers? [07:30] maybe [07:30] but I'd look at xprops [07:30] heh, symlinked in in snap shell, works now [07:30] ln -s ../../pulse/native $XDG_RUNTIME_DIR/pulse/native and magically works :/ [07:31] zyga: xprop -root |grep -i pulse comes up empty [07:32] hmm [07:32] and without pulse? [07:32] anything else there? [07:34] zyga: with or without looks the same [07:34] are you on wayland? [07:37] zyga: no x11 [07:38] ok, so it'd be nice to rebuild the snap to pick up the fixes in snapcraft-desktop-helpers [07:38] in that case my theory is broken, no idea [07:38] we have a fix there already (apparently i was the one to add it) whcih exports PULSE_SERVER [07:40] popey: any chance you could rebuild ohmygiraffe using more recent snapcraft? [07:42] mborzecki: I'm re-working the restricted/desiredPath into a structure that holds the pair [07:45] need conffee [07:48] cofefe [07:49] how do I figure out what settings a snap has? [07:49] btw snapcraft.io times out alot since yesterday [07:55] ah there is a get [08:01] Raboo: hey [08:01] yeah, the store was wonky yesterday, it's all resolved I heard though [08:01] Raboo: snap configuration doesn't have a schema yet but you can indeed use get to look at the data that is set right now [08:01] zyga ok [08:01] zyga: doesn't look resolved to me [08:02] oh? [08:02] the store is still wonky? [08:02] trying out the chromium-mir-store [08:02] s/store/kiosk/ [08:02] zyga: afaict it is [08:02] zyga still wonky [08:02] :/ [08:02] ogra_: xenial or bionic only? if we could find a way to reproduce it, it would be nice [08:04] zyga: It was all resolved, but is having some minor trouble now. Should be working again. [08:04] zyga: please just look at (and refer people to) https://status.snapcraft.io [08:05] thank you, will do [08:05] we (store team) will keep that up to date, and avoids "I heard" games of Telephone [08:07] does the chromium-mir-kiosk people hang here? I'm wondering what I need to do to enable audio and webcam [08:09] Chipaca: good morning! [08:10] Chipaca: I think you tricked me into writing tests for store.go:download() ;) [08:10] mvo: morning! [08:10] Chipaca: we do not test this explicitly, do we? [08:10] mvo: only that if wasn't covered! [08:10] mvo: probably not explicitly, the tests will be fore Download [08:10] or whatever [08:11] mvo: can't you parametrise one of the existing tests? [08:11] mvo: as in, TestDownload(*C) -> testDownloadMaybeWithRateLimit(*C, bool) [08:11] Chipaca: not sure, afaict we mock func download away pretty much everywhere [08:11] hmm [08:11] * Chipaca looks [08:13] Chipaca: I looked at storeTestSuite and in SetUpTest it mocks it away and I don't see where its unmocked :/ but again, maybe blind :) [08:16] hey John, good morning [08:16] mborzecki: hey [08:16] do you have a sec for HO? [08:16] sure [08:16] sec [08:17] zyga: ok, i'm there [08:17] k, joining [08:18] Chipaca: mvo: we should have some tests for download, what I'm not sure is whether we have tests for Download calling download [08:18] pedronis: mvo: look for TestActualDownload [08:18] pedronis: mvo: there are a bunch [08:19] coverage is bright green, not the pale green of only-barely-covered [08:19] zyga: hey zyga [08:19] zyga: I'm assuming you mean me when you say 'hey John' :-) [08:20] Chipaca: mvo: SetUp stores it away to restore, it doesn't mock it afaict [08:20] Chipaca: clearly the tea then, thanks, I will add [08:21] s.origDownloadFunc = download [08:21] Chipaca: to that family plus adding one that does the download directly [08:21] This is my interfaces http://termbin.com/nm9z, do I need to connect anything more to enable camera and audio for chromium-mir-kiosk? [08:21] pedronis: yeah, thanks. I see it now, sorry for the noise [08:21] mvo: well store_test.go is a bit of a jungle [08:22] but at least this bit is kind of straighforward [08:22] pedronis, Chipaca would you mind if I change this to use MockDownload ? to make it a bit more like the other parts? [08:22] pedronis: yeah, sorry again [08:22] (probably in a separate PR) [08:22] I don't know [08:22] pedronis: mvo: it wasn't obvious fwiw, I had to add a panic() to the download() :-) [08:22] it's a step in the right direction otoh I think that file needs a more general attack [08:22] Chipaca: heh, thanks for comforting me :) [08:23] pedronis: I would move the actual download tests into its own suite plus add mocking via export_test.go as a first step. but I'm fine leaving it if there is a bigger plan in place [08:23] mvo: there are not bigger plans [08:24] mostly noticing that Mock* is not used much around there [08:24] mvo: the main issue is really that store_test.go is "package store" [08:25] only unclarity comes from that [08:25] store really needs some love, yes [08:25] it and daemon are the few places left doding that [08:25] pedronis: yeah [08:25] daemon is 100% my fault :-| [08:25] pedronis: I have a look [08:25] * pedronis is only morning and I cannot type [08:25] Chipaca: its the fault of history [08:25] * mvo hugs Chipaca [08:26] :-) [08:27] anyway, back to snapshotstate tests for me [08:38] mborzecki: sure, what's the issue I'm solving by rebuilding omg? [08:41] HAH! found you, you nasty effluvia [08:43] hi. where is "snapctl" localed in the snap? it seems it's not in path by default in hooks [08:43] ppisati, ubuntu core 16 ... 4.4 kernel [08:44] ackk: /usr/bin/snapctl [08:44] Chipaca, oh, wait it seems it's missing in core18? [08:45] ackk: shouldn't be, but :-) [08:45] ackk: do you have core, or snapd snaps? [08:45] ppisati, the systems are all the same, running a webcam with mjpg-streamer (so there is a lot of data going over the net) ... [08:45] Chipaca, I have "core" but the snap I'm working on is based on core18 [08:46] Chipaca, confirmed, no snapctl in core18 [08:46] ackk: right, core18 doesn't ship any of snapd; that's shipped in the snapd snap (in the new world) or in the core snap (in the old world) [08:46] ackk: snapd should be smart enough to find it and put it where it's expected though [08:46] mvo: any issues here ^? [08:46] Chipaca, so how do I base a snap on core18 and use hooks? [08:47] ackk: as I say, it should just work -- you shouldn't need to care [08:47] ackk: you've found a bug, maybe [08:47] ackk: waiting for word from mvo who is the god of core18 and hugs [08:47] Chipaca, should I have a "snapd" snap as well? [08:47] I don't [08:47] ackk: no you should not need it [08:47] ackk: can you check if it's in /usr/lib/snapd/ ? [08:48] snapctl i mean [08:48] ackk: are you using the "beta" or "edge" of core18 ? if not, please try that [08:48] Chipaca, it's not [08:48] mvo, no I'm using stable, I'll try edge [08:49] mvo, that worked, thanks [08:49] mvo, btw are pre-refresh and post-refresh hooks already supported in released snapd? [08:49] ackk: that should work, yes [08:50] cool [08:50] Chipaca, mvo thanks [08:55] pedronis: that thing where the cleanup test would freeze that had me stumped? was an actual bug :-D [08:55] Chipaca: ok [08:56] * pstolowski -> school run [08:57] Chipaca, unrelated, do you know if it's possible to run ssh confied in a snap? I've been trying but it fails on setgroups call and I can't log in [08:58] ackk: ssh should work (there might even be an interface to let it get the host keys); sshd might need tweaking [08:58] popey: the one i know of is it'll get properly exported PULSE_SERVER, so even if you restart pulseaudio the sound will work [08:58] Chipaca: indeed [08:58] Chipaca, right, I want sshd [08:58] ackk: if you arm yourself with logs and patience jd_strand might be able to help [08:59] ackk: sshd has a lot of levers you can pull via config :-) [08:59] ackk: but: if it tries to setuid, it won't work [08:59] Chipaca, right, I've been trying that, including AllowedUsers/Group and so on, but I couldn't get it to work [08:59] setgroups sounds like part of that family [08:59] Chipaca, right, I suspect it would work if it could use a "nobody" user [09:00] Chipaca, basically I wanted an isolated sshd so that I can use it as a target for sshuttle-based VPNs [09:00] ackk: nice [09:00] Chipaca, it would be if it worked :) [09:01] ackk: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461?u=chipaca fwiw [09:02] Chipaca, yeah I know about that thread, it's something we'd like for the maas snap too [09:06] k [09:13] ackk: We discussed the idea of introducing a "daemon" user early on, using the same model of the final design.. might work for those cases before the whole thing is fleshed out [09:13] Mornings, btw [09:16] hi niemeyer, yeah I think that would be enough for our use case [09:16] (daemons that refuse to run as root) [09:17] ackk: Yeah, that's indeed the reason why that idea came up [09:18] pedronis: Settle(t) always take t? I thought it was a maximum but in practice it looks like a mminimum (at least when there's cleanup involved) [09:19] popey, sparkiegeek ping vlc stuck in store [09:20] thresh: hmm, sorry about that :/ I've re-triggered the checks again on 3.0.4 [09:20] sparkiegeek, np and thanks! [09:24] Chipaca: it's complicated, t doesn't cover time some scenarios [09:24] pedronis: hmm [09:24] pedronis: what I'm seeing is that cleanup gets called again and again [09:25] hmm [09:25] pedronis: if cleanup returns error it just gets called again? [09:25] Chipaca: ah, yes, no basically cannot return errors from cleanups [09:25] unless you think being called forever is what you want [09:26] pedronis: thank you for having me write these tests ;-) [09:40] Hi everyone. Quick question concerning the Ruby plugin: Is there a way to preserve a built Ruby version across iterations as long as I don't change the ruby-version keyword? I'm experimenting with different stage-packages and the plugin rebuilds Ruby from source on every iteration. [09:58] thresh, popey: it is now unstuck [09:59] dot-tobias: I'm not sure who, short of sergiusens or kyrofa, can answer that [10:11] mborzecki: I think I found another logic quirk in my code [10:11] eh eh [10:11] but I'll commit everything and push it for review [10:11] ok [10:11] then work on your branch [10:11] mborzecki: essentially the call to LiftRestrictions is fine [10:11] mborzecki: but what if we did /rofs//a [10:11] mborzecki: and want to make /rofs/b then? [10:11] mborzecki: we remember that /rofs is a tmpfs we made [10:12] mborzecki: so we'll make b [10:12] that will work [10:12] mborzecki: but /rofs/a/c [10:12] mborzecki: that will go to rofs, it's a tmpfs so we carry on, then we will see an _existing_ directory a and bail out [10:12] (because we may not attempt writes there) [10:12] it's non-trivial :/ [10:13] mborzecki: because as I coded it so far, we only lift restrictions when making a new directory on top of a tmpfs mount point [10:13] mborzecki: to allow /rofs/a/c we'd have to keep track of other mount ops and ensure that /rofs/a/ is not populated [10:13] mborzecki: it can be a fix on top of this branch I suspect [10:13] but meh, this is hard stuff [10:14] heh, maybe we should try whiteboard instead :P [10:15] mborzecki: we need the "are you evil" bit [10:16] zyga: it feels like you'd need to comb through the ops and match the longest prefix of current path [10:16] mborzecki: we also need to keep track of mount changes we started with (current mount profile) [10:16] mborzecki: well, not sure, it's all complex (you can have filesystems and symlinks there) [10:19] zyga: we could track just the current state, but then symlinks don't show up because it's kind of side channel [10:19] mborzecki: we cannot track just the current state, we are called _update_ ns for a reason [10:21] zyga: i meant tracking the 'current state' after each change, but that's not helping either [10:22] zyga: btw. what if symlinks were applied last? [10:22] mborzecki: we know in order [10:22] mborzecki: I mean, we know it all [10:23] but it's hard to come up with an algorithm can respond reliably to the set of questions we have [10:31] mborzecki: pushed! [10:33] I'm making the PR now, [10:36] mborzecki: I have an idea how to fix /rofs/a/c [10:36] if we know /rofs/a and we can fstat it we can check the device major number [10:37] (and the magic/type value) [10:37] *fstatfs [10:37] Then we can fstatfs /rofs/a/c and also allow it iff it is still a tmpfs and has a major number that matches one of the past ones we've checked [10:37] since we must have traversed /rofs/a/ we will know the major number [10:38] anyway [10:38] that's a follow-up [10:43] mborzecki: https://github.com/snapcore/snapd/pull/5760 [10:43] mborzecki: I'll look at your PR now [10:48] mborzecki: just to double check: https://github.com/snapcore/snapd/pull/5758 [10:49] this one? [10:54] zyga: https://github.com/snapcore/snapd/pull/5713 [10:54] zyga: well, you can do both :) [10:55] ok [10:59] mborzecki: quick question: why didn't you make the changes to apparmor? [10:59] mborzecki: there are some typos in parallel in the PR :) [11:07] zyga: default template? [11:08] or instance specific template, either way [11:08] anyway, reading on [11:17] pedronis: hi, another one for you https://github.com/snapcore/snapd/pull/5761 :) this is first step to get the stable instance key across refresh requests (cc wgrant) [11:19] ooh [11:20] hello, I'm curious whether it'll be possible to get snaps to run on Haiku OS: https://www.haiku-os.org/ [11:20] baimafeima: hey, that's unlikely as snaps rely on a number of linux technologies [11:21] baimafeima: I'm not a haiku expert but I don't suppose haiku can run unmodified linux executables today [11:21] Yeah [11:21] baimafeima: so apart from the extra requirements of snapd (related to container technologies and sandboxing) you would have existing problems of just running unmodified apps that people release [11:21] I just wonder whether there's any ambition among snap developers to even move beyond the linux ecosystem [11:22] to make it more "universal" [11:22] baimafeima: one by one ;) [11:22] baimafeima: I think the answer is that it's unreasonable outside of "let's run it in a VM" [11:23] baimafeima: I doubt the number of users there would justify the engineering work required to attempt that [11:23] baimafeima: allowing snaps on windows would be more interesting for example [11:24] zyga, yeah, I just happen to be really fascinated about haiku :D [11:24] and well, they really lack software [11:29] baimafeima: I understand that [11:29] baimafeima: good luck with haiku! [11:30] mborzecki: ack [11:31] zyga, thanks for the info though === pstolowski is now known as pstolowski|lunch [11:36] mborzecki: wow, https://github.com/snapcore/snapd/pull/5760 is green on first go :) [11:37] no need to re-trigger tests [11:37] that's fun :) [11:42] mborzecki: RequestSeed will be persisted in state somewhere, I guess? [11:42] I suppose it needn't be a per-snap value. Machine-global would be fine. [11:42] wgrant: i planned to use seed-time which is machine global for that [11:45] off to pick up the kids [11:48] * zyga preps for lunch [11:49] mborzecki: review of 80% sent, I'll grab some food now [11:49] mborzecki: and there are lots of conflicts in that PR [11:49] anywAY === chihchun is now known as chihchun_afk [12:30] re :) [12:30] mborzecki: resuming the review [12:34] a lot of "error: unable to contact snap store" today, still [12:35] pstolowski|lunch: we are still battling some performance issues so having internmittent timeouts [12:35] noise][: ack, thanks === pstolowski|lunch is now known as pstolowski [12:36] niemeyer: thanks for the yesterday's udev review! the followup https://github.com/snapcore/snapd/pull/5632 is now much smaller (and also finally green again) [12:39] re [12:41] pstolowski: Thanks! [12:41] zyga: yeah, the conflicts are expected, parts of the PR were landing independently [12:44] state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic" [12:44] :'( [12:44] noise][: ^ is that another form of intermittent timeout? [12:45] yes, we lock you up until the timeout is reached [12:46] Chipaca: we should move catalog fetching to a task btw [12:49] noise][, given that https://forum.snapcraft.io/t/solved-request-failures-to-the-store/7177/6 claims "solved" perhaps someone from store could answer here https://forum.snapcraft.io/t/snapd-not-connecting-to-the-store-what-to-test-do/7190 [12:49] (since the latter one is more specific) [12:52] ogra: "solved" y un jamón :-) [12:52] I'm here [12:52] yes, we'll get the notices updated, sorry for the delay on those [12:53] jdstrand, do you highlight "jamón" lately ? [12:53] no [12:53] :) [12:53] I saw the store failures bit [12:53] ah [12:53] but seems you are talking about different things [12:54] jdstrand: hello [12:54] yeah ... the review-tools are fine on 16.04 ... 18.04 still fails though [12:54] I'll sync with roadmr when he is online. a new revision of the review tools should've hit prod yesterday but it doesn't seem to have [12:54] ogra: jamon? :D [12:54] ogra: yeah [12:54] zyga, see Chipaca's last line :) [12:54] jdstrand: I revived the trespassing fix for layouts, some churn still but at some point I'll ask you to sanity check [12:54] ogra: so, depending on what he says, I'll do the same for 18.04 that I did for 16.04 [12:54] zyga: hey, sure [12:55] jdstrand: there's also some related change in mount table sorting we are doing for instances [12:55] jdstrand: I'll go through it now, to poke holes [12:55] jdstrand: but if I fail I'll ask you to double check that aspect [13:07] roadmr: good morning! what is the status of getting r1123 of the tools into prod? [13:07] hi jdstrand ! we've had some issues with breakage in the store since yesterday which have preempted any rollouts :/ [13:08] jdstrand: but once the fire is out, rolling r1123 and a couple of other changes is highest priority for us [13:09] roadmr: should I roll a downgraded deb for bionic or does that fire seem to be out? [13:10] roadmr: (I can do the same for base: core18 snaps as I did for regular snaps. that would help some, but then there are non-LP/snapcraft.io builds that need r1123) [13:10] (I can't do anything about those) [13:11] jdstrand: it's probably still affecting users building on 18.04 [13:12] roadmr: which 'it'? I know lack of r1123 is affecting users (that is what I'm wondering about with uploading a downgraded bionic). ie, is the fire almost out and therefore r1123 will make it in the next few hours, or should I prepare that downgraded deb? [13:17] jdstrand: it == the new snapcraft that emits those new keys :) [13:17] jdstrand: we might be able to do the rollout this afternoon but no promises - it might be reasonable to downgrade bionic :( [13:17] roadmr: right, ok [13:17] * jdstrand does that [13:18] jdstrand: because it'll be a couple of hours before we know more, and what we end up finding out may be "it's all still borked, we can't roll out yet" [13:18] jdstrand: sorry - this issue we've hit had particularly bad timing :( [13:18] no worries === sparkieg` is now known as sparkiegeek` [13:59] niemeyer: the snapd snap failover test: https://github.com/snapcore/snapd/blob/master/tests/core18/snapd-failover/task.yaml [13:59] niemeyer: sorry that I did not find it earlier, it is under the core18 subsection, I forgot about this [14:02] mvo: Thanks! [14:02] mvo: and np at all [14:10] mvo, https://forum.snapcraft.io/t/core18-included-binaries/7191 ( <-- and probably also niemeyer ) [14:12] kjackal: hey there, can you direct me to where the microk8s project lives? [14:12] niemeyer: wrt changing 'okay' to 'ack', was your expectation also that the user-facing command would become 'ack'? [14:12] (maybe as an alias for 'acknowledge'? [14:12] ) [14:12] Chipaca: snap ack exists already, for assertions [14:12] Right, on both counts [14:13] that's why we went with okay here originally, I think [14:13] Oh, wait.. the command doesn't work.. :( [14:14] ogra: ta [14:14] It's a bit awkward to see it as a verb.. it was also unexpected to see it mixed [14:14] Hmmmmm [14:14] niemeyer: 'snap okay' comes straight from the whiteboard fwiw [14:14] Ack [14:15] (or okay? :P) [14:16] "snap dismiss" [14:16] snap read NN (like in gentoo) [14:18] snap conform [14:19] zyga: That's pretty good, but as something we need to type out often "okay" feels practical, and sort of okay [14:19] I cannot find any better options right away, unsurprisingly.. [14:19] haha so just like typing any two letters on a unix system does *something*, snap $ANY_VERB is bound to eventually also do something :D [14:19] We probably spent a good while finding it in the sprint [14:20] looking at synomyms of "acknowledge" there is nothing useful that is not many word, or long and uncommon [14:22] does anyone know why the forums are inaccessible? [14:22] hmm [14:22] was a blip [14:22] it works now [14:26] Chipaca, pedronis: alright, I we want to go with "okay", indeed it sounds better to go end-to-end with it so we use the same terminology everywhere [14:26] Chipaca: sorry for the false lead.. I forgot we had such a strong meaning for ack already [14:32] jdstrand: hey! the script that sends USN notifications for snaps, that lives in the reviewer-tools repo, right? [14:38] niemeyer: yeah, I think okay is okay :) [14:39] Okay then! [14:42] zyga: I think ack is ack [14:48] ack, okay [14:48] meh [14:48] can we have "snap meh" [14:48] doing something useful? :) [14:49] snap blink and snap nod [14:49] snap wink wink wink [14:52] * mvo likes snap nod [14:55] snap aye, snap nay? [15:09] snap popey the sailor [15:19]