[04:40] <zyga> o/
[05:10] <mborzecki> morning
[05:13] <zyga> mborzecki: hey
[05:13] <zyga> https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
[05:13] <mborzecki> yup reading
[05:16] <mborzecki> zyga: any clue if mvo got access to a vm where the refresh-mode issue was reproducible?
[05:16] <zyga> no
[05:16] <zyga> let's make a spread test that has similar characteristics
[05:16] <mborzecki> zyga: do we know what disto tha was?
[05:16] <zyga> and strace the hell out of it
[05:17] <zyga> not really
[05:17] <zyga> note that we have not reproduced it yet
[05:17] <zyga> but I will let mvo discuss tihs
[05:17] <zyga> he knows the most
[05:21] <mborzecki> hm that memory usage, we could play with GOGC, but there's another possibility that we're just keeping that much stuff in memory
[05:22] <mborzecki> (i'm taking about RES, VIRT is high but it should not be a problem)
[05:47] <zyga> mborzecki: yes, RES is key, though VIRT is weirdly huge
[05:47] <zyga> but maybe that's the nature of golang gc
[05:47] <zyga> ok, kids off to school
[05:47] <zyga> and I can have my coffee and focus
[06:32] <mborzecki> gdm is just so useless, it stats a whole gnome session, does nothing else than shows a login screen and has a 50% chance of locking up the system when switching back to it after logout
[06:33] <mborzecki> at least autostart works as expected with 2.32.4
[06:33] <zyga> Heh, the modern desktop stack
[06:34] <mborzecki> btw. clicking on quit label in tray menu of discord: https://paste.ubuntu.com/p/CtG3Kx7Kxt/
[06:39] <zyga> Well
[06:39] <zyga> On my system gnome shell logs errors every second
[06:40] <zyga> Finalization issue with some object
[06:40] <zyga> I frankly miss unity quality
[06:40] <zyga> Later on unity was way more solid
[06:51] <mborzecki> ok, bumped arch package to 2.32.4
[06:52] <mvo> good morning
[06:52] <mborzecki> mvo: morning!
[06:53] <zyga> hey mvo
[06:55] <mvo> hey mborzecki and zyga ! how is life this morning?
[06:55] <zyga> great, it's a bit chilly in the morning though
[06:55] <zyga> I'm looking into the memory leak
[06:56] <zyga> but if I get stuck or it goes nowhere I will look at the mount issue
[06:56] <pedronis> hello
[06:57] <zyga> hey good morning
[06:58] <pedronis> so I discovered that init is 2M and snapd nowadays 21M , just the executable  (of course systemd has other daemons)
[06:58] <zyga> I really wonder what is inside golang executables
[06:58] <zyga> small instance of google Borg?
[06:58] <pedronis> well, as I said,  systemd has many daemons
[06:58] <pedronis> so it's not a fair comparison
[06:59] <pedronis> but it doesn't put in a good spot
[06:59] <pedronis> we have not to run at all, not to use memory
[07:00] <mborzecki> that ~21M would mostly count to virt though
[07:00] <pedronis> mborzecki: looking at smaps it doesn't seem so
[07:00] <mborzecki> but it still needs to be loaded into memory and so on
[07:01] <pedronis> anyway on a constrained system probably even running and stopping is bad
[07:03] <pedronis> mvo: let me know if we should have a HO in 1h or so to talk about that issue at least and options
[07:04] <mvo> pedronis: yeah, sounds good a HO in the morning sounds good, I am currently baby-sitting autopkgtest but hopefully that does not take too long
[07:06] <pstolowski> morning
[07:06] <zyga> hey pawel
[07:06] <zyga> http://paste.ubuntu.com/p/GtVYbzfgC8/
[07:06] <zyga> pstolowski: FIY https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
[07:07] <pstolowski> zyga: yes reading
[07:13] <zyga> with GOGC=10 http://paste.ubuntu.com/p/Gbnz675BT3/
[07:13] <mborzecki> playing with GOGC, off -> 33MB, 5 -> 19MB, 50 -> 20MB, 100 (default) -> 22MB
[07:17] <mvo> zyga: what tool is that?
[07:17] <zyga> pmap
[07:17]  * mvo nods
[07:19] <mborzecki> zyga: comparison of GOGC=1 and GOGC=100 https://paste.ubuntu.com/p/74zgkbZBWj/
[07:19] <mborzecki> (disabled ASLR so that we get stable addresses)
[07:19] <zyga> nice
[07:19] <zyga> how did you disable ASLR?
[07:20] <mborzecki> /proc/sys/kernel/randomize_va_something
[07:20] <zyga> but the bottom line is that rss shrinks just a little and virt doesn't
[07:20] <mwhudson> you can also disble aslr for one invocation with setarch
[07:21] <mwhudson> setarch `uname -m` -R whatever
[07:21] <mborzecki> nice
[07:26] <mborzecki> wonder why there's 7 * 64MB and 6*8MB blocks, 64MB ones are ---p, 8MB are rw-p
[07:28] <mup> PR snapd#5035 closed: release: snapd 2.32.4 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5035>
[07:29] <mvo> good news, spread on xenial is happy again and we have some tests passing already, the other ones are retriggered
[07:29] <mvo> (missing build of test-snapd-account-services on s390x was one failure which is fixed now)
[07:31] <zyga> mborzecki: noite that the 64MB ones are empty
[07:31] <zyga> they take almost no memory
[07:32] <mborzecki> zyga: cow?
[07:34] <zyga> they feel like a/b gc
[07:35] <mborzecki> hm bottom line, we're not going to get lower than whatever is the size of snapd binary, i.e. ~16MB
[07:38] <mborzecki> zyga: installing core snap https://paste.ubuntu.com/p/dQDYNJz2Vf/
[07:41] <mborzecki> also the binary in core built with go 1.7 right?
[07:41] <mborzecki> zyga: before and after installing core snap and reexec https://paste.ubuntu.com/p/xPpCQjV4j8/
[07:56] <pstolowski> zyga, mvo, mborzecki would it make sense to add profiling code to snapd and land it in edge, eg something like https://flaviocopes.com/golang-profiling/ in the daemon?
[07:58] <mborzecki> pstolowski: there's pprof which is super simple
[07:59] <zyga> pstolowski: I don't have experience with that, no idea
[08:00] <mborzecki> i can try building it locally though
[08:01] <pstolowski> yeah i'm going to try local build too
[08:11] <zyga> man we are leaking that memory quickly
[08:13] <zyga> I'm in a loo where test-snapd-poicy-app-consumer:bluez is constantly discon reconnected
[08:14] <zyga> this also stresses udev
[08:15] <mvo> mborzecki: the binary in core is build with go1.6 (xenial)
[08:15] <pedronis> mvo: I'm around
[08:15] <mvo> zyga: kernel mem?
[08:15] <mvo> pedronis: ok, I join in 2min then
[08:15] <zyga> mvo: perhaps, I'm not sure yet
[08:17] <zyga> interestingly doing this puts lots of load on X as well
[08:17] <zyga> (perhaps due to udev)
[08:17] <zyga> to the point where session is unresponsive (not stuck but very slow)
[08:17] <zyga> I see constantly raising buffer_head allocations
[08:20] <zyga> I see several dozen udev processes at a time
[08:20] <zyga> the leak may be unrelated to apparmor if udevadm trigger / settle leaks something into the kernel / netlink area
[08:22] <mwhudson> BjornT_: hi, do you have a ppa with a snapcraft that has https://github.com/snapcore/snapcraft/pull/2058 applied by any chance?
[08:22] <mup> PR snapcraft#2058: python plugin: install python-distutils when run on bionic <bug> <Created by bjornt> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2058>
[08:24] <BjornT_> mwhudson: no. but it's in the snap edge channel now
[08:25] <mwhudson> BjornT_: hm but you can't build a snap in launchpad from a snapcraft from a snap can you?
[08:26] <mwhudson> (that sentence is quite a tongue twister)
[08:29] <BjornT_> mwhudson: right, you can't. but i'm guessing you will have problems building a bionic snap in launchpad anyway, won't you?
[08:32] <Chipaca> mvo: I saw you put #1616629 into 'in progress', does that mean you have a branch for it?
[08:33] <mup> Bug #1616629: could not unmarshal state entry "snap-type" <Snappy:In Progress> <https://launchpad.net/bugs/1616629>
[08:46] <mwhudson> BjornT_: nope, been doing that for months :)
[08:58] <mvo> Chipaca: it means "we are looking at it", pedronis  is working on improving the error at least to fail way earlier
[08:58] <Chipaca> mvo: ah, ok
[08:59] <pedronis> Chipaca: one theory is that it relates to removing and reinstalling   (maybe we the fs of the snap in use) and lazy unmounting
[08:59] <Chipaca> pedronis: was that what pindonga did yesterday?
[09:00] <pedronis> yes, he said he had removed the snap
[09:00] <pedronis> Chipaca: anyway current plan is 1) improve error, 2) possibly add belt and suspenders 3) somebody might want to play with loops of remove and install of the same thing
[09:01] <Chipaca> i can start on 3 right no
[09:01] <Chipaca> now*
[09:01] <pedronis> thx
[09:02] <pedronis> I will work now on 1)
[09:06] <mvo> zyga: here is something strange. this is the LowMem value after running each of the tests, the tests are in order http://paste.ubuntu.com/p/k8wvw689B9/
[09:07] <mvo> zyga: the fluctuation is also strange
[09:07] <zyga> I suspect what is going on is that as memory pressure raises kernel is dropping more and more caches
[09:08] <zyga> releasing some memory in that zone
[09:08] <mvo> zyga: aha, yeah, that makes sense
[09:09] <mborzecki> pstolowski: hooked up pprof finally, https://paste.ubuntu.com/p/XXBv8qFFym/ :6060 is the regular http one, the one over /run/snapd.socket you need to wrap around with socat
[09:11] <mborzecki> pstolowski: something like `socat -v tcp-listen:6070,reuseaddr,fork "unix-connect:/run/snapd.socket"` should work
[09:12] <pedronis> mborzecki: pstolowski:  we discussed with mvo some ideas about not starting at all  , it seems hard to  halve or /3 memory usage in one week
[09:13] <mborzecki> pedronis: especially as the binary is 16MB already ;)
[09:13] <mborzecki> pedronis: so what are the current ideas?
[09:14] <pedronis> mborzecki: mvo is working on that I think,   but basically only play at the level of the systemd units
[09:15] <pstolowski> mborzecki: thanks, checking; i was pursuing something else in the meantime - run 2.32.4 snapd under gcvis but didn't find anything conclusive
[09:15] <Chipaca> is it still the case that a snap can't call a binary in another snap?
[09:16] <mvo> mborzecki: the idea is to use a generator that looks if there is a snap or a seed and if none of this is true generates a service file that is socket activated only
[09:16] <mvo> mborzecki: this way we do not run at all on cloud instances until first use
[09:16] <mvo> mborzecki: the downside is that we don't get the c-n-f data so we need to put that into an external timer
[09:17] <mvo> but I think its an acceptable trade-off given the time contrains
[09:18] <mborzecki> sounds fair
[09:18] <mborzecki> mvo: do you need help with that?
[09:19] <mvo> mborzecki: sure, I also have the sigterm issue that needs attention, if you want to add the generator that would be great.
[09:20] <mvo> mborzecki: we have two options: a) generator b) snapd is also socket activated and we add a "wakeup" service that has conditions on /snap/* and /var/lib/snapd/seed/*
[09:20] <mvo> mborzecki: and this wakeup would just run snap version to ensure the daemon runs
[09:21] <mvo> mborzecki: plus one idea from zyga was to use the "idle" option of systemd so that snapd starts a bit later (when it starts) when the system has settled
[09:21] <mvo> mborzecki: sounds sensible? happy to have a quick HO if you want
[09:21] <mvo> mborzecki: alternatively the SIGTERM issue is something I am willing to trade too, whatever you find more interessting :)
[09:22] <pedronis> to be clear: /snap/*   OR  /var/lib/snapd/seed/seed.yaml
[09:22] <pedronis> not AND
[09:22] <mborzecki> mvo: let's do HO
[09:23] <Chipaca> pedronis: /snap/*/current i guess
[09:23] <pedronis> something
[09:23] <pedronis> it's really /snap/* ignoring bin
[09:24] <pedronis> and also /snap is not always snap
[09:26] <Chipaca> the problem with doing install/remove in a loop is that i quickly remember how badly that grows :-(
[09:28] <Chipaca> loop #1: ~1s; loop #200: ~6s
[09:28] <mup> PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>
[09:28] <Chipaca> mup: er... thanks
[09:28] <mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
[09:36] <mvo> mup: #1
[09:36] <mvo> *pfff*
[09:41] <Chipaca> mvo: istr #1 being an issue, which are now gone
[09:44]  * cjwatson is lost in a twisty maze
[09:44] <cjwatson> Is there some way to force snapd to forget about its existing store device macaroon?
[09:44] <cjwatson> It must be serialised to disk somewhere to persist between snapd startups, but I can't find it
[09:45] <mvo> Chipaca: yes, gone, let me update the post
[09:46]  * zyga builds 4.17
[09:46] <zyga> well, master
[09:46] <pedronis> cjwatson: it's in   state.json  under  data.auth.device
[09:46] <zyga> kissiel: /me hugs his computer :)
[09:46] <pedronis> cjwatson: session-macaroon
[09:47] <Chipaca> mvo: which post?
[09:47] <pedronis> cjwatson: /var/lib/snapd/state.json.  stop and restart snapd for editing
[09:47] <cjwatson> Aha, thanks
[09:50] <mwhudson> mvo: np on go 1.6/stable, i'm just waiting for the coinstallable tracks feature :)
[10:00] <mwhudson> zyga: would you be interested in my "use x/net/context instead of context" sed of doom? :)
[10:00] <mwhudson> find -type f -name \*.go \! -path '*/.pc/*' -print0 | xargs -0 sed -i -e 's%^\(\s\+\)"context"$%\1"golang.org/x/net/context"%'
[10:00] <mwhudson> zyga: it works on docker.io :)
[10:01] <zyga> mwhudson: across the whole tree?
[10:01] <zyga> mwhudson: well, I don't mind that, though I don't see how that helps us this week (fire squad)
[10:01] <mwhudson> zyga: i saw something about spread not building with go 1.6?
[10:01] <zyga> ah
[10:02] <zyga> mvo fixed that earlier today
[10:02] <mwhudson> ok
[10:02] <mwhudson> never mind me then :)
[10:02] <zyga> mwhudson: but thank you for the offer
[10:02] <zyga> we are working through this list: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954/1
[10:04] <mup> PR snapd#5036 opened: overlord/snapstate: allow to get an error from readInfo instead of a broken stub, use it in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5036>
[10:04] <pedronis> mvo: Chipaca: ^
[10:06] <mvo> pedronis: thank you!
[10:07] <mborzecki> hmmm /snap/README, there goes ConditionExistsGlob
[10:07] <Chipaca> mborzecki: /snap/*/current
[10:08] <mborzecki> Chipaca: oh, that's good
[10:09] <mborzecki> pedronis: just to be sure, that's an /snap/.. OR /var/lib/../seed.yaml ?
[10:09] <mvo> mborzecki: yes, either of those should trigger a wakeup
[10:09] <Chipaca> Apr 12 11:09:21 fleet snapd[7512]: 2018/04/12 11:09:21.252174 services.go:226: DEBUG: StopServices called for [%!q(*snap.AppInfo=&{0xc820397600 webserver [] command-webserver.wrapper simple 0        map[network:0xc8203f9270 network-bind:0xc8203f92c0] map[] map[] {[] map[]} [] [] <nil>})], reason: remove
[10:09] <mup> PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12>
[10:09] <Chipaca> hmmm
[10:09] <mborzecki> mvo: ok
[10:10] <Chipaca> something awry in a printf :-)
[10:11] <mvo> Chipaca: woah, where did you get this?
[10:13] <Chipaca> mvo: snap remove a snap with a service with debug on
[10:14] <Chipaca> i looped installing/removing a snap without a service and it couldn't repro 1616629, so now trying with a service
[10:16] <pedronis> Chipaca: doInstall also has int flags, yes but things that are exported or go into state I agree we shouldn't use int flags
[10:16] <Chipaca> pedronis: we still have a lot of int flags, and i don't think it's a blocker
[10:28] <mborzecki> so the wakeup service works
[10:28] <mborzecki> spread test for this will be tricky
[10:31] <zyga> jdstrand: hey
[10:31] <zyga> jdstrand: is apparmor@lists.ubuntu.com still the place to send patches?
[10:32] <mwhudson> sergiusens: fwiw 'd bet patchelf is doing something differently horrible to java
[10:33] <mwhudson> +i
[10:34] <mup> Issue snapcraft#1676 closed: Support for set-version <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1676>
[10:34] <mup> PR snapcraft#2063 closed: many: add snapcraftctl set-version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2063>
[10:38] <pedronis> Chipaca: btw seems we don't have undo on error code in doMountSnap, not sure it's good time to add that tough
[10:39] <mborzecki> pedronis: where?
[10:39] <mup> PR snapd#5037 opened: snap: snap.AppInfo is now a fmt.Stringer <Created by chipaca> <https://github.com/snapcore/snapd/pull/5037>
[10:39] <Chipaca> pedronis: undo as in in-task undo?
[10:40] <Chipaca> mvo ^ 5037 fixes that %!q thing
[10:40] <mvo> Chipaca: nice
[10:41] <pedronis> Chipaca: yes, in-task undo
[10:41] <mborzecki> pedronis: around readInfo?
[10:41] <Chipaca> pedronis: what are we missing?
[10:42] <Chipaca> pedronis: removing the mount unit?
[10:42]  * Chipaca looks
[10:42] <pedronis> removing the mount unit
[10:42] <pedronis> I suppose
[10:42] <pedronis> in fairness SetupSnap is an opaque name
[10:42] <Chipaca> no, we remove the unit
[10:42] <Chipaca> one rror
[10:42] <Chipaca> RemoveSnapFiles removes the unit
[10:42] <Chipaca> stops and removes, even
[10:43] <pedronis> yes, but now ReadInfo itself can fail
[10:44] <pedronis> (well it always could but not materially)
[10:44] <Chipaca> pedronis: ah! now i gotcha
[10:45] <Chipaca> pedronis: sounds like you want a m.backend.RemoveSnapFiles there then
[10:45] <pedronis> yes, seems so
[10:45] <Chipaca> or maybe UndoSnapSetup?
[10:45] <Chipaca> UndoSetupSnap*
[10:45] <Chipaca> which, er, just calls RemoveSnapFIles :-) but might make the intent clearer from the calling side
[10:46] <pedronis> yes
[10:49] <zyga> woah?
[10:50] <zyga> WOAH
[10:50] <zyga> mvo: wanna hear a funny story?
[10:50] <zyga> my test
[10:50] <pedronis> Chipaca: sadly that thing needs a type
[10:50] <zyga> where I ate 8GB of ram pretty quickly
[10:50] <zyga> this was my command
[10:50] <zyga> sudo sh -c 'for i in $(seq 10000); do snap connect test-snapd-policy-app-consumer:bluez && snap disconnect test-snapd-policy-app-consumer:bluez; done'
[10:51] <zyga> I took a snapshot of all the profiles before/after this
[10:51] <zyga> before disconnect and after disconnect
[10:51] <zyga> it was connected initially
[10:51] <zyga> and the profiles are identical
[10:51] <zyga> all the apparmor profiles on my system
[10:51] <zyga> so we were leaking all that memory _despite_ not having _any_ changes
[10:52] <Chipaca> pedronis: which thing?
[10:52] <pedronis> UndoSnapSetup
[10:52] <pedronis> sorry, UndoSetupSnap
[10:52] <pedronis> now, that I look at the code, there's a lot of silliness going on
[10:52] <zyga> so, a bit of a WTF moment
[10:52] <Chipaca> pedronis: :-)
[10:52] <zyga> I will write a loop that recompiles that one profile in a loop and see if that is eating any memory
[10:52] <pedronis> Chipaca: SnapSetup read the type from the snap,   and the its caller tries to read the type from the mount
[10:52] <Chipaca> zyga: wtf yes
[10:53] <zyga> iff it does that's also very interesting
[10:53] <zyga> because apparmor parser supposedly does nothing when you are not really changing the profile
[10:53] <Chipaca> zyga: the 8G is kernel, not snapd?
[10:53] <zyga> so perhaps simply reading one of the apparmorfs files leaks
[10:53] <zyga> Chipaca: yes
[10:53] <Chipaca> noice
[10:53] <zyga> almost all in kmalloc-1024
[10:53] <zyga> I'm on mainline master
[10:53] <zyga> so that should give us all the fixes
[10:54] <zyga> I'll start by confirming the loop I used before still leaks
[10:54] <pedronis> Chipaca: so apart details of how is easy it is to untangle this,   the readInfo is not stricly needed, it's a nice fence though
[10:54] <Chipaca> pedronis: only if we check the error
[10:55] <pedronis> but then we need the type to undo
[10:55] <pedronis> I wonder how painful it is to add returning the type to SetupSnap
[10:55] <pedronis> and how tisky
[10:55] <pedronis> risky even
[10:56] <popey> jdstrand: updating the machine (kernel) fixed that issue, thanks.
[10:57] <zyga> mvo: I have a feeling this issue, whatever it is, is fixed in mainline
[10:57] <zyga> so it _might_ be in ubuntu sauce
[10:57] <pedronis> Chipaca: I'll try to see what I can do
[10:58] <zyga> or just not present in mainline
[10:58] <zyga> I'm on a mainline kernel now
[10:58] <Chipaca> pedronis: you could even return the whole info
[10:58] <Chipaca> pedronis: and avoid that readinfo entirely
[10:58] <zyga> I'll leave it running for 15 minutes
[10:58] <Chipaca> ah, but we only use the type
[10:58] <mborzecki> what would be the idiomatic way to disable just one service in debian/rules?
[10:58] <Chipaca> pedronis: now i gotcha
[10:58] <zyga> but even if it is raising, it's doing so at a far slower pace
[10:59] <pedronis> the readInfo is realy a check, it this thing mounted at all
[10:59] <Chipaca> mborzecki: carg-cult copying of a 2MB bash file, probably
[10:59] <pedronis> but yes we need only the type
[10:59] <zyga> jdstrand: ^ FYI
[11:00] <Chipaca> zyga: the 8GB was also on mainline, and the difference now is just reloading in a loop?
[11:00] <zyga> Chipaca: AFAIK we never used mainline kernel before
[11:00] <zyga> on the ubuntu kernel we quickly eat memory
[11:00] <Chipaca> zyga: so the 8GB was on ubuntu kernel?
[11:00] <zyga> yes
[11:03] <sparkiegeek> *cough* is the forum inaccessible to everyone, or just me?
[11:03] <zyga> sparkiegeek: oh?
[11:03] <zyga> I _just now_ posted a message
[11:03] <zyga> https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/11?u=zyga
[11:03] <sparkiegeek> zyga: The certificate expired on 12 April 2018, 11:17. The current time is 12 April 2018, 12:01
[11:03] <sparkiegeek> zyga: with HSTS enabled
[11:03] <zyga> oops :)
[11:03] <zyga> perhaps my browser is more lousy
[11:03] <Chipaca> i also don't see that fwiw
[11:04] <zyga> niemeyer: ^ FYI, it looks like forum cert is has expired
[11:04] <sparkiegeek> https://www.ssllabs.com/ssltest/analyze.html?d=forum.snapcraft.io&latest
[11:04] <sparkiegeek> confirms that it's expired
[11:04] <zyga> after running for ~10 minutes my memory usage is below 2GB
[11:07] <Chipaca> speaking of expiry, i need to go make lunch for the tribe
[11:07] <Chipaca> ttfn
[11:07] <sparkiegeek> Chipaca: bon appetit
[11:08] <niemeyer> zyga: Yeah, I was going to make sure it was renewed yesterday and missed it...
[11:08] <niemeyer> I'm on it
[11:09] <zyga> woot, thanks
[11:11] <vidal72[m]> are you aware of expired cert for https://forum.snapcraft.io ?
[11:11] <sparkiegeek> vidal72[m]: has just been fixed
[11:12] <vidal72[m]> sparkiegeek: I can confirm, thx
[11:19] <mup> PR snapd#5038 opened: data/systemd: helper service for waking up the main snapd service <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5038>
[11:19] <jdstrand> popey: nice!
[11:20] <jdstrand> zyga: yes, posting your findings to the mailing list would make sense, or adding to https://bugs.launchpad.net/apparmor/+bug/1750594
[11:20] <mup> Bug #1750594: Eventual OOM with profile reloads <AppArmor:New> <https://launchpad.net/bugs/1750594>
[11:20] <zyga> jdstrand: nice, thanks
[11:22] <zyga> jdstrand: I found some interesting things already: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/11?u=zyga
[11:22] <zyga> and sent some silly patches to apparmor tree
[11:28] <jdstrand> zyga: I see that. that should help jjohansen. I also summarized the email I sent yesterday in that topic
[11:28] <zyga> I see that, thanks
[11:29] <sergiusens> mwhudson: yeah, it seems to be the case as it is not an isolated incident
[11:30] <mwhudson> sergiusens: reading the patchelf code makes it seem a bit ... optimistic, maybe?
[11:33] <sergiusens> mwhudson: eventually I will have to do what I wanted to avoid doing when tasked to work on classic confinement and just master that code base and elf
[11:34] <mwhudson> sergiusens: i learnt waaaay too much about all that stuff doing go shared libraries
[11:34] <mwhudson> it's fun, mostly :)
[11:34] <mup> PR snapd#5039 opened: overlord/snapstate: use the readInfo in doMountSnap as a check only, undo if it errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5039>
[11:34] <pedronis> Chipaca: mvo: digging deeper ^
[11:35] <mwhudson> sergiusens: have you read ian lance taylor's blog? https://www.airs.com/blog/archives/38 through https://www.airs.com/blog/archives/57
[11:36] <sergiusens> I have not; adding to the reading list. Thanks!
[11:42] <didrocks> cjwatson: hey, sorry if the question was probably already asked (it was probably already done), but is there any way to get daily build of a snap (even if the branch didn't change, as a snapcraft.yaml can refer to multiple repos) on https://build.snapcraft.io/ or launchpad?
[11:43] <didrocks> I guess the workaround can be to use launchpad API to start a build, but I would prefer something more integrated
[11:43] <mup> PR snapcraft#2065 opened: many: update the yaml loading logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2065>
[11:44] <popey> didrocks: i personally use lp-build-snap (a snap) to poke the launchpad API daily via a cron job to do that
[11:44] <popey> build does do daily builds now AIUI.
[11:45] <didrocks> popey: oh? (well, I guess it's still building on xenial, which is an issue for me), but I didn't find any option
[11:45] <popey> it doesnt have to be building on xenial
[11:45] <popey> you can pick in your repo what it builds on
[11:46] <didrocks> on build.snapcraft.io?
[11:46] <popey> no, launchpad
[11:46] <popey> I dont use build, because i need the flexibility launchpad offers
[11:46] <didrocks> ah yeah, for this, sure :)
[11:46] <popey> build isn't supposed to cover every use case.
[11:46] <didrocks> "build does do daily builds now AIUI" -> you meant launchpad or build.snapcraft.io?
[11:47]  * cachio afk
[11:47] <popey> build
[11:48] <didrocks> ok ;) so yeah, I have to use launchpad and having a ping script (like lp-build-snap) seems necessary
[11:48] <didrocks> thanks popey ;)
[11:48] <popey> np
[11:50] <mup> PR snapd#5037 closed: snap: snap.AppInfo is now a fmt.Stringer <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5037>
[11:58] <mborzecki> finishing up with spread test
[11:59] <cjwatson> didrocks: the above all seems correct.
[12:00] <didrocks> thx for confirming cjwatson
[12:04] <mborzecki> off to pick up the kids, coming back for standup
[12:15] <zyga> jdstrand: some more leak findings on the forum
[12:15] <mup> PR snapd#5040 opened: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5040>
[12:19] <zyga> mvo: I have to break now and go to the vet but I can propose a simple tweak to apparmor backend to limit memory usage
[12:26] <mup> PR snapd#5041 opened: interfaces/apparmor: don't reload unchanged profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/5041>
[12:26] <zyga> mvo: hey
[12:26] <zyga> mvo: can you run adt tests against that PR somehow?
[12:26] <zyga> I need to break now and go to the vet or I will miss my time
[12:27] <zyga> I will resume my analysis later today,
[12:30] <mvo> zyga: yeah, I can
[12:30] <zyga> thanks
[12:30] <zyga> I'll go now, I'll be on telegram/irc on the phone though
[12:38]  * kalikiana lunch
[12:42] <diddledan> popey: for atom, in snapcrafters, there's a new release upstream (a point release: x.y.1) do I just need to trigger a manual build in the build service to get it to update?
[12:42] <diddledan> alternatively, Wimpress ^^^^
[12:42] <Wimpress> Yep
[12:44] <diddledan> aww, it says I don't have admin perms on the github repo so I can't trigger it :-(
[12:51] <zyga> mvo: standup postponed by one hour, right?
[12:52] <pedronis> mvo: I proposed a chain of PR,   John reviewed them, we need to decide a bit what to do with them (whether we care more to understand the bug vs preventing it)
[12:52] <pedronis> it's also rare afawk
[12:54] <mvo> pedronis: I have a look, thank you and Chipaca
[12:55] <pedronis> mvo: I also tried to play with remove/install while keeping the old mount in use, but seems to just work
[12:55] <pedronis> at least here
[12:57] <mvo> zyga: standup is in 3min
[12:57] <mvo> mborzecki: I think I figured the refresh-mode issue out
[12:57] <mborzecki> mvo: what was it?
[12:57] <zyga> mvo: Gustavo asked to postpone
[12:58] <mvo> zyga: oh, ok, sorry, I miseed that
[12:58] <mvo> zyga: in this case, sure
[12:58] <pedronis> by 1h
[12:58] <mvo> mborzecki: we need KillMode=process in the service file for the non -all signal because it looks like system cleans up the whole cgroup if the main pid dies otherwise
[12:59] <mvo> mborzecki: which makes sense
[12:59] <mvo> mborzecki: I changed the test a bit and added some code to do this and *hopefully* this fixes this
[13:00] <mborzecki> mvo: a maze of manpages
[13:00] <mvo> mborzecki: I looked at the source :)
[13:00] <mvo> mborzecki: but yeah, its a bit difficult to get the picture
[13:00] <mvo> mborzecki: I may still miss pieces but it all makes some sense now
[13:00]  * mvo is a happy camper again
[13:00] <pedronis> it's a maze of non-orthogonal settings
[13:01] <pedronis> btw it does make sense
[13:01] <pedronis> :/
[13:01] <mborzecki> mvo: does ssytemctl stop work correctly still?
[13:02] <pedronis> probably not
[13:04] <pedronis> we need to specify --kill-who=all then?
[13:04] <pedronis> for when is not just a refresh
[13:05] <pedronis> but that's the default
[13:06] <pedronis> mborzecki: my reading is that stop will kill all processes one by one, instead of killing the cgroup
[13:06] <pedronis> (I haven't tried)
[13:09] <mvo> mborzecki: looking now, sorry for the delay
[13:09] <mvo> pedronis: yeah
[13:13]  * pedronis needs a break
[13:15] <mborzecki> there's a problem with snapd.wakeup.service on fedora, it's disabled by systemd presets, explicitly enabling it will probably make Son_Goku unhappy
[13:15] <mborzecki> and fedora has presets
[13:15] <Son_Goku> it needs to be requested to be enabled via central presets
[13:15] <mborzecki> opensuse has none?
[13:16] <mborzecki> Son_Goku: bz ticket then?
[13:16] <Son_Goku> yep
[13:16] <Son_Goku> openSUSE has central presets too
[13:25] <popey> diddledan: thanks for the ping - I triggered a build
[13:25] <pedronis> mborzecki: can't we do it only on ubuntu, and keep the other distros as is for now
[13:25] <diddledan> thankyou popey
[13:26] <mborzecki> pedronis: yeah, i'm afraid that's what we'll have to do
[13:28] <mvo> mborzecki, pedronis you are right about the "stop", with KillMode=process the refresh mode works like we want it to work (yay) but the side-effect of course is that "systemctl stop service-that-uses-refresh-mode-sig{term,hup,..}" also only stops the main process
[13:28] <mborzecki> omg
[13:28] <mborzecki> mvo: mixed?
[13:30] <mvo> mborzecki: oh
[13:30] <mvo> mborzecki: let me try that
[13:36] <pedronis> mvo: btw, how did the autopkgtests in xenial go?
[13:36] <mvo> pedronis: it died in interfaces-many but I try again without this one, this test is especially problematic
[13:37] <pedronis> ok, but at least unblocked
[13:37] <pedronis> thx
[13:37] <mvo> pedronis: well, not sure yet if unblocked or not, I had to restart
[13:37] <pedronis> well, it's no worse than bionic
[13:38] <pedronis> something runs :)
[13:38]  * pedronis is about the small victories these days
[13:38] <mvo> pedronis: heh, yeah
[13:39] <mvo> mborzecki: test with mixed running now :)
[13:40] <greyback> kalikiana: hey, snapcraft stuck at "Preparing to build desktop-gtk3" for me, using 100% of a cpu. How could I track down what's wrong?
[13:40] <mvo> mborzecki: the way I read it I don't have high hopes *but* I was wrong before!
[13:41] <mborzecki> mvo: aiui if the main process ignores sigterm kill is tried again, but this time everyone gets sigkill
[13:42] <mvo> cachio: how is the sru validation going? any fires there?
[13:42] <mvo> mborzecki: oh, that would be what we want I think. if the main process dies the rest is ignored if it does not die/restart the entire group is killed
[13:43] <cachio> mvo, hey
[13:43] <cachio> I finished it
[13:43] <mvo> cachio: yay, any issues?
[13:43] <mvo> mborzecki: the answer is just a spread run (and some patience) away :-D
[13:43] <cachio> mvo, but I saw the oom on autopackgtests for i386
[13:44] <mborzecki> mvo: patience is key today
[13:44] <cachio> for artful and bionic
[13:44] <zyga> mvo: hey, just checking about that auto package test in my PR
[13:44] <zyga> Is it triggered, I cannot see that on the pull request page
[13:44] <cachio> mvo, that's the only relevant issue
[13:44] <cachio> mvo, I think it is because of the environment
[13:46] <jbicha> hi, somehow my gnome-characters snap got disconnected from the gnome-3-26-1604 snap. I'm on bionic and it used to work. I'm using stable channels for this stuff
[13:46] <jbicha> how can I figure out how this happened?
[13:47] <mvo> cachio: yeah, the oom is what we also see everywhere its a sad and known issue
[13:47] <cachio> the rest is
[13:47] <cachio> ok
[13:48] <cachio> mvo, well known issues on autopckgtests
[13:48] <mvo> cachio: great, I think we can document that in the bug and then move on and set it to validated
[13:48] <mvo> cachio: are there more known issue that need addressing?
[13:48] <cachio> yes
[13:48] <cachio> mvo, just that the tests on xenial are not being executed because spread cannot be built
[13:48] <mvo> mborzecki: mixed did not work the way we want it to work, it did kill the children
[13:49] <mvo> cachio: spread is fixed now
[13:49] <mvo> cachio: since last night :)
[13:49] <mvo> cachio: gustavo applied my fix (yay)
[13:49] <cachio> mvo, great
[13:49] <cachio> mvo, ok, but it failed for the sru :(
[13:49] <mvo> zyga: tests are running, I had to restart because it died in interfaces-many?
[13:50] <mvo> cachio: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd <- xenial is mostly green again
[13:50] <jbicha> hmm, gnome-characters worked after restarting my computer 😦
[13:50] <mvo> cachio: I manually restarted some
[13:50] <cachio> mvo, nice
[13:50] <cachio> thankis
[13:51] <mvo> zyga: interfaces-many is a bit of a beast, I disabled that (and it is already disabled for autopkgtest)
[13:51] <mvo> zyga: so if the run survives the remaining tests, that would be huge
[13:51] <mvo> zyga: its at 17/224 right now
[13:51] <zyga>  Thanks
[13:52] <greyback> kalikiana: ignore me, seems it was doing legitimate work
[13:55] <mup> PR snapd#5042 opened: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5042>
[14:00] <cachio> mvo, sru in lp updated
[14:08]  * kalikiana totally ignores greyback and walks away again
[14:12] <greyback> kalikiana: I'm trying to use cleanbuild, where my part has its source in a directory elsewhere in the system. It builds ok with dirty build, but with cleanbuild it complains it cannot determine the source type - and I see no source type specifier for a directory
[14:12] <greyback> any ideas?
[14:18] <kenvandine> jbicha, so it resolved itself on reboot?
[14:18] <jbicha> kenvandine: yes
[14:18] <kenvandine> :/
[14:21] <kalikiana> greyback: elsewhere meaning outside of the source tree? is it a folder?
[14:21] <greyback> kalikiana: correct, and yes
[14:21] <kalikiana> greyback: so how do you get the folder into the container?
[14:22] <greyback> kalikiana: I'm not, hence the problem.
[14:29] <kalikiana> greyback: Can you manually copy it to the tree? Well, or if that's not an option, you could... use a persistent container that you've prepared beforehand.
[14:29] <greyback> kalikiana: I'm doing option 2.
[14:30] <greyback> kalikiana: I'll log a bug tho
[14:34] <kalikiana> greyback: Okay.
[14:34] <greyback> kalikiana: https://bugs.launchpad.net/snapcraft/+bug/1763394
[14:34] <mup> Bug #1763394: cleanbuild gets confused with directory source type <Snapcraft:New> <https://launchpad.net/bugs/1763394>
[14:39] <kalikiana> Thanks!
[14:54] <Chipaca> hah, browser crashed
[14:54] <Chipaca> and now y'all're gone
[14:54] <pedronis> mvo: about my PRs, the easiest is probably to squash merge #5040 with everything (so it's easier to backport for the SRU)  but I can wait for that, as you prefer
[14:54] <mup> PR #5040: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5040>
[14:55] <mvo> pedronis: yeah, otoh, its just three commits so we can just backport those via three cherry-picks (hopefully not too many conflicts)
[14:56] <pedronis> mvo: as your prefer
[14:56] <pedronis> you I merge them today? or wait a bit?
[14:56] <pedronis> sorry
[14:57] <pedronis> mvo: should I merge them today or wait a bit?
[14:57] <mup> PR snapd#5042 closed: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5042>
[14:59] <pedronis> mvo: I marked them blocked for now, let me know
[14:59] <mvo> zyga: adt run died with oom in 153/224, sorry for that
[15:00] <mvo> pedronis: either is fine, its edge so feel free to merge and we can backport at our leisure
[15:02] <pedronis> mvo: I think I'll merge them tomorrow,  I need to EOD in a bit to go to some event
[15:02] <pedronis> for some of my evening
[15:03] <pstolowski> zyga: one question to 5401
[15:05] <mvo> pedronis: sure, enjoy
[15:05] <mvo> pedronis: its not urgent
[15:05] <pedronis> mvo: I don't think we have fires not under control at this point,  I can be pinged on TG if needed
[15:08] <jdstrand> zyga: thanks for those patches! nothing silly about typo fixes :)
[15:16] <mvo> pedronis: yeah, thanks for all the fires you extinguished! have a great evening
[15:22] <zyga> pstolowski: ack, looking
[15:26] <zyga> pstolowski: replied
[15:26] <zyga> mvo: do you have an URL to the test results?
[15:27] <pstolowski> zyga: thanks!
[15:27] <mvo> zyga: I ran it locally
[15:27] <zyga> ah
[15:27] <zyga> and? :-)
[15:27] <mvo> zyga: its easy to reproduce, just use the ubuntu-18.04-32 image
[15:27] <mvo> zyga: it died at test 153 or so :(
[15:27] <zyga> :/
[15:27] <mvo> zyga: what kind of data do you want?
[15:28] <zyga> crap, same way as before, right?
[15:28] <zyga> mvo: I wanted a pass/fail status, I got that
[15:28] <mvo> zyga: yeah, *maybe* it survived longer
[15:28] <mvo> zyga: but its hard to say as the pattern is not consistent, I would have to run with the same -seed= setting once with the branch and once without
[15:28] <zyga> I will do more checks at home, I need to write a small automatic program that triggers the bug and checks that memory is leaking
[15:29] <zyga> then try all the kernels gustavo suggested
[15:29] <mvo> zyga: cool, thanks
[15:32] <popey> diddledan: atom now in stable, thanks for the nudge
[15:46]  * zyga is starving, having feed the dog I need to eat something myself
[16:17] <mup> PR snapd#5043 opened: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043>
[16:18] <mup> PR snapcraft#2061 closed: go: only use Go build package if not using the snap <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2061>
[16:23] <mvo> Chipaca: 5043 might also be interessting for you, I think it is really as simple as this, when systemd sees the main-pid die it goes into stop-state which triggers the cleanups. but double checking is certainly appreciated
[16:24]  * kalikiana eod, o/
[16:50] <suebt> zyga: hey there :]
[16:56] <zyga> suebt: hi
[16:56] <Chipaca> mvo: what happens in 5043 if start-refresh-mode-sigterm tries a little harder?
[16:56] <zyga> I’m busy now, sorry, no change yet. I’ll tell you what I know back home
[16:57] <suebt> zyga: Okay, no problem, will hang around for a while, thank you
[16:59] <zyga> Sorry for keeping you waiting. It is a busy day
[17:00] <Chipaca> mvo: i mean, something like 'setsid nohup sleep' instead of just sleep :-)
[17:24] <mup> PR snapcraft#2066 opened: errors: feature flag error reports <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2066>
[17:29] <nacc> is there possibly a bug in snapd that let's older snaps get unmounted when they are in use?
[17:29] <nacc> :)
[17:29] <nacc> *older snap revisions
[17:29] <nacc> specifically, i've got a long-running app from a snap in the edge channel, which is building from master
[17:29] <nacc> it was at r409, now at r418
[17:30] <nacc> the r409 run ended up dying suddenly because it could not find executables in it's squashfs
[17:30] <nacc> i'm guessing because it got unmounted on some update
[17:42] <Chipaca> nacc: we have a bug around long-running processes and refreshes
[17:42] <Chipaca> nacc: basically if an app is running, and the snap gets refreshed, the file descriptors it has are now useless
[17:43] <nacc> Chipaca: yeah
[17:43] <nacc> that's ... seriously bad for us
[17:43] <Chipaca> nacc: it's on the 'fix soon' list, i think it's one of the first things zyga will work on post 18.04
[17:43] <Chipaca> nacc: how so?
[17:44] <nacc> Chipaca: because we are importing Ubuntu source packages using a snap and it crashes
[17:44] <nacc> for 'official' Ubuntu use :)
[17:44] <Chipaca> nacc: you are importing Ubuntu source packages using a snap, and the snap refreshes while the import is happening? Every time?
[17:45] <nacc> Chipaca: the snap *can* refresh while it is happening yes
[17:45] <nacc> not every time, but when it does, this clearly would break things
[17:45] <nacc> so we have an importer, which is short-lived (sort of)
[17:45] <nacc> and control scripts which are long-lived (watching the publisher itself)
[17:45] <nacc> the latter is quite long-lived (one never dies)
[17:45] <Chipaca> nacc: long lived but not a daemon?
[17:45] <nacc> Chipaca: right, not yet
[17:46] <nacc> would a daemon avoid this?
[17:46] <Chipaca> nacc: the daemon would be restarted on refresh (unless you ask not to be, but then presumably you're only using _COMMON
[17:47] <nacc> Chipaca: restarting the daemon is 'bad' for us, sort of too
[17:47] <nacc> Chipaca: hence why it's not a daemon yet :)
[17:47] <Chipaca> nacc: as a short term workaround you can ask snapd to hold off refreshes until you're done
[17:47] <nacc> Chipaca: yeah, i might need to do that, quick syntax/cli?
[17:48] <Chipaca> nacc: ach, i always get that one wrong
[17:48] <nacc> :)
[17:48] <Chipaca> it's 'snap set <something something>'
[17:48] <Chipaca> :-)
[17:48] <Chipaca> mvo knows -- and it should be documented
[17:49] <Chipaca> and I've got to go make dinner
[17:49] <nacc> Chipaca: np, i'll look it up
[17:50] <nacc> https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/6 i think
[17:51] <Chipaca> nacc: snap set core refresh.hold=<when>
[17:51] <Chipaca> nacc: some work to be done around the UX of it though
[17:52] <mup> Issue snapcraft#2033 closed: LP: #1752344 <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2033>
[17:52] <mup> PR snapcraft#2065 closed: many: update the yaml loading logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2065>
[17:52] <nacc> Chipaca: thanks
[17:52] <Chipaca> nacc: it requires a timestamp (the error will show you the format)
[17:52] <nacc> Chipaca: ok :)
[17:52] <Chipaca> nacc: but the expectation is that a script or something would say "give me 5 minutes" every 5 minutes until it was done
[17:53] <Chipaca> hence, ux needs more work (or maybe an interface that isn't 'snap set')
[17:53] <Chipaca> anyhoo. dinner.
[17:53] <zyga> nacc: refresh sanity is on my plate post 18.04
[17:53] <zyga> Is the bug related to an apparmor denial?
[17:54] <nacc> zyga: Chipaca: thanks, i was able to set it to be at least a week away
[17:54] <nacc> zyga: is that to me?
[17:54] <zyga> Yes
[17:54] <nacc> zyga: no apparmor denials in dmesg
[17:54] <zyga> About refresh breaking some source import
[17:54] <nacc> zyga: it just failed to find the `git` binary that was in the snap
[17:54] <zyga> Can you let me know what is the problem?
[17:54] <nacc> because, i'm guessing, the fd was closed underneath it
[17:54] <zyga> Hmmm
[17:55] <Chipaca> o/
[17:55] <zyga> It would not be closed
[17:55] <zyga> But can be revalidated
[17:55] <zyga> But that would log a denial
[17:55] <zyga> Can you give me a link to a case that reproduces the issue
[17:55] <nacc> zyga: i don't have the logs handy anymore, but i can try and scrape them (about to leave though) -- basically our snap was running (git-ubuntu.source-package-walker) ... and it ran for some time
[17:55] <nacc> at an older review
[17:55] <nacc> *revision
[17:56] <zyga> Including a refresh to another channel in a side terminal is ok if that helps
[17:56] <nacc> we then refreshed (auto) edge from which we're running
[17:56] <zyga> Is that snap classic or strict?
[17:56] <nacc> at some point, we must have gotten past the 'keep 2 versions' or whatever snapd does
[17:56] <nacc> classic
[17:56] <nacc> and our snap crashes becasue it's unable to find an executable that is in the snap
[17:56] <zyga> Hmmm
[17:56] <nacc> i believe with a 'no such file or directory'
[17:56] <zyga> Classic snaps have no constraints
[17:57] <zyga> So it is probably another part
[17:57] <zyga> Thanks
[17:57] <zyga> I know what I needed now
[17:57] <zyga> Right, I understand why this happens
[17:57] <nacc> confirmed i got a no such file or directory for 'git' in our case (which we build from source and is in our snap's path)
[17:58] <nacc> zyga: ok :)
[17:58] <zyga> Thank you
[17:58] <nacc> zyga: we admittedly are a weird classic snap -- we are basically confined (by munging the environment) but we need to be able to write anywhere on the fs
[18:06] <zyga> re
[18:06] <zyga> nacc: classic snaps are confined but have wide open permissions and are not sealed in a mount namespace
[18:07] <nacc> zyga: yeah i know
[18:07] <nacc> well the former part is why :)
[18:07] <nacc> *why we use a classic snap
[18:08] <zyga> to have access to /var/lib/snapd/hostfs easily?
[18:08] <zyga> (as in, at /)
[18:08] <nacc> zyga: yeah basically (and network)
[18:08] <nacc> but network obviously we could use an interface for
[18:08] <nacc> last i checked there was not a 'hostfs' interface
[18:08] <zyga> network?
[18:08] <zyga> network should not be a problem
[18:09] <zyga> we could add an interface for hostfs and hand it out just like classic
[18:09] <zyga> if that helps
[18:09] <nacc> zyga: that would probably help us, yes
[18:09] <nacc> not sure if we have other needs, but that woudl be my guess right now
[18:09] <nacc> zyga: gotta go afk for a bit
[18:10] <zyga> thanks, no worries :)
[18:10]  * zyga is still at school, waiting to talk to the teacher
[18:20]  * zyga is very sleepy somehow
[18:46] <mup> PR snapcraft#2067 opened: many: add snapcraftctl set-grade <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2067>
[18:49]  * zyga returns for evening hacking
[18:56] <zyga> jdstrand: hey, can you please look at https://github.com/snapcore/snapd/pull/5041 and specifically at the question from pawel as well as my response there
[18:56] <mup> PR #5041: interfaces/apparmor: don't reload unchanged profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/5041>
[18:59] <zyga> jdstrand: I'm mainly trying to raise any red flags that you may notice
[19:02]  * cachio afk
[19:40] <mup> PR snapcraft#2068 opened: states: track override scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2068>
[21:02] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[21:03] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[21:03] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[21:05] <jjohansen> zyga, mvo: with your testing you are only seeing this with the bionic kernel?
[21:35] <mup> Issue snapcraft#1681 closed: Design/document support for architecture selection during builds <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1681>