| === nyx_ is now known as kjar | ||
| zyga | hello | 07:54 |
|---|---|---|
| dholbach | good morning | 08:02 |
| noizer | good morning | 08:50 |
| JamesTait | Good morning all! Happy Tuesday, and happy Pancake Day! 🙌 | 09:32 |
| diwic | JamesTait, good morning! What do I need to install to see that unicode character? It is not visible on OOTB Ubuntu 14.04, at least. | 09:33 |
| JamesTait | diwic, you're not the first person to ask, but I still don't know the answer. I might have had to install a specific font for it, not sure. | 09:34 |
| dholbach | diwic, fonts-symbola? | 09:34 |
| dholbach | I searched for it in gucharmap and right-clicked on it | 09:34 |
| JamesTait | dholbach, that does sound familiar, actually. | 09:35 |
| dholbach | mh... then I don't know :) | 09:35 |
| diwic | dholbach, thanks, but I can't find fonts-symbola in the archive...? | 09:35 |
| dholbach | diwic, I'm on xenial | 09:36 |
| JamesTait | In fact I think someone on IRC told me to install that, let me check my logs. | 09:36 |
| dholbach | Description: symbolic font providing emoji characters from Unicode 7.0 | 09:36 |
| JamesTait | ttf-ancient-fonts-symbola? | 09:36 |
| diwic | interesting, it appears on vivid and nothing below that | 09:37 |
| dholbach | that's what it provides in 16.04, yes | 09:37 |
| dholbach | 14.04 is pre-emoji times | 09:37 |
| diwic | heh | 09:37 |
| diwic | maybe I can just install the .deb from vivid and hope for the best :p | 09:38 |
| diwic | it worked! \o/ thanks dholbach and JamesTait | 09:41 |
| JamesTait | Woohoo! 🙌 | 09:42 |
| dholbach | :) | 09:42 |
| diwic | or should I say 🙌 | 09:42 |
| diwic | oh well, now on to figuring out how to make snapcraft generate correct security profiles | 09:43 |
| opny | Hello! After a bit of hassle, I've been able to get running Snapcraft 2.1 on Xenial. I've noticed however the jdk plugin fails now, is this a known issue? | 09:46 |
| dholbach | opny, fails how? | 09:49 |
| opny | dholbach, http://paste.ubuntu.com/15000971/ | 09:51 |
| dholbach | opny, I can't find any bug report for it at https://bugs.launchpad.net/snapcraft | 09:52 |
| opny | dholbach, is it an implicit request? | 09:53 |
| dholbach | opny, you asked if it was a known issue :) | 09:53 |
| dholbach | I'm just playing around with the java related examples to see if I can reproduce anything | 09:53 |
| dholbach | so the java-hello-world example works for me too | 09:54 |
| dholbach | trying the tomcat example now | 09:54 |
| opny | dholbach, :) ok.. If you mind I have a github repository for that snap I'm looking to build | 09:54 |
| dholbach | cool - have a link? | 09:55 |
| opny | dholbach, https://github.com/muka/kura.snap (Let me a moment to push current status) | 09:55 |
| dholbach | cool, let me know once you're done | 09:57 |
| opny | dholbach, ok done | 09:58 |
| dholbach | taking a look now | 10:00 |
| dholbach | opny, I can't reproduce the problem | 10:02 |
| opny | dholbach, uhm ok thank you for checking. May be the case I'm using a mount in virtualbox, will try to move it out | 10:04 |
| dholbach | maybe you can run snapcraft clean and start over? it looks like an apt problem | 10:04 |
| dholbach | maybe... *shrug* | 10:04 |
| dholbach | first I thought "maybe a part can't have the name of a snapcraft plugin", but that seemed irrelevant | 10:04 |
| dholbach | then I saw that build-packages should probably be stage-packages | 10:05 |
| dholbach | (if you want to bundle things in your snap, as opposed to making sure that certain packages are installed on the machine where you're building the snap) | 10:05 |
| opny | dholbach, build vs stage packages is a recurring topic for me :) Yes, stage is the appropriate one! | 10:06 |
| dholbach | :) | 10:06 |
| opny | dholbach, moving out of shared folder worked.. thanks | 10:11 |
| dholbach | excellent :-D | 10:12 |
| asac | elopio: running unit snapcraft tests on master cant find the storeapi etc... i use ./runtests.sh unit | 10:18 |
| asac | ok seems thats xenial only | 10:26 |
| * zyga pushed https://github.com/ubuntu-core/snappy/pull/468 | 10:54 | |
| opny | Hi, in snapcraft can I specify a git branch to pull? | 11:03 |
| dholbach | opny, yes - take a look at examples/godd/snapcraft.yaml | 11:04 |
| opny | dholbach, thank you | 11:05 |
| opny | dholbach, I do not see any branch ref https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml#L15 | 11:10 |
| opny | dholbach, Is it like url#branch ? | 11:10 |
| dholbach | opny, use source-branch | 11:41 |
| dholbach | (type: snapcraft help sources) | 11:48 |
| * zyga pushed big security part of skills for review | 11:50 | |
| zyga | https://github.com/ubuntu-core/snappy/pull/468 | 11:50 |
| zyga | elopio: do you know why some integration tests fail on all the branches (3 out of 58) | 11:51 |
| fgimenez | zyga, that was fixed with https://github.com/ubuntu-core/snappy/pull/467, if you rebase to the tip of master all should be fine | 12:06 |
| zyga | fgimenez: ah, thanks | 12:21 |
| zyga | fgimenez: I should stop being lazy and use my VPN :) | 12:21 |
| === vrruiz_ is now known as rvr | ||
| kyrofa | Good morning | 13:17 |
| didrocks | hey kyrofa! | 13:17 |
| kyrofa | didrocks, hey there! Good day so far? | 13:17 |
| didrocks | kyrofa: so far, yeah :-) | 13:18 |
| didrocks | how are you? | 13:18 |
| kyrofa | I'm doing pretty well-- my son has been sleeping kinda bad, which means I have been too :P | 13:18 |
| didrocks | argh, yeah, coffee time I guess then! :-) | 13:19 |
| kyrofa | Oh yes ;) | 13:20 |
| ogra_ | ppisati, hmm, is the "linux-snapdragon" you uploaded this morning usable on the dragonboard already ? | 13:21 |
| ppisati | ogra_: nope | 13:22 |
| ogra_ | k, thx | 13:22 |
| opny | hi, snapcraft fails while doing its own apt-get update with a "Hash Sum mismatch". I've edited the sources.list to point to other archives but snapcraft still tries to use the old one | 14:05 |
| kyrofa | opny, that's usually a temporary error with the archives | 14:06 |
| kyrofa | opny, just try again in a few minutes | 14:06 |
| opny | kyrofa, thanks, however, this is making me go crazy! | 14:07 |
| kyrofa | opny, yeah it kills our CI tests every once in a while too | 14:07 |
| opny | kyrofa, I have a sed thing to switch around countries and have it working. This work for apt-get but not for snapcraft | 14:08 |
| kyrofa | You know you're OCD when you realize you have a thousand tabs open and just close the browser completely to start over | 14:12 |
| ogra_ | the bad thing is that over time you end up with all these "session restore" tabs that pile up :P | 14:16 |
| kyrofa | ogra_, hahaha | 14:17 |
| kyrofa | ogra_, but those only come up if it exits inappropriately, though | 14:17 |
| ogra_ | well, depends if you actually want that (i have occasions where i just want to archive the tabs and start over to save ram... and kill -9 ...) | 14:18 |
| kyrofa | ogra_, ha! | 14:20 |
| JamesTait | So glad to know I'm not the only one who has that problem. | 14:22 |
| kyrofa | JamesTait, which one, slaughtering firefox to archive your tabs, or OCD? | 14:23 |
| JamesTait | kyrofa, just the "ZOMG, I have 7 Firefox windows with 54 tabs in each, how did this happen?" problem. | 14:24 |
| kyrofa | JamesTait, ah, yes exactly. "Kill them all! Go away! I don't care what I was in the middle of doing, I can't keep track of all this!" | 14:25 |
| JamesTait | And they're killing tab groups! | 14:25 |
| JamesTait | So instead I made an attempt to organise things into bookmark folders, and then "open all in tabs" when I want to work on something specific. | 14:26 |
| JamesTait | With varying degrees of success.... | 14:26 |
| kyrofa | Interesting idea | 14:26 |
| JamesTait | I'm still trialling it. It's taking some time to get used to and to be disciplined about. | 14:27 |
| kyrofa | elopio, I'm assuming you can't hear me :P | 14:33 |
| jdstrand | dholbach: hi! would you mind looking at my response to your comment to my MP? | 14:35 |
| kyrofa | elopio, if you have headphones in, and aren't hearing me... what you are listening to? Are you muted and just have headphones on? | 14:35 |
| dholbach | jdstrand, I'm in calls for the next hour, but could take a look later on | 14:36 |
| kyrofa | elopio, so this is creepy. I'll get out so I don't feel like I'm spying on you :P . Ping me when you're ready? | 14:36 |
| kyrofa | Ping timeout... that might explain some things | 14:37 |
| kyrofa | elopio, you there now? | 14:40 |
| JamesTait | jdstrand, I just re-merged that branch locally and get the same, but I didn't see it yesterday. Not sure what changed since then. | 14:41 |
| elopio | kyrofa: I can't see you. | 14:41 |
| elopio | nor hear you. | 14:41 |
| kyrofa | elopio, yeah that was several minutes ago now. Let me hop back in | 14:41 |
| JamesTait | jdstrand, are there any plans (is it even possible) to split the MP into smaller chunks? 10k lines is a lot to review. ☺ | 14:42 |
| elopio | several minutes ago it also appeared that I was alone. | 14:42 |
| kyrofa | Creepy | 14:44 |
| zyga | jdstrand: hey :) | 14:45 |
| plars | elopio: for the testconfig.json needed by the integration tests, what's the bare minimum we need to make it run? | 14:48 |
| plars | elopio: also, do the values in it really affect the tests that run? | 14:48 |
| jdstrand | JamesTait: well, I could remove some of the sr_ bits | 14:49 |
| jdstrand | JamesTait: but the problem is that it will be large because it is a refactor | 14:50 |
| jdstrand | well, in part | 14:50 |
| jdstrand | zyga: hi :) | 14:50 |
| jdstrand | I did write a ton of new tests for snap.yaml which are adding to the length | 14:51 |
| JamesTait | jdstrand, yeah, I noticed that, and I'm thankful. ☺ | 14:52 |
| JamesTait | jdstrand, I've been looking at individual commits to try and make the diff smaller. I just wondered if there was a neat way to split "this factors out the common stuff but maintains feature parity" from "this starts adding snappy 2.0 specific functionality". | 14:53 |
| elopio | plars: I think now it will just affect the update tests. | 14:54 |
| elopio | oh well, after a couple of my branches land, that simplify things. | 14:54 |
| elopio | I need to check in detail if we still need it. | 14:54 |
| JamesTait | jdstrand, fwiw I've been throwing lots of files at the refactored version and haven't noticed any obvious problems. | 14:55 |
| kyrofa | elopio, ... it's an invalid python syntax thing?! | 14:55 |
| jdstrand | JamesTait: well, I can probably do that if is do the refactor, then pull out the 16.04 tests from cr_*, then add the 16.04 sr_* tests. the problem is, that is going to take me a while to make those 3 commits committable since the refactor happened rather organically since I didn't know what needed refactoring until I got into it | 14:56 |
| jdstrand | JamesTait: but, if that is going to help with the review, I can take the time to do that | 14:56 |
| plars | elopio: these branches will make it so that all the tests don't try to need that json file? | 14:56 |
| elopio | plars: no, I think we'll still need it. | 14:57 |
| jdstrand | JamesTait: re lots of files-- yeah, as part of the testing I plan to run all the snaps through the tools in the old and new versions and do a compare (like I've done with other big changes) | 14:57 |
| elopio | I'm just not 100% sure why. It had like three functions. I removed one. | 14:57 |
| elopio | kyrofa: that's what it says, but it's valid syntax. | 14:58 |
| jdstrand | but as I've been going I've been doing various spot checks | 14:58 |
| jdstrand | JamesTait: thanks for the testing | 14:58 |
| elopio | kyrofa: ah, it could be missing the quotes. | 14:59 |
| plars | elopio: ok, we're trying to run these tests under checkbox, and it's complaining about not having that file. I'm trying to see if there's a way to just avoid it, or if we should just put a stub file there to make it happy, or if we need to generate the real thing | 14:59 |
| kyrofa | elopio, yeah running that command here doesn't work, though it exits with a shell error, not a python error | 14:59 |
| elopio | plars: you need to generate the real thing. | 14:59 |
| JamesTait | jdstrand, yeah, I understand. ☺ I've been there enough times myself! On the one hand I'd like to do a thorough review of all the changes, on the other hand we'd like to get this landed sooner rather than later. | 14:59 |
| elopio | plars: I'm with you all morning today. Just give me a second to get ready. | 15:00 |
| plars | elopio: no rush, I am off to a standup anyway | 15:00 |
| jdstrand | JamesTait: ok, I will focus on finishing the TODO for this so at the very least, reviewers can run this branch locally on snaps that are flagged for manual review. that will make sure there isn't any more refactoring (it's possible I'll have more for the security bits). then I can look into breaking this up into review parts | 15:02 |
| jdstrand | dholbach, JamesTait: weird, if I bzr branch anew and the run-tests, it passes | 15:03 |
| jdstrand | dholbach, JamesTait: the new check_snappy_readme_md() just doesn't use is_squashfs anymore... not sure why it is that way for you guys | 15:03 |
| JamesTait | jdstrand, interesting - I just did that and it worked for me as well. | 15:04 |
| jdstrand | dholbach, JamesTait: do you guys need to do 'make clean'? | 15:04 |
| * JamesTait does that just to be sure. | 15:04 | |
| JamesTait | Nope, that still failed. :-/ | 15:05 |
| jdstrand | diff -Naur -x .bzr ./existing ./newcheckout | 15:06 |
| jdstrand | might be interesting | 15:06 |
| dholbach | jdstrand, still fails here - I checked 'bzr {diff,ignored,unknowns}' to have no output... not sure what else to do | 15:06 |
| jdstrand | it is a mystery, but if I am breaking this up into 3 different parts, then perhaps looking into why it is a problem now is probably not the best use of our time | 15:08 |
| JamesTait | Weird, this is the same branch that was passing for me last week. | 15:08 |
| jdstrand | dholbach, JamesTait: you you both on xenial? I am, though I haven't updated in a few days | 15:08 |
| JamesTait | I'm not - still on Wily. | 15:09 |
| dholbach | yes, on xenial, up to date | 15:09 |
| jdstrand | heh | 15:09 |
| dholbach | hah, a new checkout works | 15:09 |
| jdstrand | so, probably not xenial specific | 15:09 |
| dholbach | that'S bizarre | 15:09 |
| JamesTait | Yeah, odd. | 15:09 |
| jdstrand | ok, I'm not going to worry about this. I'll keep pushing to the big branch, then I'll break up into smaller branches later | 15:10 |
| jdstrand | if there is a problem then, we'll dive in | 15:10 |
| JamesTait | Thanks, jdstrand! | 15:11 |
| dholbach | jdstrand, I think I know what the problem is - maybe we have a backed-out change in lp:click-reviewers-tools? | 15:11 |
| dholbach | jdstrand, http://paste.ubuntu.com/15002261/ | 15:12 |
| dholbach | or rather: http://paste.ubuntu.com/15002273/ | 15:14 |
| === nyx__ is now known as kjar | ||
| JamesTait | dholbach, I see http://paste.ubuntu.com/15002276/ | 15:15 |
| JamesTait | Aha! | 15:16 |
| JamesTait | Heh. ☺ | 15:16 |
| dholbach | :-D | 15:16 |
| diwic | jdstrand, hi, want to chat about PulseAudio on snappy? | 15:16 |
| * tedg watches, he wants to define new skills too | 15:17 | |
| * JamesTait defines the new skill Time Travel. | 15:17 | |
| kyrofa | JamesTait, I didn't know Apple was bring Time Machine to Ubuntu Core! | 15:18 |
| jdstrand | dholbach, JamesTait: are your branches up to date with trunk? | 15:19 |
| JamesTait | kyrofa, you should see it - it's magical! 😝 | 15:19 |
| dholbach | jdstrand, yes | 15:19 |
| jdstrand | diwic: give me just a minute | 15:19 |
| diwic | the "kill daemons" skill sounds like it could fit in an RPG style game | 15:19 |
| JamesTait | Seems to be. | 15:19 |
| tedg | Honestly, that would be a sweet snap. Have it come on a device with a HDD or put it on your server. | 15:19 |
| diwic | jdstrand, sure | 15:19 |
| jdstrand | cause, I'm at r572 in my trunk | 15:20 |
| dholbach | jdstrand, are there any previously backed-out changes that might confuse bzr during the merge? | 15:20 |
| jdstrand | I think I didn't merge 569 and later into the cleanup branch | 15:21 |
| * JamesTait wonders what on earth he did to have this working locally. | 15:21 | |
| JamesTait | Probably not a make clean. :-/ | 15:21 |
| JamesTait | Bah, school run time. | 15:22 |
| jdstrand | but I just tried to merge with trunk and it came back clean | 15:22 |
| jdstrand | ok, pulling in as cherrypicks | 15:22 |
| jdstrand | and I can reproduce | 15:23 |
| jdstrand | let me fix that and push | 15:23 |
| jdstrand | dholbach, JamesTait: ^. thanks for helping me figure that out | 15:23 |
| dholbach | glad it's going to be fixed soon :-) | 15:24 |
| jdstrand | dholbach, JamesTait: ok, pushed | 15:28 |
| jdstrand | diwic: ok | 15:28 |
| diwic | jdstrand, ok, so what's currently blocking me is access to /dev/snd/* | 15:29 |
| dholbach | jdstrand, confirming the fix :) | 15:29 |
| jdstrand | diwic: are you on 15.04 or 16.04? | 15:29 |
| diwic | jdstrand, 16.04, just upgraded to the latest skill-based images | 15:30 |
| jdstrand | diwic: ok, things may be a bit rough atm as the skills work is mid-implementation | 15:30 |
| jdstrand | diwic: let me check something | 15:30 |
| diwic | jdstrand, to the extent that you think I should defer the snappy work and go do something else and come back in a week or two? | 15:31 |
| kyrofa | elopio, I can't duplicate that ROS error locally | 15:31 |
| jdstrand | diwic: alright, since /dev/snd devices aren't implemented as skills yet, hw-assign is what you need to use, and it is still available on 16.04 | 15:31 |
| kyrofa | elopio, I'm really not sure what's happening there | 15:31 |
| jdstrand | diwic: sudo snappy hw-assign foo.sideload /dev/snd/* | 15:31 |
| diwic | jdstrand, ok, let me see if that works | 15:32 |
| elopio | kyrofa: ok, I can try to debug in a docker that's the same as the slave. | 15:32 |
| jdstrand | diwic: well, we're going to need to understand what pulse needs in order to create the skills for it. I'm confident we can get you unblocked such that we have enough information for developing those skills | 15:33 |
| kyrofa | elopio, alright. That call happens via a subprocess.check_output, so there should be no problems with the quotes | 15:33 |
| kyrofa | elopio, I suspect the syntax error is a red herring | 15:33 |
| diwic | jdstrand, cool. Feel free to ping me if you have further questions about what pulse needs - the hwassign thing does seem to work. | 15:33 |
| diwic | jdstrand, how does hw-assign work internally, btw? | 15:34 |
| diwic | jdstrand, is it related to acls somehow? | 15:34 |
| jdstrand | diwic: great. really, if you have a working snap, I just need it or the link to the branch | 15:34 |
| jdstrand | diwic: yes. if the specified files are in /sys, then you get apparmor rules, if in /dev, the device gets added to an app-specific cgroup | 15:35 |
| jdstrand | diwic: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement | 15:35 |
| diwic | jdstrand, cool, thanks. I'll need to work some more on the snap - now that I know how to deal with /dev/snd/ - to make sure the sound card loads correctly | 15:37 |
| * diwic unblocked | 15:37 | |
| jdstrand | \o/ | 15:38 |
| jdstrand | dholbach: did it work for you? | 15:49 |
| dholbach | jdstrand, yes | 15:50 |
| dholbach | <dholbach> jdstrand, confirming the fix :) | 15:50 |
| tedg | jdstrand: But won't diwic need to provide a skill for applications to use? I don't understand how he does that. | 15:50 |
| tedg | jdstrand: Seems he'll need to put some apparmor configuration inside his snap. | 15:50 |
| jdstrand | dholbach: ah, I took 'confirming' as you were in the process of confirming it and would get back to me. thanks! | 15:50 |
| dholbach | ah, sorry :) | 15:50 |
| dholbach | so, yes - fixed, all good! :-D | 15:51 |
| jdstrand | tedg: that part of the discussion has been deferred since he is unblocked | 15:51 |
| jdstrand | tedg: but the general idea is this | 15:51 |
| jdstrand | tedg: people have something that needs to use skills that aren't yet defined. in this case, he needed /dev/snd and mayve some udev stuff | 15:52 |
| jdstrand | tedg: comes to snappy team, decide if the skill is worthwhile. if it is, define a skill type and the security policy, and add to snappy | 15:52 |
| jdstrand | tedg: then the app can 'uses' the skill | 15:52 |
| tedg | jdstrand: That clearly doesn't scale. | 15:52 |
| JamesTait | jdstrand, dholbach - thanks! | 15:53 |
| diwic | pulseaudio clients don't need /dev/snd, only the pulseaudio server does. | 15:53 |
| tedg | jdstrand: And what you're saying is that snappy hardcodes the path to the pulse socket. When in reality, it should be pulse defining that. So if it is "foo" today and "foo1" tomorrow, that's defined in the relationship between the provider and the slot. | 15:54 |
| jdstrand | tedg: then if the app is going to provide skills, they use existing types to declare what it provides. so, in this case, a socket and a dbus interface. snappy understands these skill types (eventually) and will dynamically create security policy for apps that 'uses' them | 15:54 |
| tedg | jdstrand: It shouldn't be dependent on a specific version of snappy. | 15:54 |
| jdstrand | tedg: no, not what I'm saying | 15:54 |
| jdstrand | tedg: there were two parts | 15:54 |
| jdstrand | there is what pulse needs from the system that is different from what is already there | 15:55 |
| jdstrand | and there is what pulse can provide to other snaps | 15:55 |
| tedg | Sure, I'm worried about the second. | 15:55 |
| jdstrand | the first part will be a smallish set of skills | 15:55 |
| jdstrand | that is what I described | 15:55 |
| jdstrand | the second part is a smallish set of skill *types* that are configurable by the providing snap | 15:55 |
| jdstrand | eg, lets say for simplicity there is a dbus skill type | 15:56 |
| jdstrand | snappy knows about this skill type | 15:56 |
| jdstrand | pulse snap fills in attributes for this skills type so that snappy can do stuff on the fly | 15:56 |
| jdstrand | pulse provides a pulse skill to the system | 15:57 |
| jdstrand | apps 'uses' this pulse skill | 15:57 |
| tedg | Okay, I'm good with that, but then what does the app specify? All the parameters for dbus? | 15:57 |
| jdstrand | tedg: what attributes pulse can set in its snap skill declaration for dbus is TBD | 15:58 |
| jdstrand | tedg: bluez, pulse and nm are three snaps we can look at to help define what a dbus skill or set of skills will look like | 15:59 |
| tedg | Seems like a big TBD, as that's kinda the core of how they integrate with each other. | 15:59 |
| diwic | side note: pulseaudio uses unix sockets as primary IPC mechanism | 15:59 |
| tedg | Unfortunately none of those deal with things like AppIDs being part of the dbus path, which is important for us on the phone. | 16:00 |
| jdstrand | diwic: yes, we have 'socket' right now for that, but there will be some sort of transition to skills for that aiui (which is TBD) | 16:00 |
| tedg | It would be nice to add a case of that as well. | 16:00 |
| jdstrand | diwic: and the 'socket' options support both file and abstract sockets | 16:01 |
| diwic | jdstrand, in snapcraft terms, where should I add 'socket' ? | 16:01 |
| diwic | i e where in snapcraft.yaml | 16:01 |
| jdstrand | tedg: today on snappy there is only a singular 'bus-name' (eg, org.freedesktop.pulseaudio) | 16:02 |
| * ogra_ curses | 16:02 | |
| jdstrand | diwic: alongside 'command' under 'apps' | 16:02 |
| ogra_ | root@anubis:/# snappy build --squashfs snap/ | 16:02 |
| ogra_ | 2016/02/09 16:02:18.472075 main.go:40: WARNING: can not create syslog logger | 16:02 |
| ogra_ | open snap/meta/snap.yaml: no such file or directory | 16:02 |
| jdstrand | diwic: see docs/meta.md in the snappy git tree | 16:02 |
| tedg | jdstrand: So, in general, I agree that this overall approach makes sense. But when I said that on the list, zyga said that is incorrect. | 16:02 |
| jdstrand | tedg: but this was far too limiting on two fronts: bluez listens on more than one bus-name and there was no way to define dbus bus policy | 16:03 |
| tedg | jdstrand: The problem is that is the "easy case" — where there is less interaction and negotiation that is needed. We need to tackle the hard cases too. | 16:03 |
| diwic | jdstrand, in 16.04 too? | 16:04 |
| jdstrand | tedg: so the skills work will need to accommodate that. note, I said for the simple case there is a skills type of 'dbus'-- I don't know if that will be more specific or not | 16:04 |
| jdstrand | diwic: yes | 16:04 |
| tedg | jdstrand: Before feature freeze next week? ;-) | 16:05 |
| jdstrand | tedg: now, in terms of APP_ID, that shouldn't be a hard problem. only 'trusted helpers' need to know about APP_ID's. app templated policy won't really have to change here and the trusted helper will only need security policy to allow looking at its own path, etc. it should basically work, but there might be some fine-tuning (possibly an additional skill for trusted helpers, but I doubt it). I don't see a big issue there | 16:06 |
| jdstrand | tedg: this is snappy, feature freeze isn't until May :P | 16:06 |
| noizer | hi, short question. is ASCII not support by a snap? | 16:07 |
| noizer | because i get the following error with my uwsgi LookupError: no codec search functions registered: can't find encoding | 16:07 |
| tedg | jdstrand: Sure, there could be another simple type, but we're startting to add a lot of simple types then. | 16:08 |
| tedg | jdstrand: I'm worried we're only covering the trivial cases and not specing out the complex ones early enough. The format doesn't seem like it can handle the complex cases and is becoming more and more difficult to chagne. | 16:09 |
| jdstrand | tedg: I personally worry about the number types exploding. on touch we tried to keep that low. in snappy 15.04 we did the same. in snappy 16.04 and skills, people said this wasn't a problem and that is the path forward | 16:10 |
| jdstrand | tedg: types are actually supposed to be pretty easy to add | 16:10 |
| tedg | jdstrand: I *think* the hooks are going to need richer communication with the security frameworks, which is harder to add. It's hard to see with the current state of things though. | 16:11 |
| jdstrand | and 16.04 is only supposed to have a smallish number of easily understood types so that we can learn from them to do more complex ones | 16:11 |
| jdstrand | tedg: mapping click hooks to snappy is not on anyone's 16.04 todo list afaik | 16:12 |
| tedg | I'm fine as long as "smallish" is "everything we need for phone" :-) | 16:12 |
| tedg | jdstrand: It is on my todo list, but I can't figure out enough info to make anything other than a shot in the dark. | 16:12 |
| jdstrand | tedg: I though 'Personal' work was not for 16.04. did that change? | 16:13 |
| jdstrand | also, while I am speaking rather authoritatively here, skills are Gustavo's and zyga's baby-- I'm only providing input for the security bits and bringing up other things as needed (ie, I'm thinking about touch too) | 16:14 |
| tedg | jdstrand: Getting snaps so they could be installed on desktop or phone is a desirable feature, and we'd want those snaps to work into the future. So "personal" is not, but getting apps that will work for personal is. | 16:15 |
| fgimenez | elopio, sorry, don't know how i ended in the internal channel :D | 16:18 |
| jdstrand | tedg: I think getting leaf desktop snaps will be fine. that is different from a trusted helper and different than a click with lots of hooks, both I interpreted in the realms of 'Personal' | 16:20 |
| tedg | jdstrand: Certainly desktop is easier than phone, but while no one has decided anything, phone apps are on the table still as well. | 16:23 |
| zyga | jdstrand: I refreshed bool-file skill, would love if you can have a 2nd look at the security side | 16:24 |
| elopio | fgimenez: I think this is ready: https://github.com/ubuntu-core/snappy-jenkins/pull/72 | 16:25 |
| fgimenez | elopio, thx let's merge after travis finishes | 16:27 |
| jdstrand | zyga: ack-- saw it, haven't gotten out of irc questions yet :) | 16:27 |
| zyga | jdstrand: thanks, if you have any questions about it we can also talk on irc | 16:31 |
| jdstrand | ok | 16:32 |
| JamesTait | jdstrand, what gotchas would I need to look out for if I wanted to use click-reviewers-tools as a library in the Store, rather than shelling out to a subprocess? Is there a stable public API? | 16:37 |
| jdstrand | JamesTait: I think to do that well, we'd want to break what is in click-review out into a library and have that be the api. then click-review and you could use that | 16:43 |
| * JamesTait nods | 16:43 | |
| jdstrand | JamesTait: click-review itself has been very stable and not changed much (until this cleanup branch) | 16:43 |
| jdstrand | so I think breaking out those bits would provide a good api | 16:44 |
| JamesTait | It's not something I'm looking to do immediately, unless it turns out to be so trivial it'd just fit into existing work, but as a future path I think it'd be preferable. | 16:45 |
| plars | elopio: I think it looks like we won't need much (anything?) in that json file if we aren't using the update/rollback tests, but it will still error if it can't read the file. So we can stub one, but it seems to read from a hardcoded relative path, that picks up its base path from the GOPATH on the build system | 16:47 |
| plars | elopio: would a parameter for this testconfig path be ok to add? | 16:48 |
| plars | elopio: or do you have a better suggestion | 16:48 |
| JamesTait | jdstrand, also, this is totally work that I'd expect the Store team to take on - just to be clear. 😉 | 16:48 |
| jdstrand | ack | 16:49 |
| elopio | plars: it's only used for update, rollback and the info_test. | 16:49 |
| elopio | I'm not sure if you want to run the info test. | 16:49 |
| elopio | if you don't want anything to do with it, I can catch the file not existent error, and put a default config. | 16:49 |
| JamesTait | We've got a Trello card open for it, I'm just going to add some thoughts to it for now and we'll see where it fits in. | 16:50 |
| plars | elopio: but all tests try to read it: Error reading config: open integration-tests/data/output/testconfig.json: no such file or directory | 16:50 |
| jdstrand | makes sense | 16:50 |
| elopio | plars: yes, because all tests check if they are in the middle of an update or rollback. | 16:50 |
| elopio | I can put a default false in there. | 16:51 |
| plars | elopio: or we could probably just generate a json file with "{}" in it right? | 16:51 |
| elopio | plars: I'm not sure what will happen in that case. Maybe json.Unmarshal sets default values, or maybe it fails because of the missing fields. | 16:52 |
| elopio | plars: but there's something more important to solve here. | 16:52 |
| elopio | that integration-tests/data/ path is important, not just for the config. All the test snaps are in there. | 16:53 |
| elopio | so it's not just the binary what you need. You also need the test data. | 16:53 |
| plars | elopio: oh, so it's not enough just to ship the test binary, there's other data there too it needs? | 16:53 |
| plars | got it | 16:53 |
| elopio | yes. The config is not too important now. But the others are. | 16:54 |
| elopio | plars: can you try creating that testconfig.json to see if the binary finds it? | 16:54 |
| plars | elopio: I see that now... elopio but those don't get built when I build the integration tests with go test -d | 16:54 |
| plars | err.. -c | 16:55 |
| elopio | nop. Just the code goes into the binary, no data files. | 16:55 |
| plars | elopio: yeah, we'll give that a try. What will I need to force it to build all those other snaps? and will they need to be in that exact directory structure? | 16:56 |
| olli_ | ho | 16:57 |
| elopio | plars: you don't need to build the snaps, they are build during the tests. You can't include them in the binary, afaik. You'll have to copy them to the testbed, as we do here with adt-run. | 16:57 |
| olli_ | I love xchat and how it moves keyboard input between channels when starting up | 16:57 |
| fgimenez | elopio, this is done https://hub.docker.com/r/ubuntucore/snappy-jenkins-slave-xenial/builds/ we can build the new base image now | 16:57 |
| elopio | fgimenez: let me first re-run the tests on my branch and merge it. | 16:57 |
| fgimenez | elopio, the error from travis should be fixed with the latest changes too, ok | 16:58 |
| kyrofa | olli_, so you don't actually know where you pinged unless you look through them all? Yeah I love that too | 17:09 |
| === retrack is now known as Guest58434 | ||
| jerryG | Chipaca: have you done a coredump ? | 17:49 |
| jdstrand | beuno, matiasb: I just uploaded snappy-debug to the store for rolling only, and 'snap find snappy-debug' doesn't see it. is this because the device is not authenticated with the store? | 18:24 |
| jdstrand | beuno, matiasb: it is published afaics | 18:25 |
| plars | elopio: getting a log of errors, even if I put the testconfig.json and snaps data there: http://paste.ubuntu.com/15003786/ | 18:25 |
| jdstrand | beuno, matiasb: in the logs: snapd[3217]: 2016/02/09 18:20:36.827803 response.go:118: method "GET" not allowed | 18:25 |
| jdstrand | beuno, matiasb: /usr/bin/snapd[3217]: daemon.go:153: DEBUG: uid=0;@ GET /2.0/snaps?q=snappy-debug&sources=store 630.821587ms 200 | 18:26 |
| elopio | plars: is that an allsnaps image generated with mvo's latest udf? | 18:27 |
| matiasb | jdstrand, let me check | 18:27 |
| plars | elopio: no | 18:28 |
| plars | elopio: it needs to be in order to work? | 18:28 |
| elopio | plars: if you have a 1504 image, you have to run the tests from the 1504 branch. If you want to run tests in rollilng, you need to use mvo's allsnaps image. | 18:28 |
| elopio | https://people.canonical.com/~mvo/all-snaps/ | 18:29 |
| jdstrand | matiasb: thanks | 18:29 |
| elopio | pindonga: how can I upload a snap to the edge channel? | 18:30 |
| plars | elopio: so, the test binary I built was from ubuntu-core/snappy trunk, with your patches to enable the parameters cherry-picked on top of it | 18:30 |
| pindonga | elopio, setting channels is not yet supported in the api, so I think you need to upload then go to the web ui and set the channels for the new verison | 18:30 |
| elopio | pindonga: do you know if that will be ready for 1604? | 18:31 |
| elopio | plars: yes, trunk needs allsnaps. | 18:31 |
| pindonga | elopio, depends on how strong you can make your case for beuno :) | 18:31 |
| plars | elopio: ack, thanks | 18:31 |
| pindonga | elopio, I'd start by filing a bug for it | 18:31 |
| matiasb | jdstrand, afaict, the revno is published and it looks ok; we would need to confirm that the rolling snappy client is not sending a framework when hitting CPI <- mvo could you confirm? | 18:31 |
| pindonga | elopio, and possibly listing all bugs related to the upload api | 18:32 |
| jdstrand | mvo is out sick | 18:32 |
| pindonga | so that we can see what's really missing and consider the effort | 18:32 |
| elopio | pindonga: well, I need squashfs first autoreview first, so I won't push to much with the channel. | 18:32 |
| pindonga | elopio, as said, autoreview depends on click-reviewers tools | 18:32 |
| pindonga | so, not something we can change in the store itself | 18:32 |
| jdstrand | matiasb: perhaps Chipaca could help in mvo's absense? | 18:32 |
| elopio | pindonga: right, but is that beuno's team too? | 18:32 |
| pindonga | not really | 18:32 |
| pindonga | it's snappy team I think? (jdstrand, mvo, ...?) | 18:33 |
| matiasb | jdstrand, did you get any results when searching? I mean, are you getting an old revision instead? | 18:33 |
| elopio | oh good. So I can make the two requests in parallel to two different teams :D | 18:33 |
| jdstrand | matiasb: no | 18:33 |
| jdstrand | pindonga: I wasn't following the conversation. I can say that snap.yaml changes for the review tools are in progress and squashfs in the store is after that | 18:34 |
| elopio | jdstrand: awesome! | 18:34 |
| jdstrand | matiasb: $ snap find snappy-debug | 18:34 |
| jdstrand | error: no snaps found for "snappy-debug" | 18:34 |
| jdstrand | $ snap find snappy-debug.canonical | 18:35 |
| jdstrand | error: no snaps found for "snappy-debug.canonical" | 18:35 |
| nessita | jdstrand, you need to be running this commit of snap command (or newer) https://github.com/ubuntu-core/snappy/commit/d18e35ef719a418332cd14eb61ec3841ff2a535f | 18:35 |
| matiasb | jdstrand, odd, everything looks ok, and hitting the index directly, the search seems to return the expected result | 18:35 |
| jdstrand | nessita: I'm on latest all snaps images from mvo... | 18:36 |
| jdstrand | let me see if I can determine if that is in it | 18:36 |
| nessita | jdstrand, if you could grab the raw http request is being done, it would be helpful | 18:37 |
| nessita | the headers being sent is key | 18:37 |
| jdstrand | ok... tcpdump not on the device... | 18:38 |
| nessita | jdstrand, as a summary, if your snap search is sending the framework ubuntu-core-15.04-dev1 only revnos with that framework will be returned, and revno 12 opf snappy-debug does not have any framework (which is correct) | 18:39 |
| jdstrand | nessita: hrmm, this is https so I don't seem to be able to see the headers | 18:42 |
| * jdstrand goes back at looking at changes in the ppa | 18:43 | |
| nessita | jdstrand, I guess source inspection with go is not possible? | 18:44 |
| jdstrand | nessita: that is what I am doing. the current os snap has an earlier version than what is in the ppa so I'm just tracking it all down | 18:45 |
| jdstrand | nessita: based on the diff for 1.7.3ubuntu1-1+1108~ubuntu16.04.1 , which is what is on the image, the change should be on the image | 18:47 |
| jdstrand | nessita: could this have something to do with it not authenticating with the store, ala, that other thread? | 18:48 |
| nessita | jdstrand, nopes, since search is anonymous: https://search.apps.ubuntu.com/api/v1/package/snappy-debug.canonical | 18:48 |
| nessita | https://search.apps.ubuntu.com/api/v1/search?q=snappy-debug | 18:48 |
| nessita | jdstrand, not authenticating could be a 401 when downloading the package, but this is not the case | 18:48 |
| jdstrand | this is what I see in the log: | 18:49 |
| nessita | jdstrand, from those package index URLs, you can see a search (with no headers) returns your package | 18:49 |
| jdstrand | /usr/bin/snapd[3217]: response.go:118: method "GET" not allowed | 18:49 |
| jdstrand | /usr/bin/snapd[3217]: daemon.go:153: DEBUG: uid=1000;@ GET /2.0/snaps?q=snappy-debug&sources=store 1.059970664s 200 | 18:49 |
| nessita | jdstrand, that URL is not store "server" side, may be something internal | 18:49 |
| jdstrand | hmm | 18:49 |
| jdstrand | I guess I'll file a bug | 18:50 |
| nessita | the URL for searching is https://search.apps.ubuntu.com/api/v1/search?<params> | 18:50 |
| nessita | plus headers | 18:50 |
| === retrack is now known as Guest94879 | ||
| jdstrand | Chipaca, matiasb, nessita: fyi, https://bugs.launchpad.net/snappy/+bug/1543731 | 18:57 |
| ubottu | Launchpad bug 1543731 in Snappy "'snap find snappy-debug' cannot find snappy-debug" [Undecided,New] | 18:57 |
| matiasb | ack | 18:59 |
| elopio | Chipaca: do you have the credentials of the canonical account in the store? I need it to get the spi tests working. | 19:00 |
| jerryG | any1 been able to create coredumps successfully? | 19:00 |
| wiggleworm | I am getting a java error when I try to start my snap - "nohup: failed to run java: no such file or directory | 20:18 |
| wiggleworm | any thoughts on how to fix this? | 20:18 |
| wiggleworm | Or better yet, Am i not dofing somthing correct in snapcraft? | 20:19 |
| jerryG | kgunn: are you there? | 23:02 |
| kgunn | jerryG: i'm literally needing to step away just now...feel free to leave query | 23:11 |
| jerryG | kgunn: kk lol. ill wait till tomorrow :} | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!