=== wgrant__ is now known as wgrant [05:31] good morning [05:35] mwhudson: I'll look into packaging this week [05:35] mwhudson: sorry for not having any time for that lately [05:37] good morning mvo :) [05:38] mvo: I got a +1 from jdstrand on 4008, could you please do 2nd review? [05:39] mvo: that branch is on the critical path towards layouts [05:39] mvo: and I'd love it if we could pull it into 2.29.2 [05:40] hey zyga-solus - good morning === JanC_ is now known as JanC [06:06] zyga-solus: pr looks very good, I added some cosmetic suggestions and I'm fine pulling this in for 2.29 [06:12] thank you === chihchun_afk is now known as chihchun [06:46] good morning, snappy [06:53] good morning kalikiana [07:31] zyga-solus: me neither [07:31] zyga-solus: i refreshed the patches, so i think it's build-dep updates and try to build [07:32] thank you, that sounds good [07:32] let me check i pushed that much to alioth :) [07:34] thank you :) [07:35] seems i did! === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:02] hi folks! I just got an extra rasperri pi 3 and would love to use it for Ubuntu core. What would you all use it for? Nextcloud? [08:02] what's the new snapped hotness? :p [08:07] mvo: hey [08:07] mvo: I updated 4008 [08:08] mvo: could you please look at secureMkdirAll again? I'm not using defer but if you feel strongly about it I can reiterate === JoshStrobl is now known as JoshStrobl|zzz [08:14] zyga-solus: thanks, I check it out. out of curiosity, whats wrong with defer there? [08:14] mvo: nothing technically, there are two reasons (perhaps three) that I didn't use defer for [08:15] mvo: it was a rewrite from C and I kept the style [08:15] mvo: I check for all possible errors, including from close (unless already handling an error) [08:15] mvo: and defer would keep more FDs open then we need (one for each path segment) [08:15] mvo: if you prefer defer I can re-work the code to use defer and adjust tests to match [08:16] zyga-solus: ok, that makes sense. I was thinking the fd usage would be it [08:17] mvo: it's not a very strong argument arguably as in typical cases it would keep a handful of FDs open at most [08:17] mvo: I'll try defer quickly, if it's not too ugly we can merge that ;) [08:23] mvo: pushed with defer [08:24] mvo: have a look at patch here please: https://github.com/snapcore/snapd/pull/4008/commits/1a4d21279aedfbad71357ee031cca068af8e4850 [08:24] PR #4008: cmd/snap-update-ns: create missing mount points automatically [08:24] * zyga-solus -> ENOTEA brb [08:25] zyga-solus: it says "done" to the rename of EnsureMountPointImpl but the name is still EnsureMountPointImpl not EnsureMountPoint ? [08:27] zyga-solus: I like it but no super strong opinion either, just feel more "natural" [08:50] mvo: oh, I must have missed it, I renamed the other Impl, correcting now [08:51] Morning guys, I have got past the error I had yesterday building the image for the jetson tk1. I'm now at step 8: populate_filesystems. But I'm missing the MLO. [08:51] no, wait, I dropped that patch entirely :/ [08:52] I have tried to go through the uboot build steps in a terminal and it isn't building the MLO, anyone who can point me in the right direction of figuring out how to build a MLO or why ubuntu-image build expects to find one? [08:53] skjensen: sorry, I don't know much about uboot :/ [08:53] mvo: ok, all done now [08:54] * zyga-solus didn't make tea but instead walked his daughter to school to help [08:55] zyga-solus: to help what? [08:55] Chipaca: to help her, it's raining all the time and her backpack was very heavy today [08:56] zyga-solus: you're supposed to let the rain water get out of the backpack [08:58] :D [08:58] Chipaca: how would they have their swimming classes if I did? [08:59] zyga-solus: fair point [08:59] mvo: hi, did you see my comment from last evening? [09:00] Chipaca: can I frame you into a review of one function? [09:00] zyga-solus: you can try [09:00] Chipaca: can you please have a look at secureMkdirAll in 4008 please [09:00] Chipaca: it's very sensitive to get right and mvo found a bug already today [09:02] pedronis: yeah, I think it makes sense. I have no managed to start with it though but I think I'm done with the xdg-settings for now until I get a review from jamie again so I will look at it next [09:05] mvo: thx [09:05] zyga-solus: I don't understand your answer wrt path vs path/filepath [09:06] mvo, hey, the autokpgtest failure on 4072 look unrelated to the change (spread passed), i think it's safe to merge isn't it? [09:06] zyga-solus: filepath is path for filesystem stuff, path is a more generic thing (for, say, the web) [09:06] Chipaca: snapd#4075 needs a review, it's mostly undoing a previouw checking and starting going in a different direction (in store/ ) [09:06] PR #4075: many: reorg things in preparation to make handling of the base url in store dynamic [09:06] Chipaca: aha [09:07] pedronis: a'ight, i'll get to it after looking at zyga's [09:07] Chipaca: I didn't get that, I'll switch to filepath [09:08] Chipaca: done [09:08] pstolowski: indeed, thank you [09:08] PR snapd#4072 closed: daemon: use newChange() in changeAliases for consistency [09:10] zyga-solus: path.go still uses path though [09:11] Chipaca: path.go? [09:12] ah I see [09:12] OTOH grepping shows a few places [09:12] maybe i should fix in a separate pr [09:12] done [09:13] pushed [09:15] zyga-solus: jamie asked that you add a comment about why secureMkdirAll doesn't take relative paths, and you said 'done', but i don't see the comment; is it somewhere else? [09:15] Chipaca: man, I added that comment, did I break my rebase? [09:15] * zyga-solus looks [09:16] yep [09:16] it's not there :/ [09:16] * zyga-solus looks at reflog [09:17] pushed [09:18] * Chipaca worries [09:20] I just checked, nothing else is lost [09:22] mwhudson: could you please check https://bugs.launchpad.net/ubuntu/+source/golang-1.7/+bug/1726706 and comment if that is safe? there is concern from the sru team that this changes existing behavior on unrelated architectures [09:22] Bug #1726706: Fails to build snapd on ppc64el

[09:24] zyga-solus: how much bikeshedding is acceptable on this? [09:24] zyga-solus: 3? :-) [09:24] Chipaca: any amount, what else did you find? [09:25] mvo: sure [09:25] mvo, looks like Sergio has been waiting for your feedback on 3994 (and it's a very small change) [09:25] zyga-solus: i'll comment on the pr [09:27] pstolowski: thanks, I just checked and have the same question as you :) [09:27] good :) [09:30] mvo: where did the sru team express their concerns? [09:30] mwhudson: on irc via /query *cough* [09:30] mvo: hooray [09:31] mvo, hey, do you know what's the status of making classic snaps to work on 17.10? [09:32] mwhudson: I will ask apw to voice his concern about https://launchpad.net/bugs/1726706 in the bug :) but if you can just confirm its an ok change (with your golang maintainer/upstream head on, that would be great) [09:32] Bug #1726706: Fails to build snapd on ppc64el

[09:32] mvo: done [09:32] seb128: I'm not sure we are tracking this right now, aiui snapcraft is working on a fix, maybe kalikiana knows more? [09:32] mwhudson: thank you! [09:34] mvo, seems like an important issue? we have projects that were trying to go the snap way and are considering not doing that after all and going back to some other format since snaps don't work for them on current Ubuntu :-/ [09:35] seb128: yes, it sucks. I will raise it during the standup to make sure it gets attention and a proper analysis. is there a forum topic already? [09:37] seb128, i think snapcraft works on droopping all LD_LIBARY_PATH stuff for that and to make all classic snaps use rpath ... [09:37] * ogra_ looks fo the PR ... [09:38] zyga-solus: i was wrong :-) [09:39] Chipaca: about what? [09:42] seb128, https://github.com/snapcore/snapcraft/pull/1632 and https://github.com/snapcore/snapcraft/pull/1635 (seems both are merged in master already... though i guess all existing classic snaps need to be re-built) [09:42] PR snapcraft#1632: libraries: exclude the full set of libc6 [09:42] PR snapcraft#1635: snap: remove leaking LD_LIBRARY_PATH [09:43] mvo, ogra_, thanks [09:44] mvo: Fix for...? [09:44] mvo, https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/ is the forum post ... from what ogra_ replied it seems to be worked, would still be good to make sure it's properly tracked and know when it might land [09:44] * kalikiana reading the backlog [09:44] kalikiana, ^ [09:45] ogra_, kalikiana, mvo , could somebody post an update on that forum topic? it has several users asking for a status update in the course of the recent weeks and they just got silence in return so far [09:46] seb128: Good call. We've got some fixes for library exclusion and LD_LIBRARY_PATH handling in the pipeline. Will have to check exactly which bits apply to this topic [09:46] seb128, well, kyrofa and sergiusens have been working on it ... either of them should be able to give updates (i dont know more than whats in the discussion and the PRs) [09:52] kyrofa, sergiusens, ^ could you update that forum post before we get people who consider stopping their snap actually doing that because they feel like the system is buggy and nobody cares to update them on the issues? [09:55] zyga-solus: curse you! why am i reading open_by_handle_at(2) at this time of the morning [09:56] Chipaca, dude! now you made us all read it ! [09:57] ogra_: it's all dem bionic badgers [09:57] heh [10:02] Chipaca: haha [10:03] Chipaca: I read it too, did you find anything interesting? [10:06] zyga-solus: no, it nerdsniped me, is all [10:06] zyga-solus: commented on the pr [10:09] Chipaca: thank you [10:10] Chipaca: I can add O_PATH easily [10:10] Chipaca: please look at the defer vs hand-made cleanup response [10:10] PR snapd#4052 closed: tests: check for invalid udev files during all tests [10:10] zyga-solus: yes i know you added the defers [10:10] zyga-solus: i thought the better solution would be to move the body of the loop to a helper, but it doesn't help [10:11] Chipaca, hey, 4050 has a conflict [10:11] (that's why it took me some time to review: i wrote what i thought would help, and it didn't) [10:11] pstolowski: lies! [10:11] * Chipaca looks [10:11] :) [10:11] a PR that's been open for over a week, having a conflict? i'm shocked [10:12] fixing... [10:12] Chipaca: yes, I was thinking about that but there's no nicer way with defer [10:12] Chipaca: python refcount would be better [10:13] PR snapd#4007 closed: interfaces: add plugRef/slotRef helpers for PlugInfo/SlotInfo [10:13] zyga-solus: not really, as the refcount cleanup is not deterministic [10:13] zyga-solus: at least with defers when you're done you're done [10:14] Chipaca: in CPython it is deterministic [10:15] true [10:15] but who still uses cpython :-p [10:15] * Chipaca knows the answer is 'everybody' [10:17] mvo: remember `tidyNoticef`? did you have a better name in mind? [10:17] i'm touching that pr anyway to resolve a conflict so i might as well address this [10:20] kalikiana, thanks for posting on that forum discussion [10:20] Sure. Thanks for bring it up. I try to follow what's going on but sometimes it's just a lot to read. [10:30] i hadn't noticed github's favicon now shows the state of the tests [10:30] nice [10:32] Is it possible to unpack a gadget snap? [10:33] Chipaca: hm, I need to think about a better name but names are hard [10:33] skjensen: you can unpack it with unsquashfs, or you can mount it by hand [10:34] Chipaca: updated again [10:34] skjensen: snaps are just squashfs [10:34] Excellent.. Thanks I will try that and try understand what I have packed down into the gadget.. :) [10:34] :-) [10:35] zyga-solus: ack. On samuele's pr now, i'll check back later (unless i forget :-) [10:35] thank you! [10:35] I'll look at my other PRs that are close to landing [10:36] mvo: I'll just call it noticef, and add a comment [10:41] Chipaca: ok [10:53] Chipaca, got travis failure on completion test https://travis-ci.org/snapcore/snapd/builds/292510395?utm_source=github_status&utm_medium=notification , thought you might want to know [10:54] pstolowski: in prepare [10:55] nice one [10:55] 'tar: /var/lib/snapd: file changed as we read it' [11:07] pedronis: About your comment yesterday, perhaps the right place is indeed the handler of the "configure" task handler [11:08] pedronis: Oh, wait.. the task is actually a hook task [11:08] Hmm [11:08] niemeyer: yea, so a level up [11:08] configstate.Configure [11:08] which needs to create the hook task or a different one [11:08] unless we had overriding pluggability into hooks themselves [11:09] which seems a bit overkill unless we have another use case [11:09] pedronis: The cheapest seems to be intercepting it within the hook handler itself [11:10] pedronis: Well.. or we just have a new handler inside configstate [11:10] the 2nd one was my idea [11:11] I mean hacking in doRunHook is probably cheap but is strange unless we do it as a general mechanism, but then is not that cheap anymore [11:12] pedronis: Sounds good.. these other options in HookSetup probably don't make much sense either way [11:12] pedronis: "configure-snapd"? [11:13] sounds reasonable [11:13] mvo: ^ [11:14] elopio, sergiusens, hello! do you know how could I get reviews here? https://github.com/snapcore/snapcraft/pull/1634 thanks! [11:14] PR snapcraft#1634: Push metadata to the Store [11:24] Facu: For some reason there was no GitHub notifications of your replies... let me have another look now. [11:25] So thanks for pinging on that! [11:25] kalikiana, :) [11:25] The other guys will be around later. I can check also who would help review [11:29] pedronis, mvo: https://forum.snapcraft.io/t/special-casing-the-core-configuration/2594 [11:35] Facu: I added some comments - I'm still slightly confused, though, regarding the arch in update_metadata... what relevance does it have there, if it's unused in the failing code path? [11:36] Maybe the error should be changed? [11:36] pedronis: When you have a moment, would you mind to pass your eyes over #4070.. I think it's good to go, but it wouldn't heart to have another pair of eyes there to check we didn't miss something [11:36] PR #4070: hooks/configure: queue service restarts [11:37] thanks niemeyer [11:37] pstolowski: np [11:38] kalikiana, mmm... I see that SnapNotFoundError supports *not* receiving the arch [11:38] niemeyer, btw, any chance to have your eyes on #4013 before your holidays? [11:38] PR #4013: repo, daemon: use PlugInfo, SlotInfo [11:39] niemeyer, pedronis thanks for this, I'm working on this now [11:40] kalikiana, OTOH, see for example the function get_snap_status in that file; it builds the error with the arch even if the situation that led to the error has nothing to do with the arch (it happened to have the arch because it's just used later) [11:42] niemeyer: I'll look at 4070 in a bit [11:42] pedronis: Thanks! [11:42] mvo: np [11:42] ackk: PR reviewed, and LGTM [11:43] ackk: We need a second review on it [11:43] I don't recall who was involved in the socket activation conversations.. [11:44] Facu: I'd say rather not use it if nothing in the method does. It makes a lot more sense to me anyway [11:45] Ah, Chipaca would be a great reviewer here I think [11:45] Chipaca: #3916! [11:45] PR #3916: snap,wrappers: add support for socket activation [11:45] kalikiana, let's do that [11:46] pstolowski: Yeah, I'm hoping so.. it's looking like a long day :) [11:47] kalikiana, do you have any idea about that ACL failure in Travis? [11:48] thanks niemeyer [11:48] Facu: You mean CLI? Try merging master. The check can get confused when there's new commits. [11:49] CLA, even === chihchun is now known as chihchun_afk [11:54] skjensen, MLO is only expected if you defined it ... if your board doesnt use one you indeed dont need to add it to the gadget.yaml (sorry, only saw you now in the backlog) [11:55] skjensen, here is an example gadget without MLO https://github.com/ogra1/nanopi-neo-gadget ... note that you need to find the right size and offset values for your board indeed ... [11:55] niemeyer: pstolowski: about #4070, +1 with some comments [11:55] PR #4070: hooks/configure: queue service restarts [11:56] and questions [11:57] pstolowski: it seems some of your "upcoming" were in 2.28, time to remove the tags ? [11:57] pedronis: Good points [11:58] Definitely worth testing, and documenting in the snapctl description [11:58] pedronis, pstolowski: The flag also seems useful for the near future.. I'd wait until we have some experience, though, even to make sure we won't have to revert this decision based on user feedback [11:59] I'd name it as --now if it comes [11:59] yea [12:00] updated my comment [12:01] Thanks! [12:01] kalikiana, ack, will merge master, thanks [12:02] ogra_ thanks I will try to build the snap without.. :) [12:03] ogra_ how do you find the correct size and offset values? [12:03] skjensen, i think i wrote about thet in my blog ... [12:03] *that [12:03] okay, I will have another read through the blog.. :) [12:04] https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/ [12:04] under "creating the gadget.yaml " [12:05] you need to know the values typically used for your board ... then you can convert them to byte offsets and size [12:06] yes.. [12:20] ogra_ any chance you know the difference between u-boot.img u-boot-tegra.bin u-boot-dtb-tegra.bin u-boot-nodtb-tegra.bin I see you used the u-boot.img in your example for the bbb but the nanopo is using u-boot-sunxi-with-spl.bin so a bin file.. I got both from building u-boot so which to choose? [12:23] skjensen, oh, no idea, i'd start with u-boot-tegra.bin [12:24] try to find some docs about that from someone wh has done this before [12:24] Okay.. [12:44] willcooke: hey, I had an idea about speeding up gnome snaps on first launch [12:45] willcooke: it isn't fully formed or anything, but snappy has this thing 'userd' that runs as the user in the user's session. it seems plausible that it could be the thing that compiles the gschemas [12:49] jdstrand, we're planning on layouts allowing us to use the compiled schemas which should shave a couple of seconds at least of start-up [12:49] jdstrand, I'll ask jamesh to sync with you on that topic [12:49] willcooke: I'm actually involved in the layouts work, so if he can solve it there, even better [12:50] jdstrand, nice one. I'll drop James an email now anyway [12:52] pedronis, thanks for the review, good points. i'll check my 'upcoming' tags, thanks [12:55] anybody know a snap that has a service and a command? [13:00] Chipaca: network-manager [13:02] Chipaca: it's an interesting example though, because we don't want (for now) people installing it on classic [13:02] Chipaca: fun fact: no fchown with O_PATH [13:03] Chipaca: also, standup [13:05] Chipaca: postgresql? [13:26] Hi, I have a question. Say I have a snap that needs access to /tmp what interface(s) should it connect to? [13:30] arubislander: hey [13:31] arubislander: /tmp is always available but it is private to the snap [13:31] arubislander: no snap can use the real host-side /tmp directory [13:31] arubislander: there is no interface that controls this currently [13:31] arubislander: why do you need access to the host-side /tmp? [13:34] Well, it was more that I am using the libreoffice snap, and every time I want to directly open a file downloaded in firefox I get a permissions error thrown. I need to save the file first to a location in my home folder. [13:35] So I was thinking that maybe there should be an interface for /tmp access just like there is for removable media access. [13:36] zyga-ubuntu: O, I see the convention here is to make it explicit who you are talking too. Apologies for the previous omissions. [13:38] noise][: the postgres snaps have no daemons [13:38] noise][: i suspect this is a bug [13:39] odd. [13:40] Chipaca: etcd has both [13:41] yes yes it does [13:47] zyga-ubuntu: 'daemon is not so portable actually'. what failed with daemon? [13:47] it is defined by the LSB as required [13:48] I'm curious because of something I am working on [13:48] jdstrand: solus [13:48] jdstrand: I switched to nobody nogroup [13:49] arubislander: no worries :) [13:49] arubislander: real /tmp is in /var/lib/snapd/hostfs/tmp but it's not accessible [13:49] jdstrand: I think ikey would know why daemon group is not available there :) [13:51] jdstrand: thank you for the reviews, I think the two branches are much better now [13:51] jdstrand: I'm curious to know what you are working on now [13:51] well, the uid/gid priv dropping work [13:51] but it isn't something I have much time to focus on unfortunately [13:53] jdstrand: uid/gid priv dropping where? I'm not familiar with this topic [13:53] ah === JoshStrobl|zzz is now known as JoshStrobl [13:53] you mean in-snap users? [13:53] (users and grops) [13:53] *groups) [13:53] zyga-ubuntu: that is one of 4 use cases, yes [13:54] https://forum.snapcraft.io/t/snappy-users-and-groups-take-2/1461 [13:54] the topic was renamed to focus on only one use case though... [13:55] ikey: fyi> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/usernames.html [13:55] ikey: 'daemon' is listed under 'Required User & Group Names' [13:56] zyga-ubuntu: you might consider the fact that 'nobody' is optional under LSB and 'nogroup' is not lised as anything (I think 'nogroup' is a Debian-ism iirc) [13:57] zyga-ubuntu: perhaps your PR should use 'bin/bin' or continue to use 'daemon/daemon' and pick something else on solus? [13:57] anyway, I'm not blocking on that. it is just the test code [13:58] niemeyer: would be good to have your input here https://forum.snapcraft.io/t/new-install-refresh-api-with-the-store/2269/6 if you have any immediate feedback [14:02] jdstrand: eh, good point [14:02] jdstrand: maybe I cna put a list of things and if any of those work, pass the tset [14:02] *test [14:04] PR snapcraft#1639 opened: grammar: to statement [14:13] mvo: FYI, I just want to get this under someone's radar: https://bugs.launchpad.net/snappy/+bug/1723881 [14:13] Bug #1723881: [Feature Request] Support pre-invoke and post-invoke commands as DPkg::Pre-Invoke and DPkg::Post-Invoke in APT [14:16] * zyga-ubuntu breaks for lunch [14:29] zyga-ubuntu: thanks for the info. /tmp not being accessible, is that a confinement security based decision? [14:34] * jdstrand -> errands and lunch [14:41] mvo: can i nominate #4050 for 2.19rcN? [14:41] PR #4050: cmd/snap: tell translators about arg names and descs req's [14:42] mvo: also can i have a review of it :-) [14:43] hey popey, can you share the snapcraft.yaml of yakyak, probably a comment here: https://github.com/yakyak/yakyak/issues/741 would be nice. [14:44] arubislander: yes [14:44] arubislander: for isolation each snap sees a private /tmp [14:45] popey: someone actually proposed snap packaging a few months ago for yakyak: https://github.com/yakyak/yakyak/pull/752 but that didn't go much far. (and the diff looks weird) [14:45] PR yakyak/yakyak#752: Added Snap Support [14:45] mvo, is this the error that you mentioned in trusty https://paste.ubuntu.com/25817308/ [14:45] ? [14:46] darn, I didn't plug my laptop and it suspended [14:48] ogra_, kalikiana seb128 mvo not completely fixed yet, but definitely a high priority [14:49] ogra_, kalikiana seb128 mvo we've landed a few PRs that make progress, but we're still missing patchelf changes [14:49] Which is in progress [14:49] I'll update the forum thread [14:49] +1 [14:49] seb128, thank you for the ping, we should have been updating it as we made progress [14:50] cachio: I have not seen this one yet :/ [14:51] mvo, ok [14:52] kyrofa, thanks [15:05] PR snapd#3989 closed: client, daemon: rest api to configure store api [15:05] snappy-m-o 1630 xenial:amd64:integrationtests [15:06] PR snapd#3990 closed: cmd/snap,client,daemon: support set/unset of store front [15:08] snappy-m-o autopkgtest 1630 xenial:amd64:integrationtests [15:09] elopio: I've just triggered your test. [15:11] hrm [15:11] Chipaca: any reason not to merge #4062, you addressed the objection afaict. [15:11] PR #4062: cmd/snap: warn when a snap is not from the tracking channel [15:13] pedronis: I did, but I don't like to merge while it's still 'changes requested' [15:13] although I now see a "dismiss review" button [15:13] * Chipaca grins evily === cachio_ is now known as cachio_lunch [15:14] snappy-m-o, autopkgtest 1636 xenial:amd64 [15:14] kyrofa: I've just triggered your test. [15:15] PR snapd#3965 closed: interfaces/mount: add support for parsing x-snapd.{mode,uid,gid}= [15:15] PR snapd#3999 closed: cmd/snap-confine: add detection of stale mount namespace [15:16] PR snapd#4062 closed: cmd/snap: warn when a snap is not from the tracking channel