/srv/irclogs.ubuntu.com/2019/09/11/#snappy.txt

mborzeckimorning05:21
mupPR snapd#7443 opened: timeutil: fix schedules with ambiguous nth weekday spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>06:12
mborzeckipedronis: hey06:15
mborzeckigopkg is down?06:15
pedronismborzecki: from spread tests? I haven't seen that, I have see lots of things timing out though06:22
mborzeckipedronis: the unit test travis job failed because of this in 7443, though it's green now after i restarted it06:23
pstolowskimorning07:05
mvohey pstolowski07:06
mvozyga: any updates on the pi system that was problematic yesterday?07:12
mvosil2100: if you have time a review for https://github.com/snapcore/core18/pull/139 would be great (should be simple)07:12
mupPR core18#139: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <https://github.com/snapcore/core18/pull/139>07:12
zygaGood morning07:18
mvohey zyga !07:18
zygaStarting just now, sorry, today kids go to school at 8:4507:18
zygamvo: the reporter promised to try rebooting and report back07:19
zygaSo no update yet07:19
mvozyga: I see no new bugreport from that system in the error tracker since ~2 days07:19
mvozyga: no idea if thats good or bad though :/07:19
zygaI’ll reach out07:20
zygaMvo we have another problem07:20
zygaPlease check the mail from Jamie07:20
mborzeckianyoen feels like looking at https://github.com/snapcore/snapd/pull/7443 ?07:30
mupPR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>07:30
mborzeckikeep in mind, there be dragons07:31
zygare07:47
mupPR 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
Chipacapedronis: ^07:48
pedronisChipaca: thanks07:51
Chipacapedronis: 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:52
pedronisChipaca: 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 step07:55
Chipacapedronis: some of them were failing07:56
Chipacabut I could've made them pass with some tweaks07:56
Chipacapedronis: I can put them back, fix them, and then remove them07:56
pedronisChipaca: would be better for reviewers I think07:56
Chipacaok07:57
pedronisChipaca: I also I recommend having different file per types already, because the PR that decides we need that will be weird and hard to review08:00
pedronisotherwise08:00
Chipacahmm08:00
Chipacapedronis: ok08:00
pedronisgit will not help there, splitting a file in a lot of files08:00
Chipacapedronis: should I close that, force-push with these changes?08:01
pedronisyou can force push08:01
Chipacak08:01
pedronisI'm just giving high level comments08:01
pedronisnot really started reviewing in detail as such08:01
zygaheh08:01
sil2100mvo: sure thing!08:02
zygaremember our 3K diffs08:02
zygacheck this out https://github.com/apple/swift/pull/20315/files08:02
mupPR 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
zygahello sil210008:02
zygahow are you08:02
mupPR 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:02
sil2100zyga: hello o/ Still a bit tired, but not bad - how about you?08:03
zygasil2100: enjoying the sun today, looking at landing some branches and finally doing a release for opensuse08:03
zygasil2100: mvo sent a small patch yesterday, I pinged you about it08:03
zygasil2100: can you look at it today please?08:04
sil2100zyga: yes, looking at it right now ;)08:05
Chipacapedronis: WDYT of canremove_test?08:06
mupPR 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
Chipacapedronis: organisation wise i mean08:06
zygathank you sil2100 :)08:06
zyganow we need a regression test08:07
zygamvo: I think it'd be easier to write snapd side08:07
zygamvo: we can run it in nightly suite08:07
mvozyga: yeah08:07
zygaand ensure nightly is ran on all relases08:07
zygamvo: we should write that down somewhere on release acceptance08:07
pedronisChipaca: yes, I think organising tests by policy method makes sense08:08
pedroniswe can always have <type>_test.go if there is really something very specific or helper to test08:09
Chipacak08:09
pedronis#7416 needs reviews (it's big)08:32
mupPR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>08:32
mvoChipaca, 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
mvoChipaca: i.e. it looks like its not checking alternative emails in LP so it misses a lot of @canonical.com ones08:46
Chipacapedronis: i broke 7444 so 7445 is up for your viewing pleasure08:50
mupPR snapd#6705 closed: bootloader: little kernel support <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6705>08:51
mupPR 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
Chipacamvo: ...?08:51
Chipacamvo: let me see08:51
Chipacaah, super old pr?08:52
Chipacamvo: there's a small change I'd like to you to try first08:52
mvoChipaca: ok08:53
mupPR snapd#7125 closed: snapstate: make progress reporting less granular <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7125>08:54
zygamborzecki: re08:54
Chipacawhoops09:02
zyga?09:04
Chipacapushed code with for-debug panics09:05
Chipacanot entirely convinced the panics aren't actually properly deserved tho :)09:06
Chipacabut not right now09:06
Chipacadegville: 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 memory09:13
degvilleChipaca: 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:14
Chipacadegville: is the poster aware of your efforts?09:15
degvilleChipaca: maybe - I responded on the RHEL install page on docs category.09:18
degvilleChipaca: 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:18
=== JanC_ is now known as JanC
mupPR snapd#7446 opened: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>09:23
zygarogpeppe: hello, did you have any luck rebooting your board?09:27
rogpeppezyga: i'm waiting for someone to be around to power cycle when it fails to reboot09:30
rogpeppezyga: actually, i'll just try it anyway09:30
zygarogpeppe: understood, thank you so much for helping us understand this issue09:30
zygarogpeppe: we've fixed missing fsck.vfat already, we're going to implement a test that verifies the filesystem is really checked and repaired automatically next09:30
rogpeppezyga: ok, rebooting. keeping fingers crossed :)09:32
zygamvo: ^ :)09:32
zygarogpeppe: did it boot?09:41
rogpeppezyga: yes!09:42
zygaexcellent!!!09:42
zygarogpeppe: can you now try to refresh core18 snap09:42
zygait should be successful now09:42
rogpeppezyga: i have to say i wasn't expecting that :)09:43
zygaand with some luck, it may unblock all refreshes09:43
zygarogpeppe: thanks to the image you sent me I will investigate how uboot you have sees that09:43
zygaperhaps there's a discrepancy there09:44
zyga(and by "that", I mean the file that controls the boot process)09:44
rogpeppezyga: ok, refreshed, waiting for reboot now. more crossed fingers. :)09:44
rogpeppezyga: sadly it hasn't come back up after that09:49
zygahuh09:49
zygahuh09:49
zygathe plot thickens then09:49
zygalet's wait some more and in case nothing changes, reboot it manually09:50
Chipaca*clot09:50
rogpeppezyga: for the record, this was what the snap refresh command printed: http://paste.ubuntu.com/p/fPdkPjxdwY/09:50
zygaonce it recovers, let's look at "snap changes" and at journald09:51
zygaChipaca: is it likely that core18 revision 1100 is corrupt but stays in cache?09:54
zygaChipaca: and if so, is there a way we could verify that somehow from command line?09:54
Chipacazyga: no, things are only moved if sha3 is ok09:55
zygayes but if the card is corrputed09:55
zygaand the file on disk is just corrputed09:55
zygais it going to be in cache after a failed refresh / reboot?09:55
zyga*corrupted09:55
Chipacaso, sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose09:56
Chipacawill print the sha3 of all snaps in the cache09:56
Chipacaby re-reading them i mean09:57
zygammm09:57
zygarogpeppe: ^^09:57
mupPR snapd#7447 opened: snapstate: do not allow removal of the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7447>10:00
Chipacanow, the sha3 is also the filename10:00
Chipacabut because of Reasons, it's formatted differently :-|10:00
mvoChipaca: \o/ for your cla check unshallow magic!10:02
zygarogpeppe: did it recover after power-cycle?10:03
rogpeppezyga: i'm waiting for my dad to see the email asking him to power cycle...10:04
zygaunderstood10:04
zygaI'll check if we can enable watchdog from the bootloader10:04
zygaso that things like that don't require intervention10:04
rogpeppezyga: what do you mean by "watchdog" there?10:04
Chipacamvo: :)10:06
Chipacamvo: in store/cache.go, why is it using the hex digest instead of the EncodeDigest thing?10:06
Chipacabah, i guess store/store.go is the one that actually uses one or t'other10:07
mvoChipaca: I don't know why hex digest, sry10:08
Chipacak10:08
mvoChipaca: with the new unshallo I guess I can now remove the zyga@xenial-server from the whitelist, right?10:08
pedronisChipaca: hex might slightly more filename friendly?10:08
Chipacapedronis: a tiny bit, but the inconsistency bites10:09
Chipacamvo: dunno. Maybe?10:09
Chipacamvo: feel free to try :-)10:09
mvoChipaca: will do10:09
Chipacapedronis: bah, we could also make snap info print out both variants10:09
Chipacafeels messy tho10:10
pedronisthat doesn't sound great10:10
pedronisinfo is messy enough as is10:10
* Chipaca covers info's ears10:11
Chipacapedronis: EncodeDigest is a base64 url encoding, so it should be fine for filenames10:13
Chipacait's got _ and - and alphanum10:13
Chipacai'll look into switching it sometime10:16
rogpeppezyga: ok, looks like it was power-cycled. here's the snap changes output: http://paste.ubuntu.com/p/My5Cv4P443/10:16
rogpeppezyga: for the record, it took two power cycles to come up again, as before10:18
zygarogpeppe: there is one more angle10:19
zygarogpeppe: we are testing two things at the same time10:19
zygarogpeppe: if you recall, your kernel snap is refreshed and waiting to boot as well10:20
zygarogpeppe: so it might be either of the two that cause issues10:20
rogpeppezyga: i've emailed you the ouput of `journalctl --system`10:20
zygaI'm reading it now10:20
pstolowskimborzecki: funny bug that one with snap unset & unsupported core options you found... subtle bug in transaction.Changes()10:21
mborzeckipstolowski:  heh ;)10:21
zygaSep 11 09:45:32 localhost snapd[690]: stateengine.go:150: state ensure error: devicemgr: snap "core18" has "refresh-snap" change in progress10:23
zygaSep 11 10:09:25 localhost snapd[690]: handlers.go:460: Reported install problem for "core18" as 37ec03ba-d47c-11e9-a667-fa163e6cac46 OOPSID10:23
zygamvo: ^ can you please look at that oops id?10:23
Chipacazyga: can't you?10:24
zygano10:24
zygaor if I do10:24
zygaI don't know I do10:24
zygalast time I only could look at the graph of errors10:24
* zyga checks10:24
zygaChipaca: perhaps I should ask, can you see those?10:26
Chipacazyga: https://errors.ubuntu.com/oops/37ec03ba-d47c-11e9-a667-fa163e6cac4610:26
Chipacazyga: you need to log in10:26
mvozyga: looks the same as the last one, no more extra data10:26
zygaoh, I see that one10:26
zygaI tried https://errors.ubuntu.com/?problem/37ec03ba-d47c-11e9-a667-fa163e6cac4610:26
mvozyga: I'm not even seeing the "has ... changes in progress" in the oops :(10:27
zygamvo: that was in the journal10:27
zygathank you for teaching me about the proper URL Chipaca10:27
zygait's odd that there's "problem" and "oops" separately10:27
Chipaca¯\_(ツ)_/¯10:27
Chipacazyga: problems are aggregations10:27
zygayeah, on second thought it does make sense10:27
zygabut ... uuid,10:27
zygalook up10:27
zygaanyway :D10:27
Chipacazyga: at the bottom of every problem there's a list of oopses10:28
Chipacaoopsen10:28
Chipacaoopsi10:28
* Chipaca hides10:28
zygaI'll check what the state engine message is about10:28
zygaoppsinen?10:28
zygaI prefer oopsi10:28
zygarogpeppe: I think we need to think about what may be going on now10:31
zygarogpeppe: I will gather more ideas from the team and see if any of those are worth experimenting at your inconvenience10:32
mupPR 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
rogpeppezyga: thanks. let me know if you have any more ideas.10:36
zygarogpeppe: thank you for working with us again, I'll try to replicate your setup locally to see if anything can be learned from this10:37
zygapedronis: 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 answer10:41
mupBug #1647256: snap create-user cannot add a new user to an existing ubuntu core device <Snappy:New> <https://launchpad.net/bugs/1647256>10:41
pedroniszyga: put in my queue, I don't have an immediate answer10:57
rogpeppezyga: FYI I just tried fsck.vfat again and it's all clean11:00
zygarogpeppe: mmm, that's useful, so it's not corruption that is causing the problem11:01
zygarogpeppe: can you check what Chipaca suggested above:11:01
rogpeppezyga: what was that (I see quite a few messages from Chipaca)11:02
rogpeppe?11:02
* Chipaca is a chatterbox11:02
zygaone sec :)11:02
Chipacaso, sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose11:02
Chipacarogpeppe: ^11:02
zygasudo find /var/lib/snapd/cache | xargs sudo snap info --verbose11:02
rogpeppewow, snap info is really slow!11:03
Chipacawith verbose, it's doing some expensive stuff yes11:05
rogpeppeChipaca, zyga: http://paste.ubuntu.com/p/vSpW6tmnJn/11:05
Chipacaok, gimme a bit to check those11:05
zygaChipaca: can I ask the dummy question of unifying the way the hash is printed11:06
rogpeppeChipaca, 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 currently11:06
zygaso that it is easier to eyeball-check11:06
zygarogpeppe: oh, can you give us the output of systemctl status for that service unit?11:06
zygarogpeppe: I think at some point it'd be good to report issues or we will be lost in the details11:07
rogpeppezyga: as in `systemctl status hydroctl.hydroserver` ?11:07
zygaI think that it ought to be systemctl status snap.hydroctl.hydroserver.service11:07
rogpeppezyga: ah, ok11:08
zygasnapd prepends "snap." to all units installed by snap packages11:08
rogpeppezyga: http://paste.ubuntu.com/p/ntMd8jXMFg/11:08
zygaindeed, if snap service output disagrees, that's a bug!11:09
zygacan you collect that as well and report it via bugs.launchpad.net/snapd11:09
zygaChipaca: can we look up snap revision for a blob for "snap info --verbose"?11:10
rogpeppezyga: without truncated logs FWIW http://paste.ubuntu.com/p/rjxwqpvFM5/11:10
zygathank you11:10
rogpeppezyga: sorry, i'm not exactly sure what's the bug here11:10
zygarogpeppe: disagreement, snap service should not misrepresent facts11:10
rogpeppezyga: you mean "snap info", right?11:11
Chipacazyga: rogpeppe all those hashes are coorect11:11
zygaChipaca: thank you for checking that!11:12
zygarogpeppe: 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
zygahow did you produce the information?11:13
rogpeppezyga: which information?11:13
zygainformation for hydroctl service11:13
rogpeppezyga: it runs a web service that I can access11:14
Chipacaheh11:14
zygaaha11:14
Chipacarogpeppe: sorry if that's confusing11:14
Chipacayou ran snap info on a file, not on an installed snap11:14
Chipacait should not print that service info for files11:14
Chipacai'll look into it11:14
rogpeppeChipaca: ok, i see11:15
Chipacarogpeppe: if you run snap info --verbose hydroctl, you should see the right status there11:15
zygaah, I understand now11:16
zygathank you Chipaca11:16
rogpeppehttps://bugs.launchpad.net/snapd/+bug/184356711:17
mupBug #1843567: snap info reports incorrect service status <snapd:New> <https://launchpad.net/bugs/1843567>11:17
=== pedronis_ is now known as pedronis
=== ricab is now known as ricab|lunch
mupPR snapd#7449 opened: overlord/configstate: special-case json.RawMessage("null") in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>11:40
Chipacaniemeyer: is gopkg.in in trouble?11:41
zyga70 PRs11:41
zygatime to stop11:41
rogpeppeChipaca: looks ok to me11:41
Chipacajust 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
Chipacaeh, redoing11:42
pstolowskimborzecki: can you take a look at #7449?11:44
mupPR #7449: overlord/configstate: special-case "null" in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>11:44
pstolowskimborzecki: and i'm going to look at your schedule fix11:44
zygapstolowski: I'm looking at that too11:44
mborzeckipstolowski: sure, looking11:45
zygapstolowski: looking at your comment there11:50
zygapstolowski: the decoder acts on the type you give, so if you give a map, you get a nil map11:50
zygapstolowski: though one might discuss if "null" is a valid JSON representation of a map11:50
zygapstolowski: I think, perhaps surprisingly so, that it is11:50
pstolowskizyga: yep, it's a bit ambigous11:51
zygapstolowski: as a technicality, perhaps the len check could be merged into the original line, after err == nil11:51
zygaand the comment put up front, with slight rewording11:51
zygaso that it's reasier to read11:51
zygaI think again that the point is that the decoding is not unexpected11:51
pstolowskizyga: yes i had the len check merged but found it easier to read if the case is isolated with comment11:52
pstolowskiymmv11:52
zygaalternatively, it's the single condition, len > 011:52
zygaas err is otherwise unused11:52
zygauh11:56
zygawe have another thing to fix in master11:56
zyga'debian-sid-64' now has support. Please update this test11:56
zygathis is from     - google:debian-sid-64:tests/main/system-usernames11:56
pedronissomething for jdstrand11:57
zygawe should open a priority pull request to make address that11:57
Chipacapedronis: 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:03
pedronisChipaca: depends where,  in some places we might not have set snapst type yet12:04
pedronisbasically the one from the yaml might be safer to know it's there12:04
Chipacapedronis: in places that call canRemove12:04
Chipaca:)12:04
pedronisshould be safe, last famous words12:05
Chipaca:-)12:05
mborzeckioff to pick up the kids12:05
Chipacapedronis: i can always make it fall back to loading the yaml if unset12:05
pedronismight be easier to assume app if it's not12:06
pedronisfor remove12:06
pedroniswe might even have code like that anyway12:06
pedronisbecause remove should work even with broken snaps12:06
pedronisin theory12:06
pedronisor at least it should try12:06
Chipacapedronis: fair12:06
ChipacaI'll be tweaking the code in a followup :-)12:07
zygagoing through this slowly12:07
Chipacaooh, i think i see a bug12:17
* Chipaca kicks off a core1812:18
sergiusensGetting 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:18
Chipacasergiusens: what's in the journal when that happens?12:19
sergiusensChipaca: I will have to add a "debug" stanza to see (I can only trigger the google provider through travis, me have no keys)12:21
Chipacasergiusens: k12:22
Chipacasergiusens: you should have a debug stanza, yes :-)12:22
Chipacathe logs of when things break can be quite valuable12:22
sergiusensChipaca: does debug at the top level run fine (spread.yaml) or do I need debug-each (does that exists?)12:26
Chipacasergiusens: debug at the toplevel should work fine12:27
Chipacasergiusens: debug-each exists, indeed12:27
sergiusensok, since this fails for the top level prepare I will add a debug, but just in case, will also add "debug-each"12:28
pedroniswe had also this related to lxd.activate: https://forum.snapcraft.io/t/snapd-pegged-cpu-updates-never-completing-on-core/1314212:37
=== ricab|lunch is now known as ricab
Chipacapedronis: mvo: we have a bug where we'll take "core" to satisfy a "base: core16" snap, but not check in canRemove12:53
pedronisChipaca: ok12:54
sergiusensChipaca: "journalctl -xe" or more?12:54
pedronisChipaca: I don't think is very urgent, just keep track of it somehow12:55
Chipacasergiusens: probably enough for now (you'll add more as you go i guess?)12:55
Chipacapedronis: i'm in the right place to fix it now tho12:55
Chipaca:)12:55
Chipacabut, sure12:55
pedronisChipaca: if it's not too much extra lines/work12:55
Chipacaeep, 70 PRs :-|12:57
zygaChipaca: and master being red13:00
Chipacammm, red13:00
niemeyerChipaca: It's not in trouble but it's suffering.. there are spikes over the day that may put the machine over capacity for a moment13:04
Chipacaniemeyer: ack13:04
niemeyerChipaca: We're already in the process of moving it inside Canonical DC13:05
mupPR snapd#7450 opened: tests: debian sid now ships new seccomp, adjust tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>13:09
zygajdstrand: can you please look at https://github.com/snapcore/snapd/pull/7450 -- I must be missing something there13:09
mupPR #7450: tests: debian sid now ships new seccomp, adjust tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>13:09
zygathank you, I'll check the other tests as well13:15
zygaI'll rewrite the commit message as well13:15
zygajdstrand: fixed and pushed13:20
jdstrandthanks!13:20
zygathank you for the urgent review :)13:21
jdstrand_np13:26
=== jdstrand_ is now known as jdstrand
zygamvo: we can always productively add _more_ PRs13:41
mupBug #1843589 opened: core snap stuck refreshing <Snappy:New> <https://launchpad.net/bugs/1843589>13:51
zygaugh, mvo, Chipaca ^^^^13:52
Chipacayeah, reading13:53
Chipacasomething's missing there though13:53
Chipacabah, it's strange13:53
zygastranger snaps13:53
* zyga break for coffee and some rest 13:57
mvohm, store is not a happy puppy right now - I just got 400 from a refresh on jq13:58
Chipacamvo: 400?!14:03
Chipacanice14:03
mvoyes14:04
tomwardillhello! store team again, store is having problems, refresh particuarly.14:07
mupPR 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:09
mupPR snapd#7451 opened: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>14:15
* Chipaca takes a break14:20
ijohnsonzyga: I reviewed #7435 for you, you should merge it while it's still green :-)14:21
mupPR #7435: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7435>14:21
zygaijohnson: thank you14:21
ijohnsonnp you're welcome14:21
mupPR 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:22
zygamborzecki: https://github.com/snapcore/snapd/pull/7451#pullrequestreview-28682509114:25
mupPR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>14:25
sergiusensmvo: pstolowski 3.8 is in stable, which has the snapcraft fix from edge tested to build the snapd snp14:28
mvosergiusens: cool, thank you14:28
mvoniemeyer: 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
mupPR spread#69: Manage pagination retrieving images from google backend <Ready> <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>14:30
niemeyermvo: Nice, thanks!14:32
joedborgmorning 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 builds14:40
niemeyermvo: Isn't the pagination design/API a general feature of GCE?14:41
niemeyermvo: In other words, will we be doing the same for every similar call?14:41
niemeyermvo: If so, should we integrate the feature in the 'do' method instead?14:41
niemeyermvo: I appreciate that in the original design the fiddling with the document is abstracted away: give a URL, obtain a Go value14:42
niemeyermvo: This is moving that slightly up the chain14:42
niemeyermvo: Maybe unavoidable, but worth considering at least14:43
mvoniemeyer: thanks, thats great feedback. if you don't mind I put it into the PR and will look into moving it into the proper place14:44
zygajoedborg: hello,yes, it's all doneby  the configure hook14:44
zygait's all done14:44
niemeyermvo: Of course, and sorry, should have mentioned there14:44
joedborgzyga: so there's no way for a user to see what args are available to be set?14:45
joedborgvia the snap command i mean14:45
mvoniemeyer: thanks! I explore this and get back to you :)14:45
zygajoedborg: no, not at present, you can document that elsewhere in your snap but the system doesn't know about that yet14:45
joedborgzyga: thanks14:45
zygajoedborg: we were thinking about adding a schema to the configuration system but that work was de-prioritized for now14:46
joedborgzyga: 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
joedborgzyga: thanks for the help14:46
zygagood luck!14:47
niemeyermvo: Thank you!14:48
ijohnsoncachio, 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:50
ijohnsonI realize there's some store stuff today with store outages, but not sure if we can/need to make that test more robust14:51
ijohnsonsee https://api.travis-ci.org/v3/job/583566210/log.txt for example14:51
mupPR 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:51
zygaijohnson: I tried to improve the catalog-update test a while ago14:58
zygalet me pull the PR number14:58
zygaijohnson: https://github.com/snapcore/snapd/pull/6174/files14:59
mupPR #6174: many: add snap debug refresh-catalogs <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6174>14:59
zygaperhaps something to revisit?15:00
ijohnsonzyga: yes I agree, we should revisit that I think15:00
cachioijohnson, hey, do you have a log for that?15:05
cachioijohnson, have a log15:05
cachioijohnson, I'll try to reproduce it15:06
zygacachio: what for?15:09
zygait's a known issue, when store is under load15:09
cachiozyga, ah15:09
cachiook15:09
cachiozyga, I thought it was something new15:10
zygacachio: the catalog update test is know, I didn't check if there are other failures there15:11
zygathough now with store being partially up checking stuff is going to be painful15:11
cachiozyga, following the log I think it could be caused  by load in the server15:14
mupPR snapd#6174 opened: many: add snap debug refresh-catalogs <Created by zyga> <https://github.com/snapcore/snapd/pull/6174>15:20
zyga^ needs love though15:20
zygamvo: can I point your attention to https://github.com/snapcore/snapd/pull/7450 please15:29
mupPR #7450: tests: debian sid now ships new seccomp, adjust tests <Simple 😃> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>15:30
ijohnsoncachio, 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 behavior15:30
zygait's green in travis but shows up red in github15:30
ijohnsonso 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 reason15:31
ijohnsonzyga: is that test waiting on the unstable status?15:31
zygaah, perhaps that's the case15:31
zygait's only pushed back once all tests are done15:31
ijohnsonthat would make sense15:31
zygahopefully soon15:31
mupPR snapcraft#2711 opened: tests: print journal logs when spread tests fail <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2711>15:33
zygafinally15:35
zygamaster should no longer always fail15:35
zygait's back to roll-a-dice15:35
mupPR 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:36
* ijohnson goes and gets his lucky dice15:38
zygapstolowski: https://github.com/snapcore/snapd/pull/7449 is a bug fix so let's tag it as such15:49
mupPR #7449: overlord/configstate: special-case "null" in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>15:49
zygapstolowski: if you want you can also report a bug number on lauchpad for some stats but I won't push you for that :)15:50
pstolowskizyga: sure about tagging, i didn't know we do that15:53
zygapstolowski: I think it helps to prioritize reviews in some way15:55
zygamborzecki: can you look at https://github.com/snapcore/snapd/pull/7446 please15:56
mupPR #7446: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>15:56
zygait's rather simple and close to unblocking another PR15:56
zygawhich will in turn unblock a few more15:56
pstolowskizyga: no disagreement, +115:56
zygaijohnson: can you look at https://github.com/snapcore/snapd/pull/7448 -- just at the rationale of the change16:05
mupPR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>16:05
zygathe 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_id16:06
=== pstolowski is now known as pstolowski|afk
* cachio lunch16:26
sergiusenszyga: hey, how do I reset connections? I removed a couple of interfaces and snap connections is still showing them after removing and reinstalling the snap16:27
zygaI believe right now there is no user-facing way16:28
zygayou'd have to edit the state16:28
zygacc mborzecki for ideas16:28
zygaI think we discussed having something to do it16:28
* zyga switched to passive mode16:35
=== ricab_ is now known as ricab
pedroniswe have some ideas in that area (also related to hotplug), but not implemented yet17:15
ijohnsonzyga: yes I had that on my list of things to review for you17:55
zygaijohnson: thank you so much!18:12
mupPR snapcraft#2712 opened: snap: migrate to core18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2712>18:14
mupPR 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>18:47
mupPR 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:05
mupPR snapd#7452 opened: tests/classic-ubuntu-core-transition*: move to nightly <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7452>19:30
mupPR 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>20:28

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!