[00:00] That makes the snapd suite far more than just hello-type snaps [00:01] But I'm fine with it as long as running the snaps doesn't add a lot of time [00:01] kyrofa: some of them should be in the plugins integration suite, right? [00:01] the ones that don't require execution. [00:02] Yeah that would be better... but then we have problems :P [00:02] Just trying to figure out what we want to do about snapcraft#1717 [00:02] PR snapcraft#1717: catkin plugin: check for pip packages in part only [00:04] kyrofa: I haven't seen that plainbox error before, but permission denied in tmp isn't it the same we get in ruby? [00:04] elopio, I've never seen that for ruby, I just saw an inability to find rbconfig.rb [00:06] kyrofa: http://paste.ubuntu.com/25954649/ line #4 [00:06] elopio, that's probably shebang rewriting etc. Yeah, not sure why permission would be denied there [00:07] But it's a separate issue from the breakage a few lines below [00:07] (which I've fixed) [00:08] elopio, note that I see those warnings as well [00:08] (just checked) [00:09] elopio, looks like ruby sets gems to 444 (read-only) [00:09] So, non-fatal indeed [00:09] We can ignore those === mwhudson_ is now known as mwhudson [00:13] kyrofa: ahh, I was looking at the wrong place then. Where are you getting those plainbox errors? to try to reproduce [00:13] elopio, on xenial, adt running in xenial lxc [00:13] I'll be running another one in a minute, see if it happens again or if it was a fluke of some kind [00:14] kyrofa: amd64? [00:14] elopio, yes indeed, sorry [00:14] yeah, I haven't seen that one. [00:16] sergiusens, elopio, both of those PRs depend on making a call on where we want that test to be [00:17] I vote for leaving it alone until we can split the plugins suite [00:21] kyrofa: +1. Make the move after we have the reorg branch, probably to snapcraft/integration/plugins/catkin [00:22] the hard part is to define where to put all the ones that are not catkin, naming those directories "general" is kind of sad. [00:22] maybe, we can make a filter, and run everything except catkin. [00:23] elopio, hmm, aren't the filters regex though? [00:23] kyrofa: they could be. [00:24] Negative regex gets gross [00:25] yes. I don't have a solution for this, but I'm happy to push it for later. [00:25] reorgs later [00:26] Good [00:26] I'll run a zesty test on 1717 [00:31] elopio, thanks for the --setup-commands hint, by the way. I'll propose that for our testing doc once this release is out the door [00:41] Running 1719 zesty:amd64 on my server as well [00:41] elopio, how do you feel about upping the ROS timeouts for arm adt? [00:44] kyrofa: I'm ok with that [00:44] Every time it happens they're priming or snapping, so we're so close [00:44] It also means it's not a legit hang, it's just taking a little longer [00:44] kyrofa: also, they can be moved to integration tests, right? [00:45] elopio, oh, are we talking about the demos? [00:45] elopio, yes they can, but then we run into the same question of where to put them [00:46] Seems pointless to move them until we have a place they can stay [00:47] kyrofa: they will be slow snapd integration tests, so they will only run on adt [00:47] Oh riiight [00:47] we haven't set a timeout for those, but we probably should. [00:48] I'd still rather just tweak the timeouts here so I don't need to retest them [00:48] (for release I mean) [00:51] kyrofa: ah, yes, for now, just bump that. [00:51] I would hate to cause a timeout in a different place, again. [00:51] No kidding [00:51] I just wanna get this thing out the door [00:58] PR snapcraft#1731 opened: demo tests: bump catkin timeout by ten minutes [00:58] elopio, ^ [01:42] kyrofa elopio fwiw I am not fond of timeouts [01:42] * sergiusens looks for a clever blog post with why [01:44] meh, I cannot find any. I wouldn't use timeouts on test hardware that is shared or out of our control [01:44] there are so many things that can go wrong [02:22] PR snapd#4211 opened: tests: adding tests for time*-control interfaces [02:28] sergiusens, fine by me, they do cause issues [02:29] sergiusens, we can remove them after this release, when we slurp them into the snapd suite [02:29] (which doesn't have timeouts) [02:29] (at least, I don't think they do. Maybe they have shorter timeouts though, we'll have to check) [02:38] kyrofa \o/ === JoshStrobl is now known as JoshStrobl|zzz [03:32] sergiusens, bug #1732065 is probably for you [03:32] Bug #1732065: dotnetplugin: use of xenial-only stage-packages [03:33] kyrofa heh, the dotnet plugin will not work on anything but xenial [03:33] sergiusens, alrighty, more skips! [03:35] kyrofa seems the tests for snapcraft#1730 went rather well [03:35] PR snapcraft#1730: ruby plugin: be smarter about arch-specific paths [03:35] snappy-m-o, autopkgtest 1731 xenial:armhf [03:36] kyrofa: I've just triggered your test. [03:36] sergiusens, armhf is red, let me see... [03:37] Ugh. Network problems [03:37] kyrofa ros test and python, network related and unrelated to this, but please double check [03:37] sergiusens, indeed, both network related [03:38] kyrofa is snapcraft#1717 good when looking at the errors? [03:38] PR snapcraft#1717: catkin plugin: check for pip packages in part only [03:39] sergiusens, for zesty anyway, yeah. But that skips some tests... would sure like xenial armhf to run [03:39] But then we hit the timeout issue [03:40] kyrofa is that the 10 thing? [03:40] sergiusens, yep [03:40] armhf is running there now [03:40] Or queued at least [03:40] kyrofa be more ambitious, triple it [03:40] Hahaha [03:40] You got it [03:40] as if there were no timeout [03:40] really [03:40] I asked elopio a year ago to remove these timeouts [03:40] the only thing we do when we reach them is increase it [03:40] PR snapcraft#1730 closed: ruby plugin: be smarter about arch-specific paths [03:41] and we already have the timeouts imposed by the machinery running the tests anyways [03:43] snappy-m-o, autopkgtest 1731 xenial:armhf [03:43] kyrofa: I've just triggered your test. [03:43] sergiusens, done [03:44] great [03:47] sergiusens, my adt run on snapcraft#1719 blew up, unfortunately, it seems like it doesn't like running in nested containers. I'm starting it again here, but it takes about two hours [03:47] PR snapcraft#1719: many: account for python shebang args in rewrite [03:47] (zesty:amd64) [03:48] Would be nice to see xenial:armhf there as well but there seems little point in queuing that up until the timeout fix lands [03:49] I'll check back in a bit [03:49] kyrofa one sec [03:49] can you review something real quick? [03:49] Sure [03:50] kyrofa #1732 [03:50] PR #1732: many: respect dirs.SnapSnapsDir in tests [03:50] kyrofa hmph, snapcraft#1732 [03:50] PR snapcraft#1732: tests: dotnet only works on 16.04 [03:51] sergiusens, haha, I got it. Always gets ya, though! [03:51] kyrofa I am doing it on purpose sometimes, maybe enough "incorrect" people get pinged that it gets removed as the implicit default :-P [03:51] Hahahahaha [03:52] sergiusens, +1 [03:52] Alright, back soon [03:52] PR snapcraft#1732 opened: tests: dotnet only works on 16.04 [03:57] Is there a guide to package Wine programs into snaps? I want to try out some windows programs but I don't want to have all those dependencies [04:38] Issue snapcraft#1492 closed: Support for advanced filtering for build-packages [04:40] snappy-m-o autopkgtest 1732 artful:amd64 [04:40] sergiusens: I've just triggered your test. [04:43] had to push a fix to the full-nvidia-support PR [04:43] turns out Ubuntu uses a slightly different filename convention for vulkan ICDs (it doens't start with 10_ so i glob without the 10 now..) [05:38] Tests still running... [05:41] The timeout-increasing PR has its armhf run going though, looks like [05:41] I suspect things will come together tomorrow [06:50] PR core#64 opened: 30-fix-timedatectl.chroot: fix quoting issues [07:45] * zyga-ubuntu is doing some tax work in the morning, sorry about that [08:21] PR snapd#4212 opened: tests/interfaces-network-control-tuntap: disable on debian-unstable for now [08:23] mvo: hint: all of debian unstable is broken [08:24] mvo: because of https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/12 [08:24] mvo: so perhaps we need to refresh the debian image and fix this for real, disabling all of debian while this happens [08:25] zyga-ubuntu: I see only the failures in tun/tap so far [08:25] zyga-ubuntu: but those are quite consitent [08:26] mvo: what is the error there? [08:26] zyga-ubuntu: permission denied [08:27] zyga-ubuntu: I have not checked (yet) for the details, just want to unblock master for now [08:27] zyga-ubuntu: there are some PRs ready otherwise [08:55] pstolowski: hi, I re-reviewed #4158 [08:55] PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh [08:57] pedronis, ty [09:06] pedronis: hey, good morning. can I run an idea by you? I have created https://github.com/snapcore/snapd/compare/master...mvo5:refresh-candidates-managed?expand=1 as a starting point for the work for the refresh.schedule=managed PR. my idea was that if the refresh schedule is managed there is code that calls store.ListRefresh() with the RefreshControlManaged flag. do you think this makes sense or would you suggest a different approach? [09:07] also 4212 would unblock master [09:07] if it gets reviews [09:07] PR snapd#4212 closed: tests/interfaces-network-control-tuntap: disable on debian-unstable for now [09:07] * mvo hugs zyga [09:08] zyga-ubuntu: lets try to merge in a controlled way so that we don't cause a travis congestion [09:08] mvo: ok, let's coordinate here [09:09] zyga-ubuntu: I will push 4204 as this should be ready now [09:09] https://github.com/snapcore/snapd/pull/4207 can land [09:09] PR #4207: Flesh out NVIDIA support for biarch and multiarch systems [09:09] zyga-ubuntu: also 4202 [09:09] 4202 has some comments [09:09] if you add those that's fine [09:10] zyga-ubuntu: I think he addressed them, no? [09:10] mvo: we are trying not do add new headers [09:10] because we are redesigning all of them [09:10] pedronis: aha, happy to use json then, any suggestions for a straw-man? [09:11] mvo: I mean it's ok if first iteration doesn't flag this anyway [09:11] it's really a question for cprov tbh [09:11] pedronis: what the json should look like [09:12] pedronis: oh, you mean in the first iteration we don't need this flag send? fair enough, I can hold back then if it does not make sense to add it at this point (because of the store API work) [09:12] mvo: I don't know, the issue is also that if we send something like this probably we need to send it with all calls [09:12] not just the extra calls [09:12] pstolowski, zyga-ubuntu: is there anything controversial in 4120? it looks quite mechanical, if this is the agreed interface it seems we want to merge it. or does it need a gustavo +1? [09:13] mvo: I don't think it make sense to add a flag without discussing how it will be used [09:13] for that we probably need cprov [09:13] pedronis: all refresh calls or all all calls, i.e. install etc as ewll? [09:13] all refresh calls at least [09:13] but see general point [09:13] mvo: I'll look in a sec [09:14] pedronis: adding it to all refresh calls was my plan, but happy to hold off for now and discuss wider first. sorry for the rush, was mostly because we want the managed mode in 2.30 but if we can life without the flag for v1 all is well [09:14] pedronis: I followup in the forum [09:17] mvo, i hope there is nothing controversial [09:18] that was the agreed direction, Permanent takes Info sanitized at read time [09:19] mo'in [09:19] pedronis: great, then its just a second review and it can go in. thanks for your feedback [09:19] hey Chipaca [09:19] mvo: yes, please write something in the topic [09:20] Chipaca, hi, could you please have another look at https://github.com/snapcore/snapd/pull/3916 ? I think I addressed the remaining comments [09:20] PR #3916: snap,wrappers: add support for socket activation [09:21] sure [09:21] thanks [09:25] mvo, pedronis: Hi! how can I help ? [09:25] cprov: hey, good morning [09:26] mvo: morning [09:28] zyga-ubuntu: you did say that you want to have a look at 4207, right? [09:28] zyga-ubuntu: it has two +1 already but you are the expert in this area so your review will certainly not hurt :) [09:30] mvo: I will look again and merge it [09:30] thank you :) [09:31] * zyga-ubuntu is almost done with taxes [09:40] mvo: +1 to land https://github.com/snapcore/snapd/pull/4120 [09:40] PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots [09:42] thanks1 [09:45] PR snapcraft#1731 closed: demo tests: bump catkin timeout by a lot [09:46] PR snapd#4120 closed: repo: use PlugInfo and SlotInfo for permanent plugs/slots [09:52] PR core#64 closed: 30-fix-timedatectl.chroot: fix quoting issues [10:01] snappy-m-o autopkgtest 1717 xenial:armhf [10:01] sergiusens: I've just triggered your test. [10:09] * zyga-ubuntu goes to the doctor with his son [10:11] ackk: +1; merged [10:11] ackk: thank you! [10:11] PR snapd#3916 closed: snap,wrappers: add support for socket activation [10:11] Chipaca, \o/ thanks :) [10:12] Chipaca, are the blockers for the snapcraft PR to alow that syntax? [10:16] ackk: je ne sais pas [10:16] ackk: that's a snapcrafter question :-) [10:16] (i haven't been following that particular thing) [10:16] ackk: have you checked with review tools also? [10:20] Chipaca, wdym? [10:21] yeah I should probably ask kyrofa about that one [10:21] (https://github.com/snapcore/snapcraft/pull/1617 FTR) [10:21] PR snapcraft#1617: Add options to configure applications socket activation [10:23] ackk: there's a sanity checker / enforcer that's run as part of a store upload that might block this (i don't know, but somebody should check) [10:23] ackk: it used to be called click-review-tools (it might still be called that) [10:23] I see [10:24] rabble rabble proud heritage rah rah [10:45] Chipaca: hey, so man pages :-) I've been putting some weekend/evening time into getting man-db set up with apparmor and seccomp [10:46] Chipaca: at the moment the state of play is that I've got committed-but-not-uploaded changes to add an apparmor profile to /usr/bin/man that confines various groff-related processes that it starts, plus decompressors and other misc filters [10:47] Chipaca: I've also got work in progress to do seccomp confinement in other simpler cases - groff can't really be seccomp-confined because we need to be able to do path filtering (to let it open temp files but not other things) [10:48] Chipaca: how widely deployed would we want all this to be before we could be comfortable turning it on in snaps, though? [10:49] Chipaca: the main issue here is that seccomp confinement requires some new API in libpipeline, so it'd be difficult to SRU. the apparmor confinement on its own would probably be quite easy to SRU. might we be comfortable if we just had apparmor for groff-related processes called by man, which it seemed to me before was the main concern? [10:49] cjwatson: wrt whether apparmor would be enough for us to be happy, that's a question for jdstrand [10:50] OK, hopefully he'll see that. I did run the profile past him [10:50] cjwatson: wrt SRU, i'll check what mvo thinks; worst case we might look at rolling it into 18 [10:50] AIUI from Gustavo at the rally, 18 is more of a future escape hatch than a concrete plan [10:50] so yeah, that's a worst case, seems like quite a bad one though :) [10:50] cjwatson: wrt how widely deployed, i'm ok with letting the packager decide whether their target distribution supports it or not [10:51] cjwatson: 18 is many things :-) but we'll be switching to an 18.04-based default at _some_ point [10:51] as opposed to our current 16.04-based default [10:51] and that's what i meant [10:51] right, if you mean 18.04 base snaps rather than series 18 assertions or whatever, then sure [10:51] series:18 is the thing that's an escape hatch [10:52] hopefully should be able to get the apparmor profile SRUed to xenial after some bake time, though [10:52] yes (for moost non-devs, a 18.04 base snap defaut is as 18 as it gets) [10:52] that would be ideal, agreed [10:54] cjwatson: the change in libpipeline, it's a new API, not a changed one? [10:54] the main hole this leaves would be man-db's own scanning of manual pages to figure out what their NAME headers are. there's literally never been a vulnerability in that, though, so I'm not too worried [10:54] so it can be made ABI-compatible? [10:54] it's a new API, yes, but it'd effectively be a new upstream version [10:54] also new ABI, so not quite sure what you mean by ABI-compatibile [10:54] *compatible [10:55] maybe i misunderstood -- i thought if you just added new symbols you didn't need to bump the abi [10:55] but my knowledge of that part of the stack is very hazy :-) [10:56] (i've never had to learn it) [10:56] Chipaca: well, it's not a new SONAME so doesn't require a library transition or anything, sure [10:56] right, that's what i meant, thank you [10:59] cjwatson: taking a step back, that's great news, and thank you for your work on this! I'll try not to get too excited until more bits get put in place, but it's hard :-) [11:01] right, it'll take a week or two more until everything lands in bionic, probably, since the seccomp stuff requires some care about portability. Just mainly wanted to check whether I was missing anything important [11:10] Son_Goku: o/ [11:10] hey [11:12] Son_Goku: question for you: if you set MANPATH to include, say, /var/lib/snapd/snap/man, and that directory contained manpages, would your man pick it up, or would its confinement block that? [11:13] it'd probably get blocked [11:13] o/ [11:13] niemeyer: hi [11:13] man can only access files labeled as "man_t" [11:14] I'd probably have to fiddle with the SELinux policy to make sure any files in /var/lib/snapd/snap/man were marked as man pages [11:14] or at least could transition from type snappy_var_t to man_t [11:14] Son_Goku: could snapd do that labeling? [11:15] it *should* [11:15] pedronis: I think I'm at the point now where I would like to use the fakestore with a fake snapDeclaration for my snapd refresh managed PR, maybe we can have a quick chat after the standup? happy to work on it just want to make sure things are aligned [11:15] the fact it doesn't is super annoying [11:15] Son_Goku: ok, i'll keep it in mind [11:15] it should be generating all of these policy things [11:15] Son_Goku: tell me more [11:15] about "all of these policy things"? [11:16] i mean, i have no idea how to label something, but i presume it's something that could in worst case be done via a command [11:16] so snapd could do it as part of install [11:16] sure [11:16] there are a few ways to do it [11:16] so my question is more what needs labeling [11:16] libselinux provides a programmatic way to do it, but you can also use chcon to do it [11:17] it does run the risk of being reset unless a policy is generated and loaded [11:17] so snaps need to be labeled correctly on install and mount [11:17] matching the label in the snapd policy profile for them [11:18] assuming man is confined, man pages on install need to be labeled correctly, too [11:18] Son_Goku: what would do that resetting? and how does a policy loading stop the reset? [11:18] mvo: yes, it's almost lunch here, we can chat after the standup, this morning I looked around about what is the current situation about that [11:18] and snapd should be generating policies to enforce these so that when the user runs restorecon, it doesn't get reset by policy [11:19] the restorecon command can be used to reset all filesystem labels to match what's in the loaded SELinux policy [11:19] Son_Goku: is the policy something like "everything under /foo/bar has label baz"? [11:19] yes, it can be [11:20] Son_Goku: so we could instead have that and do restorecon? [11:20] yes [11:20] or would that be frowned on [11:20] no, that's fine [11:20] you can tell restorecon to restore only within a set of paths [11:20] rather than the whole filesystem [11:20] Son_Goku: and how does restorecon affect running processes? [11:21] it doesn't === chihchun_afk is now known as chihchun [11:21] ok [11:21] processes get their SELinux context from when they're initialized [11:21] that comes from the label they were on disk [11:21] Son_Goku: thanks (i'll ask and dig more when i'm closer to the feature) [11:21] :) [11:21] this gives me a general feel of what needs to happen :-) [11:23] for SELinux, there are two "languages" for them: a high level language (you can see that here: https://github.com/snapcore/snapd/tree/master/data/selinux), and an intermediate language that you can use to build another language to compile to: https://github.com/SELinuxProject/cil/wiki [11:23] cjwatson: is the libpipeline work being done upstream? would fedora be picking that up as well? [11:24] Chipaca: I am upstream for libpipeline [11:24] so yes [11:24] pedronis: same here, lunch and meetings, looking forward for your ideas :) enjoy lunch [11:24] cjwatson: thank you [11:24] Chipaca, since snapd has its own high level language for security constructs, any programmatic SELinux enablement would probably be done by leveraging the CIL [11:25] CIL constructs can be directly loaded into the kernel [11:26] Son_Goku: I know some of those words! I'll see how much I need to learn down the road (not now though) [11:27] :D [11:28] Son_Goku: the context is that we'll be adding manpage support at some point, and want man to be able to load manpages from snaps while minimising risk [11:28] right [11:29] the CIL structure more closely resembles how AppArmor profiles are written, so that might be helpful for you ;) [11:30] * Chipaca goes back to reviewing stuff [11:30] also... restorecon: https://www.mankier.com/8/restorecon [11:36] * kalikiana tea break [11:38] the in-progress apparmor profile is https://anonscm.debian.org/cgit/pkg-man-db/man-db.git/tree/debian/apparmor/usr.bin.man FWIW [11:39] definitely not perfect but it protects the bits that deal with untrusted data most directly [11:48] ogra_: regarding the problem of snaps mounts appearing in gdu [11:48] the mount options 'x-gdu.whatdever' cannot be used because it requires that to be in fstab [11:49] an enviroment variable cannot be used because cannot be get using udisk2 [11:50] re [11:50] JamieBennett: I'm home now [11:51] zyga-ubuntu: http://paste.ubuntu.com/25960186/ [11:52] I asked upstream if we can just mark them as udisk2 ignored [11:52] and maybe gdu can avoid displaying an ignored loop device [11:53] and show all the other devices (even if ignored) [11:53] andyrock: looking [11:54] andyrock: I don't understand why x-gdu.whatever cannot be used [11:54] because it's not passed around [11:54] andyrock: is it because the custom mount unit data is lost and cannot be accessed? [11:54] not written in mtab [11:54] nowhere [11:55] I see [11:56] it can be that i'm doing something wrong [11:56] but I don't think so :D [11:57] https://www.irccloud.com/pastebin/qWM7FlOw/ [11:59] it can be that I'm using an old version of util-linux [11:59] let me check on bionic [12:01] andyrock: I think you are right [12:01] https://www.irccloud.com/pastebin/8i62fxih/ [12:02] zenial has 2.27 [12:02] *xenial [12:02] bionic should be fine [12:02] and it's ok to not target X [12:03] zyga-ubuntu: OK, see you at the stand-up [12:06] mvo: hello, did you consider increasing the number of workers? [12:08] ok [12:19] mvo: I just +1d https://github.com/snapcore/snapd/pull/4207 [12:19] PR #4207: Flesh out NVIDIA support for biarch and multiarch systems