| === shuduo-afk is now known as shuduo | ||
| 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 | 04:00 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 07:33 |
| zyga-phone | good morning | 07:52 |
| 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:35 |
| didrocks | dholbach: sure, I'll have a look in 10 minutes | 08:38 |
| dholbach | awesome | 08:38 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | didrocks, did you get to it already? :-P | 10:37 |
| 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:38 |
| dholbach | did you write a mail to the list about it already? | 10:39 |
| dholbach | maybe somebody there can help? | 10:39 |
| didrocks | dholbach: tried already with pitti and mvo, I don't see anyone else better at those systemd issues though | 10:40 |
| 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:47 |
| 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:49 |
| pitti | running it under a minimal environment without $HOME and such | 10:50 |
| 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:10 |
| didrocks | and 6 is /dev/urandom | 11:13 |
| didrocks | pitti: is it something that rings a bell, like systemd preventing access to this socket? ^ | 11:14 |
| 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! | 11:15 |
| kyrofa | Good morning | 12:27 |
| didrocks | good morning kyrofa! | 12:27 |
| kyrofa | Hey didrocks! | 12:27 |
| pindonga | jdstrand, finally, crt @ 606 on prod \o/ | 12:44 |
| jdstrand | pindonga: yay! :) | 13:05 |
| jdstrand | pindonga: thank you :) | 13:05 |
| pindonga | yw | 13:05 |
| 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:06 |
| * jdstrand wonders what versions of the tools ran | 13:07 | |
| jdstrand | 601 | 13:08 |
| * jdstrand runs automated review again | 13:08 | |
| jdstrand | hmm | 13:12 |
| 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:13 | |
| 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:14 |
| 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:15 |
| * 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:16 |
| 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:17 |
| zyga-phone | (I keep saying that) | 13:18 |
| jdstrand | pindonga: python -mjson.tool is happy | 13:18 |
| jdstrand | zyga-phone: nice :) | 13:19 |
| zyga-phone | jdstrand: oh while you are here and I remember | 13:19 |
| 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:20 |
| zyga-phone | jdstrand: let's have a hangout | 13:24 |
| 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:25 |
| 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:26 |
| jdstrand | 30 minutes? | 13:27 |
| zyga-phone | jdstrand: okay | 13:27 |
| plars | elopio: around? | 13:29 |
| plars | elopio: I'm a bit confused by your comment on that PR yesterday | 13:30 |
| 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:31 |
| 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:32 |
| 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:35 |
| 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:36 |
| ogra_ | (i.e. make that check conditional based on what partition table is used) | 13:37 |
| pindonga | jdstrand, nm that.. I'll see to adapt the store's code to cope with non-zero exit codes | 13:38 |
| 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:39 |
| 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:41 |
| zyga-phone | how about we try quickly in 10 minutes? | 13:42 |
| zyga-phone | jdstrand: ^ ? | 13:43 |
| 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:46 |
| 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:48 |
| ogra_ | MBR is a bit more unpleasant than GPT here | 13:49 |
| niemeyer | Hello | 13:53 |
| niemeyer | jdstrand: Aroud? | 13:53 |
| niemeyer | nnnd | 13:53 |
| 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: ^ | 13:59 |
| zyga-phone | jdstrand, niemeyer: ok, see you in the HO | 14:01 |
| niemeyer | Okie dokie | 14:01 |
| 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:07 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| elopio | you are right, I can reopen it. Give me a second to merge it with trunk and test it again. | 14:14 |
| kyrofa | jdstrand, pindonga now the failure says "Unexpected failure while running click-review. click-review" | 14:24 |
| 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:25 |
| 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:26 |
| kyrofa | pindonga, didn't jdstrand say it was because of the network-listener cap though, which is apparently still valid? | 14:27 |
| 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:28 |
| sergiusens | kyrofa, elopio are we standing? | 14:31 |
| kyrofa | sergiusens, yup, on my way | 14:32 |
| 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:33 |
| 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:54 |
| 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:55 |
| kyrofa | jdstrand, ahh, that makes total sense | 14:58 |
| kyrofa | jdstrand, so that snap looks okay then? It can be approved? | 15:01 |
| elopio | plars: you are frozen. | 15:02 |
| * ogra_ sighs about 90+ min turnaround time for a simple fix .... | 15:32 | |
| 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:33 |
| 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:34 |
| 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:53 |
| === chihchun is now known as chihchun_afk | ||
| beuno | pedronis, ^ | 15:55 |
| pedronis | beuno: that's a c assertion | 15:56 |
| 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. | 15:59 |
| sergiusens | kyrofa, yeah, discussed it with ricmm already | 16:00 |
| kyrofa | sergiusens, sweet, happy to hear it | 16:00 |
| ogra_ | sergiusens, oh, btw ... note that i'm working on a script atm that prevents us from fully re-packing the initrd | 16:01 |
| 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:02 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| niemeyer | Yo | 16:16 |
| niemeyer | jdstrand: Okay, thanks for following up on that | 16:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| === shuduo is now known as shuduo-afk | ||
| jdstrand | well, we are a bit outside of convention here | 16:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| fgimenez | elopio, it seems that we need more executors :D http://162.213.35.179:8080/ | 16:42 |
| elopio | I wonder why those unit tests are so slow when we build the deb. | 16:43 |
| 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:44 |
| 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:53 |
| 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:55 |
| 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 | 16:57 |
| 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:00 |
| 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:01 |
| 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:04 |
| pindonga | elopio, ogra_ we don't yet support publishing via the api | 17:06 |
| 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:07 |
| 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:08 |
| code1o6 | Hello guys | 17:12 |
| 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:13 |
| zyga-phone | jdstrand: ack, thank you for the explanation | 17:21 |
| ogra_ | stevebiscuit, is it known that webdm doesnt auto-start after reboot anymore ? | 17:22 |
| 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:23 |
| elopio | ogra_: why is it that we don't have usb networking but debian has? | 17:26 |
| ogra_ | elopio, gadget you mean ? | 17:26 |
| 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:28 |
| elopio | ogra_: and that's the kind of things that we would put in the gadget snap, right? | 17:29 |
| 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:30 | |
| ogra_ | Chipaca, mvo, bug 1558181 and bug 1558179 for you guys ... | 17:33 |
| ubottu | bug 1558181 in Snappy "services are not started on boot anymore" [Undecided,New] https://launchpad.net/bugs/1558181 | 17:33 |
| ubottu | bug 1558179 in Snappy "snappy list does not show webdm anymore, while sudo snappy list does" [Undecided,New] https://launchpad.net/bugs/1558179 | 17:33 |
| 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:46 |
| stevebiscuit | ogra_: Chipaca knows the finer details of the Go/avahi trouble I think | 17:47 |
| ogra_ | k | 17:48 |
| ogra_ | i havent seen any discussions here | 17:49 |
| stevebiscuit | ogra_: the discussion was in the #snappy-devel Telegram channel if you want to join that | 17:50 |
| ogra_ | stevebiscuit, no, i dont | 17:54 |
| ogra_ | that excludes everyone | 17:54 |
| zyga-phone | ogra_: I know more about webdm issue | 17:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 | |
| 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) | 17:59 |
| 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:00 |
| 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:01 |
| zyga-phone | I don't know, do you work like that? | 18:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| enoch85 | so basically kyrofa I'll check if the app works standalone, and then talk to you about how to integrate it, right? | 18:16 |
| 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:17 |
| kyrofa | enoch85, yeah, sounds good | 18:19 |
| kyrofa | pindonga, alright thank you! I'll check it out when I've rebuilt | 18:20 |
| enoch85 | kyrofa: +1 :) | 18:23 |
| Mr_Cake | Hello guys | 18:26 |
| code1o6 | Hi | 18:27 |
| 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:18 |
| 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:19 |
| pindonga | :) | 19:20 |
| 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:21 |
| kyrofa | jospoortvliet, sounds good :) | 19:26 |
| mvip | hey manik. How are things? | 19:29 |
| manik | hey mvip | 19:29 |
| manik | mvip: i am good, how are you? | 19:29 |
| 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:30 |
| mvip | manik: Great. Full house. Lots of cool DIY projects. | 19:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| manik | its a little early to say honestly | 19:38 |
| manik | let me find out where we are and circle back | 19:38 |
| mvip | manik: thanks. that's probably the most important issue for us. | 19:39 |
| manik | sure | 19:40 |
| ogra_ | mvo, nope, properly networked | 19:55 |
| mvo | ogra_: hm, hm | 19:56 |
| ogra_ | mvo, it is a dragonboard ... so wlan ... might be that starts a bit later than wired | 19:57 |
| ogra_ | (or slower) | 19:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| mvo | could be, little has changed in this particular area though recently | 20:04 |
| 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:05 |
| 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:09 |
| 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:10 |
| 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:12 |
| ogra_ | thats the snap.yaml that got installed | 20:13 |
| 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:14 | |
| 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:15 |
| jdstrand | I suggest someone look at what systemd is doing | 20:16 |
| 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:17 |
| * ogra_ wishes snap find wouldnt be full of false positives | 20:19 | |
| ogra_ | anyway ... back to doing evening stuff :) | 20:19 |
| kyrofa | Ah ogra_ ... you're so very helpful to me. Thank you for your help on the writable stuff. It works perfectly | 20:22 |
| mvo | ogra_: uh, that should work | 20:39 |
| mvo | ogra_: its all going downhil | 20:39 |
| * mvo goes to bed | 20:39 | |
| kyrofa | jdstrand, did you get a chance to approve that owncloud snap by any chance? | 20:54 |
| 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 | 20:57 |
| 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:06 |
| 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:07 |
| kyrofa | jdstrand, much better now: "unsupported cap 'network-listener' security-snap-v2_cap_exists (listener, network-listener) " | 21:12 |
| jdstrand | kyrofa: cool. can you request a manual review again? | 21:13 |
| kyrofa | jdstrand, done | 21:13 |
| 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:15 |
| kyrofa | sergiusens, nevermind, from the store, awesome | 21:28 |
| zyga-phone | jdstrand: https://github.com/ubuntu-core/snappy/pull/658#discussion_r56430318 | 23:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| zyga-phone | this is a very volatile week | 23:15 |
| 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! | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!