[00:11] wgrant: should http://cpisnap.ols.internal/api/v1/ still work? [00:11] ah [00:11] d'oh [00:11] .internal [01:05] hello, I'm trying to make a snap for openmw (re-implementation of the morrowind game engine) and when trying to launch my snap, I'm getting the error "libGL error: unable to load driver: i965_dri.so" I think I might be missing a plug. Does anyone happen to know which plug would make that driver available? I've tried adding x11, opengl, home, and pulseaudio. [01:14] jorian: This may be a red herring, but my question is, is there such a file inside your snap? [01:20] qengho: it seems to be in 3 places inside the snap directory [01:20] ./parts/openmw/install/usr/lib/x86_64-linux-gnu/dri/i965_dri.so [01:20] plus in stage and prime [02:07] I'm looking at the guide for creating a snappy interface on zygoon.pl. The method involves editing the snapd source and the recompiling the whole project. Is there currently a way to add interfaces externally / by installing a snap similar to how the core snap works? [02:11] I need to create an interface to allow writes to /var/run but I don't really want to have to manage a custom version of snapd [03:09] Thank you wgrant, I appreciate the help! [03:10] olympionex, the only reason the core snap can make any interface available is because the interfaces it supports are supported by snapd [03:10] It's not doing anything special [03:11] kyrofa: thanks -- I see that now looking at the source [03:11] kyrofa: all the interfaces are in snapd itself [03:11] qengho, if jorian comes back, the gl libs are required in stage-packages. Specifically libgl1-mesa-dri [03:12] olympionex, indeed: interface SUPPORT is in snapd, but then the producer (slot) side of interfaces must be supplied by a snap, and the consumer (plug) side must be consumed by a snap [03:12] The interface being USED by the plug/slot, however, must still be one that's supported by snapd [03:14] Oh wait... qengho nevermind, looks like that lib made it into prime. Just missing the right LD_LIBRARY_PATH then, it seems [03:14] I see - so the content plugin lets a snap provide access to some internal path, but if I want to access some other system path, I will have to add it to snapd [03:14] olympionex, yes. Although I'm curious about your use-case, do you mind sharing? [03:15] kyrofa: yeah, I just have a binary that I don't have the source to and it creates some socket files in /var/run [03:15] olympionex, yep that would do it :P . However, have you investigated using LD_PRELOAD to get around it? [03:16] kyrofa: i was using classic mode, and probably still can, but it looks like it changed a bit in 2.22 maybe [03:16] hmm, I'm have a look at that [03:16] 2.22 is a bit behind, 2.25 is out now [03:17] olympionex, there's a preload part out there already if you want to check it out. Here's an example of how to use it: https://github.com/nextcloud/client_theming/blob/master/linux/snap/snapcraft.yaml#L50 [03:17] Check out line 34 as well for where it's pulled in [03:18] I actually meant snapcraft 2.22. The new version doesn't add the library paths to the command wrappers it generates. I can of course just make my own script that gets called by the wrapper, but I need to research all the consequences. I was just checking again about running it in strict mode [03:19] olympionex, in that case it's even older: 2.29 is out :P [03:19] olympionex, yeah, strict is _always_ best if you can swing it [03:19] olympionex, classic snaps have trouble running on other distros, and they don't run on ubuntu core either [03:20] olympionex, definitely worth investigating that preload part, especially considering it's an extra line and a half [03:20] kyrofa: We've identified the two bugs in dashboard.snapcraft.io that combined to cause this issue. It's possible you'll run into similar issues again with that particular snap until we fix the root cause properly, but we know what's going on now so that should be quick. [03:21] wgrant, it's something particular to the snap?! [03:21] What did I break? [03:22] kyrofa: A review race caused one of the revisions to get stuck in a bad state, and that will possibly confuse further automatic refuses until we fix that old revision. [03:22] ... [03:22] s/refuses/reviews/ [03:22] Hopefully not refusals :) [03:22] wgrant, ah ha, I wondered about that weird rev :P [03:22] They shouldn't fail, just get stuck [03:22] wgrant, if I reject it, would that fix things? [03:23] kyrofa: Quite possibly. We already know we need to manually fix that revision, so rejecting it can't really make it worse. [03:23] So might be worth a try. [03:23] * kyrofa tries [03:24] kyrofa: fortunately i have a limited set of systems I have to run on. I use snapcraft to simply our internal deployment of some software. Still, i prefer to get things working in the most supported way to avoid suprises later. [03:25] olympionex, understood [03:26] kyrofa: Looks like that's worked. [03:26] So we just need to manually fix up 1418 later. [03:27] wgrant, no need to worry about that one [03:28] kyrofa: thanks for the preload info, i was looking at some ELF hacking but this may be cleaner [03:28] olympionex, yeah that would not be fun [03:28] And of course, any time :) [05:56] PR snapd#3393 opened: Add retry mechanism for snap install command to fix test === koza|away is now known as koza === JanC_ is now known as JanC === elfgoh_ is now known as elfgoh [07:11] pedronis, mvo mind unblocking re-reviewing https://github.com/snapcore/snapd/pull/3353 ? [07:11] PR snapd#3353: Add support for reboot parameter [07:18] good morning [07:19] PR snapcraft#1333 opened: state: search for the dependencies in the archive [07:21] morning zyga! [07:27] o/ [07:32] zyga: hey! [07:32] zyga: time for a review on https://github.com/snapcore/snapd/pull/3371 ? [07:32] PR snapd#3371: packaging: import packaging bits for opensuse [07:35] morphis: looking [07:39] zyga: CI hates me, another store timeout [07:52] zyga: but thanks for approving [07:52] zyga: and a review on https://github.com/snapcore/snapd/pull/3365 would be nice too [07:52] PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup [08:03] morphis: what does it mean https://github.com/snapcore/snapd/pull/3365/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R268 ? [08:03] PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup [08:04] didn't the pkgdb helper land already [08:04] ah [08:04] sorry, I see [08:04] zyga: you can't use it at this place [08:04] ok :-) [08:05] ooh, listen to the wind! [08:05] it sounds like "reeeeviewwsss" [08:05] good morning peeps [08:09] morphis: done [08:10] hey Chipaca [08:10] * zyga feels miserable [08:11] zyga: :-( [08:11] zyga: did you see the issues ryebot was having yesterday? [08:13] Chipaca: yes but I didn't manage to reply [08:13] zyga: 's ok; i just don't want to have to remember it myself [08:14] if you're aware, i can forget [08:14] thanks :-) [08:41] Chipaca: I nitpicked a bit on one of your PRs [08:41] pedronis: good morning to you too :-) [08:42] zyga: ok, updated the PR [08:43] pedronis: good points you make [08:43] http://paste.ubuntu.com/24642129/ [08:43] pedronis: i'm currently working on a bug where we don't distinguish "already at the latest revision on that channel" from "that channel does not exist" [08:43] any wording suggestions before I do the full set? [08:44] pedronis: (you can try it! snap refresh core --channel potato) [08:44] pedronis: (then check 'snap info') [08:44] (ideally the output would be more consistent) [08:44] and not sure what to do with "allows" [08:44] maybe just skip it [08:44] 's fun [08:45] fun fact: we have 91 interfaces [08:45] I'll add a 100th anniversary interface ;-) [08:47] Chipaca: can we do it without store help? [08:47] pedronis: the store is telling us [08:47] (more or less) [08:48] pedronis: i'm fixing it alreayd [08:48] zyga: I don't want to be a party pooper but https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-possible-revert-race-condition/722 is currently higher on the priority list than anniversaries ;) [08:48] pedronis: basically ListRefresh is fine for multi-updates, but we need a special one for single updates that doesn't throw away this info [08:48] pedronis: pretty much exactly the same except if the store returns nothing, raise an error [08:48] Chipaca: just telling me why you won't fixing my nitpicks straight away :) [08:49] pedronis: yes, that's exactly what i'm doing [08:49] you're very perceptive today [08:49] but inpolite because I didn't say good morning yet [08:50] pedronis: what's a good name for something that does what store.ListRefresh does, but for a single refresh candidate? [08:50] mvo: you are completely right [08:50] mvo: I'll finish this PR and send it for review in a moment [08:51] mvo: but before I do that, let's chat here briefly [08:51] mvo: if the new syntax is a blocker (I mean |N) then the plan falls apart [08:52] zyga: yeah, its rather annoying [08:52] mvo: your plan to compile seccomp profiles in snapd is possible [08:52] mvo: but, well, needs discussion [08:52] mvo: we could make a new internal helper [08:52] zyga: we would have to generate old-style files for a while for backward compatiblity [08:52] mvo: why? I don't think so [08:52] zyga: old style with a frozen format so that also is slightly complicated [08:52] zyga: no? [08:52] mvo: (just whatever matches snap-confine) [08:52] zyga: aha, just leave the old ones around :) ? [08:52] mvo: yes [08:53] mvo: so we'd stop writing the old files entirely (but not remove them yet) [08:53] mvo: for revert specifically [08:53] zyga: hm, that would break in the case of "snap refresh core; snap install hello; snap revert core", then hello would no longer work. maybe not too terrible [08:53] mvo: aha [08:53] mvo: interesting, yes, it would work if snapd would start before "hello" but I see your point [08:54] zyga: aha, good point [08:54] mvo: but the bigger issue is that we'd have two seccomp profiles per security tag [08:54] mvo: one old and one new, with different semantics (because no |N) [08:54] zyga: yeah, that is the part that worries me, it feels fragile [08:54] mvo: but if we do that we can use the old text format [08:54] mvo: because we'd just write two files [08:54] mvo: one with |N and one without [08:54] heh [08:54] good point [08:54] * zyga greps for |N syntax [08:55] well, the seccomp bpf would make us future proof forever(tm) [08:55] weird [08:55] mvo: I agree on that [08:55] (needs some research but it looks like bpf is pretty stable as a binary format) [08:55] yes [08:55] zyga: what is weird? [08:56] mvo: I don't see any |N syntax with quick grep [08:56] Chipaca: LookupRefresh ? [08:56] are we even using this? [08:56] mvo: (also it would be faster for startup, which is nice) [08:57] zyga: let me double check the debdiff [08:57] mvo: can you grep for anything that uses this [08:57] thanks! [08:57] zyga: if we are not using it, that would be splendid [08:57] * zyga feels sick again [08:57] yes :) [08:57] (perfect timing, just before a conference) [08:57] zyga: uh, get some rest if you feel sick, I can work on this [08:58] zyga: seriously, get well, especially if you need to travel soon [08:58] mvo: no, I cannot do anything about it :/ [08:58] zyga: meh, ok [08:58] mvo: I'd rather finish the interface meta-data changes and feel better by doing that [08:58] mvo: sick as in food-sick, not flu-sick [08:59] zyga: autsch, ok. all right, I do the investigation on |N while you finish your interface work :) [08:59] OK [08:59] zyga, mind unblocking/re-reviewing https://github.com/snapcore/snapd/pull/3353 ? [08:59] PR snapd#3353: Add support for reboot parameter [09:08] zyga: we use the |S_IFREG in our default template now https://github.com/snapcore/snapd/blob/master/interfaces/seccomp/template.go [09:08] zyga: I will write a forum topic with some ideas, looks like it is not going to be super simple, but maybe not to hard either [09:20] mvo: zyga: one of you should probably review snapd#3350 if we want it in 2.27 [09:20] PR snapd#3350: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots [09:21] anyway I suppose 2.27 is delayed by a fair bit because of 2.25 issues? [09:21] *fair bit now [09:21] pedronis: yeah, there is a slight crisis right now :/ [09:22] mvo: can't we just change the names of the seccomp profiles ? or start putting them into profiles/something [09:22] s/something/somehash/ [09:22] and teach 2.26.x snap-confine about new new place [09:23] s/new new/the new/ [09:24] pedronis: probably, there is still this problem that "snap refresh core; snap install daemon; snap revert core" may lead to the same issue we currently having. i.e. the new snapd does only write a new seccomp file but on reboot daemon starts so early that the old snapd does not generate a new seccomp file early enough. but still doing this would probably get us a long way forward [09:25] reverting core after installing new stuff is bound to create troubles anyway in some scenarios [09:26] * mvo nods [09:26] I mean can see some non security profiles one [09:26] mvo: do we use |S_IFREG or just S_IFREG? [09:26] pedronis: ack [09:27] has anyone used the snapcraft-preload project? I'm thinking there is a bug in the preload for the bind method, or possibly there is something i'm not doing. When creating an AF_UNIX socket, it would seem that it should redirect to a writeable path, but that doesn't seem to be the default behavior, at least for my case. I have manually patched it on my side and it seems to work, but just wanting to verify. [09:27] olympionex: guys who wrote that are in americas so I'd suggest opening a forum topic [09:30] zyga: the former |S_IFREG [09:32] mvo: aww, drat [09:32] mvo: well [09:32] mvo: plan B [09:32] mvo: revert that change [09:32] mvo: like we did before [09:33] mvo: if it is just one spot it is easier [09:33] ah, there are a few [09:33] all the mknod [09:34] hmm hmm hmm [09:34] zyga: yeah [09:37] mvo: so what is your plan? [09:38] zyga: can you merge https://github.com/snapcore/snapd/pull/3371 ? [09:38] PR snapd#3371: packaging: import packaging bits for opensuse [09:39] zyga: I'm still pondering, its tricky. worst case would be to revert the new syntax again, i.e. revert all mknod and keep quotactl via the secompSymbolTable branch. we need jdstrand input here [09:39] morphis: done [09:39] PR snapd#3371 closed: packaging: import packaging bits for opensuse [09:39] mvo: the question is, what do we lose if we do that [09:39] mvo: was this released in 2.25? [09:40] abeato: some feedback [09:40] zyga, ok, thanks [09:48] zyga, I've answered one of the comments [09:58] zyga: yeah, the mknod was released in 2.25, I think we need jamies input. but I will also try to find out more [09:59] mvo: can we replace |foo with a list of rules? [09:59] hmm, so using delta updates on the pi3, the delay is noticeable but not super awful [10:00] i fear that wont be usable on a bbb [10:00] PR snapd#3388 closed: osutil: add non-blocking flock [10:02] sorry I did this merge ^ but messed up a bit the commit message, because GH seems very partial on what it remembers or not when you move away and back to a merge in progress [10:22] PR core#35 closed: move xdg-open to proper paths [10:22] PR core#38 closed: Add another pi-config option [10:23] PR core#35 opened: move xdg-open to proper paths [10:23] PR core#38 opened: Add another pi-config option [10:23] mvo: fgimenez: do you guys have dev access to etcd? [10:24] actually, i just want to know a revision of etcd that isn't published [10:24] bah [10:24] never mind [10:24] Chipaca: i don't sorry [10:24] * Chipaca noticed the store's response [10:25] $ /tmp/snp install potato --revision 2 --channel whaat [10:25] error: snap "potato" not found (at least in channel "whaat/stable" at revision 2) [10:25] incredible how much work i had to do to get that (at least) there [10:27] PR snapd#3394 opened: interfaces/seccomp: add bind() syscall for forced-devmode systems [10:31] mvo, what is linux-armhf ? is that leftover cruft ? https://forum.snapcraft.io/t/issues-while-porting-ubuntu-core-16-image-for-olimex-lime2-platform-board/761 (snap info says its yours) [10:34] that's an old kernel [10:34] yes [10:34] from before we could have multiple architectures in the same snap [10:34] i just wonder why it is available [10:34] we did a big cleanup run a while ago [10:35] zyga: thanks! [10:39] gaah [10:39] ogra_: fwiw i can confirm it's in the store [10:39] at revision 9 [10:40] Chsure, i wouldnt have pinged if i had not checked it before ;) [10:40] yeah, in all channels [10:40] zyga: gah? [10:40] so, interface summary is very confusing to write [10:40] as plugs and slots have totally different purpose [10:40] what is a good summary of the "pulseaudio" interface? [10:41] it's both to be pulseaudio service and to talk to it as a clinent [10:41] zyga: "this interface lets you pulse your audio" [10:41] should we have two summary lines per interface? (up to) [10:42] zyga: are both those things available to you when you use it as a slot? [10:42] Chipaca: no, but this is not about plugs or slots [10:42] zyga: maybe it should be [10:42] Chipaca: this is about the new "interface" command and interface meta-data [10:42] Chipaca: what interfaces do you have? (not instances, types) [10:43] http://paste.ubuntu.com/24642921/ [10:43] Chipaca: my misery so far [10:43] Chipaca: maybe "allows operating as or using the pulseaudio service" [10:44] zyga: is the "allows" there something you've agreed to standardize on? [10:44] looks nasty af [10:44] no, this is still a prototype [10:44] :-) [10:44] af? [10:44] zyga: how about you drop the allows and verb the thing you have after it? [10:44] zyga: as fireworks [10:45] :-p [10:45] Chipaca: yeah, I'm open to suggestions, I'll finish this pass to just have something consistent for each and then propose the bits and pieces [10:45] zyga: i mean: "allows frobbing the plumus" -> "frob the plumbus" [10:45] this is just one patch among many and one that I suspect we'll bikeshed the most [10:46] Chipaca: try this on 5 different real interfaces or it doesn't count [10:46] zyga: i did :-) [10:46] Chipaca: how about network? [10:46] ogra_: hm, a very old kernel that I put there for experiments I think, I will unpublish it [10:46] zyga: "access the network" [10:47] zyga: pulsaudio would be, for example, "host or communicate with a pulsaudio server" [10:47] mvo, thanks [10:47] ogra_: done [10:48] zyga: unity8 would be "aw, bless" [10:48] Chipaca: kind of like the pulseaudio thing but this is still very confusing IMO, from users POV (no deep insight into plug-vs-slot semantics) there's a lot of difference here [10:48] zyga: remember these are more for orientation and not explanation [10:48] that is, details at the url [10:48] yes, that is true [10:49] the URL is already in the meta-data [10:49] zyga: a user looking at this list is either refreshing their memory, or wanting to know what to read to learn more [10:49] zyga: so you give them enough information to pare down the list [10:50] anything networkish, they're probably going to have to look at all the network* things the first time to figure out what they need [10:50] the second time it'll be enough as is [10:57] PR snapd#3381 closed: logger (& many more, to accommodate): drop explicit syslog [11:02] zyga: hmmm [11:02] yes? [11:03] $ snap remove http [11:03] error: cannot perform the following tasks: [11:03] - Remove security profile for snap "http" (x1) (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented) [11:03] Chipaca: you are using snapd from master but the rest from package [11:03] Chipaca: just buind and install snap-update-ns [11:03] ah ok [11:03] also [11:03] our error stacking sucks [11:03] i'll get there eventually [11:04] Chipaca: you want discard-ns too [11:04] FYI [11:04] and snap-confine [11:04] zyga: so, make hack [11:04] or you may hit weird issues [11:04] Chipaca: yes, and I need to teach it to build the go parts maybe :) [11:04] nah, those are easy :-) [11:06] just 4 left [11:08] ok, i've got to run [11:08] got physio [11:08] take care! [11:08] I probably won't be back in time for standup [11:09] morphis: is this https://forum.snapcraft.io/t/run-configure-hook-of-core-snap-if-present-runs-seemingly-forever/674/2 the snapctl/bind issue likely, or something else? [11:09] so: i'm working on "snap refresh core --channel bogus" (which currently, erroneously, works) [11:09] got a fix already, fixing tests and cleaning it up, should have pr before eod [11:09] also, got some work to do on go patch [11:11] pedronis: it looks different here as from the log output it hangs at "Mount snap" [11:11] so the topic is wrong? [11:11] pedronis: and the bind() issue shouldn't occur for the core snap as the core snap now plugs network-bind [11:11] it's not about configure [11:11] pedronis: the first post in that topic is [11:12] "[-] Run configure hook of "core" snap if present" [11:12] ok, confusion === tinwood is now known as tinwood_afk [11:43] zyga: https://github.com/snapcore/snapd/pull/3394 is ready for a merge unless you want someone else to have a look [11:43] PR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems [11:43] morphis: can mvo ack it please? [11:43] mvo: ^^ === chihchun_afk is now known as chihchun === tinwood_afk is now known as tinwood [13:57] * zyga prepares the three banches [14:00] zyga: btw. when you try lxd on suse just don't forget to disable AppArmor for the containers [14:01] niemeyer: Spread-32 is now down to 1.3G, ok for you? [14:07] morphis: aha [14:07] morphis: how do I do that? [14:08] zyga: --with-less-security [14:09] zyga: --make-hackable [14:09] zyga: --wanton-insecurity [14:09] zyga: --make-chipaca-stop [14:09] Chipaca: sudo make me a sandwitch [14:09] PR snapd#3395 opened: many: remove interface meta-data from list of connections [14:09] * zyga didn't eat anything but breakfast today [14:09] fgimenez, how do you usually retriger a ci check when there is a failure which doesn't need any change in the code? [14:09] Chipaca: ^^ please land that [14:09] fgimenez, I got this https://travis-ci.org/snapcore/snapd/builds/235333896?utm_source=github_status&utm_medium=notification [14:10] zyga: you're going off? [14:12] zyga: https://github.com/lxc/lxd/issues/3096 [14:18] cachio: i can't retrigger on travis sorry, i think only people in the snapd-commiters team can retrigger [14:18] cachio: usually, if your PR needs to wait, merging master is a good idea in general, that push retriggers the build [14:22] zyga: https://github.com/lxc/lxd/issues/3345 [14:27] fgimenez, nice, tx [14:37] morphis: Any chance we can take it a bit further down? This will likely be something like ~2G for imaging purposes [14:38] * zyga -> car & kids [14:48] PR snapd#3396 opened: interfaces: add summary to each interface [14:50] PR snapd#3397 opened: interfaces: disable "mknod |N" in the default seccomp template again [14:51] niemeyer: ^^ [14:55] morphis: Also sent a review on the no-apparmor bind issue.. we should probably have forum conversation about that one.. given the comment is not entirely clear that we're in agreement about what's going on in that case [14:57] cachio: hey [14:57] cachio: some failing tests https://travis-ci.org/snapcore/snapd/builds/235657720?utm_source=github_status&utm_medium=notification [14:57] cachio: please collect the log if you want to keep inspecting it, as I want to restart the test [14:59] PR snapd#3393 closed: tests: add retry mechanism for snap install command