LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-10-2018, 11:35 AM   #1
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 206

Rep: Reputation: 52
sbopkg installs "original" SlackBuild to /usr/doc/<pkg>/ instead of "local" SlackBuild


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
Code:
sbopkg -k -b intel-microcode
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?
 
Old 01-10-2018, 12:06 PM   #2
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 5,114

Rep: Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894
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.
 
Old 01-10-2018, 12:22 PM   #3
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 206

Original Poster
Rep: Reputation: 52
Ah, you're right. I should have check the website first. I'll move the discussion to github.
 
Old 01-11-2018, 06:57 PM   #4
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 3,821

Rep: Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094
Thanks for the patch
It has been merged in master and it will be included in the next release.
 
Old 01-12-2018, 09:57 AM   #5
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 525

Rep: Reputation: 132Reputation: 132
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

Last edited by bamunds; 01-12-2018 at 10:26 AM.
 
Old 01-12-2018, 10:24 AM   #6
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 206

Original Poster
Rep: Reputation: 52
Quote:
Originally Posted by bamunds View Post
Was this an issue for sbopkg or was it an issue for the specific slackbuild?
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.
Old 01-12-2018, 10:33 AM   #7
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 525

Rep: Reputation: 132Reputation: 132
Quote:
Originally Posted by drumz View Post
It was an issue with sbopkg,
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"?
 
Old 01-12-2018, 10:47 AM   #8
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 206

Original Poster
Rep: Reputation: 52
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:

Code:
cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
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.
Old 01-12-2018, 10:50 AM   #9
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 206

Original Poster
Rep: Reputation: 52
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.
Old 01-12-2018, 11:07 AM   #10
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 525

Rep: Reputation: 132Reputation: 132
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?
 
Old 01-12-2018, 11:29 AM   #11
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 206

Original Poster
Rep: Reputation: 52
Quote:
Originally Posted by bamunds View Post
1. So the patch is to fix a documentation placement issue, not a building issue?
Yes
Quote:
Originally Posted by bamunds View Post
2. How will it affect those packages which don't have the error in their doc cat line?
The doc cat line in the SlackBuild is not an error. If a SlackBuild doesn't have this line, the patch has no effect.
Quote:
Originally Posted by bamunds View Post
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?
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.

Quote:
Originally Posted by bamunds View Post
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?
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.
Old 01-12-2018, 01:57 PM   #12
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 525

Rep: Reputation: 132Reputation: 132
Quote:
Originally Posted by drumz View Post
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.
Agreed concrete occurrences are always easier to explain what happened, and how to fix.
Quote:
Originally Posted by drumz View Post
Then install (or explodepkg) the package and examine /usr/doc/$PRGNAME-$VERSION/$PRGNAM.SlackBuild. Your edits aren't there.
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.
 
Old 01-12-2018, 02:16 PM   #13
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 5,114

Rep: Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894Reputation: 2894
Quote:
Originally Posted by bamunds View Post
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.
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

Code:
if runModifiedSlackBuild = yes;
    mv $PRGNAM.SlackBuild $PRGNAM.SlackBuild.original
    cp $PRGNAM.SlackBuild.build $PRGNAM.SlackBuild

    sh $PRGNAM.SlackBuild
else
    sh $PRGNAM.SlackBuild
fi
 
Old 01-12-2018, 03:34 PM   #14
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 525

Rep: Reputation: 132Reputation: 132
Quote:
Originally Posted by bassmadrigal View Post
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.
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.
 
Old 01-12-2018, 04:03 PM   #15
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 984

Rep: Reputation: 708Reputation: 708Reputation: 708Reputation: 708Reputation: 708Reputation: 708Reputation: 708
Quote:
Originally Posted by bamunds View Post
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.
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:

Code:
# This is an added line.
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:

Code:
root@Thinkpad-T430:~# diff /usr/doc/CAFS_divergence-1.0/CAFS_divergence.SlackBuild /var/lib/sbopkg/SBo/14.2/academic/CAFS_divergence/CAFS_divergence.SlackBuild.sbopkg
24a25,26
> # This is an added line.
>

Last edited by montagdude; 01-12-2018 at 04:04 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
FireFox SlackBuild removes the "/usr/include" directory khronosschoty Slackware 4 12-13-2016 06:51 AM
[SOLVED] IPv6 "link-local" fe80:: vs "unique local address (ULA)" fc00:: + fd00:: psycroptic Linux - Networking 4 08-07-2014 12:51 AM
Ubuntu12.04 Libre office ".odt" & ".doc" file problem rishjain26 Ubuntu 1 05-08-2013 07:32 AM
Slackbuild enconters error with missing "ibus.csh" ShellyCat Slackware 3 01-11-2011 07:07 AM
Compromised? Files "/usr/lib.hwm", "/usr/lib.pwd", "/usr/lib.pwi" Klaus Pforte Linux - Security 4 09-28-2004 11:33 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:29 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration