The default download seems not to contain the kernel directory while use the prebuilt linux kernel image. Does any one know how to get the linux kernel directory? I have googled and tried some methods but they did not work.
You know how to use git right?
Here :
https://android.googlesource.com/
Go to https://android.googlesource.com/ as the repositories moved away from kernel.org to Google's own servers (~2011).
There are a couple of repositories named "kernel/*". Each one is for a different device. For instance, the one used in the emulator is the "kernel/goldfish".
Once you click in any one of them, at the top of the repository page you'll get a "git clone" command to download them individually.
Related
Git status returns different results if I run it on my Linux system and my Windows10 laptop.
The original directory was started on the Linux machine (running RedHat 6.4). I got tired of editing all of our Python code using VIM, so I decided to map a network drive on my Windows10 laptop to the remote Linux box (which controls all of our test equipment) and the directory set up with Git. So now I can use Visual Studio Code to easily view/edit/update any files on the remote Linux machine. I run all my git commands from the Linux box, but it would be nice if I could run them right from VS Code, but there is obviously a difference between the two versions of Git.
'git status' --> on the Linux box returns no updated or modified files.
'git status' --> on Windows shows I have over 200 modified files and 2 directories that are deleted.
I have already looked through this thread: Git - Windows AND linux line-endings
There was a lot of great information there that I have tried. The only thing that seemed to have any effect at all though was adding the 'git config core.filemode false' setting, which I did on the Linux machine. Now, when I run 'git status' on my Windows machine I see it reduced my modified files from 200+ down to 4. So that is great. However, and I still see those 4 files as modified and the 2 folders it thinks are deleted.
Any other suggestions as to what I can check?
As a side note, I have 112 files that show up as Untracked in VS Code, but not coincidentally I believe, all 112 are files that reside in the 2 directories that Windows git status think are deleted.
Git stores, in the index, some special bits of information to know easily whether a file in the work-tree is modified or not. The index itself is a file that resides within the Git repository (.git/index; there may be additional auxiliary files, and temporary index files, here, but .git/index is the index, the first and real-est, as it were).
These special bits of information in the index are (derived from) the result of operating system stat calls. The stat calls on Linux and the stat calls on Windows deliver different data (specifically st_dev, though the ino, uid, and gid can also be an issue), so a single index (and hence Git repository-and-work-tree) cannot1 be correctly shared across a machine boundary. This holds for network drives, VM images, Dropbox folders (which have other issues), or any other sharing mechanism that allows either system to directly view the other system's data.
The end result of all of this is that it's sometimes, just barely, possible to share a Git repository this way, but it's a bad idea: you'll get odd effects, such as Git missing some modified files, or thinking files are modified when they aren't. The latter is what you're seeing, probably.
It really works a lot better, though, not to share repository directories (nor work-trees) like this. That's even true on "friendlier" systems, such as MacOS vs Linux when using VMs and, e.g., vagrant. It sort of works, sometimes, but it just is not reliable. Use separate clones and your life will be happier.
1At compile time, one can choose to have Git ignore the st_dev field, to enable sharing across network drives. That sometimes makes a difference, and sometimes doesn't. I suspect this option is chosen in most Windows builds so that Windows can share with Windows, but is not enabled in Linux builds, which means the Linux side won't ignore changes made by the Windows side—which will result in odd behavior.
The timestamps are normally compatible, but if one enables nanosecond-resolution time stamps, that may also be problematic.
I use two OSs (Windows and Linux). And the git status also didn't indicate the same thing. I noticed that this happened for some repositories and not for all.
Comparing the configurations between the repositories that reported errors and the others (which git status did not indicate errors) I noticed different configurations...
For those with problem, I applied the following settings. The first one is necessary, the others I did to standardize all my repos.
git config core.fileMode false
git config core.symlinks false
git config core.ignorecase true
For more information about file.mode...
I'm working in a environment where files are at Windows side (because I like to work with phpStorm from that side) and Linux side (because I've a Virtual Machine running CentOS 6.6 and there is where LAMP environment is). The phpStorm project is a remote files one. This are the steps I followed to create the project:
Clone the repo at Windows directory
Copy the files to Linux using WinSCP
Create the remote project using phpStorm and this step copy the whole files from Linux to Windows.
I'm using SmartGit to manage my repos and do GIT/SVN tasks (the easy way). But surprise, files hasn't been changed but SmartGit says it does, but waits? How is that possible if the only steps I did was the one described above? Even if you try to open a file SmartGit will said that the content is the same? So, how to avoid this behavior? How to not to commit the whole files? If I made a commit already, how do I dismiss it? Is not the first time I'm running this problem but before repos was mine and I can lose every but now is a serious project and I take care for not damage others work. Any advice? Help? What you can do in this case?
See this pic:
There you can see what I'm talking about.
The need
Recently I've started flirting with the idea of making my own customized Debian live distro. My aim is to have an USB stick with Debian, specific packages, custom scripts and files installed inside. In this way, I can take my OS with everything I need to work with without taking my laptop with me. Furthermore, It will be specially useful in case I just wanted to replicate the OS without the hassle of installing every single packages and further customizations over again.
The research
So I decided to go for it and educate myself on the subject. I've found the Linux from scratch project (LFS), but to be honest, it will take me lots of time I currently cannot afford to invest (But seriously thinking for the future).
I decided to use the live-build project scripts based on the instructions and examples of their manual. http://live.debian.net/manual/3.x/html/live-manual.en.html
The problem
So far, I've built a hybrid.iso image with a custom selection of packages by specifying them in the /config/packages-list/mylist.list.chroot.
Then I tried to copy my custom scripts, files and software inside specific folders under the chroot directory just created,
i.e.
mkdir chroot/etc/skel/<custom dir here>
or
cp <some file or script> chroot/usr/local/bin/
and then run
lb build binary
The problem is that the iso doesn't get built after the first time I run lb build and the customizations done on the chroot directory are deleted every time I try to build it again.
I've tried...
lb clean --binary
lb clean --stage
lb build binary
or
lb build binary iso
So what am I missing? How can I add custom files, folders, scripts to my custom live Debian without downloading every single package over again?
why isn't the iso image built again after the first time I run lb build?
Thanks in advance...
P.D: I decided to be very detailed on the writing so anyone could understand, specially those that want to try the same...
I am conscious about LFS too. But, this
My aim is to have an USB stick with Debian, specific packages, custom
scripts and files installed inside.
and this
it will take me lots of time I currently cannot afford to invest
made me pointing to my answer
I have two suggestions. The easy one, use tools like remastersys or live-magic.
Follow this link.
The difficult one, follow the official documentation to how to creat a custom debian cd.
Debian official doc
This answer comes a year late for the original poster, but for future searchers: don't add files directly to the chroot. Instead, make a folder structure in config/includes.chroot. Then your customizations will be retained when you rebuild the image.
See the section "Live/chroot local includes" in the debian-live manual: http://live.debian.net/manual/4.x/html/live-manual.en.html#506
I have written an open source (GPL) application for Linux and OSX and now wish to distribute it. Is it normal to distribute the source code along with the binaries by default, or just provide a link to where it can be obtained?
If I include the source files, where is the normal location for writing them on the users system for Linux and OSX (I thought /usr/local/src but on my Ubuntu machine, supposedly chock-full of open source apps, this directory is empty).
It is usual to distribute the sources and binaries separately. Binaries would normally be distributed in distro-specific package formats whilst sources would be a simple .tar.gz containing a project folder. The user could unpack it to /usr/local/src if they wanted but it should build anywhere. It's not up to your program to drop its sources in any particular location.
I thought /usr/local/src but on my Ubuntu machine, supposedly chock-full of open source apps, this directory is empty
It will be empty if you are only using the Ubuntu repos. The OS is in charge of /usr and will drop any sources you install into /usr/src. But /usr/local is left for you to play with; that's where you install stuff that the distro doesn't provide.
About /usr/local/src
/usr/local and any subdirectories are always going to be empty on your machine unless YOU have specifically put something in there. It's a section of the filesystem that is reserved for user-installed software for that specific machine. Ubuntu (or any distribution) is not ever supposed to touch it.
Your distro will have separate places for its own source code, if any. Most Ubuntu installations won't need source code anyway (though you can download it if you want to), but if they do it'll go somewhere like /usr/src. But if you want to place your own source code somewhere and don't want your distro to mess with it, then just:
If it's just for developing/compiling in your own user account, you can just put it somewhere in your home directory.
If it's a piece of software you'll installing on the system, /usr/local/src is the suggested spot and your distro won't mess with it there.
FHS is the standard which says where in the filesystems things go, and includes distinctions such as the ones I've discussed above.
Your software should be able to be compiled no matter which directory it's in, because as you can see, it can depend.
It's worth looking at a few projects on Sourceforge (http://www.sf.net). As menioned by #bobince it's normal to distribute binaries and source separately. It's certainly kind to users not to require compilation so they can download and run.
I have nearly identical Linux (Fedora) machines at home and at work and I keep my files on both machines synchronized using the excellent Unison program. I have been trying to keep an eclipse workspace synchronized across the two machines but this has failed. I tried both:
Synchronize just the /workspace directory, badness due to plugin upgrades
Synchronize both /workspace and my .eclipse/ director.
What happens is that I work in one machine, create new projects on eclipse, etc. Then unison. Then when I go to the other machine the projects will sometimes not appear, sometimes they will appear but eclipse cannot find the files, and sometimes (rarely) it works.
I don't understand why eclipse gets so confused since I have identical workspaces, eclipse versions, and even .eclipse directories.
Have considered going through a source control repository? If privacy is a concern, there are private SVN spaces available (e.g. assembla).
I understand this technique will (at least) make it possible to synchronize the projects but probably not all the settings related to a workspace. It might be an option, no?
Take a look at Pulse. It's an Eclipse distribution that can handle synchronization of workspace preferences across users and machines. It might be what you need.
I have been using dropbox to synchronize my workspace. I have been able to work on 3 different computers so far without any issues.
I used to store my workspace(s) and sometimes the eclipse installation itself on a USB stick drive and use that for project portability from windows machine to windows machine. You can then just run Eclipse from the stick and mount the workspace on the same stick.
I have also heard that drop box (http://getdropbox.com - they have a 2gb free plan) is useful for this, though I have not tried it.
It's odd that it does not work with your sync software.
I've ad issues with unison and eclipse and have them mostly worked out though it still needs to refresh the entire workspace when I switch systems.
There are two issues I've discovered that need to be configured before it is at all happy:
1) sync your workspace, your eclipse install and ~/.eclipse
2) Specify "ignorenot" rules in your unison "prf" files to not ignore any files in these directories. This is necessary because, by default, unison excludes files it thinks are built unsing rules similar to CVS which causes issues.
for example:
path = eclipse
path = workspace
path = .eclipse
ignorenot Regex eclipse/.*
ignorenot Regex workspace/.*
ignorenot Regex .eclipse/.*
Have you considered setting up a network drive and installing Eclipse on that drive (along with your workspace)? That way, when you open Eclipse on either machine, it will be pointing at the network path for your workspace. I've successfully used this solution in the past.
I used the Mercurial DVSC on a USB stick as the transfer between home and work. I had three Mercurial repositories: one on the USB stick, one at home and one at the office sharing the same space as my Subversion checkout. If you're up-to-speed with DVSC concepts, I'd push/pull changes from office->USB->home.
It worked fine, but the first check-in was a pain as USB flash writes have crappy speeds. Pushing/pulling deltas was fairly quick afterwords.
I believe the Mozilla guys use a similar hybrid approach of SVN for the 'official' repository, but the developers use Mercurial for their development environment.