[00:14] hmm, ok, not a good start for snappy and docker ... -1 ... I'll ask again tomorrow. === arthur is now known as Guest43396 [07:16] good morning [07:28] Morning o/ [07:35] good morning [09:01] Good morning all; happy Friday, and happy Respect Day! 😃 [09:07] A basic question: how do you test changes in snappy itself? how can I install it? [09:08] clobrano: if you modify snappy itself you can just copy in into our snappy system and run it via sudo ./snappy something [09:11] mvo: doesn't snappy need any particular permission? Can I run it just like that? [09:12] sure [09:12] ok, thank you [09:13] clobrano: one nice property is that its a single binary so for the most part this method of just copyign will work [09:13] mvo: great :) [09:14] if you want to test it deeper in the system you can also make the filesystem writable, copy it in place and switch back to readonly [09:14] i.e. to test something that happens during boot or so [09:15] the base system is still just a normal linux system ... just without traditional package manager [09:15] ogra_: how do I make the fs writable? [09:15] sudo mount -o remount,rw / [09:15] sudo mount -o remount,ro / [09:16] ogra_: oh sure, I was expecting something special :D [09:16] heh [09:17] yeah, ogra_ made great suggestions. some stuff can only be tested by copying (snappy booted for example which is run by a startup job) [09:17] perfect [09:24] mvo, ogra_, I need to do a small doc fix in the 15.04 branch, should I merge to snappy/trunk first, then snappy/15.04? [09:25] davidcalle: easiest is probably to just do it 15.04 and then we merge the 15.04 change to trunk [09:25] davidcalle: i.e. just do it on 15.04 and we will take care of the rest :) [09:28] mvo, sounds good :) https://code.launchpad.net/~davidc3/snappy/oem-docs-formatting/+merge/271624 [09:29] mvo, ty === apw is now known as apw_ === apw_ is now known as cafetiere === cafetiere is now known as apw === JamesTait is now known as JamesTait_ === JamesTait_ is now known as JamesTait [10:04] Hey folks, i noticed that my ODROID-C image does not have most of the firmware files in /lib/firmware - is that expected when a device tarball with system/.. tree is used? [10:28] longsleep, you need to ship it in the device tarball [10:28] * ogra_ has the same issue on rpi [10:37] davidcalle, *next' release will bring official RPi support ... [10:37] we'Re not there yet :) [10:39] * davidcalle adds a "don't open before christmas" label on the email [10:40] ogra_, alright then :) [11:01] ogra_: sorry i got distracted, you say i have to ship all the firmware in the device tarball right? [11:01] yeah ... just unpack linux-firmware in the tree when you create it [11:02] ogra_: ok cool, thanks! [11:42] o/ [11:42] my pi is on #5 :) [11:42] feels faster [11:43] heh [11:43] i bet thats subjective [11:43] guess thats just the excitement because i had to invest to get tehre [11:43] :) [11:43] yeah [11:43] and snappy list bails very quickly [11:43] https://bugs.launchpad.net/snappy/+bug/1497245 [11:43] Launchpad bug 1497245 in Snappy "snappy list/remove bails on 15.04/stable #5 if invalid package.yaml is on disk (no vendor field)" [High,New] [11:44] you and your exotic packages :P [11:45] well, vendor field wasnt mandatory no? [11:45] * ogra_ isnt sure [11:45] probably it is now [11:45] in any case, think for list and in particular remove we should be super robust against anything [11:46] i think its mandatory for 16.04 ... but not for 15.04 [11:46] we backported trunk ... [11:55] asac, vendor was always mandatory [11:56] asac, the store at least booted you because of that, did you manually install? [11:56] sure [11:56] my beloved zigbee gateway :( [11:57] lol [11:57] * asac goes and manually removes the app from /apps and the other prominent places [11:57] asac, why didn't you upload it to the store ? sounds like an interesing app ;-) [11:58] yay what i love about snappy is that there is no cache/meta files [11:58] sergiusens: like most of our apps they are customer related as they prep for launching big devices :P [11:59] thats why in store we have like 2% of the existing snappy apps at best [11:59] I was just punning :-) [11:59] i know [11:59] sergiusens: good that you are awake again [11:59] the call is cancelled... [11:59] NOT :) [11:59] lol [11:59] asac, well, meetings! ;-) [11:59] will be there in 1 minute [12:00] huh ? [12:00] why the heck is the clinic a hangout [12:00] thats nonsense [12:01] ogra_: its a meeting [12:01] you coming? [12:02] asac, what for ? [12:03] asac, if we want to do a clinic it should be on IRC ... i.e. a special time where we help with specific developer problems [12:05] ogra_: moar hangouts [12:28] I think https://code.launchpad.net/~zyga/snapcraft/gitignore/+merge/271313 and https://code.launchpad.net/~dholbach/snapcraft/1496789/+merge/271444 can be landed, right? :) [12:32] asac, mvo_, so i dont think there is any solution to the Pi update issue without actually releasing a stable #6 ... [12:32] i guess we should just release-note it that you have to manually copy the kernel pieces [12:33] ogra_: yeah, its really really hard :/ will the generic kernel not boot at all? or what will happen? [12:34] it hangs hard at "Starting kernel ..." [12:34] meh [12:34] doesnt even unpack it completely [12:35] yeah, that does not give us many options :( [12:35] right [12:35] we could hack something into the s-i process or some such ... but that would still require a #6 release [12:37] (at least for armhf) [12:37] we could indeed do an armhf only release ... at the cost of gettin the image numbers out of sync [12:40] thanks sergiusens [12:47] ogra_: yeah, I really have no good idea either, lets create the device thing on the server so that we are safe for the future, I talk to sil [12:48] yup. i see that :) [12:49] mvo_, the other question is ... why is there a kernel in /boot at all :) i thought we added code to remove it in livecd-rootfs [12:50] * ogra_ wonders if that only went into rolling [12:52] ah, so it did [12:55] ogra_: heya, quick rpi2 question for you if you have a moment - We're seeing that our ethernet hwaddress changes on every boot, I'm guessing because it has the serial as all 0s in proc cpuinfo. Is there any way you know of to have it configure a serial or come up with a static hwaddress? [12:55] plars, seems you are using an outdated image [12:55] that was fixed a while ago [12:56] ogra_: well, I'm not booting to snappy yet, this is just an ubuntu image as a base, and we'll boot snappy from there. What was the fix? [12:57] changing uboot and reading the binary blob data into the kernel cmdline [12:57] the binary blob provides the actual MAC in a variable [12:58] ogra_: which binary blob is it reading, and how does it get passed? [13:00] the binary blob that boots your board [13:00] i.e. the graphics driver that acts as bootloader :) [13:02] ogra_: we're all waiting for our nvidia overlords to boot our x86 pc [13:02] plars, i dont remember exactly, iirc you need to crate a cmdline.txt next to the config.txt [13:02] it needs to contain something ... then the args get handed over to the uboot env [13:03] (RaspberryPi2)ubuntu@localhost:~$ cat /boot/uboot/cmdline.txt [13:03] elevator=deadline [13:03] (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep ^args [13:03] args=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 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 elevator=deadline [13:03] that is how my Pi expands the cmdline [13:03] * ogra_ forgot if there were additional steps required [13:04] ogra_: weird, I actually copied the boot directory from snappy [13:04] from image #4 ? [13:04] ogra_: so I'm not sure what could be missing [13:04] that only landed in the last image [13:04] ogra_: from one I downloaded last night [13:04] ogra_: how recent was that? [13:05] ogra_: I just grabbed the prebuilt one [13:05] ogra_: yeah, that puzzles me too, on armhf we really do not need that in /boot [13:05] well, if it is the one from ~/platform thats the most recent one [13:05] mvo_, i think we just didnt pull the change into the PPA [13:05] ogra_: oh, ok [13:05] ogra_: that makes sense [13:05] ogra_: yes, that's the one [13:05] i see the right code in live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary in wily [13:06] plars, weird [13:06] ogra_: its fine [13:06] should definitely work then [13:06] ogra_: can you reply to the release thread explaining the workaround? [13:06] asac, will do [13:06] or togetyher with your release announce when the pi2 is there [13:06] there too [13:06] cant mention it often enough ;) [13:06] just say "becauyse pi2 is not officially consumed from channels you need to do these copies after snappy update [13:06] and done [13:07] yep [13:11] sergiusens, i'm looking at package.yaml for pi and BBB oem snaps ... i dont see where it would define generic_armhf vs raspi2_armhf [13:11] i think sergio forgot to add that optioon to the yaml [13:11] was an oversight. we discussed a while back to have another field [13:11] "architecture: armhf" is what i see in both currently [13:11] beyond architecture [13:11] channel: [13:11] or somethign [13:11] generic [13:11] pi2 [13:11] etc. [13:11] i see platform ... but that only defines the default dtb [13:12] does the azure have an oem snap? [13:12] if so it might have that info [13:12] but guess it still is created with manual [13:12] if azure does it isnt in http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files [13:12] that much i know [13:12] but doesnt mean there isnt one [13:13] right [13:13] anyway, i know it was a missing field before 15.04 release and most likely we just didnt add it [13:13] ogra_: weird, I don't see it in the uboot environment, but I do see usbethaddr there, but I don't see it get used [13:13] plars, usbethaddr is wrong [13:13] but adding a new field with default "generic" shouldnt be a problem [13:13] smsc95xx.macaddr is what you need [13:13] just remember to add cards etc. [13:13] ogra_: it's the one I ended up with when I booted snappy [13:14] ogra_: but not when I boot something else - then it's random even though I copied all the bootloader files and uboot from the snappy image [13:14] do you have uboot.env ? [13:15] asac, ogra_ since we don't want to expose s-i in snappy so high up; it was never there; you can build with u-d-f passing --device with the channel (like for azure); but it might only work for azure (as we don't want to make it easy to go down a path we can't support) [13:15] ogra_: I do [13:17] sergiusens: platform: ? [13:17] that doesnt feel like surfacing something from si if we use that [13:17] plars, and is it used ? [13:17] ogra_: yes [13:17] ogra_, http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/ubuntu-device-flash/snappy.go#L123 [13:17] (do you see it pload properly in the serial log) [13:17] architecture: + platform: (optional, default: generic) [13:17] asac, we had platform; but in the end this would be in the kernel snap [13:18] reading uboot.env [13:18] sergiusens, deviceChannel ? [13:18] ogra_: yep :) [13:18] ogra_, --device [13:18] sergiusens: wait, in OEM snap specifying what platform this is for makes sense [13:18] hmm [13:18] ah, s.device ... right [13:18] oor we just say kernel: pi2 [13:18] * ogra_ looked to far down [13:18] default: generic [13:18] doesbnt matter for OEM snap... we will revisit those fields for 16.04 anyway then [13:18] asac, ok; makes sense [13:21] ogra_: surely it's pulling the serial from the board somehow and not from the image though, right? [13:21] plars, yeah, same thing [13:21] bcm2709.serial=0x8b04db1c [13:21] cmdline option [13:21] seeded from the binary blob [13:22] plars, if you intercept the boot, do you see "args" ? [13:22] in printenv [13:23] ogra_: no [13:23] ogra_: was there something in the kernel needed for this? [13:23] no [13:23] thats pre-kernel [13:23] but ... [13:23] mmcargs=setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot}" [13:24] and snappy_boot calls "run mmcargs" on first boot [13:25] plars, ah, and: [13:25] loadfdt=fdt addr 0x100; fdt get value args /chosen bootargs [13:25] try running that line [13:25] and then see if args= exists [13:25] if so, add it to your non snappy boot [13:26] * ogra_ forgot you have to pull te dtb from ram in to have the values [13:26] ogra_: just "args"? no still not set [13:26] that was the bit :) [13:26] ah, I see [13:26] get value args /chosen bootargs [13:26] hang on let me try that [13:26] fdt addr 0x100 [13:27] you need that first [13:27] ogra_: running loadfdt did it, thanks! [13:27] cool [13:27] ogra_: we have a raspi2_armhf platform now! [13:27] mvo_, yeah, i see that !! [13:28] mvo_, i'll triger an edge build to see of it imports fine [13:28] on rolling? nice ;) [13:28] no [13:28] https://system-image.ubuntu.com/ubuntu-core/15.04/edge/ [13:28] on 15.04 edge :) [13:29] build running [13:30] I added it to rolling and 15.04 so we should be fine [13:30] now I guess we just update reference image and the upgrade problem is solved for good [13:30] * mvo_ is happy [13:33] mvo_, the importer will now run 5min longer [13:33] or so [13:33] new arch means moar diffing [13:34] meh [13:35] I saw an unexpected (for me) behavior in hw-assign: each call to hw-assign overwrite the udev rule for the , while the list of write_path in .apparmor.json.additional is just updated [13:36] so that udev rule only contains 1 device node at a time [13:37] hmmm [13:37] http://paste.ubuntu.com/12448771/ [13:37] Chipaca: mvo_: the above looks pretty garbled formatting wise [13:38] is it possible to improve the way we present multi-line yaml? [13:38] like the content: one for the network interface looks much nicer [13:39] jdstrand: see clobrano's questiona bout hw-assign... feels like a bug [13:39] 6 lines above [13:41] yes, it does [13:42] http://paste.ubuntu.com/12448814/ [13:42] asac: I think the problem is the \t it can only represented in the "" form. looks at the startup above, this is what it should look like [13:42] clobrano: can you file a bug at https://bugs.launchpad.net/snappy/+filebug ? you might add a comment that it is (perhaps) hindering on your progress on the other bug [13:43] sure [13:43] well, it is not really hindering, I just saw that I had to change device name at each try :D [13:46] fgimenez, I'm not sure this helps a whole lot, but I thought I'd share what I was playing around with: https://code.launchpad.net/~dholbach/snapcraft/examples-tests/+merge/271649 [13:46] fgimenez, great work on adding the examples test [13:46] tedg, the qmldemo example is still broken on wily - do you know how to fix it? [13:46] dholbach, i'm looking into it right now, thanks a lot :) [13:47] <3 [13:48] pitti, you once told me, iirc, that we can enable autopackage tests on PPAs? [13:48] sergiusens: that's the plan, yes [13:49] not implemented yet because too many diversions and kernel testing having higher prio [13:49] sergiusens: but I definitely want this too; might still be a few weeks, though [13:49] pitti, oh, still on paper :-) ah, but sooner than I thought :-) [13:50] * sergiusens puts a 1 month away reminder [13:50] sergiusens: is this something important/critical for snappy development? [13:50] dholbach: I think so, I just need to get a wily VM setup [13:51] pitti, we just added lots of tests; we run them before merging but would be nice to run on package build as well [13:51] pitti, so important, but not critical [13:51] sergiusens: i. e. next week I need to work on prototyping the "run deb chroot on snappy" thingy for the snappy sprint the following week; if this is important, I'm happy to work on that on the sprint and have you test it :) [13:51] pitti, I will defer to elopio on that ;-) [13:51] pitti, sounds good! [13:52] sergiusens: the mere act of running them is actually fairly simple; it's mostly how to trigger them and what to do with the results which is the interesting bit there [13:54] jdstrand: Is there a permission to read/write the user's home directory? [13:54] yeah, I hear you, integrating it all together is what mostly blocks things from getting done [13:55] tedg, wrt question, I was thinking that the wrapper for binaries should cd to $SNAP_APP_DATA_PATH (the one in $HOME) [13:55] jdstrand: here it is https://bugs.launchpad.net/snappy/+bug/1497299 [13:55] Launchpad bug 1497299 in Snappy "hw-assign overwrites existing udev rules" [Undecided,New] [14:04] sergiusens: Why? [14:06] tedg, there was a docker bug that affected that; but yeah; I guess it will break badly in most occasions [14:06] tedg, although no binary can read outside its containment either [14:06] sergiusens: I think we should probably have a conversation about how we expect UAL to work with core launcher. [14:07] sergiusens: I'm curious if we want to seperate out "run as a user" and "run as root" [14:07] sergiusens: For instance, setting the XDG* variables so that most things will "just work" with that being their only writable directory [14:11] tedg, sergiusens docker is not allowed by apparmor to read data outside its own $HOME/apps/docker/version directory. [14:13] sergiusens: mvo_: Do we have an idea how to finish off this branch? https://code.launchpad.net/~mvo/snapcraft/more-python-apt/+merge/270831 [14:15] tedg, I like it already, we just need to trim manifest.txt [14:24] tedg, my brain will explode with this one https://code.launchpad.net/~ted/snapcraft/inception/+merge/271656 :-P [14:24] sergiusens: Yeah, it's kinda fun. We should run all our tests in the snappy CI service :-) [14:25] tedg, hah, this is rather useless though as we depend on build tools still but rather interesting in itself [14:25] tedg, if we get rid of build tools we can certainly cater for this [14:26] sergiusens: Yeah, it feels like something we should do. If we want other people to include a snapcraft.yaml in their repos. [14:33] ev: can we talk about jenkins? [14:33] elopio: sure! [14:34] ev: I played with the svn config sync plugin and it needs to push to git. For that we need to put the ssh public key of jenkins on launchpad. [14:34] ev: is that ok for you? [14:41] elopio: I'm confused; what's the security risk you're eluding to? [14:42] ev: no security risk. Just to push the config to the git branch in launchpad we need the key. [14:43] elopio: and while we're talking about Jenkins, can I ask that you guys focus on getting your Canonistack Jenkins driving daily testing of Snappy through SPI before all the time gets eaten up transitioning to Jenkins as a service? [14:43] I didn't realise this was going to require so much work for you guys, otherwise I wouldn't have suggested Jenkins as a service until we saw a steady stream of results in SPI. [14:44] elopio: can't you have a separate ssh key that you generate for the purpose? [14:44] something like http://superuser.com/a/232406 [14:45] oh, I guess when we're dealing with public keys it really doesn't matter [14:45] so yeah, I think it's reasonable for you to put the public key in LP [14:45] +1 :) [14:46] ev: I'm not sure if I can tell the plugin to use a different key. [14:46] yup, that's fine [14:46] ev: ok, let me ask for it on an RT. [14:46] cool [14:46] please do CC me [14:46] ev: what's taking long is that we had a release this week, and we have another next week. [14:46] so we actually didn't touch ci at all this week. [14:47] elopio: is there anything I can do to help you guys get your tests running daily on SPI? [14:48] ev: I think not, this was the last question I had. Let me give it another try after the snapcraft release. [14:48] * ev nods [14:48] asac: mvo_: tbh the file-contents-as-value-of-key thing is rather nasty, and i'd change it if we're going to do that long term [14:49] asac: mvo_: ie treat values that are files differently, e.g. yaml points to /1.0/packages/{pacakge}/config/{uuid}, and you GET/POST to .../uuid to operate on the file [14:52] pitti: Have you talked to the libertine container folks about running deb containers? [14:52] tedg: libertine? no, I didn't (I don't even know what that is) [14:53] tedg: running it as an actual container is fine; but AFAIUI sabdfl suggested running them in a chroot with shared processes [14:53] Chipaca: I don't follow, sorry. but I'm in a meeting rightnow so maybe I just need to re-parse this [14:53] so that from within that you can "admin" snappy [14:53] pitti: It does both, depending on kernel version [14:53] this comes at quite a high cost and loss of reliability, though [14:53] pitti: Basically it is the same feature for phones [14:53] pitti: It would be nice if we had one set of this code :-) [14:53] Chipaca: yeah sounds reasonable [14:54] Chipaca: like a resource:// thingy [14:54] is there any yamnl extension that is standard for such? [14:55] tedg: ah, https://launchpad.net/libertine ? thanks for the pointer, I'll look at that [14:55] pitti: You should chat with ChrisTownsend about it some [14:55] pitti: I think they're basically the same goals, it'd be nice if we converged on one solution for phone/snappy [14:56] pitti: tedg: Yeah, I'm here. bregma too [14:56] tedg: not sure -- this sounds like you actually want to containerize and isolate this [14:56] tedg: but either way, I'll look at this and talk to ChrisTownsend, thanks [14:57] pitti: It started more with containers, but because of the old kernels on the phones it grew chroot. So the description might not match the implementation in that regard. [14:58] tedg: Libertine supports both chroot and lxc. [15:00] dunno [15:03] pitti: FYI, I'll be around today, but off next week. bregma can definitely help too. [15:14] ChrisTownsend: does this do anything like discovering sysv init and systemd jobs in the chroot and start them from the host, but properly chrooted? [15:15] ChrisTownsend: that seems to be the most brittle/heuristic aspect of all [15:16] ChrisTownsend: for what Michael and Mark have in mind, it's probably better to actually start the deb env as a proper container with all services and its own init, but then provide a mode to just chroot into it if you want to do snappy admin/devel [15:16] that's the model which seems most robust to me and still reasonably fulfill the requirements [15:16] pitti: Wouldn't we want to use LXC instead of a chroot? [15:17] pitti: The chroot is only intended for kernels that don't support unprivileged LXC's. [15:17] ChrisTownsend: with LXC you can't see/admin the host processes and bits; AFAIK this was the raison d'être for this [15:17] ChrisTownsend: oh, and it's certainly a privileged container [15:17] fgimenez, I could imagine that the problem has to do with the fact that the examples directory is not mentioned in setup.py anywhere, but I'm not 100% sure yet [15:18] pitti: I was wondering if we could setup snappy-remote to make it so that it would know it is in an embedded situation. [15:18] pitti: Hmm, ok. I really don't have any sense of your requirements, so I may be off base in my replies:) [15:18] pitti: So then you could manage your snappy system, but it'd actually be using REST. [15:18] ChrisTownsend: the idea of that was not to treat some debs as an "app", but to provide a "classic ubuntu" like environment for development and admin'ing snappy [15:18] mvo_: ^ right? [15:18] pitti: I think that sabdfl's concern was being able to manage the core system from the container. [15:18] ChrisTownsend: well, neither have I, I'll mostly come to this as a consultant :) [15:19] pitti: yes, right, its a full environment to "sh" into [15:19] pitti: lol, ok [15:19] tedg: right; so it can't be a container when you get a shell into it [15:19] pitti: It could if the snappy tool used the REST interface transparently. [15:19] tedg: that doesn't preclude actually booting it as a container, so that you have the .deb services running properly [15:19] fgimenez, or integration-tests/manage.py maybe [15:19] pitti: and one use case if e.g. install and run tcpdump on snappy [15:19] pitti: or install strace/gdb etc [15:19] right [15:20] Hmm, strace is trickey [15:20] so for that mode you'd chroot into the root fs; you would see the snappy pids, but can't do /etc/init.d/apache2 restart (you need a "container shell" for that) [15:20] mvo_: So it would have to be completely unconfined [15:20] so it's always a bit weird [15:20] yes, this isn't a security thingy -- you want full access [15:21] mvo_: Is the concern that you'd need gdb/strace for things already installed as snaps, or for building debugging them? [15:22] both I think [15:22] I'm thinking the way we make libertine containers may be too confining for this purpose. [15:23] yeah, it's two rather different use cases [15:23] We make an unprivileged chroot and only bind mount a few necessary host dirs. [15:23] tedg: worth clarifying in budapest, but my understanding was that it is intended to troubleshoot a existing system [15:23] ChrisTownsend: libertine basically is a snap for a bunch of debs, treated as an "app", right? [15:24] pitti: Well the idea is that it maintains a container long term, so you end up apt-get'ing more over time. [15:24] pitti: So it's not a one-shot type thing. [15:24] well, I'll take a look at it either way [15:25] I don't feel that this "deb env on snap" thing will be a lot of code, it's just getting the concept right [15:25] thanks for your input! /me needs to leave now [15:34] 'night pitti ! [15:34] sergiusens: tedg: could there be a way for a snapcraft.yaml to include another snap? [15:34] Man I hate my wifi [15:35] Oh, oh! An inception2 branch! [15:35] elopio, crazy talk [15:35] elopio, just use reusable parts ;) [15:35] elopio, the snap as a binary or the snap layed out as an overlay? [15:36] I mean we could decompress it and just copy the same files into the new snap. [15:36] The potential use I could see is that someone wants to include a particular version of a framework. [15:37] sergiusens, tedg: I don't know. I'm just thinking. Lets say I want to test hello-world.snap. Maybe I don't want to put the test binaries in the production snap because they import testtools and a lot of other stuff. [15:37] so, maybe I could write a test snap that includes the production snap. [15:37] then I install hello-world-test.snap. And it has both the production and test binaries. [15:38] I was thinking that perhaps we could have a plugin you could add to your snapcraft that would do some testing things. Like run the bins under gdbserver. [15:38] That's kinda how QtCreator does things. It builds a new click that has the gdbserver connection setup. [15:38] Then it connects to that. [15:39] that sounds cool. But not what I'm after here. I want a test that runs the binary and checks the output. And a test that starts the service and makes requests to it. [15:41] Hmm, would you want that to be an external package then? [15:41] foo.snap and foo-tests.snap [15:42] tedg: maybe. For small tests that don't have a lot of dependencies, I can just add a binary foo-test to foo.snap. [15:43] but for complex things, like a full suite on the docker snap. We probably want to import a testing framework, and testing helpers. For that I would like a docker-tests.snap. [15:43] I wonder if we just make it super easy to make that foo-tests.snap and then you don't care how small/big it is. [15:44] but that docker-tests.snap should have access to everything docker.snap has. And we don't have dependencies to say docker-test.snap depends on docker.snap, so I'm thinking we should bundle docker.snap inside docker-tests.snap, somehow. [15:45] tedg: that foo-tests.snap it's super easy to make with snapcraft already, just a python project gives us everything we can possibly need. [15:45] but how to call foo from foo-tests.snap? [15:46] foo-tests.run [15:46] It would have to export its own binary [15:46] dholbach, mmm i think it has to do with the examples directory not being available from plainbox's ${PLAINBOX_PROVIDER_DATA}, the symlink at http://bazaar.launchpad.net/~fgimenez/snapcraft/build-examples-test/view/head:/integration-tests/runtests.sh#L40 is not properly created [15:48] tedg: right, how to call foo.run from foo-tests.run if foo.snap is not installed. [15:48] oh wait, I'm sorry. You are working on the release. I forgot I said we will discuss about this next week. [15:48] tedg: sergiusens: I'll add a meeting to the calendar. [15:48] elopio: Wait, why don't you install foo.snap ? [15:48] fgimenez, my last hypothesis was that the examples directory was missing because it wasn't mentioned in neither setup.py nor integration-tests/manage.py, but that might be my lack of understanding of plainbox [15:49] * tedg wants to install all the foo's! [15:49]