[05:55] <mborzecki> morning
[06:56] <mup> PR snapcraft#1852 opened: Added a missing step in Hacking.md <Created by Tanesh1701> <https://github.com/snapcore/snapcraft/pull/1852>
[07:40] <zyga-ubuntu> o/
[07:41] <mvo> hey zyga-ubuntu, good monring
[07:41] <zyga-ubuntu> hey :)
[07:44] <mup> PR core#68 closed: hooks: fix shellcheck complains <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/68>
[07:47] <mborzecki> zyga-ubuntu: mvo: morning guys
[07:50] <zyga-ubuntu> good morning
[07:51] <kalikiana> morning, zyga-ubuntu
[07:51] <zyga-ubuntu> hey :)
[07:51]  * zyga-ubuntu had a fsck-initramfs-based-morning 
[07:52] <zyga-ubuntu> but all is good now, I hope
[07:52] <kalikiana> not how you wanna start your day... :-(
[07:53] <mup> PR snapd#4449 opened: 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>
[07:53] <mvo> hey mborzecki - good morning and good morning kalikiana
[07:53] <mborzecki> kalikiana: morning
[07:53] <kalikiana> mborzecki: mvo o/
[07:54] <zyga-ubuntu> gconstpointer ?
[07:54] <zyga-ubuntu> why do we need that over, apparently, bool?
[07:55] <zyga-ubuntu> ah, could be the limitation of the test protocol
[07:55] <mborzecki> zyga-ubuntu: just following gtest declarations and didn't want the compiler to scream at me
[07:56] <zyga-ubuntu> I think I would have preferred a debug library but this change is smaller, +1
[07:58] <mborzecki> zyga-ubuntu: thanks
[08:09] <mborzecki> zyga-ubuntu: have you seen this? https://forum.snapcraft.io/t/on-arch-snaps-show-broken-after-switch-from-snapd-to-snapd-git/3427/4
[08:09] <mborzecki> pstolowski: morning
[08:10] <zyga-ubuntu> mborzecki: no, I just had a look now - my bet is it's a mount from some directory that dones't exist on arch in default install, maybe /usr/src or something like
[08:10] <zyga-ubuntu> ...that
[08:11] <zyga-ubuntu> if you can strace it you will get the answer
[08:12] <zyga-ubuntu> mborzecki: btw, does it work for you?
[08:12] <mborzecki> zyga-ubuntu: hm but what fails is: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory
[08:12] <zyga-ubuntu> mborzecki: or also no?
[08:12] <mborzecki> yes, it does
[08:12] <zyga-ubuntu> that's odd, is the source/target present?
[08:12] <mborzecki> it would be off for /dev not to exist
[08:13] <mborzecki> lookign at snap-confine source code, we create the destination directory
[08:14] <mborzecki> aah, w8, we create the destination only it's it's bidirectional
[08:17] <mup> PR snapcraft#1853 opened: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
[08:18] <zyga-ubuntu> hmm
[08:19] <zyga-ubuntu> that feels like a bug
[08:19] <zyga-ubuntu> but
[08:19] <zyga-ubuntu> .. /dev should be in the core snap
[08:19] <mvo> zyga-ubuntu: it is
[08:21] <haisheng-from-ch> Hi, I met a question about snapd. I make a pc.img which use ubuntu-img command. But when i log into the system. the snap can't mount, ant the syslog print:'Jan  5 08:10:49 localhost snapd[889]: 2018/01/05 08:10:49.391477 stateengine.go:101: state ensure error: devicemgr: cannot mark boot successful: cannot determine bootloader' many times. what should i do. Thanks.
[08:24] <zyga-ubuntu> haisheng-from-ch: hey, which gadget/kernel/model did you use?
[08:25] <haisheng-from-ch> also when start the system . the screen print 'Mounting Mount unit for core.Mounted Mount unit for core. Unmounted Mount unit for core. ' many times.
[08:25] <mborzecki> i'll try to spin a manjaro vm locally and check what's happenning there
[08:26] <ackkk> mvo, hi! wrt that changes to base-18 you made on Fri, are they available in the latest build yet?
[08:27] <mvo> ackk: I checked https://code.launchpad.net/~mvo/+snap/base-18 this morning - and it still has not build :( so we probably need to ask in #launchpad what is going on
[08:27] <ackk> I guess the few builders availble are hammered
[08:29] <zyga-ubuntu> ackk: what's wrong with the build farm?
[08:30] <haisheng-from-ch> kernel is 1604. gadget is the sample which provided in website.the model is customized by myself.
[08:31] <haisheng-from-ch> the model is '{
[08:31] <haisheng-from-ch>   "type": "model",
[08:31] <haisheng-from-ch>   "authority-id": "9go0hDakgpo17fYGy06ZguLT8Ly0Ma9F",
[08:31] <haisheng-from-ch>   "brand-id": "9go0hDakgpo17fYGy06ZguLT8Ly0Ma9F",
[08:31] <haisheng-from-ch>   "series": "16",
[08:31] <haisheng-from-ch>   "model": "kylin-test",
[08:31] <haisheng-from-ch>   "architecture": "amd64",
[08:31] <haisheng-from-ch>   "gadget": "kylin-gadget",
[08:31] <haisheng-from-ch>   "kernel": "pc-kernel",
[08:31] <haisheng-from-ch>   "timestamp": "2018-01-08T06:23:22+00:00"
[08:31] <haisheng-from-ch> }
[08:31] <haisheng-from-ch> '
[08:32] <ackk> zyga-ubuntu, it was shutdown because of meltdown/spectre, only whitelisted projects are built
[08:32] <ackk> zyga-ubuntu, so no PPA and snap builds
[08:33] <zyga-ubuntu> aaah
[08:33] <zyga-ubuntu> makes sense
[08:37] <mvo> ackk: maybe we are not in that whitelist
[08:42]  * zyga-ubuntu uses his GPU to heat up the room
[08:42] <ackk> mvo, yeah you should ask about it, I know other teams did
[08:42] <zyga-ubuntu> darn it's a cold day today
[08:44] <haisheng-from-ch> hi, zyga-ubuntu, any info can be provieded for me about this error?
[08:44] <zyga-ubuntu> haisheng-from-ch: not immediately, I work on core snapd but how it combines with reference gadgets and ubuntu image is complex; perhaps ask ogra_ as he's closer to that layer
[08:45] <zyga-ubuntu> it's best to open a forum topic
[08:45] <zyga-ubuntu> include all the details: which ubuntu-image you've used, how did you boot it, etc
[08:45] <haisheng-from-ch> ok thanks.
[09:03] <mup> PR snapd#4450 opened: snap: support `command-not-found` symlink for `snap advise-command` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4450>
[09:05] <ackk> mvo, so with your latest changes you were able to get a working maas snap installed, right?
[09:09] <mvo> ackk: yeah, it was not getting past "intializing" though
[09:10] <mvo> ackk: fwiw, I ask on #launchpad about the build but I guess tricky TZ wise currently
[09:10] <mvo> ackk: to get answers
[09:11] <ackk> mvo, cool. could you pass me the snap for the base so i can try locally (see if I can actually get maas to work)
[09:14] <mvo> ackk: sure, let me try a cleanbuild for you
[09:17] <ackk> mvo, you might want to try #launchpad-ops
[09:23] <zyga-ubuntu> hey Chipaca
[09:23] <Chipaca> zyga-ubuntu: o/
[09:27] <Chipaca> zyga-ubuntu: over the weekend i might've gone all "here's a nickel, kid" on somebody's distro
[09:27] <zyga-ubuntu> Chipaca: sorry, the analogy eludes me
[09:27] <Chipaca> zyga-ubuntu: http://assets.amuniversal.com/6b08abb09fbb012f2fe600163e41dd5b
[09:27] <zyga-ubuntu> Chipaca: are you saying you tried a bunch of distros?
[09:27] <zyga-ubuntu> haha
[09:28] <Chipaca> zyga-ubuntu: in particular, https://forum.snapcraft.io/t/cannot-comunicate-with-server-mx-linux-17/3455/2
[09:31] <kalikiana> elopio: you're awake?
[09:31] <mup> PR core#70 opened: hooks: use symlink to run `snap advise-command` <Created by mvo5> <https://github.com/snapcore/core/pull/70>
[09:31] <Chipaca> kalikiana: it's 3am in .cr
[09:32] <kalikiana> Chipaca: Well, it didn't seem to stop him from pushing code to GitHub, that's why I'm asking
[09:32] <Chipaca> ah
[09:32] <Chipaca> kalikiana: i read it as a "are you awake", not as "wtf you awake"
[09:32] <Chipaca> :)
[09:33] <kalikiana> :-D
[09:34] <kalikiana> English is so ambiguous when you don't use properly foul language
[09:35] <Chipaca> well i could've also been unambiguouss without being lazy, but i'm lazy
[09:46]  * zyga-ubuntu crosses fingers
[09:46] <mborzecki> TIL manjaro has a user friendly installer
[09:50] <zyga-ubuntu> is it just me or has the lower temperature brought much higher pressure
[09:50] <zyga-ubuntu> I don't feel sleepy like I did all last week
[09:56] <Chipaca> mvo: you around?
[09:57] <mvo> Chipaca: yes, good morning!
[09:58] <Chipaca> mvo: good morning! what are my chances of you finishing your review of #4394?
[09:58] <mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
[10:01] <mvo> Chipaca: *cough* I let you wait long enough - I do that now as in right now
[10:01] <Chipaca> :-D
[10:01]  * kalikiana coffee break
[10:03] <Chipaca> note fedora tests are disabled again
[10:04] <mborzecki> btw. i actuallt hit the same problem as the spread tests did when updating my wife's fedora on friday
[10:05] <Chipaca> mborzecki: which problem?
[10:06] <Chipaca> mborzecki: or rather, which of the problems? :-)
[10:07] <mborzecki> Chipaca: failure to downlaod from updates repo
[10:07] <Chipaca> ah
[10:08] <Chipaca> mborzecki: i've also seen (in the tests) fedora not having 'snap' in the path, and fedora's systemd not knowing about snapd.service
[10:08] <Chipaca> that's the point i disabled the test again
[10:08] <Chipaca> (after re-running them ~6 times because of the repo thing)
[10:08] <mborzecki> that's interesting, was it reproducible?
[10:08] <Chipaca> something's very broken, needs fixing, but beyond me atm
[10:08] <Chipaca> mborzecki: afaik it was just the once, but it was just the breaking point
[10:09] <mborzecki> haha ok :)
[10:09] <Chipaca> that is, i had about 6 runs of it breaking because of the repo thing
[10:09] <Chipaca> then it didn't break because of the repo and instead didn't know about snapd
[10:09] <Chipaca> or the service
[10:09] <Chipaca> (different instances of fedora in the same run)
[10:09] <mborzecki> well f26 was to be switched to manual anyway, hoping we could get the f27 PR merged soon
[10:09] <Chipaca> so, (╯°□°）╯︵ ┻━┻
[10:18] <Chipaca> ok, off to physio for me
[10:18]  * Chipaca bbi1h
[10:38] <mborzecki> hmm installed snapd-git on clean manjaro .. and it's broken, seems like snap mount dir is /var/lib/snapd/snap, but there's only /snap in the system, /var/lib/snapd/snap does not exist
[10:38] <mborzecki> zyga-ubuntu: any idea who i can talk to about this?
[10:39] <zyga-ubuntu> mborzecki: so which of the two layouts would manjro prefer?
[10:41] <mborzecki> idk, seems like they're undecided
[10:42]  * kalikiana moving to coffee shop, brb
[11:09] <mborzecki> so i managed to get:
[11:09] <mborzecki> Name         Version  Rev   Developer  Notes
[11:09] <mborzecki> core                  3748  canonical  broken
[11:09] <mborzecki> hello-world           27    canonical  broken
[11:09] <mborzecki> on manjaro
[11:09] <zyga-ubuntu> mborzecki: what's the configuration there/
[11:09] <zyga-ubuntu> mborzecki: did it reexec
[11:09] <zyga-ubuntu> mborzecki: is it using /snap or /var/lib/snapd/snap?
[11:10] <mborzecki> yeah, it's using /var/lib/snapd/snap
[11:10] <mborzecki> looks like the manjaro `community` repo pacakaes do not do a proper cleanup when removing
[11:10] <zyga-ubuntu> ahh
[11:10] <zyga-ubuntu> that's not catastrophic
[11:10] <mborzecki> there's bits and pieces left behind, one of those is mounted snaps
[11:11] <mborzecki> and for some reason i ended up having `hello-world` in /var/lib/snapd/snap but there's no core
[11:12] <mborzecki> uhh, taje that back, there's 'hello-world' in /snap but no 'core'
[11:12] <zyga-ubuntu> mborzecki: what if you start from scratch on a clean manjaro system
[11:12] <zyga-ubuntu> is it still broken then?
[11:13] <mborzecki> i had a clean system, then installed snapd-git, but apaprently they have snapd-git in community repo (?) and it was broken like i described earlier
[11:13] <zyga-ubuntu> aha, I see
[11:13] <zyga-ubuntu> mborzecki: they accept PRs there so I guess we need to update it
[11:14] <mborzecki> then i removed that package and tried to install snapd-git from aur, ran into multiple issues with files left behind by their community package and finally got into the 'broken' state :)
[11:17] <ackk> mvo, any luck on the build?
[11:18]  * kalikiana having lunch earlier today
[11:20]  * zyga-ubuntu burns spread cycles on iteration with apparmor
[11:21] <mvo> ackk: not yet, I can give you a manually build one, for some reason "snapcraft cleanbuild" fails for me in artful, maybe deboostrap is doing things that are not supported, I get https://paste.ubuntu.com/26346220/ ( kalikiana may know more). I can give you a hand-hacked one instead
[11:23] <ackk> mvo, that would be helpful, thanks
[11:26] <mup> PR snapd#4451 opened: cmd/snap-update-ns: improve mocking for tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4451>
[11:26] <niemeyer> Good morning!
[11:27] <zyga-ubuntu> niemeyer: hello
[11:27] <zyga-ubuntu> long time no see!
[11:28] <niemeyer> Indeed!
[11:28] <mvo> ackk: please try http://people.canonical.com/~mvo/tmp/base-18_very-unstable_amd64.snap
[11:28] <niemeyer> Just learning how to type again..
[11:28] <ackk> mvo, thanks
[11:28] <mvo> hey niemeyer - welcome back! we missed you
[11:28] <niemeyer> mvo: Heya, thanks!
[11:29] <niemeyer> Missed you all too.. was a bit hard to put myself away from all action :)
[11:29] <mborzecki> niemeyer: hey, how was your vacation?
[11:30] <niemeyer> It was great being so offline for a few days
[11:30] <ackk> mvo, still getting https://paste.ubuntu.com/26346261/ when trying my snap
[11:32] <kalikiana> mvo: you get that error with cleanbuild? I've never seen that. Would you mind filing a bug?
[11:34] <pstolowski> niemeyer, hi! welcome back!
[11:43]  * kalikiana getting food now, biab
[11:50] <mup> PR snapd#4452 opened: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4452>
[11:50] <zyga-ubuntu> wow, the bot is instant
[11:51] <zyga-ubuntu> when I opened this PR the latency was << 1s
[11:54]  * zyga-ubuntu food break
[12:00] <Chipaca> zyga-ubuntu: i think you just happened to open the PR at :59 :-)
[12:00] <mvo> kalikiana: sure
[12:00] <mvo> ackk: could you please try in clean vm? I can't reproduce this error
[12:02] <zyga-ubuntu> Chipaca: hehe, maybe :)
[12:02] <mvo> Chipaca: you have a first bit of review, I will continue in a little bit, its fine don't get me wrong, just tiny ideas/nitpicks
[12:02] <zyga-ubuntu> mvo: I'll do two more PRs on hole-poking and layouts and then look at LXD mount issue
[12:02] <Chipaca> mvo: ah then i'll wait (i already added your suggestion, was about to push)
[12:03] <Chipaca> mvo: if you consider them nitpick-level, i can address them in the followup instead of here
[12:03] <Chipaca> mvo: let me know :-)
[12:03] <mborzecki> the AUR snapd package does not build :(
[12:06] <mvo> Chipaca: interessting idea, we could merge and then do a follwup indeed
[12:06] <Chipaca> mvo: i mean, i have a followup -- but it's not small
[12:06] <Chipaca> so maybe it's a _bad_ idea :-)
[12:07] <Chipaca> but it's certainly an idea
[12:07] <mvo> Chipaca: the dirstack is used instead of recursion because you want to keep the open file handles low?
[12:07] <mvo> Chipaca: heh :)
[12:07] <Chipaca> mvo: and the call stack
[12:07] <mvo> Chipaca: *nod*
[12:08] <Chipaca> mvo: better to have a stack of string than a stack of stacks
[12:08] <mvo> +1
[12:08] <Chipaca> at least that's what i was taught in uni, back when i paid attention
[12:08] <mvo> Chipaca: was just wondering as the recursive version is easier to read but its fine, your reasoning is sound
[12:10] <mvo> Chipaca: when you apply the "readOneDir" idea, maybe "readOneDirN()" and we add the "100" to the readOneDirN() call?
[12:10] <Chipaca> mvo: what for?
[12:11] <mvo> Chipaca: mostly clarity, readOneDir() is really read100ItemsFromOneDir :)
[12:11] <mvo> (as it is today/in that pastebin)
[12:12] <Chipaca> mvo: maybe i should rename it babySteps()
[12:12] <Chipaca> as in Walk() -> babySteps()
[12:12] <Chipaca> :-)
[12:12] <mvo> Chipaca: heh, yeah, something like this, seriously, just to avoid our future selfs using it assuming it would read *all* of that dir
[12:12] <mvo> (or my future self that has a limited memory span)
[12:14] <Chipaca> I'll rename it something super obvious, like twiddle()
[12:14] <Chipaca> doThing()
[12:14] <Chipaca> oh, i know! doProcessThing()
[12:14] <zyga-ubuntu> just go all the way and call it all twinky, twonky, twooty, twoo, calling each other with one global variable as help
[12:16] <Chipaca> zyga-ubuntu: and the global variable should be literally 'help'
[12:16] <pstolowski> Chipaca, hey, there are rumours you have a lot on your plate and might want some help? for example with warnings, or free disk check?
[12:16] <zyga-ubuntu> Chipaca: bonus point if it's a function pointer initialized to a XKCD strip
[12:16] <Chipaca> pstolowski: warnings comes before free disk check warnings, but free disk computation coud come before that
[12:17]  * zyga-ubuntu prepares oatmeal, the O(1) complexity food for software developers
[12:17] <zyga-ubuntu> water, flakes, heat, eat
[12:17] <Chipaca> zyga-ubuntu: this is go, you can't do `var help func() = "http://..."`
[12:17] <zyga-ubuntu> Chipaca: function printing that or sensible-browser opening that would do
[12:18] <zyga-ubuntu> https://xkcd.com/1513/ is fine
[12:18] <Chipaca> zyga-ubuntu: is it bad that somewhere on my other computer is a javascript page that edits itself until it compiles
[12:19] <Chipaca> pstolowski: i've got a branch with part of warnings, i think? but not sure if it'd still work as it's from two sprints ago
[12:20] <pstolowski> Chipaca, perhaps I could take free disk computation?
[12:20] <Chipaca> pstolowski: disk usage shares some of the issues with snapshots for which i wanted to fix user iteration, but i wasn't able to get to the bottom of those failures
[12:21] <Chipaca> pstolowski: actually perhaps that's a good place to poke: want to see if you can figure out the failures?
[12:22] <Chipaca> pstolowski: if you take #4299 and then
[12:22] <mup> PR #4299: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4299>
[12:22] <Chipaca> pstolowski: spread  -seed=1512088627 -shell linode:ubuntu-14.04-64:tests/main/{interfaces-browser-support,abort}
[12:22] <Chipaca> pstolowski: but with -debug instead of -shell
[12:22] <Chipaca> pstolowski: you'll see the failures i mean (or you should)
[12:22] <pstolowski> Chipaca, ack, will see if I can find something
[12:23] <Chipaca> pstolowski: the failure is the whole thing dying (spread says something about EOF)
[12:23] <Chipaca> pstolowski: good luck
[12:23] <pstolowski> Chipaca, ahh, that failure
[12:23] <mup> PR snapd#4453 opened: Update README.md <Created by popey> <https://github.com/snapcore/snapd/pull/4453>
[12:24] <Chipaca> pstolowski: indeedly
[12:24] <mup> PR snapcraft#1854 opened: Update README.md <Created by popey> <https://github.com/snapcore/snapcraft/pull/1854>
[12:25] <greyback> hey, any easy way to re-run CI on this? https://github.com/snapcore/snapd/pull/4365
[12:25] <mup> PR #4365: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
[12:26] <zyga-ubuntu> greyback: as in restart?
[12:26] <Chipaca> greyback: by CI you mean travis?
[12:26] <zyga-ubuntu>  just did
[12:27] <greyback> zyga-ubuntu: Chipaca yes and yes
[12:27] <Chipaca> greyback: merge master first
[12:27] <zyga-ubuntu> aww
[12:27] <Chipaca> zyga-ubuntu: fedora will fail :-/
[12:27] <zyga-ubuntu> sorry for wasting cycles
[12:27] <zyga-ubuntu> cancelled
[12:27] <greyback> ah, the fedora thing still not fixed
[12:27] <greyback> ok
[12:27] <Chipaca> greyback: well, if you merge master, they're disabled
[12:27] <greyback> Chipaca: aha, ok
[12:27] <greyback> will do
[12:27] <Chipaca> so no, but yes
[12:27] <greyback> :)
[12:29] <Chipaca> greyback: note if people have looked at it already we ask you merge instead of rebasing
[12:29] <greyback> Chipaca: good to know, thank you
[12:30] <mvo> Chipaca: ok, finished the rest, I get some lunch now
[12:30] <ackk> mvo, I'm testing in a container, not a vm
[12:30] <ackk> I can try a clean one, though
[12:30] <mvo> ackk: if its not too much hassle that would be great.
[12:30] <ackk> sure
[12:30] <mvo> ackk: I couldn't reproduce the issue, but I was testing using a vm :/
[12:30]  * mvo lunch
[12:34] <ackk> mvo, https://paste.ubuntu.com/26346467/ in a clean LXD
[12:35] <mvo> ackk: thanks, puzzling
[12:35] <ackk> the first error I 've seen randomly happen, but usually it's just the first time
[12:42] <kalikiana> re
[12:59] <pstolowski> Chipaca, interfaces-browser-support from your branch passed here. i'm running 16.04, could this be a factor?
[12:59] <Chipaca> pstolowski: i'm running 16.04 as well
[12:59] <Chipaca> pstolowski: note it only fails together with another test
[12:59] <pstolowski> Chipaca, aha!
[13:00] <Chipaca> pstolowski: that's why the command was as i typed
[13:00] <pstolowski> I should treat your command literally.. yes
[13:01] <Chipaca> niemeyer: standup?
[13:12] <kalikiana> popey: Hey! Can you provide an example that triggers this bug? https://bugs.launchpad.net/snapcraft/+bug/1741752
[13:12] <mup> Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:Incomplete> <https://launchpad.net/bugs/1741752>
[13:14] <popey> kalikiana: done
[13:25] <kalikiana> popey: Thanks! Will try to reproduce here
[13:30] <pstolowski> Chipaca, and it passed https://pastebin.ubuntu.com/26346695/
[13:30] <pstolowski> Chipaca, you said it was failing every time for you?
[13:34] <mborzecki> Chipaca: i can look into fedora issues later today/tomorrow
[13:37] <popey> kalikiana: are we going to get stacktrace spam turned off sometime soon?
[13:39] <kalikiana> popey: There were some fixes for that already. Have you tested with the --beta snap?
[13:39] <popey> kalikiana: I'm on edge
[13:40] <kalikiana> popey: If that isn't a Freudin slip :-P Can you paste any recent example? We might not have caught all of them
[13:40] <popey> kalikiana: how about the bug you just asked me to put an example on? :)
[13:44] <kalikiana> popey:  Ah, right. So in this case you see the trace because it's not a known failure case. It's a genuine bug so this will need a proper exception code path.
[13:45] <kalikiana> We don't generally try to hide those
[13:45] <popey> I don't ever want to see them
[13:45] <diddledan> me too
[13:45] <popey> unless I pass some kind of -show_me_the_python_nonsense_I_dont_care_about
[13:45] <diddledan> only devs need to see those
[13:46] <diddledan> just say "we dun goof'd" on unknown errors and leave it there
[13:47] <popey> SNAPCRAFT_VERBOSE=1 would do
[13:47] <popey> i would set that on build.snapcraft.io or travis, but never on my laptop
[13:48] <kalikiana> We could make them `--debug` only and something like `Please re-run with --debug to get a full trace`.  The most important aspect to my mind is that there's a clear path to knowing how to get the error and report it if desired.
[13:48] <popey> that'd work
[13:49] <diddledan> even better: --file-bug; that runs through until the failure and then gets all the useful debug info and posts it to launchpad similar to ubuntu-bug does
[13:50] <diddledan> or maybe call it "--create-bug"
[13:50] <diddledan> something like that anywho
[13:50] <diddledan> then we don't need to even work out which bits we need to copy
[13:52] <kalikiana> That might need some discussion on what that info is... although that's a nice idea
[13:53] <diddledan> or rather than being explicit when it hits a failure it just prompts "do you want to create a bug? (Y/n)" which you can disable with a `--quiet` flag
[13:54] <diddledan> bonus points for finding duplicates
[13:54] <kalikiana> That would've been awesome for codein...
[13:54]  * kalikiana won't have time to look into the anytime soon
[13:55] <diddledan> pop it on the backlog :-)
[13:55] <kalikiana> diddledan: Mind filing a bug for it?
[13:56] <diddledan> roger that
[13:56] <popey> there is one
[13:56] <popey> i filed it iirc
[13:56] <kalikiana> For "file a bug"?
[13:56] <popey> no, for stfu
[13:56] <popey> https://bugs.launchpad.net/snapcraft/+bug/1740265
[13:56] <mup> Bug #1740265: Stack trace makes it hard to discern real errors <Snapcraft:New> <https://launchpad.net/bugs/1740265>
[13:57] <popey> Please don't push that back until after we have bug reporting built in though :(
[13:57] <kalikiana> popey: Aye, this one is pretty straightforward. I'll bring it up later in our weekly meeting
[13:57] <popey> thanks
[14:03] <diddledan> bug #1741900
[14:03] <mup> Bug #1741900: Add file-a-bug functionality on errors <Snapcraft:New> <https://launchpad.net/bugs/1741900>
[14:05] <kalikiana> diddledan: Thanks!
[14:10]  * pstolowski lunch
[14:10]  * zyga-ubuntu quick break to catch up with kids
[14:19]  * mborzecki is off to pick up the kids
[14:29] <ogra_> cyphermox, i have the next wlan module that doesnt support unbind ... given how big that block in netplan already is i wonder, cant we get away without unbinding the dirvers at all ?
[14:30] <ogra_> cyphermox, ath6kl_sdio this time ...
[14:31] <cyphermox> not afaik
[14:31]  * ogra_ will file a bug and patch as usual ... but all these SRUs get tiring 
[14:32] <Chipaca> pstolowski: indeed. Can you run the whole suite?
[14:33] <Chipaca> pstolowski: also, what's your PROMPT_COMMAND? :-)
[14:41] <ogra_> cyphermox, https://code.launchpad.net/~ogra/netplan/+git/netplan/+merge/335824 .. do you need a separate MP for the xenial branch or will you just backport it ?
[14:42] <mup> PR snapd#4454 opened: snap: fix gadget.yaml parsing for multi volume gadgets <Created by mvo5> <https://github.com/snapcore/snapd/pull/4454>
[14:42] <mup> PR snapd#4455 opened: store, daemon/api: Rename MyAppsServer, point to dashboard.snapcraft.io instead <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/4455>
[14:48] <zyga-ubuntu> back to work
[14:52] <ogra_> cyphermox, https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1741910
[14:52] <mup> Bug #1741910: ath6kl_sdio does not support unbinding <netplan:New> <nplan (Ubuntu):New> <nplan (Ubuntu Xenial):New> <https://launchpad.net/bugs/1741910>
[15:00] <cyphermox> ogra_: it's fine as-is,thanks!
[15:00] <ogra_> awesome !
[15:00] <elopio> hello!
[15:00] <elopio> kalikiana: I am awake now :)
[15:15] <kalikiana> elopio: :-D
[15:19] <kalikiana> elopio: Actually there's something I'd like your input on. Can you have another look at snapcraft#1847 and tell me your thoughts on conditional `sudo` in `_container_run`? kyrofa wasn't very happy with it, so I changed it twice now. I figure a third opinion would help figure out the best path
[15:19] <mup> PR snapcraft#1847: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1847>
[15:21] <kalikiana> elopio: Also in case you haven't seen it, I made some comments on snapcraft#1853
[15:21] <mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
[15:21] <elopio> yup, thanks for the review.
[15:25] <elopio> kalikiana: I find that clear, if user != 'root': prepend sudo.
[15:26] <kalikiana> elopio: first I had heuristics, then I had user=False... if you like this version I'm hoping kyrofa will also like it, but otherwise I'm out of ideas :-P
[15:27] <kyrofa> kalikiana, haha, I'm sorry to be causing pain. user=False was way better
[15:27] <kalikiana> kyrofa: :-|
[15:27] <elopio> that's easy to fix, ask kyrofa for what will make him happy, instead of guessing :D
[15:27] <kyrofa> kalikiana, I mean way better than the heuristics
[15:27] <elopio> lol
[15:27] <kyrofa> kalikiana, haven't looked at the new way yet
[15:27] <kalikiana> kyrofa: Oh, hah, okay
[15:28] <kalikiana> I'm actually liking the latest one a lot more myself now than what I did before
[15:28] <kyrofa> Alright I'll take a look soon. I have oodles of codein reviews
[15:29] <kalikiana> The good kind of spam ;-)
[15:30] <kalikiana> kyrofa: We can also have a quick chat about it in/after the weekly, might be easier at this point
[15:30] <kyrofa> kalikiana, we can do that if I haven't been able to review by then, I know you go *poof* shortly after
[15:32] <kalikiana> Yeah. I'm weird like that. As if the sun somehow goes down earlier where I'm at :-P
[15:43] <mup> PR snapcraft#1854 closed: Update README.md <Created by popey> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1854>
[15:51] <kyrofa> kalikiana, yeah, let's chat about this in a few
[16:08]  * zyga-ubuntu runs new tests and goes to update the forum on the progress towards layouts
[16:24] <Chipaca> pstolowski: sorry if i missed your reply, were you able to run the full suite?
[16:25] <pstolowski> Chipaca, no, I got a bunch of EOFs, but not on the tests in questions
[16:25] <pstolowski> *in question
[16:26] <Chipaca> pstolowski: that's fine
[16:26] <Chipaca> pstolowski: those test were not the problem, the EOFs were
[16:26] <pstolowski> ah, ok
[16:26] <Chipaca> just that with those two i was always able to reproduce, but it's weird enough that i'm not surprised it's moved
[16:26] <pstolowski> Chipaca, re my command prompt, I use zsh and oh-my-zsh dot files ;)
[16:26] <Chipaca> booh :-) ok
[16:27] <pstolowski> who uses bash anyway? ;)
[16:28] <Chipaca> o/
[16:29] <ogra_> hey !
[16:30]  * Chipaca hides before ogra_ goes nukular
[16:30] <ogra_> lol
[16:34] <mup> PR snapcraft#1855 opened: storeapi: add docstrings for _snap_index_client.py <Created by konrad11901> <https://github.com/snapcore/snapcraft/pull/1855>
[16:39] <brunosfer> Hi guys, does anyone knows how can I install the exact version of a snap on ubuntu core?
[16:45] <zyga-ubuntu> brunosfer: what do you mean by exact version of a snap?
[16:53] <pstolowski> Chipaca, so it appears I need to run multiple spread tests to trigger EOF, that matches your observations right?
[16:53] <Chipaca> pstolowski: yuup
[17:03] <brunosfer> zyga-ubuntu: e.g. snap discord has older versions. the current version is 0.0.3, however it has an older version 0.0.2, if I remove this snap from my OS, can I make something like sudo snap install discord --version=0.0.2 ?
[17:04] <brunosfer> Not exactly a rollback to the previous version, but rather a version in particular, however in this case such thing does not apply.
[17:06] <zyga-ubuntu> brunosfer: not quite like that, versions are meaningless, you can install appropriate revision (see snap install --help)
[17:06] <ogra_> you can do that if you own the snap
[17:06] <ogra_> but only then
[17:06] <zyga-ubuntu> brunosfer: you can list the revisions you have on your machine
[17:06] <zyga-ubuntu> brunosfer: you can switch between any revisions that are published (by switching channels)
[17:06] <zyga-ubuntu> brunosfer: and between any revisions on your machine that you already had (by using -r)
[17:07] <ogra_> ... and between random revisions from the store if you are the owner (developer)
[17:08] <ogra_> (unless that got disabled since i used it last)
[17:08] <zyga-ubuntu> ogra_: no, it's a desired feature
[17:08] <ogra_> right
[17:09] <kyrofa> kalikiana, test failures on snapcraft#1847
[17:09] <mup> PR snapcraft#1847: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1847>
[17:10] <kalikiana> kyrofa: Eh. Lemme check those quickly before I leave. Those all passed locally...
[17:10] <kalikiana> Thanks
[17:12]  * Chipaca hugs mvo 
[17:13] <Chipaca> mvo: thank you for asking me for more tests
[17:17] <kalikiana> Meh, I was missing a mock geteuid there
[17:32] <sparkiegeek> is there a way of telling 'snap set' to not show progress (because I'm running it from a script)?
[17:34] <zyga-ubuntu> Chipaca: ^
[17:34] <Chipaca> sparkiegeek: </dev/null
[17:35]  * zyga-ubuntu goes to fix a quick oversight in the new mimic code
[17:35] <Chipaca> sparkiegeek: although it should already do that if stdin is not a tty
[17:35] <zyga-ubuntu> well, not in minic but around it
[17:35] <sparkiegeek> Chipaca: thanks
[17:35] <Chipaca> sparkiegeek: just checked, and in 2.30 at least, if stdin is not a tty, you should get the nonverbose noninteractive "progress bar"
[17:36] <Chipaca> it'll just print success
[17:36] <Chipaca> and that sort of thing
[17:36] <sparkiegeek> Chipaca: confirmed with 2.30, stdin=open('/dev/null') does what I want
[17:36] <sparkiegeek> I was trying to find a --quiet/--non-interactive option
[17:36] <sparkiegeek> this is fine though, cheers
[17:37] <zyga-ubuntu> sparkiegeek: if this is python, use subprocess.DEVNULL
[17:37] <mup> PR snapcraft#1856 opened: remote_parts: Use hashed folder based on parts URI <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1856>
[17:39] <kalikiana> Alrighty, pushed the remote parts fix out, now I'll call it a day
[17:40]  * zyga-ubuntu will work for a little while longer to get all of the mimic branches merge-worthy and fully functional
[17:40] <zyga-ubuntu> and tomorrow, layouts
[17:41] <sparkiegeek> zyga-ubuntu: good shout
[17:41] <kyrofa> Hey ogra_, do you know anything about the kernel on the nvidia Jetson boards? Can they run snaps?
[17:41] <ogra_> no idea
[17:42] <ogra_> but i doubt that
[17:42] <kyrofa> Me too
[17:43] <sparkiegeek> is there a way of getting snapd version information in a parseable format (e.g. JSON/YAML/..)?
[17:44] <sparkiegeek> or should I just do "^(.*)\s+(.*)$" style parsing?
[17:44] <zyga-ubuntu> sparkiegeek: talk to the socket
[17:44] <zyga-ubuntu> there's a whole API there
[17:44] <zyga-ubuntu> (talking json)
[17:56] <brunosfer> zyga-ubuntu: sudo snap discord -r 0.0.2 ? Would be something like this?
[17:58]  * Chipaca wraps up his day, at least for now
[18:02] <zyga-ubuntu> brunosfer: no, revisions are always integers
[18:02] <zyga-ubuntu> brunosfer: this looks like a version
[18:02] <zyga-ubuntu> brunosfer: try snap list --all
[18:03] <zyga-ubuntu> brunosfer: you will see various revisions of each snap on your system
[18:03] <zyga-ubuntu> brunosfer: again, unless you had a revision you want to go to, you cannot do that
[18:03] <zyga-ubuntu> brunosfer: only the owner of that snap can
[18:03] <zyga-ubuntu> brunosfer: snaps should have sensibly defined channels and not rely on their users pinning a specific revision
[18:10] <brunosfer> zyga-ubuntu: Thanks, for clarifying. I want to go to the revision 32, how can I switch to an older revision? Because I have tried the -r flag and it didn't work.
[18:10] <zyga-ubuntu> brunosfer: do you have that revision on your system (snap list --all)
[18:11] <brunosfer> zyga-ubuntu: Yes
[18:11] <brunosfer> zyga-ubuntu: discord          0.0.3        41    snapcrafters  -
[18:11] <brunosfer> discord          0.0.2        32    snapcrafters  disabled
[18:11] <brunosfer> discord          0.0.3        38    snapcrafters  disabled
[18:11] <brunosfer> zyga-ubuntu: I want to switch to the revision 32
[18:11] <zyga-ubuntu> snap refresh discord -r 32 OR snap revert discord
[18:11] <zyga-ubuntu> refresh will go there but will keep updating
[18:11] <zyga-ubuntu> and revert will skip 38
[18:11] <zyga-ubuntu> AFAIK
[18:13] <brunosfer> zyga-ubuntu: Thanks, I was using the switch for that. Now that you explained it makes indeed more sense to use the refresh to a specific revision. Thank ;)
[18:14] <brunosfer> zyga-ubuntu: It's giving me the error: unknown flag 'r'
[18:15] <brunosfer> zyga-ubuntu: It's working... no '-' was needed... just the 'r' as a flag.
[18:17] <ogra_> that sounds a bit buggy
[18:17] <zyga-ubuntu> maybe try --revision
[18:17] <ogra_> short options should use a -
[18:18] <brunosfer> zyga-ubuntu: sudo snap refresh discord --revision=50
[18:19] <brunosfer> zyga-ubuntu: it works like this... With the short option doesn't work.
[18:19] <ogra_> ah, the --help also doesnt list any short options at all
[18:28] <zyga-ubuntu> sorry it must have been my rusty memory then
[18:28]  * zyga-ubuntu still debugs one issue
[21:32] <kyrofa> elopio, if you feel like taking circle ci for a spin: https://github.com/canonical-websites/tutorials.ubuntu.com/pull/618
[21:33] <kyrofa> Hey niemeyer, are you around today? Or are you still out on vacation?
[21:35] <kyrofa> Oh, back today, it seems. Okay, I'll catch you tomorrow then :)
[21:42] <kyrofa> Hey there cratliff, good to see you around
[21:44] <cratliff> Hey, yeah, the holidays can keep you busy sometimes.
[21:56] <mup> PR snapcraft#1847 closed: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1847>
[22:16] <kyrofa> Boy no kidding
[23:06] <niemeyer> kyrofa: I'm fully back already