=== epod is now known as luk3yx | ||
zyga | Hey | 06:21 |
---|---|---|
zyga | I will be partially away for errands | 06:21 |
pstolowski | mornings | 08:06 |
luk3yx | Is there any way I can access the system's locale directory from a snap (with the "strict" confinement)? | 08:09 |
Chipaca | luk3yx: no | 08:10 |
luk3yx | Shouldn't there be a way to do that? | 08:11 |
Chipaca | luk3yx: ...no? | 08:11 |
Chipaca | luk3yx: what for? | 08:11 |
luk3yx | gettext() I think | 08:12 |
Chipaca | luk3yx: what are you l10n'ing? | 08:12 |
luk3yx | Minetest | 08:12 |
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:13 |
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:14 |
luk3yx | Oh, I can disable gettext | 08:15 |
Chipaca | luk3yx: gettext will print the msgid if it can't find a translation | 08:15 |
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:16 |
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:17 |
Chipaca | luk3yx: ok | 08:18 |
luk3yx | Oh, it's probably looking in the wrong place | 08:19 |
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:20 |
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:21 |
ackk | ok, thanks | 08:22 |
abeato | mvo, morning! I have just noticed that core18 does not have initramfs, I'm curious, why that decision? | 08:24 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:37 |
abeato | aha, interesting - would be something good to discuss in Malta | 08:38 |
mvo | abeato: yes, I think we need to define a better process | 08:39 |
mvo | abeato: hence malta :) | 08:39 |
abeato | yeah, sure thing | 08:40 |
* dot-tobias says hi | 08:58 | |
Chipaca | augh | 09:55 |
Chipaca | pedronis: please let me know you're editing a pr i'm working on | 09:55 |
Chipaca | mvo: I'm off to prep for the trip; telegram works | 09:57 |
mvo | Chipaca: thanks | 09:59 |
=== alan_g_ is now known as alan_g | ||
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:10 |
zyga | ok back now | 11:21 |
zyga | mvo: anything urgent to jump at instead of the patches? | 11:22 |
zyga | guess not | 11:29 |
zyga | pstolowski: hey | 11:31 |
zyga | on 2nd though, about your question on ConnRef | 11:31 |
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:32 |
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:34 |
pstolowski | zyga: the fix for api should land though | 11:35 |
zyga | +1 | 11:35 |
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:36 |
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:37 |
pstolowski | zyga: so yeah, let's talk in malta | 11:38 |
mup | PR snapd#6512 opened: overlord: fix random typos <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6512> | 11:41 |
zyga | quick trivial ^ | 11:42 |
mvo | zyga: thank you! | 11:48 |
zyga | hey mvo :) | 11:48 |
mvo | zyga: patches are the most important thing right now | 11:48 |
mvo | pedronis: lp-1813963 failed, I saw this before, I think we should disable this test, it seems to be unreliable | 11:49 |
zyga | oh? | 11:50 |
zyga | how does it fail? | 11:51 |
zyga | mvo: ? | 11:56 |
mvo | zyga: https://paste.ubuntu.com/p/fB35ntFNFv/ | 12:00 |
mvo | zyga: we can investigate in a bit but probably simply a dirty dmesg | 12:01 |
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:02 |
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:05 |
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:06 |
zyga | hmmmm | 12:07 |
zyga | interesting | 12:08 |
zyga | it's a real bug, the fix is simple but this is curious | 12:08 |
zyga | mvo: something like this | 12:10 |
zyga | https://www.irccloud.com/pastebin/bxOqgLJE/ | 12:10 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
pstolowski | zyga, mvo i can do that | 12:27 |
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:46 |
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:47 |
zyga | pstolowski: device filtering only as eBPF programs | 12:48 |
zyga | mvo: I replied on the patches thread | 12:49 |
zyga | mvo: please advise on preferred approach | 12:50 |
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:53 |
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:54 |
zyga | pstolowski: the persistent objects are described by bpf(2) man page | 12:55 |
* zyga AFK for more errands | 12:59 | |
pstolowski | zyga: looks extremely interesting, thanks | 12:59 |
pstolowski | will take a look | 12:59 |
* pstolowski lucnh | 12:59 | |
mup | PR snapd#6513 opened: [RFC] many: support `snap install --skip-service-start` <Created by chipaca> <https://github.com/snapcore/snapd/pull/6513> | 13:02 |
Chipaca | mvo, pedronis, popey & Wimpress: ^? | 13:03 |
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:04 | |
pedronis | Chipaca: it seems a bit too specific, a commented a bit | 13:16 |
pedronis | I commented | 13:16 |
=== ricab is now known as ricab|lunch | ||
kjackal | Hi snappy people this page from the official docs seems to be missing https://docs.snapcraft.io/1239 | 13:55 |
mvo | Chipaca: nice! | 13:56 |
Chipaca | kjackal: where did you get that link? | 14:00 |
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:01 |
degville | kjackal: (with info from the responses to the question - and thanks for the question) | 14:02 |
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:03 |
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:04 |
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:36 |
zyga | pstolowski: did you push that one-liner by any chance? | 14:41 |
zyga | it will fix master | 14:41 |
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:42 |
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:43 |
Chipaca | tomwardill: yes | 14:45 |
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:46 |
pstolowski | zyga: pushing | 14:47 |
tomwardill | Chipaca: ah, that will do nicely, thanks! | 14:47 |
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:48 |
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:51 |
zyga | thnx | 14:53 |
zyga | pstolowski: you have feedback on your PR | 14:53 |
pstolowski | updated | 14:58 |
=== ricab|lunch is now known as ricba | ||
=== ricba is now known as ricab | ||
* cachio lunch | 15:08 | |
Chipaca | tomwardill: ah, also, https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537 | 15:14 |
tomwardill | Chipaca: ooh, excellent. I was just having 'fun' with trying to human parse the journal logs :) | 15:15 |
Chipaca | yeah | 15:15 |
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:17 |
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:19 | |
mup | Bug #1816073 opened: snap info does not scope to brand store <Snappy:New> <https://launchpad.net/bugs/1816073> | 15:20 |
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:22 |
mvo | zyga: I don't think the test is broken, something else is strange | 15:26 |
zyga | I agree with strange | 15:26 |
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:29 |
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:30 |
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:31 |
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:32 |
zyga | mvo: gah, I think seccomp is just really more buggy | 15:45 |
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> | 15:59 |
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:04 |
mvo | zyga: so 6515 is the workaround for the test fix | 16:05 |
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:06 |
zyga | sanity testing on other arches now | 16:09 |
DonAlex | OK can someone tell me why I get launch failed: instance "<snap-name>" already exists when I try re running snapcraft ? | 17:08 |
DonAlex | How do I stop the instance so i can rebuild with different options ? | 17:09 |
=== pstolowski is now known as pstolowski|afk | ||
Chipaca | DonAlex: you still there? | 18:00 |
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:48 |
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 | 18:51 |
mup | PR snapcraft#2473 opened: cli: validate schemas before invoking provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2473> | 19:05 |
mup | PR snapd#6516 opened: interfaces/seccomp: generate global seccomp profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6516> | 19:13 |
bdx | hello | 22:20 |
bdx | is there a way to include a private git repo as a git source type in snapcraft.yaml? | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!