On Wed, 5 Dec 2018 23:44:07 +0100 Fil <[email protected]> wrote:
> Hi Denis, Hi, > On 12/04/2018 05:34 PM, Denis 'GNUtoo' Carikli wrote: > >> I'll have a look at some radio logs, have a search around the tree > >> for those exceptions, and get back to you with some questions > >> soon... > > - Did you have the time to look into that second issue? > > Unfortunately, no. I got busy with other jobs in the while.. > I'm sorry for not keeping up with my promise.. Life's so short and > there are so many things to be done! :D What do you think about potentially working on other tasks that are not that urgent instead like: - Making the GPS work on the Galaxy S2 or the Galaxy Nexus: if my memory is correct they have a chip that might already be supported in GNU/Linux by gpsd. - Making Replicant work with Usptream WiFi drivers: You already have the hardware and software setup required to do that: You could start by trying to understand how to integrate external WiFi keys or standard WiFi drivers in the hardware abstraction libraries. The main difficulty here is to design it in a way that makes it as automatic as possible (like for instance autodetect the hardware and good software design). You might also find other ideas here: https://redmine.replicant.us/projects/replicant/wiki/Tasks https://redmine.replicant.us/projects/replicant/wiki/Upstream https://redmine.replicant.us/projects/replicant/wiki/Google_Summer_of_Code_2018 I also met Jeremy Rand some weeks ago and during our discussion on Replicant we found out that Java developers knowing how to write Android applications will probably be very badly needed for several tasks: - We are in the process of thinking on how to integrate llvmpipe to Replicant. The current design is to have both llvmpipe and libagl in parallel, with a way to choose between one or the other for each application. The current design is to have defaults to choose which one to use for each applications, but the user also need to be able to override that choice. It would be really important to have a graphical way to do that when the rest is ready. - There was also another task that was crucially needing people knowing how to write Android applications, but I don't remember it. It may or may not have been related to f-droid. That said, the SIM issue is very urgent to fix, and any help is welcome on that, including your help, however if you cannot commit to work on it, we could do that: - I will try to work on it as soon as I find a big enough time chunk to dedicate to it. - You could also work on it, so if you find the time to do it before me, it would make things progress faster. - And if we both end up working on it at the same time we'd simply coordinate to work together on it. It's always more fun to do that, and some things are handled way faster when you're more than one person looking at an issue. > > - Do you need help with it? > > Sure I do, but I guess I'd have to start from somewhere before asking > for any meaningful question.. > > Is reading the logs a good place to start from? > Is there any "shortcut" that would make me jump straight to the core > of the issue? > Like.. specific options to dump relevant logs only? > Specific errors to watch for? > Specific source files to debug? > I know those questions seem a bit random.. but I really have no clue > where to start from. For the SIM issue: by looking at logs and trying to understand what is going on. After that you can make hypothesis and some for some ideas on how to test the hypothesis (like for instance do a very crude workaround). What's next is pretty straightforward (try to fix it in a clean way, and if possible ask help or ideas on how to do it, and send patches along the way). Denis.
pgpk6mlrubRv7.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
