| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#2159 closed: many: extract lifecycle ordering into own module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2159> | 02:53 |
|---|---|---|
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === prime is now known as Guest35617 | ||
| mborzecki | morning | 05:05 |
| zyga | Good day | 06:05 |
| zyga | mborzecki: thank you for the review | 06:05 |
| mborzecki | zyga: hey | 06:05 |
| mborzecki | zyga: sorry for doing it late, went for a quick bike route, prepped the dinner and only then came back to do the review | 06:06 |
| zyga | No worries | 06:07 |
| zyga | kyrofa: found a bug in hook environment | 06:07 |
| zyga | There is a pr | 06:07 |
| zyga | I think we need to respin 2.33 | 06:07 |
| mborzecki | hmm, why were there newlines used in hook env? | 06:10 |
| zyga | no idea | 06:12 |
| zyga | old bug | 06:12 |
| zyga | I think we used to have the same bug in app env | 06:12 |
| zyga | but it was fixed for apps | 06:12 |
| mborzecki | right, it was fixed for apps back in 2.23 | 06:21 |
| mborzecki | and the \n was introduced in 2.11 | 06:22 |
| zyga | hey mvo | 06:42 |
| zyga | some bad 2.33 news perhaps | 06:42 |
| mvo | hey zyga | 06:42 |
| mvo | zyga: good morning - tell me more please | 06:43 |
| zyga | there's a small PR that fixes an embarrassing issue in hooks | 06:43 |
| zyga | https://github.com/snapcore/snapd/pull/5302 | 06:43 |
| mup | PR #5302: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302> | 06:43 |
| zyga | so maybe new 2.33 needed | 06:43 |
| mvo | zyga: what is the impact of the issue? | 06:44 |
| zyga | hooks that use environment get broken values | 06:45 |
| zyga | the newlines mess something up apparently | 06:45 |
| mvo | zyga: uh, ok. is this a regression? | 06:45 |
| zyga | ha, good question | 06:45 |
| zyga | if so it is very old | 06:45 |
| zyga | mborzecki found that it got broken in 2.11 | 06:45 |
| mvo | zyga: ok, thanks for the investigation! | 06:46 |
| zyga | mvo: all the kudos go to kyrofa | 06:46 |
| * mvo hugs kyrofa | 06:47 | |
| mborzecki | introduced back in 2.11, 2.23 fixed AppInfo.Env(), but hooks env was left intact (probably because \n seemed special to begin with) | 06:47 |
| mvo | zyga: does http://paste.ubuntu.com/p/ggZryMrdQm/ ring a bell (cc mborzecki ) | 06:52 |
| mvo | zyga: i.e. [Mon Jun 11 13:21:08 2018] audit: type=1400 audit(1528723268.368:2393): apparmor="DENIED" operation="signal" profile="snap-update-ns.test-snapd-service-watchdog" pid=1 comm="systemd" requested_mask="receive" denied_mask="receive" signal=abrt peer="unconfined" | 06:52 |
| mvo | this is an autopkgtest failure on arm64 | 06:52 |
| zyga | this says that "systemd" running with the snap-update-ns.test-snapd-service-watchdog label (I presume a C helper?) cannot receive SIGABRT from an unconfined process | 06:53 |
| zyga | so if something kills snap-update-ns it won't get the signal | 06:53 |
| zyga | I think that warrants a patch | 06:54 |
| mborzecki | hmm | 06:54 |
| mborzecki | there were some changes recently to signals | 06:54 |
| mborzecki | from jdstrand, about receiving the signals from unconfined processes or somesuch | 06:54 |
| zyga | mvo: I'll make a PR in a sec | 06:56 |
| mborzecki | nvm, that change from jamie was about signals from other snaps | 06:56 |
| mborzecki | mvo: is the system in which this happens super slow? maybe it hit the watchdog timeout already (i.e. while the snap is still starting) in which case systemd sends sigabrt | 06:59 |
| zyga | mvo: #5303 | 07:00 |
| mup | PR #5303: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5303> | 07:00 |
| mup | PR snapd#5303 opened: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5303> | 07:00 |
| mvo | mborzecki: its an arm64 it is probably not fast, not sure if super slow though, let me try to guestimate | 07:01 |
| zyga | mvo: wait, did something enable the watchdog along the way? | 07:02 |
| mvo | mborzecki: a full testsuite run take 3h15 which there, on amd64 its ~1:15h or so | 07:02 |
| mvo | zyga: I think this is part of the test | 07:02 |
| mborzecki | zyga: it's part of the test | 07:02 |
| zyga | ah | 07:02 |
| zyga | ok | 07:02 |
| mvo | mborzecki, zyga do you think this denial is just noice or could it be the reason for the failure? | 07:03 |
| zyga | it's not noise for sure, | 07:03 |
| zyga | apparmor is fun | 07:03 |
| zyga | you can confine a process so that it cannot be SIGKILLed | 07:03 |
| zyga | just deny signals | 07:04 |
| zyga | and that's that | 07:04 |
| mvo | mborzecki: we give it 20s to restart, no? so even slow shouldn't be that slow | 07:04 |
| mvo | mborzecki: (?) | 07:04 |
| mborzecki | mvo: it's using update-ns profile, iirc that's suppsoed to be used when s-c runs s-u-n (zyga?) | 07:04 |
| mborzecki | and then it switches to the app profile | 07:04 |
| mvo | its fun, the fatest is actually ppc64el afaict | 07:04 |
| zyga | mborzecki: that's correct | 07:04 |
| zyga | snap run foo -> snap-confine -> snap-update-ns.foo -> snap.foo.foo | 07:05 |
| zyga | that's the profile transition chain | 07:05 |
| mborzecki | mvo: so what happens, is that it's still runnign with s-u-n profile while it gets abrt, hence the quesion about that host being super slow :P | 07:05 |
| zyga | what I don't get is how it can run comm="systemd" | 07:06 |
| zyga | that's weird | 07:06 |
| pstolowski | mornings | 07:07 |
| zyga | pstolowski: good morning | 07:07 |
| mvo | zyga, mborzecki I upload it to comisc to get another autopkgtest run with this fix in | 07:07 |
| mborzecki | pstolowski: hey | 07:07 |
| zyga | pstolowski: can you please look at #5302 | 07:07 |
| mvo | hey pstolowski | 07:07 |
| zyga | mvo: is you do a new upload then please consider the hook | 07:07 |
| mup | PR #5302: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302> | 07:07 |
| mvo | zyga: yeah, I will mark it for 2.33 | 07:07 |
| zyga | let pawel review it | 07:08 |
| mvo | zyga: this will be a cosmic only upload | 07:08 |
| zyga | I think the patch can be reduced | 07:08 |
| zyga | Kyle did some refactoring there as well | 07:08 |
| mborzecki | zyga: i'm looking at #5303 and #5174, the comment in 5174 mentions that we allow receiving signals from uconfined in the base abstraction (the template right?) | 07:08 |
| mup | PR #5303: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5303> | 07:08 |
| mup | PR #5174: interfaces/default,process-control: miscellaneous signal policy fixes <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5174> | 07:08 |
| zyga | mborzecki: base abstraction is something else | 07:09 |
| * zyga looks | 07:09 | |
| mvo | zyga: just looked at it, fun bug (the env one) | 07:09 |
| zyga | mborzecki: snap-update-ns is not including any abstractions | 07:09 |
| zyga | this is why (probably) it has this issue | 07:09 |
| zyga | mvo: I think 5303 ought to be seen by jdstrand | 07:18 |
| zyga | but he won't be around until afternoon | 07:18 |
| mup | PR snapd#5302 closed: snap: don't include newline in hook environment <Created by kyrofa> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5302> | 07:40 |
| pedronis | pstolowski: hi, I need to reuse code similar doAutoConnect but checkConnectConflicts doesn't quite fit as it is, otoh I noticed there are some simplications that can be done there now that we moved the checks before/out of the connect bit, I'll propose a small PR with just that, that you can look at | 07:47 |
| pstolowski | pedronis: hey, sounds good, thanks | 07:48 |
| mborzecki | people seem to be building the aur package on most interesting setups, got one report that building fails, the guy is using clang (with ld), and ld is not there (?), another one https://paste.ubuntu.com/p/YbyN6Mtpvn/ i think it's behind some proxy that either cuts the network or does some bad stuff to the headers | 07:53 |
| mvo | zyga: thats fine, no worries about 5303 | 08:03 |
| mvo | zyga: afternoon is early enough | 08:03 |
| mvo | zyga: so far its only an issue on arm64 | 08:03 |
| zyga | ack | 08:05 |
| Chipaca | nack | 08:06 |
| * Chipaca plays it safe | 08:06 | |
| zyga | quack | 08:06 |
| * Chipaca 's space bar is still not debouncing properly | 08:06 | |
| * zyga plays it eco | 08:06 | |
| * Chipaca plays 'It' in C# | 08:07 | |
| * Chipaca notes C# is D because # == ♯♯ but most people don't care | 08:07 | |
| Chipaca | huh, wikipedia actually says # is 1.5 semis | 08:09 |
| Chipaca | oh well, i've been lied to before this | 08:09 |
| Chipaca | and by better people than my music teacher | 08:10 |
| mup | PR snapd#5304 opened: overlord/ifacestate: simplify checkConnectConflicts and also connect signature <Created by pedronis> <https://github.com/snapcore/snapd/pull/5304> | 08:12 |
| pedronis | pstolowski: ^ , I will look over the disconnect one in a little bit | 08:13 |
| cjwatson | I've certainly never seen double-sharp notated in any way other than ♯♯ or 𝄪 | 08:13 |
| pstolowski | pedronis: thanks | 08:14 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#5299 closed: tests: publish test-snapd-appstreamid for any architecture <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5299> | 08:30 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | pedronis: do you think i should push the store changes to #5253? | 08:44 |
| mup | PR #5253: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5253> | 08:45 |
| * zyga -> brief walk | 08:47 | |
| pedronis | mborzecki: we need to think a bit | 08:48 |
| pedronis | how we want to proceed | 08:48 |
| mborzecki | pedronis: the renames and snapsup changes should be fairly benign | 08:48 |
| mborzecki | (or at least not break things) | 08:49 |
| mborzecki | and subsequent reviews would be much smaller | 08:49 |
| pedronis | mborzecki: but some bits are not just renames, those bits need tests of some form | 08:50 |
| pedronis | also landing will disrupt Chipaca's work | 08:51 |
| mborzecki | pedronis: i think we should land Chipaca's pr first, pulling in master to my branch is not a problem | 08:53 |
| pedronis | mborzecki: either you are not blocked, it's probably a good time to separately write some failing spread tests and mangers_test.go you want to pass at some point | 08:54 |
| pedronis | mborzecki: I need to look at the rename PRs to see what is doable there | 08:57 |
| pedronis | mborzecki: John's PR need a 2nd review btw | 08:58 |
| mborzecki | pedronis: have it open already :P | 08:58 |
| popey | if I build a snap against base: core18, will it automatically connect to the interfaces in core18? | 09:16 |
| popey | I can't see any way to identify which base snap the app snap is connected to | 09:16 |
| pedronis | popey: that is still to be defined, but really core interfaces are system interfaces (core was just use to attach them somewhere), so unlikely they would connect to a base in the new world | 09:17 |
| popey | hm. i have a core18 snap which just dies on its arse, and I can't see what it's connected to | 09:18 |
| pedronis | on classic system right now they connect ot core | 09:18 |
| jamesh | maybe you could hang the implicit interfaces off the snapd snap? | 09:18 |
| pedronis | that's one of the ideas floating around | 09:19 |
| pedronis | but I was confused, that discussion really applies to core systems | 09:19 |
| pedronis | popey: they will connect to "core", the problem is that nothing probably brings it in unless it's already there | 09:19 |
| popey | i have core and core18 installed | 09:20 |
| pedronis | ok, then they should connect to core | 09:20 |
| zyga | re | 09:20 |
| popey | but I want them to connect to core18 | 09:20 |
| pedronis | nothing changed about that on classic | 09:20 |
| pedronis | popey: that doesn't mean anything | 09:20 |
| popey | I built the app in an 1804 container | 09:20 |
| pedronis | that's not releated to intefaces | 09:20 |
| pedronis | what interface is giving you problems? | 09:21 |
| popey | i dont know, I'm trying to debug | 09:21 |
| pedronis | there might be corner cases about intefaces that give access to binaries, but even connected to core, you would get the binaries in core18 | 09:21 |
| pedronis | (of course the interfaces cannot give access to core18-only binaries) | 09:22 |
| jamesh | popey: interfaces like "desktop" are about connecting to the host system: they don't have a whole lot to do with the minimal root file system shown in the sandbox | 09:22 |
| jamesh | a desktop snap based on "core" is doing pretty much the same thing as a desktop snap based on "core18" | 09:23 |
| popey | huh. okay. thanks. | 09:24 |
| pedronis | I mean there might be also an approach in which we do connect to the base (but it would be more about the base controlling the subset of host interfaces that make sense), that model though is quite a bit of changes from the status quo | 09:26 |
| pedronis | we might do it at a later point (don't know) | 09:26 |
| Chipaca | mborzecki: if spread fails, I'll add the validator | 09:26 |
| Chipaca | mborzecki: otherwise I'll merge :-) | 09:26 |
| mborzecki | Chipaca: it failed, but i restarted the build already :) not a blocker though, i can add it with my changes | 09:27 |
| Chipaca | mborzecki: hah. Well then, if it fails *again* :-D | 09:27 |
| pedronis | mborzecki: I think what we should do is that I should look at the rename PR again (after I have done some other things I owe though), and then we should try to have a HO | 09:27 |
| Chipaca | pedronis: rename as in rename a snap? | 09:29 |
| mborzecki | pedronis: ok | 09:29 |
| mborzecki | Chipaca: rename as in snap.Info.Name() -> snap.Info.(Instance|Store)Name() | 09:29 |
| pedronis | Chipaca: no, s/Name/InstanceName/ and frieends | 09:30 |
| Chipaca | aww | 09:30 |
| mborzecki | Chipaca: 5253 if you want to take a look | 09:30 |
| Chipaca | i got my hopes up for a bit | 09:30 |
| mvo | popey: what error do you see? could you pastebin or make the snap(craft.yaml) availabe? maybe we can help with the debug? | 09:38 |
| popey | mvo: thanks. It's kdenlive. I've built the snap in an 18.04 container. It just dies. Nothing useful on the command line. Nothing much in dmesg | 09:47 |
| popey | only an apparmor dnial trying to look at /proc/sys/kernel/core_pattern | 09:48 |
| popey | so I presume it wants to core dump | 09:48 |
| popey | I can send you the snap if you're interested | 09:48 |
| mvo | popey: yeah, if you could make it available that would be great, at least I could give it a poke | 09:49 |
| popey | do you have wormhole installed? | 09:50 |
| pedronis | pstolowski: I added some comments to the disconnect hooks PR | 10:15 |
| pstolowski | ty | 10:16 |
| pedronis | pstolowski: do take a look at my PR when you have moment, it will conflicts but should also simplify some stuff in that PR | 10:21 |
| pstolowski | pedronis: will do soon | 10:23 |
| pedronis | mvo: did you see my comments in #5276 and #5301 ? | 10:28 |
| mup | PR #5276: devicestate: support seeding from a base snap instead of core <Created by mvo5> <https://github.com/snapcore/snapd/pull/5276> | 10:28 |
| mup | PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301> | 10:28 |
| mvo | pedronis: yes, will work on those in a little bit | 10:34 |
| mup | PR snapd#5305 opened: interfaces/policy: test that base policy can be parsed <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5305> | 10:44 |
| mup | PR snapd#5306 opened: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306> | 10:45 |
| mborzecki | zyga: ^^ | 10:45 |
| zyga | I just saw this while opening my own PR | 10:45 |
| zyga | looking | 10:46 |
| pstolowski | pedronis: +1 with one remark re auto name | 11:03 |
| mborzecki | google:ubuntu-16.04-64:tests/main/interfaces-contacts-service started failing recently | 11:11 |
| mborzecki | https://paste.ubuntu.com/p/w9gC7PBWCX/ | 11:14 |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | mborzecki: reviewed | 11:21 |
| pedronis | pstolowski|lunch: I listed some options there, but I also agree we could do the rename later in your PR | 11:33 |
| mborzecki | zyga: thx, pushing fixes in a minute | 11:34 |
| Chipaca | pstolowski|lunch: is #1776466 something you have on your plate? | 11:56 |
| mup | Bug #1776466: snap get with multiple values does not return json <snapd (Ubuntu):New> <https://launchpad.net/bugs/1776466> | 11:56 |
| pedronis | mborzecki: I did a pass over the whole 5253, there are some open questions and it doesn't seem landable atm as it is, let me know when you want to chat | 12:06 |
| mup | PR snapd#5307 opened: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307> | 12:20 |
| mup | PR snapd#5283 closed: snapstate: get rid of needsMaybeCore <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5283> | 12:22 |
| mup | PR snapd#5286 closed: snapstate: fix assumptions about core in setup phase2 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5286> | 12:22 |
| zyga | mborzecki: can you please look at 5307 | 12:27 |
| zyga | mvo: 5303 needs a 2nd review | 12:29 |
| zyga | jdstrand: thank you for the review! | 12:30 |
| zyga | jdstrand: I need to make the list of hard-coded mount operations in snap-confine partially optional | 12:30 |
| zyga | jdstrand: specifically the /mnt directory must not be required as some existing bases (probably just the test ones) don't have it | 12:30 |
| zyga | jdstrand: I made a PR that makes this possible #5307 | 12:31 |
| mup | PR #5307: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307> | 12:31 |
| mup | PR snapd#5308 opened: tests: skip "try" test on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/5308> | 12:31 |
| zyga | jdstrand: I chose to use mount directly to avoid adding a lot of boilerplate | 12:31 |
| jdstrand | zyga: I'd need to look at it more closely. it isn't exciting that it is broken out the way it is, but it also isn't that much and might even be cleaner the way you did it | 12:34 |
| zyga | jdstrand: I implemented the "full" way initially, that is extra function that doesn't fail, propagates the error, etc | 12:34 |
| zyga | but then it could not do the nice error formatting anymore because as an utility it could not just drop privs | 12:35 |
| zyga | so I went this way | 12:35 |
| zyga | jdstrand: I have two branches on GitHub that show where this is going, the one with the full history is feature/legacy-mnt-iface | 12:36 |
| zyga | I'm now adding spread tests to it | 12:36 |
| jdstrand | ok | 12:36 |
| zyga | this is the rough diff | 12:37 |
| zyga | https://github.com/snapcore/snapd/compare/master...zyga:feature/legacy-mnt-iface?expand=1 | 12:37 |
| zyga | jdstrand: the only thing I wasn't sure about was the apparmor rule | 12:37 |
| zyga | jdstrand: I used: +/mnt/*/** rwk, | 12:37 |
| zyga | coupled with /mnt/ r, | 12:37 |
| zyga | so that you cannot make new things in /mnt but you can see the existing ones and you can write to things there already | 12:37 |
| zyga | (that was my intent) | 12:37 |
| pedronis | mmh, now I got: + lxd.lxc stop my-ubuntu --force | 12:43 |
| pedronis | Error: The container is already stopped | 12:43 |
| pedronis | Try `lxc info --show-log my-ubuntu` for more info | 12:43 |
| pedronis | from the lxd test | 12:43 |
| jdstrand | zyga: to achieve that in the most compatible way, you would want: /mnt/{,*/} r, /mnt/*/** rwk, | 12:44 |
| pedronis | pstolowski|lunch: I adressed your comment in #5221 | 12:44 |
| mup | PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221> | 12:44 |
| === pstolowski|lunch is now known as pstolowski | ||
| jdstrand | zyga: I also don't think 'legacy-mnt' is right. the fhs defines it as "This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run." | 12:46 |
| jdstrand | zyga: in practice, users use it for more than temporary access though | 12:46 |
| zyga | jdstrand: are you suggesting that we don't do any new interface or just call it in a different way? | 12:46 |
| jdstrand | rename it | 12:47 |
| zyga | I used the word legacy because typically people don't really do things like that (or care about using /mnt specifically). Most users just get auto-mounts via /media | 12:48 |
| zyga | do you have a suggestion for a better name? | 12:48 |
| mvo | pedronis: I updated 5276 | 12:48 |
| mvo | pedronis: and the other one (5301) | 12:48 |
| mvo | pedronis: but no rush | 12:48 |
| jdstrand | I'm not sure what. mount-local? local-mount? mnt? | 12:48 |
| jdstrand | zyga: how about start with 'mnt' since it takes inspiration from 'home' with the understanding that it'll probably change in PR review | 12:49 |
| zyga | +1 | 12:50 |
| jdstrand | zyga: I understand why you chose legacy, but it isn't actually a legacy interface. it serves a real purpose in the modern world (users use it wrong of course) | 12:50 |
| jdstrand | anyway. I'll think about it | 12:51 |
| jdstrand | we should all think about it :) | 12:51 |
| zyga | jdstrand: sure, I don't mind changing the name at all | 12:51 |
| zyga | jdstrand: once the prerequisites land I will rename it | 12:51 |
| pedronis | mvo: I looked at 5301, the other one needs to wait, I have standup and then another meeting | 12:52 |
| jdstrand | zyga: just for completeness, I don't care for -support because it implies being able to do mount() operations and -observe isn't right cause it allows 'w'rite | 12:52 |
| jdstrand | zyga: -control also implies mount() | 12:53 |
| jdstrand | more so than -support | 12:53 |
| jdstrand | so, yeah, not sure yet | 12:53 |
| mvo | pedronis: ta | 12:58 |
| Saviq | hi all, can someone please comment on bug #1776295 whether it's by design or indeed a bug? | 13:30 |
| mup | Bug #1776295: `stop` and `disable` should kill all processes regardless of daemon stop-mode <snapd:New> <https://launchpad.net/bugs/1776295> | 13:30 |
| zyga | Saviq: ack | 13:37 |
| zyga | Saviq: replied | 13:39 |
| Son_Goku | zyga, mvo, niemeyer: https://src.fedoraproject.org/rpms/plasma-discover/c/31053b99061eb17bb29f7fd1142c9bd614247238 | 13:42 |
| zyga | Son_Goku: very nice :) | 13:42 |
| zyga | any issues? | 13:42 |
| Son_Goku | well, discover no longer crashes when the plugin isn't installed :) | 13:43 |
| Son_Goku | so that's a plus | 13:43 |
| Son_Goku | however, the plugin crashes when no desktop portal implementation is installed | 13:43 |
| Son_Goku | we're fixing that now in the KDE Plasma 5.13.0 rebase going on now | 13:43 |
| Son_Goku | but yeah, basically since the snap plugin isn't horrifically broken anymore, I figure it's worth enabling | 13:45 |
| Son_Goku | people using snapd on Fedora KDE will get the plugin installed automatically when they upgrade to Plasma 5.13 | 13:45 |
| cachio | mborzecki, hey | 13:48 |
| zyga | joc: hey, you have some feedback on https://github.com/snapcore/snapd/pull/5279 | 13:52 |
| mup | PR #5279: interfaces/builtin: create socketcan interface <Created by jocave> <https://github.com/snapcore/snapd/pull/5279> | 13:52 |
| mborzecki | zyga: https://github.com/bboozzoo/aur-snapd/pull/7 | 13:54 |
| mup | PR bboozzoo/aur-snapd#7: snapd: use budled release pacakage, bump to 2.33-2 <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/7> | 13:54 |
| zyga | mborzecki: +1 | 13:55 |
| joc | zyga: yep thanks, did the fix for travis already, will address Jamie's comments now | 13:55 |
| zyga | super, thank you | 13:56 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | cachio: https://paste.ubuntu.com/p/SdQpcvyQWk/ line 1670 is when the timer is started, then gets stopped and never comes back | 14:16 |
| cachio | mborzecki, yes | 14:17 |
| mborzecki | cachio: 1662 snap-repair starts | 14:17 |
| mborzecki | there's 2 instances of snap-repair running? | 14:17 |
| mborzecki | zyga: i've updated #5306 | 14:18 |
| mup | PR #5306: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306> | 14:18 |
| cachio | mborzecki, it ran this test at thtat time | 14:19 |
| cachio | https://paste.ubuntu.com/p/yKYkVSyyDk/ | 14:20 |
| cachio | mborzecki, I think the tst ubuntu-core-snapd-run-from-snap is causing that | 14:22 |
| cachio | I'll rereun just those two to see | 14:23 |
| mborzecki | cachio: ok, use the same seed, and just one worker | 14:24 |
| cachio | mborzecki, I am also running this to see how the env is after the test | 14:26 |
| cachio | spread -shell-after google:ubuntu-core-16-64:tests/main/ubuntu-core-snapd-run-from-snap | 14:26 |
| niemeyer | Son_Goku: Nice! Was it just a matter of enabling it or is this just the tip of a long series of patches? | 14:34 |
| Son_Goku | now it's just a matter of enabling it | 14:36 |
| Son_Goku | earlier iterations of the backend plugin were too unstable to use | 14:37 |
| Son_Goku | the implementation in discover is better than the one in gnome-software, which needs to be rectified | 14:37 |
| Son_Goku | there's a lot of issues with g-s because the work you guys have done in Ubuntu Software hasn't been getting upstreamed | 14:37 |
| Son_Goku | I checked recently in gitlab.gnome.org, and I haven't seen any proposals to submit those changes | 14:38 |
| Son_Goku | and since hughsie maintains the Fedora package _and_ upstream g-s, my hands are tied unless the Ubuntu g-s/u-s maintainer upstreams those changes | 14:39 |
| * zyga needs to handle some errands (accountant), ttyl | 14:39 | |
| Son_Goku | I gotta go to work now... | 14:41 |
| Son_Goku | niemeyer, could you try to follow up with the g-s maintainer in Ubuntu about getting the improvements upstreamed? | 14:41 |
| Son_Goku | even the simplest thing of being able to see different tracks doesn't work in upstream g-s | 14:42 |
| cachio | mborzecki, confirmed | 14:42 |
| mborzecki | hah | 14:42 |
| cachio | ubuntu-core-snapd-run-from-snap is the reason | 14:42 |
| mborzecki | cachio: so the quesion is now, is that test doing something wrong, or is it something else? | 14:43 |
| cachio | mborzecki, in the restore it is doint rm -f /run/systemd/system/snapd.* | 14:44 |
| cachio | mborzecki, not sure yet, it is a weird test | 14:45 |
| mborzecki | cachio: but it's rm -f units in /run | 14:45 |
| mborzecki | maybe that daemon-reload is triggering this | 14:45 |
| cachio | I am running a shell session now | 14:46 |
| cachio | I'll debug it to see where it is making the mistake | 14:46 |
| mborzecki | cachio: ok, i see now | 14:46 |
| mborzecki | so snap-mgmt stop will stop all units (snap-repair.timer) among them | 14:47 |
| kenvandine | zyga, to reproduce the theme mount problem, install gtk-common-themes from edge and gnome-calculator from candidate | 14:47 |
| mborzecki | cachio: and in restore only snapd.{socket,service} are started | 14:47 |
| kenvandine | and snap run gnome-calculator | 14:47 |
| cachio | mborzecki, yes | 14:47 |
| zyga | kenvandine: what was the denial that you got? | 14:48 |
| kenvandine | 2018/06/12 10:17:13.182049 main.go:192: cannot change mount namespace of snap "gnome-calculator" according to change mount (/snap/gtk-common-themes/319/share/themes/Communitheme /snap/gnome-calculator/172/usr/share/themes/Communitheme none bind,ro 0 0): cannot create writable mimic over "/snap/gnome-calculator/172/usr/share": permission denied | 14:48 |
| cachio | we should restore all the snapd units | 14:48 |
| cachio | restart | 14:48 |
| mborzecki | cachio: probably systemctl start snapd.snap-repair.timer in that test's restore section will be enough | 14:48 |
| cachio | ok, let me try it | 14:49 |
| mborzecki | cachio: we know that the timer is started by default and gets stopped in the test, so starting it in restore seems fair | 14:49 |
| cachio | mborzecki, change made, testing now | 14:50 |
| cachio | lets, see | 14:50 |
| zyga | kenvandine what does “dmesg | grep DENIED” say? | 14:52 |
| kenvandine | [435791.168135] audit: type=1400 audit(1528813033.178:1735): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.gnome-calculator" name="/tmp/.snap/snap/gnome-calculator/172/usr/share/" pid=20539 comm="3" srcname="/snap/gnome-calculator/172/usr/share/" flags="rw, rbind" | 14:53 |
| kenvandine | zyga, it doesn't like mounting it over /usr/share | 14:54 |
| kenvandine | well $SNAP/usr/share | 14:54 |
| kenvandine | if i change it to $SNAP/share it's actually fine | 14:54 |
| mup | PR snapd#5305 closed: interfaces/policy: test that base policy can be parsed <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5305> | 14:55 |
| zyga | What is the content definition? | 14:55 |
| zyga | I will debug this asap but I need to run an errand now | 14:55 |
| kenvandine | gtk-3-themes: | 14:55 |
| kenvandine | interface: content | 14:55 |
| kenvandine | target: $SNAP/usr/share/themes | 14:55 |
| kenvandine | default-provider: gtk-common-themes | 14:55 |
| kenvandine | zyga, ^^ | 14:55 |
| kenvandine | zyga, i can change my snaps to use $SNAP/share/themes instead | 14:56 |
| kenvandine | but that also requires a change to the desktop helpers | 14:56 |
| mup | PR snapd#5309 opened: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309> | 14:56 |
| zyga | Thank you. I have all the information now | 14:56 |
| joc | jdstrand: was just working on the reply to the auto-connect question, it's there now | 14:59 |
| jdstrand | joc: thanks! | 14:59 |
| jdstrand | joc: yep, that was my thinking. thanks again :) | 15:00 |
| === leftyfb_ is now known as leftyfb | ||
| Chipaca | pedronis: you know this code better than I do: does the snap action call need any fields beyond download for the "install" action? | 15:09 |
| mup | PR snapd#5310 opened: tests: fix snapd-repair.timer on ubuntu-core-snapd-run- from-snap test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5310> | 15:15 |
| Chipaca | pedronis: looks like it also needs name, revision, snap id at least | 15:16 |
| pedronis | Chipaca: sorry, in a meeting | 15:29 |
| Chipaca | pedronis: no worries, mostly answered myself | 15:29 |
| mup | PR snapd#5298 closed: store, image: have 'snap download' use v2/refresh action=download <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5298> | 15:32 |
| kenvandine | zyga, you can ignore that issue... i found if i change the mount point it works fine and actually is probably more desirable | 15:35 |
| pedronis | Chipaca: I'm not sure I understand the question, you mean in terms of the result? or what we put in the action? | 15:36 |
| Chipaca | pedronis: currently we get everything, and we only need … a lot less than everything :-) | 15:37 |
| Chipaca | so looking at asking for just what we need | 15:37 |
| pedronis | Chipaca: ah, we need quite a few things though, type, snap-yaml probably more | 15:37 |
| pedronis | it's a bit hard to tell | 15:37 |
| zyga | kenvandine: ack, though I will get to the bottom of this anyway | 15:37 |
| Chipaca | pedronis: what do we need type and snap-yaml for? | 15:38 |
| pedronis | Chipaca: sorry, you were maing for "download", not for "install" ? | 15:39 |
| pedronis | *meaning | 15:39 |
| Chipaca | pedronis: :-/ yes | 15:40 |
| pedronis | Chipaca: you need to consiser the code in image.go too | 15:41 |
| Chipaca | pedronis: I added fields until it stopped complaining, because that's the sort of deep analytical work I do | 15:41 |
| Chipaca | hmm, that code does seem to use type | 15:42 |
| pedronis | Chipaca: I see at least Type and Contact | 15:42 |
| pedronis | and whatever is needed to compute NeedsDevMode | 15:43 |
| pedronis | I also expect soon we will need base and snap-yaml | 15:43 |
| pedronis | (to grab the base and default-providers) | 15:43 |
| pedronis | arguably we could also change the code though, to open the downloaded file once we have checked the assertions | 15:45 |
| Chipaca | pedronis: this only asking for the fields we want is what we want to do, right? | 15:45 |
| pedronis | it's reasonable, but then what I suggest, reopening in the snap in image after the assertion check | 15:46 |
| pedronis | is probably the best of both | 15:46 |
| pedronis | worlds | 15:46 |
| pedronis | we don't have to update the list | 15:47 |
| Chipaca | pedronis: hmmmmmmm | 15:47 |
| pedronis | Chipaca: it's not a complicated change I think | 15:47 |
| Chipaca | pedronis: I'll try | 15:49 |
| pedronis | Chipaca: notice that you want also all the fields to populate sideinfo likely | 15:49 |
| pedronis | I mean consulting the store and not asking those is probably wrong | 15:50 |
| Chipaca | pedronis: yeah | 15:51 |
| mup | PR snapd#5308 closed: tests: skip "try" test on s390x <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5308> | 15:51 |
| pedronis | Chipaca: any particular reason to do this btw? it's reasonable but prepare-image/download are propbably not super common in the gran scheme of things | 15:52 |
| mup | PR snapd#5303 closed: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5303> | 15:52 |
| Chipaca | pedronis: this felt like a low-hanging fruit and it turned out to be an araucaria | 15:53 |
| pedronis | it's not a low hanging fruit | 15:53 |
| pedronis | sorry | 15:53 |
| * cachio lunch | 15:53 | |
| pedronis | also because image.go will need to learn more tricks soon | 15:53 |
| Chipaca | grmbl | 15:53 |
| Chipaca | I'll just use it for conncheck then | 15:53 |
| Chipaca | ¯\_(ツ)_/¯ | 15:53 |
| Chipaca | i mean, i still want to give actions the optional fields thing | 15:53 |
| Chipaca | because, conncheck just wants the 'download' field | 15:54 |
| Chipaca | (and that one happens more often than snap download :) ) | 15:54 |
| pedronis | yes | 15:54 |
| pedronis | there is makes full sense and we are more in control | 15:54 |
| mvo | yay autopkgtest for cosmic green! | 16:00 |
| pedronis | mvo: re-reviewed #5276 | 16:12 |
| mup | PR #5276: devicestate: support seeding from a base snap instead of core <Created by mvo5> <https://github.com/snapcore/snapd/pull/5276> | 16:12 |
| pedronis | pstolowski: did you forget, could you re-vote in #5221 ? | 16:13 |
| mup | PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221> | 16:13 |
| pstolowski | pedronis: done | 16:15 |
| pedronis | thx | 16:15 |
| pedronis | ah, mvo looked at the first version only: niemeyer or mvo: I need a re-review of #5221 | 16:16 |
| mup | PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221> | 16:16 |
| mvo | pedronis: sure | 16:19 |
| niemeyer | pedronis: My main blocker there was the syntax, which we agreed on that call. If that's sorted per discussion and you're happy about the other points, LGTM | 16:23 |
| pedronis | niemeyer: yes, I changed the syntax to be as the last update in the topic | 16:23 |
| binarycreations | Hello there, I am attempting to create my first snap. I am running Arch Linux with the 4.14.48-1-LTS kernel, I am trying to get my head around how all the concepts work. Is my current host OS going to be supported by snapcraft? | 16:34 |
| binarycreations | I am getting a mount error when attempting to run snapcraft cleanbuild when following the getting started documentation | 16:35 |
| mklvr | Is the recommended build host for snaps still 16.04? | 16:51 |
| kyrofa | mklvr, today, yes | 16:53 |
| mklvr | kyrofa, Thanks! | 16:53 |
| pedronis | mvo: thx | 17:02 |
| cachio | niemeyer, hey, when you have time, could you please take a look to this one? | 17:48 |
| cachio | tx | 17:48 |
| niemeyer | cachio: Which one? | 17:48 |
| cachio | https://github.com/snapcore/spread/pull/60 | 17:48 |
| mup | PR spread#60: Garbage collection for google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/60> | 17:48 |
| cachio | zyga, when you have 5 minutes #5310 | 18:37 |
| mup | PR #5310: tests: fix snapd-repair.timer on ubuntu-core-snapd-run- from-snap test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5310> | 18:37 |
| cachio | thanks | 18:37 |
| zyga | Ack | 18:38 |
| cachio | tx | 18:38 |
| zyga | cachio: looking | 18:46 |
| cachio | zyga, tx | 18:47 |
| === Sir_Gallantmon is now known as Son_Goku | ||
| mup | PR snapd#5310 closed: tests: fix snapd-repair.timer on ubuntu-core-snapd-run- from-snap test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5310> | 18:48 |
| gouchi | Hi, I tried using controller with a snap app but it is not recognized | 18:51 |
| gouchi | We connect joystick and hardware-observe interface and we are using udev | 18:51 |
| gouchi | using /dev/input/jsX and /dev/input/eventX | 18:52 |
| gouchi | I tested on 16.04 and 18.04 | 18:53 |
| gouchi | it seems something from here https://nopaste.xyz/?905527d7c2931bd4#pN7KjJSL5qdrVAzy4T5IhZ2yr7/q/0Uh6mzFM4mcN2w= | 18:53 |
| gouchi | which is blocked but I don't have anything in the log | 18:54 |
| gouchi | any idea ? | 18:56 |
| gouchi | of course using --devmode it is working | 18:56 |
| zyga | Hey gouchi | 19:11 |
| zyga | There is a branch that improves this | 19:11 |
| zyga | Can you try “snap refresh —edge core” | 19:11 |
| zyga | And see if that fixes it | 19:12 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| gouchi | zyga: thank you I will try it | 19:40 |
| gouchi | zyga: nice it is working ! Thank you very much ! | 19:58 |
| gouchi | zyga: when this branch will be moved to stable ? | 19:58 |
| zyga | gouchi: I need to check, either very soon or in the next month | 19:59 |
| zyga | you can keep using edge for now | 19:59 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| mup | PR snapcraft#2152 closed: many: automatically redo step for specified part <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2152> | 20:25 |
| gouchi | zyga: thank you | 20:41 |
| === jkridner|pd is now known as jkridner | ||
| === chihchun_afk is now known as chihchun | ||
| === georgeowell is now known as kawaiipunk | ||
| mup | PR snapd#5311 opened: tests: start active system units on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311> | 21:43 |
| mup | PR snapd#5312 opened: store: switch connectivity check to use v2/info <Created by chipaca> <https://github.com/snapcore/snapd/pull/5312> | 21:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!