DSM-G600, DNS-3xx and NSA-220 Hack Forum

jules wrote:

Kudos for the idea of a feed for the latest user submitted ipkg, it could ease the testing of new packages reducing the installation/removal to the click of a button.

Just for info: by "testing feed" I meant more like a pre-feed area - the reason being that you can create packages with pre & post install scripts - allowing people to upload untested packages could result in someone being malicious and uploading a package with a pre-install script of "rm -rf /mnt/HD_a2" or similar (not good!), so the first part of uploading a package would be for someone (me?) un-taring the package and checking any scripts for malicious code - then move it to an actual beta/testing feed, and finally on to the live feed.

jules wrote:

i don't know if it's possible to build apps in a "location agnostic" way (maybe exploiting LD_LIBRARY_PATH).

Most apps are by default are built in a, as you put it,  "location agnostic" way, usually all they need to know is where the libs are either by LD_LIB..._PATH or ld.so.conf/ldconfig. If you installed all of the optware packages and did something like "cd /opt; find . -type f -exec strings "{}" |grep \/opt \;" you'd probably get an idea if any are actually hard coded - as long as you ignore any conf files.

fonz wrote:

- At the moment, optware is based on the dlink toolchain while I'm using more recent tools for 0.5 (e.g. gcc4, latest uclibc).

I agree that dlink toolchain is too old.

bzhou:

2 - While they may look in /opt for the libraries first, if it fails to find them under /opt they will still search the standard library paths specified in ld.so.conf or the LD_LIBRARY_PATH env variable. This is standard behavior and as an example I'm certain the optware python25 does this (as I tested it on Friday - my ipkg.conf uses /mnt/HD_a2/ipkg as the root path) and I would assume most other packages will also - this should only be false if the app itself is, in my opinion, badly coded.

3 - I have instructions for using buildroot to create a newer toolchain, although they were created in December so may be outdated in terms of software revisions. However, if you use libs newer than the dns-323 standard you'll need to identify which optware packages use these newer libs and create dependencies - I had to do this for mediatomb & stdc++.so.N

    $ unset CC; unset CXX
    $ cd
    $ svn co svn://uclibc.org/trunk/buildroot
    $ cd buildroot

    $ make menuconfig
    --> Target Architecture = arm
    --> Enable: Target Options --> ARM Ltd. Device Support
    --> Enable: Toolchain --> Build/install c++ compiler and libstdc++
    --> Enable: Toolchain --> Enable WCHAR support
    --> Kernel --> .config file = /var/tmp/.config
    --> Leave the rest as the default values, exit & save

    --> Copy the .config file from your current (i.e: wiki) toolchains kernel to /var/tmp

    $ make
    --> select default values if prompted for kernel options

    --> gcc etc should now be in ~/buildroot/build_arm/staging_dir/usr/bin

There is no /opt/lib/ld-*:

/ # ls /opt/lib/ld*
ls: /opt/lib/ld*: No such file or directory

Apps use /lib/uClibc.so:

/ # ldd /opt/bin/perl
        libperl.so => /opt/lib/perl5/5.8.8/arm-linux/CORE/libperl.so (0x4000d000
)
        libnsl.so.0 => /lib/libnsl.so.0 (0x40114000)
        libdl.so.0 => /lib/libdl.so.0 (0x4011d000)
        libm.so.0 => /lib/libm.so.0 (0x40127000)
        libcrypt.so.0 => /lib/libcrypt.so.0 (0x4013d000)
        libutil.so.0 => /lib/libutil.so.0 (0x40159000)
        libc.so.0 => /lib/libc.so.0 (0x40162000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401bb000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)

fonz wrote:

In the end, ipkg is just some package tool, and I don't see any problem running ffp and optware in parallel. You'll have two prefixes /ffp and /opt, but that's about it.

Hmm, ipkg is some package management tool, ipk is some package; but optware is a large collection of apps already ported to uClibc. I think it would be useful for ipkg (app) to be distributed with ffp - maybe it would save you some time compiling apps.

Like you say, there's no problem having /ffp and /opt.

But then we would maybe need (or want) ffp 0.5 to be a special optware target platform "dns323-ffp"?

fonz wrote:

Native compilation is slow, but more reliable and also allows to run test suites (more easily).

What makes it more reliable? Could you just run the configure and test suite native? I just bought a fancy new dev machine, and would feel bad if I had to wait for compiles on the DNS323 :-(

HaydnH wrote:

Most apps are by default are built in a, as you put it,  "location agnostic" way, usually all they need to know is where the libs are either by LD_LIB..._PATH or ld.so.conf/ldconfig. If you installed all of the optware packages and did something like "cd /opt; find . -type f -exec strings "{}" |grep \/opt \;" you'd probably get an idea if any are actually hard coded - as long as you ignore any conf files.

Ok, after reading the latest posts i get your point. I agree on your security concerns about the test feed (you can never know what users post on a forum) and about hardcoding (bad practice indeed).
Looking at bzhou point 1 it looks like that before compiling a prefix is added (or some base path variable set or?) where necessary to point to the right /var, /etc,/log to create a sandbox separated from anything else. If i got it right, even if unpractical for us, from that point of view, their choice is reasonable.

HaydnH wrote:

fonz wrote:

You're looking for a _large_ collection of packets? http://www.pkgsrc.se

This is just a database of source rather things compiled for the dns-323, you may as well point to sourceforge, or am I missing something?

optware is a collection of makefiles to build packages with a custom prefix (/opt), and so is pkgsrc (/usr/pkg). and just like optware, pkgsrc creates binary packages that can be installed, removed, etc.

HaydnH wrote:

This is just a database of source rather things compiled for the dns-323, you may as well point to sourceforge, or am I missing something?

I think maybe it's poke at me for getting excited about big numbers? :-)

Obviously a huge number of apps is not helpful if almost all of them are not appropriate for the target - for example, why would you want an X server for your DNS323? But I read that optware was specifically intended for embedded linux devices, so I'd expect a high percentage of the apps to be "appropriate". (At least _someone_ thought they were when they ported them!) Am I wrong?

Additionally, a big collection of software is not so useful if it takes a lot of work to port to your target, but bzhou seems to have done a lot of that, so optware/ipkg is a good start for any app port effort (again, IMVHO).

Or did I miss something too?

I can imagine there would be disadvantages to fonz in making an explicit link between ffp and ipkg; I think that the major issues were the different build process and no personal interest in investing time in that direction (which is perfectly valid!)

bzhou implied that it would be straight forward to update the target that optware uses for the dns323 to be similar to the ffp 0.5 distro (updated uClibc, gcc), which might be worth doing regardless of "tight" integration with ffp, but I don't understand the benefits or scope of that work.

=Edit: snip stray text=

Last edited by sjmac (2008-03-11 14:05:16)

sjmac wrote:

I read that optware was specifically intended for embedded linux devices, so I'd expect a high percentage of the apps to be "appropriate".

pkgsrc is the software collection from netbsd. And netbsd is known to run even on toasters: http://www.embeddedarm.com/software/arm … oaster.php

sjmac wrote:

Additionally, a big collection of software is not so useful if it takes a lot of work to port to your target...
I can imagine there would be disadvantages to fonz in making an explicit link between ffp and ipkg;

0.5 is the next step to pkgsrc. In theory, whats missing is:

cvs co pkgsrc
cd pkgsrc/bootstrap
./bootstrap
cd /what/do/you/want/to/compile/today
bmake

So basically it's all there. I just need to give it another test. I've tested pkgsrc with uClibc on my dns before, with good results (eg. I've succesfully built lighttpd, perl, openssl, etc..).

Btw, I've added cvs yesterday

Does pkgsrc have an easy way to remove/upgrade packages and handle dependencies? i.e: if it's just make files are you planning on any package management in ffp?

HaydnH wrote:

Does pkgsrc have an easy way to remove/upgrade packages and handle dependencies? i.e: if it's just make files are you planning on any package management in ffp?

It handles dependencies. I don't have much experience with the binary package tools, yet, but during the build it will automatically build all dependencies before the package you requested. Have a look here for more info:

http://pkgsrc.se/pkgtools

See pkg_install and friends.

PS: pkgsrc documentation is here: http://www.netbsd.org/docs/pkgsrc/

sjmac wrote:

HaydnH - would you try to support both pkgsrc and ipkg?

It's certainly possible, atm the php code (very basically) grabs the package info to an array and displays them, adding pkgsrc to the web interface would probably be relatively simple (i.e: grab ipkg packages to array, grab pkgsrc packages to same array, sort array, if (ipkg) { displayA } else { displayB }). However, dependencies between the 2 could be a nightmare, e.g: if an ipk requires a lib provided by pkgsrc... you could probably handle that fine through the web interface but would make it a pita using the cli.

FYI, there's also an optware package ipkg-web that manages ipkg's with a CGI web interface. (haven't used it personally)