Porting Motorola Moto G 2014 "titan"

Hello.

I love your project and would like to contribute porting my Moto G 2014 device.

In addition to opening issues about minor bugs, I've also pushed the current work to my device-motorola-titan branch banch.

What's still missing?

• deviceinfo_flash_offset_base value
• kernel
• testing

According to titan.yml this device is using android_kernel_motorola_msm8226 but since my lack of knowledge I don't know how to continue.

Any help is appreciated!

This script requires a shell more modern than all the shells that I found on your system. Please tell bug-autoconf@gnu.org about your system, including any error possibly output before this message. Then install a modern shell, or manually run the script under such a shell if you do have one.

https://pastebin.com/nF2X22ea

By Pablo Castellano on 2017-06-04T12:14:29

Created by: ollieparanoid

What is your host system?

By * postmarketOS Bot on 2017-06-04T12:16:10

vermuth:~$ lsb_release -d
Description:	Linux Mint 17 Qiana

(based on Ubuntu 14.04)

By Pablo Castellano on 2017-06-04T12:20:45

Created by: ollieparanoid

You have tried building with pmbootstrap build linux-motorola-titan first, right? Looks like device nodes are missing in your chroot. As suggested in #52 (closed): try to zap your chroot and re-create it (pmbootstrap chroot will re-create it). pay attention to whether the device nodes get created correctly in the log.

By * postmarketOS Bot on 2017-06-04T12:28:55

Created by: ollieparanoid

CARCH=x86_64 abuild -d <- this is not how it is intended, the dependency resolving should be done with pmbootstrap

By * postmarketOS Bot on 2017-06-04T12:30:43

JFTR: I changed the chroot directory and the issue that was preventing me from building binutils went away

By Pablo Castellano on 2017-06-04T17:36:43

Created by: lawl

So this is an issue with ecryptfs. Should probably file a bug on ecryptfs and maybe add a message to pmbootstrap if it detects it. An easy way would be to check if the system can handle long paths.

By * postmarketOS Bot on 2017-06-04T17:46:38

Created by: lawl

@PabloCastellano Do you want to report this upstream in ecryptfs that it has issues with special devices?

By * postmarketOS Bot on 2017-06-04T22:03:28

Created by: ollieparanoid

@lawl: I have added ecryptfs to the Troubleshooting wiki page. I don't think implementing a check for it is worth it right now, but if there are lots of users having this problem in the future, we should do it.

If we do implement a check, it should really check if /dev/random etc. work after creating them, instead of assuming, that if the filename length is limited, it must be ecryptfs (reminds me of these bad browser checks: if you can't do that, you must be browser xy).

By * postmarketOS Bot on 2017-06-04T23:46:15

Created by: ollieparanoid

@PabloCastellano: Your ecryptfs issue seems to be solved now (that newer version of eCryptFS seems to work), and further steps are described in the porting guide. I see that you have already created a device page and written down your porting status in the wiki (thanks!).

Do you have any more questions? Otherwise we'd close this ticket (the porting status is already on the wiki page, and otherwise this ticket would get quite long - so better open up a new one for specific issues). Thanks for your porting efforts so far :)

By * postmarketOS Bot on 2017-06-05T15:26:17

Created by: ollieparanoid

Closing, as discussed on IRC.

By * postmarketOS Bot on 2017-06-05T15:49:41