[05:21] <mborzecki> morning
[06:12] <mup> PR snapd#7443 opened: timeutil: fix schedules with ambiguous nth weekday spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
[06:15] <mborzecki> pedronis: hey
[06:15] <mborzecki> gopkg is down?
[06:22] <pedronis> mborzecki: from spread tests? I haven't seen that, I have see lots of things timing out though
[06:23] <mborzecki> pedronis: the unit test travis job failed because of this in 7443, though it's green now after i restarted it
[07:05] <pstolowski> morning
[07:06] <mvo> hey pstolowski
[07:12] <mvo> zyga: any updates on the pi system that was problematic yesterday?
[07:12] <mvo> sil2100: if you have time a review for https://github.com/snapcore/core18/pull/139 would be great (should be simple)
[07:12] <mup> PR core18#139: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <https://github.com/snapcore/core18/pull/139>
[07:18] <zyga> Good morning
[07:18] <mvo> hey zyga !
[07:18] <zyga> Starting just now, sorry, today kids go to school at 8:45
[07:19] <zyga> mvo: the reporter promised to try rebooting and report back
[07:19] <zyga> So no update yet
[07:19] <mvo> zyga: I see no new bugreport from that system in the error tracker since ~2 days
[07:19] <mvo> zyga: no idea if thats good or bad though :/
[07:20] <zyga> I’ll reach out
[07:20] <zyga> Mvo we have another problem
[07:20] <zyga> Please check the mail from Jamie
[07:30] <mborzecki> anyoen feels like looking at https://github.com/snapcore/snapd/pull/7443 ?
[07:30] <mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
[07:31] <mborzecki> keep in mind, there be dragons
[07:47] <zyga> re
[07:48] <mup> PR snapd#7444 opened: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7444>
[07:48] <Chipaca> pedronis: ^
[07:51] <pedronis> Chipaca: thanks
[07:52] <Chipaca> pedronis: there's a bunch of things I'm itching to do to that code, but I've tried to leave it alone as much as possible :)
[07:55] <pedronis> Chipaca: were the tests in snapstate that you are removing still passing? in general in this cases I prefer to do that removal as a 2nd step
[07:56] <Chipaca> pedronis: some of them were failing
[07:56] <Chipaca> but I could've made them pass with some tweaks
[07:56] <Chipaca> pedronis: I can put them back, fix them, and then remove them
[07:56] <pedronis> Chipaca: would be better for reviewers I think
[07:57] <Chipaca> ok
[08:00] <pedronis> Chipaca: I also I recommend having different file per types already, because the PR that decides we need that will be weird and hard to review
[08:00] <pedronis> otherwise
[08:00] <Chipaca> hmm
[08:00] <Chipaca> pedronis: ok
[08:00] <pedronis> git will not help there, splitting a file in a lot of files
[08:01] <Chipaca> pedronis: should I close that, force-push with these changes?
[08:01] <pedronis> you can force push
[08:01] <Chipaca> k
[08:01] <pedronis> I'm just giving high level comments
[08:01] <pedronis> not really started reviewing in detail as such
[08:01] <zyga> heh
[08:02] <sil2100> mvo: sure thing!
[08:02] <zyga> remember our 3K diffs
[08:02] <zyga> check this out https://github.com/apple/swift/pull/20315/files
[08:02] <mup> PR apple/swift#20315: [String] Use a UTF-8 representation for native strings <Created by milseman> <Merged by milseman> <https://github.com/apple/swift/pull/20315>
[08:02] <zyga> hello sil2100
[08:02] <zyga> how are you
[08:02] <mup> PR snapd#7444 closed: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7444>
[08:03] <sil2100> zyga: hello o/ Still a bit tired, but not bad - how about you?
[08:03] <zyga> sil2100: enjoying the sun today, looking at landing some branches and finally doing a release for opensuse
[08:03] <zyga> sil2100: mvo sent a small patch yesterday, I pinged you about it
[08:04] <zyga> sil2100: can you look at it today please?
[08:05] <sil2100> zyga: yes, looking at it right now ;)
[08:06] <Chipaca> pedronis: WDYT of canremove_test?
[08:06] <mup> PR core18#139 closed: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/139>
[08:06] <Chipaca> pedronis: organisation wise i mean
[08:06] <zyga> thank you sil2100 :)
[08:07] <zyga> now we need a regression test
[08:07] <zyga> mvo: I think it'd be easier to write snapd side
[08:07] <zyga> mvo: we can run it in nightly suite
[08:07] <mvo> zyga: yeah
[08:07] <zyga> and ensure nightly is ran on all relases
[08:07] <zyga> mvo: we should write that down somewhere on release acceptance
[08:08] <pedronis> Chipaca: yes, I think organising tests by policy method makes sense
[08:09] <pedronis> we can always have <type>_test.go if there is really something very specific or helper to test
[08:09] <Chipaca> k
[08:32] <pedronis> #7416 needs reviews (it's big)
[08:32] <mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
[08:46] <mvo> Chipaca, pedronis 6404 is extremly confused in the cla check. it thinks it needs to check 196 emails and fails on a gazillion of them. I'm not sure its worth fixing the checker, I could create a new PR, point to the discussion of the old PR and get on with things? wdyt?
[08:46] <mvo> Chipaca: i.e. it looks like its not checking alternative emails in LP so it misses a lot of @canonical.com ones
[08:50] <Chipaca> pedronis: i broke 7444 so 7445 is up for your viewing pleasure
[08:51] <mup> PR snapd#6705 closed: bootloader: little kernel support <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6705>
[08:51] <mup> PR snapd#7445 opened: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>
[08:51] <Chipaca> mvo: ...?
[08:51] <Chipaca> mvo: let me see
[08:52] <Chipaca> ah, super old pr?
[08:52] <Chipaca> mvo: there's a small change I'd like to you to try first
[08:53] <mvo> Chipaca: ok
[08:54] <mup> PR snapd#7125 closed: snapstate: make progress reporting less granular <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7125>
[08:54] <zyga> mborzecki: re
[09:02] <Chipaca> whoops
[09:04] <zyga> ?
[09:05] <Chipaca> pushed code with for-debug panics
[09:06] <Chipaca> not entirely convinced the panics aren't actually properly deserved tho :)
[09:06] <Chipaca> but not right now
[09:13] <Chipaca> degville: did I understand correctly that you were looking into https://forum.snapcraft.io/t/trouble-installing-snapd-on-rhel-8/13140 ? or, who was?
[09:13]  * Chipaca has bad memory
[09:14] <degville> Chipaca: yes, that's the post I talked about yesterday. Although I've not had much luck. Our docs reference EPEL for 7, and things have changed slightly for 8.
[09:15] <Chipaca> degville: is the poster aware of your efforts?
[09:18] <degville> Chipaca: maybe - I responded on the RHEL install page on docs category.
[09:18] <degville> Chipaca: I had hoped it would be simply adding new instructions for the new repo config for EPEL, but that hasn't worked for me either.
[09:23] <mup> PR snapd#7446 opened: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>
[09:27] <zyga> rogpeppe: hello, did you have any luck rebooting your board?
[09:30] <rogpeppe> zyga: i'm waiting for someone to be around to power cycle when it fails to reboot
[09:30] <rogpeppe> zyga: actually, i'll just try it anyway
[09:30] <zyga> rogpeppe: understood, thank you so much for helping us understand this issue
[09:30] <zyga> rogpeppe: we've fixed missing fsck.vfat already, we're going to implement a test that verifies the filesystem is really checked and repaired automatically next
[09:32] <rogpeppe> zyga: ok, rebooting. keeping fingers crossed :)
[09:32] <zyga> mvo: ^ :)
[09:41] <zyga> rogpeppe: did it boot?
[09:42] <rogpeppe> zyga: yes!
[09:42] <zyga> excellent!!!
[09:42] <zyga> rogpeppe: can you now try to refresh core18 snap
[09:42] <zyga> it should be successful now
[09:43] <rogpeppe> zyga: i have to say i wasn't expecting that :)
[09:43] <zyga> and with some luck, it may unblock all refreshes
[09:43] <zyga> rogpeppe: thanks to the image you sent me I will investigate how uboot you have sees that
[09:44] <zyga> perhaps there's a discrepancy there
[09:44] <zyga> (and by "that", I mean the file that controls the boot process)
[09:44] <rogpeppe> zyga: ok, refreshed, waiting for reboot now. more crossed fingers. :)
[09:49] <rogpeppe> zyga: sadly it hasn't come back up after that
[09:49] <zyga> huh
[09:49] <zyga> huh
[09:49] <zyga> the plot thickens then
[09:50] <zyga> let's wait some more and in case nothing changes, reboot it manually
[09:50] <Chipaca> *clot
[09:50] <rogpeppe> zyga: for the record, this was what the snap refresh command printed: http://paste.ubuntu.com/p/fPdkPjxdwY/
[09:51] <zyga> once it recovers, let's look at "snap changes" and at journald
[09:54] <zyga> Chipaca: is it likely that core18 revision 1100 is corrupt but stays in cache?
[09:54] <zyga> Chipaca: and if so, is there a way we could verify that somehow from command line?
[09:55] <Chipaca> zyga: no, things are only moved if sha3 is ok
[09:55] <zyga> yes but if the card is corrputed
[09:55] <zyga> and the file on disk is just corrputed
[09:55] <zyga> is it going to be in cache after a failed refresh / reboot?
[09:55] <zyga> *corrupted
[09:56] <Chipaca> so, sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose
[09:56] <Chipaca> will print the sha3 of all snaps in the cache
[09:57] <Chipaca> by re-reading them i mean
[09:57] <zyga> mmm
[09:57] <zyga> rogpeppe: ^^
[10:00] <mup> PR snapd#7447 opened: snapstate: do not allow removal of the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7447>
[10:00] <Chipaca> now, the sha3 is also the filename
[10:00] <Chipaca> but because of Reasons, it's formatted differently :-|
[10:02] <mvo> Chipaca: \o/ for your cla check unshallow magic!
[10:03] <zyga> rogpeppe: did it recover after power-cycle?
[10:04] <rogpeppe> zyga: i'm waiting for my dad to see the email asking him to power cycle...
[10:04] <zyga> understood
[10:04] <zyga> I'll check if we can enable watchdog from the bootloader
[10:04] <zyga> so that things like that don't require intervention
[10:04] <rogpeppe> zyga: what do you mean by "watchdog" there?
[10:06] <Chipaca> mvo: :)
[10:06] <Chipaca> mvo: in store/cache.go, why is it using the hex digest instead of the EncodeDigest thing?
[10:07] <Chipaca> bah, i guess store/store.go is the one that actually uses one or t'other
[10:08] <mvo> Chipaca: I don't know why hex digest, sry
[10:08] <Chipaca> k
[10:08] <mvo> Chipaca: with the new unshallo I guess I can now remove the zyga@xenial-server from the whitelist, right?
[10:08] <pedronis> Chipaca: hex might slightly more filename friendly?
[10:09] <Chipaca> pedronis: a tiny bit, but the inconsistency bites
[10:09] <Chipaca> mvo: dunno. Maybe?
[10:09] <Chipaca> mvo: feel free to try :-)
[10:09] <mvo> Chipaca: will do
[10:09] <Chipaca> pedronis: bah, we could also make snap info print out both variants
[10:10] <Chipaca> feels messy tho
[10:10] <pedronis> that doesn't sound great
[10:10] <pedronis> info is messy enough as is
[10:11]  * Chipaca covers info's ears
[10:13] <Chipaca> pedronis: EncodeDigest is a base64 url encoding, so it should be fine for filenames
[10:13] <Chipaca> it's got _ and - and alphanum
[10:16] <Chipaca> i'll look into switching it sometime
[10:16] <rogpeppe> zyga: ok, looks like it was power-cycled. here's the snap changes output: http://paste.ubuntu.com/p/My5Cv4P443/
[10:18] <rogpeppe> zyga: for the record, it took two power cycles to come up again, as before
[10:19] <zyga> rogpeppe: there is one more angle
[10:19] <zyga> rogpeppe: we are testing two things at the same time
[10:20] <zyga> rogpeppe: if you recall, your kernel snap is refreshed and waiting to boot as well
[10:20] <zyga> rogpeppe: so it might be either of the two that cause issues
[10:20] <rogpeppe> zyga: i've emailed you the ouput of `journalctl --system`
[10:20] <zyga> I'm reading it now
[10:21] <pstolowski> mborzecki: funny bug that one with snap unset & unsupported core options you found... subtle bug in transaction.Changes()
[10:21] <mborzecki> pstolowski:  heh ;)
[10:23] <zyga> Sep 11 09:45:32 localhost snapd[690]: stateengine.go:150: state ensure error: devicemgr: snap "core18" has "refresh-snap" change in progress
[10:23] <zyga> Sep 11 10:09:25 localhost snapd[690]: handlers.go:460: Reported install problem for "core18" as 37ec03ba-d47c-11e9-a667-fa163e6cac46 OOPSID
[10:23] <zyga> mvo: ^ can you please look at that oops id?
[10:24] <Chipaca> zyga: can't you?
[10:24] <zyga> no
[10:24] <zyga> or if I do
[10:24] <zyga> I don't know I do
[10:24] <zyga> last time I only could look at the graph of errors
[10:24]  * zyga checks
[10:26] <zyga> Chipaca: perhaps I should ask, can you see those?
[10:26] <Chipaca> zyga: https://errors.ubuntu.com/oops/37ec03ba-d47c-11e9-a667-fa163e6cac46
[10:26] <Chipaca> zyga: you need to log in
[10:26] <mvo> zyga: looks the same as the last one, no more extra data
[10:26] <zyga> oh, I see that one
[10:26] <zyga> I tried https://errors.ubuntu.com/?problem/37ec03ba-d47c-11e9-a667-fa163e6cac46
[10:27] <mvo> zyga: I'm not even seeing the "has ... changes in progress" in the oops :(
[10:27] <zyga> mvo: that was in the journal
[10:27] <zyga> thank you for teaching me about the proper URL Chipaca
[10:27] <zyga> it's odd that there's "problem" and "oops" separately
[10:27] <Chipaca> ¯\_(ツ)_/¯
[10:27] <Chipaca> zyga: problems are aggregations
[10:27] <zyga> yeah, on second thought it does make sense
[10:27] <zyga> but ... uuid,
[10:27] <zyga> look up
[10:27] <zyga> anyway :D
[10:28] <Chipaca> zyga: at the bottom of every problem there's a list of oopses
[10:28] <Chipaca> oopsen
[10:28] <Chipaca> oopsi
[10:28]  * Chipaca hides
[10:28] <zyga> I'll check what the state engine message is about
[10:28] <zyga> oppsinen?
[10:28] <zyga> I prefer oopsi
[10:31] <zyga> rogpeppe: I think we need to think about what may be going on now
[10:32] <zyga> rogpeppe: I will gather more ideas from the team and see if any of those are worth experimenting at your inconvenience
[10:36] <mup> PR snapd#7448 opened: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
[10:36] <rogpeppe> zyga: thanks. let me know if you have any more ideas.
[10:37] <zyga> rogpeppe: thank you for working with us again, I'll try to replicate your setup locally to see if anything can be learned from this
[10:41] <zyga> pedronis: there's a question about snap create-user --force-managed on https://bugs.launchpad.net/snappy/+bug/1647256 that I'm not sure how to answer
[10:41] <mup> Bug #1647256: snap create-user cannot add a new user to an existing ubuntu core device <Snappy:New> <https://launchpad.net/bugs/1647256>
[10:57] <pedronis> zyga: put in my queue, I don't have an immediate answer
[11:00] <rogpeppe> zyga: FYI I just tried fsck.vfat again and it's all clean
[11:01] <zyga> rogpeppe: mmm, that's useful, so it's not corruption that is causing the problem
[11:01] <zyga> rogpeppe: can you check what Chipaca suggested above:
[11:02] <rogpeppe> zyga: what was that (I see quite a few messages from Chipaca)
[11:02] <rogpeppe> ?
[11:02]  * Chipaca is a chatterbox
[11:02] <zyga> one sec :)
[11:02] <Chipaca> so, sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose
[11:02] <Chipaca> rogpeppe: ^
[11:02] <zyga> sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose
[11:03] <rogpeppe> wow, snap info is really slow!
[11:05] <Chipaca> with verbose, it's doing some expensive stuff yes
[11:05] <rogpeppe> Chipaca, zyga: http://paste.ubuntu.com/p/vSpW6tmnJn/
[11:05] <Chipaca> ok, gimme a bit to check those
[11:06] <zyga> Chipaca: can I ask the dummy question of unifying the way the hash is printed
[11:06] <rogpeppe> Chipaca, zyga: FWIW, the info for the hydroctl service doesn't seem to be correct - it says that the hydroctl.hydroserver service is disabled/inactive, but it's definitely running currently
[11:06] <zyga> so that it is easier to eyeball-check
[11:06] <zyga> rogpeppe: oh, can you give us the output of systemctl status for that service unit?
[11:07] <zyga> rogpeppe: I think at some point it'd be good to report issues or we will be lost in the details
[11:07] <rogpeppe> zyga: as in `systemctl status hydroctl.hydroserver` ?
[11:07] <zyga> I think that it ought to be systemctl status snap.hydroctl.hydroserver.service
[11:08] <rogpeppe> zyga: ah, ok
[11:08] <zyga> snapd prepends "snap." to all units installed by snap packages
[11:08] <rogpeppe> zyga: http://paste.ubuntu.com/p/ntMd8jXMFg/
[11:09] <zyga> indeed, if snap service output disagrees, that's a bug!
[11:09] <zyga> can you collect that as well and report it via bugs.launchpad.net/snapd
[11:10] <zyga> Chipaca: can we look up snap revision for a blob for "snap info --verbose"?
[11:10] <rogpeppe> zyga: without truncated logs FWIW http://paste.ubuntu.com/p/rjxwqpvFM5/
[11:10] <zyga> thank you
[11:10] <rogpeppe> zyga: sorry, i'm not exactly sure what's the bug here
[11:10] <zyga> rogpeppe: disagreement, snap service should not misrepresent facts
[11:11] <rogpeppe> zyga: you mean "snap info", right?
[11:11] <Chipaca> zyga: rogpeppe all those hashes are coorect
[11:12] <zyga> Chipaca: thank you for checking that!
[11:13] <zyga> rogpeppe: perhaps I misunderstood, what did you mean when you said "FWIW, the info for the hydroctl service doesn't seem to be correct - it says that the hydroctl.hydroserver service is disabled/inactive, but it's definitely running currently"
[11:13] <zyga> how did you produce the information?
[11:13] <rogpeppe> zyga: which information?
[11:13] <zyga> information for hydroctl service
[11:14] <rogpeppe> zyga: it runs a web service that I can access
[11:14] <Chipaca> heh
[11:14] <zyga> aha
[11:14] <Chipaca> rogpeppe: sorry if that's confusing
[11:14] <Chipaca> you ran snap info on a file, not on an installed snap
[11:14] <Chipaca> it should not print that service info for files
[11:14] <Chipaca> i'll look into it
[11:15] <rogpeppe> Chipaca: ok, i see
[11:15] <Chipaca> rogpeppe: if you run snap info --verbose hydroctl, you should see the right status there
[11:16] <zyga> ah, I understand now
[11:16] <zyga> thank you Chipaca
[11:17] <rogpeppe> https://bugs.launchpad.net/snapd/+bug/1843567
[11:17] <mup> Bug #1843567: snap info reports incorrect service status <snapd:New> <https://launchpad.net/bugs/1843567>
[11:40] <mup> PR snapd#7449 opened: overlord/configstate: special-case json.RawMessage("null") in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>
[11:41] <Chipaca> niemeyer: is gopkg.in in trouble?
[11:41] <zyga> 70 PRs
[11:41] <zyga> time to stop
[11:41] <rogpeppe> Chipaca: looks ok to me
[11:42] <Chipaca> just got a string of failed tests because of 'Failed for "gopkg.in/retry.v1" (failed to clone repo)' because 'error: RPC failed; HTTP 502 curl 22 The requested URL returned error: 502'
[11:42] <Chipaca> eh, redoing
[11:44] <pstolowski> mborzecki: can you take a look at #7449?
[11:44] <mup> PR #7449: overlord/configstate: special-case "null" in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>
[11:44] <pstolowski> mborzecki: and i'm going to look at your schedule fix
[11:44] <zyga> pstolowski: I'm looking at that too
[11:45] <mborzecki> pstolowski: sure, looking
[11:50] <zyga> pstolowski: looking at your comment there
[11:50] <zyga> pstolowski: the decoder acts on the type you give, so if you give a map, you get a nil map
[11:50] <zyga> pstolowski: though one might discuss if "null" is a valid JSON representation of a map
[11:50] <zyga> pstolowski: I think, perhaps surprisingly so, that it is
[11:51] <pstolowski> zyga: yep, it's a bit ambigous
[11:51] <zyga> pstolowski: as a technicality, perhaps the len check could be merged into the original line, after err == nil
[11:51] <zyga> and the comment put up front, with slight rewording
[11:51] <zyga> so that it's reasier to read
[11:51] <zyga> I think again that the point is that the decoding is not unexpected
[11:52] <pstolowski> zyga: yes i had the len check merged but found it easier to read if the case is isolated with comment
[11:52] <pstolowski> ymmv
[11:52] <zyga> alternatively, it's the single condition, len > 0
[11:52] <zyga> as err is otherwise unused
[11:56] <zyga> uh
[11:56] <zyga> we have another thing to fix in master
[11:56] <zyga> 'debian-sid-64' now has support. Please update this test
[11:56] <zyga> this is from     - google:debian-sid-64:tests/main/system-usernames
[11:57] <pedronis> something for jdstrand
[11:57] <zyga> we should open a priority pull request to make address that
[12:03] <Chipaca> pedronis: in snapstate, any reason to load the yaml and look at type instead of using snapst.Type()? (afaik no but you're better at tracking this)
[12:04] <pedronis> Chipaca: depends where,  in some places we might not have set snapst type yet
[12:04] <pedronis> basically the one from the yaml might be safer to know it's there
[12:04] <Chipaca> pedronis: in places that call canRemove
[12:04] <Chipaca> :)
[12:05] <pedronis> should be safe, last famous words
[12:05] <Chipaca> :-)
[12:05] <mborzecki> off to pick up the kids
[12:05] <Chipaca> pedronis: i can always make it fall back to loading the yaml if unset
[12:06] <pedronis> might be easier to assume app if it's not
[12:06] <pedronis> for remove
[12:06] <pedronis> we might even have code like that anyway
[12:06] <pedronis> because remove should work even with broken snaps
[12:06] <pedronis> in theory
[12:06] <pedronis> or at least it should try
[12:06] <Chipaca> pedronis: fair
[12:07] <Chipaca> I'll be tweaking the code in a followup :-)
[12:07] <zyga> going through this slowly
[12:17] <Chipaca> ooh, i think i see a bug
[12:18]  * Chipaca kicks off a core18
[12:18] <sergiusens> Getting this error a lot since Monday, anyone else seeing something similar when running on spread/google? "- Start snap "lxd" (11824) services ([start snap.lxd.activate.service] failed with exit status 1: Job for snap.lxd.activate.service failed because the control process exited with error code."
[12:19] <Chipaca> sergiusens: what's in the journal when that happens?
[12:21] <sergiusens> Chipaca: I will have to add a "debug" stanza to see (I can only trigger the google provider through travis, me have no keys)
[12:22] <Chipaca> sergiusens: k
[12:22] <Chipaca> sergiusens: you should have a debug stanza, yes :-)
[12:22] <Chipaca> the logs of when things break can be quite valuable
[12:26] <sergiusens> Chipaca: does debug at the top level run fine (spread.yaml) or do I need debug-each (does that exists?)
[12:27] <Chipaca> sergiusens: debug at the toplevel should work fine
[12:27] <Chipaca> sergiusens: debug-each exists, indeed
[12:28] <sergiusens> ok, since this fails for the top level prepare I will add a debug, but just in case, will also add "debug-each"
[12:37] <pedronis> we had also this related to lxd.activate: https://forum.snapcraft.io/t/snapd-pegged-cpu-updates-never-completing-on-core/13142
[12:53] <Chipaca> pedronis: mvo: we have a bug where we'll take "core" to satisfy a "base: core16" snap, but not check in canRemove
[12:54] <pedronis> Chipaca: ok
[12:54] <sergiusens> Chipaca: "journalctl -xe" or more?
[12:55] <pedronis> Chipaca: I don't think is very urgent, just keep track of it somehow
[12:55] <Chipaca> sergiusens: probably enough for now (you'll add more as you go i guess?)
[12:55] <Chipaca> pedronis: i'm in the right place to fix it now tho
[12:55] <Chipaca> :)
[12:55] <Chipaca> but, sure
[12:55] <pedronis> Chipaca: if it's not too much extra lines/work
[12:57] <Chipaca> eep, 70 PRs :-|
[13:00] <zyga> Chipaca: and master being red
[13:00] <Chipaca> mmm, red
[13:04] <niemeyer> Chipaca: It's not in trouble but it's suffering.. there are spikes over the day that may put the machine over capacity for a moment
[13:04] <Chipaca> niemeyer: ack
[13:05] <niemeyer> Chipaca: We're already in the process of moving it inside Canonical DC
[13:09] <mup> PR snapd#7450 opened: tests: debian sid now ships new seccomp, adjust tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>
[13:09] <zyga> jdstrand: can you please look at https://github.com/snapcore/snapd/pull/7450 -- I must be missing something there
[13:09] <mup> PR #7450: tests: debian sid now ships new seccomp, adjust tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>
[13:15] <zyga> thank you, I'll check the other tests as well
[13:15] <zyga> I'll rewrite the commit message as well
[13:20] <zyga> jdstrand: fixed and pushed
[13:20] <jdstrand> thanks!
[13:21] <zyga> thank you for the urgent review :)
[13:26] <jdstrand_> np
[13:41] <zyga> mvo: we can always productively add _more_ PRs
[13:51] <mup> Bug #1843589 opened: core snap stuck refreshing <Snappy:New> <https://launchpad.net/bugs/1843589>
[13:52] <zyga> ugh, mvo, Chipaca ^^^^
[13:53] <Chipaca> yeah, reading
[13:53] <Chipaca> something's missing there though
[13:53] <Chipaca> bah, it's strange
[13:53] <zyga> stranger snaps
[13:57]  * zyga break for coffee and some rest 
[13:58] <mvo> hm, store is not a happy puppy right now - I just got 400 from a refresh on jq
[14:03] <Chipaca> mvo: 400?!
[14:03] <Chipaca> nice
[14:04] <mvo> yes
[14:07] <tomwardill> hello! store team again, store is having problems, refresh particuarly.
[14:09] <mup> PR snapcraft#2710 opened: Add setting to remove the "jar" option in the gradle command <Created by LyzardKing> <https://github.com/snapcore/snapcraft/pull/2710>
[14:15] <mup> PR snapd#7451 opened: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
[14:20]  * Chipaca takes a break
[14:21] <ijohnson> zyga: I reviewed #7435 for you, you should merge it while it's still green :-)
[14:21] <mup> PR #7435: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7435>
[14:21] <zyga> ijohnson: thank you
[14:21] <ijohnson> np you're welcome
[14:22] <mup> PR snapd#7435 closed: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7435>
[14:25] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7451#pullrequestreview-286825091
[14:25] <mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
[14:28] <sergiusens> mvo: pstolowski 3.8 is in stable, which has the snapcraft fix from edge tested to build the snapd snp
[14:28] <mvo> sergiusens: cool, thank you
[14:30] <mvo> niemeyer: we have a small spread PR for you, hopefully easy and quick to review https://github.com/snapcore/spread/pull/69 - it will help sergio because we hit the limit of a single page for the images :)
[14:30] <mup> PR spread#69: Manage pagination retrieving images from google backend <Ready> <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>
[14:32] <niemeyer> mvo: Nice, thanks!
[14:40] <joedborg> morning all, i'm trying to add some config options (i.e. snap get / set) to a snap.  am i right in saying that *all* of the logic for this is handled by snap/hooks/configure (including default options etc)?  I've seen `add-arg` in some over-ride builds
[14:41] <niemeyer> mvo: Isn't the pagination design/API a general feature of GCE?
[14:41] <niemeyer> mvo: In other words, will we be doing the same for every similar call?
[14:41] <niemeyer> mvo: If so, should we integrate the feature in the 'do' method instead?
[14:42] <niemeyer> mvo: I appreciate that in the original design the fiddling with the document is abstracted away: give a URL, obtain a Go value
[14:42] <niemeyer> mvo: This is moving that slightly up the chain
[14:43] <niemeyer> mvo: Maybe unavoidable, but worth considering at least
[14:44] <mvo> niemeyer: thanks, thats great feedback. if you don't mind I put it into the PR and will look into moving it into the proper place
[14:44] <zyga> joedborg: hello,yes, it's all doneby  the configure hook
[14:44] <zyga> it's all done
[14:44] <niemeyer> mvo: Of course, and sorry, should have mentioned there
[14:45] <joedborg> zyga: so there's no way for a user to see what args are available to be set?
[14:45] <joedborg> via the snap command i mean
[14:45] <mvo> niemeyer: thanks! I explore this and get back to you :)
[14:45] <zyga> joedborg: no, not at present, you can document that elsewhere in your snap but the system doesn't know about that yet
[14:45] <joedborg> zyga: thanks
[14:46] <zyga> joedborg: we were thinking about adding a schema to the configuration system but that work was de-prioritized for now
[14:46] <joedborg> zyga: yeah i can see pros and cons with allowing it all to be handled in the hook, i've just hit a con in this instance :)
[14:46] <joedborg> zyga: thanks for the help
[14:47] <zyga> good luck!
[14:48] <niemeyer> mvo: Thank you!
[14:50] <ijohnson> cachio, Chipaca: I've now seen the google:ubuntu-core-16-64:tests/main/catalog-update test fail a few times, hitting the loop limit (yesterday and Monday as well), is that test susecptible to store outages?
[14:51] <ijohnson> I realize there's some store stuff today with store outages, but not sure if we can/need to make that test more robust
[14:51] <ijohnson> see https://api.travis-ci.org/v3/job/583566210/log.txt for example
[14:51] <mup> PR snapcraft#2682 closed: tests: change default spread provider to lxd outside of travis <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2682>
[14:58] <zyga> ijohnson: I tried to improve the catalog-update test a while ago
[14:58] <zyga> let me pull the PR number
[14:59] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/6174/files
[14:59] <mup> PR #6174: many: add snap debug refresh-catalogs <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6174>
[15:00] <zyga> perhaps something to revisit?
[15:00] <ijohnson> zyga: yes I agree, we should revisit that I think
[15:05] <cachio> ijohnson, hey, do you have a log for that?
[15:05] <cachio> ijohnson, have a log
[15:06] <cachio> ijohnson, I'll try to reproduce it
[15:09] <zyga> cachio: what for?
[15:09] <zyga> it's a known issue, when store is under load
[15:09] <cachio> zyga, ah
[15:09] <cachio> ok
[15:10] <cachio> zyga, I thought it was something new
[15:11] <zyga> cachio: the catalog update test is know, I didn't check if there are other failures there
[15:11] <zyga> though now with store being partially up checking stuff is going to be painful
[15:14] <cachio> zyga, following the log I think it could be caused  by load in the server
[15:20] <mup> PR snapd#6174 opened: many: add snap debug refresh-catalogs <Created by zyga> <https://github.com/snapcore/snapd/pull/6174>
[15:20] <zyga> ^ needs love though
[15:29] <zyga> mvo: can I point your attention to https://github.com/snapcore/snapd/pull/7450 please
[15:30] <mup> PR #7450: tests: debian sid now ships new seccomp, adjust tests <Simple 😃> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>
[15:30] <ijohnson> cachio, zyga: yeah the log is above, and I think it's probably because the store was under load, but I've seen it fail in other circumstances as well with the same behavior
[15:30] <zyga> it's green in travis but shows up red in github
[15:31] <ijohnson> so I was just wondering what we can do about that test to either make it more clear why it's failing (i.e. store under load) or if it might be failing for some other reason
[15:31] <ijohnson> zyga: is that test waiting on the unstable status?
[15:31] <zyga> ah, perhaps that's the case
[15:31] <zyga> it's only pushed back once all tests are done
[15:31] <ijohnson> that would make sense
[15:31] <zyga> hopefully soon
[15:33] <mup> PR snapcraft#2711 opened: tests: print journal logs when spread tests fail <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2711>
[15:35] <zyga> finally
[15:35] <zyga> master should no longer always fail
[15:35] <zyga> it's back to roll-a-dice
[15:36] <mup> PR snapd#7450 closed: tests: debian sid now ships new seccomp, adjust tests <Simple 😃> <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7450>
[15:38]  * ijohnson goes and gets his lucky dice
[15:49] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/7449 is a bug fix so let's tag it as such
[15:49] <mup> PR #7449: overlord/configstate: special-case "null" in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>
[15:50] <zyga> pstolowski: if you want you can also report a bug number on lauchpad for some stats but I won't push you for that :)
[15:53] <pstolowski> zyga: sure about tagging, i didn't know we do that
[15:55] <zyga> pstolowski: I think it helps to prioritize reviews in some way
[15:56] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7446 please
[15:56] <mup> PR #7446: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>
[15:56] <zyga> it's rather simple and close to unblocking another PR
[15:56] <zyga> which will in turn unblock a few more
[15:56] <pstolowski> zyga: no disagreement, +1
[16:05] <zyga> ijohnson: can you look at https://github.com/snapcore/snapd/pull/7448 -- just at the rationale of the change
[16:05] <mup> PR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
[16:06] <zyga> the actual "diff" is one liner here https://github.com/snapcore/snapd/pull/7448/files#diff-36e872aea1fc7dba34c7dfa820f13ac0R108 that effectively overrides the default and hides .mount_id .parent_id
[16:26]  * cachio lunch
[16:27] <sergiusens> zyga: hey, how do I reset connections? I removed a couple of interfaces and snap connections is still showing them after removing and reinstalling the snap
[16:28] <zyga> I believe right now there is no user-facing way
[16:28] <zyga> you'd have to edit the state
[16:28] <zyga> cc mborzecki for ideas
[16:28] <zyga> I think we discussed having something to do it
[16:35]  * zyga switched to passive mode
[17:15] <pedronis> we have some ideas in that area (also related to hotplug), but not implemented yet
[17:55] <ijohnson> zyga: yes I had that on my list of things to review for you
[18:12] <zyga> ijohnson: thank you so much!
[18:14] <mup> PR snapcraft#2712 opened: snap: migrate to core18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2712>
[18:47] <mup> PR snapd#7109 closed: snap-confine: fallback gracefully on a cgroup v2 only system <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7109>
[19:05] <mup> PR snapcraft#2711 closed: tests: print journal logs when spread tests fail <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2711>
[19:30] <mup> PR snapd#7452 opened: tests/classic-ubuntu-core-transition*: move to nightly <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7452>
[20:28] <mup> PR snapd#7453 opened: tests/classic-custom-device-reg: disable on opensuse-15 and fedora-30 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7453>