| liuxg | may I know who has build snap using docker with armhf ubuntu? | 02:49 |
|---|---|---|
| dholbach | good morning | 07:54 |
| zyga | good morning :) | 07:57 |
| fgimenez | good morning | 08:05 |
| === Guest42341 is now known as O | ||
| === O is now known as Guest78101 | ||
| soffokl | ogra_, do you remember, on Friday I asked you about high IOwait for stable Snappy on VirtualBox? | 08:26 |
| soffokl | dmesg give me following output http://pastebin.com/M96u8Che | 08:26 |
| mvo | ogra_: Chipaca found some interessting initrd sizes with recent rolling images, some where ~25mb big and that caused issues with the small /boot partition. were those accidents or will the initrd grow significantly | 08:28 |
| mkarliner | trying to install snappy for RPi2 on mac. It says the image archive format is unsupported. Anyone else have this? | 08:40 |
| dholbach | mvo, can you review https://code.launchpad.net/~dholbach/click-reviewers-tools/1514346/+merge/276961? | 08:54 |
| dholbach | mvo, you can see the error in the connected bug report | 08:55 |
| mvo | dholbach: sure | 08:57 |
| mvo | dholbach: done, thanks | 08:58 |
| dholbach | thanks | 09:01 |
| JamesTait | Good morning all; happy Monday, and happy World Freedom Day! 😃 | 09:40 |
| zyga | I've pushed my firsts bits of capabilitiy work https://github.com/ubuntu-core/snappy/pull/65 | 09:44 |
| zyga | please have a look, take apart and poke holes at, I'm still learning go | 09:44 |
| ogra_ | mvo, they were accidents, it should be back to normal i guess ... if not i have to fix it | 09:49 |
| === Guest78101 is now known as QUESTION | ||
| === QUESTION is now known as Guest78101 | ||
| ogra_ | mvo, hmm, no, it is still 29M ... i'll check | 10:00 |
| * zyga repushed https://github.com/ubuntu-core/snappy/pull/65 with some golint fixes and goes for a quick coffee | 10:08 | |
| longsleep | ogra_: so my live-build did not got much faster when on tmpfs :/ - i guess qemu ist just not faster and i might try it on native arm | 10:09 |
| ogra_ | longsleep, find something with a fast disk then :) | 10:09 |
| longsleep | ogra_: well we have an armhf cluster with ssd usb raid for compiling Iridium browser - that is probably the fastest i can find without buying anything new - its a shame that dpkg cannot be ccached :/ | 10:11 |
| longsleep | distributed dpkg would be nice as well :P | 10:12 |
| woodrowshen | hi, how about the progress of snapcrart with deb plugin ? i saw longsleep has a PR but no actions after CI fonnd errors. | 10:12 |
| longsleep | woodrowshen: sorry, did not have the time for that yet - i use the plugin on daily basis and the CI error is a minor one | 10:13 |
| longsleep | woodrowshen: were are some other suggestions on that plugin i need to investigate | 10:14 |
| longsleep | s/were/there | 10:14 |
| woodrowshen | longsleep: ok, so if i'd like to try deb plugin, i need to patch the commit of PR #53, based on git master, right ? | 10:16 |
| longsleep | woodrowshen: well if you want to try the plugin, just use my branch - sure you can rebase on master if you need some features not yet in my branch | 10:17 |
| woodrowshen | longsleep: i see, thank you. :) | 10:18 |
| ogra_ | mvo, hmm, could it be that we didnt install linux-image-extra in the past ? | 10:21 |
| ogra_ | in our device tarball | 10:21 |
| mvo | ogra_: that might be but I have not checked | 10:21 |
| ogra_ | comparing rolling and 15.04 i see that in the unpacked rolling initrd /lib/modules is 15MB bigger and /lib/firmware is 8M bigger | 10:23 |
| ogra_ | that might account for the extra 10M | 10:23 |
| Chipaca | ogra_: in am image created with the latest rolling, initrd is 8MB | 10:24 |
| woodrowshen | i have another question, snapcraft will happen errors when the snapcraft.yaml only set the field of seccomp for security-overwrites. Why did security-overwrites need to set both of apparmor and seccomp ? | 10:24 |
| Chipaca | ogra_: um, are you talking about initrd? :-) | 10:24 |
| ogra_ | Chipaca, oh ? | 10:24 |
| ogra_ | yes, i'm talking about initrd | 10:24 |
| Chipaca | let me build it again, just to confirm | 10:25 |
| ogra_ | i just downloaded the latest device tarball from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ and it contains a 29M initrd | 10:25 |
| ogra_ | and unpacking it and comparing with one from 15.04 i see ~23M extra stuff in /lib/modules|firmware ... | 10:26 |
| Chipaca | uff | 10:27 |
| ogra_ | when i moved th device tarball creation out of the build process into a clean chroot i just install "linux-generic" ... which pulls in linux-image-extra-* .... i assume that wasnt installe dbefore | 10:28 |
| Chipaca | ogra_: so. 235 builds fine, 236 on (or at least, 236 and 238 :) ) don't, at all; no space left on device. But already 217 was weird: http://pastebin.ubuntu.com/13208129/ | 10:39 |
| Chipaca | you can get to 236+ from 235, but once you're there you can't update any further, either | 10:39 |
| Chipaca | because two 236+-sized things don't fit | 10:40 |
| ogra_ | hmm, that 217 one is werid | 10:40 |
| Chipaca | very wird | 10:41 |
| ogra_ | i only started touchin amd64 around wed. | 10:41 |
| Chipaca | it might be a read herring, but even a red herring can tell you stuff | 10:41 |
| Chipaca | :-) | 10:41 |
| ogra_ | oh, but i see when comparing my initrds that linux-firmware ships about 9M extra for amd/radeon gpu fw. | 10:41 |
| * ogra_ checks when that was added to the package | 10:42 | |
| Chipaca | hold on | 10:43 |
| Chipaca | 238 has the same size initrds as 235, once installed? | 10:44 |
| Chipaca | 6.4M? | 10:44 |
| ogra_ | hmm, no, linux-firmware was 27MB the whole wily circle and recently grew to 29M | 10:44 |
| ogra_ | i'm pretyt sure its linux-image-extra | 10:45 |
| ogra_ | http://paste.ubuntu.com/13208164/ | 10:49 |
| ogra_ | http://paste.ubuntu.com/13208169/ | 10:50 |
| ogra_ | only /lib/modules and /lib/firmware have massively grown | 10:50 |
| ogra_ | hrm | 10:52 |
| ogra_ | but i see linux-image-extra being installed in a 15.04 build log | 10:52 |
| ogra_ | sigh, it doesnt help that some package added a new user over night it seems | 11:21 |
| ogra_ | mvo, were the last two xenial failures your attempts ? | 11:24 |
| mvo | ogra_: I don't think so | 11:24 |
| mvo | ogra_: looks like a passwd change again | 11:25 |
| ogra_ | hmm, someone started a build that failed | 11:25 |
| ogra_ | mvo, yeah | 11:25 |
| ogra_ | now where did the dnsmasq and tts users go ? | 11:28 |
| ogra_ | sigh, so all systemd related UIDs changed for no good reason .. fun | 11:41 |
| ogra_ | aha, because the input grouop disappeared ... | 11:42 |
| ogra_ | hmm, so lool added that group in february but the livecd-rootfs changelog doesnt say why | 11:44 |
| ogra_ | mvo, so when tryting to drop the initramfs generation bits from the rootfs on the weekend i found that ubuntu-snappy has a dep on initramfs-tools-ubuntu-core, could we drop that ? | 11:56 |
| ogra_ | (along with apparmor having a (seemingly useless) dep on initramfs-tools) | 11:57 |
| mvo | ogra_: I think we can for snappy, not sure about apparmor I would have to check | 11:59 |
| ogra_ | mvo, apparmor is in the hands of the security team, they told me its not needed | 11:59 |
| ogra_ | i'll leave it to them to drop it | 11:59 |
| ogra_ | (or make it a recommends or so, which would help as well) | 12:00 |
| ogra_ | sigh, i dont really get how we end up with so many more modules | 12:06 |
| ogra_ | ogra@anubis:~/Devel/branches/livecd-rootfs/initrd$ grep -c lib/modules ramdisk-15.04.manifest | 12:10 |
| ogra_ | 506 | 12:10 |
| ogra_ | ogra@anubis:~/Devel/branches/livecd-rootfs/initrd$ grep -c lib/modules ramdisk-rolling.manifest | 12:10 |
| ogra_ | 720 | 12:10 |
| === joc_ is now known as joc|lunch | ||
| * ogra_ slaps forehead | 12:29 | |
| ogra_ | oh man | 12:29 |
| ogra_ | so gzip vs lzma make 10M difference it seems :P | 12:30 |
| longsleep | lvzm is pretty awesome for file system tarballs but it takes ages to compress | 12:32 |
| ogra_ | yeah, i dont really care how long it takes | 12:32 |
| longsleep | s/lvzm/lzma | 12:32 |
| ogra_ | but i wonder why the default did silently switch to gzip | 12:32 |
| ogra_ | must be some live-build thing | 12:33 |
| longsleep | yeah live-build generates tar.gz for me as well | 12:33 |
| longsleep | system image then build tar.xz | 12:33 |
| ogra_ | i'm only talking about the initrd | 12:33 |
| longsleep | ah | 12:33 |
| Guest42341 | :/ | 12:55 |
| mkarliner_ | Anybody prepared to help a newbie? | 13:14 |
| === joc|lunch is now known as joc_ | ||
| mvo | jdstrand: good news, https://github.com/ubuntu-core/snappy/pull/55 got a +1 from Chipaca - thats your (and mine) security policy generation branch | 13:41 |
| Chipaca | mkarliner: don't ask to ask, just ask | 13:50 |
| mkarliner | OK, I'm confused, is the only way to develop snappy apps to create them on Ubuntu Desktop? | 14:09 |
| mkarliner | Is there no native development on Snappy? | 14:10 |
| ogra_ | on an ubuntu system, yes ... doesnt need to be desktop | 14:10 |
| ogra_ | you can do it on snappy alone in a lxc container | 14:10 |
| Chipaca | on snappy, i'd say no. some people are doing it, but it's complicated. | 14:10 |
| ogra_ | or in a chroot | 14:11 |
| Chipaca | there's going to be a devel snap at some point | 14:11 |
| dholbach | ogra_, mvo: do you all current snappy images have webdm installed? | 14:21 |
| ogra_ | stable definitely., yes | 14:21 |
| ogra_ | for rolling we dont provide dd'able images | 14:21 |
| ogra_ | so its up to the person running ubuntu-device-flash to build it | 14:22 |
| dholbach | ok, thanks | 14:22 |
| ogra_ | s/build/include when building/ | 14:22 |
| mkarliner | Thanks guys. Its just that the getting started page makes absolutely no mention of cross development. | 14:26 |
| === chihchun is now known as chihchun_afk | ||
| === fginther` is now known as fginther | ||
| === balloons is now known as Guest42098 | ||
| === Ursinha_ is now known as Ursinha | ||
| === Guest42098 is now known as balloons_ | ||
| longsleep | Chipaca: Do you have any news on bug #1511435 - it is starting to become a blocker for us soon | 14:59 |
| ubottu | bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,Confirmed] https://launchpad.net/bugs/1511435 | 14:59 |
| Chipaca | gah. longsleep, i dropped that. On it now. | 15:11 |
| jdstrand | sergiusens: before you rip out vendor, please see my comment in the bug | 15:12 |
| longsleep | Chipaca: cool - i build my own snappy based rootfs images now - so let me know if you want me to test some fix to a specific package | 15:14 |
| sergiusens | jdstrand, I saw it; but I have include beuno and niemeyer in that conversation. Long term vendor is going away in any case so I'm not sure how this is going to be enforced given that the store doesn't enforce it at all either | 15:23 |
| sergiusens | as in as a developer I can upload with whatever vendor and have you think everything is good | 15:23 |
| sergiusens | and still see this issue | 15:23 |
| sergiusens | there is no check for, the vendor in this package does not match any of your account emails | 15:23 |
| jdstrand | sergiusens: sure-- I'm not asking for you to change anything per se, however, it seemed that the bit of information I mentioned wasn't considered, and I think it should be. if we remove the check, it will lead to situations where there will be conflicting dbus services and frameworks won't be coninstallable | 15:25 |
| jdstrand | sergiusens: right now, we have to manage the ones that fail the check, like nm and bluez, but those are Canonical provided | 15:26 |
| jdstrand | sergiusens: but the idea was that the vendor could own that reverse namespace, so if they created two frameworks that competed for the bus-name, that is on them to control | 15:26 |
| jdstrand | sergiusens: if we remove the check altogether, it is on the store to make sure there aren't coninstallability concerns | 15:27 |
| sergiusens | jdstrand, maybe the use of bus-name needs to trigger a check on what bus name you actually choose | 15:27 |
| sergiusens | jdstrand, in any case, the store still allowed having two snaps with conflicts here | 15:27 |
| jdstrand | sergiusens: the store would, but it would be on the vendor | 15:28 |
| jdstrand | sergiusens: ie, the vendor owned that slice of dbus namespace | 15:28 |
| jdstrand | sergiusens: I'm not saying we can't change this, just that there is a subtle difference | 15:29 |
| sergiusens | jdstrand, e.g.; I grab a snap you made that included a bus-name, kept vendor as you and I could potentially get into the store as there would be no vendor issue raised | 15:29 |
| sergiusens | jdstrand, I understand fully | 15:29 |
| jdstrand | sergiusens: because the review tools would 'warn' and trigger a manual review if the check failed | 15:29 |
| jdstrand | sergiusens: but if the check passed, then the vendor was in control | 15:29 |
| jdstrand | ok | 15:29 |
| jdstrand | sergiusens: yes, I understand what you are saying too | 15:30 |
| sergiusens | jdstrand, I am just saying we are not enforcing it as the store has no concept of vendor itself | 15:30 |
| sergiusens | ah, good | 15:30 |
| sergiusens | we enforce consistency locally to the snap but not against the ecosystem | 15:30 |
| sergiusens | those are the words I guess that best describe what I wanted to say | 15:30 |
| jdstrand | sergiusens: so what I am taking from this is that you are going to go back to the other guys with this info? | 15:31 |
| jdstrand | and comment in the bug? | 15:31 |
| sergiusens | jdstrand, yes, this also blocks the original bug in any case for moving vendor to an external snapcraft managed file | 15:31 |
| elopio | zyga: I need help with templates. So I have to put this in testplans.pxu *and* in examples.pxu? | 15:33 |
| elopio | http://paste.ubuntu.com/13209194/ | 15:33 |
| === fginther` is now known as fginther | ||
| elopio | plars: I don't get why go get doesn't seem to be doing anything in the test agent. No error either. | 15:44 |
| elopio | do you have a way to try this? go get launchpad.net/godeps | 15:44 |
| plars | elopio: I don't see much output from your test... it looks like it just gets and runs http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job2.sh right? | 15:45 |
| jdstrand | woodrowshen: hey, you asked about security-overrides needing both-- that was for historical reasons, however 16.04 is going to make security-override much easier to use (ie, it'll be actually useful) | 15:45 |
| elopio | plars: yup. I'm trying different things to debug why the go code is not downloaded. | 15:46 |
| plars | elopio: trying it now | 15:47 |
| plars | elopio: godeps: cannot parse "dependencies.tsv": open dependencies.tsv: no such file or directory | 15:49 |
| plars | elopio: I got that when I ran 'godeps -u dependencies.tsv' | 15:49 |
| elopio | right, that comes from go get github.com/ubuntu-core/snappy/... | 15:49 |
| plars | elopio: I think it should be snappy/dependencies.tsv | 15:50 |
| elopio | plars: I just wanted to check if go get downloads the code for you. | 15:50 |
| plars | elopio: it's sitting in the dir underneath that when it runs it | 15:50 |
| plars | elopio: yes, go get launchpad.net/godeps works fine | 15:50 |
| === balloons_ is now known as balloons | ||
| elopio | plars: what do you have in $GOPATH ? | 15:50 |
| elopio | it could be that from my script it's donwloading it somewhere else. | 15:51 |
| plars | elopio: I'm just running it from a test dir under tmp, so I have that | 15:51 |
| plars | elopio: in a real job, it would have a tmpdir created by python tempfile module | 15:51 |
| plars | that's the workspace that spi creates | 15:51 |
| elopio | plars: I'm using export GOPATH="$(pwd)" to download the code in this temp dir for the job. | 15:52 |
| plars | elopio: that's perfect | 15:52 |
| elopio | perfect, except that it doesn't work. | 15:53 |
| plars | elopio: I think it will if you fix that path | 15:53 |
| elopio | plars: sorry, which path? | 15:54 |
| plars | elopio: the one I mentioned earlier with the .tsv file... or is it not even getting that far? Where are you seeing where it gets stuck and what error are you seeing? | 15:56 |
| Chipaca | longsleep: just to be clear, you get this error when making your own oem snap and preinstalling things there? | 15:56 |
| elopio | plars: that was just a workaround for go get not working for me. On this workaround the path was alright, but the godeps binary was not downloaded. So not good. | 15:58 |
| elopio | plars: this fails for me: | 15:58 |
| elopio | export GOPATH="$(pwd)" | 15:58 |
| elopio | go get -d -v github.com/ubuntu-core/snappy/... | 15:58 |
| elopio | cd $GOPATH/src/github.com/ubuntu-core/snappy | 15:58 |
| elopio | saying that the dir doesn't exist. | 15:58 |
| longsleep | Chipaca: yes exactly | 15:58 |
| plars | elopio: can you show me the error? | 15:59 |
| elopio | sure. In about 5 minutes. | 15:59 |
| longsleep | Chipaca: oem snap sideloaded by u-d-f and installing spreed-webrtc.longsleep from the store triggers it | 15:59 |
| plars | elopio: I'm trying that on one of the spi agent hosts, and it's working fine for me | 15:59 |
| longsleep | Chipaca: software: | 16:00 |
| longsleep | built-in: | 16:00 |
| longsleep | - spreed-webrtc.longsleep | 16:00 |
| Chipaca | longsleep: ta | 16:00 |
| longsleep | Chipaca: let me paste you a complete example | 16:01 |
| longsleep | Chipaca: http://paste.ubuntu.com/13209349/ | 16:04 |
| longsleep | Chipaca: so i want to preinstall something and apply config | 16:04 |
| plars | elopio: one thing to be aware of, is that the SPI workdir path is quite long: example: /tmp/run/d5cc3aa6-6ef6-4615-9c7e-e57ca04cc992_2015-11-09T15:51:39.029430 | 16:04 |
| plars | basically uuid+datestamp | 16:04 |
| plars | elopio: I ran the following in a dir just like that though, and it ran: | 16:05 |
| plars | https://www.irccloud.com/pastebin/Q8q0bEhL/ | 16:05 |
| elopio | plars: and did that work? | 16:06 |
| plars | elopio: yes | 16:06 |
| elopio | plars: I'm trying this version now: | 16:08 |
| elopio | export GOPATH="$(pwd)" | 16:08 |
| elopio | go get -d -v github.com/ubuntu-core/snappy/... | 16:08 |
| elopio | still waiting for results... | 16:08 |
| elopio | this one either worked, or it's taking a long time provisioning. | 16:16 |
| elopio | plars: here's the error: http://paste.ubuntu.com/13209409/ | 16:27 |
| elopio | can't cd to /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627/src/github.com/ubuntu-core/snappy | 16:27 |
| plars | elopio: trying to reproduce | 16:30 |
| elopio | plars: when I do this on my xenial machine, I get: go: GOPATH entry is relative; must be absolute path: "53". | 16:32 |
| elopio | but the spi agent doesn't say anything about that. | 16:32 |
| plars | elopio: haha, I know the problem | 16:33 |
| plars | cd /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627/src/github.com/ubuntu-core/snappy | 16:33 |
| Chipaca | longsleep: that's a lovely test | 16:33 |
| plars | err | 16:33 |
| plars | elopio: sec... | 16:33 |
| Chipaca | longsleep: and i can confirm it fails even with a trivial example snap | 16:33 |
| plars | GOPATH=/tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627 | 16:33 |
| Chipaca | elopio: we haz breakage :-/ with a test case that could be added to integration | 16:33 |
| plars | elopio: so the paths are 3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15 and 53 and 58.859627 | 16:34 |
| elopio | Chipaca: good. Tell me more. | 16:34 |
| plars | elopio: so it's sticking src in /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15 which is wrong | 16:34 |
| plars | elopio: I bet | 16:34 |
| elopio | ahhh, I get it plars. | 16:34 |
| plars | ev: ^ something interesting to note about SPI with it's very long and flavorful working dir :). I'm sure it can be worked around, but it has led to several gotchas already | 16:35 |
| Chipaca | elopio: https://bugs.launchpad.net/snappy/+bug/1511435/comments/4 | 16:37 |
| ubottu | Launchpad bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,Confirmed] | 16:37 |
| elopio | plars: can we just remove the timestamp? UUID seems enough. | 16:37 |
| plars | elopio: that's not something I create, that's done by the SPI agent, that's why I cc'd ev | 16:39 |
| elopio | Chipaca: this would need a separate integration suite where we start the vm with a different oem. | 16:39 |
| elopio | so, I'll add a task for that. | 16:40 |
| ogra_ | mvo, ok,. initrd is back to 19M now | 16:41 |
| ogra_ | and i added a ls -l to the build log so we can check there | 16:41 |
| jdstrand | sergiusens: oh, I forgot, it isn't actually so bad with the vendor name check. if we have 'name: foo\nvendor: someone@example.com', the busname check verifies com.example.foo. also, only frameworks can specify bus-name. so, you and I can't upload 'foo', so even if you used example.com, you couldn't trample on com.example.foo | 16:42 |
| noise][ | plars: interesting - you can workaround for now probably by running the agent in —debug which will use a fixed run/debug directory | 16:42 |
| jdstrand | sergiusens: (just some more context for your conversation) | 16:42 |
| noise][ | plars: and i'll file a bug to remove the timestamp | 16:42 |
| sergiusens | jdstrand, right, I got that from the start, but if we want busname to follow something, the conversation is, what should we make it follow for 16.04 | 16:43 |
| * jdstrand nods | 16:43 | |
| elopio | plars: do I have permission to run mktemp -d ? I also tried that during the weekend, but failed. | 16:44 |
| elopio | I couldn't get an error from that either. I'll try again. | 16:45 |
| plars | noise][: I don't think I want a fixed run dir, but I'd recommend that elopio either escape the special chars via sed or some such, or just create your own (and make sure to clean it up) for now | 16:45 |
| plars | elopio: yes, you should be able to do that just fine | 16:45 |
| plars | elopio: not sure why that would fail? | 16:45 |
| noise][ | plars - right, just offering that as a possible temp workaround | 16:46 |
| plars | noise][: indeed | 16:46 |
| elopio | plars: not sure either. I don't understand why running ./snappy-tests-job2.sh $1 $2 > output.txt 2>&1 doesn't put the errors in the output file. | 16:46 |
| plars | elopio: if you'd like, you can just do something like: rm -rf /tmp/elopio && mkdir /tmp/elopio at the beginning, and put all your stuff there... then I could check on it if you like? | 16:48 |
| plars | elopio: keep it really simple for now until we really understand what's going on | 16:48 |
| elopio | plars: that makes sense. Let me finish this try. | 16:48 |
| Chipaca | longsleep: i know how to unblock you, if you're blocked by this | 16:53 |
| longsleep | Chipaca: that would be awesome yes please | 16:54 |
| Chipaca | longsleep: it's a change to the snappy core filesystem though, not sure if you're building that from scratch or not | 16:55 |
| longsleep | Chipaca: not yet, but we surely can | 16:56 |
| longsleep | Chipaca: wait - do you mean the rootfs ? | 16:56 |
| Chipaca | longsleep: yes | 16:56 |
| longsleep | Chipaca: i am building that | 16:56 |
| longsleep | Chipaca: i got livecd-rootfs with all the hooks + custom extensions | 16:57 |
| Chipaca | if you weren't, changing the generated filesystem is also no sweat :) | 16:57 |
| Chipaca | longsleep: /lib/systemd/system/ubuntu-snappy.run-hooks.service | 16:58 |
| Chipaca | longsleep: change it from After=firstboot to Before=firstboot | 16:58 |
| Chipaca | longsleep: \o/ | 16:58 |
| longsleep | lol ok thats simple | 16:58 |
| longsleep | Chipaca: great! | 16:58 |
| longsleep | so i will add a cheap hook to hack that on rootfs building | 16:58 |
| Chipaca | for 15.04 that's enough | 16:58 |
| Chipaca | 16.04 is a bit trickier, but not a lot | 16:58 |
| longsleep | Chipaca: well, i assume it will be fixed when we switch to 16.04 | 16:59 |
| Chipaca | yes, you would assume that :) | 16:59 |
| * Chipaca hopes so too | 16:59 | |
| zyga | elopio: looking at pastebin | 16:59 |
| longsleep | Chipaca: great - thank you very much! | 16:59 |
| Chipaca | longsleep: thank you for finding this :) | 17:00 |
| Chipaca | and for your patience as always | 17:00 |
| zyga | elopio: do you have a branch I can look at? | 17:00 |
| zyga | elopio: that will be much faster | 17:00 |
| elopio | zyga: one second. | 17:01 |
| elopio | zyga: https://github.com/elopio/snapcraft/commit/a091059324765cb48807f237a9acccb8ab23fa72 | 17:02 |
| fgimenez | leaving have a nice evening o/ | 17:12 |
| zyga | elopio: looking | 17:13 |
| zyga | elopio: use $PLAINBOX_PROVIDER_DATA instead of ${PLAINBOX_PROVIDER_DATA} -- easier and less to worry about on quoting | 17:14 |
| zyga | elopio: in your code there's just one line missing | 17:14 |
| * elopio waits for it... | 17:16 | |
| zyga | elopio: have a look | 17:17 |
| zyga | elopio: I think technically only one line is needed | 17:17 |
| zyga | elopio: but I'd apply all the changes I've listed | 17:18 |
| zyga | elopio: have a look | 17:19 |
| zyga | elopio: in the end you will only have two things in the examples.pxu | 17:19 |
| zyga | elopio: the resource (id: examples_resource) | 17:19 |
| zyga | elopio: and a template | 17:19 |
| zyga | elopio: nothing else | 17:19 |
| zyga | elopio: right? | 17:19 |
| elopio | ah, you can comment on the diff even if it's not a pull request | 17:19 |
| elopio | I didn't know that. | 17:19 |
| elopio | zyga: right. | 17:19 |
| zyga | elopio: yeah :) | 17:19 |
| zyga | elopio: neat stuff | 17:19 |
| elopio | zyga: so bootstrap_include instead of bootstrap_jobs? | 17:26 |
| longsleep | Chipaca: i added a hook: http://paste.ubuntu.com/13209799/ - building a new rootfs now | 17:27 |
| zyga | elopio: I think so, it's documented in the plainbox-test-plan-unit manual page | 17:37 |
| zyga | elopio: manage.py validate should say | 17:37 |
| elopio | zyga: ok, I think I got everything you proposed. Now it doesn't fail, but doesn't run anything either. | 17:38 |
| elopio | pushed the commit | 17:39 |
| longsleep | Is there any information what cloud-init actually is doing in snappy? I wish to remove it and wonder if i miss anything important aside from sshd key generation .. | 17:39 |
| elopio | I still don't know if I should duplicate the entier examples_resource section, but I get the same result with or without | 17:40 |
| mkarliner | Does anyone know if python pip is available on Snappy | 17:42 |
| mkarliner | ?? | 17:42 |
| longsleep | mkarliner: See the examples in https://github.com/ubuntu-core/snapcraft/tree/master/examples to learn how to build a snap which includes python. | 17:44 |
| mkarliner | @longsleep - thanks | 17:45 |
| nothal | mkarliner: No such command! | 17:45 |
| zyga | elopio: I'll check it out locally | 17:48 |
| zyga | elopio: sorry for the lag | 17:48 |
| elopio | zyga: don't worry. I'm in no hurry.l | 17:49 |
| === joc_ is now known as joc|away | ||
| elopio | noise][: plars: I think that the result should include a field for the output of the test script. That's in addition to the results payload. | 18:30 |
| elopio | the only ways I have to capture an error like this one are weird: http://paste.ubuntu.com/13209822/ | 18:30 |
| plars | elopio: you can put it in the test result json file, that gets picked up by spi. Otherwise, if it's just raw output, I do capture that in logstash for debugging purposes. Most of your output seems to be redirected to local output files though, so I don't see it (and neither would spi) | 18:34 |
| elopio | plars: I'm redirecting it to files just to debug, because I don't get what the command runs. | 18:35 |
| elopio | something like travis, for example, makes this a little easier. | 18:36 |
| elopio | not a lot easier because you can't reproduce the run environment. But a little. | 18:36 |
| rickspencer3 | stgraber, o/ | 19:44 |
| stgraber | rickspencer3: hey | 19:44 |
| rickspencer3 | I am following instructions here: https://linuxcontainers.org/lxd/getting-started-cli/ | 19:44 |
| rickspencer3 | I snappy installed lxd.stgraber | 19:44 |
| rickspencer3 | but then ... | 19:44 |
| rickspencer3 | $ lxd-images import ubuntu --alias ubuntu | 19:44 |
| rickspencer3 | LXD isn't running. | 19:44 |
| rickspencer3 | thoughts? | 19:44 |
| stgraber | rickspencer3: what are you running snappy on? | 19:45 |
| rickspencer3 | stgraber, my rip2 | 19:45 |
| stgraber | that's probably the problem then | 19:45 |
| stgraber | lxd 0.21 depends on a current symlink to exist under /var/lib/apps/lxd | 19:45 |
| stgraber | and IIRC you need recent-ish snappy for that | 19:45 |
| stgraber | you could try manually creating the symlink from /var/lib/apps/lxd/current to /var/lib/apps/lxd/0.21-1 (which is what recent snappy does for you) | 19:45 |
| rickspencer3 | stgraber, this core is the latest, from Sept. 25 | 19:46 |
| stgraber | then either reboot or bounce the systemd unit | 19:46 |
| stgraber | rickspencer3: yeah, which is nowhere near "recent" when compared to x86, that's the problem | 19:46 |
| rickspencer3 | stystemd unit for ldx, I assume | 19:46 |
| rickspencer3 | ? | 19:46 |
| stgraber | yup | 19:46 |
| stgraber | systemctl -a | grep lxd | 19:46 |
| rickspencer3 | ln -s blah/current blah/0.21-1 ? | 19:47 |
| stgraber | ogra_: any hope of getting new rpi2 images that match what we've got on x86? We have that problem where sideload on recent snappy gets us a random version string so we can't use the version dir anymore and current doesn't exist in current rpi2 images | 19:47 |
| stgraber | rickspencer3: probably lxd/current to lxd/0.21-1 but yeah | 19:47 |
| stgraber | (RaspberryPi2)ubuntu@localhost:~$ ls -lh /var/lib/apps/lxd | 19:48 |
| stgraber | total 4.0K | 19:48 |
| stgraber | drwxr-xr-x 5 root root 4.0K Aug 17 17:24 0.21-1 | 19:48 |
| stgraber | lrwxrwxrwx 1 root root 7 Nov 2 07:06 current -> 0.21-1/ | 19:48 |
| rickspencer3 | thanks stgraber, that seemed to work | 19:52 |
| rickspencer3 | maybe add a note to the wiki? | 19:52 |
| stgraber | great! | 19:52 |
| stgraber | yeah, good point, making a note to update the instructions for rpi2 | 19:53 |
| rickspencer3 | stgraber, so, looks like I am getting server-cloud image | 19:55 |
| stgraber | correct | 19:55 |
| rickspencer3 | that should work fine for running snapcraft, etc..., right? | 19:55 |
| stgraber | I guess so, it's a clean deb based Ubuntu | 19:55 |
| stgraber | note that it's trusty by default unless you tell lxd-images otherwise, but I think the snappy guys have PPAs that work fine on trusty | 19:56 |
| * rickspencer3 wishes he named his container at launch | 20:05 | |
| rickspencer3 | stgraber, so, I am changing this image by installing things to it | 20:05 |
| rickspencer3 | I am not certain how I make that change stick, or do I have to make an image that has the changes in it, and import that into lxc? | 20:06 |
| stgraber | rickspencer3: the container state is persistent so you won't be loosing it on reboot or anything. You can then either make new containers from that container (lxc copy source destination), or do "lxc publish source --alias some-name" which will get you a new image that you can use. | 20:07 |
| rickspencer3 | stgraber, is there a simple set of docs that I can look at so I do things right without asking you at each and every step? ;) | 20:07 |
| stgraber | rickspencer3: outside of the getting started stuff, not really. I've got a todo for today (but will likely end up being tomorrow) to update our demo site with instructions similar to what I do in my demo (which covers all lxd features) | 20:08 |
| rickspencer3 | ack | 20:09 |
| rickspencer3 | basically, I want an ARM build environment for snapcraft | 20:09 |
| rickspencer3 | I wonder if I can make an image that people can easily import that has everything all set up | 20:09 |
| rickspencer3 | stgraber, soooo, I made the snap in the container | 20:19 |
| rickspencer3 | \o/ | 20:19 |
| rickspencer3 | but, um ... what's the best way to get it off the container? just push it somewhere? | 20:19 |
| rickspencer3 | is there an easy way to copy it to the host? | 20:20 |
| stgraber | lxc file pull container-name/path/inside/the/container | 20:20 |
| stgraber | though I can't remember whether that works on snappy, we had some apparmor/path oddities related to that I believe | 20:21 |
| rickspencer3 | wow | 20:22 |
| * rickspencer3 tries | 20:22 | |
| rickspencer3 | stgraber, so, I have the file at /root/zork/whatever.snap | 20:25 |
| rickspencer3 | when I try to file pull, it says permission denied | 20:25 |
| rickspencer3 | and I get an even stranger error when I use sudo | 20:26 |
| stgraber | right, that'd be the bug in question | 20:26 |
| rickspencer3 | ug | 20:26 |
| stgraber | I wonder if doing something odd like "lxc file pull container-name/path/inside/the/container - > blah.snap" would workaround the problem | 20:26 |
| stgraber | so basically have the client spit it out on stdout and then have your shell write it, working around the permission problem | 20:27 |
| * rickspencer3 tries | 20:27 | |
| rickspencer3 | stgraber, fyi ... the - > trick worked, thanks | 20:43 |
| stgraber | cool | 20:43 |
| josepht | rickspencer3: fwiw, I used scp from the host to grab files from the container | 21:03 |
| rickspencer3 | josepht, ack | 21:04 |
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!