Mar 302013
 

Development has slowed on sbotools once again, which probably makes since given the size of the change-set for 1.5; this release is strictly a bug-fix release. Here are the highlights:

  • A bug where sbotools unsafely assumed the existence of /tmp/SBo has been fixed (this looked like “readdir() attempted on invalid dirhandle $tsbo_dh” with some other details afterward).
  • Support for $TMP being set in the environment has finally been implemented. SlackBuild files make use of this info, or fall back to /tmp/SBo; previously, we would not honour user changes to $TMP so all scripts used /tmp/SBo, which may not be what the user expects.
  • A bug where trying to install something which doesn’t exist threw a meaningless error has been fixed (this looked like “Odd number of elements in hash assignment” with some other details afterward).
  • A bug in the requirement checking code which could match something which was not a perl module against something installed via the cpan has been fixed.
  • A bug which would, in certain conditions, cause the queue to be generated out-of-order, which could cause builds to fail to sboinstall trying to build something before its requirement has been built, has been fixed. Thanks to W. Li for reporting this.

An updated slackbuild has been submitted to slackbuilds.org; you can either wait for it to be accepted there then use sboupgrade to update to 1.6 (if you have 1.5 installed), or you can download the slackbuild from there and modify it for 1.6 and use it to update manually.

The local-modification changes are still planned, just with one thing and another, they have not yet been gotten to, but unless we find some more stupid bugs first, that will be the next thing worked on. In theory…

sbotools on dawnrazor.net
sbotools on SlackBuilds.org

Feb 142013
 

This release took a little longer as we finally felt that sbotools was in a sufficiently stable state as to be submitted to SlackBuilds.org. So, that’s the most obvious change, and it also means that, moving forward, sbotools will be able to upgrade itself. For this release, if you have a previous version installed, you will not be able to upgrade it using sboupgrade, since the tag for previous versions was _d4wnr4z0r instead of _SBo, meaning sbotools will not see an older version as an upgradable SBo; simply remove the old package and then install the new one. Beyond that, here’s a summary of the other changes in this version:

  • Proper varying exit statuses have been implemented to indicate the cause of the exit. Read the man page for a given command to determine its possible exit codes; if there are none documented, that command can only exit 0. If there are multiple errors, the exit code will be based on the last one encountered prior to exiting.
  • Several minor fixes in the way that sboupgrade and sboinstall operate.
  • If sboupgrade or sboinstall encounter an error, instead of simply stopping, they will ask if one would like to continue on. In some cases, errors encountered are not sufficient to stop other things from working, so this allows one to have the scripts continue on in order to do as much as can be done.
  • A bug where certain special characters in download links broke the downloading of those source files has been fixed.
  • A bug where an invalidly formatted file in /var/log/packages would cause sboinstall and sboupgrade to die has been fixed.
  • Previously sboupgrade and sboinstall, when set to “make clean”, as well as sboclean, had no knowledge of -compat32 stuff still lying around under /tmp; those items are now properly cleaned.
  • A bug where sbocheck would die if there were no updates, instead of exiting cleanly, has been fixed.
  • Several non-optimal sections of code have been optimized.

Moving forward, our next big thing is to implement a method of handling local modifications. We also have a couple bug reports to look into, and we’ll also be getting a wiki and some other fun things setup at some point.

sbotools on dawnrazor.net
sbotools on SlackBuilds.org

Jan 062013
 

sbotools 1.4 is now released, yes, less than a week after 1.3, but we have a lot of small fixes and enhancements in this release. Not all are user-visible, but here are the ones that are:

  • When checking for installed requirements, sbotools is now aware of non-SBo packages. This means you can, for example, install jdk from /extra, and sbotools will see that as fulfilling an SBo’s requirement to have jdk already installed.
  • When checking for installed requirements, sbotools is aware of CPAN-installed Perl modules. Note that not all CPAN-installed Perl modules register themselves in the system’s perllocal.pod, so sbotools won’t know about them, and in some cases SlackBuilds of Perl modules rename the module in bizarre ways, and sbotools won’t know about such renamings.
  • A bug where attempting to build a compat32 package from something which had differing 32-bit and 64-bit download links would fail due to the slackbuild attempting to use the 64-bit source packages has been fixed.
  • The requirement to have Text::Tabulate installed for sbotools is no more.
  • sbocheck now writes a log, located at /var/log/sbocheck.log, of what updates it finds as available.
  • A bug where sbotools was no longer aware of installed compat32 packages from SlackBuilds.org, due to a modification in how these packages get tagged, has been fixed.
  • A bug where sbotools could not always “make clean” the source directories, or would do an incomplete job of it, has been fixed.
  • sbotools will now attempt to download and md5sum verify all source files for all packages queued before attempting to build any of them.
  • A bug where if a source fail already existed but failed md5sum verification sbotools would not remove it before wget’ing a new copy, resulting in the new copy having .1 appended and the md5sum verification still failing, has been fixed.

As I mentioned last release, we’re a lot more organized now, and it has helped a lot.

Moving forward, we’re looking at the different ways we can go about supporting local modifications to the tree, implementing a wiki, doing some refactoring/rewriting/cleanups, and (probably the very next thing we’ll do) implementing a new testing method which we figure ought to expose a number of interesting bugs that we don’t even know about yet.

Exciting!

Dec 312012
 

sbotools 1.3 is here, and includes a new tool called “sboremove”; sboremove utilizes requirement information in the slackbuilds.org tree to provide the ability to easily remove an SBo along with all of its requirements. It is also aware of other installed SBos and their requirements and, by default, will not offer to remove any of a specified SBo’s requirements if another installed SBo shares any such requirements – though there is, of course, an option to have it do so.
Beyond that, there are a couple cosmetic bug fixes, as well as a fix for a bug which caused SBos specified to sboinstall which were also requirements of other specified SBos at the same time to show up multiple times in the install queue.

Moving forward, we’re starting to get a lot more organized now, which should positively impact not only the quality of sbotools but also the speed at which we can effect positive, beneficial changes to the codebase.

enjoy!

Nov 032012
 

This took longer than it should have as I got very sidetracked with another project.

Anyhow, the release includes the following changes:

  • The devs package is now ignored by default; it generates thousands of thousands of lines of verification failures, when typically udev is being used to manage /dev and so the failures aren’t even applicable. The -d option has been added to not ignore it.
  • .new files are now ignored by default for unofficial packages – a bug in the last version caused them to never be ignored for unofficial packages.
  • Issues found for unofficial packages weren’t properly counting before, causing pkg_verify to claim there were no issues after claiming there were issues.
  • Symlink issues found for packages weren’t properly counting before for either unofficial or official packages.
  • A lot of stuff that doesn’t have to be done if not verifying official packages no longer is in those cases.
  • osuosl is now the default mirror – the one which pkg_verify will use to pull official file lists if it can’t pull a selected one from /etc/slackpkg/mirrors. This may fix problems where pkg_verify advises the user to run updates because it doesn’t see a patch in the file lists it’s using.
  • Man page wording regarding -n option has been corrected.

Thanks go to Roberto for bringing a few of these problems to my attention.

pkg_verify

Oct 122012
 

pkg_verify 0.2 brings support for 14.0, support for verifying unofficial packages, and possibly a bug fix or three that I didn’t really keep track of. Thanks go to Roberto who emailed me letting me know of problems utilizing pkg_verify on 14.0, and who also convinced me to add support for verifying unofficial packages.

pkg_verify

Jul 052012
 

Well, this is fairly overdue, considering that Pat bumped the slackware-version in -current to 14.0 a week and a half ago. Possibly the only noticeable difference in this release is that it now supports -current again, whereas 0.6 expects -current’s slackware-version to be 13.37.0.  In the meantime, there have many changes to the code itself. A lot of stuff has been cleaned up and refactored, a number of things have been made more robust, and some few hundred lines of code were removed. The code no longer handles temp files itself but uses File::Temp, which is better in virtually every way. A lot of little bugs were fixed along the way… but I didn’t keep track of which were pre-existing conditions and which were created along the way, so I can’t say those are bug fixes to the previous version as such.

And somewhere along the line I got into the idea of test-driven development, so that should, theoretically, mean the code is in better shape by definition… theoretically.

At any rate, click click.

Jun 072012
 

pkg_verify 0.1 is released. This is a tool to verify installed official Slackware packages. I’ve thought of writing something to parse the MANIFESTs and do the comparisons for a long time, but I am only just now actually doing it. It’s the sort of tool one doesn’t need very often, but when one does, it can be highly useful indeed.

Take a look at the pkg_verify page for the requisite info.

Jun 012012
 

sbotools 0.6 is now released. I am now considering sbotools to be essentially feature-complete. Here are some of the changes with this release:

  • Numerous enhancements have been made to the requirement-parsing code to work around some of the many variations in the way requirements are specified in README files.
  • sbofind has two new options: -i and -r, which show the contents of .info files and the contents of README files, respectively.
  • sboclean now exists as a simple means of cleaning distfiles and working directories.
  • Much cleanup and refactoring of code.
  • sboupgrade and sboinstall now grok  groupadd and useradd commands listed in README files, and offer to run those commands first.
  • sbofind’s search has been made case-insensitive.
  • sboupgrade and sboinstall now grok when a slackbuild has options documented in the README (of the form KEY=value); when they see this, they offer the option to set any options for the slackbuild.
  • The “Proceed with” question displayed after a README now reflects -compat32 when the -p flag is specified to sboupgrade or sboinstall.
  • Installation of a compat32 package now requires the non-compat32 version to be installed; when it is not, sboupgrade and sboinstall will offer to install it.
  • A bug which caused the -c option sboupgrade and sboinstall to not disabling cleaning of the working directories has been fixed.
  • Several other minor glitches have been fixed, wording has been cleaned up, man pages have been reorganized, etc.

Check out the sobtools page, and please report any problems found.

May 282012
 

sbotools 0.5 is now released. 0.5 brings the following changes:

  • Requirement-parsing has been added to sboupgrade(1); when sboinstall(1) or sboupgrade(1)  are run WITHOUT the -r flag, the tool will look for a list of requirements in a given slackbuild’s README. For any found, it will check to see whether or not they are already installed, and if not, go through the list, asking whether or not the user wishes to install them. This is recursive, so that order is handled correctly. This is not foolproof, however, which is why requirement parsing does not happen when the README prompt is bypassed; you are expected to read and ensure the parsing functioned correctly. If you find a case where it did not, please let me know.
  • A bug which caused temp files to not be deleted has been fixed.
  • The bug from the previous post, where attempting to install a -compat32 package resulted in a 32-bit but not actually -compat32 package being installed (given -i was not specified), has been fixed.
  • Comments have been added to the code for the sake of anyone wishing to assist or whatnot.

Given no serious bugs are found in this release, in the immediate future I will be focusing on some cleanup and refactoring that needs to happen, so the next release will likely take a little longer. This is necessary, however, to ensure the future of sbotools.

See the sbotools page for more information.