[Q] hover cherry pick?? - Paranoid Android Q&A

Hi all,
Noob here and PA follower.
I'm well enough in AOSP and CM11 sources building...follow an howto is not so diffcult
Anyway I'm just learning Git and GitHUb and I was wondering if my favourite PA feature
could be included in my personal AOSP build.
I'm talking about Hover.
Is it feasible and legal to include it in others builds?
I mean, could I "repo sync" AOSP and after include Hover from PA git?..and if so, will I need to "cherry-pick"
its commit(s)?
syscall

Check out the guides on cherry picking. Git add remote the repo, git cherry pick the commit
#stayparanoid

Related

[REF] Source code: Unified git repo for GT-I9000 Gingerbread kernel source

Here we go
Common gingerbread-samsung git branch for all of us
This branch contains the fixed Gingerbread source (compiling and working) everyone of us may use as reference git repository.
Fixed in this source:
- all cleaned up gitignores
- missing FSR in Makefile
Take also a look at the updated README.txt that will explain you how to compile and get it working with modules
Also: makes sure you disable, in .config:
[*] Automatically append version information to the version string in menuconfig or CONFIG_LOCALVERSION_AUTO in .config
It will help each developer to exchange patches easily because of the common starting point.
bilboa1 said:
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
I certainly support this idea.
Click to expand...
Click to collapse
How you can fork this repository:
- clone it via github directly
or, if you prefer keeping only this gingerbread branch directly, on your dev computer:
Code:
git clone git://github.com/project-voodoo/linux_gt-i9000.git -b gingerbread-samsung
cd linux_gt-i9000
git remote rm origin
git remote add origin git://your-new-remote-repository.git
git remote add common git://github.com/project-voodoo/linux_gt-i9000.git
This way, for people re-using Vodooo sound for example, it will be as easy as:
Code:
git fetch common
git merge gingerbread-voodoo-sound
If you have more idea of collaboration like that, express yourself
FAQ:
Q: Bleh! I hate this Kernel/ directory.
A: Yes, this was the case for the original commits but now it's a standard Linux repository with everything on its root.
But it didn't worked as expected, so I had to make the change, sorry for the inconvenience to the early adopters.
Q: What happens when Samsung update their source code tarballs
A: I'll update the common git repository accordingly (hopefully fast enough for you)
On your side, all you'll need to do will is.
Code:
git fetch common
− or git fetch git://github.com/project-voodoo/linux_gt-i9000.git
git merge gingerbread-samsung
Say good bye to messy tarballs!
PS: if you're looking to initramfs, take a shot at https://github.com/project-voodoo/samsung_initramfs − contribution welcome.
Good idea, I second that, it will be easier
wrong link
Github reads http://project-voodo.org/
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
Forking in git hub is VERY VERY easy btw.
I certainly support this idea.
Awesome! - I also support this idea
United Galaxy S Developers
Nice idea! Perfect spirit of open source
I hope good things come out og this.
Great move Supercurio - once again !
Simply awesome men
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
pikachu01 said:
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
Click to expand...
Click to collapse
The gingerbread-samsung branch promoted here will only contain Samsung kernel sources and won't interfere with other developers modifications.
Only exception is if this source is broken and needs something to work, like nikademus's patch: https://github.com/project-voodoo/linux_gt-i9000/commit/6c8f989f58999770d23236bb172c3a4e1c80586b
It seems that JVK and JVB was pulled from Kies because of an update problem. Looks like we're going to have new ROMs to play with in a week or two (maybe less)
Edit: What about the SSL fix (http://forum.xda-developers.com/showthread.php?t=1040005)
Great, good idea. That's how community development should work!
zorxd said:
Great, good idea. That's how community development should work!
Click to expand...
Click to collapse
Agreed! Thanks for getting things started Supercurio! Now I have to start making a Vibrant branch.
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
ttabbal said:
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
Click to expand...
Click to collapse
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
supercurio said:
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Click to expand...
Click to collapse
Excellent! I just did a defconfig to check it out and saw the preempt in there.. Nice to see Samsung fixing things up a little. Now I need to get a GB ROM to install so I can try to boot.
Thanks again. I'll send a pull request when I have a Vibrant branch ready. Going for minimal modifications, fix touch button mapping and such. People can add whatever they want after that. Now I need to learn the new code tree... wheee! Hopefully the basics are the same, getting the changes into an i9k froyo kernel is pretty easy.
zorxd said:
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
Click to expand...
Click to collapse
You will need an initramfs... anyone have a default one we can start with for 2.3?
zImage will have to be in a TAR file to flash with Odin. Heimdall can flash a bare zImage, as can the SGS Kernel Flasher tool for Android.
Oh... think I saw a setting in "make menuconfig" for the cross-compiler prefix. Might be able to avoid Makefile mods....
Sorry for the newb question, but how do we generate the initramfs? I guess we could take the one from stock JVB. But how do we extract it and how do we combine our compiled kernel with it?
On a side note, I noticed that CFQ is the default scheduler. Isn't it better to use No-op for flash memory?

[Q] [REQ] How to cook a PA rom

I like the PA rom but i would want to have the Rom Control / Similar tweaks into PA.
Can someone help me with this.
Thanks
husytcs said:
I like the PA rom but i would want to have the Rom Control / Similar tweaks into PA.
Can someone help me with this.
Thanks
Click to expand...
Click to collapse
build from source. there's a thread about aosp building stickied in general. learn git and its various functions. you'll need linux or mac osx (only builds on master branch, afaik).
explore rom's source you wish to kang @github (or any other git repository). enjoy the beauty of open source. learn how to (at least) read, cherry-pick and merge code.
naturally, after you get your build running, you can't (or shouldn't) ask for help, you need to know how to debug, and how to get yourself out of trouble.
sent from my i9250

[Q] Paranoid Android Hover Sources

Can anyone give me Paranoid Android Hover sources files?
It's all in github dude. Frameworks/base
#stayparanoid

[Q] PA with Lollipop source code

Sorry for noob question or spam question
When is PA use lollipop base?
I hope this years has been merge lollipop to PA
Asking for an EtA is quite rude. We don't know.
Source is open, feel free to watch gerrit and github.
But the fact of the matter is, Google hasn't provided the binary blobs we need for Nexus devices
#stayparanoid

Learning to build from source could use some help

We'll I've built Firefox OS from source previously but that used git and what not but this phone you straight download the kernel sources how would one go about building from source that way can someone point me to a good guide please and thanks
Sent from my Robin using Tapatalk
Me too, but I have given up on it due to too many issues with building. If you are looking to continue, AOSP has a guide. Also, look on Cyanogenmod git and TheMuppets git for device specific items.

Categories

Resources