[01:04] PR snapcraft#1367 closed: catkin plugin: add support for ROS Lunar [02:34] PR snapcraft#1332 closed: cli: provide a whoami command [04:55] PR snapcraft#1363 closed: tests: use pyramid as a router for the fake servers [05:40] PR snapd#3517 opened: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese [07:36] good morning mvo, i'm already running the core-revert stable -> edge -> stable test but it seems to get stuck after the first refresh, this will be addressed by snapd#3517, is that correct? [07:36] PR snapd#3517: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese [07:45] mvo: the error i get is "Jun 23 07:15:00 localhost snap[1685]: cannot open cookie file /var/lib/snapd/cookie/snap.network-managercannot stat /var/lib/snapd/seccomp/bpf/snap.network-manager.networkmanager.bin: No such file or directory" [08:10] mvo: fwiw we got a new edge core built from the edge ppa this morning, maybe there are bits in there that shouldn't be part of 2.26.last === chihchun_afk is now known as chihchun [08:52] fgimenez: thank you, I was able to reproduce, the cookie error is a red herring, the real issue is that we have a race, I think #3517 will fix it [08:58] mvo: great thank you, let me know if i can be of any help [09:00] fgimenez: no worries, I just need reviews [09:13] * zyga waves from Poland [09:16] zyga: welcome home! [09:16] mvo: hey, thank you :) [09:17] how are things? [09:17] I'm pretty sleepy but eager to wake up, the plane was delayed by two hours and departed after midnight... [09:17] but it's all behind us now, the day awaits [09:17] PR snapd#3516 closed: asserts: implement FindManyTrusted as well [09:17] zyga: things are good [09:18] zyga: if you want to review stuff, 3517 might be an interessting one [09:18] yes, I think that's a good use of my time today [09:18] zyga: 3512 as well [09:18] zyga: I think I will merge the shellcheck ones with a single reivew only, those are pretty mechanical and tests ar efine [09:19] zyga: 3514 is an easy win [09:20] mvo: am I reading 3512 right that it will re-exec tools on distros that don't reexec? [09:20] mvo: I think this is very undesirable and will break if used today [09:20] PR snapd#3511 closed: tests: shellcheck improvements for unit tasks [09:21] zyga: unless I made a mistake it should not do this. it will look at the running snapd, if that is re-execed it will use the reexecd path [09:21] mvo: ah, ok, let me read that in detail [09:21] mvo: but that should be good [09:21] PR snapd#3514 closed: wrappers: add SyslogIdentifier to the service unit files [09:21] zyga, hey! :) [09:22] zyga: the code could actually be even simpler, it could just always use $dirname("/proc/self/exe")+tool-name [09:22] fgimenez, ping [09:22] zyga: but I think that would break some tests so the way its written now should be ok [09:22] pstolowski: hey :) [09:22] mvo: mmmm, indeed [09:22] hey pstolowski and zyga :) [09:22] hey fgimenez :) [09:23] mvo: nice way to solve the current symlink issue btw [09:23] fgimenez, hey, advice needed [09:23] zyga: how was your trip? [09:23] PR snapd#3509 closed: tests: shellcheck improvements for tests/nested tasks [09:24] zyga: thank you! [09:24] pstolowski: sure, how can i help? [09:25] fgimenez, i'd like to create a spread test for revert-hook that I implemented; looking at our revert spread test, we use test-snapd-tools from the store and then switch to the fake store to simulate refresh, so that we can revert. but for my test I need a new custom snap with revert hook inside [09:26] fgimenez, so question is, how to do that with minimum hassle [09:27] fgimenez: exhausting, the trafic on costa brava was very heavy in anticipation of the holidays [09:27] fgimenez: the plane was delayed because of thunderstorms in France [09:27] fgimenez: plus lots of stress with packing everything on the very last moment [09:28] fgimenez: but it's all over now so that's all behind me :) === chihchun is now known as chihchun_afk [09:29] pstolowski: we have been creating the test snaps required by specific tests and, when needed, uploading them to the store under the shared account, i think in this case that should be the right thing to do [09:31] fgimenez, sounds good. I think it would be fine to add this new hook to test-snapd-tools; this hook will be a simple one liner that e.g. drops a file somewhere so I can verify it was run. what do you think? [09:31] zyga: that's the spirit! :) happy to hear that all went well after all, also tonight is "noche de san juan", good moment to burn the old and embrace new things :) [09:32] fgimenez, btw, i'm going to Spain for my vacation in ~3 weeks, reportedly close to where zyga lived ;) [09:34] * zyga stops reviews for a moment and goes to make coffee [09:34] pstolowski: it's a very beautiful place, you'll enjoy for sure :) [09:35] fgimenez, :) [09:37] pstolowski: about test-snapd-tools i'd personally prefer to have an specific snap for this test, something like test-snapd-with-configure, test-snapd-with-revert in this case, so that the purpose of each one is clear [09:37] Heya [09:38] fgimenez, ok, fine by me [09:38] niemeyer, hey! [09:38] fgimenez, do we use our tests/lib/snaps/ as a source for building these snaps for the real store? [09:39] zyga: Happy to hear the move went fine, despite the unavoidable stress it entails :) [09:41] niemeyer: hey! [09:41] niemeyer: yes, it's all good now [09:41] niemeyer: kids are running around the place re-discoveing early childhood items [09:44] zyga: 3464 probably needs a merge of master to make spread work [09:45] what happens when a snap previously published in the store with strict confinement gets an update that declares classic confinement? will the update be applied silently? [09:49] 'Snap 'ubuntu-core' for 'powerpc' cannot be found in the 'edge' channel.' [09:49] we have a ppc64el ubuntu-core but no powerpc? how come? [10:02] zyga: a quick look at 3517 would be great, then I can (hopefully) merge and get a new core over lunch for the nested tests [10:12] mvo: ack, looking [10:13] mvo: I have spotty network here, I need to fix it (after the sprint) so don't feel discouraged if I dissapear for a moment [10:16] zyga: Lots of nostalgia :) [10:16] mvo: Just trivials on snapd#3512 [10:16] PR snapd#3512: cmd: avoid using current symlink in InternalToolPath [10:17] niemeyer: nice, thank you [10:17] ppisati: I think we don't have powerpc because we can not (or could not back then) build snaps for powerpc [10:18] mvo: np, review queue looks quite nice today actually :) [10:18] fgimenez: Didn't we decide to drop the static tests from within Travis? [10:19] mvo, fgimenez: Btw, any more issues on Linode? [10:19] It's sort of amazing that we managed to have a bug on our end and a bug on their end on the same week [10:19] niemeyer: linode was fine for me in the last few hours [10:19] (including last night) [10:19] mvo: Phew [10:20] niemeyer: afaik they are moved to a spread task let me check [10:20] fgimenez: That's what I thought as well, but looking through logs recently they seemed to be back [10:21] niemeyer: i've seen some authentication errors like "ssh error 2017-06-22 16:39:58 Discarding linode:debian-unstable-64 (Spread-04), cannot connect: cannot connect to linode:debian-unstable-64 (Spread-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain" [10:21] niemeyer: indeed :) [10:21] mvo: two nitpicks on 3517 [10:21] fgimenez: Ok, but that's from yesterday.. there was a real bug on the Linode side this time around [10:21] fgimenez: They fixed it late yesterday [10:22] sure, I will reply inline, thanks a bunch [10:22] niemeyer: great, about the static checks they are currently run here https://github.com/snapcore/snapd/blob/master/tests/unit/go/task.yaml#L17 [10:22] zyga: atoi(getenv("not-exist")) will segfault :) atoi crashes when oyu feed it a NULL [10:23] niemeyer: and travis only runs spread https://github.com/snapcore/snapd/blob/master/.travis.yml#L22 [10:23] mvo: I meant under the first if [10:23] mvo: just on the line I commented [10:23] fgimenez: Okay, it must have been some old code that hasn't merged back from master in a while then [10:23] fgimenez: Thanks for checking [10:23] mvo: or just use variables and be less fancy, I wanted to avoid the repeated getenv and atoi [10:24] zyga: aha, ok [10:24] zyga: I'm inclinded to merge and do a followup mostly to avoid waiting for the tests again, is that ok with you? [10:24] zyga: i.e. when I return from lunch I want to have a new core snap :) [10:25] mvo: certainly, I can follow up as well if you want [10:25] mvo: small bite for the troubled voyager [10:25] zyga: sure, even better [10:25] niemeyer: np, thank you, another weird error from linode this morning "cannot boot linode:ubuntu-16.04-32 (Spread-50): linode disk /dev/sda not ready to boot. Please contact support." https://travis-ci.org/snapcore/spread-cron/builds/246018927#L669 [10:25] PR snapd#3517 closed: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese [10:27] FFS [10:27] fgimenez: This is the CI infra bug week [10:28] niemeyer: :) and the ssh issue seems to be still around, this build has it and is currently running https://travis-ci.org/snapcore/snapd/builds/246132571#L908 [10:29] niemeyer: about that, did you see those scaleway 128GB ram 64 core VMs that are on sale now? [10:29] niemeyer: I wonder if we could get really solid arm server spread tests this way [10:29] fgimenez: Thanks, will look into the console to see if it's the same issue and reopen the ticket [10:29] niemeyer: not pi-like tests, just serious arm server snapd [10:29] zyga: The problem with arm is that in general we want to test the actual device [10:30] niemeyer: it _is_ the actual device, this is not the old arm but the new big-iron arm that is not device specific [10:30] zyga: That's why those magic SD muxes are so interesting [10:30] niemeyer: modern x86_64 server [10:30] niemeyer: just with arm now :) [10:30] zyga: Sorry, I don't get the point [10:31] niemeyer: we test x86 extensively in VMs [10:31] niemeyer: and we test arm on hardware (IOT devices) [10:31] zyga: Do you mean this 128GB RAM and 64 core server is actually a Raspberry Pi behind the scenes? [10:31] :P [10:31] niemeyer: but we don't have any automated ARM tests like we do for x86 because we don't have arm server hardware (with virtualization and everything) [10:32] niemeyer: I'm saying we could run the very same suite of tests we use on x86 VMs on that arm system for better coverage [10:32] zyga: Yeah, and that's what I meant above [10:32] plus, it's beefy and on sale [10:32] niemeyer: arm is not just the pi's [10:32] zyga: The problem is that this doesn't really solve the question of whether the supported devices are broken or not [10:33] niemeyer: yes and I'm not saying it does [10:33] zyga: Yes, it's one more testing platform, that will need custom kernels, custom gadgets, custom everything [10:33] niemeyer: no, no custom kernels [10:33] zyga: Unless someone is working with us to support that, we can't just add more platforms [10:33] niemeyer: arm servers use one kernel [10:33] niemeyer: all acpi and standards based like x86 servers [10:33] zyga: That hasn't been my experience with anything arm [10:34] niemeyer: because you deal with non server hardware [10:34] zyga: Ok, so which of our kernels will this use? [10:34] niemeyer: stock ubuntu kernel for aarch64 [10:35] * zyga has to fix his wifi, signal dropping every few seconds [10:35] * zyga -> brb [10:37] zyga: Okay, so classic Ubuntu rather than Ubuntu Core [10:41] niemeyer: yes, I'd start with that === chihchun_afk is now known as chihchun [11:09] * Chipaca ~> lunch [11:13] mvo: https://github.com/snapcore/snapd/pull/3518 [11:13] PR snapd#3518: cmd/snap-confine: various small fixes and tweaks to seccomp support code [11:14] PR snapd#3518 opened: cmd/snap-confine: various small fixes and tweaks to seccomp support code [11:14] zyga: ta [11:15] Hi. I had previously asked about a web app store for snaps. And I was suggested to use snapweb. I am facing a problem with snapweb though. I am able access my Ubuntu desktop using the web app store on a browser on the same PC. But I am unable to access my raspbery pi (running on ubuntu core) from the browser on the PC :| [11:15] PR snapd#3519 opened: arch: the kernel architecutre name is armv7l instead of armv7 [11:15] Also if it helps, both the PC and the pi are on the same network. [11:17] Vamsi: what kind of error are you seeing? [11:17] mvo: +1 [11:18] mvo: consider merging my branch too if we lost that slot anyway [11:18] zyga: ta [11:18] zyga: the browser says that the accsess token is invalid. [11:19] Vamsi: I see [11:19] unfortunately I don't know much about snapweb internals [11:19] but it accepts the access token from the PC though. [11:21] * Chipaca ~> really lunch [11:22] * zyga knows the feeling very well Chipaca :) [11:24] mvo: reviewed 3512 [11:24] mvo: let me know if you want me to change that [11:24] mvo: otherwise I'll work on base updates [11:30] PR snapd#3520 opened: asserts: add enterprise-store assertion type [11:34] * zyga focuses on base snaps === chihchun is now known as chihchun_afk === ahoneybun_ is now known as ahoneybun [12:16] fgimenez: "In this case there was a problem with how the host was reserving disk space while creating new disks. However, one of our administrators was able to fix the problem, and it shouldn't occur again in the future." [12:17] niemeyer: \o/ ? not sure if that souds really well :) [12:17] fgimenez: I think it's fine :) [12:18] Yesterday the response was "The previous message yesterday was "It looks like this one was a fluke. I've been able to thaw out the same image on your Linode just fine. Please let us know if it happens again and we'll be glad to look into it further." [12:18] hello. Is https://bugs.launchpad.net/snapd/+bugs the right place for snapd bugs? I filed one yesterday but nobody was subscribed to it and it's still in "New" state [12:18] Which is less fine :) [12:19] jacekn: If you want quick feedback, the forum is the best place to report issues and discuss them [12:21] niemeyer: ack. In this case it looks like a bug so I reported it. It's not super critical [12:22] niemeyer: but is https://bugs.launchpad.net/snapd/+bugs the right place or there is somewhere else I should be reporting bugs? [12:22] jacekn: If it's about snapd, that's the right place [12:22] great, thanks for confirmation [12:23] np [12:26] niemeyer: that location looks dead BTW, there are many old bugs that were not even triaged [12:26] jacekn: I really mean it when I said the forum is the place to discuss and get quick feedback [12:27] niemeyer: as in you prefer people to open forum threads about bugs rather than file them in LP? [12:29] jacekn: As in that's where all the daily activities happen, and that's where we discuss issues most frequently.. if you file a bug in Launchpad, it's tracked and will be eventually looked at, but there are many more eyes in the forum every single day [12:29] jacekn: If you want to talk about the bug today, please open a forum thread [12:31] PR snapcraft#1376 opened: options: fix s390 kernel arch [12:33] ppisati, wow, do we ever exect to support s390 UbuntuCore installs ? [12:33] expect [12:34] * ogra_ thinks s390x and ppc64el should simply not be built by the plugin by default ... it is unlikely that anyone will ever actually boot UbuntuCore on such systems [12:34] (kernels that is) [12:34] niemeyer: thanks for explaining. I don't want/need to talk about the bug, totally happy to wait. I wanted to make sure that LP bug tracking was not dead (because that's what it may look to people without context abotu forums) [12:34] PR snapcraft#1377 opened: kernel plugin: add default targets per powerpc, ppc64el and s390x [12:34] ogra_, our contracts says different =) [12:35] xnox, you mean there will be people booting off an UbuntuCore image natively ? [12:35] ogra_, and core is very much usable in kvm / openstack on both s390x and ppc64el. [12:35] ogra_, yes. [12:35] wow [12:35] jacekn: It's not dead, but it's not well maintained today either, as you've noticed. That's something we need to fix. [12:37] * ogra_ notes that he just triaged two snapd bgs that were filed today ... definitely not dead, just not moving super fast since many issues are resolved in forum discussions before even becoming actual bugs [12:44] pedronis: question about aliases: in the json you get from the store, is the 'target' the name of the app? [12:44] Chipaca: which json? [12:45] pedronis: ah, maybe this doesn't come to you as json yet [12:45] but in the declaration itself i guess? [12:45] Chipaca: it's in the assertion [12:45] is not json [12:45] that'd explain why a quick search didn't find me the json bits of this :-) [12:45] pedronis: ok. I'll be getting a list of aliases from the store, in json [12:46] ok [12:46] pedronis: [{"name": "foo", "target": "bar"}, ...] [12:46] but that's unrelated to how we do aliases [12:46] for actually installed snaps [12:46] those comes from the signed snap-declaration [12:46] pedronis: right, this is for command-not-found, ie for non-installed snaps [12:46] I know nothing about that (atm) [12:46] ok [12:47] but yes, internall we keep things as name, taget [12:47] I mean in the internally in the store [12:47] pedronis: and target is the app name? [12:47] yes [12:47] ok [12:47] it's a plain app name [12:48] not snap.app [12:48] just double-checking with nessita_ that things are sane :-) [12:48] that's fine, it'll be "inside" a snap [12:48] {"package_name": "some-snap", "aliases": [...]} [12:48] so i'll know the snap :-) [12:50] fgimenez: yay, good news. the nested core-revert test seems to be working now with current edge [12:51] mvo: \o/ wonderful news!!! congrats for all the hard work [12:51] mvo: shall i start with the full validation? [12:57] fgimenez: some smoke testing for edge with the core revert would be great, or just an independant re-run, I need to get this all backported to 2.26, then we can do te real validation [13:01] mvo: sure, i have the core revert already running locally, in fact it was started automatically too by spreadcron when the new core was detected but it was killed because of the time restriction https://travis-ci.org/snapcore/spread-cron/builds/246175108 [13:02] i'll run some additional smoke tests === chihchun_afk is now known as chihchun [13:27] cachio: we are still getting create-key timeout errors, have all the fixes landed? https://travis-ci.org/snapcore/spread-cron/builds/246175157 [13:29] fgimenez, ouch [13:29] fgimenez, it is failing to restart the service [13:32] fgimenez, the manual was working better than the automatic restart [13:35] did you merge your branch with the latest changes in master? [13:35] fgimenez, [13:37] cachio: yes, this is executed from the current master [13:38] cachio: https://github.com/snapcore/spread-cron/blob/snapd-core-i386-edge/run-checks [13:38] fgimenez, ok, thanks for the info, I'll research more [13:39] cachio: ok thx [13:41] mvo: nice speed improvement in https://github.com/snapcore/snapd/pull/3502. Thanks for doing that PR (fyi, I commented) [13:41] PR snapd#3502: snap-seccomp: add more tests [13:43] jdstrand: hey [13:43] jdstrand: greetings from Poland :) [13:44] zyga: hi! :) nice to be back? [13:46] jdstrand: it's a big change in our lives, not sure yet :) [13:46] mvo: I also notice https://github.com/snapcore/snapd/pull/3504 isn't committed yet. isn't it needed to truly test the revert regression that the bpf fixes? [13:46] PR snapd#3504: interfaces: bring back seccomp argument filtering [13:46] jdstrand: thank you for the review on the cleanup, I'll follow up shortly [13:46] zyga: oh, permanently? wow [13:46] zyga: thanks you for doing it :) [13:46] jdstrand: yes, all our stuff is packed into ~60 boxes now [13:46] jdstrand: (most haven't arrived yet) [13:47] some quick example code went through as is and then I missed the NULL checks :\ that's why we have more than one reviewer! :) [13:47] jdstrand: yep, it's always possible to miss something [13:48] jdstrand: but I'm very happy with the changes towards precompiled bpf [13:48] zyga: does this mean you will attend (in part or in whole) the Warsaw sprint? [13:48] jdstrand: it's going to be safer and faster [13:48] jdstrand: I plan to but I didn't talk to JamieBennett about it yet [13:48] jdstrand: if anything I'll drop by to get a coffee and say hi :) [13:48] zyga: if you do, we can visit (I'll be there) [13:48] mvo: core-revert succeeded with the edge core snap \o/ I'm currently generating images for running the full suite on them, will keep you posted [13:48] jdstrand: I'd never miss the only sprint in warsaw :) [13:48] hehe :) [13:49] jdstrand: that's great to hear :-) I'll show you around Warsaw (except I need to catch up after 6 years of living in Spain) [13:49] fgimenez: note my above question to mvo re https://github.com/snapcore/snapd/pull/3504 [13:49] PR snapd#3504: interfaces: bring back seccomp argument filtering [13:52] jdstrand: aha thanks, good to know, all seems to be working fine now fwiw, anyway will keep running it in a loop to try to catch racy results [13:55] fgimenez: I guess there was the netlink revert failure that never had the policy reverted. I don't know if you are testing that snap, but if you are, then that PR isn't strictly needed to demonstrate the fix [13:56] jdstrand: hey, thanks for the review of 3502. re 3504 - our test also failed without the reverts, but I agreee, we should do the test with that one merged too. we had a failure with bluez that hit exactly the same issue so I'm quite confident that the fix is there. but then, I'm much in favour of double checking :) [13:57] jdstrand: it needs a second review, then it can go in [13:58] mvo: yeah, I just remembered netlink wasn't reverted [13:58] jdstrand: exactly, the test includes bluez, which was failing after revert with "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process", with the current core at edge this problem is gone [13:58] ok, perfect [13:58] perhaps zyga would want to peek at 3504 :) [14:01] PR snapd#3519 closed: arch: the kernel architecutre name is armv7l instead of armv7 [14:43] It's getting to that point where I type "snap install blah" and then wonder why nobody has snapped blah yet [15:19] PR snapcraft#1378 opened: Integration tests for snap command with target arch [15:26] fgimenez: hm,hm, it looks like #3519 got merged 4h ago but its not part of the snapd-vendor branch (and hence not in the ppa) yet, any idea? [15:26] fgimenez: can I manually trigger this? [15:29] mvo: mm maybe the build after merging on master didn't succeed, the sync is done after merge + green build [15:30] mvo: i'll check, anyway you can retrigger from #mupmock on tg, this will get the current master no matter if the test passed or not, let me show you [15:40] PR snapd#3521 opened: snap-seccomp: make sure snap-seccomp writes the bpf file atomically [15:41] mvo: i got two errors executing the suite from master on the latest edge http://paste.ubuntu.com/24933366/, if you could take a look that would be great, i'm trying to reproduce both of them now [15:42] fgimenez: thanks, 2017/06/23 16:52:12 Error executing external:ubuntu-core-16-64:tests/main/server-snap:goServer : is strnage, no denials or anything [15:44] fgimenez: the snapd-notify is hopefully fixed with 3515 [15:44] cachio: could oyu please check 3515 why the testsuite fails? [15:44] mvo: ok thx, i'll focus on server-snap:goServer then [15:45] Chipaca: 3521 is something for you, the best thing is that we probably caught it via one of the tests :) [15:45] (spread tests) [15:54] mvo: it fails consistently, adding -v to the nc call i get "nc: connect to ip6-localhost port 8081 (tcp) failed: Cannot assign requested address", the session is open in case you want to get anything else [15:54] fgimenez: is the service itself running? [15:56] mvo: yep, it's up and listening on 8081 http://paste.ubuntu.com/24933471/ [16:07] mvo: i think this is probably related to the changes to the way we manage ipv6 when /etc/gai.conf is not writable http://paste.ubuntu.com/24933600/ [16:08] fgimenez: aha, puhhh, that a) makes sense b) means I did not break it .) [16:09] mvo: yep :) http://paste.ubuntu.com/24933635/ i'll prepare a PR for fixing it [16:09] fgimenez: I broke master bug 35212 should fix that [16:09] Bug #35212: unable to compose messages

[16:10] mvo: thx, np [16:12] mvo: anyway, it won't affect the backport to 2.26, we didn't have any changes related to /etc/gai.conf there === chihchun is now known as chihchun_afk [16:29] PR snapd#3522 opened: tests: do not disable ipv6 on core systems [16:52] PR snapcraft#1374 closed: tests: set up the spread execution in linode [17:04] PR snapcraft#1379 opened: blank version not allowed in snapcraft.yaml [17:16] PR snapcraft#1380 opened: release changelog for 2.32 [17:44] PR snapd#3523 opened: tests: fix for create-key task to avoid rng-tools service ramains alive [18:11] PR snapd#3524 opened: asserts,overlord/devicestate: allow and support serials signed by a trusted authority instead of the brand [18:25] PR snapd#3522 closed: tests: do not disable ipv6 on core systems [18:41] PR snapcraft#1381 opened: tests: install pyramid in autopkg integration tests [19:29] mvo, sorry for the delay [19:30] the 3515 is failing due to the reboot error [19:30] mvo, it is one of the most difficult tests to fix [19:32] mvo, it always happens on ubuntu-core-16-64 and the issue is that after the core image is created and the system rebooted, the machine does not start anymore [19:35] mvo, I also pushed a fix for the create-key issue, this should be the final one [19:44] cachio: nice, thank you [19:44] mvo, if you can retrigger it should be fine [19:44] cachio: yeah, I noticed the that the ubuntu-core-16-64 issue is tricky [19:44] cachio: sure, let me do that [19:45] mvo, then if you can trigger also 3523 [19:46] if failed because of the snapd-notify [19:46] it failed [19:48] cachio: sure thing [19:49] cachio: I can not (easily) retrigger autopkgtests, we need to ignore those for now. sorry for that [19:54] mvo, np [20:15] PR snapd#3525 opened: interfaces: add password-manager-service implicit classic interface (LP: #1653769) [20:59] niemeyer, could yo please take a look to Spread-14 [20:59] in the console [20:59] niemeyer, 50.116.52.47 [21:01] niemeyer, in case it is powered off, could yo uplease try to start it and see the screen output? [21:14]