[00:06] * ogra_ curses ... [00:07] popey, i got wlan working on the nanopi-air ... but that now just shows a bug in netplan ... (the same one we had with the pi3) [00:08] cyphermox, can we disable unbind/bind for all brcmfmac drivers in netplan ? [00:08] (not just for -sdio) [00:09] * ogra_ has console-conf reliably explode (and the wlan device vanish when the config gets applied) [00:13] ogra_, why on _earth_ are you still awake? [00:13] kyrofa, battling with my nanopi-air ... my head doesnt stop thinking when i go to bed ... so i can as well just fix it :) [00:13] (and i did ... apart from that damned netplan bug) [00:13] Yeah I feel ya on that problem [00:20] PR snapd#3565 closed: cmd/snap-repair: skeleton code around actually running a repair [00:35] cyphermox, (or mwhudson, not sure who cares for nplan nowadays ...) bug 1712224 [00:35] Bug #1712224: netplan should not try to unbind brcmfmac [00:35] PR snapcraft#1499 opened: repo: make errors based on SnapcraftError [00:44] PR snapcraft#1500 opened: grammar: move out of pluginhandler === JoshStrobl|Work is now known as JoshStrobl|AFK [04:38] jjohansen: hey [04:45] PR snapcraft#1501 opened: tests: use assertThat instead of assertEqual [06:22] PR snapd#3776 opened: snap-repair: update snap-repair/runner_test.go for API change in makeMockServer [06:27] good morning [06:47] hey zyga-suse_ good morning. how are you? [06:48] zyga-suse_: if you could have a look a 3776 that would unbreak master [07:03] mvo: good morning, doing fine though we could use less rain :) [07:03] looking at the PR [07:04] mvo: looks good, [07:04] mvo: I'll grab breakfast/coffee and be back shortly [07:05] ta [07:35] re [07:36] PR snapd#3776 closed: snap-repair: update snap-repair/runner_test.go for API change in makeMockServer [07:40] mvo: 2.27.3 is non in stable yet, what are we waiting on? [07:43] zyga-suse_: I need to catchup with sergio and fgimenez - if QA is ok and CE got green light as well we can promote. but sergio was off yesterday so we couldn't promote then [07:52] ogra_: i think probably cyphermox, but if it's just a case of skipping the replug for another driver that sounds pretty easy [07:53] oh heh you patched it already [07:54] ogra_: give cyphermox a chance to look today if not, ping me and i'll merge it tomorrow? [08:01] hey mvo, afaik CE results are good so far (i've just forwarded you the last message in the 2.27.2 validation thread), not sure if they have finished though [08:05] fgimenez: thanks, that sounds promising [08:06] ogra_: The revision field of LP snap builds dates from May. The difference you point out isn't mysterious: one of those snaps builds from bzr and the other from git. [08:09] ogra_: (The revision is the source VCS revision that the snap was built from, not the revision in the store.) [08:20] cjwatson, oh, how confusing... but that explains it, thanks :) [08:47] PR snapd#3777 opened: snap-repair: implement basic `snap-repair list` (with --verbose) [08:59] ogra_: oooh! [09:00] ogra_: looking forward to playing with it :) [09:01] popey, i'll have an image ready soon [09:05] Bug #1708703 changed: "enable" does not apply connected slot security policy === matteo` is now known as matteo [09:08] Bug #1711847 changed: "snap run" doesn't support not installed packages [09:09] ogra_: super news :) [09:09] * ogra_ sits here waiting for "please press enter" already .... [09:12] popey, note that you need an antenna ... the wifi wont find anything without one [09:12] yeah, i have one [09:13] bah, and i messed up [09:13] * ogra_ starts over [09:13] PR snapd#3774 closed: spread: opt into unsafe IO during spread tests [09:13] (accidentially removing the SD when attaching the antenna on the running board isnt helpful ...) [09:13] mvo: hey, I've assigned https://bugs.launchpad.net/snapd/+bug/1709536 to you, since you worked on it recently and know the status better than I do [09:13] Bug #1709536: snapd 2.26.14 on ubuntu-core won't start in containers anymore [09:14] mvo: can you please update the bug? I believe this is fixed but I wanted to be sure [09:14] woot [09:14] with the unsafe-io flag tests ran in sub 30 minutes :) [09:14] it's a net win for all PRs [09:21] ogra@localhost:~$ snap list [09:21] Name Version Rev Developer Notes [09:21] core 16-2.27.2 2715 canonical core [09:21] linux-generic-allwinner 4.11.0-13.19 16 ogra kernel [09:22] nanopi-air 16-0.1 x1 gadget [09:22] ogra@localhost:~$ [09:22] popey, ^^^^ [09:22] is that good? :) [09:22] (uploading an image for you noow) [09:22] i'm ssh'ed in, yes, thats good ;) [09:22] ok, now I need to find my nano pi! [09:22] they're so small I lost it [09:24] i lost one of my antennas on the weeked ... they're even smaller and the plug on the board isnt really fitting 100% here [09:32] popey, http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz (once you found it) [09:32] ta === matteo is now known as matteo` === matteo` is now known as matteo [09:36] mvo: could you try to merge master into snapd#3757 [09:36] PR snapd#3757: snapstate: undo a daemon restart on classic if needed [09:38] please don't merge 3778 [09:38] PR snapd#3778 opened: overlord/ifacestate: setup profiles is its own undo task [09:39] PR snapd#3778 closed: overlord/ifacestate: setup profiles is its own undo task [09:41] pedronis: sure, I have a look now === ikey|zzz is now known as ikey [09:57] * zyga-suse reboots [09:58] OH! [09:58] thats cool [09:59] popey, seems the image work just as fine if you dd it to the internal mmc, so you only need the SD to dd it to /dev/mmcblk1 [09:59] *works [09:59] there's internal mmc? [09:59] yeah :D [09:59] huh, that's handy [09:59] so boot from it, then copy image to it then dd that to internal mmc? [09:59] right [10:00] thats amazing [10:00] well, its a bit more tricky since you need to get nanopi-air.img.xz onto the SD ... [10:00] and you indeed need to configure twice [10:00] right, but that part is known [10:00] but yeah, the board can run completely standalone, no SD needed [10:00] PR snapd#3779 opened: snap-seccomp: remove use of x/net/bpf from tests [10:01] i might produce an image with hacked initrd and the img file pre-loaded on the SD ;) [10:01] so that you get an option to directly write to mmc ... (just an initrd UI to dd) [10:02] pedronis: just to clarify for 3777 - we need to look at both state *and* disk because one might be corrupted (or both :) [10:02] mvo: well, my point was not about corrupted, more that state has only the last runs [10:03] per seq [10:04] mvo: for each sequence num we could have multiple revisions and for each revision we could have multiple runs [10:04] mvo: did you push https://github.com/snapcore/snapd/pull/3779 earlier? I recall seeing the same diff [10:04] PR snapd#3779: snap-seccomp: remove use of x/net/bpf from tests [10:04] pedronis: aha, indeed, let me fix that [10:05] zyga-suse: no, but its similar to 3502 which you reviwed 6 days ago [10:05] aha, thank you [10:05] mvo, FYI, i added the debdiff from https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1712224 to our netplan package in the image PPA [10:05] Bug #1712224: netplan should not try to unbind brcmfmac (like brcmfmac-sdio) [10:06] ogra_: thank you [10:07] pedronis: I will rework it to ignore the state, sounds reasonable? [10:08] zyga-suse: fwiw, I addressed your comments on 3502 [10:08] zyga-suse: it has a +1 from jamie, so an extra +1 would help :) [10:08] aha, thank you, I'll check that out [10:10] * zyga-suse needs a break [10:11] it's finally less cloudy/rainy, I'm stuck indoors for too long [10:17] mvo: you will still need the state for skip [10:18] mvo: I mean some stuff will be skip immediately and then there's no files on disk (at least atm) [10:18] pedronis: aha, what condition currently skips them? [10:19] mvo: not matching model, arch etc [10:19] pedronis: ok [10:19] mvo: anyway probably non verbose mode shouldn't list skipped stuff that didn't run anything [10:19] (there might be a lot of those for a given device) [10:20] pedronis: ok, I added a FIXME for myself and will look once the other bits are in place [10:20] pedronis: will work on the on-disk thing after lunch [10:21] mvo: I'm waiting for green to merge one of my repair PRs [10:22] pedronis: how do you feel about renaming "scipt.r0" to "r0.script" for consistency with the other file prefixes (output and stamp)? [10:24] ogra_: [10:24] popey@localhost:~$ uname -a [10:24] Linux localhost.localdomain 4.11.0-13-generic #19 SMP Sun Aug 20 16:36:37 CEST 2017 armv7l armv7l armv7l GNU/Linux [10:24] popey@localhost:~$ snap list [10:24] Name Version Rev Developer Notes [10:24] core 16-2.27.2 2715 canonical core [10:24] linux-generic-allwinner 4.11.0-13.19 16 ogra kernel [10:24] nanopi-air 16-0.1 x1 gadget [10:24] \o/ [10:24] thank you! [10:24] wohooo !!!! [10:25] * ogra_ pushes the gadget to the store [10:25] so mmcblk0 is the sd card and mccblk1 is the internal mmc, but I guess the internal one will be 0 once i reboot without the sd card? [10:25] nope, it stays 1 [10:26] but you dont need to care anyway, core operates based on filesystem labels [10:26] how big is it? [10:26] wonder how many snaps I can install before it blows up [10:27] oh, 8GB [10:27] /dev/mmcblk1p2 7.1G 400M 6.3G 6% /writable [10:27] that's enough [10:27] yeah [10:27] sweeet! [10:27] interesting, there is already two partitions on the internal device here [10:28] i wonder how long it will take to empty my USB powerbank [10:28] it has a filesystem on it already [10:28] yeah, there are some hardcoded "boot" partitions ... thats a kernel thing [10:28] oh ? [10:28] mine didnt have any filesystems i think [10:29] DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" [10:29] ah [10:29] that their hacked up deboostrap thingie that they advertise as Ubuntu Core [10:29] ah okay [10:29] will dd over it [10:37] yay, booting off internal mmc, nice work ogra_ ! I smell a forum post :) [10:38] gimme a bit ... i need to get the gadget snap past jdstrand in the store first and want to build a proper image :) [10:39] super, I won't steal your thunder :) [10:39] just imagine how cool it will be once you dont need a serial cable anymore (thats my next task with that kernel) [10:40] jdstrand, https://dashboard.snapcraft.io/dev/snaps/8227/rev/1/ for you :) [10:41] Bug #1712312 opened: Cannot add secondary group to user [10:45] PR snapd#3780 opened: many: configure store from state, reconfigure store at runtime [10:51] mvo: I'm thinking about that, I'm not a fan of "r1..." tbh, also because (though I'm not checking) revision can only increase, so we could use one counter across all revisions, and have revision later in the name [10:55] mvo: we have also "repair.r#" for the assertion atm [10:55] PR snapd#3571 closed: cmd/snap-repair: recover brand/model from /var/lib/snapd/seed/assertions checking signatures and brand account [11:14] mvo: do you know when we are goin to cut 2.28 ? there's some ongoing discussion that might need to changes to things that landed before it goes out [11:19] pedronis, we dont even have 2.27.3 out [11:20] (unless mvo decided to drop it and move the fix to 2.28) [11:27] PR snapcraft#1486 closed: core: improve source caching logic [11:31] re [11:31] * zyga-suse feels better now [11:33] ogra_: yep, I saw. approved [11:34] * ogra_ hugs jdstrand [11:34] ogra_: also updated the review tools, but need a store sync of course [11:34] * jdstrand hugs ogra_ :) [11:35] ogra_: what would you use to get the air on a new wifi network? [11:35] like, over serial console, when at a meetup, connecting to their wifi [11:35] either console-conf or edit the netplan config and call netplan apply [11:36] is this documented somewhere? [11:36] not sure ... /etc/netplan/00-snapd-config.yaml is the file to edit [11:36] ta [11:36] i guess cyphermox would know [11:36] kk [11:37] ah, wait ... i think it is "edit file", then "netplan generate" and then "netplan apply"" [11:39] hey jdstrand [11:39] how are you doing === zyga-suse_ is now known as zyga-suse [11:47] would the LD_PRELOAD hack help with libpeas looking for libpythonloader.so in /usr/lib/libpeas-1.0/loaders/libpythonloader.so without $SNAP prefix? [11:49] diddledan: maybe, maybe not, depending on some factors [11:51] specifically I am referring to this preload hack: https://github.com/sergiusens/snapcraft-preload [11:52] pedronis: aha, so the dir also contains "repair.r#"? I will update my mocks [11:52] diddledan, will that prevent peas from walking its buildin search path ? [11:53] it looks like the thing does hook dlopen, so I'll give it a go [11:53] pedronis: I want to talk to cachio about the release, hopefully we can release today [11:53] diddledan, alternatively https://developer.gnome.org/libpeas/stable/PeasEngine.html#peas-engine-add-search-path ... [11:53] mvo: no, that is in a different set of dirs [11:53] but i guess thats something you'd have to patch ... [11:54] (and use getenv() to give it a env var with the $SNAP search path) [11:55] pedronis: aha, ok. what do you mean with " we have also "repair.r#" for the assertion atm"? [11:55] ogra_: afaict it doesn't do any "searching" it seems to memoize the prefix at build time and then use that when building paths - the libpythonloader is found by literally "libdir" + "loaders" + "libpythonloader.so" [11:55] diddledan, well, it has that function above [11:55] (also prepend_search_path() as well) [11:55] mvo: /var/lib/snapd/repair/assertions/{$BRAND_ID}/${REPAIR_ID} vs /var/lib/snapd/repair/run/{$BRAND_ID}/${REPAIR_ID} [11:56] so it allows it ... just not OOTB [11:56] but we don't want to be hacking stuff to make it work in snappy - that is a sure WONTFIX when pushing upstream [11:57] asking them to ccep an env var for more flexibility ? not sure [11:57] mvo: we have a hierarchy for the assertions and a different one for the run artifacts [11:57] *accept [11:57] pedronis:yes [11:57] I tried that: https://bugzilla.gnome.org/show_bug.cgi?id=786581 [11:57] NOTABUG [11:58] mvo: just saying repair.r# exists but is not under */run/* [11:58] I even gave them a patch [11:58] pedronis: aha, ok. now I see what you mean [11:58] booo [11:59] maybe I should reword my bug report and try again [11:59] pedronis: quick brainstorm on your idea about just using the counter as the prefix? http://pad.ubuntu.com/c3Ku7ZRkGk has that what you have in mind? [11:59] mvo: anyway maybe it's ok to turn them all aorund to be "r#..." [11:59] yeah, talk about flexibility and advantages ;) [11:59] (make it sound like a positive thing they want :) ) [12:00] ogra_: in snap changes, I'm seeing a bunch of errors when doing Initialize device [12:00] Error 2017-08-22T11:57:13Z 2017-08-22T11:57:18Z Request device serial [12:00] popey, about get a serial" ? [12:00] ya [12:00] mvo: yes, but as I said now, not sure it's a good idea [12:01] popey, yeah, thats pointless ... pedronis once promised me it would stop doing that over time (but it isnt ... at least for me) [12:01] :) [12:01] mvo: anymore [12:01] pedronis: ok, let me do the alternative in the pad [12:01] popey, it wont ever get a serial since it isnt an official canonical image, but that doesnt do any harm apart from spamming the log [12:02] pedronis: maybe its a gustavo question, I'm sure he has an opinion, I don't mind either way much as long as its somewhat consistent [12:02] ogra_: no, it's my fault it back offs but per reboot, so if you reboot often it spams a bit anyway [12:02] ogra_: ok [12:03] pedronis: which means I will write/update the forum post I guess [12:03] pedronis, heh, well, an edge image reboots daily for the daily core ... thats it then (i only use edge everywhere) [12:03] mvo: anyway my point is that r1.repair is probably more consistent to what we usually do thatn repair.r1 and then it goes from there [12:04] mvo: other those are more than the repair, they are streams [12:09] PR snapd#3781 opened: cmd/snap-repair: track and use a lower bound for the time for TLS checks [12:09] pedronis: right [12:16] PR snapd#3757 closed: snapstate: undo a daemon restart on classic if needed [12:36] Issue snapcraft#1502 opened: Support :target suffix for build-packages [12:39] Issue snapcraft#1477 closed: multi-arch build packages [12:39] PR snapcraft#1346 closed: repo: multi-arch build deps [12:40] PR snapd#3782 opened: client: fix go vet 1.7 errors [12:42] who manages mup? [12:42] the syntax of issue URLs is wrong [12:43] Son_Goku: we were wondering ourselves recently [12:43] not sure, maybe niemeyer? === ShalokShalom_ is now known as ShalokShalom [12:45] mvo, hey, is it sru validation ready to start? [12:50] cachio: yes [12:51] mvo, starting with it [12:52] ta [13:00] hey zyga-arch :) [13:03] PR snapd#3783 opened: tests: make 17.04 shellcheck clean [13:26] nessita, remember we talked about collaborators will remain when we change the publisher of a snap? Is that only active shares or will the pending go along as well? [13:27] nessita, i'm trying to decide how persistently i nag the collaborators I invited :) [13:31] kenvandine, hum I'm not 100% sure and I'm otp, I can check after this call I'm in [13:31] nessita, no rush :) [13:43] the desktop-gnome-platform has a minor bug (this is a PR fixing it): https://github.com/ubuntu/snapcraft-desktop-helpers/pull/70 [13:43] PR ubuntu/snapcraft-desktop-helpers#70: update init to fix cases where the helper exits [13:46] diddledan: looking [13:55] diddledan: not sure what I think about it, I'd have to look at what the code is doing there elsewhere [13:55] diddledan: I'll let others review [13:56] ok [13:56] the line I removed is duplicated currently in mark-and-exec: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/mark-and-exec#L5 [13:57] so it's just removing the early setting of the .last_revision === JoshStrobl|AFK is now known as JoshStrobl [14:36] diddledan: this was a missing git add -p a long time ago [14:36] was supposed to be in [14:36] (when I added the mark-and-exec statement) [14:36] aha [14:36] :-) [14:36] so yeah, completly my fault, thanks for spotting it! :) [14:36] no problem .. glad to help :-) [14:37] merged, thanks again [14:44] obviously after adding measurements I cannot reproduce this failure [14:44] but running tests over and over I see failures all over the tree [14:54] popey, here you go https://forum.snapcraft.io/t/new-nanopi-neo-air-ubuntu-core-developer-image/1814 [15:01] sergiusens: the snappy-preload rewriting shared memory. have you tried it against an application that uses pulseaudio? [15:02] specifically I'm getting [pid 21683] open("/dev/shm/snap.liferea.pulse-shm-908736786", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory) [15:02] I'm wondering if the pulse-shm is not meant to be rewritten [15:03] ref: https://github.com/sergiusens/snapcraft-preload [15:09] ogra_: yay [15:18] mvo: so... [15:19] https://paste.gnome.org/pmlk7zgjb [15:19] mvo: I added this patch in the build: https://paste.gnome.org/pkepaslix [15:19] and came out with this https://paste.gnome.org/p8akyvrfy [15:19] I'm totally puzzled now [15:20] shall I leave it on memcheck for the evening? [15:20] (the host) [15:20] did we run into any golang bugs recently? [15:20] niemeyer: ^ [15:34] zyga-arch: AFAIK only the one about fork/exec concurrency, which arguably is a kernel bug [16:00] https://paste.gnome.org/p1hsubmo4 [16:05] pedronis: ^ any ideas/ [16:07] in daemon? [16:07] zyga-arch: our tests don't always use the lock correctly for convenience, it also means though that a test failure can turn into such a panic [16:08] aha, I see [16:08] this is not the error I'm researching but I wanted to share it in case it is more serious [16:08] so something else is failing but you get this insteaad [16:09] some printing around in the test exploding should reveal what's happening [16:12] it's not easily reproducible, it feels like each time I run it some part explodes but not the same part [16:27] PR snapd#3741 closed: tests: remove TestInterfacesHelp as it breaks when go-flags changes [17:42] PR snapd#3783 closed: tests: make 17.04 shellcheck clean [18:12] Stepping out into the non-eclipsed sun for a while === JanC is now known as Guest23196 === JanC_ is now known as JanC [19:14] niemeyer: added this to the topic with a question that we didn't consider: https://forum.snapcraft.io/t/lazy-fallback-serial-registration-for-classic/1232/8 [19:17] niemeyer: I also I have an errand tomorrow that will not allow me to make the standup I think [19:55] roadmr: hi! can you sync r913? this isn't urgent, but note there are a number of code changes [19:55] jdstrand: oh boy.. sure [19:56] jdstrand: as long as you're fairly confident it won't start rejecting snaps or crashing, we should be ok :) [19:56] jdstrand: I do a basic smoke check before proposing the merge, and then we can test on staging a bit [19:57] roadmr: I have a bunch of tests to test things. they aren't crazy changes [19:57] err, bunch of snaps [19:57] nice :) [19:57] and a lot of testsuite changes [19:57] so I am confident it'll be fine, but I watch the queue every day so I'll pay the price if things get rejected [19:58] pedronis: Thanks for the topic, and thanks for the note [19:59] roadmr: more seriously, it's mostly data changes. then there is a safety check for verifying there is enough disk space to uncompress, and then another check for executable stacks, which is rarely used by anything [20:00] roadmr: and then a few things to help the tools when run as a snap [20:00] which we're not using yet :/ but can't hurt [20:00] roadmr: I use it regularly and I run it through all the same tests [20:02] roadmr: but I discovered an issue that would've caused you problems: the snap was defaulting to using python3's default for gettemptdir(), which is /tmp, which in snappy is a memory backed tmpfs, which means that the size of reviewable snaps would've been smaller (eg, out of space if the snap didn't fit in half the ram on the review system) [20:03] roadmr: the change was to use SNAP_USER_COMMON, but then because we didn't get cleanup of that directory for free, I implemented some stale review dir reaping code [20:04] I'm particularly happy that the snap no longer needs to 'plugs: [ network ]' [20:07] \o/ [20:37]