[Bismark-devel] bismark software package requirements

[Bismark-devel] bismark software package requirements

[Dave Taht]

I put the details on the wndr up on the wiki. All members of this 
project have wiki editing privs,
so if there is a procedure you can document or a bug you have to file, 
please do so.

http://www.bufferbloat.net/projects/bismark/wiki/Wndr3700

libstdcpp is a package requirement for the bismark software according to ldd

root@OpenWrt:/etc/bismark/bin# ldd ./ITGSend
         libpthread.so.0 => /lib/libpthread.so.0 (0x2b6fc000)
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2b720000)
         libm.so.0 => /lib/libm.so.0 (0x2b7fe000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2b822000)
         libc.so.0 => /lib/libc.so.0 (0x2b844000)
         libdl.so.0 => /lib/libdl.so.0 (0x2b8a9000)
         ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2b6e4000)

And bash is also a requirement at the present time (it is not in the 
default image, but is built)

How to create a feed is documented here

http://wiki.openwrt.org/doc/devel/feeds

There should probably be a bismark-all meta package...

http://www.bufferbloat.net/issues/64

And multiple other issues are on the issue tracker.

Re: [Bismark-devel] bismark software package requirements

[Poole, Brian]

Well, I got the first bismark package (and the custom feed) setup. It's ugly (very ugly) but I'm getting a handle on the package building system so it should shape up pretty quickly.

I foresee splitting off the D-ITG & shaperprobe into their own package and just adding dependencies to reduce the complexity of the bismark package. We'll probably ultimately also have a few bismark-* pkgs rather than just one to allow for different levels of participation but that can be thought about a little later.

Walter, what about the tar that Sri built was wrong? I would like to get the packages further along tomorrow and knowing that will help. I did see a couple of symlinks (rather than original files) were packed in the keys and that there are some non-essential ITG binaries included. Were there other problems? 

Also, I think moving /root/scripts/* and /root/bin/* into /usr/bin or /usr/sbin as appropriate would be a good idea. Other than a few path updates I can't imagine this causing much of a problem. Opinions? Any scripts/binaries that you know would be sbin versus bin?

Finally, I'm guessing that the authorized_keys and known_hosts will probably be moved from the bismark svn to the source control for the custom feed. This is because we don't want to just copy those files in (might overwrite what the user already had) but rather concatenate the keys dynamically as part of a post-install process for the package. I'm not 100% on this yet as I haven't played with the post-install but I encountered a similar situation with /etc/rc.local (which was already being provided by another core package.)

Brian
 
________________________________________
From: bismark-devel-bounces@lists.bufferbloat.net [bismark-devel-bounces@lists.bufferbloat.net] on behalf of Dave Taht [d@taht.net]
Sent: Thursday, April 07, 2011 9:15 PM
To: bismark-devel@lists.bufferbloat.net
Subject: [Bismark-devel] bismark software package requirements

I put the details on the wndr up on the wiki. All members of this
project have wiki editing privs,
so if there is a procedure you can document or a bug you have to file,
please do so.

http://www.bufferbloat.net/projects/bismark/wiki/Wndr3700

libstdcpp is a package requirement for the bismark software according to ldd

root@OpenWrt:/etc/bismark/bin# ldd ./ITGSend
         libpthread.so.0 => /lib/libpthread.so.0 (0x2b6fc000)
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2b720000)
         libm.so.0 => /lib/libm.so.0 (0x2b7fe000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2b822000)
         libc.so.0 => /lib/libc.so.0 (0x2b844000)
         libdl.so.0 => /lib/libdl.so.0 (0x2b8a9000)
         ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2b6e4000)

And bash is also a requirement at the present time (it is not in the
default image, but is built)

How to create a feed is documented here

http://wiki.openwrt.org/doc/devel/feeds

There should probably be a bismark-all meta package...

http://www.bufferbloat.net/issues/64

And multiple other issues are on the issue tracker.

_______________________________________________
Bismark-devel mailing list
Bismark-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bismark-devel

Re: [Bismark-devel] bismark software package requirements

[Walter de Donato]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

My (in late) comments inline

I foresee splitting off the D-ITG & shaperprobe into their own package and
> just adding dependencies to reduce the complexity of the bismark package.
> We'll probably ultimately also have a few bismark-* pkgs rather than just
> one to allow for different levels of participation but that can be thought
> about a little later.
>

I agree with this proposal.
I'd propose to start creating the folowing packages:
- bismark-shaperprobe
- bismark-ditg
- bismark-tie

and properly set their dependencies/conflicts.


> Walter, what about the tar that Sri built was wrong? I would like to get
> the packages further along tomorrow and knowing that will help. I did see a
> couple of symlinks (rather than original files) were packed in the keys and
> that there are some non-essential ITG binaries included. Were there other
> problems?
>

Sorry about the long latency on that.
Apart from symlinks and unnecessary binaries, some paths referenced inside
the scripts should be modified
according to the folder structure we want to use (see the next point).


>
> Also, I think moving /root/scripts/* and /root/bin/* into /usr/bin or
> /usr/sbin as appropriate would be a good idea. Other than a few path updates
> I can't imagine this causing much of a problem. Opinions? Any
> scripts/binaries that you know would be sbin versus bin?
>

I agree with moving binaries inside /bin or /sbin, but probably I'll try to
keep the scripts in a different folder
and dispose a wrapper in /bin to call each of them.
Otherwise I'd suggest to rename all the scripts with a prefix "bismark_".


>
> Finally, I'm guessing that the authorized_keys and known_hosts will
> probably be moved from the bismark svn to the source control for the custom
> feed. This is because we don't want to just copy those files in (might
> overwrite what the user already had) but rather concatenate the keys
> dynamically as part of a post-install process for the package. I'm not 100%
> on this yet as I haven't played with the post-install but I encountered a
> similar situation with /etc/rc.local (which was already being provided by
> another core package.)
>

We can decide to unpack them in /etc/bismark and then let the post-install
script manage their content.

-Walter

[-- Attachment #2: Type: text/html, Size: 3089 bytes --]