| ikey | crazy question here | 00:41 |
|---|---|---|
| ikey | lets say i wanted to control the cpu governor from inside a snap... | 00:41 |
| ikey | to switch between powersave/ondemand + performance... | 00:41 |
| ikey | would this be something i could ever do? | 00:41 |
| === nsg_ is now known as nsg | ||
| === AdmWiggin is now known as tianon | ||
| === pbek_ is now known as pbek | ||
| mborzecki | morning everyone | 06:02 |
| mup | PR snapd#4164 closed: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4164> | 06:13 |
| zyga-ubuntu | o/ | 06:16 |
| zyga-ubuntu | mborzecki: you start early :) | 06:16 |
| mborzecki | zyga-ubuntu: hey, yeah i plan to keep a regular 7-15 schedule, otherwise my day goes to hell quickly | 06:17 |
| mborzecki | besides, my wife drives kids to school at ~7 so I'm already up at ~5:45-6 | 06:17 |
| mborzecki | zyga-ubuntu: no rush about the review :) suppose you have things to do in the morning | 06:18 |
| mup | PR snapd#4151 closed: tests: fix security-device-cgroup* tests on devices with framebuffer <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4151> | 06:21 |
| zyga-ubuntu | mborzecki: yeah, I feel broken-ish still | 06:24 |
| zyga-ubuntu | 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 |
| mvo | mborzecki: uh, still not feeling well? take it easy then | 06:24 |
| mborzecki | caught a cold? | 06:24 |
| zyga-ubuntu | I need to adopt the morning / early afternoon cycle | 06:24 |
| zyga-ubuntu | both that and still recovering from back pain (over a week now) :/ | 06:25 |
| zyga-ubuntu | mvo: I'll prep kids and I'll focus on udev branches for 2.29 / master | 06:25 |
| zyga-ubuntu | 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 |
| mvo | zyga-ubuntu: more to come? meh | 06:26 |
| mvo | zyga-ubuntu: or the hooks one? | 06:26 |
| zyga-ubuntu | the hooks one | 06:26 |
| mvo | zyga-ubuntu: aha, ok. thank you! | 06:26 |
| zyga-ubuntu | it will conflict after some other bits land so I'll focus on that first | 06:26 |
| mvo | pedronis: for later (not urgent at all) - 3992 needs some love, unit test failure currently | 06:26 |
| zyga-ubuntu | I guess today is final 2.29.3 attempt, right? | 06:26 |
| mvo | 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:30 |
| mvo | 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:31 |
| zyga-ubuntu | mvo: I see, ok | 06:35 |
| zyga-ubuntu | I'll do my best to help as soon kids are sorted | 06:35 |
| mup | PR snapd#4121 closed: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4121> | 06:58 |
| mup | PR snapd#4125 closed: corecfg: support setting proxy.store if there's a matching store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4125> | 06:59 |
| mborzecki | is /var/lib/snapd/apparmor/snap-confine needed if snap-confine was configured with --disable-apparmor? | 07:06 |
| zyga-ubuntu | mborzecki: no | 07:06 |
| zyga-ubuntu | but | 07:07 |
| zyga-ubuntu | snapd will do runtime detection and will create and may populate that directory anyway | 07:07 |
| mborzecki | oh, ok | 07:07 |
| zyga-ubuntu | I think in general it is better to enable apparmor | 07:07 |
| zyga-ubuntu | even if the kernel is not apparmor aware | 07:07 |
| zyga-ubuntu | (as long as there is userspace) | 07:07 |
| mborzecki | yeah, arch is so manly that we don't use apparmor... | 07:08 |
| zyga-ubuntu | my point is that the configure time options are partial, they don't affect snapd | 07:08 |
| zyga-ubuntu | so I'd, if you can, enable apparmor to the extent possible | 07:08 |
| mborzecki | 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 |
| elopio | snappy-m-o autopkgtest 1716 xenial:amd64 | 07:10 |
| snappy-m-o | elopio: I've just triggered your test. | 07:10 |
| elopio | snappy-m-o autopkgtest 1657 xenial:amd64 | 07:11 |
| snappy-m-o | elopio: I've just triggered your test. | 07:11 |
| zyga-ubuntu | classic is actually harder :) | 07:11 |
| mborzecki | 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 |
| zyga-ubuntu | yes | 07:12 |
| zyga-ubuntu | it's a _very_ old and simplistic test btw | 07:12 |
| mborzecki | 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:13 |
| mborzecki | oh, and cleaned up environment file, now you can properly set SNAPD_DEBUG=1 for the daemon :P | 07:14 |
| mvo | mborzecki: 4135 has some simple nitpick things then it can go in from my POV | 07:18 |
| mborzecki | mvo: thanks for the review | 07:18 |
| mvo | mborzecki: felt slightly bad as it is really just nitpicks but then consistency in the codebase++ and all that :) | 07:18 |
| mborzecki | sure thing | 07:19 |
| mvo | (I mean, I felt slightly bad about nitpicking so much) | 07:19 |
| zyga-ubuntu | nitpick: nitpick less | 07:21 |
| zyga-ubuntu | :) | 07:21 |
| * zyga-ubuntu looks at sorting udev rules better | 07:21 | |
| mborzecki | is there something like a smoke test i could use to verify that local snapd installation works as expected? | 07:40 |
| zyga-ubuntu | mborzecki: spread tests, but that's one big leap to do | 07:40 |
| zyga-ubuntu | mborzecki: if you run spread you will find all the interesting details that are broken | 07:41 |
| mborzecki | i was hoping for something i can run in 5 minutes locally to verify that the arch package works ok | 07:41 |
| zyga-ubuntu | 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:42 |
| zyga-ubuntu | mborzecki: but don't get me wrong, just use it daily and we'll know over time | 07:43 |
| zyga-ubuntu | mborzecki: but there are some many features that only a spread run is a really good measure of what is broken | 07:43 |
| mborzecki | hmm DirsTestSuite.TestClassicConfinementSupportOnSpecificDistributions() started failing out of the blue | 07:44 |
| mborzecki | SupportsClassicConfinement() found /snap in my system | 07:47 |
| zyga-ubuntu | perhaps missing mocking | 07:48 |
| mborzecki | there's something weird about that test, its outcome may be altered by having the package installed in the system | 08:04 |
| mborzecki | the whole check-SnapMountDir-symlink should probably be mocked | 08:04 |
| mvo | mborzecki: yeah, sounds very much like an oversight from our patrt | 08:10 |
| mvo | part | 08:10 |
| === JanC is now known as Guest4348 | ||
| * zyga-ubuntu goes to change 26 unit tests after rendering of udev rules got changed | 08:15 | |
| kalikiana | good morning | 08:20 |
| mvo | hey kalikiana - good morning | 08:20 |
| mup | PR snapd#4172 opened: interfaces/kmod: simplify loadModules now that errors are ignored <Created by mvo5> <https://github.com/snapcore/snapd/pull/4172> | 08:37 |
| zyga-ubuntu | mvo: reviewed | 08:44 |
| mborzecki | 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:52 | |
| * mvo tries to reproduce the lxd/juju bug from the forum | 08:54 | |
| mborzecki | pushed fixes for #4135 | 09:02 |
| mup | PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 09:02 |
| zyga-ubuntu | mvo: can you look at https://github.com/snapcore/snapd/pull/4144 please | 09:07 |
| mup | PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144> | 09:07 |
| zyga-ubuntu | I adjusted as jdstrand requested, | 09:07 |
| zyga-ubuntu | the diff is slighltly larger because of how formatting and sorting is done but this should help in readability of actual udev rules | 09:07 |
| pedronis | 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 |
| mup | PR #3992: asserts: add cross-checking for snap-build <Created by pedronis> <https://github.com/snapcore/snapd/pull/3992> | 09:09 |
| mup | PR snapd#3992 closed: asserts: add cross-checking for snap-build <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3992> | 09:11 |
| mup | PR snapd#4165 closed: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS (2.29) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4165> | 09:11 |
| zyga-ubuntu | I need a review for https://github.com/snapcore/snapd/pull/4163 | 09:16 |
| mup | PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163> | 09:16 |
| zyga-ubuntu | jamesh: failing tests on 4140 | 09:20 |
| mup | PR snapd#4167 closed: cmd/snap-update-ns: fix golint and some stale comments <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4167> | 09:21 |
| zyga-ubuntu | mborzecki: conflict on 4135 | 09:22 |
| === __chip__ is now known as Chipaca | ||
| mborzecki | zyga-ubuntu: s/update.XSnapdGid/update.XSnapdGID/ right? | 09:25 |
| mborzecki | when merging a branch, do you leave the list of files with conflicts in the commit message? | 09:28 |
| zyga-ubuntu | mborzecki: hmm? | 09:32 |
| zyga-ubuntu | mborzecki: about the conflicts, not really, I think those are stripped out | 09:32 |
| mcphail | 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:36 |
| zyga-ubuntu | 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 |
| mcphail | aah. thanks zyga-ubuntu | 09:41 |
| mborzecki | zyga-ubuntu: conflicts are resolved now | 09:41 |
| * zyga-ubuntu -> coffee, brb | 09:41 | |
| zyga-ubuntu | mborzecki: thank you | 09:41 |
| mcphail | mborzecki: great :) | 09:42 |
| === jero is now known as Guest45935 | ||
| mup | PR snapd#4173 opened: corecfg: validate refresh.schedule when it is applied <Created by mvo5> <https://github.com/snapcore/snapd/pull/4173> | 09:51 |
| zyga-ubuntu | mvo: removed where? ^^ | 09:54 |
| zyga-ubuntu | mvo: you said that we did this in the test suite | 09:55 |
| zyga-ubuntu | and that you removed that now | 09:55 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| mborzecki | zyga-ubuntu: added some comments to #4163 | 09:58 |
| mup | PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163> | 09:58 |
| zyga-ubuntu | mborzecki: thank you | 09:59 |
| mvo | zyga-ubuntu: ups, sorry, forgot to push that commit, will do so in a sec | 10:00 |
| mborzecki | 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 |
| mvo | zyga-ubuntu: force pushed, sorry but I also forgot to add the header to corecfg.go | 10:01 |
| pedronis | mvo: what's the schedule for edge builds atm ? | 10:06 |
| mvo | pedronis: its broken right now, its supposed to happen after merges to master that have a green test | 10:12 |
| pedronis | heh | 10:12 |
| pedronis | is that spread-cron, or something else? | 10:13 |
| mvo | pedronis: yes, spread cron | 10:13 |
| pedronis | :( | 10:13 |
| mvo | pedronis: I triggered it manually this morning so we should have a proper edge soon | 10:13 |
| mvo | but that is not a soluation of course | 10:14 |
| mvo | solution even | 10:14 |
| pedronis | mvo: after or before the proxy.store= merge ? | 10:14 |
| mvo | pedronis: I think after, this merged happend last night, right? | 10:14 |
| pedronis | mvo: no, you merged it this morning I think | 10:15 |
| * kalikiana coffee | 10:15 | |
| zyga-ubuntu | mborzecki: yeah, I'm adding tests | 10:16 |
| zyga-ubuntu | mvo: thanks :) | 10:16 |
| mvo | pedronis: hm, let me double check then | 10:17 |
| mvo | zyga-ubuntu: thank you! | 10:17 |
| mvo | pedronis: according to launchpad it is in | 10:17 |
| pedronis | ok | 10:28 |
| zyga-ubuntu | mborzecki: pushed with some updates, thank you for spotting that | 10:31 |
| mborzecki | zyga-ubuntu: similar thing with secureMkFile | 10:32 |
| mborzecki | but I think you can bail out there early by checking if the path does not end with / | 10:32 |
| zyga-ubuntu | mborzecki: or just is "/", yeah | 10:33 |
| zyga-ubuntu | mborzecki: I decided not to bail but instead check length around critical places | 10:33 |
| mborzecki | just checking / will not cover a path like /foo/bar/ | 10:33 |
| zyga-ubuntu | mborzecki: this works just as fine and has lower coverage impact | 10:33 |
| zyga-ubuntu | mborzecki: I mean check if the actual full path is exactly "/" | 10:34 |
| pedronis | 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 |
| mborzecki | zyga-ubuntu: uhh, yeah, i meant for secureMkFile you'll probably need to check if the path does not end with / | 10:36 |
| zyga-ubuntu | mborzecki: we do filepath.Clean on that | 10:37 |
| zyga-ubuntu | it will chop off the final / | 10:37 |
| zyga-ubuntu | it's a bit tricky, I agree | 10:37 |
| zyga-ubuntu | mborzecki: I'll look at mkfile now | 10:37 |
| zyga-ubuntu | mborzecki: I think for mkfile we should error if name ends with "/" | 10:38 |
| mborzecki | yup | 10:38 |
| mvo | 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:38 |
| mvo | pedronis: I fix it | 10:39 |
| zyga-ubuntu | mvo: and perhaps this can explain random failures (some of them) | 10:39 |
| zyga-ubuntu | where we just refresh | 10:39 |
| mvo | zyga-ubuntu: definitely | 10:39 |
| zyga-ubuntu | mborzecki: updated and pushed https://github.com/snapcore/snapd/pull/4169 | 11:07 |
| mup | PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169> | 11:07 |
| zyga-ubuntu | mborzecki: In the end I rebased because somehow the merge was messy | 11:07 |
| mborzecki | ok | 11:07 |
| zyga-ubuntu | mborzecki: so please look at https://github.com/snapcore/snapd/pull/4169/commits/08d3ed6f54de26a7e671b58453044baebf591e1d | 11:07 |
| mborzecki | zyga-ubuntu: sorry for poking your reviews :) it's just that you have so many of them | 11:08 |
| zyga-ubuntu | mborzecki: thank you :-D I cannot be happier really | 11:10 |
| zyga-ubuntu | usually we beg for reviews | 11:10 |
| mup | PR snapd#4162 closed: interfaces/kmod: treat failure to load module as non-fatal <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4162> | 11:11 |
| zyga-ubuntu | mborzecki: https://github.com/snapcore/snapd/pull/4166 is trivial | 11:13 |
| mup | PR #4166: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/4166> | 11:13 |
| zyga-ubuntu | just https://github.com/snapcore/snapd/pull/4166/commits/c21a85a15c923a5935d5374fe76c29463030c588 on top of other PRs | 11:13 |
| mborzecki | i'm look at it right now | 11:13 |
| zyga-ubuntu | (I have a similar one, unpushed, for mkfile) | 11:13 |
| zyga-ubuntu | 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 |
| zyga-ubuntu | and with some luck, it will all fall into place and "just work" | 11:14 |
| zyga-ubuntu | 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:15 |
| mborzecki | 4170 is part of this work too? | 11:16 |
| zyga-ubuntu | yes | 11:16 |
| zyga-ubuntu | that's the "main" element in many ways | 11:16 |
| zyga-ubuntu | everything else is to make that part work | 11:16 |
| niemeyer | o/ | 11:21 |
| mborzecki | 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 |
| zyga-ubuntu | mborzecki: exactly | 11:22 |
| mborzecki | niemeyer: hi | 11:22 |
| zyga-ubuntu | hey niemeyer | 11:22 |
| pstolowski | hi niemeyer | 11:24 |
| zyga-ubuntu | Pharaoh_Atem: hey, did you see https://bugzilla.redhat.com/show_bug.cgi?id=1509586 | 11:27 |
| zyga-ubuntu | I don't have F27 around | 11:28 |
| niemeyer | Hey there | 11:29 |
| * zyga-ubuntu -> break | 11:35 | |
| pstolowski | pedronis, do you have a moment for HO? | 11:42 |
| mborzecki | https://travis-ci.org/snapcore/snapd/builds/299009217 hit travis timeout, should i restart? | 11:46 |
| zyga-ubuntu | yes | 11:50 |
| zyga-ubuntu | ok, I really want to break now | 12:01 |
| zyga-ubuntu | see you at the call | 12:01 |
| mvo | pedronis: fwiw, core in edge should be up-to-date now | 12:07 |
| mvo | 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 |
| mvo | in udev afaict | 12:18 |
| mup | PR #4171: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171> | 12:18 |
| mup | PR snapd#4174 opened: packaging/arch: packaging update <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4174> | 12:21 |
| mup | PR snapcraft#1648 closed: sources: get svn revision with --show-item flag <bug> <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1648> | 12:23 |
| pedronis | Chipaca: hi, I do plan to look at your aliases PR today or tomorrow | 12:37 |
| niemeyer | jdstrand: Related to our conversation around user ids and daemon: | 12:45 |
| niemeyer | https://github.com/snapcore/snapd/pull/4135/files#diff-be7cfe1e5aff69d70d80b1c2cabcaaccL749 | 12:45 |
| mup | PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 12:45 |
| sergiusens | kalikiana mind looking into my comment on snapcraft#1633 ? | 12:47 |
| mup | PR snapcraft#1633: recording: record information from the image in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633> | 12:47 |
| jdstrand | niemeyer: hey, yeah I saw that and thought the same thing | 12:48 |
| jdstrand | mvo: there are kernel controls for /dev/mem | 12:48 |
| jdstrand | mvo, cachio: our kernels are configured with STRICT_DEVMEM. see interfaces/builtin/physical_memory_control.go for details | 12:51 |
| * zyga-ubuntu just read a PR title as "add support for soviet activation" | 12:52 | |
| jdstrand | zyga-ubuntu: I don't know if I should laugh or give you a hug :) | 12:57 |
| zyga-ubuntu | jdstrand: SOVIETS TRIGGERED! | 12:59 |
| jdstrand | heh | 13:00 |
| zyga-ubuntu | jdstrand: I pushed updates to udev tagging for hooks | 13:10 |
| zyga-ubuntu | jdstrand: I'm running spread locally now to see if I broke something | 13:10 |
| zyga-ubuntu | jdstrand: sorting by tag is actually a pretty nice idea | 13:12 |
| zyga-ubuntu | jdstrand: I also added a comment that says # iface so that we know which interface added the rule | 13:12 |
| zyga-ubuntu | jdstrand: have a look if you have time | 13:12 |
| popey | Can someone please review my alias request? https://forum.snapcraft.io/t/alias-request-for-mgba/2710 | 13:16 |
| mvo | 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 |
| mvo | jdstrand: if you need to look it up, no worries, I can do this too :) just wondering if you know without research | 13:20 |
| jdstrand | zyga-ubuntu: awesome, thanks! | 13:28 |
| zyga-ubuntu | jdstrand: I think some spread tests fail but they are probably (probably) just too picky and grep for detailed strings | 13:30 |
| zyga-ubuntu | I'll fix those soon | 13:30 |
| zyga-ubuntu | (well, fixing now) | 13:30 |
| jdstrand | popey: I planned to today (note, 1 week hasn't gone by yet) | 13:30 |
| popey | ok :) | 13:31 |
| mup | PR snapcraft#1720 opened: kernel plugin: introduce kernel-channel to select from which channel … <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1720> | 13:47 |
| zyga-ubuntu | Son_Goku: I'm installing gnome desktop on centos now, I can try your EPEL package soon | 13:48 |
| Son_Goku | zyga-ubuntu: okay, cool | 13:48 |
| zyga-ubuntu | Son_Goku: I forgot how to use yum :) | 13:48 |
| Son_Goku | heh | 13:48 |
| zyga-ubuntu | Son_Goku: is there a nice way to meta-install the desktop | 13:48 |
| Son_Goku | there's a DNF for CentOS 7 | 13:48 |
| zyga-ubuntu | oh? it's not installed by default | 13:48 |
| zyga-ubuntu | I'm on centos 7 for sure | 13:49 |
| Son_Goku | https://seven.centos.org/2017/10/yum-4-is-available-for-testing/ | 13:49 |
| zyga-ubuntu | yum or dnf? | 13:49 |
| Son_Goku | yum 4 == dnf | 13:49 |
| zyga-ubuntu | ah | 13:49 |
| zyga-ubuntu | but is the CLI the same? | 13:50 |
| Son_Goku | Yep | 13:50 |
| Son_Goku | yum4 is a symlink to /usr/bin/dnf | 13:50 |
| Son_Goku | in Fedora, this is the "dnf-yum" package | 13:50 |
| Son_Goku | zyga-ubuntu: so once that's installed, you can use dnf as normal | 13:53 |
| mup | PR snapcraft#1655 closed: lxd: distinguish argless clean from clean -s pull <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1655> | 13:57 |
| diddledan | the build service is refusing to let me login again | 13:58 |
| diddledan | refusing my launchpad oauth token | 13:58 |
| diddledan | "Error:Invalid association handle" | 13:59 |
| diddledan | hmm, maybe it's specific to firefox (I have ublock origin installed, which might be conflicting) | 14:02 |
| zyga-ubuntu | jdstrand: oh, drat | 14:06 |
| zyga-ubuntu | jdstrand: my bad | 14:06 |
| zyga-ubuntu | jdstrand: KERNEL=="foo", TAG+="bar" # this is a comment | 14:06 |
| zyga-ubuntu | this is not valid | 14:06 |
| zyga-ubuntu | udev, man... really? | 14:06 |
| zyga-ubuntu | I need to change that to | 14:06 |
| zyga-ubuntu | # this is a comment | 14:07 |
| jdstrand | heh, yeah. it seems pretty finicky | 14:09 |
| kalikiana | 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:09 |
| kalikiana | 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:11 |
| diddledan | flexiondotorg: or popey: the build service has lost the store-name references for inadyn, opentyrian, and warzone2100 from the snapcrafters repositories | 14:14 |
| popey | que? | 14:14 |
| diddledan | https://usercontent.irccloud-cdn.com/file/sJAYGe5k/Screenshot%20from%202017-11-08%2014-14-40.png | 14:15 |
| popey | huh | 14:16 |
| popey | thats odd | 14:16 |
| zyga-ubuntu | jdstrand: I'm considering dropping the # iface comment | 14:16 |
| popey | fixed warzone2100 | 14:17 |
| zyga-ubuntu | jdstrand: unless you think strongly we should keep it | 14:17 |
| diddledan | 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 |
| zyga-ubuntu | it's just a hassle, I really hoped udev would suck less at parsing | 14:17 |
| jdstrand | zyga-ubuntu: it would be nice, but I don't think it is strictly required | 14:17 |
| popey | thats plausible | 14:17 |
| popey | diddledan: fixed all three, they're all building now | 14:17 |
| diddledan | thankyou :-) | 14:18 |
| popey | np | 14:18 |
| popey | in other news. diddledan would you like to be a collaborator on these snaps? | 14:18 |
| diddledan | I was trying to force a build so they get i386 versions when I spotted it :-) | 14:18 |
| popey | so you can help manage them in the store? | 14:18 |
| jdstrand | zyga-ubuntu: I wonder if you could do # comment\nKERNEL==... for the first string... | 14:18 |
| mvo | jdstrand: sorry, I had various laptop problems | 14:18 |
| jdstrand | not super pretty | 14:18 |
| diddledan | sure :D | 14:19 |
| mvo | jdstrand: did you write anything after I asked about STRICT_DEVMEM? | 14:19 |
| jdstrand | mvo: no. I don't know of anything else otoh | 14:19 |
| popey | ok, what email address should I add you as? | 14:19 |
| diddledan | my launchpad is diddledan, I think that's pointing at daniel@bowlhat.net | 14:19 |
| mvo | 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 |
| diddledan | alternatively diddledan@gmail will work | 14:20 |
| mvo | 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 | |
| jdstrand | mvo: yeah, I don't know otoh | 14:20 |
| popey | which one do you sso with? | 14:20 |
| mvo | jdstrand: ta | 14:20 |
| diddledan | I try to sso with daniel@bowlhat.net | 14:20 |
| popey | ok | 14:21 |
| popey | will add you a bit later. | 14:21 |
| diddledan | ta | 14:21 |
| zyga-ubuntu | ok, soup time, I'll get back to udev shortly | 14:22 |
| jdstrand | mvo: did you come up with a kmod test? I thought of one that we could use on core | 14:24 |
| mvo | jdstrand: I just wrote a unit test, I was not thinking about a kmod spread test so far | 14:25 |
| jdstrand | mvo: ok. I'll try a spread test soonish | 14:25 |
| mvo | thanks | 14:26 |
| mup | PR snapd#4135 closed: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 14:31 |
| mup | PR snapd#4175 opened: dirs: use alt root when checking classic confinement support without … <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4175> | 14:36 |
| cachio_ | niemeyer, partially fixed the issue on spread-cron | 14:47 |
| cachio_ | niemeyer, I'll add a PR to fix the problem | 14:47 |
| cachio_ | basically, it is failing when there are conflicts on the branches, and that be caused because a change we do and push | 14:48 |
| sergiusens | kalikiana well the json in a yaml thing is just not nice; pseudo json I even. | 14:53 |
| kalikiana | sergiusens: right. I'm trying to figure out if we can force the style | 14:54 |
| elopio | hey popey, how can I enable build.snapcraft.io for vault? | 14:55 |
| sergiusens | kalikiana if you just add the dict, the right thing will happen on unmarshalling | 14:55 |
| popey | elopio: just did it, building now | 14:55 |
| kalikiana | sergiusens: no it doesn't | 14:56 |
| kalikiana | It's already a dict | 14:56 |
| kalikiana | This is YAML | 14:56 |
| elopio | 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 |
| popey | elopio: pull requests against the yaml is the simplest thing | 14:57 |
| popey | preferable to push it upstream of course | 15:01 |
| zyga-ubuntu | re | 15:01 |
| elopio | popey: yeah, but for the ones that upstream doesn't want. Would you mind if I experiment with vault to do it automatically? | 15:05 |
| cachio_ | elopio, could you share the setup you have done for the autopcktests exec on snapcraft? | 15:16 |
| cachio_ | elopio, you are running agains a ppa right? | 15:17 |
| popey | elopio: sure | 15:25 |
| popey | elopio: flexiondotorg has some scripts to automate this too | 15:25 |
| sergiusens | kalikiana one comment on snapcraft#1412 | 15:26 |
| mup | PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412> | 15:26 |
| elopio | cachio_: https://github.com/snapcore/snapcraft/pull/1643 | 15:26 |
| mup | PR snapcraft#1643: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643> | 15:26 |
| sergiusens | 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:27 |
| cachio_ | elopio, tx | 15:29 |
| diddledan | 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:32 |
| diddledan | is there an environment variable to tell libc where to look for the locale folder? | 15:33 |
| Chipaca | diddledan: LOCALEDIR? | 15:38 |
| Chipaca | 'parently not | 15:39 |
| Chipaca | diddledan: dunno | 15:39 |
| zyga-ubuntu | WHYISITALLSODIFFICULT | 15:42 |
| zyga-ubuntu | I'm hoping that with layouts it's not going to be that hard | 15:42 |
| diddledan | when do we get layouts? :-p | 15:42 |
| * diddledan ducks | 15:43 | |
| Chipaca | diddledan: tomorrow, but only if you use layouts to override glibc's date functions | 15:43 |
| sergiusens | Chipaca careful, if someone makes glibc return dates after tomorrow you will be N days late ;-) | 15:44 |
| Chipaca | sergiusens: or early! | 15:44 |
| Chipaca | sergiusens: in fact, given that we're closer to 2038 than to 1970, on average i'll be early _anyway_! | 15:45 |
| * zyga-ubuntu does the right thing wrt udev | 15:45 | |
| zyga-ubuntu | even if painful | 15:45 |
| * Chipaca does the wrong things wrt everything else because he can blame pain meds | 15:46 | |
| zyga-ubuntu | ha | 15:46 |
| zyga-ubuntu | I need some :( | 15:46 |
| zyga-ubuntu | I forgot about that | 15:46 |
| sergiusens | kalikiana wrt to that yaml thing; a dict that is yaml dumped should produce proper yaml, unless the thing that is json loaded is interpreted as a string in itself | 15:46 |
| zyga-ubuntu | I almost never take painkillers as they make me numb :( | 15:47 |
| kalikiana | sergiusens: it is YAML :-) | 15:47 |
| sergiusens | Chipaca that is kind of like blaming bad behavior on alcohol :-) | 15:47 |
| Chipaca | sergiusens: darn | 15:47 |
| kalikiana | sergiusens: I'm trying to find a way to switch the syntax to multi-line in any case | 15:48 |
| sergiusens | kalikiana oh, I thought we had code for that in the loader thing already | 15:48 |
| sergiusens | kalikiana try http://paste.ubuntu.com/25918524/ | 15:51 |
| zyga-ubuntu | jdstrand: about that | 15:51 |
| zyga-ubuntu | jdstrand: gpio has a new /dev based API | 15:51 |
| zyga-ubuntu | jdstrand: we need to tweak the interface for that | 15:51 |
| zyga-ubuntu | there are ioctls and /dev/gpiochip entries for each controller | 15:52 |
| zyga-ubuntu | and the sysfs interface gets depracated (slowly) | 15:52 |
| jdstrand | happy to review that PR (I don't have hardware to implement that so would be best if someone who could test with real hardware could implement it) | 15:53 |
| zyga-ubuntu | gladly :) | 15:53 |
| kalikiana | sergiusens: Oh nice! Thanks! Was staring at why this didn't seem to work at first, turns out it also makes architectures a list. But actually it makes everything consistent. | 16:05 |
| kalikiana | pushed | 16:08 |
| kalikiana | need to get some food into my stomach, back in a bit | 16:09 |
| zyga-ubuntu | jdstrand: there, I retained all the comments | 16:14 |
| zyga-ubuntu | spread is running now, fingers croessed | 16:14 |
| zyga-ubuntu | jdstrand: man I wish we had https://github.com/snapcore/snapd/pull/4157 merged already | 16:15 |
| mup | PR #4157: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157> | 16:15 |
| zyga-ubuntu | niemeyer, jdstrand: interesting stuff here on lwn: https://lwn.net/Articles/738306/ - we could use the same idea for persistent identifiers of hot-plug usb devices | 16:20 |
| zyga-ubuntu | I'll break now, kids home, I'll check back and garden my PRs | 16:20 |
| zyga-ubuntu | I plan to send one more feature PR today, with changes-needed patch that enables tmpfs to work (and associated tests) | 16:21 |
| zyga-ubuntu | that will be two feature patches short of all the major bits, then enabling this and integration and final spread test (that already exists and just has a path disabled) to show it works | 16:21 |
| zyga-ubuntu | then reality will show where I was wrong :) | 16:21 |
| zyga-ubuntu | but that's what I'm here for | 16:21 |
| popey | elopio: i dont understand your nba-go - did you patch it? I absolutely can't get it to build. you using new snapcraft or something? | 16:24 |
| popey | elopio: i am on 2.34 from candidate | 16:25 |
| cachio_ | elopio, so, you run from a container in travis the autopkgtests | 16:27 |
| cachio_ | elopio, you are running against all the ubuntu releases right? | 16:28 |
| elopio | cachio_: no, that branch is only xenial. We will move it to nightly travis, so maybe we add more releases. | 16:33 |
| elopio | popey: I'm using snapcraft from source, but what gets installed in the container is the latest snapcraft deb. | 16:34 |
| popey | i dont understand, your branch builds, but if i just copy your yaml to an empty dir and source upstream it fails | 16:34 |
| elopio | popey: ah, maybe submodules? | 16:34 |
| elopio | no, doesn't look like it. | 16:35 |
| elopio | let me try that way. | 16:35 |
| mup | PR snapd#4176 opened: cmd: fix re-exec bug with classic confinement for host snapd < 2.28 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4176> | 16:37 |
| Chipaca | niemeyer: 15pm -> 3pm in https://forum.snapcraft.io/t/1239/6 | 16:37 |
| niemeyer | Chipaca: Oops, thanks | 16:37 |
| kyrofa | kalikiana, do you have an rpi handy? | 16:44 |
| kyrofa | (or any other arch, really) | 16:44 |
| kyrofa | We need to make sure cleanbuilding with a remote still works in snapcraft#1718 | 16:45 |
| mup | PR snapcraft#1718: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718> | 16:45 |
| kyrofa | Remote of another arch, specifically | 16:45 |
| elopio | popey: yeah, you are not crazy. This only works from a fork, no idea why. | 16:46 |
| kalikiana | kyrofa: I have only amd64 and i386 servers | 16:46 |
| kyrofa | i386 will do | 16:46 |
| popey | hah | 16:46 |
| kalikiana | kyrofa: I didn't stress test it yet since I wanted to know that we agree on the code. I'm still finding the string splitting rather ugly... | 16:47 |
| kyrofa | kalikiana, well, before we were doing the same thing, but pretending it was YAML, right? | 16:48 |
| elopio | popey: would you mind reporting a snapcraft bug? It could be that we are not installing the devDependencies for some reason. Or I don't know, this is weird, it needs debugging. | 16:48 |
| kyrofa | It's not, so I'm not sure there's a better solution | 16:48 |
| popey | elopio: where should i file that? | 16:48 |
| mup | PR snapd#4177 opened: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177> | 16:49 |
| kalikiana | kyrofa: well, it parsed as YAML... are you saying it might stop working? | 16:49 |
| kyrofa | kalikiana, it could very well. It's definitely not dumped as YAML | 16:50 |
| kyrofa | Seems dangerous to parse something as YAML that we know for a fact is not YAML | 16:50 |
| kalikiana | kyrofa: Maybe stgraber should weigh in here actually | 16:50 |
| pstolowski | pedronis, ^ can you take a look at #4177? I found your suggestion cleaner than an alternative I mentioned in the standup | 16:51 |
| mup | PR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177> | 16:51 |
| kyrofa | Yeah stgraber, why u no yaml? | 16:51 |
| nacc | kyrofa: funny that you typed out why but not you | 16:51 |
| kyrofa | Dangit | 16:51 |
| nacc | just wasting bits! | 16:51 |
| kyrofa | nacc, I'll admit, even typing 'u' was hard | 16:52 |
| nacc | heh | 16:52 |
| popey | elopio: https://bugs.launchpad.net/snapcraft/+bug/1731003 | 16:54 |
| mup | Bug #1731003: node app builds forked, but not referencing upstream source <Snapcraft:New> <https://launchpad.net/bugs/1731003> | 16:54 |
| pedronis | pstolowski: yes, that looks like what I had in mind | 16:55 |
| zyga-ubuntu | mvo: wow | 16:56 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/4176/files | 16:56 |
| mup | PR #4176: cmd: fix re-exec bug with classic confinement for host snapd < 2.28 <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4176> | 16:56 |
| cachio_ | elopio, you trigger the execution and where do you see the results? | 17:00 |
| pedronis | pstolowski: that's probably a useful helper anyway but what was the problem with your other approach? | 17:00 |
| cachio_ | elopio, in the build history? | 17:01 |
| pstolowski | pedronis, I stored ID of last task to wait in context (initially it was hook's task ID, then if you queued another command, it would be that command's task ID and so on. problem was servicestate.Control (and cmdstate.Exec) gives taskset | 17:05 |
| pedronis | pstolowski: there's also a problem though that we should be waited by what was waiting for the tasks | 17:06 |
| pedronis | sorry, | 17:06 |
| pedronis | s/tasks/the configure hook task/ | 17:06 |
| elopio | cachio_: travis sends an email when the nightly fails. | 17:07 |
| pedronis | pstolowski: there's also WaitTasks and HaltTasks on tasks to follow that btw, not sure if you knew those already | 17:07 |
| elopio | popey: flexiondotorg: what do you think about this? https://github.com/snapcrafters/vault/pull/3/files | 17:07 |
| mup | PR snapcrafters/vault#3: Build the latest unreleased tag <Created by elopio> <https://github.com/snapcrafters/vault/pull/3> | 17:07 |
| elopio | (I'm kind of proud of it, so be nice :) | 17:08 |
| pstolowski | pedronis, hmm, yeah I knew of them, but it didn't occur to me, WaitTasks can be useful indeed | 17:10 |
| === CodeMouse92 is now known as CodeMouse92__ | ||
| pstolowski | elopio, I like how you motivate reviewers, and hi btw :) | 17:12 |
| pedronis | pstolowski: tbh I'm not quite sure how important it is to serialize the restarts vs what comes after the configure | 17:12 |
| pstolowski | pedronis, what's the question/concern? | 17:15 |
| elopio | pstolowski: hello :) | 17:16 |
| pedronis | pstolowski: should we wait the stop/start/restart before doing anything that was waiting on configure itself | 17:19 |
| pedronis | that's the question | 17:19 |
| kyrofa | Hey niemeyer, any progress on the LXC issues? https://forum.snapcraft.io/t/lxc-error-when-updating-snap-and-cleaning-old-revisions/786/34 | 17:23 |
| zyga-ubuntu | jdstrand: hey, udev tagging for hooks works :) | 17:24 |
| pstolowski | pedronis, configure is the last task, there is nothing strictly waiting for it | 17:26 |
| kyrofa | elopio, any idea what's happening here? https://travis-ci.org/snapcore/snapcraft/jobs/299061202 | 17:27 |
| pedronis | pstolowski: that is not true in some complex refresh cases | 17:27 |
| pedronis | if I remember correctly | 17:27 |
| zyga-ubuntu | kyrofa: hey, no progress from me yet :-( I only reproduced it and didn't try to fix it | 17:28 |
| zyga-ubuntu | kyrofa: sorry, too many things burning/working on at the same time | 17:28 |
| pedronis | pstolowski: at the moment I think is probably fine not to worry, but it's a question | 17:28 |
| kyrofa | zyga-ubuntu, right, niemeyer mentioned someone else would work on it | 17:28 |
| pedronis | pstolowski: if you look at doUpdate, you'll see that sometimes if attach more tasks after the doInstall ones | 17:29 |
| pedronis | s/if attach/we attach/ | 17:29 |
| * zyga-ubuntu installs a new home router | 17:29 | |
| zyga-ubuntu | well, helper router | 17:29 |
| zyga-ubuntu | and new as in "junk people threw out" | 17:29 |
| kyrofa | I sorta feel like the lxc issue falls into the "make things work before working on new features" but I guess that's just me | 17:30 |
| zyga-ubuntu | kyrofa: yes, I agree; we had some of that recently | 17:30 |
| * zyga-ubuntu looks at udev | 17:30 | |
| zyga-ubuntu | kyrofa: I honestly think that we don't use lxc enough in the team to be burned by this; but I agree we should fix it as lxc is an important use-case | 17:31 |
| kyrofa | zyga-ubuntu, yeah I keep hearing that :) | 17:31 |
| pedronis | kyrofa: is it lxc or lxd ? | 17:31 |
| kyrofa | pedronis, lxd | 17:31 |
| kyrofa | pedronis, snaps only update three times before they never update again | 17:32 |
| mup | PR snapd#4178 opened: asserts/assertstest: fix use of hardcoded value when the passed or default keys should be used <Created by pedronis> <https://github.com/snapcore/snapd/pull/4178> | 17:32 |
| pstolowski | pedronis, ah, I see what you mean. when waiting for configure's hook task, the remaining tasks that may potentially be waiting for configure will not be waiting on us, we essentially insert new tasks in the middle | 17:32 |
| pedronis | pstolowski: as I said, I don't think is a problem atm, but I don't know if that will stay true | 17:33 |
| pstolowski | pedronis, if that ever becomes true, we will need a proper "run-queued-services" task that sits in the sequence i guess | 17:34 |
| * zyga-ubuntu EODs, goes to tweak home networking to merge two networks into one | 17:36 | |
| mvo | zyga-ubuntu: yes :( | 17:38 |
| mvo | zyga-ubuntu: sorry for the delay, had dinner | 17:38 |
| mup | PR snapd#4179 opened: tests: add a spread test for proxy.store setting together with store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4179> | 17:39 |
| kalikiana | sergiusens: updated snapcraft#1412 as per your suggestion | 17:44 |
| mup | PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412> | 17:44 |
| kalikiana | going to wrap up shortly | 17:44 |
| === cachio_ is now known as cachio__afk | ||
| zyga-ubuntu | mvo: no worries, thank you for finding and fixing that | 17:47 |
| zyga-ubuntu | mvo: I'm mentally drained now so I'll refrain from complex work | 17:47 |
| zyga-ubuntu | mvo: any releases today/ | 17:47 |
| mvo | zyga-ubuntu: no release, I will push 2.29.3 tomorrow in my morning | 17:48 |
| zyga-ubuntu | mvo: which of those do you plan to merge: https://github.com/snapcore/snapd/milestone/14 | 17:48 |
| mup | PR snapd#4180 opened: interfaces/many: misc policy updates for browser-support, cups-control and network-status <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4180> | 17:51 |
| mup | PR snapd#4181 opened: interfaces/many: misc policy updates for browser-support, cups-control and network-status (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4181> | 17:54 |
| mvo | zyga-ubuntu: I need to look at them with a fresh mind, maybe/probably all | 17:55 |
| jdstrand | mvo: hey, for your consideration, PR #4181. it is not a regression. it would help mailspring and some other high profile electron snaps | 17:56 |
| mup | PR #4181: interfaces/many: misc policy updates for browser-support, cups-control and network-status (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4181> | 17:56 |
| mvo | jdstrand: looking | 17:57 |
| jdstrand | a regression fix* | 17:57 |
| jdstrand | mvo: the two other denial are not important for 2.29, but cachio__afk I think would appreciate one, and ogra_ the other | 17:57 |
| jdstrand | s/denial/denial fixes/ | 17:57 |
| mvo | jdstrand: thanks, looks fine | 17:58 |
| mvo | cachio__afk: some more validation work tomorrow for 2.29.3 :/ | 17:58 |
| zyga-ubuntu | man, we have 46PRs | 17:59 |
| jdstrand | mvo: thanks. from mailspring upstream: "How long will it take for the policy change to reach the stable channel? I’d love to ship the Mailspring snap (I’m actually getting a couple emails / tweets a day about it because I said it was coming soon on the website ) but I should probably wait until a fix for this is in the wild." | 17:59 |
| jdstrand | mvo (cachio__afk): in other words, they will appreciate the effort | 18:00 |
| Chipaca | ttfn | 18:00 |
| mvo | jdstrand: we aim for Monday | 18:01 |
| mvo | jdstrand: and yeah, looks like a no-brainer, will pull it in | 18:01 |
| pedronis | zyga-ubuntu: close to needing us to declare a review sprint | 18:01 |
| zyga-ubuntu | yes | 18:01 |
| zyga-ubuntu | I was just thinking about that | 18:01 |
| jdstrand | mvo: there is one more mpris denial I need to look at for popey. I don't know if that will turn into a PR but will try to get it in place (if needed) today | 18:03 |
| jdstrand | mvo: the forum has been keeping my (and us!) busy! | 18:03 |
| jdstrand | s/my/me/ | 18:03 |
| mvo | jdstrand: yeah, if you can get it done in (your) day, I can look at it in (my) tomorrow monring :) | 18:03 |
| mvo | jdstrand: in ~12h | 18:03 |
| * jdstrand nods | 18:03 | |
| jdstrand | yep | 18:03 |
| mvo | jdstrand: $everything is keeping me busy :( | 18:03 |
| jdstrand | that one shouldn't take too long to chase down | 18:03 |
| jdstrand | mvo: heh, yeah, I bet | 18:04 |
| pedronis | zyga-ubuntu: I don't have immediate new feature coding to do, I need to go explore/analyze some things, I can also do reviews over the next few days | 18:04 |
| mvo | jdstrand: but lots of good stuff! | 18:04 |
| mvo | I will also do more reviews! | 18:04 |
| zyga-ubuntu | pedronis: thank you! | 18:04 |
| zyga-ubuntu | mvo: I think we need to really fix the lxc issue | 18:04 |
| * mvo does the pinkey swear | 18:04 | |
| mvo | zyga-ubuntu: which one? the one in the forum? | 18:05 |
| zyga-ubuntu | mvo: I'll break feature coding while I wait for reviews and I'll focus on that tomorrow | 18:05 |
| zyga-ubuntu | kyrofa: all of my tomorrow I'll look at LX[cd] | 18:05 |
| kyrofa | Thank you zyga-ubuntu, I appreciate that | 18:05 |
| mvo | zyga-ubuntu: what lxc issue is that? sorry for being a bit slow | 18:06 |
| pedronis | mvo: https://forum.snapcraft.io/t/lxc-snaps-dont-update/786 I think | 18:06 |
| zyga-ubuntu | mvo: refreshes inside containers break due to mount event ordering and special /snap sharing change | 18:06 |
| pedronis | it's a long topic, been around since a while | 18:06 |
| zyga-ubuntu | mvo: somewhat related to 14.04 | 18:06 |
| zyga-ubuntu | mvo: where simiar special sharing applies | 18:07 |
| pedronis | didn't we fix something about order in 14.04 recently though? | 18:07 |
| pedronis | rewriting units? | 18:07 |
| zyga-ubuntu | pedronis: yes but that is different | 18:07 |
| zyga-ubuntu | pedronis: we didn't rewrite on-disk units so that's still a todo | 18:07 |
| pedronis | ah | 18:07 |
| pedronis | do we have it somewhere? | 18:07 |
| pedronis | on the forum? | 18:07 |
| zyga-ubuntu | pedronis: here the lxd issue is really the mount events are in wrong order and this needs some love | 18:07 |
| pedronis | in a bug? | 18:07 |
| zyga-ubuntu | https://forum.snapcraft.io/t/lxc-snaps-dont-update/786/36 | 18:08 |
| mvo | zyga-ubuntu: thats not a regression, right? | 18:08 |
| pedronis | no, the other issue, the rewrite units | 18:08 |
| pedronis | mvo: no, it's been terrible for a long while ;) | 18:08 |
| zyga-ubuntu | mvo: "doctor help, the patient is dying", "is it a regression?" ;D | 18:08 |
| zyga-ubuntu | mvo: technically no | 18:08 |
| mvo | zyga-ubuntu: *pfff* | 18:08 |
| mvo | zyga-ubuntu: ;) | 18:08 |
| zyga-ubuntu | mvo: but I love your release-manager approach :) | 18:08 |
| zyga-ubuntu | being very focused on making the release work more and not less | 18:09 |
| * zyga-ubuntu hugs mvo for being so fantastic | 18:09 | |
| mvo | zyga-ubuntu, pedronis well, you guys know where the term "triage" comes from, right? | 18:09 |
| jdstrand | zyga-ubuntu: re udev tagging for hooks> \o/ | 18:09 |
| pedronis | mvo: do we do it? | 18:09 |
| zyga-ubuntu | mvo: actually, I don't know | 18:09 |
| mvo | pedronis: *cough* | 18:09 |
| pedronis | anyway me needs to eod/have dinner | 18:09 |
| zyga-ubuntu | jdstrand: 2.29 variant is the one without sorting changes | 18:09 |
| mvo | zyga-ubuntu: worth looking it up, it comes from the medical triage of patients, i.e. treat the ones that need urgent attention first | 18:10 |
| * zyga-ubuntu looks that up | 18:10 | |
| mvo | zyga-ubuntu: but conversely (in the worst case) don't spend time on something where there is no hope | 18:10 |
| zyga-ubuntu | mvo: oh, that's an interesting concept | 18:10 |
| zyga-ubuntu | do we tell the patient when that happens? | 18:11 |
| mvo | zyga-ubuntu: *cough* | 18:11 |
| mvo | zyga-ubuntu: or better *shhhh* ;) | 18:11 |
| zyga-ubuntu | https://commons.wikimedia.org/wiki/File:Deconference-2002-triage-tag.jpg | 18:11 |
| jdstrand | zyga-ubuntu (cc niemeyer): re https://lwn.net/Articles/738306/ (usbguard), this is actually on the security team's radar. It isn't bug free though. note that it isn't actually useful for snappy since the usb authorization system in the kernel is boolean, not application specific | 18:11 |
| jdstrand | zyga-ubuntu (cc niemeyer): however, the idea of hooking into the kernel's uevent stream like usbguard does is absolutely something we'll want to do | 18:11 |
| zyga-ubuntu | jdstrand: I was merely thinking about the "fingerprinting" logic where we could have stable-ish (more than now) identifiers for hotplug devices | 18:12 |
| zyga-ubuntu | jdstrand: yeah | 18:12 |
| zyga-ubuntu | jdstrand: I'd love to do implement that | 18:12 |
| jdstrand | zyga-ubuntu: if only the usbgurad fingerprinting worked well :\ | 18:12 |
| zyga-ubuntu | mvo: I like how the "minor: walking wounded" category is green | 18:12 |
| jdstrand | zyga-ubuntu: we can certainly look at it | 18:12 |
| mvo | zyga-ubuntu: but seriously, if you have a fix and if its easy enough that even I can understand it I'm happy to take it | 18:12 |
| mvo | zyga-ubuntu: lol | 18:12 |
| zyga-ubuntu | mvo: I don't have a fix but I was thinking about one that may be very simple | 18:13 |
| zyga-ubuntu | mvo: one-line simple, I'll try tomorrow | 18:13 |
| mvo | zyga-ubuntu: oh? woah | 18:13 |
| mvo | zyga-ubuntu: that would be lovely | 18:13 |
| jdstrand | zyga-ubuntu: eg, if I plug my mouse into different buses, it shows up differently to usbguard | 18:13 |
| zyga-ubuntu | jdstrand: yeah, it's not a trivial problem in any way | 18:13 |
| zyga-ubuntu | jdstrand: but trivial problems are solved by dpkg | 18:14 |
| jdstrand | anyway, let me get to mpris then back to look at pr #4144 | 18:14 |
| mup | PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144> | 18:14 |
| zyga-ubuntu | jdstrand: we are fixing interesting problems - | 18:14 |
| zyga-ubuntu | ;-) | 18:14 |
| jdstrand | :) | 18:14 |
| zyga-ubuntu | thanks :) | 18:14 |
| kyrofa | Yikes, github | 18:24 |
| zyga-ubuntu | ? | 18:26 |
| kyrofa | They're having javascript issues it seems | 18:28 |
| zyga-ubuntu | Son_Goku: I have centos 7 but too exhausted to play | 18:31 |
| zyga-ubuntu | Son_Goku: do some code reviews if you feel like jumping into layouts :) | 18:32 |
| kyrofa | Looks like he doesn't want to jump into layouts | 18:35 |
| zyga-ubuntu | kyrofa: or he jumped into layouts and is stuck in a namespace | 18:35 |
| kyrofa | Oooo, good one | 18:35 |
| Pharaoh_Atem | zyga-ubuntu: I hadn't seen the bug | 18:44 |
| Pharaoh_Atem | and HALP, stuck in namespace! | 18:44 |
| Pharaoh_Atem | :D | 18:44 |
| zyga-ubuntu | :-) | 18:45 |
| kyrofa | elopio, FYI, I'm looking at the Artful ruby errors. Want to make sure we aren't stepping on each other's toes | 18:46 |
| kyrofa | I'm also assuming we're not starting our nightly autopkgtest idea given that we're stilling waiting for stuff from the weekend | 18:47 |
| mvo | zyga-ubuntu: does 4146 (the 2.29 version) need cherry-picks from the changes that you did on the master version of this PR | 18:47 |
| sergiusens | kyrofa what do you feel about my comment on snapcraft#1633 | 18:49 |
| mup | PR snapcraft#1633: recording: record information from the image in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633> | 18:49 |
| kyrofa | sergiusens, raise a warning i.e. parse the output anyway? | 18:49 |
| kyrofa | sergiusens, I totally agree that something we know is not YAML should not be parsed as YAML | 18:50 |
| kyrofa | So yeah, I like the idea of trying to use --json, warning if it doesn't work, then falling back to processing the CLI output, but not with a YAML processor | 18:51 |
| sergiusens | kyrofa no, if you do --format=json and it is not supported you would get an errno from the command | 18:51 |
| sergiusens | kyrofa I'd say, just not support it, period | 18:51 |
| kyrofa | Oh oh, this is recording | 18:51 |
| sergiusens | yes, this is recording | 18:52 |
| kyrofa | sergiusens, sorry, we're having this exact same discussion on another PR :P | 18:52 |
| kyrofa | Well, almost | 18:52 |
| kyrofa | sergiusens, yes, I agree | 18:52 |
| elopio | kyrofa: I am debugging the autopkgtest on travis error. Not yet ready to land. | 18:54 |
| sergiusens | kyrofa I know about the other PR, I just want to wrap up this recording thing; elopio want to close that one up with the latest comments? | 18:54 |
| elopio | thanks for looking into ruby. This is the segfault, right? | 18:54 |
| kyrofa | elopio, indeed | 18:54 |
| sergiusens | kyrofa elopio decided to just continue landing things if they made sense and thoroughly tested | 18:55 |
| kyrofa | sergiusens, fair enough. It's either that or kinda sit on our hands | 18:55 |
| kyrofa | I need to refresh my memory for how to run our adt suite in lxc | 18:56 |
| kyrofa | We can start doing that | 18:56 |
| elopio | sergiusens: I agree with the --json thing. I will revert the change after lunch, and make sure that we don't crash if it fails. | 18:56 |
| elopio | sergiusens: ack. I'll update my branches so they are ready to land. Most of them require an autopkgtest run though :( | 18:57 |
| elopio | kyrofa: about that failed travis execution, the CLA fails because the email is private. Rebase with master, to no longer carry that commit. | 18:58 |
| kyrofa | elopio, what's confusing is that there are only two commits on that PR, mine and kalikiana's | 18:59 |
| kyrofa | I merged with master, we'll see what Travis says. I'll rebase if necessary | 18:59 |
| sergiusens | kyrofa running the suite and unit tests in lxd should be our default :-) | 18:59 |
| zyga-ubuntu | mvo: looking | 19:01 |
| kyrofa | sergiusens, think so? It's a bit more of a barrier to proposing something | 19:01 |
| zyga-ubuntu | mvo: the 2.29 version is older, subsequent changes to master version are cosmetic though | 19:01 |
| sergiusens | kyrofa for us, not others | 19:01 |
| zyga-ubuntu | mvo: so I'd say no, no changes needed | 19:01 |
| kyrofa | sergiusens elopio, alright, I'll start running the autopkgtests for some of the PRs up now. I'll comment on the ones I've tested | 19:12 |
| kyrofa | Although... elopio will it install squashfuse by any chance for the snapd tests? | 19:13 |
| kyrofa | Otherwise it'll just fail partway through | 19:13 |
| matiasb_ | sergiusens, elopio, o/ hey, when you get a few, any chance you can take another look at facundo's MP on metadata handling? https://github.com/snapcore/snapcraft/pull/1634 | 19:14 |
| mup | PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634> | 19:14 |
| === matiasb_ is now known as matiasb | ||
| elopio | kyrofa yes, squashfuse should be installed for the suites that install snaps | 19:19 |
| kyrofa | Whew, good | 19:19 |
| elopio | matiasb: sorry for the delay. We have been stuck on autopktest for too long. I'll take another look today | 19:20 |
| matiasb | elopio, np, just wanted to check it is in your radar, thx | 19:21 |
| === JoshStrobl is now known as JoshStrobl|Away | ||
| === cachio__afk is now known as cachio | ||
| cachio | jdstrand, nice, thanks, so the denials that I shared yesterday should be fixed with this PR, right? | 19:45 |
| jdstrand | cachio: yes | 19:49 |
| jdstrand | cachio: I mean, I didn't test it beyond the policy compile (I just took the connected slot rule and used the unconfined label), but yeah, it should work | 19:50 |
| cachio | jdstrand, great, tx | 19:51 |
| zyga-ubuntu | jdstrand: still fighting the mpris bug/ | 19:57 |
| mup | PR snapd#4175 closed: dirs: use alt root when checking classic confinement support without … <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4175> | 19:59 |
| mwhudson | kyrofa, kalikiana: "lxc info remote:" is real yaml, "lxc info container" is not | 20:12 |
| mwhudson | unfortunately it's the latter that is really needed | 20:12 |
| mwhudson | heh heh "curl --silent --unix-socket /var/lib/lxd/unix.socket http://a/1.0/containers/complete-amoeba | jq .metadata.architecture" works for the local remote... | 20:21 |
| jdstrand | zyga-ubuntu: I just finished | 20:26 |
| jdstrand | cachio: fyi, I mentioned to mvo that I might have a PR for mpris. I will not. no bug in snapd (afaics) | 20:26 |
| jdstrand | cachio: mentioning it to you since he is offline and this was potentially something extra for 2.29.3, which I know you are helping validate | 20:30 |
| * zyga-ubuntu had fun watching https://www.youtube.com/watch?v=M6xZZiaLOV4 | 20:36 | |
| kyrofa | elopio, can you explain why snapcraft seems to be running units in debug mode in adt, but not normally? | 20:47 |
| kyrofa | (getting a failure in master due to this) | 20:47 |
| cachio | jdstrand, perfect | 20:50 |
| cachio | jdstrand, about the read access to /dev/mem | 20:51 |
| cachio | how should I make to run to read in the allowed spaces | 20:52 |
| jdstrand | cachio: otoh, I'm not sure, but I think mvo was looking into it | 20:52 |
| elopio | kyrofa, do you mean with --debug? | 20:53 |
| kyrofa | elopio, yeah | 20:53 |
| jdstrand | cachio: there is something called CONFIG_STRICT_DEVMEM that is getting in the way | 20:53 |
| jdstrand | there are ways to use it, but otoh idk | 20:54 |
| elopio | kyrofa: sounds weird that unit tests are using debug, because they don't call the snapcraft command. | 20:54 |
| kyrofa | elopio, I don't even now why units are run, haha | 20:54 |
| kyrofa | Yeah something weird is happening | 20:54 |
| kyrofa | All I see in debian/tests are integration and snaps tests | 20:55 |
| jdstrand | mvo: hey, fyi, I won't be submitting anything for mpris. I'm done (for now) | 20:55 |
| jdstrand | heh | 20:55 |
| cachio | jdstrand, so, is it any way to use that interface? | 20:55 |
| elopio | kyrofa: adt starts building the deb, and for that the unit tests are run | 20:55 |
| kyrofa | Ah right, of course | 20:56 |
| kyrofa | I'll look that way | 20:56 |
| cachio | should I disable the CONFIG_STRICT_DEVMEM? | 20:56 |
| jdstrand | cachio: that's a kernel config option | 20:56 |
| cachio | jdstrand, so the only way is rebooting the machine | 20:57 |
| jdstrand | cachio: there should be a way to do it (X uses it afaik), but I personally don't know the incantation required | 20:57 |
| kyrofa | elopio, huh, is it automatically determining how to run the units? | 20:58 |
| kyrofa | It's probably wrong, then | 20:58 |
| kyrofa | And sets the logger level wrong | 20:59 |
| elopio | kyrofa: setup.py defines the tests to run | 20:59 |
| jdstrand | cachio: the kernel-module-control interface needed it for read access. that interface was written for livepatch. maybe something in there that could give a clue | 20:59 |
| kyrofa | Oh! I've never run tests that way before | 21:00 |
| elopio | tests that depend on logger levele should set it up. But as far as I know, nothing on adt touches that | 21:02 |
| jdstrand | cachio: I suspect you can read it, but need to access it in a specific way. we have in the interfacec: "allow reading /dev/mem for read-only access to architecture-specific subset of the physical address (eg, PCI, space, BIOS code and data regions on x86, etc)." | 21:02 |
| jdstrand | cachio: all Ubuntu kernels use STRICT_DEVMEM=y so you wont' be able to test write access (physical-memory-control) on Ubuntu kernels | 21:03 |
| pedronis | mmh, I'm seeing this tests fail linode:ubuntu-16.04-32:tests/main/xdg-open-compat: with apt download snapd-xdg-open=0.0.0~16.04 => E: Version '0.0.0~16.04' for 'snapd-xdg-open' was not found | 21:03 |
| jdstrand | cachio: there might be a kernel snap somewhere that uses STRICT_DEVMEM=n, but I don't know which one. I would guess perhaps an armhf kernel, but that is only a guess | 21:03 |
| cachio | jdstrand, ok, I'll research about it | 21:04 |
| pedronis | mmh, it works here, strange fluke | 21:05 |
| kyrofa | elopio, why is the ruby integration test using such an old version of ruby? | 21:06 |
| cachio | jdstrand, I'll take a look to the armhf ones | 21:06 |
| cachio | thanks | 21:06 |
| jdstrand | cachio: oh, I forgot we have a test for this. here is some more context: https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fmem_protection | 21:06 |
| jdstrand | cachio: let me get the link for the test | 21:06 |
| cachio | jdstrand, nice | 21:07 |
| kyrofa | elopio, well, it's not ancient I suppose. But versions < 2.4 don't seem to build with GCC7 | 21:08 |
| kyrofa | I'm gonna propose changing it unless there was a good reason we were using the old one | 21:09 |
| elopio | kyrofa: no good reason that I can think of. But should we raise an early exception if we see gcc7 and ruby < 2.4? | 21:09 |
| jdstrand | cachio: oh boo. the test for STRICT_DEVMEM only verifies /boot/config... is set | 21:09 |
| kyrofa | elopio, I don't think so, might be fixed at some point | 21:10 |
| jdstrand | cachio: so nothing to verify the kernel protection is working | 21:10 |
| cachio | jdstrand, well the the that I did :) | 21:11 |
| elopio | kyrofa: updating the tests works for me. | 21:11 |
| jdstrand | cachio: Xorg might be something to look at if research doesn't help much | 21:12 |
| kyrofa | elopio, alright. Testing once more, then I'll propose | 21:12 |
| kyrofa | elopio, back to the autopkgtests: note that `python3 setup.py test` fails with the same error | 21:12 |
| kyrofa | So it's using a weird logging level | 21:12 |
| * elopio runs that | 21:16 | |
| zyga-solus | jdstrand: hmm | 21:17 |
| zyga-solus | jdstrand: it _is_ sorted by command now :) | 21:17 |
| zyga-solus | jdstrand: unless I missed something | 21:17 |
| jdstrand | oh, hmm. I checked the new commits and I must've missed something | 21:18 |
| * zyga-solus tries to pull the diff | 21:18 | |
| zyga-solus | https://github.com/snapcore/snapd/pull/4144/files#diff-641ccdace7a269ed745615226d7f4cffR111 | 21:19 |
| mup | PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144> | 21:19 |
| zyga-solus | here | 21:19 |
| zyga-solus | is that what you expected? | 21:19 |
| jdstrand | zyga-solus: I see it now | 21:19 |
| zyga-solus | jdstrand: it's not super pretty because of that comment | 21:19 |
| zyga-solus | and we could be smarter about how to lay out stuff | 21:19 |
| zyga-solus | but it's a start | 21:20 |
| zyga-solus | also because of those comments it's ordered by TAG, interface, snippet | 21:20 |
| zyga-solus | which is at least, consistent :) | 21:20 |
| jdstrand | that sounds great | 21:21 |
| g4l | Hello guys! I'm try to connect to my vpn server, on a snappy ubuntu core os. using easy-openvpn.connect-server, I face this error: "ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)" | 21:25 |
| g4l | I'm thinking about some network permissions? | 21:25 |
| elopio | kyrofa: snapcraft.tests.test_lifecycle.ExecutionTestCase.test_dependency_recursed_correctly ? | 21:26 |
| kyrofa | Yep | 21:27 |
| kyrofa | g4l, if you run `snap interfaces`, are all of them connected? | 21:28 |
| ikey | zyga-solus, got 2.29.2 built | 21:28 |
| ikey | gonna try installing it and seeing how much i broke it | 21:28 |
| kyrofa | Can't remember if network management is granted by default | 21:28 |
| g4l | :firewall-control docker,easy-openvpn | 21:28 |
| ikey | also yay for mkversion.sh taking an argument | 21:28 |
| kyrofa | elopio, see the ""GET /v2/snaps HTTP/1.1" 200 None" there throwing it off? | 21:29 |
| ikey | and not causing one | 21:29 |
| g4l | :network-control easy-openvpn | 21:29 |
| g4l | :home easy-openvpn | 21:29 |
| g4l | I think that these 3 are enough | 21:29 |
| kyrofa | g4l, huh, yeah those are the ones I was thinking | 21:29 |
| kyrofa | g4l, although, did you use sudo? | 21:29 |
| cachio | jdstrand, the good part is that the test is working in debian, fedora and opensuse | 21:30 |
| elopio | kyrofa: seems to be affected by another test. ugh, that's hard to reproduce. | 21:30 |
| kyrofa | elopio, argh, I hate those | 21:30 |
| g4l | I did try. some other problems show up: "Options error: In [CMD-LINE]:1: Error opening configuration file: " | 21:30 |
| cachio | jdstrand, it is weird, why I can ready /dev/mem from the console | 21:30 |
| kyrofa | g4l, because adding tun/tap interfaces definitely requires sudo. For anything more snap-specific, you'll need to talk to the maintainer | 21:30 |
| ikey | snap run ohmygiraffe | 21:30 |
| ikey | cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_qF4Snx//lib/modules: Permission denied | 21:30 |
| ikey | pfft. | 21:31 |
| kyrofa | elopio, it happens every time for me, three times in a row | 21:31 |
| zyga-solus | ikey: any denials? | 21:32 |
| zyga-solus | ikey: on which snapd? | 21:32 |
| zyga-solus | ikey: I have _that_ snap installed and it works | 21:32 |
| ikey | AVC apparmor="DENIED" operation="open" profile="/usr/lib64/snapd/snap-confine" name="/etc/os-release" pid=2163 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 21:32 |
| zyga-solus | right here on solus | 21:32 |
| zyga-solus | that's so weird, /etc/os-release is allowed by the profile | 21:33 |
| ikey | Nov 08 21:30:37 ironhide kernel: audit: type=1400 audit(1510176637.423:37): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/lib64/snapd/snap-confine" name="/tmp/snap.rootfs_qF4Snx/lib/modules/" pid=2163 comm="snap-confine" srcname="/lib64/modules/" flags="rw, rbind" | 21:33 |
| zyga-solus | hm | 21:33 |
| zyga-solus | actually, it's not | 21:33 |
| ikey | ok well that one is fairly trivial | 21:33 |
| ikey | needs lib+lib64 | 21:33 |
| ikey | stupid solus with its weirdisms | 21:33 |
| zyga-solus | but that's an old copy of snap-confine probably | 21:33 |
| ikey | ? | 21:33 |
| g4l | kyrofa, even as root, I can't make it. has no one ever try to configure this on a rpi3 ? | 21:33 |
| ikey | im on snapd 2.29.2 | 21:34 |
| ikey | and id rebooted | 21:34 |
| zyga-solus | ikey: you will find that /lib/modules is baked into snap-confine itself | 21:34 |
| ikey | aye | 21:34 |
| zyga-solus | ikey: ah, I'm still on 2.27 | 21:34 |
| ikey | oh yeah 2.27 is gloriously fine | 21:34 |
| ikey | 2.29.2 is choking on cookies | 21:34 |
| ikey | ima fix | 21:34 |
| kyrofa | g4l, please file a bug, I'm afraid I don't know anything about that snap | 21:34 |
| zyga-solus | ironically that's one of the things we could get into the new profiles now | 21:34 |
| zyga-solus | where it could be distro-based easily from snapd side | 21:35 |
| zyga-solus | ikey: tomorrow we do 2.29.3 | 21:35 |
| kyrofa | g4l, https://bugs.launchpad.net/snappy-hwe-snaps/+filebug from the look of it | 21:35 |
| zyga-solus | there are a few PRs tagged for 2.29 | 21:35 |
| ikey | ok | 21:35 |
| zyga-solus | milestoned | 21:35 |
| zyga-solus | not tagged in git sense | 21:35 |
| ikey | mount options=(rw rbind) {,/usr}/lib{,32,64,x32}/modules/ -> /tmp/snap.rootfs_*{,/usr}/lib/modules/, | 21:36 |
| ikey | surely that already covers it? | 21:36 |
| ikey | or im being thick altogether | 21:36 |
| ikey | why it even needs my kernel modules ive no idea | 21:36 |
| zyga-solus | it looks good | 21:36 |
| zyga-solus | "failed flags match" | 21:37 |
| ikey | right | 21:37 |
| zyga-solus | I'm too tired | 21:37 |
| ikey | maybe somehow rw, rbind != rw rbind ? | 21:37 |
| zyga-solus | sorry, I need to stop typing | 21:37 |
| zyga-solus | tomorrow :) | 21:37 |
| ikey | kk | 21:37 |
| mup | PR snapcraft#1721 opened: integration tests: use ruby v2.4.2 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1721> | 21:41 |
| ikey | oo the patch isnt in 2.29.2.. | 21:41 |
| ikey | k well that makes sense then | 21:41 |
| mup | PR snapd#4182 opened: cmd/snap-confine: Ensure snap-confine is allowed to access os-release <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4182> | 22:00 |
| elopio | kyrofa: can you please try this patch with your autopkgtest runs? http://paste.ubuntu.com/25920819/ | 22:17 |
| mup | PR snapd#4183 opened: cmd/snap-confine: Respect biarch nature of libdirs <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4183> | 22:52 |
| kyrofa | elopio, it's the parser test | 22:55 |
| kyrofa | I'm not sure how yet, but it is | 22:56 |
| ikey | turns out you guys were serious about snap-update-ns being static. :p | 22:56 |
| ikey | tada https://plus.google.com/+Solus-Project/posts/hG14dctjrfg | 23:03 |
| elopio | can somebody open build.snapcraft.io? I think I broke it :( | 23:22 |
| nacc | elopio: or is it affected by the canonical maintenance? | 23:22 |
| elopio | nacc: phew, so it wasn't me :) | 23:23 |
| nacc | elopio: it's nnot explicitly metioed, but the store and "Ubuntu web sites" are | 23:24 |
| nacc | *Canonical and Ubuntu | 23:24 |
| diddledan | aha, I was just about to ask whether I broked it | 23:30 |
| kyrofa | IRC is back, test again | 23:32 |
| mcphail | ikey: I love that ohmygiraffe has become the de facto test of snapd :) | 23:35 |
| ikey | lol yea | 23:35 |
| ikey | its nice because GL + sound + xdg | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
