=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== pstolowski|afk is now known as pstolowski
[08:04] <pstolowski> mornings
[08:11] <pedronis> pstolowski: morning
[08:13] <mvo> hey pstolowski and pedronis
[08:13] <pedronis> pstolowski: when you have a moment could you review #6576 , is adding yet another attr merger, I wonder if it can reuse something or there is something to expose from else to avoid that
[08:13] <mup> PR #6576: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6576>
[08:13] <pedronis> *elsewhere
[08:13] <pstolowski> pedronis: looking at it right now
[08:13] <pedronis> thank you
[08:14] <pedronis> mvo: hi
[08:42] <pstolowski> pedronis: i think we avoided attrs merger after all; it was floating around in the interface hooks PRs concerning policy check, but it eventually got replaced by implementation using Attrer interface and Lookup method, which looks dynamic/static attrs up without merging them physically
[08:44] <pedronis> pstolowski: ah, I forgot
[08:44] <pstolowski> pedronis: re that PR i'm wondering if we shouldn't leave merging to the client (instead of doing it api-side), more future-proof in case we ever want to distinguish them if the cli grows some new options (e.g. "show me only attributes set by hooks")
[08:44] <pedronis> pstolowski: not sure, that sounds more like a debug thing
[08:45] <pedronis> an attriute could be set statically or dynamically
[08:45] <pedronis> it shouldn't matter too much
[08:45] <pedronis> from somebody looking from outside
[08:45] <mvo> pstolowski: hey, I remember you had a problem with check.DeepEqual going into a circular list and eating memory like crazy, what was the solution back then? it seems one of my tests has hit this now too
[08:46] <pstolowski> maybe, probably. just a remark, when we do that it's set in stone as far as api is concerned, harder to change
[08:46] <pstolowski> mvo: i've a fix proposed upstream, but upstream is silent. one sec
[08:47] <pedronis> pstolowski: those set are supposed to be disjoint, right?
[08:47] <pedronis> we don't let you override
[08:47] <pedronis> if I remeber correctly
[08:47] <pstolowski> pedronis: yes, we don't allow that
[08:47] <pedronis> pstolowski: so we have options
[08:47] <pstolowski> mvo: https://github.com/kr/pretty/pull/58
[08:47] <mup> PR kr/pretty#58: Fix infinite recursion when diffing structs with cycles <Created by stolowski> <https://github.com/kr/pretty/pull/58>
[08:47] <pedronis> anyway
[08:48] <pedronis> pstolowski: like return a list of dynamic attr names
[08:48] <mvo> pstolowski: ta
[08:48] <pedronis> if needed
[08:48] <pstolowski> mvo: i made a comment on that in the trello card as well a while ago.. perhaps we should move this into our tree
[08:48] <pedronis> pstolowski: what I'm not sure though if the merging should happen in interface mgr or daemon
[08:48] <pedronis> but that we can always change
[08:51] <mvo> pstolowski: thank you!
[08:52] <pstolowski> mvo: i recently helped Chipaca with this fix as well.. so seems to be recurring problem with tests
[08:53] <mvo> pstolowski: yeah, I pinged in the PR again (the kr) one, but yeah, maybe we need to fork it :(
[08:56] <pstolowski> mvo: yeah that would be unfortunate. let me know if the fix helps
=== sparkieg` is now known as sparkiegeek
[09:25] <zyga> Hello
[09:26] <zyga> If this continues I will start filing mornings off :/
[09:27] <pstolowski> hey zyga, what happend?
[09:28] <zyga> Homework late, kitchen cleaning late, bed time late, morning early kids prep. ENOSLEEP
[09:29] <zyga> I woke up at 6 but fell asleep after kids went to school at 8
[09:51] <pstolowski> aha
[11:08] <pedronis> pstolowski: I did I think the last pass on 6562
[11:09] <pstolowski> pedronis: ok, looking, ta
[11:11] <pedronis> pstolowski: if the comments make sense, I can +1 it
[11:12] <pedronis> pstolowski: as we discussed we can explore the Timing interface idea in a followup
[11:18] <pedronis> #6572 needs a 2nd review
[11:18] <mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
[11:18] <pedronis> (it's part of a refactoring chain)
[11:21] <pstolowski> pedronis: updated
[11:22] <pstolowski> ah, updating description of the PR
[11:28] <mvo> pstolowski: happy to look at the timings pr again as well, I'm excited about this (but I think I mentioned this before ;)
[11:28] <pstolowski> mvo: ty :)
[11:29]  * mvo just needs to finish his own PR first
[11:33]  * zyga is slowly starting to work now
[11:33] <zyga> mvo: I'll file the morning off
[11:34] <zyga> sorry, I just feel so tired today
[11:37] <zyga> https://github.com/snapcore/snapd/pull/6572 is an easy win
[11:37] <mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
[11:49] <cachio> mvo, hey
[11:49] <cachio> is snapd 2.38 going to beta as well?
[11:51] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6568 is green and has two reviiews
[11:51] <mup> PR #6568: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap <Created by stolowski> <https://github.com/snapcore/snapd/pull/6568>
[11:54] <pstolowski> zyga: thanks; im not sure if pedronis would like to take a look?
[11:55] <zyga> pstolowski: let's add him to the review
[12:01] <mvo> cachio: yeah, 2.38~pre1 for the snapd snap should go into beta as well, once 2.37.4 for the snapd snap is in candidate I will arrange that
[12:03] <mup> PR snapd#6577 opened: many: make Remodel() download everything first before installing <Created by mvo5> <https://github.com/snapcore/snapd/pull/6577>
[12:05] <cachio> mvo, ok, I'll ask about what's missing
[12:05] <cachio> I gave the +1 last friday
[12:11] <pedronis> pstolowski: zyga:  is there something deep going on in 6568 ?  (I don't think I need to review everything)
[12:12] <zyga> pedronis: I don't think so, just easier to get your qucik decision if you want to review it
[12:13] <pedronis> the problem there is more that nobody has told us of this bug, maybe people don't expect the behavior
[12:13] <pedronis> or maybe configure is not used a lot
[12:19] <mvo> cachio: thanks, I just double checked and put the right 2.37.4 of the snapd snap into the beta channel - once that is validated please move it to candidate
[12:33] <pstolowski> pedronis: i think the chances of hitting this were simply very very slim, not only you need to have configure hook, it also needs to change config to something new on refresh, and then you need to hit an error for undo to kick in
[12:33] <pedronis> pstolowski: anyway I added John to review it
[12:33] <pedronis> and removed myself
[12:33] <pstolowski> ok
=== ricab is now known as ricab|lunch
[13:20] <zyga> mvo: do you have time for a quick review
[13:20] <zyga> https://github.com/snapcore/snapd/pull/6572
[13:20] <mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
[13:20] <zyga> it is just taking a bit of code and wrapping it in a function
[13:28] <mvo> zyga: meeting(s) now, after that yes
[13:29] <mvo> zyga: thanks for looking into this why
[13:30] <zyga> mvo: I'll take the whole day off, I'm just 100% useless today
=== ricab|lunch is now known as ricab
[14:52] <mup> PR snapd#6572 closed: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6572>
[15:05] <dot-tobias> cjwatson: I just got this error on a LP builder while cloning a public Github repo: “Received HTTP code 407 from proxy after CONNECT” → couldn't find any forum entry, is this a known problem or should I just retry? Same snapcraft.yaml works fine on my local machine.
[15:06] <cjwatson> dot-tobias: I need a link to the build in order to say anything useful
[15:07] <cjwatson> Also we don't in general track Launchpad issues on the forum
[15:07] <dot-tobias> cjwatson: https://launchpadlibrarian.net/414273477/buildlog_snap_ubuntu_bionic_armhf_wpe-webkit-mir-kiosk_BUILDING.txt.gz
[15:07] <cjwatson> (Sometimes we post about major changes there)
[15:08] <cjwatson> dot-tobias: Right, so the proxy gives two hours of internet access to a build; this is a rough cut-off to reduce things like potential botnet impact
[15:08] <cjwatson> dot-tobias: The failure in this case was more than two hours into the build
[15:08] <cjwatson> dot-tobias: So you need to take steps to ensure that your pulls happen generally towards the start of the build process, or at least not over two hours in
[15:09] <cjwatson> dot-tobias: I think there are normally ways to do this by reordering parts
[15:09] <dot-tobias> cjwatson: Ok, that explains it. Unfortunately, the wpe-webkit just takes a lot of time to build and I can't build the github part before wpe-webkit (or it would fail to find the libs).
[15:09] <cjwatson> Can you use some kind of dummy part to pull it earlier and then have a subsequent part do the actual build?
[15:10] <cjwatson> This is slightly more snapcraft wizardry than I possess myself, but I think I've seen people doing that kind of thing ...
[15:10] <dot-tobias> cjwatson: May be an option, but I'll just put the checked-out tag in the snap source until the snap is finished. Just wanted to make sure its not something else 😊 Thanks!
[15:11] <cjwatson> OK
[15:28]  * cachio lunch
[15:39]  * zyga woke up and pushed master into https://github.com/snapcore/snapd/pull/6573
[15:39] <mup> PR #6573: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <https://github.com/snapcore/snapd/pull/6573>
[17:35] <sergiusens> mvo: kyrofa pinging you as I saw your conversation flow through, had this in draft for over a week as I couldn't get to editing it before shutting y computer down: http://blog.sergiusens.org/posts/broader-use-of-bases-for-snaps/
[17:37] <cjwatson> sergiusens: Ah, is LP going to need to look at build-base as well as base in order to work out what builder base images to dispatch to?  A bug would be appreciated if so to tell us what the priority order should be
[17:39] <sergiusens> cjwatson: I will let the snapd folks timeline that, as the feature is only relevant once `base: none` is implemented on their side
[17:39] <sergiusens> pedronis: mvo ^
[17:39] <cjwatson> sergiusens: (see https://bazaar.launchpad.net/+branch/launchpad/view/head:/lib/lp/snappy/model/snap.py#L620)
[17:40] <diddledan> do we know of any costs involved in layouts with many configured mounts?
[17:40] <diddledan> this is where I'm heading... https://www.irccloud.com/pastebin/G7thrJLE/
[17:40] <ijohnson> diddledan: it increases the call to apparmor_parser and generating the apparmor profile is proportional to the number of mounts last time I checked
[17:41] <diddledan> I'm wondering which is faster and less resource intensive for runtime: either mounting everything up the wazoo or a huge launcher script
[17:41] <ijohnson> diddledan: I think what you have there in that snippet is probably fine, I tried it with over 1000 layouts specified and apparmor crashed :-(
[17:42] <diddledan> oops :-p
[17:42] <ijohnson> I think layouts would be faster because you only pay that apparmor cost once, and then it's like those files are already there
[17:42] <diddledan> I'm thinking about adding some of those into the gnome extension, you see, so I want to be sure it's better
[17:42] <ijohnson> (because they are)
[17:42] <diddledan> cc/ sergiusens
[17:43] <sergiusens> diddledan: you should cc cmatsuoka and kenvandine instead 🙂
[17:43] <diddledan> roger :-p
[17:43]  * sergiusens is a plasma user
[17:43] <diddledan> haha
[17:44] <sergiusens> where less hacks are needed
[17:45] <diddledan> this is my untested (yet) new launch script for mycroft - MUCH shorter! https://www.irccloud.com/pastebin/Vn6kaHm3/
[17:47]  * cmatsuoka is a gnome user, but agrees with sergiusens 
[17:48] <mvo> sergiusens: my memory is a bit hazy but I thought we said that snapcraft could simply script "base: none" from the snapcraft.yaml when generating the snap.yaml, am I misremembering that?
[17:48] <sergiusens> mvo: that's for "base: core"
[17:49] <sergiusens> base: none is an internally generated empty squashfs handled by snapd
[17:49] <sergiusens> more useful for types base, snapd, kernel and gadget
[17:49] <sergiusens> mvo: my post is short, skim through it :-)
[17:53] <mvo> sergiusens: sorry, I was just reading to the last backscroll item, didn't see the other lines, I have the blog post now
[17:53] <sergiusens> mvo: we had two discussions in parallel, one for use of base for other snap types and its implication and the other was how to get around core16 not being ready (which we agreed to support by allowing `base: core` in snapcraft.yaml and stripping it out from snap.yaml)
[17:54] <sergiusens> mvo: cjwatson https://bugs.launchpad.net/launchpad/+bug/1819196
[17:54] <mup> Bug #1819196: support for base: none and build-base <Launchpad itself:New> <Snapcraft:Triaged> <snapd:Triaged> <https://launchpad.net/bugs/1819196>
[17:54] <cjwatson> ta
[17:54] <mvo> sergiusens: thanks, I ponder over base: none, hopefully not too much work on our side
[17:55] <diddledan> error: cannot validate snap "mycroft": layout "/opt/mycroft" uses invalid bind mount source "$SNAP_USER_COMMON/mycroft-core": reference to unknown variable "$SNAP_USER_COMMON"
[17:55] <diddledan> aww
[17:55] <diddledan> no fair :-p
[17:55] <sergiusens> mvo: what i think was agreed to be a lot of work is supporting base for kernel and gadget
[17:56] <sergiusens> base: none for a snap type of app shouldn't be that much work (just logic to generate an empty snap on the fly instead of downloading it from the store)
[17:57] <sergiusens> anyways, lp and snapcraft need to wait for base: one to become a thing before we can do any work on that specific item
[17:58] <sergiusens> for "base: core" in snapcraft.yaml I can work on now and IIRC from conversations, base: core is mapped in launchpad already
[17:58] <sergiusens> ant that requires no work on snapd
[17:59] <cjwatson> LP doesn't *have* to wait, but it may be wise to in case the definition changes
[17:59] <cjwatson> base: core is dispatched to xenial base images and snapcraft from apt, yes
[17:59] <cjwatson> same as no base
[17:59] <sergiusens> cjwatson: right, it is the reason snapcraft waits too 🙂
[18:01] <sergiusens> cjwatson: hmm, base: core needs to be dispatched to the snap though. I will look into where I slipped up in communication there as "base: core" is not even allowed today.
[18:01] <cjwatson> err let me check what we actually did
[18:02] <cjwatson> OK, indeed, base: core is dispatched to apt
[18:03] <cjwatson> I mean, mainly by coincidence since we just needed a name for the default
[18:04] <cjwatson> I'm at EOD but send me email or whatever with what the situation is actually supposed to be and I'll fix up the DB on Monday
[18:04] <sergiusens> cjwatson: yeah, and I misread your statement. I will log a bug, thanks
[18:05] <cjwatson> if "base: core" were dispatched to the snap then there'd be no difference between it and core16 from LP's point of view
[18:05] <cjwatson> perhaps that's how it should be, I dunno
[18:06] <sergiusens> cjwatson: yes, that is the proposal to get around the lack of a core16 coming anytime soon
[18:06] <sergiusens> and it is all confusing as core is a base when at the same time, it is not
[18:06] <sergiusens> I'll work it out in the bug, just EOD in peace
[18:10] <cjwatson> will do :)
[18:58] <mup> PR snapcraft#2494 closed: sources: handle network request errors <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2494>
[19:04] <mup> PR snapcraft#2492 closed: store: handle invalid snap file errors <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2492>
[19:16] <mup> PR snapcraft#2482 closed: docs: update pull request template <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2482>
[19:19] <mup> PR snapcraft#1720 closed: kernel plugin: introduce kernel-channel to select from which channel … <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1720>