[02:49] <bkerensa> valorie: you made the news
[02:49] <bkerensa> :D
[02:49] <bkerensa> valorie: http://www.datamation.com/open-source/will-xp-users-shun-windows-8-in-favor-of-ubuntu-1.html
[02:50] <bkerensa> Washington LoCo is mentioned
[02:50] <bkerensa> :D
[03:16] <valorie> nice!
[03:17] <valorie> good criticism, for sure
[03:18] <valorie> we need more people, and I guess it takes people to draw new people
[03:18]  * valorie has zero time for the loco
[03:18] <valorie> http://hint.fm/wind/ is really cool
[03:21] <valorie> you can really see where the big mountains are, in our area
[04:55] <Salt> bkerensa, nice
[04:56] <Salt> but yeah, the deal is no one has stepped up to take things over and get the loco active
[04:57] <Salt> I have way WAY too much on my plate but will support anyone who'd like to
[05:23] <bkerensa> valorie: What I think it that LoCo's as a program need more resources
[05:23] <bkerensa> LoCo's cannot be expected to attract people out of thin air without CD's and material
[05:23] <bkerensa> Oregon was a struggle uphill constantly
[05:23] <bkerensa> Salt: totally understood
[05:25] <valorie> well sure
[05:25] <Salt> yeah, we usually make a decent showing at lfnw, but since that's about it we don't really get new blood
[05:25] <valorie> but the article correctly points out that we are preaching to the choir now
[05:25] <valorie> but you need a bunch of people in order to have fun taking it to the masses
[05:26] <valorie> a few people just get burned out
[05:26] <valorie> "struggle uphill constantly" doesn't sound fun
[05:26] <valorie> I've got enough of that in Real Life
[05:39] <savedjuli> hi
[05:42] <bkerensa> savedjuli: hi
[05:42] <bkerensa> Salt: speaking of lfnw I plan to be there this year :) I will be running a Mozilla booth likely
[05:47] <valorie> cool!
[05:47] <valorie> finally we get ben outta Portland
[05:47] <valorie> :-)
[05:49] <bkerensa> valorie: Yeah I need a break
[05:49] <bkerensa> a break from Ubuntu too
[05:49] <bkerensa> vacay next month
[05:50] <Salt> bkerensa, schweet
[05:51] <Salt> I'll be there at the gslug/ubuntu-wa table
[05:51] <bkerensa> cool
[05:51] <bkerensa> Portland is having a Winter Coders Social in December
[05:51] <bkerensa> so I ordered 5 dozen Firefox Donuts
[05:51] <bkerensa> :D
[05:51] <Salt> sweet


[07:18] <zyga> good morning
[07:18]  * zyga welcomes everyone after the busiest break ever :)
[07:53] <zyga> brb
[08:02] <zyga> re
[08:07] <zyga> hello mvo :)
[08:13] <mvo> hey zyga
[08:13] <zyga> how are you doing?
[08:13] <mvo> zyga: I think what you had last week (infection) got me sunday and today :/
[08:13] <mvo> zyga: but otherwise doing well!
[08:13] <zyga> ouch, good luck with that
[08:13] <mvo> zyga: how are you?
[08:13] <pstolowski> morning!
[08:13] <zyga> hey pstolowski
[08:13] <zyga> mvo: tired
[08:13] <zyga> mvo: they are still at the hospital
[08:14] <zyga> maybe if all goes good they will be back on Tuesday
[08:14] <zyga> but I was told the exact same thing a week ago
[08:14] <mvo> zyga: uh, good luck!
[08:17] <mvo> sil2100: hey, are you guys in the process of building new cosmic images or something? or any other reason why our snapd sru to comsic got rejected?
[08:22]  * zyga goes to make tea, picks up ancient PR https://github.com/snapcore/snapd/pull/6111
[08:22] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[08:22] <mwhudson> mvo: the message i saw implied that vorlon wanted the version currently in -proposed to migrate to updates rather than superseding it and waiting another 7 days
[08:22] <mvo> mwhudson: aha, misread the message then
[08:23] <mvo> mwhudson: yeah, thats fine
[08:23] <mvo> mwhudson: I missed that cosmic got accepted
[08:23] <mwhudson> mvo: well, or i did :)
[09:05] <sil2100> mvo: it got rejected? What was the rejection message?
[09:36] <pstolowski> mvo: hey, i've run console-conf twice and it consistently fails on network_wifi_static test - http://paste.ubuntu.com/p/fGwfvvSymX/ - know? must be a flaky test since i had no issue with console-conf during all the previous testing
[09:37] <pstolowski> *known
[09:40]  * dot-tobias says hi
[09:40] <Chipaca> o/
[10:01] <zyga> hey Chipaca
[10:01] <zyga> it's good to be back :)
[10:01] <Chipaca> zyga: :-) you're feeling better, then?
[10:01] <Chipaca> zyga: less contagious?
[10:01] <zyga> Chipaca: yes
[10:01] <zyga> Chipaca: though the expanded family is not reunited yet, they are still at the hospital for a few more days
[10:02] <zyga> but there's good progress so hopefully by the middle of the week we'll be all home
[10:16] <popey> Chipaca: can I just give you (and team) a massive <3 for having the date in snap info now. It really improves my workflow.
[10:16] <sil2100> mvo: ok, hmmm
[10:17] <mvo> pstolowski: thanks! now that sergio is back its probably best to check with him, I have not run this test myself on the pi, only in a VM
[10:17] <pstolowski> mvo: ok
[10:17] <sil2100> mvo: so, since there's 2.37.1+18.10 in cosmic-proposed ready to go, I guess Steve wanted that to be released, right?
[10:17] <sil2100> mvo: I remember you mentioned .1 didn't have any blocking issues?
[10:17] <Chipaca> popey: that one goes all the way up to sabdfl
[10:18] <popey> It's ace
[10:18] <mvo> sil2100: sorry for the slow reply, was in a meeting
[10:18] <mvo> sil2100: there is one small issue if people have symlinks in /var/lib/jenkins
[10:18] <mvo> sil2100: but I think we can fix this by removing "/var/lib/jenkins" from the core snap
[10:19] <mvo> sil2100: I slightly prefer .2 as it fixes this known regression but its really a corner case
[10:20] <sil2100> eeek, so the core18 'fix' for jenkins that added /var/lib/jenkins actually caused a regression?
[10:21] <pedronis> sil2100: it was not really a fix actually
[10:21] <mvo> sil2100: we misunderstood a subset of the bug :(
[10:27] <zyga> hey pedronis :)
[11:07]  * Chipaca takes a break
[11:13] <mup> PR snapd#6488 opened: interfaces/network-manager: no peer label check for hostname1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6488>
[11:35] <pstolowski> mvo: do you have a moment to re-review https://github.com/snapcore/snapd/pull/6486 ? that would unblock another pr
[11:35] <mup> PR #6486: interfaces/hotplug: renamed RequestedSlotSpec to ProposedSlot, removed Specification <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6486>
[12:18] <pstolowski> cachio: hey
[12:18] <cachio> pstolowski, hey
[12:19] <dot-tobias> If someone from the Snappy HWE team would be so kind to have a look at this: https://forum.snapcraft.io/t/apparmor-denials-for-dbus-objectmanager-network-manager/9885/4?u=tobias → any ETA for network-manager 1.10 track on ARM?
[12:19] <pstolowski> cachio: how was your holidays?
[12:19] <cachio> pstolowski, awesome!!! thanks for asking
[12:19] <mvo> hey cachio ! welcome back
[12:20] <cachio> mvo, thanks
[12:20] <cachio> I am in the jungle again :(
[12:21] <cachio> mvo, I am creating images to run beta validation for 37.2
[12:23] <pstolowski> cachio: great!
[12:25] <pstolowski> cachio: i've been running console-conf validation tests this morning, and network_wifi_static test was failing consistently; is this a known issue? full log - http://paste.ubuntu.com/p/fGwfvvSymX/
[12:25] <cachio> pstolowski, checking
[12:26] <cachio> pstolowski, it was passing during last executions
[12:26] <cachio> pstolowski, which board is that?
[12:27] <cachio> pi2 pi3?
[12:27] <pstolowski> cachio: pi3
[12:28] <pstolowski> cachio: it's possible i did something wrong. the testing guide doesn't tell to pre-configure pi3 before tests, but i found it was necessary (manual setup of console-conf on first boot, so that test scripts can connect)
[12:29] <cachio> pstolowski, yes, initial setup is required
[12:29] <cachio> it is for 37.2?
[12:30] <cachio> niemeyer, hey
[12:30] <cachio> niemeyer, I see a permissions error creating new images https://paste.ubuntu.com/p/zsPBGfszkw/
[12:30] <niemeyer> cachio: Hey
[12:31] <cachio> niemeyer, all the images scripts have failed due to this permission error
[12:31] <Chipaca> ogra: curious that you'd have 6 hardlink-count-1 files in the cache; has anything strange happened recently?
[12:32] <Chipaca> ogra: like, snapd crashing mid install?
[12:32] <Chipaca> or … dunno :-)
[12:32] <niemeyer> cachio: Are you sure you have the right credentials?  Just reminding of the previous issue we discussed
[12:32] <niemeyer> cachio: I'm checking the project
[12:33] <cachio> niemeyer, well, those scripts are using the sa that you created a time ago
[12:33] <cachio> the new one
[12:33] <cachio> image-baker
[12:33] <niemeyer> cachio: I know they should be.. just raising the fact last time it was a credentials issue.
[12:33] <niemeyer> cachio: Anyway, checking
[12:34] <Chipaca> ogra: ah, figured it out, you've done a 'snap remove' :-)
[12:35] <pstolowski> cachio: ok. i'm pretty positive console-conf works and it was just something wrong with the test. i've been using console-conf manually a lot last week during beta-validation
[12:37] <Chipaca> where should I put a de-logger? (that converts the debug http snapd logs to something more legible) test-snapd-tools?
[12:37] <cachio> pstolowski, it is probably there is a problem with the test, I'll check it later today
[12:37] <cachio> pstolowski, it is for 2.37.2 right?
[12:38] <niemeyer> cachio: Done, please test now
[12:39] <niemeyer> cachio: Something must have changed in the code
[12:39] <niemeyer> cachio: Either way, I just added the permission.. doesn't seem problematic
[12:39] <pstolowski> cachio: right
[12:39] <cachio> niemeyer, what I saw reviewing the logs is that the image is created but the permission error is raised
[12:40] <cachio> niemeyer, no code changes in our side but perhaps the google library I am using changed
[12:40] <niemeyer> cachio: That's what I mean too
[12:41] <cachio> niemeyer, :)
[12:41] <cachio> niemeyer, thanks for the update
[12:41] <niemeyer> cachio: Please let me know if it works
[12:42] <cachio> niemeyer, can I run it now?
[12:42] <cachio> niemeyer, in progress
[12:44] <zyga> hey niemeyer :)
[12:44] <zyga> hey cachio :)
[12:44] <niemeyer> zyga: Heya!
[12:44] <niemeyer> zyga: How're things there?
[12:45] <zyga> niemeyer: great, I just got a call from my wife that they are coming home today :)
[12:45] <niemeyer> zyga: Fantastic news
[12:47] <mvo> zyga: \o/
[12:48] <mvo> cachio: thank you for the validation, we did a lot of those already, give me a sec, I will send you our trello link
[12:48] <cachio> mvo, THANKS
[12:49] <zyga> mvo: I've built the early version of refresh-app-awareness
[12:50] <zyga> zyga@yantra:~/snapd/cmd/snapd> snap refresh gnome-calculator
[12:50] <zyga> error: cannot refresh "gnome-calculator": snap "gnome-calculator" has running apps or hooks
[12:50] <zyga> niemeyer: ^ will be ready for review by the next sprint
[12:51] <mvo> cachio: see /msg - I sent you the link and also added you to the card
[12:51] <mvo> zyga: nice!
[12:51] <mvo> zyga: really nice
[12:52] <niemeyer> zyga: Sweet!
[12:53] <niemeyer> zyga: How's the strategy for not delaying forever going?
[12:53] <zyga> niemeyer: it's not, I just started on this todat
[12:53] <zyga> (I'm back after last week)
[12:53] <niemeyer> zyga: Ack
[12:54] <cachio> mvo, nice, it is ok if I finish the missing ones?
[12:54] <zyga> niemeyer: I think we will do what was planned in cape town
[12:54] <cachio> niemeyer, ERROR: (gcloud.compute.images.create) Could not fetch resource:
[12:54] <cachio> zyga, hey
[12:54] <mvo> cachio: sure
[12:54] <mvo> cachio: thank you!
[12:55] <zyga> all of the code so far is on https://github.com/snapcore/snapd/compare/master...zyga:feature/refresh-app-awareness?expand=1
[12:55] <cachio> mvo, I'll update the card
[12:55] <cachio> and review the results
[12:55] <niemeyer> cachio: ?
[12:56] <cachio> niemeyer, it is failing but now with that permission error
[12:56] <niemeyer> cachio: That's not a permission error
[12:56] <mvo> cachio: great, thank you!
[12:56] <niemeyer> cachio: The permission error is what comes below it
[12:57] <zyga> Chipaca: hey
[12:57] <Chipaca> zyga: 'sup
[12:57] <zyga> do you have a minute for a  silly question
[12:57] <zyga> so I added an extra check in Update and UpdateMany
[12:57] <zyga> when I run snap refresh gnome-calculator
[12:57] <cachio> niemeyer, right now it failed because I need to clean up the temp images
[12:58] <zyga> I get this delay of about 4 seconds
[12:58] <cachio> niemeyer, sorry, there was a name overlap
[12:58] <zyga> and then it does stuff and actually says that the snap cannot be refreshed
[12:58] <niemeyer> cachio: Coo
[12:58] <niemeyer> l
[12:58] <zyga> Chipaca: so either I did something silly and I really do the refresh check and then fail
[12:58] <zyga> or something else is at play
[12:58] <zyga> any ideas
[12:58] <zyga> ?
[12:59] <zyga> Chipaca: https://github.com/snapcore/snapd/compare/master...zyga:feature/refresh-app-awareness?expand=1#diff-4f584006240926759b614bfd921c5fc0R1147
[12:59]  * Chipaca looks
[13:01] <Chipaca> zyga: I'm not sure where the 4 seconds are coming from, but you're checking all snaps instead of just those that have a refresh?
[13:01] <zyga> Chipaca: I'm checking those that have the refresh, I think
[13:01] <Chipaca> zyga: you get the candidates after doing the soft refresh check
[13:01] <zyga> right
[13:01] <zyga> so it shouldn't be slow, right?
[13:02] <Chipaca> zyga: log stuff before, during, and after the loop?
[13:02] <zyga> is UpdateMany hit on one snap name?
[13:02] <zyga> or is that always routed to Update?
[13:02] <Chipaca> zyga: one snap goes to Update
[13:02] <pedronis> Update takes many more options
[13:02] <pedronis> snap refresh <1 snap>
[13:02] <pedronis> always goes through Update
[13:03] <zyga> 2019/02/11 14:03:42.831902 snapstate.go:1174: before soft check
[13:03] <zyga> 2019/02/11 14:03:42.832542 snapstate.go:1176: failed soft check
[13:04] <zyga> so the check itself is fast, must be something prior to that
[13:04] <zyga> I'll dig
[13:04] <pedronis> might be assertion refreshes
[13:04] <Chipaca> zyga: sorry, silly question
[13:04] <pedronis> if you have a lot of snaps
[13:04] <Chipaca> zyga: why check before looking for candidates?
[13:04] <Chipaca> you'd be erroring out even for snaps that don't have a refresh
[13:05] <zyga> ah, good point
[13:05] <zyga> well
[13:05] <pedronis> that sounds wrong :)
[13:05] <zyga> hmm
[13:05] <pedronis> especially for auto-refresh
[13:05] <Chipaca> zyga: also, also
[13:05] <Chipaca> zyga: why is softwarerefreshcheck not cehcking all snaps in a batch?
[13:05] <zyga> if you are running and you are asking to refresh something is it better to get <delay>nothing to do or <delay>cannot because running?
[13:06] <zyga> Chipaca: why would it?
[13:06] <Chipaca> zyga: the things it's doing look like they'd be a lot more efficient checking for N snaps at once instead of 1 at a time in a loop
[13:06] <zyga> which things specifically?
[13:06] <zyga> I could move the get-from-state part outside of the function
[13:07] <zyga> but other than that?
[13:07] <zyga> Chipaca: as for timing, Update is called after the delay, so something else is slow
[13:07] <zyga> Chipaca: zyga@yantra:~/snapd/cmd/snapd> SNAPD_DEBUG=1 snap refresh gnome-calculator
[13:07] <zyga> 2019/02/11 14:06:22.606869 cmd_linux.go:70: DEBUG: re-exec not supported on distro "opensuse-tumbleweed" yet
[13:07] <zyga> 2019/02/11 14:06:27.672286 error.go:100: DEBUG: error: cannot refresh "gnome-calculator": snap "gnome-calculator" has running apps or hooks
[13:07] <zyga> error: cannot refresh "gnome-calculator": snap "gnome-calculator" has running apps or hooks
[13:08] <zyga> Chipaca: the check is entirely per-snap anyway
[13:08] <Chipaca> zyga: the logs in snapd are the ones you want, not the ones in snap :-)
[13:08] <ogra> Chipaca, nothing has happened but my install is really old so it could well bee that at some point something did happen
[13:08] <ogra> definitely nothing recently though
[13:08] <zyga> aha
[13:09] <zyga> it checks for a zillion assertions first
[13:09] <Chipaca> zyga: as pedronis siad
[13:09] <Chipaca> said*
[13:10] <Chipaca> ogra: but it should be cleaned up on any install/refresh
[13:10] <ogra> hmm, weird then
[13:11] <Chipaca> ogra: can you turn on debug and install something you don't have? (may i suggest 'icdiff' :)
[13:12] <zyga> Chipaca: one more question
[13:12] <Chipaca> zyga: shoot
[13:13] <zyga> Chipaca: when refreshing many I may get three cases: some can be refreshed and some cannot or all can or cannot be refreshed
[13:13] <zyga> when all cannot be refreshed it can be a synchronous error
[13:13] <zyga> but when some can be refreshed
[13:13] <zyga> I would like to refresh those
[13:13] <zyga> and still do something sane with the ones I cannot
[13:13] <ogra> Chipaca, not right now but i'll try that later
[13:13] <zyga> any advice on that?
[13:14] <Chipaca> zyga: it depends on what was requested
[13:14] <zyga> snap refresh gnome-calculator core  # refreshing core in the background but failing the gnome-calculator refresh in a way that the user  sees
[13:14] <pedronis> we have various code that does similar things right now just with logs
[13:14] <pedronis> but has comments to move to warning
[13:15] <zyga> I see
[13:15] <Chipaca> zyga: if it's a bare 'snap refresh', I'd suggest to tell the user and update what can be done
[13:15] <zyga> should that be a warning?
[13:15] <zyga> Chipaca: tell via warning or is there another mechanism?
[13:15] <Chipaca> hold on
[13:15] <Chipaca> if it's "snap refresh foo bar baz", i'd say fail the whole thing
[13:16] <Chipaca> auto-refresh, use warnings
[13:16] <zyga> ok
[13:16] <zyga> I'll try that :)
[13:16] <pedronis> yes
[13:16] <Chipaca> that's three different things
[13:16] <zyga> but first, walk the dog
[13:16] <Chipaca> 'snap refresh': print message, update what's updatable
[13:16] <zyga> time is running quickly today
[13:16] <Chipaca> 'snap refresh foo bar baz' -> error
[13:16] <Chipaca> auto-refresh -> warning
[13:16] <zyga> Chipaca: print message -> warning, right?
[13:16] <zyga> or if not, how do I print?
[13:16] <Chipaca> zyga: no
[13:16] <zyga> logger or something smarter?
[13:17] <cachio> niemeyer, https://paste.ubuntu.com/p/B6KnsSfsxG/
[13:17] <cachio> niemeyer, same error
[13:17] <Chipaca> zyga: abuse the fact that the log of tasks get printed to the user?
[13:17] <Chipaca> not sure
[13:17] <cachio> compute.globalOperations.get permission
[13:17] <Chipaca> might need something adhoc
[13:17] <niemeyer> cachio: The image admin service now has that permission
[13:17] <zyga> haha, ok
[13:17] <zyga> Chipaca, pedronis: thank you, that is super useful
[13:17] <pedronis> Chipaca: we don't have good support for that case
[13:17] <niemeyer> cachio: I suspect something very similar to the issue we've observed last time is taking place
[13:18] <pedronis> Chipaca: inform but proceed
[13:18] <Chipaca> pedronis: zyga: we could use warnings for the inform-but-proceed but it'd suck a bit
[13:18] <pedronis> Chipaca: agreed
[13:18] <Chipaca> unless we tweaked refresh for this case
[13:18] <Chipaca> but if we're tweaking, we could tweak to jfdi
[13:18]  * pedronis quick errands
[13:18] <niemeyer> Oh my
[13:19] <niemeyer> And now GCE just did something silly and destroyed the role due to the lack of atomicity of their operations
[13:19] <niemeyer> ARGH
[13:20] <cachio> niemeyer, :(
[13:21] <niemeyer> Extremely frustrating
[13:21] <niemeyer> cachio: We'll need to recreate the role again from the ground up.. but I'll have lunch first
[13:21] <cachio> niemeyer, sure, np
[13:21] <cachio> thanks for helping
[13:43] <mup> PR snapcraft#2466 closed: ruby plugin: support new download URL <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2466>
[13:45] <pstolowski> cachio: i think our nested vm images will need updating and checking, i found out last week while working on hotplug tests that 16.04 image couldn't be found anymore; i'm using SPREAD_NESTED_SYSTEM=bionic with google-nested:ubuntu-18.04-64 which works but upgrades grub and some other packages on every run
[13:46] <cachio> pstolowski, thanks for the headsup
[13:47] <cachio> I'll do it ones the issue with gce account is fixed, I hope today
[13:47] <cachio> once
[13:51] <sil2100> mvo: should we revert the core18 change for /var/lib/jenkins then?
[13:51] <sil2100> mvo: I'm asking because I'd like to spin the first .2 core18 candidate images
[13:52] <sil2100> mvo: is it safe to use the current core18 + snapd 2.37.1?
[13:59] <mvo> sil2100: I think reverting adding /var/lib/jenkins is the right move
[14:02] <sil2100> mvo: let me do that then, I'll try to fast-track the new core18 to stable ASAP
[14:10] <mvo> sil2100: \o/
[14:24] <niemeyer> cachio: I've recreated the role.. can you please give it a shot when you have a moment?  I'll likely have missed something
[14:31] <cachio> niemeyer, hey, ready
[14:31] <cachio> niemeyer, do we need a new sa.json file?
[14:33] <pedronis> zyga: mvo: the two PRs I was mentioning were #6111 and #6410
[14:33] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[14:33] <mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
[14:35] <niemeyer> cachio: No, I've just lost the roles
[14:35] <niemeyer> cachio: Sorry, the permissions of the role actually
[14:35] <cachio> niemeyer, nice
[14:35] <cachio> niemeyer, I'll try again in that case
[14:35] <niemeyer> cachio: Google replaced the permissions instead of updating, due to some kind of error in the console
[14:35] <niemeyer> cachio: So I had to come up with the permissions again, which of course will likely be wrong
[14:36] <mvo> pedronis: ok
[14:36] <cachio> niemeyer, :(
[14:36] <cachio> niemeyer, I am running a task now
[14:36] <niemeyer> Thanks
[14:37] <cachio> I'll let you know if it goes well
[14:37] <pedronis> mvo: we also need to remove /var/lib/jenkins from core, right?
[14:38] <pedronis> mvo: can we though? will it break 2.37.1 using things?
[14:38] <mvo> pedronis: yeah, sil2100 is working on removing /var/lib/jenkins
[14:38] <pedronis> mvo: from core18, there is also core
[14:38] <mvo> pedronis: it should not break, we need to double check but its marked as "optional" in the snap-confine
[14:39] <mvo> pedronis: we need to double check if that "optional" checks both sides of the bind mount
[14:39] <pedronis> yes
[14:43] <pstolowski> cachio: hey, one question, is it possible to re-run individual beta validation tests with the scripts? or only manually without help of the scripts (SPREAD_EXTERNAL_ADDRESS=...) ?
[14:45] <pedronis> mvo: seems either side can be missing afaict
[14:47] <mvo> pedronis: ok, if thats the case we should be good by just removing it from the core snap with no ill effects
[14:52] <cachio> pstolowski, yes
[14:52] <cachio> pstolowski, SPREAD_TESTS=external:ubuntu-core-16-arm-64:tests/main/interfaces-hostname-control
[14:53] <cachio> will run just that test
[14:53] <cachio> pstolowski, SPREAD_TESTS=external:ubuntu-core-16-arm-64:tests/main/interfaces-hostname-control,external:ubuntu-core-16-arm-64:tests/main/snap-logs
[14:53] <cachio> will run both
[14:54] <cachio> pstolowski, it is possible to skip tests too with SKIP_TESTS=tests/main/revert-devmode
[15:01] <kjackal> Hey snappy people. I get a "Revision 410 is not approved." when trying to release microk8s on arm64. Why? How can I see what is wrong?
[15:04] <roadmr> kjackal: why - it's still pending automated review. what's wrong? nothing, you just need to wait a bit for it to finish review :)
[15:04] <kjackal> Ah, ok, where did you see that?
[15:04] <kjackal> (I was afraid i broke something in the builders)
[15:05] <roadmr> kjackal: in the dashboard.snapcraft.io page for microk8s; you'll notice (on the left side) that revision 410 has a clock next to it, indicating it's awaiting review
[15:05] <roadmr> kjackal: if you click on it, you'll see "automated review not yet completed" and "task xxxxxx awaiting execution"
[15:06] <kjackal> Ahh dashboard! I was only looking at the https://snapcraft.io/microk8s/releases
[15:06] <kjackal> thank you roadmr
[15:06] <Chipaca> pedronis: so, wrt macaroon expiry, indeed the refresh endpoint is ok and the download endpoint 401's
[15:06] <diddledan> another thing to remember (if I'm right) is that automated tests are sequentrial, so if you have two builds ready for testing they will be done one-at-a-time
[15:06] <diddledan> --r
[15:07] <roadmr> kjackal: np. Usually if something breaks we let you know about it; if you have no news, it usually means things are going well
[15:07] <kjackal> no news is good news!
[15:07] <diddledan> ... unless Trump has gone quiet :-o
[15:08] <roadmr> if you wish upon a star...
[15:12] <mvo> pedronis: I addressed the remodel feedback now
[15:19] <cachio> niemeyer, https://paste.ubuntu.com/p/mc3SttFRwv/
[15:19] <cachio> this permission is missing
[15:20] <niemeyer> cachio: Added
[15:20] <cachio> niemeyer, tx
[15:26] <pedronis> mvo: thanks, I will again
[15:26] <pedronis> Chipaca: ok,  can we do something only snapd side or do we need store changes?
[15:28] <mvo> ta
[15:33] <cachio> niemeyer, images are being created now
[15:33] <cachio> niemeyer, thanks for the support
[15:33] <niemeyer> cachio: Nice, phew
[15:50] <Chipaca> pedronis: there's nothing to tell snapd the macaroon is expired until suddenly download 401s
[15:50] <Chipaca> hmmm
[15:51] <Chipaca> pedronis: we could add code to just retry without the macaroon?
[15:51] <mup> PR snapd#6486 closed: interfaces/hotplug: renamed RequestedSlotSpec to ProposedSlot, removed Specification <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6486>
[15:52]  * Chipaca tries that
[15:53] <pstolowski> pedronis: #5962 updated
[15:53] <mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
[15:56] <vorlon> mwhudson, mvo: yes, cosmic-proposed version released now
[15:56] <pedronis> Chipaca: can't we know we don't need to send the macaroon upfront ? do we produce an error early if it's just "snap refresh one-snap"
[15:56]  * zyga waits for the final paperwork to go home from hospital
[15:57] <zyga> I may be back to work some more later tonight but I think I will really be back tomorrow, this is a good time as any to EOD
[15:58] <Chipaca> pedronis: wrt sending the macaroon, we can check private==false, and maybe there's code to check payment
[15:58] <Chipaca> not sure we have all the bits for the latter but we might
[15:58] <pedronis> Chipaca: there'a  Paid flag
[15:58] <Chipaca> pedronis: where?
[15:58] <pedronis> not sure if we keep around or not
[15:58] <pedronis> Chipaca: on Info for sure
[15:59] <Chipaca> pedronis: ah, details_v2 sets it from prices
[15:59] <Chipaca> ok
[15:59] <Chipaca> zyga: yeah, take family time
[16:00] <Chipaca> pedronis: is this what we want to do?
[16:00] <pedronis> Chipaca: possibly,  but best if to discuss this in Malta with the store?
[16:00] <pedronis> Chipaca: does the test I mentioned btw passes or fail (on staging) ?
[16:02] <Chipaca> pedronis: I don't know
[16:02] <pedronis> Chipaca: could you try it ?
[16:02] <mvo> vorlon: thank you, I will do a .2 soonish then
[16:02] <Chipaca> pedronis: I don't know :-)
[16:02] <Chipaca> pedronis: i don't know how to run spread against staging, do you know where that's documented / explained / described?
[16:02] <pedronis> mvo: will do the PR to remove /var/lib/jenkins from core
[16:03] <mvo> pedronis: thank you, please check with sil2100 to avoid duplication
[16:03] <pedronis> mvo: sorry
[16:03] <pedronis> mvo: I meant to ask will you do?
[16:03] <pedronis> Chipaca: not sure it's documented, cachio should be able to tell you
[16:04] <mvo> sil2100: hey, are you on the /var/lib/jenkins dir removal from core/core18 PR? asking because pedronis is keen to get rid of it and we want to avoid duplication of effort
[16:05] <Chipaca> cachio: hiya. I'd like to run a spread test against the staging store. How do I do that?
[16:06] <Chipaca> cachio: one of the ones that use SPREAD_STORE_USER and _PASSWORD
[16:06] <cachio> Chipaca, you need to check a PR?
[16:06] <Chipaca> cachio: master
[16:07] <cachio> Chipaca, we ran today against master
[16:07] <cachio> Chipaca, this is the log
[16:08] <cachio> Chipaca, https://travis-ci.org/snapcore/spread-cron/builds/491457033
[16:08] <Chipaca> pedronis: is system-files meant to be used to give you access to things in /sys?
[16:08] <Chipaca> cachio: thanks!
[16:08] <sil2100> mvo: I reverted the change in core18, I guess the packages are now in testing
[16:09] <cachio> Chipaca, this is the config we use to run it https://github.com/snapcore/spread-cron/blob/snapd-staging-store/run-checks
[16:09] <pedronis> Chipaca: in which sense?  it can be used for that, but a proper interface would be better
[16:09] <Chipaca> pedronis: https://forum.snapcraft.io/t/snap-manual-review/9923 sense
[16:10] <Chipaca> cachio: hmm
[16:10] <pedronis> Chipaca: that's gpio stuff, it should use the gpio interface
[16:11] <pedronis> unless they are trying to do something about more than one gpio
[16:11] <pedronis> but anyway, it's not a use case for system-files
[16:12] <sil2100> mvo: I mean, maybe I misunderstood, but is anything else required besides just reverting the dir-addition change? Do we have to somehow handle the removal on runtime? I don't think so, right?
[16:15] <mvo> sil2100: just reverting the change in core/core18 should be enough indeed
[16:15] <mvo> sil2100: sorry for the slow reply
[16:18] <Chipaca> cachio: and where do the users come from? in particular the stg-dummydev user, whoever that is
[16:18] <Chipaca> actually, pedronis ^ that user's only mentioned once in a change with your name on it
[16:19] <pedronis> Chipaca: the secrets, sorry I need to reload state on this
[16:24] <Chipaca> sergiusens: o/
[16:29] <mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
[16:29] <mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98
[16:30] <mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
[16:30] <mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98
[16:35] <pedronis> cachio: I reviewed #6320, small nitpick, I also changed the summary
[16:35] <mup> PR #6320: tests: pre-cache core on core18 systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6320>
[16:38] <cachio> pedronis, nice
[16:38] <cachio> I'll take a look no
[16:38] <cachio> w
[16:41] <cachio> pedronis, thanks for reviewing this, fix will be ready in 1 minutes
[16:45] <mup> PR snapd#6489 opened: tests: improve snaps-system-env test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6489>
[17:06] <mup> PR snapd#6490 opened: tests: fix NFS home mocking <Created by stolowski> <https://github.com/snapcore/snapd/pull/6490>
[17:15] <pstolowski> cachio: sorry, missed your erlier message. that's great, thanks! i'll propose a PR to add it to doc
[17:23] <oneguynick> 2/join #raspberrypoi
[17:23] <oneguynick> sorry
[17:23] <oneguynick> wireless keyboard is dying
[17:24] <cachio> pstolowski, nice
[17:24] <cachio> thanks
[17:26] <mup> PR snapd#6491 opened: interfaces: hotplug nested vm test, updated serial-port interface <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
[17:27] <pstolowski> np
[17:29] <pstolowski|afk> cachio: i've just proposed the test for hotplug based on nested vm ^
[17:30] <pstolowski|afk> cachio: since you split classic and core, we will need to have a separate one i suppose
[17:30] <pstolowski|afk> cachio: (for core)
[17:34] <cachio> pstolowski|afk, I'll take a look to that one
[17:40] <sil2100> cwayne: hey! I'd like to promote the current core18 ASAP once it passes automation, how are things looking so far?
[17:40] <sil2100> cwayne: I see some tests are still 'running', with some failures marked?
[17:41] <cwayne> We gave the +1 to the last one but it got overwritten
[17:41] <cwayne> Will take a look
[17:56] <mup> PR snapcraft#2467 opened: [legacy] ruby plugin: support new download URL (#2466) <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2467>
[17:57]  * zyga is home with the rest of the family now :)
[18:09]  * Chipaca EODs like a boss
[18:09]  * Chipaca looks at mvo
[18:09] <Chipaca> ok, like a different boss
[18:23] <sil2100> cwayne: I see the rpi3 tests are still running for core18, right?
[18:23] <cwayne> sil2100: yes
[18:23] <cwayne> You'll be the first to know when they're done
[18:25] <cwayne> sil2100: I think we need to refine this process a bit though, we've already given a bunch of +1s for snaps in beta that then got immediately overwritten
[18:26] <cwayne> IMHO a snap shouldn't really start this process unless it's meant to make it to stable
[18:26] <mup> PR core#101 opened: Revert "Merge pull request #100 from mvo5/add-jenkins-dirs" <Created by pedronis> <https://github.com/snapcore/core/pull/101>
[18:26] <pedronis> mvo: I went ahead and created this ^
[18:28] <sil2100> cwayne: yeah, even without rebuilding it on every new ubuntu-base tarball, the velocity is still too high, since basically if any seeded package changes it (by design) triggers a rebuild
[18:29] <sil2100> cwayne: I guess the base idea was that snaps in the pipeline would just stay in the pipeline and go forward
[18:29] <sil2100> cwayne: but then there's still the thing about bandwidth usage
[18:30] <sil2100> Of not-always-necessary constant updates
[18:30] <cwayne> Yeah
[18:31] <cwayne> IMHO it should be something like weekly + critical cves
[18:31] <mvo> pedronis: thank you
[20:09] <cwayne> sil2100: good to go
[20:41] <mup> PR snapcraft#2456 closed: plugins: add colcon plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2456>
[21:32] <mup> PR snapd#6320 closed: tests: pre-cache core on core18 systems <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6320>
[21:46] <mup> PR core#101 closed: Revert "Merge pull request #100 from mvo5/add-jenkins-dirs" <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/core/pull/101>
[21:53] <mup> PR snapd#6489 closed: tests: improve snaps-system-env test <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6489>
[22:05] <sil2100> cwayne: thanks!