How to fix Git repeatedly requesting user credentials?

 When you engage with a remote repository via HTTPS URLs through the command line, you'll inevitably encounter prompts for your GitHub username and password. This can be rather frustrating, wouldn't you agree?

Nevertheless, there are some notable advantages to using an HTTPS remote URL: it's considerably simpler to configure compared to SSH 😅, and it typically circumvents the restrictions imposed by stringent firewalls and proxies. However, it does come with the drawback of incessantly requesting your GitHub user credentials whenever you perform a repository pull or push 😞.

Fortunately, there's a way to rectify this predicament by configuring Git to handle your password for you. Here's the step-by-step solution:

1. Update the origin remote URL to use SSH instead of HTTPS:

   git remote set-url origin git@github.com:username/repo.git

   Or, for those who prefer an alternative approach:

2. Configure Git to store your username and password, effectively eliminating the need for manual entry:

   git config --global credential.helper store

3. If you want to take it a step further and cache your credentials for a session, you can use:

   git config --global credential.helper cache

4. Optionally, you can set a specific timeout for the credential cache to enhance security:

   git config --global credential.helper 'cache --timeout=600'

Voilà! You've successfully resolved the issue, and from this point onward, Git won't pester you for your credentials anymore. 😄

How to Use Git LFS for Files Larger than 100MB on GitHub

If you're working on a GitHub repository and need to handle files larger than 100MB, Git LFS (Large File Storage) is the solution. Git LFS allows you to manage and version large files efficiently. In this guide, we'll walk you through the steps to use Git LFS for files exceeding 100MB on GitHub.

Step 1: Install Git LFS

To get started, you need to install Git LFS on your local machine. Open your terminal and run the following command:

sudo apt-get install git-lfs

Step 2: Navigate to Your Repository

Change your working directory to the location of your Git repository:

cd path_to_your_repo

Step 3: Initialize Git LFS

Before you can start using Git LFS for large files, you need to initialize it for your repository:

git lfs install

Step 4: Specify File Types for Git LFS

Tell Git LFS which file types you want to manage. For example, if you want to use Git LFS for files with the extensions .tflite and .apk, run the following commands:

git lfs track "*.tflite"
git lfs track "*.apk"

Step 5: Stage and Commit Your Changes

Now that Git LFS is set up for the specified file types, add your files to the staging area and commit them. Replace "added file above 100MB with lfs" with an appropriate commit message:

git add .
git commit -am "added file above 100MB with lfs"

Step 6: Push to GitHub

Finally, push your changes to your GitHub repository:

git push origin main

That's it! You've successfully configured Git LFS to manage files larger than 100MB in your GitHub repository. These steps will help you keep your repository organized and prevent large files from bloating your Git history.

Git LFS is a powerful tool for handling large files in Git, and it ensures that your repositories remain efficient and manageable. Now you can work with large assets in your projects on GitHub with ease.

Share common folder between two git repo

 One common approach is to use Git Submodules.

A Git submodule allows you to include a repository as a sub-folder within another repository. The submodule remains a separate repository, but changes made to it are committed and tracked in the parent repository.

To add a submodule to a Git repository, you would run the following commands:

$ git submodule add [url_of_the_submodule_repo] [path/to/submodule] $ git commit -m "Adding submodule [name_of_the_submodule]" $ git push

You can then clone the parent repository and initialize the submodule by running:

$ git clone [url_of_the_parent_repo] $ cd [parent_repo] $ git submodule init $ git submodule update

This way, both the parent and submodule repositories will have the latest version of the submodule code. However, changes made to the submodule code will need to be committed and pushed to the submodule repository and then committed and pushed in the parent repository to propagate to other users.

for more info:

https://phoenixnap.com/kb/git-clone-submodule

Wine installation on ubuntu 20.04

If your system is 64 bit, enable 32 bit architecture (if you haven't already):
sudo dpkg --add-architecture i386 

Download and add the repository key:
wget -O - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add -

Add the repository:

For Ubuntu 20.04
sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main'

Update packages:
sudo apt update

Then install one of the following packages:

Stable branch 
sudo apt install --install-recommends winehq-stable

Development branch 
sudo apt install --install-recommends winehq-devel

Staging branch 
sudo apt install --install-recommends winehq-staging

Install sourceinsight

wine sourceinsight40124-setup.exe 
wine winecfg

set below setting to set full screen for wine windows on ubuntu with 1920x1080, 125 scaling

Reference: 

https://www.youtube.com/watch?v=Wx8NbZEAPNM&ab_channel=ProgrammingKnowledge

Understanding Audio Tracks and Configurations

In the context of audio processing and playback on computer systems or mobile devices, there are various modes and configurations designed to optimize performance and power consumption. These modes can significantly impact the audio quality, latency, and power efficiency of the system. Let's delve into each of the mentioned audio tracks and configurations in detail.

Normal Tracks:

• Audio Format: PCM (Pulse Code Modulation) is commonly used for high-quality audio playback.
• Buffer Size: Typical buffer size is approximately 20 milliseconds.
• Latency: Higher latency, which means there might be a slight delay between when the audio is generated and when it's heard.
• Purpose: This mode prioritizes audio quality and is suitable for scenarios where latency is not a critical concern, such as music playback or video streaming.

Fast Tracks:

• Audio Format: PCM (Pulse Code Modulation).
• Buffer Size: Typical buffer size is 5 milliseconds or even less.
• Latency: Lower latency, resulting in minimal delay between audio generation and playback.
• Purpose: Fast tracks are optimized for real-time applications where low latency is essential. This includes voice calls, gaming, and any situation where immediate audio feedback is critical.

Deep Buffer:

• Audio Format: PCM (Pulse Code Modulation).
• Buffer Size: Typical buffer size is greater than or equal to 100 milliseconds.
• Latency: Very high latency, which can result in significant delays.
• Purpose: Deep buffer mode is primarily used to conserve power. By allowing longer gaps between audio processing, the system can enter low-power states more frequently. This mode may be suitable for audio playback in situations where power efficiency is more critical than low latency, such as background music playback.

Codec Offload:

• Audio Format: Compressed audio formats like MP3, AAC, etc.
• Buffer Size: Typically involves very high latency.
• Latency: Very high latency, similar to deep buffer mode.
• Purpose: Codec offload mode is designed to save even more power by offloading audio decoding tasks to dedicated hardware or specialized DSPs (Digital Signal Processors). This mode is suitable for scenarios where power consumption needs to be minimized at the expense of higher latency. It's commonly used in low-power or battery-sensitive devices during audio playback.

The command grep -r DEEP_BUFFER in frameworks/av/* is likely used to search for references or configurations related to the "Deep Buffer" mode within the Android Audio/Video framework. This search can help developers or system administrators find specific code or settings related to this mode, allowing them to customize or optimize the audio playback behavior based on their requirements.

In summary, the choice of audio track and configuration mode depends on the specific use case, with trade-offs between audio quality, latency, and power efficiency. Understanding and customizing these modes can help achieve the desired audio performance for various applications.

Building AOSP for Google Pixel 3a (Sargo)

In this blog post, we will guide you through the process of building Android from source for the Pixel 3a smartphone. Building Android from source gives you full control over the operating system and allows for customization. We'll also cover how to handle common issues during the process.

Step 1: Get the Source Code

1. Create a directory for the project:

   mkdir aosp12
   cd aosp12
         

2. Initialize the repository with the Android source code:

   repo init -u https://android.googlesource.com/platform/manifest -b android-12.1.0_r27
         

3. Sync the source code to your local machine:

   repo sync -c --force-sync --no-clone-bundle --no-tags -j$(nproc --all)
         

Step 2: Handling Repo Sync Errors

If you encounter any errors during the repo sync process, follow these steps:

1. Navigate to the .repo/repo directory:

   cd .repo/repo
         

2. Check out forcefully:

   git checkout -f
         

3. Retry the repo sync with the following command:

   repo sync -c
         

Step 3: Download Driver Binaries

Next, you'll need to download the driver binaries for the same Build ID that you selected previously. For Pixel 3a, you can find the drivers here.

After downloading, extract the driver binaries into your project directory (aosp12).

Step 4: Build Android

1. Set up the build environment:

   source build/envsetup.sh
         

2. Choose the build variant (userdebug in this case):

   lunch aosp_sargo-userdebug
         

3. Build Android. You can specify the number of CPU cores to use for the build. For example, to use one core for kernel compilation and four cores for the rest of the build:

   m -j1 (till kernel compilation)
   m -j4 (after kernel compilation)
         

Step 5: Flash the Build

1. Reboot your device into bootloader mode:

   adb reboot bootloader
         

2. Flash the build onto your device. This will wipe all data, so be cautious:

   fastboot flashall -w
         

Step 6: Finalize and Test

After flashing, your device will reboot. You can then:

1. Reconnect to the device:

   adb root
   adb remount
         

2. Reboot your device:

   adb reboot
         

Conclusion

Congratulations! You've successfully built and flashed Android from source for your Pixel 3a smartphone. Enjoy your custom Android experience!

Build Pixel Experience 11 for Realme 3 pro

https://wiki.pixelexperience.org/devices/RMX1851/build

pixelexp11/.repo/manifests$ git remote -v
origin https://github.com/PixelExperience/manifest (fetch)
origin https://github.com/PixelExperience/manifest (push)

pixelexp11/.repo/manifests$ git branch -a
* default
  remotes/m/eleven -> origin/eleven
  remotes/origin/eleven

pixelexp$ repo status
project device/realme/RMX1851/                  (*** NO BRANCH ***)
 -m     device.mk
project kernel/realme/sdm710/                   (*** NO BRANCH ***)
 -m     Makefile
 -m     drivers/staging/qcacld-3.0/Kbuild 

pixelexp/device/realme/RMX1851$ git diff
diff --git a/device.mk b/device.mk
index d4a032a..736ab51 100644
--- a/device.mk
+++ b/device.mk
@@ -157,8 +157,8 @@ PRODUCT_COPY_FILES += \
 PRODUCT_PACKAGES += \
     libnl

-PRODUCT_BOOT_JARS += \
-    WfdCommon
+#PRODUCT_BOOT_JARS += \
+#    WfdCommon 

 # Wallpapers
 PRODUCT_PACKAGES += \

no changes added to commit (use "git add" and/or "git commit -a")
pixelexp/kernel/realme/sdm710$ git diff
diff --git a/Makefile b/Makefile
index 276f98015b43..05b4407fdf0d 100755
--- a/Makefile
+++ b/Makefile
@@ -692,6 +692,10 @@ CFLAGS_GCOV        := -fprofile-arcs -ftest-coverage \
        $(call cc-option,-fno-tree-loop-im) \
        $(call cc-disable-warning,maybe-uninitialized,)
 CFLAGS_KCOV    := $(call cc-option,-fsanitize-coverage=trace-pc,)
+
+KBUILD_CFLAGS += $(call cc-option,-Wno-error=maybe-uninitialized,)
+KBUILD_CFLAGS += $(call cc-option,-Wno-error=array-bounds,)
+
 export CFLAGS_GCOV CFLAGS_KCOV

 # Make toolchain changes before including arch/$(SRCARCH)/Makefile to ensure
diff --git a/drivers/staging/qcacld-3.0/Kbuild b/drivers/staging/qcacld-3.0/Kbuild
index 0631e4b76016..93df236bc784 100644
--- a/drivers/staging/qcacld-3.0/Kbuild
+++ b/drivers/staging/qcacld-3.0/Kbuild
@@ -1573,7 +1573,6 @@ ccflags-y += $(INCS)
  cppflags-y +=  -DANI_OS_TYPE_ANDROID=6 \
                -Wall\
-               -Werror\
                -D__linux__
 cppflags-$(CONFIG_PTT_SOCK_SVC_ENABLE) += -DPTT_SOCK_SVC_ENABLE

install android 10 to unlock bootloader using:
https://download.c.realme.com/flash/Rollbackpack/realme_3Pro/sign_RMX1851EX_11_OTA_1180_all_w236tl6xfsaL.ozip

Turn off your phone-->
Long press the volume down and power buttons at the same time enter recovery mode-->
Choose the language -->
Install from storage-->
Input your screen locked password-->
Find & tap the rollback package to go back to the previous version.

Follow steps to unlock bootloader:
https://c.realme.com/in/post-details/1243537172376584192

Flash recovery twrp:
https://www.right-brothers.net//how-to-unlock-bootloader-of-realme-3-pro-guide/n

Install pixel experience
https://www.right-brothers.net/how-to-install-pixel-experience-rom-on-realme-3-pro/

adb reboot bootloader
fastboot flash recovery twrp-3.4.0-0-RMX1851.img

Note: if there is problem with fastboot command, use usb2.0 port or usb2.0 hub

fastboot reboot
adb reboot recovery

wipe all except vendor partition.
install PixelExperience_RMX1851-11.0-20211216-0324-UNOFFICIAL.zip