# I need help with Poudriere EXTRA_PATCHES



## vmb (Jan 25, 2021)

I have been using Poudriere for a number of years with a patch method that applies patches directly to a custom ports tree. I would like to use the extra patches method that appears to be in Poudriere as I think it will make it easier for me to manage my own local customizations in git.

I am using a 'jail' hook to create a local patch directory for the jail and this appears to be working OK. However, the process that Poudriere 3.3.6 uses to actually apply my extra patches always fails. I used this guide for info on the hook required.


```
=======================<phase: patch          >============================
===>  Patching for nss-3.61
===>  Applying extra patch patches for nss-3.61 from /local-patches/nss
1 out of 1 hunks failed--saving rejects to Makefile.rej
===>  FAILED Applying extra patch patch-Makefile_disable-neon-on-armv6
===> FAILED to apply cleanly extra patch patch(es)  patch-Makefile_disable-neon-on-armv6
*** Error code 1

Stop.
make: stopped in /usr/ports/security/nss
=>> Cleaning up wrkdir
===>  Cleaning for nss-3.61
build of security/nss | nss-3.61 ended at Mon Jan 25 18:52:25 GMT 2021
build time: 00:00:41
!!! build failure encountered !!!
```
My make.conf does not mention the patch by name, it loads all patches that start with 'patch-' from the named directory. The log shows this is working as my directory for the patch being tested is /local-patches/nss and the patch file that Poudriere finds inside it is 'patch-Makefile_disable-neon-on-armv6'. However, it fails to patch the code when used by Poudriere.

If I apply the patch directly to my ports-tree outside of Poudriere it works fine.

My patch looks like this:

```
--- Makefile
+++ Makefile
@@ -69,6 +69,10 @@
.endif
.endif

+.if ${ARCH} == armv6
+MAKE_ENV+=      NSS_DISABLE_ARM32_NEON=1
+.endif
+
.if ${OPSYS} == FreeBSD && ${ARCH} == amd64
USE_BINUTILS=    # intel-gcm.s
CC+=    -B${LOCALBASE}/bin
```

If you are using extra patches with Poudriere can you see what I have done wrong?


----------



## vmb (Jan 26, 2021)

I created a new test patch file today that just increments the port revision number. I tested it manually outside of Poudriere and the patch works fine. I made a small tweak to attempt to patch a non-existent file. I changed the source specification from 'Makefile' to 'MakefileZ'. This is what I got in the log file...

```
=======================<phase: patch          >============================
===>  Patching for nss-3.61
===>  Applying extra patch patches for nss-3.61 from /local-patches/nss
No file to patch.  Skipping...
1 out of 1 hunks ignored--saving rejects to MakefileZ.rej
===>  FAILED Applying extra patch patch-test01
===> FAILED to apply cleanly extra patch patch(es)  patch-test01
*** Error code 1
```
Clearly the extra patches process in Poudriere is locating my patch file, reading it's contents and processing it as the log file acknowledges the non existence of MakefileZ.

After changing the patch target to a filename that should exist (Makefile). I get this...

```
=======================<phase: patch          >============================
===>  Patching for nss-3.61
===>  Applying extra patch patches for nss-3.61 from /local-patches/nss
1 out of 1 hunks failed--saving rejects to Makefile.rej
===>  FAILED Applying extra patch patch-test01
===> FAILED to apply cleanly extra patch patch(es)  patch-test01
*** Error code 1
```
I wonder if it is a umask or rights problem on the target file that is preventing patching? It doesn't matter what port I try patching with the extra patches method, I get the same failure.


----------



## acheron (Jan 26, 2021)

Make sure your patch is generated on the correct directory (WRKSRC)


----------



## SirDice (Jan 26, 2021)

Naming convention of the patch file is also important. A patch-Makefile_disable-neon-on-armv6 would refer to a file named Makefile/disable-neon-on-armv6. 

4.4.1. General Rules for Patching


----------



## vmb (Jan 26, 2021)

SirDice said:


> Naming convention of the patch file is also important. A patch-Makefile_disable-neon-on-armv6 would refer to a file named Makefile/disable-neon-on-armv6.
> 
> 4.4.1. General Rules for Patching


Thanks. The patches I need to apply are for local customisations or for testing published fixes for problems that pkg maintainers have not yet corrected. Do I really need to adhere to the Handbook conventions if these patches are never going to find their way to a pkg maintainer? 

I might have completely misunderstood extra patches. I was hoping that I could keep a clean, regularly updated production FreeBSD ports tree and apply my entirely separate local customisations in the jail at the point of running a Poudriere bulk build.


----------



## vmb (Jan 26, 2021)

acheron said:


> Make sure your patch is generated on the correct directory (WRKSRC)


Thanks. Where would the pkg maintainer's Makefile be in relation to $WRKSRC ? I want to patch the pkg Makefile not the Makefile for the application's source code.

Poudriere logs don't show that $WRKSRC is set for a build in a jail. I suppose I could write a Poudriere hook to run make -V WRKSRC to find the path. I have assumed, probably incorrectly, that WRKSRC is the same directory as the pkg Makefile.


----------



## SirDice (Jan 26, 2021)

vmb said:


> I want to patch the pkg Makefile not the Makefile for the application's source code.


Then you're modifying the port itself. That's not what the intended use for EXTRA_PATCHES is. If you need to modify the port(s) themselves the OVERLAYS function is probably better suited. This allows you to overlay a custom ports tree over an original, that way you don't have to import all the dependencies for your custom port(s).



vmb said:


> have assumed, probably incorrectly, that WRKSRC is the same directory as the pkg Makefile.


No, it's usually the extracted distfile directory in the work/ directory. Usually something like work/<portname>-<version>/ but can be something else. Unfortunately I can't refer to the Porter's Handbook at the moment, it seems to be giving me a 404 at the moment (They're probably busy moving things around due to svn->git migration).


----------



## acheron (Jan 26, 2021)

If there is a build problem with nss on armv6, please create a PR in our bugzilla and put me in CC (mikael@)


----------



## PMc (Jan 26, 2021)

vmb said:


> Thanks. The patches I need to apply are for local customisations or for testing published fixes for problems that pkg maintainers have not yet corrected. Do I really need to adhere to the Handbook conventions if these patches are never going to find their way to a pkg maintainer?


Well, I for my part came to the conclusion that I should do straight the opposite, in order to clearly differenciate between my local patches and those provided in the ports tree.
(not using poudriere, but my own solution with simialr features. But then, if you want to patch the /usr/ports/<category>/<port>/Makefile, you need a different approach anyway)


----------



## vmb (Jan 27, 2021)

PMc said:


> Well, I for my part came to the conclusion that I should do straight the opposite, in order to clearly differenciate between my local patches and those provided in the ports tree.
> (not using poudriere, but my own solution with simialr features. But then, if you want to patch the /usr/ports/<category>/<port>/Makefile, you need a different approach anyway)


I am working on my own Poudriere hook script for applying patches to the pkg/port Makefile. Most of my local patches just switch on i386 builds when the FreeBSD port maintainer has decided to no longer support 32-bit X86 but upstream still does.


----------

