[01:20] oy slackers get https://github.com/mvo5/net/commit/0c0cd2628b36f2b053b7cc1ec04b76aab4c5189c upstream pls [01:20] or at least try [01:24] ah https://github.com/golang/go/issues/20556 === chihchun_afk is now known as chihchun [06:40] good morning [06:40] PR snapd#3638 opened: packaging: add current arch packaging [06:41] janisozaur1: https://github.com/snapcore/snapd/pull/3638 [06:41] PR snapd#3638: packaging: add current arch packaging [06:41] that's the current packaging [06:41] so there's a nice way to review changes later [06:41] I'll merge this as soon as I can [06:56] zyga-arch: o/ [06:56] hey [06:56] you have mail [06:56] s [06:56] even [06:56] but i'm not really here for an hour or so so no hurry :) [06:56] * zyga-arch looks [06:58] mwhudson: aha [06:59] mwhudson: thank you for pointing that out and finding it [07:00] mwhudson: I think that mvo may be on holidays still, if he's back we should pursue this === ikey|afk is now known as ikey [07:19] jamesh: hey [07:19] hi zyga-arch [07:20] jamesh, hey! :) [07:21] I replied to the thread with you and jdstrand [07:21] please have a look and if you want to discuss something quickly now, let's do it [07:21] zyga-arch: thanks. reading [07:21] hi pstolowski [07:22] zyga-arch: do you currently ever update the persistent namespaces rather than throwing them away to start over? [07:22] zyga-arch: nice, but I see some unrelated(?) test failed on travis? [07:23] jamesh: we update them when the fstab file (content interface and parts of layouts) change [07:24] jamesh: we have a very serious bug where we don't update them on base snap change that I cannot fix because it breaks apparmor and we'd have to unconfine snap-confine [07:24] jamesh: and I also forgot to meniton that snap-update-ns may need to get a new, specific, confinement for a *given snap* as it will process snap-specific mount profile [07:25] otherwise it must be unconfined to do that [07:25] janisozaur1: yes, master is very unhappy lately [07:25] janisozaur1: I ran into an issue where snap-seccomp needs to link libseccomp statically, I need to reverse that for arch [07:25] zyga-arch: but does "update" mean changing the existing namespace in use by running processes, or only making sure new processes see the changes? [07:25] yes [07:25] we change it live [07:26] existing processes see this [07:26] the "easy" solution was nacked as this fractured the view [07:26] that is essentially what snap-update-ns does [07:29] jamesh: the invalidation of base snap includes snap-confine figuring out that the base snap is not the same device anymore, using the freezer cgroup to see if any process uses the namespace and discarding/rebuilding it [07:29] jamesh: one more complexity is that snap-confine/snap-update-ns must work from within the constructed namespace and this brings in extra complexity (mainly around bugs in apparmor) [07:30] where naive setns() to pid 1 breaks everything [07:31] ah. I'd been concentrating on snap-confine and missed snap-update-ns [07:31] there's a small PR that starts this already... [07:32] https://github.com/snapcore/snapd/pull/3621 [07:32] PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [07:32] please have a look [07:32] jamesh: oh, and also reexec and base snaps adds more complexity (obviously) [07:32] because snap-confine needs to run snap-update-ns [07:32] but the base snap may not even have a normal FHS [07:33] reexec certainly adds some level of problems where we need to ensure tools use a consistent set of executables [07:33] and not a mix of the two [07:33] "reexec" only conceptually, really it is "using binaries from core snap" [07:36] jamesh: I'll grab something for breakfast, please tell me what you think, I'll be readin [07:38] zyga-arch: sure. I'm replying to your email with a description of what I need. [07:56] zyga-arch: okay. Replied with some details of how xdg-document-portal works [07:57] jamesh: wait, so this is /run/user/$UID/doc? [07:58] jamesh: so... we need nothing? [07:58] run is mounted as a slave of the host /run [07:58] so if you mount /run/whatever on the host this automatically works in the snap [07:59] no user-specific mount namespaces necessary [07:59] just make sure this is mounted on from the session and not from the snap (since it is a slave of the peer group) [07:59] does that make sense or am I prematurely enthusiastic? [08:01] zyga-arch: it is a different bind mount per package [08:01] per-package? [08:01] yes [08:01] read on a bit further :) [08:01] ok [08:02] the daemon produces per-package subdirectories inside the fuse file system that get mounted at /run/user/$UID/doc [08:02] aha [08:03] so we're back to square one [08:03] presumably because a fuse daemon doesn't know what pid originates each request, and/or the kernel may cache inode information between requests [08:04] are you familiar with bubblewrap and how flatpak uses it? [08:04] what's the mount namespace story there? [08:04] it builds a new namespace for each instance of the app [08:04] jamesh: so snapd 2.0.2 story [08:04] it doesn't try to share or update existing namespaces [08:05] jamesh: how does it access process specific namespace? just via /proc/$PID/ns/mnt? [08:05] (at least that's what I understood from reading it) [08:05] ohhh [08:05] and it's also FUSE [08:05] man [08:05] all the stars align to spell "oblivion" [08:06] rbind is just a set of recursively created bind mounts *at the time you call mount* [08:06] further changes are propagated using peer groups [08:06] so if I do a change in one process [08:06] and another process shares that peer group [08:06] and is a slave [08:07] it will see the change (things get mounted) [08:07] if a slave does a change the master won't see it [08:07] but does it break the master/slave relationship if the slave makes changes? [08:07] there are a few sharing modes (private, shared, slave, master, and one more I forgot) [08:07] no [08:07] slave can make changes that only it will see [08:08] so if you think about making changes to /run from within the snap namespace they won't propagate outwards [08:08] so if the process creates a new mount namespace as a slave rbind of the persistent namespace and then mounts the document portal over the top, things might work? [08:09] well, not sure, the sharing is per *mount point* [08:09] one sec [08:11] https://forum.snapcraft.io/t/feature-snap-layouts/1471 [08:11] there's a link to how peer groups function there [08:11] https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt [08:11] so assuming we still need the user mount namespace [08:12] and that it *probably* has to be persistent too [08:12] (for that users) [08:13] https://github.com/projectatomic/bubblewrap/blob/master/bubblewrap.c <- that's the bubblewrap code. It definitely isn't trying to share namespaces [08:13] we could do a bind mount from /run/user/doc/by-app (which is tricky if >1 app is in a snap) to /run/user/doc [08:13] zyga-suse: treat by-app as by-package [08:14] my proof of concept patches were doing permissions at the package level, since that seemed most sane [08:15] for flatpak, apps == packages so they are a bit loose with that terminology [08:17] right [08:17] but in our model one snap can ship two flatpaks really [08:18] hmm [08:21] right. I'm just saying that the "by-app" directory inside the document portal file system is effectively per-package [08:21] If you give one app from a snap access to a document, there isn't much to stop it giving another app from the same snap access [08:23] well, we can still use apparmor [08:23] ;-) [08:23] but yeahg [08:23] so, who does the bind mounting of all of that? [08:25] the portal runtime running in the session? [08:28] how many zyga's is too many [08:29] flatpak constructs a bubblewrap command line that says how to set up the sandbox [08:29] also 2.26.*14* ? oh dear [08:29] mwhudson: well, it's just cooperative multi tasking so it's not any better than one :D [08:29] one of the arguments tells bubblewrap to bind mount the document portal [08:29] mwhudson: *yes* [08:29] we found more bugs but mvo didn't want 15 [08:31] zyga-arch: i made a thing https://docs.google.com/spreadsheets/d/1ndk9eN5uSSY9A3SYzBRLBxOLMWw5--A2KNbS0v0y6_g/edit?usp=sharing [08:36] aha, looking [08:37] mwhudson: I requested write access to add some notes [08:39] zyga-ubuntu: granted [08:40] mwhudson: ok, comments made [08:40] I think the biggest thing is the net fork [08:41] the gettext package seems like a low hanging fruit [08:41] is that only used for a test? [08:41] as is the go-flags update [08:41] gettext? [08:41] the net fork [08:41] or net? [08:41] I don't recall, let me check [08:41] but my bet is not just tests [08:41] git grep mvo5/net/bdf [08:43] mwhudson: actually [08:43] it seems just for tests [08:43] ok good [08:43] so we could patch that away for now [08:43] yeah [08:43] (except on big-endian arches where it works by accident) [08:44] Chipaca: hey hey [08:44] zyga-ubuntu: hiya [08:45] zyga-ubuntu: looks like subunit-go is unused in 2.26.14 too? [08:45] I had a look at weather in London today [08:46] 16C vs 30+ here :/ [08:46] I miss London [08:46] mwhudson: I think we never used it [08:46] it may have been pulled in earlier by something else [08:46] but not directly via snapd tests [08:46] no matches in grep [08:47] oh i guess it could be a transitive dep [08:48] easy to find out [08:48] I think it is gone totally now, I grepped in the vendor tree as well [08:50] zyga-ubuntu: hnngh https://github.com/mvo5/libseccomp-golang is a fork too? [08:52] https://github.com/mvo5/libseccomp-golang/commits/master it seems so [08:52] not sure if we want to package the fork [08:52] or work with upstream [08:52] aha, mvo added support for older libseccomp [08:52] but not sure if this is even landable [08:53] I think it may refer to our special-cased patched 2.1.1 from ubuntu [08:53] https://github.com/mvo5/goconfigparser is not a fork but the debian package is of a version that is not tagged in the repo [08:53] (wehre it is more like 2.2) [08:53] mwhudson: I think for that we can use master or ask mvo for a release [08:53] is that even used though? [08:53] yeah i don't know if it's a problem, it's just making filling this sheet out less trivial :) [08:53] /partition/grub_test.go: "github.com/mvo5/goconfigparser" [08:53] partition/grub_test.go: cfg := goconfigparser.New() [08:54] just in tests? [08:54] feels bogus [08:54] I think it's a leftover [08:54] and the test can be patched away [08:54] we moved to something else in the tree now [08:55] I think this became "partition/grubenv" [08:55] well, maybe, not sure [09:17] sigh [09:18] an hour and a bit wasted because 17.10 was using wayland behind my back [09:18] Chipaca: it was one hour in the future [09:18] pedronis: hey, welcome back :-) [09:23] Chipaca: oh? what broke? [09:27] Chipaca: could you please do a review of https://github.com/snapcore/snapd/pull/3636 [09:27] PR snapd#3636: snap: add support for parsing snap layout section [09:27] PR snapd#3637 closed: interfaces/unity7: allow receiving media key events in (at least) gnome-shell [09:30] zyga-ubuntu: if you ssh -X into a thing that's running wayland, gtk apps start in the wayland session [09:32] * zyga-ubuntu posted https://forum.snapcraft.io/t/slow-core-downloads-breaks-tests/1521/1 [09:32] Chipaca: and? [09:32] Chipaca: about that cache thing you mentioned [09:32] Chipaca: you'd be interested, I suspect [09:35] zyga-ubuntu: in general for the deps where snapd is way behind debian should i just propose PRs that update the snapd version? [09:35] and let CI decide if it works [09:35] mwhudson: I'd say yes [09:35] mwhudson: but one by one so that we can evaluate where it breaks [09:35] heh yes [09:35] thanks [09:35] i'm not that daft :) [09:41] mwhudson: :) [10:24] PR snapd#3638 closed: packaging: add current arch packaging [10:29] wow [10:29] Chipaca: not quantitative, but this feels way faster [10:30] hm? [10:30] you mean the Arch packaging? [10:30] it's deliberately designed to not be able to do a lot [10:31] it's derived from how we do things in RPM, but drastically simplified [10:31] Son_Goku: no, I was talking to Chipaca in private about this https://forum.snapcraft.io/t/slow-core-downloads-breaks-tests/1521/2 [10:31] Son_Goku: a small optimization with huge wins for testing [10:31] Son_Goku: pre-cache heavy snaps we download [10:31] no coding required [10:31] duh? [10:31] why weren't we doing that before? [10:31] Son_Goku: ¯\_(ツ)_/¯ [10:31] effort != 0 [10:31] ;) [10:32] I thought we were already doing that [10:32] and nobody cared before [10:32] sure, easy to say "duh" after the fact [10:32] :-D [10:32] now when it takes one failure out of a 1000 tests to break the run [10:32] Chipaca: there's thing thing that I call base expectations [10:32] nobody expected base expectations [10:32] when we do not even do system updates before running the tests anymore, I expected we were caching the snaps [10:32] proper caching is still not there [10:32] but this is a huge win [10:34] test took 19 minutes [10:34] PR snapd#3639 opened: Update to version of golang.org/x/crypto currently in Debian unstable [10:35] I'll do some tweaks and do A/B [10:35] hm, does that mean that with this dep upgrade, snapd won't build on Fedora 25 anymore? [10:36] Debian sid is on Go 1.8, and Fedora 25 is only on 1.7 [10:37] Son_Goku: dep update? [10:37] [06:34:47 AM] PR snapd#3639 opened: Update to version of golang.org/x/crypto currently in Debian unstable [10:37] PR snapd#3639: Update to version of golang.org/x/crypto currently in Debian unstable [10:37] ah [10:37] good question [10:42] Son_Goku: i don't think so, this is only the crypto bits, they should still support 1.7 [10:43] zyga-ubuntu: i have code i can push [10:43] actually, let me run all the unit tests first :-D [10:43] * Chipaca _thinks_ he's covered all the angles, but [10:43] PR snapcraft#1434 opened: lxd: clean with no parts should only delete [10:44] basically: if the snap has a known size, and it's equal to the resume, then skip the download; and if it has a non-empty hash, check the hash [10:44] those ifs should make it work with the tests as they stand (and they make some sort of sense) [10:44] * mwhudson zzzz [10:45] Chipaca: haha, easy prey :) [10:45] thank you for fixing it [10:45] Chipaca: will it rename .partial files that aren't "partial" too? [10:46] mwhudson: night night! thank you! [10:46] zyga-ubuntu: what does that mean? [10:48] Chipaca: if I naively "snap download core" [10:48] stick it as .partial in /var/lib/snapd/snaps/ [10:49] will it choke? [10:49] I mean, I don't mind chopping of the final byte [10:49] zyga-arch: yes, that's what the patch is for [10:49] excellent [10:49] zyga-arch: no need to even talk to the server if we already have the whole thing [10:49] and, unit tests pass [10:50] if you have a pr i can push this to it [10:50] or [10:50] we can do it backwards [10:50] maybe easier to do it backwards :-) [10:52] backwards as in who goes first? [10:53] zyga-ubuntu: yes [10:53] zyga-ubuntu: https://github.com/snapcore/snapd/pull/3640 [10:53] PR snapd#3640: store: do not resume a download when we already have the whole thing [10:53] PR snapd#3640 opened: store: do not resume a download when we already have the whole thing [10:54] zyga-ubuntu: if you push your changes to that, everybody should be happy [10:54] Chipaca: understood [10:54] it changes the logic for downloading deltas a teeny bit [10:54] bit it shouldn't change things in practice [10:54] I'll review it in a moment [10:55] if the store says "no deltas", download begins, download is canceled, download is reattempted and the store says there are deltas, currently we don't resume; this makes the resume win [10:55] in practice it shouldn't make much difference except outside tests [10:55] i mean except inside tests :-) [10:55] anyway [10:56] time for me to take a break, run, and lunch [10:56] * Chipaca afk [10:59] ok, I will need ~45 minutes to finish the A/B timing tests [10:59] and in the meantime I can review [10:59] actually [10:59] scratch that [10:59] I can push my PR directly to see how long it takes [11:09] hrm ... travis ?? [11:15] Chipaca, are you still working on the shutdown stuff (unmounting /writable and /lib/modules failing) or is that on hold ? [11:15] PR snapd#3641 opened: tests: download core and ubuntu-core at most once [11:16] ogra: that's merged [11:16] ogra: loooong ago [11:16] zyga-ubuntu, where ? that never changed on any ubuntu core images i run [11:16] ogra: look at /usr/lib/snapd/ [11:16] there should be a shutdown executable there [11:16] there's a systemd job that puts it in the special place that systemd uses on shutdown [11:17] I think it runs all the time for ~6 months now [11:17] well, it didnt fix the bug obviously [11:17] oh? [11:17] Chipaca: ^ [11:17] [FAILED] Failed unmounting /lib/modules. [11:17] [ OK ] Unmounted /etc/sudoers.d. [11:17] [ OK ] Unmounted /run/snapd/ns. [11:17] [FAILED] Failed unmounting /writable. [11:17] i still see that all the time on every shutdown on every install [11:18] mmmmm [11:18] maybe something broke? [11:18] I wonder if we can get some logs from the tool [11:18] well, i never "not" saw it [11:18] I remember testing the thing in kvm [11:18] (i actually thought john is still working on it ) [11:23] i see the systemd job simply copies it to /run/initramfs/ [11:27] another faiure of FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune [11:39] * ogra pokes https://travis-ci.org/snapcore/core-build/builds/259703332 with a pointy stick in the eye ... [11:40] ogra: remember the abyss quote [11:44] mwhudson: haven't read all backscroll. it seems like getting snapd in Debian (properly?) depends on using non-embedded code copies? [11:44] jdstrand: yes, and we did de-vendorize everything [11:45] jdstrand: but now the problem is we have a few forks [11:45] jdstrand: and it's unclear if we should move the vendorized deps ahead when we do this in debian [11:46] PR snapd#3642 opened: cmd/snap: get keys or root document [11:52] that's interesting. we have asimilar policy in Ubuntu but was told do to time constraints to relax the requirement for snapd [11:52] due* [11:53] interesting the work is happening now [11:55] ogra: can you open a thread about that /writable bug? [11:56] jdstrand: it's only happening for debian [11:56] jdstrand: I think that in ubuntu it is not even considered [11:56] jdstrand: especially since it impacts testing value [11:56] jdstrand: and that we reexec anyway [11:57] well, if there weren't outside factors influencing what we are doing in Ubuntu I would imagine we wuld do it in Ubuntu [11:58] jdstrand: I think the key factor was OMG time [11:58] it seems like Debian picked up on Ubuntu's definition of how to support golang packages but are actually enforcing it [11:58] jdstrand: though we lack in debian/copyright heavily todayu [12:00] cachio,hey! have you found any pattern for reproducing hook errors from https://paste.ubuntu.com/25218225/ ? e.g. linode vs local qemu etc? [12:03] huh, i might've broken deltas (according to spread) [12:03] * Chipaca will fix after lunch [12:03] zyga-ubuntu: ogra: those [FAILED] are from systemd [12:04] zyga-ubuntu: ogra: our helper runs _after_ that; those failed are the reason we need the helper [12:05] jdstrand: jdstrand:policy-updates-xxvi [12:05] jdstrand: wow, roman numerals! [12:07] Chipaca: lots of refresh tests failed with your PR https://travis-ci.org/snapcore/snapd/builds/260146033?utm_source=github_status&utm_medium=notification [12:07] Chipaca, well, can we quieten them ? [12:13] zyga-ubuntu: yes, as i said, i seem to have broken deltas (or their tests) [12:14] ogra: sure! systemd is free software, right? [12:14] dunno, ask redhat :P [12:15] (surely open source though :) ) [12:15] nu-uh, they're on the other side of the river from me [12:29] zyga-ubuntu: yeah, rocking it old school. keeping it fun! :) [12:39] zyga-ubuntu: about your patch, unless i'm much mistaken the way you've done it won't work [12:39] zyga-ubuntu: that is: only the first test will find the .partial [12:39] zyga-ubuntu: you need to download them somewhere, and then at the start of each test copy them? or sth like that [12:40] Chipaca: isn't that exactly what is going on [12:40] otherwise, test downloads thing, tests its stuff, cleans up -> no more thing [12:40] this is doing in the "prepare the magic state tarball" stop [12:40] step* [12:40] and then it gets restored in each one [12:40] or maybe I misunderstood the restore logic [12:40] zyga-ubuntu: ah... if that's the case then it's ok :-) [12:40] Chipaca: but now that you said it, I'm not sure it is restored in each test [12:41] zyga-ubuntu: easy to test [12:41] TBH the spread setup is so wonky now someone could sit down and write a comprehensive document about it [12:41] Chipaca: how? [12:41] zyga-ubuntu: spread --shell yadda [12:41] mmm, let me try, thanks! [12:42] zyga-ubuntu: tweak spread.yaml to workers:1 [12:42] ah [12:42] good iea [12:42] ctrlc- [12:43] I think too late [12:43] 2017-08-02 14:43:04 Server (Spread-44) exceeds halt-timeout. Shutting it down... [12:43] pstolowski, I could reproduce it in qemu [12:43] interesting server! [12:45] Chipaca: on the up side, it's very refreshing to see green tests [12:45] cachio, every time? [12:45] yes [12:46] using branch [12:46] release/2.27 [12:46]