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