| mup | PR snapcraft#1907 closed: tests: setup the correct environment for adt <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1907> | 00:56 |
|---|---|---|
| kyrofa | cprov, any chance you're around? | 01:13 |
| cprov | kyrofa: hey, how can I help ? | 01:17 |
| kyrofa | Something interesting has come up and I'd like your advice. You're familiar with the format of the snapcraft credentials file? | 01:19 |
| kyrofa | Turns out there are two ways to utilize export-login, one anticipated, and one not | 01:19 |
| cprov | kyrofa: not by heart, go on | 01:20 |
| kyrofa | One way is to encrypt the credentials file, save the decryption key in CI, and use it to decrypt the file, then use the file to log in | 01:20 |
| kyrofa | (it's an ini file basically) | 01:20 |
| kyrofa | That ^ is the anticipated usage | 01:20 |
| cprov | Right | 01:20 |
| kyrofa | However, some folks here are building tooling that actually saves the individual macaroons out of the credentials file, putting THOSE into the CI environment, and then reconstructing the file itself in order to login | 01:21 |
| kyrofa | This works of course, but is quite fragile. What if we change the login URL, or any part of that file format | 01:21 |
| kyrofa | So I'm trying to think of a way to make it more... token-ish | 01:22 |
| mup | PR snapcraft#1908 opened: tests: update tests to work in adt <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1908> | 01:23 |
| kyrofa | But it's weird because we have a root macaroon and a discharge | 01:24 |
| kyrofa | (or however that works) | 01:24 |
| kyrofa | I dunno, I guess I just wanted your thoughts | 01:24 |
| kyrofa | It would be cool if people could just paste the entire creds into an environment variable instead of needing to encrypt a file | 01:25 |
| cprov | kyrofa: we can serialize/discharge it and have the authorization token | 01:26 |
| kyrofa | So is the discharged one the only one we need? | 01:27 |
| cprov | But i am not sure it is that easier to use | 01:27 |
| kyrofa | cprov, here's another use-case for something like that: https://pastebin.ubuntu.com/26503341/ | 01:29 |
| elopio | snappy-m-o autopkgtest 1908 xenial:armhf xenial:arm64 | 01:29 |
| kyrofa | I'm writing a Travis deployer | 01:29 |
| snappy-m-o | Computer says nooo. See logs for details: | 01:29 |
| snappy-m-o | Command '['/tmp/tmpb03l5uir/retry_autopkgtest.sh', '1908', 'xenial:armhf', 'xenial:arm64']' returned non-zero exit status 1 | 01:29 |
| kyrofa | cprov, that's an example of AWS, note how they handle the access keys | 01:29 |
| cprov | kyrofa: i guess we snacraft can consume the a env var with the final secret | 01:34 |
| kyrofa | cprov, what would that final secret be, though? The unbound_discharge that we have in the config file now? | 01:35 |
| kyrofa | cprov, sorry, still pretty dense on macaroons :D | 01:36 |
| cprov | kyrofa: no, we have to bind it | 01:36 |
| elopio | snappy-m-o autopkgtest 1908 xenial:armhf | 01:37 |
| snappy-m-o | Computer says nooo. See logs for details: | 01:37 |
| snappy-m-o | Command '['/tmp/tmp1bapez85/retry_autopkgtest.sh', '1908', 'xenial:armhf']' returned non-zero exit status 1 | 01:37 |
| cprov | It is called serialize_for_request(), iirc | 01:37 |
| kyrofa | deserialize_macaroon, maybe? | 01:38 |
| cprov | Let me find it, one sec | 01:38 |
| kyrofa | Ah, no: root_macaroon.prepare_for_request | 01:38 |
| cprov | kyrofa: yup, https://github.com/cprov/surl/blob/master/surl.py#L130 | 01:39 |
| kyrofa | Okay so if I save that `bound` value then, that's all I need? | 01:40 |
| kyrofa | Does that have the same expiration time as the macaroon? | 01:40 |
| cprov | kyrofa: not only the bound discharge, you also need the root to build an 'Authorization' header the store can validate | 01:41 |
| cprov | kyrofa: 'Macaroon root={}, discharge={}', then we can probably hex encode the text and pass it in as a ready to use secret | 01:42 |
| kyrofa | cprov, ah, okay gotcha | 01:45 |
| kyrofa | cprov, I think that's a good idea. And `login --with -` will read from stdin | 01:46 |
| kyrofa | cprov, thank you for letting me borrow your brain :) | 01:47 |
| cprov | kyrofa: good idea about allowing stdin for pipe-ing evn vars | 01:48 |
| cprov | env, even | 01:48 |
| kyrofa | Yeah that already works | 01:49 |
| cprov | kyrofa: the b64 encoded auth is about 4k, a bit too long to be a secret. That's the only problem I can see. | 01:54 |
| mup | PR snapcraft#1909 opened: Add dotnet command to path and enable developer scenario for snap <Created by rakeshsinghranchi> <https://github.com/snapcore/snapcraft/pull/1909> | 03:06 |
| mup | PR snapcraft#1910 opened: tests: expect in-snap unsquashfs when using docker <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1910> | 04:09 |
| mup | PR snapd#4591 opened: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4591> | 04:13 |
| mup | PR snapd#4592 opened: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() for 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4592> | 04:17 |
| mup | PR snapcraft#1911 opened: Add support enable configurable runtime version for .NET Core applications <Created by rakeshsinghranchi> <https://github.com/snapcore/snapcraft/pull/1911> | 04:36 |
| zyga | o/ | 05:58 |
| * zyga preps breakfast for kids | 05:58 | |
| mborzecki | morning | 06:12 |
| zyga | hey | 06:16 |
| mborzecki | zyga: o/ | 06:17 |
| mborzecki | zyga: on the same note as this https://forum.snapcraft.io/t/spotify-cannot-create-tmpfs-target/3805/7 do we create /var/lib/snapd/lib/gl automatically? | 06:18 |
| zyga | mborzecki: no, we need to do that | 06:40 |
| zyga | I think we create one of those | 06:40 |
| zyga | but not all perhaps | 06:40 |
| zyga | and this needs to be rc3 IMO | 06:40 |
| zyga | I'm going to take a shower, let's discuss soon | 06:40 |
| zyga | look at snap-confine's tree that handles that | 06:40 |
| mborzecki | ok | 06:40 |
| zyga | let's add the mkdir's there | 06:41 |
| mborzecki | zyga: we should cover lib/gl, lib/gl32 and lib/vulkan then | 06:43 |
| zyga | all of the variants enumerated from the regular expressions in the apparmor profile | 06:47 |
| zyga | well | 06:47 |
| zyga | I assume there are variables for that | 06:47 |
| zyga | and that on any given system there's a fixed amount | 06:48 |
| mborzecki | right | 06:57 |
| mborzecki | zyga: will you be looking into this? | 06:57 |
| zyga | mborzecki: mmm, maybe, depends on timing | 07:00 |
| zyga | I need to discuss with mvo first | 07:00 |
| zyga | mvo: good morning | 07:29 |
| zyga | mvo: I have great news and bad news | 07:29 |
| zyga | mvo: pick :) | 07:29 |
| mvo | hey zyga | 07:29 |
| mvo | zyga: bad first | 07:29 |
| zyga | mvo: we need to add some code that creates new directories in /var/lib/snapd/lib/{gl,vulkan,...} | 07:29 |
| zyga | mvo: people are running into this if they use rc2 and have nvidia and reexec | 07:30 |
| mvo | zyga: *nod* | 07:30 |
| zyga | mvo: it's small but a little annoying that we found out this late | 07:30 |
| zyga | mvo: ikey can help I'm sure, with his array of hardware | 07:30 |
| zyga | mvo: the good news is that if we wait for monday (jdstrand is off today) we can get fully functional layouts tooo | 07:31 |
| zyga | though that is more complex than we initially discussed because of confinement | 07:31 |
| zyga | in any case, it will be ready today and it's an option | 07:32 |
| zyga | (maybe "layouts beta" | 07:32 |
| zyga | anyway, that's the news, how are you feeling today? | 07:32 |
| mvo | zyga: hm, we want to be in candidate by monday | 07:32 |
| mvo | so thats a tough one | 07:32 |
| zyga | so let's fix the bad news and play safe | 07:33 |
| zyga | we can be in edge with layouts | 07:33 |
| mvo | yeah | 07:33 |
| zyga | I'd love 2.31 but I agree that this is an added risk | 07:33 |
| zyga | mvo: perhaps we should disable layouts for 2.31 | 07:33 |
| mvo | he will also not be able to review before .eu evening, right? | 07:33 |
| zyga | (entirely with some early return) | 07:33 |
| zyga | I think he will, he is just traveling today | 07:33 |
| zyga | he was super exited about what we did last night | 07:33 |
| zyga | maybe over weekend, we'll see | 07:34 |
| zyga | we just realized we need per-snap snap-update-ns profiles | 07:34 |
| zyga | because otherwise snap-confine becomes unconfined | 07:34 |
| zyga | we discussed the details already and implementation is straightforward | 07:34 |
| zyga | my plan today is to get layous ready in master, do the per-snap snap-update-ns profiles done, write spread tests and merge that | 07:35 |
| zyga | if you want I can help with missing directories | 07:35 |
| mvo | zyga: help> would be great, just catching up with mails and stuff | 07:41 |
| zyga | same here :) | 07:41 |
| zyga | hey spineau | 07:58 |
| spineau | morning zyga | 07:59 |
| kalikiana | good morning everyone | 08:07 |
| pstolowski | mornings! | 08:08 |
| zyga | hey pstolowski | 08:09 |
| zyga | sorry I didn't finish that review yesterday, I wasn't feeling good and ended up being unproductive for first half of the day | 08:10 |
| zyga | pstolowski: I read the code and it was OK so far, I wanted to see if there's anything missing by checking the non-diff parts and stopped there | 08:10 |
| pstolowski | zyga, 4551? | 08:11 |
| zyga | yes | 08:11 |
| pstolowski | zyga, ok, thanks for looking at it. Gustavo had objections against not reusing "conns" in the state for that, but perhaps I explained my reasoning purely in the standup (and he didn't look at the code yet afaict) | 08:13 |
| pstolowski | zyga, feeling better today? | 08:15 |
| zyga | yes | 08:16 |
| zyga | my back is okay, not sure why it hurt so much yesterday | 08:16 |
| zyga | it's not like broken bones that hurt when weather changes | 08:17 |
| zyga | thank you :) | 08:17 |
| pstolowski | glad to hear! | 08:17 |
| ikey | grats on skype | 08:18 |
| mup | PR snapd#4593 opened: advisor: ensure commands.db has mode 0644 and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4593> | 08:19 |
| zyga | hey ikey | 08:30 |
| zyga | :) | 08:30 |
| zyga | snaps are starting to get popular :) | 08:30 |
| zyga | ikey: any issues on solus, I cannot wait to get skype off from classic confinement | 08:30 |
| ikey | zyga, not tried the one in the store yet | 08:38 |
| ikey | got back home late yesterday | 08:38 |
| mup | PR snapd#4594 opened: systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4594> | 08:38 |
| mborzecki | ^^ more thinking than coding :/ | 08:39 |
| mborzecki | zyga: about those lib/gl[32], lib/vulkan directories, shall i look into it? | 08:39 |
| * ikey perks up ears at mention of the one domain he looks at | 08:40 | |
| mborzecki | mvo: pstolowski: ikey: morning guys | 08:40 |
| ikey | morning | 08:40 |
| pstolowski | o/ | 08:40 |
| ikey | mborzecki, might i query whats changing in gl/vulkan land? | 08:42 |
| mborzecki | ikey: https://forum.snapcraft.io/t/spotify-cannot-create-tmpfs-target/3805 | 08:42 |
| mvo | hey mborzecki | 08:42 |
| ikey | is there some missing stuff on the hostside? | 08:42 |
| ikey | i.e missing host dir | 08:43 |
| mborzecki | ikey: yup | 08:43 |
| ikey | so packaging fixes, gotcha | 08:43 |
| ikey | thought the dirs were changing :D | 08:43 |
| mvo | mborzecki: thanks for the PR | 08:43 |
| ikey | technically the vulkan stuff would be my fault, sorry guys | 08:43 |
| mborzecki | mvo: i'll try to check it with that guy's snaps, but i'm missing some of the stuff he added in his snapd fork (btw. it'd be great if he opened an PR :P) | 08:44 |
| zyga | mborzecki: mmm, yeah go for it please, I'm working on new profile generation | 08:50 |
| zyga | thank you for taking care of that | 08:51 |
| mup | PR snapd#4595 opened: snap: improve validation of snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4595> | 08:59 |
| zyga | mvo: this one is for 2.31, it will ensure 2.32 won't reject snaps accepted by 2.31 (layouts) | 08:59 |
| Chipaca | moin | 09:10 |
| mvo | hey Chipaca ! good morning | 09:12 |
| mborzecki | Chipaca: morning | 09:15 |
| pstolowski | Chipaca, o/ | 09:16 |
| zyga | hey Chipaca | 09:16 |
| mborzecki | hm no luck with syncloud's platform snap either https://paste.ubuntu.com/26504652/ | 09:16 |
| zyga | mborzecki: you could try with layouts soon :) | 09:19 |
| zyga | *today* | 09:20 |
| zyga | you can remap /opt/disk to $SNAP_DATA/opt/disk | 09:20 |
| zyga | (or to snap common) | 09:20 |
| zyga | mborzecki: try with my branch from last night | 09:20 |
| mborzecki | fyi https://www.reddit.com/r/linux/comments/7ukrbq/microsoft_releases_skype_as_a_snap_for_linux/ | 09:23 |
| kalikiana | yay for skype snap ^_^ | 09:24 |
| mborzecki | btw there was a post on slashdot too | 09:26 |
| mborzecki | don't know if anyone visits the site still, but here it is https://linux.slashdot.org/story/18/02/01/1644250/microsoft-releases-skype-as-a-snap-for-linux | 09:26 |
| mborzecki | the year of linux desktop is upon us :P | 09:27 |
| pstolowski | :) | 09:27 |
| * zyga reads slashdot | 09:31 | |
| zyga | mborzecki: haha, yes | 09:31 |
| mborzecki | now that we've had at 's' with releases we'll probably never get to see photoshop as snap, and i can't really think of any interesting application that starts with 't' | 09:31 |
| zyga | mborzecki: total commander ;-) | 09:33 |
| zyga | mborzecki: we'll wrap around and 'a' will come with adobe busyware | 09:33 |
| mborzecki | total commander - the 'ever' shareware | 09:33 |
| Chipaca | mborzecki: thunderbird :-p | 09:34 |
| mborzecki | zyga: i'd swap adobe for autodesk, see their A* suite running on linux | 09:34 |
| zyga | mborzecki: yeah, I remember using *commander style programs since forever essentially | 09:35 |
| zyga | when I was 9 and we got a 386 at home | 09:35 |
| mborzecki | haha, remember 'dos navigator'? | 09:36 |
| * zyga googles | 09:36 | |
| zyga | maybe not by name | 09:36 |
| zyga | I didn't speak english back then | 09:36 |
| zyga | so things were "magic" | 09:36 |
| zyga | so the name doesn't ring any bells but 1st screenshot I see is "yep, used that" | 09:36 |
| pstolowski | mborzecki, mvo thanks for you comments to 4584, i've implemented your suggestions (and the aspects we discussed yesterday during standup) | 09:43 |
| mvo | pstolowski: nice, thank you | 09:46 |
| mborzecki | hmm so a friend of mine tried installing skype on 17.10: https://paste.ubuntu.com/26504804/ | 09:50 |
| mvo | mborzecki: server side overload? we see a lot of failures in spread as well | 09:51 |
| mborzecki | he got: 2018/02/02 10:39:47.590935 backend.go:152: cannot create host snap-confine apparmor configuration: cannot replace snap-confine apparmor profile: AppArmor parser error for /etc/apparmor.d/snap.core.3887.usr.lib.snapd.snap-confine in /etc/apparmor.d/snap.core.3887.usr.lib.snapd.snap-confine at line 11: Could not open '/var/lib/snapd/apparmor/snap-confine | 09:52 |
| zyga | is /var/lib/snapd/apparmor/snap-confine a directory? | 09:54 |
| zyga | it should be | 09:54 |
| mvo | ogra_: quick question about the gadget defaults for core> you say this worked for 2.30? are you sure? then I will check the diff between the 2.30->2.31, so far I have not found a smoking gun (but adding a test case right now :) | 09:54 |
| ogra_ | mvo, not 100% ... i have definitely checked it a week or two ago and there it was behaving | 09:55 |
| ogra_ | i'm not 100% sure about the exact version though | 09:55 |
| mvo | ogra_: how much work is it for you to run this again with stable (2.30)? if trivial it would be nice to double check | 09:56 |
| ogra_ | i currently have the system completely messed up (trying out grub-uboot atm) ... it would take a bit | 09:57 |
| zyga | hmm, tests are sad today | 09:59 |
| pedronis | Chipaca: snapshots it's big, usually indeed we would split overlord, daemon/client and cmd/snap bits in different PRs | 10:15 |
| Chipaca | pedronis: yep, thus the commits | 10:16 |
| Chipaca | pedronis: having 4-5 RFC PRs didn't seem to me to be something that'd progress | 10:16 |
| Chipaca | I'm not expecting a deep nitpicky review of this, just a "yeah that's what it should look like" / "WTF are you on can i have some" thing | 10:17 |
| zyga | Chipaca: can I have some | 10:18 |
| zyga | it must be good :) | 10:18 |
| Chipaca | zyga: diclofenac + pridinol (but not too often) | 10:19 |
| mvo | ogra_: re 1746714> there seems to be typo there, in your gadget it should read "rsyslog:\n disable: true" - your gadget has disable*d* | 10:19 |
| ogra_ | oh man | 10:19 |
| * Chipaca ~> physio | 10:20 | |
| zyga | ogra_: no validation? | 10:23 |
| ogra_ | zyga, obviously not | 10:23 |
| mvo | zyga: config schemas is on the roadmap for some time | 10:23 |
| mvo | for core we could (nowdays) probably "emulate" them | 10:24 |
| * mvo thinks a bit | 10:24 | |
| ogra_ | well | 10:24 |
| * zyga feels like having a hangover, needs more water | 10:25 | |
| ogra_ | even an error when it is attempted to be set would already help here | 10:25 |
| zyga | (weather is terrible lately) | 10:25 |
| kalikiana | zyga: you realize you just said you want to have a hangover? ;-) | 10:26 |
| mborzecki | zyga: should't the vulkan code be outside of nvidia specific pieces? | 10:26 |
| zyga | kalikiana: oh yes | 10:30 |
| zyga | it came out wront | 10:30 |
| zyga | wrong | 10:30 |
| zyga | see! | 10:30 |
| zyga | I feel like I have a hangover, not like I would like to have one | 10:31 |
| kalikiana | :-D | 10:31 |
| zyga | mborzecki: not sure, good question | 10:31 |
| * kalikiana coffee break, back in a bit | 10:31 | |
| zyga | mborzecki: I think not | 10:31 |
| zyga | mborzecki: it's not about nvidia but about external drivers | 10:32 |
| pstolowski | oh the tests are very unhappy today, indeed | 10:35 |
| mvo | ogra_: I wrote a testcase and I think once the typo is fixed this will work | 10:46 |
| pedronis | mvo: I don't know if we can error, but we could at least log a warning if we see core configs that we don't know about | 10:48 |
| mvo | niemeyer: quick question - we just had this issue that an invalid core config option was used, for core itself we could validate if its a supported option, do you think that is worth persuing? probably not hard, we just need to expose something like config.Transaction.ChangesKeys() or something | 10:48 |
| mvo | pedronis: yeah, that was what I was thinking | 10:49 |
| mvo | pedronis: also it kind of buged me a bit that we do not test setting core options right now in spread, unfortunately because core has no snap-id its not easy to test (I hacked a bit and with https://paste.ubuntu.com/26505078/ it works) | 10:50 |
| pedronis | because of nesting is not super obvious what it means though | 10:50 |
| pedronis | mvo: I wonder if we should have a special key for that could be used there and would work also for non store core | 10:50 |
| pedronis | mvo: like $core or something | 10:50 |
| mvo | pedronis: oh, nice | 10:51 |
| mvo | pedronis: I like that idea | 10:51 |
| pedronis | it also would solve the issue that core doesn't have the same id in prod and staging (not super important but it's an issue for testing) | 10:51 |
| pedronis | anyway just an idea | 10:52 |
| mvo | pedronis: I can prepare the pastebin as a proper PR with $core | 10:53 |
| pedronis | the other option would be to invent a general syntax to use name instead of id, it's a bit a pity if we go there because then it would have been saner to have a special syntax for ids instead | 10:54 |
| pedronis | we will have the same issues with the connect functionality | 10:54 |
| pedronis | btw | 10:54 |
| pedronis | mvo: anyway $core is also interesting because is a bit unclear what should happen when we split core vs base or have core-16 etc | 10:56 |
| mvo | pedronis: excellent point | 11:00 |
| mvo | pedronis: could we use heuristics? i.e. is the snap-id longer than the allowed snap names? | 11:01 |
| pedronis | I don't remember what are the rules | 11:01 |
| pedronis | ids are fixed lentgh | 11:01 |
| pedronis | I think | 11:01 |
| pedronis | we don't have a size limit in snapd for names | 11:02 |
| mvo | pedronis: yeah, that is what I remember too, might be worth looking at. anyway, I make this $core thing and will ask about validation in the standup, nested values will be a bit nasty but iirc we don't use those for the core config | 11:02 |
| pedronis | but I think there is one in the store | 11:02 |
| mvo | pedronis: yeah, thats what I remember, I had to shorten some test snaps | 11:02 |
| mvo | because the store was unhappy :) | 11:03 |
| pedronis | I can check that | 11:03 |
| pedronis | (in a bit) | 11:03 |
| mvo | pedronis: no rush. it looks like snap-id is 32char, I think snap names can be larger so a heuristic may not be easily possible | 11:05 |
| * mvo is slightly sad about this | 11:05 | |
| pedronis | anyway using ids was quite intentional I think, just a bit annoying | 11:06 |
| pedronis | but core is a bit special because reasons | 11:06 |
| pedronis | anyway something to discuss with Gustavo | 11:06 |
| * mvo nods | 11:07 | |
| pedronis | mvo: snap name max length is 40 | 11:10 |
| pedronis | (in the store) | 11:10 |
| mvo | pedronis: ta | 11:12 |
| zyga | mvo: does this fail on your machine? | 11:43 |
| zyga | ---------------------------------------------------------------------- | 11:43 |
| zyga | FAIL: cmd_userd_test.go:62: userdSuite.TestUserd | 11:43 |
| zyga | cmd_userd_test.go:84: | 11:43 |
| zyga | c.Assert(err, IsNil) | 11:43 |
| zyga | ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'") | 11:43 |
| mup | PR snapd#4596 opened: osutil: allow using many globs in EnsureDirState <Created by zyga> <https://github.com/snapcore/snapd/pull/4596> | 11:45 |
| zyga | Chipaca: ^ perhaps for you, it's pretty short and I need it badly | 11:57 |
| * Chipaca looks | 12:00 | |
| ikey | so, question | 12:01 |
| ikey | are the /etc/apparmor.d files meant to include /var/lib/snapd/apparmor/profiles ? | 12:01 |
| ikey | because it seems those guys will only be loaded when i start snapd | 12:01 |
| ikey | but if i snap run something, those profiles don't exist yet | 12:02 |
| ikey | i.e. AVC apparmor="DENIED" operation="change_onexec" info="label not found" | 12:02 |
| zyga | ikey: I think that the thing that loads profiles on boot looks at /var/lib/snapd/apparmor/profiles | 12:06 |
| ikey | yeah thats kinda the thing here | 12:06 |
| zyga | ikey: we reload them in snapd if needed but it should happen during boot to let services start without starting snapd | 12:06 |
| ikey | "the thing" is slow as ass | 12:06 |
| ikey | and massively regresses boot time | 12:07 |
| zyga | ikey: that's orthogonal, I'm explaining how it functions, not why it is slow | 12:07 |
| ikey | and the only "solution" is private to the debuntu packaging world | 12:07 |
| zyga | oh? | 12:07 |
| zyga | what solution is that? | 12:07 |
| ikey | your package hooks for apparmor | 12:07 |
| zyga | maybe I'm missing the point somewhere | 12:07 |
| ikey | and the boot load service | 12:07 |
| ikey | the /var/lib/apparmor/profiles path isnt referenced in the /etc/apparmor.d/* files | 12:07 |
| ikey | so they won't be compiled in with a boot time service | 12:07 |
| ikey | until snapd is started and does the reload you mentioned | 12:08 |
| ikey | but with socket activation, snapd.service itself wont be started | 12:08 |
| zyga | it should be referenced by the arcane /etc/init.d/apparmor script | 12:08 |
| ikey | and a snap run of some snap will fail | 12:08 |
| ikey | i use systemd. :) | 12:08 |
| zyga | /etc/apparmor.d is more like a /usr/lib/apparmor.d | 12:08 |
| zyga | yes, we too | 12:08 |
| ikey | /etc/init.d is a banned path in solus | 12:08 |
| ikey | so i know we dont have it | 12:08 |
| zyga | it's a shell script and runs with sysv compat generator AFAIK | 12:08 |
| ikey | so are nasty shell scripts during boot | 12:08 |
| ikey | lol | 12:08 |
| zyga | and that's what makes it slow for you perhaps | 12:09 |
| zyga | so | 12:09 |
| ikey | im adding a workaround | 12:09 |
| zyga | I think you want to write a small tool (that would go upstream) | 12:09 |
| zyga | that 1) loads and 2) caches profiles | 12:09 |
| ikey | by including the private apparmor profiles directory into our aot portion | 12:09 |
| ikey | ya ive done that | 12:09 |
| zyga | loading cached profile is very fast | 12:09 |
| ikey | way ahead of ya | 12:09 |
| zyga | cool, | 12:09 |
| zyga | but please share that with jdstrand and upstream, | 12:09 |
| ikey | https://github.com/solus-project/aa-lsm-hook | 12:09 |
| zyga | that script has some reason for not being a systemd job sadly | 12:09 |
| zyga | and it's probably some messy complexity | 12:09 |
| zyga | maybe it's just legacy complexity that can die | 12:09 |
| zyga | but maybe there's some genuine thing to care about and you'd just run into it all over again | 12:10 |
| ikey | working out the kinks with this in solus atm | 12:10 |
| zyga | jdstrand is off today (traveling) but next week we can sync on that | 12:10 |
| ikey | so we have a -compile and a -load binary | 12:10 |
| ikey | -compile is called during package operations | 12:10 |
| ikey | and -load at boot | 12:10 |
| ikey | which if it fails to load, will recompile | 12:10 |
| ikey | to handle kernel abi changes and such | 12:10 |
| ikey | which takes my whopping 1.3s regression to to 32ms | 12:10 |
| ikey | in my VM over half the boot time /was/ spent in apparmor.service ^^ | 12:11 |
| ikey | but now im doing the AoT/cache approach and making sure it doesn't bust snapd :P | 12:12 |
| zyga | yeah, it also doesn't help that that is a shell script and it wasn't a one liner | 12:12 |
| zyga | look at how it gets invalidated | 12:12 |
| zyga | one of the things that the old code cared for was apparmor base things gettingchanged | 12:12 |
| zyga | so all the #include files | 12:12 |
| zyga | this sucks IMO | 12:12 |
| ikey | right | 12:12 |
| zyga | and it could be nice to even ship _precompiled_ profiles and build-depend on the include files | 12:12 |
| ikey | so this is why our AoT is called by usysconf during package changes | 12:12 |
| zyga | but that's not how it's done in ubuntu | 12:12 |
| ikey | only if /etc/apparmor.d changes | 12:12 |
| zyga | yes | 12:13 |
| ikey | and then the boot uses the cache | 12:13 |
| zyga | and really /etc/apparmod.d is a messy zoo that should live in /usr/lib | 12:13 |
| ikey | yeah | 12:13 |
| zyga | and not in /etc for the vast majority of content | 12:13 |
| zyga | it's just in dire need of a gardener | 12:13 |
| ikey | /usr being shipped, /etc being local vendor/etc | 12:13 |
| zyga | yeah, exactly | 12:13 |
| * zyga wrote https://disqus.com/home/discussion/omgubuntu/it_just_got_a_lot_easier_to_install_skype_on_ubuntu/#comment-3738650041 | 12:13 | |
| ikey | people still raging about getting the stuff they want? .. | 12:14 |
| zyga | yeah, but I think that unless we put accurate comments and explanations people will run off with the wildest conspiracy theory they can come up with | 12:14 |
| ikey | yeah true | 12:15 |
| zyga | snaps are from SATAN or whatever | 12:15 |
| ikey | 8ms aa-lsm-hook.service | 12:15 |
| ikey | thats more like it | 12:15 |
| zyga | wooot | 12:15 |
| zyga | thank you | 12:15 |
| zyga | I actually think that's something we could adopt in base18 | 12:15 |
| zyga | mvo: ^^ | 12:15 |
| zyga | we want empty /ec | 12:15 |
| ikey | https://hastebin.com/mukeneheha.coffeescript | 12:15 |
| zyga | _empty_ /etc | 12:15 |
| ikey | all loaded properly | 12:16 |
| zyga | oh | 12:16 |
| zyga | minecraft!!! | 12:16 |
| ikey | so for now we load /from/ etc path, *but* | 12:16 |
| * zyga snap installs it | 12:16 | |
| ikey | we support optional paths | 12:16 |
| zyga | man snaps are really a double-edged sword | 12:16 |
| ikey | i mean my eventual thinking is we'd merge the hook into apparmor userspace after discussion | 12:16 |
| ikey | zyga, productivity | 12:16 |
| zyga | how do you stay focused when you can install cool software and use it :) | 12:16 |
| ikey | xD | 12:16 |
| zyga | yes, that sounds good to me | 12:16 |
| zyga | soooooo... I have a new computer now | 12:17 |
| ikey | we have some path magic here: https://github.com/solus-project/aa-lsm-hook/blob/master/src/lib/hook.c#L24 | 12:17 |
| ikey | oh? | 12:17 |
| zyga | feeling very tempted to open it ^_^ | 12:17 |
| ikey | it was popeys snap not sure how far he got with it | 12:17 |
| zyga | oh neat, proper compiled language | 12:17 |
| * zyga hugs ikey for being this cool dude that writes in C | 12:18 | |
| ikey | :D | 12:18 |
| ikey | we had to for the boot time regressions | 12:18 |
| ikey | we just did the same with solus-hardware-config | 12:19 |
| zyga | and in other news, I now have per-snap apparmor profiles for snap-update-ns if a given snap uses layouts | 12:19 |
| ikey | oh very nice | 12:19 |
| zyga | so ... layouts not only work but are safe and won't weaken snap-conifne | 12:19 |
| zyga | man, I'm so exited about that one :) | 12:19 |
| zyga | I'll break for some more tea and convert my hand-made layout snap to a spread test | 12:19 |
| ikey | :D | 12:21 |
| zyga | btw will layouts benefit solus in any immediate way? | 12:22 |
| ikey | idk but i mean we can probably invent some use cases | 12:22 |
| ikey | totally up for that | 12:22 |
| zyga | layous, let you put, for instance $SNAP_DATA/stuff in /var/lib/whatever | 12:22 |
| ikey | yeah | 12:22 |
| zyga | or $SNAP/usr/share/foo in /usr/shre/foo | 12:22 |
| ikey | seems good in terms of bolt-ons | 12:23 |
| ikey | or hell even themes | 12:23 |
| ikey | if they were content layouts | 12:23 |
| zyga | mmm, | 12:23 |
| zyga | so themes are a separate topic but they already benefit from this | 12:23 |
| ikey | oh ok | 12:23 |
| zyga | because as a prereuquisite we can now *spool* content interface | 12:23 |
| zyga | so you can create $SNAP/plugin and connect any number of things there | 12:23 |
| zyga | and they will show up as $SNAP/plugin/{foo,bar,froz} | 12:24 |
| zyga | (even deconflict on name clash to foo, foo_2 | 12:24 |
| zyga | and the same idea is that we can now stick a theme snap up | 12:24 |
| zyga | and connect it via a theme interface (or just one of the desktop interfaces) | 12:24 |
| zyga | and use the right content tags to ship various variants and connect the right one | 12:24 |
| zyga | (so you get all themes but the right ABIs) | 12:25 |
| zyga | and one fat theme snap can cover common themes | 12:25 |
| zyga | and other theme snaps can complement that freely | 12:25 |
| zyga | all of that is possible, just not used yet | 12:25 |
| zyga | and the ubuntu desktop team is looking at adopting it now | 12:25 |
| zyga | the single fat theme snap is just a 1st step before snapd knows which theme you use and which ABI it needs for a particular snap and pulls that from the store automatically | 12:26 |
| zyga | I'm so so so looking forward to that | 12:26 |
| zyga | as it will unbreak theming in a major way | 12:26 |
| ikey | true | 12:26 |
| ikey | i think folks will be a lot happier when they land | 12:26 |
| zyga | but first | 12:27 |
| zyga | coffee | 12:27 |
| zyga | I can slow down and plan what's needed for layouts to land on monday | 12:28 |
| ikey | yeah i gotta run to town and get a new shirt for myself | 12:29 |
| zyga | oh? wedding? | 12:30 |
| mborzecki | zyga: what kind of rig do you have now? | 12:30 |
| zyga | mborzecki: I have this x250 laptop | 12:30 |
| ikey | zyga, nah just heading out to a mates place for pizza + beer | 12:30 |
| pstolowski | mvo, 4579 looks great to me; and what's the plan re seccomp features? | 12:30 |
| zyga | and I'm selling my hand-built PC wit amd x4 845 cpu | 12:30 |
| zyga | with two r9's 280x | 12:30 |
| zyga | ikey: man, I miss pizza | 12:31 |
| * zyga had breakfast | 12:31 | |
| ikey | :D | 12:31 |
| mborzecki | 13:17 <zyga>soooooo... I have a new computer now <--- i mean this :) | 12:31 |
| zyga | hahaha | 12:31 |
| zyga | that's still in a box :) maybe it's a bag of bricks | 12:31 |
| * Chipaca -> lunch | 12:32 | |
| Chipaca | zyga: maybe it's a mini pdp8 | 12:32 |
| jdstrand | zyga: I have 30 seconds before leaving for a plane, but I woke up thinking *maybe* it isn't so bad if snap-update-ns has wide write access. the idea is, snapd writes the fstab entries, snap-confine can't write them or modify/load apparmor policy, snap-confine calls snap-update-ns, snap-update-ns can't write fstab files or modify/load apparmor policy (ie, use explicit deny rules) | 12:55 |
| zyga | jdstrand: hey | 12:55 |
| jdstrand | zyga: but I would need to study the existing profile to convince myself this is ok | 12:56 |
| zyga | jdstrand: I wrote the per-snap policy now | 12:56 |
| jdstrand | heh | 12:56 |
| zyga | jdstrand: it will be ready for review over weekend | 12:56 |
| zyga | jdstrand: :) | 12:56 |
| zyga | jdstrand: it's super sweet, I did the optimization we talked about | 12:56 |
| jdstrand | you're too fast. I mean, I didn't even sleep that long! | 12:56 |
| zyga | jdstrand: so that we have fewer profiles and it's less of an impact for non-layout snaps | 12:56 |
| zyga | jdstrand: haha :) | 12:56 |
| zyga | jdstrand: I'm super keen to see this fly :) | 12:56 |
| jdstrand | ok | 12:56 |
| jdstrand | well, I gotta run | 12:57 |
| jdstrand | have a nice day! | 12:57 |
| * jdstrand -> travel | 12:57 | |
| zyga | safe travels! | 12:57 |
| jdstrand | thanks :) | 12:57 |
| mup | PR snapd#4597 opened: snapstate: allow core config via $core <Created by mvo5> <https://github.com/snapcore/snapd/pull/4597> | 13:11 |
| mup | PR snapd#4598 opened: packaging: create /var/lib/snapd/lib/{gl,gl32,vulkan} as part of packaging <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4598> | 13:19 |
| mvo | mborzecki: \o/ | 13:20 |
| * kalikiana heading out for lunch, back in a bit | 13:33 | |
| pstolowski | niemeyer, can you take a look at #4584? | 14:03 |
| mup | PR #4584: hooks/osutil: limit the number of data read from the hooks to avoid oom <Created by stolowski> <https://github.com/snapcore/snapd/pull/4584> | 14:03 |
| niemeyer | pstolowski: Reading | 14:04 |
| mup | PR snapd#4594 closed: systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4594> | 14:06 |
| mup | PR snapd#4591 closed: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4591> | 14:07 |
| mup | PR snapd#4580 closed: tests: ensure disabled services are masked <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4580> | 14:13 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/4595 needs review for 2.31 | 14:14 |
| mup | PR #4595: snap: improve validation of snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4595> | 14:14 |
| mup | PR snapd#4599 opened: many: send new Snap-CDN header with none or with cloud instance placement info as needed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4599> | 14:14 |
| mvo | zyga: looking | 14:14 |
| * pstolowski lunch | 14:20 | |
| zyga | small break to handle kids | 14:29 |
| kalikiana | re | 14:35 |
| zyga | thank you | 14:37 |
| mup | PR snapd#4595 closed: snap: improve validation of snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4595> | 14:37 |
| zyga | we'll probably do some tweaks but this should be very much like what we want to have in edge week | 14:37 |
| niemeyer | pstolowski: ALright, | 14:45 |
| niemeyer | pstolowski: I sent a review.. which actually suggests a slightly different route that does not involve killing the process | 14:46 |
| niemeyer | pstolowski: I'm sorry for the late suggestion, but it seems worth it.. have a look at the rationale there and let me know what you think please | 14:46 |
| zyga | wow | 14:55 |
| zyga | http://lkml.iu.edu/hypermail/linux/kernel/1802.0/00454.html | 14:55 |
| zyga | search for "snap" | 14:55 |
| cachio__ | mvo, hey | 14:58 |
| cachio__ | mvo, I see a bug in arm64 for the test prepare-image-uboot | 14:59 |
| cachio__ | mvo, after snap prepare-image .... | 14:59 |
| cachio__ | it downloads all the snapd | 14:59 |
| cachio__ | snaps | 14:59 |
| cachio__ | but kernel.img is not in $IMAGE/boot/uboot/pi2-kernel_*.snap | 14:59 |
| cachio__ | initrd.img it is there | 15:00 |
| cachio__ | not sure if there is any log where I could get more info | 15:00 |
| cachio__ | nothing in journalctl and dmesg | 15:00 |
| pstolowski | niemeyer, thank you. yes I agree killing completely innocent hooks that happen to produce too much output is valid concern. I'll redo this | 15:17 |
| * zyga breaks for some time to unpack | 15:25 | |
| mup | PR snapd#4600 opened: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600> | 15:29 |
| mvo | 4593 needs a second review | 15:32 |
| mvo | (should be pretty trivial) | 15:32 |
| mup | PR snapd#4592 closed: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() for 2.31 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4592> | 15:33 |
| ogra_ | cjwatson, do you happen to have any clue about grub-uboot ? (i have it working fine, chainloaded from a vendor u-boot and am at the grub prompt, but i cant find out how to actually access a disk (hd0/hd1 apparently do not work) | 15:33 |
| cachio__ | mvo, review done on 4593 | 15:34 |
| cjwatson | ogra_: I know that it exists but not a whole lot more. You might be able to tab-complete disks if you start with a ( | 15:35 |
| cjwatson | ogra_: sounds like you either have a wrong prefix or haven't built in the necessary modules to get at /boot/grub | 15:36 |
| ogra_ | yeah, i cant see mmc or sdhc modules in the grub-core/ dir of my build | 15:36 |
| ogra_ | i'd expect something like that to be there | 15:37 |
| ogra_ | (the fun part is that i just loaded core.img from the MMC with u-boot ... so it is initialized and all) | 15:40 |
| * cachio__ launch | 15:41 | |
| * cachio__ lunch | 15:41 | |
| ogra_ | launching lunch :) | 15:41 |
| cachio__ | ogra_, :) | 15:43 |
| mup | PR snapcraft#1912 opened: lxd: unset SNAP to work-around LXD deb thinking it's a snap <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1912> | 15:47 |
| kalikiana | kyrofa: have a look at this one, please. This is a work-around for the broken container builds with LXD v2.21 | 15:48 |
| mborzecki | EOW for me, enjoy the weekend guys | 15:50 |
| mborzecki | there's FOSDEM this weekend, be sure to watch the live streams | 15:50 |
| niemeyer | pstolowski: Thank you, and again sorry for figuring this a bit too late.. | 15:55 |
| mup | PR snapd#4593 closed: advisor: ensure commands.db has mode 0644 and add test <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4593> | 15:56 |
| pstolowski | niemeyer, no worries. i've visited a few dark corners by doing this, was a nice learning excercise anyway | 15:58 |
| cjwatson | ogra_: it *looks* like grub-core/disk/uboot/ubootdisk.c is supposed to be built into the GRUB kernel and deal with disks enumerated by u-boot init | 16:24 |
| cjwatson | ogra_: did tab-completion after ( say anything? | 16:24 |
| ogra_ | cjwatson, yeah, but it seems to need a devicetree, i suspect thats what i'm doing wrong here | 16:24 |
| ogra_ | nope | 16:25 |
| cjwatson | ah, at this point I know nothing | 16:25 |
| mvo | cachio__: what is the revno of the pi2-kernel snap that is downloaded? I wonder why this test is only failing on arm64 | 16:51 |
| mvo | cachio__: thanks for the review, I have a look | 16:51 |
| cachio__ | mvo, rev 49 | 16:55 |
| cachio__ | mvo, I did unsquash and everything seems to be good | 16:55 |
| cachio__ | mvo, }kernel.img is there | 16:55 |
| cachio__ | -rw------- 1 sergio sergio 5722584 ene 7 10:07 kernel.img | 16:55 |
| mvo | cachio__: so if you manually download and unsquash it is good but it fails on the arm64 test? or am I misunderstanding? | 16:56 |
| Chipaca | pstolowski: I have this round robin thing here if you're interested btw | 16:56 |
| pstolowski | Chipaca, ? | 16:58 |
| cachio__ | mvo, in a debug session I did > su -c "SNAPPY_USE_STAGING_STORE=$SNAPPY_USE_STAGING_STORE snap prepare-image --channel edge --extra-snaps snapweb $ROOT/model.assertion $ROOT" test | 16:58 |
| * kalikiana going to wrap up shortly | 16:58 | |
| Chipaca | pstolowski: suddenly remembered you were working on making the limit writer a round robin thing? | 16:58 |
| cachio__ | and then I unsquash the downloaded kernel snap | 16:58 |
| Chipaca | pstolowski: and that i had one | 16:58 |
| Chipaca | pstolowski: https://gist.github.com/chipaca/d292f8f29110d5ab72bc675ca1c5d0e6 fwiw | 16:59 |
| mvo | cachio__: so in the debug session you could not reproduce the failure, is that what you say? | 16:59 |
| cachio__ | mvo, yes | 17:00 |
| mvo | cachio__: :( | 17:00 |
| mvo | cachio__: thats mysterious | 17:00 |
| cachio__ | mvo, https://paste.ubuntu.com/26506616/ | 17:00 |
| cachio__ | mvo, that's what I see after run the snap prepare-image command | 17:00 |
| mvo | cachio__: hm, kernel.img is a symlink - I wonder if that is the problem | 17:03 |
| mvo | cachio__: still - why only on arm64 :( | 17:03 |
| mvo | cachio__: btw, do you have more test fixes that we should merge into 2.31? | 17:04 |
| pstolowski | Chipaca, ah, that! thaank you. i haven't yet go deep into the details of what Gustavo suggested in the review comment (currently adressing some other PR's comments), but thanks, it be good for inspiration | 17:04 |
| cachio__ | mvo, no, just this is remaining | 17:04 |
| mvo | cachio__: great to hear | 17:04 |
| cachio__ | the othe fixes were in the test tools that I have for the boards | 17:05 |
| pstolowski | / grr my wireless keyboard is eating characters | 17:05 |
| Chipaca | pstolowski: np! there are a couple of tweaks I'd do if it was something or production use, fwiw, but otherwise it worked | 17:05 |
| Chipaca | s/or/for/ | 17:05 |
| cachio__ | mvo, this is the snap content https://paste.ubuntu.com/26506641/ | 17:05 |
| pstolowski | Chipaca, ack | 17:06 |
| * kalikiana going off into the weekend | 17:12 | |
| mvo | cachio__: of what rev number? I see kernel.img as a symlink in r49 | 17:12 |
| cachio__ | mvo, the kernel snap is rev 49 | 17:15 |
| cachio__ | mvo, pi2-kernel_49.snap | 17:15 |
| pstolowski | eow o/ | 17:18 |
| smoser | hi. | 17:26 |
| smoser | i walk through https://developer.ubuntu.com/core/get-started/kvm | 17:26 |
| smoser | and i get http://paste.ubuntu.com/26506699/ | 17:26 |
| smoser | is that known? i basically can't get through the consoleconf | 17:26 |
| mvo | cachio__: strange, when I unsquash -ls I see kernel.img as a symlink and in your output it is a real file | 17:27 |
| smoser | so i think the issue above occurs if i attach a 'nocloud' config disk. | 17:49 |
| smoser | probably because cloud-init enables itself and writes network config, that throws fits for console-conf. | 17:49 |
| Chipaca | smoser: in what part of that walk does it say "attach a 'nocloud' config disk"? | 17:54 |
| smoser | Chipaca: you're right, it does not. | 18:00 |
| Chipaca | phew | 18:01 |
| Chipaca | mvo: I'm EOWing, which means you should've EOWed already | 18:02 |
| Chipaca | mvo: have a great weekend (starting now) | 18:02 |
| Chipaca | :-) | 18:03 |
| * Chipaca waves | 18:03 | |
| cachio__ | mvo, could we add a new pr for rc3? | 18:04 |
| cachio__ | mvo: #4601 | 18:12 |
| mup | PR #4601: tests: update kill-timeout focused on making tests pass on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4601> | 18:12 |
| mvo | cachio__: sure | 18:12 |
| cachio__ | mvo, it is really small | 18:12 |
| mup | PR snapd#4601 opened: tests: update kill-timeout focused on making tests pass on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4601> | 18:13 |
| mvo | cachio__: ta | 18:13 |
| === jkridner|pd is now known as jkridner | ||
| cachio__ | mvo, just the prepate-image-uboot test missing | 18:14 |
| cachio__ | mvo, still chasing the problem | 18:15 |
| mvo | cachio__: yeah, a mystery, sorry that I am not useful right now in solving this puzzle :( | 18:16 |
| mvo | cachio__: I gtg, but I will read scrollback! | 18:16 |
| cachio__ | mvo, np, I0ll try to see which is the problem | 18:18 |
| cachio__ | enjoy your weekend | 18:18 |
| * zyga-ubuntu moved his files onto the new machine | 19:13 | |
| kyrofa | zyga-ubuntu, hey, you got a sec? | 19:14 |
| zyga-ubuntu | yes | 19:14 |
| zyga-ubuntu | what's up? | 19:14 |
| kyrofa | zyga-ubuntu, take a look at this: https://pastebin.ubuntu.com/26508980/ | 19:15 |
| kyrofa | zyga-ubuntu, note that the hook is present, and is executable | 19:15 |
| zyga-ubuntu | cannot find | 19:15 |
| zyga-ubuntu | hmm | 19:15 |
| zyga-ubuntu | can you nsenter into the namespace | 19:15 |
| zyga-ubuntu | and see if it's really there? | 19:15 |
| kyrofa | zyga-ubuntu, it's not my machine I'm afraid, but I'll pass that on. Note that this snap actually works fine on my machine, same version of core/snapd | 19:16 |
| zyga-ubuntu | is that iside a container? | 19:18 |
| kyrofa | zyga-ubuntu, Tyriar is the one having this issue, would you mind repeating what you said above? | 19:19 |
| zyga-ubuntu | kyrofa: I don't know what that may be caused by, if it says it cannot find it then it's probably not mounted | 19:19 |
| zyga-ubuntu | the hook runs inside the namespace | 19:19 |
| zyga-ubuntu | so it's probably just not there (probably the mount event didn't propagate inside) | 19:20 |
| kyrofa | zyga-ubuntu, indeed, this is actually parallels | 19:20 |
| kyrofa | Right Tyriar? | 19:21 |
| Tyriar | Yeah parallels | 19:21 |
| zyga-ubuntu | Tyriar: interesting | 19:21 |
| Tyriar | there are other issues with parallels I've noticed (cannot launch the snap from inside the snap) | 19:21 |
| zyga-ubuntu | Tyriar: what does "snap version" say? | 19:21 |
| zyga-ubuntu | Tyriar: thats normal, it's not allowed | 19:22 |
| zyga-ubuntu | parallels as in that virtualization software, right? | 19:22 |
| Tyriar | It works normally though? | 19:22 |
| zyga-ubuntu | no, it shouldn't | 19:22 |
| zyga-ubuntu | though | 19:22 |
| zyga-ubuntu | I wonder what parallels does | 19:22 |
| Tyriar | By running inside the snap, I mean a pty is launched from the snap which launches another window | 19:22 |
| Tyriar | Parallels is mac only VM software yeah | 19:22 |
| Tyriar | snap version: snap 2.30 snapd 2.30 series 16 ubuntu 16.04 kernel 4.4.0-104-generic | 19:23 |
| zyga-ubuntu | Tyriar: can you give me the output of "cat /proc/self/mountinfo" (tip: use pastebinit) | 19:23 |
| zyga-ubuntu | Tyriar: in any case, can you please drop a topic on the forum, give some information about how to reproduce the problem | 19:24 |
| zyga-ubuntu | I can try (no promises though) | 19:24 |
| Tyriar | https://pastebin.com/iFEKBUyq | 19:24 |
| zyga-ubuntu | this looks normal | 19:25 |
| zyga-ubuntu | which snap failed? | 19:25 |
| zyga-ubuntu | ah, my-snap | 19:25 |
| zyga-ubuntu | actually | 19:25 |
| zyga-ubuntu | maybe it's a bug :) | 19:25 |
| zyga-ubuntu | Tyriar: can you please switch core to the beta channel | 19:25 |
| zyga-ubuntu | there's a new release of snapd there | 19:26 |
| zyga-ubuntu | can you see if that also has the same issue | 19:26 |
| Tyriar | what do I run to switch the channel again? | 19:26 |
| kyrofa | zyga-ubuntu, I used my-snap in the pastebin, but it's actually the one at the very bottom of Tyriar's paste | 19:26 |
| zyga-ubuntu | code-insiders? | 19:26 |
| kyrofa | Indeed | 19:27 |
| zyga-ubuntu | so it's correctly shared:96OC | 19:27 |
| kyrofa | zyga-ubuntu, note also that the one that failed probably won't be there as it's the post-refresh hooks that's dying, thus rolling it back | 19:27 |
| zyga-ubuntu | it should be mounted inside the snap mount namespace | 19:27 |
| zyga-ubuntu | kyrofa: ah, noted | 19:27 |
| kyrofa | The ones you see there have no hooks | 19:27 |
| zyga-ubuntu | Tyriar: so when it failed, you were refreshing a snap? | 19:27 |
| zyga-ubuntu | were you refreshing from a store revision to a local revision? | 19:27 |
| kyrofa | zyga-ubuntu, just installing --dangerous over the top. | 19:28 |
| Tyriar | I was installing a local snap with --dangerous, over a store revision yes | 19:28 |
| kyrofa | Ah, wonder if that has something to do with it | 19:28 |
| kyrofa | I didn't try that | 19:28 |
| Tyriar | kyrofa, it's a private snap on the store which I think you have access to | 19:30 |
| zyga-ubuntu | kyrofa, Tyriar: this is something for pstolowski on monday | 19:31 |
| zyga-ubuntu | it may be a bug where we think a hook exists | 19:31 |
| zyga-ubuntu | but it doesn't in the right revision | 19:31 |
| zyga-ubuntu | but that's just a theory, no idea what's wrong for real | 19:31 |
| kyrofa | zyga-ubuntu, that sounds accurate given the symptoms | 19:32 |
| Tyriar | the store revision definitely doesn't have a post-refresh hook, if that matters | 19:32 |
| kyrofa | zyga-ubuntu, I'll try to install from the store and see if I can reproduce | 19:32 |
| zyga-ubuntu | yeah, looks like a bug there | 19:35 |
| * zyga-ubuntu looks at ubuntu in high-dpi and is amazed | 19:36 | |
| noise][ | FYI, having some API slowness + elevated error rates on snap store | 19:37 |
| noise][ | investigating | 19:37 |
| kyrofa | noise][, I was just about to ping you, thank you :) | 19:38 |
| noise][ | updated the status page but there seems to be a rendering delay there or something | 19:38 |
| mup | PR snapcraft#1913 opened: Use pyelftools to parse ELF files rather than using readelf <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/1913> | 20:00 |
| marosg | hi, is something wong with snapcraft.io? snap info takes 40 seconds and snap refresh times out | 20:07 |
| marosg | s/wong/wrong/ | 20:07 |
| Odd_Bloke | marosg: There is an issue with the snap store ATM; the team are working to address it. | 20:09 |
| kyrofa | noise][, I can't refresh anything either, but status.snapcraft.io shows green for everything except search | 20:14 |
| noise][ | site24x7 status page won't reflect my outage notif :( | 20:14 |
| noise][ | anyway, working the problem | 20:14 |
| mup | PR snapd#4602 opened: tests: use root path to /home/test/tmp to avoid lack of space issue <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4602> | 21:38 |
| cachio__ | mvo, please could you add the PR #4602 to the rc3 too? tx | 22:17 |
| mup | PR #4602: tests: use root path to /home/test/tmp to avoid lack of space issue <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4602> | 22:17 |
| zyga | are you guys still working on the release? | 22:17 |
| cachio__ | zyga, I just left the comment for mvo | 22:17 |
| cachio__ | I am almost done today | 22:18 |
| cachio__ | zyga, you should be too :) | 22:18 |
| zyga | yeah, though I'm not working anymore, just exploring my book collection | 22:18 |
| kyrofa | jdstrand, you around by any chance? | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!