| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:57 |
|---|---|---|
| fgimenez | good morning | 07:13 |
| JamesTait | Good morning all; happy Work Like A Dog Day! 😃 | 08:32 |
| ogra_ | ppisati, help ! ... i know i managed once to get the rpi bootloader to hand the cmdline.txt over to u-boot ... but i cant manage that anymore, do you remember if we needed to use the mkknlimg tool against uboot.bin to achieve that ? | 08:41 |
| ogra_ | or was that kernel only (which wouldnt help for plain u-boot indeed) | 08:41 |
| ppisati | ogra_: hi | 08:42 |
| ppisati | uhm | 08:42 |
| longsleep | oh joy - cant you guys get rid of the rpi bootloader? | 08:42 |
| ogra_ | nope | 08:42 |
| longsleep | :/ | 08:42 |
| ogra_ | pi cant boot without it | 08:42 |
| ogra_ | uboot is just a chainloaded thing here | 08:42 |
| ppisati | ogra_: i don't remember ever doing that | 08:43 |
| longsleep | so it could boot without uboot then? | 08:43 |
| ppisati | ogra_: let me grab my pi board | 08:43 |
| ogra_ | (and for the fun, all DTB overlay handling also has to happen in the blob bootloader) | 08:43 |
| ppisati | yep | 08:43 |
| longsleep | oh | 08:43 |
| ogra_ | longsleep, it could boot, but not update and rollback ... or failover | 08:43 |
| longsleep | ogra_: i see - and the rpi bootloader loads something from disk itself? | 08:44 |
| longsleep | ogra_: so it has fat read drivers and all itself? | 08:44 |
| ogra_ | yeah, it loads either uboot.bin or the kernl | 08:44 |
| ogra_ | (and aside from that it is also the binary GPU driver as well) | 08:45 |
| longsleep | is that new for rpi2? | 08:46 |
| ogra_ | nope | 08:46 |
| ogra_ | has always been like that | 08:46 |
| ogra_ | there is no free bootloader for it ... and the bootloader is the GPU driver (it even loads into the GPU to then init the HW afterwards before loading kernel or uboot) | 08:47 |
| longsleep | ogra_: ok - let me check one of the rpi's i have then | 08:49 |
| ogra_ | the thing is that this bootloader has its own config file and also a file where you can put the cmdline in ... if there is something inside that cmdline file it creates a cmdline from ROM values merged with the file content it hands over to uboot as "args=" variable ... | 08:50 |
| longsleep | ah yes - seems that i am not even using u-boot then | 08:50 |
| ogra_ | these ROM values contain the board serial and the MAC address ... | 08:50 |
| longsleep | urg | 08:51 |
| ogra_ | i need them in my uboot env and cant get them to show up anymore | 08:51 |
| longsleep | thats config.txt and cmdline.txt you are referring to? | 08:51 |
| longsleep | i see these both | 08:51 |
| ogra_ | yeah | 08:51 |
| ogra_ | http://paste.ubuntu.com/11993082/ | 08:51 |
| ogra_ | see the "args=" line at the top | 08:51 |
| longsleep | right | 08:52 |
| ogra_ | that comes from the bootloader (my cmdline.txt contained elevator=deadline in that case) | 08:52 |
| longsleep | do you have the fixup.dat as well? | 08:52 |
| ogra_ | yes | 08:52 |
| ogra_ | i have start.elf, bootloader.bin and fixup.dat ... the configs and the respective DT | 08:52 |
| longsleep | so, for you the args value are the defaults and you cannot change them> | 08:53 |
| longsleep | ? | 08:53 |
| ogra_ | no | 08:53 |
| ogra_ | the args value is unset now | 08:53 |
| longsleep | ah ok | 08:53 |
| ogra_ | it doesnt get handed over to uboot at all | 08:53 |
| ogra_ | there seems to be some chack for DT capability of the kernel in the bootloader ... if it doesnt find that, it uses ATAGs, which i think is my prob | 08:54 |
| ogra_ | *check | 08:54 |
| ogra_ | you need to use a special tool that adds a suffix to the kernel binary which makes the bootloader know the kernel is DT capable | 08:55 |
| longsleep | oh joy | 08:55 |
| ogra_ | and i think that is what i'm missin on my uboot binary | 08:55 |
| ppisati | wait | 08:55 |
| ppisati | i had an email about that | 08:56 |
| ogra_ | (we had some mail discussion about that before, thats why i asked ppisati if he still remembers) | 08:56 |
| ogra_ | *snap* | 08:56 |
| ppisati | right | 08:56 |
| ogra_ | :) | 08:56 |
| ogra_ | but that doesnt talk about uboot at all | 08:56 |
| ogra_ | only about the kernel | 08:56 |
| longsleep | ogra_: and in your config you set kernel=uboot.bin or something? | 08:56 |
| ogra_ | i need the var before the kernel is loaded | 08:56 |
| ogra_ | longsleep, right | 08:57 |
| ogra_ | the silly thing is that i had it working properly ... as you can see in the paste | 08:57 |
| ogra_ | but then the file corruption issie showed up, i forgot to write down what i had done and now i cant get it to work anymore | 08:57 |
| longsleep | ogra_: mhm you think it is a u-boot compile time flag? | 08:58 |
| ogra_ | no, we didnt patch uboot much | 08:58 |
| ogra_ | there is the raw initrd patch, thats all (one config line) | 08:58 |
| longsleep | right, so you use latest mainline u-boot for the rpi? | 08:59 |
| ogra_ | and for the new uboot.env stuff i changed the file size of uboot.env ... but i cant even get it to work without that | 08:59 |
| ogra_ | i tried both, mailine and srwarrens tree | 08:59 |
| ppisati | ogra_: do you recall the subj of that email conversation? i can't find it right now... | 08:59 |
| ogra_ | i dont think it is uboot | 08:59 |
| ogra_ | ppisati, "Snappy Core Image for Raspberry Pi" | 09:00 |
| ogra_ | 1) You need to use the 'mkknlimg' utility to append a trailer to the kernel image. Without this, the loader doesn't know that the kernel is DT-capable, and will use ATAGs instead. | 09:00 |
| ogra_ | Follow the (recently updated) instructions here: https://www.raspberrypi.org/documentation/linux/kernel/building.md | 09:00 |
| ogra_ | uh, oh | 09:02 |
| longsleep | whoah that script looks scary | 09:02 |
| ogra_ | ppisati, i remember there was some uboot cmdline you gave me to have the content of "0x100" stuffed into the env ... | 09:03 |
| ogra_ | (it slowl comes back ...) | 09:03 |
| ogra_ | *slowly | 09:03 |
| longsleep | ah that would make sense | 09:03 |
| ppisati | ogra_: i'm passing directly what i get from the rpi loader to the kernel | 09:04 |
| ogra_ | i can actually see the cmdline with md 0x100 | 09:04 |
| longsleep | then just import it | 09:04 |
| longsleep | if the rpi bootloader writes its args to 0x100 | 09:05 |
| longsleep | ogra_: something like 'env import -t 0x100' | 09:14 |
| longsleep | (sorry i got distracted) | 09:14 |
| ogra_ | longsleep, no, i found the old conversation ... it isnt an env but actually the start if the devicetreew i see with md | 09:18 |
| ogra_ | fdt addr 0x100 ... should theoretically work ... but gives me an error | 09:19 |
| ogra_ | libfdt fdt_check_header(): FDT_ERR_BADMAGIC | 09:19 |
| ogra_ | but i'm on the right track now so i should get it working | 09:20 |
| ogra_ | aha ! | 09:20 |
| ogra_ | Jun 16 13:32:43 <ppisati> ogra_: BTW, the patched uboot is here if you want to try it - http://people.canonical.com/~ppisati/uboot.raspy2 | 09:20 |
| ogra_ | ppisati, do you remember what you patched there ? | 09:20 |
| ppisati | i think i know | 09:21 |
| ppisati | let me check | 09:21 |
| longsleep | yes i think it must be u-boot | 09:21 |
| ogra_ | (i would just take your binary but i need additional patching sadly) | 09:21 |
| ppisati | right | 09:21 |
| ppisati | so | 09:21 |
| ppisati | ./mkknlimg --dtok ./uboot.bin.old ./uboot.bin | 09:22 |
| ppisati | to get that uboot | 09:22 |
| ogra_ | bah, i had --dtok --283x in my last try | 09:23 |
| ogra_ | i guess thats it :P | 09:23 |
| ogra_ | so close (and just by guessin) | 09:23 |
| ppisati | ogra_: | 09:24 |
| ppisati | ops | 09:24 |
| ogra_ | U-Boot> fdt addr 0x100 | 09:25 |
| ogra_ | libfdt fdt_check_header(): FDT_ERR_BADMAGIC | 09:25 |
| ogra_ | grrr | 09:25 |
| ppisati | even with the patched uboot | 09:26 |
| ppisati | fdt addr 0x100 | 09:26 |
| ppisati | works here | 09:26 |
| ppisati | ok, forget bout that | 09:27 |
| ogra_ | the error looks like the dtb file is messed up ... | 09:27 |
| ppisati | i was able to boot a kernel | 09:27 |
| ogra_ | but why would it be loaded to ram just flawless if it was | 09:27 |
| ppisati | U-Boot> fdt addr 0x100 | 09:27 |
| ppisati | U-Boot> run loadkernel | 09:27 |
| ppisati | 4537616 bytes read in 3313 ms (1.3 MiB/s) | 09:27 |
| ppisati | U-Boot> bootz ${kernel_addr_r} - 0x100 | 09:28 |
| ppisati | and i got to a booted system | 09:28 |
| ogra_ | sure | 09:28 |
| ogra_ | i'm far from that point ... i need the values in my uboot env to assmeble a proper cmdline first :) | 09:28 |
| ogra_ | then i'll care for booting :) | 09:28 |
| ogra_ | i guess i should start over from a clean state | 09:29 |
| ogra_ | U-Boot> fdt addr 0x100 | 09:35 |
| ogra_ | U-Boot> fdt get value serial /system linux,serial | 09:35 |
| ogra_ | U-Boot> echo ${serial} | 09:35 |
| ogra_ | 000000001cdb048b | 09:35 |
| ogra_ | \o/ | 09:35 |
| ogra_ | yippie !! | 09:36 |
| ogra_ | U-Boot> fdt get value args /chosen bootargs | 09:36 |
| ogra_ | U-Boot> printenv args | 09:36 |
| ogra_ | args=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa01041 bcm2709.serial=0x8b04db1c smsc95xx.macaddr=B8:27:EB:04:DB:1C bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait | 09:36 |
| ogra_ | there we go | 09:36 |
| longsleep | what did you change? | 09:38 |
| longsleep | and what do you use the serial for? | 09:38 |
| ogra_ | i used ./mkknlimg --dtok on the uboot binary ... and actually copied the dtb files freshly in | 09:38 |
| ogra_ | the serial is needed if you want to buy the video codecs | 09:39 |
| longsleep | ah yes | 09:39 |
| ogra_ | so it must be set in /proc/cpuinfo | 09:39 |
| ogra_ | and indeed you want the persistent MAC | 09:39 |
| longsleep | do you know how the bootloader generates it? | 09:39 |
| ogra_ | from msc95xx.macaddr=B8:27:EB:04:DB:1C | 09:39 |
| ogra_ | afaik the first stage loader reads it from ROM | 09:40 |
| longsleep | mhm you think they fuse it on the chip? | 09:40 |
| ogra_ | well, i dont know how it exactly works, but it must come out of the HW somehow ... i guess they imprint it with the first stage loader in the ROM | 09:41 |
| longsleep | it is probably derived from the serial number in some way - i was just wondering if there could be collision (which i have seen in ODROID land). | 09:43 |
| ogra_ | yeah, hard to tell ... that bootloader is a blackbox | 09:44 |
| longsleep | yes - closed source bootloaders make me sad | 09:46 |
| ppisati | ogra_: cool | 09:54 |
| ogra_ | ppisati, thanks a lot ! | 09:54 |
| ppisati | ogra_: how do you make printenv print on different lines? | 09:54 |
| ppisati | ogra_: i totally forgot about all this stuff | 09:54 |
| ppisati | ogra_: i mean, instead of clobbing a single line | 09:54 |
| ogra_ | me too, thats was my prob for the last three days :P | 09:54 |
| * ogra_ is banging his head against that since friday | 09:54 | |
| ppisati | poor friday | 09:55 |
| ogra_ | ppisati, i dont do anything, printenv has a newline at the end of each line here | 09:55 |
| ppisati | uhm | 09:55 |
| ppisati | not here | 09:55 |
| * ppisati sad panda | 09:55 | |
| ogra_ | what terminal do you use ? | 09:55 |
| ogra_ | screen /dev/ttyUSB0 115200 ... | 09:56 |
| ppisati | minicom | 09:56 |
| ppisati | let me try screen | 09:56 |
| ogra_ | that gets me poper terminal shaped output | 09:56 |
| ogra_ | (and i can detach ... ssh from my laptop in the livingroom into the machine with the serial line and take over the console from there ... very helpful) | 09:57 |
| ppisati | so you have a host in betweeb? | 09:57 |
| ppisati | *between | 09:57 |
| ogra_ | not atm | 09:57 |
| ogra_ | but i can if needed/wanted | 09:57 |
| ppisati | i mean, i can detach too | 09:57 |
| ppisati | anyhow | 09:58 |
| ppisati | let me try screen | 09:58 |
| ppisati | fuck | 09:58 |
| ppisati | it works | 09:58 |
| ogra_ | well, screen keeps the terminal up but detaches the tty ... so i can switch machines | 09:58 |
| ogra_ | indeed :) | 09:58 |
| * ogra_ gave up on all other terminal emulators years ao | 09:59 | |
| ogra_ | *ago | 09:59 |
| ppisati | i've always used cu | 10:00 |
| ppisati | then minicom since i have problems with cu and some boards | 10:00 |
| clobrano | Hello, I was wondering if packages already in ubuntu repository (e.g. iperf) could be submitted to snappy store or is it something that will be done automatically | 10:01 |
| ogra_ | clobrano, depends ... what would you use iperf for ? if it is something inside your snap that wants it you would ship it in your project snap | 10:02 |
| ogra_ | if it is for general convenience it would go into the "comfy" snap which we are working on ... thats a snap to make your shell experience a bit more convenient as a developer that actually works on the snappy box and will include a bunch of helpful tools | 10:03 |
| clobrano | ogra_: well, not directly used by my snap, but iperf like other tools are useful when testing some applications | 10:03 |
| ogra_ | right, then it would be a comfy thing | 10:04 |
| clobrano | ok, perfect | 10:04 |
| clobrano | that's exactly what I was thinking | 10:04 |
| ogra_ | (along with a proper vim ... htop etc etc ... ) | 10:04 |
| clobrano | I would love vim :) | 10:04 |
| ogra_ | there was a ML discussion about comfy iirc ... started by lool | 10:04 |
| ogra_ | i think for the start it will likely be something like the dependencies of the ubuntu-minimal metapackage +/- one or the other tool | 10:05 |
| ogra_ | and then we'll ghrow it over time | 10:05 |
| clobrano | nice | 10:07 |
| longsleep | yay proper vim!!! | 10:10 |
| longsleep | ogra_: so, regarding the rpi you now modify the u-boot after you created it? | 10:13 |
| ogra_ | longsleep, well, i run it through the mmknimg tool to get the suffix set | 10:14 |
| ogra_ | http://paste.ubuntu.com/12005875/ | 10:17 |
| ogra_ | my notes for next time :) | 10:17 |
| longsleep | ogra_: You should fork my make files for the ODROID :) | 10:18 |
| longsleep | ogra_: https://github.com/longsleep/snappy-odroidc | 10:19 |
| ogra_ | i got shellscripts for that ;) | 10:20 |
| ogra_ | (just not for the rpi yet) | 10:20 |
| longsleep | ogra_: by the way, mu odroidc oem new version is still not reviewed, any idea how to get this going> | 10:22 |
| longsleep | ? | 10:22 |
| ogra_ | lets get sergio on it once he shows up | 10:23 |
| longsleep | it could be a issue as well, it is in published state and a new version was uploaded. Maybe there is no notifications as the snap is not in pending review state | 10:24 |
| ogra_ | we'll see what he says | 10:25 |
| ogra_ | worst case we'll get beuno to fix it :) | 10:25 |
| longsleep | and i noticed another inconsistency in the store, I have two snaps now, but i see only one /dev/click-apps and both in /dev/click-apps/?format=snap | 10:26 |
| longsleep | (and the oem snapp also shows up for /dev/click-apps/?format=click) | 10:27 |
| ogra_ | hmm, i see all my 60 click apps without the format snap thingie | 10:27 |
| ogra_ | and with it i see the snaps | 10:27 |
| ogra_ | clikc will hopefully not persist for to long anymore though | 10:28 |
| longsleep | it seems that one only sess click apps by default and the oem snap is counted as format=click and format=snap | 10:28 |
| ogra_ | so this will solve itself :) | 10:28 |
| kivi | snappy-tools still a thing? Its not on 15.10 | 11:06 |
| ogra_ | kivi, what do you mean by that ? snapppy-tools is a PPA that contains the tools we use | 11:13 |
| kivi | ogra_, okay thanks | 11:13 |
| ogra_ | (ubuntu-device-flash for example) | 11:13 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/tools | 11:13 |
| ogra_ | the tools themselves should all be in 15.10 | 11:13 |
| ogra_ | the PPA has backports for older releases | 11:14 |
| kivi | ogra_, ah | 11:14 |
| kivi | okay | 11:14 |
| kivi | sorry, just following a tutorial for making python snaps, and the apt-get did not mention the ppa | 11:14 |
| ogra_ | ah | 11:14 |
| longsleep | sergiusens: Hey, any chance you can review the new version of https://myapps.developer.ubuntu.com/dev/click-apps/2822/ at some point. I uploaded a new version a week ago and i am not sure if anyone did see that. | 11:56 |
| sergiusens | longsleep: sure, I'll add to my TODO | 11:57 |
| longsleep | sergiusens: great thanks | 11:58 |
| dholbach | can somebody review https://code.launchpad.net/~dholbach/snapcraft/doc-fixes/+merge/267010? (just syntax fixes) | 12:15 |
| longsleep | dholbach: not sure if it helps if someone from the community approves but i did it because all those special characters needs to go away asap and you merge just did that :) | 12:20 |
| dholbach | longsleep, we're all part of the community :) | 12:21 |
| dholbach | can somebody review https://code.launchpad.net/~dholbach/snapcraft/docs-next-steps/+merge/267019 too? :) | 12:32 |
| dholbach | longsleep, sergiusens, elopio, merged now - thanks for the reviews | 13:15 |
| sergiusens | longsleep: hey, ogra_ tells me you've used snapcraft to build armhf snaps, did you do that on native armhf env? | 13:19 |
| dholbach | dpm, I'll put the snapcraft docs online in a bit - we should be ready to go | 13:19 |
| dholbach | and another one: https://code.launchpad.net/~dholbach/snapcraft/rename-tutorial-file/+merge/267031 :) | 13:40 |
| elopio | zyga: the snapcraft tests print lots of warnings. Any tips to clean it up? | 13:46 |
| * dholbach hugs elopio | 13:48 | |
| elopio | :) | 13:48 |
| longsleep | sergiusens: no - i wrote my own plugin which allows to pull in built deb files into the snap. That way i can build any deb using pbuilder for any target platform and just create a snap with those. | 13:49 |
| longsleep | sergiusens: if you want to review/comment: https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650 | 13:49 |
| zyga | elopio: can you pastebin something? | 13:49 |
| zyga | elopio: I'll help you out | 13:49 |
| longsleep | sergiusens: Or you can also comment on https://bugs.launchpad.net/snappy/+bug/1480144 which tries to cover the whole picture | 13:50 |
| ubottu | Launchpad bug 1480144 in Snappy "Snapcraft should be able to run in clean environment with pbuilder/cowbuilder" [Undecided,New] | 13:50 |
| elopio | zyga: http://paste.ubuntu.com/12006977/ | 13:51 |
| zyga | elopio: so for the leftover thing | 13:52 |
| zyga | elopio: I can quickly add a flag that will say the job is expected to dirty the temporary working directory (it's not default before it was often a bug on our part in the old jobs) | 13:52 |
| zyga | elopio: and you can use that flag to get rid of those parts | 13:53 |
| longsleep | sergiusens: so the deb packages i need in the snap are built on a build system for the target platform and snapcraft runs afterwards, using the produced deb files. The debs plugin also can pull in deb files from URL locations to make it easy to test. | 13:53 |
| zyga | elopio: is there anything else you'd like to change there specifically? | 13:53 |
| zyga | elopio: can you file a bug on that (tag it 'snappy') and I'll try to fix it ASAP | 13:53 |
| zyga | elopio: we should sync next week, I have some interesting bits coming that should be able to help you a lot | 13:54 |
| elopio | zyga: I tought first about making the snapcraft build out of the working directory, but if you thing the flag would be better lets do it. | 13:54 |
| elopio | zyga: other than that, I would like to have subunit test results. | 13:55 |
| zyga | elopio: mmm, another bug, if you show me a simple snippet of python that does that (create some result object, set data, etc,) then I can write that today as well | 13:56 |
| zyga | elopio: so both on the "plainbox" project and both with "snappy" tag pretty please | 13:58 |
| elopio | zyga: ok. | 13:58 |
| elopio | about a simple snippet, it depends on how your test suites are implemented. | 13:59 |
| zyga | elopio: mmm | 13:59 |
| elopio | If you are using a test runner, just replace it with the subunit test runner. https://bazaar.launchpad.net/~subunit/subunit/master/view/head:/README.rst | 13:59 |
| zyga | elopio: the way I understand it you could ask plainbox to exports results to subunit format | 13:59 |
| zyga | elopio: maybe I misunderstand what subunit is | 13:59 |
| * zyga looks | 14:00 | |
| elopio | zyga: you can convert to subunit after the fact, or you can make a subunit stream and fill it while the tests are running. | 14:00 |
| elopio | the stream is nicer, but both work. | 14:00 |
| elopio | mterry: any clues about what's wrong here? http://paste.ubuntu.com/12007001/ | 14:01 |
| elopio | that's the simple-cmake integration tests running from adt-run. | 14:01 |
| zyga | elopio: mmmm | 14:01 |
| zyga | elopio: the former is easy, streaming is harder but we could do it with the new API that I worked on | 14:01 |
| zyga | elopio: it would not be a new exporter format | 14:02 |
| zyga | elopio: but a small tool that uses stable, public plainbox APIs and subunit to stream stuff | 14:02 |
| zyga | elopio: that's the thing I was talking about earlier (new shiny stuff == public api) | 14:02 |
| elopio | fgimenez: with one command, I magically have a snappy jenkins running :) | 14:03 |
| elopio | zyga: sounds good. | 14:03 |
| fgimenez | elopio, great! :) | 14:03 |
| elopio | so, feel free to join us next week, any time you want. | 14:03 |
| mterry | elopio, cc is broken... | 14:04 |
| mterry | :( | 14:04 |
| mterry | elopio, can I see those logs it mentions? | 14:05 |
| elopio | mterry: the thing is that if I ssh into the machine and run it, it works. | 14:05 |
| elopio | mterry: you can, but I need like 15 minutes. This is slow. | 14:05 |
| elopio | mterry: are we going to have snapcraft in the archive soon? | 14:06 |
| longsleep | mterry: Do you have any more comments on my snapcraft debs plugin? https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650 - Do you think something like this makes sense to upstream to you guys? | 14:09 |
| mterry | elopio, I can upload it to the archive, when we think it's ready. rsalveti, do we think it's ready? :) | 14:10 |
| rsalveti | mterry: elopio: we can upload to the archive already, sure | 14:12 |
| mterry | longsleep, sorry for slow reply :) | 14:12 |
| mterry | longsleep, so your use case is sort of a workaround the fact that we don't have cross building. Plus an emphasis on making sure you have the exact version you want | 14:13 |
| mterry | rsalveti, ok, can upload to wily later today then | 14:13 |
| mterry | elopio, ^ | 14:13 |
| longsleep | mterry: yes - the cross building might go away in the future, but i still need to build in clean environment (which is provided by pbuilder for deb file) | 14:13 |
| longsleep | mterry: From my point of view, this was the easiest way to build a snap from existing deb files. It was even easy to add another deb file as i found i had to ship openssl binary inside my snap. | 14:16 |
| ted | Could we build an ARM Snappy image that's like this one: https://fedoraproject.org/wiki/Architectures/ARM/F22/Installation#For_Versatile_Express_Emulation_with_QEMU | 14:16 |
| mterry | longsleep, it seems like you may have dependency problems a lot with this strategy | 14:16 |
| longsleep | mterry: i also have the idea that this could be extended to build multi arch snaps by creating sub folders per arch and extract the corresponding deb files to this subfolders and detect the arch in start script. | 14:17 |
| longsleep | mterry: Yes, it does not resolve dependencies automatically. Though the developer writing the snap file can resolve those manually. | 14:17 |
| mterry | longsleep, if we had cross building support, would pointing at a git branch with a tag be enough of reproducable build for you? | 14:19 |
| guest42345 | how big is ubuntu personal image? i want to try it from USB | 14:19 |
| mterry | dholbach, why did you remove my utf8 characters from the docs? | 14:20 |
| mterry | They were so pretty | 14:20 |
| longsleep | mterry: No, reproducable builds need to pull and install dependencies required at compile time. Thus i would always go through a debian package to have reproducable builds. | 14:20 |
| dholbach | mterry, when I ran markdown on the file, the output wasn't pretty | 14:21 |
| ogra_ | guest42345, a month ago the img that ubuntu-device-flash produced was 9GB | 14:21 |
| longsleep | mterry: dpkg gives that all, i think it will a lot of work to replicate that within snapcraft | 14:21 |
| ogra_ | not sure if it changed | 14:21 |
| mterry | elopio, your makedirs branch failed to merge | 14:21 |
| elopio | wtf, simple cmake passed now. | 14:21 |
| longsleep | mterry: alternative would be to run snapcraft in pbuilder environment and have it produce a snap instead of deb | 14:21 |
| guest42345 | ogra_, thanks :> that's pretty BIG! i have a tiny 4G USB stick, i guess it's time to buy new ones | 14:22 |
| mterry | longsleep, that would be something we'd expect would work | 14:22 |
| mterry | dholbach, markdown doesn't handle utf8? shocking... | 14:22 |
| guest42345 | ogra_, so.. for now there is no way to install ubuntu personal on a diff partition, right? | 14:22 |
| guest42345 | i can't have ubuntu 14.04 and ubuntu personal on the same hdd | 14:23 |
| elopio | mterry: let me check tarmac. | 14:23 |
| longsleep | mterry: well thinking anbout it .. that will not work because that environment mit not be able to compile all the stuff in one shot. It would need to setup a environment for each dependency. I think that is too complicated. | 14:23 |
| ogra_ | guest42345, there surely is a way to dd the img file to some other device from a live-booted system or so | 14:23 |
| ogra_ | but yeah, you would need to overwrite the whole device ... there is no dual boot or anything | 14:23 |
| longsleep | mterry: I think lots of people might like to simply extract their deb files into a snap and add a start script. That is simple and people need to know about their dependencies only. | 14:24 |
| ogra_ | (and snappy is really not designed for something like that) | 14:24 |
| sergiusens | longsleep: We’ve been working on adding support for building snap packages (#1476405), but there’s still more to do here; we should be able to make this available to some alpha testers around mid-August | 14:24 |
| sergiusens | http://blog.launchpad.net/general/launchpad-news-july-2015 | 14:24 |
| sergiusens | https://bugs.launchpad.net/launchpad/+bug/1476405 | 14:24 |
| ubottu | Launchpad bug 1476405 in Launchpad itself "Add support for building snaps" [High,In progress] | 14:24 |
| sergiusens | mterry: to build for armhf I'd need native/emulated arm, right? | 14:25 |
| longsleep | sergiusens: launchpad building snaps would be nice. | 14:25 |
| guest42345 | ogra_, thanks, that's what i thought.. i don't know how to feel about it | 14:25 |
| guest42345 | ogra_, i need some beer :)) thanks again | 14:25 |
| longsleep | sergiusens: lots of stuff does not build on emulated arm | 14:25 |
| ogra_ | enjoy the beer :) | 14:26 |
| guest42345 | mmmm delicious | 14:26 |
| longsleep | sergiusens: that is why we have a arm build cluster here, though that only supports pbuilder | 14:26 |
| sergiusens | longsleep: oh, I know... I hate it, I'm just avoiding pedantic people clarifying that it could be done with qemu-arm-static | 14:26 |
| sergiusens | :-P | 14:26 |
| longsleep | sergiusens: so, when you have launchpad building snaps, i suppose you will activate armhf only upon request similar as for debs? | 14:28 |
| mterry | sergiusens, yeah | 14:30 |
| ogra_ | sergiusens, did you just call me pedantic ? | 14:31 |
| ogra_ | :P | 14:31 |
| tasdomas | does the orange box mac address change on reboot? | 14:32 |
| ogra_ | tasdomas, yes, working on a fix, a new image should be ready before end of the week | 14:32 |
| ogra_ | (the current bootloader setup swallows the MAC and serial of the rpi) | 14:33 |
| longsleep | mterry: So explaining my current use case: I have clean built spreed-webrtc deb packages and want to make a snap out of it. | 14:33 |
| mterry | longsleep, I follow... Hrm, let me look at MP again | 14:34 |
| mterry | longsleep, thanks for explaining to me | 14:34 |
| longsleep | mterry: Sure - with that suff i was able to add the snap to the store, so either nobody is as crazy as me yet or everyone sets up a clean build system for every build :) | 14:35 |
| sergiusens | mterry: I notice that easy install/py2 rewrites the shebang to my local machine; any way around that? (thinking of my binary entry calling out python2 explicitly) | 14:36 |
| mterry | sergiusens, easy install/py2? | 14:36 |
| longsleep | sergiusens: by the way, any chance that at some point Go can be built by launchpad on armhf: https://launchpadlibrarian.net/207704013/buildlog_ubuntu-trusty-armhf.golang_2%3A1.4.2-1%2Bstruktur0%2Btrusty0_BUILDING.txt.gz ? | 14:39 |
| sergiusens | mterry: setuptools/easy_install/python 2 | 14:39 |
| sergiusens | mterry: did you see my diff? | 14:39 |
| sergiusens | mterry: http://paste.ubuntu.com/12006412/ | 14:40 |
| longsleep | sergiusens: We have all the gear on lp to provide debs for armhf but go builds crash with Segmentation fault | 14:40 |
| sergiusens | mterry: I think I just duplicated some work there | 14:40 |
| sergiusens | longsleep: oh, you are using virtual builders I guess | 14:40 |
| longsleep | sergiusens: yes | 14:40 |
| sergiusens | longsleep: I don't know a way out of that | 14:41 |
| longsleep | sergiusens: i mean it is not a big deal as we build locally as well, though i think Golang should be buildable for all platforms on launchpad :) | 14:41 |
| === vrruiz_ is now known as rvr | ||
| ted | mterry, So, on your comment to rename ubuntu.package to just ubuntu.packages everywhere... I'm not against that, but I'm curious if it'll break too many folks at this point. | 14:45 |
| ted | mterry, Perhaps we change the plugin yaml and take both | 14:45 |
| mterry | ted, and warn on both being used maybe? | 14:45 |
| mterry | ted, I mean error out I guess | 14:45 |
| ted | Yeah, I'm fine warning in that it will *work* | 14:46 |
| mterry | ted, are there too many people now? | 14:46 |
| * ted assumes everyone is using snapcraft now | 14:46 | |
| sergiusens | mterry: I seem to be able to get away with it with 'binaries:\n name: python ./usr/bin/app' | 14:46 |
| ted | IBM is probably already working on an XML schema for it. | 14:46 |
| mterry | sergiusens, yeah, snapcraft has special logic (thanks to ted) to repurpose your 'python' call to the internal python | 14:47 |
| mterry | ted, I bet it's fine to break world | 14:47 |
| mterry | :) | 14:47 |
| ted | K, I'll break 'em ;-) | 14:47 |
| mterry | ted, as long as we error on unknown options? I don't think we do yet | 14:48 |
| mterry | ted, maybe add that to your branch too? | 14:48 |
| mterry | ted, OR.... have a warning saying it's deprecated but still accept it | 14:48 |
| ted | mterry, Well I was just gonna require packages | 14:48 |
| mterry | ted, and error out if both are used | 14:48 |
| mterry | ted, fair on requiring packages, forgot that detail | 14:48 |
| mterry | ted, oh wait, you don't get to auto-infer package name? | 14:48 |
| mterry | ted, I loved that feature | 14:49 |
| mterry | was I the only one? | 14:49 |
| sergiusens | mterry: you mean the magic symlinking? | 14:49 |
| mterry | sergiusens, hrm? | 14:49 |
| sergiusens | mterry: you sai special logic | 14:49 |
| ted | mterry, Heh, not sure it's really practical. Doubt anyone will have a single package that often. | 14:49 |
| dholbach | dpm, mterry, rsalveti: https://developer.ubuntu.com/en/snappy/snapcraft/ - it's not auto-imported yet, nor announced anywhere | 14:50 |
| mterry | sergiusens, oh no, we change how we wrap your binary call to make your 'python' bit be found (normally snappy binary paths are relative paths to the executable in the snap, not PATH-resolved commands) | 14:50 |
| mterry | ted, what, you're crazy | 14:50 |
| sergiusens | mterry: this is what I have now http://paste.ubuntu.com/12007310/ but if I specifically launch as 'python app' I can get around the broken shebang | 14:50 |
| rsalveti | dholbach: nice | 14:51 |
| * sergiusens starts the trek back home | 14:51 | |
| mterry | elopio, in your dep8 branch, why not just run the unit tests too? If they end up being broken (by unittests api changing or wget being broken), we'd want to know about that as well. At the least it means snapcraft would ftbfs on a rebuild | 14:52 |
| elopio | mterry: the unit tests are run when the deb package is built. | 14:57 |
| elopio | then it is installed, and we run the test-as-installed, the dep8. | 14:57 |
| elopio | if we put the unit tests in dep8 they would run twice. | 14:57 |
| mterry | elopio, yup. But when a depends of snapcraft is uploaded, snapcraft's dep8 tests are run. And we want the unit tests run then too | 14:58 |
| elopio | mterry: ok, that makes sense I think. Do you want to keep the integration-tests/runtests.sh script, or should I merge it back? | 15:00 |
| mterry | elopio, I'm fine with those split sure | 15:00 |
| elopio | now if only it passed... | 15:01 |
| kyrofa | Hey ogra_ any update on the rpi2 i2c and gpio stuff? | 15:25 |
| ogra_ | kyrofa, on it ... right now :) | 15:25 |
| ogra_ | (some blockers showed up that i had to fix first) | 15:25 |
| longsleep | qjkc | 15:26 |
| longsleep | err sorry | 15:26 |
| kyrofa | ogra_, awesome! I have to work up a demo by this time next week. Do you suggest waiting for i2c for my plan A, or start working on my plan B? | 15:26 |
| longsleep | quick question, how does the snappy tool access the store, where does the configuration come from> | 15:26 |
| longsleep | ? | 15:26 |
| ogra_ | kyrofa, i should have some image for testing later tonight or tomorrown morning | 15:27 |
| kyrofa | ogra_, ah! Okay, I'll wait :) | 15:27 |
| ogra_ | you will still have to hack something if you want to use overlay dtb's though, since i dont expect the needed udf fix to land in time for that | 15:27 |
| ogra_ | (unless sergiusens secretly developed something i dont know about ) | 15:28 |
| kyrofa | ogra_, I'm fine hacking stuff to work as long as you're willing to guide me... ? | 15:28 |
| ogra_ | sure, np | 15:28 |
| kyrofa | longsleep, it hits system-image.ubuntu.com, using the image channel and device to build the URL | 15:30 |
| kyrofa | longsleep, well, that's what happens when I try to update the index anyway | 15:31 |
| longsleep | kt | 15:31 |
| longsleep | kyrofa: yes | 15:31 |
| longsleep | kyrofa: but how does it find and download snaps? | 15:31 |
| kyrofa | longsleep, it's the same store as clicks | 15:32 |
| longsleep | kyrofa: ok - but where does the URL come from? | 15:32 |
| === chihchun is now known as chihchun_afk | ||
| longsleep | kyrofa: i found the configuration for the system image - but no luck for the store yet | 15:33 |
| kyrofa | longsleep, snappy/snapp.go: https://search.apps.ubuntu.com/api/v1/ | 15:33 |
| longsleep | kyrofa: thanks! i am just blind obviously | 15:34 |
| kyrofa | longsleep, no problem! | 15:34 |
| kyrofa | Hey ogra_ got a sec for a framework question? | 15:42 |
| ogra_ | not sure i can answer it, but sure, shoot :) | 15:43 |
| kyrofa | ogra_, well with my (limited) understanding of frameworks, I felt that apache or nginx should be frameworks, but you felt differently which means you obviously know more about them than I do :P | 15:44 |
| kyrofa | So I have something else I feel should be a framework, and wanted to bounce it off of you | 15:44 |
| kyrofa | ogra_, are you familiar at all with ROS? | 15:45 |
| mterry | elopio, have you tried your new dep8 branch in a chroot? I'm guessing that @ isn't enough to cover all the deps you need (it's only run time deps, not build time deps, right?). Like it won't have python3-testscenarios, needed for the unit tests | 15:45 |
| ogra_ | only via reading about it :) | 15:45 |
| elopio | mterry: I've added them, let me push. | 15:46 |
| kyrofa | ogra_, that's probably good enough. ROS Core is the hub of the star-like message architecture, with various clients connecting to the core in order to learn about other clients and pass messages around | 15:46 |
| elopio | still, I can't get it to pass. Errors range from unable to install all the deps to gcc not found. | 15:46 |
| kyrofa | ogra_, would ROS Core make | 15:46 |
| elopio | I'll put it back to work in progress. | 15:46 |
| kyrofa | ogra_, a good framework? | 15:46 |
| kyrofa | ogra_, since there can only be one that all clients must share | 15:47 |
| ogra_ | yeah, but i'm not the master of frameworks or even their definition ... to me ROS definitely looks like a good framework but i'm guessing as much as you here :) | 15:47 |
| mterry | elopio, you can do @builddeps@! I didn't know that before now | 15:47 |
| elopio | mterry: right, but in the docs it says we should probably not use it. | 15:48 |
| mterry | elopio, that could be your entire line. Depends: @builddeps@ | 15:48 |
| kyrofa | ogra_, alright, thank you! I just wanted to get your impression before I looked any further | 15:48 |
| ogra_ | our framework definition definitely needs a better description of what a framework is or can be | 15:48 |
| kyrofa | ogra_, agreed... a bit muddy | 15:48 |
| mterry | elopio, hmph | 15:48 |
| ted | mterry, Okay, pushed the 'packages' changes. It required a bunch of changes in different places, but not as big of a diff as I was worried about. | 15:53 |
| sergiusens | mterry: git@github.com:sergiusens/galileo.git | 15:56 |
| elopio | s/dep8/pep8. /me needs sun light. | 15:58 |
| longsleep | kyrofa: I think that Nginx should be a framework as well. But i have no idea about what a framework is supposed to be :) | 16:01 |
| kyrofa | longsleep, ogra_ who knows that stuff? Or is it still being fleshed out? | 16:03 |
| ogra_ | kyrofa, i guess one of the architects (lool perhaps) could shed more light on it for you | 16:04 |
| longsleep | ogra_, kyrofa : Yes lool had some ideas about this a couple of days ago. I think his suggestion was just to move forwards and see how it goes. | 16:12 |
| ogra_ | lol | 16:12 |
| ogra_ | right | 16:12 |
| ogra_ | diplomacy FTW :) | 16:12 |
| kyrofa | longsleep, that's potentially brutal advice :P | 16:13 |
| longsleep | well the stuff is fresh - so whoever comes first defines the standard :P | 16:14 |
| kyrofa | longsleep, or goes to the effort of trying it only to get told "that's not how we use frameworks," heh | 16:15 |
| longsleep | kyrofa: well yest - but if you have the need to do it exactly that way and it is not possible with the existing definition the world needs to expand | 16:15 |
| longsleep | i like the idea to see how it goes | 16:16 |
| longsleep | and i need a Nginx framework as well and i might go forward with writing one, or i add Nginx to my system image .. | 16:16 |
| longsleep | probably a bad idea :D | 16:17 |
| longsleep | ogra_: I am back to resarch on system image building. What i understand is that i should run ubuntu-cdimage with http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/live-build/ubuntu-core/ hooks - does that make sense? | 16:23 |
| ogra_ | longsleep, no. you really dont want to run ubuntu-cdimage :) | 16:24 |
| ogra_ | what you want to run is live-build with the changes from the livecd-rootfs package applied | 16:24 |
| ogra_ | (this is essentially all that ubuntu-cdimage would do) | 16:24 |
| longsleep | ok - what is live-build ? another couple of scripts? | 16:25 |
| ogra_ | longsleep, https://code.launchpad.net/~ogra/project-rootstock-ng/trunk | 16:25 |
| longsleep | ogra_: awesome thanks | 16:25 |
| ogra_ | look at the rootstock-touch script ... it essentialyl does what a buildd does | 16:25 |
| ogra_ | (note also that it cant build wily for core currently, but vivid works ... just takes ages) | 16:26 |
| ogra_ | it shoudl give you an idea ... | 16:26 |
| longsleep | ogra_: well i have gear to build a rootfs for normal Ubuntu already. Do you think it would make sense to start from that and just apply the changes for snappy? | 16:28 |
| ogra_ | no, it wouldnt, it would make sense to just use -core as is and make your changes in the snaps ... or to ask us to add/remove bvits from core as needed | 16:28 |
| longsleep | ogra_: yes - but not everything can be done in snaps and not everything should be in core. Some things are specific to a single device. I still fail to see how that can work without modification of the boot process or other things in core. | 16:30 |
| ogra_ | via unconfined snaps for example | 16:31 |
| longsleep | mhm - could i overwrite stuff from the base system? That sounds iffy on update | 16:31 |
| ogra_ | the plan is that you have a gadget snap for your appliance ... that is the only snap that can actually have dependencies -... | 16:31 |
| ogra_ | these dependencies would be your add-on snaps that enhance core | 16:31 |
| longsleep | all right - i think i can try that | 16:32 |
| ogra_ | in any case you should never need to modify core | 16:32 |
| longsleep | what if i want to use another system image server, or even another api endpoint for the store? | 16:32 |
| ogra_ | if you have to, we either have to much or not enough functionality in core :) | 16:32 |
| longsleep | like a self controlled one, or a local one | 16:33 |
| ogra_ | system-image will go away soon, it will only be the store | 16:33 |
| ogra_ | (core will become a snap too) | 16:33 |
| ogra_ | and for the store bits i can point to beuno :) as usual :) | 16:33 |
| longsleep | hehe - well i will be among the first to test all this once it is available - in the meantime i will experiment | 16:34 |
| sergiusens | mterry: is the source_type key in yaml source_type as well? | 16:46 |
| elopio | mterry: this is the only remaining failure: http://paste.ubuntu.com/12007972/ | 16:47 |
| elopio | the message is not useful, and when I ssh into the machine, extract the tar and run make, it just works. | 16:48 |
| beuno | longsleep, the store's endpoint won't be changeable (and isn't) | 17:09 |
| mterry | sergiusenswhat was that about source-type in yaml? | 17:13 |
| mterry | elopio, yeah, that looks like gcc failing... | 17:13 |
| mterry | sergiusens, what was that about source-type in yaml? | 17:13 |
| elopio | mterry: how can we print the error? I added gcc -v, but no output on is printed. | 17:16 |
| mterry | elopio, it might be crashing? | 17:17 |
| sergiusens | mterry: ah, thanks | 17:24 |
| * sergiusens wants a schema | 17:24 | |
| mterry | sergiusens, well the source-type stuff is plugin-specific (though shared between a lot of plugins, granted) | 17:26 |
| sergiusens | mterry: we probably want to document those anyways | 17:28 |
| sergiusens | mterry: I have to argue that it is not plugin specific as it is part of PluginsBase ;-) | 17:33 |
| sergiusens | even if private | 17:33 |
| sergiusens | mterry: anyways that's me arguing about nothing important :-) | 17:34 |
| mterry | sergiusens, well the CODE is shared. But plugins can expose/parse the option how they like. We just have helpers. But yes, they are so common as options, we should document them | 17:34 |
| sergiusens | mterry: care to look at https://code.launchpad.net/~sergiusens/snapcraft/mercury/+merge/267080 ? | 17:34 |
| mterry | ted, don't you think all those packages: [onething] lines are grosser than the implicit package? | 17:53 |
| sergiusens | mterry: hey, there isn't much of a test base for code checkout; I need to remember how to mock to mock the run commands; maybe elopio can help template that for bzr/hg/git pull | 18:16 |
| ted | mterry, I think that they are uglier, but I guess I see it as an exception more than the rule. The examples are simpler than most projects. | 18:20 |
| ted | mterry, I'd be happy to put back the implicit package if you feel strongly though. | 18:20 |
| mterry | ted, so there are two major types of projects: ones that use parts as dependencies and 'integration' projects that pull things together. In integration projects, you'll want toplevel packages like 'apache2' or whatever. Or fswebcam in examples. Logically distinct, toplevel parts. I think for those it makes sense for the implicit syntactic sugar | 18:25 |
| mterry | sergiusens, doesn't that already exist in test_base_plugin? we do something with bzr there | 18:25 |
| sergiusens | mterry: I only see error checks for setting branch in bzr and the most complex test there is pull_tarball | 18:26 |
| mterry | sergiusens, yeah... Ok. So maybe just add error checks for yours. Unless you feel fancy and want to mock hg | 18:28 |
| sergiusens | mterry: I'd rather have elopio write me a template ;-) | 18:29 |
| sergiusens | mterry: and I did convert the git/hg into a scenario based test class for errors | 18:29 |
| mterry | sergiusens, and you've tested this I assume on real hg branches? | 18:30 |
| mterry | sergiusens, ooh wait | 18:30 |
| mterry | sergiusens, the integration-tests have some live git/bzr tests. hg would be good to add to that, to confirm we don't break cloning or updating | 18:30 |
| sergiusens | mterry: yes, I already replaced my codebase | 18:31 |
| sergiusens | mterry: oh, and --user + --root (instead of --prefix doesn't require a PYTHONPATH, I haven't tested if it produces anything that works yet) | 18:31 |
| sergiusens | mterry: sure, I will add an integration-test | 18:32 |
| sergiusens | oh, I need a newer plainbox | 18:32 |
| sergiusens | mterry: what was the ppa I needed for that? | 18:32 |
| mterry | sergiusens, ppa:hardware-certification/public (from HACKING.md) | 18:33 |
| sergiusens | mterry: silly me, I only search for 'plainbox' | 18:33 |
| sergiusens | thanks | 18:34 |
| ted | mterry, implicit package is back :-) | 18:43 |
| * mterry dances | 18:43 | |
| ted | mterry, What did you do to work around the store not supporting architectures | 20:08 |
| ted | ? | 20:08 |
| * beuno squints | 20:09 | |
| beuno | not supporting architectures? | 20:09 |
| ted | beuno, The 'architectures' key in the yaml | 20:09 |
| beuno | ah | 20:09 |
| beuno | the store doesn't look at the yaml | 20:09 |
| beuno | it looks at the json | 20:09 |
| beuno | that is created on build time | 20:09 |
| ted | Oh, interesting. | 20:10 |
| beuno | it still treats it as a click | 20:10 |
| ted | Everyone uses JSON :-) | 20:10 |
| mterry | ted, used architecture instead | 20:10 |
| ted | mterry, Can that be an array? | 20:10 |
| mterry | ted, I think so? | 20:10 |
| ted | K | 20:10 |
| rsalveti | ted: how is the qml mr going? | 20:12 |
| * ted is trying to make mterry happy :-) | 20:12 | |
| rsalveti | :-) | 20:12 |
| mterry | hmm.. i should look at that again | 20:12 |
| mterry | I think it's ready | 20:12 |
| * ted buys flowers | 20:13 | |
| mterry | ted, run ./runtests.sh | 20:16 |
| mterry | ted, need to update test_get_all_dep_packages_with_unrecognized_package | 20:16 |
| ted | mterry, "Everything passed" | 20:17 |
| mterry | ted, merge from trunk then? | 20:17 |
| ted | Ah, K, that breaks it :-) | 20:18 |
| ted | mterry, Updated | 20:19 |
| sergiusens | mterry: updated the mercurial branch (took longer than expected) | 20:43 |
| sergiusens | I also played a bit with --user and such, but everything goes bonkers wrt to path rewrites | 20:43 |
| ogra_ | rsalveti, that livecd-rootfs stuff slowly turns into an all nighter :( | 20:47 |
| mterry | Uploaded initial version of snapcraft to wily! | 20:50 |
| ogra_ | \o/ | 20:50 |
| ted | *snap* ! | 20:51 |
| mterry | ted, your qml plugin made it | 20:53 |
| ted | Oh, cool. | 20:54 |
| ted | Are the docs live? | 20:54 |
| ted | I should put links in my blog post and get that out. | 20:54 |
| rsalveti | ogra_: oh crap | 20:58 |
| * rsalveti hugs ogra_ | 20:58 | |
| rsalveti | mterry: nice | 20:58 |
| mterry | ted, it hasn't landed in wily yet, has to be manually approved since it's a new package | 20:59 |
| mterry | ted, I don't know if docs are live | 20:59 |
| davmor2 | ogra_: like you need sleep | 21:00 |
| ogra_ | davmor2, :P | 21:03 |
| davmor2 | ogra_: you know you're not happy unless you wake up the shapes of keys imprinted on the side of your face ;) | 21:04 |
| ogra_ | yup, if they are not there my GF doesnt actualy recognize me anymore | 21:05 |
| davmor2 | ogra_: or wants to know what you've been up to :) | 21:05 |
| ted | Seems like there's no way to specify a service with a timer, to start it hourly or whatever | 21:08 |
| ted | Is that on purpose or just not got there yet? :-) | 21:08 |
| * ogra_ triggers another phone image and goes afk for a bit | 21:19 | |
| ogra_ | phew, finally | 22:38 |
| sergiusens | elopio: mind checking https://code.launchpad.net/~sergiusens/snapcraft/mercury/+merge/267080 ? | 22:57 |
| ogra_ | slangasek, did you see my PM from earlier today (no action needed right now, i just want to make sure the question got through to you) | 23:00 |
| elopio | sergiusens: looks good. But you are missing the data dirs. | 23:01 |
| elopio | cp: cannot stat ‘/home/elopio/workspace/canonical/snapcraft/reviews/sergiusens/mercury/integration-tests/data/hg-head’: No such file or directory | 23:02 |
| sergiusens | elopio: err, let me bzr add! | 23:03 |
| slangasek | ogra_: hi - yes, I did; the whole thing looks fine to me, so I wasn't sure what needed commenting on | 23:11 |
| ogra_ | slangasek, ah, cool, i just didnt want to say yes or no without feeling qualified enough | 23:12 |
| ogra_ | slangasek, mainly marks comment of using a new distributor ID for snappy | 23:12 |
| ogra_ | (instead of "Ubuntu" ... ) | 23:13 |
| slangasek | so it's possible that third-party things may make assumptions about the values of these field | 23:13 |
| slangasek | s | 23:13 |
| slangasek | but those things are likely not looking at the snappy one | 23:13 |
| ogra_ | ok | 23:14 |
| sergiusens | elopio: there we go (network was slow) | 23:18 |
| sergiusens | elopio: I don't mind a top approve ;-) | 23:21 |
| elopio | sergiusens: let me run the tests. | 23:22 |
| elopio | sergiusens: I like that you left the error conditions for unit tests, and the snapcraft command for integration. | 23:23 |
| elopio | any thoughts about writing tests for snapcraft? | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!