[00:41] crazy question here [00:41] lets say i wanted to control the cpu governor from inside a snap... [00:41] to switch between powersave/ondemand + performance... [00:41] would this be something i could ever do? === nsg_ is now known as nsg === AdmWiggin is now known as tianon === pbek_ is now known as pbek [06:02] morning everyone [06:13] PR snapd#4164 closed: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS [06:16] o/ [06:16] mborzecki: you start early :) [06:17] zyga-ubuntu: hey, yeah i plan to keep a regular 7-15 schedule, otherwise my day goes to hell quickly [06:17] besides, my wife drives kids to school at ~7 so I'm already up at ~5:45-6 [06:18] zyga-ubuntu: no rush about the review :) suppose you have things to do in the morning [06:21] PR snapd#4151 closed: tests: fix security-device-cgroup* tests on devices with framebuffer [06:24] mborzecki: yeah, I feel broken-ish still [06:24] my yesterday was a disaster, I started my day in the late afternoon after meds helped, then stayed way too long (as usual) [06:24] mborzecki: uh, still not feeling well? take it easy then [06:24] caught a cold? [06:24] I need to adopt the morning / early afternoon cycle [06:25] both that and still recovering from back pain (over a week now) :/ [06:25] mvo: I'll prep kids and I'll focus on udev branches for 2.29 / master [06:26] mvo: I got a review from jamie on udev tagging on hooks and I need to tweak it to format the output differently (sorting) [06:26] zyga-ubuntu: more to come? meh [06:26] zyga-ubuntu: or the hooks one? [06:26] the hooks one [06:26] zyga-ubuntu: aha, ok. thank you! [06:26] it will conflict after some other bits land so I'll focus on that first [06:26] pedronis: for later (not urgent at all) - 3992 needs some love, unit test failure currently [06:26] I guess today is final 2.29.3 attempt, right? [06:30] zyga-ubuntu: well, I would like to do 2.29.2 and then 2.29.3 a week later, unless we have regression in 2.29 that were not in 2.28 already [06:31] zyga-ubuntu: but depends a bit on QA feedback, we wanted to release today but that seems unlikely given that we need CE results [06:35] mvo: I see, ok [06:35] I'll do my best to help as soon kids are sorted [06:58] PR snapd#4121 closed: overlord/snapstate: toggle ignore-validation as needed as we do for channel [06:59] PR snapd#4125 closed: corecfg: support setting proxy.store if there's a matching store assertion [07:06] is /var/lib/snapd/apparmor/snap-confine needed if snap-confine was configured with --disable-apparmor? [07:06] mborzecki: no [07:07] but [07:07] snapd will do runtime detection and will create and may populate that directory anyway [07:07] oh, ok [07:07] I think in general it is better to enable apparmor [07:07] even if the kernel is not apparmor aware [07:07] (as long as there is userspace) [07:08] yeah, arch is so manly that we don't use apparmor... [07:08] my point is that the configure time options are partial, they don't affect snapd [07:08] so I'd, if you can, enable apparmor to the extent possible [07:10] i'm getting close with arch packaging, at least the blender snap works just fine (though it's classinc, but it didn't work before anyway) [07:10] snappy-m-o autopkgtest 1716 xenial:amd64 [07:10] elopio: I've just triggered your test. [07:11] snappy-m-o autopkgtest 1657 xenial:amd64 [07:11] elopio: I've just triggered your test. [07:11] classic is actually harder :) [07:12] btw. hello-world.evil 'If you see this line the confinement is not working correctly, please file a bug' will not show only if using apparmor? [07:12] yes [07:12] it's a _very_ old and simplistic test btw [07:13] ok, i saw the message and wasn't sure whether I've screwed sth up or the system is missing some piece of infra [07:14] oh, and cleaned up environment file, now you can properly set SNAPD_DEBUG=1 for the daemon :P [07:18] mborzecki: 4135 has some simple nitpick things then it can go in from my POV [07:18] mvo: thanks for the review [07:18] mborzecki: felt slightly bad as it is really just nitpicks but then consistency in the codebase++ and all that :) [07:19] sure thing [07:19] (I mean, I felt slightly bad about nitpicking so much) [07:21] nitpick: nitpick less [07:21] :) [07:21] * zyga-ubuntu looks at sorting udev rules better [07:40] is there something like a smoke test i could use to verify that local snapd installation works as expected? [07:40] mborzecki: spread tests, but that's one big leap to do [07:41] mborzecki: if you run spread you will find all the interesting details that are broken [07:41] i was hoping for something i can run in 5 minutes locally to verify that the arch package works ok [07:42] you can run something for 5 minutes or you can run spread to find out if it works well, in my experience it's almost always something unexpected that fails mysteriously due to bugs or missing packaging [07:43] mborzecki: but don't get me wrong, just use it daily and we'll know over time [07:43] mborzecki: but there are some many features that only a spread run is a really good measure of what is broken [07:44] hmm DirsTestSuite.TestClassicConfinementSupportOnSpecificDistributions() started failing out of the blue [07:47] SupportsClassicConfinement() found /snap in my system [07:48] perhaps missing mocking [08:04] there's something weird about that test, its outcome may be altered by having the package installed in the system [08:04] the whole check-SnapMountDir-symlink should probably be mocked [08:10] mborzecki: yeah, sounds very much like an oversight from our patrt [08:10] part === JanC is now known as Guest4348 [08:15] * zyga-ubuntu goes to change 26 unit tests after rendering of udev rules got changed [08:20] good morning [08:20] hey kalikiana - good morning [08:37] PR snapd#4172 opened: interfaces/kmod: simplify loadModules now that errors are ignored [08:44] mvo: reviewed [08:52] that feeling when you spend time mocking something just to come to a relization that a simpler fix is only a couple of lines [08:52] * mvo hugs mborzecki - we have all been there [08:54] * mvo tries to reproduce the lxd/juju bug from the forum [09:02] pushed fixes for #4135 [09:02] PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch [09:07] mvo: can you look at https://github.com/snapcore/snapd/pull/4144 please [09:07] PR #4144: interfaces: fix udev tagging for hooks [09:07] I adjusted as jdstrand requested, [09:07] the diff is slighltly larger because of how formatting and sorting is done but this should help in readability of actual udev rules [09:09] mvo: about #3992, after some recent discussions is not so clear anymore that is exactly what we need, I will close until that area is been worked on concretely again [09:09] PR #3992: asserts: add cross-checking for snap-build [09:11] PR snapd#3992 closed: asserts: add cross-checking for snap-build [09:11] PR snapd#4165 closed: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS (2.29) [09:16] I need a review for https://github.com/snapcore/snapd/pull/4163 [09:16] PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} [09:20] jamesh: failing tests on 4140 [09:21] PR snapd#4167 closed: cmd/snap-update-ns: fix golint and some stale comments [09:22] mborzecki: conflict on 4135 === __chip__ is now known as Chipaca [09:25] zyga-ubuntu: s/update.XSnapdGid/update.XSnapdGID/ right? [09:28] when merging a branch, do you leave the list of files with conflicts in the commit message? [09:32] mborzecki: hmm? [09:32] mborzecki: about the conflicts, not really, I think those are stripped out [09:36] Good morning all. Will the patches needed for snaps be included in the mainline 4.14 kernel? I'm thinking of switching graphics cards to AMD, and that might push me into upstream kernel territory for best performance [09:41] mcphail: this is a question for jjohansen; AFAIK one patch was still discussed and that was blocking the merge so perhaps the answer is no [09:41] aah. thanks zyga-ubuntu [09:41] zyga-ubuntu: conflicts are resolved now [09:41] * zyga-ubuntu -> coffee, brb [09:41] mborzecki: thank you [09:42] mborzecki: great :) === jero is now known as Guest45935 [09:51] PR snapd#4173 opened: corecfg: validate refresh.schedule when it is applied [09:54] mvo: removed where? ^^ [09:55] mvo: you said that we did this in the test suite [09:55] and that you removed that now === JoshStrobl|zzz is now known as JoshStrobl [09:58] zyga-ubuntu: added some comments to #4163 [09:58] PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} [09:59] mborzecki: thank you [10:00] zyga-ubuntu: ups, sorry, forgot to push that commit, will do so in a sec [10:01] zyga-ubuntu: i'm not entirely sure about that "/", i may be worth double checking cause it looks like you'll do `segment := segments[-1]` in secureMkDir [10:01] zyga-ubuntu: force pushed, sorry but I also forgot to add the header to corecfg.go [10:06] mvo: what's the schedule for edge builds atm ? [10:12] pedronis: its broken right now, its supposed to happen after merges to master that have a green test [10:12] heh [10:13] is that spread-cron, or something else? [10:13] pedronis: yes, spread cron [10:13] :( [10:13] pedronis: I triggered it manually this morning so we should have a proper edge soon [10:14] but that is not a soluation of course [10:14] solution even [10:14] mvo: after or before the proxy.store= merge ? [10:14] pedronis: I think after, this merged happend last night, right? [10:15] mvo: no, you merged it this morning I think [10:15] * kalikiana coffee [10:16] mborzecki: yeah, I'm adding tests [10:16] mvo: thanks :) [10:17] pedronis: hm, let me double check then [10:17] zyga-ubuntu: thank you! [10:17] pedronis: according to launchpad it is in [10:28] ok [10:31] mborzecki: pushed with some updates, thank you for spotting that [10:32] zyga-ubuntu: similar thing with secureMkFile [10:32] but I think you can bail out there early by checking if the path does not end with / [10:33] mborzecki: or just is "/", yeah [10:33] mborzecki: I decided not to bail but instead check length around critical places [10:33] just checking / will not cover a path like /foo/bar/ [10:33] mborzecki: this works just as fine and has lower coverage impact [10:34] mborzecki: I mean check if the actual full path is exactly "/" [10:36] mvo: I don't understand the refresh.schedule change in the tests? isn't the idea that we don't want refreshes during the tests? shouldn't we put something correct back? [10:36] zyga-ubuntu: uhh, yeah, i meant for secureMkFile you'll probably need to check if the path does not end with / [10:37] mborzecki: we do filepath.Clean on that [10:37] it will chop off the final / [10:37] it's a bit tricky, I agree [10:37] mborzecki: I'll look at mkfile now [10:38] mborzecki: I think for mkfile we should error if name ends with "/" [10:38] yup [10:38] pedronis: I can look into this, right now the settings have no effect (they will be rejected by snapd when it reads them internally) so things are not worse than before. but I agree this is a good opportunity to ensure things are properly done [10:39] pedronis: I fix it [10:39] mvo: and perhaps this can explain random failures (some of them) [10:39] where we just refresh [10:39] zyga-ubuntu: definitely [11:07] mborzecki: updated and pushed https://github.com/snapcore/snapd/pull/4169 [11:07] PR #4169: cmd/snap-update-ns: add secureMkfileAll [11:07] mborzecki: In the end I rebased because somehow the merge was messy [11:07] ok [11:07] mborzecki: so please look at https://github.com/snapcore/snapd/pull/4169/commits/08d3ed6f54de26a7e671b58453044baebf591e1d [11:08] zyga-ubuntu: sorry for poking your reviews :) it's just that you have so many of them [11:10] mborzecki: thank you :-D I cannot be happier really [11:10] usually we beg for reviews [11:11] PR snapd#4162 closed: interfaces/kmod: treat failure to load module as non-fatal [11:13] mborzecki: https://github.com/snapcore/snapd/pull/4166 is trivial [11:13] PR #4166: cmd/snap-update-ns: detect and report read-only filesystems [11:13] just https://github.com/snapcore/snapd/pull/4166/commits/c21a85a15c923a5935d5374fe76c29463030c588 on top of other PRs [11:13] i'm look at it right now [11:13] (I have a similar one, unpushed, for mkfile) [11:14] mborzecki: once some of those land I'll rebase my working branch and start push one more trivial branch and two more interesting branches for the "tmpfs bind mount farm" [11:14] and with some luck, it will all fall into place and "just work" [11:15] I still need to implement symlink creation and generalize actions for create/destroy (so that we don't "mount" symlinks which is just confusing) [11:16] 4170 is part of this work too? [11:16] yes [11:16] that's the "main" element in many ways [11:16] everything else is to make that part work [11:21] o/ [11:22] so high level view is that once you hit a read only path, you'll bind tmpfs over this and recreate all the things from that original location inside tmpfs? [11:22] mborzecki: exactly [11:22] niemeyer: hi [11:22] hey niemeyer [11:24] hi niemeyer [11:27] Pharaoh_Atem: hey, did you see https://bugzilla.redhat.com/show_bug.cgi?id=1509586 [11:28] I don't have F27 around [11:29] Hey there [11:35] * zyga-ubuntu -> break [11:42] pedronis, do you have a moment for HO? [11:46] https://travis-ci.org/snapcore/snapd/builds/299009217 hit travis timeout, should i restart? [11:50] yes [12:01] ok, I really want to break now [12:01] see you at the call [12:07] pedronis: fwiw, core in edge should be up-to-date now [12:18] jdstrand: the /dev/mem test that cachio did in PR 4171 is interesting - it fails with EPERM and no apparmor denial, this is strange, usually we get EPERM (instead of EACCESS) when the device cgroup access fails, but poking around in a spread VM with the failed test things look ok there. do you know if /dev/mem is handled specially (beside the strict_devmem kernel mode which should still allow us to read the first 1mb). fwiw, its correctly tagged [12:18] in udev afaict [12:18] PR #4171: tests: adding test to test physical memory observe interface [12:21] PR snapd#4174 opened: packaging/arch: packaging update [12:23] PR snapcraft#1648 closed: sources: get svn revision with --show-item flag [12:37] Chipaca: hi, I do plan to look at your aliases PR today or tomorrow [12:45] jdstrand: Related to our conversation around user ids and daemon: [12:45] https://github.com/snapcore/snapd/pull/4135/files#diff-be7cfe1e5aff69d70d80b1c2cabcaaccL749 [12:45] PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch [12:47] kalikiana mind looking into my comment on snapcraft#1633 ? [12:47] PR snapcraft#1633: recording: record information from the image in container builds [12:48] niemeyer: hey, yeah I saw that and thought the same thing [12:48] mvo: there are kernel controls for /dev/mem [12:51] mvo, cachio: our kernels are configured with STRICT_DEVMEM. see interfaces/builtin/physical_memory_control.go for details [12:52] * zyga-ubuntu just read a PR title as "add support for soviet activation" [12:57] zyga-ubuntu: I don't know if I should laugh or give you a hug :) [12:59] jdstrand: SOVIETS TRIGGERED! [13:00] heh [13:10] jdstrand: I pushed updates to udev tagging for hooks [13:10] jdstrand: I'm running spread locally now to see if I broke something [13:12] jdstrand: sorting by tag is actually a pretty nice idea [13:12] jdstrand: I also added a comment that says # iface so that we know which interface added the rule [13:12] jdstrand: have a look if you have time [13:16] Can someone please review my alias request? https://forum.snapcraft.io/t/alias-request-for-mgba/2710 [13:20] jdstrand: my understanding is that STRICT_DEVMEM allows access to the first 1mb of mem - it is also failig in open() already, so how is this supposed to work, does it just support mmap()? [13:20] jdstrand: if you need to look it up, no worries, I can do this too :) just wondering if you know without research [13:28] zyga-ubuntu: awesome, thanks! [13:30] jdstrand: I think some spread tests fail but they are probably (probably) just too picky and grep for detailed strings [13:30] I'll fix those soon [13:30] (well, fixing now) [13:30] popey: I planned to today (note, 1 week hasn't gone by yet) [13:31] ok :) [13:47] PR snapcraft#1720 opened: kernel plugin: introduce kernel-channel to select from which channel … [13:48] Son_Goku: I'm installing gnome desktop on centos now, I can try your EPEL package soon [13:48] zyga-ubuntu: okay, cool [13:48] Son_Goku: I forgot how to use yum :) [13:48] heh [13:48] Son_Goku: is there a nice way to meta-install the desktop [13:48] there's a DNF for CentOS 7 [13:48] oh? it's not installed by default [13:49] I'm on centos 7 for sure [13:49] https://seven.centos.org/2017/10/yum-4-is-available-for-testing/ [13:49] yum or dnf? [13:49] yum 4 == dnf [13:49] ah [13:50] but is the CLI the same? [13:50] Yep [13:50] yum4 is a symlink to /usr/bin/dnf [13:50] in Fedora, this is the "dnf-yum" package [13:53] zyga-ubuntu: so once that's installed, you can use dnf as normal [13:57] PR snapcraft#1655 closed: lxd: distinguish argless clean from clean -s pull [13:58] the build service is refusing to let me login again [13:58] refusing my launchpad oauth token [13:59] "Error:Invalid association handle" [14:02] hmm, maybe it's specific to firefox (I have ublock origin installed, which might be conflicting) [14:06] jdstrand: oh, drat [14:06] jdstrand: my bad [14:06] jdstrand: KERNEL=="foo", TAG+="bar" # this is a comment [14:06] this is not valid [14:06] udev, man... really? [14:06] I need to change that to [14:07] # this is a comment [14:09] heh, yeah. it seems pretty finicky [14:09] sergiusens: now that you asked me to change the test... I'm pondering to change "image-info: {architecture: test-architecture, created_at: test-created-at, fingerprint: test-fingerprint}" to use line-broken syntax without the {} for consistency [14:11] need to check, though, how to change that. yaml has this behavior where the syntax depends on what types you use, not sure you can choose manually [14:14] flexiondotorg: or popey: the build service has lost the store-name references for inadyn, opentyrian, and warzone2100 from the snapcrafters repositories [14:14] que? [14:15] https://usercontent.irccloud-cdn.com/file/sJAYGe5k/Screenshot%20from%202017-11-08%2014-14-40.png [14:16] huh [14:16] thats odd [14:16] jdstrand: I'm considering dropping the # iface comment [14:17] fixed warzone2100 [14:17] jdstrand: unless you think strongly we should keep it [14:17] I think it's because I had duplicates building from my own repo that should have been nuked. I nuked them, and it appears they've also disassociated the snapcrafters repos. [14:17] it's just a hassle, I really hoped udev would suck less at parsing [14:17] zyga-ubuntu: it would be nice, but I don't think it is strictly required [14:17] thats plausible [14:17] diddledan: fixed all three, they're all building now [14:18] thankyou :-) [14:18] np [14:18] in other news. diddledan would you like to be a collaborator on these snaps? [14:18] I was trying to force a build so they get i386 versions when I spotted it :-) [14:18] so you can help manage them in the store? [14:18] zyga-ubuntu: I wonder if you could do # comment\nKERNEL==... for the first string... [14:18] jdstrand: sorry, I had various laptop problems [14:18] not super pretty [14:19] sure :D [14:19] jdstrand: did you write anything after I asked about STRICT_DEVMEM? [14:19] mvo: no. I don't know of anything else otoh [14:19] ok, what email address should I add you as? [14:19] my launchpad is diddledan, I think that's pointing at daniel@bowlhat.net [14:20] jdstrand: ok, thank you, I poke a bit more, maybe the 1mb limit is on 32bit systems only, i.e. maybe this is arch dependent or something [14:20] alternatively diddledan@gmail will work [14:20] jdstrand: eh, I mean the limit that you can access the first 1mb on dev/mem [14:20] * diddledan fires up the forum to catch-up on todays posts [14:20] mvo: yeah, I don't know otoh [14:20] which one do you sso with? [14:20] jdstrand: ta [14:20] I try to sso with daniel@bowlhat.net [14:21] ok [14:21] will add you a bit later. [14:21] ta [14:22] ok, soup time, I'll get back to udev shortly [14:24] mvo: did you come up with a kmod test? I thought of one that we could use on core [14:25] jdstrand: I just wrote a unit test, I was not thinking about a kmod spread test so far [14:25] mvo: ok. I'll try a spread test soonish [14:26] thanks [14:31] PR snapd#4135 closed: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch [14:36] PR snapd#4175 opened: dirs: use alt root when checking classic confinement support without … [14:47] niemeyer, partially fixed the issue on spread-cron [14:47] niemeyer, I'll add a PR to fix the problem [14:48] basically, it is failing when there are conflicts on the branches, and that be caused because a change we do and push [14:53] kalikiana well the json in a yaml thing is just not nice; pseudo json I even. [14:54] sergiusens: right. I'm trying to figure out if we can force the style [14:55] hey popey, how can I enable build.snapcraft.io for vault? [14:55] kalikiana if you just add the dict, the right thing will happen on unmarshalling [14:55] elopio: just did it, building now [14:56] sergiusens: no it doesn't [14:56] It's already a dict [14:56] This is YAML [14:57] popey: thanks. Do you have in mind any solution to keep the snapcrafters branches up-to-date with upstream? Latest vault stable is 8.3, and the latest we have released is 8.0. [14:57] elopio: pull requests against the yaml is the simplest thing [15:01] preferable to push it upstream of course [15:01] re [15:05] popey: yeah, but for the ones that upstream doesn't want. Would you mind if I experiment with vault to do it automatically? [15:16] elopio, could you share the setup you have done for the autopcktests exec on snapcraft? [15:17] elopio, you are running agains a ppa right? [15:25] elopio: sure [15:25] elopio: flexiondotorg has some scripts to automate this too [15:26] kalikiana one comment on snapcraft#1412 [15:26] PR snapcraft#1412: lxd: snapcraft refresh in containers [15:26] cachio_: https://github.com/snapcore/snapcraft/pull/1643 [15:26] PR snapcraft#1643: [WIP] tests: run daily autopkgtest in travis [15:27] kalikiana also, not sure you noticed, but it would be nice to use a temfile context to copy the snap into the lxd accessible area when copying the snaps over [15:29] elopio, tx [15:32] I'm looking at gimp. Trying to get internationalization working. I can't figure out how to tell gimp that it's translations are in $SNAP/usr/share/locale [15:33] is there an environment variable to tell libc where to look for the locale folder? [15:38] diddledan: LOCALEDIR? [15:39] 'parently not [15:39] diddledan: dunno [15:42] WHYISITALLSODIFFICULT [15:42] I'm hoping that with layouts it's not going to be that hard [15:42]