| === laza_ is now known as laza | ||
| zlowred | hi there, I'm having troubles using 1-wire on Raspberry Pi 2 using latest Ubuntu Snappy Core, I did 'modprobe w1-gpio' which looks ok and adds w1 into /sys/bus, but /sys/bus/w1/devices is empty. Same hw works well under Raspbian. Are there any manuals/hints on getting it running? thanks | 05:49 |
|---|---|---|
| Tenacious-Techhu | Good luck, zlowred; every time I ask a question here, I get nothing. :P | 06:04 |
| zlowred | didn't want to dive into kernel sources... but afraid choices are only that or switching back to raspbian | 06:06 |
| Tenacious-Techhu | zlowred, you know anything about how secure by default Snappy is? | 06:10 |
| zlowred | not really worried about this as my device is supposed to run on local network | 06:12 |
| Tenacious-Techhu | That's the question I've been asking... I'm the one that cares. XD | 06:18 |
| pitti | elopio: sure, call it with --copy to copy a file into the testbed, or pass it via --setup-commands | 07:08 |
| pitti | elopio: you can't do that on the production infrastructure of course | 07:08 |
| pitti | but locally is fine | 07:08 |
| Tenacious-Techhu | pitti, how secure by default is Snappy, and in what ways isn't it secure by default? | 07:31 |
| pitti | Tenacious-Techhu: I'm not working on snappy, sorry; but this is a very fuzzy question, you need to get more specific | 07:32 |
| pitti | (I. e. I can't answer details about snappy) | 07:32 |
| Tenacious-Techhu | It's not a fuzzy question. "Secure by default" is a practice in which the attack surface of a system is completely minimized at the time of initial install and startup, until the "system administrator" changes it in order to enable features. | 07:34 |
| fgimenez | good morning | 08:04 |
| Tenacious-Techhu | Hello! | 08:05 |
| Tenacious-Techhu | How secure by default is Snappy? | 08:05 |
| anpok | Tenacious-Techhu: hm i guess this question is best aked on the mailing list.. But snappy by default is very minimal.. and it requires you to enable access for applications via app armor | 08:05 |
| Tenacious-Techhu | Being secure by default isn't necessarily about minimality; that's more about how insecure things are after they've been turned on. But thanks for the info. | 08:06 |
| anpok | i.e. installing common linux software is all about making sure it does not touch anything on the file system and figuring out what profile might be suitable for the applicatiohn | 08:07 |
| anpok | -h | 08:07 |
| anpok | you dont turn on things globally.. you do that per application.. | 08:07 |
| Tenacious-Techhu | Right; but if I were to install everything, would those things start off turned off or not? | 08:08 |
| Tenacious-Techhu | They should be disabled even though they've been installed. | 08:08 |
| anpok | take a lot at the security wiki page .. hmm here: | 08:10 |
| anpok | https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement | 08:10 |
| anpok | some the yaml settings have been renamed already | 08:10 |
| anpok | if you install a snap its package yaml is scanned for requires security profiles, those are then used to confine the application.. and yes if the snap contains a service that one will be started. | 08:14 |
| anpok | *required.. | 08:14 |
| anpok | note i am not one of the devs, just someone that tries to use it. | 08:14 |
| Tenacious-Techhu | More answers than I was getting anpok. XD | 08:36 |
| dholbach | good morning | 09:07 |
| Tenacious-Techhu | Good morning! | 09:09 |
| Tenacious-Techhu | dholbach, how secure by default is Snappy? | 09:09 |
| noizer | good morning :D | 09:10 |
| dholbach | Tenacious-Techhu: https://github.com/ubuntu-core/snappy/blob/master/docs/security.md should give you a good idea | 09:11 |
| Tenacious-Techhu | So... it's not. | 09:12 |
| dholbach | ? | 09:13 |
| Tenacious-Techhu | "If unspecified, default confinement allows the snap to run as a network client." | 09:14 |
| Tenacious-Techhu | It's not. | 09:14 |
| dholbach | ... | 09:20 |
| Tenacious-Techhu | dholbach, do you disagree with my assessment? | 09:28 |
| seb128 | kyrofa, hey, could you comment on bug #1542451? is that scope deprecated or is it going to be fixed/updated? | 09:29 |
| ubottu | bug 1542451 in unity-scope-snappy (Ubuntu) "RM: unity-scope-snappy" [Critical,Triaged] https://launchpad.net/bugs/1542451 | 09:29 |
| seb128 | willcooke, ^ just fyi, since our team was assigned to reply on it | 09:30 |
| willcooke | thanks seb128 | 09:31 |
| * willcooke subscribes | 09:31 | |
| seb128 | yw | 09:32 |
| seb128 | willcooke, you should get emails through desktop team assignement | 09:32 |
| willcooke | hrm | 09:32 |
| * willcooke searches | 09:32 | |
| willcooke | in spam | 09:33 |
| willcooke | od | 09:33 |
| willcooke | d | 09:33 |
| Tenacious-Techhu | Anyone else have anything to say about whether Snappy is secure by default? | 09:34 |
| JamesTait | Good morning all! Happy Monday, and happy Chinese New Year! š | 09:53 |
| Tenacious-Techhu | dholbach, do you disagree with my assessment? | 10:04 |
| === vrruiz_ is now known as rvr | ||
| noizer | Hi, I got a short question can i start other snaps from my snap? | 10:37 |
| Tenacious-Techhu | noizer, good luck getting your question asked. | 10:42 |
| beuno | noizer, hi. No, you can't | 10:43 |
| beuno | it breaks confinement, essentially | 10:43 |
| Tenacious-Techhu | beuno, is Snappy secure by default? | 10:43 |
| beuno | Tenacious-Techhu, I think that's been answered already | 10:44 |
| Tenacious-Techhu | No, it hasn't; they just pointed at documents. But if you would be so kind as to elaborate, that would be very helpful. | 10:44 |
| noizer | beuno hmm will there be something to start an other app later? | 10:44 |
| beuno | it seems like you are fishing for something, I'd prefer you to ask specific questions | 10:44 |
| Tenacious-Techhu | I am looking for a linux distribution that is secure by default. | 10:45 |
| beuno | Tenacious-Techhu, maybe you need to expand on what secure to you means? | 10:45 |
| Tenacious-Techhu | "Secure by default" means that all installed software starts with defaults that prevent it from being insecure. | 10:46 |
| beuno | noizer, it's not currently on our radar, given it breaks out of confinement. Can you expand a bit on what you're trying to acheive? | 10:46 |
| Tenacious-Techhu | It is my impression that, allowing software to be a network client by default goes against that security paradigm. Is that consistent with your perspective on the issue? | 10:47 |
| beuno | Tenacious-Techhu, I read through your previous comments on apps that can access the network makes them insecure | 10:47 |
| Tenacious-Techhu | So your conclusion would be that it isn't? | 10:48 |
| noizer | beuno We are making a product where people can make snaps for it. This product needs able to start applications just like the webdm or something | 10:48 |
| beuno | Tenacious-Techhu, we don't plan on locking down Snappy by default to that extent, Internet of Things without the Internet part is just "things" :) | 10:48 |
| Bughunter | Any one experience the same situation with two ubuntu-core packages installed. | 10:48 |
| Bughunter | The default username and password are ubuntu. | 10:49 |
| === beowulf_ is now known as beowulf | ||
| Bughunter | snappy list -v Name Date Version Developer ubuntu-core 2016-01-28 7 ubuntu* ubuntu-core 2016-01-28 7 ubuntu | 10:49 |
| beuno | noizer, ah, I see. So, we will have special permissions you can request in order to use the same APIs webdm uses | 10:49 |
| Tenacious-Techhu | Well yes, but you also don't want your unwatched "thing" to start running software the user didn't explicitly approve.\ | 10:49 |
| Tenacious-Techhu | Malware installed on an IoT device shouldn't be allowed network access by default. | 10:49 |
| beuno | Tenacious-Techhu, we do capture that a device uses the network, and there are scenarios where you might be able to lock it down further and/or inspect what snaps have requested network access | 10:50 |
| Tenacious-Techhu | That would only allow dealing with the problem after-the-fact. | 10:50 |
| noizer | beuno where can i find the webdm api? | 10:50 |
| Tenacious-Techhu | A piece of software should have to explicitly specify if it wants network access, and be granted that approval. | 10:50 |
| beuno | noizer, it's WIP, but, here it is: https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md | 10:51 |
| beuno | Tenacious-Techhu, we might be able to provide a bit further down the line an option to set stricter policies | 10:51 |
| beuno | but it is unlikely going to be the default | 10:51 |
| noizer | can webdm starts an application? | 10:52 |
| noizer | beuno | 10:52 |
| beuno | noizer, I think it either can now or it will in the near future | 10:52 |
| beuno | the command line and webdm are both moving to the internal rest api | 10:53 |
| Tenacious-Techhu | beuno, that does little good when a device is already out in the field, waiting to be preyed upon. | 10:53 |
| Tenacious-Techhu | Better to handle it now. | 10:53 |
| Bughunter | Issue: after update of ubuntu-core package with command "sudo snappy update ubuntu-core" we end up with two simular versions of ubuntu-core. | 10:53 |
| noizer | thanks for the help beuno :D | 10:54 |
| beuno | Bughunter, sorry, I don't understand the issue | 10:54 |
| beuno | what's going on? | 10:54 |
| ogra_ | Tenacious-Techhu, if you are concerned about that, there is a ufw snap that allows you to firewall the whole device by default and thus have full control over network accesses | 10:54 |
| Bughunter | Strange things is, why update with simular version. And why is it impossible to remove the duplicate package? | 10:54 |
| beuno | Tenacious-Techhu, end users don't understand security and will just approve everything. Additionally, most devices that will ship will require them to have internet access *and* won't have a UI for the user | 10:55 |
| Tenacious-Techhu | ogra, that would only be an improvement if that firewall were installed by default on all versions of Snappy. | 10:55 |
| ogra_ | no, it wouldnt | 10:55 |
| Tenacious-Techhu | Additionally, it would still be insufficient for meeting the criteria of "secure by default". | 10:55 |
| beuno | Tenacious-Techhu, so, if you want to ship a device that is further locked down, you can with Snappy | 10:55 |
| ogra_ | it would mean the everyone who uses a device behind a firewall already would have to set it up | 10:55 |
| beuno | we aren't planning on shipping devices locked down that much | 10:56 |
| Tenacious-Techhu | Yes, and that is my objection. | 10:56 |
| Tenacious-Techhu | Don't. | 10:56 |
| beuno | Bughunter, sorry, I don't understand the problem. Why update with similar versions? | 10:56 |
| beuno | Tenacious-Techhu, ok, noted | 10:56 |
| ogra_ | but you are free to create your own gadget snap that pulls in ufw in your default install | 10:56 |
| Tenacious-Techhu | Devices should ship as secure by default, period. Otherwise, they're just going to be exploited under the watch of people who don't know any better. | 10:57 |
| * ogra_ would say thats up to the device manufacturer | 10:57 | |
| Bughunter | Now, wy does snappy update ubuntu-core at al with the same version. Seems version checking is bugged? | 10:57 |
| beuno | Tenacious-Techhu, that's one way to look at it if you're not actually shipping devices to users, yes | 10:57 |
| Tenacious-Techhu | And as such, Snappy should start out that way, so that developers are starting from a state as correct as possible. | 10:57 |
| beuno | Tenacious-Techhu, we disagree | 10:58 |
| Bughunter | i just perfomed this command: snappy update ubuntu-core. | 10:58 |
| Tenacious-Techhu | Yes, I know. | 10:58 |
| Tenacious-Techhu | I encourage you to take the security of IoT devices more seriously. | 10:58 |
| beuno | Bughunter, is this 15.04 or 16.04/rolling? | 10:58 |
| ogra_ | *developers* shoudl start as easy as possible .... *manufacturers* should start as safe as possible with pre-defined services | 10:58 |
| beuno | Tenacious-Techhu, I think you're misguided. I understand why locking down the network makes it more secure, however, it also makes it useless to users | 10:59 |
| beuno | as a default | 10:59 |
| ogra_ | you can go and buy a dell ip gateway with snappy preinstalled ... you will find that this is differently secured than our developer images | 10:59 |
| Bughunter | I would expect snappy to update only when there is a later version of the ubuntu-core package. Instead it downloads and install the same packages. Thats odd. | 10:59 |
| Tenacious-Techhu | It is up to the developers to unlock it, and up to third party software to request that network access be unlocked. | 10:59 |
| Tenacious-Techhu | If network access is allowed to any third party software that doesn't specify a specific request, it's going to be a nightmare. | 11:00 |
| Bughunter | Think ill search the snappy-devel@lists.ubuntu.com list for answers. Sheers. | 11:00 |
| Tenacious-Techhu | You'll get a bunch of trojans that call home and such. | 11:00 |
| ogra_ | and what do they tell "home" ? | 11:00 |
| ogra_ | an app cant really see anything outside of its own box | 11:01 |
| Tenacious-Techhu | Whatever that software was written to. :P | 11:01 |
| ogra_ | apart from thinks like CPU architecture and some minor info+ | 11:01 |
| ogra_ | *things | 11:01 |
| ogra_ | apps cant access the OS | 11:01 |
| Tenacious-Techhu | Well no, but the minute one of those pieces of software uses an exploit on an embedded system to gain more access, they can tell them who knows what. | 11:01 |
| Tenacious-Techhu | You're leaving open an unnecessary security hole that will be a problem later when an exploit for that embedded system is discovered. | 11:02 |
| ogra_ | apps cant exploit the system either ... they are checked what they du when uploaded to the store | 11:02 |
| Tenacious-Techhu | And it may go unpatched while the device sits wherever the naive users put it. | 11:02 |
| ogra_ | *do | 11:02 |
| Tenacious-Techhu | Who says the thing was installed from the store? | 11:02 |
| ogra_ | well, then you are on your own | 11:03 |
| Tenacious-Techhu | From what I could tell, what I read said anything that was installed had network privileges by default. | 11:03 |
| ogra_ | you would have to scp and manually snappy install though | 11:03 |
| Tenacious-Techhu | Installed from the store or not. | 11:03 |
| ogra_ | via ssh | 11:03 |
| ogra_ | for which you have the key | 11:03 |
| Tenacious-Techhu | The point is, it's an unlocked door. | 11:03 |
| ogra_ | so that an administrator mistake | 11:03 |
| ogra_ | not snappys fault | 11:03 |
| Tenacious-Techhu | The end user will NEVER be an administrator! | 11:04 |
| Tenacious-Techhu | That's the point! | 11:04 |
| ogra_ | its an unlocked door if you gave some evil guy your ssh key, yes | 11:04 |
| Tenacious-Techhu | Lock ALL the doors, and make the devs decide which doors to open, and which not to open. | 11:04 |
| Chipaca | Tenacious-Techhu, i don't understand | 11:04 |
| Chipaca | Tenacious-Techhu, what's the point you're trying to make | 11:04 |
| Chipaca | ? | 11:05 |
| Tenacious-Techhu | That way, everyone knows whose responsibility it is when malware gets on the device. | 11:05 |
| ogra_ | well, you know who has the ssh key ... so you know who leaked it | 11:05 |
| Tenacious-Techhu | That's not what I'm saying. | 11:05 |
| Chipaca | ogra_, if ssh is running the device was in developer mode :-) | 11:05 |
| Tenacious-Techhu | Allowing software network privileges by default is an unlocked door. | 11:05 |
| ogra_ | (and to be honest, i wouldnt expect ssh to be enabled on enduser devices .... but again, thats up to the vendor) | 11:06 |
| ogra_ | Tenacious-Techhu, to do exactly what ? | 11:06 |
| Tenacious-Techhu | A door that should have never been left unlocked to begin with. | 11:06 |
| Tenacious-Techhu | Every door that's left unlocked is security that could have prevented disaster. | 11:06 |
| ogra_ | Tenacious-Techhu, yozur app runs under confinement, it cant see anything outside of its own system space | 11:06 |
| anpok | Tenacious-Techhu: I believe they are talking about network-client | 11:06 |
| ogra_ | all it could do would be to exploit its own data | 11:06 |
| Tenacious-Techhu | You guys need to stop assuming that the rest of the security is going to work. | 11:06 |
| Tenacious-Techhu | Lock ALL the doors. | 11:07 |
| anpok | which is not unlocked network.. | 11:07 |
| Tenacious-Techhu | Assume each one is the thing that is going to keep the bad guys out. | 11:07 |
| Tenacious-Techhu | Yes. | 11:07 |
| Tenacious-Techhu | The software should have to request network access, and the system should be able to deny it. | 11:07 |
| Chipaca | Tenacious-Techhu, request to whom? | 11:07 |
| Chipaca | Tenacious-Techhu, and which system? | 11:07 |
| Tenacious-Techhu | To the system that is currently allowing that by default. :P | 11:08 |
| Chipaca | Tenacious-Techhu, can you describe exactly how you think things work now, and how you think they should work? | 11:09 |
| Tenacious-Techhu | https://github.com/ubuntu-core/snappy/blob/master/docs/security.md | 11:09 |
| Tenacious-Techhu | If unspecified, default confinement allows the snap to run as a network client. | 11:09 |
| Tenacious-Techhu | Bad. Very bad. | 11:09 |
| Tenacious-Techhu | Default should allow absolutely nothing at all. | 11:10 |
| Chipaca | i'm five seconds away from assuming you're trolling | 11:10 |
| beuno | so, by default, the device isn't useful for anything? | 11:11 |
| Tenacious-Techhu | Not until the developers building software for that device specifically unlock it, yes. | 11:11 |
| Chipaca | beuno, either that, or they think we should manually review every app that requests network-client | 11:11 |
| beuno | right | 11:11 |
| Tenacious-Techhu | Everything should be locked until a developer unlocks it. | 11:11 |
| Tenacious-Techhu | Accountability should be squarely placed on the developer's shoulders. | 11:12 |
| beuno | Tenacious-Techhu, I think your argument is technically sound, not particulary novel, but sound. It just isn't practical when you actually think about users | 11:12 |
| Tenacious-Techhu | Third party software that makes it onto the device however it may should be able to be soundly rejected, if required. | 11:12 |
| Tenacious-Techhu | When I think about users, I think about some teenage girl whose boyfriend slipped a webcam snooper onto her outdated router. | 11:13 |
| Tenacious-Techhu | Unless a piece of software has been whitelisted, or someone has entered an administrator password to allow that software, it should be denied. | 11:14 |
| Tenacious-Techhu | Just because it's found on the device, that doesn't mean it's legitimate software. | 11:14 |
| Tenacious-Techhu | And so it shouldn't be granted network access. | 11:14 |
| beuno | snappy devices won't be outdate, they auto-update | 11:15 |
| Tenacious-Techhu | Don't assume where they will be installed. | 11:15 |
| beuno | if you want to lock down the device further and know how to administrate a device, you can | 11:16 |
| Tenacious-Techhu | If it is on some local network, and not on the internet, it won't update. | 11:16 |
| Tenacious-Techhu | But it can still do damage there. | 11:16 |
| Tenacious-Techhu | This is not about what I want to do. | 11:16 |
| Tenacious-Techhu | This is about what any IoT OS should do by default. | 11:16 |
| Tenacious-Techhu | To keep the users safe, the onus for unlocking access should be on the software developers. | 11:17 |
| Chipaca | Tenacious-Techhu, by default, you won't be able to install software that doesn't have a chain of certs behind it | 11:17 |
| Chipaca | of assertions | 11:18 |
| Tenacious-Techhu | Maybe not, but once it's on the device, how it got there doesn't matter anymore, does it? | 11:18 |
| Chipaca | enabling that software to be on that particular device, and asserting it has been made by who it says it's been made, and etc | 11:18 |
| Chipaca | Tenacious-Techhu, the snap won't work unless it has the assertions | 11:19 |
| Tenacious-Techhu | You don't get to justify leaving one door unlocked just because the others are. | 11:19 |
| Tenacious-Techhu | You have to lock all of them, because you don't know which one is going to keep the system safe. | 11:19 |
| Chipaca | you don't get to tell me what i have to do | 11:20 |
| Chipaca | especially when i try to explain why what you think is a problem isn't, and when i've tried to explain that what you think is a solution isn't | 11:20 |
| Chipaca | and have ignored or dismissed those points | 11:21 |
| Tenacious-Techhu | Oh? So if your neighbor left your front door open, you wouldn't want me to tell him to shut it? | 11:21 |
| Tenacious-Techhu | I am not dismissing your points out of hand. | 11:22 |
| anpok | Tenacious-Techhu: no better analogon would be.. the keys for your house are all opening the door of your house without coming with an extra letter telling you that the keys of your house unlock your doors | 11:22 |
| Tenacious-Techhu | I am dismissing them because they are insufficient. | 11:22 |
| Chipaca | Tenacious-Techhu, you're saying the neighbour should have to write "i can open the front door" before they can open the front door | 11:22 |
| Chipaca | Tenacious-Techhu, that's all you're saying | 11:23 |
| Tenacious-Techhu | No, you misunderstand, anpok. | 11:23 |
| Chipaca | that an app dev needs to explicitly write "i can use the network" before they can use the network | 11:23 |
| Chipaca | and that that will somehow stop malware | 11:23 |
| Tenacious-Techhu | It is not what the app dev writes... | 11:23 |
| Tenacious-Techhu | It is what the system decides when receiving that request that matters. | 11:24 |
| Tenacious-Techhu | Rather than granting that access by default, it has the chance to reject it. | 11:24 |
| Chipaca | Tenacious-Techhu, so three options: either always grant that request, always reject it, or always have somebody manually audit it | 11:24 |
| Tenacious-Techhu | And right now, you are auditing those requests, except by default. | 11:25 |
| Chipaca | Tenacious-Techhu, which of those do you think is sane? | 11:25 |
| Tenacious-Techhu | I'm just saying audit that one too. | 11:25 |
| Chipaca | Tenacious-Techhu, we are not auditing all requests, only those that we consider have real security implications | 11:25 |
| Tenacious-Techhu | Yes, but internet access DOES have real security implications. | 11:26 |
| Chipaca | Tenacious-Techhu, explain | 11:26 |
| Chipaca | Tenacious-Techhu, give me an example, even if it's contrived, in which *just* being a network client has security implications for a sandboxed app | 11:27 |
| Tenacious-Techhu | Someone could find an exploit on the poorly maintained, widely deployed IoT device, write a piece of trojan malware for it, get a bunch of naive idiots to install it, and then when the server it dials home to says "go", it explodes. | 11:28 |
| Tenacious-Techhu | Whereas, if it had to request internet access to begin with, it could be rejected, and thus, never could be installed in the first place. | 11:28 |
| Chipaca | Tenacious-Techhu, how could it be rejected? | 11:30 |
| Tenacious-Techhu | The request for internet access would be denied by the existing mechanisms that deny other things in non-default circumstances. | 11:31 |
| Tenacious-Techhu | My recommendation is to assign network access, even as a client, to a specific request, and not a default one. That way, it can be denied, just as any other specific request can be. | 11:42 |
| beuno | Tenacious-Techhu, as I said an hour ago, noted | 11:42 |
| Tenacious-Techhu | Well, fair enough then. | 11:43 |
| Tenacious-Techhu | Go to a Homeland Security conference some time. | 11:43 |
| didrocks | ogra_: argh, no loadkeys in 15.04 Core image! Do you know off hand how to switch to my sweet french kbd layout? :) | 11:49 |
| ogra_ | didrocks, i dont, actually :) | 11:51 |
| ogra_ | even if loadkeys was there we wouldnt have the keymaps | 11:52 |
| didrocks | ogra_: do you know who would have any idea on this? :p | 11:52 |
| * ogra_ tends to always use ssh so i dont run into this ;) | 11:52 | |
| beuno | ogra_, where does uboot go in the 16.04 images? | 11:56 |
| ogra_ | didrocks, i guess they shoudl be part of some UI snap in the end ... | 11:56 |
| didrocks | ogra_: yeah | 11:56 |
| ogra_ | beuno, on disk ? in what snap ? you have to be more precise ;) | 11:56 |
| beuno | ogra_, heh, yeah, in what snap | 11:56 |
| ogra_ | gadget | 11:56 |
| ogra_ | (talking about all-snaps here ... system-image builds still use the 15.04 setup) | 11:57 |
| beuno | ogra_, and that's the plan going forward, right? | 11:57 |
| beuno | yeah, all-snaps | 11:57 |
| ogra_ | right | 11:57 |
| beuno | thanks ogra_ | 11:57 |
| noizer | ogra_ Hello, I'm trying to use UWSGI in a snap but i got following error: error removing unix socket, unlink(): Read-only file system [core/socket.c line 198] | 12:04 |
| noizer | but this is some permission issue. If you have any idea how I can solve that | 12:05 |
| Chipaca | noizer, what's in the audit logs? | 12:05 |
| noizer | where can i find the audit logs Chipaca? | 12:06 |
| Chipaca | noizer, sudo journalctl | grep audit | 12:06 |
| ogra_ | yeah, looks like the socket is created in some dir outside of your box | 12:06 |
| Chipaca | noizer, there's probably a better way, but that one works :-) | 12:06 |
| * ogra_ prefers syslog :) | 12:06 | |
| noizer | oooh ok ogra_ first i will try to change the path of my sock maybe that will hep | 12:07 |
| noizer | Chipaca then i will share my log | 12:08 |
| ogra_ | noizer, use $TMPDIR ;) | 12:08 |
| noizer | in the ini of the socket? | 12:08 |
| noizer | (ini of uwsgi) | 12:08 |
| ogra_ | if that respects the environment vars, yes | 12:09 |
| Chipaca | otherwise /tmp/something should work | 12:09 |
| ogra_ | yeah | 12:09 |
| Chipaca | /tmp/foo.sock | 12:09 |
| Chipaca | noizer, it's a private tmp, fwiw | 12:09 |
| ogra_ | what a luck Tenacious-Techhu is gone now | 12:10 |
| * ogra_ bets that would be the next discussion ;) | 12:10 | |
| noizer | hahah xD | 12:10 |
| noizer | Chipaca and ogra_ thx this error is fix. I think so xD. now the next error | 12:31 |
| zyga | jdstrand: hey | 13:17 |
| zyga | jdstrand: around? | 13:17 |
| noizer | Chipaca ogra_ do you now something about this error? lock engine: pthread robust mutexes | 13:17 |
| noizer | oooh sorry thats the issue Bad system call | 13:19 |
| ogra_ | might be seccoomp related | 13:19 |
| noizer | secoomp?? | 13:19 |
| ogra_ | right, check with ubuntu debug | 13:19 |
| ogra_ | *seccomp | 13:20 |
| ogra_ | err | 13:20 |
| ogra_ | snappy-debug, sorry | 13:20 |
| zyga | robust mutex are used internally to implement parts of the stdlib | 13:20 |
| zyga | they should be allowed by seccomp | 13:20 |
| zyga | (perhaps they are not) | 13:20 |
| ogra_ | right | 13:20 |
| ogra_ | thats why i asked to check it :) | 13:20 |
| zyga | hey ogra_ :) | 13:20 |
| ogra_ | yo | 13:20 |
| zyga | busy week ahead | 13:21 |
| ogra_ | two of them :) | 13:21 |
| zyga | that's quite true | 13:21 |
| noizer | ogra_ what do you mean with ubuntu debug | 13:21 |
| ogra_ | snappy-debug was what i meant | 13:21 |
| ogra_ | it ships a tool to check the logs for seccomp denials | 13:22 |
| noizer | ok and how can i test that because im nog familiar with it | 13:22 |
| ogra_ | (i forgot the new name, it used to be called sc-logresolve in 15.04) | 13:22 |
| noizer | ogra_ I'm using 16 (xenial) | 13:22 |
| ogra_ | install the snappy-debug snap and run sc-logresolve ... IIRC it tells you the new name | 13:22 |
| ogra_ | then run whateve it tells you | 13:23 |
| noizer | ok i will check it out | 13:23 |
| noizer | snappy-debug failed to install: can not open /tmp/snappy-debug230025468: cannot open snap: unknown header: "!<arch>\ndebian-binar" | 13:24 |
| noizer | tried to install it dammed | 13:24 |
| noizer | is that a bug? | 13:24 |
| ogra_ | jdstrand, ^^^ hasnt that been updated to the 16.04 format yet ? | 13:25 |
| ogra_ | noizer, try snappy install snappy-debug/edge | 13:25 |
| ogra_ | if that gets you the same error it hasnt been updated yet (and thats a bug, yes) | 13:25 |
| noizer | hmmm same error | 13:26 |
| ogra_ | yeah, thats a bug then | 13:26 |
| noizer | ogra_ should I file it or?? | 13:26 |
| ogra_ | yeah, i'm unsure against what exactly though ... file it against the snappy project itself for now | 13:27 |
| noizer | this project ? https://bugs.launchpad.net/ubuntu/+source/snappy | 13:28 |
| ogra_ | nop, see the channel topic | 13:28 |
| ogra_ | ("/ubuntu/+source/snappy" would be the snappy package in ubuntu ... not the project) | 13:29 |
| noizer | ok sorry xD my mistake | 13:30 |
| noizer | now I will file it now. But how can we debug it then? | 13:30 |
| ogra_ | i guess you have to ask tyhicks or jdstrand ... i dont know how you can get seccomp messages without the tool | 13:31 |
| ogra_ | (or even if you can) | 13:31 |
| noizer | ogra_ ok i will ask them | 13:32 |
| noizer | tyhicks and jdstrand Hi i wanted to use UWSGI in xenial but i had some errors. ogra_ said to me its something with the seccomp can we debug it without snappy-debug? (I'm using xenial for my development) | 13:34 |
| kyrofa | Good morning | 13:36 |
| noizer | ogra_ they online? or can kyrofa help me? | 13:36 |
| noizer | Good morning | 13:36 |
| ogra_ | noizer, perhaps not yet (US timezone ?) | 13:37 |
| ogra_ | sergiusens, what are you doing here ? isnt is a holiday in arg. ? | 13:37 |
| noizer | ok | 13:37 |
| kyrofa | Hey seb128 the scope is out-of-date (using the webdm API instead of the snappy API) and not being used since Personal isn't being used. And as you see on the bug, it sounds like the golang updates have broken it. I think it will probably be updated eventually, but it doesn't make sense to put in the effort right now for something no one is using :) | 13:39 |
| sergiusens | ogra_, auto connect; good bye ;-) | 13:39 |
| ogra_ | enjoy ! | 13:39 |
| ogra_ | :) | 13:39 |
| sergiusens | ogra_, it's almost 11 and I just got up; I started the day perfectly :-) | 13:40 |
| * sergiusens waves | 13:40 | |
| ogra_ | :D | 13:40 |
| seb128 | kyrofa, I expect some people are going to want pocketpc or unity8 desktops to be able to install snaps, even if there is no personal image | 13:40 |
| kyrofa | ogra_, I believe seccomp denials go into syslog as well | 13:40 |
| seb128 | willcooke, ^ do you know? | 13:41 |
| ogra_ | kyrofa, oh, right | 13:41 |
| kyrofa | seb128, good question | 13:41 |
| kyrofa | ogra_, snappy-debug just parses syslog | 13:41 |
| ogra_ | yeah | 13:42 |
| noizer | ogra_ are there some other things that i can test? | 13:43 |
| willcooke | seb128, kyrofa - yes, I would expect that people would want to install snaps in a U8 session on a desktop. But, it's probably not a priority. Let me see what I can find out. | 13:43 |
| ogra_ | noizer, as kyrofa said, check syslog for seccomp lines | 13:43 |
| noizer | ow sorry | 13:44 |
| noizer | how can i do that ogra_ sorry not familiar with some logging of linux | 13:45 |
| ogra_ | its a text file :) | 13:45 |
| ogra_ | /var7log/syslog | 13:45 |
| ogra_ | bah | 13:45 |
| noizer | ooh dammed | 13:45 |
| ogra_ | /var/log/syslog | 13:45 |
| noizer | :D | 13:45 |
| noizer | ty | 13:45 |
| ogra_ | run tail -f /var/log/syslog ... in one terminal ... in another terminal start your app/service/whatever ... and see what it logs ... watch for seccomp lines then | 13:46 |
| ogra_ | (or just search for former seccomp lines without monitoring live ... as you like) | 13:46 |
| noizer | ogra_ that is what i got when im started my application | 13:50 |
| noizer | http://pastebin.ubuntu.com/14993207/ | 13:50 |
| kyrofa | willcooke, yeah, please let me know. I can talk to alecu again, see if we should give it a higher priority if that's true | 13:50 |
| ogra_ | noizer, syscall=282 is blocked then | 13:50 |
| ogra_ | noizer, now run: scmp_sys_resolver 282 | 13:51 |
| ogra_ | that tells you which function it is | 13:51 |
| noizer | its the bind method | 13:53 |
| noizer | now the bind method is that from the ubuntu snappy? or from my uwsgi? | 13:55 |
| kyrofa | noizer, binding to a port, probably. You're using Snappy 16.04 right? What capabilities are you providing to your service/binary? | 13:56 |
| noizer | kyrofa yea i'm using Snappy 16.04. what do you mean by the capabilities of my binary? | 13:59 |
| kyrofa | noizer, pastebin your YAML real quick | 13:59 |
| noizer | ok | 13:59 |
| noizer | but now its not a service I start it from command line (bash file) | 14:00 |
| kyrofa | noizer, alright | 14:00 |
| noizer | He isnt at the moment a network service if you mean that | 14:00 |
| noizer | I will add something to it | 14:00 |
| noizer | kyrofa does you need then my Yaml file? | 14:01 |
| noizer | kyrofa how can i sea if uwsgi is running then? In normal ubuntu then you can see it with ps -A but in snappy i don't know that | 14:03 |
| kyrofa | noizer, yeah let me take a look. But yeah, you need to give it permission to bind to a port | 14:03 |
| kyrofa | noizer, yeah you can still use ps | 14:03 |
| noizer | Ok awesome | 14:03 |
| noizer | My snap is now building with the network-service. but now an other question seccomp what does it do with snappy? | 14:04 |
| kyrofa | noizer, ahh, so much | 14:05 |
| kyrofa | noizer, snappy has an excellent confinement story, utilizing a number of technologies to get there | 14:05 |
| noizer | kyrofa can i find some information of the complete build of snappy | 14:06 |
| kyrofa | noizer, it uses apparmor to make sure the .snap can only play in its own space on the filesystem, seccomp filters to make sure it can only call a whitelist of syscalls, as well as cgroups | 14:06 |
| kyrofa | noizer, so that one little network-service capability you added results in a different profile being used for apparmor and seccomp | 14:07 |
| kyrofa | noizer, what do you mean by "complete build?" | 14:10 |
| noizer | oooh ok dem so a nice system Snappy | 14:10 |
| noizer | How snappy is builded | 14:10 |
| noizer | So i know more about the underlaying things | 14:10 |
| kyrofa | noizer, ah, that's outside of my purview. But here's an overview of the security side of things: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement | 14:11 |
| noizer | kyrofa ok I will read this. Looks very intresting :D | 14:14 |
| noizer | kyrofa I tried now with ps -A but dont see anything running | 14:21 |
| kyrofa | noizer, probably died then. If it gets a seccomp denial it's always fatal | 14:22 |
| noizer | will it be in the syslog? | 14:22 |
| * kyrofa has a flashback to having to modify the mysql code so it wouldn't die | 14:22 | |
| noizer | Does i need do some command to start the services? | 14:23 |
| kyrofa | noizer, not sure what you mean | 14:23 |
| noizer | no uwsgi can run now :D awesome | 14:25 |
| kyrofa | noizer, so it works? | 14:25 |
| noizer | normally yes thanks for you help :D awesome support here :D | 14:26 |
| === nyx_ is now known as kjar | ||
| kyrofa | noizer, very good! | 14:28 |
| ogra_ | yay | 14:28 |
| noizer | hahah ogra_ | 14:28 |
| noizer | now i need to wait until Skills will be released :D | 14:29 |
| noizer | what is the expected release date of the skills? | 14:37 |
| beuno | noizer, I think we have a few more weeks until we reach a testing phase | 14:37 |
| kyrofa | noizer, the only target I know of is "for 16.04" :P | 14:39 |
| noizer | kyrofa lol ok :D | 14:40 |
| dholbach | kyrofa, did you ever see anything like this? http://paste.ubuntu.com/14993445/ | 14:40 |
| kyrofa | dholbach, uhh | 14:40 |
| kyrofa | dholbach, nope. Gross :P | 14:41 |
| dholbach | I'll file a bug :) | 14:41 |
| kyrofa | dholbach, does it work on a second try? i.e. store hated you for a sec? | 14:41 |
| kyrofa | dholbach, obviously we should handle those errors better | 14:41 |
| === zbenjamin_ is now known as zbenjamin | ||
| dholbach | kyrofa, this time it didn't explode :) | 14:43 |
| dholbach | so maybe intermittent | 14:43 |
| kyrofa | dholbach, honestly that's an all-around snapcraft bug (the stack trace) | 14:43 |
| kyrofa | dholbach, something I've been very much wanting to make cleaner | 14:44 |
| dholbach | <3 | 14:44 |
| === nyx_ is now known as kjar | ||
| kyrofa | ogra_, can 15.04 run decently on the dragonboard then? | 14:47 |
| ogra_ | kyrofa, it might, i dont think anyone works on this beyond some basic demo stuff (i surely am not aware of plans to make official 15.04 images) | 14:47 |
| kyrofa | ogra_, alright, does regular-old Ubuntu work? | 14:49 |
| ogra_ | it might ... you have to set up the SD in a special way though | 14:49 |
| ogra_ | i have scripts for that at http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/README | 14:50 |
| elopio | fgimenez: tests still fail with http proxy. Could you please check if I'm doing something wrong here: https://github.com/ubuntu-core/snappy/pull/429/files | 14:50 |
| kyrofa | ogra_, I'll take a look, maybe I can get the owncloud snap built for arm64 | 14:51 |
| ogra_ | yay, that would be cool (though it is WLAN only, might have some bootloenecks) | 14:51 |
| fgimenez | elopio, sure, on it | 14:52 |
| fgimenez | elopio, jenkins feels young and strong again! :D | 14:59 |
| elopio | fgimenez: yes! I changed the ip. I'm making a change in this branch to see it run. | 15:00 |
| fgimenez | elopio, last time i tried the http://squid.internal:3128 was only accessible from scalingstack instances | 15:07 |
| fgimenez | elopio, in order to test in jenkins we need to add -httpProxy to snappy-tests-job too | 15:07 |
| elopio | fgimenez: on that last execution, I did the deps manually, got an image, and called main. | 15:09 |
| zyga | jdstrand: hi | 15:26 |
| zyga | jdstrand: could you have a look at https://github.com/ubuntu-core/snappy/pull/462 | 15:26 |
| zyga | jdstrand: (hopefully last iteration of this type) | 15:26 |
| zyga | tyhicks: ^^ | 15:26 |
| jkridner | hi ogra_! | 15:40 |
| * jkridner looks for rcn-ee | 15:40 | |
| ogra_ | hey jkridner ! | 15:40 |
| kyrofa | elopio, wait... encrypted variables in travis don't work from forks? | 15:41 |
| elopio | kyrofa: yes, just the main repo. | 15:47 |
| kyrofa | elopio, why? I glanced through that bug but didn't really see one. Maybe the worry is that the third-party can add code to phone the variable's value home to them? | 15:48 |
| elopio | kyrofa: or just echo it and get it from the logs. | 15:50 |
| kyrofa | elopio, that might be easier, yeah | 15:50 |
| kyrofa | elopio, huh. Guess I never thought about it before | 15:50 |
| kyrofa | elopio, how on earth does coveralls work? | 15:51 |
| ysionneau | Hi, is it possible to install the snappy-tools on Debian? | 15:51 |
| jkridner | ogra_: can you give rcn-ee and I some pointers on how to easily build a snappy image? The above question about doing it on Debian is also useful. | 15:55 |
| jkridner | ogra_: sorry to ask such a google-able FAQ.... | 15:55 |
| jkridner | ogra_: but want to make sure we short-circuit it as much as possible. | 15:56 |
| noizer | kyrofa i have an other question for you | 15:56 |
| noizer | is it possible to launch an other snap from my own snap? | 15:57 |
| ogra_ | jkridner, our core tool (for the final assemblement) is called ubuntu-device-flash ... it is written in go with no deps ... that part should definitely run under debian | 15:57 |
| ogra_ | not sure about other bits though | 15:57 |
| jkridner | ogra_: cool. | 15:57 |
| kyrofa | noizer, no, snaps can only touch their own stuff, not interfere with each other | 15:57 |
| jkridner | ogra_: /me can't /invite rcn-ee | 15:57 |
| kyrofa | noizer, unless you unconfined it, but I doubt such a thing would accepted in the store | 15:58 |
| * jkridner notes no channel operators here! | 15:58 | |
| * jkridner goes afk | 15:58 | |
| noizer | hmm | 15:59 |
| noizer | kyrofa but we asked ubuntu if that was possible or will be possible and then they said yes. Because we are making something where people can make their own applications and these application needed to be snaps. | 16:01 |
| noizer | or can you start an app from the webdm? | 16:01 |
| kyrofa | noizer, I'm not saying it'll never be possible-- anything is possible with the right skill. There's just no skill that encompasses that functionality that I know of | 16:02 |
| kyrofa | noizer, no, just install/uninstall them | 16:02 |
| noizer | hmmm | 16:02 |
| kyrofa | noizer, and you don't want them to be services that just run upon install? | 16:02 |
| elopio | kyrofa: it doesn't sound hard to allow secure env vars per user, instead of per repo. But the travis team is small, they just close most of the bugs as won't fix :( | 16:02 |
| kyrofa | elopio, sad | 16:03 |
| elopio | kyrofa: and I have no clue about how coveralls work. I started wondering because fgimenez added a coveralls report without token. | 16:03 |
| noizer | maybe but can you hook into an snapp as a developer I dont think so :s | 16:03 |
| kyrofa | noizer, I'm not sure what you mean | 16:03 |
| elopio | they should have something special between coveralls and travis. As the reports are per branch, it sounds safer than normal tokens. | 16:03 |
| noizer | Do you mean that the people needed to make services so they can run on it? | 16:04 |
| noizer | kyrofa | 16:04 |
| kyrofa | noizer, I'm sorry, I still don't understand. So you have service snap A, upon which client snaps B and C depend. Are you saying that snap A needs to be able to start and stop the programs contained within snaps B and C? Or can the programs contained within B and C simply be running at all times? | 16:07 |
| zyga | jdstrand: around? | 16:07 |
| fgimenez | elopio, about the different images reported by the vivid and xenial slaves http://paste.ubuntu.com/14993929/ | 16:07 |
| elopio | fgimenez: that's crazy. A bug? | 16:08 |
| elopio | a bug in grep maybe :D | 16:09 |
| fgimenez | elopio, no idea, anyway vivid's version of the client is very old, maybe it's a known issue... "image show" woks even with images that don't appear in the list :D | 16:13 |
| elopio | fgimenez: how do you set up two labels for a slave in this docker run statement? | 16:15 |
| fgimenez | elopio, white-spaced separated according to https://wiki.jenkins-ci.org/display/JENKINS/Swarm+Plugin#SwarmPlugin-AvailableOptions | 16:17 |
| jdstrand | zyga: hey, yes | 16:25 |
| jdstrand | zyga: I got your request to look at the pull request. I haven't gotten to it just yet | 16:26 |
| zyga | jdstrand: thanks | 16:32 |
| elopio | fgimenez: common.sh is getting really ugly when I add the snapcraft container. Is there a way to install the dependencies on each test run? | 16:35 |
| elopio | oh, he's gone. | 16:36 |
| elopio | fgimenez: common.sh is getting really ugly when I add the snapcraft container. Is there a way to install the dependencies on each test run? | 16:38 |
| fgimenez | elopio, right now the slave user isn't a sudoer, we can change that. anyway, why not adding the dependencies to the container itself? | 16:41 |
| elopio | fgimenez: I did that. The problem is with the naming. Now we have slave-xenial and slave-xenial-snapcraft. So all the get_name and get_dir functions are getting an extra optional argument. | 16:42 |
| elopio | doens't look nice. | 16:42 |
| kyrofa | noizer, you're asking questions that may interest others. If you ask them via PM no one else can benefit from them | 16:42 |
| fgimenez | elopio, all that functions are going away with docker-compose, no worries | 16:43 |
| elopio | fgimenez: right, I supposed you were going to say that. | 16:44 |
| elopio | :) | 16:44 |
| fgimenez | fgimenez, yep :) | 16:44 |
| elopio | so I'll dump this branch and wait for you. | 16:44 |
| elopio | pedronis: you merged your last PR with integration errors. Did you check if you could have caused them? | 16:51 |
| pedronis | elopio: they are quite flaky this dies, it was again a vm creation problem | 16:53 |
| elopio | pedronis: I see: sudo snap assert integration-tests/data/dev1.acckey | 16:54 |
| elopio | error: open : no such file or directory | 16:54 |
| pedronis | ? | 16:54 |
| pedronis | where what | 16:54 |
| elopio | which doesn't make a lot of sense. | 16:54 |
| elopio | pedronis: http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/725/consoleFull | 16:55 |
| pedronis | elopio: they passed here: http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/723/ | 16:58 |
| pedronis | I don't think IĀ changed anything significant since | 16:59 |
| elopio | pedronis: that one failed to create the vm. | 16:59 |
| elopio | wrong link? | 17:00 |
| pedronis | elopio: is marked as passed in github | 17:00 |
| pedronis | fascinating | 17:00 |
| elopio | crazy thing. | 17:01 |
| elopio | it should say no results found. | 17:01 |
| elopio | pedronis: we have a brand new jenkins today. Now that the deploy and the slaves are more stable, we can dig on those weird things. | 17:01 |
| elopio | and add retries for when scalingstack is grumpy. | 17:01 |
| pedronis | elopio: seems there all bunch of green in github that was actually vm not started | 17:06 |
| pedronis | so not sure when they started failing, I see other failures in that run that are not assert related | 17:06 |
| elopio | pedronis: please give me a link. | 17:07 |
| elopio | pedronis: I'll be monitoring today. | 17:07 |
| pedronis | elopio: the runs at the top here: https://github.com/ubuntu-core/snappy/pull/460 | 17:07 |
| pedronis | marked as green | 17:07 |
| pedronis | if you click you see they didn't run | 17:07 |
| fgimenez | elopio, pedronis this is probably due to the lack of sync before setting up the new server, this is the successful run that pedronis was talking about http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/723/ | 17:08 |
| elopio | pedronis: hum, that doesn't make sense. Maybe when we redeployed we messed with the history. | 17:08 |
| pedronis | ah | 17:08 |
| elopio | it prints 60 successful tests. There's no way to get that message from a failed job. | 17:08 |
| fgimenez | elopio, pedronis and the list of greens http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/ | 17:09 |
| pedronis | ok, but if that one passed, no clue what make them fails | 17:09 |
| pedronis | after | 17:09 |
| elopio | so now the numbers are different. | 17:09 |
| pedronis | because nothing substatianl change | 17:09 |
| pedronis | d | 17:09 |
| pedronis | it's all formatting and comments | 17:10 |
| elopio | weird. fgimenez: do you have any idea about that failure to find the file in integration-tests/data? | 17:10 |
| fgimenez | pedronis, something must be different in the new server, probably not related to the code | 17:10 |
| fgimenez | elopio, nope, taking a look now | 17:10 |
| pedronis | also that message is not super clear, not sure is not finding the file or one of the commands | 17:11 |
| pedronis | or what | 17:11 |
| elopio | pedronis: fgimenez: I also see this: https://paste.ubuntu.com/14994568/ | 17:33 |
| elopio | doesn't seem normal. | 17:33 |
| fgimenez | elopio, this was happening before the server change | 17:33 |
| pedronis | elopio: that's the code John added, is retrying so that's expected I think | 17:33 |
| pedronis | a bit ugly but expected | 17:33 |
| fgimenez | elopio, http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/723/consoleFull | 17:33 |
| elopio | I'm going to get a testbed kvm. | 17:34 |
| elopio | ah, we can make that prettier making more prints in the wait package. | 17:34 |
| * pedronis needs to go have dinner, will check logs later | 17:36 | |
| fgimenez | elopio, pedronis i think that the errors might be related to the recent changes in the testutils/cli package, the server seems to be fine | 17:36 |
| fgimenez | elopio, if you can execute it locally it would be great to confirm, i'm leaving too | 17:36 |
| elopio | fgimenez: pedronis: enjoy. I'll be debugging here, come back tomorrow for the results :) | 17:37 |
| fgimenez | elopio, thx :) i'll keep an eye on telegram o/ | 17:38 |
| pedronis | elopio: if I try to run the tests here IĀ crash already in testutil/common.go GetCurrentVersion | 18:52 |
| pedronis | something is off with those cli changes, I also don't understand that branch didn't seem to have run the integration tests | 18:52 |
| pedronis | ah, no it did | 18:53 |
| elopio | pedronis: I'm bisecting... | 18:53 |
| * ogra_ wonders why nobody has created a unifi manager snap yet | 18:55 | |
| ogra_ | (i know many canonicalers are using unifi APs) | 18:55 |
| elopio | pedronis: nop, I went back to a revision that I know passed all the tests and it still fails. Something else changed, not our repo. | 18:58 |
| pedronis | at least I crash on snappy list not having content | 19:02 |
| elopio | it has to do with the flags, because assertOptions.AssertionFile doesn't get the name from the command line. | 19:08 |
| elopio | zyga: pedronis: ^ | 19:14 |
| elopio | zyga: you have been touching the cmds, right? Any idea what could be going on here? | 19:14 |
| zyga | elopio: looking | 19:17 |
| zyga | elopio: I haven't seen GetCurrentVersion, that's not related to my changes | 19:17 |
| zyga | elopio: I was making CLI more testable (ironically!) | 19:17 |
| pedronis | that is still something else | 19:17 |
| elopio | I don't get any error with GetCurrentVersion. Nor scalingstack. | 19:18 |
| pedronis | elopio: the snap I get compiled here seems to work (it gets the first arg) | 19:18 |
| pedronis | but my test runs crash before that :/ | 19:18 |
| elopio | pedronis: the one I got here doesn't even show the file help in -h | 19:23 |
| pedronis | snap [OPTIONS] assert assertion-file | 19:25 |
| elopio | pedronis: https://paste.ubuntu.com/14995878/ | 19:25 |
| pedronis | weird | 19:25 |
| elopio | this is a pristine all snaps just generated with mvo's udf | 19:25 |
| elopio | asserts -h shows the options. | 19:26 |
| pedronis | bulding it on trunk looks right | 19:27 |
| pedronis | does the archive have a go-flags that is older than the dep | 19:27 |
| elopio | ahh, no, this is a whole mess. https://paste.ubuntu.com/14995920/ | 19:27 |
| elopio | asserts shows options that are not for the asserts command :) | 19:28 |
| pedronis | it's ignoring arg 1 | 19:28 |
| pedronis | but yes it seems the snap and snappy in the image are broken | 19:28 |
| elopio | I'm using goflags 0.0~git20150817-0ubuntu1 | 19:29 |
| elopio | latest xenial. | 19:29 |
| elopio | pedronis: which one do you have? | 19:29 |
| pedronis | I'm building from the checkouts | 19:29 |
| pedronis | but yes the snappy snap in ubuntu-core.snap are broken IĀ suppose | 19:29 |
| pedronis | elopio: I double checked the image my tests are trying to use has a broken snappy list | 19:38 |
| elopio | pedronis: I can run snappy list here. | 19:39 |
| pedronis | so weird | 19:39 |
| elopio | yes indeed. | 19:39 |
| pedronis | elopio: this is what I get http://pastebin.ubuntu.com/14996079/ | 19:40 |
| pedronis | this built with u-d-f by running integration tests | 19:40 |
| elopio | pedronis: ah, if you didn't patch your udf with mvo's version, that's not going to work. | 19:40 |
| pedronis | elopio: have mvo versions | 19:41 |
| pedronis | IĀ have been happily running integration tests all last week | 19:41 |
| elopio | oh, I think I know what's the deal. | 19:41 |
| elopio | give me a second... | 19:42 |
| elopio | pedronis: this made my tests pass. | 19:44 |
| elopio | https://paste.ubuntu.com/14996133/ | 19:44 |
| elopio | now you have an image that's clearly more broken than mine. | 19:44 |
| elopio | I flashed like this: https://paste.ubuntu.com/14996153/ | 19:45 |
| pedronis | did xenial go-flags change recently? | 19:46 |
| pedronis | still not understanding what changed since last week | 19:47 |
| pedronis | elopio: was the old testing box also xenial? | 19:49 |
| elopio | pedronis: no, it's the same that we have in the deps since a long time ago. | 19:49 |
| elopio | maybe something in go changed. | 19:49 |
| elopio | pedronis: yes, also xenial, but we deployed a new one today. That one had old packages, probably. | 19:49 |
| elopio | this is an important thing that we are not doing. apt-get update && upgrade often on the slaves. | 19:49 |
| elopio | pedronis: can I propose this as a quick fix to get back to green, and let you investigate the reason tomorrow? | 19:50 |
| elopio | https://bugs.launchpad.net/snappy/+bug/1543266 | 19:57 |
| ubottu | Launchpad bug 1543266 in Snappy "snap assert failing with error: open : no such file or directory" [Critical,Confirmed] | 19:57 |
| pedronis | elopio: yes | 19:57 |
| pedronis | and yes it seems related to go version | 19:58 |
| elopio | pedronis: ok. So this can wait until tomorrow, you don't need to stay so late. | 19:58 |
| elopio | thanks a lot for your debugging. | 19:58 |
| pedronis | so it's probably go-flags that is unprepared/has go 1.6 bugs | 20:07 |
| pedronis | I don't care either way about that code though | 20:08 |
| pedronis | elopio: solved the snappy list, seems IĀ had mvo u-d-f but not the latest | 20:09 |
| elopio | pedronis: phew. One less thing to investigate :D | 20:09 |
| elopio | oh, the asserts tests should be failing too. | 20:10 |
| elopio | let me upper-case that. | 20:11 |
| pedronis | found the problematic code in go-flags, in case we want to give them a PR | 20:12 |
| elopio | pedronis: that would be awesome. I want to peek, where is it? | 20:12 |
| pedronis | elopio: it's related to this | 20:14 |
| pedronis | http://tip.golang.org/doc/go1.6#reflect | 20:14 |
| pedronis | group_private.go:72:if field.PkgPath != "" in go-flags | 20:14 |
| elopio | interesting. Not a single boring day in the snappy world. | 20:14 |
| pedronis | should be change like they change encoding/json in go ittself, it seems | 20:15 |
| elopio | kyrofa: is there a way to see the squashed commits after the PR was merged? | 20:17 |
| kyrofa | elopio, not without playing some fun games... that's kinda the point. Why, what happened? | 20:18 |
| elopio | kyrofa: nothing. I want to convince snappy to squash commits. | 20:18 |
| kyrofa | elopio, yeah not really | 20:19 |
| elopio | if there is a way to see all the commits, there's no convincing to do. I'll just tell them to use that. | 20:19 |
| kyrofa | elopio, yeah, you'd have to use the reflog | 20:21 |
| kyrofa | elopio, which is usually more of a "I made a mistake, give me back my stuff" type of thing in my experience | 20:21 |
| elopio | ok, it doesn't matter. I have a good argument. | 20:22 |
| elopio | the discussion history is not lost. | 20:22 |
| kyrofa | elopio, haha, you're brave | 20:25 |
| elopio | bisecting this crazy issue just made it clear that not even with a nice commit message the snappy changelog makes sense. | 20:27 |
| elopio | we need branches, and we need squashes. QA has spoken! :D | 20:27 |
| kyrofa | elopio, heh, yeah bisecting is key | 20:29 |
| wiggleworm | is there a graphical interface for wifi setup in snappy | 21:51 |
| wiggleworm | i worry i am staring right at it :) | 21:51 |
| camako | When I change the cmake file 'snapcraft snap' doesn't seem to detect the changes and regenerate cmake config accordingly. Is there a way to do that? | 22:05 |
| camako | I couldn't find a '--force' option either | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!