[06:55] <zyga>  Hello
[07:02] <zyga> :)
[07:02] <zyga> man it's all snowy white today :)
[07:15] <mborzecki> morning
[07:15] <zyga> hey mborzecki, mvo
[07:16] <zyga> I almost typed "hey mup", but we don't greet mup :/
[07:16] <mvo> hey zyga
[07:17] <mborzecki> mvo: zyga: hey
[07:17] <mvo> hey mborzecki
[07:23] <mborzecki> 61 PRs
[07:26] <mup> PR snapd#6429 opened: Bboozzoo/section rename 2.37 <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6429>
[07:26] <mborzecki> mvo: ^^ need this for 2.37 branch too
[07:27] <zyga> I will do some reviews today
[07:32] <jamesh> hi mvo, zyga
[07:35] <mvo> hey jamesh
[07:35] <mvo> mborzecki: ok, I have a look and will cherry-pick
[07:35] <mborzecki> mvo: opened a PR to 2.37
[07:35] <mvo> mborzecki: I also need to cherry-pick the find fix
[07:36] <mborzecki> mvo: but feel free to close if you prefer to cherry-pick and push manually :)
[07:37] <mvo> mborzecki: yeah, did cherry pick some minutes ago, but still thanks for noticing
[07:38] <mup> PR snapd#6429 closed: tests/searching: handle renamed video section <Simple 😃> <Created by bboozzoo> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6429>
[07:48] <zyga> hey jamesh
[08:40] <mup> PR snapd#6348 closed: snap: split alignment calculation and display for channels <⛔ Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6348>
[08:51] <mborzecki> Chipaca: pedronis: updated #6016
[08:51] <mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
[08:55] <Chipaca> mborzecki: oh no! now what do I do with my "z" snap?
[08:56] <mborzecki> Chipaca: you make it go zzz
[08:56] <Chipaca> about half of my registered names are answers to "i wonder if the whole stack catches me trying to register this name we decided was invalid"
[08:56] <Chipaca> (hint: mmmmmmaybe?)
[08:58] <mborzecki> Chipaca: btw. we allow 2 letter names right? :P plenty of combinations
[09:00] <mborzecki> Chipaca: pushing a little tweak, dropped *Name suffix where it seemed a bit sueprfluous given that the package is called 'naming'
[09:00] <Chipaca> hmm
[09:00]  * Chipaca looks
[09:00] <Chipaca> yes that works
[09:01] <jamesh> mvo: where do you want to have the meeting?  IRC, hangouts, something else?
[09:02] <mvo> jamesh: meet should be ok, I sent you an invite
[09:02] <mvo> jamesh: sorry that it was not on the original thing
[09:38] <pedronis> mborzecki: hi, Q for you in 6016
[09:39] <mborzecki> pedronis: right, i tried to keep the diff size under control, so introducing the package and indirection felt right as a first step
[09:39] <Chipaca> pedronis: with removing the store info cache (btw any better names appreciated) from being tasks, I'm moving them out of backend and into snapstate itself (like seq is already), ok?
[09:40] <pedronis> Chipaca: it's fine out backend
[09:40] <pedronis> mborzecki: can you work on a follow up to remove the indirection ones when you havea bit of time
[09:40] <Chipaca> pedronis: should I read that as "it's fine not in backend"?
[09:41] <pedronis> Chipaca: yes
[09:41] <Chipaca> pedronis: ok :-)
[09:41] <pedronis> missing a "of", at least
[09:41] <Chipaca> pedronis: spent a little time with nltk looking for the intersection between synonyms of 'container' and 'blob', with no luck
[09:41] <mborzecki> pedronis: sure :) planned to do it all along
[09:44] <pedronis> Chipaca: ok, seems "naming" is reasonable tough
[09:44] <Chipaca> pedronis: yes <3
[09:54] <pedronis> Chipaca: did you see my #6389 comment ?
[09:54] <mup> PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
[09:54] <Chipaca> pedronis: yes
[09:54] <Chipaca> pedronis: thank you
[09:54] <Chipaca> pedronis: need to get to that yet
[09:55] <pedronis> ok
[09:58] <zyga> FYI I will be away for the next few hours,
[10:08] <mborzecki> oh, codecov is back
[10:12] <mup> PR snapd#6421 closed: spread: enable upgrade suite on fedora <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6421>
[10:16] <pedronis> Chipaca: looked at #6356, doesn't seem inline with the requirements, what we discussed originally
[10:16] <mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
[10:17] <sil2100> mvo: hey! Did you see Pat's and Cody's e-mail about trusty snap preseeding? I'm not really knowledgable in these areas and thought maybe you had some leads/ideas
[10:18] <oSoMoN> how do I build a core snap from a PR that adds a new interface, to test it locally?
[10:21] <mvo> sil2100: I did see it, but haven't managed to look at it yet :(
[10:26] <sil2100> mvo: busy times, no worries! It might be something wrong from the image build POV, but I'd like a snappy expert to first take a look and see if there's anything obviously wrong there
[10:40] <mborzecki> Chipaca: /var/lib/snapd/sequence is something from snapshots?
[10:40] <Chipaca> mborzecki: nop
[10:41] <Chipaca> mborzecki: it's a cache of <snapstate>.Sequence
[10:41] <Chipaca> used for recovery iirc
[10:42] <mup> PR snapd#6427 closed: interfaces: add block-devices interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6427>
[10:42] <mborzecki> Chipaca: hm, didn't notice this before, snapd arch package does not clean it up properly for some reason
[10:42] <Chipaca> mborzecki: missing diff in cmd/snap-mgmt/snap-mgmt.sh.in ?
[10:43] <mborzecki> Chipaca: nah, it's not accounted for in the package, so removing the package leaves the dir behind
[10:44] <mborzecki> Chipaca: snap-mgmt only removes /var/lib/snapd/sequence/*
[10:44] <Chipaca> mborzecki: when you get a diff, show me? because I need to do something similar for /var/cache/snapd/store i suspect
[10:44] <Chipaca> mborzecki: unless you mean it doesn't remove the director itself?
[10:44] <mvo> 6408 needs a second review, hopefully simple
[10:46] <mborzecki> Chipaca: snap-mgmt removes all of /var/cache/snapd/*
[10:48] <mup> PR snapd#6424 closed: tests: remove -o pipefail <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6424>
[10:48] <Chipaca> mborzecki: why doesn't it remove all of /var/lib/snapd?
[10:48] <mborzecki> Chipaca: because fedora packaging takes care of this with %dir entries in rpm spec
[10:49] <mborzecki> Chipaca: there is no equivalent on arch, so dirs are precreated when package is built and then automatically revmoed by pacman
[11:21] <zyga> re
[11:26] <mborzecki> mvo: got a node when console-conf@ttyS0 keeps restarting
[11:29] <mvo> mborzecki: what is the systemctl status / jounralctl log output?
[11:29] <mvo> mborzecki: any interessting error message
[11:29] <mup> PR snapd#6408 closed: tests: add spread test for system dbus interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6408>
[11:30] <mborzecki> mvo: no, the log is rather useless https://paste.ubuntu.com/p/CHH2m9k6t5/
[11:31] <mborzecki> mvo: hm looking at the full log, there might be a pattern though
[11:31] <mvo> mborzecki: how did you trigger it?
[11:32] <mvo> mborzecki: my naive way did not work :/
[11:32] <mborzecki> mvo: https://paste.ubuntu.com/p/qyGfvxNrmh/
[11:32] <mvo> mborzecki: aha, maybe different machines
[11:32] <mborzecki> mvo: notice how reloads are interleaved with console-conf restarting
[11:33] <mvo> mborzecki: indeed
[11:33] <mvo> mborzecki: that looks suspicious
[11:33] <mborzecki> mvo: note, i'm installing and removing 11 snaps in parallel in a separate shell
[11:34] <mvo> mborzecki: interessting
[11:34] <mvo> mborzecki: is this all the logs we get? Jan 25 11:24:45 jan251115-985265 systemd[1]: serial-console-conf@ttyS0.service: Failed with result 'exit-code'. is really not helpful, not even the exit code numbe
[11:34] <mvo> r
[11:34] <mborzecki> mvo: yup
[11:35] <mvo> mborzecki: nothing in journalctl -u serial-console-conf@ttyS0.service or systemctl status -l serial-console-conf@ttyS0.service :( sad
[11:35] <mvo> mborzecki: I guess you can't strace it as this all happens too quickly?
[11:37] <zyga> mvo: what is the value you saw from exit code?
[11:37] <mvo> zyga: looking at the logs from mborzecki I see nothing there
[11:42] <mup> PR snapd#6430 opened:  tests: enable debian sid as part of the main suite on travis <Created by mvo5> <https://github.com/snapcore/snapd/pull/6430>
[11:50] <mborzecki> mvo: heh, reloading daemon makes console-conf fail, wtf?
[11:51] <mvo> mborzecki: yeah, that is … unexpected
[11:56] <mborzecki> mvo: https://paste.ubuntu.com/p/ZsCjMDdQNC/ confole-conf-wrapper started by agettu
[11:57] <mborzecki> mvo: fd 0 is /dev/ttyS0
[12:04] <mborzecki> mvo: another one showing what it writes to stderr https://paste.ubuntu.com/p/ht5v7QhPxC/
[12:05] <mvo> zyga: do you know/remember the switch to drive sbuild so that it is as close as possible to the buildds?
[12:06] <mvo> mborzecki: aha, nice
[12:06] <zyga> you have to change .sbuildrc
[12:06] <mvo> mborzecki: "write(2, "/usr/share/subiquity/console-conf-wrapper: line 62: read: read error: 0: Resource temporarily unavailable\n", 106) = 106"
[12:06] <zyga> to build arch indep separately AFAIK
[12:06] <zyga> mvo: but I strongly recommend something else
[12:06] <zyga> mvo: please look at and improve this: https://github.com/snapcore/snapd/pull/6410
[12:06] <mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
[12:06] <mvo> zyga: well
[12:06] <zyga> you can test it there :)
[12:06] <zyga> it's just a fire&forget
[12:06] <mvo> zyga: I'm looking at a spread test
[12:06] <zyga> (for experimenting)
[12:07] <zyga> I mean, to get to the point where we can be certain 2.37-2 reproduces the failure
[12:07] <zyga> just feed the 2.37-2 package to this script
[12:07] <zyga> and see if it fails
[12:07] <mvo> zyga: the arch indep ?
[12:07] <zyga> if so, that's representative of what we know so far
[12:07] <zyga> yes
[12:07] <mborzecki> mvo: yeah, then it proceeds to run stty, waits for it, waits for any children and exits, maybe it's how this works? the sequence seems legit
[12:08] <mvo> zyga: but that is "just" doing a normal sbuild without any extras, no?
[12:08] <zyga> correct
[12:08] <zyga> I suggested that as a vehicle to find out which setting in sbuild controls this to reproduce the failure
[12:08] <mvo> zyga: we did this as well and for us it did not fail
[12:08] <zyga> I think it's just one of the variables you can set there
[12:08] <mvo> zyga: aha, ok
[12:09] <zyga> I don't know the answer from the top of my head
[12:09] <zyga> sorry :/
[12:09] <zyga> I just recall reading the example file
[12:09] <zyga> and this is something you can tweak there
[12:09] <zyga> I believe we need to run a pair of builds then though
[12:09] <mvo> zyga: all parts of the example are commented out :/
[12:10] <zyga> maybe               --no-arch-all
[12:10] <zyga> http://manpages.ubuntu.com/manpages/bionic/man5/sbuild.conf.5.html
[12:10] <zyga> by default they are built
[12:11] <mvo> zyga: yeah, I play around, thank you
[12:11] <mvo> zyga: but lunch first :)
[12:11] <zyga> I mainly recommended that script because you  can get to the part where you can tinker easily
[12:11] <zyga> and it is reproducible
[12:28] <zyga> mvo: the thing is https://salsa.debian.org/debian/snapd/commit/7991e731c068148de7ae1b9e99d8df4e6f45601e
[12:28] <zyga> --no-arch-any
[12:28] <zyga> that's what you need
[12:34] <Chipaca> pedronis: pushed changes to the store info cache. This change makes it a lot smaller; need to update the description though
[12:34] <Chipaca> pedronis: but, one more change I think I should make: I should make the cache be per snap id, not per  snap name
[12:36] <pedronis> Chipaca: sounds reasonable
[12:36] <Chipaca> pedronis: making it per snap name would  be more friendly but not sure if we care
[12:36] <Chipaca> could include the name in the json if that helped? (would it?)
[12:37]  * Chipaca thinks it'd be fine as is but with snap id
[12:39] <pedronis> Chipaca: we don't want people to rely on this, so it shouldn't matter
[12:39] <pedronis> Chipaca: I mean, it should be a snap detail, not something people use, no?
[12:39] <pedronis> *snapd detail
[12:39] <Chipaca> right
[12:39] <Chipaca> and tomorrow we couold change it to be a sqlite or something
[12:41] <pedronis> yes
[12:41] <pedronis> mborzecki: reviewed 6333
[12:41] <mborzecki> pedronis: thanks
[12:44] <pedronis> mborzecki: anything blokcing #6403 ?
[12:44] <mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
[12:46] <mborzecki> pedronis: not really
[12:47] <mborzecki> mvo: are we ok to land 1.9+ things?
[13:01] <rbasak> sergiusens: around? About https://irclogs.ubuntu.com/2018/12/18/%23snappy.html#t02:09
[13:01] <rbasak> If you are, then I'll catch up on any upstream changes to the problem since, and if it's still there I'd appreciate some of your time please.
[13:02] <rbasak> Hmm I say that but the problem appears to have gone away for now. Presumably requirements.txt changed again.
[13:03] <sergiusens> rbasak: if you use a base, it is a list, if you do not, it is a string when using 3.x
[13:03] <rbasak> However it would be nice to know how to solve it properly and/or register it as a shortcoming in snapcraft's Python plugin if appropriate.
[13:03] <sergiusens> rbasak: and fwiw, the deb is going to stick to 2.x
[13:04]  * Chipaca goes to have lunch
[13:35] <mup> PR snapcraft#2451 opened: static: address black warnings <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2451>
[13:45] <mvo> mborzecki: yes, we are ok
[13:45] <mup> PR snapd#6431 opened: snapcraft.yaml: fix snapcraft building in launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/6431>
[13:46] <mup> PR snapd#6403 closed: many: cleanup golang.org/x/net/context <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
[13:47] <mup> PR snapd#6430 closed:  tests: enable debian sid as part of the main suite on travis <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6430>
[13:57] <jdstrand> zyga: hey, don't bother adding your backlight to the PR, I've got a better idea
[13:58] <Chipaca> jdstrand: should I mark that pr blocked? it's green and has two +1's, somebody'll land it otherwise :-)
[13:58] <jdstrand> Chipaca: I just did, thanks!
[13:59] <zyga> jdstrand: ack
[13:59] <zyga> jdstrand: I really wish sysfs wasn't a maze of symlinks :)
[13:59] <Chipaca> jdstrand: github here disagrees, but i guess eventual consistency is eventual
[13:59] <jdstrand> Chipaca: I *just* did it after you suggested it
[14:00] <Chipaca> jdstrand: reloading it and still not seeing it :)
[14:00] <Chipaca> anyway, i'm off to the standup
[14:12] <Chipaca> degville: 2010 says hi: https://r.chipaca.com/the_cult_of_done_manifesto.png
[14:13] <degville> thanks Chipaca!
[14:13] <degville> done is definitely better than perfect.
[14:17] <Chipaca> zyga: "shall I compare thee to seccomp" -- mvo, probably
[14:24] <Chipaca> zyga: https://en.wikipedia.org/wiki/Singularity_(operating_system)
[14:25] <zyga> I love the shade of blue they used
[14:47] <Chipaca> zyga: https://wiki.debian.org/X32Port FWIW
[14:48] <Chipaca> zyga: but alas debian-x32.org is no more
[14:48] <Chipaca> anyhooo
[14:50] <Chipaca> zyga: mborzecki: and i was wrong about the kernel it seems. Had the worng end of the stick on this. Sorry for the noise.
[15:02] <mvo> mborzecki: re 6422 - you write that you can reproduce hte mount issue without the change in the PR. does that mean with the change (i.e. when console-conf is disabled) the mount issue is no longer there?
[15:03] <mborzecki> mvo: it's still running
[15:03] <mvo> ta
[15:05] <mborzecki> mvo: so a core 18 node was up for ~1h and didn't error out
[15:06] <mborzecki> mvo: need to go out now, but i'll spin another one and let it run
[15:06] <mvo> Chipaca: do you know if 6280 is ready for a second review? or is there something fundamental that needs discussion still?
[15:06] <mvo> mborzecki: ta
[15:06] <mborzecki> mvo: this is the script i'm using if you want to try it yourself too https://paste.ubuntu.com/p/rXDvJgFShf/ imo it's bit more aggressive than the test we have
[15:06] <mvo> mborzecki: so a core18 node without console-conf (with console-conf disabled) survived 1h ? that sounds encouraging
[15:07] <mvo> mborzecki: thanks, looking
[15:07] <Chipaca> mvo: I think pedronis unblocked it because it's ok
[15:07] <mvo> Chipaca: it got my +1 - its (IMHO) an easy win, would love to see itin
[15:08] <mvo> so if someone looks for a fun review: 6280 (/me clearly works on is marketing skillz)
[15:10] <roadmr> I bet it's a trap
[15:18] <pedronis> Chipaca: mvo: yes, nothing fundamental against it (also now that --unicode is fixed for non-tty)
[15:31] <pedronis> mborzecki: +1 to 6016 but some comments there
[15:43] <zyga> re
[15:43] <zyga> dinner done, now onwards
[15:53] <r4co0n> Since a few months, sound is no longer working in my snapped Firefox, but other applications can still produce sound. This is running Debian buster. I haven't tested other sound-producing snaps, though. (repost from #snapcraft)
[15:53] <kenvandine> r4co0n: how about the chromium snap?
[15:54] <r4co0n> kenvandine, I'll go install and test. I got chromium installed via apt and it is working fine.
[15:54] <zyga> r4co0n: hey
[15:54] <zyga> r4co0n: we've made an upload to buster recently, 2.37-3 will be coming your way soon (tm)
[15:54] <zyga> r4co0n: would be great if you could check once that is released
[15:55] <zyga> r4co0n: or get it from the incoming pipe if you want
[15:55]  * cachio lunch
[15:56] <r4co0n> zyga, I'm still on 2.36-3, let's see when this comes to my mirror.
[15:57] <zyga> r4co0n: it's not migrated yet
[15:57] <zyga> r4co0n: can you look at your journal output, perhaps there are some denials or something similar?
[15:57] <zyga> r4co0n: I can try locally in a moment
[15:57] <mup> PR snapd#6412 closed: tests: interfaces tests normalization <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6412>
[15:58] <Chipaca> pedronis: got a bit to talk about the triggering logic for rere?
[16:01] <r4co0n> zyga, kenvandine, sound is working in the chromium snap.
[16:01] <pedronis> Chipaca: I have a meeting noew
[16:01] <Chipaca> pedronis: my condolences
[16:02] <zyga> Chipaca: let's just head to the pub then ;)
[16:02] <Chipaca> yeah
[16:02]  * Chipaca puts on his boots
[16:03] <mvo> zyga: I added sbuild spread test now
[16:03] <zyga> woot, I'm going through reviews now, but I can look at this out of band if you want
[16:06] <r4co0n> How can I run the firefox snap in safe mode, with all plugins disabled? I tried gathering it from the help and a websearch, but found nothing.
[16:06] <zyga> r4co0n: no idea, sorry
[16:06] <kyrofa> r4co0n, zyga, kenvandine might be able to help
[16:08] <r4co0n> I can start with --ProfileManager and create a new profile
[16:08] <r4co0n> Not exactly the same, but problem solved.
[16:09] <r4co0n> But no sound in a new profile :/
[16:11] <r4co0n> zyga, you were talking about some journal output I can be checking? How do I do that? I ran the snap from the terminal and there is nothing remarkable showing up...
[16:11] <mvo> 6431 is a very easy review
[16:11] <mvo> *please*
[16:12] <pedronis> Chipaca: the meeting was short, didn't quite happen
[16:12] <r4co0n> btw, the same snap continues to work fine on Debian stretch.
[16:12] <r4co0n> Similar setup.
[16:13] <r4co0n> Other system.
[16:14] <kenvandine> r4co0n: maybe different versions of snapd though
[16:14] <Chipaca> pedronis: wrt "only do refreshes that would change epoch again", I would have to check with the store about updates, and then decide client-side whether to do the update or not depending on whether an epoch change happened?
[16:15] <kenvandine> r4co0n: is it connected to the pulseaudio interface?
[16:15] <kenvandine> check "snap interfaces firefox"
[16:15] <Chipaca> pedronis: I understand that there's a small window where a snap changes its epoch and then refreshes without changing the epoch and this would re-refresh "early" (not sure why it's a problem), but having to decide client-side whether to do a refresh the store told me to do seems wrong?
[16:16] <r4co0n> kenvandine, yes ':pulseaudio              chromium,firefox'
[16:17] <r4co0n> Could reinstall help anything?
[16:19] <r4co0n> The thing is, I am using every other part of this snap just fine everytime I'm at this system. It's just those odd YouTube,etc. moments when I get aware of this problem again.
[16:20] <kenvandine> r4co0n: did you try chromium?
[16:20] <r4co0n> kenvandine, yes I did and it works there
[16:22] <kenvandine> well that's odd
[16:22] <kenvandine> r4co0n: what version of firefox?
[16:23] <mup> PR snapd#6419 closed: miscellaneous policy updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6419>
[16:23] <mup> PR snapd#6420 closed: miscellaneous policy updates - 2.37 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6420>
[16:25] <mvo> 6417 is another simple review
[16:25] <mvo> (we just need a second one :)
[16:27] <r4co0n> kenvandine, it's 64.0.2-1 (167) with no available upgrades on stable
[16:31] <kenvandine> r4co0n: same as me
[16:34] <mvo> Chipaca: if you are around - can I merge 6400 (nice number!) or is there anything missing? I did a quick test on the UX and it looks reasonable to me
[16:35] <mvo> Chipaca: nice job btw, really like this
[16:35] <r4co0n> I got KDE reporting  in Audio Volume Applications that 'No applications playing or recording audio' before I start audio in firefox snap, and 'AudioIPC Server' showing up as an application as soon as I start the audio stream.
[16:35] <r4co0n> The volume is non-zero.
[16:35] <Chipaca> mvo: ooh, you did the ux thing?
[16:35] <Chipaca> mvo: let me look
[16:35] <Chipaca> mvo: nice. It won't be translated, but at least it's not lying :-)
[16:36] <Chipaca> mvo: pedronis had Opinions about the naming of things, but not sure if they were blockers
[16:36] <Chipaca> ErrNoExpectedResult instead of ErrStoreUnresponsive
[16:36] <Chipaca> although ErrNoExpectedResult is wrong; it'd be ErrMissingExpectedResult
[16:37] <Chipaca> but, as i say,  dunno if a blocker
[16:37] <kenvandine> r4co0n: so it's trying to do something
[16:38] <mvo> Chipaca: hm, hm, both seem ok to me. no strong opinion
[16:38] <mvo> Chipaca: anyway, should be landable once this is clarified
[16:38] <Chipaca> mvo: thanks
[16:39] <mvo> Chipaca: you trapped me, now I'm thinking about a good name for the last 5min
[16:40] <pedronis> Chipaca: yes, it's a blocker
[16:40] <r4co0n> kenvandine, with Chromium, it is showing the application name 'Chromium' almost(?) immediately, sound is at the same level, and I hear stuff.
[16:41] <r4co0n> Testing with the top-left link on YouTube, btw.
[16:41] <pedronis> Chipaca: I mean, I really don't like unresponsive there
[16:41] <pedronis> Chipaca: do you want me to explicitly -1 it ?
[16:41] <mup> PR snapd#6363 closed: cmd/snap-update-ns: save errno from strtoul <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6363>
[16:42] <Chipaca> pedronis: it wouldn't be necessary now that i know you think it's a blocker
[16:42] <Chipaca> pedronis: but it does communicate that unambiguously :-)
[16:42] <Chipaca> i wish the store returned 420 instead of bogus responses, fwiw
[16:43] <pedronis> Chipaca: done
[16:43] <Chipaca> this is again us heuristicating things
[16:43] <kenvandine> r4co0n: gnome also shows firefox as Audio IPC Server
[16:43] <kenvandine> but i can hear it
[16:44] <pedronis> Chipaca: once we alway have rerefresh , we have to do something to chose when to reupdate
[16:44] <mup> PR snapd#6432 opened: interfaces: add block-devices interface - 2.37 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6432>
[16:45] <r4co0n> kenvandine, funny side story, I purged it yesterday after having not used it for quite some months. But I still run it on my laptops.
[16:45] <r4co0n> Would have been nice for testing now.
[16:45] <pedronis> Chipaca: you are already checking if epochs are equal  (in the common code, which I don't think is where we want to make the choice)
[16:46] <pedronis> Chipaca: I'm saying that needs to be postponed plus extra recheck in the task itself
[16:46] <mvo> down to 53 open PRs - lets see if we can hit 50 today!
[16:49] <pedronis> Chipaca: we can chat more on Monday
[16:52] <pedronis> Chipaca: Missing works for me
[16:56] <pedronis> jdstrand: hi, could you look at #6376
[16:56] <mup> PR #6376: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
[16:57] <jdstrand> pedronis: yes, I started yesterday and will pick up in a bit
[17:03] <mup> PR snapd#6433 opened: tests: Update fedora 29 workers to speed up the whole testing time <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6433>
[18:01] <kyrofa> Hey ogra, does the Ubuntu Core image support the rpi 3B+ ?
[18:10] <cwayne> Yes
[18:10] <cwayne> kyrofa: ^
[18:10] <kyrofa> cwayne, thank you, I suppose you ARE the person to ask these days, eh?
[18:11] <cwayne> So I've heard :)
[18:11] <kyrofa> Ha!
[18:36]  * cachio afk
[18:42] <zyga> re
[18:43]  * zyga fell asleep, sorry :(
[19:16] <zyga> Chipaca: https://github.com/google/gops
[19:16] <zyga> shiny
[19:31] <mup> PR snapd#6425 closed: interfaces: add u2f-devices interface and allow reading udev +power_supply:* in hardware-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6425>
[19:32] <mup> PR snapd#6432 closed: interfaces: add block-devices interface - 2.37 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6432>
[19:32] <mup> PR snapd#6433 closed: tests: update fedora 29 workers to speed up the whole testing time <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6433>
[19:38] <mup> PR snapcraft#2449 closed: Release changelog for 3.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2449>
[19:49] <mup> PR snapd#6434 opened: interfaces: add u2f-devices interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6434>
[20:04] <mup> PR snapd#6435 opened: interfaces: add display-control interface - 2.37 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6435>
[21:36] <mup> PR snapcraft#2452 opened: Fix typo in comments <Created by Lin-Buo-Ren> <https://github.com/snapcore/snapcraft/pull/2452>