[00:30] anybody around to help me troubleshoot a snap? [00:48] Bug #1623279 opened: [Errno 2] No such file or directory: '/home/robru/src/bileto.snap/stage/usr/share/locale/ku' === mup_ is now known as mup [02:25] PR snapcraft#793 closed: Unify python plugin [02:49] PR snapcraft#794 closed: Improve lifecycle execution of steps [05:52] PR snapcraft#797 opened: Use --dangerous when installing snaps in yakkety [06:12] PR snapd#1902 opened: tests: add new SNAP_IGNORE_SUDO_USER and set it for the spread tests [06:13] mvo: oh, you closed that already [06:13] mvo: quick question about qemu/spread, can we just use su instead? [06:13] zyga: yeah, currently thinking about fixing it directly in spread [06:13] zyga: sure, fire [06:13] mvo: so that linode and qemu behave the same way [06:14] PR snapd#1902 closed: tests: add new SNAP_IGNORE_SUDO_USER and set it for the spread tests [06:14] zyga: qemu and linode should behave the same, its just adhoc that is different [06:14] ah, I see [06:15] how are we using adhoc today? [06:15] zyga: inside the autopkgtest, its running the tests against localhost basicly [06:17] ah, I see [06:19] mvo: offtopic, do you know how can I get a yakkety image for the qemu backend easily? [06:21] zyga: yes [06:21] zyga: sudo apt install autopkgtest/xenial-backports [06:21] zyga: and adt-buildvm-ubuntu-cloud -r yakkety [06:21] ah, thanks [06:25] yw [06:45] hey hey [07:09] * zyga zeros on the test breaks the remainder of the testing cycle [07:40] PR snapd#1903 opened: tests: ensure SUDO_{USER,GID} is unset in the spread tests [07:41] PR snapd#1904 opened: tests: add debug out put to ubuntu-core-update-rollback-stresstest: [07:58] PR snapcraft#796 closed: Only discover dependencies once per file [08:12] PR snapd#1905 opened: snap: (re)add --force-dangerous compat option [08:17] PR snapd#1903 closed: tests: ensure SUDO_{USER,GID} is unset in the spread tests [08:28] PR snapd#1906 opened: CONTRIBUTING.md: remove integration-tests, include spread [08:46] mvo, ok... expired key error fixed ... what a silly thing [08:48] mvo, do we know how long assetrtion keys are actually valid, this could really bite us for released images given that fixrtc sets the clock to the image creation date while it can not sync to a timeserver [08:48] if the expiration time is to shart they key might be expired [08:48] *short [08:55] PR snapd#1907 opened: asserts: basic support for validation assertion [08:56] PR snapd#1905 closed: snap: (re)add --force-dangerous compat option [09:05] mwhudson, FYI, i just invalidated Bug #1623119 [09:05] Bug #1623119: wlan setup done by console-conf not persistent [09:06] Bug #1623119 changed: wlan setup done by console-conf not persistent [09:09] ogra_: ok, although i think the snapd behaviour is a bit unhelpful too [09:10] well, i dont think the job runs if it finished successfully [09:10] ogra_: https://github.com/snapcore/snapd/pull/1901 [09:10] PR snapd#1901: firstboot: do not overwrite any existing netplan config [09:10] ogra_: true, will leave it to mvo to decide :-) [09:11] but your fix at least looks like a good safety net [09:12] ogra_: wow https://bugs.launchpad.net/snappy/+bug/1623125 looks like heaps of fun [09:12] Bug #1623125: fixrtc script does not catch "Last mount time: n/a" string

[09:12] * zyga finally figured out what is going on with snap-confine [09:13] mwhudson, yeah, who would have thought that the ext4 devs put some useful thing in that field one day :P [09:14] it used to be the epoch or empty in the past ... the script deals with both ... just not with a funny string [09:15] fun fact "n/a" translates to Feb 11 (no idea which year) if handed to that date command call :) [09:16] PR snapd#1908 opened: tests/lib/prepare.sh: test that classic does not setting bootvars [09:17] BOOO ! [09:18] console-conf doesnt see my wlan device on the pi3 ! [09:20] yeah, even after a reboot ... :( [09:27] mvo, hmm, this is an interesting one: http://paste.ubuntu.com/23177205/ ... i'm greeted with a reboot message on first login ... there were no updates though [09:28] PR snapd#1748 closed: asserts: basic support for validation assertion [09:28] PR snapcraft#798 opened: Replace uses of copy with dump [09:44] PR snapd#1837 closed: asserts: add refresh-control header to snap-declaration assertion [09:50] PR snapd#1909 opened: snap: fix SNAP* environment merging in `snap run` [09:51] hmpf [09:51] and this time i'm dropped into console-conf after reboot even though the system was already configured fine [09:51] lol ... and now i get wlan config as an option [09:52] wow this is buggy [09:53] oh man [09:53] and console-conf wants to re-create the already existing user ... no way to skip the user part [09:53] ogra_: iz fine, just add me to your machine ,) [09:53] haha [09:54] error: bad user result: cannot create user "ogra@ubuntu.com": Get [09:54] https://login.ubuntu.com/api/v2/keys/ogra%40ubuntu.com: dial tcp: lookup [09:54] login.ubuntu.com: no such host [09:54] oh, lovely [09:54] and even though console-conf told me it configured the wlan it seems it didnt [09:55] ok, so i get a console-conf on second boot and cant get out of it anymore [09:56] heh [09:57] and i can log in with the user creasted at the former boot [10:00] seems console-conf really doesnt get along with two interfaces [10:00] PR snapd#1910 opened: spread.yaml: don't assume LANG is set [10:02] now the network config constantly times out ... it seems to try to use the wired NIC even though that was set to "dont use" [10:05] ok, switching back to wired and completely turning off wlan now gets me to [10:05] error: bad user result: cannot create user ogra: adduser failed with [10:05] exit status 1: adduser: The user `ogra' already exists. [10:05] and no way to ever get out of it again [10:05] cancel just gets me back to the start page of console-conf [10:06] crazyly broken [10:07] * ogra_ takes a break to go crying in a corner === oSoMoN_ is now known as oSoMoN [10:21] PR snapd#1900 closed: interfaces: miscellaneous policy updates for default, browser-support and camera [10:25] PR snapd#1897 closed: snap: run all tests with gpg2 [10:25] PR snapd#1907 closed: asserts: basic support for validation assertion and refresh-control [10:32] PR snapd#1911 opened: snap: add additional checks for snap run symlinks [10:38] woooot [10:38] \\o [10:38] o// [10:38] \o/ [10:38] PR snapd#1908 closed: tests/lib/prepare.sh: test that classic does not setting bootvars [11:03] mvo, is there any reason for which a devmode snap would get ECONNREFUSED when trying to connect to a UNIX socket? [11:06] How would one snap an application which has both python requirements.txt, but is also a node app? have two parts referencing the same source, one python2 plugin, one nodejs plugin? [11:08] PR snapd#1904 closed: tests: add debug out put to ubuntu-core-update-rollback-stresstest: [11:09] mvo: https://github.com/snapcore/snap-confine/pull/141/files [11:09] PR snap-confine#141: Ensure that parent is alive after installing PR_SET_PDEATHSIG [11:09] mvo: I fixed ns-sharing to work in spread now, I'll propose a few separate fixes for review [11:09] mvo: this is the first one, feedback welcome1 [11:10] jdstrand, tyhicks: ^^ [11:10] PR snapd#1901 closed: firstboot: do not overwrite any existing netplan config [11:12] PR snapd#1891 closed: doscs: add create-user documentation [11:12] PR snapd#1896 closed: cmd/snap: match UX document for message when buying without login [11:21] https://github.com/snapcore/snap-confine/pull/142 [11:21] PR snap-confine#142: Add sanity timeouts [11:28] https://github.com/snapcore/snap-confine/pull/143 [11:28] PR snap-confine#143: Don't assume /run/snapd/ns can be removed [11:29] https://github.com/snapcore/snap-confine/pull/144 [11:29] PR snap-confine#144: Ensure that snap-confine is dead after each test terminates [11:31] tyhicks, jdstrand: around? :) [11:37] spread-in-qemu and local http proxy saved me 7GB of traffic over the last 24 hours :) [11:48] PR snapd#1912 opened: cmd/snap: do runtime linting of descriptions [12:12] mvo, ugh ... [12:13] mvo, just testing your re-compressed pi3 image here ... [12:13] mvo, did you actually only re-compress it or is this a complete new ubuntu-image build ? [12:15] mvo, regardless ... it seems broken [12:23] zyga: hi! [12:27] jdstrand: hey [12:27] jdstrand: I managed to get ns-sharing to work on in spread now [12:27] jdstrand: I posted some patches [12:27] nice! [12:28] I tried to respond to one of them when I was out. curous what github did with it :) [12:28] curious even [12:29] jdstrand: it did the right thing [12:29] jdstrand: I saw that reply, github is pretty good at this stuff [12:30] jdstrand: this is the essential one: https://github.com/snapcore/snap-confine/pull/141 [12:30] PR snap-confine#141: Ensure that parent is alive after installing PR_SET_PDEATHSIG [12:30] jdstrand: if this lands I can propose the real thing and it should be green [12:30] jdstrand: debugging this I also implemented https://github.com/snapcore/snap-confine/pull/142 [12:30] PR snap-confine#142: Add sanity timeouts [12:31] jdstrand: though I don't believe the use of this patch (and a separate tiny patch that puts it arounf flock() is really required [12:31] jdstrand: still it is a 'death man hand' kind of failsafe [12:34] jdstrand: I added qemu spread support so if you have recent spread (not installed as a snap) this makes testing far better [12:43] cprov, the publishing bug in the store doesnt seem to actually be related to a long revision history, i did re-builds of pi2-kernel and dragonboard-kernel yesterday which both have only seen a few revisions yet (pi2 is at 14, dragonboard at 9) ... and had to do the unpublish/publish dance to make them seen [12:44] ogra_: you are right, the problem is on the snap-release endpoint itself [12:44] ah, so already known by you ? then its fine ... [12:44] * ogra_ just wanted to report the new data point [12:44] ogra_: the fix is on its way, I've literally just isolated it [12:45] PR snapd#1899 closed: store: don't discard error body from request device session call [12:45] i just had not seen it on other packages before ... [12:45] ogra_: thanks for adding more info on this (what a nightmare bug!) [12:45] heh, yeah [12:46] PR snapd#1906 closed: CONTRIBUTING.md: remove integration-tests, include spread [12:49] * ogra_ points mvo to his ping from 30min ago ... [12:49] jdstrand: can I merge 141 [12:50] * ogra_ feels ignored today :( [12:50] ogra_: o/ [12:50] :D [12:50] zyga: it's funny that I read 141 before your alarm branch and I came to the same conclusion :) [12:51] jdstrand: :-) there is some nice tricky code around [12:51] zyga: so, if you are going to do the alarm, what is the benefit of doing the pid check since it is slightly flawed? [12:52] ie, why isn't the alarm check enough? [12:52] jdstrand: it's an early warning system where the parent just dies right away, the timeout is 3 seconds [12:52] ogra_: broken it what way? [12:52] ogra_: its a new build but its still based on the same beta images [12:52] jdstrand: it's not *so* flawed, AFAIR the pid namespace would have to overflow before the kernel would recycle process IDs [12:52] mvo, did you re-build it from scratch using a newer ubuntu-image ? [12:52] ogra_: beta channel content [12:52] jdstrand: so the check is immediate and good enough [12:53] (as in, not broken totally, but not sufficient( [12:53] zyga: I guess there is no harm if the pid is reused. that process won't send the signal and then the alarm will hit [12:53] ogra_: its a fresh build [12:53] jdstrand: I wonder if there's a way to avoid that altogether with a pipe, after all, we'd get EPIPE on the read instantly [12:53] mvo, right, but you used the new ubuntu-image for it ... so the rootfs doesnt get loop mounted and has now the same fixrtc bug that i fixed tonight [12:53] jdstrand: (and eventfd had one task, make the use of the pipe obsolete, eh :-( [12:54] pipe goes back farther too.. [12:54] ogra_: oh, I see, hm, hm. what is the fix? a new initramfs-tools in the beta channel? [12:54] mvo, either you re-build using an ubuntu-image from before the mtools fix landed or we promote the new kernel to beta and do a re-build ... the current image on cdimage will fall over [12:54] zyga, could you please take a look at https://github.com/snapcore/snapd/pull/1640 when you have a minute? it seems that i'm approaching gsettings interface testing the wrong way [12:54] PR snapd#1640: tests: add gsettings interface spread test [12:54] fgimenez: I saw that but I didn't reply yet, I'll make sure to reply today [12:54] mvo, right, new initrd is in all the kernel snaps in edge already ... since thats the only change i think we can just promote them [12:54] ogra_: lets do a new image with a new kernel then and we also reduce the image size [12:54] zyga, cool thanks! :) [12:55] zyga: I don't think you need to move to pipe, at least not for this and not today. I'll comment in the PR [12:55] ogra_: yeah, lets do it, could you please delete the pi3 image from nusakan and trigger the mirror sync? [12:55] doing so [12:56] done [12:58] mvo, both kernels published to beta [12:58] zyga: commented === chihchun is now known as chihchun_afk [13:00] jdstrand: thank you, will do [13:04] PR snapcraft#799 opened: Load project information in one location [13:11] ahoy ahoy [13:13] I am currently wondering how, if at all, one would share compiled artifacts across snaps at build time. example of the day: we make a kde-frameworks content snap, we'd then want to build an app using that snap. the problem is at build time we'd have to have access to the content to use headers and libraries. [13:22] zyga: kyrofa ^^ can you help sitter please? [13:29] * zyga looks [13:29] sitter: hey [13:29] sergiusens: do you have an ETA for snapcraft 2.17 in Xenial? [13:29] sitter: I believe sergiusens has an idea about this, he was working on the design [13:29] (morning btw) [13:33] zyga: could sitter push his compiled artifacts to a ppa/repo and just pull that in as a build-package in snaps? [13:33] as an interim [13:34] popey: there are many ideas that are possible, sergiusens spent a lot of time on the design of this (as it affects snapcraft) and I believe he's the right person to talk to [13:35] okay [13:44] jdstrand: this is the key branch, if this lands I'll be supper happy: https://github.com/snapcore/snap-confine/pull/145 [13:44] PR snap-confine#145: Enable snap-confine namespace sharing [13:49] PR snapcraft#800 opened: LP: #1623509 fix to install of deps in package.json [13:50] Bug #1574851 changed: libgl not found on nvidia machines (so far)

[14:00] popey: zyga: are build-packages copied into stage and prime directories? [14:00] if not, then that is a solution [14:00] mhall119: stage-packages are copied, build-packages are just installed on the host AFAIR [14:01] indeed [14:01] sitter: ^^ would that work for you? [14:02] basically include your -dev packages from the archives or PPA in build-packages in your snapcraft.yaml, that way your application's build-time process can see them, but they won't put anything into your snap [14:04] mhall119, zyga: thanks that could work [14:04] I'll give it a stab tomorrow [14:10] jdstrand: refreshed https://github.com/snapcore/snap-confine/pull/142 [14:10] PR snap-confine#142: Add sanity timeouts [14:10] jdstrand: if it goes green let's land and use it :) [14:12] zyga: fyi, I've started looking at 145. I really want to tear it apart though and I have an appoint in 30 minutes, but I will be looking at this with top priority after that [14:13] jdstrand: I need to leave in an hour [14:13] jdstrand: if you can tighten the profile that would help me a lot [14:14] jdstrand: I can propose a small branch on top of the sanity timeout branch that actually uses it in three places [14:14] jdstrand: then I think we are good to seriously consider landing 145 [14:14] jdstrand: I'll be back in the evening (~5 hours from now) so I think we can still sync today [14:15] zyga: in my tear-apart I'll look at the profile [14:15] jdstrand: thank you [14:15] jdstrand: as an extra thing to think about, what about cgroups (nothing tests that today) [14:16] jdstrand: I'll add a pile of spread tests before this is relased but I didn't want to clutter the pull request with them [14:16] zyga: I added spread tests for that some time ago? did you mean something else? [14:16] jdstrand: I mean spread tests for ns sharing specifically [14:16] jdstrand: I have one simple test and I have some more in the works (e.g. a stress test that runs lots of concurrent copies of snap confine and checks that they all finish with the same NS identifier [14:17] I'm sorry, I'm having a hard time changing gears [14:17] jdstrand: hmm? [14:17] what is the interaction with cgroups you are concerned about? [14:17] because the sysfs is mounted in there? [14:18] hey guys, i'm having issues doing a "snap login" without sudo (snapd from edge, running on xenial) [14:18] jdstrand: I don't really know but my point is that there's little testing for ns sharing *and* cgroup usage, which is not default [14:18] jdstrand: e.g. one process has a cgroup and another doesn't but they share the ns, does the order in which they start matter? [14:19] I see. I'll take a look at that too [14:29] sitter, zyga mhall119 indeed, I believe sergiusens's plan is to provide a way to make a "-dev" snap that can be used to build against [14:29] kyrofa: so i was reading up on [14:29] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1586465 [14:29] Bug #1586465: Add support for hooks [14:30] kyrofa: do you consider that "done" enough that in next release u8 app folk could attempt to use for their own hooks? [14:33] Hey kgunn! [14:34] Yeah, the machinery is all there, add away! [14:34] kgunn, that's what I'm working on at the moment, too [14:34] kyrofa: that==? [14:34] Finally adding a hook [14:34] actually trying to use? [14:35] ah noice! [14:39] kgunn, I'll see if I can add some documentation about adding hooks [14:39] tedg: ^ [14:40] thanks kyrofa [14:40] Good to know there's interest [14:41] Cool, docs would be great. [14:49] jdstrand: is there a bug report tracking the refresh-while-running problem? [14:54] PR snapd#1913 opened: daemon,store: move store login user logic to store [14:55] kgunn, tedg: pstolowski has been learning that as well [14:57] kyrofa: Snapcraft support? I don't see anything in the snapcraft.yaml schema: https://github.com/snapcore/snapcraft/blob/master/schema/snapcraft.yaml [14:57] tedg, yeah that's missing at the moment. Probably my next task [14:58] tedg, but it's not too bad to get working without [14:59] kyrofa: Sure without docs is harder than without snapcraft support ;-) [15:00] tedg, yeah I'll make a PR with the spec as well as a tutorial today [15:00] kyrofa: Great, thanks! [15:00] Thanks for asking! [15:02] PR snapcraft#758 closed: Add an integration test for parts with filesets [15:02] PR snapcraft#797 closed: Use --dangerous when installing snaps in yakkety [15:05] kgunn, tedg yeah i'm learning that as well, working on my first hooks [15:15] Bug #1623279 changed: [Errno 2] No such file or directory: '/home/robru/src/bileto.snap/stage/debian/source' [15:19] jdstrand: https://github.com/snapcore/snap-confine/pull/146/files enables sanity timeouts [15:19] PR snap-confine#146: Use sanity timeouts around blocking operations [15:19] jdstrand: I need to leave now [15:19]