| === wgrant_ is now known as wgrant | ||
| mup | Bug #1760252 changed: starting slack crashes xwayland on 18.04 <bionic> <xorg-server (Ubuntu):New> <https://launchpad.net/bugs/1760252> | 01:33 |
|---|---|---|
| mup | PR snapd#5690 opened: Add an error code for Polkit auth cancels <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/5690> | 03:05 |
| mborzecki | morning | 05:09 |
| mborzecki | mvo: hey | 05:42 |
| mborzecki | mvo: easy win https://github.com/snapcore/snapd/pull/5687 | 05:42 |
| mup | PR #5687: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5687> | 05:42 |
| mborzecki | mvo: hey, you probably missed that, https://github.com/snapcore/snapd/pull/5687 is an easy win, same as https://github.com/snapcore/snapd/pull/5684 | 05:50 |
| mup | PR #5687: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5687> | 05:50 |
| mup | PR #5684: cmd/snap: create snap user directory when running parallel installed snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5684> | 05:50 |
| mvo | mborzecki: yeah, missed that, looking. thank you | 05:53 |
| zyga | good morning! | 05:53 |
| * zyga tries to shift to 6AM wake-ups | 05:54 | |
| zyga | not there yet | 05:54 |
| zyga | but slowly :) | 05:54 |
| mvo | zyga: good morning | 05:54 |
| zyga | I'll make coffee and join you guys shortly | 05:54 |
| mborzecki | zyga: hey | 05:54 |
| mborzecki | zyga: you're still 2h behind the schedule :P | 05:54 |
| mup | PR snapd#5687 closed: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME <Parallel installs> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5687> | 05:57 |
| mvo | mborzecki: 5684 waits for john, no? | 05:57 |
| mborzecki | mvo: yay, thanks | 05:57 |
| mborzecki | mvo: yes, i pinged him and pawel yday | 05:57 |
| mborzecki | feels good to be back at the proper screen | 05:58 |
| === mborzeck1 is now known as mborzecki | ||
| zyga | :-) | 06:24 |
| zyga | Yeah but I’m shifting | 06:25 |
| zyga | When I woke up today I felt like it’s autumn ready | 06:26 |
| zyga | Is it OK to say I already miss the summer? | 06:27 |
| zyga | My plan for today is to talk with Paweł about the system snap | 06:28 |
| zyga | And to finish off the two remaining PR I have open | 06:29 |
| zyga | And then work and user mounts | 06:29 |
| zyga | mvo: When do you plan to release the next point release? | 06:29 |
| mborzecki | zyga: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/parallel-install-snap-namespace-mapping i'd love to hear your thoughts | 06:30 |
| mborzecki | zyga: also need to look info why /snap/foo is mounted rw | 06:31 |
| zyga | I’ll check it out very soon but just as an observation snap foo cannot be a mount point, because there’s nothing out there is just a directory | 06:32 |
| mborzecki | zyga: rbind & ro are a no go (you added that comment?), guess it's not much of a problem for /snao/foo_bar -> /snap/foo | 06:52 |
| zyga | re | 06:53 |
| zyga | mborzecki: looking | 06:54 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:10 |
| mvo | zyga: I have no plans yet for a point release. what do we need in it? | 07:23 |
| zyga | some things are tagged with 2.35 | 07:23 |
| mvo | zyga: we can do in a week after the real release | 07:23 |
| zyga | and 2.35.0 is in the release page | 07:23 |
| mvo | zyga: aha, let me check | 07:23 |
| zyga | so I assumed you would do another one | 07:23 |
| zyga | is 2.35 out? | 07:23 |
| zyga | or am I just mistaken about the assumption | 07:23 |
| mvo | zyga: I thought I had moved them to .36 | 07:23 |
| mvo | zyga: its in beta now | 07:23 |
| zyga | ah, that must be it then | 07:23 |
| mvo | zyga: https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.35 | 07:24 |
| mvo | zyga: but we can do a point release i fneeded | 07:24 |
| zyga | ah, ok | 07:24 |
| zyga | :) | 07:24 |
| mborzecki | zyga: mount profiles for test-snapd-layout{,_foo} https://paste.ubuntu.com/p/JvmWd88tKp/ unfortunately the _foo one explodes on startup https://paste.ubuntu.com/p/8ZYtzf7sgG/ | 07:42 |
| zyga | https://www.irccloud.com/pastebin/d39eugoc/ | 07:43 |
| zyga | mborzecki: that's "expected", aka known issue | 07:44 |
| zyga | mborzecki: rm the symlink on your host to fix it | 07:44 |
| zyga | mborzecki: that's the "trespassing" bug that I was trying to fix for many months now | 07:44 |
| zyga | mborzecki: it manifests itself as dangling symlinks and empty files in /etc | 07:45 |
| mborzecki | zyga: ok, removing files made it go away | 07:46 |
| mup | PR snapcraft#2220 opened: schema: allow license field <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2220> | 08:04 |
| alexlarsson | zyga: hey, do you know if there is any work going on to backport the new xdg-desktop-portal releases (in particular, 1.0) to bionic? | 08:12 |
| alexlarsson | zyga: I'm considering whether to add it to the bionic flatpak ppa | 08:13 |
| mup | PR snapd#5691 opened: spdx: allow Other-Open-Source <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5691> | 08:24 |
| seb128 | jamesh, ^ you might know? | 08:24 |
| jamesh | alexlarsson: we want to backport xdg-desktop-portal to xenial. I think it might make that backport 1.0, and push it to bionic, assuming there aren't compat issues | 08:26 |
| alexlarsson | jamesh: Should be no compat issues | 08:26 |
| alexlarsson | I have x-d-p 1.0 for xenial in the flatpak ppa, but historically i didn't add it to bionic, because it had 0.11 already | 08:27 |
| zyga | whee, thank you alexlarsson and jamesh :) | 08:27 |
| jamesh | alexlarsson: I'll talk about it with Ken | 08:27 |
| mborzecki | zyga: parallel installs + layouts spread test running now | 08:34 |
| zyga | cool | 08:35 |
| alexlarsson | jamesh: cool | 08:35 |
| === chihchun_afk is now known as chihchun | ||
| zyga | mborzecki: any luck? | 08:44 |
| mborzecki | zyga: heh, stopped at the trespassing thing, fixed the test to cleanup /etc/demo* stuff and retrying now | 08:46 |
| zyga | kk | 08:47 |
| zyga | once it passes (if it does) look around, as I said it's more about just ensuring the outcome makes sense than looking at the boolean pass/fail value | 08:47 |
| mup | Bug #1533899 changed: Add support for proxies <canonical-is> <proxy> <webdm> <cloud-init:New> <Snap Layer:Fix Released by stub> <Snapcraft:Invalid> <Snappy:Fix Released> <snapweb:Invalid> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1533899> | 08:47 |
| mborzecki | zyga: yeah, modified it a bit to write different content to locations and added some steps to verify if the things look ok from the outside | 08:48 |
| mborzecki | zyga: once https://github.com/snapcore/snapd/pull/5670 i'll be able to open a PR with mapping changes along with a spread test | 08:48 |
| mup | PR #5670: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670> | 08:48 |
| mborzecki | hm actually most of the spread tests, there's one that depends on https://github.com/snapcore/snapd/pull/5614 | 08:49 |
| mup | PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614> | 08:49 |
| Chipaca | zyga: next time you're feeling smug about your mac, have you looked at the uname implementation for darwin vs the one for linux | 08:58 |
| zyga | mmm, nope/ | 08:58 |
| zyga | what's the difference? | 08:59 |
| Chipaca | zyga: https://github.com/golang/sys/blob/master/unix/syscall_darwin.go#L368 vs https://github.com/golang/sys/blob/master/unix/zsyscall_linux_amd64.go#L1378 | 08:59 |
| Chipaca | zyga: the darwin one is five syscalls and a loop | 08:59 |
| zyga | interesting, I knew apple did some unusual things with their sys call layers | 09:02 |
| zyga | notably for compatibility at the extreme | 09:02 |
| zyga | and also flexibility | 09:02 |
| zyga | some system calls don't have numbers | 09:03 |
| zyga | only names | 09:03 |
| zyga | and to call them you literally have to pass the string to the kernel | 09:03 |
| zyga | then again apple sys calls are executed differently due to (last time I looked at 32bit systems) 4/4 split | 09:03 |
| zyga | where the whole address space flips (except for a tiny page that has the flip code and arg buffers) | 09:03 |
| zyga | Chipaca: but yeah, cool stuff :) | 09:04 |
| zyga | and apparently it doesn't matter (marketshare :) | 09:04 |
| Chipaca | zyga: :-) | 09:04 |
| Chipaca | what does userd use SIGUSR1 for? | 09:11 |
| Chipaca | morphis: do you remember? | 09:11 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR core#93 opened: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93> | 09:15 |
| mborzecki | zyga: that's the test currently https://paste.ubuntu.com/p/KfNJC6tJV2/ | 09:23 |
| zyga | mborzecki: looking | 09:25 |
| zyga | mborzecki: what I would look for in this test is something that verifies that both instances don't step on each other's data | 09:26 |
| mborzecki | zyga: that's towards the end | 09:26 |
| zyga | mmm, I don't see that | 09:27 |
| mborzecki | zyga: lines 85+, unless you have something else in mind | 09:27 |
| zyga | mborzecki: I mean that one snap should say "snap-a" and the instance snap should say "snap-b" | 09:28 |
| zyga | they should both write | 09:28 |
| zyga | and only after that we should verify the data seen by both | 09:28 |
| zyga | so that it's not "snap-a" in all the places (or snap-b in all the places) | 09:28 |
| mborzecki | zyga: that's exactly what's there | 09:29 |
| zyga | hmm? | 09:29 |
| zyga | but you write foo-1, 2, 3 for _both_ | 09:29 |
| zyga | so how can you check that | 09:29 |
| mborzecki | zyga: $name foo-1 .. | 09:29 |
| zyga | either I don't see it or the pastebin is wrong :D | 09:29 |
| zyga | aaah | 09:29 |
| zyga | $name :D | 09:29 |
| === chihchun_afk is now known as chihchun | ||
| zyga | I didn't notice that at a ll | 09:29 |
| zyga | ++ | 09:29 |
| zyga | it's good :) | 09:29 |
| mborzecki | heh :) | 09:29 |
| zyga | thank you | 09:29 |
| mborzecki | zyga: ok, i'll add it to the tests and integration branches, and deal with that change in mount spec that you suggested layer | 09:31 |
| mborzecki | have to deal with UpdateMany() now | 09:31 |
| mvo | zyga: do you know what (bind) mounts /var/lib/extrausers in snap-confine - git grep extrausers is very quiet for me | 09:33 |
| zyga | let me think | 09:33 |
| zyga | I don't think that's us | 09:33 |
| zyga | isn't that the test setup? | 09:33 |
| zyga | or core boot process? | 09:33 |
| zyga | (us as in the cli tools) | 09:34 |
| mvo | zyga: snap run --shell test-snapd-tools.echo gives me a valid /var/lib/extrausers inside the mount namespace | 09:34 |
| mvo | zyga: so I assume that is us doing it | 09:34 |
| zyga | ok, let me look deeper | 09:34 |
| zyga | probably my memory is just rusty | 09:34 |
| zyga | ah | 09:35 |
| zyga | I know | 09:35 |
| zyga | just let me check to be 100% sure | 09:35 |
| zyga | yep | 09:35 |
| zyga | it's the LXD quirk | 09:35 |
| zyga | we have a "quirk" system in snap-confine that we only used after a particular release of snap-confine broke lxd | 09:35 |
| zyga | we make /var/lib/lxd (which is not in the base snap) | 09:36 |
| zyga | and we bind mount the host's version there | 09:36 |
| zyga | to do that we construct an (older implementation of) a writable mimic over /var/lib | 09:36 |
| zyga | I would like to disable that code but perhaps hard to ensure it's not a backwards incompatible change now | 09:36 |
| mvo | zyga: and this runs only if core is the base? not core18 ? or how is that decided? | 09:36 |
| zyga | (and we could tie that code to the lxd interface perhaps) | 09:36 |
| zyga | it runs on all classic systems for sure | 09:36 |
| zyga | let me look | 09:36 |
| zyga | yes | 09:37 |
| mvo | zyga: aha, ok | 09:37 |
| zyga | sc_setup_quirks is called if distro is SC_DISTRO_CLASSIC | 09:37 |
| zyga | but I would like to drop that, really | 09:37 |
| zyga | it pollutes the mount table with stuff for one snap but runs for all the snaps | 09:37 |
| zyga | and it's very very very likely to be unused now | 09:37 |
| zyga | and it can move to an interface (for sure) | 09:38 |
| mvo | zyga: hm, something else is going on - I see this on !classic, on uc16 | 09:38 |
| zyga | though all such transitions are non-trivial because we have no mechanism to update in-place the | 09:38 |
| zyga | oh | 09:38 |
| zyga | maybe there's a bug in core / classic classification on uc16 | 09:38 |
| mvo | zyga: could be, not super important right now, I was mostly looking why core18 was not displaying a username on core18 devices inside the mount namespace | 09:39 |
| zyga | mvo: what's the /etc/os-release file you see? | 09:39 |
| mvo | zyga: https://paste.ubuntu.com/p/XkFW7hYYTX/ | 09:40 |
| zyga | ID=ubuntu-core | 09:40 |
| mvo | zyga: silly question - in sc_mount_config what does "normal mode" mean? | 09:41 |
| zyga | normal mode is the preferred mode of operation where pivot root happens | 09:41 |
| zyga | the exceptional mode is only on core16 when we don't do that | 09:41 |
| zyga | (for compatibility reasons) | 09:41 |
| zyga | the exceptional mode is called "legacy mode" | 09:42 |
| mvo | zyga: do we have two normal modes? on in the struct and one global? | 09:42 |
| zyga | nope | 09:42 |
| zyga | normal == used on classic, used on core 18 + | 09:43 |
| zyga | legacy == used only on core16 | 09:43 |
| zyga | brb, coffee | 09:43 |
| mvo | zyga: thank you | 09:43 |
| mvo | zyga: enjoy coffee, I will dig a bit around myself | 09:43 |
| mup | PR snapd#5683 opened: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683> | 09:44 |
| zyga | mvo: back | 10:04 |
| zyga | I was getting coffee making lessons actually (unexpectedly) | 10:04 |
| zyga | mvo: I can spin up a core16 VM and check as well if you want | 10:04 |
| mborzecki | need to go to the car shop, will work from there, bbiab | 10:05 |
| zyga | kk | 10:05 |
| zyga | mvo: you can also get a trace with SNAP_CONFINE_DEBUG=yes | 10:06 |
| zyga | perhaps that will shed some light as to what is going on | 10:07 |
| mvo | zyga: ok | 10:08 |
| zyga | mvo: if you pastebin that I will gladly look | 10:08 |
| zyga | mvo: just remember that on 2nd run it will use the persisted namespace | 10:09 |
| zyga | so you may want to discard it before collecting the log | 10:09 |
| mvo | zyga: https://paste.ubuntu.com/p/mTqsSKSfTz/ | 10:10 |
| mup | PR snapd#5692 opened: snap-confine: map /var/lib/extrausers into snaps mount-namespace <Created by mvo5> <https://github.com/snapcore/snapd/pull/5692> | 10:10 |
| mvo | zyga: oh, what was the command again to discard it? | 10:10 |
| mvo | zyga: ^- the PR above is the actual problem I want to fix :) | 10:10 |
| mvo | zyga: this is a bit of a side-issue | 10:10 |
| zyga | mvo: /usr/lib/snapd/snap-discard-ns $SNAP_NAME | 10:10 |
| mvo | zyga: https://paste.ubuntu.com/p/26bb6N4mVQ/ | 10:11 |
| zyga | mvo: if you use SNAP_DEBUG=1 you will also get snap-update-ns feedback | 10:12 |
| zyga | mvo: hmm | 10:12 |
| zyga | mvo: so this says nothing happened really pretty much | 10:12 |
| mvo | zyga: https://paste.ubuntu.com/p/FtqGCYzTnT/ <- with SNAPD_DEBUG=1 | 10:15 |
| mwhudson | niemeyer: https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/corecfg.go#L119-L125 <- means that snap set core proxy.http doesn't do anything on non-core, right? | 10:25 |
| mvo | mwhudson: correct | 10:25 |
| mwhudson | mvo: context https://bugs.launchpad.net/snapcraft/+bug/1533899 | 10:26 |
| mup | Bug #1533899: Add support for proxies <canonical-is> <proxy> <webdm> <cloud-init:New> <Snap Layer:Fix Released by stub> <Snapcraft:Invalid> <Snappy:Fix Released> <snapweb:Invalid> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1533899> | 10:26 |
| mvo | mwhudson: aha, I see. this is about respecting it in snapd internally? | 10:27 |
| mwhudson | mvo: i don't know | 10:27 |
| mvo | mwhudson: yeah, I think thats missing but should be simple, let me have a poke | 10:27 |
| Chipaca | mwhudson: proxy on classic can be set via /etc/environment, can't it? | 10:28 |
| mwhudson | mvo: there is a tension core-aka-system-config vs core-aka-snapd-config | 10:28 |
| mwhudson | mvo: which i guess you are fixing in series 18 :) | 10:28 |
| mwhudson | Chipaca: that works about as well or badly as any other way of setting it, yes | 10:28 |
| Chipaca | mwhudson: also to keep things interesting, there's http proxying, and there's snap store proxy | 10:29 |
| mvo | mwhudson, Chipaca my gut feeling is that on core device we edit /etc/environment and thats fine. on classic we don't but we should still lookup if the config was set and respect it | 10:29 |
| zyga | brb | 10:29 |
| Chipaca | sparkieg`: the link to documentation from https://forum.snapcraft.io/t/announcing-snap-store-proxy-beta/4666 is broken | 10:30 |
| mwhudson | i think snapd.service still says EnvironmentFile=/etc/environment? | 10:30 |
| Chipaca | mwhudson: yup | 10:30 |
| mwhudson | anyway, i wouldn't want people to think that saying snap set core proxy.http=.. does anything at all on classic now, because it doesn't | 10:30 |
| mwhudson | maybe it should but i don't have an opinion on that :) | 10:31 |
| Chipaca | mvo: mwhudson: on classic, setting the proxy via unity-control-center edits /etc/environment | 10:31 |
| mvo | Chipaca: yeah, thats fine | 10:31 |
| Chipaca | I'm lost about what the bug is about tbh | 10:31 |
| Chipaca | description just talks about core | 10:31 |
| mvo | Chipaca: I was mostly thinking that we should do somehting on classic. either error if you try to set it on classic *or* respect it for snapd only | 10:31 |
| mvo | Chipaca: yeah, its not entirely clear to me either but there is confusion and it seems the above (either error or support it) should fix the confusion | 10:32 |
| mvo | mwhudson: ^- does this make sense? | 10:32 |
| Chipaca | mvo: hold on | 10:32 |
| mwhudson | Chipaca: should probably do something to do with environment.d(7) nowadays? don't really care though | 10:33 |
| Chipaca | mvo: "snap set system proxy.store=xyzzy" works on classic, doesn't it? | 10:33 |
| Chipaca | mwhudson: environment.d wasn't in <18 afaik | 10:33 |
| mwhudson | oh wait that's only user sessions? | 10:33 |
| mwhudson | yeah all this is fairly new | 10:33 |
| niemeyer | mvo: Don't we use the proxy internally? | 10:33 |
| mvo | mwhudson: this is not read by pam, right? so things like ssh will not use it(?) | 10:33 |
| Chipaca | mwhudson: so yeah nah | 10:33 |
| mvo | niemeyer: I think we did not add support for this, I can look into making this happen should be easy but iirc we did not do it yet | 10:34 |
| Chipaca | mvo: erroring on the ones we don't support would be good yes | 10:34 |
| mvo | mwhudson: I whish pam_env would support it, I looked at this briefly but iirc there were some complications (beside it being pam) | 10:34 |
| mwhudson | mvo: something extra fun iirc here is that go's ProxyFromEnvironment looks at the environment *once* | 10:35 |
| mvo | Chipaca: yeah, lets see if niemeyer prefers support or error | 10:35 |
| mvo | mwhudson: heh, fun indeed :) | 10:35 |
| mwhudson | i spent a while trying for subiquity to find a way of providing a proxy to snapd that didn't involve restarting it and failed | 10:35 |
| niemeyer | For some reason I assumed we were already using it for internal purposes at least.. just not changing the whole system configuration when !core | 10:36 |
| Chipaca | mvo: wait, that onClassic check means we don't support proxy.store on classic either | 10:36 |
| mvo | mwhudson: hm, you should talk to use more :) | 10:36 |
| niemeyer | Chipaca: Yeah, this is busted | 10:36 |
| mwhudson | mvo: probably | 10:36 |
| mvo | mwhudson: I mean, we can/should honor it internally | 10:36 |
| mvo | Chipaca: is it? this is just used internally, no? | 10:36 |
| Chipaca | mvo: which is 'this'? | 10:36 |
| mwhudson | i should also not rush to complete features before deadlines i guess | 10:37 |
| mvo | Chipaca: let me look at the code before I make more statements :) | 10:37 |
| Chipaca | mvo: ok :-) | 10:37 |
| mvo | Chipaca: what I mean is that iirc we allow setting proxy.store | 10:37 |
| mvo | Chipaca: and it is store in the internal configuration state | 10:37 |
| mvo | Chipaca: and we honor it inside our code | 10:37 |
| Chipaca | mwhudson: turns out deadlines are really only slightly-upset-lines | 10:37 |
| niemeyer | Chipaca: Ah, except we do it seems | 10:37 |
| mvo | Chipaca: *but* I have not looked at this | 10:37 |
| mvo | Chipaca: I mean, this is just memory | 10:37 |
| * Chipaca tries | 10:38 | |
| Chipaca | hmm, proxy.store does do _something_ (it complains about a missing assertion at least) | 10:39 |
| Chipaca | proxy.http does not, though | 10:39 |
| mvo | Chipaca: yeah, thats my understanding | 10:39 |
| mvo | Chipaca: let me do a quick PR that errors and then I do a not-so-quick PR that honors it internally | 10:39 |
| mwhudson | looks like all snap set core proxy.store does is validate the args | 10:40 |
| mvo | niemeyer: ^- sounds reasonable? | 10:40 |
| mwhudson | on any system | 10:40 |
| Chipaca | bah | 10:40 |
| Chipaca | i dunno | 10:40 |
| Chipaca | validation happens, but handling does not ? | 10:40 |
| mwhudson | looks like it | 10:40 |
| mvo | Chipaca: we don't need to handle it at this level, do weß | 10:40 |
| mvo | s/ß/?/ | 10:40 |
| * Chipaca gives up | 10:40 | |
| * mwhudson gets back to ordering groceries (why the laptop is open at 22:40) | 10:40 | |
| * Chipaca goes shopping | 10:40 | |
| Chipaca | mwhudson: a solid plan | 10:40 |
| mwhudson | ha | 10:40 |
| mvo | Chipaca: I mean - for http.proxy we need to modify the filesystem but proxy.store is only used internally and does not need any external actions iirc | 10:41 |
| niemeyer | func ProxyStore(st *state.State) (*asserts.Store, error) { | 10:41 |
| niemeyer | tr := config.NewTransaction(st) | 10:41 |
| niemeyer | var proxyStore string | 10:41 |
| niemeyer | err := tr.GetMaybe("core", "proxy.store", &proxyStore) | 10:41 |
| niemeyer | The fact we don't do anything at set time but validation doesn't mean it's unused | 10:41 |
| mvo | +1 | 10:41 |
| niemeyer | I assumed the same was being done for proxy, at least for internal purposes | 10:42 |
| niemeyer | We just shouldn't fiddle with the whole system when snapd is not on a core system | 10:42 |
| niemeyer | But respecting the variable seems reasonable | 10:42 |
| niemeyer | I mean, if people don't want snapd to have a proxy, just don't set it | 10:42 |
| mvo | niemeyer: yeah, I think we are in agreement, I have a look at this | 10:43 |
| niemeyer | mvo: The question is what's the easiest way to make sure all requests are proxied | 10:43 |
| niemeyer | mvo: It may well be to take the proxy configuration and set the environment variable | 10:43 |
| niemeyer | Both when we start, and when someone changes the conifg | 10:44 |
| niemeyer | Otherwise we'll need to tune every single *http.Client | 10:44 |
| mvo | niemeyer: yeah, this is straightforward, we need to double check that golang actually reads the env anew every time | 10:44 |
| niemeyer | mvo: +1.. I assume it does, but needs confirmation indeed | 10:44 |
| mwhudson | er no it doesn't | 10:45 |
| mwhudson | that's what i was saying above | 10:45 |
| mvo | mwhudson: hm, hm, thats unfortunate | 10:46 |
| ogra | just make people stop using that ancient classic thing ;) core for everyone ! | 10:46 |
| mvo | niemeyer: the good news is that we have httputils:NewHTTPClient so hopefully a single point where we need to inject this | 10:47 |
| mwhudson | mvo: hmmm maybe i am wrong, or maybe this has changed in golang now | 10:47 |
| mvo | mwhudson: I was just looking at 1.10 | 10:48 |
| mvo | mwhudson: but then we still build with 1.6 :( | 10:48 |
| mwhudson | ah no net/http's ProxyFromEnvironment still has a sync.once | 10:49 |
| niemeyer | mvo: Ah, sweet! I didn't realize we had already consolidated that, great | 10:49 |
| mvo | niemeyer: its a bit of a layering problem still because we use that in e.g. "snap download" so we need access to the state | 10:50 |
| mvo | niemeyer: we could of course cheat and set an (internal) env var snapd_http_proxy etc | 10:50 |
| niemeyer | mvo: I think we need to fix snap download to be more typical | 10:50 |
| niemeyer | mvo: Meanwhile, we might just ask for the config in the command maybe? | 10:51 |
| niemeyer | mvo: I mean, the configuration is readable from the API | 10:51 |
| mvo | niemeyer: great idea | 10:51 |
| mwhudson | aah ok you can call golang.org/x/net/httpproxy.FromEnvironment() to make a new thing from the current environment | 10:54 |
| mwhudson | (thanks to rog, it seems0 | 10:56 |
| mwhudson | ) | 10:56 |
| mvo | mwhudson: this will work in 1.6? | 10:58 |
| mwhudson | mvo: no idea | 10:58 |
| mwhudson | mvo: suspect not :/ | 10:58 |
| mwhudson | mvo: do you have a plan for getting off 1.6? | 10:59 |
| mwhudson | juju-core uploads in xenial build golang first... | 10:59 |
| mvo | mwhudson: I hard foundations will support 1.10 in xenial :P | 10:59 |
| mvo | mwhudson: yeah, we might need to do the same, I'm not looking forward to it | 11:00 |
| mwhudson | mvo: i just do what the security team tells me to do | 11:00 |
| mvo | mwhudson: heh, sure I understand the issue(s) | 11:00 |
| mwhudson | (which is why juju does what it does!) | 11:00 |
| mvo | mwhudson: it makes me wonder (again) if we should make the snapd in the deb just a small shim that downloads the snapd *snap* which we then can build in whatever way we want | 11:00 |
| * mwhudson reaches for his boostraps only to find he's already standing on them | 11:01 | |
| mwhudson | mvo: something about the current setup certainly smells bad | 11:03 |
| mwhudson | mvo: something something prepare-image classic something | 11:03 |
| mvo | mwhudson: I'm missing something here, what about prepare-image classic ? | 11:04 |
| * mvo might be a bit slow due to lack of lunch | 11:04 | |
| mwhudson | mvo: heh i'm skipping ahead in ways that probably don't make sense | 11:04 |
| mwhudson | mvo: we already support including snaps in all the images we make | 11:05 |
| mwhudson | or will | 11:05 |
| mwhudson | why shouldn't the snapd snap be one of them? | 11:05 |
| mvo | mwhudson: \o/ I like that thinking! | 11:06 |
| mwhudson | well because it's snapd that processes the seed.yaml | 11:06 |
| mvo | mwhudson: sillly bootstraps | 11:06 |
| mwhudson | so you need something to at least partly process it at image build time | 11:06 |
| mwhudson | --> prepare image for classic | 11:06 |
| mvo | mwhudson: yeah, we would just need to extract the snapd binary and when it starts and finds a valid seed env it will DTRT (i.e. seed itself, restart itself, seed the rest) | 11:07 |
| mvo | mwhudson: so that is actually pretty simple | 11:07 |
| mwhudson | and then you can use the go snap to build snapd :) | 11:08 |
| mvo | mwhudson: \\o// | 11:08 |
| mvo | mwhudson: I will think about this over lunch | 11:09 |
| mwhudson | mvo: i'm at least somewhat procastinating about ordering groceries, please don't let me disturb your day too much | 11:10 |
| Chipaca | um, sorry if i got distracted and worked on the same thing you've been working | 11:10 |
| Chipaca | without reading all the backlog :-) | 11:11 |
| Chipaca | i can confirm proxy.store works on classic | 11:11 |
| * Chipaca hates having to set up proxy for a quick check like this | 11:12 | |
| * Chipaca now wonders if he's stuck with the proxy asserts forever | 11:12 | |
| mup | PR snapd#5693 opened: overlord/snapstate: verify SnapState name matches instance key <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5693> | 11:12 |
| * Chipaca further wonders why he didn't do it in a vm | 11:12 | |
| zyga | Chipaca: setting proxy on classic blows up fuses in your CPU *forever* | 11:13 |
| mborzecki | pedronis: i'm wondering if a change like #5693 would be useful (actually makes my life easier in the tests) | 11:13 |
| mup | PR #5693: overlord/snapstate: verify SnapState name matches instance key <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5693> | 11:13 |
| Chipaca | zyga: 'proxy' is not settable, so neener neener | 11:13 |
| ogra | jdstrand, already around ? | 11:17 |
| Chipaca | mborzecki: which was the pr you asked me to review? | 11:31 |
| mborzecki | Chipaca: https://github.com/snapcore/snapd/pull/5670 | 11:34 |
| mborzecki | Chipaca: thanks! | 11:34 |
| mup | PR #5670: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670> | 11:34 |
| pedronis | mborzecki: it's a bit problematic because some buggy code in a corner doesn't undo the current op, it kills snapd | 11:40 |
| pedronis | but making Set return an error is a huge change | 11:40 |
| mborzecki | pedronis: yeah, that's what i'm afraid of, either way it's no good :/ | 11:41 |
| pedronis | mborzecki: otoh I don't think we have a ton of non-test places using Set | 11:41 |
| pedronis | you might just do it one level up or have a wrapping helper | 11:42 |
| mborzecki | pedronis: the reason i added it is that in the tests it's easy to do .Set(.., "foo_bar", ..) and forget to set InstanceKey in SnapState | 11:42 |
| mborzecki | pedronis: MustSet? | 11:42 |
| pedronis | I see, for tests | 11:43 |
| pedronis | that is a big change too | 11:43 |
| mborzecki | pedronis: ok, let me drop it for now | 11:43 |
| mup | PR snapd#5693 closed: overlord/snapstate: verify SnapState name matches instance key <Parallel installs> <Simple> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5693> | 11:45 |
| pedronis | mborzecki: an approach would be some kind of global flag we set in tests | 11:51 |
| mborzecki | pedronis: right, that would work, i saw some test only flags/ifs inside the code, so the precedent is set | 11:52 |
| Facu | hi all! | 11:54 |
| Facu | may it be that snap is restarting my lxd? I have this in my /var/log/syslog: http://linkode.org/#UkaWdFxuTwqJTFFc3UqLW5 | 11:54 |
| Facu | in that log, snap is telling that some of my snaps have no update available, but for lxd it doesn't say that, and some seconds later lxd is stopped | 11:55 |
| mborzecki | zyga: hah, layout test recovery has to be improved little, it leaves garbage behind, jut had tests/main/layout fail because tests/main/parallel-install-layout left the /etc/* symlinks | 11:56 |
| zyga | mborzecki: yeah, that's the (existing) bug I mentioned | 11:57 |
| mborzecki | mhm | 11:57 |
| mborzecki | zyga: the trespassing thing, something i could help you with? | 11:58 |
| zyga | yes, I have a branch that we need to go back to | 11:58 |
| zyga | I got stuck on the precise algorithm there (after loads of attempts) | 11:58 |
| zyga | we can talk about that today | 11:58 |
| mborzecki | zyga: i remember the reviewing some checkers for this | 11:58 |
| zyga | yeah, a lot of the preceding helpers landed but the "meat" did not | 11:59 |
| mborzecki | sounds familiar :) | 11:59 |
| pedronis | mvo: I saw you updated the roadmap, there is still some mistyped "topic" in the 2.34 bits | 12:05 |
| === pstolowski is now known as pstolowski|lunch | ||
| mup | PR snapd#5694 opened: tests/main/layout: cleanup after the test <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5694> | 12:12 |
| mborzecki | zyga: ^^ | 12:12 |
| zyga | yeah, +1 | 12:13 |
| zyga | odd - we had that before | 12:13 |
| zyga | must have been lost in some PR | 12:13 |
| zyga | I remember that all of the trespassing PRs (the full blown versions that didn't land) removed that part | 12:14 |
| mborzecki | yeah, btw. cachio__ tracking of tests that executed before came in handy :) | 12:14 |
| ackk | hi, I'm trynig to implement a configure hook for a snap, but I get "snapctl: not found" when I run "snapctl get <something>" in the hook script | 12:15 |
| cachio__ | mborzecki, :) | 12:15 |
| ackk | do I need special permissions for the snap to do that? | 12:15 |
| ogra | Facu, better start a forum thread ... (see channel topic) | 12:16 |
| Facu | ogra, ack, thanks | 12:18 |
| mup | PR snapd#5684 closed: cmd/snap: create snap user directory when running parallel installed snaps <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5684> | 12:29 |
| zyga | mvo: any luck? | 12:30 |
| Gargoyle | Hi all. All my snaps have stopped working - is this likely to be related to giving kernel 4.18 a spin (I can't think of anything else I have done). "snap list" shows them all, but none of them work. lxd, discord, postman. It's as though they are just not on the system. | 12:31 |
| zyga | Gargoyle: hey, can you provide some more details? what does snap version show? | 12:33 |
| mvo | pedronis: thanks, will fix the ypos | 12:33 |
| mvo | pedronis: *cough* typos | 12:33 |
| pedronis | mvo: not the most important thing but I see them :) | 12:33 |
| mvo | zyga: no luck, lunch and tea and then | 12:34 |
| zyga | k | 12:34 |
| mvo | pedronis: yeah, thanks for noticing! | 12:34 |
| mvo | Chipaca: did you work on the http-proxy stuff? or just store proxy? | 12:34 |
| Chipaca | mvo: I just set up postgres and the store proxy to get the assertions and see if it actually worked (it did) | 12:34 |
| mvo | Chipaca: great | 12:35 |
| Chipaca | mvo: I also set http-proxy and confirmed it did not work | 12:35 |
| mvo | Chipaca: thanks for doing this! | 12:35 |
| mvo | Chipaca: I am looking into making http-proxy actually work | 12:35 |
| Gargoyle | zyga: https://paste.ubuntu.com/p/qFcJvTKx5Z/, I've also tried "snap remove postman" and "snap install postman" which seemed to run the installation fine, but can't launch "postman" from gnome or command line. | 12:35 |
| Chipaca | mvo: if in classic, and it's set, it overrides environ? | 12:35 |
| zyga | Gargoyle: how did you install the 4.18 kernel? | 12:35 |
| mvo | Chipaca: I would assume so, going from most generic to most specific | 12:35 |
| zyga | perhaps there's an issue with that kernel and snap confinement | 12:36 |
| Chipaca | mvo: can I bother you for a +1/-1 on #5689 ? | 12:36 |
| Chipaca | mvo: (you already looked at it) | 12:36 |
| mup | PR #5689: many: move Uname to osutil, for more DRY and easier porting <Created by chipaca> <https://github.com/snapcore/snapd/pull/5689> | 12:36 |
| Gargoyle | zyga: From the .deb files on http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18.3/ | 12:36 |
| zyga | I see | 12:36 |
| mvo | Chipaca: we could also warn | 12:36 |
| zyga | Gargoyle: I can give that a spin | 12:36 |
| mvo | Chipaca: sure, looking | 12:36 |
| Chipaca | mvo: thanks | 12:36 |
| mvo | Chipaca: you stole all the comments ;) or it would be approved already | 12:37 |
| Chipaca | mvo: I put 'em back :-D | 12:37 |
| * mvo stops being silly and looks at the code | 12:37 | |
| Gargoyle | zyga: Cool. I had nvidia drivers and virtualbox installed, so I removed those first and re-installed later. Everything else seems to be working a-ok. | 12:38 |
| zyga | Gargoyle: do you have any apparmor denials? | 12:38 |
| zyga | what does snap debug sandbox-features # shows | 12:38 |
| zyga | (apparmor denials can be checked with: dmesg | grep DENIED | 12:39 |
| Chipaca | mvo: \o/ | 12:39 |
| mup | PR snapd#5689 closed: many: move Uname to osutil, for more DRY and easier porting <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5689> | 12:39 |
| Gargoyle | zyga: https://paste.ubuntu.com/p/z6xX3vwGKT/ | 12:40 |
| Gargoyle | Snap core denied... that's probably not good!? :/ | 12:41 |
| mup | PR snapd#5695 opened: osutil/sys: small tweaks to let it build on darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/5695> | 12:41 |
| zyga | mmm | 12:41 |
| zyga | Gargoyle: I think I've seen this, it looked like a bug in the latest kernel | 12:42 |
| zyga | jdstrand, jjohansen1: ^ do you guys remember if the ptrace(read) issue turned out to be a kernel bug? | 12:42 |
| mvo | zyga: hm, we have no notion of "optional" things to mount into a mount namespace right now? i.e. if /var/lib/extrausers exists, mount otherswise no error? | 12:44 |
| mvo | zyga: mind if I add it? | 12:44 |
| zyga | mvo: we do now (almost, just needs an ack from jdstrand) | 12:44 |
| zyga | mvo: look athttps://github.com/snapcore/snapd/pull/5307 | 12:44 |
| mup | PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307> | 12:44 |
| zyga | once that lands we can use this feature | 12:44 |
| * zyga goes and fixes garbage in that PR | 12:46 | |
| zyga | brb | 12:48 |
| mvo | zyga: cool, I will base my PR on yours then | 12:49 |
| mup | PR snapd#5696 opened: interfaces/builtin/opengl.go: add additional cuda bits to opengl <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696> | 12:51 |
| Gargoyle | brb, reboot (reverting to 4.15) | 12:58 |
| === pstolowski|lunch is now known as pstolowski | ||
| morphis | Chipaca: hm, let me have a look | 13:00 |
| morphis | Chipaca: no, sure. I don't see any reason for it to use SIGUSR1 | 13:01 |
| Gargoyle | zyga: All working fine again back on 4.15. | 13:01 |
| Chipaca | morphis: ok, thank you | 13:01 |
| zyga | Gargoyle: ack | 13:02 |
| zyga | mvo: ack | 13:02 |
| mborzecki | store hiccup? | 13:06 |
| mup | PR snapd#5690 closed: Add an error code for Polkit auth cancels <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5690> | 13:23 |
| zyga | mvo: do you know more about the details of the core18 mount issue that cachio mentioned? | 13:24 |
| sergiusens | Chipaca: does the latest snapd in beta now default to setting the snaps in /var/lib/snapd/snaps to 600? | 13:27 |
| Chipaca | sergiusens: yes | 13:28 |
| sergiusens | Chipaca: this unfortunately breaks snap install snapcraft ....; mkdir project; cd project; snapcraft init; /snap/bin/snapcraft cleanbuild | 13:28 |
| Chipaca | sergiusens: <3 you're using beta! | 13:29 |
| sergiusens | Chipaca: not me... I got burned by beta already :-P | 13:29 |
| Chipaca | sergiusens: boo :-( | 13:29 |
| sergiusens | not on my main machine at least, I rely on too many snaps to get my work done that if anything breaks I would need to use my cellphone until I bring back my computer from backup | 13:30 |
| sergiusens | Chipaca: how many snaps do you rely on for day to day work ;-) | 13:30 |
| mborzecki | damn, was looking for bugs in snapstate.refreshCandidate(), found i'm not setting parallel-instances feature flag | 13:30 |
| popey | i too have been burned this morning by this | 13:31 |
| popey | should I refresh core to stable, or something else? | 13:33 |
| Chipaca | sergiusens: ~5 :-) | 13:34 |
| sergiusens | Chipaca: my only installed browser and code editor are from snaps :-) | 13:34 |
| popey | every application i have open is a snap | 13:35 |
| Chipaca | sergiusens: popey: you're awesome | 13:37 |
| jdstrand | zyga (cc mvo and Gargoyle): it was a kernel *fix* | 13:44 |
| zyga | jdstrand: I see, is it upstream now? | 13:44 |
| jdstrand | Gargoyle: if you update to snapd 2.35, it will work | 13:45 |
| Gargoyle | ahh. OK. Thanks. | 13:45 |
| jdstrand | zyga: is what upstream? the kernel fix? yes, it is in 4.18. there is a fix for this in snapd 2.35 already. there is additional work to only add the trace rule conditionally, but that needs kernel upstreaming (but is not a problem for snapd, it is just hardening) | 13:46 |
| zyga | ok | 13:47 |
| jdstrand | https://forum.snapcraft.io/t/snaps-are-not-working-with-linux-kernel-v4-18-rc/6708/3 | 13:47 |
| mborzecki | going to pick up the car, bbl | 13:55 |
| Chipaca | https://www.reddit.com/r/Ubuntu/comments/992mcd/help_snaps_are_using_all_my_data/ fwiw | 14:15 |
| * Chipaca pushes a "EAT MORE DATA" PR | 14:15 | |
| pstolowski | so, re system snap name - hotplug needs to know where to attach hotplug slots to; there needs to be one authoritative helper that does return snapinfo for the system i think. what kind of logic do we need for that, should these slots live on "snapd" snap if available? | 14:32 |
| Chipaca | sergiusens: so, about files being 0600, what can we do? | 14:35 |
| Chipaca | sergiusens: you were there when we decided to do this :-) | 14:35 |
| sergiusens | Chipaca: the alternatives are: break everything, wait on the release until we add logic for this or revert the change | 14:36 |
| sergiusens | Chipaca: yes, but the when was not decided :-) | 14:36 |
| sergiusens | Chipaca: I was also there when we decided on the first version of epochs, it lives in snapcraft to this date ;-) | 14:36 |
| Chipaca | sergiusens: it really sounds like you're asking for a waterfall process with deliverables and stuff which ain't gonna happen | 14:37 |
| Chipaca | :-) | 14:37 |
| Chipaca | sergiusens: hold on | 14:37 |
| Chipaca | sergiusens: this came about because, in _some_ situations, files were already 0600 | 14:37 |
| sergiusens | yes, the ones with x | 14:37 |
| Chipaca | sergiusens: so you already have a workaround for those? | 14:38 |
| sergiusens | so, snaps with no assertions | 14:38 |
| sergiusens | yes, if the revision starts with x, sudo comes into play | 14:38 |
| Chipaca | ah | 14:38 |
| Chipaca | sergiusens: given the alternatives, we need to involve mvo and niemeyer | 14:39 |
| zyga | pstolowski: I'm going for lunch now, sorry; took a break to sync with family | 14:39 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | sergiusens: so, a proposal | 14:43 |
| Chipaca | sergiusens: as a temp fix, make it always use sudo for that step (I'd like to see how it uses sudo, just in case) | 14:44 |
| Chipaca | sergiusens: then, maybe in 2.36 we can add something that lets you stream the snapfile given some constraints | 14:45 |
| Chipaca | sergiusens: how does that sound? | 14:45 |
| sergiusens | Chipaca: all the new code is already resilient, it is this old stuff, which everyone uses that will break | 14:46 |
| sergiusens | requesting sudo for non corner case will suck though | 14:46 |
| Chipaca | sergiusens: what's the code that does this? | 14:48 |
| sergiusens | Chipaca: it still begs the question, will you wait until that makes it into general availability? | 14:48 |
| Chipaca | sergiusens: I am not the one that decides that | 14:48 |
| Chipaca | ah, found the code | 14:49 |
| sergiusens | Chipaca: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L345 | 14:50 |
| Chipaca | hmm | 14:53 |
| Chipaca | sergiusens: when I run snapcraft from master things just worked | 14:53 |
| Chipaca | sergiusens: what's the snap doing differently? | 14:53 |
| sergiusens | Chipaca: injection is when running from the snapcraft snap | 14:53 |
| Chipaca | ah, i guess that's common.is_snap() == False and the other path | 14:53 |
| Chipaca | sergiusens: unrelated question about this code | 14:54 |
| Chipaca | sergiusens: I see the watch for auto-refresh, but i don't see the refresh.hold; is that done? | 14:54 |
| sergiusens | Chipaca: for the new code | 14:56 |
| mborzecki | re | 14:57 |
| Chipaca | mborzecki: wb | 14:57 |
| sergiusens | Chipaca: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_snap.py#L263 | 14:57 |
| Chipaca | mborzecki: do you remember if we check metered for the catalog refresh? | 14:57 |
| sergiusens | I asked you to look at the PR 2 weeks ago :-) | 14:57 |
| mborzecki | Chipaca: we probably don't | 14:58 |
| Chipaca | sergiusens: does it still need a look? | 14:59 |
| sergiusens | it is already in master, but yeah, a look never hurts | 14:59 |
| Chipaca | sergiusens: but the _containerbuild.py does not do/use that/ | 14:59 |
| Chipaca | ? | 14:59 |
| mup | PR snapd#5670 closed: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5670> | 14:59 |
| sergiusens | Chipaca: it does not, I can point release that in the future | 15:00 |
| cachio | mvo, should I run sru for 2.35 after beta validation? | 15:01 |
| Chipaca | mvo: note sergiusens says we might want to hold off on 2.35 until snapcraft is ready for it | 15:02 |
| Chipaca | sergiusens: getting back to containerbuild, why would using sudo suck that much? | 15:03 |
| mvo | cachio: yeah, that wouldbe great. is it accepted into -proposed yet? if not we need to ask apw to have a look if snapd can go into -proposed | 15:04 |
| sergiusens | Chipaca: because it previously was not requested, that's all | 15:04 |
| mvo | Chipaca: oh, tell me more please | 15:04 |
| sergiusens | Chipaca: I will work on a fix | 15:04 |
| Chipaca | mvo: the 0600 snaps means 'snapcraft cleanbuild' fails for snapped snapcraft | 15:04 |
| mvo | ok, when does snapcraft plan to push the update? | 15:05 |
| Chipaca | mvo: we were still discussing what to do about it | 15:05 |
| sergiusens | mvo: we need to write a fix first | 15:05 |
| mvo | sergiusens: heh, ok | 15:05 |
| Chipaca | mvo: I flagged you and niemeyer above, but it's just been the two of us | 15:05 |
| mvo | sergiusens: sorry, i missed that | 15:05 |
| mvo | sergiusens: this sounds like its a couple of days away? with qa and pushing a new release and all that? | 15:05 |
| Chipaca | mvo: the easy fix sucks for users | 15:06 |
| mvo | yeah | 15:06 |
| mvo | sudo is not great | 15:06 |
| Chipaca | to be clear, it was already using sudo before, just in more cornery-cases (sideloaded files were already 0600) | 15:06 |
| sergiusens | mvo: provided that I have been running adt to push a new snapcraft for a week and just did dput I am not so confident | 15:06 |
| sergiusens | but yeah, as soon as possible | 15:07 |
| Chipaca | mvo: and then the question is, what can snapd do to make it better | 15:07 |
| cachio | mvo, sure, I'll try to promote to candidate 2.35 today and then I'll start with thtat | 15:07 |
| niemeyer | sergiusens, Chipaca: How about using download? | 15:07 |
| mvo | sergiusens: I share the adt pain | 15:08 |
| mvo | sergiusens: but yeah, that sounds unfortuante, maybe we need to remove this change on our side and re-add on 2.36 | 15:08 |
| mvo | cachio: thank you! | 15:08 |
| Gargoyle | jdstrand: Will 2.35 be made available via standard packages for 18.04, or do you have to add a ppa to get the latest version? | 15:08 |
| sergiusens | niemeyer: I will try download first, it will remove the possibility to inject the currently sideloaded snap (if it existed) but would solve the greater use case | 15:09 |
| niemeyer | sergiusens: Not necessarily | 15:09 |
| niemeyer | sergiusens: But possibly, at least for now | 15:10 |
| niemeyer | sergiusens: I really hope we can stop special casing the "snap download" command.. it's only caused us pain | 15:10 |
| niemeyer | sergiusens: When that happens, we can make "snap download" pick up content from the cache.. that's already done for internal operations | 15:11 |
| sergiusens | niemeyer: oh, I am not asking for that :-) | 15:11 |
| niemeyer | sergiusens: Right, I'm the one suggesting it... | 15:11 |
| sergiusens | niemeyer: 👍 | 15:12 |
| sergiusens | I will work on a fix and get a review from Chipaca | 15:12 |
| Chipaca | I'll make sure to forget to review it | 15:12 |
| zyga | Pharaoh_Atem: hey | 15:12 |
| zyga | Pharaoh_Atem: I think we need your help | 15:12 |
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#5413 closed: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5413> | 15:56 |
| mup | PR snapd#5697 opened: overlord/snapstate: fix UpdateMany() to work with parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5697> | 16:01 |
| mborzecki | pedronis: ^^ | 16:01 |
| pedronis | mborzecki: thanks, I will look at it tomorrow | 16:02 |
| mborzecki | pedronis: great, thank you! | 16:02 |
| === pstolowski is now known as pstolowski|afk | ||
| jdstrand | Gargoyle: it will be made available to 18.04, but since you are on Ubuntu, you can simply do: sudo snap refresh core --beta | 16:15 |
| zyga | niemeyer: hey, could you please refresh spread the snap to the current release please? | 16:31 |
| Chipaca | niemeyer: i'm missing something wrt patch sublevels i'm afraid | 16:32 |
| Chipaca | niemeyer: if a user refreshes from pre-sublevels to a revno with sublevels, and then goes back, what makes the sublevel patch run again when they come back back? | 16:33 |
| ogra | whee ! | 16:38 |
| ogra | i actually managed to get my wmx gui session into a confined state ! | 16:38 |
| pedronis | Chipaca: we need a breaking patch to introduce them? :/ | 16:39 |
| Chipaca | ogra: does your gui have a red button that says 'exec' on it | 16:40 |
| ogra | jdstrand, i'd appreciate if you could unleash wmx-kiosk-session in the snap store ... its another Xwayland snap that uses the loopback x11 setup (similar to xdmcp-client) and got stuck in review | 16:40 |
| pedronis | Chipaca: or maybe not breaking, but a release that just reset them on start | 16:40 |
| Chipaca | pedronis: we could also edit the patchlevel on exit | 16:41 |
| Chipaca | pedronis: i mean, on downgrade, it's snapd doing the downgrade | 16:41 |
| pedronis | but we don't easily know the patchlevel of the old thing | 16:42 |
| ogra | Chipaca, https://imgur.com/a/HuXpmJh | 16:42 |
| ogra | no red | 16:42 |
| Chipaca | ogra: http://okcancel.com/comic/4.html | 16:42 |
| ogra | (but i could add some red ... :) ) | 16:42 |
| ogra | lol ... i love the kill -9 in green :) | 16:43 |
| === chihchun is now known as chihchun_afk | ||
| mvo | Chipaca: an early sniff test of https://github.com/snapcore/snapd/compare/master...mvo5:use-proxy-conf?expand=1 would be great, I will expand and add tests, also ideas where the proxy handler should life would be great (maybe the place is ok) | 16:58 |
| mvo | Chipaca: hey, disconnected, sorry. did you get my earlier message | 17:06 |
| Chipaca | mvo: I got it but I hadn't seen it | 17:07 |
| Chipaca | mvo: looking now | 17:07 |
| mvo | Chipaca: thanks, no worris | 17:09 |
| Chipaca | mvo: that looks nice | 17:10 |
| mvo | Chipaca: yeah, I'm not sure where proxyHelper should live but beside that it just needs some polish and should be good to go | 17:10 |
| Chipaca | mvo: ttfn! see you tuesday! | 17:26 |
| jdstrand | ogra: ok | 17:26 |
| niemeyer | chihchun_afk: Reviewed the PR>. not sure if it clarifies your question | 17:26 |
| niemeyer | chihchun_afk: Sorry.. wrong nick | 17:27 |
| ogra | popey, now confined and shipping all basic x11 apps in the snap https://imgur.com/a/s47MQOw | 17:28 |
| ogra | (though you can indeed not use "snap run" anymore with that) | 17:28 |
| ogra | (unless you explicitly switch to --devmode) | 17:28 |
| Pharaoh_Atem | zyga: wut, what? | 17:38 |
| zyga | Pharaoh_Atem: there are some selinux issues with socket activation of services installed from snaps | 17:38 |
| zyga | Pharaoh_Atem: do you have some time to look into that? | 17:38 |
| Pharaoh_Atem | not right now | 17:38 |
| niemeyer | sergiusens: What happened here: | 17:38 |
| Pharaoh_Atem | I'm really compressed and I'm trying to squeeze time to update snapd right now | 17:39 |
| niemeyer | https://www.irccloud.com/pastebin/dPnQNNkp/output.txt | 17:39 |
| Pharaoh_Atem | zyga: I suspect that this is the consequence of not generating policies here | 17:39 |
| niemeyer | sergiusens: This snap get command doesn't make much sense... | 17:39 |
| Pharaoh_Atem | the socket path used isn't covered in the domain of snappy run applications and services | 17:39 |
| niemeyer | sergiusens: This was the snapcraft.yaml I've been using since I started packing spread as a snap | 17:39 |
| zyga | Pharaoh_Atem: mmm | 17:39 |
| Pharaoh_Atem | because properly packaged lxd works fine | 17:40 |
| niemeyer | sergiusens: The plugin can't be much simpler than this: | 17:40 |
| Pharaoh_Atem | as the SELinux policy for container runtimes already supports LXD when built and installed normally | 17:40 |
| niemeyer | https://www.irccloud.com/pastebin/CltIdxY9/ | 17:40 |
| niemeyer | Sorry, I mean the part | 17:40 |
| Pharaoh_Atem | the fact that no one upstream is interested in bringing LXD to Fedora as a native package is beside the point, though | 17:40 |
| zyga | Pharaoh_Atem: is there something that needs to happen in the snapd policy or is this something to correct in the main policy? | 17:41 |
| Pharaoh_Atem | zyga: I'm not sure | 17:41 |
| Pharaoh_Atem | do we have a strict rule about where sockets are created for snapped services? | 17:41 |
| sergiusens | niemeyer: that does indeed look correct, we have not made any changes as of late to any of this. | 17:41 |
| Pharaoh_Atem | and the other question, how do we enforce the label being set? | 17:41 |
| zyga | Pharaoh_Atem: I don't know | 17:42 |
| niemeyer | sergiusens: Weird.. I wonder what's going on.. the command there makes little sense | 17:42 |
| Pharaoh_Atem | zyga: without answers to these things, this is going to be very hard | 17:42 |
| niemeyer | 2.41 shows the same error | 17:42 |
| zyga | mm | 17:42 |
| sergiusens | niemeyer: can you point me to the full repo? | 17:43 |
| niemeyer | sergiusens: https://github.com/snapcore/spread/ | 17:43 |
| niemeyer | sergiusens: Woah | 17:50 |
| niemeyer | sergiusens: There's apparently a serious bug there.. It seems to be getting the local source instead of checking out the remote package | 17:51 |
| sergiusens | niemeyer: paste.ubuntu.com/p/DTK8DxVXZ6/ the problem is related the fact that source is implicit and defaults to "." (I have made it explicit in that diff). It is one of the things I wanted to bring up as a requirement with the move to bases. The next entry is since the source is not in a fully qualified import path,we need a way to know where it lives. If we removed the implicit source, your snapcraft.yaml will work collocated in there | 17:51 |
| niemeyer | sergiusens: This snapcraft.yaml worked... | 17:52 |
| niemeyer | sergiusens: Which means something changed in a breaking way | 17:52 |
| sergiusens | niemeyer: that implicit source has been there for over two years, so the only thing I can think of is that it was collocated with the source just recently | 17:52 |
| niemeyer | sergiusens: Well, maybe I'm just crazy then, and it has been doing something other than what I assumed since forever | 17:53 |
| niemeyer | Which is a real possibility | 17:53 |
| sergiusens | this is on my list of things to fix without breaking the older plugins for a while now | 17:53 |
| sergiusens | fwiw, I do not like this behavior of implicit source | 17:54 |
| niemeyer | sergiusens: I can see how it's nice when that's what you want, on something simple | 17:54 |
| niemeyer | sergiusens: But this particular case makes it error prone because we _seem_ to request a particular URL, but not really | 17:55 |
| sergiusens | niemeyer: but it leads to confusing things like this, we have also had the same comment from people using npm and yarn | 17:55 |
| niemeyer | Yeah | 17:56 |
| sergiusens | niemeyer: I'll write up a proposal on the forum for the behavior and send your way | 17:58 |
| niemeyer | sergiusens: Thanks! | 18:02 |
| zyga | success! spread works for me again | 18:08 |
| zyga | man, I need to figure out why now | 18:08 |
| niemeyer | zyga: You got it | 18:08 |
| niemeyer | spread, that is | 18:08 |
| niemeyer | pstolowski|afk: And you got a review for the patch sublevel PR, but you're rightfully out of here already | 18:09 |
| niemeyer | As should I be | 18:09 |
| niemeyer | In fact, here I go.. o/ | 18:10 |
| zyga | niemeyer: thank you! I'll give it a try after this run | 18:14 |
| zyga | niemeyer: I was trying to get locally built copy to work | 18:14 |
| zyga | mvo: hey, still around\ | 18:15 |
| zyga | mvo: I just wanted to comment about the extrausers topic | 18:16 |
| zyga | mvo: if you are around, I'd love to share that thought that I had during the standup | 18:16 |
| mispp | hey all, a question if i may. is it possible to define which g++ and which qt5 version is used when building snaps? | 18:18 |
| zyga | mispp: I believe that you can craft a makefile and define CC and CXX and just use that | 18:19 |
| zyga | mispp: snaps are not opinionated and snapcraft allows for a lot of flexibility | 18:19 |
| mispp | well, i can build snap on my own box with ubuntu 18.04, works perfectly | 18:19 |
| zyga | mispp: you just need enough of the dependencies to use that compiler | 18:20 |
| mispp | but now i'm trying to set up build.snapcraft.io | 18:20 |
| mispp | to pull directly from github | 18:20 |
| mispp | and it fails probalby because of the same reason why "snapcraft cleanbuild" fails - too old g++/qt5 | 18:20 |
| zyga | mispp: because on your 18.04 machine you are using your local tools for building; snapcraft builder uses a virtual machine or a container with ubuntu 16.04 there | 18:20 |
| zyga | mispp: as a simple answer you will be able to use core18 instead of core16 (aka core) to use the more recent toolchain | 18:21 |
| mispp | alright, googling | 18:22 |
| zyga | mispp: please try core18 instead, I personally haven't used snapcraft for building apps against core18 (I use hand-crafted tools because we are building things before the other tools are ready), | 18:22 |
| zyga | mispp: try just adding "base: core18" | 18:22 |
| zyga | mispp: I don't know if that is supported end-to-end | 18:22 |
| zyga | mispp: but that declaration conveys multiple things: that the application will run against a ubuntu 18.04-based runtime | 18:23 |
| zyga | and that the application should be _built_ against such environment as well | 18:23 |
| mispp | thanks for the concerns, but this is still development what i'm trying | 18:24 |
| mispp | so even if it doesnt work, no harm done | 18:24 |
| ogra | note though that nothing binds you to any ubuntu release thoug, you can craft a snapcraft.yaml that even builds a toolchain, compiler and Qt from soucre if you want | 18:25 |
| mispp | i'm not that skilled that i can pull this off, so i'd rather try core18 if it works | 18:25 |
| mispp | where can i find this in docu? | 18:26 |
| popey | ogra: nice! | 18:26 |
| ogra | (it surely is a lot effort and will massively increase build time, but snapcraft is flexible enough that you can build all bits you want to ship from source) | 18:26 |
| zyga | mispp: not sure, sorry, being on the front lines is not doesn't give me the right perspective | 18:27 |
| zyga | mispp: just put "base: core18" into your snapcraft yaml and build that | 18:28 |
| zyga | I'm going for a bike ride while it's not pitch black | 18:28 |
| zyga | bbl | 18:28 |
| mvo | zyga: I'm around | 18:29 |
| mup | PR snapd#5695 closed: osutil/sys: small tweaks to let it build on darwin <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5695> | 18:45 |
| mup | PR snapd#5698 opened: osutil: reorg and stub out things to get it building on darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/5698> | 18:46 |
| mispp | core18 doesnt work, still uses old toolchain | 18:54 |
| mispp | also ... error: cannot find app "goat" in "goat" | 19:06 |
| mispp | i guess apps part was missing | 19:09 |
| mup | PR snapd#5699 opened: overlord,store: support proxy settings internally too <Created by mvo5> <https://github.com/snapcore/snapd/pull/5699> | 19:28 |
| mispp | cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied | 19:30 |
| mispp | what's this about? | 19:30 |
| === kirkland is now known as Guest25977 | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | re | 20:28 |
| zyga | mispp: are you on 4.18? | 20:28 |
| zyga | mispp: I believe this is one of the bugs that is fixed in mainline / snapd 2.35 | 20:28 |
| === AdmWiggin is now known as tianon | ||
| === cjwatson_ is now known as cjwatson | ||
| kyrofa | zyga, snapd supports automatically starting snap apps on login, right? Do we have docs for that? | 22:10 |
| kyrofa | All I see is https://forum.snapcraft.io/t/how-to-autostart-a-snap-of-a-desktop-application/2449/33, which pretty much tells me nothing | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!