[07:03] <mborzecki> morning
[07:31] <mup> PR snapd#9819 closed: snap-confine: make host /etc/ssl available for snaps on classic <Needs Samuele review> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9819>
[07:41] <mborzecki> 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] <mborzecki> 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] <mvo> mborzecki: works for me
[07:56] <mvo> mborzecki: thanks for this, I would love to have it in 2.49
[08:01] <pstolowski> morning
[08:03] <mvo> good morning pstolowski
[08:05] <mborzecki> pstolowski: hey
[08:10] <mvo> pstolowski: good morning
[08:21] <mborzecki> hmm why are the unit test results not cached between runs in github
[08:22] <mborzecki> looks like the withbootassetstesting tag adds ~4m of the unit test job as all test get run
[08:23] <mborzecki> hmm same for nosecboot tag
[08:24] <mborzecki> maybe it's because govendor sync runs in between
[08:36] <mup> PR snapd#9837 closed: cmd/snap-repair: filter repair assertions based on bases + modes <Needs Samuele review> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9837>
[13:13] <mup> PR snapd#9848 closed: overlord/devicestate, sysconfig: do nothing when cloud-init is not present <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9848>
[13:38] <pedronis> mborzecki: mvo:  hi, is there a reason why the code in mountedfilesystem.go tends to use VolumeContent instead of LaidOutContent ?
[13:39] <mborzecki> pedronis: because it's a regular filesystem content, one cannot specify its position using start offsets
[13:40] <pedronis> mborzecki: but we could use LaidOutContent, or not?
[13:41] <pedronis> mborzecki: I mean the input is ps         *LaidOutStructure  but then we don't use the LaidOut bits
[13:41] <mborzecki> pedronis: i mean LaidOutContent is defined as having only raw content, we could not be populating it even for a filesystem structure
[13:43] <pedronis> I see
[13:53] <mup> PR snapd#9862 opened: github, run-checks: do not collect coverage data on subsequent test runs <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9862>
[13:57] <mup> PR snapcraft#3429 closed: plugins: Pin pip to supported versions <Created by philroche> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3429>
[13:58] <mup> PR snapd#9863 opened: tests: use 6 spread workers for centos8 <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9863>
[14:37] <mup> PR snapcraft#3428 closed: plugins v1: Pin pip to supported versions <Created by philroche> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3428>
[14:49] <mborzecki> 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] <mborzecki> s/9848/9862/
[15:02] <ijohnson> hmm do we have a way to silence seccomp denials ?
[15:03] <ijohnson> I know we have `deny` for apparmor, but do we have a similar mechanism for seccomp ?
[15:03] <mup> PR snapd#9852 closed: gadget: enable multi-volume uc20 gadgets in  LaidOutSystemVolumeFromGadget; rename too <Bug> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9852>
[15:05]  * cachio lunch
[15:07] <mborzecki> ijohnson: there's log, but that logs ;)
[15:07] <mborzecki> and it's the default iirc
[15:07] <ijohnson> right
[15:07] <mborzecki> ijohnson: i understand you're referring to that sched_setaffinity thing
[15:07] <ijohnson> mborzecki: yeah
[15:07] <ijohnson> it just occurred to me that I don't know how to silence seccomp denials
[15:07] <mborzecki> ijohnson: i think we should just make that part of the browser-support
[15:08] <ijohnson> yeah I think so too
[15:08] <ijohnson> browser-sandbox: true already allows lots of other dangerous things anyways
[15:08] <mborzecki> imo it's a valid use case to pin a thread to some cpu in a browser
[15:08] <mborzecki> given how performance optimized they are
[15:09] <mborzecki> ijohnson: we need to run that by security though, don't we?
[15:09] <ijohnson> yes it would need a security review
[15:10] <mborzecki> reviews and spread runs will take longer than the change anywa ;), it's a one liner afaict
[15:10] <ijohnson> haha yes true
[15:11] <mborzecki> maybe two, if one adds a comment
[15:18] <ijohnson> cachio: have you ever seen this sort of nested failure? https://pastebin.ubuntu.com/p/ZJs5wYRpYb/
[15:18] <ijohnson> ```
[15:18] <ijohnson> 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] <ijohnson> ```
[15:19] <mup> PR snapd#9864 opened: gadget/gadget.go: rename ubuntu-* to system-* in doc-comment <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9864>
[15:19] <ijohnson> cachio: or I guess a better log is this pastebin https://pastebin.ubuntu.com/p/kxPs7ZZxCs/
[15:24] <mup> PR snapd#9865 opened: interfaces/browser-support: allow sched_setaffinity with browser-sandbox: true <Bug> <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9865>
[15:30] <jdstrand> 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] <ijohnson> jdstrand: hey! so that would be a change in snap-seccomp compiler, correct ?
[15:31] <jdstrand> ijohnson: yes, and would be 'profile wide' (ie, not concept of per-rule)
[15:31] <jdstrand> no*
[15:31] <ijohnson> hmm I see
[15:31] <ijohnson> cachio: I see another case of that odd qemu failure: https://pastebin.ubuntu.com/p/X8VYMzdwZ4/
[16:02] <mup> PR snapcraft#3430 opened: More improvements for using python3.8 from within a snap <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3430>
[16:30] <cachio> ijohnson, checking
[16:30] <cachio> thnaks for sharing this
[16:32] <ijohnson> cachio: np, have you seen it before?
[16:32] <cachio> no, first time
[16:32] <ijohnson> it doesn't happen every time, just sometimes, it's very weird
[16:34] <cachio> yes, need to google a bit
[17:19] <mup> PR snapd#9857 closed: bootloader/assets: support injecting bootloader assets in testing builds of snapd <Run nested> <Simple 😃> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9857>
[18:04] <mup> PR snapd#9866 opened: osutil/stat.go: add RegularFileExists <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9866>
[19:14] <jdstrand> 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] <jdstrand> stgraber: ah, yes. https://linuxcontainers.org/lxd/getting-started-cli/#choose-your-release
[19:15] <jdstrand> stgraber: nm
[19:17] <mup> PR snapcraft#3431 opened: godeps spread test: use latest/stable go snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3431>
[20:12] <bandali> hi, does one have to anything special to use ssl certs in a snap?
[20:13] <bandali> s/have to/have to do/
[21:14] <ijohnson> bandali: can you be more specific? what are you trying to do ?
[21:19] <bandali> 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] <bandali> it works in basically every other scenario/environment
[21:19] <ijohnson> bandali: hmm that website seems to have a valid SSL cert so I'm not sure what the problem would be
[21:20] <ijohnson> bandali: how does the problem manifest itself?
[21:20] <bandali> i think it's due to absence of certs in /etc/ssl/certs
[21:20] <bandali> ijohnson, you can try reproduce this by `snap install jami`, then try to create a new account and register a username
[21:20] <bandali> it will try to make a connection to https://ns.jami.net/name/yourdesiredusername but it always fails
[21:21] <ijohnson> 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] <bandali> 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] <ijohnson> 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] <ijohnson> you have access to the ssl certs from the base snap that jami uses
[21:24] <bandali> ijohnson, do we have to set any special envs/paths like SSL_CERT_DIR for that to work?
[21:24] <ijohnson> I don't know, that depends on what libraries you are using
[21:24] <bandali> 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] <ijohnson> bandali: it should be available from /etc/ssl/certs
[21:25] <bandali> as i mentioned, we use asio which in turns uses openssl or libressl
[21:25] <bandali> ijohnson, would that get packaged/included in the produced jami snap file itself?
[21:25] <bandali> because as of now etc/ssl/certs in the jami snap file doesn't exist and/or is empty
[21:26] <ijohnson> 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] <bandali> i see. thanks i'll try that in a sec to be sure
[21:27] <bandali> huh, /etc/ssl/certs is empty there
[21:27] <ijohnson> bandali: what OS are you on ?
[21:29] <bandali> 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] <bandali> oh, turns out a 'quick rebuild' is unfortunately a full rebuild :-p i'll report back in 30-40 mins or so :-)
[21:34] <ijohnson> :-)
[21:36] <mup> PR snapd#9863 closed: tests: use 6 spread workers for centos8 <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9863>
[22:04] <bandali> interesting... looks like /etc/ssl/certs does in fact include certificates
[22:09] <bandali> 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] <ijohnson> that would certainly explain it
[22:14] <bandali> :-) what a rabbithole. quite curious to see where it leads