/srv/irclogs.ubuntu.com/2019/02/15/#snappy.txt

=== epod is now known as luk3yx
zygaHey06:21
zygaI will be partially away for errands06:21
pstolowskimornings08:06
luk3yxIs there any way I can access the system's locale directory from a snap (with the "strict" confinement)?08:09
Chipacaluk3yx: no08:10
luk3yxShouldn't there be a way to do that?08:11
Chipacaluk3yx: ...no?08:11
Chipacaluk3yx: what for?08:11
luk3yxgettext() I think08:12
Chipacaluk3yx: what are you l10n'ing?08:12
luk3yxMinetest08:12
Chipacaluk3yx: how would the system's locale directory have minetest strings in it?08:13
luk3yxMaybe it's a bug in Minetest then, it doesn't show certain text when it can't access the locale directory08:13
Chipacaluk3yx: it doesn't show it translated, or it doesn't show it at all?08:14
luk3yxIt doesn't show certain text (such as the title) at all08:14
luk3yxOh, I can disable gettext08:15
Chipacaluk3yx: gettext will print the msgid if it can't find a translation08:15
Chipacaluk3yx: that is, gettext("house") will return "house" if it can't find the locale to print "casa"08:16
Chipacas/print/return/08:16
* Chipaca still having breakfast08:16
Chipacaluk3yx: so it's probably something else08:16
luk3yxOkay, thanks08:17
Chipacaluk3yx: now, you can ship your localisation strings inside the snap08:17
Chipacaluk3yx: IIRC there's even helpers for that08:17
luk3yxIt should be doing that anyway08:17
Chipacaluk3yx: ok08:18
luk3yxOh, it's probably looking in the wrong place08:19
ackkhi, 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 anymore08:20
Chipacaackk: my suggestion would be to ask later, or open a forum topic08:21
Chipacaackk: most snapcraft proper is asleep08:21
Chipacaand08:21
Chipacawe're off to a conference next week, so async communication will work best08:21
ackkok, thanks08:22
abeatomvo, morning! I have just noticed that core18 does not have initramfs, I'm curious, why that decision?08:24
mvoabeato: no initramfs package you mean? we stripped everything out and added only the bits needed, if you need it back we can add it back08:30
mvoabeato: or am I misunderstanding? do you mean the initramfs bits that are in the core snap and used by the kernel?08:31
abeatomvo, 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 devices08:31
abeatomvo, that is correct08:31
abeatomvo, snapcraft downloads core and gets the initrd from there in the kernel plugin08:32
Chipacamvo: wrt 6506, I'm puzzled about having to do https://github.com/snapcore/snapd/pull/6506/commits/49b86259568abe1bce74fb625b479417c46e3fa408:32
mupPR #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
pedronisthat needs to change somehow08:32
mvoabeato: 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/image08:32
pedroniscore18 is a base now08:32
abeatomvo, in fact snapcarft woule need to be modified to address this too08:32
mvoabeato: yeah, sounds like somehting we should discuss in malta08:33
pedronisin theory the developent image coresponding to a base can have more stuff than the base08:33
abeatomvo, 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 anyway08:34
abeatopedronis, I had not heard about development images, is that something new?08:37
pedroniswhen you build with a base  snapcrat gets a corresponding multipass image08:37
pedroniswhich is not just the base snap08:37
pedronisor at least that was the plan afaik08:37
abeatoaha, interesting - would be something good to discuss in Malta08:38
mvoabeato: yes, I think we need to define a better process08:39
mvoabeato: hence malta :)08:39
abeatoyeah, sure thing08:40
* dot-tobias says hi08:58
Chipacaaugh09:55
Chipacapedronis: please let me know you're editing a pr i'm working on09:55
Chipacamvo: I'm off to prep for the trip; telegram works09:57
mvoChipaca: thanks09:59
=== alan_g_ is now known as alan_g
zygaRe11:10
zygaJust getting coffee, cannot wake up today. Paperwork for Lucy is done. I will work on the patches mvo knows about now11:10
zygaok back now11:21
zygamvo: anything urgent to jump at instead of the patches?11:22
zygaguess not11:29
zygapstolowski: hey11:31
zygaon 2nd though, about your question on ConnRef11:31
zygaI was wondering if this is really the tip of a larger problem to address11:32
zygalet's not change that method yet please, we can discuss on Sunday, ok?11:32
pstolowskizyga: 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
mupPR #6511: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>11:34
pstolowskizyga: i've a change for repo ready in a separate branch (worked on this morning), but yeah, i'm kinda unsure about this11:34
pstolowskizyga: the fix for api should land though11:35
zyga+111:35
zygapstolowski: my feeling is that repo needs to become transactional OR we need to change locking semantics entirely11:36
zyga(caller locks)11:36
pstolowskizyga: yes11:36
pstolowskizyga: it was all kinda ok when we only acessed repo from tasks and all accesses were locked by state11:37
zygayeah11:37
zygaI agree11:37
pstolowskizyga: then i introduced repo access in api, for disconnect and hooks11:37
pstolowskizyga: so yeah, let's talk in malta11:38
mupPR snapd#6512 opened: overlord: fix random typos <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6512>11:41
zygaquick trivial ^11:42
mvozyga: thank you!11:48
zygahey mvo :)11:48
mvozyga: patches are the most important thing right now11:48
mvopedronis: lp-1813963 failed, I saw this before, I think we should disable this test, it seems to be unreliable11:49
zygaoh?11:50
zygahow does it fail?11:51
zygamvo: ?11:56
mvozyga: https://paste.ubuntu.com/p/fB35ntFNFv/12:00
mvozyga: we can investigate in a bit but probably simply a dirty dmesg12:01
zygahmmmm12:02
zygait's unlikely12:02
zygaI clean dmesg explicitly12:02
zygafeels like worth having a look to just get the denials12:02
zygadid you get the debug part as well?12:02
mvozyga: let me see if I find it12:05
mvozyga: for reference full log is https://api.travis-ci.org/v3/job/493672747/log.txt12:05
mvozyga: it dies in prepare12:06
mvozyga: [ 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
zygathanks, let me look at one thing quickly12:06
zygahmmmm12:07
zygainteresting12:08
zygait's a real bug, the fix is simple but this is curious12:08
zygamvo: something like this12:10
zygahttps://www.irccloud.com/pastebin/bxOqgLJE/12:10
mvozyga: makes sesne, isn't that kind of central to how alarm() works, makes me wonder why we did not hit this earlier - oh well12:13
mvozyga: or am I missing things?12:13
zygamvo: it's not in snap-confine12:13
zygalook at the profile name12:13
zygait's sun12:13
mvozyga: its snap-update-ns, right?12:13
zygaprobably the mocked sun binary12:13
zygayour simplification I suspect12:13
mvozyga: aha12:13
zygabut I don't recall what was done there in the end12:13
mvozyga: its a simple time.Sleep(31s)12:14
zygahmm12:14
zygaso real sun doesn't need this12:14
zygaso we're back to changing things for a test12:14
zygabut at  the same time I think this is super safe12:14
zygait's self-signaling12:14
zygashould be allowed12:14
zygawe're not allowing it only becaue we're not using any of the typical abstractions12:14
mvozyga: we could just extend the profile in the test, yes?12:15
zyganah, just extend the template12:15
zygait's way less headache12:15
zyga(see what I did to make the template different just for the test before)12:15
mvozyga: true12:15
mvozyga: 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
mvozyga: does that make sense?12:16
mvozyga: then you can focus on the other thing you work on right now :)12:16
mvoETOOMUCH12:16
zygayes12:17
zygaI'm not interrupting the other patches I'm working on12:17
zygabut I can propose this by EOD  if nobody does12:17
* mvo vanishes for lunch for some minutes12:17
mvozyga: thanks12:17
pstolowskizyga, mvo i can do that12:27
zygapstolowski: some food for thoght12:46
zygapstolowski: no device cgroup12:46
zygapstolowski: no udev tagging for any device assignment12:46
zygapstolowski: (scratch that, no udev tagging like we currently do, we can keep the tagging part)12:47
zygapstolowski: udev tagging invokes small binary that modifies certain persistent kernel objects12:47
zygapstolowski: device filtering only as eBPF programs12:48
zygamvo: I replied on the patches thread12:49
zygamvo: please advise on preferred approach12:50
zygapstolowski: in my head this is working as follows: we create and update, on demand, kernel objects representing access permissions for a given snap12:53
zygapstolowski: all snaps launch with a eBPF program that controls device access12:53
zygapstolowski: snap-device-helper mostly goes away (would need to be rewritten as a small C program)12:54
pstolowskizyga, interesting!12:54
zygapstolowski: alternatively, as a snapctl thing but I think that is problematic (early boot)12:54
zygapstolowski: the persistent objects are described by bpf(2) man page12:55
* zyga AFK for more errands12:59
pstolowskizyga: looks extremely interesting, thanks12:59
pstolowskiwill take a look12:59
* pstolowski lucnh12:59
mupPR snapd#6513 opened: [RFC] many: support `snap install --skip-service-start` <Created by chipaca> <https://github.com/snapcore/snapd/pull/6513>13:02
Chipacamvo, pedronis, popey & Wimpress: ^?13:03
Chipacapedronis: it's a very minor complication to doInstall, IMHO, and it'll help people that're currently suffering13:04
* Chipaca goes back to trip prep13:04
pedronisChipaca: it seems a bit too specific, a commented a bit13:16
pedronisI commented13:16
=== ricab is now known as ricab|lunch
kjackalHi snappy people this page from the official docs seems to be missing https://docs.snapcraft.io/123913:55
mvoChipaca: nice!13:56
Chipacakjackal: where did you get that link?14:00
Chipacakjackal: that's not part of the official docs, and it shouldn't be linked to from the official docs14:01
Chipacakjackal: that's https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/123914:01
degvilleChipaca / kjackal: all those posts are published currently - it's probably not linked anywhere. But there's an issue for removing them.14:01
Chipacayeah the docs thing should only be serving 'docs'14:01
Chipaca¯\_(ツ)_/¯14:01
degvillekjackal: I think we can add to that page though to make it clearer.14:01
degvillekjackal: (with info from the responses to the question - and thanks for the question)14:02
kjackaldegville: Chipaca: I go to this page from the official docs by searching for "schedule". First link.14:03
mupPR 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
kjackalSo where is the official docs for snap refresh scheduling?14:03
degvillekjackal: https://docs.snapcraft.io/keeping-snaps-up-to-date/702214:04
kjackalAwesome, thank you14:04
degvillenp. thanks for flagging the issue.14:04
mupPR 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
zygapstolowski: did you push that one-liner by any chance?14:41
zygait will fix master14:41
kenvandinezyga: in case i haven't said this before... thanks for layouts!14:42
kenvandinesooooooo useful14:42
zyga:love: :)14:42
zygathank you14:42
zygaI'm making them better14:42
zygajust slow to land stuff14:42
kenvandineso many snaps with the same copy and pasted parts to for handling relocation14:42
kenvandinethat i can remove now14:42
kenvandinelike iso-codes14:42
tomwardillhi 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
Chipacatomwardill: yes14:45
Chipaca1 sec14:46
Chipacatomwardill: 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=chipaca14:46
pstolowskizyga: pushing14:47
tomwardillChipaca: ah, that will do nicely, thanks!14:47
mupPR snapd#6514 opened: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <https://github.com/snapcore/snapd/pull/6514>14:48
pstolowskipedronis, 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 needed14:51
mupPR #6511: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>14:51
pstolowskizyga: pushed #651414:51
mupPR #6514: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <https://github.com/snapcore/snapd/pull/6514>14:51
zygathnx14:53
zygapstolowski: you have feedback on your PR14:53
pstolowskiupdated14:58
=== ricab|lunch is now known as ricba
=== ricba is now known as ricab
* cachio lunch15:08
Chipacatomwardill: ah, also, https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c653715:14
tomwardillChipaca: ooh, excellent. I was just having 'fun' with trying to human parse the journal logs :)15:15
Chipacayeah15:15
mupPR 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
mvopedronis, 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=015:19
mvo 15:19
* mvo runs again15:19
mupBug #1816073 opened: snap info does not scope to brand store <Snappy:New> <https://launchpad.net/bugs/1816073>15:20
zygamvo: that makes no sense, it passed but was denieid15:22
zygait makes me feel that the test is flawed and cannot detect service being broken correctly15:22
mvozyga: I don't think the test is broken, something else is strange15:26
zygaI agree with strange15:26
BjornThi. 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
Chipacamvo: I'm guessing 6515 means I'm going to have to merge master again15:29
zygaBjornT: snap try uses a local bind mount15:29
zygaBjornT: snap install uses snapfuse15:29
mupBug #1816073 changed: snap info does not scope to brand store <Snappy:Invalid> <Snap Store:Invalid> <https://launchpad.net/bugs/1816073>15:30
zygaBjornT: can you please report a bug on launchpad.net/snapd with the details of the container (how to reproduce yor setup)15:30
zygaBjornT: I cannot promise any quick fix but Friday and people are about to go away for travel and errands next week15:30
BjornTzyga: ah, that explains that. sure, i'll report a bug15:30
zygaBjornT: note that snapd doesn't actively detect all unsupported container environments15:31
zygaBjornT: tl;dr; recent versions of lxd on recent kernels work, everything else is a "maybe"15:31
zygaBjornT: privileged containers don't work with snapd15:31
BjornTzyga: does bionic count as 'recent'?15:32
zygaBjornT: yes15:32
zyga16.04+15:32
BjornTok, that's good15:32
zygamvo: gah, I think seccomp is just really more buggy15:45
mvoChipaca: maybe, lets see if my change helps15:59
mupPR 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
mvozyga: just fyi - adding "/usr/lib/snapd/snap-exec m,16:04
mvo" seems to be not helping :/16:04
mvozyga: hold on, silly me16:04
zygawhat are you getting?16:04
mvozyga: sorry, it does fix it16:04
mvozyga: so 6515 is the workaround for the test fix16:05
zygaok16:06
zygaI'm doubting libseccomp16:06
zygathe pfc program is garbage16:06
zygaI'm using the disassembler from the kernel to check16:06
zygasanity testing on other arches now16:09
DonAlexOK can someone tell me why I get launch failed: instance "<snap-name>" already exists when I try re running snapcraft ?17:08
DonAlexHow do I stop the instance so i can rebuild with different options ?17:09
=== pstolowski is now known as pstolowski|afk
ChipacaDonAlex: you still there?18:00
mupPR 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
pedronisI merged master again into #6506 (so get that ^)18:51
mupPR #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
mvopedronis: great18:51
mupPR snapcraft#2473 opened: cli: validate schemas before invoking provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2473>19:05
mupPR snapd#6516 opened: interfaces/seccomp: generate global seccomp profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6516>19:13
bdxhello22:20
bdxis 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!