[07:03] morning [07:31] PR snapd#9819 closed: snap-confine: make host /etc/ssl available for snaps on classic

[07:41] mvo: hey, i think we should land the errno fix that you have and try to look into cleaning up the errno mess in our code [07:41] mvo: maybe it's as simple as having a separate die_with_error(..) that takes explicit errno parameter like we discussed with zyga [07:55] mborzecki: works for me [07:56] mborzecki: thanks for this, I would love to have it in 2.49 [08:01] morning [08:03] good morning pstolowski [08:05] pstolowski: hey [08:10] pstolowski: good morning [08:21] hmm why are the unit test results not cached between runs in github [08:22] looks like the withbootassetstesting tag adds ~4m of the unit test job as all test get run [08:23] hmm same for nosecboot tag [08:24] maybe it's because govendor sync runs in between [08:36] PR snapd#9837 closed: cmd/snap-repair: filter repair assertions based on bases + modes [13:13] PR snapd#9848 closed: overlord/devicestate, sysconfig: do nothing when cloud-init is not present [13:38] mborzecki: mvo: hi, is there a reason why the code in mountedfilesystem.go tends to use VolumeContent instead of LaidOutContent ? [13:39] pedronis: because it's a regular filesystem content, one cannot specify its position using start offsets [13:40] mborzecki: but we could use LaidOutContent, or not? [13:41] mborzecki: I mean the input is ps *LaidOutStructure but then we don't use the LaidOut bits [13:41] pedronis: i mean LaidOutContent is defined as having only raw content, we could not be populating it even for a filesystem structure [13:43] I see [13:53] PR snapd#9862 opened: github, run-checks: do not collect coverage data on subsequent test runs [13:57] PR snapcraft#3429 closed: plugins: Pin pip to supported versions [13:58] PR snapd#9863 opened: tests: use 6 spread workers for centos8 [14:37] PR snapcraft#3428 closed: plugins v1: Pin pip to supported versions [14:49] hmmmm the first run-checks --unit run on my system is ~5m, then with SKIP_COVERAGE i added in 9848, removing secboot & setting the build tag as we do in gothub test workflow it's 20s, but it seems to be different on gh [14:49] s/9848/9862/ [15:02] hmm do we have a way to silence seccomp denials ? [15:03] I know we have `deny` for apparmor, but do we have a similar mechanism for seccomp ? [15:03] PR snapd#9852 closed: gadget: enable multi-volume uc20 gadgets in LaidOutSystemVolumeFromGadget; rename too [15:05] * cachio lunch [15:07] ijohnson: there's log, but that logs ;) [15:07] and it's the default iirc [15:07] right [15:07] ijohnson: i understand you're referring to that sched_setaffinity thing [15:07] mborzecki: yeah [15:07] it just occurred to me that I don't know how to silence seccomp denials [15:07] ijohnson: i think we should just make that part of the browser-support [15:08] yeah I think so too [15:08] browser-sandbox: true already allows lots of other dangerous things anyways [15:08] imo it's a valid use case to pin a thread to some cpu in a browser [15:08] given how performance optimized they are [15:09] ijohnson: we need to run that by security though, don't we? [15:09] yes it would need a security review [15:10] reviews and spread runs will take longer than the change anywa ;), it's a one liner afaict [15:10] haha yes true [15:11] maybe two, if one adds a comment [15:18] cachio: have you ever seen this sort of nested failure? https://pastebin.ubuntu.com/p/ZJs5wYRpYb/ [15:18] ``` [15:18] Code=qemu-system-x86_64: /build/qemu-uc0X9e/qemu-4.2/include/hw/core/cpu.h:633: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. [15:18] ``` [15:19] PR snapd#9864 opened: gadget/gadget.go: rename ubuntu-* to system-* in doc-comment [15:19] cachio: or I guess a better log is this pastebin https://pastebin.ubuntu.com/p/kxPs7ZZxCs/ [15:24] PR snapd#9865 opened: interfaces/browser-support: allow sched_setaffinity with browser-sandbox: true [15:30] ijohnson: re seccomp denials, we do not on a per rule basis. it would be possible to add a flag similar to 'unrestricted' to tell the compiler to not log [15:30] jdstrand: hey! so that would be a change in snap-seccomp compiler, correct ? [15:31] ijohnson: yes, and would be 'profile wide' (ie, not concept of per-rule) [15:31] no* [15:31] hmm I see [15:31] cachio: I see another case of that odd qemu failure: https://pastebin.ubuntu.com/p/X8VYMzdwZ4/ === jamespage_ is now known as jamespage [16:02] PR snapcraft#3430 opened: More improvements for using python3.8 from within a snap [16:30] ijohnson, checking [16:30] thnaks for sharing this [16:32] cachio: np, have you seen it before? [16:32] no, first time [16:32] it doesn't happen every time, just sometimes, it's very weird [16:34] yes, need to google a bit [17:19] PR snapd#9857 closed: bootloader/assets: support injecting bootloader assets in testing builds of snapd [18:04] PR snapd#9866 opened: osutil/stat.go: add RegularFileExists === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [19:14] stgraber: hey, so according to https://ubuntu.com/blog/lxd-4-0-lts-stable-release-is-now-available 4.0/stable is the lts, right? [19:15] stgraber: ah, yes. https://linuxcontainers.org/lxd/getting-started-cli/#choose-your-release [19:15] stgraber: nm [19:17] PR snapcraft#3431 opened: godeps spread test: use latest/stable go snap [20:12] hi, does one have to anything special to use ssl certs in a snap? [20:13] s/have to/have to do/ [21:14] bandali: can you be more specific? what are you trying to do ? [21:19] ijohnson, the jami snap has been failing to make connections over https to https://ns.jami.net, and i'm wondering if we have to do any hacks/worksarounds to fix it [21:19] it works in basically every other scenario/environment [21:19] bandali: hmm that website seems to have a valid SSL cert so I'm not sure what the problem would be [21:20] bandali: how does the problem manifest itself? [21:20] i think it's due to absence of certs in /etc/ssl/certs [21:20] ijohnson, you can try reproduce this by `snap install jami`, then try to create a new account and register a username [21:20] it will try to make a connection to https://ns.jami.net/name/yourdesiredusername but it always fails [21:21] bandali: at least with another strictly confined snap, I can access that site just fine with curl from inside the snap's environment [21:23] ijohnson, ha. we use a low-level cpp library, asio, which basically interfaces with openssl or libressl and calls its SSL_CTX_set_default_verify_paths [21:23] bandali: well using curl it seems to be fine, I guess I don't see why it wouldn't work from inside a strict snap [21:23] you have access to the ssl certs from the base snap that jami uses [21:24] ijohnson, do we have to set any special envs/paths like SSL_CERT_DIR for that to work? [21:24] I don't know, that depends on what libraries you are using [21:24] cjp256 also mentioned (in #snapcraft) that ssl certs are available from the base snap; and i'm wondering where its location/path is, and if we had to set any envs [21:25] bandali: it should be available from /etc/ssl/certs [21:25] as i mentioned, we use asio which in turns uses openssl or libressl [21:25] ijohnson, would that get packaged/included in the produced jami snap file itself? [21:25] because as of now etc/ssl/certs in the jami snap file doesn't exist and/or is empty [21:26] bandali: no that comes from the snap's base snap, if you isntall the snap and then run `snap run --shell jami` you can do `ls /etc/ssl/certs` and see the ssl certs from the base snap [21:26] i see. thanks i'll try that in a sec to be sure [21:27] huh, /etc/ssl/certs is empty there [21:27] bandali: what OS are you on ? [21:29] ijohnson, this is on a ubuntu 20.10 vm. though, i was recently trying with adding ca-certificates to stage-packages and setting a layout bind at /etc/ssl/certs as a workaround. i commented those out and am doing a quick rebuild to try again to be sure [21:34] oh, turns out a 'quick rebuild' is unfortunately a full rebuild :-p i'll report back in 30-40 mins or so :-) [21:34] :-) [21:36] PR snapd#9863 closed: tests: use 6 spread workers for centos8 [22:04] interesting... looks like /etc/ssl/certs does in fact include certificates [22:09] upon a closer look (using strace), it seems we're for some reason trying to look up certs in /root/parts/jami/build/daemon/contrib/x86_64-linux-gnu/etc/ssl rather than /etc/ssl. i'll see if other jami devs have any idea as to why [22:11] that would certainly explain it [22:14] :-) what a rabbithole. quite curious to see where it leads