Bug #65

I have been toying with this task as my intro to OpenWRT packages, but it has been a bit of a pain (at least for a newbie like myself :). The main issue is that the Makefile distributed with the nuttcp-6.1.2 tarball does not have a target for install, and I am unsure of how to have the OpenWRT Makefile’s Package/nuttcp/install not call make install on the nuttcp Makefile.

My workaround to successfully compile and install into staging was to add a dummy install entry nuttcp’s Makefile, and that seems to work fine. I am not sure if storing our own copy of nuttcp’s source is The Right Way of doing this, but I couldn’t find a good way of modifying the nuttcp Makefile in the OpenWRT build process after pulling the tarball down.

Anyway, I put what I think is a correctly cross compiled version of the nuttcp binary and an ipk in /tmp/tupty_nuttcp_test/. I am unsure of a way to test this myself, hence the reason for me not grabbing the ticket. For the record, the ipk should install into /root/bin/, but that can obviously be changed if you want it somewhere else.

That’s cool - I’ve been working on testing nuttcp, though with v7.1.3. Slightly confused, though, is the file in /tmp/tupty_nuttcp_test the binary or the ipk?

Incidentally I have been fiddling with creating a package of my own.

I took an existing package (gpsd), changed the name to gpsd-mini,
modified it to eliminate the libusb dependency, got that working on the
wndr with a gps… then tried to update it to a later version (from 2.94
to 2.96) last night, which broke.

So… at the moment this breaks the bismark build (thus proving the need
to NOT do raw development against the /home/bismark/src/wndr3700 tree),
so I’ve disabled it from that build as of this morning, and will move
off to doing package development against a private tree.

Gpsd may contain an example of how to do a make install with the nuttcp
code.

I would like to suggest moving the bismark package feed into a git tree
(which I just did) and for folk to check their preliminary packages into
that and push them back to the main repo so more eyeballs can be had on
the problem.

If working remotely, the clone would be:

git clone
ssh://bismark@huchra.bufferbloat.net/home/bismark/src/bismark-packages

or merely the path if working on packages directly on huchra in your
private directory.

(Why gpsd? I wanted accurate TIME and possibly lat/long information, and
was working with esr on a ntp interface. The first version of the code
worked, but getting the gps to work required that the antenna be near a
window. We’re thinking that an interface to a atomic radio clock would
be better, now)

I obtained the TIE code, which is lying around in ~bismark, awaiting a
packager…

Apparently there is a bismark package in the build already, but it
appears to be just a test package.

You can put a patch to the makefile in the package (see gpsd-mini for an example)

Is this a dead packaging project currently? Is it needed by next week?
If not please put in a deadline for it….

Still wanted?

Dear Stephen.

I love you man. It’s not physical or anything, however. :)
yes, I’d like nuttcp a lot, but not for today’s attempt at a release candidate.

Can you slam it into ceropackages if you haven’t already? Or openwrt? Somewhere? before wednesday next week?

Added it to ceropackages.