SlackWiki - User contributions [en]

LCD Monitor Configuration In X.Org

2009-05-28T20:36:03Z

Dugan: Migrated from old wiki

[[Category:Tutorials]]
==DISCLAIMER==

If there is nothing wrong with your display, please don't go mucking about with your ~/.fonts.conf file (at least, back it up first). If you do have problems with your LCD display, then this is a good bet to try. If you have any success or failure, please do report this back, and changes, if any, that you made to your .fonts.conf file and any other file (perhaps /etc/X11/xorg.conf?) Comments, corrections and thoughts are always welcome.

This may well also work with XFree86 > 4.3, since they use the same font configuration files as this. Older versions have a non-XML font configuration setup (I don't know when the switch over was made though), and will not be covered.

WARNING - Parts of this article are out of date, and there are a few changes required for modular X. These will be added soon.

==Introduction==

LCD/TFTs display fonts very differently to a CRT. Unfortunately with Slackware's default settings on X.Org/FreeType, the results for fonts on an LCD are painful to say the least. This is further compounded by the fact that all the 'helpful' HOWTOs out there are badly out of date, referring to ancient versions of the now defunct XFree86. Whilst there are a few sites out there with bits of information, putting into a workable solution is quite a challenge.

This exists, therefore, to show the naysayers that they're wrong, and that you _can_ enjoy nice looking fonts in Slackware.

(Please note, this is _not_ an exhaustive HOWTO, and it is _not_ a HOWTO about .fonts.conf (please see the Bibliography for a site detailing the tags available in .fonts.conf). This HOWTO is only about configuring an LCD monitor and what works best for one)

==What You'll Need==

*Your favourite text editor
*X.Org (or a later edition of XFree86 >4.3. This has only been tested on Slackware 10.1 and above).
*An LCD/TFT monitor (most of this may also apply to an LCD monitor on a laptop).

==Physical Setup==

===The Monitor===

(I humbly apologise in advance for this section, but better safe than sorry.)

(Standalone Monitors only) Plug up your LCD. Where possible, use the DVI-D (i.e. The digital, not analogue VGA) connector, if both your monitor and your graphics card have one. If not, use an analogue VGA cable and connection (where possible, avoid using DVI-D to VGA adaptors.) Then, ensure the viewing angle of your LCD is correct. Play around with it until you are happy.

==Settings==

===X===

As far as I know, there is no special configuration of X needed for an LCD monitor. Just create the necessary entry for a monitor in /etc/X11/xorg.conf with the correct refresh rates as normal and enjoy (the monitor itself may even be able to give you these, mine does.) I won't cover this in any more detail, as it's pretty standard and covered better elsewhere.

X will also detect the correct sub-pixel alignment, so you don't need to deal with that either.

===Fonts and FreeType===

The real problems begins with font rendering in X. If you are switching over on your machine from a CRT to an LCD, what is facing you at first sight will be unpleasant to say the least.

Of course, this isn't down to X, as in all modern X servers from X.Org (and the later ones from XFree86) FreeType is responsible for all font rendering (any other modules loaded in your /etc/X11/xorg.conf for font rendering are anachronisms: they are no longer used, and X tells you they don't exist). Something I've seen a lot is that “fonts looked better on 9.0” or earlier versions of Slackware, and there is good reason for this. With the changeover to FreeType2, due to various Apple patents in the US and Japan, the 'bytecode interpreter' is now disabled by default. (Plus, IMHO, the Bitstream fonts that ship with Slackware aren't very good). With a CRT, this isn't much of a problem, but it does make a lot of difference on an LCD and is nearly illegible.

There are two ways round this, either:

#Make alterations to .fonts.conf to try and make the Bitstream fonts render better on an LCD.
#Rebuild FreeType with the bytecode interpreter, and use the properly hinted MS fonts (Arial, et al) to get cleaner, crisper looking fonts on the LCD.

Both of these solutions give different results (though I prefer the second).

====Common====

For both alternatives, there are some common settings that must be made.

If you're using KDE or GNOME, you'll find they have tools for doing some of what I'm going to describe. However, I would recommend _against_ using them. I've found their attempts at generating and editing a .fonts.conf file to be dubious to say the least. It is much more preferable to edit the file yourself, and since it is now done through a well defined XML file, this isn't as bad as it once appeared to be (judging from some of those ancient HOWTOs).

Crank up your editor and load ~/.fonts.conf (or /etc/fonts/local.conf)

If it exists: Just add these sections to it, inside the <fontconfig></fontconfig> tags.
If it doesn't exist: Use my ~/.fonts.conf skeleton from Appendix A as your .fonts.conf and edit as necessary.

1. Ensure that the sub pixel order is _not_ specified.

X knows the sub pixel order already, and if this is enabled as well, FreeType produces some very strange results. However, if you do still have problems, consider replacing 'none' with 'rgb' (the standard for LCD monitors), 'bgr' (unusual), 'vrgb' (vertical rgb, if you have a monitor that has been rotated by 90 degrees[1]), 'vgbr' (as vrgb, but very rare).

<match target="font" >
<edit mode="assign" name="rgba" >
<const>none</const>
</edit>
</match>

2. Enable sub-pixel hinting

This is what really starts to make the difference. Visit http://grc.com/ctwhat.htm for the technical explanation of why we're doing all of this.

<match target="font" >
<edit mode="assign" name="hinting" >
<bool>true</bool>
</edit>
</match>

3. Set the hinting amount

Usually, this should be full. Valid options are 'none', 'hintslight', 'hintmedium' and 'hintfull' which should be fairly self explanatory if you've read the article at the link above.

<match target="font" >
<edit mode="assign" name="hintstyle" >
<const>hintfull</const>
</edit>
</match>

====Option 1) The 'Easy' Way====

Essentially, we're going to enable FreeType's non-patented autohinter and antialiasing to improve the appeareance of the default Bitstream fonts.

Add the following to ~/.fonts.conf.

#Enable anti aliasing

This makes the fonts start to look nice, but some of the shapes will be distorted, so we need the FreeType autohinter (see next part).

<match target="font" >
<edit mode="assign" name="antialias" >
<bool>true</bool>
</edit>
</match>

Fluxbox only:

You may need to enable anti alias separately on Fluxbox before it takes notice of the changes:

fluxbox menu --> Configure --> AntiAlias

#Enable the FreeType autohinter

The autohinter is not turned on automatically, so we have to do this manually.

Please note that OpenOffice.org binaries from the OOo website are built against the bytecode interpreter, so even if you have compiled FreeType with the bytecode interpreter and override it with the autohinter, OOo will still use the bytecode interpreter.

<match target="pattern" >
<edit mode="assign" name="autohint" >
<bool>true</bool>
</edit>
</match>

====Option 2) The 'Hard' Way====

This is my ([[User:Cathectic]]) preferred solution, as I believe it gives better results. This involves rebuilding FreeType with the bytecode interpreter enabled, and then using the properly hinted fonts 'Core Fonts For the Web' from Microsoft.

For this, you will need to:

#Get a copy of FreeType that has the bytecode interpreter enabled.
##Download the Freetype sources from your local Slackware mirror (slackware-$VERSION/source/l/freetype)
##In freetype.SlackBuild, uncomment the line to apply the bytecode enabling patch
##Run the SlackBuild
##Replace your old freetype package with the new one you've just built.

'''32bit X Applications (Slamd64 only)''': To enable 32bit applications in Slamd64 to use the bytecode interpreter, you need to install a 32bit bytecode enabled FreeType.

#Download and install the 'Microsoft Core Fonts for the Web' (if you have a Windows installation, you could import the fonts from that instead. This tutorial assumes you do not) from either:
##LinuxPackages (install CabExtract, then CoreFonts)
##Or, From the 'Core Fonts for the Web' at http://prdownloads.sourceforge.net/corefonts/
###Get all the *.exe files
###Get the CabExtract source RPM, rpm2tgz it, untar, build and install
###Use CabExtract to extract the *.ttf's from the *.exe's you downloaded, and then move the fonts to /usr/X11/lib/X11/fonts/TTF (/usr/share/fonts/TTF for X.Org 7 or newer).

Now add the following to ~/.fonts.conf

1. Disable the autohinter

This isn't strictly necessary – the autohinter is not enabled by default, and if it's not enabled, the bytecode interpreter is used by default. However, it's better safe than sorry.


<match target="pattern" >
<edit mode="assign" name="autohint" >
<bool>false</bool>
</edit>
</match>

2. Set the MS fonts as defaults


<match target="pattern" name="family" >
<test name="family" qual="any" >
<string>sans-serif</string>
</test>
<edit mode="assign" name="family" >
<string>Arial</string>
</edit>
</match>


<match target="pattern" name="family" >
<test name="family" qual="any" >
<string>monospace</string>
</test>
<edit mode="assign" name="family" >
<string>Courier New</string>
</edit>
</match>


<match target="pattern" name="family" >
<test name="family" qual="any" >
<string>serif</string>
</test>
<edit mode="assign" name="family" >
<string>Times New Roman</string>
</edit>
</match>

(I would also recommend using the template in Appendix B to replace all the Bitstream and Luxi fonts with the MS equivalents (or set them to use serif, sans-serif, monospace instead)).

====Testing====

Just load any application up (I'd recommend a Gtk one, KDE will probably need a restart for the changes to take affect everywhere), and the changes should be immediately obvious (I used Mozilla Firefox, by opening and closing it after every tweak of ~/.fonts.conf, I was able to see the changes immediately).

====Apply System Wide====

You can apply these changes system wide, using /etc/fonts/local.conf

If it exists, just append the sections you added above to it.
If it doesn't, use your .fonts.conf as /etc/fonts/local.conf, and edit it as necessary

(The order of precedence for processing is /etc/fonts/fonts.conf (automatically generated, don't edit it), /etc/fonts/local.conf then ~/.fonts.conf - meaning your ~/.fonts.conf will always override the system settings).

===Application Specific Settings===

Qt and Gtk settings need to be changed.

====Gtk====

For gtk, edit .gtkrc-2.0 and set the fonts either to the generic 'serif', 'sans-serif', etc (now aliased to the MS fonts), or specify the MS fonts outright.

====Qt====
For qt, edit .kde/kderc and .qt/qtrc

==Suggestions==

===Non TrueType fonts===

Non TrueType fonts don't render well on LCDs as they don't support hinting. For these fonts (e.g. Helvetica), it is recommended that you specify an alternative TrueType font (that is hopefully similar, but it doesn't have to be!) to use instead (in this case, whatever the default sans-serif font on the system is):

<match target="pattern" name="family" >
<test name="family" qual="any" >
<string>Helvetica</string>
</test>
<edit mode="assign" name="family" >
<string>sans-serif</string>
</edit>
</match>

You can easily reuse this for other fonts. Just copy and paste, then replace 'Helvetica' with the font to replace, and 'sans-serif' with the font you want to replace it with (or you can use the generic descriptions 'serif', 'sans-serif' or 'monospace').

===Old Gtk/Qt===

Some programs (usually older ones) using these libraries may not always use anti aliased fonts, even if you've specified them in .fonts.conf. This can fixed by:

Gtk: Add the following to /etc/profile:
export GDK_USE_XFT='1'

qt: In ~/.qt/qtrc, ensure the following entry is present under [General]:
enableXft=true
useXft=true

Programs coded using Gtk 1.x don't appear to support anti aliasing properly – you may want to consider replacing them with ones that use Gtk 2.x (e.g. Replacing XMMS with its Gtk2 fork, Beep Media Player)

===OpenOffice.org===

OpenOffice.org binaries are built against the bytecode interpreter. If you install a bytecode enabled FreeType, OOo will always use it, regardless of any system settings enabling the autohinter. Also, OpenOffice.org fonts have to be changed manually.

Tools > Options > OpenOffice.org > 'Use system font for user interface' (make sure this is checked).

==Appendix A==

The following is a ~/.fonts.conf / /etc/fonts/local.conf skeleton. Use this to put together a working configuration for your system.

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>



</fontconfig>

==Appendix B==

This section is a recommendation only. Some fonts are not TrueType, which means they don't support anti aliasing and look dreadful on an LCD. The way round this is to tell FreeType to replace any such fonts with a properly hinted TrueType equivalent. All of the Bitstream and Luxi fonts should be aliased in this way (some sites, such as Gnome's home page, use these fonts, and they don't render correctly with the bytecode interpreter).

You can copy, paste and edit the following example for Helvetica for any other fonts you want to replace. (Just replace 'Helvetica' with the font to replace, and 'sans-serif' with the font you want it to be replaced with. Generic font descriptions serif, sans-serif and monospace are valid entries, as well as specific font names.)


<match target="pattern" name="family" >
<test name="family" qual="any" >
<string>Helvetica</string>
</test>
<edit mode="assign" name="family" >
<string>sans-serif</string>
</edit>
</match>
<alias>

==Footnotes==

[1] Apparently, there are some monitors where the screen can be rotated. If so, perhaps the vrgb/vbgr settings might be better for you (but only when the screen is rotated) If you can test this, please report back the results.

==Bibliography==

Man Page of fonts.conf - http://www.fontconfig.org/fontconfig-user.html 
XFree86 Font Configuration - http://www.xfree86.org/current/fonts2.html 
Explanation of Sub Pixel Hinting - http://grc.com/ctwhat.htm 
Gentoo Xorg & Fonts (And how to fix Konsole Linux fonts problem) - http://gentoo-wiki.com/HOWTO_Xorg_and_Fonts 
If you're running an old version of XFree http://www.tldp.org/HOWTO/FDU/index.html

Compiling

2009-05-28T20:28:32Z

Dugan: Migrated from old wiki

Well compiling a program can be a pain, but it's pretty fun. First you need to get the source you're compiling and read the INSTALL and README files on any weird install techniques. We first need to extract the source:

: <code>tar zxvf file.tar.gz</code>

You will now see a bunch of files on your screen, that means it's extracting, now half the programs have a configure script, this means you can enable, disable and tell the program where to install to:

: <code>./configure --help</code>

This gives you a list of the options you can compile in or disable options. Now this is a normal compile line:

: <code>./configure --prefix=/usr</code>

Now this installs the program in /usr so you don't need to edit the $PATH to launch it, Now 2 other options that you might want to add to some programs are:

: <code>--sysconfdir=/etc</code>
: <code>--localstatedir=/var</code>

These are pretty self explanatory. You may or may not need to edit these. Some source say $PREFIX/etc or something similar for the --sysconfdir and you might not want that, this is an example of when you need the --sysconfdir=/etc. Now when we have the source configured, you want to compile it:

: <code>make</code>

This compiles the actual program. It might take some time, it might not, depending on the source.

If make succeeds without errors, the program is now technically compiled. Some simpler programs can be run directly after compiling, without having to be installed, but most programs need to be fully installed before they can properly run.

To install, one can simply proceed as such:

: <code>su</code>

: <code>make install</code>

However, the above method does not take advantage of Slackware's package management system, which will make upgrading or uninstalling this program in the future much easier. The preferred way to install programs is through packages-- thus, at this point, the program should be packaged instead of simply running "make install" as root. See [[Building_A_Package]] and [[Checkinstall]].

This is just a basic way to compile a program and it's pretty easy to do. Now you know how to compile a program. Good luck.

[[Category:Tutorials]]

Checkinstall

2009-05-28T20:27:22Z

Dugan: Migrated from old wiki. AND GOT RID OF SPAM.

Checkinstall is actually really easy to use. Like it's told in [[compiling]] tutorial, you first do: 

<pre>./configure (--option=argument/path)</pre> 

then when configure has finished you write 

<pre>make</pre> 

after compiling you simply write 

<pre>checkinstall -y -S</pre> 

and you don't have to worry about it. This command makes a package and installs it. Also it leaves copy of this package to current directory in case you need it. If you want to remove package you go to /var/log/packages and write: 

<pre>removepkg pkgname</pre> 

'''Configuration'''

Checkinstall also works with a config file: /etc/checkinstall/checkinstallrc. In this file, the options that are especially
interesting to a SlackWare user are:
<pre>
ARCHITECTURE="i686"
INSTYPE="S"
PAK_DIR="/usr/src"
SHOW_SLACK_INSTALL=0
</pre>

"ARCHITECTURE" sets your architecture (if blank, it will auto guess)

"INSTYPE" specifies the type of package to create (S for Slackware)

"PAK_DIR" is the location where the finished packages will be moved to

"SHOW_SLACK_INSTALL" specifies wether the slackware package info will be shown when it's installed

That's it.

== External Links ==
Checkinstall home page: http://asic-linux.com.mx/~izto/checkinstall/
[[Category:Tutorials]]

Building A Package

2009-05-28T20:24:50Z

Dugan: Migrated from old wiki

[[Category:Tutorials]]

This is a rough outline for building Slackware packages. Some steps may not be neccessary, some steps might be missing. Use the discussion page for side-notes such as using slacktrack (when DESTDIR fails) and other utilities like checkinstall.

----

Configure and compile the source as you usually do:
./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
make

Make a temporary destination directory available:
mkdir /tmp/build

Install into the temporary directory:
make install DESTDIR=/tmp/build

Now strip libs/bins within the temporary directory:
strip -s /tmp/build/usr/lib/* /tmp/build/usr/bin/*

You also want to make sure that anything in <tt>/usr/man</tt> is gzipped before you make the package:
gzip -9 /tmp/build/usr/man/man?/*.?

Create the <tt>install</tt> directory, this is where the description and install script will be stored:
cd /tmp/build
mkdir install
cd install

Using a text editor, create a file called <tt>slack-desc</tt> and fill it with the following contents:

|-----handy-ruler------------------------------------------------------|
app: Application Name (Short/Brief description)
app:
app: Enter a description of the package you are building.
app: All 11 "app:" lines must be present
app: "app" needs to be your application name.
app: The handy-ruler is there to help you, these lines should not exceed
app: 79 characters.
app:
app:
app:
app:

Create the actual package:
cd /tmp/build
makepkg ../app-version-arch-tag.tgz

''(The dashes should appear as above, so if the version has a subversion like say "1.0 RC2" make sure you use 1.0_RC2 not 1.0-RC2. The arch should be something like "i486" for example. The tag should consist of the build number and your initals, e.g. 1zb for Zaphod Beeblebrox's first build, 2zb for his second build, etc. Official slackware packages have only numbers as tags.)''

When prompted to recreate symbolic links, say <tt>yes</tt> 
When prompted to reset permissions, say <tt>no</tt>

''Note: Using '''makepkg -l y -c n''' will give you the same behaviour as answering yes to the symlinks question, and no to the permissions question.''

If all went well, you can now install the package.
cd ..
installpkg app-version-arch-tag.tgz

----
For more information, also see the pages on [[SlackBuild_Scripts]] and [[Different_Approach_To_Buildscripts]].
----

Different Approach To Buildscripts

2009-05-28T20:23:32Z

Dugan: Migrated from old wiki

[[Category:Tutorials]]
Pretty much everyone can have their own way of writing Slackware buildscripts. I also have mine, which just makes it easier for me to package software.

In here, I'm going to explain mine. To start, let's look at one I wrote this morning while drinking coffee cup #1:

#!/bin/bash

#############################################################################
## Name: jpilot ##
## Version: 0.99.8 ##
## Packager: Martin Lefebvre (dadexter@gmail.com) ##
## Homepage: http://www.jpilot.org ##
#############################################################################

PKGNAME=jpilot
VERSION=0.99.8
LOC="http://jpilot.org/$PKGNAME-$VERSION.tar.gz"
ARCH=`uname -m`

START=`pwd`
PKG=$START/pkg
SRC=$START/work

build() {
mkdir -p $PKG $SRC
cd $SRC
wget $LOC
tar -zxvf $PKGNAME-$VERSION.tar.gz
cd $PKGNAME-$VERSION
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
--enable-gtk2 --enable-prometheon

patch -p0 < patch.0.99.8-memory
patch -p0 < patch.jpilot-sync
make
make DESTDIR=$PKG install
mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION
cp -r ABOUT-NLS AUTHORS BUGS COPYING ChangeLog ChangeLog.cvs INSTALL \
NEWS README TODO UPGRADING docs $PKG/usr/doc/$PKGNAME-$VERSION

cp KeyRing/README.txt $PKG/usr/doc/$PKGNAME-$VERSION/README.keyring
cp dialer/README $PKG/usr/doc/$PKGNAME-$VERSION/README.dialer
cp icons/README $PKG/usr/doc/$PKGNAME-$VERSION/README.icons
}

package() {
cd $PKG
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : \
| xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : \
| xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "current ar archive" | cut -f 1 -d : | \
xargs strip --strip-debug 2> /dev/null
chown -R root:root usr/bin
gzip -p $PKG/usr/man/man*/*
mkdir $PKG/install
cp $START/slack-desc $PKG/install/slack-desc
cd $PKG
makepkg -l y -c n $START/$PKGNAME-$VERSION-$ARCH-1.tgz
}

build
package

The top section is just comments identifying the piece of software we're going to build, and the name of the script's author. Then we have the following lines:

PKGNAME=jpilot
VERSION=0.99.8
LOC="http://jpilot.org/$PKGNAME-$VERSION.tar.gz"
ARCH=`uname -m`

START=`pwd`
PKG=$START/pkg
SRC=$START/work

They set the program's name, version, download URL, build and package directories. Since I usually don't specify anything related to the cpu or architecture, it auto detects the architecture. So, the $ARCH variable *should be* accurate.

build() {
mkdir -p $PKG $SRC
cd $SRC
wget $LOC
tar -zxvf $PKGNAME-$VERSION.tar.gz
cd $PKGNAME-$VERSION
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
--enable-gtk2 --enable-prometheon

patch -p0 < patch.0.99.8-memory
patch -p0 < patch.jpilot-sync
make
make DESTDIR=$PKG install
mkdir -p $PKG/usr/doc/$PKGNAME-$VERSION
cp -r ABOUT-NLS AUTHORS BUGS COPYING ChangeLog ChangeLog.cvs INSTALL \
NEWS README TODO UPGRADING docs $PKG/usr/doc/$PKGNAME-$VERSION

cp KeyRing/README.txt $PKG/usr/doc/$PKGNAME-$VERSION/README.keyring
cp dialer/README $PKG/usr/doc/$PKGNAME-$VERSION/README.dialer
cp icons/README $PKG/usr/doc/$PKGNAME-$VERSION/README.icons
}

The is the main build function. This contains the code required to build the software. First, we create the build and package directories. The next 3 lines change to the building diirectory, uses wget to fetch the source file and extracts it.

The lines after that are what you would normally type at your command line to build the software:

* Change to the source directory.
* Run ./configure with all the options you want.
* Apply two patches required (in this case) to fix bugs with the software.
* Run make
* Install the software in the package directory defined by $PKG
* Create the standard Slackware Software Documentation directory in the package
* Copy the standard documentation.

The next section is the packaging part:

package() {
cd $PKG
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : \
| xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : \
| xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "current ar archive" | cut -f 1 -d : | \
xargs strip --strip-debug 2> /dev/null
chown -R root:root usr/bin
gzip -p $PKG/usr/man/man*/*
mkdir $PKG/install
cp $START/slack-desc $PKG/install/slack-desc
cd $PKG
makepkg -l y -c n $START/$PKGNAME-$VERSION-$ARCH-1.tgz
}

* We change to the package directory
* Strip executables and libraries in order to decrease size.
* As a Slackware standard, we change the ownership of the executables to root:root (to be done for every bin/ and sbin/ directory)
* We compress the manpages
* Create install/ and copy the slack-desc file from the start directory
* Finally, change back to the package folder and create the package tarball.

In this example, the slack-desc and some patch files are distributed with the SlackBuild. This also makes it easier to ship the build script with patches that might be required for the software to work on Slackware (patch to remove PAM stuff).

The slack-desc file format is described here: [http://www.linuxpackages.net/howto.php?page=slack-desc&title=Slackware+Desc+Files LinuxPackages.net]

Additional files:

Some people use slapt-get (like me). slapt-get supports additional features such as
* Dependencies
* Conflicts
* Suggestions

Not everyone wants those features, so building a package with those files will not interfere with the normal pkgtools process. For more info on these optional files, go here: [http://www.linuxpackages.net/howto.php?page=perfect-package&title=Perfect+Package#Optional LinuxPackages.net]

If you decide to use those files, you will then have to repeat these lines:

cp $START/slack-desc $PKG/install/slack-desc

for slack-required, slack-conflicts, and slack-suggests.

----
See also [[SlackBuild_Scripts]] and [[Writing A SlackBuild Script]]
----

Contest

2009-05-28T20:19:39Z

Dugan: Migrated from old wiki

'''This contest is completed; congratulations to Marcus'''

This page is here for those of you who wanted to create logos for slackwiki.org's contest.
Have at it!!!

From [[User:FredEmmott|Fred87]] Can i have SVGs and/or png's please :)

From [[User:erik|erik]] Mine is a png :)
----
Submitted by: [[User:Dominian|Dominian]] on Nov. 17, 2004 
http://home.insightbb.com/~mhayes/images/slackwiki_logo.png

-----------------------------------------

Submitted by: [[User:jjdm|jjdm]] on Nov. 20, 2004 
Repainted [http://us.aminet.net/pix/trace/BOOK.jpg this book] with sodipodi, repainted the slackware-logo and added a third-party svg-tux. You can get the SVG-file at [http://mufl.politux.org/logo.svg]. If you like the logo, but not the colors, feel free to edit the SVG-file. I meen, _please_ edit the SVG if you are good in colors because I'm a little colorblind. Thanks. 
http://mufl.politux.org/logo.png

-----------------------------------------

Submitted by: [[User:erik|erik]] on Nov. 21, 2004 
The Wings of Slack, not mine, original from [http://subgenius.com/ The Church of the Subgenius]. 
Should fit right over the old logo (135x135), transparent bg will blend with current bg. 
http://sl1200.org/WingsOfSlack.png

-----------------------------------------

Submitted by: [[User:buzzedlightyear|buzzedlightyear]] on Nov. 23, 2004 
Slackware logo, cropped it from a background i found and added text. 
http://www.slackwaregallery.com/albums/userpics/10157/slackwikilogo.png

-----------------------------------------

Submitted by: [[User:tewmten|tewmten]] on Dec. 14, 2004 
A little penguin writing a book wich has the Slackware S on it. 
135x135 with transparent background. 
http://irda.mine.nu/~tewmten/SlackWiki-tew.png

----

Submitted by: [[User:v3ctor|v3ctor]] on Dec. 15, 2004 
Just a little something.
http://www.geocities.com/thelucid99/slackwiki.png

----
Submitted by: [[User:Marcus|Marcus]] on Dec. 25, 2004 

Feel free to use it:

http://www.gnulinux.de/images/personal/slackwiki/slackwiki.gif

Build Environment

2009-05-28T20:17:15Z

Dugan: Replaced [CODE] tags (which weren't displaying properly)

= Introduction =
The purpose of this document is to give you several ideas on how to set up a good building environment (directory structure and such) for making Slackware packages from SlackBuild scripts.

Hopefully, you can see what works for several different people here. The definition of "good" is largely dependent upon personal preference, but all of these would be classified as "good" for the individuals using them.

= Individual Setups =

== jjdm ==

My directory structure is as follows:

'''/home/slackware/'''
The slackware home directory. This directory (and all subdirectories) are owned by the group "packager" (of which root and my user account are members on my system).

'''/home/slackware/source'''
In this directory I've placed the whole slackware-source because maybe I have to temporarily build another package to build a new one because of header files and stuff.

'''/home/slackware/source/myslackware/'''
This is where I build all my packages. Now they are unorganized but you can organize them in different topics like they're in Slackware.

'''/home/slackware/source/myslackware/<package>'''
In this directory you build your package <package>.

'''/home/slackware/packages'''
Place where the built packages are.

You don't have to use such a building environment. You can place everything in your home-folder, in /root or somewhere else. The only important thing is that you always keep track of your files and packages.

BTW: You can get the Slackware source packages from your Slackware-mirror of choice. It's placed in source/.

== robw810 ==

=== Directory Structure ===
My setup is something like this:
/shared/os_files/slackware/slackware-(version)/source/...
/home/rworkman/build/source
/home/rworkman/build/packages

=== Explanation of Directory Structure ===
The '''/shared/os_files/slackware/slackware-(version)/source/''' directory contains all of the source files (it's copied directly from the cdroms) from that release of Slackware.

The '''/home/rworkman/build/source''' directory contains all of the sources for my SlackBuild scripts and such (it's set up basically identical to what the Slackware source directory contains).

The '''/home/rworkman/build/packages''' directory contains all of the packages compiled from my sources.

=== Integration of Directory Structure with Executing SlackBuild Scripts ===

With some good environment variables declared in your SlackBuild scripts, it's relatively easy to manage this setup:
PKG_OUT=/home/rworkman/build/packages

=== Final Thoughts ===
As always, what works for me may not be ideal for you, so adjust your expectations accordingly :)

= Other Resources =

* [[Writing_A_SlackBuild_Script]]
* [[SlackBuild_Scripts]]

Build Environment

2009-05-28T20:12:40Z

Dugan: Migrated from old wiki

= Introduction =
The purpose of this document is to give you several ideas on how to set up a good building environment (directory structure and such) for making Slackware packages from SlackBuild scripts.

Hopefully, you can see what works for several different people here. The definition of "good" is largely dependent upon personal preference, but all of these would be classified as "good" for the individuals using them.

= Individual Setups =

== jjdm ==

My directory structure is as follows:

'''/home/slackware/'''
The slackware home directory. This directory (and all subdirectories) are owned by the group "packager" (of which root and my user account are members on my system).

'''/home/slackware/source'''
In this directory I've placed the whole slackware-source because maybe I have to temporarily build another package to build a new one because of header files and stuff.

'''/home/slackware/source/myslackware/'''
This is where I build all my packages. Now they are unorganized but you can organize them in different topics like they're in Slackware.

'''/home/slackware/source/myslackware/<package>'''
In this directory you build your package <package>.

'''/home/slackware/packages'''
Place where the built packages are.

You don't have to use such a building environment. You can place everything in your home-folder, in /root or somewhere else. The only important thing is that you always keep track of your files and packages.

BTW: You can get the Slackware source packages from your Slackware-mirror of choice. It's placed in source/.

== robw810 ==

=== Directory Structure ===
My setup is something like this:
/shared/os_files/slackware/slackware-(version)/source/...
/home/rworkman/build/source
/home/rworkman/build/packages

=== Explanation of Directory Structure ===
The [code] /shared/os_files/slackware/slackware-(version)/source/ [/code] directory contains all of the source files (it's copied directly from the cdroms) from that release of Slackware.

The [code]/home/rworkman/build/source[/code] directory contains all of the sources for my SlackBuild scripts and such (it's set up basically identical to what the Slackware source directory contains).

The [code]/home/rworkman/build/packages[/code] directory contains all of the packages compiled from my sources.

=== Integration of Directory Structure with Executing SlackBuild Scripts ===

With some good environment variables declared in your SlackBuild scripts, it's relatively easy to manage this setup:
PKG_OUT=/home/rworkman/build/packages

=== Final Thoughts ===
As always, what works for me may not be ideal for you, so adjust your expectations accordingly :)

= Other Resources =

* [[Writing_A_SlackBuild_Script]]
* [[SlackBuild_Scripts]]

Doinst.sh

2009-05-28T20:09:56Z

Dugan: Migrated from old wiki

This script is usually included under ./install within Slackware [[packages]] and contains post-install actions.

Usually automatically created by [[makepkg]] for cleaning up and recreating symbolic links, advanced packagers may wish to include further configuration instructions here to be executed after files have been extracted from the .tgz package.

== Files ==

Within packages, doinst.sh is located in install/.

After installation, the doinst.sh scripts are placed in /var/log/scripts, and renamed into the package name.

== Examples ==

=== Handling symbolic links ===

The package 'udev-064-i486-2' (from Slackware 10.2), contains a doinst.sh script which includes the following:

( cd etc/hotplug.d/default ; rm -rf 10-udev.hotplug )
( cd etc/hotplug.d/default ; ln -sf /sbin/udevsend 10-udev.hotplug )
( cd usr/man/man8 ; rm -rf udevsend.8.gz )
( cd usr/man/man8 ; ln -sf udevd.8.gz udevsend.8.gz )

Thus, during installation of this package, it will delete 'etc/hotplug.d/default/10-udev.hotplug' and 'usr/man/man8/udevsend.8.gz', then immediately recreate them using symbolic links.

This part of doinst.sh scripts is the most common, and is almost always generated by [[makepkg]] automatically during the creation of the package. In fact, 'makepkg' strongly suggests handling symbolic links using the doinst.sh script this way.

=== Configuration Files ===

The package 'vim-7.0.109-i486-1' (from Slackware 11.0), contains a doinst.sh script which includes the following:

config() {
NEW="$1"
OLD="$(dirname $NEW)/$(basename $NEW .new)"
# If there's no config file by that name, mv it over:
if [ ! -r $OLD ]; then
mv $NEW $OLD
elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then # toss the redundant copy
rm $NEW
fi
# Otherwise, we leave the .new copy for the admin to consider...
}
config usr/share/vim/vimrc.new

The config() function checks whether the configuration file in the package (vimrc) already exists on the system, or is exactly the same as the new one included in the package; if it exists and is not the same as the package's copy, it will not overwrite the old one but instead will be copied with a .new file extension (vimrc.new).

This is a common, and the preferred, way of dealing with configuration files in Slackware packages.

== See Also ==
* [[Packages]]
* [[Building A Package]]

Packages

2009-05-28T20:07:13Z

Dugan: Migrated from old wiki

Slackware's package management system utilizes .tgz tarballs as its standard package format. These tarballs are tar.gz archives which contain Slackware built binaries, support files, a description file and installation script. Although they can be unzipped and untarred like a normal archive, they are (usually) binary-only packages intended to be installed through Slackware's provided package management tools.

Information about a package is stored in two ways, in the filename of the package and a description file inside that package.

==Package Tools==
See the respective manual pages for more information on each of the following commands.

<code>pkgtool</code>

<code>installpkg</code>

<code>removepkg</code>

<code>explodepkg</code>

<code>makepkg</code>

<code>upgradepkg</code>

==Slackware Package Layout==
A typical Slackware package is laid out as such:
./
./install/doinst.sh
./install/slack-desc
[./usr/bin]
[./usr/lib]
[...]

The install directory as well as the files within it will be deleted after the installation of the package to the root install directory (usually '/'). The install directory is not necessarily required for the most basic packages but allows additional functionality: [[slack-desc]] contains the package description, and [[doinst.sh]] contains post-installation instructions such as creating symbolic links.

Every other file within the package is simply untarred (extracted) to the root directory. Most of these files are in standard locations.

There are other special files within packages:

'''usr/doc/<appname><version>'''
All documentation included with the package (such as README, INSTALL, ChangeLog, docs/, etcetera) should be placed in this directory. Some of the files in this directory should be manually copied from the source archive, since Makefiles usually don't copy these documentation files to the package build tree.

==Making Slackware Packages==
See [[Building A Package]]

Slack-desc

2009-05-28T17:47:48Z

Dugan:

=Overview=
A proper slack-desc file should be written as follows:

# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description. Line
# up the first '|' above the ':' following the base package name, and the '|' on
# the right side marks the last column you can put a character in. You must make
# exactly 11 lines for the formatting to be correct. It's also customary to
# leave one space after the ':'.

|-----handy-ruler------------------------------------------------------|
appname: Summary of application name and function (one line only)
appname: <this line is generally left blank>
appname: Description of application - this description should be fairly
appname: in-depth; in other words, make it clear what the package does (and
appname: maybe include relevant links and/or instructions if there's room),
appname: but don't get too verbose.
appname: This file can have a maximum of eleven (11) lines of text preceded by
appname: the "appname: " designation.
appname:
appname: It's a good idea to include a link to the application's homepage too.
appname:

The "appname" string must *exactly* match the application name portion of the
Slackware package (for example, a package titled "gaim-1.5-i486-1.tgz" must have
a slack-desc file with the <appname> string of "gaim: " rather than "Gaim: " or
"GAIM: " or something else.

The "handy ruler" is meant to stop you at 79 characters, because the standard
console is 80x25 and if you go beyond this the words will wrap.

=See Also=
man makepkg
man pkgtool

[[Category:Tutorials]]

Slack-desc

2009-05-28T17:46:19Z

Dugan: Created page with 'Category:Tutorials = Introduction = Originally written by Florian Mueller jjdm@jjdm.org Substantial cleanup and enhancement by Robby Workman (rworkman) If you use slackw...'

[[Category:Tutorials]]

= Introduction =

Originally written by Florian Mueller jjdm@jjdm.org
Substantial cleanup and enhancement by Robby Workman (rworkman)

If you use slackware as your main operating system, you have probably wanted to install quite a few applications which are not available in the official slackware.com or even third-party repositories like linuxpackages.net, or perhaps you just don't like using third-party packages. In this situation, you have several options on how to install the application:

* ./configure && make && make install
* use checkinstall
* use installwatch
* compile and use makepkg by hand
* write a SlackBuild script

I will go through the last option: writing [[SlackBuild Scripts]] (which combines the best qualities of all the other aforementioned methods). With a SlackBuild script, you have the build process automated, which will allow you to easily do later upgrades or patches to the package. SlackBuild scripts are also the method by which Patrick Volkerding builds all of the official packages for Slackware. If you look at the various scripts from different sources, you will notice that there is generally an application-independent portion of a script and an application-specific portion of the script.

I cannot teach you how to build the "perfect" package, as reaching that goal requires fairly in-depth knowledge of the Slackware operating system. You must consider the interactions of your proposed package with all of the other packages within the distribution; they must be integrated seamlessly. What I can teach you is how to build a package that works and which stays true to the "Slackware Way."

"But it takes so much time!"

It will take approximately thirty minutes to go through this tutorial and about fifteen minutes to create each package (actual compile process not included), but the time you save in the future (you want to create a newer version of the package) makes the initial time expenditure worth it.

= The Slackware package structure =

See [[Packages#Slackware Package Layout]]

= Setting up your build environment =

See [[Build_Environment]] for examples of how various users do this.

= Getting Started =

Hopefully, everything is now clear about Slackware package structure, and you have set up a clean build environment, so we'll begin the process of building a package with a SlackBuild script.

For this example, we'll create a package of latex2html - I made my homepage with that tool.

First, you have to create a directory named <build_environment>/latex2html/. Get the most recent source code release of latex2html place it in this directory. Note that use of wget below to obtain the most recent source code is optional - you can just as well use your favorite web browser to download it, and then move it into the correct directory.

$ cd <build_environment>
$ mkdir latex2html
$ cd latex2html
$ wget http://saftsack.fs.uni-bayreuth.de/~latex2ht/current/latex2html-2002-2-1.tar.gz # 05.02.2005

Next, we'll create some other needed files with touch. If you're not familiar with touch, see:
man touch
Note that the *.SlackBuild file will always contain the name of the application for which it's written; for example, gaim would have gaim.SlackBuild.

$ touch latex2html.SlackBuild
$ touch slack-desc

Extract the source code of the application, because we'll need to look at the configure script later on to determine what options we need to pass to it.

$ tar -xzf latex2html-2002-2-1.tar.gz || exit 1

= Writing the slack-desc file =

See this [[Slack-desc]] page on SlackWiki.org for instructions on how to write a proper slack-desc file.

= Writing the SlackBuild script =

This is the section which takes the most time, and I'll go through it with you step by step. When you build more packages, you'll probably be able to just copy an existing SlackBuild script and customize it. First, you need to understand that you can write your SlackBuild script in any manner you choose so long as it creates a working package; the method described here is more or less the way Pat Volkerding [[http://slackware.com/~volkerdi]] does it, but even Pat has several different styles for writing the official SlackBuild scripts. Therefore, if you see something you would do a different way, feel free to do it that way - it's okay.

===Initial Setup===

Open the file latex2html.SlackBuild with your favourite editor. What follows below is a piece by piece walk-through of a working SlackBuild script. You may certainly paste the exact contents of those pieces, but in the author's opinion, you have a better chance of understanding it if you write everything yourself.

First, you'll need to set your shell interpreter. This should be /bin/sh, as *every* Slackware system is guaranteed to have this shell installed, and you want maximum portability. For this same reason, be careful not to use any extensions and/or syntax that is customized for your particular shell (bash, zsh, or whatever), as it won't be interpreted correctly.

#!/bin/sh

You might want to include a license of some sort with your SlackBuild script (preferably a GPL or BSD-style license), but at a minimum, you'll want something like this:

#<your name> revision date yyyy/mm/dd

With the next few lines, we set some variables that will be used throughout the script. First is the "CWD" variable; in our case, CWD will be <build_environment>/latex2html/. We also test if the TMP variable is set, and if not, we set it to /tmp.

#Set initial variables:

CWD=$(pwd)
if [ "$TMP" = "" ]; then
TMP=/tmp
fi

Some people like to build in a subdirectory of /tmp (such as /tmp/build), but that's up to you.

# The version which appears in the application's filename
VERSION=2002-2-1

# If the version conflicts with the Slackware package standard
# The dash character ("-") is not allowed in the VERSION string
# You can set the PKG_VERSION to something else than VERSION
PKG_VERSION=2002.2.1 # the version which appears in the package name.

ARCH=${ARCH:-i486} # the architecture on which you want to build your package

# First digit is the build number, which specifies how many times it has been built.
# Second string is the short form of the authors name, typical three initials:w
BUILD=${BUILD:-1_rlw}

# The application's name
APP=latex2html

# The installation directory of the package (where its actual directory
# structure will be created)
PKG=$TMP/package-$APP

Set SLKCFLAGS (which will be used for both CFLAGS and CXXFLAGS). If you are building on a system with an earlier version of gcc than 3.4.x, then you'll need to use "-mcpu" instead of "-mtune" below.

if [ "$ARCH" = "i486" ]; then
SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
fi

The section just finished sets up a few application-specific variables. When you want to create a package of some other application, you can usually just change the variables, and most of the further steps will work automatically.

=== Extract Sources ===

# Delete the leftover directories if they exist (due to a previous build)
# and (re)create the packaging directory
rm -rf $PKG
mkdir -p $TMP $PKG
rm -rf $TMP/$APP-$VERSION

# Change to the TMP directory
cd $TMP || exit 1

# Extract the application source in TMP
# Note: if your application comes as a tar.bz2, you need tar -jxvf
tar -zxvf $CWD/$APP-$VERSION.tar.gz || exit 1

# Change to the application source directory
cd $APP-$VERSION || exit 1

# Change ownership and permissions if necessary
# This may not be needed in some source tarballs, but it never hurts
chown -R root:root .
chmod -R u+w,go+r-w,a-s .

===Configure and Compile Sources===

# Set configure options
# If your app is written in C++, you'll also need to add a line for CXXFLAGS
CFLAGS="$SLKCFLAGS" \
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-perl=/usr/bin/perl \
--enable-eps \
--enable-gif \
--enable-png \
--build=$ARCH-slackware-linux \
--host=$ARCH-slackware-linux

# compile the source, but exit if anything goes wrong
make || exit

# Install everything into the package directory, but exit if anything goes wrong
make install DESTDIR=$PKG || exit

There are three configure options I always set:

* --prefix=/usr
* --sysconfdir=/etc
* --localstatedir=/var

This makes configuration files go to /etc, state files (such as log files) go to /var, and the rest goes to /usr. That's the usual Slackware way, but it's your system, so you can certainly install everything in /usr/local or some other location. See the Unix Filesystem Hierarchy Standard [[http://www.pathname.com/fhs/]] for more information on "correct" locations of various filetypes.

You notice that there were several other options passed to the configure script, and for each application you compile, you have to figure those out for yourself - that's why you were told to extract the sources earlier in this process. You simply cd into the source directory and run:
./configure --help
This will produce a page or two (sometimes more, though) of information about various options that are specific to the application. Read through this information and figure out what you need (I like to pipe that command through lpr to get a printed copy, but you can certainly use some sort of pager as well:
./configure --help | lpr
./configure --help | less

The DESTDIR variable is very important in this script because it specifies the directory in which the files should be installed. This should always be our package directory ($PKG). Unfortunately, some applications' Makefiles will not support the DESTDIR variable, so you can't use it for those apps. A simple line like this:
grep DESTDIR Makefile*
while inside the source directory should tell you whether it supports DESTDIR or not. If you get some lines of output with $DESTDIR in them, you're in good shape. If the command returns no output, then the Makefile does not support the DESTDIR variable.

Here's a piece of advice: ALWAYS go through the ./configure && make && make install DESTDIR=/somedir process manually and as a NORMAL USER account BEFORE you run your SlackBuild script. There are quite a few applications out there which try to do "funny stuff" during the installation phase.
For example, apcupsd will attempt to patch your /etc/rc.d/rc.6 init script
Yes, it's possible to avoid this with a configure option, but it's not obvious that you would need
to do so until you look at all of the Makefiles for apcupsd (or watch the install process)
Anyway, if you go through the process as a normal user, you will get "Permission Denied" errors and such if the install process tries to write anywhere it's not allowed to do so.

=== Install Documentation ===

# Create a directory for documentation
mkdir -p $PKG/usr/doc/$APP-$VERSION

# Copy documentation to the docs directory and fix permissions
cp -a BUGS Changes FAQ INSTALL LICENSE MANIFEST README TODO docs/ $PKG/usr/doc/$APP-$VERSION
find $PKG/usr/doc/$APP-$VERSION -type f -exec chmod 644 {} \;

I (rworkman) also like to place a copy of my SlackBuild script in this directory
cat $CWD/$APP.SlackBuild > $PKG/usr/doc/$APP-$VERSION/$APP.SlackBuild

Make sure you look inside the actual source archive of the application, because some applications won't have all of the documentation files specified above, and some applications will have additional files. In other words, don't just copy/paste what you see above into your SlackBuild script - you *must* customize this section for each individual application.

=== Final Touches ===

# Create the ./install directory and copy the slack-desc into it
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc

NOTE: In some cases, you will have some sort of command or setup that
needs to run after the package contents are installed - for this, you
would add a file to $CWD called "doinst.sh" which contains the needed
commands, and then compress that file with gzip. The SlackBuild script
will zcat (which means to gunzip and cat its contents) that file and
write the output to a doinst.sh file in the $PKG/install directory.

# Add doinst.sh to package (if it exists)
if [ -e $CWD/doinst.sh.gz ]; then
zcat $CWD/doinst.sh.gz > $PKG/install/doinst.sh
fi

Let's conserve space if we can; strip libraries and binaries and compress man pages with gzip
Note that you might be able to use "make install-strip" instead of "make install" above instead to accomplish the same purpose

# Strip some libraries and binaries
( cd $PKG
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
)

# Compress man pages if they exist
if [ -d $PKG/usr/man ]; then
( cd $PKG/usr/man
find . -type f -exec gzip -9 {} \;
for i in $(find . -type l) ; do ln -s $(readlink $i).gz $i.gz ; rm $i ; done
)
fi

# Compress info pages if they exist (and remove the dir file)
if [ -d $PKG/usr/info ]; then
gzip -9 $PKG/usr/info/*.info
rm -f $PKG/usr/info/dir
fi

=== Build the Package ===

# Build the package
cd $PKG
/sbin/makepkg -l y -c n $TMP/$APP-$PKG_VERSION-$ARCH-$BUILD.tgz

= Other Concerns =

=== DESTDIR Option Not Available ===

As mentioned above, there are quite a few applications whose Makefiles do not support the DESTDIR option for make install. On some applications the DESTDIR Makefile variable has another name. For example, some Qt applications use the variable INSTALL_ROOT for the same purpose. If you can understand Makefiles, it is probably worth your time to take a look at its contents and try to find out which actions are performed in the install rule. Sometimes there will be no DESTDIR equivalent at all. The best thing you can do in this situation is write a patch for the Makefile.in or equivalent, and submit it to the developer(s) for inclusion in the source, but I realize that everyone doesn't have the ability to do that. The second best thing you can do it write to the developer(s) and ask them to include that functionality in future releases. In the meantime, here are some thoughts on the subject...

==== Example 1: ====
Configure the build with:
./configure --prefix=$PKG/usr
along with your other configure options. This will install *all* of the package contents in that directory. If the package creates $PKG/usr/etc and $PKG/usr/var directories (or any other directories that should be elsewhere), you can probably just move them to their correct location within the package directory tree and everything will be fine. You might also try this along with your other configure options.
./configure --prefix=$PKG/usr \
--sysconfdir=$PKG/etc \
--localstatedir=$PKG/var
There are some applications, however, which "hard-code" configuration files based on configure/Makefile parameters. In those cases, you'll have to figure out a way to patch the config file prior to packaging it, or in worst-case scenario, include instructions for the end user on how to make the necessary changes.

==== Example 2: ====
This example makes use of the ability to override any Makefile variable, which is called a '''macro''' in the Makefile terminology, on the command line and not have to worry about patching the Makefile to include a '''DESTDIR''' macro in the Makefile. This approach makes it a bit easier for those not familiar with Makefiles.

If the Makefile does not honor '''DESTDIR''' for the 'make install' command, you can change the prefix macro, instead:
make prefix=$PKG/usr install
This will override the $(prefix) variable inside the Makefile and install to the location you supplied on the command line. Therefore, you can configure with the standard ''./configure --prefix=/usr'' (or ''./configure --prefix=/usr/local'') syntax, yet install to a different location as if you supplied a ''DESTDIR=$PKG/usr'' for the 'make install' command.

IMPORTANT NOTE: Macro names are case-sensitive (at least for GNU make). Some Makefiles may use a "'''PREFIX ='''" macro instead of the usual "'''prefix ='''", so the 'make install' command would look like this:
make PREFIX=$PKG/usr install
Therefore, it's necessary to look inside the Makefile to be sure which form was used for the prefix. For large, complex makefiles, the easiest way is to 'grep' the Makefile, like so:
grep -i '^prefix \?=' Makefile{,.in}
The ''-i'' option makes the search case-insensitive and the ''{,.in}'' part at the end will search "Makefile" or "Makefile.in" files, the second one being a template for the "configure" script. Grep's search term is a basic regular expression, so the escaped question mark after the space (\?) means there may or may not be a space in between when searching.

Once in a while, there may be a "'''PREFIX ='''" in a Makefile that is not defined which you are to edit and supply the location. Use the usual ''/usr'' (or ''/usr/local''), in this case, and then use 'make PREFIX=$PKG/usr install' to install to the package's build location.

=== Patching the Sources ===

Sooner or later, there will be some reason to patch the source code prior to building a package, and you'll want to be able to do this automatically.

===== Obtaining the Patch =====

In most cases, the patch will be provided by the author of the source code, so we're not going to discuss patch *creation* here. Download the patch and place it in the same directory as the SlackBuild script, slack-desc file, and other related files (in $CWD from above).
$ wget http://someapplication.org/files/patches/bigsecuritypatch.diff
It's not necessary to do the next step, but because developers generally want to conserve space if possible, it's conventional to do this:
$ gzip -9 bigsecuritypatch.diff
This will result in a new file called bigsecuritypatch.diff.gz -- we'll use that in the SlackBuild script in just a moment.

===== Applying the Patch =====

You will now need to edit your <application>.SlackBuild script so that it applies the patch before it runs configure, make, and make install. To do this, you'll want something like this to run before the configure script, but after extracting the sources:
zcat $CWD/bigsecuritypatch.diff.gz | patch -p1 || exit
Depending on how the patch was created, you might use a different patchlevel on that line, as in:
zcat $CWD/bigsecuritypatch.diff.gz | patch -p0 || exit
It's a bit beyond the scope of this HOWTO, but essentially, the -p# specifies the number of trailing directories to skip when looking for the file to patch. You'll often need to skip the top-level directory, but not always (hence the -p0).

= See Also =

* [[SlackBuild_Scripts]]
* [[Different_Approach_To_Buildscripts]]
* [[Building_A_Package]]
* [[Slack-desc]]
* [[Checkinstall]]
* [[Compiling]]

= SlackBuild Script Repositories =

;* http://slackbuilds.org
;* http://www.slackware.com/~alien/slackbuilds/
;* http://slackbuilds.slackadelic.com/
;* http://slackbuilds.rlworkman.net/
;* http://www.slackbuilds.net/slackbuilds/
;* http://slackbuild.strangeworlds.co.uk/
;* http://www2.linuxpackages.net/packages/SlackBuilds/
;* http://www.selkfoster.com.ar/downloads/slackbuilds/
;* http://slack.sarava.org/slackbuilds/

Writing A SlackBuild Script

2009-05-28T17:39:45Z

Dugan: Created page with 'Category:Tutorials = Introduction = Originally written by Florian Mueller jjdm@jjdm.org Substantial cleanup and enhancement by Robby Workman (rworkman) If you use slackw...'

SlackBuild Scripts

2009-05-28T17:37:32Z

Dugan: Created page with 'SlackBuild scripts are simple shell scripts which can automate the compiling and packaging of a program from source. While not necessary to compile and create packages on Slack...'

SlackBuild scripts are simple shell scripts which can automate the compiling and packaging of a program from source.

While not necessary to compile and create packages on Slackware, SlackBuilds serve as tools for scripting the compiling and packaging processes, which are often repetitive. Just as importantly, SlackBuilds also act as documentation of compile-time options and configurations for that particular package. For that reason, official Slackware packages come with SlackBuilds bundled with the source code, and the inclusion of a SlackBuild is desirable in third-party packages.

== Using SlackBuild Scripts ==
In this example I'm going to use the [http://www.pidgin.im Pidgin] slackbuild. First you find on the mirror in the source directory and download the whole directory of Pidgin:

: <code>mkdir pidgin</code>
: <code>cd pidgin</code>
: <code>wget --passive-ftp <nowiki>ftp://slackware.at/slackware-12.1/source/xap/pidgin/*</nowiki></code>

This downloads the files needed for Slackware scripts. The same idea applies for SlackBuild scripts from other
sources - you generally need to download all of the files in the directory that contains the build script. For example, in the pidgin source directory, you would need the following files:

: <code>pidgin-2.4.1.tar.bz2 pidgin-encryption-3.0.tar.gz pidgin.SlackBuild* slack-desc </code>

There will sometimes be other files, such as doinst.sh, diff.gz patch files, and rc.* scripts in this directory.

Now, say you want to get the newest version of pidgin? Well, you download the tar.bz2 file (in Pidgin, the script uses tar.bz2). Now you open up pidgin.Slackbuild:

: <code>VERSION=2.4.1</code>

This is the line we are looking at. Now we can change this to

: <code>VERSION=2.4.2</code>

Now you can edit the compile flags and other cool things not covered here. Now that we have downloaded and edited the SlackBuild script, let's make it executable:

: <code>chmod +x pidgin.SlackBuild</code>

Now this is executable, and we want to run as root for permissions and other reasons so we want to become root:

: <code>su -</code>

Now we start the script, and this will compile Pidgin and make a Slackware package. Depending on how the
script is written, the resulting package will be in /tmp, some directory of /tmp, or perhaps some
other location - have a look at the SlackBuild script for some hints if you can't find the package that
was built.

Once you find the package, you simply use 'installpkg' to install it normally (and you probably want to
move it somewhere else on your system for safekeeping).

: <code>./pidgin.SlackBuild</code>

=SlackBuild Archives=
;* http://www.slackbuilds.org
;* http://repository.slacky.eu
;* http://www.slackware.com/~alien/slackbuilds/
;* http://www.slackbuilds.net/slackbuilds/
;* http://slackbuild.strangeworlds.co.uk/

=Other Resources=
For a bit more detailed tutorial, see this entry: [[Writing A SlackBuild Script]]

[[Category:Tutorials]]