[05:47] hello [06:01] morning [06:21] hey [06:21] mborzecki: quick qustion, does the aur packaging limit architectures? [06:21] mborzecki: someone is asking for snapd on manjaro on aarch64 [06:22] zyga: yes and no, iirc the general consensus was that you put x86_64 there and then people building the package on other arches can edit PKGBUILD to their liking [06:22] also aur helpers usually allow to ignore the arch and build with whatever the local one is [06:22] i've added i386 for some arch-on-x86 project poeple asked about [06:23] i can add aarch64 too [06:24] mborzecki: uh, that's odd, why do you have to put x86_64? [06:24] mborzecki: yeah, let's add aarch64 and just call it a day (on that issue) [06:25] haha i see the forum topic now [06:25] so poeple can close and call makepkg -i but don't bother to read the manpage :P [06:29] "snap install things quickly" :) [07:10] zyga: i'm seeing 434 syscalls known to libseccomp in the current master branch [07:10] mborzecki: how are you measuring? [07:11] zyga: there's arch-syscall-dump tool in the source code that dumps the known syscalls for that arch [07:11] ah, nice [07:11] zyga: this is combined for all arches: https://paste.ubuntu.com/p/3vDk88tFZf/ [07:32] brb,dog.walk() [07:44] re [07:44] hello mvo [07:45] hey zyga ! good morning [07:45] welcome back :) [07:45] how was your week off? [07:46] zyga: it was very nice [07:46] zyga: thank you [07:46] zyga: what did I miss? [07:47] mvo: let me think [07:48] mvo: I think last week was mostly quiet [07:48] mvo: for me some things that are important are 2.13 apparmor - we need to urgently release with support for it [07:48] zyga: in what distros is it used? and what changes for us? [07:48] mvo: I also raised the topic of snapd LTS but pedronis asked to move the discussion to this week, once you are back [07:48] mvo: it's going in everywhere, opensuse, debian and ubuntu as well [07:49] mvo: there's a PR from jdstrand [07:49] mvo: I proposed that 2.37 become the first LTS branch that just gets bug fixes and is periodically released again [07:49] and that we have tracks with that version [07:50] mvo: apart from that, we have ongoing beta validation [07:50] mvo: and I think that's it, lots of reviews to do [07:50] zyga: thanks [07:51] zyga: anything holding back beta validation? I mean, any issue that prevent the move to candidate? [07:51] mvo: I don't recall any details, sorry [07:55] zyga: ta, I will chase it [07:59] mvo: hey [08:01] morning [08:03] good morning mborzecki and pstolowski ! [08:18] moin moin [08:18] ooh, new git [08:18] * Chipaca accepts the gift of the apt gods [08:24] * zyga reviews https://github.com/snapcore/snapd/pull/6079 [08:24] PR #6079: cmd/snap: `snap connections` command [08:25] zyga: thanks! [08:27] zyga: https://paste.ubuntu.com/p/cJ2v9hfJhH/ snap-seccomp version is added at the very beginning [08:28] it's the library version followed by the hash of the supported syscall names [08:36] mborzecki: looks great, [08:36] mborzecki: would you mind moving the hash to the 2nd line and saying what it is [08:36] zyga: mhm, and the changes aren't that huge either [08:36] mborzecki: "# hash of sorted list of supported system calls [08:36] * zyga is slow today, both wife and older daughter have fever :/ [08:38] mborzecki: bonus points for naming the hash algo [08:43] mvo: Morning, welcome back. [08:43] mvo: Any idea on the current situation with backporting the catalog randomisation? [08:44] wgrant: its in beta and we uploaded the SRU last week, afaict no SRU reviewer has looked at it yet, I will poke people about it today [08:47] mvo: Does that include xenial/bionic-security? [08:52] PR snapd#6558 opened: many: remove unused code (mostly) [08:57] mvo: hi, welcome back, hope the week (mostly) off was restful === alan_g_ is now known as alan_g [08:58] Chipaca: hi, #6545 should be mergeable if you are ok with the tweaks I pushed there [08:58] PR #6545: cmd/snap, daemon: make the connectivity check use GET [08:58] What's the difference between kotlin and kotlin/native [08:58] What's the difference between kotlin and kotlin-native* [09:02] For example, "Kotlin/Native compiler" and "Command line Kotlin compiler" [09:04] kotlin-native 0.9.3 jetbrains classic Kotlin/Native compiler [09:04] kotlin 1.3.21 jetbrains classic Command line Kotlin compiler [09:06] smallville7123: read the description of both? [09:06] Where do i find thay [09:06] That [09:07] smallville7123: snap info kotlin kotlin-native (snap info kot-alt-*) [09:09] Statically typed programming language for modern multiplatform applications [09:09] Yet its summery is summary: Command line Kotlin compiler [09:09] So which is it -_- [09:10] pedronis: you introduced a double-lock on state, there [09:10] unless i missed something [09:10] nope [09:11] smallville7123: read the description? the summary was already in the output of 'snap find' [09:11] Also why are there two if both are to be the same [09:12] What does one provide that the other doesnt [09:12] smallville7123: the information is there if you read it. And ultimately, even if it weren't, ask jetbrains; how should *we* know? [09:13] Cus YOU package and provide them [09:13] Chipaca: ? [09:13] smallville7123: we do not package it, jetbrains does [09:13] pedronis: in the POST route [09:13] Chipaca: are we missing a test? [09:13] pedronis: the state you pass to checkConnectivity is locked [09:14] -_- [09:14] Chipaca: checkConnectivity and unlocks and relocks [09:14] not locks and unlocks [09:14] pedronis: hah. my bad. [09:16] PR snapd#6545 closed: cmd/snap, daemon: make the connectivity check use GET [09:20] pedronis: any conclusion on blob vs snapfile vs ...? [09:20] pedronis: wrt #6532 [09:20] PR #6532: daemon: allow downloading snaps blobs via .../blobs [09:23] PR snapd#6162 closed: interfaces/greengrass_support: update accesses for GGC 1.8 [09:23] Chipaca: no, was focused on 2.38 things === cpaelzer__ is now known as cpaelzer [09:24] Chipaca: could you re-review #6079 ? [09:24] PR #6079: cmd/snap: `snap connections` command [09:26] mborzecki: 6556 is included in 6079? [09:27] Chipaca: no, i've reverted that patch from 6079 [09:28] Chipaca: iirc the plan is snap conenctions for 2.38, then deprecation & hide interfaces in .39 [09:28] ok [09:29] i need to step out for a bit, i'll review when i return [09:31] mvo: one more thing, more core18 / core discovery, one more unhandled problem [09:31] sorry, forgot to mention [09:31] but we can chat again when you have time [09:37] pedronis: on 2nd thought I think snap-confine *does* know the boot base on core [09:37] pedronis: we parse os-release and differentiate classic, core18, core-other [09:37] zyga: does it use the info though? [09:37] pedronis: yes [09:37] and specifically for this choice too [09:37] I will double check and see if we have any tests [09:38] but it may be less terrible than we thought last week [09:43] zyga: lets talk in ~45min again then my head should be a bit less busy [09:44] zyga: yes, I see the relevant code now, it's quite spread out [09:45] pedronis: because of ns hops [09:45] hops? [09:45] pedronis: we look and remember and then use the fact much later [09:45] but yeah [09:45] joining various namespaces [09:46] there's a helper sc_should_use_normal_mode(distro, base_snap_name) [09:46] it's used exactly twice [09:46] yeah, and distro is probed early [09:49] mborzecki: +1 to 6079 [09:49] mborzecki: thank you [09:49] Chipaca: thanks for the review! [10:02] will be out for a while, left a note in the forum [10:05] ok, _now_ i'm stepping out for a bit [10:14] * dot-tobias waves [10:25] PR snapd#6558 closed: many: remove unused code (mostly) [10:37] mvo: you should look at #6549 (there's a question there about when to cover the snapd snap), and also re-review #6322 [10:37] PR #6549: apparmor: support AppArmor 2.13 [10:37] PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get [11:05] PR snapd#6559 opened: pkg/apparmor: scratch documentation of apparmor [11:30] pedronis: hey, does this https://pastebin.ubuntu.com/p/tF3X8RV6t9/ more less match the idea re flattening? this is a dump of state with 5 timings, for each timing there are 3 nested timings, flattened per-timing [11:36] pstolowski: yes [11:36] assuming it works as I would expect [11:36] pedronis: i'll show you an example in a moment [11:37] pstolowski: I mean what happens if there is more than one 1 etc [11:38] zyga: it's a bit unclear which of/whether your last comments on #6549 should block it [11:38] PR #6549: apparmor: support AppArmor 2.13 [11:39] pedronis: I don't want to block it yet, it mainly depends on the reaction to my small RFC branch [11:40] zyga: we are trying to do 2.38 today or tomorrow [11:40] pedronis: I see [11:40] pedronis: I'm happy with 2.38 having this code if you don't object [11:41] and growing something easier to follow in master [11:41] ok [11:41] we still need to understand what to do about the snapd snap case [11:42] pedronis: then you have this: https://pastebin.ubuntu.com/p/Bp9gGj7gvz/ (see the first and last nested measurement of each timing) [11:42] pstolowski: yes, that's what I would expect [11:42] pedronis: ok, good [11:50] pedronis: and this is how it's used https://pastebin.ubuntu.com/p/5hgwQqHckt/ [11:52] pstolowski: thx, looks reasonable [11:55] pstolowski: nice stuff! [11:55] * mvo is very excited about this feature [11:56] PR snapd#6557 closed: tests/main/high-user-handling: fix the test for Go 1.12 (2.37) [11:57] PR snapd#6543 closed: Add force_turbo to the list valid pi config keys [11:59] re [12:06] pedronis, mvo thanks for quick feedback, in that case i'll polish it a bit and propose a base PR [12:07] pstolowski: sounds great [12:09] we should split spread tests into "distros that often break because of mirrors and other related bull" and "real distros :-p", and use travis's can-fail flag for the former [12:10] allow_failures i mean === ricab is now known as ricab|lunch [12:46] mvo: it seems I created confusion with my comment about Active [13:01] * zyga takes the dog out [13:01] mvo: I pushed an update to https://github.com/snapcore/snapd/pull/6498 [13:01] PR #6498: cmd/libsnap: add cgroup-pids-support module === mborzeck1 is now known as mborzecki [13:11] damn, sudden power loss :/ [13:12] I remember having to have an UPS for my router :-) [13:13] mborzecki: thank you for pointing out the changing of publisher across revisions btw [13:14] Chipaca: np [13:14] it would've been a regression [13:14] Chipaca: my router & nas are under a ups already, but the desktop isnt :P [13:14] I've got these nifty computers with an integrated UPS [13:14] call 'em laptops? [13:15] :-D [13:29] hey folks if I wanted to see which commit of snapd the edge channel of the core snap was built from, is this doable? i.e. I currently have 2.37.4+git1173.2c7e249~ubuntu16.04.1 but 2c7e249 doesn't seem to be a commit in snapd [13:41] ijohnson: there is some indirection, it is built from here: https://git.launchpad.net/snapd-vendor/commit/?id=2c7e24947044fd67c166871d81374dcee76b135c [13:45] ah I see, so then that repo builds into the PPA here https://code.launchpad.net/~snappy-dev/+archive/ubuntu/edge which is then what goes into this: https://code.launchpad.net/~snappy-dev/+snap/core which is the core snap released, correct? === ricab|lunch is now known as ricab [13:58] zyga: thank you for the update to 6498 [14:19] Question: I have two snaps and I need them to talk each other via redirection to sterr and stout (using example juju status > file.log ) from another classic snap. Currently I get apparmor errors (DENIED) is there a slot, plug or interface I should use to make them accept the syscall ? [14:21] looks like I got some help here: https://github.com/lborda/snap-bug/issues/1 will give it a try [14:21] sergiusens, ^ ty [14:35] lborda: the denial says you are doing something different than what you describe. perhaps use a pipe of /dev/stderr /dev/stdout? [14:36] err [14:36] pipe or* /dev/stderr and /dev/stdout? [14:38] jdstrand, to explain exactly what I am doing is: I am running snap-bug which call popen(juju status) and using juju status > log.file from it... should I not be using that ? see the reproducer there... I am using popen for that... https://github.com/lborda/snap-bug/blob/master/collect.py [14:40] yes, that is what I figured. the problem isn't the snaps, but snap-confine. they may be two classic snaps that are effectively unconfined, but they are going through a strictly confined snap-confine [14:40] (when you call the second snap) [14:41] snap-confine doesn't have access to log.file, as can be seen from the denial [14:41] and it needs it due to fd inheritence [14:47] jdstrand: hi, when you have some time, could you take a look at https://github.com/snapcore/snapd/pull/6485 ? [14:47] PR #6485: interfaces/seccomp: regenerate changed profiles only <⛔ Blocked> [14:48] lborda: instead of specifying stdout and stderr as files, perhaps use Popen.communicate to get the output, then write that out yourself [14:49] there are probably other ways to fix it [14:49] mborzecki: ack [14:49] jdstrand: thanks! [14:58] jdstrand, I can give it a try. looks like a workaround... is this bug related to my issue ? https://bugs.launchpad.net/snapd/+bug/1815869 [14:58] Bug #1815869: Command of classic snap fails with denial when output is redirected [15:02] lborda: the underlying issue (fd inheritence with apparmor) is the same, but that is a different issue [15:04] lborda: this has some detail: https://forum.snapcraft.io/t/snapd-2-32-breaks-live-server-installer/4597/10 [15:05] lborda: but put more siccinctly, it is a limitation that should improve with time [15:05] succinctly* [15:07] jdstrand, yes agree different issue same underlying issue... [15:08] jdstrand, agree well let me do some attempts here... I am working on getting cdk and juju log output so we can gather logs for later troubleshooting... having access to the $USER env is a must [15:10] lborda: the individual snaps have that. snap-confine does not. it is the way you are gathering the output that is causing snap-confine to become entangled. snap-confine has access to /dev/stdout and /dev/stderr, so if you can adjsut your calls to use those, you should be fine [15:10] which communicate() should do (untested) [15:10] jdstrand, yes looks like it! :) give me a few to make changes here [15:14] hi, is there any apparmor stuff still working when snap is installed in devmode? [15:15] after I upgraded Qt to the latest version in my snap, I can't get qt webkit running for whatever reason, even though it's still at the same version and only qt's version went up (and all other libraries it comes with) [15:15] it works fine on the raspbian with 0 issues [15:15] does not start even in devmode on the core [15:20] re [15:20] mvo: thank you :) [15:21] jdstrand: hello :-) [15:30] jdstrand: I sent a small patch to snap-confine, your review is required https://github.com/snapcore/snapd/pull/6498 [15:30] PR #6498: cmd/libsnap: add cgroup-pids-support module [15:30] PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6079, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6381, snapd#6401, snapd#6404, [15:30] snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6492, snapd#6498, snapd#6502, snapd#6532, snapd#6539, snapd#6541, snapd#6549, snapd#6553, snapd#6556, snapd#6559 [15:31] PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6079, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6381, snapd#6401, snapd#6404, [15:31] snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6492, snapd#6498, snapd#6502, snapd#6532, snapd#6539, snapd#6541, snapd#6549, snapd#6553, snapd#6556, snapd#6559 [15:36] sborovkov: in devmode, apparmor is set to allow everything but log [15:37] sborovkov: seccomp, also [15:47] Chipaca, so basically nothing is forbidden? the only messages I see bbefore it crashes is that it can't create some kind of udev monitor and send some dbus commands to NetworkManager which is followed by "could not create AF_NETLINK socket" and a crash of process [15:48] sborovkov: nothing is forbidden by apparmor / seccomp, but the view of the system remains the same as in strict [15:49] I guess the cause should be somewhere in there then :( [15:51] sborovkov: don't you get anything in the system logs? [15:52] all I see are those errors, I pasted above, it crashes right after bbeing unable to create AF_NETLINK socket [15:52] I thought it'd work in the devmode at least but that's not the case [15:53] I guess I will try to get that process running in gdb. [15:55] sborovkov: snap run --gdb ? [15:56] I did not even know that was a thing now :) [15:57] sborovkov: also 'snap run --strace' :-) [15:57] and trace-exec … [15:57] it's getting all fancy and grown-up [15:58] that's pretty cool, not sure it's going to work for me though - my main process is not crashing [15:58] webb process does [15:59] and I have done bind mount of the directory containing modified snap so gdb spews out some errors because of that I guess [16:41] popey: hey, sublime-text doesn't work on 18.10 [16:42] I'm not sure what happened because it used to work [17:00] could anyone with appropriate permissions please click "retry" there ? https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834/+build/482950 [17:00] om26er: done [17:00] apparently the upload to store failed and I can't retry (and I am not admin on that said repo to force a rebuild) [17:00] cjwatson, thanks :) === pstolowski is now known as pstolowski|afk [17:04] PR snapd#6560 opened: cmd/snap-confine: drop uid from random /tmp name [17:09] 6549 needs a second review [17:10] PR snapd#6079 closed: cmd/snap: `snap connections` command [17:11] \o/ [17:11] pstolowski|afk: I will merge 6322 - I had some nitpicks (mostly tests) but can all be followups [17:12] pedronis: want to look at 6322 again before it goes in ? [17:12] 6492 also needs a second review [17:13] mvo: 6322 should be fine if you are ok with [17:13] mvo: yes, 6492 is next on my list [17:14] pedronis: I think you did 6492 already :) [17:14] mvo: ah, yes, was confusing it with another one [17:14] pstolowski|afk: nice job on 6322 btw, I find this easier to read than the old code [17:14] PR snapd#6322 closed: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get [17:15] pedronis: ok, I hope I did not merge too early then :/ [17:48] PR snapd#6561 opened: cmd/snap-confine: chown private /tmp to root.root [17:48] jdstrand: I opened one more cleanup from my review of older notes ^ [17:51] pedronis: design quesion, should the contents of private /tmp directory be preserved across "snap refresh" of said snap? [17:56] zyga: you mean in a world where we are sure nothing runs of the snap during the refresh? [17:58] pedronis: yes [17:58] pedronis: should it retain contents across refresh? [17:58] pedronis: today it doesn't but I don't think that was deliberae [17:58] *deliberate [17:59] pedronis: it could easily do so [18:01] zyga: that's interesting because I would have expected the reverse [18:01] pedronis: why? [18:02] pedronis: or sorry, reverse as in, it is retained? [18:02] because if stuff can be running, how can we delete its content? [18:02] we don't technically delete the contents [18:02] it's a tmpfs in the namespace? [18:02] ah, wait, I think I was mistaken a little, the conditions are more complex [18:03] it's not a tmpfs, it's a real directory in /tmp [18:03] we "delete" it when the base snap changes [18:03] but retain it while refreshing [18:03] I was thinking of refreshes but it is really the base that matters here, not the app [18:04] so the question, asked properly is: should we retain the /tmp that snaps see when the base has refreshed (we currently do not) [18:04] I need to go have dinner, seems I need to understand this more [18:05] pedronis: sure, it's not urgent, just observation from the two tiny patches I posted [18:12] jdstrand: hey, I posted https://github.com/snapcore/snapd/pull/6559 with some apparmor-y things in relation to your 2.13 work [18:12] PR #6559: pkg/apparmor: scratch documentation of apparmor [18:13] jdstrand: I understand 2.13 is urgent so I don't want to block your PR but I would like to know what you think about the ideas I posted [18:32] * zyga EODs [18:33] mvo: I tried to answer your naming nitpick, let me know === tobias is now known as Guest93332 [20:16] PR snapcraft#2494 opened: sources: handle network request errors === devil is now known as Guest97162