[05:15] <mborzecki> morning
[07:03] <mvo> good morning
[07:03] <mvo> mborzecki: hey, what did I miss so far :)
[07:04] <mborzecki> mvo: nothing :) i'm the only one online
[07:05] <mborzecki> mvo: unless you want to do a quick pass on https://github.com/snapcore/snapd/pull/6995 ?
[07:06] <mborzecki> mvo: as for the PR title check, what if we dumped the API and used beautifulsoup instead?
[07:07] <mvo> mborzecki: oh, nice idea
[07:07] <mvo> mborzecki: heh :)
[07:07] <mvo> mborzecki: its old school
[07:08] <mvo> mborzecki: scraping the web like its 1994 :P I like this
[07:08] <mborzecki> mvo: all we need is the title
[07:09] <pstolowski> mornings
[07:09] <mborzecki> pstolowski: hey
[07:10] <mvo> pstolowski: good morning!
[07:10] <mvo> mborzecki: yeah
[07:10] <mborzecki> mvo: maybe the stdlib html parser would be enough even
[07:15] <mvo> mborzecki: did you look at the html already? does it look "easy" (sih)?
[07:17] <mborzecki> mvo: https://paste.ubuntu.com/p/PhwG32HG6Q/
[07:18] <mvo> mborzecki: sweeeeeeeet
[07:18] <mvo> mborzecki: thank you so much
[07:20] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6995 ?
[07:21] <pstolowski> sure
[07:21] <mborzecki> pstolowski: thanks!
[07:38] <mborzecki> mvo: remember the weird gadget.yaml from yesterday https://github.com/rpdeo/build-pine64-image/blob/a550cb83ba319b58042599c77548101146059386/snappy/gadget/meta/gadget.yaml ?
[07:38] <mborzecki> mvo: ubuntu-image calculates exactly the same positions as our code does
[07:59] <mvo> mborzecki: good!
[07:59] <mvo> mborzecki: so no risk of regression here
[08:01] <mborzecki> mvo: added a command to dump the info of a positioned volume https://paste.ubuntu.com/p/DSwjDP8zP3/ probably useful for debugging
[08:01] <mvo> mborzecki: nice
[08:01]  * mvo looks
[08:02] <mvo> mborzecki: I updated the pr title check pr
[08:03] <mborzecki> mvo: thanks, looking
[08:05] <mvo> mborzecki: I used the python stdlib to avoid having to worry about pulling in the right dependencies (but that is debatable I guess)
[08:06] <mvo> mborzecki: actually I think I can improve my split, its a bit too silly (probably does not matter much though
[08:07] <mvo> mborzecki: let me do it anyway :)
[08:09] <mborzecki> mvo: and there's ImportError due to lxml
[08:09] <mvo> mborzecki: yeah, just noticed this as well, silly me
[08:10] <mborzecki> mvo: wondering if there's a command line tool for web scraping
[08:10] <mborzecki> mvo: ideally like curl .. | scrape '.head.title' | grep '<match>
[08:14] <mborzecki> mvo: check this out: https://paste.ubuntu.com/p/8R4Wkgdsxs/
[08:15] <mborzecki> mvo: this is the tool: https://github.com/ericchiang/pup
[08:20] <mvo> mborzecki: interessting
[08:41] <mborzecki> mvo: and the PR is green :)
[08:42] <mvo> mborzecki: yay
[08:42] <mvo> now if only the apparmor-id test would not fail :/
[08:42] <mborzecki> appstream-id? :)
[08:43] <mvo> yeah, in my other PR that is ready to land it failed, I suspect the store is not happy but I did not look further yet
[08:43] <mvo> mborzecki: https://paste.ubuntu.com/p/6f2rsHBgyg/
[08:48] <mborzecki> mvo: let me try to add some debug info there
[08:48] <mvo> mborzecki: +1
[08:49] <mvo> mborzecki: its a bit annoying that we actually have no idea what data we got beside "computer says NO"
[08:50] <mvo> mborzecki: we saw failures there a couple of times so definitely useful work to add debug there
[08:58] <mvo> a second review for 6691 would be great
[08:58] <mvo> to unblock ondra on this level
[09:01] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/6996
[09:02] <mvo> mborzecki: thank you!
[09:02] <mvo> mborzecki: do you think you can reply to "support parallel installs on desktop" in the forum? we want to do it but I am not sure where we stand right now (except that we want to do it :)
[09:03] <mborzecki> mvo: mhm, started writing a reply in the morning, but never sent it
[09:04] <mborzecki> mvo: the catch is the classic snaps & paralle installs, the guy mentions build tools, those would be classic usually
[09:04] <mvo> mborzecki: yeah, eactly
[09:05] <mvo> mborzecki: iirc we talked about some minimal fs namspacing around classic to support it(?)
[09:06] <mborzecki> mvo: yes, iirc zyga started looking into it at some point
[09:09] <mvo> mborzecki: ok, I can reply as well in this case, I had hoped you had some more details :)
[09:10] <mborzecki> thunderstorm coming this way, might loose power for a while (hopefully not)
[09:11] <mborzecki> on the upside, it's raining now
[09:11] <pstolowski> mvo: state.json provided for yesterday's bug with current symlink. investigating
[09:11] <mvo> mborzecki: good luck
[09:11] <mvo> pstolowski: sweet, thank you
[09:11] <mvo> pstolowski: please keep me updated
[09:11] <pstolowski> sure
[09:16] <mborzecki> and it's gone, rained for 10 minutes :/
[09:31] <Chipaca> mborzecki: just enough to keep the humidity up \o/
[09:31] <Chipaca> mborzecki: for if you weren't feeling the heat properly
[09:32] <mborzecki> Chipaca: a taste of the tropics for $0
[10:29] <mborzecki> anyone up for a review of this trivial PR https://github.com/snapcore/snapd/pull/6996 ?
[10:31] <Chipaca> why would anybody include a .zip in a snap :-\
[10:32] <Chipaca> mborzecki: WRT that PR, do you have an example run that failed?
[10:33] <mborzecki> Chipaca: i think mvo is the last one to see it fail
[10:33] <Chipaca> mborzecki: I suspect the debug info you want is already in the log, but want to confirm
[10:33] <mborzecki> Chipaca: https://paste.ubuntu.com/p/6f2rsHBgyg/
[10:33] <Chipaca> mborzecki: no, in 'debug output for …
[10:34] <Chipaca> mborzecki: you should have the snapd.service logs
[10:34] <mborzecki> Chipaca: sry, that's all we have, idk which PR that was
[10:34] <Chipaca> ah
[10:34] <mvo> Chipaca: one sec, I find it for you
[10:34] <Chipaca> ta
[10:35] <mvo> Chipaca: https://travis-ci.org/snapcore/snapd/builds/545102574?utm_source=github_status&utm_medium=notification
[10:35] <mvo> Chipaca: in the ubuntu section
[10:37] <Chipaca> mvo: mborzecki: 'context canceled'
[10:37] <mborzecki> Chipaca: timeout on nc side perhaps?
[10:37] <mvo> Chipaca: oh, so it might be a real bug?
[10:37] <Chipaca> mvo: mborzecki: probably
[10:37] <Chipaca> why is it using nc for this :-(
[10:37] <Chipaca> http would be a much better tool
[10:38] <Chipaca> or curl
[10:38] <mborzecki> Chipaca: the test does `nc -U -q 5 /run/snapd.socket`
[10:38] <mborzecki> Chipaca: heh i should fix that probably
[10:38] <Chipaca> mborzecki: 1.949731ms after getting the request, nc hangs up
[10:39] <mvo> ta
[10:39] <Chipaca> k
[10:40] <mvo> Chipaca: this area of the code actually changed, yes? in this pr its about adding context to SnapInfo
[10:40] <mvo> Chipaca: I wonder if there is a side-effect here ./
[10:40] <mvo> Chipaca: it is using the request.Context
[10:40] <Chipaca> mvo: the side effect should be that now we see the error :)
[10:41] <sborovkov> Hi, is there a simple way to bypass this apparmor denial? Does not work in devmode snap as well, and the app I am debugging crashes right after/
[10:41] <sborovkov> apparmor="DENIED" operation="ptrace" profile="snap.network-manager.networkmanager" pid=1387 comm="NetworkManager" requested_mask="trace
[10:41] <Chipaca> before snapd would've carried on waiting for the store, and tried to write the reply, to find that nc had gone away
[10:41] <Chipaca> now we see the error as soon as it happens so we get to see the log, probably
[10:41] <Chipaca> mvo: that's my hypothesis anyway :)
[10:41] <mvo> Chipaca: heh, ok
[10:41] <mborzecki> Chipaca: let's try with curl maybe
[10:41] <Chipaca> mborzecki: k
[10:44] <Chipaca> you get the same denial in devmode?
[10:45] <Chipaca> sborovkov: ^
[10:45] <sborovkov> Chipaca, yes
[10:45] <Chipaca> sborovkov: how do you do that?
[10:45] <sborovkov> screenly-client      1.9.0.0         x6    candidate  -               devmode
[10:45] <sborovkov> I am not sure what actually does that
[10:45] <sborovkov> I updated Qt
[10:45] <sborovkov> now qt webkit crashes
[10:46] <sborovkov> on core
[10:46] <sborovkov> not on raspbian
[10:46] <Chipaca> sborovkov: but that denial is not from the screenly snap, it's from networkmanager
[10:46] <sborovkov> yes, but it seems lijke it's communicating with it?
[10:46] <sborovkov> should I try installing network manager in devmode?
[10:46] <Chipaca> sborovkov: give it a try
[10:46] <mvo> Chipaca: if I change the context that theStore.SnapInfo() gets to context.TODO() the issue goes away. it looks like the http.Request has an (aggressive) cancel context so probably not a good idea to reuse it(?)
[10:47] <Chipaca> mvo: what happens if you use curl instead of nc?
[10:47] <sborovkov> Chipaca, is there a syntax to force it to devmode with the same version of the snap?
[10:47] <Chipaca> sborovkov: unfortunately there is no 'snap switch --devmode', no
[10:47] <Chipaca> sborovkov: but you can 'snap refresh --devmode thesnap'
[10:48] <Chipaca> dunno if it'll do what you need though
[10:48] <mvo> Chipaca: heh, seems to be working
[10:48] <Chipaca> anyway, i gotta go, will bbi1h
[10:48] <sborovkov> that won't work since it has no updates
[10:48] <sborovkov> I will just download the binary and sideload it
[10:48] <mvo> Chipaca: so your theory is correct
[10:49] <Chipaca> sborovkov: i'd suggest asking on forum.snapcraft.io, as zyga and/or jdstrand might be the best people to look into this
[10:51] <Chipaca> sborovkov: (and they might not be around at the same time as you)
[10:52]  * Chipaca really steps away now
[11:19]  * pstolowski lunch
[11:20] <mborzecki> Chipaca: updated https://github.com/snapcore/snapd/pull/6996 to use curl now
[11:28] <pedronis> Chipaca: could you answer this: https://forum.snapcraft.io/t/install-snaps-backup-or-export-and-relocation-to-new-pc/11777
[11:28] <pedronis> it's also probably in the wrong category
[12:50]  * Chipaca writes <BLINK> for the first time in ages
[12:50]  * Chipaca goes to have a quick shower before the standup because this smell will travel over hangout
[13:07] <jdstrand> pedronis: hi! I'm at the snapcraft summit and we discussed this topic and was wondering if you can comment on it soonish: https://forum.snapcraft.io/t/new-base-snap-nix-base/11787/2
[13:08] <jdstrand> pedronis: I'm heading into a meeting, but can discuss via the forum or here. zyga can also speak to it
[13:08] <kenvandine> zyga: I have a snap that's failing to update
[13:09] <kenvandine> https://www.irccloud.com/pastebin/fWXYWFf1/error%3A%20cannot%20perform%20the%20following%20tasks%3A%20-%20Setup%20snap%20%22snap-store%22%20(111)%20security%20profiles%20(cannot%20setup%20mount%20for%20snap%20%22snap-store%22%3A%20cannot%20update%20mount%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20preserved%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20snap%20namespace%3A%20no%20such%20file%20or%20direc
[13:09] <kenvandine> tory)%20-%20Setup%20snap%20%22snap-store%22%20(111)%20security%20profiles%20(cannot%20update%20mount%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20preserved%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20snap%20namespace%3A%20no%20such%20file%20or%20directory)
[13:09] <kenvandine> that was noisy :)
[13:09] <zyga> kenvandine: hey
[13:09] <zyga> kenvandine: wow, that's indeed noisy
[13:10] <zyga> kenvandine: I'm at an event now and I cannot  focus on this; two small requests please: does it fail on edge core/snapd snaps and if so, can you please file a bug with the details
[13:10] <kenvandine> i have revision 117 installed and trying to refresh to 136
[13:10] <kenvandine> ok
[13:10] <zyga> thank you
[13:13] <pedronis> jdstrand: I'll see what I can do, I skimmed and to be honest I was a bit confused by it
[13:21] <kenvandine> zyga: fails with edge too.  See bug 1832725
[13:32] <mborzecki> mkfs wrapper https://github.com/snapcore/snapd/pull/6997
[13:38] <cjp256> any know of a method to fetch a snap from the store for arch different from the running system?
[13:39] <Chipaca> cjp256: yes
[13:39] <Chipaca> cjp256: UBUNTU_STORE_ARCH=i386 snap download core16 --edge
[13:39] <cjp256> thanks chipaca! :)
[13:39] <Chipaca> cjp256: (from my bash history)
[13:40] <Chipaca> we should add an --arch, but, eh
[13:40] <Chipaca> priorities
[14:08] <zyga> kenvandine: thank you,
[14:10] <Chipaca> I've just been called to the boys' school, need to run off
[14:10]  * Chipaca runs off
[14:10] <Chipaca> of course it was just when my tea was _perfect_
[14:11] <zyga> kenvandine: can you perhaps send the the two revisions
[14:12] <zyga> mvo: hey
[14:12] <mvo> hey zyga
[14:12] <zyga> mvo: do you want to sync quickly or are you find with waiting for next week?
[14:12] <kenvandine> marcustomlinson couldn't reproduce it
[14:12] <kenvandine> so it's something with my system
[14:12] <kenvandine> i even removed snap-store, installed stable and tried refreshing to candidate
[14:12] <kenvandine> blew up
[14:13] <mvo> zyga: if you have anything important we can chat otherwise friday/next week is fine
[14:13] <zyga> mvo: ok,
[14:14] <zyga> mvo: just good news :)
[14:14] <zyga> mvo: I posted a small PR https://github.com/snapcore/snapd/pull/6998
[14:14] <mvo> looking
[14:14] <zyga> we're building an image with those patches for testing
[14:14] <zyga> jamie also posted on the forum about nixos base snap
[14:14] <zyga> and if there's any confusion about that I'd love to clear it up (interactively)
[14:14] <zyga> so that nix can continue
[14:15] <zyga> mvo: manjaro will seed snaps on the iso
[14:15] <zyga> mvo: I'd like to spend a moment with someone to walk me through snap prepare-image --classic
[14:15] <mvo> zyga: manjaro switches to /snap from /var/lib/snapd/snap ? do we need to do anything about this transition?
[14:16] <mvo> zyga: on our side I mean, or is that just handlded in the packaging?
[14:16] <mvo> zyga: I mean when users upgrade
[14:16] <zyga> mvo: yes, we do
[14:16] <zyga> mvo: it's in the patch
[14:17] <zyga> mvo: that's more tricky, I think this kind of transition is tough in general
[14:17] <zyga> mvo: I think you need to remove and reinstall snaps
[14:17] <zyga> mvo: I'd like to change how we probe distributions
[14:17] <zyga> but it's not something we need this week
[14:26] <kenvandine> zyga: http://people.ubuntu.com/~ken-vandine/snap-store.tar.bz2
[14:28] <zyga> mvo: we're discussing the migration path
[14:29] <zyga> we don't have a good story for migration
[14:32] <mvo> ok
[14:41] <zyga> mvo: we are working on a migration script
[14:41] <zyga> kenvandine: thank you
[14:44] <mvo> zyga: ok
[14:50] <pedronis> zyga: what's the question about prepare-image --classic ?
[14:51] <zyga> pedronis: I'd like understand how to use it
[14:51] <zyga> pedronis: so that manjaro can use it correctly to preseed the snap store stap
[14:59] <pedronis> zyga: it's relatively straighforward, it might not do the right thin yet if you have only core18 snaps though, and you need to specify all bases and all content providers and a model
[14:59] <zyga> pedronis: we only want to seed the snap-store snap
[15:00] <zyga> so if you walk us through that that would be amazing
[15:00] <Chipaca> mvo: d'oh, did /v2/download _just_ miss out on having context from day 1
[15:00] <zyga> right now we (I learned) use a shell implementation of prepare-image that Wimpress shared
[15:00] <zyga> and I'd be much more comfortable with the proper approach
[15:09] <pedronis> zyga: something like this (ATM):  https://pastebin.ubuntu.com/p/9fm4p6Rvy9/
[15:10] <zyga> looking
[15:10] <pedronis> as I said atm is fetching core instead of snapd
[15:10] <mvo> Chipaca: :/ I think so
[15:10] <zyga> pedronis: does it fetch generic.model?
[15:10] <Chipaca> mvo: (d'oh)³
[15:10] <zyga> or do we need to get it somehow
[15:10] <pedronis> zyga: no
[15:10] <pedronis> that is like for core
[15:11] <zyga> how can we get it?
[15:11] <pedronis> zyga: snap known model on a ubuntu system for example
[15:11] <pedronis> or they can make a model
[15:11] <pedronis> but for that they need brand account and keys
[15:11] <zyga> pedronis: do you recommend that  they make a model?
[15:11] <zyga> we could do that
[15:12] <pedronis> if they want and are comfortable managing the keys
[15:12] <zyga> could you or someone else walk us through the process?
[15:13] <pedronis> zyga: they need a brand account if they really want this, I would chat with your store person there
[15:13] <zyga> that's what we will do
[15:13] <zyga> once we have that, what else do we need
[15:14] <noise][> +1 for them to have a distinct model
[15:14] <pedronis> create a key,  register it, backup ~/.snap/gnupg
[15:15] <zyga> pedronis: we'll work with daniel
[15:15] <zyga> pedronis: and then we need to craft a model file?
[15:15] <zyga> I'm not familiar with that process
[15:16] <pedronis> there should be instructions around
[15:16] <pedronis> given that is for classic it needs the bare minimum
[15:16] <pedronis> like our generic one
[15:19] <Chipaca> zyga: you there?
[15:19] <zyga> Chipaca: yes
[15:19] <Chipaca> zyga: https://forum.snapcraft.io/t/request-for-a-base-snap-for-godot/11808/5?u=chipaca
[15:19] <Chipaca> zyga: i don't understand
[15:19] <Chipaca> zyga: maybe i'm missing something
[15:20] <Chipaca> zyga: you were there, maybe there's more context than is stated in the post, that i'm missing?
[15:20] <Chipaca> or maybe there's something i'm ignorant of
[15:21] <zyga> Chipaca: I can explain over a call?
[15:21] <Chipaca> zyga: wfm
[15:21] <zyga> pedronis: do we need a vault?
[15:21] <zyga> pedronis: or can we keep authority-id as generic?
[15:21] <pedronis> ah
[15:21] <Chipaca> zyga: https://meet.google.com/fbb-gvae-mda?authuser=1
[15:21] <pedronis> forgot about
[15:21] <pedronis> that
[15:21] <pedronis> so no
[15:21] <pedronis> they should just use generic
[15:21] <pedronis> they would need a vault otherwise
[15:22] <zyga> oh
[15:22] <zyga> hmmm
[15:22] <pedronis> we cannot sign serial for them
[15:22] <pedronis> by definition
[15:22] <zyga> I understand
[15:24] <Chipaca> zyga: i'll go make tea then
[15:24] <zyga> Chipaca: stanndup
[15:24] <zyga> or meet
[15:25] <zyga> https://meet.google.com/wmp-dfwj-jdt?authuser=0
[15:25] <cmatsuoka> mvo: I have a few unpushed recovery fixes (written in airport & plane), will test and push tonight after the event
[15:36] <mvo> cmatsuoka: please do, I get errors that partition 4 cannot be created right now
[15:42] <cmatsuoka> mvo: hmm, current HEAD was supposed to be functional (at least able to create everything and install), I'm running prepare on a new directory to see what's happening
[15:47] <zyga> pedronis: quick question: can we today create a snap that can be content shared by anyone but is not published by canonical?
[15:48] <zyga> pedronis: the use case is the godot runtime support snap for anyone publishing games via godot
[15:48] <pedronis> zyga: yes, it's a matter of setting up the right snap-declaration
[15:48] <pedronis> that's how we do it also for canonical snaps
[15:48] <zyga> excellent, thank you
[15:48] <zyga> CC Chipaca ^
[15:48] <zyga> we were just discussing that and wanted to double check with you
[15:48] <Chipaca> zyga: pedronis: ah! good, phew
[15:49] <Chipaca> zyga: pedronis: for some reason i was still stuck in the 'publisher is the same, or is "canonical"' world
[15:49] <Chipaca> glad that's moved on :)
[15:55] <mvo> cmatsuoka: thanks! its a bit cryptic, the error just says "Could not create partition 4 from 23606048 to 3920448" no reason why is given :/
[15:56]  * cachio afk
[15:56] <pedronis> Chipaca: for content, canonical is not special I think, it's really same publisher or overriden by the declaration
[15:56] <cmatsuoka> mvo: will check that and report back as soon as I have everything downloaded and built
[16:01]  * Chipaca goes for a walk
[16:01] <mvo> cmatsuoka: thank you, I will have dinner and check back
[16:13] <mvo> cmatsuoka: looks like my core-build checkout was not in the writable-ramdisk PR
[16:13] <mvo> cmatsuoka: eh, branch, let me try to figure out why
[16:13] <cmatsuoka> mvo: oh ok that explains the problem
[16:13] <mvo> cmatsuoka: yeah, sorry for the noise
[16:14] <cmatsuoka> mvo: still building here, slow network and slow cpu
[16:14] <cmatsuoka> mvo: the recent fixes are related to extracting the kernel and initrd from the snap
[16:15] <mvo> cmatsuoka: thanks
[16:16] <cmatsuoka> mvo: so recovering using a different kernel version was still booting with the original kernel (I didn't notice because in my tests I used the same kernel in both recoveries)
[16:17] <cmatsuoka> mvo: to go through the entire recovery cycle selecting a different recovery version you'll also need the pc gadget on writable-ramdisk to recognize a new "recovery_reboot" snap mode
[16:17] <mvo> cmatsuoka: I merged/uploaded your pc-gadget changes to 20/edge
[16:17] <cmatsuoka> this can be handled in a different way but that was the least intrusive one (but still required some changes in the grub configuration)
[16:18] <cmatsuoka> mvo: ah nice, thanks
[16:18] <mvo> cmatsuoka: I'm cleaning my dir now to ensure I have all the right checkouts now
[16:19] <pedronis> have the re-reg managers_test test passing, need some cleanups though (and a likely a couple follow ups)
[16:32] <jdstrand> pedronis: do you have a moment to talk about nix-base?
[16:36] <pedronis> jdstrand: I read the description more carefully, it seems ok if a bit of a degenerate (as used in math terminology) case
[16:36] <zyga> mvo: do we use snapd snap by default nonw?
[16:37] <jdstrand> pedronis: nix is quite unique in that nix packages ship only the libs they need and everything is mounted under /nix
[16:37] <jdstrand> pedronis: so there is nothing needed in there. hence the analogy to static binaries and the bare base snap
[16:38] <jdstrand> pedronis: anyhoo. can you comment in the forum that you are ok with it?
[16:40] <cmatsuoka> mvo: the re-prepared version worked here to install, didn't try recover yet
[16:40] <pedronis> jdstrand: do you know why it needs the /nix directory in it, we don't let layout create directories at that level?
[16:41] <jdstrand> pedronis: the ayouts feature does not allow creating toplevel directories under /
[16:41] <pedronis> ok
[16:41] <jdstrand> pedronis: it is a limitation of the implementation
[16:42] <pedronis> jdstrand: it would be good if the topic mentioned this for clarity
[16:42] <jdstrand> I can add that detail
[16:44] <jdstrand> pedronis: done
[16:49] <jdstrand> pedronis: it isn't clear if you approve this (I haven't approved the snap due to this discussion)
[16:56] <pedronis> jdstrand: sorry, it took a bit to understand where the comment was added, I added a comment myself
[16:57] <jdstrand> pedronis: thanks!
[17:11]  * Chipaca EODs
[18:01] <mvo> zyga: we don't auto-transition people yet but if you only have core18 we install it
[18:02] <mvo> cmatsuoka: yeah looks good
[20:07] <albertosottile> jdstrand: hi, any chance you could review our answer in the Syncplay classic confinement request topic?
[20:13] <jdstrand> albertosottile: I commented in the topic. It is now moving forward and there is one more step (publisher vetting; cc popey_ and Wimpress)
[20:13] <jdstrand> https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189/12
[20:14] <albertosottile> jdstrand: understood, thanks. Please let me and Et0h know if we can assist in any way during the vetting
[20:36] <popey_> albertosottile: done
[20:37] <albertosottile> popey_: thanks!
[20:38] <popey_> no problemo
[20:40] <jdstrand> albertosottile: granted. please see the forum comment
[20:41] <albertosottile> jdstrand: thank you :) We will submit another revision asap
[20:41] <jdstrand> albertosottile: cool. sorry it took so long. it was a bit of a different use case for classic and we wanted to make sure we considered everything
[20:42] <jdstrand> albertosottile: thank you for your patience :)
[20:42] <albertosottile> jdstrand: I totally understand
[20:42] <albertosottile> We also wanted to ask for an alias for a syncplay-server command, is now the right time to do so?
[20:43] <jdstrand> albertosottile: yes. that will go quickly. please make a request in the forum
[20:43] <albertosottile> Sure
[20:48] <albertosottile> jdstrand: https://forum.snapcraft.io/t/alias-request-syncplay-server/11821