/srv/irclogs.ubuntu.com/2020/02/24/#snappy.txt

zygaHey06:15
zygaBack to school day06:15
mborzeckimorning06:17
zygaWe need to land the critical PR06:17
mborzeckizyga: hey, which one?06:17
zygaStuff is still broken, eh06:17
zygaLast one06:17
zyga817806:18
mborzeckiuhh06:18
mborzeckizyga: that's why pushing snapd to store failed on friday?06:19
zygare06:22
zygachecking what failed06:22
zygayes06:22
zygasucks, eh?06:22
zygaI saw some failover failures yesterday06:22
zygaand eh06:23
zygafu**06:23
zygahttps://www.irccloud.com/pastebin/RwhTm8UI/06:23
mborzeckifun? :)06:23
zygawhere do we get foo frm?06:23
zygacrap from other test?06:24
mborzeckiyeah, tha'd be my first guess06:24
zygapushed a fix06:25
mborzeckithere's security-private-tmp test06:25
mborzeckiand it ran before06:26
zygammm06:27
zygaI'll get coffee and fix this properly06:27
mborzeckizyga: maybe as a workaround, we could also take down the setgid flag in postinst?06:27
zygahmm?06:28
zygapostinst of the deb?06:28
zygathat would ruin the snap, no?06:28
zygaas in, that would cause the snap to be g-s06:28
zygaunless I don't understand how it's made06:28
zygain either case, it's all temporary06:29
zygawe'll fix review tools today06:29
zygadeploy in a day or two06:29
mborzeckiduh, yeah, that may produce a different result for deb and snap06:29
mborzeckihm looks like the snap is built by just extrating snapd, so we'd have to tweak the bit there too06:30
mborzeckibut that would break review-tools again :/06:30
zygamborzecki: I didn't test-build the deb because i didn't feel comfortable guessing how it's really built06:31
zygamborzecki: but the deb, for sure, has no g+s anymore06:31
zygaer06:31
zyga*has*06:31
zygaso with some luck it will pass06:31
zygabrb06:40
mupPR snapd#8179 opened: interfaces: power control interface <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8179>07:07
zygare07:42
zygamborzecki: can you review 817807:43
zygaI'll land with one review07:43
mupPR snapd#8178 closed: packaging: work around review-tools and snap-confine <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8178>07:51
mupPR snapd#8180 opened: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>07:58
zygamborzecki: ^ quick follow-up07:58
zygahey mvo07:58
zygagood morning07:58
zygamvo: FYI https://github.com/snapcore/snapd/pull/817807:58
mupPR #8178: packaging: work around review-tools and snap-confine <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8178>07:58
mvohey zyga07:59
mvozyga: looking07:59
pstolowskimorning08:01
zygahey Pawel :)08:01
zygamvo: this was pre-approved but I wanted to let you know it landed08:01
zygamvo: it allows core/snapd snaps to be published again08:01
mborzeckimvo: pstolowski: hey08:04
mvohey pstolowski and mborzecki08:04
mvozyga: yeah, saw the mails over the weekend08:04
zygafailover still fails08:05
mvozyga: do you know if jamie is aware that the review tools need fixing?08:05
zygayes08:05
mupPR snapd#8136 closed: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8136>08:05
pedronismvo: yes, he said he was working on it08:05
zygawe talked (Jamie / Pedronis / me) about it together08:05
mvocool08:05
pstolowskimvo: hey! it occured to me over the weekend that snap-pressed could be made a classic snap, which is what you probably meant when you suggested making it a snap :)08:05
zygasnapd-failover failure on top of current master https://www.irccloud.com/pastebin/pxEx4fth/08:06
mvopstolowski: yeah, that will work08:06
mupPR snapd#8168 closed: snapcraft.yaml: add comments, rename snapd part to snapd-deb <Simple 😃> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8168>08:09
pstolowskimvo: good, i'll prep a PR for that (a snapcraft.yaml inside cmd/snap-presseed?) and will make a quick test08:10
pedronispstolowski: do we know it's needed? I'm probably missing something08:11
zygahey pedronis, good morning :)08:11
pstolowskipedronis: the only alternative afaict is to use a ppa right now, until a new deb lands in the distro08:12
mvopstolowski: it's probably ok to wait for them for feedback first, their build setup is special and may not be suitable for snaps (I honestly don't know). so might be worth to double check before we invest time in this08:14
mborzeckibtw. trying to find out why spotify core dumps on arch reminded me of the missing feature of having access to debug symbols, that we discussed but never got down to working on it08:15
pedronismborzecki: there is been work on the snapcraft side on that08:16
pedroniswe actually need to play with it08:16
pedronisbut not much time atm08:17
pstolowskimvo: sure08:17
mborzeckipedronis: interesting, is there some info about the snapcraft bits?08:18
pedronismborzecki: yes08:18
pedronismborzecki: I can give some pointers in the standup08:18
mborzeckipedronis: please do, thanks!08:19
pedronismvo: I made a comment on #8100, does #8142 need a master merge?08:39
mupPR #8100: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>08:39
mupPR #8142: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <https://github.com/snapcore/snapd/pull/8142>08:39
pedronismborzecki: did you see my remark on #6708 ?08:42
mupPR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>08:43
pedronispstolowski: are you waiting on reviews from me atm ?08:43
pstolowskipedronis: no. thanks for asking!08:43
pedronismborzecki: when you have a second could you push master into #8147 ?08:45
mupPR #8147: cmd/snap-bootstrap: verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8147>08:45
mborzeckipedronis: sure08:45
pedronisthx08:45
mvopedronis: thanks, will followup, 8142 probably needs a master merge08:58
mborzeckispread tests should be fixed now in #815609:28
mupPR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>09:28
mborzeckimvo: pedronis: the recovery chooser binary is /usr/lib/snapd/snap-recovery-chooser, does that sound ok? i want to open a PR to subiquity with changes to console-conf-wrapper09:33
ackkhi, how do I remove a broken (try) snap? it complains because it doesn't find the .service file09:34
ackkhttps://paste.ubuntu.com/p/r4H46ycwVq/ is what I get09:37
ackkoh, it seems umounting the snap before trying to remove it worked09:40
mvomborzecki: sorry for the delay, was in a meeting. the name sounds good to me09:54
mvoackk: thanks, this feels a bit like a bug on our side, we need to be robust against failures here09:55
ackkmvo, TBF this was a "snap try" whose prime dir ended up being removed/overwritten, so kinda of an edge case09:56
mvoackk: agreed and yet we should handle it better :) but agreed on the edge-case so not that high of a priority right now09:57
mvoackk: out of curiosity, did you guys made progress on the run-away supervisor processes?09:57
ackkmvo, sort of. BjornT experienced something similar installing maas on a rpi4. my gut feeling is that if for some reason there's a high cpu usage and everything slows down, supervisord times out on starting processes, kills and restarts them, making things worse09:59
ackkmvo, in my case because of squashfuse using all cpu, on the rpi because of limited cpu power10:00
ackkmvo, there doesn't seem to be any error in logs in these cases, just processes being started and killed10:00
mupPR snapd#8181 opened: packaging: revert "work around review-tools and snap-confine" <Skip spread> <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8181>10:00
mvoackk: woah, ok10:00
zygamvo: https://github.com/snapcore/snapd/pull/8181 has two patches, only one should be reverted (the other will conflict once https://github.com/snapcore/snapd/pull/8180 lands10:15
mupPR #8181: packaging: revert "work around review-tools and snap-confine" <Skip spread> <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8181>10:15
mupPR #8180: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>10:15
mborzeckiyay, opened https://github.com/CanonicalLtd/subiquity/pull/63610:19
mupPR CanonicalLtd/subiquity#636: bin/console-conf-wrapper: detect whether snapd recovery chooser should run <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/636>10:20
zygamborzecki: looking :)10:20
mborzeckii'm thinking that maybe w should have a list of ttys in snapd that the chooser can be invoked on, like /etc/securetty, this can easily be gadget dependent10:21
zygamborzecki: looks innocent enough :)10:21
mborzeckiyeah, it does ;)10:21
mvozyga: aha, thanks, feel free to edit and force push, in a meeting righ tnow10:22
zygamvo: ack, will do10:22
mborzecki/var/lib/snapd/choosertty10:22
mborzeckiagain soemthing with jenkins spread test?10:25
zygamborzecki: I saw that today10:26
zygatheir repo times out10:26
zygaeh10:26
mupPR core20#23 opened: hooks: ensure console-conf@ is started after snapd.recovery-chooser-trigger.service <Created by bboozzoo> <https://github.com/snapcore/core20/pull/23>10:26
zygamborzecki: question10:27
zygawhat happens if that service is disabled?10:27
zyganamely if you systemctl disable snapd.recovery-chooser-trigger.service10:27
zygahow does that affect dependency chain?10:27
mborzeckizyga: nothing, it's only Before/After ordering, not Requires10:27
zygaaaah10:28
zygathat's great10:28
zygaok10:28
zygamborzecki: wild west idea: a tool that reads from a google spreadsheet, allowing us to put a marker in a specific cell that means jenkins test is skipped10:31
zygaor that arch or tumbleweed are broken today10:31
zygaetc10:31
zygamborzecki: the sheet could be ACLd and locked10:31
mborzeckizyga: we have s3 like storage for out gcp now, we could easily upload a list of disabled tests there, download it to the host, and skip at runtime, then track which run skipped what10:36
zygamborzecki: spreadsheets are way easier to work with10:36
zygamborzecki: and I bet the ACLs on entire file is not as nice as per-cell ACL10:36
mborzeckiidk, i prefer plain text files :P10:38
zygamborzecki: even changing files in s3-like thing is hard10:38
zygaand the other thing is self-documenting, you open a URL to a specific cell10:38
zygaand if you can, you can edit it10:38
zygaeasy10:38
zygacore 20 setup is sloooooooow10:46
mupPR snapd#8133 closed: cmd/snap-confine: deny snap-confine to load nss libs <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8133>10:48
mupPR snapd#8182 opened: build: enable type: snapd <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8182>10:59
pedroniszyga: we'll start taking care of some todos that should improve that a bit this week11:03
zygathat's good to know11:06
mborzecki#8176 is simple and green11:12
mupPR #8176: tests: adding amazon linux to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8176>11:12
zygabrb, cold and somewhat hungry as a result11:20
zygare11:37
zygahot tea :)11:37
zygadid anyone debug why tests/go.{mod,sum} show up11:50
zygakids back from school12:00
zygaalso school is back12:00
zygawhee12:00
zyga:)12:00
mborzeckiduh, wonder why nothing is printed out with termbox-go controlling ttyS012:13
zygamborzecki: maybe it establishes exclusive control over tty?12:35
zygathere's an ioctl for it12:35
zygaI used it once12:35
zygahttps://github.com/snapcore/core-build/blob/master/initramfs/testing/init.c#L21212:35
pedronismborzecki: some comments and questions on 815612:37
mborzeckizyga: hm so input works, i'm loogginmg when keys are pressed and so on, but the output does not work13:00
zygathat's odd13:00
cmatsuokazyga: are you aware of any mount flag that disables directories bind mounts but won't affect regular file bind mounts?13:01
zygacmatsuoka: no, because that's not a property of a mount point13:01
zygacmatsuoka: in other words, that's not possible AFAIK13:02
cmatsuokazyga: I'm having this really weird bug where I can't bind mount directories but files work normally13:02
cmatsuokaI mean, bind mounting files work, but directories fail silently13:02
zygacmatsuoka: can you tell me more please13:02
zygacmatsuoka: also /proc/self/mountinfo would help13:02
cmatsuokazyga: ok, so it's a long story. I'll start with the symptoms13:02
zygacmatsuoka: sure13:03
zygacmatsuoka: do you want to HO or is here find?13:03
zyga*fine13:03
cmatsuokain a HO it will be easier to explain13:03
zygasure13:04
cmatsuokaI'm in the SU room13:04
zygaone sec13:04
pedroniscmatsuoka: hasn't xnox made progress (see uc20)13:15
xnoxcmatsuoka:  all i can see is that without a valid /etc/crypttab things that require writable mount and bind to it, all get torn down by systemd, because it says dev-mapper-ubuntu-data.device? i don't need that, stop it now.13:16
xnoxcmatsuoka:  i'm now redoing to provide a valid /etc/crypttab in the mounted system, to ensure the post-switch-root systemd has left and right half of the brain connected together.13:17
zygafor reference, we discussed some ideas, including unbindable, and will look at mountinfo data to try to understand what is going on13:21
cmatsuokaxnox: thanks, I think the most interesting piece of information is that switching from a point as late as initrd-cleanup still works13:21
zygasnap session agent socket activation failed13:22
zygahttps://www.irccloud.com/pastebin/8UEOWyMx/13:22
zygajamesh: ^13:22
xnoxcmatsuoka:  yes, it's the systemd from the rootfs that gets confused.13:27
xnoxcmatsuoka:  you can boot with init=/bin/bash => such that switch-root pivots to a bash shell, where everything still looks sane13:27
cmatsuokaxnox: will try that13:28
pedronismvo: what is happenign here:  https://api.travis-ci.org/v3/job/654356068/log.txt there's a SKIP_GOFMT=1 but an error about go fmt ??13:28
zygapedronis: it runs gofmt13:30
zygaand ignores the result13:30
zygathat's how I remember it13:30
zyga(it's kind of weird)13:31
zygapedronis: it really failed on FAIL: overlord_test.go:694: overlordSuite.TestEnsureLoopPruneAbortsOld13:31
zygapedronis: roughly before the middle of the test log13:31
pedronisah13:31
pedronisI was confused13:32
pedronispstolowski: https://api.travis-ci.org/v3/job/654356068/log.txt13:32
zygayeah, we should remove that gofmt thing on SKIP_GOFMT13:32
zygait's silly13:32
zygapedronis: I'll do it later today13:32
* zyga looks outside at endless rain13:33
zygagood thing I have tea :)13:34
cmatsuokaxnox: confirmed, it works just after switch root and before init13:37
mborzeckizyga: what about SKIP_GOFMT?13:40
zygamborzecki: it's really RUN_GOFMT_AND_NOT_FAIL_LOL=113:40
mborzeckiwell, that's its purpose13:41
zygamborzecki: it's a weird purpose13:41
zygamborzecki: it's always noise13:41
zygamborzecki: why would you want to look at gofmt from incompatible version of go?13:41
mborzeckizyga: not sure i follow13:41
zygamborzecki: we set SKIP_GOFMT=1 when we know the result is garbage anyway13:41
mborzeckizyga: the problem is that travis builds and cheks with go 1.10, which i don't use locally13:42
zygamborzecki: when it is equal to 1 then we _run_ gofmt, print a bunch of diff, and not fail on that13:42
mborzeckizyga: right, so that you know what's wrong wrt. 1.10 that travis uses13:42
zygamborzecki: are you saying it's always wrong? :)13:42
mborzeckizyga: if go didn't break the formatting in 1.11 we wouldn't have the problem, but they did13:42
zygamborzecki: anyway, if you look at what the code does now13:43
zygamborzecki: I think you will agree that what we do is silly13:43
zygamborzecki: we do run the gofmt check with the right go13:43
zygamborzecki: (in other places)13:43
zygamborzecki: but we always run and print useless diff regardless of anyone asking for it13:43
pedronisas data point I was confused by it and missed the real issue initially13:44
mborzeckizyga: but other palces isn't travis unit tests job , maybe it shouldn't check gofmt then13:44
zygamborzecki: there's a task that checks gofmt with the right version13:45
zygamborzecki: it's not the quick-and-early check13:45
zygamborzecki: the quick and early check does run gofmt verification, wasting time, producing confusion and _ignores_ the result because go version mismatch13:45
zygamborzecki: that's the problem13:45
pedronismmh, this was not the early check13:46
pedronisthis was unit/go13:46
pedronisafaict13:46
zygapedronis: right13:46
zygapedronis: because that's the same piece of code13:46
zygait runs twice13:46
mborzeckizyga: because we run unit tests twice13:46
zygaI think we should just not run gofmt check at all if SKIP_GOFMT is set13:46
zygamborzecki: correct13:46
mborzeckizyga: once in travis, then antoher one in spread, the 2nd may run on a new distro where go isn't 1.1013:47
zygamborzecki: that's correct too13:47
mborzeckizyga: so shoudl the early check fail, you get a diff of the code wrt. 1.10, and you know what to fix or reformat13:48
zygamborzecki: that's not what I'm saying13:48
zygamborzecki: unless I'm confused: <zyga> I think we should just not run gofmt check at all if SKIP_GOFMT is set13:48
zygamborzecki: this is sufficient to keep checking exactly what we check now and reduce the confusing diff intermixed with actually relevant unit test failures13:49
zygajdstrand: hey13:50
zygajdstrand: https://github.com/snapcore/snapd/pull/8123 is ready for a quick re-review13:50
mborzeckizyga: ah ok, so yeah, skip the whole thing then13:50
mupPR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>13:50
zygajdstrand: please check my comments but I think you will find that it implements what you outlined13:50
jdstrandzyga: I saw13:50
jdstrandwell, I saw it was ready for re-review13:50
zygajdstrand: I didn't implement the helper that makes the permissions side more understandable13:50
jdstrandI haven't gone through it yet13:50
ijohnsonguten tag friends :-)13:50
zygajdstrand: but you indicated that as optional for now13:51
jdstrandhey ijohnson :)13:51
ijohnsonhey jdstrand13:51
zygajdstrand: I'll get back to transient scope pr now13:51
zygaijohnson: halo :)13:51
ijohnsonhow are you zyga? have a good weekend?13:52
zygaijohnson: pretty good, yeah13:52
zygaijohnson: winter holidays are over so kids are back to order ;)13:52
ijohnsonnice, it got really warm here over the weekend (like 5-10 C I think) and we had a bbq at my mom's house, and I found some paczki to share for dessert!13:53
zygaijohnson: oh, nice :)13:53
zygaijohnson: what's the flavor?13:53
ijohnsonzyga: it had custard cream in it with some powdered sugar on the outside13:54
ijohnsonlet me see if I can find a picture13:54
zygaNO :D13:54
ijohnsonI guess it's a bit "americanized"13:54
zygaI didn't have lunch yet13:54
ijohnsonhahaha13:54
zygaI'll be super hungry all standup :D13:54
zygaijohnson: we usually have some jam inside, rose or plum13:55
zygaijohnson: and carmelized orange peel on the outside13:55
ijohnsonhttps://usercontent.irccloud-cdn.com/file/RhgAaQJe/paczki.png13:55
zyga(yummy)13:55
ijohnsonah that sounds really good13:55
ijohnson^ that's what the ones I found look like13:55
zygathat's a sizable bag :D13:55
zygaoh well13:55
zygaI have some leftovers from dinner to warm up after standup13:56
zyga(not paczki though)13:56
ijohnson:-)13:56
zygacmatsuoka: I see the mountinfo data13:57
pstolowskipedronis, zyga oh it failed despite the sleep bump last Friday? hmm13:58
zygapstolowski: not sure but I think I saw one failure after rebasing13:58
zygapstolowski: I don't know the state of the branch that Samuele was looking at13:59
pstolowskii see13:59
zygacmatsuoka: and when it was in the broken state, what's the mount operation that you tried to perform exactly?14:00
zygaoh14:00
zygastandup14:00
mupPR snapd#8183 opened: tests: remove tmp dir for snap not-test-snapd-sh on security-private-tmp test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8183>14:39
zygahttps://github.com/snapcore/snapd/pull/8180 needs a 2nd review and should be [simple]14:41
mupPR #8180: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>14:41
jdstrandzyga: ok, responded to PR 812314:43
mupPR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>14:43
zygajdstrand: thank you14:43
jdstrandzyga: did you see my comment in PR https://github.com/snapcore/snapd/pull/7731#issuecomment-58982976414:43
mupPR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open <⛔ Blocked> <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>14:43
zygajdstrand: not yet14:44
jdstrandzyga: you might want to see my other comments from friday14:44
zygajdstrand: I will, github has some nice new notifications14:44
zygaI need to start using that again14:44
jdstrandzyga: I think we can merge it now, cherry-picking to 2.44 if needed14:44
zyga(the previous one was just noise and hard to find anything in)14:44
zygajdstrand: ack, I'll review both shortly14:45
mvomeh, my inbox just exploded with snapd edge build failures :(14:50
zygayeah14:53
zygadid you check14:53
zygaI'm considering checking or having quick lunch ahead of core 20 sync14:53
roadmrdoes a rabbit qualify as "quick lunch"?15:05
roadmralso - baby oil - which part of the baby does it come from? 🤔15:05
cwayneroadmr: i literally asked that yesterday15:09
roadmryou were around asking questions about baby oil on #snappy on sunday?15:12
jdstrandroadmr: you are on fire today :)15:14
zygafailure from launchpad builders https://www.irccloud.com/pastebin/i6AZBoZK/15:14
roadmrand it's only 10:15 am :)15:14
jdstrand\o/15:14
zygapstolowski: ^ does that ring a bell15:17
ijohnson zyga: have you seen this kind of spread failure ? https://pastebin.ubuntu.com/p/TQ3mkHcQW5/ I've seen this twice now in the past week15:18
zygaijohnson: yes, it's fixed15:18
zygaijohnson: https://github.com/snapcore/snapd/pull/8180 would help too15:18
ijohnsonzyga: ack I'll merge master into my PR15:18
ijohnsonthanks15:18
mupPR #8180: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>15:18
zygaijohnson: if you review, it's +1 and green and simple15:18
zygathank you15:19
ijohnsonzyga: +1d and merged15:19
mupPR snapd#8180 closed: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8180>15:19
zygalittle description is confusingly close to little encryption15:22
pstolowskizyga: no, not really15:22
zygapstolowski: ok,15:22
mvozyga: I see a lot of failures in the ppa build with "cannot set effective group to 0: Operation not permitted" - do you know anything about this?15:41
mvozyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages e.g. the s390x build for 19.1015:42
=== hggdh-msft is now known as hggdh
mvozyga: fwiw, it happens when running the unit tests it seems15:54
zygamvo: hmmm15:57
zygamvo: probably the setgid change15:57
zygamvo: I'll check15:57
mvozyga: yeah, I was wondering if it might be15:57
mvozyga: thanks for having a look!15:57
mvozyga: the error does indicate it, maybe the priv dropping leaking into the unit tests?15:58
mvozyga: anyway, strange that it suddently starts15:58
zygamvo: perhaps that's the change I landed in the morning15:58
mvozyga: that sounds plausible15:59
mvozyga: that's around the time it started to fial15:59
zygaaaah15:59
mvofail15:59
zygaI get it15:59
* mvo hugs zyga15:59
zygathe test run as user15:59
zygaand this is new code path15:59
zygaI'll fix this today15:59
zygasorry15:59
zygait didn't come out in our tests because those ... run as root15:59
zygaOR15:59
zygathere's something else missing16:00
zygaI think we may have started to run tests as a user as well16:00
mvozyga: yeah, it breaks the snap building so let's treat is as high priority16:00
zygaI'll finish dinner and fix it16:01
mvozyga: if I can help please let me know, happy to investigate myself but I also feel it's probably silly because you know the details way better than me16:10
mvoijohnson: a review of 8182 would be appreciated, I saw you self-requested a review, we would like to cordinate with the store to do this RSN16:16
ackkhi, does snapd need access to anything else than api.snapcraft.io:443 to for store access?16:18
zygare16:19
zygaackk: probably, for downloads16:19
zygaackk: but dunno for sure16:19
pedronisackk: yes, there is more, the store keeps an official list16:21
mupPR snapd#8182 closed: build: enable type: snapd <⛔ Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8182>16:21
ackkpedronis, thanks16:22
ijohnsonpedronis: re: error wrapping in #8177, is it okay if I wrap errors in other places? or would you prefer that I just not wrap errors there for now and add a TODO:UC20: to wrap those errors later? because many of the seed errors are a bit unclear on an actual system to see why boot failed IMHO16:47
mupPR #8177: cmd/snap-bootstrap/initramfs-mounts: mount the snapd snap in run-mode too <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8177>16:47
pedronisijohnson: I would prefer not to wrap for now16:47
pedronisbecause that code is in flux16:47
ijohnsonpedronis: ack I will just remove the wrapping for now then16:47
pedronisijohnson: there's some common code there, that probably should go in a single helper16:48
ijohnsonpedronis: in this PR or later with  TODO:UC20:16:48
ijohnson?16:48
ijohnsonI know the TODO's are a bit piling up now16:48
pedronisijohnson: later16:48
ijohnsonok16:48
pedronisijohnson: I need to change a bit the signature of LoadMeta16:49
mupPR snapd#8142 closed: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8142>16:49
ijohnsonsure that would make it easier/quicker in run mode16:49
ijohnsonpedronis: 8177 is ready again but still needs second review16:53
* ijohnson updates 8147 now16:54
=== heather1 is now known as hellsworth
pedronisijohnson: I reviewed both17:11
ijohnsonthanks pedronis17:11
=== heather1 is now known as hellsworth
ijohnsonI'll do a little bit more gardening of my open PR's then get back to opening the boot robustness tests PR17:12
pedronisthx17:12
pedronisijohnson: I'm reading now grub TryKernel, I don't understand when it would return true and err at the same time17:40
sarnoldmaxiberta: hello :) what would you think about autoconnecting htop's necessary permissions? last week a user on #ubuntu had a seriously unhappy machine https://pastebin.com/raw/hJASew3R17:41
ijohnsonpedronis: but we will eventually have multiple implementations of ExtractedRunKernelImageBootloader, i.e. uboot, lk, etc.17:41
pedronisijohnson: they should all behave this way17:41
pedronisit's not a sane api17:41
ijohnsonpedronis: but can't we be more safe ?17:41
pedronisijohnson: yes, and no17:42
pedroniswe can but that invariant broken is very confusing for readers17:42
pedronisso I'm not sure this is a long term sane state of things17:42
ijohnsonwould a comment help this to explain we're being extra cautious there ?17:43
pedronisijohnson: maybe but honestly I wouldn't expect users of that api to need to be cautius17:43
pedronisit's really unusual for a go function to return an error and other values != zero17:43
pedronisit happens but it's rare17:43
pedronisand usually very documented17:43
ijohnsonyes but when it happens it's a usually a bug so we're trying to be resilient here against a bug17:44
ijohnsonif we aren't careful then we would panic and boot would fail17:44
ijohnsonerr rather17:44
ijohnsonif we aren't careful and there is a bug, we would panic and boot would fail17:44
ijohnsonI'm perfectly fine with your suggestion to change the order of the check17:44
ijohnsoni.e. `if err == nil && tryKernelExists` seems fine to me17:45
=== ijohnson is now known as ijohnson|lunch
pedronisijohnson|lunch: related to this boot.ExtractedRunKernelImageBootloader probably merits more details docs about the methods behavior18:17
mupPR snapd#8184 opened: cmd/libsnap, tests: fix C unit tests failing as non-root <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8184>18:29
* zyga pushes one small PR and EODs18:29
zygaplease land that to unbreak PPA builds18:29
* zyga is afk, tg in case of urgency18:29
mupPR snapd#8171 closed: cmd/snap-failure/snapd: rm snapd.socket, reset snapd.socket failed status <Simple 😃> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8171>18:30
mupPR pc-amd64-gadget#37 opened: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>18:37
mupPR snapd#8176 closed: tests: adding amazon linux to google backend <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8176>18:47
=== ijohnson|lunch is now known as ijohnson
mupPR snapd#8185 opened: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>19:33
ijohnsonhey mwhudson do you still maintain console-conf for ubuntu core?20:34
mwhudsonijohnson: "maintain"20:37
ijohnson:-)20:37
ijohnsonquick question20:37
ijohnsonthis PR: https://github.com/CanonicalLtd/subiquity/pull/389 was merged to the core/bionic branch, but I don't see any other core/... branches, so if we need to do the same thing/similar thing for uc20, where would we propose that change to?20:38
mupPR CanonicalLtd/subiquity#389: services: run console-conf after core18.start-snapd.service <Created by mvo5> <Merged by sil2100> <https://github.com/CanonicalLtd/subiquity/pull/389>20:38
ijohnsonor better yet, could we just land the equivalent change for uc20 to subiquity master and have it show up in focal eventually ?20:38
=== heather1 is now known as hellsworth
ijohnsonmwhudson: ^21:02
mwhudsonijohnson: hmmm the version of console-conf in focal may well be a bit broken21:03
mwhudsonijohnson: in general xnox knows a lot more about uc20 things21:03
ijohnsonmwhudson: ok, just curious about the branching situation with console-conf21:03
mwhudsonijohnson: magic 8 ball says "vague"21:04
mwhudsonijohnson: basically there isn't one i guess21:04
ijohnsonmwhudson: haha, fair enough21:04
ijohnsonmwhudson: also thoughts on having the console-conf service always specify `After=... <insert-ubuntu-core-specific-things ad infinitum>` in the systemd unit? I don't think that breaks anything because if the uc things don't exist if it's just After then it's just ignored IIRC21:06
ijohnsoni.e. put that in master so it runs on classic and core21:06
xnoxijohnson:  i've dropped version number from the systemd job in core20, because it is silly.21:06
mwhudsonijohnson: sounds vaguely sane21:07
mwhudsonah hi xnox21:07
xnoxijohnson:  and yes, something similar needs to land to master + dput to focal21:07
xnoxijohnson:  ie. After=core.start-snapd.service After=core18.start-snapd.service to cover all basis21:07
ijohnsonxnox: so should I file a PR to subiquity master with those changes then?21:07
xnoxijohnson:  we are overdue a consoleconf upload.21:07
xnoxijohnson:  yes please21:07
ijohnsonok, sounds good21:07
xnoxijohnson:  i can pre-test them against hand-built core20 snap too with a UC20 image21:08
ijohnsonxnox: also not sure if you saw, but maciej opened this: https://github.com/snapcore/core20/pull/23, but I think the better way to do that is to just put it all in console-conf upstream21:08
mupPR core20#23: hooks: ensure console-conf@ is started after snapd.recovery-chooser-trigger.service <Created by bboozzoo> <https://github.com/snapcore/core20/pull/23>21:08
xnoxijohnson:  i think so21:09
ijohnsonxnox: ok, I think I will file a PR with the core18 specific hacks first then maybe maciej re-opens his core20 PR against subiquity upstream then21:10
ijohnsonthanks xnox and mwhudson21:15
hellsworthpart21:26
mupPR snapd#8147 closed: cmd/snap-bootstrap: verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8147>21:36
pedronisijohnson: after further thinking, I still we should follow the pattern we use in other cases (like ErrNoState) and have a special error (ErrNoTryKernelRef ?) instead of the bool for TryKernel21:46
ijohnsonpedronis: ok, that's easy enough to do and I think I can wrap that up succinctly in my next PR21:46
pedroniss/still/think/21:47
pedronisijohnson: thx21:48
zygaensure prune thing is still failing22:16
zygahttps://github.com/snapcore/snapd/pull/8186 as promised22:27
mupPR #8186: run-checks: SKIP_GMFMT really skips formatting checks <Created by zyga> <https://github.com/snapcore/snapd/pull/8186>22:27
zygaand back to bed22:27
mupPR snapd#8186 opened: run-checks: SKIP_GMFMT really skips formatting checks <Created by zyga> <https://github.com/snapcore/snapd/pull/8186>22:28
mupPR snapd#8187 opened: boot: misc UC20 changes <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8187>22:55
mupPR core18#148 opened: hooks: delete console-conf hack <Created by anonymouse64> <https://github.com/snapcore/core18/pull/148>23:17
mupPR core20#24 opened: hooks: delete console-conf hack <Created by anonymouse64> <https://github.com/snapcore/core20/pull/24>23:20

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