21 Apr
2015
21 Apr
'15
12:12 p.m.
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(a)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(a)labitat.dk> wrote:
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
and with attachments.....
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)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(a)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