**** BEGIN LOGGING AT Wed Apr 17 02:59:57 2019 Apr 17 06:13:07 Morning! Apr 17 07:54:15 morning! Apr 17 08:14:14 Morning! Apr 17 08:28:14 Herrie|Laptop: I'm back from travel, so I'll be able to discuss a bit more how we can address this device status docmentation Apr 17 08:28:37 Tofe: Great :) Apr 17 08:28:56 I put some suggestions, you can find them in the logs ;) Apr 17 08:29:07 Not feeling that well today, some flu again it seems :S Apr 17 08:30:31 So far, my thinking was: 1. it needs to be acessible enough so that other people (Preemptive, other enthousiast testers...) can edit and fill it, and 2. it should give a quick overview of the status, yet let people enter some details when there is a need Apr 17 08:30:42 Oh, I hope I didn't give you mine :p Apr 17 08:32:16 Yes, I can complete the current table with your comments Apr 17 08:33:11 For a web page I would have put all the devices in the same page, but for a spreadsheet using different tabs seemed natural, to avoid too much scrolling Apr 17 08:33:32 (also maybe there would be a way to have a "template" sheet somehow) Apr 17 08:34:38 Tofe: In Excel you can "Freeze Panes" so you can keep certain rows & columns fixed Apr 17 08:34:43 And only others scroll Apr 17 08:34:54 I.e. header row(s) and left column(s) Apr 17 08:35:06 I'm pretty sure Open/Libre would offer something similar Apr 17 08:35:12 Probably yes Apr 17 08:35:48 Mainly solves the scrolling issue ;) Apr 17 08:36:06 For BT & WiFi we might want to add things like "discovery", connection, connection with pin etc Apr 17 08:37:12 How would you let people enter comments, if I fix the header column and we have devices per column ? Apr 17 08:37:28 But we should start somewhere and can always expand Apr 17 08:37:35 or just one comment column at the end ? Apr 17 08:37:47 I would go for 1 comment column Apr 17 08:38:01 Most issues shouldn't appear on many targets Apr 17 08:38:10 Or generic or one usually Apr 17 08:38:16 yes, true Apr 17 08:39:06 I'm still not satisfied with the "spreadsheet file" approach, but if people have to bear with a mediawiki table, I fear they'll just give up Apr 17 08:39:20 (plus the login and edit rights, etc) Apr 17 08:40:45 We could do something in Google Docs for example Apr 17 08:40:53 But also rights issues Apr 17 08:40:57 Or in GitHub Apr 17 08:41:46 Something like Halium does: https://github.com/Halium/projectmanagement/issues/131 Apr 17 08:41:55 But also not very good in terms of collaboration Apr 17 08:42:03 We need our issue tracker back maybe :P Apr 17 08:42:08 novaldex|away: ^ Apr 17 08:43:07 I didn't want to do the Google way by principle, but it might be a compromise too Apr 17 08:46:47 In the end we just need a fairly static page, with combos and text field, with some data storage behind Apr 17 08:49:03 A mediawiki form, maybe ? Apr 17 08:50:00 Let's have a look what kind of extensions there are Apr 17 09:04:53 Something like this could work, but still not very user friendly: https://www.mediawiki.org/wiki/Extension:TableEdit Apr 17 09:06:19 This can also help: https://chrome.google.com/webstore/detail/wikitableworks/fcidnbkcodoajhfbcaefikfemlggcpfp Apr 17 09:09:57 Ah, yes, might be part of a solution Apr 17 09:13:01 Something like this could also help: http://discoursedb.org/w/index.php?title=Picture_IDs_are_perfectly_sensible&action=formedit Apr 17 09:16:32 A custom page for edition ? Apr 17 09:17:08 Yes, might work Apr 17 12:53:28 Tofe: 5.12.3 was released today, I'll update meta-qt5 soon, lets see if it improves or break unstable builds Apr 17 12:56:03 Tofe: where were you traveling? I got flu yesterday as well :/ Apr 17 12:56:32 Damn, I propagated flu all over Europe :/ Apr 17 12:56:55 I was just traveling in south France Apr 17 12:57:15 JaMa: basically, the only remaining big issue is the black surface on qemu, right? Apr 17 13:07:38 right, AFAIK Apr 17 13:07:39 Get well soon, guys Apr 17 13:42:21 fixes for rpi signature issues sent: https://github.com/agherzan/meta-raspberrypi/pull/412 https://github.com/webOS-ports/meta-webos-ports/pull/333 https://github.com/webOS-ports/meta-rpi-luneos/pull/7 will merge them when (and if the meta-raspberrypi one is merged) Apr 17 13:42:47 ups, one is already merged :) Apr 17 13:43:20 doesn't hurt, just doesn't help much as long as userland is MACHINE_ARCH (all qt*) Apr 17 13:46:00 oops, seemed harmless yet :) Apr 17 13:46:02 yes* Apr 17 13:50:57 don't merge this 2nd half of it yet :) https://github.com/webOS-ports/meta-webos-ports/pull/334 Apr 17 13:51:09 good that I was a sec too slow to push 2nd commit into it Apr 17 13:52:35 Being able to "lock" a PR by the committer would be useful sometimes Apr 17 13:53:47 SoPine64 .. :) too thin you said.. :) Apr 17 13:55:18 but I understand that it might be more hackable platform than hammerhead-mainline or qemux86-64 Apr 17 14:20:44 JaMa: it's more fortuity than real decision :) Apr 17 14:21:53 (and, maybe, I'm too curious too) Apr 17 17:10:04 ok, let's try to tackle this black surface issue... Apr 17 18:13:34 mmh wayland debug doesn't give anything useful... Apr 17 18:14:16 JaMa: the black surfaces don't happen on hammerhead, right? Apr 17 18:20:47 Tofe: IIRC Herrie was testing it on hammerhead and didn't Apr 17 18:21:04 I was planing to test it as well and on tissot, but got side tracked to something else Apr 17 18:21:07 still on my todo Apr 17 18:21:22 ok Apr 17 20:02:44 JaMa: luneos-dev-package-hammerhead--unstable-0-80.zip works very well Apr 17 20:03:42 I've just remarked a little problem with the vkb's overlay touches, which probably is a little QML bug in the keyboard Apr 17 20:04:35 s/touches/keys/ Apr 17 20:06:25 so it's specific to qemu... maybe to mesa's swrast Apr 17 21:44:23 I've started the 5.12.3 upgrade in meta-qt5, I might have some image tomorrow if everything goes well, let me try it with that **** BEGIN LOGGING AT Wed Apr 17 22:49:39 2019 **** ENDING LOGGING AT Thu Apr 18 02:59:57 2019