[03:53] hello, is there a way to install older revision of core? [05:40] PR snapcraft#1861 opened: extractors: also support appdata.xml appstream files [05:58] morning [06:47] o/ [06:47] * zyga-ubuntu is tad sleepy [06:47] hacking till 2AM [06:48] I'll go back to bed [06:50] zyga-ubuntu: hey [07:21] mvo: morning [07:21] PR snapd#4458 closed: overlord/snapstate: no refresh just for hints if there was a recent regular full refresh [07:23] hey mborzecki - good monring [07:23] PR snapd#4456 closed: snap: rename `snap advise-command` to `snap advise-snap --command` [07:53] PR snapd#4463 opened: client, daemon: update user's email when logging in with new account [07:53] good morning [07:54] kalikiana: morning [08:14] PR snapd#4394 closed: snap: give the snap.Container interface a Walk method [08:32] hey [08:32] back now, I think I owe everyone some reviews [08:35] I took 4452 and went wild on unit tests [08:35] found an obscure bug with symlinks (and fixed it) [08:36] but grew the branch to a big extreme sizes [08:36] I will probably double back and propse all the unit test changes separately, though not sure if that will help [08:38] I'll get a coffee and start chopping [08:46] all right === __chip__ is now known as Chipaca [09:05] PR snapd#4464 opened: overlord/snapstate: add validateContainer, that uses snap.Container's [09:05] mvo: thank you for merging #4394! As a recompense, here's 4464 ^-^ [09:05] PR #4394: snap: give the snap.Container interface a Walk method [09:06] oh dear, commit message murder [09:06] * Chipaca tidies [09:07] * kalikiana coffee [09:07] Chipaca: thanks for the code update. it was very nice [09:09] Chipaca: hi, did you see my comment last night? we install jq with --devmode in other tests, do you have a preference for not doing that everywhere? [09:10] pedronis: it seems tidier to me to not use devmode for that -- we disrecommend devmode for good reasons, but if at the first problem _we_ switch to devmode, … :-) [09:11] Chipaca: well, not these days people publish as classic instead [09:12] pedronis: same argument there though [09:12] pedronis: but just to be clear, it's merely a sense of tidiness, nothing more [09:13] I found our tests not very tidy in general, but maybe it's just me [09:14] pedronis: that's fair [09:15] I mean, I feel when writing spread tests that my tidniness setting is medium [09:16] pedronis: hehe, how does that materialize? [09:18] zyga-ubuntu: I'm assuming if it were higher than that there'd be infinite PRs from samuele trying to beat our spread suite into submission [09:21] Chipaca: either way, switching away from --devmode for jq would be a PR, as I said it's done in a couple of places, starting with prepare.sh [09:21] pedronis: no worries [09:28] Chipaca: if we do that it become tempting to introduce some kind of jq_modify_state helper (but maybe we already have too many obscure helpers we don't remember about) [09:33] Chipaca: you have a review [09:33] Chipaca: nice job btw [09:34] a second review for 4454 would be nice, should be trivial [09:38] PR snapd#4454 closed: snap: fix gadget.yaml parsing for multi volume gadgets [09:39] pedronis: I think https://github.com/snapcore/snapd/pull/4356 is ready for a re-review [09:39] PR #4356: many: add new `snap refresh --amend ` command [09:40] I'll look at it today [09:41] ta [09:43] * Chipaca -> bbiab (physio) [09:44] woot, --ammend wouldn't have been my choice of name, but nice to see this [09:44] kalikiana: not too late for suggestions :) [09:44] kalikiana: in the PR please, they will need sign off from gustavo [09:49] Aye, will comment there [09:57] popey: hey, we 1742247> what version of snapd did you use to make this workaround work? [09:57] popey: fwiw, the message got improved to be ambiguous, it now says "snap foo is no longer tracking %s" [09:57] (in master) [10:01] mvo: I'm on core from candidate [10:01] popey: ta, let me try to reproduce with that [10:03] mborzecki: https://travis-ci.org/snapcore/snapd/builds/327128264#L1541 is probably something you want to look at [10:03] mborzecki: (context is 4463) [10:03] mvo: thanks, looking now [10:04] also 4461 is tiny and needs a second review [10:06] hmm, github is not responding here [10:07] popey: ping wrt bug 1741752 [10:07] Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' [10:07] kalikiana: hello [10:07] popey: Hey. How are you this morning? [10:08] Super, how are you? :) [10:08] Very well. There's a little bit of sun today so that"s rare and awesome :-D [10:09] https://status.github.com/messages [10:09] it's down [10:10] popey: I'd just like to clarify what you wrote in the bug if possible. In the description you said `usually if I re-run or clean, it goes away` but later replied `definitely didn't do lxc delete, and don't believe I did snapcraft clean` [10:10] that's right [10:11] what I do is run snapcraft, the thing needs rebuilding so I re-run snapcraft. Then the error appears [10:11] popey: Maybe the expected behavior isn't very clear. When you do `snapcraft clean`with persistent containers enabled, that equates to deleting the container if you don't pass more arguments. [10:12] Yes. That's what I expect. But as I said, I didn't clean. But I _have_ to clean to get past this error [10:12] eg. `snapcraft clean mypart` would *not* delete it [10:13] popey: You mean if you do `snapcraft clean` the error goes away? [10:13] Yes [10:13] popey: Okay, now that makes sense. I was a bit lost in your wording, sorry :-D [10:14] Ah sorry. Will try harder with my words next time :) [10:16] popey: So, as I said in the comment, re-using an existing container wouldn't pull in a new snapcraft if the revision changed or it's a local build. Can you tell me what might have expected? Maybe we should print a message like `Btw your snapcraft is on a different channel, you may wanna refresh the container` [10:16] Wait, what? [10:16] I don't want to pull in a new snapcraft revision [10:17] I just wanted the software to rebuild, that's all [10:17] and I got smacked in the face with python backtrace and an error at the bottom. I am not trying to update anything, *just* rebuild like a normal developer would as they iterate over a build [10:18] popey: Example, you have snapcraft from beta, build stuff in a container, do `snap refresh snapcraft --channel=edge`, and now your new snapcraft has different expectations [10:18] I think that's what happened, simplified [10:18] I didnt do that [10:18] i just ran snapcraft and then ran snapcraft again [10:19] you're saying snapd refreshed in the minute or two between running snapcraft and running it again? [10:20] PR snapd#4457 closed: spread: trying to re-enable tests on Fedora [10:21] popey: So you were using edge the whole time? [10:21] Please bear with me, I'm just trying to get the exact situation [10:22] yes [10:22] popey: So then it must've been snapd refreshing out of sync on your host vs. container [10:22] Which is possible since we don't force that [10:24] kalikiana: tell you what, lets park that bug, and I will try and re-produce it. [10:24] And get a better "steps to reproduce" okay? [10:24] because it's all a bit muddy now :) [10:26] (unless you fully understand it now and know what to fix) :D [10:27] PR snapd#4461 closed: snap: fix missing error check when multiple snaps are refreshed [10:27] mvo: 1st of the easy branches: https://github.com/snapcore/snapd/pull/4465/files [10:27] PR #4465: cmd/snap-update-ns: new test features [10:28] PR snapd#4465 opened: cmd/snap-update-ns: new test features [10:30] mvo: anything I can do to help #1735344 along? [10:30] Bug #1735344: [SRU] 2.30 [10:30] niemeyer: hey, for late, do the strings in 4441 look good to you ? this pr is mostly a tiny string change [10:31] sparkiegeek: a good question, it is still in unapproved. I assume apw is just super busy with spectre/meltdown and all this madness [10:32] * sparkiegeek nods [10:32] i am cirtaonly that, plus it won't build even if i accept it [10:32] apw: aha, indeed, that is the other issue :) [10:32] * mvo hugs apw for tireless work to protect us again [10:33] mvo: just to confirm, to get 2.30 in the meantime, I should use ppa:snappy-dev/edge ? [10:33] * sparkiegeek joins mvo in hugging apw [10:34] on systems that don't have core installed and need ... configuration [10:34] popey: Yeah, I think I know what's going on now. Incompatible `snap/.snapcraft/state`. I'll figure something out with elopio [10:34] sparkiegeek: the stable core got updated so you should have it via re-exec. if you prefer the deb you can add "apt-add-repository ppa:snappy-dev/image" [10:34] sparkiegeek: its there for xenial,zesty,artful [10:34] popey: Thanks for clarifying the missing pieces of the puzzle! [10:34] sparkiegeek: and I think trusty but I doubt you care about that [10:36] PR snapd#4436 closed: snap: do not leak internal errors on install/refresh etc [10:36] kalikiana: awesome [10:36] niemeyer: if you have a bit of time (hard I know) double checking the strings in 4382 and 4441 would be great. just to make sure everything is consistent [10:38] mvo: 2nd and tiny trivial PR: https://github.com/snapcore/snapd/pull/4466 [10:38] PR #4466: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options [10:39] PR snapd#4466 opened: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options [10:39] mvo: 3rd trival PR: https://github.com/snapcore/snapd/pull/4467 [10:39] PR #4467: cmd/snap-update-ns: untangle upcoming cyclic initialization [10:40] PR snapd#4334 closed: tests: ensure snap-confine apparmor profile is parsable [10:40] PR snapd#4467 opened: cmd/snap-update-ns: untangle upcoming cyclic initialization [10:40] mvo: 4th: ^ [10:41] PR snapd#4468 opened: cmd/snap-update-ns: we don't want to bind mount symlinks [10:41] zyga-ubuntu: ta [10:41] now the main dish, this will take a little longer to prepare [11:05] PR snapd#4452 closed: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP [11:05] mvo: I have the rest but I need this batch to land, I'll switch to review to help others now [11:06] mvo: if you can review 4465, 4466, 4467 and 4468 it will help me a lot, they are all small [11:12] zyga-ubuntu: ok [11:12] mvo: Thanks, will look at that next [11:13] hey niemeyer, good morning :) [11:13] niemeyer: thanks! really just a quick ack/nack on the strings [11:13] niemeyer: and good morning :) [11:13] Moin! [11:23] morning! [11:24] * Son_Goku rises from the dead [11:27] Son_Goku: hey [11:27] * zyga-ubuntu hands Son_Goku a coffee [11:27] mborzecki: you have a review on 4449 [11:27] * Son_Goku stares at the coffee [11:30] zyga-ubuntu: thanks [11:31] mvo: What's the background for #4441? [11:31] PR #4441: snap: add usage hints in `snap download` [11:33] niemeyer: a bugreport [11:34] niemeyer: it should be referenced in the PR - its fine if this is a won't-fix of course [11:35] mvo: I'm asking because it felt curious to just throw the --help in this case, when this is the normal workflow for download and the vast majority of cases people using download won't be interested in these pages [11:35] mvo: What was the report? People lacking ack? [11:35] niemeyer: yeah, people did not know apparently that "snap ack" exists/can be used to import the assertion [11:36] mvo: Okay, maybe we can be more direct then and give the command names [11:36] command lines [11:36] mvo: I'll suggest something for your consideration there [11:37] niemeyer: +1 [11:37] niemeyer: thank you! [11:38] zyga-ubuntu: re 4449> what I am missing here is why the tests test for *both* messages - the "use debug build" and in the same test also with debug enabled it tests for the real message. or am I reading it incorrectly? [11:39] mvo: not sure, I think it's not relevant to the issue that mborzecki wanted to fix (building with debug actually getting a debug binary) [11:39] mvo: in the debug binary those will be visible [11:39] mvo: I think the 2nd part is not strictly needed [11:40] zyga-ubuntu: right, but still, why are the tests expecting two lines now, one with "hidden" and then "the real thing"? [11:40] mvo: I don't know :) [11:40] zyga-ubuntu: mvo: there are 2 parts, one is getting a debug binary, the other is incorrect error message from a failed [u]mount when SNAP_CONFINE_DEBUG is enabled [11:41] mvo: np, please have a look to see what you think [11:41] basically when you have a non-debug build and run with SNAP_CONFINE_DEBUG you'll see `cannot perform operation: (disabled) use debug build to see details` [11:42] mborzecki: that's the desired behavior [11:42] zyga-ubuntu: ok, but then but if you turn SNAP_CONFINE_DEBUG off you'll see `cannot perform operation: mount -t blah blah` [11:42] mborzecki: lol, really? [11:42] yes, that's what the PR is fixing [11:43] mborzecki: hmmm :) [11:43] mborzecki: ok, then I just don't understand the test in https://github.com/snapcore/snapd/pull/4449/files#diff-70758630224dcb7ba3963d1fa05bb69aR234 - it seems to check for both message on stderr, no? [11:43] PR #4449: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 [11:43] mborzecki: that's probably confusing, are you sure we render the messages in non-debug builds? [11:43] mborzecki: I've seen the disabled message countless times [11:43] mborzecki: some messages are hardcoded and not formatted on the fly [11:44] zyga-ubuntu: take a look here: https://forum.snapcraft.io/t/on-arch-snaps-show-broken-after-switch-from-snapd-to-snapd-git/3427, specifically the first message and then the debug log [11:44] popey got: [11:44] [alan@manjarovm ~]$ snap run brave [11:44] cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory [11:44] and then when running with SNAP_CONFINE_DEBUG: [11:44] mborzecki: that particular one may be hardcoded [11:45] mborzecki: they look the same but come from different places [11:45] cannot perform operation: (disabled) use debug build to see details: No such file or directory [11:45] mborzecki: DEBUG: performing operation: (disabled) use debug build to see details [11:45] mborzecki: that's the disabled one [11:45] mborzecki: I still don't see what's wrong there [11:46] zyga-ubuntu: no SNAP_CONFINE_DEBUG, `cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory` [11:46] zyga-ubuntu: with SNAP_CONFINE_DEBUG `cannot perform operation: (disabled) use debug build to see details: No such file or directory` [11:46] same binary [11:46] mborzecki: devil is in the details :) but I see how this is confusing (for me too) [11:46] mborzecki: it depends on who prints what [11:46] mborzecki: anyway, I'll look again, thank you for explaining that [11:48] zyga-ubuntu: we're hitting this path: https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/mount-opt.c#L266 then this check https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/mount-opt.c#L280 neve succeeds so you end up printing the `(disabled) ..` message whem mount/umount fails [11:49] ohh [11:49] that's wrong [11:49] it should not be there [11:49] that whole thing should go away [11:49] ah [11:49] no [11:49] sorry [11:49] :D [11:50] I just read the comment above it [11:50] sorry, my mind is rusty about this === ogra_ is now known as ogra [11:52] Chipaca: i'm playing with gometalinter and vet tool just raised this: 'advisor/backend.go:178::error: literal copies lock value from *db: github.com/boltdb/bolt.DB contains sync.Pool contains sync.noCopy (vet)' [12:00] PR snapcraft#1831 closed: cli: add expiration option to export-login [12:00] PR snapcraft#1849 closed: tests: add snap not found tests [12:00] * Chipakeitor looks takes careful aim at Chipaca [12:00] mborzecki: nice find! === Chipakeitor is now known as Chipaca [12:01] mborzecki: i'm not sure i understand [12:04] mvo: On the second one, a typo and a suggestion [12:04] niemeyer: \o/ thank you [12:04] Chipaca: looking into it now, might be false positive [12:05] * zyga-ubuntu goes to cook something, ttyl [12:05] mvo: Thank you! [12:05] mborzecki: I don't mind making boltFinder embed a *bolt.DB instead of a bolt.DB if it makes the liter happy [12:05] linter* [12:06] Chipaca: i guess the tool cannot detect if the pool was used and raises a warning [12:07] mborzecki: and it's fair; there's no guarantee the DB didn't start a maintenance goroutine [12:07] then i think it's fair to embed *botl.DB rather than a copy [12:08] * Chipaca nods [12:08] thanks, metalinter! [12:25] * Chipaca -> dentit [12:42] PR snapd#4469 opened: tests: add hard-coded fully expired macaroons to run related tests [12:58] i might be a few minutes late to the standup [12:58] * Chipaca returning from dentistist [12:59] gometalinter running from run-checks --static https://paste.ubuntu.com/26359996/ [13:07] PR snapd#4470 opened: overlord/snapstate: fix gofmt -s -l [13:36] PR snapcraft#1860 closed: setup: simplify bin/snapcraft and correct tests [13:40] kyrofa, sergiusens what happend to https://github.com/snapcore/snapcraft/pull/1420/files ? I tried to build a snap using that with snapcraft 2.34 and I got an error that "adapter" is unknown. is my snapcraft too old? [13:40] PR snapcraft#1420: add new "no-wrapper" property to apps [13:47] Chipakeitor: can you look at 4465-4468 quickly, I'd like to land them to propse the intersting changes that will take longer to review === Chipakeitor is now known as Chipaca [13:47] * Chipaca looks [13:53] PR snapd#4463 closed: client, daemon: update user's email when logging in with new account [13:55] zyga-ubuntu: neat-o [14:00] * kalikiana going to have lunch, back in a bit [14:01] * pstolowski lunch [14:01] PR snapd#4467 closed: cmd/snap-update-ns: untangle upcoming cyclic initialization [14:02] PR snapd#4466 closed: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options [14:02] PR snapd#4468 closed: cmd/snap-update-ns: we don't want to bind mount symlinks [14:14] zyga-ubuntu: hi. Yesterday you mentioned having a chat about user-mounts some time tomorrow with niemeyer. Should we set a time? [14:15] jamesh: hey, yes the plan is to do it tomorrow, you mentioned someting about your morning being preferred [14:15] let's look at the calendar now [14:15] zyga-ubuntu: I thought my evening might be easier [14:16] ah I must have rembembered wrong then, sorry [14:16] I think the biggest time difference is between WA and Brazil [14:18] off to pick up the kids [14:18] I wish google calendar could show the local time for each participant [14:19] jamesh: when it's 10AM here (CET+1) what is it for you? [14:19] zyga-ubuntu: i thought you were on CET [14:20] Chipaca: I never remember if its' CET or +1 [14:20] Chipaca: DST and that [14:20] zyga-ubuntu: your DST is in march [14:21] starts in march, i mean [14:21] zyga-ubuntu: WA is UTC+8, so 10AM in UTC+1 would be 5 PM [14:21] jamesh: that's reasonable for you I think [14:22] Chipaca: ah, I remembered UTC+1=CET, now it makes sense [14:22] jamesh: ok I think 10AM it is [14:23] zyga-ubuntu: sounds great. [14:23] hmm, the new calendar has arrived [14:24] no idea how to add a hangout link [14:24] zyga-ubuntu: maybe move it forward a day? [14:25] HAH! a bunch of spread tests failed because the snaps don't pass validation [14:25] * sergiusens ran out to run some errands [14:25] doh :D [14:25] zyga-ubuntu: you've got it scheduled for 5 hours ago [14:26] sorry, the UI is totally confusing at first sight, I saw vertical stripes which I assumed were days, it's updated now [14:26] (it were people, not days) [14:26] mvo is your PR tagged with a greater number? [14:27] sergiusens: it says "milestone: 2.35" [14:28] jamesh: realistically I think we'll see a lot of mount features ladning next week [14:28] jamesh: I'm close to enabling layouts, the new content interface will likely land this week [14:28] sergiusens: hrm, but apparently I only have 2.34 - sorry, let me figure out where I can get 2.35 [14:28] jamesh: your work is also looking very good [14:29] jamesh: we can look at enabling themes soon, though I don't really know if my I know what your plans for that are [14:30] zyga-ubuntu: If there is time, I'd also like to discuss how we could support the dbus app container socket feature [14:30] I'm not familiar with that, can you share a link so that I can prepare [14:31] zyga-ubuntu: https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 has a summary I prepared, plus links to the upstream bugs [14:31] thank you, I'll read that today [14:33] zyga-ubuntu: I've been talking with upstream to try and make sure the feature takes a form we can use, but properly supporting it will require some changes to the way we construct the mount namespaces [14:34] since we'd want to inject a new unix socket [14:34] jamesh: do you have a specific plan (I haven't read everything yet) [14:34] jamesh: where would it be injected? into the per-user mount ns? [14:35] zyga-ubuntu: no specific plan yet. From that thread, I had some ideas that were shot down. [14:35] ok [14:36] zyga-ubuntu: for the session bus, we probably need to have "snap run" ask some user process to set up the socket in $XDG_RUNTIME_DIR/snap.$pkgname/dbus [14:36] zyga-ubuntu: It's less obvious what to do about the system bus [14:37] jamesh: do you see this as something apps can use transparently or will this be a transition that can break existing snaps? [14:38] zyga-ubuntu: apps connect to whatever $DBUS_SESSION_BUS_ADDRESS tells them to connect to. [14:38] right but I presume the point of this exercise is to put something new at the other end [14:38] zyga-ubuntu: this would mainly offer a way for unconfined trusted helpers to identify confined apps in a confinement system independent way [14:38] some proxy probably [14:39] zyga-ubuntu: so e.g. rather than xdg-desktop-portal having code to separately identify when it is talking to a snap or a flatpak, it would check for an app container ID [14:41] zyga-ubuntu: the dbus feature also offers a new message filtering ACL system, but we can continue to rely on the existing AppArmor mediation [14:42] jamesh: how does the container ID thing work? [14:43] zyga-ubuntu: some process creates a new listening unix domain socket, and passes it to dbus-daemon along with some metadata (containment system, application identifier, etc). dbus-daemon will then listen on that socket in addition to its main one, and any connections accepted on the new socket will be tagged with that info [14:44] ah [14:44] cool [14:44] essentially a trusted way to introduce a new socket to dbus [14:44] is that shipping today? [14:44] (anywhere) [14:45] if we roll this out how hard will it be to push it to 14.04 [14:46] the initial work is in dbus master. I don't think it's in bionic yet [14:47] and some things are in flux [14:47] jamesh: do you see this as a feature we only enable on some releases/distros? [14:47] jamesh: and can we easily identify if dbusd has it? [14:48] zyga-ubuntu: ideally I'd use it everywhere. But it will need some kinks worked out [14:49] jamesh: but we cannot ship it to, say, fedora 26 [14:49] zyga-ubuntu: the feature is controlled via method calls on the bus daemon: if those method calls are missing, then the feature isn't available. [14:49]