[00:02] <elopio> sergiusens: that would be a reason to ignore my comment.
[00:03] <sergiusens> elopio, the orignal code was like that
[00:06] <sergiusens> elopio, I'll switch to it; but you get the Chipaca into furiosa mode
[00:07] <sergiusens> :)
[00:07] <sergiusens> elopio, seems minimal http://paste.ubuntu.com/13655053/
[00:07] <Chipaca> ummm
[00:08] <Chipaca> is this about the if thing == 'foo': foo() elif thing == 'bar': bar() elif thing == 'potato': brotato()?
[00:08] <Chipaca> ?
[00:09] <sergiusens> Chipaca, yeah, like the paste above
[00:10] <Chipaca> is there no 'none of the above' case?
[00:10] <sergiusens> Chipaca, or the execute function I made you look at earlier
[00:10] <sergiusens> Chipaca, hah :-)
[00:10] <sergiusens> Chipaca, you can offer one :-)
[00:11] <Chipaca> i mean, in execute, it was the 'step' variable, right?
[00:11] <Chipaca> and you checked three things
[00:11] <Chipaca> are those all the values step can take?
[00:11] <sergiusens> Chipaca, yeah
[00:11] <sergiusens> elopio, for ref https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42
[00:11] <elopio> furiosa mode, lol
[00:12] <Chipaca> I dislike spurious use of getattr(), but a forest of if/elif is what getattr avoids :)
[00:12] <sergiusens> Chipaca, one more, strip
[00:12] <Chipaca> sergiusens: so in your perf checking code, add a 'd' to the tests
[00:12] <sergiusens> Chipaca, I have
[00:13] <sergiusens> Chipaca, http://paste.ubuntu.com/13655167/
[00:13] <sergiusens> just didn't share it
[00:13] <elopio> also this is public, so we would need to catch the case where the step argument is not one of the allowed.
[00:13] <sergiusens> it is neglible to the point of asking, which is more pleasant to read
[00:13] <Chipaca> sergiusens: um, no, i mean
[00:13] <Chipaca> sergiusens: in https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42
[00:13] <Chipaca> sergiusens: step can take three values
[00:14] <Chipaca> grah
[00:14]  * Chipaca tired
[00:14] <Chipaca> sergiusens: step can take *four* values
[00:14] <Chipaca> sergiusens: but you only do stuff for *three* of them
[00:14] <Chipaca> that is, it's not a direct getattr(self, step)()
[00:15] <elopio> Chipaca: that's work in progress. He has the fourth case in another branch.
[00:15] <Chipaca> ah. If that's the case, then it's a nobrainer getattr
[00:15] <sergiusens> Chipaca, so 4 hits the mark?
[00:15] <Chipaca> siiiiiiigh
[00:16] <Chipaca> i'll try to explain it with short words
[00:16] <Chipaca> because i'm tired and can't type long ones
[00:16] <sergiusens> Chipaca, elopio oh wait, wait there is an hidden reason I did it like this
[00:16] <sergiusens> well, I can do it differently, no worries
[00:17] <Chipaca> sergiusens: shoot
[00:17] <sergiusens> Chipaca, the 'force' logic in the current code is very dark sideish
[00:17] <Chipaca> force?
[00:17] <sergiusens> Chipaca, I was planning to make force, only force the desired step and not all the previous ones
[00:17] <Chipaca> ah
[00:17] <sergiusens> snapcraft build --force
[00:18] <Chipaca> that sounds like an --only more than a --force, but --whatevs
[00:18] <sergiusens> Chipaca, but I can make the 'force' param for each step smarter by not having it there and do it differently
[00:19] <sergiusens> so no getattr until otherwise mentioned it is
[00:19] <sergiusens> Chipaca, thanks for being the 3rd opinion on this :-)
[00:19] <sergiusens> tie breaker ;-)
[00:19] <Chipaca> is it bad if i understood nothing about where force comes in to play?
[00:20]  * Chipaca looks at the code a bit more
[00:20] <sergiusens> Chipaca, I removed all the 'force' mentions in this new code to reimplement it correctly
[00:20] <sergiusens> Chipaca, current force does what follows...
[00:22] <Chipaca> i'm writing a long thing about my opinion on this, because i was unable to write it short
[00:22] <Chipaca> i have 45 minutes to do it in (after which the battery dies)
[00:22] <Chipaca> hopefully it will be less than that :-)
[00:22] <sergiusens> hah
[00:24] <sergiusens> Chipaca, hmm, never mind me, --force is useless
[00:32]  * elopio goes for cryptobeers
[00:32] <elopio> I'll bbl, drunk and anonymous.
[00:35] <Chipaca> sergiusens: https://gist.github.com/chipaca/a49c1f6888c2f6dd4184
[00:37] <Chipaca> i hope it makes sense
[00:37] <elopio> Chipaca: the dict solution is nice.
[00:37] <Chipaca> it's often the hardest to read though
[00:38] <Chipaca> :)
[00:42] <Chipaca> ooh, forgot one
[00:44] <sergiusens> Chipaca, it is indeed hard to read :)
[00:44] <Chipaca> elopio: sergiusens: added one last one just for fun, and now yes g'night
[07:17] <dragunov11> hi, wanted to know if its possible to create our own snappy store.
[07:34] <dragunov11> hi, wanted to know if its possible to create our own snappy store.
[08:10] <fgimenez> good morning
[08:13] <dholbach> good morning
[09:03] <zyga> good morning
[09:52] <JamesTait> Good morning all; happy Friday, and happy World Wildlife Conservation Day! 😃
[10:06] <liuxg> dholbach, ping
[10:07] <dholbach> liuxg, pong
[10:08] <liuxg> dholbach, in my python project, I need to install some extra packages like django for instance. How can I do it in the snapcraft.yaml file?
[10:09] <liuxg> dholbach, I have seen that webcam example, it has a setup file, and it installs a package like pyyaml, does it only apply for config.py only?
[10:09] <dholbach> liuxg, do you want to install them locally on your machine or do you want to install them in the resulting .snap package?
[10:10] <liuxg> dholbach, in the snap package
[10:10] <dholbach> you use stage-packages to include them in your .snap
[10:10] <zyga> dholbach: I think he can also use pip plugin to use upstream releases directly
[10:11] <zyga> liuxg: I haven't tried that in a while but give it a try
[10:11] <zyga> liuxg: it has access to fresh software faster this way
[10:11] <liuxg> dholbach, can I do the same like the one in the file https://github.com/ubuntu-core/snapcraft/blob/master/examples/webcam-webui/setup.py?
[10:11] <liuxg> zyga, thanks. then what is the syntax for doing pip?
[10:12] <liuxg> zyga, dholbach I have seen it is done in the setup.py in the webcam project
[10:12] <dholbach> liuxg, as an exercise it's a good idea to separate all the individual bits into parts and find out where their source/binaries come from, how they are built/installed, if all of the files need to be installed
[10:13] <dholbach> so if for example you have a couple of files you want to ship which don't make use of a build system (like cmake or setuptools or anything else), you could use the copy plugin
[10:13] <dholbach> so it entirely depends on your setup
[10:15] <zyga> liuxg: I don't really remember, let me try to find that
[10:15] <liuxg> dholbach, for my specific example, django is already there for installation. I need it for my app. how can I install it. is it the same way like the fswebcam?
[10:15] <dholbach> you could take django from the archive?
[10:15] <liuxg> dholbach, either way, I think it has apt-get and pip
[10:16] <dholbach> so add       stage-packages: [python-django]
[10:16] <liuxg> zyga, thanks
[10:17] <liuxg> dholbach, thanks, I will have a try on that. by the way, can a plugin support more than one stage-packages?
[10:17] <dholbach> yes
[10:17] <liuxg> dholbach, it is interesting. I will try to an exercise for it :)
[10:18] <dholbach> cool :)
[10:18] <zyga> liuxg: try this https://github.com/ubuntu-core/snapcraft/blob/f8176788e6a932998c9cac3f98c3eb78c40fcab3/snapcraft/plugins/python3.py#L32
[10:18] <zyga> liuxg: it seems that it's merged with python2/3 plugin now
[10:18] <zyga> liuxg: just pass a path to requirements.txt
[10:19] <zyga> liuxg: and it will pip-install anyhting you need
[10:19] <zyga> liuxg: let me know if that works, I'm curious myself
[10:19] <dholbach> stage-packages should probably be easier in this case... unless you need a very specific django version
[10:20] <dholbach> and want to maintain the version number yourself
[10:20] <liuxg> zyga, what is the form of requirements.txt?
[10:23] <dholbach> liuxg, something like this:
[10:23] <dholbach> Framework==0.9.4
[10:23] <dholbach> Library>=0.2
[10:23] <dholbach> hi sergiusens
[10:25] <zyga> liuxg: normal requirements file, you can make one like this:
[10:25] <zyga> liuxg: create a virtualenv
[10:25] <zyga> liuxg: setup.py install your stuff there (or pip install anything you need)
[10:25] <zyga> liuxg: then run: pip freeze
[10:25] <zyga> liuxg: that's your requirements file
[10:25] <zyga> liuxg: so when it works for you in virtualenv you can pip freeze and put that into snappy
[10:25] <zyga> sergiusens: o/
[10:26] <dholbach> going with the archive is probably easier ;-)
[10:26] <dholbach> sorry :)
[10:26] <dholbach> but yeah.. it would probably be good to test that as well :)
[10:26] <zyga> dholbach: if your stuff is in the archive
[10:26] <zyga> dholbach: at the right version
[10:26] <dholbach> django is
[10:26] <liuxg> zyga, thanks for the info. it sounds like some info like the one here http://www.django-rest-framework.org/tutorial/quickstart/. just append pip freeze there?
[10:26] <zyga> dholbach: requirements can also pull straight from git/hg/bzr at any revision/tag
[10:26] <dholbach> yep, that's right
[10:27] <zyga> liuxg: looks like it
[10:27] <liuxg> zyga, is it like http://paste.ubuntu.com/13665491/?
[10:28] <liuxg> zyga, I will have a try for that.
[10:28] <sergiusens> o/
[10:28] <zyga> liuxg: that's not requirements.txt
[10:28] <zyga> liuxg: that's something you can run in your shell
[10:29] <zyga> liuxg: then you can pip freeze
[10:29] <zyga> liuxg: and redirect that to > requirements.txt
[10:29] <liuxg> zyga, so what does a requirements.txt look like?
[10:29] <zyga> liuxg: run that and see
[10:31] <liuxg> zyga, do you have any example or document for this? it is hard for developers to figure out.
[10:32] <sergiusens> liuxg, a requirements.txt is not hard for a developer already working on python
[10:33] <sergiusens> dholbach, you can make the QA 6am my time I guess
[10:34] <liuxg> sergiusens, how to integrate it into snapcraft may be a problem.
[10:36] <liuxg> sergiusens, do you have any simple example for that? thanks
[10:37] <sergiusens> liuxg, snapcraft help python3
[10:37] <sergiusens> liuxg, look at the requirements keyword text, it says to point it to the path to your requirements.txt
[10:39] <liuxg> sergiusens, in the python-packages, it installs all of the needed packages? right?
[10:43] <liuxg> sergiusens, for my case, I need to run django on snappy, how does the requirement looks like. If I use virtualenv, how can I start the app/service in this case? I have seen a simple django tutorial at http://www.django-rest-framework.org/tutorial/quickstart/, thanks
[10:44] <dholbach> sergiusens, are you sure that's not too early?
[10:50] <liuxg> zyga, do you know how to run a python project in an virtualenv on snappy??
[10:55] <zyga> liuxg: I don't think you need virtualenv on snappy per se
[10:55] <zyga> liuxg: (you can in classic mode for testing)
[10:55] <zyga> liuxg: you want to develop your project locally if you can, using virtualenv
[10:55] <zyga> liuxg: and then package that with snapcraft
[10:56] <liuxg> zyga, yes, that is what I think. we just install everything to the space of the snappy app.
[10:58] <liuxg> zyga, the python3 plugin supports requirements and python-packages, what is the difference between them?
[10:58] <liuxg> zyga, in the requirements.txt, we can install the packages, how about the python-packages? do they do the same thing?
[10:59] <zyga> liuxg: I actually don't know - I'd have to read the source of the plugin
[10:59] <zyga> liuxg: get started with requirements
[11:00] <liuxg> zyga, we truly need more documents and examples for the tool. Even though for an experienced developer, he may get stuck without diving into it.
[11:03] <sergiusens> dholbach, it is fine
[11:03] <dholbach> sergiusens, ok... I'll tell Kay
[11:52]  * zyga fiddles with GPIOs and LEDs for a demo
[12:31] <olli> pers
[12:31] <olli> +morning sna...
[12:39] <ogra_> heh
[13:00] <liuxg> sergiusens, would you please show me a simple example how to use the requirements.txt to install django for my python project? thanks. I did not figure it out. thanks!
[13:22] <olli> mvo, how do I get all snap goodness on my Pi? rickspencer3 threw me off yday by saying he built an image... I would have expected to just download our pi reference image
[13:23]  * rickspencer3 braces
[13:23] <ogra_> olli, we dont have any downloadable images for rolling
[13:23] <ogra_> the reference image is stable
[13:23] <rickspencer3> olli, I did this:
[13:23] <rickspencer3> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
[13:24] <rickspencer3> I don't know if or how well the system is documented, but this created an image for me quite quickly, then I just dd'ed it over
[13:24] <rickspencer3> hmmm, though I just noticed it says pi2.canonical/stable :/
[13:25] <ogra_> thats correct
[13:25] <ogra_> u-d-f doesnt know about channels yet
[13:25] <rickspencer3> ack
[13:25] <ogra_> so you need /stable
[13:25] <rickspencer3> confusing, but "ack" ;)
[13:26] <olli> ogra_, ah, remember
[13:26] <olli> ogra_, which u-d-f do I want?
[13:26] <olli> there was a specific branch iirc
[13:26] <olli> sergiusens, ^
[13:26]  * olli is gathering stuff for his 18h journey tomorrow
[13:26] <zyga> olli: lucky you
[13:27] <ogra_> olli, just the latest :)
[13:27] <olli> zyga, lucky as I have time to check out your demo ;)
[13:27]  * ogra_ is on 0.31-0ubuntu1 on trusty ... that works fine ... though i think there was a newer release
[13:51] <sergiusens> olli, I thought you needed mvo's specific branches
[13:51] <sergiusens> olli, for u-d-f
[13:51] <sergiusens> olli, this is until we have time to implement ubuntu-image
[13:51] <mvo> rickspencer3, ogra_, olli: let me check and fix the need to add rpi2/stable
[13:51] <mvo> sergiusens: for non all-snap images the old u-d-f is still ok
[13:51] <mvo> sergiusens: probably changes after the sprint
[13:51] <sergiusens> oh, wrt channels, I haven't been involved in any preempt work
[13:52] <rickspencer3> mvo, oh, so does that mean the version I have now is not all snaps?
[13:52] <sergiusens> mvo, oh, and it works? Notice olli was specifically asking about "all snaps"
[13:53] <mvo> sergiusens: ups, srry, I overlooked the all-snaps bit :/
[13:53] <mvo> rickspencer3: yeah, you are still old-school, I only have a BBB all-snap image at this point
[13:53] <rickspencer3> oh man
[13:53] <rickspencer3> what a bummer
[13:53] <mvo> olli: sorry, I missed the all-snap part, we have no rpi2 image right now ready, I need to build a kernel snap first, let me do this
[13:53] <mvo> rickspencer3: sorry!
[13:54] <rickspencer3> mvo, could someone document how to get a rolling 16.04 all snap image somewhere?
[13:54] <rickspencer3> even just an email to the list would be nice
[13:54] <mvo> rickspencer3: so here is the issue - I can not upload ubuntu-core for armhf to the store because I can only have one name for each architecture and I use ubuntu-core for amd64 already. should I wait for the store to fix this or call it ubuntu-core-armhf ?
[13:55] <mvo> rickspencer3: there is on all-snap rpi2 image or bbb image because of the naming issue. but I may make this too complicated and just use ubuntu-core-armhf and ubuntu-kernel-rpi2 as names?
[13:56] <mvo> in the store?
[13:57] <rickspencer3> mvo, I don't think I have enough context to make that decision
[13:57] <rickspencer3> but it seems like we want people using all snaps asap
[13:58] <rickspencer3> I think we want the feedback asap wrt what is working perfectly and what is working not perfectly right now
[13:58] <rickspencer3> is it reasonable to use your naming trick on a temporary basis?
[13:59] <mvo> rickspencer3: I think so, people may need to manually switch later to a new anme but I guess thats ok
[13:59] <rickspencer3> olli, thoughts? ^
[13:59] <rickspencer3> I think olli is the right person to facilitate this decision
[13:59] <rickspencer3> I worry that I am just impatient ;)
[13:59] <olli> we stopped worrying about that and accepted it as a fact
[13:59] <olli> years ago
[14:00] <rickspencer3> haha
[14:00] <mvo> let me make a image for you guys using a sideloaded kernel so that at least there is something
[14:00] <olli> was hoping we can discuss in BRA next week
[14:00] <olli> mvo, I can create an image myself if above u-d-f does the trick
[14:01] <mvo> olli: for all-snaps you need the ubuntu-device flash from https://people.canonical.com/~mvo/all-snaps/ and I need to push a rpi2 kernel into the store. I guess pi2-kernel is a good name(?)
[14:02] <mvo> ogra_: any preferences for the kernel name for the pi2?
[14:03] <ogra_> mvo, we already have a name
[14:03] <mvo> olli: I'm on it now and can make you a sideloaded image and we can talk about the store names via g+ if you want or I can send you a mail with the problem summary whatever you prefer. but maybe I make this too complicated and just upload ubuntu-core-armhf
[14:03] <mvo> ogra_: we do?
[14:03] <ogra_> just use the name we use for the channel and for the current kernel package
[14:04] <ogra_> "raspi2"
[14:04] <mvo> ogra_: works for me, thanks
[14:04] <olli> mvo, ok, if you can make an image without being negatively impacted from your sprint prep then that's fine for today
[14:04] <olli> everything else (naming) we can cover next week
[14:04] <olli> if I don't get an image today I am ok too
[14:06] <mvo> olli: thanks!
[14:06] <BrianLinuxing> Hello
[14:06] <BrianLinuxing> I've got a snappy related question
[14:07] <BrianLinuxing> Is there any good reason why Snappy couldn't work on the new Pi Zero? (once an image was built)
[14:10] <ogra_> BrianLinuxing, yes ...
[14:11] <ogra_> BrianLinuxing, Pi zero uses a very old ARM arch (like the Pi1 ... ) there is no way to use that with ubuntu
[14:11] <mvo> ogra_: where is the source for the pi2 oem snap? I would like to modify it for the all-snap os/kernel uboot environment
[14:11] <ogra_> mvo, hmm, on my disk ... let me dig it up and push somewhere
[14:11] <mvo> ogra_: thanks! I especially need the uboot.env.in file :)
[14:13] <BrianLinuxing> Gotcha Orga, but if Debian can be built for Pi Zero, wondering why not Snappy?
[14:14] <ogra_> mvo, http://paste.ubuntu.com/13669072/
[14:14] <tbr> BrianLinuxing: debian does not exist for pizero, raspbian does, which is a full rebuild.
[14:14] <ogra_> BrianLinuxing, debian cant be built for pi zero ... raspbian can
[14:15] <ogra_> you could indeed do the same for ubuntu ... it is essential a completely new archive arch you need to create
[14:15] <ogra_> (which is a whole lot of work)
[14:15] <tbr> and then there would be no binary apps running, because they are all for armv7 or x86_64
[14:16] <ogra_> right
[14:16] <rickspencer3> mvo, I'm with olli, if it's not easy to get the all snaps image out today, just wait until the right time
[14:16] <ogra_> mvo, the paste was u-boot.env.in FWIW
[14:16] <rickspencer3> I can use the old school arch for the time being
[14:17] <BrianLinuxing> Ok, finger trouble raspbian (and seemingly a version of Arch), assuming all of that, what's the issue blocking Snappy on an A6?
[14:17] <ogra_> BrianLinuxing, there is no ubuntu for ARMv6
[14:18] <ogra_> the ubuntu armhf arch is built for v7
[14:18] <ogra_> like the debian one
[14:18] <ogra_> or any other relevant distro nowadays
[14:18] <ogra_> the raspbian people take the whole archive, change the compiler defaults and re-build the whole distro
[14:19] <BrianLinuxing> got it
[14:19] <mvo> ogra_: thanks, what is the size of the uboot env for the rpi2? i.e. what mkenvimage parameter do I have to use?
[14:19] <ogra_> mvo, same as for bbb
[14:19] <BrianLinuxing> so there is no technical reason why it couldn't be built, just its a lot of work?
[14:19] <ogra_> should all be identical
[14:20] <mvo> rickspencer3: I should be able to make a sideloaded one and will see what I can do about the store. maybe I'm just too cautious :/
[14:20] <ogra_> BrianLinuxing, well, you could set up your own archive server, your own build infrastructure and rebuild ubuntu the same way as raspbian rebuilds debian, yes
[14:20] <rickspencer3> mvo, I think it makes sense to be cautious about uploading to the store without thinking it through
[14:20] <BrianLinuxing> is there a full build procedure for snappy for a7? so I can look at replicating on an a6
[14:20] <BrianLinuxing> thank orga :)
[14:21] <ogra_> BrianLinuxing, no ... you need the ubuntu build infrastructure set up for this ...
[14:21] <ogra_> it is a million of steps that involves quite a lot of people
[14:21] <tbr> BrianLinuxing: canonical doesn't really document their infrastructure, that helps them retain control over ubuntu </my_opinion>
[14:21] <BrianLinuxing> ok, how would one replicate the ubuntu build infrastructure set up
[14:21] <ogra_> first of all you would need the rebuilt archive (which will take you 6 months or more i guess)
[14:21] <BrianLinuxing> I have a lot of kit
[14:22] <tbr> BrianLinuxing: step one, hire 20-50 build engineers ;)
[14:22] <ogra_> thenm you would need to replicate the cdimage and live-build infrastructure ubuntu uses
[14:22] <ogra_> after that you would have tarballs
[14:23] <ogra_> then you need to set up a system-image server that creates the deltas of these tarballs and tuns them into consumable system-image pieces that ubuntu-device-flash can build images from
[14:23] <ogra_> i guess tbr's assumption of 20 devs isnt to far off
[14:23] <tbr> BrianLinuxing: if you want targeted distributions, look at buildroot, yocto+openembedded+angstrom/poky
[14:23] <BrianLinuxing> tbr, I am old but nimbled fingered :)
[14:23] <ogra_> unless you have a year of time or more :)
[14:23] <BrianLinuxing> OK
[14:24] <ogra_> and once you are done, none of the snap packages from the snapstore would run
[14:24] <BrianLinuxing> not wishing to state the obvious, but y'all know Pi Zero will take off like a rocket?
[14:24] <ogra_> since they are built for armhf (v7)
[14:24] <tbr> oh and you would also be left with the fact that you can't call it ubuntu
[14:24] <ogra_> right
[14:24] <tbr> and MUST remove the word ubuntu from all the source code and everywhere
[14:25] <ogra_> nah
[14:25] <ogra_> thats nonsense :)
[14:25] <BrianLinuxing> of course
[14:25] <tbr> well, the issue is contended and there are diverging opinions
[14:25] <ogra_> you need to remove all copyright relevant bits ...
[14:25] <BrianLinuxing> got that.
[14:26] <ogra_> but surely not changelog entries that reference @ubuntu.com and such :) or readmes that refer to ubuntu etc
[14:26] <tbr> ask a lawyer and they will side with me ;)
[14:26] <ogra_> it is moot anyway
[14:26] <BrianLinuxing> but back to my point, y'all know 30,000 Pi Zeros sold out in < a week
[14:26] <ogra_> BrianLinuxing, yeah, not much different from Pi1
[14:26] <ogra_> yet we cant support it
[14:27] <BrianLinuxing> [let me cut to the chase, not interested in copyright nonsense, just wondered if there were any good technical reasons for not having it]
[14:27] <tbr> BrianLinuxing: yes, and recently still huge numbers of VW Golf I and Beetle and Transporter were produced in south america
[14:27] <ogra_> (at least not without making armhf unusable for most other ARM arches)
[14:27] <tbr> the technical reasons were named in the beginning already
[14:27] <BrianLinuxing> fair enough, remember that thought :)
[14:28] <ogra_> BrianLinuxing, the techincal reasons are that a build for the v6 arch disables many/most v7 features
[14:28] <tbr> it is an enormous overhead and cost to run two arches instead of one
[14:28] <ogra_> which means ubuntu on phones would for example be really slow and have a lot larger binaries
[14:28] <ogra_> or ubuntu for clouds where arm is also used a lot
[14:29] <BrianLinuxing> if its part politics, resources, etc I get that
[14:29] <ogra_> no
[14:29] <BrianLinuxing> but Pi Zero will be big.
[14:29] <ogra_> it is part of money and manhours that arent available
[14:29] <BrianLinuxing> off to CoreOS, thanks for the chat :)
[14:29] <tbr> BrianLinuxing: and keep in mind, every second more ARMv7 devices are sold, than RPi ARMv6 devices in a month or even a year.
[14:30] <ogra_> sonamoe recently told me a new archi might cost between 10.20Mio
[14:30] <ogra_> *10-20
[14:30]  * ogra_ grins at olli 
[14:30] <tbr> my personal opinion is that pizero will always remain a toy, a moderately popular toy.
[14:30] <tbr> everyone wanting to get real work done has moved on from ARMv6 to ARMv7 or AArch64 long ago
[14:31] <ogra_> i'd say its more like 5-10 Mio ... but it is definitely a lot of money
[14:31] <ogra_> right, and the latter two are the arches ubuntu supports
[14:32] <tbr> truth hurz
[14:32] <ogra_> yeah
[14:33] <mvo> ogra_: do you mind if I put the pi2 stuff into lp:~snappy-dev/snappy-hub/snappy-systems next to bbb and amd64?
[14:33] <ogra_> mvo, not at all !
[14:34] <ogra_> i was plannin to do that sice a while but it always moved to the bottom of my TODO with more important tasks on the list
[14:35] <mvo> ogra_: tell me about TODO lists - just like memory in a C program, it keeps growing
[14:35] <mvo> ogra_: but I can do it while waiting for me sd card to finish writing :)
[14:36] <ogra_> yeah, ARM work gives you a lot of slack all the time :)
[15:05] <Chopper> I'm sure this has been asked before. https://developer.ubuntu.com/en/snappy/start/#try-x86 - It appears as though you can't install Snappy onto a hard disk via an installer, you can only run it off a USB device?
[15:05] <Chopper> If this is the case, is Snappy not really meant for bare metal installations?
[15:10] <mvo> ogra_: your advice would be great, I have my pi2 snap but it seems like there is something wrong with the env, it tries to load /vmlinuz which does not make sense from the uboot.env.in file. uEnv.txt is empty fwiw
[15:10] <mvo> ogra_: I send you an image
[15:11] <mvo> ogra_: anything I can do to debug?
[15:11] <ogra_> mvo, is that the existing uboot binary ?
[15:12] <mvo> ogra_: I guess, I did not change anything on the pi2, its brand new
[15:12] <ogra_> i dont see it loading uboot.env
[15:13] <mvo> ogra_: how can I debug this? sorry, arm noob
[15:13] <ogra_> well, you should see a "loading uboot.env"
[15:14] <ogra_> are you sure the file is in the right place ?
[15:14] <mvo> ogra_: it shows up on my sd card :) but maybe  I just download the pre-build rpi2 image and compare the two filesystem trees
[15:15] <elopio> sergiusens: how were the prerequisites implemented before? also with recurssion?
[15:15] <ogra_> mvo, looks to me like it isnt recognized at all
[15:15] <mvo> ogra_: whats the boot sequence normally? which of the file is loaded/run in system-boot?
[15:15] <ogra_> mvo, also screen -L helps a lot
[15:15] <mvo> ogra_: hm, the card you mean?
[15:15] <sergiusens> elopio, it was broken before
[15:15] <ogra_> (to log all serial output to a logfile)
[15:16] <mvo> ogra_: I have it on a norma monitor right now, no serial
[15:16] <sergiusens> elopio, just hidden as pull, build, stage, strip was done for a complete part before moving to the next
[15:16] <ogra_> mvo, it loads the binary blob (start.bin or how thats called) then uboot-bin ... then uboot loads the uboot.env *before* it loads uEnv-txt
[15:16] <sergiusens> elopio, but if you did `snapcraft build` and one part depended on the other it would break
[15:17] <elopio> sergiusens: so if now you do snapcraft build, the parts that are reqs will be staged.
[15:18] <sergiusens> elopio, yes, it is a semantic requirement I want to introduce for `after`, it doesn't make sense otherwise
[15:18] <elopio> maybe it would be worth printing something about that. Staging part bla because it's a requisite of this other part.
[15:19] <sergiusens> elopio, that is a good point indeed
[15:19] <elopio> sergiusens: I like your fancy recursion, but it scares me. The only thing that prevents this to go to infinite are the stamp files that say that a step for a part was already run, right?
[15:23] <Chopper> Think I found my answer - https://developer.ubuntu.com/en/snappy/start/installation-tips/
[15:24] <mvo> ogra_: hm, hm, anything I can type in the uboot commandline prompt to give me a clue ? I'm downloading the image now fwiw to see if I can find anything
[15:25] <ogra_> mvo, printenv and see if the vars from the .in file show up there
[15:31] <sergiusens> elopio, oh, you think we should add levels? I think python has a limit in itself
[15:32] <sergiusens> elopio, also, circular dependency checks on load_config prevent a circular eternal loop
[15:32] <elopio> sergiusens: that's a good thing to mention on this function, somewhere.
[15:33] <elopio> sergiusens: I don't understand what you mean by levels.
[15:33] <sergiusens> elopio, have execute take a recursion_level param and check it on entry
[15:34] <ogra_> mvo, you can also check with fatls and fatload if the file is found and can be loaded
[15:36] <mvo> ogra_: usb keyboard does not work *sigh* so I need to find a serial cable
[15:36] <mvo> ogra_: I wonder if the one from the bbb will work
[15:40] <ogra_> mvo, it will, only attach RX/TX/GND though
[15:42] <zyga> sergiusens: what's the best way to have meta/stuff in snapcraft.yaml, I'd like a config hook
[15:44] <ogra_> zyga, you just add "config: config.sh" and snapyp config will call that script
[15:44] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml
[15:45] <zyga> ogra_: perfect, thanks!
[15:47] <rickspencer3> ogra_, any idea what this might mean?
[15:47] <rickspencer3> http://pastebin.ubuntu.com/13670711/
[15:47] <rickspencer3> or maybe that is Chipaca?
[15:48] <ogra_> rickspencer3, looks liek a bug to me
[15:48] <mvo> rickspencer3: happening on pi2 rolling I assume?
[15:48] <ogra_> no idea when/where snappy update calls mkdir
[15:48] <rickspencer3> mvo yes
[15:50] <rickspencer3> I logged a bug, fwiw https://bugs.launchpad.net/snappy/+bug/1522889
[15:51] <ogra_> rickspencer3, my update via autopilot worked tonight ... (i'm on 76 here)
[15:51] <ogra_> rickspencer3, could your disk be full ?
[15:52] <rickspencer3> ogra_, I guess so
[15:52] <sergiusens> zyga, use config: <path to config>
[15:53] <rickspencer3> ogra_, it doesn't look full: http://pastebin.ubuntu.com/13670818/
[15:54] <ogra_> 533M free in /writable/cache/system, yeah that should be enough
[15:55] <ogra_> oh
[15:56] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy search
[15:56] <ogra_> Name              Version Summary
[15:56] <ogra_> classic.mvo       1.0-3   classic
[15:56] <ogra_> generic-amd64.mvo 2.0     generic-amd64
[15:56] <ogra_> (RaspberryPi2)ubuntu@localhost:~$
[15:56] <ogra_> where are all the snaps gone !
[15:56] <ogra_> did the store change again ?
[15:56] <ogra_> beuno, ^^^ ?
[15:57] <ogra_> this used to show a lot more packages with yesterdays image
[15:57] <Guest55209> ogra_: beuno is on holiday
[16:02] <ricmm> ogra_: why do you see generic-amd64 in the rpi2 results
[16:02] <ricmm> :D
[16:02] <Chipaca> ogra_: what snappy image is that?
[16:03] <Chipaca> ricmm: because all-snaps
[16:03] <ogra_> Chipaca, rpi, todays image
[16:03] <Chipaca> ogra_: on an unrelated subject, what is rpi2 version 0.16?
[16:04] <ogra_> Chipaca, the OEM snap
[16:04] <Chipaca> ogra_: newish?
[16:04] <ogra_> no, ancient
[16:04] <ogra_> mvo just tries to update it
[16:09] <mvo> ogra_: hm, once I get rolling to boot…
[16:10] <ogra_> mvo, hmm, which mkenvimage do you use to create the uboot.env ?
[16:10] <ogra_> i think i used the one from ym local uboot build
[16:14] <mvo> ogra_: hm, indeed my bbb uboot env code give me a bad checksum error
[16:14] <mvo> ogra_: so different format it seems
[16:14] <mvo> joy
[16:14] <ogra_> but it tries to load it at lest
[16:14] <ogra_> your screenshot didnt have any indication it tried to load it at all
[16:15] <mvo> ogra_: indeed. i compared the system-boot and they look similar on my image
[16:15] <mvo> ogra_: I play with the env now and see what I can find out
[16:15] <ricmm> just need 1 bit to go ~ for it to not boot
[16:15] <ogra_> worst case give me your .in file and i'll ive you the .env
[16:16] <ogra_> i still have the tree here
[16:17] <mvo> ogra_: its here http://bazaar.launchpad.net/~mvo/snappy-hub/snappy-systems-new-kernel-os-logic/view/head:/pi2/boot-assets/uboot.env.in - please mail me the bin file and the command you used I will document that in the readme
[16:18] <mvo> ogra_: hmmmm, size is also very different from bbb
[16:19] <ogra_> how can that be ?
[16:19] <ogra_> you define the size in mkenvimg
[16:19] <mvo> ogra_: ignore me, mixed up files, now it does print me the right output, lets see what my image prints
[16:30] <ogra_> mvo, mail with uboot.env is out
[16:30] <olli> ogra_, shiny!
[16:31] <ogra_> see if that works any better
[16:32] <mvo> ogra_: thanks I will try that
[16:32] <ogra_> did ou use -r to mkenvimage ?
[16:32] <mvo> ogra_: but maybe it was a red herring, I will let you know
[16:32] <mvo> ogra_: yes
[16:32] <ogra_> k, that should be good then
[16:32] <mvo> ogra_: I used http://bazaar.launchpad.net/~mvo/snappy-hub/snappy-systems-new-kernel-os-logic/view/head:/pi2/boot-assets/README
[16:32] <ogra_> right
[16:32] <mvo> ogra_: but maybe something else funny is going on, I investigate
[16:33] <ogra_> iven that fw_setenv needs to be able to read/write them they need to be kind of indentical :)
[16:47] <ogra_> mvo, where do the values for snappy_good_os and snappy_good_kernel come from ?
[16:48] <ogra_> (and snappy_os/snappy_kernel)
[16:50] <mvo> ogra_: thats something that u-d-f will set
[16:50] <mvo> ogra_: on image creation
[16:51] <mvo> ogra_: hm, interessting clue
[16:52] <ogra_> mvo, so i can replace my uboot.env on the running rpi with the one i mailed you and fw_printenv properly shows all values
[16:52] <ogra_> so i guess it would boot fine too
[16:53] <mvo> ogra_: let me try to investigate if that snappy_{os,kernel} setting does not work correctly, that looks like a candidate for the rootcause
[16:53] <ogra_> mvo, well it should still load the env and tell you about that
[16:54] <ogra_> does it do that now  ?
[16:54] <mvo> ogra_: it does not tell me that it loads it, no :/
[16:54] <ogra_> weird
[17:01] <mvo> yeah, maybe its only showing that it loads the env on the serial console not on the main hdmi screen
[17:01] <mvo> (?)
[17:01] <mvo> just a guess
[17:09] <kyrofa> So I'm trying to snap an app that determine's the user's homedir via getpwuid(geteuid()), and that's giving it /home/ubuntu. If the getpwuid call returns NULL then it'll check $HOME, which means I can work around this in two ways: either make getpwuid() fail or make getpwuid() return the confined HOME. Any suggestions?
[17:10] <ogra_> mvo, oh, damn, i forgot that you dont use serial
[17:10] <mvo> ogra_: it boots now and crashes, but progress!
[17:10] <kyrofa> (note that I can't change the src)
[17:11] <ogra_> mvo, with your or my uboot.env ?
[17:11] <ogra_> (do you need my mkenvimage binary ?)
[17:12] <mvo> ogra_: I think it crashes in kernel or initrd maybe in my uboot code, I need a sertial port now as it flashes too quickly away
[17:13] <ogra_> yeah, hard to debug without
[17:15] <kyrofa> Ooo wait, scratch my above problem, it checks another env variable first
[17:20] <mvo> ogra_: http://paste.ubuntu.com/13672523/ is where I am now
[17:20] <mvo> ogra_: but dinner first
[17:21] <ogra_> mvo, looks like a typo somewhere ... or wrong quoting
[17:26] <dholbach> elopio, thanks for the review - I lifted the content from the Dell doc
[17:39] <dholbach> kyrofa, elopio: can you handhold me through a rebase?
[17:39] <kyrofa> dholbach, definitely :)
[17:39] <dholbach> I can't say I enjoy working with git
[17:40] <kyrofa> dholbach, yeah it has a learning cliff
[17:40] <elopio> I'm sorry daniel, I'm afraid I can't do that.
[17:40] <kyrofa> dholbach, but once it "clicks" you'll get it!
[17:40]  * ogra_ hugs dholbach 
[17:40] <elopio> it's friday, it's time for me to delete all my repos and branches and start again.
[17:41] <rickspencer3> did anyone else read elopio's response in HAL's voice?
[17:41] <kyrofa> rickspencer3, yes, I'm curious if he was actually making a joke or not though
[17:41] <ogra_> rickspencer3, how can you not read these words in that voice :)
[17:41] <rickspencer3> me too
[17:41] <davmor2> rickspencer3: elopio is HAL did they not warn you of that
[17:42] <kyrofa> dholbach, ANY way... let me understand what you're doing here. Is this the branch that you targeted to master, and now you're trying to get them into 1.x as well?
[17:42] <elopio> Dave, this conversation can serve no purpose anymore. Goodbye.
[17:42] <davmor2> rickspencer3: it's really scary for me
[17:42] <rickspencer3> lol
[17:42] <davmor2> see
[17:43] <davmor2> rickspencer3: rather Hal than skynet though right :)
[17:43] <ogra_> whats wrong with skynet ?
[17:43] <ogra_> :)
[17:44] <dholbach> kyrofa, in https://github.com/ubuntu-core/snapcraft/pull/146 I pushed some changes, but was confused since the coverage percentage dropped (I added a doc to the branch), so I updated it to current tip again, pushed some more changes, and yes it's against 1.x
[17:44] <kyrofa> davmor2, depends on who's voice you'd say skynet used
[17:44] <davmor2> kyrofa: minions always the minions ;)
[17:45] <dholbach> kyrofa, you are right, it contains other changes - sorry
[17:45] <dholbach> maybe I'll just delete it and propose a new PR
[17:45] <kyrofa> dholbach, nahh, this is a learning opportunity!
[17:45] <elopio> dholbach: if you change only docs, feel free to ignore coveralls. It tends to get confused.
[17:45] <kyrofa> dholbach, let me pull your branch down real quick, hold on
[17:46] <dholbach> yeah, but I just realised that it's 18:45 on Friday, so maybe looking at it on Monday will make more sense? ;-)
[17:46] <davmor2> ogra_: did you see the latest terminator???? And you still have the nerve to ask that ;)
[17:46] <kyrofa> dholbach, haha, no problem!
[17:47] <kyrofa> dholbach, feel free to scratch it and start over, but if you want to figure it out ping me on Monday, I'd be happy to help :)
[17:47] <dholbach> I'd definitely come back for some more learning though because I need it - I feel like http://i.imgur.com/xVyoSl.jpg a lot when dealing with git
[17:47] <dholbach> kyrofa, ^
[17:47] <dholbach> thanks a lot for your offer of help! :)
[17:47] <dholbach> all right my friends - I call it a day - have a great weekend and see you on Monday!
[17:48] <kyrofa> dholbach, you'll get there! Actually there's a really good video you should watch if you have the time: https://www.youtube.com/watch?v=1ffBJ4sVUb4
[17:48] <dholbach> cool, noting it down
[17:49] <dholbach> hah, 4 year olds, that's reassuring
[17:49] <dholbach> thanks kyrofa - have a good one! :)
[17:57] <sergiusens> elopio, 151 is up
[17:58] <mvip> mectors: I'm happy to announce that we've begun our Snappy porting ;)
[17:58] <mvip> (Sorry if that was sent twice. Got reconnected)
[17:59] <elopio> sergiusens: is it called strip because it will just remove unnecessary parts?
[17:59] <mvip> mectors: let's just get those last other pieces sorted asap. :)
[18:00] <mvip> mectors: Viktor from Screenly :)
[18:00] <sergiusens> elopio, heh, it's in the spec :-P
[18:00] <mvip> mectors: no worries ;)
[18:01] <mvip> mectors: it's not as obvious as your ;)
[18:01] <elopio> I know, but I don't like the name. Too late to say that?
[18:01] <mvip> mectors: ah ok
[18:01] <sergiusens> elopio, it doesn't stick well; it won't be a hard change
[18:01] <elopio> mvip: \o/ welcome.
[18:03] <mvip> mectors: deal!
[18:03] <mvip> mectors: we should have something proper to show by then.
[18:04] <mvip> elopio: thanks btw :)
[18:05] <mvo> ogra_, Chipaca: ok, here is the issue - the sideloaded version number uses upper and lower-case. but vfat is only lower-case
[18:05] <mvo> (or upper case)
[18:06] <ogra_> yeah, upper
[18:07] <mvip> mectors: you in London next week? Maybe drop by for a coffee?
[18:08] <ogra_> mvo, your setnev issue is the quotes though i guess
[18:09] <mvip> mectors: cool. I can swing by for a coffee in the afternoon or a beer in the evening. Whichever you prefer.
[18:10] <ogra_> mvo, or rather the missing quotes for the bit where you added equal signs ... i.e. setenv mmcroot /dev/disk/by-label/writable ${snappy_cmdline} snappy_os=${snappy_os} snappy_kernel=${snappy_kernel}
[18:10] <ogra_> setenv freaks out if you dont get this 100% right
[18:10] <ogra_> i'd try something like: setenv mmcroot '/dev/disk/by-label/writable ${snappy_cmdline} snappy_os=${snappy_os} snappy_kernel=${snappy_kernel}'
[18:10] <mvip> mectors: also, please meet renat. He's one of our devs working on Snappy.
[18:11] <mvip> renat: welcome ;)
[18:11] <renat> Hi all! My name is Renat. I'm working on Screenly and invited by Viktor (mvip).
[18:11] <renat> mvip: Good evening!
[18:12] <ogra_> welcome guys :)
[18:13] <mvip> We had a bit of discussion internally for where to store content on disk that will be persistent through versions and can be shared across different Snaps
[18:14] <mvip> Is there a best praxis for where to store these?
[18:14] <mvip> *best practise
[18:15] <renat> And will not require too complex AppArmor config.
[18:17] <ogra_> well, currently there is no such space
[18:17] <ogra_> snaps cant see anything outside their allowed dirs
[18:18] <ogra_> you could share and mirror stuff via network ports i guess ... and store them in one snaps environment in $SNAP_APP_DATA_PATH
[18:19] <mvip> ogra_: We're talking about gigabytes of data tho (potentially)
[18:19] <ogra_> why do you have to use different snaps btw
[18:20] <mvip> ogra_: to keep each snap as simple as possible.
[18:20] <renat> ogra_, to limit access for each service.
[18:20] <mvip> and that :)
[18:20] <ogra_> well, but then you also limit their capabilities
[18:21] <ogra_> (like shared files)
[18:21] <ogra_> i'm not sure where content sharing inside snappy is on the TODO of the security team ... you might want to ask jdstrand
[18:22] <zyga> jdstrand: ping
[18:22] <zyga> jdstrand: I need some emergency help
[18:22] <mvip> ogra_: the reasoning is also that the overhead for isolating each service in a snap is minimal, so it creates a nice isolation
[18:22] <zyga> jdstrand: I have snappy hw-assign to /sys/class/gpio/gpio67/value
[18:22] <zyga> jdstrand: it doesn't work at runtime (I get EPERM on open)
[18:23] <ogra_> mvip, well, but it also limits the abilities to chare data between services
[18:23] <zyga> jdstrand: from my reading of the default template (I'll pastebin the whole thing in a sec) it seems that all of /sys is off-limits (no /sys r, /sys/** r, rules like there are for /dev)
[18:23] <ogra_> *share
[18:23] <zyga> jdstrand: do I guess right or is something else at play?
[18:24] <zyga> jdstrand: full apparmor profile: http://pastebin.ubuntu.com/13673818/
[18:24] <kyrofa> elopio, when you have time: https://github.com/ubuntu-core/snapcraft/pull/152
[18:25] <mvip> ogra_: we just need a socket and files on disk. Other than that, the services are fully independent.
[18:25] <mvip> ogra_: also, they're using different frameworks. Some are Python, others QT
[18:25]  * zyga is blind, there are /sys rules below dev rules
[18:26]  * zyga has no theory anymore
[18:26] <ogra_> well, you need to bundle that anyway
[18:26] <mvip> ogra_: but this should all be doable with a custom AppArmour policy, no?
[18:27] <kyrofa> zyga, I see this in your paste:
[18:27] <kyrofa> # Do the same with /sys/devices and /sys/class to help people using hw-assign
[18:27] <kyrofa>   /sys/devices/ r,
[18:27] <kyrofa>   /sys/devices/**/ r,
[18:27] <kyrofa>   /sys/class/ r,
[18:27] <kyrofa>   /sys/class/**/ r,
[18:27] <ogra_> mvip, depends ...
[18:28] <zyga> kyrofa: yes, I saw that too (now)
[18:28] <zyga> so now how to see what's the EPERM about
[18:29] <zyga> ahh
[18:29] <zyga> I see
[18:29] <zyga> Dec  4 18:26:48 localhost kernel: [ 3321.964683] audit: type=1400 audit(1449253608.501:26): apparmor="DENIED" operation="open" profile="caps-demo.sideload_bool-file_IHGIDOLcSPKD" name="/sys/devices/platform/ocp/481ac000.gpio/gpio/gpio67/value" pid=2058 comm="python3" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=0
[18:29] <zyga> that makes sense
[18:29] <zyga> good, so I just have to provide realpath
[18:30] <zyga> ufff
[18:30] <kyrofa> zyga, wait, it looks like that profile will only allow read-only
[18:30] <ogra_> mvip, changing apparmor rules means manual reviews ... unless you have a dedicated part of the store for your product, then you can freely do that
[18:30] <mvip> ogra_ i spoke with ricmm in Madrid about this a few weeks back and that was my impression from the conversation
[18:30] <mvip> ogra_: we'll have a dedicated store
[18:30] <ogra_> right, it is a matter of context ;)
[18:31] <ogra_> yeah, then you can indeed just adjust apparmor rules and even have dirs shared between snaps
[18:31] <mvip> ogra_: :)
[18:31] <ogra_> the normal store wouldnt allow that
[18:31] <zyga> kyrofa: yes, I hw-assign (kind of) rwk (whatever "k" is)
[18:31] <mvip> ogra_: fair enough.
[18:31] <dstaley> Hi there! I just installed the Snappy Core image on my Raspberry Pi 2 and I seem to be running into issues upgrading ubuntu-core. It downloads fine and prompts me to reboot, but once I issue the reboot command it falls off the network. I'm unable to SSH back into it until I manually pull the power and turn it back on. However, after that ubuntu-core hasn't been updated. Any ideas?
[18:31] <kyrofa> zyga, a lock
[18:31] <mvip> ogra_: so there is no best practise of where to store this data then i preseume
[18:32] <ogra_> dstaley, which channel do you use ?
[18:32] <renat> mvip, I believe that it should be located in /var/
[18:32] <ogra_> mvip, i would put it into one of the snaps into SNAP_APP_DATA_PATH ...
[18:32] <mvip> renat: yeah, i have no strong opinion. I just wanted to make sure we follow best practice if there was one
[18:33] <mvip> renat: yeah that's fine then. Go ahead and do it that way ;)
[18:33] <renat> mvip, thanks.
[18:33] <renat> ogra_, thanks for help.
[18:33] <ogra_> dstaley, in xenial there was a bug that only got fixed with todays image (revision 76 in the rolling/edge channel)
[18:33] <dstaley> ogra_: I'm unsure. How would I check that?
[18:34] <ogra_> dstaley, well, how/where did you get that image ?
[18:34] <ogra_> there are no downloadable xenial images so you would know if you created one yourself :)
[18:34] <dstaley> Oh it looks like it's 15.04 stable
[18:34] <ogra_> right
[18:36] <zyga> it was a realpath issue
[18:36] <zyga> apparmor and symlinks don't play well
[18:36] <zyga> jdstrand: all is good, alarm off :)
[18:39] <sergiusens> elopio, kyrofa simple pimple https://github.com/ubuntu-core/snapcraft/pull/153/files
[18:46] <dstaley> Well, this is strange! I just pulled the power and SSH'd back into it. Got "snappy autopilot triggered a reboot to boot into an up to date system"
[18:50] <mvo> ogra_: one more step http://paste.ubuntu.com/13674418/ - "data abort" - wonder what that means
[18:51] <ogra_> mvo, to big for the reserved ram space ?
[18:51] <ogra_> (just guessing, never seen "data abort")
[18:51] <ogra_> unless your kernel is corrupt somehow
[18:51] <jdstrand> zyga: sorry I didn't respond sooner. apparmor plays fine with symlinks, it (necessarily for security) resolves them. there is a bug report I think that a community member filed on having snappy resolve them
[18:52] <jdstrand> zyga: but I think it was deprioritized because hw-assign is the old way (not sure about that)
[19:00] <sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/154
[19:04] <sergiusens> elopio, last but not least https://github.com/ubuntu-core/snapcraft/pull/155
[19:05] <sergiusens> elopio, and that is all I have, anything newer needs work (the `snap` command ;-) )
[19:05] <sergiusens> and updating the integration tests
[19:17] <plars> elopio: when I try to run run-tests locally, I get "go tool: no such tool "vet""
[19:27] <mvo> ogra_: hm, where can I find the options you use for the initrd pi2 compression?
[19:29] <elopio> plars: checkout the main README
[19:30] <elopio> you could also go run ./integration-tests/main.go, which will skip the style checks.
[19:33] <plars> elopio: that's what I was following, I got some other strange errors when I tried running it directly yesterday, but it seems to be running better now
[19:47] <ogra_> mvo, livecd-rootfs
[19:48] <ogra_> echo "COMPRESS=lzma" >chroot/etc/initramfs-tools/conf.d/snappy-device-tarball.conf
[19:48] <ogra_> mvo, line 392 in live-build/auto/build
[19:49] <ogra_> mvo, data abort seems to be a typpical error if your dtb isnt loaded (or the wrong one was loaded)
[19:50] <ogra_> mvo, did yu make sure to use the dtb and overlays from the kernel ?
[19:50] <mvo> ogra_: I compared the uboot.env.in from snappy_ab and snappy_{kernel,os} and they look similar enough, how can I verify the dtb loading? what should I look for?
[19:51] <ogra_> you would have to interrupt the boot for that and call each command by hand
[19:51] <ogra_> where does the dtb in your snap come from ?
[19:52] <mvo> ogra_: from the cdimage device.raspi2 tarball
[19:52] <ogra_> (did that kernel and dtb boot before in this combo)
[19:52] <ogra_> that should be fine then
[19:52] <ogra_> hmm
[20:02] <mvo> ogra_: yeah, all quite strange. is the bootz call that triggers the crash fwiw
[20:04] <ogra_> do you still have ${ftdaddr} at the end ?
[20:04] <mvo> ogra_: yes
[20:04] <ogra_> and i guess you didnt drop "run loadfiles" from your line
[20:05] <mvo> ogra_: still there
[20:05] <mvo> ogra_: here is the diff http://paste.ubuntu.com/13676901/
[20:11] <ogra_> there is nothing that strikes me as wrong :/
[20:11] <ogra_> oh !
[20:12] <kyrofa> Okay so I understand how snappy binaries are launched with a given environment (e.g. with a $SNAP_APP_PATH etc.). But do services not get that environment?
[20:12] <ogra_> mvo, try replacing ${ftdaddr} with 0x100
[20:12] <mvo> kyrofa: service get that too
[20:12] <mvo> ogra_: I noticed this too, but its defined in the file. I will try it anyway
[20:12] <mvo> ogra_: if its that I really want to know why
[20:13] <mvo> ogra_: holly cow
[20:13] <ogra_> and for a test i would also try to drop the whole initrd stuff for one boot
[20:13] <mvo> ogra_: HOLLY COW
[20:13] <kyrofa> mvo oh I'm stupid-- it's probably in the systemd config file huh
[20:13] <ogra_> mvo, ha !
[20:13] <mvo> ogra_: but but but … WHY?
[20:13] <ogra_> good question
[20:14] <mvo> wuuut? "echo ${ftdaddr}
[20:14] <mvo> "
[20:14] <mvo> empty?
[20:14] <mvo> printenv|grep fdt
[20:14] <ogra_> yeah, thats weird
[20:14] <mvo> fdtaddr=0x100
[20:14] <ogra_> something overwrites it at runtime
[20:14] <mvo> ogra_: *quoting* it seems
[20:15] <mvo> echo "${fdtaddr}"
[20:15] <mvo> 0x100
[20:15] <mvo> I don't understand uboot
[20:15] <ogra_> the shell is awful
[20:16] <ogra_> and quoting is a pain ...
[20:16] <ogra_> crap !
[20:16] <ogra_> my Rpi has no IP again after boot
[20:17] <ogra_> despite the fix having landed :(
[20:17] <ogra_> http://people.canonical.com/~ogra/core-image-stats/20151204.changes
[20:17] <mvo> ogra_: ok, I don't understand why, I will put 0x100 there and be happy for now but I don't want to touch uboot again, everytime I do it its a rathole (cf the uboot env go code)
[20:17] <ogra_> mvo, next time just give it to me :)
[20:19] <mvo> ogra_: I have no idea why I did not 3h ago :/ anyway, let me do an end-to-end test
[20:22] <kyrofa> mvo so in the systemd conf, I see `SNAP_APP_USER_DATA_PATH=%h/apps/ros-example.sideload/1.0` . Not being familiar with systemd I'll assume %h is the home directory of the running user. However, I'm getting a "ubuntu-core-launcher[2767]: OSError: [Errno 13] Permission denied: '/root/apps'"
[20:23] <mvo> kyrofa: yeah, there is a open bug about this iirc, jdstrand discussed that some days ago, the apparmor rules deny /root iirc
[20:23] <kyrofa> mvo, ah, okay makes sense. I suppose I'll wait for a fix, then :)
[20:23] <kyrofa> Thank you!
[20:26] <jdstrand> mvo: fyi, the apparmor fix is in. what is needed now is a stable update (for kyrofa's specific issue with services) and a snappy update to adjust the wrapper
[20:26] <kyrofa> Awesome, thanks for the update jdstrand :)
[20:26] <jdstrand> np
[20:27] <kyrofa> jdstrand, can I get a bug number for that, btw?
[20:27] <jdstrand> mvo: fyi, the snappy task is currently unassigned. I imagine this might be something to backport to 15.04, but I'll let you decide
[20:27] <jdstrand> sure
[20:28] <jdstrand> kyrofa: bug #1466234
[20:28] <mvo> jdstrand: thanks, I put on my today for monday morning
[20:28] <jdstrand> cool, thanks
[21:01] <kyrofa> elopio, sergiusens #152 has been cleaned up
[21:01] <sergiusens> kyrofa, nice, was just reading the comments
[21:09] <kyrofa> Alright, EOD here. Have a great weekend everyone!
[21:09] <sergiusens> kyrofa, great, I'll probably have this merged as soon as the tests finish running
[21:09] <sergiusens> kyrofa, enjoy the weekend!
[21:09] <kyrofa> sergiusens, awesome :) . Safe flight!
[21:09] <sergiusens> thanks
[21:11] <sergiusens> kyrofa, oh great, the ros example failed to build...
[21:11] <sergiusens> catkin one built fine, I'll look into it in a bit
[21:23] <tedg> kyrofa: I think the removals were needed if there were two catkin parts they conflicted.
[21:23] <tedg> Ah, reading backlog. Have a good EOW.
[23:17] <johest> good $localtime, is there any way how I can run python pip based apps on core? I am missing a compiler