=== jamesh_ is now known as jamesh === pbek_ is now known as pbek [05:54] morning [06:48] PR snapd#4699 closed: cmd/snap: tweaks to 'snap info' output [06:49] mvo: morning [06:49] PR snapd#4689 closed: tests: new spread test for kvm interface [06:51] hey mborzecki ! good morning [06:52] PR snapd#4686 closed: daemon: make the ast-inspecting test smarter; drop 'exceptions' [06:58] PR snapd#4617 closed: many: implement "refresh-mode: {restart,endure,...}" for services [07:08] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1746710 is this something calling xdg-user-dirs-update with incorrect locale? [07:08] Bug #1746710: Snap creates redundant duplicate directories in home folder [07:10] good morning [07:10] zyga: morning [07:11] * zyga feels sick today, I'll be off for at least half the day [07:11] sorry guys [07:11] zyga: get some rest [07:11] I'll try to work in a few hours after some meds take effect [07:13] hey zyga [07:13] zyga: uh, yeah, get well! [07:29] mvo: any idea why this test would randomly fail? https://paste.ubuntu.com/p/zSH48GPxp6/ [07:30] mvo: last i've seen it fail on #4702, restarted the build and it's green now [07:30] PR #4702: cmd/snap: also include tracking channel in list output [07:30] mvo: this one in particular failed on debian-9 [07:37] mborzecki: I assume this is randomly failing? or conistently? [07:38] mvo: randomly [07:38] mborzecki: it [07:38] mborzecki: ups [07:38] mborzecki: did that start recently? there was a branch to move to EnsureDirState() for this file recently by zyga [07:38] I wonder if it that is related [07:39] i don't recall exactly when it started to fail [07:39] seen it a couple of times and it enede in my to-investigate list [07:42] 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] mvo: days, might as well be that change [07:59] sliff [08:07] moin moin [08:08] Chipaca: kalikiana: morning guys [08:08] just popping in for a minute before doing the morning school run [08:08] what was up with the failing apparmor test on debian? [08:09] Chipaca: https://paste.ubuntu.com/p/zSH48GPxp6/ it's gone after i restarted the job [08:09] huh [08:09] pstolowski: morning [08:09] morning! [08:09] pstolowski: o/ :-) [08:09] mborzecki: good call on those changes, i'll do them when i get back [08:46] Issue snapcraft#1939 closed: rust plugin: i386 multiarch linker error [08:49] mvo: i can reproduce the failure locally [08:49] mborzecki: oh, nice! [08:58] 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] re [09:04] how are things [09:12] mvo: on it [09:12] 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] 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] mborzecki: reason for having it earlier is that it's a quicker check [09:16] feels silly to put quick checks after the slow one [09:18] Chipaca: hm so maybe you meant to return in the `if idx2 := strings.IndexByte(rest, '/'); idx2 >= 0` block? [09:19] gah [09:19] mborzecki: ignore me, i shouldn't be allowed to look at code this early [09:20] of course there's no return so the order is unimportant [09:31] 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] mborzecki oooh [09:31] good thing is it will go away once we wait long enough [09:31] sorry, my bad! [09:31] will open a PR shorty :) [09:31] thank you for tracing this and working on a fix [09:32] mborzecki: haha, nice bug [09:38] 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] PR #4103: snapstate: auto install default-providers for content snaps [09:39] mvo: we can talk about it when you want [09:40] pedronis: oh, that sounds great. I was just picking up this PR again [09:40] pedronis: when is a good time for you? in ~30min maybe? [09:40] yea [09:42] PR snapd#4703 opened: interfaces/apparmor: use snap revision with surrounding '.' when replacing in glob [09:42] zyga_: ^^ [09:42] pedronis, thanks for the review btw, i've just finished addressing your last comment and added some more tests; do you want [09:42] ack [09:42] pedronis, do you want to take another look or can I merge when green? [09:43] 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] pedronis, sure [09:44] pstolowski: it's related to the managers_test fwiw [09:45] * kalikiana moving to coffee shop [09:57] anyone wants to take a look at #4676? [09:57] PR #4676: timeutil: introduce helpers for checking it time falls inside the schedule [09:58] PR snapd#4049 closed: debian,vendor: import github.com/snapcore/squashfs and use [10:02] mborzecki, yes, looking at it atm [10:03] pstolowski: thanks [10:04] pedronis, pstolowski I am in the hangout channel now, ready when you are (not exactly 30min yet so no worries) [10:05] k [10:09] PR snapd#4703 closed: interfaces/apparmor: use snap revision with surrounding '.' when replacing in glob [10:24] mborzecki: i think fmtChannel is a lot nicer thanks to your feedback, now [10:33] pstolowski: the ErrNoState change seems wrongly placed [10:33] hmm [10:33] we still want to return err if it's not ErrNoState [10:33] pstolowski: I left a comment [10:33] sorry [10:33] ah [10:47] pstolowski: thank you for working through this, once it is green it can land [10:48] pedronis, cool. thanks again for great reviews and spotting all these issues! [10:58] niemeyer: are you here? [11:00] Chipaca: Heya [11:07] niemeyer: oh! [11:07] mvo: he's here now, we could continue this right now [11:07] * Chipaca can go to physio after the standup [11:07] Chipaca: sure, I can if you want [11:07] Chipaca: whatever is more convenient for you [11:07] niemeyer: can you hangout? [11:08] * Chipaca pops back onto the standup [11:08] what are you chatting about? === zyga_ is now known as zyga [11:08] zyga: c-n-f [11:08] ah, interesting [11:08] well, I'm in mount-land and I feel like so I'll skip [11:08] sorry guys, barely holding up here [11:08] * Chipaca hugs zyga [11:08] zyga: thats fine [11:08] good luck guys [11:09] zyga: take a break, take a walk [11:09] Chipaca I just got out of bed, I want to do stuff as otherwise I'll just sleep [11:10] Chipaca, mvo: Yeah, omw [11:10] zyga: taking a walk fixes that as well [11:11] 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] mborzecki, reviewed 4676 [11:19] hello [11:20] 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] pstolowski: thanks a lot :) [11:21] 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] 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] 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] hey [11:28] theme support? [11:28] Making it so desktop applications don't look out of place on other desktops. [11:28] I think this is not strictly related to layouts but close; I believe the desktop theme is working on that [11:28] I'm not actively involved anymore as the part I was working on (mechanics to make that possible) is ready now [11:28] hey popey [11:29] I believe jamesh has a branch which is needed in the desktop helpers, but that's blocked on layouts AIUI [11:29] zyga: when will it land? [11:29] popey my part has landed in 2.31 [11:29] I don't know what's the progress of the desktop team to use this [11:29] seb128 ^ do you know anything about theme support work? [11:31] https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510 has some info [11:31] popey I believe themes are now possible [11:31] and I'm working on user mounts [11:32] 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] 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] sweet popey [11:33] mvo, looks like unexpected diff when checking /usr/share/dbus-1/services/io.snapcraft.Launcher.service [11:33] thanks! [11:33] zyga: what's the status of #4644 [11:33] PR #4644: tests: add a spread test for layouts [11:33] pedronis on my backlog, [11:33] pedronis I think I know what to do now but I need to discuss this with mvo [11:35] ok [11:37] PR snapcraft#1938 closed: tests: improvements to demos [11:38] zyga, not more than what is in the forum [11:47] PR snapcraft#1940 opened: tests: remove the webcam-webui demo [11:52] * cachio afk [12:14] pstolowski: in a meeting right now [12:14] pstolowski: the error seems to be "Job for snapd.socket canceled." ? [12:28] * zyga shivers [12:30] mvo, gosh, the log got overwritten as I restarted the job. it was different issue before [12:42] PR snapd#4702 closed: cmd/snap: also include tracking channel in list output [12:56] pstolowski: aha, ok. [13:02] PR snapcraft#1941 opened: project_loader: handle invalid unicode chars [13:34] * kalikiana lunch [13:36] mvo are bionic adt tests running against proposed? [13:36] zyga: yes [13:36] zyga: I run them locally now again to see if that helps [13:36] because bionic still has an artful kernel [13:36] I'm looking at that now [13:36] zyga: I like your idea about the secocmp things [13:36] (kernel) [13:37] zyga: maybe I was unfairly blaiming adt! [13:44] mvo I suck at finding the source package for 4.15 in bionic [13:44] and at getting a useful changelog [13:44] or configuration [14:00] mvo: fighting a bit to have clean tests but should have my UserAgent for snap repair PR soonish [14:01] 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] PR snapd#4401 closed: snapstate/ifacestate: auto-connect tasks [14:10] mvo, pedronis ^ autoconnect changes landed [14:11] yay !! [14:11] yay indeed, i hope to see the same re interface-hooks soon :} [14:13] pstolowski: nice! [14:13] pstolowski: \o/ [14:16] PR snapd#4704 opened: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu [14:16] mvo: a strange formatting in vendor.json has landed on master: https://github.com/snapcore/snapd/blob/master/vendor/vendor.json#L77 [14:17] mborzecki: https://www.youtube.com/watch?v=rzKaOp383vA [14:18] * Chipaca forgot to press enter half an hour ago [14:18] haha [14:18] right, looks relaxed :) [14:18] Chipaca: https://www.youtube.com/watch?v=3QiGuXETYnQ [14:18] 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] Yeah, it looks great on KDE Neon 16.04 here too. [14:19] (the version in stable) [14:19] I mean I used kde neon repos to stage & build packages :) Testing on the same kubuntu 17.10 to run it.. [14:20] ahh [14:20] it's weird that you have it working nicely on Neon @ 16.04 [14:20] it's not supposed to :] [14:20] Pretty sure the screenshot i put in the @ubuntu social post came from my kde laptop [14:20] pedronis: autsch, probably my fault while resolving a conflict [14:20] PR snapd#4705 opened: set snap-repair User-Agent on requests [14:20] that probably means my snap is not exactly contained? [14:20] PR snapcraft#1940 closed: tests: remove the webcam-webui demo [14:21] mvo: proposed 4705 [14:21] mvo: do want me to do a PR for vendor.json ? [14:22] pedronis: yeah, please do [14:24] thresh: what's your snap? [14:25] Chipaca: vlc [14:25] PR snapd#4706 opened: vendor: resync formatting of vendor.json [14:25] looks confined here [14:27] mvo: ^ done [14:27] mvo: do you needa cherry pick for 2.31 of 4705 ? [14:28] 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] looks like I'm missing some fonts still [14:31] re [14:31] * pedronis break [14:31] yeah, solves the looknfeel on Gnome shell as well [14:31] let's try mate [14:32] 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] popey, ^^^ we should probably do some promotion around that fact ;) [14:34] It was quite a challenge to get that working! [14:34] Stepping out for an early lunch so I can be in a call at the top of the hour.. biab [14:34] (on nvidia, amd and intel) [14:34] and it is soooo awesome ! [14:34] yeah, and that's all not my fault :) [14:34] mvo, snap core 2.31 in stable [14:34] i really love that my laptop fan stays silent if i stream TV [14:34] mvo, smoke test passed [14:36] yep, but that isnt reproduced on Debian stable with nvidia, on gnome shell, it's the same [14:36] oops EWRONGCHAN [14:37] I wonder if I'm supposed to ship all the fonts the users might use? [14:37] it would be pretty tough to handle all weird languages [14:40] No, as I understand it layouts can fix fonts too [14:43] 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] this is on xenial, and the machine was rebooted a few minutes ago [14:45] PR snapd#4707 opened: Tests interface broadcom asic control [14:47] 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] PR #1941: interfaces/builtin: allow mmaping pulseaudio buffers [14:49] kalikiana: before your change, if you had a 💩 in your description, you'd get a nasty traceback [14:49] Yes [14:49] kalikiana: with your change you now get an error that says "character foo not allowed in description" [14:49] Chipaca: You got that same error together with the traceback before [14:49] kalikiana: I'm saying: it's not true that it's not allowed [14:50] the yaml parser can't handle it, but it's totally allowed [14:50] tell the user that, not that it's not allowed [14:50] Hmmm [14:50] their 💩 apps can be as 💩-y as they want [14:51] Chipaca: They could be, if pyyaml would release a fix... [14:51] all the user needs to do, today, without you doing anything, is use a \u escape [14:51] or a \U escape if it's not BMP [14:52] just saying "not supported (try escaping)" would be more truthful and helpful [14:52] that's my point [14:52] nothing more [14:52] (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] cachio: thank you! [15:03] pedronis: no need to cherry pick the vendor.json I think thats only a issue in master [15:09] mvo, did you see https://forum.snapcraft.io/t/accessing-ttys0-on-raspberry-pi-3-running-ubuntu-core/4096 [15:12] ogra_: I have not, let me look (but in a meeting) [15:16] mvo: I meant the snap-repair fix [15:16] mvo, no hurry ... minor addition to the config.txt code (one more option) [15:16] pedronis: yes, I will cherry-pick that one [15:16] ogra_: yeah, looks almost trivial [15:16] mvo: ah, ok [15:17] mvo: not green yet though [15:17] pedronis: yeah, store was a bit unhappy [15:18] Chipaca: could you do a 2nd review of #4705, it's small and should be an area you know [15:18] PR #4705: cmd/snap-repair,httputil: set snap-repair User-Agent on requests [15:20] is it an US holiday today? [15:20] yes. presidents day [15:20] ah, thanks [15:20] * zyga refrains from joking about it [15:21] indeed. too painful, i suspect [15:22] not for non-americans :) [15:25] pedronis: +1 [15:33] It's ok, were just celebrating 44/45 Presidents today [15:37] PR snapd#4706 closed: vendor: resync formatting of vendor.json [15:40] cwayne my thoughts exactly [15:46] 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] 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] ahh [15:50] 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] kalikiana: 👍 [15:52] * cachio lunch [15:52] * Chipaca physio [15:56] Chipaca: Thanks for your review. I definitely don't consider it noise! :-) [15:56] Call is over, and I need to take kid to school.. o/ [16:04] 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] oh [16:04] could it be caused by our "trigger" usage? [16:04] or a regression in systemd somewhere [16:05] in any case that's not a fun thing to learn [16:05] trigger shouldnt be able to cause OOM ... after all it just replays uevents in the kernel [16:06] zyga: http://paste.ubuntu.com/p/zJTYQ4SjqX/ [16:06] zyga: I have no idea should [16:07] I don't understand those logs out of the blue, not sure what's using memory [16:07] how did you reproduce it? [16:08] zyga: http://paste.ubuntu.com/p/9w5YwCJXP9/ is also interessting [16:08] zyga: yeah, I need to dig into this now and figure out what it means [16:09] zyga: but it really looks like snapd and snap are the outliners in the second paste [16:09] mvo so both snapd and snap use about 200MB/s? [16:09] or is toal_vm just address space and rss is the right thing [16:09] zyga: aiui rss is the working set so closer to the truth [16:10] zyga: but still high on both snapd and snap [16:17] 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] do you have the state? maybe there are some interesting tasks? [16:19] pstolowski did you land the connect hooks? [16:19] zyga, no. just autoconnect changes [16:20] zyga, made autoconnect handled by tasks [16:21] zyga: I looked at the state size, its just 136k [16:21] zyga: butthe state is now lost, my ssh got killed [16:21] how are you setting that up for tetsing? [16:21] (it's certainly annoying to do) [16:22] zyga: at first I was running autopkgtest, then just pure spread on a ubuntu-18.04-32 image [16:22] zyga, is your question related to the issue you're discussing with mvo? [16:22] pstolowski yes [16:22] zyga: and now I try to do it on my regular system (which is -64) [16:22] zyga, my changes landed shortly after the standup [16:23] zyga: the usage pattern was ~800mb free mem (according to htop), then "snap connect ..." and my task got killed [16:23] pstolowski: its probably not that (yet) [16:23] pstolowski: because the adt failure is older and shows the same pattern [16:23] mvo not sure if you can, try to set oom score for your shell [16:23] (older as in a couple of days older) [16:23] zyga: yeah, I'm running the spread again [16:23] zyga: its a bit of hit and miss if I get a shell at all :) [16:42] PR snapd#4705 closed: cmd/snap-repair,httputil: set snap-repair User-Agent on requests [16:46] thanks pedronis - and its cherry-picked now [16:47] thank you [17:04] 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] cachio: where is test-snapd-hello-classic? we will need a build for ppc64el for this one (and probably s390x) [17:05] mvo, let me check [17:05] any thoughts? [17:06] mvo, I don't have it [17:06] mvo, I don't see it neither in the store nor launchpad [17:08] * kalikiana wrapping up for today [17:09] mvo, you don't see it in the store? [17:10] cachio: slightly mysterious it is only there for i386/amd64 - test-snapd-hello-classic [17:10] 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] mvo, np, could you please share it with me? [17:11] mvo, I'll do the rest [17:12] mvo, I'll push it to launchpad [17:12] mborzecki: do you have a snapcraft.yaml for test-snapd-hello-classic for cachio ? [17:12] it should be in the repo [17:13] mvo: cachio: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-hello-classic [17:14] 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] mvo, mborzecki could you please share the snap with me in the snap store? [17:15] so I can trigger the build for all the archs [17:16] cachio: it was reassigned to the 'canonical' account [17:16] mborzecki, great tx [17:17] it was already shared to me [17:19] mborzecki, mvo builds triggered for arm64 armhf and ppc64el [17:19] snaps will be available in 1 hour aprox [18:04] mvo are you going to send 2.31.1 to beta today? [18:05] cachio: probably not, I need to fix the autopkgtest failures first, without that there is little use in having 2.31.1 [18:06] 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] cachio: I'm checking now if increasing the memory helps, its a bit thorny [18:07] cachio: interfaces-many will fail on bionic on i386 (if you want to reproduce it) [18:07] mvo, ok, just tell me on what I can help you [18:07] mvo, sure [18:07] cachio: you will need https://github.com/snapcore/snapd/pull/4704 [18:07] PR #4704: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu [18:07] mvo, ok [18:08] 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] ok [18:08] 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] 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] mvo, which image are you using? [18:09] the last one? [18:09] 18-Feb? [18:19] cachio: I created a bionic image via autopkgtest-buildvm -r bionic -a i386 and renamed it to ubuntu-16.04-32 [18:19] mvo, ok, I'll try that [18:19] }tx [18:20] cachio: thanks, I tried with -m 3500 - kill OOM :/ [18:44] mvo: is snapd using so much memory? [18:48] 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] pedronis: but at least it is reproducible [18:48] I would hope is not snapd, unless it's a change in go that triggers the issue [18:49] I mean no deep reason for memory usage of snapd to change [18:50] mvo: as usual is also hard I suppose to correlate to what has changed recently in bionic :/ [18:51] pedronis: yeah, bionic is very much in flux and we did not run an i386 based test there in a while [18:51] 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] pedronis: its definitely not fun [18:52] 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] 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] mvo, pedronis I can try all this this afternoon [18:55] cachio: thank you, keep me updated please :) [18:55] mvo, sure === Guest92838 is now known as devil__ [19:00] 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] cachio: the next adt run (in a couple of hours) hopefully gives us some more hints [19:01] mvo, thaks!! [19:01] I'll keep an eye on that run [19:02] mvo, I am running here on i386 to see the output of interfaces-many [19:02] mbut preparing yet [19:02] 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] cachio: cool, that is interessting [19:02] cachio: it took a while for me but the oom is triggered every time [19:07] PR snapcraft#1935 closed: elf: contemplate more patching scenarios [19:18] Please look over at your pleasure: https://github.com/lupoDharkael/flameshot/pull/120 [19:18] PR lupoDharkael/flameshot#120: snapcraft files added [20:23] zyga: when will snaps work in lxd again? [20:25] sergiusens: what is broken right now? [20:26] mvo: same thing from Kyle's forum post on refreshes [20:27] sergiusens: hm, iirc things have landed in edge - is it broken with edge still? [20:27] 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] I will check later [20:28] sergiusens: *cough* [20:28] sergiusens: are you running stable right now? if so you should have 2.31 since today [20:28] sergiusens: which might contain the fix already, I can double check if you want [20:28] PR snapd#4678 closed: snap: fix `snap moo` output [20:30] no worries, I'll keep an eye open and complain accordingly :-P [20:32] sergiusens it already should work [20:33] but you need a new deb [20:38] aha, new deb - I'm working on that === wxl_ is now known as wxl [21:17] why am i getting excited about new terminal escape sequences in bionic [21:19] sergiusens: are you on bionic? [21:20] * Chipaca goes back to reading vte sourcecode [21:23] * zyga gets back to bed [21:24] 37.5C again :/