[06:45] morning [06:48] hey mborzecki [06:49] mvo: did you get my messages yesterday? [06:54] mborzecki: yes, interessting results [06:55] mvo: even though just a few interfaces are connected, we compile bpf for every declared plug [06:56] mborzecki: yeah, thta seems very wasteful [06:57] mvo: w8, hm i got it wrong, it's compiling bpf for each app, and that snap has plenty of apps [07:00] mvo: still, it's weird, looking at the log, we connect opengl, but still compile new profiles for apps that don't declare opengl [07:05] mborzecki: oka === pstolowski|afk is now known as pstolowski [08:03] mornings [08:04] pstolowski: hey [08:12] mvo: thanks for the review of hotplug pr! [08:12] pstolowski: my pleasure [08:24] moin all [08:39] hey Chipaca - good morning [08:50] mvo: addressed your comments re #6465 ; regarding open points (the Specification stuff), we agreed with pedronis that it will be addressed in a followup, so once you're happy about the resolution of your suggestions this PR can land [08:50] PR #6465: overlord/ifacestate: hotplug-add-slot handler [08:50] pstolowski: cool, looking [09:19] pstolowski: I added feedback to 6322 as well (not sure if you saw it) [09:19] Chipaca: hi, could double check my last changes to #6469 [09:19] PR #6469: image,cmd/snap,tests: introduce support for modern prepare-image --snap [=] [09:20] mvo: yes i saw it, will get to it later today, thank you [09:21] pstolowski: thanks, no rush [09:40] PR snapd#6465 closed: overlord/ifacestate: hotplug-add-slot handler [09:40] yay \o/ [09:40] great! [09:41] * pstolowski reading my master theis about selinux from 2008. real journey to the past ;) [09:42] pstolowski: nice [09:43] kenvandine: hi Ken, not sure if my message was posted here yesterday because I had connection issues. Any news about building GTK 3.24 for GWE? https://forum.snapcraft.io/t/support-for-gtk-3-24/9782/6 [09:49] PR snapd#6484 opened: debian: ensure leftover usr.lib.snapd.snap-confine is gone [09:50] mvo: review of #6478 would be great [09:50] PR #6478: overlord/ifacestate: tweak logic for generating unique slot names [09:50] pstolowski: have you merged master? [09:51] xnox: I updated lp 1814141 - if you could double check the PR that would be great [09:51] mvo yes [09:51] ta [09:54] Chipaca: have you applied all feedback to #6034 or is it still wip ? [09:54] PR #6034: many: save media info when installing, show it when listing [09:57] mvo: ty! [10:02] pedronis: i think it's ready [10:02] pedronis: "Specify extra snaps from store or local or optionally control the channel to track for a snap" [10:02] pedronis: hmm [10:03] Chipaca: it was there before [10:03] pedronis: i missed it before :-) [10:03] I mean, I didn't change it in this last commit [10:03] yeah [10:03] I moved a bit out [10:03] but not changed it [10:04] pedronis: thank you for the value-name change, makes things nicer [10:04] yea [10:04] Chipaca: about your other PR, I asked because loadStore seems still there ? [10:04] pedronis: we can i18n that if you want, fwiw (would take abit of coding similar to other things) [10:05] i thought i'd changed that [10:05] * Chipaca checks [10:05] dang [10:05] Chipaca: anyway at least that help sentence for --snap should use the singular now [10:05] I think [10:05] pedronis: sorry, will fix in a bit [10:06] Chipaca: np [10:07] pedronis: maybe, Include this snap (optionally controling the channel it tracks); may be from store or local [10:08] pedronis: but, I'd also say something about repeating it [10:08] because the help doesn't [10:08] I wish it did :-/ [10:08] the help sucks [10:08] prepare-image-OPTIONS what [10:08] Chipaca: but you can control also the channel of a snap you are not including [10:08] :-/ [10:08] that is also already included [10:09] yeah [10:11] Have this snap track the given channel (default: latest/stable); if not present, include it from store or local file [10:11] if not already included*? [10:12] re [10:14] Chipaca: pushed something [10:14] a bit different [10:15] pedronis: +1 [10:17] Chipaca: yes, the prepare-image-OPTIONS is not beautiful [10:17] that's go-flags though, no? [10:17] yes [10:17] and, you'd think we could just set Usage to override that [10:18] but https://github.com/jessevdk/go-flags/issues/264 [10:18] heh (me has stopped making optimistic/navie assumption about that package long ago) [10:20] yeah, no navy assumptions [10:21] naive :P [10:23] no u [10:28] PR snapd#6406 closed: tests: enable debian sid as part of the main suite on travis [10:28] PR snapd#6413 closed: packaging: import debian salsa packaging work, add sbuild test and use in spead [10:28] down to 39! [10:32] Chipaca: the description (future commit message) needs updating as well [10:32] yep [10:32] it's going to get squashed, but yes [10:34] Chipaca: also my two comments about the undo logic seems unanswered [10:35] pedronis: i answered them in my head, does that count? [10:35] * Chipaca looks at the pr again [10:35] Chipaca: .5 cookie [10:35] * Chipaca could have second breakfast [10:36] pedronis: actually, which two? [10:36] Chipaca: https://github.com/snapcore/snapd/pull/6034#discussion_r254207769 and https://github.com/snapcore/snapd/pull/6034#discussion_r254207844 [10:36] PR #6034: many: save media info when installing, show it when listing [10:37] pedronis: ah, phew [10:37] pedronis: answered [10:38] that wasn't undo, that was cleanup of do [10:38] ;) [10:38] mwhudson: the debian packaging of salsa is now part of our tree in packaging/debian-sid and we use that for automatic testing - juts fyi - so on the next merge you can hopefully just "git mv package/debian-sid debian" and then we are in sync and we can just cherry-pick/merge your changes back into our tree (and vice-versa) [10:39] PR snapd#6478 closed: overlord/ifacestate: tweak logic for generating unique slot names [10:40] Chipaca: ah, this: TestDoLinkSnapFailureCleansUpAux [10:40] pedronis: ye [10:41] it's a bit chummy with the implementation in how it triggers the failure [10:41] but i reckon it's good enough [10:43] naming tweaks landed as well, and #5962 updated with master and ready for reviews. i'll prep followup with the simplification of spec [10:43] PR #5962: ifacestate/hotplug: hotplug handlers [10:43] Chipaca: +1 with 1 nitpick, it needs a 2nd review tough because I think it changed too much since zygmunt looked at it [10:44] (I dismissed already his review) [10:44] pedronis: agreed [10:45] pedronis: there's an obvious followup up to this with categories [10:46] Chipaca: btw, do we really need the store bit in "store/aux" , other things under cache also come from the store already, no? [10:46] pedronis: good point [10:47] we could s/aux/aux-info/ if it's clearer, not sure [10:59] PR snapd#6485 opened: interfaces/seccomp: regenerate changed profiles only [10:59] mvo: ^^ [10:59] mvo: there are some numbers in the PR description [11:10] Morning mvo. I have a font related query regarding snapd. [11:10] It doesn't appear to be possible to user installed or user local fonts in classic snaps. [11:11] Wimpress: only in classic snaps? [11:11] For examples, if I install fonts in ~/.fonts, ~/.local/share/fonts or /usr/local/share fonts I am unable to use them in the code-insiders snap, which uses classic confinement. [11:12] mborzecki: Right now, I'm only interested in a classic snaps. [11:12] Wimpress: have you tried using them in a classic snap that doesn't use the desktopy parts? [11:12] Chipaca: There are no desktop helpers in the code-insiders snap. [11:13] ah [11:13] mborzecki: nice, looking [11:13] Wimpress: in classic confined snaps, that is slightly unexpected [11:14] Glad you say that, because I thought so too. [11:14] There is an upstream bug raised against VSCode. I am investigating. [11:15] Wimpress: silly question, what do I need to do to reproduce? [11:15] Wimpress: I have vscode, how to instlal a local font? [11:15] * mvo feels like a real n00b [11:16] Install a monospaced font to a user location, such as ~/.fonts or ~/.local/share/fonts and then be able to set that font in the VSCode font preferences. [11:16] mvo: git clone https://go.googlesource.com/image [11:17] `Ctrl+,` to open preferences. [11:17] mvo: and copy the resulting image/font/gofont/Go-Mono*.ttf to ~/.fonts [11:17] :-) [11:17] Wimpress: trying that now [11:17] leinardi: we're still working on that. Once we figure out the gtk build failure in the build snap i'll give you a patch that adds it to your snap [11:18] leinardi: oSoMoN is looking into that now [11:18] Wimpress: do you know if any other classic snaps are affected too? eg. atom maybe? [11:18] I have checked any others, but I can. [11:20] *haven't [11:23] http://paste.ubuntu.com/p/SCRGVsgCnq/mvo: got external:ubuntu-core-18-arm-32:tests/core18/compat failure on pi3; will re-run manually ; have you seen it failing before? full log: [11:23] The font being referenced in the upstream bug is this - https://github.com/tonsky/FiraCode/releases/download/1.206/FiraCode_1.206.zip [11:23] mvo: http://paste.ubuntu.com/p/SCRGVsgCnq/ [11:24] pstolowski: yes, I think its the same as yesterday, i.e. there is a core installed in the state but not on disk because prepare/restore do crazy stuff [11:25] I've also tried rebuiling font cahces using `fc-cache -f -v` and `/snap/core/current/bin/fc-cache-v6 -f -v` and `/snap/core/current/bin/fc-cache-v7 -f -v` [11:26] Wimpress: this is slightly mysterious, so I ran: "snap run --shell vscode" and in there gnome-font-viewer and I see the go fonts there but I don't have them in vscode [11:26] mvo, Install `code-insider` instead. It is published by Microsoft. [11:27] But yes, I am seeing the same issue. [11:27] code-insiders* [11:27] Although I using `mate-font-viewer` ;-) [11:28] Yes, sorry. [11:28] Wimpress: haha [11:28] Wimpress: no worries [11:28] Trying the atom snap. [11:28] Wimpress: trying code-insiders now, *maybe* its related to the framework they use? [11:28] Wimpress: I will try to run it outside of snap, just from local dir next [11:29] Does fc-cache-v7 and fc-cache-v6 run in the root context when a snap is installed. [11:29] yeah, fc-list works fine inside the snap [11:30] Wimpress: fwiw, they really should consider using ubuntu mono as their defualt font [11:30] Wimpress: yes [11:30] Chipaca: You ran that from within the Code terminal, right? [11:30] Wimpress: it runs as root but that should not matter, its just a cache [11:31] um [11:31] it picks up the font just fine [11:31] Running `fc-list | grep Fira` from within the Code terminal does show me the user installed fonts from ~/.fonts [11:32] Wimpress: also running vscode without confinement (just ./bin/electron-launch ...) gives me the same result so it looks like its not our fault(tm) :) [11:32] Chipaca: So, if you change the Editor: Font Family in Code, you can see any open files rendered using that font? [11:32] Wimpress: https://i.imgur.com/N333CRv.png [11:34] Chipaca: Please can you confim the Fira Code font also works for you? [11:34] I'll try the Go font you suggested here. [11:34] Wimpress: I don't have Fira [11:34] isn't that the one with all the funky ligatures? [11:36] I use the vscode snap with Fira, if that helps [11:36] Wimpress: does Fira Code work on 16.04? [11:38] tomwardill: Where did you install the Fira font? [11:38] sec, checking [11:38] Chipaca: I can't get the Go font to render. [11:38] Wimpress: what are you putting in settings? [11:38] ...in the code-insiders snap. [11:38] `'Go', 'Droid Sans Mono', 'monospace', 'Droid Sans Fallback'` [11:38] Wimpress: the font is called Go Mono [11:38] Wimpress: I have it install via the apt package [11:39] tomwardill: OK, thanks. system wide fonts are working fine. [11:39] The issue here user installed fonts in ~/.fonts for example. [11:40] ah, sorry, missed that context in scrollback [11:40] np :-) [11:41] Wimpress: https://imgur.com/a/Rz26nPz [11:41] Wimpress: fira code works [11:42] using the fonts-firacode deb package from bionic [11:42] Wimpress: I'm on 16.04 [11:42] ah [11:42] oh [11:42] Chipaca: aha, using the deb [11:42] I am on 18.10 [11:42] removing the deb, moving the fonts to local dir, 1 sec [11:42] * mvo also tested on 18.10 [11:42] Ah, you have the deb. [11:42] Chipaca: aha, ok [11:46] mvo: Wimpress: removed the deb, downloaded the .ttf and put them in .fonts, it works [11:46] Works on 16.04? [11:46] yes [11:46] hey [11:46] Wimpress: what do you have in your fonts dir? [11:46] Wimpress: and, what are you putting in settings [11:46] * zyga pops in briefly for the last day of his "holiday" break [11:46] zyga: shoo go coo at a baby [11:46] mvo: I will send the patches that you requested in a moment [11:47] Chipaca: the baby is still at the hospital, not coming home yet, still sick :( [11:47] zyga: :'( [11:47] Chipaca: not serious but must stay for a few more days [11:47] https://www.irccloud.com/pastebin/xysZGLIn/ [11:47] how are fires this week? [11:47] Those are the fonts I have in ~/.fonts [11:47] zyga: ta [11:47] mwhudson: thank you for the debian upload, I was going to make one but I'm super happy to see it's done :) [11:47] zyga: good luck [11:47] Wimpress: yep, got those also [11:48] zyga: packaging is merged [11:48] :) [11:48] Wimpress: and in your settings? [11:48] Chipaca: I will test on a 16.04 VM [11:49] `'Fira Code', 'Droid Sans Mono', 'monospace', 'Droid Sans Fallback'` [11:49] Wimpress: and if you put just: Fira Code [11:49] Wimpress: no quotes, no list, no nuthin' [11:49] (that's what i have) [11:50] It is not Fira Code rendering the test I do that. [11:50] Looks like Courier. [11:50] yeah it's very obvious when it's not finding it [11:50] it uses a proportional font, even, at least here [11:50] (but i probably don't have courier new) [11:51] Wimpress: I'll try on 18.04 here and report back [11:51] Chipaca: thanks. I'll give 16.04 a go. [11:55] Wimpress: works on 18.04 as well [11:56] Wimpress: with both Go Mono and Fira Code [11:56] Wimpress: ligatures and all [11:58] mvo, noted. I'll feed that back. [11:59] regarding using ubuntu mono as a default. [12:01] Wimpress: ta [12:02] Wimpress, Chipaca interessting - works for me on 18.04 as well [12:02] Chipaca: popey confirms Fira Code in working on 18.04 with the code-insiders snap. [12:02] I tested with the go fonts and vscode snap [12:02] broken in 18.10 for me [12:02] https://usercontent.irccloud-cdn.com/file/GGM2tbAk/Bootiful%20font%20on%2018.04 [12:02] yeah, same here, no fun on 18.10 [12:03] I figured I had configured it wrong all this time >.< [12:03] Thanks for the confirmations. [12:04] i just booted an 18.10 vm... [12:04] fc-list from within the code inbuilt shell (ctrl+`) doesn't show the font I've configured [12:04] but i appear to have picked the wrong vm [12:04] https://usercontent.irccloud-cdn.com/file/n1NdD344/does%20this%20support%20snaps%20%3B)%20 [12:05] from within the inbuilt vscode shell (ctrl+`) https://www.irccloud.com/pastebin/PNe8FQgQ/ [12:06] oh, I lie, it is there.. just intermixed with all the others even though it is in my locala fonts dir [12:06] fura code regular [12:07] could it be, in my case, that I'm using an otf font? [12:09] diddledan: I only have "installed" the ttf version oof Fira Code in ~/.fonts [12:09] aah ok [12:10] I'm using the repacked fira code by nerd fonts [12:12] added DejaVu Sans Mono as a fallback when it can't find fura code regular and it looks sooo much better :-p [12:12] I think it uses a bitmap font when none of the ones in the list are found [12:12] ugly jaggies [12:15] Ok, font looks bad on 18.10 [12:15] https://usercontent.irccloud-cdn.com/file/CS7igM08/Screenshot%20from%202019-02-08%2012-15-14.png [12:16] choosing ubuntu mono works fine [12:17] yours is decidedly more pretty https://usercontent.irccloud-cdn.com/file/IunzHJTb/image.png [12:19] I miss hidpi when I'm on this desktop :-( [12:26] just move the monitors 2m away [12:31] Wimpress: so [12:31] Wimpress: I can confirm it's not finding the font in 18.10 [12:31] Wimpress: but [12:31] Wimpress: putting the full path to the font works [12:32] Whhhhaaaaat?! [12:32] Wimpress: dude try it :-) [12:32] Full path to a ttf? [12:32] yes [12:33] Wimpress: what was another snap that didn't find local fonts in 18.10? [12:34] I can't confirm your workaround. [12:34] Wimpress: why? [12:34] `/home/martin/.fonts/FiraCode-Regular.ttf, 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback'` [12:34] Does not render using Fira. [12:34] Wimpress: just the path, nothing more [12:35] I have no idea what the rules are for quoting and enumerating in that text entry [12:35] "nothing more"? that *is* the path [12:35] booting the cd up again just in case [12:35] WHat is your font settting? [12:35] popey: all the things after the comma, remove them [12:36] those are the defaults that vscode supports [12:39] doing this in a vm all over again is very slow [12:39] Atom also has the same issue [12:42] booting with kvm, putting just /home/ubuntu/.fonts/FiraCode-Medium.ttf [12:42] it picks it up [12:42] doesn't get ligatures [12:43] in code [12:43] I can try atom next if you want? [12:47] specifying the full path to the font on 18.10 does not work here [12:47] it defaults back to a variable width font [12:48] Just tested with pycharm-community snap. Also classic but implemented using Java, not Electron. [12:48] I can set the editor font to Fira Code on 18.10 just fine. [13:18] * pstolowski lunch === ricab is now known as ricab|bbl [13:38] Hello, maybe a silly question - how do I run snapcraft 3 on a VM? It requires multipass but multipass won't run on a VM and all of my build servers run in cloud... [13:48] PR snapd#6469 closed: image,cmd/snap,tests: introduce support for modern prepare-image --snap [=] [13:50] sil2100: ^ https://forum.snapcraft.io/t/evolving-prepare-image-syntax/5988/4 what was mentioned on Tue === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [13:53] pedronis: excellent [13:54] I'll pick that up for ubuntu-image, possibly next week [13:54] thank you [14:03] Issue # closed: core18#56, core18#86, core18#89, core18#117 [14:03] PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98 [14:04] Issue # opened: core18#56, core18#86, core18#89, core18#117 [14:04] PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98 [14:28] Does someone have experience with network-manager / nmcli calls from a core18 base'd snap? I'm really lost as to what I might be doing wrong … https://forum.snapcraft.io/t/apparmor-denials-for-dbus-objectmanager-network-manager/9885 [14:37] sergiusens is there easy way to tell snapcraft which multipass instance to use for build? [14:37] Wimpress: I followed your instructions for the font with code-insiders on disco and it wasn't picked up [14:38] ondra: what do you mean? [14:39] sergiusens correct me if I'm wrong, but snapcraft will try to run clean build by creating new multipass instance? [14:39] sergiusens or is it more instance per-project? [14:39] sergiusens so is there option instead to tell it to use existing instance I already have? [14:40] ondra: it is, per project [14:40] sergiusens ah cool, and can I tell it to use specific one? [14:40] ondra: it is simple today, by name, "snapcraft-", but if you do manual things, it could get icky with some things done using cloud-init [14:41] sergiusens ah OK, so better to map dir and build inside instance directly [14:41] when we have support of some form of "project" from multipass, we will lock it down more [14:41] yes [14:41] sergiusens cool [15:08] kenvandine: cool, thanks a lot [15:08] leinardi: np [15:09] jdstrand: hi :) [15:18] PR snapd#6484 closed: debian: ensure leftover usr.lib.snapd.snap-confine is gone [15:24] mvo: did a first pass on the 1st Remodel PR [15:28] PR snapd#6486 opened: interfaces/hotplug: renamed RequestedSlotSpec to ProposedSlot, removed Specification [15:29] pedronis: thank you [15:30] mvo: what's the status of the discussion about where to do things in snapd vs snap-confine, in https://github.com/snapcore/snapd/pull/6418? [15:30] PR #6418: many: allow core as a fallback for core16 [15:31] pedronis: impas it seems, I would prefer snap-confine.c as we already to something similar there - unless I miss something? [15:31] mvo: do we know where in snapd would we do this? [15:31] pedronis: in cmd_run.go I think [15:31] or is that snap-exec or snap run? [15:31] pedronis: snap run [15:32] pedronis: I can explore this and push a passtebin with the required work [15:32] mvo: just remember my point, we don't want base: core16 not to pivot [15:32] it will hide bugs that will hunt us later [15:33] pedronis: aha, I see [15:33] so from that point view no base, base: core16 are not quite the seem [15:33] it feels right [15:33] but caveats [15:33] pedronis: yeah, if we do it in snap run this will be less clear [15:34] mvo: yes, we cannot turn base: core16 into no base [15:34] and be done [15:34] pedronis: right [15:48] PR snapd#6487 opened: interfaces: add new intel-management-interface interface [16:41]