=== jamesh_ is now known as jamesh
[10:32] <rbasak> Skuggen: o/
[10:33] <Unit193> I like how they all ping out at once. :D
[10:33] <rbasak> Meet thedac who is looking into using mysql-shell around OpenStack
[10:33] <rbasak> He's excited about the snap I think you just published?
[10:33] <thedac> Hey, Skuggen.
[10:33] <Skuggen> o/
[10:33] <thedac> I'll test out your snap today
[10:34] <Skuggen> Yeah, I made a fairly trivial one. Since shell is a fairly straightforward client app it doesn't need to be all that complex, but one issue is that it can't access the socket file right now (except in devmode)
[10:35] <Skuggen> And should probably have a mysqlsh alias, since that's the standard command
[10:37] <rbasak> I'll leave you two to it now that you're connected. Thank you for working on all of this!
[10:37] <rbasak> Let me know if you need anything please.
[10:37]  * rbasak goes to lunch
[10:38] <Skuggen> rbasak: Np!
[10:38] <thedac> Skuggen: I'll see if there is a local socket plugin for snapcraft.
[10:39] <thedac> And I'll get back to you after I get a chance to test with your version of the snap. Is there a github repo for the snapcraft.yaml that I might be able to contirbute to?
[10:40] <Skuggen> Do you know if there's any general file access plugins? The efforts to make a MySQL server snap some time ago stranded because I couldn't get it to work right on a system level
[10:40] <Skuggen> We do have a repo for the old server snap (which I might look into getting updated), but don't have the shell yaml uploaded there now
[10:41] <thedac> Not off the top of my head, but I'll get back to you. --classic is always a mid step. That gives you normal access to the file system.
[10:42] <thedac> OK, I should be able to get back to you in a couple of hours
[10:43] <Skuggen> https://paste.ubuntu.com/p/DPvjT43DWY/ is all there is to the yaml right now :)
[10:43] <Skuggen> Ok, sounds good!
[10:43] <thedac> Perfect. Thanks. Talk to you soon.
=== cpaelzer_ is now known as cpaelzer
[12:23] <rbasak> xnox: I don't understand your git-ubuntu bug request.
[12:23] <rbasak> xnox: maybe while you're here we can chat in person?
[12:23] <rbasak> The three people around this table think you're asking for three different things.
[12:35] <xnox> rbasak:  hahahhaha
[12:35] <xnox> rbasak:  where?
[12:36] <rbasak> xnox: we're in the server room
[12:36] <xnox> ok
[12:36] <thedac> Skuggen: I am running out of day (we are cutting out early)
[12:36] <thedac> I have tested your snap and it seems to be working. We both derived the exact same solution with one exception. I had the following for the apps section w
[12:36] <thedac> hich allows for the msyqlsh command and network access: https://pastebin.ubuntu.com/p/SN8B78bG3
[12:36] <thedac> Regarding local sockets. Here is some hints on running the server:
[12:36] <thedac> https://snapcraft.io/docs/snapcraft-yaml-reference
[12:36] <thedac> Search for apps.<app-name>.socket
[12:36] <thedac> And by using the common area both the server and the client can find the socket in strict confinement:
[12:36] <thedac> https://forum.snapcraft.io/t/sharing-a-unix-domain-socket-between-a-daemon-and-an-app/12332
[12:36] <thedac> Ultimately, my goal for the mysql-shell snap is to build it for multiple architectures, which requires compiling from source. If you have any hints on com
[12:36] <thedac> piling the shell let me know.
[12:36] <thedac> I will ping you next week when I have more info. Feel free to DM me an email address and we can work to get this it great shape.
[12:37] <thedac> Skuggen: That link was broken. This is correct: https://pastebin.ubuntu.com/p/SN8B78bG39/
[12:45] <Skuggen> Ah, yeah will need network access of course
[12:48] <Skuggen> Building from source would be better, yeah. It shouldn't be all that complicated, but will need to check the exact dependencies. I'll take a look at adding the socket support and getting that working, plus setting this up in git
[12:49] <Skuggen> Also, we only test upstream for amd64, i386 and arm64 builds, so possible we'll run into some issues with other archs
[12:58] <thedac> OK, good to know. Sounds like a plan. I'll touch base next week.
[19:22] <LocutusOfBorg> Unit193, your fix in http://launchpadlibrarian.net/335155209/bzr-fastimport_0.13.0+bzr361-1_0.13.0+bzr361-1ubuntu1.diff.gz will disappear post eoan...
[19:22] <LocutusOfBorg> do you have any idea?
[21:09] <Unit193> LocutusOfBorg: So I saw, at least that brz didn't have the fix.  I'm just presuming nobody cares about bzr/brz enough at this point, a lot of Ubuntu stuff moved to git.
[21:21] <cjwatson> Unit193: jelmer is being pretty active in maintaining brz.  Did you ever send the patch their way?  Might be worth a resend if so.
[21:22] <cjwatson> (fastimport has always been pretty hairy of course ...)
[21:55] <Unit193> cjwatson: The patch was picked out of three bug reports, I did create a MR back in '15 which he commented on though.
[22:06] <cjwatson> Just saying that what I'm seeing at the moment doesn't suggest that a presumption of nobody caring is valid.
[22:38] <Unit193> Fair, perhaps fastimport is somewhat neglected instead.
[23:42] <jelmer> Unit193: we do care about fastimport bugs in breezy; I'm not aware of any open merge requests or bug reports related to it
[23:44] <Unit193> jelmer: There's not one in brz, just an old one in bzr.  Good to know!  I haven't used brz (yet), but I don't use bzr much.