| mup | PR snapcraft#1948 closed: tests: move test files out of the snapcraft dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1948> | 03:33 |
|---|---|---|
| mborzecki | morning | 06:05 |
| mborzecki | mvo: morning | 07:25 |
| mborzecki | mvo: someone on arch tried to use `snap run --gdb` to debug a segfault with nvidia, they had some problems though so i'm trying to find out more | 07:28 |
| mvo | mborzecki: aha, interessting. yeah, this is super new. keen to learn more about the exact issues | 07:30 |
| mborzecki | zyga: hey, feeling better? | 07:37 |
| zyga | mborzecki hey | 07:37 |
| zyga | yeah I feel better | 07:37 |
| zyga | I think the worst is over now, I'll try to help as much as I can now | 07:37 |
| mborzecki | zyga: take it easy ;) no use if end up getting worse | 07:39 |
| zyga | thanks, I'm wrapped in blanket and dressed like an onion | 07:40 |
| mvo | zyga: hey, welcome back. yeah, be careful and take it easy. I wonder how long I will last, my kids are sick too | 07:42 |
| zyga | is it flu as well? | 07:42 |
| zyga | I had fever for a few days but now it's (almost) good, I hope your kids are better quickly | 07:43 |
| mvo | zyga: yeah, fever and all that | 07:45 |
| kalikiana | good morning | 07:50 |
| kalikiana | zyga: are you using tor as well? ;-) | 07:51 |
| zyga | kalikiana, no I don't use tor | 07:52 |
| kalikiana | Just thinking you are dressed accordingly at least | 07:52 |
| zyga | aahh | 07:52 |
| zyga | :D | 07:52 |
| zyga | sorry, I'm slow on jokes today | 07:52 |
| zyga | yeah, I wish there was a flu firewall ;) | 07:53 |
| kalikiana | Avoid touching your face with your own hands ever unless you cleaned your hands | 07:55 |
| zyga | can I git push? :) | 07:55 |
| kalikiana | You can you the keyboard, it's the dirtiest thing around you anyways | 07:56 |
| kalikiana | *touch | 07:56 |
| zyga | I clean my keyboard regularly but yeah | 07:56 |
| mwhudson | snap download going extremely slowly for me for some reason :/ | 08:12 |
| mwhudson | 35 kB/s | 08:13 |
| pstolowski | morning! | 08:20 |
| zyga | hey pawel | 08:26 |
| zyga | mwhudson are you being redirected to some CDN on the other side of the planet? | 08:26 |
| mwhudson | zyga: how would i tell? | 08:26 |
| mwhudson | it was fast yesterday i think... | 08:26 |
| zyga | mwhudson mmm, good question | 08:26 |
| zyga | I don't know | 08:26 |
| mborzecki | pstolowski: hey | 08:26 |
| mwhudson | but that might have been office vs home | 08:26 |
| zyga | mwhudson btw, kudos on the installer work, it's stellar! | 08:26 |
| mwhudson | zyga: thanks, it's ok :) | 08:30 |
| pstolowski | zyga, hey, can you revoke your approval of #4358 (I don't seem to be able to)? there were many additions that it mandates 2 reviews again I'm afraid | 08:35 |
| mup | PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358> | 08:35 |
| zyga | sure | 08:35 |
| pstolowski | thankx | 08:36 |
| mborzecki | travis jobs timing out again? | 09:03 |
| Chipaca | *yawn* | 09:09 |
| zyga | hey John | 09:14 |
| pedronis | Chipaca: hi | 09:21 |
| Chipaca | zyga: pedronis: hiya | 09:22 |
| Chipaca | zyga: are you back amongst the living? | 09:22 |
| zyga | hey pedronis :-) | 09:22 |
| zyga | Chipaca yeah, more or less | 09:22 |
| * Son_Goku rises from the dead | 09:28 | |
| mborzecki | guys, should we have a content snap with debugging symbols for the core? | 09:54 |
| mup | PR snapd#4715 opened: store: reorg auth refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4715> | 09:54 |
| pedronis | Chipaca: this ^ might be something for you to review | 09:54 |
| zyga | mborzecki very interesting and big problem to solve correctly (ideally with gdb support for snap run --gdb) | 09:55 |
| mborzecki | an example, a user found a segfault that happens with nvidia drivers and snaps that require acceleration, he tried to use snap run --gdb, got this https://hastebin.com/sutuguquxu backtrace points to libc (probably something corrupt) but it's hard to discern what has really happened | 09:55 |
| mvo | hrm, a pastebin that requires javascript to display text *grumpf* | 09:57 |
| pedronis | mvo: I +1ed #4103, but there were quite a few changes since Gustavo's +1, I think it needs a 2nd review again, not sure if by Gustavo or somebody else, maybe pawel | 10:09 |
| mup | PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103> | 10:09 |
| pedronis | Chipaca: mvo: what do you think of a PR that does s/remoteRepoTestSuite/storeTestSuite/ s/UbuntuStoreRepository// in store/store_test.go | 10:17 |
| Chipaca | pedronis: +33 | 10:17 |
| pedronis | Chipaca: ok, once a couple of other PRs touching store have landed I can do that, seems a clean up that is quite overdue | 10:18 |
| pstolowski | pedronis, mvo curious about your opinion on https://forum.snapcraft.io/t/snap-set-xxx-requires-configure-hook/4134 | 10:24 |
| pedronis | pstolowski: my impression is that is something we could revisit when we have configuration schemas | 10:25 |
| pstolowski | pedronis, right, good idea. that will ensure people don't add more config garbage | 10:26 |
| pedronis | once we have schemas to say what is the config/who can read it, then it might make sense to make configure optional | 10:27 |
| pstolowski | +1 | 10:28 |
| mborzecki | hmm: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/main/binary-amd64/Packages Hash Sum mismatch | 10:28 |
| pedronis | mvo: there's a failure of tests/main/snap-service-refresh-mode on suse here: https://travis-ci.org/snapcore/snapd/builds/344719396?utm_source=github_status&utm_medium=notification | 10:32 |
| pedronis | plus the Hash Sum mismatch stuff | 10:32 |
| Son_Goku | zyga, mvo: new errors from gcc | 10:36 |
| Son_Goku | libsnap-confine-private/locking-test.c: In function 'sc_test_use_fake_lock_dir': | 10:36 |
| Son_Goku | libsnap-confine-private/locking-test.c:53:24: error: cast between incompatible function types from 'int (*)(const char *)' to 'void (*)(void *)' [-Werror=cast-function-type] | 10:36 |
| Son_Goku | g_test_queue_destroy((GDestroyNotify) unsetenv, | 10:36 |
| Son_Goku | ^ | 10:36 |
| Son_Goku | cc1: all warnings being treated as errors | 10:36 |
| Son_Goku | make[1]: *** [Makefile:1571: libsnap-confine-private/libsnap_confine_private_unit_tests-locking-test.o] Error 1 | 10:36 |
| zyga | Son_Goku oho, thanks I will fix that shortly | 10:36 |
| mup | PR snapd#4716 opened: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <https://github.com/snapcore/snapd/pull/4716> | 10:38 |
| mup | PR snapd#4717 opened: cmd/snap-update-ns,testutil: move syscall testing helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4717> | 10:56 |
| mup | PR snapd#4718 opened: tests: disable interfaces-location-control on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/4718> | 10:57 |
| zyga | mvo ^ this is the first chunk of the move, it turned out to be pretty harmless actually, the diff is mostly caused by me writing tests for the testing helperrs | 10:58 |
| * zyga -> break for lunch and meds | 10:59 | |
| mup | PR core#81 opened: 14-set-motd.chroot: updated based on the suggestions from Mark <Created by mvo5> <https://github.com/snapcore/core/pull/81> | 11:04 |
| * pstolowski lunch | 11:19 | |
| * pstolowski lunch | 11:23 | |
| === wiking_ is now known as wiking | ||
| === stokachu_ is now known as stokachu | ||
| niemeyer | Heya | 11:34 |
| niemeyer | chipaca, mvo: Around? | 11:35 |
| Chipaca | niemeyer: o/ | 11:35 |
| niemeyer | Hey | 11:35 |
| zyga | hey niemeyer | 11:36 |
| niemeyer | Chipaca: did you catch up with mvo about command not found? | 11:36 |
| Chipaca | niemeyer: a little last night; last i heard there was more discussion to be had | 11:37 |
| niemeyer | We said we'd have a call yesterday and I missed it.. Want to make sure you are in sync about the discussion in the meeting yesterday before spending time in a diff direction | 11:37 |
| Chipaca | niemeyer: i am not spending time on it, pending those discussions | 11:37 |
| niemeyer | Mark suggested a simpler approach, which looks fine to me | 11:38 |
| niemeyer | Has less data | 11:38 |
| niemeyer | We didn't agree on an output for the fuZy case but it should be easy to extrapolate | 11:38 |
| niemeyer | He also recommended c-nf to be its own tool for the output to not go out of sync between the different backends | 11:39 |
| niemeyer | Which is also fine since he understands we won't be able to change the output so easily | 11:40 |
| mup | PR snapd#4719 opened: timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4719> | 11:41 |
| niemeyer | I would like to preserve the idea of us using a command on our end, though, instead of having c-n-f coonsulting a file by itself.. The command can put json out | 11:41 |
| niemeyer | The rationale for that is being able to evolve the implementation without having to keep historical data around that arbitrary tools depend on | 11:42 |
| niemeyer | Chipaca: Those are the main points, I think | 11:42 |
| niemeyer | Or at least the main points that seem worth typing on a phone :) | 11:43 |
| Chipaca | niemeyer: ack. Not much for me in that; will await further news. | 11:48 |
| === cjwatson_ is now known as cjwatson | ||
| mup | PR snapd#4720 opened: interfaces: add xdg-desktop-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4720> | 12:04 |
| Chipaca | mvo: need to go to the school for a meeting, probably won't make it back for the standup | 12:17 |
| zyga | mborzecki can you please have a look at https://github.com/snapcore/snapd/pull/4717 | 12:26 |
| mup | PR #4717: cmd/snap-update-ns,testutil: move syscall testing helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4717> | 12:26 |
| ogra_ | mvo, is there anything wrong with the PPA seems all nightly core snap builds failed with PPA errors ... https://launchpadlibrarian.net/357979314/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz | 12:26 |
| zyga | most of the diff is just new unit tests | 12:26 |
| mborzecki | zyga: ok | 12:26 |
| zyga | but have a look at the API in general, I'd like to turn it from "locally crafted helper" to "semi reusable helper" | 12:26 |
| zyga | hey ogra_ | 12:26 |
| * zyga looks | 12:26 | |
| ogra_ | hmm, ut different PPA issues in the different arches | 12:27 |
| zyga | launchpad was offline for some maintenance lately, maybe that is related | 12:27 |
| ogra_ | thats weird | 12:27 |
| ogra_ | ah | 12:27 |
| ogra_ | yeah, that might be it | 12:27 |
| zyga | though not really sure | 12:27 |
| zyga | does it happen now or is that log from last night | 12:27 |
| ogra_ | thats from 5:20 this morning | 12:28 |
| ogra_ | but arm64 has an internal server error for the PPA https://launchpadlibrarian.net/357979358/buildlog_snap_ubuntu_xenial_arm64_core_BUILDING.txt.gz | 12:29 |
| ogra_ | so i guess it was that maintenance window | 12:29 |
| zyga | yeah, could be | 12:29 |
| cjwatson | There were some reboots which weren't completely perfectly coordinated. Just retry those. | 12:36 |
| pedronis | mborzecki: wasn't the issue here addressed: https://travis-ci.org/snapcore/snapd/builds/344749295?utm_source=github_status&utm_medium=notification | 12:39 |
| pedronis | I merged master in that branch | 12:40 |
| mborzecki | pedronis: looking | 12:41 |
| pstolowski | mvo, "mainframe does not change location that often", love that :D | 12:43 |
| pedronis | mborzecki: ah, the test seems to need to be fixed too | 12:44 |
| mborzecki | pedronis: hah right | 12:44 |
| mborzecki | pedronis: are you fixing this or should i? | 12:45 |
| pedronis | I can fix it I suppose | 12:45 |
| pedronis | mborzecki: I find the original code a bit strange to be honest | 12:53 |
| mborzecki | pedronis: you mean globbing & stuff? | 12:53 |
| pedronis | I mean all this replacing | 12:53 |
| pedronis | but not your fault | 12:54 |
| pedronis | seems just odd | 12:54 |
| mvo | ogra_: thanks, I have not seen this error yet, hope its transient? | 13:02 |
| kalikiana | re | 13:17 |
| ogra_ | mvo, i fired off a new auto-build, then we will know soon | 13:36 |
| ackk | hi, is something special required in the snap to make xdg-open work? I have the snapd-xdg-open package installed (this is artful) | 13:36 |
| magicaltrout | has the snap store died a death? | 13:37 |
| zyga | ackk it depends on what you want to open | 13:37 |
| ackk | zyga, web url | 13:37 |
| zyga | ackk then it should just work | 13:37 |
| zyga | what happens when you try? | 13:37 |
| ackk | zyga, https://pastebin.canonical.com/p/WhvMqTgCDx/ | 13:38 |
| ackk | zyga, note that is a --devmode snap installed via snap try | 13:38 |
| ackk | (if it makes a difference) | 13:38 |
| zyga | ah | 13:38 |
| zyga | don't ship xdg-open | 13:38 |
| ackk | ah you mean it's trying to use the wrong one? | 13:39 |
| zyga | kalikiana ^ snapcraft should not bundle xdg-open deb as it will just break things | 13:39 |
| zyga | yes, it's using the regular one and that's shadowing the magic one | 13:39 |
| zyga | magicaltrout what are you seeing? | 13:39 |
| magicaltrout | api.snapcraft.io is 503ing | 13:39 |
| magicaltrout | can't install anything | 13:40 |
| mborzecki | mvo: the 2.31-maybe PR I mentioned: https://github.com/snapcore/snapd/pull/4594 | 13:41 |
| mup | PR #4594: systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4594> | 13:41 |
| ahasenack | magicaltrout: confirmed | 13:42 |
| magicaltrout | lovely | 13:42 |
| ahasenack | I pinged staff | 13:42 |
| magicaltrout | thanks | 13:42 |
| zyga | https://status.snapcraft.io is useful | 13:43 |
| magicaltrout | ah | 13:43 |
| magicaltrout | cool | 13:43 |
| magicaltrout | 99.57% | 13:43 |
| magicaltrout | how rubbish! ;) | 13:43 |
| ackk | zyga, fwiw we don't pull it in explicitly, it's pulled as a dep | 13:45 |
| mvo | jdstrand: hey, quick question - do we want settimeofday in time_control.go (in the time-control inteface). I think we do and we did in 2.31 but for some reason its not there in master afaict. I noticed when doing the merge of 2.31 back into master (c.f. https://github.com/snapcore/snapd/pull/4712/files#diff-398a6a1ea514e53bd322812b60f02924R111 ) | 13:50 |
| mup | PR #4712: release: version 2.31.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4712> | 13:50 |
| ackk | zyga, i guess we can strip it manually from the snap | 13:51 |
| zyga | ackk yes, please try to remove it, I think you can do that with one of the organize features of snapcraft | 13:51 |
| zyga | kalikiana may be able to help, I don't remember the syntax for them | 13:51 |
| ackk | zyga, yeah, thanks for the info | 13:51 |
| brunosfer | error: unable to contact snap store | 13:52 |
| ackk | zyga, does the base snap provide xdg-open? | 13:53 |
| zyga | yes | 13:53 |
| ackk | I wonder if base-18 has it | 13:53 |
| zyga | ackk it is a part of snapd now | 13:53 |
| zyga | but ... hmm | 13:54 |
| zyga | mvo ^ perhaps omission | 13:54 |
| ackk | zyga, it's not there in base-18 fwiw | 13:54 |
| mvo | yeah, base-18 does not have it just yet | 13:54 |
| jdstrand | mvo: it was in https://github.com/snapcore/snapd/pull/4687 | 13:54 |
| mup | PR #4687: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4687> | 13:54 |
| jdstrand | mvo: which says it was merged... | 13:54 |
| * jdstrand scratches head | 13:54 | |
| mvo | jdstrand: yeah, I'm puzzled | 13:54 |
| jdstrand | mvo: but looking at https://github.com/snapcore/snapd/pull/4687/files, it isn't in there | 13:55 |
| mup | PR #4687: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4687> | 13:55 |
| jdstrand | but there it is: https://github.com/snapcore/snapd/pull/4687/commits/c1093d46437a33d60d7378b1c6676818655bc359 | 13:56 |
| b4nt | Hello, is the snapcraft downtime planned? | 13:58 |
| zyga | b4nt no, https://status.snapcraft.io | 13:58 |
| pedronis | it should be back | 13:58 |
| * jdstrand verifies the others | 13:58 | |
| b4nt | ok, weird... | 13:59 |
| mvo | jdstrand: yeah, its there and the log says it is mereged but https://github.com/snapcore/snapd/blob/master/interfaces/builtin/time_control.go#L109 in master does not have it and I'm puzzled why | 13:59 |
| jdstrand | mvo: this reverted it: https://github.com/snapcore/snapd/pull/4687/commits/cc5dcd8cd8879f81d9077b8300b36dd1db2224eb | 13:59 |
| mup | PR #4687: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4687> | 13:59 |
| zyga | b4nt it's down but not on purpose | 13:59 |
| mvo | jdstrand: ohhhh | 13:59 |
| mvo | jdstrand: accidently? | 13:59 |
| mvo | jdstrand: if it got reverted by mistake I will just pull it back in via the 2.31 merge | 14:00 |
| jdstrand | mvo: I know there was a conflict in that file. I may have done a rebase somewhere and reorganized and messed it up | 14:00 |
| jdstrand | mvo: definitely a mistake | 14:00 |
| mvo | jdstrand: no worries! | 14:00 |
| mvo | jdstrand: thank you for helping solve this mystery :) | 14:00 |
| jdstrand | heh | 14:00 |
| mvo | jdstrand: its back now! | 14:01 |
| jdstrand | mvo: sorry :) and thank you for pulling that in and noticing it in the first place! :) | 14:01 |
| diddledan | is api.snapcraft.io down? | 14:01 |
| diddledan | I'm getting 403 | 14:01 |
| mup | PR snapd#4712 closed: release: version 2.31.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4712> | 14:01 |
| mvo | jdstrand: np! | 14:01 |
| diddledan | aah, I'm behind - I see yes it is | 14:02 |
| mup | PR snapd#4718 closed: tests: disable interfaces-location-control on s390x <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4718> | 14:02 |
| diddledan | bonus points for zyga sharing the status.snapcraft.io page which I didn't know existed | 14:03 |
| kalikiana | ackk: zyga: what do you need to know for organize? to exclude a binary? | 14:07 |
| zyga | kalikiana yes, get rid of xdg-open | 14:07 |
| zyga | and it should _probably_ be excluded by default | 14:07 |
| kalikiana | what's pulling it in? desktop helpers? | 14:08 |
| zyga | kalikiana unclear, ackk can share his snapcraft yaml | 14:08 |
| kalikiana | I'd recommend `snapcraft help plugins` to learn about he syntax in general. There's a section about "organize" as well as the other generic keywords | 14:09 |
| kalikiana | Okay, looking at the YAML would be best to see what's needed here | 14:09 |
| mborzecki | off to pick up the kids | 14:10 |
| ackk | kalikiana, amtterm is pulling it in as a dependency | 14:11 |
| ackk | kalikiana, zyga: https://git.launchpad.net/maas/tree/snap/snapcraft.yaml | 14:12 |
| kalikiana | ackk: Ah. By the looks of it, you can probably just add -usr/bin/xdg-open to the existing "remove" fileset. Note the leading - in addition to the - for each item in the list. That's how you exclude. | 14:15 |
| ackk | kalikiana, ah yeah, thanks | 14:15 |
| ackk | kalikiana, I'll try that | 14:16 |
| === leftyfb_ is now known as leftyfb | ||
| mup | PR snapd#4717 closed: cmd/snap-update-ns,testutil: move syscall testing helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4717> | 14:21 |
| ogra_ | mvo, looks like the builds succeeded, so it was transient indeed | 14:29 |
| jdstrand | sergiusens: hi! not sure you saw, but https://github.com/snapcore/snapcraft/pull/1945#pullrequestreview-98350157 | 14:30 |
| mup | PR snapcraft#1945: elf: clear execstack by default <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1945> | 14:30 |
| mvo | ogra_: puh, thanks | 14:31 |
| jdstrand | zyga: hi! would you mind briefly looking at https://github.com/snapcore/snapd/pull/4714, and responding to my questions? that way I can finish the PR for a proper review | 14:31 |
| mup | PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714> | 14:31 |
| zyga | gladly, looking | 14:31 |
| jdstrand | zyga: thanks! | 14:31 |
| zyga | I'm doing some cleanups in that area actually | 14:32 |
| zyga | this should address point 10 | 14:32 |
| zyga | 1) | 14:32 |
| jdstrand | zyga: fs_detect.go could be detect.go? | 14:32 |
| jdstrand | zyga: ah, ok | 14:33 |
| zyga | jdstrand I'll probably merge overlay, nfs into mount.go later | 14:34 |
| sergiusens | thanks jdstrand | 14:36 |
| zyga | jdstrand reviewed | 14:40 |
| jdstrand | zyga: fyi, willcooke asked about the per-user mounts feature yesterday (I heard you were out. hope you're feeling better). I tried to summarize it as best I could that you are actively looking at it with priority | 14:40 |
| mup | PR snapd#4721 opened: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721> | 14:41 |
| jdstrand | zyga: thanks! | 14:42 |
| zyga | jdstrand does this look sane, as a list of mount constraints for user mounts: https://pastebin.ubuntu.com/p/V6zXf9wWkd/ | 14:53 |
| mvo | Chipaca: the snap pack validation saved my bacon a couple of times today when creating test snaps, nice job | 15:06 |
| jdstrand | zyga: looking | 15:07 |
| zyga | jdstrand thanks | 15:07 |
| jdstrand | zyga: I'd love for point '3' to be enforceable because then this could be bulletproof. unfortunately '3' can't be a constraint for portals to work (see https://github.com/snapcore/snapd/pull/3963#discussion_r164623540) | 15:13 |
| mup | PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963> | 15:13 |
| zyga | aha, in that case 3 has to fly off the list | 15:14 |
| jdstrand | zyga: yeah. otherwise +1 | 15:14 |
| zyga | jdstrand btw, I was thinking about traversing the filesystem (descending from /) and then doing mount ., this would halve the attack surface | 15:14 |
| zyga | for bind mounts that is | 15:14 |
| zyga | for normal mounts it would make it race-free | 15:15 |
| zyga | (whee) | 15:15 |
| zyga | (well, assuming /dev doesn't race0 | 15:15 |
| jdstrand | zyga: that's an interesting idea | 15:17 |
| zyga | we could also do one more crazy thing | 15:17 |
| zyga | for bind mounts | 15:17 |
| zyga | but that's not for today | 15:17 |
| ackk | mvo, is there a place to file bugs about things that are missing in base-18, or is it too early? | 15:18 |
| zyga | jdstrand do you think it is worth it? | 15:19 |
| jdstrand | zyga: if you do ConservativeMount, then I think that should be sufficient for portals for now since the setuid process (which dropped, but retains enough privilege to mount) will fail if mismounted | 15:19 |
| jdstrand | we have to get that detection right though | 15:19 |
| jdstrand | (mismount detection) | 15:19 |
| zyga | right | 15:19 |
| zyga | I think that's quite easy but maybe I miss something | 15:19 |
| jdstrand | we can consider hardening after | 15:19 |
| zyga | because of rule 4) we can simply look for the mount point in mountinfo _after_ | 15:20 |
| zyga | so before we mount we ensure that mountinfo doens't contain the mount point | 15:20 |
| zyga | and after mount we ensure that it does | 15:20 |
| zyga | this means that we managed to mount exactly where we intended | 15:20 |
| jdstrand | zyga: james h had trouble with it, but he didn't write all the mount code you did. it seemed like something that would be easy for you :) | 15:20 |
| zyga | I wrote some test code for that | 15:21 |
| mup | PR snapd#4599 closed: many: send new Snap-CDN header with none or with cloud instance placement info as needed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4599> | 15:22 |
| jdstrand | zyga: hmm. actually I was thinking of '4' as 'a snapd managed mountpoint', not an 'absolute mountpoint' | 15:22 |
| jdstrand | zyga: because XDG_RUNTIME_DIR (/run/user/uid) *is* a mountpoint | 15:23 |
| zyga | aha | 15:23 |
| zyga | so that's good feedback, I didn't realise that | 15:23 |
| jdstrand | zyga: *perhaps* for just portals it is ok because XDG_RUNTIME_DIR will *not* be a mountpoint | 15:23 |
| zyga | I will have to adjust the verification logic accordingly | 15:23 |
| zyga | mmm, one sec | 15:24 |
| jdstrand | zyga: but we will want to mount on XDG_RUNTIME_DIR to cleanup the wayland compat symlinks in XDG_RUNTIME_DIR/snap.foo/wayland -> ../wayland | 15:24 |
| jdstrand | (ie, get rid of wrappers) | 15:25 |
| zyga | jdstrand so for portals we'll have the equivalent of: mount --bind $XDG_RUNTIME_DIR/doc/by-app/snap.pkg.$SNAP_NAME $XDG_RUNTIME_DIR/doc | 15:25 |
| zyga | jdstrand and what's the value of $XDG_RUNTIME_DIR we want? | 15:25 |
| zyga | jdstrand /run/user/1234 or something else/ | 15:25 |
| jdstrand | zyga: re equivalent> that is my understanding | 15:26 |
| jdstrand | zyga: with XDG_RUNTIME_DIR, it will be /run/user/<uid>, which is a mountpoint, but /run/user/<uid>/doc will not be | 15:26 |
| jdstrand | zyga: so '4' | 15:26 |
| mvo | pedronis: thanks again for the review. I added a unit and spread test for circular content providers and I think this is good for a review by e.g. pstolowski | 15:26 |
| jdstrand | meh | 15:26 |
| jdstrand | zyga: so '4' should be ok for portals | 15:26 |
| pstolowski | mvo, sure | 15:27 |
| jdstrand | zyga: but it won't be for the XDG_RUNTIME_DIR cleanup (if you recall, XDG_RUNTIME_DIR as /run/user/uid/snap.foo has been problematic for some snaps) | 15:27 |
| jdstrand | zyga: and to be even more clear, XDG_RUNTIME_DIR in this context is what the host sees as XDG_RUNTIME_DIR, not what the snap sees. portals won't bind mount into /run/user/uid/snap.foo/doc | 15:28 |
| jdstrand | aiui | 15:28 |
| jdstrand | we might need jamesh for that bit if we want to keep '4' as a constraint | 15:29 |
| jdstrand | I think I can answer definitively though. while we could distro patch portals to do what we want, we can't distro patch all the distros, so it needs to operate the way it does, which is /run/user/uid/doc | 15:30 |
| jdstrand | jamesh: can you comment ^ | 15:30 |
| zyga | jdstrand thanks for explaining this, I'm still a bit slow on the logic (I'm still a little sick) | 15:32 |
| jdstrand | zyga: regardless. we do know that we want to eventually have a per snap mount of: mount --bind /run/user/uid/snap.foo -> /run/user/uid, with bind-file mounts for the wayland and pulse sockets | 15:32 |
| zyga | the per snap mount is okay as that can be done with non-conservative mount | 15:32 |
| jdstrand | zyga: I think the question is, do we plan for this now or do we do the 'whatever makes portals work today' | 15:33 |
| zyga | I think we make portals work while considering what will be needed eventually | 15:33 |
| jdstrand | where 'this' is the bind mount for /run/user/uid | 15:33 |
| mvo | pstolowski: thank you! | 15:34 |
| jdstrand | zyga: if that is the constraint, then '4' can remain, but we need to comment that we'll need to lift this restriction at some point | 15:34 |
| zyga | ok | 15:37 |
| zyga | I'll get to work | 15:37 |
| mup | PR snapd#4722 opened: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references <Created by pedronis> <https://github.com/snapcore/snapd/pull/4722> | 15:41 |
| === lool- is now known as lool | ||
| pedronis | mvo: Chipaca: #4722 is the cleanup I was talking about, prereq has not landed though, anyway probably easist to look at each commit by itself | 15:58 |
| mup | PR #4722: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references <Created by pedronis> <https://github.com/snapcore/snapd/pull/4722> | 15:58 |
| pstolowski | mvo, reviewed, great stuff! some nitpicks/suggestions + one question | 16:46 |
| mup | PR snapd#4723 opened: Translate polkit strings <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4723> | 16:47 |
| pstolowski | #4716 needs 2nd review (and is trivial) | 16:53 |
| mup | PR #4716: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <https://github.com/snapcore/snapd/pull/4716> | 16:53 |
| pedronis | pstolowski: I myself forgot about Attrer, thanks for the review | 16:55 |
| pedronis | I mean for mvo's PR | 16:55 |
| pstolowski | pedronis, np | 16:58 |
| mvo | pstolowski: thanks, I have a look and will fixup things | 17:01 |
| pstolowski | yw | 17:03 |
| * kalikiana wrapping up for today | 17:17 | |
| mup | PR snapd#4724 opened: osutil: aggregate mockable symbols <Created by zyga> <https://github.com/snapcore/snapd/pull/4724> | 17:38 |
| Chipaca | huh | 18:14 |
| Chipaca | mvo: you around? | 18:15 |
| mvo | Chipaca: ish | 18:16 |
| mvo | Chipaca: good envening | 18:16 |
| Chipaca | mvo: good evening | 18:16 |
| Chipaca | mvo: I've got a grep for you | 18:17 |
| Chipaca | mvo: grep -r SNAP_REFRESH_FROM | 18:18 |
| Chipaca | mvo: I have a relatively strong suspicion that the two lines should match more than they do | 18:18 |
| mvo | Chipaca: uh, oh, I see the problem | 18:18 |
| Chipaca | :-) | 18:18 |
| mvo | Chipaca: thanks for spotting this, lets fix it and get the fix in 2.31 (just in case) | 18:19 |
| mvo | Chipaca: will you or shall I? | 18:19 |
| Chipaca | funny what you spot when a user asks questions | 18:19 |
| * Chipaca hugs Odd_Bloke | 18:19 | |
| * mvo hugs Odd_Bloke as well | 18:19 | |
| Chipaca | mvo: if you can do it, i'll review it | 18:20 |
| mvo | Chipaca: thanks! lets catchup on c-n-f tomorrow morning, sorry that I did not managed today, but it looks like the default content provider is sorted, so that is good | 18:20 |
| mvo | Chipaca: sure think | 18:20 |
| Chipaca | mvo: my git is very messy right now | 18:20 |
| Chipaca | and the sort of messy that doesn't stash well | 18:20 |
| Chipaca | (added and removed files) | 18:20 |
| === pbek_ is now known as pbek | ||
| mvo | Chipaca: eh, actually - I think there is a reason! sorry, we used to have the _FROM_TIMER=1 and then changed it to the emergency timer. so the check in the code is really there to prevent us running in case of an old .service file/timer file being around (hope that makes sense) | 18:24 |
| Chipaca | mvo: but there's nothing that triggers from the emergency timer | 18:24 |
| Chipaca | i mean, setting that env var does nothing | 18:25 |
| Chipaca | or am i missing something? | 18:25 |
| Chipaca | (as it is the systemd timer is firing and people are seeing "manual" refreshes triggered by it) | 18:25 |
| Chipaca | mvo: https://forum.snapcraft.io/t/refresh-vs-auto-refresh-in-snap-changes-output/4145 | 18:26 |
| pedronis | Chipaca: afaik "refreshed" in snap info is the time of revision mount directory | 18:27 |
| Chipaca | pedronis: it's the mtime of the mount dir | 18:27 |
| Chipaca | pedronis: i.e. the mtime of the squash root | 18:27 |
| Chipaca | code is in daemon/snap.go:57, func snapDate | 18:28 |
| Chipaca | st, err := os.Stat(info.MountDir()) | 18:28 |
| Chipaca | and then ModTime of that | 18:28 |
| * Chipaca greps the logs | 18:31 | |
| Chipaca | mvo: so... it seems we had FROM_TIMER in the systemd files in debian, and FROM_EMERGENCY_TIMER in the ones in data, and at some point we dropped the ones in debian for the ones in data, but there never was code to handle the FROM_EMERGENCY_TIMER | 18:36 |
| Chipaca | the FROM_TIMER was there so that a new snapd (with internal timer) would ignore the systemd timer | 18:37 |
| Chipaca | whereas the FROM_EMERGENCY_TIMER I think the idea was that snapd would check how long it'd been since it refreshed? | 18:37 |
| Chipaca | but we never did that code afaict | 18:37 |
| Chipaca | not sure ¯\_(ツ)_/¯ | 18:37 |
| Chipaca | ah, the note on on the emergency one is that it'd just run a manual refresh once a week | 18:39 |
| Chipaca | ehhhhhh | 18:39 |
| pedronis | Chipaca: I suppose /snap/*/current mtime would be a better estimate of when it was refreshed, right? | 18:40 |
| Chipaca | pedronis: I love the current value | 18:41 |
| Chipaca | it tells you when the snap was created | 18:41 |
| Chipaca | (assuming sane system times where it was created, but hey) | 18:42 |
| Chipaca | maybe we should validate it though :-) | 18:42 |
| * Chipaca seems to be thinking a lot about validation | 18:42 | |
| Chipaca | jdstrand: do we check the times in the squash at all? | 18:42 |
| pedronis | Chipaca: yes, but I have been asked for other reasons, about the time the snap was refreshed | 18:42 |
| pedronis | on the system | 18:42 |
| Chipaca | right, for that, get the mtime of /var/lib/snapd/snaps/<yoursnap> | 18:43 |
| pedronis | Chipaca: that emergency timer behavior seeems bad | 18:43 |
| Chipaca | pedronis: bd946e43a477b054b6ea944497998faa4a709442 | 18:43 |
| Chipaca | (there's a followup that s/RY/CY/) | 18:43 |
| Chipaca | pedronis: that's the explanation for the current behaviour | 18:43 |
| pedronis | ? | 18:44 |
| Chipaca | the ignoring of FROM_TIMER is because if you have FROM_TIMER you're on an older systemd unit which runs too often | 18:44 |
| Chipaca | so that's ignored completely | 18:44 |
| pedronis | I thought EMERGENCY was for repairs | 18:45 |
| pedronis | not refresh | 18:45 |
| Chipaca | this predates repairs by a lot, i think | 18:45 |
| Chipaca | pedronis: ah, by bd946e43a477b054b6ea944497998faa4a709442 i meant 'git show bd946e43a477b054b6ea944497998faa4a709442' | 18:46 |
| Chipaca | pedronis: this is literally so if <random event> happens and the refresh timer never fires, _something_ kicks the system to refresh so we can fix it | 18:47 |
| pedronis | Chipaca: that behavior is wrong now that we have monthly schedules | 18:47 |
| jdstrand | Chipaca: not for reasonableness. we do for complete grossness (ie, if unsquasfs -lls matches "date_pat = re.compile(r'^\d\d\d\d-\d\d-\d\d$')" and "time_pat = re.compile(r'^\d\d:\d\d$')" | 18:47 |
| jdstrand | Chipaca: is there something you are thinking about? this is kinda tricky for arbitrary files in the system | 18:48 |
| jdstrand | s/system/snap/ | 18:48 |
| Chipaca | jdstrand: not sure if you saw, but we were talking about how we report the mtime of the root of the squash as the time the snap was … updated? (currently we say refreshed, which is wrong) | 18:49 |
| jdstrand | I didn't see that | 18:49 |
| pedronis | Chipaca: we shouldn't trigger a random weekly one, if the schedule is monthly | 18:50 |
| jdstrand | Chipaca: it might be better to look at the superblock | 18:50 |
| Chipaca | jdstrand: how so? | 18:50 |
| jdstrand | this is what the review tools do: extract the fstime from the superblock then feed that back in for the resquash | 18:50 |
| Chipaca | (and, how? :-) but i can google that) | 18:50 |
| Chipaca | pedronis: we should make a note about it at least | 18:51 |
| Chipaca | pedronis: 'system administrators that wish to have refreshes >1week should also adjust yadda yadda' | 18:51 |
| pedronis | Chipaca: or we convey the env var along the api request | 18:52 |
| pedronis | and check something in snapd itself | 18:52 |
| jdstrand | Chipaca: the why is cause it seems plausible that someone might have a dir tree up, never remove it and tickle files inside, so squashfs-root doesn't change (does mksquashfs update it? I don't know) | 18:52 |
| Chipaca | pedronis: I'd favour that tbh | 18:52 |
| pedronis | sounds like we need a note somewhere | 18:53 |
| pedronis | Chipaca: can you add something here: https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239 perhaps ? | 18:54 |
| jdstrand | Chipaca: right, sBlk.s.mkfs_time. here is a patch I did for squashfs-tools for extracting that: http://launchpadlibrarian.net/242328684/squashfs-tools_1%3A4.2+20130409-2_1%3A4.2+20130409-2ubuntu0.14.04.1.diff.gz | 18:55 |
| jdstrand | perhaps mksquashfs updates squashfs-root times whenever it is created | 18:56 |
| jdstrand | that's easy enough to check | 18:56 |
| Chipaca | jdstrand: i can confirm the root timestamp doesn't change unless something in it contains directly changes | 18:56 |
| jdstrand | ok | 18:57 |
| Chipaca | IOW mksquashfs preserves the filesystem timestamp | 18:57 |
| Chipaca | wait, let me double-check the flags we use | 18:57 |
| jdstrand | Chipaca: so, mksquashfs is is going to update the mkfs_time on each run | 18:57 |
| jdstrand | Chipaca: so you don't have to worry about squashfs-root | 18:57 |
| Chipaca | a'ight | 18:58 |
| Chipaca | I'll fix this at some point | 18:58 |
| jdstrand | I mean, someone could game that, but what does it gain them? buggy freshness? | 18:58 |
| jdstrand | so I think mkfs_time is going to be most robust | 18:58 |
| jdstrand | (even if it can be gamed) | 18:59 |
| Chipaca | pedronis: https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/18 | 19:02 |
| Chipaca | jdstrand: okie doke | 19:03 |
| Chipaca | not for the first time I find myself thinking of writing a squashfs parser in go | 19:03 |
| jdstrand | heh | 19:03 |
| Chipaca | jdstrand: that patch isn't upstream, is it? | 19:03 |
| jdstrand | it shouldn't be *terrible* to extract the super block... | 19:04 |
| pedronis | Chipaca: thank you | 19:04 |
| jdstrand | Chipaca: in squashfs-tools? no | 19:04 |
| Chipaca | ah well | 19:04 |
| Chipaca | i should have a way to ask the kernel for this | 19:05 |
| Chipaca | huh, "file" knows how to find it | 19:06 |
| jdstrand | Chipaca: $ unsquashfs -s /path/to/snap | 19:07 |
| jdstrand | Creation or last append time Fri Feb 2 19:23:56 2018 | 19:07 |
| Chipaca | aww, that's a lot easier than figuring out what '>>>40 bequad x' means | 19:08 |
| * Chipaca hugs jdstrand | 19:08 | |
| * jdstrand hugs Chipaca :) | 19:08 | |
| pedronis | Chipaca: "file" knows a lot of things | 19:09 |
| jdstrand | it does | 19:09 |
| jdstrand | it also occasionally has bugs | 19:09 |
| Chipaca | every time I'm tempted to look at its sourcecode I'm amazed it works so consistently well | 19:10 |
| jdstrand | I can't remember otoh, but I feel like it had to do with the review-tools and file behaving differently on 14.04 and 16.04+ | 19:10 |
| jdstrand | I could be making that up. I know I was annoyed with file once though | 19:10 |
| jdstrand | oh yeah, it's great | 19:11 |
| Chipaca | mvo: you'll be pleased to hear that "unsquashfs -s" does report errors with an exit code different from zero | 19:11 |
| jdstrand | I was just thinking through if you used file, you'd probably want to use the one from the core snap rather than the system | 19:11 |
| Chipaca | I don't think there's a file in the core snap | 19:11 |
| jdstrand | all the more reason to use unsquashfs :) | 19:12 |
| Chipaca | ooh, yes there is a file in the core snap | 19:12 |
| Chipaca | oh wait this one is classic | 19:12 |
| * Chipaca backpedals | 19:12 | |
| pedronis | I'm not finding it | 19:12 |
| jdstrand | and yes, isn't unsquashfs annoying in that it returns 0 when it seems pretty clear it shouldn't? | 19:12 |
| Chipaca | there's no file in the core snap :-) | 19:12 |
| jdstrand | glad -s is reasonable | 19:13 |
| Chipaca | jdstrand: we have a bug about that, and a patch upstream, thanks to mvo | 19:13 |
| pedronis | no "file" in core | 19:13 |
| jdstrand | Chipaca: I actually wonder how the world will break if that patch is applied | 19:13 |
| pedronis | there is "fold" though | 19:14 |
| jdstrand | Tyler came across it (might be what prompted mvo to submit the patch) and we were uneasy about it | 19:14 |
| Chipaca | jdstrand: the workaround we're using is grepping the output of unsquashfs for the error strings (fortunately they're consistent) (unfortunately, nobody can ever have a file named like one of their error messages) | 19:14 |
| pedronis | and "factor" | 19:14 |
| * pedronis stops | 19:14 | |
| jdstrand | Chipaca: hehe, yes | 19:14 |
| jdstrand | pedronis: I don't know what we would do if 'factor' was removed from core! oh noes! :) | 19:15 |
| pedronis | I mostly wonder what depends on it to be there | 19:16 |
| jdstrand | it comes from coreutils | 19:16 |
| pedronis | I suspect so | 19:16 |
| pedronis | still wonder why it's a "core"util :) | 19:16 |
| jdstrand | heh, well, the googles may have your answer ;) | 19:16 |
| Chipaca | jdstrand: https://github.com/plougher/squashfs-tools/pull/46 fwiw | 19:22 |
| mup | PR plougher/squashfs-tools#46: unsquashfs: return exit 1 if writing fails for some reason <Created by mvo5> <https://github.com/plougher/squashfs-tools/pull/46> | 19:22 |
| jdstrand | roadmr: can you pull r1004 of the review tools? just some new/updated checks | 19:22 |
| jdstrand | Chipaca: thanks. fyi, ^ that has the pkgversion update | 19:22 |
| Chipaca | jdstrand: cheers | 19:22 |
| Chipaca | jdstrand: next up, I'll be rejecting snap descriptions that aren't valid markdown | 19:23 |
| * Chipaca runs | 19:23 | |
| jdstrand | heh | 19:24 |
| Chipaca | (i don't think there's "invalid markdown") | 19:24 |
| pedronis | "doesn't look right" markdown | 19:25 |
| pedronis | so we can add ML to our stack :) | 19:26 |
| Chipaca | snap rejection reason: poor phrasing in snap description | 19:27 |
| Chipaca | of _course_ unsquashfs doesn't know about locales | 19:27 |
| roadmr | jdstrand: sure thing, I'll get an MP for that rolling | 19:33 |
| jdstrand | roadmr: thanks! | 19:39 |
| tyhicks | huh, I didn't realize that there was a squashfs-tools github project | 19:41 |
| Chipaca | so, what's a better label for 'refreshed' in 'snap info'? | 20:14 |
| * Chipaca should probably ask in the forum | 20:15 | |
| pedronis | it's reall "built" no? | 20:17 |
| pedronis | but that will be confusing in context | 20:18 |
| pedronis | Chipaca: or we could keep refreshed but give the /var/lib/snapd/snaps/snap.snap time | 20:23 |
| pedronis | Chipaca: notice that internally is called InstalledDate so that is worse | 20:24 |
| Chipaca | pedronis: https://forum.snapcraft.io/t/better-field-name-for-refreshed-in-snap-info-output/4150 | 20:24 |
| Chipaca | I think at some point it started looking at the wrong thing, and the tests didn't catch it | 20:25 |
| Chipaca | (as i say in that post) | 20:25 |
| Chipaca | because, ye, between it being InstallDate in the api, and refreshed in info, ye | 20:25 |
| pedronis | I think the api value is wrong | 20:25 |
| Chipaca | anyhow. i should stop, go grab me some curry, and then … dunno, more hacking probably | 20:26 |
| pedronis | given the api field name | 20:26 |
| Chipaca | pedronis: exactly | 20:26 |
| Chipaca | pedronis: but i also like that value | 20:26 |
| pedronis | we can have a different field with the value you like :) | 20:26 |
| Chipaca | exactly! | 20:26 |
| Chipaca | that's what the forum post is about, i think | 20:26 |
| Chipaca | title might be wrong tho | 20:26 |
| * Chipaca might get used to calling it organolepcy | 20:28 | |
| * Chipaca -> really curry | 20:29 | |
| jdstrand | tyhicks, mvo: can you update me on the status of the seccomp EPERM status? | 20:33 |
| jdstrand | tyhicks, mvo: still see new setpriority and chown questions in the forum | 20:34 |
| tyhicks | jdstrand: AFAIK, this cross-distro issue is still the blocker: https://github.com/snapcore/snapd/pull/3998/#issuecomment-358028579 | 20:35 |
| mup | PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998> | 20:35 |
| tyhicks | jdstrand, mvo: I think we could split that PR up and land the SECCOMP_RET_KILL -> SECCOMP_RET_ERRNO(EPERM) strict mode change separately from the SECCOMP_RET_LOG dev mode change if that helps | 20:38 |
| mup | PR snapcraft#1949 opened: repo: silence deb caching when fetching packages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1949> | 20:38 |
| zyga_ | tyhicks I think this would be welcome by developers | 20:38 |
| === zyga_ is now known as zyga | ||
| jdstrand | well | 20:40 |
| jdstrand | not if they have a denial, cause it would eperm with no logging | 20:40 |
| zyga | I think those that learned would like that denial to go away now :) | 20:41 |
| jdstrand | I mean, if its discussed and that is deemed less worse than the current situation, it is an option | 20:41 |
| zyga | err, the kill to go away | 20:41 |
| jdstrand | I mean, it is a problem, that is why the PR is there | 20:42 |
| tyhicks | jdstrand: I think you're getting the two things slightly mixed up | 20:43 |
| jdstrand | by requiring to strace an unlogged eperm is pretty bad imho | 20:43 |
| tyhicks | SECCOMP_RET_LOG isn't needed for the SECCOMP_RET_KILL -> SECCOMP_RET_ERRNO(EPERM) strict mode change | 20:43 |
| jdstrand | tyhicks: I know it isn't required from a technical perspective | 20:43 |
| jdstrand | tyhicks: but if we only do eperm, we lose logging, no? | 20:44 |
| jdstrand | I mean, that is why the pr is the way it is :) | 20:44 |
| tyhicks | if we switch to EPERM, the kernel needs to support the SECCOMP_FILTER_FLAG_LOG filter attribute or EPERM will not be logged | 20:44 |
| mup | PR snapd#4725 opened: tests: avoid removing preinstalled snaps on core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4725> | 20:44 |
| jdstrand | I'm saying *if* we do that, it is a differently bad experience | 20:45 |
| jdstrand | tyhicks: right... and you need the golang changes for SECCOMP_FILTER_FLAG_LOG | 20:45 |
| zyga | and there is no upstream release still AFAIR | 20:45 |
| jdstrand | zyga: there isn't, I just checked. it hasn't moved since Jan 16 | 20:46 |
| tyhicks | jdstrand: no, we don't need golang changes for SECCOMP_FILTER_FLAG_LOG because snap-confine sets that flag in the seccomp() syscall when it loads the filter | 20:46 |
| jdstrand | tyhicks: or am I not remembering right? | 20:46 |
| zyga | tyhicks where is SECCOMP_FILTER_FLAG_LOAD passed to? prctl? | 20:47 |
| tyhicks | zyga: seccomp(2), when that syscall is available | 20:47 |
| tyhicks | it falls back to prctl(), without SECCOMP_FILTER_FLAG_LOAD, when seccomp() isn't available | 20:47 |
| zyga | I see | 20:47 |
| tyhicks | prctl() doesn't let us specify filter flags | 20:47 |
| jdstrand | tyhicks: ok, so SECCOMP_FILTER_FLAG_LOG is only used by golang to query if it is available? | 20:47 |
| jdstrand | in the kernel? | 20:48 |
| tyhicks | jdstrand: right now, we're not querying the kernel to see if SECCOMP_FILTER_FLAG_LOG is supported by the kernel when snapd is constructing the filters | 20:48 |
| tyhicks | jdstrand: I thought we determined that wasn't needed | 20:49 |
| jdstrand | tyhicks: ok, I've lost too much context apparently. what is the golang change needed for? | 20:49 |
| tyhicks | jdstrand: snapd could call a small piece of C code that determines if SECCOMP_FILTER_FLAG_LOG is supported by the kernel and either use SECCOMP_RET_KILL or SECCOMP_RET_ERRNO(EPERM) | 20:49 |
| mup | PR snapcraft#1950 opened: elf: better debug messages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1950> | 20:50 |
| tyhicks | jdstrand: the golang change is needed for snapd to be able to construct a filter with SECCOMP_RET_LOG for dev mode snaps | 20:50 |
| jdstrand | right | 20:50 |
| jdstrand | so, today, we could drop that and devmode snaps operate the same | 20:51 |
| tyhicks | yes | 20:51 |
| jdstrand | I would be in favor of splitting it then | 20:51 |
| jdstrand | unless someone can do the runtime detection | 20:51 |
| jdstrand | tyhicks: can you suggest in the PR that it could be split? | 20:52 |
| jdstrand | tyhicks: thanks for bringing me up to speed (again) :) | 20:52 |
| tyhicks | jdstrand: yes | 20:52 |
| tyhicks | jdstrand: do you want to revisit our previous decision to not fall back to SECCOMP_RET_KILL even if SECCOMP_FILTER_FLAG_LOG is not supported? | 20:53 |
| jdstrand | it hard to keep all the context in your head when you visit something only monthly :p | 20:53 |
| tyhicks | jdstrand: it sounded like you weren't liking the idea of returning quietly returning ERRNO when the kernel doesn't support SECCOMP_FILTER_FLAG_LOG | 20:53 |
| tyhicks | s/returning quietly returning/quietly returning/ | 20:54 |
| jdstrand | tyhicks: no, we don't need to revisit imo. most distros that have strict mode should pick up the kernel change. we can even communicate that outward in the release notes of the snapd version that changes this that distros can pull the patches to get the logging back | 20:54 |
| jdstrand | tyhicks: I didn't for everyone | 20:55 |
| jdstrand | tyhicks: if we can get the top strict distros to patch, then I think its ok | 20:55 |
| tyhicks | ok | 20:55 |
| jdstrand | tyhicks: you did say the Ubuntu kernels have this support, right? | 20:56 |
| jdstrand | or am I misremembering that too? :) | 20:56 |
| tyhicks | jdstrand: yes, for months and months now | 20:56 |
| jdstrand | right | 20:56 |
| jdstrand | ok | 20:56 |
| jdstrand | yes, then I think not falling back to KILL is less of a big deal. we release note it. Ubuntu and (most of) its derivatives just work. solus would probably just snag the patch | 20:57 |
| jdstrand | if it proves to be an issue, we can patch snap-confine | 20:57 |
| tyhicks | I don't really understand why we define our own golang seccomp actions here: https://github.com/snapcore/snapd/pull/3998/files#diff-52db82d188e96fd9798675f0e17850faL382 | 21:00 |
| mup | PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998> | 21:00 |
| tyhicks | and then use libseccomp-golang's here: https://github.com/snapcore/snapd/pull/3998/files#diff-52db82d188e96fd9798675f0e17850faR634 | 21:00 |
| tyhicks | I followed the lead of the existing code that I was changing in that regard but we could probably be smarter about that and not hit the cross-distro problem | 21:01 |
| tyhicks | (and not have to split up the PR) | 21:01 |
| tyhicks | I'll leave the requested comments and then think about that some more | 21:02 |
| jdstrand | tyhicks: interesting. it might be for the testsuite. mvo would have more context | 21:02 |
| Aelius | hello! I just found snap | 21:46 |
| Aelius | if it requires sudo to install a package, then I assume the self updating feature won't work? (that is, unless I sign up for an ubuntu one account) | 21:46 |
| Aelius | also,is there a way to browse the online repository without searching? | 21:46 |
| nacc | Aelius: your first question doesn't make sense | 21:51 |
| nacc | Aelius: afaik, all snaps require sudo to install | 21:51 |
| nacc | Aelius: and all snaps autoupdate by default | 21:52 |
| Aelius | nacc: the docs tell me that sudo is not required if I log in with an ubuntu one account. you log in with sudo, and I guess it caches your credentials | 21:52 |
| nacc | Aelius: which docs? | 21:53 |
| Aelius | https://docs.snapcraft.io/core/usage | 21:53 |
| Aelius | > When you are not logged in, most snap commands will require you to run them as root. | 21:54 |
| diddledan | Aelius: snapd runs as root, so refreshing installed snaps is already privileged. snap login lets you assign your user account which allows you to snap install without sudo | 21:54 |
| pedronis | for public snaps there's no need for store credentials to update them, auto update works also for the one installed with sudo | 21:54 |
| Aelius | ok, good | 21:55 |
| Chipaca | Aelius: also, you shouldn't need sudo anyway | 21:56 |
| Chipaca | you'll just get a polkit dialog | 21:56 |
| diddledan | that too | 21:57 |
| Aelius | I am on archlinux- this dialog doesn't seem to be implemented here | 21:57 |
| Chipaca | Aelius: it being arch, i guess it's up to you to have polkit installed and configured and everything? | 21:58 |
| Aelius | probably. I believe I installed it for the sole purpose of being able to use `reboot` without sudo | 21:58 |
| Aelius | but havent touchhed it otherwise | 21:59 |
| Chipaca | Aelius: if so maybe you need to copy the policy files | 21:59 |
| Chipaca | anyway, i personally prefer sudo :-) | 21:59 |
| Aelius | yeah sudo is fine | 21:59 |
| Chipaca | Aelius: OTOH if you're creating snaps, you'll want to log in anyway | 22:00 |
| Chipaca | (as snapd can then let you get arbitrary revisions of your snaps, and/or private snaps) | 22:01 |
| cachio_ | zyga, which driver is ok for the nvidia | 22:08 |
| cachio_ | machine | 22:08 |
| cachio_ | the nouveau is ok? | 22:08 |
| zyga | no | 22:08 |
| cachio_ | or has to be the once from nvidea | 22:08 |
| zyga | cachio_ the test must use proprietary driver | 22:08 |
| zyga | ideally the non-legacy | 22:08 |
| zyga | (depending on hardware version) | 22:08 |
| cachio_ | zyga, ok, I'll try now with nvidia-390 | 22:09 |
| cachio_ | for xenial | 22:09 |
| cachio_ | and see | 22:09 |
| zyga | perfect | 22:09 |
| zyga | try all of spread suite | 22:09 |
| cachio_ | zyga, yes | 22:10 |
| Saviq | niemeyer: do you know if 17.10 images went away for good from linode ?? https://www.linode.com/distributions | 22:52 |
| Saviq | our CI is failing, missing ubuntu-17.10 images | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!