| liuxg | how to define the cap for services in snapcraft.yaml? I have not seen an example for this. I have seen something defined in a package.yaml at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/go-example-webserver/meta/package.yaml | 00:36 |
|---|---|---|
| === JohnB_ is now known as Guest89533 | ||
| liuxg | has anyone done cross compile for snapy app using Docker? thanks | 05:57 |
| woodrowshen | liuxg: using snapcraft ? | 06:17 |
| liuxg | woodrowshen, yes, I wan to build my app in the docker container for my RaspBerry PI device. | 06:18 |
| liuxg | woodrowshen, is that possible? | 06:18 |
| woodrowshen | liuxg: according to maillist, the snappy team seems they're still working cross build with snapcraft. | 06:22 |
| liuxg | woodrowshen, this is more like a native build. I use the arm container for the purpose. | 06:23 |
| woodrowshen | liuxg: yes, just use snapcraft if you have arm container. why not | 06:25 |
| liuxg | woodrowshen, the thing is that I got an error like "Pulling webserver | 06:26 |
| liuxg | env GOPATH=/home/liuxg/snappy/examples/go-webserver/parts/webserver/build go get -t -d github.com/liu-xiao-guo/golang-http | 06:26 |
| liuxg | fatal error: rt_sigaction failure" | 06:26 |
| woodrowshen | liuxg: longsleep did the PR, https://github.com/ubuntu-core/snapcraft/pull/53, but it seems ubuntu-core branch didn't accept commits yet. | 06:26 |
| woodrowshen | liuxg: did you find where does the message come from ? | 06:28 |
| liuxg | woodrowshen, that looks easier without going through a container, right? | 06:28 |
| woodrowshen | liuxg: acutally i also use snapcraft to build a snap in the docker (although it's amd64 arch), but i think it's different between container and native platform. | 06:30 |
| liuxg | woodrowshen, the message came from the build inside the arm container http://paste.ubuntu.com/13122312/ | 06:30 |
| liuxg | woodrowshen, sorry, I built it from a container inside the docker. | 06:31 |
| liuxg | woodrowshen, how did you set it up? | 06:32 |
| woodrowshen | liuxg: ok. so you have a native arm platform ? | 06:32 |
| liuxg | woodrowshen, I do not have it yet. I want to do it using one PI device in the near future. I want to get the ubuntu mate on it. | 06:33 |
| liuxg | woodrowshen, the output is actually from the arm container | 06:33 |
| liuxg | woodrowshen, it seems like "go get github.com/liu-xiao-guo/golang-http" command has problem. | 06:37 |
| woodrowshen | liuxg: i'm not sure, but maybe it has some clues, https://github.com/golang/go/issues/13024 | 06:41 |
| woodrowshen | liuxg: or your go version is too old ? | 06:42 |
| woodrowshen | liuxg: i think you can test a simple go program first to check go is workable or not. | 06:43 |
| woodrowshen | liuxg: s/check/check if/ | 06:43 |
| liuxg | woodrowshen, I just updated it to the latest. | 06:44 |
| liuxg | woodrowshen, you are right. "go" command simply gets the erro. | 06:46 |
| liuxg | woodrowshen, I used apt-get install golang-go to install the go. how did you get it installed. | 06:47 |
| woodrowshen | liuxg: what's version of go in your env ? | 06:56 |
| liuxg | woodrowshen, may I know how you installed the "go"? my "go version" command crashes | 06:56 |
| liuxg | woodrowshen, http://paste.ubuntu.com/13122387/ | 06:57 |
| woodrowshen | liuxg: i used gvm, https://github.com/moovweb/gvm | 07:00 |
| woodrowshen | liuxg: and also you can check my github, https://github.com/woodrow-shen/snapcraft-grafana | 07:01 |
| woodrowshen | liuxg: fyi | 07:01 |
| liuxg | woodrowshen, many thanks! | 07:02 |
| woodrowshen | liuxg: np | 07:04 |
| liuxg | woodrowshen, by the way, where did you get the armhf image for vivid. I get it from my colleague's source like docker pull alextucc/ubuntu:vivid-armhf-hybris. | 07:47 |
| dholbach | good morning | 07:50 |
| mvo | hey dholbach! good morning | 07:51 |
| dholbach | hey mvo | 07:52 |
| liuxg | woodrowshen, I just followed your steps to do "gvm install go1.4", during the installation, I got the error like http://paste.ubuntu.com/13122582/. so, it is basically the same thing. I doubt whether it is because of my armhf for vivid image issue. | 07:56 |
| fgimenez | good morning | 08:02 |
| soffokl | Hey, we are using OVA images for Snappy Ubuntu, and latest stable release. But there is a problem with installing snap packages. “snappy internal-unpack” spend a lot of time with high IOwait, it takes minutes. We are using SSD disks only and disks are not loaded, but snappy still shows high IOwait. Can someone help to solve it? | 09:14 |
| zt | hi, I am new to snappy world, can someone knows a good tutorial on how to create a snappy app (more than the hello world), I dont know how to create an app that need to add libraries to it, thank you! | 09:28 |
| zt | if it helps I want to try to use the raspberry pi CLI to build a basic app | 09:28 |
| Chipaca | zt: maybe https://developer.ubuntu.com/en/snappy/build-apps/ ? | 09:48 |
| JamesTait | Good morning all; happy Friday, and happy Nachos Day! 😃 | 10:00 |
| Chipaca | * totopos | 10:05 |
| Guest42341 | nope | 10:10 |
| ogra_ | soffokl, what hardware architecure ? | 10:55 |
| soffokl | ogra_, amd64 | 11:08 |
| ogra_ | hmm, that should definitely not have performance issues | 11:13 |
| soffokl | ogra_, I will try to collect more information about problem, thanks | 11:44 |
| longsleep | Is ppa:snappy-dev/image livecd-rootfs built from http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/ or what is the best tree i could sync with? | 12:10 |
| ogra_ | longsleep, bzr branch lp:livecd-rootfs | 12:53 |
| ogra_ | (for xenial ... for vivid just apt-get source from the PPA) | 12:54 |
| longsleep | ogra_: ok thanks - is there no branch for vidid? I would prefer to have source control integration | 12:56 |
| ogra_ | nope | 12:56 |
| ogra_ | the branch gets locked down on release day | 12:57 |
| longsleep | i see - so how are the fixed created then? Just in local source control? | 12:57 |
| ogra_ | package | 12:57 |
| longsleep | without source control then? | 12:57 |
| ogra_ | well, with debdiffs and package versioning :) | 12:58 |
| longsleep | ok got it - i guess i can just git apply the debdiffs - i am doing that for other packages already | 12:58 |
| === rcj` is now known as rcj | ||
| clobrano | hello all, is there any news about the possibility to write udev rules? I mean, without re-mounting the filesystem RW :) | 13:58 |
| longsleep | mvo: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config#L394 has uses space indentation, while the rest of the file uses tabs | 14:23 |
| ogra_ | longsleep, yeah, the code is a mess since years | 14:24 |
| ogra_ | wrt indendation | 14:25 |
| ogra_ | not only there | 14:25 |
| longsleep | ogra_: well the vivid version of that file is horrible, but someone cleaned up in trunk - so i thought i report it as that one is the only issue in this file | 14:26 |
| mvo | longsleep: thanks, I will try to remember that | 14:43 |
| plars | joc_: sergiusens: so I was thinking about the difficulty of naming the 'null' plugin, what do you think about just calling it 'basic' | 14:47 |
| sergiusens | plars, what is wrong with null or nil? | 14:47 |
| plars | sergiusens: nil may be ok also I think, but null seems to be a type in yaml, so when it's translated it becomes Nonetype | 14:48 |
| plars | sergiusens: unless you wrap it in quotes... but then it would be different from every other plugin | 14:51 |
| sergiusens | plars, ah, then nil :-) | 14:52 |
| plars | sergiusens: ok, nil should be fine then... ^ joc_ | 14:52 |
| joc_ | ok | 14:53 |
| sergiusens | plars, I would go against basic, I'm happier with it being the anti-plugin :-) | 14:53 |
| plars | sergiusens: heh, ok. I was thinking basic because it's 'no frills/nothing added' i.e. you just get the base plugin class | 14:53 |
| sergiusens | plars, just add docstrings explaining the purpose of the plugin. """This plugin does nothing.\n\n [More about the plugin which is probably more of nothing or its purpose]""" | 14:54 |
| plars | right | 14:54 |
| plars | joc_: are you going to propose that? ^ | 14:54 |
| joc_ | plars: can do, will just rename the stuff in my branch... | 14:55 |
| joc_ | plars: sergiusens: https://github.com/ubuntu-core/snapcraft/pull/85 | 15:10 |
| joc_ | plars: dammit, defeated by plainbox! | 15:19 |
| joc_ | elopio: hey, could you help work out what tests i need to add to snapcraft to accompany a new plugin? | 15:36 |
| sergiusens | joc_, fyi, trunk broke with the last commit so many tests are failing, wait for tedg to get the fix up | 15:38 |
| joc_ | k | 15:39 |
| elopio | joc_: yes, I was looking at it ... | 15:41 |
| elopio | the example is nice. I think it would be good to have an integration test that checks that when you do snapcraft pull, the parts/part-name dir is empty. | 15:41 |
| elopio | joc_: the integration-tests use plainbox. So for that you would have to add the really simple snapcraft.yaml to integration-tests/data/nil | 15:42 |
| elopio | and write a check in bash in integration-tests/units/jobx.pxu | 15:43 |
| elopio | joc_: and in addition to that, it would be nice to have a unit test that instantiates the plugin. Those are in snapcraft/tests/ | 15:44 |
| joc_ | elopio: makes sense, i was just adding a job for nil-plugin-pkgfiler testing if nmcli was in the snap/usr/bin/ | 15:44 |
| elopio | let me know if you need a hand. | 15:44 |
| joc_ | elopio: thanks, will try and get those ready soon | 15:45 |
| elopio | joc_: We need that, but we still don't have a suite to check things in the examples. It only checks that the build succeeds. | 15:45 |
| elopio | Chipaca: I don't understand this endpoint: /1.0/icons/[icon] | 16:45 |
| elopio | what's an example of [icon] in there? | 16:45 |
| Chipaca | elopio: generic-amd64_1.4.png | 16:54 |
| Chipaca | elopio: but you're not supposed to guess these | 16:54 |
| Chipaca | elopio: they're given in /1.0/packages output | 16:54 |
| elopio | ahh, it's the file name. Makes sense. | 16:54 |
| Chipaca | it's the filename in /var/lib/meta/icons | 16:54 |
| Chipaca | which is preferred over the icon from the snap itself | 16:55 |
| jerryG | Chipaca: where are mir logs kept? Any documentation on mir w/ snappy? | 17:06 |
| Chipaca | jerryG: sudo snappy service logs | 17:07 |
| Chipaca | ogra_: it seems we've got a leftover eth0 in interfaces.d. I know we mount over it, but it'd be tidier if we removed it entirely. I don't know where it comes from though. Do you? | 17:12 |
| ogra_ | Chipaca, not really, but i'm just playing with debug prints in livecd-rootfs, i can add a check to my next image build | 17:12 |
| Chipaca | ogra_: taw | 17:15 |
| ogra_ | i can tell you in ~30min | 17:16 |
| longsleep | ogra_: How long does a livecd-rootfs build run for you? I am wondering what i could do to speed it up .. | 17:18 |
| ogra_ | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image | 17:18 |
| ogra_ | click on the "Successfully built" link for the arch you want to check | 17:18 |
| ogra_ | it has the time | 17:18 |
| longsleep | 8 minutes | 17:19 |
| longsleep | so launchpad builds faster than my workstation | 17:19 |
| ogra_ | (note though that i'm currently experimenting there, the time might be longer than usual due to some debug stuff i added) | 17:19 |
| longsleep | ah am64 - lets checkar m | 17:19 |
| longsleep | ah 21 minutes | 17:19 |
| longsleep | thats more like the time i have here | 17:20 |
| longsleep | (arm) | 17:20 |
| longsleep | i wonder if it would build faster on native arm - or is that building on arm hardware on launchpad? | 17:20 |
| ogra_ | it builds on native arm :) | 17:20 |
| longsleep | ah cool | 17:21 |
| ogra_ | what definitely speeds up if you do local builds is a package proxy | 17:21 |
| longsleep | my qemu thing builds in 15 to 20 minutes | 17:21 |
| ogra_ | beyond that 90% of the build is disk IO depending | 17:22 |
| ogra_ | neither CPU nor RAM are used much | 17:22 |
| longsleep | yeah i have to set this up | 17:22 |
| ogra_ | so a package proxy and an arm board with mSATA socket would help you :) | 17:22 |
| longsleep | to me it seems it spends most time in configuring and unpacking though | 17:22 |
| ogra_ | right | 17:22 |
| ogra_ | disk ... | 17:22 |
| ogra_ | well | 17:23 |
| ogra_ | if you do it in a qemu chroot there is another thing you can try ... create the chroot in a tmpfs ;) | 17:23 |
| ogra_ | that will definitely speed up a lot | 17:23 |
| longsleep | ah yeah thats a nice idea | 17:23 |
| longsleep | i will try that next week for sure | 17:24 |
| Chipaca | longsleep: the ubuntu schroot thing walks you through that, i think | 17:31 |
| jerryG | Chipaca: new set of errors: pastebin.com/Z70S0xiS | 17:37 |
| Chipaca | jerryG: you're building mir with the wrong abi for the system. you need to either include these libs also, or build against the ones on the system | 17:38 |
| jerryG | k thx ill try that | 17:39 |
| longsleep | Chipaca: Ubuntu schroot, i have read that somewhere - what does it walk me through? | 17:49 |
| Chipaca | longsleep: https://wiki.ubuntu.com/SimpleSbuild | 17:50 |
| Chipaca | longsleep: that's oriented around rebuilding packages, but the setup is the same for other uses | 17:50 |
| longsleep | Chipaca: cool thanks | 17:56 |
| longsleep | ogra_: i want to try getting rid of opencryptoki, though i seem to be unable to find where it is actually seeded from - can you give me a hint? | 17:58 |
| ogra_ | depends on the release ... for vivid it should be in live-build/auto/config ... for xenial it is in the seeds | 17:58 |
| longsleep | ogra_: mhm maybe i am blind - let me check auto/config again | 17:59 |
| ogra_ | (the latter means you cant hack it out ... you would have to provide a chroot hook that apt-get pzurges it) | 17:59 |
| ogra_ | hmm, or auto/build | 18:00 |
| longsleep | ogra_: yeah i am doing that hack for python already | 18:00 |
| longsleep | ogra_: mhm its neither in my auto/build nor in auto/config and i am based on (2.301~ppa43) vivid | 18:02 |
| longsleep | ogra_: and built images have it inside, so it must come from somewhere | 18:02 |
| longsleep | strange | 18:02 |
| jerryG | Chipaca: is CXXABI_1.3.9 part of gcc ? | 18:03 |
| Chipaca | jerryG: I *think* it's the c++ standard library abi | 18:04 |
| ogra_ | longsleep, tpm-tools is in the seeds ... opencryptoki is a dependency | 18:05 |
| longsleep | aha! thanks | 18:05 |
| ogra_ | not sure how we solved that for vivid | 18:05 |
| ogra_ | but i think its hacked into livecd-rootfs there | 18:05 |
| longsleep | well, it actually explains why you had to add it - if the tpm tools want it then its clear | 18:06 |
| longsleep | ogra_: vivid has add_package install tpm-tools in auto/config | 18:07 |
| ogra_ | yeah | 18:07 |
| ogra_ | what i thoguht | 18:07 |
| ogra_ | ricmm, your rootfs is done, now the system-image importer just needs to pick it up | 18:12 |
| ricmm | mine | 18:13 |
| ricmm | mineee | 18:13 |
| ricmm | ogra_: working fine | 18:34 |
| ricmm | thanks for the help | 18:34 |
| ogra_ | awesomeness | 18:34 |
| ogra_ | ricmm, let me know if you need anything else, i'm still around for a bit | 18:34 |
| ricmm | dont think so, have a good weekend | 18:35 |
| ricmm | sorry for the last minute req | 18:35 |
| ogra_ | np | 18:35 |
| ogra_ | not last minute ... still working ;) | 18:35 |
| sergiusens | joc_, can you update with master for another travis test run to trigger? | 18:36 |
| george_e | I'm attempting to build a snap package but receiving an error "'stop-timeout' is not an integer". | 19:24 |
| george_e | http://askubuntu.com/questions/694844/stop-timeout-is-not-an-integer-when-generating-snap-package-why | 19:24 |
| george_e | Any ideas what I'm doing wrong? | 19:24 |
| ogra_ | jdstrand, mdeslaur, i'm trying to get rid of initramfs-tools from the snappy rootfs tarball ... sadly apparmor keeps it in, do you see a way to split out an apparmor-initramfs package that would make it possible to remove all the initrd stuff we dont want on a snappy rootfs ? | 22:00 |
| mdeslaur | jdstrand, ogra_: I don't know why we even have that dependency at all | 22:07 |
| ogra_ | heh | 22:08 |
| mdeslaur | jdstrand, ogra_: pretty sure it's vestigial from a long time ago, and isn't necessary anymore | 22:12 |
| jjohansen | jdstrand: ogra_: I can confirm we aren't putting policy in the initramfs atm, and it is not currently required | 22:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!