| csanders | Anyone here? | 00:39 |
|---|---|---|
| liuxg | I am running a service in golang, in the code, there are some runtime outputs like fmt.Println. where can I find the output data? | 02:01 |
| === timchen1` is now known as timchen119 | ||
| elopio | liuxg: sudo snappy service logs <name of the snap> | 03:27 |
| liuxg | elopio, thanks. I just found it either :) | 03:28 |
| elopio | that's good. | 03:28 |
| liuxg | elopio, snapcraft does not support local file compilation for go, right? | 03:29 |
| elopio | liuxg: not sure what you mean by that. | 03:29 |
| liuxg | elopio, I have a webserver project, and it is source code is in a github project. is it possible to compile a local go file https://github.com/liu-xiao-guo/go-webserver/blob/master/snapcraft.yaml | 03:30 |
| elopio | liuxg: sure, should be possible. There are two go projects in the examples: https://github.com/ubuntu-core/snapcraft/tree/master/examples | 03:31 |
| liuxg | elopio, looking in the snapcraft.yaml file, all of the sources pointing to the github. they are not local.. | 03:33 |
| elopio | liuxg: so, I'm still not sure what you want. But you should be able a local path instead of a git location. | 03:35 |
| elopio | plugin: go | 03:35 |
| elopio | source: path/to/src. | 03:35 |
| liuxg | elopio, I have changed path to local, it does not work. | 03:36 |
| elopio | liuxg: then that's a bug. Can you paste the error? | 03:36 |
| liuxg | elopio, https://bugs.launchpad.net/snapcraft/+bug/1515132 | 03:37 |
| ubottu | Launchpad bug 1499240 in Snapcraft "duplicate for #1515132 User friendly error missing when using go's source entry incorrectly" [Medium,Triaged] | 03:37 |
| elopio | liuxg: ah, right. So it needs to ve a valid go path. Something you would use with go get. | 03:37 |
| liuxg | elopio, so, how can I correct the issue? | 03:38 |
| elopio | sorry for making it more confusing. I think we need to support your case, and that's a different issue. | 03:38 |
| liuxg | elopio, yes, it is reasonable usage case for most the developers. | 03:39 |
| elopio | liuxg: I'm not quite sure. In order to be importable, it needs to be in $GOPATH/src/ | 03:40 |
| liuxg | elopio, would you please make my bug as a valid request? | 03:41 |
| elopio | liuxg: yes, tomorrow I'll talk about this with sergiusens. | 03:41 |
| liuxg | elopio, ok. many thanks :) | 03:42 |
| liuxg | elopio, do you mean that I need to set the $GOPATH myself to make it work? | 03:42 |
| elopio | liuxg: I really don't know. I'd had to look at the go plugin source to understand how it works, but I'm having dinner :) | 03:43 |
| liuxg | elopio, ok. thanks! have a nice dinner. | 03:43 |
| elopio | liuxg: for now you can push your source to github or launchpad. | 03:43 |
| elopio | if it's a valid source for go get, it should work with the git plugin. | 03:43 |
| liuxg | elopio, the thing is that some projects may not be open projects :) and also, in order to build it, we have to always push it, it is troublesome. yes, for the short term, github works. | 03:44 |
| elopio | yeah, your use case is valid. Take a look at the bug tomorrow morning | 03:45 |
| Bluefoxicy | What's going on with snappy? | 03:47 |
| Bluefoxicy | is this going to be the new thing? Am I going to install ubuntu-gnome under snappy one day? | 03:47 |
| elopio | Bluefoxicy: one day, sure. | 04:06 |
| Bluefoxicy | elopio: want to see something from 2004? | 04:09 |
| elopio | Bluefoxicy: I'm not particularly interested in 2004, no. | 04:09 |
| Bluefoxicy | heh | 04:10 |
| Bluefoxicy | so how does snappy work, anyway? The root is read-only, you put an image on top, can roll back if it doesn't work? | 04:12 |
| elopio | Bluefoxicy: you have two partitions. When you start, the two are the same, the latest image. | 04:14 |
| elopio | When you update, you put the new image in the second partition. | 04:14 |
| elopio | You reboot to that other partition, and if it fails the system reboots on the first partition. | 04:14 |
| elopio | if it works but you don't like the new version, you can manually roll back to the first partition too. | 04:14 |
| Bluefoxicy | finally. | 04:16 |
| Bluefoxicy | Now maybe one day we'll get automatic just-in-time security updates. | 04:16 |
| elopio | liuxg: GOPATH is set to builddir. And pull always does go get. So there's no workaround for your case, we'll need to extend the plugin. | 04:16 |
| Bluefoxicy | elopio: does the tech this runs on have the capability to detect and react to file access before it goes through, or is that still not part of the OS? | 04:17 |
| liuxg | elopio, ok. got it. so the bug is a valid bug, right? I think it is a little different from the said bug. | 04:17 |
| elopio | liuxg: I think it's valid, and shouldn't be duplicated. Need to convince Sergio, which shouldn't be hard. | 04:18 |
| elopio | and you also pointed to a case we had not considered. If the github or launchpad repo is private, we need to handle credentials. | 04:18 |
| elopio | Bluefoxicy: not sure what you mean. The snaps, as we call the packages for snappy, have a local working space. They can only touch files in their working space. | 04:19 |
| liuxg | elopio, yes, thanks for your understanding | 04:19 |
| Bluefoxicy | elopio: back in 2005 I wrote about plans I never got to for making an OS that essentially isolated the base installation from the rest of the system by using unionfs to mount over it. It was crude. One of the things I described was detecting access to files and responding accordingly--notably, with an integrated package manager that would recognize when you tried to access an executable or library from a package with a secur | 04:22 |
| Bluefoxicy | ity update, and immediately install the update. | 04:22 |
| Bluefoxicy | don't ask me why I thought this was a good idea | 04:22 |
| Bluefoxicy | at the moment, I still think it's an interesting idea; actual merits are debatable. | 04:22 |
| elopio | Bluefoxicy: it's interesting to check for updates just-in-time. What we have is a daily autoupdate. | 04:23 |
| Bluefoxicy | in any case, the technology going into things like coreos or snappy is ...better than what I Had on hand. | 04:23 |
| Bluefoxicy | elopio: yes, but you have the obvious problem of a program halting for 10 minutes while it downloads and installs a bunch of dependencies | 04:24 |
| elopio | Bluefoxicy: it would be interesting to have push notifications for security updates. | 04:24 |
| elopio | on the phone we have that. | 04:24 |
| Bluefoxicy | haha. Perhaps, but that's a whole different can of worms | 04:24 |
| elopio | when there's a new update, you get a message and you can manually install it. Or configure your phone to autoinstall updates on wi-fi. | 04:25 |
| Bluefoxicy | yeah. | 04:25 |
| elopio | we'll have to get that working on top of snappy at some point. | 04:25 |
| Bluefoxicy | delta debs would be great. | 04:28 |
| Bluefoxicy | delta updates have been a topic of debate and salivation for over a decade | 04:28 |
| Bluefoxicy | Has anyone thought of an unpatch-and-patch model yet, where you send the delta for both release base and installed, as well as the delta for current and release, so as to first build an as-installed deb, then make that a release deb, and patch that into a current deb? | 04:29 |
| Bluefoxicy | I guess you can do the same with snaps | 04:29 |
| Bluefoxicy | The ability to send half a megabyte to update LibreOffice would make JIT upgrades reasonable I think | 04:30 |
| elopio | Bluefoxicy: delta downloads works on the phone already. Needs some more thinking on snappy, because of the format of the snaps. | 04:46 |
| Bluefoxicy | nice | 04:46 |
| elopio | but there is no patching in snaps. You apply the patches in your repository, and then generate the snap from that repo. | 04:47 |
| Bluefoxicy | How will the desktop work? Will it install all desktop applications in one container, or will it provide containers for Chromium and Thunderbird and such and somehow make application links in the desktop that just work? | 04:48 |
| elopio | Bluefoxicy: that's still work in progress. There will be a snappy personal, which will work like the phone on desktop. | 04:50 |
| elopio | we'll have to package thunderbird and chromium as snaps for them to work with all the security and isolation. | 04:50 |
| elopio | there will be a classic mode in something more light than a container, that will let you install debs. | 04:51 |
| elopio | also work in progress. | 04:51 |
| Bluefoxicy | interesting. | 04:51 |
| Bluefoxicy | I can't see why all this wasn't done years ago, other than that nobody thought of it. | 04:51 |
| elopio | Bluefoxicy: go to github.com/ubuntu-core/snappy. You'll have fun there. | 04:51 |
| elopio | Bluefoxicy: I think there were more important problems to solve years ago. | 04:53 |
| Bluefoxicy | perhaps. | 04:53 |
| elopio | the users of desktop were happy with apt-get upgrades and not really interested in a certified bullet proof machine | 04:54 |
| elopio | and on the phone we were struggling to get linux running, like openmoko. Android changed everything. | 04:54 |
| elopio | and there was no beaglebone or raspberry pi. | 04:55 |
| elopio | this is a great momment to be developing for linux. Lots of things to do. | 04:55 |
| Bluefoxicy | I always wanted computers to be magic. | 04:55 |
| Bluefoxicy | I remember configuring my PC and laptop to trade processes between them. OpenMosix would let them send stuff over the network to execute on other machines. Dragonfly BSD has this thing where you can freeze a program, then thaw it later--dump its entire execution to a file, boot a new kernel, then continue executing. | 05:00 |
| Bluefoxicy | and then there's Minix | 05:00 |
| Bluefoxicy | now we have PCs the size of credit cards what can run programs in isolated contexts, pop them in and out, and cluster together to move applications around to wherever there's execution space. | 05:01 |
| Bluefoxicy | elopio: and all this stuff is trying to target phones and desktops. | 05:02 |
| Bluefoxicy | Do you know what I've been fantasizing in my head for the past 3 years? | 05:02 |
| Bluefoxicy | You're running Chrome on your phone, that little browser interface set up for it, the way it runs on android | 05:02 |
| Bluefoxicy | then, you pop it in the dock, and your 40 inch 4K display shows you an X or Wayland or whatever display, and taht little chromium window turns itself into a desktop window. | 05:03 |
| Bluefoxicy | a phone display over here, a desktop display over there. | 05:03 |
| elopio | Bluefoxicy: ah, but where have you been the past months? Let me look a video for you. | 05:04 |
| Bluefoxicy | people are like, "We could have it reboot into a full desktop OS..." and I'm like "Screw that, you could have it reshape itself depending on what kind of terminal it's connected to!" | 05:04 |
| Bluefoxicy | they're actually doing this? | 05:04 |
| Bluefoxicy | I've been awake too long. | 05:08 |
| elopio | Bluefoxicy: https://youtu.be/hLYvy1tPKtQ?t=10m4s | 05:09 |
| Bluefoxicy | elopio: I see that it plugs in and runs a program in a window | 05:16 |
| Bluefoxicy | but I don't see everything already running suddenly exporting its display to a desktop display on connection | 05:17 |
| elopio | my slimport cable hasn't arrived, so I haven't checked it. | 05:18 |
| elopio | but that should work, if not now, soon. | 05:18 |
| Bluefoxicy | cool | 05:18 |
| Bluefoxicy | it's also weird that it gives that MegaBloks interface when plugged into an enormous tv with a mouse and keyboard, instead of a proper UI. It's not a gigantic Android tablet. | 05:19 |
| Bluefoxicy | I suppose the goal is eventually to make it behave like a PC when plugged into appropriate peripherals, instead of like a cell phone hooked up to a giant screen | 05:20 |
| elopio | Bluefoxicy: that's because on a TV you will usually be far from it, so you need the icons and fonts to be big. | 05:20 |
| elopio | when you connect it to a monitor, the pixel density is different. The fonts will be smaller because you are expected to be closer to the monitor. | 05:20 |
| Bluefoxicy | I didn't mean size | 05:21 |
| Bluefoxicy | I meant the visual style is that of a child's toy. I guess that's a minor complaint, considering just how bad modern UI design has become from a functional perspective. | 05:22 |
| elopio | well, yeah, that's the ubuntu sdk style. | 05:22 |
| elopio | I like it. | 05:23 |
| Bluefoxicy | There was a time when everything was a mess; then we learned to put things in nice groups in front of the user, where expected, and to have advanced functions tucked away with sane defaults you could revert to if the user decided to go hunting for things to tweak. Now all those advanced features are completely removed, and you get stupid crap like a phone that only sends a 200kbyte MMS on a carrier who allows 1Mbyte MMS, becau | 05:23 |
| Bluefoxicy | se nobody wants the user to raise the limit and break their MMS. | 05:23 |
| Bluefoxicy | Android is particularly littered with gems of bad UI design like that. | 05:24 |
| Bluefoxicy | And here I am complaining about shiny boxes being too shiny. | 05:24 |
| elopio | :) | 05:25 |
| elopio | it's good. It's free software. If you don't like the shine, go and change it. | 05:25 |
| elopio | some decissions are going to be hard to tweak. But even now you can put plasma movil on your ubuntu phone instead of unity. | 05:26 |
| Bluefoxicy | You do understand that's a false choice unless somebody else does it first, right? | 05:26 |
| elopio | other options will come too. | 05:26 |
| elopio | Bluefoxicy: why somebody else? | 05:26 |
| Bluefoxicy | Most people can't just go about changing things. Hell, even Ubuntu and RedHat can't go about just changing things; they invest an immense amount of R&D into stuff like this. | 05:26 |
| Bluefoxicy | elopio: a lot of people would have to invest a lot of labor time up front to develop the skills required to make any specific changes to open source software | 05:27 |
| Bluefoxicy | it's like saying if you don't like the trucks Chevrolet sells, why not build your own? | 05:27 |
| elopio | I'm not saying that it will be easy. I'm not even close to say that your change will look good. But it's possible, the only thing you need is time and an itch. | 05:27 |
| Bluefoxicy | Financial considerations aside, do you even know how to engineer an automobile? | 05:28 |
| Bluefoxicy | right | 05:28 |
| elopio | Bluefoxicy: that's different. The Chevrolet also involves money. | 05:28 |
| Bluefoxicy | elopio: even if it didn't, it would involve a lot of engineering knowledge. | 05:28 |
| elopio | but if I have the money, I also have the potential to hack my car. And it will probably be a lot harder, because all the sources of it are closed. | 05:28 |
| Bluefoxicy | I'll probably drive myself insane teaching myself to program so I can write video games. Nothing I can't handle, although my mind is breaking under the strain already. | 05:29 |
| elopio | Bluefoxicy: yeah, but engineering knowledge is something you can earn by investing time. | 05:29 |
| elopio | so not *you*. But anybody else with the time can do it. | 05:30 |
| Bluefoxicy | elopio: to be precise: anybody with the time and with nothing better to invest the time in can do it. We're getting into an economics discussion, though. | 05:30 |
| Bluefoxicy | which irritates me these days, ever since I figured out how to solve poverty and discovered nobody cares. I've started to hate politics, but I guess I'm catching up to everyone else in that regard. | 05:31 |
| * Bluefoxicy sleeps. | 05:34 | |
| elopio | bye. | 05:34 |
| liuxg | elopio, ping | 05:44 |
| elopio | liuxg: tell me. | 05:44 |
| liuxg | elopio, I am now trying to cross-compile my project for armhf. I found a bug related to snapcraft at https://bugs.launchpad.net/snapcraft/+bug/1514650 | 05:45 |
| ubottu | Launchpad bug 1514650 in Snapcraft "Building golang project on ARM board gets "imports runtime: C source files not allowed when not using cgo or SWIG" error" [Undecided,New] | 05:45 |
| liuxg | elopio, how do you normally compile a project for armhf so far? cross-compile is not supported by the tool. | 05:45 |
| elopio | liuxg: and probably won't be supported. The discussions so far point to running snapcraft on the target. | 05:46 |
| elopio | liuxg: so, get snappy running on an arm board, install lxd and start a lxc. Install snapcraft there. | 05:46 |
| liuxg | elopio, yes, that is currently what I am doing. I am using a docker, inside it, I install a armhf ubuntu | 05:46 |
| liuxg | elopio, lxd seems not supporting armhf so far. | 05:47 |
| elopio | so let me look at the bug. | 05:47 |
| liuxg | elopio, ok | 05:47 |
| elopio | liuxg: what does gvm do? How is it fixing it? | 05:49 |
| liuxg | elopio, I search for some posts, it asks me to do install sth go1.5. I just installed half way, and it started to work. | 05:50 |
| liuxg | elopio, I think the installation must have some problem with it for the golang for the image. | 05:51 |
| elopio | liuxg: could you try with an empty lxc, just with snapcraft installed? Just to rule out a problem in the docker container. | 05:51 |
| liuxg | elopio, have you tried that solution before? if you have the guide for me, please send it to me. thanks | 05:52 |
| elopio | liuxg: I have compiled some packages in lxc. I don't remember if I tried go. | 05:53 |
| elopio | liuxg: https://plus.google.com/+St%C3%A9phaneGraber/posts/aX6vogzEQ1X | 05:53 |
| liuxg | elopio, could you have a try for my project? it is a very simple one. | 05:54 |
| liuxg | elopio, if it does not work, it won't work in my place as well. | 05:54 |
| elopio | liuxg: I can triage your bug tomorrow. It's already midnight and flashing my bbb takes time. | 05:57 |
| elopio | I've been trying to leave since your first ping :) | 05:58 |
| elopio | damn tests that don't want to be green. | 05:58 |
| liuxg | elopio, ok. many thanks. if you have any result of it, please update me :) | 05:58 |
| elopio | liuxg: sure, I'll comment on the bug. | 05:58 |
| liuxg | elopio, I am really sorry for that. have a good sleep! | 05:58 |
| elopio | not yet, but soon. | 05:59 |
| liuxg | elopio, :) | 05:59 |
| chiluk | Hey guys is there a how to on how to cross-arch snap? | 07:19 |
| chiluk | basically I'm trying to create a snap package on my amd64 machine that I'd like to put on my completely useless raspberry pi | 07:20 |
| chiluk | pi 2 actually. | 07:20 |
| chiluk | basically when I go to stage my snap it just gets created for my local architecture... as this is intended for embedded I assume you guys have this figured out already since only a small percentage of us are using arm-books | 07:22 |
| * chiluk goes to sleep and hopes answer is awaiting him in the morning. | 07:22 | |
| liuxg | chiluk, I just got a Chinese article for it at http://blog.csdn.net/ubuntutouch/article/details/49780767? you may use google translate for help :) | 07:23 |
| dholbach | good morning | 07:28 |
| fgimenez | good morning | 08:03 |
| davidcalle | Morning o/ | 08:40 |
| === chihchun_afk is now known as chihchun | ||
| JamesTait | Good morning all; happy Thursday, and happy Pizza With The Works Except Anchovies Day! 😃 | 10:12 |
| longsleep | So, since when does Snappy wait for networking on boot, seems like i missed that. snappy-wait4network.service does block until there is a default route .. :/ | 10:17 |
| mvo | ogra_: did you trigger a 15.04 build ? I noticed there is one running right now. | 10:46 |
| mvo | ogra_: i.e. I would like to start with the stable release checklist and promote the current edge to alpha so that fgimenez can start the upgrade/rollback test process | 10:47 |
| fgimenez | mvo, ogra_ ping me when ready | 10:50 |
| mvo | fgimenez: amd64 is ready in 15.04/alpha now | 10:53 |
| fgimenez | mvo, ok thanks, on it | 10:53 |
| mvo | fgimenez: great, thanks | 10:53 |
| mvo | fgimenez: armhf is ready in 15.04/alpha too | 10:59 |
| mvo | fgimenez: and i386 in some minutes | 11:00 |
| fgimenez | mvo, ok thanks, having them in alpha make things easier | 11:01 |
| ogra_ | mvo, see other channel | 11:17 |
| === kickinz1 is now known as kickinz1|lunch | ||
| fgimenez | mvo, the update -> rollback -> update -> rollback ... went well for amd64, from 16 to 17; but there are problems with the integration suite, 11 tests are failing with "Error: another snappy is running, try again later" | 11:42 |
| fgimenez | mvo, i think that we hit this some days ago, i'll try to find the root cause of this, maybe we can make the tests more resilient | 11:43 |
| mvo | thanks fgimenez, thats interessting, we did disable auto-pilot in the tests didn't we? | 11:55 |
| fgimenez | mvo, yes, it's disabled at the beginning of the suite after each reboot | 11:55 |
| === bigcat is now known as b[junior]|away | ||
| fgimenez | mvo, it seems that the problem comes from https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/autoupdate-msg_test.go, we are not stopping snappy-autopilot after the test | 12:18 |
| fgimenez | mvo, with that in place, and modifying the expected message, the suite seems to be running fine, i'll prepare a branch with the changes | 12:18 |
| mvo | fgimenez: \o/ | 12:20 |
| mvo | fgimenez: thanks for digging and finding it! | 12:20 |
| fgimenez | mvo, np :) let's see if all goes fine with the suite | 12:21 |
| === kickinz1|lunch is now known as kickinz1 | ||
| fgimenez | mvo, yes, the complete suite in amd64 is ok, i'm currently with rollback -> update -> rollback in bbb, fine too so far | 12:25 |
| fgimenez | mvo rollback -> update -> rollback -> update .... worked well in bbb, now running the suite | 12:42 |
| === chihchun is now known as chihchun_afk | ||
| mvo | fgimenez: \o/ | 12:58 |
| === chihchun_afk is now known as chihchun | ||
| mvo | fgimenez: I had to do another build for the image, its now in alpha for all arches. sorry for that, I'm afarid there is a re-test required. should be virtually identical to the last one but one never knows | 13:23 |
| ogra_ | well, we are waiting for a system-image merge, this wont be the last | 13:23 |
| ogra_ | and we really should only copy the last one to alpha since that is supposed to be for testing satble->stable updates | 13:24 |
| === chihchun is now known as chihchun_afk | ||
| fgimenez | mvo, ok, np | 13:52 |
| fgimenez | mvo, the suite works fine in amd64 #18, now trying 16 -> 18 -> 16 -> 18... | 14:14 |
| mvo | fgimenez: \o/ | 14:15 |
| fgimenez | mvo, update+rollback ok too, on to bbb | 14:21 |
| jdstrand | beuno, pindonga: ok, there is one last change for the vendor bug. instead of pulling r545, please pull r547 (or later) | 14:29 |
| jdstrand | mvo: hey, https://github.com/jdstrand/snappy/pull/6 has a merge conflict | 14:46 |
| mvo | jdstrand: let me fix | 14:50 |
| dholbach | STRAW POLL: Yes/No to a bot which shares new Askubuntu questions about Snappy in this channel? | 14:52 |
| mvo | jdstrand: should work now, contains a bit of extra stuff because I merged master | 14:53 |
| ogra_ | dholbach, yes | 14:55 |
| ogra_ | (until the traffic gets high indeed) | 14:56 |
| jdstrand | mvo: thanks | 15:04 |
| fgimenez | elopio, the image validation goes good so far (suite and update+rollback on amd64), they are published in the alpha channel | 15:10 |
| ogra_ | fgimenez, dont forget there are two more arches to test this time | 15:10 |
| ogra_ | (once we actually have the final image) | 15:10 |
| elopio | fgimenez: nice, thanks. | 15:10 |
| elopio | ogra_: wait, why two more? not just armhf? | 15:11 |
| fgimenez | ogra_, plano and raspi2_armhf right? | 15:11 |
| ogra_ | fgimenez, yeps :) | 15:11 |
| fgimenez | elopio, ogra_ i can go for raspi2 | 15:11 |
| ogra_ | cool | 15:11 |
| elopio | we don't have planos to test. | 15:11 |
| ogra_ | we're just waiting for a final fix for system-image to actually make it pick the right device tarballs | 15:12 |
| elopio | the certification team has been taking care of that. | 15:12 |
| ogra_ | right | 15:12 |
| ricmm | mvo: did we ever land the u-d-f branches for 128 mb and the other thing? | 15:54 |
| ricmm | the dst/target bit | 15:54 |
| ogra_ | ricmm, i dont think so | 15:55 |
| ogra_ | (or at least it didnt reach me ... my last weeks kvm image still has 64M) | 15:55 |
| ricmm | ok | 15:55 |
| ricmm | WARNING: this option should only be used to build azure images | 15:55 |
| ogra_ | yeah | 15:55 |
| ogra_ | ignore :P | 15:55 |
| ogra_ | we need to get rid of that | 15:56 |
| longsleep | Hey, i just have the case where an snappy update did not clean up old systemd services from two snaps - so now there are the new and the old systemd service and the old fail to start - any idea what could cause this? | 16:20 |
| longsleep | i typed snappy update, and it updated a new ubuntu-core and two snaps in that order | 16:21 |
| fgimenez | elopio, the rollback test is failing on bbb 1504/alpha #17, could you please confirm? i'm going to try now the update + rollback from #15 to #17 | 16:31 |
| elopio | fgimenez: ok, let me flash it. | 16:38 |
| fgimenez | elopio, there are other two errors, failover zerosize initrd (removing the check for mode=try works fine) and initramfs, but they are not related to the image | 16:41 |
| mvo | ricmm: hrm, the branch did not land, there was a tarmac failure. *sigh* let me fix that | 16:46 |
| ricmm | hurgh | 16:47 |
| mvo | ricmm: so the dst change landed | 16:48 |
| mvo | ricmm: I land the 128mb one now | 16:49 |
| mvo | (or try to) | 16:49 |
| ricmm | oh, those, I thought you meant image | 16:49 |
| ogra_ | mvo, there might be other u-d-f issues | 16:49 |
| ricmm | err, snappy | 16:49 |
| mvo | ogra_: hm? | 16:50 |
| ogra_ | i cant get the rpi2 to boot | 16:50 |
| ogra_ | it looks like the error i usually get if writable doesnt contain the cloud-init files | 16:50 |
| ogra_ | trying to verify that atm | 16:50 |
| ogra_ | yeah, writable is completely empty for me | 16:51 |
| ogra_ | mvo, afaik u-d-f usually puts the cloud-init stuff there when creating the img | 16:53 |
| mvo | ogra_: uh, so thats a regression? but it was not released in a while iirc | 16:55 |
| ogra_ | yeah, thats werid | 16:55 |
| ogra_ | i dont understand that | 16:55 |
| elopio | fgimenez: having problems here. The serial console only prints Cs. Have you seen that? | 17:06 |
| elopio | trying again... | 17:06 |
| fgimenez | elopio, nope, here works fine | 17:09 |
| jdstrand | mvo: I'm unable to install docker with your branch | 17:11 |
| elopio | tried 17 and 18, with two different bbb, two different sd cards. | 17:17 |
| elopio | damn it, what did I break? | 17:17 |
| fgimenez | elopio, 18? the tip of 1504/alpha is 17, right? | 17:20 |
| elopio | fgimenez: ahhhh, stupid. I'm flashing 18 amd64... | 17:21 |
| elopio | not enough breakfast today. | 17:21 |
| fgimenez | ahh those Cs are pretty significant :) | 17:22 |
| fgimenez | elopio, 15 -> 17 -> 15 -> 17 -> 15 ... works fine, btw i've confirmed that snappy_mode doesn't change after snappy update http://paste.ubuntu.com/13240185/ | 17:28 |
| === sarnold_ is now known as sarnold | ||
| fgimenez | leaving, have a nice day o/ | 17:32 |
| kyrofa | So say I'm developing an app to be packaged in a .snap and I'm running into apparmor denials when installed. Is there a Snappy way to debug this? Normally I'd just set it to complain mode, but ubuntu-core-launcher is the thing enforcing the profile... | 17:41 |
| jdstrand | kyrofa: snappy install snappy-debug, then run in one console 'sudo snappy-debug.security scanlog' while exercising your app in another | 17:42 |
| kyrofa | Ooo! Thanks jdstrand | 17:42 |
| jdstrand | dpm_: fyi, that ^ is the sorta thing I'd love to point people to when the 15.04 developer doc is available (see snappy-app-devel@, 'Adding custom apparmor rules' thread (I was talking with dholbach, but he is eod now I guess)) | 17:44 |
| dpm_ | jdstrand, there is an easy way to point people at this in the meantime: why not make it an ask ubuntu question? | 17:45 |
| jdstrand | dpm_: well, sure, but the larger point isn't that specific question, but that we need the 15.04 dev doc out there so people can tie everything together | 17:46 |
| plars | mvo: Hi, are there any details regarding the changes to core images that gustavo mentioned in his email? | 17:47 |
| plars | mvo: I'd like to know sooner than later if they will break our automated provisioning in any way | 17:47 |
| dpm_ | jdstrand, gotcha, I hadn't seen the thread until now, now I can see the context of the question | 17:48 |
| ogra_ | mvo, triggering a new 15.04 edge build for a fixed raspi2 device tarball | 17:58 |
| rickspencer3 | jdstrand, hi, I am trying to run fsweb from a snap on my rpi2 and bbb, and fsweb says that it doesn't have permissions to open /dev/video0 | 18:10 |
| rickspencer3 | does this look right for hw-assign?: sudo snappy hw-assign rest-cam.sideload /dev/video0 | 18:10 |
| jdstrand | rickspencer3: yes | 18:10 |
| jdstrand | I actually have to step away for an appt. if you have other questions, please feel free to ask tyhicks (or ask me and I'll answer when I get back) | 18:12 |
| rickspencer3 | will do | 18:13 |
| mvo | plars: d you use ubuntu-device-flash? if so, you may not need anything, or maybe change the parameters how u-d-f is called slightly the details are not fixed yet. essentially you need to tell it what os and kernel you want | 18:20 |
| mvo | ogra_: ta | 18:20 |
| * ogra_ twiddles thumbs waiting for the importer | 18:32 | |
| * genii makes sure ogra_ has enough coffee to stay awake | 18:36 | |
| ogra_ | hah, always :) | 18:36 |
| plars | mvo: yes, I do use udf, but just wondering if there were details yet | 18:40 |
| mvo | plars: we may make it transparent | 18:42 |
| mvo | plars: i.e. the gadget snap defines kernel/os so for you nothing changes | 18:42 |
| ogra_ | sudo ubuntu-device-flash core --oem pi2.canonical --channel edge --enable-ssh --device raspi2_armhf -o rpi.img 15.04 | 19:02 |
| ogra_ | ... | 19:02 |
| ogra_ | Summary: | 19:02 |
| ogra_ | Output: rpi.img | 19:02 |
| ogra_ | Architecture: armhf | 19:02 |
| ogra_ | Channel: edge | 19:02 |
| ogra_ | Version: 59 | 19:02 |
| ogra_ | \o/ | 19:02 |
| elopio | \o/ | 19:03 |
| genii | Hm | 19:04 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ snappy list | 19:10 |
| ogra_ | Name Date Version Developer | 19:10 |
| ogra_ | ubuntu-core 2015-11-12 59 ubuntu | 19:10 |
| ogra_ | pi2 2015-11-12 0.16 canonical | 19:10 |
| ogra_ | and it BOOTS ! | 19:11 |
| ogra_ | ok, rpi stable is ready for consumption :) | 19:11 |
| elopio | ogra_: stable? | 19:20 |
| ogra_ | mvo, elopio, i just copied the raspi2 59 edge image to alpha for testing | 19:20 |
| ogra_ | alpha 3 is all yours :) | 19:20 |
| elopio | ok. | 19:20 |
| ogra_ | yeah, stable | 19:20 |
| ogra_ | i'm not sure if rollback to 2 will or should work, given the images have been produced quite differently | 19:21 |
| ogra_ | (but you can try indeed and all future images should support rollback/install) | 19:22 |
| mvo | ogra_: worth re-testing the other ones too, just in case? | 19:27 |
| * jdstrand -> back | 19:27 | |
| ogra_ | mvo, well, they shouldnt have any changes, but sure | 19:28 |
| mvo | ogra_: did you promote the current candidates (latest build) to alpha? | 19:50 |
| mvo | ogra_: nevermind, I just did that | 19:52 |
| mvo | elopio: if you could do a validation of alpha that would be great, I just promoted the latest build from ogra to alpha, if all is looking good I will promote to stable later tonight or tomorrow morning | 19:53 |
| elopio | mvo: I'm on it. | 19:53 |
| ogra_ | mvo, oops, not yet | 19:53 |
| ogra_ | thanks ! | 19:54 |
| mvo | elopio: thanks! keep me updated :) | 19:55 |
| elopio | mvo: sure. Testing rpi alpha #3 now. | 19:55 |
| kyrofa | jdstrand, snappy-debug only seems to work if apparmor is in audit mode... is that right? | 21:22 |
| kyrofa | jdstrand, is there a reason for that? | 21:22 |
| kyrofa | jdstrand, I don't know a ton about apparmor, but I needed to change the regex "audit: type=1400 audit" to just "type=1400 audit" . After that, life-saver tool man | 21:24 |
| jjohansen | kyrofa: where is that regex? | 21:27 |
| kyrofa | jjohansen, snappy-security-scanlog line 77 | 21:28 |
| jdstrand | kyrofa: oh, interesting | 21:28 |
| jdstrand | kyrofa: what kernel is this on? | 21:28 |
| jjohansen | kyrofa: ah, okay /me is not familiar with that tool, but it really shouldn't be directly scanning the log | 21:28 |
| jdstrand | jjohansen: it uses libapparmor but it filters slightly to grab just the seccomp and apparmor stuff | 21:29 |
| jjohansen | jdstrand: doesn't really matter, that change isn't a kernel thing | 21:29 |
| jdstrand | oh I guess not | 21:30 |
| jdstrand | I'll update the tool | 21:30 |
| kyrofa | jdstrand, jjohansen before I lead you on a wild goose chase, this is part of the effort to get snaps running on the current phone image, so it may very well be a difference there | 21:30 |
| jjohansen | jdstrand: ah | 21:30 |
| jjohansen | kyrofa: not so much a wild goose chase, as a log prefixing issue that has been seen before in different configs | 21:32 |
| jjohansen | so its not just a phone issue | 21:32 |
| kyrofa | jjohansen, ah, good deal. Yeah perhaps making that regex a little less specific would be good, then | 21:32 |
| jdstrand | that is what I'm working on now | 21:33 |
| kyrofa | Thanks jdstrand :) | 21:33 |
| jjohansen | jdstrand: I am not sure a prefilter at this level is worth it | 21:34 |
| jdstrand | jjohansen: we need to choose between seccomp and apparmor and we do that by looking for the regex. but, we can just do ' type=1400 ' and ' type=1326 ' | 21:37 |
| jdstrand | rather than having the 'audit' bits around it | 21:37 |
| jjohansen | jdstrand: obviously doesn't know about the subversive plans to bring seccomp log parsing into libapparmor | 21:38 |
| jdstrand | heh | 21:39 |
| jdstrand | kyrofa: would you mind testing this: http://paste.ubuntu.com/13241898/ | 21:40 |
| jjohansen | but sure, what ever you need | 21:40 |
| kyrofa | jdstrand, doing now | 21:40 |
| kyrofa | jdstrand, the spaces are an issue. Here's a typical log for me: [ 7486.263143]type=1400 audit(1447364595.911:238): apparmor="DENIED" | 21:44 |
| jdstrand | huh | 21:44 |
| jdstrand | ok | 21:44 |
| jdstrand | kyrofa: guessing this'll do the trick: http://paste.ubuntu.com/13241961/ | 21:45 |
| kyrofa | jdstrand, bingo! Works great | 21:47 |
| jdstrand | kyrofa: ok, snappy update should get you 0.5 with the fix | 21:49 |
| kyrofa | jdstrand, best service in the business | 21:50 |
| jdstrand | hehe | 21:50 |
| jdstrand | welcome to snappy :) | 21:50 |
| kyrofa | Thanks : ) | 21:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!