[01:49] <andschwa> I need some help. I'm looking for the global configurations so I can change SNAP_DATA and SNAP_COMMON for all my snaps (so I can install them to a separate drive).
[01:49] <andschwa> But my god, I've searched and searched. There's docs on what the environment variables are, but not how to set them for snapd.
[01:50] <andschwa> Should I really perhaps be looking at mounting my drive to /var/snap?
[01:56] <andschwa> This seems like a super straightforward thing to do.
[01:56] <andschwa> And I cannot find it.
[01:59] <andschwa> Is anyone here, or is everyone on "Rocket"?
[02:05] <andschwa> Is what I want to do against snappy's design or something?
[02:05] <andschwa> It doesn't seem like it, since it's all centered around environment variables set at runtime by snapd for a snap.
[02:05] <andschwa> So it seems almost explicitly setup such that you can change what snapd sets those variables to.
[02:06] <andschwa> Yet I cannot find it.
[04:25] <mup> PR # closed: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
[04:25] <mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3810, snapd#3812
[04:26] <mup> PR # opened: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
[04:26] <mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3810, snapd#3812
[06:24] <abeato> ogra_, do you know which is the current status of https://forum.snapcraft.io/t/updating-bootloader-assets-in-the-gadget-snap ?
[07:39] <mup> PR snapd#3759 closed: add spread test for wayland <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3759>
[07:41] <zyga-suse> good morning
[07:41] <zyga-suse> sorry for being late, I was the last one at breakfast, along with my sleepwalking daugther
[07:44] <zyga-suse> mvo: how are you doing today?
[07:45] <mvo> zyga-suse: hey, good morning. doing fine, how are you?
[07:45] <zyga-suse> pstolowski: hey, I think there's something you want to look into
[07:45] <zyga-suse> mvo: perhaps ^ before release
[07:45] <zyga-suse> mvo: downgrading from master to stable fails if you have any changes in flight that involves hooks
[07:46] <zyga-suse> because of the new hooks that don't have handlers
[07:47] <mvo>  zyga-suse hm, interessting. what does the error look like? can you pastebin the session?
[07:47] <pstolowski> zyga-suse, hey
[07:48] <zyga-suse> mvo: I _may_ I ran into it over weekend
[07:48]  * zyga-suse scrolls back
[07:48] <mvo> zyga-suse: thank you
[07:48] <zyga-suse> mvo: essentially this looks like the "CE cannot rollback" problem we had
[07:49] <mvo> zyga-suse: I'm mostly curious about the exact effect, if we really cannot rollback that is a problem
[07:49] <zyga-suse> mvo: aha, maybe that wording was too strong, I think the given change will fail but rollback as a whole will work (still just guessing)
[07:50] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[07:50] <mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[07:51] <mvo> zyga-suse: yeah, if that is the case its bad but not a blocker for the release. still something we want to fix
[07:51] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[07:51] <mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[07:51] <pstolowski> zyga-suse, what do I do exactly to reproduce?
[07:51] <mvo> zyga-suse, pstolowski: please keep me updated :)
[07:51] <zyga-suse> pstolowski: wait, let me find it
[07:52] <zyga-suse> mvo: one more thing, I merged that PR with apparmor probing code
[07:52] <zyga-suse> mvo: I re-designed it after your comment
[07:52] <zyga-suse> mvo: please have a look if you like that
[07:55] <mvo> zyga-suse: you merged it and then re-designed it?
[07:55] <zyga-suse> mvo: no, I read your comment, re-designed and merged
[07:56] <mvo> zyga-suse: ok, I have a look. but I would prefer to look before it gets merged (two +1 and all that)
[07:57] <zyga-suse> mvo: it's very similar to your suggestion and I had +1 from jamie so I merged it but I'll wait for re-affirmation next time
[07:57]  * zyga-suse still looks for that hook info
[08:02] <zyga-suse> darn, where was that...
[08:06] <zyga-suse> pstolowski: sorry I cannot find it
[08:06] <zyga-suse> I think it was on IRC but you were already off
[08:06] <zyga-suse> but I cannot see it in my backlog
[08:07] <zyga-suse> pstolowski, the situation is as follows, start installing a snap using master, stop snapd and revert to stable
[08:10] <pedronis> I don't see many solutions here except changing the handling of hooks slightly in 2.26
[08:11] <zyga-suse> I think being more graceful, as if the task was done in 2.26 would be good
[08:11] <zyga-suse> essentially you cannot rely on the hook
[08:11] <zyga-suse> since old snapd may run it
[08:12] <zyga-suse> and if you want to rely, use assumes
[08:12] <pedronis> is the revert of core itself that explodes?
[08:12] <zyga-suse> I don't remember, I think it was not the core but then again, it may be
[08:12] <zyga-suse> and in that case it would be unfortunate
[08:14] <mvo> zyga-suse: I put some comments into the PR 3808, nothing criticial but worth considering IMO
[08:14] <zyga-suse> sure,
[08:16] <mvo> zyga-suse: don't get me wrong, I appreciate the work on this feature and I know its frustrating to wait for reviews :)
[08:18] <zyga-suse> mvo: the nil result is something I copied from Chipaca's PR
[08:18] <zyga-suse> mvo: I can undo that, I was just surprised that you can call methods on typed nil just fine
[08:18] <zyga-suse> mvo: and I did it here
[08:19] <mvo> zyga-suse: right, its fine, I was also surprised about it (haven't seen that pattern) and that is one good reason to have it in code review to spread the knowledge etc :)
[08:19]  * zyga-suse got a telemarketer call now
[08:19] <mvo> zyga-suse: do you remember what PR it was where Chipaca used this nil check pattern? curious to see how/why it was used there too
[08:19] <mvo> zyga-suse: meh, I hate those
[08:19] <zyga-suse> with a 500GB 3G/LTE data plan
[08:20] <zyga-suse> mvo: no, but maybe Chipaca remembers, it was very recent
[08:20] <zyga-suse> at 23euro / month
[08:20]  * zyga-suse is considering that 
[08:20] <zyga-suse> they also bundle some crap laptop
[08:22] <mvo> Chipaca: do you think you could have a look at 3795? it probably also needs a review from niemeyer but if we are happy with the code that will help I think (we need gustavo mostly for the concecpt behind it)
[08:22] <mvo> Chipaca: its also short :)
[08:23] <zyga-suse> mvo: replied
[08:23] <zyga-suse> mvo: let me know if you want me to change the nil pointer thing
[08:24] <zyga-suse> man, clouds == crap network
[08:26] <pstolowski> zyga-suse, you mean install a deb with master, then revert to debs from the distro?
[08:27] <pstolowski> (pardon my ignorance, but I'm not sure if it should involve some images from edge etc.)
[08:29] <zyga-suse> pstolowski: I think just install edge and go to stable
[08:29] <zyga-suse> pstolowski: and have the right snap install pending
[08:40] <pstolowski> k
[08:40]  * mwhudson waves
[08:43] <zyga-suse> hey mwhudson
[08:49] <Chipaca> zyga-suse: mvo: good morning!
[08:49] <Chipaca> *technically* it's a national holiday here
[08:49] <zyga-suse> Chipaca: ohhh, nice
[08:49] <zyga-suse> so what are you doing here?
[08:49] <Chipaca> zyga-suse: having breakfast, and also i've been trying to snap a rather gnarly application
[08:50] <zyga-suse> +100
[08:50] <zyga-suse> I love trying to snap things
[08:50] <zyga-suse> to see how that feels like
[08:50] <zyga-suse> and to see what issues I run into
[08:50] <Chipaca> it's looking like i can't make this one work without either bases or layouts
[08:50] <Chipaca> and that assumes layouts lets me replace /lib
[08:54] <Chipaca> zyga-suse: mvo: which PR were you two discussing?
[08:57] <zyga-suse> Chipaca: remember when you showed me a PR where you did methods on nils?
[08:57] <zyga-suse> Chipaca: and I was surprised this is doable in go
[08:58] <Chipaca> yes
[09:00] <mup> PR snapcraft#1512 opened: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
[09:01] <zyga-suse> mvo: ^
[09:04] <ogra_> abeato, no idea, perhaps ask in the thread ?
[09:05] <pedronis> afaik it's been postponed
[09:05] <abeato> ogra_, ok, will do
[09:06] <mvo> Chipaca: context is my review of 3808, most specically https://github.com/snapcore/snapd/pull/3808/files#r135463240
[09:06] <mup> PR snapd#3808: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3808>
[09:07] <mvo> Chipaca: and was curious in what context you use it. in the context of this pr I was mostly wondering why not just return by-value but mostly I wanted some context as this is/was a new pattern for me
[09:07] <mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[09:08] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[09:10] <zyga-suse> mvo, Chipaca: please let me know if you want me to change that code, otherwise I'll move on to other work
[09:10] <mvo> meh, it looks like our update to github.com/snapcore/snapd/vendor/golang.org/x/sys/unix broke powerpc
[09:10]  * mvo looks
[09:10] <zyga-suse> aww, sucks
[09:10] <zyga-suse> mvo: btw, golang 1.9 had some support changes for that arch
[09:10] <zyga-suse> they dropped some older HW
[09:11] <pedronis> mvo: we updated it because of the golang/x/crypto update, I don't even think we needed it before
[09:11] <pedronis> fwiw
[09:13]  * pstolowski amazed by mvo's code review
[09:14] <zyga-suse> Chipaca: hmm, why doesn't logger.Noticef print stuff?
[09:14] <pstolowski> mvo, thank you for taking time & proposing the changes
[09:14] <pstolowski> !
[09:14] <mvo> pedronis: aha, thanks, that is good to know, I will investigate, its a bit of a bummer
[09:14] <zyga-suse> Chipaca: but it does later
[09:14] <zyga-suse> 2017/08/28 11:13:52.385942 daemon.go:275: started snapd/2.27.3+git744.gd34c3ddc6 (series 16; classic; devmode) opensuse/20170823 (amd64) linux/4.12.8-1-default.
[09:14] <zyga-suse> that's the first message I see
[09:14] <mvo> pstolowski: your welcome, my pleasure
[09:14] <zyga-suse> but before that I call noticef + println in another spot and only the println shows up
[09:14] <mwhudson> zyga-suse: 1.9 changed stuff around ppc64 big endian, which has never been an ubuntu architecture
[09:14] <mvo> zyga-suse: go-1.9> things we should land?
[09:14] <mvo> zyga-suse: in master I mean?
[09:14] <zyga-suse> mwhudson: ah, good
[09:14] <mwhudson> zyga-suse: this failure is about powerpc
[09:14] <mwhudson> i.e. 32-bit
[09:15] <zyga-suse> aha
[09:15]  * zyga-suse shuts up then
[09:15] <mwhudson> which stopped being an ubuntu architecture in ... zesty?
[09:15] <mwhudson> it ought to be possible to add gccgo / powerpc support to sys/unix, i never figured out how to do it thouh
[09:16] <mwhudson> (also didn't care overly much)
[09:16] <mvo> mwhudson: powerpc we probably still need to support because of 16.04, the failures look slightly nasty: http://paste.ubuntu.com/25416387/
[09:16]  * zyga-suse sees SetLogger
[09:16] <mwhudson> mvo: x/sys/unix just doesn't support powerpc at all
[09:16] <mvo> mwhudson: aha, great that you know more about this, so what are our options? can we avoid sys/unix somehow?
[09:16] <mwhudson> mvo: i don't know which bit of crypto is using it
[09:17] <Chipaca> mvo: sitting in the top of the tree, try: find -type f -name \*.go -print0 | xargs -0 perl -wne 'BEGIN{$n=0}; if ($n!=0) {$n=0; print "$ARGV: $f$ARGV: $_" if /if $v == nil/ }; if (/^func \((\S+) \*/) {$n=1; $f=$_; $v=$1}'
[09:17] <Chipaca> zyga-suse: where doesn't logger.Noticef print stuff?
[09:18] <mwhudson> mvo: support for other arches with gccgo has been added, so presumably the same can be done for ppc
[09:18] <zyga-suse> woah
[09:18] <zyga-suse> that's nice
[09:18] <Chipaca> zyga-suse: it might be trying to print stuff before it's initialised?
[09:18] <ogra_> mvo, i just noticed that the initramfs-tools-ubuntu-core deb is behind the git tree, androidboot is missing and there was no deb build after the unit tests branch landed ... if i push that to the PPA today do i disturb any release ?
[09:18] <zyga-suse> Chipaca: I patched an init() function in a module to call it
[09:18] <zyga-suse> Chipaca: I understand that during startup we actually init the logger
[09:18] <Chipaca> yes
[09:18] <zyga-suse> Chipaca: and I got the short end of the ordering stick
[09:18] <Chipaca> probably
[09:18] <zyga-suse> hmmm
[09:19]  * zyga-suse wants the user warning framework
[09:19] <zyga-suse> I could really use it now
[09:19] <Chipaca> zyga-suse: is this in debugging snapd?
[09:19] <zyga-suse> yes
[09:19] <zyga-suse> well
[09:19] <Chipaca> zyga-suse: just print it?
[09:19] <mvo> ogra_: thanks for checking, things should be fine today
[09:19] <zyga-suse> I want something more sticky
[09:19] <zyga-suse> jdstrand requested that we log that we are on partial apparomr
[09:19] <ogra_> mvo, ok, then i'll upload
[09:19] <zyga-suse> "prominently" logged
[09:20] <zyga-suse> Chipaca: I'll just print it with a comment
[09:20] <pedronis> so the failing test now is passing, so probably a bunch of other tests might start failing, will see
[09:21] <Chipaca> mvo: that pattern is used in our code in a few places where the expected use of a something includes it sometimes being nil
[09:22] <ogra_> so i built a wine snap last night ...
[09:22] <mvo> Chipaca: thanks, interessting, it escaped me so far
[09:22] <ogra_> and since wine currently only does i386 i actually had to build for i386 ...
[09:23] <Chipaca> mvo: so rather than having “artifact:=default; if thing != nil {artifact = thing.GetArtifact()}”, you move the check into GetArtifact
[09:23] <ogra_> and i must say i have never had such a painful experience with snapcraft :/
[09:23] <ogra_> (trying to build for i386 on amd64 host)
[09:24] <pedronis> Chipaca: mvo:  go does it by static typing, but it exists as pattern since smalltalk (maybe even earlier), afaik it is liked/disliked ever since though
[09:24] <Chipaca> ogra_: you know you can ship i386 binaries in an amd64 snap, yes?
[09:25] <Chipaca> maybe that wasn't your issue :-)
[09:25] <ogra_> Chipaca, but when buiolding from source you still need a i386 build env
[09:25] <Chipaca> anyway, i'll shut up now, seeing as how i'm not really working
[09:25] <mvo> Chipaca, pedronis: thanks, it makes perfect sense was mostly wondering a bit when/how to use it. thanks for your input on this :)
[09:25] <Chipaca> ogra_: “apt install build-essential:i386”?
[09:25] <ogra_> and i dont want the 79234846 build deps wine needs installed on my host ...
[09:25] <Chipaca> ah
[09:25] <ogra_> so i use cleanbuild
[09:26] <ogra_> and then things explode
[09:26] <ogra_> even using a plain lxd container as i386 system doesnt work properly
[09:26] <ogra_> (there is an unfixed bug in libc)
[09:26] <mwhudson> pedronis: smalltalk is a bit different though, messages sent to nil are all ignored, iirc?
[09:28]  * zyga-suse suffers terrible network
[09:28] <zyga-suse> just 2 days left
[09:28] <zyga-suse> I'll be home by Wednesday
[09:30] <pedronis> mwhudson: well, I was more referring to people adding implementation of things to nil
[09:30] <pedronis> which you can
[09:31] <mwhudson> ah
[09:31] <pedronis> (unless I'm totally misremembering this)
[09:31] <pstolowski> zyga-suse, - Run refresh hook of "core" snap if present (internal error: no registered handlers for hook "refresh")
[09:31] <pstolowski> zyga-suse, ^ is that what you saw when refreshing core from stable to edge and back to stable?
[09:34] <zyga-suse> yes
[09:34] <zyga-suse> that's what I saw
[09:34] <mup> PR snapd#3814 opened: interfaces: enable partial apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/3814>
[09:34] <zyga-suse> pstolowski: is that a release blocker?
[09:37] <mvo> 3781 needs a second review, its very nice and not very long
[09:39] <pstolowski> zyga-suse, afaict we don't have this hook in release/2.27
[09:40] <pedronis> pstolowski: a blocker for 2.28
[09:40]  * zyga-suse looks at 3781
[09:40] <mvo> Chipaca: 3748 has a conflict
[09:40] <pstolowski> pedronis, oh, for 2.28 yes
[09:40] <pedronis> or for 2.27 if we decide we need to do something there
[09:41] <pedronis> it seems this a problem that will show up again and again with new hooks
[09:43] <pstolowski> yes
[09:44] <zyga-suse> pedronis, pstolowski: are you suggesting a 2.27.5 with some future-proofing for hooks in general?
[09:44] <zyga-suse> ahead of 2.28 release?
[09:44] <pedronis> I don't know
[09:44] <pedronis> I'm mostly musing
[09:47]  * zyga-suse nods
[09:48] <pstolowski> i'm not sure. i need to fully understand the problem. hook machinery is a little bit deceptive with the 'Optional' flag. clearly the registration of hook handlers is critical
[09:49] <zyga-suse> optional feels like "may fail"
[09:49] <zyga-suse> but we need to know it exists
[09:50] <zyga-suse> which poses a problem for each added hook
[09:50] <pstolowski> i have a feeling that the only way around this is to make a missing handler non-critical
[09:50] <pedronis> if it's optional and the hooks doesn't exist in the snap, we don't care if the hook is registered or not
[09:50] <pedronis> internally
[09:50] <pedronis> but I don't remember the internal details to know if this is easy or not to tweak that way
[09:51] <pedronis> it probably breaks abstractions
[10:22] <pstolowski> uh oh we have a logic like this in place already, but i think it has a bug
[10:38]  * tbr slaps chihchun_afk around a bit with a large and slimy trout. Dude, turn off your nick-changes. That annoys the crap out of people.
[10:41] <zyga-suse> whee
[10:42] <zyga-suse> let me try it on ubuntu now
[10:42] <zyga-suse> mvo: I'm almost ready with 2.28 branches :)
[10:42] <zyga-suse> mvo: how are we doing with release freeze/fork
[10:43] <ogra_> zyga-suse, oh, did you tell pstolowski about the "refresh back to beta" image we found on the weekend ?
[10:43] <ogra_> (i didnt file a bug)
[10:43] <zyga-suse> ogra_: yes, I was wondering where I saw that
[10:43] <ogra_> pstolowski, http://paste.ubuntu.com/25416803/
[10:44] <zyga-suse> ogra_: was that on IRC? I couldn't find the discussion
[10:44] <zyga-suse> ogra_: woot, thank you :)
[10:44] <ogra_> this is when moving to edge (for a test) and then trying to go back to beta
[10:45] <zyga-suse> mvo: ^ given this I would say we need to fix that for 2.28
[10:46] <pstolowski> ogra_, yeah, that's the issue i'm looking on. nb, you can of course snap revert core
[10:46] <ogra_> a revert would switch channels ?
[10:47] <mvo> zyga-suse: sounds like something we need to 2.28, yes. I understand pstolowski is looking into it(?)
[10:47] <pstolowski> ogra_, no, just mentioning, it won't fail that way
[10:47] <ogra_> right
[10:47] <pstolowski> mvo, yes, i think i've a fix
[10:47] <ogra_> it only fails when moving to edge and trying to go back though ...
[10:48] <ogra_> (i doubt it affects the beta/candidate or stable channels yet)
[10:48] <zyga-suse> ogra_: and by extension it will fail when CE will test rollback from 2.28
[10:48] <ogra_> right
[10:55] <fgimenez> hey mvo, looks like CE QA found an issue with 2.27.4, i've just forwarded you the message
[10:55] <mvo> Chipaca: http://paste.ubuntu.com/25416853/ is probably something we need to fix for 2.28
[10:56] <mvo> fgimenez: thanks, let me have a look
[10:56] <zyga-suse> fgimenez: can this be public somewhere please?
[10:57] <zyga-suse> mvo: also FYI, not for 2.28 (needs research first) but important as it breaks containers: https://bugs.launchpad.net/snapd/+bug/1712930
[10:57] <mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
[10:57] <fgimenez> zyga-suse: not sure better ask them, they are posting to snap-update-verification@lists.canonical.com, maybe you can subscribe?
[10:58] <zyga-suse> fgimenez: I mean, I could do that but then again we have https://forum.snapcraft.io/t/in-progress-snapd-2-27-4/572 that everybody should post to
[10:59] <mvo> zyga-suse: hm, is this just changing the order of things (ideally switching two lines). or is there more work involved here?
[11:03] <fgimenez> zyga-suse: yeap, i already mentioned them about the forum and the release threads but don't know about how (or if) they make their test results public, they can explain better for sure :)
[11:05] <zyga-suse> mvo: not sure if this is just two lines :)
[11:06] <zyga-suse> mvo: could be trivial or very complex, I didn't look yet
[11:06] <mvo> ok
[11:06] <mup> PR snapcraft#1513 opened: lifecycle: outdated step should raise SnapcraftError <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1513>
[11:18] <mup> PR snapd#3815 opened: tests: install test-snapd-complexion on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815>
[11:18] <mvo> Chipaca: trivial reproducer -^
[11:22] <zyga-suse> hmmmmmmm
[11:22]  * zyga-suse is unhappy about https://travis-ci.org/snapcore/snapd/builds/269141620?utm_source=github_status&utm_medium=notification
[11:22] <pedronis> mvo: I think it's an holiday for John
[11:22] <zyga-suse> is that just another bug in apparmor profile loading for tests
[11:22] <zyga-suse> or a real issue
[11:22] <zyga-suse> indeed
[11:22] <mwhudson> mvo: i wrote up that dput linter wrapper thing I talked about before https://gist.github.com/mwhudson/616499edb1191bd99c987bbbd8781ce9
[11:22] <zyga-suse> he is off
[11:22] <mvo> pedronis: oh, thanks
[11:22] <mvo> Chipaca: weeeh, sorry - you are off today? I won't bother you anymore
[11:23] <mvo> mwhudson: nice
[11:23] <zyga-suse> mvo: question, will we re-load snap-confine's apparmor profile before configuring core?
[11:45] <mup> PR snapd#3816 opened: hooks: do not error out when hook is optional and no hook handler is registered <Created by stolowski> <https://github.com/snapcore/snapd/pull/3816>
[11:45] <pstolowski> zyga-suse, mvo ^ this should fix the problem with hooks, but I only tested with unit test
[11:51] <mup> PR snapd#3817 opened: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <https://github.com/snapcore/snapd/pull/3817>
[11:54] <mup> PR snapcraft#1510 closed: ci: disable the travis deploy stage for docs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1510>
[12:12] <mup> PR snapcraft#1508 closed: schema: version should have a max length of 32 <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1508>
[12:52] <cachio> mvo, did you see the email I fw?
[12:52] <mvo> zyga-suse, spineau, jdstrand: so I think I have an idea about the problem with "sudo network-manager.nmcli d show eth0" getting denies on 2.27 - we enabled seccomp argument filtering for socket. and the profile has "#  socket AF_NETLINK - -" and I assume that nmcli uses the netlink socket
[12:52] <mvo> cachio: indeed I did and after a small panic I started debugging
[12:53] <cachio> mvo, ohhh, any finding?
[12:54] <mvo> cachio: yes, maybe, I think I need jdstrand to help me, but I suspect we need to enable socket AF_NETLINK at least for nmcli, maybe for more.
[12:55] <cachio> mvo, is this caused because the last change done for 2.27.4?
[12:55] <zyga-suse> mvo: there's a new set of netlink interfaces
[12:55] <zyga-suse> mvo: maybe those are sufficient there
[12:55] <zyga-suse> mvo: I wish we knew the values of other arguments but I suspect I can easily check that locally
[12:55] <zyga-suse> mvo: (if it is netlink or not)
[12:56] <zyga-suse> mvo: AFAIK it used KOBJECT_UEVENT but perhaps I'm wrong
[12:56] <spineau> mvo: like mmcli? that's the first one I can think of
[12:56] <zyga-suse> mvo: note that jamie is off today, I'll check it out after checking out one other thing
[12:56] <zyga-suse> mvo: if you can strace it on your machine and pastebin that it would be sufficient
[12:59] <spineau> zyga-suse: mvo: I'm still connected to our test device, if I can help you by providing more logs, just ask
[12:59] <zyga-suse> spineau: thank you, if you know how to run strace under snap confinement (not trivial) then please do that
[13:00] <zyga-suse> spineau: you need to edit the seccomp/apparmor profiles, allow extra stuff and run strace you get from the host somehow
[13:00] <zyga-suse> spineau: don't worry if you don't want to go through those hoops
[13:00] <spineau> zyga-suse: unfortunately, I'm still a snap newbie
[13:01] <mvo> zyga-suse: strace is not working for me, hangs
[13:01] <mvo> zyga-suse: when I enable AF_NETLINK things work
[13:01] <zyga-suse> mvo: strace needs some love, ok
[13:02] <mvo> zyga-suse: socket AF_NETLINK - -
[13:02] <mvo> zyga-suse: if that is part of the profile things work
[13:03] <zyga-suse> mvo: note that we don't have any interfaces that add that
[13:03] <zyga-suse> mvo: we have "socket AF_NETLINK - NETLINK_AUDIT" and similarly NETLINK_CONNECTOR
[13:03] <zyga-suse> we need to know which one is really required
[13:03] <zyga-suse> mvo: and perhaps consider an approach (new release of network-manager or a snap-id specific quirk)
[13:26] <willdeberry> so it seems that everything was passing, but since I have been rebasing just to keep things fresh, travis build now fails: https://github.com/snapcore/snapd/pull/3812
[13:26] <mup> PR snapd#3812: Expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
[13:34] <zyga-suse> mvo: offtopic
[13:34] <pedronis> niemeyer: will you create a tracker topic in the forum for the current PRs?
[13:34] <zyga-suse> mvo: I updated my x250 to zesty
[13:34] <zyga-suse> mvo: and ... the update removed xorg-input-all
[13:34] <zyga-suse> mvo: that was curious to debug
[13:35] <zyga-suse> mvo: apparently people ran into this too and I found lots of forum posts and what not
[13:35] <zyga-suse> mvo: so now things work
[13:35] <zyga-suse> mvo: when you don't have xorg-input-all and its deps you have GDM/lightdm with *no* keyboard interaction at all
[13:35] <zyga-suse> not even alt-ctrl-f2 to get out
[13:36] <niemeyer> pedronis: I'm on the fence about it.. I want to make sure we take it as an actual sprint if it's added, and given all the work on the release we may not be able to do it
[13:36] <zyga-suse> aha, so I know what is wrong with the spread setup, nothing, it looks like a very odd and curious apparmor behavior
[13:36] <niemeyer> pedronis: Perhaps we can kick it off once the release is clean?
[13:36] <pedronis> niemeyer: ok, just wondering because I start to have a bit of hard time finding/remembering what to review
[13:37] <niemeyer> pedronis: Aha, I see
[13:37] <niemeyer> pedronis: Let me create one then
[13:37] <mup> PR snapd#3818 opened: interfaces: fix network-manger plug <Created by mvo5> <https://github.com/snapcore/snapd/pull/3818>
[13:38] <mup> PR snapd#3819 opened: hooks: do not error out when hook is optional and no hook handler is registered (2.27) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3819>
[13:38] <mvo> 3260 needs a second review, tests are green now
[13:39] <mvo> zyga-suse: 3818 is maybe what we need to fix the nmcli issue, an early look  is appreciated, I mostly opened it to get spread tests running
[13:43] <zyga-suse> mvo: ack
[13:43] <pedronis> snapd#3817 needs quick a review (it's about the fakestore tests that were sill failing sometimes for me in autopkgtests)
[13:43] <mup> PR snapd#3817: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <https://github.com/snapcore/snapd/pull/3817>
[13:43] <zyga-suse> re-started something else and looking
[13:43] <niemeyer> Forgot to ask.. did we have any other issues on the testing infra after the Spread changes I did on Friday?
[13:43] <ogra_> wow, cool ...
[13:44] <ogra_> seems my wine snap really works with all exe installers i have lying around ... and all install just go fine to SNAP_USER_DATA
[13:44] <ogra_> *all installs
[13:45] <mvo> ogra_: thats very neat, wine is a nice snap to have
[13:45] <ogra_> well, needs --devmode
[13:45] <ogra_> (or --classic, but i didnt feel like making a classic snap)
[13:45] <ogra_> it wants to read / and /boot
[13:46] <mvo> makes one wonder why that :)
[13:46] <ogra_> but it it really cool that you can just install wine 2.15 next to the deb one
[13:46] <ogra_> because it can put .desktop files in place and such
[13:46] <ogra_> for apps it installs
[13:46] <mvo> yeah, also wine might be perfect for tracks, i.e. being able to install 2.0, 2.1, etc
[13:46] <ogra_> yeah
[13:47] <ogra_> i only did it out of curiosity ... but there is a snapcraft source tree now that someone can take and make something real out of it
[13:47] <ogra_> our forum doesnt work with the sippped wine IE :/
[13:47] <ogra_> *shipped
[13:48]  * mvo nods
[13:48] <ogra_> "your browser is to old" :P
[13:49] <ogra_> snapcraft.io itself and ubuntu.com work fine
[13:53] <mup> PR snapd#3817 closed: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3817>
[13:55] <zyga-suse> mvo: re, thank you for checking it is UEVENT
[13:55] <zyga-suse> let me look at something related and I will review this
[13:57] <mvo> zyga-suse: no real rush, I want to see the test results first, maybe its actually not working
[13:58] <zyga-suse> I commented
[13:59] <mvo> zyga-suse: aha, indeed, silly me, you are right. I will fix
[13:59] <zyga-suse> thanks!
[14:00] <zyga-suse> I checked other interfaces
[14:00] <zyga-suse> they all use permanent snippet but for slot
[14:00] <zyga-suse> for plug I think it's fine to keep this on connected
[14:07] <mup> PR snapcraft#1514 opened: docs: add github processed templates <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1514>
[14:11] <mup> PR snapd#2807 closed: snap: add new `snap switch` command <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2807>
[14:25] <mup> PR snapd#3820 opened: spread: don't set HTTPS?_PROXY for linode <Created by zyga> <https://github.com/snapcore/snapd/pull/3820>
[14:26] <zyga-suse> mvo: ^ trivial one
[14:31] <zyga-suse> tested locally
[14:33] <zyga-suse> mvo: looking at the ordering issue now
[14:33] <mvo> zyga-suse: great, thank you!
[14:34] <mvo> zyga-suse: I'm waiting for tests and I think 3818 will need a review from jamie as well, right?
[14:34] <zyga-suse> yes
[14:34] <zyga-suse> note that jamie is off today
[14:43] <niemeyer> pedronis: https://forum.snapcraft.io/t/review-sprint-3/1880
[14:49] <pedronis> niemeyer: thanks
[14:52] <niemeyer> pedronis: No problem.. tweaked the format slightly as apparently the recent changes in Discourse modified some of the old icons we were using, but still same thing
[14:52] <mup> PR snapd#3821 opened: tests: new regex used to validate the core version on extra snaps ass <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3821>
[15:08]  * zyga-suse moved indoors, too cold 
[15:45] <soee> hi, i have installed an app via snap and have this: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[15:46] <soee> any idea what is wrong ?
[16:00] <zyga-suse> hey
[16:00] <zyga-suse> soee: let me try to help you
[16:00] <zyga-suse> soee: can you start by running "snap version" and pasting the result
[16:01] <Chipaca> mvo: ah! so on core we need to not do the snippets (and source complete.sh)
[16:01]  * Chipaca disappears again
[16:27] <cachio> pedronis, hey, any idea why this error could be happening runing tests on staging ?
[16:27] <cachio> error: cannot fetch snap signatures/assertions: circular assertions are not expected: account (canonical)
[16:41] <pedronis> cachio: sounds it's not using the right kind of snapd
[16:41] <pedronis> maybe reexec doing something wrong
[16:42] <pedronis> cachio: fwiw I used a correctly built snapd against staging on Friday and things worked
[16:42] <pedronis> snapd built from master
[16:43] <cachio> pedronis, how did you setup the tests?
[16:43] <cachio> pedronis, which variables did you use?
[16:44] <cachio> I want to replicate that into the sread-cron tests against staging
[16:44] <pedronis> cachio:  afair  the test setup should do the right thing, there are two part to this,  you need a snapd built with withtestkeys or withstagingkeys
[16:44] <pedronis> cachio: then you need SNAPPY_USE_STAGING_STORE=1
[16:45] <cachio> pedronis, I have that
[16:45] <cachio> export SPREAD_REMOTE_STORE=staging
[16:45] <cachio> it is traduced into  SNAPPY_USE_STAGING_STORE=1
[16:46] <pedronis> and DEB_BUILD_OPTIONS='nocheck testkeys' dpkg-buildpackage -tc -b -Zgzip
[16:46] <pedronis> the testkeys should do the other part
[16:47] <pedronis> I need a bit more details where this exactly is breaking? breaking early or in some specific test?
[16:48] <pedronis> anyway I need to go have dinner
[16:52] <cachio> pedronis, on those tests https://travis-ci.org/snapcore/spread-cron/builds/268521976#L1224
[16:52] <cachio> there are many tests failing for he same reason
[17:11] <pedronis> cachio: I'll look in my morning
[17:11] <cachio> pedronis, sure, tx
[17:11] <cachio> I am taking a look right now too
[17:13] <pedronis> notice that some are other platforms
[17:13] <pedronis> I mean != ubuntu
[17:13] <pedronis> I don't think it makes sense to run those tests against staging
[17:14] <pedronis> like that failure is for opensuse
[17:14] <pedronis> I don't know if it knows how to build a staging snapd
[17:16] <cachio> ok
[17:16] <cachio> pedronis, i'll change that too, thanks
[17:16] <pedronis> cachio: I mean until we understand more I would skip anything not ubuntu  for staging tests
[17:20] <cachio> pedronis, sure
[17:21] <pedronis> the main user of these tests would be store after a staging deployment
[17:21] <pedronis> I think they have been too flaky to use them tough :/
[17:24] <cachio> pedronis, yes, agree
[17:24] <cachio> most of them have been failing for a while
[17:25] <cachio> pedronis, I think staging should be used just to validate some specific stuff
[17:25] <cachio> pedronis, so it is easier to keep it in green
[17:44] <zyga-suse_> hmm
[17:44] <zyga-suse_> - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
[17:44] <zyga-suse_> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170828_165347_9cd1b@/log.gz
[17:44] <zyga-suse_> from upgrade/basic
[19:14] <stormmore> How difficult would it be to write a snap that can read /etc with making using --classic?
[19:34] <mup> PR snapd#3821 closed: tests: new regex used to validate the core version on extra snaps ass <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3821>
[19:41] <niemeyer> stormmore: With classic or without classic?
[19:42] <niemeyer> pedronis, zyga-suse_, cachio: Review board now has details on who's reviewing or needs to review
[19:43] <cachio> niemeyer, nice
[19:43] <stormmore> niemeyer: preferably without
[19:47] <niemeyer> stormmore: That needs an interface for the specific need you have.. many are already available, but it may need to be created as well if it's not yet there
[19:48] <niemeyer> stormmore: With classic, it's just a matter of opening the files.. nothing fancy to be done
[19:49] <stormmore> niemeyer: whats a good place to see a list of interfaces. I did look there as that was what I was suspecting but I didn't find one that would give even read-only (not sure that is going to be sufficient for my needs yet but gotta start somewhere) access to /etc from their desc
[19:50] <niemeyer> stormmore: No interface will give access to all of /etc
[19:50] <niemeyer> stormmore: Some will give access to specific bits inside /etc, according to their described purpose
[19:51] <stormmore> niemeyer: ah that is why I am probably leaning towards making this a classic snap (at least initially)
[19:51] <niemeyer> stormmore: Yeah, it's a fine way to get started
[19:52] <stormmore> niemeyer: thanks, just wanted to see if there was a "better way" but looks like I was on the right track
[20:00] <mup> PR snapd#3120 closed: [WIP] interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3120>
[20:08] <zyga-suse_> niemeyer: wow, that's nice
[20:08] <zyga-suse_> WOW, way nicer than I expected :D
[20:10] <zyga-suse_> really nice work :)
[20:10] <zyga-suse_> niemeyer: I wonder what will happen when we have initial clashes in the team
[20:11] <niemeyer> zyga-suse_: Wow, thanks :)
[20:11] <niemeyer> zyga-suse_: You mean more than 26 reviewers? ;P
[20:12] <zyga-suse_> well, if we get another zygmunt, will we call him z^1 ;D
[20:12] <niemeyer> zyga-suse_: We already have clashes.. look closely
[20:13] <niemeyer> and apparently we also have a bug.. something is wrong with #3260.. looking
[20:13] <zyga-suse_> ah, indeed
[20:14]  * zyga-suse_ is happy that zygmunt is an uncommon word and his life is simple here
[20:19] <cachio> niemeyer, do you know which is the job to sync prod with staging stores?
[20:21] <pedronis> cachio: there's no such job
[20:22] <cachio> pedronis, ok, is it a manual procedura?
[20:22] <pedronis> yes, we typically add relevant snaps to staging
[20:22] <pedronis> staging store and prod store are fairly indepedent
[20:23] <cachio> ok, so I should download/upload the snaps
[20:23] <cachio> pedronis, I'll try that
[20:24] <pedronis> anyway probably another good reason to cut down staging tests
[20:25] <cachio> pedronis, yes
[20:25] <cachio> pedronis, if it is not automatic, it does not scale
[20:25] <pedronis> not sure how to do that though, spread doesn't have more tagging than manual
[20:25] <pedronis> skipping support is also missing, our skips atm ad hoc
[20:27] <pedronis> one approach could be just have a different suite and symlinks
[20:29] <cachio> pedronis, why we are running tests against staging?
[20:30] <cachio> pedronis, if there is not something new to test on there the best we can do is to remove those execution from spread-cron as you suggested
[20:30] <pedronis> cachio: ?  the idea was to run them each time one of the store services gets a new staging deploy ?
[20:31] <pedronis> that's what triggers runs
[20:31] <pedronis> to check that changes to the store don't break the contract with snapd
[20:31] <pedronis> that was the idea
[20:31] <cachio> pedronis, makes sense
[20:32] <pedronis> yes, it's a sound idea, the executation hasn't been amazing so far though, also probably too many not relevant tests
[20:32] <cachio> so, we just need to keep the databases synchronized
[20:32] <pedronis> and also the store has changed, so we need different checks
[20:32] <pedronis> cachio: ?
[20:32] <pedronis> don't think that's going to happen
[20:34] <cachio> pedronis, I mean, perhaps the solution is to add a job to keep both in sync
[20:34] <pedronis> we can add something that keeps some subset of snaps in sync
[20:34] <pedronis> but in general afaik there's no plan to keep them generally in sync
[20:35] <cachio> pedronis, otherwise always when we do a change in a snap we need to make that same change in staging
[20:35] <cachio> is it correct?
[20:35] <pedronis> that's how we did so far, yes
[20:36] <cachio> pedronis, ok
[20:37] <cachio> pedronis, what do you suggest, disable the staging jobs? or continue doing that sync manually? or start doing something to keep it on sync
[20:38] <pedronis> cachio: I think we need to take a step back and setup a meeting with the stakeholder interested in that
[20:38] <pedronis> it's not about what *I* suggest 
[20:39] <pedronis> *stakeholders
[20:39] <cachio> pedronis, ok, makes sense, how are the interested stakeholders?
[20:39] <cachio> who
[20:39] <cachio> celso?
[20:40] <pedronis> I can ask tomorrow
[20:40] <cachio> pedronis, sure
[20:40] <cachio> let's talk about that tomorrow
[21:16] <niemeyer> Okay, figured the issue and fixed.. board updated again, with correct data.
[22:30] <mup> PR snapd#3760 closed: Allow snap-confine to be confined even with --disable-apparmor <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/3760>
[23:36] <mup> PR snapd#3260 closed: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3260>