[03:53] <seyeongkim> hello, is there a way to install older revision of core?
[05:40] <mup> PR snapcraft#1861 opened: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861>
[05:58] <mborzecki> morning
[06:47] <zyga-ubuntu> o/
[06:47]  * zyga-ubuntu is tad sleepy
[06:47] <zyga-ubuntu> hacking till 2AM
[06:48] <zyga-ubuntu> I'll go back to bed
[06:50] <mborzecki> zyga-ubuntu: hey
[07:21] <mborzecki> mvo: morning
[07:21] <mup> PR snapd#4458 closed: overlord/snapstate: no refresh just for hints if there was a recent regular full refresh <Reviewed> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4458>
[07:23] <mvo> hey mborzecki - good monring
[07:23] <mup> PR snapd#4456 closed:  snap: rename `snap advise-command` to `snap advise-snap --command`  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4456>
[07:53] <mup> PR snapd#4463 opened: client, daemon: update user's email when logging in with new account <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4463>
[07:53] <kalikiana> good morning
[07:54] <mborzecki> kalikiana: morning
[08:14] <mup> PR snapd#4394 closed: snap: give the snap.Container interface a Walk method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4394>
[08:32] <zyga-ubuntu> hey
[08:32] <zyga-ubuntu> back now, I think I owe everyone some reviews
[08:35] <zyga-ubuntu> I took 4452 and went wild on unit tests
[08:35] <zyga-ubuntu> found an obscure bug with symlinks (and fixed it)
[08:36] <zyga-ubuntu> but grew the branch to a big extreme sizes
[08:36] <zyga-ubuntu> I will probably double back and propse all the unit test changes separately, though not sure if that will help
[08:38] <zyga-ubuntu> I'll get a coffee and start chopping
[08:46] <zyga-ubuntu> all right
[09:05] <mup> PR snapd#4464 opened: overlord/snapstate: add validateContainer, that uses snap.Container's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>
[09:05] <Chipaca> mvo: thank you for merging #4394! As a recompense, here's 4464 ^-^
[09:05] <mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4394>
[09:06] <Chipaca> oh dear, commit message murder
[09:06]  * Chipaca tidies
[09:07]  * kalikiana coffee
[09:07] <mvo> Chipaca: thanks for the code update. it was very nice
[09:09] <pedronis> 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] <Chipaca> 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] <pedronis> Chipaca: well, not these days people publish as classic instead
[09:12] <Chipaca> pedronis: same argument there though
[09:12] <Chipaca> pedronis: but just to be clear, it's merely a sense of tidiness, nothing more
[09:13] <pedronis> I found our tests not very tidy in general, but maybe it's just me
[09:14] <Chipaca> pedronis: that's fair
[09:15] <pedronis> I mean, I feel when writing spread tests that my tidniness setting is medium
[09:16] <zyga-ubuntu> pedronis: hehe, how does that materialize?
[09:18] <Chipaca> 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] <pedronis> 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] <Chipaca> pedronis: no worries
[09:28] <pedronis> 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] <mvo> Chipaca: you have a review
[09:33] <mvo> Chipaca: nice job btw
[09:34] <mvo> a second review for 4454 would be nice, should be trivial
[09:38] <mup> PR snapd#4454 closed: snap: fix gadget.yaml parsing for multi volume gadgets <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4454>
[09:39] <mvo> pedronis: I think https://github.com/snapcore/snapd/pull/4356 is ready for a re-review
[09:39] <mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
[09:40] <pedronis> I'll look at it today
[09:41] <mvo> ta
[09:43]  * Chipaca -> bbiab (physio)
[09:44] <kalikiana> woot, --ammend wouldn't have been my choice of name, but nice to see this
[09:44] <mvo> kalikiana: not too late for suggestions :)
[09:44] <mvo> kalikiana: in the PR please, they will need sign off from gustavo
[09:49] <kalikiana> Aye, will comment there
[09:57] <mvo> popey: hey, we 1742247> what version of snapd did you use to make this workaround work?
[09:57] <mvo> popey: fwiw, the message got improved to be ambiguous, it now says "snap foo is no longer tracking %s"
[09:57] <mvo> (in master)
[10:01] <popey> mvo: I'm on core from candidate
[10:01] <mvo> popey: ta, let me try to reproduce with that
[10:03] <mvo> mborzecki: https://travis-ci.org/snapcore/snapd/builds/327128264#L1541 is probably something you want to look at
[10:03] <mvo> mborzecki: (context is 4463)
[10:03] <mborzecki> mvo: thanks, looking now
[10:04] <mvo> also 4461 is tiny and needs a second review
[10:06] <zyga-ubuntu> hmm, github is not responding here
[10:07] <kalikiana> popey: ping wrt bug 1741752
[10:07] <mup> Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:New> <https://launchpad.net/bugs/1741752>
[10:07] <popey> kalikiana: hello
[10:07] <kalikiana> popey: Hey. How are you this morning?
[10:08] <popey> Super, how are you? :)
[10:08] <kalikiana> Very well. There's a little bit of sun today so that"s rare and awesome :-D
[10:09] <zyga-ubuntu> https://status.github.com/messages
[10:09] <zyga-ubuntu> it's down
[10:10] <kalikiana> 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] <popey> that's right
[10:11] <popey> what I do is run snapcraft, the thing needs rebuilding so I re-run snapcraft. Then the error appears
[10:11] <kalikiana> 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] <popey> 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] <kalikiana> eg. `snapcraft clean mypart` would *not* delete it
[10:13] <kalikiana> popey: You mean if you do `snapcraft clean` the error goes away?
[10:13] <popey> Yes
[10:13] <kalikiana> popey: Okay, now that makes sense. I was a bit lost in your wording, sorry :-D
[10:14] <popey> Ah sorry. Will try harder with my words next time :)
[10:16] <kalikiana> 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] <popey> Wait, what?
[10:16] <popey> I don't want to pull in a new snapcraft revision
[10:17] <popey> I just wanted the software to rebuild, that's all
[10:17] <popey> 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] <kalikiana> 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] <kalikiana> I think that's what happened, simplified
[10:18] <popey> I didnt do that
[10:18] <popey> i just ran snapcraft and then ran snapcraft again
[10:19] <popey> you're saying snapd refreshed in the minute or two between running snapcraft and running it again?
[10:20] <mup> PR snapd#4457 closed: spread: trying to re-enable tests on Fedora <Reviewed> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4457>
[10:21] <kalikiana> popey: So you were using edge the whole time?
[10:21] <kalikiana> Please bear with me, I'm just trying to get the exact situation
[10:22] <popey> yes
[10:22] <kalikiana> popey: So then it must've been snapd refreshing out of sync on your host vs. container
[10:22] <kalikiana> Which is possible since we don't force that
[10:24] <popey> kalikiana: tell you what, lets park that bug, and I will try and re-produce it.
[10:24] <popey> And get a better "steps to reproduce" okay?
[10:24] <popey> because it's all a bit muddy now :)
[10:26] <popey> (unless you fully understand it now and know what to fix) :D
[10:27] <mup> PR snapd#4461 closed: snap: fix missing error check when multiple snaps are refreshed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4461>
[10:27] <zyga-ubuntu> mvo: 1st of the easy branches: https://github.com/snapcore/snapd/pull/4465/files
[10:27] <mup> PR #4465: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465>
[10:28] <mup> PR snapd#4465 opened: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465>
[10:30] <sparkiegeek> mvo: anything I can do to help #1735344 along?
[10:30] <mup> Bug #1735344: [SRU] 2.30 <snapd (Ubuntu):Confirmed> <snapd (Ubuntu Trusty):Confirmed> <snapd (Ubuntu Xenial):Confirmed> <snapd (Ubuntu Zesty):Confirmed> <snapd (Ubuntu Artful):Confirmed> <https://launchpad.net/bugs/1735344>
[10:30] <mvo> niemeyer: hey, for late, do the strings in 4441 look good to you ? this pr is mostly a tiny string change
[10:31] <mvo> 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] <apw> i am cirtaonly that, plus it won't build even if i accept it
[10:32] <mvo> apw: aha, indeed, that is the other issue :)
[10:32]  * mvo hugs apw for tireless work to protect us again
[10:33] <sparkiegeek> 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] <sparkiegeek> on systems that don't have core installed and need ... configuration
[10:34] <kalikiana> popey: Yeah, I think I know what's going on now. Incompatible `snap/.snapcraft/state`. I'll figure something out with elopio
[10:34] <mvo> 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] <mvo> sparkiegeek: its there for xenial,zesty,artful
[10:34] <kalikiana> popey: Thanks for clarifying the missing pieces of the puzzle!
[10:34] <mvo> sparkiegeek: and I think trusty but I doubt you care about that
[10:36] <mup> PR snapd#4436 closed:  snap: do not leak internal errors on install/refresh etc  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4436>
[10:36] <popey> kalikiana: awesome
[10:36] <mvo> 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] <zyga-ubuntu> mvo: 2nd and tiny trivial PR: https://github.com/snapcore/snapd/pull/4466
[10:38] <mup> PR #4466: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466>
[10:39] <mup> PR snapd#4466 opened: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466>
[10:39] <zyga-ubuntu> mvo: 3rd trival PR: https://github.com/snapcore/snapd/pull/4467
[10:39] <mup> PR #4467: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467>
[10:40] <mup> PR snapd#4334 closed: tests: ensure snap-confine apparmor profile is parsable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4334>
[10:40] <mup> PR snapd#4467 opened: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467>
[10:40] <zyga-ubuntu> mvo: 4th: ^
[10:41] <mup> PR snapd#4468 opened: cmd/snap-update-ns: we don't want to bind mount symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4468>
[10:41] <mvo> zyga-ubuntu: ta
[10:41] <zyga-ubuntu> now the main dish, this will take a little longer to prepare
[11:05] <mup> PR snapd#4452 closed: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4452>
[11:05] <zyga-ubuntu> mvo: I have the rest but I need this batch to land, I'll switch to review to help others now
[11:06] <zyga-ubuntu> mvo: if you can review 4465, 4466, 4467 and 4468 it will help me a lot, they are all small
[11:12] <mvo> zyga-ubuntu: ok
[11:12] <niemeyer> mvo: Thanks, will look at that next
[11:13] <zyga-ubuntu> hey niemeyer, good morning :)
[11:13] <mvo> niemeyer: thanks! really just a quick ack/nack on the strings
[11:13] <mvo> niemeyer: and good morning :)
[11:13] <niemeyer> Moin!
[11:23] <pstolowski> morning!
[11:24]  * Son_Goku rises from the dead
[11:27] <zyga-ubuntu> Son_Goku: hey
[11:27]  * zyga-ubuntu hands Son_Goku a coffee
[11:27] <zyga-ubuntu> mborzecki: you have a review on 4449
[11:27]  * Son_Goku stares at the coffee
[11:30] <mborzecki> zyga-ubuntu: thanks
[11:31] <niemeyer> mvo: What's the background for #4441?
[11:31] <mup> PR #4441: snap: add usage hints in `snap download` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4441>
[11:33] <mvo> niemeyer: a bugreport
[11:34] <mvo> niemeyer: it should be referenced in the PR - its fine if this is a won't-fix of course
[11:35] <niemeyer> 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] <niemeyer> mvo: What was the report? People lacking ack?
[11:35] <mvo> niemeyer: yeah, people did not know apparently that "snap ack" exists/can be used to import the assertion
[11:36] <niemeyer> mvo: Okay, maybe we can be more direct then and give the command names
[11:36] <niemeyer> command lines
[11:36] <niemeyer> mvo: I'll suggest something for your consideration there
[11:37] <mvo> niemeyer: +1
[11:37] <mvo> niemeyer: thank you!
[11:38] <mvo> 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] <zyga-ubuntu> 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] <zyga-ubuntu> mvo: in the debug binary those will be visible
[11:39] <zyga-ubuntu> mvo: I think the 2nd part is not strictly needed
[11:40] <mvo> zyga-ubuntu: right, but still, why are the tests expecting two lines now, one with "hidden" and then "the real thing"?
[11:40] <zyga-ubuntu> mvo: I don't know :)
[11:40] <mborzecki> 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] <niemeyer> mvo: np, please have a look to see what you think
[11:41] <mborzecki> 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] <zyga-ubuntu> mborzecki: that's the desired behavior
[11:42] <mborzecki> 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] <mvo> mborzecki: lol, really?
[11:42] <mborzecki> yes, that's what the PR is fixing
[11:43] <zyga-ubuntu> mborzecki: hmmm :)
[11:43] <mvo> 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] <mup> PR #4449: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4449>
[11:43] <zyga-ubuntu> mborzecki: that's probably confusing, are you sure we render the messages in non-debug builds?
[11:43] <zyga-ubuntu> mborzecki: I've seen the disabled message countless times
[11:43] <zyga-ubuntu> mborzecki: some messages are hardcoded and not formatted on the fly
[11:44] <mborzecki> 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] <mborzecki> popey got:
[11:44] <mborzecki> [alan@manjarovm ~]$ snap run brave
[11:44] <mborzecki> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory
[11:44] <mborzecki> and then when running with SNAP_CONFINE_DEBUG:
[11:44] <zyga-ubuntu> mborzecki: that particular one may be hardcoded
[11:45] <zyga-ubuntu> mborzecki: they look the same but come from different places
[11:45] <mborzecki> cannot perform operation: (disabled) use debug build to see details: No such file or directory
[11:45] <zyga-ubuntu> mborzecki: DEBUG: performing operation: (disabled) use debug build to see details
[11:45] <zyga-ubuntu> mborzecki: that's the disabled one
[11:45] <zyga-ubuntu> mborzecki: I still don't see what's wrong there
[11:46] <mborzecki> zyga-ubuntu: no SNAP_CONFINE_DEBUG, `cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory`
[11:46] <mborzecki> zyga-ubuntu: with SNAP_CONFINE_DEBUG `cannot perform operation: (disabled) use debug build to see details: No such file or directory`
[11:46] <mborzecki> same binary
[11:46] <zyga-ubuntu> mborzecki: devil is in the details :) but I see how this is confusing (for me too)
[11:46] <zyga-ubuntu> mborzecki: it depends on who prints what
[11:46] <zyga-ubuntu> mborzecki: anyway, I'll look again, thank you for explaining that
[11:48] <mborzecki> 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] <zyga-ubuntu> ohh
[11:49] <zyga-ubuntu> that's wrong
[11:49] <zyga-ubuntu> it should not be there
[11:49] <zyga-ubuntu> that whole thing should go away
[11:49] <zyga-ubuntu> ah
[11:49] <zyga-ubuntu> no
[11:49] <zyga-ubuntu> sorry
[11:49] <zyga-ubuntu>  :D
[11:50] <zyga-ubuntu> I just read the comment above it
[11:50] <zyga-ubuntu> sorry, my mind is rusty about this
[11:52] <mborzecki> 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] <mup> PR snapcraft#1831 closed: cli: add expiration option to export-login <enhancement> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1831>
[12:00] <mup> PR snapcraft#1849 closed: tests: add snap not found tests <codein> <Created by daniellimws> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1849>
[12:00]  * Chipakeitor looks takes careful aim at Chipaca
[12:00] <zyga-ubuntu> mborzecki: nice find!
[12:01] <Chipaca> mborzecki: i'm not sure i understand
[12:04] <niemeyer> mvo: On the second one, a typo and a suggestion
[12:04] <mvo> niemeyer: \o/ thank you
[12:04] <mborzecki> Chipaca: looking into it now, might be false positive
[12:05]  * zyga-ubuntu goes to cook something, ttyl
[12:05] <niemeyer> mvo: Thank you!
[12:05] <Chipaca> mborzecki: I don't mind making boltFinder embed a *bolt.DB instead of a bolt.DB if it makes the liter happy
[12:05] <Chipaca> linter*
[12:06] <mborzecki> Chipaca: i guess the tool cannot detect if the pool was used and raises a warning
[12:07] <Chipaca> mborzecki: and it's fair; there's no guarantee the DB didn't start a maintenance goroutine
[12:07] <mborzecki> then i think it's fair to embed *botl.DB rather than a copy
[12:08]  * Chipaca nods
[12:08] <Chipaca> thanks, metalinter! <plastic grin> <cut to commercial>
[12:25]  * Chipaca -> dentit
[12:42] <mup> PR snapd#4469 opened: tests: add hard-coded fully expired macaroons to run related tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4469>
[12:58] <Chipaca> i might be a few minutes late to the standup
[12:58]  * Chipaca returning from dentistist
[12:59] <mborzecki> gometalinter running from run-checks --static https://paste.ubuntu.com/26359996/
[13:07] <mup> PR snapd#4470 opened: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4470>
[13:36] <mup> PR snapcraft#1860 closed: setup: simplify bin/snapcraft and correct tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1860>
[13:40] <mvo> 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] <mup> PR snapcraft#1420: add new "no-wrapper" property to apps <enhancement> <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1420>
[13:47] <zyga-ubuntu> 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
[13:47]  * Chipaca looks
[13:53] <mup> PR snapd#4463 closed: client, daemon: update user's email when logging in with new account <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4463>
[13:55] <Chipaca> zyga-ubuntu: neat-o
[14:00]  * kalikiana going to have lunch, back in a bit
[14:01]  * pstolowski lunch
[14:01] <mup> PR snapd#4467 closed: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4467>
[14:02] <mup> PR snapd#4466 closed: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4466>
[14:02] <mup> PR snapd#4468 closed: cmd/snap-update-ns: we don't want to bind mount symlinks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4468>
[14:14] <jamesh> zyga-ubuntu: hi.  Yesterday you mentioned having a chat about user-mounts some time tomorrow  with niemeyer.  Should we set a time?
[14:15] <zyga-ubuntu> jamesh: hey, yes the plan is to do it tomorrow, you mentioned someting about your morning being preferred
[14:15] <zyga-ubuntu> let's look at the calendar now
[14:15] <jamesh> zyga-ubuntu: I thought my evening might be easier
[14:16] <zyga-ubuntu> ah I must have rembembered wrong then, sorry
[14:16] <jamesh> I think the biggest time difference is between WA and Brazil
[14:18] <mborzecki> off to pick up the kids
[14:18] <zyga-ubuntu> I wish google calendar could show the local time for each participant
[14:19] <zyga-ubuntu> jamesh: when it's 10AM here (CET+1) what is it for you?
[14:19] <Chipaca> zyga-ubuntu: i thought you were on CET
[14:20] <zyga-ubuntu> Chipaca: I never remember if its' CET or +1
[14:20] <zyga-ubuntu> Chipaca: DST and that
[14:20] <Chipaca> zyga-ubuntu: your DST is in march
[14:21] <Chipaca> starts in march, i mean
[14:21] <jamesh> zyga-ubuntu: WA is UTC+8, so 10AM in UTC+1 would be 5 PM
[14:21] <zyga-ubuntu> jamesh: that's reasonable for you I think
[14:22] <zyga-ubuntu> Chipaca: ah, I remembered UTC+1=CET, now it makes sense
[14:22] <zyga-ubuntu> jamesh: ok I think 10AM it is
[14:23] <jamesh> zyga-ubuntu: sounds great.
[14:23] <zyga-ubuntu> hmm, the new calendar has arrived
[14:24] <zyga-ubuntu> no idea how to add a hangout link
[14:24] <jamesh> zyga-ubuntu: maybe move it forward a day?
[14:25] <Chipaca> 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] <zyga-ubuntu> doh :D
[14:25] <jamesh> zyga-ubuntu: you've got it scheduled for 5 hours ago
[14:26] <zyga-ubuntu> sorry, the UI is totally confusing at first sight, I saw vertical stripes which I assumed were days, it's updated now
[14:26] <zyga-ubuntu> (it were people, not days)
[14:26] <sergiusens> mvo is your PR tagged with a greater number?
[14:27] <mvo> sergiusens: it says "milestone: 2.35"
[14:28] <zyga-ubuntu> jamesh: realistically I think we'll see a lot of mount features ladning next week
[14:28] <zyga-ubuntu> jamesh: I'm close to enabling layouts, the new content interface will likely land this week
[14:28] <mvo> sergiusens: hrm, but apparently I only have 2.34 - sorry, let me figure out where I can get 2.35
[14:28] <zyga-ubuntu> jamesh: your work is also looking very good
[14:29] <zyga-ubuntu> 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] <jamesh> zyga-ubuntu: If there is time, I'd also like to discuss how we could support the dbus app container socket feature
[14:30] <zyga-ubuntu> I'm not familiar with that, can you share a link so that I can prepare
[14:31] <jamesh> 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] <zyga-ubuntu> thank you, I'll read that today
[14:33] <jamesh> 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] <jamesh> since we'd want to inject a new unix socket
[14:34] <zyga-ubuntu> jamesh: do you have a specific plan (I haven't read everything yet)
[14:34] <zyga-ubuntu> jamesh: where would it be injected? into the per-user mount ns?
[14:35] <jamesh> zyga-ubuntu: no specific plan yet.  From that thread, I had some ideas that were shot down.
[14:35] <zyga-ubuntu> ok
[14:36] <jamesh> 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] <jamesh> zyga-ubuntu: It's less obvious what to do about the system bus
[14:37] <zyga-ubuntu> jamesh: do you see this as something apps can use transparently or will this be a transition that can break existing snaps?
[14:38] <jamesh> zyga-ubuntu: apps connect to whatever $DBUS_SESSION_BUS_ADDRESS tells them to connect to.
[14:38] <zyga-ubuntu> right but I presume the point of this exercise is to put something new at the other end
[14:38] <jamesh> zyga-ubuntu: this would mainly offer a way for unconfined trusted helpers to identify confined apps in a confinement system independent way
[14:38] <zyga-ubuntu> some proxy probably
[14:39] <jamesh> 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] <jamesh> 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] <zyga-ubuntu> jamesh: how does the container ID thing work?
[14:43] <jamesh> 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] <zyga-ubuntu> ah
[14:44] <zyga-ubuntu> cool
[14:44] <zyga-ubuntu> essentially a trusted way to introduce a new socket to dbus
[14:44] <zyga-ubuntu> is that shipping today?
[14:44] <zyga-ubuntu> (anywhere)
[14:45] <zyga-ubuntu> if we roll this out how hard will it be to push it to 14.04
[14:46] <jamesh> the initial work is in dbus master.  I don't think it's in bionic yet
[14:47] <jamesh> and some things are in flux
[14:47] <zyga-ubuntu> jamesh: do you see this as a feature we only enable on some releases/distros?
[14:47] <zyga-ubuntu> jamesh: and can we easily identify if dbusd has it?
[14:48] <jamesh> zyga-ubuntu: ideally I'd use it everywhere.  But it will need some kinks worked out
[14:49] <zyga-ubuntu> jamesh: but we cannot ship it to, say, fedora 26
[14:49] <jamesh> 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] <zyga-ubuntu> jamesh: I see, that is enough to identify I guess
[14:50] <jamesh> zyga-ubuntu: this isn't just a feature for snapd though.  It sounds like this is something flatpak wants too, which might help with getting the patches out
[14:51] <zyga-ubuntu> jamesh: indeed, especially since otherise, my understanding is that dbus filtering in selinux and flatpak in general is not very rich
[14:51] <jamesh> zyga-ubuntu: I'd like to have some plans about how we'll handle it early, rather than waiting and have it solidify in a form that works for flatpak but is unusable to us
[14:52] <zyga-ubuntu> (not at all available in flatpak)
[14:52] <jamesh> zyga-ubuntu: flatpak currently uses a dbus proxy to do its filtering, so this feature lets them get rid of that
[14:53] <zyga-ubuntu> ah, I see
[14:53] <zyga-ubuntu> is the new ACL language something you see us adopt in snapd? another securty backend (perhaps part of the existing dbus backend)
[14:53] <jamesh> zyga-ubuntu: I believe we can mostly ignore the filtering side by installing a wide open ACL and continue to rely on the LSM hooks
[14:53] <zyga-ubuntu> is there any advantage for us to use it as compared to apparmor
[14:53] <zyga-ubuntu> jamesh: it could boost our cross distro support
[14:54] <zyga-ubuntu> jamesh: I wonder if the language is similar enough to let us generate appropriate things automatically
[14:54] <zyga-ubuntu> either ACLs for dbus-daemon or apparmor profiles
[14:54] <jamesh> zyga-ubuntu: there are things that dbus's filtering could help us with.  For instance, dbus won't let a process see bus names its ACL doesn't allow
[14:55] <jamesh> so there could be room for us to include some filtering there.
[14:56] <elopio> sergiusens: that ant test takes here 3 minutes.
[14:57] <popey> sergiusens: how can I "unrelease" a snap using snapcraft?
[14:58] <popey> I need to pull a specific revision from the store. Not all, just one.
[14:58] <jamesh> zyga-ubuntu: the upstream info about the ACL language is here: https://bugs.freedesktop.org/show_bug.cgi?id=101902 -- I've made some comments there about what I think I'd need (mainly a way to replace the base ACL after the container was created)
[14:59] <jamesh> zyga-ubuntu: anyway. It's late here, so I'll talk to you tomorrow.
[14:59] <zyga-ubuntu> jamesh: certainly, thank you for keeping me int the loop! very interesting things
[15:06] <kalikiana> re
[15:12] <sergiusens> popey I think that would be accomplished by a  release of the previous revision
[15:12] <popey> sergiusens: nope, I don't want it released
[15:12] <popey> I want to *un* release it, not revert it
[15:12] <sergiusens> We don't have API semantics for unrelease
[15:12] <sergiusens> close the channel?
[15:12] <popey> nope
[15:12] <popey> I want to unrelease one arch
[15:13] <popey> one revision
[15:13] <popey> not the entire application/channel
[15:13] <popey> I'll file a bug if we don't have a way to do it.
[15:13] <sergiusens> popey I don't think you can and I am not aware of an API that would allow us to do so
[15:13] <popey> ok, ta :)
[15:13] <sergiusens> noise][ ideas ^
[15:15] <noise][> yeah, i don't think we currently cover that use case
[15:16] <popey> https://bugs.launchpad.net/snapstore/+bug/1742464  here you go then :)
[15:16] <mup> Bug #1742464: Not obvious how to 'un-release' a revision <Snapcraft:New> <Snap Store:New> <https://launchpad.net/bugs/1742464>
[15:16] <noise][> thx popey
[15:17] <popey> noise][: is there some way a store person can ninja this?
[15:21] <mup> PR snapd#4470 closed: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4470>
[15:22] <sergiusens> elopio hey, about those tests, try with my branch as it does a lot more crawling on files
[15:23] <elopio> sergiusens: ack.
[15:34] <noise][> popey: ping in #snapstore, probably can work something out
[15:36] <popey> ok
[15:39] <mup> PR snapd#4465 closed: cmd/snap-update-ns: new test features <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4465>
[15:45] <zyga-ubuntu> Chipaca: FYI https://github.com/snapcore/snapd/pull/4464/files#r160714920
[15:45] <mup> PR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>
[15:45] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4471
[15:45] <mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[15:46] <mup> PR snapd#4471 opened: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[15:46] <zyga-ubuntu> mvo: that's the essence of the PR we spoke about in the morning
[15:46] <zyga-ubuntu> mvo: everything else are just extra tests added on top
[15:47] <Chipaca> hmmm
[15:47] <Chipaca> zyga-ubuntu: cannot snap-exec: cannot exec "/snap/snap-hooks/x1/true": exec format error
[15:47] <Chipaca> zyga-ubuntu: i suspect there's a trivial case not accounted for somewhere :-)
[15:48] <Chipaca> zyga-ubuntu: the trivial /bin/true is an empty file with the executable bit set
[15:48] <Chipaca> zyga-ubuntu: looks like we don't support that :-)
[15:48] <zyga-ubuntu> Chipaca: that's odd, it should be done by the kernel
[15:48] <zyga-ubuntu> the kernel should invoke /bin/sh
[15:48] <zyga-ubuntu> anyway
[15:49] <flexiondotorg> apol: Welcome!
[15:49] <zyga-ubuntu> Chipaca: can you please look at 4471, just some sanity review on the structure of changePerform
[15:49] <apol> o/
[15:49] <Chipaca> zyga-ubuntu: in a mo'
[15:49] <zyga-ubuntu> Chipaca: I tried hard to make that sane but then ran into a but that caused some extra logic in unexpected places
[15:49] <zyga-ubuntu> Chipaca: sure, thank you!
[15:53] <Chipaca> hmmmmmm
[15:53] <zyga-ubuntu> mm?
[15:54] <Chipaca> zyga-ubuntu: is the way snap-exec interprets commands intentional? documented?
[15:54] <zyga-ubuntu> Chipaca: haha, no
[15:54] <zyga-ubuntu> Chipaca: probably just an evolutionary result of hacking
[15:54] <Chipaca> zyga-ubuntu: in particular the way it interpolates variables (i think?) and splits on spaces
[15:54] <Chipaca> (it might not be the one doing the interpolation)
[15:54] <zyga-ubuntu> "we require more bugfixes" with the starcraft 2 voice
[15:56] <Chipaca> yes it is snap-exec doing the whole thing
[15:56] <mup> PR snapd#4472 opened: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
[15:57] <pstolowski> niemeyer, dang, re plug/slot.DynamicAttrs(), I can get rid of it in policy, and that eliminates one use case, but I've two more uses cases that are slightly problematic (but i've an idea); do you have a moment to discuss before I dive into changing it?
[15:59] <Chipaca> zyga-ubuntu: https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L178 :-)
[15:59] <niemeyer> pstolowski: Sure
[16:00] <zyga-ubuntu> Chipaca: not sure what to think about it
[16:00] <Chipaca> zyga-ubuntu: 's fine
[16:00] <Chipaca> zyga-ubuntu: i just need to handle it in the validator as well :-)
[16:02] <pstolowski> niemeyer, standup ho?
[16:03] <niemeyer> pstolowski: On my way
[16:06] <mup> PR snapd#4473 opened: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4473>
[16:06] <mvo> zyga-ubuntu: thanks sorry was distracted mostly by spectre and a bit by the recent pr
[16:07] <zyga-ubuntu> mvo: sure, no worries :) anything new about spectre?
[16:08] <mvo> zyga-ubuntu: we have an updated kernel snap
[16:08] <mvo> zyga-ubuntu: for meltdown, I asked slangasek to build a new image for release.u.c - but there is more work to do
[16:10] <zyga-ubuntu> mvo: the image is for everything? AFAIK the pi is not affected
[16:10] <mvo> zyga-ubuntu: thats up to steve, we need an update to at least i386/amd64
[16:11] <zyga-ubuntu> and then the clouds reboot
[16:22] <roadmr> hey folks is jdstran-d on vacation maybe?
[16:26] <kalikiana> kyrofa: Arg, just noticed I hadn't finished my commit for snapcraft#1857 ... pushed it now. Please let me know if you like the revised way of testing. Or if it needs more discussion
[16:26] <mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
[16:26] <mvo> roadmr: yeah, he is on vac
[16:26] <roadmr> mvo: ok, thanks :)
[16:28] <Chipaca> zyga-ubuntu: which was the pr you wanted me to shake a stick at?
[16:30] <Chipaca> roadmr: and there are photos to prove it
[16:35] <brunosfer> Hi guys, I'm trying to make a go application to further embed in a snap. However I do need to know in Go how can I get the list from the snaps installed without throwing a command such as "snap list" and then parse the info.
[16:36] <Chipaca> brunosfer: you want a snap that can list snaps?
[16:36] <nacc> brunosfer: or are you trying to depend on other snaps?
[16:42] <zyga-ubuntu> re, sorry was paying taxes
[16:42] <zyga-ubuntu> Chipaca: the one that makes changePerform do magic...
[16:42] <brunosfer> I wanted to reuse the code that exists in the cmd_lists.go to retrieve the list of snaps
[16:42] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4471
[16:42] <mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[16:43] <zyga-ubuntu> brunosfer: I don't know if you can access that from a snap
[16:43] <brunosfer> but since that code is private, I will use the cmd line and parse the output with awk and so on...
[16:43] <zyga-ubuntu> brunosfer: you cannot run "snap" from your snap
[16:43] <zyga-ubuntu> brunosfer: or it won't do what you would normally be allowed to do
[16:44] <brunosfer> zyga-ubuntu: yeah, I just got that now after reaind the source code...
[16:44] <zyga-ubuntu> roadmr: hey, yes, he's off all week AFAIK
[16:44] <Chipaca> brunosfer: sorry to intrude, but why do you want to list the snaps installed?
[16:46] <zyga-ubuntu> Chipaca: actually reading my own diff I see some of the comments are stale
[16:46] <zyga-ubuntu> Chipaca: and could use some facelift
[16:47] <brunosfer> Chipaca: because I want to check if they need updates with no internet available.
[16:48] <Chipaca> brunosfer: there are (privileged) interfaces that let you query the snapd api directly
[16:48] <zyga-ubuntu> brunosfer: are you writing some management software? typically snapd does that
[16:48] <brunosfer> Chipaca: what are the interfaces?
[16:48] <Chipaca> brunosfer: so if your snap has snapd-control, you can talk to snapd and ask it (if your lcient is go, you could use the code in client/)
[16:49] <Chipaca> brunosfer: snapd-control is the name of the interface that gives your snap that permission
[16:49] <Chipaca> brunosfer: if you want to see what's available, one tool i found very useful is the 'http' snap
[16:49] <brunosfer> Chipaca: Thank you very much, I will give a look to that.
[16:49] <Chipaca> brunosfer: the http snap has snapd-control, so it can talk to snapd, and
[16:49] <brunosfer> Chipaca: I already used the HTTP Flag, but that's for REST requests to the API
[16:50] <Chipaca> brunosfer: http snapd:////v2/snaps
[16:50] <Chipaca> brunosfer: lists all the snaps installed
[16:50] <brunosfer> Chipaca: Awesome. I will check that out
[16:50] <zyga-ubuntu> good luck :)
[16:50] <brunosfer> Chipaca: Thanks!
[16:50] <Chipaca> brunosfer: i don't know what "HTTP Flag" is, but good luck :-)
[16:50] <brunosfer> zyga-ubuntu: Thanks!
[16:57] <zyga-ubuntu> Chipaca: the PR goes in tandem with this one https://github.com/snapcore/snapd/pull/4472
[16:57] <mup> PR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
[16:57] <zyga-ubuntu> it's a tiny tiny diff that shows you what's new
[16:58] <brunosfer> Chipaca: I was talking about this "sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 /usr/lib/snapd/snapd"
[16:58] <Chipaca> ah :) yes
[17:00] <Chipaca> zyga-ubuntu: given your comments about the comments, should i wait before looking at 4471?
[17:01] <zyga-ubuntu> Chipaca: no, they are not that wrong
[17:01] <zyga-ubuntu> just a bit weirdly worded
[17:01] <zyga-ubuntu> Chipaca: and I'm on a clock
[17:02] <zyga-ubuntu> Chipaca: this cannot be proposed yet but a spread test for this is here; https://github.com/zyga/snapd/commit/617739eee69faf483dee8cad3ae241a1c5b08b57
[17:14]  * kalikiana calling it a day
[17:22] <brunosfer> Chipaca: Do you know how can I query directly the API locally?
[17:23] <Chipaca> brunosfer: it depends exactly what you mean by 'directly' and 'locally' :-)
[17:23] <Chipaca> brunosfer: from inside the snap?
[17:23] <Chipaca> brunosfer: or do you mean from a script?
[17:24] <zyga-ubuntu> brunosfer: talk to the same socket, if you have the right interface it can be done from the snap
[17:24] <zyga-ubuntu> brunosfer: if not you need to be unconfined (outside)
[17:24] <zyga-ubuntu> brunosfer: but should be enough to let you code
[17:26] <brunosfer> right now I'm doing it in golang but the idea is to make a snap out of it, so I would need to make my yaml file with those previledges, but I'm also quite noob in Go as well as in the Snaps =P
[17:27] <zyga-ubuntu> brunosfer: you cannot grant the permission yourself, the interface that you'd have to request is sensitive, it would have to be a decision agreed upon in the forum and reviewed by the security team
[17:27] <brunosfer> Chipaca: And what do you mean by priviledged? --devmode?
[17:28] <zyga-ubuntu> brunosfer: some interfaces can be accessed instantly as they are considered safe
[17:28] <zyga-ubuntu> brunosfer: but with this interface you can equally remove and install snaps
[17:29] <Chipaca> brunosfer: i'm sorry if i'm not fully following what you need
[17:30] <Chipaca> brunosfer: curl -s --unix-socket /run/snapd.socket http://localhost/v2/snaps
[17:30] <Chipaca> brunosfer: ^ is that what you're asking?
[17:31] <pedronis> mvo: test lxd seems to have failed here:  https://travis-ci.org/snapcore/snapd/builds/327212657?utm_source=github_status&utm_medium=notification
[17:38] <brunosfer> Chipaca: That's exactly what I was looking for! Perfect answer! Thank you so much for the command line. It works perfectly.
[17:38] <brunosfer> Chipaca: But for me to perform that command line do I need to have a special permission? Using it from my snap?
[17:39] <Chipaca> brunosfer: yes, the snap needs snapd-control to accss the socket
[17:40] <brunosfer> Chipaca: That's perfect. You helped me a lot ;)
[17:46] <mvo> pedronis: hm, you restarted by now I guess? was it just a slow download? that happens sometimes unfortunately
[17:56] <popey> flexiondotorg: https://bugs.launchpad.net/snapcraft/+bug/1742504
[17:56] <mup> Bug #1742504: magic.mgc, 1: Warning: offset `' invalid <Snapcraft:New> <https://launchpad.net/bugs/1742504>
[17:57] <popey> kyrofa: ^ New and interesting ways to break snapcraft
[17:57] <kyrofa> Oh how fun!
[17:57] <kyrofa> Oh dang
[17:58] <kyrofa> popey, and that didn't happen in 2.35?
[17:58] <popey> nope
[17:58] <popey> flexiondotorg: just hit the same
[17:58] <popey> he's in an i386 vm, I'm on an i386 VPS
[17:58] <kyrofa> popey, you didn't read the changelog? Snapcraft does abstract art now. It's a feature
[17:58] <popey> lulz
[17:58] <popey> Nice try!
[17:58] <flexiondotorg> I'm running snapcraft from the beta channel on a i386 VM.
[17:58] <flexiondotorg> Same issue.
[17:59] <kyrofa> i386, huh?
[17:59] <kyrofa> Have either of you tried on amd64?
[17:59] <flexiondotorg> Doesn't happend of metal amd64.
[18:00] <popey> lemme switch my amd64 laptop to beta to reproduce
[18:01] <popey> oooh
[18:01] <popey> got it to do it and not screw fonts up
[18:02] <popey> so i have a readable stacktrace now
[18:03] <popey> kyrofa: there you go, comment #2
[18:05] <kyrofa> popey, any chance the snap you're building is public so I can poke at what's happening there?
[18:05] <popey> I'll attach the yaml
[18:07] <popey> kyrofa: attached, and had the same issue on armhf and not amd64
[18:07] <popey> You're wecome! :D
[18:07] <kyrofa> Thank you! We'll have a look
[18:10] <Chipaca> santa cachucha, so many special cases
[18:10] <flexiondotorg> Looks like elf patching is not working on 32-bit binaries.
[18:13] <popey> Looks like we need more test cases on more architectures! :D
[18:15] <ogra> or just drop support for some :P
[18:15] <flexiondotorg> Yeah, armhf ;-)
[18:16] <ogra> booo
[18:17] <Chipaca> let's drop armel and nubus-ppc
[18:19] <kyrofa> popey, flexiondotorg we have test cases on other arches, but they're adt
[18:20] <lundmar> so, the build.snapcraft.io is currently down?
[18:20]  * zyga-ubuntu looks at slashdot story
[18:20] <zyga-ubuntu> https://news.slashdot.org/story/18/01/10/1634215/meltdown-and-spectre-patches-bricking-ubuntu-1604-computers
[18:22] <mup> PR snapcraft#1810 closed: [WIP] i18n support <Created by m4sk1n> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1810>
[18:22] <lundmar> man, for some work loads the performance degradation of spectre/meltdown fix is quite a blow.
[18:25] <cwayne> zyga-ubuntu: that's fixed with -109 which is already out
[18:25] <zyga-ubuntu> yeah, I read that
[18:25] <zyga-ubuntu> just was caught by the headline
[18:25] <roadmr> zyga-ubuntu: "bricking" should not be used to mean "left unbootable and needing recovery and/or factory reset". Bricking means "it became a useless brick and had to be thrown into trash"
[18:25] <zyga-ubuntu> lundmar: can you elaborate please? I'm curious
[18:26] <roadmr> also hi :)
[18:26] <zyga-ubuntu> roadmr: yeah, it's just clickbait journalism
[18:26] <sergiusens> kyrofa popey if it is magic that is breaking I think I can fix that
[18:26] <roadmr> zyga-ubuntu: well I've seen "bricking" used to mean a recoverable situation very frequently. I think people are just confused and/or have never actually had a bricked device
[18:26] <lundmar> zyga-ubuntu: some workloads seem to degrade by as much as ~30%
[18:26] <kyrofa> sergiusens, yeah, seems so
[18:26] <roadmr> zyga-ubuntu: but anyway I'm just whining :)
[18:27] <zyga-ubuntu> roadmr: hey, that's my spare time activity ;)
[18:27] <sergiusens> kyrofa might as well get rid of magic completely, that python module is a mess
[18:27] <kyrofa> sergiusens, can we? It's always so hard to find documentation for it as well
[18:27] <sergiusens> I wish we could also get rid of python-apt, that would also be a blessing :-)
[18:27] <sergiusens> kyrofa yes, I will replace it with readelf, then it is also one call
[18:28] <lundmar> zyga-ubuntu: you might find this interesting: https://www.phoronix.com/scan.php?page=news_item&px=KPTI-Retpoline-Combined-Ubuntu
[18:29] <lundmar> anyone know what is going on with build.snapcraft.io - it seems to be down but https://status.snapcraft.io is all green?
[18:30] <kyrofa> lundmar, yeah, the build farm is down pending mitigation for meltdown/specre
[18:30] <kyrofa> noise][, were you going to put something about that on status.snapcraft.io?
[18:30] <lundmar> the status page should show red then :)
[18:31] <kyrofa> No argument from me. I sent an email about this last week
[18:32] <noise][> sorry, we added a notice in the Incident History on status.snapcraft.io and it was pinned to the top for a time but has now drifted down
[18:32] <lundmar> it's been down for a while? I only just noticed.
[18:33] <kyrofa> lundmar, about a week now
[18:33] <lundmar> ok
[18:33] <lundmar> hopefully it will be up again soon
[18:33] <kyrofa> lundmar, https://twitter.com/launchpadstatus/status/948688233029881856
[18:33] <kyrofa> My hope as well
[18:33] <kyrofa> Mitigations started rolling last night, so I expect it to come back up any time
[18:34] <lundmar> great
[18:34] <noise][> yes, hopefully all back over the next 2 days
[18:34] <lundmar> this whole spectre thing is quite a big deal - amazing such a simple mechanism has gone unnoticed until now.
[18:34] <kyrofa> noise][, I kinda feel like something should be big and red, there
[18:35] <kyrofa> build.snapcraft.io is a pretty decent thing that we should consider tracking there
[18:35] <noise][> for various reasons we don't have access to check the status of the actual build farm in that status dashboard
[18:35] <noise][> just that the store side and build.snapcraft.io website are up
[18:36] <kyrofa> Even just something that could be toggled by hand, seeing that we know the build farm is down would be handy
[18:36] <noise][> well that was the incident notice, which i will re-pin now
[18:37] <kyrofa> noise][, I doubt people will scroll down that far once they see everything is green
[18:37] <kyrofa> Just sayin
[18:37] <lundmar> I almst missed the pinned incident pop up notice.
[18:37] <lundmar> almost*
[18:51] <zyga-ubuntu> I'm a bit exhausted, time to sleep
[18:52] <zyga-ubuntu> I'll wake up earlier tomorrow
[19:04] <mup> PR snapcraft#1862 opened: zip: support extracting non-unix zip files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1862>
[19:04] <kyrofa> sergiusens, that's for you ^^
[19:06] <sergiusens> actually for ogra ^ ;-)
[19:06] <kyrofa> Ha!
[19:07] <ogra> well, i'm also just proxying
[19:07] <sergiusens> ogra if you want to give the snap a spin, go to the travis build and search for the transfer.sh file upload ;-)
[19:07] <ogra> it is for that mythical "customer" guy :)
[19:10] <kyrofa> Yeah, like to keep those happy and non-mythical
[19:14] <sergiusens> kyrofa btw, was snapcraft#1639 supposed to be approved?
[19:14] <mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
[19:15] <kyrofa> sergiusens, I'm re-reviewing now. elopio and I didn't like the tests, but kalikiana's fix for that seemed to introduce weird test problems
[19:15] <kyrofa> sergiusens, so the tests have been reverted
[19:16] <kyrofa> I'm kinda meh on the tests. I'd rather see real integration test snaps like we do for the other pieces of the grammar
[19:17] <kyrofa> But in the interest of time they may be okay
[19:32] <sergiusens> kyrofa if they are not good, then they are not good.
[19:33] <sergiusens> kyrofa what about snapcraft#1857 ?
[19:33] <mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
[19:33] <kyrofa> sergiusens, it's next on my queue
[19:34] <kyrofa> Had some testing questions there on the last pass
[19:36] <kyrofa> elopio, what are your thoughts on snapcraft#1639? Do you like that better than putting more snaps in tests/integration/snaps ?
[19:36] <mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
[20:00] <popey> sergiusens: yay!
[20:29] <kyrofa> sergiusens, while I'll pass snapcraft#1639 assuming elopio is okay with it, snapcraft#1857's tests aren't right yet
[20:29] <mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
[20:29] <mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
[20:29] <kyrofa> Should be an easy change though, hopefully
[20:56] <sergiusens> kyrofa so now only snapcraft#1853 is left?
[20:56] <mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
[20:58] <kyrofa> Yep
[20:59] <elopio> kyrofa: yes, I think we have too many snaps in tests/integration/snaps
[20:59] <kyrofa> sergiusens, although we should consider snapcraft#1861 as well
[20:59] <mup> PR snapcraft#1861: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861>
[21:00] <elopio> I'm ok with the tests. Not super happy, but I think we can later make a better filter of the ones that require to be in snaps. And get all the others to consistently use the fixture
[21:01] <kyrofa> elopio, sounds good
[21:41] <sergiusens> elopio kyrofa fwiw I am seriously considering removing the buffering and let tests print everything they need to
[21:42] <kyrofa> sergiusens, we kinda tried that already, things slow waaay down
[21:42] <sergiusens> kyrofa not for unit, for integration
[21:42] <sergiusens> I don't like the current travis hack I had to do
[21:42] <kyrofa> sergiusens, yeah, that's what I'm talking about. Let me find the PR...
[21:43] <sergiusens> oh, bummer :-/
[21:43] <sergiusens> ok, for the past to months every other week we've had to stop and deal with something new with travis; let's consider some alternatives
[21:44] <kyrofa> sergiusens, oh wait, nevermind-- things might slow down a little, but we closed it because it ended up not being necessary for what we were doing. You might like it: https://github.com/snapcore/snapcraft/pull/1591
[21:44] <mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[21:44] <kyrofa> sergiusens, that's just a subset of the integration tests, but you get the idea
[21:46] <kyrofa> I wonder how hard it would be to port to circle CI. They seem to innovate faster, and have longer runtimes
[21:46] <kyrofa> Oh wait, no-- you only get one instance. Nevermind
[21:46] <kyrofa> That'll slow things down
[21:47] <sergiusens> kyrofa so, instead of printing to stdout/stderr we opted to just skip the test? :-/
[21:47] <sergiusens> kyrofa we are at a point where if we do not print we need to skip all the tests
[21:47] <kyrofa> Hahahaha
[21:48] <kyrofa> It wasn't an "instead" so much as a "well, that didn't actually help us solve the problem"
[21:48] <kyrofa> We thought the issue was that travis was timing out before we could print, but once we fixed that the test still took waaay to long to be in the suite
[21:49] <kyrofa> But I agree that printing would be useful as long as we didn't suffer too much of a slowdown
[21:53] <mup> PR snapcraft#1639 closed: grammar: to statement <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1639>
[21:56] <mup> PR snapcraft#1861 closed: extractors: also support appdata.xml appstream files <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1861>
[22:04] <sergiusens> elopio you now have conflicts
[22:05] <sergiusens> kyrofa we should print a `.` for every line of progress or something like that
[22:05] <sergiusens> kyrofa I still think we need to migrate away from travis, the free tier isn't cutting it
[22:06] <kyrofa> sergiusens, then I only see two options: non-free tier, or self-hosting
[22:06] <kyrofa> (which is also non-free)
[22:06] <sergiusens> kyrofa yeah we will probably go back to adt
[22:16] <kyrofa> elopio, one more comment on snapcraft#1853, but I suspect it's good
[22:16] <mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
[22:20] <elopio> kyrofa!
[22:20] <elopio> sorry
[22:21] <elopio> kyrofa: so are you OK with every get to return Union[str, List[str]]?
[22:22] <elopio> It's easy to change, just want to double check I got your comment
[22:26] <kyrofa> elopio, seems better than Any
[22:26] <kyrofa> elopio, note that mypy will barf if you end up handing it off to something that expects a str though, so you can cast if you know for sure it is (and need it to be)
[22:44] <popey> kyrofa: for some reason I picked up from a thread on the forum that $SNAP_ARCH_TRIPLET was a thing I could use in environment:
[22:44] <popey> kyrofa: seems not :(
[22:44] <popey> Any plan to add it, so we don't have to add if elif elif elif else fi nonsense?
[22:44] <kyrofa> popey, SNAPCRAFT_ARCH_TRIPLET, and only in 2.36 and later
[22:44] <popey> oh!
[22:45] <popey> in environment?
[22:45] <popey> e.g. if I have an environment setup for a command, will snapcraft fill it in at build time?
[22:46] <kyrofa> popey, I'm not 100% sure what you're asking, but it's like SNAPCRAFT_PART_INSTALL if you've used that
[22:46] <kyrofa> It is an environment variable
[22:46] <popey> but it's an environment varibale at snapcraft runtime, not snap runtime
[22:47] <popey> so for example if i have a command that needs a path set to a lib directory, setting environment: PATH: "$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/foo" gonna work?
[22:49] <kyrofa> popey, ahh, right, I see where you're coming from now
[22:49] <kyrofa> popey, no, that won't work
[22:50] <popey> :(
[22:50] <popey> I end up needing 3 yamls, one per arch
[22:50] <kyrofa> popey, I really wish snapd would add that, but I added a remote part for it if you want to use that instead
[22:50] <popey> yeah, i found that :)
[22:50] <kyrofa> THAT will give you SNAP_ARCH_TRIPLET
[22:51] <kyrofa> popey, and it literally just does the elif elif elif vi nonsense for you :P
[22:52] <kyrofa> Huh. I type that command too much
[22:52] <popey> :D
[22:53] <kyrofa> So yeah, you can use SNAPCRAFT_ARCH_TRIPLET at snap build time, but at runtime all snapd gives you is SNAP_ARCH, so you either need to write the elif stuff or use that remote part
[22:53] <popey> This feels like it needs a bug
[22:54] <popey> having a bunch of shell script attached to a hundred snaps makes no sense
[22:54] <kyrofa> I could have sworn we had one against snapd at some point, but I suspect it was lost between snappy/snapd/etc.
[22:54] <kyrofa> I agree
[22:54]  * popey files
[22:56] <kyrofa> popey, sorry I got your hopes up. I pictured your childish joy at learning this was possible only to have crushed it
[22:56] <popey> hahah
[22:56] <kyrofa> er, childlike is probably what I wanted there
[22:58] <popey> https://bugs.launchpad.net/snapd/+bug/1742565
[22:58] <mup> Bug #1742565: snapd should provide SNAP_ARCH_TRIPLET <snapd:New> <https://launchpad.net/bugs/1742565>
[23:20] <popey> kyrofa: snapcraft really craps the bed if you switch from beta to stable
[23:20] <popey> i.e. from 2.38 back to 2.35
[23:20] <kyrofa> popey, because of the state tracking?
[23:21] <kyrofa> Yeah, that was written well before snaps were a possibility. We should start accounting for that
[23:21] <popey> https://paste.ubuntu.com/26363030/
[23:21] <kyrofa> Handle it well, say 'hey yo, I don't recognize this state stuff at all. Clean, man."
[23:22] <popey> i have no idea what to do at this point ^
[23:22] <kyrofa> popey, wait, that's different
[23:22] <kyrofa> popey, are you on i386 again?
[23:22] <popey> yes, same on armhf
[23:22] <kyrofa> stable channel?
[23:22] <popey> yes
[23:23] <popey> i reverted back from beta to stable to rebuild something and avoid the magic bug from earlier
[23:23] <kyrofa> popey, https://bugs.launchpad.net/snapcraft/+bug/1733922
[23:23] <mup> Bug #1733922: “snapcraft init” crashes on 32-bit Ubuntu <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1733922>
[23:23] <kyrofa> popey, the fix is in 2.36, I'm afraid
[23:23] <popey> uhm
[23:24] <kyrofa> That never made it to stable
[23:24] <popey> so 2.35 is broken, 2.36 is fixed (but never released) and 2.38 (released) is broken.
[23:24] <popey> Which version should I use? :)
[23:24] <kyrofa> popey, hold on, let me give you 2.36
[23:25] <popey> i wonder if I can refresh --revision?
[23:25] <kyrofa> popey, you're not a collaborator. But you don't need to be, I'll make a hotfix channel for ya
[23:25] <popey> oh, i dont think you need to be a collaborator to --revision ninja
[23:25] <popey> I did this earlier with another snap ;)
[23:26] <kyrofa> Hmm, okay. I thought that was the idea, anyway
[23:26] <kyrofa> popey, you're on armhf? Try rev 878
[23:27] <kyrofa> popey, let me know if it doesn't work and I'll create a hotfix
[23:27] <popey> it wont let me
[23:27] <kyrofa> Oh good, I'm not insane
[23:27] <popey> i think the deb works
[23:27] <popey> (I used the deb earlier successfully, but only moved to snap to test some of these environment variables)
[23:28] <kyrofa> Indeed, the deb should work for that bug anyway
[23:28] <popey> ok, lemme test that
[23:33] <kyrofa> popey, feel free to use the edge/2-36 channel as well, if you like
[23:33] <popey> thanks
[23:33] <popey> they're all building now
[23:35] <kyrofa> popey, edge/2-37 is open as well, if you find you need it
[23:35] <popey> you're a star
[23:35] <kyrofa> Remember they only live for a month, but easy to re-create if necessary
[23:46] <popey> I'm sure all the bugs will be fixed in a month, so won't need it ;)