[00:56] Bug #1747794 opened: cannot resolve host name with avahi interface [04:18] Bug #1702095 changed: snap enable removes complain for daemons === mup_ is now known as mup === mup_ is now known as mup === mup_ is now known as mup [06:18] morning [06:29] good morning [06:33] zyga: hey [06:42] -6 outside now [06:42] so pretty [06:49] coffee and back to spread [06:49] I wrote a new feature and a test together [06:49] need to split those out [07:11] hm tried to reproduce this https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894 but no luck, nothing 'hangs' [07:18] looking at that I wonder if the original deamon did something "fancy" that made it hang [07:18] like get stuck on a syscall or whatever [07:21] the next thing that happens after starting the services is running configuration hooks [07:22] wonder if he had any [07:25] oh [07:25] shit [07:25] oh? [07:25] did you find something nasty? [07:25] yeah, so whena snap is installed we run all the services [07:25] this one is 'oneshot' [07:27] so? [07:27] it should run and stop [07:28] hahaha [07:28] but it does not [07:29] is this a regression in 2.31? [07:29] (do we need rc4) or 2.31.1 [07:29] it's named usb_mount, suggesting that's it will mount a usb device, if there's none then it will apparently wait [07:29] oh [07:29] so oneshot services block until they exit? [07:29] so i made a simple service that loops infinitely, and it hangs 'Start snap "daemon-oneshot" (unset) services' [07:29] yeah [07:29] oh, wow [07:29] that's not great [07:30] we also probably shoulnd't start them when installing a snap [07:30] actually, what should happen for oneshot services isn't clear to me [07:30] who should start them? [07:30] the snap itself? [07:32] the way i used oneshot is either as a dependency before other service (eg. generate ssh keys) or as a response to something that happens (path conditions, or a template unit) [08:06] --no-block may be a reasonable workaround, but this doesn't change the fact that the service should not wait indefinitely [08:08] heyas! [08:09] pstolowski: morning [08:09] moin moin [08:10] everyone joining :) morning mvo & kalikiana [08:10] good morning mborzecki [08:10] hey kalikiana [08:21] hey guys [08:21] mborzecki is the service bug a regression? [08:21] if so I bet mvo will want to know [08:21] zyga: I do want to know [08:22] mvo: https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894 [08:22] zyga: not a regression, technically it was there before [08:25] mborzecki: nice find [08:26] mvo: what happens is that if a oneshot service hangs/loops/does not termine, snapd will be stuck in start-snap-services task [08:26] s/termine/terminate/ [08:26] mborzecki: yeah, I was just readoing it [08:27] mborzecki: thats really unfortunate, I wonder if --no-block in systemctl might help [08:28] i'm looking at some options, like not starting oneshot tasks, adding --no-block (complicates systemd interface internally), adding TimeoutSec= in *.service (the timeout is fairly arbitrary and probably incorrect in some edge cases) [08:28] mborzecki: thanks for looking into this [08:29] mvo: frankly i'm leaning towards not starting oneshot services at all [08:29] PR snapd#4621 closed: tests: skip alsa interface test when the system does not have any audio devices [08:30] PR snapd#4618 closed: tests: new snaps to test installs nightly === mthaddon` is now known as mthaddon [08:38] * zyga iterates on layouts and testing [08:38] next up: refreshes that change layouts :) [08:38] *that* will be interesting [08:41] jamesh, hey, good morning [08:55] did you guys watch the falcon heavy launch yesterday? [08:58] zyga: yeah, quite spectacular. [08:59] I watched it by accident (I got a tip from kissiel) and wow, it was crazy, like watching a sci-fi movie [08:59] *live* [08:59] :) [08:59] * zyga found some bugs in layout validation [08:59] time to fix that [08:59] (too conservative) [08:59] nothing to worry about [09:00] mvo remember before we had spread? [09:00] it was like driving blind [09:00] zyga: I don't, my therapist helped me with that [09:00] * mvo pats the emacs therapist [09:00] haha, good one [09:01] zyga: but indeed, totally agree [09:01] -5C outside, brrr [09:01] let's rethink that validator === chihchun_afk is now known as chihchun [09:23] PR snapd#4623 opened: wrappers: do not start oneshot services [09:23] there's probably a spread test that will fail as a result of ^^ [09:29] * kalikiana coffeeeeee [09:30] * zyga notices a movie crew outside his house [09:30] kalikiana khaaaaaaan [09:31] there's a fake police car, fake news crew and fake people doing an interview [09:31] they use this site for some sitcom or other local TV thing once in a while [09:31] I wonder if I was in the shot, helping my daughter go to school [09:31] they didn't stop filming, maybe just a dry run [09:32] zyga: they are shooting a new sitcom - the big O theory - guess who the starts will be ? [09:32] haha :) [09:33] * mvo stops being silly and makes more tea [09:33] is it also freezing for you mvo? [09:38] zyga: a little bit of snow fell this morning, ~5am [09:38] zyga: it's just sitting on the glass patio table, pondering life [09:38] melting away [09:38] like all of us [09:38] ;-) [09:38] no, actually [09:38] * zyga is in a good mood today [09:39] zyga: your comment on my MatchCounter PR, could you expand it? [09:39] yeah, let me pull the diff tab [09:39] w.partial is empty [09:39] oh [09:39] man [09:39] I should not comment late at night === chihchun is now known as chihchun_afk [09:39] nothing :) [09:40] I got rid of it [09:40] I somehow read that bytes.IndexByte() was called on w.partial [09:40] ueh ueh ueh, or something [09:40] zyga: its around 0 here [09:41] Chipaca: I guess you want to rebase my PR on top of this ;)? [09:43] zyga: https://i.imgur.com/Wcj6Swd.png [09:43] zyga: censorship! [09:43] :-) [09:43] oh? [09:43] I didn't delete your comment, I just deleted mine [09:43] I guess it killed your comment that wasn't loaded in my tab [09:44] mvo: more like: if you think it'll improve things, I can push a commit to your PR that uses this [09:44] Chipaca: its more general than mine, so +1 for this [09:44] mvo: ok, i'll push a commit to yours as soon as this lands [09:44] ta [09:45] that was a subtle clue that I should review it, right? [09:45] today I'm going into london, so a lot of time on public transport with little/bad connectivity, and I'm going to miss the standup [09:45] mvo: not at all [09:45] mvo: I mean, I wasn't subtle [09:45] :-D [09:45] lol [09:46] * mvo hugs Chipaca [09:46] Chipaca: i have mixed feelings about 4632 too, idk, maybe it'd be best to leave the code as it is now, this guys code is probably wrong [09:47] mborzecki: FWIW i think we _should_ expose startup timeout, and conditionals, and have some extra magic for oneshots where we don't hang but still handle it, but it's a lot of work for something that, in this case, is probably dev error [09:47] I mean: why would a mount process hang [09:47] Chipaca: otoh, it's not really possible to interrupt this, ^C has no effect [09:48] mborzecki: in that abort doesn't abort? [09:48] Chipaca: yeah, i have a snap with an app that loops inside and i cannot abort the installation [09:48] mborzecki: we probably want to make systemctl use the brand new osutil.RunWithContext :-) [09:48] and bubble context into systemd [09:49] OTOH it might be better to make start use --no-block and then poll, like we do with stop [09:49] zyga: what are fake people? robots? ;-) [09:49] (i mean, without it, systemctl is doing the polling) [09:49] kalikiana just actors ;) [09:49] kalikiana: kardashains [09:49] lol [09:50] Chipaca: hmm right, let me take another look at the code [09:50] s/kardashians/osbournes/ [09:50] mborzecki: OTO²H context + (no-block + poll) is probably the real winner [09:51] mborzecki: OTO³H probably a lot of work [09:51] yeah, sounds backlog worthy [09:51] mborzecki: OTO⁴H I'm running out of superscripts [09:51] * sparkiegeek wonders how many hands Chipaca has [09:52] mborzecki: OTO⁽ⁿ⁺¹⁾H, you'll never know [09:52] Chipaca: RunWithContext was merged right? [09:52] mborzecki: yes [09:53] mborzecki: but killing systemctl might not dtrt wrt systemd, which is why i said it might be better to do the more detailed work [09:53] but you could use it as a base, or phase 1, or sth [09:53] * Chipaca gives up, and starts getting ready to leave [09:53] probably better than stalling [09:54] mborzecki: first, see if killing systemctl stops the eternal oneshot [09:54] 'eternal oneshot' [09:54] if so then robert is your mother's brother [09:54] or something [09:55] Chipaca: right, it did, the unit was stopped [09:56] perfect then :-) [09:56] trivial PR for someone, pretty please [09:57] 4624 [09:57] PR snapd#4624 opened: snap: apply some golint suggestions [09:58] mmm, golint fixes [09:58] zyga: ValidAppName returns true if if given string is a valid application name. [09:59] zyga: and if if not? [09:59] well, it returns false ;) [09:59] zyga: I mean, too many ifs [09:59] oh [09:59] I see now [09:59] thanks [10:00] this isn't me getting into the "oh it should be whether" thing [10:00] which I have learned is pedantic :-) [10:00] another good point [10:00] I never write that word [10:00] because I'm always afraid I will say weather [10:00] or actually, write weather [10:00] if if you see what I mean [10:00] zyga: maybe it's just a tsundere comment [10:01] a what comment? [10:01] PR snapd#4625 opened: daemon: remove redundant UserOK markings from api commands [10:01] Chipaca: ^- is what we talked about last night [10:01] zyga: maybe you don't want to know [10:01] mvo: ack [10:01] * Chipaca looks [10:01] Chipaca: I hope this makes things for my future self easier to grok [10:03] mvo: when the mythical "no more features, just fixes and cleanup" year arrives, I grab "rewrite daemon" [10:03] anyhow, I need to run [10:03] o/ [10:04] telegram is your best bet to reach me (or whatsapp fwiw) [10:04] mvo "what the canAccess() policy." ... what? [10:04] Chipaca: see you [10:05] zyga: not sure I follow, did I write something in an unclear way? [10:06] I think it ends abruptly [10:06] "what the canAccess() policy means." maybe? [10:07] unless it was meant to be "polices" (the verb) [10:08] PR snapd#4626 opened: daemon: improve ucrednet code for the snap.socket [10:08] ah, just the "what" is too much [10:10] mvo, hey, #4579 can land, right? it got +1 from security in the old PR? [10:10] PR #4579: many: add interfaces.SystemKey() helper [10:13] pstolowski: I think so, but zyga asked for a tweak (which I can do in a followup if this helps you) [10:13] mvo can be in a follow-up yeah [10:13] mvo especially since there's a new function to extract out of that logic [10:14] pstolowski, zyga I work on the followup and then work on the other two (smaller) ones [10:14] mvo, no, it doesn't change much for me (need other PRs as well), it's just 1 less to look after ;) [10:14] PR snapd#4579 closed: many: add interfaces.SystemKey() helper [10:15] FYI: the snappy store is in a maintenance window until 11:00 UTC (see https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866 ) [10:15] oh, thanks for the heads up sparkiegeek [10:18] zyga: hm, the release/apparmor.go code is doing the inverse of what I need, so I guess I just move my code there? or am I missing something? [10:18] yes [10:18] just move it there and perhaps reuse your code in the computation of what was already there, if feasible [10:19] hmm, store is doing 503 [10:19] is that expected sparkiegeek [10:21] zyga: yes, but it should be coming back up now [10:36] PR snapd#4627 opened: release, interfaces: add new release.AppArmorFeatures helper === mborzeck1 is now known as mborzecki [10:37] pstolowski: left you a comment about truncation, feel free to ignore it, i think it would complicate the internals a bit too much [10:40] mvo 4627 is almost good [10:40] mborzecki, thx, will check [10:45] PR snapd#4623 closed: wrappers: do not start oneshot services [10:46] whee [10:46] spread now passes [10:47] ok, let's upstream the changes and work on hardening so that jdstrand doesn't turn grey on release day [10:52] store maintenance is now over, please report any issues on the forum thread: https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866 [11:26] PR snapd#4613 closed: release: snapd 2.31 [11:26] woot :) [11:26] mvo, hey, we are ready to go to candidate [11:27] so no more RCs? :) [11:27] no [11:27] cachio_: yes [11:28] cachio_: actually, give me ~20min to check the autopkgtest results on bionic [11:28] mvo, sure [11:28] cachio_: if these are bad we *migth* need a .1 [11:29] uhhn the changes allwoing cancelling of systemctl start are ugly [11:30] cachio_: looks like we do have some issues in autopkgtest due to the different environment. oh well. [11:30] mvo, which is the link? [11:31] mvo, could I take a look? [11:31] cachio_: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd and follow the bionic links [11:31] cachio_: one strange one is unit test for TestDoREquestSerialErrorsOnNoHost [11:31] cachio_: but it looks like a random assortion [11:35] mvo, I see that a failure in the interfaces-timeserver-control is breaking the whole suite [11:35] for amd64 [11:36] cachio_: yeah, I have not looked into the details yet but it seems there are some failures we need to look at :/ [11:36] cachio_: slightly annoying that its so hard to test autopkgtest for real [11:38] PR snapd#4628 opened: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines [11:39] cachio_: some is rather trivial like -^ [11:39] mvo, yes, I'll work on that [11:40] cachio_: thanks [11:40] zyga: looks like we need an s390x build for snapd-hacker-toolbelt [11:40] cachio_: and one for test-snapd-kernel-module-consumer for s390x [11:40] cachio_: but I guess we should focus on amd64/i386 first [11:41] mvo, yes, agree [11:41] mvo, isn't it nice, that s390x is no longer a restricted arch and one can just tick the tickbox for it ;-) [11:41] mvo aha [11:41] mvo in a moment, I'm busy for 15 minutes [11:41] mvo, not sure if we are able to create a bionic image in linode [11:42] xnox: it is! [11:42] as it is not stable [11:42] cachio_: I don't think this will help us much [11:42] cachio_: my feeling is that the images are not the problem [11:42] cachio_: its that the autopkgtest env is more restricted [11:42] mvo, ah, ok [11:42] cachio_: for whatever reason [11:43] cachio_: it really should not be, we run in a full VM and added hints that we mess the host up but e.g. timezone setting is denied [11:43] mvo, thanks for 4627! [11:43] mvo, how do you do to trigger the tests? [11:43] cachio_: or maybe it is actually bionic, might be easiest to just run against qemu to see if something in e.g. systemd failed [11:43] cachio_: s/failed/changed/ [11:44] cachio_: thats the sad part - to trigger the tests I need to upload the package to the real archive [11:44] cachio_: this is my grief with adt - there is no easy way to test against e.g. a ppa [11:45] mvo, ok, I'll start runnig in qemu and then if we have a 100% we can go forward [11:45] cachio_: great, I keen to know if e.g. the timezone failure is related to bionic or adt [11:48] mvo, so, should I promote to candidate? [11:49] mvo, I can do it after the standup [11:51] mvo, I have a doc appointment now, I'll be bac for the standup [11:52] * cachio_ afk [11:58] mvo sorry I'm back now [11:58] I just sold my x250 [11:58] so, about that build for s390x [12:02] mvo, I wonder how we can build one, will snapcraft.io do it? [12:03] zyga: launchpad can do it, if you have snap building enabled on it [12:03] zyga: then you can just click on s390x as an arch [12:03] pstolowski: the next one (re-generate on system-key change) will arrive as soon as 4627 is green [12:04] mvo, great! [12:04] mvo, let me look, I honestly don't remember how I built it [12:04] pstolowski: then i think its just #3471 and its done [12:04] PR #3471: snap: make `snap run` look at the system-key for security profiles [12:04] pstolowski: not sure if you need this piece for your work though [12:04] cool [12:04] ah, it's on launchpad allright [12:04] mvo: shall I just rebuild for all arches? [12:05] zyga: +1 [12:05] mvo, ah, if this is only about snap-run then no [12:05] mvo, man, I can even build for powerpc :) [12:05] would that work? [12:05] or is it just fake? [12:06] zyga: I think it will work [12:07] zyga: we could even build a core for powerpc now if that is fully enabled [12:07] https://launchpad.net/~zyga/+snap/snapd-hacker-toolbelt [12:07] builds are pending [12:11] that will be an interesting refresh :) [12:12] I should adopt one of the new features in snapcraft and generate version dynamically [12:13] * pstolowski lunch [12:14] mvo all done [12:14] wow, [12:17] PR snapd#4624 closed: snap: apply some golint suggestions [12:20] * zyga re-reads 4622 === jospoortvliet is now known as jos === jos is now known as jospoortvliet [13:00] PR snapd#4627 closed: release, interfaces: add new release.AppArmorFeatures helper [13:04] PR snapd#4629 opened: ifacestate: only rewrite security profiles if the system-key changes [13:12] PR snapd#4630 opened: snap: sort layout elements before validating [13:25] + systemctl stop snapd.service snapd.socket [13:25] Job for snapd.socket canceled. [13:25] I wonder what this was, is this something that we fixed in another context before? [13:25] ^ cachio_ (perhaps you remember) [13:30] mvo ^ trivial 4630 [13:30] zyga: ta! [13:31] I have one more on top, also trivial but separate issue [13:32] jdstrand 4631 is super trivial but for you [13:33] PR snapd#4631 opened: cmd/snap-confine: allow mounting anywhere, effectively [13:33] jdstrand this is a side effect of a fully working spread test, which is coming up in two branches from now [13:34] once the test lands I will start pushing hardening for snap-update-ns, knowing that I didn't break anything [13:53] PR snapd#4626 closed: daemon: improve ucrednet code for the snap.socket [13:56] what's a "gated snap"? [13:57] diddledan snaps can use gating to ensure QA constraints [13:57] * diddledan read the snapcraft --help and found `snapcraft gated` and `snapcraft validate` [13:57] you can use it to ensure that refreshes will happen only after you sign that off as not breaking your snap [13:57] so what's "gating"? [13:58] so. you can, for example, have a super important snap that you want to support 24/7 [13:58] gating is the whole process [13:58] and you control your snap so that part is easy [13:58] but the core snap can introduce bugs so you want to have a way to validate them [13:59] if you have validation control on the core snap you can say that the core snap will refresh only if you say that your snap works with a given revision of the core snap [13:59] (core can by any other snap but it's typically core) [13:59] obviously this only applies if your snap is installed [13:59] it's a way to check that you can conform to your contractual agreements most likely [13:59] where you can check each new core revision and "ack" it [13:59] (for the purpose of your snap) [13:59] does that make sense? [13:59] no [14:00] clear as mud :-p [14:00] can you be more specific? [14:00] I'm just thick [14:00] I can give you an example if that helps [14:01] "Get the list of snaps and revisions gating a snap." means nothing to me [14:01] gets the list of snaps and revisions that _block the snap from refreshing_ [14:01] can we change the verbiage then? [14:02] change what, sorry? [14:02] "gating" is a term which requires intimate knowledge of what it means to "gate" [14:02] yes, we use many words that require one specific knowledge [14:02] "block", "blocks" and "blocking" are much more appropriate words if that's what is happening [14:02] but I think that's unavoidable and not a problem as long as they are clearly explained somewhere accessible [14:03] it's not just blocking, it's more subtle [14:03] ... which they're not (explained somewhere accessible) [14:03] the users can override that [14:03] diddledan please raised this with kalikiana as I think this is a snapcraft documentation [14:04] PR snapd#4632 opened: Fixing denial for when using avahi-observe slot [14:06] * zyga -> lunch [14:09]