| rsalveti | sergiusens: elopio: failed to me even when not empty, this bug sucks | 00:04 |
|---|---|---|
| rsalveti | we need a smarter workaround | 00:04 |
| sergiusens | rsalveti: what failed? snappy-stamp? | 00:09 |
| rsalveti | sergiusens: the fat partition got corrupted even when the stamp is not 0 | 00:10 |
| rsalveti | so we need to go with ogra_'s solution | 00:10 |
| rsalveti | to use env + kernel cmdline | 00:10 |
| rsalveti | and do that under the initrd | 00:11 |
| sergiusens | rsalveti: I guess we can have some logic in lp:snappy to carry this change | 00:11 |
| rsalveti | right | 00:11 |
| sergiusens | rsalveti: I was just coming in to propose and do something like that for the fatwrite thing | 00:12 |
| sergiusens | rsalveti: I don't understand ogra's solution though; instead of a stamp file the env would be stored on disk? is that it? | 00:12 |
| sergiusens | rsalveti: env being snappy_ab, snappy_mode and snappy-stamp's replacement ? | 00:13 |
| rsalveti | trying to remember the details | 00:13 |
| rsalveti | but we can try something different as long we're not writing from the bootloader | 00:14 |
| rsalveti | we can read from the bootloader | 00:14 |
| rsalveti | and pass over arguments via kernel cmdline, for example | 00:14 |
| rsalveti | need to get off for dinner, try to propose something, otherwise we can talk tomorrow | 00:15 |
| sergiusens | rsalveti: well we need to write from the bootloader when something fails at that level | 00:15 |
| rsalveti | can't you just invert the logic? | 00:15 |
| rsalveti | if the file is not there, it means the previous boot didn't work | 00:16 |
| rsalveti | bbl | 00:17 |
| sergiusens | rsalveti: I guess, and that is a much simpler fix | 00:17 |
| sergiusens | rsalveti: but we can't reverse the logic at this stage | 00:17 |
| === rcj` is now known as rcj | ||
| fgimenez | good morning | 07:09 |
| dholbach | good morning | 07:13 |
| === erkules_ is now known as erkules | ||
| JamesTait | Good morning all; happy Gummi Worm Day! 😃 | 08:33 |
| === greyback__ is now known as greyback | ||
| Chipaca | JamesTait: i'm starting to suspect your days calendar is subsidised in part by haribo | 09:53 |
| JamesTait | Chipaca, now there's an idea! | 10:18 |
| Chipaca | JamesTait: you could save *dozens* on your kids' uni tuition! | 10:19 |
| ogra_ | lool, *tickle* | 10:19 |
| JamesTait | Chipaca, who said anything about the kids? | 10:20 |
| Chipaca | JamesTait: I did. Just now. Pay attention! | 10:27 |
| JamesTait | Yes, sire. Sorry, sir. | 10:27 |
| lool | ogra_: hey | 10:38 |
| ogra_ | lool, did your patches for uboot ever make it upstream ? | 10:38 |
| lool | ogra_: sorry was away yesterday, I see you were discussing some u-boot stuff with ricardo s | 10:38 |
| ogra_ | yeah | 10:38 |
| lool | no idea, checking | 10:38 |
| lool | it was a one line patch to the config | 10:38 |
| ogra_ | seems fatwrite is constantly corrupting the vfat ... we are looking of the newer uboot from the wily archive could perhaps help | 10:39 |
| ogra_ | *if the | 10:39 |
| lool | ogra_: oh wow, that sucks | 10:39 |
| ogra_ | (and in general we'd like to base off an archive package) | 10:39 |
| lool | I dont care about basing on archive TBH | 10:40 |
| ogra_ | well, you got everything in one central place there | 10:40 |
| lool | ogra_: I dont see my patch merged upstream, but it seems to me the config includes were reworked in a way that enables this particular config | 10:41 |
| lool | ogra_: we dont want to be the central place for firmware IMO | 10:42 |
| ogra_ | was it really just config ? i thought you needed some extra stuff for raw initrd | 10:42 |
| lool | ogra_: no, just a config | 10:42 |
| lool | ogra_: http://people.canonical.com/~lool/snappy-bbb/0001-Enable-SUPPORT_RAW_INITRD-to-load-initrd.img.patch | 10:42 |
| ogra_ | we want to be able to maintain the firmware for our supported imaes | 10:42 |
| ogra_ | and having that centralized makes it easier | 10:42 |
| lool | nowadays, include/configs/am335x_evm.h includes include/configs/ti_am335x_common.h which includes include/configs/ti_armv7_common.h which defines CONFIG_SUPPORT_RAW_INITRD | 10:43 |
| lool | ogra_: I dont think we want to maintain that firmware; also it's ok if we build it once and stop worrying about it | 10:44 |
| ogra_ | ah, cool. that was the thing i needed to knwo | 10:44 |
| lool | I know this sounds extreme and contrary to our usual standards | 10:44 |
| lool | but it's just make work where we have no value | 10:44 |
| ogra_ | well, we ship that firmware and we *wnat* to control it ... at least til we know it isnt bugy anymore | 10:44 |
| * ogra_ needs new kbd (or new fingers) | 10:45 | |
| ogra_ | for now we only want fatwrite to work or find an alternative though :) | 10:45 |
| ogra_ | my idea was to ship a uboot.env by default that carries the values, but that needs some hackery if we want to change them from userspace after boot | 10:47 |
| lool | ogra_: do you have a recipe to trigger the fatwrite issue? | 10:47 |
| ogra_ | lool, doing multiple rollback and update actions on a BBB 15.04 alpha image | 10:48 |
| ogra_ | the prob is also that the BBB can fall back to the internal uboot ... which has fatwrite enabled but is 8 months older than what we ship | 10:48 |
| lool | ogra_: FYI, upstream commit we care about is: | 10:49 |
| ogra_ | so might even have other bugs | 10:49 |
| lool | commit 6440b807399c81c3670f7c9805c917308cfdd5d3 | 10:49 |
| lool | Author: Guillaume GARDET <guillaume.gardet@free.fr> | 10:49 |
| lool | Date: Mon Nov 3 14:26:17 2014 +0100 | 10:49 |
| lool | ARM: TI: Enable raw initrd support | 10:49 |
| lool | (my patch was produced later but on top of the previous u-boot release | 10:49 |
| ogra_ | right | 10:49 |
| lool | ogra_: what's the symptom of the fatwrite issue? | 10:50 |
| ogra_ | corrupt files on the vfat ... kernel or dtb usually | 10:51 |
| sergiusens | morning | 10:51 |
| ogra_ | bug 1474126 is one of the current bugs with it | 10:51 |
| ubottu | bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed] https://launchpad.net/bugs/1474126 | 10:51 |
| ogra_ | rsalveti confirmed that he never gets the issue when removing fatwrite from the process and hacking the a/b stuff manually instead | 10:52 |
| rsalveti | morning | 10:52 |
| rsalveti | ogra_: latest uboot doesn't help | 10:53 |
| ogra_ | ah, i feared that | 10:53 |
| ogra_ | i didnt see anything about it in the backlog | 10:53 |
| lool | so we've likely found an u-boot bug, or we have a misconception | 10:53 |
| lool | how do we deal with it? | 10:54 |
| ogra_ | i think fatwrite is used so rarely that it still has many bugs | 10:54 |
| sergiusens | lool: that is what is under discussion | 10:54 |
| sergiusens | dealing with it | 10:54 |
| rsalveti | ideally I'd like to not use fatwrite | 10:54 |
| ogra_ | lool, as i said, one option would be a uboot.env by default | 10:54 |
| lool | I wonder whether it's by virtue of u-boot touching the MMC at all; that is, the abstraction of the MMC controller doing the writes might just result in corruption (dependent on the SD card brand) and then we need to go back to the drawing board | 10:54 |
| rsalveti | either invert the logic or get to another solution | 10:54 |
| ogra_ | but snappy needs to be able to disassemble and change it | 10:54 |
| sergiusens | last night rsalveti proposed inverting the logic (file not there for u-boot and file created by snappy) | 10:55 |
| sergiusens | but that isn't backwards compatible | 10:55 |
| lool | u-boot needs to be able to write some flag | 10:55 |
| rsalveti | sergiusens: I don't think we can do any solution that is backwards compatible | 10:55 |
| ogra_ | and wont work for a/b | 10:55 |
| lool | otherwise you have no u-boot retries | 10:55 |
| ogra_ | right | 10:55 |
| rsalveti | because we can't change the file that does the fatwrite | 10:55 |
| lool | we can drop the u-boot retries if that's more pain than use | 10:55 |
| * ogra_ still thinks we should just use a uboot env var | 10:56 | |
| rsalveti | what I thought was inverting the logic and giving the u-boot var via kernel cmdline | 10:56 |
| rsalveti | and touch the file from the initrd | 10:56 |
| rsalveti | fatread is fine, fatwrite is the problem | 10:56 |
| lool | rsalveti: this is not enough | 10:57 |
| lool | rsalveti: I mean, it's less than today | 10:57 |
| rsalveti | why? | 10:57 |
| rsalveti | we only check for the file to know if the boot succeeded or not | 10:58 |
| lool | how do you record that you've attempted the boot? | 10:58 |
| lool | kernel panics, board reboots, you're back to the same bootloader logic, how do you avoid the boot loop? | 10:58 |
| rsalveti | can't use save via env var in uboot? | 10:58 |
| lool | there is no flash on BBB | 10:59 |
| lool | so it's either over FAT, or we create a new u-boot environment partition on the emmc | 10:59 |
| lool | we can even have redundant environment! :-) | 10:59 |
| lool | but that diverges quite a lot from upstream u-boot | 10:59 |
| rsalveti | yeah | 10:59 |
| lool | or we debug fatwrite / emmc issue and we find the issue | 10:59 |
| rsalveti | the only thing I don't like about that is that we'd be enforcing a newer u-boot (or patch) for everyone | 11:00 |
| ogra_ | gah, what was that | 11:01 |
| ogra_ | the stamp file can actually be touched from initrd, but the snappy_ab var needs to be dynamic and to be set before uboot tries to boot anything | 11:01 |
| ogra_ | so the kernel commandline doesnt buy you much | 11:01 |
| * ogra_ goes to find lunch | 11:07 | |
| sergiusens | ogra_: lool rsalveti to be fair, we don't have this stamping logic for grub based systems | 11:10 |
| sergiusens | iirc | 11:10 |
| rsalveti | sergiusens: what do we do there? | 11:10 |
| lool | sergiusens: we dont? | 11:10 |
| sergiusens | rsalveti: I'm not sure, wasn't involved (I think nothing), mvo do you know? | 11:10 |
| lool | I thought we were writing to the grub environment and setting a/b from there | 11:11 |
| lool | but never saw it | 11:11 |
| sergiusens | lool: yes, a/b we set, but we have nothing similar to the stamp file | 11:11 |
| rsalveti | we need a way to know that we should not continue trying to boot one specific kernel | 11:12 |
| sergiusens | lool: rsalveti ah, snappy_trial_boot | 11:12 |
| sergiusens | grubenv | 11:12 |
| lool | the general problem is as follows: we want to demonstrate product-grade reliability across updates including kernel breakage, that relies on the bootloader being at least able to tell whether it's trying again or not; we're demo-ing on BBB | 11:12 |
| lool | I see two ways out of this | 11:12 |
| sergiusens | path uboot | 11:12 |
| sergiusens | patch* | 11:12 |
| lool | either we find another path to track the "retry"; for instance, we could use memory, but that's fragile | 11:12 |
| lool | (e.g. trigger the reboot with some concept, much like "reboot to recovery" on android) | 11:12 |
| lool | or we deliver a firmware which does what we want | 11:13 |
| lool | and we drop the "upstream firmware" artificial constraint | 11:13 |
| ogra_ | well, we only need to move the backend off the vfat | 11:13 |
| lool | which is just a constraint we're imposing on ourselves to be good citizens | 11:13 |
| ogra_ | i.e. into a uboot var | 11:13 |
| lool | ogra_: that's fine with me, but then we need to use a patched bootloader to do this | 11:14 |
| ogra_ | why is that ? | 11:14 |
| lool | sergiusens: so GRUB does implement the logic? good to know | 11:14 |
| ogra_ | i thought uboot can generally use env blobs | 11:14 |
| lool | ogra_: hmm, perhaps it does support a raw environment at a fixed SD card offset, that might be a solution | 11:15 |
| lool | another solution of this kind to consider is to ditch u-boot in favor of edk2 | 11:15 |
| ogra_ | lool, well, more a blob file | 11:15 |
| rsalveti | I think it supports that | 11:15 |
| ogra_ | lool, like on the rpi | 11:15 |
| rsalveti | ogra_: a blob file in a fs or in an offset? | 11:15 |
| lool | ogra_: a blob file might be more reliable, but not sure | 11:15 |
| ogra_ | it doesnt have any requirements on the partitioning | 11:16 |
| lool | I guess u-boot *might* be clever enough to overwrite the same blocks when updating the env file | 11:16 |
| lool | but this might also be equally unreliable | 11:16 |
| ogra_ | you can use saveenv in the uboot script | 11:16 |
| ogra_ | it will properly update | 11:16 |
| rsalveti | but where would we save the blob? | 11:16 |
| lool | ogra_: the question is whether it's any reliable | 11:16 |
| ogra_ | in uboot.env o the vfat | 11:16 |
| ogra_ | *on | 11:16 |
| lool | if it's replacing an unreliable solution with another unreliable one, it's not a good deal IMO | 11:16 |
| rsalveti | right, but not sure if that is reliable | 11:16 |
| rsalveti | still writing in the fat partition | 11:17 |
| ogra_ | i thinnk it is as reliable as the uboot env is in general | 11:17 |
| ogra_ | as long as we can safely load that blob file we are fine | 11:17 |
| lool | rsalveti: perhaps we can just add a sync/flush in the u-boot logic to shrink the window where the fs is getting corrupted? | 11:17 |
| rsalveti | I don't think it's a sync problem | 11:18 |
| rsalveti | but we can try | 11:18 |
| lool | rsalveti: you sync ;-) it's an actual bug in the fat logic? | 11:18 |
| lool | that would be worth fixing in any case | 11:18 |
| * lool notes that everyone focuses on u-boot since I agitated the edk2 broom | 11:19 | |
| rsalveti | yeah, just that this is holding our stable release | 11:19 |
| * ogra_ already proposed to switch arm to grub yesterday | 11:19 | |
| rsalveti | but, we're not going to be able to update the bootloader anyway | 11:19 |
| ogra_ | :P | 11:19 |
| rsalveti | so I believe we just release the stable image and try to fix the uboot issue | 11:19 |
| rsalveti | lool: what do you think? | 11:20 |
| * ogra_ wonders if thats not actually to serious to release with it | 11:20 | |
| lool | rsalveti: I think it's a fine way forward given the other things we need to think about | 11:20 |
| lool | is this only hitting BBB/omap platforms? | 11:21 |
| lool | I wonder whether it would affect the pi2 | 11:21 |
| ogra_ | lool, we dont support upgrades/rollbacks on any others | 11:21 |
| lool | right | 11:21 |
| ogra_ | so no way to test | 11:21 |
| lool | I personally like to think we will move to UEFI and replace this with the GRUB logic entirely | 11:21 |
| ogra_ | even on armhf ? | 11:21 |
| ogra_ | (who would be doing that grub port? ) | 11:22 |
| rsalveti | ogra_: lool: problem is, we can't update the bootloader | 11:22 |
| rsalveti | we don't have support for that | 11:22 |
| rsalveti | so even if we find the fix, we'd need someone to manually update it | 11:23 |
| rsalveti | or we add enough logic to handle that | 11:23 |
| rsalveti | which is kind of separating the upgrader from snappy | 11:23 |
| lool | rsalveti: let's do a bootloader update snap | 11:25 |
| rsalveti | that's kind of the upgrader snap | 11:25 |
| lool | we could call it update-manager.deb | 11:25 |
| rsalveti | because we want to update the upgrader before doing the upgrade | 11:26 |
| rsalveti | to work around issues in the upgrader code | 11:26 |
| lool | rsalveti: well I think it's ok to say "we had a critical issue with BBB reliable updates; we recommend you dump+restore your installation as follows" with 16.04 | 11:26 |
| ogra_ | well, one of the lessons we learned with the pandaboard is that we should definitely be able to update the bootloader :) | 11:26 |
| ogra_ | i wonder why we make the same mistake again | 11:27 |
| lool | but we need a working solution :-) | 11:27 |
| rsalveti | ogra_: right! | 11:27 |
| rsalveti | and why did we decide to not be able to update the snappy-update uboot script | 11:27 |
| rsalveti | we can have bugs anywhere | 11:27 |
| ogra_ | because it is dynamically created by udf today | 11:28 |
| ogra_ | but i guess it could just move into the snap | 11:28 |
| rsalveti | right, which is bad | 11:29 |
| rsalveti | so will send an email saying we're holding up the stable image until we are able to identify a fix for the bootloader | 11:30 |
| ogra_ | going with an env blob would enable us to actually drop all these files and have vars instead | 11:30 |
| rsalveti | ogra_: maybe something you can experiment | 11:30 |
| ogra_ | yes | 11:30 |
| mvo_ | grub uses the grubenv which is a magic file that can be written from grub | 11:32 |
| ogra_ | right, uboot.env would be the same | 11:32 |
| mvo_ | and there we do the same try-dance | 11:32 |
| ogra_ | the prob is that we need to touch the stamp after boot | 11:33 |
| ogra_ | so something in userspaxce needs to be able to modify the blob file | 11:33 |
| mvo_ | ogra_: yeah, grub has a save_env function for this | 11:33 |
| sergiusens | rsalveti: ogra_ in rolling snappy-system.txt can be updated fwiw | 11:33 |
| ogra_ | how does that work outside of the grub env ? | 11:33 |
| sergiusens | rsalveti: ogra_ just needs to go into the oem/gadget snap | 11:33 |
| ogra_ | uboot has a saveenv command too ... but that only works inside uboot | 11:34 |
| mvo_ | ogra_: oh, that works in both grub itself and the grub binary afaik | 11:34 |
| sergiusens | ogra_: shouldn't fw_saveenv work? | 11:34 |
| ogra_ | it might | 11:34 |
| mvo_ | ogra_: the implementation seems to be very simple, its a static 1k file, and it will simply update that, i.e. no grow/shrink and no filesystems like zfs where stuff might explode (or is checksumed) | 11:35 |
| mvo_ | that might explain why btfs and grubenv might be problematic | 11:35 |
| ogra_ | yeah | 11:35 |
| ogra_ | thats the idea for uboot.env too | 11:35 |
| mvo_ | the alternative idea? or the idea behing fatwrite? | 11:35 |
| ogra_ | the idea to replace fatwrite | 11:36 |
| ogra_ | theoretically we could even get rid of snappy-system.txt with that | 11:36 |
| mvo_ | ogra_: cool. if it works the same way as grub we could write a small helper that modifies the file making the same assumptions as grub | 11:36 |
| ogra_ | yeah | 11:36 |
| mvo_ | ogra_: i.e. no grow/shrink etc | 11:36 |
| ogra_ | i guess thats the missing bit atm | 11:36 |
| ogra_ | (beyond proving that the blob on top if a fat doesnt corrupt things as well :P ) | 11:37 |
| ogra_ | (i assume it doesnt, but this indeed needs testing) | 11:37 |
| === dstokes_ is now known as dstokes | ||
| rsalveti | ogra_: alright, sent the email, on you now :-) | 11:40 |
| ogra_ | heh, ok | 11:40 |
| mvo_ | ogra_: writing the helper should be straightforward, aiui, the cluster size in fat32 is at least 2k so as long as thats enough we should be able to do the same as grubenv is doing in a single fat32 cluster | 11:42 |
| mvo_ | ogra_: but let me refresh my memory by looking at some actual documentation :) | 11:42 |
| ogra_ | mvo_, well, the uboot binary blob is a text file with uboot hearder afaik | 11:45 |
| ogra_ | we'd just need to remove the header and can edit it ... then re-add the header | 11:45 |
| ogra_ | or use fw_saveenv ... but i have to look if thats still working with current uboot ... | 11:46 |
| mvo_ | ok | 11:46 |
| sergiusens | ogra_: last I tried fw-saveenv wasn't working for me and lool gave me a fancy explanation | 11:46 |
| sergiusens | rsalveti: I say we delay release until this is fixed so new installs have a working solution | 11:47 |
| sergiusens | reduces the possible affected surface | 11:47 |
| ogra_ | can we actually change uEnv.txt in the snap (wwill it be upgraded ?) | 11:48 |
| ogra_ | since that has the logic to read snappy-system.txt ... so even if we cant update that file in 15.04 we could just leave it around but not use it anymore | 11:49 |
| sergiusens | mvo_: thanks for those tests! where/how to insert the mock partition thing was why I took so long | 11:51 |
| sergiusens | ogra_: in rolling yes | 11:52 |
| sergiusens | ogra_: in 15.04 no, but I can backport a fix | 11:52 |
| ogra_ | sergiusens, ah, what *can* we updae in 15.04 ? | 11:52 |
| sergiusens | not going to be straightforward due to all the refactoring that happened though | 11:52 |
| mvo_ | sergiusens: no problem, thanks for finding the issue, that was the hard part | 11:52 |
| rsalveti | sergiusens: yeah, already sent an email saying we're delaying the release | 11:53 |
| longsleep | i just saw that email, how is fatwrite related to the base image? Is this not a u-boot issue? | 11:54 |
| longsleep | i mean, i had to backport basically the whole fat driver for the ODROID u-boot to get rid of corruption. | 11:55 |
| ogra_ | longsleep, well, fatwrite is only used for the rollback/update logic of the core system... yes, it is a uboot issue | 11:57 |
| * ogra_ lols ... | 11:57 | |
| ogra_ | so Commodore sells phones now | 11:57 |
| ogra_ | they dont look like breadboxes ! | 11:58 |
| longsleep | ogra_: yes - so i fail to see how it is related to any release of the base system. U-Boot is specific to the hardware is it not? | 11:59 |
| ogra_ | longsleep, we ship our own uboot on the SD | 11:59 |
| longsleep | ogra_: Ok - but specific for the BBB right? | 11:59 |
| ogra_ | specific to any of the debvices, yes | 12:00 |
| ogra_ | *devices | 12:00 |
| ogra_ | (every image ships a device specific uboot) | 12:00 |
| longsleep | ogra_: and that u-boot does not have the latest fat drivers? | 12:00 |
| ogra_ | it does, but still causes corruption on the BBB | 12:01 |
| longsleep | mhm | 12:01 |
| longsleep | i see | 12:01 |
| ogra_ | and we want to get rid of the fatwrite bits altogether | 12:01 |
| longsleep | that sounds good - it gave me lots of trouble :) | 12:01 |
| ogra_ | the plan is to have a uboot env in a file instead | 12:01 |
| longsleep | If it helps, check if the u-boot really has all the commits i merged in https://github.com/longsleep/u-boot-odroidc/commits/master | 12:01 |
| ogra_ | so that we can use vars and saveenv instead ... | 12:02 |
| longsleep | i hope very much that these commands are not some "rather" new feature of u-boot :) | 12:02 |
| ogra_ | no, the oldest ones :) | 12:03 |
| jdstrand | elopio: hey, in the title and description of 1474658 I think you at times mistyped 'hello-world-fwk' (which doesn't exist) for 'hello-dbus-fwk' (which does). not saying anything about the bug, just saying that reading the report is confusing because of that | 12:27 |
| elopio | good morning, | 12:33 |
| elopio | jdstrand: yes, at first it was my fault for mistyping it. | 12:34 |
| elopio | then it turned out to be a real bug. I forgot to update the title. | 12:34 |
| elopio | from fgimenez reply, I suppose that the result of search should include the origin. | 12:35 |
| elopio | but I'm not really sure why it works for hello-world without origin. | 12:35 |
| jdstrand | elopio: I think hello-world has an alias in the store | 12:41 |
| elopio | mmm, that would make sense. So I think I would like to see the origin as part of the name in the search output. | 12:42 |
| Chipaca | tedg: you around? | 12:46 |
| * ogra_ is waiting for him too ... for a phone question | 12:46 | |
| Chipaca | ogra_: canté pri! | 12:47 |
| * Chipaca has no idea how to translate that | 12:47 | |
| Chipaca | ogra_: something like "dibs!" | 12:47 |
| elopio | the translation to costa rican would be: "¡primas!". | 12:53 |
| Chipaca | elopio: i'm not sure where your female cousins come into it, but it sounds like a lot of fun. | 12:56 |
| elopio | puzzles me too. But I just do as the rest. | 12:56 |
| Chipaca | elopio: this might help: | 12:57 |
| Chipaca | http://buscon.rae.es/drae/srv/search?id=v0qAEEf8TDXX2jytCRSE|aiJ5mOGSxDXX2KPmUIAG | 12:57 |
| Chipaca | elopio: 20 definitions for "prima" | 12:57 |
| elopio | the beauty of spanish... ^_^ | 12:58 |
| elopio | fgimenez: a little style comment, we probably shouldn't use "get" in the function names: | 13:22 |
| elopio | http://golang.org/doc/effective_go.html#Getters | 13:22 |
| tedg | Then how to you get a getter for Git without a getGitGetter function? | 13:24 |
| tedg | mvo_, ICANHAZ your libxcb patch? | 13:24 |
| elopio | tedg: you just can't. go fmt will refactor it to panic. | 13:25 |
| tedg | elopio, That's it, we need to stick with Bazaar then. | 13:25 |
| elopio | +1. | 13:25 |
| * ogra_ notes that tedg is hiding from the #ubuntu-app-devel channel | 13:26 | |
| tedg | Oh, didn't realize there was one... | 13:26 |
| mterry | elopio, why are the tests in snappy under a directory called "_integration_tests"? underscore feels weird | 13:28 |
| ogra_ | upperscore is harder to type :P | 13:28 |
| elopio | mterry: I found no way to exclude them from the unit test execution. | 13:28 |
| mvo_ | tedg: Chipaca probably has a better version if not I can pass you my original quick diff | 13:29 |
| Chipaca | 1 sec | 13:29 |
| mterry | elopio, huh. you mean "go test" was finding them? | 13:30 |
| Chipaca | uh, why did i just edit this :-/ | 13:30 |
| Chipaca | tedg: http://pastebin.ubuntu.com/11882626/ | 13:32 |
| tedg | Chipaca, Thanks! | 13:33 |
| tedg | meep | 13:33 |
| elopio | mterry: yes, go test ./... ignores the dirs beginning with underscore. | 13:33 |
| elopio | but this was just a quick solution. | 13:33 |
| mterry | elopio, cool, just curious :) | 13:34 |
| mterry | thanks for explaining :) | 13:34 |
| elopio | maybe we can put all the unit tests in the unit package, and use -filter unit | 13:34 |
| elopio | or maybe we can extend gocheck filter to have a -x. | 13:34 |
| Chipaca | tedg: point that variable to somewhere you've copied /usr/share/X11/xkb to | 13:35 |
| Chipaca | and it's mvo's patch; the only difference is that he said FOO, and I changed it to the more confusing XKB_CONFIG_ROOT | 13:36 |
| Chipaca | was tempted to make it XKB_RENDER_ENGINE | 13:36 |
| tedg | I'd really like it to be XKB_MEEP | 13:37 |
| Chipaca | tedg: XKB_MEEP_MEEP, and we call it the roadrunner patch | 13:37 |
| elopio | mterry: about functional tests for snapcraft, do you think we should install the snap in a snappy machine and run the binaries? or just check that the generated file seems correct? | 13:40 |
| mterry | elopio, so far I've just been testing that the files we would put in the snap are fine. But I can see the virtue in installing the snap in a snappy machine. Maybe not for all tests, but certainly when testing our final "make a snap" step | 13:41 |
| elopio | mterry: shouldn't be hard, in this case we just need to deploy a rolling edge snappy, and adt-run takes care of that. I'm thinking about running the examples, at least. | 13:44 |
| === __bjf is now known as bjf | ||
| mterry | elopio, we have some integration tests already, using plainbox (in tests/plainbox) | 13:47 |
| mterry | elopio, but nothing that uses adt-run yet | 13:47 |
| mterry | elopio, for tests that want to download big things (like the go1.4 binary tarball)... how do we best do that in an automated way? | 13:47 |
| elopio | mterry: many options. But I'm inclined to run the big download at least once. So maybe do unit tests for all the parts faking the download, or one integration tests using a local source. This will be run on each MP. | 13:51 |
| elopio | and then we can have a daily suite that does the real thing, hitting the real server. | 13:51 |
| ogra_ | rsalveti, sergiusens, mvo_, so we seems to be missing a setting in the BBB binary ... #define FAT_ENV_FILE"uboot.env" | 13:53 |
| ogra_ | that allows it to boot the env blob | 13:54 |
| ogra_ | (it is funny, since most other TI targets actually have it set by default ... just am335x_* doesnt) | 13:57 |
| ogra_ | oh man | 13:59 |
| ogra_ | http://lists.freebsd.org/pipermail/svn-ports-head/2014-December/079896.html | 13:59 |
| ogra_ | -+#define FAT_ENV_FILE"uboot.env" | 14:00 |
| ogra_ | ++#define FAT_ENV_FILE"u-boot.env" | 14:00 |
| ogra_ | srysly ! | 14:00 |
| ogra_ | (yay for standadized names :( ... ) | 14:00 |
| sergiusens | ogra_: gotta love forks :-) | 14:15 |
| ogra_ | yeah... i'm more into spooning than into forking usually though :) | 14:15 |
| ogra_ | lool, so where exactly is the source we use for our uboot on the BBB | 14:16 |
| lool | ogra_: it's 2014.10 + the patch I linked earleir | 14:16 |
| sergiusens | ogra_: comes from that readme I gave yesterday | 14:16 |
| ogra_ | lool, ah, mailine ? | 14:16 |
| ogra_ | *main | 14:17 |
| sergiusens | ogra_: http://people.canonical.com/~lool/snappy-bbb/build | 14:17 |
| ogra_ | ah, i only had seen the README :P | 14:17 |
| mterry | mvo_, I mentioned in an MR that I think assemble() should only wrap the binaries that are mentioned in package.yaml. I think I'll make a merge for that, FYI | 14:31 |
| === bjf is now known as _jfb | ||
| === _jfb is now known as _fjb | ||
| mvo_ | mterry: yeah, that makes perfect sense | 14:36 |
| mterry | mvo_, when we move the original executable out of the way... do you like ".real" as a suffix? or ".snapcraft"? Or ".orig" maybe? | 14:36 |
| mvo_ | mterry: hm, no strong opinion, .snapcraft is so specific it has the least risk of collisions :) but then, we should protect against this anyway, I don't really mind. .real is good enough for me | 14:37 |
| mvo_ | (but .orig is also fine) | 14:37 |
| mterry | mvo_, or we could make a new directory in the snap, snapcraft/ and put a wrapper in there, and modify package.yaml to point at our version | 14:37 |
| mterry | But maybe other parts of their code have hardcoded relative paths to their executable | 14:38 |
| mterry | But that should be fine... | 14:39 |
| mterry | They'd already be running under the right env | 14:39 |
| mterry | Well, .orig is less invasive for now | 14:39 |
| mvo_ | mterry: yep | 14:40 |
| mvo_ | mterry: silly question, how can I test inside ./snap ? would it make sense to generate the wrappers already in the stage where the ./snap is generated ? | 14:40 |
| mvo_ | mterry: I'm snappyfying libreoffice right now for bjoern :) | 14:41 |
| mterry | mvo_, maybe? I've used "snapcraft shell" to test inside stage/ | 14:41 |
| mterry | mvo_, are you kidding? :) | 14:41 |
| mvo_ | mterry: I am - mostly, I use the deb plugin to see how far I can get with just that :) | 14:41 |
| mterry | mvo_, for libreoffice, you'll almost certainly hit the hardcoded path problem | 14:41 |
| mvo_ | yeah | 14:42 |
| mterry | mvo_, do we want to add ld_preload logic to snapcraft? As an interim for the final bindmount/overlayfs solution? | 14:43 |
| ogra_ | jdstrand, did you notice the ML ? someone is asking about mounting his USB driver to extend the writable space ... do we have any story for such a use case yet ? | 14:44 |
| ogra_ | *drive | 14:44 |
| mvo_ | mterry: maybe as a option? its a pretty cool feature | 14:45 |
| mvo_ | mterry: just like you said :/ http://paste.ubuntu.com/11882956/ | 14:50 |
| * ogra_ notices elopio has an airtame too ... we need to talk the mir team into supporting that from the phone ;) | 14:50 | |
| jdstrand | ogra_: it needs to be handle by a storage framework (access to a shared resource). touch is developing one. snappy doesn't have one at this time | 14:50 |
| mterry | mvo_, :( hardcoded paths are pervasive | 14:50 |
| elopio | ogra_: saviq offered on the forums to write an app. | 14:50 |
| mvo_ | yep | 14:50 |
| ogra_ | jdstrand, ok, i guess we need the same framework on both ... are the people designing that aware of this fact ? | 14:51 |
| ogra_ | iven the phone will switch to snappy eventually | 14:51 |
| jdstrand | ogra_: or, snappy could define something as part of its FHS and then app-specific rules could be added for the external storage. basically, someone needs to work with the architects to define something | 14:51 |
| ogra_ | right | 14:51 |
| jdstrand | ogra_: tvoss is designing it. he is on the architects team | 14:51 |
| ogra_ | would just be bad to have something on the phone that we have to throw away or re-write | 14:52 |
| jdstrand | ogra_: I don't think snappy was explicitly mentioned. this was more of a user-driven interaction type of thing with content-hub | 14:52 |
| ogra_ | i assume it would be nice if we could at least provide some hack for users so their device gets into fstab somehow | 14:53 |
| jdstrand | that with a change to the snappy FHS and we could create security policy for it | 14:53 |
| ogra_ | the guy asking actually only wants to use it in docker ... which i guess can be done via some configuration if the device is actually available or mounted | 14:53 |
| jdstrand | that is my understanding, yes | 14:54 |
| Chipaca | mterry: mvo_: hardcoded paths are pervasive, but we don't have to fix them all at once | 14:55 |
| * ogra_ would also like to use owncloud on his rpi ... | 14:55 | |
| ogra_ | (with 1G writable space thats kind of pointless though) | 14:55 |
| Saviq | elopio, yeah, I was even PM'ing with them for a bit about it but they went silent since | 14:55 |
| ogra_ | Saviq, well, is Mir even capable of doing such stuff ? | 14:55 |
| ogra_ | beyond vnc ... | 14:56 |
| Saviq | ogra_, depends what you mean by "such stuff" | 14:56 |
| ogra_ | remote desktop ... | 14:57 |
| ogra_ | or desktop forwarding | 14:57 |
| Saviq | ogra_, but, for what their mobile apps do (streaming content, not remote desktop), no mir support needed | 14:57 |
| ogra_ | (or phone forwarding) | 14:57 |
| ogra_ | ah | 14:57 |
| ogra_ | only content streaming, ok | 14:57 |
| Saviq | ogra_, but Mir can do screen sharing, too | 14:57 |
| Saviq | ogra_, the troublesome bit there is compression | 14:58 |
| ogra_ | well, i know it cant do anything like X11 forwarding ... or ssh X forwarding | 14:58 |
| Saviq | airtame can't, either | 14:58 |
| Saviq | airtame's a video streamer, is all | 14:58 |
| ogra_ | doesnt that depend on what you feed it ? | 14:58 |
| Saviq | the device itself is really just a h264 decoder | 14:58 |
| ogra_ | ah | 14:59 |
| * ogra_ still hasnt used any of his airtames | 14:59 | |
| ogra_ | i have two | 14:59 |
| ogra_ | (one early adopter version) | 14:59 |
| Saviq | ogra_, I did discuss compression with Mir folk before, and FWIW it should be possible to use hardware compression capabilities of the GPU | 15:00 |
| Saviq | well, SoC | 15:00 |
| Saviq | is what's used for camera video | 15:00 |
| Saviq | s | 15:00 |
| mterry | dholbach, heyo! I found a weird typo I guess in snappy docs: https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ -- look at the "binaries" example. The two examples use exec and name differently | 15:00 |
| Saviq | in theory you could feed it your screen | 15:00 |
| Saviq | and stream that to the airtame | 15:00 |
| ogra_ | yeah | 15:01 |
| davidcalle | mterry, nice catch, thanks | 15:04 |
| dholbach | mterry, very soon we'll have the docs auto imported :) | 15:07 |
| ogra_ | and everything will break :) | 15:07 |
| davidcalle | ogra_, of course, but isn't this nice ? http://i.imgur.com/jX4SSJs.png , http://i.imgur.com/qUlDv1q.png :) | 15:07 |
| ogra_ | sweet ! | 15:08 |
| davidcalle | mterry, fixed | 15:08 |
| sergiusens | davidcalle: it sure is! | 15:08 |
| mterry | davidcalle, dholbach: awesome, thanks | 15:08 |
| Chipaca | i've got to go to the mechanic, will bbl | 15:27 |
| Chipaca | tedg: any quesitons or blockers, telegram will work | 15:27 |
| tedg | Chipaca, Cool | 15:28 |
| tedg | Chipaca, Good luck :-) | 15:28 |
| elopio | sergiusens: I like your proposal for map + Scan, but for the format compliance tests. | 15:28 |
| elopio | what we are doing in the integration tests is closer to pattern matching: a user will ignore big chunks of text and care only about some lines. I find regexp and .* to express that nicely. | 15:28 |
| elopio | We have a card for the format tests, where we will want to check every single line. I'll copy your comment in there. | 15:28 |
| elopio | what do you think? | 15:28 |
| elopio | fgimenez: before you go, can you please review https://code.launchpad.net/~elopio/snappy/test_go_install_framework/+merge/264666 ? | 15:29 |
| elopio | that one blocks some of the others already approved. | 15:29 |
| fgimenez | elopio, sure | 15:30 |
| sergiusens | elopio: it's fine; scanning is also good to see how long a specific message takes to get on screen; but is leagues away | 15:35 |
| elopio | sergiusens: for that I was thinking about gocheck's StartTimer and StopTimer to surround the Exec call. But you are right, that won't work if what we want is to check when the downloading message appears, or when does it end. | 15:43 |
| elopio | Doesn't seem to be that far away, though. | 15:43 |
| fgimenez | elopio, you are working on test_go_install_framework right? | 15:45 |
| elopio | fgimenez: agh, no that's ready. | 15:46 |
| elopio | I left the comment on the wrong branch. | 15:46 |
| fgimenez | elopio, ok np :) | 15:46 |
| elopio | fgimenez: it's ok if I delete the generated control files, right? | 15:49 |
| fgimenez | elopio, sure, we should remove them | 15:50 |
| elopio | ok, that makes it easier. | 15:50 |
| plars | elopio: if you have a moment today, can you help me sort out how to run the snappy selftests now? I was running a snapshot of the older adt stuff in lp:~snappy-dev/selftests but I understand it's all in trunk now | 15:51 |
| elopio | plars: yes! I wanted to meet with you after we got all the tests running in bbb, but we are close to that now. | 15:52 |
| elopio | plars: take a look here: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/README.md | 15:52 |
| plars | elopio: I have a fully automated local setup still for automated provisioning and testing | 15:54 |
| plars | elopio: just landed some more code to support that in a more flexible way, so you can specify how the device gets a hard reset, boot mode selection, and stuff like that through just a config change | 15:55 |
| plars | elopio: that way once the hardware lands in the lab, we can easily support that | 15:55 |
| elopio | plars: nice. And are we going to be able to choose the release, channel and image that gets flashed? | 15:56 |
| plars | elopio: yeah, I looked at that, but I couldn't get it to work, getting stuff like this: | 15:56 |
| plars | https://www.irccloud.com/pastebin/jqCr0J8s/ | 15:56 |
| plars | elopio: well, it's assuming you provide an image, so that's external to this process | 15:56 |
| elopio | plars: you need to set up the go tree | 15:57 |
| elopio | and export the env vars. | 15:57 |
| plars | elopio: for now, I need to build the image outside and provide a url to download it from (preferably gzipped - downloading a 4GB image to bbb is *really* slow) | 15:57 |
| elopio | that's explained on the main REAMDE. | 15:57 |
| plars | elopio: yeah, I thought I had all that set up though... I'll look again, maybe I missed one | 15:57 |
| plars | elopio: does this not run easily through adt anymore? | 15:57 |
| elopio | plars: that sounds fine. We are generating the image, we would just need to uplaod it. | 15:57 |
| plars | elopio: it seems like there should be an easy way to run this all from a script | 15:58 |
| elopio | plars: it does run through adt. Easily, that's relative. | 15:58 |
| elopio | plars: your go tree should look like /tmp/scratch/go/src/launchpad.net/snappy. | 15:58 |
| plars | elopio: how would you run it through adt today? I didn't see a debian/tests or anything | 15:59 |
| elopio | plars: once you get it set up as the root README says, and have autopkgtest installed, you can ./run-checks. | 15:59 |
| kyrofa | seb128, how should I give the snappy scope .deb a test run on Ubuntu Personal? | 15:59 |
| elopio | plars: we generate the adt-run control file on-the-fly. And pass the path as an argument. | 16:00 |
| seb128 | kyrofa, build a daily image, boot it (vm or usb stick), mount / rw, install the deb, reboot | 16:00 |
| elopio | plars: we can't really put the tests in debian/tests as they access the internet, and they require an snappy image. If we put them in debian/tests they will run in proposed migration, making a mess. | 16:00 |
| elopio | plars: once we are able to specify this requirements in the control test-class, we could move them to debian/tests. Make a default control file that will have everything we want proposed migration to run. | 16:01 |
| kyrofa | seb128, very good. I know you'll be leaving shortly. Assuming everything works okay, what are the next steps? Since the Ubuntu Personal seed pulls (I assume) from the archives, do I need to set it up to land in the archives somewhere? | 16:02 |
| elopio | plars: anyway, we can meet whenever you want. I would prefer fgimenez to be around, but that would have to wait until friday. | 16:02 |
| * Chipaca back | 16:02 | |
| elopio | if you prefer to do it earlier, we can just fill him in by mail. | 16:02 |
| seb128 | kyrofa, it needs to land in Ubuntu first, then to be added to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop | 16:02 |
| plars | elopio: normally, I would use the ssh provider or similar for adt and run something like "adt-run --built-tree /tmp/scratch/selftests --output /tmp/results-0123 --- ssh -d -l ubuntu -P ubuntu -H 192.168.1.147 | 16:02 |
| elopio | plars: yeah, no, we had to wrap that in our own script because adt-run works fine for running, but not for provisioning. | 16:03 |
| plars | elopio: the recent changes seem to have made this work very differently from running other tests | 16:04 |
| plars | elopio: oh, I provision it ahead of time | 16:04 |
| plars | elopio: by provisioning you mean installing the snappy image? | 16:04 |
| elopio | plars: go run _integration-tests/main.go --ip 192.168.1.147 would give you that. | 16:04 |
| plars | elopio: right, but that's what requires all the aditional go setup, and not just an adt-run | 16:04 |
| kyrofa | seb128, alright, I'll get that setup | 16:04 |
| sergiusens | ogra_: by the way, your 64MiB suggestion for boot won't work, the modules in the kernel add up to 187MiB | 16:05 |
| elopio | plars: if you pass the ip, it does only adt-run, not building the image. | 16:05 |
| seb128 | kyrofa, thanks, when you have a sponsoring bug for the new package feel free to subscribe me | 16:05 |
| sergiusens | ogra_: but we don't keep that in boot... | 16:05 |
| elopio | plars: but we still need to generate the tests, generate snappy if you want to validate trunk, and some other stuff. | 16:05 |
| plars | elopio: I'm not seeing much about go/path setup in http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/README.md | 16:06 |
| elopio | plars: take a look at that main.go. Is now nice and readable thanks to fgimenez' refactor. | 16:06 |
| plars | elopio: I'm just interested in running the selftests on a device that has already been provisioned | 16:06 |
| elopio | plars: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/README.md | 16:06 |
| elopio | plars: yes, you still have to copy the tests to that provisioned device. | 16:07 |
| elopio | maybe I should add a pointer to the other README. | 16:07 |
| plars | ah, I see some of the integration tests are in go now... I didn't look one level deeper | 16:09 |
| plars | I was just seeing the shell ones | 16:09 |
| elopio | plars: hopefully, all of them will be go by the end of this week. | 16:10 |
| plars | doing things like this means a lot more requirements on the host side need to be supported, but if they have to be in go, I'm not sure there's a great way to do it | 16:11 |
| plars | I can see the problem | 16:11 |
| elopio | plars: what kind of requirements do you think we need? | 16:11 |
| === Abhishek__ is now known as Abhishek_ | ||
| plars | elopio: just all the go stuff to get it building on the host, paths set up, etc... not as simple as the adt-run we did previously | 16:12 |
| elopio | plars: right, that's because previously you were running the tests on the published image. | 16:12 |
| elopio | we need to run the tests before an image is published. So we have to build snappy and get it into the image. | 16:12 |
| plars | elopio: I got as far as go build working, but the test run bit doesn't work | 16:13 |
| plars | it just drops a binary for snappy itself in /tmp | 16:13 |
| sergiusens | ogra_: rsalveti btw, bind mounting modules.img to /lib/modules worked like a charm :-) | 16:13 |
| elopio | plars: can you paste the output? | 16:13 |
| plars | elopio: I did, it was the previous pastebin | 16:14 |
| elopio | plars: on the previous pastebin you didn't have the proper go path, that's why it doesn't find the gocheck module. | 16:14 |
| sergiusens | plars: godeps -u dependencies.tsv | 16:15 |
| plars | $ echo $GOPATH | 16:15 |
| plars | /home/plars/go/work | 16:15 |
| plars | elopio: under that, it seems to have downloaded all the necessary bits | 16:15 |
| plars | elopio: but I'd rather it didn't, don't we want it to pull from the branch checked out so it gets what's there? | 16:15 |
| elopio | plars: so cd /home/plars/go/work/src/launchpad.net/snappy and ./run-checks in there. | 16:16 |
| plars | sergiusens: I don't seem to have godeps | 16:16 |
| elopio | plars: not sure what you meant with the last statement. | 16:16 |
| plars | elopio: that's using a downloaded copy from launchpad.net right? how do you tell it to just use what you have checked out (and possibly changed locally) | 16:18 |
| plars | elopio: or do you have to download it with 'go get' and modify the copy in your $GOPATH/src/... | 16:18 |
| elopio | plars: with go get you only download the dependencies. | 16:19 |
| elopio | you get snappy from the bzr branch. | 16:19 |
| elopio | not yet sure if that's what you are asking though :) | 16:19 |
| elopio | fgimenez: https://code.launchpad.net/~elopio/snappy/test_go_info/+merge/264790 is again ready for review. | 16:22 |
| fgimenez | elopio, ok i'll take a look | 16:22 |
| elopio | not sure if it's already late for you. If so, don't worry, we'll get it on friday. | 16:22 |
| plars | elopio: run-checks seems to be trying to generate the image, which is precisely what I *don't* want to do | 16:23 |
| elopio | plars: I know. | 16:23 |
| elopio | that's just to check that you have everything in place. | 16:23 |
| plars | elopio: I suppose I would also need to build these for arm right? | 16:24 |
| elopio | no, instead of ./run-checks, do | 16:24 |
| elopio | go run _integration-tests/main.go --ip {remote-device-ip} | 16:24 |
| elopio | plars: ah, right | 16:24 |
| elopio | go run _integration-tests/main.go --ip {remote-device-ip} --arch arm | 16:25 |
| plars | adt-virt-ssh: error: unrecognized arguments: --reboot | 16:26 |
| plars | elopio: I guess I need a different version of adt-run? | 16:26 |
| elopio | plars: you need the latest one. | 16:26 |
| plars | I just have 3.13 from vivid | 16:26 |
| elopio | on the _integration-tests/REAMDE you'll find the link. | 16:26 |
| plars | ah, I see | 16:26 |
| elopio | plars: the one for wily is ok, but sometimes pitti fixes something for us so even that one can be outdated. | 16:27 |
| plars | yeah | 16:28 |
| elopio | plars: https://trello.com/c/KHFqlCce/157-make-sure-that-the-machines-running-the-tests-have-the-latest-adt-run | 16:28 |
| plars | elopio: ok, it's getting farther... I'll see what I can do with this. Thanks a lot for the help! | 16:28 |
| plars | elopio: which test beds is that aimed at? something you have set up somewhere? | 16:29 |
| elopio | plars: just in general. Everything we use as a test host needs the latest adt-run. | 16:29 |
| elopio | we are currently playing with a canonistack machine that will deploy other canonistack machines as testbed. And locally from our dev machines. | 16:30 |
| fgimenez | elopio, done with test_go_info, dropped a comment | 16:30 |
| plars | ah, ok. so a pre-run check | 16:30 |
| fgimenez | nice evening everyone o/ | 16:32 |
| elopio | plars: yes. | 16:33 |
| sergiusens | mvo_: do you know what creates /lib/firmware? | 16:33 |
| sergiusens | mvo_: oh, nevermind, I'll fix the 500 binary task to not remove the dir :-) | 16:34 |
| elopio | plars: so, when you get this bbbs running from the lab, we will extend main.go to run the tests in there in addition to in kvms. | 16:34 |
| elopio | we'll give you an image path, and you'll return us an ip. Everything will then just work (tm). | 16:35 |
| plars | elopio: well, the image really needs to feed into it before you call main.go | 16:40 |
| === vmayoral|pc is now known as vmayoral | ||
| elopio | plars: why is that? | 16:41 |
| plars | elopio: so we can just call ubuntu-device-flash somewhere else, build the image and push it to a download site, then the provisioner makes sure the device is stable and flashes it, boots into the image, then the script to run the test is called | 16:41 |
| elopio | plars: I think we need to start that whole process from main.go. | 16:42 |
| plars | elopio: it's already a very weird process from everything else, but that's the only sane thing I can think of to do | 16:42 |
| plars | elopio: that's going to be a problem I'm afraid | 16:42 |
| plars | elopio: the provisioning is handling a lot more than building an image, and in fact doesn't even build the image | 16:42 |
| plars | it needs the image handed to it | 16:42 |
| plars | elopio: it also handles detecting if the device is even available, or if it needs to be recovered to some working state | 16:43 |
| elopio | plars: ok, we can call main.go to an already generated and provisioned device. | 16:43 |
| elopio | plars: but I'd like two things: | 16:43 |
| elopio | 1. tarmac notices a new merge proposal is ready for review, so it triggers the whole test suite in kvm and bbb. | 16:43 |
| plars | hah, watching adt-run complain about apparmor rules and autopilot introspection in this context is a bit funny | 16:44 |
| elopio | 2. something notices that there's a new image in the channel and triggers the whole suite in kvm and bbb. | 16:44 |
| elopio | I think you are thinking about giving us 2, which is useful. But 1 it's more important atm. | 16:45 |
| plars | elopio: that part is on your side like all other teams, we just provide the hardware :) | 16:45 |
| plars | elopio: you really should sync up with the ci (ols) team and start taking a look at what they are working on | 16:46 |
| sergiusens | plars: that ci is not the thing we need; I don't think they are doing source level ci which is what elopio wants; in any case, once we have webhooks and we can talk to this hardware somehow, it won't be a problem | 16:49 |
| plars | sergiusens: I'd like to understand how that works, I would imagine that someone wants to test on hardware? | 16:51 |
| beuno | elopio, plars, sergiusens, CI is *only* focusing on product testing. That is, testing an image with one or many snaps, and their test suite however that's defined | 16:53 |
| beuno | unit tests on branches it out of scope for the CI work being done, or planned to be done | 16:53 |
| beuno | the entry point is a built snap | 16:53 |
| elopio | beuno: yes, this is not unit testing. This is testing snappy as-installed. | 16:55 |
| elopio | now, if snappy is a deb, not a snap. So, that's out of your scope? | 16:55 |
| plars | beuno: right, and this may be very different from the tarmac stuff they want to do right now, but if anyone wants to use the selftests as we have done before for testing snappy images, it would need to fit into that process somehow | 16:55 |
| beuno | elopio, we start off from a pre-built image, and can put snaps on top. CI won't care how that image is put together | 16:56 |
| beuno | elopio, once it's all snaps, it will be able to compose images on-the-fly | 16:57 |
| beuno | plars, yeah, we have uses cases for testing snaps before putting them in the store (or publishing them to any channel). Is that what you had in mind? | 16:57 |
| beuno | it's still a snap as a starting point | 16:58 |
| elopio | ok, so everything will just work. We just need to plug everything. | 16:58 |
| beuno | elopio, correct | 16:58 |
| elopio | once I know who to get a bbb provisioned, I'll add it. | 16:58 |
| elopio | and once I know how to define a test as part of a snapp, I'll add it. | 16:58 |
| beuno | elopio, the first MVP will be able to take a URL for an image, trigger test runs in jenkinses controlled by you and in hardware controlled by plars | 16:58 |
| beuno | report back | 16:58 |
| elopio | and once I know how to generate a image on the fly, I'll add it. | 16:59 |
| beuno | second MVP, that, but also install a snap | 16:59 |
| elopio | sounds easy :) | 16:59 |
| beuno | elopio, I expect plars to sort out bbb provisioning for you | 16:59 |
| beuno | he owns the lab | 16:59 |
| beuno | and you just focus on where and how to run tests | 16:59 |
| beuno | you slap on a small agent to the jenkinses and CI takes over in driving tests and reporting back | 16:59 |
| elopio | beuno: yes, all good. | 17:02 |
| elopio | however, I expect we will start having problems when the boundaries between runner, provisioning and test are blurry. | 17:02 |
| elopio | for example, we'll run the whole suite on a given image, that's the easy case. | 17:02 |
| plars | beuno: as I understand it, a test request can be made with or without a new snap. It just needs to be provided with a image to install and a test payload | 17:02 |
| elopio | then we will want to specify image 15.04 alpha -1. Update it, reboot and then run more tests. | 17:02 |
| beuno | plars, correct | 17:02 |
| elopio | that's harder. But we'll get to it after solving the first case. | 17:02 |
| plars | beuno: BBB provisioning is sorted out locally, and as soon as the hardware we've ordered arrives, it will be sorted in the lab | 17:03 |
| beuno | elopio, indeed. So provisioning will need to support that, and there's plenty of places to collaborate | 17:03 |
| beuno | plars, awesome. The good thing about our current model is that we could run it on your bbb and elopio's until we do :) | 17:03 |
| plars | beuno: my concern here was that provisioning needs an image, not a go binary to try to handle everything fo rit | 17:03 |
| elopio | plars: so, for now, we just need an ip from you. | 17:04 |
| elopio | we will adt-run into that ip. | 17:04 |
| plars | beuno: indeed! I'm sitting next to a breadboard with relays and a BBB fully instrumented right now :) | 17:04 |
| plars | elopio: but you don't know how to drive those relays, the control mechanism, hard power on/off, etc | 17:04 |
| plars | elopio: that's why I need to have the local provisioning agent handle that | 17:04 |
| elopio | plars: what you need is make an adt-run controller that knows how to handle that. | 17:05 |
| plars | elopio: it's not that your scripts can't be taught to do that, but it's configured locally per device, so there's no way to know how to do that in a generic way for any device in any environment | 17:05 |
| elopio | but in our current tests, we don't need hard power. Not yet. | 17:05 |
| plars | elopio: I do, for provisioning and recovery | 17:05 |
| elopio | that's only needed on your side, after a test ends. | 17:05 |
| plars | elopio: that's why the hard poweroff is needed | 17:05 |
| plars | elopio: no | 17:05 |
| plars | elopio: for provisioning, the bbb needs to boot either into emmc or sd | 17:06 |
| elopio | plars: but that's on your side too. | 17:06 |
| plars | elopio: you can never assume that the image on there before was ok to boot from | 17:06 |
| plars | elopio: exactly, that's why you *should* want me to handle provisioning, not your tests, and definitely not adt | 17:06 |
| elopio | we will give you an image, you provision however you want and we'll wait. | 17:06 |
| plars | that's way too late in the process | 17:06 |
| elopio | once we get the ip, we run the tetsts. | 17:06 |
| plars | and there's no way to make it generic enough for those to handle it | 17:06 |
| plars | it's a local device problem to solve | 17:06 |
| plars | that way you can just say "here's the image, you sort out how to get it on the device" | 17:07 |
| elopio | plars: you are saying just what I'm saying, I don't understand why you say it's too late. | 17:07 |
| elopio | we will give you the image, somehow. | 17:07 |
| plars | elopio: then that's fine | 17:08 |
| elopio | you put it in a device, somehow. | 17:08 |
| elopio | when that's ready, you give us an ip, and we adt-run into that ip. | 17:08 |
| plars | sort of... | 17:08 |
| plars | you would tell us where the test payload lives, which we need to figure out | 17:08 |
| elopio | plars: adt-run takes care of setting up the tests, through ssh. | 17:09 |
| plars | then a local script would probably have to detect that it's this selftest thing, not a regular adt test, and set up the go environment, call your main.go with the ip of $device | 17:09 |
| elopio | you don't need to know anything about the tests. | 17:09 |
| plars | then save off the results somewhere you can get to them | 17:09 |
| plars | elopio: well, sadly I do now | 17:09 |
| plars | elopio: because I can't treat it as a regular adt-run | 17:09 |
| elopio | not yet, at least. Once we want to test hardware power-off, then it's harder. But again, we'll figure it out later. | 17:09 |
| elopio | plars: adt-run takes care of collecting the results, through ssh again. | 17:10 |
| plars | off the device... then what? | 17:10 |
| plars | elopio: you don't have access to the local setup, and all that is going to get destroyed locally, not kept forever | 17:10 |
| elopio | why can't you treat them as regular adt-run? | 17:10 |
| plars | elopio: you said I couldn't | 17:10 |
| elopio | plars: yes, but you destroy it after the test finished. After adt-run collected everything. | 17:10 |
| plars | elopio: you said I had to set up the go build environment and build it first | 17:10 |
| elopio | plars: oh, I meant not as regular dep8 tests. | 17:11 |
| plars | right :) | 17:11 |
| elopio | these are not normal debian package tests, because they can't run in any debian, they need to run in a snappy. | 17:11 |
| plars | elopio: so at that point the tests are sitting on a host system half-way around the world... I assume you'd like to get at them somehow? | 17:11 |
| elopio | plars: so, the host is my machine, and the test bed is a bbb in the lab. | 17:12 |
| plars | elopio: sure, the previous selftest could run directly from adt-run though, and didn't require building and setup ahead of time, that's what I meant | 17:12 |
| plars | elopio: ah, that's where the confusion is | 17:12 |
| elopio | once I have the ip of the bbb, from my machine I use adt-run to get the tests into the bbb, to run the tests, and to collect back the results. | 17:12 |
| plars | elopio: your local machine may be the one requesting the test, but it's definitely not the host machine from which adt-run gets called | 17:12 |
| plars | elopio: assume lab, private network, etc | 17:13 |
| elopio | plars: it has to be either my machine, or the tarmac machine, or the jenkins machine. | 17:14 |
| plars | elopio: otherwise, if you want to instrument beaglebones and run them all locally, that's an option | 17:14 |
| plars | elopio: why? | 17:14 |
| plars | elopio: this is not that different to the problem on phones... you need something that manages that resource, connects to it locally, etc | 17:14 |
| plars | if it's in a lab, it needs to be something there, providing a service that lets you request provisioning, testing, etc. and feeds you back the results | 17:15 |
| plars | elopio: otherwise there's no way to stop you from stomping on stuff others are doing, or stop them from messing up your stuff | 17:15 |
| plars | elopio: now if it's something sitting locally on your desk, that's not a shared device and you can locally control access to it | 17:16 |
| plars | elopio: but the automated provisioning has to be handled locally, or else done manually | 17:16 |
| elopio | plars: yes, so you will have in the lab a tarmac machine that will ./run-checks from a snappy branch. And that will request a bbb and run tests in there. | 17:16 |
| elopio | that tarmac machine will take care of collecting the results, and posting them to launchpad. | 17:16 |
| elopio | ev, let me paste the log for you. | 17:18 |
| ev | thanks | 17:19 |
| elopio | thought I feel that we are going in circles. Once there's an API I can call, everything will be easier. | 17:19 |
| ev | I'll read over it after lunch | 17:19 |
| beuno | I think it's all fine, FWIW, and this will be clear once we have the first piece in place | 17:21 |
| beuno | but the journey of the conversation was super valuable | 17:21 |
| plars | indeed, I think it will make a lot more sense as soon as some of those pieces land | 17:23 |
| plars | elopio: for you, I think the process will work something roughly like: request $test on $image_url, receive a unique id, poll $somewhere for results (including a link to details result tarball and pass/fail status), download $results_url | 17:25 |
| plars | elopio: from that, if it's tarmac, it could use that to make a decision on the MP landing for example | 17:25 |
| plars | elopio: there's a lot of flexibility here | 17:25 |
| elopio | ev: noise][: http://paste.ubuntu.com/11883742/ | 17:26 |
| noise][ | elopio: thx | 17:27 |
| elopio | plars: and can that request $test look like: request "bzr branch lp:snappy && ./run-checks"? | 17:28 |
| plars | elopio: for now, I don't think so. It's going to need some wrapper to help it find the device, ensure the host environment doesn't get trashed, etc | 17:29 |
| plars | elopio: in the beginning, I have good support for adt-run on some branch (I was using the old selftests as a prototype actually!) | 17:29 |
| plars | elopio: and I was planning to add plainbox to that soon, so it could see some sort of test_type or something, and figure out which thing to call | 17:30 |
| plars | elopio: I'm sure we can support a special one for you, it's just too bad that it can't just be adt-run directly on the branch | 17:30 |
| plars | elopio: now if it's a snap that's already in the image, then I would bet it could work that way | 17:31 |
| elopio | if we can't specify the branch we want to test, then it's useful, yes, but we will get results too late. | 17:31 |
| elopio | plars: it can't be adt-run directly on the branch to run all the tests we want, at the moment we want to run them. | 17:31 |
| elopio | but it's possible for a subset of the tests, sure. | 17:31 |
| elopio | again, just give me the specs that the test needs to meet. And we will make it happen. | 17:32 |
| plars | elopio: I think specifying the branch would be just fine, it can be part of that test payload | 17:33 |
| plars | elopio: in fact, I was counting on it :) | 17:33 |
| elopio | plars: ok, but then how are you planning to build the branch? | 17:34 |
| elopio | you can't just bzr-bd, because you will end up with a .deb that you can't install on the snappy image. | 17:34 |
| plars | elopio: as I said, I can treat this as a 3rd "type" of test, and it would need to set up GOPATH, go get $something, and run it | 17:35 |
| plars | elopio: go run _integration-tests/main.go --ip $THIS_DEVICE_IP --arch arm | 17:35 |
| elopio | plars: ok, that's fine. I just started by saying that this "test from snappy build from a branch" is our main goal, it's what gives us more useful information. | 17:36 |
| elopio | a "test from snappy already published in an image" is useful, but not that much as the results will arrive a day late. | 17:36 |
| plars | elopio: incidentally, where can I find the output dir after running that? | 17:37 |
| kyrofa | seb128, I've got the .deb installed, but I'm not sure how to launch it. I can't seem to be able to drag up from the launcher | 17:37 |
| plars | elopio: well you have to build the image somehow? can't you pull the branch and build the image from that, then give me the url for it? | 17:37 |
| elopio | plars: not yet. Currently we depend on launchpad for building the image. | 17:38 |
| plars | elopio: and ./run_checks does that somehow? | 17:38 |
| elopio | ogra_ will work on rootstock to give us a quick way to build it locally, and beuno's team will at some point work on giving us images built on-the-fly. | 17:39 |
| plars | elopio: I'm assuming *something* can get the image you really want to check | 17:39 |
| elopio | plars: no, the trick run-checks does is that it puts the build snappy binary in the PATH, so instead of running the installed one, it runs the one from the branch. | 17:39 |
| plars | published, unpublished, or otherwise | 17:39 |
| elopio | that's also a temporary workaround that should be adjusted once more testability features start landing. | 17:40 |
| elopio | plars: the restuls are in /tmp/snappy-tests | 17:40 |
| elopio | /tmp/snappy-test | 17:40 |
| kyrofa | kgunn, have you gotten up and running with a recent Ubuntu Personal image? | 17:40 |
| plars | elopio: cool, found it. I got a bunch of failures, but to be fair this was an old image I was running it on. I'd like to do a newer one and try again at some point | 17:41 |
| elopio | plars: yes, and we haven't landed the branch that makes all the tests pass in bbb. | 17:42 |
| elopio | ...because we still have to make that branch :) | 17:42 |
| plars | elopio: ah, cool. Please let me know when that branch lands, that one will be interesting to watch for :) | 17:42 |
| elopio | currently it passes 100% only on kvm, 90% on canonistack. | 17:42 |
| plars | elopio: sure, understandable | 17:42 |
| elopio | bbb, I'm not sure now. I'll get back to it tomorrow. | 17:43 |
| plars | a lot of stuff does pass too btw | 17:43 |
| plars | so hopefully it's not *too* far off | 17:43 |
| elopio | plars: many tests are quite simple. The problem is with the failover ones. | 17:44 |
| plars | oh.. yeah | 17:44 |
| elopio | there are some real bugs, and there are some things that work differently on the board. | 17:44 |
| elopio | but yeah, we are close. | 17:44 |
| elopio | early next week, tops. | 17:44 |
| * rsalveti reading the huge backlog | 17:56 | |
| rsalveti | elopio: yeah, the way I see the main difference to when we're testing the landings with image testing is that for the first case we'd be generating the image by hand | 17:58 |
| rsalveti | and giving that to CI | 17:58 |
| rsalveti | plars: so where is the real lab going to be, in taiwan? | 17:59 |
| plars | rsalveti: yes | 18:02 |
| rsalveti | plars: so we need a real amd64 box in order to do the same tests but for kvm | 18:03 |
| rsalveti | since we can't do nested kvm easily | 18:03 |
| rsalveti | I was trying to get a machine so we could drive such testing, but that might still take a bit of time | 18:03 |
| rsalveti | plars: so wonder if we could just have a real box in there that could run such kvm testing | 18:04 |
| rsalveti | so we can follow the same testing path/logic for both kvm and bbb | 18:04 |
| plars | rsalveti: hmm, I'll have to talk to my manager about that. It's not something we were planning for right now. | 18:04 |
| rsalveti | and then drive the jobs by a custom jenkins or something along that line | 18:04 |
| plars | rsalveti: I wonder though, could you use a cloud instance instead of hardware+kvm? | 18:04 |
| rsalveti | plars: problem is nested kvm | 18:04 |
| plars | rsalveti: right, I don't mean run kvm on the instance, I mean the instance running snappy itself | 18:05 |
| rsalveti | so the host would need to be bare metal | 18:05 |
| rsalveti | that's kind of what elopio and federico are doing, but wonder if it will be fast enough | 18:06 |
| rsalveti | elopio: how are you planning on feeding the images on that case? | 18:06 |
| elopio | rsalveti: for our cloud testing so far, we are just taking the latest image in canonistack. | 18:07 |
| elopio | putting on top of that the built snappy from the branch and updating the PATH. | 18:08 |
| rsalveti | right, to test our own images we'd need to have a way to feed images | 18:08 |
| plars | elopio: the ci team had code to build an image with ubuntu-device-flash, convert it, and upload to glance | 18:08 |
| rsalveti | is that something we can do? | 18:08 |
| plars | and it even ran snappy selftests on it iirc :) | 18:08 |
| elopio | plars: /me wants! | 18:08 |
| plars | but just the old one | 18:08 |
| plars | elopio: hang on, there's even a microservice for it | 18:08 |
| rsalveti | plars: but on canonistack? | 18:09 |
| beuno | plars, how about maas + hardware in the lab? | 18:10 |
| beuno | to provision images for x86 | 18:10 |
| beuno | I'm sure we can either find the hardware or get some | 18:10 |
| plars | beuno: we *may* have something like this for our own sanity, but very likely not for test hardware directly | 18:10 |
| * beuno nods | 18:10 | |
| * beuno lets plars figure out how to make computers dance | 18:11 | |
| * elopio C< lunch. | 18:16 | |
| mterry | My snappy-rolling install still has python3. I thought we dropped that? | 18:29 |
| mterry | ah | 18:29 |
| mterry | I'm not really rolling | 18:29 |
| mterry | 15.04/edge | 18:29 |
| kgunn | kyrofa: i did last week, but haven't done much with it since | 18:31 |
| kgunn | what's up? | 18:31 |
| sergiusens | mterry: no, rolling still has python3 | 18:37 |
| mterry | sergiusens, guh | 18:37 |
| sergiusens | mterry: we need to drop system-image first and get a new cloud-init | 18:37 |
| rsalveti | yeah | 18:41 |
| === davmor2_ is now known as davmor2 | ||
| rsalveti | hopefully we can drop system-image soon | 18:41 |
| rsalveti | at least | 18:41 |
| kyrofa | kgunn, I can't swipe up on the app scope to get access to other scopes, so I can't test mine out, haha | 18:41 |
| kyrofa | kgunn, can you? | 18:42 |
| kyrofa | kgunn, swipe up, I mean | 18:42 |
| kgunn | lemme check kyrofa | 18:42 |
| kgunn | gimme a sec to build a new img | 18:43 |
| kyrofa | kgunn, thank you :) | 18:44 |
| kyrofa | kgunn, mine is a bit old at this point too... maybe I should do that | 18:44 |
| kgunn | kyrofa: you still using this incantation ? | 18:45 |
| kgunn | u-d-f personal rolling --channel edge --output wily.img | 18:45 |
| * kgunn checks cause you never know what changes in a week :) | 18:45 | |
| kyrofa | kgunn, yessir! | 18:46 |
| mterry | barry, got a sec for python import questions? If I installed python2 into /usr/local as well as a python module into /usr/local (but otherwise the same way ubuntu does), would python2 know how to find that module without any env vars? | 19:21 |
| barry | mterry: depends on where in /usr/local :) | 19:22 |
| mterry | barry, I'm testing a snap with python2 installed | 19:22 |
| mterry | barry, inside the snap. I also put a module in there | 19:22 |
| barry | mterry: you can always tell for sure by running `python -c "import sys; print(sys.path)" | 19:22 |
| mterry | barry, and somehow python2 is finding the module, I wouldn't have expected that | 19:22 |
| mterry | good point, /me tries that | 19:23 |
| barry | mterry: this is a python built for ubuntu right? (it will have different default paths than a built-from-upstream-source version) | 19:23 |
| mterry | barry, this is ubuntu python, yeah | 19:23 |
| mterry | (amd64)ubuntu@localhost:~$ spongeshaker.sha3sum /usr/bin/env['/apps/spongeshaker.sideload/0/bin', '/apps/spongeshaker.sideload/0', '/apps/spongeshaker.sideload/0/usr/lib/python2.7', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/plat-x86_64-linux-gnu', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/lib-tk', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/lib-old', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/lib-dynload', '/apps/spongeshaker | 19:23 |
| mterry | .sideload/0/usr/lib/python2.7/dist-packages'] | 19:23 |
| mterry | barry, ^ looks like it finds it alright, along with a bunch of other weird stuff | 19:24 |
| barry | mterry: weird (well, the spongeshaker prefixes). i haven't yet had time to follow your work here too closely | 19:25 |
| mterry | barry, ignore the silly spongeshaker stuff | 19:25 |
| mterry | barry, that's just the name of the snap I'm testing with | 19:26 |
| barry | mterry: cool, the lib-tk, lib-old, lib-dynload are expected | 19:26 |
| barry | as is the plat triplet | 19:26 |
| mterry | barry, and the dist-packages presumably | 19:26 |
| mterry | barry, so our python2 looks at where it's being run from, and assumes the prefix from that? | 19:26 |
| barry | mterry: yep, that's the debian-ism | 19:26 |
| mterry | barry, that's pleasantly progressive of it | 19:26 |
| mterry | barry, considering we know we're always running from /usr | 19:26 |
| mterry | barry, well, usually ;) | 19:27 |
| barry | mterry: python generally looks for some landmarks and crafts its default sys.path from those | 19:27 |
| barry | i don't remember the landmark, it's changed a few times. could be os.py these days | 19:27 |
| beuno | jdstrand, o/ I want to make my automated blinds thing a proper snap I can submit to the store. Is the hardware permissions story in 15.04 at all, or should I target (and install) rolling instead? | 19:35 |
| beuno | my code is all sudo this and sudo that atm :) | 19:35 |
| kgunn | kyrofa: ok, had a little 'puter trouble, back now and got my unity8 personal up...what exactly were you experiencing trouble with ? | 19:36 |
| kyrofa | Well, on the phone, I can drag up from the bottom to get access to all installed scopes. That default window in Ubuntu Personal looks the same, but I'm unable to drag that little arrow up from the bottom to get access to other scopes | 19:37 |
| kyrofa | kgunn, ^^ | 19:37 |
| kgunn | ah | 19:37 |
| kgunn | one sec | 19:37 |
| kgunn | yeah...having the same prob | 19:38 |
| kgunn | i suspect some issue with pointer events in window mode | 19:38 |
| kyrofa | kgunn, hmm... tough to test scopes out that way. I don't know another way to launch them. Any ideas? | 19:39 |
| kgunn | mzanetti: ^ any ideas ? is there a cli maybe to reveal the manage dash ? | 19:40 |
| kgunn | seems on personal image (windowed mode unity8 in a vm) that bottom edge of dash is either impossible or close to impossible | 19:41 |
| kyrofa | cihelp: I have a package that's running in jenkins and autolanding. I need the configuration changed so that I can land it in the archives. What do I do? | 19:54 |
| kyrofa | Oops... wrong room | 19:54 |
| kyrofa | Ahem... | 19:54 |
| mzanetti | kgunn, kyrofa: try launching it with "-mousetouch" | 20:06 |
| mzanetti | that should convert all mouse input to touch events and allow activating those touch-only drag areas | 20:06 |
| kyrofa | kgunn, do we have a terminal we can do that ^^ in? | 20:07 |
| kyrofa | mzanetti, , not sure how mir displays work, but I assume I can't do that on SSH and expect it to work | 20:08 |
| mzanetti | kyrofa, how do you launch the dash? is it autostarted? | 20:08 |
| kyrofa | mzanetti, yeah, autostarted | 20:09 |
| mzanetti | then I think you can edit /usr/share/upstart/sessions/unity8-dash.qml | 20:09 |
| mzanetti | and add some args there somewhere | 20:09 |
| mzanetti | use "restart unity8-dash" | 20:09 |
| kgunn | mmm... | 20:10 |
| kgunn | but can we flip to vt1 ? | 20:10 |
| kgunn | think there's a bug maybe | 20:10 |
| kgunn | ah...it worked | 20:11 |
| kyrofa | kgunn, I can get there | 20:11 |
| kgunn | nice | 20:11 |
| kyrofa | kgunn, ah, good | 20:11 |
| kgunn | :) | 20:11 |
| mzanetti | to use "restart unity8-dash" you need to have session variables exported tho... | 20:11 |
| kyrofa | mzanetti, how about a reboot? | 20:12 |
| mzanetti | yeah, that would work too :) | 20:12 |
| mzanetti | here's a terminal for unity8... http://notyetthere.org/data/com.ubuntu.terminal_0.7.latest_amd64_rev015.click | 20:12 |
| mzanetti | I found that quite useful | 20:12 |
| kyrofa | mzanetti, awesome, thank you! | 20:13 |
| mzanetti | np | 20:13 |
| tedg | kyrofa, I just used a session upstart job. Copied the /usr/share/upstart/sessions one to ~/.config/upstart and then added the -mouse touch parameter. | 20:13 |
| kyrofa | tedg, good call, thanks | 20:21 |
| kyrofa | tedg, just add the -mousetouch at the end of the exec line? | 20:24 |
| kyrofa | It's not working for me. Perhaps I'm putting that param in the wrong place | 20:26 |
| tedg | kyrofa, I did it for unity8 not the dash, not sure if they work differently. | 20:34 |
| jdstrand | beuno: everything that is in rolling is in 15.04 afaik. so hw-assign works and so does assign via the oem snap | 20:37 |
| jdstrand | beuno: you might talk to snappy core guys for updates. I do know that it isn't documented well and there is a bug on that | 20:38 |
| kirkland | does icon.png have to be a specific dimension? | 21:04 |
| tedg | I think that icons can only be SVGs | 21:08 |
| ev | elopio: for what it's worth (after that whole discussion earlier), you don't have to work strictly in images. We have a potential use case in testing pre-snappy phones. Because you never pass along an actual image but instead a reference to an image (a URL or whatever text you want), this can be ubuntu-device-flash --do-stuff or whatever. | 21:26 |
| ev | Also, the core of this system is product based testing with clear separation between three actors: test authors, labs, and promotion. CI purposefully knows nothing about the tests. They can be written in DEP8 or Haskell for all we care. However, the tests should not reach beyond their role: they shouldn't manage the lifecycle of the device under test, as | 21:26 |
| ev | that's a property of the lab. They need to be able to ensure that you're not phoning them up complaining about BBBs being wedged. | 21:26 |
| ev | We're going to follow this up with happy shiny documentation to explain it more eloquently than I can over IRC | 21:27 |
| === _fjb is now known as bjf | ||
| elopio | my quassel is angry at me again. | 22:27 |
| elopio | ev: sounds good. The test experiment we are doing on writing the test in go is awesome because it's self contained, it's just a binary you run and it will have all the dependencies. | 22:29 |
| elopio | for that part, we only need to know what is the api and the format expected from us, and we'll compy. | 22:29 |
| elopio | there's one detail that's hard, and we don't yet know how to solve, and that's generating an image without waiting for launchpad to do it for us. | 22:29 |
| elopio | but even that it's a problem that we can solve as we go. Worst case scenario, we keep our hack with the PATH which is OK for now. | 22:30 |
| elopio | but I'm sure the solution will be a lot better than the worst case scenario. | 22:31 |
| ev | elopio: image composition is something we're being mindful of, but exists outside of the CI product: https://docs.google.com/presentation/d/1Ds08fWyDkd-oddA7LMuj0iO6iHa2OyqsIWHGg5_4mv8/edit#slide=id.gb43807a7b_0_497 and https://docs.google.com/document/d/1aIKRneZWge6U6BuuchGE7MWBYE67dog900zWqJU0zi8/edit (grep for img_composer) | 22:35 |
| ev | elopio: might I recommend IRCCloud ;) | 22:36 |
| ev | it almost makes IRC tolerable | 22:36 |
| elopio | ev: I love quassel, despite all its tantrums. Generally it works on my desktop when it fails on my laptop, like today :) | 22:55 |
| elopio | ev: we are close to finish our first goal for the test suite. Then, focus will be on running the tests often, so I'll soon send a calendar appointment with you and plars to re-sync. | 22:56 |
| elopio | for now, I think we are good enough. If you or somebody from your team could run the snappy _integration-test locally to get a sense of what we are doing, that would be awesome. | 22:57 |
| ev | elopio: that's more for you to do directly. This is self-service CI. We purposefully don't have knowledge of the tests, how they're ultimately run, or how to interpret the results. | 23:33 |
| ev | The team is working on documenting how to submit results, how to (work with plars) to configure the agent's provisioner, and where to poll for results. | 23:33 |
| ev | I'll reach out to you once those docs are in place to review our progress towards the story of validating the core snappy product | 23:33 |
| ev | (that's slides 2-4 in https://docs.google.com/presentation/d/1Ds08fWyDkd-oddA7LMuj0iO6iHa2OyqsIWHGg5_4mv8/edit#slide=id.gb43807a7b_0_366 ) | 23:39 |
| ev | s,how to submit results,how to submit new test opportunities, | 23:42 |
| ev | this, incidentally, means you have more freedom to do what you need, but at present it requires that you drive the process (until we hook up to the firehose of the store) | 23:44 |
| beuno | *cough* public channel *cough* | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
