[01:33] <mup> Bug #1760252 changed: starting slack crashes xwayland on 18.04 <bionic> <xorg-server (Ubuntu):New> <https://launchpad.net/bugs/1760252>
[03:05] <mup> PR snapd#5690 opened: Add an error code for Polkit auth cancels <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/5690>
[05:09] <mborzecki> morning
[05:42] <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:50] <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:53] <mvo> mborzecki: yeah, missed that, looking. thank you
[05:53] <zyga> good morning!
[05:54]  * 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:57] <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:58] <mborzecki> feels good to be back at the proper screen
[06:24] <zyga> :-)
[06:25] <zyga> Yeah but I’m shifting
[06:26] <zyga> When I woke up today I felt like it’s autumn ready
[06:27] <zyga> Is it OK to say I already miss the summer?
[06:28] <zyga> My plan for today is to talk with Paweł about the system snap
[06:29] <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:30] <mborzecki> zyga: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/parallel-install-snap-namespace-mapping i'd love to hear your thoughts
[06:31] <mborzecki> zyga: also need to look info why /snap/foo is mounted rw
[06:32] <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:52] <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:53] <zyga> re
[06:54] <zyga> mborzecki: looking
[07:10] <pstolowski> mornings
[07:23] <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:24] <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:42] <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:43] <zyga> https://www.irccloud.com/pastebin/d39eugoc/
[07:44] <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:45] <zyga> mborzecki: it manifests itself as dangling symlinks and empty files in /etc
[07:46] <mborzecki> zyga: ok, removing files made it go away
[08:04] <mup> PR snapcraft#2220 opened: schema: allow license field <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2220>
[08:12] <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:13] <alexlarsson> zyga: I'm considering whether to add it to the bionic flatpak ppa
[08:24] <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:26] <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:27] <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:34] <mborzecki> zyga: parallel installs + layouts spread test running now
[08:35] <zyga> cool
[08:35] <alexlarsson> jamesh: cool
[08:44] <zyga> mborzecki: any luck?
[08:46] <mborzecki> zyga: heh, stopped at the trespassing thing, fixed the test to cleanup /etc/demo* stuff and retrying now
[08:47] <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:48] <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:49] <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:58] <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:59] <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
[09:02] <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:03] <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:04] <zyga> Chipaca: but yeah, cool stuff :)
[09:04] <zyga> and apparently it doesn't matter (marketshare :)
[09:04] <Chipaca> zyga: :-)
[09:11] <Chipaca> what does userd use SIGUSR1 for?
[09:11] <Chipaca> morphis: do you remember?
[09:15] <mup> PR core#93 opened: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93>
[09:23] <mborzecki> zyga: that's the test currently https://paste.ubuntu.com/p/KfNJC6tJV2/
[09:25] <zyga> mborzecki: looking
[09:26] <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:27] <zyga> mmm, I don't see that
[09:27] <mborzecki> zyga: lines 85+, unless you have something else in mind
[09:28] <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:29] <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] <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:31] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <mvo> zyga: https://paste.ubuntu.com/p/XkFW7hYYTX/
[09:40] <zyga> ID=ubuntu-core
[09:41] <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:42] <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:43] <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:44] <mup> PR snapd#5683 opened: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683>
[10:04] <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:05] <mborzecki> need to go to the car shop, will work from there, bbiab
[10:05] <zyga> kk
[10:06] <zyga> mvo: you can also get a trace with SNAP_CONFINE_DEBUG=yes
[10:07] <zyga> perhaps that will shed some light as to what is going on
[10:08] <mvo> zyga: ok
[10:08] <zyga> mvo: if you pastebin that I will gladly look
[10:09] <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:10] <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:11] <mvo> zyga: https://paste.ubuntu.com/p/26bb6N4mVQ/
[10:12] <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:15] <mvo> zyga: https://paste.ubuntu.com/p/FtqGCYzTnT/ <- with SNAPD_DEBUG=1
[10:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38]  * Chipaca tries
[10:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <mwhudson> er no it doesn't
[10:45] <mwhudson> that's what i was saying above
[10:46] <mvo> mwhudson: hm, hm, thats unfortunate
[10:46] <ogra> just make people stop using that ancient classic thing ;) core for everyone !
[10:47] <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:48] <mvo> mwhudson: I was just looking at 1.10
[10:48] <mvo> mwhudson: but then we still build with 1.6 :(
[10:49] <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:50] <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:51] <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:54] <mwhudson> aah ok you can call golang.org/x/net/httpproxy.FromEnvironment() to make a new thing from the current environment
[10:56] <mwhudson> (thanks to rog, it seems0
[10:56] <mwhudson> )
[10:58] <mvo> mwhudson: this will work in 1.6?
[10:58] <mwhudson> mvo: no idea
[10:58] <mwhudson> mvo: suspect not :/
[10:59] <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
[11:00] <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:01]  * mwhudson reaches for his boostraps only to find he's already standing on them
[11:03] <mwhudson> mvo: something about the current setup certainly smells bad
[11:03] <mwhudson> mvo: something something prepare-image classic something
[11:04] <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:05] <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:06] <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:07] <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:08] <mwhudson> and then you can use the go snap to build snapd :)
[11:08] <mvo> mwhudson: \\o//
[11:09] <mvo> mwhudson: I will think about this over lunch
[11:10] <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:11] <Chipaca> without reading all the backlog :-)
[11:11] <Chipaca> i can confirm proxy.store works on classic
[11:12]  * 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:13] <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:17] <ogra> jdstrand, already around ?
[11:31] <Chipaca> mborzecki: which was the pr you asked me to review?
[11:34] <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:40] <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:41] <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:42] <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:43] <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:45] <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:51] <pedronis> mborzecki: an approach would be some kind of global flag we set in tests
[11:52] <mborzecki> pedronis: right, that would work, i saw some test only flags/ifs inside the code, so the precedent is set
[11:54] <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:55] <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:56] <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:57] <zyga> mborzecki: yeah, that's the (existing) bug I mentioned
[11:57] <mborzecki> mhm
[11:58] <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:59] <zyga> yeah, a lot of the preceding helpers landed but the "meat" did not
[11:59] <mborzecki> sounds familiar :)
[12:05] <pedronis> mvo: I saw you updated the roadmap, there is still some mistyped "topic"   in the 2.34 bits
[12:12] <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:13] <zyga> yeah, +1
[12:13] <zyga> odd - we had that before
[12:13] <zyga> must have been lost in some PR
[12:14] <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:15] <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:16] <ogra> Facu, better start a forum thread ... (see channel topic)
[12:18] <Facu> ogra, ack, thanks
[12:29] <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:30] <zyga> mvo: any luck?
[12:31] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <Gargoyle> zyga: https://paste.ubuntu.com/p/z6xX3vwGKT/
[12:41] <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:42] <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:44] <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:46]  * zyga goes and fixes garbage in that PR
[12:48] <zyga> brb
[12:49] <mvo> zyga: cool, I will base my PR on yours then
[12:51] <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:58] <Gargoyle> brb, reboot (reverting to 4.15)
[13:00] <morphis> Chipaca: hm, let me have a look
[13:01] <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:02] <zyga> Gargoyle: ack
[13:02] <zyga> mvo: ack
[13:06] <mborzecki> store hiccup?
[13:23] <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:24] <zyga> mvo: do you know more about the details of the core18 mount issue that cachio mentioned?
[13:27] <sergiusens> Chipaca: does the latest snapd in beta now default to setting the snaps in /var/lib/snapd/snaps to 600?
[13:28] <Chipaca> sergiusens: yes
[13:28] <sergiusens> Chipaca: this unfortunately breaks snap install snapcraft ....; mkdir project; cd project; snapcraft init; /snap/bin/snapcraft cleanbuild
[13:29] <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:30] <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:31] <popey> i too have been burned this morning by this
[13:33] <popey> should I refresh core to stable, or something else?
[13:34] <Chipaca> sergiusens: ~5 :-)
[13:34] <sergiusens> Chipaca: my only installed browser and code editor are from snaps :-)
[13:35] <popey> every application i have open is a snap
[13:37] <Chipaca> sergiusens: popey: you're awesome
[13:44] <jdstrand> zyga (cc mvo and Gargoyle): it was a kernel *fix*
[13:44] <zyga> jdstrand: I see, is it upstream now?
[13:45] <jdstrand> Gargoyle: if you update to snapd 2.35, it will work
[13:45] <Gargoyle> ahh. OK. Thanks.
[13:46] <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:47] <zyga> ok
[13:47] <jdstrand> https://forum.snapcraft.io/t/snaps-are-not-working-with-linux-kernel-v4-18-rc/6708/3
[13:55] <mborzecki> going to pick up the car, bbl
[14:15] <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:32] <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:35] <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:36] <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:37] <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:38] <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:39] <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:43] <Chipaca> sergiusens: so, a proposal
[14:44] <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:45] <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:46] <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:48] <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:49] <Chipaca> ah, found the code
[14:50] <sergiusens> Chipaca: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L345
[14:53] <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:54] <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:56] <sergiusens> Chipaca: for the new code
[14:57] <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:58] <mborzecki> Chipaca: we probably don't
[14:59] <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>
[15:00] <sergiusens> Chipaca: it does not, I can point release that in the future
[15:01] <cachio> mvo, should I run sru for 2.35 after beta validation?
[15:02] <Chipaca> mvo: note sergiusens says we might want to hold off on 2.35 until snapcraft is ready for it
[15:03] <Chipaca> sergiusens: getting back to containerbuild, why would using sudo suck that much?
[15:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:56] <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>
[16:01] <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:02] <pedronis> mborzecki: thanks, I will look at it tomorrow
[16:02] <mborzecki> pedronis: great, thank you!
[16:15] <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:31] <zyga> niemeyer: hey, could you please refresh spread the snap to the current release please?
[16:32] <Chipaca> niemeyer: i'm missing something wrt patch sublevels i'm afraid
[16:33] <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:38] <ogra> whee !
[16:38] <ogra> i actually managed to get my wmx gui session into a confined state !
[16:39] <pedronis> Chipaca: we need a breaking patch to introduce them? :/
[16:40] <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:41] <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:42] <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:43] <ogra> lol ... i love the kill -9 in green :)
[16:58] <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)
[17:06] <mvo> Chipaca: hey, disconnected, sorry. did you get my earlier message
[17:07] <Chipaca> mvo: I got it but I hadn't seen it
[17:07] <Chipaca> mvo: looking now
[17:09] <mvo> Chipaca: thanks, no worris
[17:10] <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:26] <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:27] <niemeyer> chihchun_afk: Sorry.. wrong nick
[17:28] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <sergiusens> niemeyer: can you point me to the full repo?
[17:43] <niemeyer> sergiusens: https://github.com/snapcore/spread/
[17:50] <niemeyer> sergiusens: Woah
[17:51] <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:52] <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:53] <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:54] <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:55] <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:56] <niemeyer> Yeah
[17:58] <sergiusens> niemeyer: I'll write up a proposal on the forum for the behavior and send your way
[18:02] <niemeyer> sergiusens: Thanks!
[18:08] <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:09] <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:10] <niemeyer> In fact, here I go.. o/
[18:14] <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:15] <zyga> mvo: hey, still around\
[18:16] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <zyga> mispp: not sure, sorry, being on the front lines is not doesn't give me the right perspective
[18:28] <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:29] <mvo> zyga: I'm around
[18:45] <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:46] <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:54] <mispp> core18 doesnt work, still uses old toolchain
[19:06] <mispp> also ... error: cannot find app "goat" in "goat"
[19:09] <mispp> i guess apps part was missing
[19:28] <mup> PR snapd#5699 opened: overlord,store: support proxy settings internally too <Created by mvo5> <https://github.com/snapcore/snapd/pull/5699>
[19:30] <mispp> cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
[19:30] <mispp> what's this about?
[20:28] <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
[22:10] <kyrofa> zyga, snapd supports automatically starting snap apps on login, right? Do we have docs for that?
[22:11] <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