[00:01] zyga-ubuntu: thanks. it is high on the list but after two things [00:01] zyga-ubuntu: ie, consider it enqueued. have a nice evening :) [00:04] jdstrand: thank you, likewise :) [00:05] PR snapd#4063 closed: tests: add new kernel refresh/revert test for spread-cron [00:20] om26er: the snap version of sublime text has low-res icon [00:20] om26er: the deb has much better one, is that a store side issue or just a mistake somewhere? [00:20] zyga-ubuntu: yeah 64x64 variant [00:21] the source has others as well, so we can use them [00:21] 128x128 be fine ? [00:21] why did we pick the 64x64 icon? [00:21] zyga-ubuntu: ^ [00:21] on low-dpi screen 64x64 looks bad when alt-tabbing [00:21] I'd provide all the highest-res one [00:21] is that even possible ? [00:21] (and this is an interesting TODO for theming to allow many icon sizes to ship with each app) [00:22] s/all// [00:22] just the one high-res one [00:22] yeah so 128x128 sounds good to you ? [00:22] om26er: whichever is highest resolution in the original package [00:22] om26er: if that's 128x128 that's fine, if there's a 256x256 use that one [00:22] I think they have 256x256 as well [00:23] om26er: and it'd be cool to have track this in desktop theme discussions [00:23] om26er: as it looks like an oversight on our end, something we should do better [00:23] In an ideal world our system will chose icon automatically based on DPI [00:23] om26er: (provide many icons) [00:23] om26er: right but we cannot even *ship* more than one icon size yet [00:23] yeah [00:32] PR snapd#4534 closed: release: 2.31~rc1 [00:33] Son_Goku: note, 2.31 rc1 is not ready for packaging, [00:33] Son_Goku: we'll have rc2 for sure, maybe more [00:33] didn't think it was [00:36] I'm only planning on doing 2.30 for now anyway [00:54] zyga-ubuntu: you might find this interesting: https://fedoraproject.org/wiki/Workstation/Flatpaks [00:56] Son_Goku: ack, I'll read that tomorrow [00:57] man, it's 2AM already [00:57] zyga.susped() [01:06] PR snapd#4537 opened: interfaces/builtin: Replace Solus support with GLVND support [01:09] ok so yeah the interfaces still make zero sense [01:14] like i cant see anywhere that allows me to do "only connect to this particular snap and do so automatically" .. [01:21] *oh* that happens in the store [01:21] well then. [01:51] PR snapd#4538 opened: interfaces/builtin: Add new steam-support interface [06:01] morning [06:28] mborzecki: o/ [06:28] mborzecki: master isn't happy now [06:28] zyga-ubuntu: hey [06:28] mborzecki: - linode:ubuntu-core-16-64:tests/main/kernel-snap-refresh-on-core [06:29] I think we have to disable it to fix builds & investigate [06:29] zyga-ubuntu: hm this one was also randomly failing [06:32] I'm kind of sleepy [06:32] I couldn't sleep and I was here at ~3 AM [06:36] zyga-ubuntu: do you have a link to the travis job where the test failed? [06:40] mborzecki: https://github.com/snapcore/snapd/pulls the top three [06:53] zyga-ubuntu: something fishy about linode, 2 runs attempted, both ended with io timeout when connecting to the machine [07:04] mborzecki: you need to update spread [07:04] mborzecki: brand new spread is out now [07:08] hey mvo [07:08] hey zyga-ubuntu [07:09] zyga-ubuntu: how are you? [07:09] haha, good question [07:09] I went to bed at 3AM [07:09] and woke up at 6 [07:09] 7 [07:09] zyga-ubuntu: woah [07:09] (not six, didn't hit the key right) [07:09] * mvo hugs zyga-ubuntu [07:11] I think my back is worse than my head [07:11] mvo: I merged some things last night, reviewed most of the rest [07:11] mvo: things are either green or need fixing now [07:11] but I believe I broke master by merging one spread test [07:11] last three runs show it as broken [07:11] linode:ubuntu-core-16-64:tests/main/kernel-snap-refresh-on-core [07:12] mvo: morning [07:14] zyga-ubuntu: well the test is awkward [07:16] zyga-ubuntu: aha, yeah, this one should be set to manual I think, let me double check [07:16] hey mborzecki good morning [07:16] take a look at this: https://paste.ubuntu.com/26456741/ stable and edge channels carry the same version atm [07:17] i guess that's why snap_try_kernel ends up being unset [07:20] * Son_Goku rises from the dead [07:20] Son_Goku: OMG go to sleep [07:20] don't do what I did [07:20] I tried... so hard [07:21] I coudn't sleep, so cold last night [07:22] mvo, mborzecki: one amazing thing last night was that I could restart any job and it would just go [07:22] zyga-ubuntu: you can do the same over the weeked and still get some sleep :) [07:23] mborzecki: I didn't plan on doing this [07:25] zyga-ubuntu: mvo: tests/main/kernel-snap-refresh-on-core to manual then? [07:25] yes [07:25] or make it smarter and have it skip [07:25] if same thing on both channels [07:26] mborzecki, zyga-ubuntu or both, manual and smarter, we want this to run nightly via spread-cron [07:27] https://paste.ubuntu.com/26456780/ any idea why pc-kernel versions don't have the 'up arrow' in snap info? [07:30] mborzecki: I think you only get it if the channel is closed, here its all the same rev but put in the channel explicitely [07:40] mborzecki: are you looking into this? if not I can push something in 4 minute or so [07:40] mvo: yes, i'm testing a fix right now [07:41] mborzecki: cool, thank you [07:44] https://pastebin.ubuntu.com/26456824/ :/ [07:48] zyga-ubuntu: uhhh [07:50] that's ok, I'm going to get rid of all this eventually [07:50] mvo: why do we lose license data? [07:50] mvo: what's the reference data, is it snap.yaml or the store? [07:50] I think there was some discussion about that last night [07:51] * zyga-ubuntu pulls the link [07:51] https://forum.snapcraft.io/t/snap-license-metadata/856/17?u=zyga [07:52] mvo: my question is this, can we just load the license from yaml today [07:52] (for local snaps) [07:52] and treat that as authorative? [07:53] zyga-ubuntu: i think the problem is that there is no license information in meta/snap.yaml [07:53] PR snapd#4533 closed: errtracker: include detected virtualisation [07:53] zyga-ubuntu: it is store data that we do not store locally [07:53] zyga-ubuntu: I think we can [07:53] zyga-ubuntu: if we have it there [07:54] zyga-ubuntu: but most of this is store data [07:54] mvo: hmm [07:54] mvo: but snaps can also store it in meta/snap.yaml, right? [07:54] I think I saw that in the spec [07:54] the snap info does a store roundtrip anyway, it may be just a matter of merging the information [07:54] zyga-ubuntu: I need to get back to the london sprint discussion, I don't remember the details right now [07:55] mvo: yeah, I'm looking at that now [07:55] yes, there's a license: field now [07:55] mvo: so... [07:55] Chipaca: what was this email you talked about yesterday? [07:55] zyga-ubuntu: cool [07:55] I think the is a bug in general that store and meta-data can get out of sync [07:56] but this can be a good start, just show the license field, either sourced locally or remotely [07:57] PR snapd#4539 opened: tests/main/kernel-snap-refresh-on-core: do not fail if edge and stable kernels are the same version [07:58] i'm a bit confused with what happens in `snap info`, we do a store round trip, get the data, get the local data, then prefer the local data for all fields but the ones that cover channels [07:59] mborzecki: I think Chipaca knows why, I'd love to know too [07:59] an easy way out would be to display the license information from the store data, provided we're able to query the store for info on the snap revision we have installed now (?) [08:00] an alternative is to store the license information when installing the snap (that's what i'm lookin into now) [08:00] mborzecki: I think there's something odd about having to query the store for license of something we installed already [08:01] mborzecki: it's wrong on many levels [08:01] mborzecki: yeah, I think we must not permit the license to vary without the revision varying as well [08:01] mborzecki: I think that is what we want - store the information locally [08:01] mborzecki: it's probably illegal [08:02] btw. snap.Info has some intersting fields like LicenseAgreement, LicenseVersion ;) [08:02] mvo, mborzecki: but there's still the interesting case of snap meta-data that disagrees with the store [08:02] mborzecki: legacy from EULA support days [08:02] when one snap installs a snap locally [08:02] and acks the assertion [08:02] yeah, these are not there inside store.snapDetails ;) [08:03] I think it's a bit of a mess, perhaps we could refuse to install snaps that disagree on license from assertion and from the meta-data? [08:07] good morning [08:07] hey kalikiana [08:07] kalikiana: how are your REs? [08:09] mvo: SideInfo is stored in state.json right? [08:09] mborzecki: correct [08:09] mborzecki: yes [08:14] zyga-ubuntu: going back to being simpler. getting the processor to connect the "compound" statements now. which should be more maintainable long-term [08:19] hey o/ [08:22] hey paweł [08:22] pstolowski: hey [08:29] PR core#70 closed: hooks: use symlink to run `snap advise-command` [08:29] PR core#71 closed: live-build: make /lib64/ld-linux-x86-64.so.2 a relative link [08:29] PR core#73 closed: Support for armhf binaries on arm64 (aarch64) operating system [08:32] mborzecki: can you look at 4539, either way the answer will unblock master [08:34] koza: hey, is https://github.com/snapcore/core/pull/76 ready to merge? iirc you were thinking about improvements to the text plus the idea to keep 00-header in place might be nice [08:34] PR core#76: hooks: update the set-motd hook to provide better motd [08:34] koza: I would love to have this in 2.31 [08:39] mvo, mborzecki: snapd 2.30 is being pushed now: https://src.fedoraproject.org/rpms/snapd/c/47a18f3d2bbce275366342f621ce362d189cc1bc [08:41] Son_Goku: \o/ [08:41] hopefully it builds for all arches [08:41] Son_Goku: that's great, thank you [08:41] PR snapd#4511 closed: tests: new spread test for ssh-keys interface [08:41] this has been the easiest rebase in a while [08:41] no unexpected dependency breaks, patches were easy to refresh... [08:42] Son_Goku: nice, thank you for doing that :) [08:42] Son_Goku: great to hear. we tried to keep the spec file up-to-date for 2.31 as well to make your life easier. lets see if that worked :) [08:43] mvo: here's to hoping [08:43] zyga-ubuntu: is your "cool" comment in 4473 a +1 :) ? [08:43] if the build passes in rawhide for all arches, I'll merge it back into Fedora 26 and 27, and then make a PR to sync snapd master to Dist-Git again [08:43] cool [08:43] Yes :) [08:43] LGTM [08:44] I didn't hit approve, [08:44] but I meant to [08:44] and yay rich dependencies :D [08:45] zyga-ubuntu: \o/ [08:45] zyga-ubuntu: thank you [08:45] I will look into the other strace one [08:45] PR snapd#4473 closed: snap: add `snap run --strace` to be able to strace snap apps [08:47] thank *you* mvo :) [08:49] zyga-ubuntu: looks like people are starting to build their own HLLs using SELinux CIL: https://github.com/garyttierney/rust-csp [08:50] yeah, I think I saw a similar one a few months back [08:51] * zyga-ubuntu -> breakfast [08:55] mvo: https://koji.fedoraproject.org/koji/buildinfo?buildID=1020618 :D [08:57] that was fast [08:58] Son_Goku: yay [08:58] PR snapd#4539 closed: tests/main/kernel-snap-refresh-on-core: do not fail if edge and stable kernels are the same version [08:59] zyga-ubuntu: i'll do followup on 4539 (testing it right now but the spread nodes keep being stolen from under a running job) [09:00] mborzecki: did you update your spread? [09:00] mborzecki: each *up to date* spread system allocates fresh nodes [09:00] it's actually quite funny, it goes to prepare, then `2018-01-25 09:52:30 Error running debug shell: EOF`, and `cannot deallocate Linode machine linode:ubuntu-core-16-64 (Spread-5470034): object not found` [09:00] mborzecki: the behaviour you are describing was the bug that gustavo fixed last night [09:01] zyga-ubuntu: yes i did [09:01] oh :D [09:01] need to make sure ti'm using the latest binary though :/ [09:01] zyga-ubuntu: fwiw, spread-cron and the update for snapd-vendor has the saem issue [09:01] mborzecki: ohi [09:02] mborzecki: there's a bunch of info (some of which is in the snap.yaml today) that we've decided a couple of sprints back that we should query the store for it, and cache it locally [09:03] mborzecki: title, description, icon, screenshots are on that list; presumably license as well [09:03] hmmm [09:03] Chipaca: IMO the license shouldn't [09:03] no, license needs to be local to the snap - the license of the thing you have installed can't change i guess? [09:03] except that typos happen [09:03] hmm [09:04] Chipaca: license is validated [09:04] no typos would go through [09:04] BSD-2 vs BSD-3 could be a typo, but I guess it's fine [09:04] yes [09:04] so could MPL vs GPL vs ZPL vs YPL vs WTFYWPL [09:04] wait maybe not the last one [09:06] mborzecki: all that metadata should be served locally, and get updated when the store provides it for other reasons [09:07] mborzecki: this is driven by a real need from GUI stores to have a single, fast, local roundtrip for installed snaps including visual elements [09:07] mborzecki: whisper some of those words close to ikey if you want to know more (than you wanted to) [09:08] zyga-ubuntu, mvo: what are we doing CI with now? [09:08] for Fedora releases [09:09] Son_Goku: we're running spread for all builds [09:09] Son_Goku: but we don't enable all tests I think, a good subset though [09:09] I didn't look at details in a while [09:09] Son_Goku: Fedora-27 [09:09] Son_Goku: https://github.com/snapcore/snapd/blob/master/spread.yaml#L82 [09:11] Chipaca: i may be missing somthing then, when you do a cli.Info() it ends up in SnapState.CurrentInfo that in turn pulls in the side info from state and the rest comes from snap yaml [09:11] Chipaca: isn't ubuntu 17.04 EOL? [09:11] Son_Goku: yes, it is [09:11] good catch! [09:11] Son_Goku: how would i know :-p [09:12] mborzecki: yes, that sounds accurate [09:13] zyga-ubuntu: so you can drop ubuntu 17.04 and add fedora-26 :) [09:14] Chipaca: oh ok, i thought that when you wrote `all that metadata should be served locally` you meant that it's like this now [09:14] on my way [09:14] PR core#75 closed: ensure that all live-build/hooks run with `set -e` [09:15] 4540 [09:15] Son_Goku: I'll add fedora next [09:15] though I'd rather add arch [09:15] as arch is not tested yet [09:15] PR snapd#4540 opened: spread: Ubuntu 17.04 is EOL, remove it [09:17] PR core#76 closed: hooks: update the set-motd hook to provide better motd [09:18] mborzecki: i meant currently a GUI needs to hit /v2/snaps, and then hit /v2/find to query the store for the same snap to get it (notable screenshots) [09:19] Chipaca: right, that's much like snap info does it now too [09:19] mborzecki: and even the data we do serve can be staler than we want, because of where we get it from (mostly because we've dithered between "snap.yaml is the source of truth" and "store is the source of truth" a bit) [09:21] mborzecki: i'm not sure i'm answering the questions you had though [09:21] zyga-ubuntu, mborzecki: https://bodhi.fedoraproject.org/updates/FEDORA-2018-798e0f02ff & https://bodhi.fedoraproject.org/updates/FEDORA-2018-04bdce8944 [09:21] Chipaca: not exactly but you've confirmed what i see in the code :P at least i know i haven't missed anything [09:22] mborzecki: what were your questions tho [09:22] Son_Goku: ack, let me boot fedora [09:24] Son_Goku: testing [09:25] I should script spread external run against a fedora system [09:25] Chipaca: i'm looking into storing license information locally, since it primarly comes from the store the current idea is to keep it in SideInfo in a separate field, eg. StoreLicense so that it wouldn't clash with snap.Info.License, then while doing `snap info` show one or the other (there may be license in meta/snap.yaml but i haven't seen a snap with it yet), does that sound right to you? [09:25] mborzecki: why will it "primarily come from the store"? [09:26] mborzecki: it's in the snap.yaml [09:26] I'm assuming you mean the license field, not the license text [09:27] Chipaca: license field [09:27] mborzecki: as I mentioned above, license is one where the store does _not_ win, AFAIK; the license of the thing you have installed is that license [09:27] mborzecki: publishers can't change the license of things they have distributed post-hoc [09:27] they can distribute a new thing with a new license [09:28] otherwise we need a way to let users accept the license change, which is a nightmare [09:31] mborzecki: if the store is doing that it needs to stop doing that :-) says me [09:31] mvo, on the pr now [09:31] mvo, will ping u [09:31] Chipaca: what i mean is that in the snaps i have installed right now, the license field in meta/snap.yaml is not set [09:32] koza: thanks! just do a followup, this is already a nice improvement [09:32] mborzecki: yes, that is true. That will stop being true soon, as I understand things. [09:33] Chipaca: right, so for now i can record the license in side info when installing the snap, then should meta/snap.yaml come with a license field set it will take priority over what's kept in the state [09:33] mborzecki: I don't understand [09:33] mborzecki: it doesn't make sense to have it in side info [09:34] mborzecki: if the snap.yaml doesn't have a license, the license of the snap is unknown [09:34] mborzecki: there is no side info [09:34] PR snapd#4541 opened: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix [09:35] Chipaca: can you take a look at #4531? [09:35] mborzecki: what am I missing? [09:35] PR #4531: cmd/snap: display snap license information [09:35] mvo: https://github.com/snapcore/snapd/pull/4541 [09:35] PR #4541: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix [09:36] mborzecki: I can repeat what I'm saying here, there [09:37] Son_Goku: \o/ [09:38] Chipaca: and the effects are like this https://paste.ubuntu.com/26457230/ [09:39] zyga-ubuntu, mborzecki: you'll need to get snapd packages for testing from Koji for now: https://koji.fedoraproject.org/koji/packageinfo?packageID=23242 [09:40] Son_Goku: yep, doing that [09:41] mborzecki: tell me if that makes sense to you [09:42] mborzecki: and sorry if this is too much of a politics / business / lawyers thing for your taste :-) [09:42] zyga-ubuntu: the RHEL 7.5 beta just went live yesterday, apparently: https://www.redhat.com/en/blog/red-hat-enterprise-linux-75-beta-now-available [09:42] they rebased to GNOME 3.26 [09:43] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.5_release_notes/new_features_desktop [09:44] Son_Goku: can I update my existing installation? [09:44] Chipaca: i'm ok with not showing the field, it just looks a bit weird when it's shown once and disappears once you install :/ [09:44] zyga-ubuntu: CentOS doesn't have a RHEL 7.5 based build yet [09:44] unless you're paying for RHEL in some way, nope :/ [09:45] I've grabbed the source packages for RHEL 7.5 Beta, so I'm going to check and see if GNOME Software was rebased [09:45] I think it was, but there's only one way to find out [09:45] Son_Goku: ok, thanks for letting me know [09:45] mvo, https://github.com/snapcore/core/pull/77 [09:45] PR core#77: Feature/fix motd 2 [09:45] koza: ta! [09:46] PR core#77 opened: Feature/fix motd 2 [09:46] zyga-ubuntu: huh, looks like gnome software stayed at v3.22 [09:46] mborzecki: my problem is that things will get very hard to keep straight if we drop it into sideinfo to address the current issue [09:47] mborzecki: once it's in sideinfo it doesn't go away [09:47] mborzecki: I agree with Chipaca here [09:47] landing a simple patch will put pressure to fix the snaps in the store [09:47] (with new revisions) [09:47] snapcraft should enforce some kind of license too (that's discussed separately with the new custom license text option) [09:48] the store letting publishers change the license on the fly needs fixing too [09:48] i'll file a bug [09:48] Chipaca: gustavo raised this on the forum but a bug is a great idea [09:48] zyga-ubuntu, thats a no on the ptrace thing [09:48] zyga-ubuntu: ooh, do you have a link? [09:48] games crash and die [09:48] ikey: is it because [09:48] aha [09:48] ikey: on apparmor denial or on seccomp? [09:48] Chipaca: sure, one moment [09:49] cant remember man it was almost a month ago [09:49] pretty confident it was seccomp [09:49] good [09:49] we have a fix for that [09:49] sure? [09:49] because my experience thus far is apparmor is weak. [09:49] Chipaca: I think here https://forum.snapcraft.io/t/snap-license-metadata/856/14 [09:49] and lacks basic security features [09:50] ikey: there's ongoing work to make seccomp non-fatal [09:50] ikey: and then all seccomp, on compatible kernels, can set errno instead of killing the process [09:50] ok but none of this is upstream much less in my kernels :) [09:50] ikey: what does it lack that you miss the most? [09:50] ikey: actually the seccomp is in the kernel now [09:50] fine grained controls [09:50] such as ppid/group specifiers [09:50] ikey: it's also in libseccomp now, it's just very new [09:51] zyga-ubuntu: so I tried the /snap mount unit again and I did a systemd-analyize plot and it runs fairly early. however I still get duplicated mount entries [09:51] there are a number of comments in the PR about apparmor limitations [09:51] ikey: those are variables, this is true and people are working on it but it's not straightforward [09:51] mvo: can you pastebin what you have? [09:51] mvo: the mount table [09:51] alright but im just saying it seems like apparmor isnt finished [09:51] and potentially presents more of a security risk than the issues it purports to resolve [09:51] ikey: it's growing so things that grow are never finished [09:51] by nature of wide matching [09:52] you have to use a shotgun when you only need a pinprick [09:52] well, it's that or a wide open door [09:52] apart from variables I think it's pretty okay [09:52] zyga-ubuntu: https://paste.ubuntu.com/26457288/ [09:52] I'd wish some niche things would be there but I don't think it's that bad [09:53] PR snapd#4542 opened: tests/main/kernel-snap-refresh-on-core: skip the whole test edge and stable are the same version [09:53] mvo: that's very curious [09:53] tbh i think with the permissions that steam titles need, sandboxing is going to be a dishonest term for it, so ill probably need to document a wiki somewhere [09:53] mvo: note what happened [09:53] mvo: they are *both* shared [09:53] that's better than before [09:53] mvo: do you have the analysis somewhere? [09:53] mvo: did the bind mount happen before the snap mount? [09:54] PR snapd#4535 closed: interfaces: miscellaneous policy updates [09:54] PR snapd#4537 closed: interfaces/builtin: Replace Solus support with GLVND support [09:54] ikey: sure, it's a start though, things like ptrace are biggest issues as those are a way out of confinement for bad actors [09:54] right - and the issue is i cant not have ptrace turned on [09:54] and LSMs have no way to control ptrace properly [09:55] pretty much all the AAA titles these days start a process cluster with a monitor, a shm + socket share, and ptrace the child [09:55] that's true [09:55] that's new to me, I didn't know it is this widespread [09:55] its frustrating but i can /kinda/ see why they do it [09:56] I'll talk to the security team to see if there's something that can be done to neuter ptrace without disabling it [09:56] believe it or not a lot of them are actually using cef UIs too [09:56] why do they do it? for crash reports only? [09:56] cef? [09:56] i dont know i dont have the source code :P [09:56] cef, chrome/electron style apps [09:56] ah [09:57] its also possible ptrace is used in some games for active monitoring of memory to prevent cheating [09:58] phew, three different fora tied together makes connecting the dots hard [09:58] wait does this one count as four [09:58] dammit [09:59] * Chipaca takes a break before he feels too much like a manager againi [09:59] fwiw shouldnt the default ptrace scope prevent blind escapes anyway zyga-ubuntu ? [10:00] ikey: ptrace lets you manipulate enough to prevent LSMs from working from what I know [10:00] sure but i mean ubuntu kernels are defaulting to a strict ptrace scope - regardless of the lsm [10:00] ikey: I'm afraid I don't know the answer you seek [10:00] and you can only inspect your child or parent in the group as long as the MAC is satisfied [10:00] before it goes up to the lsm [10:01] (CAP_SYS_PTRACE blowing the MAC and tree out of the water ofc though) [10:02] anyway, now you can see why i said about limiting the interface to one snap :P [10:02] yes [10:03] PR snapd#4527 closed: Fix comment about running gofmt on contributions [10:06] PR core#77 closed: Feature/fix motd 2 [10:14] zyga-ubuntu, i think ill let the security guys get frightened by it and add some comments before i do any updates to it [10:15] on account of all the hole-pokerin [10:18] ikey: sounds like a plan :) [10:20] with any luck ill be able to get a stable snap before q2 [10:20] \o/ [10:20] popey, for clarification that wasn't optimism :p [10:20] sorry [10:20] Son_Goku: trying your fresh packages now [10:20] We live in hope ;) [10:21] its just been a really, really, really, really long, tiring road. [10:21] and regrets are forming [10:21] i cant be a ray of sunshine about this anymore :p [10:23] PR snapd#4543 opened: tests: set test kernel-snap-refresh-on-core to manual [10:26] Son_Goku: where can I comment on the new build? [10:26] zyga-ubuntu: bodhi updates [10:27] Son_Goku: did you send it as an update already? I only see the koji page [10:28] [04:21:32 AM] zyga-ubuntu, mborzecki: https://bodhi.fedoraproject.org/updates/FEDORA-2018-798e0f02ff & https://bodhi.fedoraproject.org/updates/FEDORA-2018-04bdce8944 [10:28] zyga-ubuntu: do you have fedora with graphics display installation? could you try installing slack? [10:28] ah [10:28] thanks! [10:28] sure, I just play with spotify now [10:28] I'll do slack next [10:28] thank you Neal! [10:28] best snap = spotify. :p [10:28] indeed [10:29] offtopic, how does gnome-software do reviews [10:30] the flatpak spotify from flathub has reviews [10:30] snap doesn't show any [10:30] the snap store doesn't support reviews (currently?) [10:30] there's no way to tie the reviews to the snap right now [10:30] they're bound by the key of the AppStream ID [10:30] I see [10:31] I heard that was released recently (appid support) [10:31] gnome-software reviews are not source-specific [10:31] ahh [10:31] cool [10:31] that's great [10:31] uses ODRS i believe [10:31] Yep [10:31] except on Ubuntu [10:31] mborzecki, Chipaca ^ would be cool to surface that through the API [10:31] where it uses the Ubuntu One system instead [10:31] ah k [10:32] (hence the Ubuntu One login requirement for reviews there) [10:32] oh right 0-9 regex, need to remember that thing.. [10:34] mborzecki: slack works [10:34] yay [10:35] heh, now i have to "validate" my PR changes [10:35] *launches games* [10:35] yeah so zyga-ubuntu your suggested changes make valve unhappy [10:35] it breaks [10:36] the [0-9]+ thing doesnt work [10:36] can you paste the diff please [10:36] -+owner /{dev,run}/shm/u*-Shm_* mrw, [10:36] ++owner /{dev,run}/shm/u[0-9]+-Shm_* mrw, [10:36] do i need to scape somethin? [10:36] *escape [10:37] cuz that +- looks janky to my eyes [10:37] wow, so what's there? [10:37] yeah [10:37] something looks fishy [10:37] * is a .* or just *? [10:37] uuuuuuuuuu or uomgthisisavalidausername [10:37] sample path looks like /dev/shm/u1000-Shm_cf1307a0 [10:40] * zyga-ubuntu has an empty mind [10:40] ya i dont know if this is meant to be fnmatch style or what [10:41] mvo, FYI, multi volume support works fine here with latest edge \o/ [10:41] ogra_: yay, great to hear, thank you [10:42] no, thank *you* :) [10:42] * mvo blushes [10:46] PR snapcraft#1883 closed: Revert "meta: create XDG_RUNTIME_DIR in wrappers. (#1818)" [10:47] yeah idk what to do with those [0-9]+ changes, introducing them breaks everything, and without them, works wonderful [10:47] * ikey turns blind eye to existence of regex [10:59] zyga-ubuntu: where does the + come from? [11:00] Chipaca: in which sense? [11:00] it was my adevice [11:00] but it didn't work [11:00] linux hates me [11:00] zyga-ubuntu: I don't see other rules that use a + [11:00] but we good with that [11:00] yeah, I was just drunk [11:00] I slept 3 hours today [11:00] lol [11:00] zyga-ubuntu: [0-9][0-9]* might work [11:01] without groking this (so people who actually know can call me out), reading apparmor.d I see ?*[]{}^ are the special sauce, and everything else is non-special [11:02] notably there's no + in that [11:02] ... [11:02] weird [11:02] that's apparmor.d(5) [11:02] * ikey looks at man page for sortafnmatchishkinda(3) [11:02] * Chipaca hugs ikey and points him at the bar [11:02] F27 works great, let's try the same in F26 [11:02] 11am lol [11:03] * Son_Goku is rebasing snapd and snapd-glib for el7 [11:03] ikey: _salad_ bar, obvs [11:03] ikey: itsregexpbutnotasyouknowitcaptin [11:03] LOL [11:03] Chipaca, oooh right [11:03] fermented salad, must be good [11:03] Son_Goku: why did I read that as e17 [11:03] poor rabbits walking away from the salad bar sideways [11:03] that... would be horrifying [11:03] depends [11:03] I don't know if I can deal with Enlightenment as hangry as I am now [11:03] if you mean the desktop [11:03] or the boyband [11:03] ikey: either or [11:04] Son_Goku: maybe you were *really* fed up with gnome [11:04] s/gnome/life/ [11:04] ikey might be closer to the truth... [11:04] apparmor.d> the point here is that it's a glob, not a regex [11:04] Son_Goku, take this! https://www.youtube.com/watch?v=-wNhdjoF-6M - its not safe to go alone [11:04] (insert meme, not sure if few up with gnome or ...) [11:04] cjwatson: but [0-9]* means 'lots of digits'? [11:05] no, it means [0-9] followed by anything [11:05] lol [11:05] ~_~ [11:05] like a shell wildcard expansion [11:05] a'ight [11:05] we could use {} and [0-9] to handle uids from 0 to 65555 [11:05] >_> [11:05] (well, anything except /) [11:05] * ikey eye twitches thinking about it [11:07] * Son_Goku shuts down from brain damage caused by contemplating it [11:07] also... this video [11:07] wtf [11:07] XD [11:07] e17.. lol [11:09] man [11:09] I remember that login animantion still [11:09] like duke 3d [11:09] glorious pixels [11:09] fiddled with the oomph of cpu alone [11:09] like ill happily rip kde, but e17.. damn [11:10] the desktop that time tried to forget [11:10] zyga-ubuntu: `NAUGHTY PROGRAMMER!!! SPANK SPANK SPANK!!!`? [11:10] mvo: +1 to morge 4540 [11:11] for a second i thought y'all had a secret club [11:11] then i remembered running any efl app ever [11:11] I'm still stunned [11:11] with a hash map that might not actually be the right hash [11:11] (not kidding.) [11:11] Son_Goku: your patches are merged [11:12] whole efl was an unforgettable experience, i remember how that was the first thing that greeted you when you tried intel-ivi [11:12] zyga-ubuntu: yay [11:12] PR snapd#4525 closed: tests: new spread test for interface gpg-keys [11:12] PR snapd#4541 closed: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix [11:12] Son_Goku: F26 testing now [11:12] Son_Goku: I'll do opensuse updates next [11:12] and then escape the house [11:12] ive tried describing the UI a couple times [11:13] ikey: not the right hash? [11:13] closest i ever got was "the unwanted child of melted lip gloss and hollywood remakes" [11:13] ikey: as a programmer I alwas admired EFL for trying to come up with a set of rich C APIs for apps [11:13] yeah they're APIs are kinda janky [11:13] *their [11:13] ow my engerlish [11:13] oajsda [11:14] I never tried them [11:14] meep [11:14] just the general style is meh [11:14] I know samsung invested some time and cash into it [11:14] like namespace_type_{get,set} [11:14] they still do [11:14] omg, reall? [11:14] serious [11:14] what for? [11:14] tizen [11:14] all their TVs, watches, etc. [11:15] and that one fridge [11:15] everything except the phones and tablets [11:15] I thought tizen was a rewrite after EFL-based code went south [11:15] man, insane [11:15] right, the creepy fridge too [11:15] i can probably ask around today :P [11:15] nah the modern tizen is the rewrite using efl [11:15] tizen 2.x [11:15] i.e tizen minus intel [11:15] yep [11:15] the tizen 1.x was the Qt5 based one [11:15] it it pure efl under the tizen layer? [11:15] yep [11:15] ish [11:15] or sed/esomething_/sammy_/ [11:15] well, there's the webkit/chrome thing [11:15] they have crosswalk and whatnot [11:15] was it crosswalk? [11:16] the web yokey [11:16] I think so? [11:16] it's built on top of chromium now [11:16] i was involved in tizen a whiles back [11:16] we used gerrit. [11:16] they use ML + patchwork now [11:16] * zyga-ubuntu too, though briefly [11:16] i had the distinct joy at one point of becoming the perl stack maintainer [11:16] terrifying. [11:16] the chromium has a *massive* patch set to swap ffmpeg for gstreamer [11:16] thats stoopid [11:17] gstreamer-libav.. [11:17] well, they don't ship gst-libav [11:17] thats stoopid [11:17] they want to use the hw-accel codecs on the boards [11:17] which only gst can support [11:17] * ikey was involved in a little known swift killed effort called "tizen pc" :p [11:17] I really wish the MeeGo thing had been more successful [11:17] meetoo ;) [11:17] * zyga-ubuntu reboots F26 [11:18] so the original moblin/meego guys also worked on the tizen pc effort [11:18] the old openhand->intel crowd [11:18] and I will forever curse that Microsoft guy who killed it on Nokia [11:18] i.e. creators of "modern gnome" [11:18] * ikey worked with those dudes [11:19] then i got lucky and got to work on non desktop stuff, and for a while, was content :P [11:19] then Solus happened [11:19] thrice [11:19] was it thrice? [11:19] I can never really remember anymore [11:19] ah right evolve os [11:19] yeah [11:19] technically that one was a rename not a relaunch [11:19] I thought I got it right this time [11:19] lol [11:19] i cant even keep up [11:20] you *created* the bugger! [11:20] lol [11:20] if you can't, what hope do the rest of us have? [11:20] hey im just tryna escape :p [11:22] i think that escape game beats the ops one [11:23] Son_Goku: polkit works nicely [11:23] :D [11:23] Son_Goku: though on F26 there's a loooooad of selinux advisory messages logged [11:23] * Son_Goku sighs [11:23] we really need to fix that one day [11:23] I know [11:23] but that requires time to sit down and go through all of it [11:23] sudo setenforce 0 [11:23] which I haven't had yet [11:23] *tada* [11:24] ikey: it's non-blocking as selinux policy for snaps is permissive [11:24] ill just grab my coat.. xD [11:24] Son_Goku: any amount will help [11:24] Son_Goku, ah just spammage, gotcha [11:24] yep [11:24] Son_Goku: could you try a forum topic with a simple loop on how to do that [11:24] maybe some people will help? [11:24] oh oh oh oh speaking of forum topics [11:24] ... [11:24] * ikey nails zyga-ubuntu's feet to the floor before he escapes [11:24] * zyga-ubuntu is still here [11:24] what we gonna do about this whole udev thingy? [11:24] you might want to clean up that liquored blood [11:25] so that steam / ps4 controllers / etc work with the snap [11:25] on account of they dont [11:25] i mean technically the udev rules are jank in that they 0666 the controllers [11:25] and it should probably be a uaccess thing [11:26] what is uaccess? [11:26] * Son_Goku watches the liquored blood pool from zyga-ubuntu's feet to ikey [11:26] Son_Goku: F26 looks good [11:26] udev/systemd stuff which tags the device with ACLs [11:26] basically its acl/attr based [11:26] ikey: ah [11:26] you want that for a specific user [11:27] sure and i dont know how thats going to tie into the whole snapd world [11:27] and not wide open? [11:27] it's on the roadmap for a long time [11:27] jdstrand described it on the forum very very early on [11:27] it's just not a thing that's scheduled yet [11:27] ya i started a thread a few months back on it [11:27] since pstolowski is looking into hotplug it will come aroudn [11:27] but failed to construct a conversation [11:27] sorry, I know that sucks [11:28] im trying not to give up :P [11:28] but honestly this steam crap has taken up an insane amount of my time so far [11:28] this hack and slash game has an excess of mobs to kill and just a few adventurers :) [11:28] and snapd still isnt ready for it [11:28] i just wonder if its time to throw in the towel [11:28] and cancel the lsi snaps [11:29] ikey: are they unusable or just not great? [11:29] zyga-ubuntu: they don't work [11:29] what the snaps or the controllers? [11:30] well, a number of games don't [11:30] the basic confinement rules in snapd breaks many games [11:30] ikey: could they just work now with devmode? [11:30] no [11:30] devmode is whats breaking it [11:30] ikey: I think it's fine to run in devmode while other things get into place [11:30] why not? [11:30] oh?! [11:30] zyga-ubuntu: because there are still basic filters in place with devmode [11:30] why do you think im sat on my arse screaming all the time? :P [11:30] you _still_ can't do certain things [11:30] snapd actively breaks my snaps [11:31] all feral games are broken with it [11:31] I know dbus doesn't get turned off [11:31] maybe we could turn of the device cgroup [11:31] it breaks mapping libraries [11:31] to make devmode really devmode [11:31] basically with my PR, the strict snap works better than the devmode one [11:31] like, way better [11:31] it also reduces host contamination [11:31] so i have the snaps working the same on all distros [11:31] ikey: don't throw the towel yet please, let's see what securty thinks of it [11:32] with devmode i have contamination [11:32] I think it's fine for this one snap [11:32] note that devmode doesn't mean classic [11:32] right [11:32] it'd be be namespaced [11:32] classic is a whole nother problem [11:32] its the basic profiles that bugger it [11:32] but if you say that this PR fixes the buggers for you [11:32] and i cannot use classic with my snaps [11:32] let's see what we need to do to land it [11:32] like it has to be isolated [11:32] and 2.31 rc2 is around the corner [11:32] got a whole solus inside it [11:32] I see [11:32] right! [11:33] * zyga-ubuntu screams at gnome boxes [11:33] honestly i have two major items left on my snap worklist [11:33] and alt-f4 closing the wrong window [11:33] first is actually getting full confinement [11:33] even at that point i can move off edge channel [11:33] the next major one being controller support [11:33] thats literally all there is in major items [11:33] can you think of some low hanging fruit to make controllers work for now? [11:33] even for that one snap [11:34] you can udev tag and do anything with it after all [11:34] probably some fudging of the joystick interface [11:34] or hidraw maybe [11:34] because we actually will want hidraw for ps4/steam controllers [11:35] but even getting to a point (even without controllers) where i can move the snaps off edge will help significantly [11:35] right now only a very small handful can actually test and use it [11:35] ikey: i can only beg you to come back to this at some point rather than abandoning it. We really need something like your snaps to push out the rough edges of the whole snap infrastructure. i can't think of anyone else as qualified to be able to push this through [11:36] mcphail, i get what you're saying but its the "come back to this" part thats the issue for me [11:36] i understand [11:36] i want/need to move solus off of package based steam runtime [11:36] as it has a limited shelf life for the core distro [11:36] needs to be lifecycled independently, right? [11:36] basically [11:37] we need to be able to hammer it and solus separately in some areas [11:37] because ABI compat [11:37] and ABI ugliness :/ [11:37] mvo: linode:ubuntu-16.04-32:tests/unit/go fails in strace test https://paste.ubuntu.com/26457861/ [11:38] if /me was sabdfl, i'd be on the phone getting a team together to push this through with urgency [11:39] mcphail, fwiw im not overly fussed with *how* long things take, just as long as im part of that timeline [11:39] anyway, ima hold out a bit longer on this because there are still interesting bits to solve [11:39] and my 2018 goal is to try and kick linux gaming up the bum [11:40] and i didnt google the current year there. [11:40] (kinda did.) [11:40] ikey: what i'd say is, unlike yhe similar experiences with click packages on the phone, it does seem that snaps continue to move in the right direction. albeit it is a chore to keep everyone focused on the same goals [11:41] PR snapd#4543 closed: tests: set test kernel-snap-refresh-on-core to manual [11:42] the improvements i've seen in the snap world over a few years has been greatly encoraging, and much more developer friendly [11:42] mcphail, plus i just decided to have the most awkward snap proposal, couldnt have been satisfied with just packaging gedit :p [11:42] i'm optimistic it is possible to get steam and lsi working properly :) (and soon) [11:44] we'll see which way does it go [11:44] ikey: and if it doesn't work out, i greatly appreciate your efforts [11:45] ah no worries [11:45] if push comes to shove ill bundle it up in an ironic self extracting .exe [11:45] frankensteim.exe.sh [11:45] i wish for this name to be a thing [11:46] The Windows Steam Linux Steam Subruntime System Subsystem ™ [11:46] for OS2/Warp [11:46] lol [11:46] it will play Rebel Assault [11:46] PR snapd#4540 closed: spread: Ubuntu 17.04 is EOL, remove it [11:46] and support 9dot printers [11:47] o/t: i was at an amiga event the other day [11:47] * ikey wants to upgrade to a downgrade [11:47] pstolowski: conflict on 4401 [11:47] PR snapd#4542 closed: tests/main/kernel-snap-refresh-on-core: skip the whole test edge and stable are the same version [11:48] zyga-ubuntu, thanks, looking [11:48] 4459 needs a 2nd review [11:48] * zyga-ubuntu is now starting to crash [11:48] sleeeeeep [11:48] sleep $debt [11:49] sleeping for the bank ? [11:49] mborzecki: meh, thank you, looking [11:49] count sheep vaulting over the .. well.. the vault [11:50] I just imagined borderlands vault and sheep getting slaughtered [11:50] lol [11:50] with green blood and rocket lauchers [11:52] zyga-ubuntu: can I conk out and die now? https://forum.snapcraft.io/t/install-snapd-on-centos/1495/21?u=conan_kudo [11:52] zyga-ubuntu, mvo could someone put a yes or no in https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675 (it is bocking a decision for a customer snap) [11:53] Son_Goku: please don't die [11:53] * zyga-ubuntu looks [11:53] thx [11:53] Nice, I will give that a try! [11:53] ogra_: ack, enqueued [11:53] thx [11:53] :) [11:53] PR snapd#4356 closed: many: add new `snap refresh --amend ` command [11:54] ogra_: on real paper queue [11:54] haha, you're so last century [11:54] no, I refreshed to --stable [11:54] ;) [11:54] lol [11:55] zyga-ubuntu: yay, thanks for merging this [11:55] ogra_: my gut feeling is that this is a gustavo question but let me check [11:56] mvo: we're at 36 PRs [11:56] mvo: much nicer than 45 yesterday [11:56] zyga-ubuntu: \o/ [11:56] uygindeed [11:56] mvo: we could go to 29 it would be an awesome day [11:56] mvo, well, mine is that it is a samulele one, but he seems to be vacating [11:56] mvo: I think some should be closed [11:56] ogra_: heh [11:56] zyga-ubuntu: 4517 for example - did you had a chance to look at my mountinfo? [11:57] mvo: the one with two entries? [11:57] mvo: yes, did you see my follow up question? [11:57] mvo: I asked about the order of events in systemd, if you had that from boot analysis [11:57] * zyga-ubuntu updates centos 7 [11:57] good luck :3 [11:58] mvo: 4351 looks like an easy win if you can look [11:58] mborzecki: what's the state of 4285? [11:58] zyga-ubuntu: I missed the question, I can uplaod my svg [11:58] mvo: can we just merge 4049? [11:58] mvo: thanks! [11:59] btw can report im using snapd + glvnd here quite nicely [11:59] ikey: awesome! [11:59] thought it'd be more problematic but seems to be fine now [11:59] just had that one rule change in apparmor to do and then it slotted into place [11:59] zyga-ubuntu: haven't updated 4285 yet [11:59] mborzecki: shall we close it until you do or do you want to let it linger there? [11:59] PR snapd#4351 closed: tests: new test to validate location control interface [11:59] * zyga-ubuntu puts some peer pressure to cut those PRs [12:00] (howerver I come out over IRC my intentions are good:) [12:00] text makes it hard to express *how* you mean something.. [12:01] Heya [12:01] zyga-ubuntu: [12:01] "2018-01-24 23:02:31 Cannot allocate linode:debian-9-64: server linode:debian-9-64 (Spread-5460254) concurrently allocated, giving up on it" [12:01] zyga-ubuntu: Shouldn't fail based on that [12:01] hey hey [12:02] niemeyer: AFAIR that one failed totally but it was ok on next go [12:02] when they said CI, you didnt think it'd be the framework you'd be integrating :p [12:02] niemeyer: no issues today [12:02] zyga-ubuntu: It will allocate something else, and even if that fails too, there are other systems that can pick up its work [12:02] niemeyer: and things are l-l-landing :) [12:02] zyga-ubuntu: But for a different reason, I assume [12:02] niemeyer: yeah, I think it was still one of those pre-fix PRs [12:02] ikey: Yeah :) [12:03] so hypotheticals: [12:04] niemeyer: just heads up if I don't show up today; I was up till 3AM for some reason and woke up at 7 today [12:04] lets say post new interface merge and such, ill need to request autoconnect for the new interface [12:04] this is something that the store decides or..? [12:04] and I feel like floor is warm and soft now [12:04] i was tryna wrap my head around it [12:04] ikey: yes [12:04] zyga-ubuntu: hm i have a wip branch for 4285 that i forgot to push ;) i'll merge current master, resolve coflicts and push it and we'll see how for it will go this time [12:04] aha, ty [12:04] ikey: it's in the snap declaration assertion [12:04] mborzecki: awesome, thank you [12:04] see i was stuck on this for a long time, figuring out how do i make stuff autoconnect.. [12:05] ikey: essentially you can get more things if the store says it's okay [12:05] right [12:05] ikey: ask on the forum and it gets voted and granted [12:05] and for the steam-support one, we'd want it to be sanctioned by store only [12:05] not by the snap itself [12:05] cuz its poking an awful lot of holes [12:05] yeah [12:05] snap can say it wants anything [12:05] but snapd has a built-in policy [12:05] right [12:05] and store has a persnap override [12:06] yeah i dont want someone getting the wrong idea and start using steam-support in their snaps [12:06] no worries, it's safe [12:06] as it is technically an extension of browser-support [12:06] without sandbox keys [12:06] zyga-ubuntu: the ordering http://people.canonical.com/~mvo/tmp/snap-boot.svg [12:06] thank you, looking [12:06] so i guess an interesting question becomes - does the steam snap really then need to know about ~ after this? [12:06] mborzecki: in what PR was this strace error? is that master failing? [12:07] i mean i assume its harmless enough as it cant access dotfiles [12:07] typically folks use steam with a ~ library or a removable-media library.. [12:08] ikey: probably no then [12:08] mvo: https://travis-ci.org/snapcore/snapd/builds/333196455 4531 [12:08] ya cuz if they have steam library already in ~ - we cant see it in snap [12:08] because it'd be ~/.local/share/Steam [12:09] yep [12:09] migration sucks [12:09] but then ~ is $HOME/snap/$SNAP_NAME/$SNAP_REVISION anyway [12:09] right but i mean if they move from "native" steam to lsi steam [12:09] maybe offer a migration script? [12:09] or a migration tool [12:10] that can run and can have :home [12:10] hm. [12:10] it would just cp/mv [12:10] yeah that could be an idea [12:10] it could even be the configure hook! [12:10] just give it :home [12:10] :) [12:10] (kind of neat, no?) [12:10] but if they're in the old ~/.local/share/Steam then they're out of luck [12:10] like host-side ~ [12:10] ah, yes [12:10] cuz confinement wont let us see that [12:10] well [12:10] it's just an interface away :) [12:10] it could be steam-migration iface [12:10] well i think maybe we'll cross that bridge when we get to it [12:11] and for now focus on immediate concerns, like, does it play the games it sees [12:12] mborzecki: thank you [12:14] mborzecki: I think I know what it is, sorry for that, a race, restart may help [12:17] * ikey fixes dumb typo in PR [12:18] Son_Goku: installing snapd on centos now :) [12:18] so far good though I wonder about that 3.10 kernel [12:19] *exciting* in some ways [12:19] 3.10? o-O [12:19] Son_Goku: failed on lack of squasfuse and policycoreutils-python-utils [12:20] zyga-ubuntu: you need epel-release installed [12:20] Son_Goku: cool, can you update your post please? [12:20] done [12:20] (I supect it will become the official install docs soon) [12:21] it'd better not [12:21] lol [12:21] I don't even know if anything works [12:21] policycoreutils-python-utils is probably a packaging bug [12:21] Son_Goku: better but policycoreutils-python-utils (what a package name) is still missing [12:21] as we all know, if the package manager says something is installed, then it means it works [12:21] though squashfuse is now OK [12:21] ikey: if it compiles send it to the mars rover [12:21] lol [12:21] the package was renamed sometime between Fedora 22 and Fedora 27 [12:22] I should just change that to a file dep... [12:22] great, I will try it when the new build is done [12:22] mvo: doing that svg analysis now [12:23] btw, any hints on how to reproduce that? [12:29] mvo: did you see my question about 4049? [12:29] mvo: is that something we can now land? [12:30] Son_Goku: the instructions should tell people to update, epel-release gives new gnome-software [12:30] epel-release gives you squashfuse [12:30] not new gnome-software [12:31] new gnome-software comes from copr repo [12:31] ah [12:31] sorry [12:31] it's from your repo [12:31] I misread, all is cool [12:31] zyga-ubuntu: pushed to #4285 [12:31] PR #4285: tests, spread: add Arch Linux to CI systems [12:33] niemeyer: hey, any news re: spread? [12:33] Saviq: Well, lots of them [12:34] Saviq: What are you looking for more specifically? [12:36] mvo: in your trace there are no snap mount entries, (there's just one for /snap), any idea why? [12:36] zyga-ubuntu: at least now all the selinux macros are defined in el7... [12:36] mvo: was that on an empty VM without any snaps? [12:36] that was a big problem before [12:38] I'm stopping for lunch with my parents who dropped by; I might be a little late to the standup (I'll try not to) [12:39] Chipaca: enjoy [12:39] zyga-ubuntu: as you wish [12:40] Saviq? [12:41] zyga-ubuntu: new build published [12:41] yes, I saw [12:41] updating [12:42] niemeyer: sorry, the Mir failures to allocate nodes? [12:42] Saviq: Where are the logs? [12:42] Son_Goku: installing :) [12:43] niemeyer: https://travis-ci.org/MirServer/mir [12:44] Son_Goku: oh, I like that prompt [12:44] zyga-ubuntu: eh? [12:44] "enable non-free software" [12:44] in g-s on startup [12:45] :) [12:45] installing core now [12:45] though no snaps in g-s [12:45] I'll reboot in case ... not sure [12:45] plugin dind't load somewhere [12:45] you may need to kill g-s daemon and reload it [12:45] right [12:45] g-s starts as a session daemon [12:46] so I _think_ logging out and logging back in should be enough [12:47] Son_Goku: g-s needs me to sign-in [12:47] yeah [12:47] that's always been the case [12:47] Son_Goku: I think that's either older code or maybe polkit [12:47] Son_Goku: no, it's not! [12:47] Son_Goku: try it on fedora [12:47] for g-s 3.22? [12:47] it's a polkit prompt now [12:47] I think it is [12:47] i wonder what real world people do when they see those prompts [12:47] ahh [12:47] maybe [12:47] "enable non-free software" [12:48] "is this discount shopping mode?" [12:48] xD [12:48] I thought that was a part of the plugin to g-s that you ship [12:48] ikey: LOL [12:48] I ship the plugin as is from gnome-3-22 branch: https://gitlab.gnome.org/GNOME/gnome-software/commits/gnome-3-22 [12:48] * ikey focuses on the important issues in life.. :p [12:48] OK [12:48] there's a lot more crap here: https://gitlab.gnome.org/GNOME/gnome-software/commits/wip/ubuntu-3-22 [12:48] Saviq: Looks like the same concurrency issue we're seeing in snapd in some cases.. I need to dig into it [12:49] but I don't really want to touch that [12:49] Son_Goku: I cannot log in, probably something missing in packaging or wrong paths [12:49] Saviq: It's safe to restart the build in those cases [12:49] Saviq: I'll let you know once it's supposed to not happen again [12:49] the paths are unchanged between Fedora and EL7, since it's the same packages [12:49] just tweaks for dependencies [12:49] Son_Goku: selinux prevents startup of snapd-login-service [12:50] Son_Goku: "setenforce 0" t-shirt [12:50] oh joy [12:50] more policy fixes [12:51] there are more denials on snap install [12:51] zyga-ubuntu: but this is why this is an experimental repository :) [12:51] I think the "advisory" part didn't work [12:51] sure :) [12:51] though snap install is still running [12:51] (downloading) [12:53] spotify works! [12:54] \i. [12:54] er [12:54] \o/* [12:54] [12:54] Son_Goku: com.canonical.SafeLauncher was not provided by any service files [12:54] eiter activation or selinux [12:55] oh no [12:55] I know what's wrong [12:55] I updated snapd-glib [12:55] and the plugin doesn't know about the new name [12:55] hmm that's from the core snap [12:55] and from the snapd package [12:55] so it shouldn't care [12:55] I ran 'xdg-open' in snap run --shell foo [12:58] hmm, nothing has changed in the code since 1.26 [12:58] Son_Goku: run "snap userd" [12:58] I'm providing 1.29, which should work [12:58] it cannot acquire bus name [12:58] it's selinux [12:59] hmmm [12:59] is the dbus service file path correct? [12:59] as in /usr/share/dbus-1/services/ [12:59] rpm -ql snapd-login-service [12:59] no not [12:59] that's separate [13:00] snap userd [13:00] (I think) [13:00] I'll investigate after standup [13:00] okay [13:00] I've got to get ready for work anyway [13:00] yay... full day of tiredness [13:00] Thank you! This is a big push forward [13:01] * Son_Goku yawns [13:01] 😪 [13:01] WOW [13:01] irssi does emoji in gnome terminal [13:01] crazy [13:02] hot damn [13:02] i have a tamigotchi in my hexchat [13:02] (looks like one anyway :P) [13:02] ^ Chipaca that's a whole new chapter for smily faces [13:03] if you're on gnome 3.24 or newer, you should have emoji support [13:03] oh crap i forgot to add colour emoji support to solus [13:03] knew i was missing something [13:03] or was it gnome 3.26 [13:03] meh [13:03] either one [13:03] .26 + git bits [13:03] right [13:03] okay then [13:03] ikey: you should add that... [13:03] it's kinda nice to have [13:03] yeah i created an "unbreak now" task for that [13:03] think that was november [13:04] still deciding precisely what "now" means [13:04] yeah, there's a bit of a mess to untangle and fun fontconfig directives [13:04] yer [13:04] and newer fontconfig trashed older emojis [13:04] so i reverted it [13:05] niemeyer: it's a 100% failure rate though, so restarting doesn't help [13:07] Saviq: Ok, in the standup, but will dig into this right afterwards [13:07] maybe we can limit the number of jobs, since we're starting multiple spreads concurrently [13:08] so is that glass half full or ... ? :p [13:09] right or left half is the question here i guess ... [13:10] lol [13:26] PR snapd#4544 opened: spread: remove more EOLed releases [13:27] mvo: ahem [13:27] so I need that nap now [13:27] zyga-ubuntu: hm? [13:27] you were certainly right [13:27] zyga-ubuntu: oh, sure, go for it [13:27] zyga-ubuntu: need some help lookin into selinux things? [13:27] I didn't stage it [13:28] zyga-ubuntu: I'm not sure right about what, but its fine, we can talk later :) [13:28] * pstolowski lunch [13:28] mborzecki: no, not now, I'm in a state of running on life supprot [13:28] I need sleep first [13:28] mvo: about EOL releases, see pr 4544 [13:28] ok, i'll try to take the packages for a spin here [13:28] PR #4544: spread: remove more EOLed releases [13:28] zyga-ubuntu: aha, ok [13:28] * zyga-ubuntu -> sleep [13:29] * kalikiana going to head out for lunch shortly [13:46] ikey: 'apparmor is weak' - can you give specifics? if you are talking about ptrace only, then apparmor is actually quite strong [13:46] mvo cachio noise][ we've been getting a bunch of these lately (from snapd) https://paste.ubuntu.com/26458462/ ... do you guys see the same? [13:47] no ptrace is the kernels fault [13:47] that part i know [13:47] i mean in terms of currently available selectors [13:47] ikey (cc zyga-ubuntu): the issue with ptrace (and capabilities for that matter) is that the kernel, separate from apparmor and the LSMs, lumps things together that shouldn't be [13:48] ya i know :) tis why i said its the kernels fault [13:48] kernel doesn't give the lsm enough to work with [13:48] seems the kernel is generally unfriendly to lsm design [13:48] sergiusens: that looks like a server side timeout to me [13:48] sergiusens, I didn't see this on our tests [13:48] ikey (cc zyga-ubuntu): and what the comments say in the policy is that on <4.8 kernels, ptrace could be used to break out of the seccomp sandbox. so, because apparmor is strong, we block it [13:48] sergiusens: the snapd log should contain a bunch of retries [13:49] sergiusens: we retry hard but eventually (have to) give up [13:49] mvo thanks, it is on travis though, so I cannot see much into it :-) [13:49] jdstrand, right [13:49] ikey: the kernel certainly can be, yes (note, I'm still reading the long backtrace, so sorry if repeating things) [13:49] yeah no worries, figured :D [13:50] ikey (c zyga-ubuntu): so, for >=4.8 kernels, we could actually allow ptrace oneself and anything matching your snap's label [13:50] right [13:51] ikey: snapd could interrogate the kernel version and allow that rule conditionally [13:51] i know in solus terms we expect minimum 4.9 kernel [13:51] (thats the oldest we ship) [13:51] but other distros etc.. [13:52] ikey: the only problem is we would really want to also support <4.8 kernels that have that patch backported, and there is no way to interrogate that (it isn't exposed in sysfs, etc) [13:52] jdstrand: distro patch for backported kernels [13:52] but, we could probably do things like 'if dist is ... and kernel > ...) [13:52] hm yeah [13:52] fwiw solus has a funky uname so i dont know if that affects things [13:52] Son_Goku: that's what I'm saying. some will want that patch (it is great on its own, unrelated to snapd) [13:52] that's probably going to be necessary for CentOS 7 if I really decide I want that working... [13:53] i assume your detection can ignore extra_version info [13:53] and we'd want to detect they have it [13:53] robustnessness™ [13:53] NOOOPE [13:53] aw [13:53] could so be a word [13:56] btw jdstrand apologies for any trauma inflicted by my PR :P [13:56] I'm having this error when I'm staging a file in snapcraft.yaml does anyone can help me? The error is: `SystemError: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22ece2af1015668ccc056a3396acc37aba3295be593ad5cb979843e44423ff5c3d560113fc876976790a6/var/lib/apt/lists/partial/deb.nodesource.com_node%5f8.x_dists_artful_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permi [13:56] ssion denied), E:Method http has died unexpectedly!, E:Sub-process http received a segmentation fault.` [13:56] morning [13:56] ikey: beyond ptrace, one 'weakness' is leakyness in /proc since @{pid} doesn't apply to the snap. we try to document that wherever we know it is leaky so we can fix it. *but*, those leaks are minor. if there is something big, we put it behind a separate interface [13:56] hm ok [13:57] ikey: the other thing is lack of finegrained network mediation [13:57] yeah [13:57] most snaps don't need that, so we have 'network-control' [13:57] PR snapd#4488 closed: snap: make `snap find --section` show all sections [13:57] and then apply to something as large as steam and it gets nasty.. [13:57] but sure, it isn't 'done' [13:57] as they say, when is anything [13:58] but it is very flexible and allows us to stitch together policies and let snaps interact in very flexible ways [13:58] so we are working to finish it, after it is upstreamed [13:58] which forces you to batch work really [13:59] but this is also why we combine technologies [13:59] anyway [13:59] :D [13:59] ikey: so, you have a forum post and a PR. its been on my todo to look at both, but between holidays and sprinting, hasn't been done yet [14:00] sure [14:00] ikey: which would you like me to look at first? [14:00] (and sorry for not looking at it sooner) [14:00] well the PR is the manifestation of the topic [14:00] basically add new interface derived from browser-support [14:00] to make things not bork [14:00] and poke relevant holes [14:00] and those holes are apparently your domain to determine badness ™ [14:00] * ikey tm's all the things [14:01] the idea is we want the interface to not autoconnect, and get a vote on the forum to have the lsi snap autoconnect to steam-support [14:01] due to the nature of the hole popping [14:01] ok, I'll read the forum post for context then look at the pr. I'll try to get to it today, if not tomorrow [14:01] * jdstrand nods [14:01] you know [14:01] in future ill need autoconnects for hidraw/joystick/removable-media [14:02] and extend for ps4/steam controllers/etc [14:02] just the nature of the beast.. [14:02] we could in theory look at auto-connection depending on kernel version [14:03] so the problem is that under strict confinement, steam absolutely and utterly requires this interface [14:03] that would require a bit of work, but I'll take a look at the policy and ask questions, etc [14:03] or will spinlock-of-doom [14:03] it gets stuck in an infinite cycle trying to open the shm nodes [14:03] shm is annoying [14:03] yeah [14:03] also, even in devmode, a lot of stuff is broken by the base policies [14:03] there is something that apparmor could do there as well [14:04] but yeah, as you can imagine, getting all the denials and whatnot was a complete pain [14:04] lol [14:04] niemeyer: wall of text wrt licenses [14:04] but finally got to the point where i could even launch and play AAA titles from feral [14:04] sorry for it, i mean [14:04] so, yay [14:04] also why is my day all about licenses :-( [14:04] oftentimes (but not always) you can adjust the path, but that requires patching or LD_PRELOAD, which may or may not work for you (obviously patching wouldn't) [14:05] so LSI is kinda on a thin line of "is this ok" with the existing redirects it does to games [14:05] and the silent agreement with valve is we dont break *them* or do anything that could be misconstrued as cheating [14:05] so unbreaking libraries and behaviour is OK [14:06] but i imagine they'll frown on me redirecting shm [14:06] especially when you factor in VAC [14:06] that is unbreaking something :) [14:06] its not broken [14:06] but the shm is used for IPC in the libsteam API [14:06] it depends on how you look at it [14:06] and is used for the client + transactions [14:06] oh i know [14:06] but i dont wanna take the piss with valve, basically [14:06] * jdstrand nods [14:07] so we dont do any symbol redirection in valves space in LSI [14:07] we only do LD_PRELOAD fixes to definitely-broken-games [14:07] and it keeps everyone "Happy" [14:07] its also why most of LSI is hard-coded fixes, so that users cannot extend it to bypass systems [14:07] and thats sorta been the silent agreement [14:07] write it well and dont let it become a cheat system [14:08] * jdstrand nods [14:08] fwiw in future we'll be moving solus exclusively to the snaps for steam and its very likely we'll add self verification for the LSI modules [14:08] as part of that "we're not cheating" thing [14:08] why i had to pick gaming for my niche ill never know [14:09] haha [14:10] but all the drama aside i do look forward to dispelling the game devs raison d'etre for not supporting linux [14:10] ikey: starts with m, rhymes with schism [14:10] "too many distros" [14:10] Chipaca, oh i know this one! [14:10] macho man randy savage [14:10] Chipaca: np, responded [14:11] also since when do i causally use french [14:12] hello everybody [14:14] off to get the kids [14:16] niemeyer: the long thing i wrote might not have been as clear as I thought it was; can you give it a second read? What I tried to do was exactly point out what you open by saying you don't see [14:17] that is, it tries to explain _why_ the issues are harder [14:23] roadmr: fyi, lxi-tools got stuck on r576 and r577. I simply ran the automated reviews again and it seems to be clearing out the backlog [14:24] roadmr: iirc, r576 said something about 'task state unknown' [14:24] roadmr: I'm sorry: s/576/575/ [14:25] roadmr: I don't need anything at this point. fyi only [14:26] jdstrand: ok... yes, task state unknown happens when a revision gets queued while another is processing [14:26] because the task hasn't been started, its state is unknown [14:27] I'm having this error when I'm staging a file in snapcraft.yaml does anyone can help me? The error is: `SystemError: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22ece2af1015668ccc056a3396acc37aba3295be593ad5cb979843e44423ff5c3d560113fc876976790a6/var/lib/apt/lists/partial/deb.nodesource.com_node%5f8.x_dists_artful_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permi [14:27] ssion denied), E:Method http has died unexpectedly!, E:Sub-process http received a segmentation fault.` [14:27] jdstrand: the ones that are being processed say stuff like "Task 8f975758-3665-497f-840e-77e2178c9459 is waiting for execution. " [14:27] in this case we're just waiting for an available worker process [14:28] roadmr: ok, but by 'stuck' I mean that 18 hours ago it was uploaded and didn't progress, and 24 revisions were queued behind it [14:29] kyrofa: the autopkgtests can be triggered again from the bot. [14:29] jdstrand: oh!! [14:30] jdstrand: let me check the logs [14:31] roadmr: do look at 577 in addition to 575 though, it said something about /tmp/... couldn't be found (or similar) so it sounded like it got reaped early or something () [14:31] jdstrand: yes, I have seen that thing about temporary directories occasionally, think we still have that race condition sometimes :/ [14:32] jdstrand: and I think in that case the task does end up in an unfinished state, which is what blocks the queue [14:32] jdstrand: there's a place where I can check for stuck revisions, but I don't look at it regularly :/ [14:34] roadmr: so the theory is 575 and 577 were uploaded at about the same time, they raced and deadlocked? [14:34] jdstrand: it could be. The snap is big enough that one review might have been in progress when the other 2 (576 and 577) were uploaded [14:35] jdstrand: it's somewhat surprising though because the queue is sequential per snap [14:35] yeah [14:35] fwiw, it happens very rarely [14:35] jdstrand: so maybe the race was with another snap altogether, a revision for which was uploaded around the same time [14:35] tbh, I can't remember the last time I had to do this [14:35] (months?) [14:36] yes, it was maybe 3 months ago [14:42] roadmr: fyi, when going through the backlog it got stuck on 586: "Could not find '/tmp/review-tools-nxy1gblo' msg" [14:42] roadmr: I did not run it again in cause you want to investigate [14:43] roadmr: https://dashboard.snapcraft.io/snaps/lxi-tools/revisions/586/ [14:46] jdstrand: oh that's useful! let me see [14:47] roadmr: our cleanup code is to remove stale review directories tha are older than 3 hours. I'm not sure how the parallelism works, but the logic is very simple-- time.time() - os.path.getmtime(d) > maxage: # 3 hours [14:47] the logic in the review tools that is [14:47] jdstrand: so the only way that could happen is if two tools runs finish at almost the same time and try to reap the same dir, one of them would fail to find it and get that message [14:48] roadmr: but, why would the dir be older than 3 hours in that case? [14:49] jdstrand: I'm assuming the dir to be reaped was created by a prior run [14:49] so: at 00:00, a run creates directory A [14:49] at 03:01 two runs finish at the same time, both run their reaper code, and identify A to be removed [14:49] but only the first one does, the second one will get "could not find A" [14:50] right. that seems unlikely that ran A would take 3 hours longer to run than B [14:50] jdstrand: hm, but I'm assuming A ran quickly (maybe finished at 00:02) and left the directory there. Or do runs clean up after themselves too? [14:51] oh they do [14:51] roadmr: they are supposed to cleanup after themselves [14:51] mvo, not sure you have seen it ... core x86 builds fail: [14:51] + grep -q bin/grub-editenv [14:51] + rm -f /. [14:51] rm: cannot remove '/.': Is a directory [14:51] E: config/hooks/15-remove-grub-common.chroot failed (exit non-zero). You should check for errors. [14:51] roadmr: the reaper code is in case that didn't happen for some random reason [14:51] i guess the set -e shows now :) [14:52] jdstrand: indeed... hm [14:52] roadmr: so, maybe it is that a run failed weird and didn't get cleaned. than later 2 different runs finish at the same time and try to clean it [14:52] ogra_: aha, "great! [14:53] ogra_: eh, "great" - this is the new "set -e" everywhere [14:53] yeah [14:53] ogra_: I suspected this would cause some fallout [14:53] * mvo weeps a bit [14:53] jdstrand: yes, you expressed it more clearly, it's what I meant with my example [14:53] well, rm -f /. sounds weird anyway [14:54] jdstrand: oh mm.. [14:54] re [14:55] jdstrand: one thing that puzzled me is that your code seems to eat exceptions, so why is the message (which should be merely informative) cause the run to get stuck? [14:55] jdstrand: then I saw that the code does "except Exception" [14:55] jdstrand: but recursive_rm calls some methods which may raise OSError or IOError, which I remember from experience are sometimes not caught as Exceptions, need to be caught explicitly as IOError or OSError [14:57] roadmr: the idea is that we don't want to traceback if something goes wrong with recursive_rm, and just report it [14:58] jdstrand: exactly, but the store is reacting as if the tools had exited with a bad error code [15:00] roadmr: that is because we are gathering up any errors and shoving it into the json [15:00] jdstrand: haha wait - the reaper code never says "could not find". It says "could not remove"... so it's not a reaper race [15:01] roadmr: if you recall, there were issues before if the output was not json [15:01] jdstrand: indeed - in that case the store said "unexpected output", which it isn't doing here... hmm [15:01] roadmr: right-- I think we fixed almost all of those, but your remove vs find is key [15:02] that could be a lot of things [15:03] jdstrand: "/tmp/review-tools-nxy1gblo" should be a directory, right? if so, it must be in common.py detect_package, "error("Could not find '%s'" % unpack_dir)" [15:03] roadmr: I suspect it is detect_package() with the os.path.isdir() [15:03] \o/ [15:03] right [15:03] jdstrand and roadmr independently arrive at the same conclusion \o/ [15:07] there's some duplicate code in detect_package and init [15:09] that shouldn't matter here, but I should fix that [15:10] roadmr: you don't use bin/detect-package anywhere, do you? [15:11] jdstrand: nope! [15:11] I'll probably just remove that then. I don't think anyone uses it and I can cleanup a little [15:12] yay :) less code is always better [15:13] you will like when I rip out snapv1 and click code then :) [15:14] ohh yes [15:14] make sure to sloccount before and after [15:15] hehe [15:15] PR snapd#4545 opened: interfaces/x11: allow X11 slot implementations [15:18] niemeyer: 'Cannot allocate linode:arch-2017.07.01: no Linode image or distribution for "arch-2017.07.01"' the arch image is no longer available on linode? [15:38] roadmr: I don't see an error in the code. it is as if after the unpack the dir disappeared. is there a fs issue? does the fs use dangerous mount options (eg, the unpack finishes but not syncd to disk)? this seems unlikely. I'll be adding some extra debugging information for next time [15:40] I mean, I could be missing something, but the extra debug info will help with that [15:40] roadmr: at this point, I'm inclined to run the reviews again and get this cleared out [15:41] PR snapd#4546 opened: snap: tidy up top-level help output [15:41] jdstrand: yes, I'd say that makes sense, until we have more debugging info/code [15:42] jdstrand: I found nothiing in the logs, but that's because the tools ran fine, they just reported this message as an error in the json, that causes the store to think there was a problem which gets the queue stuck [15:43] roadmr: sure, that I understand. note that r575 didn't have an '!', it was the task state unknown. but I think we discussed that enough [15:44] yep... that one is weird :( I'll be really interested to see what the extra debugging code shows [15:45] jdstrand: oh wow so you unstuck 586 and 587 is now in the same boat [15:45] I reran automated review on that one [15:48] cprov, bug #1745410, thank you! [15:48] Bug #1745410: Please further document ACLs [15:53] diddledan: have you ever spoken to upstream irccloud about the desktop snap? Thinking we should upstream to get it out of snapcrafters and into their hands. [15:54] not yet. I'm reluctant while we're still suffering the chown to self problem because that's from a project upstream of them [15:54] Good point. [15:55] we're currently two releases behind because of that issue :-( [15:57] Maybe we can come up with creative solutions next week :) [16:09] ikey: hey, so can you at a high level describe the intended architecture for the snaps? for example, what is declaring 'steam-support'? a launcher? games shipped as snaps? [16:09] ah right ya [16:10] so solus-runtime-gaming = runtime thing, basically solus's NIH core, linux-steam-integration is the "app" part which *depends* on that dude, and the whole thing together requires the permissions set in steam-support [16:10] jdstrand: I addressed the point in 4073 and will do a followup with support for kdialog and xfce-dialog etc [16:10] like there is no _provider_ as such, its "can haz permissions pls" [16:10] can I get some permissions, too, if we're handing them about freely? ;-p [16:11] preferably permission to something top secrit [16:11] lol [16:12] ikey: let me ask it differently. I'm a solus user and I want to play steam games. there is a steam snap that allows me to purchase games. if I buy a game, how do I then launch it? [16:12] through steam [16:12] all of it is running under the snap [16:13] ok, so I always go through that thing that declares steam-support [16:13] yeah [16:13] and it launches the game [16:13] there is no branching, just the toplevel steam process tree [16:13] and any child nodes [16:13] so its *effectively* all under a single confinement [16:13] is it possible for that thing to launch games under a different apparmor profile? [16:13] or is that the proprietary bit we don't control? [16:14] proprietary [16:14] **technically* its possible to cd into the dir and try to execute it yourself [16:14] but "good" users of libsteam_api will fail here [16:14] or reexec *under* steam [16:14] so the moral is that steam client is boss and executor [16:15] ikey: so the steam launcher will actually fork/exec the game (obviously). where are the executables it launches? [16:15] they can be anywhere technically [16:15] but not within the context of snappy [16:15] either home or removable-media [16:16] you'll notice that path addition for /media [16:16] I did [16:16] it also has its own helper binaries under its own core runtime tree [16:16] so, do they ever end up in something 'steam-y'. eg, /home/user/Steam or /media/.../Steam? [16:16] like steamwebhelper etc [16:16] well this is the issue [16:16] you have multiple sets [16:17] there is no hard requirement for the steamapps path [16:17] typically a game tree will contain steamapps/common/$NAME/ [16:17] like steamapps/common/Teeworlds [16:18] what I'm pondering is that the launcher and the games themselves are really two different things, and so could in theory have different permission sets [16:18] but the steam core itself has no such real organisation [16:18] jdstrand, not entirely sure that would help you [16:18] the steam api library in the client and games do much of the same stuff [16:18] well, I'm not proposing it. I'm pondering it [16:18] also many game launchers are basically full blown CEF applications [16:18] jdstrand, any idea why apparmor.service would take 1min to start (and stall the boot) https://paste.ubuntu.com/26459192/ [16:18] so they need as much (or more) support as the steam client itself does [16:19] I don't understand gnome-terminal.. I've snapped a replacement but when I launch it (it's in classic mode) it seems to decide I wanted to launch the one on my system instead of the one in the snap [16:19] (this is a single core imx6 ... 256M ram ... about beaglebone class HW) [16:19] diddledan, gnome-terminal has a server running on dbus [16:20] and will activate it on the session [16:20] ergh [16:20] ogra_: let me get back to you. the obvious reason is the cache was invalidated and everything had to be recompiled. on an armhf device with lots of snaps, that could take a while [16:20] any way of telling it not to do that? [16:20] no idea :/ [16:20] jdstrand, only the obligatory core, kernel gadget installed :) [16:20] thats after a fresh install, no extra snaps [16:21] jdstrand, i think one of the main reasons it would be so hard to split this profile up is the way in which steam client is implemented on linux [16:21] (but about the tenth boot so the cache should be there) [16:21] its also a whopping great big cef app [16:21] with a cluster of binaries *and* shell helpers and shell script init [16:21] ogra_: there should only be a couple of profiles there. does rebooting help? (ie, the cache files are in place) [16:21] jdstrand, all reboots take about 2-3min no matter how often i reboot [16:21] ikey: well, so, there were a bunch of shm accesses and the ptrace [16:22] right [16:22] ptrace happens with a whole bunch of feral titles [16:22] and others [16:22] ogra_: does /etc/apparmor.d/cache have anything in it? is the clock right? [16:22] hrm, anyone know how snaps which require --classic confinement can be seeded for snapd? https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4 [16:22] and its not feasible for us to list path matches to every game using ptrace [16:22] the clock is right after network connects (no RTC indeed) [16:22] ogra_: let me get back to you [16:22] yeah, take your time [16:23] ah, ineresting [16:23] ogra@localhost:~$ ls -l /etc/apparmor.d/cache [16:23] total 0 [16:23] i guess there is a prob with the kernel patches then .. thanks for getting me on the right track [16:23] ogra_: that would explain why reboots aren't faster [16:23] yeah [16:24] funnily everything seems ot work as it should [16:24] *to [16:24] still 1 minute for the few profiles is also pretty slow [16:24] well, it doesnt fill the cache ... note i'm logged in on a booted system [16:25] but the kernel is a pre-production thing with self-merged apparmor patches ... i bet there is something missing or broken [16:25] ikey: so, just at a high level, it seems that some of the shm accesses are launcher specific. also, it seams that the launcher should be able to ptrace games, and games should ptrace themselves, but games shouldn't ptrace the launcher or other games [16:26] it is also disappointing the 'm' is needed, but I suppose that is a steam thing [16:26] yeah steam likes to map the shm [16:26] the ptrace thing seems highly specific to child->parent relationship [16:27] and we dont want it going outside that [16:27] hmm, or not ... on my pi's there is also nothing in /etc/apparmor.d/cache ... [16:27] it does seem specific to the ones using CEF btw [16:27] like Hitman Pro etc [16:27] (i.e. AAAs) [16:27] so it mightn't be such a game thing as a "they use chrome" thing [16:28] ikey: it sounds like the CEF games are using the chromium setuid sandbox [16:28] right but none of them are actually setuid [16:28] curious [16:28] mm [16:28] they may have modified chromium [16:28] very possible [16:29] and mostly impossible for us to know sadly [16:29] also they tend to have very ugly changing paths [16:30] an example would be something like /run/media/bigdisk/games/steamapps/common/Hitman Pro™/blahblah/ [16:30] and they have spaces and unicodes and no fixed name for the main entries [16:30] I'm not terribly worried about the ptrace and escaping confinement, because of what we said earlier about kernel version [16:30] yeah [16:30] the valve ipc objects initially i thought were private to the client but it turns out the libsteam api remaps (but not locks) from some games [16:30] I don't care for the fact that an arbitrary steam game could ptrace the launcher and other steam games [16:31] hm ok [16:31] so how would we remedy that portion?> [16:31] *? [16:31] that is what I was pondering [16:31] apparmor has the concept of child profiles [16:32] if we could launch the game under the child profile, the launcher and the child could have different rules [16:32] hm [16:32] there are a lot of ways to pull that off [16:32] PR core#78 opened: 15-remove-grub-common.chroot: skip the first line in grub-common.list [16:32] so the `capability sys_ptrace` would only be in the child profile? [16:32] the launcher itself could use libapparmor to change_profile/change_on_exec. that won't happen though without crazy LD_PRELOAD or upstream support [16:33] right and they'd kick off [16:33] right [16:33] so that is out [16:33] if we know where the executables are, we can use banary attachment [16:33] so can we do crummy path matching? [16:33] if we just assume all steamapps/common/* [16:33] eg, @{HOME}/Steam/** Cx -> steamgame, [16:34] yes [16:34] we could have as many of those as we want [16:34] it looks like all of my test locations have that suffix [16:34] i created 2 new libraries: [16:34] "1" "/home/ufee1dead/SteamLibrary" [16:34] "2" "/run/media/bigdisk/games" [16:34] (on host) [16:34] it doesn't seem terrible that the steam snap could be opinionated on where steam games live [16:35] right [16:35] and both definitely have steamapps/common/ as basedirs of games [16:35] soso we could work with that (in theory) [16:35] right [16:36] so that means that when the launcher (or .sh entry or w/e) starts, its the new child profile there and can ptrace underneath, but not back up? [16:36] the other thing is if the launcher uses a helper to do the launching, we have a child profile for the helper, and then the helper uses ix to launch anything [16:36] there is absolutely no guarantee of any helpers [16:36] they might have .sh or direct executable [16:36] or hell even a .jar [16:36] /path/to/helper Cx -> steamhelper, profile steamhelper { ... } [16:36] like we dont ever know what the middleman is gonna be [16:37] I don't mean the individual games. I mean the launcher itself is broken up into different executables [16:37] *if* they had that architecture, we *may* be able to use a child for the helper instead of the path based stuff [16:37] sure but typically its going to execute /bin/sh [16:38] the launcher just fork/execs any random game thing? [16:38] preeeeeetty much [16:38] i mean this is the game industry [16:38] ok, so that leaves only path-based matching [16:38] i can show you strings for the libraries they use where they exec system("pulseaudio --check 2>/dev/null"); [16:38] (not even kidding.) [16:38] they're not like us :p [16:39] in your opinion, can the steam snap be opinionated in the locations of the games? [16:39] i think it'll need to be [16:39] i cant see evidence of a main launcher outside those paths for the games [16:39] ok, that that gives us the option to explore the feasibility of a child profile [16:39] the main client has all kinds of mad crap with various executables but that side doesnt need ptrace [16:40] let me sketch something real quick... [16:41] does a child profile automatically inherit the parent context? [16:41] or actually ill not say stuff to distract you [16:41] and reconvene shortly xD [16:45] ikey: this is what I'm thinking about: https://paste.ubuntu.com/26459304/ [16:46] ikey: Cx doesn't inherit any apparmor rules. Cx (as opposed to cx) will allow most of the environ through, but LD_PRELOAD and glibc secure exec vars are scrubbed (cx doesn't do that)) [16:48] ikey: with that sketch, the games can be ptraced by the launcher but can't ptrace the launcher. it sounds like CEF would also need: ptrace (trace) peer=@{profile_name}, # allow ptracing one-self [16:48] (that would mean all the steam games could ptrace each other though) [16:48] * ikey clicks [16:49] the question then becomes, is this added complexity doing anything meaningful? [16:49] idk i mean its certainly managed to confuse me plenty [16:50] another day going by, which feels much too short for the amount of work, *sigh* [16:50] to be really useful, we'd need support from the launcher to launch games under individual profiles tailored to the game [16:50] right [16:50] which we're just plain and simple not gonna get [16:50] in an ideal world we'd be able to install each game as a snap too.. [16:51] ikey: sorry. the idea is simple if the sketch isn't. the launcher runs under one profile and can do what it needs to launch games under the child profile. games run under a separate child profile from the launcher and have the perms to do just what they need [16:52] so thats where we'd stuff the bits like mono shm etc? [16:52] the question is then, is the intersection of the two profile basically entire and therefore there is no point in the exercise, or is it small enough to where teasing out the two is useful [16:53] well my view is that if you tease out the two, you may as well tease the third [16:53] the toplevel profile being basic stuff like vulkan, openal, that kinda cruft [16:53] which is the 3rd? [16:53] a child profile for the main steam client [16:53] and then steam games [16:53] I see [16:53] so the client one could handle the mk differences on the IPC objects perhaps [16:53] won't all games need vulkan, openal, etc? [16:54] as well as only allowing the client binaries to touch the executable file on removeable-media [16:54] right but couldnt the two child profiles inherit the top profile? [16:54] as a common thing [16:54] so the commonality would be in the main top profile [16:54] lets not use the word 'inherit' but yes, we could do that fine [16:54] and then specialise in the child profiles [16:54] well, inherit/clone [16:54] (inherit has a very specific meaning in apparmor) [16:54] ah [16:55] like this one would be explicitly for the client: /run/media/**/.steam_exec_test.sh ixmrw, [16:55] we are taling about Cx rules here. that changes to a child profile. most rules you are probably used to are ix rules, which inherit the parent profile [16:56] right [16:56] anyway, let's skip all that exec transition discussion for now :) [16:56] i did see some comments in browser-support suggesting the idea of child profiles but it was commented out [16:57] ikey: just so terminology is correct, when you say 'client', it is what I've been referring to as the 'launcher', yes? [16:57] i would imagine so [16:57] the main Steam UI [16:57] yes [16:57] store/make games open [16:57] ok [16:57] * jdstrand nods [16:58] the client wouldn't have ix rules, it would have Cx (possibly cx) rules [16:58] /run/media/**/.steam_exec_test.sh Cxr -> steamgame, [16:58] ok so that effectively changes the profile to "steamgame" if im interpreting right? [16:58] profile steamgame {} would have ix rules so anything it executes would be under the 'steamgame' profile [16:59] so it would "lose" anything defined in the main profile..? [16:59] yes [16:59] so perhaps my approach is a bit over complicated then [16:59] the child profile allows us to start from scratch to build up a profile specific for games [16:59] right [17:00] we are free to use #include directives or share policy with snapd to insert common rules into it [17:00] oh ok [17:00] yeah i was pondering there the duplication aspect [17:00] if it makes sense to create a little helper in the .go file to splat out common rules for the client and the game, that's totally fine [17:01] right so that'd handle the runtime bits like openal/ pci, etc [17:01] and then specialise on the path [17:01] how that is implemented in code don't worry about. assume we can do what we want when building up the client and the steamgame profiles [17:01] right [17:02] so i mean that approach then "solves" (4.8+) the gaping hole that is ptrace? [17:02] it makes it better [17:02] because it does seem "wrong" that games can have the same permissions as the parent launcher, like writing the executable .steam_exec_test.sh .. [17:02] I mean, 4.8+ means that neither the client nor the game can escape the seccomp sandbox [17:03] right [17:03] that is the real gaping hole [17:03] and we dont want them ptracing *each other* for the icing on the cake [17:03] the other bits are extra hardening to separate games from the client [17:03] which, if we were valve, we'd kinda want [17:03] to protect us from bad actors [17:03] I would think so [17:03] right [17:03] PR snapd#4547 opened: snap: fix race in `snap run --strace` [17:03] what this scheme doesn't do is spearate games from each other [17:03] ok so then we'd also want to specialise the shm paths [17:04] yeah [17:04] all games have the same level of access.. [17:04] which, without some level of magic client support, i dont think we could achieve.. [17:04] we could probably come up with something for that, but I'd like to explore the client from the games more, and if feasible, even implement that first and see if we can isolate games from each other [17:05] well [17:05] we could do some crazy stuff [17:05] (I suspect) [17:05] i agree protecting the client is likely the most important aspect [17:06] given that it does store-like-things [17:06] and credit cards [17:06] where we allow the client profile to load apparmor policy, and we derive profile names from fs paths to launch clients under separate profiles [17:06] but, let's not go there now [17:06] oO [17:06] future wizardry++ [17:06] maybe* [17:06] lol [17:06] really the client needs to do this rather that hackery around it [17:07] yeah [17:07] but, we're creative folks ;) [17:07] :D [17:07] anyway [17:07] ikey: do you feel like two profile approach (client vs child game) would provide a meaningful benefit? [17:08] assuming 4.8 kernel is in place [17:08] well i mean you're the security guy, would that be your recommendation? [17:08] because if it does provide real world benefit then we should [17:08] I like that games can't ptrace the client a lot. like you said, the client takes payment info, etc [17:09] that *alone* is probably worth it [17:09] the following scenario is totally possible: game gets greenlit on steam, hijacks the root ppid memory, and scans for credit cards [17:09] unity asset flip then makes real money [17:09] if we can do bits with shm access to make it better, that is a bonus [17:09] right [17:09] ok [17:09] so we allow the client / launcher to create the shm [17:09] and the games to map and read [17:09] or whatever stops it crashing locally when i do it [17:09] heh [17:10] so the path if it *doesn't* match, i keep my local ix? [17:10] otherwise i go Cx and redo inside that profile..? [17:10] * ikey might be butchering terminology slightly here [17:11] and fwiw it seems silly for us to avoid what the sandboxing can offer ^^ [17:12] in essence, yes, but we might have to do some weird stuff to avoid 'conflicting x modifiers'. I'd like to shield you from that, so I'd like to work up a test snap and then give you the rules for the Cx/ix [17:12] oh, that'd be fantastic, ty [17:13] ikey: this is my idea. I create a little test snap that has a 'launcher'. the 'launcher' plugs home and removable-media. the launcher is allowed to Cx to ~/SteamLibrary/where? and /media/where? [17:13] well SteamLibrary was just a sample path [17:13] technically its ~/**/steamapps/common/** and /run/media/**/steamapps/common/** [17:13] just give me the path in home and /media you'd like to use [17:14] ok [17:14] our launcher im gonna have to figure out technically exactly where it lives and how ~ expands [17:14] as LSI modifies ~ [17:14] we use SNAP_USER_COMMON as our root [17:15] basically to prevent against gigs of data being shuffled around on each snap update [17:15] Saviq: Can you please give it a shot now? [17:16] so my full host side path would be /home/ufee1dead/snap/linux-steam-integration/common/.local/share/Steam [17:16] so what is ~/**/steamapps/common/** more specifically? @{HOME}/snaps/${SNAP_NAME}/common/steamapps/common/** ? [17:16] ok [17:16] /home/ufee1dead/snap/linux-steam-integration/common/.local/share/Steam [17:16] and what about a full path in /media? [17:17] '/run/media/bigdisk/games/steamapps/common/DiRT Rally/bin/DirtRally' [17:17] interesting [17:17] so *not* /run/media/USERNAME/bigdisk/... [17:17] everything before "steamapps" is my own pathing [17:17] yeah [17:18] right its a static fstab [17:18] ah [17:18] ok [17:19] i think there is some notion of /{run,}/media/**/steamapps/common/** needed [17:19] * ikey cant mentally shell expand atm [17:19] ikey: alright, I'll work through this a bit and comment in the forum. then you can play and hopefully be able to update the PR, at which point we can iterate in the PR [17:19] * jdstrand nods [17:19] yeah that sounds great to me, thanks [17:19] yw [17:19] like these are my last big blockers [17:20] full confinement to unbreak it, and then controllers [17:20] * jdstrand nods [17:20] then tada leave edge [17:20] sorry for the delay. I knew I needed both time and you to be able to respond intelligently [17:20] yeah thats why i did the forum post approach originally, cuz i even said theres no way it could go in without discussion [17:20] it had to be properly thinkerised [17:21] * ikey isn't a security guy either so will happily rely on others expertise [17:37] PR snapd#4548 opened: spread: reduce linode plan size too see impact [17:47] ppisati, still around ? ... if i have "kdefconfig: [xxx_defconfig, snappy/generic.config, snappy/security.config, snappy/systemd.config, snappy/snappy.config, snappy/containers.config]" and have conflicting settings in one f the snappy ones (vs xxx_defconfig), will they override ? i.e. are the configs processed in the order they are listed there .... left to right ? [17:58] Saviq: Looking good: https://travis-ci.org/MirServer/mir/jobs/333310160 [17:58] niemeyer: yeah, if only travis showed me the jobs... [17:59] Saviq: Hm? [17:59] there we go [17:59] Saviq: Doesn't it? [17:59] it was just hanging there with the animated dots [17:59] Ah :) [17:59] slow javascript is slow ;) [17:59] * Saviq restarted the remaining jobs, let's see [18:02] niemeyer: it does look much better indeed [18:02] Saviq: I think the concurrency issues are sorted, but I've fiddled quite a bit, so please let me know if you see any extraneous behavior [18:03] ack! [18:03] thansk! [18:03] thanks, even! [18:06] mvo: ok, reviewed your changes: https://github.com/snapcore/snapd/pull/4073#pullrequestreview-91614503 [18:06] PR #4073: snap: add io.snapcraft.Settings to `snap userd` [18:08] Saviq: np [18:12] hey folks, where can I find docs on snapd's local API? [18:18] Is there a portable/bootstrap install of snapd? The distro I use, openSUSE, is packaging old versions, and not responding to requests to update. I'd rather use an upstream solution, but afaict, there's no "portable installer" at https://docs.snapcraft.io/core/install . [18:18] Is the only option to DIY build? [18:19] PR snapd#4548 closed: spread: reduce linode plan size too see impact [18:29] sigise, that's probably a question for zyga-ubuntu [18:36] kyrofa: thx zyga-ubuntu ping [19:21] zyga-ubuntu mvo how many times can I plug with the content interface inside a snap? [19:22] hoping for the answer to be N, where N > 1 [19:35] sergiusens: eee, yes [19:35] sergiusens: especially since like yesterday [19:35] sergiusens: when improved c-i got merged [19:35] sergiusens: but not until 4471 [19:35] zyga-ubuntu so not on 2.30? [19:35] sergiusens: which is the mechanism for the policy [19:35] sergiusens: you can on 2.30 but it will do useless things [19:36] hmm, so mid week maybe? We have interesting use cases; is this avail on edge or will it be by Monday at least? [19:36] sergiusens: in rc2 it will be auto-aggregating as subidrs [19:36] sergiusens: by monday likely [19:36] or just merge 4471 [19:37] zyga-ubuntu great, do we have docs for this behavior somewhere? [19:37] zyga-ubuntu I have an ISV really interested in this working [19:51] zyga-ubuntu: ping again [19:56] jdstrand: hi! we added this new common-id field (https://forum.snapcraft.io/t/support-for-appstream-id/2327/18) but need the reviewer tools to be aware of the field, otherwise any snap using it will be rejected :( [19:59] roadmr: ok, I'll add that for the next pull [20:00] sergiusens: some in the forum but I will update the main content iface docs once it lands [20:00] sergiusens: and I have pending forum post about it, [20:00] sergiusens: what is the use case? [20:06] thanks jdstrand ! [21:18] PR snapcraft#1881 closed: elf: better handling for newer libc6 [21:26] PR core#78 closed: 15-remove-grub-common.chroot: skip the first line in grub-common.list [21:42] PR snapcraft#1885 opened: Release 2.39 === devil is now known as Guest81887