SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I wanted to wait a few days to post this here (and most folks here probably already know this) but sbopkg version 0.30.1 has been released (which is a bugfix release to the sbopkg 0.30.0 release for Slackware 13.0). The 0.30.x branch of sbopkg has many substantial changes from prior versions, and is intended to work seamlessly with Slackware 13.0 32 and 64 bit and the SlackBuilds.org repository for Slackware 13.0.
Check out the sbopkg ChangeLog for information about what's new. You can also read about the "new and improved" sbopkg queuefiles here.
For those migrating from 0.27.4 and older, it is recommended that you uninstall the old version of sbopkg and then install the new one, instead of upgrading.
Check out http://www.sbopkg.org for a package or source tarball for version 0.30.1. If you encounter any issues, please post to the sbopkg mailing list instead of posting here. Please file bug reports at the sbopkg Issue tracker.
Thanks to everybody to helped with testing, feedback, and providing bug reports. Those kinds of things are extremely helpful and we really appreciate it. We want sbopkg to be as good as possible, and your feedback is very important.
Thanks!
P.S. Many people have asked how to set $ARCH if they are using sbopkg on Slackware64. The answer is: you don't necessarily need to do anything. Sbopkg checks the output of 'uname -m' and if it returns 'x86_64' then it will build a 64 bit package (assuming the SlackBuild script supports a 64 bit package, of course).
I wanted to wait a few days to post this here (and most folks here probably already know this) but sbopkg version 0.30.1 has been released (which is a bugfix release to the sbopkg 0.30.0 release for Slackware 13.0). The 0.30.x branch of sbopkg has many substantial changes from prior versions, and is intended to work seamlessly with Slackware 13.0 32 and 64 bit and the SlackBuilds.org repository for Slackware 13.0.
Is this only for 13.0? Because I don't know when I will have a chance to upgrade my laptop and it is still running 12.1. Or is there even any need to upgrade (does this release only benefit 13.0 users)? I am running 0.27.4.
Is this only for 13.0? Because I don't know when I will have a chance to upgrade my laptop and it is still running 12.1. Or is there even any need to upgrade (does this release only benefit 13.0 users)? I am running 0.27.4.
Yes, most of the updates are not necessarily 13.0 or 64 bit related. The security enhancements, I think, alone are worth the upgrade. The entire codebase has been cleaned up and improved, and there are several new features and enhancements that would be of some benefit. Check out the ChangeLog I linked to above (see the long list of new things in version 0.30.0).
Sbopkg checks the output of 'uname -m' and if it returns 'x86_64' then it will build a 64 bit package (assuming the SlackBuild script supports a 64 bit package, of course).
What happens if the slackbuild is 32-bit only, is there a change in the naming, e.g. i486 as opposed to x86_64. What I am trying to say is, how do we know how sbopkg has compiled the program, is it 32-bit or is it 64-bit?
Yes, the naming will be different. If uname -m does not return x86_64, then sbopkg falls back to the default situation, which means ARCH will be whatever is in the SlackBuild, or whatever the user has set ARCH to in his environment.
So, the package will have 'i486' in the name in most cases on 32 bit.
If uname -m does not return x86_64, then sbopkg falls back to the default situation
Sorry Chess, I didn't make myself totally clear. What I meant was, if uname -m returns x86_64, but the slackbuild can only be built, or only has instructions for, 32-bit, does the built package have x86_64 or i486?
To be more precise, if 'uname -m' is not i.86, then ARCH is set to 'uname -m'. Thus, ARCH will be set to x86_64 on 64 bit systems. One can look to the SlackBuild and determine what the resulting package (and its name) will be if ARCH is set to x86_64. If one wants something else, they can always override it with 'export ARCH=i686 && sbopkg -b foo' for example.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.