| kyrofa | jorian, snap would be a good option for packaging your app _together_ with the newer lib | 00:22 |
|---|---|---|
| === georgeowell_ is now known as georgeowell | ||
| diddledan | if anyone is familiar with locales in combo with snaps, is the folder usr/lib/locale important for an app, or can I omit it (presumably by not installing locales-all in stage-packages)? | 01:00 |
| diddledan | it's 117MB is all so it's bloating my snap to rather large proportions | 01:01 |
| diddledan | (117MB uncompressed) | 01:02 |
| === chihchun_afk is now known as chihchun | ||
| nacc | kyrofa: good point, sorry I didn't say that more explicitly | 03:48 |
| mup | PR snapd#3334 closed: Release snapd 2.26.2 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3334> | 05:51 |
| mup | PR snapd#3336 opened: Reease snapd 2.26.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3336> | 05:51 |
| mup | PR snapd#3292 closed: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3292> | 05:58 |
| mup | PR snapcraft#1320 opened: store: send X-Ubuntu-Series, not X-Ubuntu-Release <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1320> | 06:09 |
| mup | PR snapd#3337 opened: errtracker: try multiple paths to read machine-id <Created by morphis> <https://github.com/snapcore/snapd/pull/3337> | 06:33 |
| morphis | mvo: ^^ | 06:34 |
| mvo | morphis: cool, thank you | 06:41 |
| mvo | morphis: is there a leftover debug fmt.Prinln in there ;) ? | 06:42 |
| morphis | mvo: yeah, could be :-) | 06:42 |
| mvo | morphis: looks great otherwise, I will do a formal review in a bit, just fixing the image, shadow is out-of-sync with the archive | 06:43 |
| morphis | mvo: oh wonderful, that just happened recently | 06:43 |
| morphis | mvo: dropped the Println | 06:43 |
| zyga | good morning | 06:47 |
| zyga | mvo: hey, I'd like to trigger a build of the ppa that feeds edge, I'm looking at https://launchpad.net/~snappy-dev but I see quite a few archives there, can you give me a hand plese? | 07:00 |
| zyga | mvo: perhaps we could close some archives (I suspect we don't need all of them at once) | 07:00 |
| zyga | CC ogra_ ^^ | 07:01 |
| mvo | zyga: sure, let me check | 07:01 |
| * zyga goes to garden PRs in the meantime | 07:02 | |
| zyga | thank you :) | 07:02 |
| mvo | zyga: https://launchpad.net/~snappy-dev/+snap/core is what need if you want to trigger a new build | 07:03 |
| mvo | zyga: please check that shadow build in the ppa:snappy-dev/image, would be good to have that fix in the iamge too | 07:04 |
| zyga | mvo: I know the snap recipe, I was just struggling with the PPA part | 07:05 |
| mvo | zyga: aha, ok | 07:05 |
| zyga | mvo: thank you! | 07:05 |
| mvo | zyga: ppa:snappy-dev/image is the relevant one | 07:05 |
| mvo | zyga: I will trigger a new build now unless you want something else in there too? | 07:06 |
| zyga | mvo: I'll talk to ogra about closing the remaining archives, they feel like just noise | 07:06 |
| zyga | mvo: no, everyting is ready since yesterday | 07:06 |
| zyga | mvo: please go ahead | 07:06 |
| zyga | everything* | 07:06 |
| mvo | zyga: I deleted some obvious ones, some are 15.04, if we are really sure we don't need 15.04 anymore for the previous snappy incarnation then those can go | 07:06 |
| zyga | mvo: though when I refreshed core today (from edge) I got 2.26.2 | 07:07 |
| zyga | mvo: what about this one? https://launchpad.net/~snappy-dev/+archive/ubuntu/edge2 | 07:07 |
| zyga | or https://launchpad.net/~snappy-dev/+archive/ubuntu/beta ? | 07:07 |
| mvo | zyga: checking | 07:10 |
| mvo | zyga: I guess beta is fine to remove, the risk is always that if you delete a ppa you screw all the people who still have it in their sources.list | 07:11 |
| mvo | zyga: but given that the latest archive in there that is still supported is trusty the risk is relatively low | 07:11 |
| mvo | zyga: I will delete edge2 after this core build | 07:12 |
| zyga | mvo: there is something wrong in the image | 07:13 |
| zyga | https://travis-ci.org/snapcore/snapd/builds/233106199#L3814 | 07:13 |
| zyga | mvo: this is the 2.26.2 merge back to master | 07:13 |
| zyga | we lack --extrausers | 07:13 |
| zyga | it seems like the archive package has higher version number | 07:13 |
| mvo | zyga: yes, the core build that is currently in process will fix it | 07:13 |
| zyga | and we're not getting the patched one | 07:13 |
| zyga | ah, perfect, thank you for handling this :) | 07:13 |
| morphis | zyga: thanks for pushing to my PR but I will squash that change if you're ok | 07:20 |
| morphis | was about to push the same | 07:21 |
| zyga | morphis: no worries, do it | 07:25 |
| zyga | morphis: I'd squash myself if I knew you wanted it :) | 07:25 |
| morphis | :-) | 07:25 |
| fgimenez | hi mvo: i've started with 2.26.2 validation, tests/main/listing and tests/main/interefaces-log-observe are failing on i386 (the first one that finished) this is expected (it seems that https://github.com/snapcore/snapd/pull/3327 is missong in the release branch), right? | 07:36 |
| mup | PR snapd#3327: tests: fix failing tests (snap core version, syslog changes) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3327> | 07:36 |
| mvo | fgimenez: meh, the listing test! we may need to backport that fix to 2.26 too | 07:38 |
| mvo | fgimenez: interfaces-log-observe is unexpected | 07:38 |
| mvo | fgimenez: tests/main/listing will also fail in autopkgtest so we also need a new SRU :/ | 07:38 |
| fgimenez | mvo: i think interfaces-log-observe is fixed in the same branch, will check in the upgrade-from-stable scenario | 07:39 |
| morphis | zyga: so moment of truth, running the entire main suite again for fedora, we should now close to 100% | 07:39 |
| morphis | or better said close to 100% of those tests which apply to Fedora (disabled those which test re-execution or classic confinement which we don't support on Fedora yet) | 07:40 |
| mup | PR snapd#3338 opened: tests/main/completion: source from /usr/share/bash-completion <Created by morphis> <https://github.com/snapcore/snapd/pull/3338> | 07:43 |
| zyga | morphis: I'm very happy to see that :) | 07:44 |
| morphis | :-) | 07:44 |
| morphis | zyga: when you're leaving for the suse conference? | 07:44 |
| zyga | next week | 07:45 |
| zyga | 25th | 07:45 |
| morphis | ok | 07:45 |
| pedronis | mvo: why interfaces-log-observe is unexpected? did you build also with an older revision of core stuff | 07:58 |
| mvo | pedronis: well, maybe it is not, I have not checked the log what exactly is failing. if it has a similar regex as the listing test then it is not unexpected | 08:01 |
| * zyga hugs mvo - the SRU dancer | 08:01 | |
| mvo | pedronis: I will check as soon as I'm finished with the current code review | 08:01 |
| pedronis | mvo: well we turned off rsyslog | 08:01 |
| zyga | yep, that was bundled into chipaca's branch | 08:01 |
| pedronis | at least that's why we had interfaces-log-observe issues on the mainline | 08:01 |
| === didrocks1 is now known as didrocks | ||
| mvo | pedronis: aha, I must have missed that, thank you. that will also need to be ported then | 08:04 |
| pedronis | mvo: here is the discussion https://forum.snapcraft.io/t/change-in-logging-behaviour-on-ubuntu-core/591/4 jdstrand still thinks it's bad backward compatibility wise | 08:05 |
| mvo | pedronis: fwiw, I agree with that | 08:06 |
| mvo | pedronis: if it changed from 2.26 to 2.26.3 that would also be very bad | 08:07 |
| mvo | pedronis: thanks for raising it, I will look, it definitely needs to go into the release notes if it goes into 2.26 | 08:08 |
| mvo | pedronis: I will follow up in the forum, I think if nothing else we should create some hint for people looking at /var/log/syslog that they now need to use journalctl | 08:10 |
| morphis | zyga: you already had time to look into the bind problem? this really prevents configure hook execution on !ubuntu for all !core snaps | 08:18 |
| zyga | mvo: can you override merge https://github.com/snapcore/snapd/pull/3332 so that we don't waste resources on re-testing it | 08:18 |
| mup | PR snapd#3332: interfaces/seccomp: document Backend.NewSpecification <Created by zyga> <https://github.com/snapcore/snapd/pull/3332> | 08:18 |
| zyga | pstolowski: hey | 08:19 |
| pstolowski | zyga, hey! | 08:19 |
| zyga | pstolowski: question about https://github.com/snapcore/snapd/pull/3328 - how would you feel starting afresh; take that branch, squash the history so that it makes more sense | 08:19 |
| mup | PR snapd#3328: many: snapctl outside hooks v2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/3328> | 08:19 |
| morphis | zyga: 87% pass rate, is what I have now | 08:19 |
| zyga | pstolowski: I will work with you on the regexp code elimination today | 08:20 |
| pstolowski | zyga, np, i can do that if it helps | 08:20 |
| mvo | morphis: nice job | 08:21 |
| zyga | pstolowski: as you think but I would recommend it, it's a "new" PR and the history is full of stuff that makes it harder to follow | 08:21 |
| mup | PR snapd#3332 closed: interfaces/seccomp: document Backend.NewSpecification <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3332> | 08:21 |
| morphis | mvo, zyga: however we need to fix the bind() problem for hooks this cycle, if you have any pointers for me what calls it in the go libs when snapctl is executed from your previous research that would be a great starting point | 08:22 |
| zyga | morphis: sure | 08:22 |
| mvo | morphis: who should I talk to about the dropping of rsyslog in the CE team? I would like to make sure none of our existing customers will suffer because of it | 08:22 |
| pstolowski | zyga, ok, will do in a few | 08:22 |
| zyga | morphis: it's easy, one sec | 08:22 |
| morphis | mvo: I can raise this with Tony later today, it will mean that /var/log/syslog is not being filled anymore, right? | 08:23 |
| morphis | joc: would that be a problem for you guys in any way? | 08:23 |
| mvo | morphis: I think so, I'm looking at it right now | 08:24 |
| zyga | morphis: look at /usr/share/go-1.6/src/net | 08:25 |
| zyga | morphis: look at /usr/share/go-1.6/src/net/net.go line 99 | 08:25 |
| zyga | morphis: on startup the net package probes ipv4 and ipv6 | 08:25 |
| fgimenez | mvo: i can conform that adding the changes in snapd#3327 to the release/2.26 branch makes the full suite pass using core from beta (amd64 so far) | 08:25 |
| mup | PR snapd#3327: tests: fix failing tests (snap core version, syslog changes) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3327> | 08:25 |
| fgimenez | *confirm | 08:25 |
| morphis | zyga: hm | 08:25 |
| zyga | morphis: it creates two sockets and binds them to localhost address | 08:26 |
| joc | morphis: pretty sure we have some tests that expect to be able to find events logged in syslog | 08:26 |
| zyga | morphis: I don't know if seccomp can even express that | 08:26 |
| zyga | morphis: and even if, I don't know if this is safe | 08:26 |
| zyga | morphis: after all, you can bind on localhost and that's still IPC | 08:26 |
| joc | morphis: off the top of my head, usb insertions | 08:27 |
| zyga | morphis: apart from allowing any hook to do "socket+bind" | 08:27 |
| zyga | morphis: or waiting for the bleeding edge kernel that can return EPERM | 08:27 |
| zyga | morphis: (instead of killing) | 08:27 |
| zyga | morphis: well, clarification, all kernels can EPERM, we want bleeding edge kernel that does EPERM + audit | 08:27 |
| zyga | morphis: even if we just return EPERM today, I don't know if we can do that per syscall | 08:28 |
| zyga | morphis: and even if we can I don't know how that combines with a rule that allows bind (say an actual hook that has the network-bind plug) | 08:28 |
| zyga | morphis: all in all, it's pretty messy at this level | 08:28 |
| zyga | morphis: for network filtering I'd feel much better if we wrapped things in a network namespace and used firewall rules | 08:29 |
| zyga | morphis: but that's a huge chunk of work | 08:29 |
| zyga | joc: interesting | 08:29 |
| zyga | mvo: ^^ | 08:29 |
| morphis | zyga: hm | 08:29 |
| zyga | mvo: how about postponing this till we can ship a working rsyslog snap? | 08:29 |
| zyga | mvo: I know it's a tough problem because we have people that want both things _now_ | 08:30 |
| mvo | zyga: this was suggested by jamie as well, see the forum discussion | 08:30 |
| zyga | mvo: alternatively allow customers to disable it | 08:31 |
| zyga | mvo: but don't disable yet and don't remove yet | 08:31 |
| icey | I'm trying to make a snap of a prigram that uses git internally, to clone and manage stuff, I'm having trouble getting all of git working from within the snap | 08:31 |
| mvo | zyga: I personally think even the removal is risky, its a stable 16 core afterall and we enforce updates. if an update is percived to be breaking functionality that will weaken the trust in the system | 08:31 |
| zyga | mvo: yes, I agree | 08:31 |
| icey | looks like it's not finding the stuff that's normally in /usr/lib/git-core/ | 08:31 |
| zyga | icey: that's expected | 08:31 |
| zyga | icey: snap execution environment is not like the regular environment | 08:31 |
| icey | zyga: I'm aware | 08:32 |
| icey | zyga: I've got git installed in the snap | 08:32 |
| zyga | icey: all the content of your snap is in $SNAP which is something like /snap/yourfancysnapname/123 | 08:32 |
| icey | zyga: my program executes git fine, but git can't find any of its handlers | 08:32 |
| zyga | icey: and the root filesystem is not the one you normally see | 08:32 |
| zyga | icey: but the core snap itself (see /snap/core/current for some ideas) | 08:32 |
| icey | zyga: warning: templates not found /usr/share/git-core/templates | 08:32 |
| icey | fatal: Unable to find remote helper for 'http' | 08:32 |
| zyga | icey: tip: run snap run --shell yoursnapname and look around | 08:32 |
| icey | zyga: yes, I've been doing that | 08:32 |
| icey | zyga: I'm wondering if anybody has figured out a way to let a program use git (inside the snap) as a dependency | 08:33 |
| zyga | icey: some people that tried this also set a variable that redirects git to look elsewhere but I don't remember the details | 08:33 |
| zyga | icey: yes they have, there was a discussion here a few months ago | 08:34 |
| zyga | icey: but you will still struggle with ssh as ~/.ssh is not going to be available | 08:34 |
| icey | zyga: I'm digging through git's manpages now to try to find environment variables | 08:34 |
| zyga | icey: and $HOME will not retain its value | 08:34 |
| zyga | icey: dig through git source code | 08:34 |
| icey | zyga: I'm only expecting to use the http handlers | 08:34 |
| zyga | icey: should be good then | 08:35 |
| icey | zyga: and I'm not using $HOME | 08:35 |
| zyga | morphis: what do you think about the bind issue? | 08:35 |
| icey | zyga: practically, my program should be fine (and I can change its source ;-) ) | 08:35 |
| morphis | zyga: it's hard to say what we can do | 08:35 |
| morphis | zyga: it would be good if you could generate a profile specific for snapctl | 08:36 |
| morphis | as that is the real issue here and it gets executed under the umbrella of the hook profile | 08:36 |
| icey | zyga: do you know if the environment variable is a runtime change or if it would need to be an install time thing? | 08:36 |
| zyga | icey: I don't know | 08:37 |
| zyga | icey: may be either, it was long ago, sorry :/ | 08:37 |
| pedronis | fgimenez: mvo: we need to upload some test-snapd-* snap with a configure hook (can be empty, accept anything) | 08:37 |
| zyga | morphis: interesting | 08:37 |
| zyga | morphis: that may be a nice way out | 08:37 |
| morphis | zyga: yes | 08:37 |
| zyga | morphis: we could have a profile just for snapctl and allow anyone to run snapctl in a way that changes profiles | 08:37 |
| morphis | zyga: is that something we can do without a lot of refactoring? | 08:37 |
| zyga | morphis: there's still risk ask overmount must now reject you from changing snapctl | 08:37 |
| zyga | morphis: perhaps | 08:38 |
| zyga | morphis: let me try | 08:38 |
| mvo | pedronis: do we have the snap already? if so its trivial for me to upload | 08:38 |
| zyga | morphis: thanks for the idea! | 08:38 |
| morphis | zyga: np :-) | 08:38 |
| pedronis | mvo: no | 08:38 |
| morphis | zyga: if you have some initial code I can help more with that as we need to get this fixed real soon | 08:38 |
| pedronis | mvo: can make a PR with one though | 08:38 |
| mvo | pedronis: ok, I can create one - test-snapd-with-configure ? | 08:38 |
| pedronis | yea | 08:38 |
| mvo | pedronis: whatever is easier for you :) | 08:38 |
| morphis | zyga: I can open a forum topic to get this more widely discussed | 08:38 |
| mvo | pedronis: but I can do it too | 08:39 |
| zyga | morphis: open one please | 08:39 |
| zyga | morphis: I have no code at all but I can get started quickly | 08:39 |
| zyga | morphis: it's actually trivial to test | 08:39 |
| morphis | zyga: would be great! | 08:39 |
| pedronis | mvo: I'll make a PR about that and ping you | 08:39 |
| mvo | pedronis: thanks a bunch ! | 08:39 |
| mvo | pedronis: btw, 3211 (the repair assertion) is green and has two +1, anything else I can do there or can I merge? | 08:40 |
| pedronis | mvo: I think it's fine personally, also after further thinking I think it's a good property that if we want we can emit a canonical signed brand_model-# assertion if needed | 08:41 |
| pedronis | (witho some coord with the brand) | 08:41 |
| zyga | morphis: hmmmmmm | 08:41 |
| zyga | morphis: I think there's a separate problem | 08:42 |
| zyga | morphis: we can change the apparmor profile | 08:42 |
| zyga | morphis: but not the seccomp profile | 08:42 |
| zyga | morphis: let me read some man pages | 08:42 |
| icey | zyga: any chance there's a way to see the snapcraft.yaml used to build a snap? looks like https://uappexplorer.com/app/git-repo.jhodapp may have figured it out | 08:42 |
| mvo | pedronis: great, I merge it then, it got a +1 from gustavo as well, we can always iterate, its not being actively used yet anyway | 08:42 |
| pedronis | mvo: yup | 08:42 |
| zyga | icey: no | 08:43 |
| zyga | icey: I know there's ongoing work for that but I don't think it is ready :/ | 08:43 |
| zyga | icey: you can just reach to the author of that snap | 08:43 |
| pedronis | mvo: do we have a core that fixe create-user ? or is still building? | 08:43 |
| icey | yeah zyga, stalking hiim on GH + Launchpad hasn't led me to useful results | 08:44 |
| pedronis | Chipaca: maybe snapd#3335 is something you can review? | 08:45 |
| mup | PR snapd#3335: daemon: teach the daemon to wait on active connections when shutting down <Created by pedronis> <https://github.com/snapcore/snapd/pull/3335> | 08:45 |
| Chipaca | nah | 08:45 |
| Chipaca | :-p | 08:45 |
| zyga | oh, no battery | 08:45 |
| * zyga looks for cable | 08:45 | |
| icey | zyga: looks like there's a $prefix available during build, I'm going to try building git in my snap ;-) | 08:46 |
| mvo | fwiw https://codecov.io/gh/snapcore/snapd/pulls | 08:46 |
| zyga | icey: tip: set prefix to /snap/your-snap-name/current/usr and then install it so that the snap's prime directory only contains the /usr part | 08:47 |
| zyga | icey: (I think you can do this with organize) | 08:47 |
| mup | PR snapd#3211 closed: assertions: add "repair" assertion <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3211> | 08:47 |
| zyga | icey: ask kyrofa for hints, I'm not using snapcraft that much and my knowledge can be stale | 08:47 |
| mvo | zyga: also sorry about the missing comment on 3308 - I added one last night but for some reason gh marked it as pending :/ | 08:47 |
| Chipaca | pedronis: 1.6 didn't have Shutdown, i guess | 08:50 |
| pedronis | Chipaca: it doesn't | 08:50 |
| pedronis | with 1.8 | 08:50 |
| pedronis | we wouldn't need this | 08:50 |
| pedronis | but doing it similarly means we if/when we move to 1.8, the change is easier | 08:51 |
| pstolowski | zyga, we already have sc_snap_name_validate, which is regexp-free | 08:52 |
| pedronis | there was some idea to do something inside Command.ServeHTTP , but this seems less invasive | 08:52 |
| zyga | pstolowski: I think we need a few more as well | 08:53 |
| zyga | pstolowski: but yeah | 08:53 |
| zyga | pstolowski: that's the way to go | 08:53 |
| zyga | mvo: no worries, I just replied to your question | 08:53 |
| zyga | mvo: thank you for responding :) | 08:53 |
| pedronis | Chipaca: I need to merge master and waiting for a fixed core to rerun tests, so I can add a comment about that | 08:54 |
| Chipaca | pedronis: +1, anyway | 08:54 |
| Chipaca | pedronis: my questions were merely because the godoc i have up right now points to 1.8 | 08:55 |
| Chipaca | if it had been pointing to 1.6 i woudln't've had to ask them at all | 08:55 |
| Chipaca | code is super clear | 08:55 |
| mup | PR snapd#3328 closed: many: snapctl outside hooks v2 <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/3328> | 08:55 |
| pedronis | thx | 08:55 |
| zyga | offtopic: wow, amd has released some insane chips! | 08:58 |
| mup | PR snapd#3338 closed: tests/main/completion: source from /usr/share/bash-completion <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3338> | 08:58 |
| morphis | mvo: thanks! | 08:59 |
| pedronis | mvo: do you have a tentative date for 2.27 ? | 08:59 |
| zyga | mvo: new core built | 09:03 |
| mvo | pedronis: yes, 23.05 ideally, that would follow the two weeks cadance, I created a milestone | 09:03 |
| mvo | zyga: another new core? what changed? | 09:03 |
| zyga | mvo: I was thinking that the release "shadow" issues say we should think about a pair of PPAs and snap recipes | 09:03 |
| zyga | mvo: I think it was the one you built :) | 09:04 |
| zyga | mvo: 2.26.2 with fixed --extrausers | 09:04 |
| pedronis | mvo: thank you | 09:04 |
| zyga | mvo: I'd like to see the new core, from master, with update-ns though | 09:04 |
| mvo | zyga: that one finished some time ago, maybe the last stranglers or something | 09:04 |
| zyga | mvo: without interrupting the release | 09:04 |
| morphis | zyga: reading a bit through the snap-confine code for the seccomp setup .. | 09:04 |
| zyga | mvo: perhaps, I'm on 1952 now | 09:04 |
| zyga | morphis: seccomp can only be appended to, I think | 09:04 |
| zyga | morphis: (constrained) | 09:05 |
| mvo | zyga: I can't parse the "shadow" issue suggestion, sorry. could you elaborate please? | 09:05 |
| zyga | mvo: sure, sorry, the conflict of which snapd package is build into the snap | 09:05 |
| mvo | zyga: the update-ns from core? I think we need to merge the 2.26.2 change first | 09:05 |
| morphis | zyga: so we can split out the current profile and extend just for snapctl? | 09:05 |
| zyga | mvo: like when you made 2.26.2 you needed to dput to a ppa and quickly build the core snap | 09:05 |
| zyga | mvo: so that another daily build doesn't clobber your state | 09:05 |
| zyga | morphis: "split out the current profile? | 09:05 |
| zyga | morphis: the problem is that as we can only constrain profiles | 09:06 |
| zyga | morphis: if you are in a hook/app that doesn't have network-bind (hook) | 09:06 |
| zyga | morphis: nothing you can do will add that | 09:06 |
| zyga | morphis: if you allow network-bind in the first place then you'd have to constrain it for _everything_ else (apart from snapctl) but there's no way to do that | 09:06 |
| mvo | zyga: thats how it works, except it does not need to be "quick" because as long as the version in the ppa is higher than the version in git master we are good, as soon as e.g. 3336 gets merged we get new core builds with the edge snapd. so the workflow is ok for now | 09:06 |
| morphis | zyga: hm | 09:07 |
| zyga | mvo: why didn't we get a single build in master that contains edge then? | 09:07 |
| zyga | mvo: it's not okay because it doesn't work, releases interrupt master and vice versa IMO | 09:07 |
| zyga | mvo: (I swapped the semantics of master and edge in the previous statement) | 09:07 |
| mvo | zyga: yeah, that is true, during release the edge is the released version not the edge version, that is annoying | 09:08 |
| zyga | mvo: not something i wan't to jump at fixing but I want to recongize the issue | 09:08 |
| morphis | zyga: we can't even patch golang for this .. | 09:08 |
| mvo | zyga: usually the interruption is short but this time its not because of the various issues (snapd, listing test breakage, rsyslog) | 09:08 |
| zyga | morphis: nope | 09:08 |
| mvo | zyga: yeah, agreed, I now understand your point and there is no disagreement | 09:09 |
| zyga | mvo: I was thinking if we could clone the current setup so we have two of everything: snap recipes, deb recipes and PPA archives | 09:09 |
| zyga | mvo: then edge just always contains master no matter what | 09:09 |
| zyga | mvo: and beta is a hand-triggered thing | 09:09 |
| zyga | mvo: though the list of packages in the ppa is scary :/ | 09:09 |
| zyga | mvo: I wish we didn't need those | 09:09 |
| zyga | mvo: for the rarely changing packages we could just copy them from edge ppa once in a while | 09:09 |
| zyga | mvo: but it'd be better if those didn't exist in the first place | 09:10 |
| zyga | mvo: and our ppa just contained snapd and nothing else | 09:10 |
| zyga | mvo: though maybe it can, with the image machinery | 09:10 |
| zyga | mvo: we might move everything else to a 3rd ppa that is there as a base for all core channels | 09:10 |
| mup | PR snapd#3336 closed: Reease snapd 2.26.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3336> | 09:12 |
| mvo | zyga: yes, we can build more infrastructure and decouple the two. there is also the suggesiton from Gustavo about decoupling the snapd build and the base image which is probably the first step as we get a more predictable core with it | 09:13 |
| zyga | mvo: yes, the way the core is assembled also has to change | 09:14 |
| ogra_ | zyga, i need to contact all the uploaders first, (i dont want to delete PPAs without consent), but i'll put dropping them on my TODO | 09:15 |
| zyga | ogra_: hey, good mornign | 09:16 |
| zyga | ogra_: I think mvo axed some PPAs | 09:16 |
| ogra_ | zyga, mvo, hmm, did you guys disable something already ? | 09:16 |
| zyga | ogra_: I think so | 09:17 |
| ogra_ | seems edge is broken | 09:17 |
| ogra_ | (the edge PPA) | 09:17 |
| zyga | ogra_: those looked very much dead anyway | 09:17 |
| zyga | ogra_: in which way? | 09:17 |
| ogra_ | "This PPA depends on disabled archives. it may cause spurious build failures or binaries with unexpected contents." | 09:17 |
| mvo | ogra_: I killed edge2, I can fix the fallout | 09:17 |
| ogra_ | this needs some planning i fear | 09:17 |
| ogra_ | ok | 09:17 |
| mvo | ogra_: edge is fine again | 09:18 |
| ogra_ | we should end up with image anbd edge though, all the others should go ... but there might be people or other PPAs still using them somehow | 09:18 |
| * ogra_ will start a forum thread | 09:18 | |
| zyga | ogra_: have a look at the discussion just above ^ where I advocate for a beta PPA | 09:18 |
| ogra_ | zyga, well, we should finally follow the plan ... | 09:19 |
| zyga | ogra_: as we (the snapd team) release just beta and edge snaps having a pair makes sense | 09:19 |
| ogra_ | it exists since nearly 2 years now and we're still buiolding from random PPAs | 09:19 |
| ogra_ | there should only be one PPA ... for edge ... the rest of the snap builds should come from different stages of the actual archive | 09:19 |
| * ogra_ points to the QA teams https://wiki.ubuntu.com/QATeam/OSSnapPromotion | 09:20 | |
| zyga | ogra_: did you see my rationale for a beta ppa? | 09:20 |
| zyga | ogra_: do you think it makes no sense to have it? | 09:21 |
| ogra_ | zyga, i think building beta from proposed is the way to go ... but that means a lot of PPA cleanup (packasges to go to the archive) | 09:21 |
| ogra_ | like the plan describes | 09:21 |
| ogra_ | else you have a PPA for beta builds and *still* need to do the deb release aside ... using proposed as beta stage archive saves that step | 09:22 |
| zyga | ogra_: interesting, yes, I think that could work | 09:22 |
| ogra_ | the problem is that we need to get rid of the image PPA or at least clean up massively in there | 09:23 |
| ogra_ | we could start with it enabled, but then we need to make sure the package version for snapd is always higher in proposed before we build | 09:24 |
| mup | PR snapd#3339 opened: tests/lib/snaps: add a test store snap with a passthrough configure hook <Created by pedronis> <https://github.com/snapcore/snapd/pull/3339> | 09:24 |
| pedronis | mvo: ^ | 09:25 |
| mvo | pedronis: thanks, on it | 09:26 |
| morphis | zyga: https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658 | 09:26 |
| zyga | morphis: I read it, thank you | 09:28 |
| zyga | I'm checking what the kernel allows | 09:28 |
| zyga | ogra_: who is doing the work on upstraming parts of our PPA? | 09:28 |
| mvo | pedronis: thanks, uploaded and shared with you | 09:29 |
| mup | PR snapd#3340 opened: Smany: snapctl outside hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3340> | 09:33 |
| pstolowski | zyga, ^ reopened; I've addressed some of your comments but not all, don't worry, i'll address them based on comments from previous PR | 09:34 |
| zyga | pstolowski: great, thank you! | 09:35 |
| * zyga looks | 09:35 | |
| * zyga needs some breakfast | 09:35 | |
| fgimenez | mvo: pi3 finished with just listing and interfaces-log-observe failing, no more crashes it seems, pi2 is good too so far (85/116), i'll trigger now the upgrade-from-stable scenario on pi3 (this one crahsed too on 2.26.1) | 09:35 |
| morphis | zyga: happy thing, latest golang git master has changed from an initializer to lazy support detection | 09:36 |
| morphis | so the func init() call is gone | 09:36 |
| mvo | fgimenez: excellent, thank you. I'm working on 2.26.3 that fixes the listing and observer failures | 09:36 |
| fgimenez | mvo: great tahnks | 09:36 |
| pstolowski | friendly neighbour drilling again... I need a walk... | 09:38 |
| fgimenez | mvo: pedronis should we upload test-snapd-with-configure to snappy-hub too and automate the upload to the store? it is not likely going to change too much, but to align it with the rest of test-snapd-*, i can prepare the lp branch and build | 09:39 |
| zyga | morphis: nice :) | 09:39 |
| morphis | zyga: however, doesn't really help us :-) | 09:39 |
| zyga | morphis: but still meh :( we won't be using that anytime soon | 09:39 |
| morphis | zyga: LD_PRELOAD would be another way but not sure if that would work | 09:40 |
| morphis | I guess golang doesn't go through libc for that | 09:40 |
| morphis | hm, they use syscall() | 09:41 |
| mup | PR snapd#3331 closed: tests: remove unit tests task <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3331> | 09:41 |
| zyga | morphis: how would LD_PRELOAD help? | 09:45 |
| morphis | zyga: if it would use libc to call bind we could easily intercept the bind() call | 09:45 |
| morphis | but we can't | 09:45 |
| zyga | morphis: ah, right | 09:45 |
| zyga | morphis: those are stright syscalls I'm afraid | 09:46 |
| zyga | also sucks for strace | 09:46 |
| zyga | (golang tooling sucks here) | 09:46 |
| morphis | zyga: yes | 09:46 |
| pedronis | mvo: mmh, I haven't got the sharing email for that snap afaict | 09:50 |
| mvo | pedronis: could you /msg me your primary sso email address please? there used to be a bug that it would only share it with this mail | 09:50 |
| * zyga eats breakfast while reading seccomp sources | 09:51 | |
| ogra_ | mvo, a review of https://github.com/snapcore/core/pull/43 would be appreciated ... (in that course ... i wonder if we should drop cron, the only remaining thing left for it is logrotate which we could switch to a systemd timer instead) | 10:11 |
| mup | PR core#43: remove generated logs, cleaner lsb-release removal <Created by ogra1> <https://github.com/snapcore/core/pull/43> | 10:11 |
| mvo | ogra_: I don't want to make the cron removal call, I think its risky to do package removal on a stable core, I would prefer if we do this and the rsyslog change in 18 only. but thats just me | 10:16 |
| morphis | zyga: hm, looks like we have a problem with rshared on Fedora | 10:17 |
| zyga | morphis: tell me | 10:19 |
| morphis | zyga: not sure yet, but the snap-on-non-shared-root spread tests fails, explicitly here https://github.com/snapcore/snapd/blob/master/tests/main/snap-on-non-shared-root/task.yaml#L18 | 10:19 |
| morphis | zyga: https://paste.ubuntu.com/24592098/ | 10:20 |
| zyga | morphis: can you capture that with SNAP_CONFINE_DEBUG=yes ? | 10:21 |
| pedronis | pstolowski: I think I'm a bit confused about the relationship between Sanitize* and Validate* and default values for interface attributes (which is not a concept we use much, mind) | 10:22 |
| morphis | zyga: yes, rebooting the machine right now and will do that | 10:23 |
| Chipaca | pedronis, mvo: is there an obvious way of adding info (e.g. apps) to overlord/snapstate's mock snaps that i'm missing? | 10:23 |
| pedronis | Chipaca: what kind of snaps ? snaptest.MockSNap ? | 10:24 |
| Chipaca | pedronis: most tests just start with a SideInfo | 10:25 |
| pedronis | well, there's snaptest.MockSnap | 10:25 |
| pedronis | that we use when you want something on disk | 10:25 |
| Chipaca | and it seems that changing that to something that has apps is a lot of repetitive typing | 10:25 |
| * Chipaca looks | 10:26 | |
| pedronis | (remember to undo the mocking of ReadInfo though) | 10:26 |
| pedronis | we use it sometimes in snapstate | 10:26 |
| pedronis | this is more for stuff already installed though | 10:27 |
| Chipaca | yep. sounds like the basic answer is 'no' :-/ but let me see how far i get | 10:27 |
| ogra_ | mvo, well, you should comment on the rsyslog thread at least ... i'll leave cron untouched for 16 then | 10:27 |
| pedronis | if you want to start from a .snap, there's something else | 10:27 |
| Chipaca | pedronis: yep. I was just wanting to avoid having to rewrite all the tests | 10:28 |
| * zyga errands | 10:28 | |
| Chipaca | well, 'all', 21 of them | 10:29 |
| pedronis | Chipaca: there is also snaptest.MakeTestSnapWithFiles if you need a .snap | 10:29 |
| abeato | zyga, hi, what do you mean by "atomic write helpers"? | 10:30 |
| Chipaca | I'll probably remove the code that makes all the tests fail, and come back to it later | 10:30 |
| mvo | ogra_: maybe, but it seems I'm just repeating something that has already been debated so I will not add much value to the discussion | 10:30 |
| morphis | zyga: https://paste.ubuntu.com/24592122/ | 10:30 |
| Chipaca | (with the changes i made it's super easy to not add the {start,stop}-snap-services task if the snap has no services, so I thought I'd do that, but it breaks 21 tests :-) ) | 10:30 |
| ogra_ | mvo, well, it will add value in that it shows you agree with jamie ... i would have preferred to just be able to disable it but didnt find it worth to have an argument about it | 10:31 |
| Chipaca | (sorry, not the task, the backend call) | 10:32 |
| morphis | zyga: will be out for lunch now | 10:33 |
| pedronis | Chipaca: ah, my experience is that making task optional is a recipe for pain | 10:34 |
| Chipaca | pedronis: i can imagine :-) but it's not the task, just the backend call, so it should be doable | 10:35 |
| Chipaca | :-) | 10:35 |
| Chipaca | pedronis: (and it'd avoid a lock/unlock of state, which is why i think it might be worth it) | 10:35 |
| pedronis | Chipaca: anyway if you go that way what you want is remove those things from all tests and then just have a couple of tests about your case | 10:35 |
| Chipaca | but, completely secondary to the work i'm doing | 10:35 |
| pedronis | Chipaca: not re-add services everywhere | 10:35 |
| Chipaca | pedronis: ! | 10:35 |
| Chipaca | good point | 10:35 |
| Chipaca | in a later branch. | 10:36 |
| * Chipaca tries to focus | 10:36 | |
| pedronis | fgimenez: mvo: still getting main/compleation create-key time outs fwiw :/ | 10:36 |
| Chipaca | basically in prep for 'snap start', i'm making wrappers.StartSnapServices -> wrappers.StartServices take a []*snap.AppInfo instead of a *snap.Info, and seeing how far into the beast this makes sense to let it bubble in | 10:37 |
| Chipaca | i've reached the task level with no great changes, and i think this is good | 10:37 |
| Chipaca | (not touching tasks) | 10:37 |
| fgimenez | pedronis: that's bad, do you have a link to the build? | 10:38 |
| pedronis | fgimenez: no, I resterarted it | 10:38 |
| pedronis | but nothing interesting | 10:38 |
| pedronis | just expect on create-key giving time out | 10:38 |
| pedronis | in the prepare of main/completion | 10:38 |
| fgimenez | pedronis: ok did you notice which system was failing? now we should be installing and configuring rng-tools for all the ubuntu-* systems | 10:40 |
| fgimenez | maybe that's not enough though, i think Chipaca suggested to use something else | 10:40 |
| pedronis | fgimenez: also here a prepare timed out: https://travis-ci.org/snapcore/snapd/builds/233161781 | 10:41 |
| pedronis | fgimenez: no, sorry, I will try to check that the next time :/ | 10:41 |
| Chipaca | look at the times on the prepares that succeeded | 10:41 |
| pedronis | fgimenez: it seems we are quite back into flaky land overall | 10:41 |
| pedronis | I see a green run everywhere I don't know many red ones | 10:41 |
| pedronis | :/ | 10:41 |
| fgimenez | pedronis: nw, i'll try to keep an eye on it | 10:41 |
| fgimenez | pedronis: yep, the flaky switch | 10:42 |
| abeato | Chipaca, hey, how this thing about export_test.go works? don't really get it | 10:42 |
| Chipaca | abeato: because it's called foo_test, it only is looked at during tests | 10:42 |
| Chipaca | abeato: but you put it in the foo package, not the foo_test package | 10:43 |
| Chipaca | abeato: so you have code in the main package that is only looked at during tests | 10:43 |
| pedronis | abeato: you write most of your _tesst.go tests with "package pkg_test" but you use "package pkg" in export_test.go | 10:43 |
| pedronis | go test collects and compiles all _test.go but export_test.go that way has access and can reexport give access to pkg internals | 10:44 |
| Chipaca | abeato: so there you can do things like make private methods public, or mock out external calls, or etc | 10:44 |
| Chipaca | abeato: hoping this makes sense in the context of that review :-) | 10:44 |
| Chipaca | abeato: as I said there, it looks good; the changes i asked for are idiomatic | 10:44 |
| Chipaca | looking forward to having that code :-) | 10:45 |
| abeato | Chipaca, does that mean that I need to add somewhat all private methods that I use in the tests to export_test.go? | 10:45 |
| fgimenez | pedronis: i've seen quite a few times the prepare timeout lately http://paste.ubuntu.com/24592153/, maybe we could remove the "quiet" call there now that we are folding the output in travis to see what's going on | 10:45 |
| abeato | Chipaca, sure, you know, I am starting with golang, so it is still hard for me :) | 10:45 |
| Chipaca | abeato: yep! we've all been there | 10:46 |
| Chipaca | abeato: wrt "all private methods", are there really that many? | 10:46 |
| Chipaca | it's usually just a few, if any | 10:46 |
| * Chipaca looks | 10:46 | |
| abeato | Chipaca, well, just too, androidboot and newAndroidboot | 10:47 |
| Chipaca | abeato: androidboot is a type, but you can add accessors in export_test | 10:47 |
| zyga | re | 10:47 |
| Chipaca | abeato: and yes, a constructor that lets you set more internal things makes sense | 10:48 |
| Chipaca | in export_test i mean | 10:48 |
| zyga | abeato: look at osutil/io.go | 10:48 |
| zyga | morphis: thank you, reading | 10:48 |
| abeato | Chipaca, will try that, thanks | 10:48 |
| Chipaca | abeato: also it might help you write the tests more unit-y if you mock androidbootenv.NewEnv | 10:49 |
| zyga | morphis: DEBUG: share snap directory here... this (somewhat ugly) output says that we rshared /snap | 10:49 |
| zyga | morphis: let me triple check | 10:49 |
| Chipaca | abeato: but i'm not fussed about that one | 10:49 |
| abeato | Chipaca, ok | 10:49 |
| Chipaca | abeato: (mocking would usually involve something like “var newEnv = androidbootenv.NewEnv” in the main code | 10:49 |
| Chipaca | abeato: then you use newEnv | 10:50 |
| zyga | morphis: but this also shows the code is different in master, | 10:50 |
| zyga | morphis: which release was this? | 10:50 |
| Chipaca | abeato: and in export_test you have a Mock function that lets you overwrite it | 10:50 |
| zyga | morphis: and if you can, try master | 10:50 |
| * zyga looks at email | 10:50 | |
| Chipaca | abeato: those Mock functions usually are func MockThing(newThing) func(), and they return a function that resets things to how they were | 10:50 |
| Chipaca | abeato: so you can do e.g. restore := MockThing(newThing); defer restore() | 10:51 |
| Chipaca | (or directly “defer MockThing(newThing)()” but that's harder to read) | 10:51 |
| Chipaca | abeato: anyway i'll let you work :-) | 10:51 |
| abeato | Chipaca, thanks :) | 10:51 |
| * zyga wonders what https://bugs.launchpad.net/snap-confine/+bug/1691405 is about | 10:52 | |
| mup | Bug #1691405: apt autoremove in removing snap-confine 2.24.1 cause mariadb galera crashes <galera> <mariadb> <snap-confine> <snap-confine:New> <https://launchpad.net/bugs/1691405> | 10:52 |
| ogra_ | zyga, smells like coincidence | 10:53 |
| Chipaca | zyga: quoth the raven, WAT | 10:53 |
| ogra_ | (hard to tell with proper logs etc) | 10:53 |
| zyga | Chipaca: my feeling exactly | 10:53 |
| mup | PR snapd#3341 opened: Release 2.26.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3341> | 11:03 |
| zyga | pstolowski: question about the validate methods: are they mandatory? | 11:07 |
| zyga | pstolowski: if not, can we drop the no-op ones? | 11:07 |
| pstolowski | zyga, my understanding is they are not mandatory, most interfaces will not need attributes collected at runtime. ok, I'll drop the no-op ones | 11:09 |
| zyga | pstolowski: thanks! | 11:09 |
| pstolowski | pedronis, re your earlier question.. we still need to discuss these aspects, i'm not sure if I know all I did matches what Gustavo had in mind last time we talked about it. the basic idea is that Sanitize* checks that attributes from yaml are fine and it can error out if a mandatory attribute is missing. It can also add missing attributes if it wants to. Whatever attributes are present after Sanitize* step, cannot be overwritten by snapctl at runtime. | 11:16 |
| pstolowski | Validate* methods should validate all attributes collected from snapctl | 11:16 |
| pedronis | pstolowski: the issue is whether, can Validate fill in defaults? because otherwise you cannot overwrite things with defaults left out form the yaml with those rules | 11:17 |
| pstolowski | *i'm not sure if all I did matches* | 11:17 |
| mup | PR snapd#3342 opened: this is a refactor branch, in preparation for 'snap start' etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342> | 11:18 |
| pedronis | pstolowski: in other words, my question is, should we fill defaults after the yaml, or do we need to support filling in defaults once we have seen both yaml attrs and dynamic attrs | 11:18 |
| pedronis | I vaguely remember that we discussed the latter, but then I don't understand the roles and when called of Sanitize* and Validate* anymore | 11:19 |
| pstolowski | pedronis, Sanitize* is still called when plug or slot is added to the repo | 11:20 |
| pedronis | I know | 11:21 |
| pedronis | but that doesn't help with defaults if we need to fill after dynamic attrs | 11:21 |
| pedronis | fgimenez: mvo: I'm seeing this kind of failures: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170517_111137_b1b51@/log.gz | 11:22 |
| juanrubio | Hi guys, I'm trying to figure out how to include a configure hook so that my application gets its configuration file updated before the first use. Going through the docs, I've placed a 'configure' script under 'tizonia/snap/hooks'.. see https://github.com/tizonia/tizonia-openmax-il/tree/master/snap/hooks... but the hook is not getting included in the snap | 11:22 |
| pedronis | it looks like we capture state.json when core is still being worked on somehow | 11:22 |
| * zyga -> lunch | 11:23 | |
| pedronis | fgimenez: mvo: error: snap "core" has changes in progress | 11:24 |
| fgimenez | pedronis: maybe because of the recent core publication? not sure | 11:24 |
| pstolowski | pedronis, shouldn't this decision be left out to the interface implementation? if it wishes to support some attributes from runtime, it needs to implement Validate* and supply defaults at Validate* time, or error out there if missing, Otherwise if interface doesn't support runtime attributes, they all need to come from yaml and be handled in Sanitize* | 11:24 |
| pedronis | pstolowski: that's a decision but now we have two places where to support attributes, or we just move things from Sanitize* to Validate* | 11:25 |
| pedronis | pstolowski: anyway I'm also interested to keep this thing under control because of the passing nil for attrs and methods trying to write them | 11:26 |
| pedronis | we need a hackish fix for content | 11:26 |
| pedronis | for that | 11:26 |
| fgimenez | pedronis: core with 2.26.3 has been just published to edge and beta, maybe the autorefresh detected it during the suite execution and started an update | 11:26 |
| pstolowski | pedronis, yes.. that's a valid concern. thanks for bringing it up | 11:27 |
| morphis | zyga: this is master between 2.25 and 2.26 | 11:27 |
| pedronis | s/we need/we did/ | 11:28 |
| mup | PR snapd#3335 closed: daemon: teach the daemon to wait on active connections when shutting down <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3335> | 11:29 |
| pedronis | fgimenez: ah | 11:29 |
| pedronis | pstolowski: what's the current idea? an interface supports dynamic attrs only if it has Validate* ? | 11:35 |
| pedronis | otherwise we error? | 11:35 |
| morphis | zyga: rebased now, let me see if that helps | 11:36 |
| pedronis | pstolowski: no, I remember discussing that, and the idea was to just ignore them? | 11:36 |
| sborovkov | hi, does service running inside the snap have access to /proc/$IT's_pid? | 11:39 |
| pstolowski | pedronis, if an interface doesn't implement Validate*, but its implementation supports any extra attributes not present in yaml and after Sanitize*, then it would work if they were supplied by a hook. | 11:40 |
| Chipaca | sborovkov: mostly, yes | 11:41 |
| jamespage | Q: what does the syntax for consuming a snap for a specific track look like? Google is failing me and I'm trying to write some forward looking UX for the openstack snaps | 11:41 |
| pstolowski | pedronis, in other words, if want to specifically block this scenario, that it needs an extra check | 11:41 |
| pedronis | I don't think we want to block it | 11:41 |
| Chipaca | jamespage: 'snap install --channel foo/bar thesnap' | 11:41 |
| jamespage | foo being the track and bar being the channel? | 11:41 |
| sborovkov | Chipaca: nice, I just want to know the number of threads my own process is using | 11:41 |
| jamespage | so that might be ocata/stable for me I think | 11:42 |
| pedronis | pstolowski: we call Validate* even if there are no dyamic attrs if it's defined? | 11:42 |
| Chipaca | sborovkov: where does that info come from? | 11:42 |
| sborovkov | Chipaca: well /proc/$pid/status should give that info I think. Not sure if there is better way | 11:42 |
| Chipaca | jamespage: see the 'snap info' output, might help | 11:42 |
| pstolowski | pedronis, yes. it receives plug or slot (same as Sanitize*), plus a dictionary with extra attributes (may be empty) | 11:43 |
| pedronis | jamespage: --channel=track[/risk] where risk defaults to stable | 11:43 |
| pstolowski | pedronis, btw, I feel that this discussion should happen in the forum | 11:43 |
| jamespage | pedronis: thanks | 11:43 |
| Chipaca | pedronis: the defaulting to stable only recently landed in master | 11:43 |
| Chipaca | so you're right, but it might not be what jamespage is on yet :-) | 11:44 |
| ogra_ | sborovkov, to find out such stuff, install hello-world ... then you can use hello-world.sh to spawn a shell inside the snap and check what it can read/access | 11:44 |
| jamespage | my forward looking UX is sufficiently far out it will be by the time we have things in tracks... | 11:44 |
| pedronis | pstolowski: do we have a topic already, I can write something there later | 11:44 |
| ogra_ | sborovkov, "cat /proc/self/status" definitely works fine here | 11:44 |
| pstolowski | pedronis, no, this branch is older than the forum ;) | 11:44 |
| sborovkov | ogra_: alright, thanks | 11:44 |
| ogra_ | (self always points to your PID) | 11:44 |
| sborovkov | wow nice I did not know that | 11:45 |
| pedronis | pstolowski: maybe you can start a topic then ;) | 11:45 |
| Chipaca | to be precise, jamespage: pedronis: making --channel=foo (for foo not in stable,candidate,beta,edge) mean foo/stable landed in master 5 days ago, in snapd#3290 | 11:45 |
| mup | PR snapd#3290: add support for `snap install foo --channel=3.4` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3290> | 11:45 |
| jamespage | \o/ | 11:46 |
| Chipaca | jamespage: hurray for forward-looking UX | 11:46 |
| Chipaca | jamespage: (also if you want to try it, use core from edge -- but it's called edge for a reason :-) ) | 11:46 |
| zyga | morphis: thank you, capture another trace with SNAP_CONFINE_DEBUG | 11:53 |
| mup | PR snapd#3343 opened: WIP: Spread tests for fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3343> | 11:56 |
| pstolowski | pedronis, sure, will do | 11:56 |
| pedronis | thx | 11:56 |
| diddledan | I just released corebird 1.5 to stable | 11:56 |
| diddledan | (amd64 only atm, until the buildd works properly :-p - jhbuild doesn't like it) | 11:57 |
| morphis | zyga: https://paste.ubuntu.com/24592352/ | 11:57 |
| morphis | zyga: the kernel and native arch values are wrong too | 11:57 |
| morphis | zyga: or these are raw printed values | 11:58 |
| morphis | looks like that is it | 11:59 |
| Chipaca | diddledan: looks good! why does it download libopenh264 outside of the snap? | 12:00 |
| diddledan | Chipaca: because it's legal | 12:00 |
| zyga | morphis: the kernel / arch thing is just the way seccomp represents them, there's nothing better sadly | 12:00 |
| zyga | morphis: interesting, | 12:00 |
| Chipaca | diddledan: meaning you can't distribute libopenh264? | 12:00 |
| zyga | morphis: can you cp snap-confine-debug to snap-confine | 12:00 |
| morphis | we could atleast do some string conversion so we print something like x86-64 but would be just for the reader :-) | 12:00 |
| zyga | morphis: and try again? | 12:01 |
| diddledan | Chipaca: you're still liable for licensing costs if you distribute it yourself | 12:01 |
| zyga | morphis: it's not that easy, it's not just a string | 12:01 |
| Chipaca | diddledan: ew | 12:01 |
| zyga | morphis: and it's opaque to us, internal seccomp thing | 12:01 |
| morphis | zyga: right but there are defined values which you compare already | 12:01 |
| diddledan | Chipaca: cisco are taking the hit for their compiled binary | 12:01 |
| morphis | like SCMP_ARCH_X86 | 12:01 |
| diddledan | of course, I didn't think about that for arm.. must sort out whether it's possible to download an arm binary on those | 12:02 |
| zyga | morphis: where? | 12:02 |
| morphis | seccomp-support.c | 12:02 |
| morphis | sc_add_seccomp_archs | 12:02 |
| zyga | ah | 12:02 |
| morphis | host_arch and native_arch | 12:02 |
| zyga | the problem is that it not the whole view | 12:02 |
| zyga | let me look at the internals of seccomp | 12:02 |
| zyga | AFAIR there are bitfields and flags and other bianry garbage there | 12:03 |
| morphis | zyga: let me build the -debug varaint of snap-confine and retry | 12:03 |
| zyga | morphis: the debug variant is built too, just not intstalled | 12:03 |
| zyga | morphis: you may have it in your tree | 12:03 |
| zyga | morphis: but really | 12:03 |
| morphis | zyga: you do a switch on host_arch against SCMP_ARCH_X86_64 | 12:03 |
| zyga | morphis: this is: mount --bind /snap /snap | 12:04 |
| zyga | morphis: what is wrong is clearly the path | 12:04 |
| morphis | so we can do something similar for a host_arch to string conversion | 12:04 |
| zyga | morphis: anyway, irrelevant to the problem and let's look at seccomp to be sure | 12:04 |
| jdstrand | morphis, zyga: trying to get through your backscroll conversaton-- it is spread out over several hours. but to confirm a few things: a) you can't seccomp arg filter bind because it can't derefernce userspace pointers (that is a hard limitation of seccomp) and b) there is no such thing as a profile transition with seccomp (that is a limitation of the kernel) c) you may change the current seccomp filter, but only by making it more restrictive (ie, you | 12:05 |
| morphis | zyga: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L641 , should that use the configured SNAPMOUNTDIR? | 12:05 |
| zyga | morphis: ah | 12:05 |
| zyga | yes | 12:05 |
| zyga | sorry, I should have caught that! | 12:06 |
| jdstrand | morphis, zyga: tyhicks is working on kernel changes that would allow us to not KILL but EPERM, which would make this non-fatal | 12:06 |
| morphis | jdstrand: hm, but a kernel change wouldn't really help in this case | 12:06 |
| zyga | morphis: shall you make a patch or do you want me to | 12:06 |
| morphis | zyga: let me do one | 12:06 |
| zyga | jdstrand: we can already EPERM, what AFAIK is missing is the extra message that goes along with the currnet KILL | 12:07 |
| zyga | morphis: thank you | 12:07 |
| zyga | *current | 12:07 |
| morphis | jdstrand: very interesting | 12:07 |
| zyga | jdstrand: though I really wonder how we plan to work with that, given the various kernels out there, is this something we can detect from userspace before we create the profile? | 12:07 |
| jdstrand | zyga: we absolutely do *not* want a network namespace. look at all the problems that the mount namespace has caused. we want fine-grained network filtering in the lsm. the netowkr namespace would tremendously complicate how the snap integrates into the system and how snaps interact | 12:07 |
| zyga | jdstrand: maybe, maybe not, I'm not convinced | 12:08 |
| zyga | jdstrand: I think vast majority of snaps would work inside a network namespace, you could opt-into a real-network-namespace interface to be free of that | 12:08 |
| jdstrand | zyga: with that we can use seccmark. ie, we tag each packet with an per-snap seccmark, and then firewalling can be used with that | 12:08 |
| zyga | jdstrand: a network namespace + firewall is a portable way to handle this | 12:08 |
| * Chipaca ponders lunch | 12:08 | |
| jdstrand | zyga: remember, namespaces are for separation, not for integration into the system. selinux can do secmark too, so that shouldn't be an issue | 12:09 |
| zyga | jdstrand: do you have any pointers to documentation about seccmark, I'm not faimilar with it | 12:09 |
| zyga | jdstrand: oh and while you are here; a more relevant and pressing need | 12:10 |
| zyga | jdstrand: is there _any_ way to replace the seccomp profile of a process? | 12:10 |
| jdstrand | morphis, zyga: can you point me to the bug. I feel like I already discussed this and options but am having trouble finding that conversation | 12:10 |
| zyga | jdstrand: (replace, not augment) | 12:10 |
| zyga | jdstrand: ha, it is in fact the same problem | 12:10 |
| zyga | sure | 12:10 |
| * zyga gets the link | 12:10 | |
| morphis | jdstrand: https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658 , I didn't added the LP bugs yet, let me do that now | 12:10 |
| zyga | https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658/2 | 12:10 |
| zyga | jdstrand: the instant idea was to give snapctl a dedicated apparmor profile (like snap-confine) but then we'd still be stuck on the seccomp profile | 12:10 |
| jdstrand | zyga, morphis: re separate profile for snapctl-- that won't work in the way you might be thinking-- there is no such thing as a profile transition in seccomp. you can do that if you cross IPC though | 12:11 |
| morphis | jdstrand: https://bugs.launchpad.net/snappy/+bug/1644573 | 12:11 |
| mup | Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573> | 12:11 |
| zyga | jdstrand: yep, that's what we realized earlier today :( | 12:11 |
| zyga | jdstrand: I just hoped I was wrong and there's (some) way | 12:11 |
| morphis | jdstrand, zyga: also added in https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658/3?u=morphis | 12:12 |
| zyga | thanks! | 12:12 |
| jdstrand | morphis: as for kernel changes not helping-- we are going to need to be a little more agile about that sort of thing I'm afraid (not that there isn't something else we can do here), but we used to have a long list of patches that a certified snappy kernel needed. anyway, that's a digression | 12:14 |
| jdstrand | zyga: we can eperm, but it is either kill or EPERM now and if you EPERM you lose logging for everything | 12:14 |
| zyga | jdstrand: the point is not that (that's all fine) but if we can detect such kernel in the first place so that we can make a compatible profile | 12:14 |
| morphis | jdstrand: I agree, however I am not sure how fast we could get such a change into the official kernel for already released versions of Fedora, openSUSE, ... | 12:14 |
| zyga | jdstrand: right, that's my understanding as well (eperm and logging) | 12:14 |
| jdstrand | zyga: EPERM+audit will be detectable from userspace | 12:15 |
| morphis | jdstrand: actually for Ubuntu this isn't a problem, this is one for all !Ubuntu systems where we have no apparmor but seccomp | 12:15 |
| jdstrand | zyga: I can't say strongly enough that I think a network namespace is a mistake | 12:15 |
| jdstrand | zyga: there is no way to replace a seccomp profile or to transition out of it | 12:16 |
| niemeyer | Mornings! | 12:16 |
| jdstrand | morphis: I read that forum post, but there is a bug and other conversation on it | 12:16 |
| zyga | jdstrand: note that I'm not doing anything towards that, it was just (any) idea that I had left | 12:16 |
| * jdstrand is still getting through your responses to my responses to backscroll (might've waited for me to come online :P) | 12:16 | |
| zyga | jdstrand: hehe | 12:17 |
| morphis | jdstrand: :-) | 12:17 |
| zyga | jdstrand: do you think we could _safely_ allow bind-on-localhost to in the default template? | 12:17 |
| zyga | jdstrand: just bind, I don't think we need connect | 12:17 |
| zyga | jdstrand: or even listen perhaps /me looks | 12:18 |
| jdstrand | zyga: bind-on-localhost: that isn't a thing. it is bind or no bind. we can't derefence the struct to see it is for localhost | 12:18 |
| jdstrand | ok | 12:18 |
| jdstrand | I'm caught up | 12:19 |
| zyga | jdstrand: not even listen! | 12:19 |
| jdstrand | let me read everything and think a moment | 12:19 |
| zyga | jdstrand: ah, then we've got no other options that I can think of | 12:19 |
| zyga | it's a real shame seccomp cannot do this and apparmor cannot do this at the same time :/ | 12:19 |
| jdstrand | there is an option. just add the bind on systems without apparmor | 12:19 |
| * Chipaca really lunch now | 12:19 | |
| zyga | Chipaca: ejoy | 12:19 |
| zyga | niemeyer: hey! :) | 12:19 |
| jdstrand | zyga: well, finegrained network mediation could come after the upstreaming-- you'd have to talk to ratliff and tyhicks about prioritizing that, but that doesn't solve anything here cause a) you said we can't patch kernels and b) this is for systems with only seccomp and not apparmor | 12:21 |
| morphis | jdstrand: would be an option | 12:21 |
| jdstrand | I guess morphis was the one who said we can't patch kernels | 12:21 |
| jdstrand | ok, let me read | 12:22 |
| morphis | jdstrand: we maybe can but I guess this will be a longer process to get such a patch into Fedora, openSUSE etc. | 12:22 |
| zyga | jdstrand: we cannot patch kernels on existing systems, consistently and predictably so we need anything else as plan B | 12:23 |
| jdstrand | morphis: note that an early implementation decision was that the lsm and seccomp would work together and that we wouldn't pick one or the other, since both are needed for proper confinement | 12:23 |
| morphis | but given that we run snaps "unconfined" on these distros anyway we could just allow bind | 12:23 |
| morphis | jdstrand: interesting, I was told we can use seccomp independently | 12:24 |
| ogra_ | just default to snap install canonical-livepatch alongside snapd ... | 12:24 |
| * ogra_ grins | 12:24 | |
| jdstrand | zyga: I understand the problem but think about it-- we can only ever weaken the sandbox because we reach out farther and farther to systems that are running kernels that don't have features, may have bugs and at the same time reaching back in time to 3.4 | 12:25 |
| morphis | jdstrand: if that is true we should maybe make seccomp requiring apparmor being enabled inside snap-confine | 12:25 |
| jdstrand | I mean, everything was designed with a particular set of requirements. how is one supposed to fix bugs if we are now trying to support unupdateable ancient kernels? why are we even upstreaming anything-- it won't but something everyone can use so no one can use it | 12:26 |
| jdstrand | (that is not meant to be answered-- of course we need to upstream-- but it illustrates the point) | 12:27 |
| * jdstrand really reads now | 12:27 | |
| * zyga agrees with jdstrand | 12:28 | |
| zyga | perhaps just disabling seccomp if incompatible LSM is found is the way to go? | 12:28 |
| morphis | zyga: I would say when --disable-apparmor disable seccomp too | 12:29 |
| jdstrand | oh, and we can't patch go either :) | 12:29 |
| zyga | morphis: we can just emit a no-op profile in snapd | 12:29 |
| morphis | jdstrand: yeah, however latest go is a lot better and doesn't seem to have this problem anymore :-) | 12:29 |
| morphis | zyga: why not disable it completely for snap-confine? | 12:29 |
| jdstrand | morphis: iirc, my comments in bug #1674193 re the /run/snapd.socket are fixed now, right? ie, snapctl now chooses the correct socket | 12:30 |
| mup | Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193> | 12:30 |
| morphis | jdstrand: AFAIK, yes | 12:30 |
| jdstrand | but there is no lsm on these other distros, so they can just talk to that socket | 12:30 |
| zyga | morphis: because it's a compile time decision | 12:31 |
| morphis | jdstrand: right, but they are blocked by seccomp | 12:31 |
| mvo | fgimenez, pedronis, nessita: I see a new error in our tests: "error: Please buy test-snapd-control-consumer before installing it." - did anything change to this snap recently? | 12:31 |
| * jdstrand would have to remind himself of the code on those | 12:31 | |
| jdstrand | morphis: not if they plugs network-bind which is autoconnected | 12:31 |
| pedronis | mvo: that the spurious error we would get on a 401 | 12:31 |
| mvo | pedronis: aha, that explains it | 12:32 |
| pedronis | mvo: is this a classic test or a core test | 12:32 |
| mvo | pedronis: this happend on classic | 12:32 |
| zyga | morphis: ohhh, that thing you found earlier is a compile time choice :(((( | 12:33 |
| zyga | morphis: we need to change that too | 12:33 |
| pedronis | mvo: bit unexpected | 12:33 |
| Chipaca | mvo: are you running with SNAPD_DEBUG_HTTP? | 12:34 |
| Chipaca | mvo: (do you get that every time?) | 12:34 |
| mvo | Chipaca: I think it was just a one off | 12:34 |
| mvo | Chipaca: sorry for the noise | 12:35 |
| Chipaca | mvo: if you were running with http debug on, i'd like to see the store repsonse | 12:35 |
| Chipaca | or its response | 12:35 |
| Chipaca | either will do | 12:35 |
| * mvo nods | 12:36 | |
| Chipaca | mvo: if this was in spread, it does have debug on :-) | 12:36 |
| Chipaca | SNAPD_DEBUG_HTTP=7 even | 12:36 |
| mvo | Chipaca: it did happen there, but in snap download which has no debug enabled apparently (c.f. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170517_120423_15d84@/log.gz) | 12:38 |
| Chipaca | :-( | 12:38 |
| jdstrand | morphis, zyga: let's just accept for the moment that seccomp without lsm is ok for now and assume we can't patch anything but snapd/snap-confine. I see a few options: a) add bind unconditionally everyone, b) add bind conditionally on if apparmor isn't there and seccomp isn't using EPERM and c) adjust snapctl to not make these calls | 12:44 |
| jdstrand | morphis, zyga: I don't like 'a' at all. let's strike that | 12:44 |
| pedronis | it's go runtime that does these so c) is not an option | 12:44 |
| pedronis | afaiu | 12:44 |
| nessita | mvo, as pedronis said, is a misleading error, I thought pete worked on that before he left (maybe not?) | 12:45 |
| pedronis | nessita: no, after discussion it was decided to wait for the store to return better errors | 12:45 |
| jdstrand | pedronis: well, as its implemented. there would need to be investigating. perhaps reaching out to C and that wouldn't happen. out of process helper. fork a C program, etc | 12:45 |
| jdstrand | however, 'c' is complicated | 12:45 |
| jdstrand | so I suggest 'b'. zyga worked on code to conditionally add policy for snap try for ecryptfs, this is very similar to that | 12:46 |
| jdstrand | zyga, morphis: ^ | 12:46 |
| Chipaca | + snap install --dangerous basic-hooks_1.0_all.snap | 12:47 |
| Chipaca | error: cannot read snap file: info failed to parse: yaml: control characters | 12:47 |
| Chipaca | are not allowed | 12:47 |
| Chipaca | from https://api.travis-ci.org/jobs/233194012/log.txt | 12:47 |
| pedronis | Chipaca: weirdness++ | 12:48 |
| pedronis | and flakiness on top | 12:48 |
| Chipaca | niemeyer: fgimenez: any chance we can fsck the images? | 12:48 |
| mup | PR snapd#3341 closed: Release 2.26.3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3341> | 12:48 |
| jdstrand | zyga, morphis: that's totally doable this cycle. it's simple to understand and shouldn't be hard to implement. please request me as a reviewer | 12:48 |
| nessita | pedronis, but an inmediate fix can be done which will help users considerably: on 401 from the download url, if the local metadata says there is no price set, just return a different error and do not mention buy or price | 12:48 |
| pedronis | nessita: that was not my decision | 12:48 |
| niemeyer | Chipaca: Do we have any issues there? | 12:49 |
| Chipaca | niemeyer: ^^^ | 12:49 |
| pedronis | nessita: it's complicated because we don't the price information at that point | 12:49 |
| Chipaca | niemeyer: what i pasted | 12:49 |
| pedronis | in the code | 12:49 |
| niemeyer | Chipaca: Sorry, a bit slow today.. I'm failing to make the correlation | 12:49 |
| zyga | jdstrand: reading | 12:50 |
| pedronis | Chipaca: we build the snaps, no? | 12:50 |
| Chipaca | niemeyer: how did 'control characters' get to the yaml? | 12:50 |
| pedronis | so it would flaky virtual disk not the image | 12:50 |
| pedronis | that yaml comes from the checkout | 12:50 |
| pedronis | same | 12:50 |
| niemeyer | pedronis: Ah, but I think our snap builder doesn't read the files does it? | 12:50 |
| niemeyer | Chipaca: That said, wouldn't that fail every single time? | 12:51 |
| niemeyer | If it was the image | 12:51 |
| zyga | jdstrand: I think b and c are possible and welcome; c is "free" on new golang stack but b feels more realistic quickly | 12:51 |
| Chipaca | niemeyer: probably? I don't know | 12:51 |
| fgimenez | Chipaca: you can always check an instance of the images with "spread -reuse -shell <system>" | 12:51 |
| zyga | jdstrand: I agree on 'b' | 12:51 |
| fgimenez | even without -reuse | 12:51 |
| mup | PR snapcraft#1319 closed: kernel plugin: config check: remove DMIID option <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1319> | 12:51 |
| niemeyer | Chipaca: If it was a broken image, how would it work sometimeS? | 12:51 |
| ogra_ | must be a moody image :) | 12:52 |
| Chipaca | niemeyer: I don't have a hypothesis that could give this behaviour, so I was looking to eliminate things that could introduce failures | 12:53 |
| Chipaca | s/give/explain/ | 12:53 |
| niemeyer | Ack | 12:53 |
| zyga | ogra_: probability, image has a quantum state that when measured on full moon, crashes ;) | 12:53 |
| ogra_ | haha, yeah | 12:53 |
| morphis | zyga: https://github.com/snapcore/snapd/pull/3344 doesn't work, as it happens before the call to sc_populate_mount_ns which mounts the /var/lib/snapd dir from the host into the core snap | 12:54 |
| mup | PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344> | 12:54 |
| mup | PR snapd#3344 opened: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344> | 12:55 |
| morphis | so that doesn't seem to be the real problem as this only seems to remount /snap onto /snap again | 12:55 |
| morphis | let me read through that code a bit more | 12:56 |
| zyga | morphis: no | 12:56 |
| zyga | morphis: 2nd line is wrong | 12:56 |
| zyga | sc_do_mount(SNAP_MOUNT_DIR, "/snap", "none", MS_BIND | MS_REC, | 12:56 |
| zyga | let that just do SNAP_MOUNT_DIR *again* | 12:56 |
| zyga | it will work :) | 12:56 |
| * zyga afk | 12:56 | |
| zyga | morphis: and please write a nicer commit message :D | 12:56 |
| jdstrand | morphis, zyga: I'm commenting in the form | 12:57 |
| jdstrand | forum | 12:57 |
| morphis | zyga: ah I see, this is before the pivot_root call | 12:58 |
| morphis | jdstrand: thanks! | 12:58 |
| abeato | zyga, Chipaca https://github.com/snapcore/snapd/pull/3324 ready again, thanks for the thorough review! | 13:23 |
| mup | PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324> | 13:23 |
| Chipaca | abeato: yep! i'd be on it if i weren't in a meeting :-) | 13:25 |
| abeato | Chipaca, :) | 13:26 |
| Chipaca | mvo: in this case i think it was chrome and not pulseaudio funnily enough (or HO itself); pulseaudio was seeing my mics fine | 13:28 |
| zyga | abeato: thanks, I'll have a look in a moment, just need to refill my drink, it's super hot in spain today | 13:28 |
| Chipaca | abeato: the bit i got to look at so far looks much cleaner :-) | 13:29 |
| morphis | abeato: is that PR still WIP? | 13:31 |
| abeato | morphis, not really, I will remove that | 13:34 |
| morphis | ok | 13:34 |
| mup | PR snapd#3339 closed: tests/lib/snaps: add a test store snap with a passthrough configure hook <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3339> | 13:42 |
| mvo | abeato: I added some feedback too, nice job I have to say :) | 13:45 |
| zyga | abeato: done | 13:46 |
| abeato | mvo, zyga thanks! | 13:46 |
| morphis | zyga: ok, it seems to work now, but running into other problems on restore now | 13:52 |
| ogra_ | mvo, did you notice that the systemd in the image PPA is actually overridden by the archive now ? the one stuck in -proposed finally made it through ... do you think we can drop the systemd package from the PPA now ? | 13:53 |
| ogra_ | (seems we are building with the archive version since a while already ... with no bugs or complaints) | 13:53 |
| mvo | ogra_: yeah, this looks pretty good now, this can go now. very happy that this is finally fixed | 13:55 |
| ogra_ | \o/ | 13:55 |
| * ogra_ removes the package | 13:55 | |
| ogra_ | mvo, resolvconf too i suppose ? | 13:56 |
| mvo | yes | 13:57 |
| ogra_ | done | 13:57 |
| mvo | ta | 13:58 |
| morphis | Pharaoh_Atem: can you include one minor fix in the 2.26.* package updates for fedora? just add --disable-seccomp for the snap-confine build | 13:58 |
| mvo | morphis: \o/& | 13:59 |
| morphis | Pharaoh_Atem: but wait a second, just reading jdstrand's reply | 14:02 |
| Pharaoh_Atem | why is this broken again? | 14:02 |
| morphis | jdstrand: didn't you say before that the seccomp confinement shouldn't be used without an LSM? | 14:03 |
| morphis | Pharaoh_Atem: https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658/ | 14:03 |
| morphis | Pharaoh_Atem: it was never really fixed, just for the core snap which now plugs network-bind | 14:04 |
| morphis | jdstrand: " 'd' should not be used because it weakens the sandbox on systems where AppArmor is disabled (though the seccomp sandbox alone should not be considered strong confinement)" seems to contradict what you said before or do I miss something? | 14:04 |
| Pharaoh_Atem | if it's fixed in Go 1.8, I can just conditionally disable it | 14:07 |
| jdstrand | morphis: maybe its the double negative. I'm saying that on systems without apparmor, forcing disabling seccomp is undesirable since it would mean no seccomp filtering on those systems | 14:08 |
| jdstrand | it's | 14:08 |
| morphis | jdstrand: right, and I agree that is not really what we want but trying to see what this whole thing is actually meant to be | 14:08 |
| jdstrand | morphis: in the irc scrollback, I did say that using them separately wasn't part of the original design, yes | 14:09 |
| morphis | jdstrand: so with that said, !apparmor + seccomp is sth we want to support? | 14:10 |
| jdstrand | morphis: but we are down that path now and it is easy enough to not disable seccomp by doing 'b' | 14:10 |
| morphis | jdstrand: ok, got it | 14:10 |
| jdstrand | morphis: well 'support'? I mean, we are already doing it. let's see how long we can continue with it. it isn't strong confinement, but it is something | 14:10 |
| Pharaoh_Atem | which is precisely why I have it on | 14:11 |
| Pharaoh_Atem | it's better than zero | 14:11 |
| morphis | jdstrand: we could strongly say we don't want to support it | 14:11 |
| Pharaoh_Atem | morphis: no | 14:11 |
| morphis | Pharaoh_Atem: it's two sided, if it is unsupported you may run into problems upstream don't care about | 14:11 |
| Pharaoh_Atem | but upstream is supposed to care about it | 14:11 |
| morphis | if it doesn't fit into the confinement roadmap than we may better disable it | 14:11 |
| morphis | Pharaoh_Atem: that is what I am trying to make clear | 14:12 |
| Pharaoh_Atem | then by that logic, I should just remove fedora snapd because you guys can't support it properly :( | 14:12 |
| Pharaoh_Atem | I'd really like for support to not be regressive in nature | 14:12 |
| Pharaoh_Atem | and frankly, even openSUSE can't have apparmor+seccomp yet | 14:12 |
| Pharaoh_Atem | we'll have it there this fall, but no earlier | 14:13 |
| Pharaoh_Atem | I'm pinning my hopes on the patches being merged before Factory is branched for SLE 15 | 14:13 |
| morphis | Pharaoh_Atem: no you shouldn't because this doesn't mean nobody cares | 14:14 |
| morphis | I am just trying to get a better understand of how things are supposed to work | 14:14 |
| morphis | but I think option b as jdstrand described it is what we will do | 14:14 |
| Chipaca | fgimenez: mvo: CPI is hitting multi-second response times 3x more than usual, 2x more than usual 5+ seconds responses. This might be impacting at least some of the flakiness we're seeing in tests. | 14:19 |
| jdstrand | morphis: this corner case is the only thing that is like this that I'm aware of. that doesn't mean that others won't come up and distros always --disable-seccomp if they choose. I'd like to see how it goes for a while allowing seccomp without LSM before saying we can't support it | 14:20 |
| jdstrand | always can* | 14:20 |
| morphis | jdstrand: ok | 14:20 |
| morphis | Pharaoh_Atem, jdstrand: https://github.com/morphis/snapd/commit/a604e6e94cca5251a1a1ae31907832e023b38fa7 | 14:20 |
| morphis | does that look ok for you guys? (untested yet) | 14:20 |
| jdstrand | morphis: I like the comment (thanks) up until NOTE | 14:21 |
| Pharaoh_Atem | looks okay to me... | 14:21 |
| Pharaoh_Atem | though I'm not sure why you couldn't just apply it in general? | 14:21 |
| jdstrand | morphis: how I see this is that you determine if apparmor is available, then if it isn't, tack this snippet on | 14:22 |
| fgimenez | thanks Chipaca, good to know, i'm already seeing the effects in the core validation http://paste.ubuntu.com/24592937/ | 14:22 |
| jdstrand | morphis: ie, runtime, not compile time | 14:22 |
| morphis | jdstrand: it does, it's just meant a distro-patch for the mean time | 14:22 |
| jdstrand | morphis: ok, I only see that commit, not the full PR. ping me when you want the PR reviewed | 14:22 |
| jdstrand | as that is written though, it clearly is just in the default template rather than appended to the default template based on a runtime check | 14:23 |
| jdstrand | pseudo code: | 14:23 |
| morphis | jdstrand: right, that is what I will work on next for 2.27 | 14:23 |
| jdstrand | template = what is there today | 14:23 |
| jdstrand | if apparmor not available: | 14:24 |
| jdstrand | append bind and its comment | 14:24 |
| morphis | jdstrand: just want to land this patch into fedora/suse now | 14:24 |
| jdstrand | ok | 14:24 |
| jdstrand | then yes, that is fine as a distro patch | 14:24 |
| morphis | jdstrand: thanks | 14:24 |
| morphis | Pharaoh_Atem: can you include that tiny patch in the next fedora pkg upload you're doing? | 14:34 |
| Pharaoh_Atem | yes | 14:35 |
| mvo | zyga: silly question, I'm looking at the dbus branch currently and there is this issue that we want to only allow a single slot with a given dbus path in the entire system, i.e. no two snaps should be able to provide com.example.MyDbus. whats the best way to do this from inside e.g. dbusInterface.SanitizeSlot? | 14:36 |
| zyga | mvo: aha, interesting problem | 14:38 |
| zyga | mvo: I think that you should allow each interface to contribute whatever it wants | 14:38 |
| zyga | mvo: but the backend can detect conflicts | 14:38 |
| zyga | mvo: the problem is that at that time it is too late | 14:38 |
| zyga | mvo: so this seems to hint that we should allow backends to veto interface connections | 14:39 |
| zyga | mvo: then a backend could trivially do the same check (where it matters, it could be a no-op) | 14:39 |
| zyga | mvo: and given this the interface may produce a useful error message | 14:39 |
| zyga | mvo: func (i *iface) ConnectionConsistency(repo *Repository, plug *Plug, slot *Slot) error | 14:40 |
| zyga | mvo: (+ interface attributes perhaps) | 14:40 |
| zyga | mvo: this should IMO happen before we even go ask hooks | 14:41 |
| zyga | mvo: perhaps both before/after, that is less clear | 14:41 |
| Pharaoh_Atem | morphis: this list of snapd paths, what is this relative to? | 14:41 |
| morphis | Pharaoh_Atem: /var/lib/snapd | 14:41 |
| zyga | mvo: the question still remains, how exactly we'd veto that; is it the backend that does the veto or is it in each interface's responsibility | 14:42 |
| zyga | mvo: what do you think? | 14:43 |
| zyga | mvo: btw, this is already present in the systemd backend | 14:43 |
| zyga | mvo: but we never had to run into the issue | 14:43 |
| zyga | mvo: there the backend can simply fail | 14:43 |
| zyga | mvo: but nothing would handle that nicely later | 14:43 |
| zyga | mvo: maybe try this: | 14:43 |
| zyga | mvo: just start with a conflict in the backend | 14:43 |
| zyga | mvo: and see what happens | 14:43 |
| zyga | mvo: maybe it's "nice" enough | 14:43 |
| Pharaoh_Atem | morphis: what is hostfs? | 14:43 |
| zyga | Pharaoh_Atem: it's the place where classic distribution filesystem is visible | 14:44 |
| zyga | Pharaoh_Atem: I'd call it "classicfs" but that'd be just mean on the word classic | 14:44 |
| mvo | zyga: thanks, I check it out | 14:45 |
| mup | PR snapcraft#1321 opened: tests: remove the reusable parts tour test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1321> | 14:45 |
| zyga | mvo: the hook problem is going to spin this around | 14:47 |
| zyga | mvo: as it means we fail when we told apps that we didn't | 14:48 |
| zyga | mvo: but before hooks it is okay | 14:48 |
| zyga | mvo: to fail in the backend | 14:48 |
| mvo | zyga: ok, looking at this next then | 14:49 |
| abeato | mvo, zyga thanks for the quick reviews, https://github.com/snapcore/snapd/pull/3324 ready again for you ;) | 14:52 |
| mup | PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324> | 14:52 |
| Pharaoh_Atem | what does /var/lib/snapd/device do? | 14:52 |
| zyga | Pharaoh_Atem: I think it is where device-specific things go | 14:54 |
| * zyga looks | 14:54 | |
| zyga | Pharaoh_Atem: things like device key and such | 14:54 |
| * zyga takes a break | 14:56 | |
| Pharaoh_Atem | morphis: is /var/lib/snapd/hostfs a directory or a symlink? | 14:57 |
| morphis | Pharaoh_Atem: a directory | 14:57 |
| morphis | the host / gets bind mounted there | 14:57 |
| Pharaoh_Atem | morphis: does the bind mount go away when snapd is stopped? | 15:00 |
| morphis | Pharaoh_Atem: its not in the root mount namespace, it will get bind mounted in the mount namespace every snap gets | 15:01 |
| morphis | Pharaoh_Atem: so, if I am not wrong, the one one the hostfs gets never used | 15:01 |
| morphis | only one from the core snap | 15:01 |
| Pharaoh_Atem | okay then | 15:02 |
| morphis | Pharaoh_Atem: I would guess we don't even have to create it if we don't use the rpm to include it in a core snap later on | 15:02 |
| Pharaoh_Atem | morphis: https://paste.fedoraproject.org/paste/Nl-XU2nzkPUlVLHnnGFw515M1UNdIGYhyRLivL9gydE= | 15:03 |
| Pharaoh_Atem | looks good? | 15:03 |
| morphis | let me check | 15:03 |
| morphis | Pharaoh_Atem: what is with the snap and snaps directories | 15:04 |
| morphis | they will have content too | 15:04 |
| morphis | I didn't saw them cleaned | 15:04 |
| Pharaoh_Atem | those are getting erased already in snap-mgmt | 15:04 |
| Pharaoh_Atem | hmm | 15:04 |
| morphis | Pharaoh_Atem: can you give this a quick try? | 15:04 |
| abeato | ogra_, where are the /boot/* created? Where should I do the change so we get /boot/androidboot ? | 15:09 |
| Pharaoh_Atem | hmm, interesting | 15:09 |
| abeato | (inside core snap) | 15:09 |
| ogra_ | abeato, one sec | 15:10 |
| abeato | ok | 15:10 |
| Pharaoh_Atem | this is a bit tricky because /var/lib/snapd/snap and /var/lib/snapd/snap/bin exist | 15:10 |
| pedronis | fgimenez: niemeyer: anothere prepare timeout: https://travis-ci.org/snapcore/snapd/builds/233253922 | 15:10 |
| Pharaoh_Atem | and I want to erase them independently :/ | 15:10 |
| niemeyer | fgimenez: Can we please bump the timing? | 15:10 |
| ogra_ | abeato, add it there https://github.com/snapcore/core/blob/master/live-build/hooks/16-ensure-bootloaders.chroot ... but you also want the initrd to learnto handle it ... that is here https://github.com/snapcore/core-build/blob/master/initramfs/scripts/ubuntu-core-rootfs#L313 | 15:12 |
| niemeyer | Lunch, back shortly | 15:12 |
| fgimenez | niemeyer: sure i'll prepare a branch, given that we are folding the output in travis we could also remove the "quiet" call here https://travis-ci.org/snapcore/snapd/builds/233253922#L3999 to see where is it hanging | 15:12 |
| abeato | ogra_, yes, yes, I know :) Thanks! | 15:13 |
| ogra_ | :) | 15:13 |
| ogra_ | sorry for pointing to it every time :) | 15:13 |
| abeato | better that than not pointing at it at all :D | 15:14 |
| Chipaca | abeato: dunno if you saw you've got failing static tests | 15:18 |
| Chipaca | abeato: [...]/partition/androidbootenv/androidbootenv_test.go:42:2: ineffectual assignment to env | 15:18 |
| abeato | Chipaca, hmm, I see, thanks for pointing out... | 15:19 |
| zyga | mvo: can I trigger a PPA build to get master into edge (eventually?) or will that still interfere with the release? | 15:23 |
| zyga | morphis: can you correct https://github.com/snapcore/snapd/pull/3344/files | 15:23 |
| mup | PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344> | 15:23 |
| morphis | zyga: I am testing that right now | 15:24 |
| zyga | morphis: perfect! | 15:24 |
| Pharaoh_Atem | morphis: https://paste.fedoraproject.org/paste/SaaKKnO-XBb-0cJvsnAc4V5M1UNdIGYhyRLivL9gydE= | 15:24 |
| mup | PR core#44 opened: Add hook for androidboot bootloader <Created by alfonsosanchezbeato> <https://github.com/snapcore/core/pull/44> | 15:24 |
| abeato | mvo, ogra_ ^^ | 15:24 |
| morphis | Pharaoh_Atem: looks good, does it work? | 15:25 |
| Pharaoh_Atem | I'm about to find out | 15:25 |
| mup | PR snapd#3345 opened: tests: bump kill-timeout and remove quiet call on build <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3345> | 15:25 |
| ogra_ | abeato, approved ... btw, can i remove the writable-path change ? | 15:25 |
| ogra_ | (since you now mount a writable partition that shouldnt be needed ) | 15:26 |
| abeato | ogra_, sure, let me close the PR | 15:26 |
| ogra_ | thx | 15:26 |
| Pharaoh_Atem | morphis: running a scratch build now: https://koji.fedoraproject.org/koji/taskinfo?taskID=19597779 | 15:26 |
| fgimenez | niemeyer: pedronis snapd#3345 increases the project's kill-timeout to 20m, also removes "quiet" from the command that is actually timing out | 15:27 |
| mup | PR snapd#3345: tests: bump kill-timeout and remove quiet call on build <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3345> | 15:27 |
| mup | PR core-build#9 closed: Add writable boot for android-boot "bootloader" <Created by alfonsosanchezbeato> <Closed by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/9> | 15:28 |
| Pharaoh_Atem | morphis: is there a new version of the distrolibexecdir patch for 2.26.1? | 15:33 |
| Pharaoh_Atem | it ftbfs with the current one | 15:33 |
| * zyga works in an unusual place | 15:34 | |
| Pharaoh_Atem | zyga: eh? | 15:36 |
| zyga | Pharaoh_Atem: I'm sitting on a beach | 15:37 |
| zyga | ogra_: is this recipe used? https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily-xenial | 15:37 |
| zyga | ogra_: it's ancient and hasn't built since 2016 | 15:37 |
| zyga | ogra_: I want to rebuild snapd to the image ppa | 15:37 |
| ogra_ | zyga, ask the owner _P | 15:37 |
| zyga | ogra_: but I guess it is built from the vendorized repo | 15:38 |
| zyga | ogra_: we're the owners | 15:38 |
| ogra_ | it uses https://code.launchpad.net/~snappy-dev/snappy/trunk-github | 15:38 |
| ogra_ | and the owner seems to be sergio | 15:38 |
| zyga | the url says the owner is snapp-dev | 15:39 |
| ogra_ | zyga, yes, but thats moot ... it was createrd by sergio, no idea for what etc ... ask him | 15:39 |
| morphis | Pharaoh_Atem: there is, just take the current PR | 15:39 |
| ogra_ | zyga, the daily edge build of snapd is handled by elopio iirc | 15:40 |
| morphis | Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3222 | 15:40 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 15:40 |
| zyga | elopio: ^^ | 15:40 |
| zyga | elopio: do you handle the daily snapd -> ppa build? | 15:40 |
| zyga | the build process is so messy | 15:41 |
| ogra_ | zyga, whatever that thing builds is called "ubuntu-snappy" ... "dpkg-source -i -I --before-build ubuntu-snappy-1.7.2+20160204ubuntu1" ... (from the build log of that receipe) | 15:41 |
| Pharaoh_Atem | morphis: new scratch build run: https://koji.fedoraproject.org/koji/taskinfo?taskID=19597955 | 15:42 |
| fgimenez | zyga: we have a spread-cron branch for that, after each merge + green build on master we update snapd-vendor on launchpad and trigger a build https://github.com/snapcore/spread-cron/blob/snapd-vendor-sync/target/tasks/snapd-vendor-sync/task.yaml | 15:43 |
| zyga | fgimenez: can you trigger that manually now | 15:43 |
| fgimenez | zyga: sure 1sec | 15:43 |
| ogra_ | zyga, also https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial ... seems the last build was 2h ago | 15:44 |
| ogra_ | do you need anything newer ? | 15:44 |
| fgimenez | ogra_: zyga yes, no longer daily | 15:44 |
| ogra_ | yep | 15:44 |
| Pharaoh_Atem | morphis: patch does not apply | 15:45 |
| ogra_ | since quite a while already IIRC | 15:45 |
| Pharaoh_Atem | morphis: https://kojipkgs.fedoraproject.org//work/tasks/7958/19597958/build.log | 15:45 |
| zyga | ogra_: hmmm | 15:46 |
| zyga | ogra_: I was under the impression that we only use one ppa during builds, the image ppa | 15:46 |
| ogra_ | zyga, ? | 15:47 |
| zyga | ogra_: I think at this stage we should have a post that describes how this all works | 15:47 |
| zyga | ogra_: I thought we use https://launchpad.net/~snappy-dev/+archive/ubuntu/image | 15:47 |
| ogra_ | zyga, both PPAs are always enabled ... before doing a release a snapd with higher version gets uploaded to the image PPA ... that supersedes edge | 15:48 |
| zyga | aha | 15:48 |
| zyga | ogra_: thank you | 15:48 |
| ogra_ | (you did that plenty of times already ... why do you need it documented now) | 15:48 |
| zyga | ogra_: I never realized this is how it works | 15:48 |
| zyga | ogra_: or I forgot since | 15:48 |
| ogra_ | ah, k :) | 15:48 |
| zyga | ogra_: I think cleaning the ppas will make it more obvious as there will be less moving pieces | 15:48 |
| zyga | (or potentially moving) | 15:49 |
| zyga | ogra_: thanks! | 15:49 |
| zyga | ogra_: I want the core snap with master snapd to play with update-ns | 15:49 |
| ogra_ | ah, right, then the release got in your way i guess | 15:50 |
| zyga | yes | 15:50 |
| zyga | this is why I started the topic of how things are made in the first place | 15:50 |
| mvo | zyga, ogra_: new edge deb is there and I triggered a build so you should have a new snapd edge in ~30min | 15:51 |
| ogra_ | thx! | 15:51 |
| zyga | mvo: thank you sir :) | 15:51 |
| ogra_ | wow | 15:51 |
| ogra_ | if you mess up the oser creation in a kvm image bad things happen | 15:51 |
| ogra_ | *user | 15:51 |
| mvo | but +1 for actually documenting it, its relatively straghtfoward *once* used to it | 15:51 |
| * ogra_ shakes fist at shadow | 15:54 | |
| ogra_ | (and higs mvo for fixing it) | 15:54 |
| ogra_ | *hugs even | 15:54 |
| mvo | ogra_: heh, was wondering what about it, hopefully not another security upload | 15:55 |
| ogra_ | insecure crap ... always these CVEs! | 15:55 |
| zyga | mvo: I was thinking about one thing | 15:55 |
| Pharaoh_Atem | morphis: I'm disabling this patch and seeing if I can build without it | 15:55 |
| Pharaoh_Atem | morphis: https://koji.fedoraproject.org/koji/taskinfo?taskID=19598084 | 15:55 |
| Pharaoh_Atem | we don't do unit testing yet anyway... | 15:55 |
| zyga | mvo: about passing some compile time choices as variables from snapd to snap-confine | 15:55 |
| zyga | mvo: this would allow us to enable reexec nearly everywhere where we can run unpatched master | 15:55 |
| zyga | mvo: a single file in /var/lib/snapd/ say snap-confine.cfg | 15:56 |
| zyga | mvo: key=value | 15:56 |
| zyga | mvo: we'd pass a handful of things, mostly like force-devmode, snap-mount-dir and maybe something I'm not thinking about yet | 15:56 |
| zyga | mvo: we could make it per security tag to also convey things like --classic without having snap-run care | 15:57 |
| zyga | mvo: and we could finally fix the missing link between snap-run and snapd, snapd simply would write the new .cfg file | 15:57 |
| zyga | mvo: (I recall that we had issues where snap run doesn't know something changed already and we kind of ignored it for now) | 15:58 |
| zyga | mvo: so that snap-run doesn't have to wake anything up | 15:58 |
| mup | PR core#44 closed: Add hook for androidboot bootloader <Created by alfonsosanchezbeato> <Merged by ogra1> <https://github.com/snapcore/core/pull/44> | 15:59 |
| === chihchun is now known as chihchun_afk | ||
| mvo | zyga: yeah, I think we want to close this gap, maybe a forum post to discuss things? | 16:00 |
| mvo | zyga: I will leave for dinner soon | 16:00 |
| zyga | mvo: yes, sounds good, I'll write something onw | 16:02 |
| mvo | ta | 16:05 |
| zyga | mvo: done https://forum.snapcraft.io/t/closing-the-gap-in-snap-confine-snapd-communication/665 | 16:12 |
| zyga | morphis, jdstrand ^ | 16:12 |
| zyga | me has another core snap, again with 2.26.3 | 16:13 |
| zyga | :-( | 16:13 |
| * zyga doesn't understand how this work | 16:13 | |
| zyga | ks | 16:13 |
| zyga | ogra_: what is snappy devices ppa? https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-devices | 16:15 |
| * ogra_ highly dounbts zyga's sense for "better" | 16:15 | |
| zyga | some things are 2017is | 16:15 |
| zyga | ogra_: my sense for better is doing very good ;-) | 16:15 |
| ogra_ | zyga, thats for the signed customer kernels for secureboot | 16:15 |
| zyga | ogra_: aah | 16:15 |
| ogra_ | ignore it :) | 16:16 |
| zyga | ogra_: can I document it? | 16:16 |
| mvo | zyga: meh, the edge ppa still has 2.26.2 not .3 | 16:16 |
| zyga | mvo: on the upside, my modem needs to download only deltas | 16:16 |
| zyga | ogra_: I edited the description on https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-devices | 16:17 |
| ogra_ | zyga, looks fine | 16:17 |
| mup | PR snapd#3345 closed: tests: bump kill-timeout and remove quiet call on build <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3345> | 16:17 |
| fgimenez | mvo: we can trigger an execution of spread-cron's sync by pushing to snapcore/spread-cron in the snapd-vendor-sync branch (this is done automatically after detecting a new merge + green build on snapcore/snapd's master) | 16:20 |
| fgimenez | probably the flakiness of the tests made that this wasn't executed for a while (the "+ green build" part wasn't happenning) | 16:21 |
| ogra_ | mvo, https://forum.snapcraft.io/t/bug-running-mir-kiosk-apps/657 might be a release blocker ... | 16:21 |
| zyga | fgimenez: aha | 16:21 |
| zyga | ogra_: yes, I was thinking about it | 16:22 |
| zyga | it stopped working in beta because beta was updated | 16:22 |
| ogra_ | mvo, seems edge and beta are broken ... | 16:22 |
| zyga | and it smells like netlink | 16:22 |
| ogra_ | we should really have a log message for the netlink stuff :( | 16:22 |
| ogra_ | not sure how to strace the kiosk apps to get valuable info | 16:23 |
| zyga | I think we do | 16:23 |
| zyga | it's a seccomp kill | 16:23 |
| zyga | HUZZAH and SIGKILL | 16:23 |
| ogra_ | well, we dont get it in the logs | 16:23 |
| zyga | then it's not occuring | 16:23 |
| fgimenez | zyga: mvo if you need it i can push a commit to trigger the build, let me know | 16:23 |
| ogra_ | http://paste.ubuntu.com/24592960/ | 16:23 |
| ogra_ | the issue starts at line 164 | 16:24 |
| zyga | fgimenez: if you can, please | 16:24 |
| ogra_ | which is a simple dlopen that fails for whastever reason | 16:24 |
| zyga | and we really need to fix master == edge && beta == whatever mvo promoted distinction | 16:24 |
| * zyga looks | 16:24 | |
| zyga | well | 16:25 |
| zyga | no details why | 16:25 |
| zyga | useless error :/ | 16:25 |
| robinhood2017 | Hi, I'm just getting started with developing snap packages. I attempted to push my Hello World app (by entering 'snapcraft push hello-[username removed]_2.10_amd64.snap --release=candidate'), but I get the error message saying "The store was unable to accept this snap: You do not have access to modify this package." | 16:25 |
| zyga | "I cannot do that Dave" | 16:25 |
| ogra_ | zyga, there are snapctl complaints above though | 16:25 |
| jdstrand | snap.mir-kiosk-apps.mir-kiosk-app-daemon.service: Main process exited, code=exited, status=1/FAILURE | 16:25 |
| jdstrand | that is not a KILL | 16:25 |
| ogra_ | zyga, ipv6 related it seems | 16:25 |
| zyga | robinhood2017: did you snapcraft register that name? | 16:25 |
| * jdstrand notes that mir interface was updated for netlink | 16:25 | |
| robinhood2017 | Yes, I did "snapcraft register hello-robinhood2017" beforehand. | 16:26 |
| zyga | ogra_: the denials are harmless | 16:26 |
| zyga | (that's apparmor) | 16:26 |
| ogra_ | jdstrand, well, check the paste above ... line 148-153 | 16:26 |
| zyga | jdstrand: aha, still with no seccomp I think my netlink idea was wrong | 16:26 |
| ogra_ | zyga, harmless ? ... ok | 16:27 |
| zyga | ogra_: that's snapctl, harmless | 16:27 |
| ogra_ | ok | 16:27 |
| ogra_ | well, then it boils down to dlopen again | 16:27 |
| jdstrand | ogra_: the 148-153 is the normal snapctl denials and unrelated to this | 16:28 |
| * zyga would love a call to dlerror | 16:28 | |
| ogra_ | jdstrand, yeah, zyga said so | 16:28 |
| ogra_ | http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/base_module.h#L113 | 16:28 |
| ogra_ | thats the code that loads the module | 16:29 |
| jdstrand | it feels to my like something with the mount namespace | 16:29 |
| zyga | yes, missing dleerr | 16:29 |
| zyga | dlerror | 16:29 |
| zyga | jdstrand: perhaps | 16:29 |
| zyga | jdstrand: but what might it be... | 16:29 |
| zyga | very little changes | 16:29 |
| jdstrand | like, mir-libs isn't mounted | 16:29 |
| zyga | jdstrand: mmmmm, | 16:30 |
| zyga | maybe | 16:30 |
| ogra_ | the script has checks for that | 16:30 |
| zyga | ogra_: do you have a reproducer? | 16:30 |
| ogra_ | see line 26 of http://paste.ubuntu.com/24593625/ | 16:30 |
| ogra_ | zyga, install mir-libs, mir-kiosk and mir-kiosk-apps ... thats all i have | 16:31 |
| zyga | ogra_: on x86-64? | 16:31 |
| zyga | ogra_: I don't have a VM handy | 16:31 |
| ogra_ | zyga, mir-kiosk starts fine (you get a black screen with mouse cursor) | 16:31 |
| ogra_ | but the apps cant | 16:31 |
| zyga | ogra_: ok, can you look at /var/lib/snapd/mount | 16:31 |
| zyga | ogra_: and tell me what you see in any of the files there | 16:31 |
| robinhood2017 | So if I've registered the name, and it's still giving me that error, what's next? | 16:31 |
| jdstrand | zyga: I'm not saying it is that. it just kinda feels like it | 16:32 |
| zyga | jdstrand: yes | 16:32 |
| jdstrand | oh | 16:32 |
| ogra_ | ogra@pi3:~$ ls /var/lib/snapd/mount | 16:32 |
| ogra_ | snap.mir-kiosk-apps.fstab snap.mir-kiosk-apps.mir-kiosk-app-daemon.fstab snap.mir-kiosk.hook.configure.fstab | 16:32 |
| ogra_ | snap.mir-kiosk-apps.hook.configure.fstab snap.mir-kiosk.fstab snap.mir-kiosk.mir-kiosk.fstab | 16:32 |
| zyga | jdstrand: would certainly be easiest issue :) | 16:32 |
| zyga | ogra_: look at the one that fails to start please | 16:32 |
| zyga | jdstrand: well | 16:32 |
| zyga | ogra_: well, at the snap that fails to start | 16:32 |
| zyga | I need to stop writing per-app profiles | 16:32 |
| zyga | those are not used anywhere | 16:32 |
| ogra_ | /snap/mir-libs/28/mirlibs0/usr/lib /snap/mir-kiosk-apps/16/mir-libs none bind,ro 0 0 | 16:32 |
| ogra_ | thats the content | 16:32 |
| jdstrand | there was one other thing. I remember when looking at kiosk I could get it to run once, then on subsequent runs I had to remove ~/snap/<snap name> | 16:32 |
| zyga | ogra_: ok, can you now do this: | 16:32 |
| jdstrand | that was unclear | 16:33 |
| zyga | ogra_: sudo nsenter -m/run/snapd/ns/mir-kiosk-apps.mnt | 16:33 |
| jdstrand | the app snap talking to mir, I could run it once, but then after I needed to clear out its user data | 16:33 |
| ogra_ | zyga, done | 16:33 |
| fgimenez | zyga: the job is triggered https://travis-ci.org/snapcore/spread-cron/branches, snapd-vendor-sync branch, now with the latest edge core things are a bit busy :) | 16:33 |
| zyga | ogra_: then look at /snap/mir-kiosk-apps/16/mir-libs | 16:33 |
| ogra_ | i'm groot! | 16:33 |
| ogra_ | err | 16:33 |
| ogra_ | root | 16:33 |
| zyga | fgimenez: thank you! :) | 16:33 |
| zyga | ogra_: groot :D | 16:34 |
| zyga | ogra_: is there anything there? | 16:34 |
| jdstrand | this was with webbrowser-app though, so I was thinking this was something weird in the qt stuff, but maybe it is something with mirlibs | 16:34 |
| ogra_ | zyga, yes, but not sure if it is actualyl the right stuff | 16:34 |
| ogra_ | gimem a bit | 16:34 |
| zyga | ogra_: ls | 16:34 |
| ogra_ | *gimme | 16:34 |
| ogra_ | zyga, 12847523478 files :P | 16:34 |
| zyga | ogra_: !!!!?!??!?! | 16:34 |
| zyga | seriously? | 16:35 |
| ogra_ | root@pi3:/# find /snap/mir-kiosk-apps/16/ -name '*libubuntu_application_api_test*' | 16:35 |
| ogra_ | /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3 | 16:35 |
| ogra_ | /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3.0.0 | 16:35 |
| ogra_ | theer we go | 16:35 |
| zyga | ogra_: ok, now do this | 16:35 |
| ogra_ | oh | 16:36 |
| ogra_ | wait! | 16:36 |
| zyga | ogra_: run cat /proc/self/mountinfo | 16:36 |
| zyga | and tell me if there's a bind mount in that directory | 16:36 |
| zyga | what's going on? | 16:36 |
| ogra_ | root@pi3:/# find /snap/mir-kiosk-apps/16/mir-libs/arm-linux-gnueabihf/ -name '*libubuntu_application_api_test*' | 16:36 |
| ogra_ | root@pi3:/# | 16:36 |
| ogra_ | it is not in the shared dir i think | 16:37 |
| zyga | ogra_: so are snaps broken? | 16:37 |
| zyga | ogra_: or is snapd broken? | 16:37 |
| zyga | ogra_: which version of snapd is this? | 16:37 |
| ogra_ | .3 | 16:37 |
| zyga | aha | 16:37 |
| ogra_ | the most recent one | 16:37 |
| zyga | so pre update-ns | 16:37 |
| zyga | well, not maste R:) | 16:37 |
| ogra_ | but .2 had it too if i can judge by the "broken in edge since a few days" | 16:37 |
| zyga | can you run /usr/lib/snapd/update-ns $SNAP_NAME (from outside the mount namespace) to confirm it says "Not implemented" or something ike that | 16:38 |
| ogra_ | zyga, theory: | 16:38 |
| * zyga listens | 16:38 | |
| ogra_ | mir-kiosk-apps ships the lib in /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf ... but new snapd binmounts mir-libs one level above | 16:38 |
| ogra_ | *bind | 16:39 |
| ogra_ | so the shipped lib from the snap itself is gone | 16:39 |
| ogra_ | and mir-libs doesnt ship it | 16:39 |
| ogra_ | s/gone/hidden/ | 16:39 |
| zyga | ogra_: we just bind mount what the .fstab file says | 16:39 |
| zyga | aha | 16:39 |
| zyga | maybe the snap changed | 16:39 |
| zyga | can you look at /snap/$SNAP_NAME/current/meta/snap.yaml | 16:39 |
| ogra_ | http://paste.ubuntu.com/24593671/ | 16:41 |
| * zyga looks | 16:41 | |
| ogra_ | it seems to lose $SNAP/usr/lib/$ARCH from its library path somehow | 16:41 |
| zyga | ogra_: maybe environment handling broke? | 16:42 |
| ogra_ | and uses $SNAP/mir-libs/$ARCH instead | 16:42 |
| ogra_ | which comes from the interface | 16:42 |
| zyga | ogra_: the snap mount profile looks correct | 16:42 |
| zyga | ogra_: cna you please: cat /proc/self/mountinfo | grep mir-libs | 16:42 |
| zyga | ogra_: (from the mount namespace) | 16:42 |
| zyga | ogra_: I just want to ensure that is mounted | 16:43 |
| zyga | ogra_: and we're not chasing ghosts | 16:43 |
| ogra_ | http://paste.ubuntu.com/24593685/ | 16:43 |
| ogra_ | the last line seems to be the one we use ... | 16:43 |
| zyga | looks OK | 16:43 |
| ogra_ | yeah | 16:44 |
| zyga | yes | 16:44 |
| ogra_ | does the mounting somehow mangle LD_LIBRARY_PATH ? | 16:44 |
| zyga | no | 16:44 |
| zyga | it's not related in any way | 16:44 |
| zyga | ogra_: one more idea | 16:44 |
| zyga | run: snap run --shell snapname.appname | 16:44 |
| zyga | and inspect environment | 16:44 |
| zyga | environment | 16:44 |
| ogra_ | hmm, does that work with daemons ? | 16:44 |
| zyga | ogra_: it does, it runs shell instead | 16:45 |
| zyga | ogra_: using the same confinement/environment | 16:45 |
| ogra_ | k, let me try | 16:45 |
| zyga | ogra_: also look at the launcher wrappers from snapcraft, they used to touch environment | 16:45 |
| ogra_ | http://paste.ubuntu.com/24593692/ | 16:46 |
| morphis | zyga: thanks! | 16:47 |
| ogra_ | no LD_LIBRARY_PATH at all ... | 16:47 |
| * ogra_ checks rteh wrapper | 16:47 | |
| zyga | ogra_: interesting | 16:48 |
| * zyga checks if snapd sets it | 16:48 | |
| ogra_ | http://paste.ubuntu.com/24593700/ | 16:48 |
| ogra_ | wrapper | 16:48 |
| ogra_ | it sets a bunch | 16:48 |
| zyga | ogra_: snapd doesn't set it, it's purely under snap/snapcraft contorl | 16:49 |
| ogra_ | right | 16:49 |
| zyga | ok, that wrapper doesn't run in --shell | 16:49 |
| zyga | no idea | 16:49 |
| * zyga is underground | 16:49 | |
| ogra_ | so how does an app get the one from the namespace mount onto LD_LIBRARY_PATH ? | 16:50 |
| morphis | zyga: can you check https://github.com/snapcore/snapd/pull/3344/files again? | 16:50 |
| mup | PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344> | 16:50 |
| zyga | ogra_: I cannot parse that question | 16:50 |
| ogra_ | something needs to add it there when the mount occurs ... is that snap-confine ? | 16:50 |
| zyga | ogra_: no, it's a hard-coded thing in the wrapper | 16:50 |
| zyga | ogra_: snap-confine doesn't care what is being mounted | 16:50 |
| ogra_ | zyga, when you mount a shared lib space via a content interface nothing adds the new lib space dynamically ? | 16:51 |
| ogra_ | (to the env that is) | 16:51 |
| ogra_ | it somehow needs to end up in LD_LIBRARY_PATH | 16:51 |
| zyga | yes | 16:52 |
| zyga | it is impossible BTW | 16:52 |
| zyga | it has to be predicted by the snap and just added unconditionally | 16:52 |
| ogra_ | well, it used to work ... now it doesnt :) ... | 16:52 |
| morphis | zyga: thanks | 16:52 |
| ogra_ | so something changed | 16:52 |
| ogra_ | and that wasnt the snap | 16:52 |
| ogra_ | (last upload was in feb) | 16:52 |
| morphis | zyga: but don't merge yet, still need to fix my spread tests with that | 16:52 |
| zyga | morphis: it's still wrong :) | 16:53 |
| ogra_ | might be that the snap did it wrong before ... but it definitely used to work | 16:53 |
| zyga | morphis: commented | 16:53 |
| zyga | ogra_: hmm | 16:53 |
| zyga | ogra_: I'll check | 16:53 |
| morphis | zyga: only see "Just one trivial" | 16:54 |
| zyga | morphis: yeah, my connection died, I just commented again | 16:54 |
| morphis | zyga: ah that is what I wanted to ask | 16:54 |
| morphis | zyga: pushed again | 16:55 |
| zyga | done | 16:58 |
| ogra_ | i added an "env" call to the daemon script ... http://paste.ubuntu.com/24593758/ | 16:59 |
| zyga | ogra_: we never set LD_LIBRARY_PATH according to git grep | 16:59 |
| ogra_ | and i see /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf as well as /snap/mir-kiosk-apps/16/mir-libs/arm-linux-gnueabihf | 17:00 |
| ogra_ | in LD_LIBRARY_PATH | 17:00 |
| zyga | so | 17:01 |
| zyga | maybe dlopen works | 17:01 |
| zyga | but without dlerror | 17:01 |
| zyga | ... | 17:01 |
| ogra_ | no, doesnt start | 17:01 |
| zyga | we're just guessing | 17:01 |
| zyga | er, s/dlopen/mount/ | 17:01 |
| ogra_ | zyga, well ask for it to be added :) | 17:03 |
| zyga | ogra_: look at the forum | 17:03 |
| ogra_ | zyga, yeah, got the same as ping in #ubuntu-mir | 17:04 |
| zyga | mvo: don't look | 17:05 |
| ogra_ | now ... why did that get removed | 17:05 |
| zyga | mvo: I forsee 2.23.4 | 17:05 |
| ogra_ | i dont | 17:05 |
| zyga | mvo: er, 2.26.4 | 17:05 |
| zyga | more core builds (with same snapd) | 17:05 |
| ogra_ | right | 17:05 |
| ogra_ | unless libjson was a dep of snapd | 17:05 |
| zyga | maybe | 17:06 |
| zyga | still :/ | 17:06 |
| zyga | we cannot remove anything | 17:06 |
| ogra_ | zyga, we have no influencve on that ... if a package drops a dependency it is gone and we need to retroactively adjust | 17:08 |
| zyga | ogra_: yes, we need better tooling | 17:09 |
| zyga | ogra_: core ABI traces | 17:09 |
| zyga | ogra_: and tests that ensure we don't break ABIs | 17:09 |
| ogra_ | we have manifest files | 17:09 |
| zyga | ogra_: we are missing testss | 17:09 |
| zyga | *tests | 17:09 |
| zyga | we need a 2nd review for https://github.com/snapcore/snapd/pull/3344 | 17:09 |
| mup | PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344> | 17:09 |
| zyga | perhaps Chipaca or jdstrand can have a look, just a few lines of diff | 17:10 |
| ogra_ | zyga, so libjson-c2 was pulled in by rsyslog before ... | 17:10 |
| jdstrand | I reviewed it | 17:13 |
| zyga | aha | 17:14 |
| zyga | ogra_: nice find | 17:14 |
| zyga | ogra_: can you add this to this thread? | 17:14 |
| zyga | thanks jdstrand ! | 17:14 |
| ogra_ | zyga, in the light that we do not guarantee anything bug /bin/sh and libc the fact that the snap depends on something inside core is wrong though ... i'll seed it for now but the snap is broken IMHO | 17:14 |
| ogra_ | s/bug/but/ | 17:14 |
| zyga | ogra_: in principle I agree but I think we need to be pragmatic | 17:15 |
| zyga | Chipaca: I edited https://github.com/snapcore/snapd/pull/3342 - please keep nicer messages as those end up in changelogs and such | 17:16 |
| mup | PR snapd#3342: many: refactor in preparation for 'snap start' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342> | 17:16 |
| zyga | morphis: make fmt | 17:16 |
| morphis | zyga: yeah, saw that | 17:17 |
| morphis | these formattign rules are nasty :-) | 17:17 |
| zyga | morphis: https://imgflip.com/i/1p7lz6 | 17:17 |
| zyga | morphis: I have something nicer brewing towards that end | 17:18 |
| ogra_ | mvo, zyga http://paste.ubuntu.com/24593840/ can i get an ACK for this ? | 17:18 |
| zyga | ogra_: '' | 17:18 |
| morphis | zyga: need a pre-commit hook for that :-) | 17:18 |
| Saviq | hey all, if I've a part (app) that builds against another part (library) in that same snapcraft.yaml, what's a good way of pointing the app at the library? ../parts/library/install/...? | 17:20 |
| nacc | Saviq: you mean you need build-time linkage? | 17:30 |
| Saviq | nacc, yes | 17:30 |
| ogra_ | niemeyer, i assume an opinion of a director/architect might come in handy here https://forum.snapcraft.io/t/bug-running-mir-kiosk-apps/657 | 17:31 |
| ogra_ | if you dont mind | 17:31 |
| Saviq | nacc, something along the lines of PKG_CONFIG_PATH=$SNAPCRAFT_STAGE..., but I just notice PKG_CONFIG_PATH is already set up to include the stage... | 17:31 |
| nacc | Saviq: i would think that would 'just work', put your library in a part, make your app be a part that is 'after' the library part | 17:32 |
| Saviq | yeah I think my "after: " was wrong | 17:32 |
| nacc | Saviq: or at least, it's explicitly mentioned as the uses case for after on https://snapcraft.io/docs/build-snaps/parts :) | 17:32 |
| Saviq | nacc, yeah I think PEBKAC | 17:32 |
| Chipaca | zyga: github uses the first line of the commit message as the title; my commit message was quite a bit longer | 17:32 |
| nacc | Saviq: happens to me all the time :) | 17:32 |
| zyga | Chipaca: well, commit messages have rules :) | 17:33 |
| elfgoh | ogra_, any idea if there are updates on this thread? https://lists.ubuntu.com/archives/snapcraft/2017-April/003774.html | 17:33 |
| zyga | Chipaca: first line is shorter (afair 60-something) then newline, then anything | 17:33 |
| Chipaca | zyga: where are these rules? this is news to me | 17:33 |
| elfgoh | Am trying to figure out where to get started on using GPIOs on a raspberry pi 3 | 17:33 |
| ogra_ | elfgoh, you use the exposed gpio interfaces | 17:33 |
| ogra_ | look at snap interfaces | 17:34 |
| ogra_ | elfgoh, this didnt make it to the stable channel though since the pi3 gadgets can not be upgraded there and the interface comes from the gadget | 17:35 |
| niemeyer | ogra_: Looking | 17:35 |
| ogra_ | thanks | 17:35 |
| elfgoh | ogra_: so which channel is the change in now? I do have the flexibility to not use the stable channel for now | 17:37 |
| ogra_ | elfgoh, should be in all channels but stable | 17:38 |
| elfgoh | And any rough non binding forecast on when the change will be in stable? | 17:38 |
| ogra_ | elfgoh, whenever upgradeable gadgets exist for the pi ... no idea | 17:38 |
| zyga | Chipaca: one sec | 17:38 |
| zyga | Chipaca: https://chris.beams.io/posts/git-commit/ | 17:39 |
| zyga | Chipaca: (quick google) | 17:39 |
| zyga | Chipaca: http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting | 17:39 |
| zyga | Chipaca: there are plenty of things like this | 17:39 |
| ogra_ | afaik it was discussed at the last planning sprint how to handle such upgrades, but i wasnt there and havent seen any docs with details for this issue | 17:39 |
| elfgoh | ogra: who/what decides that? Canonical? | 17:39 |
| zyga | Chipaca: frankly we as a team are utterly terrible at those | 17:40 |
| ogra_ | elfgoh, currently it is a technical limitation and needs to be implemented ... upgrading bootloaders is risky so its not an easy or small task ... it will happen but is a matter of time | 17:40 |
| zyga | ogra_: I would love to know when someone will start working on this | 17:41 |
| morphis | zyga: ok, that PR is good to go, there is a problem with my restore setup | 17:42 |
| zyga | ogra_: are you planning to? | 17:42 |
| zyga | morphis: OK | 17:42 |
| * zyga looks again | 17:42 | |
| elfgoh | ogra: so means the upgrading of bootloaders is in all channels but no stable, due to the risk? | 17:42 |
| ogra_ | zyga, on what ? gadget upgrades ? | 17:42 |
| Chipaca | zyga: most of the log messages i see are "merge pull request #yadda from foo/barbaz" | 17:42 |
| zyga | Chipaca: yes, that too (because rebase policy) | 17:42 |
| zyga | Chipaca: honestly looking at our history is next-to-useless but I really think it's a shame and we could do better | 17:42 |
| zyga | ogra_: yes | 17:42 |
| Chipaca | zyga: i suggest opening a topic and having a discussion about it, then | 17:43 |
| zyga | ogra_: not sure if we have design on that | 17:43 |
| Chipaca | zyga: as it stands I'm not clear what it is exactly that you're wanting us to improve | 17:43 |
| zyga | Chipaca: well | 17:43 |
| zyga | Chipaca: two things | 17:43 |
| zyga | Chipaca: the lines cannot be this long | 17:43 |
| ogra_ | zyga, right, we dont ... i was expecting some design to have come out of the planning sprint | 17:43 |
| zyga | Chipaca: they are way way too long usually | 17:43 |
| zyga | Chipaca: and they are not scoped | 17:43 |
| zyga | Chipaca: the rest is usually empty but I think it really should be different | 17:44 |
| Chipaca | zyga: "too long" and "not scoped" seem to contradict each otehr | 17:44 |
| zyga | Chipaca: (scope == many: ....) | 17:44 |
| zyga | Chipaca: under 50 chars | 17:44 |
| Chipaca | exactly, but scope can easily eat up more than that | 17:45 |
| zyga | Chipaca: it should not, usually it is very short (just directory name of 1/2nd level) | 17:45 |
| zyga | I think it's easy to use common sense | 17:45 |
| Chipaca | zyga: I mean | 17:46 |
| Chipaca | zyga: if the criteria is "--oneline needs to look good" | 17:46 |
| Chipaca | zyga: that is very different from "you need to understand what the commit is about" | 17:46 |
| Chipaca | I thought we wanted the latter | 17:46 |
| zyga | Chipaca: you want both actually | 17:47 |
| zyga | Chipaca: and it's not hard | 17:47 |
| zyga | Chipaca: one line summary, scope and short facts, + newline + poem of any size | 17:47 |
| jdstrand | ogra_: have you observed the behavior of /var/log/syslog in edge? | 17:54 |
| jdstrand | ogra_: claims a size of 2M but reads just hang | 17:55 |
| jdstrand | ogra_: stat /var/log/syslog too | 17:55 |
| jdstrand | ogra_: cp... | 17:55 |
| ogra_ | jdstrand, i dont have that file on my current edge images anymore | 17:55 |
| Chipaca | zyga: that's a nice article, the first one you linked | 17:55 |
| Chipaca | anyway, i need to go make dinner | 17:55 |
| Chipaca | o/ | 17:55 |
| jdstrand | ogra_: core 16-2.26.3 1962 canonical - | 17:56 |
| ogra_ | jdstrand, where do yiou get it from ? | 17:56 |
| jdstrand | ogra_: this is an upgrade | 17:56 |
| ogra_ | nothing should create it anymore | 17:56 |
| jdstrand | snap refresh core --edge | 17:56 |
| ogra_ | so its an old file you have lying around | 17:56 |
| ogra_ | not much we can do about that i fear | 17:56 |
| jdstrand | I don't know how it is there. I can't read it or do anything with it, yet, ls -l shows it | 17:56 |
| jdstrand | $ ls -l /var/log/syslog | 17:56 |
| jdstrand | -rw-r----- 1 syslog adm 1950368 May 17 09:53 /var/log/syslog | 17:56 |
| ogra_ | ogra@pi3:~$ ls /snap/core/current/var/log/|grep syslog | 17:57 |
| ogra_ | ogra@pi3:~$ | 17:57 |
| jdstrand | ogra_: that's a confusing bug that will trip up applications. they can't decide to read the journal or that file for example because the file exists | 17:57 |
| jdstrand | if they try to read, it'll just hang | 17:58 |
| ogra_ | it definitely doesnt exist on fresh installs ... i'm not really sure what to do regarding upgrades where that file was created before but i wouldnt expect it to be any different than before we removed rsyslog | 17:58 |
| ogra_ | it just doesnt get filled up | 17:58 |
| jdstrand | ogra_: why can't that file be removed on upgrade? or zeroed out, or something | 17:59 |
| ogra_ | do we have upgrade hooks that i dont know about ? | 17:59 |
| === elfgoh_ is now known as elfgoh | ||
| jdstrand | ogra_: it is different, that is why I am talking to you. I expected it to either not be there, or be whatever it was before and unchanging | 17:59 |
| jdstrand | :) | 17:59 |
| ogra_ | yes, me too | 18:00 |
| ogra_ | its just a text file after all | 18:00 |
| ogra_ | just that nothing writes to it anymore | 18:00 |
| ogra_ | permissions or anything didnt change | 18:00 |
| jdstrand | ogra_: maybe it is journald | 18:00 |
| ogra_ | and it was never readable by anyone but root anyway | 18:00 |
| ogra_ | i dont think journalds cares about syslog | 18:00 |
| jdstrand | that shouldn't be it... | 18:01 |
| jdstrand | ogra_: oh, another issue: | 18:02 |
| jdstrand | $ find /etc/systemd -name "*rsyslog*" | 18:02 |
| jdstrand | /etc/systemd/system/multi-user.target.wants/rsyslog.service | 18:02 |
| ogra_ | ouch | 18:03 |
| ogra_ | juts dangling though | 18:03 |
| jdstrand | that a dangling symlink | 18:03 |
| ogra_ | but ugly ... | 18:03 |
| jdstrand | yeah | 18:03 |
| ogra_ | mind filing a bug for that ... i'm not sure what we can do there though without upgrade hooks | 18:03 |
| ogra_ | (apart from ugly hacks) | 18:04 |
| jdstrand | there is something weird going on with this vm | 18:04 |
| ogra_ | anyway ... i need to stop now GF starts looking angry that i work so late today | 18:04 |
| jdstrand | I can't remove that file | 18:04 |
| ogra_ | ogra@pi3:~$ sudo rm /etc/systemd/system/multi-user.target.wants/rsyslog.service | 18:04 |
| ogra_ | ogra@pi3:~$ | 18:04 |
| ogra_ | works fine on my pi3 | 18:05 |
| ogra_ | i wonder if your syslog issue is also caused by this | 18:05 |
| jdstrand | that's what I'm wondering | 18:05 |
| jdstrand | ogra_: ok, see you later | 18:05 |
| jdstrand | ogra_: fyi, https://bugs.launchpad.net/snapd/+bug/1691525 | 18:11 |
| mup | Bug #1691525: dangling symlink /etc/systemd/system/multi-user.target.wants/rsyslog.service <snapd:New> <https://launchpad.net/bugs/1691525> | 18:11 |
| pedronis | mvo: I now added a spread test to the default config PR | 18:16 |
| * zyga calls it a day | 18:19 | |
| zyga | core is not ready as a snap | 18:19 |
| ogra_ | zyga, next build will be though | 18:20 |
| zyga | ogra_: yes but 20:20 is the time for kids and books; :-) | 18:20 |
| ogra_ | +1 | 18:20 |
| ogra_ | (or TV ... ) | 18:20 |
| zyga | I have a TV but I think it will stay in spain | 18:22 |
| zyga | too big to move back | 18:22 |
| zyga | not worth it (old) | 18:22 |
| zyga | not CRT-old though | 18:23 |
| zyga | and TV has only one use anyway, to plug to PS4 :) | 18:23 |
| zyga | youtube/netflix/some games | 18:23 |
| ogra_ | you will need a good spy-glass if you want to watch TV then though ... spain is quite a bit from poland | 18:24 |
| ogra_ | :P | 18:24 |
| zyga | ogra_: but we have big-brother TVs you know ;) | 18:25 |
| ogra_ | hehe | 18:25 |
| zyga | maybe I should become a politician | 18:25 |
| zyga | "I'm not nuts and far-right religious extremist!" | 18:25 |
| zyga | but nobody votes for that | 18:26 |
| ogra_ | yeah, not where you are going at least | 18:26 |
| zyga | yeah | 18:27 |
| ogra_ | compe to germany instead ;) | 18:27 |
| ogra_ | *come | 18:27 |
| ogra_ | (not the east part though ... there you also need to be fascist to be politican) | 18:28 |
| zyga | i can live at the border, i can be both then ;) | 18:29 |
| ogra_ | hah | 18:29 |
| jdstrand | ogra_: fyi, it seems that vm was messed up. I created a new one from stable and refreshed to edge and I can cat /var/log/syslog. it is unchanging | 18:34 |
| kyrofa | Do we have any real documentation on tracks? | 18:58 |
| Saviq | kalikiana, hey, any idea about http://pastebin.ubuntu.com/24594439/ when trying to use project containers? | 18:58 |
| * Saviq on lxd+ZFS, I suppose that matters | 18:58 | |
| davidcalle | kyrofa: anything missing from https://snapcraft.io/docs/reference/channels on the topic? | 18:59 |
| Saviq | I can launch via `lxc launch...` no problem | 18:59 |
| kyrofa | davidcalle, ah ha! I was looking in Build snaps | 19:02 |
| kyrofa | I should trust you more. You're always on top of things | 19:03 |
| davidcalle | kyrofa: I wish! :D | 19:03 |
| kyrofa | davidcalle, good docs. A question I'm left with, though, is: by default, it seems I have one track, `latest`. Once I start creating tracks, what is latest pointing to? | 19:09 |
| kyrofa | Can I change it? And I assume people using latest change with it? | 19:09 |
| kyrofa | Or is `latest` still its own thing, a track to which I must release separately? | 19:10 |
| Facu | kyrofa, "latest" is always the default, the one used when you don't specify one | 19:10 |
| Facu | right, you need to release to latest separately | 19:10 |
| Facu | kyrofa, everybody start with "latest", so let's suppose you cut 5.10 of your project, at that point you'd have "5.10" track and latest (with latest stuff) | 19:11 |
| kyrofa | Facu, and it 5.10 IS latest, I release into both? | 19:11 |
| kyrofa | s/it/if/ | 19:11 |
| kyrofa | cjwatson, does launchpad support releasing into multiple tracks? (it seems not) | 19:12 |
| Facu | kyrofa, if 5.10 is latest, you don't need to request a track for it, just use latest | 19:13 |
| Facu | kyrofa, there's no need to use a track, if you're ok with latest | 19:14 |
| mup | PR snapcraft#1321 closed: tests: remove the reusable parts tour test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1321> | 19:15 |
| kyrofa | Facu, then there's no way for my users to say "I only want to stay on 5.x" | 19:18 |
| kyrofa | Right? | 19:19 |
| noise][ | kyrofa: you would at some point before moving beyond 5.x, cut a 5.x branch and message users to move to it if they want to stay on 5.x | 19:20 |
| noise][ | and give enough time before dropping a 6.x onto latest or whatever | 19:20 |
| Facu | kyrofa, mmm... if you want users to say "I want to stay on 5.x" but currently 5.x is the ONLY thing you have... then you'd need to create a track, yes; you still would have "latest", but as 5.x is the only thing you have, no need for releases into latest | 19:20 |
| kyrofa | Facu, but then there's no way for users to say "I'm happy to roll to 6.x when it's out" :P | 19:21 |
| kyrofa | Facu, this is all academic anyway, I'm just giving you a hard time. Thanks for answering my questions! | 19:21 |
| Facu | kyrofa, not sure if I understand that question or use case | 19:21 |
| Facu | kyrofa, in any case there's no automatic switch between tracks | 19:22 |
| kyrofa | Indeed: if one wanted such a thing, they would need to be tracking `latest`, right? | 19:22 |
| Facu | kyrofa, right | 19:23 |
| kyrofa | davidcalle, perhaps you should note that in your recommendation: "Eg. when you release the 2.0 version of your software in the latest track, open a track called 2.0 for users wanting to stay on 2.0 and subsequent 2.* releases." | 19:23 |
| kyrofa | You'll need to release to both the 2.0 track _and_ latest | 19:24 |
| mup | PR snapcraft#1317 closed: recording: save the details of the source pulled <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1317> | 19:24 |
| kyrofa | And it seems that LP won't work with the workflow you're suggesting | 19:25 |
| === dpb1_ is now known as dpb1 | ||
| mup | Bug #1638334 changed: snap install not properly generating ConnectedSlot policy when auto-connecting via snap-declaration-allowed connection <personal> <snapd-interface> <Canonical System Image:Fix Released by kgunn72> <Snappy:Fix Released by albaguirre> <https://launchpad.net/bugs/1638334> | 20:31 |
| cjwatson | kyrofa: not at the moment, though it ought to be possible to add if we can work out a reasonable UI (maybe just space-separated tracks in that input box I guess) | 20:32 |
| cjwatson | kyrofa: it's just a UI issue though - you can set snap.store_channels over the API, in which case you could set it to ['2.0/edge', 'latest/edge'] or something | 20:33 |
| kyrofa | cjwatson, good to know, thank you! | 20:34 |
| cjwatson | kyrofa: (I don't recall what the UI will do when it tries to display that) | 20:34 |
| CantaloupMelon | I think I have a quick question: Why would my snap not auto connect to plugs? I have them listed under each app, as plugs: [network, network-bind, etc] | 20:35 |
| kyrofa | CantaloupMelon, some plugs don't auto-connect as they can be a bit dangerous | 20:35 |
| kyrofa | CantaloupMelon, but network and network-bind should auto-connect fine | 20:35 |
| CantaloupMelon | I also have home for a few as well | 20:36 |
| kyrofa | That one should also be automatically connected these days | 20:36 |
| CantaloupMelon | when I do a snap interfaces (after a snap try) they're not connected, and if I do it manually after the fact everything is great | 20:37 |
| kyrofa | CantaloupMelon, none of them? Not even the network ones? | 20:37 |
| CantaloupMelon | no, none. | 20:37 |
| kyrofa | That doesn't seem right. Have you tried actually installing the snap? Does the same thing happen, or is it specific to tried snaps? | 20:38 |
| CantaloupMelon | Also strangely one VM I could do a snap connect foo:network :network and it worked fine, but not in this other VM running ubuntu 16.10 | 20:38 |
| CantaloupMelon | kyrofa: happened on installed ones too | 20:38 |
| kyrofa | CantaloupMelon, only in 16.10, though? | 20:39 |
| CantaloupMelon | well, I did a fresh VM cause what I was doing wasn't compiling under my original VM Ubuntu 16.04. maybe I forgot to install something | 20:39 |
| CantaloupMelon | or update? | 20:40 |
| kyrofa | CantaloupMelon, jdstrand or zyga might have ideas for you... I'm not sure why interfaces wouldn't be auto-connecting on 16.10 | 20:40 |
| CantaloupMelon | at least I'm not going nuts, I figured it should work | 20:41 |
| kyrofa | CantaloupMelon, agreed, I figure it should work as well | 20:42 |
| mup | PR snapcraft#1322 opened: state: ignore the 'any' architecture in the build packages apt cache <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1322> | 22:18 |
| mup | PR snapcraft#1323 opened: state: search for the build package that provides a virtual package <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1323> | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!