/srv/irclogs.ubuntu.com/2018/10/15/#snappy.txt

=== cpaelzer_ is now known as cpaelzer
mborzeckimorning05:11
mborzeckimvo: hey05:57
mvohey mborzecki - good morning05:58
mborzeckimvo: when's the release?05:59
mvomborzecki: 2.36~pre2 happend last friday but it looks like we need a 2.35.5 :/06:01
mvomborzecki: why? anything important pending?06:01
mborzeckimvo: no, just checking if we could squeeze in https://github.com/snapcore/snapd/pull/597906:03
mupPR #5979: install: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5979>06:03
mvomborzecki: mark it for 2.36 please06:03
mvomborzecki: and alsp please mark for squash merge to merge the cherry-pick/pr easier06:03
mborzeckimvo: marked06:04
mupPR snapd#5983 opened: interfaces/home: don't allow snaps to write to $HOME/bin (2.35) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5983>06:05
mvomborzecki: ta06:06
mvozyga: 5974 has some comment improvement suggestions, could you do a followup with those? I will merge and pull into 2.35 so that things move here06:07
mupPR snapd#5974 closed: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5974>06:07
mvozyga: in case you didn't already, not sure if all points where addressed06:07
mvomborzecki: jdstrand pushed a bunch of PRs that look important but he did not attach a milestone - do you happen to know what he needs? I tagged them as 2.3606:25
mvomborzecki: but I'm not sure if we might even pull things into 2.35 (cc zyga)06:25
mborzeckimvo: i recall the one about scrubbing env on profile change, i see it's tagged for 2.3606:27
=== chihchun_afk is now known as chihchun
zygare07:13
zygagood morning07:13
zygasorry for starting late, very very rough night07:13
zygamvo: looking at 597407:13
zygaah that, I need to digest those as, as we were discussing in on IRC, we were also talking in the pull request07:14
zygamvo: I believe all the code there is correct, we can tweak the comment07:15
zygamvo: I will look at Jamie's pr's now07:15
zygajdrab: https://github.com/snapcore/snapd/pull/5982 this one is very important07:15
mupPR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>07:15
mupPR snapd#5983 closed: interfaces/home: don't allow snaps to write to $HOME/bin (2.35) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5983>07:17
zygathe k8s pull requests are something I was not tracking so I cannot asses those07:17
=== pstolowski|afk is now known as pstolowski
pstolowskimornings07:18
mvozyga: thanks07:18
mborzeckizyga: pstolowski: hey07:20
zygathe unsafe PR is holly smokes long :)07:20
zygamvo: I left some comments on https://github.com/snapcore/snapd/pull/5980#pullrequestreview-164581442 - I suspect we should rename the fields/methods to match go naming scheme but otherwise this is a very welcome improvement07:51
mupPR #5980: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5980>07:51
zygamvo: please let me know if you want to see those extra changes as additional patches in this PR directly or as a separate PR07:51
mvozyga: ta, I have a look in a wee bit07:52
zygaBritish English wee bit :)07:52
mvozyga: I don't know :) the wee as in little07:53
zygaexactly07:53
zygathat's what I meant :)07:53
mvoare there more meanings than this one?07:53
zyganot that I know of, I meant that it is specific to British English as a way to say little07:54
sparkiegeekhttps://en.wiktionary.org/wiki/wee#Adjective https://en.wiktionary.org/wiki/wee#Noun07:54
sparkiegeekoh, I meant to link to Etymology 207:54
zygalol07:55
zygathat's new :)07:55
zygaTIL wee things matter07:55
zygapstolowski: is 5975 something we can land for 2.36?07:58
zygait's +2 green right now07:58
pstolowskizyga: we could yes, but mvo wanted to have a look i think07:59
* zyga looks at k8s pull request07:59
zygamvo: I would vote +1 on that since it makes everyday "snap tasks" much more understandable and accurate07:59
zygamvo: but please do see it before merging07:59
pstolowski(let's squash merge then if we do)08:00
zygasure, please set a tag there08:00
mvozyga: yeah, I think its good, looking now (sorry, just had to finish the classic dimension forum post before it escapes my mind again :)08:04
zygacool, thank you for doing that - I will gladly read it soon08:04
Chipacagood morning08:06
zygagood morning sir08:07
Chipacazyga: are we there yet?08:09
zygano, not quite08:10
Chipacaaww08:10
mvopstolowski: 5975 looks great, please go ahead and squash merge it so that we can backport to 2.3608:23
pstolowskimvo: great, ty!08:23
mvozyga: anything else we might need for 2.35.5 ? if not I will go ahead with this soon08:24
zygamvo: I don't know of anything else but let me look at the full list of PRs08:29
mupPR snapd#5975 closed: ifacestate/hooks: only create interface hook tasks if hooks exist <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5975>08:35
=== chihchun is now known as chihchun_afk
pstolowskimvo: merged, shall i prepare PR for 2.36?08:40
mvopstolowski: please do08:40
pstolowskisure08:40
mvopstolowski: thank you08:40
zygamvo: perhaps a subset of https://github.com/snapcore/snapd/pull/5696/files08:42
mupPR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>08:42
zygawhere we have the extra directory but not the part that jdstrand pointed out (the mknod perm)08:42
zygamvo: otherwise nothing else I see for 3.35.x08:43
mupPR snapd#5984 opened: ifacestate/hooks: only create interface hook tasks if hooks exist (2.36) <Created by stolowski> <https://github.com/snapcore/snapd/pull/5984>08:46
=== chihchun_afk is now known as chihchun
mvozyga: thanks for double checking. I looked at 5980, it looks good, I agree with your comments about naming conventions though08:51
zygaI can push a patch to change it there and in the other PRs that are built on it08:51
pstolowskimvo, zyga ^ pr for 2.36 is up08:52
mborzeckipstolowski: did a pass on #596208:52
mupPR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>08:52
mvopstolowski: cool, thanks08:52
mborzeckiheh github, if you search with query https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%F0%9F%94%8C (using the hotplug emoji) it finds no PRs08:54
pstolowskimborzecki: thanks!08:55
pstolowskimborzecki: +1 for #5966, with one remaks (perhaps degville can help again)09:07
mupPR #5966: snap: overhaul validation error messages <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5966>09:07
niemeyerYeah, the emojis are funny, but we should probably drop them09:10
niemeyerMorning all09:10
mvogood morning niemeyer09:11
niemeyermvo: Yo09:12
Chipacamborzecki: does searching by the contents of a tag find things? (doesn't work with 'complex' either)09:12
mborzeckiChipaca: probably not, seems like freetext search ignores labels09:13
mvoChipaca: a while ago you looked into uc16 to ensure things cleanly unmount on stop/reboot, do you think you could you do the same for uc18 again?09:20
Chipacamvo: I think I probably could :-) do you know it doesn't?09:21
mvoppisati: did you had any luck getting to the bottom of the 4.15 pi3 b+ ethernet connection issues?09:21
mvoChipaca: I suspect it might be :/09:21
Chipacamvo: ok. Is there a working intel core18 i could look at?09:22
mvoChipaca: http://people.canonical.com/~mvo/core18/09:22
mvoChipaca: so http://people.canonical.com/~mvo/core18/core18-amd64-18-beta20180823.img.xz09:22
Chipacathanks09:22
mvoChipaca: should work, please do let me know if you notice anything09:22
mvoChipaca: thank *you*09:23
pstolowskimvo: i think #5969 needs master merged, the base PR already landed09:24
mupPR #5969:  apparmor: add unit test for probeAppArmorParser and simplify code  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5969>09:24
mvopstolowski: thanks, done09:25
pstolowskithx09:27
ppisatimvo: the fix is already queued in bionic09:28
mvoppisati: \o/09:29
mvoppisati: great to hear, do you have a rough eta for the snap? I guess its too much work to just do an edge build of the pi-kernel (?)09:29
ppisatimvo: as soon as the new SRU kernel is released - IIRC they cut a new kernel tomorrow, then it's 2 weeks after that09:32
ppisatimvo: but there was a respin of kernels last week, so the window might have slide a bit09:32
ppisati*slid09:34
mvoppisati: ok. I wish we had git snapshots in the edge channel :) but I guess that is a wishlist item for another day. might actually be nice for you guys as well to get people testing/validating fixes09:35
mvoppisati: thanks for this update!09:35
mborzeckiChipaca: i'm looking at snapshot file names, the code does not reverse the file name anywhere, so we sould be safe there wrt. parallel instances and extra _09:42
Chipacamborzecki: yep, the filename is for the sysadmin, snapshots doesn't infer info from it09:43
mborzeckiChipaca: mhm, cool09:43
Chipacamborzecki: only thing where it might be a problem is creating duplicate filenames, which we might not check for09:43
Chipacamborzecki: but we use InstanceName so should be fine, afaik09:43
mborzeckiChipaca: yes, instance names are unique09:43
Chipacai mean afaik we use instance name :)09:43
Chipacamvo: how long does the 'resize partition' step take, usually? boot's been stuck there for a while now09:44
mvoChipaca: probably entropy :(09:46
mvoChipaca: just hammer at some keys09:46
Chipacaheh, that was it09:46
* mvo weeps a bit in the corner about this problem09:47
mborzeckiheh, wonder what one will do when there's no keyboard attached09:47
mborzeckiwiggle some gpios09:48
* Chipaca suddenly wishes for "base: core | core1809:48
Chipacahuh09:51
Chipacamvo: a 'snap install' got aborted by a refresh of core18; is that expected?09:51
zygaaborted?09:51
zygacan we even do that?09:51
Chipacamight've been just coincidence09:52
Chipaca'snap tasks' say 'server misbehaving'09:52
zygamvo: actually09:57
zygamvo: perhaps https://github.com/snapcore/snapd/pull/5982#pullrequestreview-164628872 is a candidate for .509:57
zygamvo: but it is stacked on top of a pile of other things09:57
zygaso unsure09:57
mupPR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>09:57
zygayou marked that PR as targeting 2.36 so perhaps you know better09:58
Chipacamvo: bad news: we're hitting a variant of https://github.com/systemd/systemd/issues/815510:09
mvozyga: I can wait for jamie to clarify10:10
mvoChipaca: uhhh10:11
Chipacamvo: maybe :)10:11
* Chipaca is still digging10:11
Chipacabut, yeah, we just see the nasty [  364.293811] systemd-shutdown[1]: Failed to wait for process: Protocol error10:11
Chipacawhich seems to mean that systemd < 23810:11
mvoChipaca: hrm, hrm, or would need to sru10:12
Chipacayeah, systemd --version says 23710:12
Chipacawe could also backport https://github.com/systemd/systemd/pull/8429/files10:12
mupPR systemd/systemd#8429: sd-shutdown improvements <ci-fails/needs-rework 🔥> <merged-but-needs-fixing> <pid1> <Created by medhefgo> <Merged by keszybz> <https://github.com/systemd/systemd/pull/8429>10:12
zygauh fun10:13
zyga(not)10:13
Chipacamvo: but all that _really_ does is turn up the logging10:13
Chipacabah, maybe :)10:13
Chipacafor our case it might be the only difference10:13
Chipacai wonder if i can't turn up the logging without that10:13
mvoChipaca: ok10:13
Chipacamvo: so. we might not need that patch10:22
Chipacamvo: it's just that our systemd-shutdown helper unit isn't getting triggered10:22
Chipacadigging continues10:22
Chipacathat is: if I set it up by hand, I get10:23
mvoChipaca: oh, nice10:23
ChipacaSuccessfully changed into root pivot.10:23
ChipacaReturning to initrd...10:23
Chipacasnapd system-shutdown helper: started.10:23
Chipacasnapd system-shutdown helper: no reboot parameter10:23
Chipacasnapd system-shutdown helper: * unable to disassociate loop device /dev/loop0s: No such device or address10:23
Chipacasnapd system-shutdown helper: - was able to unmount writable cleanly10:23
Chipacasnapd system-shutdown helper: - halting.10:23
mvoChipaca: so maybe just a missing symlink to activate it?10:23
Chipacapr'aps10:23
Chipacarebooting to see :-)10:23
zygaChipaca: really /dev/loop0s?10:23
mvoChipaca: I can look for this is that helps you :)10:23
zygawhat even is that10:23
Chipaca$ systemctl is-enabled snapd.system-shutdown.service10:24
Chipacaenabled10:24
Chipacamvo: so it's not that :-|10:25
Chipacazyga: ¯\_(ツ)_/¯10:25
Chipacazyga: /dev/loop0; the s is probably a typo10:26
Chipacazyga: kmsg("* unable to disassociate loop device %ss: %s",10:26
zygaah10:26
Chipaca:)10:26
zygagood10:26
zygaat least10:26
zygaloop0 is probably the boot snap10:26
Chipacait's probably fine;  disassociation is automatic after dunno-what-utils-linux-version10:27
Chipacamvo: so,  the unit is enabled; it's not getting activated afaict10:28
Chipacaprobably changes to systemd-shutdown10:28
mvoChipaca: :/ hrm, hrm10:29
Chipacaah10:30
Chipacai think i might know why10:30
Chipacamvo: the snapd snap does not ship sh10:32
zygahuh? why would we need to ship sh?10:33
Chipacawell, we don't, but we then create snapd.system-shutdown.service as if we did10:34
zygais the service using shell?10:34
Chipacasudo sed -i -e 's|/snap/snapd/659/bin/sh|/snap/core18/304/bin/dash|' /etc/systemd/system/snapd.system-shutdown.service && sudo systemctl daemon-reload -> works10:35
Chipacazyga: ExecStart=/snap/core18/304/bin/dash -euc 'mount /run -o remount,exec; mkdir -p /run/initramfs; cp /usr/lib/snapd/system-shutdown /run/initramfs/shutdown'10:35
zygaohohh10:35
zygaI see10:35
mvoChipaca: oh woah - nice catch!10:36
ChipacaI don't remember why it does that instead of having multiple ExecStart= lines10:36
Chipacalet me try that instea10:36
Chipacaprobably more portable10:36
* Chipaca tries10:36
Chipacaof course if I had 'vi' this would be slightly easier :-D10:37
mvoChipaca: I thought we added this10:39
mvoChipaca: maybe you need a newer core18?10:39
Chipacamvo: I'll let it refresh10:39
mvook10:40
Chipacamvo: which 'this' is this, btw?10:40
mvoChipaca: I thought we added "vi" to core1810:42
mvo(vim.tiny to be exact)10:42
Chipacamvo: ah, possibly, it seems the core image was ~200 revisions behind10:42
zygabrb, dog10:44
Chipacaok10:45
Chipacaso10:45
Chipacaeasy fix10:45
mupPR snapd#5985 opened: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5985>10:45
mvoChipaca: I like the ring of "easy fix" \o/10:46
Chipacamvo: what creates snapd.system-shutdown.service?10:47
Chipacamvo: found it10:48
Chipacahmm10:51
Chipacamvo: what changes /bin/sh to /snap/snapd/<revno>/bin/sh ?10:51
Chipacamvo: found it10:55
sil2100mvo: I have uploaded the probert with the fix for db that mwhudson prepared to our PPA, once it's built I'll be triggering a new core1810:55
sil2100Once that's in would be nice to confirm that the probert crash is gone10:56
sil2100zyga: ^10:56
mvosil2100: nice11:00
mvosil2100: I will test with my pi-64bit11:00
zygaAs will once back11:01
mvosil2100: nice fix11:02
mvosil2100: great that this is under control11:03
mvoChipaca: fwiw, this fix sounds a lot like we want it in 2.35.5 just to be one the safe side (if its someting that needs to go into snapd)11:14
Chipacak11:15
mvoChipaca: ta11:15
mvoChipaca: but don't worry about this, I can do the backporting etc11:15
Chipacamvo: there is no worry; there is only do11:16
mvo:)11:16
mvoDO!11:16
* mvo hugs Chipaca 11:16
zygasil2100: is that the image from Friday good for testing?11:22
zygamvo: release day is like xmas11:23
zygaeveryone has a present11:23
sil2100No, not yet11:23
sil2100I mean, not anymore ;)11:23
sil2100I'll have a new one soonish11:23
zygaok11:23
sil2100The packages  need to publish though11:23
zygaI'll grab lunch quickly then11:24
mupPR snapd#5986 opened: data/systemd, wrappers: tweak system-shutdown helper for core18 <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5986>11:26
Chipacamvo, zyga: ^11:26
Chipacaooh, lunch, a capital idea11:26
pstolowskimborzecki: +1 on  #5985, would be good to land it fast11:26
mupPR #5985: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5985>11:27
mvoChipaca: thank you11:28
zygaChipaca: reviewed11:33
sil2100mvo: ummm, could you re-build core18 snap? Since currently I guess the main snap recipe is owned by you for now11:39
sil2100probert is good11:39
mborzeckioff to pick up the kids11:49
jdstrandmvo: hi!11:58
jdstrandmvo: I didn't tag those as 2.36 because I wasn't sure how suitable they were for it at this point in time and was going to let you decide (they are bigger than whatI (and probably you) were expecting last week12:00
jdstrandneedless to say, they took more than 'a few hours'12:00
jdstrandmvo: I mean, I'm happy if they go into 2.36, but having them just in trunk is ok too12:01
jdstrandmvo: but I wanted to talk to you about this: audit: type=1400 audit(1539604887.557:452): apparmor="DENIED" operation="exec" profile="snap.hello-world.env" name="/sbin/apparmor_parser" pid=30864 comm="snap-exec" requested_mask="x" denied_mask="x" fsuid=1000 ouid=012:01
jdstrandmvo: it seems every snap run invocation is causing this. let me know when you have a moment12:02
zygawoah?12:03
zygaso snap-exec runs apparmor_parser12:03
zygaprobably in the quest to compute system key12:03
zygaor something similar?12:03
jdstrandthat is what I was thinking12:03
zygawhat is worse12:03
zygaif apaprmor is updated12:03
zygaand we have a new apparmor parser12:03
zygathe system key will not match12:03
zygabut snapd doesn't care about the upgrade in the system12:04
zygaso it will always be wrong12:04
jdstrandso, release/apparmor.go init(), there is:12:04
jdstrandappArmorLevel, appArmorSummary = probeAppArmor()12:04
zygauntil you reboot and snapd considers this12:04
jdstrandappArmorParserFeatures = probeAppArmorParser()12:04
jdstrandwhat is weird though, is if this is the issue, then why don't I see denials from probeAppArmor?12:04
jdstrandI only see denials for probeAppArmorParser12:05
zygaI think we allowed the former12:05
jdstrandI looked in the template. let me look again12:05
zygaoh, in that case I don't know12:05
jdstrandalso, I was really surprised that snap run is doing all these checks12:05
jdstrandit isn't like it can do anything with the result12:05
zygaI think we d12:06
zygawe spin and wait12:06
zygathat's the purpose of system key there12:06
jdstrandand we are adding a bunch of stat()s and an exec() to the snap run12:06
jdstrandhmm12:06
jdstrandI definitely didn't mean for apparmor_parser to be called every time that an app was run12:06
zygaright12:06
jdstrandquite the opposite. I didn't even want it run every time a profile was compile12:07
zygaI think this falls under the idea I had a while ago with "facts" in /var/lib/snapd/facts - that would be written by snapd and interrogated by other parts of the stsack12:07
jdstrandI wanted it precisely once when snapd started :)12:07
jdstrandand I thought that was what happened with system-key12:07
zygammm, not quite12:07
zygayou need to be able to compute the system key12:07
jdstrandwell, clearly12:07
zygain snap-run12:07
zygaand quickly too as you now learned12:08
jdstrandwe need to short circuit this or move it12:08
jdstrandI mean we could add a rule, but blech, I don't want this-- it is only useful for profile generation12:08
zygaI agree12:08
zygahmmm hmm12:08
jdstrandsnap run can literally do nothing with the information12:08
* pstolowski lunches12:12
zygajdstrand: if you need me for this just ask, otherwise I'll be going through per user mount namespaces12:12
jdstrandyeah, I don't see /sys/kernel/security/apparmor/features in the template12:14
jdstrandzyga: thanks, I'll discuss with mvo and we can decide from there12:14
jdstrandit is definitely denied: $ ls /sys/kernel/security/apparmor/features/12:15
jdstrandls: cannot open directory '/sys/kernel/security/apparmor/features/': Permission denied12:15
jdstrandso, probeAppArmor() is not getting called, but probeAppArmorParser() is...12:17
jdstrandwhich makes no sense cause they are both only called via init()...12:18
* jdstrand is confused12:19
zygaperhaps probe apparmor is really lazy?12:27
jdstrandhuh12:29
jdstrand./interfaces/system_key.go:sk.AppArmorParserFeatures = release.AppArmorParserFeatures()12:29
jdstrand./interfaces/apparmor/backend.go:parserFeatures        = release.AppArmorParserFeatures12:29
jdstrandso in system_key, we assign '()' but in backend.go we do not12:30
jdstrandthat is the same with AppAmorFeatures though...12:31
zyga!12:32
mborzeckire12:35
jdstrandmaybeWaitForSecurityProfileRegeneration() does call interfaces.SystemKeyMismatch()12:36
jdstrandI'm really puzzled that I'm not seeing denials from release.AppArmorFeatures() but I am for release.AppArmorParserFeatures()12:40
mvosil2100: sure12:41
mvojdstrand: hi, reading backlog (looks like there is a lot of it :)12:41
jdstrandmvo: yes, halp :)12:41
zyga(insert 5th element quote012:42
jdstrandI wonder what ioutil.ReadDir() is doing12:43
=== chihchun is now known as chihchun_afk
jdstrandmaybe it doesn't trigger the apparmor denial12:43
jdstrandbut then that would be a bug in system-key detection12:44
jdstrandhmm, it is just an os.Open12:46
Chipacajdstrand: ls /sys/kernel/security/apparmor/features/ triggers the denial, but does stat on its own?12:51
jdstrandChipaca: it would not, no12:52
zygastat is not mediated anywhere AFAIK12:53
Chipacajdstrand: maybe whatever's triggering the denial is not one of the required features that we stat in probeAppArmor12:53
jdstrandyes, that is what it is Chipaca12:53
Chipacaah12:53
jdstrandprobeAppArmor only does an isDirectory() which is just a stat12:53
Chipacayup12:54
Chipacaand a rather dumb stat at that :)12:54
zygaaaah12:54
jdstrandok, so mystery solved on the why probeAppArmor() doesn't trigger denials12:54
zygaman, that's magic12:54
jdstrandmvo: ^12:54
mvojdstrand: I just finished reading backlog - indeed, we compute the system-key in snap run, sorry that I did not realize during the review about the implication of the apparmor parser test12:54
jdstrandso, the question is how to fix probeAppArmorParser12:54
mupPR snapd#5987 opened: cmd: refactor IPC and lifecycle of the helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/5987>12:54
mvojdstrand: let me quickly look at this (its 5min until our standup)12:55
zygastandup time but I'll be 3 min late12:55
zygabrb12:55
jdstrandmvo: so, on the one hand, it does make sense that we might wait for profile regeneration for the unsafe, but on the other, I'd *way* much prefer we *not* exec apparmor_parser in every snap run12:56
mvojdstrand: from the top of my head: probe once and then save the result in e.g. /run/snapd12:56
jdstrandmvo: that's what I was trying to do :)12:56
jdstrandmvo: you mean, just touch a file?12:56
mvojdstrand: yeah12:56
jdstrandmvo: ok, let me work through that12:56
mvojdstrand: thanks, the other option would be to simply not make it part of system-key and hope that something else triggers a re-run12:57
jdstrandmvo: which do you prefer?12:57
mvojdstrand: let me quickly look at what goes into system-key already12:57
mvojdstrand: it partly depenends on your preferences as well, if we remove it from the system-key worst case is that the profile is only re-generated with the next snapd refresh12:58
jdstrandit would be fast to add a touch at the end of probeAppArmorParser and then stat for it at the top12:58
jdstrandmvo: I think that is least correct12:58
mvojdstrand: yeah, and cheapest :)12:59
jdstrandmvo: no, I meant removing and hoping is least correct12:59
jdstrandmvo: but is is also not correct to touch the file. cause, well, in theory the parser could've been updated in the mean time (that was always true with the intent of the original PR13:00
jdstrand)13:00
mvojdstrand: we could use the mtime of apparmor_parser as input13:00
mvoof system-key13:00
jdstrandmvo: so, mtime and touch?13:01
mvojdstrand: mtime of /usr/bin/apparmor_parser and if that changes the system-key changes and we re-generation apparmor. and when doing that we check apparmor features13:02
* jdstrand doesn't see how mtime is enough13:02
jdstrandthat would require redoing system key generation a bit, no?13:03
jdstrandwell wait13:03
jdstrandok, I add mtime to the systemKey struct. then I always just check for that13:04
jdstrandso, that is a stat, and we only call probeAppArmorPaarser if they are different13:04
jdstrandok, let me look at that13:05
mvojdstrand: thank you! in the standup right now so I may be a bit slow replying13:11
Chipacajdstrand: dunno if it helps, but i've got this in my bash history: grep -rl --include \*.go --exclude \*_test.go '^func init()' | xargs perl -pi -we 's/(^func init\(.*)/\1\nprintln("$ARGV")/'13:28
Chipacajdstrand: adds a print to any and all init, so you can easily spot unexpected inits13:29
zygajdstrand: offtopic, I think you should enqueue https://github.com/snapcore/snapd/pull/588513:33
mupPR #5885: Adding DPDK interface for DPDK Snap <Created by wililupy> <https://github.com/snapcore/snapd/pull/5885>13:33
* Chipaca hugs mborzecki 14:01
* mvo hugs mborzecki as well well14:02
mborzeckiwhy the hugs?14:02
mvojdstrand: standup over, anything I can help with?14:02
Chipacaniemeyer: dunno if you saw but at least mborzecki isn't here in 1h14:02
Chipacamborzecki: no, that you said the above just as we wrapped (and I feel guilty because I said "yes", for myself, but know how that can be taken as a for all so I should've waited)14:02
mvomborzecki: because Chipaca started it :) *grouphug*14:03
Chipaca:)14:03
mvoChipaca: I think its fine, we just skip the bits from mborzecki  and talk about them tomorrow, no?14:03
niemeyerChipaca: Ah, I didn't realize.. well, we can get together either way and just finish that list.. tomorrow we can review the whole thing again14:03
* Son_Goku hugs mborzecki 14:04
mborzeckiworks for me14:04
Son_GokuI'm just happy someone besides me actually bothers to investigate SELinux stuff, so you deserve hugs from me anyway :D14:04
jdstrandmvo: not yet14:04
mvook14:04
Son_Gokumborzecki, when 2.36 becomes available, I'm going to push out for epel7 at the same time as fedora14:05
zygamborzecki: hey, I pushed a few tweaks to snap-confine, would you be willing to look14:05
zygait's nothing major really, and not that long14:05
zygamostly a switch to pipe14:05
jdstrandChipaca: that's interesting. thank you14:15
mborzeckiSon_Goku: nice, thank you!14:16
mupPR snapd#5988 opened: cmd: rename ns_group to mount_ns <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/5988>14:27
zygamvo: if you can, please land that, that's just a rename14:32
zyga^14:32
mvozyga: sure, I have a look14:36
zygathank you!14:41
niemeyerzyga: You coming?15:02
zygaah, sure15:02
zyganiemeyer: same URL?15:02
degvillezyga: yep15:03
mupPR snapcraft#2353 opened: tests: remove dependency on snapcraft for integration tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2353>15:21
ackkhi, can classic snaps run deamons as specific system users?15:38
smoserzyga: is there expected to be a new snapd upload before release  of 18.10 ?15:49
zygasmoser: I defer to our release manager, mvo16:25
zygaI don't know16:25
zygaackk: not at present16:26
zygaunless said daemons do that themselves16:26
ackkzyga, meaning, you can "su" as a different user from classic, right? IOW a daemon could run as "nobody" in that case?17:20
kyr0Hi, I have a snap package that when I launch it from the terminal, nothing happens. Where should I start to troubleshoot?17:36
zygare17:45
zygaackk: correct17:45
zygakyr0: hello17:45
zygakyr0: it depends on the software but you may have some good idea what is happening in general by using:17:45
zygakyr0: SNAPD_DEBUG=1 snap run ...17:46
zyga(or just the program name)17:46
kyr0zyga: Thank you, ill start my investigation.17:49
zygakyr0: you can also run "snap run --shell" to enter a shell with the same confinement17:50
zygakyr0: but note, not the same environment17:50
zygasome of the environment is set by wrapper scripts in $SNAP17:50
zygacd $SNAP to look around17:50
zygayou can run those scripts directly to execute the same command17:50
zygahmm17:53
zygaChipaca: still hear?17:53
zygahere*17:53
kyr0zyga: Thanks, i'll start looking into it17:53
Chipacazyga: yes18:44
zygaoh god why :)18:44
zygaok18:44
zygaI was thinking about taking the accounts service test manual for a moment18:44
Chipacazyga: finished dinner, came to eod18:44
zygait's failing all the time18:44
zygawanted to discuss ideas18:44
zygabut can wait18:44
zyganot urgent :)18:44
Chipacazyga: i've left it looping here to see if i can catch the failure18:44
zygaI caught it once18:45
Chipacaon iteration 20 with no failures18:45
zygaforgot about it18:45
zygaclosed terminal18:45
zygayes ;)18:45
zygaI would suggest adding ps aux to debug18:45
zygaI bet there's something very odd running then18:45
zyga(not accounts service)18:45
Chipacayeap18:45
Chipacazyga: instead of 'gdbus monitor --session --dest yadda', i'd do 'dbus-monitor --session' which is a lot more chatty18:46
Chipacabut, that assumes I can reproduce the issue :-D18:46
zygaChipaca: is your unmount fix ready?18:46
Chipacazyga: well, its spread is red, if that's what you're asking18:47
Chipacaor was when i looked last18:47
Chipacazyga: https://api.travis-ci.org/v3/job/441628807/log.txt18:47
Chipacazyga: the last run, degraded and snap-repair failed, which … not sure what those are about18:47
zygaI see18:47
Chipacasuspect something is actually broken18:48
zygaah18:48
zygaI was just chatting with mvo about a possible release tonight18:48
Chipacathat'd be nice but integration tests aren't cooperating18:48
Chipacaand i don't know enough about those two tests to know if they're real or not18:48
Chipacathey're failing on core 1818:49
Chipacaare you seeing them fail there as well?18:49
zygaI see the error log now18:49
zygahmmm18:52
zygaChipaca: is ExecStart= ... ordered?18:56
zygaseems so according to manual pages18:57
mupPR snapd#5989 opened: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989>19:12
Chipacazyga: yes, it's ordered19:13
Chipacazyga: and yes it stops as soon as one fails, unless it starts with -19:13
kyrofaHow is the possibility for a 2.36 release looking this week?19:36
Chipacakyrofa: 0.4719:44
Chipacakyrofa: but i'm probably overly pessimistic, so maybe it's .8719:45
kyrofaChipaca, I'll take your earlier assessment :P19:57
Chipacakyrofa: I hope I'm wrong, because I'm itching to update the brew formula so it no longer neads --HEAD19:58
mupPR snapcraft#2349 closed: extensions: use extension docstring <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2349>20:24
popeyChipaca: fyi, that person you conversed with was a spammer, i removed them20:50
popey(on the forum)20:50
Chipacapopey: they were? their question seemed relevant20:50
Chipacabooo20:50
popeyit was a copy/pasta from a reddit thread a year ago20:50
Chipacaoh20:50
popeythey do that to get credit on the forum, then slip a url edit in a few days later20:50
Chipacaright20:50
popeyi didnt spot it until the edit20:51
Chipacahow isn't there an emoji for spam20:53
popeytrademarks i guess20:54
Chipaca🥫 came so close20:54
Chipacaanyhoo, it's a relief as the "why do i need to log in" thing should be well dead20:55
popeyYeah, i recently requested an edit to the appimage wiki because it claimed we still needed to login21:00
popeyxkcd 38621:00
mupPR snapcraft#2354 opened: Preflight missing multipass <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/2354>21:15
mupPR snapcraft#2350 closed: extensions: parse all declared extensions before applying <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2350>21:54
mupPR snapcraft#2355 opened: extensions: cleanup and generic tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2355>22:24
mupPR snapcraft#2246 closed: packaging: cleanup extension usage in setup.py <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2246>22:27

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