I upgraded intel-microcode today using sbopkg by creating intel-microcode.SlackBuild.sbopkg and intel-microcode.info.sbopkg in /var/lib/sbopkg/SBo/14.2/system/intel-microcode according to the pending commit for slackbuilds.org. I built the package using the command
and selected to use the Queuefile (which lists iucode_tool as a dependency). sbopkg then informed me that a local version of the .info file and the SlackBuild were available, and I chose to use the local version. It then downloaded the new 20180108 version and built the package as expected. However, when I looked at the SlackBuild that sbopkg copies into the documentation directory (/usr/doc/intel-microcode-20180108/intel-microcode.SlackBuild), it is the "original" version of the SlackBuild, rather than my "local" copy.

I've found that the reason is that the intel-microcode SlackBuild (along with probably every SlackBuild at slackbuilds.org) copies the file $PRGNAM.SlackBuild to /usr/doc, while sbopkg executes $PKGNAME.SlackBuild.build, where the "original" or "local" version of the SlackBuild is copied to $PKGNAME.SlackBuild.build so that the correct user choice is used.

I believe the solution should be for sbopkg to:

1. mv $PKGNAME.SlackBuild to $PKGNAME.SlackBuild.original
2. If $PKGNAME.SlackBuild.sbopkg is found, ask user if local version should be used. If so, copy $PKGNAME.SlackBuild.sbopkg to $PKGNAME.SlackBuild, else copy $PKGNAME.SlackBuild.original to $PKGNAME.SlackBuild.
3. Build package.
4. Unconditionally mv $PKGNAME.SlackBuild.original to $PKGNAME.SlackBuild.

I'll work on a patch to do just that. Any suggestions for a better way?

While I know willysr, the current maintainer of sbopkg, frequents these forums, a better place for the bug report might be the issue page on sbopkg's github.

Ah, you're right. I should have check the website first. I'll move the discussion to github.

Thanks for the patch
It has been merged in master and it will be included in the next release.

Was this an issue for sbopkg or was it an issue for the specific slackbuild?

I've used sbopkg for a couple of years without this experiencing this issue. The packages have always built the modified local copy I've created. For example if I see a newer version of claw-mail or quipzilla then using the built in sbopkg editor, I save the file, and respond to use "local copy" has always worked. I have not hand modified the package and stored it in the repository because then sbopkg would think it is the version from Slackbuilds.org or would overwrite with the SBo version if clicking on "Sync" first. Doing it your way I can't imagine how sbopkg could pick the local copy, because it didn't know a local copy was available.

Alternatively, if you want to build a slackpkg locally you can download from slackbuilds.org the files and the source to a personal download folder location, modifiy the Slackbuild and info fiels, then as root issue the sh ./{packagename}.SlackBuild and the package will be built with your modifications. I just did this for the intel-microcode and it packaged the 20180108 version correctly.

So @willysr did you find the patch needed for the intel-microcode SBo or was there some error in sbopkg? If the slackbuild I'll want to "note" in my Howto install Intel microcode thread to use latest intel-microcode.SlackBuild or users of sbopkg should now rebuild. Cheers

It was an issue with sbopkg, fixed by this commit. The only problem was that the wrong SlackBuild was copied to the /usr/doc directory in the package, which most people would never notice. It would not affect the functionality of the resulting package at all.

1 members found this post helpful.

As I've edited my statement since your response, please read my post again. I never had the bug you describe when "editing" the slackbuild from within sbopkg. I wonder if the commit is now going to cause a problem with the sbopkg "editor"?

sbopkg has always used the correct SlackBuild (local or original, depending on user choice) to build the package. The only issue of which SlackBuild (local or original) is copied to the /usr/doc/ directory. Look near the bottom of the SlackBuild and you see this line:

Note the name of the file that is copied to /usr/doc: $PRGNAM.SlackBuild. Originally, sbopkg would create $PRGNAM.SlackBuild.build (copying from either the "original" version or "local" version that the user created) and execute $PRGNAME.SlackBuild.build. So, the correct SlackBuild would be used to build the package. However, within the SlackBuild itself $PRGNAME.SlackBuild was copied to the documentation directory, which when using sbopkg was always the "original" SlackBuild. My patch simply copies $PRGNAM.SlackBuild.build to $PRGNAM.SlackBuild so that the "proper" SlackBuild is copied to /usr/doc/. The patch does not alter the logic of selecting which SlackBuild (original or local) to execute.

1 members found this post helpful.

To put it another way: the SlackBuilds on slackbuids.org assume the name of the SlackBuild is $PRGNAM.SlackBuild. The only place this actually matters is the line within the SlackBuild that copies the SlackBuild to /usr/doc/. sbopkg broke this assumption by actually executing $PRGNAM.SlackBuild.build. Thus, under some cases the wrong SlackBuild was copied to /usr/doc/.

1 members found this post helpful.

1. So the patch is to fix a documentation placement issue, not a building issue?
2. How will it affect those packages which don't have the error in their doc cat line?
3. /usr/doc is suppose to be the destination for documentation, not a copy of the slackbuild file that was executed, so why isn't the sbopkg log tracking the slackbuild that was actually built?

Since SBo already is showing that latest intel-microcode release I don't feel a need to even note this bug in the other thread.
I still contend that I never ran across this issue when using the internal editor and wonder if the issue is that you modified the slackbuild outside of the sbopkg build environment?

Yes
The doc cat line in the SlackBuild is not an error. If a SlackBuild doesn't have this line, the patch has no effect.
SlackBuilds copy themselves to /usr/doc to make themselves self-documenting. You can examine /usr/doc for any package from slackbuilds.org and learn how the package was built.

There is nothing specific to intel-microcode and no need to note this issue there. I was just giving an example of how I found the issue. Concrete examples are often easier to understand than vague catch-alls. Most people would never notice this because most people never examine /usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild. Using sbopkg 0.38.1, create a package, but first edit the SlackBuild by adding some comments to it. When sbopkg asks, choose to use the Local version. Then install (or explodepkg) the package and examine /usr/doc/$PRGNAME-$VERSION/$PRGNAM.SlackBuild. Your edits aren't there. That's it. Nothing more. Probably over 95% of people will never notice, and it in no way affects the functionality of the package.

1 members found this post helpful.

Agreed concrete occurrences are always easier to explain what happened, and how to fix.
Since I downloaded the intel-microcode 20171117 slackbuild files and source, then modified slackbuild and info for 20180108 source, then ran sh ./intel-microcode.SlackBuild and do see the modifications made /usr/doc/intel-microcode it seems inconclusive that the slackbuild was at fault. I did not run the slackbuild from sbopkg, so I wonder if this is a sbopkg issue, for a unique situation as described where if the slackbuild is modified outside of sbopkg but sbopkg is then used to attempt the build and install that the error occurs. I'll have to give another SBo package a try before upgrade sbopkg to the latest commit. Thank you for the explanantion. Maybe this corner case is resolved at least. Cheers.

This is the difference. sbopkg saves different files and will run the modified file (with a slightly different name), but then will copy the original file over. This change has sbopkg mv the modified file to be the normal SlackBuild name, then the script will copy the correct one.

Think of this example:

You use sbopkg to modify the intel-microcode.SlackBuild file. sbopkg will save the modified file as intel-microcode.SlackBuild.build and will run that. But, the SlackBuild is hardcoded to move intel-microcode.SlackBuild, so it moves the original. The patch provided changes sbopkg behavior and when you're running a custom SlackBuild, it will rename the original SlackBuild to intel-microcode.SlackBuild.orginal and then it will rename the modified SlackBuild to the normal name. This means when the SlackBuild runs, it will copy over the file that is used to create the package.

Here's some psuedocode that might make it a bit more clear

Thanks again for the explanation. I understand what is being proposed, I'm simply not convinced the commit is actually correcting the "bug" described. Here are the reasons:
1) I've never had this issue with either hand modifying and executing a slackbuild (and specifically didn't happen with the intel-microcode 20171117 modified to 20180108) or modifying the slackbuild within the sbopkg "Edit Slackbuild" or "Edit Info" functions.
2) Examined the sbopkg code and I don't see any function to "cat" anything to /usr/doc, the slackbuild package does that function. Which is why a hand processed slackbuild will leave the correct files in /usr/doc just as using sbopkg does.
3) sbopkg already recognizes that it has an original file and with original or modified it creates a package name to build using the .build extension. Then in both the process_package and build_package steps it will remove the .build in cleanup statements. This commit will eliminate that extension and cause a new issue, no cleanup in the process_package process of sbopkg.

My concern is that this modification will cause new issues for a corner case that probably should not have been done in the first place. The commit is eliminating the .build package name in the build_package process but the process_package (which calls the build_package subprocess) won't have the proper name to cleanup and so won't rm the file in the process_package step. So I don't see that the issue is in sbopkg. But if the sbopkg package maintainer believes this will resolve this issue then I leave it to people who are programmers to resolve. I'm not a programmer and can only share my experience using the tool and understanding of the code as seen in sbopkg-0.38.1 in /usr/sbin of my Slackware64 14.2.

If I've put foot in mouth because of ignorance for reading code, I accept that I look foolish now. But that's how we learn....:-) Cheers.

Have you ever checked? To test, I just tried installing CAFS_divergence with sbopkg-0.38.1. Before installing, I added this line to the SlackBuild:

Then I chose to install the local version, but the original SlackBuild was installed in /usr/doc/CAFS_divergence-1.0. As you can see, it does not include my modification: