[00:56] <sincere_fox> Hello
[00:58] <sincere_fox> I just installed an electron app via snap and I get this error https://pastebin.com/63MfH8NH
[05:39] <mborzecki> morning
[07:04] <mborzecki> Chipaca: mvo: morning guys
[07:11] <pstolowski> morning
[07:12] <mborzecki> pstolowski: hey
[07:14] <mvo> hey pstolowski and mborzecki
[07:16] <mborzecki> have you seen https://forum.snapcraft.io/t/new-base-snap-nix-base/11787 ?
[07:17] <mvo> yeah, its very cool
[07:18] <mborzecki> on the same note, wodner if any help is needed here: https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/
[07:18] <mborzecki> would that enable a flatpak to be repacked as snap and vice versa?
[07:19] <mvo> mborzecki: I think so
[07:20] <mvo> mborzecki: or at least flat->snap it seems, not sure about the reverse but having a common base seems to be sensible
[07:21] <Chipaca> mborzecki: morning
[07:21] <mvo> pstolowski: mup is still down :( I pushed a tiny PR to not error if "current" is missing in "patch"
[07:21] <mvo> pstolowski: please have a look, maybe its too naive
[07:21] <mvo> hey Chipaca, gooood morning :)
[07:22] <Chipaca> :)
[07:23] <mborzecki> anyone up for some mkfs magic? https://github.com/snapcore/snapd/pull/6997
[07:23] <mborzecki> or i shoudl say mkfs/mtools
[07:28] <pstolowski> mvo: thanks. i've been thinking about what to do about that.. looking
[07:28] <mvo> pstolowski: again, maybe too naive but I think we don't want to fail
[07:32] <mvo> mborzecki: I like your idea about the symlink /snap to avoid the full cost of switching in the majaro case
[07:33] <mborzecki> mvo: i'm bit afraid this would break when poeple grab snapd from AUR
[07:33] <mborzecki> mvo: which they have done in the past :/
[07:33] <mvo> yeah
[07:34] <pstolowski> mvo: okay, i think it's fine, let me comment in the PR
[07:43] <mvo> pstolowski: \o/
[07:43] <mvo> pstolowski: thank you
[07:47] <pstolowski> mvo: added comments
[07:58] <mvo> pstolowski: thanks, makes perfect sense
[07:58] <mvo> mborzecki: looking at your mkfs stuff now
[07:58] <mborzecki> mvo: ta
[07:59] <mvo> mborzecki: its actually short, I like that
[07:59] <pstolowski> mvo: thanks for the change, one more remark for the test change you made
[08:00] <mvo> pstolowski: thanks, looking!
[08:00] <mvo> pstolowski: indeed, very good point
[08:00] <mvo> pstolowski: thank you!
[08:00] <pstolowski> ty!
[08:10] <mborzecki> usual issues https://www.reddit.com/r/linux/comments/c07mp1/ubuntu_devs_testing_chromium_browser_transition/ snaps are slow, themes, auto refresh etc
[08:20] <mvo> mborzecki: some ideas for your PR  looks great overall
[08:25] <mvo> gentle ping about 6691, it needs a second review
[08:35] <pstolowski> mvo: #7000, what a milestone! :)
[08:36] <mvo> pstolowski: indeed, 7k PRs its slightly crazy
[09:15] <Chipaca> mvo: does brave work for you?
[09:16] <mvo> Chipaca: it used to work
[09:16] <mvo> Chipaca: I can try again, shall I use the script from my gist?
[09:16] <mvo> Chipaca: or just deb/snap?
[09:16] <mvo> Chipaca: what release of ubuntu?
[09:17] <Chipaca> mvo: nah, just tell me if the snap's app runs
[09:17] <Chipaca> here it dies
[09:17] <Chipaca> but i'm on xenial
[09:17] <Chipaca> wondering if it's universally broken or what
[09:17] <Chipaca> (it complains about the sandbox)
[09:18] <Chipaca> wait, drat
[09:18] <Chipaca> it does work
[09:18] <Chipaca> hmm hmm
[09:18] <mvo> Chipaca: aha, ok. its still installing here :)
[09:18] <Chipaca> mvo: maybe i just needed to install it with assertions once for it to pick up the connections
[09:18] <Chipaca> :)
[09:19] <mvo> ok
[09:40] <pstolowski> grr @go-flags
[09:54] <Chipaca> pstolowski: no why?
[09:54] <Chipaca> now*
[10:16] <Chipaca> mvo: grr @ snaps that do a bunch of copying stuff around on first run :-/
[10:17] <Chipaca> on an HDD, that's nearly a whole minute waiting for the window
[10:17] <Chipaca> impressive
[10:17] <Chipaca> s/nearly/more than/
[10:17] <Chipaca> brave:none:596299776:69398:3087:2707
[10:17] <mvo> Chipaca: ohhhh, so thats the reaon?
[10:17] <mvo> Chipaca: reason?
[10:18] <mvo> Chipaca: its the copying of stuff not actually anything else?
[10:18] <Chipaca> that's SNAP:MODE:SIZE:START:START2:WALK
[10:18] <mvo> Chipaca: I'm very happy I asked you to look at this :)
[10:18] <Chipaca> is 69 seconds for first run, 3 seconds for 2nd (from an empty cache)
[10:18] <mvo> Chipaca: is that perf output?
[10:18] <Chipaca> that's my script output
[10:18] <Chipaca> one line of it
[10:18] <mvo> Chipaca: *nod*
[10:18] <Chipaca> an evolution of yours :)
[10:19] <mvo> Chipaca: nice find, out of curisoity, what is it copying around?
[10:19] <Chipaca> running it on my laptop with its blazing fast ssd, this wasn't noticeable
[10:19] <Chipaca> bah, a little: 6s to 4s or something like tht
[10:19] <Chipaca> on the gaming computer that has HDD homes, the above
[10:20] <Chipaca> anyway, will push the script and the results in a bit
[10:20] <Chipaca> i don't have zstd though so somebody else needs to run those to get that
[10:20] <Chipaca> (where is zstd supported?)
[10:21] <mvo> Chipaca: I can build you a sqaushfs-tools with zstd
[10:21] <mvo> Chipaca: its only available in git ./
[10:21] <Chipaca> mvo: will my kernel know how to mount it?
[10:21] <mvo> Chipaca: how do things compare to "on squashfs vs on ext4"? that is the most interessting one to me :)
[10:22] <mvo> Chipaca: thats a xenial kernel? I can check, iirc zstd in kernel was done way before squashfs-tools supported it (which is kinda-ironic)
[10:22] <mvo> Chipaca: 4.1.4
[10:22] <Chipaca> xenial here, bionic on the hdd
[10:22] <mvo> Chipaca: so should be in xenial, let me double check
[10:23] <Chipaca> CONFIG_SQUASHFS_ZSTD=y ← bionic
[10:23] <Chipaca> nothing like that in xenial
[10:24] <mvo> meh, ok
[10:24] <Chipaca> gnome-calculator:try:16560272:4577:3320:391
[10:24] <Chipaca> gnome-calculator:xz:4218880:4120:2904:328
[10:24] <Chipaca> mvo: ^ ext4 vs xz-compressed squashfs
[10:25] <Chipaca> about the same
[10:25] <Chipaca> (granted g-c is small)
[10:26] <mvo> Chipaca: silly me, misread - its 4.14 so no luck for you
[10:26] <mvo> Chipaca: niiiiiiiiiiiiiiice
[10:26] <mvo> Chipaca: I think that is a really good find
[10:26] <mvo> Chipaca: well, second run is with hot cache?
[10:27] <Chipaca> mvo: https://paste.ubuntu.com/p/82p3BFzwD9/
[10:27] <Chipaca> mvo: no, both drop caches
[10:27] <Chipaca> mvo: second run is without whatever the snap does on first run
[10:27] <mvo> Chipaca: \o/
[10:27] <mvo> Chipaca: you rock
[10:27] <mvo> Chipaca: this data looks very encouraging
[10:28] <Chipaca> mvo: https://gist.github.com/chipaca/2efec6e9d89cadada6478d8a010c5c2e
[10:29] <pedronis> Chipaca: what are you actually trying?  me is a bit confused here
[10:30] <Chipaca> pedronis: the effect of different compression options of squashfs on the speed of apps in a snap
[10:30] <mvo> pedronis: we talked yesterday that one of the open questions is how much overhead squashfs/xz is compared to ext4. I had some concerns about this from measurements on brave (and from feedback from the advocy team)
[10:30] <pedronis> mvo: talked when?
[10:30] <Chipaca> day before yesterday i think
[10:30] <Chipaca> pedronis: you were off
[10:32] <mvo> pedronis: do you have concerns about this ?
[10:33] <pedronis> mvo: multiple, mostly process ones
[10:33] <mvo> pedronis: as in "not the right time"?
[10:34] <pedronis> yes, also is untracked
[10:34] <pedronis> also it's hard for me to help if I don't have context
[10:36] <pedronis> mvo: if I look at trello I wouldn't know John is working on this
[10:36] <mvo> pedronis: meh, sorry then. I updated the trello to have some info on it. also its hopefully not a long task, ~1d or so. but happy to talk some more during the standup and address concerns
[10:36] <pedronis> or that it was started at all
[10:36] <mvo> pedronis: yeah, my bad, let me fix this
[10:40] <mborzecki> Chipaca: https://paste.ubuntu.com/p/wd3YjtbWbW/
[10:40] <pedronis> mvo: is John also working on https://trello.com/c/mwEvN8Hk/237-squashfs-install-performance-fuse-sucks ?
[10:40] <pedronis> or just the one you moved to WIP
[10:41] <Chipaca> pedronis: i am not working on that one
[10:41] <pedronis> ok, I thought you were
[10:41] <pedronis> that's why I was also confused
[10:41] <Chipaca> pedronis: we did talk about that i was working on this yesterday in the standup
[10:41] <pedronis> I understood as the other one
[10:41] <pedronis> funnily enough
[10:42] <pedronis> we did talk about lxd, no?
[10:42] <Chipaca> pedronis: i mentioned that tangentially i suggested the unpack-on-install approach as a global flag and that might be a solution to the fuse thing
[10:42] <pedronis> that's the other thing though
[10:42] <pedronis> so my confusion
[10:42] <mvo> pedronis: indeed, now it all makes sense. sorry for the confusion
[10:42] <Chipaca> heh
[10:43] <Chipaca> pedronis: this was one of the things that distracted me a bit from working on the benchmarking script itself (which is now done for now)
[10:43] <Chipaca> that, and people being wrong on the internet
[10:44] <mvo> Chipaca: heh :) I think we should write a forum post and maybe igor from advocacy can make it into a blog post). also would be nice to figure out what brave is doing, ideally we could suggest a fix to them (but timeboxed, lets not get dragged into a rathole :)
[10:44] <mvo> Chipaca: anyway, very happy with these numbers
[10:48] <Chipaca> mvo: http://paste.ubuntu.com/p/PVS5shj2QZ/
[10:48] <Chipaca> mvo: that's 'find ~/snap/brave' after first run, starting from it being empty
[10:49] <Chipaca> mvo: it's 37MB big
[10:49] <Chipaca> (so not big enough to justify how long it takes to do it)
[10:51] <mvo> Chipaca: thanks! its probably also doing some sort of generation for this data. oh well
[10:51] <Chipaca> mvo: desktop-launch
[10:52] <mvo> Chipaca: oh? snap run --trace-exec brave should give us some clues about this
[10:52] <Chipaca> ok let me do that on the slow box :)
[10:52] <mvo> Chipaca: i need to get lunch now, will read backlog
[10:52] <mvo> Chipaca: thank you!
[10:53] <Chipaca> pedronis: you ok with landing #6978 then? i'm not sure, from your comments
[10:59] <Chipaca> mvo: https://paste.ubuntu.com/p/sw3wGxgWzk/ (spoiler: it's update-mime-database)
[11:00] <mborzecki> off to pick up the kids
[11:16] <pedronis> Chipaca: ?
[11:17] <pedronis> Chipaca: no, need to have a pass, mostly about those switch summary messages
[11:17] <Chipaca> ok
[11:26] <pedronis> Chipaca: made my main comments
[11:33] <pedronis> Chipaca: I understand they from no channel came before, but given we are touching all of them it's a chance to improve that
[11:33] <Chipaca> yep
[11:33] <Chipaca> pedronis: but
[11:34] <Chipaca> pedronis: can i address it in a followup?
[11:35] <pedronis> Chipaca: worried about conflicts ?
[11:35] <Chipaca> pedronis: wanting to get the pr that exposes all these things (with spread test) up
[11:35] <Chipaca> and it's stacked on this one
[11:35] <pedronis> ah, ok
[11:38] <pedronis> Chipaca: ack that in the PR
[11:38] <pedronis> *acked
[11:39] <mborzecki> re
[11:58] <pedronis> mvo: pstolowski: made a comment on #7000
[12:03] <pstolowski> pedronis: thanks, thinking about it right now
[12:03] <pedronis> pstolowski: also we have a bigger problem, what if snapd comes from snapd
[12:04] <pedronis> but you have core installed
[12:05] <mvo> pedronis: thank you, in a meeting right now but will look at it once that is over
[12:07] <pstolowski> pedronis: right.. this logic predates snapd snap.. the reset only happens for level 6 under these conditions, and patches should be idempotent though
[12:07] <pstolowski> pedronis: nb, we have 2 other issues i found that led to all this, we can discuss before/after standup
[12:07] <pedronis> pstolowski: yes, the problem is that we wouldn't run them though
[12:07] <pedronis> because snapd will be updated before core maybe
[12:07] <pedronis> but we look at core
[12:08] <pedronis> (not sure it depends on ordering issues)
[12:09] <pstolowski> pedronis: hmm i see
[12:13] <zyga> hey everyone
[12:13] <zyga> last day
[12:14] <pstolowski> hey zyga! how is it going? tired?
[12:14] <zyga> it's been a fantastic week
[12:15] <zyga> lots of really amazing results
[12:15] <zyga> I strongly recommend reading the forum summary
[12:15] <pstolowski> zyga: yep i saw the tweets etc
[12:15] <zyga> https://forum.snapcraft.io/t/snapcraft-summit-montreal-2019-day-1-2-3/11763/5 <- for anyone interested
[12:15] <zyga> pstolowski: building firefox out of nixos packages in ~10 lines == mind blown
[12:15] <zyga> a little tired :)
[12:16] <zyga> but it's 14C here so I cannot complain
[12:17] <zyga> how was the week back home?
[12:18] <pstolowski> zyga: insanely hot.. with thunders yesterday afternoon, so a little relief
[12:20] <zyga> I'm off for breakfast, ttyl
[13:14] <vladoski> I'm trying to install Heroku via snap, but everytime gets stuck on this and fails: error: cannot perform the following tasks:
[13:14] <vladoski> - Run configure hook of "heroku" snap if present (run hook "configure": execv failed: Permission denied)
[13:17] <Chipaca> vladoski: strange
[13:17] <Chipaca> vladoski: what snap is it?
[13:17] <Chipaca> d'oh, "heroku"
[13:18] <vladoski> Chipaca: yep it's heroku
[13:19] <Chipaca> vladoski: looks like a buggy snap
[13:19] <Chipaca> vladoski: do you have /snap/bin ?
[13:19] <vladoski> ahm, so what should I do?
[13:20] <vladoski> Chipaca: yes
[13:21] <vladoski> I have 4 snaps in it
[13:21] <Chipaca> vladoski: what's the output of 'snap version'?
[13:26] <vladoski> snap    2.39.1-1.fc30
[13:26] <vladoski> snapd   2.39.1-1.fc30
[13:26] <vladoski> series  16
[13:26] <vladoski> fedora  30
[13:26] <vladoski> kernel  5.1.8-300.fc30.x86_64
[13:26] <vladoski> Chipaca: that's the output
[13:28] <Chipaca> mborzecki: ^ ?
[13:29] <vladoski> I'm using Fedora 30 if it helps
[13:29] <vladoski> oh nvm it was in the log ahah
[13:29] <Chipaca> vladoski: yeah, mborzecki has been looking at issues on fc30 which is why i'm asking him to take a look
[13:29] <Chipaca> just in case it's a known issue / known workaround
[13:30] <mborzecki> vladoski: it's aknown problem, we have a fix for it and it's in fedora src repo already, we just need to update the package
[13:30] <Chipaca> huzzah
[13:31] <vladoski> Yes I know that snap is a little buggy now with fedora, one week ago I had to remove it because it was giving problems with battery status, function keys and system errors
[13:31] <mborzecki> wondering if zyga or Eighth_Doctor could fedpkg build a new package maybe?
[13:32] <Eighth_Doctor> for what?
[13:32] <mborzecki> vladoski: you can temporarily switch selinux to permissive, setenforce 0, install the snap, and then setenforce 1
[13:32] <mborzecki> Eighth_Doctor: snapd
[13:32] <Eighth_Doctor> oh the fixes you sent in yesterday, right?
[13:33] <mborzecki> Eighth_Doctor: yup :)
[13:33] <Eighth_Doctor> I'll fedpkg build them now
[13:33] <Eighth_Doctor> only reason I didn't was that I thought mvo was going to release 2.39.3 with that fix integrated
[13:34] <Chipaca> Eighth_Doctor: hmm, yesterday mvo in the standup decided not to do a .3, and have it be distro-patched, so we could move on to .40
[13:35] <mborzecki> Eighth_Doctor: i think we'll do 2.40, let me double check with mvo
[13:35] <Chipaca> Eighth_Doctor: we dropped the ball on letting you know
[13:35] <Eighth_Doctor> welp
[13:35] <mborzecki> ah, missed that
[13:35] <Chipaca> mborzecki: was that a "mvo should have told you to communicate that"?
[13:35] <mvo> meh, sorry, did I fail at doing this?
[13:35] <zyga> mborzecki: next week at earliest
[13:36] <mborzecki> Chipaca: nope, i should have picked that up myself :P
[13:36] <Eighth_Doctor> I guess I'll update to 2.39.2 and push it
[13:36] <mborzecki> so basically, /me dropping the ball :)
[13:36] <Chipaca> mborzecki: yes but mvo should've double-checked :)
 etc
[13:36]  * Chipaca lazy
[13:36] <mborzecki> Eighth_Doctor: that last 2 patches are not in .2, so please apply those separately
[13:37] <Eighth_Doctor> will do
[13:37] <mborzecki> Eighth_Doctor: great, thank you!
[13:47] <Eighth_Doctor> they're building now
[13:49] <Eighth_Doctor> zyga, mborzecki: I've been thinking that for Fedora snaps, we should look to plug into the modularity toolchain
[13:49] <Eighth_Doctor> instead of trying to beat snapcraft into working
[13:49] <Eighth_Doctor> I'm tired of trying to figure out how to make snapcraft do what I want, and getting the modularity toolchain to do it would make it possible for Fedora contributors to officially build and submit snaps
[13:50] <mborzecki> ha
[13:50] <mborzecki> Eighth_Doctor: sounds like what the nix guys did
[13:50] <zyga> Eighth_Doctor: I have the exact same feeling this week
[13:50] <Eighth_Doctor> and like the flatpaks/ namespace we have in Dist-Git, we could have a snaps/ one for people to make snap modules
[13:50] <zyga> Eighth_Doctor: it is the most direct way to get the right things to happen
[13:50] <zyga> Eighth_Doctor: oh, btw, I asked the godot deveoper to go to flock
[13:50] <Eighth_Doctor> yeah
[13:50] <zyga> his work on using fedora in snaps is amazing
[13:50] <Eighth_Doctor> which one?
[13:50] <zyga> and it  is really an eye-opening experience as to why this is done this way
[13:51] <zyga> Eighth_Doctor: godot stack, including games, are all built from fedora bits
[13:51] <zyga> Eighth_Doctor: but the story there is much deeper
[13:51] <Eighth_Doctor> nice!
[13:51] <Eighth_Doctor> I knew that at least one godot dev liked the fedora stack :)
[13:52] <Eighth_Doctor> and that would be an awesome surprise to put into our presentation at flock: https://pagure.io/flock/issue/163
[13:53] <Eighth_Doctor> zyga, mborzecki: https://src.fedoraproject.org/projects/flatpaks/*
[13:53] <Eighth_Doctor> I want exactly the same thing for snaps
[13:53] <mborzecki> cachio: https://github.com/snapcore/snapd/pull/7004 this should work (works locally in xenial vm), i'll try to run one of nested core tests
[13:55] <Eighth_Doctor> zyga: I'm pretty close to having a new simple tool for producing a base snap
[13:55] <Eighth_Doctor> there's a few things I'm changing up so that it works in a decently portable way across rpm distros without baking too much logic into it for that
[13:56] <Eighth_Doctor> but also the part I don't know is uploading snaps properly without requiring snapcraft
[13:56] <Chipaca> siiiiigh
[13:57] <Chipaca> home isn't auto-connected on core, right?
[13:57] <Chipaca> si³³gh
[13:57]  * Chipaca fixes the spread test
[13:57] <cachio> mborzecki, nice
[13:58] <cachio> i'll try it
[13:59] <mborzecki> cachio: i'm trying google-nested:ubuntu-16.04-64:tests/nested/core/hotplug
[13:59] <zyga> Chipaca: correct
[14:01] <cachio> mborzecki, nice, I integrated that to the PR #6892 and I am running on 18.04 and 16.04
[14:01] <cachio> I'll tell you how it works
[14:02] <Eighth_Doctor> zyga, mborzecki: bodhi updates proposed
[14:02] <Eighth_Doctor> F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-17c0fb9ce6
[14:02] <Eighth_Doctor> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-91c0be0cc5
[14:02] <Eighth_Doctor> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-502ed76053
[14:03] <Eighth_Doctor> I need testing and karma
[14:03] <mborzecki> Eighth_Doctor: great, thank you!
[14:05]  * Chipaca reckons Eighth_Doctor should have enough karma to launch a spaceship, at this point
[14:05]  * Eighth_Doctor snorts
[14:06] <mborzecki> vladoski: you should be able to get a working version from updates-testing repo once it's there ^^
[14:07] <vladoski> mborzecki: okay thanks!
[14:09]  * cachio afk
[14:10]  * zyga is extremely sleepy and tired
[14:10] <zyga> sorry everyone
[14:13] <zyga> Eighth_Doctor: some more attention on the update, thank you for working on this !
[14:24] <abeato> jdstrand, hey, I have a couple of minor updates to interfaces waiting for review: https://github.com/snapcore/snapd/pull/6962 and https://github.com/snapcore/snapd/pull/6975
[14:39] <juliank> I recently realized that snapped browsers break integration with KeePassXC, because it uses some native messaging thingy
[14:39] <juliank> but I'm not sure what could be done about that
[14:39] <pedronis> pstolowski: I reviewed #6960
[14:40] <juliank> Apparently this is super nasty stuff, where the browser invokes a binary on the host
[14:41] <juliank> e.g. https://developer.chrome.com/extensions/nativeMessaging
[14:42] <pstolowski> pedronis: ty
[15:11] <cachio> pstolowski, when you have some time could you please take a look to #6892
[15:13] <pstolowski> cachio: oh yes, looking now
[15:13] <cachio> pstolowski, thanks
[15:17] <pstolowski> cachio: so the problem with assertion disk & snapshot remains unresolved, right? no problem with the workaround, just curious, did Maciej have any other ideas?
[15:18] <cachio> pstolowski, no new ideas so fat
[15:18] <cachio> far
[15:18] <cachio> I juest tested the change on how assertions disk is created
[15:18] <cachio> and works very well
[15:19] <cachio> I'll wait Maciej reply before merging this PR
[15:23] <pstolowski> cachio: ok, +1 from me
[15:23] <cachio> pstolowski, nice, thanks
[15:47]  * cachio lunch
[19:05]  * cachio afk