liuxgmay I know who has build snap using docker with armhf ubuntu?02:49
dholbachgood morning07:54
zygagood morning :)07:57
fgimenezgood morning08:05
=== Guest42341 is now known as O
=== O is now known as Guest78101
soffoklogra_, do you remember, on Friday I asked you about high IOwait for stable Snappy on VirtualBox?08:26
soffokldmesg give me following output http://pastebin.com/M96u8Che08:26
mvoogra_: 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 significantly08:28
mkarlinertrying to install snappy for RPi2 on mac. It says the image archive format is unsupported. Anyone else have this?08:40
dholbachmvo, can you review https://code.launchpad.net/~dholbach/click-reviewers-tools/1514346/+merge/276961?08:54
dholbachmvo, you can see the error in the connected bug report08:55
mvodholbach: sure08:57
mvodholbach: done, thanks08:58
JamesTaitGood morning all; happy Monday, and happy World Freedom Day! 😃09:40
zygaI've pushed my firsts bits of capabilitiy work https://github.com/ubuntu-core/snappy/pull/6509:44
zygaplease have a look, take apart and poke holes at, I'm still learning go09:44
ogra_mvo, they were accidents, it should be back to normal i guess ... if not i have to fix it09:49
=== Guest78101 is now known as QUESTION
=== QUESTION is now known as Guest78101
ogra_mvo, hmm, no, it is still 29M ... i'll check10:00
* zyga repushed https://github.com/ubuntu-core/snappy/pull/65 with some golint fixes and goes for a quick coffee10:08
longsleepogra_: 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 arm10:09
ogra_longsleep, find something with a fast disk then :)10:09
longsleepogra_: 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
longsleepdistributed dpkg would be nice as well :P10:12
woodrowshenhi, how about the progress of snapcrart with deb plugin ? i saw longsleep has a PR but no actions after CI fonnd errors.10:12
longsleepwoodrowshen: sorry, did not have the time for that yet - i use the plugin on daily basis and the CI error is a minor one10:13
longsleepwoodrowshen: were are some other suggestions on that plugin i need to investigate10:14
woodrowshenlongsleep: 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
longsleepwoodrowshen: 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 branch10:17
woodrowshenlongsleep: 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 tarball10:21
mvoogra_: that might be but I have not checked10: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 bigger10:23
ogra_that might account for the extra 10M10:23
Chipacaogra_: in am image created with the latest rolling, initrd is 8MB10:24
woodrowsheni 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
Chipacaogra_: um, are you talking about initrd? :-)10:24
ogra_Chipaca, oh ?10:24
ogra_yes, i'm talking about initrd10:24
Chipacalet me build it again, just to confirm10:25
ogra_i just downloaded the latest device tarball from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ and it contains a 29M initrd10:25
ogra_and unpacking it and comparing with one from 15.04 i see ~23M extra stuff in /lib/modules|firmware ...10:26
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 dbefore10:28
Chipacaogra_: 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
Chipacayou can get to 236+ from 235, but once you're there you can't update any further, either10:39
Chipacabecause two 236+-sized things don't fit10:40
ogra_hmm, that 217 one is werid10:40
Chipacavery wird10:41
ogra_i only started touchin amd64 around wed.10:41
Chipacait might be a read herring, but even a red herring can tell you stuff10: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 package10:42
Chipacahold on10:43
Chipaca238 has the same size initrds as 235, once installed?10:44
ogra_hmm, no, linux-firmware was 27MB the whole wily circle and recently grew to 29M10:44
ogra_i'm pretyt sure its linux-image-extra10:45
ogra_only /lib/modules and /lib/firmware have massively grown10:50
ogra_but i see linux-image-extra being installed in a 15.04 build log10:52
ogra_sigh, it doesnt help that some package added a new user over night it seems11:21
ogra_mvo, were the last two xenial failures your attempts ?11:24
mvoogra_: I don't think so11:24
mvoogra_: looks like a passwd change again11:25
ogra_hmm, someone started a build that failed11:25
ogra_mvo, yeah11: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 .. fun11: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 why11: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
mvoogra_: I think we can for snappy, not sure about apparmor I would have to check11:59
ogra_mvo, apparmor is in the hands of the security team, they told me its not needed11:59
ogra_i'll leave it to them to drop it11: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 modules12:06
ogra_ogra@anubis:~/Devel/branches/livecd-rootfs/initrd$ grep -c lib/modules ramdisk-15.04.manifest12:10
ogra_ogra@anubis:~/Devel/branches/livecd-rootfs/initrd$ grep -c lib/modules ramdisk-rolling.manifest12:10
=== joc_ is now known as joc|lunch
* ogra_ slaps forehead 12:29
ogra_oh man12:29
ogra_so gzip vs lzma make 10M difference it seems :P12:30
longsleeplvzm is pretty awesome for file system tarballs but it takes ages to compress12:32
ogra_yeah, i dont really care how long it takes12:32
ogra_but i wonder why the default did silently switch to gzip12:32
ogra_must be some live-build thing12:33
longsleepyeah live-build generates tar.gz for me as well12:33
longsleepsystem image then build tar.xz12:33
ogra_i'm only talking about the initrd12:33
mkarliner_Anybody prepared to help a newbie?13:14
=== joc|lunch is now known as joc_
mvojdstrand: good news, https://github.com/ubuntu-core/snappy/pull/55 got a +1 from Chipaca - thats your (and mine) security policy generation branch13:41
Chipacamkarliner: don't ask to ask, just ask13:50
mkarlinerOK, I'm confused, is the only way to  develop snappy apps to create them on Ubuntu Desktop?14:09
mkarlinerIs there no native development on Snappy?14:10
ogra_on an ubuntu system, yes ... doesnt need to be desktop14:10
ogra_you can do it on snappy alone in a lxc container14:10
Chipacaon snappy, i'd say no. some people are doing it, but it's complicated.14:10
ogra_or in a chroot14:11
Chipacathere's going to be a devel snap at some point14:11
dholbachogra_, mvo: do you all current snappy images have webdm installed?14:21
ogra_stable definitely., yes14:21
ogra_for rolling we dont provide dd'able images14:21
ogra_so its up to the person running ubuntu-device-flash to build it14:22
dholbachok, thanks14:22
ogra_s/build/include when building/14:22
mkarlinerThanks 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_
longsleepChipaca: Do you have any news on bug #1511435 - it is starting to become a blocker for us soon14:59
ubottubug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,Confirmed] https://launchpad.net/bugs/151143514:59
Chipacagah. longsleep, i dropped that. On it now.15:11
jdstrandsergiusens: before you rip out vendor, please see my comment in the bug15:12
longsleepChipaca: 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 package15:14
sergiusensjdstrand, 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 either15:23
sergiusensas in as a developer I can upload with whatever vendor and have you think everything is good15:23
sergiusensand still see this issue15:23
sergiusensthere is no check for, the vendor in this package does not match any of your account emails15:23
jdstrandsergiusens: 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 coninstallable15:25
jdstrandsergiusens: right now, we have to manage the ones that fail the check, like nm and bluez, but those are Canonical provided15:26
jdstrandsergiusens: 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 control15:26
jdstrandsergiusens: if we remove the check altogether, it is on the store to make sure there aren't coninstallability concerns15:27
sergiusensjdstrand, maybe the use of bus-name needs to trigger a check on what bus name you actually choose15:27
sergiusensjdstrand, in any case, the store still allowed having two snaps with conflicts here15:27
jdstrandsergiusens: the store would, but it would be on the vendor15:28
jdstrandsergiusens: ie, the vendor owned that slice of dbus namespace15:28
jdstrandsergiusens: I'm not saying we can't change this, just that there is a subtle difference15:29
sergiusensjdstrand, 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 raised15:29
sergiusensjdstrand, I understand fully15:29
jdstrandsergiusens: because the review tools would 'warn' and trigger a manual review if the check failed15:29
jdstrandsergiusens: but if the check passed, then the vendor was in control15:29
jdstrandsergiusens: yes, I understand what you are saying too15:30
sergiusensjdstrand, I am just saying we are not enforcing it as the store has no concept of vendor itself15:30
sergiusensah, good15:30
sergiusenswe enforce consistency locally to the snap but not against the ecosystem15:30
sergiusensthose are the words I guess that best describe what I wanted to say15:30
jdstrandsergiusens: so what I am taking from this is that you are going to go back to the other guys with this info?15:31
jdstrandand comment in the bug?15:31
sergiusensjdstrand, yes, this also blocks the original bug in any case for moving vendor to an external snapcraft managed file15:31
elopiozyga: I need help with templates. So I have to put this in testplans.pxu *and* in examples.pxu?15:33
=== fginther` is now known as fginther
elopioplars: I don't get why go get doesn't seem to be doing anything in the test agent. No error either.15:44
elopiodo you have a way to try this? go get launchpad.net/godeps15:44
plarselopio: 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
jdstrandwoodrowshen: 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
elopioplars: yup. I'm trying different things to debug why the go code is not downloaded.15:46
plarselopio: trying it now15:47
plarselopio: godeps: cannot parse "dependencies.tsv": open dependencies.tsv: no such file or directory15:49
plarselopio: I got that when I ran 'godeps -u dependencies.tsv'15:49
elopioright, that comes from go get github.com/ubuntu-core/snappy/...15:49
plarselopio: I think it should be snappy/dependencies.tsv15:50
elopioplars: I just wanted to check if go get downloads the code for you.15:50
plarselopio: it's sitting in the dir underneath that when it runs it15:50
plarselopio:  yes, go get launchpad.net/godeps works fine15:50
=== balloons_ is now known as balloons
elopioplars: what do you have in $GOPATH ?15:50
elopioit could be that from my script it's donwloading it somewhere else.15:51
plarselopio: I'm just running it from a test dir under tmp, so I have that15:51
plarselopio: in a real job, it would have a tmpdir created by python tempfile module15:51
plarsthat's the workspace that spi creates15:51
elopioplars: I'm using export GOPATH="$(pwd)" to download the code in this temp dir for the job.15:52
plarselopio: that's perfect15:52
elopioperfect, except that it doesn't work.15:53
plarselopio: I think it will if you fix that path15:53
elopioplars: sorry, which path?15:54
plarselopio: 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
Chipacalongsleep: just to be clear, you get this error when making your own oem snap and preinstalling things there?15:56
elopioplars: 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
elopioplars: this fails for me:15:58
elopioexport GOPATH="$(pwd)"15:58
elopiogo get -d -v github.com/ubuntu-core/snappy/...15:58
elopiocd $GOPATH/src/github.com/ubuntu-core/snappy15:58
elopiosaying that the dir doesn't exist.15:58
longsleepChipaca: yes exactly15:58
plarselopio: can you show me the error?15:59
elopiosure. In about 5 minutes.15:59
longsleepChipaca: oem snap sideloaded by u-d-f and installing spreed-webrtc.longsleep from the store triggers it15:59
plarselopio: I'm trying that on one of the spi agent hosts, and it's working fine for me15:59
longsleepChipaca:   software:16:00
longsleep    built-in:16:00
longsleep      - spreed-webrtc.longsleep16:00
Chipacalongsleep: ta16:00
longsleepChipaca: let me paste you a complete example16:01
longsleepChipaca: http://paste.ubuntu.com/13209349/16:04
longsleepChipaca: so i want to preinstall something and apply config16:04
plarselopio: 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.02943016:04
plarsbasically uuid+datestamp16:04
plarselopio: I ran the following in a dir just like that though, and it ran:16:05
elopioplars: and did that work?16:06
plarselopio: yes16:06
elopioplars: I'm trying this version now:16:08
elopioexport GOPATH="$(pwd)"16:08
elopiogo get -d -v github.com/ubuntu-core/snappy/...16:08
elopiostill waiting for results...16:08
elopiothis one either worked, or it's taking a long time provisioning.16:16
elopioplars: here's the error: http://paste.ubuntu.com/13209409/16:27
elopiocan't cd to /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627/src/github.com/ubuntu-core/snappy16:27
plarselopio: trying to reproduce16:30
elopioplars: when I do this on my xenial machine, I get: go: GOPATH entry is relative; must be absolute path: "53".16:32
elopiobut the spi agent doesn't say anything about that.16:32
plarselopio: haha, I know the problem16:33
plarscd /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627/src/github.com/ubuntu-core/snappy16:33
Chipacalongsleep: that's a lovely test16:33
plarselopio: sec...16:33
Chipacalongsleep: and i can confirm it fails even with a trivial example snap16:33
Chipacaelopio: we haz breakage :-/ with a test case that could be added to integration16:33
plarselopio: so the paths are 3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15     and    53    and    58.85962716:34
elopioChipaca: good. Tell me more.16:34
plarselopio: so it's sticking src in /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15 which is wrong16:34
plarselopio: I bet16:34
elopioahhh, I get it plars.16:34
plarsev: ^ 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 already16:35
Chipacaelopio: https://bugs.launchpad.net/snappy/+bug/1511435/comments/416:37
ubottuLaunchpad bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,Confirmed]16:37
elopioplars: can we just remove the timestamp? UUID seems enough.16:37
plarselopio: that's not something I create, that's done by the SPI agent, that's why I cc'd ev16:39
elopioChipaca: this would need a separate integration suite where we start the vm with a different oem.16:39
elopioso, I'll add a task for that.16:40
ogra_mvo, ok,. initrd is back to 19M now16:41
ogra_and i added a ls -l to the build log so we can check there16:41
jdstrandsergiusens: 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.foo16:42
noise][plars: interesting - you can workaround for now probably by running the agent in —debug which will use a fixed run/debug directory16:42
jdstrandsergiusens: (just some more context for your conversation)16:42
noise][plars: and i'll file a bug to remove the timestamp16:42
sergiusensjdstrand, 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.0416:43
* jdstrand nods16:43
elopioplars: do I have permission to run mktemp -d ? I also tried that during the weekend, but failed.16:44
elopioI couldn't get an error from that either. I'll try again.16:45
plarsnoise][: 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 now16:45
plarselopio: yes, you should be able to do that just fine16:45
plarselopio: not sure why that would fail?16:45
noise][plars - right, just offering that as a possible temp workaround16:46
plarsnoise][: indeed16:46
elopioplars: 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
plarselopio: 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
plarselopio: keep it really simple for now until we really understand what's going on16:48
elopioplars: that makes sense. Let me finish this try.16:48
Chipacalongsleep: i know how to unblock you, if you're blocked by this16:53
longsleepChipaca: that would be awesome yes please16:54
Chipacalongsleep: it's a change to the snappy core filesystem though, not sure if you're building that from scratch or not16:55
longsleepChipaca: not yet, but we surely can16:56
longsleepChipaca: wait - do you mean the rootfs ?16:56
Chipacalongsleep: yes16:56
longsleepChipaca: i am building that16:56
longsleepChipaca: i got livecd-rootfs with all the hooks + custom extensions16:57
Chipacaif you weren't, changing the generated filesystem is also no sweat :)16:57
Chipacalongsleep: /lib/systemd/system/ubuntu-snappy.run-hooks.service16:58
Chipacalongsleep: change it from After=firstboot to Before=firstboot16:58
Chipacalongsleep: \o/16:58
longsleeplol ok thats simple16:58
longsleepChipaca: great!16:58
longsleepso i will add a cheap hook to hack that on rootfs building16:58
Chipacafor 15.04 that's enough16:58
Chipaca16.04 is a bit trickier, but not a lot16:58
longsleepChipaca: well, i assume it will be fixed when we switch to 16.0416:59
Chipacayes, you would assume that :)16:59
* Chipaca hopes so too16:59
zygaelopio: looking at pastebin16:59
longsleepChipaca: great - thank you very much!16:59
Chipacalongsleep: thank you for finding this :)17:00
Chipacaand for your patience as always17:00
zygaelopio: do you have a branch I can look at?17:00
zygaelopio: that will be much faster17:00
elopiozyga: one second.17:01
elopiozyga: https://github.com/elopio/snapcraft/commit/a091059324765cb48807f237a9acccb8ab23fa7217:02
fgimenezleaving have a nice evening o/17:12
zygaelopio: looking17:13
zygaelopio: use $PLAINBOX_PROVIDER_DATA instead of ${PLAINBOX_PROVIDER_DATA} -- easier and less to worry about on quoting17:14
zygaelopio: in your code there's just one line missing17:14
* elopio waits for it...17:16
zygaelopio: have a look17:17
zygaelopio: I think technically only one line is needed17:17
zygaelopio: but I'd apply all the changes I've listed17:18
zygaelopio: have a look17:19
zygaelopio: in the end you will only have two things in the examples.pxu17:19
zygaelopio: the resource (id: examples_resource)17:19
zygaelopio: and a template17:19
zygaelopio: nothing else17:19
zygaelopio: right?17:19
elopioah, you can comment on the diff even if it's not a pull request17:19
elopioI didn't know that.17:19
elopiozyga: right.17:19
zygaelopio: yeah :)17:19
zygaelopio: neat stuff17:19
elopiozyga: so bootstrap_include instead of bootstrap_jobs?17:26
longsleepChipaca: i added a hook: http://paste.ubuntu.com/13209799/ - building a new rootfs now17:27
zygaelopio: I think so, it's documented in the plainbox-test-plan-unit manual page17:37
zygaelopio: manage.py validate should say17:37
elopiozyga: ok, I think I got everything you proposed. Now it doesn't fail, but doesn't run anything either.17:38
elopiopushed the commit17:39
longsleepIs 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
elopioI still don't know if I should duplicate the entier examples_resource section, but I get the same result with or without17:40
mkarlinerDoes anyone know if python pip is available on Snappy17:42
longsleepmkarliner: 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 - thanks17:45
nothalmkarliner: No such command!17:45
zygaelopio: I'll check it out locally17:48
zygaelopio: sorry for the lag17:48
elopiozyga: don't worry. I'm in no hurry.l17:49
=== joc_ is now known as joc|away
elopionoise][: 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
elopiothe only ways I have to capture an error like this one are weird: http://paste.ubuntu.com/13209822/18:30
plarselopio: 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
elopioplars: I'm redirecting it to files just to debug, because I don't get what the command runs.18:35
elopiosomething like travis, for example, makes this a little easier.18:36
elopionot a lot easier because you can't reproduce the run environment. But a little.18:36
rickspencer3stgraber, o/19:44
stgraberrickspencer3: hey19:44
rickspencer3I am following instructions here: https://linuxcontainers.org/lxd/getting-started-cli/19:44
rickspencer3I snappy installed lxd.stgraber19:44
rickspencer3but then ...19:44
rickspencer3$ lxd-images import ubuntu --alias ubuntu19:44
rickspencer3LXD isn't running.19:44
stgraberrickspencer3: what are you running snappy on?19:45
rickspencer3stgraber, my rip219:45
stgraberthat's probably the problem then19:45
stgraberlxd 0.21 depends on a current symlink to exist under /var/lib/apps/lxd19:45
stgraberand IIRC you need recent-ish snappy for that19:45
stgraberyou 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
rickspencer3stgraber, this core is the latest, from Sept. 2519:46
stgraberthen either reboot or bounce the systemd unit19:46
stgraberrickspencer3: yeah, which is nowhere near "recent" when compared to x86, that's the problem19:46
rickspencer3stystemd unit for ldx, I assume19:46
stgrabersystemctl -a | grep lxd19:46
rickspencer3ln -s blah/current blah/0.21-1 ?19:47
stgraberogra_: 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 images19:47
stgraberrickspencer3: probably lxd/current to lxd/0.21-1 but yeah19:47
stgraber(RaspberryPi2)ubuntu@localhost:~$ ls -lh /var/lib/apps/lxd19:48
stgrabertotal 4.0K19:48
stgraberdrwxr-xr-x 5 root root 4.0K Aug 17 17:24 0.21-119:48
stgraberlrwxrwxrwx 1 root root    7 Nov  2 07:06 current -> 0.21-1/19:48
rickspencer3thanks stgraber, that seemed to work19:52
rickspencer3maybe add a note to the wiki?19:52
stgraberyeah, good point, making a note to update the instructions for rpi219:53
rickspencer3stgraber, so, looks like I am getting server-cloud image19:55
rickspencer3that should work fine for running snapcraft, etc..., right?19:55
stgraberI guess so, it's a clean deb based Ubuntu19:55
stgrabernote that it's trusty by default unless you tell lxd-images otherwise, but I think the snappy guys have PPAs that work fine on trusty19:56
* rickspencer3 wishes he named his container at launch20:05
rickspencer3stgraber, so, I am changing this image by installing things to it20:05
rickspencer3I 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
stgraberrickspencer3: 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
rickspencer3stgraber, 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
stgraberrickspencer3: 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
rickspencer3basically, I want an ARM build environment for snapcraft20:09
rickspencer3I wonder if I can make an image that people can easily import that has everything all set up20:09
rickspencer3stgraber, soooo, I made the snap in the container20:19
rickspencer3but, um ... what's the best way to get it off the container? just push it somewhere?20:19
rickspencer3is there an easy way to copy it to the host?20:20
stgraberlxc file pull container-name/path/inside/the/container20:20
stgraberthough I can't remember whether that works on snappy, we had some apparmor/path oddities related to that I believe20:21
* rickspencer3 tries20:22
rickspencer3stgraber, so, I have the file at /root/zork/whatever.snap20:25
rickspencer3when I try to file pull, it says permission denied20:25
rickspencer3and I get an even stranger error when I use sudo20:26
stgraberright, that'd be the bug in question20:26
stgraberI wonder if doing something odd like "lxc file pull container-name/path/inside/the/container - > blah.snap" would workaround the problem20:26
stgraberso basically have the client spit it out on stdout and then have your shell write it, working around the permission problem20:27
* rickspencer3 tries20:27
rickspencer3stgraber, fyi ... the - > trick worked, thanks20:43
josephtrickspencer3: fwiw, I used scp from the host to grab files from the container21:03
rickspencer3josepht, ack21:04
=== chihchun_afk is now known as chihchun

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!