[00:02] sergiusens: that would be a reason to ignore my comment. [00:03] elopio, the orignal code was like that [00:06] elopio, I'll switch to it; but you get the Chipaca into furiosa mode [00:07] :) [00:07] elopio, seems minimal http://paste.ubuntu.com/13655053/ [00:07] ummm [00:08] is this about the if thing == 'foo': foo() elif thing == 'bar': bar() elif thing == 'potato': brotato()? [00:08] ? [00:09] Chipaca, yeah, like the paste above [00:10] is there no 'none of the above' case? [00:10] Chipaca, or the execute function I made you look at earlier [00:10] Chipaca, hah :-) [00:10] Chipaca, you can offer one :-) [00:11] i mean, in execute, it was the 'step' variable, right? [00:11] and you checked three things [00:11] are those all the values step can take? [00:11] Chipaca, yeah [00:11] elopio, for ref https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42 [00:11] furiosa mode, lol [00:12] I dislike spurious use of getattr(), but a forest of if/elif is what getattr avoids :) [00:12] Chipaca, one more, strip [00:12] sergiusens: so in your perf checking code, add a 'd' to the tests [00:12] Chipaca, I have [00:13] Chipaca, http://paste.ubuntu.com/13655167/ [00:13] just didn't share it [00:13] also this is public, so we would need to catch the case where the step argument is not one of the allowed. [00:13] it is neglible to the point of asking, which is more pleasant to read [00:13] sergiusens: um, no, i mean [00:13] sergiusens: in https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42 [00:13] sergiusens: step can take three values [00:14] grah [00:14] * Chipaca tired [00:14] sergiusens: step can take *four* values [00:14] sergiusens: but you only do stuff for *three* of them [00:14] that is, it's not a direct getattr(self, step)() [00:15] Chipaca: that's work in progress. He has the fourth case in another branch. [00:15] ah. If that's the case, then it's a nobrainer getattr [00:15] Chipaca, so 4 hits the mark? [00:15] siiiiiiigh [00:16] i'll try to explain it with short words [00:16] because i'm tired and can't type long ones [00:16] Chipaca, elopio oh wait, wait there is an hidden reason I did it like this [00:16] well, I can do it differently, no worries [00:17] sergiusens: shoot [00:17] Chipaca, the 'force' logic in the current code is very dark sideish [00:17] force? [00:17] Chipaca, I was planning to make force, only force the desired step and not all the previous ones [00:17] ah [00:17] snapcraft build --force [00:18] that sounds like an --only more than a --force, but --whatevs [00:18] Chipaca, but I can make the 'force' param for each step smarter by not having it there and do it differently [00:19] so no getattr until otherwise mentioned it is [00:19] Chipaca, thanks for being the 3rd opinion on this :-) [00:19] tie breaker ;-) [00:19] 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] Chipaca, I removed all the 'force' mentions in this new code to reimplement it correctly [00:20] Chipaca, current force does what follows... [00:22] i'm writing a long thing about my opinion on this, because i was unable to write it short [00:22] i have 45 minutes to do it in (after which the battery dies) [00:22] hopefully it will be less than that :-) [00:22] hah [00:24] Chipaca, hmm, never mind me, --force is useless [00:32] * elopio goes for cryptobeers [00:32] I'll bbl, drunk and anonymous. [00:35] sergiusens: https://gist.github.com/chipaca/a49c1f6888c2f6dd4184 [00:37] i hope it makes sense [00:37] Chipaca: the dict solution is nice. [00:37] it's often the hardest to read though [00:38] :) [00:42] ooh, forgot one [00:44] Chipaca, it is indeed hard to read :) [00:44] elopio: sergiusens: added one last one just for fun, and now yes g'night [07:17] hi, wanted to know if its possible to create our own snappy store. [07:34] hi, wanted to know if its possible to create our own snappy store. [08:10] good morning [08:13] good morning [09:03] good morning [09:52] Good morning all; happy Friday, and happy World Wildlife Conservation Day! 😃 [10:06] dholbach, ping [10:07] liuxg, pong [10:08] 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] 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] 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] dholbach, in the snap package [10:10] you use stage-packages to include them in your .snap [10:10] dholbach: I think he can also use pip plugin to use upstream releases directly [10:11] liuxg: I haven't tried that in a while but give it a try [10:11] liuxg: it has access to fresh software faster this way [10:11] 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] zyga, thanks. then what is the syntax for doing pip? [10:12] zyga, dholbach I have seen it is done in the setup.py in the webcam project [10:12] 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] 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] so it entirely depends on your setup [10:15] liuxg: I don't really remember, let me try to find that [10:15] 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] you could take django from the archive? [10:15] dholbach, either way, I think it has apt-get and pip [10:16] so add stage-packages: [python-django] [10:16] zyga, thanks [10:17] dholbach, thanks, I will have a try on that. by the way, can a plugin support more than one stage-packages? [10:17] yes [10:17] dholbach, it is interesting. I will try to an exercise for it :) [10:18] cool :) [10:18] liuxg: try this https://github.com/ubuntu-core/snapcraft/blob/f8176788e6a932998c9cac3f98c3eb78c40fcab3/snapcraft/plugins/python3.py#L32 [10:18] liuxg: it seems that it's merged with python2/3 plugin now [10:18] liuxg: just pass a path to requirements.txt [10:19] liuxg: and it will pip-install anyhting you need [10:19] liuxg: let me know if that works, I'm curious myself [10:19] stage-packages should probably be easier in this case... unless you need a very specific django version [10:20] and want to maintain the version number yourself [10:20] zyga, what is the form of requirements.txt? [10:23] liuxg, something like this: [10:23] Framework==0.9.4 [10:23] Library>=0.2 [10:23] hi sergiusens [10:25] liuxg: normal requirements file, you can make one like this: [10:25] liuxg: create a virtualenv [10:25] liuxg: setup.py install your stuff there (or pip install anything you need) [10:25] liuxg: then run: pip freeze [10:25] liuxg: that's your requirements file [10:25] liuxg: so when it works for you in virtualenv you can pip freeze and put that into snappy [10:25] sergiusens: o/ [10:26] going with the archive is probably easier ;-) [10:26] sorry :) [10:26] but yeah.. it would probably be good to test that as well :) [10:26] dholbach: if your stuff is in the archive [10:26] dholbach: at the right version [10:26] django is [10:26] 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] dholbach: requirements can also pull straight from git/hg/bzr at any revision/tag [10:26] yep, that's right [10:27] liuxg: looks like it [10:27] zyga, is it like http://paste.ubuntu.com/13665491/? [10:28] zyga, I will have a try for that. [10:28] o/ [10:28] liuxg: that's not requirements.txt [10:28] liuxg: that's something you can run in your shell [10:29] liuxg: then you can pip freeze [10:29] liuxg: and redirect that to > requirements.txt [10:29] zyga, so what does a requirements.txt look like? [10:29] liuxg: run that and see [10:31] zyga, do you have any example or document for this? it is hard for developers to figure out. [10:32] liuxg, a requirements.txt is not hard for a developer already working on python [10:33] dholbach, you can make the QA 6am my time I guess [10:34] sergiusens, how to integrate it into snapcraft may be a problem. [10:36] sergiusens, do you have any simple example for that? thanks [10:37] liuxg, snapcraft help python3 [10:37] liuxg, look at the requirements keyword text, it says to point it to the path to your requirements.txt [10:39] sergiusens, in the python-packages, it installs all of the needed packages? right? [10:43] 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] sergiusens, are you sure that's not too early? [10:50] zyga, do you know how to run a python project in an virtualenv on snappy?? [10:55] liuxg: I don't think you need virtualenv on snappy per se [10:55] liuxg: (you can in classic mode for testing) [10:55] liuxg: you want to develop your project locally if you can, using virtualenv [10:55] liuxg: and then package that with snapcraft [10:56] zyga, yes, that is what I think. we just install everything to the space of the snappy app. [10:58] zyga, the python3 plugin supports requirements and python-packages, what is the difference between them? [10:58] zyga, in the requirements.txt, we can install the packages, how about the python-packages? do they do the same thing? [10:59] liuxg: I actually don't know - I'd have to read the source of the plugin [10:59] liuxg: get started with requirements [11:00] 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] dholbach, it is fine [11:03] sergiusens, ok... I'll tell Kay [11:52] * zyga fiddles with GPIOs and LEDs for a demo [12:31] pers [12:31] +morning sna... [12:39] heh [13:00] 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] 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] olli, we dont have any downloadable images for rolling [13:23] the reference image is stable [13:23] olli, I did this: [13:23] sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img [13:24] 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] hmmm, though I just noticed it says pi2.canonical/stable :/ [13:25] thats correct [13:25] u-d-f doesnt know about channels yet [13:25] ack [13:25] so you need /stable [13:25] confusing, but "ack" ;) [13:26] ogra_, ah, remember [13:26] ogra_, which u-d-f do I want? [13:26] there was a specific branch iirc [13:26] sergiusens, ^ [13:26] * olli is gathering stuff for his 18h journey tomorrow [13:26] olli: lucky you [13:27] olli, just the latest :) [13:27] 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] olli, I thought you needed mvo's specific branches [13:51] olli, for u-d-f [13:51] olli, this is until we have time to implement ubuntu-image [13:51] rickspencer3, ogra_, olli: let me check and fix the need to add rpi2/stable [13:51] sergiusens: for non all-snap images the old u-d-f is still ok [13:51] sergiusens: probably changes after the sprint [13:51] oh, wrt channels, I haven't been involved in any preempt work [13:52] mvo, oh, so does that mean the version I have now is not all snaps? [13:52] mvo, oh, and it works? Notice olli was specifically asking about "all snaps" [13:53] sergiusens: ups, srry, I overlooked the all-snaps bit :/ [13:53] rickspencer3: yeah, you are still old-school, I only have a BBB all-snap image at this point [13:53] oh man [13:53] what a bummer [13:53] 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] rickspencer3: sorry! [13:54] mvo, could someone document how to get a rolling 16.04 all snap image somewhere? [13:54] even just an email to the list would be nice [13:54] 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] 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] in the store? [13:57] mvo, I don't think I have enough context to make that decision [13:57] but it seems like we want people using all snaps asap [13:58] I think we want the feedback asap wrt what is working perfectly and what is working not perfectly right now [13:58] is it reasonable to use your naming trick on a temporary basis? [13:59] rickspencer3: I think so, people may need to manually switch later to a new anme but I guess thats ok [13:59] olli, thoughts? ^ [13:59] I think olli is the right person to facilitate this decision [13:59] I worry that I am just impatient ;) [13:59] we stopped worrying about that and accepted it as a fact [13:59] years ago [14:00] haha [14:00] let me make a image for you guys using a sideloaded kernel so that at least there is something [14:00] was hoping we can discuss in BRA next week [14:00] mvo, I can create an image myself if above u-d-f does the trick [14:01] 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] ogra_: any preferences for the kernel name for the pi2? [14:03] mvo, we already have a name [14:03] 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] ogra_: we do? [14:03] just use the name we use for the channel and for the current kernel package [14:04] "raspi2" [14:04] ogra_: works for me, thanks [14:04] mvo, ok, if you can make an image without being negatively impacted from your sprint prep then that's fine for today [14:04] everything else (naming) we can cover next week [14:04] if I don't get an image today I am ok too [14:06] olli: thanks! [14:06] Hello [14:06] I've got a snappy related question [14:07] Is there any good reason why Snappy couldn't work on the new Pi Zero? (once an image was built) [14:10] BrianLinuxing, yes ... [14:11] BrianLinuxing, Pi zero uses a very old ARM arch (like the Pi1 ... ) there is no way to use that with ubuntu [14:11] 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] mvo, hmm, on my disk ... let me dig it up and push somewhere [14:11] ogra_: thanks! I especially need the uboot.env.in file :) [14:13] Gotcha Orga, but if Debian can be built for Pi Zero, wondering why not Snappy? [14:14] mvo, http://paste.ubuntu.com/13669072/ [14:14] BrianLinuxing: debian does not exist for pizero, raspbian does, which is a full rebuild. [14:14] BrianLinuxing, debian cant be built for pi zero ... raspbian can [14:15] you could indeed do the same for ubuntu ... it is essential a completely new archive arch you need to create [14:15] (which is a whole lot of work) [14:15] and then there would be no binary apps running, because they are all for armv7 or x86_64 [14:16] right [14:16] 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] mvo, the paste was u-boot.env.in FWIW [14:16] I can use the old school arch for the time being [14:17] 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] BrianLinuxing, there is no ubuntu for ARMv6 [14:18] the ubuntu armhf arch is built for v7 [14:18] like the debian one [14:18] or any other relevant distro nowadays [14:18] the raspbian people take the whole archive, change the compiler defaults and re-build the whole distro [14:19] got it [14:19] 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] mvo, same as for bbb [14:19] so there is no technical reason why it couldn't be built, just its a lot of work? [14:19] should all be identical [14:20] 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] 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] mvo, I think it makes sense to be cautious about uploading to the store without thinking it through [14:20] is there a full build procedure for snappy for a7? so I can look at replicating on an a6 [14:20] thank orga :) [14:21] BrianLinuxing, no ... you need the ubuntu build infrastructure set up for this ... [14:21] it is a million of steps that involves quite a lot of people [14:21] BrianLinuxing: canonical doesn't really document their infrastructure, that helps them retain control over ubuntu [14:21] ok, how would one replicate the ubuntu build infrastructure set up [14:21] first of all you would need the rebuilt archive (which will take you 6 months or more i guess) [14:21] I have a lot of kit [14:22] BrianLinuxing: step one, hire 20-50 build engineers ;) [14:22] thenm you would need to replicate the cdimage and live-build infrastructure ubuntu uses [14:22] after that you would have tarballs [14:23] 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] i guess tbr's assumption of 20 devs isnt to far off [14:23] BrianLinuxing: if you want targeted distributions, look at buildroot, yocto+openembedded+angstrom/poky [14:23] tbr, I am old but nimbled fingered :) [14:23] unless you have a year of time or more :) [14:23] OK [14:24] and once you are done, none of the snap packages from the snapstore would run [14:24] not wishing to state the obvious, but y'all know Pi Zero will take off like a rocket? [14:24] since they are built for armhf (v7) [14:24] oh and you would also be left with the fact that you can't call it ubuntu [14:24] right [14:24] and MUST remove the word ubuntu from all the source code and everywhere [14:25] nah [14:25] thats nonsense :) [14:25] of course [14:25] well, the issue is contended and there are diverging opinions [14:25] you need to remove all copyright relevant bits ... [14:25] got that. [14:26] but surely not changelog entries that reference @ubuntu.com and such :) or readmes that refer to ubuntu etc [14:26] ask a lawyer and they will side with me ;) [14:26] it is moot anyway [14:26] but back to my point, y'all know 30,000 Pi Zeros sold out in < a week [14:26] BrianLinuxing, yeah, not much different from Pi1 [14:26] yet we cant support it [14:27] [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] BrianLinuxing: yes, and recently still huge numbers of VW Golf I and Beetle and Transporter were produced in south america [14:27] (at least not without making armhf unusable for most other ARM arches) [14:27] the technical reasons were named in the beginning already [14:27] fair enough, remember that thought :) [14:28] BrianLinuxing, the techincal reasons are that a build for the v6 arch disables many/most v7 features [14:28] it is an enormous overhead and cost to run two arches instead of one [14:28] which means ubuntu on phones would for example be really slow and have a lot larger binaries [14:28] or ubuntu for clouds where arm is also used a lot [14:29] if its part politics, resources, etc I get that [14:29] no [14:29] but Pi Zero will be big. [14:29] it is part of money and manhours that arent available [14:29] off to CoreOS, thanks for the chat :) [14:29] 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] sonamoe recently told me a new archi might cost between 10.20Mio [14:30] *10-20 [14:30] * ogra_ grins at olli [14:30] my personal opinion is that pizero will always remain a toy, a moderately popular toy. [14:30] everyone wanting to get real work done has moved on from ARMv6 to ARMv7 or AArch64 long ago [14:31] i'd say its more like 5-10 Mio ... but it is definitely a lot of money [14:31] right, and the latter two are the arches ubuntu supports [14:32] truth hurz [14:32] yeah [14:33] 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] mvo, not at all ! [14:34] 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] ogra_: tell me about TODO lists - just like memory in a C program, it keeps growing [14:35] ogra_: but I can do it while waiting for me sd card to finish writing :) [14:36] yeah, ARM work gives you a lot of slack all the time :) [15:05] 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] If this is the case, is Snappy not really meant for bare metal installations? [15:10] 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] ogra_: I send you an image [15:11] ogra_: anything I can do to debug? [15:11] mvo, is that the existing uboot binary ? [15:12] ogra_: I guess, I did not change anything on the pi2, its brand new [15:12] i dont see it loading uboot.env [15:13] ogra_: how can I debug this? sorry, arm noob [15:13] well, you should see a "loading uboot.env" [15:14] are you sure the file is in the right place ? [15:14] 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] sergiusens: how were the prerequisites implemented before? also with recurssion? [15:15] mvo, looks to me like it isnt recognized at all [15:15] ogra_: whats the boot sequence normally? which of the file is loaded/run in system-boot? [15:15] mvo, also screen -L helps a lot [15:15] ogra_: hm, the card you mean? [15:15] elopio, it was broken before [15:15] (to log all serial output to a logfile) [15:16] ogra_: I have it on a norma monitor right now, no serial [15:16] elopio, just hidden as pull, build, stage, strip was done for a complete part before moving to the next [15:16] 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] elopio, but if you did `snapcraft build` and one part depended on the other it would break [15:17] sergiusens: so if now you do snapcraft build, the parts that are reqs will be staged. [15:18] elopio, yes, it is a semantic requirement I want to introduce for `after`, it doesn't make sense otherwise [15:18] maybe it would be worth printing something about that. Staging part bla because it's a requisite of this other part. [15:19] elopio, that is a good point indeed [15:19] 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] Think I found my answer - https://developer.ubuntu.com/en/snappy/start/installation-tips/ [15:24] 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] mvo, printenv and see if the vars from the .in file show up there [15:31] elopio, oh, you think we should add levels? I think python has a limit in itself [15:32] elopio, also, circular dependency checks on load_config prevent a circular eternal loop [15:32] sergiusens: that's a good thing to mention on this function, somewhere. [15:33] sergiusens: I don't understand what you mean by levels. [15:33] elopio, have execute take a recursion_level param and check it on entry [15:34] mvo, you can also check with fatls and fatload if the file is found and can be loaded [15:36] ogra_: usb keyboard does not work *sigh* so I need to find a serial cable [15:36] ogra_: I wonder if the one from the bbb will work [15:40] mvo, it will, only attach RX/TX/GND though [15:42] sergiusens: what's the best way to have meta/stuff in snapcraft.yaml, I'd like a config hook [15:44] zyga, you just add "config: config.sh" and snapyp config will call that script [15:44] http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml [15:45] ogra_: perfect, thanks! [15:47] ogra_, any idea what this might mean? [15:47] http://pastebin.ubuntu.com/13670711/ [15:47] or maybe that is Chipaca? [15:48] rickspencer3, looks liek a bug to me [15:48] rickspencer3: happening on pi2 rolling I assume? [15:48] no idea when/where snappy update calls mkdir [15:48] mvo yes [15:50] I logged a bug, fwiw https://bugs.launchpad.net/snappy/+bug/1522889 [15:50] Launchpad bug 1522889 in Snappy "error when running snappy update on rpi2 on rolling (mkdir : no such file or directory)" [Undecided,New] [15:51] rickspencer3, my update via autopilot worked tonight ... (i'm on 76 here) [15:51] rickspencer3, could your disk be full ? [15:52] ogra_, I guess so [15:52] zyga, use config: [15:53] ogra_, it doesn't look full: http://pastebin.ubuntu.com/13670818/ [15:54] 533M free in /writable/cache/system, yeah that should be enough [15:55] oh [15:56] (RaspberryPi2)ubuntu@localhost:~$ snappy search [15:56] Name Version Summary [15:56] classic.mvo 1.0-3 classic [15:56] generic-amd64.mvo 2.0 generic-amd64 [15:56] (RaspberryPi2)ubuntu@localhost:~$ [15:56] where are all the snaps gone ! [15:56] did the store change again ? [15:56] beuno, ^^^ ? [15:57] this used to show a lot more packages with yesterdays image [15:57] ogra_: beuno is on holiday === Guest55209 is now known as beowulf === beowulf is now known as Guest9543 [16:02]