Need help applying MinGW patches for std string, getting unexpected ends - c++

I'm trying to apply these patches:
http://tehsausage.com/mingw-to-string
So that I can use std string stuff that I should have access to anyways.
I have MinGW 4.7.2, and at first, I tried copying the zip files with no luck.
Now I'm trying to manually apply the patches. I copied the patch information into a file.patch, placed it in the same folder as the file I am patching, and ran
patch < file.patch
and then I get:
patching file stdio.h
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 574.
patch unexpectedly ends in middle of line
1 out of 1 hunk FAILED -- saving rejects to file stdio.h.rej
patch unexpectedly ends in middle of line
I made sure that there is no extra white space at the end..
Please help!

OK, installed the latest mingw from the web-site, downloaded the patch files and made sure they were clean.
I applied each one individually, and they worked without issue. There was a warning that it was 'Stripping the trailing CRs from the file', but it worked without issue.
each patch is applied in the appropriate directory; e.g. the stdio.patch is applied to stdio.h which is in /mingw/include using:
patch </path/to/stdio.patch
ditto for wchar.patch
The os_defines.h file is found at /mingw/lib/gcc/mingw32/4.7.2/include/c++/mingw32/bits, and the patch works properly for that one as well.
I created a github with the patches at https://github.com/petesh/mingwpatches.git - you can clone the repository, or download the individual files from there. Each of them should work correctly without more than a complaint about the trailing CR warning.

After looking at the patch files, you probably need to use the -c option to the patch command. This tells patch that the patch-files are from a context diff.
E.g.
$ patch -c < file.patch

Related

Applying a Patch to a library using MinGW?

There's a similarenter link description here It's on the below link.
I have been given a patch on an email and I need to create a patch file. I have just pasted the contents into a text file and saved it as 'All Files' as file.patch. As far as I can tell this is correct.
This patch will apply to multiple files in a library.
I'm not sure how to apply the patch. I'm guessing that this is done using MinGW but I'm not sure how. I have set the above directory to the library in the command line like this..
cd c:\library
I place the patch file in this libraries base director and write the name of the patch.
file.patch
When I do this (I have tortoise svn installed on my pc) a the patch file opens up with a bunch of colors (Red/Yellor/Green) highlighting some of the text in the file.
Does this mean the patch automatically applies or am I going about this completely the wrong way?
I can't put the patch on the internet but the explanation above is clear.
If I have it all wrong would someone mind explaining how I apply a patch using MinGW on Windows? Thanks

How do I edit and repackage the source code of a RPM?

The title of this question does not begin to capture my years of exasperation with the RPM system. There is a vast gulf between a development system (./configure; make; make install;) and a rpm system (tar files, patch files, spec files, arcane build scripts, environments and tools) which I cannot bridge.
All I want to do is to change a few lines of code in a bigger program.
The problems which I run into:
Getting the source code of the system as-installed (e.g. SRPM from EPEL, original tarball, something else). What source should I use?
Getting that source code into a ready-to-edit form - something that I can edit with my favourite editor. How can I know that I'm editing the code as-deployed, bugs and all? (rpm -ivh x.src.rpm gives me tar files and squabs of patch files littered about in the SOURCES directory ... how can I get it right?)
Editing the code to implement some amazing hack (this part I can actually do).
Compiling the amazing code as edited - just compiling it in-place. Usually I can get this right, but it would be nice to have a hand sometimes, e.g. with ./configure set to use something other than the default /usr/local and /lost+found/opt/etc/opt or whatever crazy default autoconf decides to use.
Transforming my edits into a patch against the previous source and building new RPMs to test on some remote system (this is the great promise of RPM - pristine sources and hacky patches). If I do a diff of the original and the edited directories, the resulting patch contains all sorts of rubbish that I don't want to delete because I'm still developing (e.g. object code). (Actually, I don't have an 'original' at this point to do a diff against ... because I was only looking at the code casually when I realised I could "improve" it ...) Should I use some revision control system to track the changes I am making?
This should be simple stuff, but somehow all I can do is edit the code. After I have edited the code, it can never get over the hump, even though it is an already-solved problem. I have a GREAT fix for an open source project, but every single time that I finish developing my amazing hack, having delved into the code and made it compile (and possibly work), I am completely stumped. Nothing at all can turn my modified and now amazing source tree into a RPM. I end up deploying source code (into /usr/local), because that at least works.
How do people who do (say) security fixes actually go about the extract-edit-compile-test loop?
The SRPM is (relatively) self-contained: there are often some assumptions about build requirements not reflected in the spec file.
I would start by taking the SRPM, and rebuilding it to address the issue of build-requirements (adding whatever is needed to get it to build).
Then, extract the spec-file and sources from the SRPM, putting the patches and tar-file(s) into ~/rpmbuild/SOURCES, and building from the spec-file
Next, modify the spec-file to add my own patch file (or scripting changes),
Finally there's a new SRPM with my changes.
For extracting, I use an unrpm script (essentially a wrapper around cpio) which can be found on the network.
Making your own patch file is discussed here:
HowTo Create A Patch File For A RPM
RPM - Creating Patches
Patches for .spec file

Running NotePad++ from Command line with Compare Plugin showing compare result

I am trying to find a way to call notepad++ from command line with compare plugin showing the compare result providing I pass 2 files name which I want to compare.
Think like I have a batch file, which does some work and result is opening notepad++ showing 2 files in compare mode. (Yes, compare plugin is installed)
If anyone has any other suggestion to using any other editor or software also welcome..
tl;dr:
The command is Notepad++\plugins\ComparePlugin\compare.exe file1 file2.
Details:
Download the compare plugin https://bitbucket.org/uph0/compare/downloads/ComparePlugin.v1.5.6.6.bin.zip. Installing the compare plugin from the plugin manager within Notepad++ does not install the requisite exe. I assume you could also build from source to obtain the exe.
Follow the manual installation instructions in the readme:
To install manually, copy ComparePlugin.dll and ComparePlugin subfolder
into the plugins directory C:\Program Files\Notepad++\Plugins.
For a portable Notepad++ installation, you need to run the command from a directory above the notepad++ directory (or with absolute path of exe), otherwise you get an error that Notepad++.exe is not found.
The commands look like this:
>cd C:\portapps\Notepad++
>cd ..
>Notepad++\plugins\ComparePlugin\compare.exe C:\files\file1.txt C:\files\file2.txt
ufo's answer put me on the right track but it did not contain the commands to run.
There's a tool called NppCompareLoader doing exactly what you want. Simply drop it in the N++ installation folder. I'm using it since many years as a diff viewer for TortoiseSVN and TortoiseGit, thus you should certainly be able to call it right from command line.
/EDIT
Since the (unofficial) Compare-plug-in version 1.5.6.6 the additional loader mentioned above isn't required anymore. There's already one included in the plug-in. Here's the regarding change-log fragment:
NEW: Loader for using N++ as an external diff viewer (e.g. in TortoiseSVN, TortoiseGit, ..)

How to have Jenkins ignore certain files when checking for change?

In the "Excluded Regions" of the CVS configuration, I have added the following:
.*/.*/.*\.d
.*/.*/.*\.o
.*/.*/.*\.so
.*/.*/.*\.a
.*/.*/.*\.exe
.*/.*/.*\.obj
.*/.*/.*\.dll
.*/.*/.*\.lib
.*/.*/.*\.txt
.*/.*/.*\.tar
.*/.*/.*\.tar\.gz
All files with the above extensions should be ignored. However, Jenkins still runs builds based on the fact that a file "build.txt" in some folder ABC has changed, or the one of the tar.gz files has changed. How to get Jenkins to ignore these files? Is something wrong with my regex?
Glad that worked for you! Reposting as requested:
My guess is it has to do with the .*/ parts. Have you tried it with just .*\.txt?
Just as an experiment, you might also try /.*/.*/.*\.txt (note the extra / at the beginning). I have a feeling the problem was related to using relative vs. absolute file paths.

How to apply django patches

I want to apply a patch to this bug (http://code.djangoproject.com/ticket/13095) but I have never done it before and I have no idea where to begin. Can anyone point me to a tutorial?
On Linux/UNIX, you can use the patch command for this.
It works in the following way:
cd /usr/lib.../site-packages/django/
patch --dry-run -p1 < ~/downloads/somefix.patch
The patch command looks in the file to find the proper files it needs to update.
The -p1 tells patch to ignore the first level of the folder mentioned in the patch file. Often this is the project name itself. The --dry-run option prevents actual execution, so you can experiment with it.
When everything is allright, you can remove the --dry-run option, and the actual patch will be applied.
On Windows, several tools (e.g. WinMerge / TortoiseMerge) have a "Apply patch" option in the menu, which will allow you to do the same thing.
Try 'patch' if you are using a linux based server.
http://en.wikipedia.org/wiki/Patch_%28Unix%29
Windows appears do have a utility written for it although I havent used one
http://gnuwin32.sourceforge.net/packages/patch.htm
remember to make backups of the directory if you are unsure of its outcome