[06:13] <mborzecki> morning
[06:34] <mborzecki> school run, back in 30
[07:08] <mborzecki> re
[07:08] <mborzecki> mvo: hey!
[07:11] <mvo> hey mborzecki ! good morning
[07:12] <mvo> mborzecki: 8146 and 8144 are easy wins I think
[07:14] <doko> the chromium snap and others don't accept keyboard input anymore in focal. is this known, or where should this be reported?
[07:17] <mborzecki> doko: afaik it's fixed in master, and mvo uploaded a patched snapd to ubuntu
[07:20] <mvo> doko: upload should already be in focal, I think I got the focal-proposed -> focal mail last night
[07:20] <doko> ahh, ok, a reload helped
[07:23] <mup> PR snapd#8146 closed: tests/core: add swapfiles test <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8146>
[07:35] <mup> PR snapd#8144 closed: tests: use Filename() instead of filepath.Base(sn.MountFile()) <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8144>
[07:37] <mvo> mborzecki: \o/
[08:09] <pstolowski> morning
[08:12] <mvo> hey pstolowski - good morning
[08:20] <mborzecki> pstolowski: hey
[08:23] <zyga> good morning
[08:23] <zyga> sorry for a late start
[08:23] <zyga> let's get to work!
[08:32] <pstolowski> hey zyga
[08:32] <zyga> hey :-)
[08:50] <mup> PR snapd#8148 opened: overlord/configstate/configcore: add support for backlight service <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>
[08:57] <sdhd-sascha> hello
[09:27] <mvo> sdhd-sascha: good morning!
[09:27] <sdhd-sascha> mvo: :-)
[09:28] <zyga> hey sdhd-sascha :)
[09:28]  * zyga munges breakfast while catching up on email
[09:28] <sdhd-sascha> I just started to add some variables to the build-action. So every repo on github can configure, if the action should run...
[09:29] <sdhd-sascha> I use `github secrets` for variables...
[09:30] <zyga> oh boy, I have 342 bugs in fedora on selinux denials
[09:30] <zyga> and it's my bug triage day
[09:30]  * zyga cries a little
[09:35] <mborzecki> zyga: some of those are probably fixed
[09:36] <mborzecki> some are probably caused by anaware users :/
[09:37] <mborzecki> s/anaware/unaware/ ofc
[09:39] <mup> PR snapd#7624 closed: snap: make `snap download` download via snapd if available <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7624>
[09:47] <zyga> mborzecki: yeah but which
[09:47] <zyga> mborzecki: I'll try to do something smart about them
[10:04] <pedronis> mborzecki: hi, did you see that #6708 failed on a some task.yaml formatting issue?
[10:04] <mup> PR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
[10:06] <zyga> pedronis: fixed
[10:06] <zyga> pedronis: it's funny because maciek added the checks :)
[10:06] <mborzecki> pedronis: thanks for spotting, spread-shellcheck didn't complain but i obviously forgot about the multiline check :/
[10:06] <mborzecki> zyga: heh, yeah the irony of it :P
[10:07] <mborzecki> hm maybe this should become part of spread-shellcheck at some point
[10:07] <pedronis> it failed somewhere in the static checks afaict
[10:08] <zyga> pedronis: it failed on lack of | in prepare
[10:08] <mborzecki> pedronis: it complained about `tests/main/buildmode-pie/task.yaml:9:prepare:` not bneing `prepare: |`
[10:08] <zyga> technically it is parsing but not as people expected
[10:30] <pedronis> #8003, #8078 and #8101 need reviews or 2nd reviews (they should all be close to landable)
[10:30] <mup> PR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
[10:30] <mup> PR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>
[10:30] <mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
[10:31] <zyga> pedronis: I'll look at 8003 after going through new bugs
[10:32] <zyga> I can look at the rest as well though 8078 can probably be merged
[10:32] <zyga> I see there's one change since my last review
[10:32] <zyga> I'll read it and probably approve
[10:33] <zyga> pedronis: let's land 8078
[10:33] <zyga> thank you for pushing this forward!
[10:34] <pedronis> thx
[10:36] <pstolowski> doh, getting something green on travis seems very hard again
[10:36] <zyga> https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/263 is interesting to read
[10:37] <sdhd-sascha> I just added some `secrets` to control the github-action-workflow
[10:38] <sdhd-sascha> mvo: any idea to make the github-action more usable ?
[10:41] <mvo> sdhd-sascha: is it trivial to run unit tests in it?
[10:43] <sdhd-sascha> mvo: i think it's possible. If you look at jhenstridge github action. It's super readable typescript
[10:43] <sdhd-sascha> And you can run, any shell script ...
[10:45] <mvo> sdhd-sascha: I think the building in GH is less interessting for us, we have LP building stuff for us and I think that's fine, has the nice store integration so we auto-upload builds to the store and get the assertions etc. but I can see actions as a nice way to do a first level checking, i.e. what we do today with travis static checks. not sure about the details though, haven't really looked at this myself
[10:47] <sdhd-sascha> mvo: true. I also added upload to the store. As i have said, i need for classic-snap's, because of the approval
[10:47] <mup> PR snapd#8078 closed: daemon: support resuming downloads <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8078>
[10:49] <sdhd-sascha> mvo: i have to install a github-runner locally, to better understand how it works internal
[10:57] <mvo> sdhd-sascha: upload to the store> interessting
[10:57] <mvo> sdhd-sascha: keep me updated please, it sure looks like fun :)
[10:57]  * mvo really hopes it is
[11:01] <sdhd-sascha> mvo: i too :-)
[11:12] <pstolowski> pedronis: ok to land https://github.com/snapcore/snapd/pull/8046 ? i pushed small changes to the spread test for focal. and it's finally green
[11:12] <mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[11:14] <pedronis> pstolowski: do we understand why prepare is different?
[11:14] <pstolowski> pedronis: yes and no, we understand that qemu-nbd gets stuck if it's part of prepare. i reorganized the test to do this in execute
[11:14] <pedronis> but we don't know why it gets stuck?
[11:15] <pstolowski> pedronis: yep, we don't
[11:16] <pedronis> ok
[11:16] <pstolowski> pedronis: i can try to investigate and maybe have a followup; fwtw it's unrelated to the functionality and what we're testing
[11:16] <pedronis> pstolowski: anyway it is fine to land,  we don't have the same problem in restore, right?
[11:16] <pstolowski> pedronis: no
[11:17] <pstolowski> thanks
[11:17]  * pedronis lunch
[11:18] <mup> PR snapd#8046 closed: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[11:21] <mup> PR snapd#8149 opened: snapmgr, backends: maybe restart & security backend options <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8149>
[11:37] <sdhd-sascha> mvo: did you know, that it is possible to run services on github: https://github.com/actions/example-services
[11:37] <zyga> oh
[11:37] <zyga> that's ... interesting!
[11:39] <sdhd-sascha> :-)
[11:40] <ogra> well ... https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930
[11:40] <ogra> ;)
[11:44] <mvo> sdhd-sascha: I had no idea
[12:09] <pedronis> pstolowski: I re-reviewed #8130, the logic is not quite what I expected
[12:09] <mup> PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130>
[12:11] <pstolowski> oh
[12:12] <pstolowski> pedronis: ok, thanks
[12:12] <pstolowski> i must have misunderstood the details
[12:12] <mborzecki> ijohnson: mvo: cmatsuoka: a little script for repacking the kernel snap with changes to initramfs https://gist.github.com/bboozzoo/010ed5e94ee0f695d1aeece43513a018
[12:13] <pedronis> pstolowski: the change is not big, anyway see my comment there
[12:13] <pedronis> but the tests will need adjusting too
[12:14] <cmatsuoka> mborzecki: ah thanks, it's nicer than the one I'm currently using
[12:18] <mvo> mborzecki: woah, nice!
[12:29]  * pstolowski lunch
[13:38] <zyga> ondra, ogra, plars: hey guys
[13:38] <zyga> I tried reproducing https://bugs.launchpad.net/snapd/+bug/1846397
[13:38] <zyga> (perhals sil2100 ^ as well as you were in the bug)
[13:38] <mup> Bug #1846397: snapdragon uc18 image fails to boot (current stable) <snapd:In Progress by ondrak> <https://launchpad.net/bugs/1846397>
[13:38] <zyga> can you guys tell me that we successfully test-boot current core18 images on the dragon board?
[13:39] <zyga> I'll try the release image to double check
[13:42] <cwayne> zyga: that bug should be marked as fixed
[13:42] <zyga> cwayne: can you mark it as such with a comment please
[13:43] <cwayne> done
[13:44] <zyga> cwayne: hmm, given that you are here, do you remember if there's anything special that is needed to boot that board?
[13:44] <zyga> I wonder why I cannot get ubuntu core on it
[13:45] <zyga> (as my last message in the bug indicated)
[13:45] <cwayne> was that with the latest stable?
[13:45] <zyga> I tried the release image we advertise on the website
[13:45] <zyga> https://ubuntu.com/download/qualcomm-dragonboard-410c
[13:45] <zyga> http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ubuntu-core-18-arm64+snapdragon.img.xz
[13:46] <zyga> but I suspect the image may be correct - I don't think I actually even attempted to boot it for some reason
[13:46] <zyga> I have the card inserted now and I'm running some old debian from linaro
[13:46] <zyga> I can poke around the SD
[13:47] <cwayne> zyga: i'd ask plars when he's around, I don't have this board (but i feel like there's some dipswitch needed or something)
[13:47] <zyga> yeah, I set those up
[13:47] <zyga> could be a wonky card, I'll try with another one
[13:50] <zyga> yeah
[13:50] <zyga> werd
[13:50] <zyga> weird
[13:50] <zyga> the card works but would not boot
[13:50] <zyga> I used another and boom,
[13:50] <zyga> it's okay
[13:50] <cwayne> phew, you scared me there zyga
[13:51] <zyga> I'll make sure it works past registrationa
[13:51] <zyga> and that I can refresh
[13:51] <zyga> and adjust the bug
[13:51] <cwayne> also it wasnt really appropriately logged, IIRC it was an issue with the gadget not snapd at all
[13:52] <zyga> yeah, that's common, snapd is the catch-all-project
[13:52] <cwayne> ah right, fair enough
[13:52] <ogra> wasnt there some switch on the db410 that you need to flick to have it boot from SD?
[13:53] <ogra> (i havent touched any dragonboard in probably 1.5y)
[13:53] <cwayne> neither has anyone else lol
[13:53] <cwayne> ogra: it turned out to be a bad sd card
[13:53] <ogra> in general ondra is our qualcomm guy though
[13:53] <zyga> heeey
[13:53] <ogra> haha
[13:53] <zyga> look at what I got
[13:53] <zyga> Press enter to configure.
[13:53] <zyga> :D
[13:53] <zyga> that's a small wonder there
[13:54] <zyga> I'm in
[13:55] <ijohnson> morning folks
[13:55] <cwayne> Imagining you saying that like a hacker in a movie
[13:55] <cwayne> GUYS IM IN
[13:56]  * ijohnson almost got crushed by a car this morning
[13:56] <zyga> ijohnson: good morning, are you okay? what happened?
[13:56] <zyga> cwayne: that's unix, I know this
[13:56] <zyga> cwayne: AWW SNAP
[13:56]  * zyga googles how to work with snaps on stackoverflow
[13:56] <ijohnson> yeah I'm fine, just very icy outside and an SUV couldn't stop at a stop sign and so slid through the intersection
[13:57] <ijohnson> great way to end yoga though
[13:57] <plars> zyga: yes, the core18 images currently in stable should boot just fine for you, and upgrading to the latest gadget snap will not cause any problems, but you could get the problem if you build a fresh image with the current gadget snap
[13:57] <cwayne> Gotta re-tense after yoga
[13:57] <zyga> ijohnson: ouch
[13:57] <ijohnson> cwayne: exactly
[13:57] <zyga> is it common to use chains on icy days?
[13:57] <ijohnson> no not in the cityu
[13:57] <zyga> plars: confirmed, it's all good
[13:57] <ijohnson> you just wait for the city to put ice down, or you drive carefully :-)
[13:57]  * cwayne has never used snow chains
[13:58] <cwayne> Or snow tires
[13:58] <zyga> plars: I see, do you know what is the problem with the gadget snap?
[13:58] <ijohnson> my grandpa showed me how to put them on, but I have never used them and don't own any
[13:58] <roadmr> cwayne: aren't winter tires mandatory in your neck of the woods, in winter?
[13:58] <cwayne> Nah
[13:58] <ogra> cwayne, didnt you grow up in new hampshire ?
[13:58] <cwayne> Heavily suggested
[13:58] <cwayne> ogra: Massachusetts :)
[13:58] <ogra> well, close
[13:58] <cwayne> Took my driving test in a blizzard
[13:58] <ogra> how can you never have used snow tires there
[13:59] <ijohnson> it used to be mandatory where my grandpa lives in rural wisconsin because the roads were plowed so infrequently
[13:59] <plars> zyga: I believe it was a u-boot issue - some new bug that came with it getting updated
[13:59] <ogra> it definitely is in germany ...
[13:59] <zyga> plars: I see, another bug for another time
[13:59]  * zyga is reviewing in-progress bugs
[13:59] <ijohnson> time to SU
[14:27] <kenvandine> zyga: i'm still seeing this ibus/snapd issue in focal with all the updates installed
[14:27] <kenvandine> zyga: wiping ~/snap/irccloud-desktop/common/.cache fixed it for irccloud-desktop
[14:27] <kenvandine> but not for other snaps
[14:28] <kenvandine> all very weird
[14:28] <zyga> kenvandine: uh, weird, do you know how ibus works enough to debug this?
[14:28] <zyga> I'm essentially green
[14:28] <zyga> do you see any more denials?
[14:28] <kenvandine> no idea
[14:28] <kenvandine> Feb 18 09:23:06 trabajo kernel: [  667.096071] audit: type=1400 audit(1582035786.790:404): apparmor="DENIED" operation="connect" profile="snap.chromium.chromium" pid=39109 comm="pool" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/home/ken/.cache/ibus/dbus-MQguChWC" peer="unconfined"
[14:28] <kenvandine> i think oSoMoN understands it
[14:38] <zyga> I'll go and grab some food now
[14:38] <zyga> see you guys later :)
[14:39] <sil2100> zyga: hey!
[14:39] <sil2100> zyga: commented on the bug o/
[14:40] <sil2100> So once you're back, have a look :)
[14:49] <mup> PR core18#147 closed: Add bash-completion support <Created by xnox> <Merged by sil2100> <https://github.com/snapcore/core18/pull/147>
[15:09] <ijohnson> kenvandine: I just upgraded to focal yesterday and had the same problem with ibus, it wasn't fixed with snapd from focal-proposed or the core snap edge either, I had to rebuild snapd from master and use that
[15:09] <kenvandine> ijohnson: interesting
[15:09] <kenvandine> the fix seems to have worked for some snaps
[15:10] <ijohnson> kenvandine: it might be possible that the fix from jdstrand hasn't made it to edge yet somehow
[15:10] <kenvandine> i haven't really figured anything out though
[15:10] <ijohnson> kenvandine: the snap I immediately noticed the problem with was irccloud
[15:10] <kenvandine> me too
[15:10] <kenvandine> firefox and chromium are working for me now too
[15:10] <kenvandine> but gedit isn't
[15:13] <ijohnson> is gedit a snap now?
[15:13]  * ijohnson still has gedit from deb pkg on focal
[15:14] <jdstrand> ijohnson, kenvandine: the snapd in focal has the fix
[15:14] <ijohnson> jdstrand: the deb ? why doesn't the edge snap have the fix ?
[15:14] <kenvandine> jdstrand: it should... and it's working for some snaps
[15:15] <jdstrand> ijohnson: the deb yes. I don't know about edge if it doesn't
[15:15] <kenvandine> jdstrand: i had to wipe ~/snap/chromium/common/.cache to get chromium to work
[15:15] <kenvandine> gedit is still seeing denials
[15:15] <kenvandine> i have avoided wiping the cache to keep the test case around
[15:16]  * ijohnson tries snapd from deb pkg w/irccloud again, brb
[15:16] <jdstrand> kenvandine: you are still talking about ibus?
[15:17] <kenvandine> jdstrand: yes
[15:17] <jdstrand> kenvandine: I think all you need to do is make sure all the chromium processes are gone
[15:17] <jdstrand> kenvandine: that is all I had to do with firefox and chromium
[15:17] <jdstrand> and gedit works fine
[15:17] <kenvandine> that could have been the case there
[15:17] <kenvandine> gedit is still a problem for me
[15:17] <kenvandine> Feb 18 09:49:52 trabajo kernel: [ 2272.927989] audit: type=1400 audit(1582037392.623:434): apparmor="DENIED" operation="connect" profile="snap.gedit.gedit" pid=104786 comm="pool" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/home/ken/.cache/ibus/dbus-MQguChWC" peer="unconfined"
[15:18] <jdstrand> kenvandine: can you paste /var/lib/snapd/apparmor/profiles/snap.gedit.gedit ?
[15:19] <ijohnson> hmm the deb seems to work w/ irccloud and the gedit snap now for me, with re-exec disabled
[15:19] <ijohnson> trying with re-exec enabled
[15:19] <kenvandine> jdstrand: https://paste.ubuntu.com/p/xwBCYrr6Yt/
[15:19]  * jdstrand notes he has the stable core, so the deb comes up as newer
[15:20] <jdstrand> kenvandine: yeah, that doesn't have the new rule
[15:20] <jdstrand> kenvandine: what is the output of snap version?
[15:20] <ijohnson> jdstrand: yeah with edge core snap and re-exec enabled I can't type now again
[15:20] <kenvandine> https://paste.ubuntu.com/p/qFdSkXvpq2/
[15:20] <kenvandine> yeah, i have core from edge
[15:20] <jdstrand> sounds like edge doesn't have the fix yet
[15:21] <jdstrand> refresh to stable and it should work again
[15:21] <ijohnson> cachio: where's the snapd vendor LP project we build core snap from edge again? I think core snap edge channel is behind a bit
[15:21] <jdstrand> https://github.com/snapcore/snapd/pull/8139 was merged two days ago. no idea why that wouldn't be in edge
[15:21] <mup> PR #8139: interfaces/{desktop-legacy,unity7}: adjust for new ibus socket location <Simple 😃> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8139>
[15:28] <cachio> ijohnson, it is because the issue I explained with spread-cron
[15:28] <ijohnson> cachio: ahhh right I remember you saying this in SU
[15:29] <cachio> ijohnson, the job to update the lp repo has been executed 30 minutes ago
[15:29] <cachio> ijohnson, so next core is gonna containd everythin
[15:30] <ijohnson> great, sounds good
[15:30] <cachio> ijohnson, this is the project in lp https://launchpad.net/snapd-vendor
[15:30] <ijohnson> cachio: thanks I should have just tried snapd-vendor :-)
[15:31] <cachio> :)
[15:32] <ijohnson> kenvandine: jdstrand: I added a note to the bug about needing to wait for the edge channel to be refreshed or needing to manually switch to stable channel to pick up the fix (counter-intuitively)
[15:32] <ijohnson> s/refreshed/updated/
[15:32] <kenvandine> is the fix in stable?
[15:33] <kenvandine> no...
[15:34] <ijohnson> no, but due to how re-exec works when the version of the core snap is less than the deb, snapd will not re-exec into the snap
[15:34] <ijohnson> the issue is that the edge channel has a higher version number than the deb, but is actually behind
[15:34]  * cachio lunch
[15:37] <mup> PR snapcraft#2946 opened: store: temprorarily remove support for progressive releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2946>
[15:40] <jdstrand> ijohnson: thanks!
[15:49] <zyga> jdstrand: good morning
[15:51] <ijohnson> pedronis: let's chat tomorrow if that's alright with you?
[15:52] <pedronis> ijohnson: ok
[15:58] <pedronis> zyga: does #8123 needs jdstrand to review it?
[15:58] <mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
[16:00] <zyga> Yes
[16:00] <zyga> But is has lower priority
[16:04] <pedronis> zyga: should we close 8113 ?
[16:04] <zyga> Checking
[16:05] <zyga> Yes but after a review from Jamie for comparison
[16:05] <zyga> I think it is really one review
[16:05] <zyga> And two ideas
[16:05] <pedronis> ok
[16:06] <pedronis> I request him on both them, is there enough context in them to know what to do?
[16:06] <pedronis> *I requested
[16:12] <pedronis> mvo: I made a slightly annoying comment on #8148
[16:12] <mup> PR #8148: overlord/configstate/configcore: add support for backlight service <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>
[16:14] <mvo> pedronis: interessting, I think it makes sense
[16:20] <mup> PR snapd#8117 closed: tests: add preseed test for classic <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8117>
[16:22] <zyga> pedronis: I think so, I also mentioned it to jamie a while ago but the priority is indeed lower than others
[16:22] <zyga> jdstrand: I think https://github.com/snapcore/snapd/pull/7825 is ready for a re-review
[16:22] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[16:22] <zyga> er
[16:22] <zyga> I meant https://github.com/snapcore/snapd/pull/7980
[16:22] <zyga> but the other one too
[16:22] <zyga> just in the opposite order
[16:22] <mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
[16:23] <zyga> don't you guys find it annoying
[16:23] <zyga> when you look at a PR comemnt
[16:23] <zyga> *comment
[16:23] <zyga> that out of the blue cannot be replied to
[16:23] <zyga> and it belongs to the same review
[16:23] <zyga> by the same person
[16:23] <zyga> and the code is not outdated
[16:23] <zyga> I mean
[16:23] <zyga> why
[16:23] <zyga> but then if I go to diff view
[16:24] <zyga> I can reply there
[16:24] <zyga> but I only see SOME comments there
[16:24] <zyga> *why*
[16:27] <pedronis> pstolowski: reviewed #8149, +1 with a question
[16:27] <mup> PR #8149: snapmgr, backends: maybe restart & security backend options <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8149>
[16:29] <pstolowski> pedronis: thanks, will check it
[16:38] <sdhd-sascha> mvo: update at the end ;-)
[16:38] <sdhd-sascha> https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930/17
[16:41] <sdhd-sascha> I didn't tested it yet, but it's a snap for `github action runner's`. For local building of github actions.
[16:42] <mvo> sdhd-sascha: woha, you made a snap from the runner? and even strictly confined it? that's nice
[16:43] <sdhd-sascha> mvo: next, i need to figure out the interfaces
[16:43] <sdhd-sascha> ...
[16:43]  * mvo nods
[16:44] <sdhd-sascha> hmm, hope until tomorrow, i will get it run
[16:45] <sdhd-sascha> mvo: it's seems to be `nodejs` stuff, with some `dotnet`. i will see
[16:49] <mvo> good luck!
[16:54] <pstolowski> pedronis: updated #8130, let me know if this is what you meant (i need to check if my the overlord/devicestate tests still make sense after this change, but state_test.go should be ok)
[16:54] <mup> PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130>
[16:56] <sdhd-sascha> mvo: after short thinking, should i change it to classic. I see no other chance :-(
[16:56] <sdhd-sascha> Then it's only on github and not on the store ...
[17:01] <mvo> sdhd-sascha: sometimes we make exceptions for classic snaps in the store, go for example
[17:07] <zyga> jdstrand: were you successful with SNAP_REEXEC=0
[17:08] <zyga> jdstrand: I must confess I was puzzled by your comment, everything looked godo
[17:08] <zyga> *good
[17:08] <zyga> jdstrand: but I was running this code on fedora and ubuntu many times
[17:08] <zyga> jdstrand: and there are tests that show it really operates
[17:08] <zyga> jdstrand: so ... I don't know
[17:08] <zyga> jdstrand: the last thing I want to change in that PR is the UUID pattern
[17:08] <zyga> jdstrand: but I would like to do it in a followup as it's an annoying change across this PR (in many places) and I would like to have a dedicated patch for that
[17:09] <jdstrand> I was in a meeting and doing follow ups after, so haven't look at it yet
[17:10] <zyga> jdstrand: ack, I'm looking at that rexec aspect now
[18:15] <mup> PR snapd#8150 opened: tests: ask tar to speak English <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8150>
[19:08] <mup> PR snapcraft#2946 closed: store: temprorarily remove support for progressive releases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2946>
[19:16] <zyga> stgraber: I think there's a small bug in the lxd snap meta-data that affects the configure hook
[19:16] <zyga> stgraber: the details are in the last two comments of https://bugs.launchpad.net/snapd/+bug/1863772
[19:16] <mup> Bug #1863772: apparmor missing read permission for /var/lib/snapd/hostfs/usr/lib/os-release <snapd:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1863772>
[19:17] <zyga> stgraber: do you want me to add an lxd task or mirror it elsewhere?
[19:18] <stgraber> zyga: the lxd-support interface wouldn't do any good
[19:18] <jdstrand> zyga: hey, sorry had some internet woes. did you reproduce? I tried again and explecitly disabled reexec. I am still not seeing what I expect
[19:18] <stgraber> zyga: all that interface does is allow the use of aa-exec which we're not using in the hook
[19:19] <stgraber> zyga: for that matter, the hook also never attempts to access os-release
[19:20]  * jdstrand notes in the denial: comm="snapctl"
[19:20] <zyga> stgraber: that interface allows for access to that file
[19:21] <zyga> stgraber: (I specifically looked at the denial, if there's more I didn't see that)
[19:21] <jdstrand> I think stgraber is saying that before the update, snapctl didn't need the access. now it does
[19:21] <zyga> jdstrand: it's the configure hook, I don't understand why snapctl would reach out to /var/lib/snapd/hostfs but perhaps my memory is rusty and it does
[19:21] <zyga> jdstrand: interesting
[19:21] <zyga> maybe something bigger broke
[19:22] <stgraber> zyga: oh, you're right that someone added os-release to lxd-support, no idea why that was done though :)
[19:22] <zyga> stgraber: I can git blame...
[19:22] <stgraber> zyga: we never access os-release prior to calling aa-exec, so it feels wrong for the interface to allow something we shouldn't need
[19:22] <jdstrand>     audit: type=1400 audit(1510219691.912:133): apparmor="DENIED" operation="open"
[19:22] <stgraber> zyga: if snapd itself requires it somehow, then it would feel more appropriate for this to be somewhere else :)
[19:22] <jdstrand>            profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=29008
[19:22] <jdstrand>            comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[19:23] <jdstrand> Maciej said he added that to the interface to fix snap-exec ^
[19:23] <stgraber> zyga: 7beabf5b9f back in 2017, doesn't give a lot of context though
[19:23] <zyga> https://github.com/snapcore/snapd/commit/7beabf5b9f5f7062e9630325b30f52ccf4448410
[19:23] <zyga> yeah
[19:23] <stgraber> zyga: it's effectively attempting to fix snap-exec which had the same issue as snapctl
[19:23] <zyga> so it's certainly not new
[19:23] <zyga> and the comm is different
[19:23] <zyga> snap-exec
[19:23] <zyga> weir
[19:23] <zyga> *weird
[19:23] <pedronis> we have code to read os-release in release
[19:24] <pedronis> so I expect it can crop easily anywhere
[19:24] <zyga> pedronis: but we don't read it via hostfs, do we?
[19:24] <stgraber> yeah, still feels wrong to dump that in the lxd-support interface but I guess I can add that interface to the hook for now to silence things :)
[19:24] <zyga> pedronis: don't read it via hostfs (I checked now)
[19:24] <jdstrand> stgraber: is it just noise?
[19:24] <stgraber> jdstrand: yeah
[19:24] <pedronis> we don't use hostfs a lot
[19:24] <zyga> jdstrand: perhaps not, we're debugging an issue that showed up just now in snappy-internal
[19:25] <zyga> jdstrand: maybe something did break
[19:25] <zyga> I think this is noise but the question is, why now?
[19:25] <stgraber> might just be that nobody noticed :)
[19:25] <stgraber> lxd hosts are full of apparmor noise already
[19:25] <pedronis> zyga: no, not via hostfs
[19:26] <jdstrand> stgraber: use system-observe instead if you're working around
[19:26] <jdstrand> way less privilege :)
[19:26] <stgraber> I think I know where the hostfs thing comes from, it's because the configure hook is run within the LXD mntns which has its own copy of /etc with a weird layout. snapctl then just looks at /etc/os-release and hits a symlink to the host path
[19:26] <zyga> ah!
[19:26] <stgraber> jdstrand: ah yeah, sounds a bit less crazy indeed
[19:27] <zyga> that explains it
[19:27] <zyga> stgraber: can you paste that line into the bug
[19:27] <zyga> you just saved me some debug time :)
[19:27] <zyga> so it's all understood now and we can just silence that, I think
[19:27] <jdstrand> ok, cool
[19:56] <zyga> ijohnson: snapd-failover failed
[19:56] <zyga> https://www.irccloud.com/pastebin/T22XZ91h/
[19:57] <zyga> there's more debug
[19:57] <ijohnson> zyga: well that's sad
[19:57] <zyga> https://www.irccloud.com/pastebin/sb9D5gYY/
[19:58] <ijohnson> zyga: is that all of the debug ? seems cut off at the end
[19:58] <zyga> there's more
[19:58] <zyga> but lots of repeats
[19:58] <zyga> https://api.travis-ci.org/v3/job/652108951/log.txt
[19:58] <zyga> then some more
[19:58] <ijohnson> thanks I was jsut gonna ask for the travis log
[19:58] <zyga> perhaps you can make heads and tails out of that
[19:58] <zyga> I don't see anything about snapd-failure.service
[19:58] <ijohnson> yes I've seen this before but haven't been able to fully debug it
[19:59] <ijohnson> I thought that mborzecki's change from a couple days ago would have helped this
[19:59] <ijohnson> which PR is this ?
[19:59] <zyga> ijohnson: it failed on a PR that has one liner change in totally unrelated place
[19:59] <zyga> https://github.com/snapcore/snapd/pull/8150
[19:59] <ijohnson> but was that PR based off of master or an older commit ?
[19:59] <mup> PR #8150: tests: ask tar to speak English <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8150>
[19:59] <zyga> ijohnson: master
[19:59] <zyga> I just made it
[19:59] <zyga> I _think_
[19:59]  * zyga checks
[19:59] <ijohnson> ah I see it
[20:00] <ijohnson> yeah looks like it was on top of master
[20:00] <zyga> yeah
[20:02] <ijohnson> thanks for point it out to me, but this log is the same as one I have saved locally so you can restart the job if you like
[20:02] <ijohnson> *pointing
[20:20] <mup> PR snapcraft#2947 opened: remote-build: pass through 'source-subdir' property <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2947>
[21:43]  * cachio afk
[23:53] <mup> PR snapd#8151 opened: cmd/snap-bootstrap/initramfs-mounts: only write modeenv if it changed <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8151>