I am trying to add new c file in place of file that already comes after downloading the package from git.Tried bbappend but the original file is still there.also modified src_uri += file://fileone.c but that is also not overwriting file.
Any suggestions would be of great help
Regards
Mayank
This is where devtool modify can be very helpful if you're using the jethro (2.0) release or later. Assuming you have already sourced the environment setup script:
devtool modify <recipename>
It will tell you where it has extracted the source - cd into that directory.
Make the changes to the file that you want - which could be overwriting it completely.
git commit -a to commit your changes
devtool update-recipe <recipename> -a /path/to/your/custom/layer (assuming you want to create a bbappend in a custom layer, otherwise just omit the -a and path to apply the changes to the original recipe instead).
If you are completely finished, you can devtool reset <recipename> to put everything back to building completely from the metadata.
So the original C file is part of the release tarball (or git, or wherever the release comes from) and you want to replace that file with your own before configure and compile happen?
Replacing the whole file is just a special case of any smaller changes you might want to do the source files, so just do what you would do in those cases: create a patch the replaces the file and add the patch with SRC_URI += file://replace-file-with-my-file.patch.
I use this work flow (in the project source directory, e.g. poky/build/tmp/work/corei7-64-poky-linux/my-project):
# initialize git (only if this is not a git repo already)
git init
git add *
git commit -m "original code"
# <--- here you should replace the file
git commit -a -m "Replace file with a better file"
git format-patch -1
Now you should have a patch file that you can copy into the proper recipe directory.
Related
I want to stop cloning my application files to Github, How can I do that completely and remove the circle status on each solution files?
Environment: Visual Studio for Mac
Are you intending to have git ignore those files completely?
You can use a gitignore file (.gitignore) in the root working directory of your project to specify which files to ignore. In there, specify a filename per line in that file, or a whole directory to be ignored (eg: Shared/*).
You'll also need to remove those files from your git repo, since they've already been committed.
Copy-pasting from here:
Unstage the file
git reset HEAD newfile
Remove the file from git
git rm --cached newfile
Deleting the file will count as a commit, so you'll need to git push once you're done.
Also note that the file(s) and their contents will still exist in the git commit history, so this isn't a good idea if the goal is removing files with sensitive info.
I'm trying to upload my copy of Godot to my own github and it complains:
remote: error: File Godot.app/Contents/MacOS/Godot is 156.41 MB; this exceeds GitHub's file size limit of 100.00 MB
Ideally I dont want to upload this file at all.
I tried adding it to the .gitignore file.
I tried adding all kinds of different ways to type the path but none of them worked.
Heres the end of the file:
# Scons progress indicator
.scons_node_count
# ccls cache (https://github.com/MaskRay/ccls)
.ccls-cache/
# compile commands (https://clang.llvm.org/docs/JSONCompilationDatabase.html)
compile_commands.json
# Cppcheck
*.cppcheck
# https://clangd.llvm.org/ cache folder
.clangd/
.cache/
# The Godot app
/Godot.app
The pattern /Godot.app should match your file just fine. However, if the file is already added to the repository, then .gitignore has no effect on it. The .gitignore file affects only files which are untracked.
In your case, your file is in the history, and it needs to be removed from the entire history if you want to upload it to GitHub. You can do a git rebase -i to go back in history to the point at which it was added and remove it from history, or, if it was added in the most recent commit, you can remove it with git rm -r Godot.app and then run git commit --amend.
You could also use git filter-branch or git filter-repo to filter it out from the history.
Is it good practice to edit source code in poky/build/tmp/work directory ? because if we accidentally cleansstate ,the changes will be erased.
Alternatively we can edit source code in "files" directory along with recipe file but since mostly code here is in zipped form due to large number of files , so we will need to unzip and zip again just to change one line of code.
So what is best way to edit source code in yocto ?
If your question is about permanent changes, then Dan's answer is the one to follow. I.e. add a <recipe name>.bbappend to the recipe in your own layer, in which you add
SRC_URI += "file://mypatch1.patch \
file://mypatch2.patch \
"
enumerating all the patches you need.
If there's a large number of patches, it might make sense to fork the upstream repository, and maintain your own branch in your fork. In that case, you'll likely want to reference your own repository, instead of either the upstream repository or tarball.
OTOH, if your question was more about work-in-progress; then sure, doing it in oky/build/tmp/workoky/build/tmp/work/xxxx will work. (And quite likely, it's what most people have been doing for a long time).
However, there's a much better way in recent releases (from 1.8, fido). The new tool is called devtool. You can use it as follows:
devtool modify -x <recipe-name> <path-to-unpack-source>
unpacks the source and creates a new bbappend to build from the unpacked source. It also creates a git repo in the source directory.
Now you can modify the source. You can test-build your modified source by running devtool build <recipe-name>. Once you're satisfied, use git add ... and git commit to commit your changes to the local repo. Once you've commited the changes to the local repo, you can run:
devtool update-recipe <recipe-name>
to update the recipe in question. When you're satisfied, you can run devtool reset <recipe-name> to remove the temporary bbappend.
See also: Yocto manual on modifying source code
If you are continuously "patching" a given package manually, I would recommend you to look at implementing a .bbappend file in a separate layer which applies your patch using the do_patch function (http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#patching-dev-environment).
I'm looking for the opposite mechanism to the .ignore file, which should add all files of a given pattern automatically, for example *.tex for any LaTeX documentation project or *.def for any file that was added by OASIS (an MS Access addin for version control).
hg add with no arguments will add all files not explicitly ignored. You can also use hg commit --addremove to add all unknown files (and remove all deleted files, i.e. hg rm any which hg status lists as '!') to do this automatically when committing.
Adding files only happens when you run hg add. If you want to add all files matching a pattern, use the --include (-I) switch.
I am new to Hudson / Jenkins and was wondering if there is a way to check in Hudson's configuration files to source control.
Ideally I want to be able to click some button in the UI that says 'save configuration' and have the Hudson configuration files checked in to source control.
Most helpful Answer
There is a plugin called SCM Sync configuration plugin.
Original Answer
Have a look at my answer to a similar question. The basic idea is to use the filesystem-scm-plugin to detect changes to the xml-files. Your second part would be committing the changes to SVN.
EDIT: If you find a way to determine the user for a change, let us know.
EDIT 2011-01-10 Meanwhile there is a new plugin: SCM Sync configuration plugin. Currently it only works with subversion and git, but support for more repositories is planned. I am using it since version 0.0.3 and it worked good so far.
Note that Vogella has a recent (January 2014, compared to the OP's question January 2010) and different take on this.
Consider that the SCM Sync configuration plugin can generate a lot of commits.
So, instead of relying on a plugin and an automated process, he manages the same feature manually:
Storing the Job information of Jenkins in Git
I found the amount of commits a bit overwhelming, so I decided to control the commits manually and to save only the Job information and not the Jenkins configuration.
For this switch into your Jenkins jobs directory (Ubuntu: /var/lib/jenkins/jobs) and perform the “git init” command.
I created the following .gitignore file to store only the Git jobs information:
builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber
modules/
*.log
Now you can add and commit changes at your own will.
And if you add another remote to your Git repository you can push your configuration to another server.
Alberto actually recommend to add as well (in $JENKINS_HOME):
jenkins own config (config.xml),
the jenkins plugins configs (hudson*.xml) and
the users configs (users/*/config.xml)
To manually manage your configuration with Git, the following .gitignore file may be helpful.
# Miscellaneous Hudson litter
*.log
*.tmp
*.old
*.bak
*.jar
*.json
# Generated Hudson state
/.owner
/secret.key
/queue.xml
/fingerprints/
/shelvedProjects/
/updates/
# Tools that Hudson manages
/tools/
# Extracted plugins
/plugins/*/
# Job state
builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber
See this GitHub Gist and this blog post for more details.
There is a new SCM Sync Configuration plug-in which does exactly what you are looking for.
SCM Sync Configuration Hudson plugin
is aimed at 2 main features :
Keep sync'ed your config.xml (and other ressources) hudson files with a
SCM repository
Track changes (and author) made on every file with commit messages
I haven't actually tried this yet, but it looks promising.
You can find configuration files in Jenkins home folder (e.g. /var/lib/jenkins).
To keep them in VCS, first login as Jenkins (sudo su - jenkins) and create its git credentials:
git config --global user.name "Jenkins"
git config --global user.email "jenkins#example.com"
Then initialize, add and commit the basic files such as:
git init
git add config.xml jobs/ .gitconfig
git commit -m'Adds Jenkins config files' -a
also consider creating .gitignore with the following files to ignore (customize as needed):
# Git untracked files to ignore.
# Cache.
.cache/
# Fingerprint records.
fingerprints/
# Working directories.
workspace/
# Secret files.
secrets/
secret.*
*.enc
*.key
users/
id_rsa
# Plugins.
plugins/
# State files.
*.state
# Job state files.
builds/
lastStable
lastSuccessful
nextBuildNumber
# Updates.
updates/
# Hidden files.
.*
# Except git config files.
!.git*
!.ssh/
# User content.
userContent/
# Log files.
logs/
*.log
# Miscellaneous litter
*.tmp
*.old
*.bak
*.jar
*.json
*.lastExecVersion
Then add it: git add .gitignore.
When done, you can add job config files, e.g.
shopt -s globstar
git add **/config.xml
git commit -m'Added job config files' -a
Finally add and commit any other files if needed, then push it to the remote repository where you want to keep the config files.
When Jenkins files are updated, you need to reload them (Reload Configuration from Disk) or run reload-configuration from Jenkins CLI.
A more accurate .gitignore, inspired by the reply from nepa:
*
!.gitignore
!/jobs/
!/jobs/*/
/jobs/*/*
!/jobs/*/config.xml
!/users/
!/users/*/
/users/*/*
!/users/*/config.xml
!/*.xml
It ignores everything except for .xml config files and .gitignore itself.
(the difference to nepa's .gitignore is that it doesn't "unignore" all top-level directories (!*/) like logs/, cache/, etc.)
The way I prefer is to exclude everything in the Jenkins home folder except the configuration files you really want to be in your VCS. Here is the .gitignore file I use:
*
!.gitignore
!/jobs/*/*.xml
!/*.xml
!/users/*/config.xml
!*/
This ignores everything (*) except (!) .gitignore itself, the jobs/projects, the plugin and other important and user configuration files.
It's also worth considering to include the plugins folder. Annoyingly updated plugins should be included...
Basically this solution makes it easier for future Jenkins/Hudson updates because new files aren't automatically in scope. You just get on the screeen what you really want.
Answer from Mark (https://stackoverflow.com/a/4066654/142207) should work for SVN and Git (although Git configuration did not work for me).
But if you need it to work with Mercurial repo, create a job with following script:
hg remove -A || true
hg add ../../config.xml
hg add ../../*/config.xml
if [ ! -z "`hg status -admrn`" ]; then
hg commit -m "Scheduled commit" -u fill_in_the#blank.com
hg push
fi
I've written a plugin that lets you check your Jenkins instructions into source control. Just add a .jenkins.yml file with the contents:
script:
- make
- make test
and Jenkins will do it:
I checked in hudson entirely, you could use this as a starting point https://github.com/morkeleb/continuous-delivery-with-hudson
There are benefits to keeping entire hudson in git. All config changes are logged and you can test the testup quite easily on one machine and then update the other machine(s) using git pull.
We used this as a boilerplate for our hudson continuous delivery setup at work.
Regards
Morten