| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| zyga | good morning | 05:05 |
|---|---|---|
| mborzecki | morning | 05:06 |
| mvo | hey zyga and mborzecki | 05:13 |
| zyga | Hey guys | 05:13 |
| * zyga has a doctor appointment on the other side of the city at 12:30, wondering if he should go now and wait there or wait and then go when it's hotter outside | 05:47 | |
| zyga | mborzecki: can you look at 5254 please? :) | 05:50 |
| zyga | mvo: I sent the kernel RFC idea we talked about last night to 5260 | 05:50 |
| mborzecki | btw. i think we should merge #5258 | 05:50 |
| mup | PR #5258: tests: fix lxd test which hangs on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5258> | 05:50 |
| zyga | +1 | 05:50 |
| zyga | mborzecki: 5257 is a short low hanging fruit in need of a 2nd review | 05:52 |
| mvo | zyga: ok | 05:53 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#5258 closed: tests: fix lxd test which hangs on restore <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5258> | 05:55 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mborzecki | zyga: 5257 is magic, had to go through snapstate for it to make sense :) | 06:16 |
| zyga | jdstrand: | 06:22 |
| mvo | mborzecki: thank you! it was sightly annoying because it poped up in the middle of something totally different | 06:23 |
| mup | PR snapd#5257 closed: snapstate: ensure fakestore returns TypeOS for the core snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5257> | 06:23 |
| mborzecki | mvo: hah, i can imagine it was tricky :) | 06:23 |
| mborzecki | zyga: can you take another look at #5256? | 06:24 |
| mup | PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256> | 06:24 |
| mup | PR snapd#5261 closed: tests: wait more time until snap start to be downloaded on econnreset test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5261> | 06:26 |
| mup | PR snapd#5241 closed: interfaces/udev: call 'udevadm settle --timeout=10' after triggering events <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5241> | 06:46 |
| mup | PR snapd#5255 closed: cmd/snap-confine: applied make fmt <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5255> | 07:02 |
| zyga | mvo: can I merge https://github.com/snapcore/snapd/pull/5248#pullrequestreview-125842002 | 07:05 |
| mup | PR #5248: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5248> | 07:05 |
| zyga | it is a 2.33 branch | 07:05 |
| zyga | with LXD test failing | 07:05 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:06 |
| zyga | pstolowski: good morning | 07:06 |
| mborzecki | mvo: can you cherry-pick https://github.com/snapcore/snapd/commit/7f4d533166b73551317bf421bc88f65cfd6b12f9 to 2.33 ? | 07:06 |
| mborzecki | or let me open a PR with it | 07:07 |
| mborzecki | (that's the lxd bit) | 07:07 |
| mvo | mborzecki: if you open a PR please also cherry-pick the econnreset thing | 07:07 |
| mborzecki | mvo: ok | 07:08 |
| mup | PR snapd#5262 opened: tests: backport lxd force stop and econnreset fixes (2.33) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5262> | 07:12 |
| mborzecki | mvo: zyga: ^^ | 07:12 |
| zyga | thanks | 07:12 |
| mvo | mborzecki: ta | 07:15 |
| pstolowski | jeez, got google:ubuntu-14.04-64:tests/main/econnreset failure this time; it seems to be flaky as well, i saw occasional failures before | 07:46 |
| mvo | pstolowski: master should have a workaround (timeout got increased) | 07:47 |
| pstolowski | mborzecki: hey, would you like to take another look at #5215 ? | 07:47 |
| pstolowski | mvo: ah, great, ty | 07:47 |
| mup | PR #5215: ifacestate: improved conflict and error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215> | 07:48 |
| justasking | hello everybody | 07:52 |
| justasking | will firefox snap touch my existing firefox profile (ESR 52)? | 07:52 |
| zyga | Hey | 07:53 |
| zyga | I’m going offline for a few hours, at least till 14 | 07:54 |
| zyga | Ping me on irc if urgent | 07:54 |
| zyga | I have an older laptop without a modem with me | 07:54 |
| zyga | And I will be gardening my old branches | 07:54 |
| mvo | 5204 needs a review | 07:55 |
| mvo | it would unblock some more core18 work | 07:55 |
| mborzecki | mvo: left some comments in 5204 | 08:19 |
| mborzecki | pedronis: you're breaking my heart, can't use gorename for that Name() -> LocalName() job now :) | 08:20 |
| pedronis | mborzecki: ? | 08:20 |
| mborzecki | pedronis: your comment about parallel installs and using a different name for the method to actually go through all the code locations where it's used at | 08:21 |
| mborzecki | pedronis: it's a valid concern btw | 08:21 |
| pedronis | mborzecki: well, I'm trying to make suggestions not to break the software | 08:21 |
| pedronis | I understand they are annoying, maybe | 08:22 |
| pedronis | as I said, it's likely that you might learn that most places were fine | 08:22 |
| pedronis | but is a bit unclear | 08:22 |
| mborzecki | yeah i tried to jot down some places where i'm certain we'll need the non-local name (eg. apparmor profiles, sice we'll hide the local name inside the mount ns) | 08:24 |
| pstolowski | pedronis: hey, about disconnect hooks, i think that if the snap on either end of connection is not active, we should either error out (but not with retry, it doesn't make much senso imho) or we should run the disconnect hook only on the active side and ignore the inactive one. both options are a little bit problematic though - we don't want to leak resources by not running a hook, but at the same time you may have good | 08:33 |
| pstolowski | reason to have snap disabled. and I don't think we want to block snap removal on not being able to run disconnect hook on the other end (because snap on the other end is not active) | 08:33 |
| pedronis | pstolowski: mmh, we have static inactive and dynamic inactive though | 08:34 |
| pstolowski | pedronis: what do you mean, don't we have a single Active flag? | 08:34 |
| pedronis | pstolowski: yes, but remember a refreshed snap is inactive for a while | 08:35 |
| pedronis | and then gets back to active | 08:35 |
| pedronis | that's why we have the complexity in autoconnect | 08:35 |
| pedronis | pstolowski: afaik you need the same kind of code as autoconnect, but anyway all of this shows we really need to implement some of my recommendations or something similar. it's clear it's hard to keep in mind this stuff | 08:38 |
| pstolowski | yes | 08:38 |
| pstolowski | pedronis: btw I've read your recommendations twice last week, very well written, i've yet to read it once more | 08:40 |
| pedronis | pstolowski: but yes, if the other side has no pending link* task and its inactive you have to skip its hooks | 08:47 |
| pedronis | that's probably true for autoconnect as well (unless it's not listed anyway for other reasons) | 08:48 |
| pedronis | pstolowski: as we discussed the behavior of disable and connections is probably a bit buggy already | 09:16 |
| pstolowski | yes | 09:25 |
| mup | PR snapd#5263 opened: errtracker: do not send duplicated reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/5263> | 09:52 |
| Chipaca | how would root know what a user's XDG_CONFIG_HOME is? | 10:13 |
| mvo | Chipaca: in what context do you want to know? | 10:23 |
| mvo | Chipaca: inspect /proc/$pid/environ | 10:23 |
| mvo | Chipaca: of the user | 10:23 |
| Chipaca | mvo: daemon running as root needing to look at a user's config | 10:23 |
| mvo | Chipaca: but even then nfs-root-squash may squash us | 10:23 |
| mvo | Chipaca: maybe running a helper as this user? | 10:24 |
| Chipaca | :-( yeah | 10:24 |
| Chipaca | mvo: there might be a way to refactor things to take away the need, also | 10:26 |
| mup | PR snapd#5215 closed: ifacestate: improved conflict and error handling when creating autoconnect tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5215> | 10:29 |
| mup | PR snapd#5248 closed: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5248> | 10:29 |
| mvo | Chipaca: quick question about 5176 - this need to be reworked to just do a net.Dial() - is that correct? and also a new api command? | 10:33 |
| Chipaca | mvo: I understand that for some of them, yes | 10:33 |
| Chipaca | mvo: but not for all | 10:34 |
| Chipaca | mvo: the 'get the details and check the cdn' thing is still full http | 10:34 |
| Chipaca | so really just the auth check | 10:34 |
| mvo | Chipaca: ok | 10:34 |
| Chipaca | mvo: and one of the auth checks needs dropping entirely | 10:34 |
| mvo | Chipaca: do you have any thoughts about the API to use? apparently /v2/debug is out | 10:35 |
| pedronis | mvo: we need to discuss, I think it could go in some for under system-info | 10:35 |
| pedronis | inventing tons of new api is not sane either | 10:35 |
| pedronis | I think | 10:35 |
| Chipaca | mvo: so... I'd either like to add a system-info command that better mapped /v2/system-info, with options of all sorts | 10:35 |
| Chipaca | mvo: or, maybe, have version grow options | 10:35 |
| pedronis | Chipaca: yes, that was my proposoal | 10:35 |
| Chipaca | the second one feels weird | 10:35 |
| pedronis | but didn't discuss it with Gustavo | 10:36 |
| pedronis | is in a note in the PR | 10:36 |
| pedronis | s/note/commnet/ | 10:36 |
| Chipaca | and then, whatever the command, i think a /v2/system-info option would be best for this and the verbose sandboxing thing | 10:36 |
| Chipaca | sandbox-features i mean | 10:36 |
| pedronis | that one landed already though | 10:36 |
| pedronis | but maybe it's in .33 ? | 10:37 |
| Chipaca | e.g. /v2/system-info?select=connectivity and /v2/system-info?select=sandbox-features | 10:37 |
| Chipaca | yep, landed, but could be hidden and deprecated | 10:37 |
| * pedronis needs to go have lunch | 10:37 | |
| mvo | 2.33 is not released outside of beta yet so that should be fine | 10:37 |
| pedronis | mvo: anyway we should have a chat at standup about this | 10:37 |
| mvo | pedronis: ok | 10:38 |
| * pedronis lunch is a bit delayed | 10:43 | |
| pedronis | mvo: btw discussing with Gustavo he also proposed that maybe we just continue to stick system config to "core" as key (even if it's not there), it might work, but it might mean disallowing config on any base until we have understand more/have a use case | 10:44 |
| mvo | pedronis: oh, interessting idea | 10:46 |
| mvo | pedronis: I was starting to look at the config once 5259 is ready (unless the concensus is that we should solve both in a single PR) | 10:47 |
| mborzecki | what would be the easiest way to stick custom snap-exec into core? bind mount my local copy over the real one? | 10:50 |
| mvo | mborzecki: for testing? yeah, bind mount sounds like the easiest option | 10:50 |
| mborzecki | mvo: yup for testing only | 10:50 |
| mvo | mborzecki: yeah, manual testing should be fine this way. alternative you can unpack the core snap and repack it | 10:51 |
| mvo | (but no need I think) | 10:51 |
| mborzecki | i actually make the tmpfs for /snap work somehow, snap-exec is the last bit standing in the way | 10:51 |
| pstolowski | ugh, unit test error on debian-9-64:tests/unit/go in master, on undo hooks test; i'm looking at it | 11:13 |
| mup | PR snapd#5252 closed: store, jsonutil: move store.getStructFields to jsonutil.StructFields <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5252> | 11:23 |
| mup | PR snapd#5264 opened: many: use ~/.config/snap if it exists, instead of ~/.snap <Created by chipaca> <https://github.com/snapcore/snapd/pull/5264> | 11:35 |
| Chipaca | law of preservation of the number of chipaca PRs | 11:36 |
| mborzecki | Chipaca: you should aim for 2, no more, no less, one big one small | 11:39 |
| mborzecki | your own rule of two | 11:39 |
| * Chipaca checks | 11:40 | |
| Chipaca | yep, that's where I'm at | 11:40 |
| Chipaca | now if we all did this, we'd be *fine* | 11:40 |
| pedronis | mborzecki: afair Gustavo explicitly said he expected to force the dir to always exist, not to use a tmpfs (that might be an issue on systems not having /snap though) | 11:44 |
| mborzecki | pedronis: the /snap/<snap-name> dir? | 11:45 |
| pedronis | yes | 11:45 |
| mborzecki | ack | 11:45 |
| * Chipaca lunches | 11:52 | |
| zyga | mborzecki: hey, would you mind reviewing 5254? | 12:10 |
| pstolowski | fyi, my isp seems to be experiencing a major outage, even their own website is down and their phone is completely busy right now | 12:16 |
| zyga | pstolowski: orange? | 12:20 |
| pstolowski | zyga: awacom, a local provider | 12:21 |
| zyga | ah | 12:21 |
| zyga | wired network? | 12:21 |
| pstolowski | Yes | 12:21 |
| mvo | 5225 needs a second review, should be simple | 12:23 |
| * zyga looks | 12:27 | |
| zyga | mvo: are we putting snapfuse on PATH? | 12:28 |
| mvo | zyga: yes and iirc we have to so that fuse finds it | 12:29 |
| Chipaca | mborzecki: The proposed constrains <- constraints | 12:30 |
| Chipaca | mborzecki: and I'd expect to be able to know the local key from inside the snap, as a debugging aid if nothing more | 12:31 |
| Chipaca | hm, i'll repeat this on the forum | 12:31 |
| * pstolowski back online | 12:31 | |
| mborzecki | Chipaca: please do | 12:32 |
| mup | PR snapd#5225 closed: selftest: add new selftest package that tests squashfs mounting <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5225> | 12:32 |
| mvo | zyga: was 5225 a squash merge or a regular one? | 12:34 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/5260/files needs a 2nd review and is pretty simple | 12:34 |
| zyga | mvo: I don't know, whatever was default on my system :/ | 12:34 |
| mup | PR #5260: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <https://github.com/snapcore/snapd/pull/5260> | 12:34 |
| zyga | probably regular | 12:34 |
| zyga | do you need a cherry pick ? | 12:34 |
| mvo | zyga: ok, I will do some cherry picks then | 12:34 |
| mvo | zyga: yeah, I want this for 2.33 as it may help with the protocol problem issues we see on errors.u.c | 12:34 |
| zyga | mvo: hold on, we can revert | 12:35 |
| zyga | and squash | 12:35 |
| zyga | shall I try? | 12:35 |
| mvo | zyga: its ok, its not that many commits | 12:35 |
| zyga | I'm sorry, I just read the diff and didn't noice the squash label | 12:35 |
| mvo | zyga: no worries | 12:35 |
| Chipaca | zyga: don't forget the 360 fun | 12:38 |
| zyga | Chipaca: already done it | 12:39 |
| zyga | oops | 12:39 |
| zyga | I will skip standup today | 12:39 |
| mup | PR snapd#5265 opened: selftest: add new selftest package that tests squashfs mounting (2.33) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5265> | 12:39 |
| zyga | I actually should file the day as off as I wasn't of much use (doctor visit) | 12:39 |
| Chipaca | zyga: hmmm! | 12:39 |
| * Chipaca scribbles in his little black book | 12:39 | |
| zyga | my daughter is returning from overnight school trip | 12:39 |
| zyga | and I need to pick her up in 20 minutes | 12:39 |
| sil2100 | mvo: hey! Hope that you don't mind that to save you some time after I review some smaller merges from you and approve, I'll also merge them? | 12:39 |
| mvo | sil2100: sounds great | 12:40 |
| sil2100 | mvo: also, my work hours will be a bit strange this week as my team is in Portland | 12:40 |
| mvo | sil2100: aha, right. the sprint | 12:40 |
| mvo | sil2100: have fun, I understand that you will be less available during the sprint | 12:40 |
| sil2100 | So I'm working in the morning and then to be with them on all the meetings I'm sticking around till after midnight | 12:40 |
| zyga | sil2100: Portland sounds just like Poland, there was a joke about that somewhere ;) | 12:41 |
| sil2100 | (since I stayed home) | 12:41 |
| mvo | sil2100: ok | 12:41 |
| sil2100 | zyga: almost like home! | 12:41 |
| zyga | Chipaca: some comments on 5264 | 12:42 |
| mborzecki | Chipaca: SNAP_HKEY_LOCAL_MACHINE and we're ready for being bought by MS | 12:44 |
| Chipaca | mborzecki: \o/ | 12:44 |
| pstolowski | :) | 12:44 |
| zyga | mborzecki: you will implement snapd active directory integration | 12:45 |
| zyga | and local group policy | 12:45 |
| * sil2100 AFK for a bit, will try to be back for standup | 12:45 | |
| Chipaca | As part of that effort, I'll implement counting the dosh | 12:45 |
| zyga | dosh? | 12:45 |
| Chipaca | zyga: money | 12:45 |
| mborzecki | zyga: i can do the LDAP login bits, leave the rest for you :P | 12:45 |
| zyga | Chipaca: cash++ | 12:45 |
| Son_Goku | nooooo! | 12:45 |
| * Son_Goku runs away from the insanity | 12:46 | |
| * zyga observes Son_Goku run around in a room where all walls are plastered with big-brand company names | 12:46 | |
| * Son_Goku runs screaming with his eyes bugging out | 12:46 | |
| Chipaca | also we need to move from squashfs to that filesystem that was actually just ms's sql | 12:47 |
| * Son_Goku dies | 12:47 | |
| mborzecki | Chipaca: the one that never made its way to windows? | 12:47 |
| Son_Goku | WinFS | 12:48 |
| Son_Goku | https://en.wikipedia.org/wiki/WinFS | 12:48 |
| Son_Goku | DBaaFS | 12:48 |
| * zyga goes to pick up his daughter | 12:49 | |
| zyga | mvo: I'm skipping standup, sorry | 12:49 |
| mvo | zyga: ok | 12:50 |
| mvo | zyga: (fun fact right next to ok (if you shift one row to the right): pl) | 12:50 |
| Chipaca | mvo: so you're saying pl is not ok because it's too far east | 12:53 |
| mvo | Chipaca: the opposite, its very ok, spelled ok one column on the keyboard to the east actually | 12:54 |
| Chipaca | mvo: if you want ok, but you're from the far right, you get pl | 12:54 |
| Chipaca | mvo: got it | 12:54 |
| mup | PR snapd#5266 opened: interfaces/builtin/docker: use commonInterface over specific struct <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5266> | 13:24 |
| mup | PR snapd#5264 closed: many: use ~/.config/snap if it exists, instead of ~/.snap <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5264> | 13:31 |
| mup | PR snapd#5260 closed: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5260> | 13:40 |
| mborzecki | pstolowski: is this something you are looking into https://paste.ubuntu.com/p/qkNvVZcZZ6/ ? | 13:42 |
| pstolowski | mborzecki: yes! | 13:42 |
| mborzecki | ack | 13:42 |
| pstolowski | mborzecki: where do you see it? | 13:42 |
| mborzecki | pstolowski: saw it here https://github.com/snapcore/snapd/pull/5256 (restarted the build already) | 13:43 |
| mup | PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256> | 13:43 |
| pstolowski | mborzecki: debian or something else? | 13:43 |
| mborzecki | pstolowski: ubuntu-16.04-32 | 13:43 |
| Chipaca | https://github.com/snapcore/snapd/pull/5266 seems wrong to me, but I don't know enough to explain (or even count) the ways | 13:44 |
| mup | PR #5266: interfaces/builtin/docker: use commonInterface over specific struct <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5266> | 13:44 |
| pstolowski | mborzecki: ah, ok. that's good i guess | 13:44 |
| Chipaca | probably a zyga or jdstrand thing ^^ | 13:44 |
| * zyga looks | 13:46 | |
| Trel | I had one question after continuing to read up on this, what interfaces need to be request for access to dotfiles in a user's home directory? | 13:47 |
| zyga | done | 13:48 |
| zyga | Trel: there's no generic interface for all of them | 13:49 |
| zyga | Trel: which dot files are you after, specifically? | 13:49 |
| zyga | https://github.com/snapcore/snapd/pull/5230 needs a second review | 13:51 |
| mup | PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230> | 13:51 |
| Trel | In this case the ability to write new dotfiles to a user's home directory (or another they specify) as well as read ones that are already there, specifically .profile and .bashrc | 13:51 |
| Trel | maybe also .bash_profile | 13:52 |
| Trel | I saw "home" gives homedir access, but not to hidden files | 13:52 |
| zyga | Trel: there is no interface for that | 13:52 |
| zyga | because that is very dangerous | 13:52 |
| zyga | you can use it to essentially bypass confinement | 13:52 |
| zyga | why do you need to write to bash/sh profile files? | 13:52 |
| Trel | I'm assuming because of . and ..? | 13:52 |
| Trel | In this case, I was thinking of converting my new machine/account setup script(s) to a snap | 13:53 |
| Trel | Part of it is adding my standard dotfiles like .vimrc, adding to my PATH and adding some bits to .profile and .bashrc | 13:54 |
| zyga | because any interface that would allow this is pretty much equivalent to becoming unconfined it would not be something we hand out easily | 13:54 |
| zyga | I would instead suggest to rework the application to show how to add anything to one's profile scripts | 13:54 |
| zyga | part of the appeal of snaps is that they don't have real root/superpower over one's machine anymore | 13:55 |
| zyga | and we don't want to break the trust by creating an interface that can be easily abused | 13:55 |
| zyga | even if the intentions were pristine | 13:55 |
| Trel | I'm a confused about other than the .. directory entry, how accessing dotfiles in user's home is dangerous to anything other than the user | 13:56 |
| Trel | Or is that the reason why? | 13:56 |
| zyga | Trel: let me explain | 13:57 |
| zyga | Trel: if you can write to ~/.profile | 13:57 |
| zyga | then you can insert a payload that runs the next time a terminal is open | 13:57 |
| zyga | (or the next time any login shell starts) | 13:57 |
| zyga | that code is no longer confined so it could, for instance, wget a script from somewhere | 13:57 |
| zyga | and pipe it to sh | 13:57 |
| zyga | and that can do anything | 13:57 |
| zyga | so this is effectively a way to break out of the sandbox | 13:57 |
| Trel | Still restricted to that user's permissions though, right? That doesn't get you root access for example | 13:58 |
| zyga | no, but you can steal user's secrets, install malware, exploit a kernel issue to become root or anything else | 13:58 |
| zyga | (malware doesn't have to be root) | 13:58 |
| Trel | Yes, I meant full system compromise vs user compromise is all | 13:59 |
| Trel | I suppose I could have it generate a finalize script and drop it in their home that they'd have to run after manually. | 13:59 |
| Trel | In this case it's for my use primarily to expidite new setups, so I'd trust it since I wrote it. | 14:00 |
| zyga | right | 14:00 |
| zyga | well, you can always make a private devmode snap | 14:00 |
| zyga | but if you want to ship it to everyone you need to play by the sandbox rules | 14:01 |
| Trel | That's not something that'd be depreciated right? I have no problem using devmode for this since it's primarily personal. I'd distribute manually to anyone (non-me) who'd want it | 14:04 |
| niemeyer | sergiusens: I won't be around at that time today.. can we have it right now? | 14:04 |
| niemeyer | Otherwise it'll probably be too late for Evan | 14:05 |
| zyga | Trel: I don't think devmode for private snaps is something that is going to become deprecated | 14:05 |
| sergiusens | niemeyer: I set it for tomorrow, it is 7am for kyrofa_ right now | 14:05 |
| sergiusens | starting next week, it is on Tuesdays, | 14:05 |
| niemeyer | sergiusens: Ah, that works, thanks | 14:06 |
| sergiusens | does that work niemeyer or should I reschedule? | 14:06 |
| sergiusens | ah, great :-) | 14:06 |
| sergiusens | I had an issue yesterday with family and scheduling the meeting earlier flew by me, sorry for that | 14:07 |
| Trel | Then I guess that's fine for this one then. Most of the others I wanted to do are simple text transforms which I have to pipe text into, so I don't think those would need anything at all | 14:10 |
| Trel | I'm thinking of bundling a bunch of the text transforms into a single one and publishing that. | 14:10 |
| mup | PR snapd#5262 closed: tests: backport lxd force stop and econnreset fixes (2.33) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5262> | 14:12 |
| zyga | mborzecki: thank you for the review | 14:16 |
| sergiusens | Chipaca: what's the progress on getting the snap command split out and ported over for us to use for `snap pack`? | 14:22 |
| * zyga -> lunch | 14:31 | |
| Chipaca | sergiusens: "ported over"? | 14:35 |
| Chipaca | sergiusens: snap pack has had --check-skeleton for a while now (i thought you'd reviewed that?) | 14:35 |
| Chipaca | sergiusens: we haven't split it into its own .deb yet though | 14:37 |
| sergiusens | Chipaca: I had not reviewed AFAIK. We only discussed early March. "ported over", we currently support `snapcraft pack` on osx (and windows) | 14:37 |
| sergiusens | Chipaca: yeah, I cannot really use it until it is standalone | 14:38 |
| Chipaca | sergiusens: sorry, getting mixed messages | 14:38 |
| Chipaca | sergiusens: you wouldn't use the .deb on windows nor osx | 14:38 |
| Chipaca | sergiusens: so as far as those are concerned, it's unclear to me what you need | 14:38 |
| Chipaca | sergiusens: there are no code changes afaik to make it standalone, unless i'm misremembering | 14:39 |
| Chipaca | it's just packaging | 14:39 |
| sergiusens | Chipaca: let me state the requirement so I don't impose how you deliver it; I the `snap pack` to be runnable on Windows, OSX and Linux | 14:39 |
| Chipaca | sergiusens: ok. Done! | 14:39 |
| sergiusens | just tell me how to get it on each platform and we are good :-) | 14:39 |
| Chipaca | sergiusens: I don't have access to those platforms, but I assume you do. Do you have a go build env? | 14:40 |
| mvo | Chipaca: I did the changes as discussed in the standup to connectivity check, what about authConnCheck() - should this become a net.Dial() only check? if so I will delete a lot of code now | 14:40 |
| Chipaca | sergiusens: I seem to recall we explicitly agreed that we weren't on the hook for delivering binaries to windows and osx; if that's not correct, then we have a bunch of busywork to have that happen | 14:41 |
| Chipaca | sergiusens: so my question is, i think, how do you get the rest of the snapcraft build environ onto windows and osx | 14:42 |
| sergiusens | Chipaca: not immediately, no. I don't think it is as important now, but it would be a regression to not support it anymore | 14:42 |
| sergiusens | Chipaca: `brew install snapcraft` and on windows in a venv for now | 14:43 |
| sergiusens | brew install snapcraft is essentially a venv, just wrapped nicely into a higher order package manager | 14:43 |
| Chipaca | sergiusens: how does 'brew install snapcraft' or the venv pull in squashfs-tools? | 14:45 |
| sergiusens | Chipaca: https://formulae.brew.sh/formula/snapcraft | 14:45 |
| Chipaca | sergiusens: and that builds mksquashfs from source? | 14:46 |
| sergiusens | Chipaca: it is easy to create a formula for the snap command, I can scaffold it and get the first version if you promise to maintain it ;) | 14:46 |
| sergiusens | Chipaca: only on "upload", you would get it in what homebrew calls a "bottle" | 14:46 |
| Chipaca | sergiusens: if by "it" you mean the formula or whatnot, that's exactly what I'm trying to understand who owns it | 14:46 |
| sergiusens | which is like a wheel in python | 14:46 |
| sergiusens | Chipaca: https://github.com/Homebrew/homebrew-core/blob/master/Formula/snapcraft.rb | 14:47 |
| Pharaoh_Atem | brew formulae are similar to rpm specs or Arch PKGBUILDs | 14:47 |
| mvo | Chipaca: did my earlier question get lost? or are you just busy? | 14:47 |
| Pharaoh_Atem | main difference is that unlike the latter two, formulae are based on Ruby rather than shell | 14:47 |
| mvo | Chipaca: (busy is fine, just asking to ensure its not lost) | 14:47 |
| Chipaca | mvo: I'm trying to understand if we're on the hook for windows and osx binaries of snap and the surrounding build infra or not | 14:48 |
| Chipaca | I wouldn't even start to hazard a guess at how to integrate that with our CI | 14:49 |
| Pharaoh_Atem | Chipaca: you are probably not | 14:49 |
| sergiusens | Chipaca: I own the snapcraft formula (maintain it), someone else the squash one. Once there is a snap command on homebrew I can replace the squashfs in "depends_on" to whatever the snap thing is called. | 14:49 |
| mvo | Chipaca: hm,hm,we will need a minimal snap pack in this case, we use too much syscall imports right now for GOOS=windows (but you know this already :) | 14:49 |
| sergiusens | Chipaca: alternatively, I can condition the code to just use the snap command on Linux and fallback to mksquashfs on other OS | 14:49 |
| Pharaoh_Atem | sergiusens: it'd be simpler to just test for the /usr/bin/snap command, and if it doesn't exist, always fall back | 14:50 |
| sergiusens | Pharaoh_Atem: yeah, an actual call with parameter checks to be honest as the `snap` command namespace is quite busy ;-) | 14:50 |
| sergiusens | there is no `snap` formula yet at least | 14:51 |
| Chipaca | mvo: yes, authConnCheck should be a single net.Dial to the macaroon endpoint | 14:52 |
| Chipaca | sergiusens: do you know how to build things for osx and windows from travis? | 14:54 |
| * Chipaca googles | 14:56 | |
| sergiusens | Chipaca: look at our .travis.yml and appveyor.yaml | 15:10 |
| mup | PR snapd#5267 opened: tests: retry 'restarting into..' match in the snap-confine-from-core test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5267> | 15:11 |
| morphis | mvo: ping | 15:15 |
| Chipaca | sergiusens: ok, i'll take a stab at it | 15:16 |
| mvo | morphis: pon | 15:17 |
| mvo | morphis: h | 15:17 |
| mvo | morphis: pong | 15:17 |
| mvo | Chipaca: I updated the PR in question fwiw, but no rush | 15:17 |
| mvo | zyga: do you think you could look at 5204 again? | 15:18 |
| mvo | zyga: you asked for changes and I think I addressed things now | 15:18 |
| zyga | Chipaca: sure | 15:21 |
| * zyga looks | 15:21 | |
| morphis | mvo: I tried to create a base snap recently and wanted to check if I was running into a bug or if what I was trying to do is simply not supported yet | 15:21 |
| morphis | mvo: basically I was setting `type: base` in my snap, build it and then installed it | 15:22 |
| morphis | however after running $ snap run --shell snap.app I was still seeing the core snap mounted on / | 15:22 |
| zyga | morphis: we didn't anticipate bases with apps so bases use core for their apps | 15:22 |
| zyga | (which is odd) | 15:22 |
| morphis | isn't that the core principle of a base? | 15:23 |
| zyga | morphis: no, the principle of bases (so far) is to host other snaps | 15:23 |
| zyga | not saying that it's a bad idea | 15:24 |
| zyga | but it is something we didn't anticipate | 15:24 |
| zyga | that's all | 15:24 |
| morphis | isn't that what ubuntu-core will require snapd to do? | 15:24 |
| zyga | I don't understand, can you rephrase please? | 15:25 |
| zyga | snapd won't ship any apps either | 15:25 |
| zyga | (in the sense of snap declared apps) | 15:25 |
| morphis | in terms of ubuntu-core core18 will be a base snap, right? | 15:25 |
| zyga | yes | 15:25 |
| zyga | but it won't have apps or services | 15:25 |
| morphis | none which are exposed through the snap, right | 15:26 |
| morphis | but something still has to provide systemd which is handled by the initramfs mounting core18 as / and running systemd outside of a snap environment | 15:26 |
| zyga | yes, that is whatever has booted, my only point is that snap applications from bases were unanticipated | 15:27 |
| zyga | it's a bug | 15:27 |
| zyga | but we need to think what it means if we allow it | 15:27 |
| morphis | so basically snapd ignores all apps defined in a base snap, correct? | 15:27 |
| zyga | I don't think it does | 15:28 |
| zyga | Chipaca: ^ does it | 15:28 |
| Chipaca | hmmmm | 15:28 |
| zyga | I think we need to decide if we should ignore all apps / hooks or if we should handle them consistently with the same snap used as base | 15:28 |
| Chipaca | I'd have to check, as I don't remember offhand, but it's quite possible there's an "if snap.type is app" | 15:29 |
| morphis | I saw the apps exported as I could do `$ snap run --shell snap.app` | 15:29 |
| zyga | mvo: review on 5204 | 15:30 |
| morphis | Chipaca, zyga: let me get that base snap back installed and try again | 15:32 |
| zyga | morphis can you open a thread about this | 15:32 |
| Chipaca | morphis: it's also possible there _isn't_ one | 15:32 |
| zyga | so that we don't forget | 15:33 |
| morphis | zyga: sure | 15:33 |
| zyga | I think it's a valid use case | 15:33 |
| zyga | but I want to be formal about it | 15:33 |
| zyga | my gut feeling is that bases _must_ use themselves as base | 15:33 |
| zyga | I need to walk my dog quickly, 15 min AFK | 15:33 |
| morphis | zyga: if they don't I see weird things happening | 15:34 |
| morphis | what if a fedora base snap has an app defined which then is executed against the Ubuntu core snap | 15:34 |
| zyga | Yeah | 15:38 |
| zyga | I agree | 15:38 |
| Chipaca | graaaahgh | 15:39 |
| Chipaca | I think I'm going to start from the other end, and move stuff around for pack, instead of trying to make osutil build everywhere | 15:40 |
| * Chipaca gets more tea | 15:40 | |
| morphis | zyga: Chipaca: but thanks for the insights | 15:40 |
| morphis | zyga, Chipaca: ok, both services and apps work when `type: base` is set, however my base is more or less Ubuntu 16.04 as its more or less an app snap relabeled as a base | 15:44 |
| mup | PR snapd#5268 opened: tests: fix flaky test for hooks undo <Critical> <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5268> | 15:55 |
| pstolowski | zyga, mvo ^ a trivial that should fix flaky test that we currently have | 15:56 |
| zyga | Thank you :-) | 16:00 |
| pstolowski | zyga: thanks for review, I enhanced the description, hope it makes more sense | 16:08 |
| mvo | pstolowski: nice | 16:08 |
| pstolowski | cachio: addressed your suggestion re #5267 | 16:09 |
| mup | PR #5267: tests: retry 'restarting into..' match in the snap-confine-from-core test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5267> | 16:09 |
| pstolowski | mvo, zyga ^ and that's another trivial re flaky tests | 16:10 |
| mvo | morphis: sorry, had to step out for a bit, that sounds like something to discuss in the forum, I'm not against having apps for bases but we need to discuss this at least with gustavo | 16:10 |
| zyga | Ok | 16:10 |
| mvo | zyga: re review> $< iirc only takes the first "dependency" of a make rule | 16:11 |
| zyga | yes, did I suggest that? | 16:14 |
| zyga | I meant $^ | 16:14 |
| zyga | sorry | 16:14 |
| mvo | zyga: aha, sure | 16:18 |
| === pstolowski is now known as pstolowski|afk | ||
| * zyga tea and fixing branches | 16:23 | |
| mvo | zyga: thanks for the review, I will think about the name a bit over dinner (snapd.manager, snapd.entrypoint, snapd.run-from-snapd, snapd.start-me-up, ...) ideas welcome :) | 16:29 |
| zyga | snapd.stargate | 16:29 |
| zyga | snapd.snapd.snapd | 16:29 |
| zyga | snapd.make-it-so | 16:29 |
| zyga | snapd.startup | 16:30 |
| zyga | maybe just snapd.run-from-snapd-snap | 16:39 |
| morphis | mvo: thanks! I will open a forum topic tomorrow | 16:50 |
| mup | PR snapcraft#2157 opened: nodejs plugin: update to the latest 6.x LTS point release <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2157> | 17:02 |
| mvo | zyga: updated, thanks for your suggestions | 17:29 |
| zyga | Super, i will check in a sec, finishing my supper | 17:30 |
| zyga | Which name did you pick? | 17:30 |
| mvo | pedronis: just to double check - we can kill authConnCheck entirely? | 17:30 |
| mvo | zyga: your suggestion from earlier: snapd.run-from-snap | 17:30 |
| pedronis | mvo: afaiu yes, all those bits are activate/relevant only on "snap login" | 17:31 |
| zyga | +1 | 17:32 |
| pedronis | *activated | 17:32 |
| mvo | pedronis: great, less code is always better. I removed those bits now | 17:33 |
| zyga | mvo: review on 5204 | 18:06 |
| cachio | zyga, https://paste.ubuntu.com/p/tqghBCHfb6/ | 18:38 |
| cachio | any idea why the configure hook is giving me this? | 18:39 |
| alphawarrior | Hello everyone. Can I update snapcraft from an older version using itself? I'm on gentoo and the "latest" package linked by the snapcraft tutorial on installing only has a 2 year old version :( | 18:39 |
| nacc | alphawarrior: snapcraft is itself available as a snap | 18:53 |
| alphawarrior | oh thanks ^^ | 18:54 |
| === jz is now known as Guest1025 | ||
| jzzz | Hello. I'm having trouble getting new vanilla canonical kubernetes installed into lxd containers on my ubuntu host to come back up after a restart. Wondering if anyone might be able to help me. The error msgs seem to point towards apparmor/snap. | 19:52 |
| jzzz | I'm thinking apparmor/snap is the root cause because `dmesg` shows entries like `[90947.819924] audit: type=1400 audit(1528228545.536:2983): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/usr/lib/snapd/snap-confine" name="snap-update-ns.kube-apiserver" pid=24205 comm="snap-confine"` | 19:56 |
| zyga | I’m afk but I will check it out soon | 19:57 |
| jzzz | with snap-update-ns errors for kube-apiserver and etcd, and similar snap.kubelet.kubelet errors. | 19:58 |
| jzzz | thx @zyga. pls let me know whatever I can do on my system for more clues. | 19:59 |
| zyga | Ack | 19:59 |
| jzzz | the stacktrace from `juju debug-log` looks like it might be kicking off a subprocess that is running a sanity check command (giving back the version) to determine that the service is installed in the container. Here's a pastebin: https://pastebin.com/60VR7gSi | 20:04 |
| jzzz | so I'm not sure if the apparmor/snap error is a cause or a symptom. :\ | 20:05 |
| jzzz | ``` $ uname -r 4.4.0-127-generic $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.4 LTS Release: 16.04 Codename: xenial ``` | 20:08 |
| mup | PR snapd#5265 closed: selftest: add new selftest package that tests squashfs mounting (2.33) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5265> | 20:26 |
| cachio | niemeyer, hey, did you see this https://travis-ci.org/snapcore/snapd/builds/388466179 ? | 20:31 |
| Luke | hey guys, is there a recommended way for dealing with creating and using multiple users within a single snap? For example, nginx + pgsql + the app all being on different users? | 20:38 |
| mup | PR snapd#5269 opened: systemd: adjust TestWriteMountUnitForDirs() to use squashfs.MockUseFuse(false) <Simple> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5269> | 21:03 |
| jdstrand | Luke: not yet. you probably want to follow https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461 | 21:09 |
| Luke | jdstrand: thanks! | 21:19 |
| Luke | jdstrand: this is the perfect answer to my question. thanks for taking the time to write this up | 21:20 |
| jdstrand | Luke: np. it is roadmapped and getting closer to implementing, but it'll be a little while yet | 21:21 |
| Luke | jdstrand: I think with this post I can work my way around it without too much compromise | 21:34 |
| jdstrand | cool | 21:36 |
| zyga | re | 21:36 |
| niemeyer | cachio: No, fix is due | 22:17 |
| zyga | jdstrand: can you have another look at 5254 please, I'm still pondering one aspect (has suffix check) but I think I addressed all the points you have raised | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!