[00:28] <Chipaca> elopio: you around?
[00:28] <elopio> Chipaca: o/ here
[00:28] <Chipaca> elopio: hiya
[00:29] <Chipaca> elopio: http://pastebin.ubuntu.com/12607030/
[00:29] <Chipaca> elopio: halp :)
[00:29] <Chipaca> elopio: i don't even know what failed :-/
[00:30] <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:31] <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:32] <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:33] <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:39] <Chipaca> elopio: it failed again, and i'm off to bed
[00:40] <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 :)
[01:15] <Guest34947> hi everyone.. could you help me..? how to install ubuntu OS on Samsung Galaxy S3
[01:19] <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:20] <Guest34947> hope somebody help me here... i really want to try have ubuntu and become a familiar with this beautiful OS
[01:23] <Guest34947> o yey... btw the OS on my Galaxy S3 now already the default; "Factory Reser"
[06:04] <Chipaca> elopio: no news about that test?
[06:05] <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:06] <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:07] <elopio> you should have also an assertion error. Do you still have that trace around?
[06:08] <Chipaca> elopio: i do
[06:08] <Chipaca> a ver ...
[06:08] <Chipaca> http://pastebin.ubuntu.com/12609009/
[06:09] <elopio> ... 0 files matching /boot/grub/a/snappy-selftest-initrd*, 1 expected
[06:09] <elopio> that's an error I supposedly fixed already.
[06:10] <Chipaca> branch is up to date with trunk fwiw
[06:15] <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:16] <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:17] <Chipaca> ah well
[06:17] <elopio> Chipaca: that one is https://bugs.launchpad.net/snappy/+bug/1468958
[06:17] <Chipaca> ah! got it
[06:18] <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:19] <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:20] <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:21] <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:22] <elopio> of course, the goctest pretty print will be faster.
[06:23] <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:27] <clobrano> morning :)
[06:29] <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:30] <Chipaca> elopio: one is the /apps/$APP/current symlink, the other is the /var/lib/apps/$APP/current symlink
[06:32] <Chipaca> was there a bug for this?
[06:32]  * Chipaca goes looking
[06:35] <pitti> asac: df failing> hm, /proc missing or so? are you doing this in a chroot or so?
[06:53] <dholbach> good morning
[06:54] <elopio> Chipaca: +1.
[06:54] <elopio> Chipaca: when you remove a snap that has an empty data dir, should the dir be removed?
[06:55] <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:56] <elopio> ok, just wondering.
[06:56] <elopio> I'm going to bed now. See you soon.
[06:57] <Chipaca> elopio: take care, que descances
[07:45] <Chipaca> it's not yet 9am and i've already done a carnaugh map
[07:45] <Chipaca> today is going to be interesting
[07:51] <guest42315> it's 10:51am :P
[07:52] <guest42315> you are -3 h, portugal?
[07:53] <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
[08:21] <Chipaca> vmayoral|pc: got enable/disable working in branch locally. Need to add tests :)
[08:22] <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:23] <JamesTait> Good morning all; happy Tuesday, and happy World Heart Day! 😃  <3
[08:39] <vmayoral|pc> Chipaca: that's great, thanks
[08:41] <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:42] <Chipaca> and the second one should've read u+1f49f, not u+u...
[08:42]  * Chipaca goes back to his coffee
[08:45] <vmayoral|pc> ogra_: ping
[08:56] <zyga> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1500759
[09:10] <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:11] <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:13] <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:14] <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:16] <Chipaca> asac: what's "landing" in this context?
[09:17] <Chipaca> asac: also note it does _not_ keep a symlink in the SNAP_APP_USER_DATA_PATH, just in SNAP_APP_DATA_PATH
[09:18] <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:33] <ogra_> hey vmayoral|pc
[09:34] <vmayoral|pc> ogra_: morning
[09:34] <vmayoral|pc> ogra_: what do you think about https://bugs.launchpad.net/snappy/+bug/1500755?
[09:43] <ogra_> vmayoral, see the bug :)
[09:43] <ogra_> (will milestone it for 15.04.5 as soon as someone created the milestone)
[09:48]  * Chipaca grovels for reviews of https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716
[09:51] <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:52] <ogra_> http://people.canonical.com/~platform/snappy/raspberrypi2/pi2_0.16_all.snap
[09:53] <ogra_> (there is "Rebuilding the oem snap" in the RPi2 section on https://developer.ubuntu.com/en/snappy/start/)
[09:54] <ogra_> make sure to keep the dtb's in place, they come from the kernel build (including overlay.tgz)
[09:57] <pitti> asac: /etc/mtab should be a symlink to /proc/mounts
[09:59] <ogra_> it is :)
[10:05] <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:06] <ogra_> current stable is in the /~platform location ... dail/edge doesnt get actual img builds (like all other arches)
[10:06] <ogra_> *daily
[10:09] <davidcalle> ogra_, thanks!
[10:16] <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:17] <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:18] <ogra_> why would you recompile the kernel
[10:19] <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:21] <vmayoral> all right, any shortcut to replace the pi2 snap on an existing image or should i create a new snappy image?
[10:27] <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:28] <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:29] <ogra_> (essentially the start* fixup* and bootcode.bin files)
[10:30] <zyga> sergiusens: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720
[10:34] <sergiusens> elopio, fgimenez hey, can you check if something is wrong with tarmac?
[10:35] <sergiusens> seems stuck; and I am missing an MP
[10:35] <fgimenez> sergiusens, sure, i'll take a look
[10:37] <sergiusens> fgimenez, ah, nevermind
[10:37] <sergiusens> fgimenez, I was just confused
[10:39] <fgimenez> sergiusens, ok np :) seems to be working fine http://paste.ubuntu.com/12610492/
[10:42] <sergiusens> fgimenez, oh, we need to update tarmac with the latest plainbox
[10:44] <sergiusens> Chipaca, good morning; mind reviewing something? https://code.launchpad.net/~sergiusens/snapcraft/1500758/+merge/272728
[10:45] <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:46] <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:47] <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:49] <Chipaca> sergiusens: LGTM, with a question :)
[10:50] <sergiusens> Chipaca, approved dirs with a suggestion :-)
[10:50] <Chipaca> sergiusens: it already is snappy/dirs
[10:51] <Chipaca> as in launchpad.net/snappy/dirs
[10:51] <Chipaca> launchpad.net/snappy/snappy just feels wrong already :)
[10:51] <sergiusens> Chipaca, oh, :-)
[10:52] <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:53] <Chipaca> d'oh :)
[10:54] <Chipaca> sergiusens: where does vendoring come into the equation there?
[10:54] <sergiusens> Chipaca, nice filepaths and GOPATH goodies
[13:00] <ricmm> vmayoral: https://launchpad.net/ubuntu/+source/linux-raspi2
[13:03] <ricmm> vmayoral: here too http://kernel.ubuntu.com/git/ubuntu/ubuntu-wily.git/log/?h=raspi2
[13:03] <vmayoral> ricmm: got it
[13:18] <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:28]  * clobrano thinks it should have used the QUESTION tag
[13:29] <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:35] <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:36] <Chipaca> what's the question again?
[13:37] <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] <Chipaca> please don't implement bugs! :-p
[13:38]  * Chipaca reads
[13:38] <clobrano> Chipaca: I expected that :D
[13:41] <Chipaca> clobrano: let me check wrt reworking of hw-assign
[13:48] <Chipaca> clobrano: right! so there will be a redesign, but not for a while, so let's do this :)
[13:49] <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:51] <clobrano> Chipaca: this way, when using hw-unassign on a hw device, I can see that there is also a symlink to unassign
[13:54] <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:55] <clobrano> Chipaca: yep, I took a long way to explain it :D
[13:55] <clobrano> Chipaca: fine then
[13:56] <clobrano> Chipaca: thanks
[14:22] <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:23] <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:24] <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:25] <zyga> fgimenez: thanks :)
[14:38]  * guest42315 ubuntuonair in 20 min http://ubuntuonair.com/
[15:00] <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:05]  * zyga stands up
[15:28] <Chipaca> longsleep: that's yet another good question I don't know the answer to.
[15:29] <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:30] <vmayoral> sergiusens:  http://paste.ubuntu.com/12613213/
[15:44] <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:45] <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:46] <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:48] <longsleep> Chipaca: ok, so how can we let you know that it is this group?
[15:59] <Chipaca> longsleep: you should've received an invite
[16:00] <Chipaca> longsleep: (in future we might ask that the person signing is owner of the group; for now, this'll do)
[16:18] <sergiusens> zyga, https://code.launchpad.net/~sergiusens/snapcraft/scons_options/+merge/272817
[16:24] <vmayoral> sergiusens:  https://gist.github.com/vmayoral/0ddc3b9c50198cb182a4
[16:30] <longsleep> Chipaca: ok great, worked perfectly - thank you !
[18:08] <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:09]  * rickspencer3 gets a pastebin
[18:10] <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:11] <rickspencer3> it says "okay"
[18:11] <ogra_> well, then it should work ...
[18:12] <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:14] <ogra_> https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L419
[18:15] <ogra_> so you can obviously use: dtoverlay=pwm,pin=18
[18:16]  * ogra_ tries 
[18:29] <ogra_> rickspencer3, the export node is a toggle ... only takes 0/1
[18:30] <ogra_> rickspencer3, if i echo 1 into it i see a /sys/class/pwm/pwmchip0/pwm1 being created
[18:31]  * 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:33] <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" 
[19:52] <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:53] <sergiusens> elopio, I blame zyga
[20:05] <sergiusens> elopio, thanks
[20:06] <elopio> np
[20:06] <sergiusens> elopio, btw, did you see zyga's branch?
[20:06] <elopio> sergiusens: por encimita.
[20:07] <sergiusens> elopio, it is good because we can autocomplete and select tests specifically or with a filter
[20:08] <elopio> ah, that's cool.
[20:09] <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:26] <victorp> kyrofa, ping
[20:26] <kyrofa> Hey victorp :)
[20:26] <victorp> hi kyrofa
[20:26] <sergiusens> zyga, lp:~sergiusens/snapcraft/1501035
[20:27] <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:28] <kyrofa> victorp, not bzr, but git
[20:28] <kyrofa> victorp: https://github.com/kyrofa/piglowtop
[20:29] <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:30] <victorp> kyrofa, awesome!
[20:30] <victorp> thanks
[20:30] <kyrofa> victorp, any time!
[21:01] <zyga> sergiusens: it doesn't work
[21:02] <sergiusens> zyga, because of python3?
[21:02] <zyga> sergiusens: py3versions
[21:03] <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:04] <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:05] <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:06] <zyga> it needs py3versions itself :)
[21:06] <zyga> /tmp/tmpgzjdflwl: 7: export: python3.5/dist-packages: bad variable name
[21:07] <sergiusens> oh, python 3.5
[21:07] <sergiusens> darn wily
[21:13] <plars> "write /tmp/diskimage045123107/boot/a/dtbs/r8a7791-henninger.dtb: no space left on device"
[21:14] <plars> I get this when trying to create the raspberry pi image
[21:16] <plars> ah, nm, I didn't specify the device
[21:16] <ogra_> how do you create it ?
[21:17] <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:18] <ogra_> plars, well, if you dont specify --device it simply tries the generic tarball on top
[21:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:28] <plars> ogra_: there's some strange magic there
[21:28] <plars> ogra_: which entries end up getting modified when you do an update?
[21:29] <ogra_> snappy_ab and snappy_trial_boot
[21:29] <ogra_> err nnno
[21:30] <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:31] <ogra_> or in case of uboot the "other dir"
[21:31] <plars> ogra_: but it's still under /boot/uboot/{a,b}
[21:32] <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:33] <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:34] <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:35] <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:37] <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:38]  * zyga looks
[21:40] <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:41] <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:42] <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:43] <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:44] <zyga_> ogra_: O_o
[21:44] <ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
[21:45] <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:47] <zyga_> ogra_: good luck
[21:47] <ogra_> :)
[21:47] <ogra_> well, its mostly waiting