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

=== heather is now known as hellsworth
mborzeckimorning06:13
mborzeckischool run, back in 3006:34
mborzeckire07:08
mborzeckimvo: hey!07:08
mvohey mborzecki ! good morning07:11
mvomborzecki: 8146 and 8144 are easy wins I think07:12
dokothe chromium snap and others don't accept keyboard input anymore in focal. is this known, or where should this be reported?07:14
mborzeckidoko: afaik it's fixed in master, and mvo uploaded a patched snapd to ubuntu07:17
mvodoko: upload should already be in focal, I think I got the focal-proposed -> focal mail last night07:20
dokoahh, ok, a reload helped07:20
mupPR 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:23
mupPR 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:35
mvomborzecki: \o/07:37
pstolowskimorning08:09
mvohey pstolowski - good morning08:12
mborzeckipstolowski: hey08:20
zygagood morning08:23
zygasorry for a late start08:23
zygalet's get to work!08:23
pstolowskihey zyga08:32
zygahey :-)08:32
mupPR snapd#8148 opened: overlord/configstate/configcore: add support for backlight service <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>08:50
sdhd-saschahello08:57
mvosdhd-sascha: good morning!09:27
sdhd-saschamvo: :-)09:27
zygahey sdhd-sascha :)09:28
* zyga munges breakfast while catching up on email09:28
sdhd-saschaI just started to add some variables to the build-action. So every repo on github can configure, if the action should run...09:28
sdhd-saschaI use `github secrets` for variables...09:29
zygaoh boy, I have 342 bugs in fedora on selinux denials09:30
zygaand it's my bug triage day09:30
* zyga cries a little09:30
mborzeckizyga: some of those are probably fixed09:35
mborzeckisome are probably caused by anaware users :/09:36
mborzeckis/anaware/unaware/ ofc09:37
mupPR 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:39
zygamborzecki: yeah but which09:47
zygamborzecki: I'll try to do something smart about them09:47
pedronismborzecki: hi, did you see that #6708 failed on a some task.yaml formatting issue?10:04
mupPR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>10:04
zygapedronis: fixed10:06
zygapedronis: it's funny because maciek added the checks :)10:06
mborzeckipedronis: thanks for spotting, spread-shellcheck didn't complain but i obviously forgot about the multiline check :/10:06
mborzeckizyga: heh, yeah the irony of it :P10:06
mborzeckihm maybe this should become part of spread-shellcheck at some point10:07
pedronisit failed somewhere in the static checks afaict10:07
zygapedronis: it failed on lack of | in prepare10:08
mborzeckipedronis: it complained about `tests/main/buildmode-pie/task.yaml:9:prepare:` not bneing `prepare: |`10:08
zygatechnically it is parsing but not as people expected10:08
pedronis#8003, #8078 and #8101 need reviews or 2nd reviews (they should all be close to landable)10:30
mupPR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>10:30
mupPR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>10:30
mupPR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>10:30
zygapedronis: I'll look at 8003 after going through new bugs10:31
zygaI can look at the rest as well though 8078 can probably be merged10:32
zygaI see there's one change since my last review10:32
zygaI'll read it and probably approve10:32
zygapedronis: let's land 807810:33
zygathank you for pushing this forward!10:33
pedronisthx10:34
pstolowskidoh, getting something green on travis seems very hard again10:36
zygahttps://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/263 is interesting to read10:36
sdhd-saschaI just added some `secrets` to control the github-action-workflow10:37
sdhd-saschamvo: any idea to make the github-action more usable ?10:38
mvosdhd-sascha: is it trivial to run unit tests in it?10:41
sdhd-saschamvo: i think it's possible. If you look at jhenstridge github action. It's super readable typescript10:43
sdhd-saschaAnd you can run, any shell script ...10:43
mvosdhd-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 myself10:45
sdhd-saschamvo: true. I also added upload to the store. As i have said, i need for classic-snap's, because of the approval10:47
mupPR snapd#8078 closed: daemon: support resuming downloads <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8078>10:47
sdhd-saschamvo: i have to install a github-runner locally, to better understand how it works internal10:49
mvosdhd-sascha: upload to the store> interessting10:57
mvosdhd-sascha: keep me updated please, it sure looks like fun :)10:57
* mvo really hopes it is10:57
sdhd-saschamvo: i too :-)11:01
pstolowskipedronis: ok to land https://github.com/snapcore/snapd/pull/8046 ? i pushed small changes to the spread test for focal. and it's finally green11:12
mupPR #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:12
pedronispstolowski: do we understand why prepare is different?11:14
pstolowskipedronis: yes and no, we understand that qemu-nbd gets stuck if it's part of prepare. i reorganized the test to do this in execute11:14
pedronisbut we don't know why it gets stuck?11:14
pstolowskipedronis: yep, we don't11:15
pedronisok11:16
pstolowskipedronis: i can try to investigate and maybe have a followup; fwtw it's unrelated to the functionality and what we're testing11:16
pedronispstolowski: anyway it is fine to land,  we don't have the same problem in restore, right?11:16
pstolowskipedronis: no11:16
pstolowskithanks11:17
* pedronis lunch11:17
mupPR 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:18
mupPR snapd#8149 opened: snapmgr, backends: maybe restart & security backend options <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8149>11:21
sdhd-saschamvo: did you know, that it is possible to run services on github: https://github.com/actions/example-services11:37
zygaoh11:37
zygathat's ... interesting!11:37
sdhd-sascha:-)11:39
ograwell ... https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/1493011:40
ogra;)11:40
mvosdhd-sascha: I had no idea11:44
pedronispstolowski: I re-reviewed #8130, the logic is not quite what I expected12:09
mupPR #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:09
pstolowskioh12:11
pstolowskipedronis: ok, thanks12:12
pstolowskii must have misunderstood the details12:12
mborzeckiijohnson: mvo: cmatsuoka: a little script for repacking the kernel snap with changes to initramfs https://gist.github.com/bboozzoo/010ed5e94ee0f695d1aeece43513a01812:12
pedronispstolowski: the change is not big, anyway see my comment there12:13
pedronisbut the tests will need adjusting too12:13
cmatsuokamborzecki: ah thanks, it's nicer than the one I'm currently using12:14
mvomborzecki: woah, nice!12:18
* pstolowski lunch12:29
zygaondra, ogra, plars: hey guys13:38
zygaI tried reproducing https://bugs.launchpad.net/snapd/+bug/184639713:38
zyga(perhals sil2100 ^ as well as you were in the bug)13:38
mupBug #1846397: snapdragon uc18 image fails to boot (current stable) <snapd:In Progress by ondrak> <https://launchpad.net/bugs/1846397>13:38
zygacan you guys tell me that we successfully test-boot current core18 images on the dragon board?13:38
zygaI'll try the release image to double check13:39
cwaynezyga: that bug should be marked as fixed13:42
zygacwayne: can you mark it as such with a comment please13:42
cwaynedone13:43
zygacwayne: hmm, given that you are here, do you remember if there's anything special that is needed to boot that board?13:44
zygaI wonder why I cannot get ubuntu core on it13:44
zyga(as my last message in the bug indicated)13:45
cwaynewas that with the latest stable?13:45
zygaI tried the release image we advertise on the website13:45
zygahttps://ubuntu.com/download/qualcomm-dragonboard-410c13:45
zygahttp://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ubuntu-core-18-arm64+snapdragon.img.xz13:45
zygabut I suspect the image may be correct - I don't think I actually even attempted to boot it for some reason13:46
zygaI have the card inserted now and I'm running some old debian from linaro13:46
zygaI can poke around the SD13:46
cwaynezyga: 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
zygayeah, I set those up13:47
zygacould be a wonky card, I'll try with another one13:47
zygayeah13:50
zygawerd13:50
zygaweird13:50
zygathe card works but would not boot13:50
zygaI used another and boom,13:50
zygait's okay13:50
cwaynephew, you scared me there zyga13:50
zygaI'll make sure it works past registrationa13:51
zygaand that I can refresh13:51
zygaand adjust the bug13:51
cwaynealso it wasnt really appropriately logged, IIRC it was an issue with the gadget not snapd at all13:51
zygayeah, that's common, snapd is the catch-all-project13:52
cwayneah right, fair enough13:52
ograwasnt there some switch on the db410 that you need to flick to have it boot from SD?13:52
ogra(i havent touched any dragonboard in probably 1.5y)13:53
cwayneneither has anyone else lol13:53
cwayneogra: it turned out to be a bad sd card13:53
ograin general ondra is our qualcomm guy though13:53
zygaheeey13:53
ograhaha13:53
zygalook at what I got13:53
zygaPress enter to configure.13:53
zyga:D13:53
zygathat's a small wonder there13:53
zygaI'm in13:54
ijohnsonmorning folks13:55
cwayneImagining you saying that like a hacker in a movie13:55
cwayneGUYS IM IN13:55
* ijohnson almost got crushed by a car this morning13:56
zygaijohnson: good morning, are you okay? what happened?13:56
zygacwayne: that's unix, I know this13:56
zygacwayne: AWW SNAP13:56
* zyga googles how to work with snaps on stackoverflow13:56
ijohnsonyeah I'm fine, just very icy outside and an SUV couldn't stop at a stop sign and so slid through the intersection13:56
ijohnsongreat way to end yoga though13:57
plarszyga: 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 snap13:57
cwayneGotta re-tense after yoga13:57
zygaijohnson: ouch13:57
ijohnsoncwayne: exactly13:57
zygais it common to use chains on icy days?13:57
ijohnsonno not in the cityu13:57
zygaplars: confirmed, it's all good13:57
ijohnsonyou just wait for the city to put ice down, or you drive carefully :-)13:57
* cwayne has never used snow chains13:57
cwayneOr snow tires13:58
zygaplars: I see, do you know what is the problem with the gadget snap?13:58
ijohnsonmy grandpa showed me how to put them on, but I have never used them and don't own any13:58
roadmrcwayne: aren't winter tires mandatory in your neck of the woods, in winter?13:58
cwayneNah13:58
ogracwayne, didnt you grow up in new hampshire ?13:58
cwayneHeavily suggested13:58
cwayneogra: Massachusetts :)13:58
ograwell, close13:58
cwayneTook my driving test in a blizzard13:58
ograhow can you never have used snow tires there13:58
ijohnsonit used to be mandatory where my grandpa lives in rural wisconsin because the roads were plowed so infrequently13:59
plarszyga: I believe it was a u-boot issue - some new bug that came with it getting updated13:59
ograit definitely is in germany ...13:59
zygaplars: I see, another bug for another time13:59
* zyga is reviewing in-progress bugs13:59
ijohnsontime to SU13:59
kenvandinezyga: i'm still seeing this ibus/snapd issue in focal with all the updates installed14:27
kenvandinezyga: wiping ~/snap/irccloud-desktop/common/.cache fixed it for irccloud-desktop14:27
kenvandinebut not for other snaps14:27
kenvandineall very weird14:28
zygakenvandine: uh, weird, do you know how ibus works enough to debug this?14:28
zygaI'm essentially green14:28
zygado you see any more denials?14:28
kenvandineno idea14:28
kenvandineFeb 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
kenvandinei think oSoMoN understands it14:28
zygaI'll go and grab some food now14:38
zygasee you guys later :)14:38
sil2100zyga: hey!14:39
sil2100zyga: commented on the bug o/14:39
sil2100So once you're back, have a look :)14:40
mupPR core18#147 closed: Add bash-completion support <Created by xnox> <Merged by sil2100> <https://github.com/snapcore/core18/pull/147>14:49
ijohnsonkenvandine: 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 that15:09
kenvandineijohnson: interesting15:09
kenvandinethe fix seems to have worked for some snaps15:09
ijohnsonkenvandine: it might be possible that the fix from jdstrand hasn't made it to edge yet somehow15:10
kenvandinei haven't really figured anything out though15:10
ijohnsonkenvandine: the snap I immediately noticed the problem with was irccloud15:10
kenvandineme too15:10
kenvandinefirefox and chromium are working for me now too15:10
kenvandinebut gedit isn't15:10
ijohnsonis gedit a snap now?15:13
* ijohnson still has gedit from deb pkg on focal15:13
jdstrandijohnson, kenvandine: the snapd in focal has the fix15:14
ijohnsonjdstrand: the deb ? why doesn't the edge snap have the fix ?15:14
kenvandinejdstrand: it should... and it's working for some snaps15:14
jdstrandijohnson: the deb yes. I don't know about edge if it doesn't15:15
kenvandinejdstrand: i had to wipe ~/snap/chromium/common/.cache to get chromium to work15:15
kenvandinegedit is still seeing denials15:15
kenvandinei have avoided wiping the cache to keep the test case around15:15
* ijohnson tries snapd from deb pkg w/irccloud again, brb15:16
jdstrandkenvandine: you are still talking about ibus?15:16
kenvandinejdstrand: yes15:17
jdstrandkenvandine: I think all you need to do is make sure all the chromium processes are gone15:17
jdstrandkenvandine: that is all I had to do with firefox and chromium15:17
jdstrandand gedit works fine15:17
kenvandinethat could have been the case there15:17
kenvandinegedit is still a problem for me15:17
kenvandineFeb 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:17
jdstrandkenvandine: can you paste /var/lib/snapd/apparmor/profiles/snap.gedit.gedit ?15:18
ijohnsonhmm the deb seems to work w/ irccloud and the gedit snap now for me, with re-exec disabled15:19
ijohnsontrying with re-exec enabled15:19
kenvandinejdstrand: https://paste.ubuntu.com/p/xwBCYrr6Yt/15:19
* jdstrand notes he has the stable core, so the deb comes up as newer15:19
jdstrandkenvandine: yeah, that doesn't have the new rule15:20
jdstrandkenvandine: what is the output of snap version?15:20
ijohnsonjdstrand: yeah with edge core snap and re-exec enabled I can't type now again15:20
kenvandinehttps://paste.ubuntu.com/p/qFdSkXvpq2/15:20
kenvandineyeah, i have core from edge15:20
jdstrandsounds like edge doesn't have the fix yet15:20
jdstrandrefresh to stable and it should work again15:21
ijohnsoncachio: where's the snapd vendor LP project we build core snap from edge again? I think core snap edge channel is behind a bit15:21
jdstrandhttps://github.com/snapcore/snapd/pull/8139 was merged two days ago. no idea why that wouldn't be in edge15:21
mupPR #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:21
cachioijohnson, it is because the issue I explained with spread-cron15:28
ijohnsoncachio: ahhh right I remember you saying this in SU15:28
cachioijohnson, the job to update the lp repo has been executed 30 minutes ago15:29
cachioijohnson, so next core is gonna containd everythin15:29
ijohnsongreat, sounds good15:30
cachioijohnson, this is the project in lp https://launchpad.net/snapd-vendor15:30
ijohnsoncachio: thanks I should have just tried snapd-vendor :-)15:30
cachio:)15:31
ijohnsonkenvandine: 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
ijohnsons/refreshed/updated/15:32
kenvandineis the fix in stable?15:32
kenvandineno...15:33
ijohnsonno, 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 snap15:34
ijohnsonthe issue is that the edge channel has a higher version number than the deb, but is actually behind15:34
* cachio lunch15:34
mupPR snapcraft#2946 opened: store: temprorarily remove support for progressive releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2946>15:37
jdstrandijohnson: thanks!15:40
zygajdstrand: good morning15:49
ijohnsonpedronis: let's chat tomorrow if that's alright with you?15:51
pedronisijohnson: ok15:52
pedroniszyga: does #8123 needs jdstrand to review it?15:58
mupPR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>15:58
zygaYes16:00
zygaBut is has lower priority16:00
pedroniszyga: should we close 8113 ?16:04
zygaChecking16:04
zygaYes but after a review from Jamie for comparison16:05
zygaI think it is really one review16:05
zygaAnd two ideas16:05
pedronisok16:05
pedronisI request him on both them, is there enough context in them to know what to do?16:06
pedronis*I requested16:06
pedronismvo: I made a slightly annoying comment on #814816:12
mupPR #8148: overlord/configstate/configcore: add support for backlight service <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>16:12
mvopedronis: interessting, I think it makes sense16:14
mupPR snapd#8117 closed: tests: add preseed test for classic <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8117>16:20
zygapedronis: I think so, I also mentioned it to jamie a while ago but the priority is indeed lower than others16:22
zygajdstrand: I think https://github.com/snapcore/snapd/pull/7825 is ready for a re-review16:22
mupPR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>16:22
zygaer16:22
zygaI meant https://github.com/snapcore/snapd/pull/798016:22
zygabut the other one too16:22
zygajust in the opposite order16:22
mupPR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>16:22
zygadon't you guys find it annoying16:23
zygawhen you look at a PR comemnt16:23
zyga*comment16:23
zygathat out of the blue cannot be replied to16:23
zygaand it belongs to the same review16:23
zygaby the same person16:23
zygaand the code is not outdated16:23
zygaI mean16:23
zygawhy16:23
zygabut then if I go to diff view16:23
zygaI can reply there16:24
zygabut I only see SOME comments there16:24
zyga*why*16:24
pedronispstolowski: reviewed #8149, +1 with a question16:27
mupPR #8149: snapmgr, backends: maybe restart & security backend options <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8149>16:27
pstolowskipedronis: thanks, will check it16:29
sdhd-saschamvo: update at the end ;-)16:38
sdhd-saschahttps://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930/1716:38
sdhd-saschaI didn't tested it yet, but it's a snap for `github action runner's`. For local building of github actions.16:41
mvosdhd-sascha: woha, you made a snap from the runner? and even strictly confined it? that's nice16:42
sdhd-saschamvo: next, i need to figure out the interfaces16:43
sdhd-sascha...16:43
* mvo nods16:43
sdhd-saschahmm, hope until tomorrow, i will get it run16:44
sdhd-saschamvo: it's seems to be `nodejs` stuff, with some `dotnet`. i will see16:45
mvogood luck!16:49
pstolowskipedronis: 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
mupPR #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:54
sdhd-saschamvo: after short thinking, should i change it to classic. I see no other chance :-(16:56
sdhd-saschaThen it's only on github and not on the store ...16:56
mvosdhd-sascha: sometimes we make exceptions for classic snaps in the store, go for example17:01
zygajdstrand: were you successful with SNAP_REEXEC=017:07
zygajdstrand: I must confess I was puzzled by your comment, everything looked godo17:08
zyga*good17:08
zygajdstrand: but I was running this code on fedora and ubuntu many times17:08
zygajdstrand: and there are tests that show it really operates17:08
zygajdstrand: so ... I don't know17:08
zygajdstrand: the last thing I want to change in that PR is the UUID pattern17:08
zygajdstrand: 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 that17:08
jdstrandI was in a meeting and doing follow ups after, so haven't look at it yet17:09
zygajdstrand: ack, I'm looking at that rexec aspect now17:10
mupPR snapd#8150 opened: tests: ask tar to speak English <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8150>18:15
mupPR snapcraft#2946 closed: store: temprorarily remove support for progressive releases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2946>19:08
zygastgraber: I think there's a small bug in the lxd snap meta-data that affects the configure hook19:16
zygastgraber: the details are in the last two comments of https://bugs.launchpad.net/snapd/+bug/186377219:16
mupBug #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:16
zygastgraber: do you want me to add an lxd task or mirror it elsewhere?19:17
stgraberzyga: the lxd-support interface wouldn't do any good19:18
jdstrandzyga: hey, sorry had some internet woes. did you reproduce? I tried again and explecitly disabled reexec. I am still not seeing what I expect19:18
stgraberzyga: all that interface does is allow the use of aa-exec which we're not using in the hook19:18
stgraberzyga: for that matter, the hook also never attempts to access os-release19:19
* jdstrand notes in the denial: comm="snapctl"19:20
zygastgraber: that interface allows for access to that file19:20
zygastgraber: (I specifically looked at the denial, if there's more I didn't see that)19:21
jdstrandI think stgraber is saying that before the update, snapctl didn't need the access. now it does19:21
zygajdstrand: 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 does19:21
zygajdstrand: interesting19:21
zygamaybe something bigger broke19:21
stgraberzyga: oh, you're right that someone added os-release to lxd-support, no idea why that was done though :)19:22
zygastgraber: I can git blame...19:22
stgraberzyga: we never access os-release prior to calling aa-exec, so it feels wrong for the interface to allow something we shouldn't need19:22
jdstrand    audit: type=1400 audit(1510219691.912:133): apparmor="DENIED" operation="open"19:22
stgraberzyga: 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=2900819:22
jdstrand           comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=019:22
jdstrandMaciej said he added that to the interface to fix snap-exec ^19:23
stgraberzyga: 7beabf5b9f back in 2017, doesn't give a lot of context though19:23
zygahttps://github.com/snapcore/snapd/commit/7beabf5b9f5f7062e9630325b30f52ccf444841019:23
zygayeah19:23
stgraberzyga: it's effectively attempting to fix snap-exec which had the same issue as snapctl19:23
zygaso it's certainly not new19:23
zygaand the comm is different19:23
zygasnap-exec19:23
zygaweir19:23
zyga*weird19:23
pedroniswe have code to read os-release in release19:23
pedronisso I expect it can crop easily anywhere19:24
zygapedronis: but we don't read it via hostfs, do we?19:24
stgraberyeah, 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
zygapedronis: don't read it via hostfs (I checked now)19:24
jdstrandstgraber: is it just noise?19:24
stgraberjdstrand: yeah19:24
pedroniswe don't use hostfs a lot19:24
zygajdstrand: perhaps not, we're debugging an issue that showed up just now in snappy-internal19:24
zygajdstrand: maybe something did break19:25
zygaI think this is noise but the question is, why now?19:25
stgrabermight just be that nobody noticed :)19:25
stgraberlxd hosts are full of apparmor noise already19:25
pedroniszyga: no, not via hostfs19:25
jdstrandstgraber: use system-observe instead if you're working around19:26
jdstrandway less privilege :)19:26
stgraberI 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 path19:26
zygaah!19:26
stgraberjdstrand: ah yeah, sounds a bit less crazy indeed19:26
zygathat explains it19:27
zygastgraber: can you paste that line into the bug19:27
zygayou just saved me some debug time :)19:27
zygaso it's all understood now and we can just silence that, I think19:27
jdstrandok, cool19:27
=== jdstrand_ is now known as jdstrand
zygaijohnson: snapd-failover failed19:56
zygahttps://www.irccloud.com/pastebin/T22XZ91h/19:56
zygathere's more debug19:57
ijohnsonzyga: well that's sad19:57
zygahttps://www.irccloud.com/pastebin/sb9D5gYY/19:57
ijohnsonzyga: is that all of the debug ? seems cut off at the end19:58
zygathere's more19:58
zygabut lots of repeats19:58
zygahttps://api.travis-ci.org/v3/job/652108951/log.txt19:58
zygathen some more19:58
ijohnsonthanks I was jsut gonna ask for the travis log19:58
zygaperhaps you can make heads and tails out of that19:58
zygaI don't see anything about snapd-failure.service19:58
ijohnsonyes I've seen this before but haven't been able to fully debug it19:58
ijohnsonI thought that mborzecki's change from a couple days ago would have helped this19:59
ijohnsonwhich PR is this ?19:59
zygaijohnson: it failed on a PR that has one liner change in totally unrelated place19:59
zygahttps://github.com/snapcore/snapd/pull/815019:59
ijohnsonbut was that PR based off of master or an older commit ?19:59
mupPR #8150: tests: ask tar to speak English <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8150>19:59
zygaijohnson: master19:59
zygaI just made it19:59
zygaI _think_19:59
* zyga checks19:59
ijohnsonah I see it19:59
ijohnsonyeah looks like it was on top of master20:00
zygayeah20:00
ijohnsonthanks 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 like20:02
ijohnson*pointing20:02
mupPR snapcraft#2947 opened: remote-build: pass through 'source-subdir' property <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2947>20:20
* cachio afk21:43
mupPR 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>23:53

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