| kirkland | is there a public "view" of my app uploaded to the snappy store? | 00:56 |
|---|---|---|
| kirkland | I can see https://myapps.developer.ubuntu.com/dev/click-apps/3123/ but that looks to be private to me | 00:57 |
| === jkridner|work is now known as jkridner | ||
| === chihchun_afk is now known as chihchun | ||
| === c74d is now known as c74d3a4 | ||
| === c74d3a4 is now known as c74d | ||
| mvo | ogra_: good morning! there is https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975 right now but thats incomplete, right? would be awsome if you could point me to the steps that are missing. is it just adding "snappy-system.txt" to mkenvimage? | 06:14 |
| === tvoss|afk is now known as tvoss | ||
| fgimenez | good morning | 07:04 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| ogra_ | mvo, the input file shouldnt be called uEnv.txt, we want that file empty in the /boot dir ... (or alternatively fix snappy to not look for it but to check for uboot.env instead) | 07:43 |
| ogra_ | i'll prepare an MP with the file content | 07:43 |
| dholbach | good morning | 08:04 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| JamesTait | Good morning all; happy Viking 1 Landing Day! š | 08:55 |
| longsleep | ogra_: I was thinking about the saveenv a bit more and was wondering why you guys do not see fat corruption that way. Any idea? | 09:05 |
| ogra_ | longsleep, different layer i guess | 09:06 |
| ogra_ | the assigned size of the file on the fs is fixed, only the content inside changes, i guess that makes it behave different | 09:06 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mvo, https://code.launchpad.net/~ogra/snappy-hub/bbb-new-binaries-and-env/+merge/265375 | 09:21 |
| mvo | ogra_: hm, thats long :) none of this is in the default env that uboot already generates? thats a bit disappointing of uboot :/ | 09:25 |
| ogra_ | mvo, thjats in the default env that is hardcoded into the uboot binar | 09:26 |
| ogra_ | y | 09:26 |
| ogra_ | which gets emptied automatically if uboot.env gets loaded | 09:26 |
| mvo | ogra_: aha, that was my question, if it merges or overrides | 09:27 |
| ogra_ | to keep it we need to carry over the whole of it | 09:27 |
| mvo | yeah, makes sense | 09:27 |
| === chihchun_afk is now known as chihchun | ||
| mvo | would be great if we could document this for porters later how to ge tthe defaults that needs to be added | 09:27 |
| ogra_ | thats my plan once we are finished | 09:27 |
| mvo | yay | 09:27 |
| mvo | :) | 09:28 |
| ogra_ | i added the MP as item to the trello card | 09:28 |
| longsleep | ogra_: ah yes that makes sense - the file size always stays the same | 09:28 |
| ogra_ | (and commented on https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975) | 09:28 |
| mvo | so does that mean with that uboot.env a fresh system with your latest uboot will fully work with the uboot.env (and with my snappy branch)? | 09:28 |
| mvo | ogra_: yeah, my branch is obsolete now | 09:29 |
| ogra_ | mvo, thats what i tested here | 09:29 |
| mvo | ogra_: \o/ | 09:29 |
| ogra_ | mvo, no, it isnt | 09:29 |
| ogra_ | i left out the bits your branch has | 09:29 |
| ogra_ | the README needs updating though :) | 09:29 |
| mvo | ogra_: you tested and it all worked? thats fantastic news | 09:29 |
| mvo | ogra_: haha, ok | 09:29 |
| mvo | ogra_: I merge your stuff then :) | 09:29 |
| ogra_ | mvo, last friday, yes | 09:29 |
| ogra_ | with my own snap though (based off the beagleblack snap from the store) ... we'll still need an end to end test with a snap built fr4om the branch | 09:30 |
| mvo | ok | 09:32 |
| ogra_ | (and with your chanes in place indeed) | 09:32 |
| mvo | ogra_: did you managed to test if the fs corruption is fixed too? | 09:32 |
| ogra_ | (without me cp'ing the snappy binary in place ;)) | 09:32 |
| ogra_ | i didnt have any corruption, but i would still like to see it in a real end to end test first | 09:33 |
| ogra_ | (i switched back and forth twice when i tested, the prob is indeed that i manually hack the env to trigger that) | 09:35 |
| longsleep | thats what i also wanted to ask, how can i build an image which does change the stuff in uboot.env? Is there something in edge channel already? | 09:36 |
| ogra_ | well, technically we dont support rollback on non beagle boards currently | 09:36 |
| ogra_ | though i bet in 15.04 it might still work somehow | 09:37 |
| longsleep | ogra_: rollback works fine for the odroidc with my image | 09:45 |
| ogra_ | hah, good :) | 09:45 |
| longsleep | and i would like to keep it that way with the upcoming changes :) | 09:45 |
| ogra_ | well, snappy will refuse to update at some point ... | 09:46 |
| ogra_ | in rolling ... | 09:46 |
| longsleep | i can easily trigger it from uboot shell now, the only thing missing is the stuff modifying the uboot.evn after successfull boot | 09:46 |
| longsleep | why would it refuse to update? | 09:46 |
| ogra_ | because only fully supported boards are supposed to get updates | 09:47 |
| ogra_ | (there were a few discussions on the ML about this ... in the RPi threads ) | 09:47 |
| longsleep | how is it detected? I have the auto updater currently enabled and it worked fine when version 3 was released | 09:48 |
| ogra_ | (that doesnt stop you from doing any uboot shell hackery, but the automatism wil likely refuse to work at some point) | 09:48 |
| ogra_ | yes, as i said, in 15.04 that still works | 09:49 |
| longsleep | well - thats why i am here to fix things and make it working | 09:49 |
| ogra_ | i assume what is supported will be considered by the store ... technically only the bits from plain mainline are under active support currently ... which limits us to the BBB on arm | 09:50 |
| Chipaca | rsalveti: ping about the difference between "snappy service status" and "snappy service list" | 09:52 |
| longsleep | yes that is fine with me - i can even run my own system-image server if required. I want to provide a stable upgrade path to anyone trying my images. | 09:52 |
| ogra_ | well, system-image will go away | 09:53 |
| ogra_ | everything will become a snap | 09:53 |
| longsleep | right - i might to want to run my own source for snaps then. I already have the odroid oem snap in the store. If that is the way thats fine too. | 09:54 |
| chihchun | is rootfs of snappy ubuntu core built with this seed ? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily ? | 09:58 |
| chihchun | bafu: hi | 09:59 |
| bafu | chihchun, hi | 10:01 |
| ogra_ | chihchun, from the system-imae file in there | 10:02 |
| ogra_ | *image | 10:02 |
| chihchun | ogra_: thanks | 10:03 |
| chihchun | ogra_: for the device tarball, I assume it's built by CI system. But I could not find the source code or build script ? | 10:11 |
| ogra_ | no, it is built by cdimage during the rootfs build | 10:11 |
| ogra_ | which is done by live-build ... the configs and scripts used by live-build live in the livecd-rootfs package | 10:12 |
| chihchun | ogra_: got it, thanks | 10:12 |
| chihchun | did not aware the config of live-build also included | 10:13 |
| ogra_ | well, we abuse the chroot from it after the rootfs has been produced to actually roll the device tarball | 10:14 |
| ogra_ | so you have all in one central place | 10:14 |
| ogra_ | mvo, hmm ... | 10:41 |
| ogra_ | mvo, i wonder how/where we can ship mkenvimage in the snappy-hub tree | 10:42 |
| mvo | ogra_: hm, hm, its part of u-boot-tools, could we just depend on that? | 10:44 |
| ogra_ | the uboot-tools one might be older or use different defaults | 10:44 |
| ogra_ | since we require the uboot binary to be built by hand anyway we should use the mkenvimage from the same build imho | 10:45 |
| ogra_ | i have a proper binary here, i just dont know where to put it | 10:46 |
| ogra_ | mvo, http://people.canonical.com/~ogra/snappy/bootloader/ has a snap created from the tree now | 11:20 |
| ogra_ | (boots fine here ) | 11:20 |
| ogra_ | "Firefox prevented the execution of Adobe Flash for github.com, do you want to keep it blocked" .... | 11:59 |
| ogra_ | WTF | 11:59 |
| ogra_ | where does github use flash ! | 11:59 |
| tbr | IIRC in the repository url widget and somewhere else | 12:02 |
| ogra_ | gross | 12:05 |
| mvo | ogra_: nice, let try it too | 12:06 |
| kyrofa | seb128, quick status update: the snappy scope is in the NEW queue awaiting review | 12:06 |
| seb128 | kyrofa, hey, great, let me have a look | 12:07 |
| ogra_ | kyrofa, was that a subtle way of asking seb128 to review it ? | 12:07 |
| ogra_ | :) | 12:07 |
| longsleep | Flash is used in all kind of places as it is the only way to put something into clipboard with javascript. | 12:07 |
| kyrofa | ogra_, maaaaaaaybe | 12:07 |
| ogra_ | :D | 12:07 |
| ogra_ | longsleep, well, github was one of the pages where i wouldnt have expected it | 12:07 |
| tbr | ogra_: just as I remembered, it's some sort of clipboard bridge flash abomination, probably due to the native browser restrictions on pushing things to clipboard | 12:07 |
| ogra_ | yeah | 12:08 |
| longsleep | ogra_: they have the copy to clipboard button for clone urls | 12:08 |
| ogra_ | because selecting an url and hitting ctrl-c is so hard :P | 12:08 |
| ogra_ | but yeah, understood :) | 12:09 |
| * tbr uses a different paste buffer anyway, so selects the url manually in the field and then middle-click pastes | 12:09 | |
| ogra_ | same here | 12:09 |
| ogra_ | but even here ctrl-c works :) | 12:10 |
| ogra_ | and i kind of would expect people that use git to know how to copy/paste something | 12:10 |
| ogra_ | (or is that knowledge limited to us bzr users ? (muhahaha)) | 12:10 |
| === erkules_ is now known as erkules | ||
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mvo, did it work for you ? | 12:37 |
| mvo | ogra_: haven't checked yet, the BBB is busy with some squashfs releated work | 12:38 |
| ogra_ | ah | 12:38 |
| ogra_ | well, i think we should soon start to produce an image to start testing | 12:38 |
| longsleep | i would be interested in that as well :) | 12:39 |
| mvo | ogra_: good point, I will try to hurry here (hurry and BBB is a bit of a contradiction though) | 12:39 |
| ogra_ | haha, yeah | 12:39 |
| ogra_ | we should have picked the parallella board as default :) | 12:40 |
| kyrofa | ogra_, ahh, the parallella | 12:41 |
| ogra_ | shiny little fast thing :) | 12:41 |
| ogra_ | (the odroid is nearly as fast though) | 12:41 |
| longsleep | you can test my snap :P https://www.stdin.xyz/downloads/people/longsleep/tmp/odroidc-bootloader/ | 12:42 |
| ogra_ | i have a bit of an SD card shortage atm ... but will try it at one point | 12:42 |
| longsleep | so - now that i have a snap the only thing i need now is a ubuntu-device-flash which builds an image using uboot.env :) | 12:44 |
| kyrofa | ogra_, speaking of SD cards, how hard is it to get u-boot to boot to a USB HD instead of the SD? | 12:44 |
| ogra_ | kyrofa, that depends completely on the ROM | 12:44 |
| ogra_ | some boards can do that ... but it is realyl rare | 12:44 |
| ogra_ | (the pandaboard was capable of booting via USB if you gave it a uboot binary via netboot or usb cable iirc) | 12:45 |
| longsleep | odroidc u-boot does not support booting from USB | 12:45 |
| kyrofa | ogra_, that's too bad. My main personal web server is a mirabox (one of those plug computers), and that thing toasts through an SD card a year or so | 12:46 |
| ogra_ | well, if you have an MMC inside where you could put the /boot partition on to carry bootloader, kernel and initrd, booting off USB key is possible | 12:47 |
| ogra_ | but you need these bits in place on SD or MMC | 12:47 |
| kyrofa | ogra_, hmm, interesting. And that stuff could be read-only, yeah? I may ask your advice on that later :) | 12:48 |
| ogra_ | well, if you use snappy it cant be read only because snappy needs to be able to modify the bootloader config | 12:48 |
| ogra_ | but if you stick to one image and dont upgrade you could keep it readonly indeed | 12:49 |
| ogra_ | the good thing is that we mount everything by label ... so you can just use a normal snappy img and dd it to your usb key and it will work | 12:49 |
| ogra_ | (you could do that only with the writable partition btw, since that is the only one that actually counts on snappy ... i.e. remove the label from the writable lartition on the SD, format the USB key and copy the former writable partition contents over ... then add a label to the usb key and it should work) | 12:51 |
| * ogra_ is plannning to do that for a owncloud install here ... | 12:51 | |
| kyrofa | ogra_, heh, that's currently one of the usages for my current server | 12:52 |
| kyrofa | ogra_, good ideas, thank you :) | 12:52 |
| mterry | sergiusens, could you install python3-fixtures to the snapcraft tarmac instance? | 12:53 |
| === chihchun_afk is now known as chihchun | ||
| rsalveti | fgimenez: replying back your question from yesterday, just report to snappy itself (about the writable-paths) | 12:57 |
| kyrofa | sergiusens, we talked briefly last week about making webdm available in the Ubuntu Personal channel. Is that still something you plan on doing? | 12:59 |
| fgimenez | rsalveti, ok thx, will do | 12:59 |
| longsleep | btw, anyone has written a tool to enlarge the writeable partition to fill the whole storage device? | 13:07 |
| longsleep | i mean i can easily use a script for my particular device but i would like to see a generic solution for this in snappy. | 13:08 |
| === alexabreu is now known as alex-abreu | ||
| ogra_ | longsleep, we have scripts for the initrd to do that ... just not ported over to snappy | 13:13 |
| longsleep | ogra_: is this planned? I know cloud-init can do it - do you mean these scripts? | 13:13 |
| ogra_ | no, initrd scripts that do it before the first mount | 13:14 |
| longsleep | ok - that was what i have to do myself unless snappy gets it by default :) | 13:14 |
| longsleep | i mean i have plenty of stuff to be done on first boot | 13:15 |
| longsleep | like waiting for entropy, generate keys, dhparams etc .. | 13:15 |
| ogra_ | not from the initrd i hope :) | 13:16 |
| longsleep | yeah - from the initrd it should only be the resize | 13:17 |
| longsleep | though i do consider waiting for entropy in initrd as well | 13:17 |
| * rsalveti finally get to read backlog | 13:37 | |
| === chihchun is now known as chihchun_afk | ||
| rsalveti | Chipaca: better to ask mvo, he is the one that added the entries to the checklist | 13:43 |
| Chipaca | fair :) | 13:44 |
| rsalveti | longsleep: https://trello.com/c/EdWkd2UW/181-use-cloud-init-to-extend-resize-the-writable-partition-during-first-boot | 13:45 |
| rsalveti | longsleep: that's in the list, patches are welcome if you want to give it a try | 13:45 |
| longsleep | rsalveti: my problem is that i do not like cloud-init very much :) | 13:46 |
| rsalveti | hard to find one that really likes it :-) | 13:46 |
| * ogra_ is with longsleep :) | 13:46 | |
| longsleep | hehe | 13:46 |
| longsleep | well - i have some gear to do it without cloud init for non snappy ubuntu | 13:46 |
| rsalveti | we don't yet know if it's better to do in the initrd or cloud-init | 13:47 |
| rsalveti | the good with thing with cloud-init is that we don't need to add extra logic in the initrd itself | 13:47 |
| rsalveti | but that's the main difference | 13:47 |
| ogra_ | but get multi hour boot times :P | 13:48 |
| ogra_ | and python on the image | 13:48 |
| rsalveti | well, cloud-init is already there | 13:48 |
| longsleep | cloud init is so bloated - i would like it to go away :) | 13:48 |
| rsalveti | the new cloud-init should probably be in go | 13:48 |
| rsalveti | but further down the line | 13:48 |
| longsleep | yeah - i can see that. Though cloud-init is the only thing which stopped me to implement something so far | 13:49 |
| longsleep | and for me, that is just one problem. I need means to run (and optionally block) for other things on boot as well | 13:50 |
| longsleep | first boot - i mean | 13:50 |
| rsalveti | yeah, it's not ideal | 13:51 |
| longsleep | in non snappy i just have a upstart service with run-parts a directory and writing a marker when complete. That way i can easily spawn multiple stuff, wait on it and make sure it is only done once. | 13:51 |
| longsleep | for example on the ODROIDC generating 2048 bit dhparams takes over 10 minutes | 13:52 |
| longsleep | and the question is what services are allowed to start until that is complete | 13:53 |
| longsleep | assuming a default params file is shipped or something | 13:53 |
| longsleep | another thing is the system time | 13:53 |
| longsleep | when generating certificates on first boot, it is bad if the time is 1970 :) | 13:53 |
| ogra_ | longsleep, that means you have not enabled fixrtc on the cmdline then | 13:54 |
| longsleep | i have - but i have no clue what it does | 13:54 |
| longsleep | if it does not happen with snappy thats fine | 13:54 |
| longsleep | just an example from other devices | 13:54 |
| ogra_ | well, seems it doesnt work then ... it forces the clock to the last mount time or the creation time of your partition | 13:55 |
| ogra_ | (whatever is newer) | 13:55 |
| longsleep | that is reasonable | 13:55 |
| ogra_ | so while the clock will still be off, the diff wont be that massive | 13:55 |
| longsleep | yeah that should be fine. | 13:55 |
| mvo | Chipaca: what was the question again? sorry can't see it in the backlog | 13:55 |
| Chipaca | mvo: there wasn't a question in the backlog; just a note to ask a quesiton | 13:56 |
| mvo | heh, ok | 13:56 |
| Chipaca | mvo: what's the difference between "snappy service list" and "snappy service status"? | 13:56 |
| mvo | Chipaca: I was thinking that list would simply list the available ones and status gives details for a specific one, but that was shooting from the hip, so feel free to override/refine/improve :) | 13:57 |
| Chipaca | mvo: ok, i'll implement status and then we see if we need list | 13:57 |
| mvo | sounds good | 13:58 |
| longsleep | rsalveti, ogra_ : Well i just tried the stuff cloud-init is doing - seems all the gear is there (growpart, resize2fs). | 14:14 |
| ogra_ | sure | 14:14 |
| rsalveti | longsleep: yeah, might be a config change only | 14:15 |
| longsleep | the config says something about sfdisk missing which is true but it does not seem to be required. I just ran growpart and then resize2fs. Growpart showed some warning about sfdisk but did the trick just fine. Did not even have to reboot. | 14:16 |
| longsleep | so this could be a 3 liner script instead of cloud-init. Find disk device and partition number for writable label. Run gropwart on that partition, on success run resize2fs | 14:17 |
| rsalveti | yup | 14:20 |
| longsleep | rsalveti: In your trello extend/resize task there is a reference to "recovery" what is this "recovery" ? | 14:20 |
| rsalveti | longsleep: we had an idea to investigate on having a recovery (similar to what we have for phones), but for snappy | 14:21 |
| longsleep | rsalveti: oh all right - but that does not exist yet? | 14:22 |
| rsalveti | the recovery could help restoring the image to factory, help sideloading apps and doing extra logic | 14:22 |
| rsalveti | longsleep: nops, just an idea atm | 14:22 |
| longsleep | ok | 14:22 |
| dholbach | mvo, mterry: thanks a bunch! | 14:33 |
| elopio | zyga: have you tried to measure the code covered by plainbox? | 14:37 |
| zyga | elopio: hey | 14:39 |
| zyga | elopio: code coverage of plainbox itself? | 14:39 |
| zyga | elopio: yes | 14:39 |
| zyga | elopio: cli parts are poorly covered, most of the core is covered well | 14:40 |
| zyga | elopio: though a few of the new features may have lowered the scoer a little | 14:40 |
| zyga | elopio: there's a script in trunk to run all tests with coverage | 14:40 |
| tedg | mvo, So I think I might be caught up in the conflict between the copy plugin and trunk. Are you merging that? | 14:40 |
| elopio | zyga: not plainbox itself. The code that the plainbox tests are covering. | 14:41 |
| elopio | like in snapcraft, call plainbox from python3-coverage or something like that. | 14:41 |
| mvo | tedg: I can fix merge conflicts, sure, one sec | 14:41 |
| tedg | Great, thank you! | 14:41 |
| zyga | elopio: ah | 14:41 |
| zyga | elopio: no, that's hard to do in general | 14:42 |
| zyga | elopio: though, if we specialize | 14:42 |
| zyga | elopio: then it's quite possible | 14:42 |
| zyga | elopio: I wrote a bit of an interesting proof of concept a while ago | 14:42 |
| zyga | elopio: you can run a test with that, it will show you what was executed per test case | 14:42 |
| zyga | elopio: it was specialized to python obviously | 14:42 |
| zyga | elopio: (our code tends to be split between python, shell and C so we did not pursue that but for python-specific projects we could) | 14:43 |
| zyga | elopio: if you have ideas how you'd like to make it better to run unit tests via plainbox I'm all ears | 14:43 |
| elopio | zyga: we only need python here. Do you have a link? | 14:43 |
| zyga | elopio: I'll be adding benchmark support next week | 14:43 |
| zyga | elopio: it wasn't specific for plainbox but sure, let me find it | 14:43 |
| zyga | elopio: though the benchmarks I'm after are like "this test compiles the linux 3.14 kernel" | 14:45 |
| zyga | elopio: :-) | 14:45 |
| * zyga looks at his +junk branches | 14:46 | |
| zyga | it's somewhere there :D | 14:46 |
| elopio | zyga: for snapcraft seems to be a good fit. I'd like nicer regex matching, but we can add that. | 14:47 |
| zyga | elopio: one thing that's possible (not sure if useful yet) | 14:47 |
| zyga | elopio: is write a local job that looks at your python code to see what tests exist (just to discover them) | 14:47 |
| zyga | elopio: and then let you run each single test directly via plainbox (each test would become a new job) | 14:48 |
| zyga | elopio: local jobs are like test generators, they can run any code and can print additional test definitions) | 14:48 |
| * zyga goes through his old code... | 14:57 | |
| kyrofa | tedg, the click scope launches click apps and scopes via UAL, right? | 14:57 |
| tedg | kyrofa, Basically, it sends URLs to the dash when sends them to URL dispatcher which uses UAL. | 14:59 |
| zyga | found it :) | 14:59 |
| kyrofa | tedg, alright. Do you envision the same happening for snaps? | 14:59 |
| zyga | whee | 14:59 |
| tedg | kyrofa, Yeah, I do. | 14:59 |
| tedg | kyrofa, Should just be appid:// URLs | 14:59 |
| kyrofa | tedg, should something like that work currently? | 15:00 |
| tedg | kyrofa, No, there's no way to define an application in a snap today. | 15:00 |
| mvo | ogra_: http://paste.ubuntu.com/11914911/ <- this looks good, right? | 15:00 |
| ogra_ | mvo, "reading uboot.env" | 15:00 |
| tedg | kyrofa, Only binaries and services, it needs to grow a bit of functionality before applications can exist. | 15:00 |
| ogra_ | mvo, so it does :) | 15:00 |
| kyrofa | tedg, alright, interesting. What needs to grow beyond having a binary and some sort of .desktop (or yaml, whatever) file with install hooks? | 15:02 |
| mvo | ogra_: yay! | 15:03 |
| tedg | kyrofa, Well, it is more fundamental than that. There's no such thing as a way to provide install hooks or anything like that. | 15:03 |
| tedg | kyrofa, So once a system is defined for that, it can be used to provide application information. | 15:03 |
| tedg | kyrofa, Then we'll have appids. | 15:03 |
| zyga | elopio: one sec, just adding boilderplate and fixing this to work on python3 | 15:04 |
| zyga | elopio: (it's pretty old) | 15:04 |
| kyrofa | tedg, okay, I gotcha | 15:04 |
| mvo | Chipaca: will you be able to do a bit of code review for the new uboot env snappy code today? | 15:05 |
| kyrofa | tedg, do you have any idea of a timeline for those features? | 15:06 |
| Chipaca | mvo: sure | 15:06 |
| mvo | Chipaca: https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 and the new uboot-go env code (which is relatively small). happy to talk about deails | 15:08 |
| tedg | kyrofa, I don't know of anyone working on it currently. | 15:10 |
| tedg | kyrofa, I proposed a spec, but it hasn't passed through the system yet. | 15:10 |
| tedg | kyrofa, It also needs more work if the basics do get approved there. | 15:10 |
| kyrofa | tedg, alright. Just curious from an Ubuntu Personal perspective | 15:11 |
| mvo | tedg: hm, I don't see a conflict in snapcraft between copy-plugin and trunk(?) | 15:11 |
| === Abhishek___ is now known as Abhishek__ | ||
| kyrofa | tedg, in the same vein, will UAL handle legacy app launches? | 15:11 |
| tedg | mvo, I've got the copy tests failing, could have been my merge, but I saw this comment from mterry: https://code.launchpad.net/~mvo/snapcraft/copy-plugin/+merge/264706/comments/665846 | 15:12 |
| tedg | kyrofa, I understand, not sure what you mean by "legacy" in this context. | 15:12 |
| kyrofa | tedg, libertine | 15:12 |
| tedg | kyrofa, libertine or /usr/share | 15:12 |
| tedg | kyrofa, Yes, there's a branch for that, needs review. | 15:13 |
| zyga | elopio: almost done | 15:13 |
| elopio | zyga: no hurries. | 15:13 |
| kyrofa | tedg, awesome! Okay, thanks for the update :) | 15:13 |
| Chipaca | mvo: i think you need to update depedencies.tsv | 15:14 |
| mterry | tedg, the tests in the copy-plugin branch failing you mean? | 15:15 |
| zyga | elopio: python3 support for the example and I'm done | 15:20 |
| tedg | mterry, Yeah | 15:23 |
| mvo_ | Chipaca: feedback on uboot-go would also be great, it has no review yet and api review etc | 15:23 |
| Chipaca | sure | 15:23 |
| mvo_ | \o/ | 15:23 |
| kyrofa | tedg, the spec you proposed, is it the extension points document? | 15:37 |
| tedg | kyrofa, Yes | 15:38 |
| Chipaca | mvo_: how do i review the one in github? | 15:39 |
| * Chipaca has a low github score | 15:39 | |
| tedg | kyrofa, Idea being that person could provide extension points for applications (devs don't need them as much) and then apps could connect into those points. | 15:39 |
| mvo_ | Chipaca: just clone and yell at me via mail or irc | 15:39 |
| mvo_ | Chipaca: or file issues, but I think thats more overhead | 15:40 |
| * Chipaca engages yelling mode | 15:40 | |
| Chipaca | mvo_: so, silly things first | 15:41 |
| Chipaca | mvo_: https://github.com/mvo5/uboot-go/blob/master/uenv/uboot.go~ | 15:41 |
| * mvo_ drops dead | 15:41 | |
| mvo_ | thanks Chipaca | 15:41 |
| Chipaca | mvo_: next, in https://github.com/mvo5/uboot-go/blob/master/uenv/env.go | 15:42 |
| Chipaca | mvo_: you don't check the writes | 15:43 |
| Chipaca | mvo_: what's the reasoning there? | 15:43 |
| Chipaca | mvo_: not so worried about the writes to the bytes buffer, but the writes to the actual file probably need checking | 15:43 |
| mvo_ | Chipaca: absolutely | 15:43 |
| Chipaca | mvo_: that's in Save fwiw | 15:44 |
| ogra_ | pfft, that sounds like we even test code ... "checking" hah | 15:44 |
| Chipaca | mvo_: and you don't Sync the file | 15:44 |
| mvo_ | Chipaca: yes! | 15:44 |
| ogra_ | Chipaca, we mount with sync option | 15:44 |
| ogra_ | (while more elegant it shouldnt be needed to do any extra sync call) | 15:45 |
| mvo_ | I will still add the f.Sync() | 15:45 |
| Chipaca | ogra_: great! that means the Sync will be instant | 15:45 |
| Chipaca | :) | 15:45 |
| ogra_ | yeah | 15:45 |
| mvo_ | Chipaca: thats great great feedback, keep it coming | 15:45 |
| Chipaca | mvo_: you also don't do the atomic rename dance | 15:45 |
| ogra_ | technically not needed ... for code sexiness it is though :) | 15:45 |
| Chipaca | mvo_: not sure if that's important in this case | 15:45 |
| Chipaca | ogra_: ideally we could stop using sync, and reap perf gainz :-p | 15:46 |
| Chipaca | anyway | 15:46 |
| ogra_ | on /boot ? | 15:46 |
| ogra_ | :) | 15:46 |
| Chipaca | mvo_: in Import, why don't you return scanner.Err() instead of only returning it if it's not nil, and returning nil otherwise? | 15:46 |
| zyga | elopio: ok, done https://git.launchpad.net/testtrace/tree/demo.py | 15:46 |
| Chipaca | ogra_: maybe in arm we don't copy kernels and initrds around between a/ and b/ ? | 15:46 |
| Chipaca | ogra_: i thought we did | 15:46 |
| Chipaca | ogra_: and sync makes that slow | 15:47 |
| zyga | elopio: not much but I did clean it up a little | 15:47 |
| ogra_ | Chipaca, ah | 15:47 |
| ogra_ | i didnt think of that | 15:47 |
| mvo_ | Chipaca: yes! | 15:47 |
| Chipaca | mvo_: and starting to get really nit-picky with this file: in āSet sets an environment name to the given valueā | 15:48 |
| Chipaca | mvo_: you could write āSet an environment name to the given valueā | 15:48 |
| Chipaca | mvo_: ditto āGet returns the value of the environment variableā -> āGet the value of the environment variableā | 15:49 |
| mvo_ | Chipaca: I guess its a good sign that we are at this level already | 15:49 |
| mvo_ | :P | 15:49 |
| zyga | elopio: have a look and tell me if it's of any use to you | 15:49 |
| Chipaca | either that, or my head works via BFS | 15:49 |
| mvo_ | heh | 15:49 |
| * mvo_ starts fixing | 15:49 | |
| elopio | zyga: looking. Also looking at the python3-coverage approach, that doesn't require a TestCase. | 15:50 |
| zyga | elopio: they are based on the same logic | 15:50 |
| zyga | elopio: I mean, the same low-level feature | 15:50 |
| zyga | elopio: this is tied to a test case so that one can easily get data that is per-test-case | 15:50 |
| zyga | elopio: though this is just an old proof-of-concept, dusted and packaged | 15:51 |
| elopio | zyga: it's useful, thanks. | 15:51 |
| elopio | what's not clear for me is why python3-coverage needs to run a python file. Seems the same to me who starts the run. But I'll dig more, slowly through the week. | 15:52 |
| zyga | elopio: because it sets up that low level trace call this way | 15:53 |
| === soee_ is now known as soee | ||
| Chipaca | mvo_: that's all i have for now :) | 15:57 |
| mvo_ | Chipaca: I pushed a updated version, let me know if there is anything I overlooked or if my comment on e.g. write-rename make sense | 16:00 |
| Chipaca | mvo_: there is one thing in run-checks, but we have the same issue | 16:01 |
| Chipaca | mvo_: we should probably quote the lint output | 16:01 |
| elopio | wow, this works. | 16:01 |
| mvo_ | Chipaca: indeed, let me fix that | 16:02 |
| elopio | mterry: zyga: if we replace all the calls to snapcraft to something like "python3-coverage run --append --source snapcraft bin/snapcraft", we would be able to collect the coverage. | 16:02 |
| elopio | easiest solution that comes to mind. | 16:03 |
| mvo_ | nice! | 16:03 |
| Chipaca | mvo_: difference being http://pastebin.ubuntu.com/11915213/ | 16:03 |
| mvo_ | Chipaca: fixed, I may cowboy it into lp:snappy | 16:04 |
| Chipaca | mvo_: haven't looked at the gofmt output, but it might need the same kindness | 16:04 |
| mvo_ | Chipaca: indeed so, updated that too now | 16:06 |
| mvo_ | Chipaca: I can prepare a branch for snappy now too, unless you want to do that (don't want to steal your credits :) | 16:07 |
| Chipaca | mvo_: s/rational/rationale/; s/FAt/FAT/; s/we not truncate/$english/; and \o/ | 16:08 |
| * ogra_ prefers FAT free ... | 16:09 | |
| mvo_ | Chipaca: pfff, whats wrong with "we not truncate" :P | 16:09 |
| mvo_ | Chipaca: fixing ! | 16:09 |
| Chipaca | mvo_: i no idea | 16:10 |
| Chipaca | mvo_: but it wrong | 16:10 |
| Chipaca | mvo_: as if something missing | 16:10 |
| mvo_ | Chipaca: :-D pushed another fix | 16:10 |
| * mvo_ hugs Chipaca for his patience | 16:11 | |
| FergusL | anyone tried Snappy on OrangePi boards ? | 16:11 |
| ogra_ | FergusL, a few people i would think | 16:11 |
| ogra_ | (or is OrangePi different from OrangeBox) ? | 16:11 |
| Chipaca | mvo_: wrt snappy branch, i don't mind either way :) | 16:12 |
| mvo_ | Chipaca: then you do it and I get dinner ;) | 16:12 |
| Chipaca | ogra_: http://www.orangepi.org/ | 16:12 |
| ogra_ | oh | 16:12 |
| mvo_ | Chipaca: and I will come back later and fix all the issues in the -env2 branch and prepare the backport after that - deal? | 16:12 |
| ogra_ | WOW ! | 16:12 |
| ogra_ | sata and GigE | 16:13 |
| ogra_ | FergusL, then i was wrong ... :) i mixed it up | 16:13 |
| longsleep | yeah, but crappy allwinner cpu | 16:13 |
| ogra_ | well, you cant have everything | 16:14 |
| Chipaca | and it has an upgrade key! | 16:14 |
| Chipaca | mvo_: deal | 16:14 |
| fgimenez | nice evening everyone o/ | 16:17 |
| FergusL | I have OrangePi 2 with H3 (quad 1.6GHz A7) | 16:20 |
| Chipaca | mvo_: only thing I see in -env2 is that we don't have a packaged golang-uboot-yadda | 16:23 |
| mvo_ | Chipaca: indeed, please add this as a review comment (if you haven't already). I will either package or just pull it into snappy, but it feels like its really a standalone thing | 16:25 |
| * Chipaca nods | 16:25 | |
| Chipaca | mterry: any reason not to approve the copy plugin? | 16:42 |
| Chipaca | ah, the last changes after your comments are fairly new | 16:43 |
| longsleep | Anyone who is interested in a simple generic Snappy writable resize to max script - grab it here: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh | 16:50 |
| mterry | Chipaca, also all my previous review comments haven't been addressed yet | 17:07 |
| mterry | Chipaca, that is one thing I don't like about inline comments. They get "lost" when someone does any update at all | 17:08 |
| === howefield_afk is now known as howefield | ||
| tedg | mterry, Do I have the wrong version of something? manage.py: error: unrecognized arguments: -d /tmp/tmp.5BfenzNjeb | 18:08 |
| mterry | tedg, README.md should have the right PPA to install to get the correct plainbox version | 18:08 |
| mterry | tedg, also, not on wily?! :) | 18:08 |
| tedg | mterry, Ha, yeah. Can't wait for libertine container to work :-) | 18:09 |
| mterry | tedg, libertine? | 18:10 |
| tedg | mterry, The system that's being developed to run a "standard Ubuntu" on a read only filesystem. | 18:10 |
| tedg | mterry, Runs as a container, but then exports the apps to the launcher, etc. | 18:10 |
| mterry | ah interesting | 18:10 |
| kyrofa | rsalveti, we're investigating i18n in the snappy scope. Do you know if webdm supports that at all? | 18:11 |
| tedg | The nice part is that you can have real apps on multiple containers then. So it'll be easier to keep a wily version of things around. | 18:11 |
| mterry | mvo_, can snap binary exec: lines be multi-word like service start/stop lines can be? I'm guessing so | 18:38 |
| mvo_ | mterry: yes, that should work | 18:39 |
| mterry | mvo_, cool | 18:39 |
| kyrofa | Hey bregma, did you ever try running Ubuntu Personal on the rpi2? | 18:54 |
| bregma | kyrofa, Ubuntu Personal no, because there is missing support for Mir (or Mir is missing support) | 18:55 |
| bregma | or both | 18:55 |
| kyrofa | bregma, heh, okay gotcha | 18:55 |
| kyrofa | ogra_, were you ever able to get i2c + devicetree working on the rpi image? | 18:57 |
| ogra_ | kyrofa, not yet, thats in the works for the next (delayed) stable image | 18:58 |
| ogra_ | working on fixing the image itself before going back to the rpi | 18:59 |
| kyrofa | ogra_, alright, sounds good | 19:00 |
| ogra_ | i'll send a mail announcement once the image is ready | 19:00 |
| ogra_ | we're just re-working a critical part for the default image that takes my attention atm | 19:00 |
| tedg | mterry, So I think that focused assemble is confusing the copy plugin and breaking it's test. | 19:53 |
| tedg | its' | 19:54 |
| tedg | mterry, Do you have a second to take a look at that? | 19:54 |
| tedg | mterry, I think that it shouldn't be in the build step anymore, no? | 19:55 |
| mterry | tedg, yeah... the integrated test for copy should do 'snapcraft stage' instead of 'snapcraft snap' since it doesn't provide the metadata that 'snapcraft snap' now demands | 19:56 |
| mterry | tedg, and should test ./stage/dst instead of ./snap/dst | 19:56 |
| tedg | Ah, okay. | 19:56 |
| tedg | mterry, Cool, works, thanks! | 19:57 |
| mterry | tedg, sweet | 19:57 |
| kyrofa | ogra_, without i2c, does that mean GPIO works OOTB? | 20:00 |
| kyrofa | ogra_, on the rpi2 | 20:00 |
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!