| mborzecki | morning | 07:03 |
|---|---|---|
| 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:31 |
| 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:41 |
| mvo | mborzecki: works for me | 07:55 |
| mvo | mborzecki: thanks for this, I would love to have it in 2.49 | 07:56 |
| pstolowski | morning | 08:01 |
| mvo | good morning pstolowski | 08:03 |
| mborzecki | pstolowski: hey | 08:05 |
| mvo | pstolowski: good morning | 08:10 |
| mborzecki | hmm why are the unit test results not cached between runs in github | 08:21 |
| mborzecki | looks like the withbootassetstesting tag adds ~4m of the unit test job as all test get run | 08:22 |
| mborzecki | hmm same for nosecboot tag | 08:23 |
| mborzecki | maybe it's because govendor sync runs in between | 08:24 |
| 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> | 08:36 |
| 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:13 |
| pedronis | mborzecki: mvo: hi, is there a reason why the code in mountedfilesystem.go tends to use VolumeContent instead of LaidOutContent ? | 13:38 |
| mborzecki | pedronis: because it's a regular filesystem content, one cannot specify its position using start offsets | 13:39 |
| pedronis | mborzecki: but we could use LaidOutContent, or not? | 13:40 |
| 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:41 |
| pedronis | I see | 13:43 |
| 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:53 |
| 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:57 |
| mup | PR snapd#9863 opened: tests: use 6 spread workers for centos8 <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9863> | 13:58 |
| 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:37 |
| 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/ | 14:49 |
| ijohnson | hmm do we have a way to silence seccomp denials ? | 15:02 |
| 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:03 |
| * cachio lunch | 15:05 | |
| 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:07 |
| 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:08 |
| mborzecki | ijohnson: we need to run that by security though, don't we? | 15:09 |
| ijohnson | yes it would need a security review | 15:09 |
| 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:10 |
| mborzecki | maybe two, if one adds a comment | 15:11 |
| 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:18 |
| 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:19 |
| 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:24 |
| 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:30 |
| 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/ | 15:31 |
| === jamespage_ is now known as jamespage | ||
| 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:02 |
| cachio | ijohnson, checking | 16:30 |
| cachio | thnaks for sharing this | 16:30 |
| 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:32 |
| cachio | yes, need to google a bit | 16:34 |
| 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> | 17:19 |
| mup | PR snapd#9866 opened: osutil/stat.go: add RegularFileExists <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9866> | 18:04 |
| === ijohnson is now known as ijohnson|lunch | ||
| === ijohnson|lunch is now known as ijohnson | ||
| 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:14 |
| jdstrand | stgraber: ah, yes. https://linuxcontainers.org/lxd/getting-started-cli/#choose-your-release | 19:15 |
| jdstrand | stgraber: nm | 19:15 |
| mup | PR snapcraft#3431 opened: godeps spread test: use latest/stable go snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3431> | 19:17 |
| bandali | hi, does one have to anything special to use ssl certs in a snap? | 20:12 |
| bandali | s/have to/have to do/ | 20:13 |
| ijohnson | bandali: can you be more specific? what are you trying to do ? | 21:14 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| bandali | huh, /etc/ssl/certs is empty there | 21:27 |
| ijohnson | bandali: what OS are you on ? | 21:27 |
| 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:29 |
| 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:34 |
| 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> | 21:36 |
| bandali | interesting... looks like /etc/ssl/certs does in fact include certificates | 22:04 |
| 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:09 |
| ijohnson | that would certainly explain it | 22:11 |
| bandali | :-) what a rabbithole. quite curious to see where it leads | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!