When installing a new CocoaPod, I got the following error.
$ pod install
Analyzing dependencies
[!] Pod::Executable pull
A AFHARchiver/0.2.1/AFHARchiver.podspec
A AFWunderlist/1.0/AFWunderlist.podspec
A AFWunderlist/1.1/AFWunderlist.podspec
A AFgzipRequestSerializer/0.0.1/AFgzipRequestSerializer.podspec
.
.
.
A wpxmlrpc/0.4/wpxmlrpc.podspec
A zipzap/6.0/zipzap.podspec
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use `'git add/rm <file>'`
as appropriate to mark resolution, or use `'git commit -a'`.
Thought I would share the fix below.
Problem was with specs repository, not on my side.
Found the answer here podfile gives an error on install, but since the question was less explicit on the symptom, I thought I would cross-reference it again in case someone was looking it up differently.
The answer is in the blog post here http://blog.cocoapods.org/Repairing-Our-Broken-Specs-Repository/ which explains the issue and the fix which is repeated below:
"You are going to have to manually delete any local copies of the Specs repository and re-clone the new version of the Specs repository. You can do that with the following commands:
$ pod repo remove master
$ pod setup
If you have any local commits or changes to the Specs repository which are not merged, you should ensure you have a copy of them. I would recommend that you manually copy these changes over and re-commit them. You can fix your repository without deleting, however, this is not a simple process, so we are instead recommending that you delete your copy of the Specs repository and any forks of it."
rm -rf ~/.cocoapods also works
Related
I have developed my own application and this app have already some pods dependency like Almofire, SwiftJSON, MBProgressHUD and many more. I want to create my own Cocoapods in which these dependency can be linked
Please follow these steps to create your won Cococapods -
Create a public repository on your git account
Copy Repository Url. Open terminal and run following command.
git clone <-Repository Url->.git
Now Copy all the xcode project file and folder inside the cloned
repo. and run the below command
git add *
git commit -m "Initial Setup"
git push origin master
Create a new release to go to your git repository or run following
commands
git tag 1.0.0
git push --tags
Generate create Podspec file
Run the below command to generate the podspec file.
touch reponame.podscpec
Open the podspec file on any editor and paste these text as it is.
Format like below attached screenshot.
Save the file and Now run the below command on terminal.
pod lib lint
If validation passed. then run the below commands
pod trunk register <-abx#xyz.com-> 'user name'
You will get an email for verification. Just verify the email and now run the below command.
pod trunk push PodName.podspec
If all goes well, you will get this on terminal
Congratulations. Now you can use this pod whenever you want.
You can follow this link as well. I have created my own steps with reference for this link to ease the ways.
https://www.appcoda.com/cocoapods-making-guide/
I had not heard of this file until I randomly checked git status in an old repository and there it was, a file I had not edited myself nor ever seen before. I do not know how it got there.
It seems it's common asked about - mostly how to remove it (e.g. here and here).
What is this file, and what created it?
.idea is the dir for saving the project configurations for all Jetbrains IDES (RubyMine , Pycharm , PHPStorm , WebStorm ..etc)
you can handle it using two ways if you don't want to commit it to the repo
Ignore it only for yourself
in .git/info/exclude
add /.idea
Ignore it in .gitignore so it will be ignored for everyone who uses the repo
by adding /.idea to .gitignore
if the dir .idea already tracked by git you will need to remove it first from the cached files before ignoring by git rm -r --cached .idea
This folder can include important configuration if you did any custom configuration for the project and also include the indexed data for the IDE which helps it to provide quick autocomplete and in certain cases would be better to commit it to the repo but I always ignore it because the other developers in the team don't use RubyMinee
In the project, I have cloned from my organization's GitLab, there is a module in the package.json as:
"react-native-device-info": "https://github.com/KarlosQ/react-native-device-info#master",
and respectively in the yarn.lock we have
"react-native-device-info#https://github.com/KarlosQ/react-native-device-info#master":
version "0.21.5"
resolved "https://github.com/KarlosQ/react-native-device-info#beebff8dc284decfba917f2c6d30d0e535cc4002"
For any reason that commit beebff8dc... does not exist at the master branch of the module.
Because of that, all builds in the GitLab pipeline fails.
error Couldn't find match for "beebff8dc..." in ....
How can I change it locally and push to the remote branch that affects the pipeline and build passes?
Clearing the Yarn cache locally did not help. deleting that module from yarn.lock causes other issues that my organization account is not recognized anymore and yarn install fails!
Run:
yarn uninstall react-native-device-info && yarn add react-native-device-info#0.21.5
The first one will remove the dependency from your node_modules, package.json and yarn.lock.
The second one will recover the version you are depending on, namely 0.21.5 as stated in your old yarn.lock.
You should not concern yourself with any specific commit, but should yarn handle the internals.
The missing commit was most likely deleted from the master branch of the external repository and hence will never be resolved properly.
... $make menuconfig
select some package
... $make
...
there are many bin files in the bin folder.:
My question is , I want to change some software source code of openwrt and rebuild again.
I have try to edit some source code of build_dir. But want I rebuild openwrt My code with be refresh with the newest code of svn.
Does any one how to do that?
Writing your code and synchronizing it:
1) Clone the official linino repository from Arduino on your machine using git (install it using sudo apt-get install git):
git clone https://github.com/linino/linino_distro.git
2) Do your own changes in the relevant code files, Makefiles or whatever that you need to change.
3) Whenever you want to synchronize your work with the latest changes from the remote master branch in the linino repository, you need to first fetch the changes, meaning retrieving them without yet merging them, then in a 2nd time merge them and then resolve conflicts if any:
Preliminary: if you created a local branch with your own changes make sur you get back to the master branch, you need to check out the master:
git checkout master
a) fetching the latest changes:
git fetch master
b) Merging them with your changes on your local repository (normally called origin):
git merge origin/master
Note: alternatively you can do it in one command:
git pull
It essentially does a fetch and a merge at the same time but it's important to understand the process using fetch first. From experience it can be confusing for beginners, plus it can cause automerge if not explicitely specified otherwise, causing more work to undo them.
4) Now you're ready to resolve conflicts if any, for that you can use:
git mergetool
This will allow you to resolve conflicts using a graphical tool such as tkdiff (2 way merge tool), or meld (3 way merge tool, diff your changes, the changes from the remote master, and the original file).
Compiling your code:
5) Open a terminal in your linino buildroot directory, make sure you get to update the config if you added any new packages, then recompile the image i.e.
cd ~/myLininoBuildRoot/trunk
make menuconfig
#now select your new package, that you added in trunk/package
# Make sure you save the configuration before exiting
make
Note: Alternatively you can recompile packages one by one. Instead of doing a simple make do:
Preliminary step:
Make sure to have compiled the linino toolchain that allows you to compile packages separately:
cd trunk/
make tools/install
make toolchain/install
make target/compile
Then compile your package:
make package/myPackage
Or Alternatively, you can be more specific by selecting the any target from your package Makefile say for instance install or compile or build targets:
make package/myPackage/install
make package/myPackage/compile
make package/myPackage/build
Finally, recompile the index target common to all packages that will allow you to have an bin directory trunk/bin/yourArchitecture/packages that contains an up to date index of packages including your freshly compiled one:
make package/index
More info at: http://wiki.openwrt.org/doc/howto/build.a.package
Checking that everything is alright:
Now go have a look at trunk/bin/yourArchitecture/packages/Packages, do a grep to make sure it is listed in Packages (the actual packages index file) and is up to date:
grep Packages | myPackage
You probably want to:
Get the latest version of the source code.
Make whatever changes you want.
Use diff to make a patch recording your changes.
Update the source code (in the future)
Use patch to apply the patch
Manually perform any changes that could not be patched.
This is example build motion to newer version.
edit:
../package/feeds/packages/motion
Original Makefile
PKG_NAME:=motion
PKG_VERSION:=20110826-051001
PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.lavrsen.dk/sources/motion-daily \
#SF/motion
PKG_MD5SUM:=e703fce57ae2215cb05f25e3027f5818
Edited Makefile
PKG_NAME:=motion
PKG_VERSION:=20120605-224837
PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.lavrsen.dk/sources/motion-daily \
#SF/motion
PKG_MD5SUM:=145fffcb99aed311a9c1d93b838db66f
You can also change Package Source URL (PKG_SOURCE_URL) if necessary
Rebuild newer motion application with:
make package/feeds/packages/motion/compile
Let's say I have a main Project A with several cocoapods dependencies (which are internally owned by our organization's cocoapods repo).
Let's say I'm working on Project A, and while working on it I find a fix on a DependencyB, so I modify the code in that dependency while still being on ProjectA's Xcode project.
What would be the best workflow to push the changes on that dependency to it's own repository and then updating that dependency in Project A?
I would really like some ways so avoid, completely automate or simplify the following workflow (which is a PITA)
Worflow to avoid
git clone git#github.com:Organization/DependencyB.git
Make your changes in the dependency project (the same changes that where made while fixing the issue that I found while working on Project A)
Update the DependencyB.podspec file
s.version = "0.1.7"
s.source = { :git => "https://github.com/Organization/DependencyB.git", :tag => "0.1.7" }
Commit & Tag this dependency's version
git add -A
git commit -m 'Made some changes'
git tag -a 0.1.7 -m 'This is an awesome tag :D'
git push origin master
git push --tags origin
Update the organiazation's private cocoapods repo (which I stored in ~/)
cd ~/.cocoapods/OrganizationPrivateRepo/CoverFlux
mkdir 0.1.7
cd 0.1.7
copy the updated DependencyB.podspec to the organiation's private repo (cloned in ~/.cocoapods)
~/.cocoapods/OrganizationPrivateRepo/DependencyB/0.1.7/CoverFlux.podspec
Commit changes in the private repository & push to remote
cd ~/.cocoapods/OrganizationPrivateRepo/
git commit -am 'Added version 0.1.7 to DependencyB spec'
git push origin master
Finally proceed to the initial's 'Project A' folder and update
pod update
Note:
Project's A podfile looks like:
platform :ios, '6.0'
pod 'DependencyB'
Here are some tips to simplify your workflow. Beyond these, you might need to consider making some additional scripts.
First, I recommend that you keep your podspec file located at the root of your project. So, DependencyB.git would have the file DependencyB.podspec.
Simplify Step 3
Change your source tag to reference the version. This way, you only need to change the version line in your podspec.
s.source = { :git => "https://github.com/Organization/DependencyB.git", :tag => "#{s.version}" }
Simplify Steps 5, 6, and 7
Run the following from your DependencyB.git directory. (Assuming you have your podspec there as I suggested above)
pod push OrganizationPrivateRepo DependencyB.podspec
If DependencyB.podspec is the only podspec file, you don't even need to include it on the line, yielding:
pod push OrganizationPrivateRepo
Step 4
Finally, I think that simplifying Step 4 is possible, but is one of those things that varies between organizations and individual developers as it is part of their workflow. For example, I normally commit from my IDE.
Such scripts could be integrated into the podspec so that they update the s.version value. Or alternatively, get the correct tag from the s.version value.
UPDATE: Simplify Step 2
It looks like you are making a change twice to DependencyB. You can have CocoaPods setup a symbolic link. In ProjectA's Podfile, set the following:
pod 'DependencyB', :path => "../path/to/DependencyB'
You can now edit the files in DependencyB from ProjectA. You will need to run pod update after making this change. After that, the changes to the source will be available immediately since it is a symbolic link. I have had trouble making Git commits from Xcode when doing this, but other than that it works well.