=== JanC_ is now known as JanC [06:46] good morning [06:47] hey zyga-suse, good morning [06:47] mvo: hey, [06:48] mvo: did you see https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446/9 ? [06:52] mvo: I thought this is another instance of the rrexec bug from last week but I'm not so sure anymore [06:53] I found it interesting that half of snapd reexecuted [06:53] but the rest did not [06:58] mvo: I'll grab some food and I'll be back soon to do code reviews [06:58] zyga-ubuntu: yeah, will do the same [06:59] zyga-ubuntu: interessting bug :/ [07:14] PR snapd#3614 closed: daemon, client, cmd/snap: implement "snap services" [07:24] mvo: last night gustavo asked everyone to upgrade spread [07:29] I wrote a test simulating 2.0.2 and re-execing snapd, let's see how it works [07:34] * zyga-suse wonders what the movie crew outside is doing? [07:36] I need a 2nd review for 3619 [07:38] they are shooting a TV show outside now [07:38] * zyga-suse wonders what's going on [07:39] zyga-suse: why each of this check that the interface match? shouldn't this be done before/somewhere in the caller? is there a case where that shouldn't hold? [07:39] pedronis: I think we never call this incorrectly but this is part of the code that was written veeery long time ago [07:39] pedronis: and I think we just kept the cross-checking semantics [07:40] pedronis: I wasn't trying to change it, just improve how it is done [07:40] well, given we are cleaning up, I question why not clean up even more [07:40] notice that pawel will have to touch these again btw [07:40] new names, new signatures [07:40] aha, indeed [07:41] well, I can yank the sanitize calls if you feel strongly about them [07:41] in theory this ensures that we are not, by mistake, allowing sanitize to pass with a wrong interface [07:41] I don't feel strongly but you are asking to check you put everywhere something, where that probably means it's done in the wrong place [07:44] I think it's more of a security paranoia at play; I just checked how we call Sanitize and we always call it with a matching interface that is looked up from the Interface field [07:44] so again, I can remove it as there seems to be no harm done [07:45] well, you can define helpers on repo [07:45] sanitizePlug and sanizeSlot [07:45] that would do the check [07:45] if you feel the paranoia is worth [07:46] it's a bit strange to ask everybody writing an interface to help taking of this paranoia [07:46] they are taking another shot of the same scene [07:46] indeed [07:46] this things are called in 4 places at all [07:46] though I think we had those helpers and they were nacked before (they checked for any panics as well) [07:46] I think Gustavo was gainst the catching panics [07:47] not the helpers [07:47] I think you are right [07:47] let me put private helpers in the repo and drop the checks in each interface then [07:49] you could even have private helpers sanitize on Slot and Plug themselves [07:49] hmm, interesting [07:49] let me experiment [07:50] (and another shot) [07:52] mmh [07:52] sorry [07:52] about what? [07:53] nothing was thinking something [08:18] mvo: ha [08:18] mvo: so weird [08:18] mvo: if I start with 2.0.2 [08:18] mvo: there's no core transition yet [08:18] so.... we're on 2.0.2 forever [08:18] (and ever and ever) [08:18] it seems [08:19] not sure if we can even do anything about it [08:20] zyga-suse: does 2.0.2 do re-exec? [08:24] nope [08:24] I don't see any traces of that [08:24] zyga-suse: then there is really nothing we can do :/ [08:24] PR snapd#3615 closed: add broadcom-asic-control interface [08:24] I think we only managed to do it for a later version that was also in debian stable [08:25] mvo: yep, I just found this very unfortunate as this is the version the reporter of that bug was using [08:25] zyga-suse: I mean, without re-exec its irrelevant if it fetches core or ubuntu-core. in general if things re-exec it will work even if ubuntu-core is used. then it will fetch ubuntu-core re-exec into that snapd and that snapd will transition to core [08:26] zyga-suse: version 2.21 is doing re-exec but we had a experimental re-exec in some earlier versions that got disabled again. iirc 2.0.10 is also re-execing [08:26] zyga-suse: unfortunate> totally :/ [08:26] mvo: one idea, unpublish ubuntu-core [08:26] or even tweak the store to say something like "update your snapd package" [08:26] as an error message, if one can be shoved to 2.0.2 [08:28] zyga-suse: if people start from a version that fetches ubuntu-core, thats fine, things will work. [08:28] do we know which version is requesting the snap? [08:28] zyga-suse: I mean, the problem with 2.0.2 is that it is not doing re-exec at all. or am I missing something? [08:28] maybe we could reject ubuntu-core on 2.0.2 installs [08:28] mvo: yes, that's the problem [08:28] and somehow people keep having it because it's on the ISO [08:31] zyga-suse: aha, I see. well, ideally the store would reply to every request from 2.0.2 with "please upgrade your snapd". so +1 for this proposal, we just need to check if the error message is visiable to the end-user [08:31] now we just need to check with store people to see if we can craft this [08:36] Chipaca: o/ === zyga-ubu1tu is now known as zyga-ubuntu [08:36] zyga-ubuntu: \o [08:38] zyga-ubuntu: does 3591 look good to you? [08:38] zyga-ubuntu: you did a review before and jamie addressed things afaict [08:38] hey Chipaca [08:38] mvo: how's things with you? [08:39] mvo: just a sec [08:39] mvo: I wrote a forum topic on the 2.0.2 problem https://forum.snapcraft.io/t/snapd-2-0-2-doesnt-reexecute-pulls-in-ubuntu-core-stays-stale/1455 [08:40] mvo: yep, +1 [08:40] Chipaca: doing well, finally doing reviews :) [08:40] Chipaca: and you? [08:40] mvo: no longer working on 'snap status'! [08:40] Chipaca: congrats on merging your PR [08:41] * Chipaca dances [08:41] of course, the next one is 'snap logs', so... :-) [08:41] ¯\_(ツ)_/¯ [08:41] Chipaca: just put an easter egg when you run "snap logs everything" [08:41] PR snapd#3591 closed: interfaces/greengrass-support: adjust accesses now that have working snap [08:41] could be an ester egg theme [08:42] zyga-ubuntu: I couldn't possibly comment [08:47] Chipaca: yay! [09:50] ogra_: since when we required the dtb to be part of the kernel snap? wasn't it supposed to be part of the gadget snap? [10:07] ppisati: it was discussed in london, the idea is that it is tied to the kernel snap as the kernel may or may not boot depending on the dbt that is used [10:07] ppisati: (in the pi specific case) [10:07] zyga-suse: ok [10:11] ppisati: https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/46?u=zyga [10:35] ppisati, it is only part of the gadget for pi ... all other boards use it from the kernel snap [10:36] ppisati, and what we discussed in london was to move for the pi to the same model and additionally include the binary blobs in the kernel snap [10:37] ppisati, essentially everything that is version wise bound together will go into the kernel snap on pi ... making us lose any kind of rollback for the kernel though [10:40] ogra_: ack [11:26] changing anything about interfaces in genral is a chore [11:26] mvo, zyga-ubuntu: do you guys have time to look at https://github.com/snapcore/snapd/pull/3260 ? [11:26] PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open [11:27] morphis: not at present [11:27] hm [11:27] I'm wrapping up stuff to switch to packaging and layouts [11:27] maybe after packaging [11:32] Trevinho Afternoon. What is the current status of your Telegram snap? [11:32] flexiondotorg: hey [11:32] flexiondotorg: I've replied to an email from popey some weeks ago about it.. [11:32] Can you forward that to me please? [11:33] flexiondotorg: basically, it needs work... Which I might do to finish if there's interest and we can have proper upstream contacts [11:33] flexiondotorg: sure I can [11:33] Thanks. [11:33] Does the email outline what work is required? [11:34] * zyga-ubuntu uses telegram snap all the time, would love to see upstream adopt it [11:38] * ogra_ uses sergios telegram snap ... [11:40] i didnt even know Trevinho has one as well ! [11:40] ogra_: mine is basde on sources [11:40] ogra_: but I didn't publish on store [11:40] ogra_: or well not public [11:40] ah [11:40] I wanted to get snapcraft to do the cool job of compilinng all the ellemtns and such [11:40] as they do upstream.. [11:41] ogra_: there is an email I sent to canonical-snapcraft ML [11:42] ages ago ... i remember that [11:42] flexiondotorg: sent [11:42] ty [11:44] Trevinho: flexiondotorg: what's the relation between your telegram snap and sergiusen's? [11:45] Chipaca: none.. [11:45] Chipaca: sergio's one takes the upstream built telegram and ships it [11:45] mine takes upstream code, and builds it as telegram does [11:46] it doesn't sign the binary of course, as it's something they only can do [11:54] pedronis: 3619 updated [12:02] zyga-ubuntu: did you change anything in core/repo ? [12:03] pedronis: I'm adding {plug,slot}.Sanitize [12:03] and making Sanitize{Plug,Slot} optional :D [12:03] in the branch ? [12:03] yep [12:04] but not yet? [12:04] I just pushed the initial huge patch in case I missed something there [12:04] in a moment [12:56] cachio: hi, I'm getting this unrelated errors on this branch, quite regularly: https://travis-ci.org/snapcore/snapd/builds/257198925?utm_source=github_status&utm_medium=notification do I need to merge branch or they new problems [12:56] pedronis, taking a look [12:57] merge trunk === sergiusens_ is now known as sergiusens [13:02] hello folks [13:02] random snap creation question [13:02] if I use the maven plugin to build some archive [13:02] can i then use something to extract the finished tarball? [13:07] or use the dump plugin to extract stuff from a previous part? [13:08] snapcraft keeps every by-product around after build ... so yes, if there is a tarball created, you will find it somewhere in your build directory [13:08] btw, http://rocket.ubuntu.com is probably the better place for snapcraft questions [13:09] (there is a #snapcraft channel) [13:09] aww but that involves more browser tabs [13:09] snap install rocketchat-desktop [13:09] ;) [13:09] no tabs needed [13:21] PR snapcraft#1403 closed: lxd: Only remove container if one exists [13:24] morphis, hey [13:25] ogra_: hey [13:25] morphis, could i bribe you for a second ack on https://github.com/snapcore/pi3-gadget/pull/11 (already tested and ondra reviewed and approved it already) [13:25] PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive [13:26] ogra_: sure [13:26] will have a look in a bit [13:26] * ogra_ hugs morphis [13:26] :-) [13:26] fg [13:26] bg [13:26] ah [13:26] darn ) [13:27] pick the middle ground ... thats the best compromise [13:35] cachio: you can point the suite to staging with "export SPREAD_REMOTE_STORE=staging" before executing [13:36] fgimenez, ok, thanks [13:41] cachio: np, this is the forum post with the beta validation details https://forum.snapcraft.io/t/core-snap-validation-process-at-beta-channel/1454 [13:42] fgimenez, great!!! [13:47] zyga-ubuntu: this is the error in the orangepi using the latest core from edge https://forum.snapcraft.io/t/how-to-use-spread-to-test-ubuntucore-image/1323/44?u=fgimenez [13:49] zyga-ubuntu: if you could take a look that would be great, it seems to pass with core from beta [13:49] ack [13:49] I'll check it out after lunch [13:55] zyga-suse: great, thanks! [14:21] mvo: did you push that parser branch by any chance? [14:22] mvo: we hit the hook issue again [14:22] - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install") [14:22] :/ === sergiusens_ is now known as sergiusens [14:24] zyga-ubuntu: is that on a revert? [14:24] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170727_125232_a75a6@/log.gz [14:24] upgrade/basic [14:27] zyga-ubuntu: meh, how annoying [14:29] feels like a blocker to me [14:29] we need to understand what is going on [14:30] it happened on amd64 this time, yesterday it was i386 [14:30] I think it is random [14:30] something is racing there [14:35] hmm [14:35] ogra@styx:~/tmp$ snap run --shell hello-world [14:35] To run a command as administrator (user "root"), use "sudo ". [14:35] See "man sudo_root" for details. [14:35] why do i get that sudo hint ? [14:38] of course the only path I didn't unit test has a off-by-one panic [14:38] huh, interesting [14:38] * Chipaca hugs everything [14:39] is that done by profilerc perhaps? [14:39] hehe [15:03] hello, I'm stuck on debian 9 after "snap install lx" with "[/] Run configure hook of "core" snap if present", any idea how I can solve this? [15:04] Slashman: hey [15:04] hmm [15:04] mvo: ^ [15:04] Slashman: I think rebooting will just fix that [15:04] and after that it will work OK [15:04] zyga-suse: ok, I wanted to avoid that but oh well [15:05] techincally [15:05] well, it is a bug ... [15:05] try this: [15:05] sudo umount /run/snapd/ns/core.mnt [15:05] too late, I just rebooted :p [15:05] ah [15:05] :D [15:05] ok [15:05] anyway, rebooting is easier to explain [15:05] ogra_: yes, but a pretty obscure one [15:06] it's not obvious what is going on [15:06] yeah, i just meant to say that it isnt normal that you have to reboot for anything *snap [15:06] hm, now I have 'error: cannot install "lxd": snap "lxd" has changes in progress' [15:07] snap list doesn't list lxd [15:07] Slashman: what does snap changes say? [15:07] "1 Doing 2017-07-27T14:51:42Z - Install "lxd" snap" [15:07] snap change 1 [15:08] https://apaste.info/GmKr [15:09] Slashman: is it stuck there now? [15:09] you can perhaps kill snapctl process (it should be stuck somewhere) [15:09] how can I know ? [15:09] that will unblock it [15:09] it should finish in a few seconds [15:09] if not it's the bug [15:10] snapctl is already dead it seems: https://apaste.info/1hOT [15:11] well I killed it [15:12] not sure if the error are a real issue: https://apaste.info/rut0 [15:12] hmmm [15:12] man [15:12] mvo: ^^ [15:12] https://apaste.info/qrre [15:13] yeah it's gone [15:13] please unmount /run/snapd/ns/core.mnt [15:13] sudo snap install core [15:13] and let's see if that works [15:13] which version of snapd are you on right now? 2.21 something? [15:13] Slashman: what is the output of "snap version"? [15:13] yeah, the one on debian 9 [15:13] 2.21-2 [15:14] Slashman: "snap version" may give different numbers, snapd will try to use bits from the core if it can [15:14] ok, here is the output: https://apaste.info/Vqic [15:15] ok [15:15] mvo: again [15:15] same case as https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446/9 [15:16] anyway I can make it work? [15:16] zyga-suse: yeah, snapd restarted, configure failed and it reverted to 2.21 but did not restart the new snapd [15:17] Slashman: sudo systemctl restart snapd should bring it back to normal operation. then "snap install core" - would be interessting to see if that works [15:17] what a mess :( [15:17] yes, re-exec has a problem we have not found yet on debian [15:18] seems to work, one strange info message but I see the core snap: https://apaste.info/1z60 [15:18] trying lxd now [15:18] devmode ?!? [15:18] Slashman: and snap version should how now that you are on 2.26.14 - does it do that? [15:19] indeed [15:19] ogra_: that's been fixed post 2.21, I think new snapd will correct that [15:19] Slashman: could you try something trivial like snap install hello ? [15:19] ah, k [15:19] I just installed the lxd snap [15:19] irritating though ... :) [15:19] Slashman: even better! [15:19] mvo: https://apaste.info/olsa [15:19] zyga-suse: I suspect it has something to do with "snap install $thing" without core, i.e. the implicit download of core [15:19] mvo: we need a debian-9 out of the box test ra [15:20] mvo: yes [15:20] mvo: I agree [15:20] Slashman: yes, that looks better :) [15:20] mvo: note that we don't have a debian 9 linode image [15:20] zyga-suse: yeah, I have a debian-9 and couldn't find a way to reproduce the error in there :/ [15:20] so, if I understand correctly, after snap installation, I should: 1) reboot 2) snap install core 3) systemctl restart snap 4) snap install core ? [15:21] Slashman, normally not ... but yes [15:21] Slashman: I think we don't know yet [15:21] :P [15:21] Slashman: umounting one special file and restarting snapd is the trick [15:21] but we're hazy on the details [15:21] Slashman, the normal behaviour is that you snap install lxd and it automagically pulls in core first without you having to do anythinng [15:22] yeah, I understand that's not the normal behavior :D [15:23] but until it is fixed, I'll have to document it my team doesn't get stuck trying to install it [15:24] anyway, thank you for your help guys! [15:29] PR snapd#3630 opened: many: implement "snap logs" [15:29] Slashman: thank you for reporting this, we're sorry for the bad experience [15:29] ^ "snap logs" \o/ [15:29] Chipaca: nice!! [15:29] favourite thing i learned: http.Flusher [15:30] (making "snap logs -f" nice an' responsive) [15:30] what is it? [15:30] zyga-suse: don't worry about it, I'm grateful that snap exists ;) [15:30] flush an ongoing log? [15:30] like tail -f? [15:31] Slashman: thank you! :-) [15:31] zyga-suse: http.ResponseWriter can optionally also be an http.Flusher [15:31] zyga-suse: if it is, then you can call w.Flush() [15:31] and it flushes the writer [15:31] the default writers are flushers [15:31] 😩 [15:32] * Chipaca hugs Pharaoh_Atem [15:32] 😫 [15:32] Pharaoh_Atem: what's wrong? [15:32] I was working late last night on a maint window and it went wrong [15:32] ouh :-( [15:32] ouch [15:34] so now I'm really tired today [15:35] * Chipaca sends cake [15:35] fgimenez, cachio: 2.27~rc4 for testing is now available in beta [15:35] * mvo hugs Pharaoh_Atem [15:36] zyga-suse: I don't suppose you've fixed 32-bit arches for fedora yet on snap-seccomp> [15:36] ? [15:36] Chipaca: nice, I learned something new! [15:37] zyga-suse: it's the same thing that bit us before with snap-confine a long time back [15:37] no, I'm still burried [15:37] sorry :/ [15:43] zyga-suse: could you please fix it before mvo makes 2.27? [15:43] I'd really rather not have to skip 2.27 :( [15:44] Is it safe to remove old revisions of the core snap? [15:44] yeah, I think it should be easy [15:44] mvo: when do you want to tag 2.27? [15:44] mcphail: yes [15:45] zyga-suse: thanks! [15:45] we should also probably add an i686 fedora test [15:45] to make sure we don't break this again [15:46] I don't know if we have a compatible i386 image in linode today [15:46] but totally agreed otherwise [15:53] pedronis: pushed with all the stuff I wanted [15:53] oh wow [15:53] github has a new "jump to symbol" feature! [15:54] sorry chasing something completely different [15:54] pedronis: no worries [15:54] -1449 +618 [15:54] my fingers hurt [15:55] from running rm ? [15:55] :P [16:03] I think pawel's work will be easier now [16:03] 1722 removed [16:04] only 24 actual non-empty sanitize functions left [16:07] * zyga-ubuntu -> coffee [16:08] * genii sips [16:26] mvo: \o/ thanks a lot, cachio want to give it a try? :) [16:27] fgimenez, mvo sure, I'll do [16:28] fgimenez, starting now [16:29] cachio: great thanks a lot, pls let me know how it goes and if i can be of any help, i think the forum post has all the details, let's see [16:29] fgimenez, I'll follow that [16:29] cachio: cool thank you [16:30] fgimenez, yaw [16:45] PR snapd#3631 opened: tests: apply underscore convention for SNAPMOUNTDIR variable [16:47] mvo: do you intend to investigate the debian issue? [16:47] if not I can pick that up [16:50] Chipaca: why don't you write longer commit messages? [16:52] mvo, if you have 1 minute to look at PR 3631 [16:52] it is trivial but large [16:52] cachio, mvo: note that I'd like to squash merge it [16:53] there's a lot of junk in the history for a patch like that [16:53] zyga-ubuntu, yes, trying to fix that [16:53] not sure why it is showing the history [16:53] I can explain later, for now it's just a matter of squash merging that [16:53] but most of the commits are already merged [16:54] alternatively you can squash locally and push that over [16:54] zyga-ubuntu, i'll try that [16:54] cachio: git rebase -i origin/master [16:54] squash everything [16:54] and reuse the commit message from the PR (I edited it) [16:57] cachio: also if you do this, please pull [16:57] cachio: I pushed one patch into your branch [17:06] cachio: did you force push? [17:06] cachio: my commit is gone and the whole history is there still [17:06] zyga-ubuntu, I found the problem why it is showing all the commits [17:06] one sec [17:12] zyga-ubuntu, I'll create a new Pr [17:12] cachio: stop [17:12] cachio: why? [17:12] cachio: let me show you how to fix this, ok? [17:12] cachio: do you want to hop on a hangout? [17:12] I had differences between origin/master and upstream/master [17:12]