[00:27] PR snapcraft#2081 closed: elf: patch everything instead of a subset of elf files [01:04] PR snapcraft#2083 opened: python plugin: properly handle distutils on bionic [01:37] PR snapcraft#1990 closed: tests: build and install snapcraft on osx [01:37] PR snapcraft#2084 opened: Osx travis [01:44] 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] [11:39:43 AM] 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] pstolowski, it probably is [02:11] I haven't done any go packaging since new guidelines went out [02:11] but as zyga said, mock is your friend [02:11] you can also enter the mock environment by doing "mock --shell" [02:28] PR snapcraft#2082 closed: Ignore me, throwing to CI [03:16] Hey guys, I do snaps prevent access to source codes? [03:19] PR snapcraft#2085 opened: elf: clear the current runpath before setting the rpath [03:19] 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? === chihchun_afk is now known as chihchun === pbek_ is now known as pbek [05:07] morning [05:53] good morning [05:53] eraserpencil: hey, just don't put your source code into the snap then [05:53] zyga: hey [05:53] eraserpencil: snaps don't have any copy protection [05:54] * zyga is worried by this: [05:54] jdstrand, zyga: fyi that corebird issue I mentioned, the profile seems to be vanishing from '/var/lib/snapd/apparmor/profiles/' on every other boot === mborzeck1 is now known as mborzecki [06:12] hmm [06:12] why is bionic spread broken? [06:13] zyga: I think there was a kernel update, if it is still broken after a retry we need to investigate [06:14] zyga: and goooood morning [06:14] good morning! [06:14] I merged master a few times, still broken [06:14] mvo: maybe we need to use a more recent snapshot [06:14] zyga: aha, yes, that sounds very reasonable [06:16] PR snapd#5065 opened: spread.yaml: move bionic image forward [06:16] zyga: lets see if -^ helps [06:17] oh cool [06:17] I just made the same :D [06:17] autsch [06:17] ok [06:17] haha, no worries :) [06:27] hmm, have you guys seen https://zulipchat.com/ [06:28] it's fully FOSS [06:35] mvo: Sergio reported that some apparmor profiles disappear randomly on boto [06:35] *boot [06:35] but very frequently [06:39] -buildmode=pie does not work in go anymore [06:39] what? was it removed? [06:40] just doesn't work, left some comments here https://github.com/snapcore/snapd/pull/5064#issuecomment-382098028 [06:40] PR #5064: tests: smaller fixes for Arch tests [06:40] uh [06:41] mvo ^ [06:42] zyga: hm, hm, disappear. just apparmor or also seccomp? [06:43] mvo: I don't know yet, trying to reproduce it [06:43] zyga: ta [06:44] wonder what fedora does [06:49] hm maybe it just doesn't work, non-cgo and pie [07:02] good morning [07:05] * zyga -> dog [07:06] mvo: travis hasn't ran your PR yet [07:06] the one from early morning [07:07] ok [07:22] Actually taking the dog out now [07:36] o/ [07:46] 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] jamespage: hey, just FYI, elopio left Canonical [07:49] zyga: yeah I know ;) === chihchun is now known as chihchun_afk [07:58] zyga: call my request a retrospective handover... === chihchun_afk is now known as chihchun [08:08] mvo: still nothing, is travis broken today? [08:08] zyga: not sure, let me check [08:08] zyga: anything on the vanishing profiles? [08:08] mvo: I tried to reproduce it but no luck [08:08] mvo: I used xenial [08:09] mvo: maybe it is somehow related to the specific kernel sergio is using [08:09] mvo: I will try to sync with him today [08:09] (sergio is not using the stock kernel, he's on a surface enablement kernel) [08:09] zyga: aha, and he is using xenial as well? [08:10] zyga: travis status page says its up [08:10] zyga: but I also see nothing building [08:10] yeah :/ [08:14] mvo: it just started :) [08:20] uhh go build, -extldflags & shell quoting is a mess [08:21] mborzecki: yeah [08:21] I failed to make snap-exec static on suse [08:21] because of rpm macros and the need to quote a space [08:21] it just failed all the way :/ [08:22] and the ldflags to pass static [08:22] 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] zyga: i did go build -buildmode=pie -ldflags=-extldflags=-static ;) appears to work [08:28] at some point i gave up and wrote a wrapper and pointed -ldflags=-extld= at it [08:29] mborzecki: oh, smart [08:29] I'll try that [08:29] mwhudson: yeah, it's super confusing [08:30] zyga: afaik it will work if you define a macro in the spec, take a look at fedora spec [08:30] zyga: i mean, you won't have to resort to such ugly tricks [08:35] moin moin [08:35] very spotty network for me today [08:40] anything on fire today? [08:41] Chipaca: zyga had one alarming message but otherwise it seems to be ok [08:41] mvo: was the alarming message "wake up"? [08:41] Chipaca: sergio reported that some apparmor profiles go away on reboot randomly [08:41] but I could not reproduce this [08:41] and I don't know more [08:43] anyone else using the vscode snap on bionic and seen it stop working since rev 32? [08:43] joc: I can try [08:43] (`snap revert` FTW) [08:43] zyga: wait is it sergio, or is it snapcraft [08:44] Chipaca: aren't teplate specializations commutative ;-) [08:44] zyga: that would be really tidy of them [08:44] Chipaca: both of them ;-) [08:44] * zyga is in a silly mood [08:45] pulling vscode in a park at 2.5MB/s [08:45] that's not silly, that's bragging [08:45] hey [08:45] just two blocks from my home [08:45] broadband :) [08:46] vscode snap (r32) broken on ubuntu 18.04 https://www.irccloud.com/pastebin/EiQuCMnT/ [08:46] Are you on your home wifi in the park? [08:46] itsfemme[m]: no, on LTE [08:46] joc: confirmed [08:46] popey: ^ FYI, vscode is missing some things and doesn't work on bionic [08:46] zyga: ack, thanks [08:46] joc: try sublime-text [08:46] it works :) [08:47] 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] PR #5027: you won't believe how client gets initial support for snapshots [08:47] heh, i've reverted and all is good [08:47] Chipaca: go go go [08:47] Chipaca: LOL [08:47] with that commit message [08:47] mvo: remember to edit the changelog on that :D [08:47] 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] Chipaca: yep, happy with that [08:49] zyga: what release? [08:49] popey: revision 32 of vscode [08:49] popey: on bionic [08:49] popey: joc said previous revision worked ok [08:49] works here [08:49] popey: on bionic? [08:50] yes [08:50] popey: r32? [08:50] oh, 32? [08:50] yes :) [08:50] you should update :) [08:50] it used to work, now broke [08:50] what? :D [08:50] test 33 [08:50] does that work? [08:50] I literally just installed it now [08:50] sorry, i think it didnt get promoted, 33 works I think [08:50] checking [08:50] 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] Chipaca: I found a bug :D [08:51] zyga: impossible [08:51] zyga: where? [08:51] PR snapd#5027 closed: you won't believe how client gets initial support for snapshots [08:52] you won't believe what I just found Chipaca https://www.irccloud.com/pastebin/86utZoMt/ [08:52] zyga: whaa? [08:52] Chipaca: ouch, it's a symlink to a brkoen try mode snap [08:52] I mean [08:53] I did snap try on something I kept in ~ [08:53] then I moved it to Documents [08:53] and snap refresh broke [08:53] zyga: ok yes that's a bug, but not a new one -- file it? [08:53] sure [08:56] Chipaca: https://bugs.launchpad.net/snapd/+bug/1764977 [08:56] Bug #1764977: Removing backing directory of try mode snap breaks refresh of other snaps [08:56] Chipaca: it's worse, I cannot snap list [08:56] snap remove [08:56] that's not even broken now [08:56] is that a follow-up of the change pedronis landed [08:56] mvo: ^ this may warrant a .6 :// [08:56] essentially I cannot refresh core now [08:57] zyga: it breaks refreshing everything? if one snap is in broken state? [08:57] yes [08:57] it shouldn't [08:57] it does [08:57] try it [08:57] (literally) [08:58] "No thank you" :D [08:58] we have a bigger bug then [08:58] mvo: snap list, refresh et all are all failing [08:58] > that escalated quickly [08:58] popey: so I believe you [08:58] joc: can you please refresh vscode to edge [08:58] and see if that fixes it [08:58] we didn't change snap list [08:58] afaiu [08:58] i can... [08:58] and communicate with popey wrt promiton of r33 to stable [08:59] pedronis: well :) [08:59] zyga: I doubt this is a new thing [08:59] 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] let's put it this way, we tried very carefully not to change snap list [08:59] so I'm a bit confused [08:59] joc: zyga 33 is now in stable [08:59] pedronis: can you just try it, "snap try" one of the test snaps, move it aside and see [09:00] popey: same error: [09:00] I wonder if we have an integration test for snaps in broken state [09:00] joc: can you paste the error somewherre? [09:00] ```/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] mvo: I bet we don't [09:00] popey: you probably have that library installed on your host [09:00] gah [09:00] popey: I wrote an analyzer for classic snaps [09:00] that shows missing libs [09:00] PR snapd#5066 opened: overlord/snapshotstate/backend: introducing the snapshot backend [09:00] _ironically_ it is the snap I moved to another directory [09:01] that broke everything for me now [09:01] joc: we're on it. thanks [09:01] zyga: if you move it back, does it unbreak [09:01] trying [09:01] yes [09:01] That lib is in the snapcraft.yaml though, I just checked [09:01] it unbreaks everything [09:01] itsfemme[m]: it's not loaded from there though [09:02] popey: http://paste.ubuntu.com/p/4sb3wxqNHD/ [09:02] try this and see where it loads the libs from [09:02] zyga: please add that to the bug report just in case it happens to people before we can fix it [09:02] i'd do it myself but my network is already struggling [09:03] Chipaca: I just updated the bug report [09:03] I also bumped it to critical [09:03] it's interesting because people who have broken snaps will stay on 2.32.5 [09:04] until we fix it with classic package [09:04] which is a bit unfortunatel [09:04] *unfortunate [09:04] I'll drop what I was doing and add a spread test onw [09:04] zyga: broken in general, or broken in this particular way [09:05] snaps that are broken [09:05] any old try mode snap that is removed qualifies [09:05] but unfortunately any unmounted snap :/ [09:09] mmh [09:09] 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] mvo: sure [09:10] I have the impression is not new to .5 [09:10] I can just snap refresh to older rev [09:10] it's easier [09:10] mvo: stable is at 2.32.3 still [09:10] trying... [09:11] * zyga hums while LTE does its magic [09:11] 100GB of traffic for my laptop as a free add-on to my low cost phone plan [09:11] I really missed that in spain [09:11] spain has LTE and all but man, not at this quantity [09:11] zyga: pushed the fix to https://github.com/snapcore/snapd/pull/5064 [09:11] PR #5064: tests: smaller fixes for Arch tests [09:12] what reminds me, we should fix the install path of snapd-generator [09:12] pedronis, mvo: confirmed, the bug is also present on 2.32.3 [09:13] ok, that makes more sense [09:13] can someone confirm https://bugs.launchpad.net/snapd/+bug/1764977 [09:13] Bug #1764977: Removing backing directory of try mode snap breaks refresh, listing (at least 2.32.3, till 2.32.5) [09:13] zyga: :( so we need a) integration test b) fix [09:13] mvo: I'm doing (a) now [09:13] zyga: \o/ [09:13] I can do (b) after [09:13] cool [09:13] mvo: is that a .6 then? [09:14] we are doing stat of snaps in some place, but not ignoring errors as we should [09:14] zyga: probably, depends a bit on the diff [09:14] zyga: but I think it does make sense [09:15] yea, confirmed it's in 2.32.3 as well [09:15] it's nor related to the new api stuff or the doMountSnap changes [09:15] it's something older [09:16] ah, I think I know [09:17] maybe [09:17] we have "try-snap-goes-away" test [09:17] I wonder how it didn't catch this! [09:17] mvo: zyga: my suspecte is the InstalledDate code [09:17] oh [09:18] neat, that's probably it [09:18] it's ignoring the case where the snap is set to Broken [09:18] because it's doing an independent Lstat [09:18] * Chipaca whistles innocently [09:19] mmg [09:19] no [09:19] PR snapd#5063 closed: tests: run interfaces-broadcom-asic-control early [09:19] it doesn'r eturn error [09:22] PR snapd#5067 opened: tests: add a regression test for https://bugs.launchpad.net/snapd/+bu… [09:22] I added this test, let's see what happens with it [09:23] 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] mvo: yes, I don't know why that test didn't catch it [09:24] mmh [09:25] it's the MountFile [09:25] not the MountDir [09:25] it's the code to find the size ? [09:26] mmh [09:27] shouldn't [09:27] * zyga tries to find what it might be [09:28] ah [09:28] found it? [09:28] zyga: if you notice the problem is not that the mount goes [09:28] away [09:28] the mount is there [09:28] if you move the dir [09:28] indeed! [09:28] it's still mounted [09:28] but the symlink because dangling [09:28] yes [09:28] so we don't fail where we think we should [09:28] that's it [09:29] so it's the size computation [09:29] it's not really broken [09:29] except it is a bit [09:30] it was added in 74be4020e [09:31] it's a very old bug at least [09:31] it's not a regression [09:32] what is calling .Size()? [09:32] ? [09:33] I mean, what's where's the bug, I see that Size() returns an error if we cannot stat the file [09:33] but where is that used in practice [09:34] grepping for '.Size()' shows nothing weird [09:34] my understanding (unproven) is that we fail here: https://github.com/snapcore/snapd/blob/master/snap/info.go#L801 [09:34] because of the dangling symlink [09:34] is it ReadInfoFromSnapFile [09:34] no [09:35] it's ReadInfo [09:35] ah [09:35] we don't retunr NotFoundError because the mount is there [09:35] yeah, I see [09:35] do you want to fix it? [09:35] or shall I [09:35] I actually not sure how to fix it [09:36] 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] something like htis [09:37] http://paste.ubuntu.com/p/C5pHxBYrpM/ [09:37] yeah, the size if bogus in that case [09:37] I just don't want it to break [09:37] it should really walk the snap to calculate [09:37] but that's a separate thing to fix [09:38] 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] (I swapped a condition there in the paste but fixed onw) [09:38] mvo: magic?! [09:38] why [09:38] mvo: it means the mount is gone away [09:39] in the bug case it doesn't [09:39] well, not the mount [09:39] the snap.yaml [09:39] mvo: I think there's a difference between rm the content of the try snap, vs moving it away [09:39] yeah, that would explain it [09:40] there must be a difference :) [09:40] I mean, I understand there's a difference [09:40] mvo: if the try is moved [09:40] the mount is still there [09:40] with a snap.yaml [09:40] so we fail later in ReadInfo [09:40] if you remove the snap.yaml [09:40] then you get the broken state [09:41] we really need two different tests [09:41] I pushed a small patch to my PR [09:41] https://github.com/snapcore/snapd/pull/5067/files check if it makes sense to you please Chipaca [09:41] PR #5067: tests: add a regression test for https://bugs.launchpad.net/snapd/+bu… [09:42] mvo: did you restart https://travis-ci.org/snapcore/snapd/builds/367998252?utm_source=github_status&utm_medium=notification ? [09:42] did it fail? [09:42] anyway I'm not sure it means we need a .6 [09:42] it's been there since a while [09:42] zyga: I didn't touch this one [09:42] pedronis: I agree [09:42] we can do it later [09:42] it's not super typical case [09:42] unless mvo disagrees [09:42] but I think it's ok [09:42] though [09:42] I'd like to see a deb with this [09:43] pedronis: aha, this makes sense, yes [09:43]