[01:41] <sergiusens> jdstrand, kyrofa, popey Wimpress https://github.com/snapcore/snapcraft/pull/2234
[05:03] <mborzecki> morning
[05:55] <zyga> Good morning
[05:55] <zyga> Summer feels over now
[06:19] <zyga> good morning
[06:20] <zyga> again
[06:20] <zyga> this time from a computer
[06:20] <zyga> man, Monday will be brutal :)
[06:22] <mvo> zyga: good morning
[06:22] <mvo> zyga: monday is back to school?
[06:23] <zyga> yes
[06:27] <zyga> mvo: reviewed systemd env generator PR
[06:27] <mvo> zyga: nice
[06:32] <mborzecki> mvo: zyga: hey
[06:33] <mborzecki> yeah, i'll likely be starting late on monday (or have a break sometime around morning) with the school and all
[06:36] <zyga> mborzecki: same here
[06:36] <zyga> two kids to sort out :)
[06:36] <mvo> mborzecki: good morning
[06:36] <mvo> mborzecki: no worries
[06:44] <mborzecki> and back to the 'breakfast, work, kids from school, help with home homework, <do one other thing you may have planned>, dinner, sleep, goto 1' routine
[06:44] <mvo> zyga: curious, why a man-page for the generator? this thing is pretty well hidden
[06:47] <zyga> All generators have them
[06:47] <mvo> zyga: aha, ok
[06:48] <zyga> It is good courtesy to users since this is an opaque compiled program
[06:49] <mborzecki> systemd-environment-d-generator has it too, although it's not very useful
[06:53] <zyga> I’m moving outdoors
[06:53] <zyga> Network at home sucks
[06:53] <zyga> And I need to do a trial school run to see how bus traffic looks like
[07:10] <pstolowski> morning
[07:24] <mborzecki> pstolowski: heyah
[07:31] <zyga> re
[07:40] <mvo> mborzecki: the arch failures on 2.35 look real
[07:41] <mborzecki> mvo: that's unfortunate, do you have link to the logs?
[07:41] <mvo> mborzecki: I mean, they are the same as yesterfday, any idea ? and if this does not affect master we probably just need to find the right commit that fixed it in master
[07:41] <mvo> mborzecki: https://api.travis-ci.org/v3/job/422560948/log.txt
[07:43] <mborzecki> mvo: ssh keygen?
[07:43] <mvo> mborzecki: ohhh
[07:43] <mvo> mborzecki: yeah, let me find htis one and cherry-pick it
[07:43] <mvo> mborzecki: thats definitely a good candidate
[07:46] <mvo> mborzecki: cherry-picked and pushed, lets see if that helps
[07:46] <mvo> mborzecki: thank you!
[07:48] <mborzecki> mvo: hopefully it'll be green now :)
[07:49] <zyga> breaking compat one by one :)
[08:02] <Chipaca> moin moin
[08:03] <Chipaca> any idea why #5744 still shows up in github as 'in progress' (and no coverage report) when the tests passed?
[08:03]  * zyga works on trespassing unit tests
[08:04] <zyga> working from suse :)
[08:04] <zyga> I think we have enough people with ubuntu
[08:04] <zyga> (in the team, go ubuntu :)
[08:06] <mborzecki> haha
[08:10] <popey> hmm
[08:11] <popey> when snapd dies, "snap info" lies
[08:11] <popey> it says "no snap found" when it should really say that it couldn't contact the store
[08:11] <popey> https://www.irccloud.com/pastebin/MErmQt88/
[08:11] <Chipaca> popey: it didn't say there weren't any, it said it didn't find any
[08:11] <Chipaca> popey: like when I tell my boys to go get something
[08:11] <popey> "Man looking"
[08:12] <Chipaca> popey: "I LOOKED NOWHERE AND I CAN'T FIND IT"
[08:12] <popey> :D
[08:12] <popey> Should it not also warn that it can't get to snapd?
[08:13] <popey> the "I looked nowhere" bit
[08:13] <Chipaca> maybe snap should learn to pick things up and look under things, especially if it just put that thing down
[08:14] <popey> It should at least pick up the boxes and give them a bit of a shake.
[08:14] <Chipaca> that's like level 3
[08:14] <Chipaca> no chance
[08:15] <popey> snapd needs to lean the Jan Hankel Flank Pat system for finding things
[08:15] <Chipaca> I see what's going on, I'll push a pr to address it in a bit
[08:15] <popey> https://www.youtube.com/watch?v=DY-Zdgo0OXo
[08:15] <popey> Thank you!
[08:16] <Chipaca> popey: the first time I saw that vid I didn't notice how old it was
[08:16] <Chipaca> maybe it was a long time ago
[08:16] <Chipaca> hm
[08:18] <popey> Yeah, Mitchell & Webb Look aired 10 years ago!
[08:19] <mvo> mborzecki: aarch is greeeeeeeeeeen
[08:19] <mborzecki> yay, rejoice :P
[08:19] <mvo> mborzecki: merged into 2.35 thanks again
[08:19] <Chipaca> popey: if you did 'snap info foo bar' in that situation, what would you expect to see?
[08:24] <popey> We'll. Shut down snapd and run snap list. You get a completely different experience
[08:24] <popey> I would prefer snap list had a nicer error too
[08:24] <popey> When snapd is down
[08:25] <popey> (in this case snapd was down due to lack of disk space)
[08:30] <Chipaca> popey: the problem is 'snap info' does a lot more stuff than 'snap list'
[08:30] <Chipaca> popey: so each query to  'snap info' can produce up to 2 errors during normal operation
[08:31] <Chipaca> popey: and up to 3 errors when snapd is down
[08:32] <Chipaca> popey: note info _can_ produce useful output with no snapd
[08:32] <Chipaca> popey: e.g. 'snap info /var/lib/snapd/snaps/*'
[08:34] <popey> (I never knew that)
[08:34] <popey> (I bet nobody else does either)
[08:34] <Chipaca> popey: 'snap info /snap/core/current/' also tries to be informative
[08:35] <Chipaca> popey: or 'snap info ./prime'
[08:43] <Chipaca> I need to make the errors from client a little more structured before I can hope to make this work
[08:43] <Chipaca> but we've been wanting this for a while now
[08:43] <Chipaca> so, yay
[08:44] <popey> \o/
[08:44] <Chipaca> yeap. Just, not a quick fix
[08:44] <popey> no rush
[08:44] <popey> is it done yet?
[08:48] <Chipaca> popey: https://www.youtube.com/watch?v=RYVlJKSEsyM
[08:49] <popey> awwww <3 that video
[08:49] <popey> Those were happy times
[08:52] <Chipaca> popey: back when we were part of ESA you mean?
[08:52] <mborzecki> zyga: niemeyer: https://github.com/snapcore/snapd/pull/5747
[08:55] <zyga> +1
[08:57] <mvo> zyga: is there a way to make apparmor refuse to stat/etc/lsb-base-logging.sh  ?
[08:57] <mvo> zyga: context is https://bugs.launchpad.net/snapd/+bug/1779416
[09:03] <popey> main.go:192: cannot change mount namespace of snap "mattermost-desktop" according to change mount (/snap/gtk-common-themes/319/share/sounds/communitheme /snap/mattermost-desktop/78/usr/share/sounds/communitheme none bind,ro 0 0): cannot create writable mimic over "/snap/mattermost-desktop/78/usr/share/": permission denied
[09:03] <popey> ^ anyone seen that before? What does it mean?
[09:03] <Chipaca> zyga: ^
[09:03] <popey> I am launching mattermost-desktop from edge, and have the communitheme install
[09:07] <zyga> popey: hey
[09:07] <zyga> popey: known issue, please show me the snapcraft yaml, I will show you how to work around it
[09:07] <zyga> it's a trivial trick
[09:22] <popey> zyga: https://github.com/snapcrafters/mattermost-desktop/blob/master/snap/snapcraft.yaml
[09:23] <zyga> looking
[09:23] <zyga> right
[09:24] <zyga> if the snap ships $SNAP/usr/share/{icons,themes,sounds} as empty directories
[09:24] <zyga> this bug goes away
[09:24] <popey> hah!
[09:25] <diddledan> ooh, new mycroft
[09:25]  * diddledan gets compiling
[09:25] <zyga> popey: the issue is that the rules for poking holes are super precise
[09:25] <zyga> and they should be more generic in cases like this where there are many more directories to create
[09:26] <zyga> popey: I'm working on fixing that (2.36)
[09:26] <popey> ok, thanks.
[09:28] <diddledan> oh, looks like it's not rolled-out yet (mycroft 18.08)
[09:29] <Son_Goku> zyga, snapd 2.35 rolled out to fc28
[09:29] <Son_Goku> still waiting for karma for fc27
[09:29] <zyga> Son_Goku: Thank You!
[09:29] <zyga> Son_Goku: I can give it a spin today
[09:29] <zyga> I'm trying to get out of a very long unit test change
[09:29] <zyga> for a .1 release
[09:30] <zyga> Son_Goku: btw, I want to participate in the golang sig
[09:30] <zyga> I have my own proposal to contribute
[09:30] <zyga> I was working on it after hours recently
[09:30] <Son_Goku> cool
[09:30] <zyga> something that fits upstream and downstream at the same time
[09:30] <zyga> is easy to use for regular go developres
[09:30] <zyga> and does all that distros need
[09:30] <zyga> (magic, right?)
[09:30] <zyga> I will have it ready in a few days
[09:31] <zyga> I think there's a real chance to unify fedora and suse helpers
[09:31] <Son_Goku> heh
[09:33] <mborzecki> zyga: no more shell wrappers for each go command?
[09:33] <zyga> mborzecki: exactly
[09:34] <zyga> anyway, back to work, I'll demo it next week
[09:35] <mborzecki> heh going through opensuse wrappers was interesting, but to be fair OE also has some hacks spefifically for go packaging
[09:36] <Son_Goku> Fedora's wrappers are pretty thin
[09:36] <Son_Goku> the macro directly calls the go command
[09:43] <mborzecki> Son_Goku: well, suse has an elaborate shell script(s) :/
[09:43] <Son_Goku> it used to be ruby
[09:43] <Son_Goku> so be happy it's not that
[09:43] <mborzecki> hehehe
[09:43] <mborzecki> Son_Goku: but ruby is like haiku
[09:44] <mborzecki> Son_Goku: or better, the code reads like plain english
[09:44] <Son_Goku> suse's golang-packaging being rewritten from ruby to shell was the result of an ugly dispute with the original creator of suse's golang packaging standard
[09:46] <mborzecki> Son_Goku: otoh the languages bundling their dependencies do not really fit that well with the packaging model used by some distros, i can't imaging splitting dependencies of a trivial node app
[09:46] <Son_Goku> you don't have to imagine
[09:46] <Son_Goku> it happened for a while in Fedora
[09:46] <Son_Goku> and it still does in Debian
[09:47] <popey> yeah, the number of ITP mails which are "please package this node module" is too damn high
[09:58] <niemeyer> mborzecki: Thank you! And sorry for the late reply
[09:58] <niemeyer> And good morning :)
[10:03] <Chipaca> niemeyer: you got to say 'good morning' by two minutes :-)
[10:03] <Chipaca> niemeyer: good afternoon sir
[10:03] <niemeyer> Aftnoon!
[10:04] <Chipaca> :-)
[10:05] <mborzecki> niemeyer: sure, thanks for the review
[10:05] <Chipaca> zyga: pstolowski: if you have a window for an easy review, #5744 is kinda blocking me (I could merge it and then let git sort it out, and I'll do that if it's not reviewed soonish, but i'd rather avoid it)
[10:06] <zyga> looking
[10:06] <Chipaca> woo
[10:06] <Chipaca> thanks
[10:06] <Chipaca> zyga: tests are green despite github not knowing it
[10:06] <pstolowski> kk. and what happend to mup btw, is it gone again?
[10:06] <zyga> mvo: my dragon apparently has android on emmc
[10:06] <Chipaca> pstolowski: ^ zyga's on it, thanks
[10:06] <mborzecki> niemeyer: pushed the changes to https://github.com/snapcore/snapd/pull/5713 too (hopefully got all of it now)
[10:07] <Chipaca> also, how can I merge a PR if travis didn't let github know it was green?
[10:07] <Chipaca> :-(
[10:07] <zyga> Chipaca: ask mvo
[10:08] <zyga> Chipaca: is bytes.Bytes expensive?
[10:08] <zyga> er
[10:08] <zyga> buffer.Bytes
[10:08] <Chipaca> zyga: only a little bit more than doing the maf ourselves
[10:08] <Chipaca> zyga: memorywise it's about the same
[10:08] <Chipaca> (especially as it's already used elsewhere)
[10:09] <mvo> Chipaca: I can
[10:09] <zyga> why did you move w.partial = nil; to be a w.partial.Reset() a few lines below (after } )
[10:09] <mvo> Chipaca: which one do you need
[10:09] <zyga> 5713
[10:09] <zyga> er
[10:09] <zyga> not
[10:09] <zyga> 5744
[10:09] <Chipaca> mvo: 5744 (but it doesn't have zyga's second +1 yet)
[10:10] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5744/files#diff-7c96d8cb550f40c45f4ded10cc30f5eeL54 about this line
[10:10] <Chipaca> zyga: yep ye
[10:10] <zyga> it is clear that it is just a p.Reset but why did you move it?
[10:10] <zyga> is it because of https://github.com/snapcore/snapd/pull/5744/files#diff-7c96d8cb550f40c45f4ded10cc30f5eeL58
[10:10] <zyga> which is not 1-to-1 (write is append, = was reset + write)
[10:10] <Chipaca> zyga: because I'd be doing it in the other paths as well
[10:10] <zyga> ok
[10:10] <Chipaca> zyga: that is: w.partial = p -> w.partial.Reset(); w.partial.Write(p)
[10:11] <zyga> +1
[10:12] <Chipaca> mvo: ok now yes please
[10:12] <zyga> done
[10:12] <zyga> mvo: 3/4 flashed
[10:13] <Chipaca> mvo: https://github.com/snapcore/snapd/pull/5744 is green and has two +1's
[10:13]  * Chipaca ~> break
[10:14] <mvo> Chipaca: done thank you
[10:14] <Chipaca> mvo: whee, thanks
[10:14] <Chipaca> wait i was supposed to be on a break
[10:14]  * Chipaca hides
[10:14] <popey> hm, is there any way to see which snap pulled in a core18 ?
[10:15] <Chipaca> we should include that in the error (there's a // TODO)
[10:15] <Chipaca> (in the "snap remove core18" error i mean)
[10:15] <pedronis> popey: snap info --verbose should show the base of a snap
[10:15] <zyga> yep, it does
[10:16] <Chipaca> maybe snap list should include it as well
[10:16] <mvo> or snap info core18 could list the rdepends
[10:16] <Chipaca> mvo: oooh
[10:16] <Chipaca> mvo: I'll add that
[10:16] <popey> that would be nice
[10:17] <Chipaca> could also look at slots/plugs
[10:18] <popey> diddledan: you moved to core18 on gimp? :)
[10:18] <diddledan> yes. I've got the snap building on launchpad for now
[10:18] <mborzecki> zyga: where was the mapping thing that changed system -> core and back?
[10:19] <diddledan> just this second told it to do a new build for libx11-related security patches overnight
[10:19] <zyga> mborzecki: in overlord/ifacestate
[10:19] <zyga> man, SD cards are slow
[10:20] <mborzecki> zyga: i'm thinking if we could have something similar instead of snap.Info.ExpandSnapVariables(), like a mapped that does this in 'inside' snap mount ns or 'outside' (cc niemeyer)
[10:20] <mborzecki> s/mapped/mapper/
[10:20] <zyga> hmmm
[10:20]  * zyga thinks
[10:21] <mborzecki> zyga: then for eg. snap.MountNSView().ExpandVariables(info)
[10:22] <niemeyer> mborzecki: The problem tastes a bit simple for that
[10:22] <niemeyer> mborzecki: What changes between the two cases, and how often we need either?
[10:23] <popey> diddledan: that'll be why core18 number of installs rocketed up over the last few days then :)
[10:23] <mborzecki> niemeyer: yeah, the only use cases now are 'inside' mount ns, so we could go yagni about that just have one function for this (as it is right now)
[10:23] <niemeyer> mborzecki: !
[10:23] <diddledan> rocketed?
[10:23] <diddledan> one snap. yeesh :-p
[10:24] <popey> one - popular - snap :)
[10:24] <diddledan> aha
[10:24] <diddledan> I see what you mean
[10:24] <diddledan> pics or it didn't happen!
[10:24]  * niemeyer wants pictures too
[10:25] <popey> https://snapcraft.io/core18
[10:25] <popey> look at the distro graph
[10:26] <diddledan> I don't see a timeline :-(
[10:27] <MattJ> On a tangent, but the map just reminded me of https://xkcd.com/1138/
[10:28] <zyga> mvo: it's booting
[10:28] <popey> MattJ: hah! :D
[10:28] <pstolowski> niemeyer: hey! will you find a moment today for a quick HO re udev & stop channel?
[10:28] <zyga> mvo: same as last time
[10:28] <zyga> mvo: let me look at logs
[10:29] <niemeyer> pstolowski: Yeah, definitely
[10:29] <zyga> mvo: same == "snap command not found"
[10:29] <zyga> I'll enable journal and see what we get
[10:32] <mvo> xnox: did you get my message about https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 ?
[10:32] <mvo> xnox: i.e. can/should I sru this or will you do a sru with more changes anyway where this could be included?
[10:32] <zyga> mvo: I reflashed and created /var/log/journal
[10:32] <mvo> zyga: meh, that sucks
[10:32] <mvo> zyga: thanks
[10:32] <zyga> it failed
[10:32] <zyga> let me recover the journal after a second, I want to make sure this is written to the card
[10:32] <mvo> zyga: ta
[10:33] <mvo> zyga: the error you got a couple of days ago should be fixed so I wonder what is going on
[10:33] <zyga> mvo: I'll bring it for the sprint
[10:34] <zyga> sie 31 12:32:18 localhost run-snapd-from-snap[738]: stateengine.go:102: state ensure error: devicemgr: cannot use gadget snap because its base "" is different from model base "core18"
[10:34] <zyga> mvo: :D
[10:34] <zyga> let me know if you want another test run
[10:35] <zyga> mvo: I streamlined my setup so I can test it very quickly
[10:35] <zyga> there are more errors, I'll give you the full og
[10:35] <zyga> *log
[10:37] <zyga> mvo: boot log https://paste.ubuntu.com/p/pkhHBrzFNm/
[10:37] <zyga> back to coding
[10:37] <zyga> ping me for another run
[10:38] <mvo> zyga: thanks, fixing
[10:59] <Chipaca> ouch, a panic from prepare-image
[10:59]  * zyga is hungry
[10:59] <mborzecki> Chipaca: bt?
[11:00] <mvo> Chipaca: yeah, I saw this a couple of time in the lsat day
[11:01] <mvo> Chipaca: I pushed a fix for the panic
[11:01] <mvo> Chipaca: its an open pr, that hopefully gives us clues what is going on
[11:01] <mvo> Chipaca: 5743 if you look for a simple review ,)
[11:01] <Chipaca> mborzecki: https://pastebin.ubuntu.com/p/2ZTtNDngWp/
[11:02] <Chipaca> mvo: nice
[11:02] <mvo> Chipaca: the question is really why we get into this situation, its impossible :) (well, clearly not but)
[11:04] <Chipaca> mvo: because it's only added to the map 		if typ == snap.TypeKernel || local.Name(snapName) == baseName {
[11:05] <Chipaca> mvo: and then it looks in that map for 'snapweb'
[11:05] <mvo> Chipaca: is it snapweb its crashing for?
[11:05] <mvo> Chipaca: I thought that was invisilble without the other PR
[11:05] <mvo> (but maybe I hvae not looked hard enough)
[11:05] <Chipaca> mvo: it prints "fetching %s" before looking at the map?
[11:06] <Chipaca> bah, i don't realluy know this code
[11:06] <Chipaca> so i could have it backwards
[11:07] <Chipaca> hmm hmm
[11:07] <Chipaca> mvo: so, with your change, the test will still fail at this point, right?
[11:08] <mvo> Chipaca: yes
[11:08] <mvo> Chipaca: it will fail but report on what snap it failed
[11:09] <mvo> Chipaca: I can add some more code to diagnose this I think
[11:10] <mvo> Chipaca: heh, you suggested this too :) let me add it
[11:10] <Chipaca> mvo: +1'ed, but yeah
[11:11] <mvo> Chipaca: ta
[11:23] <zyga> re
[11:34]  * Chipaca ~> lunch
[11:42] <mborzecki> niemeyer: https://github.com/snapcore/snapd/pull/5749
[12:02] <jdstrand> zyga: hey, I'm not really here. I didn't get to the /mnt PR yesterday but will try today
[12:03] <zyga> jdstrand: hey
[12:03] <zyga> jdstrand: mvo and I decided to merge it (ahead of an important release) but if you find anything we will do a point release
[12:03] <zyga> sorry about that, I hope that's okay
[12:03] <zyga> jdstrand: so take your holidays for real and let's do this next week
[12:11] <xnox> mvo, there is an sru outstanding to do, yes.
[12:11] <xnox> mvo, however, it appears that snapd is failing autopkgtests now that said patch is in, in cosmic-proposed.
[12:12] <xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/s/snapd/20180830_184959_a6800@/log.gz
[12:12] <xnox> 2018-08-30 18:49:42 Failed tasks: 1
[12:12] <xnox>     - autopkgtest:ubuntu-18.10-amd64:tests/main/dirs-not-shared-with-host:alternatives
[12:12] <xnox> mvo, as if i should back that change out.... if it is related.
[12:16] <zyga> mborzecki: less than 20 errors left, brace yourself for that long code review :D
[12:21] <mvo> jdstrand: who else can approve snaps? I have some gadgets with "base: core18" that neeed approval
[12:21] <mvo> xnox: its not related I will push a fix for this
[12:22] <mvo> xnox: its a core snap change
[12:22] <xnox> mvo, oh, ok!
[12:22] <xnox> mvo, that's good =) cause it means i need not to back out things in systemd package then!
[12:22] <mvo> xnox: yeah, I'm very happy if the fix is included too :)
[12:26] <diddledan> wheee
[12:27] <diddledan> all those failed-to-release: https://www.youtube.com/watch?v=0BHQT3Omqtw
[12:27] <diddledan> err
[12:27] <diddledan> wrong link
[12:27] <diddledan> file:///home/dllewellyn/Pictures/Screenshot_20180831_132719.png
[12:27] <diddledan> bah
[12:27] <diddledan> THIS TIME! https://usercontent.irccloud-cdn.com/file/hKp3lTzL/Screenshot_20180831_132719.png
[12:29] <mvo> diddledan: i had some store upload rejections as well, mine were some new fields from snapcraft iirc
[12:30] <zyga> mborzecki: it's green :)
[12:30] <zyga> mborzecki: I'll chop it
[12:30] <diddledan> https://www.youtube.com/watch?v=TkZFuKHXa7w
[12:34] <diddledan> ^^ without comment
[12:39] <cachio> mvo, hey
[12:39] <cachio> https://paste.ubuntu.com/p/Gr835VXzcF/
[12:39] <cachio> did yo see that error on master?
[12:41] <mvo> cachio: yes
[12:41] <mvo> I pushed a PR to make it more obvious what is going on
[12:41] <cachio> mvo, great, thanks
[12:42] <mvo> cachio: 5743 - its ready
[12:42] <mvo> cachio: that hopefully gives us a clue
[12:42] <mvo> cachio: what is going on there
[12:42] <mvo> cachio: I saw it a couple of times today and yesterday
[12:43] <mvo> diddledan: let me try to find out what is going on with the rejections - do you also get it for nknown keys in snap/manifest.yaml: snapcraft-os-release-id
[12:45] <diddledan> no idea why it's failed to release
[12:45] <diddledan> everything appears normal
[12:46] <diddledan> for example, micropolis failed to release, but: https://usercontent.irccloud-cdn.com/file/eZSJeaNF/Screenshot_20180831_134635.png
[12:47] <cachio> mvo, yes it started yesterday suddenly, some branches without any change started failing
[12:48] <diddledan> gimp just got rejected with "unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest"
[12:54] <zyga> brb, see you at the call
[12:58] <mvo> diddledan: yeah, I had the same
[13:00] <diddledan> apparently I singlehandedly skyrocketed the number of core18 installations (according to popey )
[13:00] <diddledan> I call shenanigans
[13:01] <diddledan> as if my gimp is really _That_ popular!?!
[13:01] <popey> "skyrocketed" :D
[13:02] <diddledan> oh, right, so in the last 3 days 77 thousand people have updated to core18ified gimp...
[13:03] <diddledan> htf have I managed to become influential to 100k people?!
[13:04] <popey> Turns out people like gimp. who knew? :)
[13:04] <diddledan> nuts
[13:15] <diddledan> left with no comment: https://usercontent.irccloud-cdn.com/file/gOjXXEh5/Screenshot_20180831_141513.png
[13:16] <diddledan> actually, question regarding that, is nil gonna be treated as string 'nil' or as no-value?
[13:17] <diddledan> I wanted it to be no-value
[13:17] <diddledan> i.e. don't you dare think of giving me a base damn you!
[13:19]  * diddledan hacks all the things
[13:22] <Son_Goku> mvo, zyga: https://github.com/snapcore/snapd/pull/5750
[13:22] <Son_Goku> mvo, also, your script for generating changelogs is broken
[13:23] <Son_Goku> I had to add the "- New upstream release <version>" line for the last few changelog entries
[13:23] <zyga> Son_Goku: shall we sort the changelogs like I did in suse?
[13:23] <zyga> I need to update my script
[13:23] <Son_Goku> sort them?
[13:23] <zyga> the dates are broken
[13:24] <zyga> at least in suse they were, due to various historic mistakes
[13:24] <Son_Goku> yeah
[13:24] <Son_Goku> the dates and authors need to be fixed
[13:24] <zyga> https://gitlab.com/zygoon/rpmtools
[13:24] <Son_Goku> I thought about fixing it the last time I went in and whacked the changelogs
[13:24] <Son_Goku> err fixed the suse packaging
[13:24] <zyga> just need to handle embedded changelogs
[13:24] <Son_Goku> changes format changed last week
[13:25] <Son_Goku> zyga: spot the difference: https://build.opensuse.org/package/view_file/system:packagemanager:dnf/dnf/dnf.changes?expand=1
[13:25] <mvo> Son_Goku: thanks, in a meeting right now, but thanks for the PR - and sorry for the broken script I have a look and fix it
[13:26] <zyga> Son_Goku: in a meeting, but I will look after
[13:26] <Son_Goku> mvo, zyga, clearly you're both in the same meeting :P
[13:26] <zyga> yep
[13:26] <zyga> standup
[13:29] <Son_Goku> zyga, also: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html-single/7.6_release_notes/#BZ1461652 & https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html-single/7.6_release_notes/#BZ1564775
[13:39] <niemeyer> cachio: uploaded
[13:39] <cachio> niemeyer, tx
[13:40] <zyga> Son_Goku: how do the two rhel notices you linked to affect us?
[13:41] <Son_Goku> zyga, well, the first one means that the code I'm writing for integration in fedora infra will work for producing centos7 base snaps eventually
[13:41] <Son_Goku> as for the second one, I'm not sure, it sounds like something we might want?
[13:42] <Son_Goku> at least with the mmap() support, that means that the policy will compile again on el7
[13:42] <Son_Goku> zyga, it seemed like the socket stuff is something along the lines of what the socket mediation stuff in apparmor does
[13:43] <zyga> Son_Goku: apparmor does packet inspection (so to speak)
[13:43] <zyga> more like a firewall than a traditional "you can or cannot use that socket" control
[13:43] <Son_Goku> ah
[13:43] <zyga> but I understand what you meant now
[13:49] <mvo> diddledan: I got feedback about the store rejections, they are working on it and it should be back to normal soon. out of curiosity, is your gimp snap core18 based?
[13:50] <diddledan> yes, it is
[13:50] <mvo> diddledan: thanks for confirming. it looks like only the 18.04 build env is currently in unhappy land
[13:50] <diddledan> hence 77k new core18 downloads this week :-p
[13:50]  * mvo hugs diddledan 
[13:51] <mvo> diddledan: thats cool
[13:51] <diddledan> ooh cuddles!
[13:52] <diddledan> I wanna see the graph of core18 to see what impact that's had overall
[13:53] <mvo> diddledan: its quite dramatic
[13:53] <diddledan> I unleashed gimp core18 about 3 days ago IIRC
[13:54] <mvo> diddledan: yeah and the graph is exploding since :)
[13:54] <zyga> indeed :)
[13:54] <mvo> diddledan: nice job
[13:54] <diddledan> nice
[13:54] <mvo> Chipaca: 5730 might be interessting for you
[13:54] <zyga> mvo: beta testers ;)
[13:54] <mvo> Chipaca: super easy
[13:54] <diddledan> haha. I hope you were ready ;-p
[13:54] <mvo> zyga: yeah but to be fair, core18 as a base for normal snaps should be fine
[13:55] <diddledan> seems stable for gimp's usage
[13:55] <mvo> diddledan: he is joking, as a base its good
[13:55] <zyga> yes, I was somewhat kidding
[13:55] <mvo> diddledan: as a booting image we have some work (but even there its pretty good by now :)
[13:55] <diddledan> "should"
[13:55] <diddledan> yey
[13:55]  * diddledan waits for his pi to automatically upgrade
[13:56] <diddledan> I'm guessing moving over to the core18 boot image is gonna be a case of many spinning plates
[13:56] <zyga> flashing bits
[13:56] <zyga> yes
[13:56]  * diddledan flashes his bits
[13:56] <zyga> brb, I need some water, it's getting warm on this side of the house
[13:56] <mvo> 5743 is trivial and needs a second review
[13:56] <diddledan> yeah, the sun's just got around to my main window now, too
[13:57] <Chipaca> mvo: in a mo
[13:57] <zyga> mvo: shall I squash it
[13:57] <zyga> or just merge it
[13:57] <popey> jdstrand: did the snapcraft build get reverted back in launchpad builders?
[13:57] <popey> jdstrand: we are seeing developers complaining that their snaps are not updating
[13:57] <mvo> zyga: which one?
[13:58] <mvo> zyga: just merge unless it has the label
[13:58] <zyga> 5743
[14:02] <cjwatson> popey: for xenial builds, yes
[14:02] <cachio> niemeyer, still failing spread
[14:02] <popey> cjwatson: ok, thanks
[14:02] <cjwatson> popey: unless I'm confused about what you mean by "reverted back".  xenial builds are currently running with (effectively) 2.42.1
[14:03] <popey> well, a working version of snapcraft, which doesn't have the extra metadata which the store rejects
[14:03] <popey> so <2.43
[14:03] <cjwatson> indeed
[14:06] <cachio> niemeyer, I found the problem
[14:06] <cachio> it works now
[14:08] <niemeyer> Ah, nice
[14:15] <zyga> mvo: will you have another dragon image to test today?
[14:15] <zyga> or can I put it back into the drawer
[14:26] <mvo> zyga: I will ask the store guys if they can approve my dragon gadget
[14:29] <Chipaca> mvo: 5730 is about talking to a store proxy through an http proxy?
[14:30] <mvo> Chipaca: correct
[14:30] <Chipaca> mvo: why tho
[14:30] <Chipaca> :-)
[14:30] <mvo> Chipaca: also about locking
[14:31] <mvo> Chipaca: oh, if thats not a support configuration I can close the PR
[14:31] <Chipaca> mvo: I don't know. Maybe sparkiegeek does (but he's away i think)
[14:31] <Chipaca> mvo: I'll ask
[14:31] <Chipaca> mvo: seems sane though
[14:32] <Chipaca> I mean, why would you do it, but if you need to do it, this is what we need to do to let you do it
[14:32] <pedronis> Chipaca: should also be normal store, no?
[14:32] <Chipaca> pedronis: 5730 is only about the proxy store
[14:32] <Chipaca> pedronis: it changes 'newEnoughProxy'
[14:33] <Chipaca> oh! also getSerial
[14:33] <Chipaca> darn
[14:33] <Chipaca> heh
[14:33] <Chipaca> my bad
[14:33] <Chipaca> pedronis: thanks
[14:33] <pedronis> ah, I thought I was confused
[14:33] <pedronis> it seems consistent at least
[14:33] <pedronis> and the bit in getSerial might be useful
[14:33] <Chipaca> yup
[14:34] <mvo> thanks guys!
[14:37] <zyga> mvo: did you ask about /etc/lsb something and apparmor?
[14:38] <mvo> zyga: I did but i figure out I can't deny stat with apparmor
[14:38] <mvo> zyga: which is a) surprising b) annoying
[14:39] <zyga> Yes
[14:40] <zyga> Yes
[14:40] <zyga> :-)
[14:40] <Chipaca> mvo: is the prepare-image pr merged?
[14:41] <mvo> Chipaca: someone merge it I think
[14:41] <Chipaca> mvo: nice
[14:41] <Chipaca> mvo: and you merged it into 5730?
[14:42] <mvo> Chipaca: yes, I think I did
[14:43] <sergiusens> jdstrand: did you get a chance to look at https://github.com/snapcore/snapcraft/pull/2234/files ? roadmr too maybe
[14:44] <joc> mvo: Chipaca: could you clear up something for me - i'm wondering what is the mechanism that distinguishes a series 16 Ubuntu Core image from a series 18 Ubuntu Core image - i.e. both could have the core snap from the other installed, but there is something that indicates where to run init + snapd from?
[14:44] <joc> (also trying to get my terminology correct)
[14:45] <sergiusens> joc: isn't that described in the model/gadget?
[14:45] <roadmr> sergiusens: oh so we weren't pushing snaps with a manifest before?
[14:45] <roadmr> this looks good
[14:46] <sergiusens> roadmr: we always were, just that the review tools are a bit overzealous about new attributes.
[14:46] <roadmr> yes, that they are.
[14:46] <mvo> joc: not sure I get the question, but could you check /etc/os-release?
[14:46] <roadmr> sergiusens: remember jdstrand is off today and Monday
[14:47] <joc> sergiusens: possibly, but i was looking around the gadget of an image i'm testing and could see an obvious key that says the is a core18 system
[14:47] <sergiusens> roadmr: which I think we agreed would be removed. I am not sure all the corner cases for all possible entries for the manifest are covered. I do agree that the review-tools should be strict on what they already know about to be able to generate proper USNs and other tooling
[14:47] <Chipaca> mvo: I think he's asking, on a core device with core16 and core18 installed, how do we know which one to boot
[14:47] <joc> yeah that basically :)
[14:47] <Chipaca> joc: it depends on how good the random number generator of the board is
[14:47]  * Chipaca runs for the hills
[14:48] <joc> lol
[14:48] <Chipaca> joc: the model says which one is the blessed one
[14:49] <Chipaca> joc: https://forum.snapcraft.io/t/model-assertions-for-core18/6870
[14:50] <sergiusens> roadmr: the irony in this case is that the review tools are rejecting the keywords Jamie asked me to add :-)
[14:50] <mvo> pedronis: thanks again for the review for 5583, I think you are right and we need to periodically check if snapd can go into socket activated mode, maybe every 5min?
[14:51] <sergiusens> well, were, as the review tools are up to date already
[14:51] <mvo> Chipaca, joc yeah, the model it is
[14:52] <mvo> zyga: new test dragonboard image is uploading, I let you know once its there
[14:52] <joc> and that then informs the variables used at boot time to identify which snap to mount?
[14:54] <Chipaca> joc: yep
[14:54] <roadmr> sergiusens: it's because they're old tools that don't know those keywords :) haha we've seen this, we can't start sending snaps with new fields until the tools support them :/ makes for some interesting interlock
[14:55] <joc> Chipaca: ok, thanks, that clears thing a bit for me
[14:58] <zyga> mvo: cool
[14:58] <sergiusens> roadmr: the tools already do support them ;-)
[14:59] <zyga> mvo: did you really compress it this time? :D
[14:59] <roadmr> sergiusens: aha, but not the version that's in the store :/ that was added recently AIUI (r1122/1123 while the store has 1121)
[15:00] <roadmr> sergiusens: we've discussed using the review-tools snap so it might be easier to update the tools
[15:00] <roadmr> sergiusens: haha yes, we haven't embraced the snap :) we had one huge hurdle which was the store being on trusty, that's not true anymore so the road is now open but fraught with peril
[15:01] <mvo> zyga: new version is up
[15:01] <mvo> zyga: I did not bother this time
[15:01] <sergiusens> roadmr: I do not know what rXXXX are, all I see is revision 553 (version 0.48+git) :-)
[15:02] <zyga> mvo: it's a big difference on both upload and download
[15:02] <zyga> ETA 52min
[15:02] <zyga> (on my capped link)
[15:04] <Chipaca> you know that feeling when you're writing long, hard to read integration-type tests and suddenly realise you could instead just write a unit test and let the rest sort itself out? yeah, that
[15:04] <zyga> switched to my laptop LTE, it's going to be fast now
[15:04] <Chipaca> i blame friday
[15:04] <zyga> 3 minutes
[15:04] <Chipaca> zyga: is this the same lte that you ate 1TB off of?
[15:04] <pedronis> mvo: as I said I'm not sure it's a serious problem
[15:04] <zyga> Chipaca: no, I have ... many
[15:04] <zyga> Chipaca: the 1TB empty one is slow now
[15:04] <pedronis> mvo: but wanted to point it out
[15:04] <zyga> Chipaca: my laptop has 100GB of private plan
[15:05] <zyga> Chipaca: and my phone has 65GB
[15:05] <zyga> Chipaca: I also have a pre-paid plan on a backup router with 60GB (pre-paid so I won't use it this way)
[15:05] <zyga> Chipaca: the polish phone has ... some amount but it's running ubuntu so I never use it
[15:05] <roadmr> I have 1 GB allowance :~(
[15:06] <zyga> roadmr: yes comrade ;-)
[15:06] <zyga> roadmr: I know, US&Canada suck wrt network
[15:06] <Chipaca> zyga: is your whole house glowing at night
[15:06] <roadmr> totally
[15:06] <zyga> roadmr: it's crazy how much network you get here
[15:06] <roadmr> there's slightly more competition in the US but Canada is horrible
[15:06] <roadmr> and I live in one on the best provinces for that, others are worse
[15:06] <zyga> Chipaca: plus each phone (e.g. kid phones) have 10GB at least (probably more, never ran out)
[15:07] <zyga> roadmr: I wonder if you could get a better deal by roaming from EU sim
[15:07] <zyga> roadmr: up until recently I had free roaming in US (I didn't check if that's still valid)
[15:08] <zyga> so my 65GB data, yep, same as back home
[15:09] <zyga> roadmr: my rural network link I used while on holidays has 100GB of data for 12 euro / month
[15:09] <zyga> roadmr: and it came with this big ass outdoor modem / antenna + indoor repeater wifi
[15:10] <roadmr> that's ridiculously cheap hehe
[15:10] <zyga> roadmr: it also allows you to make wifi-based phone calls so you don't need coverage in your handset
[15:10] <roadmr> oh I have that as well, never used it though
[15:10] <zyga> roadmr: works great in the forest
[15:10] <zyga> I'm very happy with the network here, it's never been this available and cheap
[15:11] <roadmr> cool :) somewhat envious :)
[15:11] <zyga> the rural aspect is interesting, is it a side product of covering everything else?
[15:11] <zyga> (get the last 10% customers?)
[15:13] <roadmr> sure, and also of the territory being smaller
[15:13] <roadmr> parts of rural and northern Canada has no coverage, because it' sjust huge
[15:39] <joc> mvo: i refreshed snapd to edge as the extrausers PR had landed then rebooted - it appears to have fixed those issues i was having - thank you!
[15:39] <mvo> joc: cool, thanks for confirming
[15:42] <mvo> sil2100: we may need your console-conf expertise soon again :) zyga has a test image for the dragonboard and it looks like console-conf is segfaulting there, might be related to not having network yet. we are investigating, just a heads up
[15:42] <sil2100> mvo: hm hm! Symptoms sound familiar to what I was seeing on my pi3
[15:43] <mvo> sil2100: it looks like its segfaulting
[16:00] <zyga> it is definitely signal 11
[16:00] <zyga> it goes all the way up to 11 in a bad way
[16:01] <zyga> sil2100: let me know if you want any debugging done
[16:09] <Chipaca> zyga: where was the thing that compared directories?
[16:09] <zyga> syncdir?
[16:09] <zyga> syncdir.go
[16:09] <zyga> osutils
[16:09] <Chipaca> zyga: thanks
[16:10]  * zyga hugs Chipaca 
[16:10] <zyga> :)
[16:10] <Chipaca> hmmmm
[16:10] <Chipaca> zyga: didn't we have a thing where we gave it to dirs and it told us what was different?
[16:10] <zyga> mmmmmmmmm
[16:11] <Chipaca> zyga: looks like no
[16:11] <zyga> no, I don't think we had _that_
[16:11] <Chipaca> zyga: because I see pack_test just doing diff
[16:11] <Chipaca> which is fine, i'll do that as well
[16:11] <zyga> we have this thing that compares mount profiles
[16:11] <zyga> but that's not that
[16:12] <Chipaca> zyga: diff is _fine_ :-)
[16:26] <zyga> woot
[16:26] <zyga> I found the bug :)
[16:26] <zyga> man :P
[16:26] <zyga> refactoring
[16:26] <zyga> old old old refactoring
[16:26] <zyga> I used an interface
[16:26] <zyga> and review asked to change that
[16:26] <zyga> so the only place that cared didn't get updated
[16:26] <zyga> fixed now!
[16:26] <zyga> woooot
[16:28] <Chipaca> pedronis: if overlord.Settle(t) takes more than t, what do i need to poke?
[16:33] <zyga> ah maciej is off already
[16:33] <zyga> well, fair enough :)
[16:33] <zyga> I'll prepare this for chopping
[16:37]  * Chipaca ~> afk (gym! but tests are running)
[16:39] <cmars> question about branches & auto upgrades. if i have a snap installed from a branch of edge, and that branch expires, what does auto-upgrade do?
[16:39] <cmars> would it install whatever's on edge automatically?
[16:39] <zyga> Chipaca: ^
[16:39] <zyga> ah
[16:40] <zyga> cmars: I think it's going to behave as if it was on edge
[16:41] <cmars> zyga: then i notice the branch expired and i push back to the branch.. would the clients that had this branch installed switch back? or would i have to snap refresh on all the machines/devices to get them back?
[16:42] <cmars> basically, i needed these devices to stay on the branch, but forgot to keep the branch alive and there was a window where it was gone
[16:42] <cmars> wondering what kind of mess this might have made..
[16:43] <Chipaca> cmars: the client is tracking the branch; when it re-opens, it'll get the new thing
[16:43] <Chipaca> cmars: you can check this: in "snap info", see what "tracking" says
[16:44] <cmars> Chipaca: ok. that's encouraging.. what if i had an older rev on the edge branch than edge, and when i restore the branch, it's still older than edge, but the branch is there again
[16:44] <cmars> Chipaca: will the client still switch back to the branch?
[16:44] <Chipaca> cmars: there is no "older"; there's jsut "is this the current tip"
[16:44] <cmars> or, would it have autoupgraded to edge in the first place?
[16:45] <zyga> woooooooooooooooooooooooooot
[16:45] <zyga>  :D
[16:45] <zyga> layouts no longer leak
[16:45] <Chipaca> cmars: if it refreshed while the branch was closed, it would have gone to whatever was current on edge
[16:45] <zyga> wooot wooot woot
[16:46] <Chipaca> cmars: also why do you have long-lived branches and not tracks
[16:46] <Chipaca> :-)
[16:46]  * zyga is super happy :D
[16:46]  * Chipaca hugs zyga 
[16:47] <Chipaca> zyga: EOW right now, on this feeling
[16:47] <cmars> Chipaca: i don't think tracks existed when we needed different builds. what's a track?
[16:47] <zyga> I need to chop the code a little but basically https://github.com/snapcore/snapd/compare/master...zyga:fix/trespassing-v2?expand=1 does the right thing
[16:47] <Chipaca> cmars: https://forum.snapcraft.io/t/using-tracks/6230
[16:48]  * Chipaca needs to run
[16:48] <zyga> I'll go for a bike ride with my kids
[16:48] <zyga> and then polish the diff
[16:48] <Chipaca> cmars: i'll be back in ~1.5h if you have more qs
[16:48] <cmars> Chipaca: ok, thanks
[16:50]  * zyga EODs
[17:21] <pedronis> Chipaca: usually something is not right
[17:22] <pedronis> Chipaca: it's more a matter of understanding what is not happening that should or we think should
[18:16] <pedronis> Chipaca: going over tasks and changes and look at their state, clean state after the timeout might be a good idea
[18:21] <Chipaca> pedronis: fair enough. I'll take a look at it Monday morning
[18:21] <Chipaca> now I think I'll just call it a wrap
[19:49] <diddledan> here's a good one for snapcraft devs to be thinking "wtf is he doing?!" about: `shutil.Error: [('/root/build_gnome-calculator-gentoo/parts/gnome-calculator/src/var/spool/nullmailer/trigger', '/root/build_gnome-calculator-gentoo/parts/gnome-calculator/build/var/spool/nullmailer/trigger', '`/root/build_gnome-calculator-gentoo/parts/gnome-calculator/src/var/spool/nullmailer/trigger` is a named pipe')]`
[19:51] <diddledan> note that it took several hours to get to that point