[00:27] <mup> PR snapcraft#2081 closed: elf: patch everything instead of a subset of elf files <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2081>
[01:04] <mup> PR snapcraft#2083 opened: python plugin: properly handle distutils on bionic <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2083>
[01:37] <mup> PR snapcraft#1990 closed: tests: build and install snapcraft on osx <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1990>
[01:37] <mup> PR snapcraft#2084 opened: Osx travis <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2084>
[01:44] <sergiusens> jdstrand, zyga:  fyi that corebird issue I mentioned, the profile seems to be vanishing from '/var/lib/snapd/apparmor/profiles/' on every other boot
[02:10] <Son_Goku> [11:39:43 AM]  <pstolowski>	Son_Goku: hey Neal! quick question, do you know if %{gofindfilter} macro is a new addition? I'm having failures trying to use it
[02:10] <Son_Goku> pstolowski, it probably is
[02:11] <Son_Goku> I haven't done any go packaging since new guidelines went out
[02:11] <Son_Goku> but as zyga said, mock is your friend
[02:11] <Son_Goku> you can also enter the mock environment by doing "mock --shell"
[02:28] <mup> PR snapcraft#2082 closed: Ignore me, throwing to CI <do-not-merge-yet> <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2082>
[03:16] <eraserpencil> Hey guys, I do snaps prevent access to source codes?
[03:19] <mup> PR snapcraft#2085 opened: elf: clear the current runpath before setting the rpath <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2085>
[03:19] <eraserpencil> I have a project I'd like to deploy and test out but I'm afraid the the source code would be copied. Does making it a snap helps protect the source code?
[05:07] <mborzecki> morning
[05:53] <zyga> good morning
[05:53] <zyga> eraserpencil: hey, just don't put your source code into the snap then
[05:53] <mborzeck1> zyga: hey
[05:53] <zyga> eraserpencil: snaps don't have any copy protection
[05:54]  * zyga is worried by this:
 jdstrand, zyga:  fyi that corebird issue I mentioned, the profile seems to be vanishing from '/var/lib/snapd/apparmor/profiles/' on every other boot
[06:12] <zyga> hmm
[06:12] <zyga> why is bionic spread broken?
[06:13] <mvo> zyga: I think there was a kernel update, if it is still broken after a retry we need to investigate
[06:14] <mvo> zyga: and goooood morning
[06:14] <zyga> good morning!
[06:14] <zyga> I merged master a few times, still broken
[06:14] <zyga> mvo: maybe we need to use a more recent snapshot
[06:14] <mvo> zyga: aha, yes, that sounds very reasonable
[06:16] <mup> PR snapd#5065 opened: spread.yaml: move bionic image forward <Created by mvo5> <https://github.com/snapcore/snapd/pull/5065>
[06:16] <mvo> zyga: lets see if -^ helps
[06:17] <zyga> oh cool
[06:17] <zyga> I just made the same :D
[06:17] <mvo> autsch
[06:17] <mvo> ok
[06:17] <zyga> haha, no worries :)
[06:27] <zyga> hmm, have you guys seen https://zulipchat.com/
[06:28] <zyga> it's fully FOSS
[06:35] <zyga> mvo: Sergio<snapcraft> reported that some apparmor profiles disappear randomly on boto
[06:35] <zyga> *boot
[06:35] <zyga> but very frequently
[06:39] <mborzecki> -buildmode=pie does not work in go anymore
[06:39] <zyga> what? was it removed?
[06:40] <mborzecki> just doesn't work, left some comments here https://github.com/snapcore/snapd/pull/5064#issuecomment-382098028
[06:40] <mup> PR #5064: tests: smaller fixes for Arch tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
[06:40] <zyga> uh
[06:41] <zyga> mvo ^
[06:42] <mvo> zyga: hm, hm, disappear. just apparmor or also seccomp?
[06:43] <zyga> mvo: I don't know yet, trying to reproduce it
[06:43] <mvo> zyga: ta
[06:44] <mborzecki> wonder what fedora does
[06:49] <mborzecki> hm maybe it just doesn't work, non-cgo and pie
[07:02] <pstolowski> good morning
[07:05]  * zyga -> dog
[07:06] <zyga> mvo: travis hasn't ran your PR yet
[07:06] <zyga> the one from early morning
[07:07] <mvo> ok
[07:22] <zyga> Actually taking the dog out now
[07:36] <kalikiana> o/
[07:46] <jamespage> elopio: around? working on vault bits and pieces and wondered if you had time to bring me up to speed on how you are managing the vault snap
[07:49] <zyga> jamespage: hey, just FYI, elopio left Canonical
[07:49] <jamespage> zyga: yeah I know ;)
[07:58] <jamespage> zyga: call my request a retrospective handover...
[08:08] <zyga> mvo: still nothing, is travis broken today?
[08:08] <mvo> zyga: not sure, let me check
[08:08] <mvo> zyga: anything on the vanishing profiles?
[08:08] <zyga> mvo: I tried to reproduce it but no luck
[08:08] <zyga> mvo: I used xenial
[08:09] <zyga> mvo: maybe it is somehow related to the specific kernel sergio is using
[08:09] <zyga> mvo: I will try to sync with him today
[08:09] <zyga> (sergio is not using the stock kernel, he's on a surface enablement kernel)
[08:09] <mvo> zyga: aha, and he is using xenial as well?
[08:10] <mvo> zyga: travis status page says its up
[08:10] <mvo> zyga: but I also see nothing building
[08:10] <zyga> yeah :/
[08:14] <zyga> mvo: it just started :)
[08:20] <mborzecki> uhh go build, -extldflags & shell quoting is a mess
[08:21] <zyga> mborzecki: yeah
[08:21] <zyga> I failed to make snap-exec static on suse
[08:21] <zyga> because of rpm macros and the need to quote a space
[08:21] <zyga> it just failed all the way :/
[08:22] <zyga> and the ldflags to pass static
[08:22] <mborzecki> anyways, -buildmode=pie & CGO_ENABLED does not work, fedora uses proper go build -buildmode=pie -ldflags="-extldflags '-static'" and it work, did the same for arch
[08:22] <mborzecki> zyga: i did go build -buildmode=pie -ldflags=-extldflags=-static ;) appears to work
[08:28] <mwhudson> at some point i gave up and wrote a wrapper and pointed -ldflags=-extld= at it
[08:29] <zyga> mborzecki: oh, smart
[08:29] <zyga> I'll try that
[08:29] <mborzecki> mwhudson: yeah, it's super confusing
[08:30] <mborzecki> zyga: afaik it will work if you define a macro in the spec, take a look at fedora spec
[08:30] <mborzecki> zyga: i mean, you won't have to resort to such ugly tricks
[08:35] <Chipaca> moin moin
[08:35] <Chipaca> very spotty network for me today
[08:40] <Chipaca> anything on fire today?
[08:41] <mvo> Chipaca: zyga had one alarming message but otherwise it seems to be ok
[08:41] <Chipaca> mvo: was the alarming message "wake up"?
[08:41] <zyga> Chipaca: sergio<snapcraft> reported that some apparmor profiles go away on reboot randomly
[08:41] <zyga> but I could not reproduce this
[08:41] <zyga> and I don't know more
[08:43] <joc> anyone else using the vscode snap on bionic and seen it stop working since rev 32?
[08:43] <zyga> joc: I can try
[08:43] <joc> (`snap revert` FTW)
[08:43] <Chipaca> zyga: wait is it sergio<snapcraft>, or is it snapcraft<sergio>
[08:44] <zyga> Chipaca: aren't teplate specializations commutative ;-)
[08:44] <Chipaca> zyga: that would be really tidy of them
[08:44] <zyga> Chipaca: both of them ;-)
[08:44]  * zyga is in a silly mood
[08:45] <zyga> pulling vscode in a park at 2.5MB/s
[08:45] <Chipaca> that's not silly, that's bragging
[08:45] <zyga> hey
[08:45] <zyga> just two blocks from my home
[08:45] <mborzecki> broadband :)
[08:46] <zyga> vscode snap (r32) broken on ubuntu 18.04 https://www.irccloud.com/pastebin/EiQuCMnT/
[08:46] <itsfemme[m]> Are you on your home wifi in the park?
[08:46] <zyga> itsfemme[m]: no, on LTE
[08:46] <zyga> joc: confirmed
[08:46] <zyga> popey: ^ FYI, vscode is missing some things and doesn't work on bionic
[08:46] <joc> zyga: ack, thanks
[08:46] <zyga> joc: try sublime-text
[08:46] <zyga> it works :)
[08:47] <Chipaca> so... I've got two +1's on #5027 and it's green, and master's open, so I'm going to go ahead and merge it
[08:47]  * Chipaca is full of trepidation
[08:47] <mup> PR #5027: you won't believe how client gets initial support for snapshots <Created by chipaca> <https://github.com/snapcore/snapd/pull/5027>
[08:47] <joc> heh, i've reverted and all is good
[08:47] <zyga> Chipaca: go go go
[08:47] <zyga> Chipaca: LOL
[08:47] <zyga> with that commit message
[08:47] <zyga> mvo: remember to edit the changelog on that :D
[08:47] <Chipaca> joc: FWIW reverting blacklists the revision, but if they push a new one you'll get it (which is what you want imho)
[08:48] <joc> Chipaca: yep, happy with that
[08:49] <popey> zyga: what release?
[08:49] <zyga> popey: revision 32 of vscode
[08:49] <zyga> popey: on bionic
[08:49] <zyga> popey: joc said previous revision worked ok
[08:49] <popey> works here
[08:49] <zyga> popey: on bionic?
[08:50] <popey> yes
[08:50] <zyga> popey: r32?
[08:50] <popey> oh, 32?
[08:50] <zyga> yes :)
[08:50] <popey> you should update :)
[08:50] <zyga> it used to work, now broke
[08:50] <zyga> what? :D
[08:50] <popey> test 33
[08:50] <popey> does that work?
[08:50] <zyga> I literally just installed it now
[08:50] <popey> sorry, i think it didnt get promoted, 33 works I think
[08:50] <zyga> checking
[08:50] <itsfemme[m]> I'm looking at their snapcraft.yaml and it seems they are moving to gtk3 for debs and rpms but did not add it to the snap
[08:50] <zyga> Chipaca: I found a bug :D
[08:51] <Chipaca> zyga: impossible
[08:51] <Chipaca> zyga: where?
[08:51] <mup> PR snapd#5027 closed: you won't believe how client gets initial support for snapshots <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5027>
[08:52] <zyga> you won't believe what I just found Chipaca https://www.irccloud.com/pastebin/86utZoMt/
[08:52] <Chipaca> zyga: whaa?
[08:52] <zyga> Chipaca: ouch, it's a symlink to a brkoen try mode snap
[08:52] <zyga> I mean
[08:53] <zyga> I did snap try on something I kept in ~
[08:53] <zyga> then I moved it to Documents
[08:53] <zyga> and snap refresh broke
[08:53] <Chipaca> zyga: ok yes that's a bug, but not a new one -- file it?
[08:53] <zyga> sure
[08:56] <zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1764977
[08:56] <mup> Bug #1764977: Removing backing directory of try mode snap breaks refresh of other snaps <snapd:New> <https://launchpad.net/bugs/1764977>
[08:56] <zyga> Chipaca: it's worse, I cannot snap list
[08:56] <zyga> snap remove
[08:56] <zyga> that's not even broken now
[08:56] <zyga> is that a follow-up of the change pedronis landed
[08:56] <zyga> mvo: ^ this may warrant a .6 ://
[08:56] <zyga> essentially I cannot refresh core now
[08:57] <mvo> zyga: it breaks refreshing everything? if one snap is in broken state?
[08:57] <zyga> yes
[08:57] <pedronis> it shouldn't
[08:57] <zyga> it does
[08:57] <zyga> try it
[08:57] <zyga> (literally)
[08:58] <popey> "No thank you" :D
[08:58] <pedronis> we have a bigger bug then
[08:58] <zyga> mvo: snap list, refresh et all are all failing
[08:58] <mborzecki> > that escalated quickly
[08:58] <zyga> popey: so I believe you
[08:58] <zyga> joc: can you please refresh vscode to edge
[08:58] <zyga> and see if that fixes it
[08:58] <pedronis> we didn't change snap list
[08:58] <pedronis> afaiu
[08:58] <joc> i can...
[08:58] <zyga> and communicate with popey wrt promiton of r33 to stable
[08:59] <zyga> pedronis: well :)
[08:59] <Chipaca> zyga: I doubt this is a new thing
[08:59] <zyga> kwi 18 10:59:22 t470 snapd[2069]: 2018/04/18 10:59:22.512843 snapmgr.go:228: cannot read snap info of snap "classic-snap-analyzer" at revision x4: stat /var/lib/snapd/snaps/classic-snap-analyzer_x4.snap: no such file or directory
[08:59] <pedronis> let's put it this way, we tried very carefully not to change snap list
[08:59] <pedronis> so I'm a bit confused
[08:59] <popey> joc: zyga 33 is now in stable
[08:59] <zyga> pedronis: can you just try it, "snap try" one of the test snaps, move it aside and see
[09:00] <joc> popey: same error:
[09:00] <mvo> I wonder if we have an integration test for snaps in broken state
[09:00] <popey> joc: can you paste the error somewherre?
[09:00] <joc> ```/snap/vscode/33/usr/share/code/bin/../code: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory```
[09:00] <zyga> mvo: I bet we don't
[09:00] <zyga> popey: you probably have that library installed on your host
[09:00] <popey> gah
[09:00] <zyga> popey: I wrote an analyzer for classic snaps
[09:00] <zyga> that shows missing libs
[09:00] <mup> PR snapd#5066 opened: overlord/snapshotstate/backend: introducing the snapshot backend <Created by chipaca> <https://github.com/snapcore/snapd/pull/5066>
[09:00] <zyga> _ironically_ it is the snap I moved to another directory
[09:01] <zyga> that broke everything for me now
[09:01] <popey> joc: we're on it. thanks
[09:01] <Chipaca> zyga: if you move it back, does it unbreak
[09:01] <zyga> trying
[09:01] <zyga> yes
[09:01] <itsfemme[m]> That lib is in the snapcraft.yaml though, I just checked
[09:01] <zyga> it unbreaks everything
[09:01] <zyga> itsfemme[m]: it's not loaded from there though
[09:02] <zyga> popey: http://paste.ubuntu.com/p/4sb3wxqNHD/
[09:02] <zyga> try this and see where it loads the libs from
[09:02] <Chipaca> zyga: please add that to the bug report just in case it happens to people before we can fix it
[09:02] <Chipaca> i'd do it myself but my network is already struggling
[09:03] <zyga> Chipaca: I just updated the bug report
[09:03] <zyga> I also bumped it to critical
[09:03] <zyga> it's interesting because people who have broken snaps will stay on 2.32.5
[09:04] <zyga> until we fix it with classic package
[09:04] <zyga> which is a bit unfortunatel
[09:04] <zyga> *unfortunate
[09:04] <zyga> I'll drop what I was doing and add a spread test onw
[09:04] <Chipaca> zyga: broken in general, or broken in this particular way
[09:05] <zyga> snaps that are broken
[09:05] <zyga> any old try mode snap that is removed qualifies
[09:05] <zyga> but unfortunately any unmounted snap :/
[09:09] <pedronis> mmh
[09:09] <mvo> zyga: I wonder if you could check if going to a tag like 2.32 and running snapd from there shows that its also broken or not
[09:10] <zyga> mvo: sure
[09:10] <pedronis> I have the impression is not new to .5
[09:10] <zyga> I can just snap refresh to older rev
[09:10] <zyga> it's easier
[09:10] <zyga> mvo: stable is at 2.32.3 still
[09:10] <zyga> trying...
[09:11]  * zyga hums while LTE does its magic
[09:11] <zyga> 100GB of traffic for my laptop as a free add-on to my low cost phone plan
[09:11] <zyga> I really missed that in spain
[09:11] <zyga> spain has LTE and all but man, not at this quantity
[09:11] <mborzecki> zyga: pushed the fix to https://github.com/snapcore/snapd/pull/5064
[09:11] <mup> PR #5064: tests: smaller fixes for Arch tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
[09:12] <mborzecki> what reminds me, we should fix the install path of snapd-generator
[09:12] <zyga> pedronis, mvo: confirmed, the bug is also present on 2.32.3
[09:13] <pedronis> ok, that makes more sense
[09:13] <zyga> can someone confirm https://bugs.launchpad.net/snapd/+bug/1764977
[09:13] <mup> Bug #1764977: Removing backing directory of try mode snap breaks refresh, listing (at least 2.32.3, till 2.32.5) <snapd:New> <https://launchpad.net/bugs/1764977>
[09:13] <mvo> zyga: :( so we need a) integration test b) fix
[09:13] <zyga> mvo: I'm doing (a) now
[09:13] <mvo> zyga: \o/
[09:13] <zyga> I can do (b) after
[09:13] <mvo> cool
[09:13] <zyga> mvo: is that a .6 then?
[09:14] <pedronis> we are doing stat of snaps in some place, but not ignoring errors as we should
[09:14] <mvo> zyga: probably, depends a bit on the diff
[09:14] <mvo> zyga: but I think it does make sense
[09:15] <pedronis> yea, confirmed it's in 2.32.3 as well
[09:15] <pedronis> it's nor related to the new api stuff or the doMountSnap changes
[09:15] <pedronis> it's something older
[09:16] <pedronis> ah, I think I know
[09:17] <pedronis> maybe
[09:17] <zyga> we have "try-snap-goes-away" test
[09:17] <zyga> I wonder how it didn't catch this!
[09:17] <pedronis> mvo: zyga: my suspecte is the InstalledDate code
[09:17] <zyga> oh
[09:18] <zyga> neat, that's probably it
[09:18] <pedronis> it's ignoring the case where the snap is set to Broken
[09:18] <pedronis> because it's doing an independent Lstat
[09:18]  * Chipaca whistles innocently
[09:19] <pedronis> mmg
[09:19] <pedronis> no
[09:19] <mup> PR snapd#5063 closed: tests: run interfaces-broadcom-asic-control early <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5063>
[09:19] <pedronis> it doesn'r eturn error
[09:22] <mup> PR snapd#5067 opened: tests: add a regression test for https://bugs.launchpad.net/snapd/+bu… <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[09:22] <zyga> I added this test, let's see what happens with it
[09:23] <mvo> zyga: interessting, it looks very similar to the existing test
[09:23]  * mvo is confused why the existing one does not work, it does not look broken on first glance at least
[09:23] <zyga> mvo: yes, I don't know why that test didn't catch it
[09:24] <pedronis> mmh
[09:25] <pedronis> it's the MountFile
[09:25] <pedronis> not the MountDir
[09:25] <pedronis> it's the code to find the size ?
[09:26] <pedronis> mmh
[09:27] <pedronis> shouldn't
[09:27]  * zyga tries to find what it might be
[09:28] <pedronis> ah
[09:28] <zyga> found it?
[09:28] <pedronis> zyga: if you notice the problem is not that the mount goes
[09:28] <pedronis> away
[09:28] <pedronis> the mount is there
[09:28] <pedronis> if you move the dir
[09:28] <zyga> indeed!
[09:28] <zyga> it's still mounted
[09:28] <pedronis> but the symlink because dangling
[09:28] <zyga> yes
[09:28] <pedronis> so we don't fail where we think we should
[09:28] <zyga> that's it
[09:29] <pedronis> so it's the size computation
[09:29] <pedronis> it's not really broken
[09:29] <pedronis> except it is a bit
[09:30] <pedronis> it was added in 74be4020e
[09:31] <pedronis> it's a very old bug at least
[09:31] <pedronis> it's not a regression
[09:32] <zyga> what is calling .Size()?
[09:32] <pedronis> ?
[09:33] <zyga> I mean, what's where's the bug, I see that Size() returns an error if we cannot stat the file
[09:33] <zyga> but where is that used in practice
[09:34] <zyga> grepping for '.Size()' shows nothing weird
[09:34] <pedronis> my  understanding (unproven) is that we fail here:  https://github.com/snapcore/snapd/blob/master/snap/info.go#L801
[09:34] <pedronis> because of the dangling symlink
[09:34] <zyga> is it ReadInfoFromSnapFile
[09:34] <pedronis> no
[09:35] <pedronis> it's ReadInfo
[09:35] <zyga> ah
[09:35] <pedronis> we don't retunr NotFoundError because the mount is there
[09:35] <zyga> yeah, I see
[09:35] <zyga> do you want to fix it?
[09:35] <zyga> or shall I
[09:35] <pedronis> I actually not sure how to fix it
[09:36] <pedronis> maybe Chipaca has an opionin, is not super clear that that value make even sense when .snap is a symlink to a dir
[09:37] <zyga> something like htis
[09:37] <zyga> http://paste.ubuntu.com/p/C5pHxBYrpM/
[09:37] <zyga> yeah, the size if bogus in that case
[09:37] <zyga> I just don't want it to break
[09:37] <zyga> it should really walk the snap to calculate
[09:37] <zyga> but that's a separate thing to fix
[09:38] <mvo> fwiw, I am in a debug shell in try-snap-goes-away and snap list is fine and shows it in "broken" state
[09:38] <zyga> (I swapped a condition there in the paste but fixed onw)
[09:38] <zyga> mvo: magic?!
[09:38] <zyga> why
[09:38] <pedronis> mvo: it means the mount is gone away
[09:39] <pedronis> in the bug case it doesn't
[09:39] <pedronis> well, not the mount
[09:39] <pedronis> the snap.yaml
[09:39] <pedronis> mvo: I think there's a difference between rm   the content of the try snap, vs moving it away
[09:39] <mvo> yeah, that would explain it
[09:40] <mvo> there must be a difference :)
[09:40] <pedronis> I mean, I understand there's a difference
[09:40] <pedronis> mvo:  if the try is moved
[09:40] <pedronis> the mount is still there
[09:40] <pedronis> with a snap.yaml
[09:40] <pedronis> so we fail later in ReadInfo
[09:40] <pedronis> if you remove the snap.yaml
[09:40] <pedronis> then you get the broken state
[09:41] <pedronis> we really need two different tests
[09:41] <zyga> I pushed a small patch to my PR
[09:41] <zyga> https://github.com/snapcore/snapd/pull/5067/files check if it makes sense to you please Chipaca
[09:41] <mup> PR #5067: tests: add a regression test for https://bugs.launchpad.net/snapd/+bu… <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[09:42] <zyga> mvo: did you restart https://travis-ci.org/snapcore/snapd/builds/367998252?utm_source=github_status&utm_medium=notification ?
[09:42] <zyga> did it fail?
[09:42] <pedronis> anyway I'm not sure it means we need a .6
[09:42] <pedronis> it's been there since a while
[09:42] <mvo> zyga: I didn't touch this one
[09:42] <zyga> pedronis: I agree
[09:42] <zyga> we can do it later
[09:42] <pedronis> it's not super typical case
[09:42] <zyga> unless mvo disagrees
[09:42] <zyga> but I think it's ok
[09:42] <zyga> though
[09:42] <zyga> I'd like to see a deb with this
[09:43] <mvo> pedronis: aha, this makes sense, yes
[09:43] <zyga> mvo: maybe it's still worth doing a .6
[09:43] <zyga> if it is "free" still
[09:43] <mvo> pedronis, zyga I think we should pull the fix in
[09:43] <zyga> as in, people get this deb
[09:43] <mvo> but not necessarily release it
[09:43] <zyga> not SRU wait
[09:43] <mvo> just now and in a rush
[09:43] <zyga> aha
[09:43] <zyga> ok, I'll defer to your call then
[09:43] <zyga> man, it's getting too warm over here
[09:44]  * zyga moves to the shade
[09:44] <Chipaca> zyga: I doubt it's that path in side info that is causing this
[09:44] <Chipaca> zyga: as it's able to read the snap.yaml
[09:44] <pedronis> Chipaca: we found the problem
[09:44] <pedronis> it's the Size code in ReadInfo
[09:45] <Chipaca> pedronis: that's what i'm looking at i think
[09:45] <Chipaca> in https://github.com/snapcore/snapd/pull/5067/files
[09:45] <mup> PR #5067: tests: add a regression test for https://bugs.launchpad.net/snapd/+bu… <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[09:45] <pedronis> been there since 2016
[09:45] <Chipaca> but the snap.yaml was read ok
[09:45] <Chipaca> for it to get to the size bit
[09:45] <pedronis> yes
[09:45] <pedronis> if you move the try dir
[09:45] <pedronis> the mount is still fine (until reboot)
[09:45] <pedronis> so the snap.yaml is there
[09:45] <pedronis> but the .snap symlink is dangling
[09:46] <Chipaca> augh
[09:46] <pedronis> it's different from rm around
[09:47] <pedronis> fun
[09:48] <pedronis> anyway, it's not recent code
[09:48] <Chipaca> can we have a comment
[09:48] <pedronis> where? who?
[09:49] <Chipaca> I think I'm lagged to heck
[09:52] <Chipaca> zyga: with that change, do snaps in this state actually appear as 'broken' in snap list?
[09:52] <zyga> No
[09:53] <Chipaca> zyga: should they? :-)
[09:53] <Chipaca> zyga: either that, or the comment on the task.yaml needs fixing
[09:53] <Chipaca> zyga: actually the whole test won't work?
[09:54] <zyga> I didnt try yet
[09:56] <zyga> I think they should
[09:56] <zyga> Yes
[09:56] <zyga> But they won’t just yet
[09:58] <Chipaca> zyga: I suspect returning NotFoundError instead of ignoring the not found will dwww
[09:58] <Chipaca> but i haven't tested :-)
[09:58] <zyga> Yeah, I think so too
[10:03] <zyga> I force pushed this behavior now
[10:08] <zyga> let's see what spread says
[10:09] <mup> PR snapd#5065 closed: spread.yaml: move bionic image forward <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5065>
[10:11] <zyga> mvo: let's hope master is going to be good now
[10:14] <zyga> Chipaca: updated: https://github.com/snapcore/snapd/pull/5067
[10:14] <mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[10:15]  * Chipaca  looks
[10:15]  * Chipaca still lagged
[10:16] <Chipaca> * Ping reply from Chipaca: 41.707 second(s)
[10:17] <zyga> woah
[10:17] <zyga> your packets are going to the moon and back :)
[10:17] <Chipaca> 3G from the reception of a school in the middle of a field somewhere
[10:18] <mup> PR snapd#5068 opened: spread: bump delta reference to 2.32.5 <Created by zyga> <https://github.com/snapcore/snapd/pull/5068>
[10:19] <zyga> how are you testing that?
[10:21] <Chipaca> zyga: testing what?
[10:21] <zyga> the ping
[10:22] <mvo> zyga: thanks for the merge
[10:29] <Chipaca> zyga: /ping Chipaca
[10:30] <zyga> can you ping me?
[10:30] <zyga> my client doesn't report the time
[10:31] <Chipaca> * Ping reply from zyga: 0.490 second(s)
[10:31] <zyga> thanks
[10:33] <Chipaca> zyga: it's very variable today though :-)
[10:33] <Chipaca> the bar that tells me about ping goes all over the place
[10:34] <zyga> perhaps you are close to several towers and are constantly doing handover between them
[10:35] <Chipaca> perhaps the uk 3g network is made entirely of spit and wattle
[10:35] <Chipaca> and not that much wattle either
[10:36] <zyga> haha
[10:36] <zyga> perhaps :)
[10:36] <zyga> come visit me some day
[10:39] <mborzecki> 3G? isn't that like umts/hsdpa thing?
[10:40] <Chipaca> https://opensignal.com/networks?z=15&minLat=51.4545&maxLat=51.4705&minLng=-0.2734&maxLng=-0.2287&s=all&t=2-3 <- i'm at the red splotch in the middle of that
[10:40] <ogra_> Chipaca, if its so much spit your data should slide through the network fast :)
[10:42] <Chipaca> zyga: #1764998
[10:42] <mup> Bug #1764998: profiles making a run for it <amd64> <apport-bug> <bionic> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1764998>
[10:48] <zyga> Sure, just after lunch
[11:23] <Chipaca> mborzecki: thanks for the review! i'll work on it in a bit
[11:23] <mborzecki> Chipaca: np
[11:29] <jamespage> would someone be able to check who has permissions on the vault charm in the snapstore?
[11:30] <pstolowski> Son_Goku: hey! I've re-created my spec to follow the new go guidelines, it builds locally but fails on copr on %gometa tag; I've BuildRequires: go-srpm-macros in the spec, do you know what else might be missing?
[11:42] <zyga> I’m heading home
[11:48] <pstolowski> Son_Goku: hey! I've re-created my spec to follow the new go guidelines, it builds locally but fails on copr on %gometa tag; I've BuildRequires: go-srpm-macros in the spec, do you know what else might be missing?
[11:48] <Son_Goku> %gocratfmeta
[11:48] <Son_Goku> err
[11:48] <Son_Goku> %gocraftmeta
[11:48] <Son_Goku> https://github.com/gofed/go-macros/commit/b8474abd963b4992e8aadd6efbde09833980e985#diff-455385f5d8493917cb83541909b7cfa9
[11:50] <pstolowski> Son_Goku: ahh, thanks, let me check
[11:54] <pstolowski> Son_Goku: Unknown tag: %gocraftmeta (copr, rawhide)
[11:54] <Son_Goku> blech
[11:54] <Son_Goku> someone has goofed
[11:56] <Son_Goku> pstolowski, are you in #fedora-devel?
[11:57] <pstolowski> Son_Goku: i'm now
[11:57] <Son_Goku> pstolowski, you might want to ask for help there
[11:57] <Son_Goku> because I'm a bit lost myself :(
[11:57]  * Son_Goku notes that he's been very wary to change how snapd is packaged because go is already hard
[11:58] <pstolowski> https://www.irccloud.com/pastebin/vEuTRpRH/
[11:59] <pstolowski> Son_Goku: it there any BuildRequire that I could be missing? I've this ^ atm
[12:02] <Son_Goku> let me check
[12:02] <sergiusens> BjornT_: can I bother you with a review? https://github.com/snapcore/snapcraft/pull/2083
[12:02] <mup> PR snapcraft#2083: python plugin: properly handle distutils on bionic <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2083>
[12:05] <Son_Goku> pstolowski, so here's the macros that are available:
[12:05] <Son_Goku> * Rawhide: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/master/f/macros.go-srpm
[12:05] <Son_Goku> * F28: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/f28/f/macros.go-srpm
[12:06] <Son_Goku> * F27: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/f27/f/macros.go-srpm
[12:06] <Son_Goku> * F26: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/f26/f/macros.go-srpm
[12:06] <Son_Goku> pstolowski, just revert back to the old style and mention in the ticket that you need to support F26 for the moment
[12:07] <mborzecki> off to pick up the kids
[12:07] <Son_Goku> the new style seems to be in a weird state right now and it's not supported at all in F26
[12:14] <pstolowski> Son_Goku: doh, i see.. i hope i still have the old file around ;)
[12:14] <Son_Goku> if you don't, you can get it from COPR dist git
[12:14] <BjornT_> sergiusens: sure
[12:14] <Son_Goku> pstolowski: https://copr-be.cloud.fedoraproject.org/results/pstolowski/go-udev/fedora-27-x86_64/00741447-golang-github-pilebones-go-udev/golang-github-pilebones-go-udev.spec
[12:15] <Son_Goku> old version is still there ;)
[12:15] <Son_Goku> just download that and use it again
[12:15] <zyga> and I’m back
[12:18] <pstolowski> Son_Goku: right :)
[12:18] <pstolowski> Son_Goku: thanks for help!
[12:22] <Son_Goku> no problem
[12:22] <zyga> hey, https://github.com/snapcore/snapd/pull/5067 is green :)
[12:22] <mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[12:22] <zyga> mvo, pedronis: ^ can you please review it
[12:22] <zyga> can we land trivial https://github.com/snapcore/snapd/pull/5068
[12:22] <mup> PR #5068: spread: bump delta reference to 2.32.5 <Created by zyga> <https://github.com/snapcore/snapd/pull/5068>
[12:23] <zyga> jamesh: hey
[12:23] <zyga> jamesh: I saw some updates on the user mounts branch
[12:24] <zyga> I asked a question there
[12:24] <zyga> also FYI I'm working on somewhat the same idea from another angle (persistence and updates)
[12:24] <cachio> mvo, hey, we got the +1 to go to stable
[12:24] <zyga> I will keep de-conflicting your branch as I move along
[12:24] <zyga> I hope your branch can land soon or at least shrink to 1/10th
[12:31] <mvo> cachio: great, lets talk in the standup
[12:36] <jamesh> zyga: that was something I missed when rebasing the branch to clear out what had already been merged.  I dropped the patch with those interfaces/mount/backend.go changes
[12:37] <zyga> thanks, I'll check the rest soon
[12:37] <jamesh> zyga: I'm hopeful CI will give me a tick this time around
[12:37] <zyga> my plan is to land the locking (done), mount namespace setup (in progress) and persistence
[12:37] <zyga> and then take the privs code from your PR
[12:37] <zyga> as well as the whole run-snap-update-ns as user
[12:37] <zyga> I still have to make some update changes but it's not major I hope
[12:38] <jamesh> zyga: from what I can tell, read only bind mounts are broken in snapd master
[12:38] <zyga> oh, I will look into that!
[12:38] <jamesh> zyga: this is due to mount() ignoring all flags but MS_BIND and MS_REC for bind mounts
[12:39] <zyga> aww, that makes sense
[12:39] <zyga> man, that's not great then
[12:39] <jamesh> so MS_BIND|MS_RDONLY is equivalent to MS_BIND
[12:40] <jamesh> Secure.BindMount gets it right, but required some AppArmor changes to match
[12:41] <zyga> hmm hmm
[12:41] <zyga> what's different about the secure bind mount?
[12:41] <jamesh> that's what the most recent commit in the PR is doing
[12:42] <jamesh> it follows up with a MS_REMOUNT|MS_BIND|MS_RDONLY mount() call
[12:42] <zyga> what about MS_REC?
[12:42] <zyga> what if the initial MS_BIND|MS_REC created multiple bind mounts
[12:43] <mup> PR snapd#5068 closed: spread: bump delta reference to 2.32.5 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5068>
[12:43] <jamesh> zyga: at the moment, that errors out.  Alex had some code in flatpak/bubblewrap to parse mountinfo to find out what needed remounting.  So that would be a possibility
[12:44] <zyga> jamesh: I see, I think I need to look into that
[12:44] <popeycore> :( 3rd time now I have side loaded a snap and it's completely nuked xorg on 18.04
[12:44] <zyga> I read that bubblewrap code
[12:44] <popeycore> lost my entire session immediately after a snap was installed.
[12:44] <jamesh> zyga: do we have any read only recursive bind mounts?
[12:44] <zyga> popeycore: xwayland or x
[12:44] <popeycore> i dont use wayland
[12:44] <zyga> jamesh: no but AFAIR we made all content recursive, no?
[12:45] <zyga> and we can use read only content connections
[12:45] <zyga> still, something to look into
[12:45] <zyga> popeycore: yeah, that happened to me, though I was not on X at the tiem
[12:45] <zyga> *time
[12:45] <zyga> so maybe it's more widespread
[12:45] <jamesh> there is no obvious examples in the spread tests, and I don't think you can do it with layouts
[12:45] <zyga> popeycore: did you see my pastebin for checking if classically confined snaps are made correctly?
[12:45] <popeycore> i wlil try and reproduce it
[12:45] <popeycore> yes, but it's not my snap, it's Wimpress
[12:46] <popeycore> and sergio has fixes too
[12:46] <zyga> jamesh: perhaps it's untested, I will look into that
[12:46] <jamesh> when AppArmor is used, read only content interface shares are protected
[12:46] <zyga> ah, that's good
[12:46] <zyga> at least we're not breaking something that was working (widely) before
[12:46] <Wimpress> Just returned from lunch. Will rebuild vscode now.
[12:47] <mup> PR snapd#5054 closed: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5054>
[12:47] <zyga> Wimpress: same shout about my pastebin that checks if snap is made correctly
[12:48] <zyga> I would make it a snap but I need jdstrand to ack an extension of system-observe interface
[12:49] <mup> PR snapd#5064 closed: tests: smaller fixes for Arch tests <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
[12:53] <jamesh> zyga: spread tests failed: I introduced a bug in a unit test, and the user-mounts spread test seems to be failing on debian.  I've submitted a fix for the unit test, but not sure why the user-mounts one fails in one place only
[12:54] <zyga> I'll look after the standup
[12:54] <zyga> jamesh: again, I'll try to get your branch merged
[12:54] <zyga> if you want I can take it over entirely
[12:55] <mup> Issue snapcraft#2071 closed: patchelf to handle RUNPATH <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2071>
[12:55] <mup> PR snapcraft#2085 closed: elf: clear the current runpath before setting the rpath <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2085>
[12:55] <jamesh> zyga: it's late here, so I won't check back on it til tomorrow morning.  I think it is fairly clean as is, but there is definitely room for further work
[12:55] <jamesh> maybe that could go post merge
[12:55] <zyga> thank you for all the work on this!
[12:55] <jamesh> (1) recursive read only bind mounts
[12:56] <jamesh> (2) get Secure.BindMount to handle file bind mounts
[12:56] <cachio> mvo, zyga, mborzecki could someone take a look to https://github.com/snapcore/spread-images/pull/10
[12:56] <mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
[12:56] <jamesh> (2) should be pretty easy with the new secure bind mount strategy
[12:56] <zyga> yes, the new secure bind mount is awesome :)
[12:56] <cachio> mvo, zyga mborzecki I have another one with the documentation to push today
[12:57] <zyga> cachio: sorry, I'm not sure I follow
[12:57] <mborzecki> cachio: this is for building gce images right?
[12:58] <zyga> ah
[12:58] <zyga> I see what you mean now
[12:58] <cachio> mborzecki, yes
[12:58] <mborzecki> cachio: like the whole bunch of scripts/tools
[12:58] <cachio> create images and update images
[12:58] <mborzecki> ok, got it
[12:58] <cachio> mborzecki, yes
[12:58] <cachio> I used those to create update all the images we are already using for gce
[12:58] <mvo> cachio: thanks, looking
[12:59] <zyga> cachio: that's quite a diff
[12:59] <cachio> zyga, yes
[12:59] <cachio> sorry
[12:59] <cachio> it started as a small branch to add debian
[13:00] <cachio> but then I ended up adding all the scripts there
[13:00] <zyga> cachio: is is spellcheck clean?
[13:01] <mup> PR snapcraft#2083 closed: python plugin: properly handle distutils on bionic <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2083>
[13:01] <cachio> zyga, I'll make a spellcheck run again
[13:08] <popey> Uhm
[13:09] <popey> I know "snap remove foo", will remove my data from snap/foo/current, but *why* does "snap install foo" do that?
[13:09] <popey> (I mean I don't agree with either, but install, removing my data, that's a bit mad)
[13:09] <zyga> popey: can you expand on that please
[13:09] <zyga> popey: install should not do anything
[13:09] <popey> i had a snap directory containing data for an application
[13:09] <popey> i tried running the snap, and noticed thaat i no longer have the snap installed
[13:10] <popey> so i installed it, tried running it and the config is gone
[13:10] <popey> i literally have a code editor open and it says the file disappeared
[13:11] <zyga> hmmmm
[13:11] <zyga> current is a symlink
[13:11] <zyga> where was the data exactly?
[13:12] <popey> sure, but I had a text editor open with snap/foo/current/foo.json open
[13:12] <popey> i realise current is a symlink, but I guess a symlink to an old version
[13:12] <popey> but I can't tell now because I have installed the snap so the link has been changed
[13:13] <popey> i wonder if current was a broken symlink or somehow was a directory?
[13:13] <zyga> popey: I don't know yet
[13:14] <popey> my previous full system crash appears to have crashed in the nvidia driver :(
[13:18] <zyga> interesting
[13:18] <zyga> maybe mutex thing again ^ mborzecki
[13:23] <zyga> that TLS mutex library
[13:23] <mborzecki> hmm
[13:24] <mborzecki> popey: log?
[13:24] <mborzecki> or which snap
[13:24] <popey> i was installing a local snap
[13:24] <popey> it is always a local snap
[13:25] <mborzecki> popey: local as in 'snap try'?
[13:25] <popey> as in i built it and installed with --dangerous
[13:25] <popey> lemme try installing again to see if i can reproduce
[13:26] <mborzecki> popey: hm ok, can i say, pull ohmygiraffe, snap pack and snap install --dangerous then?
[13:26] <popey> you can try :)
[13:27] <popey> i just tried to reproduce it, and it didn't crash
[13:27] <popey> https://errors.ubuntu.com/oops/a598af70-4306-11e8-9dfd-fa163e839e11
[13:27] <popey> ^ thats my crash
[13:30] <popey> https://errors.ubuntu.com/oops/eb22f554-3c0e-11e8-81fe-fa163e171d9b and https://errors.ubuntu.com/oops/8b8b9504-341d-11e8-8901-fa163ed44aae are also mine
[13:35] <mborzecki> popey: wow, that's the whole xorg crashing?
[13:35] <popey> yes, my entire desktop goes bang
[13:38] <mborzecki> not sure that's something that can be attributed to snaps
[13:38] <mborzecki> popey: i'll try to reproduce it with ohmygiraffe once we finish the standup
[13:38] <popey> kk
[14:02] <zyga> https://bugs.launchpad.net/snapd/+bug/1756317 looks nasty
[14:02] <mup> Bug #1756317: Can set garbage for core experimental.layouts <snapd:New> <https://launchpad.net/bugs/1756317>
[14:05] <pedronis> mborzecki: mvo:  we mentioned it yesterday, https://forum.snapcraft.io/t/system-options/87  should document set system
[14:06] <pedronis> mvo: we didn't discuss goint to stable, I suppose we nedeed cachio for that
[14:09] <mborzecki> pedronis: let me update that
[14:09] <pedronis> mborzecki: we need to document both  (and say 2.32.5+ for the 2nd one) for a while I suspect
[14:09] <mvo> pedronis: yeah, we need him for this, also traditionally we prefer Mon,Tue for this
[14:10] <mvo> zyga: related to the bug from greyback - pr 4600
[14:10] <mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
[14:10] <zyga> ack
[14:10] <zyga> 43 patches :)
[14:14] <zyga> mvo: it needs a review from niemeyer
[14:14] <mvo> ok
[14:16] <mup> PR snapcraft#2086 opened: tests: update metadata store integration test, no previous push required <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/2086>
[14:16] <zyga> given that .5 is in bionic, do we promote .5 to stable?
[14:17] <niemeyer> mvo, zyga: That's pretty interesting.. will need to dig in a bit to remind myself about the semantics of the changes map
[14:18] <niemeyer> I think we should eventually expose something along those lines via the API as well
[14:18] <niemeyer> Details to be figured
[14:19] <mvo> zyga: .5 is ready for stable promotion we need to decide when we want to do this. traditionally we release to stable Mon,Tue
[14:19] <mvo> (cc niemeyer -^)
[14:19] <zyga> doing it now means we can still react to the outcome
[14:19] <zyga> I think Wed is late in the meaning of "mid week" but it's not too late
[14:20] <niemeyer> mvo: The delta was just the stop-mode right?
[14:21] <mvo> niemeyer: stop-mode plus new API
[14:21] <zyga> niemeyer: https://github.com/snapcore/snapd/releases/
[14:21] <zyga> I made the release page show some details for the last few releases I worked on
[14:23] <niemeyer> zyga: Can we please not do that?
[14:23] <niemeyer> zyga: We have a roadmap page in the forum.. just point it there
[14:23] <niemeyer> zyga: Otherwise we have two different places, most likely showing different information
[14:24] <zyga> yes, it doesn't show per release details
[14:24] <zyga> the point releases we made recently I mean
[14:24] <niemeyer> zyga: it looks exactly like we want it to look
[14:24] <niemeyer> zyga: If we want to make it look different, we do
[14:25] <zyga> sure, I can make that
[14:25] <zyga> I just thought it is nice to have some information on the GitHub release pages still, I just need to make sure that is in the forum in the end
[14:26] <niemeyer> zyga: We can point that to the roadmap page.. and we can tune the roadmap page to show more information
[14:26] <niemeyer> zyga: But we don't want it t be obnoxious
[14:27] <niemeyer> zyga: What we don't want is multiple people maintaining the same kind of information in different places, with different content
[14:29] <niemeyer> zyga: Our current roadmap is also much better about providing context about features described.. we need to keep that true.. I'd also prefer to not break down every single patch release in a different section..
[14:29] <niemeyer> zyga: I suggest having a call today to talk about how we want that organized
[14:29] <zyga> niemeyer: I'm not sure I agree about not having any information on point releases
[14:29] <zyga> git log is too ra
[14:29] <zyga> *raw
[14:30] <niemeyer> zyga: That's not what I said
[14:31] <joc> sergiusens: to answer your question from yesterday, yes seems to be a new problem with 2.40
[14:31] <sergiusens> kalikiana: can you help joc out ^?
[14:31] <niemeyer> zyga: We should highlight relevant deltas, and demote trivial changes
[14:32] <niemeyer> zyga: We don't need whole sections for trivial changes
[14:32] <kalikiana> joc: sergiusens what do you need me to help with?
[14:32] <sergiusens> not me, joc
[14:33] <joc> kalikiana: I have a snap that we've been building for a while (months), but since 2.40 is failing to build with some python/pip problems
[14:35] <kalikiana> joc: Can you paste what's failing?
[14:35] <mup> PR snapd#5069 opened: configcore: validate experimental.layouts option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5069>
[14:44] <kyrofa> Chipaca, just realized a script of mine ended up calling `snap install <snap> --channel=` (i.e. no channel at all) which was happily translated to stable instead of yelling at me. Expected?
[14:45] <kyrofa> Not really a problem, just not what I expected to happen
[14:45] <kyrofa> And indeed, not what used to happen
[14:46] <mborzecki> popey: tried both install --dangerous and snap try, no issues
[14:46] <popey> Yeah, doesn't happen every time, I'm not sure what the critical way to trigger it is
[14:48] <Chipaca> kyrofa: expected
[14:48] <kyrofa> Alright
[14:49] <Chipaca> kyrofa: not sure if it's _right_, but it's expected :-)
[14:49] <kyrofa> Chipaca, heh, no big deal, just means I need to do my OWN error checking, thanks a lot
[14:49] <Chipaca> kyrofa: the other option would be to throw an error
[14:50] <Chipaca> kyrofa: but stable _is_ "" :-)
[14:50] <kyrofa> Haha
[14:50] <kyrofa> Yeah no complaint, just a change, wanted to make sure
[14:50] <Chipaca> kyrofa: it's interesting that you say it's a change
[14:51] <Chipaca> kyrofa: when did it change?
[14:51] <kyrofa> My script used to blow up
[14:51] <kyrofa> I dunno, I'm figuring the core snap updated a while back. My script used to blow up
[14:51] <kyrofa> (if I forgot to specify a channel)
[14:51] <kyrofa> Or heck, who knows, maybe it's all in my head
[14:54] <mup> PR snapd#5070 opened: debian: update LP bug for the 2.32.5 SRU <Created by mvo5> <https://github.com/snapcore/snapd/pull/5070>
[14:55] <diddledan> kyrofa: did you manage to get anywhere investigating my gimp build?
[15:02] <jdstrand> zyga: feel free to let me know when 3963 is ready for me to review (I see in backscroll there are failing tests, you may be taking over, etc)
[15:02] <zyga> thanks, I will
[15:03] <joc> popey: did vscode get dropped back to rev 29?
[15:03] <cachio> mvo, are you going to send to proposed the 32.5?
[15:04] <joc> popey: because that is still not a working revision for me, the last one i have that works is 27
[15:04] <popey> joc: yup, needs more debugging
[15:04] <popey> ugh
[15:04] <popey> Wimpress: ^
[15:04] <mvo> cachio: yes
[15:05] <mvo> cachio: I let you know once it gets accepted there
[15:05] <cachio> mvo, nice
[15:05] <Wimpress> joc: I've just release rev 27 to stable, beta, candidate
[15:06] <joc> thanks
[15:09] <diddledan> Wimpress: joc: revision 29 seems ok here :-/
[15:11] <diddledan> aah. the font rendering is a problem..
[15:11] <diddledan> only in the editor window though, the file tree is fine
[15:12] <joc> diddledan: seems likely to be a host pc specific thing - the error is a missing lib
[15:21] <pstolowski> zyga: snapcraft doesn't seem to be supporting layouts yet, does it?
[15:22] <zyga> pstolowski: I don't know
[15:22] <zyga> perhaps not
[15:22] <zyga> I usually build snaps by hand
[15:22] <pstolowski> kyrofa: do you know? ^
[15:23] <kyrofa> pstolowski, it does not, but in edge you can use the `passthrough` keyword to indicate a set of things you just want passed into the snap.yaml
[15:23] <pstolowski> zyga: yeah I could do that, but would prefer something I can easily iterate on/rebuild
[15:23] <pstolowski> kyrofa: sounds great, thanks!
[15:23] <kyrofa> pstolowski, actually beta and candidate too-- 2.41
[15:28] <sergiusens> pstolowski, zyga: yeah, please participate https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-41/5022
[15:28] <pstolowski> sergiusens: yep, i'm just in!
[15:37] <kyrofa> niemeyer, hey, thanks for merging Saviq's fix, so much better
[15:42] <niemeyer> kyrofa: np
[15:42] <niemeyer> kyrofa: Does it work now?
[15:42] <kyrofa> niemeyer, it does, wonderfully
[15:42] <kyrofa> Saves me a significant amount of time not needing to manually test on those
[15:43] <niemeyer> mvo: The release notes say the API was back in .4 .. is that not out yet?
[15:43] <kyrofa> Now if only squashfuse was in trusty so I could do that too...
[15:43] <niemeyer> kyrofa: Hmm.. we have snapfuse inside core I think
[15:44] <kyrofa> niemeyer, I can't install snaps in a trusty lxd instance, should I be able to?
[15:44] <kyrofa> (core itself can't install)
[15:46] <niemeyer> kyrofa: I don't know if we have other constraints, but the point of having snapfuse was precisely to make containers work
[15:50] <zyga> kyrofa: trusty guest on which host?
[15:50] <kyrofa> zyga, xenial
[15:50] <zyga> kyrofa: what's the error you see?
[15:51] <kyrofa> mounting issues, it's been a while since I tried, let me fire one up
[15:59] <mup> PR snapcraft#2087 opened: Add configuration for AppVeyor <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2087>
[16:06] <mvo> niemeyer: .4 is not out in stable yet
[16:08] <mvo> niemeyer: I mean .5 is in bionic so .4 is there by implication. but its not available in a stable core snap or in a stable distro release yet, we can release that today (the stable core with .5 is ready) or Monday, its our call (plus we need to get an ack from the store)
[16:10] <niemeyer> mvo: ok, got it thanks.. let's have that call shortly and we can also use a bit of time to discuss our options there
[16:10] <mvo> ok
[16:12]  * kalikiana heading out for the day
[16:14] <kyrofa> zyga, huh, nowadays it's "error: cannot communicate with server: Post http://localhost/v2/snaps/core: dial unix /run/snapd.socket: connect: no such file or directory"
[16:14] <kyrofa> Seems snapd isn't running
[16:14] <zyga> what's the status of the snapd.service?
[16:15] <kyrofa> Yikes, systemctl doesn't work either, dbus is busted
[16:15] <kyrofa> Looks like installing snapd borked things, it pulled in a kernel even though it's a container, wonder if that has something to do with it
[16:18] <Chipaca> kyrofa: wrt channels (now that i got around to looking), last relevant change seems to be 2016-09
[16:19] <kyrofa> Chipaca, I shall plead insanity, then!
[16:19] <Chipaca> kyrofa: you could also shout and posture and claim that I must be wrong
[16:20] <kyrofa> :P
[16:23] <mvo> kyrofa: hm, I think we have or had a kernel dependency on trusty
[16:24] <Chipaca> kyrofa: snapd inside a trusty lxd?
[16:24] <kyrofa> Chipaca, yep, on xenial host
[16:25] <Chipaca> kyrofa: I _think_ that isn't meant to work, but I'm not 100%
[16:25] <Caelum> zyga: I'm posting on the factory list now, that list is actually alive
[16:25] <kyrofa> mvo, yeah, looks like that's the case
[16:25] <Chipaca> stgraber: could you remind me if that's expected to work?
[16:25] <zyga> Caelum: thank you, please keep me posted on the developments :)
[16:25] <Chipaca> stgraber: 1604 running lxd, a 1404 container in that lxd, running snapd
[16:26] <stgraber> Chipaca: not supposed to as 14.04 containers don't have apparmor running
[16:26] <mvo> kyrofa: its a recommends nowdays but still will get pulled in by default. still, that should not kill your dbus :/
[16:26] <Chipaca> stgraber: thanks
[16:26] <Chipaca> kyrofa: neener neener
[16:26] <kyrofa> Chipaca, I'm tired of you telling me no today
[16:26]  * Chipaca is extremely professional in all his interactions
[16:26] <kyrofa> :P
[16:27] <kyrofa> Thanks for clarifying Chipaca, mvo, stgraber
[16:27] <Chipaca> kyrofa: hey, don't blame me. Blame .... Elves on strike. (Why do they call EMAG Elf Magic)
[16:28]  * Chipaca puts away the bofh excuse generator for another year
[16:31]  * zyga takes a break and goes for a walk
[16:32] <mup> PR snapcraft#2055 closed: python: bring back support for older versions of pip <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2055>
[16:33] <niemeyer> mvo: Ready when you are
[16:51] <niemeyer> mvo: Hmm.. nm.. I guess your EOD is now at my 1PM local time..
[17:09] <Chipaca> oh look at that, it's beer o'clock, and it's lovely outside
[17:13] <pstolowski> zyga: layouts do not let me bind a subdir under /usr/lib - I get cannot update snap namespace: cannot create writable mimic over "/usr/lib": permission denied; is that by design?
[17:13] <zyga> No
[17:13]  * genii checks his Beer O'Clock alarm, but it's it's stilll a seemingly forever 3 hours and 47 minutes away yet
[17:13] <pstolowski> zyga: ok; so i'm trying to do this: /usr/lib/tcltk/x86_64-linux-gnu/tk8.5:
[17:13] <pstolowski>       bind: $SNAP/usr/lib/tcltk/x86_64-linux-gnu/tk8.5
[17:14] <zyga> What is the denial
[17:14] <zyga> I’m on a bike now
[17:15] <pstolowski> zyga: [68891.838823] audit: type=1400 audit(1524071502.757:492): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.scid" name="/tmp/.snap/usr/lib/" pid=15755 comm="3" srcname="/usr/lib/" flags="rw, rbind"
[17:15] <pstolowski> zyga: ha, enjoy it then, let's talk tomorrow!
[17:15] <pstolowski> i'm about to eod anyway
[17:17] <zyga> What is the yaml again
[17:18] <zyga> The source name looks bad
[17:18] <zyga> Backwards
[17:26] <mvo> niemeyer: sorry, real life commitments, but if you have a free slot in 1h I shall be able to attend
[17:27] <niemeyer> mvo: I certainly do, but don't want to run into your evening.. I didn't realize we had shifted time so much already that my early afternoon is already off-hours for you
[17:31] <mvo> niemeyer: no worries, a quick syncup is fine
[17:31] <mvo> niemeyer: I ping you in ~1h, ok?
[17:31] <niemeyer> mvo: Deal
[17:31] <mvo> :)
[17:34] <pstolowski|eod> zyga: https://pastebin.ubuntu.com/p/VgpRx43PVJ/
[18:09] <mup> PR snapd#5071 opened: tests: replace snap try when possible to speedup tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5071>
[18:41] <mvo> niemeyer: I'm in the hangout channel now
[18:43] <niemeyer> mvo: OMW!
[18:57] <pbek> is there a way to contribute to https://docs.snapcraft.io/build-snaps/syntax? the most valuable parameter "version-script" is missing.
[18:59] <mup> PR snapcraft#2003 closed: patches: make the ctypes patch more robust and add armhf arch triplet <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2003>
[19:05] <popey> pbek: https://github.com/canonical-docs/snappy-docs/blob/master/build-snaps/syntax.md
[19:05] <popey> pbek: that's the repo with those docs in.
[19:31] <sergiusens> pbek: there's a link at the bottom
[21:15] <mup> PR snapcraft#2088 opened: grammar: support compound on..to statement <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2088>
[22:09] <mup> PR snapcraft#2089 opened: many: remove support for remote lxd per project containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2089>