[01:22] <mup> PR snapcraft#2456 opened: plugins: add colcon plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2456>
[06:12] <mborzecki> morning
[07:17] <mup> PR snapd#6462 closed: snap-confine: fix incorrect "sanity timeout 3s" message <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6462>
[07:18] <mup> PR snapd#6463 closed: snap-confine: increase locking timeout to 30s  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6463>
=== sabdfl_ is now known as sabdfl
[07:22] <Saviq> sergiusens, mwhudson: I believe we got the multipass build going on bsi before we moved it under Canonical, and yeah last I checked it wasn't possible to set up a build if you were only a collaborator
[07:38] <zyga> Hi
[07:39] <Saviq> moaning
[07:39] <mvo> hey zyga ! good morning
[07:39] <mvo> hey Saviq
[07:39] <zyga> Good morning
[07:47] <mborzecki> zyga: mvo: Saviq: hey guys
[07:47] <mborzecki> zyga: feeling better today?
[07:47] <zyga> mvo: so-so, I was just thinking if I should be off and back in bed to be on the safe side
[07:47] <mvo> mborzecki: good morning
[07:47] <mvo> zyga: sure, do it
[07:47] <zyga> mvo: I was thinking about the timing issue yesterday
[07:48] <zyga> mvo: I will investigate one aspect and then probably just quit (I'll file paperwork for both days)
[07:48] <zyga> mvo: there's a reliable way to trigger the issue
[07:48] <mvo> zyga: sure
[07:48] <mvo> zyga: oh?
[07:48] <zyga> mvo: I want to see what happens now with 2.37.x as far as systemd is concerned
[07:48] <zyga> mvo: sure, just put a long sleep in the main process after forking the helper
[07:49] <zyga> mvo: if there's a difference to 2.36 I will look at patching that
[07:49] <mvo> zyga: aha, I see
[07:50] <Saviq> zyga: "put a long sleep... after forking..." that's re: your day off, is it? ;)
[07:51] <zyga> haha
[07:51] <zyga> fork & exec and then I will be off ;)
[07:51] <zyga> (for a few days at least)
=== pstolowski|afk is now known as pstolowski
[07:59] <pstolowski> morning
[08:02] <mborzecki> pstolowski: hey
[08:04] <pedronis> pstolowski: hi, couldn't the doHotplugAddSlot bit be separated out in a PR before being used?
[08:05] <pstolowski> pedronis: hi, yes it could, i wasn't sure if we want to separate further. shall i do this?
[08:05] <pedronis> pstolowski: yes, but I left a comment there as well, one sec
[08:06] <pedronis> pstolowski: ok, added one comment
[08:06] <pedronis> (for now)
[08:06] <pstolowski> pedronis: km thanks
[08:12] <mup> PR snapd#6456 closed: interfaces: add network-manager-observe interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6456>
=== phoenix_firebrd is now known as murthy
=== ricab is now known as ricab|brb
[09:16] <ogra> sil2100, hey ho ... do you currently use ubuntu-image to create the classic pi images (and a gadget for classic) ?
[09:21] <sil2100> ogra: yeah, pi3 for now, and using currently a slightly modified gadget tree for classic
[09:21] <sil2100> ogra: (we want to merge it into one gadget repo in the next iteration)
[09:21] <sil2100> I hope waveform will help with that ;)
[09:22] <ogra> sil2100, do you have the gadget code public ... ?
[09:23] <sil2100> ogra: sure, it's used in our daily builds so yes
[09:23] <sil2100> https://github.com/CanonicalLtd/pi3-gadget/tree/classic
[09:23] <ogra> thanks !
[09:24] <sil2100> ogra: it has some messy bits right now (some hacks to workaround various missing pieces here and there) and well, the custom classic bootscript is very simple as we didn't have time to create one that would do our things for both classic and core
[09:25] <sil2100> I blame it on time constraints of course
[09:25] <ogra> sil2100, uh, why did you re-inroduce boot.scr ? took us years to get that fixed upstream to allow uEnv.txt files
[09:26] <sil2100> ogra: yeah, so that was not the best decision I made, we'll be going back to using uenv soon, I used boot.scr because: a) that's what ryan's pi3 classic images used and b) that's what flash-kernel upstream was using for the pi3
[09:26] <ogra> wow, that code is miles apart from the core gadgets
[09:26] <sil2100> But yeah, it's something we'll change back in the nearest weeks
[09:27] <sil2100> Which part of the code? ;)
[09:28] <ogra> Makefiles instead of letting snapcraft do everyrthing (i.e. only a snapcraft.yaml) ... boot.scr ... copying blobs around instead of building from source
[09:29] <sil2100> ogra: yes, the Makefile and copying blobs is all that will go 'upstream'
[09:29] <sil2100> ogra: we can't use snapcraft to do all the things because snapcraft is in universe, and we need to build the gadget trees in our livefs builders (livecd-rootfs)
[09:30] <sil2100> ogra: and we need to pull all the blobs from the archive as everything we build officially for classic should use existing binaries from the archive, not building them 'in place'
[09:30] <ogra> oh, and you cant use the snapcraft snap during build either ?
[09:31] <sil2100> No, since livecd-rootfs needs to only use debs, we're not relying on snaps in any point of our image build process
[09:31] <ogra> oh my ... yeah, then that setup is probably best
[09:31] <sil2100> So I had to switch to a Makefile, which made things eh, very complicated
=== ricab|brb is now known as ricab
[09:31] <ogra> yep, i know what you mean
[09:32] <sil2100> The boot.scr is a mistake, I know ;p
[09:32] <ogra> my "getting in touch with snaps" was exactly the other way around ... everything was a Makefile ... nowadays everything is just snapcraft.yaml
[09:32] <sil2100> I was going back and forth with that one sadly
[09:32] <ogra> yeah, its not easy
[09:33] <ogra> in core its a bit better since we need to pre-build the whole environment as an image
[09:33] <sil2100> First I used uenv like core, but then saw flash-kernel and our unofficial images and well, switched, but that's actually not what we want - and it was already a bit too late then
[09:33] <ogra> so no need for a boot.scr, all customization happens when the env is created
[09:34] <ogra> core only used uEnv.txt in 15.04
[09:34] <ogra> we quickly moved to a full environment build
[09:34] <sil2100> Yeah, and we need to have a common scenario for both core and classic, so I'll switch back to u-boot.env
[09:34] <ogra> makes everything easier to maintain :)
[09:37] <ogra> sil2100, BTW, why do you build separate images, you could have a single universal Pi image that runs on all Pi's we support (at least for armhf ... arm64 only for all Pi3 models)
[09:37] <Chipaca> mvo: o/
[09:38] <Chipaca> mvo: two things for you (ish?)
[09:38] <Chipaca> mvo: one, https://forum.snapcraft.io/t/the-road-to-core18/5547/24
[09:38] <Chipaca> mvo: two, https://forum.snapcraft.io/t/cant-set-permission-set-hardware-observer/8695/6
[09:38] <ogra> sil2100, (note i dont want to mimic adam smith :P ... just an interest question)
[09:39] <sil2100> ogra: that's the plan as well! Right now they're called pi3 images, but we're pretty confident that the pi3 armhf images we have will just work on the pi2
[09:40] <sil2100> ogra: but we don't brand them that way yet as we didn't commit to making sure that's really the case
[09:40] <waveform> ah, more reading (have not come across uEnv.txt yet!)
[09:40] <sil2100> ogra: for now we're only concentrating on making the pi3 arm64 one working
[09:40] <ogra> sil2100, https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md should be interesting ... you can use conditionals in config.txt to switch to the right u-boot/kernel.img based on the HW the first stage bootloader detected
[09:40] <sil2100> waveform: hah! Well, we'll be just using u-boot.env in our case, just like the core snap
[09:40] <waveform> I shall be testing on "all the Pis" when I get a spare moment!
[09:41] <waveform> ogra, yup - includes may be useful too (to avoid trampling users changes to config.txt)
[09:41] <ogra> sil2100, thats what i use in my core universal Pi gadget ... https://github.com/ogra1/pi-kiosk-gadget
[09:41] <sil2100> ogra: yeah, didn't use it but saw that in the config.txt of core18 gadgets, seemed nice and useful
[09:41] <sil2100> ogra: we have that in the universal pi gadget for core18 as well, although a bit messy ;p
[09:42] <ogra> waveform, ah, you are the Pi-guy ? welcome to the madhouse ;)
[09:42] <mvo> Chipaca: thank you
[09:42] <waveform> ogra, yup - surrounded by the things (and the madness :)
[09:42] <sil2100> ogra: yes, waveform will make our Pi experience amazing ;)
[09:42] <ogra> sil2100, because i initially wrote it :) i'm known for "messy but working, ... needs work" stuff ... you know me ;)
[09:43] <sil2100> I guess we all have projects like that ;)
[09:43] <ogra> yeah
[09:48] <mup> PR snapd#6415 closed: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
[09:49] <mup> PR snapd#6464 opened: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6464>
[09:50] <mvo> waveform: nice - welcome!
[09:50] <mvo> mborzecki: firstboot measure, the above is my RFC/idea how to get started, very simple but should give us something to start from (if pedronis  is happy with the initial shape :)
[09:51] <mborzecki> mvo: ok, will look in a bit
[09:51] <mborzecki> mvo: snap analyze-blame :P
[09:52] <ogra> now that would be a thing
[09:52] <ogra> !
[09:52] <mvo> mborzecki: haha - I like that
[09:52] <pedronis> mvo: I'm a bit worried you did that at all :)
[09:54] <mborzecki> mvo: iirc zyga has a branch to collect some timing measures too, we closed it didn't we?
[09:54] <zyga> yes
[09:54] <zyga> I have it on github
[09:54] <mvo> pedronis: its just a quick outline, promised I will not touch it more
[09:54] <mvo> mborzecki: yeah, I reference to zyga PR
[09:54] <zyga> specifically the ring buffer code is IMO good to merge
[09:55] <mvo> mborzecki: zyga approached it from the other side, I think we need to agree on the shape first (with pedronis) then we can take those bits, YAGNI and all that
[09:55] <mborzecki> yup, agreed
[09:55] <mvo> zyga: yeah, there is a FIXME in there that point to the ringbuffer
[09:55] <zyga> I started with the assumption that snapd should know timing data about any part of the stack
[09:56]  * mvo really likes snap analyize
[09:56] <zyga> k
[09:56] <zyga> I didn't read any of the PRs
[09:56] <pedronis> yes, don't carried away too much before I look at things
[09:56] <mvo> zyga: its fine, no worries, I think we will need most of your stuff its just approaching it from the other direction
[10:02]  * dot-tobias waves hello
[10:06]  * Chipaca waves back
[10:22] <Chipaca> pedronis: both my PRs are ready for re-reviews, if you're wondering what to do :-p
[10:25] <mup> PR snapd#6465 opened: overlord/ifacestate: hotplug-add-slot handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
[10:26] <pstolowski> pedronis: ^ it grew some extra tests not present in the main branch
[10:28] <Chipaca> pedronis: unrelatedly, if I have a ClientSnapFromInfoSnap(*info.Snap) (*client.Snap, error), should I put it in cmd/ (next to the similar ClientAppInfosFromSnapAppInfos(apps []*snap.AppInfo) ([]client.AppInfo, error) ) ?
[10:28] <Chipaca> it'd be used by daemon and cmd/snap
[10:37] <pedronis> Chipaca: yes, seems those two need to be together
[10:37] <pedronis> pstolowski: thanks, in my queue
[10:37] <pedronis> pstolowski: are you blocked or are you looking again at EnsureBefore ?
[10:40] <pstolowski> pedronis: yes, i'm looking at ensurebefore, not blocked
[10:47] <pedronis> pstolowski: thx
[10:49] <mborzecki> should we land #6422 and see if that makes the occasional mount issue on ubuntu-core-18 go away?
[10:49] <mup> PR #6422: tests/prepare: prevent console-conf from running <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6422>
[10:50] <pedronis> Chipaca: thanks, yes your PRs are likely the next things I look at
[11:14] <mup> PR snapcraft#2438 closed: rust plugin: new link for rustup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2438>
[11:14] <mup> PR snapcraft#2454 closed: baseplugin: add a proper exception for cross-compilation support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2454>
[11:53] <dot-tobias> Struggling with cross-compilation in multipass VMs / snapcraft 3.x, super grateful for any “you're holding it wrong” hints: https://forum.snapcraft.io/t/snapcraft-3-x-cross-compilation-amd64-armhf-in-multipass-vm/9758
[12:05] <mup> PR snapd#6426 closed: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6426>
[12:30] <Chipaca> mvo: ping
[12:30] <Chipaca> popey: ping?
[12:30] <Chipaca> oh, fosdem
[12:30] <Chipaca> fossdem?
[12:31] <Chipaca> Wimpress: also fosdem?
=== alan_g_ is now known as alan_g
[12:45] <Wimpress> Chipaca: Hi
[12:46] <Wimpress> Sorry, was head down. I'm available. Not a FOSDEM.
[12:46] <Wimpress> I don't have anything to discuss, but if you've got something we can jump on a call?
[12:58] <Chipaca> Wimpress: ah, er, I went off to prepare lunch (it's cooking rn), mvo did similarly i think
[13:21] <leinardi> Hi, when I try to run my app from the snap I'm getting an error related to gnome-3-26-1604, even if I specified gnome-3-30-1804 and core18. Can someone give me some hints on how to fix this? More details here: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/17
[13:21] <zyga> kenvandine: ^
[13:21] <zyga> leinardi: you might need to wait for people from US time-zones to be up though
[13:21] <kenvandine> Hey
[13:21] <Chipaca> leinardi: are the connections ok?
[13:22] <zyga> hey kenvandine :-)
[13:22] <Chipaca> maybe we got the content interface plugged wrong or sth
[13:22] <kenvandine> That message just means the content snap isn't mounted
[13:24] <zyga> kenvandine: does 3-30-1804 exist?
[13:24] <zyga> mvo: iterating on the regression test, it's trickier than it should perhaps :/
[13:25] <kenvandine> zyga: it's only in edge and untested
[13:26] <kenvandine> leinardi: Use gnome-3-28-1084 it probably has a newer gtk than gnome-3-30-1804
[13:26] <zyga> kenvandine: is there a plan to make it stable, 18.04 was shipped a while ago and core18 is a thing for a few weeks now
[13:27] <kenvandine> we're shipping a bunch of snaps with gnome-3-28-1804 already
[13:28] <kenvandine> if $SNAP/gnome-platform doesn't exist or is empty it prints out that error to connect it
[13:28] <zyga> ah
[13:28] <zyga> I missed 28 vs 30
[13:28] <kenvandine> right now the scripts are hard coded to gnome-3-26-1604 for that print statement
[13:29] <zyga> mborzecki: ^ it would be great if we had a way to get slot attributes via snapctl
[13:29] <zyga> e.g. snapctl slot-info --print-attr=content "gnome-platform"
[13:29] <zyga> so that a message like that doesn't have to be hard-coded
[13:31] <mborzecki> zyga: hm iirc there's snapctl get --slot/--plug
[13:31] <zyga> oh, I didn't know
[13:31] <zyga> does it show stuff like attributes easily?
[13:31] <zyga> I'm mainly after usability from shell
[13:32] <mborzecki> idk
[13:32] <Chipaca> zyga: you can just run it :-)
[13:33] <Chipaca> error: error running snapctl: interface attributes can only be read during the execution of interface hooks
[13:33] <Chipaca> I lied
[13:33] <mborzecki> heh
[13:33] <zyga> ~/go/src/github.com/snapcore/snapd/tests/regression/lp-1813963 $ snapctl get --plug :opengl
[13:33] <zyga> error: error running snapctl: interface attributes can only be read during the execution of interface hooks
[13:33] <zyga> not useful
[13:34] <Chipaca> quoth the raven, Y THO
[13:34] <mborzecki> poe rolling in his grave
[13:34] <kenvandine> zyga: speed is very important there
[13:34] <kenvandine> we don't want to slow down desktop-launch
[13:34] <zyga> sure
[13:34] <zyga> it should be zippy
[13:34] <zyga> fast
[13:34] <zyga> snappy even
[13:34] <kenvandine> it needs to be as fast as checking for the contents of the directory :)
[13:35] <zyga> sure but now it is fast but misleading
[13:35] <Chipaca> right, the fast path yes, but if it fails you can be slower reporting the error
[13:35] <kenvandine> but... it would be a big improvement
[13:35] <zyga> it needs to be useful and fast
[13:35] <kenvandine> ah
[13:35] <kenvandine> good point
=== ricab is now known as ricab|lunch
[13:35] <kenvandine> we'll look at doing that in the gnome extension of snapcraft
[13:35] <Chipaca> error handlers have all the time in the world¹
[13:36] <zyga> good point
[13:36]  * zyga recalls a special parser that has a fast path for correct code and a super-generic error path for any errors that is then causing re-parsing with a parser crafted for careful errors at the expense of longer parsing time
[13:37] <Chipaca> in other news, cabbage does not shrink while cooking. I'm eating out of a bucket today.
[13:44] <zyga> mvo: whee
[13:44] <zyga> it passed
[13:44] <zyga> man that was tricky
[13:45] <leinardi> > <kenvandine> leinardi: Use gnome-3-28-1084 it probably has a newer gtk than gnome-3-30-1804
[13:46] <leinardi> kenvandine, wait, so gnome-3.28.1804 actually has Gnome 3.30? I need 3.30, can't use 3.28
[13:47] <kenvandine> they are both built from 18.04, gnome-3-30-1804 isn't a real thing yet
[13:47] <kenvandine> it's not in stable because it's not complete yet
[13:47] <kenvandine> and it will ultimately be built from the build snap, not the archive
[13:49] <leinardi> so, there is no current way to get gnome 3.30 to work with snap? should I just wait to release my app with it?
[13:50] <Wimpress> I've just installed `multipass` on a clean install of 18.10.
[13:51] <Wimpress> Every multipass command I issue results in: `dropping privs did not work` which is an error being thrown by snapd-confine.
[13:52] <Wimpress> Just want to know if this is a known issue before I got digging.
[13:52] <Chipaca> zyga: ^
[13:52] <zyga> Wimpress: no
[13:52] <zyga> hmm hmm hmm
[13:52] <zyga> Wimpress: I will check in a moment but can you please open a bug
[13:52] <zyga> Wimpress: and attach
[13:53] <zyga> SNAPD_DEBUG=1 multipass
[13:53] <zyga> I will handle the rest
[13:53] <Wimpress> Sure thing.
[13:57] <pedronis> Chipaca: I did a review of #6356
[13:57] <mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
[13:57] <Chipaca> pedronis: ta
[13:58] <Wimpress> zyga: You can stand down. We have a case of use error.
[13:58] <zyga> :D
[13:58] <zyga> what did you do?
[13:58] <Wimpress> I've just notice the terminal I was use is logged in as root.
[13:59] <Chipaca> pedronis: the call to SetStatus needs to happen before the call to EnsureBefore, right?
[13:59] <pedronis> Chipaca: no, doesn't matter, given you holding the lock
[14:00] <Chipaca> k
[14:00] <pedronis> Chipaca: we tend to do it last, lots of examples
[14:00] <pedronis> in ifacestate
[14:00] <Chipaca> pedronis: isn't the status set to done as soon as the handler returns with no error?
[14:00] <pedronis> Chipaca: yes, but we release the lock in the middle of that
[14:00] <pedronis> so not guarentee
[14:00] <pedronis> that we get there
[14:01] <abeato> jdstrand, hey, was wondering if you had seen my comment about NM controlling netplan: https://github.com/snapcore/snapd/pull/5915#issuecomment-454695004
[14:01] <mup> PR #5915: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5915>
[14:01] <sergiusens> Wimpress: hmm, multipass works fine on the current devel I am typing from
[14:02] <kenvandine> leinardi: i can take another look at your snap in a bit, i'm in a meeting for the next couple hours
[14:16] <Wimpress> sergiusens: It was user error on my part.
[14:36] <jdstrand> abeato: I had and need to circle back to it (it is on my todo). thanks for the reminder
[14:36] <abeato> jdstrand, great, thank you
[14:38] <pedronis> abeato: which snaps need this? just our own NM?
[14:38] <pedronis> jdstrand: fwiw I'm also thinking about this problem
[14:39] <abeato> pedronis, just that one, yes
[14:42]  * jdstrand nods
[14:46] <Chipaca> pedronis: wrt putting fromChange 'last', that'd be last before flags, right? or actually last?
=== ricab|lunch is now known as ricab
[15:13] <pedronis> Chipaca: actually last
[15:15] <Chipaca> pedronis: ack
[15:15] <Chipaca> pedronis: and the filter also after the flags?
[15:15] <jdstrand> is there a problem with lp snap builds? I tried to request a build from something and all it says is 'Failed to build' with no buildlog
[15:17] <cjwatson> jdstrand: #is-outage
[15:17] <ogra> jdstrand, theer seem to be other timeouts too
[15:17] <cjwatson> swift takes out librarian which takes out a bunch of random stuff
[15:17] <ogra> ah, cjwatson beats me
[15:19] <jdstrand> cjwatson: thanks
[15:28] <pedronis> Chipaca: that's fine, not as a strong opinion on that
[15:31] <leinardi> kenvandine, sure thanks! I'll go offline soon, if you can please reply on the forum post: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/27
[15:49] <zyga> mvo: given is-outage I wonder if we can release today
[15:54] <mvo> zyga: we released
[15:54] <zyga> I mean about .2
[15:54] <zyga> can we even go to beta?
[15:56] <zyga> mvo: interesting observation from just now
[15:56] <zyga> I fixed one more typo
[15:56] <zyga> the service fails correctly now
[15:57] <zyga> but :)
[15:57] <zyga> it is "working" during the startup phase
[15:57] <zyga> I wonder if snap-confine or snap-run perhaps should be able to tell systemd "hold on, not really there yet"
[15:57] <zyga> systemctl start snap.foo.bar.service # <- while snap-confine is running the service appears to be operational
[15:57] <zyga> I realise this is a daemon=simple service
[15:58] <zyga> just was not expecting it, I guess
[15:58] <cjwatson> zyga: note that the swift that the LP librarian uses isn't the same as the one that the snap store uses
[15:59] <zyga> cjwatson: ah, uff, that's good news
[15:59] <cjwatson> at most it could cause a problem for builds; if you have something built it won't matter though
[15:59] <cjwatson> (also it looks like it might be fixed)
[16:10] <zyga> mvo: the test is passing now, I will experiment with the two extra variants that pedronis suggested
[16:13] <mvo> zyga: thank you - I will take a break and get back to it then
[16:13] <zyga> k
[16:16] <cjwatson> jdstrand: try again now?
[16:31] <zyga> mvo: going through smoke testing main/regression with my patch
[16:31] <zyga> mvo: in parallel iterating on the variants pedronis suggested
[16:31] <zyga> mvo: so far all good
[16:31] <zyga> jdstrand: hey
[16:31] <zyga> jdstrand: do you have a moment to discuss a regression I introduced to snap-confine?
[16:32] <zyga> jdstrand: a quick look at a patch fixing that, I can give you context about the earlier discussion I had with pedronis and mvo
[16:32] <zyga> jdstrand: if you cannot do it now that's fine, we can try next week
[16:40] <jdstrand> zyga: if it isn't urgent, next week would be better
[16:40] <jdstrand> zyga: and hello :)
[16:40] <zyga> jdstrand: hey :)
[16:41] <zyga> jdstrand: it's urgent-ish but I think it can wait (CC: mvo)
[16:41] <zyga> jdstrand: I will open the PR and let anyone comment in case someone wants to over weekend
[16:44] <jdstrand> zyga: if you do it that way, ping me with the PR and perhaps I can get to it later today
[16:45] <zyga> thank you!
[16:45] <zyga> I have a patch now but I'm trying to reduce it in scope so that it can do less side-effects and damage
[16:54] <diddledan> Lukewh: did the build.snapcraft.io get fixed for https://github.com/canonical-websites/build.snapcraft.io/issues/1181?
[16:55] <pstolowski> pedronis: hey, i'm fighting with ensurebefore.. as soon as i enhance the "naive" fix with "if !o.ensureTimer.Stop() { <-o.ensureTimer.C }" it hangs around it
[16:55] <diddledan> I'm seeing the snaps again that had disappeared, but I'm not sure if it's because of a fix or just my dumb luck that I received a different set of data from the API when I refreshed (my bug was https://github.com/canonical-websites/build.snapcraft.io/issues/1175) but it seems identical to popeys
[16:55] <diddledan> popey's
[16:57] <mvo> zyga: thanks
[16:58] <mvo> zyga: yeah, what I heard from abeato was that monday is ok but if not I can jump on it now
[16:58] <zyga> mvo: I have the patch now
[16:58] <zyga> reduced
[16:58] <mvo> zyga: is there a PR yet? abeato was also keen to look at the details
[16:58] <zyga> yes
[16:58] <mvo> zyga: aha, nice - with pedronis suggestions?
[16:59] <Chipaca> I'm going to take a break for a while. Will bbl, in a couple of hours. If you go before I'm back, have a great weekend!
[16:59] <zyga> yes
[17:00] <zyga> sorry, messed up my branch names (wip vs fix) opened properly now
[17:00] <mup> PR snapd#6466 opened: cmd/snap-confine: handle death of helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
[17:00] <zyga> jdstrand: ^
[17:00] <zyga> pedronis: ^ FYI
[17:00] <zyga> at least for _this_ test it works correctly
[17:01] <zyga> and feels like a safe thing to releae
[17:01] <zyga> *release
[17:01] <zyga> there are more children but this is the only pipe handling
[17:01] <zyga> (so yay)
[17:01] <mvo> zyga: sweet, shorter
[17:02] <zyga> yes, the test, now devoid of critical typos, is most of the code
[17:02] <zyga> I was thinking about a negative test
[17:02] <zyga> edit-out the sleep and see things work
[17:02] <zyga> but I will let everyone comment first
[17:03] <zyga> I ran main suite successfully with this change
[17:03] <zyga> and, surprisingly, it even works on 14.04
[17:03] <pedronis> zyga: thanks for checking out simplifying the change at least for now, have a bit of head ache so I will let other look at it today, calling it a week
[17:03] <zyga> pedronis: that's a good plan :)
[17:03] <pedronis> have a great weekend!
[17:06] <zyga> pedronis: likewise!
[17:06] <zyga> jdstrand: note, this fixes a private consumer bug, I can subscribe you for context
[17:07] <zyga> jdstrand: done now, you should be able to see the bug
[17:09]  * zyga EOWs
[17:20] <Lukewh> diddledan: We haven't released build.snapcraft.io recently, so I assume magic has made it work for you again. I'm going to leave your bug open as it still needs further investigation. Please update the bug if it happens again!
[17:20] <diddledan> willdo
[17:20] <diddledan> thanks
=== pstolowski is now known as pstolowski|afk
[18:54] <mup> PR snapcraft#2457 opened: lifecyle: avoid installation of snaps in docker <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2457>
=== Howard is now known as Guest24234
[20:24] <mup> PR snapcraft#2458 opened: clean: error out on invalid or missing yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2458>
=== Luke_ is now known as LUke
=== LUke is now known as Luke
[23:16] <mup> PR snapcraft#2459 opened: catkin plugin: describe how to build all packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2459>