[01:09] <mwhudson> hey i broke snapcraft https://launchpadlibrarian.net/396538792/buildlog_snap_ubuntu_xenial_ppc64el_go-tip_BUILDING.txt.gz
[01:20] <mup> PR snapd#6121 opened: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6121>
[01:49] <mup> Issue core18#89 opened: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>
[06:14] <mborzecki> morning
[06:19] <mborzecki> brb
[06:43] <zyga> Good morning
[06:43] <zyga> mwhudson: hello
[06:43] <mborzecki> zyga: hey
[06:44] <zyga> Quick question sir: what is the Debin policy for golang builds. That is, what more is needed in top of vanilla go build to do what packaging macros do
[06:45] <mwhudson> zyga: i don't understand the question
[06:45] <mwhudson> zyga: but basically you have a bunch of golang-*-dev packages for your build depends
[06:46] <zyga> For example: in openSUSE to be compliant you need to pass -buildmode=pie to “go build”
[06:47] <zyga> Is there something like that in Debian?
[06:59] <mwhudson> ah
[06:59] <mwhudson> no
[06:59] <mwhudson> you can, you can override dh_auto_build to run dh_auto_build -- -buildmode=pie or whatever
[07:00] <mwhudson> (if you particularly hate i386 users...)
[07:00] <mwhudson> zyga: you should probably join #debian-golang on oftc
[07:01] <zyga>  I should, yes
[07:01] <zyga> I have a deeper interest but I’m tired and wanted to have a slow morning today
[07:02] <zyga> So still AFK
[07:14] <zyga> Good morning mvo
[07:23] <mborzecki> mvo: hey
[07:34] <mvo> hey zyga and mborzecki
[07:34] <mvo> zyga: 6118 contains the fix for snap-confine we dicussed yesterday
[07:40] <zyga> Hey
[08:07] <pstolowski> morning
[08:10] <mvo> good morning pstolowski
[08:12] <zyga> mvo: I’m still afk, doing a slow start today
[08:12] <zyga> Sorry about that
[08:14] <mvo> zyga: now worries, still waiting for travis in any case
[08:17] <pstolowski> trivial https://github.com/snapcore/snapd/pull/6117 needs 2nd review
[08:17] <mup> PR #6117: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6117>
[08:22] <ackk> mvo, hi, I run in another issue yesterday with core18 only installed: https://github.com/snapcore/core18/issues/89
[08:23] <mvo> ackk: thanks, looking
[08:27] <mup> PR snapd#6120 closed: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6120>
[08:29] <mborzecki> #6065 needs a 2nd review
[08:29] <mup> PR #6065: cmd: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
[08:35] <mvo> mborzecki: I have a look, sorry this was on my list but slipped
[08:35] <mborzecki> pedronis: hi, did you happen to git push to the wrong remote by accident? origin/pedronis-localInstallCleanup-doc
[08:36] <mup> PR snapd#6117 closed: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6117>
[08:50] <mvo> mborzecki: I'm looking at 6039 and the error tweak there right now - or is that something you are already doing?
[08:52] <mborzecki> mvo: yeah, just started
[08:52] <mborzecki> mvo: do you want to look into this or shuld i?
[09:00] <mvo> mborzecki: its fine, just go ahead, I will do more reviews then
[09:06] <mup> PR snapd#6065 closed: cmd: make coreSupportsReExec faster <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6065>
[09:07] <mvo> pedronis: is 6070 something you want to look at (at a high level) or can I just go ahead and merge?
[09:17] <mvo> zyga: do you know the status of 5696?
[09:21] <thresh> is snap store dead again?
[09:21] <mborzecki> mvo: it needs a 2nd review
[09:21] <thresh> The Snap Store encountered an error while processing your request: internal server error (code 500).
[09:23] <pedronis> mborzecki: hi,  do we have spread tests about refreshing parallel installed snaps through the store?
[09:23] <mup> PR snapd#6119 closed: sanity, release, cmd/snap: refuse to try to do things on WSL <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6119>
[09:23] <pedronis> mborzecki: no,  I used direct editing in github, I will remove the branch now that is merged
[09:25] <mborzecki> pedronis: no, i don't think we have any, we have tests for install but not for refresh, i can look into adding one
[09:25] <pedronis> mborzecki: yes, I think we should have some
[09:25] <pedronis> thank you
[09:26] <pedronis> mvo: can you give me a bit more context about 6070 ?
[09:26] <pedronis> and hi
[09:26] <mvo> pedronis: sure, let me update this
[09:27] <mvo> pedronis: context in the PR description I assume?
[09:29] <pedronis> mvo: what's the coverage like of those function in store?
[09:30] <mvo> pedronis: the coverage change with this PR you mean? I checked that the bits that get mocked are also tested inside store but let me run the percentages
[09:41] <zyga> mvo: good for merge AFAIK
[10:02] <pstolowski> pedronis: could this land https://github.com/snapcore/snapd/pull/6072 ? got 2 reviews and is probably uncontroversial as it's touching  the udevmon bits
[10:02] <mup> PR #6072: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6072>
[10:05] <pedronis> pstolowski: yes, seems fine in itself
[10:06] <pstolowski> thanks
[10:08] <mborzecki> mvo: pedronis: i've updated 6039 with new error kind
[10:09] <mborzecki> zyga: can you take a look at #5696 and +1 it if it looks ok for you?
[10:09] <mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
[10:09] <pedronis> mborzecki: would try to get a review from John first
[10:10] <mborzecki> pedronis: ok
[10:10] <pedronis> I requested one there
[10:10] <pedronis> I will look after him
[10:11] <pedronis> zyga: are you blocked by 6116, or can you go forward and just deal with tweaks down the line?
[10:12] <pedronis> anyway I see there are comments there
[10:17] <mvo> pedronis: I updated 6070 with pointers to the tests and a bit more motivation, I hope this is what you asked for, if I misread, please let me know
[10:19] <zyga> pedronis: I can move forward
[10:19] <pedronis> zyga: thx
[10:19] <pedronis> mvo: ah, you added a test as well
[10:20] <thresh> is there any way to use JVM inside a snap, without providing the JVM itself?  Like a plug, maybe?
[10:20] <mvo> pedronis: yeah, one was missing actually, not a super critical one but it was missing :)
[10:21] <thresh> I don't really want to ship JVM as a part of VLC snap, but in case of Blu-Ray discs (which have Java-based menus) it can be useful
[10:22] <mvo> zyga: 6118 is ready for review, tests are green except a curl 51 error on opensuse :/
[10:22] <pedronis> thresh: theoretically there should be a way to have a content snaps for this, like we do for gnome library, the question is how to coordinate/mantain this, maybe something to discuss with advocacy/snapcrafters
[10:23] <pedronis> thresh: sounds a fine forum discussion
[10:24] <zyga> Uh
[10:24] <pedronis> zyga: ?
[10:25] <pedronis> mvo: btw have we broken the coverage reports, I don't see them in recent green PRs
[10:25] <pedronis> ?
[10:26] <mup> PR snapd#6122 opened: Tests core18 base configure 2.36 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6122>
[10:26] <zyga> I mean the 51 error on suse
[10:26] <zyga> archive woes
[10:26] <mvo> pedronis: yeah, I haven't seen them either, let me look
[10:26]  * zyga works on some reviews now
[10:27] <zyga> sorry for starting late and everyone
[10:31] <mvo> pedronis: I can't install codecov for snapcore/snapd - only an admin can do this, so looks like we need to ask Gustavo
[10:32] <pedronis> mvo: why do we need to install it? did github change something so that we need to install it again?
[10:32] <mvo> pedronis: I don't know, I don't see it in the installed services or the installed github apps anymore
[10:32] <pedronis> I see
[10:32] <mvo> pedronis: I don't know why it went away :/ I will dig a bit more but not sure I have enough prems to do much
[10:33] <pedronis> mvo: no, that's fine
[10:33] <pedronis> sounds like we need niemeyer
[10:33] <pedronis> and as we know a general question about getting more people with the perms
[10:33] <pedronis> your and/or me
[10:36] <mvo> pedronis: yeah
[10:38]  * pedronis dives back into reviews
[10:44] <kyrofa> cjwatson, I want to thank you for your email, and let you know that we're at the snapcraft summit this week with very little brain space for anything else, but will get back to you next week if that's alright
[10:47] <tomwardill> kyrofa: colin is off today
[10:49] <kyrofa> tomwardill, well then, that works out
[10:57] <mvo> a review for https://github.com/snapcore/core18/pull/83 would be great
[10:57] <mup> PR core18#83: add swapfile support (ported from ubuntu-core-config) <Created by mvo5> <https://github.com/snapcore/core18/pull/83>
[11:00] <mup> PR core18#84 closed: hooks: port classic mode generation to UC18 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/84>
[11:00] <mvo> and https://github.com/snapcore/core18/pull/88 :)
[11:00] <mup> PR core18#88: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <https://github.com/snapcore/core18/pull/88>
[11:01] <zyga> mvo: do you need https://github.com/snapcore/snapd/pull/6118 squashed?
[11:01] <mup> PR #6118: tests: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6118>
[11:01] <mborzecki> #5897 should be ready for landing once jdstrand approves it
[11:01] <mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
[11:01] <mup> PR snapd#6118 closed: tests: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6118>
[11:10] <zyga> mvo: I'd like to squash merge and add https://github.com/snapcore/snapd/pull/5696 to 2.36.1, what do you think?
[11:10] <mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
[11:10] <Chipaca> mvo: I only get grey reviews in core18
[11:12] <mvo> Chipaca: thanks
[11:12] <mvo> Chipaca: I think we need to talk to foundations why this is
[11:15] <mup> PR snapd#5696 closed: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>
[11:16] <mvo> Chipaca: thanks for the reviews! while you are here,  any idea about https://github.com/snapcore/core18/issues/89
[11:16] <mborzecki> zyga: 5696 squash merged as requested ;)
[11:16] <zyga> thanky you! :)
[11:17] <Chipaca> mvo: I'll take a look
[11:17] <mup> PR snapcraft#2400 closed: tests: fix maven spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2400>
[11:20] <mup> PR snapcraft#2401 closed: ci: reduce spread system declarations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2401>
[11:23] <Chipaca> mvo: yes a few
[11:23] <Chipaca> mvo: ideas i mean
[11:24] <Chipaca> mvo: core18 doesn't have the completer bits. I presume they're in the snapd snap
[11:25] <Chipaca> mvo: but core18 also does not have bash completion itself
[11:25] <mvo> Chipaca: oh, interessting - /usr/lib/snapd, right? that should be available via the host (deb package)
[11:25] <Chipaca> mvo: it's got all the completers, but not the completion
[11:25] <zyga> pstolowski: updated https://github.com/snapcore/snapd/pull/6116 :)
[11:25] <zyga> I used a slightly different function name
[11:25] <mup> PR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116>
[11:25] <mvo> Chipaca: aha! so just a misisng package in there?
[11:25] <Chipaca> mvo: perhaps
[11:25] <mvo> Chipaca: that should be easy to fix :)
[11:26] <pstolowski> zyga: thanks! will take a look in a moment
[11:26] <zyga> thank you
[11:27] <Chipaca> mvo: yes it looks like it's missing the bash-completion package
[11:27] <Chipaca> mvo: should  that be from core, or in snapd itself? dunno
[11:27] <mvo> niemeyer: when is a good time for you to chat about the dotfiles/files/sensitive-files naming? should we have a quick HO with pedronis  maybe later today about it? or early next week?
[11:28] <niemeyer> mvo: Heya
[11:28] <Chipaca> mvo: probably from core as it's used in the context of the snap-provided completer, i.e. with the base
[11:28] <niemeyer> mvo: I can do it now
[11:28] <mvo> Chipaca: making that part of core18 seems ok, no?
[11:28] <Chipaca> mvo: sitll digging to see if this would be enough though
[11:28] <Chipaca> mvo: i think so yes
[11:28] <niemeyer> Just let me grab my power cable so laptop doesn't run off in the middle
[11:29] <Chipaca> mvo: 'snap run --shell' doesn't work :-(
[11:30] <pedronis> niemeyer: mvo: I can do it if it doesn't drag too long (almost lunch), otherwise we will need a follow up
[11:30] <mvo> Chipaca: ta, let me know if you need help but hopefully the PR against core18 is trivial
[11:30] <niemeyer> pedronis: Yeah, same here
[11:31] <mvo> same here
[11:31] <mvo> I'm in the standup HO, ready when you are
[11:32] <zyga> hey niemeyer :)
[11:36] <Chipaca> mvo: 	CompleteSh = filepath.Join(SnapMountDir, "core/current/usr/lib/snapd/complete.sh")
[11:37] <Chipaca> mvo: so not just a core fix, needs a snapd change
[11:38] <mvo> Chipaca: :/ ta
[11:38] <Chipaca> !osutil.IsWritable(dirs.CompletersDir) || !osutil.FileExists(dirs.CompletersDir)
[11:38] <Chipaca> hmmm
[11:39]  * Chipaca wonders how many non-existent writable things exist out there
[11:53] <zyga> mvo: what we discussed last night https://github.com/snapcore/snapd/pull/6123
[11:53] <mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
[11:53] <mup> PR snapd#6123 opened: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
[11:53]  * zyga -> quick lunch break
[12:03] <mvo> zyga: ta, I check after lunch
[12:19] <mup> PR snapd#6124 opened: tests: simple reproducer for snap try and hooks bug <Created by stolowski> <https://github.com/snapcore/snapd/pull/6124>
[12:29] <cachio> mvo, pedronis hey, I need to go to make a study now
[12:29] <cachio> I'll try to by for the stand up
[12:29] <cachio> perhaps a bit late
[12:30]  * cachio afk
[12:40] <pedronis> zyga: on a system with snapd snap we add implicit slots to it, right?
[12:43] <pedronis> pstolowski: ensureSystemSnapIsPresent seems to have the wrong implementation now ^, also the name should probably have "is" or nothing, "ensure" sounds like it will install it if it's not there
[12:46] <pstolowski> pedronis: wrong because of CoreInfo implementation?
[12:47] <pedronis> pstolowski: yes
[12:47] <pedronis> it doesn't account for when snapd is used for that
[12:48] <pedronis> pstolowski: I suppose zyga can remind us what's the best way to get that info
[12:51] <pedronis> seems we need a bit more help from mapper
[12:51] <pedronis> actually
[12:52] <pstolowski> pedronis: we may need to revisit repo code and its guessSystemSnap(), there is some fuzzyness there
[12:52] <pedronis> maybe, not sure it's related
[12:53] <pedronis> this code I'm talking about is all in ifacestate
[12:53] <pedronis> atm
[13:00] <pedronis> pstolowski: will we rerun the interface hooks when a hotplug slot that was gone reappers?
[13:02] <pstolowski> pedronis: yes. and we will run disconnect hooks when you unplug
[13:03] <pedronis> pstolowski: should we clear the dynamic attributes of gone connections then?
[13:03] <pedronis> pstolowski: for context, I'm looking at the byHotplug case in doDisconnect
[13:04] <pstolowski> pedronis: we probably could. are you thinking about just optimization or something more?
[13:04] <pedronis> pstolowski: will we end up using them by mistake when we reconnect?
[13:05] <pedronis> that's more my question, not worried about opt
[13:08] <zyga> pedronis: I updated https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394/3 - let me know if that answers your questions
[13:08] <pstolowski> pedronis: looking at the code, in Connect we start off with empty dynamic attributes, so this should not happen
[13:08] <zyga> Unless you disagree I want to work on a fix for this issue now, that would limit re-packaging to just snap-exec, outside of 16.04 world
[13:09] <zyga> alternatively I can work on snap-confine and work with mvo on this in the evening
[13:09] <pedronis> zyga: I need to re-read the forum post first, I think you should continue on user namespaces until I understand more
[13:10] <zyga> ok
[13:10] <pedronis> pstolowski: ok, I think it would be marginally cleaner/safer to reset them but can be done in any PR, not urgent
[13:10] <zyga> pedronis: the only impact now is testing recent distributions
[13:10] <pstolowski> pedronis: allright
[13:10] <zyga> pedronis: it is not a problem in actual production use
[13:10] <zyga> (even in future distributions)
[13:10] <pedronis> zyga: yea, that's why I don't think you should jump on it
[13:10] <zyga> ok
[13:11] <zyga> mvo: 6122 approved
[13:11] <zyga> did you say 2.36.1?
[13:12] <pstolowski> pedronis: shall i look at printing a warning on snap try & hooks, or do we want to think about it some more?
[13:13] <pedronis> pstolowski: no, you should look, likely with a bit of input from zyga how to fix ensureSystemSnapIsPresent, unless you have already something else
[13:13] <pedronis> I fear adding that warning is messy
[13:16] <pstolowski> pedronis: ok
[13:17] <pedronis> pstolowski: btw, if it wasn't clear, I'm still absorbing the already landed hotplug code atm
[13:17] <pstolowski> pedronis: yes, yes, it was clear
[13:18] <pstolowski> pedronis: thanks
[13:32] <mup> PR snapd#6122 closed: tests,snap-confine: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6122>
[13:40] <zyga> heh
[13:40] <zyga> I just realised we need facts for one more reason
[13:40] <zyga> we need to know the PATH to set
[13:40] <zyga> fedora29 cannot use ubuntu PATH
[13:50] <pedronis> zyga: I re-read the forum topic, there is definitely more to clarify before it can be acted on, I can write more there and/or we can chat on it next week
[13:52] <zyga> pedronis: thank you, I think if you write some more questions or concerns we can think about them and then have a call next week
[13:52] <zyga> note, I just talked to pawel about monday
[13:53] <zyga> our government decided to make Monday a holiday just now
[13:53] <zyga> so I will (or should be) off
[13:53] <pedronis> zyga: one first question, do we run our tests mostly with reexec on all distros? even if they default to not reexec
[13:53] <zyga> it's not reexec
[13:54] <zyga> it's re-packaging of core that breaks this
[13:54] <zyga> we run with native setting of reexec
[13:54] <zyga> so enabled where it works
[13:54] <pedronis> zyga: ok, but some of your proposal don't make in the non reexec case
[13:54] <pedronis> make sense
[13:55] <zyga> there are two proposal: solution and workaround
[13:55] <pedronis> no there are many bits
[13:55] <zyga> solution is to build snapd with ubuntu 16.04 toolchain and re-package core with that build results
[13:55] <mup> PR snapd#6125 opened: release: 2.36.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6125>
[13:55] <pedronis> no, you propose to change some bind mounting too
[13:55] <zyga> the workaround is to stop repackaging with the special exception of snap-exec
[13:55] <zyga> because snap-exec is safe
[13:55] <pedronis> that doesn't make sense in general
[13:55] <zyga> indeed, sorry, that is a special case of what we do today on core18 snaps
[13:56] <zyga> we cannot use the host package as source for certain binaries
[13:56] <zyga> we must bind mount from snapd.snap
[13:56] <pedronis> if we don't reexec
[13:56] <pedronis> or depending on which binary
[13:56] <zyga> yes, even if we don't reexec
[13:56] <pedronis> it's complicatted
[13:56] <zyga> I mean when we run a core18 snap app,
[13:56] <zyga> (I agree)
[13:56] <pedronis> anyway it's not ready to be worked on
[13:56] <zyga> we _may_ in some cases use host binaries with ill effects
[13:56] <pedronis> I'll write some this in the post later
[13:56] <zyga> thank you!
[13:57] <zyga> it's super complicated because of many possible interactions
[13:57] <zyga> I think in general the solution case is easy, it would just cost test time to build snapd twice
[13:57] <zyga> and it matches reality in non-test useage
[13:57] <zyga> there are certainly some tweaks to do for core18 and fedora29 based snaps
[13:57] <zyga> but those are nearly not as broken as the repackaging today
[14:03] <mup> PR snapd#6116 closed: cmd/libsnap: add simplified feature flag checker <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6116>
[14:06] <ogra> mvo, so when you install an app on UC18 today ... it is very likely that this app pulls in core16 (simply since we only have very few UC18 core apps yet) ... once the apps switch to core 18, do we have some automation to remove the core16 snap automatically once nothing depends o it anymore ?
[14:07] <ogra> if not ... could we add that ?
[14:09] <mborzecki> mvo: can you publish the files to github release page?
[14:10] <zyga> mvo: yes please, I'll release 2.36.1 for suse too
[14:10] <mvo> mborzecki: yes, will do so in a little bit
[14:11] <mup> PR snapd#6072 closed: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6072>
[14:12] <mvo> ogra: we have no auto-cleanup of unused bases yet but its planned
[14:13] <ogra> good
[14:13] <ackk> ogra, there are also a few issues currenty if you don't have "core" installed
[14:13] <ogra> it just struck me that 3xcore16 on disk will easily eat 200-300MB
[14:13] <ogra> for devices with 4GB MMC (which we have a lot) thats quite a lot
[14:25] <zyga> ogra: we may save a lot soon
[14:26] <zyga> I'll tell you more after the standup
[14:26] <ogra> interesting
[14:38] <zyga> re
[14:38] <zyga> ogra: golang can now strip correctly
[14:38] <zyga> tl;dr
[14:38] <zyga> we can investigate
[14:39] <ogra> zyga, that doesnt help much with the core snap size i fear
[14:39] <zyga> ogra: it's way bigger because of snapd
[14:39] <zyga> anyway
[14:39] <zyga> pstolowski: let's chat in an hour or two
[14:39] <zyga> I need to get home
[14:39] <ogra> (i dont think there is a single go binary in it apart from snapd)
[14:39] <pstolowski> zyga: sounds good, i need (late) lunch
[14:40] <Chipaca> ogra: also there's a config to only keep 2x instead of 3x
[14:42] <ogra> \o/
[14:42] <ogra> that was about time !!!
[14:42] <ogra> awesome !
[14:44] <Chipaca> ogra: there since 2.34
[14:44] <Chipaca> ogra: https://github.com/snapcore/snapd/pull/5207
[14:44] <mup> PR #5207: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5207>
[14:45] <ogra> you guy need a promotion agent !!! such features deserve way more noise ... even TV ads for thi particular one ;)
[14:45] <ogra> *guy
[14:45] <ogra> *guys
[14:45] <ogra> bah
[14:45] <Chipaca> ogra: and you need a keyboard with two S keys in a hot-hot configuration
[14:46] <ogra> yeah ... i'm so sad this KBD *again* only lasted 1y ... i really like it
[14:46] <ogra> funnily usually the vowels break ... this is the firsst time i killed an S
[14:57] <Chipaca> fun fact: snap.BaseDir() is not the directory of the base of a snap
[14:58] <pstolowski> :)
[14:59]  * cachio lunch
[15:10] <jdstrand> mborzecki: hi, fyi, I approved PR 5897, but please fix the two typos before merging
[15:10] <mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
[15:10] <mborzecki> jdstrand: thanks for the review, i'll look into it in a while
[15:11] <jdstrand> mborzecki: thanks!
[15:17] <Chipaca> mvo: let me know when you have 5-10' to go over /usr/lib/snapd/* wrt bases
[15:17] <mvo> Chipaca: in a meeting right now
[15:17] <Chipaca> mvo: yea
[15:17] <Chipaca> mvo: you have all the fun, i know
[15:17] <mvo> Chipaca: we bind mount this ususally, either from the host or from the snapd snap
[15:18] <mvo> Chipaca: yeah, envy me!
[15:47] <mvo> ackk: the fix for the issue you reported about core18 onyl on classic went into 2.36 we will sru this either today or early monday
[15:51] <mvo> cachio: everything except i386 is ready for beta validation
[15:52] <ackk> mvo, \o/ thanks
[15:55] <mvo> thank *you* for reporting and the reproducer!
[15:58] <mvo> cachio: i386 is now also ready for beta validation
[15:59] <ogra> ppisati, oh my ... bug 1802320 sounds like you had a really painful time just for some blinking
[15:59] <mup> Bug #1802320: rpi3bp+: ethernet leds don't blink <patch> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1802320>
[16:01] <ppisati> ogra: yep, actually fixing the leds made the ethernet controller die
[16:01] <ppisati> ogra: but in the end it was fun
[16:01] <ogra> heh
[16:08] <kenvandine> what provides location-observe?
[16:09] <kenvandine> sudo snap connect gnome-clocks:location-observe
[16:09] <kenvandine> error: snap "core" has no "location-observe" interface slots
[16:10] <pedronis> kenvandine: afaik only the locationd snap provides that
[16:11] <pedronis> but I don't have enough context to say what that is, or what we should do instead
[16:11] <pedronis> sorry, s/what that is/why that is/
[16:12] <zyga> Finally home
[16:13] <zyga> Tea and work
[16:16] <zyga> Maybe coffee instead
[16:17] <pedronis> zyga: I wrote a bit more in that forum post, it's a bit rambly I fear, I don't think it yet capture the problem in a way that one can tell yes, this is the problem. Also I'm confused if we have related bugs outside of tests, I suppose not, but reading your comment it sounds like we do
[16:18] <pedronis> zyga: either way, not urgent to answer, do it when you feel good/rested
[16:20] <pedronis> *it's a bit rambly, it there is my own answer
[16:21] <pedronis> pstolowski: in case I finish going through the preexisting code, can you tell me where I should start the important reviews for hotplug?
[16:21] <pstolowski> pedronis: sure, let me take a look
[16:26] <kenvandine> pedronis: thanks
[16:28] <cachio> mvo, running
[16:29] <pstolowski> pedronis: i suggest the simple #6082 first; then three PRs closely related to each other: #6069, #6114, #6100
[16:29] <mup> PR #6082: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6082>
[16:29] <mup> PR #6069: ifacestate/hotplug: removeDevice helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6069>
[16:29] <mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
[16:29] <mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[16:31] <pedronis> pstolowski: thx, I'll see how far I get on monday
[16:38] <cachio> zyga, do you have the link for this python utility
[16:38] <cachio> ?
[16:40] <dot-tobias> Is launchpad currently unavailable? Estimated build time for my snaps is 5+ hours, and is still at 5h after 2h wait.
[16:41] <ogra> dot-tobias, https://launchpad.net/builders is always a good place to check
[16:45] <mup> PR snapd#6126 opened: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>
[16:45] <dot-tobias> ogra: thanks!
[16:58] <zyga> cachio: yes, one sec
[16:59] <zyga> pedronis: offtopic, https://github.com/snapcore/snapweb is pinned if you go to GitHub.com/snapcore/ perhaps we should unpin it as it's not really maintained
[17:00] <zyga> cachio: this is here https://github.com/snapcore/core-build/tree/master/initramfs/testing
[17:00] <zyga> cachio: I think it's not useful as-is for you directly
[17:00] <zyga> cachio: but it should be not too hard to extract a little bit out
[17:00] <zyga> cachio: that can drive kvm and do the snapshot / restore
[17:00] <kenvandine> mvo: i just learned there's a "bare" snap.  Would it make sense for a content snap like gtk-common-themes to use base: bare?
[17:01] <zyga> kenvandine: hey
[17:01] <kenvandine> hey zyga
[17:01] <zyga> kenvandine: content snaps don't provide apps
[17:01] <zyga> kenvandine: I don't think it needs to be using the bare base
[17:01] <kenvandine> oh, so if no app is defined it won't care?
[17:01] <zyga> precisely
[17:01] <kenvandine> great
[17:02] <zyga> bases are the roots for running stuff
[17:02] <zyga> nothing to run, nothing to care about :)
[17:02] <kenvandine> awesome
[17:03] <cachio> zyga, tx
[17:04] <Chipaca> um
[17:04] <Chipaca> well
[17:04] <Chipaca> zyga: if it doesn't say base: <something>, we'll dutifully install core for it
[17:04] <zyga> Chipaca: we should change thta
[17:05] <zyga> Chipaca: so that no apps == no base needed, no prerequisites
[17:05] <Chipaca> just confirmed, 'snap install gtk-common-themes' pulls in core
[17:06] <zyga> fun
[17:06] <zyga> I'll file a bug
[17:06] <Chipaca> kenvandine: can you think of a core18-based snap that uses gtk-common-themes?
[17:06] <Chipaca> i notice gimp doesn't
[17:06] <kenvandine> Chipaca: yes, several
[17:07] <kenvandine> evince
[17:07] <kenvandine> gnome-chess
[17:07] <kenvandine> gnome-clocks in candidate
[17:07] <Chipaca> hm
[17:07] <Chipaca> that's interesting, maybe the check is smarter now
[17:07]  * Chipaca wonders
[17:08] <kenvandine> Chipaca: i'm in the process moving all the gnome snaps to core18/gnome-3-28-1804
[17:08] <Chipaca> ah,no, there we go
[17:08] <Chipaca> it got 'core' as well
[17:08] <kenvandine> not moving the seeded snaps just yet though :)
[17:08] <Chipaca> zyga: on a bare system (no snaps at all), snap install gimp -> you get core18 and gimp; snap install evince -> you get fun
[17:08] <Chipaca> core, core18, evince, gnome-2-28-potato, gtk-common-themes
[17:10] <pedronis> zyga: Chipaca: we cannot change what no base means,  we might need a way to express no base tough
[17:11] <kenvandine> base: none ?
[17:11] <kenvandine> for gtk-common-themes
[17:12] <pedronis> that will try to find a snap called none atm
[17:12] <zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1802541
[17:12] <mup> Bug #1802541: Installing a snap without any apps or hooks should depend on the base snap <snapd:New> <https://launchpad.net/bugs/1802541>
[17:12] <zyga> pedronis: I think we could just be smart about what prerequisites to pull
[17:12] <zyga> pedronis: but we'd have to see the snap.info of a snap from the store
[17:12] <zyga> including apps/hooks
[17:13] <Chipaca> zyga: i think you a not
[17:13] <pedronis> zyga: maybe
[17:13] <Chipaca> zyga: note we aready get the raw yaml to look at content interface thinigs
[17:13] <Chipaca> things
[17:14] <zyga>  ah, I didn't know that
[17:14] <zyga> we may also need to know if hooks exist
[17:14] <zyga> even if undeclared in yaml
[17:14] <zyga> it would be nice if snapcraft created full hook defs
[17:14] <pedronis> that is a bit balooning
[17:14] <Chipaca> zyga: i edited the description to include a 'not', and changed the wording a bit
[17:14] <pedronis> anyway good that is captured in a bug
[17:15] <Chipaca> zyga: "even if undeclared in yaml", when are they declared?
[17:16] <zyga> Chipaca: when they need interfaces
[17:16] <zyga> they _can_ be declared
[17:16] <zyga> it would be neat if store knew
[17:16] <zyga> yep
[17:17] <zyga> cachio: about that python kvm thing, you can clone the repo and run it locally
[17:17] <kenvandine> zyga: thanks for the bug report, that was exactly the issue i was concerned with
[17:17] <zyga> cachio: the main idea is that you can just talk to kvm to make a super fast snapshot
[17:17] <zyga> and restore it
[17:17] <zyga> in the project I linked to it is used to drive tests
[17:17] <zyga> that run on the inside
[17:17] <zyga> the whole VM is reverted before each test
[17:18] <zyga> so it's always 100% pristine
[17:18] <zyga> since it is written for testing initramfs it is a bit specific in how it operats
[17:18] <zyga> (tests are written in python and are defined on the host, are transformed to shell and run in the initrd in the guest)
[17:18] <zyga> but that's all orthogonal to the main idea of snapshots
[17:18] <zyga> I mainly mentioned it because it is extremely fast
[17:19] <zyga> that test def setup ran >>10 tests in pristine VM per_second_ on my old laptop
[17:20] <mup> PR snapd#6125 closed: release: 2.36.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6125>
[17:21] <mvo> hm, 6039 needs a second review
[17:21] <zyga> looking
[17:21] <mvo> zyga: you reviewed it already
[17:21] <mvo> :)
[17:21] <zyga> ah :/
[17:28] <pedronis> mvo: Chipaca should look at it
[17:28] <pedronis> #6039
[17:28] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[17:31] <cachio> zyga, it is pretty nice
[17:31] <cachio> it is using the snapshot features provided by qemu
[17:32] <cachio> zyga, it also set the qemu monitor
[17:33] <cachio> and uses it to save/restore the vm
[17:33] <cachio> this it nice
[17:37] <pedronis> Chipaca: zyga: I wrote something in the bug about the challengens
[17:50] <zyga> pedronis: thanks, I replied
[17:50] <zyga> I think it's not a high priority problem
[17:50] <zyga> but we should take it into account if we change how installation works
[18:10] <mborzecki> zyga: fyi, gpg 2.2.10 is in arch too, but the test that fails in TW does not seem to fail there
[18:10] <zyga> isn't it disabled there?
[18:11] <zyga> if not then that is indeed curious
[18:11] <zyga> something else is at play
[18:11] <zyga> but that's also reassuring :)
[18:11] <mborzecki> heh, let me check
[18:11] <zyga> mborzecki: would you be interested in looking at the makefile in https://github.com/snapcore/snapd/pull/6111
[18:11] <mborzecki> zyga: it's not
[18:11] <zyga> I think it would (or might be) good fit for arch
[18:11] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[18:12] <mborzecki> (not disabled)
[18:12] <zyga> should cut the boilerplate
[18:12] <zyga> and provide consistency
[18:12] <zyga> (ack)
[18:13] <zyga> uh, 19:00 on Friday
[18:13] <zyga> sorry about that :)
[18:13] <zyga> well, I'll get back to some coding I want to finish but I don't expect reviews at this time :)"
[18:14] <mborzecki> zyga: checked pacman log, gnupg update to 2.2.10 arrived on 05.09, so it's been a while
[18:15] <mborzecki> zyga: as for the PR, i looked briefly in the morning but didn't leave any comments, imo there should a way of overriding things like -buildmode, fedora does =pie, arch doesn't care and yocto does =shared by default
[18:16] <zyga> yes
[18:16] <zyga> that's indigo
[18:16] <mborzecki> zyga: also LC_ALL=C.UTF-8 is non standard glibc extension
[18:16] <zyga> this is just temporary
[18:16] <zyga> all of the go build policy is handled by indigo
[18:16] <zyga> ish -- I think we need something like that
[18:16] <zyga> I mean
[18:16] <zyga> LC_ALL=C won't pass tests
[18:16] <zyga> we need either a real locale
[18:16] <zyga> or C.UTF-8
[18:17] <pedronis> zyga: about those gpg tests, have you tried what the test tries manually on a box, without expect etc in the way? that seems step one to understand if it's a test issue vs other
[18:17] <pedronis> I mean a box with the affected distro
[18:17] <mborzecki> zyga: or fix the culprit
[18:18] <zyga> pedronis: partially, I only ran it in a test VM as I wasn't fully familiar with what that test was doing to keys, I can run it on my machine easily though
[18:18] <zyga> (I'm developing on tumbleweed for the last few weeks
[18:18] <zyga> mborzecki: remember this was for release :)
[18:19] <zyga> mborzecki: to fix it we just need to set environment in a bunch of tests
[18:19] <pedronis> Chipaca: given that #6039 is introducing that error, maybe that fact that is not good is a blocker :)
[18:19] <mborzecki> zyga: heh, i see that now, * instead of ✓
[18:19] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[18:20] <zyga> mborzecki: yes :)
[18:20] <zyga> Chipaca: ^
[18:20] <zyga> Chipaca: tests don't mock locale so they fail if you have unset LANG and stuff
[18:20] <pedronis> Chipaca: this is 2.37 material, if you have suggestion for a better error, please suggest
[18:21] <mborzecki> Chipaca: pedronis: how about `classic confinment requested, but snap %q is not a classic confined snap` ?
[18:22] <mborzecki> the original version by mvo was `classic confinment requested for a non classic confined snap', maybe a variant of this could work
[18:23] <pedronis> mborzecki: I think Chipaca is suggesting that it's one of those longer messages, explaining a bit the concept as well
[18:23] <pedronis> I'm honestly a bit too tired right now to make a suggestion
[18:23] <pedronis> like the ones for SnapNeeds*
[18:24] <pedronis> maybe the error needs to carry the actual confinement to help produce a better error
[18:24] <pedronis> message
[18:25] <pedronis> as well
[18:25] <mup> PR core-build#37 opened: Introduce recovery-mode for factory-reset <Created by slimjim777> <https://github.com/snapcore/core-build/pull/37>
[18:27] <pedronis> mborzecki: Chipaca: I copied this convo in the PR
[18:28] <Chipaca> pedronis: mborzecki: sorry i was afk
[18:29]  * Chipaca looks at errors.go
[18:30] <Chipaca> mborzecki: pedronis: i'm very tired so not sure this suggestion is any good, but something like "snap %q is not compatible with --classic" would spell out exactly what the user did wrong
[18:30] <Chipaca> my main complaint is that it doesn't tell the user what they did wrong, and doesn't tell them how to fix it
[18:31] <Chipaca> "wtf drop that --classic nonsense" would work too
[18:31] <Chipaca> mborzecki: pedronis: let's all EOW and worry on Monday/Tuesday/whatever is the appropriate day next week
[18:31] <mborzecki> ack :)
[18:39] <zyga> 2.36.1 in opensuse now
[18:39] <zyga> mborzecki: is arch package up to date? :-) (wink wink)
[18:39] <mborzecki> hehe
[18:39] <mborzecki> nah, haven't pushed an update yet
[18:39] <zyga> I will push the snapd sync in a moment
[18:40] <zyga> or maybe not,
[18:40] <zyga> it's trivial bump of two lines
[18:40] <zyga> can wait
[18:41] <pedronis> Chipaca: it's fine, as I said it's not urgent to land afaict and I'm tired too
[18:45] <pedronis> Chipaca: I pasted that into the PR in case
[18:45]  * pedronis goes away
[18:45] <zyga> o/
[18:45] <pedronis> ttfn
[18:49] <Chipaca> o/ eow here