[05:54] <mborzecki> morning
[06:48] <mup> PR snapd#4699 closed: cmd/snap: tweaks to 'snap info' output <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4699>
[06:49] <mborzecki> mvo: morning
[06:49] <mup> PR snapd#4689 closed: tests: new spread test for kvm interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4689>
[06:51] <mvo> hey mborzecki ! good morning
[06:52] <mup> PR snapd#4686 closed: daemon: make the ast-inspecting test smarter; drop 'exceptions' <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4686>
[06:58] <mup> PR snapd#4617 closed: many: implement "refresh-mode: {restart,endure,...}" for services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4617>
[07:08] <mborzecki> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1746710 is this something calling xdg-user-dirs-update with incorrect locale?
[07:08] <mup> Bug #1746710: Snap creates redundant duplicate directories in home folder <amd64> <apport-bug> <artful> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1746710>
[07:10] <zyga> good morning
[07:10] <mborzecki> zyga: morning
[07:11]  * zyga feels sick today, I'll be off for at least half the day
[07:11] <zyga> sorry guys
[07:11] <mborzecki> zyga: get some rest
[07:11] <zyga> I'll try to work in a few hours after some meds take effect
[07:13] <mvo> hey zyga
[07:13] <mvo> zyga: uh, yeah, get well!
[07:29] <mborzecki> mvo: any idea why this test would randomly fail? https://paste.ubuntu.com/p/zSH48GPxp6/
[07:30] <mborzecki> mvo: last i've seen it fail on #4702, restarted the build and it's green now
[07:30] <mup> PR #4702: cmd/snap: also include tracking channel in list output <Created by chipaca> <https://github.com/snapcore/snapd/pull/4702>
[07:30] <mborzecki> mvo: this one in particular failed on debian-9
[07:37] <mvo> mborzecki: I assume this is randomly failing? or conistently?
[07:38] <mborzecki> mvo: randomly
[07:38] <mvo> mborzecki: it
[07:38] <mvo> mborzecki: ups
[07:38] <mvo> mborzecki: did that start recently? there was a branch to move to EnsureDirState() for this file recently by zyga
[07:38] <mvo> I wonder if it that is related
[07:39] <mborzecki> i don't recall exactly when it started to fail
[07:39] <mborzecki> seen it a couple of times and it enede in my to-investigate list
[07:42] <mvo> mborzecki: whats your feeling time wise? a couple of days or more than that? iirc the ensuredirstate thing landed only mid last week
[07:43] <mborzecki> mvo: days, might as well be that change
[07:59] <kalikiana> sliff
[08:07] <Chipaca> moin moin
[08:08] <mborzecki> Chipaca: kalikiana: morning guys
[08:08] <Chipaca> just popping in for a minute before doing the morning school run
[08:08] <Chipaca> what was up with the failing apparmor test on debian?
[08:09] <mborzecki> Chipaca: https://paste.ubuntu.com/p/zSH48GPxp6/ it's gone after i restarted the job
[08:09] <Chipaca> huh
[08:09] <mborzecki> pstolowski: morning
[08:09] <pstolowski> morning!
[08:09] <Chipaca> pstolowski: o/ :-)
[08:09] <Chipaca> mborzecki: good call on those changes, i'll do them when i get back
[08:46] <mup> Issue snapcraft#1939 closed: rust plugin: i386 multiarch linker error  <Created by General-Beck> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1939>
[08:49] <mborzecki> mvo: i can reproduce the failure locally
[08:49] <mvo> mborzecki: oh, nice!
[08:58] <mvo> Chipaca: https://pad.ubuntu.com/dcABWlRGY9 are some notes about the c-n-f work, let me know what you think and where it is too terse
[09:03] <zyga> re
[09:04] <zyga> how are things
[09:12] <Chipaca> mvo: on it
[09:12] <Chipaca> mborzecki: when you say you'd rather the if directly next to the for, you just mean remove the interleaving comment and move the comments into the if/for?
[09:14] <mborzecki> Chipaca: haha, don't know what i was thinking about when writihg this comment, what i meant is that you could swap the order of if/for blocks, so that the for comes first
[09:15] <Chipaca> mborzecki: reason for having it earlier is that it's a quicker check
[09:16] <Chipaca> feels silly to put quick checks after the slow one
[09:18] <mborzecki> Chipaca: hm so maybe you meant to return in the `if idx2 := strings.IndexByte(rest, '/'); idx2 >= 0` block?
[09:19] <Chipaca> gah
[09:19] <Chipaca> mborzecki: ignore me, i shouldn't be allowed to look at code this early
[09:20] <Chipaca> of course there's no return so the order is unimportant
[09:31] <mborzecki> mvo: haha, yeah, that bug is random surely, we're replacing core snap revision in a string like this tmp.check-1114575628337396084.0.var.lib.snapd.snap.core.111.usr.lib.snapd.snap-confine with simple .Replace(..., "111", 1), this ends up replacing the first '111' that appears, producing glob: tmp.check-*4575628337396084.0.var.lib.snapd.snap.core.111.usr.lib.snapd.snap-confine
[09:31] <zyga_> mborzecki oooh
[09:31] <mborzecki> good thing is it will go away once we wait long enough
[09:31] <zyga_> sorry, my bad!
[09:31] <mborzecki> will open a PR shorty :)
[09:31] <zyga_> thank you for tracing this and working on a fix
[09:32] <mvo> mborzecki: haha, nice bug
[09:38] <pedronis> mvo: hi, I think once pstolowski auto-connect branch goes in, #4103 will need changes, but the hard problem should not be there anymore either
[09:38] <mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
[09:39] <pedronis> mvo: we can talk about it when you want
[09:40] <mvo> pedronis: oh, that sounds great. I was just picking up this PR again
[09:40] <mvo> pedronis: when is a good time for you? in ~30min maybe?
[09:40] <pedronis> yea
[09:42] <mup> PR snapd#4703 opened: interfaces/apparmor: use snap revision with surrounding '.' when replacing in glob <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4703>
[09:42] <mborzecki> zyga_: ^^
[09:42] <pstolowski> pedronis, thanks for the review btw, i've just finished addressing your last comment and added some more tests; do you want
[09:42] <zyga_> ack
[09:42] <pstolowski> pedronis, do you want to take another look or can I merge when green?
[09:43] <pedronis> pstolowski: mmh, I just noticed something,  it's not a bug in the new code, the old code would behave the same I think, maybe you want to pop in that chat with mvo in a bit?
[09:44] <pstolowski> pedronis, sure
[09:44] <pedronis> pstolowski: it's related to the managers_test fwiw
[09:45]  * kalikiana moving to coffee shop
[09:57] <mborzecki> anyone wants to take a look at #4676?
[09:57] <mup> PR #4676: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4676>
[09:58] <mup> PR snapd#4049 closed: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4049>
[10:02] <pstolowski> mborzecki, yes, looking at it atm
[10:03] <mborzecki> pstolowski: thanks
[10:04] <mvo> pedronis, pstolowski I am in the hangout channel now, ready when you are (not exactly 30min yet so no worries)
[10:05] <pstolowski> k
[10:09] <mup> PR snapd#4703 closed: interfaces/apparmor: use snap revision with surrounding '.' when replacing in glob <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4703>
[10:24] <Chipaca> mborzecki: i think fmtChannel is a lot nicer thanks to your feedback, now
[10:33] <pedronis> pstolowski: the ErrNoState change seems wrongly placed
[10:33] <pstolowski> hmm
[10:33] <pedronis> we still want to return err if it's not ErrNoState
[10:33] <pedronis> pstolowski: I left a comment
[10:33] <pedronis> sorry
[10:33] <pstolowski> ah
[10:47] <pedronis> pstolowski: thank you for working through this, once it is green it can land
[10:48] <pstolowski> pedronis, cool. thanks again for great reviews and spotting all these issues!
[10:58] <Chipaca> niemeyer: are you here?
[11:00] <niemeyer> Chipaca: Heya
[11:07] <Chipaca> niemeyer: oh!
[11:07] <Chipaca> mvo: he's here now, we could continue this right now
[11:07]  * Chipaca can go to physio after the standup
[11:07] <mvo> Chipaca: sure, I can if you want
[11:07] <mvo> Chipaca: whatever is more convenient for you
[11:07] <Chipaca> niemeyer: can you hangout?
[11:08]  * Chipaca pops back onto the standup
[11:08] <zyga_> what are you chatting about?
[11:08] <mvo> zyga: c-n-f
[11:08] <zyga> ah, interesting
[11:08] <zyga> well, I'm in mount-land and I feel like <unicode poo> so I'll skip
[11:08] <zyga> sorry guys, barely holding up here
[11:08]  * Chipaca hugs zyga 
[11:08] <mvo> zyga: thats fine
[11:08] <zyga> good luck guys
[11:09] <Chipaca> zyga: take a break, take a walk
[11:09] <zyga> Chipaca I just got out of bed, I want to do stuff as otherwise I'll just sleep
[11:10] <niemeyer> Chipaca, mvo: Yeah, omw
[11:10] <Chipaca> zyga: taking a walk fixes that as well
[11:11] <zyga> I think it's too cold now, it's been a windy and outdoory weekend for me and I guess this is why I feel like this now
[11:17] <pstolowski> mborzecki, reviewed 4676
[11:19] <thresh> hello
[11:20] <thresh> I'm struggling with theming issues on VLC snap;  It only seems to work under Unity, and GNOME shell, KDE, and MATE seem to show non-themed windows95-like UI.  We're using Qt5 from xenial-updates.
[11:20] <mborzecki> pstolowski: thanks a lot :)
[11:21] <thresh> I've tried editing desktop-launch, to remove QT_QPA_PLATFORMTHEME=appmenu-qt5 and QT_QPA_PLATFORM=xcb from it, and now on KDE the Qt theme is picked up, but no icons show up at all.  It also does not fix the issue on gnome shell.
[11:22] <thresh> Is there anything I forgot to include to the snap?  Maybe some deps which provide theming are not staged?   Here's the snapcraft.yaml: git.videolan.org/?p=vlc.git;a=blob;f=extras/package/snap/snapcraft.yaml
[11:27] <popey> thresh: heya. I think this is a known issue which will be resolved as part of the work on 'layouts'. I believe zyga owns this?
[11:28] <zyga> hey
[11:28] <zyga> theme support?
[11:28] <popey> Making it so desktop applications don't look out of place on other desktops.
[11:28] <zyga> I think this is not strictly related to layouts but close; I believe the desktop theme is working on that
[11:28] <zyga> I'm not actively involved anymore as the part I was working on (mechanics to make that possible) is ready now
[11:28] <thresh> hey popey
[11:29] <popey> I believe jamesh has a branch which is needed in the desktop helpers, but that's blocked on layouts AIUI
[11:29] <popey> zyga: when will it land?
[11:29] <zyga> popey my part has landed in 2.31
[11:29] <zyga> I don't know what's the progress of the desktop team to use this
[11:29] <zyga> seb128 ^ do you know anything about theme support work?
[11:31] <zyga> https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510 has some info
[11:31] <zyga> popey I believe themes are now possible
[11:31] <zyga> and I'm working on user mounts
[11:32] <pstolowski> mvo, hey, a weird failure in just one test/machine - https://api.travis-ci.org/v3/job/343305881/log.txt - snap-userd-reexec test, have you seen that before?
[11:32] <popey> I will drop jamesh a mail to see where we are (for when he wakes) (thresh, james is in nz), and get back to thresh once I know more.
[11:32] <thresh> sweet popey
[11:33] <pstolowski> mvo, looks like unexpected diff when checking /usr/share/dbus-1/services/io.snapcraft.Launcher.service
[11:33] <thresh> thanks!
[11:33] <pedronis> zyga: what's the status of #4644
[11:33] <mup> PR #4644: tests: add a spread test for layouts <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4644>
[11:33] <zyga> pedronis on my backlog,
[11:33] <zyga> pedronis I think I know what to do now but I need to discuss this with mvo
[11:35] <pedronis> ok
[11:37] <mup> PR snapcraft#1938 closed: tests: improvements to demos <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1938>
[11:38] <seb128> zyga, not more than what is in the forum
[11:47] <mup> PR snapcraft#1940 opened: tests: remove the webcam-webui demo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1940>
[11:52]  * cachio afk
[12:14] <mvo> pstolowski: in a meeting right now
[12:14] <mvo> pstolowski: the error seems to be "Job for snapd.socket canceled." ?
[12:28]  * zyga shivers
[12:30] <pstolowski> mvo, gosh, the log got overwritten as I restarted the job. it was different issue before
[12:42] <mup> PR snapd#4702 closed: cmd/snap: also include tracking channel in list output <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4702>
[12:56] <mvo> pstolowski: aha, ok.
[13:02] <mup> PR snapcraft#1941 opened: project_loader: handle invalid unicode chars <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1941>
[13:34]  * kalikiana lunch
[13:36] <zyga> mvo are bionic adt tests running against proposed?
[13:36] <mvo> zyga: yes
[13:36] <mvo> zyga: I run them locally now again to see if that helps
[13:36] <zyga> because bionic still has an artful kernel
[13:36] <zyga> I'm looking at that now
[13:36] <mvo> zyga: I like your idea about the secocmp things
[13:36] <zyga> (kernel)
[13:37] <mvo> zyga: maybe I was unfairly blaiming adt!
[13:44] <zyga> mvo I suck at finding the source package for 4.15 in bionic
[13:44] <zyga> and at getting a useful changelog
[13:44] <zyga> or configuration
[14:00] <pedronis> mvo: fighting a bit to have clean tests but should have my UserAgent for snap repair PR soonish
[14:01] <mvo> pedronis: great, thank you. no worries, I'm wrestling with autopkgtest right now anyway so I'm not blocked
[14:01]  * zyga gets more meds, brb
[14:10] <mup> PR snapd#4401 closed: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4401>
[14:10] <pstolowski> mvo, pedronis ^ autoconnect changes landed
[14:11] <mborzecki> yay !!
[14:11] <pstolowski> yay indeed, i hope to see the same re interface-hooks soon :}
[14:13] <mvo> pstolowski: nice!
[14:13] <pedronis> pstolowski: \o/
[14:16] <mup> PR snapd#4704 opened: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <https://github.com/snapcore/snapd/pull/4704>
[14:16] <pedronis> mvo: a strange formatting in vendor.json has landed on master:  https://github.com/snapcore/snapd/blob/master/vendor/vendor.json#L77
[14:17] <Chipaca> mborzecki: https://www.youtube.com/watch?v=rzKaOp383vA
[14:18]  * Chipaca forgot to press enter half an hour ago
[14:18] <mborzecki> haha
[14:18] <mborzecki> right, looks relaxed :)
[14:18] <mborzecki> Chipaca: https://www.youtube.com/watch?v=3QiGuXETYnQ
[14:18] <thresh> popey, huh;  I've used KDE Neon repos with their version of Qt5 -- and VLC looknfeel on Kubuntu 17.10 is great now;  I'm going to do more testing now.
[14:19] <popey> Yeah, it looks great on KDE Neon 16.04 here too.
[14:19] <popey> (the version in stable)
[14:19] <thresh> I mean I used kde neon repos to stage & build packages :)  Testing on the same kubuntu 17.10 to run it..
[14:20] <popey> ahh
[14:20] <thresh> it's weird that you have it working nicely on Neon @ 16.04
[14:20] <thresh> it's not supposed to :]
[14:20] <popey> Pretty sure the screenshot i put in the @ubuntu social post came from my kde laptop
[14:20] <mvo> pedronis: autsch, probably my fault while resolving a conflict
[14:20] <mup> PR snapd#4705 opened: set snap-repair User-Agent on requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4705>
[14:20] <thresh> that probably means my snap is not exactly contained?
[14:20] <mup> PR snapcraft#1940 closed: tests: remove the webcam-webui demo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1940>
[14:21] <pedronis> mvo: proposed 4705
[14:21] <pedronis> mvo: do want me to do a PR for vendor.json ?
[14:22] <mvo> pedronis: yeah, please do
[14:24] <Chipaca> thresh: what's your snap?
[14:25] <popey> Chipaca: vlc
[14:25] <mup> PR snapd#4706 opened: vendor: resync formatting of vendor.json <Created by pedronis> <https://github.com/snapcore/snapd/pull/4706>
[14:25] <Chipaca> looks confined here
[14:27] <pedronis> mvo: ^ done
[14:27] <pedronis> mvo: do you needa  cherry pick for 2.31 of 4705 ?
[14:28] <thresh> http://thre.sh/stuff/vlc-snap-kubuntu-neon.png  - the one on the right is the snapped one, the left one is 2.2.6 from the repos
[14:29] <thresh> looks like I'm missing some fonts still
[14:31] <kalikiana> re
[14:31]  * pedronis break
[14:31] <thresh> yeah, solves the looknfeel on Gnome shell as well
[14:31] <thresh> let's try mate
[14:32] <ogra_> what is really awesome about the vlc snap is that it comes with full vaapi support ... i can actually run fully accelerated video playback on 16.04 with it where vaapi in the repo isnt properly working...
[14:33] <ogra_> popey, ^^^ we should probably do some promotion around that fact ;)
[14:34] <popey> It was quite a challenge to get that working!
[14:34] <niemeyer> Stepping out for an early lunch so I can be in a call at the top of the hour.. biab
[14:34] <popey> (on nvidia, amd and intel)
[14:34] <ogra_> and it is soooo awesome !
[14:34] <thresh> yeah, and that's all not my fault :)
[14:34] <cachio> mvo, snap core 2.31 in stable
[14:34] <ogra_> i really love that my laptop fan stays silent if i stream TV
[14:34] <cachio> mvo, smoke test passed
[14:36] <thresh> yep, but that isnt reproduced on Debian stable with nvidia, on gnome shell, it's the same
[14:36] <thresh> oops EWRONGCHAN
[14:37] <thresh> I wonder if I'm supposed to ship all the fonts the users might use?
[14:37] <thresh> it would be pretty tough to handle all weird languages
[14:40] <popey> No, as I understand it layouts can fix fonts too
[14:43] <ahasenack> hi, this doesn't seem right, I have just two revisions of the core snap installed, but many more mountpoints for it: https://pastebin.ubuntu.com/p/7nj4VNrsw5/
[14:44] <ahasenack> this is on xenial, and the machine was rebooted a few minutes ago
[14:45] <mup> PR snapd#4707 opened: Tests interface broadcom asic control <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4707>
[14:47] <kalikiana> Chipaca: your comment on #1941 is confusing me... either I utterly failed at explaining or you're talking about something else than I am. You seem to be suggesting that I am somehow changing validation. I'm not. All this is is an explicit error message. No change in the underlying logic whatsoever.
[14:47] <mup> PR #1941: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1941>
[14:49] <Chipaca> kalikiana: before your change, if you had a 💩  in your description, you'd get a nasty traceback
[14:49] <kalikiana> Yes
[14:49] <Chipaca> kalikiana: with your change you now get an error that says "character foo not allowed in description"
[14:49] <kalikiana> Chipaca: You got that same error together with the traceback before
[14:49] <Chipaca> kalikiana: I'm saying: it's not true that it's not allowed
[14:50] <Chipaca> the yaml parser can't handle it, but it's totally allowed
[14:50] <Chipaca> tell the user that, not that it's not allowed
[14:50] <kalikiana> Hmmm
[14:50] <Chipaca> their 💩 apps can be as 💩-y as they want
[14:51] <kalikiana> Chipaca: They could be, if pyyaml would release a fix...
[14:51] <Chipaca> all the user needs to do, today, without you doing anything, is use a \u escape
[14:51] <Chipaca> or a \U escape if it's not BMP
[14:52] <Chipaca> just saying "not supported (try escaping)" would be more truthful and helpful
[14:52] <Chipaca> that's my point
[14:52] <Chipaca> nothing more
[14:52] <Chipaca> (the 'escape it before loading it' is a lot of work and needs a lot of testing, but you might want to consider it if you have nothing else to do :-D )
[14:55]  * Chipaca -> school run
[14:56] <mvo> cachio: thank you!
[15:03] <mvo> pedronis: no need to cherry pick the vendor.json I think thats only a issue in master
[15:09] <ogra_> mvo, did you see https://forum.snapcraft.io/t/accessing-ttys0-on-raspberry-pi-3-running-ubuntu-core/4096
[15:12] <mvo> ogra_: I have not, let me look (but in a meeting)
[15:16] <pedronis> mvo: I meant the snap-repair fix
[15:16] <ogra_> mvo, no hurry ... minor addition to the config.txt code (one more option)
[15:16] <mvo> pedronis: yes, I will cherry-pick that one
[15:16] <mvo> ogra_: yeah, looks almost trivial
[15:16] <pedronis> mvo: ah, ok
[15:17] <pedronis> mvo: not green yet though
[15:17] <mvo> pedronis: yeah, store was a bit unhappy
[15:18] <pedronis> Chipaca: could you do a 2nd review of #4705, it's small and should be an area you know
[15:18] <mup> PR #4705: cmd/snap-repair,httputil: set snap-repair User-Agent on requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4705>
[15:20] <zyga> is it an US holiday today?
[15:20] <mcphail> yes. presidents day
[15:20] <zyga> ah, thanks
[15:20]  * zyga refrains from joking about it
[15:21] <mcphail> indeed. too painful, i suspect
[15:22] <ogra_> not for non-americans :)
[15:25] <Chipaca> pedronis: +1
[15:33] <cwayne> It's ok, were just celebrating 44/45 Presidents today
[15:37] <mup> PR snapd#4706 closed: vendor: resync formatting of vendor.json <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4706>
[15:40] <zyga> cwayne my thoughts exactly
[15:46] <Chipaca> kalikiana: question, trying to understand this a bit more: why am I able to load the yaml from the bug in python without issues?
[15:49] <kalikiana> Chipaca: I was just asking myself that, but with regard to Travis CI. It seems the Debian package is patched so it behaves different than what's in pip...
[15:49] <Chipaca> ahh
[15:50] <kalikiana> Chipaca: I added a work-around now so the result is what you expect with either version. And no more need for second-guessing error messages now I think
[15:51] <Chipaca> kalikiana: 👍
[15:52]  * cachio lunch
[15:52]  * Chipaca physio
[15:56] <kalikiana> Chipaca: Thanks for your review. I definitely don't consider it noise! :-)
[15:56] <niemeyer> Call is over, and I need to take kid to school.. o/
[16:04] <mvo> zyga: good news (or bad news) - I can reproduce the failure of autopkgtest on i386 - its systemd-udev invoked oom killer (on a 1.5gb machine)
[16:04] <zyga> oh
[16:04] <zyga> could it be caused by our "trigger" usage?
[16:04] <zyga> or a regression in systemd somewhere
[16:05] <zyga> in any case that's not a fun thing to learn
[16:05] <ogra_> trigger shouldnt be able to cause OOM ... after all it just replays uevents in the kernel
[16:06] <mvo> zyga: http://paste.ubuntu.com/p/zJTYQ4SjqX/
[16:06] <mvo> zyga: I have no idea should
[16:07] <zyga> I don't understand those logs out of the blue, not sure what's using memory
[16:07] <zyga> how did you reproduce it?
[16:08] <mvo> zyga: http://paste.ubuntu.com/p/9w5YwCJXP9/ is also interessting
[16:08] <mvo> zyga: yeah, I need to dig into this now and figure out what it means
[16:09] <mvo> zyga: but it really looks like snapd and snap are the outliners in the second paste
[16:09] <zyga> mvo so both snapd and snap use about 200MB/s?
[16:09] <zyga> or is toal_vm just address space and rss is the right thing
[16:09] <mvo> zyga: aiui rss is the working set so closer to the truth
[16:10] <mvo> zyga: but still high on both snapd and snap
[16:17] <mvo> zyga: woah, its really interessting (and hard to debug as it keeps killing the bash I use to ssh into my vm). its related to snap connect, that triggers the oom
[16:17] <zyga> do you have the state? maybe there are some interesting tasks?
[16:19] <zyga> pstolowski did you land the connect hooks?
[16:19] <pstolowski> zyga, no. just autoconnect changes
[16:20] <pstolowski> zyga, made autoconnect handled by tasks
[16:21] <mvo> zyga: I looked at the state size, its just 136k
[16:21] <mvo> zyga: butthe state is now lost, my ssh got killed
[16:21] <zyga> how are you setting that up for tetsing?
[16:21] <zyga> (it's certainly annoying to do)
[16:22] <mvo> zyga: at first I was running autopkgtest, then just pure spread on a ubuntu-18.04-32 image
[16:22] <pstolowski> zyga, is your question related to the issue you're discussing with mvo?
[16:22] <zyga> pstolowski yes
[16:22] <mvo> zyga: and now I try to do it on my regular system (which is -64)
[16:22] <pstolowski> zyga, my changes landed shortly after the standup
[16:23] <mvo> zyga: the usage pattern was ~800mb free mem (according to htop), then "snap connect ..." and my task got killed
[16:23] <mvo> pstolowski: its probably not that (yet)
[16:23] <mvo> pstolowski: because the adt failure is older and shows the same pattern
[16:23] <zyga> mvo not sure if you can, try to set oom score for your shell
[16:23] <mvo> (older as in a couple of days older)
[16:23] <mvo> zyga: yeah, I'm running the spread again
[16:23] <mvo> zyga: its a bit of hit and miss if I get a shell at all :)
[16:42] <mup> PR snapd#4705 closed: cmd/snap-repair,httputil: set snap-repair User-Agent on requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4705>
[16:46] <mvo> thanks pedronis - and its cherry-picked now
[16:47] <pedronis> thank you
[17:04] <andyrock> hey all, regarding logging in snapd during in ubiquity (the installer) the chroot solution will not work. I tried to feed the auth data (something like this https://paste.ubuntu.com/p/sSbKstQ2Sy/) and it seems to work fine
[17:05] <mvo> cachio: where is test-snapd-hello-classic? we will need a build for ppc64el for this one (and probably s390x)
[17:05] <cachio> mvo, let me check
[17:05] <andyrock> any thoughts?
[17:06] <cachio> mvo, I don't have it
[17:06] <cachio> mvo, I don't see it neither in the store nor launchpad
[17:08]  * kalikiana wrapping up for today
[17:09] <cachio> mvo, you don't see it in the store?
[17:10] <mvo> cachio: slightly mysterious it is only there for i386/amd64 - test-snapd-hello-classic
[17:10] <mvo> cachio: I need to have dinner now, not sure where it comes from but we need to make it available for all arches
[17:10] <cachio> mvo, np, could you please share it with me?
[17:11] <cachio> mvo, I'll do the rest
[17:12] <cachio> mvo, I'll push it to launchpad
[17:12] <mvo> mborzecki: do you have a snapcraft.yaml for test-snapd-hello-classic for cachio ?
[17:12] <mborzecki> it should be in the repo
[17:13] <mborzecki> mvo: cachio: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-hello-classic
[17:14] <cachio> mvo, mborzecki I uploaded the snap to launchpad to generate all the snaps for all the arch https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-hello-classic
[17:15] <cachio> mvo, mborzecki could you please share the snap with me in the snap store?
[17:15] <cachio> so I can trigger the build for all the archs
[17:16] <mborzecki> cachio: it was reassigned to the 'canonical' account
[17:16] <cachio> mborzecki, great tx
[17:17] <cachio> it was already shared to me
[17:19] <cachio> mborzecki, mvo builds triggered for arm64 armhf and ppc64el
[17:19] <cachio> snaps will be available in 1 hour aprox
[18:04] <cachio> mvo are you going to send 2.31.1 to beta today?
[18:05] <mvo> cachio: probably not, I need to fix the autopkgtest failures first, without that there is little use in having 2.31.1
[18:06] <mvo> cachio: I'm kill struggling, with that, looks like we need some extra snaps for s390x and ppc64el (that should be fine) and we might need to figure out the interface-many test. it causes a out-of-memory condition
[18:06] <mvo> cachio: I'm checking now if increasing the memory helps, its a bit thorny
[18:07] <mvo> cachio: interfaces-many will fail on bionic on i386 (if you want to reproduce it)
[18:07] <cachio> mvo, ok, just tell me on what I can help you
[18:07] <cachio> mvo, sure
[18:07] <mvo> cachio: you will need https://github.com/snapcore/snapd/pull/4704
[18:07] <mup> PR #4704: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <https://github.com/snapcore/snapd/pull/4704>
[18:07] <cachio> mvo, ok
[18:08] <mvo> cachio: and then just run spread against the one interfaces-many test, this should result in an error and dmesg/journal should show you that it ran out of memory
[18:08] <cachio> ok
[18:08] <mvo> cachio: we probably want to improve spread to set /proc/$$/oom_score_adj to -960 or something to ensure the ssh shell is not killed but that is a PR for later :)
[18:08] <mvo> cachio: if you can find out anything, please do let me know. I'm currently running it with -m 3500 to see if that helps
[18:09] <cachio> mvo, which image are you using?
[18:09] <cachio> the last one?
[18:09] <cachio> 18-Feb?
[18:19] <mvo> cachio: I created a bionic image via autopkgtest-buildvm -r bionic -a i386 and renamed it to ubuntu-16.04-32
[18:19] <cachio> mvo, ok, I'll try that
[18:19] <cachio> }tx
[18:20] <mvo> cachio: thanks, I tried with -m 3500 - kill OOM :/
[18:44] <pedronis> mvo: is snapd using so much memory?
[18:48] <mvo> pedronis: its not quite clear what is triggering this, it might also be something else, kernel or udev, the debug log I have so far is hard to read :/
[18:48] <mvo> pedronis: but at least it is reproducible
[18:48] <pedronis> I would hope is not snapd, unless it's a change in go that triggers the issue
[18:49] <pedronis> I mean no deep reason for memory usage of snapd to change
[18:50] <pedronis> mvo: as usual is also hard I suppose to correlate to what has changed recently in bionic :/
[18:51] <mvo> pedronis: yeah, bionic is very much in flux and we did not run an i386 based test there in a while
[18:51] <mvo> pedronis: maybe cachio can run this test with a 4.13 (artful) kernel to isolate if its that. then the same with systemd (downgrrade that as well). that might give us clues
[18:51] <mvo> pedronis: its definitely not fun
[18:52] <mvo> pedronis: the memory pattern I saw does not look terrible (saw in the journal output). snapd uses quite a bit of memory but nothing like the 1.5gb my VM has. not talking about the 4.5gb I gave it for testing and it would still die. also this works on amd64
[18:53] <mvo> pedronis: and maybe cachio can test using a go1.9 build (and/or all of this I can also try in my morning)
[18:54] <cachio> mvo, pedronis I can try all this this afternoon
[18:55] <mvo> cachio: thank you, keep me updated please :)
[18:55] <cachio> mvo, sure
[19:00] <mvo> cachio: fwiw, here are the current autopkgtest results http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd - the worrying one is i386 with the interfaces-many failure. ppc64el looks like some snaps are missing, I think I uplaoded them all, s390x is new and also misses some snaps but I think they are also available now
[19:00] <mvo> cachio: the next adt run (in a couple  of hours) hopefully gives us some more hints
[19:01] <cachio> mvo, thaks!!
[19:01] <cachio> I'll keep an eye on that run
[19:02] <cachio> mvo, I am running here on i386 to see the output of interfaces-many
[19:02] <cachio> mbut preparing yet
[19:02] <mvo> cachio: thank you. one more possible test is to use gccgo instead of go for the i386 build but that would really be the last possible thing to try
[19:02] <mvo> cachio: cool, that is interessting
[19:02] <mvo> cachio: it took a while for me but the oom is triggered every time
[19:07] <mup> PR snapcraft#1935 closed: elf: contemplate more patching scenarios <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1935>
[19:18] <hurricanehrndz> Please look over at your pleasure: https://github.com/lupoDharkael/flameshot/pull/120
[19:18] <mup> PR lupoDharkael/flameshot#120: snapcraft files added <Created by hurricanehrndz> <https://github.com/lupoDharkael/flameshot/pull/120>
[20:23] <sergiusens> zyga:  when will snaps work in lxd again?
[20:25] <mvo> sergiusens: what is broken right now?
[20:26] <sergiusens> mvo: same thing from Kyle's forum post on refreshes
[20:27] <mvo> sergiusens: hm, iirc things have landed in edge - is it broken with edge still?
[20:27] <sergiusens> mvo: last time you told me to go to edge I couldn't move back, not going to lightly move as my entire workflow depends on snaps working :-)
[20:27] <sergiusens> I will check later
[20:28] <mvo> sergiusens: *cough*
[20:28] <mvo> sergiusens: are you running stable right now? if so you should have 2.31 since today
[20:28] <mvo> sergiusens: which might contain the fix already, I can double check if you want
[20:28] <mup> PR snapd#4678 closed: snap: fix `snap moo` output <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4678>
[20:30] <sergiusens> no worries, I'll keep an eye open and complain accordingly :-P
[20:32] <zyga> sergiusens it already should work
[20:33] <zyga> but you need a new deb
[20:38] <mvo> aha, new deb - I'm working on that
[21:17] <Chipaca> why am i getting excited about new terminal escape sequences in bionic
[21:19] <Chipaca> sergiusens: are you on bionic?
[21:20]  * Chipaca goes back to reading vte sourcecode
[21:23]  * zyga gets back to bed 
[21:24] <zyga> 37.5C again :/