Ok attached are the most recently compiled ipks. I'm fairly confident that they match juul's most recent commits.

Also - I was looking into it, and I think that as long as we're targeting supported openwrt chipsets, we can probably wire up a continuous integration server to build our packages automatically.

This unfortunately won't work for the time being with our whole firmware. Re-building the entire buildroot takes too long (at least for the free and easily configurable options that I encountered). Other options include:

 - A VPS which has a git hook or other command which rebuilds the entire buildroot whenever the code changes.
 - We build a sudowrt SDK or imagebuilder or whatever that is. That would substantially reduce the amount of time that firmware builds would take, but would also require us to rebuild the sdk/imagebuilder every time that we want to patch kernel, etc.
 - We more or less keep the system we have, except that we add some scripts which rebuild parts of the firmware. I know that juul spent a long time looking over the image builder and I've spent enough time looking over it to know that it's not particularly easy, but it would be pretty awesome to at least have a script which will go through all the steps to update a package feed, clean all of the relevant lingering files, and (re)build a package.

Just some thoughts.

On Mon, Apr 20, 2015 at 6:05 PM, max b <maxb.personal@gmail.com> wrote:
I spent the evening debugging and improving notdhcp and it really needs to be compiled again. Hopefully that's easy now? 

Yeah shouldn't be very hard. I can do it before the hacknight tomorrow. 

I like your timelines! May 1st may prove to be a little soon to have an actual working release, but I'm happy to see if we can make it work! I'll try to keep any comments I have on the github issue.

See ya tomorrow!

Max

On Sun, Apr 19, 2015 at 2:16 AM, Marc Juul <juul@labitat.dk> wrote:


On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal@gmail.com> wrote:
and with attachments.....

On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal@gmail.com> wrote:
Scratch that - those aren't compiled correctly. These should be though. Damn openwrt buildroot is a pita. Why wouldn't make package/packagename/clean && make package/packagename/compile re-download the git tarball!!

On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal@gmail.com> wrote:
Hey folks,

I'm running a little late, but it does look like I successfully compiled an ar71xx binary of notdchpclient and notdhcpserver. I've attached the ipks to this email in case anyone is super anxious to get running with them, otherwise I'll be at sudo a little after 8.

Yay! \o/

For some reason these messages ended up in my spam box :/

I spent the evening debugging and improving notdhcp and it really needs to be compiled again. Hopefully that's easy now?

I wrote down some thoughts on our future plans to auto-switch ethernet ports from public/private to dedicated extender-node ports. Here they are:

  https://github.com/sudomesh/sudowrt-firmware/issues/26

I was thinking about setting a tentative development schedule for roll-out:

Suggested milestones for v0.2:

* Switch to babel [done]
* Upgrade to barrier breaker [done]
* Multi-radio support [done]
* Add-on radios via extender-nodes [nearly there]
* New ubus-based web interface (but no extender-node management) [~three nights work?]
* Working (but not necessarily ideal) node monitoring system [done?]
* No fake captive portal [postponed]

Suggested timeline:

  * May 1st: sudowrt feature-complete for 0.2 and ready to test. First home+extender node up near curtis st. garden.
  * May 7th: First garden node prototype operational at Curtis st. community garden.
  * June 1st:
    ** sudowrt v0.2 release candidate 1.
    ** Development of v0.3 begins.
  * July 1st: sudowrt v0.2 stable release
  * August 1st: v0.3 feature-complete

Potential milestones for v0.3:

* Improved web interface
** Usage statistics
** Extender-node management
* Automatic extender-node connection on all ethernet ports
* Fake captive portal working
* Service browser working well
* Node alignment-helper web interface
* Support for monthly bandwidth sharing cap

Potential milestones for v1.0:

* Per-node internet-routable IPv6 subnet
* Multicast node-monitoring
* Gigabit connection piped into mesh
* Decentralized exit node / VPuN server discovery
* Service browser working well
* Switch to "foo over udp" tunnel
* Auto-launch of local services (wikipedia/openstreetmaps) when USB stick plugged in
* Logistics management for sale of pre-flashed nodes
* Launch crowdfunding campaign

Potential milestones for v2.0:
* Secure trust-based babel routing
* Automatic node transmit power adjustment

Our efforts to document should keep up with releases, so it may make sense to take a couple of weeks of focused documentation effort after each release.

What do you humans think?

--
marc/juul