=== shuduo-afk is now known as shuduo [04:00] Hey guys, I'm writing my first snappy app. Could someone take a look at my snapcraft.yaml ... I'm having issues following the tutorial basically the section on extending the metadata. http://pastebin.com/smaw2XAr === chihchun_afk is now known as chihchun [07:33] good morning [07:52] good morning [08:35] didrocks, I almost finished the review of the replies [08:35] didrocks, maybe you can take a look and see how we can summarise this in a mail? :) [08:38] dholbach: sure, I'll have a look in 10 minutes [08:38] awesome === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:37] didrocks, did you get to it already? :-P [10:38] dholbach: I did read what you wrote [10:38] dholbach: want to write the email together or me to have a first pass? [10:38] as you like it [10:38] dholbach: I would prefer writing this email and you debugging my systemd issue under snappy :p (good deal! ;) [10:39] did you write a mail to the list about it already? [10:39] maybe somebody there can help? [10:40] dholbach: tried already with pitti and mvo, I don't see anyone else better at those systemd issues though [10:47] writing an email shouldn't take very long :-) [10:47] it's worth a try, no? [10:47] dholbach: I'm just afraid we'll reash those 4 hours of exploring and retrying everything [10:49] I could imagine that you're not the only one to run into a problem like this [10:49] so it might be worth discussing [10:49] dholbach: from what pitti said he has never seen this [10:49] right [10:49] well, it seems fairly specific to vlc, so no wonder [10:50] running it under a minimal environment without $HOME and such [11:10] pitti: the difference between the service and the app launched from the cmdline is when it succeeds, there is a core access debug: connection succeeded (socket = 6) [11:13] and 6 is /dev/urandom [11:14] pitti: is it something that rings a bell, like systemd preventing access to this socket? ^ [11:15] no, there is usually no access restrictiosn for services, unless you specifically request them [11:15] it's in net_Connect() which is where the network issue happens! [12:27] Good morning [12:27] good morning kyrofa! [12:27] Hey didrocks! [12:44] jdstrand, finally, crt @ 606 on prod \o/ [13:05] pindonga: yay! :) [13:05] pindonga: thank you :) [13:05] yw [13:06] Morning jdstrand! I hit that hash issue again with the owncloud snap and requested a manual review. Mind taking a look when you're able? [13:07] * jdstrand wonders what versions of the tools ran [13:08] 601 [13:08] * jdstrand runs automated review again [13:12] hmm [13:13] pindonga: I did 'run automated tools again' on https://myapps.developer.ubuntu.com/dev/click-apps/2431/rev/11/ and see that 606 was attempted, but 'Unexpected failure while running click-review. click-review' [13:13] let me try them locally [13:13] * pindonga checks and hopes he didn't break anything [13:14] PYTHONPATH=./ ./bin/click-review /tmp/owncloud.canonical_8.2.2ubuntu2_armhf.snap [13:14] Errors [13:14] ------ [13:14] - security-snap-v2:cap_exists:listener:network-listener [13:14] unsupported cap 'network-listener' [13:14] /tmp/owncloud.canonical_8.2.2ubuntu2_armhf.snap: FAIL [13:14] so, they are ok [13:14] [2] [13:15] "they are ok" meaning it's ok the review failed? [13:15] but it should have displayed the errors though [13:15] granted, that is with r610 [13:15] pindonga: yes [13:15] I mean, the tools didn't crash or anything. they correctly failed and corrected errored with '2' [13:15] jdstrand, oh it's no longer network-listener? [13:16] * pindonga checks the logs [13:16] jdstrand, the 'unexpected error' is bc we now avoid displaying tracebacks [13:16] kyrofa: it is for the moment [13:16] so I presume the tools crashed and didn't return a valid json [13:16] kyrofa: when interfaces land, it will be network-bind [13:16] pindonga: unfortunately, the output in the store didn't give anything useful [13:17] let me try with --json [13:17] jdstrand, ah, so that snap is okay then? [13:17] jdstrand, can you run the tools at 606 with --json [13:17] yesh [13:17] jdstrand: I got connect to work via the state engine yesterday [13:17] zyga-phone: woo! [13:17] jdstrand: disconnect is up for review, intents are almost done (I'll return to them soon), [13:17] jdstrand: I'm waiting for snap manager to stabiliize to detect snap changes [13:17] jdstrand: and a few more loose ends but very very much close [13:18] (I keep saying that) [13:18] pindonga: python -mjson.tool is happy [13:19] zyga-phone: nice :) [13:19] jdstrand: oh while you are here and I remember [13:20] jdstrand: I'd like to land apparmor branch - I think we can do it without unloading any *.snap profiles unconditionally [13:20] we are still using *.snap even though the security team doesn't like it and mvo and Chipaca gave us their support? [13:24] jdstrand: let's have a hangout [13:25] jdstrand: in a few moments, how do you feel about that? [13:25] jdstrand: to understand what the problems are and what we want to do about it [13:26] jdstrand: https://plus.google.com/hangouts/_/canonical.com/snappy-devel [13:26] zyga-phone: I can't come right this second [13:26] jdstrand: when would it be convenient for you? [13:27] 30 minutes? [13:27] jdstrand: okay [13:29] elopio: around? [13:30] elopio: I'm a bit confused by your comment on that PR yesterday [13:31] jdstrand, ok, I think the problem is that the tools are returning a non-zero exit code [13:31] jdstrand: invite sent [13:32] jdstrand, I know I probably asked you to do that... but I think we should return 0 if the tools succeeded (even if there are errors reported) [13:35] ogra_, running gdisk -l on an amd64 image makes it pretty obvious which partition is the writable one. However, running it on a pi2 image I get "Microsoft basic data" and "Linux filesystem." I assume "Linux filesystem" is the writable one, but why doesn't it have that label? [13:36] kyrofa, hmm, you probably want to look at the filesystem label for msdos (vs GPT) partitions [13:36] instead of the partition label [13:37] (i.e. make that check conditional based on what partition table is used) [13:38] jdstrand, nm that.. I'll see to adapt the store's code to cope with non-zero exit codes [13:39] ogra_, I'm afraid my familiarity with such things is really limited. Does that mean for the pi2 image I should use fdisk? Or am I misunderstanding? [13:41] zyga-phone: actually, 30 minutes is not going to work for me. in 30 I have another meeting to prepare for and then attend. 2.5 hours? [13:41] jdstrand: let's check [13:41] meh [13:41] I have a meeting not long after that too [13:41] hmm [13:41] really, I said what I needed to in the review [13:41] that could be difficult [13:42] how about we try quickly in 10 minutes? [13:43] jdstrand: ^ ? [13:46] kyrofa, i suspect you actually need to access the filesystem (so use kpartx to have a loop device and then inspect that with some e2fs tool) [13:46] i.e. dumpe2fs should give you the label [13:48] jdstrand: so you cannot meet in roughly two minutes for a moment just for a quick chat? [13:48] ogra_, ah okay, playing with that now. Thank you! [13:49] MBR is a bit more unpleasant than GPT here [13:53] Hello [13:53] jdstrand: Aroud? [13:53] nnnd [13:59] was in a meeting. gathering notes [13:59] I can meet for a few minutes [13:59] but give me a minutes [13:59] zyga-phone: ^ [14:01] jdstrand, niemeyer: ok, see you in the HO [14:01] Okie dokie [14:07] plars: I'm here. I was talking about the changes in this file: https://github.com/ubuntu-core/snappy/pull/650/files#diff-2b427437cfbad1b468fc4b05d0218bf1 [14:10] elopio: yes, those came from your PR! [14:10] elopio: but it never landed [14:10] elopio: https://github.com/ubuntu-core/snappy/pull/650/commits/12fa9a4eb73461d4177fdfc900fe4283ef6441ba [14:10] elopio: it was in this PR: https://github.com/ubuntu-core/snappy/pull/242 [14:11] plars: right. What I mean is that the change in that file should be in a different PR. The one we discussed an approved is about: "Avoid autopilot stop" [14:11] elopio: I did not requthor it, just cherry-picked it because it's needed for my PR to be of any use [14:11] elopio: but it already is in another PR... I'm confused [14:12] plars: I'm just requesting to split your PR in two, to keep a better changelog. [14:12] elopio: can't we just land your PR and rebase mine? [14:13] plars: sure. So let me propose the list flag in a new PR. [14:13] elopio: ah, is there no way to just use the original one? seems like you should just be able to reopen/resubmit it rigth? [14:14] you are right, I can reopen it. Give me a second to merge it with trunk and test it again. [14:24] jdstrand, pindonga now the failure says "Unexpected failure while running click-review. click-review" [14:25] kyrofa, yes, I'm aware, just submitted a fix for that in the store [14:25] will try to get it out asap [14:25] kyrofa, it's basically bc the store wasn't expecting a non-zero exit code from the tools [14:25] which they now do when there are errors [14:26] but it swallows the actual errors (which is what I fixed) [14:26] * sergiusens wants to say that if anyone PM'ed him that his computer crashed and has no idea who it was [14:26] good morning! [14:26] pindonga, but it seems that the snap shouldn't have failed, right? Because those caps are actually correct right now? [14:26] Hey sergiusens! Everything okay now? [14:26] kyrofa, after a reboot you mean? :-) [14:26] kyrofa, if the tools returned non-zero then the store considered that as a failure [14:27] pindonga, didn't jdstrand say it was because of the network-listener cap though, which is apparently still valid? [14:28] It's like the review tools are too new or something. If I switched the snap to use network-bind I don't think it would run right now... ? [14:31] kyrofa, elopio are we standing? [14:32] sergiusens, yup, on my way [14:33] kyrofa, the tools report an error: security-snap-v2:cap_exists:listener:network-listener (unsupported cap 'network-listener') [14:33] kyrofa, so the store rejects the review [14:54] kyrofa, pindonga: don't get hung up on network-listener. it is actually good that it failed because it showed a problem with the store [14:55] kyrofa: as for network-listener itself, it is understood that manually reviews will have to happen until the interfaces code lands [14:55] kyrofa: I didn't want to add a bunch of compat for 1 week when everything is changing after [14:58] jdstrand, ahh, that makes total sense [15:01] jdstrand, so that snap looks okay then? It can be approved? [15:02] plars: you are frozen. [15:32] * ogra_ sighs about 90+ min turnaround time for a simple fix .... [15:33] kyrofa: I can approve it, yes [15:33] pindonga: do you need that snap to hang around? ^ [15:33] jdstrand, nopes [15:33] jdstrand, awesome, thank you! [15:34] ogra_, there's the rebuilt owncloud you asked about a while back ^^ [15:34] yay [15:34] v9 ? [15:34] ogra_, no, though I have that one built already, there just seems to be a bug in the upgrade process that wipes out the calendar [15:34] ogra_, still investigating [15:34] oh [15:53] Hmm. This is new to me. "Inconsistency detected by ld.so: dl-open.c: 691: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!" === chihchun is now known as chihchun_afk [15:55] pedronis, ^ [15:56] beuno: that's a c assertion [15:59] sergiusens, using the kernel plugin, do you think it's possible to have another part that builds more kernel modules? [15:59] sergiusens, that builds "after" the kernel part? [15:59] "ldd" output doesn't look suspicious to me. [16:00] kyrofa, yeah, discussed it with ricmm already [16:00] sergiusens, sweet, happy to hear it [16:01] sergiusens, oh, btw ... note that i'm working on a script atm that prevents us from fully re-packing the initrd [16:02] (cpio being a tape archive tool actually has a concept of "append to existing archive" ... so we only need to decompress, append and recpmpress instead of completely unpacking and re-building) [16:11] niemeyer, zyga-phone: hey, so I had a lengthy discussion with the apparmor lead (jjohansen) and 'profile name: profile "/snaps/." {}' does not behave the way I expected. [16:12] niemeyer, zyga-phone: I was thinking that 'profile' made it a profile name and not do binary attachment, but that is not the case. if '/' is the first character of the profile name, the profile does binary attachment [16:13] niemeyer, zyga-phone: so, while /snaps/. isn't an actually file on disk and would technically work, this is weird because there is a trap for whenever /snaps/. did exist [16:13] niemeyer, zyga-phone: so we revisited policy namespaces and .snap [16:14] niemeyer, zyga-phone: short answer-- consider niemeyer's excellent reasoning that we are already doing a sort of namespacing currently (since you can filter on the '_' tuple in the profile name), appending .snap is no worse [16:15] niemeyer, zyga-phone: please go with appending .snap at this time [16:15] niemeyer, zyga-phone: we also talked through policy namespaces and I created a card to explore the topic more fully after 16.04 (it would need to be prioritized) [16:16] Yo [16:17] jdstrand: Okay, thanks for following up on that [16:18] niemeyer, zyga-phone as for the filename on disk-- I have no preference other than to say I find it very convenient to have the label be the same as the filename (so '..snap' now) [16:19] niemeyer, zyga-phone: but if you prefer something else, I'm ok with that [16:19] niemeyer, zyga-phone: sorry it took so long to come to a conclusion-- there were quite a few things to think through, including particulars on attachment and policy namespaces that needed to be worked out [16:20] jdstrand: No worries at all, happy we're finding some reasonable alternatives [16:20] jdstrand: Would snaps.. be any better, in terms of being slightly closer to the current apparmor convention? === shuduo is now known as shuduo-afk [16:21] well, we are a bit outside of convention here [16:22] Or perhaps snap.., to avoid the potential conflict with an actual binary at that location in the future [16:22] what might be interesting to consider is what does a policy namespace look like [16:22] in the future if we do policy namespaces, the label would look like: :snappy://. [16:22] (where 'snappy' is whatever we choose) [16:23] so, perhaps prepending is better since in the future we might change to policy namespaces [16:23] and in this manner, it will be similar to what people will have already been looking at [16:24] I think I am leaning towards snap.. [16:24] Okay deal [16:24] zyga-phone: ^^^ [16:24] then in the future, we might have: :snap://. [16:24] +1 [16:42] elopio, it seems that we need more executors :D http://162.213.35.179:8080/ [16:43] I wonder why those unit tests are so slow when we build the deb. [16:44] elopio, not the best moment for the update [16:44] yep it seems to get stuck with some of them [16:44] fgimenez: indeed. I will prepare it when all the devs have gone to bed. [16:53] pindonga: do you have some time for me? [16:53] I want to know how can I upload a snap to edge, and then promote it to beta in our CI process. [16:55] elopio, i recently asked the same and was pointed to bzr branch lp:click-toolbelt [16:55] (there is a README) [16:55] thanks ogra_ [16:55] though i'm not sure you can do channel switching with it ... [16:55] but the upload bit should be covered (if you cant use snapcraft upload) [16:57] I can use snapcraft upload, but I would be missing the publishing to edge part. [16:57] isnt that the default ? [16:57] i thought new uploads of an existing package automatically go to edge [17:00] as I understood, you first upload and the package is in no channel. Then you publish to a channel. [17:00] uuh, that would be bad [17:00] (if all subsequent uploads just went through) [17:01] i thought you always need to publish them [17:01] with an explicit step [17:01] at least thats how beuno always made it sound [17:04] snapcraft is missing the publishing command atm, yes [17:04] but there are ways 5to do it through the store api directly, right ? [17:06] elopio, ogra_ we don't yet support publishing via the api [17:07] it's in the trello board though [17:07] hmm, i kind of need that for the cdimage built kernel and os snaps ... [17:08] preferably they would get uploaded to the edge channel ... then get tested in an image and only then get auto-published to stable [17:12] Hello guys [17:13] When you run snapcraft snap you should get a .snap file correct? [17:13] indeed [17:13] (or an error message) [17:21] jdstrand: ack, thank you for the explanation [17:22] stevebiscuit, is it known that webdm doesnt auto-start after reboot anymore ? [17:23] (it works fine right after install, but never comes up on boot afterwards) [17:23] "sudo snappy service webdm start" starts it fine [17:23] Chipaca, ^^ did anything change there recently ? [17:26] ogra_: why is it that we don't have usb networking but debian has? [17:26] elopio, gadget you mean ? [17:28] ogra_: gadget? I mean that when I plug my bbb and boot into debian, it shares my network connection through the usb cable and I can ssh magically into the board. [17:28] elopio, right, thats the usb gadget driver [17:28] elopio, that would need some very BBB specific hacks, but is indeed just a setup thing (though i doubt it works on other boards that easily) [17:29] ogra_: and that's the kind of things that we would put in the gadget snap, right? [17:30] well, you need to make sure the kernel has the gadget modules you want ... you need to force-load them through /etc/modules (yes, that would be gadget) ... and then you need the proper network setup through some hacks/scripts [17:30] interesting. [17:30] * elopio reads about usb gadget driver. [17:33] Chipaca, mvo, bug 1558181 and bug 1558179 for you guys ... [17:33] bug 1558181 in Snappy "services are not started on boot anymore" [Undecided,New] https://launchpad.net/bugs/1558181 [17:33] bug 1558179 in Snappy "snappy list does not show webdm anymore, while sudo snappy list does" [Undecided,New] https://launchpad.net/bugs/1558179 [17:46] ogra_: that's the first time I've seen that behaviour, I believe mvo made some changes to how avahi is managed in Go which may affect webdm on reboot [17:46] stevebiscuit, yeah, i just tried a kvm amd64 image, there it behaves ... might be that actual HW adds some slowness that triggers races [17:46] ogra_: iirc there was discussion to make starting webdm on boot a special case but I don't think that's been done [17:47] ogra_: Chipaca knows the finer details of the Go/avahi trouble I think [17:48] k [17:49] i havent seen any discussions here [17:50] ogra_: the discussion was in the #snappy-devel Telegram channel if you want to join that [17:54] stevebiscuit, no, i dont [17:54] that excludes everyone [17:54] ogra_: I know more about webdm issue [17:55] ogra_: don't blame you ;) [17:55] zyga-phone, well, as long as it is being fixed at some point, its all fine [17:55] ogra_: it's complicated [17:55] ogra_: long story short, webdm cannot start without having eth0/wlan0 ready [17:55] ogra_: fixing this would require major go surgery [17:56] ogra_: right now we don't have a way to start a particular service only after network is available [17:56] zyga-phone, huh ? cant we just make the systemd unit wait ? [17:56] why would go be involved at alll there [17:56] ogra_: and AFAIR the idea is to special case webdm once and fix it after 16.04 [17:56] ogra_: webdm uses go [17:56] sure [17:56] but it ships a systemd service file [17:56] ogra_: go has no way to set a socket option that would make this problem go-away [17:56] and that can wait for the network [17:56] ogra_: no, it doesn't [17:57] ogra_: we generate all systemd units [17:57] oh ? [17:57] ah [17:57] ogra_: hence the special casing to just hack that dependency in there for webdm for 16.04 [17:57] ok, got it :) [17:57] thanks [17:57] ogra_: in the past that was magically tied to the network-client capability [17:57] right, it should be again :) [17:57] ogra_: but we're trying to break that coupling (as in, the coupling is gone now AFAIK) [17:58] (I could be wrong, I don't touch that code lately) [17:58] ogra_: the real fix is to fix go and webdm to have a way to set socket options [17:58] ogra_: so then it can just start as soon as it can [17:58] * zyga-phone has a very offtopic question [17:59] does anyone have a puff instead of a chair for their daily sitting needs? [17:59] after moving I didn't bring any quality chairs and the one I was using so far fell apart [17:59] and I'm considernig buying a puff instead of a regular char [17:59] chair* (too much C and I cannot see chairs but chars) [18:00] puff ? why not a ball ? [18:00] ball doesn't hold your back in any way [18:00] and I'd rather have something that does [18:00] it makes your back hold itself [18:00] and trains your muscules [18:00] + I think it's more comfy [18:00] that for sure ... [18:01] I only used a ball like that when my wife was pregnant - big red ball, moves around all the time, not something that works well in an office :/ [18:01] thats the purpose :) [18:01] (moving around so your body makes the right counter movements) [18:01] well 15 hours a day? [18:02] I don't know, do you work like that? [18:03] no, i have a comfy armchair in the living room and a semi-proper office chair ... and i switch between them several times per day [18:04] mmm [18:04] I found that they make those puffs where I live [18:04] just 10 minutes away from here literally [18:05] we've been at the factory and we'll get a quote for a custom model [18:05] that's somewhat bigger so it'd be more like an office chair as far as height is concerned [18:16] so basically kyrofa I'll check if the app works standalone, and then talk to you about how to integrate it, right? [18:17] jdstrand, kyrofa can you try uploading some snap? I've deployed the "fix" for the previous issue [18:17] it should now display the reported errors despite the non-zero exit code [18:19] enoch85, yeah, sounds good [18:20] pindonga, alright thank you! I'll check it out when I've rebuilt [18:23] kyrofa: +1 :) [18:26] Hello guys [18:27] Hi [19:18] pindonga: hey, sorry. fyi, kgunn uploaded this: https://myapps.developer.ubuntu.com/dev/click-apps/4520/rev/2/ [19:18] ogra_: is this a non-networked board maybe? [19:18] pindonga: so it looks like the store dtrt. there were review tools errors and the store handled them [19:18] jdstrand, so this looks a bit better than before, right? [19:18] pindonga: very much so. it is correct [19:18] cool [19:18] thx jdstrand [19:19] pindonga: thank you for the quick fix! :) [19:19] nw [19:19] and thanks kgunn for beating me to an upload :) [19:20] :) [19:21] kyrofa: keep me updated on progress of the image, got a test setup here but I'm guessing 'tonight' was 'tonight Virginia time' right... ;-) [19:21] jospoortvliet, ah, yes I suppose so! [19:21] ;-) [19:21] that's cool of course, will play with the results tomorrow or Friday. [19:26] jospoortvliet, sounds good :) [19:29] hey manik. How are things? [19:29] hey mvip [19:29] mvip: i am good, how are you? [19:30] manik: not bad. Recoverd from BCN and a few events following that. :) [19:30] manik: now there will hopefully be some time before the next one. [19:30] mvip: that's great. how was the rpi party? [19:31] manik: Great. Full house. Lots of cool DIY projects. [19:32] that's nice [19:32] was anything public? [19:32] amongst the projects? [19:32] manik: oh yeah, i think all of it was [19:32] manik it's more a community event [19:33] manik: with invited vendors/partners etc [19:33] manik: i need to step out in few to grab a bite before i starve to death, but a quick question for you [19:33] i see [19:33] sure [19:33] manik: what's the status on the disk wear and tear things? [19:33] the team's reviewing it, its a little early to say [19:34] 16.04 [19:34] 16.04s keeping things very busy atm [19:34] but it will make it into 16.04 at some point in a not too distant future? [19:34] i'll check on it again [19:34] thanks. [19:34] sure [19:34] and it will be part of an OS update, correct? [19:38] its a little early to say honestly [19:38] let me find out where we are and circle back [19:39] manik: thanks. that's probably the most important issue for us. [19:40] sure [19:55] mvo, nope, properly networked [19:56] ogra_: hm, hm [19:57] mvo, it is a dragonboard ... so wlan ... might be that starts a bit later than wired [19:58] (or slower) [20:00] ogra_: so there is a unfortunate dependency on network for services but if its networked it should work [20:00] ogra_: is it just webdm? [20:00] ogra_: or also e.g. xkcd-webserver? [20:01] mvo, cant tell much about xkcd-webserver since it is broken :P .- it starts but doesnt have networking allowed [20:01] so it just idles in the processlist [20:01] ogra_: uh [20:01] ogra_: wuut? that works in the integration tests I thnk [20:01] well i get errors here .... [20:02] hm, maybe its a new issue [20:02] note that i use daily images though ... i'm on todays os snap from cdimage [20:02] so there might be changes in the security layer that your all-snaps images dont have yet [20:04] could be, little has changed in this particular area though recently [20:05] I will check tomorrow [20:05] yeah, no hurry [20:05] that snapps list thing is really curious though [20:05] *snappy list [20:09] no changes in the security layer that I am aware of *except* that snappy no longer grants network-client if nothing is specified [20:10] mvo: ^ [20:10] is network-client specified in old-security/caps? is it reflected in /var/lib/snappy/{apparmor,seccomp}/profiles/xkcd...? [20:12] plugs: [20:12]