=== JanC is now known as Guest50625 === JanC_ is now known as JanC [00:22] it looks like FreeCAD is opening a socket into /tmp/FreeCAD [00:22] and that when used through the launcher it god an ENOENT when trying to open it [00:22] which is an issue [01:53] vejmarie it is weird that /tmp/FeeCAD opening would block you. Can you run `snappy-debug`? (Install with `snap install snappy-debug`) [01:54] I will try [01:54] just re-assembling my snap currently (it is a big one about 300MB) [01:55] elopio sorry to bother, but that PR https://github.com/ubuntu-core/snapcraft/pull/518 could use some (update me clicking) ;-) [02:15] I also have an issue for an unknown reason my snap do not want to connect to :home [02:15] it does have the plug defined [02:15] and connect to unity7 [02:28] ok I found the solution for that [02:28] now, new issue. FreeCAD is storing parameters in ~/.FreeCAD [02:29] I am connected to ubuntu-core:home, but no ways to have free cad creating the directory into ~ [02:29] any ideas ? === chihchun_afk is now known as chihchun [07:16] o/ [07:53] ogra_: hey === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:23] Hello! Could someone point to me on why sandboxing applications inside snaps? Wouldn't linux group+read permissions be ideal for this? [10:25] * brunch875 returned from crashing IRC client [10:28] how would you do that ? one user/group per package ? [10:28] that's more or less what I have in mind [10:29] that would likely result in an unmanageable bit set of groups in the end [10:29] also what do you do with system services that need root access ? [10:30] (note that currently all snappy services run as root by default, the confinement happens on a way lower level) [10:30] (read: even root processes are restricted in what they can execute or what they can access) [10:31] using a groups based system would mean that you need to patch the software to actually operate under such a user and the like [10:32] That makes a lot of sense. Could this new permission system be used to replace the current user/group system? [10:33] well, you still want userss to run user specific stuff, to store user specific config etc [10:33] they are accompanying each other [10:34] it depends on the context ... on a headless IoT system that you manage via a web UI you can definitely get along without having a user [10:35] would it make sense to ship a text editor like vim as a snap package? [10:35] on a multi user desktop you definitely still want them (same on a server) [10:35] will apt get eventually deprecated? [10:36] kind of ... we dont have all interfaces in place yet (i.e. content sharing) ... so you would have to install the snap in --devmode [10:36] to have enough system access to read and write everywhere (which you want with en editor) [10:36] no [10:36] apt-get wont be deprecated [10:36] and the classic ubuntu wont go away [10:36] snappy is built from debs :) [10:37] what I meant by that is if new programs will be all preferred to use snappy [10:38] hey ogra_ do we have a new rpi image yet ? [10:38] thats really up to the maintainers ... canonical will definitely focus on snaps over other stuff when it comes to applications (i.e. you might be able to get the latest version of an app for your desktop installl rather via a snap than via a PPA) [10:39] daker, nope ... build one yourself is the suggestion ... as always :) [10:39] (within the next two-three weeks we should have something in alpha/betat status though) [10:39] -t [10:39] if i build one myself it will contain this fix bug 1577393 ? [10:39] bug 1577393 in linux-raspi2 (Ubuntu) "Linux-raspi2 is missing several driver modules when compared against generic" [Undecided,Fix released] https://launchpad.net/bugs/1577393 [10:41] daker, if you use the kernel snap from cdimage ... i'm not sure the change was uploaded to the store yet [10:41] ogra_: ok [11:50] Can I tell snapcraft to pull a specific branch from a github repo? [11:50] I have a build dep on a particular version of a library in git, master is too new [11:51] willcooke: source-tag or source-branch should do it [11:52] svij, ah ha! Perfect, thanks [12:03] had to use source-branch because I /think/ source-tag is actually trying to do source-branch [12:04] morphis: hey [12:04] morphis: was the i2c example I've sent of any use? [12:42] zyga: hey! [12:42] zyga: not yet, and it would be lpotter who will use it [12:44] zyga: you had time to look into the modem-manager interface already? [12:44] morning [12:45] sergiusens: morning! [12:47] kyrofa are you around? === mterry_ is now known as mterry [12:47] sergiusens, I am, I'll get that branch fixed up [12:48] morphis: no, I promise to do it today [12:48] kyrofa oh, right :-P [12:48] zyga: sounds good! [12:48] morphis: if I slack please ping me because I just forgot that m-m needed revieweing [12:48] abeato: ^^ [12:48] ok [12:48] zyga: it has some interesting things in it we need to cover [12:48] ack [12:49] sergiusens, haha, I thought that was what you were going to ask, no? :P [12:49] zyga: btw. how far is the auto-connect-from-gadget-snap story? [12:49] kyrofa btw, this landed https://github.com/ubuntu-core/snapcraft/pull/523 but now that I see, I think I only had verbal consent from elopio so I would like for you tot ake a look [12:49] morphis: not touched, nobody is exploring that [12:49] zyga: meant to be done for RTM? [12:49] zyga, that would be interesting for the nm-mm connection [12:49] ev: hi! there are a number of ev-gadget snaps in the store. do you need any approved? [12:50] abeato: yes, but for all other plug/slot connection we have to establish for our snaps too [12:50] sergiusens, will do, after standup here in a few minutes [12:50] abeato: yes, and many other cases [12:50] ineed [12:50] indeed [12:50] jdstrand: you can reject all. It's causing an oops when I try to delete them [12:50] abeato: can you please draft a message to snapcraft@ and we can take it from there [12:50] ev: ack, thanks :) [12:51] jdstrand: hey! [12:51] zyga, sure, I'll do [12:52] zyga: hi! [12:53] niemeyer4: what's your opinion on if the 'home' interface should be auto-approved in the store? [12:59] jamiebennett, niemeyer4: hi! mvo uploaded an os snap with the name 'base'. should it be approved or rejected? (not sure where we stand on the naming of things-- I thought I read 'base' was rejected [13:00] jdstrand, throw it away [13:00] jdstrand, we'll do a proper "core" snap on monday [13:00] ack, thanks! [13:01] jamiebennett, niemeyer4: nm re os snap [13:02] :) [13:11] what's the process for snaps that set interfaces like 'system-reserve'? the CRT error in the store is: "reserved cap 'system-observe' for vetted applications only security-snap-v2_app_plug_safe (vtop, system-observe)" [13:11] s/reserve/observe [13:11] in https://myapps.developer.ubuntu.com/dev/click-apps/5100/rev/1/ [13:15] abeato: btw. the second part "due to apparmor denials when trying to register for [13:15] tracking DBus name for partner before connection is established" can't we do that better in network-manager and use a dbus name watch? [13:15] morphis, that is what fails [13:15] trying to register for the wathc [13:15] oh really? [13:16] yep [13:16] apparmor denial? [13:16] yep [13:16] beowulf: can you elaborate on "what's the process for"? [13:17] beowulf: you mean the review process? [13:17] beowulf: or something else? [13:17] jdstrand: so it's just the normal review process? [13:17] abeato: we should extend the permanent slot then for the network-manager interface to allow that [13:18] as network-manager should be allowed to listen for modem-manager even without the plug being connected [13:18] jdstrand: https://developer.ubuntu.com/en/snappy/guides/interfaces/ made me think it might be more involved [13:18] sure, that can be done [13:18] abeato: can you add that to your m-m interface PR? [13:18] beowulf: it's the normal review process. it will be flagged for manual review atm, but then a reviewer will look at it [13:19] this stuff is still being worked through though with store changes and assertions changes coming [13:19] morphis, better in another PR [13:19] and trying to understand how autoconnect and manual connect fit into store auto-approvals [13:20] abeato: then lets push another one on top [13:21] jdstrand: right ... i was wondering if ideally in the store UI that should be less of "there was a problem!" and more "package is fine, we just need to be sure about X" ... "manual review state" is treated like a failure, which it isn't really? [13:21] morphis: oh, if you are pushing another nm change... I started looking at the ConnectedSlot changes for it to bring it in line with what we were doing with location service [13:22] jdstrand: we need to add a bit to allow dbus name watches to allow interconnections between n-m and modem-manager [13:22] beowulf: it is a failure in auto-approval. I think we need to understand where we are going before we change the ui though [13:22] jdstrand: absolutely, just thinking out loud [13:24] morphis: I wonder if you would want to take: https://github.com/jdstrand/snapd/tree/nm-fixes (totally untested) as part of that work? [13:24] well, it is 'run-tests' tested [13:25] morphis: if not, I can keep plugging away at it. at some point I would need one of you to run it through your test plan though (unless you have a test plan I step through that you can point me at) [13:25] jdstrand: sounds good, abeato can you include those changes? [13:26] ok, cool [13:28] morphis, will do later [13:31] kyrofa one more https://github.com/ubuntu-core/snapcraft/pull/524 [13:31] hi all, what's the best way to specify an icon in a .desktop file to make sure it will find the proper image in the app's install directory [13:31] abeato: thanks [13:31] mhall119, I remember zyga talking about that... I don't remember where though (maybe a blog post) so he'll probably be able to help [13:34] mhall119 something like this https://github.com/sergiusens/vscode/tree/release/1.0.0/setup/gui [13:42] thanks sergiusens [13:43] jdstrand: Heya [13:43] jdstrand: So, home interface.. [13:43] jdstrand: Tricky one [13:44] jdstrand: I don't think we should stop auto-connecting it until we have a better experience for connecting it in the first place [13:44] jdstrand: But that's an initial gut feeling.. we can explore options [13:57] niemeyer: I agree with that. I wonder about auto-approving in the store then. there is some overlap with manual reviews and auto-connecting, but it isn't at all clear to me. I know things will get clearer with the assertions work, but perhaps 'home' should be autoapproved but manually connected, but say network-manager is both manual approve and manual connected. it's a little weird atm with the transition [13:58] davidcalle: thanks for the whitepaper updates. does the process we came up with work for you? [13:59] jdstrand: yes, works for me :) [13:59] great [13:59] seems lightweight and flexible :) [14:01] jdstrand: indeed, I'm running an importer that does 90% of the work, the I diff the text with what's published and apply (quicker than publishing the new import and doing the remaining 10%) [14:01] nice :) [14:01] jdstrand: Not clear to me.. what are we looking for? [14:02] jdstrand: snaps need to be useful in the first place, otherwise there's no point in even doing the work [14:05] niemeyer: I think maybe if we/I knew where we were going with the future assertions and UI work, it might be clearer. for example, we know that snaps providing a slot will need an assertion saying it is ok [14:05] (aiui) [14:05] and if we know that the ui requires users to make an active decision to connect, then things like system-observe can be approved [14:06] I'd hate for people to copy/paste code though (install my snap, run this snap connect command and everything is great!) [14:06] I'm not sure what we want either [14:07] I can say that gut feeling is some things seem to need manual store approval, but some things don't [14:07] jdstrand: For specific interfaces.. both slots and plugs will need a declaration [14:07] but I'd like it to be less about our guts and more about defining why things are the way they are [14:08] jdstrand: Right, exactly [14:08] and it can be case by case, but I'd like to know the criteria for deciding :) [14:09] jdstrand: One criteria is that it must be useful.. [14:09] like, nm slot needs a lot of privilege (manual approve?), nm plug gives a lot of priv (manual approve??), system-observe gives some priv but manual connect (auto-approve?) [14:10] fgimenez: I forgot we now have a meeting on fridays too. I'm sorry. [14:10] niemeyer: can you expand on that? must be useful seems like a criteria for implementing the interface at all [14:10] jdstrand: Yes, the idea that manual connect == auto approve seems good [14:11] niemeyer: yes, I've been leaning towards manual connect == autoapprove as the baseline, then perhaps with exceptions as we see fit? [14:12] 'as we see fit' is obviously still a gut thing atm, but at least manual-connect == auto-approve as a default stance is helpful [14:13] niemeyer: I don't want to try to solve this all today-- just trying to keep the conversation going [14:14] jdstrand: Yeah, the decision making in those cases requires some deep thinking.. let's see.. [14:14] niemeyer: how about this: home and *-observe are all manual connect, so we auto-approve [14:14] niemeyer: then we punt on nm, *-control, etc for now and leave them as manual connect and manual approve while we continue to think about it? [14:15] niemeyer: I think that will help real folks. I see system-observe and log-observe along with home periodically [14:25] elopio, np, we'll be repeating it during next week [14:37] where do I report bugs about https://github.com/ubuntu-core/snapcraft/blob/master/docs/your-first-snap.md ? [14:38] that has an example with an icon key [14:38] which is deprecated [15:04] sergiusens, now that mark wants the snapcraft-examples thing to be different, I think I'll leave that branch for didrocks. Sound okay? [15:04] jdstrand, hey, is there any easy way to make strace work in a snap without devmode? I tried to enable ptrace in the profile but get [15:04] some permission denied error still [15:07] fgimenez: I made some comments on the check branch. I'm again pushing for fixing them after we can free a reporter interface. [15:07] we can discuss it in the meeting. [15:08] seb128: depends on what you define as easy. you can modify /var/lib/snapd/apparmor/profiles/snap.your.app to have 'ptrace,' then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.you.app'. then add 'ptrace' to /var/lib/snapd/seccomp/profiles/snap.your.app [15:09] seb128: note, you need the comma in the apparmor rule, you don't in the seccomp [15:09] elopio, ok, sounds good [15:20] ok, I made another progress [15:20] so it looks like that snappy do not authorized listen and bind [15:21] syscall [15:21] is there any specific reason for that ? [15:21] FreeCAD is using sockets [15:21] if I had the sys call into /var/lib/snapd/seccomp/profiles/snap.freecad.FreeCAD [15:21] I can go further [15:22] I now have GL crash (but this is probably because I am missing some libraries into the snap and test system) [15:28] shrug [15:28] error: cannot remove "gnome-calculator": snap "gnome-calculator" has changes in progress [15:28] the squash unmount failed due to process still actives [15:28] which I killed now [15:28] restarting snapd didn't fix it [15:28] how do I get out of there? [15:31] seb128: I use https://github.com/zyga/devtools/blob/master/reset-state [15:31] It's a radical option, though [15:32] that's still needed? [15:32] I did that in Prague but I hoped snapd was more solid nowadays :-/ [15:32] davidcalle, thanks [15:33] seb128, i think it is fixed already, just not landed via SRU [15:33] k [15:33] * seb128 wipes snap away [15:34] seb128, bug 1583085 [15:34] bug 1583085 in snapd (Ubuntu) "[SRU] New stable micro release" [Undecided,New] https://launchpad.net/bugs/1583085 [15:34] i think 2.0.5 has the related fix [15:35] I've 2.0.3 [15:35] needs to upgrade [15:35] I installed snapcraft from proposed but not snapd it seems [15:36] back to my canonical-tech message, need an easier way to get those updates that to cherry pick from proposed ;-) [15:38] jdstrand, thanks for the help, fcitx works with "#include " added the apparmor profile, I updated the im bug with details [15:42] seb128: interesting. I don't have abstractions/fcitx... I'll need to look into this. thanks so much! [15:43] jdstrand, yw! [15:44] jdstrand, it's part of fcitx-data [15:45] jdstrand, btw robert_ancell might need your input on a similar issue on https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1581187 [15:45] Launchpad bug 1581187 in lightdm (Ubuntu) "AppArmor parser error for /etc/apparmor.d/lightdm-guest-session in /etc/apparmor.d/lightdm-guest-session at line 14: Could not open 'abstractions/fcitx'" [Undecided,New] [15:45] seb128: yes, I thought of that bug when you mentioned that abstraction [15:45] lightdm included the abstraction but it might not be installed [15:46] I need to see what it going on [15:46] we maybe need to move the abstraction to a package which is always installed if includes can't be optional [15:48] seb128: includes can't be optional. another option is to have lightdm depends on the package that is providing the abstraction. let me look into it before I make a recommendation [15:49] well, they can be options if you #include a directory and drop files into the directory. that isn't the case here [15:49] optional* [15:57] kyrofa not super hard to change though ;-) But I know where this is headed ;-) [15:58] sergiusens, hahaha [15:59] seb128 2.0.3 was the one that supposedly fixed that problem you see [15:59] seb128 2.0.3 was the one that supposedly fixed that problem you see [15:59] sergiusens, needs to be fixed harder then [16:00] ouch [16:00] vejmarie for bind you need the network-bind interface [16:00] * ogra_ is sure seb128 is just holding it wrong [16:00] lol === chihchun is now known as chihchun_afk [16:08] @sergiusens: Thanks a lot ! I am new to the tool and didn't figure out all the interfaces ;) [16:08] vejmarie: No such command! === chihchun_afk is now known as chihchun [17:01] how can I re-do the staged packages in a part without re-compiling the source in that part? [17:04] * mhall119 thinks he figured it out [17:06] mhall119 in the same part? not likely supportable as a stage-package has the potential to change the build result [17:06] oh? I thought only build-packages would affect the build result [17:10] mhall119, no, stage packages can also be used for the build [17:10] mhall119, they're pulled down and unpacked as part of the pull step [17:10] mhall119, in fact, the python plugins use stage packages IN the pull step [17:16] ok: I still have some issues with the software raster dry driver [17:16] I have this libGL error: unable to load driver: swrast_dri.so [17:16] my snap is connected to OpenGL (not yet x11, and unity7) [17:16] and GTk do not find modules which are into the snap either like overlay-controller [17:22] vejmarie I'll have to address you to zyga for that [17:22] kyrofa is 525 good to go? [17:22] sergiusens: no problem, is he on the channel ? [17:22] vejmarie yeah [17:28] ok, I did connect free cad to x11 [17:28] no changes [17:28] libGL can't find swrast_dri [17:28] and Gtk complains about modules [17:29] any ideas welcome ! This is the last issues I have and then after FreeCAD will be fully snapped (except the build of the app which is performed though a single script, as it is coming with the whole dependencies) [17:29] sergiusens, yessir [17:30] zyga: r u there ? [17:30] vejmarie: yes [17:30] vejmarie: what's up? [17:31] I have some issue to snap freecad [17:31] I am mostly done but this piece of code is huge [17:31] and requires access to some dry drivers for 3D rendering like swrast_dri.so [17:31] I put them into my snap [17:31] and run on ubuntu [17:32] I setup the various interfaces to x11 OpenGL and unity7 [17:32] but still no way to load properly the driver through libGL [17:33] same thing for some VTK module like overlay-scrollbar [17:33] vejmarie: I have no idea how to help you right now, I'd need to jump into that snap and figure out how the stack looks like, I only planned to do that after some infrastructure code is done (bind mounts and environment via interfaces) [17:33] vejmarie: then the goal will be to *remove* all wrapper-ser variables [17:34] vejmarie: but now I cannot do much, I can only help to guide you and I'll gladly take patches that don't depend on those two features [17:35] zyga: ok I will continue to digg and keep you posted. Hopefully I will find from where the issue come === chihchun is now known as chihchun_afk [17:48] niemeyer: just commented back on the udev rules in gadget/kernel snap thing [17:49] niemeyer: that is a very critical thing and we simply can't rely on releasing a new snapd version for each new supported device [17:49] niemeyer: though we could abstract the rule generation with a specific interface [17:50] which then just makes things quite more complex [17:50] jdstrand: ^^ [17:50] zyga: ^^ [17:51] morphis: If it was "simply can't" we probably wouldn't be talking about it :) [17:51] morphis: At the very least it's not simple, and perhaps not even can't :) [17:51] I don't have context [17:51] morphis: We won't allow security overruling like that.. [17:52] jdstrand: This is about kernel/gadget snaps shipping arbitrary security snippets [17:52] jdstrand: udev rules for modem detection to be concrete [17:52] niemeyer: the thing is that we can't even expose certain vendor IDs until a device is published [17:53] so we basically sit on a factory image with a customized snapd as we can't release the used IDs in the public interface definition [17:53] ok. I'm a bit out of date possibly, but I thought that is one of the reasons why the gadget snaps exists-- to create devices that snapd can reliably consume? [17:53] jdstrand: yes [17:53] that was my understanding too [17:54] morphis: Well, hmm [17:54] but I don't think any of that is designed. perhaps I'm wrong. I think zyga had some ideas [17:54] so [17:54] just otoh [17:54] the gadget snap doesn't have to ship udev rules [17:54] jdstrand: actually that is something really important if we're talking about what we need pretty soon in snapd for customer devices [17:55] it could ship yaml that tells how to match [17:55] we were thinking about an slot that the gadget could have, that would be plugged to various special snaps (like n-m) that would grant permissions to the plug side and the permissions were encoded in the slot side [17:55] morphis: The udev rules are not much of a concern, actually [17:55] jdstrand, niemeyer: basically that is what I got from zyga that we would put the udev rules into the gadget or kernel snap [17:55] then snapd takes that and creates udev tags or something that can be used for hw mapping [17:55] morphis: Because simply detecting won't give implicit access [17:55] morphis: What happens next after detection for this particular case? [17:56] niemeyer: you mean what ModemManager does with detected devices? [17:57] * jdstrand notes I think we are talking about two different things-- reliably detecting and then connecting what was detected [17:57] guys, can we maybe do a meeting about this next week to solve this? [17:57] yes [17:57] morphis: Sounds good [17:57] maybe the best thing [17:57] wfm [17:57] morphis: It'll probably be a very short one [17:58] morphis: I think we're all pretty much in agreement [17:58] niemeyer: possible, lets see [17:58] morphis: I jumped the gun with my comment, misunderstanding what you were actually asking for [17:58] we just need to get to a common understand and what the way forward is to get this implemented [17:58] morphis: Sorry about that [17:58] niemeyer: np [17:58] niemeyer: lets move this discussion to the meeting [17:58] +1 [17:59] we can explain what ModemManager does and you apply to that what snapd should do with that [17:59] then we will come out with something [17:59] * jdstrand notes he is off Monday (US holiday) [18:00] jdstrand: ah, forgot that [18:01] jdstrand: moved it to tuesday then [18:02] thanks [18:11] jdstrand: https://github.com/ubuntu-core/snap-confine/pull/7 reviewed [18:11] :D [18:23] I'm trying to build a snap from a git repo. When it downloads from git the thing I want to build is in a subdir. [18:23] Specifically... [18:24] I'm trying to build Mythtv [18:25] if you clone the git repo, then the main bulk of the app lives in a subdir "mythtv" which has the configure file in it [18:25] so when I run snapcraft on it it can't find configure in builddir and so it tries to run autoreconf -i [18:26] the configure file does exist, just in builddir/mythtv/ [18:26] can I tell snapcraft to look in that dir instead of "build"? [18:26] *root of build [18:30] hmm [18:30] stuff works :") [18:34] willcooke: I think you either need to make your own plugin, or put a dir in your root and in another section with source: yourdir\nplugin: make and make the Makefile boot up your own configure, etc. [18:35] willcooke: your plugin will just extend the normal autoconf. [18:35] cool, I'll try a new plugin, thanks qengho [18:38] ok, some progress on my side, if I run as root the snap bin command no libGL issue. If I run as a standard user, I got error loading the GL driver [18:40] vejmarie: oh man the driver stuff is going to be ugly. I encountered that recently. [18:43] how did you fix it ? [18:43] it is really really strange [18:43] as root [18:43] ls -lt /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so [18:43] -rw-r--r-- 8 root root 9734592 Apr 14 19:08 /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so [18:43] as user [18:43] ls -lt /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so [18:43] ls: cannot access '/usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so': No such file or directory [18:44] vejmarie: what stage-packages do you have? At least [ libgl1-mesa-glx, libgl1-mesa-dri ] ? [18:44] wrong copy you have to remove the tls [18:45] yep [18:56] this issue is really really strange to me [18:56] qengho, it only bleedin' worked! [18:57] :D [18:57] willcooke, there's a `source-subdir` param you can use [18:58] kyrofa, ah, that sounds exactly what I needed - does that work for autotools too? [18:58] willcooke, indeed-- any plugin that supports the `source*` keywords [18:58] I'll give that a go, thanks [18:58] willcooke, you can learn more about those keywords with `snapcraft help sources` [19:01] kyrofa, that was exactly what I needed, thanks¬ [19:01] ! [19:01] willcooke, any time! Sorry for the delay :) [19:02] kyrofa, ain't no thing. I copied the autotools plugin and added another option, which then did: [19:02] if self.options.build_subdir is not None: [19:02] self.builddir = os.path.join(self.builddir, self.options.build_subdir) [19:02] which I expect is pretty much the same as source-subdir [19:03] so I can drop that now [19:03] Pretty close, yeah [19:03] it does mean I don't get to make a PR against snapcraft though [19:03] :) [19:03] better luck next time I guess [19:13] willcooke you can still get around to the gnome builder one ;-) [19:13] sergiusens, desrt is working on that one [19:53] hi, is there an example of a snap with fontconfig as a dependency, or handles fontconfig configs? [19:55] beowulf: https://bugs.launchpad.net/snapcraft/+bug/1576303 [19:55] Launchpad bug 1576303 in snapcraft (Ubuntu) "Needs fontconfig integration" [Undecided,Confirmed] [19:55] qengho: aha! thanks [19:55] Ain't no thang. [22:11] Have any of you encountered "python2" plugin complaints that .pth files are not supported, stemming (I think) from the part install dir not being the stage dir (which is in PYTHONPATH)? === vejmarie_ is now known as vejmarie