[05:08] <mborzecki> morning
[06:14] <mborzecki> mvo: hey
[06:14] <mvo> hey mborzecki - good morning
[06:14] <mborzecki> mvo: do you plan to release 2.35 today?
[06:15] <mvo> mborzecki: yes
[06:15] <mborzecki> ack
[06:19] <mvo> mborzecki: reviews for 2.35 prs would be great, iirc its not that many left
[06:19] <mvo> mborzecki: and 5583 can be ignored and 5340 as well, those will go to 2.36
[06:19] <mvo> mborzecki: oh, I see there are reviews :) yay
[06:22] <mborzecki> mvo: yeah, tried to go through 2.35 ones first
[07:03] <zyga> Good morning
[07:09] <mborzecki> zyga: hey
[07:11] <zyga> *yawn* :-)
[07:11] <zyga> I should make a double espresso
[07:26] <mvo> zyga: heh, yeah, I make a cup of tea as well
[07:30] <zyga> :-)
[07:30] <mborzecki> zyga: quick question, can you take a look at https://paste.ubuntu.com/p/xgQDvNqmtb/ ? i haven't updated apparmor profile yet, so it's expected to fail, the thing i'm a bit suprised is that failure in snap-update-ns does not make the whole thing exit with non-0 status
[07:30] <zyga> Yes that is expected”
[07:30] <zyga> Only layout failures are “loud”
[07:32] <zyga> It is an old decision we took
[07:33] <mborzecki> zyga: ok, so i guess i should make those changes be of 'layout' origin
[07:36] <mborzecki> pstolowski: hey
[07:36] <pstolowski> heyas
[07:38] <zyga> Or change the default
[07:43] <zyga> mborzecki: I mean, the decision was made because we only had the content interface using it
[07:44] <zyga> mborzecki: I would argue that we could reverse the decision now
[07:59]  * zyga goes to find 2fa tokens
[08:06] <Chipaca> moin moin
[08:06] <zyga> hey Chipaca :)
[08:07] <mborzecki> Chipaca: hey
[08:07] <Chipaca> mborzecki: is 2.34 really *that* old, or is something weird going on there?
[08:07] <mborzecki> Chipaca: hm?
[08:08] <zyga> mborzecki: btw, I prepared 2.35 for opensuse
[08:08] <Chipaca> mborzecki: this arch bug on the forum
[08:08] <zyga> but then my opensuse box removed grub
[08:08] <zyga> so I need to recover it but the packaging is ready
[08:08] <zyga> I tested it for about a day
[08:08] <mborzecki> Chipaca: i think it's something odd
[08:20] <mvo> Chipaca: once 5678 has a second review I can release 2.35 for real ;)
[08:20] <mvo> Chipaca: hm, and 5677 it seems
[08:21] <mvo> Chipaca: meh, the later one can go in
[08:21] <Chipaca> mvo: how any +1s do you want on it?
[08:21]  * mvo does that now
[08:21] <Chipaca> mvo: 5678 has a +1 from samuele from 3 days ago and one from maciej from 2 hours ago
[08:22] <mvo> Chipaca: aha, sorry then!
[08:22] <mvo> Chipaca: I was trying to debug this grub xz failure, I think that messed with my brain :(
[08:22] <Chipaca> mvo: good thing the week is nearly over
[08:23] <Chipaca> mvo: the comment about the error message is on point though (but fine for a follow-up imo)
[08:24] <Chipaca> niemeyer: dunno if you saw my question about the limitation in spread about not mixing absolute and relative 'systems' statements
[08:24] <mborzecki> Chipaca: yeah, that forum user has a messed up snapd install from before antergos fixes imo
[08:25] <Chipaca> niemeyer: I'd like to relax it so that you can mix them as long as the absolute come before the relative
[08:25] <niemeyer> Mornings!
[08:25] <mborzecki> Chipaca: at that time we'd just default to /snap instead of /var/lib/snapd/snap and after an update to proper version things go sideways
[08:25] <Chipaca> niemeyer: that way one can say: systems: [ubuntu-*, -ubuntu-14*]
[08:25] <niemeyer> Chipaca: Sounds reasonable
[08:25] <Chipaca> niemeyer: PR coming your way in a bit
[08:25] <niemeyer> Thanks!
[08:37] <Chipaca> niemeyer: 'go test' is failing with errors in humbox, am i holding it wrong?
[08:39] <niemeyer> Chipaca: No, I see them as well, sorry.. humbox is not yet properly finished.. the other end of it, the spread backend itself, still sits on my tree
[08:40] <Chipaca> niemeyer: no worries
[08:40] <niemeyer> Chipaca: Just to make sure, the errors you see are from vet, right?
[08:40] <Chipaca> niemeyer: yes, about printf
[08:40] <niemeyer> Chipaca: COol.. let me fix those quickly
[08:44] <niemeyer> Chipaca: Done
[08:45] <Chipaca> niemeyer: mucho bettero
[08:48] <mborzecki> zyga: hm asking for user.Current() to work in snap-update-ns is probably too much right?
[08:49] <zyga> yes, it will run inside the mount namespace and it will not necessarily see the right /etc
[08:50] <zyga> brb
[09:01] <zyga> re
[09:04] <zyga> pstolowski: I'm going over all of the hot plug branches
[09:06] <pstolowski> zyga: great, thank you! btw, last friday we're discussing the need for a helper such as SystemSnapInfo(), i need to talk yo you about that
[09:06] <zyga> pstolowski: tell me more, what would that do
[09:06] <pstolowski> zyga: can we have a quick HO?
[09:07] <pstolowski> it's related to hotplug
[09:12] <zyga> yes
[09:12] <zyga> sure
[09:12] <zyga> standup?
[09:13] <pstolowski> ok, coming
[09:13] <zyga> eh
[09:13] <zyga> why is google so moronic
[09:14] <zyga> I personally cannot wait until we move off google services :/
[09:17] <niemeyer> I'm particularly frustrated with the new interface of Meet.. it now feels like we're speaking to one or two people, even if there are 10 on the call
[09:33] <mborzecki> zyga: https://paste.ubuntu.com/p/F2hNNVx8HJ/
[09:34] <mborzecki> zyga: it's still a bit ugly on the inside as I need to guess the user's home dir while not beign able to use user.Current() https://paste.ubuntu.com/p/h8RPVFm4RH/
[09:34] <zyga> one sec, in a call
[09:38] <niemeyer> pedronis: Commented on the store scope doc
[09:39] <pedronis> niemeyer: I'm a bit confused by some of the comments
[09:46] <zyga> mborzecki: looking
[09:48] <zyga> mborzecki: hmm, curious
[09:48] <zyga> mborzecki: since we do user mounts, we have to know the user id at least, and presumably more, in a robust way
[09:49] <zyga> mborzecki: how does snap-confine get that today?
[09:49] <zyga> mborzecki: is it a bit of environment that we trust?
[09:49] <mborzecki> zyga: uid is known, but the paths are from snap run (?)
[09:49] <zyga> aha
[09:49] <mborzecki> zyga: s/paths/env vars/
[09:50] <zyga> right
[09:50] <zyga> mborzecki: well, we could do one more thing
[09:50] <zyga> since this is a profile written by snapd
[09:50] <zyga> we can just ask snapd to tell us
[09:50] <zyga> that is, we can bake the variables into the per-user profile
[09:51] <mborzecki> zyga: per user profile?
[09:51] <zyga> yeah
[09:51] <zyga> I mean per user mount profile
[09:51] <zyga> ah
[09:51] <zyga> I'm dumb, sorry
[09:51] <zyga> no we cannot :P
[09:51] <zyga> drat :)
[09:51] <mborzecki> zyga: but you don't know the user at this point
[09:51] <zyga> yeah
[09:51] <zyga> ...
[09:52] <zyga> we could have snapd write authoritative user data per-user
[09:52] <zyga> but ...
[09:52] <mborzecki> bit of chicken and egg :)
[09:52] <zyga> not sure if sensible
[09:52] <zyga> I mean something like /var/lib/snapd/users/zyga
[09:52] <zyga> with authoritative data
[09:52] <zyga> and it would be true inside mount namespaces and what not
[09:52] <zyga> so no need to rely on /etc
[09:52] <mborzecki> zyga: you'd need to know the users upfront
[09:53] <zyga> well, snapd already needs to know
[09:53] <zyga> but yeah, more sprawling complexity there
[10:23] <photex> moin moin! Looking into using snap as an internal app format. Is it possible to run a private snap repo/service?
[10:25] <zyga> photex: hey, you can send private snaps to the store that only you can download, you can also copy a snap and just install it from a file as well; we don't support running a private repository just yet but for bigger deployments you can redirect your device to a private store (which is a commercial offering I believe) where you can locally host snaps that are private to your organisation (locally) and also filter access to the
[10:25] <zyga> main store
[10:28] <photex> Thanks for the info zyga
[10:29] <photex> And can snaps contain services?
[10:30] <zyga> yes
[10:30] <photex> we're specifically looking at snaps as an alternative to deb
[10:30] <photex> which I'd assume you may have guessed :D
[10:31] <mborzecki> zyga: so the spread test that runs snaps, writes some data to SNAP_{DATA,COMMON,USER_DATA,USER_COMMON} works now
[10:31] <zyga> mborzecki: that's great :-)
[10:31] <mborzecki> zyga: obviously non ubuntu host :P now i have to update autogenerated apparmor profile whihc will be a bit of fun i presume
[10:51] <zyga> mborzecki: yeah, it should be doable :-)
[10:54] <mborzecki> is mup quiet again?
[10:55] <mborzecki> https://github.com/snapcore/snapd/pull/5684
[11:10] <zyga> pstolowski: hey, I put hotplug reviews on hold for now, I will fix my PRs so that they land; once I do another pass we should be closer to the key decision wrt system snap
[11:11] <zyga> mvo: we should discuss the system snap concept again
[11:11] <zyga> mvo: I have a feeling that pawel's work needs to solve that
[11:13] <pstolowski> zyga: sure & thanks
[11:21] <mvo> zyga: yeah, I have free cycles one 2.35 is out
[11:23] <mvo> simple review: 5685
[11:23] <mvo> (but important for core18)
[11:27] <zyga> mvo: done
[11:27] <zyga> and back to hacking
[11:28] <mvo> zyga: thank you!
[11:32] <mvo> ogra: I think the latest (edge) snapd fixes the reboot hang, kudos to pedronis
[11:40] <ogra> mvo, will try !
[11:46] <ogra> (VM is running but it might take a while until it refreshes)
[11:53] <ogra> pedronis, mvo, seems to have helped, thanks (havent seen any timeouts this time)
[11:55]  * Chipaca ~> lunch
[12:22] <mborzecki> what part is actually skipped when doing spread -reuse ?
[12:22] <zyga> I think chunks of prepare are skipped
[12:23] <zyga> but also allocation (obviously)
[12:23] <mborzecki> hm got a case when s-c was not being rebuilt when using -reuse
[12:23] <zyga> that's prepare that I mentioned
[12:24] <mborzecki> i'd guess that package is rebuilt but well, maybe not then
[12:25] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/5687 your turf
[12:26] <zyga> hmmm
[12:26] <zyga> will this work if we disable reexecution
[12:27] <zyga> that is
[12:27] <zyga> if future snapd sets SNAP_NAME and SNAP_INSTANCE_NAME
[12:27] <zyga> and somehow old snap-confine is ran
[12:27] <zyga> I know that the answer is "it doesn't work"
[12:27] <zyga> but I wonder how to guard against that
[12:27] <zyga> or if it will happen in practice
[12:28] <mborzecki> zyga: i remember talking to mvo that snap/s-c go in sync
[12:28] <mborzecki> so you either reexec both or none
[12:28] <zyga> anyway, I will think and review
[12:40] <mborzecki> zyga: thanks!
[12:44] <Chipaca> mvo: did we have a problem with x/sys/unix? something about powerpc?
[12:47] <mvo> Chipaca: we had a problem there in 2.35. do we have a new one=
[12:47] <mvo> Chipaca: ?
[12:47] <mvo> Chipaca: do you have more details? 2.35 should be happy everywhere now
[12:48] <Chipaca> mvo: I'm asking because I was wondering whether I could use it or not
[12:49] <mvo> Chipaca: let me try
[12:49] <Chipaca> why did I add the 'or not' there
[12:49]  * Chipaca grabs the dunce hat
[12:49] <mvo> Chipaca: did I mention that my brain got a bit damaged by grub?
[12:49] <mvo> Chipaca: anyway, let me try to login into a ppc machine to test this
[12:50] <Chipaca> we use syscall all over the place :-/
[12:56] <mvo> Chipaca: which package? "syscall"? or "x/sys/unix"?
[12:56] <Chipaca> mvo: x/sys/unix is the one I'd like to use
[12:58] <mvo> Chipaca: hm, there is a bugreport that x/sys/unix is broken with go1.6
[12:58] <Chipaca> mvo: link?
[12:59] <mvo> Chipaca: https://github.com/golang/go/issues/26576
[12:59] <mvo> Chipaca: on powerpc I have proxy issues right now, looking into it
[13:00] <Chipaca> :-(
[13:16] <zyga> mvo: it's interesting because of how that snap (classic) works;
[13:17] <zyga> mvo: should we keep all the variant deltas (core18, core16) inside?
[13:17] <zyga> should those be separate snaps (classic/18)
[13:17] <zyga> etc
[13:22] <mvo> zyga: good questions
[13:23] <zyga> mvo: and to take the question further, what about fedora29 is that is a boot base and you install classic, then what
[13:24] <zyga> mvo: perhaps classic should be a special snap, that can talk to snapd (snapd-control) figure out where it is (which boot base, which environment (classic or core)) and DTRT
[13:24] <zyga> (e.g. download the delta or do something similar)
[13:25] <zyga> mvo: but being executable in the classic snap itself feels like a good idea, then we could do the right thing without having all that logic in snapd
[13:32]  * zyga goes to make coffee while spread runs
[13:48] <mborzecki> Chipaca: could you take a look at https://github.com/snapcore/snapd/pull/5670 later on?
[13:48] <Chipaca> mborzecki: yep
[13:48] <mborzecki> Chipaca: thanks!
[13:56] <zyga> dh_clean fails in spread? https://www.irccloud.com/pastebin/Sp1cvxRD/
[14:05] <mvo> zyga: I have not seen this yet
[14:21]  * zyga -> afk
[14:23] <mborzecki> zyga: when you're back, please take a look at https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/parallel-install-snap-namespace-mapping just to do a sanity check of the changes
[14:23] <alexlarsson> jamesh: I'm updating the flatpak PPA to 1.0, which includes the xdg-desktop-portal 1.0 release
[14:24] <alexlarsson> I'm not sure if updating it for bionic is a good idea though
[14:24] <alexlarsson> Do you want to do that update eventually?
[14:25] <mborzecki> zyga: this works on ubuntu 18.04 running from spread, i've pushed it to the integration branch as well so we'll know if other releases are good too
[14:34] <zyga> Looking
[14:36] <zyga> Mborzecki: there may be one issue there
[14:36] <zyga> Mborzecki is envp big enough? I doubt it is
[14:37] <Chipaca> mvo: can i show you something funny?
[14:37] <Chipaca> mvo: funny but not urgent :-) so no worries if you'd rather be ignorant for a bit longer
[14:38] <sergiusens> Chipaca: is funny the thing we are talking about? 😅
[14:38] <Chipaca> sergiusens: yes
[14:38] <mvo> Chipaca: sure
[14:39] <Chipaca> mvo: try "snap install --channel=latest/stable bofh" (or any snap) (or refresh instead of install)
[14:39] <mvo> Chipaca: heh, it tells me this channel is closed
[14:40] <Chipaca> mvo: :-)
[14:40] <Chipaca> i'll look into fixing it later
[14:40] <mvo> Chipaca: thank you
[14:40] <Chipaca> as soon as this uname thing is green :-)
[14:40] <Chipaca> thanks to sergiusens fwiw
[14:40]  * mvo hugs sergiusens 
[14:40] <Chipaca> refreshing between stable and latest/stable is also fun
[14:40] <Chipaca> we need a "normalize channel name" thing before comparing them
[14:42] <mvo> Chipaca: I think we have something like this
[14:42] <mvo> Chipaca: iirc Channel.Clean() will do that
[14:43] <sergiusens> Chipaca: I have normalizing logic in snapcraft for build snaps because the api does not normalize them for me ;-)
[14:44] <sergiusens> Chipaca: LP: #1787967
[14:59] <Chipaca> sergiusens: ta
[14:59]  * Chipaca pokes mup
[15:00] <Chipaca> niemeyer: ^
[15:00] <niemeyer> Chipaca: Thanks, must have reconnected .. I still haven't managed to fix the nickserv behavior properly
[15:01] <ogra> the spam wave seems to be over though ... perhaps we could remove +r again
[15:02] <niemeyer> mup: Ok now?
[15:02] <mup> niemeyer: Roses are red, violets are blue, and I don't understand what you just said.
[15:03] <niemeyer> Chipaca: ^
[15:03] <Chipaca> mup: <3
[15:03] <niemeyer> ogra: Worth trying, otherwise I'll need to spend some time this week actually fixing that
[15:05] <ogra> niemeyer, actually, looks like someone did that already
[15:06] <ogra> seeems to only be +cnt ... i see no +r
[15:06] <Chipaca> ogra: what does the global +R do?
[15:08] <Chipaca> (block messages from unidentified users)
[15:08] <ogra> Chipaca, +r means registered channel +R means you also need to use an registered nick ... but neither seems to be set here anymore
[15:08] <ogra> so it should be fine for mup for the moment
[15:14] <ogra> Chipaca, for details https://freenode.net/kb/answer/channelmodes
[15:15] <Chipaca> #1787967
[15:15] <mup> PR snapd#5689 opened: many: move Uname to osutil, for more DRY and easier porting <Created by chipaca> <https://github.com/snapcore/snapd/pull/5689>
[15:15] <mup> Bug #1787967: installing from latest/stable tells you latest/stable is closed and tracking stable <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1787967>
[15:15] <Chipaca> k
[15:37] <kyrofa> Hey Chipaca, any chance you could take a look at https://github.com/snapcore/snapd/pull/5655 ?
[15:37] <mup> PR #5655: snap,snap-exec: support command-chain for hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5655>
[16:19] <jdstrand> roadmr: hi! would you mind pulling r1115 of the review-tools? it's all overrides
[16:21] <roadmr> jdstrand: ohai! sure thing, coming up
[16:23] <jdstrand> roadmr: thanks!
[17:23] <Chipaca> kyrofa: tomorrow, i'm afraid
[17:35] <kyrofa> Chipaca, no problem, thanks!
[17:56] <smoser> hey all. someone suggeseted i enable the 'removable-media' plug. is there any reason to not do that?
[17:56] <smoser>  https://github.com/smoser/pdftk/issues/1
[17:56] <zyga> smoser: no, just go ahead and do it
[19:35] <popey> ogra: finally tried wmx, but it doesn't start. https://paste.ubuntu.com/p/PjHX72f2Bx/
[19:41] <jdstrand> roadmr, nessita: hey, I've had two LP generated uploads fail. Eg: https://launchpad.net/~myapps-reviewers/+snap/review-tools/+build/316386
[19:41] <jdstrand> "Store upload failed: Piston/0.2.4 (Django 1.11.13) crash report: Method signature does not match. Resource does not expect any parameters. "
[19:42] <jdstrand> I looked on status.snapcraft.io and...
[19:42] <jdstrand> oh, there it is "
[19:42] <jdstrand> We are experiencing some problems with the Snapstore hosting infrastructure, and are investigating."
[19:42] <nessita> jdstrand, is all the rebootarama on every server
[19:43] <jdstrand> I see, ok
[19:43] <nessita> jdstrand, but I'm not sure your error is related
[19:43] <jdstrand> it is a weird error
[19:43] <roadmr> \o/
[19:44] <roadmr> it's piston, it's all weird
[19:44] <nessita> jdstrand, if you click retry, does it fail consistently?
[19:45] <jdstrand> nessita: I did one retry and it failed. let me try again
[19:46] <jdstrand> nessita: it failed again
[19:53] <nessita> jdstrand, hum, I will try to dig logs
[20:01]  * zyga fixed a very stupid network bug that was driving him crazy
[20:01] <zyga> I had network sharing on one machine and two conflicting dhcp servers
[20:01] <zyga> stuff _sometimes_ worked, depending on luck and off/on status of the other box
[20:01] <zyga> man that was silly and hard to track down
[20:06] <roadmr> Heads up folks - snap store is having some trouble with some operations like some snap pushes, releases, addition of developer accounts. We're looking into it.
[20:11] <popey> ogra: seems if I reboot, wmx is running and I see a mouse pointer, but nothing more.
[20:17] <roadmr> jdstrand: see my latest. Some stuff is broken indeed :( we're looking into it
[20:19] <nessita> jdstrand, hey, can you please retry the review-tools?
[20:19] <nessita> jdstrand, or I can click on the button (I see it, at least :-))
[20:19]  * nessita clicks
[20:28] <nessita> jdstrand, issue fixed
[20:32] <ogra> popey, a left click should bring up a one-entry-menu ... "New" ...
[20:32] <ogra> clicking it starts an xterm
[20:33] <ogra> (and makes that xterm show up in that menu)
[20:33] <popey> no, it's a blank desktop
[20:33] <popey> like, doesn't even look like a desktop is running.
[20:33] <ogra> and nothing if you click ?
[20:33] <popey> nope
[20:33] <ogra> weird
[20:33] <ogra> you did install in devmode ?
[20:34] <popey> yes
[20:34] <ogra> and connected the wayland-socket-dir and and x11-plug interfaces
[20:34] <popey> yes
[20:34] <ogra> very weird
[20:34] <ogra> whcih snap did you use ?
[20:35] <ogra> (it runs fine here in my qemu instance and on a pi)
[20:35] <ogra> i uploaded the one i'm running to the store but the review is stuck atm
[20:36] <roadmr> ogra: stuck or waiting for manual review?
[20:36] <popey> i used the one you linked to
[20:36] <roadmr> ogra: stuck I can help with, waiting for manual, I probably can't :(
[20:37] <popey> https://paste.ubuntu.com/p/XKJfG99Cxr/  ogra
[20:37] <ogra> roadmr, the latter ... the snap uses a llopback x11 plug/scket setup ...
[20:37] <popey> i see no snap called wmx in the store
[20:37] <ogra> the review tools arent happy with that
[20:37] <popey> https://dashboard.snapcraft.io/snaps/wmx/
[20:37] <popey> that shows 404
[20:38] <ogra> popey, no, it is called wmx-kiosk-session
[20:38] <popey> oh
[20:38] <jdstrand> nessita: thanks! sorry, someone was at the door
[20:38] <popey> ok, well it doesn't work here. I have a mouse cursor and that's it
[20:38] <popey> in fact, if i touch the mouse, the cursor disappears
[20:39] <ogra> thats ok ... thats a mir bug
[20:39] <ogra> but you should also get a menu
[20:39] <popey> ooh!
[20:39] <popey> now I do
[20:39] <roadmr> ogra: oh then :( sorry :( would need to wait for someone who knows what they're doing to review it
[20:39] <ogra> \o/
[20:40] <ogra> roadmr, yeah, i know jamie knows how to deal with that ... but it isnt that urgent that i want to push it :)
[20:40] <popey> ogra: is there some graphical thing I should be able to run?
[20:40] <popey> like a desktop snap?
[20:40] <ogra> i havent tried desktop apps ... but htop definitely works
[20:41] <ogra> so should irssi and friends
[20:41] <popey> hm, i have to "snap run" things
[20:41] <ogra> i'm not really sure what happens with desktop apps ... you'd likely need to connect them somehow to the x11 slot
[20:42] <ogra> su popey
[20:42] <ogra> ;)
[20:42] <ogra> switch to the actual user
[20:42] <ogra> that should give you the needed path entry (root doesnt have /snap7bin in path)
[20:42] <popeycore> :)
[20:42] <ogra> ha !
[20:43] <popey> https://usercontent.irccloud-cdn.com/file/PQV1cfQk/IMG_20180820_214251.jpg
[20:43] <ogra> yeah ...
[20:43] <popey> Nice one, thanks ogra :)
[20:43] <ogra> with another "New" you can open mre terminals
[20:43] <ogra> *more
[20:44] <ogra> to run more apps :)
[20:47] <Chipaca> sergiusens: how do I tell mypy to chill?
[20:49] <sergiusens> chipaca: # type: ignore
[20:50] <Chipaca> sergiusens: and, where should I put a yaml module, if I were to write it?
[20:50] <sergiusens> chipaca I think kyrofa might take over your PR
[20:50] <Chipaca> sergiusens: that's fair
[20:51] <sergiusens> chipaca if that speeds up a review for his he might be happier too :-)
[20:52] <Chipaca> sergiusens: that sounds efficient
[20:52] <Chipaca> OTOH, i've checked out of go, and was only looking at mypy because I was curious :-D
[20:54] <sergiusens> oh, add the proper type check then :-)
[20:55] <zyga> jdstrand: re
[20:55] <Chipaca> sergiusens: it looks  like I'll dive into mypy over my staycation
[20:55] <Chipaca> bah
[20:56] <Chipaca> a friend is getting married, also
[20:56] <zyga> jdstrand: not sure if you remember the interface for sharing /mnt, I just updated the PR for that with a simpler approach that just reuses the removable-media; added some more tests and replied / applied all feedback.
[20:56] <Chipaca> so there might be a lot of alcohol involved
[20:58] <jdstrand> zyga: I do and I saw and it is already on my TODO to review
[20:58] <jdstrand> :)
[20:58] <zyga> thank you
[20:58] <zyga> https://twitter.com/zygoon/status/1031646427611578370 :-)
[20:58]  * zyga tries to switch to vim hjkl for navigation
[21:05] <Chipaca> g'night y'all
[21:06] <jdstrand> zyga: nice :) and hjkl is worth it I think (I switched a year or so ago)
[21:07] <zyga> jdstrand: it's nicer in real life, my phone camera doesn't capture the contrast
[21:07] <zyga> plus most keys leave ghosting trail as I type
[21:07] <zyga> it's pure bling but it looks great :D
[21:07] <jdstrand> hehe
[21:07] <zyga> brb, shower time
[21:18] <jdstrand> nessita: fyi, snapcraft release had the same issue as before: bad-request: Piston/0.2.4 (Django 1.11.13) crash report:
[21:18] <jdstrand> Method signature does not match.
[21:18] <jdstrand> Resource does not expect any parameters.
[21:18] <jdstrand> nessita: different from before, retries seemed to help. I am not blocked
[21:26] <roadmr> jdstrand: yes, we just noticed we missed restarting some processes :)
[21:26]  * jdstrand nods
[21:31] <roadmr> jdstrand: done, hopefully solved now but we'll keep an eye on things
[21:44] <sergiusens> jdstrand: zyga hjkl on vi(m) or something else?
[21:45] <sergiusens> I only ever used that, but am on vscode now... contemplating switching back just for navigational purposes
[21:46] <roadmr> I was going to say hjkl sucks for me because I'm left-handed, but the arrow keys which I use just fine *are* on the right side :/ so I guess it's just never getting used to using letters if there are perfectly fine, pointy arrows for that purpose
[21:50] <jdstrand> sergiusens: I was assuming vim
[21:51] <jdstrand> roadmr: hehe :)
[23:42] <cjwatson> ogra: I think I set +q $~a here rather than +r
[23:43] <cjwatson> which is slightly gentler