=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:57] good morning [07:13] good morning [08:32] Good morning all; happy Work Like A Dog Day! 😃 [08:41] 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] or was that kernel only (which wouldnt help for plain u-boot indeed) [08:42] ogra_: hi [08:42] uhm [08:42] oh joy - cant you guys get rid of the rpi bootloader? [08:42] nope [08:42] :/ [08:42] pi cant boot without it [08:42] uboot is just a chainloaded thing here [08:43] ogra_: i don't remember ever doing that [08:43] so it could boot without uboot then? [08:43] ogra_: let me grab my pi board [08:43] (and for the fun, all DTB overlay handling also has to happen in the blob bootloader) [08:43] yep [08:43] oh [08:43] longsleep, it could boot, but not update and rollback ... or failover [08:44] ogra_: i see - and the rpi bootloader loads something from disk itself? [08:44] ogra_: so it has fat read drivers and all itself? [08:44] yeah, it loads either uboot.bin or the kernl [08:45] (and aside from that it is also the binary GPU driver as well) [08:46] is that new for rpi2? [08:46] nope [08:46] has always been like that [08:47] 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:49] ogra_: ok - let me check one of the rpi's i have then [08:50] 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] ah yes - seems that i am not even using u-boot then [08:50] these ROM values contain the board serial and the MAC address ... [08:51] urg [08:51] i need them in my uboot env and cant get them to show up anymore [08:51] thats config.txt and cmdline.txt you are referring to? [08:51] i see these both [08:51] yeah [08:51] http://paste.ubuntu.com/11993082/ [08:51] see the "args=" line at the top [08:52] right [08:52] that comes from the bootloader (my cmdline.txt contained elevator=deadline in that case) [08:52] do you have the fixup.dat as well? [08:52] yes [08:52] i have start.elf, bootloader.bin and fixup.dat ... the configs and the respective DT [08:53] so, for you the args value are the defaults and you cannot change them> [08:53] ? [08:53] no [08:53] the args value is unset now [08:53] ah ok [08:53] it doesnt get handed over to uboot at all [08:54] 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] *check [08:55] 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] oh joy [08:55] and i think that is what i'm missin on my uboot binary [08:55] wait [08:56] i had an email about that [08:56] (we had some mail discussion about that before, thats why i asked ppisati if he still remembers) [08:56] *snap* [08:56] right [08:56] :) [08:56] but that doesnt talk about uboot at all [08:56] only about the kernel [08:56] ogra_: and in your config you set kernel=uboot.bin or something? [08:56] i need the var before the kernel is loaded [08:57] longsleep, right [08:57] the silly thing is that i had it working properly ... as you can see in the paste [08:57] 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:58] ogra_: mhm you think it is a u-boot compile time flag? [08:58] no, we didnt patch uboot much [08:58] there is the raw initrd patch, thats all (one config line) [08:59] right, so you use latest mainline u-boot for the rpi? [08:59] 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] i tried both, mailine and srwarrens tree [08:59] ogra_: do you recall the subj of that email conversation? i can't find it right now... [08:59] i dont think it is uboot [09:00] ppisati, "Snappy Core Image for Raspberry Pi" [09:00] 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] Follow the (recently updated) instructions here: https://www.raspberrypi.org/documentation/linux/kernel/building.md [09:02] uh, oh [09:02] whoah that script looks scary [09:03] ppisati, i remember there was some uboot cmdline you gave me to have the content of "0x100" stuffed into the env ... [09:03] (it slowl comes back ...) [09:03] *slowly [09:03] ah that would make sense [09:04] ogra_: i'm passing directly what i get from the rpi loader to the kernel [09:04] i can actually see the cmdline with md 0x100 [09:04] then just import it [09:05] if the rpi bootloader writes its args to 0x100 [09:14] ogra_: something like 'env import -t 0x100' [09:14] (sorry i got distracted) [09:18] longsleep, no, i found the old conversation ... it isnt an env but actually the start if the devicetreew i see with md [09:19] fdt addr 0x100 ... should theoretically work ... but gives me an error [09:19] libfdt fdt_check_header(): FDT_ERR_BADMAGIC [09:20] but i'm on the right track now so i should get it working [09:20] aha ! [09:20] Jun 16 13:32:43 ogra_: BTW, the patched uboot is here if you want to try it - http://people.canonical.com/~ppisati/uboot.raspy2 [09:20] ppisati, do you remember what you patched there ? [09:21] i think i know [09:21] let me check [09:21] yes i think it must be u-boot [09:21] (i would just take your binary but i need additional patching sadly) [09:21] right [09:21] so [09:22] ./mkknlimg --dtok ./uboot.bin.old ./uboot.bin [09:22] to get that uboot [09:23] bah, i had --dtok --283x in my last try [09:23] i guess thats it :P [09:23] so close (and just by guessin) [09:24] ogra_: [09:24] ops [09:25] U-Boot> fdt addr 0x100 [09:25] libfdt fdt_check_header(): FDT_ERR_BADMAGIC [09:25] grrr [09:26] even with the patched uboot [09:26] fdt addr 0x100 [09:26] works here [09:27] ok, forget bout that [09:27] the error looks like the dtb file is messed up ... [09:27] i was able to boot a kernel [09:27] but why would it be loaded to ram just flawless if it was [09:27] U-Boot> fdt addr 0x100 [09:27] U-Boot> run loadkernel [09:27] 4537616 bytes read in 3313 ms (1.3 MiB/s) [09:28] U-Boot> bootz ${kernel_addr_r} - 0x100 [09:28] and i got to a booted system [09:28] sure [09:28] i'm far from that point ... i need the values in my uboot env to assmeble a proper cmdline first :) [09:28] then i'll care for booting :) [09:29] i guess i should start over from a clean state [09:35] U-Boot> fdt addr 0x100 [09:35] U-Boot> fdt get value serial /system linux,serial [09:35] U-Boot> echo ${serial} [09:35] 000000001cdb048b [09:35] \o/ [09:36] yippie !! [09:36] U-Boot> fdt get value args /chosen bootargs [09:36] U-Boot> printenv args [09:36] 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] there we go [09:38] what did you change? [09:38] and what do you use the serial for? [09:38] i used ./mkknlimg --dtok on the uboot binary ... and actually copied the dtb files freshly in [09:39] the serial is needed if you want to buy the video codecs [09:39] ah yes [09:39] so it must be set in /proc/cpuinfo [09:39] and indeed you want the persistent MAC [09:39] do you know how the bootloader generates it? [09:39] from msc95xx.macaddr=B8:27:EB:04:DB:1C [09:40] afaik the first stage loader reads it from ROM [09:40] mhm you think they fuse it on the chip? [09:41] 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:43] 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:44] yeah, hard to tell ... that bootloader is a blackbox [09:46] yes - closed source bootloaders make me sad [09:54] ogra_: cool [09:54] ppisati, thanks a lot ! [09:54] ogra_: how do you make printenv print on different lines? [09:54] ogra_: i totally forgot about all this stuff [09:54] ogra_: i mean, instead of clobbing a single line [09:54] me too, thats was my prob for the last three days :P [09:54] * ogra_ is banging his head against that since friday [09:55] poor friday [09:55] ppisati, i dont do anything, printenv has a newline at the end of each line here [09:55] uhm [09:55] not here [09:55] * ppisati sad panda [09:55] what terminal do you use ? [09:56] screen /dev/ttyUSB0 115200 ... [09:56] minicom [09:56] let me try screen [09:56] that gets me poper terminal shaped output [09:57] (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] so you have a host in betweeb? [09:57] *between [09:57] not atm [09:57] but i can if needed/wanted [09:57] i mean, i can detach too [09:58] anyhow [09:58] let me try screen [09:58] fuck [09:58] it works [09:58] well, screen keeps the terminal up but detaches the tty ... so i can switch machines [09:58] indeed :) [09:59] * ogra_ gave up on all other terminal emulators years ao [09:59] *ago [10:00] i've always used cu [10:00] then minicom since i have problems with cu and some boards [10:01] 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:02] 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:03] 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] ogra_: well, not directly used by my snap, but iperf like other tools are useful when testing some applications [10:04] right, then it would be a comfy thing [10:04] ok, perfect [10:04] that's exactly what I was thinking [10:04] (along with a proper vim ... htop etc etc ... ) [10:04] I would love vim :) [10:04] there was a ML discussion about comfy iirc ... started by lool [10:05] 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] and then we'll ghrow it over time [10:07] nice [10:10] yay proper vim!!! [10:13] ogra_: so, regarding the rpi you now modify the u-boot after you created it? [10:14] longsleep, well, i run it through the mmknimg tool to get the suffix set [10:17] http://paste.ubuntu.com/12005875/ [10:17] my notes for next time :) [10:18] ogra_: You should fork my make files for the ODROID :) [10:19] ogra_: https://github.com/longsleep/snappy-odroidc [10:20] i got shellscripts for that ;) [10:20] (just not for the rpi yet) [10:22] ogra_: by the way, mu odroidc oem new version is still not reviewed, any idea how to get this going> [10:22] ? [10:23] lets get sergio on it once he shows up [10:24] 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:25] we'll see what he says [10:25] worst case we'll get beuno to fix it :) [10:26] 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:27] (and the oem snapp also shows up for /dev/click-apps/?format=click) [10:27] hmm, i see all my 60 click apps without the format snap thingie [10:27] and with it i see the snaps [10:28] clikc will hopefully not persist for to long anymore though [10:28] it seems that one only sess click apps by default and the oem snap is counted as format=click and format=snap [10:28] so this will solve itself :) [11:06] snappy-tools still a thing? Its not on 15.10 [11:13] kivi, what do you mean by that ? snapppy-tools is a PPA that contains the tools we use [11:13] ogra_, okay thanks [11:13] (ubuntu-device-flash for example) [11:13] https://launchpad.net/~snappy-dev/+archive/ubuntu/tools [11:13] the tools themselves should all be in 15.10 [11:14] the PPA has backports for older releases [11:14] ogra_, ah [11:14] okay [11:14] sorry, just following a tutorial for making python snaps, and the apt-get did not mention the ppa [11:14] ah [11:56] 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:57] longsleep: sure, I'll add to my TODO [11:58] sergiusens: great thanks [12:15] can somebody review https://code.launchpad.net/~dholbach/snapcraft/doc-fixes/+merge/267010? (just syntax fixes) [12:20] 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:21] longsleep, we're all part of the community :) [12:32] can somebody review https://code.launchpad.net/~dholbach/snapcraft/docs-next-steps/+merge/267019 too? :) [13:15] longsleep, sergiusens, elopio, merged now - thanks for the reviews [13:19] longsleep: hey, ogra_ tells me you've used snapcraft to build armhf snaps, did you do that on native armhf env? [13:19] dpm, I'll put the snapcraft docs online in a bit - we should be ready to go [13:40] and another one: https://code.launchpad.net/~dholbach/snapcraft/rename-tutorial-file/+merge/267031 :) [13:46] zyga: the snapcraft tests print lots of warnings. Any tips to clean it up? [13:48] * dholbach hugs elopio [13:48] :) [13:49] 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] sergiusens: if you want to review/comment: https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650 [13:49] elopio: can you pastebin something? [13:49] elopio: I'll help you out [13:50] sergiusens: Or you can also comment on https://bugs.launchpad.net/snappy/+bug/1480144 which tries to cover the whole picture [13:50] Launchpad bug 1480144 in Snappy "Snapcraft should be able to run in clean environment with pbuilder/cowbuilder" [Undecided,New] [13:51] zyga: http://paste.ubuntu.com/12006977/ [13:52] elopio: so for the leftover thing [13:52] 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:53] elopio: and you can use that flag to get rid of those parts [13:53] 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] elopio: is there anything else you'd like to change there specifically? [13:53] elopio: can you file a bug on that (tag it 'snappy') and I'll try to fix it ASAP [13:54] elopio: we should sync next week, I have some interesting bits coming that should be able to help you a lot [13:54] 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:55] zyga: other than that, I would like to have subunit test results. [13:56] 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:58] elopio: so both on the "plainbox" project and both with "snappy" tag pretty please [13:58] zyga: ok. [13:59] about a simple snippet, it depends on how your test suites are implemented. [13:59] elopio: mmm [13:59] 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] elopio: the way I understand it you could ask plainbox to exports results to subunit format [13:59] elopio: maybe I misunderstand what subunit is [14:00] * zyga looks [14:00] 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] the stream is nicer, but both work. [14:01] mterry: any clues about what's wrong here? http://paste.ubuntu.com/12007001/ [14:01] that's the simple-cmake integration tests running from adt-run. [14:01] elopio: mmmm [14:01] elopio: the former is easy, streaming is harder but we could do it with the new API that I worked on [14:02] elopio: it would not be a new exporter format [14:02] elopio: but a small tool that uses stable, public plainbox APIs and subunit to stream stuff [14:02] elopio: that's the thing I was talking about earlier (new shiny stuff == public api) [14:03] fgimenez: with one command, I magically have a snappy jenkins running :) [14:03] zyga: sounds good. [14:03] elopio, great! :) [14:03] so, feel free to join us next week, any time you want. [14:04] elopio, cc is broken... [14:04] :( [14:05] elopio, can I see those logs it mentions? [14:05] mterry: the thing is that if I ssh into the machine and run it, it works. [14:05] mterry: you can, but I need like 15 minutes. This is slow. [14:06] mterry: are we going to have snapcraft in the archive soon? [14:09] 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:10] elopio, I can upload it to the archive, when we think it's ready. rsalveti, do we think it's ready? :) [14:12] mterry: elopio: we can upload to the archive already, sure [14:12] longsleep, sorry for slow reply :) [14:13] 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] rsalveti, ok, can upload to wily later today then [14:13] elopio, ^ [14:13] 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:16] 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] 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] longsleep, it seems like you may have dependency problems a lot with this strategy [14:17] 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] mterry: Yes, it does not resolve dependencies automatically. Though the developer writing the snap file can resolve those manually. [14:19] 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] how big is ubuntu personal image? i want to try it from USB [14:20] dholbach, why did you remove my utf8 characters from the docs? [14:20] They were so pretty [14:20] 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:21] mterry, when I ran markdown on the file, the output wasn't pretty [14:21] guest42345, a month ago the img that ubuntu-device-flash produced was 9GB [14:21] mterry: dpkg gives that all, i think it will a lot of work to replicate that within snapcraft [14:21] not sure if it changed [14:21] elopio, your makedirs branch failed to merge [14:21] wtf, simple cmake passed now. [14:21] mterry: alternative would be to run snapcraft in pbuilder environment and have it produce a snap instead of deb [14:22] ogra_, thanks :> that's pretty BIG! i have a tiny 4G USB stick, i guess it's time to buy new ones [14:22] longsleep, that would be something we'd expect would work [14:22] dholbach, markdown doesn't handle utf8? shocking... [14:22] ogra_, so.. for now there is no way to install ubuntu personal on a diff partition, right? [14:23] i can't have ubuntu 14.04 and ubuntu personal on the same hdd [14:23] mterry: let me check tarmac. [14:23] 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] guest42345, there surely is a way to dd the img file to some other device from a live-booted system or so [14:23] but yeah, you would need to overwrite the whole device ... there is no dual boot or anything [14:24] 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] (and snappy is really not designed for something like that) [14:24] 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] http://blog.launchpad.net/general/launchpad-news-july-2015 [14:24] https://bugs.launchpad.net/launchpad/+bug/1476405 [14:24] Launchpad bug 1476405 in Launchpad itself "Add support for building snaps" [High,In progress] [14:25] mterry: to build for armhf I'd need native/emulated arm, right? [14:25] sergiusens: launchpad building snaps would be nice. [14:25] ogra_, thanks, that's what i thought.. i don't know how to feel about it [14:25] ogra_, i need some beer :)) thanks again [14:25] sergiusens: lots of stuff does not build on emulated arm [14:26] enjoy the beer :) [14:26] mmmm delicious [14:26] sergiusens: that is why we have a arm build cluster here, though that only supports pbuilder [14:26] 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] :-P [14:28] sergiusens: so, when you have launchpad building snaps, i suppose you will activate armhf only upon request similar as for debs? [14:30] sergiusens, yeah [14:31] sergiusens, did you just call me pedantic ? [14:31] :P [14:32] does the orange box mac address change on reboot? [14:32] tasdomas, yes, working on a fix, a new image should be ready before end of the week [14:33] (the current bootloader setup swallows the MAC and serial of the rpi) [14:33] 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:34] longsleep, I follow... Hrm, let me look at MP again [14:34] longsleep, thanks for explaining to me [14:35] 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:36] 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] sergiusens, easy install/py2? [14:39] 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] mterry: setuptools/easy_install/python 2 [14:39] mterry: did you see my diff? [14:40] mterry: http://paste.ubuntu.com/12006412/ [14:40] sergiusens: We have all the gear on lp to provide debs for armhf but go builds crash with Segmentation fault [14:40] mterry: I think I just duplicated some work there [14:40] longsleep: oh, you are using virtual builders I guess [14:40] sergiusens: yes [14:41] longsleep: I don't know a way out of that [14:41] 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 :) === vrruiz_ is now known as rvr [14:45] 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] mterry, Perhaps we change the plugin yaml and take both [14:45] ted, and warn on both being used maybe? [14:45] ted, I mean error out I guess [14:46] Yeah, I'm fine warning in that it will *work* [14:46] ted, are there too many people now? [14:46] * ted assumes everyone is using snapcraft now [14:46] mterry: I seem to be able to get away with it with 'binaries:\n name: python ./usr/bin/app' [14:46] IBM is probably already working on an XML schema for it. [14:47] sergiusens, yeah, snapcraft has special logic (thanks to ted) to repurpose your 'python' call to the internal python [14:47] ted, I bet it's fine to break world [14:47] :) [14:47] K, I'll break 'em ;-) [14:48] ted, as long as we error on unknown options? I don't think we do yet [14:48] ted, maybe add that to your branch too? [14:48] ted, OR.... have a warning saying it's deprecated but still accept it [14:48] mterry, Well I was just gonna require packages [14:48] ted, and error out if both are used [14:48] ted, fair on requiring packages, forgot that detail [14:48] ted, oh wait, you don't get to auto-infer package name? [14:49] ted, I loved that feature [14:49] was I the only one? [14:49] mterry: you mean the magic symlinking? [14:49] sergiusens, hrm? [14:49] mterry: you sai special logic [14:49] mterry, Heh, not sure it's really practical. Doubt anyone will have a single package that often. [14:50] dpm, mterry, rsalveti: https://developer.ubuntu.com/en/snappy/snapcraft/ - it's not auto-imported yet, nor announced anywhere [14:50] 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] ted, what, you're crazy [14:50] 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:51] dholbach: nice [14:51] * sergiusens starts the trek back home [14:52] 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:57] mterry: the unit tests are run when the deb package is built. [14:57] then it is installed, and we run the test-as-installed, the dep8. [14:57] if we put the unit tests in dep8 they would run twice. [14:58] 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 [15:00] 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] elopio, I'm fine with those split sure [15:01] now if only it passed... [15:25] Hey ogra_ any update on the rpi2 i2c and gpio stuff? [15:25] kyrofa, on it ... right now :) [15:25]