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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

This is very interesting -- I was thinking about maybe making the msb packages (http://slackware.org.uk/msb/) compatible with slackpkg+ but I'm not sure what exactly needs to be changed. And it also looks like we have to separate copies of GPG.TXT, FILELIST.TXT and other metadata type files duplicated in each architecture's directory?

Edit: We already use Eric's gen_repo script but any suggestions on best practice for repo layout in regards to slackpkg+ would be appreciated. Thanks.

I had the same discussion with kikinovak for his MLED repository. Using my gen_repos_files.sh script you basically have two options:

Create separate ChangeLog.txt for each architecture (so, one goes into msb/14.0/x86/ and another goes into msb/14.0/x86 _64/) and you run the gen_repos_files.sh script twice - handle each repository separately. This is what kikinovak does with his MLED/MLES repositories.

Create a single ChangeLog.txt in the root of your repository tree (inside msb/) and then use the "REPO_SUBDIRS" variable inside the script to tell the script to generate separate FILELIST.TXT MANIFEST.TXT PACKAGES.TXT etc... files in each of those subdirectories, making them useable with slackpkg+ . In your case it would probably look like 'REPO_SUBDIRS="14.0/x86 14.0/x86_64"'. This is how I do it with my multilib repository.

Remember that you can put the configuration variables in a separate file instead of editing the script. Point the USERDEFS environment variable to that file when calling the script.

@zerouno, I modified our msb repo per the previous posts and things are showing up in slackpkg fine but I'm getting GPG errors when trying to install a package. And when I go into one of the subdirectories like http://slackware.org.uk/msb/14.0/x86_64/ and run 'md5sum -c CHECKSUMS.md5 | less' it also gives errors and says it can't find the packages listed but they are there. I'm missing something simple, I'm sure.

Just a small suggestion. Can AlienBob when he compiles packages for his Ktown repository modify his scripts so the packages would end something different than alien. maybe alienkde or alienktown. it would be mush easier to blacklist packages from ktown not to be upgraded using slackpkg+.

Just a small suggestion. Can AlienBob when he compiles packages for his Ktown repository modify his scripts so the packages would end something different than alien. maybe alienkde or alienktown. it would be mush easier to blacklist packages from ktown not to be upgraded using slackpkg+.

I think the ktown packages are outside the "alienbob" repository, so they should not be upgraded by slackpkg+
And it's a shame

These are the MD5 message digests for the files in this directory.
If you want to test your files, use 'md5sum' and compare the values to
the ones listed here.
To test all these files, use this command:
tail +13 CHECKSUMS.md5 | md5sum -c --quiet - | less
'md5sum' can be found in the GNU coreutils package on ftp.gnu.org in
/pub/gnu, or at any GNU mirror site.
MD5 message digest Filename
2da2c97473fd60413c84b99a003e661c ./ANNOUNCE.14_0

These are the MD5 message digests for the files in this directory.
If you want to test your files, use 'md5sum' and compare the values to
the ones listed here.
To test all these files, use this command:
tail +13 CHECKSUMS.md5 | md5sum -c --quiet - | less
'md5sum' can be found in the GNU coreutils package on ftp.gnu.org in
/pub/gnu, or at any GNU mirror site.
MD5 message digest Filename
2da2c97473fd60413c84b99a003e661c ./ANNOUNCE.14_0

I think the ktown packages are outside the "alienbob" repository, so they should not be upgraded by slackpkg+
And it's a shame

But slackpkg tries to upgrade Ktown packages with ones from the stock distribution. An if the you blacklist them not to be checked by slackpkg you also blacklist all Alienbob packages, because of blacklisting "[0-9]alien", so you need to blacklist each of Ktown packages by name.

But slackpkg tries to upgrade Ktown packages with ones from the stock distribution. An if the you blacklist them not to be checked by slackpkg you also blacklist all Alienbob packages, because of blacklisting "[0-9]alien", so you need to blacklist each of Ktown packages by name.

My point is: if the ktown is not part of the alienbob repository, it will not be managed by slackpkg+, so you will have to install them manually if you want them in your slackware.
Since you are already manually installing them, it would be of no consequence to you if you add "kde" to the slackpkg blacklist.
This way, slackpkg+ will not try to "upgrade" the ktown packages to the official slackware kde packages.