[07:09] <fgimenez> good morning
[07:25] <davidcalle> Good morning o/
[07:56] <clobrano> morning :)
[07:57] <elopio> fgimenez: hello. I did this: https://github.com/elopio/go-subunit/pull/7
[07:57] <elopio> which was a little hard and confusing for me. Could you please review it with extra care?
[07:59] <fgimenez> elopio, hey, sure i'll take a look. now get some rest! :)
[07:59] <elopio> yup, bed time \o/
[07:59] <elopio> see you later.
[08:02] <clobrano> Chipaca: if you have time, I'd like to hear your opinion about a change to hw-assign
[08:23] <guest56723> is it possible to "install"  wily-preinstalled-desktop-next-amd64.tar.gz   on a spare partition?
[08:37] <vmayoral|pc> sergiusens, ricmm: can you guys look at https://bugs.launchpad.net/snapcraft/+bug/1501651. We can't go that path to generate the snaps. Any ideas?
[08:38] <vmayoral|pc> we'll try getting snapcraft working in a native way on the RPi2 images but that seems a hack. Let us know if you come up with something else
[08:48] <Chipaca> clobrano: i don't have time right now, but if you write it out i can read it when i do have time
[08:48] <Chipaca> clobrano: OTOH this might be mailing-list fodder
[08:49] <clobrano> Chipaca: sure, no problem
[08:49] <sergiusens> vmayoral|pc, yeah, I thought you were using python and c
[08:49] <sergiusens> vmayoral|pc, qemu arm static doesn't play well with go
[08:49] <sergiusens> we should push ogra to fix it ;-)
[08:50] <vmayoral|pc> sergiusens: i'm using python
[08:50] <sergiusens> ah Chipaca already replied
[08:50] <sergiusens> vmayoral|pc, oh, I see
[08:50] <sergiusens> vmayoral|pc, so while you can't snapcraft all the way, you have reached the snap stage for everything
[08:51] <sergiusens> vmayoral|pc, you can run 'snappy build' from your host targetting the ./snap dir, it should just work (TM)
[08:51] <Chipaca> anything that tries to catch signal NSIG-1 breaks in qemu
[08:51] <sergiusens> vmayoral|pc, we will be moving 'snappy build' to 'snapcraft' as we mentioned yesterday
[08:51] <Chipaca> including, apparently, an unnamed threading implementation? dunno
[08:52]  * vmayoral|pc trying out "snappy build"
[08:53] <vmayoral|pc> sergiusens: similar result with "snappy build" https://gist.github.com/vmayoral/c248de02f8cc79c53548
[08:53]  * Chipaca afk for a while
[08:53] <Chipaca> vmayoral|pc: if it's just python, why are you building it in a qemu?
[08:53]  * Chipaca leaves with that
[08:53] <vmayoral|pc> Chipaca: trying to get a .snap for the demo
[08:54] <vmayoral|pc> not sure, but, would i be able to intall a .snap generated in x86? (even if it's just python?
[08:54] <vmayoral|pc> that's why
[08:55] <sergiusens> vmayoral|pc, from OUTSIDE the chrrot I said ;-)
[08:56] <sergiusens> Chipaca, he is using snapcraft; he needs to get the right python runtime!
[08:57] <vmayoral|pc> sergiusens: that did it, thanks
[08:57] <sergiusens> \o/
[08:57] <sergiusens> :-)
[09:03] <sergiusens> asac, http://paste.ubuntu.com/12630697/
[09:06] <longsleep> vmayoral|pc: did you see my https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin - i use that to generate armhf snaps on x86_64 by using rebuilt debian packages - the branch is outdated now, but i will continue working on it soon
[09:37] <dholbach> sergiusens, do we have a good example for a scons project we could add to snapcraft's source?
[09:38] <sergiusens> dholbach, yeah, coming soon ;-) sabdfl is playing with it
[09:39] <dholbach> cool!
[10:21] <JamesTait> Good morning all; happy Thursday, and happy International Coffee Day! 😃  🍵
[10:28] <sergiusens> tedg, are you up yet?
[11:27] <zyga> ogra: hey
[11:27] <zyga> ogra: how do you feel?
[11:30] <zyga> ogra: I have a thing you could help me with
[11:30] <zyga> ogra: let's say I have a raspberry pi
[11:31] <zyga> ogra: and I'd like to build the image with my magic sauce inside
[11:31] <zyga> ogra: I'd like to build a patched version of snappy itself (snapd)
[11:31] <zyga> ogra: patched CLI
[11:31] <zyga> ogra: some extra systemd units that start
[11:31] <zyga> ogra: how would I go about this?
[11:32] <zyga> ogra: I would really love to have a call with you and try to get to a point where I can make my own image (or iterate in some way)
[11:39] <asac> mvo: https://sigquit.wordpress.com/2009/03/13/the-core-pattern/
[11:41] <sergiusens> tedg, you around? can you get your catkin branch code polished for an MP?
[11:41] <sergiusens> tedg, would be great to use os.walk instead of 'find' or shutil.rmtree and so on and so forth
[11:43] <sergiusens> hmm, I'll create an MP and add comments
[11:47] <sergiusens> tedg, code looks good
[12:14] <sergiusens> asac, http://paste.ubuntu.com/12630697/
[12:35] <tedg> sergiusens: Awake :-)
[12:35] <tedg> sergiusens: Cool, I was waiting to see if you guys needed stuff from it.
[12:38] <sergiusens> tedg, \o/
[12:38] <sergiusens> tedg, I'll send an email :-)
[12:38]  * tedg is glad to know he was missed :-)
[12:41] <sergiusens> tedg, done, two emails
[12:57] <tedg> Haha, on the Erle Spider: https://twitter.com/pierredewet/status/649549049780158465
[12:58] <jdstrand> ogra2: hey, couple questions I have a feeling you might know the answer to: a) if I set a static ip address via snappy config ubuntu-core (easy enough), how do I setup the resolver? b) what is the recommended way to setup remote logging (ie, a snappy system sending to remote 514/udp)?
[13:02] <DexterF> greetings
[13:03] <DexterF> how "vanilla" is the Snappy Ubuntu 4.2 kernel? 4.2 has spanking new code for a certain DVB receiver I'd like to run on a Pi2, but will it be just like vanilla? are dev files like headers just like on x64, i.e., can I install build-essential and build fancy kernel modules against it like linuxtv?
[13:19] <vmayoral|pc> sergiusens: we can use your help for the camera snap
[13:22] <sergiusens> vmayoral|pc, is that also ros?
[13:22] <vmayoral|pc> no, it's not
[13:23] <sergiusens> vmayoral|pc, I'm down stairs
[13:23] <sergiusens> vmayoral|pc, want to come
[13:23] <sergiusens> ?
[13:23] <vmayoral|pc> yeap, thanks
[13:59] <tomconte> Hi everyone! Playing with snapcraft here and having strange Permission issues
[13:59] <tomconte> I suspect some kind of AppArmor problem but not sure how to troubleshoot it
[14:47] <elopio> plars: I need your help with the agent test script. Please ping me when you have time.
[14:48] <plars> elopio: sure, what's up?
[14:49] <elopio> plars: first, the deb that we are using needs to be updated daily to keep track of the changes in trunk.
[14:50] <plars> elopio: which deb?
[14:50] <elopio> could we somehow install it from the ppa? Or do you have an alternative way to make sure that we always get the daily deb?
[14:50] <elopio> currently it is just a hardcoded link.
[14:50] <elopio> plars: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh
[14:51] <elopio> https://code.launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed/+files/snappy-tests-job_1.0.0ubuntu1-0%7E64%2B201510010310%7Eubuntu15.10.1_amd64.deb
[14:52] <plars> elopio: why died this need to be a deb? This would potentially destabilize the host for that test device
[14:52] <plars> elopio: couldn't this be an artifact that gets downloaded and runs binaries from a local extracted path?
[14:52] <elopio> plars: the alternative was to set up the GOPATH in the agent and get it from trunk. But you didn't like it that way, so we went for the deb.
[14:53] <elopio> plars: it is an artifact that gets downloaded and runs binaries. The problem is that the artifact changes the path every day.
[14:54] <plars> elopio: I installed all the go dependencies you asked for so that you could do that, remember?
[14:55] <elopio> yes, but then you told me to downlod, extract and run.
[14:55] <elopio> plars: if it's ok for you, I'll switch to source code and go run.
[14:56] <plars> elopio: I thought that was the plan all along, and I think you have golang and the other deps you need there to do it. You just need a script that sets the path, pulls your branch, and does the build
[14:57] <elopio> good. I'm on it.
[14:57] <elopio> plars: second problem. If you look at the script, now I'm pushing the results summary to the json.
[14:58] <plars> elopio: let me know if you need anything from me, happy to help however I can
[14:58] <elopio> the tests should currently fail because there's a bug. And attach the error.
[14:58] <elopio> but they all pass, and the payload is empty.
[14:58] <elopio> I'm not sure what's going on here.
[14:58] <plars> One minute, let me look
[15:00] <plars> elopio: '/bin/sh: 1: ./snappy-tests-job.sh: Permission denied\n'
[15:01] <plars> elopio: it doesn't seem to be getting very far
[15:01] <elopio> oh, ok. And what should I do for it to fail instead of pass if I have that error?
[15:02] <elopio> ev: ^ here's a case where I need to deactivate the test and create a new one.
[15:04] <ev> elopio: noted; and huh, we seem to have slightly screwed up and never documented that
[15:04] <ev> getting that on the board
[15:05] <plars> elopio: what does your spec look like?
[15:05] <plars> elopio: I would think that the spi agent should pick up that failed run of the script, and call it a fail, unless you have it running some other command after that
[15:05] <elopio> plars: wget ...; ./script...
[15:05] <plars> and the later command passes
[15:05] <elopio> It's missing the chmod +x
[15:06] <plars> elopio: right, but that should exit non-0
[15:06] <plars> elopio: if that's the last command in your spec, then I would think it should get called a fail, but perhaps I'm doing something that eats it
[15:06] <plars> let me look
[15:08] <vmayoral|pc> tedg: http://wiki.ros.org/cmake_modules
[15:08] <tedg> Cool, I'll use that then
[15:08] <plars> elopio: ah yeah, I think the spi agent would depend on the provisioning kit to pass that exit value along, but we don't want to end abruptly
[15:09] <ev> elopio: I stand corrected - we just need to generate a new PDF
[15:09] <plars> elopio: I could probably set a flag somewhere that if any command in your test_cmds list fails, we should exit non-zero, does that make sense to you?
[15:09] <ev> incoming
[15:10] <elopio> ev: great, thanks.
[15:10] <vmayoral|pc> tedg: awesome!
[15:10] <elopio> plars: makes sense.
[15:10] <elopio> the other problem would be how to collect that error.
[15:10] <sergiusens> tedg, also meet ahcorde
[15:10] <tedg> Howdy ahcorde !
[15:11] <ahcorde> Hi tedg ;)
[15:11] <elopio> ev: and I have a feature request. Not sure how to send it. When I create a new test opportunity, it gives me an id. But then I can't use that id to query for the results.
[15:11] <sergiusens> ahcorde, http://paste.ubuntu.com/12632171/
[15:11] <sergiusens> tedg, so ahcorde is going to try and save you time checking if you have all the deps
[15:12] <ev> elopio: all feature requests to me (or Ursinha when I'm away)
[15:12] <sergiusens> tedg, you can remove demos, spider_imu_dev from the list
[15:12] <tedg> This is my new favorite command: find . -name package.xml -exec grep _depend {} \; | grep -v \<\!-- | cut -d \> -f 2 | cut -d \< -f 1 | sort -u
[15:12] <tedg> :-)
[15:12] <Ursinha> me
[15:12] <sergiusens> Ursinha, you!
[15:13] <Ursinha> sergiusens: happy belated birthday!
[15:13] <elopio> ev: by mail?
[15:13]  * Ursinha hugs sergiusens
[15:13] <ev> elopio: is there anything more to your request than that? If we just made it so that you could use the ID returned in a test opportunity to retrieve results for just that opportunity, would that be enough, or is there more to it?
[15:13]  * sergiusens hugs Ursinha 
[15:13] <ev> elopio: generally, yes :)
[15:13] <Ursinha> \o/
[15:13] <elopio> ev: that's just what I want, thanks.
[15:13] <ev> getting it on the board
[15:13] <tedg> vmayoral: ahcorde: cppunit? libcppunit?
[15:14] <vmayoral> tedg: not needed (i believe)
[15:14] <Ursinha> elopio: email is generally a good idea, makes it harder to miss the request :)
[15:14] <ev> Ursinha: hm, I wonder if elopio's request is a facet of this https://trello.com/c/EIgSVwFy/65-story-search-test-results-data
[15:16] <elopio> ev: Ursinha: that seems to involve a lot more. I just need another key to be allowed when querying for results.
[15:16] <Ursinha> let me see
[15:16] <elopio> and not urgent. I added a UUID to the image_unique_id, and I'm querying that.
[15:16] <elopio> works ok.
[15:16] <ev> I remember we discussed this with noise ages ago and had a card on such filtering
[15:16] <ev> I've added https://trello.com/c/jbxyvqec/188-story-filter-test-results-by-test-opportunity-id until we can otherwise prove we don't need it
[15:17] <vmayoral> sergiusens: https://github.com/ament
[15:21] <plars> elopio: I'll have a patch up for that later after I get through some other stuff, but in the meantime, just ignore the pass/fail status and chmod +x your script and I think you'll get a lot farther :)
[15:21] <tedg> vmayoral: ahcorde: eigen? eigen-containers?
[15:22] <elopio> plars: yes, I'll add the +x and change the script to run from source.
[15:22] <elopio> I'll probably mess it up and have to ask you again to copy the error for me :)
[15:22] <plars> elopio: and great idea on the results query by test id, I think that would be useful as well - you can kind of hack around it by giving your image a unique id every time, but more options for query would always be better
[15:22] <plars> elopio: no problem, I have a much easier way of looking at the trace now
[15:23] <elopio> plars: specially now that my client that requests stuff is in python.
[15:23] <elopio> it's really easy to capture the result from the previous call.
[15:23] <plars> cool
[15:23] <ahcorde> tedg: libeigen3-dev
[15:24] <Ursinha> ev: I've tagged the story accordingly, and moved to the "progress and result reporting" lane -- feel free to reorder the priority
[15:25] <ev> thanks Ursinha
[15:26] <Ursinha> ev: thanks for creating the card
[15:31] <ev> elopio: the latest PDF now has the instructions for deactivating
[15:42] <sergiusens> ogra, hey, mind testing the latest snapcraft in tools-proposed with your snapcraft.yaml's?
[16:01] <longsleep> i just switched to latest snapcraft trunk to work on my plugins, seems it now requires jsonschema which i do not have yet, is trunk supposed to work?
[16:02] <plars> elopio: oh, another dirty trick you might want to consider (I find it helpful) is to save off all your output during your test script, pastebin it at the end of the job, and post the pastebin link in the results json for spi to pick up, then you can easily see a few more details
[16:03] <elopio> plars: smart smart.
[16:03] <tedg> longsleep: You'll need to grab python3-jsonschema
[16:03] <tedg> longsleep: It validates the YAML now using that
[16:04] <elopio> fgimenez: you have one ExecCommand in the config-test that needs to be udpated for the cli branch.
[16:04] <longsleep> tedg: sure, but i thought i have the daily ppa - shouldnt it just give me the dependencies
[16:04]  * longsleep checks apt sources
[16:04] <tedg> longsleep: I'm not sure if the PPA has moved to version 0.2 yet.
[16:04] <tedg> sergiusens: ^
[16:04] <tedg> It was "not daily" there for a while to avoid breaking people.
[16:04] <longsleep> tedg: yes - the ppa seems to have 0.2.1 or 0.2.2 but for some reason my system has 0.1-0~135~ubuntu14.04.1
[16:05] <tedg> You should upgrade, it's better now ;-)
[16:05] <longsleep> the ppa i use is http://ppa.launchpad.net/snappy-dev/snapcraft-daily/ubuntu
[16:05] <sergiusens> longsleep, trunk works as long as you install what is in debian/control
[16:05] <fgimenez> elopio, ok thanks, i'll merge from trunk once it's landed
[16:06] <sergiusens> longsleep, daily ppa is dead, ppa:snappy-dev/tools is what we use
[16:06] <longsleep> ah there is indeed an update - you folks pushed that recently?
[16:06] <sergiusens> longsleep, 0.2, a long while ago
[16:06] <sergiusens> longsleep, 0.2.2 I just staged in the daily ppa
[16:06] <sergiusens> longsleep, if you want the next tentative thing, use ppa:snappy-dev/tools-proposed
[16:07] <sergiusens> longsleep, don't use http://ppa.launchpad.net/snappy-dev/snapcraft-daily/ubuntu
[16:07] <longsleep> sergiusens: ah ok thanks - i will remove the daily and add the proposed then. I got the spappy-dev/tools ppa already.
[16:08] <elopio> fgimenez: do you have any idea why the prints of my python script in jenkins appear only when the script finishes?
[16:08] <sergiusens> longsleep, hmm, if you have /tools you should of at least gotten 0.2.1
[16:09] <longsleep> sergiusens: yeah, seems like have not updated for a while
[16:09] <longsleep> i get python3-jsonschema now when doing an upgrade so i think i am good thanks
[16:09] <fgimenez> elopio, nope, didn't notice that, i thought it was due to the connection with spi
[16:10] <elopio> fgimenez: no, it should print: results not found, trying again...
[16:10] <elopio> there's a plugin for python scripts in the build which might do it better.
[16:11] <longsleep> sergiusens: another question, do you have plans to make it possible for snapcraft to use local plugins?
[16:14] <sergiusens> longsleep, it already can
[16:14] <sergiusens> longsleep, just x- it
[16:14] <longsleep> sergiusens: oh thats great
[16:15] <sergiusens> longsleep, there's a test inside integration_tests, which implements a nothing plugin
[16:19] <longsleep> sergiusens: found it - that is local to a snap though. What if i need the same plugin for multiple snaps?
[16:20] <sergiusens> longsleep, ah, upstream submission
[16:20] <sergiusens> longsleep, are you asking about the deb one?
[16:20] <longsleep> sergiusens: yes that one
[16:21] <sergiusens> longsleep, else I need to still work on some path overriding bug/task still open somewhere
[16:21] <longsleep> sergiusens: i will sync it to the latest tree
[16:21] <sergiusens> longsleep, sounds good, also if you can, unit tests and / or integration tests
[16:22] <longsleep> sergiusens: Yeah sure, it worked well for me so far - i am building 20 snaps or so with it.
[16:22] <fgimenez> nice evening all o/
[16:23] <tedg> vmayoral:
[16:23] <tedg> vmayoral: Looking at catkin_make vs. catkin_make_isolated
[16:23] <tedg> vmayoral: It seems I have to use isolated because of orocos?
[16:26] <longsleep> Mhm seems like snapcraft needs meta-data now in snapcraft.yaml
[16:26] <vmayoral> yes
[16:26]  * longsleep has some snaps to upgrade
[16:26] <vmayoral> tedg: yes
[16:28] <tedg> vmayoral: Is there a reason I wouldn't want to use isolated all the time?
[16:30] <vmayoral> we use isolated all the time
[16:30] <vmayoral> tedg: i can't come up with a reason not to use it
[16:32] <tedg> K
[16:32] <tedg> I will too :-)
[16:51] <elopio> plars: this time the run took more than 15 minutes, but I still get no result_payload.
[16:52] <plars> elopio: looking
[16:54] <plars> elopio: https://pastebin.canonical.com/140981/ sorry for the poor formatting, I just get the full string out in a log
[16:55] <plars> elopio: from a quick glance, it looks like it might want hg installed?
[16:55]  * plars wonders who uses hg still
[16:55] <elopio> plars: yes. code.google.com. Can you please install it?
[16:55] <plars> elopio: will do
[16:56] <elopio> I will make the script smarter so it doesn't fail if summary is not there. And send this to pastebin.
[16:56] <plars> elopio: and I'll add it to the extra packages to get installed in the environment too
[16:56] <elopio> plars: you have pastebinit installed, right?
[16:57] <plars> elopio: yes
[17:08] <plars> elopio: the bbb ones have mercurial now at least
[17:08] <plars> elopio: you aren't doing anything on rpi at the moment right? There's something wrong with that one that I'm trying to sort out, possibly a bad usb stick again
[17:13] <elopio> plars: no rpi yet.
[17:23] <longsleep> whats the latest syntax in snap yaml? architecture or architectures?
[18:55] <tedg> longsleep: architectures, and it's an array of architectures
[20:15] <DexterF> heya
[20:16] <DexterF> put 15.04 on a pi2. so.. does core have the same packages as standard ubuntu? can I just snappy install build-essential and compile fancy kernel modules?
[20:16] <DexterF> hmm, obviously not
[23:31] <elopio> plars: is the CWD on the agent is new every time I run it?