[00:00] <newbsie> Chipaca: I have to reimage the Pi, and then I can try to relogin with the new key's. I appreciate your help, and especially not leaving me hanging.
[00:03] <Chipaca> newbsie: how long does reimaging take?
[00:04] <zyga> ok
[00:04] <zyga> I think I'm done for tonight
[00:06] <newbsie> Just done, the big moment
[00:06] <zyga> Chipaca: can you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170511_000322_edb35@/log.gz
[00:06] <zyga> ... Panic: sync: unlock of unlocked mutex (PC=0x45BDAC)
[00:07] <zyga> this looks rather bad
[00:07] <newbsie> zyga
[00:07] <newbsie> zyga: sorry, what is known_hosts?
[00:07] <zyga> yes?
[00:07] <zyga> newbsie: it's a file where ssh remembers the hosts it saw and their keys
[00:08] <Chipaca> zyga: that one's for pedronis :-)
[00:08] <zyga> Chipaca: also here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170511_000455_63ba2@/log.gz
[00:08] <newbsie> I'm now getting "Host key verification failed"
[00:08] <newbsie> Yes, yes, yes!
[00:09] <zyga> newbsie: becausethey ip you are sshing had changed identity
[00:09] <Chipaca> newbsie: you reimaged, so the host key changed
[00:09] <newbsie> It's working now.
[00:09] <Chipaca> newbsie: wooo
[00:09] <newbsie> That only took a day, but the more you put in, the more you feel like you accomplished, although I stood on the shoulder of zyga and Chipaca. XD
[00:10] <Chipaca> *that's* why i'm so sore!
[00:10] <zyga> we ran out of machines
[00:10] <Chipaca> newbsie: let's make it suck less. Looking forward to the forum post.
[00:10] <newbsie> Chipaca: I'm not that heavy. Although I do like burgers, steak and fatty food in general.
[00:10] <Chipaca> zyga: la la la can't hear you i'm already asleep
[00:11] <zyga> Chipaca: yes, good idea
[00:11]  * zyga afk
[00:26] <newbsie> zyga: I'm going to log off too, but I really appreciate your help earlier. Will definitely make that post on the snapcraft forum.
[05:45] <mup> PR snapcraft#1309 opened: meta: read and write the desktop file with utf-8 encoding <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1309>
[05:51] <mup> PR snapcraft#1310 opened: tests: use C.UTF-8 for the docker locale <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1310>
[06:27] <mup> PR snapd#3293 closed: spread.yaml: increase linode workers by 50% <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3293>
[06:28] <mup> PR snapd#2869 closed: interfaces/builtin: add online-accounts-service interface <Created by mardy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2869>
[07:04] <morphis> zyga: ping
[07:05] <morphis> zyga: is https://paste.ubuntu.com/24553247/ expected?
[07:05] <morphis> that is with 2.25 on suse
[07:14] <pstolowski> morning
[07:14] <fgimenez> good morning mvo :) wrt 2.25 SRU and bug #1689332 if we don't promote the ubuntu-core snap shipping 2.25 (2109 for amd64, currently in beta) we are good to go right?
[07:14] <mup> Bug #1689332: internal error with any command using ubuntu-core snap on classic <snapd:In Progress by zyga> <https://launchpad.net/bugs/1689332>
[07:14] <fgimenez> hey pstolowski
[07:14] <mvo> fgimenez: good morning. yes, I think so, we just freeze ubuntu-core from now
[07:15] <mup> PR snapd#2941 closed: interfaces/builtin: add network-status interface <Created by xavi-garcia-mena> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2941>
[07:16] <fgimenez> mvo: ok, shall i put a comment in the sru bug and mark it as verification-done? we only found this issue
[07:16] <mvo> fgimenez: yes, please do, I will revert beta ubuntu-core to stable so this issue will be gone
[07:17] <fgimenez> mvo: ok thanks!
[07:17] <mvo> fgimenez: hm, actually it won't be gone :/ we need to land 3289 first
[07:19] <morphis> mvo: do you know if the message shown with https://paste.ubuntu.com/24553247/ is expected with 2.25? this is on suse so with forced-devmode
[07:19] <fgimenez> mvo: aha ok, this won't be added to the current 2.25, will it? i mean, do we need to wait until 2.26?
[07:21] <mup> PR snapd#3296 opened: image: fix go vet issue <Created by mvo5> <https://github.com/snapcore/snapd/pull/3296>
[07:21] <mvo> morphis: that is something for zyga - but I got feedback on the sprint about this as well, quite a few people see this or a variation of it. iirc we added the message as a measure of debugging this, we always had this issue but silently ignored it.
[07:21] <mvo> fgimenez: correct, for 2.25 we can do little without quite a bit of extra effort (doing a point release, re-doing the verifications)
[07:22] <fgimenez> mvo: ack thanks
[07:22] <mvo> morphis: the message also looks slightly odd, lets wait for zyga
[07:23] <mvo> 3289 needs a second review fwiw, but I guess its a bit early still
[07:43] <fgimenez> mvo: still about 2.25, pls correct me if i'm wrong but even if snapd#3289 hasn't landed, if the current ubuntu-core stable is available in all the channels then if snapd still allows installing it it wouldn't break anything? sorry maybe i'm missing something
[07:43] <mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
[07:48] <zyga> morphis: known issue, thank you for reminding me
[07:49] <zyga> pstolowski: hey, just a reminder, you didn't add the pre-attribute definers to the test
[07:49] <zyga> pstolowski: I added them already but I thought you would in your attribute branch
[07:49] <morphis> zyga: actually feels bad to have that, something we can easily fix for 2.25?
[07:49] <zyga> morphis: yes
[07:49] <zyga> morphis: the patch will remove two lines
[07:50] <zyga> I will be back shortly, I worked too late last night
[07:51] <mvo> fgimenez: lets try :)
[07:51] <mvo> zyga: if you have a fix in mind, would be great to get it for 2.26
[07:51] <mvo> zyga: please ping when you are back so that we can talk details
[07:52] <morphis> zyga: just one last quick question: why do we have all the %dir /var/lib/snapd/.. lines in the spec file for snapd on suse? Isn't it enough to one for /var/lib/snapd and snapd will take care to create all sub dirs when necessary?
[07:56] <mvo> fgimenez: you are right, things work fine with ubuntu-core from stable it seems
[07:59] <mvo> fgimenez: so no blocker, all good. thanks for this info!
[07:59] <pstolowski> zyga, sorry about that, it didn't occur to me
[08:00] <fgimenez> mvo: np thank you! i've double checked that installing 1797 (current stable) from edge works fine too
[08:02] <Chipaca> morning all
[08:02] <zyga> re
[08:02] <mvo> hey Chipaca, good morning
[08:03] <fgimenez> mvo: http://paste.ubuntu.com/24553441/ i'll put a comment on the sru bug about this and mark it as verification-done, is that ok?
[08:03] <fgimenez> hey Chipaca
[08:03] <zyga> pstolowski: I made a remark in your PR before it was merged, no worries now but we need to be careful, tests will not always show us that stale code is in place
[08:03] <mvo> Chipaca: maybe interessting for you - shellcheck in zesty gives me the following output  http://paste.ubuntu.com/24553330/
[08:03] <zyga> mvo: yes, I'll prepare one shortly
[08:03] <mvo> fgimenez: yes
[08:04] <Chipaca> oooohhh
[08:04] <Chipaca> oooooooooohhhh
[08:04] <Chipaca> oh
[08:04] <Chipaca> sigh
[08:04] <Chipaca> read *with* -r misbehaves on 14.04
[08:04] <mvo> zyga: great, please push it to the top of the todo, its the last blocker for the release (well, not blocker but really nice to have)
[08:04] <mvo> Chipaca: meh, then we can just turn this warning off :)
[08:04] <Chipaca> or was that only when combined with a timeout
[08:04] <Chipaca> mvo: no, this might be the reason for a bug we've got :-)
[08:04] <mvo> Chipaca: ohhhh
[08:05] <mvo> Chipaca: interessting
[08:05] <Chipaca> that's what I said :-)
[08:05] <mvo> lol
[08:05]  * mvo hugs Chipaca
[08:05]  * Chipaca hugs mvo right back
[08:05] <mvo> zyga: and very excited that you have a fix almost ready, great news :)
[08:05] <Chipaca> if my memory serves (for once), it only misbehaves when combined with a timeout
[08:05] <Chipaca> and we don't do that, so this should be good
[08:05] <Chipaca> I'll give it a try
[08:05] <Chipaca> mvo: thanks!
[08:06] <Chipaca> mvo: wrt the last two warnings, I'll add a disably thing
[08:06] <mvo> pstolowski: wooooh, 3119 landed! great job
[08:07] <mvo> Chipaca: thank you
[08:07] <pstolowski> mvo, yeah :}
[08:07] <mvo> pedronis: and good news for you as well, the new number of machines increased and a PR takes currently 30min for a full test run
[08:07] <mvo> (down from ~48min)
[08:08] <zyga> mvo: doing that now
[08:11] <zyga> mvo: https://github.com/snapcore/snapd/pull/3297
[08:11] <mup> PR snapd#3297: overlord/ifacestate: don't spam logs with harmless auto-connect messages <Created by zyga> <https://github.com/snapcore/snapd/pull/3297>
[08:11] <morphis> Son_Goku: did you test if the removal of the snapd package on fedora removes everything from /var/lib/snapd?
[08:11] <mup> PR snapd#3297 opened: overlord/ifacestate: don't spam logs with harmless auto-connect messages <Created by zyga> <https://github.com/snapcore/snapd/pull/3297>
[08:11] <mup> PR snapd#3298 opened: interfaces/builtin: ensure we don't register interfaces twice <Created by zyga> <https://github.com/snapcore/snapd/pull/3298>
[08:11] <Chipaca> mvo: I might be wrong, but I blocked snapd#3290
[08:11] <mup> PR snapd#3290: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>
[08:12] <Chipaca> mvo: just 'cause i'm ornery
[08:12] <mvo> Chipaca: meh, branches
[08:12] <zyga> mvo: can you consider https://github.com/snapcore/snapd/pull/3282 as well?
[08:12] <mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
[08:13] <Chipaca> mvo: basically missing a “and !strings.ContainsWotsit(mx.Channel, '/')”
[08:13] <mvo> Chipaca: I have a look after 2.26, maybe its not so un-ambigious as the doc made me believe
[08:13] <mvo> Chipaca: aha, ok
[08:13] <Chipaca> pedronis: did you see those panics? (are you awake? :-) )
[08:13] <zyga> pedronis: did you see
[08:13] <zyga> PANIC: snapstate_test.go:4416: snapmgrTestSuite.TestEnsureRefreshesAlreadyRanInThisInterval
[08:14] <mvo> Chipaca: yeah, that is making sense
[08:14] <zyga> ... Panic: sync: unlock of unlocked mutex (PC=0x809A45A)
[08:14] <Chipaca> zyga: HAH! beat you to it
[08:14] <zyga> mvo: ^^ (I'd also recommend to hold the release until we know what that is)
[08:14] <mvo> zyga, Chipaca: where are those?
[08:14] <zyga> mvo: in tests, randomly, very often
[08:14] <zyga> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170511_000455_63ba2@/log.gz
[08:14] <zyga> for instance here: https://github.com/snapcore/snapd/pull/3051
[08:14] <mup> PR snapd#3051: interfaces: add consoles interface <Blocked> <Created by femdom> <https://github.com/snapcore/snapd/pull/3051>
[08:15] <zyga> Chipaca: did you talk to pedronis already?
[08:15] <zyga> ah
[08:15] <zyga> I see :D
[08:15] <Chipaca> :)
[08:15]  * zyga is not awake yet
[08:15]  * Chipaca offers some really nice coffee
[08:16] <zyga> Chipaca: yes, I should get some
[08:16] <zyga> Chipaca: after working late I could not sleep
[08:16] <Chipaca> zyga: happens
[08:16] <zyga> Chipaca: so I went on reading, then my son woke up because he wasn't feeling well
[08:16] <zyga> Chipaca: so more stuff at 3AM
[08:16]  * zyga is in Z state today
[08:17] <didrocks> (but as we saw with the ubuntu release name, after Z, there A)
[08:17] <Chipaca> mvo: wrt the channel, i think it's unambiguous wrt lack of /
[08:17] <mvo> Chipaca: cool
[08:23] <abeato_> zyga, hey, where can I find a list of what should be enabled in the kernel for UC?
[08:23] <zyga> mvo: sorry for spamming here but:
[08:23] <zyga> /usr/lib/go-1.6/src/runtime/panic.go:443
[08:23] <zyga>   in gopanic
[08:23] <zyga> /usr/lib/go-1.6/src/math/rand/rand.go:64
[08:23] <zyga>   in Rand.Int63n
[08:23] <zyga> /usr/lib/go-1.6/src/math/rand/rand.go:203
[08:24] <zyga>   in Int63n
[08:24] <zyga> /tmp/autopkgtest.odhoEa/build.iw1/snapd/_build/src/github.com/snapcore/snapd/timeutil/schedule.go:106
[08:24] <zyga>   in randDur
[08:24] <zyga> mvo: does that say that Rand.Int63n panics?
[08:24] <zyga> abeato_: no idea
[08:24] <zyga> abeato_: sorry :/
[08:24] <zyga> abeato_: I don't think anyone maintains a list
[08:24] <zyga> abeato_: we only have "clues"
[08:24] <abeato_> zyga, nw, the thing is that I remember having seen some sort of "bits" files that gave some clues
[08:25] <Chipaca> zyga: DEBUG: host arch (kernel) is '1073741864'
[08:25] <zyga> Chipaca: yes?
[08:25] <zyga> Chipaca: that's seccomp's way of describing architectures
[08:25] <Chipaca> zyga: is that a pointer getting printed as a string?
[08:25] <zyga> (yuck but expected)
[08:26] <zyga> no, that's an opaque thing
[08:26] <Chipaca> yuck
[08:26] <zyga> yep
[08:26] <zyga> Chipaca: I think there are some flags inside there too
[08:26] <zyga> anyway
[08:26] <zyga> Chipaca: any insight into that trace above?
[08:27] <zyga> aha
[08:27] <zyga>     if n <= 0 {
[08:27] <zyga>         panic("invalid argument to Int63n")
[08:27] <zyga>     }
[08:27] <zyga> so rand *can* panic
[08:27] <zyga> mvo: I think this is the bug:
[08:27] <abeato_> zyga, of these which should be included? : http://paste.ubuntu.com/24553511/
[08:27] <zyga> func randDur(dur time.Duration) time.Duration {
[08:27] <zyga>     return time.Duration(rand.Int63n(int64(dur)))
[08:27] <zyga> }
[08:27] <zyga> mvo: you convert this to int64 which is signed
[08:27] <zyga> abeato_: I really don't know
[08:27] <Chipaca> zyga: the panics very much say it's about locking something twice
[08:28] <zyga> Chipaca: locking is another issue (perhaps)
[08:28] <abeato_> zyga, ok ok :)
[08:28] <zyga> Chipaca: but this is IMO wrong too
[08:28] <Chipaca> ah
[08:28] <Chipaca> sorry
[08:28] <Chipaca> where's that coffee i talked about
[08:30] <zyga> mvo: and then this:
[08:30] <zyga>     when := a.Sub(now) + randDur(b.Add(-5*time.Minute).Sub(a))
[08:30] <zyga> here we can call randDur with a negative duration
[08:30] <zyga> when this happens we panic
[08:30]  * zyga -> coffee
[08:31] <Chipaca> looks like that needs to be b-a-5m only if b-a>5m
[08:32] <morphis> Son_Goku: ok, remoable doesn't really work for me with your snapd package in testing
[08:32] <Chipaca> mvo: zyga: i'll fix this :)
[08:32] <zyga> thank you!
[08:33]  * zyga thinks that with snapd architecture growing we could consider some better error resilience,
[08:33] <zyga> like not crashing the whole damn thing at once
[08:40] <morphis> mvo: btw. I saw there is a name change in the vendor release tarball for snapd, 2.24 has vendor.orig.tar.xz and 2.25 has vendor.tar.xz
[08:40] <morphis> mvo: is that intentional?
[08:42] <mvo> morphis: sort of, I have a script now (finally) that is doing all this, so pick a name that you like best and from that point on it will be always the same
[08:42] <mvo> zyga, Chipaca: thank you
[08:43] <mvo> a second review for 3297 would be great
[08:43]  * zyga looks
[08:43] <zyga> aww, drat
[08:43] <zyga> I cannot review my code
[08:43] <zyga> pstolowski: ^^
[08:44] <zyga> mvo: something you suggested https://github.com/snapcore/snapd/pull/3298/files
[08:44] <mup> PR snapd#3298: interfaces/builtin: ensure we don't register interfaces twice <Created by zyga> <https://github.com/snapcore/snapd/pull/3298>
[08:47] <morphis> mvo: great, I am fine with both names, just wondered that is has changed with 2.25
[08:51] <mvo> zyga: thank you!
[08:51] <mvo> morphis: ok, I will leave the 2.25 name then
[08:52] <ogra_> rharper, a safe bet is snap_core or snap_kernel from /proc/cmdline
[08:52] <abeato_> morphis, zyga I think you have seen this before: http://paste.ubuntu.com/24553598/ . Was there a kernel patch for this?
[08:55] <morphis> abeato_: possible
[08:55] <abeato_> it appeass here: https://bugs.launchpad.net/apparmor/+bug/1656121
[08:55] <mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <verification-done-xenial> <verification-done-yakkety>
 <linux (Ubuntu):Incomplete> <linux (Ubuntu Xenial):Fix Released> <linux (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1656121>
[08:55] <mup> PR snapd#3297 closed: overlord/ifacestate: don't spam logs with harmless auto-connect messages <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3297>
[08:56] <morphis> abeato_: so we added support for /proc/*/ns/mnt with the single patch we imported into the 3.4 kernel, I fear we need a bit more than that
[08:57] <abeato_> morphis, hmm, I see
[08:58] <mup> PR snapd#3299 opened: timeutil: avoid panicing when the window is very small <Created by chipaca> <https://github.com/snapcore/snapd/pull/3299>
[08:58] <Chipaca> zyga: mvo: ^
[08:59] <Chipaca> mvo: what're you up to?
[08:59] <Chipaca> mvo: (want me to fix snapd/#3290 for you?)
[08:59] <Chipaca> snapd/3290
[08:59] <Chipaca> snapd/#3290
[08:59] <Chipaca> mup: OI!
[08:59] <mup> Chipaca: Unknown commands are unknown.
[08:59] <Chipaca> snapd#3290
[08:59] <mup> PR snapd#3290: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>
[08:59] <Chipaca> sigh...
[08:59] <Chipaca> it's going to be a long day
[09:00] <mup> PR snapd#3296 closed: image: fix go vet issue <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3296>
[09:00] <zyga> Chipaca: looking!
[09:01] <mvo> Chipaca: yay, thank you!
[09:01] <zyga> abeato_: that probably tells you that /proc/1/ns/mnt does not exist
[09:01] <zyga> abeato_: is this a pre 3.8 kernel?
[09:01] <zyga> Chipaca: we should really practice commit messages
[09:01] <zyga> Chipaca: you cannot return 0 AFAIR
[09:02] <Chipaca> zyga: why not?
[09:02] <zyga> Chipaca: that function panics on zero too
[09:02] <Chipaca> which function
[09:02] <Chipaca> ah, rand.Int64n
[09:02] <zyga> Chipaca: /usr/share/go-1.6/src/math/rand/rand.go on line 64
[09:02] <Chipaca> 63n
[09:02] <Chipaca> *
[09:02] <zyga> yp
[09:02] <zyga> yep
[09:02] <Chipaca> <= then?
[09:02] <zyga> random of 0 is pretty non random :D
[09:03] <abeato_> zyga, it does exist, it is 3.4 + ns patch, but maybe we miss something still
[09:03] <Chipaca> fo sho
[09:03] <zyga> well, you cannot return 0 :)
[09:03] <Chipaca> zyga: why can't i return 0?
[09:03] <zyga> abeato_: try stracing
[09:03] <zyga> Chipaca: ahh
[09:03] <Chipaca> zyga: the rand call is in the function i'm returning from
[09:03] <zyga> Chipaca: sorry, I misread that
[09:03] <zyga> Chipaca: yes, that's ok
[09:03] <zyga> Chipaca: I thought this returns the input to randint,
[09:03] <Chipaca> zyga: still need to change it to a <=
[09:03] <zyga> but it's not :)
[09:04] <Chipaca> adding a test
[09:05] <Chipaca> tested, fixed, pushed
[09:05]  * zyga looks at http://radio.garden
[09:05] <zyga> Chipaca: thank you!
[09:06] <mvo> Chipaca: ideally we would simply not allow windows smaller than 30min
[09:06] <pedronis> Chipaca: ?
[09:07] <Chipaca> pedronis: look at the logs zyga pasted (with a double mutex lock panic)
[09:07] <pedronis> that's refresh.schedule stuff
[09:07] <Chipaca> pedronis: good morning :-)
[09:07] <Chipaca> pedronis: sorry, i thought they were all the same things
[09:07] <pedronis> ?
[09:07] <Chipaca> pedronis: but the one that's for you is the mutex double lock one
[09:07] <Chipaca> let me get the right one for you
[09:08] <Chipaca> pedronis: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170511_000322_edb35@/log.gz
[09:08] <Chipaca> not lock, unlock
[09:08] <Chipaca> w/e :-)
[09:09] <pedronis> Chipaca: well we have some codes that can hit that
[09:09] <Chipaca> is anybody else getting a "los glaciares national park" google doodle, or is google being extra creepy with me?
[09:09] <zyga> ?
[09:09] <zyga> Chipaca: no
[09:09] <zyga> Chipaca: on google.co.uk?
[09:10] <Chipaca> yes
[09:10] <Chipaca> (also in the chrome startup page)
[09:10] <zyga> Chipaca: check out that radio thing, it's amazing :)
[09:11] <Chipaca> mvo: so just make the schedule parser return an error?
[09:11] <abeato_> zyga, morphis http://paste.ubuntu.com/24553660/    It seems that /proc/1/ns/mnt is not a link, but looking at my local machine it seems it should be...
[09:11] <zyga> abeato_: aha, I know what's going on
[09:11] <mvo> Chipaca: either that or just enlarge it to 30min
[09:11] <zyga> abeato_: you found a bug :)
[09:11] <mvo> Chipaca: but I guess for now this fine
[09:11] <abeato_> lol
[09:11] <zyga> abeato_: on older kernels it was not a link
[09:11] <zyga> abeato_: hmm hmm hmm
[09:12] <mvo> Chipaca: we can do a followup
[09:12] <zyga> abeato_: let me wake up and think about this
[09:12] <morphis> abeato_: interesting
[09:12] <mvo> Chipaca: I want 2.26 out :) so followup
[09:12] <zyga> abeato_: but if you can give me a way to run this locally to experimen
[09:12] <zyga> abeato_: I would appreciate that
[09:12] <zyga> abeato_: as a quick work-around do this:
[09:12] <abeato_> zyga, hmm... maybe I can give you remote access to the board
[09:13] <zyga> abeato_: comment-out the call to sc_reassociate_with_pid1_mount_ns in snap-confine.c
[09:13] <zyga> abeato_: that's good too
[09:13] <zyga> abeato_: perhaps we can discuss this on a private channel
[09:13] <pedronis> Chipaca: what's the question,  the test does Unlock,  and will not relock under an unexpected panic
[09:13] <morphis> zyga: you have any reference to resources who talk about ns/mnt being changed to a symlink=
[09:13] <morphis> zyga: this really means we're still missing patches
[09:13] <pedronis> Chipaca: I mean around Ensure
[09:13] <zyga> morphis: no, it's just changed in a future kernel version
[09:14] <zyga> morphis: it's even documented in namespaces(7)
[09:14] <Chipaca> pedronis: i guess the question is "can this be fixed so it doesn't fail at random", with a side of "is this a bad test or can this actually happen"
[09:15] <pedronis> Chipaca: it's a test trying to not get too fussy
[09:15] <pedronis> Chipaca: there is nothing deep going on here
[09:15] <pedronis> just read the code
[09:21] <mup> PR snapd#3300 opened: cmd/snap-confine: don't fail on pre 3.8 kernel <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3300>
[09:23] <Chipaca> mvo: should i fix the --channel one for you?
[09:24] <Chipaca> mvo: or do we bump it
[09:24] <mvo> Chipaca: isn't that fixed, I thought I pushed a fix
[09:24] <Chipaca> ah maybe i need to refresh
[09:25] <pedronis> Chipaca: short story, we should in theory never use lock/unlock pairs without defer, in practice we trade that for readability sometimes under the assumption that what is enclosed shouldn't panic or we are in a test
[09:25] <Chipaca> mvo: doesn't look fixed
[09:25] <Chipaca> mvo: only one commit
[09:26] <Chipaca> ohhhhh
[09:27] <Chipaca> pedronis: this might actually be the same bug then :-)
[09:27] <Chipaca> pedronis: i mean, this panic happens because the ensure panics
[09:27] <Chipaca> and the defer then kicks in and panics again?
[09:27] <pedronis> Chipaca: yes
[09:27] <Chipaca> and the panic is inside rand, called from timeutil/schedule.go
[09:27] <Chipaca> so it _is_ the same thing :-)
[09:28] <pedronis> Chipaca:  we lock defer unlock  then unlock then panic, the deferred unlock is not pleased
[09:28] <Chipaca> whee
[09:28] <Chipaca> pedronis: then it's fixed already :-) (not on master yet but soon)
[09:28] <Chipaca> pedronis: thank you
[09:29] <pedronis> Chipaca: anyway it's a panic on panic as you noticed,  and at least with Unlock/Lock it will not deadlock
[09:39] <mvo> Chipaca: hrm, test failure in snap auto mount test, looks like a flaky test, I have a look
[09:40] <Chipaca> mvo: _did_ you push a fix to 3290?
[09:40] <Chipaca> mvo: (no you didn't :-) )
[09:40] <zyga> Chipaca: can you tell me why this failed perhaps? https://travis-ci.org/snapcore/snapd/builds/231080836?utm_source=github_status&utm_medium=notification
[09:40]  * Chipaca looks
[09:41] <zyga> Chipaca: the non-debug output is short and lacks data, the debug output is enormous and full of store stuff
[09:42] <Chipaca> zyga: I don't know, but I do know that if that used MATCH instead of grep, we'd know :-)
[09:42] <Chipaca> now trolling the debug output
[09:42] <mvo> Chipaca: ups, sorry, forgoten push
[09:42] <Chipaca> mvo: :-)
[09:45] <mvo> zyga: I approved 3300 but it appears like there are still issues
[09:45] <zyga> thank you
[09:45] <zyga> I'm looking at that now
[09:45] <mvo> zyga: aha, I see you are on it already
[09:45] <mvo> zyga: thanks again
[09:45] <Chipaca> zyga: mvo: wrt snapd#3299, I think it's flaky and restarting the test would be ok for now
[09:45] <mup> PR snapd#3299: timeutil: avoid panicing when the window is very small <Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3299>
[09:45] <zyga> Chipaca: go for it!
[09:45] <Chipaca> i also think the test is badly written, and will push a fix
[09:45] <Chipaca> but that fix can wait for post-2.26
[09:48] <mvo> Chipaca: thank you - what do you have in mind to improve it (just curious)
[09:49] <Chipaca> mvo: for now, just switch it to use MATCH
[09:49] <Chipaca> so we know why it failed :-)
[09:49] <Chipaca> the debug output looks very wrong, like something else was going on in parallel
[09:49] <Chipaca> what should be the last thing in the log is way at the top
[09:50] <Chipaca> (the GET /v2/assertions/account-key)
[09:50] <mvo> Chipaca: heh, very good point
[09:51] <mvo> Chipaca: and agreed, the prepare is also doing much and the output of prepare is completly lost so +1 for improving the test
[09:54] <mvo> Chipaca: also thnaks for the note about the test for the "/" in the shortcut branch, I will add this once 2.26 is out, this branch is not really needed for 2.26 I think
[09:54] <pedronis> mvo: Chipaca: fwiw I agree we should have a minimal spread
[09:55] <pedronis> for refreshes
[09:55] <pedronis> s/minimal/minimum/
[09:55] <mvo> +1
[10:28] <ogra_> mvo, so did you have a chance to read through https://forum.snapcraft.io/t/allow-disabling-system-services-on-ubuntu-core/531 ? (i dont want to upload http://paste.ubuntu.com/24549394/ withough your approval)
[10:28] <ogra_> *without
[10:28] <zyga> mvo: so I think the issue is solved
[10:38] <mvo> ogra_: not yet, I will do 2.26 first and then have a look, I think its probably best to do this change after that
[10:39] <mvo> zyga: oh, nice.
[10:39] <ogra_> mvo, ok
[10:39] <mvo> zyga: so no fchdir() - do you still want to fix that?
[10:39] <mvo> zyga: if so, I can wait a little bit longer, if that is the remaining blocker for this kernel
[10:42] <zyga> mvo: not sure yet, I think this may be a bigger issue as I never tested this on a kernel this old
[10:42] <zyga> abeato_: ^
[10:42] <zyga> abeato_: do you want to cherry pick a fix into your kernel
[10:42] <zyga> abeato_: or would you see this as something that needs to change in snap-confine
[10:42] <zyga> mvo: I need to do a survey of what else is failing on 3.4 hybrid
[10:42] <mvo> zyga: ok
[10:44] <abeato_> zyga, if a cherry pick for the kernel fixes it, that is perfectly fne
[10:45] <zyga> abeato_: not sure how large the cherry pick is :)"
[10:45] <zyga> abeato_: who maintains your kernel?
[10:45] <abeato_> hehe, yeah, that i typically the issue
[10:45] <abeato_> zyga, shrirang I guess
[10:47] <mup> PR snapd#3299 closed: timeutil: avoid panicking when the window is very small <Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3299>
[10:48] <zyga> abeato_: ok, I'll refrain from changing anything more until you give me a ping
[10:48] <abeato_> ok
[10:52]  * zyga lunch
[11:20] <pedronis> pstolowski: snapd#3212 has two +1 but the tests failed/are failing
[11:20] <mup> PR snapd#3212: api, ifacestate: resolve disconnect early <Created by stolowski> <https://github.com/snapcore/snapd/pull/3212>
[11:23] <ogra_> ppisati, argh ... http://paste.ubuntu.com/24554186/
[11:28] <ogra_> fgimenez, hmm ... did you revert (or have someone revert) the pi2-kernel in edge ? i released rev30 (same as in beta) yesterday to edge ...
[11:28] <zyga> mvo: is 2.26 tagged now? :)
[11:28] <ogra_> but ...
[11:28] <ogra_> ogra@pi3:~$ snap info pi2-kernel | grep edge
[11:28] <ogra_>   latest/edge:      4.4.0-1048-55 (28) 100MB -
[11:28] <ogra_> ogra@pi3:~$
[11:28] <ogra_> oh, wow ... the store UI shows rev30 in edge ...
[11:29] <zyga> Chipaca: ^^
[11:29] <ogra_> ah, wait
[11:30] <ogra_> my browser has myapps.d.u.c open ...
[11:30] <ogra_> and thats also what i used to release it ...
[11:30] <ogra_> might be a bug in the old UI
[11:30] <Chipaca> zyga: sorry, what?
[11:31] <ogra_> dashboard.snapcraft.io shows the samer the board shows on snap info
[11:31] <zyga> Chipaca: discrepancy between snap info and store, I thought you might be interested
[11:31] <ogra_> zyga, well, the old UI is broken ... works fine when i release via dashboard.s.io
[11:32] <ogra_> we should force-redirect people
[11:32] <ogra_> (half my open browser tabs point to old myapps.* urls)
[11:32] <Chipaca> looks like i don't have store access to pi2-kernel
[11:33] <Chipaca> ogra_: zyga: I don't know what'd happen if you used myapps to push snaps now
[11:33] <Chipaca> hopefully nothing disastrous, but I don't know
[11:33] <Chipaca> Facu: do you?
[11:33] <Chipaca> zyga: in any case, "discrepancy between snap info and store" makes no sense to my addled brain
[11:34] <Chipaca> zyga: you mean SCA and CPI are inconsistent?
[11:34]  * zyga has no idea
[11:34] <zyga> did I mention I didn't sleep long last night
[11:35] <Chipaca> ogra_: can you pastebin the output of 'snapcraft list-revisions --arch armhf pi2-kernel' ?
[11:35] <Facu> hola Chipaca
[11:35]  * Facu reads
[11:35] <Chipaca> ogra_: and the output of 'snap info pi2-kernel' as well
[11:35] <ogra_> Chipaca, its a UI issue ...
[11:35] <ogra_> writing a forum topic now
[11:36] <Chipaca> ogra_: brother UI, UI, UI ♫
[11:36]  * zyga wants to hand out beer to anyone that wants to review  https://github.com/snapcore/snapd/pull/3295/files
[11:36] <mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[11:36] <ogra_> hehe
[11:37] <Chipaca> zyga: i'm working through that
[11:37]  * zyga hugs Chipaca and offers to haul some booze to portugal
[11:37] <Chipaca> zyga: and licorea.es delivers to my house
[11:37] <Chipaca> :-)
[11:37] <zyga> :D
[11:37]  * zyga looks
[11:37] <Chipaca> or was it .com
[11:37] <Chipaca> zyga: .com
[11:37] <zyga> Chipaca: what do you prefer?
[11:38] <Chipaca> zyga: i was j/k
[11:38] <pstolowski> pedronis, oh, this failure looks a bit worrying, and unrelated to my change
[11:41] <Chipaca> pstolowski: which failure?
[11:41] <pstolowski> Chipaca, https://travis-ci.org/snapcore/snapd/builds/231089319?utm_source=github_status&utm_medium=notification
[11:42] <pstolowski> panic after retry, sync: unlock of unlocked mutex
[11:43] <Chipaca> nice
[11:43] <Chipaca> and not related to rand :-)
[11:43] <Chipaca> (so it's not the one i fixed)
[11:43] <ogra_> Chipaca, Facu https://forum.snapcraft.io/t/myapps-developer-ubuntu-com-vs-dashboard-snaopcraft-io/549
[11:44] <Chipaca> ogra_: when you say myapps, do you mean dashboard.snapcraft.io?
[11:44] <Chipaca> ogra_: or do you actually mean myapps?
[11:44] <ogra_> Chipaca, no, i mean https://myapps.developer.ubuntu.com/dev/click-apps/5573
[11:44] <Chipaca> ah
[11:44] <ogra_> (thats the pi2-kernel snap)
[11:45] <Chipaca> right
[11:45] <Chipaca> ogra_: sorry i hadn't finished reading :-)
[11:46] <Chipaca> ogra_: in myapps, what series is the pi2-kernel snap?
[11:46]  * ogra_ waits for the UI to reload 
[11:46] <ogra_> bah
[11:47] <ogra_> it redirected me now :P
[11:47] <ogra_> seems the "overview" like actually does a redirect ... but just reloading or going into one of the versions does not
[11:47] <ogra_> s/like/link
[11:48] <Chipaca> ogra_: in the list of all your packages in myapps, it lists the series of the snap. what does it show for pi2-kernel?
[11:49] <ogra_> Chit doesnt show it at all
[11:49] <ogra_> Chipaca, ^^
[11:49] <ogra_> "Ubuntu Touch clicks and snaps for 15.04"
[11:49] <Chipaca> ogra_: screenshot or it didn't happen
[11:50] <Chipaca> because i'm seeing the series for everything, there
[11:50] <ogra_> it shows all 15.04 packages i own ...
[11:50] <ogra_> and says at the bottom "Your series 16 snaps can now be found at https://dashboard.snapcraft.io."
[11:51] <Chipaca> ogra_: http://imgur.com/a/RQFnG
[11:51] <Chipaca> ogra_: in the list of revisions
[11:51] <ogra_> so i guess the frontpage as well the the package overview are fine ... (since that actually redirects me) ... but when i'm on the old page and click on a version on myapps it does not redirect
[11:51] <Facu> ogra_, do you see pi2-kernel in myapps?
[11:51] <Chipaca> ogra_: it shows you the series
[11:51] <Chipaca> ogra_: my question is, in that list of the pi2-kernel, what does it show
[11:51] <ogra_> Facu, not on the frontpage ... but in the myapps pages i have open i can still navigate around myapps
[11:52] <Chipaca> ogra_: myapps is still active and functional for clicks and 15.04 snaps
[11:52] <ogra_> Facu, i guess there is simply no redirect on pages that are deeper down the tree
[11:53] <ogra_> Chit doesnt show the pi2.-kernel in that list ... but it doesnt redirect me if i'm on an old myapps site and click some version to set the checkmark on a channel
[11:53] <ogra_> Chipaca, ^^
[11:53] <ogra_> (geez ... cant get used to type three chars for tab completion )
[11:53] <Chipaca> ogra_: how did you get to the old myapps site?
[11:53] <Facu> ogra_, so, the scenario is that you had a page open showing a snap in myapps from a month ago, and now you go back to using it and it shows the snap info?
[11:53] <ogra_> Chipaca, it is open in my broiwser
[11:54] <Chipaca> ogra_: you must have a terabyte of ram :-)
[11:54] <Chipaca> but ok
[11:54] <Chipaca> Facu: over to you :-)
[11:54] <pedronis> pstolowski: seems there's a codepaht in retryPostRequestDecodeJSON that returns nil, nil ?
[11:54] <ogra_> Facu, it had it open and clicked on one of the versions ... did set a checkmark on a channel and went back to the overview
[11:54] <ogra_> Facu, so the version links should simply redirect me too ... seems the "overview" one already does
[11:55] <Facu> ogra_, or at least give some error
[11:55] <ogra_> right
[11:55] <Facu> ogra_, not leaving you with the impression "it worked"
[11:55] <ogra_> yeah
[11:56] <Chipaca> Facu: do myapps and the dashboard share a backend database?
[11:56] <Facu> Chipaca, not sure
[11:59]  * ogra_ adds a followup to the forum
[11:59] <pstolowski> pedronis, checking
[12:00] <pedronis> pstolowski: the traceback seems to say we explode on auth.go:306
[12:02]  * Chipaca poddles off to investigate lunch
[12:03] <zyga> Chipaca: do it
[12:03] <zyga> Chipaca: but beware
[12:03] <zyga> after lunch all I want is sleep
[12:03] <zyga> and I think I will just do it
[12:03] <Chipaca> i see no problem
[12:03] <zyga> I may miss standup if I succeed
[12:04] <zyga> if I do, I'll wake up and look at PRs and update-ns
[12:04] <zyga> I think release is in good hands
[12:04] <zyga> and apart from panick on unlock I think it's okay
[12:05] <mvo> zyga: I'm about to finalize the release
[12:12] <ppisati> ogra_: what did you do to get that?
[12:12] <ogra_> ppisati, obviously running 4.4.0-1048-55  pi2 ... thats outrdated though, i guess you can ignore it
[12:13] <ppisati> ogra_: oh ok
[12:13] <ogra_> i only noticed later that the kernel was old .... i'tt shout if i see it with a newer one again
[12:13] <ogra_> *i'll
[12:13] <ppisati> ogra_: ack
[12:13]  * Chipaca hugs mvo for being awesome (and because of read -r)
[12:14] <Chipaca> it's the missing bit that makes in-snap tab completion purrfect
[12:14] <Chipaca> i was dreading digging through it to figure this one out :-)
[12:22] <pstolowski> pedronis, i'm going to create a test to try reproduce
[12:26] <ali1234> ugh... why doesn't "snapcraft clean <part> -t <step>" work?
[12:44] <pedronis> pstolowski: I'm not sure at all how it happens, but reading the traceback it would seem resp == nil (or I'm missing something something), that's the thing we read on 306
[12:50] <niemeyer> Hello all
[12:50] <niemeyer> How's spread behaving this morning?
[12:50] <niemeyer> fgimenez: ^
[12:51] <fgimenez> hey niemeyer all good, the execution times have reduced to ~30min
[12:51] <niemeyer> fgimenez: Cool..  slightly over or slightly under?
[12:52] <fgimenez> niemeyer: about 10min lower
[12:52] <niemeyer> fgimenez: Sorry, I mean, slightly over 30 or sightly under 30
[12:53] <pstolowski> pedronis, i thought the same, but it's strange, we should be remembering and returning the most recent error
[12:53] <fgimenez> niemeyer: ah :) under, 28 or so, i hope to have proper metrics soon
[12:54] <niemeyer> fgimenez: Okay, that's great!
[12:54] <niemeyer> fgimenez: That means we can probably hit the 20 mins mark with another bump today
[12:55] <fgimenez> niemeyer: yep, the remaining 50% should put the build close to 20min
[12:55] <niemeyer> fgimenez: Can you please push another PR with that change?
[12:55] <fgimenez> niemeyer: sure on it
[12:55] <niemeyer> fgimenez: I'll keep an eye on resource utilization today and see whether we need more and how many
[12:56] <niemeyer> Actually, we can probably guess the right number of machines from the Travis concurrency limit
[12:57] <lazyPower> Correct me if i'm wrong, but is there a way to mount your snap from PWD instead of building the squashfs image? I'd like to debug my config hook and interactively execute some bits to test a script. I dont feel like i can do that reliably in the squashfs image... its read only in that context.
[12:57] <lazyPower> i thought i recalled hearing about a path to do that, but i'm at a loss for finding it in the docs on snapcraft.io
[12:57] <Chipaca> lazyPower: "snap try"
[12:57] <lazyPower> aha! ty
[12:57] <Chipaca> np
[12:58] <Chipaca> so many mups!
[12:58] <niemeyer> Uh?
[12:58] <ogra_> mupvasion!
[12:58] <Chipaca> niemeyer: one on ipv4, one on ipv6
[12:59] <niemeyer> Ah.. that explains it
[12:59] <niemeyer> Network is probably not so happy
[13:00] <ogra_> network mupocalypse!
[13:04] <mup> PR snapd#3301 opened: spread.yaml: increase the number of linode workers by 1 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3301>
[13:10] <niemeyer> morphis: Standup?
[13:26] <mup> PR snapd#3302 opened: release: releasing package snapd version 2.26 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3302>
[13:47] <Chipaca> mvo: in the second answer to that sd wear levelling question there's a link to bunnie pointing out that adding a wear levelling controller is cheaper than doing QA, so zyga's probably right in practice except for the most cheapestest cards (that don't do QA either way)
[13:48] <mvo> Chipaca: yeah, that is my understanding of how this works too
[13:48] <Chipaca> ok
[13:48] <mvo> Chipaca: the controller lies to you but thats ok
[13:48] <mvo> s/you/us/
[13:50] <rharper> ogra_: thanks, I'll add that to the list
[13:54] <mup> PR snapd#3300 closed: cmd/snap-confine: don't fail on pre 3.8 kernel <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3300>
[13:55] <zyga> https://github.com/snapcore/snapd/pull/3289 needs a 2nd review
[13:55] <mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
[13:59] <pstolowski> pedronis, got a test which reproduced the panic; it's enough to have a host name for the store server that doesn't resolve
[14:00] <zyga> !
[14:00] <zyga> wow
[14:02] <pstolowski> and I think I've a fix. and I think (but need to verify) this problem is unique to this single case of retry
[14:03] <pstolowski> the problem is err got shadowed
[14:08] <zyga> pstolowski: don't we have a static analyzer that looks for variables that are assigned to but not used?
[14:08] <pedronis> pstolowski: ah, the NewRequest line has :=
[14:08] <pedronis> :/
[14:09] <zyga> is that something we want to fix for 2.26 ?
[14:09] <pstolowski> pedronis, yeah...
[14:10] <pedronis> pstolowski: := creates all new variables
[14:10] <pstolowski> zyga, it is used.. the func is defined as func(..) (err error, resp Response)
[14:10] <pstolowski> pedronis, yeah I know. oversight.
[14:11] <pedronis> pstolowski: was this code new in 2.25 ?
[14:11] <pedronis> zyga: mvo: we might need a 2.25.1
[14:12] <pedronis> pstolowski: so we were missing tests, for exiting on timeout of retries ?
[14:12] <pstolowski> pedronis, I need to check this still
[14:13] <pedronis> pstolowski: the code in store.go does have this problem it seems, only auth.go
[14:13] <pstolowski> pedronis, yes I think so, but I'll add a test to store too
[14:17] <pedronis> pstolowski: code seems to have been already there in 2.23 at least
[14:18] <pstolowski> pedronis, yes, commits are from Jan 27
[14:18] <pedronis> it's not a regression but if I understand correctly it's also not very nice
[14:18] <pstolowski> yes it's pretty bad actually
[14:19] <pedronis> pstolowski: I let you and mvo decide what to do
[14:20] <pstolowski> if you ask me, I'd include the fix in this release... now sure how much hassle that is for mvo
[14:41] <mup> PR snapd#3303 opened: store: fix panic error in auth <Created by stolowski> <https://github.com/snapcore/snapd/pull/3303>
[14:41] <pstolowski> pedronis, mvo ^
[14:42] <mvo> pstolowski: cool, looking
[14:43] <mvo> pstolowski, pedronis: a 2.26.1 works for me, let me check the fix
[14:46] <mvo> pstolowski: woah, how does this happen?
[14:47] <zyga> mvo: this looks like a bug I fixed in the interface code a few months ago
[14:47] <zyga> mvo: the same pattern
[14:48] <fgimenez> mvo: we are getting this error in prepare https://travis-ci.org/snapcore/snapd/builds/231151352#L1235 it seems that there's a new version of ubuntu-image, could you please take a look when you have a moment?
[14:48] <pstolowski> mvo, err got shadowed... the test panics the same way without the fix
[14:48] <morphis> niemeyer: sorry, was out around that time today, told zyga yesterday
[14:48] <mvo> pstolowski: ohhh, shadowing. that makes sense
[14:49] <mvo> fgimenez: sure, I have a look now
[14:50] <mvo> fgimenez: could we simply switch --dvmode to --classic in the test to fix the error?
[14:50] <fgimenez> mvo: i think so, let me check
[14:50] <mvo> fgimenez: thank you
[14:57] <mvo> fgimenez: we need to do 2.26.1 anyway now if all our tests are broken
[14:57] <mvo> fgimenez: which is slightly annoying because the older spread-cron runs will also break now, no?
[14:58] <mvo> fgimenez: so maybe we need to ask foundations to revert this
[14:58] <fgimenez> mvo: np for spread-cron, most of the executions have finished but yes, with errors
[14:59] <pstolowski> mvo, sorry for adding more work with .1 :(
[14:59] <mvo> hey sil2100, good afternoon
[14:59] <sil2100> Hey o/
[14:59] <mvo> sil2100: quick question, it looks like ubuntu-image has changed to classic confinement recently?
[15:00] <sil2100> mvo: yes, after some discussions with various people barry thought that it's more fitting for this confinement
[15:00] <mvo> sil2100: this is currently breaking tests on our side and I wonder what the best way forward is. maybe just us fixing the tests but it means ubuntu-imgae can not be used on a ubuntu-core system anymore which is slightly odd
[15:01] <mvo> fgimenez: can we fix spread-cron easily to use --classic when we generate the images?
[15:01] <sil2100> https://bugs.launchpad.net/ubuntu-image/+bug/1638645
[15:01] <mup> Bug #1638645: Make ubuntu-image a classic snap <Ubuntu Image:Fix Released by barry> <https://launchpad.net/bugs/1638645>
[15:01] <sil2100> This is the relevant bug
[15:01] <mvo> sil2100: thank you. let me read it
[15:02] <fgimenez> mvo: sure np, we also need to fix snapd's prepare https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L177
[15:04] <mvo> sil2100: thanks, I'm not sure this is the best decision but I think we can fix it on our side. I may come back to you and ask for !classic at some point mostly because it seems like it should also work on core systems. but I think for now we are ok. thanks for pointing me to the relevant bug
[15:04] <mvo> fgimenez: yeah, I will do that now
[15:04] <fgimenez> mvo: great thanks!
[15:04] <mvo> fgimenez: it breaks all branches currently
[15:05] <mvo> fgimenez: and our spread-cron and other tests use a different prepare than the one in our snapd git, right?
[15:07] <morphis> Pharaoh_Atem: ping
[15:07] <mup> PR snapd#3304 opened: tests: the new ubuntu-image snap needs classic confinement, adjust tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3304>
[15:07] <Pharaoh_Atem> morphis: pong
[15:07] <fgimenez> mvo: usually not, the suite is the same only tweaked setting the appropriate environment variables, there are cases where it is different, like the nightly or nested suites, ubuntu-image would affect only the nested suite i think, where we need to create and boot an instance
[15:08] <morphis> Pharaoh_Atem: you saw my comments on bodhi?
[15:08] <sil2100> mvo: ok, no problem! I guess we're open to suggestions regarding that
[15:09] <mvo> pstolowski: no worries, this is a reason we need 2.26.1 anyway I think so all is good
[15:09] <Pharaoh_Atem> morphis: yeah, I'm going to fix it asap and push a new build
[15:09] <mvo> pstolowski: this being the uubntu-image fallout
[15:10] <pstolowski> ok
[15:10] <Pharaoh_Atem> morphis: what files are created by snapd to manage things?
[15:10] <morphis> Pharaoh_Atem: thanks!
[15:10] <Pharaoh_Atem> I can add them as %ghost files so that rpm deletes them correctly
[15:10] <sil2100> mvo: I think we just looked and saw classic to fit our case the best (as it's a tool like that) and it fixed our problems with /tmp
[15:11] <Pharaoh_Atem> morphis: is it just /var/lib/snapd/state.json, or are there other things?
[15:11] <morphis> Pharaoh_Atem: other things too
[15:11] <mvo> sil2100: yeah, the /tmp being a tmpfs is certainly annoying for the u-i use-case
[15:11] <Pharaoh_Atem> morphis: do you have a list?
[15:11] <morphis> Pharaoh_Atem: it looks like even the directories the rpm ships aren't cleared
[15:11] <ogra_> sil2100, that makes it pretty much impossible to use ubuntu-image natively in some kind of ubuntu-core installer (where you would boot an ubuntu-core and run ubuntu-image to create a fresh image tailored for a target device), there is no support for classic interfaces on core
[15:11] <morphis> Pharaoh_Atem: there is no "purge" option for dnf, right?
[15:11] <Pharaoh_Atem> apt's purge comes from dpkg, so no
[15:11] <morphis> ok
[15:11] <morphis> Pharaoh_Atem: I can give you a list later, currently
[15:12] <Pharaoh_Atem> that'd be helpful
[15:12] <morphis> my system is loaded :-)
[15:12] <Pharaoh_Atem> I can `%ghost` all the files that snapd itself creates so that on final uninstall, rpm clears them
[15:14] <niemeyer> morphis: No worries!
[15:16] <morphis> Pharaoh_Atem: ok, let me give you the list and we can fix that
[15:16] <Pharaoh_Atem> excellent
[15:16] <morphis> Pharaoh_Atem: otherwise the script works well on suse too so we should generalize it a bit more and push to the repo so all distros can use it
[15:19] <Pharaoh_Atem> morphis: that's the plan :)
[15:19] <morphis> Pharaoh_Atem: great :-)
[15:19] <Pharaoh_Atem> I'd like to minimze what this script does as much as possible because I want the package manager to be as aware as possible
[15:19] <sil2100> mvo, ogra_: could anyone of you open a bug for it for discussion?
[15:23] <morphis> ogra_: did you ever try to boot one of our armhf core images in qemu?
[15:24] <ogra_> morphis, well, on what HW emulation ?
[15:24] <ogra_> does our qemu have any Pi or dragonboard emulation ?
[15:24] <morphis> ogra_: just did a first attempt to boot a pi3 image
[15:25] <morphis> ogra_: good question, was looking which could be used
[15:25] <ogra_> i dont think there is
[15:25] <ogra_> there is something for an early beagleboard (not bone)
[15:26] <morphis> hm
[15:26] <ogra_> but thats srtill omap i think
[15:26] <morphis> -M vexpress-a9 -cpu cortex-a9 might be a start but not for the pi images
[15:27] <morphis> we would need a more common kernel snap
[15:28] <ogra_> sil2100, mvo i opened https://bugs.launchpad.net/ubuntu-image/+bug/1690170 ... mvo might be good if you could also add soemthing
[15:28] <mup> Bug #1690170: classic confinement makes running ubuntu-image inside UbuntuCore images impossible <Ubuntu Image:New> <https://launchpad.net/bugs/1690170>
[15:28] <sil2100> ogra_: thanks
[15:29] <morphis> ogra_: https://wiki.ubuntu.com/Kernel/Dev/QemuARMVexpress suggests the lpae kernel should do the job
[15:29] <ogra_> morphis, well ... vexpress
[15:29] <ogra_> you'd need a kernel and gadget for that
[15:29] <morphis> right
[15:29] <ogra_> and it will crawl
[15:29] <morphis> hm
[15:30] <ogra_> not sure thats worth the effort (unless it improved massively since i used it last ... which is admittedly a while ago)
[15:31] <pstolowski> oh my
[15:31] <morphis> just wondering if using real hardware is the best approach these days to support our spread testing for armhf only snaps or if we can use qemu for a few things too
[15:31] <pstolowski> so my DNS test fails differently on travis than locally :/
[15:31] <fgimenez> morphis: i did something about qemu and pi2 but it didn't manage to boot https://github.com/fgimenez/pi2-qemu if you want to have a look
[15:31] <ogra_> you should be able to us4e kvm on arm64 ...
[15:31] <pstolowski> error string = "cannot query the store for updates: got unexpected HTTP status code 503 via POST to \"http://nonexistingserver909123.com/updates/\""
[15:31] <ogra_> but i'm not sure how the armhf emulation on top of that is
[15:31] <morphis> ogra_: we get armhf only binaries delivered we have to use
[15:31] <morphis> fgimenez: nice! will have a look
[15:31] <pstolowski> instead of ""Post http://nonexistingserver909123.com/updates/: dial tcp: lookup nonexistingserver909123.com on .*: no such host" locally
[15:32] <ogra_> morphis, yes, i meant an armhf kvm on top of an arm64 server
[15:32] <morphis> ah
[15:32] <pstolowski> Chipaca, hey, do you have any idea why this could be? ^
[15:32] <ogra_> morphis, i know we use kvm for the arm64 buildds ... perhaps wgrant knows if it is possible to use armhf machines on that
[15:32] <morphis> fgimenez, ogra_: http://blog.3mdeb.com/2015/12/30/emulate-rapberry-pi-2-in-qemu/
[15:33] <ogra_> ah, a patch :)
[15:33] <morphis> fgimenez: see you're using -M raspi2, were you using this tree for qemu?
[15:34] <niemeyer> pedronis: On it
[15:34] <pedronis> niemeyer: thx, sorry for wrong channel
[15:34] <niemeyer> pedronis: np, I didn't realize I was replying in a different channel, sorry
[15:34] <Chipaca> pstolowski: what do you mean?
[15:34] <Chipaca> it's not resolving
[15:34] <Chipaca> ¯\_(ツ)_/¯
[15:34] <niemeyer> pedronis: (read in the pop up)
[15:35] <fgimenez> morphis: nope, qemu from the archive, afaik the (partial) support is available from 2.6? need to check
[15:35] <ogra_> ooh !
[15:35] <ogra_> now thats cool
[15:35] <morphis> fgimenez: but you didn't used xenial, right?
[15:35] <morphis> didn't saw a raspi machine on the xenial qemu
[15:35] <pstolowski> Chipaca, it's not resolving when run locally, but gives 503 on travis (?!)
[15:36] <pedronis> pstolowski: because there's a proxy setup
[15:36] <pstolowski> Chipaca, see my comment to https://github.com/snapcore/snapd/pull/3303
[15:36] <mup> PR snapd#3303: store: fix panic error in auth <Created by stolowski> <https://github.com/snapcore/snapd/pull/3303>
[15:36] <pstolowski> ahh
[15:36] <fgimenez> morphis: no, yakkety
[15:36] <morphis> fgimenez: ah
[15:36] <pedronis> pstolowski: so you get the 503 (from the proxy)
[15:36] <pstolowski> right
[15:37] <pstolowski> in that case I've no better idea than to dumb the check to only see if err != nil
[15:37] <niemeyer> pedronis: Done
[15:38] <morphis> ogra_: ok, current git tree of qemu has the raspi machine
[15:38] <ogra_> make a snap ;)
[15:39] <Chipaca> pstolowski: I'm going to ahead and guess that there's an http proxy that 503s when it can't resolve
[15:39] <morphis> ogra_: you can read my mind :-)
[15:39] <Chipaca> (when using an http proxy the client isn't the one doing the dns lookup)
[15:39] <ogra_> *g*
[15:39] <Chipaca> ah, what pedronis said
[15:40] <Chipaca> sorry for the latency :-)
[15:40] <pedronis> pstolowski: does snapd#3120 needs a test rerun or a new merge with master?
[15:40] <mup> PR snapd#3120: interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3120>
[15:40] <pstolowski> Chipaca, yep. thanks
[15:43] <pstolowski> pedronis, no, its spread test needs some work. I abused content interface there for a test, and what I did there needs changing
[15:44] <niemeyer> Lunch here
[15:49] <morphis> Pharaoh_Atem, zyga: 2017/05/11 17:47:26 Successful tasks: 89
[15:49] <Pharaoh_Atem> ?
[15:49] <morphis> Pharaoh_Atem, zyga: we're coming close to 100 working spread tests on Fedora :-)
[15:49] <Pharaoh_Atem> ah
[15:50] <Pharaoh_Atem> nice
[15:51] <zyga> morphis: very nice; I'd like to discuss how we are going to support testing that is cross distribution
[15:51] <zyga> morphis: I'd love to see your branches for that
[15:51] <zyga> morphis: we need something that is scalable
[15:51] <morphis> zyga: right
[16:10] <mup> PR snapd#3304 closed: tests: the new ubuntu-image snap needs classic confinement, adjust tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3304>
[16:11] <zyga> mvo: master is good again, we can merge it into failed PRs
[16:34] <Chipaca> zyga: Q:    cat /var/lib/snapd/apparmor/profiles/snap.test-snapd-devmode.test-snapd-devmode | grep attach_disconnected | grep -v complain
[16:34] <Chipaca> zyga: you're wanting to check that nothing that has attach_disconnected has complain?
[16:35] <Chipaca> zyga: (also there's a bug in this test where apparmor is checked for @complain)
[16:39] <nacc> is there a store way to say that a given snap has been replaced by another (and have end-users automigrate)?
[16:40]  * zyga tries to parse Chipaca's question
[16:40] <Chipaca> oh dear, store is taking a break
[16:40] <zyga> Chipaca: why would I want to check that nothing that has attach_disconnet has complain?
[16:40] <Chipaca> zyga: i dunno! you wrote the test :-)
[16:41] <zyga> ah, which test is that?
[16:41] <Chipaca> regression-jailmode-1641885
[16:41] <zyga> so the first grep just gives us the right line
[16:41] <zyga> the second test is checking for the interesting part
[16:41]  * zyga looks 
[16:42] <ogra_> hmm
[16:42] <Chipaca> Facu: is CPI AWOL?
[16:42] <zyga> Chipaca: indeed, I see the bug
[16:42] <ogra_> where is my channel info gone ?
[16:42] <ogra_> http://paste.ubuntu.com/24555462/
[16:42] <Chipaca> ogra_: CPI is not responding
[16:43] <ogra_> ouch
[16:43]  * zyga drinks to CPI
[16:43] <ogra_> oh, beer time!
[16:43] <mvo> zyga: thank you, just returned from dinner, checking out the sttaus now
[16:44] <zyga> mvo: the status may be ^^ bad
[16:44] <mvo> zyga: yeah, just noticed
[16:44] <mvo> jinxed again
[16:44] <mvo> sound like I can extend my dinner ;)
[16:44] <mvo> at least tests are pretty fast now
[16:44] <zyga> Chipaca: sorry for asking dumb question but what is about that test?
[16:44] <ogra_> "i got fat because of bugs"
[16:44] <zyga> Chipaca: I get that the seccomp part is bogus
[16:44] <zyga> Chipaca: (fixed locally)
[16:45] <Chipaca> zyga: I'm in the middle of fixing a bunch of those, can do this in drive-by
[16:45] <Chipaca> zyga: it's just a s/apparmor/seccomp/ in te path, right?
[16:45] <zyga> Chipaca: the apparmor part is as you predicted, we want to check that the profile is not in complain mode
[16:45] <zyga> Chipaca: yes
[16:45] <zyga> Chipaca: if you fix that I can remove my branch now :)
[16:45] <Chipaca> yes
[16:45] <zyga> Chipaca: can you please also git mv the test to regression/ ?
[16:45] <Chipaca> it's already fixed here :-)
[16:45] <zyga> thanks!
[16:46]  * zyga would like to see PR count drop below 20 today
[16:47] <mup> PR snapd#3302 closed: release: releasing package snapd version 2.26 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3302>
[16:48] <mup> PR snapd#3305 opened: release: snapd 2.26 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3305>
[16:50] <mup> PR snapd#3306 opened: tests/main: move a bunch of greps over to MATCH <Created by chipaca> <https://github.com/snapcore/snapd/pull/3306>
[16:50] <Chipaca> zyga: ^
[16:51]  * zyga nice, looking
[16:51] <Chipaca> http://status.snapcraft.io/
[16:51] <zyga> LOL
[16:51] <zyga> mvo: ^
[16:51] <zyga> mvo: look at that with umatrix
[16:54] <kyrofa> noise][, nessita I'm trying to refresh and getting this: "error: cannot refresh "nextcloud": cannot get refresh information for snap "nextcloud": Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"
[16:54] <kyrofa> Are there known issues right now?
[16:54] <Chipaca> kyrofa: store is down
[16:54] <Chipaca> kyrofa: see status.snapcraft.io
[16:54] <kyrofa> Huh, so it is
[16:54] <noise][> Chipaca: apparently a lot of stuff down
[16:55] <Chipaca> noise][: yeah
[16:55] <Chipaca> bah
[16:55] <Chipaca> things like ubuntu.com :-)
[16:55] <Chipaca> psh
[16:55] <Chipaca> :-D
[16:55] <kyrofa> As soon as I post a call for testing! Hahaha
[16:55] <Chipaca> kyrofa: so it's *your* fault!
[16:56] <ogra_> Chipaca, ubuntu.com isnt down ... i still get a proper 503 page :P
[16:56] <kyrofa> Hahaha
[16:56] <zyga> oh
[16:56] <zyga> someone tripped over the wrong cable?
[16:57] <ogra_> or took it with him when leaving
[16:59] <zyga> Chipaca: grep -c, what does it count?
[16:59] <zyga> matches?
[16:59] <Chipaca> matching lines
[17:00] <Chipaca> echo aaa|grep -c a == 1
[17:00] <zyga> ah, I see
[17:01] <ogra_> equivalent to "grep | wc -l"
[17:02] <zyga> one day someone will write a shell that contains a static anaylzer that rewrites stuff like "grep | wc -l" into proper optimized code
[17:02] <zyga> all the core utilities have grown over time, to accumulate more and more options
[17:02] <zyga> as optimization for what we do
[17:03] <Chipaca> that's like saying that one day we'll sit down with the openbsd guys and unify everything
[17:03] <Chipaca> their 'morse' program is so much cooler than the one in ubuntu
[17:04] <kyrofa> Have we tweeted that we know the world is broken?
[17:04] <zyga> Chipaca: no, we would never do that
[17:05] <zyga> Chipaca: but a program might
[17:05] <zyga> kyrofa: my twitter is broken
[17:05] <kyrofa> zyga, THAT cable TOO?
[17:05] <ogra_> ... -. .- .--. .--. -.--
[17:06] <Chipaca> ogra_: https://www.freebsd.org/cgi/man.cgi?query=morse&sektion=6&manpath=FreeBSD+6.4-RELEASE
[17:06] <ogra_> hah, cool
[17:06] <Chipaca> see?
[17:06] <Chipaca> :-)
[17:06] <zyga> is that in CVS?
[17:07] <zyga> actually nice :)
[17:07] <jdstrand> noise][, nessita: fyi, getting 503 going to https://dashboard.snapcraft.io/dev/snaps/reviewer/
[17:07] <kyrofa> jdstrand, yeah everything is busted
[17:07] <Chipaca> ogra_: I especially like the bit in HISTORY
[17:07] <ogra_> jdstrand, so better go to www.ubuntu.com then
[17:07] <ogra_> :P
[17:07] <zyga> is there a morse-modem so I can connect my PCs with pc-speakers and microphones and setup IP over that?
[17:07] <Chipaca> ogra_: where people sign with their callsigns
[17:07] <zyga> jdstrand: it's broken
[17:07] <jdstrand> noise][, nessita: seems you probably already know that. ignore me
[17:07] <noise][> there's a major network outage affecting multiple services
[17:07] <zyga> jdstrand: status.snapcraft.io
[17:08] <jdstrand> ok
[17:08] <noise][> i posted to the forum as well
[17:08] <Chipaca> anyway, seeing as everything is down, I'm going to EOD right about now.
[17:08]  * zyga imagines IP over two 90's era text-to-speach and speach-to-text systems
[17:08] <ogra_> farnsworth support !
[17:08] <zyga> Chipaca: yeah :/
[17:08] <zyga> Chipaca: I think that's the best to do
[17:08] <zyga> I'll finish with your PR and I'll call it a day
[17:09] <zyga> when the boat is on fire, you just take a swim and let others mend the fire ;)
[17:09] <Chipaca> zyga: teamwork \o/
[17:13] <mvo> zyga: heh, funny indeed, let me whitelist some things
[17:13] <mvo> zyga: autsch, the status is slightly depressing
[17:13] <zyga> mvo: thank you!
[17:14] <zyga> mvo: on the upside, nobody will download the release anyway
[17:14] <mvo> zyga: enjoy, I will see if I can do 2.26.1 today, if not, well, tomorrow morning
[17:14] <mvo> zyga: hahahaa
[17:14] <zyga> :)
[17:14]  * zyga goes over some PRs
[17:15] <mup> PR snapcraft#1310 closed: tests: use C.UTF-8 for the docker locale <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1310>
[17:18] <zyga> drat, we have 26 PRs again
[17:18] <zyga> mvo: I think you can override-merge https://github.com/snapcore/snapd/pull/3301
[17:18] <mup> PR snapd#3301: spread.yaml: increase the number of linode workers by 1 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3301>
[17:19] <mvo> zyga: yeah, why not
[17:19] <zyga> wow, chipaca did review https://github.com/snapcore/snapd/pull/3295 :D
[17:19] <mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[17:19] <zyga> awesome!
[17:19] <mup> PR snapd#3301 closed: spread.yaml: increase the number of linode workers by 1 <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3301>
[17:42] <zyga> mvo: so it still doesn't work (in fact more services are down)
[17:42] <zyga> mvo: I pushed fixes to several branches, did some more code reviews
[17:42] <niemeyer> Need to step out for ~1h..
[17:42] <zyga> mvo: and I think it's the best time to stop
[17:42] <zyga> in the evening I'll check back and push udpdate-ns as all-in-one
[17:44] <cratliff> Are there any plans for the catkin plugin to use catkin build instead of catkin_make?  If not, would this be a welcome change?
[18:10] <kyrofa> cratliff, yeah I like catkin build as well
[18:10] <kyrofa> cratliff, but it's not the standard-- I'm not sure what kind of ramifications moving to it would have
[18:11] <kyrofa> cratliff, would love to hear your thoughts
[18:15] <cratliff> kyrofa:  I'm fairly new to both ROS and snap, I just found out about catkin build today.  Using catkin build reduces my build time by about 10 minutes. It seems to build in isolated by default so I don't think there would be a big change in that regard.  The docs page has a list of make -> build translations.  If treated as simply a parallelized catkin_make it doesn't look to onerous, but is seems to have alot of additional feature
[18:15] <pstolowski> is something terribly broken in master or with linode right now? got plenty of errors with my fix-panic branch
[18:16] <ogra_> pstolowski, could they be related to the datacenter outage ?
[18:16] <kyrofa> cratliff, yeah it's a bit more reminiscent of rosbuild, back in the fuerte days
[18:16] <ogra_> (seems to all be up again now, but it lasted quite a while and affected a lot of services including store)
[18:17] <pstolowski> ogra_, dunno, i wasn't aware of it
[18:17] <kyrofa> cratliff, there are some hacks in the catkin plugin that were necessary because of catkin, when I know the issues were fixed in catkin build. If you're interested in taking a crack at that migration I'd be happy to review/test it out
[18:19] <cratliff> Would having it as a separate plugin be a bad move since it isn't considered standard? The news announcement for it on ros.org seems like they think well of it at least.
[18:21] <kyrofa> cratliff, might be easy to start that way. As an end user, what specifically would you notice? Just an increase in build speed?
[18:24] <kyrofa> cratliff, I think the best reason to keep it as a separate plugin is probably "This package was announced in March 2015 and is still in beta. See the GitHub Milestones for the current release schedule and roadmap."
[18:24] <kyrofa> If their API breaks, so does the plugin until we fix it
[18:30] <kyrofa> cratliff, but I think we can make it a beta plugin, or beta mode on the catkin plugin, for now. I'd love to see it in there
[18:30] <cratliff> kyrofa: An increase in speed is probably the biggest thing that would be noticeable, being able to get use out of scaling up to more cores and seeing something for it is nice.  It seems to have some more clean options.  I wonder if those could be used to make the clean step more robust as well, right now I have to clean everything for a new build.
[18:32] <kyrofa> cratliff, indeed, that's something snapcraft needs to improve generally
[18:33] <kyrofa> (definitely on the roadmap)
[18:36] <kyrofa> cratliff, indeed, it looks like the migration from catkin_build_isolated is incredible straight-forward
[18:36] <kyrofa> cratliff, is that something you're interested in doing, then?
[18:37] <kyrofa> I'd be happy to help you learn the codebase/get tests running etc.
[18:38] <cratliff> kyrofa, cool, I might be able to start on it next week depending on other responsibilities.  That would be great.
[18:38] <kyrofa> cratliff, I'm in the PST timezone. Just ping me :)
[18:39] <cratliff> kyrofa, sounds good. I'm in EST.
[18:39] <kyrofa> Easy then! I look forward to working with you
[18:40] <kyrofa> pedronis, can I use private snaps in a model assertion?
[18:53] <kyrofa> zyga, perhaps you know? ^^
[18:56] <kyrofa> noise][, status.snapcraft.io is all green, but I still can't refresh (same error)
[18:57] <noise][> kyrofa: the api server is reachable but getting hammered right now, we're working on it
[18:58] <jdstrand> zyga: fyi, this was pointed out to me: https://tingping.github.io/2017/05/11/flatpak-theming.html
[18:59] <jdstrand> zyga: it has some grammatical issues, but the idea is interesting. flatpak has runtimes (eg, gnome2.34, gnome2.16, etc. so, you install a theme as a flatpak that targets the runtime, then every flatpak that targets that runtime gets that theme
[19:01] <jdstrand> zyga: so, you install arc flatpak theme for 2.34 and 2.16 runtimes, then all flatpaks that target those runtimes gets arc. install a flatpak that target 2.10 runtime and it doesn't (until you install the arc flatpak for 2.10)
[19:02] <jdstrand> zyga: it is an interesting idea. content snaps are roughly equivalent to flatpak runtimes, so it seems plausible to be able to extend a content snap with a theme snap
[19:02] <jdstrand> zyga: ok, going back to other work, but thought I'd pass that along :)
[19:20] <pedronis> kyrofa: yessish, but it won't refresh unless you login on the device, we don't have atm ways to open a private snapd to devices vs users, we usually use branded stores to have device-limited snaps
[19:21] <kyrofa> pedronis, very good, makes sense, thank you :)
[19:21] <pedronis> s/private snapd/private snap/
[19:43] <mup> PR snapd#3303 closed: store: fix panic error in auth <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3303>
[19:47] <Facu> sergiusens_, elopio, reading this https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347 and wondering if it should mention something about https://bugs.launchpad.net/snapcraft/+bug/1670471 or https://bugs.launchpad.net/snapcraft/+bug/1686162
[19:47] <mup> Bug #1670471: Bad message after failed release <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1670471>
[19:47] <mup> Bug #1686162: Support "branch"es in Store responses <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1686162>
[19:49] <kyrofa> Hey jdstrand, seeing these on an lxc host with a guest running the nextcloud snap. Are they of concern? http://pastebin.ubuntu.com/24556341/
[19:52] <kyrofa> That's during an upgrade
[19:53] <kyrofa> jdstrand, and I'm hitting weird issues when upgrading (hook failures), so I'm wondering if that could be the cause
[19:54] <kyrofa> jdstrand, opened this topic: https://forum.snapcraft.io/t/cannot-update-to-revision-introducing-configure-hook/556
[19:55] <kyrofa> This actually might explain why other snap updates have not gone so smoothly on lxc. I always had to reboot to get it up and running
[20:01] <jdstrand> kyrofa: the stdout is fixed in master and for sure in 2.26. /me checks 2.25
[20:02] <jdstrand> kyrofa: yes, and 2.25
[20:02] <kyrofa> jdstrand, would that explain the hook failure I'm seeing?
[20:03] <jdstrand> kyrofa: that denial should be harmless. the systemctl denial would cause things to fail I suspect. it is probably trying to manage its daemon's service
[20:03] <kyrofa> jdstrand, darn, so those are the weird log-missing denials I reported before, huh? So something else is happening on lxc with hooks
[20:04] <kyrofa> Something weird happens when snaps update on lxc. Not sure what, though
[20:08] <jdstrand> kyrofa: like I said, the stdout logging denial is fixed (that is what you reported before). but mysql.server in snap.nextcloud.mysql is clearly calling systemctl
[20:08] <jdstrand> and that's a no no
[20:08] <kyrofa> jdstrand, yeah I'm probably trying to stop it incorrectly, but it still seems to work fine, so also non-fatal
[20:09] <jdstrand> you might mention that in the forum, since I said it could be fatal
[20:09] <jdstrand> it depends on the snap, etc
[20:11] <jdstrand> kyrofa: ok, I responded again just now
[20:43] <Facu> sergiusens_, et al, do you know how to run snapcraft for it to show verbosely what is hitting in the server, and what the server is answering?
[20:53] <kyrofa> Facu, wireshark
[20:53] <kyrofa> (in seriousness, no, debug output doesn't include network exchanges)
[20:53] <Facu> kyrofa, the ultimate tool, but was searching for something simpler
[20:53] <Facu> kyrofa, thanks!
[20:54] <kyrofa> Facu, although if you up the urllib logging you might get some
[20:54] <kyrofa> Or... requests
[20:56] <kyrofa> Facu, yeah, look at snapcraft/internal/log.py
[20:56] <kyrofa> Facu, the requests lib was ratcheted down to INFO because it's so noisy
[20:56] <kyrofa> Modify that and you should see all sorts of stuff
[20:58] <Facu> kyrofa, thanks!
[21:21] <zyga> jdstrand: reading
[21:21] <zyga> jdstrand: interesting concept, thank you!
[21:28] <mup> PR snapd#3305 closed: release: snapd 2.26 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3305>
[21:52] <mup> PR snapd#3298 closed: interfaces/builtin: ensure we don't register interfaces twice <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3298>
[21:55] <Pharaoh_Atem> wtf
[21:55] <Pharaoh_Atem> we're now on 2.26.1?!
[21:57] <zyga> Pharaoh_Atem: yep
[21:57] <Pharaoh_Atem> welp
[21:58] <zyga> Pharaoh_Atem: we found a but that may end up in panic so mvo did another release
[21:58] <Pharaoh_Atem> due to that datacenter outage, 2.25 never got pushed fast enough to be released
[21:58] <Pharaoh_Atem> so I guess I'll just yank it for 2.26.1 once morphis gives me that list of things
[22:01] <zyga> Pharaoh_Atem: I don't know if the outage affected 2.25
[22:01] <zyga> Pharaoh_Atem: I think we'll see 2.25.1 too
[22:01] <zyga> Pharaoh_Atem: as one of the issues we found was there since 2.23
[22:01] <Pharaoh_Atem> oh dear
[22:01] <Pharaoh_Atem> that's not good
[22:02] <zyga> Pharaoh_Atem: (but tomorrow :)
[22:02] <zyga> soon :)
[22:02]  * zyga pushed update to https://github.com/snapcore/snapd/pull/3295/files
[22:02] <mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[22:02] <zyga> that's my scaries PR ever :)
[22:02]  * Pharaoh_Atem shrugs
[22:02] <Pharaoh_Atem> it's not that bad
[22:02] <Pharaoh_Atem> you're just rewriting all the calls to every interface ever
[22:02] <zyga> hahaha
[22:03] <zyga> and tests :)
[22:03] <Pharaoh_Atem> that's implied :)
[22:03] <zyga> but the outcome is very positive
[22:03] <Pharaoh_Atem> is it?
[22:03] <Pharaoh_Atem> what does it mean?
[22:03] <zyga> I found some nastiness by doing that
[22:03] <zyga> I didn't finsh them today but I have some more cleanup piled up
[22:03] <zyga> so that tests are better and more uniform
[22:03] <zyga> I found, mostly, copy-pasted mistakes
[22:28] <mup> PR snapcraft#1299 closed: asset-tracking: save the dependencies of build packages <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1299>
[23:09] <mup> PR snapd#3212 closed: api, ifacestate: resolve disconnect early <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3212>
[23:31] <mup> PR snapcraft#1311 opened: add missing VCS dependencies to HACKING.md <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/1311>
[23:46] <mup> PR snapcraft#1303 closed: kernel plugin: slightly improve the messaging of check_config() <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1303>