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