NSLU2-Linux
view · edit · print · history

Optware.AddAPackageToOptware History

Hide minor edits - Show changes to markup

October 26, 2010, at 10:28 PM by JC -- Added build server info
Added lines 164-165:

Note regarding Build servers

As of 2010-Oct-26, the official builder is still on Ubuntu 8.04.3 LTS.

September 01, 2010, at 04:44 AM by Miguel Macias -- Link to SourceForge SVN instructions is broken. Replaced with working link.
Changed lines 15-16 from:

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

to:

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/apps/trac/sourceforge/wiki/Subversion) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

November 01, 2009, at 10:37 PM by Reedy -- note about building for nslu2 etc
Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo, subversion and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo, subversion and while your at it, your favourite editor e.g. emacs.

Note, if you are wanting to build for nslu2 (unslung), Ubuntu 9.10 cannot be used, as GCC 3.3 is needed (3.4 may suffice). Debian 5 still has this in its package feeds.

November 01, 2009, at 10:30 PM by Reedy -- add toolchain
Changed line 58 from:
  $ cd <platform>; make directories ipkg-utils
to:
  $ cd <platform>; make directories toolchain ipkg-utils
November 01, 2009, at 09:13 PM by Reedy -- subversion
Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo, subversion and while your at it, your favourite editor e.g. emacs.

July 16, 2009, at 02:11 AM by rwhitby -- Added automake to build dependencies.
Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo and while your at it, your favourite editor e.g. emacs.

July 16, 2009, at 02:11 AM by rwhitby -- Added texinfo to build dependencies list.
Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed, texinfo and while your at it, your favourite editor e.g. emacs.

June 25, 2009, at 01:20 AM by BrianZhou -- particular about pwd to build ipk
Changed line 95 from:

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

to:

Now it's time for the moment of truth. From your optware/<target> (<target> being the optware target) make your package.

December 15, 2008, at 09:11 PM by RobHam -- Note added regarding Libtool versions
Added lines 150-161:

Note regarding Libtool and Libtoolize

For building most packages, the GNU Libtool and Libtoolize are essential programs that need to be installed on the build system. These two programs interact with the ltmain.sh script included with most program tarballs. There are currently two version streams for these programs, version stream 1.5.x included with most older versions of Debian and Ubuntu etc, this is the version used by the NSLU2 Optware build machines. More recent versions of Ubuntu and other Linux distros have now upgraded Libtool and Libtoolize to the version stream 2.2.x. Unfortunately many Optware packages will not build with this later version. The reason - version stream 2.2.x is not fully backwardly compatible with ltmain.sh scripts from earlier versions. This backward compatibility problem is well documented on the internet, there are may recommended fixes and patches etc, most are not fully explored, some may fix one package but break another. To check the version of Libtool installed type at a console prompt : -

libtool --version

For Optware development it is recommended that the version of Libtool is downgraded to version 1.5.26 or lower, example - with a Ubuntu Intrepid build system install the Ubuntu Hardy version of the libtools.

Another possibility is to upgrade the version of the ltmain.sh script included with the program tarball to a version 2.2.x. This seems to work with some program tarballs but not all.

December 2008

May 25, 2008, at 10:52 PM by BrianZhou -- restored from spam
Changed lines 1-149 from:

cool girls ;) <a href=" http://groups.google.us/group/teensss ">teentonic</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 25, 2008, at 10:42 PM by pinkpanteens -- cPqAKWoqSJAVoGWv
Changed line 1 from:

great boobs dude )) see <a href=" http://groups.google.us/group/sexyboobs ">sexycouple</a>

to:

cool girls ;) <a href=" http://groups.google.us/group/teensss ">teentonic</a>

May 25, 2008, at 10:41 PM by phonesex -- fxDcHcfYcT
Changed line 1 from:

sweet babes )) <a href=" http://groups.google.us/group/sexyboxy ">asexstories</a>

to:

great boobs dude )) see <a href=" http://groups.google.us/group/sexyboobs ">sexycouple</a>

May 25, 2008, at 10:29 PM by sexbot -- NlNqeSMALWZK
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

sweet babes )) <a href=" http://groups.google.us/group/sexyboxy ">asexstories</a>

May 25, 2008, at 05:44 PM by BrianZhou -- restored from spam
Changed lines 1-149 from:

dfgdfgdfsgsd gdsfgdsf gdsfgdsf gdsfg <a href=" http://groups.google.us/group/teensxx ">whiteteensblackcocks</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 25, 2008, at 05:11 PM by teengalleries -- qLQNmUeHUIeIhbZNKAs
Changed line 1 from:

nice site man <a href=" http://groups.google.us/group/replicax ">replica louis vuitton diaper bag</a>

to:

dfgdfgdfsgsd gdsfgdsf gdsfgdsf gdsfg <a href=" http://groups.google.us/group/teensxx ">whiteteensblackcocks</a>

May 25, 2008, at 05:10 PM by swiss replica watches -- DUbFhpLY
Changed line 1 from:

great site dude <a href=" http://groups.google.us/group/replicaz ">rolex replicas</a>

to:

nice site man <a href=" http://groups.google.us/group/replicax ">replica louis vuitton diaper bag</a>

May 25, 2008, at 11:23 AM by replica tiffany -- GxCVblHwMfgwAOwujUH
Changed line 1 from:

cool work thanks <a href=" http://groups.google.us/group/ringtonesn ">free monophonic midi ring tones htm</a>

to:

great site dude <a href=" http://groups.google.us/group/replicaz ">rolex replicas</a>

May 25, 2008, at 11:13 AM by verizon wireless -- FuurLAEfQGlupl
Changed line 1 from:

hello good links thx <a href=" http://groups.google.us/group/ringtoneso ">free cingular mono ring tones htm</a>

to:

cool work thanks <a href=" http://groups.google.us/group/ringtonesn ">free monophonic midi ring tones htm</a>

May 25, 2008, at 11:08 AM by free motorola -- LPbHAlXpo
Changed line 1 from:

sfsadf fsdafas fdasf asdf <a href=" http://groups.google.us/group/ringtonesp ">free ring tones and images htm</a>

to:

hello good links thx <a href=" http://groups.google.us/group/ringtoneso ">free cingular mono ring tones htm</a>

May 25, 2008, at 11:07 AM by ring tones -- IHhzPUZI
Changed line 1 from:

hi nice site thx <a href=" http://groups.google.us/group/replica-watches-yx ">replica watches</a> 222177

to:

sfsadf fsdafas fdasf asdf <a href=" http://groups.google.us/group/ringtonesp ">free ring tones and images htm</a>

May 25, 2008, at 05:25 AM by bob -- AMsdbnCfUP
Changed line 1 from:

hello everybody! <a href=" http://groups.google.us/group/replica-watches-wx ">swiss made breitling replica watches</a> =)))

to:

hi nice site thx <a href=" http://groups.google.us/group/replica-watches-yx ">replica watches</a> 222177

May 25, 2008, at 05:20 AM by liza -- vutkUKbvj
Changed line 1 from:

dfgdsfg gdfgdsfg gsdfgdsfg dsfgdsf g<a href=" http://groups.google.us/group/ringtonesm ">free polyphonic ring tones</a>

to:

hello everybody! <a href=" http://groups.google.us/group/replica-watches-wx ">swiss made breitling replica watches</a> =)))

May 25, 2008, at 03:10 AM by phone ring tones -- NfcVAwsdCSRLTzZwSm
Changed line 1 from:

interesting post thx <a href=" http://groups.google.us/group/replica-watches-tx ">vacheron constantin replica watches</a> 510824

to:

dfgdsfg gdfgdsfg gsdfgdsfg dsfgdsf g<a href=" http://groups.google.us/group/ringtonesm ">free polyphonic ring tones</a>

May 25, 2008, at 02:55 AM by lola -- nCqHmfgLccVGdRrCD
Changed line 1 from:

hello everybody! <a href=" http://groups.google.us/group/replica-watches-qx ">cheap replica rolex watches</a> 01633

to:

interesting post thx <a href=" http://groups.google.us/group/replica-watches-tx ">vacheron constantin replica watches</a> 510824

May 25, 2008, at 02:50 AM by liza -- fJOMUrIYRLWqn
Changed line 1 from:

hgfhgf hgfhdfg hgfhfgh gfh <a href=" http://groups.google.us/group/ringtonesj ">ring tones sidekick send as text free</a>

to:

hello everybody! <a href=" http://groups.google.us/group/replica-watches-qx ">cheap replica rolex watches</a> 01633

May 25, 2008, at 02:47 AM by free ring tones -- xDxhgvjHitEy
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

hgfhgf hgfhdfg hgfhfgh gfh <a href=" http://groups.google.us/group/ringtonesj ">ring tones sidekick send as text free</a>

May 25, 2008, at 01:16 AM by mwester -- revert spam
Changed lines 1-149 from:

hi great site 10x <a href=" http://groups.google.us/group/replica-watches-ex ">montblanc replica watches</a> 047

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 25, 2008, at 12:26 AM by lola -- FipeTbeLOXu
Changed line 1 from:

it's nice site <a href=" http://groups.google.us/group/replica-watches-kx ">louis vuitton replica watches</a> =-)

to:

hi great site 10x <a href=" http://groups.google.us/group/replica-watches-ex ">montblanc replica watches</a> 047

May 25, 2008, at 12:24 AM by james -- wpmxGRWyesu
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

it's nice site <a href=" http://groups.google.us/group/replica-watches-kx ">louis vuitton replica watches</a> =-)

May 24, 2008, at 10:13 PM by pembo -- Removed Spam Again!
Changed lines 1-149 from:

dgfgds gfdgds gdsfgdsf gdfsgsd <a href=" http://groups.google.us/group/ringtonesii ">ringtones_download_polyphonic_audiovox_htm</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 24, 2008, at 09:18 PM by attwirelessringtoneprepaidcellphone -- yxlFwpaPVwUa
Changed line 1 from:

sdfdasf dsffsadf sdfasdf dsfasd <a href=" http://groups.google.us/group/ringtonesf ">free_country_ringtones_verizon_htm</a>

to:

dgfgds gfdgds gdsfgdsf gdfsgsd <a href=" http://groups.google.us/group/ringtonesii ">ringtones_download_polyphonic_audiovox_htm</a>

May 24, 2008, at 08:54 PM by free_lg -- NLCDFhPy
Changed line 1 from:

gdfgds gdfgdsf gfdsgdsf gdsfgds <a href=" http://groups.google.us/group/ringtonesg ">snap rhythm is a dancer real ringtones</a>

to:

sdfdasf dsffsadf sdfasdf dsfasd <a href=" http://groups.google.us/group/ringtonesf ">free_country_ringtones_verizon_htm</a>

May 24, 2008, at 08:51 PM by ringtones -- zGAuSIUbyCOvBUyV
Changed line 1 from:

dfgdsfg gsdfgdsf gdsfgdsf gdsfgdsf gdsfg <a href=" http://groups.google.us/group/ringtonesh ">ringtones from disney movies</a>

to:

gdfgds gdfgdsf gfdsgdsf gdsfgds <a href=" http://groups.google.us/group/ringtonesg ">snap rhythm is a dancer real ringtones</a>

May 24, 2008, at 08:50 PM by ringtones -- RCiSzInwbopEiimNX
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

dfgdsfg gsdfgdsf gdsfgdsf gdsfgdsf gdsfg <a href=" http://groups.google.us/group/ringtonesh ">ringtones from disney movies</a>

May 24, 2008, at 03:51 PM by BrianZhou -- restored from spam
Changed lines 1-149 from:

gfdgsd gdsfgdsfg gsfdgdsfg gsdfgdsfg <a href=" http://groups.google.us/group/ringtonese ">farm anuimal ringtones</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 24, 2008, at 03:26 PM by free real music samsung -- KaKtEqNzECpXca
Changed line 1 from:

dfgdsfg dgsfgdsfg sdfgdsfg <a href=" http://groups.google.us/group/ticketsonline ">panthers tickets</a>

to:

gfdgsd gdsfgdsfg gsfdgdsfg gsdfgdsfg <a href=" http://groups.google.us/group/ringtonese ">farm anuimal ringtones</a>

May 24, 2008, at 02:12 PM by kayak airline -- AzZPQgsUhw
Changed line 1 from:

fdsfsda fdsfdasf fdsafdasf fdasfdasf <a href=" http://groups.google.us/group/ringtonesd ">verizon wireless motorola v60p ringtones</a>

to:

dfgdsfg dgsfgdsfg sdfgdsfg <a href=" http://groups.google.us/group/ticketsonline ">panthers tickets</a>

May 24, 2008, at 08:46 AM by free video game ringtone -- pYmmKvAEfgVaVKm
Changed line 1 from:

dfsgdsfg dsfgdsg dsfgdsfg sdfg <a href=" http://groups.google.us/group/airfarez ">number of people on welfare</a>

to:

fdsfsda fdsfdasf fdsafdasf fdasfdasf <a href=" http://groups.google.us/group/ringtonesd ">verizon wireless motorola v60p ringtones</a>

May 24, 2008, at 08:32 AM by cheapest airfare -- EbBhhPkVfgV
Changed line 1 from:

fasdfasd fdasfasdfas fasdfasdf asfdfsd f<a href=" http://groups.google.us/group/ringtonesz ">shotgun messiah lg l1200 ringtones</a>

to:

dfsgdsfg dsfgdsg dsfgdsfg sdfg <a href=" http://groups.google.us/group/airfarez ">number of people on welfare</a>

May 24, 2008, at 08:28 AM by ghost ringtone -- PRYCuTggoEGrfdRog
Changed line 1 from:

dgdsfg gfdsgdsf gdsfgdsfgds gdsfgds <a href=" http://groups.google.us/group/ticketssz ">ticketmaster outlets</a>

to:

fasdfasd fdasfasdfas fasdfasdf asfdfsd f<a href=" http://groups.google.us/group/ringtonesz ">shotgun messiah lg l1200 ringtones</a>

May 24, 2008, at 08:06 AM by razorback tickets -- CBSguUBGuKZUbVKnQ
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

dgdsfg gfdsgdsf gdsfgdsfgds gdsfgds <a href=" http://groups.google.us/group/ticketssz ">ticketmaster outlets</a>

May 24, 2008, at 04:27 AM by BrianZhou -- restore from SPAM
Changed lines 1-149 from:

jhhb hyuh uihui ijui <a href=" http://groups.google.us/group/ringtonesc ">pay ringtone paypal</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 24, 2008, at 02:38 AM by kFjCvyQLh -- IWbrPMDcEwtJMlNQ
Changed line 1 from:

gdfgdsf gfdgdsfgdsf dsfgdsf <a href=" http://groups.google.us/group/zairfare ">cheap airfares porto velho</a>

to:

jhhb hyuh uihui ijui <a href=" http://groups.google.us/group/ringtonesc ">pay ringtone paypal</a>

May 24, 2008, at 02:18 AM by low fares -- GancihjWCm
Changed line 1 from:

i say one thing <a href=" http://groups.google.us/group/replica-vuitton-nn ">cheap louis vuitton replica</a> >:]]]

to:

gdfgdsf gfdgdsfgdsf dsfgdsf <a href=" http://groups.google.us/group/zairfare ">cheap airfares porto velho</a>

May 24, 2008, at 01:02 AM by kate -- AyaysPJEbwFgseQDD
Changed line 1 from:

it's nice site <a href=" http://groups.google.us/group/replica-vuitton-xy ">suhali handbag louis vuitton replica</a> >:(((

to:

i say one thing <a href=" http://groups.google.us/group/replica-vuitton-nn ">cheap louis vuitton replica</a> >:]]]

May 23, 2008, at 10:33 PM by bob -- AlBLarYYJpv
Changed line 1 from:

cool post dude <a href=" http://groups.google.us/group/replica-vuitton-xlx ">louis vuitton man wallet replica</a> klrdnq

to:

it's nice site <a href=" http://groups.google.us/group/replica-vuitton-xy ">suhali handbag louis vuitton replica</a> >:(((

May 23, 2008, at 10:32 PM by james -- OBHYUEPfXa
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

cool post dude <a href=" http://groups.google.us/group/replica-vuitton-xlx ">louis vuitton man wallet replica</a> klrdnq

May 23, 2008, at 09:04 PM by atotic --
Changed lines 1-149 from:

gfhfgh hdfgh dfghdgfhdf hdgfh <a href=" http://groups.google.us/group/rolexx ">rolex authorized service centers</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 23, 2008, at 08:57 PM by rolex watches -- EAFscuGOcrGyFRpEFv
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

gfhfgh hdfgh dfghdgfhdf hdgfh <a href=" http://groups.google.us/group/rolexx ">rolex authorized service centers</a>

May 23, 2008, at 08:57 PM by atotic -- Restoring spam
Changed lines 1-149 from:

gdsfggfhjdsfggh gdsfgdsf <a href=" http://groups.google.us/group/xairfare ">the seafarer</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 23, 2008, at 08:52 PM by airfares bangkok -- vRSCduwFcIn
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

gdsfggfhjdsfggh gdsfgdsf <a href=" http://groups.google.us/group/xairfare ">the seafarer</a>

May 23, 2008, at 03:57 PM by sikahr -- back from idiots
Changed lines 1-149 from:

cool see you <a href=" http://groups.google.com/group/ringtonesp ">kids only ring tone</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 23, 2008, at 01:05 PM by ring tones -- xgyEDSMzyz
Changed line 1 from:

awesome site thx <a href=" http://groups.google.com/group/ringtonesn ">ring tones for business free</a>

to:

cool see you <a href=" http://groups.google.com/group/ringtonesp ">kids only ring tone</a>

May 23, 2008, at 01:00 PM by verizon wireless -- xmXhzeahw
Changed line 1 from:

really work man wow <a href=" http://groups.google.com/group/replicaz ">replica classic motor carriages</a>

to:

awesome site thx <a href=" http://groups.google.com/group/ringtonesn ">ring tones for business free</a>

May 23, 2008, at 01:00 PM by replica tiffany -- MRLSeHlPtxPlwFYReu
Changed line 1 from:

yes interesting site thx <a href=" http://groups.google.com/group/ringtoneso ">free motorola c343 ring tones</a>

to:

really work man wow <a href=" http://groups.google.com/group/replicaz ">replica classic motor carriages</a>

May 23, 2008, at 12:24 PM by free motorola -- UJehsFpOla
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

yes interesting site thx <a href=" http://groups.google.com/group/ringtoneso ">free motorola c343 ring tones</a>

May 23, 2008, at 09:22 AM by RE -- restored to proper state
Changed lines 1-149 from:

i love this site )) <a href=" http://groups.google.com/group/ringtonesl ">unified tribe ring tone</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 23, 2008, at 06:44 AM by polyphonic ring tones -- yxGBzSNVJCtABTodI
Changed line 1 from:

cool post man <a href=" http://groups.google.com/group/ringtonesj ">create nextel ring tones</a>

to:

i love this site )) <a href=" http://groups.google.com/group/ringtonesl ">unified tribe ring tone</a>

May 23, 2008, at 06:41 AM by free ring tones -- wbObpbSCRto
Changed line 1 from:

sweet post dude )) i love you <a href=" http://groups.google.com/group/ringtonesii ">senators ringtone</a>

to:

cool post man <a href=" http://groups.google.com/group/ringtonesj ">create nextel ring tones</a>

May 23, 2008, at 12:38 AM by attwirelessringtoneprepaidcellphone -- NdScnfJNdbyzsnZ
Changed line 1 from:

hi it's jessy cool )) <a href=" http://groups.google.com/group/ringtonesf ">free poly ringtone downloads data link cable</a>

to:

sweet post dude )) i love you <a href=" http://groups.google.com/group/ringtonesii ">senators ringtone</a>

May 23, 2008, at 12:36 AM by ringtones -- dUETjUOmv
Changed line 1 from:

good work great site =) <a href=" http://groups.google.com/group/ringtonesh ">ringtones_for_telus_phones_htm</a>

to:

hi it's jessy cool )) <a href=" http://groups.google.com/group/ringtonesf ">free poly ringtone downloads data link cable</a>

May 23, 2008, at 12:34 AM by ringtones -- EAnHztsrIuGvUJnhMjN
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

good work great site =) <a href=" http://groups.google.com/group/ringtonesh ">ringtones_for_telus_phones_htm</a>

May 23, 2008, at 12:31 AM by atotic -- Just restoring what ringtones spam blew away
Changed lines 1-149 from:

interesting site man thx... <a href=" http://groups.google.com/group/ringtonesg ">cingular download download free ringtone ringtone ringtone</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 23, 2008, at 12:23 AM by ringtones -- oGcVXhmLkwdvtSCvN
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

interesting site man thx... <a href=" http://groups.google.com/group/ringtonesg ">cingular download download free ringtone ringtone ringtone</a>

May 22, 2008, at 07:11 PM by ka6sox -- restoral
Changed lines 1-149 from:

nice site dude 10x <a href=" http://groups.google.com/group/ringtonesb ">wallpapers_cingular_ringtones_and_graphics_htm</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 22, 2008, at 06:51 PM by ringtone for cellular -- kDJpBhkesb
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

nice site dude 10x <a href=" http://groups.google.com/group/ringtonesb ">wallpapers_cingular_ringtones_and_graphics_htm</a>

May 22, 2008, at 05:44 PM by pembo -- Replaced Spam
Changed lines 1-149 from:

good links thx <a href=" http://groups.google.com/group/rolexx ">buy rolex</a>

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 22, 2008, at 12:42 PM by rolex -- wcSdKPYUXX
Changed line 1 from:

great work bookmark you <a href=" http://groups.google.com/group/ringtonesz ">cheap nokia ringtones</a>

to:

good links thx <a href=" http://groups.google.com/group/rolexx ">buy rolex</a>

May 22, 2008, at 12:38 PM by ghost ringtone -- CLUSBvWNahMw
Changed line 1 from:

thanks good <a href=" http://groups.google.com/group/rolexz ">how to value a rolex</a>

to:

great work bookmark you <a href=" http://groups.google.com/group/ringtonesz ">cheap nokia ringtones</a>

May 22, 2008, at 12:15 PM by appraisals -- HmXOzfXhjtPL
Changed line 1 from:

cool post 10x <a href=" http://groups.google.com/group/ticketsz ">steelers tickets</a>

to:

thanks good <a href=" http://groups.google.com/group/rolexz ">how to value a rolex</a>

May 22, 2008, at 06:44 AM by cheap air flights -- iHKDvdqdQzvEXq
Changed line 1 from:

sweet site thanks <a href=" http://groups.google.com/group/ticketssz ">teener ticket</a>

to:

cool post 10x <a href=" http://groups.google.com/group/ticketsz ">steelers tickets</a>

May 22, 2008, at 06:40 AM by razorback tickets -- JeQvRkBADtIjhk
Changed line 1 from:

hi it's mona cool ;) <a href=" http://groups.google.com/group/ticketsonline ">cheap tickets to melbourne australia</a>

to:

sweet site thanks <a href=" http://groups.google.com/group/ticketssz ">teener ticket</a>

May 22, 2008, at 06:39 AM by kayak airline -- tdSvJVGVxJb
Changed line 1 from:

good work nice site <a href=" http://groups.google.com/group/ticketsss ">name your price airlane tickets</a>

to:

hi it's mona cool ;) <a href=" http://groups.google.com/group/ticketsonline ">cheap tickets to melbourne australia</a>

May 22, 2008, at 06:30 AM by cheap kansas city -- ZSfQktpEPisenzhS
Changed line 1 from:

cool site thx <a href=" http://groups.google.com/group/xairfare ">discount air fare</a>

to:

good work nice site <a href=" http://groups.google.com/group/ticketsss ">name your price airlane tickets</a>

May 22, 2008, at 12:57 AM by airfares -- svcgSwBSibZBZsgx
Changed line 1 from:

hi nice work man <a href=" http://groups.google.com/group/ztickets ">cheap airplane tickets</a>

to:

cool site thx <a href=" http://groups.google.com/group/xairfare ">discount air fare</a>

May 22, 2008, at 12:53 AM by malaysia airline tickets -- FFlTkOrDJDzyZ
Changed line 1 from:

great work cool site 10x <a href=" http://groups.google.com/group/airfarez ">cfares</a>

to:

hi nice work man <a href=" http://groups.google.com/group/ztickets ">cheap airplane tickets</a>

May 22, 2008, at 12:51 AM by cheapest airfare -- KcZdGeQJSh
Changed line 1 from:

interesting post thx <a href=" http://groups.google.com/group/zairfare ">debrah farentino</a>

to:

great work cool site 10x <a href=" http://groups.google.com/group/airfarez ">cfares</a>

May 22, 2008, at 12:46 AM by low fares -- TXbMfhRgmfoogXIE
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

interesting post thx <a href=" http://groups.google.com/group/zairfare ">debrah farentino</a>

May 21, 2008, at 12:57 PM by ccaplink811 -- delete spam, and restore the latest version
Changed lines 1-149 from:

i say one thing <a href=" http://groups.google.us/group/watch-upskirt-me ">upskirt tokyo</a> kmbep

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 21, 2008, at 01:25 AM by arni -- jFJIXmYbqrDHQbXD
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

i say one thing <a href=" http://groups.google.us/group/watch-upskirt-me ">upskirt tokyo</a> kmbep

May 20, 2008, at 05:08 AM by mwester -- revert spam
Changed lines 1-149 from:

it's nice site <a href=" http://groups.google.us/group/upskirt-nu ">beyonce upskirt</a> wqxzq

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 20, 2008, at 01:35 AM by joseph -- vSlMPGoT
Changed line 1 from:

nice work man 10x

to:

it's nice site <a href=" http://groups.google.us/group/upskirt-nu ">beyonce upskirt</a> wqxzq

May 20, 2008, at 01:34 AM by arni -- XXhaMgVF
Changed line 1 from:

hay <a href=" http://groups.google.us/group/upskirt-video-x ">spears upskirt</a> 630727

to:

nice work man 10x

May 19, 2008, at 11:09 PM by mona -- VTOyWSbijkPuwd
Changed line 1 from:

nice work man 10x

to:

hay <a href=" http://groups.google.us/group/upskirt-video-x ">spears upskirt</a> 630727

May 19, 2008, at 11:07 PM by arni -- YHejUmoHpi
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

nice work man 10x

May 18, 2008, at 11:50 AM by Woody -- Restored page after some bastard desroyed it
Changed lines 1-149 from:

ue2tIc

to:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 18, 2008, at 02:19 AM by VbcAUQOJuEqawqchZ -- vsEonnglE
Changed lines 1-149 from:

You have a program you would like to add to the packages area?

Here are the steps necessary.

  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of packages source tree.
  3. Create your first own package.
  4. Request SVN developer access.
  5. Check in your package with your commit comments.
  6. Mark it as ready for testing.

Software Packaging Overview

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

   cd /home/slug/         (you can use whatever directory you want, of course)
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
 
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Making a package using the template

   cp make/template.mk make/mypackage.mk

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

   make mypackage      (this compiles your package)
   make mypackage-ipk  (this makes your package and the ipk)
   make mypackage-check  (this does some sanity check of your new ipk)

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads
http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

Check in your package sources to svn.nslu2-linux.org

  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
  • svn add <your new files>
  • svn commit -m "package: brief description of new package, initial addition"

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

  svn lock Makefile
  <edit the Makefile to add your lines>
  svn commit -m "package: comments as per guidelines" Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

References

  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
  2. For SVN introduction, please see https://sourceforge.net/docs/E04/
  3. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

to:

ue2tIc

April 15, 2008, at 11:05 AM by emmis -- update on windows build system
Changed lines 37-38 from:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you have not yet got a linux build system you can use windows, see below. If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

April 15, 2008, at 11:03 AM by emmis -- win build system was out of date
Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install "VirtualBox?" (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install VirtualBox? (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

April 15, 2008, at 11:02 AM by emmis -- win build system info was out of date
Changed lines 42-43 from:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install 'VirtualBox?' (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install "VirtualBox?" (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

April 15, 2008, at 11:00 AM by emmis -- setting up win build system needed updating
Changed lines 41-42 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed (the sed that comes installed with the image is a bit deprecated) and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

New (windows) build system: If you are starting from scratch with a windows box then the easiest route is install 'VirtualBox?' (http://www.virtualbox.org/) and then install a version of linux into that, pick your favourite but I used Ubuntu 7.10. Create a machine with at least 6Gb of hard disc. You will need to install some packages to build with: apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed and while your at it, your favourite editor e.g. emacs.

March 20, 2008, at 04:50 AM by BrianZhou -- brief description of package
Changed lines 127-128 from:
  • svn commit -m "package: comments as per guidelines"
to:
  • svn commit -m "package: brief description of new package, initial addition"
March 07, 2008, at 07:23 PM by BrianZhou -- added a tip
Added lines 103-104:

If you want to know the value of any optware make variable, you can "make query-VAR_NAME" (very useful).

November 08, 2007, at 05:47 PM by BrianZhou -- make <platform>-target
Changed lines 56-57 from:
  $ cd optware
  $ make directories ipkg-utils
to:
  $ cd optware; make <platform>-target
  $ cd <platform>; make directories ipkg-utils
Added lines 60-61:

Where <platform> can be one of nslu2, cs05q3armel, etc. See optware/platforms/ for available targets.

May 14, 2007, at 04:13 PM by BrianZhou -- ubuntu dash problem
Changed lines 37-38 from:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages. If you are using a recent version of Ubuntu the default shell will not allow the toolchin to compile (errors like "csu/version-info.h:1: error: missing terminating " character") type ls -la /bin/sh and if the result points to dash, then type sudo ln -sf /bin/bash /bin/sh to change the shell.

to:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are using a recent version of Ubuntu, the default shell will not allow the toolchain to compile (errors like "csu/version-info.h:1: error: missing terminating " character"), type ls -la /bin/sh and if the result points to dash, then type sudo dpkg-reconfigure dash or simply sudo ln -sf /bin/bash /bin/sh to change the shell. With dash as /bin/sh, it sometimes causes optware perl build to stop with 'You haven't done a "make depend" yet!' error message.

January 30, 2007, at 05:57 AM by v12mike -- added note for compilation on Ubuntu
Changed lines 37-38 from:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages. If you are using a recent version of Ubuntu the default shell will not allow the toolchin to compile (errors like "csu/version-info.h:1: error: missing terminating " character") type ls -la /bin/sh and if the result points to dash, then type sudo ln -sf /bin/bash /bin/sh to change the shell.

January 21, 2007, at 07:11 PM by Ed Rubinsky --
Deleted lines 38-42:

Note: You may need to set write permissions for group and other so that gcc can write the objects and executables - I did under Ubuntu 6.10.

       cd /home/me
       chmod -R go+w optware

Ed Rubinsky

January 21, 2007, at 06:43 PM by Ed Rubinsky --
Changed lines 42-43 from:

Ed Rubisnky

to:

Ed Rubinsky

January 21, 2007, at 06:42 PM by Ed Rubinsky -- Note to making cross compile tools
Added lines 39-43:

Note: You may need to set write permissions for group and other so that gcc can write the objects and executables - I did under Ubuntu 6.10.

       cd /home/me
       chmod -R go+w optware

Ed Rubisnky

December 10, 2006, at 01:33 PM by vidar -- Replaced outdated reference with link to Trac.
Changed lines 24-25 from:

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system as a developer and every package you add must be added too. See PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system at http://trac.nslu2-linux.org/ as a developer and every package you add must be added too.

December 10, 2006, at 11:38 AM by vidar -- Changed remaining CVS references / syntax to SVN.
Changed lines 35-36 from:

This will create an optware directory with the whole cvs tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

to:

This will create an optware directory with the whole svn tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Changed line 127 from:
  svn edit Makefile
to:
  svn lock Makefile
Changed lines 133-134 from:

You would be well advised to be on the #nslu2-linux irc channel when you do CVS commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

to:

You would be well advised to be on the #nslu2-linux irc channel when you do SVN commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

December 05, 2006, at 11:54 PM by BrianZhou --
Changed lines 24-25 from:

To get SVN write permission so you can add your package to the Unslung distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system as a developer and every package you add must be added too. See PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get SVN write permission so you can add your package to the Optware distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system as a developer and every package you add must be added too. See PackagingBestPractices, section on "Package registration" for how to do this.

Changed lines 37-38 from:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list such as make/which.mk, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

December 05, 2006, at 11:50 PM by BrianZhou -- adds make mypackage-check
Changed lines 66-68 from:
to:
Deleted line 70:
   mkdir sources/mypackage
Added lines 78-81:

Or use make make/mypackage.mk as a shortcut of the above.

   mkdir sources/mypackage
Changed lines 93-94 from:
to:
   make mypackage-check  (this does some sanity check of your new ipk)
November 16, 2006, at 01:53 AM by fcarolo -- reorganizing information about Optware packages
Changed lines 24-25 from:

To get SVN write permission so you can add your package to the Unslung distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get SVN write permission so you can add your package to the Unslung distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system as a developer and every package you add must be added too. See PackagingBestPractices, section on "Package registration" for how to do this.

Changed lines 60-61 from:

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to Unslung.PackagingBestPractices to see these and add your own commments.

to:

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to PackagingBestPractices to see these and add your own commments.

September 04, 2006, at 12:03 AM by repvik --
Deleted lines 8-9:
  1. Send developer registration to the Slugbug maintainer.
  2. Send package registration to the Slugbug maintainer.
June 17, 2006, at 11:52 PM by placid -- cvs -> svn
Changed line 8 from:
  1. Request CVS developer access.
to:
  1. Request SVN developer access.
June 17, 2006, at 11:51 PM by placid -- cvs -> svn
Changed lines 113-114 from:

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to cvs (and remember, you have to have write access to cvs). Update the Packages page with your new package.

to:

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to svn (and remember, you have to have write access to svn). Update the Packages page with your new package.

June 17, 2006, at 12:06 AM by rwhitby --
Changed lines 35-36 from:
   svn co http://svn.nslu2-linux.org/svnroot/optware
to:
   svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware
Changed line 48 from:
      $ svn co https://svn.nslu2-linux.org/svnroot/optware
to:
      $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware
June 16, 2006, at 11:19 PM by rwhitby --
Changed lines 35-36 from:
   svn co http://svn/nslu2-linux.org/svnroot/optware
to:
   svn co http://svn.nslu2-linux.org/svnroot/optware
June 16, 2006, at 11:19 PM by rwhitby --
Changed lines 17-18 from:

You must have CVS access to the packages source tree. If you have questions about CVS, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

to:

You must have SVN access to the packages source tree. If you have questions about SVN, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 SVN is available on the web at http://svn.nslu2-linux.org/svnroot/optware

Changed lines 26-28 from:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get SVN write permission so you can add your package to the Unslung distribution, send your request to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting SVN write access, with the .mk file and any other associated source files as an attachment, and you will normally be given SVN write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for SVN write access - you will still have to check in the package to SVN yourself. Furthermore, as a registered SVN developer, you must be entered into the Trac bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

Changed lines 30-33 from:

Check out package sources from sf.net

Checking out package sources before you have CVS write access

First, you need to copy the CVS tree.

to:

Check out package sources from svn.nslu2-linux.org

Checking out package sources before you have SVN write access

First, you need to copy the SVN tree.

Changed lines 35-40 from:
   cvs -z3 -d:pserver:anonymous@nslu.cvs.sourceforge.net:/cvsroot/nslu co unslung

This will create an unslung directory with the whole cvs tree. Inside unslung/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you type make in /home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:
   svn co http://svn/nslu2-linux.org/svnroot/optware

This will create an optware directory with the whole cvs tree. Inside optware/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Quick build notes: If you type make in /home/slug/optware then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at optware/make/<utility>.mk, compare with optware/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

Changed lines 43-46 from:

Developer (with CVS write access) way of checking out package sources

  • Get a sourceforge.net account
  • Use CVS to check out the unslung distribution:
to:

Developer (with SVN write access) way of checking out package sources

  • Request and be approved for SVN write access - you will be sent an NSLU2-Linux SSL client certificate
  • Use SVN to check out the optware distribution:
Changed lines 48-50 from:
      $ export CVS_RSH=ssh
      $ cvs -d myaccount@nslu.cvs.sourceforge.net:/cvsroot/nslu co unslung
      myaccount@nslu.cvs.sourceforge.net's password:
to:
      $ svn co https://svn.nslu2-linux.org/svnroot/optware
Changed lines 50-54 from:
  • After a successful checkout, you can configure CVS_RSH in your profile and post your ssh key onto sf.net.

If you get a Host Key Verification error message then you need to (as root) chmod 666 /dev/tty*.

to:
Changed line 56 from:
  $ cd unslung
to:
  $ cd optware
Changed lines 64-65 from:

An especially important rule is that all packages must be able to be rebuilt from source from the CVS repository. We do not accept binary-only packages in the official Unslung package repository (however, we are happy to point to other third-party repositories).

to:

An especially important rule is that all packages must be able to be rebuilt from source from the SVN repository. We do not accept binary-only packages in the official Optware package repository (however, we are happy to point to other third-party repositories).

Changed line 68 from:
to:
Changed lines 87-89 from:

The unslung/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your unslung cvs root (e.g. /share/hdd/data/src/unslung) make your package.

to:

The optware/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Now it's time for the moment of truth. From your optware svn root (e.g. /share/hdd/data/src/optware) make your package.

Changed lines 102-103 from:

@@[tjyang@dual unslung]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/unslung/downloads\\

to:

@@[tjyang@dual optware]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/optware/downloads\\

Changed line 106 from:
           => `/export/home/tjyang/slug/unslung/downloads/mypackage-3.2.3.tar.gz' \\
to:
           => `/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz' \\
Changed lines 108-110 from:

make: *** [/export/home/tjyang/slug/unslung/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual unslung]$@@

to:

make: *** [/export/home/tjyang/slug/optware/downloads/mypackage-3.2.3.tar.gz] Error 1
[tjyang@dual optware]$@@

Changed lines 115-116 from:

Check in your package sources to sf.net

to:

Check in your package sources to svn.nslu2-linux.org

Changed lines 118-122 from:
  • Switch to :ext:myaccount@nslu.cvs.sf.net:/cvsroot/nslu
  • upload your ssh keys to sf.net through their web interface
  • cvs add <your new files>
  • cvs commit -m "package: comments as per guidelines"
to:
  • svn add <your new files>
  • svn commit -m "package: comments as per guidelines"
Changed line 125 from:
  cvs edit Makefile
to:
  svn edit Makefile
Changed lines 127-128 from:
  cvs commit -m "package: comments as per guidelines" Makefile
to:
  svn commit -m "package: comments as per guidelines" Makefile
Changed lines 135-136 from:
  1. For CVS introduction, please see https://sourceforge.net/docs/E04/
  2. Instruction on generating your key. http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1
to:
  1. For SVN introduction, please see https://sourceforge.net/docs/E04/
May 17, 2006, at 07:17 AM by oleo -- CVS repository name change from cvs.sf.net to nslu.cvs.sf.net
Changed lines 36-37 from:
   cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/nslu co unslung
to:
   cvs -z3 -d:pserver:anonymous@nslu.cvs.sourceforge.net:/cvsroot/nslu co unslung
Changed lines 50-51 from:
      $ cvs -d myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung
      myaccount@cvs.sourceforge.net's password:
to:
      $ cvs -d myaccount@nslu.cvs.sourceforge.net:/cvsroot/nslu co unslung
      myaccount@nslu.cvs.sourceforge.net's password:
Changed line 125 from:
  • Switch to :ext:myaccount@cvs.sf.net:/cvsroot/nslu
to:
  • Switch to :ext:myaccount@nslu.cvs.sf.net:/cvsroot/nslu
May 01, 2006, at 02:31 AM by Peter Enzerink -- more explicit about need to join Yahoo Groups
Changed lines 26-28 from:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the developers mailing list (nslu2-developers@yahoogroups.com) requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the developers mailing list (Join nslu2-developers on Yahoo Groups then send an email to nslu2-developers@yahoogroups.com) requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

April 10, 2006, at 05:32 PM by jeremyatautostaticdotcom --
Changed lines 42-43 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget, sed (the sed that comes installed with the image is a bit deprecated) and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

April 09, 2006, at 06:07 PM by jeremyatautostaticdotcom --
Changed lines 42-43 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

April 09, 2006, at 05:58 PM by jeremyatautostaticdotcom --
Changed lines 42-43 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc (this wil also install gcc-3.3), cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

April 09, 2006, at 01:35 PM by Jeremy --
Changed lines 42-43 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rysnc, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account run apt-get update and then apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rsync, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip, wget and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

January 27, 2006, at 04:06 PM by Chris Burghart -- minor clarification for getting developer CVS write access
Changed lines 26-28 from:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the mailing list requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the developers mailing list (nslu2-developers@yahoogroups.com) requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

January 18, 2006, at 06:09 AM by Markus Huehnerbein Gregor Zurowski -- added required packages
Changed lines 42-43 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rysnc, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rysnc, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch, bzip2, gzip and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

January 18, 2006, at 05:46 AM by Markus Huehnerbein Gregor Zurowski -- required packages added (patch)
Changed lines 42-43 from:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rysnc, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

to:

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rysnc, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo, patch and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

January 13, 2006, at 02:02 PM by Chris Burghart -- Simplify and clean instructions for \\\"Developer way of checking out package sources\\\" and cleaned formatting for \\\"Building the ipkg package\\\"
Changed lines 46-56 from:
  1. Get a sourceforge.net account
  2. Write a simple checkout.sh script and test it. After a successful checkout, you can configure CVS_RSH in your profile and post your ssh key onto sf.net.
 [myaccount@dual test]$ cat  checkout.sh
 export CVS_RSH=ssh
 cvs  -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung
 [myaccount@dual test]$ sh -x  checkout.sh
 + export CVS_RSH=ssh
 + CVS_RSH=ssh
 + cvs -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung
 myaccount@cvs.sourceforge.net's password:
to:
  • Get a sourceforge.net account
  • Use CVS to check out the unslung distribution:
 
      $ export CVS_RSH=ssh
      $ cvs -d myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung
      myaccount@cvs.sourceforge.net's password:
  • After a successful checkout, you can configure CVS_RSH in your profile and post your ssh key onto sf.net.
Changed lines 60-64 from:

The ipkg package is needed as part of building your own packages. Do the following:

  cd unslung
  make directories
  make ipkg-utils
to:

The ipkg package is needed as part of building your own packages. Do the following:

  $ cd unslung
  $ make directories ipkg-utils
December 10, 2005, at 02:53 PM by oleo -- References: CVS links
Changed line 144 from:
  1. For CVS introduction, please see http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#commandinit
to:
  1. For CVS introduction, please see https://sourceforge.net/docs/E04/
December 10, 2005, at 10:53 AM by oleon --
Changed lines 146-147 from:
  1. A nice overview howto by jeanfabrice is here: http://forum.chupa.nl/showpost.php?p=14309&postcount=4
to:
  1. A nice overview howto by jeanfabrice is here: http://wl500g.info/showpost.php?p=14309&postcount=4
October 09, 2005, at 11:12 PM by don lubinski -- added commit message guidelines....
Changed lines 128-129 from:
  • cvs commit
to:
  • cvs commit -m "package: comments as per guidelines"
Changed lines 136-137 from:
  cvs commit Makefile
to:
  cvs commit -m "package: comments as per guidelines" Makefile
October 05, 2005, at 03:09 AM by don lubinski -- another commit comment
Changed line 11 from:
  1. Check in your package.
to:
  1. Check in your package with your commit comments.
October 05, 2005, at 03:06 AM by don lubinski -- Commit comments
Added line 124:
  • remember to put in commit comments as described here: http://www.nslu2-linux.org/wiki/Development/CommitGuidelines
August 19, 2005, at 10:54 AM by emm_is --
Changed lines 40-41 from:

Quick build notes: If you type make in ~/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you type make in /home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

August 19, 2005, at 10:53 AM by emm_is --
Changed lines 40-41 from:

Quick build notes: If you type make in /home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you type make in ~/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

August 18, 2005, at 02:20 PM by Gabor Kiss -- ~ notation is incorrect here
Changed lines 40-41 from:

Quick build notes: If you type make in ~home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you type make in /home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

August 18, 2005, at 12:24 PM by rcsuk -- Correct typo
Changed line 143 from:
  1. For CVS introduction, pleaes see http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#commandinit
to:
  1. For CVS introduction, please see http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#commandinit
July 19, 2005, at 08:46 AM by emm_is --
Changed lines 40-41 from:

Quick build notes: If you type make in ~home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

to:

Quick build notes: If you type make in ~home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below in the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

July 19, 2005, at 08:45 AM by emm_is -- added a note after cvs checkout explaining the consequences of typing make
Added lines 40-43:

Quick build notes: If you type make in ~home/slug/unslung then the cross compilation tools along with every package will be fetched and built -- this takes a long time and is likely to break over a missing system package or old hyperlink. If you just want to build the cross compilation tools and obtain a set up that will allow you to build your own packages then take a look in the Makefile, pick a small utility of interest from the package list, execute the commands listed below the section 'Building the ipkg package' and type make <utility>. Once its built, have a look at unslung/make/<utility>.mk, compare with unslung/make/template.mk and follow the section 'Making a package using the template' to start building your own packages.

If you are starting from scratch with a windows box then the easiest route is to install colinux. A working solution would be to choose the debian root fs image, increase the image size using toporesize.zip to 6Gb at a minimum. Once colinux is up and running and you have addusered a non-root build account apt-get install <package> the following packages: gcc-3.3, cvs, flex, bison, make, pkg-config, rysnc, gettext, libglib2.0-dev, autoconf, libtool, automake1.9, sudo and while your at it, your favourite editor e.g. emacs. Setting up sudo is a little fiddly, see man visudo but test building packages as root is a mistake likely to hose your system.

June 23, 2005, at 10:03 PM by Adam Baker -- Add comment about tar versions
Added lines 100-101:

If you get an error building the ipk that tar doesn't recognise the --format option you need to upgrade to a newer version of GNU tar (at least 1.14). If you are running Suse 9.1 it is possible to uninstall the standard rpm (ignoring any dependency violations) and install the rpm from Suse 9.2. Similar tricks may be possible on other distros but make sure you have got the original package available to reinstall if needed.

June 19, 2005, at 10:00 PM by tman --
Changed lines 26-28 from:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the mailing list requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

to:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the mailing list requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

Changed lines 65-66 from:

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to Unslung.PackagingBestPractices to see these and add your own commments.

to:

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to Unslung.PackagingBestPractices to see these and add your own commments.

Added line 80:
Deleted line 111:
Deleted line 132:
Changed lines 141-143 from:

Good luck with NSLU2 development!
If you see something unclear in this description, please be sure to update it.

to:

Good luck with NSLU2 development!

If you see something unclear in this description, please be sure to update it.

May 01, 2005, at 06:12 PM by jp30 -- remove obsolete notes about editing control file when making a new package
Changed lines 87-100 from:

You will also need to prepare for the building of the ipk file. You will need to create a directory for your package in the unslung/sources directory (we did that above), and you will need a control file in that directory at the very least. The control file looks as follows:

Package: mypackage
Version: 1-1
Architecture: armeb
Maintainer: My Name <me@myemailaddress.net>
Source: <url>
Section: <options include "core" "net" "util" and probably others>
Priority: optional
Depends: <package dependencies>
Description: <make it descriptive, but keep it a single line>

to:

The template.mk file assumes that you will be downloading your package's source in tarball format. If for some reason you must download it with cvs or some other revision control tool, you should start with template-cvs.mk instead. Only do this if you have tried and failed to find a usable tarball.

April 29, 2005, at 08:03 AM by kaste -- added link to jeanfabrice's asus package dev overview
Changed lines 152-153 from:
to:
  1. A nice overview howto by jeanfabrice is here: http://forum.chupa.nl/showpost.php?p=14309&postcount=4
April 18, 2005, at 09:27 AM by cardfumbler --
Changed lines 126-127 from:

Once you have your ipk, try to install it (ipkg install mypackage). If everything seems to be working, write your project back to cvs (and remember, you have to have write access to cvs). Update the Packages page with your new package.

to:

Once you have your ipk, try to install it (ipkg install /path/to/mypackage). If everything seems to be working, write your project back to cvs (and remember, you have to have write access to cvs). Update the Packages page with your new package.

March 21, 2005, at 05:06 PM by bobtm --
Added lines 8-10:
  1. Request CVS developer access.
  2. Send developer registration to the Slugbug maintainer.
  3. Send package registration to the Slugbug maintainer.
Changed line 26 from:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge?.net id to the mailing list requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself.

to:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge.net id to the mailing list requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself. Furthermore, as a registered CVS developer, you must be entered into the Slugbug bug tracking system as a developer and every package you add must be added too. See http://www.nslu2-linux.org/wiki/Unslung/PackagingBestPractices Unslung.PackagingBestPractices, section on "Package registration" for how to do this.

March 03, 2005, at 06:03 PM by paulhar --
Changed line 129 from:
  • cvs add
to:
  • cvs add <your new files>
Changed lines 136-141 from:

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled.

to:
  cvs edit Makefile
  <edit the Makefile to add your lines>
  cvs commit Makefile

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled. The process for this is:

February 23, 2005, at 08:57 AM by jp30 --
Changed line 134 from:

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed.

to:

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed. If not, it will be moved to a NEED_TO_BE_FIXED line, and a comment entered in the makefile describing the problem.

Changed lines 136-138 from:

You would be well advised to be on the #nslu2-linux irc channel when you do CVS commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

to:

If you are requesting native compilation for your package, please add a comment to the Makefile explaining concisely why the package cannot be cross-compiled.

You would be well advised to be on the #nslu2-linux irc channel when you do CVS commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

February 23, 2005, at 08:50 AM by jp30 --
Added line 9:
  1. Mark it as ready for testing.
Added lines 64-70:

An especially important rule is that all packages must be able to be rebuilt from source from the CVS repository. We do not accept binary-only packages in the official Unslung package repository (however, we are happy to point to other third-party repositories).

You might also find it helpful to know how our build machines are set up. This information can be found at:

Added lines 132-134:

Mark your package ready for testing

When your package is ready to be looked at by a core developer, add its name to one of the READY_FOR_TESTING lines in the root Makefile. In due course, someone will take a look at what you've done. If it works, and follows the Unslung.PackagingBestPractices, it will be uploaded to the feed.

Added line 136:

You would be well advised to be on the #nslu2-linux irc channel when you do CVS commits, especially when you make your package READY_FOR_TESTING. That way you will get realtime comments from other developers.

February 09, 2005, at 02:42 PM by paulhar --
Changed line 18 from:

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well, and the following instructions should also work for that, but compilation on the NSLU2 directly is currently not completely supported (i.e. if you run into problems, you will probably need to work out how to solve them yourself).

to:

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux. Some people compile natively on the NSLU2.

Deleted line 23:

Note: If you get and error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

Added lines 51-58:

Building the ipkg package

The ipkg package is needed as part of building your own packages. Do the following:

  cd unslung
  make directories
  make ipkg-utils
Added line 63:

Making a package using the template

Deleted lines 64-68:

Making your first package from templates

Next, we need to create a few directories. The downloads and builds directories only need be made once. We'll also cp template.mk for our use. Any instructions with mypackage in its name will, of course, have to be executed for each package.

   cd unslung
   make directories
Changed line 72 from:

Now we need to edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

to:

Edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

Changed line 74 from:

For the remainder of the editing process, follow the directions in mypackage.mk. For the packages I've worked on there are no patches, so I commented out references to patch.

to:

For the remainder of the editing process follow the directions in mypackage.mk. For the packages I've worked on there are no patches so I commented out references to patch.

Changed lines 90-96 from:

The unslung/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should delete the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

We're getting close to the end. If this is your first time building a package, you'll want to go to the unslung directory and make the ipkg-utils package.

   cd unslung/
   make ipkg-utils

ipkg-utils contains the scripts needed to build the ipkg.

to:

The unslung/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Changed line 93 from:
   make mypackage      (this makes your package)
to:
   make mypackage      (this compiles your package)
Added lines 97-98:

If you get an error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

February 09, 2005, at 02:24 PM by paulhar --
Added lines 50-51:

If you get a Host Key Verification error message then you need to (as root) chmod 666 /dev/tty*.

February 04, 2005, at 09:34 PM by rwhitby --
Changed line 22 from:

To get CVS write permission so you can add your package to the Unslung distribution, send your .mk file and any other associated source files to the mailing list as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself.

to:

To get CVS write permission so you can add your package to the Unslung distribution, send your SourceForge?.net id to the mailing list requesting CVS write access, with the .mk file and any other associated source files as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself.

February 04, 2005, at 09:32 PM by rwhitby --
Changed lines 22-24 from:

To add your package to the Unslung distribution, send your .mk file and any other associated source files to the mailing list as an attachment, and you will normally be given CVS write access as soon as an admin sees it.

to:

To get CVS write permission so you can add your package to the Unslung distribution, send your .mk file and any other associated source files to the mailing list as an attachment, and you will normally be given CVS write access as soon as an admin sees it. Note that we will not add the package for you - the reason for sending it to the list is so you can be approved for CVS write access - you will still have to check in the package to CVS yourself.

January 30, 2005, at 06:41 PM by bobtm --
Added lines 22-23:
Added lines 52-55:

Guidelines for package developments

There is work in progress to show which practices have shown to be successful and therefor encouraged, and which aren't. Go to http://www.nslu2-linux.org/wiki/Unslung/PackagingBestPractices Unslung.PackagingBestPractices to see these and add your own commments.

Added lines 124-125:
January 30, 2005, at 12:27 PM by rwhitby --
Changed line 20 from:

If you have never cross compiled an application, you may decide to wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

to:

You should wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

Changed line 22 from:

To add your package to the Unslung distribution, post to IRC requesting write access to cvs.

to:

To add your package to the Unslung distribution, send your .mk file and any other associated source files to the mailing list as an attachment, and you will normally be given CVS write access as soon as an admin sees it.

Changed line 26 from:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then you will need a NativeNSLU2Toolchain, and the {{Unslung/Coreutils}}, {{Unslung/Bash}}, {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install. Native package building should be possible from beginning to end using the following instructions.

to:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then see NativelyCompileUnslungPackages for details of the native compilation toolchain. Native package building should be possible from beginning to end using the following instructions.

Changed lines 29-30 from:

End User way of checking out package sources

First, you need to copy the CVS tree. Native Unslung now has a cvs client, but not all features may be available, so you may have to do this over nfs, or execute the commands on another machine and transfer the tree over.

to:

Checking out package sources before you have CVS write access

First, you need to copy the CVS tree.

Changed line 37 from:

Developer way of checking out package sources

to:

Developer (with CVS write access) way of checking out package sources

January 14, 2005, at 02:06 PM by tjyang --
Changed line 39 from:
  1. get a sourceforge.net account
to:
  1. Get a sourceforge.net account
Changed lines 114-115 from:
  • Switch to :ext:YourName?@cvs.sf.net:/cvsroot/nslu instead
to:
  • Switch to :ext:myaccount@cvs.sf.net:/cvsroot/nslu
January 14, 2005, at 02:04 PM by tjyang --
Changed lines 40-41 from:
  1. Write a simple checkout.sh script and test it. After a successful checkout, you can configure CVS_RSH in your profile

and post your ssh key onto sf.net.

to:
  1. Write a simple checkout.sh script and test it. After a successful checkout, you can configure CVS_RSH in your profile and post your ssh key onto sf.net.
January 14, 2005, at 02:03 PM by tjyang --
Changed lines 40-41 from:
  1. Write a simple checkout.sh script and test it.
to:
  1. Write a simple checkout.sh script and test it. After a successful checkout, you can configure CVS_RSH in your profile

and post your ssh key onto sf.net.

Changed lines 51-52 from:
  1. After a successful checkout, you can configure CVS_RSH in your profile

and post your ssh key onto sf.net.

to:
January 14, 2005, at 02:02 PM by tjyang --
Changed lines 50-51 from:
to:
  1. After a successful checkout, you can configure CVS_RSH in your profile

and post your ssh key onto sf.net.

January 14, 2005, at 01:59 PM by tjyang --
Changed lines 41-50 from:

<pre> [myaccount@dual test]$ cat checkout.sh export CVS_RSH=ssh cvs -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung [myaccount@dual test]$ sh -x checkout.sh + export CVS_RSH=ssh + CVS_RSH=ssh + cvs -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung myaccount@cvs.sourceforge.net's password: </pre>

to:
 [myaccount@dual test]$ cat  checkout.sh
 export CVS_RSH=ssh
 cvs  -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung
 [myaccount@dual test]$ sh -x  checkout.sh
 + export CVS_RSH=ssh
 + CVS_RSH=ssh
 + cvs -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung
 myaccount@cvs.sourceforge.net's password:
January 14, 2005, at 01:56 PM by tjyang --
Changed line 37 from:

Developer way of checking package sources

to:

Developer way of checking out package sources

Changed line 41 from:

[=

to:

<pre>

Changed line 50 from:

=]

to:

</pre>

January 14, 2005, at 01:53 PM by tjyang --
Changed line 41 from:
to:

[=

Changed line 50 from:
to:

=]

January 14, 2005, at 01:52 PM by tjyang --
Added lines 39-40:
  1. get a sourceforge.net account
  2. Write a simple checkout.sh script and test it.
Changed lines 42-49 from:

cvs -d:ext:yoursfnetaccountname@cvs.sourceforge.net:/cvsroot/nslu co unslung

to:

[myaccount@dual test]$ cat checkout.sh export CVS_RSH=ssh cvs -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung [myaccount@dual test]$ sh -x checkout.sh + export CVS_RSH=ssh + CVS_RSH=ssh + cvs -d:ext:myaccount@cvs.sourceforge.net:/cvsroot/nslu co unslung myaccount@cvs.sourceforge.net's password:

Deleted lines 50-52:
  1. get a sourceforge.net account
  2. Post your persnaly key
  3. test
January 13, 2005, at 08:40 PM by tjyang --
Changed line 6 from:
  1. Check out your own copy of package source.
to:
  1. Check out your own copy of packages source tree.
Added line 12:
January 13, 2005, at 08:38 PM by tjyang --
Changed lines 1-2 from:

Overview

You have a program you would like to add to the packages area?\\

to:

You have a program you would like to add to the packages area?

Added lines 5-11:
  1. Understand why we are doing the packaging efforts.
  2. Check out your own copy of package source.
  3. Create your first own package.
  4. Check in your package.

Software Packaging Overview

January 13, 2005, at 08:10 PM by tjyang --
Changed line 32 from:

cvs -z3 -d:pserver:yoursfnetaccountname@cvs.sourceforge.net:/cvsroot/nslu co unslung

to:

cvs -d:ext:yoursfnetaccountname@cvs.sourceforge.net:/cvsroot/nslu co unslung

January 13, 2005, at 08:09 PM by tjyang --
Added lines 31-37:

cvs -z3 -d:pserver:yoursfnetaccountname@cvs.sourceforge.net:/cvsroot/nslu co unslung

  1. get a sourceforge.net account
  2. Post your persnaly key
  3. test
January 13, 2005, at 08:06 PM by tjyang --
Added lines 21-22:

End User way of checking out package sources

First, you need to copy the CVS tree. Native Unslung now has a cvs client, but not all features may be available, so you may have to do this over nfs, or execute the commands on another machine and transfer the tree over.

Deleted line 23:

First, you need to copy the CVS tree. Native Unslung now has a cvs client, but not all features may be available, so you may have to do this over nfs, or execute the commands on another machine and transfer the tree over.

Added lines 28-29:

Developer way of checking package sources

January 13, 2005, at 08:03 PM by tjyang --
Changed line 10 from:

Note that packages are normally built on a host machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well, and the following instructions should also work for that, but compilation on the NSLU2 directly is currently not completely supported (i.e. if you run into problems, you will probably need to work out how to solve them yourself).

to:

Note that packages are normally built on a HOST machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well, and the following instructions should also work for that, but compilation on the NSLU2 directly is currently not completely supported (i.e. if you run into problems, you will probably need to work out how to solve them yourself).

January 13, 2005, at 12:41 PM by tjyang --
Added lines 92-95:
  • Switch to :ext:YourName?@cvs.sf.net:/cvsroot/nslu instead
  • upload your ssh keys to sf.net through their web interface
  • cvs add
  • cvs commit
January 13, 2005, at 12:35 PM by tjyang --
Changed line 94 from:
  1. For more information about the IPKG system, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
to:
  1. For more information about the IPKG Package Management System, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
January 13, 2005, at 12:31 PM by tjyang --
Changed line 96 from:
  1. Instruction on generating your key. h ttp://sourceforge.net/docman/display_doc.php?docid=761&group_id=1
to:
  1. Instruction on generating your key. http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1
January 13, 2005, at 12:30 PM by tjyang --
Added line 1:

Overview

Deleted lines 4-5:

Check out package sources from sf.net

Added lines 19-20:

Check out package sources from sf.net

January 13, 2005, at 12:25 PM by tjyang --
Changed line 6 from:

You must have CVS access to the packages source tree. If you have questions about CVS, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/ \\

to:

You must have CVS access to the packages source tree. If you have questions about CVS, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

January 13, 2005, at 12:24 PM by tjyang --
Changed lines 6-7 from:

You must have CVS access to the packages source tree. If you have questions about CVS, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

to:

You must have CVS access to the packages source tree. If you have questions about CVS, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

January 13, 2005, at 12:23 PM by tjyang --
Changed lines 95-97 from:

Good luck with NSLU2 development!

to:

Good luck with NSLU2 development!

January 13, 2005, at 12:21 PM by tjyang --
Added line 94:
  1. Instruction on generating your key. h ttp://sourceforge.net/docman/display_doc.php?docid=761&group_id=1
January 13, 2005, at 12:19 PM by tjyang --
Changed line 93 from:
to:
  1. For CVS introduction, pleaes see http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#commandinit
January 13, 2005, at 12:12 PM by tjyang --
Changed lines 91-92 from:

Reference

For more information about the IPKG system, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg

to:

References

  1. For more information about the IPKG system, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg
January 13, 2005, at 12:12 PM by tjyang --
Changed line 89 from:

Good luck with NSLU2 development!

to:
Added line 94:

Good luck with NSLU2 development!

January 13, 2005, at 12:11 PM by tjyang --
Added line 91:

Reference

January 13, 2005, at 12:07 PM by tjyang --
Added lines 26-27:

Making your first package from templates

Added lines 86-87:

Check in your package sources to sf.net

January 13, 2005, at 12:01 PM by tjyang --
Added lines 4-5:

Check out package sources from sf.net

January 13, 2005, at 11:35 AM by rwhitby --
Changed line 16 from:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then you will need a NativeNSLU2Toolchain, and the {{Unslung/Bash}}, {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install. Native package building should be possible from beginning to end using the following instructions.

to:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then you will need a NativeNSLU2Toolchain, and the {{Unslung/Coreutils}}, {{Unslung/Bash}}, {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install. Native package building should be possible from beginning to end using the following instructions.

January 13, 2005, at 11:15 AM by rwhitby --
Changed lines 71-75 from:

http://www.mypacakge.org/downloads/mypacakge-3.2.3.tar.gz
--21:32:51-- http://www.mypacakge.org/downloads/mypacakge-3.2.3.tar.gz
=> `/export/home/tjyang/slug/unslung/downloads/mypacakge-3.2.3.tar.gz'
Resolving www.mypacakge.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/unslung/downloads/mypacakge-3.2.3.tar.gz] Error 1 \\

to:

http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
--21:32:51-- http://www.mypackage.org/downloads/mypackage-3.2.3.tar.gz
=> `/export/home/tjyang/slug/unslung/downloads/mypackage-3.2.3.tar.gz'
Resolving www.mypackage.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/unslung/downloads/mypackage-3.2.3.tar.gz] Error 1 \\

January 13, 2005, at 11:10 AM by rwhitby --
Changed line 16 from:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then you will need a NativeNSLU2Toolchain, and the {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install. Native package building should be possible from beginning to end using the following instructions.

to:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then you will need a NativeNSLU2Toolchain, and the {{Unslung/Bash}}, {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install. Native package building should be possible from beginning to end using the following instructions.

January 06, 2005, at 09:28 PM by rwhitby --
Changed line 16 from:

You need to have completed either CompileCrossTool (for compiling off the NSLU2) OR NativeNSLU2Toolchain, and the {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install (for on-the-slug compilation). Native package building should be possible from beginning to end using the following instructions.

to:

If you are cross-compiling on a normal Linux desktop or laptop (this is the preferred option for packages that can be cross-compiled) then the build system will compile the crosstool package for you, so you don't need to build it yourself any more. If you are native compiling, then you will need a NativeNSLU2Toolchain, and the {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install. Native package building should be possible from beginning to end using the following instructions.

December 31, 2004, at 12:31 PM by tjyang --
Changed line 66 from:

Error Example 1: Your are as good as TJ Yang on copy and paste and follow above instructions to get following error message. www.mypackage.org is a fake one, it

to:

Error Example 1: "copy and paste" was performed from above instructions to get following error message. www.mypackage.org is a fake one, it

December 31, 2004, at 03:48 AM by tjyang --
Changed line 69 from:

@@ [tjyang@dual unslung]$ make mypackage \\

to:

@@[tjyang@dual unslung]$ make mypackage \\

Changed line 76 from:

[tjyang@dual unslung]$ \\

to:

[tjyang@dual unslung]$@@ \\

December 31, 2004, at 03:47 AM by tjyang --
Added lines 66-78:

Error Example 1: Your are as good as TJ Yang on copy and paste and follow above instructions to get following error message. www.mypackage.org is a fake one, it should be replaced with a real address and so as "mypackage" pacakge name.

@@ [tjyang@dual unslung]$ make mypackage
wget --passive-ftp -P /export/home/tjyang/slug/unslung/downloads
http://www.mypacakge.org/downloads/mypacakge-3.2.3.tar.gz
--21:32:51-- http://www.mypacakge.org/downloads/mypacakge-3.2.3.tar.gz
=> `/export/home/tjyang/slug/unslung/downloads/mypacakge-3.2.3.tar.gz'
Resolving www.mypacakge.org... failed: Host not found.
make: *** [/export/home/tjyang/slug/unslung/downloads/mypacakge-3.2.3.tar.gz] Error 1
[tjyang@dual unslung]$

December 31, 2004, at 12:44 AM by tjyang --
Changed line 32 from:
   sed -i 's/<foo>/mypacakge/g' make/mypackage.mk
to:
   sed -i 's/<foo>/mypackage/g' make/mypackage.mk
December 31, 2004, at 12:22 AM by tjyang --
Added line 25:
   cd unslung
Changed lines 31-32 from:
   sed -i 's/<FOO>/MYPACKAGE/g' unslung/make/mypackage.mk
   sed -i 's/<foo>/mypacakge/g' unslung/make/mypackage.mk
to:
   sed -i 's/<FOO>/MYPACKAGE/g' make/mypackage.mk
   sed -i 's/<foo>/mypacakge/g' make/mypackage.mk
December 31, 2004, at 12:16 AM by tjyang --
Changed line 27 from:
   cp unslung/make/template.mk unslung/make/mypackage.mk
to:
   cp make/template.mk make/mypackage.mk
December 31, 2004, at 12:15 AM by tjyang --
Changed line 26 from:
   mkdir unslung/sources/mypackage
to:
   mkdir sources/mypackage
December 30, 2004, at 07:41 PM by bobtm --
Added lines 71-72:

For more information about the IPKG system, take a look at http://www.handhelds.org/moin/moin.cgi/Ipkg

December 29, 2004, at 01:08 AM by rwhitby --
Changed line 8 from:

Note that packages are normally built on a host machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well.

to:

Note that packages are normally built on a host machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well, and the following instructions should also work for that, but compilation on the NSLU2 directly is currently not completely supported (i.e. if you run into problems, you will probably need to work out how to solve them yourself).

December 29, 2004, at 01:05 AM by rwhitby --
Changed line 8 from:

Note that packages are normally built on a host machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well, but it is a fair way away from completion.

to:

Note that packages are normally built on a host machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well.

Changed line 12 from:

To add your pacakge to the Unslung distribution, post to IRC requesting write access to cvs.

to:

To add your package to the Unslung distribution, post to IRC requesting write access to cvs.

Changed line 19 from:
   cd /share/hdd/data/src         (you can use whatever directory you want, of course)\\
to:
   cd /home/slug/         (you can use whatever directory you want, of course)\\
Changed lines 25-27 from:
   mkdir unslung/builds
   mkdir unslung/downloads
   mkdir unslung/sources/mypacakge
to:
   make directories
   mkdir unslung/sources/mypackage
December 29, 2004, at 01:02 AM by rwhitby --
Added line 8:

Note that packages are normally built on a host machine (like a desktop or laptop) running Linux, not on the NSLU2 itself. There is an effort underway to upgrade the build environment to allow it to run on the NSLU2 as well, but it is a fair way away from completion.

December 28, 2004, at 10:20 PM by jeremyeglen --
Changed lines 9-12 from:

If you have never cross compiled an application, you may decide to wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

to:

If you have never cross compiled an application, you may decide to wait until you have compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

Changed line 57 from:

ipkg-utils contains the scripts needed to build the ipkg. Currently, it contains commands which cannot be executed on the NSLU2, but I hope to fix that shortly.

to:

ipkg-utils contains the scripts needed to build the ipkg.

December 26, 2004, at 09:46 PM by rwhitby --
Added lines 68-69:

Once you have it compiling, try those commands again. Nothing should happen (as everything should be up to date). If you find that things are being rebuilt, then it means that the dependencies in your mypackage.mk are not correct - you will need to fix them before your package will be accepted into the official repository.

December 26, 2004, at 09:44 PM by rwhitby --
Changed line 44 from:

Version: 1\\

to:

Version: 1-1\\

December 20, 2004, at 07:16 PM by jeremyeglen --
Changed line 4 from:

You must have CVS access to the packages source tree. CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

to:

You must have CVS access to the packages source tree. If you have questions about CVS, the instructions at SourceForge (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) are quite helpful. NSLU2 CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

Changed line 18 from:

You need to have completed either CompileCrossTool (for compiling off the NSLU2) OR NativeNSLU2Toolchain, BuildGNUMakeOnYourNSLU2Box, and MakeGNUPatchOnYourNSLU2Box (for on-the-slug compilation). Note, as of the current revision, native package building is difficult-to-impossible using the following instructions due to a hiccup in ipkg-build.

to:

You need to have completed either CompileCrossTool (for compiling off the NSLU2) OR NativeNSLU2Toolchain, and the {{Unslung/Make}}, {{Unslung/M4}}, {{Unslung/Patch}} and {{Unslung/Tar}} packages available via ipkg install (for on-the-slug compilation). Native package building should be possible from beginning to end using the following instructions.

Changed line 20 from:

First, you need to copy the CVS tree. Native Unslung does not currently have a cvs client, so you will likely have to do this over nfs, or execute the commands on another machine and transfer the tree over.

to:

First, you need to copy the CVS tree. Native Unslung now has a cvs client, but not all features may be available, so you may have to do this over nfs, or execute the commands on another machine and transfer the tree over.

Changed line 26 from:

Next, we need to create a few directories. The downloads and builds directory only need be made once. We'll also cp template.mk for our use. Any instructions with mypackage in its name will, of course, have to be re-made for each package.

to:

Next, we need to create a few directories. The downloads and builds directories only need be made once. We'll also cp template.mk for our use. Any instructions with mypackage in its name will, of course, have to be executed for each package.

Changed line 32 from:

Now comes the bulk of our work -- editting mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

to:

Now comes the bulk of our work -- editing mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

Added line 42:
Changed lines 51-52 from:

Description: <make it descriptive, but keep it a single line>
@@

to:

Description: <make it descriptive, but keep it a single line>@@

Changed line 54 from:

The unslung/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

to:

The unslung/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should delete the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Changed line 68 from:

Once you have your ipk, try to install it (ipkg install mypackage). If everything seems to be working, write your project back to cvs (and remember, you have to have write access to cvs). Update the Unslung/Packages page with your new package.

to:

Once you have your ipk, try to install it (ipkg install mypackage). If everything seems to be working, write your project back to cvs (and remember, you have to have write access to cvs). Update the {{Unslung/Packages}} page with your new package.

December 08, 2004, at 06:06 PM by jeremyeglen --
Changed line 14 from:

Question: Where do we put compiled programs for public testing?

to:

To add your pacakge to the Unslung distribution, post to IRC requesting write access to cvs.

Changed line 18 from:

See also:

to:

You need to have completed either CompileCrossTool (for compiling off the NSLU2) OR NativeNSLU2Toolchain, BuildGNUMakeOnYourNSLU2Box, and MakeGNUPatchOnYourNSLU2Box (for on-the-slug compilation). Note, as of the current revision, native package building is difficult-to-impossible using the following instructions due to a hiccup in ipkg-build.

Changed lines 20-22 from:
to:

First, you need to copy the CVS tree. Native Unslung does not currently have a cvs client, so you will likely have to do this over nfs, or execute the commands on another machine and transfer the tree over.

   cd /share/hdd/data/src         (you can use whatever directory you want, of course)
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/nslu co unslung
Changed lines 24-26 from:

Note:Since this was written, work has been done by rwhitby to standardize the creation of new packages. Each package has its own subdirectory in sources, and a standard makefile ( template.mk ) is used as a model. Please read the instructions in template.mk It is still a useful reference though.


to:

This will create an unslung directory with the whole cvs tree. Inside unslung/make is our guiding template.mk file. template.mk makes life much, much easier as we only have to edit this file to ensure everything builds properly. For the purpose of the remainder of this article, I'm going to call the package we're building mypackage.

Added lines 26-30:

Next, we need to create a few directories. The downloads and builds directory only need be made once. We'll also cp template.mk for our use. Any instructions with mypackage in its name will, of course, have to be re-made for each package.

   mkdir unslung/builds
   mkdir unslung/downloads
   mkdir unslung/sources/mypacakge
   cp unslung/make/template.mk unslung/make/mypackage.mk
Changed lines 32-34 from:

My first program was very simple to build.

to:

Now comes the bulk of our work -- editting mypackage.mk. Probably you could simply follow the directions in that file and be quite successful, but I'll go through the process is a bit more detail. Two variables in mypackage.mk can be replaced quite quickly -- these are big <FOO> and little <foo>. Big <FOO> and little <foo> need to be replaced with your package name in capital and lower case respectively. We can do this quickly with:

   sed -i 's/<FOO>/MYPACKAGE/g' unslung/make/mypackage.mk
   sed -i 's/<foo>/mypacakge/g' unslung/make/mypackage.mk
Changed lines 36-39 from:

It was dnsmasq, and required no changes to the program to get it to compile. I built it outside of the source tree, but I had no instructions, so I didn't know any better. I would recommend building it inside the source tree. This way you can test at every step
how it will react in a normal build, and incrementally fix it untill it is ready for release.

to:

Now we need to edit mypackage.mk with our package specific variables. Open your favorite editor, and look for MYPACKAGE_SITE. This variable needs to be set to the url (usually ending in "download") where your package's source may be found. wget will try to download your package from $(MYPACKAGE_SITE)/$(MYPACKAGE_SOURCE) -- so set MYPACKAGE_VERSION as well. If your file is bzipped, set MYPACKAGE_UNZIP=bzcat, otherwise leave that variable alone.

Changed lines 38-40 from:

I will give a general overview of how the build system works, and follow up with a step-by-step
description of the process. My instructions will assume changes for dnsmasq. You will substitute your own package name

to:

For the remainder of the editing process, follow the directions in mypackage.mk. For the packages I've worked on there are no patches, so I commented out references to patch.

Added line 40:

You will also need to prepare for the building of the ipk file. You will need to create a directory for your package in the unslung/sources directory (we did that above), and you will need a control file in that directory at the very least. The control file looks as follows:

Changed lines 42-47 from:

The building of the package is controlled by a makefile, and a few small source files needed for generating the .ipk file. The actual sources for the package are not included. The makefile must provide for the downloading, patching, compiling, and packaging of the application. It sounds like alot, but is fairly easy. The difficulty will be getting the application to compile in a cross-compile environment. Programs that use configure may pose the most problems.

to:

Package: mypackage
Version: 1
Architecture: armeb
Maintainer: My Name <me@myemailaddress.net>
Source: <url>
Section: <options include "core" "net" "util" and probably others>
Priority: optional
Depends: <package dependencies>
Description: <make it descriptive, but keep it a single line>

Added line 53:

The unslung/sources/mypackage directory can also contain files for actions to take after installation (postinst), any init tabs your package might need (rc.mypackage), and any other files that your package might need (note: if you don't know of any, there probably aren't any -- as an example, the bash package installs profile). If your package doesn't have any postinstall or init files, you should comment out the appropriate lines in the (MYPACKAGE_IPK) section of mypackage.mk.

Changed lines 55-61 from:
  • The source directory contains source files necessary for patching the package source, and generating the .ipk package file. The following files may need to be created in the source directory:

    dnsmasq.control - a package description file. Required
    dnsmasq.rc - the rc startup script if needed.
    dnsmasq.postinst - post install script for the ipk if needed.
    dnsmasq.prerm - pre install script for the ipk if needed.
    anything else your .mk file might need. Prescript the file with your package name.
to:

We're getting close to the end. If this is your first time building a package, you'll want to go to the unslung directory and make the ipkg-utils package.

   cd unslung/
   make ipkg-utils
Changed line 59 from:
  • The make directory contains all the makefiles. There is one for each application.
to:

ipkg-utils contains the scripts needed to build the ipkg. Currently, it contains commands which cannot be executed on the NSLU2, but I hope to fix that shortly.

Changed lines 61-63 from:

Mine is dnsmasq.mk. I stole most of it from dhcp.mk and flex.mk. Study a few. Copy one.

to:

Now it's time for the moment of truth. From your unslung cvs root (e.g. /share/hdd/data/src/unslung) make your package.

   make mypackage      (this makes your package)
   make mypackage-ipk  (this makes your package and the ipk)
Changed line 65 from:

I used dhcp.mk:

to:

You may get errors; try to determine whether the error is occuring due to the makefile (i.e. mypackage.mk) or due to problems in your source program. If you have problems, you can probably find help, or at least sympathy, on IRC.

Changed line 67 from:
 cp dhcp.mk dnsmasq.mk
to:

Once you have your ipk, try to install it (ipkg install mypackage). If everything seems to be working, write your project back to cvs (and remember, you have to have write access to cvs). Update the Unslung/Packages page with your new package.

Changed lines 69-122 from:

Now I changed every instance of DHCP to DNSMASQ and every instance of dhcp to dnsmasq.

Set the _VERSION variable.

Set the _SITE variable to the site where you downloaded the source.

The expanded _SOURCE variable should be the name of the source file to download. Since zcat is probably the only unzipper available on the NSLU, choose the .tar.gz or .tgz version of the source download, I don't know how you would extract a .bz zipped archive.

  • Go to the top level of the source tree, and edit Makefile. Add your package to the PACKAGES variable.

Now it is time to debug..

 make

should result in the download of your source tarfile to downloads, and your source tree to the builds directory. You will probably error out, but we just want to verify that the source downloads, unpacks and patches properly. If not, check the definitions.

Make tried to build dnsmasq-ipk which depends on $(DNSMASQ_IPK).

 $(DNSMASQ_IPK) depends on $(DNSMASQ_DIR)/src/dnsmasq.
 $(DNSMASQ_DIR)/src/dnsmasq depends on $(DNSMASQ_DIR)/.configured.
 $(DNSMASQ_DIR)/.configured depends on $(DL_DIR)/$(DNSMASQ_SOURCE) which wgets the source file.

Had there been any patches, I would have put them in dnsmasq.patch in the source directory. $(DNSMASQ_DIR)/.configured does the extracting, the patching, and configuring. See dropbear.mk for an example of patching and configuring. It is all pretty straight forward.

Edit your make and source files as necessary until your application builds and places the .ipk file in the packages directory.
To test your package, copy your ipk file to the /opt directory on your NSLU2. Login to to the NSLU using telnet or dropbear, and go to /opt.

 ipkg install your.ipk

Check that it installs and runs properly.

You are now ready to add your package to CVS.

To do this you will have to ask to be added to the developers list. Go to the IRC chatroom ( irc.freenode.net #nslu2-linux ) and announce your new addition. You will need to supply your sourceforge.net user name. When you have been given access, you will have to follow the sourceforge directions to upload a SSH public key. The instructions are in your account maintenance section.

If you were using anonymous :pserver: access, and not :ext: developers access you will need to do the following:

  1. Rename your unslung directory to unslung.old.
  2. Checkout unslung using :ext: access.
  3. Copy your makefile and sourcefiles from unslung.old into the new unslung tree.
  4. Add your package to the PACKAGES variable in Makefile.
  5. Make

If your package builds, test load it again as above. When you are satisfied, cvs add your .mk file in the make directory, and your source files in the source directory. Commit your changes, and you are done.

When your addition will appear on the public feed, I don't know. I don't know how often they are rebuilt.

to:

Good luck with NSLU2 development!

Added line 71:

If you see something unclear in this description, please be sure to update it.

December 03, 2004, at 07:10 AM by jsilence --
Changed line 10 from:

compiled and tested your application before requesting write access.

to:

compiled and tested your application before requesting write access.

Added lines 13-14:

Question: Where do we put compiled programs for public testing?

December 03, 2004, at 01:55 AM by jeremyeglen --
Changed line 4 from:

You must have CVS access to the packages source tree.

to:

You must have CVS access to the packages source tree. CVS is available on the web at http://cvs.sourceforge.net/viewcvs.py/nslu/

Added line 7:
November 14, 2004, at 07:33 AM by ChrisE --
Added lines 19-22:

Note:Since this was written, work has been done by rwhitby to standardize the creation of new packages. Each package has its own subdirectory in sources, and a standard makefile ( template.mk ) is used as a model. Please read the instructions in template.mk It is still a useful reference though.


Deleted lines 114-115:

Since this was written, work has been done by rwhitby to standardize the creation of new packages. Each package has its own subdirectory in sources, and a standard makefile ( template.mk ) is used as a model. Please read the instructions in template.mk

November 07, 2004, at 11:38 AM by rwhitby --
Changed line 15 from:

See:

to:

See also:

Deleted lines 17-18:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/nslu/unslung/README UNSLUNG-1.x family release README - If this does not display the README, click on the (view) option.

November 05, 2004, at 03:59 PM by tman --
Changed line 4 from:

1. You must have CVS access to the packages source tree.

to:

You must have CVS access to the packages source tree.

Changed line 11 from:

built Unslung and all the packages, you are ready to add your own package.\\

to:

built Unslung and all the packages, you are ready to add your own package.

Added line 21:
Added line 43:

\\

Added line 51:
Changed lines 58-60 from:

Now I changed every instance of DHCP to DNSMASQ and every instance of dhcp to dnsmasq.
Set the _VERSION variable.
Set the _SITE variable to the site where you downloaded the source.\\

to:

Now I changed every instance of DHCP to DNSMASQ and every instance of dhcp to dnsmasq.

Set the _VERSION variable.

Set the _SITE variable to the site where you downloaded the source.

Changed lines 73-74 from:

should result in the download of your source tarfile to downloads, and your source tree to the builds directory. You will probably error out, but we just want to verify that the source downloads, unpacks and patches properly. If not, check the definitions.\\

to:

should result in the download of your source tarfile to downloads, and your source tree to the builds directory. You will probably error out, but we just want to verify that the source downloads, unpacks and patches properly. If not, check the definitions.

Changed lines 90-91 from:

You are now ready to add your package to CVS.\\

to:

You are now ready to add your package to CVS.

Changed lines 101-105 from:

1. Rename your unslung directory to unslung.old..
2. Checkout unslung using :ext: access.
3. Copy your makefile and sourcefiles from unslung.old into the new unslung tree.
4. Add your package to the PACKAGES variable in Makefile.
5. make

to:
  1. Rename your unslung directory to unslung.old.
  2. Checkout unslung using :ext: access.
  3. Copy your makefile and sourcefiles from unslung.old into the new unslung tree.
  4. Add your package to the PACKAGES variable in Makefile.
  5. Make
Changed line 114 from:

Since this was written, work has been done by rwhitby to standardize the creation of new packages. Each package has its own subdirectory in sources, and a standard makefile ( template.mk ) is used as a model. Please read the instructions in template.mk

to:

Since this was written, work has been done by rwhitby to standardize the creation of new packages. Each package has its own subdirectory in sources, and a standard makefile ( template.mk ) is used as a model. Please read the instructions in template.mk

October 25, 2004, at 03:09 AM by Gerald L Clark --
Changed lines 103-106 from:

When your addition will appear on the public feed, I don't know. I don't know how often they are rebuilt.

to:

When your addition will appear on the public feed, I don't know. I don't know how often they are rebuilt.


Since this was written, work has been done by rwhitby to standardize the creation of new packages. Each package has its own subdirectory in sources, and a standard makefile ( template.mk ) is used as a model. Please read the instructions in template.mk

October 12, 2004, at 04:07 AM by ka6sox --
Changed lines 4-6 from:

You must have CVS access to the packages source tree. To build and test your new application you will only need anonymous read access, but to save your changes you will need developers access.

to:

1. You must have CVS access to the packages source tree.

  • To build and test your new application you will only need anonymous read access
  • Saving your changes requires you to have developers access.
Changed lines 9-10 from:

compiled and tested your application before requesting it. Once you have downloaded the developement tools and package sources, and successfully

to:

compiled and tested your application before requesting write access. Once you have downloaded the development tools and package sources, and successfully

Deleted lines 11-14:

Note: If you get and error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.
See:
HowTo.CompileCrossTool
http://cvs.sourceforge.net/viewcvs.py/*checkout*/nslu/unslung/README UNSLUNG-1.x family release README - If this does not display the README, click on the (view) option.\\

Changed lines 13-14 from:

My first program was very simple to build. It was dnsmasq, and required no changes to the program to get it to compile. I built it outside of the source tree, but I had no instructions, so I didn't know any better. I would recommend building it inside the source tree. This way you can test at every step how it will react in a normal build, and incrementally fix it untill it is ready for release.

to:

Note: If you get and error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.

See:

HowTo.CompileCrossTool

http://cvs.sourceforge.net/viewcvs.py/*checkout*/nslu/unslung/README UNSLUNG-1.x family release README - If this does not display the README, click on the (view) option.

Changed lines 21-30 from:

I will give a general overview of how the build system works, and follow up with a step-by-step description of the process. My instructions will assume changes for dnsmasq. You will substitute your own package name

to:

My first program was very simple to build.

It was dnsmasq, and required no changes to the program to get it to compile. I built it outside of the source tree, but I had no instructions, so I didn't know any better. I would recommend building it inside the source tree. This way you can test at every step
how it will react in a normal build, and incrementally fix it untill it is ready for release.

I will give a general overview of how the build system works, and follow up with a step-by-step
description of the process. My instructions will assume changes for dnsmasq. You will substitute your own package name

Changed lines 42-46 from:

dnsmasq.control - a package description file. Required
dnsmasq.rc - the rc startup script if needed.
dnsmasq.postinst - post install script for the ipk if needed.
dnsmasq.prerm - pre install script for the ipk if needed.
anything else your .mk file might need. Prescript the file with your package name.

to:
 dnsmasq.control - a package description file. Required
dnsmasq.rc - the rc startup script if needed.
dnsmasq.postinst - post install script for the ipk if needed.
dnsmasq.prerm - pre install script for the ipk if needed.
anything else your .mk file might need. Prescript the file with your package name.
  • The make directory contains all the makefiles. There is one for each application.

Mine is dnsmasq.mk. I stole most of it from dhcp.mk and flex.mk. Study a few. Copy one.

I used dhcp.mk:

 cp dhcp.mk dnsmasq.mk
Deleted lines 54-55:
  • The make directory contains all the makefiles. There is one for each application. Mine is dnsmasq.mk. I stole most of it from dhcp.mk and flex.mk. Study a few. Copy one. I used dhcp.mk:
    cp dhcp.mk dnsmasq.mk\\
Changed line 63 from:

Now it is time to debug.\\

to:

Now it is time to debug..

Added line 65:
 make
Deleted line 66:

make\\

Changed lines 68-71 from:

Make tried to build dnsmasq-ipk which depends on $(DNSMASQ_IPK).
$(DNSMASQ_IPK) depends on $(DNSMASQ_DIR)/src/dnsmasq.
$(DNSMASQ_DIR)/src/dnsmasq depends on $(DNSMASQ_DIR)/.configured.
$(DNSMASQ_DIR)/.configured depends on $(DL_DIR)/$(DNSMASQ_SOURCE) which wgets the source file.\\

to:

Make tried to build dnsmasq-ipk which depends on $(DNSMASQ_IPK).

 $(DNSMASQ_IPK) depends on $(DNSMASQ_DIR)/src/dnsmasq.
 $(DNSMASQ_DIR)/src/dnsmasq depends on $(DNSMASQ_DIR)/.configured.
 $(DNSMASQ_DIR)/.configured depends on $(DL_DIR)/$(DNSMASQ_SOURCE) which wgets the source file.
Changed lines 77-78 from:

To test your package, copy your ipk file to the /opt directory on your NSLU2. Login to to the NSLU using telnet or dropbear, and go to /opt.
ipkg install your.ipk\\

to:

To test your package, copy your ipk file to the /opt directory on your NSLU2. Login to to the NSLU using telnet or dropbear, and go to /opt.

 ipkg install your.ipk
Changed lines 85-86 from:

Go to the IRC chatroom ( irc.freenode.net #nslu2-linux ) and announce your new addition. You will need to supply your sourceforge.net user name.
When you have been given access, you will have to follow the sourceforge directions to upload a SSH public key. The instructions are in your account maintenance section.\\

to:

Go to the IRC chatroom ( irc.freenode.net #nslu2-linux ) and announce your new addition. You will need to supply your sourceforge.net user name. When you have been given access, you will have to follow the sourceforge directions to upload a SSH public key. The instructions are in your account maintenance section.

Changed lines 91-96 from:

to do the following:
Rename your unslung directory to unslung.old.
Checkout unslung using :ext: access.
Copy your makefile and sourcefiles from unslung.old into the new unslung tree.
Add your package to the PACKAGES variable in Makefile.
make \\

to:

to do the following:

1. Rename your unslung directory to unslung.old..
2. Checkout unslung using :ext: access.
3. Copy your makefile and sourcefiles from unslung.old into the new unslung tree.
4. Add your package to the PACKAGES variable in Makefile.
5. make

Changed lines 100-101 from:

When you are satisfied, cvs add your .mk file in the make directory, and your source files in the source directory. Commit your changes, and you are done.

to:

When you are satisfied, cvs add your .mk file in the make directory, and your source files in the source directory. Commit your changes, and you are done.

Changed line 103 from:

When your addition will appear on the public feed, I don't know. I don't know how often they are rebuilt.

to:

When your addition will appear on the public feed, I don't know. I don't know how often they are rebuilt.

October 11, 2004, at 01:59 AM by Gerald L Clark --
Changed line 37 from:
  • The make directory contains all the makefiles. There is one for each application. Mine is dnsmasq.mk. I stole most of it from dhcp.mk and fles.mk. Study a few. Copy one. I used dhcp.mk:\\
to:
  • The make directory contains all the makefiles. There is one for each application. Mine is dnsmasq.mk. I stole most of it from dhcp.mk and flex.mk. Study a few. Copy one. I used dhcp.mk:\\
October 11, 2004, at 01:23 AM by Gerald L Clark --
Added line 11:

Note: If you get and error during compilation that says keramik is not found, unset STYLE and try again. Keramik sets the STYLE variable which is also used by some packages.\\

Added line 56:
October 10, 2004, at 09:34 PM by Gerald L Clark --
Changed line 13 from:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/nslu/unslung/README README \\

to:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/nslu/unslung/README UNSLUNG-1.x family release README - If this does not display the README, click on the (view) option.\\

Changed lines 65-67 from:

Go to the IRC chatroom and announce your new addition. You will need to supply your sourceforge.net user name. ( add link to IRC instructions. ) When you have been given access, you will have to follow the sourceforge directions to upload a SSH public key.

to:

Go to the IRC chatroom ( irc.freenode.net #nslu2-linux ) and announce your new addition. You will need to supply your sourceforge.net user name.
When you have been given access, you will have to follow the sourceforge directions to upload a SSH public key. The instructions are in your account maintenance section.

October 10, 2004, at 09:06 PM by Gerald L Clark --
Deleted line 4:

( add link to cvs instructions. )

Added lines 9-13:

Once you have downloaded the developement tools and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.
See:
HowTo.CompileCrossTool
http://cvs.sourceforge.net/viewcvs.py/*checkout*/nslu/unslung/README README \\

Deleted lines 14-15:

Once you have downloaded the developement tools CompileCrossTool? and package sources, and successfully built Unslung and all the packages, you are ready to add your own package.

October 10, 2004, at 08:45 PM by Gerald L Clark --
Changed line 11 from:

Once you have downloaded the developement tools and package sources, and successfully

to:

Once you have downloaded the developement tools CompileCrossTool? and package sources, and successfully

October 10, 2004, at 08:35 PM by Gerald L Clark --
Changed lines 1-3 from:

This Page is currently under developement.

You have a program you would like to add to the packages area?

to:

You have a program you would like to add to the packages area?\\

Changed line 11 from:

Once you have downloaded the the developement tools, and package sources, and successfully

to:

Once you have downloaded the developement tools and package sources, and successfully

Changed lines 16-17 from:

I will give a general overview of how the build system works, and follow up with a step-by-step description of the process.

to:

I will give a general overview of how the build system works, and follow up with a step-by-step description of the process. My instructions will assume changes for dnsmasq. You will substitute your own package name

Deleted line 25:

My instructions will assume changes for dnsmasq. You will substitute your own package name

Changed line 27 from:
  • The following files may need to be created in the source directory:\\
to:
  • The source directory contains source files necessary for patching the package source, and generating the .ipk package file. The following files may need to be created in the source directory:\\
Changed lines 34-39 from:
  • The make directory contains all the makefiles. There is one for each application.

Mine is dnsmasq.mk. I stole most of it from dhcp.mk and fles.mk. Study a few. copy one. I used dhcp.mk .

cp dhcp.mk dnsmasq.mk

to:
  • The make directory contains all the makefiles. There is one for each application. Mine is dnsmasq.mk. I stole most of it from dhcp.mk and fles.mk. Study a few. Copy one. I used dhcp.mk:
    cp dhcp.mk dnsmasq.mk\\
Changed lines 41-42 from:

Go to the top level of the source tree, and edit Makefile. Add your package to the PACKAGES variable.
make should now result in the download of your source to downloads, and your source tree to the builds directory. You will probably error out, but we just want to verify that the source downloads and and unpacks and patches properly. If not, check the definitions.\\

to:
  • Go to the top level of the source tree, and edit Makefile. Add your package to the PACKAGES variable.

Now it is time to debug.

make
should result in the download of your source tarfile to downloads, and your source tree to the builds directory. You will probably error out, but we just want to verify that the source downloads, unpacks and patches properly. If not, check the definitions.\\

Changed line 54 from:

$(DNSMASQ_DIR)/.configured would also do the patching and configuring. See dropbear.mk for an example of patching and configuring. It is all pretty straight forward.

to:

$(DNSMASQ_DIR)/.configured does the extracting, the patching, and configuring. See dropbear.mk for an example of patching and configuring. It is all pretty straight forward.

Changed lines 56-57 from:

Edit your make and source files as necessary until your application builds asn places the .ipk file in the packages directory.
Copy your ipk file to the /opt directory on your NSLU2. Login to to the NSLU using telnet or dropbear, and go to /opt.\\

to:

Edit your make and source files as necessary until your application builds and places the .ipk file in the packages directory.
To test your package, copy your ipk file to the /opt directory on your NSLU2. Login to to the NSLU using telnet or dropbear, and go to /opt.\\

Changed lines 61-68 from:

You are now ready to add your package to CVS.

to:

You are now ready to add your package to CVS.
To do this you will have to ask to be added to the developers list. Go to the IRC chatroom and announce your new addition. You will need to supply your sourceforge.net user name. ( add link to IRC instructions. ) When you have been given access, you will have to follow the sourceforge directions to upload a SSH public key. If you were using anonymous :pserver: access, and not :ext: developers access you will need to do the following:
Rename your unslung directory to unslung.old.
Checkout unslung using :ext: access.
Copy your makefile and sourcefiles from unslung.old into the new unslung tree.
Add your package to the PACKAGES variable in Makefile.
make
If your package builds, test load it again as above. When you are satisfied, cvs add your .mk file in the make directory, and your source files in the source directory. Commit your changes, and you are done.

Changed lines 76-78 from:

To get this you will have to ask to be added to the developers list. Go to the IRC chatroom and announce your new addition. ( add link to IRC instructions. )

to:

When your addition will appear on the public feed, I don't know. I don't know how often they are rebuilt.

October 10, 2004, at 08:03 PM by Gerald L Clark --
Added lines 27-35:

My instructions will assume changes for dnsmasq. You will substitute your own package name

  • The following files may need to be created in the source directory:
    dnsmasq.control - a package description file. Required
    dnsmasq.rc - the rc startup script if needed.
    dnsmasq.postinst - post install script for the ipk if needed.
    dnsmasq.prerm - pre install script for the ipk if needed.
    anything else your .mk file might need. Prescript the file with your package name.
Changed line 38 from:

copy one. I used dhcp.mk My instructions will assume changes for dnsmasq. You will substitute your own package name.

to:

copy one. I used dhcp.mk .

Changed line 48 from:

make should now result in the download of your source in downloads, and your source tree in the builds directory. You will probably error out, but we just want to verify that the source downloads and and unpacks properly. If not, check the definitions.\\

to:

make should now result in the download of your source to downloads, and your source tree to the builds directory. You will probably error out, but we just want to verify that the source downloads and and unpacks and patches properly. If not, check the definitions.\\

Changed lines 52-61 from:

$(DNSMASQ_DIR)/.configured depends on $(DL_DIR)/$(DNSMASQ_SOURCE) which wgets the source file.

to:

$(DNSMASQ_DIR)/.configured depends on $(DL_DIR)/$(DNSMASQ_SOURCE) which wgets the source file.
Had there been any patches, I would have put them in dnsmasq.patch in the source directory. $(DNSMASQ_DIR)/.configured would also do the patching and configuring. See dropbear.mk for an example of patching and configuring. It is all pretty straight forward.

Edit your make and source files as necessary until your application builds asn places the .ipk file in the packages directory.
Copy your ipk file to the /opt directory on your NSLU2. Login to to the NSLU using telnet or dropbear, and go to /opt.
ipkg install your.ipk
Check that it installs and runs properly.

You are now ready to add your package to CVS.

October 10, 2004, at 07:25 PM by Gerald L Clark --
Changed line 29 from:

copy one. I used dhcp.mk

to:

copy one. I used dhcp.mk My instructions will assume changes for dnsmasq. You will substitute your own package name.

Changed lines 33-47 from:

Now I changed every instance of DHCP to DNSMASQ and every instance of dhcp to dnsmasq.

to:

Now I changed every instance of DHCP to DNSMASQ and every instance of dhcp to dnsmasq.
Set the _VERSION variable.
Set the _SITE variable to the site where you downloaded the source.
The expanded _SOURCE variable should be the name of the source file to download. Since zcat is probably the only unzipper available on the NSLU, choose the .tar.gz or .tgz version of the source download, I don't know how you would extract a .bz zipped archive.

Go to the top level of the source tree, and edit Makefile. Add your package to the PACKAGES variable.
make should now result in the download of your source in downloads, and your source tree in the builds directory. You will probably error out, but we just want to verify that the source downloads and and unpacks properly. If not, check the definitions.
Make tried to build dnsmasq-ipk which depends on $(DNSMASQ_IPK).
$(DNSMASQ_IPK) depends on $(DNSMASQ_DIR)/src/dnsmasq.
$(DNSMASQ_DIR)/src/dnsmasq depends on $(DNSMASQ_DIR)/.configured.
$(DNSMASQ_DIR)/.configured depends on $(DL_DIR)/$(DNSMASQ_SOURCE) which wgets the source file.

October 10, 2004, at 06:32 PM by Gerald L Clark --
Changed lines 1-40 from:
to:

This Page is currently under developement.

You have a program you would like to add to the packages area? Here are the steps necessary.

You must have CVS access to the packages source tree. ( add link to cvs instructions. ) To build and test your new application you will only need anonymous read access, but to save your changes you will need developers access. If you have never cross compiled an application, you may decide to wait until you have compiled and tested your application before requesting it.

Once you have downloaded the the developement tools, and package sources, and successfully built Unslung and all the packages, you are ready to add your own package. My first program was very simple to build. It was dnsmasq, and required no changes to the program to get it to compile. I built it outside of the source tree, but I had no instructions, so I didn't know any better. I would recommend building it inside the source tree. This way you can test at every step how it will react in a normal build, and incrementally fix it untill it is ready for release.

I will give a general overview of how the build system works, and follow up with a step-by-step description of the process.

The building of the package is controlled by a makefile, and a few small source files needed for generating the .ipk file. The actual sources for the package are not included. The makefile must provide for the downloading, patching, compiling, and packaging of the application. It sounds like alot, but is fairly easy. The difficulty will be getting the application to compile in a cross-compile environment. Programs that use configure may pose the most problems.

  • The make directory contains all the makefiles. There is one for each application.

Mine is dnsmasq.mk. I stole most of it from dhcp.mk and fles.mk. Study a few. copy one. I used dhcp.mk

cp dhcp.mk dnsmasq.mk

Now I changed every instance of DHCP to DNSMASQ and every instance of dhcp to dnsmasq.

To get this you will have to ask to be added to the developers list. Go to the IRC chatroom and announce your new addition. ( add link to IRC instructions. )