[06:21] <zyga> Hey
[06:21] <zyga> I will be partially away for errands
[08:06] <pstolowski> mornings
[08:09] <luk3yx> Is there any way I can access the system's locale directory from a snap (with the "strict" confinement)?
[08:10] <Chipaca> luk3yx: no
[08:11] <luk3yx> Shouldn't there be a way to do that?
[08:11] <Chipaca> luk3yx: ...no?
[08:11] <Chipaca> luk3yx: what for?
[08:12] <luk3yx> gettext() I think
[08:12] <Chipaca> luk3yx: what are you l10n'ing?
[08:12] <luk3yx> Minetest
[08:13] <Chipaca> luk3yx: how would the system's locale directory have minetest strings in it?
[08:13] <luk3yx> Maybe it's a bug in Minetest then, it doesn't show certain text when it can't access the locale directory
[08:14] <Chipaca> luk3yx: it doesn't show it translated, or it doesn't show it at all?
[08:14] <luk3yx> It doesn't show certain text (such as the title) at all
[08:15] <luk3yx> Oh, I can disable gettext
[08:15] <Chipaca> luk3yx: gettext will print the msgid if it can't find a translation
[08:16] <Chipaca> luk3yx: that is, gettext("house") will return "house" if it can't find the locale to print "casa"
[08:16] <Chipaca> s/print/return/
[08:16]  * Chipaca still having breakfast
[08:16] <Chipaca> luk3yx: so it's probably something else
[08:17] <luk3yx> Okay, thanks
[08:17] <Chipaca> luk3yx: now, you can ship your localisation strings inside the snap
[08:17] <Chipaca> luk3yx: IIRC there's even helpers for that
[08:17] <luk3yx> It should be doing that anyway
[08:18] <Chipaca> luk3yx: ok
[08:19] <luk3yx> Oh, it's probably looking in the wrong place
[08:20] <ackk> hi, has something changed recently in the way snapcraft handles the env? I used to be able to override-build and change PATH, but it seems it's not working anymore
[08:21] <Chipaca> ackk: my suggestion would be to ask later, or open a forum topic
[08:21] <Chipaca> ackk: most snapcraft proper is asleep
[08:21] <Chipaca> and
[08:21] <Chipaca> we're off to a conference next week, so async communication will work best
[08:22] <ackk> ok, thanks
[08:24] <abeato> mvo, morning! I have just noticed that core18 does not have initramfs, I'm curious, why that decision?
[08:30] <mvo> abeato: no initramfs package you mean? we stripped everything out and added only the bits needed, if you need it back we can add it back
[08:31] <mvo> abeato: or am I misunderstanding? do you mean the initramfs bits that are in the core snap and used by the kernel?
[08:31] <abeato> mvo, well, it is used when building the kernel snap - that means that we would use the initrd that is shipped with core even in pure core18 devices
[08:31] <abeato> mvo, that is correct
[08:32] <abeato> mvo, snapcraft downloads core and gets the initrd from there in the kernel plugin
[08:32] <Chipaca> mvo: wrt 6506, I'm puzzled about having to do https://github.com/snapcore/snapd/pull/6506/commits/49b86259568abe1bce74fb625b479417c46e3fa4
[08:32] <mup> PR #6506: overlord/snapstate: add some randomness to the catalog refresh <Squash-merge> <⚠ Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6506>
[08:32] <pedronis> that needs to change somehow
[08:32] <mvo> abeato: I see, we have not defined the new process for this, note that our kernel snap is not using that initrd, its pulling it from our ppa/image
[08:32] <pedronis> core18 is a base now
[08:32] <abeato> mvo, in fact snapcarft woule need to be modified to address this too
[08:33] <mvo> abeato: yeah, sounds like somehting we should discuss in malta
[08:33] <pedronis> in theory the developent image coresponding to a base can have more stuff than the base
[08:34] <abeato> mvo, right, probably it would be better if simply core did not ship initrd and snapcraft pulled it from the right place depending on the base for the kernel snap - which I do no know if can be defined for a kernel snap anyway
[08:37] <abeato> pedronis, I had not heard about development images, is that something new?
[08:37] <pedronis> when you build with a base  snapcrat gets a corresponding multipass image
[08:37] <pedronis> which is not just the base snap
[08:37] <pedronis> or at least that was the plan afaik
[08:38] <abeato> aha, interesting - would be something good to discuss in Malta
[08:39] <mvo> abeato: yes, I think we need to define a better process
[08:39] <mvo> abeato: hence malta :)
[08:40] <abeato> yeah, sure thing
[08:58]  * dot-tobias says hi
[09:55] <Chipaca> augh
[09:55] <Chipaca> pedronis: please let me know you're editing a pr i'm working on
[09:57] <Chipaca> mvo: I'm off to prep for the trip; telegram works
[09:59] <mvo> Chipaca: thanks
[11:10] <zyga> Re
[11:10] <zyga> Just getting coffee, cannot wake up today. Paperwork for Lucy is done. I will work on the patches mvo knows about now
[11:21] <zyga> ok back now
[11:22] <zyga> mvo: anything urgent to jump at instead of the patches?
[11:29] <zyga> guess not
[11:31] <zyga> pstolowski: hey
[11:31] <zyga> on 2nd though, about your question on ConnRef
[11:32] <zyga> I was wondering if this is really the tip of a larger problem to address
[11:32] <zyga> let's not change that method yet please, we can discuss on Sunday, ok?
[11:34] <pstolowski> zyga: hey. yes, indeed i had same thoughts, that's why i proposed an obvious fix for api bug first (https://github.com/snapcore/snapd/pull/6511);
[11:34] <mup> PR #6511: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>
[11:34] <pstolowski> zyga: i've a change for repo ready in a separate branch (worked on this morning), but yeah, i'm kinda unsure about this
[11:35] <pstolowski> zyga: the fix for api should land though
[11:35] <zyga> +1
[11:36] <zyga> pstolowski: my feeling is that repo needs to become transactional OR we need to change locking semantics entirely
[11:36] <zyga> (caller locks)
[11:36] <pstolowski> zyga: yes
[11:37] <pstolowski> zyga: it was all kinda ok when we only acessed repo from tasks and all accesses were locked by state
[11:37] <zyga> yeah
[11:37] <zyga> I agree
[11:37] <pstolowski> zyga: then i introduced repo access in api, for disconnect and hooks
[11:38] <pstolowski> zyga: so yeah, let's talk in malta
[11:41] <mup> PR snapd#6512 opened: overlord: fix random typos <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6512>
[11:42] <zyga> quick trivial ^
[11:48] <mvo> zyga: thank you!
[11:48] <zyga> hey mvo :)
[11:48] <mvo> zyga: patches are the most important thing right now
[11:49] <mvo> pedronis: lp-1813963 failed, I saw this before, I think we should disable this test, it seems to be unreliable
[11:50] <zyga> oh?
[11:51] <zyga> how does it fail?
[11:56] <zyga> mvo: ?
[12:00] <mvo> zyga: https://paste.ubuntu.com/p/fB35ntFNFv/
[12:01] <mvo> zyga: we can investigate in a bit but probably simply a dirty dmesg
[12:02] <zyga> hmmmm
[12:02] <zyga> it's unlikely
[12:02] <zyga> I clean dmesg explicitly
[12:02] <zyga> feels like worth having a look to just get the denials
[12:02] <zyga> did you get the debug part as well?
[12:05] <mvo> zyga: let me see if I find it
[12:05] <mvo> zyga: for reference full log is https://api.travis-ci.org/v3/job/493672747/log.txt
[12:06] <mvo> zyga: it dies in prepare
[12:06] <mvo> zyga: [ 1176.079662] audit: type=1400 audit(1550229169.481:649): apparmor="DENIED" operation="signal" profile="snap-update-ns.test-snapd-simple-service" pid=12178 comm="4" requested_mask="send" denied_mask="send" signal=term peer="snap-update-ns.test-snapd-simple-service"
[12:06] <zyga> thanks, let me look at one thing quickly
[12:07] <zyga> hmmmm
[12:08] <zyga> interesting
[12:08] <zyga> it's a real bug, the fix is simple but this is curious
[12:10] <zyga> mvo: something like this
[12:10] <zyga> https://www.irccloud.com/pastebin/bxOqgLJE/
[12:13] <mvo> zyga: makes sesne, isn't that kind of central to how alarm() works, makes me wonder why we did not hit this earlier - oh well
[12:13] <mvo> zyga: or am I missing things?
[12:13] <zyga> mvo: it's not in snap-confine
[12:13] <zyga> look at the profile name
[12:13] <zyga> it's sun
[12:13] <mvo> zyga: its snap-update-ns, right?
[12:13] <zyga> probably the mocked sun binary
[12:13] <zyga> your simplification I suspect
[12:13] <mvo> zyga: aha
[12:13] <zyga> but I don't recall what was done there in the end
[12:14] <mvo> zyga: its a simple time.Sleep(31s)
[12:14] <zyga> hmm
[12:14] <zyga> so real sun doesn't need this
[12:14] <zyga> so we're back to changing things for a test
[12:14] <zyga> but at  the same time I think this is super safe
[12:14] <zyga> it's self-signaling
[12:14] <zyga> should be allowed
[12:14] <zyga> we're not allowing it only becaue we're not using any of the typical abstractions
[12:15] <mvo> zyga: we could just extend the profile in the test, yes?
[12:15] <zyga> nah, just extend the template
[12:15] <zyga> it's way less headache
[12:15] <zyga> (see what I did to make the template different just for the test before)
[12:15] <mvo> zyga: true
[12:16] <mvo> zyga: I have a meeting in a bit and need some lunch before, I can look at this after the meeting or maybe someone else can help? pstolowski  could probably proposehttps://www.irccloud.com/pastebin/bxOqgLJE/  maybe?
[12:16] <mvo> zyga: does that make sense?
[12:16] <mvo> zyga: then you can focus on the other thing you work on right now :)
[12:16] <mvo> ETOOMUCH
[12:17] <zyga> yes
[12:17] <zyga> I'm not interrupting the other patches I'm working on
[12:17] <zyga> but I can propose this by EOD  if nobody does
[12:17]  * mvo vanishes for lunch for some minutes
[12:17] <mvo> zyga: thanks
[12:27] <pstolowski> zyga, mvo i can do that
[12:46] <zyga> pstolowski: some food for thoght
[12:46] <zyga> pstolowski: no device cgroup
[12:46] <zyga> pstolowski: no udev tagging for any device assignment
[12:47] <zyga> pstolowski: (scratch that, no udev tagging like we currently do, we can keep the tagging part)
[12:47] <zyga> pstolowski: udev tagging invokes small binary that modifies certain persistent kernel objects
[12:48] <zyga> pstolowski: device filtering only as eBPF programs
[12:49] <zyga> mvo: I replied on the patches thread
[12:50] <zyga> mvo: please advise on preferred approach
[12:53] <zyga> pstolowski: in my head this is working as follows: we create and update, on demand, kernel objects representing access permissions for a given snap
[12:53] <zyga> pstolowski: all snaps launch with a eBPF program that controls device access
[12:54] <zyga> pstolowski: snap-device-helper mostly goes away (would need to be rewritten as a small C program)
[12:54] <pstolowski> zyga, interesting!
[12:54] <zyga> pstolowski: alternatively, as a snapctl thing but I think that is problematic (early boot)
[12:55] <zyga> pstolowski: the persistent objects are described by bpf(2) man page
[12:59]  * zyga  AFK  for more errands
[12:59] <pstolowski> zyga: looks extremely interesting, thanks
[12:59] <pstolowski> will take a look
[12:59]  * pstolowski lucnh
[13:02] <mup> PR snapd#6513 opened: [RFC] many: support `snap install --skip-service-start` <Created by chipaca> <https://github.com/snapcore/snapd/pull/6513>
[13:03] <Chipaca> mvo, pedronis, popey & Wimpress: ^?
[13:04] <Chipaca> pedronis: it's a very minor complication to doInstall, IMHO, and it'll help people that're currently suffering
[13:04]  * Chipaca goes back to trip prep
[13:16] <pedronis> Chipaca: it seems a bit too specific, a commented a bit
[13:16] <pedronis> I commented
[13:55] <kjackal> Hi snappy people this page from the official docs seems to be missing https://docs.snapcraft.io/1239
[13:56] <mvo> Chipaca: nice!
[14:00] <Chipaca> kjackal: where did you get that link?
[14:01] <Chipaca> kjackal: that's not part of the official docs, and it shouldn't be linked to from the official docs
[14:01] <Chipaca> kjackal: that's https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239
[14:01] <degville> Chipaca / kjackal: all those posts are published currently - it's probably not linked anywhere. But there's an issue for removing them.
[14:01] <Chipaca> yeah the docs thing should only be serving 'docs'
[14:01] <Chipaca> ¯\_(ツ)_/¯
[14:01] <degville> kjackal: I think we can add to that page though to make it clearer.
[14:02] <degville> kjackal: (with info from the responses to the question - and thanks for the question)
[14:03] <kjackal> degville: Chipaca: I go to this page from the official docs by searching for "schedule". First link.
[14:03] <mup> PR snapd#6503 closed: tests: use snap which takes 15 seconds to install on retryable-error test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6503>
[14:03] <kjackal> So where is the official docs for snap refresh scheduling?
[14:04] <degville> kjackal: https://docs.snapcraft.io/keeping-snaps-up-to-date/7022
[14:04] <kjackal> Awesome, thank you
[14:04] <degville> np. thanks for flagging the issue.
[14:36] <mup> PR snapd#6376 closed: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
[14:41] <zyga> pstolowski: did you push that one-liner by any chance?
[14:41] <zyga> it will fix master
[14:42] <kenvandine> zyga: in case i haven't said this before... thanks for layouts!
[14:42] <kenvandine> sooooooo useful
[14:42] <zyga> :love: :)
[14:42] <zyga> thank you
[14:42] <zyga> I'm making them better
[14:42] <zyga> just slow to land stuff
[14:42] <kenvandine> so many snaps with the same copy and pasted parts to for handling relocation
[14:42] <kenvandine> that i can remove now
[14:42] <kenvandine> like iso-codes
[14:43] <tomwardill> hi all, if I've got an Ubuntu Core image, is it possible to enable some form of verbose debugging on a `snap install` command, so I can see HTTP requests snapd is making?
[14:45] <Chipaca> tomwardill: yes
[14:46] <Chipaca> 1 sec
[14:46] <Chipaca> tomwardill: sparkiegeek's description of how to enable debug in snapd remains the best one I know: https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/2?u=chipaca
[14:47] <pstolowski> zyga: pushing
[14:47] <tomwardill> Chipaca: ah, that will do nicely, thanks!
[14:48] <mup> PR snapd#6514 opened: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <https://github.com/snapcore/snapd/pull/6514>
[14:51] <pstolowski> pedronis, zyga, mvo : good news about daemon/api - disconnect - we already lock state early, so there is no problem after all \o/ and #6511 is really the only fix needed
[14:51] <mup> PR #6511: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>
[14:51] <pstolowski> zyga: pushed #6514
[14:51] <mup> PR #6514: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <https://github.com/snapcore/snapd/pull/6514>
[14:53] <zyga> thnx
[14:53] <zyga> pstolowski: you have feedback on your PR
[14:58] <pstolowski> updated
[15:08]  * cachio lunch
[15:14] <Chipaca> tomwardill: ah, also, https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537
[15:15] <tomwardill> Chipaca: ooh, excellent. I was just having 'fun' with trying to human parse the journal logs :)
[15:15] <Chipaca> yeah
[15:17] <mup> PR snapd#6515 opened: tests: fix upgrade-from-2.15 with kernel 4.15 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6515>
[15:19] <mvo> pedronis, zyga: test passed here with 4.15.0-1026-gcp but [  352.490101] audit: type=1400 audit(1550243833.895:40): apparmor="DENIED" operation="file_mmap" profile="snap.go-example-webserver.webserver" name="/usr/lib/snapd/snap-exec" pid=22902 comm="snap-exec" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
[15:19] <mvo>  
[15:19]  * mvo runs again
[15:20] <mup> Bug #1816073 opened: snap info does not scope to brand store <Snappy:New> <https://launchpad.net/bugs/1816073>
[15:22] <zyga> mvo: that makes no sense, it passed but was denieid
[15:22] <zyga> it makes me feel that the test is flawed and cannot detect service being broken correctly
[15:26] <mvo> zyga: I don't think the test is broken, something else is strange
[15:26] <zyga> I agree with strange
[15:29] <BjornT> hi. i have a problem running a snap inside a container. it's unusable, since snapfuse take 100% cpu for some reason. if i use 'snap try' on the prime dir, instead of install the actual snap file, it works without any problems.
[15:29] <Chipaca> mvo: I'm guessing 6515 means I'm going to have to merge master again
[15:29] <zyga> BjornT: snap try uses a local bind mount
[15:29] <zyga> BjornT: snap install uses snapfuse
[15:30] <mup> Bug #1816073 changed: snap info does not scope to brand store <Snappy:Invalid> <Snap Store:Invalid> <https://launchpad.net/bugs/1816073>
[15:30] <zyga> BjornT: can you please report a bug on launchpad.net/snapd with the details of the container (how to reproduce yor setup)
[15:30] <zyga> BjornT: I cannot promise any quick fix but Friday and people are about to go away for travel and errands next week
[15:30] <BjornT> zyga: ah, that explains that. sure, i'll report a bug
[15:31] <zyga> BjornT: note that snapd doesn't actively detect all unsupported container environments
[15:31] <zyga> BjornT: tl;dr; recent versions of lxd on recent kernels work, everything else is a "maybe"
[15:31] <zyga> BjornT: privileged containers don't work with snapd
[15:32] <BjornT> zyga: does bionic count as 'recent'?
[15:32] <zyga> BjornT: yes
[15:32] <zyga> 16.04+
[15:32] <BjornT> ok, that's good
[15:45] <zyga> mvo: gah, I think seccomp is just really more buggy
[15:59] <mvo> Chipaca: maybe, lets see if my change helps
[15:59] <mup> PR snapd#6514 closed: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6514>
[16:04] <mvo> zyga: just fyi - adding "/usr/lib/snapd/snap-exec m,
[16:04] <mvo> " seems to be not helping :/
[16:04] <mvo> zyga: hold on, silly me
[16:04] <zyga> what are you getting?
[16:04] <mvo> zyga: sorry, it does fix it
[16:05] <mvo> zyga: so 6515 is the workaround for the test fix
[16:06] <zyga> ok
[16:06] <zyga> I'm doubting libseccomp
[16:06] <zyga> the pfc program is garbage
[16:06] <zyga> I'm using the disassembler from the kernel to check
[16:09] <zyga> sanity testing on other arches now
[17:08] <DonAlex> OK can someone tell me why I get launch failed: instance "<snap-name>" already exists when I try re running snapcraft ?
[17:09] <DonAlex> How do I stop the instance so i can rebuild with different options ?
[18:00] <Chipaca> DonAlex: you still there?
[18:48] <mup> PR snapd#6515 closed: tests: fix upgrade-from-2.15 with kernel 4.15 <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6515>
[18:51] <pedronis> I merged master again into #6506 (so get that ^)
[18:51] <mup> PR #6506: overlord/snapstate: add some randomness to the catalog refresh <Squash-merge> <⚠ Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6506>
[18:51] <mvo> pedronis: great
[19:05] <mup> PR snapcraft#2473 opened: cli: validate schemas before invoking provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2473>
[19:13] <mup> PR snapd#6516 opened: interfaces/seccomp: generate global seccomp profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6516>
[22:20] <bdx> hello
[22:21] <bdx> is there a way to include a private git repo as a git source type in snapcraft.yaml?