| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === ev_ is now known as ev | ||
| * conyoo good morning o_O | 05:51 | |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| fgimenez | good morning | 07:15 |
|---|---|---|
| JamesTait | Good morning all; happy Friday, and happy Yellow Pig Day! 😃 | 08:38 |
| mvo | ogra_: I think we are getting somewhere https://github.com/mvo5/uboot-env-go might be simpler for us than fw_setenv/printenv and we can use it directly, but I will stop on that for now and wait how the rest of the uboot env work goes | 09:22 |
| ogra_ | mvo, yeah, i'm fiddlin with a snap currently to have the needed bits (and i also did a new checkout of the latest uboot before producing the new binary) | 09:28 |
| mvo | ogra_: nice | 09:32 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mvo, wget http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap && sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 ... then dd it ... | 10:23 |
| ogra_ | it has all env vars inside the uboot.env and ships an empty uEnv.txt (i think snappy still checks for that file to determine if we boot uboot) | 10:24 |
| ogra_ | boots fine for me | 10:24 |
| ogra_ | mvo, http://paste.ubuntu.com/11892121/ is the content of my input file for uboot.env | 10:26 |
| ogra_ | (note there is nothing from snapy-system.txt in it yet) | 10:28 |
| mvo | ogra_: hm, we need that snappy-system.txt in there too, no? | 10:39 |
| ogra_ | yes, and the stamp | 10:39 |
| mvo | ogra_: yeah, uEnv.txt is currently needed, my branch fixes that (or will) | 10:40 |
| ogra_ | but that requires changes to udf | 10:40 |
| mvo | aha, is that writing it? | 10:40 |
| ogra_ | i think so ... sergiusens should know | 10:40 |
| mvo | so udf would basilcy have to take the uboot.env and append the new bits from the oem snap (?) | 10:40 |
| mvo | out uboot.env with all the default config | 10:40 |
| mvo | if so I add a task for that to the card | 10:41 |
| ogra_ | well, the above is only the basic bit, with that we should have a good image to do the further work | 10:41 |
| mvo | ok | 10:41 |
| mvo | so the uboot.env will just load the snappy-system.txt (?) | 10:41 |
| ogra_ | i guess we *could* just put the snappy-system.txt content inside uboot.env at the snap level | 10:41 |
| mvo | I guess thats fine, we may even keep that if its just reading from that file, i.e. as long as we keep the system_ab and stuff out | 10:41 |
| ogra_ | i would like to get rid of all these scattered single files ... | 10:42 |
| mvo | the important part is that the uEnv.txt needs to no longer take the stamp into account and instead a new trail boot var | 10:42 |
| mvo | yeah, agreed | 10:42 |
| ogra_ | the question is, do we want that for 15.04 | 10:42 |
| ogra_ | or do we just want the very basic bits for 15.04 to not risk stability | 10:42 |
| mvo | thats a good question, my gut feeling is yes, the amount of churn is already pretty substancial, so best to have 15.04 and 16.04 in sync | 10:43 |
| ogra_ | (whouch would mean only snappy_ab and the stamp inside the env | 10:43 |
| ogra_ | ok, then we need udf involvement i thinnk | 10:43 |
| ogra_ | and either write the snappy-system.txt content to the uboot.env directly ... or have the file content in the snap (not sure why we dont have that currently, there might be a reason) | 10:44 |
| mvo | I guess the reason is to keep snappy-system.txt bits small | 10:46 |
| ogra_ | i'm a little curious what happens to the env settings that come from ATAGs ... once we call "saveenv" they will be stored in uboot.env | 10:46 |
| ogra_ | (MAC address and the like ... nothing that chnages anyway, but i wonder if uboot will get alon with them being already set) | 10:47 |
| mvo | ATAGs? | 10:47 |
| ogra_ | well, or values from the dtb ... not sure, but there are like 10 vars set by default even without any environment | 10:48 |
| mvo | aha | 10:48 |
| mvo | ok | 10:48 |
| ogra_ | and saveenv during the boot will save them in uboot.env | 10:48 |
| ogra_ | (and i dont thin there is something where you can only save a single var change to the environment, afaik it is all or nothing)+ | 10:49 |
| sergiusens | mvo: ogra_ that is automatic already (if the file is listed) | 10:49 |
| ogra_ | sergiusens, "that" ? | 10:49 |
| sergiusens | ogra_: uboot.env copy from udf | 10:49 |
| ogra_ | sergiusens, yeah, thats not the issue | 10:50 |
| ogra_ | sergiusens, we need to feed the content of snappy-system.txt into uboot.env | 10:50 |
| ogra_ | and afaik thats created by udf, no ? | 10:50 |
| sergiusens | ogra_: yes | 10:50 |
| ogra_ | so it needs to learn about that ... or we move snappy-system.txt content directly into the snap | 10:51 |
| sergiusens | ogra_: you should be able to override it by adding it to the gadget (and that would be supported in uprgades for rolling at least) | 10:51 |
| ogra_ | (meaning directly into uboot.env at creation time) | 10:51 |
| ogra_ | so i could ship an empty file ... and in parallel push the content into uboot.env | 10:52 |
| ogra_ | hmm | 10:52 |
| ogra_ | sounds doable | 10:52 |
| sergiusens | ogra_: this might put some stress in mvo's work into doing the right thing (TM) inside snappy on upgrades, but he's smart ;-) | 10:54 |
| ogra_ | yeah, snappy needs to modify uboot.env | 10:54 |
| ogra_ | instead of the txt files | 10:54 |
| ogra_ | hrm | 10:54 |
| sergiusens | ogra_: right, but it needs to save the snappy-system.txt values before overwritting it, that's all | 10:55 |
| ogra_ | and we need to completely re-write the whole logic of the snappy_boot command | 10:55 |
| ogra_ | sergiusens, we can just have "snappy_stamp_last", "snappy_ab_last" and "snappy_mode_last" vars if we need that | 10:56 |
| ogra_ | and have snappy store the values inside uboot.env too | 10:56 |
| ogra_ | i want to get rid of all additional files | 10:57 |
| ogra_ | at least for rolling (not sure we fcan for 15.04) | 10:57 |
| mvo | ogra_: do we need to change it all? grub is also doing it with a single env, it seems we can copy that behavior for now. and yes +1 for snappy_ab_last etc | 11:01 |
| mvo | ogra_: thats going to be needed anyway for the os/kernel snap work | 11:01 |
| mvo | ogra_, sergiusens: sound I need to write some uenv merge code, let me do that | 11:02 |
| ogra_ | mvo, whats "it" ? | 11:05 |
| ogra_ | do you mean snappy_boot ? | 11:05 |
| ogra_ | we need to et rid of the fatwrite call in it at least ... and also change the testing for snappy_stamp ... since it wont be a file but a variable value now | 11:05 |
| mvo | ogra_: right, there is a snappy_trial_boot env in grub, one sec and I give you the details | 11:06 |
| mvo | ogra_: ok, so grub works like this: on boot grub itself sets snappy_trial_boot=1 and the boot-sucesss command in snappy clears that | 11:09 |
| mvo | ogra_: we could simply do the same for uboot now, right? my branch for snappy implements this cleaning in uboot now too | 11:09 |
| ogra_ | yeah | 11:09 |
| ogra_ | i'm just preparing a snap with merged snappy-systerm-txt (and an empty .txt file) | 11:10 |
| mvo | silly question, whats the canonical location for uEnv.txt? | 11:10 |
| mvo | ogra_: coool! | 11:10 |
| ogra_ | (still using the old snappy_boot command though) | 11:10 |
| mvo | ok | 11:11 |
| * ogra_ wishes for faster dd | 11:11 | |
| ogra_ | *twiddle* | 11:17 |
| ogra_ | yay, seems to boot | 11:17 |
| ogra_ | bah | 11:21 |
| ogra_ | sergiusens, udf doesnt seem to respect the empty snappy-system.txt file ... | 11:21 |
| ogra_ | i still have content in it | 11:21 |
| ogra_ | http://paste.ubuntu.com/11892317/ | 11:23 |
| ogra_ | sergiusens, ^^^ | 11:23 |
| * ogra_ empties it manually ... crosses fingers and reboots | 11:25 | |
| ogra_ | looks like it boots | 11:25 |
| sergiusens | ogra_: k | 11:26 |
| ogra_ | geez ! | 11:26 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ cat /boot/uboot/snappy-system.txt | 11:26 |
| ogra_ | snappy_mode=regular | 11:26 |
| ogra_ | snappy_ab=a | 11:26 |
| ogra_ | still writes to it somewhere | 11:26 |
| sergiusens | ogra_: you need a new snappy which mvo is taking care of I gues | 11:26 |
| sergiusens | s | 11:26 |
| ogra_ | ah, it writes that file after boot ? | 11:27 |
| sergiusens | ogra_: yeah, with the snappy-boot task | 11:27 |
| ogra_ | k | 11:27 |
| sergiusens | or snappy booted | 11:27 |
| ogra_ | well, but udf needs fixing too | 11:27 |
| sergiusens | ogra_: yes; but it is going to be hard to fix as we need to support older images too :-/ | 11:28 |
| sergiusens | ogra_: that use that snappy logic | 11:28 |
| ogra_ | well, just make it not create the snappy-system.txt file if the snap ships it | 11:28 |
| ogra_ | that would be anough | 11:29 |
| ogra_ | *enouh | 11:29 |
| ogra_ | bah ! | 11:29 |
| sergiusens | ogra_: right, but think of 15.04 and creating older images which still use the older snappy logic | 11:29 |
| ogra_ | i only think of 15.04 here | 11:30 |
| sergiusens | ogra_: 15.04 rev 1 then | 11:30 |
| ogra_ | right | 11:30 |
| ogra_ | but there the snaps dont ship snappy-system.txt at all | 11:30 |
| ogra_ | so that should be safe | 11:30 |
| * ogra_ would really like to know why he only gets the colored "OK" output every second boot | 11:31 | |
| sergiusens | ogra_: right, but if we replace it from u-d-f and the old snappy logic is in place, rollbacks and upgrades would be broken | 11:31 |
| ogra_ | hmm | 11:32 |
| mvo | where is the cannical uEnv.txt location? do we have that in git somewhere? | 11:34 |
| ogra_ | in the snap | 11:34 |
| ogra_ | (snappy-hub i think... ) | 11:34 |
| * ogra_ hacks the loading of snappy-system.txt out of uboot.env ... lets see if it gets along, then the content wont matter | 11:35 | |
| ogra_ | and more dd fun ... | 11:36 |
| mvo | ogra_: try godd - it has a progress bar :) | 11:37 |
| ogra_ | mvo, and that makes it faster ? | 11:37 |
| ogra_ | :P | 11:37 |
| mvo | ogra_: weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeel | 11:37 |
| ogra_ | :D | 11:37 |
| mvo | ogra_: do you want me to build you a snappy with boot-success that uses snappy_trial_boot? | 11:38 |
| ogra_ | well, if that can write to uboot.env already | 11:38 |
| mvo | it can using fw_setenv, but I can make you a better (native) version I think that does not need /etc/fw_env.config | 11:39 |
| ogra_ | with your ned code ? yeah | 11:40 |
| ogra_ | *new | 11:40 |
| mvo | yep | 11:40 |
| mvo | ogra_: eh, sorry, I mean, whats the canonical location of snappy-system.txt ? i.e. the file that implements the actual logic? | 11:42 |
| ogra_ | mvo, on disk it is /boot/uboot/snappy-system.txt ... in udf i dont know | 11:42 |
| ogra_ | if this dd ever finishes i'll know if we can boot completely without it | 11:42 |
| mvo | ogra_: right, udf was the bit that I was looking for, thanks! i.e. in what version control system it is | 11:43 |
| mvo | thanks! | 11:43 |
| * sergiusens celebrates an exit status 2 on snappy install | 11:43 | |
| ogra_ | looks good ! | 11:43 |
| mvo | sergiusens: you were on fire yesterday? so many branches | 11:43 |
| ogra_ | (the boot i mean) | 11:43 |
| sergiusens | mvo: well none are really ready for review, I just got scared that I'd lose my laptop somehow and have to redo stuff :-P | 11:44 |
| mvo | lol | 11:44 |
| ogra_ | i updated http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap ... snappy-system.txt shouldnt be used at all anymore with that | 11:47 |
| ogra_ | (now we have snappy_stamp left) | 11:47 |
| mvo | near | 11:48 |
| mvo | neat | 11:48 |
| mvo | ! | 11:48 |
| ogra_ | so we shouldnt need changes to udf | 11:48 |
| ogra_ | (it is just ugly that the file sticks around but wont do harm) | 11:48 |
| * ogra_ notes it might be time for some breakfast | 11:48 | |
| ogra_ | :P | 11:48 |
| ogra_ | brb | 11:49 |
| ogra_ | bah, crap, forgot the meerting ... no food for me then | 11:50 |
| mvo | ogra_: highly untested, but http://people.canonical.com/~mvo/tmp/snappy will use /boot/uboot/uboot.env to set snappy_ab, snappy_mode and snappy_trial_boot | 11:54 |
| ogra_ | mvo, i assujme i replace /usr/bin/snappy with that ? | 11:56 |
| mvo | ogra_: yes | 11:58 |
| ogra_ | [FAILED] Failed to start Notify bootloader that boot was successful. | 11:58 |
| ogra_ | [FAILED] Failed to start Run snappy firstboot setup. | 11:58 |
| ogra_ | [FAILED] Failed to start Run snappy compatibility hooks. | 11:58 |
| mvo | ogra_: uh, thats the amd64 build | 11:58 |
| mvo | ogra_: I need to give you the arm build of course | 11:58 |
| ogra_ | lovely :P | 11:58 |
| ogra_ | at least we know it still boots to a prompt even with broken snappy binary :P | 11:58 |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb$ file snappy | 11:59 |
| ogra_ | snappy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=faa20b2d15c5c16533f51239a2a517f78db36dd6, not stripped | 11:59 |
| ogra_ | heh, yeah | 11:59 |
| mvo | ogra_: armhf version is upload | 12:02 |
| mvo | ogra_: armhf version is uploading | 12:02 |
| ogra_ | cool | 12:02 |
| mvo | ogra_: try http://people.canonical.com/~mvo/tmp/snappy_armhf | 12:03 |
| ogra_ | mvo, looks good, no failures this time | 12:07 |
| mvo | ogra_: cool, will a binary that can dump the env help? | 12:08 |
| mvo | ogra_: to verify that it works? | 12:08 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ cat /boot/uboot/snappy-system.txt | 12:08 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ | 12:08 |
| ogra_ | and it didnt write to the file :) | 12:08 |
| ogra_ | yeah, that might help | 12:08 |
| ogra_ | i guess to test the whole update/rollback stuff i need to build a -1 image | 12:09 |
| ogra_ | (and even then i'm not sure i can actually update) | 12:09 |
| mvo | ogra_: http://people.canonical.com/~mvo/tmp/uboot-env-armhf | 12:10 |
| mvo | ogra_: that uboot-env-armhf /boot/uboot/uboot.env print | 12:10 |
| mvo | ogra_: hopefully works | 12:10 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|wc -l | 12:13 |
| ogra_ | 70 | 12:13 |
| ogra_ | mvo, looks good | 12:13 |
| mvo | ogra_: does the content look ok too? i.e. snappy_boot_trial is cleared (if you set it already)? | 12:14 |
| ogra_ | not sure a regular user should be able to run this :) | 12:14 |
| mvo | ogra_: and try is set back to regular? | 12:14 |
| mvo | ogra_: heh :) | 12:14 |
| ogra_ | mvo, http://paste.ubuntu.com/11892475/ | 12:15 |
| mvo | ogra_: that looks good can you try "uboot-env-armhf /boot/uboot/uboot.env set snappy_mode=try", then reboot, then see if the boot sets it to "snappy_mode=regular" after the boot? | 12:17 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snapy_mode=try | 12:17 |
| ogra_ | panic: runtime error: index out of rang | 12:17 |
| mvo | ups, sorry | 12:17 |
| mvo | ogra_: that looks good can you try "uboot-env-armhf /boot/uboot/uboot.env set snappy_mode try" | 12:18 |
| mvo | has to be two args | 12:18 |
| ogra_ | doesnt work :( | 12:18 |
| mvo | same error? | 12:18 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snapy_mode try | 12:18 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode | 12:18 |
| ogra_ | snappy_mode=regular | 12:18 |
| ogra_ | no error ... | 12:18 |
| mvo | uh | 12:18 |
| ogra_ | oh | 12:18 |
| ogra_ | bah | 12:18 |
| * ogra_ tries without typo | 12:19 | |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snappy_mode try | 12:19 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode | 12:19 |
| ogra_ | snappy_mode=try | 12:19 |
| mvo | :) | 12:19 |
| ogra_ | works without PEBKAC | 12:19 |
| ogra_ | ;) | 12:19 |
| mvo | puhhh, I was scared for a minute | 12:19 |
| === tedg is now known as ted | ||
| === ted is now known as tedg | ||
| kyrofa | kgunn, another change we might want to consider making for Ubuntu Personal: Disable the automatic reboot | 13:30 |
| kyrofa | kgunn, just make the power button red or something | 13:31 |
| kgunn | kyrofa: sorry...automatic reboot ? | 13:34 |
| kyrofa | kgunn, yeah, Ubuntu Core seems to be configured to automatically update and reboot. Which makes a certain amount of sense for embedded devices | 13:34 |
| kyrofa | kgunn, but I'm not sure how much sense it makes for Ubuntu Personal (which still seems to be configured that way) | 13:35 |
| kgunn | seb128: ^ not sure who we'd talk to...i mean i guess this is based on our touch update technology, and it doesn't autoupdate/reboot afaik | 13:36 |
| seb128 | kgunn, kyrofa, does it really make more sense for an embedded device? depends what the device is doing | 13:38 |
| kyrofa | kgunn, yeah, heads up-- first few times you fire up the VM and try to ssh in only to see "snappy autopilot triggered a reboot to boot into an up to date system" or "Going down for a reboot" it catches you a bit by surprise :P | 13:38 |
| seb128 | if that's your car engine control you don't want it to reboot while you are driving :p | 13:38 |
| kyrofa | seb128, oh it certainly depends! | 13:38 |
| kyrofa | seb128, but I can see it making sense for a router or something. Keep it up-to-date and secure | 13:39 |
| kyrofa | seb128, if it was up to me, I'd definitely not make it the default on anything | 13:40 |
| kyrofa | seb128, but it seems to be that way on Ubuntu Core, at least for the time being | 13:40 |
| kyrofa | seb128, wait... maybe that's an edge thing? | 13:40 |
| seb128 | kyrofa, even a router, it might be on a critical infrastructure that should get package cut even for 10 secondes | 13:40 |
| seb128 | unsure | 13:40 |
| kyrofa | kgunn, seb128: This may be a non-issue if it's only on edge. sergiusens can answer for sure | 13:41 |
| kyrofa | seb128, agreed on the auto-updates. Tough to make that case | 13:43 |
| seb128 | yeah | 13:43 |
| seb128 | how can we turn it off? do you know? | 13:44 |
| sergiusens | kgunn: kyrofa seb128 I'd discuss the issue with the architecture team | 13:45 |
| sergiusens | snappy config ubuntu-core config_with_ap_disabled | 13:45 |
| seb128 | do we have a way to ship a different default config on the image? | 13:46 |
| seb128 | or a standard place in livecd-rootfs or such to call that | 13:46 |
| mterry | mvo, I know you're busy today, but if you have time, I have some snapcraft branches I'd love some action on | 13:48 |
| sergiusens | seb128: create your own gadget snap | 13:48 |
| sergiusens | seb128: and have u-d-f pull that in instead of generic-amd64 | 13:48 |
| seb128 | just for that? | 13:48 |
| seb128 | hum | 13:49 |
| seb128 | that sounds like more work that the change is worth | 13:49 |
| seb128 | kyrofa, kgunn ^ | 13:49 |
| kyrofa | seb128, hum indeed | 13:49 |
| sergiusens | gadget snaps are exactly for that, configs | 13:49 |
| kyrofa | seb128, depends on what's in generic-amd64 though. Might not be too bad | 13:50 |
| sergiusens | seb128: I bet you will diverge more (e.g.; seed in some preinstalled snaps) | 13:50 |
| kyrofa | seb128, yeah, we may need to do that eventually anyway | 13:50 |
| seb128 | sergiusens, that's probably true yeah | 13:50 |
| sergiusens | seb128: the gadget snap is like the custom tarball on the phone | 13:51 |
| sergiusens | except that it is declared and not just overlayed | 13:51 |
| seb128 | sergiusens, yeah, those are things I didn't look at so far and I've no clue about | 13:52 |
| seb128 | so I guess it's a good time to learn about them ;-) | 13:52 |
| sergiusens | seb128: don't look too deep though, ricmm is redefining it all | 13:52 |
| seb128 | k | 13:53 |
| sergiusens | seb128: some things may move back to the kernel snap (as we had it before) | 13:53 |
| tedg | mterry, So, did you have thoughts about editing the package.yaml in snapcraft? | 13:56 |
| tedg | mterry, It seems like something we're gonna need, and probably in a generic way. | 13:56 |
| mterry | tedg, how do you mean editing? | 13:58 |
| tedg | mterry, For instance having a plugin add a binary | 13:58 |
| tedg | mterry, But also adding the architecture | 13:59 |
| mterry | tedg, oh... I guess I imagined the user would explicitly add binaries and such they wanted -- it's hard to do automatically. There's caps and maybe calling the binary something different, etc | 14:00 |
| tedg | mterry, So Chipaca was thinking that the QML plugin would get the QML file, and then add a binary for it that was the execution of qmlscene. | 14:01 |
| tedg | mterry, I think that's a reasonable use case, and there'll probably be others. For instance if a plugin added tools. | 14:01 |
| rsalveti | ogra_: so to test if you get the fs corruption or not try image 3 from alpha | 14:01 |
| rsalveti | and update/rollback to image 5 | 14:02 |
| ogra_ | rsalveti, right, not completely done yet | 14:02 |
| ogra_ | wget http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap && sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 ... then dd it ... | 14:02 |
| ogra_ | that gets you a setup which doesnt use snappy-system.txt anymore ... but we still need to re-work snappy_boot to remove the fatwrite and need to integrate mvos snappy changes | 14:03 |
| rsalveti | did we land the snappy changes from mvo? | 14:03 |
| ogra_ | not yet | 14:03 |
| rsalveti | right | 14:03 |
| rsalveti | and udf changes as well | 14:03 |
| ogra_ | i only managed to do an initial test before he left ... we'll work on it more once he returns | 14:03 |
| ogra_ | udf changes arent needed | 14:04 |
| ogra_ | only cosmetic | 14:04 |
| rsalveti | but might be good to manually test it with the alpha release, to know if all the work we did will indeed not cause the fs corruption we had | 14:04 |
| ogra_ | (teh file will be created but not used by anything) | 14:04 |
| mterry | tedg, so for that use case, we'd want an assemble_fixes() step or something? | 14:04 |
| ogra_ | right, once we have all bits ready i'll test alpha | 14:04 |
| tedg | mterry, Yeah, or perhaps the "snap_file()" command would pass the current YAML as an object. | 14:05 |
| tedg | mterry, So then everyone would update it and it gets written out once. | 14:06 |
| mterry | tedg, well there's more they might want to edit, like the apparmor stuff maybe? But for sure the yaml object is 99% case | 14:06 |
| mterry | tedg, I don't think it semantically fits with snap_files(), but it is the same step | 14:07 |
| mterry | tedg, edit_package()? | 14:07 |
| mterry | tedg, we also might want to version our plugin interface, btw | 14:07 |
| tedg | mterry, Yeah, I guess I figured it was the "final step" or perhaps with assemble. | 14:09 |
| tedg | mterry, Sure, but let's wait until we have plugins that aren't in tree. | 14:09 |
| mterry | tedg, no, snap_files() is actually called on 'snap' step, not 'assemble' one | 14:10 |
| tedg | mterry, Yes, I was more suggesting where it might edit the packaging. | 14:10 |
| mterry | tedg, ah. Well so far we only copy the metadata into place during assemble. But maybe we should actually do that during snap... | 14:11 |
| mterry | tedg, maybe all the bits in assemble should really be in snap, so the user can muck with everything in its final position/state | 14:12 |
| mterry | tedg, then assemble is truly just a snappy build call | 14:12 |
| elopio | good morning. | 14:13 |
| * mterry waves at elopio | 14:14 | |
| nuclearbob | is there a bug somewhere about gpio/i2c support that I can follow? | 14:16 |
| tedg | mterry, Yeah, that makes sense to me. | 14:17 |
| elopio | nuclearbob: there is not. | 14:18 |
| elopio | nuclearbob: only a mailing list thread and the promise by ogra_ that he will let us know when it's ready. You can file one. | 14:19 |
| ogra_ | well, and it is a broader thin ... | 14:19 |
| ogra_ | *thing | 14:19 |
| nuclearbob | ogra_: if subscribing to the list is the best thing to do, I can do that | 14:19 |
| ogra_ | the bugs is "adding support for overlay devicetree files" ... | 14:19 |
| nuclearbob | elopio: thanks | 14:19 |
| nuclearbob | oh | 14:19 |
| nuclearbob | that does sound broader | 14:19 |
| ogra_ | it is ... and rather complex, since we look for a generic way and the boards function differently | 14:20 |
| elopio | on my beaglebone I saw the /dev/i2c-0 | 14:20 |
| elopio | I'll play with that :) | 14:20 |
| ogra_ | i will have overlay support in the next rpi image (via manual hacks) but not yet on the beaglebone | 14:20 |
| nuclearbob | okay, the rpi is what I'm looking for since I've got the orange matchbox | 14:22 |
| ogra_ | rsalveti, gah | 14:30 |
| ogra_ | so now i definitely know that fatwrite even messes up the uboot.env file | 14:31 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode | 14:31 |
| ogra_ | 2015/07/17 14:29:29 readUbootEnv failed for /boot/uboot/uboot.env: bad CRC: 4063564654 != 861698245 | 14:31 |
| * ogra_ forgot to take the fatwrite out before reboot | 14:31 | |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb$ ls /media/ogra/system-boot/a/ | 14:40 |
| ogra_ | DTBS HARDWA~1.YAM INITRD.IMG VMLINUZ | 14:40 |
| ogra_ | rsalveti, btw, that looks like the root cause of our corruption ^^^^ | 14:40 |
| ogra_ | 8+3 ... | 14:40 |
| ogra_ | (after fatwrite ) | 14:41 |
| rsalveti | ogra_: sorry, what is the root cause? | 14:48 |
| rsalveti | so fatwrite even when writing to a known file is already enough to cause the issue | 14:49 |
| ogra_ | rsalveti, seems the driver used by fatwrite doesnt support long filenames | 14:49 |
| rsalveti | it actually does | 14:49 |
| rsalveti | that's a consequence of fsck.vfat I believe | 14:49 |
| ogra_ | so the a and b directory content names get rewritten | 14:49 |
| ogra_ | oh, ok | 14:49 |
| rsalveti | that doesn't happen all the time | 14:49 |
| rsalveti | sometimes it stays fine, but fsck creates a FSCK0000.REC file | 14:50 |
| tedg | Chipaca, so getting those modules added means my snap is now 190 MB | 14:50 |
| ogra_ | lovely | 14:50 |
| ogra_ | should we perhaps kick it out ? | 14:50 |
| rsalveti | ogra_: so it looks like a combination of fatwrite + fsck | 14:50 |
| Chipaca | tedg: hah | 14:51 |
| Chipaca | tedg: I win, then | 14:51 |
| Chipaca | tedg: you're copying too much stuff | 14:51 |
| tedg | Chipaca, I have fonts ;-) | 14:51 |
| rsalveti | so basically we got back to the initial issue | 14:51 |
| rsalveti | and might need some fatwrite debugging | 14:51 |
| ogra_ | well, as expected ... | 14:51 |
| ogra_ | as i said, i forgot to take out the fatwrite stuff before rebooting | 14:52 |
| ogra_ | i just find it interesting that it even kills the blob if used like we did | 14:52 |
| ogra_ | (this wont happen once we're done) | 14:52 |
| Chipaca | tedg: 70MB of fonts? | 14:52 |
| tedg | Chipaca, You can never have too many emoji | 14:53 |
| sergiusens | Chipaca: tedg put it in a squash | 14:55 |
| Chipaca | tedg: 👹 | 14:55 |
| ogra_ | +1 | 14:55 |
| ogra_ | squash as squash can ! | 14:56 |
| Chipaca | also � with a � of � | 14:56 |
| * ogra_ wonders whyt kinds of fonts you all use ... i only get broken chars here | 14:56 | |
| sergiusens | ogra_: it's on purpose ;-) | 14:57 |
| Chipaca | ogra_: symbola + quivira cover most of the fun stuff | 14:57 |
| sergiusens | Chipaca: oh rly? | 14:57 |
| sergiusens | Chipaca: I thought this was a squashing pun :-P | 14:57 |
| Chipaca | fonts are already compressed, fwiw | 14:57 |
| Chipaca | ogra_: you just reminded me of my first 3d accelerator | 15:03 |
| Chipaca | ogra_: :) | 15:03 |
| ogra_ | haha ! | 15:03 |
| ogra_ | oh yeah, and the fun to get the dirver up | 15:03 |
| elopio | fgimenez: ugh, that 91 tests depends on the 90 test. Are you ok if I just remove both? | 15:33 |
| fgimenez | elopio, sure | 15:33 |
| elopio | 91 in this case will just do a fake update, which we already have. And the 15.04_to_rolling branch fully replaces 91. | 15:33 |
| fgimenez | elopio, yes, it's already covered | 15:35 |
| fgimenez | elopio, i'm preparing a branch with the changes to main.go and the template | 15:40 |
| elopio | fgimenez: not sure what you are talking about, but bring it on! | 15:41 |
| fgimenez | elopio, :) for removing the includeShell code, i'll push it shortly | 15:41 |
| elopio | fgimenez: I confirm that the RC test fails to reboot on latest rolling edge. | 15:41 |
| mvo | ogra_: is there anything I need to do? i.e. are you blocked on me currently? | 15:42 |
| fgimenez | elopio, yep i'll report it | 15:42 |
| elopio | fgimenez: oh, good. Thanks for mentioning it, I was about to do the same. I give you the honors :) | 15:42 |
| ogra_ | mvo, well, land your stuff ... nothing beyond that ... i'll try to get the script bits done before EOD today ... the rest on monday then | 15:42 |
| mvo | ogra_: ok | 15:43 |
| fgimenez | elopio, :) thanks, done | 15:46 |
| ogra_ | mvo, so when turning snappy_stamp into a boolean we should be fine i guess ? starting with snappy_stamp=0 ... having the boot script set it to 1 (instead of touching the file) ... who sets it back to 0 ? (whi was responsible for deleting it from disk ) | 15:48 |
| mvo | ogra_: yeah, its snappy_trial_boot=1 in grub, would be good to just mimick that | 15:49 |
| elopio | fgimenez: what do you think of moving all the tests to the tests directory? | 15:49 |
| mvo | ogra_: so grub itself sets snappy_trial_boot=1 i in its environment on boot and then the boot-script clears that value | 15:50 |
| elopio | if we have one single package, the filtering is easier. | 15:50 |
| ogra_ | mvo, for rolling for sure ... would we want to do that switch in 15.04 though ? | 15:50 |
| ogra_ | (reanming the var and all) | 15:50 |
| mvo | ogra_: hm, good question, my gut feeling is yes, its a bigger change but at least its the same code path as grub and 16.04. and it will be different in any case from the previous version so the more uniform the better I would say | 15:51 |
| fgimenez | elopio, mm at first we grouped them by the image they needed, hence the 'latest', 'update' packages, which translate to different binaries, i'm not sure if it's applicable yet? | 15:51 |
| ogra_ | mvo, ok | 15:52 |
| sergiusens | mvo: ogra_ just convert the 0-1 into a counter | 15:52 |
| elopio | fgimenez: oh, right. You'll have to read the 15.04_to_rolling first for this to make sense. | 15:52 |
| ogra_ | sergiusens, err | 15:52 |
| elopio | we'll talk about it on monday. | 15:52 |
| sergiusens | or is math not doeable in u-boot? | 15:52 |
| fgimenez | elopio, ah ok | 15:52 |
| ogra_ | it is but that makes everything more complex | 15:52 |
| sergiusens | ogra_: yeah, but we get counter failover which makes mvo happy ;-) | 15:53 |
| ogra_ | if test $snappy_stamp = 1; then ... | 15:53 |
| sergiusens | not for 15.04 though | 15:53 |
| ogra_ | thats pretty trivial to add | 15:53 |
| mvo | sergiusens, Chipaca: if one of you could review https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 - that would be very cool, that would unblock ogra_ | 15:53 |
| * Chipaca looks | 15:53 | |
| sergiusens | mvo: not enough cleanup | 15:54 |
| sergiusens | :-P | 15:54 |
| mvo | sergiusens: followup branch ;) | 15:54 |
| * sergiusens jokes | 15:54 | |
| sergiusens | mvo: oh, lol | 15:54 |
| mvo | sergiusens: but totally agreed, there is so much more we can do now | 15:55 |
| ogra_ | dont ask me about go ... looks fine to me but that means nothing :P | 15:55 |
| elopio | fgimenez: if you just leave a return at the end of a function, it will find the values it has to return? | 15:55 |
| fgimenez | elopio, if they are named in the signature yes | 15:55 |
| elopio | that is impressive. | 15:56 |
| mvo | it does, but some people dislike this style | 15:56 |
| fgimenez | elopio, coming from other languages a find it wonderful, yep :) anyway in this case it comes from the gocheck api, not sure if we have another options here | 15:57 |
| Chipaca | elopio: also confusing, so don't do it* :) | 15:58 |
| mvo | ogra_: I get some quick dinner, let me know if you need anything I will get to it when I return | 15:58 |
| Chipaca | * unless you have good reason to ;) | 15:58 |
| * elopio wants to approve this so much... | 15:58 | |
| ogra_ | mvo, yeah, i dont think so ... will need to fiddle with the snappy_boot cmd now | 15:58 |
| ogra_ | (and i need some food myself) | 15:58 |
| sergiusens | mvo: added questions | 15:58 |
| elopio | fgimenez: I'll leave you the +1, you do the top approve when you update the return. | 15:58 |
| Chipaca | mvo: lgtm, but sergio beat me to it :) | 16:00 |
| sergiusens | mvo: elopio fgimenez boilerplate returns are ok if the function is small; but you shouldn't name vars if it only adds cruft and no meaning (e.g.; name these (string, string, string, error) but maybe not these (string, error)) | 16:00 |
| elopio | sergiusens: so better to keep the signature short than to use a bare return, that makes sense. | 16:02 |
| sergiusens | elopio: go vet catches most of these btw | 16:03 |
| fgimenez | sergiusens, ok, thanks, for implementing a custom checker here https://code.launchpad.net/~fgimenez/snappy/test-writable-paths/+merge/265110 i've seen this http://godoc.org/gopkg.in/check.v1#Checker, perhaps the interface can be satisfied without naming the return values? | 16:04 |
| elopio | sergiusens: it seemed happy with the bare return version. | 16:04 |
| sergiusens | elopio: fgimenez https://golang.org/doc/effective_go.html#named-results | 16:04 |
| sergiusens | fgimenez: you don't need to name the return vals to satisfy an interface iirc | 16:05 |
| sergiusens | fgimenez: elopio in any case, if it makes the code simpler and faster to read, it's a +1 to whatever ;-) | 16:05 |
| fgimenez | sergiusens, or just "return result, error" as elopio mentioned? having them already defined seems to be handy | 16:05 |
| kgunn | hey so, on a rolling core image, i do snappy search mir, i see it...then sudo snappy install mir fails to install "snappy package not found" | 16:06 |
| elopio | sergiusens: yes, that link basically says the opposite of what you said :) | 16:06 |
| kgunn | what's up with that ^ ? | 16:06 |
| elopio | kgunn: do you have the ens3 iface up? | 16:07 |
| kgunn | yes | 16:07 |
| kgunn | without it, i couldn't see results in search | 16:07 |
| elopio | let me kill my instance and try. | 16:07 |
| sergiusens | kgunn: didn't we have this conversation already? :-P | 16:07 |
| elopio | it might need to add the origin. | 16:07 |
| sergiusens | kgunn: there is no 'mir' package https://search.apps.ubuntu.com/api/v1/package/mir | 16:08 |
| elopio | or that :) | 16:08 |
| sergiusens | kgunn: https://search.apps.ubuntu.com/api/v1/search?q=mir does say there isa mir.mvp-demo with no alias | 16:08 |
| sergiusens | which is not ok for a framework | 16:09 |
| sergiusens | kgunn: I'd ask the store guys | 16:09 |
| elopio | sergiusens: how do you add an alias ? | 16:09 |
| * sergiusens pokes at nessita and beuno | 16:09 | |
| kgunn | all news to me | 16:09 |
| sergiusens | elopio: by being a store admin | 16:09 |
| elopio | https://bugs.launchpad.net/snappy/+bug/1474658 | 16:09 |
| ubottu | Launchpad bug 1474658 in Snappy "Can't install hello-dbus-fwk: snappy package not found" [Undecided,Confirmed] | 16:09 |
| kgunn | all i know is search returns "mir" and you can't install it | 16:09 |
| elopio | kgunn: sergiusens: so it's the same bug ^ | 16:09 |
| sergiusens | elopio: so someone must of fiddled with the store database :-/ | 16:10 |
| elopio | either the search should return the origin, or it should be installed without an origin. | 16:10 |
| sergiusens | elopio: yeah, https://search.apps.ubuntu.com/api/v1/search?q=hello-dbus-fwk no alias there | 16:10 |
| sergiusens | elopio: no, frameworks without origin aren't allowed | 16:10 |
| sergiusens | elopio: so the proper client solution is to not show them in the search results until they have an alias | 16:11 |
| elopio | sergiusens: I mean that snappy install could append the origin to the name you pass. Just a suggestion, not saying it's good. | 16:11 |
| elopio | sergiusens: ok, I like that too. | 16:11 |
| elopio | fgimenez: so, I'd say "return result, error", because Chipaca finds it confusing. I was confused too when I read it. Handy, but maybe too fancy. | 16:13 |
| * Chipaca is the receptacle of the truth, and as such, if he finds something confusing it is only because it *is* confusing | 16:14 | |
| elopio | no need to state the obvious :) | 16:14 |
| elopio | sergiusens: can you give the the credentials for the snappy-tarmac user? | 16:14 |
| kgunn | bbiab | 16:15 |
| sergiusens | elopio: let me add your ssh keys | 16:16 |
| fgimenez | elopio, ok done, much clearer now :) | 16:17 |
| fgimenez | nice weekend everyone o/ | 16:18 |
| sergiusens | elopio: extending https://tour.golang.org/basics/7 | 16:38 |
| elopio | beuno: ev: is this something you will be supporting? https://launchpad.net/snappy-proposed-image-builder | 17:05 |
| ev | elopio: no, that's legacy | 17:06 |
| ev | elopio: CI works in images; it does not handle creating them. A service can be created for composing an image given some snaps, but the CI architecture won't know about its internals | 17:07 |
| elopio | ev: ack. utlemming: what can we do to start a canonistack machine with the latest rolling edge? | 17:08 |
| utlemming | elopio: rolling edge will be created sometime automatically and then published to Canonistack. One the build appears, you would launch it like you would any other Openstack instance | 17:10 |
| elopio | utlemming: good. Is there an easy way to know the name of the latest image? Or do we have to grep for ubuntu-core and sort the date? | 17:11 |
| ogra_ | mvo, ok, http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snapshould now have workign logic ... it uses snappy_trial_boot as boolean (0/1) instead of the snappy-stamp.txt file ... | 17:23 |
| mvo | ogra_: neat! where is the source for that? I would love to have a look | 17:24 |
| ogra_ | mvo, http://paste.ubuntu.com/11893726/ ... thats the input file used for uboot.env | 17:25 |
| ogra_ | http://paste.ubuntu.com/11893737/ has the steps i used | 17:27 |
| ogra_ | (beyond re-packing the .snap) | 17:28 |
| mvo | ogra_: neat! | 17:30 |
| mvo | sergiusens: thanks for your excellent feedback, I'm fixing now | 17:30 |
| ogra_ | with that we're ready for end to end testing on monday i think | 17:30 |
| sergiusens | mvo: no worries, it only popped into my mind in retrospect of the grub work | 17:31 |
| sergiusens | to avoid writing as much as possible :-) | 17:31 |
| mvo | sergiusens: :) | 17:31 |
| nessita | sergiusens, needing an alias? | 17:46 |
| tedg | Uhg, I'm missing a variable somewhere. | 17:47 |
| tedg | Chipaca, Did you ever get "qmlscene: could not find a Qt installation of ''" | 17:48 |
| beuno | '' has been known to be hard to find | 17:48 |
| tedg | I tried dividing by zero, but that didn't help. | 17:49 |
| ogra_ | hmm, telegram is dead on both of my phones | 17:52 |
| tedg | ogra_, Thumbnailer issue, apparently they dropped the C++ lib | 17:57 |
| ogra_ | uuuh | 17:57 |
| ogra_ | oh, yeah http://people.canonical.com/~ogra/touch-image-stats/vivid/20150717.changes | 17:57 |
| * ogra_ notes libsnappy1 in there :D | 17:58 | |
| ogra_ | secretly sneaking into the phone :) | 17:58 |
| kenvandine | plotting to take over the world | 18:00 |
| ogra_ | :D | 18:03 |
| nessita | sergiusens, elopio, the store will not se any alias automatically, so if you need specific packages with alias, you should email Martin and me for us to set manually | 18:13 |
| sergiusens | nessita: beuno it's aliases that WERE there and AREN'T anymore ;-) | 18:14 |
| nessita | sergiusens, yeah? I would say "impossible", but tell me more :-) | 18:17 |
| nessita | sergiusens, I personally never ever set an alias for mir | 18:17 |
| sergiusens | nessita: at least hello-dbus-fwk had an alias | 18:17 |
| nessita | perhaps beuno did, but lately he ask me to set alias | 18:17 |
| beuno | I sometimes in my sleep change things to mess up sergiusens, yes | 18:18 |
| sergiusens | nessita not sure about mir, all I know is that I told the people asking about it that it needs an alias | 18:18 |
| sergiusens | beuno: lol | 18:18 |
| nessita | sergiusens, what alias had hello-dbus-fwk set? | 18:18 |
| sergiusens | nessita: aliased to hello-dbus-fwk | 18:19 |
| nessita | sergiusens, and who setthe alias? (I didn't) | 18:19 |
| sergiusens | nessita: I thought 'alias' is a gimmick, we always want it to be 'package_name' | 18:19 |
| sergiusens | nessita: I have no idea! It worked, now it doesn't | 18:19 |
| sergiusens | that's all I know | 18:19 |
| sergiusens | nessita: and elopio reported a bug, I just saw it had no alias | 18:20 |
| sergiusens | nessita: maybe we can just set it for hello-dbus-fwk and drink some scotch to forget this ever happened :-P | 18:20 |
| nessita | sergiusens, so the only alias we have set are: generic-i386, generic-amd64 | 18:20 |
| sergiusens | nessita: what about webdm? | 18:21 |
| nessita | sergiusens, we could do that, but I would like to know that the alias setting process is understood | 18:21 |
| sergiusens | nessita: that did have an alias and made the arrangements to set it | 18:21 |
| sergiusens | heh, yeah, webdm does have an alias | 18:21 |
| * sergiusens wipes the sweat off his forehead | 18:22 | |
| nessita | as a summary: alias is set by hand by either beuno or matiasb or me, and we don't remove it unless explicitely asked for, and there is no automatic process to set one | 18:23 |
| sergiusens | nessita: wrt the process, beuno promised me that oem and framework snaps would get auto aliased when getting approved into the store (he didn't say when though) | 18:23 |
| beuno | sergiusens, FWIW, we're working on allowing al reviewers to set aliases | 18:23 |
| beuno | like yourself | 18:23 |
| sergiusens | beuno: great | 18:23 |
| beuno | which we'll follow at some point with some automation | 18:23 |
| beuno | but at least expand the group who can set it significantly | 18:23 |
| sergiusens | beuno: great, because fwk and oem can't be forked | 18:24 |
| mvo | Chipaca: libxkbcommon is uploaded to wily, I clone the repo for a pull-request now, lets see what upstream says | 18:25 |
| sergiusens | nessita: in any case, I didn't ask for hello-dbus-fwk to be aliased, did not approve it into the store nor did I push it; I only noticed it is a framework and it is missing an alias :-) | 18:25 |
| * sergiusens checks to see who approved hello-dbus-fwk and mir | 18:27 | |
| sergiusens | jdstrand: I see you approved hello-dbus-fwk into the store, did you ask any of the store guys to create an alias for it? | 18:29 |
| sergiusens | jdstrand: ditto for mir. Bringing it up as they need to be aliased and it's not automatic | 18:29 |
| jdstrand | sergiusens: I did not | 18:30 |
| jdstrand | sergiusens: on either | 18:30 |
| jdstrand | oh, I didn't realize that | 18:30 |
| jdstrand | so, we must request that all new frameworks must have an alias? | 18:30 |
| sergiusens | jdstrand: yes, it's all related to them not being able to have forks | 18:31 |
| jdstrand | shouldn't the store just do that for us automatically? | 18:31 |
| sergiusens | jdstrand: they have a task open (mentioned ^^) | 18:31 |
| jdstrand | ok | 18:31 |
| jdstrand | and yes, I understnad that frameworks can't have forks-- I just didn't realize we had to do the manual request | 18:32 |
| jdstrand | but glad to hear that is being addressed too | 18:32 |
| mvo | Chipaca: just fyi https://github.com/xkbcommon/libxkbcommon/pull/25 | 19:06 |
| tedg | jdstrand, I want to give my app access to /run/mir_socket, I don't see a cap for that, so do I just need to override for now? | 19:34 |
| carif_ | just confirming: if I were to install Ubuntu Core, I would get the same bits as Snappy Ubuntu core, but I'm using the debian packaging system, not snappy | 19:44 |
| carif_ | also, the file layout will be somewhat different because snappy operates a little differently. So I have /apps/**, I can have multiple versions installed, one of them being current and I can revert back to some prior version if I so choose | 19:45 |
| carif_ | the phone is somewhat different in that I run images on a device, say a nexus 4/7/10 and I use adb to push the images to the device and then ubuntu-device-flash to update it | 19:47 |
| tedg | The phone and snappy are both image based, and ubuntu-core is basically the same, there are minor differences in the packages installed. | 19:48 |
| jdstrand | tedg: there should be a mir_client policy group provided by the mir framework | 19:48 |
| jdstrand | tedg: depend on the mir framework, then use mir_client | 19:48 |
| tedg | Ah, it's in /var | 19:49 |
| tedg | jdstrand, Thanks :-) | 19:49 |
| jdstrand | np | 19:49 |
| carif_ | those packages are called "clicks" but clicks have been renamed to "snaps" | 19:49 |
| carif_ | tedg, ^^^ tar baby | 19:49 |
| jdstrand | tedg: fyi, 'snappy-security list -V ubuntu-core' will show you what policy is available currently on the system | 19:50 |
| carif_ | will the phone eventually install its apps in /apps? etc? | 19:50 |
| tedg | jdstrand, Oh, that's good to know. I just used "find" :-) | 19:51 |
| jdstrand | find will work too :) | 19:51 |
| tedg | carif_, Yes, in time phone applications will be snaps and the phone will be based on Snappy. | 19:51 |
| carif_ | tedg, ty | 19:51 |
| tedg | jdstrand, Not if you start it in /usr … | 19:52 |
| jdstrand | hehe, no | 19:53 |
| carif_ | tedg, when that transition happens will the phone utilities like ubuntu-device-flash be deprecated? So I will (say) snapp-remote a snap onto the phone? | 19:55 |
| * carif_ isn't sure he's asking the question correctly | 19:56 | |
| tedg | carif_, No you can still use u-d-f to flash a phone from a raw state. But like it upgrades itself today, the snappy version will do the same. | 19:56 |
| tedg | carif_, You could use snappy remote to upgrade/install a snap as well if you wanted. More an additional feature. | 19:56 |
| carif_ | vg, last question, in addition to finding snaps at the Ubuntu store, can I have my snappy device (kvm, etc) look for snaps on a local website? rather than using snap-remote to push a snap, I've like to do 'snappy install mikey' and have it find the snap on some local website | 20:00 |
| carif_ | tedg, ^^^ ... then I'll let you get back to work | 20:00 |
| tedg | carif_, We're not going to support that out of the box, we want to do a lot with the store that isn't just "download a file" to make the updates smarter and faster. It's open source, and your device, and all that, but we'd really like people to put things in the store. | 20:02 |
| tedg | Clearly you could write a shell script to do it if you wanted pretty easily. | 20:03 |
| carif_ | tedg, thanks dude | 20:03 |
| tedg | There's also a ton of work going into the store so that you can have private stores and things like that. | 20:03 |
| === yofel_ is now known as yofel | ||
| tedg | kgunn, I have Mir snap1, but I don't think that has the seccomp with the socketpair() in it, is there a more up-to-date snap? | 20:21 |
| kgunn | tedg: i'm just now uploading actually | 20:24 |
| rsalveti | tedg: mind giving a hand with some reviews? https://code.launchpad.net/~snappy-dev/snapcraft/core/+activereviews is quite a big list | 20:24 |
| kgunn | tedg: but, yes y;day (i think) i took that change in from jamie | 20:25 |
| tedg | kgunn, Upload faster! ;-) | 20:25 |
| tedg | rsalveti, Sure, I'll give them a try. Still feel a bit like the student though :-) | 20:26 |
| kgunn | tedg: actually...i just cancelled, gonna pull fresh and rebuild to make darn sure it's the right one | 20:26 |
| rsalveti | tedg: :-) | 20:26 |
| kgunn | rsalveti: so who is Mr. snappy store ? | 21:10 |
| rsalveti | beuno: ^ | 21:10 |
| rsalveti | he's the store itself | 21:10 |
| kgunn | lol | 21:10 |
| beuno | I cp software into people's phone on demand | 21:11 |
| kgunn | so i've got a new mir snap....and i altered the version to be "1.1" from "snap1"...so dropping the "snap" | 21:11 |
| kgunn | and it no likie | 21:11 |
| tedg | Because we love beuno we wrote snappy-remote to make his life easier. | 21:11 |
| beuno | kgunn, it uses debian rules for versioning (for now) | 21:11 |
| tedg | No more hand copying | 21:11 |
| kgunn | ug, so i have to live with snap in the version string? | 21:12 |
| beuno | you just want me out of a job | 21:12 |
| beuno | kgunn, not really, you just need to make it newer from a debian versioning POV | 21:12 |
| beuno | not sure what a character to integer path is | 21:12 |
| beuno | kgunn, that will change in the next month or two | 21:14 |
| kgunn | k, for now will just live with "snap" there.... | 21:14 |
| beuno | you'll be able to throw whatever you want as a version, and it'll do updates based on internal revision numbers | 21:15 |
| beuno | but not yet, because phones use that to figure out if it's newer or not | 21:15 |
| carif_ | how long does it take for ubuntu-device-flash to update a device? And do I need need to "approve" the update on the device itself or is it just an adp think on my laptop? | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!