[OpenWrt-Devel] Bringing young people in the community: Google Code-In 2017

[nemesis]

Hi everyone,

I'm Federico Capoano, some of you may know me for my involvement with 
Ninux, NetJSON, OpenWISP and contribution to several editions of the 
Google Summer of Code with Freifunk.


OpenWISP has been accepted into the Google Code-In:
https://codein.withgoogle.com/organizations/openwisp/

By participating in this program we hope to attract many new young 
contributors in the world of open source networking, free wifi and 
similar topics.
We aim at proposing easy tasks related to documentation, tutorials, 
fixing small code issues, UX improvements and so on.


We are looking for mentors that share similar goals with us and want to 
get involved, for those of you that are following the NetJSON 
development or using some OpenWISP tool, this would be a good time to 
start contributing!


We also would like to invite mentors that want to propose tasks that 
are related to OpenWRT/LEDE (as indicated to some of you at the last 
OpenWRT Summit in Prague).


Important notes:

- we want mentors to take care of the tasks they propose
- please read the GCI rules, in particular section 2, 4 and 5: 
https://developers.google.com/open-source/gci/resources/contest-rules
- take a look at the tasks proposals we are working on (we will export 
this collaborative spreadsheet to CSV) and import it using the GCI API: 
https://docs.google.com/spreadsheets/d/1nNNN6Db8fS3KtijO9BJB2YHmMzU20OUBoFrXdWk055I/edit#gid=820690942


If interested, please get in touch with us via our support channels 
(IRC, mailing list, gitter) http://openwisp.org/support.html or reply in 
private to me (in order to avoid cross-post hell).


Thank you for your attention!

Best regards
Nemesis
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Failing builds because of 404

[nemesis]

A few builds that were working fine stopped working recently. The 
errors I'm getting are related to some sources not being found, eg:


ca-certificates

Resolving ftp.debian.org... 194.71.11.165, 194.71.11.173, 
2001:6b0:19::173, ...

Connecting to ftp.debian.org|194.71.11.165|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-07-13 09:40:32 ERROR 404: Not Found.

Download failed.
--2017-07-13 09:40:32--  
http://mirror2.openwrt.org/sources/ca-certificates_20161130.tar.xz

Resolving mirror2.openwrt.org... 46.4.11.11
Connecting to mirror2.openwrt.org|46.4.11.11|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-07-13 09:40:32 ERROR 404: Not Found.

Download failed.
--2017-07-13 09:40:32--  
http://downloads.openwrt.org/sources/ca-certificates_20161130.tar.xz

Resolving downloads.openwrt.org... 78.24.191.177
Connecting to downloads.openwrt.org|78.24.191.177|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-07-13 09:40:32 ERROR 404: Not Found.

linux-3.10.36

--2017-07-13 11:41:19--  
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.10.36.tar.xz

   => '-'
Resolving ftp.all.kernel.org... failed: Name or service not known.
wget: unable to resolve host address 'ftp.all.kernel.org'
Download failed.
--2017-07-13 11:41:19--  
http://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.10.36.tar.xz

Resolving ftp.all.kernel.org... failed: Name or service not known.
wget: unable to resolve host address 'ftp.all.kernel.org'
Download failed.
--2017-07-13 11:41:19--  
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/longterm/v3.10.36/linux-3.10.36.tar.xz

   => '-'
Resolving ftp.all.kernel.org... failed: Name or service not known.
wget: unable to resolve host address 'ftp.all.kernel.org'
Download failed.
--2017-07-13 11:41:19--  
http://ftp.all.kernel.org/pub/linux/kernel/v3.x/longterm/v3.10.36/linux-3.10.36.tar.xz

Resolving ftp.all.kernel.org... failed: Name or service not known.
wget: unable to resolve host address 'ftp.all.kernel.org'
Download failed.
--2017-07-13 11:41:19--  
http://mirror2.openwrt.org/sources/linux-3.10.36.tar.xz

Resolving mirror2.openwrt.org... 46.4.11.11
Connecting to mirror2.openwrt.org|46.4.11.11|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-07-13 11:41:19 ERROR 404: Not Found.

Download failed.
--2017-07-13 11:41:19--  
http://downloads.openwrt.org/sources/linux-3.10.36.tar.xz

Resolving downloads.openwrt.org... 78.24.191.177
Connecting to downloads.openwrt.org|78.24.191.177|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-07-13 11:41:19 ERROR 404: Not Found.

Is anybody else experiencing the same issue?
Should I update something on the builds?

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] GSOC 2017 - Implement NetJSON output in ubus (OpenWRT/LEDE)

[Nemesis]

Hi Arun,

welcome to the community!

Just to provide more information, we have to thank Freifunk for their
help in getting this GSOC slot, here's the abstract that got this
project started:

https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29

Best regards
Federico


On 05/10/2017 11:24 AM, Arun Kumar wrote:
> Hi Developers,
> 
> I am Arunkumar Ravichandran currently admitted for masters program at
> University of California, San Diego. My proposal [1] Implement NetJSON
> output in ubus (OpenWRT/LEDE) has been accepted to the GSOC 2017 and I
> would like to tell more about my proposed project.
> 
> The main aim of this project is to implement parts of the NetJSON[2]
> specification in the OpenWRT/LEDE ecosystem.
> 
> Why NetJSON ??
> NetJSON would allow standardization similar to NETCONF. Since NetJSON
> uses JSON format, it makes the management of configurations done at a
> higher level and larger scale to be automated easily. By using NetJSON
> objects to either produce or collect information, in different
> vendor’s different hardware, it allows the developers to work on their
> ideas faster and in a better way.
> 
> Implementation:
> The support for NETJSON is brought in at the interconnect system-
> ubus[3]. To add support for a new ubus API which allows retrieving
> these two NetJSON object types: DeviceConfiguration[6] and
> DeviceMonitoring[7]. The NetJSON objects are filled in using the
> plugins available in System Configuration Abstraction Layer(SCAL)[4].
> Full project proposal can be read at [5].
> 
> I would welcome further suggestions from the LEDE/ OpenWRT community
> as that would help in implementing this feature sooner and in a better
> way, and also more resilient to multiple data models which are being
> used to represent network configurations.
> 
> [1] 
> https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29
> [2] https://github.com/netjson/netjson
> [3] https://lede-project.org/docs/guide-developer/ubus
> [4] https://github.com/prplfoundation/scal
> [5] 
> https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing
> [6] http://netjson.org/docs/what.html#deviceconfiguration
> [7] http://netjson.org/docs/what.html#devicemonitoring
> 
> Thanks,
> Arun
> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] Test results of OpenWrt 15.05.1 according to BSI test concept for home routers

[Nemesis]

On 04/26/2017 10:23 PM, Eric Schultz wrote:
> On 04/08/2017 11:38 AM, Hauke Mehrtens wrote:
> 
>> The German Bundesamt für Sicherheit in der Informationstechnik (short:
>> BSI, English: Federal Office for Information Security) published a
>> "Testkonzept für Breitband-Router (DSL-, Kabel-, SOHO-, CE-, CPE-Router,
>> IADs)" (English: Test concept for broadband routers). This test concept
>> is only available in German and most chapters are published in the
>> public by the BSI, chapter 4 and 5 are only available after signing a
>> NDA (Traffic Light Protocol) with the BSI:
>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Testkonzept-Breitbandrouter.pdf?__blob=publicationFile=5
>>
>> Some unnamed organization tested OpenWrt 15.05.1 on a TP-Link  TL-WR841N
>> V10.0 according to this test concept. Because I commented on the first
>> public draft of the test concept and said that I am active in the
>> OpenWrt project, the organization contacted me to check if their test
>> results are correct and provided me with the full test report under NDA.
>>
>>
>> OpenWrt 15.05.1 failed this test and LEDE will probably also fail this
>> test, because we failed on section 4.5.1 "Firewall-Bypass", which is a
>> criterion for exclusion (Ausschlusskriterium), see details below.
>>
>> The test concept focus on "normal" routers and only tests the web GUI
>> and also looks mostly on features normal home routers have. We are
>> missing some functionality like individual default password, for the web
>> GUI and the Wifi, the logging is not very good and so on. The tests
>> regarding DNS are interesting and more advanced, if someone wants to
>> look into that it would be very nice.
>>
>> The main problem is in section 4.5.1 "Firewall-Bypass".
>> OpenWrt and LEDE implement RFC4890 section 4.3.1:
>> ---
>> 4.3.1.  Traffic That Must Not Be Dropped
>>
>>Error messages that are essential to the establishment and
>>maintenance of communications:
>>
>>o  Destination Unreachable (Type 1) - All codes
>>o  Packet Too Big (Type 2)
>>o  Time Exceeded (Type 3) - Code 0 only
>>o  Parameter Problem (Type 4) - Codes 1 and 2 only
>>
>>Appendix A.4 suggests some more specific checks that could be
>>performed on Parameter Problem messages if a firewall has the
>>necessary packet inspection capabilities.
>>
>>Connectivity checking messages:
>>
>>o  Echo Request (Type 128)
>>o  Echo Response (Type 129)
>> ---
>>
>> The BSI used RFC6092 (Recommended Simple Security Capabilities in
>> Customer Premises Equipment (CPE) for Providing Residential IPv6
>> Internet Service) with this section as the base for the test:
>> ---
>> 3.2.1.  Internet Control and Management
>>
>>Recommendations for filtering ICMPv6 messages in firewall devices are
>>described separately in [RFC4890] and apply to residential gateways,
>>with the additional recommendation that incoming "Destination
>>Unreachable" and "Packet Too Big" error messages that don't match any
>>filtering state should be dropped.
>>
>>REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
>>Unreachable" and "Packet Too Big" messages containing IP headers that
>>do not match generic upper-layer transport state records.
>> ---
>>
>>
>> Attached are the results of this test of OpenWrt 15.05.1. The
>> information on how the tests from chapter 4 and 5 are done is redacted
>> from the document, if you want to work on these problems and would like
>> to get more details about the problems from chapter 4 and 5, please
>> contact me. I can also help you with translating the problem from German
>> to English. ;-)
>>
>> The "sensitive" informations are under the Traffic Light Protocol
>> classification "TLP AMBER", see these German information about the NDA:
>> https://mip.bsi.bund.de/Anlage_1_TLP-Merkblatt.pdf
>>
>>
>> I commented on the tests itself, because they are missing many important
>> stuff to test, most of the security problem of IoT devices and home
>> routers one hears about in the media are not covered here at all.
>>
>>
>> History:
>> 20.10.2015: I read this article https://heise.de/-2851354 and wrote some
>> comments to the BSI based on the first public draft. In this mail I
>> mentioned that I am activate in the OpenWrt project.
>> 23.10.2015: The BSI answered me and offered me the full draft when I
>> would sign an NDA, I did so and got the full document, but did not
>> comment on it again.
>> 23.2.2016: I got the full final draft from the BSI
>> 22.11.2016: I was told by the unnamed organization that they tested a
>> TP-Link device running OpenWrt 15.05.1 and if I could comment on their
>> results. I got the results under the NDA and 

[OpenWrt-Devel] Fix ftp.kernel.org for chaos_calmer branch

[Nemesis]

There's a fix for a very annoying issue that is breaking builds for
chaos calmer, it just needs to be merged:
https://github.com/openwrt/openwrt/pull/413

Best regards
Federico Capoano
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt summit by prpl

[Nemesis]

Hi everyone,

I have been at the event in Dublin last year with a colleague.
The event was really interesting from a technical point of view and we
really missed such an event focused on OpenWRT and the various
applications & services one can build with it.

It would be good to have more communities to participate in such an
event, and it would be awesome if the most active developers would have
a leading role in organizing it.

Hauke, one note regarding co-location, you wrote: "I would like to see
it co located with the ELCE and the Battlemesh next year."

But I believe the Battlemesh next year won't be co located with ELCE,
did you mean the Battlemesh or ELCE?

Federico




On 05/13/2016 12:44 AM, Hauke Mehrtens wrote:
> Hi,
> 
> When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come
> to a solution in the next days on this.
> 
> prpl wants to organize an OpenWrt summit again. Their goal is to bring
> the community, industry and developers together. Currently this is in
> planing and I want to know what should happen so that more developers
> and more members of the community would come to such an event.
> 
> There are different ideas on how to organize such an event:
> 1. prpl organizes an event co located with the Embedded Linux conference
> this October in Berlin.
> 2. prpl organizes an event co located with Battlemesh next year in May.
> 3. Some people from OpenWrt organize an event in Prague at CZ.NIC.
> CZ.NIC would provide a location and local logistics, prpl could help
> with finance.
> 
> It is also possible to do more than one solution or combine them.
> 
> Are there some people interested in organizing this by themselfs with
> the help of CZ.NIC, then we could go with this solution?
> If nobody is interested in organizing this I would like to see it co
> located with the ELCE and the Battlemesh next year.
> 
> No final name for this event was chosen. The current suggestion is
> "OpenWrt summit by prpl" or something similar.
> 
> Are there any comments on this?
> 
> Hauke
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [UCI] uci import -m duplicates list options

[Nemesis]

On 04/15/2016 12:17 PM, Jo-Philipp Wich wrote:
> Hi.
> 
> Just truncate the destination file beforehand.

I'll resort to lua scripting to handle this, thanks.

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [UCI] uci import -m duplicates list options

[Nemesis]

On 04/13/2016 01:33 PM, Yousong Zhou wrote:
> On 13 April 2016 at 18:54, Nemesis <neme...@ninux.org> wrote:
>> Hi,
>>
>> I've incurred in weird behaviour when using the import feature of the uci
>> tool which seems to cause duplicates when importing configuration files that
>> have "list" settings.
>>
>> To test this you can try to create a file in /tmp/network:
>>
>> config interface 'lan'
>> list ipaddr '192.168.99.1/24'
>>
>> and then import it with:
>>
>> uci import -m -f /tmp/network network
>> uci commit network
>>
>> then import it again:
>>
>> uci import -m -f /tmp/network network
>> uci commit network
>>
>> results in:
>>
>> config interface 'lan'
>> list ipaddr '192.168.99.1/24'
>> list ipaddr '192.168.99.1/24'
>>
>> two questions:
>>
>> is this intended behaviour or is it a bug?
>> can something like this break the configuration or OpenWRT will select just
>> the last one?
>>
>> Thanks
>> Federico
> 
> There is currently no rule against duplicate entries in list type
> options and there may exist a situation where values in a list are not
> unique to each other.  So I guess the result is expected.

If the operation could be idempotent it would be nice.

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [UCI] uci import -m duplicates list options

[Nemesis]

Hi,

I've incurred inweird behaviour when using the import feature of the uci
toolwhich seems to cause duplicates whenimporting configuration files
that have "list" settings.

To test this you can try to create a file in /tmp/network:

config interface 'lan'
list ipaddr '192.168.99.1/24'

and then import it with:

uci import -m -f /tmp/network network
uci commit network

then import it again:

uci import -m -f /tmp/network network
uci commit network

results in:

config interface 'lan'
list ipaddr '192.168.99.1/24'
list ipaddr '192.168.99.1/24'

two questions:

  * is this intended behaviour or is it a bug?
  * can something like this break the configuration or OpenWRT will
select just the last one?

Thanks
Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] NetJSON status at the beginning of 2016

[Nemesis]

Hi everyone,

last year I announced [1] an initiative to create a few common JSON data
structures to improve interoperability,
you can find that announcemente at:

More than 1 year has passed since that announcement and today we have an
RFC [2] and a few implementations [3].
The RFC has not been sent to the IETF yet but it is our intention to do
so in the coming months.

The "DeviceConfiguration" object [4] is particularly relevant for
OpenWRT, because it has been inspired a lot by
the ubus output.

The two implementations that deal with configurations are netjsonconfig
[5] and django-netjsonconfig [6].

Since the RFC is still draft version 0, there's still wide room for
improvement before sending it to the IETF
and thatis why I'm sending this email: I invite anyone interested in the
subject to participate in this process now rather than later.
Please forward this email if you think other groups might be interested
in participating in the discussion.

Federico Capoano

[1] announcement:
https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030422.html
[2] NetJSON RFC: http://netjson.org/rfc.html
[3] NetJSON implementations:
https://github.com/interop-dev/netjson#implementations
[4] DeviceConfiguration object: http://netjson.org/rfc.html#rfc.section.5
[5] netjsonconfig: http://netjsonconfig.openwisp.org/
[6] django-netjsonconfig: https://github.com/openwisp/django-netjsonconfig


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] dev.openwrt.org not sending emails

[Nemesis]

The ticket has been created, but an error occurred while sending
notifications: [Errno 111] Connection refused

I also did not receive the confirmation mail with the token to activate
my trac account.

Nemesis
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] OpenVPN init.d (procd) script lacks "service_triggers" section

[Nemesis]

I was expecting the ​openvpn.init script to include something like:

service_triggers()
{
procd_add_reload_trigger "openvpn"
}

But it doesn't. This makes "/sbin/reload_config" ineffective for openvpn.
Is that intentional? If not intentional I can send a patch.
I already tested the patch and it works.

I opened an issue at https://dev.openwrt.org/ticket/21469 but probably
no one was notified because it seems trac can't send emails right now.

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Git mirror with branches, tags and full history

[Nemesis]

Hi Steven,

thank you very much for this effort.

It's really handy to be able to watch the repo on github, browse the
commits and all the rest.

Federico
 

On 11/09/2015 10:06 AM, Steven Barth wrote:
> Hey everyone,
>
> I took the time last week to create a full-history git-mirror with
> branches, author mapping and release tags. It is currently on github,
> but it will probably end up on git.openwrt.org in the end.
>
> Note: Do NOT send us pull requests to this repository, they will be
> ignored. Send patches to this mailing-list instead.
>
> Now finally the mirror is at: https://github.com/openwrt/openwrt
> Since the authors are mapped, it is NOT compatible with the current
> git-mirror.
>
> Let us know what you think.
>
>
>
> Cheers,
>
> Steven
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Nemesis]

As far as I remember, there's no initiative going on, but the issue was
brought up at the summit by different speakers.

There was also a quick poll:

1. Kathy Giori asked the attendees to raise their hand if they backed
the idea of an OpenWRT foundation
I would say half of the presents raised their hands (I did not because
I'm not involved so much in OpenWRT and I don't feel entitled to take sides)

2. Kathy asked the attendees to raise their hand if they opposed the
idea of an OpenWRT foundation
I think there were almost no raised hands or not at all

Federico


On 10/13/2015 12:46 PM, Sorin Burjan wrote:
> Hello Kaloz,
>
> is there any initiative to create a non-profit organization ?
>
> Regards,
> Sorin B.
>
> On Tue, Oct 13, 2015 at 1:44 PM, Imre Kaloz  > wrote:
>
> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
> > wrote:
>
> 
>
> It should be easy possible to get funding from all the
> companies which
> work with OpenWrt. Is this in option?
>
>
> Not until we have a nonprofit organization as companies can't have
> tax deduction in exchange.. This is pretty much the main issue
> people from said companies brought up at the summit as well.
>
>
> Imre
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> 
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Nemesis]

On 10/12/2015 09:44 AM, John Crispin wrote:
> On 12/10/2015 09:07, Steven Barth wrote:
>> > And don't get me started about having a completely different Issuetracker 
>> > with
>> > different credentials etc.
> indeed there i this thing called trac which i wonder if people actually
> use/look at.
>
> so we really have 3 issues at hand
>
> 1) switch the core tree to using git
> 2) make sure that release branches have a history
> 3) pull from github trees
>
> 1) & 2) are just technical / organizational issues i guess
>
> as for 3), if we move to gihub we have yet another entry point that we
> need to look after. ok, we could close trac but that would just move the
> "noise" from one place to another. obsoleting the rest of the existing
> infra is also a bit quirky i guess as people are using it actively.

The Django Framework moved from SVN to github in 2012but they kept their
own bug tracker (which they redesigned with some funding to make it more
usable): https://code.djangoproject.com/

I think they're a good example of an open source community which went
through the process of improving the way people can join the community
and contribute, they also raise funds to pay for hard tasks like
redesigning the website, organizing sprints, periodically hire a
"fellow" which reviews (accepts/closes and occasionally fixes) tickets
and so on.
Since they started doing this django has improved massively.

I understand the desire to self host, so I suggest to take a look at
gitlab community edition.

Federico


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Nemesis]

On 10/10/2015 07:45 PM, nemesis wrote:
> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin
> <leroi.li...@gmail.com> wrote:
>> On 9 October 2015 at 21:22, Jo-Philipp Wich <j...@openwrt.org> wrote:
>>> Hi.
>>>
>>>> Moving to Git seemed to have lots of traction at the summit, and I'll
>>>> add my voice that this sounds like a step in the right direction for
>>>> OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
>>>> conversion, and Eric's help on this would be great, I think.  My
>>>> discussion with Eric is over on Google+ and marked public:
>>>> https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>>>
>>> Why does the core system need to migrate from svn to git?
>>>
>>
>> I thought everybody is using git anyway already. Are there people
>> still using svn?
>
> doing something because everybody is doing so is not the best argument
> IMHO.
>
> I would say that using git would improve quite a few things:
>
> * it would be easier to send upstream patches
> * having a good git web interface like gitlab or github would allow
> newcomers to participate more easily
> * it would make life easier to the core contributors that prefer to
> work with git because git allows a very powerful development workflow
> compared to SVN

I remember somebody also mentioned sending patches to the linux kernel
would be easier.

What do you people think about this point?

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[nemesis]

On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin 
 wrote:

On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:

Hi.

Moving to Git seemed to have lots of traction at the summit, and 
I'll
add my voice that this sounds like a step in the right direction 
for

OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
conversion, and Eric's help on this would be great, I think.  My
discussion with Eric is over on Google+ and marked public:
https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS


Why does the core system need to migrate from svn to git?



I thought everybody is using git anyway already. Are there people
still using svn?


doing something because everybody is doing so is not the best argument 
IMHO.


I would say that using git would improve quite a few things:

* it would be easier to send upstream patches
* having a good git web interface like gitlab or github would allow 
newcomers to participate more easily
* it would make life easier to the core contributors that prefer to 
work with git because git allows a very powerful development workflow 
compared to SVN


Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Ubiquiti AirOS7 is based on openwrt r40432

[Nemesis]

On 03/13/2015 09:10 PM, Bastian Bittorf wrote:
 * Nemesis neme...@ninux.org [13.03.2015 11:59]:
   see, they use an acient php from:
   http://museum.php.net/php2/
  
  I've noticed, why is that?
 i guess: the webinterface? - bye, bastian

I understand theyadded PHPfor the web UI, I do not understand why PHP 2
instead of a newer version though. Maybe because it's smaller/lighter?

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Ubiquiti AirOS7 is based on openwrt r40432

[Nemesis]

Hi all,

I went at this URL:
https://www.ubnt.com/download/?group=nanobeam-ac

Clicked on GPL Archive, downloaded it, extracted it, and took a look
in it and found out a readme file which states:

that the archive contains all GPL related sources and modifications made
by Ubiquiti Networks on original OpenWRT-r40432 sources.

So out of pure curiosity, I used some git trickeries and hacks to make a
clean diff of the two, then decided to upload it on github so everyone
can see it easily.

Here it is:
https://github.com/ninuxorg/openwrt-modified-by-ubiquiti/compare/0f06f302caa1d53bf0e1550aaadf738166c53c26...master

Anybody else has studied this code and found out anything interesting?

Best regards
Federico Capoano
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Ubiquiti AirOS7 is based on openwrt r40432

[Nemesis]

On 03/12/2015 02:12 PM, Bastian Bittorf wrote:
 * Nemesis neme...@ninux.org [12.03.2015 14:08]:
 Anybody else has studied this code and found out anything interesting?
 8-)))

 see, they use an acient php from:
 http://museum.php.net/php2/

I've noticed, why is that?

I also noticed some mysql stuff, what do they use it for?

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Google Summer of Code 2015

[Nemesis]

Hi guys,

Freifunk and Ninux are applying for the GSoC 2015.

You might want to propose projects ideas if you feel like it.

Freifunk ideas page: http://wiki.freifunk.net/Ideas

Ninux ideas page: http://wiki.ninux.org/GSoCIdeas2015

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] JSON data interchange format for networks

[Nemesis]

Hi everybody,

in the past 2months some people have been working on a simple idea,
which would bring a lot of benefits to many peopleand that for some
strange reason has not been implemented yet, probably because the effort
is more human than technical, as many different people have to work
together and come to agreements.

But here's the idea:

Immagine you could export adevice configuration in JSON format and
reimport that somewhere else,like monitoring software, node database, or
whatever you need.
Something like this:
https://github.com/interop-dev/json-for-networks/blob/master/examples/device-configuration.json

Immagine you could extract monitoring data with a simple JSONthat has a
similar structure to the device configuration, that would enable
different software to play well with one another, instead of building
silos that don't talk to each other.
Something like this:
https://github.com/interop-dev/json-for-networks/blob/master/examples/monitoring-data.json

Immagine the olsr json info plugin, or the json output by batman, but
instead of being all different,they shared a common structure, and
differed only in the key/value pairs that are specific to their protocol.
That would be easier to parse for who develops software to represent
those topologies visually.
Something like this:
https://github.com/interop-dev/json-for-networks/blob/master/examples/network-routes.json

Now, this is not some weird utopic idea. A similar thing has been done
in the GIS field: *GeoJSON*.
You can pass GeoJSON to any GIS library, written in any language, and it
will understand what is that you are passing. You can visualize that
GeoJSON on a map with leaflet or openlayers, you can useit to calculate
distances and stuff on the server side, you can output on an HTTP API,
or whatever.

Here there's a very early draft of the spec:
https://github.com/interop-dev/json-for-networks

Before we start implementing it in softwares like node databases,
monitoring systems and firmwares, we would love to have some feedback
from you guys as everybody in our communities use OpenWRT.

We would like to know if anyone else has been working on a similar idea
and we would like to have constructive critical feedback and improve our
early spec before starting to prototype.

If anybody will be at Fosdem we can also discuss in person there.

Cheers to all and hope to see many of you at the next battlemesh in
Slovenia.

Federico Capoano (aka Nemesis)
Ninux.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel