[02:00] <mup> PR snapd#6065 opened: cmd, strutil: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
[02:02]  * Chipaca zzs
[06:10] <mborzecki> morning
[06:41] <mup> PR snapd#6066 opened: tests: fixes and new backend for tests on nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6066>
[07:26] <zyga> Hello
[07:27] <mborzecki> zyga: hey
[07:28] <zyga> Fantastic day :-)
[07:31] <mup> PR snapd#6059 closed: snap: use Lstat to determine snap size, remove ReadSnapInfoExceptSize <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6059>
[07:33] <zyga> mborzecki: could you please review https://github.com/snapcore/snapd/pull/6063#pullrequestreview-169639370
[07:33] <mup> PR #6063: store: also make snaps downloaded via deltas 0600 <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6063>
[07:33] <zyga> it's trivial and needed for release
[07:35] <mborzecki> zyga: done
[07:35] <mup> PR snapd#6063 closed: store: also make snaps downloaded via deltas 0600 <Simple 😃> <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6063>
[07:36] <zyga> thanks!
[08:06] <zyga> good morning mvo
[08:07] <zyga> mvo: chipaca fixed the 0600 issue
[08:07] <zyga> I Ccd you on the PR that is now in master
[08:07] <zyga> how are you feeling this morning btw?
[08:07] <zyga> is it also very warm for you today? In the morning it was almost 15C, very unusual for this time of year
[08:07] <mborzecki> zyga: it was the same around 10pm yday ;)
[08:08] <mvo> zyga: \o/ good morning
[08:08] <mborzecki> zyga: if it stays like this for longer i see myself riding some bike on thursday :)
[08:08] <mvo> zyga: cold here and I'm tired
[08:08] <zyga> mborzecki: do it today
[08:08] <zyga> I already planned it with my daughter
[08:08] <mvo> zyga: but less so than yesterday so yay
[08:08] <zyga> it's going to be 22C today :)
[08:08] <mvo> and good morning mborzecki
[08:08] <mborzecki> mvo: hey :)
[08:09] <zyga> mvo: that's too bad, maybe you should sleep in after all :)
[08:09] <mvo> zyga: heh - I need to get into my timezone :)
[08:09] <mvo> zyga: is the fix already in 2.36? if not I cherry pick now
[08:10] <zyga> mvo: it's not, please look at GitHub notifications
[08:10] <mvo> zyga: I see it now, nice
[08:11] <mvo> zyga: cherry-pick, thanks for the quick reviews (also to mborzecki)
[08:11] <mvo> looks like 2.36.1 is ready :)
[08:11] <zyga> thank you :-)
[08:11] <zyga> yeah
[08:11] <zyga> the classic fix is not important enough to merge, right?
[08:11] <zyga> can wait for 2.37
[08:12] <mvo> zyga: I think its ok to leave it unless you feel strongly about it
[08:12] <zyga> no, I think it should stay out
[08:12] <zyga> 2.36 is big and important and feels stable now
[08:13] <mvo> yeah, I have the same feeling
[08:13] <mvo> zyga: I may try to get 6062 in, field wants this
[08:13] <zyga> aha
[08:13] <mvo> zyga: it looks like there is a real bug there, something in the auth code goes to the net without a proxy
[08:13] <zyga> yeah that looks ok
[08:13] <zyga> hmm
[08:14] <mvo> zyga: its hopefully small, just need to find what it is
[08:14] <zyga> yep
[08:14] <zyga> brb, need to tweak window shades
[08:14] <zyga> it's super bright today
[08:14] <mvo> zyga: ok
[08:23] <pieq> Hi!
[08:23] <zyga> mvo: pieq is from CE and has a question about the release schedule of 2.36.1
[08:27] <mborzecki> snapshot job failed on master: https://paste.ubuntu.com/p/2xHwcG4Kf5/
[08:28] <mvo> zyga: hey pieq, a rough eta is monday in 2 weeks (12 Nov). do you have any specific deadlines that we should know about?
[08:28] <zyga> mborzecki: chipaca knows, we talked about it
[08:28] <mvo> I will also update the snap roadmap it a bit out of date right now, sorry for that
[08:28] <zyga> mborzecki: there's a PR that adds logging, it could use a 2nd review
[08:28] <mborzecki> ack
[08:28] <mborzecki> zyga: #6060?
[08:29] <mup> PR #6060: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
[08:29] <zyga> yes
[08:29] <mvo> zyga: I looked at it had the same question about the matchall writer as you
[09:08] <zyga> hey Chipaca
[09:08] <Chipaca> morning
[09:10] <pieq> mvo hey, sorry for the long silence :) No specific deadline. Since 2.36 is already in beta, guess this shouldn't take too long to be released
[09:10] <pieq> (I ask cause I'm interested in the snap layouts feature developed by zyga. I use it for a snap and currently it seems to work fine except for a UC16 device we have here running core 2.35.4)
[09:14] <pstolowski> morning Chipaca
[09:16] <Chipaca> pstolowski: 'sup
[09:17] <pstolowski> Chipaca: do you have a moment to talk about the fat PR?
[09:17] <Chipaca> pstolowski: yes
[09:17] <Chipaca> pstolowski: hangout, or irc?
[09:17] <pstolowski> zyga: you? ^
[09:17] <zyga> +1
[09:17] <zyga> gladly
[09:17] <pstolowski> Chipaca: hangout
[09:18] <Chipaca> ok, let me get set up. 5 minutes? actually 10 so i can get more coffee
[09:18] <mborzecki> 'fat PR'
[09:18] <Chipaca> let's call it 0930 GMT
[09:18] <mborzecki> should have a label for that
[09:19] <Chipaca> mborzecki: or not have them :-)
[09:19] <pstolowski> Chipaca: ok, in 10min
[09:19] <pstolowski> that would be a funny label i'm sure
[09:25] <doko> snapcraft autopkg tests are failing in bionic, all archs
[09:37] <mup> PR snapd#6067 opened: tests/main/snap-service-after-before-install: verify after/before in snap install <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6067>
[09:47] <Chipaca> ChanServ: what have you *done*?!?
[09:47] <Chipaca> oh hi ogra
[09:47] <ogra> heh
[09:48] <mborzecki> zyga: wow, applied your suggestion directly on github, didn't know it was possible
[09:48] <zyga> ha, yes :)
[09:48] <zyga> it's nice
[09:48] <Chipaca> mvo: did #6062 actually point out the error and now it's grown the fix?
[09:48] <mup> PR #6062: tests: add test to ensure proxy is used even without core <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
[09:48] <Chipaca> mvo: first time I looked at it it was just a spread test =)
[09:49] <mborzecki> btw. maybe we should allow executing systemd-notify in daemon-notify iface?
[09:49] <zyga> I'll be coding quietly in the corner, please ping me for attention
[09:49] <zyga> I won't do reviews today
[09:52] <mvo> Chipaca: correct
[09:52] <mvo> Chipaca: let me update the description
[09:52] <mvo> Chipaca: it started as a simple test to ensure this really works but it turned out that the device session stuff is not using the proxy so things explode
[09:54] <Chipaca> mvo: tests ftw
[09:54] <Chipaca> mvo: I wouldn't've been able to do the hackery I did last night to version.go without 'em =)
[09:55] <mvo> Chipaca: yeah, nothing beats integration tests
[09:55] <mvo> (except maybe real users)
[09:55] <mvo> Chipaca: heh :) yeah, the version stuff is quite impressive
[09:55] <mvo> Chipaca: just looked at it
[09:56] <mvo> Chipaca: I want to look over the proxy stuff a bit, was wondering if some things should be methods on store.Store{} now - but my gut-feeling is no. but I'm not sure yet, maybe a new auth helper struct or something, want to medidate a bit over this. ideas welcome fwiw
[09:57] <Chipaca> actual users beat everything, yes. Sometimes to death :-þ
[09:58] <Chipaca> mvo: me I'd like to refactor store so it doesn't pull in overlord stuff
[09:58] <Chipaca> mvo: (mostly auth)
[09:58] <Chipaca> so maybe there's something there
[09:58] <Chipaca> i mean, maybe these two things are the same thing :-)
[09:58] <mvo> Chipaca: with the proxy setting stuff we need state it seems, no?
[09:59] <Chipaca> mvo: yes. But does store need to know it's state, or is there an interface that would serve?
[09:59] <Chipaca> it's the things calling it that need to get the actual state; store shouldn't care
[09:59] <mvo> Chipaca: aha, yeah, an interface is probably fine
[09:59] <mborzecki> Chipaca: as for version, we had some code checking kernel version and VersionCompare would trip over the uname -r in Arch
[09:59] <Chipaca> imo
[09:59] <mvo> Chipaca: thats a good idea for direction
[10:00] <Chipaca> mborzecki: the old one, or the new one, or both?
[10:00] <mborzecki> Chipaca: old one, probably new one too
[10:00] <pieq> mvo, zyga another question: will snap layout feature leave its experimental status with the release of snapd 2.36? Or will we still have to manually type `sudo snap set core experimental.layouts=true` before isntalling a snap using it
[10:00] <Chipaca> mborzecki: AIUI our VersionCompare is just debian's
[10:00] <zyga> pieq: you won't have to do that in 2.36
[10:00] <Chipaca> pieq: layout is no longer experimental in 2.36 as it exists in beta today
[10:00] <zyga> you can still disable it by setting it to false
[10:00] <pieq> \o/
[10:01] <zyga> but absence of a setting is now interpreted as true
[10:01] <Chipaca> pieq: why not install beta and try it out? feedback needed
[10:01] <pieq> zyga, Chipaca ok thanks for clarifying it!
[10:01] <pieq> Chipaca, I already did actually, but I machinally typed the command anyway :)
[10:01] <mborzecki> Chipaca: uname -r is currently 4.18.16-arch1-1-ARCH, iirc i saw 4.18.2-arch1.a2-1-ARCH at some point too
[10:01] <Chipaca> /o =)
[10:02] <Chipaca> mborzecki: ah, too many dashes for ours to be happy
[10:02] <mvo> yeah, version compare only allows a single "-"
[10:02] <Chipaca> we could relax that easily, fwiw
[10:02] <mvo> (the debian version policy is written this way where we inherited this from
[10:02] <mvo> )
[10:02] <Chipaca> "easily" -> generalise it to arbitrary number of -s
[10:03] <mvo> what would the semantic be if we do that? 1-1 is lt,gt 1 ? 1-1 lt/gt 1-1-1 ?
[10:03] <Chipaca> only question that'd need answering is, is 1-1 >? 1-1-1
[10:03] <Chipaca> exactly
[10:03] <mvo> (we could treat it just like a ".")
[10:04] <mvo> for the kernel we simply could ignore everything after the second "-" (including the second "-")
[10:05] <mvo> 4.15.0-36-generic should be equal in version to 4.15.0-36-bigtable
[10:05] <Chipaca> augh, i'd meant to tag you in the pr that changes version this much, but forgot (was very late...)
[10:05]  * Chipaca does it now
[10:05] <mvo> no worries
[10:05] <Chipaca> mborzecki: is that right, on arch? ^
[10:05] <Chipaca> mborzecki: and, what did we use the kernel version compare for? =)
[10:06] <mvo> don't we already strip the second "-" anyway?
[10:07] <mvo> fwiw, I updated the description of 6062
[10:07] <mborzecki> Chipaca: it was used to guess whether we should degrade apparmor profile, but then i dropped it because the host is always using the latest mainline
[10:11] <mup> PR snapd#6068 opened: ifacestate/helpers: findConnsForHotplugKey helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6068>
[10:11] <pstolowski> Chipaca, zyga ^ exposing connState wasn't neccessary at the end
[10:12] <mvo> Chipaca: would love to hear your opinion on https://github.com/snapcore/snapd/pull/6062#discussion_r229244418 (and the one below). if we make User{Login,Info} part of the store interface this PR would probably slightly shorter and it seems to also make sense that this is part of the store interface (even though it bloats the interface)
[10:12] <mup> PR #6062: tests,store,daemon: ensure proxy settings are honored in auth/userinfo too <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
[10:16] <mborzecki> zyga: pstolowski: are you taking 02.11 off too?
[10:17] <zyga> yes
[10:17] <mborzecki> ah, nice :)
[10:17] <pstolowski> i'm not
[10:21] <mvo> me too
[10:24] <Chipaca> mvo: that sounds alright
[10:24] <Chipaca> mvo: will comment on the pr
[10:27] <mvo> Chipaca: ta, will do
[10:43] <Chipaca> going for a run, bbl
[10:58] <mup> PR snapd#6069 opened: ifacestate/hotplug: removeDevice helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/6069>
[11:10] <sborovkov> ogra: btw, on the matter of force_turbo. The only reason we want to turn it on is because there seems to be some bug in firmware or kernel module. When we play videos it will correctly start ramping up in 1 of 30 playbacks which is so weird... The same goes about governing policy. It ramps up extremely slow. Both on core and raspbian.
[11:17] <mborzecki> so today is red dead travis job day
[11:18] <mborzecki> oh and opensuse mirros have hiccups again
[11:19] <mborzecki> pstolowski: is information wehether a connection is auto/manual kept in the state only?
[11:19] <pstolowski> mborzecki: yes
[11:20] <mborzecki> pstolowski: i'm looking aroudn the code, but it does not seem to be available in ConnRef or interfaces.Info
[11:21] <mborzecki> pstolowski: wondering if, in the context of https://forum.snapcraft.io/t/rfc-snap-connections-command/4296 we should show hotplug in Notes column too
[11:22] <pstolowski> mborzecki: we will only auto connect hotplug slots if their interfaces are declared as such
[11:23] <pstolowski> mborzecki: but yeah, we might want to show something about hotplug
[11:23] <mborzecki> pstolowski: https://paste.ubuntu.com/p/TcGjVXbm5D/ snap connections output i'm currently playing with (sans manual/hotplug in the notes column)
[11:24] <pstolowski> mborzecki: hotplug can be manual as well
[11:25] <mborzecki> pstolowski: right, so that would be hotplug,manual in the notes
[11:25] <pstolowski> mborzecki: hotplug will just create slots dynamically, some of them may auto-connect, some you need to connect manually
[11:25] <mvo> Chipaca: heh, just looking at the proxy stuff it is already pretty abstracted, it does not pull anything state related in (yay)
[11:25] <mborzecki> pstolowski: what the example slot names for say usb serial device?
[11:28] <pstolowski> mborzecki: they are automatically generated from some key attributes - e.g. "ft232rusbuart" (one of the adapters i test with). another example "qemuusbserial" for qemu virtual adapter
[11:37] <mborzecki> pstolowski: thx
[12:15] <mvo> opensuse is unhappy it seems, second failure this morning related to repo install/update
[12:15] <mup> PR snapd#6070 opened: store,daemon: make UserInfo,LoginUser part of the store interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6070>
[12:15] <mvo> Chipaca: ^- what we discussed, happy to move it all into a single PR if you prefer this, either way is fine for me
[12:16] <mvo> Chipaca: the upside is that the mocks in the api_test get simpler too
[12:19] <Chipaca> mvo: nice
[12:19] <Chipaca> mvo: I'll review properly after the standup (now making lunch)
[12:19] <Chipaca> trying to not get caught out like i was yesterday
[12:21] <cachio> pstolowski, you can use #6066 to develop hotplug tests
[12:21] <mup> PR #6066: tests: fixes and new backend for tests on nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6066>
[12:21] <cachio> pstolowski, it runs in 11 minutes the test
[12:27] <pstolowski> cachio: wooah, awesome!
[12:30] <pstolowski> cachio: thank you, will merge into my branch and try it soon
[12:32] <cachio> pstolowski, nice
[12:42] <mup> PR snapd#6071 opened: ifacestate/hotplug: updateDevice helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6071>
[12:46] <Chipaca> sborovkov: is it the cpu, or the gpu ramping up?
[12:49] <ogra> Chipaca, it is "delaying the cpu from ramping up" as i understood
[12:49] <Chipaca> yeah, but i thought they were doing gpu decoding
[12:50] <Chipaca> so maybe it's the gpu? dunno
[12:50] <Chipaca> i know nothing =)
[12:50] <ogra> could be ... we dont really support the proprietary driver on the Pi ... so it could well be some drawback in the opensource vc4 driver
[12:55] <sborovkov> Chipaca: both I think
[12:55] <mup> PR snapd#6064 closed: many: move regexp.(Must)Compile out of non-init functions into variables <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6064>
[12:57] <sborovkov> Chipaca: if we have on demand scheduler ramping up of CPU happens slowly. If we play 10 second videos - they all take 60 ms per frame. Eventually it goes to the 30 ms per frame. And then if stars align they stop underclocking GPU and memory and it goes to 13 ms per frame, but that almost never happens.
[12:57] <mvo> Dmitrii-Sh: thanks again for your proxy report, I updated the LP bug and pointed to the PR that should fix the issue. thanks again for reporting!
[13:02] <Dmitrii-Sh> mvo: thanks for following up! I'll give it a try
[13:13] <sborovkov> Chipaca, ogra and cpu usage is super low. The only thing that's taking up cpu is audio decoding which is not a lot. I found it by chance basically. 30 ms was what happened in most of the cases. Until I came back to my rpi in the next morning and it magically was taking 13 ms per frame. and since force_turbo does not overclock but prevents it to go to the low frequencies when idle that seems to be the answer. force_turbo also set couple of options like
[13:13] <sborovkov> minimum frequeny for cpu, gpu and memory to higher values.
[13:18] <ogra> right, it is simply not as power effectiver after you set it ... but since you dont run on battery (i assume) this is ignorable
[13:36] <Chipaca> mborzecki: so... vercmp (https://git.archlinux.org/pacman.git/tree/src/util/vercmp.c) is just a frontend for alpm_pkg_vercmp, which is in https://git.archlinux.org/pacman.git/tree/lib/libalpm/version.c
[13:36] <Chipaca> mborzecki: and it's just doing rpmvercmp on EVR
[13:36] <Chipaca> epoch-version-release
[13:36] <Chipaca> no
[13:36] <Chipaca> epoch:version-release
[13:36] <mborzecki> looking
[13:37]  * Chipaca drags people into the madness
[13:37]  * Chipaca walks away
[13:38] <mborzecki> Chipaca: /* whichever number has more digits wins */ heh
[13:46] <Chipaca> mborzecki: so i think that instead of supporting arch-style versions, we want to go with plan B
[13:46] <Chipaca> mborzecki: run away screaming
[13:47] <mborzecki> Chipaca: plan C, do nothing until required
[13:47] <Chipaca> interestingly it claims to be taken from rpm, so
[13:47] <Chipaca> mborzecki: that's like plan B but for sensible people
[13:47] <mvo> afaict in rpm only a single "-" is speced
[13:48] <mvo> aha, no - it seems they cut after the first "-" but then its legal in the "remainder"
[13:48] <Chipaca> mvo: this only looks at one -; the rest are … for free? i think. maybe
[13:48] <mborzecki> Chipaca: https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmvercmp.c
[13:49] <mvo> anyway I like the idea of ignoring it until it becomes a problem :)
[13:49] <Chipaca> mborzecki: https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmvercmp.c#L94
[13:50] <Chipaca> mvo: yep
[13:50] <Chipaca> anyway, i'll probably split the current thing into two prs as per zyga's request
[13:50] <Chipaca> but tonight when i'm in that sort of a mood
[13:56] <mborzecki> since go-1.10 appears to be in xenial-updates and trusty updates, can we drop importing golang.org/x/net/context now?
[13:58] <mborzecki> Chipaca: mvo: ^^
[13:58] <Chipaca> mborzecki: hmm
[13:59] <Chipaca> mvo: did you talk any further on removing go from main?
[14:04] <mborzecki> off to pick up the kids
[14:05] <mvo> Chipaca: we did not talk about removing go from main
[14:05] <mvo> mborzecki: I think we can and move to go 1.9
[14:06] <mvo> zyga: sent mail about /v2/interfaces
[14:17] <zyga> Ack mvo
[14:18] <zyga> I’ll reply in one hour
[14:27] <mvo> Chipaca: snap info core and the new slightly highlighted channel that is tracked is such a nice feature (subtle but really nice)
[14:27] <Chipaca> mvo: also a little bit buggy =) but yes
[14:28] <mvo> Chipaca: not buggy for me :)
[14:28] <mvo> Chipaca: its one of those nice touches that makes me thing that "woah, extra polish"
[14:28] <Chipaca> mvo: when there is a refresh not yet applied, it might seem wrong
[14:29] <Chipaca> mvo: but it's very subtle, and arguable
[14:30]  * mvo nods
[14:30] <mvo> Chipaca: aha, so after "snap switch" the output might be confusing?
[14:30] <mvo> (until the next refresh)
[14:30] <Chipaca> mvo: yes
[14:30]  * mvo nods
[14:31] <Chipaca> emphasis on might
[14:31] <mvo> yes
[14:31] <Chipaca> we might need some polish on the polish
[14:31] <Chipaca> like, bold one line and caret the other
[14:31] <Chipaca> or sth, dunno
[14:31] <Chipaca> ¯\_(ツ)_/¯
[14:32] <Chipaca> it does make it a lot easier to spot the thing you're on
[14:32] <mvo> yeah, what we have is pretty nice even with the caveats you gave
[15:11] <cachio> pstolowski, I have update the branch with an intermediate solution
[15:11] <cachio> hotplug takes 15 minutes with this
[15:11] <pstolowski> cachio: ok, thanks for the info
[15:12] <cachio> I'll continue working on another PR which uses the other aproach which takes 11 minutes
[15:12] <cachio> but I need to work a bit more in order to get a good solution for all the tests
[15:13] <cachio> core revert test went from 36 to 17 minutes with this approach
[15:13] <cachio> that0s good improvemente
[15:18] <pstolowski> cachio: yes, it's fantastic
[15:18] <mup> PR snapd#6072 opened: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6072>
[15:20]  * Chipaca hugs cachio 
[15:20] <Chipaca> cachio: that's awesome dude
[15:21] <cachio> Chipaca, tx
[15:30] <zyga> re
[15:31] <zyga> halloween costume procured
[15:31] <zyga> Chipaca: should the polish on polish be added by polish?
[15:39]  * cachio lunch
[15:41] <Chipaca> zyga: Solidarność! or something
[15:41] <zyga> haha
[15:42] <zyga> nice, including ś and ć
[15:43] <Chipaca> yeah they charge extra for those, but I thought it was worth it
[15:50] <mup> Issue core18#56 closed: Sensible version number <Created by mvo5> <https://github.com/snapcore/core18/issue/56>
[15:50] <mup> Issue core18#86 closed: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
[15:50] <mup> PR # closed: core18#43, core18#63, core18#72, core18#83, core18#84
[15:51] <mup> Issue core18#56 opened: Sensible version number <Created by mvo5> <https://github.com/snapcore/core18/issue/56>
[15:51] <mup> Issue core18#86 opened: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
[15:51] <mup> PR # opened: core18#43, core18#63, core18#72, core18#83, core18#84
[16:04] <pstolowski> cachio: just tested it, it's day and night!
[16:05] <pstolowski> ty!
[16:16] <mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2380, snapcraft#2387
[16:19] <mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2380, snapcraft#2387
[16:29] <Pharaoh_Atem> zyga: so we're finally going to have the gcp packages as part of fedora, and we're looking to figure out how to let google let us have official images in GCP
[16:30] <zyga> Pharaoh_Atem: that's good to know
[16:30] <zyga> thank you for sharing
[16:30] <zyga> oh, I have one thing to share as well
[16:30] <zyga> I was working with Zbyszek on mkosi
[16:30] <Pharaoh_Atem> oh?
[16:30] <zyga> and we will be working on fedora29 base snap release
[16:30] <Pharaoh_Atem> sweet
[16:30] <zyga> built entirely by mkosi
[16:30] <Pharaoh_Atem> that's actually sweet
[16:30] <Pharaoh_Atem> that's similar to what I was working on :)
[16:30] <Pharaoh_Atem> I wish I had known
[16:30] <zyga> it started last Friday
[16:30] <zyga> sorry for not mentioning it before
[16:31] <zyga> some busy days
[16:31] <zyga> and then the IBM thing
[16:31] <Pharaoh_Atem> yeah...
[16:31] <zyga> so after Zbyszek is recovered from shock I we will meet up again to work on mkosi
[16:31] <zyga> I am writing static typing support for it
[16:31] <Pharaoh_Atem> cool
[16:31] <zyga> so that the quality is better
[16:31] <Pharaoh_Atem> mkosi is a really nice, simple tool
[16:31] <zyga> and zbyszek has made it possible to build base snaps with it
[16:31] <Pharaoh_Atem> sweet
[16:31] <Pharaoh_Atem> which means all distros can use it
[16:31] <zyga> so some more work remains but progress looks good
[16:31] <zyga> yeah!
[16:32] <Pharaoh_Atem> and maybe ubuntu will switch to it too :P
[16:32] <zyga> I was thinking about it actually
[16:32] <zyga> it remains to be seen
[16:32] <zyga> but it's foundations now
[16:32] <zyga> not us doing the core snaps
[16:32] <zyga> (finally)
[16:32] <Pharaoh_Atem> I figured mkosi would also make it easier to make lightweight bootable snaps
[16:32] <zyga> anyway, we need to work on the essentials first
[16:32] <zyga> shipping updated mkosi :)
[16:32] <zyga> so that's that
[16:32] <Pharaoh_Atem> that part is easy on the fedora side :)
[16:32] <zyga> I'm working on a suse update
[16:33] <zyga> and there's some fedora work scheduled this cycle, we should get much better selinux support
[16:33] <zyga> so looking forward to that
[16:33] <zyga> maybe (though not for sure) some work on selinux backend for services
[16:33] <zyga> we'll see about that
[16:49] <pstolowski> zyga: hey, do you have a moment to take a look at #6068?
[16:49] <mup> PR #6068: ifacestate/helpers: findConnsForHotplugKey helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6068>
[16:50] <zyga> pstolowski: yep, sure
[16:54] <zyga> done
[16:56] <pstolowski> zyga: thanks! fwtw i added ordering in the test
[16:57] <zyga> I missed that, I see it now
[16:57] <zyga> how are you planning on using this?
[16:57] <zyga> should ordering be built in?
[16:58] <pstolowski> zyga: ordering doesn't matter for real use.. so only relevant for tests
[17:00] <pstolowski> zyga: regarding your other suggestion to have map[string]*connState, it's sensible, but I'll need to change getConns and setConns as well (and likely a few places where they are used)
[17:00] <pstolowski> cause they also have map[string]connState
[17:00] <zyga> pstolowski: don't change it here
[17:00] <zyga> just wondering aloud really
[17:00] <zyga> about the ordering still
[17:01] <zyga> will the result be typically 0-2 elements long?
[17:01] <pstolowski> probably yes
[17:02] <zyga> could we add sorting then
[17:02] <pstolowski> sure
[17:02] <zyga> I'm slightly against non-deterministic ordering leaking around the code
[17:02] <zyga> if it is cheap, let us just do it please
[17:03] <pstolowski> yep that's fine
[17:03] <zyga> thank you
[17:03] <zyga> approved!
[17:04] <pstolowski> thanks
[17:04] <zyga> thanks :)
[17:05] <zyga> offtopic
[17:05] <zyga> new Mac mini looks like a pretty great deal
[17:27] <Chipaca> zyga: pstolowski: I liked it more when it sorted for the tests =)
[17:28] <zyga> Chipaca: nondeterminism spreads like tainted perl values :)
[17:28] <Chipaca> zyga: that's what she said!
[17:28]  * zyga is speechless ;)
[17:29] <Chipaca> sometimes for the best
[17:29] <zyga> busted!
[17:29] <Chipaca> zyga: universally, not just you
[17:30] <zyga> that's what she said ;)
[17:32]  * Chipaca approves ALL the PRs
[17:34] <zyga> kids can play when adults are off ;)
[17:34] <zyga> we can revert on Monday
[17:36] <Chipaca> sigh, another snapshot error with no good logs
[17:38] <zyga> Chipaca: can we merge anything to make it possible to collect them?
[17:38] <zyga> this reminds me, I need to prepare a proper PR for my idea for collecting logs for mount ops
[17:38] <zyga> maybe there's something to learn?
[17:38] <zyga> using a feature flag file I now collect logs for what happens in each mount namespace
[17:38] <zyga> alonside the mount namespace
[17:39] <Chipaca> zyga: #6060 is for that
[17:39] <mup> PR #6060: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
[17:39] <zyga> yeah but that's ... not sure
[17:39] <zyga> it doesn't feel right
[17:39] <zyga> the matches
[17:39] <zyga> *matcher
[17:39] <Chipaca> zyga: I can drop that bit, all I was  doing was making the errors on read  an write the same
[17:40] <zyga> I'd +1 that
[17:45] <Chipaca> zyga: what is it that you don't like about the matcher?
[17:45] <zyga> It feels heavy to process all output this way
[17:45] <zyga> but perhaps I was mistaken
[17:46] <Chipaca> zyga: as opposed to which way?
[17:47] <zyga> not sure, redirecting all output to a log file when env is set
[17:47] <zyga> or something similar
[17:47] <zyga> but perhaps I'm just picky
[17:47] <zyga> sorry about that
[17:47] <Chipaca> zyga: um
[17:47] <Chipaca> zyga: so, what this does is
[17:47] <Chipaca> zyga: it catches and remembers the first line of stderr of tar
[17:48] <Chipaca> zyga: and counts lines from there on
[17:48] <Chipaca> zyga: if SNAPPY_TESTING is set,  it also writes to stderr
[17:48] <zyga> using regular expressions :)
[17:48] <zyga> that was the part I was objecting to
[17:49] <Chipaca> hmm
[17:50] <zyga> let's push that for tomorrow
[17:51] <Chipaca> I'm missing what's bad, here :-/
[17:51] <Chipaca> but ok
[17:51] <Chipaca> tomorrow is fine
[19:05] <mup> PR snapd#6073 opened: strutil: let MatchCounter work with a nil regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/6073>
[19:05] <Chipaca> zyga: ^
[19:15] <zyga> aha
[19:16] <ackk> hi, I have a (classic) snap that stopped working (not sure when), it currently seem to just hang
[19:16] <ackk> a strace stops at the exec of snap-confine
[19:18] <ackk> how can I debug the issue (tried on different systems and ubuntu releases, same result)
[19:29] <mup> PR snapd#6074 opened: strutil: make VersionCompare faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6074>
[19:49] <ackk> zyga, any idea what could cause this issue? ^
[19:58] <Chipaca> ackk: are you using 'snap run --strace'?
[19:58] <Chipaca> ackk: or are you strace'ing snap run?
[19:58] <ackk> Chipaca, snap run --strace
[19:59] <Chipaca> ah
[19:59] <Chipaca> dunno :-)
[19:59] <ackk> Chipaca, it's a published snap fwiw
[19:59] <Chipaca> ackk: public?
[19:59] <ackk> yeah
[19:59] <ackk> Chipaca, snap install --edge --classic sshoot
[20:00] <ackk> (then "sshoot")
[20:04] <Chipaca> hm, something is really slow
[20:05] <cachio> kyrofa, hey
[20:05] <cachio> did you already merged the change on the images?
[20:05] <cachio> Saviq, hey
[20:06] <cachio> we are changing the name of the images with virt enabled
[20:06] <cachio> if you are using them please tell me
[20:06] <Chipaca> zyga: btw you might like the pretty pics on #6074
[20:06] <mup> PR #6074: strutil: make VersionCompare faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6074>
[20:06] <zyga> ackk: hey
[20:06] <cachio> Saviq, because a change in the names is needed
[20:06] <zyga> ackk: is it spinning with 100% CPU?
[20:06] <zyga> Chipaca: looking at 6074
[20:07] <zyga> woah
[20:07] <zyga> man
[20:07] <zyga> that's impressive
[20:07] <zyga> I will review tomorrow as tonight I feel too tired to think about that reasonably
[20:07] <Chipaca> I'm particularly happy with the 0s
[20:07] <zyga> but I want to ack the effort!
[20:07] <zyga> ackk: if it is spinning on 100% CPU
[20:07] <zyga> ackk: it may be in an exec loop
[20:08] <zyga> ackk: it typically happens in a scenario like this:
[20:08] <Chipaca> store is timing out, fwiw
[20:08] <zyga> ackk: foo (command)
[20:08] <zyga> ackk: foo -> snap run foo -> snap-confine -> snap-exec -> (look up and run foo) -> /snap/bin/foo -> snap run foo (Oh my...)
[20:08] <Saviq> cachio: ack, not using them yet - we noticed fedora 27 is gone now? (not a problem, just in case this is unexpected)
[20:09] <Saviq> should there be 29 images yet?
[20:09] <cachio> Saviq, is it already released?
[20:10] <ackk> zyga, it does seem something like that
[20:10] <cachio> Saviq, I'll check that and create the image tomorrow
[20:10] <ackk> zyga, and yes, it's spinning
[20:10] <zyga> just change command
[20:10] <ackk> wdym
[20:10] <zyga> to use $SNAP/bin/stuff
[20:10] <zyga> +1
[20:17] <Chipaca> ackk: it does look like the command wrapper will find itself again
[20:17] <Chipaca> ackk: especially as you're classic
[20:18] <ackk> Chipaca, ah I see
[20:27] <mup> PR snapd#6075 opened: tests: removing fedora 26 system from spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6075>
[20:29] <mup> PR snapd#6076 opened: tests: linode execution is not needed anymore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6076>
[20:33]  * mvo hugs Chipaca for 6074 - slightly crazy but in a good way :-D
[20:39] <kyrofa> cachio, just merged
[20:40] <mup> PR snapcraft#2387 closed: spread: change virt-enabled image name <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2387>
[20:46] <ackk> Chipaca, zyga thanks, that was the reason
[20:51] <zyga> ackk: cool
[20:51] <zyga> I wonder if we can detect that ...
[21:19] <cachio> kyrofa, perfect, thanks
[21:20] <Saviq> cachio: just about - https://fedoraproject.org/wiki/Releases/29/Schedule
[21:20] <cachio> Saviq, nice, thanks
[21:20] <cachio> tomorrow I'll work on that
[21:38]  * cachio afk
[21:45] <popey> oh, 2.35.5 just released?
[21:53] <zyga> mvo is busy at night