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