[07:19] good morning [07:19] os upgrade, brb [07:32] Hello [07:37] re again [07:37] * zyga looks at his inbox [07:40] eh, first mail is to pay taxes [07:40] oh well [07:41] sdhd-sascha: found your mail [07:41] sdhd-sascha: do you mind if I answer here [07:41] I prefer IRC over email any day of the week [07:42] zyga: no - but some task i already have done yesterday [07:43] sdhd-sascha: about snap run test - I is up to you, perhaps the snap run test is overcrowded and deserves to be split into run, run + strace, run + gdb and run + ltrace [07:43] about wayland, yay! [07:45] as for /etc/debian_version, I think it's more complex because 1) we want to stop sharing /etc with the host 2) if it is a symlink that points to /usr it will be useless (like os-release on some systems) 3) usually reading os information is not really necessary, apart from "vanity" reasons like "you are running $foo" screens - what's the motivation behind reading /etc/debian_releae? [07:45] *release [07:45] sdhd-sascha: as for spread, that's easy, just build it from github and run with locally made images [07:45] sdhd-sascha: you can fetch some of my older images from spread.zygoon.pl [07:46] sdhd-sascha: those images are made with autopkgtest create image tools but really, any tool that spits out a machine with password auth is okay (for simplicity) [07:47] zyga: i run: ~/work/src/github.com/snapcore/snapd$ spread -v qemu:ubuntu-18.04-64 [07:47] And then i currently get only no connection [07:47] sdhd-sascha: your mileage will vary in some cases as we tweak our images more than not for certain aspects that are murky but you should have a good start that will let you iterate x10 locally before pushing a PR and having to wait for travis + spread in gce [07:47] how did you make the image? [07:47] I build spread by myself - will look how the best way to connect to the serial of qemu... [07:47] sdhd-sascha: no no [07:48] the image [07:48] remark about adding more snap-types, most likely you won't get that because it involves snap architects and store changes to implement [07:49] as for /run/systemd/sessions, grep through interfaces, if nothing sensible is there discuss a new interface design on the forum [07:49] the actual implementation is the easiest chunk [07:49] sdhd-sascha: so how did you get the ubuntu 18.04-64 image? [07:49] zyga: i use autpkgtest like in Hacking.md [07:49] hmmm [07:50] do you get anything if you run spread with -vv ? [07:50] zyga: /run/systemd/sessions works with #7881 [07:50] PR #7881: intreface: login-session-control - added missing dbus commands [07:53] sdhd-sascha: and lastly, reviews are always awesome [07:53] sdhd-sascha: those will help you get up to speed the most IMO [07:55] zyga: thank you :-) [07:55] zyga: today spread do something. don't know why, but it's fine [07:56] sdhd-sascha: local spread runs are 10x heavier on network than CPU [07:56] sdhd-sascha: I recommend exploring proxy options for apt, at least [07:56] sdhd-sascha: there are some more savings to be had after you get thorough this [07:57] sdhd-sascha: read spread.yaml for ideas on what the host environment is used (tip, grep for host:) [07:57] zyga: yes - i have to take a look, why the MAAS proxy doesn't work here [07:57] sdhd-sascha: I'm not familiar with maas proxy [07:58] it's simple a mod' in /etc/apt/apt.conf.d/XX-proxy after deployment - no magic [08:00] sdhd-sascha: aha, spread.yaml requires explicit opt-in [08:00] you need to set some environment variables that get passed down the the virtual machine / container that is started by spread [08:04] morning [08:08] hey pawel [08:16] I'll work from the kitchen until the office warms up [08:16] pstolowski: it was -4 this morning [08:35] phone [08:37] PR snapd#7882 opened: devicestate: only run ensureBootOk() in "run" mode [08:41] and back now [08:42] mvo: do you urgently need reviews or can I focus on branch iteration? [08:48] zyga: branch iteration is fine, 7880 is a blocker right now, I need to poke around this area a bit, the PR is not ready :( [08:50] ok [08:51] mvo: good luck and feel free to drag me into this :) [08:52] zyga: uhm... here https://i.paste.pics/f06e76ec6b4420a5e8cc5c006bbdcca4.png [08:53] wooow [08:53] that's just like real winter :) [09:30] hmm are we in a split [09:31] has anyone seen maciek today? [09:37] zyga: according to hr calendar he is off today [09:37] he said so in the standup yesterday [09:37] ah [09:37] ok [09:37] he'll be back tomorrow [09:37] thanks, I must have missed that [09:58] mvo: hi, bare was fixed, I looked at what is needed to land #7594 but got confused by the revisions of test-snapd-busybox-static, we can chat about it in the standup [09:58] PR #7594: tests: replace "test-snapd-base-bare" with real "bare" base snap [10:00] pedronis: ok [10:39] has anyone checked why we have red tests right now? [10:50] mvo: nope, let me look [10:50] mvo: I'm running spread in qemu locally and trying to fix something but didn't notice red [10:51] mvo: interfaces-audio-playback-record is failing on 16.04 [10:51] looking at why [10:52] hmm [10:52] it fails in a suspicious way [10:53] https://www.irccloud.com/pastebin/5GYgmfK1/ [10:53] looking at the next PR [10:55] mvo: there's a typo in your PR https://github.com/snapcore/snapd/pull/7880/files#r356529968 [10:55] PR #7880: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults [10:56] mvo: next PR has name upsetting commit checker (from sdhd-sascha) [10:57] mvo: next PR has apt-hooks failure with no useful failure [10:57] s/failure/error messages/ [10:57] mvo: next PR has gofmt issues (from jamie) [10:58] mvo: seems to be nothing specific but the audio recording failure is worrying [10:58] mvo: feels like it could break the relase [10:58] mvo: do you want me to pursue this further? [10:59] zyga: that's fine, I'm in a meeting right now though [11:28] pstolowski: just a random though, in snap is-connected we could say something super basic if stdout is a tty [11:34] just fyi - I branched 2.43 now [11:34] PR snapd#7883 opened: snapstate: relax gadget constraints in ConfigDefaults Et al [11:34] still open for selected cherry picks [11:34] zyga: we could yes, although when the pr was reviewed we opted for removing any verbosity that i initially had. fwtw snapctl is meant ot be used by scripts/apps, so i'm not sure if output is that useful [11:36] pstolowski: snapctl yes [11:36] I meant "snap" [11:36] pstolowski: note that the verbosity would obviously not be there in a "if snap is-connected foo bar; then" scenario [11:36] mvo: sounds great [11:37] PR snapd#7880 closed: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults <⛔ Blocked> [11:38] zyga: sorry, i thought you misstyped. i don't remember we ever considered snap is-connected [11:38] pstolowski: ah, I see [11:39] do we plan to have it for consistency? [11:42] i see how this could be handy as a shortcut over of snap interfaces / snap connections. at the same time it was meant to address the deficiency on snapctl side (which doesn't exist on snap side). i don't know, guess it's a question to pedronis_ [11:57] brb [12:01] * cachio afk [12:05] zyga: i will be back in at the evening. (the PR name i have changed) [12:12] PR core18#144 opened: Add efibootmgr to the extra packages [12:12] sdhd-sascha: sounds good [12:20] zyga: is offtopic - but did you use raspberry-pi4 ? i got a response from request to the maintainers, that they work on the network support for u-boot. I need this, because rpi4 can only network boot the kernel, but not the initrd ... And with u-boot, it would then possible to boot ubuntu-core over network, e.g. with MAAS :-) [12:21] sdhd-sascha: I have a rpi4 but I didn't try the new ubuntu images yet, AFAIK there's no ubuntu-core image for it yet [12:21] sdhd-sascha: as for netboot, I don't know how it boots enough to answer [12:26] zyga: currently it needs beta-firmware for network-boot. I already boot a kernel and nfs as root-filesystem. [12:26] And about ubuntu-core for rpi4. We can use the default image for arm64 the kernel and modules are always the same [12:26] PR snapd#7884 opened: snapstate: check gadget model constraints in checkSnap === pedronis_ is now known as pedronis [12:27] sdhd-sascha: I'm not pursuing that today if you are interested in it I would suggest asking sil2100 or ogra for pointers [12:27] pedronis_: a review for 7883 would be great, this should unblock the seeding in install mode [12:27] mvo: about #7879, I'm fine merging it for edge once we have cut 2.43, if it works then, we can cherry pick it, it seems it's localized enough for that [12:28] PR #7879: devicestate: use httputil.ShouldRetryError() in prepareSerialRequest [12:28] mvo: ok, resting a bit after my doc appt/lunch, will looke in a bit [12:39] pedronis: thanks [12:51] hmm [12:51] zyga, sdhd-sascha https://people.canonical.com/~ogra/snappy/raspberrypi4/core18/ [12:51] not using our kernel though ... [12:52] ogra: :-) yes, i forgot where it was [12:52] mvo: lots of PRs are red though ? general master problem? (I havent looked) [12:55] pedronis, mvo: maybe something with debian-sid [13:01] pedronis: I loked earlier today and it didn't seem like a single problem [13:01] pedronis: each PR was red for a distinct reason [13:01] fun, not. ok [13:03] pedronis: though one was worrisome [13:03] pedronis: audio-record seems broken for real now [13:03] pedronis: perhaps our images got some changes / packages got rolled back or worse, updated with patches dropped [13:04] ok, we need to rope in jdstrand on that [13:05] jdstrand: the log is https://api.travis-ci.org/v3/job/623567687/log.txt [13:05] jdstrand: the job is https://travis-ci.org/snapcore/snapd/builds/623567683 [13:05] jdstrand: ^ it looks serious [13:12] hmm i just saw it on my PR [13:13] cachio: good morning. a question about our GCE hosts, do they support nested VMs? [13:15] mvo: I did a pass of reviews [13:19] zyga (cc pedronis): it isn't serious, the mediation patches went through SRU today: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428 [13:20] Bug #1781428: please enable snap mediation support

by jamesh> [13:20] I'll submit a PR to flip on xenial and bionic [13:20] jdstrand: I'm confused, how did this test pass before? [13:20] ah [13:20] I get it now [13:20] I misread the failure message I guess [13:20] thank you, that's great news [13:20] zyga: because yesterday the patches weren't in -updates but today they are [13:21] * zyga nods [13:27] PR snapd#7885 opened: tests: 16.04 and 18.04 now have mediating pulseaudio [13:27] zyga: there you go ^ [13:27] looking [13:28] jdstrand: was this in 2.43? if so mvo needs to cherry-pick it [13:28] zyga: yes and I just milestoned it [13:28] well, let me triple check that [13:29] yes, it was [13:29] cmatsuoka, hey, sorry for the delay [13:29] cmatsuoka, yes, they do but not any instance [13:29] cmatsuoka, just the instances that we use for nightly execution do [13:31] PR snapd#7886 opened: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 [13:31] jdstrand: thank you! [13:31] I created that ^ for 2.43 to make it quick [13:32] cachio: the question is because for testing core20 installation we may need a nested VM (so we can enable secure boot and software tpm) [13:32] not excellent timing on the SRU approval, would've been nice to have had it done before the commit, but good we have the mediation now [13:32] cmatsuoka, it can be done [13:33] cachio: can I run a test on one of those instances? how do I access one of them? [13:33] cmatsuoka, yes [13:33] cmatsuoka, use google-nested backend [13:34] it is in the spread.yaml of snapd project [13:34] cachio: ah ok, thanks! [13:34] yaw [13:35] please ping me if you need any help on this [13:36] cmatsuoka, ~ === ricab is now known as ricab|lunch [13:42] cachio: testing here, thanks! [13:44] cachio: is there any stability difference between the xenial and bionic systems? and how's the stability overall, is it working perfectly or do we have crashes from time to time? [13:45] cmatsuoka, those are stable [13:45] morning folks [13:45] didn't see any error on those [13:47] cachio: great, thanks! [13:57] PR snapd#7887 opened: [RFC] seed,devicestate: check gadget model constraints when seeding [14:11] mvo: I see 2.42.5 made it to candidate yesterday, any idea when this will hit stable? [14:12] stgraber: it's getting phased to stable after our standup which is now [14:12] stgraber: talk about nice customer service, you ask for it and you get it :) [14:12] stgraber: so the first couple of percent will go out in ~30min or so and then it will ramp up over the next hours, the details of the phasing cachio knows [14:13] stgraber: and sorry again for the trouble [14:13] sounds good, thanks [14:18] niemeyer: hello [14:18] niemeyer: I made a small PR for spread for your consideration https://github.com/snapcore/spread/pull/94 [14:19] PR spread#94: qemu: invoke qemu in a portable way [14:19] niemeyer: it's literally a one liner but not sure about the architecture portability aspect [14:19] niemeyer: I'm happy to iterate, just need something that operates outside of Debian [14:19] zyga: I'm in a meeting at the office today.. can you please ping me by Friday so we can look at it together? [14:20] niemeyer: sure, is Friday okay? [14:20] Yeah, I should be back late tonight [14:20] cheers, see you then! [14:20] Thanks! [14:30] PR snapd#7885 closed: tests: 16.04 and 18.04 now have mediating pulseaudio <⚠ Critical> [14:54] stgraber, hey, progressive release for 2.42.5 started [14:55] 25% of the devices are receiving the update now [14:55] the percentage will grow during the day [14:55] Thanks === ricab|lunch is now known as ricab [15:22] pedronis: hey, can you give https://forum.snapcraft.io/t/certbot-request-for-classic-snap-approval/6240/19 a look (you'll need to read from https://forum.snapcraft.io/t/certbot-request-for-classic-snap-approval/6240/7 and lower (my, rbasak's and upstream comments on the approach, not the side conversation on use of the interface) [15:22] rbasak: also, fyi, https://forum.snapcraft.io/t/certbot-request-for-classic-snap-approval/6240/17 [15:23] pedronis: feel free to discuss in the topic. (I'm stepping away to an appt) [15:23] jdstrand: likely I'll look at it in my morning tomorrow [15:23] I have other things today [15:26] jdstrand: thanks! Assuming that output from a connection hook will end up in the console, are you saying that (yet to be confirmed by others) printing a warning from the hook and later at runtime will be sufficient? [15:27] jdstrand: and separately, do you know what the store will do in terms of autoconnection for plugins published by the same publisher as the certbot snap itself, and am I right in thinking this would be acceptable (since same publisher)? [15:29] rbasak: I'm not sure it will go to the console. you might need to use it to manage something that the certbot command might have to consult. not ddictating implementation. be tasteful, etc, but something needs to come up somewhere imo [15:29] rbasak: the store will auto-connect from the same publisher, but we can override that [15:29] if desired [15:29] hook output doesn't go the console, so far we don't have mechanism to do that [15:29] I don't think it is though, since collectively it is all 'upstream' [15:30] in general we don't expect them to be running always with somebody watching [15:30] (I haven't read the thread yet as I said) [15:30] right, that is what I though. but it can manage something (eg, a file) for something else to look at [15:31] thought* [15:31] gotta run (appt) [15:32] pedronis, hi, do you know if there was any change in snapd that could produce we are calling more times to the store service /names ? [15:33] jdstrand: OK, so in that case the warning can be at runtime of certbot only, right? And that might be automated (eg. via the systemd timer that certbot installs). Normally the first time the user would run certbot by hand to set it up, but I can imagine an adversarial scenario where someone convinces a user to add and connect the plugin after initial setup. In this case, the systemd timer will run the [15:33] third party code without the user ever seeing the message. [15:33] jdstrand: is that acceptable to you? [15:33] cachio: no, if anything we reduced it but you probably want to discuss with Chipaca when he's around [15:33] jdstrand: if not, I'm not sure how to achieve what you want with the current snapd. [15:33] pedronis, because it is producing that the store is sending an error to snapd like this https://paste.ubuntu.com/p/JY69dz4vwP/ [15:33] pedronis, ah, ok [15:34] I'll talk to jhon in that case [15:47] mvo: did a pass on #7887, nothing that haven't already mentioned [15:48] PR #7887: [RFC] seed,devicestate: check gadget model constraints when seeding [15:51] jdstrand: pedronis: it's a bit silly but you could have a connection hook that always fails with a message explaining the ramifications of connecting that interface unless there's a config set like `snap set $SNAP_NAME =ok` [15:51] here I think the connection hook could introspect what the name of the other snap that is being connected to to determine what config item to check, but I would need to check how that works [15:52] * zyga looks after lucy for an biur [15:52] Hour [15:53] pedronis: thanks! [15:53] PR snapd#7888 opened: tests: disable apt-hooks test until it can be properly fixed [15:54] * cachio lunch [16:17] PR snapd#7889 opened: overlord,o/snapstate: make sure we never leave config behind [16:21] mvo: anything I should review? [16:21] pedronis: jdstrand: I put an example into the certbot forum topic for certbot [16:23] ijohnson: yes, it's by design that we don't tell snap detail of the other side [16:23] pedronis: I updated 7884 - I will look into converting constraints -> model now [16:23] yeah that's what I thought from looking at it [16:29] mvo: +1 [16:45] jdstrand, ijohnson reading that certbot discussion i wonder if i'm missing anything here ... afaik classic snaps can provide interfaces but not consume them ... did that policy change recently ? [16:47] ogra: I don't think in this case certbot is consuming anything from the interface at all, it's just using the connection hooks and the existence of that connection to do something in the classic snap [16:47] ogra: the classic snap directly executes "snap connections" to see what connections are connected [16:48] well, and the "snap connect .." (to exec the interface hook) was the bit i thought was denied [16:48] cachio: 7888 has failed :/ [16:48] cachio: some strange error I have no seen yet [16:48] (beyond a store upload block for such snaps, but thats indeed just an override) [16:50] mvo, checkign [16:50] cachio: thank you [16:51] mvo, there is a PR for fixing this error #7877 [16:51] PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system [16:51] I'll restart the job [16:51] mvo, thanks for hte heads up [16:56] ogra: not sure about the store denial, but the example snap I have locally works fine if the snap is classic, the interface hooks are still run under confinement [16:57] aha ... well, i thought in the past the snap connect command used to cause an error [16:57] if thats not the case anymore then i'm just behind on knowledge [16:59] cachio: thank you! [16:59] mvo, yaw [17:18] cachio: do we need #7888 to be back to green? [17:19] PR #7888: tests: disable apt-hooks test until it can be properly fixed [17:19] pedronis, I restarted the failed job [17:19] pedronis, it should finish in 10 minutes [17:30] pedronis, merged [17:31] PR snapd#7888 closed: tests: disable apt-hooks test until it can be properly fixed [17:40] ogra, ijohnson: there would need to be a review-tools override. this novel use of the content interface has been used once elsewhere. it is open for everyone since the snapd team might want to design something a bit better [17:40] err [17:40] ogra, ijohnson: it isn't* [17:40] right [17:43] * cachio afk 10mins [17:46] * zyga resumes working [17:58] jdstrand, yeah [18:24] PR snapd#7890 opened: tests/many: quiet lxc launching, file pushing [18:51] PR snapd#7891 opened: devicestate: use correct model constraints in remodel/gadget updates [18:52] PR snapd#7887 closed: [RFC] seed,devicestate: check gadget model constraints when seeding [19:16] rbasak: exploring ijohnson's idea would probably be best, but if it turns into a timer/journald thing, that is maybe ok. the other thing that could be done is to use a 'snap set' on the certbot snap to allow 3rd party plugins at all [19:22] rbasak: that in and of itself doesn't help much due to cut and paste, but if the option was like: snap set certbot allow-3rd-party-plugins-for-admin=true [19:23] rbasak: or something scary and eye catching. again, just an idea [19:47] roadmr: hi! can you pull 20191211-1947UTC? [19:48] roadmr: since the last request, it is all overrides and updates for the new 2.43 interfaces [19:58] PR snapd#7886 closed: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 <⚠ Critical> [19:58] PR snapd#7890 closed: tests/many: quiet lxc launching, file pushing [20:05] jdstrand: sure thing, we're still stuck deploying the last one I pulled but I'll put this in the queue :) [20:06] roadmr: if it would make it any easier, using this one instead of the last would be fine. up to you [20:07] jdstrand: well it's a sort of pipeline, the other one is in the pipeline regardless [20:07] * cachio afk [20:08] ok [20:23] PR snapd#7882 closed: devicestate: only run ensureBootOk() in "run" mode [20:54] ijohnson: hi, commented the PR [20:56] is it possible, that there is some race-conditions on the tests ? Maybe they share some common resource, so if they run parallel on two or more repos, that they crash ? I'm new to snapd, so i didn't read the full source of the integration tests yet [20:59] cachio: I see you also commented on 7865. [21:07] PR snapd#7883 closed: snapstate: relax gadget constraints in ConfigDefaults Et al [21:32] jdstrand: wow, this review-tools change broke 12 tests in the dashboard test suite :/ === pedronis_ is now known as pedronis [21:36] roadmr: I suppose it's snap_declaration tests? we added quite a few interfaces [21:37] pedronis: yes, looks like it [21:37] roadmr: let me know if I can help or something isn't clear [21:38] pedronis: sure, I'll probably need a review on the MP that adjusts the tests [21:38] audio-playback was added, pulseaudio was removed? [21:38] roadmr: ok, np doing that [21:38] roadmr: pulseaudio wasn't removed but it's property changed [21:38] its [21:38] so it belong to different categories [21:38] now [21:39] roadmr: so I expect in those tests it will disapper from some sets and appear in others [21:40] pedronis: right I have pulseaudio in EXPECTED_NOT_PRIVILEGED_INTERFACES, where should it be now? [21:40] is it privileged now? [21:40] roadmr: yes [21:40] but I don't remember exactly the name of the vars and sets [21:41] I would need to look [21:41] pedronis: thanks, no problem, I just moved it to EXPECTED_PRIVILEGED_INTERFACES and that one test passes now [21:41] 11 more to go :) (Maybe this will fix some others too) [21:43] roadmr: some tests have used it explicitly those will be more fun [21:43] pedronis: I'm all for fun :) [21:43] roadmr: for the tests that use it explicitly maybe s/pulseauio/audo-playback/ is the easiest [21:44] fix [21:44] pedronis: sure, I can try that [21:44] ah, maybe not [21:44] need to think [21:46]