[01:24] Updated my plugs [01:24] https://forum.snapcraft.io/t/please-allow-use-of-personal-files-for-gitl-was-classic-confinement-for-gitl/9420/30 [02:29] Is there a reason snapcraft seems to pass "-prefix=" with the autotools plugin? [02:29] it seems to hork up a lot of builds [02:29] unless /usr is specified [02:36] I'm trying to add a scriptlet to symlink a library in my snap, but it doesn't seem to be doing anything. That is, I don't see any trace of it in the build log on snapcraft: https://github.com/libretro/retroarch-snap/blob/master/snapcraft.yaml#L20 [02:36] can anyone tell me if I formatted that properly in the yaml? [04:16] sorry, i am not quite there yet, havent done scripts [05:35] morning === mwhudson_ is now known as mwhudson === harrisj_ is now known as harrisj [06:35] duh, clearlinux is weird, it says it supports cloud-init, but makes no use of it when i attach a disk with vfat labeled ucidata [06:35] turns out they have their own implementation https://github.com/clearlinux/micro-config-drive/ that takes config-2 openstack style disks only :/ === pstolowski|afk is now known as pstolowski [07:06] morning [07:11] pstolowski: hey [07:14] Good morning [07:16] zyga: hey hey [07:30] mborzecki: can you re-review https://github.com/snapcore/snapd/pull/7026 [07:30] mborzecki: I have some more patches but per agreement with jdstrand those will go to another PR [07:30] mborzecki: those add a few more unit tests and allow the memory buffer to be capped [07:30] mborzecki: with those test coverage for the new code is 100% [07:31] zyga: ok, looking [07:32] thanks! [07:32] pstolowski: how are you? :) [07:32] weekend coming up, weather is slightly saner (at least in poland, here's it is going to be much hotter) [07:33] zyga: hey! i'm good, and weather is sane, yes [07:44] today is going to be blazing hot, cannot wait till 10:00 when the library opens [08:16] hi, to confirm, the "refresh" hook is called both on first install and every time a snap is updated right? [08:17] * zyga breakfast [08:17] pstolowski: ^ [08:21] ackk: no. there is no "refresh" hook, there are "pre-refresh" and "post-refresh" hooks, they are only run if snap is already installed and is refreshed, not on initial install. see https://docs.snapcraft.io/supported-snap-hooks [08:22] pstolowski, ah, thanks [08:36] pstolowski, shouldn't post-refresh run when you first install the snap? [08:39] ah, it doesn't seem so :/ [08:39] ackk: no, it runs after refresh, which is not the initial install [08:39] ackk: the idea with pre- and post- is to allow snap to do something with "old" snap resources before switching to new snap, and then afterwards in the new snap [08:39] This hook is executed for the newly installed snap, [08:40] pstolowski, so doc is wrong I think ^ [08:40] ackk: are you sure you didn't have old revision around? i checked the code before actually looking up the doc [08:40] pstolowski, if I do have an old revision, it is run [08:40] ackk: are you trying or installing? [08:41] there's a bug with snap try in this case [08:41] pstolowski, I'm saying what I see matches what you said (only run on refresh, not on new install), but the doc says otherwise [08:41] zyga, try [08:41] in try case it's broken because it's all one virtual revision [08:41] ah, snap try [08:41] zyga, so, if I want a script to be run on new install and on subsequent refresh, I can use install + post-refresh right? and symlink one to the other [08:42] ackk: or configure [08:42] zyga, yeah that's what i have at the moment but I wanted to move away from that as it might break things if you run snap set [08:42] ok [08:42] also, it would run more times that it needs [08:42] zyga, is symlinking allowed? [08:43] I suspect so but I don't believe we test for it [08:44] I'll try [08:44] zyga: thanks for pointing out 'snap try', i wouldn't realize this could be a factor [08:45] pstolowski: we should warn if refresh hooks are present in snap try [08:45] it probably would be easy now [08:45] indeed [08:46] zyga, you mean post-refresh is broken if you use snap try? [08:46] why is it one virtual revision? if you upgrade via snap try you get x2,x3... [08:50] ackk: if you snap try snapd will think that you already have the hook [08:50] ackk: because it's one actual directory it is always looking at [08:50] ackk: I suggest that you snap pack and actually install to test this code [08:50] snap try cannot be used for that reliably [08:51] zyga, ok, thanks [08:51] zyga, I'm mostly using snap try because the squashfuse bug makes it really slow to use maas in a snap [08:52] bug? [08:52] you can compress with gz [08:52] it uses 100% cpu [08:52] it will be fast [08:52] it's not a bug, it's just expensive compression :) [08:52] zyga, uhm, squashfuse constantly using 100%cpu sounds like a bug [08:52] ah [08:52] sorry, I misread [08:52] squashfuse [08:52] it's not a bug, squashfuse is just really this slow [08:52] zyga, https://bugs.launchpad.net/snapd/+bug/1817276 [08:53] lots of overhead for access [08:53] zyga, it only happens inside containers [08:53] zyga, it makes it moslty unusable [08:53] because we only use squashfuse inside containers [08:53] fuse is just slwo [08:53] *slow [08:54] we'd need a new kernel implementation that is not fuse to be any faster [08:54] perhaps something could be improved in the current one but in general fuse is just really slow [09:09] good morning and greetings from The Sprint [09:10] hey Chipaca [09:11] zyga: what's the status of #6891? [09:11] pstolowski: 'sup :-) [09:11] Chipaca: how is the sprint? [09:11] Chipaca: hey, looking [09:11] pstolowski: I'm exhausted and I've only been here 24 hours [09:12] pstolowski: how mvo, pedronis and niemeyer cope with it I don't know [09:12] Chipaca: the status is that there's one undesired consequence of the fix that is present on core16 only, it needs to be debugged but debugging is painful (slow) because of core nature [09:12] Chipaca: I will task switch to it as soon as https://github.com/snapcore/snapd/pull/7026 is merged [09:13] Chipaca: the error is that on core16, the new test measures duplicated /snap/name/revision entries [09:13] probably a consequence of something else propagating [09:13] but I don't understand it yet [09:13] Chipaca: how is the sprint so far? [09:19] zyga, fwiw it seems a bit weird that snapd only prints "Running hook if present" only when the hook actually exists. I mean why the "if present"? [09:20] zyga, FTR symlinking doesn't work :( [09:20] ackk: bug, it used to always do that [09:20] pstolowski: ^ [09:20] the message is out of date [09:21] right, we now optimize hooks out, message needs updating [09:25] ah actually my symlink test wasn't accurate, need to test again [09:33] oh actually it seems symlinks get converted, nice === ricab is now known as ricab|bbl [10:02] * ackk stares at squashfuse running at 100% since 5m [10:12] zyga, mborzecki, either of you feel like taking a look at os-release for clearlinux? wrt https://forum.snapcraft.io/t/snapd-on-clearlinux/12048?u=chipaca [10:14] Chipaca: tried booting clear linux image in the morning, was a funny experience [10:14] mborzecki: glad you're having fun [10:14] :-þ [10:15] mborzecki: anything and everything clearlinux, I blame xnox for it [10:15] hm maybe i should at least paste os-release in that topic [10:15] mborzecki: zyga has a zoo [10:16] mborzecki: https://github.com/zyga/os-release-zoo [10:16] zyga: archived? :-( [10:18] Chipaca: I have a clearlinux VM [10:18] Chipaca: tried building snapd there [10:19] Chipaca: moved to gitlab.com/zygoon/os-release-zoo [10:19] since I was curious of how the grass looks like there [10:19] it looks clear, duh [10:19] and ? [10:19] was it greener ? [10:22] ogra: it was very fast indeed [10:22] I was surprised to see a brand new package manager [10:22] not related to anything else [10:22] and a matching package format aswell [11:28] Can I get some love here: https://forum.snapcraft.io/t/please-allow-use-of-personal-files-for-gitl-was-classic-confinement-for-gitl/9420/32?u=wieczorek1990 [11:40] zyga: i love your zoo [11:40] xnox: pleasure, contributions welcome [11:40] I should be more active about adding stuff I have access to there [11:53] ppisati, where did System.map-*, abi-* and config-* go ? [11:53] wget -O- -q http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-4.4.0-154-generic_4.4.0-154.181_armhf.deb | dpkg -c - | grep boot [11:53] drwxr-xr-x root/root 0 2019-06-25 11:19 ./boot/ [11:53] -rw------- root/root 7310208 2019-06-25 11:19 ./boot/vmlinuz-4.4.0-154-generic [11:53] seems they are not in the deb anymore [11:54] ogra: :O [11:57] ogra: check the linux-modules-* package [11:58] ah, there are config-* and System.map-* .... but abi-* is still missing ... did we drop that ? [12:02] mborzecki: could you have another look at https://github.com/snapcore/snapd/pull/7026 please === ricab|bbl is now known as ricab [12:10] mborzecki: if you are interested, on top I have one patch https://github.com/zyga/snapd/commit/eacf3860affb61f2ad6f8cd40bf5e6e56bb7bf91 that I decided to postpone until after this lands [12:11] * cachio afk [12:12] zyga: nice, though jdstrand was ok with getline() :) [12:12] yeah but then I played and fed /dev/empty into it [12:12] this used all ram [12:12] so ... [12:12] here it is :) [12:12] I'll propose it as soon as this lands [12:12] haha [12:12] also need to propose a patch to get easy way to run lcov [12:13] but first, small break [12:13] then back to https://github.com/snapcore/snapd/pull/6891 [12:18] zyga: oh, looks like glib is using lcov too [12:20] zyga: i'd check of clang/llvm has something [12:24] honestly anything that works is ok [12:28] zyga: hahha, given that it's C land, you can put the bar too high :) [12:33] so dropping snap.ReadGadgetInfo() saves ~20k on snap binary, worth it? [12:39] mborzecki: yeah === ricab_ is now known as ricab [13:02] trying to join... [13:15] zyga (cc mborzecki): wow, you added a lot of code to get rid of the variable list. I feel bad cause of all the code you wrote, but jeez, why can't we just do a simple loop and search like I originally suggested? [13:16] I mean, this is setuid code, parsing teensy files that we control [13:16] * setuid looks around [13:17] lets regulate the input and be very strict (skipping if malformed/whatever) and keep the code simple without state [13:18] mborzecki: am I wrong in my assessment? [13:18] jdstrand: yeah but also made it much simpler (O(N) instead of O(N*N)) and much more testable [13:19] jdstrand: this will also allow me to replace the os-release parser with the same tested code [13:19] jdstrand: more is not necessarily worse (especially that the public code surface is smaller and even easier to use) [13:19] zyga: I think you mean s/simpler/faster/ [13:19] no, it is simpler to reason IMO [13:19] the logic in each function is more straightforward than before [13:20] I'm trying to reason about it while reviewing it and found that not to be the case [13:20] where it was all in one more complex function [13:20] the private function does a pass over the file [13:20] the public function calls the private function with a helper callback that extracts the single key we are looking for [13:20] everything else is tests [13:21] jdstrand: the structs avoid very long argument lists [13:21] I understand the one loop pass. I know why you are doing it. I'm saying it feels like a lot more than is required to extract a key/value pair from a file [13:22] zyga: I am not saying I don't understand the code. I am saying it seems like more than is needed. I'd like mborzecki's input as well [13:23] what key/value pair from what file? [13:23] ack, though I'd rather not rewrite it again :) [13:23] :) [13:23] Chipaca: key=value from a file we write [13:24] Chipaca: but also keeping it open to drop the custom code for /etc/os-release parser and use this one instead [13:24] zyga: I know, which is why I said I feel bad... [13:24] Chipaca: https://github.com/snapcore/snapd/pull/7026 [13:25] jdstrand: can you clarify if you feel bad because of how the code looks like or because of the initial suggestion, sorry I didn't get that [13:25] jdstrand: agree that it's bit more more than needed, but afaiu the idea is to reuse this elsewhere [13:25] oh in C [13:25] Chipaca: bleh C :/ [13:26] zyga: I feel bad for you writing a lot of code that I really want to NAK. I'm trying to figure out if I am beign reasonable [13:26] and in part of a 800-line PR [13:26] ack, I see [13:26] that touches 23 files in 34 commits [13:26] Chipaca: most of that is noise, the main part is just tests and a single .c file [13:26] * Chipaca steps slowly away from that [13:26] Chipaca: I can move 90% of the files changed to another PR that can land without any impact [13:27] jdstrand: on top of that I also wrote a patch to use fixed size buffer [13:27] jdstrand: but I didn't include it in this PR as we discussed [13:27] zyga: again, I didn't care about fgets vs getline. I was just adding to the sidebar commentary [13:28] ack [13:28] * jdstrand takes a deep breath and tries to reread this in different orders to somehow rationalize is is worth it [13:29] jdstrand: please make a decision, I will close and re-do this if necessary [13:29] uhh... of course? [13:30] though, if I'm being honest, if I do decide to let it through, I'm going to ask for Michael or Samuele to ack the added complexity [13:32] zyga: I'd say that anything that touched C should be very far away from anything that is noise [13:32] Chipaca: read the PR [13:32] zyga: I'm feeling particularly ornery today though [13:32] Chipaca: it's not noise per se, just trivial required changes to complete the feature [13:33] Chipaca: it's noise for the point of view of the discussion [13:33] *from [13:33] removal of .info files [13:33] spread test + data files [13:34] zyga: I've got a bug on a connected content interface [13:34] * jdstrand notes he is only talking about sc_infofile_get_key() [13:35] and down [13:35] zyga: Hello btw :) [13:35] niemeyer: hey! [13:35] niemeyer: can you tell me more please [13:35] zyga: I've been speaking to people all week live here and suddenly I forgot you were not one of those :p [13:35] jdstrand: wondering, as a middle ground, we could live without scanner state & callback thing, plus enforce =\n format, but keep the error codes, then https://github.com/snapcore/snapd/pull/7026/files#diff-5dd49f9aa50cb48081dd1039d91e4e9aR243 becomes where value is extracted, wdyt? [13:35] I hope it's one of the known ones, but we'll see [13:35] zyga: The scenario is quite specific, so might be related [13:35] zyga: I had a local snap unsigned that I developed myself [13:36] niemeyer: there's a fix that is close to landing that happened to resolve a number of bugs at once [13:36] zyga: And then I refreshed into a proper snap from the store [13:36] * zyga listens [13:36] zyga: Which had a new connection that did not exist in my local snap [13:36] zyga: The connection was established (and is), but the actual content doesn't show up in the content directory [13:37] niemeyer: ok, some questions: is this snap using the desktop interfaces by any chance? [13:37] zyga: This is the gnome platform interface [13:37] zyga: http://paste.ubuntu.com/p/qDX9jnn9qr/ [13:37] niemeyer: if you nsenter -m/run/snapd/ns/$SNAP_NAME.mnt - do you see the directory you were expecting? [13:38] mborzecki: I liked how the tests read (ie, the error codes) and found that a nice improvement. it is when I started looking at all the structs, caller_state, function pointers, etc that I was like "this is going to take me all day to prove to myself that it is bulletproof) [13:38] s/)/" [13:39] jdstrand: I'm happy you like the error handling, I think it is a good pattern to follow, even if the outcome is die() simply because of how testable that mode is, and that error forwarding also calls die if nobody is to pick up the error on the caller side. [13:39] zyga: Where do I run thta? [13:39] mborzecki: not that it would take all day, but having that feeling isn't great when you are looking at setuid file parsing [13:39] niemeyer: open a terminal, sudo nsenter -m/run/snapd/ns/foo.mnt # replace foo with the name of the snap [13:39] niemeyer: normally on your host [13:39] zyga: No [13:39] zyga: It's empty [13:40] niemeyer: ok, can you look at /run/snapd/ns/snap.$SNAP_NAME.fstab and see if we claim we made the connection there? [13:40] niemeyer: (do you see the mount point represented in that file) [13:40] zyga: Wait, but something doesn't add up [13:40] oh? [13:40] zyga: I may be running the command incorrectly [13:40] niemeyer: nsenter drops you into a shell inside the namespace [13:40] zyga: I don't have permission to run nsenter as a user on that ns [13:41] niemeyer: you have to sudo nsenter from the host [13:41] zyga: and runnign as root doesn't make sense [13:41] zyga: Doesn't that mean I'd get into a different namespace than my user would see normally? [13:41] niemeyer: it's just a debug tool, it is okay to run it as root [13:41] niemeyer: yes, but that's what I'm trying to debug at this moment [13:41] niemeyer: I strongly believe you are seeing a bug that is fixed by https://github.com/snapcore/snapd/pull/6891 [13:42] zyga: Sure, but root never run the snap command [13:42] niemeyer: sure but this is not the snap command, we are inspecting intermediate state [13:42] mborzecki: I'm also worried about future maintenance [13:42] niemeyer: if you see the mount point and stuff connected properly in this mount namespace this is the same bug [13:42] niemeyer: that is all I'm trying to establish now [13:42] mborzecki: I would be ok with a middle ground. do you think I am being unreasonable? [13:43] mborzecki: (in my gut reaction) [13:43] zyga: Okay, I must be forgetting about some detail related to namespaces.. the namespace needs to be user-specific, and this file path doesn't look user specific [13:43] Ah, no, it's not user specific [13:43] niemeyer: that's correct, this is the non-user-specific namespace; the bug is that because of sharing settings some changes don't propagate to the per-user namespaces [13:43] That's what I'm forgetting [13:44] Ack [13:44] niemeyer: the PR changes the settings to properly propagate into per-user mount namespaces [13:44] zyga: So yeah, the content is really missing [13:44] niemeyer: we're hoping it will be in 2.40 [13:44] zyga: Okay, cool [13:44] zyga: Thanks! [13:44] zyga: How's spain? [13:45] niemeyer: honestly, I'm just a piece of luggage here; I'm working all the time anyway. The kids seem to like it though, recalling memories and seeing friends [13:45] jdstrand: zyga: probably buggy middle ground? https://paste.ubuntu.com/p/nMVvYKpyQ2/ [13:45] zyga: Hope you can enjoy the evenings with them a bit at least [13:45] mborzecki: that would work but remember that the reason the callback exist is so that the os-release parser can extract ID and other fields that we need to look at without changing this function again [13:46] niemeyer: yeah, though evenings are the best moments to work for now, I take mid-day slow (I recall why siesta existed) and try to compensate in the evening [13:46] niemeyer: looking forward to a slower weekend though :) [13:47] mborzecki: that is like all that I was expecting from this PR [13:47] niemeyer: https://twitter.com/zygoon/status/1144347521613017106 [13:49] mborzecki: that verified with tests/etc is inline with what I would prefer. the fact that you loop through the whole file on each run is no big deal now (there is only one thing in the .info file) and isn't a big deal for os-release since it is small as well and one would want to extract like only a key or two anyway [13:49] zyga: jdstrand: ok, so perhaps we could work with that for now and then look at os-release once the fix lands? [13:50] jdstrand: does that mean that the door for the future where this code can be brought back is open or that you'd rather use the simpler implementation and just loop over input several times? [13:50] jdstrand: is this still blocked? https://github.com/snapcore/snapd/pull/5644 [13:50] mborzecki: a future optimization for that could be read it into memory and pass that stream into sc_infofile_get_key(). then everything stays clean. if we were talking about large files, that would be different and we'd need to consider something smarter [13:51] jdstrand: note, I wrote that version once, it was also nacked [13:51] jdstrand: one that read everything into memory and scanned that [13:51] mborzecki: but that isn't the case (we can even comment "To keep this simple, ..." [13:51] jdstrand: I have a feeling this is the 4th attempt at this key=value thing for snap-confine [13:51] zyga: I did say 'future' there [13:53] mborzecki, zyga: this PR seems like is is not focused, so yes, I like mborzecki's approach. do something simple and verifiable to fix the 'base changes' bug. then iterate to read os-release. we can land that sooner than later. for os-release, we can argue about the merits of efficiency vs simplicity/etc with all the right people looking at it [13:54] kenvandine: yes [13:54] kenvandine: it needs me to grandfather hundreds of snaps. it is still on for this cycle [13:55] jdstrand: ok, thanks [13:57] zyga: Nice! [13:58] zyga: How do I get the namespace to work again? [13:58] zyga: re open door> part of why we have peer reviews for this code is multiple viewpoints. I am always going to want simplicity in code for auditability, reliability and provability. if this was not setuid, it would be different. there is no obvious need (to me) for the optimizing, even when considering os-release. Michael and Samuele can overule that after hearing all sides [13:58] niemeyer: you'd have to discard it, I'm afraid [13:58] zyga: Already did [13:58] zyga: New namespace has the same issue [13:58] niemeyer: if it doesn't work now it may be some other issue [13:58] niemeyer: can you run this from the terminal with SNAP_CONFINE_DEBUG=yes [13:58] after discarding it [13:59] zyga: I'm concerned about-- what happens if the user is able to trick snap-confine into reading a file the user controls, and there is a bug [14:00] jdstrand: I share those concerns, I think we are on the same page here. I specifically made sure this robust (even to the point of fixed memory sizes in the follow-up) [14:00] zyga: I'm not saying the code has a bug. I'm just saying it takes a lot of mental thought to verify it is all ok and that thought will need to be expended every time this part of the code is touched when it lanes [14:00] lands* [14:00] zyga: https://pastebin.canonical.com/p/dC2YbSXMsr/ [14:01] * zyga fetches token [14:01] zyga: I know you're being careful! :) you have great checks; it is just so much more than seems required I balked at it [14:02] jdstrand: ack [14:02] zyga: perhaps save it off for now, take the middle ground approach for now and revisit when everyone is back in town? [14:02] jdstrand: yeah, I think that's the only way forward [14:02] * jdstrand notes he is off Tue-Fri next week [14:04] niemeyer: is this after you have discarded? I'm surprised to see "keep" changes there [14:04] (keep indicates that an existing entry is reused) [14:07] zyga: Yep [14:07] zyga: I assume that to discard I need to umount and rm [14:07] niemeyer: how did you discard if I may ask? [14:07] zyga: Am I missing something? [14:07] not quite, you must run the discard tool, it also removes the .fstab files [14:08] (those in /run/snapd/ns) [14:08] Aha [14:08] I mean, you must umount and rm stuff in /run/snapd/ns that matches the snap name) [14:08] There's nothing there [14:08] Uh, no, I'm lying [14:09] nothing in /run/snapd/ns/snap.*.fstab [14:09] zyga: Yeah, that fixed it [14:09] zyga: The rm of the fstab, that is [14:09] good, I'll look at fixing the propagation ASAP [14:10] kenvandine: Works, will be playing with it on the flight back home [14:10] zyga: Thank you! [14:11] niemeyer: awesome [14:19] zyga, mborzecki: ok, summarized my thoughts and irc outcome here: https://github.com/snapcore/snapd/pull/7026#pullrequestreview-255757563 [14:19] jdstrand: I'm almost done, one sec [14:19] I'll push the simplified version [14:21] jdstrand: pushed [14:21] zyga: I'm sorry for the extra work. we all want the same thing ultimately even if we have different opinions on how to get there. thanks for being patient (with all of the reviewers) [14:22] jdstrand in the extra test, you mean one that has a trailing newline? [14:23] jdstrand: because malformed input test 3 already does that without the newline [14:23] * zyga adds the extra test just in case [14:26] zyga: yes [14:26] added now [14:26] zyga: ie, the file we read in has [14:26] foo= [14:26] bar=baz [14:27] jdstrand: https://github.com/snapcore/snapd/pull/7026/commits/701b333abbdec24af7eea53f8a1479bb43ff3dc1 is this what you expected? [14:27] and foo is assigned the empty string [14:27] (or if you don't want to support empty strings, a test that it isn't allowed) [14:27] I want to support empty values [14:27] I think it is useful [14:28] zyga: I do too. then, 'yes' that is what I had in mind, but it isn't malformed [14:28] yeah, I think those are "tricky" but not clearly malformed :) [14:28] I'll rename those [14:29] char empty_value_ok = "key=\n"; [14:29] ? [14:29] but choose whatever you want [14:30] pushed [14:30] I think this matches the discussion and can be approved now [14:32] * zyga needs to take the dog out [14:47] ogra@pi3:~$ grep PRETTY /etc/os-release [14:47] PRETTY_NAME="Ubuntu Core 16" [14:47] ogra@pi3:~$ snap debug sandbox-features|grep confinement [14:47] confinement-options: classic devmode strict [14:47] why does that list classic on an UbuntuCore system ? [14:47] ogra: bug, should be fixed [14:48] k [14:52] mborzecki: https://github.com/snapcore/snapd/pull/7045 [14:52] just want to formally ack it, it's just a simple make fmt [15:01] ogra: https://github.com/snapcore/snapd/pull/7048 [15:02] zyga, ah, nice ! [15:11] jdstrand: not binding in any way: https://github.com/snapcore/snapd/pull/7049 [15:12] I don't know if it passes tests yet [15:12] just wanted to open it to see what happens and see what you think [15:41] zyga: approved both === pstolowski is now known as pstolowski|afk === ShibaInu is now known as Shibe [16:13] Oh, great, thank you :-) === ricab is now known as ricab|bbl === ricab|bbl is now known as ricab [20:20] I'm trying to run a script as part of the snapification to symlink some libs that aren't being found. I'm doing it with override-prime, but that doesn't seem to be doing anything [20:20] that is, i see no override message in the snapcraft build log and no symlinks [20:20] is there some other, better way of doing this?