[00:54] Hi team, trying to build a snap, is this the best place to get some on the spot support? [01:48] Justin`: i think the forum is even more active (see /topic) [01:52] OK thanks. === JoshStrobl is now known as JoshStrobl|zzz === john is now known as Guest81616 === cpaelzer_ is now known as cpaelzer [06:31] good morning [06:31] * zyga-suse goes to get some breakfast [06:31] mvo: how are you doing? [06:32] it is finally not hot around here, actually the reverse; from 35+ to 16 :-~) [06:34] zyga-suse: hey [06:34] Hey1 [06:35] mvo, zyga-suse: snapd 2.27.2 has rolled out to stable updates [06:35] Son_Goku: I got F25 and F26 installed, I was totally offline during weekend [06:35] Son_Goku: oh, no .3? [06:35] what's the point? [06:35] .3 only has AppArmor fixes [06:35] Son_Goku: there was a regression in containers and I thought he's doing .3 to fix it [06:36] but in any case, I'm now online again and I can test and review fedora updates [06:36] so 2.27.3 is this: https://github.com/snapcore/snapd/commit/cfc44fa948cbd42ff636d2763099446768946e71 [06:36] but snapd isn't going to run on lxd in Fedora anytime soon [06:36] right [06:36] ah, I see [06:37] unless you want to take charge and get lxd into Fedora so that it works, that's not going to be a thing [06:37] I mean, I'd totally love it to be in Fedora [06:37] (considering it's needed for snapcraft cleanbuild to work) [06:38] Son_Goku: see you in 30 minutes, I've stated to pull updates [06:38] my network is workable but slow [06:38] kids murderred my data plan [06:39] davidcalle: you can merge the snappy-docs PR now [06:39] Good morning Son_Goku, I will, thanks for the heads up [07:00] good night [07:00] must sleep [07:00] it's 3am [07:19] re :) [07:19] good night! [07:30] mvo: hey, any plans to make the .3 tarball? [07:30] mvo: I was thinking, if you could commit the tarball maker script [07:30] mvo: we could modify it to include the version as gustavo requested last week [07:32] zyga-suse: tarfile is available [07:32] oh, I searched my history for the wget command and just did .3 instead of .2 and found 404 [07:32] * zyga-suse looks [07:33] zyga-suse: re version> yes, no time for that yet, but will happen soon, reparis are the priority right now [07:33] ok [07:33] wget https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+files/snapd_2.27.3.tar.xz [07:33] mvo: shall I look at github instead? [07:33] zyga-suse: yeah, please check gh [07:33] zyga-suse: usually I upload to the image ppa too, but not this time as we do not need a new core [07:34] zyga-suse: so your wget is right in 99% of the cases :) [07:34] zyga-suse: but gh should be the place [07:35] yep, and I also corrected the spec file to contain .vendor suffix [07:36] PR snapd#3769 closed: many: sanitize NewStoreStack signature, have shared default store test private keys [07:39] mvo: I see the layout of the tarball has changed again :D [07:39] mvo: may I just commit _a_ script and let you add the parts you care about later? (changelogs perhaps) [07:41] zyga-suse: isn't the format of the tar what we want? snapd-$ver/... ? [07:41] zyga-suse: or what am I missing? [07:41] mvo: it oscilates between snappy.upstream and snapd-$version [07:42] zyga-suse: it should not, everytime its snappy.upstream in GH that is a bug [07:42] mvo: I'd honestly prefer the name-version [07:42] zyga-suse: it is currently .upstream for the dpkg-buipdackage generated tarfiles, which is a bit of a problem with dpkg-buildpackage. I want to check if I can make gbp to generate nice dirs [07:43] zyga-suse: name-version is what we want and what is in GH [07:43] mvo: aha [07:43] mvo: ok, so as long as it _stays_ this way then I'm very happy [07:43] zyga-suse: its just not (yet) in lp because of dpkg-buildpackage [07:43] zyga-suse: yeah, you can smack me everytime something is on GH where its not like this [07:43] * zyga-suse sits outside at 15C [07:44] mvo: I'll hug you for each release, no less [07:44] :D [08:17] hey pstolowski! [08:17] zyga-suse, hi! [08:26] PR snapd#3765 closed: vendor: explode and make more precise our golang.go/x/crypto deps, use same version as Debian unstable [08:38] PR snapd#3773 opened: snap-repair: execute the repair and capture logs/status [08:52] mvo, zyga-suse: seeing snapd failing to boot inside LXD atm, https://paste.ubuntu.com/25361363/ [08:52] that is 2.6.10 [08:52] sorry, 2.26.10 which is currently in xenial [08:55] mvo: hi, should we reenable Fedora tests: snapd#3755 [08:55] PR snapd#3755: try to reenable fedora spread tests [08:55] morphis: this is fixed in 2.27.3 [08:56] zyga-suse: question is then, when will it be in xenail? [08:56] morphis: via re-exec it should be very soon, not sure [08:56] morphis: directly, no idea, that's a question for mvo [08:56] zyga-suse: isn't this coming from the Nice= value being set in the .service file? [08:56] morphis: indeed [08:57] morphis: please diff 2.27.2 and 2.27.3 [08:57] how can that then be fixed via re-exec? [08:58] oohhh [08:58] sorry [08:58] indeed, good point [08:58] :-) [08:58] I think we need a real .deb release for htis [08:58] *this [08:58] jepp [08:59] * zyga-suse is freezing-ish at 15C outside [08:59] I'll get indoors and make some warm tea [08:59] zyga-suse: but yeah, already fixed with https://github.com/snapcore/snapd/commit/afcf731aac5333edd444071a8f2a41f033be0edd [08:59] thanks [09:18] * mwhudson waves [09:19] what gyrations do i need to go through to be able to seed snaps that do not have store assertions? [09:19] mwhudson: seed as in ubuntu-image? [09:19] i guess i need an account with a key and to sign both the model and the snaps' assertions ? [09:19] pedronis: yes ish, this is for subiquity [09:19] mwhudson: there's no signing your own snap assertions atm [09:20] they just go in as --dangerous [09:20] pedronis: hmm, so i can just list any old snaps in seed.yaml? [09:21] atm yes, but they need to be flagged unasserted: true [09:21] ah ok [09:21] that's fine [09:21] atm? is this going to change? [09:22] mwhudson: maybe not this, but in general we might move not to allow any snap that was not listed as required in the model assertion [09:22] pedronis: so the context is subiquity, the server installer [09:23] for a "real" image we install subiquity from the store, fine [09:23] mwhudson: well to do seeding you need a model assertion [09:23] but i want to make test images out of subiquity branches [09:23] yes, we have a self signed model assertion currently [09:24] ok, you'll want a real one at some point but you probably need to feed us your requirment because I see a tension here in terms of model assertion [09:24] vs list of snaps [09:24] mwhudson: anyway what I said should be ok for tests [09:25] i have no problem with everything in the test images being signed with a bogus, non-store, non-widely trusted key [09:25] it would probably even be better for that to be the case [09:25] but for now, unasserted: true will do :) [09:25] mwhudson: as I said there's not plan to allow for signing the snaps on your own [09:25] there's snap-build but is not the full story [09:32] pedronis: works, thanks [09:38] mvo: zyga-suse: can we do something about merging snapd#3753 [09:38] PR snapd#3753: Make updateKeyValueStream reject unsupported options [09:39] let me look [09:39] yes, I wish this was fixed too [09:39] mvo: can I just correct it ^ ? [09:40] * zyga-suse does that [09:44] zyga-suse: if you are on it already I leave it to you, otherwise I can fix it too [09:44] (sorry) [09:44] I'm on it [09:44] ta [09:51] done [10:06] mvo: when will 2.27.2 hit stable? [10:09] is the code for mup available somewhere? [10:09] i don't believe https://launchpad.net/mup is the right one any more [10:10] ah https://github.com/go-mup/mup/tree/master [10:10] I don't know, I think this is something ogra restarted recently, maybe he knows? [10:11] ?? [10:12] * ogra_ has never touched mup [10:18] ah, sorry, I recalled you restarted it or something [10:24] mvo: snapd#3757 can be merged I think [10:24] PR snapd#3757: snapstate: undo a daemon restart on classic if needed [10:26] pedronis: yes, I think so too, I can tweak the message still if you want [10:33] PR snapd#3758 closed: spread: add mtr logs to diagnose linode issues [11:03] PR snapd#3725 closed: osutil: honor SNAPD_UNSAFE_IO for testing [11:09] PR snapd#3766 closed: cmd/snap-repair: test that redirects works during fetching [11:10] PR snapd#3774 opened: spread: opt into unsafe IO during spread tests [11:13] mvo: lots of errors on https://github.com/snapcore/snapd/pull/3753 [11:13] PR snapd#3753: Make updateKeyValueStream reject unsupported options [11:13] I think your revert broke it more [11:15] zyga-suse: meh, ok [11:16] maybe we can land one then the other will become landable [11:16] zyga-suse: I'll fix it [11:16] zyga-suse: 3754 fixes it implicitely [11:17] zyga-suse: but I canupdate 3753 too [11:45] zyga-suse, i only used to block mup spam on IRC by quietening the mup user in the channel [11:45] (only IRC stuff ... ) [12:00] * zyga-suse -> lunch [12:50] re [13:36] popey, i'm starting to get desparate with the nanopi-air ... i literally spent my whole weekend on it but i cant reproduce any of your errors, nor can i make wlan0 show up at all ... i tried all possible firmware combos and devicetree changes ... funnily the armbian kernel just works [13:37] (but indeed lacks any snap support) [13:48] ogra_: thats a bummer! [13:50] popey, well, not giving up yet ... after all there is a functioning kernel somewhere ... but it means patch by patch comparison (and armbian is full of them) [13:50] mmh, github is timing out for me atm [13:51] GH in general works here [13:51] hmm, or not [13:51] * ogra_ takes that back [13:52] https://status.github.com/ [13:52] it ded [13:52] yeah, the app-server availability curve is funny [13:53] i feel bad for the SREs that are going to have to be fixing that instead of eclipse viewing [13:54] damn it [13:54] the world is exploding :( [13:55] noise][, thats still a few hours out, isnt it ? [13:55] so it depends how fast they are :) [13:56] yeah, they have 2 hrs, best get crackin'! [13:56] err…3.5 hrs [13:57] well, depends where you are, i guess 2 hrs until west-coast contact [13:57] popey, ooooh ! actually armbian works ! i can actually install snapd and it seems to kind of work (hello world works) [13:59] popey, https://www.armbian.com/nanopi-neo-air/ with that image (mainline kernel) [13:59] so can you do the diff and figure out what you need from it? [13:59] ogra@nanopiair:~$ snap list [13:59] Name Version Rev Developer Notes [13:59] core 16-2.26.14 2466 canonical - [13:59] hello 2.10 24 canonical - [13:59] ogra@nanopiair:~$ hello [13:59] Hello, world! [13:59] and ... [13:59] ogra@nanopiair:~$ snap version [13:59] snap 2.26.14 [13:59] snapd 2.26.14 [13:59] series 16 [13:59] ubuntu 16.04 [13:59] kernel 4.11.7-sun8i [14:00] * ogra_ checks syslog for denials [14:01] ah, runs completely unconfined it seems [14:01] :/ [14:02] (teh htop snap shows all processes even without connected interfaces) [14:02] (and no complaints in syslog) [14:03] popey, i surely can, but will need to actually build an armbina image i guess ... to get the patched kernel tree ... (this is assembled from different trees during build) [14:04] * ogra_ installls the lxd snap on the nanopi for laughs [14:06] heh, not working [14:11] ah, installing the squashfuse deb helps [14:18] mvo: niemeyer: we wrote this in London: copy snap-repair to local disk, replace only when necessary after it reports one successful run but I don't remember if we changed our mind on that or is it's a for later [14:19] pedronis: On a call, but will be with you shortly [14:20] mvo: I did the copying out of the points from London: https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/40 [14:23] pedronis: great, I have a look in a little bit, pushing first round of review feedback, will look at the timeout for repairs next [14:30] davidcalle: hey, date corrected, reassigned to you [14:45] mvo: couple more small comments, looking good otherwise [14:50] PR snapcraft#1498 opened: lxd: pass original CLI arguments down to container [14:50] pedronis: great, I check it out now [14:50] pedronis: I think that was the latest agreement indeed [14:50] pedronis: excellent comments, thank you! I address them now [14:51] pedronis: We decided to not rebuild the binary every time, which removed most of the complexity in keeping things safe === JoshStrobl|zzz is now known as JoshStrobl [14:51] pedronis: And then made the replacement simpler, by just saying "If you can run it successfully, the binary (and disk) is not corrupted" [14:52] pedronis: So it's sort of the typical atomic write, with the exception that we run the .tmp before the mv just to be sure it looks good [14:54] pedronis: It doesn't look like a blocker to get the primary functionality in place, though [14:54] pedronis: The fact we're not rebuilding the binary every time is the safest net we have [14:58] PR snapd#3775 opened: [IGNORE FOR NOW] make sure fakestore is running [15:39] Are there any reported bugs related to snap causing a soft cpu lockup? We're seeing this: http://i.imgur.com/jRYfjzz.png [15:40] It takes down our whole machine because it locks up all the cores. [15:43] thunderstorm here, networking super super slow [15:43] To get things started, I'd just like to know a) if there's an issue for this being tracked somewhere, and b) what information you guys would like to see in order to start working towards a resolution [15:43] ryebot: hey, I think starting a forum post about this is best as then more people will see it (timezones!) [15:43] ryebot: provide "snap version" information [15:44] ryebot: as well as other basic things, hardware, snap etc [15:44] don't think we heard of soft lock ups [15:44] zyga-suse_: ack, will do === ikey is now known as ikey|afk [16:13] hi all :) Is there an interface I can connect to the docker snap to allow it access to a locally mounted filesystem? [16:13] PR snapd#3775 closed: [IGNORE FOR NOW] make sure fakestore is running [16:16] Hi Guys, apologies for asking for help in the developer channel.. But I'm looking for someone who can guide me through packaging our python project including dependency libraries like TensorFlow and OpenCV which has to be build from source to be CPU/GPU optimized. Anyone who got experience with this type of project? [16:27] mvo: zyga-suse: I tweaked sergio's PR [16:30] pedronis: thank you! [16:31] Soren_: no, sorry, can you please start a forum thread about this, I bet you will get more feedback this way [16:31] Soren_: just go to forum.snapcraft.io and create a new thread [16:33] * zyga-suse -> supper [17:18] PR snapd#3772 closed: tests: wait until the port is listening after start the fake store [17:27] PR snapd#3753 closed: Make updateKeyValueStream reject unsupported options [17:41] pedronis: thank you for merging it [17:45] GRRRR ! [17:45] ogra@nanopi-air:~$ sudo TMPDIR=. snap install linux-generic-allwinner_10.snap [17:45] error: cannot copy request into temporary file: write [17:45] /tmp/snapd-sideload-pkg-112412374: no space left on device [17:45] why the heck doo we use /tmp there [17:45] -o [17:45] (and why dont we respect TMPDIR at least [17:45] ) [18:25] ogra_: note that TMPDIR is not seen by snapd here [18:25] ogra_: and snap just makes a RPC request [18:25] hmm, yeah, i guess i'd need to hack the systemd unit === JoshStrobl is now known as JoshStrobl|Work [18:28] zyga-suse, in any case i thought we refrained from using /tmp a while ago ... pretty surprising there is still somethig using it [18:28] we never did [18:28] we never did what ? stop isung it ? [18:29] *using [18:29] yes [18:29] I don't recall any such patches [18:30] hmm, i thought that was the fix for the core install issues we had [18:31] which fix is that? [18:31] not sure what you are talking about [18:31] or which issue actually [18:31] trying to find it ... there were a bunch of bugs [18:43] zyga-suse, hmm, i thought there were at least three of them ... bug 1667865 is the only one i can find right now (and it isnt closed) [18:43] Bug #1667865: Unable to sideload large snap on DragonBoard [18:44] ah bug 1536864 [18:44] Bug #1536864: Signature verification of large packages fails on embedded systems due to limited RAM [18:45] so the assertion side was fixed ... the snp side wasnt [18:45] *snap [19:07] ogra_, yep, still a problem :) [20:24] Bug #1667865 changed: Unable to sideload large snap on DragonBoard [21:41] this one caught me today: https://bugzilla.gnome.org/show_bug.cgi?id=786581 [21:41] great. I can't override the path used by libpeas correctly, so usage in a snap is nogo for now === ikey|afk is now known as ikey === ikey is now known as ikey|zzz