[04:00] <code1o6> 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
[07:33] <dholbach> good morning
[07:52] <zyga-phone> good morning
[08:35] <dholbach> didrocks, I almost finished the review of the replies
[08:35] <dholbach> didrocks, maybe you can take a look and see how we can summarise this in a mail? :)
[08:38] <didrocks> dholbach: sure, I'll have a look in 10 minutes
[08:38] <dholbach> awesome
[10:37] <dholbach> didrocks, did you get to it already? :-P
[10:38] <didrocks> dholbach: I did read what you wrote
[10:38] <didrocks> dholbach: want to write the email together or me to have a first pass?
[10:38] <dholbach> as you like it
[10:38] <didrocks> dholbach: I would prefer writing this email and you debugging my systemd issue under snappy :p (good deal! ;)
[10:39] <dholbach> did you write a mail to the list about it already?
[10:39] <dholbach> maybe somebody there can help?
[10:40] <didrocks> dholbach: tried already with pitti and mvo, I don't see anyone else better at those systemd issues though
[10:47] <dholbach> writing an email shouldn't take very long :-)
[10:47] <dholbach> it's worth a try, no?
[10:47] <didrocks> dholbach: I'm just afraid we'll reash those 4 hours of exploring and retrying everything
[10:49] <dholbach> I could imagine that you're not the only one to run into a problem like this
[10:49] <dholbach> so it might be worth discussing
[10:49] <didrocks> dholbach: from what pitti said he has never seen this
[10:49] <dholbach> right
[10:49] <pitti> well, it seems fairly specific to vlc, so no wonder
[10:50] <pitti> running it under a minimal environment without $HOME and such
[11:10] <didrocks> 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] <didrocks> and 6 is /dev/urandom
[11:14] <didrocks> pitti: is it something that rings a bell, like systemd preventing access to this socket? ^
[11:15] <pitti> no, there is usually no access restrictiosn for services, unless you specifically request them
[11:15] <didrocks> it's in net_Connect() which is where the network issue happens!
[12:27] <kyrofa> Good morning
[12:27] <didrocks> good morning kyrofa!
[12:27] <kyrofa> Hey didrocks!
[12:44] <pindonga> jdstrand, finally, crt @ 606 on prod \o/
[13:05] <jdstrand> pindonga: yay! :)
[13:05] <jdstrand> pindonga: thank you :)
[13:05] <pindonga> yw
[13:06] <kyrofa> 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] <jdstrand> 601
[13:08]  * jdstrand runs automated review again
[13:12] <jdstrand> hmm
[13:13] <jdstrand> 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] <jdstrand> let me try them locally
[13:13]  * pindonga checks and hopes he didn't break anything
[13:14] <jdstrand> PYTHONPATH=./ ./bin/click-review /tmp/owncloud.canonical_8.2.2ubuntu2_armhf.snap
[13:14] <jdstrand> Errors
[13:14] <jdstrand> ------
[13:14] <jdstrand>  - security-snap-v2:cap_exists:listener:network-listener
[13:14] <jdstrand> 	unsupported cap 'network-listener'
[13:14] <jdstrand> /tmp/owncloud.canonical_8.2.2ubuntu2_armhf.snap: FAIL
[13:14] <jdstrand> so, they are ok
[13:14] <jdstrand> [2]
[13:15] <pindonga> "they are ok" meaning it's ok the review failed?
[13:15] <pindonga> but it should have displayed the errors though
[13:15] <jdstrand> granted, that is with r610
[13:15] <jdstrand> pindonga: yes
[13:15] <jdstrand> I mean, the tools didn't crash or anything. they correctly failed and corrected errored with '2'
[13:15] <kyrofa> jdstrand, oh it's no longer network-listener?
[13:16]  * pindonga checks the logs
[13:16] <pindonga> jdstrand, the 'unexpected error' is bc we now avoid displaying tracebacks
[13:16] <jdstrand> kyrofa: it is for the moment
[13:16] <pindonga> so I presume the tools crashed and didn't return a valid json
[13:16] <jdstrand> kyrofa: when interfaces land, it will be network-bind
[13:16] <jdstrand> pindonga: unfortunately, the output in the store didn't give anything useful
[13:17] <jdstrand> let me try with --json
[13:17] <kyrofa> jdstrand, ah, so that snap is okay then?
[13:17] <pindonga> jdstrand, can you run the tools at 606 with --json
[13:17] <pindonga> yesh
[13:17] <zyga-phone> jdstrand: I got connect to work via the state engine yesterday
[13:17] <jdstrand> zyga-phone: woo!
[13:17] <zyga-phone> jdstrand: disconnect is up for review, intents are almost done (I'll return to them soon),
[13:17] <zyga-phone> jdstrand: I'm waiting for snap manager to stabiliize to detect snap changes
[13:17] <zyga-phone> jdstrand: and a few more loose ends but very very much close
[13:18] <zyga-phone> (I keep saying that)
[13:18] <jdstrand> pindonga: python -mjson.tool is happy
[13:19] <jdstrand> zyga-phone: nice :)
[13:19] <zyga-phone> jdstrand: oh while you are here and I remember
[13:20] <zyga-phone> jdstrand: I'd like to land apparmor branch - I think we can do it without unloading any *.snap profiles unconditionally
[13:20] <jdstrand> we are still using *.snap even though the security team doesn't like it and mvo and Chipaca gave us their support?
[13:24] <zyga-phone> jdstrand: let's have a hangout
[13:25] <zyga-phone> jdstrand: in a few moments, how do you feel about that?
[13:25] <zyga-phone> jdstrand: to understand what the problems are and what we want to do about it
[13:26] <zyga-phone> jdstrand: https://plus.google.com/hangouts/_/canonical.com/snappy-devel
[13:26] <jdstrand> zyga-phone: I can't come right this second
[13:26] <zyga-phone> jdstrand: when would it be convenient for you?
[13:27] <jdstrand> 30 minutes?
[13:27] <zyga-phone> jdstrand: okay
[13:29] <plars> elopio: around?
[13:30] <plars> elopio: I'm a bit confused by your comment on that PR yesterday
[13:31] <pindonga> jdstrand, ok, I think the problem is that the tools are returning a non-zero exit code
[13:31] <zyga-phone> jdstrand: invite sent
[13:32] <pindonga> 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] <kyrofa> 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] <ogra_> kyrofa, hmm, you probably want to look at the filesystem label for msdos (vs GPT) partitions
[13:36] <ogra_> instead of the partition label
[13:37] <ogra_> (i.e. make that check conditional based on what partition table is used)
[13:38] <pindonga> jdstrand, nm that.. I'll see to adapt the store's code to cope with non-zero exit codes
[13:39] <kyrofa> 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] <jdstrand> 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] <zyga-phone> jdstrand: let's check
[13:41] <jdstrand> meh
[13:41] <jdstrand> I have a meeting not long after that too
[13:41] <zyga-phone> hmm
[13:41] <jdstrand> really, I said what I needed to in the review
[13:41] <zyga-phone> that could be difficult
[13:42] <zyga-phone> how about we try quickly in 10 minutes?
[13:43] <zyga-phone> jdstrand: ^ ?
[13:46] <ogra_> 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] <ogra_> i.e. dumpe2fs should give you the label
[13:48] <zyga-phone> jdstrand: so you cannot meet in roughly two minutes for a moment just for a quick chat?
[13:48] <kyrofa> ogra_, ah okay, playing with that now. Thank you!
[13:49] <ogra_> MBR is a bit more unpleasant than GPT here
[13:53] <niemeyer> Hello
[13:53] <niemeyer> jdstrand: Aroud?
[13:53] <niemeyer> nnnd
[13:59] <jdstrand> was in a meeting. gathering notes
[13:59] <jdstrand> I can meet for a few minutes
[13:59] <jdstrand> but give me a minutes
[13:59] <jdstrand> zyga-phone: ^
[14:01] <zyga-phone> jdstrand, niemeyer: ok, see you in the HO
[14:01] <niemeyer> Okie dokie
[14:07] <elopio> 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] <plars> elopio: yes, those came from your PR!
[14:10] <plars> elopio: but it never landed
[14:10] <plars> elopio: https://github.com/ubuntu-core/snappy/pull/650/commits/12fa9a4eb73461d4177fdfc900fe4283ef6441ba
[14:10] <plars> elopio: it was in this PR: https://github.com/ubuntu-core/snappy/pull/242
[14:11] <elopio> 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] <plars> elopio: I did not requthor it, just cherry-picked it because it's needed for my PR to be of any use
[14:11] <plars> elopio: but it already is in another PR... I'm confused
[14:12] <elopio> plars: I'm just requesting to split your PR in two, to keep a better changelog.
[14:12] <plars> elopio: can't we just land your PR and rebase mine?
[14:13] <elopio> plars: sure. So let me propose the list flag in a new PR.
[14:13] <plars> 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] <elopio> you are right, I can reopen it. Give me a second to merge it with trunk and test it again.
[14:24] <kyrofa> jdstrand, pindonga now the failure says "Unexpected failure while running click-review. click-review"
[14:25] <pindonga> kyrofa, yes, I'm aware, just submitted a fix for that in the store
[14:25] <pindonga> will try to get it out asap
[14:25] <pindonga> kyrofa, it's basically bc the store wasn't expecting a non-zero exit code from the tools
[14:25] <pindonga> which they now do when there are errors
[14:26] <pindonga> 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] <sergiusens> good morning!
[14:26] <kyrofa> pindonga, but it seems that the snap shouldn't have failed, right? Because those caps are actually correct right now?
[14:26] <kyrofa> Hey sergiusens! Everything okay now?
[14:26] <sergiusens> kyrofa, after a reboot you mean? :-)
[14:26] <pindonga> kyrofa, if the tools returned non-zero then the store considered that as a failure
[14:27] <kyrofa> pindonga, didn't jdstrand say it was because of the network-listener cap though, which is apparently still valid?
[14:28] <kyrofa> 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] <sergiusens> kyrofa, elopio are we standing?
[14:32] <kyrofa> sergiusens, yup, on my way
[14:33] <pindonga> kyrofa, the tools report an error: security-snap-v2:cap_exists:listener:network-listener (unsupported cap 'network-listener')
[14:33] <pindonga> kyrofa, so the store rejects the review
[14:54] <jdstrand> 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] <jdstrand> kyrofa: as for network-listener itself, it is understood that manually reviews will have to happen until the interfaces code lands
[14:55] <jdstrand> kyrofa: I didn't want to add a bunch of compat for 1 week when everything is changing after
[14:58] <kyrofa> jdstrand, ahh, that makes total sense
[15:01] <kyrofa> jdstrand, so that snap looks okay then? It can be approved?
[15:02] <elopio> plars: you are frozen.
[15:32]  * ogra_ sighs about 90+ min turnaround time for a simple fix ....
[15:33] <jdstrand> kyrofa: I can approve it, yes
[15:33] <jdstrand> pindonga: do you need that snap to hang around? ^
[15:33] <pindonga> jdstrand, nopes
[15:33] <kyrofa> jdstrand, awesome, thank you!
[15:34] <kyrofa> ogra_, there's the rebuilt owncloud you asked about a while back ^^
[15:34] <ogra_> yay
[15:34] <ogra_> v9 ?
[15:34] <kyrofa> 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] <kyrofa> ogra_, still investigating
[15:34] <ogra_> oh
[15:53] <qengho> 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!"
[15:55] <beuno> pedronis, ^
[15:56] <pedronis> beuno: that's a c assertion
[15:59] <kyrofa> sergiusens, using the kernel plugin, do you think it's possible to have another part that builds more kernel modules?
[15:59] <kyrofa> sergiusens, that builds "after" the kernel part?
[15:59] <qengho> "ldd" output doesn't look suspicious to me.
[16:00] <sergiusens> kyrofa, yeah, discussed it with ricmm already
[16:00] <kyrofa> sergiusens, sweet, happy to hear it
[16:01] <ogra_> sergiusens, oh, btw ... note that i'm working on a script atm that prevents us from fully re-packing the initrd
[16:02] <ogra_> (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] <jdstrand> niemeyer, zyga-phone: hey, so I had a lengthy discussion with the apparmor lead (jjohansen) and 'profile name: profile "/snaps/<name>.<app>" {}' does not behave the way I expected.
[16:12] <jdstrand> 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] <jdstrand> niemeyer, zyga-phone: so, while /snaps/<name>.<app> isn't an actually file on disk and would technically work, this is weird because there is a trap for whenever /snaps/<name>.<app> did exist
[16:13] <jdstrand> niemeyer, zyga-phone: so we revisited policy namespaces and .snap
[16:14] <jdstrand> 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] <jdstrand> niemeyer, zyga-phone: please go with appending .snap at this time
[16:15] <jdstrand> 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] <niemeyer> Yo
[16:17] <niemeyer> jdstrand: Okay, thanks for following up on that
[16:18] <jdstrand> 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 '<name>.<app>.snap' now)
[16:19] <jdstrand> niemeyer, zyga-phone: but if you prefer something else, I'm ok with that
[16:19] <jdstrand> 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] <niemeyer> jdstrand: No worries at all, happy we're finding some reasonable alternatives
[16:20] <niemeyer> jdstrand: Would snaps.<snap>.<app> be any better, in terms of being slightly closer to the current apparmor convention?
[16:21] <jdstrand> well, we are a bit outside of convention here
[16:22] <niemeyer> Or perhaps snap.<snap>.<app>, to avoid the potential conflict with an actual binary at that location in the future
[16:22] <jdstrand> what might be interesting to consider is what does a policy namespace look like
[16:22] <jdstrand> in the future if we do policy namespaces, the label would look like: :snappy://<name>.<app>
[16:22] <jdstrand> (where 'snappy' is whatever we choose)
[16:23] <jdstrand> so, perhaps prepending is better since in the future we might change to policy namespaces
[16:23] <jdstrand> and in this manner, it will be similar to what people will have already been looking at
[16:24] <jdstrand> I think I am leaning towards snap.<snap>.<app>
[16:24] <niemeyer> Okay deal
[16:24] <niemeyer> zyga-phone: ^^^
[16:24] <jdstrand> then in the future, we might have: :snap://<snap>.<app>
[16:24] <niemeyer> +1
[16:42] <fgimenez> elopio, it seems that we need more executors :D http://162.213.35.179:8080/
[16:43] <elopio> I wonder why those unit tests are so slow when we build the deb.
[16:44] <fgimenez> elopio, not the best moment for the update
[16:44] <fgimenez> yep it seems to get stuck with some of them
[16:44] <elopio> fgimenez: indeed. I will prepare it when all the devs have gone to bed.
[16:53] <elopio> pindonga: do you have some time for me?
[16:53] <elopio> I want to know how can I upload a snap to edge, and then promote it to beta in our CI process.
[16:55] <ogra_> elopio, i recently asked the same and was pointed to bzr branch lp:click-toolbelt
[16:55] <ogra_> (there is a README)
[16:55] <elopio> thanks ogra_
[16:55] <ogra_> though i'm not sure you can do channel switching with it ...
[16:55] <ogra_> but the upload bit should be covered (if you cant use snapcraft upload)
[16:57] <elopio> I can use snapcraft upload, but I would be missing the publishing to edge part.
[16:57] <ogra_> isnt that the default ?
[16:57] <ogra_> i thought new uploads of an existing package automatically go to edge
[17:00] <elopio> as I understood, you first upload and the package is in no channel. Then you publish to a channel.
[17:00] <ogra_> uuh, that would be bad
[17:00] <ogra_> (if all subsequent uploads just went through)
[17:01] <ogra_> i thought you always need to publish them
[17:01] <ogra_> with an explicit step
[17:01] <ogra_> at least thats how beuno always made it sound
[17:04] <beuno> snapcraft is missing the publishing command atm, yes
[17:04] <ogra_> but there are ways 5to do it through the store api directly, right ?
[17:06] <pindonga> elopio, ogra_ we don't yet support publishing via the api
[17:07] <pindonga> it's in the trello board though
[17:07] <ogra_> hmm, i kind of need that for the cdimage built kernel and os snaps ...
[17:08] <ogra_> 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] <code1o6> Hello guys
[17:13] <code1o6> When you run snapcraft snap you should get a .snap file correct?
[17:13] <ogra_> indeed
[17:13] <ogra_> (or an error message)
[17:21] <zyga-phone> jdstrand: ack, thank you for the explanation
[17:22] <ogra_> stevebiscuit, is it known that webdm doesnt auto-start after reboot anymore ?
[17:23] <ogra_> (it works fine right after install, but never comes up on boot afterwards)
[17:23] <ogra_> "sudo snappy service webdm start" starts it fine
[17:23] <ogra_> Chipaca, ^^ did anything change there recently ?
[17:26] <elopio> ogra_: why is it that we don't have usb networking but debian has?
[17:26] <ogra_> elopio, gadget you mean ?
[17:28] <elopio> 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] <ogra_> elopio, right, thats the usb gadget driver
[17:28] <ogra_> 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] <elopio> ogra_: and that's the kind of things that we would put in the gadget snap, right?
[17:30] <ogra_> 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] <elopio> interesting.
[17:30]  * elopio reads about usb gadget driver.
[17:33] <ogra_> Chipaca, mvo, bug 1558181 and bug 1558179 for you guys ...
[17:46] <stevebiscuit> 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] <ogra_> 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] <stevebiscuit> 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] <stevebiscuit> ogra_: Chipaca knows the finer details of the Go/avahi trouble I think
[17:48] <ogra_> k
[17:49] <ogra_> i havent seen any discussions here
[17:50] <stevebiscuit> ogra_: the discussion was in the #snappy-devel Telegram channel if you want to join that
[17:54] <ogra_> stevebiscuit, no, i dont
[17:54] <ogra_> that excludes everyone
[17:54] <zyga-phone> ogra_: I know more about webdm issue
[17:55] <stevebiscuit> ogra_: don't blame you ;)
[17:55] <ogra_> zyga-phone, well, as long as it is being fixed at some point, its all fine
[17:55] <zyga-phone> ogra_: it's complicated
[17:55] <zyga-phone> ogra_: long story short, webdm cannot start without having eth0/wlan0 ready
[17:55] <zyga-phone> ogra_: fixing this would require major go surgery
[17:56] <zyga-phone> ogra_: right now we don't have a way to start a particular service only after network is available
[17:56] <ogra_> zyga-phone, huh ? cant we just make the systemd unit wait ?
[17:56] <ogra_> why would go be involved at alll there
[17:56] <zyga-phone> ogra_: and AFAIR the idea is to special case webdm once and fix it after 16.04
[17:56] <zyga-phone> ogra_: webdm uses go
[17:56] <ogra_> sure
[17:56] <ogra_> but it ships a systemd service file
[17:56] <zyga-phone> ogra_: go has no way to set a socket option that would make this problem go-away
[17:56] <ogra_> and that can wait for the network
[17:56] <zyga-phone> ogra_: no, it doesn't
[17:57] <zyga-phone> ogra_: we generate all systemd units
[17:57] <ogra_> oh ?
[17:57] <ogra_> ah
[17:57] <zyga-phone> ogra_: hence the special casing to just hack that dependency in there for webdm for 16.04
[17:57] <ogra_> ok, got it :)
[17:57] <ogra_> thanks
[17:57] <zyga-phone> ogra_: in the past that was magically tied to the network-client capability
[17:57] <ogra_> right, it should be again :)
[17:57] <zyga-phone> ogra_: but we're trying to break that coupling (as in, the coupling is gone now AFAIK)
[17:58] <zyga-phone> (I could be wrong, I don't touch that code lately)
[17:58] <zyga-phone> ogra_: the real fix is to fix go and webdm to have a way to set socket options
[17:58] <zyga-phone> ogra_: so then it can just start as soon as it can
[17:58]  * zyga-phone has a very offtopic question
[17:59] <zyga-phone> does anyone have a puff instead of a chair for their daily sitting needs?
[17:59] <zyga-phone> after moving I didn't bring any quality chairs and the one I was using so far fell apart
[17:59] <zyga-phone> and I'm considernig buying a puff instead of a regular char
[17:59] <zyga-phone> chair* (too much C and I cannot see chairs but chars)
[18:00] <ogra_> puff ? why not a ball ?
[18:00] <zyga-phone> ball doesn't hold your back in any way
[18:00] <zyga-phone> and I'd rather have something that does
[18:00] <ogra_> it makes your back hold itself
[18:00] <ogra_> and trains your muscules
[18:00] <zyga-phone> + I think it's more comfy
[18:00] <ogra_> that for sure ...
[18:01] <zyga-phone> 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] <ogra_> thats the purpose :)
[18:01] <ogra_> (moving around so your body makes the right counter movements)
[18:01] <zyga-phone> well 15 hours a day?
[18:02] <zyga-phone> I don't know, do you work like that?
[18:03] <ogra_> 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] <zyga-phone> mmm
[18:04] <zyga-phone> I found that they make those puffs where I live
[18:04] <zyga-phone> just 10 minutes away from here literally
[18:05] <zyga-phone> we've been at the factory and we'll get a quote for a custom model
[18:05] <zyga-phone> that's somewhat bigger so it'd be more like an office chair as far as height is concerned
[18:16] <enoch85> so basically kyrofa I'll check if the app works standalone, and then talk to you about how to integrate it, right?
[18:17] <pindonga> jdstrand, kyrofa can you try uploading some snap? I've deployed the "fix" for the previous issue
[18:17] <pindonga> it should now display the reported errors despite the non-zero exit code
[18:19] <kyrofa> enoch85, yeah, sounds good
[18:20] <kyrofa> pindonga, alright thank you! I'll check it out when I've rebuilt
[18:23] <enoch85> kyrofa: +1 :)
[18:26] <Mr_Cake> Hello guys
[18:27] <code1o6> Hi
[19:18] <jdstrand> pindonga: hey, sorry. fyi, kgunn uploaded this: https://myapps.developer.ubuntu.com/dev/click-apps/4520/rev/2/
[19:18] <mvo> ogra_: is this a non-networked board maybe?
[19:18] <jdstrand> pindonga: so it looks like the store dtrt. there were review tools errors and the store handled them
[19:18] <pindonga> jdstrand, so this looks a bit better than before, right?
[19:18] <jdstrand> pindonga: very much so. it is correct
[19:18] <pindonga> cool
[19:18] <pindonga> thx jdstrand
[19:19] <jdstrand> pindonga: thank you for the quick fix! :)
[19:19] <pindonga> nw
[19:19] <jdstrand> and thanks kgunn for beating me to an upload :)
[19:20] <pindonga> :)
[19:21] <jospoortvliet> 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] <kyrofa> jospoortvliet, ah, yes I suppose so!
[19:21] <jospoortvliet> ;-)
[19:21] <jospoortvliet> that's cool of course, will play with the results tomorrow or Friday.
[19:26] <kyrofa> jospoortvliet, sounds good :)
[19:29] <mvip> hey manik. How are things?
[19:29] <manik> hey mvip
[19:29] <manik> mvip: i am good, how are you?
[19:30] <mvip> manik: not bad. Recoverd from BCN and a few events following that. :)
[19:30] <mvip> manik: now there will hopefully be some time before the next one.
[19:30] <manik> mvip: that's great. how was the rpi party?
[19:31] <mvip> manik: Great. Full house. Lots of cool DIY projects.
[19:32] <manik> that's nice
[19:32] <manik> was anything public?
[19:32] <manik> amongst the projects?
[19:32] <mvip> manik: oh yeah, i think all of it was
[19:32] <mvip> manik it's more a community event
[19:33] <mvip> manik: with invited vendors/partners etc
[19:33] <mvip>  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] <manik> i see
[19:33] <manik> sure
[19:33] <mvip> manik: what's the status on the disk wear and tear things?
[19:33] <manik> the team's reviewing it, its a little early to say
[19:34] <manik> 16.04
[19:34] <manik> 16.04s keeping things very busy atm
[19:34] <mvip> but it will make it into 16.04 at some point in a not too distant future?
[19:34] <manik> i'll check on it again
[19:34] <mvip> thanks.
[19:34] <manik> sure
[19:34] <mvip> and it will be part of an OS update, correct?
[19:38] <manik> its a little early to say honestly
[19:38] <manik> let me find out where we are and circle back
[19:39] <mvip> manik: thanks. that's probably the most important issue for us.
[19:40] <manik> sure
[19:55] <ogra_> mvo, nope, properly networked
[19:56] <mvo> ogra_: hm, hm
[19:57] <ogra_> mvo, it is a dragonboard ... so wlan ... might be that starts a bit later than wired
[19:58] <ogra_> (or slower)
[20:00] <mvo> ogra_: so there is a unfortunate dependency on network for services but if its networked it should work
[20:00] <mvo> ogra_: is it just webdm?
[20:00] <mvo> ogra_: or also e.g. xkcd-webserver?
[20:01] <ogra_> mvo, cant tell much about xkcd-webserver since it is broken :P .- it starts but doesnt have networking allowed
[20:01] <ogra_> so it just idles in the processlist
[20:01] <mvo> ogra_: uh
[20:01] <mvo> ogra_: wuut? that works in the integration tests I thnk
[20:01] <ogra_> well i get errors here ....
[20:02] <mvo> hm, maybe its a new issue
[20:02] <ogra_> note that i use daily images though ... i'm on todays os snap from cdimage
[20:02] <ogra_> so there might be changes in the security layer that your all-snaps images dont have yet
[20:04] <mvo> could be, little has changed in this particular area though recently
[20:05] <mvo> I will check tomorrow
[20:05] <ogra_> yeah, no hurry
[20:05] <ogra_> that snapps list thing is really curious though
[20:05] <ogra_> *snappy list
[20:09] <jdstrand> 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] <jdstrand> mvo: ^
[20:10] <jdstrand> is network-client specified in old-security/caps? is it reflected in /var/lib/snappy/{apparmor,seccomp}/profiles/xkcd...?
[20:12] <ogra_> plugs:
[20:12] <ogra_>  xkcd-webserver:
[20:12] <ogra_>   interface: old-security
[20:12] <ogra_>   caps:
[20:12] <ogra_>    - network-client
[20:12] <ogra_>    - network-service
[20:13] <ogra_> thats the snap.yaml that got installed
[20:14] <jdstrand> ogra_: can you paste what is in /var/lib/snappy/{apparmor,seccomp}/profiles/xkcd* ?
[20:14] <ogra_> http://paste.ubuntu.com/15404146/ is the relevant snippet from the apparmor profile
[20:14]  * jdstrand notes that others mentioned this and that there weren't any denials
[20:15] <ogra_> looks all commented out to me
[20:15] <jdstrand> no it isn't
[20:15] <ogra_> k
[20:15] <jdstrand> it is correct
[20:15] <jdstrand> the #include lines are pulling in things
[20:15] <jdstrand> didrocks mentioned this issue. he said it was only with services and cli commands didn't have the issue
[20:16] <jdstrand> I suggest someone look at what systemd is doing
[20:17] <ogra_> hmpf
[20:17] <ogra_> ubuntu@localhost:~$ snap find pastebinit.mvo
[20:17] <ogra_> Name           Version   Summary
[20:17] <ogra_> pastebinit.mvo 1.4.0.0.2 pastebinit
[20:17] <ogra_> ubuntu@localhost:~$ sudo snappy install pastebinit.mvo
[20:17] <ogra_> Installing pastebinit.mvo
[20:17] <ogra_> pastebinit.mvo failed to install: snappy package not found
[20:17] <ogra_> lovely ...
[20:19]  * ogra_ wishes snap find wouldnt be full of false positives
[20:19] <ogra_> anyway ... back to doing evening stuff :)
[20:22] <kyrofa> Ah ogra_ ... you're so very helpful to me. Thank you for your help on the writable stuff. It works perfectly
[20:39] <mvo> ogra_: uh, that should work
[20:39] <mvo> ogra_: its all going downhil
[20:39]  * mvo goes to bed
[20:54] <kyrofa> jdstrand, did you get a chance to approve that owncloud snap by any chance?
[20:57] <jdstrand> I thought I did
[20:57]  * jdstrand checks again
[20:57] <jdstrand> I certainly meant to
[20:57] <jdstrand> there are no packages pending for review
[21:06] <kyrofa> jdstrand, oh, after the review ran again it was taken out of the manual review queue. Put it again!
[21:06] <kyrofa> Put it in again*
[21:06] <kyrofa> You should see it now
[21:07] <jdstrand> kyrofa: let me run it one more time. please keep an eye on it and ping me
[21:07] <kyrofa> jdstrand, will do
[21:07] <jdstrand> kyrofa: it seems when that review ran it didn't have pind onga's fix
[21:07] <kyrofa> jdstrand, indeed, I think it was before that
[21:12] <kyrofa> jdstrand, much better now: "unsupported cap 'network-listener' security-snap-v2_cap_exists (listener, network-listener) "
[21:13] <jdstrand> kyrofa: cool. can you request a manual review again?
[21:13] <kyrofa> jdstrand, done
[21:15] <jdstrand> kyrofa: done
[21:15] <kyrofa> jdstrand, thank you!
[21:15] <kyrofa> sergiusens, will the u-d-f --install option pull from the store, or does it sideload the app?
[21:28] <kyrofa> sergiusens, nevermind, from the store, awesome
[23:10] <zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/658#discussion_r56430318
[23:11] <zyga-phone> niemeyer: ^^
[23:11] <kyrofa> Huh... ogra_ you're right, u-d-f's --install option doesn't seem to create systemd units. zyga-phone, do you know anything about that?
[23:12] <zyga-phone> kyrofa: which units?
[23:12] <zyga-phone> for services from snaps?
[23:12] <kyrofa> zyga-phone, right
[23:12] <zyga-phone> that's AFAIK expected, snappy does that
[23:12] <zyga-phone> when a snap is activated
[23:13] <kyrofa> zyga-phone, huh... snappy-list doesn't show the snap
[23:13] <kyrofa> zyga-phone, do I have to do something special after creating the image with --install?
[23:13] <zyga-phone> kyrofa: that's different, did you try snap list?
[23:13] <zyga-phone> I don't know
[23:13] <zyga-phone> which u-d-f did you use
[23:13] <zyga-phone> only mvo's custom fork is useful
[23:14] <kyrofa> zyga-phone, yeah, the one from your ubuntu-image
[23:14] <zyga-phone> ok
[23:14] <zyga-phone> hmm, then I don't know, maybe something has changed recently
[23:15] <zyga-phone> this is a very volatile week
[23:16] <kyrofa> zyga-phone, and I have a .mount file for it in /etc/systemd/system... so _something_ happened anyway :P
[23:16] <kyrofa> zyga-phone, okay, I'll ping mvo tomorrow
[23:16] <zyga-phone> oh
[23:16] <zyga-phone> I think we do write .mount files ourselves too
[23:16] <zyga-phone> but I'm not really familiar with how we install snaps using u-d-f
[23:16] <zyga-phone> so yeah, ask mvo perhaps
[23:16] <kyrofa> zyga-phone, no problem, thanks for your thoughts!