I need to apply a patch to the vim source code, but I am having trouble finding the source code for version 7.3.285. The source code from the main vim site builds version 7.3.154. When I do a google search for "vim 7.3.285 source" I get mostly .rpm files and always something about Mandriva. I managed to find a .scr.rpm file and unpacked it, but then the main vim folder it had was exactly the same as the one on the vim site. My guess is that I have use the patch folder to apply the patch to version 285. So I tried the following:
Download .src.rpm file here
unpack .src.rpm file like so rpm2cpio vim-7.3.285-1.src.rpm | cpio -idmv --no-absolute-filenames
apply the patches to the vim73 folder somewhat like so for i in 'seq 0 285'; do patch -p0 < ../vim-7.3-patches/7.3.$i; done
then I also applied the aforementioned patch in a similar way patch -p1 -i ../vim-7.3.285-breakindent.patch
finally I compiled vim: configure, make and sudo make install
However, and this is where it gets weird, if I issue the command vim, it claims to be running version 7.3.285. If however, I issue the command gvim it claims to be running version 7.3.154. It was my understanding that you compile vim and gvim gets compiled too. Does anyone have any idea what is going wrong? Is there a 7.3.285 source file I can download instead to test out?
to get the 7.3.285 source clone the mercurial repo and then do hg up v7-3-285
full instructions here
Related
I had downloaded sublime previously directly from the browser as tarball and saved it in a folder (and of course extracted it).But this way I wasn't able to make Sublime my default editor and it didn't feature as an application when I tried to open a text file with a right-click.I read somewhere installing sublime text 3 using commands:
sudo add-apt-repository ppa:webupd8team/sublime-text-3
sudo apt-get update
sudo apt-get install sublime-text-installer
will solve my problem. So I directly deleted the Sublime_text3 folder saved in my Downloads directory and then used the given commands. But when I entered the 3rd command line I got the following error(just writing the error part):
subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:/var/cache/apt/archives/sublime-text-installer_3126-2~webupd8~1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Can anyone explain why this error is coming and suggest a way to solve this problem? Also if anyone can tell how I can set Sublime as my default text editor from the tarball downloaded from the sublime text 3 website. Thanks in advance!
you can try this command to install Sublime Text using Snap Store..
sudo snap install sublime-text --classic
I'm not sure overall how to fix that error or what's going on (I use Slackware and not Ubuntu/Debian), but for a long while there have been official Sublime repositories several different Linux distributions, including Ubuntu/Debian.
It's highly recommended that you use those if you want to go the package route and not use existing solutions such as the one referenced in your question or in the other response here, if for no other reason than only the official repository is guaranteed to contain an unmodified version of Sublime. Additionally the official repositories are always updated on release, which may or may not happen in a timely manner in other repositories.
The links referenced above contain instructions on how to set up and use Sublime from those repositories, and if you have any issues a good place to ask is the forum.
One thing to note which isn't mentioned explicitly in the above pages is that to use the official repositories, you should:
Choose only one of them (stable or dev, noting that you need a license to run a dev version) and not add both repositories or things will not work as expected
Ensure that other repositories that you've added (such as the one in your question) are removed to make sure that the package system definitely pulls the correct package
There are a couple of ways to go if you want to install Sublime from the tarball version. The easiest way would be to extract it, then manually set up launcher shortcuts and so on based on what falls out. How exactly you would register it as a text editor in that case, I'm not entirely sure since I don't use the same distribution as you.
Presuming that the process would be easier if Sublime was installed in a way similar to how the package manager would do it, the tarball comes with a desktop file and icons, so the following steps can be used to (presumably) do what the package installer would do.
The proviso here is that although these steps work on my non-Ubuntu machine, I don't know if all of the referenced tools are installed by default on an Ubuntu system, so so more setup work may be involved.
Note also that the files in the tarball are not entirely self-consistent, which makes this a little bit more work.
First, you need to extract the tarball (replace tarball filename as appropriate for location and build):
cd /opt
sudo tar xvf ~/Downloads/sublime_text_3_build_3176_x64.tar.bz2
This creates the folder /opt/sublime_text_3/ and fills it with the contents of the tarball.
Next, you want to install the icons contained in the tarball. As far as I have been able to tell, the icons in the tarball aren't in the correct directory structure, requiring each to be copied into place individually. We also need to update the icon cache to ensure that the new icon is noticed by the system:
cd /usr/share/icons/hicolor/
sudo cp /opt/sublime_text_3/Icon/16x16/sublime-text.png 16x16/apps/
sudo cp /opt/sublime_text_3/Icon/32x32/sublime-text.png 32x32/apps/
sudo cp /opt/sublime_text_3/Icon/48x48/sublime-text.png 48x48/apps/
sudo cp /opt/sublime_text_3/Icon/128x128/sublime-text.png 128x128/apps/
sudo cp /opt/sublime_text_3/Icon/256x256/sublime-text.png 256x256/apps/
sudo gtk-update-icon-cache -f -t .
Now we want to install the sublime_text.desktop file that is in the tarball. Note however that like the icons, it seems kind of broken; the tarball extracts to sublime_text_3 but the desktop file assumes that the application is actually in /opt/sublime_text instead.
As such, you either need to rename the folder that was extracted to sublime_text to match what is in the desktop file, or edit the desktop file to make the path correct.
The following steps assume that we want to keep the folder the same and rewrite the desktop file. These commands will generate a new file named sublime_text_3.desktop with the changes.
cd /opt/sublime_text_3/
sed -e "s^/sublime_text/^/sublime_text_3/^" sublime_text.desktop | sudo tee sublime_text_3.desktop
Now you can install the desktop file. You do that with desktop-file-install, passing it the name of the desktop file. For accessing Sublime from the command line, you also want to set up a subl link to the installed copy of Sublime.
Adjust the paths as appropriate here if you decided to rename the folder instead of editing the desktop file:
sudo desktop-file-install sublime_text_3.desktop --rebuild-mime-info-cache
sudo ln -s /opt/sublime_text_3/sublime_text /usr/bin/subl
At this point Sublime should show up as an installed application, or at least it does in my Window Manager; if not, executing sudo update-desktop-database may help refresh it.
You can try this once. i hope it will help
wget https://download.sublimetext.com/files/sublime-text_build-4126_amd64.deb
sudo dpkg -i sublime-text_build-4126_amd64.deb
I've run into an issue with patch (version 2.6) and was wondering if anyone else has run into this problem:
System A: Virtual Machine (VBOX) with FC21. diff == 3.3, patch == 2.7.5
Generate a Linux kernel patch for ixgbe driver (updating driver to support new HW)
Orig directory: linux/drivers/net/ethernet/intel/ixgbe
update dir: /home/patches/ixgbe-4.0.3
Patch file generated via diff -Naur <orig> <update> > file.patch
File looks OK. There are changed files as well as "new" file being added to the Orig.
Using BuildRoot (2015.08.01) and their patching setup, the patch executes, and works just fine, the driver builds and the image boots.
System B: Corp Server with RHEL6. diff == 2.8.1, patch == 2.6
Copied the entire Buildroot setup to this machine. Modify directory paths and the build runs OK, up until the patch. Output shows that changed files get updated OK, but any "new" file ends up in the "update dir" path, which doesn't exist in this environment. Verified the /home/xx/yy/zz directory DOES exist, that patch created from the filename in the patch file. Why????
System A works just fine, it puts the "new" file in the correct kernel directory.
Anyone seen this strange behavior before? How can I:
tell diff to use the orig directory?
tell patch to use the orig directory? (Build root handles patching via scripts)
Any assistance would be greatly appreciated. . .
Stephen
TL;DR: to generate the patch, make sure the original and modified directories are side-by-side.
Patches will be applied with -p1, i.e. the first component of the paths will be stripped off. So on the original side, you'll have drivers/net/ethernet/intel/ixgbe/<filename>, but on the patched side, you'll have home/patches/igbe/<filename>. Now it looks like patch 2.6 will take the path at the patched side, which clearly doesn't exist. I'm actually surprised that it does work with later patch versions.
The canonical way to generate patches is to make a copy of the full original source directory, i.e. the entire linux directory, and put that side-by-side with the patched directory. Then you do diff -Naur linux-orig linux-patched from the directory just above. Or, better yet, start from a git-controlled linux directory, make the modification, commit the change, and do git format-patch -1 -o <path-to-buildroot-patches>.
I've created packages previously by using a Makefile, the command "dh_make --createorig", then adjusting files in the debian folder generated and finally using the debuild command to generate the .deb. That workflow is simple and works for me, but I was told to adjust it a little in a way that you could build the project from the sources without requiring the orig files and I'm unsure how to do it, but according to this (https://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch) and this structure (http://bazaar.launchpad.net/~andrewsomething/imagination/debian/files) there must be a way. In my case I would have a folder with the sources and all of that and then a debian folder (generated with dh_make) but I'm unsure on how to avoid the debuild command to ask for the .orig files or if I should be using some other command for this.
Sorry for the superlong question, I think I provided all the relevant information, but I can clarify if anything is fuzzy.
The difference is in the version number in the file debian/changelog.
If you use 1.2.3-1 it implied Debian build 1 of an upstream package 1.2.3 --- for which the build programs (dpkg-buildpackage and whichever wrappers on top) --- assume an .orig.tar.gz to exists.
But if you use 1.2.3 it will consider the package 'Debian native' and the archive is just a .tar.gz and not an .orig.tar.gz.
Now the choice should not be driven by your convenience alone. If this has an upstream source, use the first scheme. If not, the second can be fine. In the packages I maintain I have both but way more of the former.
If you want to create a Debian directory directly in the source package (ie you're packaging your own work, rather than from an upstream release) you could use the --native option to dh_make
I think the question was asked differently, it was somewhat clear that the project was upstream and it's probably not a good reason to change its format to native.
Currently I package some upstream python project, this exact same question came to my mind. Why isn't there any dh_* hook to overwrite in order to generate this origin tarball on the fly so you do not get bothered by:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
for a start, I added a makefile to the project:
# Makefile
VERSION:=$(shell dpkg-parsechangelog -S Version | sed -rne 's,([^-\+]+)+(\+dfsg)*.*,\1,p'i)
UPSTREAM_PACKAGE:=click_${VERSION}.orig.tar.gz
dpkg:
tar cafv ../${UPSTREAM_PACKAGE} . --exclude debian --exclude .git
debuild -uc -us
clean:
rm -f ../${UPSTREAM_PACKAGE}
debuild clean
so a simple make clean dpkg was all it needed to build the package.
Now I think the question remains if someone has some bright idea how to insert the tar operation within the debian/rules so I could just call debuild -uc -us and it magically creates the orig tarball I would be awsome :)
I'm working on Linux.
I have installed a ruby rpm on my system sing following command,
rpm –ivh zenith_ruby_1.8.6-1.0-2.el5.src.rpm
Now i have added some debugging statments in the source files of this rpm
and i want to rebuild this rpm with my changes in source file.
I tried using following command
rpmbuild -ba rpmbuild/SPECS/zenith_ruby-1.8.6-p369.spec
But execution of this commands leads to overwriting the source file that cause removal of by changes from source file.
Is there any way to re-build with our changes in source file?
You should make your changes a patch that gets applied during the build process.
See this tutorial for instructions
I found the solution for above problem.
We need to execute following command to build already installed RPM :
rpmbuild -bc --short-circuit rpmbuild/SPECS/zenith_ruby-1.8.6-p369.spec
I'm getting "skipping XXX: it is not a regular file" every time I run ctags -R XXX. For one reason or another, ctags on Cygwin isn't recursing directories. Surely, I must be doing something stupid.
Whenever I try the de-facto standard ctags -R in my project root, it complains that I didn't specify any input files. When I specify a directory, it seems to think its a file.
I'm a tad stumped. I installed a fresh Cygwin build last week from scratch. I installed everything. I rarely use Cygwin. ctags works perfectly on all my BSD, Linux, Mac and Solaris boxes.
I thought Perforce's read-only permissions might have been the culprit, but chmod 777 changes nothing.
Any ideas? Should I recompile from source?
As is currently being discussed on the Cygwin mailing list, the xemacs-tags and ctags packages both install /bin/ctags. The behaviour you're seeing is from the xemacs version.
The developers will sort it out, although that may take a little while. In the meantime, do the following to get Exuberant Ctags (with its working -R option) installed:
Run the Cygwin installer again (download setup.exe again if you need to).
At the package list, search for "tags" and click the "New" column for both "ctags" and "xemacs-tags" until they say either "Skip" or "Uninstall" (one's under "Devel", the other under "Editors".
Hit "Next".
Once the install has completed, click "Back" instead of "Finish" (if you do this wrong, just restart the installer).
At the package list, select to install "ctags" only. As of today (12 December 2012), that'll specify version 5.8-1.
Click Next and let the install finish.
That'll give you the "ctags" package without the "xemacs-tags" package, and you should be good to go.
I'm getting the same problem, just installed full Cygwin Oct 2012. Downloaded Exuberant Ctags source, compiled, and no more problem.