[00:42] <tgm4883> Are snappy apps able to play audio?
[07:18] <fgimenez> good morning
[07:21] <davidcalle> Morning o/
[07:43] <dholbach> good morning
[07:59] <zyga> yashi_: hey
[08:00] <zyga> yashi_: how are you, do you have a moment to talk about https://code.launchpad.net/~yashi/snapcraft/snapcraft/+merge/272337
[08:22] <sergiusens> vmayoral|pc, lp:~sergiusens/snapcraft/catkin
[08:22] <sergiusens> vmayoral|pc, I'm still stabilizing it though
[08:22] <vmayoral|pc> sergiusens: awesome, thanks
[08:38] <JamesTait> Good morning all; happy Wednesday, and happy International Translation Day! 😃
[08:45] <ogra_> Guten Morgen; einen schönen Mittwoch, und einen schönen Tag der Internationalen Übersetzung! 😃
[08:46] <ogra_> JamesTait, appropriate ?
[08:46] <JamesTait> ogra_, ja, sicher!
[08:47] <ogra_> :)
[08:48] <JamesTait> I never quite grasped German (I struggled with ein, einer, einem and all that), but my son is learning it at school now, so I'm having another go. 😝
[08:48] <ogra_> good luck :)
[08:49] <JamesTait> Danke. 😉
[08:58] <lool> sergiusens: are build-packages from yaml inherited across plugins?
[08:58] <lool> sergiusens: it seems not
[08:58] <lool> sergiusens: so if I'm extending python3-project, and python3-project said build-packages: python3-pip, my plugin wont pull pip
[08:58] <lool> I need to repeat build-packages
[08:59] <sergiusens> lool, no
[08:59] <sergiusens> lool, that requires the refactor
[09:00] <lool> sergiusens: do you agree python3-project should install pip3?
[09:02] <sergiusens> lool, yes
[09:03] <sergiusens> lool, oh, don't install the ubuntu pip, it won't work
[09:05] <vmayoral|pc> ricmm: https://github.com/gnab/rtl8812au
[09:08] <ricmm> vmayoral|pc: thx
[09:15] <longsleep> ogra_: either you or my IRC client has a problem with Umlauts. Test ÃÃ„ÃÃ¤Ã¶Ã¼Ã¤
[09:15] <longsleep> ah - my client :)
[09:15] <ogra_> yeah, utf8 :)
[09:15]  * longsleep wonders how that is possible in UTF-8 land
[09:15] <ogra_> what client ?
[09:15] <longsleep> somebody screwed up my console setup on this host
[09:15] <longsleep> irssi
[09:16] <ogra_> ah
[09:16] <ogra_> xchat here
[09:17] <longsleep> mhm must be irssi, in the console it works just fine
[09:17] <longsleep> funny, looks like i did not use german in IRC since a very long time
[09:19]  * ogra_ finds it really hard to switch his brain to erman on IRC ... 
[09:19] <longsleep> lol, the command-not-found helper has unicode issues
[09:19] <ogra_> *german
[09:19] <longsleep> File "/usr/lib/python3/dist-packages/CommandNotFound/CommandNotFound.py", line 41, in lookup key = key.encode('utf-8')
[09:19] <longsleep> UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc3' in position 5: surrogates not allowed
[09:19] <tbr> longsleep: IIRC zyga's statement was "send patches if you want it fixed"
[09:20] <longsleep> :D
[09:20]  * tbr CBA to look for the g+ post
[09:29] <longsleep> ogra_: Is there somewhere a description what the difference is between developer mode and no developer mode when building a image with u-d-f?
[09:29] <ogra_> user visible is that your ssh key gets copied into /home/ubuntu ...
[09:30] <ogra_> beyond that it allows you to provide a lical oem snap ... i think thats all
[09:30] <longsleep> ok, nothing else?
[09:30] <ogra_> *local
[09:30] <longsleep> yeah - i want to release an image without development mode - it just seems to work fine so i was wondering if there are other differences
[09:30] <ogra_> not sure, i think a local device tarball can be used without it, i'd have to test
[09:31] <longsleep> yes i already tested that
[09:31] <longsleep> device tarball can be used
[09:31] <longsleep> and the image boots fine when loading the oem from store
[10:09] <vmayoral|pc> ricmm: recompiling the kernel succeeded this time
[10:19] <ricmm> vmayoral|pc: ah, perfect
[10:20] <vmayoral|pc> ricmm: driver works now, all good
[10:21] <ricmm> excellent
[11:01] <ogra_> ricmm, did you guys get anywhere with the changing MAC address ?
[11:34] <ricmm> ogra_: mac is fine
[11:35] <ogra_> ricmm, could you ask vmayoral to close the bug then ?
[12:49] <longsleep> I always wanted to ask you folks, why Snappy uses a FAT partition to store the boot files. Is there any particular reason i should be aware of?
[13:35] <mvo_> longsleep: ogra or ogra_ probably knows better, my understanding is that we need it because its what uboot supports best to store the uboot environment on a filesystem
[13:36] <ogra_> not really, i didnt make the decision for FAT
[13:37] <ogra_> i think the BBB requires it to find the SPL
[13:37] <ogra_> beyond that i personally would rather have gone with some extX
[13:37] <ogra_> but the decision pre-dates my snappy involvement
[13:37] <tbr> you can also put the MLO at a fixed offset
[13:38] <ogra_> in RAW space, yeah ...
[13:38] <ogra_> but that would mean to special case ... or to have all boards set up like that
[13:38] <Maxxi> why is there no .iso for ubuntu snappy?
[13:38] <tbr> depending on how you partition things
[13:38] <Maxxi> i want to install it on my vmplayer
[13:39] <ogra_> theer are plenty of VM images ... not sure there is one for vmplayer though
[13:39] <tbr> could qemu-img help here? :)
[13:39] <ogra_> (KVM, qemu, vagrant, virtualbox and i think lso vmware itself should eb available)
[13:40] <ogra_> and yes, you might be able to convert one
[13:55] <longsleep> mvo_, ogra_ thanks for the details, i might consider building a snappy based image without fat - uboot has plenty of ways to store the env / might not even use a boot partition at all
[13:55] <longsleep> (i am doing this for normal ubuntu already)
[13:55] <ogra_> longsleep, well,, you would have to patch ubuntu-device-flash ... after all it creates the partitions
[13:57] <ogra_> and you would have to patch snappy too, since it changes the vars after boot
[13:57] <ogra_> to notify about a successful update/rollback
[13:58] <longsleep> ogra_: yeah sure, i am aware of this - but i would have to do this anyways to support own infrastructure for os and snap sources
[13:58] <longsleep> ogra_: we are not quite there yet, but we will need this for corporate environments
[13:58] <ogra_> k
[14:01] <clobrano> tbr: this might help http://ubuntuforums.org/showthread.php?t=2260169
[14:03] <tbr> clobrano: I don't have that problem and frankly IDGAF. I suggest you reread scrollback.
[14:04] <clobrano> tbr: LOL sorry, misread nicknames
[15:20] <elopio> Chipaca: we need help here: https://bugs.launchpad.net/snappy/+bug/1498293
[15:20] <elopio> any idea what could cause a successful boot to leave snappy_mode=try and snappy_trial_boot=1 ?
[15:21] <Chipaca> elopio: systemd fubar'ed?
[15:21] <Chipaca> elopio: sudo jouralctl -x, look for things (usually in red) about cycles
[15:21] <elopio> checking...
[15:22] <peacememories> huh... seems ubuntu-device-flash doesn't like being run inside a docker container
[15:22] <peacememories> kernel mismatch
[15:22] <Chipaca> elopio: in any case, search for ubuntu-snappy.boot-ok.service
[15:22] <Chipaca> elopio: (or boot-ok for short :) )
[15:25] <Chipaca> elopio: it's possible also that you're running your test too early, before boot-ok ran
[15:26] <elopio> Chipaca: I don't think that's it. When it fails, I can ssh and the grubenv is still wrong.
[15:26] <Chipaca> elopio: ok. When it fails, ssh in, and inspect the journal
[16:01] <elopio> Chipaca: you might actually be right, who would have thought...
[16:01] <elopio> I added a wait for mode=regular, and the test passed.
[16:02] <fgimenez> elopio, Chipaca that makes a lot of sense, i haven't been able to reproduce manually on kvm, only when the test runs
[16:02] <Chipaca> elopio: i'm shocked
[16:02] <elopio> Chipaca: so what would be the bug? you can't rollback before boot-ok has run?
[16:03] <Chipaca> elopio: can you log in before boot-ok has run?
[16:03] <Chipaca> that'd be a bug
[16:03] <Chipaca> the tests running before boot-ok has run, that's a bug also
[16:04] <elopio> Chipaca: I print the /boot/grub/grubenv as soon as I can ssh, and it shows mode=try.
[16:04] <Chipaca> aha
[16:04] <elopio> let me do more runs to confirm. This could have been a lucky execution.
[16:05] <Chipaca> that might be a bug in our unit ordering, then
[16:05] <elopio> fgimenez: you are leaving now, right?
[16:05] <Chipaca> _might_ :)
[16:05] <Chipaca> i'd be interested to know whether snapd is running as soon as you can log in
[16:05] <fgimenez> elopio, yep, in a few minutes
[16:06] <fgimenez> elopio, let me know if i can help you, i can stay a bit yet
[16:06] <elopio> fgimenez: ok, nevermind. I'll do runs in my other machine to confirm.
[16:07] <ricmm> Chipaca: what versio of snappy are you using to build?
[16:07] <elopio> fgimenez: no no, please don't stay after your EOD.
[16:07] <elopio> I will make two boot tests, one to check that mode is regular and one to check that snapd is running.
[16:07] <Chipaca> launchpad.net/snappy    bzr     snappy_tarmac-20150925153317-7acittvlm7idwcwl   718
[16:07] <Chipaca> ricmm: ^
[16:08] <ricmm> thx
[16:08] <fgimenez> elopio, i can put it to run, still 20min left, any special command?
[16:11] <ricmm> Chipaca: yup thats what I had built with
[16:11] <elopio> fgimenez: lp:~elopio/snappy/wait-boot-ok
[16:11] <fgimenez> Chipaca, elopio from this log http://paste.ubuntu.com/12603352/ you can see in line 141 that snappy_trial_boot is 1 after calling snappy list and snappy rollback, not sure if it can be a timing issue
[16:12] <elopio> fgimenez: after calling snappy rollback, it must be try
[16:12] <elopio> before calling rollback, it must be "regular"
[16:12] <fgimenez> elopio, snappy_mode yes, but not snappy_trial_boot
[16:13] <ogra> snappy_trial_boot is only used internally
[16:13] <ogra> dont touch it
[16:13] <elopio> ah, right. That's what I think that happens when you call rollback before boot-ok. Things go crazy.
[16:13] <elopio> but just a theory.
[16:14] <fgimenez> elopio, yes, it seems that when it reboots it switches the partitions without rolling back http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg#L24
[16:29] <elopio> fgimenez: after 3 successful runs, I reverted the waits and got the same failure. Chipaca has won the QA smiley sticker today.
[16:29] <ogra> elopio, well, you cant really call rollback before boot-ok in real life :)
[16:30] <fgimenez> elopio, great! :) mine is stuck updating
[16:30] <ogra> boot-ok runs way before the login service
[16:30] <elopio> ogra: I think that's the bug we are hitting.
[16:30] <ogra> make your unit wait for getty or the login bits then
[16:30] <peacememories> if building a custom oem snap, can i use local snappy images or do i have to create a store?
[16:31] <elopio> ogra: we are running this through ssh, and we are seeing snappy_mode=try.
[16:33] <ogra> elopio, then ssh comes up earlier than boot.ok i'd guess
[16:33] <fgimenez> elopio, finished without errors :)
[16:33] <ogra> peacememories, you need to use --developer-mode in your ubuntu-device-flash command to build the image ...
[16:33] <fgimenez> elopio, leaving, i'll catch up tomorrow
[16:34] <elopio> fgimenez: bye, thank you.
[16:34] <ogra> peacememories, beyond that there are no further restrictions
[16:38] <peacememories> ogra, so if i use a file path in my oem-snap definition file it will use that when building it? (i haven't tried yet, just thought i'd ask beforehand)
[16:39] <ogra> a file path ?
[16:39] <ogra> you mean for something you ship inside the oem snap ?
[16:39] <peacememories> yes, for preinstalled snaps
[16:40] <peacememories> i can understand if that doesn't work. it goes a bit against the update philosophy i guess
[16:40] <ogra> ah, i have never installed any local snaps ... i guess the --install option should work for that for a local build
[17:16] <peacememories> hm, i don't relaly see how i would, for example, set the default username and password of a snappy install
[17:18] <ogra> you cant
[17:18] <ogra> (yet)
[17:20] <peacememories> um
[18:04] <peacememories> oh, i just noticed that with my own oem package i apparently also need to supply my own boot images?
[19:58] <Chipaca> does the intel compute stick do sse?
[19:58] <Chipaca> wait, not the compute stick, that's an atom
[19:59] <Chipaca> what was the weird one, the edison?
[20:00] <Chipaca> intel quark. on the galileo. no sse.
[20:06] <tbr> also depending on the silicon you need to rebuild your whole userspace