tgm4883 | Are snappy apps able to play audio? | 00:42 |
---|---|---|
=== chihchun_afk is now known as chihchun | ||
fgimenez | good morning | 07:18 |
davidcalle | Morning o/ | 07:21 |
dholbach | good morning | 07:43 |
zyga | yashi_: hey | 07:59 |
zyga | yashi_: how are you, do you have a moment to talk about https://code.launchpad.net/~yashi/snapcraft/snapcraft/+merge/272337 | 08:00 |
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:22 |
JamesTait | Good morning all; happy Wednesday, and happy International Translation Day! 😃 | 08:38 |
ogra_ | Guten Morgen; einen schönen Mittwoch, und einen schönen Tag der Internationalen Übersetzung! 😃 | 08:45 |
ogra_ | JamesTait, appropriate ? | 08:46 |
JamesTait | ogra_, ja, sicher! | 08:46 |
ogra_ | :) | 08:47 |
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:48 |
JamesTait | Danke. 😉 | 08:49 |
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:58 |
sergiusens | lool, no | 08:59 |
sergiusens | lool, that requires the refactor | 08:59 |
lool | sergiusens: do you agree python3-project should install pip3? | 09:00 |
sergiusens | lool, yes | 09:02 |
sergiusens | lool, oh, don't install the ubuntu pip, it won't work | 09:03 |
vmayoral|pc | ricmm: https://github.com/gnab/rtl8812au | 09:05 |
ricmm | vmayoral|pc: thx | 09:08 |
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:15 |
ogra_ | ah | 09:16 |
ogra_ | xchat here | 09:16 |
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:17 |
* 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 |
=== greyback__ is now known as greyback | ||
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:19 |
longsleep | :D | 09:20 |
* tbr CBA to look for the g+ post | 09:20 | |
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:29 |
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:30 |
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 | 09:31 |
vmayoral|pc | ricmm: recompiling the kernel succeeded this time | 10:09 |
ricmm | vmayoral|pc: ah, perfect | 10:19 |
vmayoral|pc | ricmm: driver works now, all good | 10:20 |
ricmm | excellent | 10:21 |
ogra_ | ricmm, did you guys get anywhere with the changing MAC address ? | 11:01 |
=== chihchun is now known as chihchun_afk | ||
ricmm | ogra_: mac is fine | 11:34 |
ogra_ | ricmm, could you ask vmayoral to close the bug then ? | 11:35 |
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? | 12:49 |
=== chihchun_afk is now known as chihchun | ||
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:35 |
ogra_ | not really, i didnt make the decision for FAT | 13:36 |
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:37 |
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:38 |
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:39 |
ogra_ | and yes, you might be able to convert one | 13:40 |
=== chihchun is now known as chihchun_afk | ||
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:55 |
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:57 |
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 | 13:58 |
clobrano | tbr: this might help http://ubuntuforums.org/showthread.php?t=2260169 | 14:01 |
tbr | clobrano: I don't have that problem and frankly IDGAF. I suggest you reread scrollback. | 14:03 |
clobrano | tbr: LOL sorry, misread nicknames | 14:04 |
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:20 |
ubottu | Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New] | 15:20 |
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:21 |
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:22 |
Chipaca | elopio: it's possible also that you're running your test too early, before boot-ok ran | 15:25 |
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 | 15:26 |
=== ogra_ is now known as ogra | ||
=== alexabreu is now known as alex-abreu | ||
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
ricmm | thx | 16:08 |
fgimenez | elopio, i can put it to run, still 20min left, any special command? | 16:08 |
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:11 |
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:12 |
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:13 |
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:14 |
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:29 |
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:30 |
elopio | ogra: we are running this through ssh, and we are seeing snappy_mode=try. | 16:31 |
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:33 |
elopio | fgimenez: bye, thank you. | 16:34 |
ogra | peacememories, beyond that there are no further restrictions | 16:34 |
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:38 |
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:39 |
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 | 16:40 |
peacememories | hm, i don't relaly see how i would, for example, set the default username and password of a snappy install | 17:16 |
ogra | you cant | 17:18 |
ogra | (yet) | 17:18 |
peacememories | um | 17:20 |
=== j12t_ is now known as j12t | ||
peacememories | oh, i just noticed that with my own oem package i apparently also need to supply my own boot images? | 18:04 |
Chipaca | does the intel compute stick do sse? | 19:58 |
Chipaca | wait, not the compute stick, that's an atom | 19:58 |
Chipaca | what was the weird one, the edison? | 19:59 |
Chipaca | intel quark. on the galileo. no sse. | 20:00 |
tbr | also depending on the silicon you need to rebuild your whole userspace | 20:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!