[SOLVED] Need a little Slackbuilds training Re: maintaining patches

thethinker · 06-01-2020, 05:33 PM

I am working on learning how to maintain Slackbuilds packages, and I'm having trouble dealing with patches. I think I understand the basic functionality of diff and patch, but they don't seem to be behaving how I expect.

So sagemath just got updated from 9.0 to 9.1. So I download the current SB, get the new source, change the version number in the Slackbuilds, and when I run it I got an error, apparently a file that is getting patched got a name change.

The patch in question is this:

Code:

--- build/pkgs/pynac/spkg-install.orig	2014-08-11 20:52:14.220516400 +0700
+++ build/pkgs/pynac/spkg-install	2014-08-11 20:52:27.906551659 +0700
@@ -31,6 +31,7 @@
 
 build_pynac()
 {
+    chmod -R g-w ${PYNACDIR}
     cd ${PYNACDIR}
     PKG_CONFIG_PATH=${SAGE_LOCAL}/lib/pkgconfig; export PKG_CONFIG_PATH
     ./configure --disable-static --prefix=${SAGE_LOCAL} --libdir="$SAGE_LOCAL/l
ib"

But unzipping the source shows the name change:

Code:

$ ls build/pkgs/pynac/
SPKG.txt       dependencies         spkg-install.in
checksums.ini  package-version.txt  type

So here's my attempted fix. Add the change ("add the line chmod.....") to a new file spkg-install-new.in. Then get the diff:

Code:

diff -u build/pkgs/pynac/spkg-install.in build/pkgs/pynac/spkg-install-new.in > pynac.patch
$ more pynac.patch
--- build/pkgs/pynac/spkg-install.in	2020-05-20 18:33:41.000000000 -0400
+++ build/pkgs/pynac/spkg-install-new.in	2020-06-01 18:11:44.231568081 -0
400
@@ -9,6 +9,7 @@
 
 build_pynac()
 {
+    chmod -R g-w ${PYNACDIR}
     cd ${PYNACDIR}
     PKG_CONFIG_PATH=${SAGE_LOCAL}/lib/pkgconfig; export PKG_CONFIG_PATH
     sdh_configure --disable-static --with-giac=no PYTHON=sage-python23

Then take that new patch and replace the old patch in the SB. However, when I run the Slackbuild, I get

Code:

patching file build/pkgs/pynac/spkg-install.in
patching file configure
Reversed (or previously applied) patch detected!  Assume -R? [n]

But I didn't apply the patch to the tarred sourceball yet, so I don't really understand why the script thinks I have. Do I need to more literally follow the naming scheme used by the original author (rename to .orig before editing)? Or am I just totally borking how this is supposed to work?

BTW, the patch is being applied like

Code:

patch -p0 < $CWD/pynac.patch

in the SB script.

chrisretusn · 06-01-2020, 10:25 PM

Just a rhetorical question here. Did you attempt to run the SlackBuild without the patch?

bassmadrigal · 06-01-2020, 10:54 PM

As chrisretusn implied, it seems that the patch is no longer needed as it seems upstream has fixed the source directly.

When bumping SlackBuild versions, it's usually best to try comment out any patches as hopefully they were already accepted in upstream. If the build fails (or the resulting package is still broken), you may want to uncomment the patch and try again.

orbea · 06-02-2020, 09:06 AM

Since the patch doesn't cleanly apply and is a single line, take a look at the code and if its still needed reapply it manually and then regenerate the patch with diff(1).

Quote:

Originally Posted by bassmadrigal

When bumping SlackBuild versions, it's usually best to try comment out any patches as hopefully they were already accepted in upstream. If the build fails (or the resulting package is still broken), you may want to uncomment the patch and try again.

And if the patch fixes an issue more subtle than a build failure you may very well not notice how its broken right away.

bassmadrigal · 06-02-2020, 09:50 AM

Quote:

Originally Posted by orbea

And if the patch fixes an issue more subtle than a build failure you may very well not notice how its broken right away.

I suppose it is best to look into the patch on each version bump and see if it is still necessary. I tend to comment the reason for the patches I use in my SlackBuilds, so it will hopefully be easier to see if they're still needed with version bumps.

orbea · 06-02-2020, 10:17 AM

Yes, I agree with adding comments. I try to at least provide the reason as well as links to any relevant upstream issues, commits and pull requests.

thethinker · 06-03-2020, 08:39 AM

Quote:

Originally Posted by chrisretusn

Just a rhetorical question here. Did you attempt to run the SlackBuild without the patch?

It's not rhetorical - I tried to give the clear impression that I didn't know what I was doing!

Quote:

Originally Posted by bassmadrigal

When bumping SlackBuild versions, it's usually best to try comment out any patches as hopefully they were already accepted in upstream. If the build fails (or the resulting package is still broken), you may want to uncomment the patch and try again.

Indeed, I see why this is best practice, and it solved the problem. I guess I wasn't expecting upstream to care that much about our little corner of the community, but of course a) they might, and b) they might have fixed something unintentionally.

More to the point, c) maybe the patch does something I'm not aware of / can't test on my system, but if it can't build on my vanilla system, that point is moot.

Thanks all for the help - just trying to learn and contribute in whatever small way I can, rather then being a total mooch over here!

chrisretusn · 06-03-2020, 10:18 AM

Quote:

Originally Posted by thethinker

It's not rhetorical - I tried to give the clear impression that I didn't know what I was doing!

Oh... it was pretty clear.

I don't always assume though, I've been there too. In a lot of areas I still am there. Clueless. hehe

Quote:

Indeed, I see why this is best practice, and it solved the problem. I guess I wasn't expecting upstream to care that much about our little corner of the community, but of course a) they might, and b) they might have fixed something unintentionally.

Most of the patches are found from other distributions and even from upstream but have not been implemented. Some are created from scratch. As already mentioned, commenting on patches is a good thing. I always add a comment on why I needed the patch and the source were I got the patch. I do this also with "patches" to code or layout that are done within the SlackBuild for example using sed to make a few quick changes or moving files around. Always good to document why.

I normally run a rebuild of a program without doing anything to the patches unless I know ahead of time a patch has been cleared. ChangeLogs help in that regard. If the build succeeds then good to go. I the build fails, then I start looking at why and if a patch could be the reason. My SlackBuild's are all coded to produce log output so I can go back and review problems. Have fun in your adventures with Slackware.