| elopio | sergiusens: that would be a reason to ignore my comment. | 00:02 |
|---|---|---|
| sergiusens | elopio, the orignal code was like that | 00:03 |
| sergiusens | elopio, I'll switch to it; but you get the Chipaca into furiosa mode | 00:06 |
| sergiusens | :) | 00:07 |
| sergiusens | elopio, seems minimal http://paste.ubuntu.com/13655053/ | 00:07 |
| Chipaca | ummm | 00:07 |
| Chipaca | is this about the if thing == 'foo': foo() elif thing == 'bar': bar() elif thing == 'potato': brotato()? | 00:08 |
| Chipaca | ? | 00:08 |
| sergiusens | Chipaca, yeah, like the paste above | 00:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| * 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:20 |
| 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:22 |
| sergiusens | Chipaca, hmm, never mind me, --force is useless | 00:24 |
| * elopio goes for cryptobeers | 00:32 | |
| elopio | I'll bbl, drunk and anonymous. | 00:32 |
| Chipaca | sergiusens: https://gist.github.com/chipaca/a49c1f6888c2f6dd4184 | 00:35 |
| 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:37 |
| Chipaca | :) | 00:38 |
| Chipaca | ooh, forgot one | 00:42 |
| 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 | 00:44 |
| dragunov11 | hi, wanted to know if its possible to create our own snappy store. | 07:17 |
| dragunov11 | hi, wanted to know if its possible to create our own snappy store. | 07:34 |
| fgimenez | good morning | 08:10 |
| dholbach | good morning | 08:13 |
| zyga | good morning | 09:03 |
| JamesTait | Good morning all; happy Friday, and happy World Wildlife Conservation Day! 😃 | 09:52 |
| liuxg | dholbach, ping | 10:06 |
| dholbach | liuxg, pong | 10:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| dholbach | so add stage-packages: [python-django] | 10:16 |
| liuxg | zyga, thanks | 10:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| dholbach | and want to maintain the version number yourself | 10:20 |
| liuxg | zyga, what is the form of requirements.txt? | 10:20 |
| dholbach | liuxg, something like this: | 10:23 |
| dholbach | Framework==0.9.4 | 10:23 |
| dholbach | Library>=0.2 | 10:23 |
| dholbach | hi sergiusens | 10:23 |
| 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:25 |
| 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:26 |
| zyga | liuxg: looks like it | 10:27 |
| liuxg | zyga, is it like http://paste.ubuntu.com/13665491/? | 10:27 |
| 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:28 |
| 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:29 |
| liuxg | zyga, do you have any example or document for this? it is hard for developers to figure out. | 10:31 |
| sergiusens | liuxg, a requirements.txt is not hard for a developer already working on python | 10:32 |
| sergiusens | dholbach, you can make the QA 6am my time I guess | 10:33 |
| liuxg | sergiusens, how to integrate it into snapcraft may be a problem. | 10:34 |
| liuxg | sergiusens, do you have any simple example for that? thanks | 10:36 |
| 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:37 |
| liuxg | sergiusens, in the python-packages, it installs all of the needed packages? right? | 10:39 |
| 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:43 |
| dholbach | sergiusens, are you sure that's not too early? | 10:44 |
| liuxg | zyga, do you know how to run a python project in an virtualenv on snappy?? | 10:50 |
| 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:55 |
| liuxg | zyga, yes, that is what I think. we just install everything to the space of the snappy app. | 10:56 |
| 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:58 |
| 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 | 10:59 |
| 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:00 |
| sergiusens | dholbach, it is fine | 11:03 |
| dholbach | sergiusens, ok... I'll tell Kay | 11:03 |
| * zyga fiddles with GPIOs and LEDs for a demo | 11:52 | |
| olli | pers | 12:31 |
| olli | +morning sna... | 12:31 |
| ogra_ | heh | 12:39 |
| 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:00 |
| 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:22 |
| * 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 | |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| mvo | in the store? | 13:56 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| mvo | ogra_: any preferences for the kernel name for the pi2? | 14:02 |
| 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:03 |
| 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:04 |
| mvo | olli: thanks! | 14:06 |
| BrianLinuxing | Hello | 14:06 |
| BrianLinuxing | I've got a snappy related question | 14:06 |
| BrianLinuxing | Is there any good reason why Snappy couldn't work on the new Pi Zero? (once an image was built) | 14:07 |
| ogra_ | BrianLinuxing, yes ... | 14:10 |
| 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:11 |
| BrianLinuxing | Gotcha Orga, but if Debian can be built for Pi Zero, wondering why not Snappy? | 14:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| tbr | truth hurz | 14:32 |
| ogra_ | yeah | 14:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| ogra_ | yeah, ARM work gives you a lot of slack all the time :) | 14:36 |
| 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:05 |
| 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:10 |
| mvo | ogra_: anything I can do to debug? | 15:11 |
| ogra_ | mvo, is that the existing uboot binary ? | 15:11 |
| 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:12 |
| mvo | ogra_: how can I debug this? sorry, arm noob | 15:13 |
| ogra_ | well, you should see a "loading uboot.env" | 15:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| elopio | sergiusens: so if now you do snapcraft build, the parts that are reqs will be staged. | 15:17 |
| 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:18 |
| 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:19 |
| Chopper | Think I found my answer - https://developer.ubuntu.com/en/snappy/start/installation-tips/ | 15:23 |
| 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:24 |
| ogra_ | mvo, printenv and see if the vars from the .in file show up there | 15:25 |
| sergiusens | elopio, oh, you think we should add levels? I think python has a limit in itself | 15:31 |
| 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:32 |
| 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:33 |
| ogra_ | mvo, you can also check with fatls and fatload if the file is found and can be loaded | 15:34 |
| 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:36 |
| ogra_ | mvo, it will, only attach RX/TX/GND though | 15:40 |
| zyga | sergiusens: what's the best way to have meta/stuff in snapcraft.yaml, I'd like a config hook | 15:42 |
| 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:44 |
| zyga | ogra_: perfect, thanks! | 15:45 |
| 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:47 |
| 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:48 |
| rickspencer3 | I logged a bug, fwiw https://bugs.launchpad.net/snappy/+bug/1522889 | 15:50 |
| ubottu | Launchpad bug 1522889 in Snappy "error when running snappy update on rpi2 on rolling (mkdir : no such file or directory)" [Undecided,New] | 15:50 |
| ogra_ | rickspencer3, my update via autopilot worked tonight ... (i'm on 76 here) | 15:51 |
| ogra_ | rickspencer3, could your disk be full ? | 15:51 |
| rickspencer3 | ogra_, I guess so | 15:52 |
| sergiusens | zyga, use config: <path to config> | 15:52 |
| rickspencer3 | ogra_, it doesn't look full: http://pastebin.ubuntu.com/13670818/ | 15:53 |
| ogra_ | 533M free in /writable/cache/system, yeah that should be enough | 15:54 |
| ogra_ | oh | 15:55 |
| 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:56 |
| ogra_ | this used to show a lot more packages with yesterdays image | 15:57 |
| Guest55209 | ogra_: beuno is on holiday | 15:57 |
| === Guest55209 is now known as beowulf | ||
| === beowulf is now known as Guest9543 | ||
| 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:02 |
| 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:03 |
| 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:04 |
| mvo | ogra_: hm, once I get rolling to boot… | 16:09 |
| 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:10 |
| 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:14 |
| 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:15 |
| ogra_ | i still have the tree here | 16:16 |
| 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:17 |
| mvo | ogra_: hmmmm, size is also very different from bbb | 16:18 |
| 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:19 |
| ogra_ | mvo, mail with uboot.env is out | 16:30 |
| olli | ogra_, shiny! | 16:30 |
| ogra_ | see if that works any better | 16:31 |
| 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:32 |
| ogra_ | iven that fw_setenv needs to be able to read/write them they need to be kind of indentical :) | 16:33 |
| ogra_ | mvo, where do the values for snappy_good_os and snappy_good_kernel come from ? | 16:47 |
| ogra_ | (and snappy_os/snappy_kernel) | 16:48 |
| mvo | ogra_: thats something that u-d-f will set | 16:50 |
| mvo | ogra_: on image creation | 16:50 |
| mvo | ogra_: hm, interessting clue | 16:51 |
| 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:52 |
| 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:53 |
| ogra_ | does it do that now ? | 16:54 |
| mvo | ogra_: it does not tell me that it loads it, no :/ | 16:54 |
| ogra_ | weird | 16:54 |
| 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:01 |
| 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:09 |
| 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:10 |
| ogra_ | mvo, with your or my uboot.env ? | 17:11 |
| ogra_ | (do you need my mkenvimage binary ?) | 17:11 |
| 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:12 |
| ogra_ | yeah, hard to debug without | 17:13 |
| kyrofa | Ooo wait, scratch my above problem, it checks another env variable first | 17:15 |
| mvo | ogra_: http://paste.ubuntu.com/13672523/ is where I am now | 17:20 |
| mvo | ogra_: but dinner first | 17:20 |
| ogra_ | mvo, looks like a typo somewhere ... or wrong quoting | 17:21 |
| dholbach | elopio, thanks for the review - I lifted the content from the Dell doc | 17:26 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| davmor2 | rickspencer3: rather Hal than skynet though right :) | 17:43 |
| ogra_ | whats wrong with skynet ? | 17:43 |
| ogra_ | :) | 17:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| dholbach | hah, 4 year olds, that's reassuring | 17:49 |
| dholbach | thanks kyrofa - have a good one! :) | 17:49 |
| sergiusens | elopio, 151 is up | 17:57 |
| 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:58 |
| 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. :) | 17:59 |
| mvip | mectors: Viktor from Screenly :) | 18:00 |
| sergiusens | elopio, heh, it's in the spec :-P | 18:00 |
| mvip | mectors: no worries ;) | 18:00 |
| 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:01 |
| mvip | mectors: deal! | 18:03 |
| mvip | mectors: we should have something proper to show by then. | 18:03 |
| mvip | elopio: thanks btw :) | 18:04 |
| 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:05 |
| ogra_ | yeah, upper | 18:06 |
| mvip | mectors: you in London next week? Maybe drop by for a coffee? | 18:07 |
| ogra_ | mvo, your setnev issue is the quotes though i guess | 18:08 |
| mvip | mectors: cool. I can swing by for a coffee in the afternoon or a beer in the evening. Whichever you prefer. | 18:09 |
| 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:10 |
| 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:11 |
| ogra_ | welcome guys :) | 18:12 |
| 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:13 |
| mvip | Is there a best praxis for where to store these? | 18:14 |
| mvip | *best practise | 18:14 |
| renat | And will not require too complex AppArmor config. | 18:15 |
| ogra_ | well, currently there is no such space | 18:17 |
| ogra_ | snaps cant see anything outside their allowed dirs | 18:17 |
| 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:18 |
| mvip | ogra_: We're talking about gigabytes of data tho (potentially) | 18:19 |
| ogra_ | why do you have to use different snaps btw | 18:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 | |
| * 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:26 |
| 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:27 |
| zyga | kyrofa: yes, I saw that too (now) | 18:28 |
| zyga | so now how to see what's the EPERM about | 18:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| sergiusens | elopio, kyrofa simple pimple https://github.com/ubuntu-core/snapcraft/pull/153/files | 18:39 |
| 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:46 |
| mvo | ogra_: one more step http://paste.ubuntu.com/13674418/ - "data abort" - wonder what that means | 18:50 |
| 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:51 |
| jdstrand | zyga: but I think it was deprioritized because hw-assign is the old way (not sure about that) | 18:52 |
| sergiusens | elopio, https://github.com/ubuntu-core/snapcraft/pull/154 | 19:00 |
| sergiusens | elopio, last but not least https://github.com/ubuntu-core/snapcraft/pull/155 | 19:04 |
| sergiusens | elopio, and that is all I have, anything newer needs work (the `snap` command ;-) ) | 19:05 |
| sergiusens | and updating the integration tests | 19:05 |
| plars | elopio: when I try to run run-tests locally, I get "go tool: no such tool "vet"" | 19:17 |
| mvo | ogra_: hm, where can I find the options you use for the initrd pi2 compression? | 19:27 |
| elopio | plars: checkout the main README | 19:29 |
| elopio | you could also go run ./integration-tests/main.go, which will skip the style checks. | 19:30 |
| 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:33 |
| ogra_ | mvo, livecd-rootfs | 19:47 |
| 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:48 |
| ogra_ | mvo, data abort seems to be a typpical error if your dtb isnt loaded (or the wrong one was loaded) | 19:49 |
| 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:50 |
| 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:51 |
| 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 | 19:52 |
| mvo | ogra_: yeah, all quite strange. is the bootz call that triggers the crash fwiw | 20:02 |
| 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:04 |
| mvo | ogra_: still there | 20:05 |
| mvo | ogra_: here is the diff http://paste.ubuntu.com/13676901/ | 20:05 |
| ogra_ | there is nothing that strikes me as wrong :/ | 20:11 |
| ogra_ | oh ! | 20:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| mvo | echo "${fdtaddr}" | 20:15 |
| mvo | 0x100 | 20:15 |
| mvo | I don't understand uboot | 20:15 |
| ogra_ | the shell is awful | 20:15 |
| ogra_ | and quoting is a pain ... | 20:16 |
| ogra_ | crap ! | 20:16 |
| ogra_ | my Rpi has no IP again after boot | 20:16 |
| 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:17 |
| mvo | ogra_: I have no idea why I did not 3h ago :/ anyway, let me do an end-to-end test | 20:19 |
| 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:22 |
| 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:23 |
| 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:26 |
| 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:27 |
| jdstrand | kyrofa: bug #1466234 | 20:28 |
| ubottu | bug 1466234 in ubuntu-snappy (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] https://launchpad.net/bugs/1466234 | 20:28 |
| mvo | jdstrand: thanks, I put on my today for monday morning | 20:28 |
| jdstrand | cool, thanks | 20:28 |
| kyrofa | elopio, sergiusens #152 has been cleaned up | 21:01 |
| sergiusens | kyrofa, nice, was just reading the comments | 21:01 |
| 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:09 |
| 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:11 |
| 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. | 21:23 |
| johest | good $localtime, is there any way how I can run python pip based apps on core? I am missing a compiler | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
