[00:49] <plars> elopio: yes
[00:50] <elopio> plars: could you please check what's the latest error?
[00:51] <elopio> I'm not yet catching the good stuff in the payload. Butt when I test it here it works.
[00:55] <plars> elopio: sure, just a minute
[00:59] <plars> elopio: this seems to be the interesting bit: cat: /results/output/log: No such file or directory\nYou are trying to send an empty document, exiting.\ncat: /results/output/summary: No such file or directory\n./snappy-tests-job.sh: 9: ./snappy-tests-job.sh: cannot create /spi_test_result.json: Permission denied
[00:59] <elopio> plars: hum. The docs say that there is an env var $CWD.
[00:59] <elopio> I was using that. I'll take it out.
[01:00] <elopio> thanks. Another try...
[01:00] <plars> elopio: $PWD perhaps?
[01:01] <elopio> plars: no, the docs say $CWD. But it's not entirely clear what they meant with that.
[01:01] <plars> elopio: which docs?
[01:02] <elopio> plars: spi-user-docs-latest.pdf
[01:02] <plars> could be a misprint, but I would think $PWD should work
[01:45]  * elopio needs better bash superpowers.
[01:54] <yashi_> regarding to bug #1499429, what's a proper workflow to reflect review comment to my launchpad branch?  force push or another branch?
[01:55] <ubottu> bug 1499429 in Snapcraft "snapcraft dies with "export: python3.5/dist-packages: bad variable name"" [Critical,Confirmed] https://launchpad.net/bugs/1499429
[02:14] <elopio> yashi_: hello.
[02:15] <elopio> I replied on the merge proposal. Just make the change, bzr commit and bzr push.
[02:15] <yashi_> elopio: thanks!
[02:15] <elopio> you use the same branch, but are not forcing anything. It will keep the previous commits.
[02:16] <elopio> yashi_: thanks a lot for finding this, and fixing it. Have you signed the contributors agreement?
[02:16] <elopio> http://www.ubuntu.com/legal/contributors/submit
[02:18] <yashi_> elopio: nop, reading....
[02:19] <elopio> yashi_: Here's the faq: http://www.ubuntu.com/legal/contributors/licence-agreement-faq
[02:19] <elopio> please let me know if you want to know something else.
[02:40] <yashi_> elopio: the submission ask me to put a project contact.  what is it?
[02:43] <yashi_> elopio: hmm.  do i need to print the pdf, sign it, and snail back to canonical?
[02:44] <elopio> yashi_: the contact is asac. Alexander Sack <alexander.sack@canonical.com>
[02:44] <elopio> yashi_: and no, afaik you don't have to send the pdf. Let me confirm.
[02:46] <elopio> yashi_: it says that you can send the pdf if you don't have a launchpad account. You are good with filling the form.
[03:20] <elopio> sigh, I suck at bash. I can't even capture the error.
[03:20] <elopio> plars: again, please, whenever you see this.
[03:48] <yashi_> elopio: done
[03:49] <elopio> yashi_: thank you!
[03:50] <elopio> welcome to snapcraft. If you ever get bored, we have tons of things funny things you can do ;)
[03:50] <yashi_> elopio: will push a fix today
=== chihchun_afk is now known as chihchun
[06:11] <elopio> sergiusens: hey, you are up.
[06:11] <elopio> sergiusens: these are the problems I had:
[06:11] <elopio> ttps://bugs.launchpad.net/snapcraft/+bug/1499429
[06:11] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1501980
[06:11] <elopio> https://bugs.launchpad.net/snapcraft/+bug/1501977
[06:11] <ubottu> Launchpad bug 1501980 in Snapcraft "the error message when a plugin is not found is not good" [Undecided,New]
[06:11] <ubottu> Launchpad bug 1501977 in Snapcraft "py2-project example fails to snap" [High,New]
[06:12] <elopio> other than that, looks good.
[06:12] <elopio> haven't tried the minecraft one yet.
=== bigcat__ is now known as bigcat
[06:50] <clobrano> morning :)
[07:04] <fgimenez> good morning
[07:25] <davidcalle> asac, thanks for the heads-up, that's an impressive team effort :) Are there any sections you'll still want to keep under wraps or can I assume (after today eod) everything is ready for a first publication?
[07:32] <dholbach> good morning
[07:35] <davidcalle> Hey dholbach, how are you?
[07:36] <dholbach> hey davidcalle
[07:36] <dholbach> good good - how about you?
[07:36] <davidcalle> dholbach, life is good
[07:38] <davidcalle> dholbach, nice work with the snappy doc propositions, I agree with everything :)
[07:38] <dholbach> yeah, I was trying to find a balance between: more useful for certain demographics and not too much new maintenance work for us :)
[07:39] <dholbach> ... and leaving IA intact
[08:36] <clobrano> Chipaca: I'll drop here my hw-assign question (I wrote on the mailing list too), please have a look at it, when you've got time :)
[08:37] <JamesTait> Good morning all; happy Friday, and happy International Day of Non-Violence! 😃
[08:37] <clobrano> Chipaca: about the possibility to assign a symlink to a device node using hw-assign command (Bug #1496319), I had everything done and ready to be submitted for something like: "snappy hw-assign <device> <symlink>"  but, then, I thought that it's more common to create a symlink only if some conditions are met (like VID/PID, etc.), so I've got the idea to change it in: "hw-assign <device> <properties>" where <properties> would be a string containing part of
[08:37] <clobrano> the Udev rule to append to the newly created rule, like "ATTRS{idVendor}==...". This way one can add different rules, not only symlinks. What do you think?
[08:37] <ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
[08:53] <Chipaca> clobrano: hmm. first thought is whether udev has been audited enough to have people safely write rules
[08:54] <clobrano> Chipaca: yep, that was my first idea too
[08:54] <clobrano> Chipaca: like with great power comes great responsability :)
[08:55] <clobrano> Chipaca: but at the same time, it's common symlinking to a generic /dev/ttyUSB* and then add conditions to narrow down the list of possible device nodes
[08:56] <lool> vmayoral|pc: ssh root@212.47.227.205
[08:56] <clobrano> Chipaca: however, that things can be done at different times. First try and add the first implementation and then see if/when we can move to the second one
=== vmayoral|pc is now known as vmayoral
[08:59] <Chipaca> clobrano: so which would the first implementation be?
[08:59] <clobrano> Chipaca: just hw-assign <device-node> <symlink>
[09:00] <clobrano> Chipaca: where <symlink> is optional
[09:03] <asac> davidcalle: not sure yet. lets see how it looks like
[09:04] <Chipaca> clobrano: and how would the move to the second phase work?
[09:05] <lool> tedg, sergiusens: ssh root@212.47.227.205 for the ARM buildd
[09:05] <lool> vivid, installing snapcraft there now
[09:05] <clobrano> Chipaca: that's depend on you all I think :), I can't decide if/when that change will be applicable
[09:05] <Chipaca> clobrano: no, i mean
[09:06] <Chipaca> clobrano: let's say we implement hw-assign <device> [<symlink>]
[09:06] <Chipaca> clobrano: document taht
[09:06] <Chipaca> clobrano: people use it
[09:06] <Chipaca> clobrano: how do we introduce the new thing without breaking the old?
[09:06] <clobrano> Chipaca: ooh, right
[09:07] <clobrano> Chipaca: well, it's not that hard to recognize a symlink (valid) from a string defining a udev rule, just to keep the backward compatibility
[09:08] <clobrano> Chipaca: but I got your point
[09:08] <lool> vmayoral, tedg, sergiusens: please use ubuntu@212.47.227.205 instead, sorry
[09:08] <lool> root will go away on reboots, and we should not use root
[09:14] <lool> ok, sudo works now, removing your root SSH keys guys
[09:32] <lool> yeah, building!
[09:40] <dholbach> fgimenez, elopio: does "python3 setup.py test" crash for you in lp:snapcraft too?
[09:41] <fgimenez> dholbach, let me try
[09:59] <fgimenez> dholbach, yes, pip-requirements is failing http://paste.ubuntu.com/12637380/
[10:01] <dholbach> fgimenez, http://pastebin.ubuntu.com/12637392/ is what I'm seeing
[10:02] <dholbach> zyga, ^ do you know what's happening here?
[10:04] <zyga> dholbach: looking
[10:04] <zyga> dholbach: yes, it's fixed with a branch that didn't land yet
[10:04] <zyga> dholbach: it's a one-line fix
[10:05] <zyga> dholbach: but I'm not sure if someone fixed it because the original contributor did the fix in a werid way but didn't respond to feedback
[10:05] <zyga> sergiusens: ^^
[10:05] <zyga> dholbach: it happens because wily has two versions of python3
[10:06] <dholbach> zyga, are http://paste.ubuntu.com/12637380/ and http://pastebin.ubuntu.com/12637392/ the same issue?
[10:08] <zyga> dholbach: no, that seems different
[10:08] <zyga> dholbach: the 2nd one looks like a bug elsewhere, how did you get it?
[10:09] <zyga> dholbach: is that trunk, any released version, something else?
[10:09] <dholbach> trunk
[10:09] <zyga> dholbach: on wily?
[10:09] <dholbach> yes
[10:09] <dholbach> I just ran    python3 setup.py test
[10:10] <zyga> dholbach: one sec
[10:10] <zyga> dholbach: I'll just fix the bug that the contributor tried
[10:10] <zyga> dholbach: and see if I get to the 2nd one
[10:11] <dholbach> <3
[10:12] <zyga> dholbach: I should have fixed it earlier but I really wanted yashi_ (AFAIR) to reply
[10:12] <dholbach> no worries
[10:12] <zyga> dholbach: https://code.launchpad.net/~yashi/snapcraft/snapcraft/+merge/272337 this is the thing
[10:13] <dpm> dholbach, looking at the developer manual, trying to do 'sudo apt-get install snapcraft-examples' does nothing for me. I'm on 15.04, and I've got the ppa:snappy-dev/tools installed
[10:13] <dpm> anything I'm missing?
[10:13] <zyga> yashi_: around?
[10:13] <dholbach> dpm, not sure if anyone updated the ppa - let me check
[10:14] <dholbach> dpm, https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/+sourcepub/5408454/+listing-archive-extra
[10:14] <dholbach> dpm, it should be there
[10:15] <dholbach> are you sure you have the ppa enabled and your apt sources updated?
[10:15]  * dpm apt updates to be sure
[10:15] <dpm> that might have been it
[10:16] <dpm> yeah, that was it, thanks dholbach
[10:17] <dholbach> cool
[10:17] <zyga> fg
[10:18] <dholbach> zyga, what does force-push mean in the MP=
[10:18] <dholbach> ?
[10:19] <zyga> dholbach: bzr push --overwrite
[10:19] <zyga> dholbach: before it lands that's the best way to do it
[10:20] <dholbach> ah, so you're asking yashi to push --overwrite to his branch?
[10:20] <zyga> dholbach: lp tracks past in case someone wants to do data mining but for everyone else it gets rid of "fixup stuff" commits that are just noise
[10:20] <zyga> dholbach: ys
[10:20] <zyga> yes*
[10:20] <dholbach> ok
[10:20] <zyga> dholbach: if you want I can fix and land this myself in 5 minutes
=== chihchun is now known as chihchun_afk
[11:18] <zyga> dholbach: do you want me to fix that quickly?
[11:21] <dholbach> zyga, I don't know - I just noticed that the test was broken
[11:26] <zyga> dholbach: yes, we know about it, I think I will just fix it now
[11:27] <dholbach> ok
[11:33] <victorp> pitti, hey - got home and I am able to ssh over wifi to the pi. Thanks!
[11:33] <pitti> victorp: cool!
[11:34] <pitti> victorp: wipi!
[11:34] <victorp> hehe
[11:42] <mvo> vmayoral: this will work  lp:~mvo/snappy/snappy-classic-mode  but its not the final on-disk layout and the comandline will be slightly diffrent
[11:42] <vmayoral> mvo: great, thanks a lot. I'll have a look
[11:42] <mvo> vmayoral: happy to give you a binary and/or talk more later
[11:43] <vmayoral> mvo: that'll be great! let's do that
[11:47] <Chipaca> mvo: tell me about that branch; does it need reviewing, or is it in progress?
[11:48] <mvo> Chipaca: it needs to actually go back to WIP
[11:48] <Chipaca> done :)
[11:48] <mvo> Chipaca: because there were some changes during the sprint how its constructed etc
[11:48] <mvo> Chipaca: thanks!
[11:54] <vmayoral> sergiusens: getting https://gist.github.com/vmayoral/b3ea80d53d5fe25e3ed2 when trying to upload the snap to the store
[11:54] <vmayoral> sergiusens: the framework doesn't exist so it just rejects it
[11:56] <sergiusens> vmayoral, I'll accept it
[11:56] <sergiusens> vmayoral, do you have the link?
[11:59] <jdstrand> beuno: hey, pindonga was working on the issues found here: https://myapps.developer.ubuntu.com/dev/click-apps/3560/review/r/2/. it turned out to be that the server isn't setting the proper local and it has nothing to do with my snap. he approved the last one but isn't here now. would you mind approving this one?
[11:59] <vmayoral> sergiusens: so i actually don't think that the snap get's even submitted
[12:00] <vmayoral> sergiusens: it gets rejected before the review process complaining about the missing framework
[12:00]  * jdstrand -> gone for a few hours
[12:01] <beuno> vmayoral, I think you can click and ask for a manual review
[12:01] <vmayoral> sergiusens, beuno: stucked at this form https://myapps.developer.ubuntu.com/dev/click-apps/upload/?format=snap
[12:02] <vmayoral> i believe the manual review process is available in a later step, but let me know if i'm not looking at the right place
[12:03] <beuno> ah
[12:03] <beuno> so we need to add that framework first
[12:03] <beuno> nessita, ^
[12:03] <beuno> vmayoral, what's the string?
[12:07]  * Chipaca hopes it's vmayoral-the-magnificent
[12:09] <vmayoral> beuno: the framework has been named "raspivid"
[12:10] <nessita> beuno, hello
[12:10] <sergiusens> beuno, fyi, they use a framework, I guess we just need to add it to the framework list
[12:10] <beuno> vmayoral, done
[12:10] <sergiusens> beuno, I think i can do that
[12:10] <beuno> sergiusens, indeed
[12:10] <beuno> done already
[12:10] <nessita> even better
[12:11] <vmayoral> beuno: trying again, thanks!
[12:14] <vmayoral> beuno, sergiusens: it got in https://myapps.developer.ubuntu.com/dev/click-apps/3591
[12:14] <vmayoral> beuno, sergiusens: remaking the snap to fix the errors
[12:14] <sergiusens> vmayoral, awesome, no inlfight installation ftw ;-)
[12:15] <sergiusens> vmayoral, oh, run click-review from your host/laptop
[12:18] <vmayoral> sergiusens: in the store already, we were missing a "description" field.
[12:20] <sergiusens> vmayoral, great
[12:34] <lool> vmayoral: I found the issue with ros/cmake/tests
[12:35] <lool> vmayoral: in the process, I found it hard to move the directory around, clean didn't clean up enough
[12:35] <lool> vmayoral: that is, I copied to a different dir, ran snapcraft clean, and then snapcraft build failed because of a ton of generated files hardcoding the previous path
[12:35] <lool> vmayoral: this was really hard to fix, would you know a clean way?
[12:36] <lool> oh shit, I take it back, the error is still there  :-(
[12:37] <vmayoral> lool: so generally, "cakin_make clean" does a good job on that. Wanna join us in the room or should i "screen -x"?
=== davidcalle_ is now known as davidcalle
[13:08] <plars> elopio: sorry, I had already gone to sleep when you sent that
[13:08] <plars> elopio: elasticsearch seems to have blown up on me, so I can't see much right now, let me sort out what happened with that and get you to retry
[14:08] <olli> ueh
[14:28] <dholbach> sergiusens, https://code.launchpad.net/~dholbach/snapcraft/fix-pep8-and-doc-indentation/+merge/273195 updated
[14:51] <plars> elopio: when you have a chance, could you try again?
=== chihchun_afk is now known as chihchun
[14:56] <elopio> plars: I've launched a new run.
[15:22] <jdstrand> popey: hey, you around? (quick store review)
[15:22] <popey> jdstrand: ya
[15:23] <jdstrand> popey: would you mind taking a look at https://myapps.developer.ubuntu.com/dev/click-apps/3560/r/2/? there are two review failures but it is due to a server side issue that pindonga has the fix for bt that hasn't rolled out yet. the snap is fine
[15:23] <jdstrand> popey: he approved 0.1 and it had the same to review failures
[15:23] <popey> okay
[15:23] <jdstrand> two*
[15:31] <plars> elopio: It looks like it's done, but I didn't see it execute any test commands, last I saw it was trying to boot the test image
[15:32] <plars> elopio: perhaps the test image didn't boot?
[15:32] <elopio> plars: can you take a look at the script to see if I'm doing something stupid?
[15:32] <plars> elopio: I really think the test image didn't boot
[15:33] <elopio> plars: if that happens, there will be a ssh timeout and the test will fail.
[15:33] <jdstrand> popey: thanks! :)
[15:33] <elopio> but it always says pass. And I get no payload.
[15:33] <plars> elopio: no, it won't even get that far if it can't confirm that the image booted
[15:33] <plars> elopio: it won't even try to run the tests
[15:34] <plars> elopio: I'm kicking off a test job of mine to see if something else could be causing this
[15:34] <elopio> ok
[15:36] <plars> grr... logstash broke again
[15:36] <plars> this was supposed to work
[15:49] <victorp> anyone knows if I have to include a .service file on a snap service or if that is taken care on its own?
[15:50] <Chipaca> victorp: you do not have to include a .service file
[15:50] <Chipaca> victorp: in fact it will be ignored :)
[15:51] <victorp> Chipaca, so any idea why when I restart the service I have sideloaded as a snap I get an error ...ICLGcNeLFEPe.service failed to load: No such file or directory
[15:52] <Chipaca> victorp: that's a bug
[15:52] <Chipaca> victorp: in particular, one we've fixed
[15:52] <victorp> hehe
[15:52] <Chipaca> victorp: but i'm bad at tracking where it is in the pipeline to you
[15:52] <victorp> ok, I shall ignore then
[15:53] <victorp> Chipaca, np, I was just thinking I might be doing something wrong, I will ingore it for now and continue
[15:53] <Chipaca> the error is real, but if it's not blocking you, sure
[15:53] <victorp> is not blocking
[15:53] <Chipaca> ok :)
[15:53] <victorp> service runs fine from a restart of the pi
[15:53]  * Chipaca nods
[15:53] <Chipaca> victorp: and you can probably find the right service and restart it using systemctl, if i remember that bug correctly
[15:57] <Chipaca> hmm
[15:57] <Chipaca> victorp: just reproduced in latest stable, so the fix isn't there
[15:58] <victorp> ack
[15:58] <Chipaca> ... this might be a different bug
[15:59] <Chipaca> victorp: um. What I'm seeing is that it's not forgetting about the old service
[15:59] <Chipaca> victorp: that is, "snappy service status" shows the old one and the new one
[15:59] <victorp> oh
[15:59] <victorp> yeah I saw that too
[15:59] <Chipaca> victorp: but the new one is running alright
[16:03] <fgimenez_> have a nice weekend o/
=== chihchun is now known as chihchun_afk
[16:17] <Chipaca> pitti: you around?
[16:32] <mwenning> Hi snappy team, I did a sudo snappy update and then rebooted, grub comes up with system-b , goes thru a certain amount of booting, then gets a kernel panic and starts over.  Is there a way to manually switch back to system-a?
[16:34] <Chipaca> mwenning: it should switch back on its own
[16:34] <Chipaca> mwenning: what system is this?
[16:34] <Chipaca> of it *isn't* switching on its own, i'd love to have a look at the system, if it is image'able
[16:36] <mwenning> Chipaca, switch to snappy-internal