Chipaca | elopio: you around? | 00:28 |
---|---|---|
elopio | Chipaca: o/ here | 00:28 |
Chipaca | elopio: hiya | 00:28 |
Chipaca | elopio: http://pastebin.ubuntu.com/12607030/ | 00:29 |
Chipaca | elopio: halp :) | 00:29 |
Chipaca | elopio: i don't even know what failed :-/ | 00:29 |
elopio | Chipaca: we still have some work to do to improve that report. It doesn't tell you where it failed. | 00:30 |
Chipaca | exactly! :) | 00:30 |
elopio | you need to scroll back and search for a FAILED: message. | 00:30 |
Chipaca | elopio: and then it panics | 00:30 |
elopio | I'm willing to bet that it's this one: https://bugs.launchpad.net/snappy/+bug/1498293 | 00:30 |
ubottu | Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New] | 00:30 |
Chipaca | FAIL: /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go:172: failoverSuite.TestZeroSizeInitrd | 00:31 |
Chipaca | elopio: ^ is that it? | 00:31 |
elopio | um, no, damn it. I lost the bet. | 00:31 |
elopio | Chipaca: are you running that in a published branch? | 00:32 |
Chipaca | no, but i can publish it | 00:32 |
elopio | I've been running tests all day and that one hasn't failed. | 00:32 |
Chipaca | elopio: lp:~chipaca/snappy/current-data-dir | 00:32 |
elopio | Chipaca: publish it and I'll check if it's a real bug or something to fix on the test. It's late for you, right? | 00:33 |
elopio | Chipaca: also, you can run only that test: go run ./_integration-tests/main.go --snappy-from-branch --filter failoverSuite.TestZeroSizeInitrd | 00:33 |
elopio | something like that. | 00:33 |
Chipaca | yeh, i think i'm stopping here | 00:33 |
Chipaca | elopio: it failed again, and i'm off to bed | 00:39 |
Chipaca | elopio: it's entirely possible it's my branch that broke it; i haven't dug | 00:40 |
elopio | Chipaca: I'm running it. We had problems with that test last week. Not sure what's going on, but I'll find out. | 00:40 |
elopio | have a good night. | 00:40 |
Chipaca | k | 00:40 |
Chipaca | g'night :) | 00:40 |
=== Bro_ is now known as Guest34947 | ||
Guest34947 | hi everyone.. could you help me..? how to install ubuntu OS on Samsung Galaxy S3 | 01:15 |
Guest34947 | i'm a new to ubuntu, and remember that ubuntu have an OS for mobilephone... that's why i wan to try install it on my Galaxy S3.. btw last day i just service my Galaxy S3 (no Samsung service center cause no guarantee more for the device) and then one-chip/peripheral already change causes Galaxy previously sundently dead.. | 01:19 |
Guest34947 | hope somebody help me here... i really want to try have ubuntu and become a familiar with this beautiful OS | 01:20 |
Guest34947 | o yey... btw the OS on my Galaxy S3 now already the default; "Factory Reser" | 01:23 |
=== chihchun_afk is now known as chihchun | ||
Chipaca | elopio: no news about that test? | 06:04 |
elopio | Chipaca: I've run it like 20 times on it's own, like 5 times on the whole suite. It always passes here. | 06:05 |
elopio | I tried some in vivid, some in wily. | 06:05 |
Chipaca | elopio: with my branch? | 06:05 |
elopio | Chipaca: yes, of course. | 06:06 |
elopio | Chipaca: I looked at your changes and they have nothing to do with that test. | 06:06 |
elopio | Chipaca: where you found that FAIL: /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go:172: failoverSuite.TestZeroSizeInitrd | 06:06 |
elopio | you should have also an assertion error. Do you still have that trace around? | 06:07 |
Chipaca | elopio: i do | 06:08 |
Chipaca | a ver ... | 06:08 |
Chipaca | http://pastebin.ubuntu.com/12609009/ | 06:08 |
elopio | ... 0 files matching /boot/grub/a/snappy-selftest-initrd*, 1 expected | 06:09 |
elopio | that's an error I supposedly fixed already. | 06:09 |
Chipaca | branch is up to date with trunk fwiw | 06:10 |
elopio | Chipaca: yes, the fix is in your branch too. I don't understand, but your branch looks good, everything passes here, so you can ignore it. | 06:15 |
Chipaca | elopio: it almost sounds like you could review https://code.launchpad.net/~chipaca/snappy/current-data-dir/+merge/272691 :) | 06:15 |
elopio | I might give you a branch tomorrow with some more prints to understand what's going on in your machine. It sucks that it's a kvm and it still behaves differently. | 06:15 |
Chipaca | open /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go: no such file or directory | 06:16 |
Chipaca | ^ what's that about? | 06:16 |
elopio | Chipaca: http://paste.ubuntu.com/12609025/ | 06:16 |
Chipaca | ah well | 06:17 |
elopio | Chipaca: that one is https://bugs.launchpad.net/snappy/+bug/1468958 | 06:17 |
ubottu | Launchpad bug 1468958 in Snappy "selftests print "no such file or directory" on error" [Low,Triaged] | 06:17 |
Chipaca | ah! got it | 06:17 |
elopio | Chipaca: and yes, let me review your branch... | 06:18 |
Chipaca | oh, i dunno if i'll let you... i'll have to think about it | 06:18 |
elopio | well, you better think fast. I have a long queue of people eager to get my approval. | 06:19 |
Chipaca | also, i should mod goctest to also work with the integration tests | 06:19 |
Chipaca | finding red is a lot easier than finding "FAIL" | 06:19 |
elopio | that would be nice. | 06:20 |
elopio | Chipaca: but you shouldn't need to search fail. At the end of the run, we are printing the subunit result. | 06:20 |
Chipaca | elopio: here it just panics | 06:20 |
elopio | there are two problems with that. One that I was dumb and made it print only if the test passes. | 06:21 |
Chipaca | elopio: which is almost, but not quite, entirely not the same | 06:21 |
elopio | the second that it happens only when you run it from ./runtests. | 06:21 |
elopio | we will integrate the _integration-tests/main.go with go-subunit, so everything will be super awesome :) | 06:21 |
elopio | of course, the goctest pretty print will be faster. | 06:22 |
zyga | ogra_: hey, while building a snappy image for rpi2 according to your instructions I've got | 06:23 |
zyga | WARNING: this option should only be used to build azure images | 06:23 |
clobrano | morning :) | 06:27 |
elopio | Chipaca: why do you create the symlink twice? once in line 120, and again in 128. | 06:29 |
elopio | oh, nevermind, they are different. | 06:29 |
Chipaca | elopio: one is the /apps/$APP/current symlink, the other is the /var/lib/apps/$APP/current symlink | 06:30 |
Chipaca | was there a bug for this? | 06:32 |
* Chipaca goes looking | 06:32 | |
pitti | asac: df failing> hm, /proc missing or so? are you doing this in a chroot or so? | 06:35 |
dholbach | good morning | 06:53 |
elopio | Chipaca: +1. | 06:54 |
elopio | Chipaca: when you remove a snap that has an empty data dir, should the dir be removed? | 06:54 |
Chipaca | elopio: not necessarily, no | 06:55 |
Chipaca | elopio: data dirs are left alone, for now | 06:55 |
Chipaca | elopio: at some point we want garbage collection to remove the n+1th | 06:55 |
elopio | ok, just wondering. | 06:56 |
elopio | I'm going to bed now. See you soon. | 06:56 |
Chipaca | elopio: take care, que descances | 06:57 |
Chipaca | it's not yet 9am and i've already done a carnaugh map | 07:45 |
Chipaca | today is going to be interesting | 07:45 |
guest42315 | it's 10:51am :P | 07:51 |
guest42315 | you are -3 h, portugal? | 07:52 |
Chipaca | I'm -1, you're +1 :) | 07:53 |
Chipaca | or something | 07:53 |
* Chipaca checks | 07:53 | |
guest42315 | :D | 07:53 |
Chipaca | yeh, I'm +1 | 07:53 |
Chipaca | so you'r +3 | 07:53 |
guest42315 | right | 07:53 |
Chipaca | vmayoral|pc: got enable/disable working in branch locally. Need to add tests :) | 08:21 |
Chipaca | but first, coffee | 08:22 |
Chipaca | vmayoral|pc: turns out it's going to be very easy to also add it to the snappy command right now, so i'll probably do that as well | 08:22 |
* Chipaca ~> coffee | 08:22 | |
JamesTait | Good morning all; happy Tuesday, and happy World Heart Day! 😃 <3 | 08:23 |
vmayoral|pc | Chipaca: that's great, thanks | 08:39 |
Chipaca | JamesTait: u+1f491 through u+uf49f | 08:41 |
JamesTait | Chipaca, ❤ | 08:41 |
Chipaca | JamesTait: that's ctrl+shift+u, the hex code, space-or-enter | 08:41 |
Chipaca | and the second one should've read u+1f49f, not u+u... | 08:42 |
* Chipaca goes back to his coffee | 08:42 | |
vmayoral|pc | ogra_: ping | 08:45 |
zyga | sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1500759 | 08:56 |
ubottu | Launchpad bug 1500759 in Snapcraft "Add support for overriding the Makefile location in makefile part type" [Undecided,New] | 08:56 |
longsleep | Is there some documentation how the u-boot scripting should look like and how the partitions are named? Seems like my old stuff does use root=/dev/disk/by-label/system-a which does not seem to work anymore | 09:10 |
asac | pitti: doing it in lxc container | 09:11 |
asac | pitti: mtab wasnt created and also the /run/resolvconf link didnt have an existing target | 09:11 |
asac | Chipaca: did we land the current link for APP_DATA_PATH yet by any chance? would mvo do that? | 09:13 |
Chipaca | asac: branch is on trunk as of a couple of hours ago | 09:13 |
asac | neat | 09:13 |
Chipaca | asac: but i don't think it's released anywhere | 09:14 |
asac | Chipaca: waiting for review and then landing it on devel and 15.04? | 09:14 |
Chipaca | asac: *on trunk* | 09:14 |
asac | oh review is done already | 09:14 |
asac | yeah | 09:14 |
asac | so just landing... | 09:14 |
Chipaca | :) | 09:14 |
Chipaca | asac: what's "landing" in this context? | 09:16 |
Chipaca | asac: also note it does _not_ keep a symlink in the SNAP_APP_USER_DATA_PATH, just in SNAP_APP_DATA_PATH | 09:17 |
=== chihchun is now known as chihchun_afk | ||
Chipaca | ... we don't currently create SNAP_APP_USER_DATA_PATH ourselves, so it's all up to the app | 09:18 |
longsleep | ah my u-boot was broken, root=/dev/disk/by-label/system-a still works fine after all | 09:18 |
ogra_ | hey vmayoral|pc | 09:33 |
vmayoral|pc | ogra_: morning | 09:34 |
vmayoral|pc | ogra_: what do you think about https://bugs.launchpad.net/snappy/+bug/1500755? | 09:34 |
ubottu | Launchpad bug 1500755 in Snappy "vchiq not working on 4.2" [Undecided,New] | 09:34 |
=== vmayoral|pc is now known as vmayoral | ||
ogra_ | vmayoral, see the bug :) | 09:43 |
ogra_ | (will milestone it for 15.04.5 as soon as someone created the milestone) | 09:43 |
* Chipaca grovels for reviews of https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716 | 09:48 | |
vmayoral | ogra_: do you have any ideas for a quick fix that unblocks ourselves? | 09:51 |
ogra_ | you could re-build your own pi2 snap | 09:51 |
ogra_ | http://people.canonical.com/~platform/snappy/raspberrypi2/pi2_0.16_all.snap | 09:52 |
ogra_ | (there is "Rebuilding the oem snap" in the RPi2 section on https://developer.ubuntu.com/en/snappy/start/) | 09:53 |
ogra_ | make sure to keep the dtb's in place, they come from the kernel build (including overlay.tgz) | 09:54 |
pitti | asac: /etc/mtab should be a symlink to /proc/mounts | 09:57 |
ogra_ | it is :) | 09:59 |
davidcalle | ogra_, hey, in the raspi2 doc email, are you talking about future install instructions or is it for the image you just released? | 10:05 |
ogra_ | davidcalle, thats for current ... and i think i updated the doc accordingly | 10:05 |
=== chihchun_afk is now known as chihchun | ||
ogra_ | current stable is in the /~platform location ... dail/edge doesnt get actual img builds (like all other arches) | 10:06 |
ogra_ | *daily | 10:06 |
davidcalle | ogra_, thanks! | 10:09 |
vmayoral | ogra_: got the oem snap and ready to rebuild it, just don't quite understand what are the things that i need to change | 10:16 |
vmayoral | ogra_: i guess i need to compile http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/ and replace dtbs and overlay.tgz? | 10:17 |
vmayoral | ogra_: master branch seems to be at 3.19, shouldn't it be 4.2 since last snappy image uses that kernel? | 10:17 |
ogra_ | why would you recompile the kernel | 10:18 |
vmayoral | ogra_: is it just a matter of regenerating the pi2 snap? | 10:19 |
ogra_ | vmayoral, you want all of https://github.com/raspberrypi/firmware/tree/master/boot except for the dtb files and the overlay dir, they should be kept in place | 10:19 |
vmayoral | all right, any shortcut to replace the pi2 snap on an existing image or should i create a new snappy image? | 10:21 |
ogra_ | create a new one and make sure to use --developer-mode, else u-d-f will refuse to use local oem snaps | 10:27 |
Chipaca | beuno: happy birthday! | 10:27 |
ogra_ | vmayoral, oh, i'm silly, you can do it without a snap by just replacing the files /boot/uboot/ if you want to test it | 10:28 |
vmayoral | ogra_: will try that out, thanks | 10:28 |
ogra_ | (essentially the start* fixup* and bootcode.bin files) | 10:29 |
zyga | sergiusens: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720 | 10:30 |
sergiusens | elopio, fgimenez hey, can you check if something is wrong with tarmac? | 10:34 |
sergiusens | seems stuck; and I am missing an MP | 10:35 |
fgimenez | sergiusens, sure, i'll take a look | 10:35 |
sergiusens | fgimenez, ah, nevermind | 10:37 |
sergiusens | fgimenez, I was just confused | 10:37 |
fgimenez | sergiusens, ok np :) seems to be working fine http://paste.ubuntu.com/12610492/ | 10:39 |
sergiusens | fgimenez, oh, we need to update tarmac with the latest plainbox | 10:42 |
sergiusens | Chipaca, good morning; mind reviewing something? https://code.launchpad.net/~sergiusens/snapcraft/1500758/+merge/272728 | 10:44 |
Chipaca | sergiusens: trade you? | 10:45 |
sergiusens | Chipaca, sure | 10:45 |
fgimenez | sergiusens, done, now it has plainbox 0.23+ppa~ubuntu14.04.1 installed | 10:45 |
sergiusens | fgimenez, great, thanks | 10:45 |
sergiusens | fgimenez, also, zyga is here and willing to share all the setup for using git and merging/testing | 10:45 |
sergiusens | fgimenez, not sure how to coordinate that, but it would be nice to have this :-) | 10:46 |
sergiusens | Chipaca, just note that my MP says 'simple' ;-) | 10:46 |
Chipaca | sergiusens: you get to choose! | 10:47 |
fgimenez | sergiusens, indeed :) let me know if we can do anything from our side | 10:47 |
Chipaca | sergiusens: simple: https://code.launchpad.net/~chipaca/snappy/dddddirs/+merge/272430 | 10:47 |
Chipaca | sergiusens: short: https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716 | 10:47 |
Chipaca | :) | 10:47 |
Chipaca | sergiusens: LGTM, with a question :) | 10:49 |
sergiusens | Chipaca, approved dirs with a suggestion :-) | 10:50 |
Chipaca | sergiusens: it already is snappy/dirs | 10:50 |
Chipaca | as in launchpad.net/snappy/dirs | 10:51 |
Chipaca | launchpad.net/snappy/snappy just feels wrong already :) | 10:51 |
sergiusens | Chipaca, oh, :-) | 10:51 |
sergiusens | Chipaca, I guess it is fine, we just need to move launchpad.net/snappy/snappy/*.go to lanuchpad.net/snappy :-D | 10:52 |
Chipaca | sergiusens: ... sooon ... :) | 10:52 |
sergiusens | or use vendoring ;-) | 10:52 |
sergiusens | Chipaca, ok, so I wait for you to approve my MP now ;-) | 10:52 |
Chipaca | d'oh :) | 10:53 |
Chipaca | sergiusens: where does vendoring come into the equation there? | 10:54 |
sergiusens | Chipaca, nice filepaths and GOPATH goodies | 10:54 |
ricmm | vmayoral: https://launchpad.net/ubuntu/+source/linux-raspi2 | 13:00 |
ricmm | vmayoral: here too http://kernel.ubuntu.com/git/ubuntu/ubuntu-wily.git/log/?h=raspi2 | 13:03 |
vmayoral | ricmm: got it | 13:03 |
clobrano | Finally got time to finish work on Bug #1496319. One question: is <snapname>.json.additional file content fixed for any reason? I mean, could I add a new field to it? | 13:18 |
ubottu | bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 | 13:18 |
* clobrano thinks it should have used the QUESTION tag | 13:28 | |
clobrano | QUESTION: Finally got time to finish work on Bug #1496319. One question: is <snapname>.json.additional file content fixed for any reason? I mean, could I add a new field to it? | 13:29 |
ubottu | bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 | 13:29 |
sergiusens | clobrano, using QUESTION is only a thing when some live broadcast is happening | 13:35 |
sergiusens | if not it generally is, fire and wait or get the right person | 13:35 |
sergiusens | ;-) | 13:35 |
clobrano | sergiusens: I wasn't sure :), thanks | 13:35 |
sergiusens | so... Chipaca maybe? ^ | 13:35 |
Chipaca | what's the question again? | 13:36 |
clobrano | Chipaca: hi :), I was thinking about adding a new field to <snapname>.json.additional file | 13:37 |
clobrano | trying to implement Bug #1496319 | 13:37 |
ubottu | bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 | 13:37 |
Chipaca | please don't implement bugs! :-p | 13:37 |
* Chipaca reads | 13:38 | |
clobrano | Chipaca: I expected that :D | 13:38 |
Chipaca | clobrano: let me check wrt reworking of hw-assign | 13:41 |
Chipaca | clobrano: right! so there will be a redesign, but not for a while, so let's do this :) | 13:48 |
Chipaca | clobrano: what is it you propose to fix that? | 13:49 |
clobrano | Chipaca: I'm thinking about adding a symlink_path field, to keep information about which path links to which HW device | 13:49 |
clobrano | Chipaca: this way, when using hw-unassign on a hw device, I can see that there is also a symlink to unassign | 13:51 |
Chipaca | clobrano: now i understand your question and everything! | 13:54 |
Chipaca | clobrano: no issues with adding an additional field to the .additional json | 13:54 |
clobrano | Chipaca: yep, I took a long way to explain it :D | 13:55 |
clobrano | Chipaca: fine then | 13:55 |
clobrano | Chipaca: thanks | 13:56 |
=== davidcalle_ is now known as davidcalle | ||
zyga | fgimenez: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720 | 14:22 |
zyga | fgimenez: not entirely done (but it's safe to land if it doesn't blow up as it's not the default) | 14:22 |
zyga | fgimenez: I'll go and do unit tests next | 14:22 |
zyga | fgimenez: but I need to patch something first around in another project | 14:22 |
zyga | fgimenez: the idea behind hat branch is to get rid of the shell script that does unholy things with plainbox and just use proper APIs | 14:23 |
fgimenez | zyga, yes we need that :) | 14:23 |
zyga | fgimenez: (the apis in plainbox are not in plainbox.public yet but they will be soon and the ones used here are the candidate APIs anyway) | 14:24 |
zyga | fgimenez: please have a look at the UX there | 14:24 |
zyga | fgimenez: I tried to make it better than the old script | 14:24 |
fgimenez | zyga, ok thanks i'll ping you back | 14:24 |
zyga | fgimenez: after you look at the basics I'd like to discuss how to integrate unit tests -- there are two ideas I have | 14:24 |
zyga | fgimenez: thanks :) | 14:25 |
* guest42315 ubuntuonair in 20 min http://ubuntuonair.com/ | 14:38 | |
longsleep | Chipaca: Hey, i just got forwared a mail that christine seem to have added us to the contributor agreement, while i am still not seeing it in the members list i now wonder how you folks know that i am contributing for this company | 15:00 |
* zyga stands up | 15:05 | |
Chipaca | longsleep: that's yet another good question I don't know the answer to. | 15:28 |
Chipaca | longsleep: maybe because the one that filled out the cla for the company tells us somehow? | 15:29 |
* Chipaca is asking elsewhere as well :) | 15:29 | |
vmayoral | sergiusens: http://paste.ubuntu.com/12613213/ | 15:30 |
longsleep | Chipaca: well, at least the confirmation mail did not say anything helpful in that regard. | 15:44 |
Chipaca | longsleep: turns out, there wasn't a process | 15:44 |
longsleep | :D | 15:44 |
Chipaca | longsleep: so, the person that signed the cla on behalf of the company | 15:45 |
Chipaca | longsleep: needs to create a group | 15:45 |
Chipaca | longsleep: and let us know what group that is | 15:45 |
longsleep | aha - can it be a existing group? | 15:45 |
Chipaca | longsleep: and then we add that group to the CLA group | 15:45 |
longsleep | and how do we let you know | 15:45 |
ogra_ | well, and it should be a controlled group ... not one everyone can join ;) | 15:45 |
Chipaca | longsleep: sure, as long as membership in that group implies they can submit code in the company's name | 15:46 |
longsleep | group is strukturag - already is there | 15:46 |
longsleep | yes | 15:46 |
longsleep | ok, but the one who has submitted is not in that group yet | 15:46 |
longsleep | oh my let me fix that | 15:46 |
longsleep | Chipaca: ok, so how can we let you know that it is this group? | 15:48 |
=== chihchun is now known as chihchun_afk | ||
Chipaca | longsleep: you should've received an invite | 15:59 |
Chipaca | longsleep: (in future we might ask that the person signing is owner of the group; for now, this'll do) | 16:00 |
sergiusens | zyga, https://code.launchpad.net/~sergiusens/snapcraft/scons_options/+merge/272817 | 16:18 |
vmayoral | sergiusens: https://gist.github.com/vmayoral/0ddc3b9c50198cb182a4 | 16:24 |
longsleep | Chipaca: ok great, worked perfectly - thank you ! | 16:30 |
rickspencer3 | ogra_ hey | 18:08 |
ogra_ | yo | 18:08 |
rickspencer3 | soooo, pwm, we followed your instructions to enable it, but, errr | 18:08 |
rickspencer3 | not sure it is working | 18:08 |
* rickspencer3 gets a pastebin | 18:09 | |
ogra_ | cat /sys/firmware/devicetree/base/soc/pwm@7e20c000/status | 18:10 |
ogra_ | if that says "okay" it is enabled | 18:10 |
rickspencer3 | http://pastebin.ubuntu.com/12615323/ | 18:10 |
* rickspencer3 looks | 18:10 | |
rickspencer3 | it says "okay" | 18:11 |
ogra_ | well, then it should work ... | 18:11 |
ogra_ | there is another pwm overlay (twochannel) you could tyr editing config.txt and use that instead of the basic one from ym instructions | 18:12 |
ogra_ | pwm-2chan-overlay.dtb | 18:12 |
ogra_ | perhaps that behaves differently | 18:12 |
ogra_ | https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L419 | 18:14 |
ogra_ | so you can obviously use: dtoverlay=pwm,pin=18 | 18:15 |
* ogra_ tries | 18:16 | |
ogra_ | rickspencer3, the export node is a toggle ... only takes 0/1 | 18:29 |
ogra_ | rickspencer3, if i echo 1 into it i see a /sys/class/pwm/pwmchip0/pwm1 being created | 18:30 |
* ogra_ doesnt have the slightest clue what he is doing | 18:31 | |
rickspencer3 | ogra_ ok, we'll keep banging on it here and see where we get | 18:31 |
ogra_ | root@localhost:~# ls /sys/class/pwm/pwmchip0/pwm1/ | 18:31 |
ogra_ | duty_cycle enable period polarity power uevent | 18:31 |
ogra_ | does that look like what you want ? | 18:31 |
ogra_ | looking at online docs it seems the interface has changed with 4.2 ... seems in older versions there were nodes like "frequency" as well | 18:33 |
* ogra_ assumes thats replaced by "period" | 18:33 | |
sergiusens | elopio, mind looking at scons again? | 19:52 |
elopio | sergiusens: sure. | 19:52 |
sergiusens | elopio, I even added the missing test I forgot the first time around :-/ | 19:52 |
elopio | sergiusens: excuses :p | 19:52 |
sergiusens | elopio, I blame zyga | 19:53 |
sergiusens | elopio, thanks | 20:05 |
elopio | np | 20:06 |
sergiusens | elopio, btw, did you see zyga's branch? | 20:06 |
elopio | sergiusens: por encimita. | 20:06 |
sergiusens | elopio, it is good because we can autocomplete and select tests specifically or with a filter | 20:07 |
elopio | ah, that's cool. | 20:08 |
elopio | he says it doesn't yet support the unittests. But that's ok, we only need to clean up the weird script we use to launch the plainbox tests. | 20:09 |
elopio | I'll give it a try after lunch. | 20:09 |
victorp | kyrofa, ping | 20:26 |
kyrofa | Hey victorp :) | 20:26 |
victorp | hi kyrofa | 20:26 |
sergiusens | zyga, lp:~sergiusens/snapcraft/1501035 | 20:26 |
victorp | I am just playing with the rpi and installed your piglowtop snap | 20:27 |
victorp | \o/ | 20:27 |
victorp | v awesome | 20:27 |
victorp | I was wondering if you had a bzr branch for it, that I can use as an example to learn a bit more about snappy | 20:27 |
kyrofa | victorp, not bzr, but git | 20:28 |
kyrofa | victorp: https://github.com/kyrofa/piglowtop | 20:28 |
victorp | kyrofa, :P | 20:29 |
kyrofa | victorp, there are two READMEs-- the main one is for the software itself, and the snappy-specific one is in meta/ | 20:29 |
victorp | kyrofa, awesome! | 20:30 |
victorp | thanks | 20:30 |
kyrofa | victorp, any time! | 20:30 |
zyga | sergiusens: it doesn't work | 21:01 |
sergiusens | zyga, because of python3? | 21:02 |
zyga | sergiusens: py3versions | 21:02 |
zyga | http://pastebin.ubuntu.com/12617891/ | 21:03 |
sergiusens | zyga, yeah, skip those on wily, it depends on the MP you reviewed earlier | 21:03 |
zyga | sergiusens: py3versions itself crashes | 21:03 |
zyga | sergiusens: I think it's different | 21:03 |
sergiusens | ah | 21:03 |
zyga | sergiusens: it crashes because py3versions is a dh-thing | 21:03 |
zyga | sergiusens: and I suspsecy you don't have that in the stage python | 21:03 |
zyga | sergiusens: (python3-minimal) hmm | 21:04 |
sergiusens | zyga, snappy shell and try it maybe | 21:04 |
zyga | I wonder what is error 2 | 21:04 |
zyga | oh! | 21:04 |
zyga | cool | 21:04 |
zyga | snappy shell -- no such command? | 21:04 |
sergiusens | snapcraft shell | 21:05 |
sergiusens | sorry | 21:05 |
sergiusens | zyga, ^ | 21:05 |
zyga | ah | 21:05 |
zyga | sergiusens: that doesn't work | 21:05 |
zyga | (venv.x200t)zyga@x200t:/tmp/1501035/integration-tests/data/pip-requirements$ snapcraft shell | 21:05 |
zyga | py3versions -i | 21:05 |
zyga | pyversions -i | 21:05 |
zyga | it needs py3versions itself :) | 21:06 |
zyga | /tmp/tmpgzjdflwl: 7: export: python3.5/dist-packages: bad variable name | 21:06 |
sergiusens | oh, python 3.5 | 21:07 |
sergiusens | darn wily | 21:07 |
plars | "write /tmp/diskimage045123107/boot/a/dtbs/r8a7791-henninger.dtb: no space left on device" | 21:13 |
plars | I get this when trying to create the raspberry pi image | 21:14 |
plars | ah, nm, I didn't specify the device | 21:16 |
ogra_ | how do you create it ? | 21:16 |
ogra_ | phew | 21:17 |
plars | ogra_: I got it now, but what really surprised me is that udf didn't exit with a non-zero rc | 21:17 |
* ogra_ feels like he had enough disasters tonight :P dont shock me | 21:17 | |
plars | haha, sorry :) | 21:17 |
ogra_ | :) | 21:17 |
ogra_ | plars, well, if you dont specify --device it simply tries the generic tarball on top | 21:18 |
ogra_ | its not an error so it doesnt exit nonzero | 21:19 |
ogra_ | (the space issu is indeed) | 21:19 |
ogra_ | (and probably worth filing a bug) | 21:19 |
plars | ogra_: I'd like to chat (not urgent, sometime when you're having a better day), about rpi2 automation | 21:19 |
ogra_ | yeah | 21:20 |
plars | ogra_: it mostly works right now, but I wasn't able to handle reading the environment from the actual image partition that I'm testing | 21:20 |
plars | ogra_: so it won't cope well if we try to test upgrade/rollback | 21:20 |
ogra_ | you mean uboot.env ? | 21:20 |
plars | ogra_: mostly just trying to work around the fact that rpi2 can only boot from one place | 21:20 |
plars | ogra_: yeah, I'm booting an ubuntu image off the SD card, with a lot of uboot bits from snappy. It reads a gpio to decide whether to keep booting from the sd card, or pull the kernel/initrd from usb (where I wrote the new image) and simulate the snappy boot process from the bits that are on usb | 21:21 |
plars | ogra_: so obviously there's a big downside that we don't actually test the bootloader from the new image, but given that we can't chainload and only have a single boot location, I don't see any way around that | 21:22 |
ogra_ | yeah | 21:22 |
ogra_ | well ... the rpi has config.txt .... | 21:22 |
ogra_ | you could mangle the kernel=uboot.bin line | 21:23 |
plars | ogra_: but the other issue is that if we do an update/rollback, those settings get written to uboot.env on the usb stick, and I don't know of a good way to selectively read in just the values I care about from there | 21:23 |
plars | ogra_: but how do I get it back if things go wrong? | 21:23 |
plars | ogra_: I need to know that it will fall back to the right place no matter what | 21:23 |
ogra_ | so you would still use the pre-loader from SD but could point to a different uboot | 21:23 |
plars | ogra_: but I don't think I could point it to the one on usb, it would still have to be on the sd card somehow | 21:24 |
plars | which I can't safely overwrite | 21:24 |
ogra_ | yeah | 21:24 |
ogra_ | you would need both uboots on the SD and duplicate the uboot config | 21:24 |
plars | there may not be any good options, but I figured if anyone would have ideas, it would probably be you :) | 21:24 |
ogra_ | heh | 21:24 |
plars | ogra_: if anything comes to mind, just let me know what your thoughts are | 21:25 |
ogra_ | well, i think what yu do is the sanest you can do ... | 21:25 |
plars | wow, did I just get accused of being sane? | 21:25 |
ogra_ | you can indeed edit uboot.env from anywhere using fw_setenv ... | 21:25 |
plars | I guess I'm making progress | 21:25 |
plars | :) | 21:25 |
ogra_ | hahaha | 21:25 |
plars | ogra_: it works pretty reliably for most things, just a few limitations that are annoying | 21:26 |
ogra_ | what you need for fw_setenv is the right config ... we ship that in /etc/fw_env.config ... | 21:26 |
plars | ogra_: there's some strange magic there | 21:28 |
plars | ogra_: which entries end up getting modified when you do an update? | 21:28 |
ogra_ | snappy_ab and snappy_trial_boot | 21:29 |
ogra_ | err nnno | 21:29 |
ogra_ | snappy_ab and snappy_mode | 21:30 |
plars | ogra_: yeah, if that's all, then I could possibly let it just modify the one on the sd card, but I'd have to remount after booting, and I've kind of lost control at that point (nor do I want it updating the kernel for me or any other files at that location) | 21:30 |
ogra_ | well, the kernel will always only be updated on the other partition | 21:30 |
ogra_ | or in case of uboot the "other dir" | 21:31 |
plars | ogra_: but it's still under /boot/uboot/{a,b} | 21:31 |
plars | ogra_: if I simply remount /boot/uboot after booting and force it to point to the mmc, then I really haven't accomplished anything | 21:32 |
plars | in fact, I could be causing more problems, since it won't persist after the reboot | 21:32 |
ogra_ | if i'm booted into the system-a partition the kernel from /boot/uboot/a is used as well ... the update switches snappy_ab=b and snappy_mode=try ... then it reboots into system-b ... systemd sets snappy_mode=regular at the end of the boot process and you are fine ... | 21:32 |
plars | I don't have control after provisioning happens, from that point forward it's completely up to the test to do the right thing (which will come from somewhere else) | 21:33 |
ogra_ | ... or you fail and snappy_mode is still set to try ... so the script recognizes it should switch back to a and does that | 21:33 |
zyga | ogra_: you're still up? | 21:33 |
plars | no, he should be sleeping, and I should quit bothering him :) | 21:34 |
ogra_ | zyga, i rarely go to bed before 2am ... worse is that i'm still working :P | 21:34 |
plars | :( | 21:34 |
zyga | ogra_: well, what can I say | 21:34 |
ogra_ | not your fault | 21:34 |
zyga | me too | 21:34 |
zyga | guys are having beer next to me though | 21:34 |
zyga | nope, though that's not bothering me :) | 21:35 |
ogra_ | it is one of these days where you recognize "oh, i forgot to seed that minor package, lets quickly do that and finishe the day" ... you seed it and the world explodes in your face :P | 21:35 |
ogra_ | and now i'm still mopping up the mess | 21:35 |
zyga | ogra_: what did you seed? | 21:37 |
zyga | ogra_: bootchart? | 21:37 |
ogra_ | fwupd ... | 21:37 |
ogra_ | zyga, and this is what changed in the image .... http://paste.ubuntu.com/12617877/ | 21:37 |
ogra_ | rather unexpected | 21:37 |
* zyga looks | 21:38 | |
zyga | useless laggy hotel wifi | 21:40 |
zyga_ | ogra2: considering that upstream does glib+gtk apps that's not unexpected, why did it explode? | 21:40 |
zyga_ | ohh | 21:41 |
zyga_ | libGDK is there too | 21:41 |
zyga_ | that's curious ;0 | 21:41 |
zyga_ | ogra2: it's 2015, daemons come with guis ;) | 21:41 |
ogra_ | zyga_, well, not sure you wnat your drone to be capable of convertingjpeg to tiff and provide the ic via XDMCP | 21:41 |
zyga_ | ogra_: heheh | 21:42 |
ogra_ | *provide the pic | 21:42 |
ogra_ | but at least you could store all the info about that in dconf then :P | 21:42 |
zyga_ | ogra_: dconf I understand but x11 | 21:42 |
zyga_ | ogra_: how did that package get through review? | 21:43 |
ogra_ | it didnt yet | 21:43 |
ogra_ | comes from our PPA | 21:43 |
zyga_ | ogra_: ohhh | 21:43 |
ogra_ | this is vivid | 21:43 |
zyga_ | ogra_: yeah, that's trustworthy and safe ;) | 21:43 |
zyga_ | ogra_: is that your ppa or 3rd party? | 21:43 |
ogra_ | the official snappy ppa | 21:43 |
* zyga_ should stop bothering ogra and just let everyone go to bed | 21:43 | |
zyga_ | ogra_: O_o | 21:44 |
ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages | 21:44 |
plars | sleep ftw! | 21:45 |
ogra_ | heh | 21:45 |
plars | oh, still a bit early here I guess :) | 21:45 |
* ogra_ still needs to revert the mess and build a test image | 21:45 | |
zyga_ | ogra_: good luck | 21:47 |
ogra_ | :) | 21:47 |
ogra_ | well, its mostly waiting | 21:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!