adding patch and patch file to a pkgsrc application

johnb

Hi;
I want to add a couple of patch file to a port in pkgsrc to be used during install. How should I go about that.
Thank You
J.B
related topic:
https://www.unitedbsd.com/d/165-difference-between-plistand-destdir-while-building-from-source/4

johnb this is tricky to explain, but let's try and, to put things into context let's do it with a fake-pkg

cd /usr/pkgsrc/fake-pkg
make

Now, for some reason your build failed and you need to patch a file to make it work, let's say the Makefile

cd/work/fake-pkg
pkgvi Makefile

Do your edits to the file and save them.

cd /usr/pkgsrc/fake-pkg
mkpatches

you should now have a patches folder inside /usr/pkgsrc/fake-pkg
cd into it and check how many files it contains. Remove the file which contains orig in the name and edit the other one adding a comment as to why the patch is needed. Then,

cd /usr/pkgsrc/fake-pkg
make clean
make makepatchsum

Check everything looks fine with pkglint -e, if not correct what's wrong and when happy just start the build again.
See also section 13.3.2 of the pkgsrc-guide.

johnb

pin you explained it perfectly.
but what if the patch file(s) come(s) from somewhere else and should be applied to the source code directory.
also they should be included to the pkgsrc tree?
Where should the patch files reside?
How/What "inside the package dir in pkgsrc" should be tweaked for those patches to be applied to the source code?
Example:
For fvwm 2.9.6 and upward there are couple of patches for round window corner and transparency. I want them to be applied automatically before the "make -j X" process do its job.

JuvenalUrbino

One of the best features of pkgsrc is the support for a LOCALPATCHES variable for local user's patches not meant to be committed to the main tree. The patches directory tree needs the reflect the same “category/package” structure as pkgsrc. Check out 13.3.2. Creating patch files on the pkgsrc developer guide.
Supposing I decided to store may patches at $HOME/pkgsrc/patches, and planned to patch for mail/mutt (as I do) in order to add sidebar support, I'd place my patch at ~/pkgsrc/patches/mutt/mail/patch-SIDEBAR.patch, and point pkgsrc to it by appending:

   

LOCALPATCHES   =   /home/<myusername>/pkgsrc/patches

to my /etc/mk.conf. See also mk.conf defaults

johnb

JuvenalUrbino So by point LOCALPATCHES to a patch directory (i.e with the same name as directories in pkgsrc) and setting the config inside mk.conf the make command automatically applies them?

JuvenalUrbino

johnb yes, make will pull them right after applying upstream patches

johnb if those patches are written according to pkgsrc requirements and, if they respect the naming nomenclature required by pkgsrc. Check if the line numbers are in agreement with the upstream source and add a comment to the patches as of why they are required.

Once you have meet all the logic operators above you could just dump the files inside /fvwm/patches directory and regenerate the checksums with make makepatchsum and hit make 😉

JuvenalUrbino

pin AFAICT (please, correct me if I'm wrong) LOCALPATCHES are not not verified (and do not require a checksum), as they're supposed to be secure, being locally stored. Respecting the naming convention is not a requirement either, as those patches are not meant to be commited. In my experience patching multiple files within the same patch file works too.
All one needs to do is placing a file containing a diff (generated with diff -bu) between the .orig file and the custom one in the proper folder, in accordance with pkgsrc tree structure.

For example I may generate a new patch with diff -bu for textrproc/urlview redirecting the output to a new ~/pkgsrc/patches/textproc/urlview/mypatch.patch file:

--- urlview.c.orig      2020-04-15 11:07:04.906046429 +0200
+++ urlview.c   2020-04-15 11:07:05.033935127 +0200
@@ -408,6 +408,10 @@

 oldcurrent = current;

+    /* XXX seems to prevent strange characters to appear on the
+       input line before entering a search string */
+    memset(search, '\0', sizeof search);
+
     switch (i = getch ())
     {
       case 'q':

Now, providing I set $LOCALPATCHES as above, all I have to do is go to /usr/pkgsrc/textproc/urlview and run make, which properly applies the patch – automatically skipping the 'Verifying' step (unlike upstream patches) – returning:

=> Applying pkgsrc patch /home/sehnsucht/pkgsrc/patches/textproc/urlview/mypatch.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- urlview.c.orig     2020-04-15 11:07:04.906046429 +0200
|+++ urlview.c  2020-04-15 11:07:05.033935127 +0200
--------------------------
Patching file urlview.c using Plan A...
Hunk #1 succeeded at 408.
done

The package is then properly built and registered 😉

JuvenalUrbino probably.
I was refering to patches that "will be", or at least are "thought to be" commited at some point. Otherwise, they are simply useless.

They still might be of use to the owner of the system where they were created but, to anyone else they are simply useless.

Honestly, I don't see the point of LOCALPATCHES.
I'm sorry to disagree with you but, if you patch something, share it please!
Not only with the OS but also, with upstream. Otherwise, these patches are useless.

JuvenalUrbino

pin
A patch doesn't necessarily imply a bug fix or an improvement which everybody may benefit from. I mean, in many cases one may just want to run a custom patched version of some software (e.g. dwm comes to mind, as it's a common use case), apply some unofficial community change or even test new features (plugins , etc..) , committed to mainstream but maybe not yet merged to the main branch. Those things are not fit for the pkgsrc tree: they may not meet stability/quality requirements, and be regarded as unneeded by many users. The sidebar patch/plugin for mutt is a perfect example: it's not part of mutt's mainstream, but has been included in neomutt. As I do not need neomutt and can happily leave without its dependencies, but I do like the sidebar feature, I just stick to a local patch (keeping in mind I won't expect help support for this feature). I think that is what LOCALPATCHES is meant for.
FVWM has seen many community-contributed patches over its long history, and OP may just want to test some unofficial add-on nobody else is interested in, rather than fix a bug or improve the package's quality, reliability...
If that's not the case, then getting used to edit patches like they're meant to be committed to the upstream pkgsrc repo, is probably the best, most advisable and definitely most useful approach.

JuvenalUrbino 😃
If that's what the OP wants that's perfectly fine.
I won't go into this any deeper but, I still disagree regarding LOCALPATCHES.

nikita

To see the point in LOCALPATCHES: site specific adjustments by administrators who do deployments of pkgsrc. Furthermore, it is necessary for some software which expects configuration of the software as a patch (for example customizing x11/st-term). etc pp

nikita Thanks!

JuvenalUrbino

nikita truthfully, I had mentioned software requiring source editing for configuration (like dwm) as well as custom deployments, but it seems somehow I had failed in explaining myself the way you did. Sometimes less is better, and I spoke too much

Jay

when i run mkpatches for

wip/bamf

it comes up with empty patches dir 😅

This is patch ../work/bamf-0.5.4/configure.ac : https://launchpadlibrarian.net/477812192/bamf-0.5.4-fix-deprecated-g-type-class-add-private.patch

Jay you have to apply the patch to the source code yourself to be able to use mkpatches.

Jay

pin do all edits to patches must be done with pkgvi?

Jay No, minor changes are usually tolerated if you edit the unified diff directly and regenerate the patch sum. If you are talking about changing several lines, than yes, you'll need to use pkgvi from scratch.

Jay

pin I did using nano to several files under ../work/bamf-0.5.4/libs/

Jay you can define your editor and pkgvi will use that 😉
You don't need to use vi, I usevim.
nano makes me go mad, I never understood it and don't want to look at it ever again.
You can even use a GUI editor, just define it in your .profile

Jay

pin and still mkpatches didn't make any patch.. Is it because make still failed ?